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

Based on the proposed, here are the required modifications in the MTA
MIB to implement it:

1. The following two new objects are introduced:

pktcMtaDevErrors   OBJECT IDENTIFIER ::= { pktcMtaMibObjects 4 }  

pktcMtaDevErrorsTooManyErrs OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
        "This object defines the OID corresponding to the error 
        condition when Too Many Errors are registered in the 
        Configuration file during provisioning."
       ::= { pktcMtaDevErrors  1 }

2. The DESCRIPTION of the pktcMtaDevErrorOidIndex is modified as
follows:

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 MUST NOT be 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 contain the following error string: 
          '<Err_OID> - Too many errors in the configuration file.'.
          In this string, the <Err_OID> is the meta-symbol representing 
          the corresponding Error OID. This meta-symbol contains 
          the human readable representation (character 
          string) of the pktcMtaDevErrorsTooManyErrs object,
          i.e. the string '.1.3.6.1.2.1.XXX.1.1.4.1'.

    ************************************************************
    * NOTES TO RFC Editor (to be removed prior to publication) *
    * Please replace XXX with the IANA-assigned number under   *
    * mib-2.                                                   *
    ************************************************************

          The <Err_OID> MUST be present in the error string. The 
          rest of the error string will contain explanatory text 
          which should be semantically close to the error being 
          indicated."
    ::= {pktcMtaDevErrorOidsEntry 1}


Eugene.

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email protected]] 
Sent: Thursday, January 13, 2005 11:11 AM
To: Eugene Nechamkin; Randy Presuhn
Cc: [email protected]
Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of
ques tions

Would it be a solution to assign some OID for this message and then say
that entry 1024 would contain

  "<the assigned OID> - Too many errors in the configuration file."

In which case you have a specific value for machine readable checking
(<the assigned OID>) and human readable text that people can even
localize if they want to.

Just thinking aloud here.

Bert

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Eugene Nechamkin
> Sent: Thursday, January 13, 2005 18:47
> To: Randy Presuhn
> Cc: [email protected]
> Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of 
> questions
> 
> 
> 
> > 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 protected] [mailto:[email protected]] On Behalf

> Of Randy Presuhn
> Sent: Wednesday, January 12, 2005 11:19 PM
> To: [email protected]
> Subject: Re: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of 
> questions
> 
> Hi -
> 
> > From: "Eugene Nechamkin" <[email protected]>
> > To: "Randy Presuhn" <[email protected]>
> > Cc: <[email protected]>
> > Sent: Wednesday, January 12, 2005 8:44 PM
> > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a
> number of
> > questions
> >
> > 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
> 
> 
> 
> _______________________________________________
> IPCDN mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 
> 
> 
> _______________________________________________
> IPCDN mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipcdn
>