Subject: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on docsBpi2CmtsAuthCmBpiVersion

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 23 Jul 2003 12:15:09 -0600

Eduardo,
The proposed resolution on docsBpi2CmtsAuthCmBpiVersion looks good to
me. Any other comments on this one?
In short, you propose to not change the enum list and start with 0 and
to add some explanatory text to justify it.

To get closure on docsBpi2CmtsAuthCmBpiVersion, minor nits (mostly add
reference to BPI spec in ref clause since value 0 is not defined in
bpi+.

        docsBpi2CmtsAuthCmBpiVersion  OBJECT-TYPE 
            SYNTAX         INTEGER { 
                         bpi (0), 
                         bpiPlus (1) 
                             } 
            MAX-ACCESS     read-only 
            STATUS         current 
            DESCRIPTION 
                 "The value of this object is the version of Baseline 
                 Privacy for which this CM has registered. The value 
                 'bpiplus' represents the value of BPI-Version Attribute
of 
                 the Baseline Privacy Key Management BPKM attribute 
                 BPI-Version (1). The value 'bpi' is used to represent
the 
                 CM registerered using DOCSIS 1.0 Baseline Privacy."
             REFERENCE 
                 "DOCSIS Baseline Privacy Plus Interface Specification, 
                 Section 4.2.2.22; DOCSIS Baseline Privacy Interface
                 Specification" 
            ::= { docsBpi2CmtsAuthEntry 2 } 

Jean-Francois.
Ps: note the email address change for Kaz (Kazuyoshi.Ozawa --AT--
toshiba.co.jp)

-----Original Message-----
From: Eduardo Cardona 
Sent: Tuesday, July 22, 2003 11:30 AM
To: Jean-Francois Mule; Wijnen, Bert (Bert); Ipcdn (E-mail)
Cc: [email-masked]; Alexander Katsnelson; [email-masked]
Subject: RE: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10

Jean Francois, 

Thanks for the sumarized details of actions, 

Here are comments and proposals for the open questions. for the MIB
authors and ipcdn group consideration.

feel free to make comments and suggestions.

Eduardo
> -     docsBpi2CmtsAuthCmBpiVersion  OBJECT-TYPE 
>            SYNTAX         INTEGER { 
>                         bpi (0), 
>                         bpiPlus (1) 
>                               } 
>    Any special reason why enumeration cannot start at 1? 
      to be discussed in docsis team. 
docsBpi2CmtsAuthTable is a CMTS table that list the CM Authorization
Association with respect to BPI+
- RFC 3083 have a similar table docsBpiCmtsAuthTable
docsBpi2CmtsAuthCmBpiVersion was added in Bpi2 mib and is not present in
Bpi mib, It reflects a new BPI+ parameters in the BPKM ( code 22)
BPI-Version:
BPI (RFC 3083) covers {0, 17-126} reserved, {127,128-255} vendor, {1-16}
BPI defined
BPI+ (bpiplus draft) covers {0, 28-126} reserved, {127,128-255} vendor,
{1-27} BPI defined
the new bpi defined parameters by bpiplus 17-27) includes :
Code 22 BPI-Version in 4.2.2.22 BPI-Version of SP-BPI+-I09-020830
defined values are :
0, Reserved
1 BPI+ 
2-255 Reserved
The mib assigns 0 to bpi , 1 to bpiplus and reserved numbers 2-255 for
future protocols denominations

---Suggested Text

        docsBpi2CmtsAuthCmBpiVersion  OBJECT-TYPE 
            SYNTAX         INTEGER { 
                         bpi (0), 
                         bpiPlus (1) 
                             } 
            MAX-ACCESS     read-only 
            STATUS         current 
            DESCRIPTION 
                 "The value of this object is the version of Baseline 
                 Privacy for which this CM has registered. The Value 
                 'bpiplus' represents the value of BPI-Version Attribute
of 
                 the Baseline Privacy Key Management BPKM attribute 
                 BPI-Version (1). Value 'bpi' is used to represent the
CM 
                 registerered using DOCSIS 1.0 Baseline Privacy."
             REFERENCE 
                 "DOCSIS Baseline Privacy Plus Interface Specification, 
                 Section 4.2.2.22" 
 
            ::= { docsBpi2CmtsAuthEntry 2 } 

--------------------------------------
>      Any special reason to start ENUMERATION with zero ?? 
> -       docsBpi2CmtsTEKSAType    OBJECT-TYPE 
>            SYNTAX         INTEGER { 
>                                   none(0), 
>                                   primary(1), 
>                                   static(2), 
>                                   dynamic(3) 
>                                   } 
>      Any special reason to start ENUMERATION with zero ?? 
  -> to be addressed in docsis team 
>      There are more of those... I won;t list them anymore, 
>      I guess you get the gist. 
docsBpi2CmTEKDataEncryptAlg
docsBpi2CmTEKDataAuthentAlg 
Already fixed since draft 9
I believe the mib author decided to align the structure of enumerations
for the objects in the table docsBpi2CmTEKTable 
docsBpi2CmTEKSAType 
docsBpi2CmTEKDataEncryptAlg
docsBpi2CmTEKDataAuthentAlg 
the BPKM Attribute 24 SA-Type does start in zero, but the defined
enumeration in the mib does not follow exactly those values.

docsBpi2CmTEKSAType : none(0) primary(1) static(2) dynamic(3)
    BPKM attribute 24
             SA-Type: 0 primary, 1 static, 2 Dynamic. 3-127 Reserved,
128-255 Vendor-Specific  (***)
             -- Ideal MIB enumeration primary(0), static(1), Dynamic(2) 
docsBpi2CmTEKDataEncryptAlg: none(0) des56CbcMode(1) des40CbcMode(2)
   BPKM Attribute 20
Cryptographic-suite: 
Data Authentication Algorithm Identifiers
                           0 Reserved, 1 CBC-Mode, 2 CBC-Mode, 3-255
Reserved
docsBpi2CmTEKDataAuthentAlg: none(0)
   BPKM Attribute 20
Cryptographic-suite: 
Data Authentic ation Algorithm Identifiers
                            0 No Data Authentication, 1-255 Reserved

A truly consistent enumeration for docsBpi2CmTEKSAType against the
protocol would be primary(0), static(1), Dynamic(2), none(3)
At the level protocol no 'none' attribute is send on the wire, 
it means BPKM messages are have not yet sent to determine the SA type

docsBpi2CmTEKSAType OBJECT-TYPE 
    ..............
      DESCRIPTION 
                 "The value of this object is the type of security 
            association.  The none(0) encoding must only be used 
            if the SA type has yet to be determined." 
In conclusion the enumeration 0 would be valid to match the protocol
requirements (see ***) ( known value from the BPKM protocol) , but the
change in the enumeration is desirable to happen to have the same
enumeration structure in docsBpi2CmTEKTable as well as keeping the
definition compatible with the broad number of devices in the field.
Proposed text (updated reference)
docsBpi2CmTEKSAType OBJECT-TYPE 
            SYNTAX         INTEGER { 
                                   none(0), 
                                   primary(1), 
                                   static(2), 
                                   dynamic(3) 
                                   } 
            MAX-ACCESS     read-only 
            STATUS         current 
            DESCRIPTION 
                 "The value of this object is the type of security 
                 association.  The none(0) encoding must only be used 
                 if the SA type has yet to be determined. Values 
                 'primary', 'static' and 'dynamic are defined in the 
                 SA-Type Attribute of the Baseline Privacy Key 
                 Management BPKM as (0), (1), (2) respectively." 
            REFERENCE 
                 "DOCSIS Baseline Privacy Plus Interface Specification, 
                 Section 4.2.2.24" 
            ::= { docsBpi2CmTEKEntry 2 } 

--------------------------------------------
> -       docsBpi2CmtsAuthBpkmCmCertValid         OBJECT-TYPE 
>            SYNTAX    INTEGER { 
>                              unknown (0), 
>                              validCmChained (1), 
>                              validCmTrusted (2), 
>                              invalidCmUntrusted (3), 
>                              invalidCAUntrusted (4), 
>                              invalidCmOther (5), 
>                              invalidCAOther (6) 
>                     } 
The docsBpi2CmtsAuthBpkmCmCertValid value is assigned by the CMTS to
indicate validity of the CM certificates path or chain provisioned or
aquired via BPKM.

The same rationale as in some BPI mibs like docsBpi2CmtsAuthCmBpiVersion
enumeration 0, 'unknown' value is used to represent the case when the CM
is running in  bpi not bpiplus
NOt a straigth match but the BPKM attibutes in bpiplus intentionaly
reserves the value zero and in bpi mode no bpiplus attibutes are not
sent in the wire. so believe  the mib is using the enmeration 0 to
reflect the bpi mode of operation without conflicting with the bpiplis
attributes values (almost all time SA-Type still has to me dark areas)

The DESCRIPTION also mention the reason of  'unknown' value for (bpi)
where certificates are not used, 
That allows to use in the future other enumerations above 6 for detailed
CM Certificates validity status. 

docsBpi2CmtsAuthBpkmCmCertValid 
....
I do not see any Protocol codes association (in BPI+ 9.4.1 CMTS
Certificate Management Model) replied to the CM that matches any
Certificate validation. BPI experts may provide a more clean
explanation.

Therefore I do not think a mib change is needed if for IETF Mib Doctors
using enumeration 0 is valid for bpiplus mibs reporting devices in bpi
mode. 
Any suggestions to make that more clear? 

> - I wonder if it would not be better to have 2 compliance 
>   statements, one for CM and one for CMTS. 
>   It is unclear to me if any GROUPS are mandatory. I think 
>   some are, but it depends if your are CM or CMTS 
  -> to be addressed in docsis team 

There is not unconditionally groups (e.e base group applying both CM and
CMTSes)
The tree groups are  

docsBpi2CmtsGroup  CMTS only
docsBpi2CmGroup    CM only
docsBpi2CodeDownloadGroup CM and optional CMTS

Maybe a way to indicates the MANDATORY requirements would be:

Proposed changes: replace 'implemented' with required

   -- conditionally mandatory group 
       GROUP     docsBpi2CmGroup 
            DESCRIPTION 
            "This group is required only in CMs, not in CMTSs." 
     
       -- conditionally mandatory group 
       GROUP     docsBpi2CmtsGroup 
            DESCRIPTION 
            "This group is required only in CMTSs, not in CMs." 
     
       -- conditionally mandatory group 
       GROUP     docsBpi2CodeDownloadGroup 
            DESCRIPTION 
            "This group is required in CMs and is optional in CMTSs." 

-----Original Message-----
From: Jean-Francois Mule 
Sent: Thursday, July 17, 2003 2:37 PM
To: Wijnen, Bert (Bert); Ipcdn (E-mail)
Cc: [email-masked]; Alexander Katsnelson; [email-masked]
Subject: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10

Bert & all, 
Below are the details on what comments got addresed in
draft-ietf-ipcdn-bpiplus-mib-10 based on your review. 
Jean-Francois. 
> -----Original Message----- 
> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Thursday, February 13, 2003 8:13 AM 
> To: Ipcdn (E-mail) 
> Cc: [email-masked]; Alexander Katsnelson; [email-masked] 
> Subject: [ipcdn] Review of: draft-ietf-ipcdn-bpiplus-mib-08.txt 
> 
> 
> Here are my comments: 
> 
> - references/citations in abstract are not allowed per 
>   RFC-Editor policy 
  -> deleted refs. 
> - 2nd para in abstract seems not needed. but I can live 
>   with it 
  ->   deleted. 
> - Tiltle of sect 1 is not inline with MIB boilerplate 
  ->   fixed. 
> - 3rd para in section 1 is not needed, in fact I'd rather 
>   see it removed. The RFC3410 explains all that. 
  ->   fixed. 
> - DESCRIPTION clause of MODULE-IDENTITY is missing the 
>   MIB copyright statement 
  ->   added the following text: 
              Copyright (C) The Internet Society (2003). This version 
              of this MIB module is part of RFC xxx; see the RFC 
              itself for full legal notices." 
> - I had asked in in earlier email: 
>   Mmm.. did I review rev 07. I can't quickly find that I 
>   did send a review report. 
>   I am assuming that you will take care of all the comments 
>   that are (in my view) to be expected based on the review 
>   of the subscriber mib I did, right? 
  -> yes. will review and double check draft10. 
> - Is this MIB obsoleteing an earlier (RFC) version? 
  ->   no. BPI mib and BPI plus coexist together. 
>   If this is the first time this MIB gets publsihed as an 
>   RFC, then we want to see only one simple revisions clause 
>   with a DESCRIPTION aka: 
>      "Initial version, published as RFC xxxx." 
>      -- RFC-editor assigns xxxx 
  ->   fixed. 
>   We do not want to see long lists of changes that happened 
>   during initial revisions of Internet Drafts 
  ->   ok. Left all the revisions in there for now with comments to be 
  deleted when doing final rfc editing. Did not get removed in draft10 
  yet, will be done later. 
> - And how did you decide to assign the 
>   docsBpi2MIB MODULE-IDENTITY 
>      ... 
>      ::= { docsIfMib 6 } 
>   I worry a lot about this practice, cause it is very difficult 
>   to keep track and to ensure that no conflicts arise. 
  ->   fixed by replacing this by 
            ::= { mib-2 xx }   -- xx to be assigned by IANA 
> - I worry about: 
>       X509Certificate ::= TEXTUAL-CONVENTION 
>            STATUS    current 
>            DESCRIPTION 
>                "An X509 digital certificate encoded as an ASN.1 DER 
>            object." 
>            SYNTAX    OCTET STRING (SIZE (0..1400)) 
>    The reason is that this is not some X509 generic Certificate 
>    but a special one for your IPCDN use. 
>    How about renaming it to DocsX509ASN1DEREncodedCertificate ?? 
  ->   good point. Changed to the suggested TC name everywhere. 

> -       docsBpi2CmAuthReset OBJECT-TYPE 
>    Would it be wise to add a docsBpi2CmAuthLastReset object 
>    similar as what was done in the subscriber MIB module? 
  -> per our interim meeting in Feb'03, the new last reset object 
  will  not 
  be added because this reset is really only for testing purposes. 
  Changed docsBpi2CmAuthReset description has been updated to add 
        This object is for testing purposes only and therefore it 
        does not require to be associated with a last reset object." 

> - objects like: 
>       docsBpi2CmAuthRejects    OBJECT-TYPE 
>            SYNTAX         Counter32 
>            MAX-ACCESS     read-only 
>            STATUS         current 
>            DESCRIPTION 
>                 "The value of this object is the count of times the CM

>            has received an Authorization Reject message, 
> since reboot." 
>   require that a Counter starts at zero. But those are NOT the 
>   semanticws of a Counter32. If this is what you want, I think you 
>   need to use the ZeroBasedCounter32 as per RFC2021. 
>   Pls read draft-ietf-ops-mib-review-guidelines-00.txt sect 4.6 
>   specifically 4.6.1.2 
>   You have quite a few of those objetcs 
   -> ok. 
   For each Counter32 object that require a start at zero, we 
   will change syntax from Counter32 to ZeroBasedCounter32. 
   Added IMPORT ZeroBasedCounter32 FROM RMON2-MIB. 
> -       docsBpi2CmAuthRejectErrorString    OBJECT-TYPE 
>            SYNTAX         SnmpAdminString (SIZE (0..128)) 
>            MAX-ACCESS     read-only 
>            STATUS         current 
>            DESCRIPTION 
>                 "The value of this object is the Display-String in 
>    S/Display-String/text string/ ?? 
>    Same for docsBpi2CmAuthInvalidErrorString 
>    And for docsBpi2CmTEKKeyRejectErrorString 
>            docsBpi2CmTEKInvalidErrorString 
>       docsBpi2CmIpMulticastSAMapRejectErrorString 
>     docsBpi2CmtsAuthInvalidErrorString 
  -> done - replaced all 'Display-String' in description clauses by
'text 
  string' 
> -      docsBpi2CmTEKDataEncryptAlg   OBJECT-TYPE 
>           SYNTAX         INTEGER { 
>                                  none(0), 
>                                  des56CbcMode(1), 
>                                  des40CbcMode(2) 
>                                  } 
>    We recommend to start Enumerations from 1. 
>    Possibly the 1 and 2 for the desXxxx enumerations are so numbered 
>    to align with some other place. If so, then starting with zero 
>    seems acceptable. But pls add some explanantion in that case 
  -> ok. fixed. 
  Table 4-22 of bpiplus spec defines the Data Encryption 
  Algorithm Identifiers and values are: 
  0 Reserved 
  1 CBC-Mode, 56-bit DES 
  2 CBC-Mode, 40-bit DES 
  3-255 Reserved 
  so it is proposed to leave object def as-is and add the following 
  justification text: 
  "Values 'des56CbcMode' and 'des40CbcMode' are defined in the 
  interface specification as integer values (1) and (2)." 

>    Same question for simial xxxCrypto object 
  -> ok. fixed. 
> -       docsBpi2CmTEKDataAuthentAlg   OBJECT-TYPE 
>            SYNTAX         INTEGER { 
>                                   none(0) 
>                                   } 
>    An object that can only have one value that is ALWAYS zero? 
>    What is the use of that? Maybe future extensibility, but if so, 
>    then please say so in DESCRIPTION clause, otherwise this 
>    seems nonsense and bloat. 
  -> ok. fixed. Added "This object is defined for future 
  extensibility." 
>    Same question for simial xxxCrypto object 
  -> ok. fixed. same as above. 
> -       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 
> -       docsBpi2CmIpMulticastAddress  OBJECT-TYPE 
>            SYNTAX         InetAddress 
>            MAX-ACCESS     read-only 
>            STATUS         current 
>            DESCRIPTION 
>                 "This object represents the IP multicast address 
>            to be mapped." 
>    you MUST specify with InetAddressType object defines the context 
>    or type of this object. You did it correct in subscriber mib. 
  -> fixed. 
> -       docsBpi2CmtsDefaultSelfSignedManufCertTrust  OBJECT-TYPE 
>            SYNTAX    INTEGER { 
>                      trusted (1), 
>                      untrusted (2) 
>                      } 
>    Seems to me that docsBpi2CmtsDefaultSelfSignedManufCertTrusted 
>    descriptor with a syntax of TruthValue is more appropriate 
> -       docsBpi2CmtsCheckCertValidityPeriods    OBJECT-TYPE 
>            SYNTAX         TruthValue 
>            MAX-ACCESS     read-write 
>            STATUS         current 
>            DESCRIPTION 
>          "Setting this object to TRUE causes all chained and 
>    The better wording is: 
>          "Setting this object to 'true' causes all chained and 
                           ->       ^^^^^ fixed. 
>    This occurs a few more times in this MIB module 
     -> fixed all of them. 

> -     docsBpi2CmtsAuthCmBpiVersion  OBJECT-TYPE 
>            SYNTAX         INTEGER { 
>                         bpi (0), 
>                         bpiPlus (1) 
>                               } 
>    Any special reason why enumeration cannot start at 1? 
      to be discussed in docsis team. 
> -       docsBpi2CmtsAuthCmReset  OBJECT-TYPE 
>    Yet another way in which you guys do resets. 
> -       docsBpi2CmtsAuthCmInfos       OBJECT-TYPE 
>            SYNTAX         Counter32 
>            MAX-ACCESS     read-only 
>            STATUS         current 
>            DESCRIPTION 
>                 "The value of this object is the count of times the 
>            CMTS has received an Authentication Information 
> message from 
>            this CM, since entry creatiion." 
>    ZeroBasedCounter32 ?? 
  -> yes, fixed. 
>    You have several of those 
  -> yes fixed. 
> -       docsBpi2CmtsAuthBpkmCmCertValid         OBJECT-TYPE 
>            SYNTAX    INTEGER { 
>                              unknown (0), 
>                              validCmChained (1), 
>                              validCmTrusted (2), 
>                              invalidCmUntrusted (3), 
>                              invalidCAUntrusted (4), 
>                              invalidCmOther (5), 
>                              invalidCAOther (6) 
>                              } 
>      Any special reason to start ENUMERATION with zero ?? 
> -       docsBpi2CmtsTEKSAType    OBJECT-TYPE 
>            SYNTAX         INTEGER { 
>                                   none(0), 
>                                   primary(1), 
>                                   static(2), 
>                                   dynamic(3) 
>                                   } 
>      Any special reason to start ENUMERATION with zero ?? 
  -> to be addressed in docsis team 
>      There are more of those... I won;t list them anymore, 
>      I guess you get the gist. 
> - I wonder if it would not be better to have 2 compliance 
>   statements, one for CM and one for CMTS. 
>   It is unclear to me if any GROUPS are mandatory. I think 
>   some are, but it depends if your are CM or CMTS 
  -> to be addressed in docsis team 
> -       -- relaxation on IP addressing 
>       OBJECT    docsBpi2CmIpMulticastAddressType 
>              -- SYNTAX InetAddressType { ipv4(1) } 
>    Pls make it a real SYNTAX clause and not a comment. 
>    That SMICng barks at it is something we know and SMICng 
>    should be fixed. 
  -> fixed. 

> - You have citations in DESCRIPTION clauses. We normally do not 
>   do that, cause they will be lost when people extract the 
>   MIB module from the RFC. 
 -> ok. fixed. 
> - Mmm.. you start off with some OBSOLETED object group right 
>   away he? You might want to say something about when/why that 
>   happened. 
> - References need to be split in normative and informative 
 -> ok. fixed. 
> - You have picked up the new MIB boilerplate, but you still 
>   have a lot of old MIB boilerplate references included, which 
>   make no sense anymore 
 -> ok. cleaned as much as possible. 
> - The new MIB boilerplate has [RFC2578], [RFC2579] and [RFC2580] 
>   as citations, but they do not show as such in the references 
>   section 
 -> ok. fixed. 
> - The security considerations section is not compliant with the 
>   new MIB security guidelines. The subscriber MIB has 
>   done a much better job. You should too. 
 -> ok, beefed up the security consideration section. 

> - I see 3 names in CONTACT-INFO while only two are listed 
>   on front page and only two are listed in Author's addresses? 
 -> The 2 co-authors of draft 08 agree to add Kaz Ozawa as 
    part of the author list. 
    Contact info for Kaz corrected. 
Minor additional nits: 
 - Enforced (mostly) the 72 character column limit in Word, and fixing 
   the wrapped text (many many changes). 
 - Removed some non-ASCII text, especially "special" quotation marks 
 - Removed IMPORT of Gauge32, since it is not used 
 - Removed the REFERENCE clauses from the OBJECT compliance 
   statements, since they are not permitted per the following syntax 
   from page 6 of RFC 2580. 

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

---

From: "Eduardo Cardona" <[email-masked]>
Date: Wed, 23 Jul 2003 17:27:53 -0600

Jean-Francois, 

That will be:
       docsBpi2CmtsAuthCmBpiVersion  OBJECT-TYPE 
            SYNTAX         INTEGER { 
                         bpi (0), 
                         bpiPlus (1) 
                             } 
            MAX-ACCESS     read-only 
            STATUS         current 
            DESCRIPTION 
                 "The value of this object is the version of Baseline 
                 Privacy for which this CM has registered. The value 
                 'bpiplus' represents the value of BPI-Version Attribute
of 
                 the Baseline Privacy Key Management BPKM attribute 
                 BPI-Version (1). The value 'bpi' is used to represent
the 
                 CM registerered using DOCSIS 1.0 Baseline Privacy."
             REFERENCE 
                 "DOCSIS Baseline Privacy Plus Interface Specification, 
                 Section 4.2.2.22; ANSI/SCTE 22-2 2002(formerly DSS
02-03) 
                 Data-Over-Cable Service Interface Specification DOCSIS
1.0
                 Baseline Privacy Interface (BPI)"
            ::= { docsBpi2CmtsAuthEntry 2 } 

About Bert Comments: 

Please make the required comments.

Below is a proposed two compliance modules 
I changed relaxation for constrains
Removed commenst in SYNTAX clauses 
Compliances modules Basic keyword removed, expanded to Cm or CMTS

       docsBpi2CmCompliance MODULE-COMPLIANCE 
            STATUS         current 
            DESCRIPTION 
                 "This is the compliance statement for CMs which 
                 implement the DOCSIS Baseline Privacy Interface Plus." 
     
            MODULE  -- docsBpi2MIB 
     
       -- unconditionally mandatory group
       MANDATORY-GROUPS {
              docsBpi2CmGroup,
              docsBpi2CodeDownloadGroup
       }

       GROUP     docsBpi2CmGroup 
            DESCRIPTION 
            "This group implementation is required for CMs only." 
     
       GROUP     docsBpi2CodeDownloadGroup 
            DESCRIPTION 
            "This group implementation is required for CMs." 
  
       -- constrains on IP addressing 
       OBJECT    docsBpi2CmIpMulticastAddressType 
              -- SYNTAX InetAddressType { ipv4(1) } 
              DESCRIPTION 
              "An implementation is only required to support IPv4 
               addresses." 
     
       -- constrains on IP addressing 
       OBJECT    docsBpi2CmIpMulticastAddress 
              SYNTAX  InetAddress (SIZE(4)) 
              DESCRIPTION 
              "An implementation is only required to support IPv4 
               addresses." 
  
       ::= { docsBpi2Compliances 1 } 

       docsBpi2CmtsCompliance MODULE-COMPLIANCE 
            STATUS         current 
            DESCRIPTION 
                 "This is the compliance statement for CMTSs which 
                 implement the DOCSIS Baseline Privacy Interface Plus." 
     
            MODULE  -- docsBpi2MIB 
       -- unconditionally mandatory group
       MANDATORY-GROUPS {
              docsBpi2CmtsGroup
       }

       GROUP     docsBpi2CmtsGroup 
            DESCRIPTION 
            "This group implementation is required for CMTSs only." 
     
       -- Optional group 
       GROUP     docsBpi2CodeDownloadGroup 
            DESCRIPTION 
            "This group is optional for CMTSs." 

       -- constrains on Object range 
       OBJECT    docsBpi2CmtsDefaultAuthLifetime 
            SYNTAX    Integer32 (86400..6048000) 
            DESCRIPTION 
            "The refined range corresponds to the minimum and maximum 
             values in operational networks." 
     
       -- constrains on mandatory range 
       OBJECT    docsBpi2CmtsDefaultTEKLifetime 
            SYNTAX    Integer32 (1800..604800) 
            DESCRIPTION 
            "The refined range corresponds to the minimum and maximum 
            values in operational networks." 
     
       -- constrains on mandatory range 
       OBJECT    docsBpi2CmtsAuthCmLifetime 
            SYNTAX    Integer32 (86400..6048000) 
            DESCRIPTION 
            "The refined range corresponds to the minimum and maximum 
            values in operational networks." 
     
       -- constrains on mandatory range 
       OBJECT    docsBpi2CmtsTEKLifetime 
            SYNTAX    Integer32 (1800..604800) 
            DESCRIPTION 
            "The refined range corresponds to the minimum and maximum 
            values in operational networks." 
     
       -- constrains on IP addressing 
       OBJECT    docsBpi2CmtsIpMulticastAddressType 
              -- SYNTAX InetAddressType { ipv4(1) } 
              DESCRIPTION 
              "An implementation is only required to support IPv4 
               addresses." 
     
       -- constrains on IP addressing 
       OBJECT    docsBpi2CmtsIpMulticastAddress 
              SYNTAX  InetAddress (SIZE(4)) 
              DESCRIPTION 
              "An implementation is only required to support IPv4 
               addresses." 
     
       -- constrains on IP addressing 
       OBJECT    docsBpi2CmtsIpMulticastMaskType 
              -- SYNTAX InetAddressType { ipv4(1) } 
              DESCRIPTION 
              "An implementation is only required to support IPv4 
               addresses." 
     
       -- constrains on IP addressing 
       OBJECT    docsBpi2CmtsIpMulticastMask 
              SYNTAX  InetAddress (SIZE(4)) 
              DESCRIPTION 
              "An implementation is only required to support IPv4 
               addresses." 
     
       ::= { docsBpi2Compliances 2 } 

-----Original Message-----
From: Jean-Francois Mule 
Sent: Wednesday, July 23, 2003 12:15 PM
To: Eduardo Cardona; Wijnen, Bert (Bert); Ipcdn (E-mail)
Cc: [email-masked]; Alexander Katsnelson;
[email-masked]
Subject: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on
docsBpi2CmtsAuthCmBpiVersion 

Eduardo,
The proposed resolution on docsBpi2CmtsAuthCmBpiVersion looks good to
me. Any other comments on this one? In short, you propose to not change
the enum list and start with 0 and to add some explanatory text to
justify it.

Jean-Francois.

-----Original Message-----
From: Eduardo Cardona 
Sent: Tuesday, July 22, 2003 11:30 AM
To: Jean-Francois Mule; Wijnen, Bert (Bert); Ipcdn (E-mail)
Cc: [email-masked]; Alexander Katsnelson; [email-masked]
Subject: RE: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10

Jean Francois, 

Eduardo
the new bpi defined parameters by bpiplus 17-27) includes : Code 22
BPI-Version in 4.2.2.22 BPI-Version of SP-BPI+-I09-020830 defined values
are : 0, Reserved 1 BPI+ 

---Suggested Text

A truly consistent enumeration for docsBpi2CmTEKSAType against the
protocol would be primary(0), static(1), Dynamic(2), none(3) At the
level protocol no 'none' attribute is send on the wire, 
it means BPKM messages are have not yet sent to determine the SA type

Proposed text (updated reference) docsBpi2CmTEKSAType OBJECT-TYPE 

The same rationale as in some BPI mibs like docsBpi2CmtsAuthCmBpiVersion
enumeration 0, 'unknown' value is used to represent the case when the CM
is running in  bpi not bpiplus NOt a straigth match but the BPKM
attibutes in bpiplus intentionaly reserves the value zero and in bpi
mode no bpiplus attibutes are not sent in the wire. so believe  the mib
is using the enmeration 0 to reflect the bpi mode of operation without
conflicting with the bpiplis attributes values (almost all time SA-Type
still has to me dark areas)

     

-----Original Message-----
From: Jean-Francois Mule 
Sent: Thursday, July 17, 2003 2:37 PM
To: Wijnen, Bert (Bert); Ipcdn (E-mail)
Cc: [email-masked]; Alexander Katsnelson; [email-masked]
Subject: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10

Bert & all, 
  -> deleted refs. 
  ->   deleted. 
  ->   fixed. 
  ->   fixed. 
  ->   fixed. 

   -> ok. 
  -> ok. fixed. 

  -> ok. fixed. 
  -> fixed. 
                           ->       ^^^^^ fixed. 
     -> fixed all of them. 

  -> yes, fixed. 
  -> yes fixed. 
  -> fixed. 

 -> ok. fixed. 
 -> ok. fixed. 
 -> ok. fixed.

---

From: "Eduardo Cardona" <[email-masked]>
Date: Thu, 24 Jul 2003 08:15:29 -0600

Bert, 

Thanks for the promply comments, 

Sorry forgot to remove the comments in the SYNTAX clauses, 
Will remove the repeated groups in CM and CMTS in both MODULE-COMPLIANCE
Will add a note explaining why this is optional 

Thanks

eduardo 

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Thursday, July 24, 2003 2:02 AM
To: Eduardo Cardona; Jean-Francois Mule; Wijnen, Bert (Bert); Ipcdn
(E-mail)
Cc: [email-masked]; Alexander Katsnelson;
[email-masked]
Subject: RE: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on
docsBpi2CmtsAuthCmBpiVersion 

Inline

> From: Eduardo Cardona [mailto:[email-masked]]
> Sent: donderdag 24 juli 2003 1:28
> Subject: RE: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on 
.. snip ..
>             "This group implementation is required for CMs."
The above two GROUP statements are not needed (may even cause errors).
They are already included in the MANDATORY-GROUPS clause !

>               -- SYNTAX InetAddressType { ipv4(1) }
This comment line should be changed in a real statement:
                SYNTAX InetAddressType { ipv4(1) } 

>             "This group implementation is required for CMTSs only."
The above GROUP can be removed, it is already included in the
MANDATORY-GROUPS clause !!

>             "This group is optional for CMTSs."
It would be better to describe under what circumstances this group
would/should be used. Or is it completely at the discretion of the
implementer?

>               -- SYNTAX InetAddressType { ipv4(1) }
This comment line should be changed in a real statement:
                SYNTAX InetAddressType { ipv4(1) } 

>               -- SYNTAX InetAddressType { ipv4(1) }
This comment line should be changed in a real statement:
                SYNTAX InetAddressType { ipv4(1) } 

>        ::= { docsBpi2Compliances 2 }
Hope this helps/explains,
Bert