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

From: "Eugene Nechamkin" <[email-masked]>
Date: Wed, 12 Jan 2005 15:34:01 -0800

As the "must" is not a normative requirement in this particular case, the string mentioned in the decsription clause does not seem to be too restrictive and should not pose problems in localized environments.

Eugene. 

-----Original Message-----
From: Dave Thaler [mailto:[email-masked]] 
Sent: Wednesday, January 12, 2005 12:03 PM
To: Jean-Francois Mule; [email-masked]
Cc: Eugene Nechamkin; Sumanth Channabasappa; PacketCable Provisioning and OSS Majordomo List; Leandro Rzezak
Subject: RE: [ipcdn] [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-masked]]
> Sent: Tuesday, January 11, 2005 3:35 PM
> To: [email-masked]
> Cc: [email-masked]; 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-masked]]
> > Sent: Thursday, August 12, 2004 6:32 PM
> > To: Leandro Rzezak; Jean-Francois Mule; [email-masked]; PacketCable 
> > Provisioning and OSS Majordomo List
> > Cc: [email-masked]; 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-masked] on behalf of Leandro Rzezak
> > Sent: Thu 8/12/2004 3:00 PM
> > To: 'Jean-Francois Mule'; [email-masked]; 'PacketCable Provisioning 
> > and OSS Majordomo List'
> > Cc: [email-masked]; '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-masked] [mailto:[email-masked]] On 
> > Behalf Of Jean-Francois Mule
> > Sent: Thursday, August 12, 2004 5:11 PM
> > To: [email-masked]; PacketCable Provisioning and OSS Majordomo List
> > Cc: [email-masked]; 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 12 Jan 2005 18:44:42 -0800

Hi -

> From: "Eugene Nechamkin" <[email-masked]>
> To: "Dave Thaler" <[email-masked]>; "Jean-Francois Mule" <[email-masked]>; <[email-masked]>
> Cc: "Leandro Rzezak" <[email-masked]>; "PacketCable Provisioning and OSS Majordomo List"
<[email-masked]>
> Sent: Wednesday, January 12, 2005 3:34 PM
> As the "must" is not a normative requirement in this particular case,

That's not what the proposed text says.  The proposal says

|           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'."

I see no way to read those words as non-normative.
An implementation that used any other string would not
be conformant.

>  the string mentioned in the decsription clause does not seem to be too
> restrictive and should not pose problems in localized environments.
...

These objects worry me.   Has someone looked at them from
the perspective of RFC 2130?  Also, is the fact that all the examples
are all in English and all in capital letters somehow significant?

Randy