RE: AD (MIB Dcotor) review of: draft-ietf-ipcdn-bpiplus-mib-11.txt

Thanks Bert, 

You already did extensive comments in this mib in the past months.

As clean (we though) as it becomes you amazingly  find more details. :) 

We will reply shortly with actions.


Eduardo

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email protected]] 
Sent: Tuesday, October 14, 2003 9:16 AM
To: Ipcdn (E-mail)
Subject: [ipcdn] AD (MIB Dcotor) review of:
draft-ietf-ipcdn-bpiplus-mib-11.txt


Did I review this one before? I need to dive into my archives 
to check, but it feels like I did.

Anyway, here is comments based on my first quick check.
I need to look some more into this document, so consider this review
incomplete.

1. When compiling (for SYNTAX checking) with SMICng I get:

   W: f(bpiplus.mi2), (104,22) Revision date not in proper order
      - most recent comes first

2. WHen I compile (syntax check) with smilint I get:

   .\DOCS-IETF-BPI2-MIB:3076: [4] {compliance-group-status} warning:
     current compliance statement `docsBpi2CmtsCompliance' includes
     obsolete group `docsBpi2ObsoleteObjectsGroup'

3. Checking with checkpage.awk I get:

   $ /bin/checkpage.awk < drafts/draft-ietf-ipcdn-bpiplus-mib-11.txt
   Bad chars at 3899
   Bad chars at 3907
   Bad chars at 4189
   -: 3 lines containing non-US-ASCII characters

4. Since this is a very first (formal) publication (as RFC) of this
   MIB module, the tradition (and guideline) is to have one and only
   one REVISION clause. I see that you have instructions to RFC editor
   to remove the extra one. WHy not just remove them now (or move them
   to an appendix to be removed later).

5. In the following, I see that the DESCRIPTION clause is out of sync
   with the actual enumrations ??!!:
       DocsBpkmSAType ::= TEXTUAL-CONVENTION
           STATUS    current
           DESCRIPTION
                "The value of this object is the type of security
           association. The values of the named-numbers are associated
           with the BPKM SA-Type attributes:
           'primary' corresponds to code '0', 'static' to code '1'
           'dynamic' to code '2'.
           'none' value must only be used if the SA type has yet
           to be determined. "
           REFERENCE
                 "DOCSIS Baseline Privacy Plus Interface
           specification, Section 4.2.2.24"
           SYNTAX    INTEGER {
                          none(0),
                          primary(1),
                          static(2),
                          dynamic(3)
                     }
   Or are the "code '0'" different codes at some other place.
   If that is the case, then maybe the ENUMs should sync up with
   those codes. no?

Technical issues/questions
a. I am not sure I understand the relationship between RFC3083 and
   this I-D. Would a device implement both MIB modules?
   - If not, does that mean that this MIB Module obsoletes the MIB
     in 3083? If so it needs to be specified. And if it does obsolte
     3083, then the normal process would be to deprecate/obsolete
     pieces in 3083 that are no longer used and to add new objects
     that are new, but keep the old one. 
     This method does work too... and I think is acceptable as long
     as we do so consciously.
   - If yes, I see a lot of duplication and I wonder if that is
     good, in fact I doubt it.
   In any event, it would be wise to document the relationship between
   these documents better than currently done in the overview section

b. I do not understand why one is Unsigned32 and the other Integer32
       docsBpi2CmTEKSAId   OBJECT-TYPE
            SYNTAX         Unsigned32 (1..16383)

       docsBpi2CmIpMulticastSAId          OBJECT-TYPE
            SYNTAX         Integer32 (0..16383)

       docsBpi2CmtsAuthPrimarySAId   OBJECT-TYPE
            SYNTAX         Integer32 (0..16383)

       docsBpi2CmtsTEKSAId OBJECT-TYPE
            SYNTAX         Unsigned32 (1..16383)

       docsBpi2CmtsIpMulticastSAId        OBJECT-TYPE
            SYNTAX         Integer32 (0..16383)

       docsBpi2CmtsMulticastAuthSAId OBJECT-TYPE
            SYNTAX         Unsigned32 (1..16383)

   Oh well, a couple of TCs seems justified too, maybe a
   DocsSAId and a DocsSAIdOrNone (or DocsSAIdOrZero) TC

c.

Administrative comments and NITs:
- Why is there a reference to RFC2819?
- Since you import from docsIfMib (RFC2670), you must have
  a normative reference to RFC2670
- Since you import from IF-MIB, you must have a normative
  reference to RFC2863
- I see no citations to RFC3414 and RFC3415, neither do I
  see any IMPORTS from those RFCs. So I do not see why they
  are in the references section at all, let alone in the
  normative references section

- In section 2, I recommend to use "MIB module" instead of "MIB"
  It occures several times. This to recognize that there is 
  only one (single) MIB that is composed of mul;tiple MIB modules.

-        docsBpi2ObsoleteObjectsGroup  OBJECT-GROUP
  Pls add to DESCRIPTION why this is/was obsoleted.

- Your MODULE-COMPLIANCE says that an implementation is only
  required to support IPv4. You may want to add to the DESCRIPTION 
  clause(s) why only IPv4 (or why not IPv6) needs to be supported.

Thanks,
Bert 

_______________________________________________
IPCDN mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipcdn