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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 14 Oct 2003 17:16:04 +0200

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

---

From: "Eduardo Cardona" <[email-masked]>
Date: Tue, 14 Oct 2003 10:29:47 -0600

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-masked]] 
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

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

c.

Thanks,
Bert

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 16 Oct 2003 15:51:14 -0600

Hi Eduardo,
Thank you for the response. 

While we are at it, can we take care of the following nits:
 - 1 editorial comment received during WGLC:
   http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/msg00843.html
   (see Stu's comments. Re: revision, let's remove all the older revisions per AD review.)

 - some normative references are out of date
   Please consider the following changes:
   :s/SP-RFIv1.1-I07-010829/SP-RFIv1.1-I10-030730 & date
   :s/SP-BPI+-I09-020830/SP-BPI+_I10-030730 & date
   :s/SP-BPI-I03-010829/"ANSI/SCTE 22-2 2002" & date
    and update reference & link to ANSI or SCTE site:
    http://www.scte.org/documents/pdf/ANSISCTE2222002DSS0203.pdf
   etc. (please cross check all the refs)

Thanks,
Jean-François

> From: Eduardo Cardona 
> Sent: Tuesday, October 14, 2003 10:30 AM
> To: Wijnen, Bert (Bert); Ipcdn (E-mail)
> Subject: RE: [ipcdn] AD (MIB Dcotor) review of:

---

From: "Eduardo Cardona" <[email-masked]>
Date: Fri, 24 Oct 2003 07:06:16 -0600

Thanks again for all the comments 

Summary of actions for new draft

1. Agree, fixed

Will remove docsBpi2ObsoleteObjectsGroup from CMTS compliance module as
GROUP clause
Rename GROUP-OBJECT  docsBpi2ObsoleteObjectsGroup as
docsBpi2CmtsObsoleteObjectsGroup

3. Agree done

4. Agree done,

5. Agree done

   - If not,  
   Yes and No. Specs and MIBS are for capability compliances
   BPI + is an enhancement of the BPI protocol, but BPI+ became a
different protocol.

   Will propose to add a section in Overview (MIB Module Implementation)

   to point to the specs references)

Something among:  

   BPI compliant devices support rfc 3083 (CM/CMTS)
   BPI+ compliant devices support BPIPlus MIB BPI+, CM/CMTS.  
        Particularly, the CM, if instructed (configured) to 
        fall back to DOCSIS "1.0 mode" will support BPI compliant
<<<
   - If yes, I see a lot of duplication and I wonder if that is
     good, in fact I doubt it.

IT does not seems to be good for the duplication as yoou pointed 
but the added objects ( 50+) in BPI+ look "very disorganized" if you add

all of them at the end of the respective tables, specially where peer
objects 
are at initial tables OIDs 

The bottom line, consider BPI and BPI + as different protocols, then
independent MIBS are needed
Two cases as examples  
BPI has only one Auth key, so Param1 of Auth key, now should (?) match
OLD Auth key BPI+; 
NEW Auth Key is exclusive of BPI+

Some parameters ranges ( protocol FSM fninite state machine) were
extended out of the original range
which would imply objects deprecation 
An operator would have many capable 1.1/2.0 CMs but still manage them as
1.0 configured network in other words, CM operating as 1.0 modems with a
1.0 management system. It will imply support both MIBS simultaneously
for management and only one operational mode

Similar case as will happen with Ipv4/v6 transitions, IpForward MIB, 
a vendor new box support v4/v6 dual stack but the box can also be
configured to support only IPv4 stack
Operator has legacy ipv4 boxes managemnt system but not IPv6
deployments.

What mib is going an operator to use? IMO, will use old Ipv4 Ipforward  
Same case are DOCSIS transitions, the mib selection is a device
specification requirements, based on operator requests, RFPs, etc. ( in
this case MSO by CL standards).

I would agree that a whole grain of Compliance statements would be good,
but all those details are in the DOCSIS specs, The section I will add
will show all this references : here is a draft....

2.2 MIB Module implementation

This section describe the overall implementation framework of BPI+ MIB
module to clarify the relation with BPI MIB [RFC3083].
BPI/BPI+ MIB requirements depends both on the device specification
compliance and additionally for CM, of its DOCSIS operational mode when
connected to a partcular CMTS type

2.2.1 DOCSIS Specification Compliance Classification
DOCSIS currently defines three kinds of interoperable specification
compliance devices based on the DOCSIS RFI specifications:
DOCSIS 1.0 CM/CMTS defined in [3]
DOCSIS 1.1 CM/CMTS defined in [4]
DOCSIS 2.0 CM/CMTS defined in [5]

2.2.2 DOCSIS Operational Modes

DOCSIS operational mode refers to the CM specification compliance set of
functionalities and the interoperability requirements to connect to a
specific CMTS type (2.0, 1.1, 1.0). In general this document calls
DOCSIS 1.1 mode a configuration where a DOCSIS 2.0/1.1 CM can
interoperate with a 1.1 CMTS; in the same way, a DOCSIS 1.0 mode is a
configuration where a DOCSIS 2.0/1.1/1.0 CM can interoperate with a 1.0
CMTS. In the CMTS side a 2.0 CMTS can support simultaneously CMs
configured in either DOCSIS 2.0, 1.1 or 1.0 mode. For the scope of the
BPI+ requirements DOCSIS 2.0 mode is equivalent to DOCSIS 1.1 mode (*)

2.2.3 BPI/BPI+ MIB implementation: 

Based on CM perational modes and CM/CMTS specification compliances below
is a summary of Baseline Privacy Interface MIB  modules requirements
(BPI and BPI+)
1. DOCSIS 1.0 CM/CMTS only implements BPI MIB per [6], 
2. DOCSIS 2.0 and 1.1 CMTS only implements BPI+ MIB per [8] 
   and[7] respectively
3. DOCSIS 2.0 and 1 1 CM in DOCSIS 1.0 mode implements BPI MIB 
   plus the BPI+ MIB objects associated with Authentication of 
   Downloaded Images
4. DOCSIS 2.0 and 1.1 CM in DOCSIS 1.1 mode (*) implements only 
   BPI+ MIB
5. DOCSIS 2.0 and 1.1 CM BPI MIB requirements are in [8] and [7] 
   respectively

<<<

Before the above list (integer32 vs Unsigned32) all were integer32

A previous discussion and revision recommended for indexes to use
Unsigned32 

------------------------
> -       docsBpi2CmIpMulticastIndex         OBJECT-TYPE
>            SYNTAX         Integer32 (1..1000)
>    It is valid. But for INDEX objects we prefer Unsigned32 with
>    a range. see again the mib review guidelines doc
>    I think this occurs a few more time in this MIB module.
>    As I say, it is valid, but since your still working on this
>    MIB module, might as well use the recommended method.
 -> certainly. fixed all integer32 INDEX objects syntax to Unsigned32.
  This includes the following objects:
  docsBpi2CmTEKSAId
  docsBpi2CmIpMulticastIndex
  docsBpi2CmCryptoSuiteIndex
  docsBpi2CmtsTEKSAId
  docsBpi2CmtsIpMulticastIndex
  docsBpi2CmtsMulticastAuthSAId
  docsBpi2CmtsCACertIndex
--------------------------

The change in indexes does not interfere with the wire compatibility of
already implemented systems,
The changes in the columnar values will..
 
The two Textual conventions can be used  ( will try to get those on time
today)

1..16383 Unsinged are all index
0..16383 are columnar values 
optimally SAIds are in range 0 (unknown) 1 to 16383
range 1 to 16383 is needed for Indexing tables ( only known SAIds can
create entries)
Which is all consistent

DocsSAId and 
DocsSAIdOrZero (maybe)

<<<<
	>>> Agree , should be RFC 2021 RMON2-MIB; done

      >>> Agree, done

      >>> Agree, done

      >>> Agree, done

      >>> Agree, done (~ 5 places ?)

   >>> will do, proposed text below: 

Before was : docsBpi2ObsoleteObjectsGroup

   docsBpi2CmtsObsoleteObjectsGroup  OBJECT-GROUP
        OBJECTS {
             docsBpi2CmtsAuthCmGraceTime,
             docsBpi2CmtsTEKGraceTime
             }
        STATUS         obsolete
        DESCRIPTION
             "This is a collection of obsolete CMTS BPI+ objects.
        The MIB objects in this group were conceived in early 
        draft versions of this document, and kept to maintain a
        continuous and uniform OID structure with pre-RFC field
        implementations.
        Particularly, the objects reports Grace Time timeouts; a 
        CMTS does not require knowledge of those Security 
        associations parameters, which are sole CM responsibility."
   ::= { docsBpi2Groups 4 }

<<<

   will add (borrow from MTA MIB; )
 
                   " Support for address types other than 'ipv4(1)'  
                     is not presently specified and therefore, is not  
                     required. It may be defined in future versions of  
                     this MIB module." 

<<<

Thanks

Eduardo

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Tuesday, October 14, 2003 9:16 AM
To: Ipcdn (E-mail)
Subject: [ipcdn] AD (MIB Dcotor) review of:

c.

Thanks,
Bert

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 24 Oct 2003 16:13:57 -0600

Eduardo,

A quick comment regarding the relationship between the BPI+ and BPI MIB modules. 
If you decide to add some informative text to explain it, I would recommend keeping it short and only stating the compliance in terms of DOCSIS 1.0/1.1/2.0, see more below. The considerations on operational modes - even though it is valuable information - are outside any implementation consideration for this MIB and they are a given due to the fact that a 2.0 CM can run in 1.0 mode and this depends on operator config & CMTS.

Refer to appendix C of the BPI+ specification (a normative ref) for more details on interop between bpi and bpi+.

You wrote:
... snipped
> 2.2 MIB Module implementation
How about a single section called "Relationship between BPI+ and BPI MIBs"

> This section describe the overall implementation framework of 
> BPI+ MIB module to clarify the relation with BPI MIB 
> [RFC3083]. BPI/BPI+ MIB requirements depends both on the 
> device specification compliance and additionally for CM, of 
> its DOCSIS operational mode when connected to a partcular CMTS type
The pb I have with this sentence is that the actual CM requirements (what a CM must implement) do not depend on the operational mode. 
> DOCSIS currently defines three kinds of interoperable 
> specification compliance devices based on the DOCSIS RFI 
> specifications: DOCSIS 1.0 CM/CMTS defined in [3] DOCSIS 1.1 
> CM/CMTS defined in [4] DOCSIS 2.0 CM/CMTS defined in [5]
> 
> DOCSIS operational mode refers to the CM specification 
> compliance set of functionalities and the interoperability 
> requirements to connect to a specific CMTS type (2.0, 1.1, 
> 1.0). In general this document calls DOCSIS 1.1 mode a 
> configuration where a DOCSIS 2.0/1.1 CM can interoperate with 
> a 1.1 CMTS; in the same way, a DOCSIS 1.0 mode is a 
> configuration where a DOCSIS 2.0/1.1/1.0 CM can interoperate 
> with a 1.0 CMTS. In the CMTS side a 2.0 CMTS can support 
> simultaneously CMs configured in either DOCSIS 2.0, 1.1 or 
> 1.0 mode. For the scope of the

The section below is very confusing and I strongly recommend to reference the BPI+ spec without trying to put too much details in the MIB. MIB implementers will have to read the spec (hopefully ;).
> 
> Based on CM perational modes and CM/CMTS specification 
> compliances below is a summary of Baseline Privacy Interface 
> MIB  modules requirements (BPI and BPI+) 1. DOCSIS 1.0 
> CM/CMTS only implements BPI MIB per [6], 

> 5. DOCSIS 2.0 and 1.1 CM BPI MIB requirements are in [8] and [7] 

How about something like this:
------------
2.2 Relationship between BPI+ and BPI MIBs
This section describes the relationship between the BPI+ MIB module defined in this document and the BPI MIB module defined in RFC 3083 [RFC3083]. The BPI+ protocol interface is an enhancement to the BPI protocol and it is a distinct protocol from BPI. The associated BPI+ managed objects should be considered separate from the BPI MIB objects defined in RFC 3083.

DOCSIS 1.1 and 2.0 systems must implement the BPI+ specification. For more information regarding the interoperability between BPI and BPI+ systems, refer to appendix C of the BPI+ specification [xxx].
------------

Jean-François

---

From: "Eduardo Cardona" <[email-masked]>
Date: Fri, 24 Oct 2003 19:18:52 -0600

Thanks Jean-Francois, 

I Agree the vendors read all specs RFI, BPI, OSSI to implement the protocols and BPI MIBs 
I will use your proposed wording with some sligth variations. 
Some additional comments below the  --- section ---

-----------------------------
To your suggestion:
- Remove the must statements to make that informational and refer to the specs
- Because the title BPI+ vs BPI MIBs, your text does not really refers to 
  BPI MIBs relationships just BPI specs (?), 
    - Also the reference to RFC 3083 in Appendix F of BPI+ spec 
      is not cited in the spec text (our fault), so, BPI+ spec does not reference 
      to BPI MIB (CM requirements) when OSSI does, so I added a couple of 
      references in your text to close the loop.

Please suggest any changes you would like

Proposed text:

DOCSIS 1.1 and 2.0 systems implement both BPI+ and BPI protocols to be backward compatible with 1.0 systems. For more information regarding the interoperability between BPI and BPI+ systems, refer to appendix C of [1] and for MIB modules requirements, refers to section 4.6.1, Figure 9 of [3] and 7.6.1, Table 7-9  of [4]

------------------------------

More notes:
The operational mode (config file) defines the BPI protocol to support, as an example a 1.1/2.0 CM support both BPI and BPI+ protocols and because a 1.1/2.0 CM in a 1.0 CMTS, the CMTS only knows BPI and won't understand BPI+ capabilities in the REG-REQ message.

The initial proposed text is the complete matrix of combinations for mib implementation, and I agree that a reader will have a terrible headacke reading that, with no more options that going to the specs.

The problem is summarized as :

Graphically is more digestable 
Indeed mode of operation (

config file for (1.0 operational mode style)   1.1 and 2.0 CM will load all BPI MIB and ( SSD of BPI+ )
Config file for (1.1 operational mode style)   1.1 and 2.0 CM will load all BPI+ only

*SSD (secure Software Download only for 1.1/2.0 systems) is not really part of the BPI+ protocol, but it is a security feature of DOCSIS, which is the only security spec available in DOCSIS, then SSD was incorporated to BPI+ spec and MIBs.

see OSSIv1.1 
http://www.cablemodem.com/downloads/specs/SP-OSSIv1.1-I07-030730.pdf

4.6.1 Coexistence and MIBs 
Figure 9. CM DOCSIS Mode and MIBs Requirement

Or in OSSIv2.0 spec 
http://www.cablemodem.com/downloads/specs/SP-OSSIv2.0-I04-030730.pdf
Section 7.6.1 Coexistence and MIBs
Table 7-9 DOCSIS 2.0 CM Modes and MIB Requirements

-----Original Message-----
From: Jean-Francois Mule 
Sent: Friday, October 24, 2003 4:14 PM
To: Eduardo Cardona; Wijnen, Bert (Bert); Ipcdn (E-mail)
Subject: RE: [ipcdn] AD (MIB Dcotor) review of: draft-ietf-ipcdn-bpiplus-mib-11.txt

Eduardo,

You wrote:
... snipped

Jean-François

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 24 Oct 2003 21:21:01 -0600

Eduardo wrote:
> This section describes the relationship between the BPI+ MIB 
> module defined in this document and the BPI MIB module 
> defined in RFC 3083 [RFC3083]. The BPI+ protocol interface is 
> an enhancement to the BPI protocol and it is a distinct 
> protocol from BPI. The associated BPI+ managed objects should 
> be considered separate from the BPI MIB objects defined in RFC 3083.
> 
> DOCSIS 1.1 and 2.0 systems implement both BPI+ and BPI 
> protocols to be backward compatible with 1.0 systems. For 
> more information regarding the interoperability between BPI 
> and BPI+ systems, refer to appendix C of [1] and for MIB 
> modules requirements, refers to section 4.6.1, Figure 9 of 
> [3] and 7.6.1, Table 7-9  of [4]

Looks good to me.
Jean-François