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

From: "Holborow, Clive (SD-EX)" <[email-masked]>
Date: Thu, 09 Nov 2000 18:15:15 -0500

It seems the OSS spec. writers need to talk to the BPI+ spec writers.
See p146 of sp-bpi+-i05-000714.  Item b) says in part:
"..., a CMTS with Baseline Privacy Plus MUST be capable of falling back into
a Baseline Privacy compatible mode of operation."

Is this possible without support of the BPI MIB?
The BPI MIB is all 1.0 CMs know about, and it has always been required that
a 1.1 CMTS be able to simultaneously support 1.0 and 1.1 CMs.

The diagram on p37 of the 1.1 OSS spec makes it clear that 1.1 CMs must
support both BPI and BPI+ MIBs.
It doesn't make sense to me that the 1.1 CMTS does not also need to support
both MIBs, since it should support a 1.1 CM operating in 1.0/BPI mode.

Clive Holborow
Motorola

>  -----Original Message-----
>  From: Rich Woundy [mailto:[email-masked]]
>  Sent: Thursday, November 09, 2000 12:22 PM
>  To: Ziper, Anna; [email-masked]
>  Subject: RE: [ipcdn] possible issue with new version of BPI MIB:
>  draft-iet f-ipcdn-mcns-bpi-mib-02.txt
>  
>  
>  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
>  
>  At 11:30 AM 11/9/00 -0800, Ziper, Anna wrote:
>  
>  >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
>  

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

---

From: Rich Woundy <[email-masked]>
Date: Thu, 09 Nov 2000 20:40:23 -0500

Clive,

You make a good argument. A DOCSIS 1.1 CMTS probably ought to implement 
both the BPI MIB and the BPI+ MIB, in anticipation of the simultaneous 
management of both DOCSIS 1.0 and 1.1 modems on the CMTS side. That would 
include the docsBpiCmtsBaseTable, docsBpiCmtsAuthTable, and 
docsBpiCmtsTEKTable, but hopefully *not* docsBpiIpMulticastMapTable nor 
docsBpiMulticastAuthTable (assuming that downstream multicast encryption is 
restricted to DOCSIS 1.1/BPI+ CMs).

Does anyone disagree?

However, my statement ("a DOCSIS 1.1 CMTS is only required to support the 
BPI+ MIB") is still literally true, until someone submits an ECR against 
the DOCSIS 1.1 OSS spec.

I think this issue has to be resolved on the docsis-oss mailing list.

-- Rich