[pkt-prov] MTA MIB Error OID table - a number of questions

Folks,

   We received one comment from Dave Thaler during the IETF mib doctor review on the MTA MIB ErrorOID table for which I would like to request some input from the lists (comment #11 from Dave).

1. Max range of the index object:
   pktcMtaDevErrorOidIndex  OBJECT-TYPE  
   SYNTAX      Unsigned32 (1..1024)
                              ^^^^
Is there any reason why we are limiting the size of this object? From an implementation point of view on the snmp mib agent, is this limitation buying much?


2. What happens if more than 1024 errors are encountered?
Hopefully this does not happen often since the operators manage the config files and it is extremely rare to have config files with over 1024 entries or with a smaller number of entries causing 1024 errors. 
That said, if we keep the range as-is, per Dave's recommendation, we should define properly what happens after the value 1024 is reached so that all MTA vendors do it consistently and so that SNMP mgers can act accordingly in those cases.

Assuming we keep the range as is (1..1024), there are a couple of options for MTAs to populate the table when a 1025th error is encountered:
  - ">/dev/null": forget about it, any error after 1024 does not get stored, only the first 1024 errors are present in the table,
  - "wrap": overwrite entries starting with entry 1, so 1025 -> 1, 1026 -> 2, etc.
  - "tail": just overwrite the last entry (1..1023 remain stable, 1024 is updated with the latest error: 1025 -> 1024, 1026 -> 1024, etc.)

The "wrap" mode is not a good option in my opinion for 2 reasons:
      - by analogy with compilation errors we sometimes encounter with C++/C/SMI, an error early on in the file being parsed can cause numerous subsequent errors which are not very relevant;
      - in this particular case of config files with TLV tuples, if something goes wrong on the MTA misinterpreting the length of a TLV for e.g., all subsequent TLV parsing will be affected.
=> "wrap" won't help troubleshoot the primary errors.

My preference would be ">/dev/null". It is simpler for MTAs and if there are 1024 errors, who cares about the remaining ones (based on the above). The "tail" mode is misleading in my opinion and is not very relevant as intermediate entries (1025..max_errors-1) will be missed.

Are there any other/better options if we keep the range? Any comments on the above?

Jean-François