Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus
draft-ietf-ipcdn-bpiplus-mib-15

Checking with Russ Housley if his DISCUSS has been addressed (I think so).

Also checking with wg chairs and authors how/if they think they have
addressed Steve Bellovin's discuss, because I fear they have not.

Bert

New rev expected Nov 19th

> -----Original Message-----
> From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]
> Sent: Thursday, October 28, 2004 22:01
> To: Wijnen, Bert (Bert)
> Cc: Jean-Francois Mule; Richard Woundy @ Comcast; Eduardo Cardona
> Subject: RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14
>
>
> Bert,
>
>  Here's a brief status on where we are with the BPI+ mib
> based on input from Eduardo.
>
> 1. Eduardo is about 60% done addressing the IESG
> comments and he plans to send a full summary with proposed
> text changes to the ipcdn list next week, by Friday Nov 5
> 2. We would like to give the list 1 week to review the
> final proposed changes (this will be the week of the IETF and
> we'll discuss those final changes in Washington)
> 3. Pending no additional comments, Eduardo will then
> release the new updated Internet-Draft by Fri Nov 19 for publication.
>
> Let me know if this plan is ok.
> Jean-François
>

[Ballot comment]
I concur in Russ' comments about the lack of any suitably strong crypto algorithms.  40-bit DES is, frankly, an embarrassment at this point.  Yes, I realize that DOCSIS isn't doing it right yet; that's no reason for us to do it wrong.  We should put the code points into the MIB now, and let them catch up.  But I'll let Russ hold that part of the DISCUSS (as well as the note that authentication algorithms are needed.)

[Ballot discuss]
The Security Considerations section says

    The time to crack DES could be additionally
    mitigated by a compromised value for the TEK lifetime and Grace Time
    (up to a minimum of 30 minutes for the TEK lifetime, see
    Appendix A [1]).

That's only partially correct.  These keys are confidentiality keys; they're still valuable even after they're no longer in active use, because they can be used to decrypt old traffic.  (By contrast, old authentication keys are useless to an attacker.)

[Ballot discuss]
The definition of docsBpi2CmPublicKey begins:
  :
  :  docsBpi2CmPublicKey    OBJECT-TYPE
  :      SYNTAX            OCTET STRING (SIZE (74|106|140|204|270))
  :
  The selection of these few octet string sizes is inappropriate.
  PKCS #1 encoding of an RSA public key is a SEQUENCE of two
  INTEGERs.  One example of an acceptable RSA public key that
  cannot be accommodated by this definition follows.  It is 139
  octets.

    0 30  135: SEQUENCE {
    3 02  129:  INTEGER
              :    00 B0 B3 67 A7 96 B5 76 83 E9 16 03 D9 1A A0 76
              :    D5 74 E7 9C 05 D2 51 3F DB 4F 19 A1 A8 39 4E CB
              :    24 7D 61 C4 1E 6A 20 AE 0F 81 DE EA B8 39 FD 1B
              :    1F 6B 36 40 ED 4D 21 25 F2 A3 D9 A1 51 D8 6C C0
              :    1B 96 F8 D4 42 94 D4 A7 CE 1B 8F D3 54 26 A2 84
              :    EF 32 85 AF 4A 3F F1 32 36 AF 3D E6 3A 27 EB 03
              :    C2 25 7E F4 61 2B AD 8A 1A 4B E6 9B 36 68 D4 2F
              :    E5 D2 88 94 DC 16 AA DA C2 15 4C 6C C3 E1 19 91
              :    C9
  135 02    1:  INTEGER 3
              :  }

  I do not believe that a five (or even ten) specific sizes can be
  chosen that accomodate all valid RSA public keys.

  The definition of docsBpi2CmtsAuthCmPublicKey has the same problem.
 
  The definition of docsBpi2CmTEKDataEncryptAlg begins:
  :
  :  docsBpi2CmTEKDataEncryptAlg  OBJECT-TYPE
  :      SYNTAX        INTEGER {
  :                              none(0),
  :                              des56CbcMode(1),
  :                              des40CbcMode(2)
  :                              }
  :
  And, the definition of docsBpi2CmTEKDataAuthentAlg begins:
  :
  : docsBpi2CmTEKDataAuthentAlg  OBJECT-TYPE
  :      SYNTAX        INTEGER {
  :                            none(0)
  :                            }
  :
  These same values are also used in the docsBpi2CmCryptoSuiteDataEncryptAlg,
  docsBpi2CmCryptoSuiteDataAuthentAlg, docsBpi2CmtsTEKDataEncryptAlg,
  docsBpi2CmtsTEKDataAuthentAlg, docsBpi2CmtsIpMulticastDataEncryptAlg,
  and docsBpi2CmtsIpMulticastDataAuthentAlg definitions.
 
  None of the encryption algorithm choices is a strong encryption
  algorithm.  Also, the encryption algorithm choice do not
  provide integrity, so they ought to be used with an integrity
  algorithm, but none are specified.  Can we get a strong
  encryption algorithm added to the list?  Can we get an strong
  integrity algorithm specified?  If not, the last few paragraphs of
  of the Security Considerations need to be made much more forceful.

[Ballot discuss]
I concur in Russ' comments about the lack of any suitably strong crypto algorithms.  40-bit DES is, frankly, an embarrassment at this point.  Yes, I realize that DOCSIS isn't doing it right yet; that's no reason for us to do it wrong.  We should put the code points into the MIB now, and let them catch up.  But I'll let Russ hold that part of the DISCUSS (as well as the note that authentication algorithms are needed.)

The Security Considerations section says

    The time to crack DES could be additionally
    mitigated by a compromised value for the TEK lifetime and Grace Time
    (up to a minimum of 30 minutes for the TEK lifetime, see
    Appendix A [1]).

That's only partially correct.  These keys are confidentiality keys; they're still valuable even after they're no longer in active use, because they can be used to decrypt old traffic.  (By contrast, old authentication keys are useless to an attacker.)

[Ballot discuss]
The definition of docsBpi2CmPublicKey begins:
  :
  :  docsBpi2CmPublicKey    OBJECT-TYPE
  :      SYNTAX            OCTET STRING (SIZE (74|106|140|204|270))
  :
  The selection of these few octet string sizes is inappropriate.
  PKCS #1 encoding of an RSA public key is a SEQUENCE of two
  INTEGERs.  One example of an acceptable RSA public key that
  cannot be accommodated by this definition follows.  It is 139
  octets.

      0 30  137: SEQUENCE {
      3 02  129:  INTEGER
                :    00 DD D8 49 85 DD 76 BE 9C 64 D2 6A 0C B3 3A 14
                :    0B 37 A5 60 97 90 40 3D C0 C6 9C 01 FB D0 6F B6
                :    49 56 E5 1A 44 F7 C7 1D 23 4C 91 A2 6F BE F7 9A
                :    D0 5F F0 88 9A 01 A2 0A 20 78 22 45 1A 9D 77 8F
                :    CA 14 3E 75 44 3C D6 67 16 21 E5 42 B5 EC BF 62
                :    6C 09 0E 4D D9 79 D0 55 82 5C 9C FD B1 B9 B6 A6
                :    5B 42 83 FA 90 1E 74 3F 5C 1C 1F D8 73 40 94 3C
                :    9A 9F 2A 04 FE ED 8C 69 C3 0E 10 A6 3B 0B A7 A4
                :    CD
    135 02    3:  INTEGER 65537
                :  }

  I do not believe that a five (or even ten) specific sizes can be
  chosen that accomodate all valid RSA public keys.

  The definition of docsBpi2CmtsAuthCmPublicKey has the same problem.
 
  The definition of docsBpi2CmTEKDataEncryptAlg begins:
  :
  :  docsBpi2CmTEKDataEncryptAlg  OBJECT-TYPE
  :      SYNTAX        INTEGER {
  :                              none(0),
  :                              des56CbcMode(1),
  :                              des40CbcMode(2)
  :                              }
  :
  And, the definition of docsBpi2CmTEKDataAuthentAlg begins:
  :
  : docsBpi2CmTEKDataAuthentAlg  OBJECT-TYPE
  :      SYNTAX        INTEGER {
  :                            none(0)
  :                            }
  :
  These same values are also used in the docsBpi2CmCryptoSuiteDataEncryptAlg,
  docsBpi2CmCryptoSuiteDataAuthentAlg, docsBpi2CmtsTEKDataEncryptAlg,
  docsBpi2CmtsTEKDataAuthentAlg, docsBpi2CmtsIpMulticastDataEncryptAlg,
  and docsBpi2CmtsIpMulticastDataAuthentAlg definitions.
 
  None of the encryption algorithm choices is a strong encryption
  algorithm.  Also, the encryption algorithm choice do not
  provide integrity, so they ought to be used with an integrity
  algorithm, but none are specified.  Can we get a strong
  encryption algorithm added to the list?  Can we get an strong
  integrity algorithm specified?  If not, the last few paragraphs of
  of the Security Considerations need to be made much more forceful.

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Sunday, September 19, 2004 22:43
To: 'Jean-Francois Mule'
Cc: Richard Woundy @ Comcast; Eduardo Cardona; Wilson Sawyer;
wsawyer@ieee.org
Subject: RE: BPI+: yes


Mmmm... I see in revision 14:

  8. IANA Considerations

  The MIB module in this document uses the following IANA-assigned
  OBJECT IDENTIFIER values recorded in the SMI Numbers registry:

  Descriptor    OBJECT IDENTIFIER Value
  ----------    -----------------------
  docsBpi2MIB    { docsIfMib yy }

  Editor's Note (to be removed prior to publication): the IANA is
  requested to assign a value for yy under the docsIfMib  subtree and
  to record the assignment in the SMI Numbers registry.  When the
  assignment has been made, the RFC Editor is asked to replace yy
  (here and in the MIB module) with the assigned value and to remove
  this note.

So WHERE in the "SMI Numbers registry" is this { docIfMib xx }
recorded? I cannot find it on
  http://www.iana.org/assignments/smi-numbers

Am I missing something? I am pretty sure IANA will come back with this
question. Did I not raise the issue that if you want to do allocations
under docsIfMib, that we MUST describe for IANA what the rules are.

They could be as simple as

  New assignments under docIfMib can only be done by Standards Action
  as defined in [RFC2434].

  The current assignments are:

      docsIfMib 1    xxx
      docsIfMib 2    yyy
    etc.

I think that I did point out the risks for this as well, did I not?
They are documented in mib review guidelines revision 3 as
in draft-ietf-ops-mib-review-guidelines-03.txt
state on page 13, sect 4.5, 3rd bullet:

  - The value assigned to the MODULE-IDENTITY descriptor MUST be unique
    and (for IETF standards-track MIB modules) SHOULD reside under the
    mgmt subtree [RFC2578].  Most often it will be an IANA-assigned
    value directly under mib-2 [RFC2578], although for media-specific
    MIB modules that extend the IF-MIB [RFC2863] it is customary to use
    an IANA-assigned value under transmission [RFC2578].  In the past
    some IETF working groups have made their own assignments from
    subtrees delegated to them by IANA, but that practice has proven
    problematic and is NOT RECOMMENDED.

So your approach is certainly not recommended anymore.
Now you are already down this path. But we need to ensure we do not
risk double assignments (I have had this happen to us in the
past, and even by MIB experts.). We need IANA to keep a
registry. For RMON (which caused the trouble in the past, we have done
RFC3737. You may want to consider a similar document for docsIfMib
allocations.

I will put the doc on IESG agenda. But you better be prepared for
pushback as per above.

Bert

New revision needed based on comments/feedback and on
AD comments raised as part of IETF Last Call.
Expected to show up in the week of Aug 16th (according to WG chairs and main editor)

Initial IETF Last Call COmments (raised by AD) and posted to IPCDN list:

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: maandag 26 juli 2004 23:30
To: 'Eduardo Cardona'; ipcdn@ietf.org
Cc: DOCSIS OSS Majordomo List
Subject: RE: [ipcdn] I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-13.txt


Mmm, in your response I see:

  "Discontinuities of this counter are indicated by sysUpTime and
    ifCounterDiscontinuityTime for the associated ifIndex."

Not sure I understand this.
Checking with other MIB doctors.

  docsBpi2CmtsCACertThumbprint OBJECT-TYPE
        Note: The zero-length string must be returned if this object is
        not supported by the CMTS."
That seems weird.
If an object is not supported, I would expect to return a noSuchObject
exception. !!

I also see:
  Rather than a Compliance statement ( the object MUST be supported) I
  believe an indication of

        "Note: For CMs running in BPI mode, this object value has no
        meaning, therefore the CMTS may not instantiate this object
        for those CM entries."

And so that would mean that the agent returns a noSuchInstance exception!

I see that to this:
  But thinking even further, Possibly the best thing to do is to use
            docsBpi2CmtsIpMulticastAddressType      InetAddressType,
            docsBpi2CmtsIpMulticastAddress          InetAddress,
            docsBpi2CmtsIpMulticastPrefixLength    InetAddressPrefixLength,
  Are not such masks always setup that they basically specify a prefixlength?
  If so, then this is the way to do it with the TCs from INET-ADDRESS-MIB.
your answer seems to be:
 
  This issue was brought up before and Rich Woundy exposed a detail
  explanation of the design requirements in favor of a netmask instead of
  an InetPrefixLength /RFC2373/3513

    plus en email from Rich, stating that it might be good to explanation
    which I cannot find.

Can that explanation be added to DESCRIPTION clause(s)?
I cannot understand that from current DESCRIPTION clauses, or am I
not reading clear at this late hour of the night?

10. I see:
      docsBpi2CmtsIpMulticastMapControl  OBJECT-TYPE
          SYNTAX        RowStatus
          MAX-ACCESS    read-create
          STATUS        current
          DESCRIPTION
                "This object controls and reflects the IP multicast
          address mapping entry.  There is no restriction on the
          ability to change values in this row while the row is
          active.  Inactive rows need not be timed out."
    Mmm... that "need not be timed out" seems in conflict with the RowStatus
    TC DESCRIPTION clause in RFC2579. Can you explain why this is?

    Also, a RowSTatus object MUST specify in its DESCRIPTION clause under
    which conditions
    - the row can be activated
    - which columns (if any) can bve changed while in the active state.
    I am missing the first.

 
  Removed the prohibition to age out inactive row entries.
  Added:
    "A created row can be set to active only after the corresponding
    instances of
    docsBpi2CmtsIpMulticastAddress, docsBpi2CmtsIpMulticastMask,
    docsBpi2CmtsIpMulticastSAId and docsBpi2CmtsIpMulticastSAType have all
    been set, otherwise the status of this object is 'notReady'".

Mmm... the status could also be notInService I would think?
Why not remove that last piece of the sentence, i.e. remove:
            , otherwise the status of this object is 'notReady'


Thanks,
Bert

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: dinsdag 27 juli 2004 12:29
To: 'Eduardo Cardona'; ipcdn@ietf.org
Cc: DOCSIS OSS Majordomo List
Subject: RE: [ipcdn] I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-13.txt


As a follow up to this, there was this comment from me:
>
> Mmm, in your response I see:
>
>    "Discontinuities of this counter are indicated by sysUpTime and
>    ifCounterDiscontinuityTime for the associated ifIndex."
>
> Not sure I understand this.
> Checking with other MIB doctors.
>
The first thing we found is that it is not so clear what the text means,
but it probably menas the same things as for other IF-MIB related counters,
i.e. (as also used in IF-MIB, RFC2863), it means:

            Discontinuities in the value of this counter can occur at
            re-initialization of the management system, and at other
            times as indicated by the value of
            ifCounterDiscontinuityTime.

And if that is indeed the case, then this new text would be MUCH better.

Now, when you added the text about discontinuities, it also makes it
more visible that one could really question if the use of ZeroBasedCounter32
makes sense and if a regular Counter32 would not be much much better.

Have you read the ZeroBasedCounter32 TC and the text that explains what this
type of counter was meant for?

One comment from another MIB doctor is:
  A ZeroBasedCounter32 in a conceptual row which can experience
  discontinuities as part of its normal operational behaviour
  just seems a bit odd to me. I fail to see what the advantage of
  a ZeroBasedCounter32 in such a situation is.

Another comment (in relation to ifCounterDiscontinuityTime) is that it would
be very good to add some text (somewhere early on in the draft) that points
to RFC2863, page 12, which has some good text about that object. As per
the comment of another MIB Doctor:
  I think it would be extremely helpful to have a discussion what this
  means somewhere in the introductionary text together with a pointer to
  the relevant text in the IF-MIB RFCs (which has some paragraphs about
  this subject that are interesting to know for implementors).

  Looking at the MIB, the question that I have is the interaction of
  discontinuities with these ZeroBasedCounter32 objects. Does a
  discontinuity couse these counters to be reset to zero? The TC says
  that a zero based counter is set to zero(0) on creation and it has
  additional text that the intended usage is in tables where the index
  space is constantly changing. Does this apply here?

Of course you have clarified (but in some prose early on in the draft may
want to re-emphasize) that the ZeroBasedCounter32 only MUST be set to zero
at row creation. But some additional discussion seems usefull.

Bert

----
Some quick notes, Here we go:

1. SMICng tells me:
    W: f(ipcdnbpi2.mi2), (3142,17) Duplicate item "docsBpi2CmtsIpMulticastAddressType"
      in compliances list for module "DOCS-IETF-BPI2-MIB"
    W: f(ipcdnbpi2.mi2), (3152,17) Duplicate item "docsBpi2CmtsIpMulticastAddress"
      in compliances list for module "DOCS-IETF-BPI2-MIB"
  Seems you duplicated something.

2.      docsBpi2CmtsIpMulticastMapControl  OBJECT-TYPE
          SYNTAX        RowStatus
          MAX-ACCESS    read-create
          STATUS        current
          DESCRIPTION
                "This object controls and reflects the IP multicast
          address mapping entry.  There is no restriction on the
          ability to change values in this row while the row is
          active.  Inactive rows need not
          A created row can be timed out." set to active only after the
          Corresponding instances of docsBpi2CmtsIpMulticastAddress,
          docsBpi2CmtsIpMulticastMask, docsBpi2CmtsIpMulticastSAId
          and docsBpi2CmtsIpMulticastSAType have all been set,
          otherwise the status of this object is 'notReady'.


          There is no restriction on the ability to change values in
          this row while the row is active."
          ::= { docsBpi2CmtsIpMulticastMapEntry 14 }

    Last sentence in DESCRIPTION clause is duplicate of 2nd sentence.
    Are you sure value is 'notReady' in that case? Could be notInService
    too, no? Why specify it. I.e. I would remove
          otherwise the status of this object is 'notReady'


3.      docsBpi2CmtsIpMulticastMapStorageType    OBJECT-TYPE
          SYNTAX        StorageType
          MAX-ACCESS    read-only
          STATUS        current
          DESCRIPTION
                "The storage type for this conceptual row."

  You must (according to RFC 2579) add txt to stat which (if any) writable
  objects MUST be writeable even for permanent entries. See 2579 fo details.

AD review of revision 12, parts 1 and 2:

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: woensdag 14 juli 2004 22:06
To: Ipcdn (E-mail)
Subject: AD review of: draft-ietf-ipcdn-bpiplus-mib-12.txt - part 2


OK, here is part 2. AT the bottom I also have repreated part 1, so you
have it all in one email in case that is handy.

more or less serious (I continue with number 12):
12. I see:
      docsBpi2CmtsProvisionedCmCertStatus OBJECT-TYPE
            SYNTAX  RowStatus
            MAX-ACCESS read-create
            STATUS  current
            DESCRIPTION
                "Standard RowStatus object except:
            a) if a row has ever been activated,
            a set to docsBpi2CmtsProvisionedCmCert need not succeed,
            b) inactive rows need not be timed out."

  So you are changing the rules of the RowStatus TC? Seems not allowed to me.


nits/administrative/questions (continue with muber 2):

2. I see:
    docsBpi2CmtsCACertSubject OBJECT-TYPE
          SYNTAX        SnmpAdminString
          MAX-ACCESS    read-only
          STATUS        current
          DESCRIPTION
                "The subject name exactly as it is encoded in the
          X509 certificate.
          The organizationName portion of the certificate's subject
          name must be present.  All other fields are optional.  Any
          optional field present must be prepended with
          (carriage return)  (line feed) ASCII characters.
          Ordering of fields present must conform to:

          organizationName 
          countryName 

    A 7-bit ASCII character (which CR and LF are) does get represented exactly
    the same when UTF-8 encoded. But it is kind of weird to speak about
    ASCII characters when discussing the content of a UTF-8 based OCTET STRING.
    I checked with our UTF-8 and Unicode expert (Patrik Faltstrom) and he comes
    up with this suggestion:

    Replace sentence:
                                                          Any
          optional field present must be prepended with
          (carriage return)  (line feed) ASCII characters.

    with:

                                                          Any
          optional field present must be prepended with
          (carriage return, U+000D) and  (line feed, U+000A).

    You have this in a number of objects, pls check them all.

3. I see:
      docsBpi2CmDeviceCmCert  OBJECT-TYPE
            SYNTAX            DocsX509ASN1DEREncodedCertificate
            MAX-ACCESS            read-write
            STATUS              current
            DESCRIPTION
                "The X509 DER-encoded cable modem certificate.
            Note:  This object can be set only when the value is the
            null string.  Once the object contains the certificate, its
            access MUST be read-only."

  Maybe this is just wording.
  - First, I already discussed the "null string" issue. I think you mean
    a zero length string or maybe better "zero length certificate" or
    "zero length OCTET STRING" or "zero length value".
  - Now, it seems to me that if the requirement is that the object has
    a zero length value in order for a SET to be accepted, then, when
    someone tries a SET while there is already a value, that then the
    system ought to return a error that explains what is wrong. I.e.
    an error that would otherwise not occur. If you get a notWritable,
    then the management station does not necassarily know why that is,
    see bullet 2 page 20 of RFC3416 or point 9 on page 21.
    Maybe a better error would be a inconsistentValue, point 10 on page
    21 of RFC3416?? Does that not seem a better way to indicate this
    error?

4. I see:
      docsBpi2CmTEKDataEncryptAlg  OBJECT-TYPE
            SYNTAX        INTEGER {
                                      none(0),
                                  des56CbcMode(1),
                                  des40CbcMode(2)
                                  }
            MAX-ACCESS    read-only
  I understand that this is read-only and so can only report what is in the
  Cm. But I would not be surprised if this will cause questions from the
  security folk. Is this the only envryption that is supported?

5. I see:
      docsBpi2CmtsDefaultSelfSignedManufCertTrust  OBJECT-TYPE
          SYNTAX    INTEGER {
                    trusted (1),
                    untrusted (2)
                    }
          MAX-ACCESS    read-write
          STATUS        current
          DESCRIPTION
                "This object determines the default trust of
          self-signed manufacturer certificate entries, contained in
          docsBpi2CmtsCACertTable, created after setting the object."

  I cannot say that I understand what "afetr setting the object" means.
  which object?


Thanks,
Bert

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: woensdag 14 juli 2004 18:03
> To: Ipcdn (E-mail)
> Subject: [ipcdn] AD review of: draft-ietf-ipcdn-bpiplus-mib-12.txt -
> part 1
>
>
> Sorry, it took too long  to finally get this done.
>
> Not sure this document is ready for IETF Last Call.
> Actaully I think it is not.
>
> This is part 1. Mainly serious things.
> I may have more nits/admin stuff later.
>
> Here are my findings.
>
> More or less serious:
> 1. I see various read-write and/or read-create objects and I do
>    not see any text in the DESCRIPTION clauses (non
> STorageType objects)
>    that tell me what the expected behaviour is w.r.t.
> persistency of such
>    objects. SO what happens after a restart/reboot?
>
> 2. I see a number of ZeroBasedCOunter32 objects that have text aka:
>    (for example docsBpi2CmAuthentInfos)
>            DESCRIPTION
>                  "The value of this object is the count of
> times the CM
>            has transmitted an Authentication Information message,
>            since reboot."
>    It is OK to tell us that a ZeroBasedCOunter32 object must
> start with zero
>    at (re-)boot time or at row creation.
>    But from that point on, a ZeroBasedCounter32 behaves
> exactly the same
>    as a Counter32, and so it is incorrect to say "count of X
> since reboot"
>    because the Counter32 may have wrapped!. Possibly this is not gonna
>    happen in practice, but literally the claim is incorrect.
>
> 3. For these ZeroBasedCounter32 objects, I also see no word
> about a possible
>    discontinuity timer. Why not. Can there NEVER be a
> discontinuity? Of if
>    there is one does that mean ALL counters experience a
> discontionuity?
>    The latter is what you basically state (or cause) by not
> pointing to a
>    specific discontinuity timer. Because then by default it
> is sysUpTime, and
>    so that means that when you DO experience a discontinuity,
> then you MUST
>    reset sysUpTime and that means that a discontinuity for
> EVERYONE (object)
>    that assumes the default. If such is intended, then fine,
> but it would be
>    good to then state that sysUpTime is the discontinuity timer.
>
> 4. I see that for some objects you speak about a "null
> string" or "NULL string".
>    The base data type for such objects is OCTET STRING. In
> all those cases
>    I suspect (but I am not sure) that you mean the
> zero-length octet string.
>    Otherwise I do not understand what "null string" means.
>    Pls explain and fix.
>
> 5. For docsBpi2CmtsAuthCmExpiresOld I see:
>            Note: For CMs running in BPI mode, implementation of this
>            object is optional and MAY vary."
>    Mmm... that sounds like a MODULE-COMPLIANCE aspect and I
> would rather
>    see such things in MODULE-COMPLIANCE and not in object
> DESCRIPTION clauses.
>
> 6. I see:
>      -- Note: the following object has been obsoleted
>
>      docsBpi2CmtsAuthCmReset  OBJECT-TYPE
>            SYNTAX    INTEGER  {
>                                noResetRequested(1),
>                                invalidateAuth(2),
>                                sendAuthInvalid(3),
>                                invalidateTeks(4)
>                                }
>            MAX-ACCESS    read-write
>            STATUS        current
>
>    So the --Note: is out of sync with the actual status!?
>    What is it? If it IS obsoleted, then status should sya so,
>    And DESCRIPTION clause should explain why it was obsoleted.
>    And the ASN.1 comment line then of course is no longer needed.
>
> 7. I see:
>      docsBpi2CmtsAuthCACertIndexPtr    OBJECT-TYPE
>            SYNTAX        Integer32 (0..10000)
>    And find that a strange limit (range). And nowhere, not
> even in the
>    docsBpi2CmtsCACertTable do I see an explanation why that
> range makes
>    sense (assuming that it does).
>
> 8. When I see:
>            docsBpi2CmtsIpMulticastAddressType      InetAddressType,
>            docsBpi2CmtsIpMulticastAddress          InetAddress,
>            docsBpi2CmtsIpMulticastMaskType        InetAddressType,
>            docsBpi2CmtsIpMulticastMask            InetAddress,
>    I wonder if (in the same row)
> docsBpi2CmtsIpMulticastMaskType will ever
>    have a different value then docsBpi2CmtsIpMulticastAddressType !??
>    It seems to me that should NOT be allowed, cause otherwise I am not
>    sure how the ANDing of the Mask is going to work/happen.
>    So the next question then is why you do not do:
>            docsBpi2CmtsIpMulticastAddressType      InetAddressType,
>            docsBpi2CmtsIpMulticastAddress          InetAddress,
>            docsBpi2CmtsIpMulticastMask            InetAddress,
>    And let docsBpi2CmtsIpMulticastAddressType be the
> discriminator for both
>    InetAddresses. One less object, and less change for error/conflict.
>
>    But thinking even further, Possibly the best thing to do is to use
>            docsBpi2CmtsIpMulticastAddressType      InetAddressType,
>            docsBpi2CmtsIpMulticastAddress          InetAddress,
>            docsBpi2CmtsIpMulticastPrefixLength   
> InetAddressPrefixLength,
>    Are not such masks always setup that they basically
> specify a prefix length?
>    If so, then this is the way to do it with the TCs from
> INET-ADDRESS-MIB.
>
> 9. I see various uses of InetAddress as for example here:
>        docsBpi2CmtsIpMulticastAddress          OBJECT-TYPE
>            SYNTAX        InetAddress
>            MAX-ACCESS    read-create
>            STATUS        current
>            DESCRIPTION
>                  "This object represents the IP multicast address
>            to be mapped, in conjunction with
>            docsBpi2CmtsIpMulticastMask."
>    The TC for InetAddress (in RFC3291 or its follow on)
> clearly state that
>    you MUST specify which InetAddressType controls the format
> of this object
>    as per DESCRIPTION from InetAddress TC:
>          An InetAddress value is always interpreted within the context
>          of an InetAddressType value. Every usage of the InetAddress
>          textual convention is required to specify the InetAddressType
>          object which provides the context. ...
>
> 10. I see:
>      docsBpi2CmtsIpMulticastMapControl  OBJECT-TYPE
>            SYNTAX        RowStatus
>            MAX-ACCESS    read-create
>            STATUS        current
>            DESCRIPTION
>                "This object controls and reflects the IP multicast
>            address mapping entry.  There is no restriction on the
>            ability to change values in this row while the row is
>            active.  Inactive rows need not be timed out."
>    Mmm... that "need not be timed out" seems in conflict
> with the RowStatus
>    TC DESCRIPTION clause in RFC2579. Can you explain why this is?
>
>    Also, a RowSTatus object MUST specify in its DESCRIPTION
> clause under
>    which conditions
>    - the row can be activated
>    - which columns (if any) can bve changed while in the
> active state.
>    I am missing the first.
>
> 11. You specify:
>        --
>        -- The BPI+ MIB Conformance Statements (with a placeholder for
>        -- notifications)
>        --
>
>        docsBpi2Notification    OBJECT IDENTIFIER
>            ::= { docsBpi2MIB 2 }
>        docsBpi2Conformance OBJECT IDENTIFIER
>            ::= { docsBpi2MIB 3 }
>        docsBpi2Compliances OBJECT IDENTIFIER
>            ::= { docsBpi2Conformance 1 }
>        docsBpi2Groups      OBJECT IDENTIFIER
>            ::= { docsBpi2Conformance 2 }
>
>    Why not be (more) consistent with other MIB modules and follow the
>    suggested OID subtrees as per MIB guidelines,
>    draft-ietf-ops-mib-review-guidelines-03.txt, appendix D:
>        xxxMIB
>        |
>        +-- xxxNotifications(0)
>        +-- xxxObjects(1)
>        +-- xxxConformance(2)
>            |
>            +-- xxxCompliances(1)
>            +-- xxxGroups(2)
>    This is not mandatiory, but consistency is always useful/helpful
>
>
> Nits/administrativia:
>
> 1. The RFC editor wants all references to have at least one citation
>    in the document. ALso for the normative references to RFCs from
>    which you import. See MIB review guidelines, sect 3.5
>
>    You need to add a citation somehwere for [RFC3411], [RFC2021],
>    [RFC3291], [RFC2670]
>
> Thanks,
> Bert
>