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
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn