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

The problem I have with 
	> must all be equal to
	> 'TOO MANY ERRORS IN THE CONFIGURATION FILE'
is that nothing else in the DESCRIPTION clauses indicates
that the text must be in English, and this introduces a MUST
which is not localizable to other languages.

-Dave

> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email protected]]
> Sent: Tuesday, January 11, 2005 3:35 PM
> To: [email protected]
> Cc: [email protected]; Dave Thaler; Sumanth Channabasappa;
> PacketCable Provisioning and OSS Majordomo List; Leandro Rzezak
> Subject: RE: [ipcdn] [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