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

Thanks Dave.
Bert 

> -----Original Message-----
> From: Dave Thaler [mailto:[email protected]]
> Sent: woensdag 4 augustus 2004 23:33
> To: [email protected]; [email protected]
> Cc: [email protected]; Wijnen, Bert (Bert); [email protected];
> 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 [...]
>