Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-13.txt

From: [email-masked]
Date: Thu, 22 Jul 2004 15:42:28 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP over Cable Data Network Working Group of the IETF.

	Title		: Management Information Base for DOCSIS Cable Modems and 
			  Cable Modem Termination Systems for Baseline Privacy Plus
	Author(s)	: S. Green, et al.
	Filename	: draft-ietf-ipcdn-bpiplus-mib-13.txt
	Pages		: 83
	Date		: 2004-7-22
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it defines a set of managed objects for SNMP based
   management of the Baseline Privacy Plus features of DOCSIS1.1 and
   DOCSIS 2.0 compliant Cable Modems and Cable Modem Termination
   Systems.
   This memo is a product of the IPCDN working group within the
   Internet Engineering Task Force.  Comments are solicited and
   should be Addressed to the working group's mailing list at
   [email-masked] and/or the authors.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-bpiplus-mib-13.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipcdn-bpiplus-mib-13.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ipcdn-bpiplus-mib-13.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Eduardo Cardona" <[email-masked]>
Date: Mon, 26 Jul 2004 09:35:44 -0600

Bert, IPCDN participants, 

as you may noticed a new draft (13) was published on time for I-D cutoff
for the upcoming meeting

Bert, 
Thanks for all the detailed comments, below are the clarification notes
added to the published draft.

>From the POV of significant changes I only see item 1. as a possible
change of requirements by defining persistence  where the Draft was not
clear:
Recently updates to BPI OSS requirements introduces persistent
requirement to configurable structures like
docsBpi2CmtsProvisionedCmCertEntry, docsBpi2CmtsCACertEntry
In a generalized way MULTICAST SAID assignments and CM authorization for
static Multicast are the areas where persistent requirements have been
added to maintain consistency around user configured data.

Below is the list of items in your review with the appropriate comments
as are now in draft-13

Thanks

Eduardo

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 behavior is w.r.t. persistency of such
   objects. SO what happens after a restart/reboot?
<edo>
read-write objects: 
docsBpi2CmAuthReset:
N/A testing purposes see description
docsBpi2CmDeviceCmCert:
 -added persistence, already a requirement that might be implicit in
current description but not explicit.

docsBpi2CmtsDefaultAuthLifetime 
docsBpi2CmtsDefaultTEKLifetime
Added to both objects:
"This object value persist after reinitialization of the managed
system."

docsBpi2CmtsDefaultSelfSignedManufCertTrust:
BPI spec calls for a testing object not recommended as an operational
parameter Do not persist Description clarified "this" instead of "the"

docsBpi2CmtsCheckCertValidityPeriods:
With a period validity of 20 years and re-issued certificated within 2
years of expiration do not indicates any usage of this object rather
than testing No need of persistence. added 
"This object value needs not to persist after reinitialization of the 
managed system.."

docsBpi2CodeCvcUpdate
added first sentence:
"then the content of this object is discarded."
 See BPI spec pointed by REFERENCE section D.3.3.2.2.

read-write objects in non-dynamic tables:

docsBpi2CmtsAuthEntry 
Entries are deleted after CM de-registers
docsBpi2CmtsTEKEntry
Entries are deleted when the SAID expires

read-create: 
docsBpi2CmtsMulticastAuthEntry, docsBpi2CmtsIpMulticastMapEntry

A Multicast Group ca be mapped by the CMTS to primary. Static or dynamic
SA. 
For the MulticastMapEntry 

it is not expected to have a multicast group mapped to a primary SA to
persist after reboot

Typically a static SA mapped to a multicast group is required to
persist, It implies entries in MulticastAuthEntry for specific
authorized CMs

Operator may decide also to create a MulticastMapEntry with SAIDType
dynamic to track the multicast group with a specific SAID.

If that condition is valid, there is no way to know a CMTS dynamically
created MulticastMapEntry vs a provisioned one

- It requires the introduction of StorageType in MulticastMapTable with
syntax read-only:

depending on CMTS created or provisioned entries the row storage type
could be 
defined as :
e.g SAIDType = primary will be volatile
    SAIDtype = static will be non-volatile
    SAIDType = dynamic:non-volatile for provisioned entries, 
               volatile for CMTS dynamically mapped multicast group. The
main advantage is to allow the BPI and OSS spec to concrete define the
management requirements for this cases, including the mandate of
persistence.

MulticastAuthEntry form the point of view of the MIB management
perspective and operations should be stated as persistent explicitly.

docsBpi2CmtsMulticastAuthEntry
Added : SAIDs of type static 

        Row entries persist after reinitialization of 
        the managed system.

docsBpi2CmtsIpMulticastMapEntry
added:
   docsBpi2CmtsIpMulticastMapStorageType     OBJECT-TYPE
        SYNTAX         StorageType
        MAX-ACCESS     read-only
        STATUS         current
        DESCRIPTION
             "The storage type for this conceptual row."
        ::= { docsBpi2CmtsIpMulticastMapEntry 15 }

docsBpi2CmtsIpMulticastSAType
added:
  SNMP created entries set this object by default
        to 'static' if not set at row creation.

docsBpi2CmtsProvisionedCmCertEntry
Added:(updates to OSSI specification: 

        Row entries persist after reinitialization of 
        the managed system.
        REFERENCE 
             "Data-Over-Cable Service Interface Specifications:
        Operations Support System Interface Specification
        SP-OSSIv2.0-I05-040407, Section 6.2.14"

docsBpi2CmtsCACertEntry
Added (updates to OSSI specification: 

        Row entries with trust status 'trusted', 'untrusted',
        or 'root' persist after reinitialization of the managed
        system."
        REFERENCE 
             "Data-Over-Cable Service Interface Specifications:
        Operations Support System Interface Specification
        SP-OSSIv2.0-I05-040407, Section 6.2.14"

</edo>

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.

<edo>

        docsBpi2CmAuthentInfos
        docsBpi2CmAuthRequests
        docsBpi2CmAuthReplies 
        docsBpi2CmAuthRejects 
        docsBpi2CmAuthInvalids
discontinuity is sysUpTime
removed counts since reboot
added:
"Reinitialization of this counter occurs at boot time.
Discontinuities of this counter are indicated by sysUpTime."

        docsBpi2CmTEKKeyRequests
        docsBpi2CmTEKKeyReplies
        docsBpi2CmTEKKeyRejects
        docsBpi2CmTEKInvalids
        docsBpi2CmTEKAuthPends
discontinuity is sysUpTime
removed since registration
added:
"Reinitialization of this counter occurs at boot time.
Discontinuities of this counter are indicated by sysUpTime."

        docsBpi2CmIpMulticastSAMapRequests
        docsBpi2CmIpMulticastSAMapReplies
        docsBpi2CmIpMulticastSAMapRejects
Delete:
"Since entry creation"
Add:
"Discontinuities of this counter are indicated by sysUpTime."

        docsBpi2CmtsAuthentInfos
        docsBpi2CmtsAuthRequests
        docsBpi2CmtsAuthReplies
        docsBpi2CmtsAuthRejects
        docsBpi2CmtsAuthInvalids
        docsBpi2CmtsSAMapRequests
        docsBpi2CmtsSAMapReplies
        docsBpi2CmtsSAMapRejects

Add:
"Discontinuities of this counter are indicated by sysUpTime and
ifCounterDiscontinuityTime for the associated ifIndex."
Delete:
"since entry creation"

        docsBpi2CmtsAuthCmInfos
        docsBpi2CmtsAuthCmRequests
        docsBpi2CmtsAuthCmReplies
        docsBpi2CmtsAuthCmRejects
        docsBpi2CmtsAuthCmInvalids

updated Entry object to indicate MAC interface dependency for IfIndex
"Discontinuities of this counter are indicated by sysUpTime and
ifCounterDiscontinuityTime for the associated ifIndex."
Delete:
"since entry creation"

        docsBpi2CmtsKeyRequests
        docsBpi2CmtsKeyReplies
        docsBpi2CmtsKeyRejects
        docsBpi2CmtsTEKInvalids
"Discontinuities of this counter are indicated by sysUpTime and
ifCounterDiscontinuityTime for the associated ifIndex."
Delete:
"since registration"

        docsBpi2CmtsIpMulticastSAMapRequests
        docsBpi2CmtsIpMulticastSAMapReplies
        docsBpi2CmtsIpMulticastSAMapRejects
Added:
"Discontinuities of this counter are indicated by sysUpTime and
ifCounterDiscontinuityTime for the associated ifIndex."
Delete:
"since entry creation"
</edo>

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.

<edo>
Added: 

   docsBpi2CodeCvcUpdate    OBJECT-TYPE
        Reading this object always returns the zero-length string."

   docsBpi2CmtsCACertThumbprint OBJECT-TYPE
        Note: The zero-length string must be returned if this object is
        not supported by the CMTS."

   docsBpi2CmtsCACert  OBJECT-TYPE
        Note: The zero-length string must be returned, on reads, if the
        entire certificate is not retained in the CMTS."

   docsBpi2CmtsProvisionedCmCert OBJECT-TYPE
        Note: The zero-length string must be returned, on reads, if the
        entire certificate is not retained in the CMTS."

   docsBpi2CmtsAuthBpkmCmCert    OBJECT-TYPE
        Note: The zero-length string must be returned if the entire
        certificate is not retained in the CMTS."

   docsBpi2CmDeviceCmCert   OBJECT-TYPE
        Note:  This object can be set only when the value is the
        zero-length string.  Once the object contains the 
        certificate, its access MUST be read-only."
</edo>

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.

A CMTS keeps track of the old and new authentication keys for example to
do seamless traffic Key updates (using a hand-shacking algorithm based
on the authentication key (old or new), CMs running in 1.0 mode follows
BPI protocol (RFC 3083) which has no concept of old/ new key expire
time, therefore the CMTS only have to track the most recent
authentication key expire to validate outstanding BPI security requests.

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

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.

<edo>

The note applies to docsBpi2CmtsAuthCmGraceTime which was already
removed
In draft 12
 
Draft 11
docsBpi2CmtsAuthCmLifetime  ::= { docsBpi2CmtsAuthEntry 7 }
-- Note: the following object has been obsoleted 
docsBpi2CmtsAuthCmGraceTime ::= { docsBpi2CmtsAuthEntry 8 }
docsBpi2CmtsAuthCmReset     ::= { docsBpi2CmtsAuthEntry 9 }

docsBpi2CmtsAuthCmLifetime  ::= { docsBpi2CmtsAuthEntry 7 }
-- Note: the following object has been obsoleted  -- remove
docsBpi2CmtsAuthCmReset     ::= { docsBpi2CmtsAuthEntry 8 }

</edo>

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

<edo>
docsBpi2CmtsAuthCACertIndexPtr follows the  size of
docsBpi2CmtsCACertIndex  
Changed to 
        SYNTAX         Unsigned32 (1..4294967295)
docsBpi2CmIpMulticastIndex, docsBpi2CmtsIpMulticastIndex
        SYNTAX         Unsigned32 (1..4294967295)
</edo>

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

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

From: Woundy, Richard [mailto:[email-masked]] 
Sent: Wednesday, February 19, 2003 8:04 AM
To: 'Wijnen, Bert (Bert)'; IPCDN WG (E-mail)
Cc: Thomas Narten (E-mail); Erik Nordmark (E-mail); Randy Bush (E-mail)
Subject: RE: [ipcdn] InetAddress or PrefixLength as a mask

Perhaps a clarification note for object multicast netmask objects.

"This object needs not to represent a contiguous netmask i.e. to assign
to same multicast SAID multicast IPv6 addresses based on multicast
scopes and/or multicast group Ids."

added to docsBpi2CmtsIpMulticastAddress and docsBpi2CmtsIpMulticastMask:
"The address type of this object is specified by the value of the object

        docsBpi2CmtsIpMulticastAddressType.

Deleted object docsBpi2CmtsIpMulticastMaskType

</edo>

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.

<edo>
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'".
</edo>

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

<edo>
Updated to follow the OPS recommendations
   docsBpi2Notification     OBJECT IDENTIFIER
        ::= { docsBpi2MIB 0 }
   docsBpi2Conformance OBJECT IDENTIFIER
        ::= { docsBpi2MIB 2 }
</edo>

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.

<edo>
Removed the prohibition to age out inactive row entries.
Removed the sentence " if a row has ever been activated, a destroy
setting need not succeed."

             "Standard RowStatus objects except:
        a) if a row has ever been activated,
        a set to docsBpi2CmtsCACert need not succeed,

changed to:

             " The status of this conceptual row. An attempt
        to set writable columnar values while this row is active 
        behaves as follows:
        - Sets to the object docsBpi2CmtsCACertTrust are allowed.
        - Sets to the object docsBpi2CmtsCACert will return an error
          inconsistentValue'."
<edo>

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]

<edo>
Added references
</edo>

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 <CR>
           (carriage return) <LF> (line feed) ASCII characters.
           Ordering of fields present must conform to:

           organizationName <CR> <LF>
           countryName <CR> <LF>

    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 <CR>
           (carriage return) <LF> (line feed) ASCII characters.

    with:

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

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

<edo>

</edo>

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?

<edo>
Added in description 
"otherwise an error 'inconsistentValue' 
        is returned"
</edo>

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?
<edo>
Added a note in the security section

BPI+ Encryption Algorithms:
BPI+ Traffic Encryption Keys TEK uses DES 56 or 40 bits encryption
ciphers, due their cryptographic strength weakness, future revisions
of BPI+ specification [1] should introduce advanced encryption 
algorithms to overcome the progress in cheaper and faster decryption
tools. CM BPI+ Authentication algorithms uses triple DES, which
guarantees strong BPI+ Authentication Traffic encryption keys updates

</edo>

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?

<edo>
"after setting the object"
Changed to: 
"after setting this object"
</edo>

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 26 Jul 2004 23:30:00 +0200

Mmm, in your response I see:

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:

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:
  <edo>
  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:
    Mmm... that "need not be timed out" seems in conflict with the RowStatus

    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.

  <edo>

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'

</edo>
Thanks,
Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 27 Jul 2004 12:29:27 +0200

> 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