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

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 11 Jan 2005 16:34:53 -0700

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: "Dave Thaler" <[email-masked]>
Date: Wed, 12 Jan 2005 12:02:42 -0800

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

> 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,
> 
>   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.
> 
>  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:

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Thu, 13 Jan 2005 09:46:42 -0800

> If that is not practical, then, 
> at least for the cases that a script or automated management 
> system would need to recognize, the EXACT strings that appear 
> in protocol should be spelled out, with recognition that a 
> user interface might present some localized equivalent.

Let me remind you that the initial concern was the presense of almost
mandatory requirement for the EXACT particular string 'TOO MANY ERRORS
IN THE CONFIGURATION FILE' which seemed to be not in line with the
language localization on the managed device (if such required in some
environments). As a recognition of this, the modification has been
proposed which softened the requirement.

Given the fact that the NMSs can accommodate various logics of mapping
the messages generated by the range of devices to the locally
meaningfull events, the last proposed text seems to be satisfactory
because it 1). allows localized text on the managed devices (if
necessary), and 2). still does not prevent the NMSs from using the
corresponding localization policies with the managed devices.

Eugene.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Randy Presuhn
Sent: Wednesday, January 12, 2005 11:19 PM
To: [email-masked]
Subject: Re: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of
questions

Hi -

> From: "Eugene Nechamkin" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, January 12, 2005 8:44 PM
> If your concern is the usage of the object in the different lingual 
> environments with presumably normative language in the object's 
> description, then the proposed, I believe, adequately addresses your 
> concern. If your concern is the interoperability, then the object 
> itself, without the normative requirement, carries the informative 
> meaning for the NMS personal, and is becoming even wider
interoperable.
>
> If this is still not satisafctory, please feel free to make a specific

> editorial suggestion.
...

A managed device has no way of knowing what locale(s) may be in effect
on the network management systems (both human-controlled and purely
automated) that are communicating with it.  The locale in effect may
even change, depending on which operator is currently using a management
system.
Consequently, localization of error messages is something to be done at
the management systems, not the managed devices.

NMS operators are not all human.  More and more work is done by scripts
and programs working on behalf of humans.  In general software isn't all
that good at figuring out "semantic equivalents".  The problem is even
worse if the localized text doesn't carry some kind of language tag.

Error messages are quite different from names and labels.  The latter
can be treated as opaque values by software, and in general there's no a
priori value that can be associated with them.  Error messages, on the
other hand, do have semantics, and management software will be expected
to alter its behaviour based on the messages it encounters.

My preference is for a machine-readable enumeration of error codes.
If that is not practical, then, at least for the cases that a script or
automated management system would need to recognize, the EXACT strings
that appear in protocol should be spelled out, with recognition that a
user interface might present some localized equivalent.

Randy

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Thu, 13 Jan 2005 10:31:03 -0800

To address this concern, the last veraion of the description clause with the softer language allowing the locatlization has been introduced (see the latest e-mail exchange on the topic).

Eugene.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Thaler
Sent: Wednesday, January 12, 2005 12:03 PM
To: Jean-Francois Mule; [email-masked]
Cc: Eugene Nechamkin; 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 
	> '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

> behavior should be when the number of errors exceeds the table size 
> limit of 1024.
> 
> 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: