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

["Leandro Rzezak" <[e-mail]>]

About the 2nd issue, perhaps going with the ">/dev/null" mode but
overwriting the 1024th error with a warning...

Regards,

Leandro Rzezak
Intraway Corp.
http://www.intraway.com
 
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Jean-Francois Mule
Sent: Thursday, August 12, 2004 5:11 PM
To: [e-mail]; PacketCable Provisioning and OSS Majordomo List
Cc: [e-mail]; Dave Thaler
Subject: [ipcdn] [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 



_______________________________________________
IPCDN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn


_______________________________________________
IPCDN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn