RE: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt

["Jean-Francois Mule" <[e-mail]>]

Just a minor editorial change in our informative text to explain why the pktcMtaDevErrorOid is of type SnmpAdminString.

:
On Tuesday, January 11, 2005 at 4:47 PM, I had proposed:
>          "Note that the syntax of this object is SnmpAdminString
>           rather OBJECT IDENTIFIER because the object value is
>           provided by an operator in the MTA configuration file
>           in the form of a character string."

Based on Eugene's comment, the newly proposed text is:
          Note that the syntax of this object is SnmpAdminString
          rather OBJECT IDENTIFIER because the object value may
          not be a valid OID due to human or configuration tool
          encoding errors.

Let us know if this new proposed text is an issue.
Jean-François 

> -----Original Message-----
> From: Jean-Francois Mule 
> Sent: Tuesday, January 11, 2005 4:47 PM
> To: Dave Thaler; [e-mail]
> Cc: [e-mail]; Wijnen, Bert (Bert); 
> [e-mail]; C. M. Heard
> Subject: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt
> 
> 
> To close on one additional comment:
> Dave wrote:
> > 12) pktcMtaDevErrorOid, pktcMtaDevErrorValue, etc:
> >     why are OIDs of type SnmpAdminString rather than an
> > OBJECT IDENTIFIER
> >     type/subtype?  As is, the management station cannot do 
> > simple things
> >     like expanding the OID into the defined string tokens 
> in the MIB.
> 
> We discussed this point during the IETF IPCDN meeting #61, 
> see proceedings at:  
> <http://www1.ietf.org/proceedings_new/04nov/ipcdn.html#cmr>
> 
> The meeting minutes recorded:
>     In the WG meeting, we had consensus that since the OID and its
>     value is provided in the MTA config file by an operator in the
>     form of a character string, it is better to leave the syntax
>     as SnmpAdminString rather than OBJECT IDENTIFIER. It was also
>     requested that the above explanation be mentioned in the doc.
> 
> So, the resolution is:
>     - no object syntax change
>     - change the description of the pktcMtaDevErrorOid to 
> indicate the following:
>          "Note that the syntax of this object is SnmpAdminString
>           rather OBJECT IDENTIFIER because the object value is
>           provided by an operator in the MTA configuration file
>           in the form of a character string."
>     - after more review of the pktcMtaDevErrorValue object, 
> we do not believe the above text should be added to its 
> description as this pktcMtaDevErrorValue object may contain 
> all kinds of object values in the case where the MTA can 
> recognize the OID but cannot interpret the given value.
> 
> Proposed text changes:
> 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.
>           Note that the syntax of this object is SnmpAdminString
>           rather OBJECT IDENTIFIER because the object value is
>           provided by an operator in the MTA configuration file
>           in the form of a character string."
>     ::= {pktcMtaDevErrorOidsEntry 2}
> 
> 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: Dave Thaler [mailto:[e-mail]]
> > Sent: Thursday, August 05, 2004 12:33 AM
> > To: [e-mail]; Jean-Francois Mule
> > Cc: [e-mail]; Wijnen, Bert (Bert); 
> > [e-mail]; C. M. Heard
> > Subject: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt
> > 
> > 
> > Here's my MIB Doctor review of this document and what I
> > believe MUST/SHOULD/MAY be fixed.
> > 
> > MUST fix
> > --------
> > 1) There is no IANA Considerations section, and this is now
> > required in the
> >    new guidelines.  The draft needs something like (based on 
> > the template 
> >    in the guidelines):
> > 
> >        9. IANA Considerations
> > 
> >        The MIB module in this document uses the following
> > IANA-assigned
> >        OBJECT IDENTIFIER values recorded in the SMI Numbers 
> registry:
> > 
> >        Descriptor        OBJECT IDENTIFIER value
> >        ----------        -----------------------
> >        pktcMtaMib        { mib-2 XXX }
> > 
> >        Editor's Note (to be removed prior to publication):
> > the IANA is
> >        requested to assign a value for "XXX" under the 'mib-2'
> >        subtree and to record the assignment in the SMI 
> > Numbers registry.
> >        When the assignment has been made, the RFC Editor is asked to
> >        replace "XXX" (here and in the MIB module) with the assigned
> >        value and to remove this note.
> > 
> > 2) The page header on pages 2-51 says July 2002
> > 
> > 3) MIB Guidelines say
> >     If the module was developed by an IETF working group, then the
> >     ORGANIZATION clause MUST provide the full name of the
> > working group
> >                                          ^^^^^^^^^
> > 
> >    The draft just uses the WG acronym:
> >        ORGANIZATION "IETF IPCDN Working Group "
> > 
> > 4) The LAST-UPDATED date predates the REVISION date:
> >        LAST-UPDATED "200406160000Z" -- June 16, 2004
> >        REVISION     "200407160000Z"
> >                           ^
> > 
> > 5) pktcMtaBasicSmtaCompliance contains
> >        MODULE DOCS-CABLE-DEVICE-MIB
> >            MANDATORY-GROUPS {
> >                docsDevSoftwareGroupV2
> >            }
> >    but RFC2669 is not referenced as a normative reference
> >    and docsDevSoftwareGroupV2 isn't in there anyway, only
> >    docsDevSoftwareGroup.  Is this blocked on the progression
> > of another
> >    document containing this?  Looks like this used to be in
> >    draft-ietf-ipcdn-device-mibv2-*.txt which has now expired.
> > 
> > 6) SEQUENCE element #4 `pktcMtaDevCmsSolicitedKeyTimeout'
> > does not match
> > 
> >    order of columnar objects under `pktcMtaDevCmsEntry'.
> >    Should swap the following two lines:
> >        pktcMtaDevCmsSolicitedKeyTimeout          Unsigned32,
> >        pktcMtaDevCmsMaxClockSkew                 Unsigned32,
> > 
> > 7) pktcMtaDevProvisioningState has 'passWithWarning' 
> (singular) in the
> >    enum, but 'passWithWarnings' (plural) twice in the DESCRIPTION.
> >    Also has 'failOtherReason' in the enum but 'failureOtherReason' 
> >    in the DESCRIPTION.
> > 
> > 8) The comment on page 29 refers to
> > draft-ietf-ipcdn-pktc-signaling-02.txt
> >    This should be added to the references section of the doc.
> >    Also grammar error "Upper case must be use to"
> >                                           ^^^
> > 
> > 9) Typo in DESCRIPTION of pktcMtaDevCmsKerbRealmName:
> >    realm table (pktcMtaDevRealmtable)."
> >                                ^ capitalize
> > 
> > 10) The DESCRIPTION of pktcMtaDevRealmTgsGracePeriod has
> > weird indentation,
> >     and includes weird characters (as do several other objects).
> > 
> > SHOULD fix
> > ----------
> > 11) pktcMtaDevErrorOidIndex: say what happens after the 
> value 1024 is 
> >     reached
> > 
> > 12) pktcMtaDevErrorOid, pktcMtaDevErrorValue, etc:
> >     why are OIDs of type SnmpAdminString rather than an
> > OBJECT IDENTIFIER
> >     type/subtype?  As is, the management station cannot do 
> > simple things
> >     like expanding the OID into the defined string tokens 
> in the MIB.
> > 
> > 13) pktcMtaDevServerDhcp1, pktcMtaDevServerDns1, etc: the
> > DESCRIPTION of
> > 
> >     these objects is worded as if the type is a string 
> rather than an
> >     InetAddress (the "dotted" IP address, etc).  Technically,
> > there's no
> >     dots in the value, only in the displayed version of it.
> > 
> > 14) pktcMtaDevServerAddressType: what does it mean for this
> > to be read-write
> >     but the dependent InetAddress fields to be read-only?  
> I.e., what 
> >     happens to the latter immediately after the former is set?
> > 
> > MAY fix
> > -------
> > 15) Consider defining a TC for kerberos realm names, since
> > this is used by 
> >     multiple objects (pktcMtaDevProvKerbRealmName, 
> > pktcMtaDevRealmName,
> >     and pktcMtaDevCmsKerbRealmName) and has special syntax 
> > restrictions 
> >     (1..255 upper case ASCII chars) 
> > 
> > 16) The current conformance statements require read-write in
> > implementations
> >     to be compliant.  Is this intended?  Since it currently 
> > only supports
> >     ipv4, it doesn't seem useful to require read-write access to the
> >     InetAddressType objects.
> > 
> > 17) pktcMtaDevSwCurrentVers is redundant with sysDescr, so
> > why is this 
> >     needed?  The draft says:
> >         The data presented in this object MUST be
> >         identical to the software version information contained
> >         in the 'sysDescr' MIB object of the MTA.
> > 
> > 18) The MIB guidelines suggest using { pktcMtaMib 0 } for the 
> >     notification prefix.  The draft currently requires two
> > definitions:
> > 
> >     pktcMtaNotificationPrefix OBJECT IDENTIFIER ::= { pktcMtaMib 2 }
> >     pktcMtaNotification OBJECT IDENTIFIER ::= {
> >          pktcMtaNotificationPrefix 0 }
> > 
> >     Is there a good reason for this? (e.g. already deployed
> > implementations?)
> > 
> > 19) What is the expected behavior when reading
> > pktcMtaDevRealmName and 
> >     pktcMtaDevRealmOrgName when the row is first created 
> and they are 
> >     not set?  (There's no DEFVAL, and the MIB doesn't say 
> > they have to 
> >     be set in the initial createAndWait set.)
> > 
> > 20) draft-ietf-ipcdn-bpiplus-mib-12.txt is referenced, and is now
> >     draft-ietf-ipcdn-bpiplus-mib-13.txt
> > 
> > 21) The wording in section 8 varies marginally from the template.
> > 
> >     Template:
> >     > Some of the readable objects in this MIB module (i.e.,
> > objects with a
> >     > MAX-ACCESS other than not-accessible) may be considered 
> > sensitive or
> >     
> >     Actual:
> >     > Some of the readable objects in this MIB module may be
> > considered
> >     > sensitive or [...]
> > 
> > 
> > 
> 
> _______________________________________________
> IPCDN mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 
> 

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