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

["Jean-Francois Mule" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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: [e-mail] [mailto:[e-mail]]On Behalf
> Of
> 
> > Brian Hedstrom
> > Sent: Monday, December 19, 2005 20:23
> > To: [e-mail]
> > 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
> > [e-mail]
> >
> >
> > -----Original Message-----
> > From: The IESG [mailto:[e-mail]]
> > Sent: Wednesday, December 14, 2005 9:44 AM
> > To: IETF-Announce
> > Cc: [e-mail]
> > 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
> > [e-mail] or [e-mail] 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 
> 
> _______________________________________________
> IPCDN mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 
> _______________________________________________
> IPCDN mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ipcdn



_______________________________________________
IPCDN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn