RE: Re: 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

In the absence of any other public feedback, here is a copy of what I =
plan to submit today (to internet-drafts) at 5pm ET.

<http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-11.txt>
<http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-11.xml>

-- Rich

-----Original Message-----
From: Woundy, Richard=20
Sent: Wednesday, March 01, 2006 9:03 PM
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 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:[email protected]]=20
Sent: Wednesday, March 01, 2006 10:55 AM
To: Woundy, Richard; [email protected]
Cc: Brian Hedstrom; Wijnen, Bert (Bert); [email protected]; 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".=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.

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:[email protected]]
> Sent: Monday, February 27, 2006 16:45
> To: [email protected]
> Cc: Brian Hedstrom; Wijnen, Bert (Bert); [email protected];=20
> 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
> Folks,
>=20
> 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=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=20
> currently plan to submit on March 3rd if all goes well.
>=20
> I performed all of the same checks (online idnits tool, xml2rfc=20
> validator tool, and smilint) on this draft version, and got the same=20
> 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 DOCSIS QoS MIB draft in=20
> section 3.3.4; now that the DOCSIS QoS MIB is published as RFC 4323,=20
> the text needed to be corrected. In addition, I needed to update the=20
> reference to the permanent RFC number, of course.
>=20
> OLD TEXT
>=20
>    Lastly, any outbound LLC filters are applied to the packet just=20
> 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.
>=20
> NEW TEXT
>=20
>    Lastly, any outbound LLC filters are applied to the packet just=20
> 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.
>=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];
> 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=20
> Last Call comment received on 12/19/2005 by the IESG from Brian=20
> 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 him, based on existing=20
> product implementation and best common practices from DOCSIS cable=20
> operators.
>=20
> In short, we propose to address Brian's comment by adding=20
> clarification text in the current IPCDN MIB module to indicate:
>=20
> 1) CM implementations must report the *first* Syslog server from the=20
> DHCP log server option value if the DHCP option received by the CM was =

> multi-valued, and
>=20
> 2) CM implementations must report the *active* time server from the=20
> DHCP time server option value if the DHCP option received by the CM=20
> was multi-valued.
>=20
> Let us know if there are any objections to this response by Friday=20
> March 3rd 5pm Eastern Time (note that the draft submission cut-off is=20
> Monday March 6th 9am ET). If there are no objections by this time, we=20
> will post the revision to the draft including only these two=20
> modifications and minimal editorial changes e.g. draft version,=20
> posting date, revision date, etc. Then we believe the IETF Last Call=20
> process will be complete, and we will assume the draft can proceed
> 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=20
> (the original IPCDN Cable Device MIB) published in August 1999. The=20
> multi-valued options in DHCP are specified in RFC 2132 which was=20
> published prior to RFC2669 in March 1997, so the current MIB module=20
> restrictions for a single time server and single log (Syslog) server=20
> have been around for over six years, without any WG, vendor or cable=20
> 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=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=20
> that, after the CM completes DHCP, the CM may download a configuration =

> file from the operator's OSS systems containing SNMP 'Set' commands=20
> for that MIB object. This provides cable operators additional=20
> flexibility and is yet another indicator that best common practice is=20
> to use a single value to set that option in the CM configuration=20
> files.
>=20
> This being said, we thank Brian for his comment and we believe that=20
> the comment should be taken into account to add clarification text in=20
> the 2 relevant MIB objects so that new implementers faced with the=20
> 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=20
> needs to address this concern, this may guarantee "more" consistency
> 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:=20
> http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01837.html
>=20
> In summary, the comment raises a question on the support of multiple=20
> Syslog servers in the CM due to the limitations of=20
> docsDevEvSyslogAddress object when the CM is provided with multiple=20
> server values in DHCP Option 7.
>=20
> As Rich pointed out in:=20
> 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=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=20
> this MIB module.
>=20
> Based on the rationale explained above in introduction of this email,=20
> 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.=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.

                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."
           ::=3D { 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. =20

                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."
           ::=3D { docsDevEvent 10 }

We believe this addresses the comment by indicating how current =
implementations deal with this situation.
------------------------------------------------------------------