Subject: Changes included in the 2/16 BPI MIB

From: Rich Woundy <[email-masked]>
Date: Wed, 16 Feb 2000 19:38:11 -0500

Folks,

The last changes in the BPI MIB and internet draft were prompted by
comments from Kaz Ozawa, [email-masked].

In this email, I have copied his comments, and described what I did to the
internet draft as a result.

>One question on docsBpiIpMulticastPrefixLength
>
>I assume that the PrefixLength makes the mask as follows.
>
>0 -  mask of 0x00000000
>1 -  mask of 0x80000000
>8 -  mask of 0xff000000
>32 - mask of 0xffffffff
>
>Then compares { actuall IP Multicast Address AND mask }
>and { docsBpiIpMulticastAddress AND mask }
>
>Is this correct ?

I changed the descriptions of docsBpiIpMulticastAddress and
docsBpiIpMulticastPrefixLength to make the multicast address and prefix
length semantics very clear (I hope).

The new description for docsBpiIpMulticastAddress is:
"This object represents the IP multicast address (prefix) to be mapped by
this row, in conjunction with docsBpiIpMulticastPrefixLength."

The new description for docsBpiIpMulticastPrefixLength is:
"This object represents the IP multicast address prefix length for this
row. The value of this object represents the length in bits of
docsBpiIpMulticastAddress for multicast address comparisons, using
big-endian ordering. An IP multicast address matches this row if the
(docsBpiIpMulticastPrefixLength) most significant bits of the IP multicast
address and of the (docsBpiIpMulticastAddress) are identical. This object
is similar in usage to an IP address mask. The value 0 corresponds to IP
address mask 0.0.0.0, the value 1 corresponds to IP address mask 128.0.0.0,
the value 8 corresponds to IP address mask 255.0.0.0, and the value 32
corresponds to IP
address mask 255.255.255.255."

>section 2.7
>According to CableLabs' definition, 
>"Data-Over-Cable Service Interface Specifications"
>instead of "Data Over Cable Interface Specification"

I fixed this as Kaz suggested.

>section 3.2, 2nd bullet says;
>  The Baseline Privacy management interface needs to support
>  operator configuration of Authorization and TEK Finite State
>  Machine (FSM) parameters, for performance tuning and security
>  incident handling.  The CMTS MUST support configuring and
>  viewing all FSM-related parameters, including baseline privacy
>  status (enabled or disabled), key lifetimes, key grace times,
>  and state timeout values.  The CM MUST support viewing these
>  parameters where possible.
>
>I understand that, while the BPI MIB does not support configuring 
>the baseline privacy status, etc, I think the above paragraph is 
>a general requirement for OSSI and the above paragraph is fine.
>(If the above paragraph is a requirement for the MIB, it may
>be better to remove "configuring and".)

I changed the offending sentence to say:
"The CMTS MUST support viewing (and configuring if possible) all
FSM-related parameters, including..."

>section 6, References
>[18] through [21], the URLs for these documents have been 
>changed.  I think we only be able to specify
>   http://www.cablemodem.com/
>for all of these 4 documents.

I fixed this as Kaz suggested. I forgot about Livelink. :^(

>Many objects contain "Note: this object will be read-write
>accessible only after....." in their DESCRIPTION.  While this is 
>not a technical problem at all, they can be removed now.....
>But I'm not sure.

I removed these sentences from various object descriptions, as Kaz suggested.

>docsBpiCmTEKEntry
>If I understand correctly, the entry is only for unicast and
>we should remove "or multicast" from DESCRIPTION.

I changed the description of docsBpiCmTEKEntry to:
"Each entry contains objects describing the TEK association attributes of
one SID. The CM MUST create one entry per unicast SID, regardless of
whether the SID was obtained from a Registration Response message, or from
an Authorization Reply message."

-- Rich