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

All,

  Eugene and I are updating the IETF IPCDN MTA MIB draft 06. 

  We'd like to close one of the open items that did not get address in the draft05 released in October: pktcMtaDevErrorOidsTable and what MTA behavior should be when the number of errors exceeds the table size limit of 1024.

  Based on the input received, we'd like to propose the following:
 1. keep 1024 as a reasonable number of errors in a single config file 
 2. if more than 1024 I had ping the list, >/dev/null": the MTA should forget about any subsequent errors i.e. any error after 1024 does not get stored in the table, and the last entry (1024th)'s is populated with a reason indicating that there are more errors per the suggestions received by Leandro and Sumanth on the list.

Proposed text changes:
pktcMtaDevErrorOidIndex  OBJECT-TYPE  
    SYNTAX      Unsigned32 (1..1024)
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION 
        " This object is the index of the MTA configuration error 
          table. It is an integer value which starts at value '1'
          and is incremented for each encountered configuration 
          file error or warning.
          If the number of configuration errors exceeds 1024, all
          errors beyond the 1024th one must be ignored - these 
          subsequent errors are not reflected in the
          pktcMtaDevErrorOidsTable. In this case, the value of the
          pktcMtaDevErrorOid, pktcMtaDevErrorValue, and 
          pktcMtaDevErrorReason objects for the 1024-th table entry
          must all be equal to
          'TOO MANY ERRORS IN THE CONFIGURATION FILE'."
    ::= {pktcMtaDevErrorOidsEntry 1}


Let us know if this change is acceptable or else, feel free to propose text improvements or suggestions.
Thanks,
Jean-François 

> -----Original Message-----
> From: Sumanth Channabasappa [mailto:[email protected]] 
> Sent: Thursday, August 12, 2004 6:32 PM
> To: Leandro Rzezak; Jean-Francois Mule; [email protected]; 
> PacketCable Provisioning and OSS Majordomo List
> Cc: [email protected]; Dave Thaler
> Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a 
> number of questions
> 
> 
> Hi,
> 
> I am unaware of any specific reason for the range when it was 
> proposed. (I guess it was assumed that 1024 errors would 
> exceed any errors in a single configuration file!).
> 
> I would agree on the /dev/null (but indicating in the 1024th 
> entry there were more errors!). 
> 
> Sumanth
> 
> .
> 
> -----Original Message----- 
> From: [email protected] on behalf of Leandro Rzezak 
> Sent: Thu 8/12/2004 3:00 PM 
> To: 'Jean-Francois Mule'; [email protected]; 'PacketCable 
> Provisioning and OSS Majordomo List' 
> Cc: [email protected]; 'Dave Thaler' 
> Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a 
> number of questions
> 
> 
> 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: [email protected] [mailto:[email protected]] 
> On Behalf Of Jean-Francois Mule
> Sent: Thursday, August 12, 2004 5:11 PM
> To: [email protected]; PacketCable Provisioning and OSS Majordomo List
> Cc: [email protected]; 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