Subject: RE: [ipcdn] possible issue with new version of BPI MIB: draft-iet f-ipcdn-mcns-bpi-mib-02.txt

From: "Ziper, Anna" <[email-masked]>
Date: Thu, 9 Nov 2000 11:30:53 -0800

Hi,

A DOCSIS1.1 CMTS is only required to support BPI+ MIB, and not BPI MIB.
Is it right?

Thanks,
Anna

-----Original Message-----
From: Rich Woundy [mailto:[email-masked]]
Sent: Monday, November 06, 2000 3:11 PM
To: [email-masked]
Subject: [ipcdn] possible issue with new version of BPI MIB:
draft-ietf-ipcdn-mcns-bpi-mib-02.txt

Folks,

I just submitted a new version of the BPI MIB, 
draft-ietf-ipcdn-mcns-bpi-mib-02.txt, as an internet draft. This revision 
is as a result of a review with the IETF MIB doctor. Most of the changes 
were minor textual changes, and will be listed in a separate email.

However, I did want to point out a particular modification to the 
DESCRIPTION of two MIB objects. In particular, I added the sentence, "There 
is no restriction on the ability to change values in this row while the row 
is active", to the two RowStatus objects in the multicast portion of the 
BPI MIB:

docsBpiIpMulticastMapControl	OBJECT-TYPE
SYNTAX				RowStatus
MAX-ACCESS			read-create
STATUS				current
DESCRIPTION
"This object controls and reflects the IP multicast address prefix
mapping entry. There is no restriction on the ability to change values
in this row while the row is active."
::= { docsBpiIpMulticastMapEntry 4 }

docsBpiMulticastAuthControl	OBJECT-TYPE
SYNTAX				RowStatus
MAX-ACCESS			read-create
STATUS				current
DESCRIPTION
"This object controls and reflects the CM authorization for each
multicast SID. There is no restriction on the ability to change
values in this row while the row is active."
::= { docsBpiMulticastAuthEntry 3 }

According to the definition of "RowStatus" in RFC 2579, the DESCRIPTION 
clause of a RowStatus column needs to "specify whether the status column 
must not be `active' in order for the value of some other column of the 
same conceptual row to be modified."

I followed the example of the Cable Device MIB, RFC 2669, which typically 
specifies that values in a row of a table can be changed while the row is 
active. For example, see docsDevNmAccessStatus, docsDevFilterLLCStatus, 
docsDevFilterIpStatus, and docsDevFilterTosStatus. A counter-example is the 
docsIfQosProfStatus in RFC 2670, which does not permit modifications when 
there are dependencies from the docsIfCmServiceTable and 
docsIfCmtsServiceTable on the docsIfQosProfileTable.

My opinion was to follow the lead of the Cable Device MIB.

Does anyone on the mailing list disagree?

-- Richard Woundy

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

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

---

From: Azlina Ahmad <[email-masked]>
Date: Thu, 09 Nov 2000 11:54:50 -0800

Correct.

Azlina

---

From: Rich Woundy <[email-masked]>
Date: Thu, 09 Nov 2000 15:22:12 -0500

Yes, a DOCSIS 1.1 CMTS is only required to support the BPI+ MIB, per the 
DOCSIS OSS specification.

See the CMTS column on pages 66-68 of SP-OSSIv1.1-I02-000714, 
<http://www.cablemodem.com/SP-OSSIv1.1-I02-000714.pdf>.

-- Rich