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]>]

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