RE: Last Call: 'Cable Device Management Information Base forData-Over-Cable Service Interface Specification CompliantCableModem s and Cable Modem Termination Systems' to ProposedStandard

Rich, Brian and all,

   Given where we are in the process and given the existing restrictions
in RFC2669, my first reaction would be to do a real check with operators
and implementers by asking:
	a) CM operators about their actual use of the syslog server DHCP
option in field deployments (multi-value or single?). 
	b) CM vendors about how their implementations deal with
multi-values in the mentioned DHCP options.

   Given that syslog is UDP-based, what would it mean to have multiple
server values? It can't reliably be used for fail-over scenarios so
should mean broadcast syslog. I personally think that this would best be
done by using a management station that could act like a trap exploder
and broadcast or multicast the syslog msg to multiple servers.

Comments and feedback from the list is appreciated.
Jean-Francois

> -----Original Message-----
> From: Richard Woundy @ Comcast
> Sent: Wednesday, December 21, 2005 1:01 PM
> To: Brian Hedstrom; Wijnen, Bert (Bert)
> Cc: Ipcdn (E-mail); Richard Woundy @ Comcast
> Subject: RE: [ipcdn] Last Call: 'Cable Device Management Information
> Base forData-Over-Cable Service Interface Specification
> CompliantCableModem s and Cable Modem Termination Systems' to
> ProposedStandard
> 
> Brian, Bert,
> 
> I need some help from the IPCDN working group to resolve this Last
> Call
> objection.
> 
> The latest DOCSIS RFI specification,
> <http://www.cablemodem.com/downloads/specs/CM-SP-RFI2.0-I10-
> 051209.pdf>,
> annex D.1.1, specifies the use of five standard DHCP options:
> 
> * Option code 1 (Subnet Mask)
> * Option code 2 (Time Offset)
> * Option code 3 (Router Option)
> * Option code 4 (Time Server Option)
> * Option code 7 (Log Server Option)
> 
> Looking at RFC 2132,
<http://www.ietf.org/rfc/rfc2132.txt?number=2132>,
> it becomes obvious that DHCP options 1 and 2 are single-valued
options,
> and DHCP options 3, 4 and 7 are potentially multi-valued options.
> 
> So it would seem that if we are worried about multi-valued DHCP
> options,
> we should be just as concerned about multiple time servers (e.g.
> docsDevServerTimeAddress) as about multiple SYSLOG servers (e.g.
> docsDevEvSyslogAddress).
> 
> RFC 2669 (the original Cable Device MIB) was published August 1999,
> and
> RFC 2132 was published March 1997. So the MIB module restrictions for
> a
> single time server and SYSLOG server has been around for over six
> years,
> without an objection until now. Is this a real problem, or a
> theoretical
> problem?
> 
> I can think of three reactions to this objection: (1) no changes, (2)
> clarify the relevant MIB objects so that they report the *first* DHCP
> option value if the DHCP option is multi-valued, or (3) change the MIB
> module to add tables to capture (multiple) Time Servers and/or SYSLOG
> servers.
> 
> -- Rich
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Wijnen, Bert (Bert)
> Sent: Wednesday, December 21, 2005 12:39 PM
> To: Ipcdn (E-mail)
> Cc: Brian Hedstrom
> 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
> 
> 
> Authors/Editors and WG,
> 
> A comment on IETF Last Call for your consideration and
> possible action.
> 
> Not sure that Brian is subscribed to IPCDN list, so pls DO
> copy him on any responses.
> 
> Bert
> 
> 
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]On Behalf
> Of
> 
> > Brian Hedstrom
> > Sent: Monday, December 19, 2005 20:23
> > To: [email protected]
> > Subject: RE: [ipcdn] Last Call: 'Cable Device Management Information
> > Base for Data-Over-Cable Service Interface Specification Compliant
> > Cable Modems and Cable Modem Termination Systems' to Proposed
> Standard
> >
> >
> > IETF:
> >
> > Regarding this object:
> >    docsDevEvSyslogAddress OBJECT-TYPE
> >            SYNTAX      InetAddress
> >            MAX-ACCESS  read-write
> >            STATUS      current
> >            DESCRIPTION
> >                "The internet address of the Syslog server.  If the
> >                 address of the server is set to any of the zero
> length
> >                 string, the 0.0.0.0 V4 address or the 0: V6 address,
> >                 syslog transmission is inhibited.  By default at
> agent
> >                 boot, this object returns the zero length string."
> >            ::= { docsDevEvent 10 }
> >
> > This object does not support provisioning multiple Syslog
> > servers within
> > the CM.  However, DHCP Option 7 (log server option, as
> > defined in DOCSIS
> > 2.0 Radio Frequency Interface Specification
> > [CM-SP-RFIv2.0-I09-050812])
> > does allow for specification of multiple log server addresses so
> > although they cannot all be instrumented it is possible to provide
> the
> > CM with multiple log server addresses. It seems reasonable to
> > extend the
> > docsDevEvSyslogAddress object to support multiple IP
> > addresses but I do
> > not know if this was already addressed and rejected during the
> > development of this Internet draft. The change could potentially
> mean
> > deprecating docsDevEvSyslogAddress and replacing it with a
> > table object
> > which supports Row Creation or statically creates n-number of rows.
> A
> > similar approach was taken in CableHome with the definition of
> > cabhCdpWanDnsServerTable (CABH-CDP-MIB). The structure of
> > cabhCdpWanDnsServerTable identifies an order of preference (primary,
> > secondary, or tertiary) for each entry.  See below:
> > cabhCdpWanDnsServerTable OBJECT-TYPE
> >     SYNTAX SEQUENCE OF CabhCdpWanDnsServerEntry
> >     MAX-ACCESS not-accessible
> >     STATUS current
> >     DESCRIPTION
> >             "This table contains the IP addresses of cable network
> and
> >             Internet DNS servers, in the order of preference in
> which
> >             the PS's CNP will query them, when it cannot resolve a
> DNS
> >             query using local information. Entries in this table are
> >             updated with the information contained in DHCP Option 6,
> >             received during both the WAN-Man and WAN-Data IP
> >             acquisition processes."
> >     ::= { cabhCdpAddr 3 }
> >
> > cabhCdpWanDnsServerEntry OBJECT-TYPE
> >     SYNTAX      CabhCdpWanDnsServerEntry
> >     MAX-ACCESS  not-accessible
> >     STATUS     current
> >     DESCRIPTION
> >             "List of cable network and Internet DNS servers."
> >     INDEX { cabhCdpWanDnsServerOrder }
> >     ::= { cabhCdpWanDnsServerTable 1 }
> >
> > CabhCdpWanDnsServerEntry ::= SEQUENCE {
> >     cabhCdpWanDnsServerOrder  INTEGER,
> >     cabhCdpWanDnsServerIpType InetAddressType,
> >     cabhCdpWanDnsServerIp     InetAddress
> >     }
> >
> > cabhCdpWanDnsServerOrder OBJECT-TYPE
> >     SYNTAX      INTEGER {
> >                     primary(1),
> >                     secondary(2),
> >                     tertiary(3)
> >                 }
> >     MAX-ACCESS  not-accessible
> >     STATUS      current
> >     DESCRIPTION
> >             "The order of preference for cable network and
> > Internet DNS
> >             servers, as listed in DHCP option 6 (Domain Server). Any
> >             time the CDC receives valid IP address information
> within
> >             DHCP Option 6, as part of lease acquisition or renewal
> of
> >             a WAN-Man or WAN-Data IP, it must update this
> information
> >             into this table.  As entries in DHCP Option 6 are
> > listed in
> >             order of preference, the highest priority entry in DHCP
> >             Option 6 must correspond to the row with a
> >             cabhCdpWanDnsServerOrder with a value of 1. If DHCP
> >             Option 6 contains 1 valid IP address, the PS MUST update
> >             the row with a cabhCdpWanDnsServerOrder value of 1 and
> >             MUST NOT modify rows with
> >             cabhCdpWanDnsServerOrder values of 2 & 3
> >             (if they exist). If DHCP Option 6 contains 2 valid
> >             IP addresses, the PS MUST update the rows with
> >             cabhCdpWanDnsServerOrder values of 1 and 2
> >             and MUST NOT modify the row with
> cabhCdpWanDnsServerOrder
> >             value of 3 (if it exists). If DHCP Option 6 contains 3
> >             valid IP addresses, the PS MUST update rows with
> >             cabhCdpWanDnsServerOrder values of 1, 2, and 3.
> >             Any DNS server information included in DHCP Option 6
> >             beyond primary, secondary and tertiary will not be
> >             represented in this table."
> >     ::= { cabhCdpWanDnsServerEntry 1 }
> >
> > cabhCdpWanDnsServerIpType OBJECT-TYPE
> >     SYNTAX      InetAddressType
> >     MAX-ACCESS read-only
> >     STATUS current
> >     DESCRIPTION
> >             "This parameter indicates the IP address type of a
> >             WAN DNS server."
> >     DEFVAL { ipv4 }
> >     ::= { cabhCdpWanDnsServerEntry 2 }
> >
> > cabhCdpWanDnsServerIp OBJECT-TYPE
> >     SYNTAX      InetAddress
> >     MAX-ACCESS  read-only
> >     STATUS      current
> >     DESCRIPTION
> >             "This parameter indicates the IP address of a WAN DNS
> >             server. The type of this address is specified by
> >             cabhCdpWanDnsServerIpType."
> >     ::= { cabhCdpWanDnsServerEntry 3 }
> >
> > Thanks,
> > Brian Hedstrom
> > Senior Engineer, Operation Support Systems
> > Broadband Access
> > CableLabs, Inc.
> > 858 Coal Creek Circle
> > Louisville, CO 80027
> > Direct: 303.661.3829
> > eFax: 303.664.8120
> > [email protected]
> >
> >
> > -----Original Message-----
> > From: The IESG [mailto:[email protected]]
> > Sent: Wednesday, December 14, 2005 9:44 AM
> > To: IETF-Announce
> > Cc: [email protected]
> > Subject: [ipcdn] Last Call: 'Cable Device Management Information
> Base
> > for Data-Over-Cable Service Interface Specification Compliant Cable
> > Modems and Cable Modem Termination Systems' to Proposed Standard
> >
> > The IESG has received a request from the IP over Cable Data Network
> WG
> 
> > to consider the following document:
> >
> > - 'Cable Device Management Information Base for
> > Data-Over-Cable Service
> >    Interface Specification Compliant Cable Modems and Cable Modem
> > Termination
> >    Systems '
> >    <draft-ietf-ipcdn-device-mibv2-10.txt> as a Proposed Standard
> >
> > This document obsoletes RFC2669.
> >
> > The IESG plans to make a decision in the next few weeks, and
> solicits
> > final comments on this action.  Please send any comments to the
> > [email protected] or [email protected] mailing lists by 2005-12-28.
> >
> > The file can be obtained via
> > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mi
> bv2-10.txt
> 
> 
> _______________________________________________
> IPCDN mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 
> 
> _______________________________________________
> IPCDN mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 
> _______________________________________________
> IPCDN mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipcdn