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

From: "Eugene Nechamkin" <[email-masked]>
Date: Fri, 14 Jan 2005 14:41:36 -0800

A slight modification of the approach: if we use the pktcMtaDevErrorOid
and pktcMtaDevErrorValue to indicate the patrticular OID of
pktcMtaDevErrorsTooManyErrs, and use the pktcMtaDevErrorReason to
indicate the non-mandatory part of the error message, then it should
provide both - interoperability and flexibility. 

So the following should address additional concerns:

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 the errors in the configuration file
          exceeds 1024, all errors beyond the 1024th one MUST 
          be ignored - these subsequent errors MUST NOT be 
          reflected in the pktcMtaDevErrorOidsTable."
    ::= {pktcMtaDevErrorOidsEntry 1}

pktcMtaDevErrorOid  OBJECT-TYPE  
    SYNTAX      SnmpAdminString
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION 
        " This object contains a human readable representation
          (character string) of the OID corresponding to the
          configuration file parameter that caused the particular
          error.
          For example, if the value of the pktcMtaDevEnabled object
          in the configuration file caused an error, then this
          object instance will contain the human readable string of
          '.1.3.6.1.2.1.XXX.1.1.6.0'.
    ************************************************************
    * NOTES TO RFC Editor (to be removed prior to publication) *
    * Please replace XXX with the IANA-assigned number under   *
    * mib-2.                                                   *
    ************************************************************

          If the MTA generated an error because it was not able 
          to recognize a particular OID, then this object 
          instance would contain an empty value (zero-length
          string).
          For example, if the value of an OID in the configuration 
          file was interpreted by the MTA as being .1.2.3.4.5, and 
          the MTA was not able to recognize this OID as a valid one,
          this object instance will contain a zero-length string.
          
          If the numbers of errors in the configuration file exceeds 
          1024, then for all subsiquent errors, the pktcMtaDevErrorOid 
          of 1024th table's entry MUST contain the a human readable 
          representation of the pktcMtaDevErrorsTooManyErrs object, 
          i.e. the string '.1.3.6.1.2.1.XXX.1.1.4.1.0'.
    ************************************************************
    * NOTES TO RFC Editor (to be removed prior to publication) *
    * Please replace XXX with the IANA-assigned number under   *
    * mib-2.                                                   *
    ************************************************************

          Note that the syntax of this object is SnmpAdminString
          rather OBJECT IDENTIFIER because not all of the parameters
          which can be potentially included into the configuration 
          file have necessarily the OID associated with them. For 
          example, TLV38 parameters do not have the valid mapping to 
          any particular valid OID. In such cases, the object MUST 
          contain the string uniquely identifying the parameter in
          error among all the parameters included into the 
          configuration file. For example, for the TLV38 
          parameter which has the wrong value in its suboption-1, 
          the string may look like '38.1'."
    ::= {pktcMtaDevErrorOidsEntry 2}

pktcMtaDevErrorValue  OBJECT-TYPE
    SYNTAX      SnmpAdminString
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        " This object contains the value of the OID corresponding to
          the configuration file parameter that caused the error.
          If the MTA cannot recognize the OID of the
          configuration parameter causing the error, then this
          object instance contains the OID itself as interpreted
          by the MTA in human readable representation.
          If the MTA can recognize the OID but generate an error due
          to a wrong value of the parameter, then the object
          instance contains the erroneous value of the parameter as
          read from the configuration file.
          In both cases, the value of this object must be
          represented in human readable form as a character string.
          For example, if the value of the pktcMtaDevEnabled object
          in the configuration file was 3 (invalid value), then the
          pktcMtaDevErrorValue object instance will contain the
          human readable (string) representation of value '3'.
          Similarly, if the OID in the configuration file has been
          interpreted by the MTA as being .1.2.3.4.5, and the MTA
          cannot recognize this OID as a valid one, then this
          pktcMtaDevErrorValue object instance will contain human
          readable (string) representation of value '.1.2.3.4.5'.

          If the numbers of errors in the configuration file exceeds 
          1024, then for all subsiquent errors, the pktcMtaDevErrorValue

          of 1024th table's entry MUST contain the a human readable 
          representation of the pktcMtaDevErrorsTooManyErrs object, 
          i.e. the string '.1.3.6.1.2.1.XXX.1.1.4.1.0'.
    ************************************************************
    * NOTES TO RFC Editor (to be removed prior to publication) *
    * Please replace XXX with the IANA-assigned number under   *
    * mib-2.                                                   *
    ************************************************************"
    ::= {pktcMtaDevErrorOidsEntry 3}

pktcMtaDevErrorReason  OBJECT-TYPE
    SYNTAX      SnmpAdminString
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        " This object indicates the reason for the error or warning,
          as per the MTA's interpretation, in human readable form.  
          Example of possible reason values are:
          'VALUE NOT IN RANGE', 'VALUE DOES NOT MATCH TYPE',
          'UNSUPPORTED VALUE', 'LAST 4 BITS MUST BE SET TO ZERO',
          'OUT OF MEMORY - CANNOT STORE', etc.
          This object may also contain vendor specific errors for
          private vendor OIDs and any proprietary error codes or 
          messages which can help diagnose configuration errors.

          If the numbers of errors in the configuration file exceeds 
          1024, then for all subsiquent errors, the
pktcMtaDevErrorReason 
          of 1024th table's entry will contain a human readable string 
          indicating the reason for an error, for example, 
          'Too many errors in the configuration file.'."
    ::= {pktcMtaDevErrorOidsEntry 4}

Eugene.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Randy Presuhn
Sent: Thursday, January 13, 2005 9:44 PM
To: [email-masked]
Subject: Re: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number
ofques tions

Hi -

I like this latest proposal more.  However, I think the DESCRIPTION of
pktcMtaDevErrorOidIndex needs a little more work.  Specifically,

> From: "Eugene Nechamkin" <[email-masked]>
> To: "Wijnen, Bert (Bert)" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, January 13, 2005 9:19 PM
> Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number 
> ofques tions
...
> pktcMtaDevErrorOidIndex  OBJECT-TYPE
 ...
>           pktcMtaDevErrorOidsTable. In this case, the value of the
>           pktcMtaDevErrorOid, pktcMtaDevErrorValue, and

remove pktMtaDevErrorOid from this list.

>          pktcMtaDevErrorReason objects for the 1024-th table entry
>           MUST all be contain the following error string:

replace "be contain" with "be"

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

"contains" should be something like "will be replaced with"

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

Delete the leading "."

Add:
            The object pktMtaDevErrorOid MUST in this case have the
             value '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."
...

This "should be semantically close" contradicts the "MUST" which appears
earlier.

Randy

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 17 Jan 2005 14:33:21 -0800

Hi -

> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Friday, January 14, 2005 2:41 PM
> Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number ofques tions
...
>           '.1.3.6.1.2.1.XXX.1.1.6.0'.

Get rid of the leading "."

...
>           file was interpreted by the MTA as being .1.2.3.4.5, and

Get rid of the leading "."

 ...
>           i.e. the string '.1.3.6.1.2.1.XXX.1.1.4.1.0'.

Get rid of the leading "."

...
...
>           readable (string) representation of value '.1.2.3.4.5'.

Get rid of both leading "." characters.

...
...

Get rid of the leading "."

The grammar for the dotted decimal notation does not permit a leading
dot.  The following message explains it all:

|Message-Id: <[email-masked]>
|X-Sender: [email-masked]
|X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
|Date: Fri, 23 Jun 2000 12:15:52 -0700
|To: [email-masked]
|From: "Kurt D. Zeilenga" <[email-masked]>
|Subject: Re: Where is the OID "dot convention" spelled out?
|Cc: [email-masked]
|In-Reply-To: <[email-masked]>
|Mime-Version: 1.0
|Content-Type: text/plain; charset="us-ascii"
|X-Loop: [email-masked]
|Status: RO
|
|See RFC 1778, 2.15:
|   Values of type objectIdentifierSyntax are encoded according to the
|   following BNF:
|
|     <oid> ::= <descr> | <descr> '.' <numericoid> | <numericoid>
|
|     <descr> ::= <keystring>
|
|     <numericoid> ::= <numericstring> | <numericstring> '.' <numericoid>
|
|   In the above BNF, <descr> is the syntactic representation of an
|   object descriptor. When encoding values of type
|   objectIdentifierSyntax, the first encoding option should be used in
|   preference to the second, which should be used in preference to the
|   third wherever possible. That is, in encoding object identifiers,
|   object descriptors (where assigned and known by the implementation)
|   should be used in preference to numeric oids to the greatest extent
|   possible. For example, in encoding the object identifier representing
|   an organizationName, the descriptor "organizationName" is preferable
|   to "ds.4.10", which is in turn preferable to the string "2.5.4.10".
|
|This was refined in RFC 2252, 4.1.  In particular, it eliminates
| the "ds.4.10" form.

Randy