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)" <[e-mail]>]

looks good to me.

Bert

> -----Original Message-----
> From: Woundy, Richard [mailto:[e-mail]]
> Sent: Thursday, March 02, 2006 03:03
> To: Wijnen, Bert (Bert); [e-mail]
> Cc: Brian Hedstrom; [e-mail]; 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:[e-mail]] 
> Sent: Wednesday, March 01, 2006 10:55 AM
> To: Woundy, Richard; [e-mail]
> Cc: Brian Hedstrom; Wijnen, Bert (Bert); [e-mail]; 
> 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:[e-mail]]
> > Sent: Monday, February 27, 2006 16:45
> > To: [e-mail]
> > Cc: Brian Hedstrom; Wijnen, Bert (Bert); [e-mail];
> > 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: [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-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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn