Subject: RE: "Final" BPI (not BPI+) MIB

From: Kazuyoshi Ozawa <[email-masked]>
Date: Thu, 3 Feb 2000 21:11:00 -0700

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 ?

Thanks,
kaz

> -----Original Message-----
> From: Rich Woundy [mailto:[email-masked]]
> Sent: Monday, January 31, 2000 10:30 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: "Final" BPI (not BPI+) MIB
> 
> 
> Folks,
> 
> I have attached what I hope to be the final DOCSIS Baseline 
> Privacy MIB
> (for pre-BPI+ modems). Again, it has been verified using 
> smicng. I will
> followup this note with the proposed Internet draft.
> 
> The differences from the January 7, 2000 version are:
> 
> 1. Commented out some "relaxations on mandatory ranges" in 
> the compliances
> statements, since these relaxations are unnecessary for read-only MIB
> objects (each "relaxation" shrinks the legal value range of 
> each object).
> This affects compliance statements for docsBpiCmAuthGraceTime,
> docsBpiCmTEKGraceTime, docsBpiCmtsAuthCmGraceTime, and
> docsBpiCmtsTEKGraceTime.
> 2. Updated numbering of external references (new 
> bibliography) and other
> minor cleanup, to support the new internet draft.
> 
> Please send comments by Friday morning. There should be no 
> real surprises
> here.
> 
> -- Rich
> 
>

---

From: Kazuyoshi Ozawa <[email-masked]>
Date: Thu, 3 Feb 2000 21:36:33 -0700

2 minor comments.

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

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

Thanks,
kaz

---

From: Rich Woundy <[email-masked]>
Date: Fri, 04 Feb 2000 00:54:23 -0500

Kaz,

Your interpretation is correct. Does this need to be clarified in the MIB?

-- Rich