RE: I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-13.txt

Mmm, in your response I see:

   "Discontinuities of this counter are indicated by sysUpTime and
    ifCounterDiscontinuityTime for the associated ifIndex."

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

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

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