RE: Re: 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:[email protected]]
> Sent: Thursday, March 02, 2006 03:03
> To: Wijnen, Bert (Bert); [email protected]
> Cc: Brian Hedstrom; [email protected]; Jean-Francois Mule; Woundy,
> Richard
> Subject: RE: Re: [ipcdn] Last Call: 'Cable Device Management=20
> Information
> Base for Data-Over-Cable Service Interface Specification Compliant
> CableModem s and Cable Modem Termination Systems' to Proposed Standard
>=20
>=20
> Thanks, Bert. So here is the resulting change in my private=20
> copy of the draft (to be submitted on Friday).
>=20
> OLD TEXT
>=20
>            DESCRIPTION
>                "This is the MIB Module for DOCSIS-compliant=20
> cable modems
>                 and cable-modem termination systems.
>=20
>                 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."
>=20
> NEW TEXT
>=20
>            DESCRIPTION
>                "This is the MIB Module for DOCSIS-compliant=20
> cable modems
>                 and cable-modem termination systems.
>=20
>                 Copyright (C) The Internet Society (2006).=20
> This version
>                 of this MIB module was published in RFC XXXX; for full
>                 legal notices see the RFC itself."
>=20
> In addition, my copy of the draft needed a similar=20
> modification as discussed for the DOCSIS RF MIB per=20
> <http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01870.html>.
>=20
> OLD TEXT
>=20
> 2.4.  DOCSIS or Data-Over-Cable Service Interface Specification
>=20
>    "Data-Over-Cable Service Interface Specification".  A term=20
> referring
>    to the ITU-T J.112 [ITU-T_J.112] Annex B standard for cable modem
>    systems.  [RFI1.0] [RFI1.1] [RFI2.0]
>=20
> NEW TEXT
>=20
> 2.4.  DOCSIS or Data-Over-Cable Service Interface Specification
>=20
>    "Data-Over-Cable Service Interface Specification".  A term=20
> referring
>    to the ITU-T Recommendation J.112 [ITU-T_J.112] Annex B=20
> standard for
>    cable modem systems.  [RFI1.0] [RFI1.1] [RFI2.0]
>=20
> -- Rich
>=20
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email protected]]=20
> Sent: Wednesday, March 01, 2006 10:55 AM
> To: Woundy, Richard; [email protected]
> Cc: Brian Hedstrom; Wijnen, Bert (Bert); [email protected];=20
> Jean-Francois Mule
> Subject: RE: Re: [ipcdn] Last Call: 'Cable Device Management=20
> Information Base for Data-Over-Cable Service Interface=20
> Specification Compliant CableModem s and Cable Modem=20
> Termination Systems' to Proposed Standard
>=20
>=20
> A nit:
>=20
> The DESCRIPTION clause of the MODULE-IDENTITY states:
>            DESCRIPTION
>                "This is the MIB Module for DOCSIS-compliant=20
> cable modems
>                 and cable-modem termination systems.
>=20
>                 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."
>=20
> - I would change "The initial version" to "This version".=20
>   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.
>=20
> I know I have the above in an RFC-Editor note, but since you=20
> post a new rev anyway, I rather would see you fix it.
>=20
>=20
> Bert
>=20
> > -----Original Message-----
> > From: Woundy, Richard [mailto:[email protected]]
> > Sent: Monday, February 27, 2006 16:45
> > To: [email protected]
> > Cc: Brian Hedstrom; Wijnen, Bert (Bert); [email protected];
> > Jean-Francois
> > Mule; Woundy, Richard
> > Subject: RE: Re: [ipcdn] Last Call: 'Cable Device Management=20
> > Information
> > Base for Data-Over-Cable Service Interface Specification Compliant
> > CableModem s and Cable Modem Termination Systems' to=20
> Proposed Standard
> >=20
> >=20
> > Folks,
> >=20
> > I incorporated the changes mentioned below in a preliminary
> > draft,=20
> > <http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-11-
> > proposed.txt>, with the XML version at=20
> > <http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-11-
> > proposed.xml>.
> >=20
> > Your comments are solicited and encouraged; this is the
> > version I currently plan to submit on March 3rd if all goes well.
> >=20
> > I performed all of the same checks (online idnits tool,
> > xml2rfc validator tool, and smilint) on this draft version,=20
> > and got the same results (basically clean) as performed in=20
> > <http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01808.html>.
> >=20
> > As I edited the current draft, I discovered we needed one
> > more update. We "anticipated" outbound LLC filters in the=20
> > DOCSIS QoS MIB draft in section 3.3.4; now that the DOCSIS=20
> > QoS MIB is published as RFC 4323, the text needed to be=20
> > corrected. In addition, I needed to update the reference to=20
> > the permanent RFC number, of course.
> >=20
> > OLD TEXT
> >=20
> >    Lastly, any outbound LLC filters are applied to the packet
> > just prior
> >    to it being emitted on the appropriate interface.  This=20
> MIB module
> >    does not specify any outbound LLC filters, but it is=20
> > 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.
> >=20
> > NEW TEXT
> >=20
> >    Lastly, any outbound LLC filters are applied to the packet
> > just prior
> >    to it being emitted on the appropriate interface.  This=20
> MIB module
> >    does not specify any outbound LLC filters, but section 3 of the
> >    DOCSIS Quality of Service (QoS) MIB, [RFC4323], includes=20
> > outbound LLC
> >    filtering requirements.
> >=20
> > -- Rich
> >=20
> > -----Original Message-----
> > From: Woundy, Richard
> > Sent: Monday, February 27, 2006 12:34 AM
> > To: [email protected]
> > Cc: Brian Hedstrom; Wijnen, Bert (Bert); [email protected];=20
> > Jean-Francois Mule; Woundy, Richard
> > Subject: Re: [ipcdn] Last Call: 'Cable Device Management=20
> > Information Base for Data-Over-Cable Service Interface=20
> > Specification Compliant CableModem s and Cable Modem=20
> > Termination Systems' to Proposed Standard
> >=20
> >=20
> > Folks,
> >=20
> > This note summarizes the editor and WG chairs' response to
> > the IETF Last Call comment received on 12/19/2005 by the IESG=20
> > from Brian Hedstrom <[email protected]> on the ID:=20
> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mib
> > v2-10.txt.
> >=20
> > This email response has been previously shared with Brian
> > Hedstrom and we believe it addresses the comment raised by=20
> > him, based on existing product implementation and best common=20
> > practices from DOCSIS cable operators.
> >=20
> > In short, we propose to address Brian's comment by adding
> > clarification text in the current IPCDN MIB module to indicate:
> >=20
> > 1) CM implementations must report the *first* Syslog server
> > from the DHCP log server option value if the DHCP option=20
> > received by the CM was multi-valued, and
> >=20
> > 2) CM implementations must report the *active* time server
> > from the DHCP time server option value if the DHCP option=20
> > received by the CM was multi-valued.
> >=20
> > Let us know if there are any objections to this response by
> > Friday March 3rd 5pm Eastern Time (note that the draft=20
> > submission cut-off is Monday March 6th 9am ET). If there are=20
> > no objections by this time, we will post the revision to the=20
> > draft including only these two modifications and minimal=20
> > editorial changes e.g. draft version, posting date, revision=20
> > date, etc. Then we believe the IETF Last Call process will be=20
> > complete, and we will assume the draft can proceed=20
> > immediately to IESG evaluation and approval.
> >=20
> > Rich and Jean-Fran=E7ois Mul=E9
> > --- Rich as Editor of the IPCDN ID and both as IPCDN co-chairs
> > ---
> >=20
> > 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=20
> > August 1999. The multi-valued options in DHCP are specified=20
> > in RFC 2132 which was published prior to RFC2669 in March=20
> > 1997, so the current MIB module restrictions for a single=20
> > time server and single log (Syslog) server have been around=20
> > for over six years, without any WG, vendor or cable modem=20
> > operator comments raised during the updating of the RFC based=20
> > on the inability for the MIB objects to reflect multi-value options;
> >    b) existing implementations and current DOCSIS cable modem=20
> > compliance indicate that most manufacturers do effectively=20
> > treat the log server options as single valued;
> >    c) most operators do rely on various, multiple mechanisms=20
> > to provide server redundancy for Syslog servers; and
> >    d) existing implementations and current DOCSIS (1.1 and=20
> > 2.0) cable modem compliance indicate that most manufacturers=20
> > do effectively treat the time server options as multi valued=20
> > for the purpose of determining a functional time server for a=20
> > single boot-time time synchronization event, per DOCSIS RFI=20
> > 1.1 section 9.2.7 and DOCSIS RFI 2.0 section 11.2.7.
> >=20
> > Furthermore, the Syslog server MIB object is read-writeable
> > meaning that, after the CM completes DHCP, the CM may=20
> > download a configuration file from the operator's OSS systems=20
> > containing SNMP 'Set' commands for that MIB object. This=20
> > provides cable operators additional flexibility and is yet=20
> > another indicator that best common practice is to use a=20
> > single value to set that option in the CM configuration files.
> >=20
> > This being said, we thank Brian for his comment and we
> > believe that the comment should be taken into account to add=20
> > clarification text in the 2 relevant MIB objects so that new=20
> > implementers faced with the same questions know how to=20
> > proceed for DOCSIS 1.x and 2.0. Even though we are not aware=20
> > of inconsistent implementations, or the practical needs to=20
> > address this concern, this may guarantee "more" consistency=20
> > in the future. As for future versions of DOCSIS, operator=20
> > guidance should be requested on these topics.
> >=20
> > --- Brian's comment:
> > See full details at:
> > http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01837.html
> >=20
> > In summary, the comment raises a question on the support of
> > multiple Syslog servers in the CM due to the limitations of=20
> > docsDevEvSyslogAddress object when the CM is provided with=20
> > multiple server values in DHCP Option 7.
> >=20
> > As Rich pointed out in:
> > http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01838.html
> > the latest DOCSIS RFI specification available at:=20
> > <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=20
> > of out the five standard DHCP options specified are allowed=20
> > to be multi-valued:
> > * Option code 3 (Router Option)
> > * Option code 4 (Time Server Option) -> docsDevServerTimeAddress
> > * Option code 7 (Log Server Option)  -> docsDevEvSyslogAddress
> >=20
> > Note that the Router Option is not referenced by any MIB
> > object in this MIB module.
> >=20
> > Based on the rationale explained above in introduction of
> > this email, we propose to add the following text to the=20
> > following objects in
> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mib
> v2-10.txt:
>=20
> - 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.=20
>=20
>                 Note that if multiple values are provided to the=20
>                 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=20
>                 RFI specification. During the period of time where
>                 the Time of Day have not been acquired, the Time=20
>                 server address reported by the CM may report the=20
>                 first address value in the DHCP option value or the
>                 last server address the CM attempted to get the Time
>                 of day value.
>=20
>                 Returns the zero length octet string if the=20
> 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."
>            ::=3D { docsDevServer 9 }
>=20
>=20
> - docsDevEvSyslogAddress:
> NEW TEXT:
>    docsDevEvSyslogAddress OBJECT-TYPE
>            SYNTAX      InetAddress
>            MAX-ACCESS  read-write
>            STATUS      current
>            DESCRIPTION
>                "The Internet address of the Syslog server as=20
> 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:=20
> IPv6 address,
>                 Syslog transmission is inhibited. =20
>=20
>                 Note that if multiple values are provided to the CM in
>                 DHCP option 7, the value of this MIB object=20
> MUST be the
>                 first Syslog server address received.
>=20
>                 By default at agent boot, this object returns the zero
>                 length string."
>            ::=3D { docsDevEvent 10 }
>=20
> We believe this addresses the comment by indicating how=20
> current implementations deal with this situation.
> ------------------------------------------------------------------
>=20