RE: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfUpchannelStatus
"Eduardo Cardona" <e.cardona@CableLabs.com> Wed, 24 August 2005 16:05 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xkh-0002Hc-Ue; Wed, 24 Aug 2005 12:05:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xke-0002Gx-1x for ipcdn@megatron.ietf.org; Wed, 24 Aug 2005 12:05:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00659 for <ipcdn@ietf.org>; Wed, 24 Aug 2005 12:05:17 -0400 (EDT)
Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7xkz-0005aZ-20 for ipcdn@ietf.org; Wed, 24 Aug 2005 12:05:41 -0400
Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7OG53lE006138; Wed, 24 Aug 2005 10:05:04 -0600 (MDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfUpchannelStatus
Date: Wed, 24 Aug 2005 10:05:38 -0600
Message-ID: <5259D0D7419C6149B347837A2E64F46FF707C9@srvxchg.cablelabs.com>
Thread-Topic: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfUpchannelStatus
Thread-Index: AcWjO0pm5pwkSOJYSvioQGI2vEiOhgE4cWKAACga3IA=
From: Eduardo Cardona <e.cardona@CableLabs.com>
To: Eduardo Cardona <e.cardona@CableLabs.com>, "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, david.raftus@ati.com
X-Approved: ondar
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4863a9796402a44fdb52482f353618fe
Content-Transfer-Encoding: quoted-printable
Cc: "Ipcdn (E-mail)" <ipcdn@ietf.org>
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
Bert, Here is my first of a set of postings answering your questions, I am keeping them in groups to not be very extensive and keep them organized way As I am adding the proposed changes to the draft as we speak If they are valid for MIB Doctors and deviations are "negligible" of the IPCN technical requirements I guess with your consent we can proceed to have a draft before IESG if that is your preference. Topic: docsIfUpChannelStatus: Below is an intend to clear the definitions and present then in a ordered manner. RFC 2670 does not have RowStatus Upstream physical interfaces are hardware Upstream receivers (CMTS) components associated to the implementation with is own organization and constraints to RF MAC interfaces - MAC domains - reflected in ifStack, etc. The Created rows -Temporary Interfaces (createAndWait, that cannot be set to active) are like buffers to do modifications of parameters for a physical interface offline and then update physical interface. because implementations might reject some parameters combinations the clone mechanism this mechanism provides commanded way ( update object ) rather than SNMP traditional asynchronous SETs 1) verify all parameters can be supported 2) reject the update if parameters are inconsistent each other and/or to the hardware capabilities 3) do an immediate update of the values avoiding asynchronous SNMP Sets - steps 1) 2) - directly over a physical interface minimize service interruption due operation mistakes Now to reflect this ( simple or obscure artifact depending of judgments) - I agree is quite late to propose other mechanisms ( implementations already in place with this IPCDN group design guidelines back in DOCSIS 2.0 specification work) such a scalar group to represent that US interface playground buffer Also the problem with the compliance statements you mention is that the object is used for two types of entries rather than per device compliance like CM or CMTS In CMTS Physical interfaces - always active - Temporary interfaces - fictitious interfaces - not settable to active In CM clone mechanism -> do not care, not applicable Note that docsIfUpChannelStatus is in the docsIfBasicGroupV2 With the read-only requirement for CM Would that be clear NOT to require instantiation of the RowStatus cloneFom and Update objects in the CM ? Now defines that this object is only defined for Temporary entries : docsIfUpChannelStatus, docsIfUpChannelCloneFrom and docsIfUpChannelUpdate out of docsIfBasicGroupV2 add those objects to docsIfCmtsGroupv2 -> As CM does no longer require those objects the below compliances are not needed: OBJECT docsIfUpChannelCloneFrom MIN-ACCESS read-only DESCRIPTION "Read-create in Cable Modem Termination Systems, read-only in Cable Modems." OBJECT docsIfUpChannelUpdate MIN-ACCESS read-only DESCRIPTION "Read-create in Cable Modem Termination Systems, read-only in Cable Modems." The updated object compliance in docsIfBacisComplianceV2 will read: OBJECT docsIfUpChannelStatus SYNTAX RowStatus {notInService(2), notReady(3)} WRITE-SYNTAX RowStatus {createAndWait(5), destroy(6)} DESCRIPTION "'read-create' in Cable Modem Termination Systems and only for upstream temporary interface entries. Upstream physical interfaces do not instantiate this object in their conceptual row entries. Temporary entries support values 'notInService' 'notReady', 'createAndWait' and 'destroy'." Note --> Reviewing RFC2579 I think both notReady, notInService applied, notReady after createAndGo, notInService after CloneFrom is set It does not impact current implemntations based on draft 05. Other updates: Introduced in Entry Object the definition and scope of physical/temporary interfaces docsIfUpstreamChannelEntry OBJECT-TYPE SYNTAX DocsIfUpstreamChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "List of attributes for a single upstream channel. For DOCSIS 2.0 CMTSs, an entry in this table exists for each ifEntry with an ifType of docsCableUpstreamChannel (205). For DOCSIS 1.x CM/CMTSs and DOCSIS 2.0 CMs, an entry in this table exists for each ifEntry with an ifType of docsCableUpstream (129). ==>Added For DOCSIS 2.0 CMTSs two classes of interfaces can be defined for this table: o Upstream Physical Interfaces: The traditional DOCSIS 1.x CMTS upstream interface ifType 129 and the DOCSIS 2.0 ifType that are functional. In other words, interfaces that represents Upstream receivers within an RF MAC interface. Entries of physical interfaces are exposed to the management interface with their corresponding ifStack hierarchy and not administratively created o Upstream Temporary Interfaces: A fictitious interface created with the purpose of manipulating the parameters of a physical interfaces parameters offline and validate values consistency prior to update a target physical Interface. This mechanism helps to minimize service disruption originated in situations where a group of interface parameters values are inconsistent each other in SET operations. Instead, a temporary buffer (temporary interface) is provided to allow the CMTS to validate the parameters offline." <<== Added INDEX { ifIndex } ::= { docsIfUpstreamChannelTable 1 } Updates docsIfUpChannelCloneFrom OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "Intended for use when a temporary upstream interface entry is created to adjust the parameters values of a upstream physical interface channel. Refer to the descriptions of docsIfUpChannelStatus and docsIfUpChannelUpdate for details of this procedure. This object contains the ifIndex value of the physical upstream interface whose parameters are to be adjusted. Upon setting this object to the ifIndex value of a physical interface, this entry objects values ( listed below) are updated with values from the ifIndex referenced by this object: docsIfUpChannelFrequency, docsIfUpChannelWidth, docsIfUpChannelModulationProfile, docsIfUpChannelSlotSize, docsIfUpChannelRangingBackoffStart, docsIfUpChannelRangingBackoffEnd, docsIfUpChannelTxBackoffStart, docsIfUpChannelTxBackoffEnd, docsIfUpChannelScdmaActiveCodes, docsIfUpChannelScdmaCodesPerSlot, docsIfUpChannelScdmaFrameSize, docsIfUpChannelScdmaHoppingSeed, docsIfUpChannelType, and docsIfUpChannelPreEqEnable Setting this object to a non-existent or temporary upstream returns an error 'wrongValue'. This object MUST contain a value of zero for physical upstream entries." ::= { docsIfUpstreamChannelEntry 16 } docsIfUpChannelUpdate OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION " Used to perform the transfer of adjusted parameters from the temporary upstream row to the physical upstream row indicated by the docsIfUpChannelCloneFrom object. The transfer is initiated through an SNMP SET to 'true' of this object. if the adjusted parameter values are not compatible with each other the managed system returns 'inconsistentValue' error . Reading this object always return 'false'." ::= { docsIfUpstreamChannelEntry 17 } docsIfUpChannelStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is only used for the creation of a temporary upstream row with the purpose of adjusting channel parameters of a physical upstream channel entry. The following restrictions apply to this object: 1. Physical Interfaces do not instantiate the RowStatus Type object. 2. Temporary Interface entries are created only by SET to RowStatus createandWait(5). 3. ifAdminStatus from the Interface MIB RFC 2863 is used to take an physical Upstream Channel offline consistent with DOCSIS 1.x operation indicated in RFC 2670. 5. The only possible status change for a temporary interface entry is to destroy(6). 6. Temporary created rows MUST never be given the status active(1). 7. Temporary entries MUST NOT persist at reinitialization of the managed system. Below is a mandatory procedure for adjusting an upstream physical interface : 1. Create a temporary interface entry through an SNMP SET using createAndWait(5). At this point the RowStatus report 'notReady' as status value. Manager entity uses an ifIndex value outside the operational range of the managed system. 2. Set the docsIfUpChannelCloneFrom object to the ifIndex value of the physical row whose parameters require adjustment. Now this object reports 'notInService' 3. Adjust the parameter values using the new temporary row. Ensure all parameters contain desired values before proceeding to step 4. 4. Update the physical row by setting the object docsIfUpChannelUpdate to true(1). 5. Delete the temporary row through an SNMP SET using destroy(6). If a Manager entity does not delete the temporary entry after the physical interface update operation the entry is aged out by the managed system as indicated in RFC 2579. This specification does not define a required aging time period, RFC 2579 suggest and interval of 5 minutes, therefore is advice that manager entities perform the parameters update defined by this table within that period of time." ::= { docsIfUpstreamChannelEntry 18 } -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Wednesday, August 17, 2005 8:51 AM To: Eduardo Cardona; david.raftus@terayon.com Cc: Ipcdn (E-mail) Subject: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Summary: - No showstoppers as far as I can see now. - We can do an IETF Last Call now and you consider the below as initial IETF Last Call comments. So after IETF Last Call completes you would address the below plus whatever comes up from IETF Last Call and only after that will I put it on IESG agenda. - Or you can go do a quick new rev to address the below. If you can do so in the next few days, then I prefer that. Here are my review comments: - In the MODULE-COMPLIANCE statement(s) I see OBJECT docsIfUpChannelStatus SYNTAX RowStatus {active(1), notReady(3)} WRITE-SYNTAX RowStatus {createAndWait(5), destroy(6)} That seems weird. I think that active(1) also needs to be included in the WRITE-SYNTAX, otherwise, when somebody does a createAndWait, and that results in a notRady, how are you then ever going to get the row in active(1) if you cannot write that value? But then I see in the DESCRIPTION clause of docsIfUpChannelStatus that one should not (never?) set a row to active. I do see that notInservice is possible in the description clause. So I am confused. Are you also aware that agents may remove non-active rows after some implementation-specific time? See RFC2579 for details. Just want to be sure you have specified things as intended. I find them strange.... but who is me. It has to do with the "complexity" of your cloning mechanism that both Randy and I have brought up. I do not have a quick alternative available. Would take serious time I guess, cause I would need to better understand your requirements and constraints first. I guess if the WG is OK with whatyou have then we can probably leave it. The WG members (at least some of them I assume) will have to implement it! - SYNTAX check with SMICng: W: f(rfmibv2.mi2), (1488,21) Item "docsIfCmStatusCode" should have SIZE specified I understand this was already the case in RFC2670. If we can add a size such that a compliant implementation of RFC2670 is still compliant, then I suggest we do so. If not, then leave as is. I see that you had a SIZE (0..16) in revision 12, and then Randy commented that that did not fit with the DESCRIPTION clause: DESCRIPTION "Status code for this Cable Modem as defined in the OSSI Specification. The status code consists of a single character indicating error groups, followed by a two- or three-digit number indicating the status condition, followed by a decimal." Which is true. In fact, I am not sure what the content is. Is it - either 3 octets (1 for error group, 2 for a number, no decimal) or 4 octets (1 for error group, 2 for a number, 1 decimal) - either 3 octets (1 for error group, 1 for number, 1 decimal) or 4 octets (1 for error group, 2 for a number, 1 decimal) - either 4 octets (1 for error group, 2 for number, 1 decimal) or 5 octets (1 for error group, 3 for a number, 1 decimal) See why we wonder?? And in any case, the way I read it, MIN length would be 3 or 4 and the MAX length 4 or 5, depending on the above interpretations. I see that Eduardo posted a response, and no-one reacted (at least I cannot quickly find it). So ?? W: f(rfmibv2.mi2), (5036,4) OBJECT-GROUP "docsIfObsoleteGroup" is not used in a MODULE-COMPLIANCE in current module I understand this was already the case in RFC2670. So I am OK to leave it as is. I had suggested (in y review of Dec 2004) Might be good to add a ASN.1 comment about it so we know it has existed for a long time. Seems that was not done. Eduardo responded: >> will add after : -- conditionally mandatory group GROUP docsIfCmtsGroup The group reference, -- obsolete group -- RFC 2670 already had a obsolete group, even though RFC2670 -- was the first version of this MIB Module GROUP docsIfObsoleteGroup DESCRIPTION "This group contains obsolete objects." But I cannot fond any of that addition? Am I missing something? - There was discussion/question Bert commented: 5. ./DOCS-IF-MIB:2400 [3] {range-added} size `(0..512)' added to type used in `docsIfCmtsCmStatusEqualizationData' Probably OK. Can you add some text to explain why this is OK? Eduardo answered: >>(*) I do not have other explanation than "enough" room, probably for future enhancements (?) Current DOCSIS MAC may constrain to 256 bytes total the equalizer data maps. Does anyone recall the reasons for the number selection? So where are we with this? Same question for: ./DOCS-IF-MIB:1167 [3] {range-added} size `(0..512)' added to type used in `docsIfSigQEqualizationData' - For object docsIfCmtsQosProfilePermissions I still see in the DESCRIPTION clause: Either createByManagement(0) or updateByManagement(2) MUST be set when writing to this object. while I see SYNTAX BITS { createByManagement(0), updateByManagement(1), createByModems(2) So that is inconsistent (still). I think you mean Either createByManagement(0) or updateByManagement(1) - Eduardo changed (after my questioning why we have a deprecated value added): docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), operational(8), -- deprecated registeredBPIInitializing(9) } to docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), -- value 8 not used registeredBPIInitializing(9) } Not sure the new thing is better. I much more wanted to see an explanation as to why the deprecated value was added. If some implementations do use it, then better to add it in deprecated form, so we understand that it may indeed be encountered in real life and if so waht it meant. At same time we see it is depreacted, and we have an explantion as to why (and best to have it in the DESCRIPTION clause). See... it is all not only about being pure, but also about representaing realistic behaviour and explaining to the readers of this doc or MIB module what exactly to expect and why. - There was discussion on list: Randy: docsIfUpChannelScdmaActiveCodes - since the primes can never be set and can never be returned, they should be excluded in the SYNTAX Eduardo: (*) >> I am not sure if this is appropiate or will breaks the regular applications, To exclude prime numbers 67,71,73,79,83,89,97,101,103,107,109, 113,127,the SYNTAX clause will be SYNTAX Unsigned32 (0|64..66|68..70|72|74..78|80..82|84..88|90..96|98..100|102 |104..106|108|110..112|114..126|128) Do you prefer this? How do you break this for the 72 columns ID text file format? Bert: I tried this and broke the line after the 102, and both smicng and smilint are happy. So it can be done and it would make the valid values machine readable instead of just being in the DESCRIPTION clause. - Reference/citation problem: !! Missing citation for Normative reference: P139 L016: [IANA] Internet Assigned Numbers Authority, "Data-Over-Cable An easy fix would be: OLD: IANAifType FROM IANAifType-MIB; NEW: IANAifType FROM IANAifType-MIB; -- [IANA] If we're going to do a new revision, then pls update all citations and reference to RFC3291 into one for RFC4001. NITS/Editorial - From an earlier review (6 Jan 2005) by Randy and not yet addressed: 5) EDITORIAL: "reinit" -> "reinitialization" 6) EDITORIAL: "ie" -> "i.e.", or better "that is" 12) EDITORIAL: "head-end" or "headend"? pick one, preferably the former. 13) EDITORIAL: there are some strange capitalizations: "Lineup" in 2.11 "Addressed" in 3.2 (although that is fixed now, now it is in 3.1.4) I checked the above 2. Not the next ones. But did you? "Downstream" in 3.2.5.1 and elsewhere "Cable" in 3.2.5.1.2 "Unicast" on page 12 & 14 & more "Multicast" on page 12 & 14 & more "Broadcast" on page 12 & 14 & more "Upstream" in 3.2.5.2.1 "Contributions" in 5 15) EDITORIAL: "empty string" would be more precise as "zero length string" (This could potentially be technical.) I really wonder why the editors do not take such comments of a carefull review into account when they do a new rev. For completeness, if you do a new rev: $ idnits draft-ietf-ipcdn-docs-rfmibv2-13.txt idnits 1.74 draft-ietf-ipcdn-docs-rfmibv2-13.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted.) Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. Run idnits with the --verbose option for more detailed information. 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
- RE: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-do… Eduardo Cardona
- RE: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-do… Eduardo Cardona