[ipcdn] RE: Additional AD review: draft-ietf-ipcdn-bpiplus-mib-13.txt-> ID-14 pre-draft

["Eduardo Cardona" <[e-mail]>]

FYI,

This email was sent early today with an attachment of draft  BPI 14, 
It maybe in quarantine to verify viruses

This items will be presented by Jean-Francois Mule, Tuesday in IETF
IPCDN meeting 

Eduardo

-----Original Message-----
From: Eduardo Cardona 
Sent: Friday, July 30, 2004 9:46 AM
To: 'Wijnen, Bert (Bert)'; 'Ipcdn (E-mail)'
Subject: RE: Additional AD review: draft-ietf-ipcdn-bpiplus-mib-13.txt->
ID-14 pre-draft


Bert, 
Find a log with the comments for the issues 

I organize them in a sort of high to low priority, also attached is a
draft of the adds into a document to submit ti IETF before Augost 2 or
tomorrow,  with all the updates

Thanks

Eduardo


-------------------
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?

<edo>
The email lost....

-----Original Message-----
From: Woundy, Richard [mailto:[e-mail]] 
Sent: Wednesday, February 19, 2003 8:04 AM
To: 'Wijnen, Bert (Bert)'; IPCDN WG (E-mail)
Cc: Thomas Narten (E-mail); Erik Nordmark (E-mail); Randy Bush (E-mail)
Subject: RE: [ipcdn] InetAddress or PrefixLength as a mask


Bert,

Since I am the person that most likely influenced the BPI+ MIB's use 
of a netmask rather than a prefix length, I suppose I should directly 
answer your question. (Of course, that makes your suggestion about
putting the explanation in the DESCRIPTION clause all the wiser.)

The IPv6 addressing architecture is currently defined in RFC 2373. 
Section 2.7 describes the format of the IPv6 multicast addresses: 
8 bits of '11111111' for identification as multicast, 
4 bits of 'flags', 4 bits of 'scope', and 112 bits of 'group ID'. 
Five scope values are defined for node-local, link-local, site-local, 
organization-local, and global scopes. 
Section 2.7.2 shows how new IPv6 multicast addresses can be assigned, 
making reference to RFC 2375.

The draft draft-ietf-ipngwg-addr-arch-v3-11.txt, which updates RFC 2373,

defines six scope values: interface-local, link-local, admin-local,
site-local, 
organization-local, and global scopes.

Some of the permanently assigned IPv6 multicast addresses appear in RFC 
2375. This RFC includes all-scope addresses in section 3.0 -- these
multicast 
address assignments apply for all IPv6 multicast scope contexts.
Typically, these 
assignments are written as "FF0X:...". These assignments are referred to
as 
"Variable Scope Multicast Addresses" by IANA, 
<http://www.iana.org/assignments/ipv6-multicast-addresses>.

As an operator, I would strongly prefer to use one row in the BPI+ MIB
table to match each of these variable-scope permanently assigned
addresses. I want to avoid creating five to six rows (one per defined
multicast scope) or sixteen rows (one per potential multicast scope).
Unfortunately, every prefix of an IPv6 multicast address that contains
at least one bit of the 'group ID' MUST contain the entire 'flags' and
'scope' components. The only way to perform an address match based
solely on 'group ID' while ignoring the 'scope' is to use a
non-contiguous netmask.

If there is a better way to accomplish this, I would love to learn about
it.

-- Rich

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[e-mail]]
Sent: Tuesday, February 18, 2003 7:13 AM
To: Ipcdn (E-mail)
Cc: Thomas Narten (E-mail); Erik Nordmark (E-mail); Randy Bush (E-mail)
Subject: [ipcdn] InetAddress or PrefixLength as a mask


During the IPCDN WG interim meeting last week
I question why in 
      docsBpi2CmtsIpMulticastMask        OBJECT-TYPE
           SYNTAX         InetAddress
           MAX-ACCESS     read-create
           STATUS         current
           DESCRIPTION
      "This object represents the IP multicast address mask
      for this row.
      An IP multicast address matches this row if the logical
      AND of the address with docsBpi2CmtsIpMulticastMask is
      identical to the logical AND of
      docsBpi2CmtsIpMulticastAddr with
      docsBpi2CmtsIpMulticastMask."
      ::= { docsBpi2CmtsIpMulticastMapEntry 5 }

You specify the mask as an InetAddress and not as an
InetAddressPrefixLength. I was given some explanations, 
but I am not 100% sure I understood and I am not 100% sure
they are valid. 

Could the authors pls respond with an explanation (which I think should
also be inclued in the DESCRIPTION clause if it is accepted).

There may be other occurences of this in one ore more of your MIB
documents.

Thanks,
Bert 
_______________________________________________
IPCDN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn

_______________________________________________
IPCDN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn

End of email....

Added in section  2.1.2. Cable Modem Termination System

       In particular, docsBpi2CmtsIpMulticastMapTable defines 
       the object docsBpi2CmtsIpMulticastMask (non-contiguous 
       netmask) instead of the INET-ADDRESS-MIB MIB Module 
       [RFC3291] Textual Convention InetAddressPrefixLength. 
       This is to facilitate the assignment of same SAID for 
       a IPv6  multicast group ID prefix matching several/any 
       Ipv6 multicast scope types with a unique entry in this 
       table.
       e.g. To assign transient multicast group prefix 'Y' 
       to SAID 'z' for ANY multicast scope the non-contiguous 
       netmak will be FF10:Y
       see [RFC3513] for details on IPv6 addressing

Also a similar note as proposed for draft 13 comments (not included
ID-13 expecting resolution in this open discussion).

docsBpi2CmtsIpMulticastMask        OBJECT-TYPE
    DESCRIPTION
    "....
    Note: For IPv6 this object needs not to represent a 
    contiguous netmask, e.g. to associate a SAID to a  
    multicast group id with a the value of the field 
    multicast scope as a mapping criteria."





</edo>


-----------------
As a follow up to this, there was this comment from me:
> 
> 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.
> 
The first thing we found is that it is not so clear what the text means,

but it probably menas the same things as for other IF-MIB related
counters, 
i.e. (as also used in IF-MIB, RFC2863), it means:

            Discontinuities in the value of this counter can occur at
            re-initialization of the management system, and at other
            times as indicated by the value of
            ifCounterDiscontinuityTime.

And if that is indeed the case, then this new text would be MUCH better.

Now, when you added the text about discontinuities, it also makes it
more 
visible that one could really question if the use of ZeroBasedCounter32 
makes sense and if a regular Counter32 would not be much much better.

Have you read the ZeroBasedCounter32 TC and the text that explains what
this type 
of counter was meant for?

One comment from another MIB doctor is:
   A ZeroBasedCounter32 in a conceptual row which can experience
   discontinuities as part of its normal operational behaviour
   just seems a bit odd to me. I fail to see what the advantage of
   a ZeroBasedCounter32 in such a situation is.

  Another comment (in relation to ifCounterDiscontinuityTime) is that
  it would be very good to add some text (somewhere early on in the
draft) 
  that points to RFC2863, page 12, which has some good text about that
object. 
  As per the comment of another MIB Doctor:
  I think it would be extremely helpful to have a discussion what this
  means somewhere in the introductionary text together with a pointer to
  the relevant text in the IF-MIB RFCs (which has some paragraphs about
  this subject that are interesting to know for implementors).

  Looking at the MIB, the question that I have is the interaction of
  discontinuities with these ZeroBasedCounter32 objects. Does a
  discontinuity couse these counters to be reset to zero? The TC says
  that a zero based counter is set to zero(0) on creation and it has
  additional text that the intended usage is in tables where the index
  space is constantly changing. Does this apply here?

Of course you have clarified (but in some prose early on in the draft 
may want to re-emphasize) that the ZeroBasedCounter32 only MUST be set 
to zero at row creation. But some additional discussion seems usefull.


<edo> 

Added the suggested Discontinuity statement from RFC 2863
Also a new section 

For the discussions if really ZeroBasedCounter32 are needed the section
below may clean up some of the concerns.



2.3 BPI+ MIB module relationship with The Interfaces Group MIB

The BPI+ MIB module is the management framework of Baseline Privacy Plus
Interface Specification [1], which provides the MAC layer (Media Access
Control) security Services of DOCSIS. The BPI+ MIB module objects are
organized as extensions of the Radio Frequency (RF) Interface Management
[RFC2670]. 

The MIB table structures of this MIB Module are extensions of the 
DOCSIS CATV (Community Antenna Television) MAC layer interface
(DocsCableMaclayer by [IANA]). In particular the provisions of the
Interface Group MIB[RFC2863] for counters discontinuities and 
system re-initialization apply to CM and CMTS to validate the 
difference between two consecutive counters polls.

In the case of the CM, BPI+ mode is not enabled until the CM properly 
registers and a new BPI+ FSM (Full State Machine) is initialized. When
CM reboots, counters defined in docsBpi2CmBaseTable, 
docsBpi2CmTEKTable and docsBpi2CmIpMulticastMapTable are not retained in
memory and start at zero. The syntax ZeroBasedCounter32 per 
[RFC 2021] is used for this counters


In the case of the CMTS There are two types of counters: 
    o   Counters defined in docsBpi2CmtsBaseTable which are 
        Interface extensions for the BPI+ management of the 
        Interface are regular Counter32 objects.
    o   Entries in tables docsBpi2CmtsAuthTable, docsBpi2CmtsTEKTable
        and docsBpi2CmtsIpMulticastMapTable are created and deleted 
        dynamically by the management system or by configuration.
        Counters defined in these tables are of type 
        ZeroBasedCounter32 and set to value zero at creation time.


All counters requirements are in the scope of 32 bits counters needs 
in terms of minimum time to wrap-up [RFC2863] due the fact that those 
counters are related to events for the BPI+_FSM (e.g. request, replies,
rejects, etc.) and their frequency occurrence (see [1] for configuration
options and timeouts).

As a clarification note, ZeroBasedCounters32 are not set back to zero
when 
discontinuities of the interface associated to the entries.


</edo>

------------------


   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. !!

<edo>
similar to the requirements of docsBpi2CmtsCACert, ThumbPrint
Certificate validation 
is an optional feature on DOCSIS, The CMTS is in the freedom to report
the value 
of either docsBpi2CmtsCACert (constly -whole Certificate-) or the
ThumbPrint object .  the other option could be to define a optional
group (only one object)
 
        Note: The zero-length OCTET STRING must be returned, on
        reads, if the CA certificate thumb print is not retained 
        in the CMTS."

</edo>

--------------------

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!

<edo>
The initial intentions of the authors I believe was to avoid holes in 
docsBpi2CmtsCACertEntry; Not being a valid semantic reason, Updated to
say:

        "Note: This object has no meaning for CMs running in BPI 
        mode, therefore this object is not instantiated for entries
        associated to those CMs."

</edo> 



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

  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>
done
</edo>


---------------------

As a follow up to this, there was this comment from me:
> 
> 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.
> 
The first thing we found is that it is not so clear what the text means,
but it probably menas the same things as for other IF-MIB related
counters, i.e. (as also used in IF-MIB, RFC2863), it means:

            Discontinuities in the value of this counter can occur at
            re-initialization of the management system, and at other
            times as indicated by the value of
            ifCounterDiscontinuityTime.

And if that is indeed the case, then this new text would be MUCH better.

Now, when you added the text about discontinuities, it also makes it
more visible that one could really question if the use of
ZeroBasedCounter32 makes sense and if a regular Counter32 would not be
much much better.

Have you read the ZeroBasedCounter32 TC and the text that explains what
this type of counter was meant for?

One comment from another MIB doctor is:
   A ZeroBasedCounter32 in a conceptual row which can experience
   discontinuities as part of its normal operational behaviour
   just seems a bit odd to me. I fail to see what the advantage of
   a ZeroBasedCounter32 in such a situation is.

Another comment (in relation to ifCounterDiscontinuityTime) is that it 
  would be very good to add some text (somewhere early on in the draft) 
  that points to RFC2863, page 12, which has some good text about that
  object. As per the comment of another MIB Doctor:
  I think it would be extremely helpful to have a discussion what this
  means somewhere in the introductionary text together with a pointer to
  the relevant text in the IF-MIB RFCs (which has some paragraphs about
  this subject that are interesting to know for implementors).

  Looking at the MIB, the question that I have is the interaction of
  discontinuities with these ZeroBasedCounter32 objects. Does a
  discontinuity couse these counters to be reset to zero? The TC says
  that a zero based counter is set to zero(0) on creation and it has
  additional text that the intended usage is in tables where the index
  space is constantly changing. Does this apply here?

Of course you have clarified (but in some prose early on in the draft
may want to re-emphasize) that the ZeroBasedCounter32 only MUST be set
to zero at row creation. But some additional discussion seems usefull.

<edo>
- Check in which draft the "since reboot was added."

</edo>

--------------
Some quick notes, Here we go:

1. SMICng tells me:
    W: f(ipcdnbpi2.mi2), (3142,17) Duplicate item
"docsBpi2CmtsIpMulticastAddressType"
       in compliances list for module "DOCS-IETF-BPI2-MIB"
    W: f(ipcdnbpi2.mi2), (3152,17) Duplicate item
"docsBpi2CmtsIpMulticastAddress"
       in compliances list for module "DOCS-IETF-BPI2-MIB"
   Seems you duplicated something.

<edo>
cleaned
<edo>

2.      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
           A created row can be timed out." 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'.


           There is no restriction on the ability to change values in
           this row while the row is active."
           ::= { docsBpi2CmtsIpMulticastMapEntry 14 }

    Last sentence in DESCRIPTION clause is duplicate of 2nd sentence.
    Are you sure value is 'notReady' in that case? Could be notInService
    too, no? Why specify it. I.e. I would remove
           otherwise the status of this object is 'notReady' <edo> done
</edo>

3.      docsBpi2CmtsIpMulticastMapStorageType     OBJECT-TYPE
           SYNTAX         StorageType
           MAX-ACCESS     read-only
           STATUS         current
           DESCRIPTION
                "The storage type for this conceptual row."

   You must (according to RFC 2579) add txt to stat which (if any)
writable
   objects MUST be writeable even for permanent entries. See 2579 fo
details.

<edo>
By compliance this table could be read-only, 
StorageType is read-only. That offers the flexibility for the
implementer to configure the BPI+ multiple options of mapping multicast
groups to SAID 
Types primary, static, or dynamic.

Implementer can always choose to assign SNMP created entries as
'nonVolatile' and leave 'permanent' for administrative commands, without
update options. 
Added :
              A SNMP SET for of any writable object with a rows
        StorageType of 'permanent' returns an error 'notWritable'."

        

</edo>

_______________________________________________
IPCDN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn