[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
looks good to me.
Bert
> -----Original Message-----
> From: Woundy, Richard [mailto:Richard_Woundy at cable.comcast.com]
> Sent: Thursday, March 02, 2006 03:03
> To: Wijnen, Bert (Bert); ipcdn at ietf.org
> Cc: Brian Hedstrom; rdroms at 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
>
>
> Thanks, Bert. So here is the resulting change in my private
> copy of the draft (to be submitted on Friday).
>
> OLD TEXT
>
> 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.";
>
> NEW TEXT
>
> DESCRIPTION
> "This is the MIB Module for DOCSIS-compliant
> cable modems
> and cable-modem termination systems.
>
> Copyright (C) The Internet Society (2006).
> This version
> of this MIB module was published in RFC XXXX; for full
> legal notices see the RFC itself."
>
> In addition, my copy of the draft needed a similar
> modification as discussed for the DOCSIS RF MIB per
> <http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01870.html>.
>
> OLD TEXT
>
> 2.4. DOCSIS or Data-Over-Cable Service Interface Specification
>
> "Data-Over-Cable Service Interface Specification". A term
> referring
> to the ITU-T J.112 [ITU-T_J.112] Annex B standard for cable modem
> systems. [RFI1.0] [RFI1.1] [RFI2.0]
>
> NEW TEXT
>
> 2.4. DOCSIS or Data-Over-Cable Service Interface Specification
>
> "Data-Over-Cable Service Interface Specification". A term
> referring
> to the ITU-T Recommendation J.112 [ITU-T_J.112] Annex B
> standard for
> cable modem systems. [RFI1.0] [RFI1.1] [RFI2.0]
>
> -- Rich
>
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen at lucent.com]
> Sent: Wednesday, March 01, 2006 10:55 AM
> To: Woundy, Richard; ipcdn at ietf.org
> Cc: Brian Hedstrom; Wijnen, Bert (Bert); rdroms at cisco.com;
> Jean-Francois Mule
> 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
>
>
> 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 at cable.comcast.com]
> > Sent: Monday, February 27, 2006 16:45
> > To: ipcdn at ietf.org
> > Cc: Brian Hedstrom; Wijnen, Bert (Bert); rdroms at 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 at ietf.org
> > Cc: Brian Hedstrom; Wijnen, Bert (Bert); rdroms at 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 at 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 at ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn