RE: Re: [ipcdn] Last Call: 'Cable Device Management Information B ase for Data-Over-Cable Service Interface Specification Compliant CableMo dem s and Cable Modem Termination Systems' to Proposed Standard
"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Wed, 01 March 2006 15:55 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FETfI-0001hi-6c; Wed, 01 Mar 2006 10:55:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FETfG-0001hb-UC for ipcdn@ietf.org; Wed, 01 Mar 2006 10:54:58 -0500
Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FETfE-0003V4-Bq for ipcdn@ietf.org; Wed, 01 Mar 2006 10:54:58 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k21Fsmca020568; Wed, 1 Mar 2006 09:54:49 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <DVB4Y23T>; Wed, 1 Mar 2006 16:54:47 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509721AEC@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>, ipcdn@ietf.org
Subject: RE: Re: [ipcdn] Last Call: 'Cable Device Management Information B ase for Data-Over-Cable Service Interface Specification Compliant CableMo dem s and Cable Modem Termination Systems' to Proposed Standard
Date: Wed, 01 Mar 2006 16:54:45 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ihemail2.lucent.com id k21Fsmca020568
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606
Cc: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, Jean-Francois Mule <jf.mule@cablelabs.com>, Brian Hedstrom <B.Hedstrom@cablelabs.com>, rdroms@cisco.com
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>
Errors-To: ipcdn-bounces@ietf.org
A nit: The DESCRIPTION clause of the MODULE-IDENTITY states: DESCRIPTION "This is the MIB Module for DOCSIS-compliant cable modems and cable-modem termination systems. Copyright (C) The Internet Society (2006). The initial version of this MIB module was published in RFC XXXX; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html." - I would change "The initial version" to "This version". Because we really want people to look at this RFC which has this version and not the initial version of RFC2669. - I would remove the last sentence: Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html. because this is a standalone MIB module and is not maintained by IANA at all. So IANA notices on copyrights do not apply I think. I vaguely recall I had mentioned this earlier... but anyway. Indeed I did mention it om 25 Nov 2005. I know I have the above in an RFC-Editor note, but since you post a new rev anyway, I rather would see you fix it. Bert > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Monday, February 27, 2006 16:45 > To: ipcdn@ietf.org > Cc: Brian Hedstrom; Wijnen, Bert (Bert); rdroms@cisco.com; > Jean-Francois > Mule; Woundy, Richard > Subject: RE: Re: [ipcdn] Last Call: 'Cable Device Management > Information > Base for Data-Over-Cable Service Interface Specification Compliant > CableModem s and Cable Modem Termination Systems' to Proposed Standard > > > Folks, > > I incorporated the changes mentioned below in a preliminary > draft, > <http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-11- > proposed.txt>, with the XML version at > <http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-11- > proposed.xml>. > > Your comments are solicited and encouraged; this is the > version I currently plan to submit on March 3rd if all goes well. > > I performed all of the same checks (online idnits tool, > xml2rfc validator tool, and smilint) on this draft version, > and got the same results (basically clean) as performed in > <http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01808.html>. > > As I edited the current draft, I discovered we needed one > more update. We "anticipated" outbound LLC filters in the > DOCSIS QoS MIB draft in section 3.3.4; now that the DOCSIS > QoS MIB is published as RFC 4323, the text needed to be > corrected. In addition, I needed to update the reference to > the permanent RFC number, of course. > > OLD TEXT > > Lastly, any outbound LLC filters are applied to the packet > just prior > to it being emitted on the appropriate interface. This MIB module > does not specify any outbound LLC filters, but it is > anticipated that > the Quality of Service (QoS) additions to the DOCSIS standard > [I-D.ietf-ipcdn-qos-mib] may include some outbound LLC filtering > requirements. If so, those filters would be applied as described > there. > > NEW TEXT > > Lastly, any outbound LLC filters are applied to the packet > just prior > to it being emitted on the appropriate interface. This MIB module > does not specify any outbound LLC filters, but section 3 of the > DOCSIS Quality of Service (QoS) MIB, [RFC4323], includes > outbound LLC > filtering requirements. > > -- Rich > > -----Original Message----- > From: Woundy, Richard > Sent: Monday, February 27, 2006 12:34 AM > To: ipcdn@ietf.org > Cc: Brian Hedstrom; Wijnen, Bert (Bert); rdroms@cisco.com; > Jean-Francois Mule; Woundy, Richard > Subject: Re: [ipcdn] Last Call: 'Cable Device Management > Information Base for Data-Over-Cable Service Interface > Specification Compliant CableModem s and Cable Modem > Termination Systems' to Proposed Standard > > > Folks, > > This note summarizes the editor and WG chairs' response to > the IETF Last Call comment received on 12/19/2005 by the IESG > from Brian Hedstrom <b.hedstrom@cablelabs.com> on the ID: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mib > v2-10.txt. > > This email response has been previously shared with Brian > Hedstrom and we believe it addresses the comment raised by > him, based on existing product implementation and best common > practices from DOCSIS cable operators. > > In short, we propose to address Brian's comment by adding > clarification text in the current IPCDN MIB module to indicate: > > 1) CM implementations must report the *first* Syslog server > from the DHCP log server option value if the DHCP option > received by the CM was multi-valued, and > > 2) CM implementations must report the *active* time server > from the DHCP time server option value if the DHCP option > received by the CM was multi-valued. > > Let us know if there are any objections to this response by > Friday March 3rd 5pm Eastern Time (note that the draft > submission cut-off is Monday March 6th 9am ET). If there are > no objections by this time, we will post the revision to the > draft including only these two modifications and minimal > editorial changes e.g. draft version, posting date, revision > date, etc. Then we believe the IETF Last Call process will be > complete, and we will assume the draft can proceed > immediately to IESG evaluation and approval. > > Rich and Jean-François Mulé > --- Rich as Editor of the IPCDN ID and both as IPCDN co-chairs > --- > > In introduction, the chairs would like to note the following: > a) the IPCDN Internet-Draft in question is an update to > RFC 2669 (the original IPCDN Cable Device MIB) published in > August 1999. The multi-valued options in DHCP are specified > in RFC 2132 which was published prior to RFC2669 in March > 1997, so the current MIB module restrictions for a single > time server and single log (Syslog) server have been around > for over six years, without any WG, vendor or cable modem > operator comments raised during the updating of the RFC based > on the inability for the MIB objects to reflect multi-value options; > b) existing implementations and current DOCSIS cable modem > compliance indicate that most manufacturers do effectively > treat the log server options as single valued; > c) most operators do rely on various, multiple mechanisms > to provide server redundancy for Syslog servers; and > d) existing implementations and current DOCSIS (1.1 and > 2.0) cable modem compliance indicate that most manufacturers > do effectively treat the time server options as multi valued > for the purpose of determining a functional time server for a > single boot-time time synchronization event, per DOCSIS RFI > 1.1 section 9.2.7 and DOCSIS RFI 2.0 section 11.2.7. > > Furthermore, the Syslog server MIB object is read-writeable > meaning that, after the CM completes DHCP, the CM may > download a configuration file from the operator's OSS systems > containing SNMP 'Set' commands for that MIB object. This > provides cable operators additional flexibility and is yet > another indicator that best common practice is to use a > single value to set that option in the CM configuration files. > > This being said, we thank Brian for his comment and we > believe that the comment should be taken into account to add > clarification text in the 2 relevant MIB objects so that new > implementers faced with the same questions know how to > proceed for DOCSIS 1.x and 2.0. Even though we are not aware > of inconsistent implementations, or the practical needs to > address this concern, this may guarantee "more" consistency > in the future. As for future versions of DOCSIS, operator > guidance should be requested on these topics. > > --- Brian's comment: > See full details at: > http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01837.html > > In summary, the comment raises a question on the support of > multiple Syslog servers in the CM due to the limitations of > docsDevEvSyslogAddress object when the CM is provided with > multiple server values in DHCP Option 7. > > As Rich pointed out in: > http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01838.html > the latest DOCSIS RFI specification available at: > <http://www.cablemodem.com/downloads/specs/CM-SP-RFI2.0-I10-05 > 1209.pdf>, > in annex D.1.1, and RFC 2132, defines 5 DHCP options. Three > of out the five standard DHCP options specified are allowed > to be multi-valued: > * Option code 3 (Router Option) > * Option code 4 (Time Server Option) -> docsDevServerTimeAddress > * Option code 7 (Log Server Option) -> docsDevEvSyslogAddress > > Note that the Router Option is not referenced by any MIB > object in this MIB module. > > Based on the rationale explained above in introduction of > this email, we propose to add the following text to the > following objects in > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mib v2-10.txt: - docsDevServerTimeAddress: NEW TEXT: docsDevServerTimeAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The Internet address of the RFC 868 Time server as provided by DHCP option 4. Note that if multiple values are provided to the CM in DHCP option 4, the value of this MIB object MUST be the Time server address from which the Time of Day reference was acquired based on the DOCSIS RFI specification. During the period of time where the Time of Day have not been acquired, the Time server address reported by the CM may report the first address value in the DHCP option value or the last server address the CM attempted to get the Time of day value. Returns the zero length octet string if the time server IP address is not provisioned." REFERENCE "DOCSIS RFI 1.1 Specification, Section 9.2.7. and DOCSIS RFI 2.0 Specification, Section 11.2.7." ::= { docsDevServer 9 } - docsDevEvSyslogAddress: NEW TEXT: docsDevEvSyslogAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The Internet address of the Syslog server as provided by DHCP option 7 or set via SNMP management. If the address of the server is set to any of the zero length string, the 0.0.0.0 IPv4 address or the 0: IPv6 address, Syslog transmission is inhibited. Note that if multiple values are provided to the CM in DHCP option 7, the value of this MIB object MUST be the first Syslog server address received. By default at agent boot, this object returns the zero length string." ::= { docsDevEvent 10 } We believe this addresses the comment by indicating how current implementations deal with this situation. ------------------------------------------------------------------ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn
- RE: Re: [ipcdn] Last Call: 'Cable Device Manageme… Wijnen, Bert (Bert)
- RE: Re: [ipcdn] Last Call: 'Cable Device Manageme… Wijnen, Bert (Bert)