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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 5 Aug 2004 20:27:01 +0200

Thanks Dave.
Bert 

> -----Original Message-----
> From: Dave Thaler [mailto:[email-masked]]
> Sent: woensdag 4 augustus 2004 23:33
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; Wijnen, Bert (Bert); [email-masked];
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 19 Aug 2004 13:56:34 -0600

Dave,

   Thank you again for your comments. 
   See my responses to the "MUST fix" items inline. 

More to follow.
Jean-Francois.

> Sent: Thursday, August 05, 2004 12:33 AM
> To: [email-masked]; Jean-Francois Mule
> Cc: [email-masked]; Wijnen, Bert (Bert); 
> [email-masked]; C. M. Heard
> Subject: [ipcdn] Review of draft-ietf-ipcdn-pktc-mtamib-04.txt
> 
> 

Ok - done: IANA section added.

> 2) The page header on pages 2-51 says July 2002
Ok - done.

>        ORGANIZATION "IETF IPCDN Working Group "
Ok - replaced with:
    ORGANIZATION "IETF IP over Cable Data Network Working Group"

>        LAST-UPDATED "200406160000Z" -- June 16, 2004
Ok - done: updated the revision date & aligned the 2.

>    draft-ietf-ipcdn-device-mibv2-*.txt which has now expired.

Yes.
Your comment raised a number of issues I have corrected in the ID:
5.a. 	section 3.6 on Secure Software Download updated:
      The issue was that this section claimed that the
docsDevSoftwareGroupV2 group was defined in the IETF BPI+ (this is
wrong). The section now says:
... the MTA MIB and the S-MTA compliance modules also rely on two MIB
object groups:
   - docsBpi2CodeDownloadGroup defined in the IETF BPI Plus MIB module
(DOCS-IETF-BPI2-MIB [RFCyyyy]), and,
   - docsDevSoftwareGroupV2 defined in the IETF Cable Devicev2 MIB
module (DOCS-CABLE-DEVICE-MIB [RFCyyy]).      

5.b.  added DOCS-CABLE-DEVICE-MIB as a normative reference

>        pktcMtaDevCmsMaxClockSkew                 Unsigned32,
Ok - done: good catch, fixed.

>    enum, but 'passWithWarnings' (plural) twice in the DESCRIPTION.
Ok - done: passWithWarnings (plural).

>    Also has 'failOtherReason' in the enum but 'failureOtherReason' 
Ok - done: good catch, changed the enum to failureOtherReason.

>    This should be added to the references section of the doc.
It is already referenced in the informative ref section.
[RFCzzz]  Beacham G., Kumar S., Channabasappa S., "Network Control
          Signaling (NCS) Signaling MIB for PacketCable and
          IPCablecom Multimedia Terminal Adapters (MTAs)", RFCzzz, 
          Monthzzz, 2004.

>    Also grammar error "Upper case must be use to"
Ok - done.

>    realm table (pktcMtaDevRealmtable)."
Ok - done.

>     and includes weird characters (as do several other objects).
Ok - done: fixed a number of these weird characters.