Subject: RE: [ipcdn] Last Call: 'Cable Device Management Information Base for Data-Over-Cable Service Interface Specification Compliant Cable Modem s and Cable Modem Termination Systems' to Proposed Standard

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 21 Dec 2005 18:38:33 +0100

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

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