From mailman-owner@ietf.org Tue Jan 1 06:25:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11238 for ; Tue, 1 Jan 2002 06:25:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05628 for ; Tue, 1 Jan 2002 06:25:37 -0500 (EST) Date: Tue, 1 Jan 2002 06:25:37 -0500 (EST) Message-Id: <200201011125.GAA05628@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: ipcdn-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ipcdn-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ipcdn-archive@lists.ietf.org: List Password // URL ---- -------- ipcdn@ietf.org BtQa http://www1.ietf.org/mailman/options/ipcdn/ipcdn-archive@lists.ietf.org From daemon@ns.ietf.org Wed Jan 2 15:24:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10095 for ; Wed, 2 Jan 2002 15:24:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20397 for ipcdn-archive@odin.ietf.org; Wed, 2 Jan 2002 15:24:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20303; Wed, 2 Jan 2002 15:21:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20277 for ; Wed, 2 Jan 2002 15:21:47 -0500 (EST) Received: from scbh01.terayon.com ([63.201.251.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10051 for ; Wed, 2 Jan 2002 15:21:44 -0500 (EST) Received: by SCBH01 with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jan 2002 12:21:55 -0800 Message-ID: From: "Raftus, David" To: ipcdn@ietf.org Cc: jason@stargus.com, a.valentine@eu.hns.com, "Rich Woundy (E-mail)" , "Goren, Aviv" , "Raftus, David" Subject: RE: [ipcdn] IPCDN meeting minutes from Salt Lake City Date: Wed, 2 Jan 2002 12:20:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Hi, Regarding the following statement from the Salt Lake meeting minutes: 1. The editors would like to change the permissible range of docsIfUpChannelActiveCodes, and exclude all non-primes. Is it too late to do this? Dave will follow up with mail to the IPCDN reflector. I have submitted an updated version of the RF mib draft, containing the following modifications to the definition and compliance statement sections: docsIfUpChannelScdmaActiveCodes OBJECT-TYPE SYNTAX Unsigned32 (0 | 64..128) MAX-ACCESS read-write STATUS current DESCRIPTION "Applicable for SCDMA channel types only. Number of active codes. Returns zero for Non-SCDMA channel types. Note that legal values from 64..128 MUST be non-prime." REFERENCE "Document [25] from References, Section 6.2.11.2.1." ::= { docsIfUpstreamChannelEntry 11 } OBJECT docsIfUpChannelScdmaActiveCodes MIN-ACCESS read-only DESCRIPTION "This object is always read-only in Cable Modems. The number of active codes when SCDMA is in use must range from 64 to 128, and must be a non- Prime value. Providing this range allows for the following features and capabilities: 1) Power management in S-CDMA spreader-on frames (with a 3 dB spread) 2) Avoidance of code 0 3) Flexible minislot sizes with and without the use of code 0" Regards, Dave ************************************ David Raftus Imedia Semiconductor 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 david.raftus@imedia.com 613.592.1052 ext 222 ************************************ -----Original Message----- From: Rich Woundy [mailto:rwoundy@cisco.com] Sent: Friday, December 21, 2001 2:50 PM To: ipcdn@ietf.org Cc: jason@stargus.com; a.valentine@eu.hns.com Subject: [ipcdn] IPCDN meeting minutes from Salt Lake City Folks, Could you verify the IPCDN meeting minutes below by December 28? I believe that I need to submit the completed minutes by January 4 for inclusion in the IETF proceedings. I would especially like to thank Jason Schnitzer for taking notes at the meeting, and Andrew Valentine for running the meeting in my absence (with only a few hours notice). Happy holidays! -- Rich IETF IPCDN Meeting Salt Lake City, Utah USA December 10, 2001 Reported by Jason Schnitzer (jason@stargus.com) WG Meeting Summary ------------------ Approximately 30 members of the IP over Cable Data Networks WG met at the Salt Lake City IETF on December 10, 2001. The WG discussed the status of its work items as well as the ongoing charter revision. Special attention was paid in the meeting to the new DOCSIS 2.0 specification and its impact on the DOCSIS RF MIB (RFC2670). Three internet-drafts completed working group last-call, and two internet-drafts started working group last-call at the meeting. Since the last IETF meeting, the WG has submitted five updates to existing internet-drafts. Total meeting time was about one hour. Based on the WG discussion, the chairs will forward the draft "Application of the IGMP MIB to DOCSIS 1.1" to the IESG, followed shortly by the "DOCSIS QoS MIB" and "DOCSIS Subscriber Management MIB" drafts. The latter drafts have some small fixes to address minor concerns raised in last-call. WG Status and Charter Revision ------------------------------ The working group quickly reviewed the overall status of work items in the working group. Three internet-drafts (Application of the IGMP MIB to DOCSIS 1.1, DOCSIS QoS MIB, and DOCSIS Subscriber Management MIB) completed working group last-calls by the date of the meeting, and two additional internet-drafts (DOCSIS RF MIB for DOCSIS 2.0, DOCSIS BPI+ MIB) started working group last-calls at the meeting. The co-chairs have been formulating and proposing significant changes to the WG charter, with updated milestones. The charter is currently under evaluation by our Area Directors. There were no comments from the working group on these issues. DOCSIS 2.0 and RFC2670 (RF Interface MIB) ------------------------------------------ The majority of the working group meeting focused on the DOCSIS 2.0 discussion. David Raftus and Aviv Goren presented the DOCSIS 2.0 technology, and reported on its impacts on the DOCSIS RF Interface MIB (RFC2670). There were a number of questions from the working group, but limited controversy. The following discussion items were noted: 1. The editors would like to change the permissible range of docsIfUpChannelActiveCodes, and exclude all non-primes. Is it too late to do this? Dave will follow up with mail to the IPCDN reflector. 2. A question surrounding the co-existence of IPv4/v6 in the CmtsCmStatusTable. What will this look like in a mixed v4/v6 network? 3. Dave discussed the co-existence strategy and the integration of the DOCS-IF-EXT-MIB originally from the DOCSIS Event Notification MIB, draft-ietf-ipcdn-docsisevent-mib-01. The working group will attempt to resolve these issues during the last-call period, which started at this meeting. DOCSIS Usage of RFC2933 MIB ---------------------------- The working group quickly reviewed the minor changes in draft-ietf-ipcdn-igmp-mib-03.txt, which were the result of comments from the working group last-call. There were no objections from the working group with respect to designation as an informational RFC. DOCSIS 1.1 QoS MIB ------------------ The working group quickly reviewed draft-ietf-ipcdn-qos-mib-06.txt (in last-call), and the proposed response to the last-call comment about ambiguity in the counting of unclassified data packets. There were no objections from the working group. DOCSIS Subscriber Management MIB -------------------------------- The working group quickly reviewed draft-ietf-ipcdn-subscriber-mib-04.txt (in last-call), and the proposed re-homing of the MIB for version -05 to prevent OID conflicts with previous versions of this MIB (version -02 has been deployed as part of DOCSIS 1.1 certification). There were no objections from the working group. BPI+ MIB -------- The working group quickly reviewed draft-ietf-ipcdn-bpiplus-mib-06.txt (in last-call), and reviewed two last-call issues: the mapping of BPI+ dynamic SAIDs to BPI static SAIDs, and the algorithm for choosing the matching row in docsBpi2CmtsIpMulticastMapTable. There were no objections from the working group. Other MIBs (DOCSIS 1.1 Notifications, Cable Device MIB, Euromodem MIBs) ----------------------------------------------------------------------- The working group reviewed the status of the Euromodem MIBs (need conversion to an appropriate archival form due to lack of implementation), the DOCSIS Event Notification MIB (resolve overlap with latest DOCSIS RF Interface MIB and get to last call), and the updated Cable Device MIB (resolve a number of technical issues). Some members of the working group had comments on the Cable Device MIB, but since the author was not present (he left the IETF meeting early due to a family emergency), these issues will be discussed on the IPCDN reflector. _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Wed Jan 2 15:24:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10090; Wed, 2 Jan 2002 15:24:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20303; Wed, 2 Jan 2002 15:21:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20277 for ; Wed, 2 Jan 2002 15:21:47 -0500 (EST) Received: from scbh01.terayon.com ([63.201.251.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10051 for ; Wed, 2 Jan 2002 15:21:44 -0500 (EST) Received: by SCBH01 with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jan 2002 12:21:55 -0800 Message-ID: From: "Raftus, David" To: ipcdn@ietf.org Cc: jason@stargus.com, a.valentine@eu.hns.com, "Rich Woundy (E-mail)" , "Goren, Aviv" , "Raftus, David" Subject: RE: [ipcdn] IPCDN meeting minutes from Salt Lake City Date: Wed, 2 Jan 2002 12:20:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Hi, Regarding the following statement from the Salt Lake meeting minutes: 1. The editors would like to change the permissible range of docsIfUpChannelActiveCodes, and exclude all non-primes. Is it too late to do this? Dave will follow up with mail to the IPCDN reflector. I have submitted an updated version of the RF mib draft, containing the following modifications to the definition and compliance statement sections: docsIfUpChannelScdmaActiveCodes OBJECT-TYPE SYNTAX Unsigned32 (0 | 64..128) MAX-ACCESS read-write STATUS current DESCRIPTION "Applicable for SCDMA channel types only. Number of active codes. Returns zero for Non-SCDMA channel types. Note that legal values from 64..128 MUST be non-prime." REFERENCE "Document [25] from References, Section 6.2.11.2.1." ::= { docsIfUpstreamChannelEntry 11 } OBJECT docsIfUpChannelScdmaActiveCodes MIN-ACCESS read-only DESCRIPTION "This object is always read-only in Cable Modems. The number of active codes when SCDMA is in use must range from 64 to 128, and must be a non- Prime value. Providing this range allows for the following features and capabilities: 1) Power management in S-CDMA spreader-on frames (with a 3 dB spread) 2) Avoidance of code 0 3) Flexible minislot sizes with and without the use of code 0" Regards, Dave ************************************ David Raftus Imedia Semiconductor 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 david.raftus@imedia.com 613.592.1052 ext 222 ************************************ -----Original Message----- From: Rich Woundy [mailto:rwoundy@cisco.com] Sent: Friday, December 21, 2001 2:50 PM To: ipcdn@ietf.org Cc: jason@stargus.com; a.valentine@eu.hns.com Subject: [ipcdn] IPCDN meeting minutes from Salt Lake City Folks, Could you verify the IPCDN meeting minutes below by December 28? I believe that I need to submit the completed minutes by January 4 for inclusion in the IETF proceedings. I would especially like to thank Jason Schnitzer for taking notes at the meeting, and Andrew Valentine for running the meeting in my absence (with only a few hours notice). Happy holidays! -- Rich IETF IPCDN Meeting Salt Lake City, Utah USA December 10, 2001 Reported by Jason Schnitzer (jason@stargus.com) WG Meeting Summary ------------------ Approximately 30 members of the IP over Cable Data Networks WG met at the Salt Lake City IETF on December 10, 2001. The WG discussed the status of its work items as well as the ongoing charter revision. Special attention was paid in the meeting to the new DOCSIS 2.0 specification and its impact on the DOCSIS RF MIB (RFC2670). Three internet-drafts completed working group last-call, and two internet-drafts started working group last-call at the meeting. Since the last IETF meeting, the WG has submitted five updates to existing internet-drafts. Total meeting time was about one hour. Based on the WG discussion, the chairs will forward the draft "Application of the IGMP MIB to DOCSIS 1.1" to the IESG, followed shortly by the "DOCSIS QoS MIB" and "DOCSIS Subscriber Management MIB" drafts. The latter drafts have some small fixes to address minor concerns raised in last-call. WG Status and Charter Revision ------------------------------ The working group quickly reviewed the overall status of work items in the working group. Three internet-drafts (Application of the IGMP MIB to DOCSIS 1.1, DOCSIS QoS MIB, and DOCSIS Subscriber Management MIB) completed working group last-calls by the date of the meeting, and two additional internet-drafts (DOCSIS RF MIB for DOCSIS 2.0, DOCSIS BPI+ MIB) started working group last-calls at the meeting. The co-chairs have been formulating and proposing significant changes to the WG charter, with updated milestones. The charter is currently under evaluation by our Area Directors. There were no comments from the working group on these issues. DOCSIS 2.0 and RFC2670 (RF Interface MIB) ------------------------------------------ The majority of the working group meeting focused on the DOCSIS 2.0 discussion. David Raftus and Aviv Goren presented the DOCSIS 2.0 technology, and reported on its impacts on the DOCSIS RF Interface MIB (RFC2670). There were a number of questions from the working group, but limited controversy. The following discussion items were noted: 1. The editors would like to change the permissible range of docsIfUpChannelActiveCodes, and exclude all non-primes. Is it too late to do this? Dave will follow up with mail to the IPCDN reflector. 2. A question surrounding the co-existence of IPv4/v6 in the CmtsCmStatusTable. What will this look like in a mixed v4/v6 network? 3. Dave discussed the co-existence strategy and the integration of the DOCS-IF-EXT-MIB originally from the DOCSIS Event Notification MIB, draft-ietf-ipcdn-docsisevent-mib-01. The working group will attempt to resolve these issues during the last-call period, which started at this meeting. DOCSIS Usage of RFC2933 MIB ---------------------------- The working group quickly reviewed the minor changes in draft-ietf-ipcdn-igmp-mib-03.txt, which were the result of comments from the working group last-call. There were no objections from the working group with respect to designation as an informational RFC. DOCSIS 1.1 QoS MIB ------------------ The working group quickly reviewed draft-ietf-ipcdn-qos-mib-06.txt (in last-call), and the proposed response to the last-call comment about ambiguity in the counting of unclassified data packets. There were no objections from the working group. DOCSIS Subscriber Management MIB -------------------------------- The working group quickly reviewed draft-ietf-ipcdn-subscriber-mib-04.txt (in last-call), and the proposed re-homing of the MIB for version -05 to prevent OID conflicts with previous versions of this MIB (version -02 has been deployed as part of DOCSIS 1.1 certification). There were no objections from the working group. BPI+ MIB -------- The working group quickly reviewed draft-ietf-ipcdn-bpiplus-mib-06.txt (in last-call), and reviewed two last-call issues: the mapping of BPI+ dynamic SAIDs to BPI static SAIDs, and the algorithm for choosing the matching row in docsBpi2CmtsIpMulticastMapTable. There were no objections from the working group. Other MIBs (DOCSIS 1.1 Notifications, Cable Device MIB, Euromodem MIBs) ----------------------------------------------------------------------- The working group reviewed the status of the Euromodem MIBs (need conversion to an appropriate archival form due to lack of implementation), the DOCSIS Event Notification MIB (resolve overlap with latest DOCSIS RF Interface MIB and get to last call), and the updated Cable Device MIB (resolve a number of technical issues). Some members of the working group had comments on the Cable Device MIB, but since the author was not present (he left the IETF meeting early due to a family emergency), these issues will be discussed on the IPCDN reflector. _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Wed Jan 16 09:59:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09942; Wed, 16 Jan 2002 09:59:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03784; Wed, 16 Jan 2002 09:57:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03748 for ; Wed, 16 Jan 2002 09:57:49 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09904 for ; Wed, 16 Jan 2002 09:57:46 -0500 (EST) Received: from goblet.cisco.com (mirapoint@goblet.cisco.com [161.44.168.80]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA07508; Wed, 16 Jan 2002 09:57:18 -0500 (EST) Received: from rwoundy-w2k.cisco.com (ch2-dhcp150-48.cisco.com [161.44.150.48]) by goblet.cisco.com (Mirapoint) with ESMTP id AAM28632; Wed, 16 Jan 2002 09:57:17 -0500 (EST) Message-Id: <4.3.2.7.2.20020116094137.01633530@goblet.cisco.com> X-Sender: rwoundy@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Jan 2002 09:59:34 -0500 To: docsis-macup@cablelabs.com, docsis-oss@cablelabs.com, ipcdn@ietf.org From: Rich Woundy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] Fwd: [dhcwg] Protocol Action: Addition of Device Class to Agent Options to Proposed Standard Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Folks, The information in this email pertains to the following requirement in the DOCSIS 1.1 RFI, section 6.3.24: "The CMTS MUST retain the device class information for use in the DHCP Process. The CMTS MUST create a DHCP Agent Option 82 tuple with the device class information and MUST insert this tuple in the DHCPDISCOVER from the corresponding CM before forwarding that DHCPDISCOVER to the DHCP server." The DHCP DCI suboption draft is on the RFC editor's queue . The RFC editor's queue is the final step before RFC publication; by publication time, the draft's suboption code (currently "TBD" in sections 2 and 4 of the draft) must be replaced with an official number from IANA. I received some email from IANA in October that suggests that they might choose suboption code 4 for this draft. Some folks from various companies (Cisco and others) are accepting some risk and implementing this draft with TBD = 4. Note that IANA could choose some other value, so implementing with this value entails some risk. The DHC working group chair (Ralph Droms) has sent email this week to IANA, requesting them to make a permanent assignment of this option code prior to RFC publication, so everyone can act on official (and common) information. When I get more information, I will forward it to these mailing lists: docsis-oss, docsis-macup, and ipcdn. -- Rich >To: IETF-Announce: ; >Cc: RFC Editor , Internet Architecture Board >, > dhcwg@ietf.org >From: The IESG >Date: Wed, 09 Jan 2002 15:17:29 -0500 >Subject: [dhcwg] Protocol Action: Addition of Device Class to Agent Options to > Proposed Standard >Sender: dhcwg-admin@ietf.org >X-Mailman-Version: 1.0 >List-Id: >X-BeenThere: dhcwg@ietf.org > > > >The IESG has approved the Internet-Draft 'Addition of Device Class to >Agent Options' as a >Proposed Standard. This document is the product of the Dynamic Host >Configuration Working Group. The IESG contact persons are Erik >Nordmark and Thomas Narten. > > >Technical Summary > >This document defines a new sub-option to the DHCP Relay Information >Agent Option. This new sub-option is for use with DOCSIS cable modems >and describes a "device class" to which the cable modem belongs. The >cable modem signals its device class information to the Relay Agent >using DOCSIS signalling, and the Relay Agent forwards the device class >information to the DHCP Server as part of DHCP request that it relays >from the modem. The DHCP server which can then make a policy decision >based on it. > >Working Group Summary > >There was consensus for this document and no issues were raised during >the Last Call. > >Protocol Quality > >This specification has been reviewed for the IESG by Thomas Narten. > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From daemon@optimus.ietf.org Wed Jan 16 10:54:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09947 for ; Wed, 16 Jan 2002 09:59:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA03864 for ipcdn-archive@odin.ietf.org; Wed, 16 Jan 2002 09:59:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03784; Wed, 16 Jan 2002 09:57:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03748 for ; Wed, 16 Jan 2002 09:57:49 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09904 for ; Wed, 16 Jan 2002 09:57:46 -0500 (EST) Received: from goblet.cisco.com (mirapoint@goblet.cisco.com [161.44.168.80]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA07508; Wed, 16 Jan 2002 09:57:18 -0500 (EST) Received: from rwoundy-w2k.cisco.com (ch2-dhcp150-48.cisco.com [161.44.150.48]) by goblet.cisco.com (Mirapoint) with ESMTP id AAM28632; Wed, 16 Jan 2002 09:57:17 -0500 (EST) Message-Id: <4.3.2.7.2.20020116094137.01633530@goblet.cisco.com> X-Sender: rwoundy@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Jan 2002 09:59:34 -0500 To: docsis-macup@cablelabs.com, docsis-oss@cablelabs.com, ipcdn@ietf.org From: Rich Woundy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] Fwd: [dhcwg] Protocol Action: Addition of Device Class to Agent Options to Proposed Standard Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Folks, The information in this email pertains to the following requirement in the DOCSIS 1.1 RFI, section 6.3.24: "The CMTS MUST retain the device class information for use in the DHCP Process. The CMTS MUST create a DHCP Agent Option 82 tuple with the device class information and MUST insert this tuple in the DHCPDISCOVER from the corresponding CM before forwarding that DHCPDISCOVER to the DHCP server." The DHCP DCI suboption draft is on the RFC editor's queue . The RFC editor's queue is the final step before RFC publication; by publication time, the draft's suboption code (currently "TBD" in sections 2 and 4 of the draft) must be replaced with an official number from IANA. I received some email from IANA in October that suggests that they might choose suboption code 4 for this draft. Some folks from various companies (Cisco and others) are accepting some risk and implementing this draft with TBD = 4. Note that IANA could choose some other value, so implementing with this value entails some risk. The DHC working group chair (Ralph Droms) has sent email this week to IANA, requesting them to make a permanent assignment of this option code prior to RFC publication, so everyone can act on official (and common) information. When I get more information, I will forward it to these mailing lists: docsis-oss, docsis-macup, and ipcdn. -- Rich >To: IETF-Announce: ; >Cc: RFC Editor , Internet Architecture Board >, > dhcwg@ietf.org >From: The IESG >Date: Wed, 09 Jan 2002 15:17:29 -0500 >Subject: [dhcwg] Protocol Action: Addition of Device Class to Agent Options to > Proposed Standard >Sender: dhcwg-admin@ietf.org >X-Mailman-Version: 1.0 >List-Id: >X-BeenThere: dhcwg@ietf.org > > > >The IESG has approved the Internet-Draft 'Addition of Device Class to >Agent Options' as a >Proposed Standard. This document is the product of the Dynamic Host >Configuration Working Group. The IESG contact persons are Erik >Nordmark and Thomas Narten. > > >Technical Summary > >This document defines a new sub-option to the DHCP Relay Information >Agent Option. This new sub-option is for use with DOCSIS cable modems >and describes a "device class" to which the cable modem belongs. The >cable modem signals its device class information to the Relay Agent >using DOCSIS signalling, and the Relay Agent forwards the device class >information to the DHCP Server as part of DHCP request that it relays >from the modem. The DHCP server which can then make a policy decision >based on it. > >Working Group Summary > >There was consensus for this document and no issues were raised during >the Last Call. > >Protocol Quality > >This specification has been reviewed for the IESG by Thomas Narten. > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn