Subject: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 17 Jul 2003 14:37:25 -0600

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.

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 22 Jul 2003 00:55:44 +0200

Inline, deleted those things that we now agree on.

> From: Jean-Francois Mule [mailto:[email-masked]]
> Sent: donderdag 17 juli 2003 22:37
> To: Wijnen, Bert (Bert); Ipcdn (E-mail)
> Subject: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10
> 
> 
> Bert & all, 

Did you do so now?

>   ->   no. BPI mib and BPI plus coexist together. 
OK

>   ->   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. 
OK, that will work

>             ::= { mib-2 xx }   -- xx to be assigned by IANA 

First, if you want to do mib-2 xx, then you must import mib-2 from
SNMPv2-SMI.

But... I see that RFc3083 is docsIfMib 6. And so if this is an
extension to that MIB module, then it makes sense (probably) to
put this new one under docsIfMib too. 
So my question was not that you cannot do so if it makes sense.
My question was more: how do you make sure that no one else
assigns the same number. If IPCDN WG keeps an eye on it, then
that may be acceptable. It might be best to ask IANA to at least
keep a registry. I currently see
 docsIfMib 1   - RFC2670
 docsIfMib 2   - RFC2670
 docsIfMib 3   - RFC2670
 docsIfMib 5   - RFC3083
 docsIfMib 6   - bpiplus
 and a few other ::= { docsIfMib XXX } -- to be assigned bu IANA

C:\bwijnen\smicng\rfcs>grep docsIfMib *.mi2
rfc2670.mi2:docsIfMib MODULE-IDENTITY
rfc2670.mi2:docsIfMibObjects  OBJECT IDENTIFIER ::= { docsIfMib 1 }
rfc2670.mi2:docsIfBaseObjects OBJECT IDENTIFIER ::= { docsIfMibObjects 1 }
rfc2670.mi2:docsIfCmObjects   OBJECT IDENTIFIER ::= { docsIfMibObjects 2 }
rfc2670.mi2:docsIfCmtsObjects OBJECT IDENTIFIER ::= { docsIfMibObjects 3 }
rfc2670.mi2:docsIfNotification OBJECT IDENTIFIER     ::= { docsIfMib 2 }
rfc2670.mi2:docsIfConformance  OBJECT IDENTIFIER     ::= { docsIfMib 3 }
rfc2670.mi2:MODULE  -- docsIfMib
rfc3083.mi2:    docsIfMib, docsIfCmServiceId, docsIfCmtsServiceId
rfc3083.mi2:    ::= { docsIfMib 5 }

In fact, looking at this, it seems a weird structure of the OID tree.
So you better decide what you want or how to clean it up if that is
what you want. Maybe we discussed this 5 months ago and I forgot.
Maybe it is indeed best to put this one under mib-2

>         does not require to be associated with a last reset object." 
OK

>    Added IMPORT ZeroBasedCounter32 FROM RMON2-MIB. 
OK. This also means that you must make RFC2021 a normative reference

>   interface specification as integer values (1) and (2)." 
OK.
>   -> ok. fixed. Added "This object is defined for future 

I still find it weird.. but ??

> >    or type of this object. You did it correct in subscriber mib. 

I still do not see that this is reflected in the InetAddress objects,
do I? Fo example:
       docsBpi2CmIpMulticastAddress  OBJECT-TYPE
            SYNTAX         InetAddress
            MAX-ACCESS     read-only
            STATUS         current
            DESCRIPTION
                 "This object represents the IP multicast address
            to be mapped."
Should say something aka:
       docsBpi2CmIpMulticastAddress  OBJECT-TYPE
            SYNTAX         InetAddress
            MAX-ACCESS     read-only
            STATUS         current
            DESCRIPTION
                 "This object represents the IP multicast address
            to be mapped. The type of this address is determined by
            the value of the docsBpi2CmIpMulticastAddressType object."

In your compliance section I see:
       -- relaxation on IP addressing
       OBJECT    docsBpi2CmIpMulticastAddressType
              -- SYNTAX InetAddressType { ipv4(1) }
              DESCRIPTION
              "An implementation is only required to support IPv4
               addresses."
First, I do not think it is a "relaxation", but rather a "restriction"?
But that is nit picking. More important, the SYNTAX should not be
a comment! I know that SMICng complains about it, but that is a bug
in SMICng. You have multiple of those

>       to be discussed in docsis team. 

Still discission needed? You better decide soon

> >    Yet another way in which you guys do resets. 

?? no answer?

>   -> to be addressed in docsis team 

When??

>   -> to be addressed in docsis team 

When ?

> >    That SMICng barks at it is something we know and SMICng 
Mmm... I still see them !!

>  -> ok, beefed up the security consideration section. 
I wonder if Security ADs want to see something about all that 
key information that you have in the MIB. You may want to check
with them early on... so that they can give you early advise.
Like Keylengths and such?

> Minor additional nits: 
>  - Enforced (mostly) the 72 character column limit in Word, 
>    and fixing  the wrapped text (many many changes). 

I still get:
$ /bin/checkpage.awk < draft-ietf-ipcdn-bpiplus-mib-10.txt
Bad chars at 77
Bad chars at 3758
Bad chars at 3950
-: 3 lines containing non-US-ASCII characters
-: 73 formfeeds not on a line by themselves

>    statements, since they are not permitted per the following syntax 

I also still see refernce to RFC2571/4/5/ which have been obsoleted
by RFC3411/4/5

You have norm ref to RFC2819.. you probably mean RFC2021 (RMON2-MIB).

Further, SMICng tells me:
   W: f(ipcdnbpiplus.mi2), (3242,8) OBJECT-GROUP
      "docsBpi2ObsoleteObjectsGroup" is not used in a 
      MODULE-COMPLIANCE in current module
It is best to list it as optional in the MODULE-COMPLIANCE.
See bottom of page 23 of draft-ietf-ops-mib-review-guidelines-01.txt

Further I see in your meeting mnutes:
 o draft-ietf-ipcdn-bpiplus-mib-10.txt
    pending resolution of 2 open issues (see action items below), the
    bpi+ ID is ready for WGLC. Expected ID update by
    end of August/early September'03 and launch of WGLC shortly after.

If you do WG LC in first half of Sept, then there is no way that this
doc will make it to RFC by end-october!

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

---

From: "Eduardo Cardona" <[email-masked]>
Date: Tue, 22 Jul 2003 11:30:22 -0600

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

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 } 

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

>      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 

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? 

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]

	Bert & all, 

	Jean-Francois. 
	> From: Wijnen, Bert (Bert) [mailto:[email-masked]
<mailto:[email-masked]> ] 
	  -> deleted refs. 

	  ->   deleted. 

	  ->   fixed. 

	  ->   fixed. 

	  ->   added the following text: 
	              Copyright (C) The Internet Society (2003). This
version 
	              of this MIB module is part of RFC xxx; see the RFC

	  ->   fixed. 

	>   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. 

	>    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." 

	   -> ok. 

	>     docsBpi2CmtsAuthInvalidErrorString 
	  -> done - replaced all 'Display-String' in description clauses
by 'text 
	  string' 

	  -> ok. fixed. 
	  so it is proposed to leave object def as-is and add the
following 

	  -> ok. fixed. 

	>    MIB module, might as well use the recommended method. 
	 -> certainly. fixed all integer32 INDEX objects syntax to
Unsigned32. 

	  -> fixed. 

	>    Seems to me that
docsBpi2CmtsDefaultSelfSignedManufCertTrusted 

	                           ->       ^^^^^ fixed. 

	     -> fixed all of them. 

	  -> yes, fixed. 

	  -> yes fixed. 

	  -> fixed. 

	 -> ok. fixed. 

	 -> ok. fixed. 

	 -> ok. fixed. 

	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.

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 23 Jul 2003 18:05:02 +0200

W.r.t.

> There is not unconditionally groups (e.e base group applying 
> both CM and CMTSes)
> The tree groups are  
>  
Or, have TWO MODULE-COMPLIANCE statements, one for
CM, which would have MANDFATORY groups docsBpi2CmGroup and 
docsBpi2CodeDownloadGroup and one for CMTS, which would
have mandatory groups docsBpi2CmtsGroup and 
docsBpi2CodeDownloadGroup

Does that not make sense?

Are there situations where one SNMP agent would be acting
in both roles?

Bert

---

From: "Eduardo Cardona" <[email-masked]>
Date: Thu, 24 Jul 2003 11:40:21 -0600

>Maybe it is indeed best to put this one under mib-2

Bert, 
We Would like to get your advise in this topic and I am extending some
generalization:

The DOCSIS Interface suite of mibs were initialy visualized as :

Mib-2 branch Device mibs RFC 2669 ( eventually SubMgmt also) 

Mib-2.transmission.docsIfMib(127) branch:  Extension of CATV Interface
(ifType=127) for Phy/MAC layer requirements like bpi, bpiplus, docsQos, 

Is that still a valid approach for the submitted drafs or mib-2 branch
will be the structure wise required tree?
Is there any other OID holder based on functionality schema? ( security/
Qos ) ? 
The intention of that was corroborated ( I presume that ) with the
assignemt of bpi mib RFC 3083 under docsIfMib 5 

We definitely will do what IETF and IANA wanted to keep organized the
OID trees, but a better understanding of IETF desire will be really
valuable. And the drafts could be the places to keep those trends
requirements among IETF, IPCDN and IANA.

A look of your oid mapping: 

 docsIfMib 1   - RFC2670 mib objects
 docsIfMib 2   - RFC2670 notifications
 docsIfMib 3   - RFC2670 conformance 
 docsIfMib 5   - RFC3083 bpi objects/notifications/conformance

The current drafts (implemented in the field showed in parantesis): ->
prior to InetAddress RFC 2851/3291
 docsIfMib 6   - bpiplus (draft 05) objects/notifications/conformance
 docsIfMib 7   - docsQos (draft 04) objects/notifications/conformance

Keeping the legacy structure: (legacy "weird structure") new proposed
drafts for RFC
 docsIfMib 8   - IETF bpiplus RFC objects/notifications/conformance
 docsIfMib 9   - IETF docsQos RFC objects/notifications/conformance 

Thinking in IETF-MODULE styles

What would be the organized structure?
Mib-2 or transmission Hierachy related ifmib, bpiplus docsqos?
How IETF really wants to organize the trees?
If Mib-2 for bpiplus and qos, any particular subtrees of mib-2

Or transmission sub-tree:

How does IETF docsIfMib play  as an umbrella for bpiplus and docsQos or
any DOCSIS related interface mib

Will that define a path requiring  IETF docsIfMib to be IESG approved
before  bpiplus/docsQos ?
Supposed in transmission branch transmission... (128 is also a docsis
ifType not as good option as 127 but that one is already covered by
rfc2670

 One option:

Transmission 128 - docsIfIETF ? ( to say any number? )
docsIfIETF 1 docsIfMib new RFC (objects/notifications/conformance)
docsIfIETF 2 bpiplus new RFC (objects/notifications/conformance)
docsIfIETF 3 docsQos new RFC (objects/notifications/conformance)

Thanks

Eduardo

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 24 Jul 2003 23:26:24 +0200

Inline

> From: Eduardo Cardona [mailto:[email-masked]]
> Sent: donderdag 24 juli 2003 19:40
> To: Wijnen, Bert (Bert); Jean-Francois Mule; Ipcdn (E-mail)
> Cc: [email-masked]; Alexander Katsnelson; [email-masked]
> Subject: RE: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10
> 
> 
That seemed (and still seems) to make sense.

> (ifType=127) for Phy/MAC layer requirements like bpi, 
So I can see that transmission.127 makes sense for the RFC2670 MIB.
Seems that BPI, BPIPLUS are also strongly related to a MAC interface,
so probably assigning them underneath docsIfMib is OK.

For the QOS MIB module I am not so sure. Seems to me that that should
go under mib-2, similar to how DIFFSERV-MIB went under mib-2.

> will be the structure wise required tree?

See above... they need to go where we think they make sense logically.

What I possibly would have done is something aka:
  
  Mib-2.transmission.docsis(127)  -- generic OID branch for DOCSIS interface
                                  -- objects
  docsis.docsIfMib(1)             -- docsIfMib
  docsIfMib.docsIfMibObjects(1)   -- OID branches within docsIfMib

  docsis.docsBpiMib(2)            -- docsBpiMib
  docsis.docsBpiPlusMib(3)        -- docsBpiPlusMib

In other words, I would have used one branch under which I would
put the MIB modules, and then within each MIB module I would
have made anotehr level for Objects, Notifications, Compliances etc.
You have now intermixed all that and that has made it a bit of a mess
(at least in my eyes). But we cannot fix that anymore. Or if we do,
then it comes with a lot of pain I suppose.
   
> Is there any other OID holder based on functionality schema? 
> ( security/Qos ) ? 
Within One MIB module, people can assign in the DRAFT docs itself.
You normally have something aka:

  someModuleMib MODULE-IDENTITY
     ...
  ::= { root-oid xx } -- xx to be assigned by IANA

  Within root-oid.xx you can then assign your own structure

This will help in the sense that you only get xx assigned once the
ID gets published as an RFC. And that is the time that people can
actually use the OID that gets assigned, not anytime earlier
while you are still developing the draft.

>  docsIfMib 7   - docsQos (draft 04) objects/notifications/conformance
This is REALLY BAD. Peopl should NOT and NEVER implement I-Ds and then
use OIDs from the IANA maintained/controlled OID space) for the MIB 
modules that are not yet published as RFC.
Vendors could have put them under their enterprise OID tree, or maybe
under some experimental OID tree if you had asked for one.

>  docsIfMib 9   - IETF docsQos RFC objects/notifications/conformance 
So if we do this, then the customers may end up with the same
objects but under two different OID trees? That sounds like BAD for
the customers, does it not?

What a mess!

> docsIfIETF 3 docsQos new RFC (objects/notifications/conformance)
Will you also rename your object descriptors?
How are people going to know the difference between
current docsIfDownstreamChannelTable and the docsIfDownstreamChannelTable
once it gets re-rooted under docsIfIETF ??

See... what is biting you here is the rules of how you can change
and update non-published (I-Ds) and existing published (as RFCs)  
MIB modules. You may want to read about that in the RFC2578/79/80
RFCs.

Hope this helps. I need to think about a solution. Maybe we need
to chat about that some more.
Bert