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

["Woundy, Richard" <[e-mail]>]

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: [e-mail]
Cc: Brian Hedstrom; Wijnen, Bert (Bert); [e-mail]; 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 <[e-mail]> on the ID: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-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-051209.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-mibv2-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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn