[ipcdn] RE: Additional AD review: draft-ietf-ipcdn-bpiplus-mib-13.txt-> ID-14 pre-draft
"Eduardo Cardona" <e.cardona@CableLabs.com> Tue, 03 August 2004 14:06 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09787 for <ipcdn-archive@ietf.org>; Tue, 3 Aug 2004 10:06:26 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brzz0-0001wu-ED for ipcdn-archive@ietf.org; Tue, 03 Aug 2004 10:09:39 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrzkH-0001j9-PY; Tue, 03 Aug 2004 09:54:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqZbM-0005v9-Dn for ipcdn@megatron.ietf.org; Fri, 30 Jul 2004 11:47:20 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15274 for <ipcdn@ietf.org>; Fri, 30 Jul 2004 11:47:16 -0400 (EDT)
Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqZdU-0001eG-Ss for ipcdn@ietf.org; Fri, 30 Jul 2004 11:49:39 -0400
Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i6UFkZc0026057; Fri, 30 Jul 2004 09:46:37 -0600 (MDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4764C.64BF842B"
Date: Fri, 30 Jul 2004 09:46:35 -0600
Message-ID: <5259D0D7419C6149B347837A2E64F46F03E670@srvxchg.cablelabs.com>
X-MS-Has-Attach: yes
Thread-Topic: Additional AD review: draft-ietf-ipcdn-bpiplus-mib-13.txt-> ID-14 pre-draft
Thread-Index: AcRzxPpjI4oVQMDyRJeBNLbstGf1KgChlFtQ
From: Eduardo Cardona <e.cardona@CableLabs.com>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, "Ipcdn (E-mail)" <ipcdn@ietf.org>
X-Approved: ondar
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9db87eb11b9869832d2de8ef28458c63
X-Mailman-Approved-At: Tue, 03 Aug 2004 09:54:22 -0400
Subject: [ipcdn] RE: Additional AD review: draft-ietf-ipcdn-bpiplus-mib-13.txt-> ID-14 pre-draft
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=subscribe>
Sender: ipcdn-bounces@ietf.org
Errors-To: ipcdn-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a8eaabcce1af2723c6834a174256ad2
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:Richard_Woundy@cable.comcast.com] 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:bwijnen@lucent.com] 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 IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org 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 IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn
- [ipcdn] RE: Additional AD review: draft-ietf-ipcd… Eduardo Cardona
- [ipcdn] RE: Additional AD review: draft-ietf-ipcd… Eduardo Cardona