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

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

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