From mailman-admin@ietf.org Sun Dec 1 10:55:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08667 for ; Sun, 1 Dec 2002 10:55:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB1Fvxv15703 for ; Sun, 1 Dec 2002 10:57:59 -0500 Date: Sun, 01 Dec 2002 10:57:59 -0500 Message-ID: <20021201155759.8899.68931.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: DHC-ARCHIVE@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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, dhcwg-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for DHC-ARCHIVE@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org aCBd https://www1.ietf.org/mailman/options/dhcwg/dhc-archive%40lists.ietf.org From dhcwg-admin@ietf.org Sun Dec 1 14:44:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14337; Sun, 1 Dec 2002 14:44:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB1JiUv28927; Sun, 1 Dec 2002 14:44:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB1Jf5v28850 for ; Sun, 1 Dec 2002 14:41:05 -0500 Received: from web10907.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14246 for ; Sun, 1 Dec 2002 14:38:10 -0500 (EST) Message-ID: <20021201194058.13741.qmail@web10907.mail.yahoo.com> Received: from [80.128.12.204] by web10907.mail.yahoo.com via HTTP; Sun, 01 Dec 2002 11:40:58 PST Date: Sun, 1 Dec 2002 11:40:58 -0800 (PST) From: "Petar Chobanov Pi." To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-727659751-1038771658=:12810" Subject: [dhcwg] unsubscribe please Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --0-727659751-1038771658=:12810 Content-Type: text/plain; charset=us-ascii Please unsubscribe this Email Address: TchobanovPeter@Yahoo.com best regards P. Chobanov +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Best Regards from | | PETAR K. CHOBANOV | | ¶:) 1. Chobanov@Mac.Com | | ¶:) 2. Chobanov@in.tum.de | | ¶:) 3. ChobanovPetar@Yahoo.Com | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now --0-727659751-1038771658=:12810 Content-Type: text/html; charset=us-ascii

Please unsubscribe this Email Address:

TchobanovPeter@Yahoo.com

best regards

P. Chobanov



+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| Best Regards from |
| PETAR K. CHOBANOV |
| ¶:) 1. Chobanov@Mac.Com |
| ¶:) 2. Chobanov@in.tum.de |
| ¶:) 3. ChobanovPetar@Yahoo.Com |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now --0-727659751-1038771658=:12810-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Dec 1 23:06:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22924; Sun, 1 Dec 2002 23:06:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB248cv20058; Sun, 1 Dec 2002 23:08:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB245Jv19392 for ; Sun, 1 Dec 2002 23:05:19 -0500 Received: from arianne.in.ishoni.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22861 for ; Sun, 1 Dec 2002 23:02:18 -0500 (EST) Received: from leonoid.in.ishoni.com (leonoid.in.ishoni.com [192.168.1.12]) by arianne.in.ishoni.com (8.11.6/Ishonir2) with ESMTP id gB248ht05643 for ; Mon, 2 Dec 2002 09:38:44 +0530 Received: by leonoid.in.ishoni.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Dec 2002 09:38:34 +0530 Message-ID: <7CFD7CA8510CD6118F950002A519EA3003A15D57@leonoid.in.ishoni.com> From: Archana Gudi To: dhcwg@ietf.org Date: Mon, 2 Dec 2002 09:38:33 +0530 X-MS-TNEF-Correlator: <7CFD7CA8510CD6118F950002A519EA3003A15D57@leonoid.in.ishoni.com> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C299B8.7B1C4E40" Subject: [dhcwg] unsubscribe please Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C299B8.7B1C4E40 Content-Type: text/plain; charset="iso-8859-1" Please unsubscribe this Email Address: archanag@ishoni.com best regards Archana Gudi ------_=_NextPart_000_01C299B8.7B1C4E40 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IiMEAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0gcMAAIACQAmACEAAQA4AQEggAMADgAAANIHDAAC AAkAJgAhAAEAOAEBCYABACEAAABGN0M2OThFODUxMDNENzExODFEMjAwQzA0RjBDQ0Q2QwApBwEE gAEAEwAAAHVuc3Vic2NyaWJlIHBsZWFzZQA/BwENgAQAAgAAAAIAAgABA5AGAMwIAAAxAAAACwAC AAEAAAADAC4AAAAAAEAAOQBAThx7uJnCAR4AcAABAAAAGwAAAFtkaGN3Z10gdW5zdWJzY3JpYmUg cGxlYXNlAAACAXEAAQAAABsAAAABwpl+IYg8Q0z+BWYR153tAJAn5ThzAA7sFkAAHgAxQAEAAAAI AAAAQVJDSEFOQQADABpAAAAAAB4AMEABAAAACAAAAEFSQ0hBTkEAAwAZQAAAAAACAQkQAQAAAKoD AACmAwAADQsAAExaRnWFEV9vAwAKAHJjcGcxMjWCMgNDaHRtbDEDMD8BAwH3CoACpAPjAgBjaMEK wHNldDAgBxMCgP8QAwBQBFYIVQeyEdUOUQMB3RDXMgYABsMR1TMERhDZ+RLvZjQQbxF2EeMI7wn3 9jsavw4wNRvfHOMR4QxgzmMAUAsJAWQzNhFgC6VkNCAQAipcDrIBkGcBILAzIDwhRE9DAFRZUEUg SFRNAEwgUFVCTElDACAiLS8vVzNDkSNwRFREIoQ0LhFg5FRyAHJ0aQIgB0AjcPBFTiI+EeMhJyHQ CqP5JdwxOSHgIpIlziDAKDD4RUFEJc0O8SbvKt8ntAI2DvA8TUVUQSDHBaACMAnwdD0iBeAik0I1 JIAwLjI5KAAuwDYzMDciICVAB4AEPUclkEVSQVRP6lIlzTQtoS8pvyGRLE8FIYE1EWA8Qk9EWUcl zSAxM69nOTY04UyBIiBLUVVPVEUlwPshMwAhIAAAOJURYDVvNn+vILARYDwQJdw2KYFQOG8ROXNc bGkgElBsZZJhETAgdQCAdWIE8pJiP5B0aAQAIEUAwLEDEUFkZBrABBA6PZb/CqI9hwpyPaYKokMI Oa0BwP8yET1hOc863zvvPP8+DyAhrSDrOCmBLgBoGsBmLpBxQNJ0bzoKwBDxJUBnSkAEAGgCIGku BaBtZCZuP/BwOyWxSdlmaQiQbGQhAmZQIAuAcyh0e0giUVIjEE5LByNATR9OJ1wnYTAifxnQAfFQ IBEgIXAaIABBdYcDIUQvTAdTUEFORuSNSFBjC2AEED05NCAgADgxODA0LTAyPw4gAdBYQEm/VS8O EDQ4gSHgRk9OVCBmANDvMFAHE1bGAJB6MFBYvBgw/wOyAdBUyVIvA3BVfk60WNjXU1JZjyelNTeR L1tCWMn7Qmgg3DlFklaCZJ8+hGeP92ifZa9mtEEp/i2ANOEw8fNDKD7gbmVD/1XPVt9X789Y/1oP WxYaMz0jL0AvQP8BIFuPXJ9zYlRgM3Fd72MP/2Qfam9mP2dPaZxCL0M/fL//RV9Gb0d/SI9Jn0qv b79wwP9xX3Jvc39gn2GvjZ99z37f60BAUNAgGsBnCxEYsH///4EPgh+DL4Q/hU+GX4dviH//iY+K n4uvnI+XP3UPdh93L494P3lPBxBfMyBHdVCg/44Pjx+QL3qve7+r75Gffu//lH+Vj5afl68nLaBw MhE3z7+uLzQaWxG3UDUfIaA3MhILKF8mp329wAAAHgBCEAEAAAA1AAAAPDIwMDIxMjAxMTk0MDU4 LjEzNzQxLnFtYWlsQHdlYjEwOTA3Lm1haWwueWFob28uY29tPgAAAAADAN4/r28AAAMAAlkAABYA AwAJWQIAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAABShQAAJ2oBAB4ABIAIIAYAAAAAAMAAAAAA AABGAAAAAFSFAAABAAAABAAAADkuMAAeAAWACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEA AAAAAAAAHgAGgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AB4AIIAYAAAAA AMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAALAAiACCAGAAAAAADAAAAAAAAARgAAAACChQAA AQAAAB4ACYAIIAYAAAAAAMAAAAAAAABGAAAAAIOFAAABAAAAEwAAADk0NjA4MTgwNC0wMjEyMjAw MgAAAwALgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAALABCACCAGAAAAAADAAAAAAAAARgAA AAAGhQAAAAAAAAMADIAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwAKgAggBgAAAAAAwAAA AAAAAEYAAAAAA4UAAAAAAAALAA2ACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMADoAIIAYA AAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAPgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAD APE/CQQAAAMAJgAAAAAAAwA2AAAAAAADAP0/5AQAAAMAgBD/////AgFHAAEAAAAwAAAAYz1VUzth PSA7cD1pc2hvbmk7bD1MRU9OT0lELTAyMTIwMjA0MDgzM1otMTE2MjMAHgA4QAEAAAAIAAAAQVJD SEFOQQAeADlAAQAAAAgAAABBUkNIQU5BAEAABzAiUxx7uJnCAUAACDCmKjR7uJnCAR4APQABAAAA AQAAAAAAAAAeAB0OAQAAABMAAAB1bnN1YnNjcmliZSBwbGVhc2UAAB4ANRABAAAAQQAAADw3Q0ZE N0NBODUxMENENjExOEY5NTAwMDJBNTE5RUEzMDAzQTE1RDU3QGxlb25vaWQuaW4uaXNob25pLmNv bT4AAAAACwApAAAAAAALACMAAAAAAAMABhDkzYSjAwAHEGQAAAADABAQAAAAAAMAERAAAAAAHgAI EAEAAABlAAAAUExFQVNFVU5TVUJTQ1JJQkVUSElTRU1BSUxBRERSRVNTOjxNQUlMVE86QVJDSEFO QUdASVNIT05JQ09NQVJDSEFOQUdASVNIT05JQ09NQkVTVFJFR0FSRFNBUkNIQU5BR1VESQAAAAAC AX8AAQAAAEEAAAA8N0NGRDdDQTg1MTBDRDYxMThGOTUwMDAyQTUxOUVBMzAwM0ExNUQ1N0BsZW9u b2lkLmluLmlzaG9uaS5jb20+AAAAAGYT ------_=_NextPart_000_01C299B8.7B1C4E40-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Dec 3 08:03:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17550; Tue, 3 Dec 2002 08:03:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3D57v05201; Tue, 3 Dec 2002 08:05:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3D1Pv05065 for ; Tue, 3 Dec 2002 08:01:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16796; Tue, 3 Dec 2002 07:58:33 -0500 (EST) Message-Id: <200212031258.HAA16796@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 03 Dec 2002 07:58:32 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : IPv6 Prefix Options for DHCPv6 Author(s) : O. Troan, R. Droms Filename : draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt Pages : 18 Date : 2002-12-2 The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using DHCP. This mechanism is intended for delegating long-lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-2135606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-2135606.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Dec 7 13:41:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04035; Sat, 7 Dec 2002 13:41:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB7IhFv27132; Sat, 7 Dec 2002 13:43:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gASDwSv21534 for ; Thu, 28 Nov 2002 08:58:28 -0500 Received: from scooter.gcal.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27960 for ; Thu, 28 Nov 2002 08:55:40 -0500 (EST) Received: from exch1.gcal.ac.uk (GCUEXCH.gcal.ac.uk) [193.62.224.40] by scooter.gcal.ac.uk; Thu, 28 Nov 2002 13:58:22 +0000 Received: by GCUEXCH.gcal.ac.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Nov 2002 13:58:23 -0000 Message-ID: From: Boyle Bernadette To: "'dhcwg@ietf.org'" Date: Thu, 28 Nov 2002 13:58:20 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C296E6.35D82F40" Subject: [dhcwg] using omapi for failover on dhcp Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C296E6.35D82F40 Content-Type: text/plain Hello, I have two dhcp machines running on redhat 7.2 and I want to use the omshell to inform the primary server that the second one will be down on day x. I'm having trouble trying to find information on how to go about this. If anyone could point me in the right direction I'd be very grateful. Bernadette ---------------------------------------------------------------------------- ----------------------- Bernadette Boyle b.boyle@gcal.ac.uk 0141 331 8822 ---------------------------------------------------------------------------- -------------------------- ------_=_NextPart_001_01C296E6.35D82F40 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Hello,

 

I have two dhcp machines = running on redhat 7.2 and I want to use the omshell to inform the primary server that the = second one will be down on day x. I'm having trouble trying to find information on how to go about this.

 

If anyone could point me in the right direction I'd = be very grateful.

 

Bernadette

 

= ------------------------------------------------------------------------= ---------------------------

= Bernadette Boyle

= b.boyle@gcal.ac.uk

= 0141 331 8822

= ------------------------------------------------------------------------= ------------------------------

=

 

------_=_NextPart_001_01C296E6.35D82F40-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Dec 7 13:41:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04034; Sat, 7 Dec 2002 13:41:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB7Ihav27150; Sat, 7 Dec 2002 13:43:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB7GtVv21902 for ; Sat, 7 Dec 2002 11:55:31 -0500 Received: from gw.xargs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01630 for ; Sat, 7 Dec 2002 11:52:34 -0500 (EST) Received: (qmail 3265 invoked from network); 7 Dec 2002 16:55:26 -0000 Received: from gw.xargs.com (democracy@192.168.11.1) by gw.xargs.com with SMTP; 7 Dec 2002 16:55:26 -0000 Date: Sat, 7 Dec 2002 08:55:26 -0800 (PST) From: Thamer Al-Harbash X-X-Sender: shadows@gw.xargs.com To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] rfc2131 and releasing leases Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi, I understand under rfc2131 that there is no way to acknowledge a release from a DHCP client. Are there any extensions, or any plans on incorporating a release acknowledgement? Problem: Client sends DHCP release. Client shuts down. Server doesn't get the release datagram because it was dropped before it reached the Server. The server holds onto the lease. How is this scenario avoided by the server if no acknowledgement is ever sent to the client? The problem becomes worse when the client machine reboots to another OS and tries to acquire the same lease with a different client-id. -- Thamer Al-Harbash http://www.whitefang.com/ team dresch made me do it _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Dec 9 21:44:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14295; Mon, 9 Dec 2002 21:44:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBA2kOv18567; Mon, 9 Dec 2002 21:46:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBA2iAv18497 for ; Mon, 9 Dec 2002 21:44:10 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14257 for ; Mon, 9 Dec 2002 21:41:05 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBA2iTfr017799 for ; Mon, 9 Dec 2002 21:44:30 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-266.cisco.com [10.82.241.10]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA15150 for ; Mon, 9 Dec 2002 21:43:57 -0500 (EST) Message-Id: <4.3.2.7.2.20021209143603.01a32b10@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Dec 2002 17:08:26 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_17384597==_.ALT" Subject: [dhcwg] Editorial changes to DHCPv6 specification Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --=====================_17384597==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed FYI...The IESG has requested changes in two sections of draft-ietf-dhc-dhcpv6-28.txt, prior to its acceptance as a Proposed Standard and publication as an RFC. The changes are noted in the text included below from sections 21.1 and 23. The change is motivated by the observation that manual keying does not prevent replay attacks. The sentence identified in the first paragraph of 21.1 will be removed. The list item labeled "Key Management" will be replaced with the text shown below. The previous text mentioned only manual keying. The indicated (last) paragraph in section 23 will be added. - Ralph ===== 21.1. Security of Messages Sent Between Servers and Relay Agents Relay agents and servers that exchange messages securely use the | IPsec mechanisms for IPv6 [11]. Relay agents and servers MUST | support manual configuration and installation of static keys. If | a client message is relayed through multiple relay agents, each of the relay agents must have established independent, pairwise trust relationships. That is, if messages from client C will be relayed by relay agent A to relay agent B and then to the server, relay agents A and B must be configured to use IPSec for the messages they exchange, and relay agent B and the server must be configured to use IPSec for the messages they exchange. Relay agents and servers that support secure relay agent to server or relay agent to relay agent communication use IPsec under the following conditions: Selectors Relay agents are manually configured with the addresses of the relay agent or server to which DHCP messages are to be forwarded. Each relay agent and server that will be using IPsec for securing DHCP messages must also be configured with a list of the relay agents to which messages will be returned. The selectors for the relay agents and servers will be the pairs of addresses defining relay agents and servers that exchange DHCP messages on the DHCPv6 UDP ports 546 and 547. Mode Relay agents and servers use transport mode and ESP. The information in DHCP messages is not generally considered confidential, so encryption need not be used (i.e., NULL encryption can be used). | Key management Because the relay agents and servers are used | within an organization, public key schemes are | not necessary. Because the relay agents and | servers must be manually configured, manually | configured key management may suffice, but | doesn't provide defense against replayed | messages. Accordingly, IKE with preshared | secrets SHOULD be supported. IKE with public | keys MAY be supported. Security policy DHCP messages between relay agents and servers should only be accepted from DHCP peers as identified in the local configuration. Authentication Shared keys, indexed to the source IP address of the received DHCP message, are adequate in this application. Availability Appropriate IPsec implementations are likely to be available for servers and for relay agents in more featureful devices used in enterprise and core ISP networks. IPsec is less likely to be available for relay agents in low end devices primarily used in the home or small office markets. 23. Security Considerations [...] Communication between a server and a relay agent and communication between relay agents can be secured through the use of IPSec, as described in section 21.1. The use of manual configuration and installation of static keys are acceptable in this instance because relay agents and the server will belong to the same administrative domain and the relay agents will require other specific configuration (for example, configuration of the DHCP server address) as well as the IPSec configuration. | Use of manually configured preshared keys for IPsec | between relay agents and servers does not defend against | replayed DHCP messages. Replayed messages can | represent a DOS attack through exhaustion of | processing resources, but not through mis-configuration | or exhaustion of other resources such as assignable addresses. --=====================_17384597==_.ALT Content-Type: text/html; charset="us-ascii" FYI...The IESG has requested changes in two sections of draft-ietf-dhc-dhcpv6-28.txt, prior to its acceptance as a Proposed Standard and publication as an RFC.  The changes are noted in the text included below from sections 21.1 and 23.  The change is motivated by the observation that manual keying does not prevent replay attacks.

The sentence identified in the first paragraph of 21.1 will be removed.  The list item labeled "Key Management" will be replaced with the text shown below.  The previous text mentioned only manual keying.  The indicated (last) paragraph in section 23 will be added.

- Ralph

=====

21.1. Security of Messages Sent Between Servers and Relay Agents

   Relay agents and servers that exchange messages securely use the
|  IPsec mechanisms for IPv6 [11].  Relay agents and servers MUST
|  support manual configuration and installation of static keys.  If
|  a client message is relayed through multiple relay agents, each of
   the relay agents must have established independent, pairwise trust
   relationships.  That is, if messages from client C will be relayed by
   relay agent A to relay agent B and then to the server, relay agents A
   and B must be configured to use IPSec for the messages they exchange,
   and relay agent B and the server must be configured to use IPSec for
   the messages they exchange.

   Relay agents and servers that support secure relay agent to server
   or relay agent to relay agent communication use IPsec under the
   following conditions:

      Selectors        Relay agents are manually configured with the
                       addresses of the relay agent or server to which
                       DHCP messages are to be forwarded.  Each relay
                       agent and server that will be using IPsec for
                       securing DHCP messages must also be configured
                       with a list of the relay agents to which messages
                       will be returned.  The selectors for the relay
                       agents and servers will be the pairs of addresses
                       defining relay agents and servers that exchange
                       DHCP messages on the DHCPv6 UDP ports 546 and
                       547.

      Mode             Relay agents and servers use transport mode and
                       ESP. The information in DHCP messages is not
                       generally considered confidential, so encryption
                       need not be used (i.e., NULL encryption can be
                       used).

|     Key management   Because the relay agents and servers are used
|                      within an organization, public key schemes are
|                      not necessary.  Because the relay agents and
|                      servers must be manually configured, manually
|                      configured key management may suffice, but
|                      doesn't provide defense against replayed
|                      messages.  Accordingly, IKE with preshared
|                      secrets SHOULD be supported.  IKE with public
|                      keys MAY be supported.

      Security policy  DHCP messages between relay agents and servers
                       should only be accepted from DHCP peers as
                       identified in the local configuration.

      Authentication   Shared keys, indexed to the source IP address of
                       the received DHCP message, are adequate in this
                       application.

      Availability     Appropriate IPsec implementations are likely to
                       be available for servers and for relay agents in
                       more featureful devices used in enterprise and
                       core ISP networks.  IPsec is less likely to be
                       available for relay agents in low end devices
                       primarily used in the home or small office
                       markets.

23. Security Considerations
   [...]

   Communication between a server and a relay agent and communication
   between relay agents can be secured through the use of IPSec, as
   described in section 21.1.  The use of manual configuration and
   installation of static keys are acceptable in this instance because
   relay agents and the server will belong to the same administrative
   domain and the relay agents will require other specific configuration
   (for example, configuration of the DHCP server address) as well as
   the IPSec configuration.

|  Use of manually configured preshared keys for IPsec
|  between relay agents and servers does not defend against
|  replayed DHCP messages.  Replayed messages can
|  represent a DOS attack through exhaustion of
|  processing resources, but not through mis-configuration
|  or exhaustion of other resources such as assignable addresses.
--=====================_17384597==_.ALT-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Dec 11 20:47:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28718; Wed, 11 Dec 2002 20:47:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBC1mwv03850; Wed, 11 Dec 2002 20:48:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBC1lIv03791 for ; Wed, 11 Dec 2002 20:47:18 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28628 for ; Wed, 11 Dec 2002 20:44:13 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id gBC1l6qW026160; Wed, 11 Dec 2002 18:47:06 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C2A180.602B29C4" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 11 Dec 2002 18:47:06 -0700 Message-ID: X-MS-Has-Attach: yes Thread-Topic: draft-ietf-dhc-suboptions-kdc-serveraddress-02 Thread-Index: AcKhgF+TrdwkvkokTN+08+yIxx6qLg== From: "Kevin Luehrs" To: Cc: "John Bevilacqua" , X-Approved: ondar Subject: [dhcwg] draft-ietf-dhc-suboptions-kdc-serveraddress-02 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2A180.602B29C4 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C2A180.602B29C4" ------_=_NextPart_002_01C2A180.602B29C4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A revision to the 'KDC Server Address sub-option' of the CableLabs Client Configuration (CCC) Option is attached, hereby submitted to update draft-ietf-dhc-suboptions-kdc-serveraddress-01. The attached version updates the reference to the 'DHCP Option for CableLabs Client Configuration' i-d. <>=20 Regards, Kevin Luehrs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Kevin Luehrs Project Director, CableHome Engineering CableLabs 400 Centennial Parkway Louisville, CO 80027 303 661 9100 fax 303 661 9199 k.luehrs@cablelabs.com ------_=_NextPart_002_01C2A180.602B29C4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-dhc-suboptions-kdc-serveraddress-02

A revision to the 'KDC Server Address = sub-option' of the CableLabs Client Configuration (CCC) Option is = attached, hereby submitted to update = draft-ietf-dhc-suboptions-kdc-serveraddress-01. The attached version = updates the reference to the 'DHCP Option for CableLabs Client = Configuration' i-d.

= <<draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt>> =

Regards,

        Kevin Luehrs

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Luehrs
Project Director, CableHome = Engineering
CableLabs
400 Centennial Parkway
Louisville, CO 80027
303 661 9100
fax 303 661 9199
k.luehrs@cablelabs.com

------_=_NextPart_002_01C2A180.602B29C4-- ------_=_NextPart_001_01C2A180.602B29C4 Content-Type: text/plain; name="draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt Content-Disposition: attachment; filename="draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQoNCg0KDQoNCklOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSy4gTHVlaHJzDQpEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBXb3JraW5nIEdy b3VwICAgICAgICAgICAgICAgIENhYmxlTGFicw0KRXhwaXJlcyBKdW5lIDIwMDMgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSLiBXb3VuZHkNCgkJCQkJCQlBVCZUIEJyb2Fk YmFuZA0KCQkJCQkJCUouIEJldmlsYWNxdWEgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFlBUyBDb3Jwb3JhdGlvbiAgIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEZWNlbWJlciAy MDAyDQoNCg0KCQlLREMgU2VydmVyIEFkZHJlc3MgU3ViLW9wdGlvbiANCiAgICAgICAgIDxkcmFm dC1pZXRmLWRoYy1zdWJvcHRpb25zLWtkYy1zZXJ2ZXJhZGRyZXNzLTAyLnR4dD4NCg0KU3RhdHVz IG9mIHRoaXMgTWVtbw0KDQogICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFu ZCBpcyBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGgNCiAgIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rp b24gMTAgb2YgUkZDMjAyNi4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3Vt ZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBp dHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdy b3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0K ICAgRHJhZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxp ZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCANCiAgIG1vbnRocyBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJl cGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzDQogICBhdCBhbnkgdGltZS4g IEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyANCiAgIHJlZmVy ZW5jZSBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9n cmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBh Y2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0 DQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4g YmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCkNv cHlyaWdodCBOb3RpY2UNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAo MjAwMikuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuDQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1l bnQgZGVmaW5lcyBhIG5ldyBzdWItb3B0aW9uIGZvciB0aGUgQ2FibGVMYWJzIENsaWVudA0KICAg Q29uZmlndXJhdGlvbiAoQ0NDKSBESENQIG9wdGlvbiBjb2RlIGZvciBjb252ZXlpbmcgdGhlIG5l dHdvcmsgDQogICBhZGRyZXNzZXMgb2YgS2V5IERpc3RyaWJ1dGlvbiBDZW50ZXIgKEtEQykgc2Vy dmVycy4NCg0KMS4gIEludHJvZHVjdGlvbg0KDQogICBUaGUgbmVlZCBmb3IgYSBDQ0MgREhDUCBP cHRpb24gY29kZSBpcyBkZXNjcmliZWQgaW4gWzFdLiBUaGUgQ0NDIA0KICAgREhDUCBvcHRpb24g Y29kZSB3aWxsIGJlIHVzZWQgdG8gYWRkcmVzcyBzcGVjaWZpYyBuZWVkcyBvZiBDYWJsZUxhYnMN CiAgIGNsaWVudCBkZXZpY2VzIGR1cmluZyB0aGVpciBjb25maWd1cmF0aW9uIHByb2Nlc3Nlcy4g VGhpcyBkb2N1bWVudCANCiAgIHByb3Bvc2VzIGEgc3ViLW9wdGlvbiBmb3IgdGhlIENDQyBESENQ IG9wdGlvbi4NCiAgIA0KICAgDQogICANCiAgIA0KICAgDQogICANCiAgIEx1ZWhycywgV291bmR5 LCAmIEJldmlsYWNxdWEgICAgICAgIEV4cGlyZXMgSnVuZSAyMDAzICAgICAgICAgW1BhZ2UgMV0M ICAgSW50ZXJuZXQgRHJhZnQJICBLREMgU2VydmVyIEFkZHJlc3MgU3ViLW9wdGlvbiAgICAgICBE ZWNlbWJlciAyMDAyDQogICANCiAgIA0KICAgQ29uZmlndXJhdGlvbiBvZiBhIGNsYXNzIG9mIENh YmxlTGFicyBjbGllbnQgZGV2aWNlcyBkZXNjcmliZWQgaW4gDQogICBbMl0gcmVxdWlyZXMgYSBE SENQIHN1Yi1vcHRpb24gdG8gcHJvdmlkZSB0aGUgY2xpZW50IHdpdGggdGhlIA0KICAgbmV0d29y ayBhZGRyZXNzIG9mIGEgS0RDIHNlcnZlciBpbiB0aGUgY2FibGUgb3BlcmF0b3IncyBkYXRhIA0K ICAgbmV0d29yay4gVGhlIGNsYXNzIG9mIGRldmljZXMgYXNzdW1lZCBpbiBbMl0gaXMgdW5saWtl IHRoZSBjbGFzcw0KICAgb2YgZGV2aWNlcyBjb25zaWRlcmVkIGluIFsxXSwgd2hpY2ggcGVyZm9y bSBhIEROUyBsb29rdXAgb2YgdGhlIA0KICAgS2VyYmVyb3MgUmVhbG0gbmFtZSB0byBmaW5kIHRo ZSBLREMgc2VydmVyIG5ldHdvcmsgYWRkcmVzcy4gDQogICANCiAgIFRoaXMgZG9jdW1lbnQgcHJv cG9zZXMgYSBzdWItb3B0aW9uIG9mIHRoZSBDQ0MgREhDUCBvcHRpb24NCiAgIGNvZGUgZm9yIHVz ZSB3aXRoIENhYmxlTGFicyBjbGllbnQgZGV2aWNlcy4gVGhlIHByb3Bvc2VkIHN1Yi1vcHRpb24N CiAgIGVuY29kZXMgYW4gaWRlbnRpZmllciBmb3IgdGhlIG5ldHdvcmsgYWRkcmVzcyBvZiBlYWNo IG9mIG9uZSBvciBtb3JlDQogICBLZXkgRGlzdHJpYnV0aW9uIENlbnRlciBzZXJ2ZXJzIHdpdGgg d2hpY2ggdGhlIENhYmxlTGFicyBjbGllbnQgDQogICBkZXZpY2UgZXhjaGFuZ2VzIHNlY3VyaXR5 IGluZm9ybWF0aW9uLiANCg0KICAgQ2FibGVMYWJzIHBsYW5zIHRvIGFzc2lnbiBzdWItb3B0aW9u IGNvZGUgcmFuZ2VzIGZvciB0aGUgQ0NDIG9wdGlvbiANCiAgIGFjY29yZGluZyB0byBDYWJsZUxh YnMgcHJvamVjdHMuIFRoZSByYW5nZSAoNTEgLSAxMDApIGlzIGFzc2lnbmVkIA0KICAgdG8gdGhl IENhYmxlSG9tZSBwcm9qZWN0LiBVc2Ugb2YgdGhlIGluaXRpYWwgdmFsdWUgb2YgdGhpcyByYW5n ZSBpcw0KICAgc3BlY2lmaWVkIGluIFsyXS4NCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJN VVNUIE5PVCIsICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIgYW5kICJNQVkiIA0KICAgaW4gdGhpcyBk b2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5IFsz XS4NCg0KDQoyLiAgS2V5IERpc3RyaWJ1dGlvbiBDZW50ZXIgSVAgQWRkcmVzcyBTdWItb3B0aW9u DQoNCiAgIFRoZSBDYWJsZUhvbWUgMS4wIHNwZWNpZmljYXRpb24gWzJdIHNwZWNpZmllcyB0aGUg S2V5IERpc3RyaWJ1dGlvbiANCiAgIENlbnRlciBuZXR3b3JrIGFkZHJlc3MgZW5jb2RpbmcgYXMg YSBzdWItb3B0aW9uIG9mIHRoZSBDQ0MgREhDUCANCiAgIE9wdGlvbiBjb2RlLiBUaGlzIGZpZWxk IGlzIHVzZWQgdG8gaW5mb3JtIHRoZSBjbGllbnQgZGV2aWNlIG9mIHRoZQ0KICAgbmV0d29yayBh ZGRyZXNzIG9mIG9uZSBvciBtb3JlIEtleSBEaXN0cmlidXRpb24gQ2VudGVyIHNlcnZlcnMuIA0K DQogICBUaGUgZW5jb2Rpbmcgb2YgdGhlIEtEQyBTZXJ2ZXIgQWRkcmVzcyBzdWItb3B0aW9uIHdp bGwgYWRoZXJlIHRvIHRoZSANCiAgIGZvcm1hdCBvZiBhbiBJUHY0IGFkZHJlc3MgdXNpbmcgdGhl IGRlZmF1bHQgcG9ydC4gVGhlIG1pbmltdW0gbGVuZ3RoDQogICBmb3IgdGhpcyBvcHRpb24gaXMg NCBvY3RldHMsIGFuZCB0aGUgbGVuZ3RoIE1VU1QgYWx3YXlzIGJlIGEgDQogICBtdWx0aXBsZSBv ZiA0LiBJZiBtdWx0aXBsZSBLREMgU2VydmVycyBhcmUgbGlzdGVkLCB0aGV5IE1VU1QgYmUNCiAg IGxpc3RlZCBpbiBkZWNyZWFzaW5nIG9yZGVyIG9mIHByaW9yaXR5LiBUaGUgZm9ybWF0IG9mIHRo ZSBLREMgU2VydmVyDQogICBBZGRyZXNzIHN1Yi1vcHRpb24gb2YgdGhlIENDQyBvcHRpb24gY29k ZSBpcyBhcyBzaG93biBiZWxvdzoNCg0KICAgIFN1Yk9wdCAgTGVuICAgICAgQWRkcmVzcyAxICAg ICAgICAgICAgICAgQWRkcmVzcyAyDQogICArLS0tLS0tKy0tLS0tKy0tLS0tKy0tLS0tKy0tLS0t Ky0tLS0tKy0tLS0tKy0tLS0tKy0tDQogICB8ICA1MSAgfCAgbiAgfCAgYTEgfCAgYTIgfCAgYTMg fCAgYTQgfCAgYTEgfCAgYTIgfCAgLi4uDQogICArLS0tLS0tKy0tLS0tKy0tLS0tKy0tLS0tKy0t LS0tKy0tLS0tKy0tLS0tKy0tLS0tKy0tDQoNCg0KMy4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z DQoNCiAgIFRoaXMgZG9jdW1lbnQgcmVsaWVzIHVwb24gdGhlIERIQ1AgcHJvdG9jb2wgWzRdIGZv ciBhdXRoZW50aWNhdGlvbg0KICAgYW5kIHNlY3VyaXR5LCBpLmUuLCBpdCBkb2VzIG5vdCBwcm92 aWRlIHNlY3VyaXR5IGluIGV4Y2VzcyBvZiB3aGF0DQogICBESENQIGlzIChvciB3aWxsIGJlKSBw cm92aWRpbmcuIEl0IGRvZXMgbm90IGV4cG9zZSBhbnkgc2VjdXJpdHkNCiAgIHRocmVhdHMgYmV5 b25kIHdoYXQgaXMgY3VycmVudGx5IGV4cG9zZWQgYnkgb3RoZXIgREhDUCBvcHRpb25zLg0KDQog ICANCg0KDQoNCiAgIA0KTHVlaHJzLCBXb3VuZHksICYgQmV2aWxhY3F1YSAgICAgICAgRXhwaXJl cyBKdW5lIDIwMDMgICAgICAgICBbUGFnZSAyXQ0KDEludGVybmV0IERyYWZ0CSAgS0RDIFNlcnZl ciBBZGRyZXNzIFN1Yi1vcHRpb24gICAgICAgRGVjZW1iZXIgMjAwMg0KDQoNCjQuICBJQU5BIENv bnNpZGVyYXRpb25zDQoNCiAgIFRoZSBLREMgU2VydmVyIEFkZHJlc3Mgc3ViLW9wdGlvbiBkZXNj cmliZWQgaW4gdGhpcyBkb2N1bWVudCBpcyANCiAgIGludGVuZGVkIHRvIGJlIGEgc3ViLW9wdGlv biBvZiB0aGUgQ2FibGVMYWJzIENsaWVudCBDb25maWd1cmF0aW9uDQogICAoQ0NDKSBvcHRpb24g ZGVzY3JpYmVkIGluIFsxXS4gSUFOQSB3aWxsIGJlIHJlcXVlc3RlZCB0byByZWdpc3Rlcg0KICAg c3ViLW9wdGlvbiBjb2RlIDUxIG9mIHRoZSBDQ0Mgb3B0aW9uIHRvIHRoZSBLREMgU2VydmVyIEFk ZHJlc3MgICAgDQogICBzdWItb3B0aW9uLg0KDQo1LiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0K DQogICBbMV0gIkRIQ1AgT3B0aW9uIGZvciBDYWJsZUxhYnMgQ2xpZW50IENvbmZpZ3VyYXRpb24g IGRyYWZ0LWlldGYtZGhjLQ0KICAgICAgICBwYWNrZXRjYWJsZS0wNSIsIElFVEYsIERlY2VtYmVy IDIwMDIuDQoNCiAgIFsyXSAiQ2FibGVIb21lIDEuMCBTcGVjaWZpY2F0aW9uIFNQLUNIMS4wLUkw Mi0wMjA5MjAiLCBDYWJsZUxhYnMsDQogICAgICAJU2VwdGVtYmVyIDIwMDIsIGh0dHA6Ly93d3cu Y2FibGVsYWJzLmNvbS9wcm9qZWN0cy9jYWJsZWhvbWUvDQoJc3BlY2lmaWNhdGlvbnMvLg0KDQog ICBbM10gQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRl IFJlcXVpcmVtZW50DQogICAgICAgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5 Ny4NCg0KICAgWzRdIERyb21zLCBSLiwgIkR5bmFtaWMgSG9zdCBDb25maWd1cmF0aW9uIFByb3Rv Y29sIiwgUkZDIDIxMzEsIE1hcmNoDQogICAgICAgMTk5Ny4NCg0KNi4gIEF1dGhvcnMnIEFkZHJl c3Nlcw0KDQoJS2V2aW4gTHVlaHJzDQoJQ2FibGVMYWJzDQoJNDAwIENlbnRlbm5pYWwgUGFya3dh eQ0KCUxvdWlzdmlsbGUsIENPIDgwMDI3DQoJUGhvbmU6ICAoMzAzKSA2NjEtOTEwMA0KCUVNYWls OiAgay5sdWVocnNAY2FibGVsYWJzLmNvbQ0KDQoJUmljaGFyZCBXb3VuZHkNCglBVCZUIEJyb2Fk YmFuZA0KCTI3IEluZHVzdHJpYWwgRHJpdmUNCglDaGVsbXNmb3JkLCBNQSAwMTgyNA0KCVBob25l OiAoOTc4KSAyNDQtNDAxMA0KCUVNYWlsOiByd291bmR5QGJyb2FkYmFuZC5hdHQuY29tDQoNCiAg ICAgICAgSm9obiBCZXZpbGFjcXVhDQogICAgICAgIFlBUyBDb3Jwb3JhdGlvbg0KICAgICAgICAz MDAgQnJpY2tzdG9uZSBTcXVhcmUNCiAgICAgICAgQW5kb3ZlciwgTUEgMDE4MTANCiAgICAgICAg UGhvbmU6ICg5NzgpIDc0OS05OTk5DQogICAgICAgIEVNYWlsOiBqb2huQHlhcy5jb20NCg0KDQoN Cg0KDQoNCg0KDQoNCkx1ZWhycywgV291bmR5LCAmIEJldmlsYWNxdWEgICAgICAgIEV4cGlyZXMg SnVuZSAyMDAzICAgICAgICAgW1BhZ2UgM10NCgxJbnRlcm5ldCBEcmFmdAkgIEtEQyBTZXJ2ZXIg QWRkcmVzcyBTdWItb3B0aW9uICAgICAgIERlY2VtYmVyIDIwMDINCg0KDQo3LiAgRnVsbCBDb3B5 cmlnaHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkg KDIwMDIpLiBBbGwgUmlnaHRzIFJlc2VydmVkLg0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0cmFu c2xhdGlvbnMgb2YgaXQgbWF5IGJlIGNvcGllZCBhbmQgZnVybmlzaGVkIHRvDQogICBvdGhlcnMs IGFuZCBkZXJpdmF0aXZlIHdvcmtzIHRoYXQgY29tbWVudCBvbiBvciBvdGhlcndpc2UgZXhwbGFp biBpdA0KICAgb3IgYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQs IGNvcGllZCwgcHVibGlzaGVkDQogICBhbmQgZGlzdHJpYnV0ZWQsIGluIHdob2xlIG9yIGluIHBh cnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2YgYW55DQogICBraW5kLCBwcm92aWRlZCB0aGF0IHRo ZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNlIGFuZCB0aGlzIHBhcmFncmFwaCANCiAgIGFyZSBpbmNs dWRlZCBvbiBhbGwgc3VjaCBjb3BpZXMgYW5kIGRlcml2YXRpdmUgd29ya3MuICBIb3dldmVyLCB0 aGlzDQogICBkb2N1bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBz dWNoIGFzIGJ5IHJlbW92aW5nDQogICB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVuY2Vz IHRvIHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIG90aGVyDQogICBJbnRlcm5ldCBvcmdhbml6YXRp b25zLCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZiBkZXZlbG9wLQ0KICAgaW5n IEludGVybmV0IHN0YW5kYXJkcyBpbiB3aGljaCBjYXNlIHRoZSBwcm9jZWR1cmVzIGZvciBjb3B5 cmlnaHRzDQogICBkZWZpbmVkIGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0 IGJlIGZvbGxvd2VkLCBvciBhcw0KICAgcmVxdWlyZWQgdG8gdHJhbnNsYXRlIGl0IGludG8gbGFu Z3VhZ2VzIG90aGVyIHRoYW4gRW5nbGlzaC4NCg0KICAgVGhlIGxpbWl0ZWQgcGVybWlzc2lvbnMg Z3JhbnRlZCBhYm92ZSBhcmUgcGVycGV0dWFsIGFuZCB3aWxsIG5vdCBiZQ0KICAgcmV2b2tlZCBi eSB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBpdHMgc3VjY2Vzc29ycyBvciBhc3NpZ25zLg0KDQoN CiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGlz IHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09DSUVU WSBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HDQogICBUQVNLIEZPUkNFIERJU0NMQUlNUyBB TEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELCBJTkNMVURJTkcNCiAgIEJVVCBOT1Qg TElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRSBJTkZPUk1BVElPTg0K ICAgSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQgV0FS UkFOVElFUyBPRiANCiAgIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VM QVIgUFVSUE9TRS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCkx1ZWhycywgV291bmR5LCAmIEJldmlsYWNxdWEgICAgICAgIEV4cGlyZXMgSnVu ZSAyMDAzICAgICAgICAgW1BhZ2UgNF0NCg== ------_=_NextPart_001_01C2A180.602B29C4-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Dec 12 07:50:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21131; Thu, 12 Dec 2002 07:50:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBCCjov16367; Thu, 12 Dec 2002 07:45:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBCCiWv16314 for ; Thu, 12 Dec 2002 07:44:32 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20999 for ; Thu, 12 Dec 2002 07:41:34 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBCCiwOw001563 for ; Thu, 12 Dec 2002 07:44:59 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-660.cisco.com [10.82.226.148]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA07762 for ; Thu, 12 Dec 2002 07:44:27 -0500 (EST) Message-Id: <4.3.2.7.2.20021212074227.037b7080@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Dec 2002 07:44:22 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Draft minutes from Atlanta Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , DHC WG Meeting minutes (Draft, 12/12/2002) IETF 55, Atlanta, 11/2002 ========================= Administrivia, agenda bashing, Ralph Droms ------------------------------------------ CableLabs Client Configuration option draft is in IETF last call. So far, the last call has elicited comments requiring some editorial and minor specification changes. DHCPv6 specification has been reviewed by IESG, and requires small edits to text describing relay agent security. Droms will post summary of changes to WG mailing list. Use of IPsec for Securing DHCPv4 Messages Exchanged Between Relay Agents and Servers, Ralph Droms ----------------------------------------------------------------- draft-droms-dhcp-relay-agent-ipsec-00.txt describes use of IPsec for securing messages between relay agents and servers. Carl Smith asked if it is different than the mechanism in the DHCPv6 draft; answer: no. Narten asked for comparison with Stapp's draft-ietf-dhc-auth-suboption-01.txt. Droms noted IPsec mechanism is hop-by-hop while authentication options covers entire path; IPsec mechanism incurs extra complexity if there are multiple relay agents in the path to the server. The WG agreed to take the document on as a WG document. The Authentication Suboption for the DHCP Relay Agent Option, Mark Stapp ------------------------------------------------------------------ draft-ietf-dhc-auth-suboption-01.txt specifies a DHCP-specific mechanism, based on a relay agent suboption that contains a message digest for checking message integrity. This mechanism uses shared keys and includes an identifier mechanism to accommodate edge devices that don't use giaddr. With additional changes, this mechanism can accommodate multiple, nested relay agents. The WG was asked what to do with the two proposals: advance both, adopt one? Does the WG have a clear understanding of the two proposals? Ted Lemon asked how we might weight the pros and cons. Thomas Narten and Stuart Cheshie asked if there is any data on whether IPsec implementations are available to relay agents today. Mark Stapp asked about potential computational complexity issues. Stapp, Lemon and John Schnizlein all asked what the perceived customer requirements are. Droms expressed concern about interoperability if both proposals are advanced. Erik Nordmark asked how relay agents would be configured to use IPsec or with the keys for the relay agent option. Droms pointed out that reuse of IPsec technology implies the availability of future IPsec enhancements. Schnizlein volunteered to organize discussion of pros and cons of both proposals on the WG mailing list. DHCP Option for SNMP Notifications, Mark Bakke ---------------------------------------------- draft-bakke-dhc-snmp-trap-01.txt was developed to address requirements for systems using diskless boot to obtain a list of IP addresses to which to send SNMP traps. Narten asked which WG is best for discussion of this option - in theory, details should be discussed in an SNMP WG with final review of syntax and compatibility in the dhc WG. Narten will coordinate review of the document with MIB groups in the IETF, and the document will ultimately be a dhc WG work item, as there are no appropriate active SNMP WGs. There was a question about whether the option should be expanded with multiple sub-options for different trap types. Subnet Allocation using DHCP, Richard Johnson --------------------------------------------- This proposal describes a mechanism through which a DHCP server can delegate a block of addresses (IPv4), collect usage data on the delegated addresses and deprecate use of addresses. It is similar to the prefix delegation mechanism for DHCPv6. Ted Lemon pointed out that this proposal would require a major revision to existing server, and he suggested that the authors review previous, related work by Walt Lazear. The WG agreed to take on this document as a WG work item. DHCP Server-ID Override Suboption, Richard Johnson -------------------------------------------------- Some DHCP client messages, such as DHCPRENEW, are unicast directly to the DHCP server and not received by a relay agent. Thus, relay agents are unable to add relay agent options to those messages. This proposal provides a mechanism through which the DHCP server can configure the client to respond to the relay agent rather than directly to the server. Narten asked if continued expansion of relay agent options is a good thing. WG consensus is that relay agent options have been found to provide function that cannot be provided in other ways, and the full range of application for relay agent options is still being explored. Stapp suggested revisiting the relay agent option specification, RFC3046, as a WG charter item. The WG agreed to take on this document as a WG work item. Considerations for the use of the Host Name option, Carl Smith -------------------------------------------------------------- Carl had one question for the WG: how can a client request that its name/address association be removed from DNS? Can we use the FQDN to accomplish this result? Kim Kinnear and Ted Lemon asked what customer requires this result. Bernie Volz suggested revisiting this question after the DHCPv6 FQDN model is completed. Load Balancing for DHCPv6, Bernie Volz -------------------------------------- Any more changes needed in this draft? No; so this document is ready for WG last call after DHCPv6 spec has advanced. Other DHCPv6 options, Ralph Droms --------------------------------- draft-ietf-dhc-dhcpv6-opt-prefix-delegation-00.txt has folded prefix delegation into identity associations; the document is also under discussion in the ipv6 WG. draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt, draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt, draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt are all ready for WG last call as soon as DHCPv6 advances. draft-ietf-dhc-dhcpv6-opt-dstm-01.txt and draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt are to be synced up with v6ops work. Lemon, Volz and Narten all asked about the requirement for the mechanism proposed in draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt. A K Vijayabhaskar (author) to clarify motivation and requirements in the specification. A Guide to Implementing Stateless DHCPv6 Service, Ralph Droms ------------------------------------------------------------- Droms asked the WG about the best way to specify the parts of DHCPv6 required for stateless DHCPv6 operation ("DHCPv6-lite") - for example, for providing DNS server configuration without address assignment. Stuart Cheshire asked if the document should be informational or standards-track. Another possibility would be BCP. The WG asked that the Reconfigure message be added to draft-droms-dhcpv6-stateless-guide-01.txt and accepted the document as a dhc WG work item. Revised DHC WG charter and milestones, Ralph Droms -------------------------------------------------- Droms reported that the revised charter and milestones have been submitted to the IESG. The IESG suggested adding a separate charter item to develop a mechanism through which a client can authenticate a server without authentication of the client by the server. Droms will add the relay agent charter item suggested by Stapp (see above). Carl Smith, Bernie Volz and Barr Hibbs volunteered to be a design team that will follow up on the charter item to review RFC3118; they will develop a threat model and analysis of the authentication provided by RFC3118. Barr Hibbs volunteered to coordinate and act as editor for a review of the DHCPv4 specification. Recycling option codes, Ralph Droms ----------------------------------- There are more than 15 options codes that have been assigned but never used. Droms will publish an Internet Draft identifying these option codes and asking for feedback from the Internet community about whether these option codes can be returned to IANA for reassignment. After the Internet Draft has been reviewed by the dhc WG and by the IESG, it will be submitted to IANA. DHCP Lease Query, Kim Kinnear ----------------------------- The WG last call on draft-ietf-dhc-leasequery-05.txt has completed. Based on input from the last call, Kinnear has changed the draft to use a new option rather than overloading the requested address option, and has made other editorial changes. The document is now ready for submission to the IESG. Link Selection sub-option for the Relay Agent Information Option, Kim Kinnear ----------------------------------------------------------------- Last call on draft-ietf-dhc-agent-subnet-selection-04.txt has completed. This document is waiting for authentication of relay agent messages to be resolved. DHCP Subscriber ID Suboption for the DHCP Relay Agent Option, Richard Johnson ------------------------------------------------------------- This option, in draft-johnson-dhc-subscriber-id-00.txt, is motivated by a requirement to identify a subscriber in a relay agent option, regardless of the port to which the subscriber is attached. The WG agreed to take on this document as a WG work item. DHCP Option for Geographic Location, John Schnizlein ---------------------------------------------------- This option, in draft-polk-dhcp-geo-loc-option-00.txt, passes location information about a DHCP client from the server to the client. The immediate purpose is to provide location information to IP phones. The geopriv WG will own the semantics, while the dhc WG will own the protocol and the syntax of the option. The DHCP Client FQDN Option, Mark Stapp DDNS-DHCP conflict resolution, Mark Stapp ----------------------------------------- Stapp reported on draft-ietf-dhc-fqdn-option-05.txt, draft-ietf-dhc-ddns-resolution-05.txt, draft-ietf-dnsext-dhcid-rr-05.txt. There are no deployed implementations of these drafts. Cisco and two others have (non-interoperable) implementation that use TXT RRs, waiting for approval of DHCID RR. Droms asked for a summary of changes to the current drafts. Stapp will post summaries to WG mailing list. Gudmundsson asked if the DHSID RR should become a more general RR type. WG consensus was no, as that would delay progress of these drafts and there is no specific requirement for other, similar RR types. Gudmundsson and Droms agreed documents are ready for dnsext and dhc WG last call. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Dec 12 22:20:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22376; Thu, 12 Dec 2002 22:20:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD3Mev06543; Thu, 12 Dec 2002 22:22:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBC9MXv05047 for ; Thu, 12 Dec 2002 04:22:33 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17493 for ; Thu, 12 Dec 2002 04:19:26 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 12 Dec 2002 01:22:22 -0800 X-Originating-IP: [194.237.142.24] From: "tm" To: Date: Thu, 12 Dec 2002 10:21:30 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01C2A1C8.3CF73400" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 12 Dec 2002 09:22:22.0007 (UTC) FILETIME=[F9B5EC70:01C2A1BF] Subject: [dhcwg] FORCE RENEW questions Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0035_01C2A1C8.3CF73400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Two questions: A) Is DHCP FORCE RENEW supported by any operating system today? Or are = there any known plans for it at Microsoft, Linux, BSD, etc.? B) Is it possible to send a FORCE RENEW to a NIC that has not yet been = configured with an IP address, that is, a NIC that never received a DHCP = reply after reboot? (With the result that the host will do a DHCP = request). /TM ------=_NextPart_000_0035_01C2A1C8.3CF73400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Two questions:
 
A) Is DHCP FORCE RENEW supported by any = operating=20 system today? Or are there any known plans for it at Microsoft, Linux, = BSD,=20 etc.?
 
B) Is it possible to send a FORCE RENEW = to a NIC=20 that has not yet been configured with an IP address, that is, a NIC that = never=20 received a DHCP reply after reboot? (With the result that the host will = do a=20 DHCP request).
 
/TM
 
 
------=_NextPart_000_0035_01C2A1C8.3CF73400-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Dec 12 22:23:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22513; Thu, 12 Dec 2002 22:23:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD3PPv06695; Thu, 12 Dec 2002 22:25:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD2f1v04135 for ; Thu, 12 Dec 2002 21:41:01 -0500 Received: from web12406.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21395 for ; Thu, 12 Dec 2002 21:37:56 -0500 (EST) Message-ID: <20021213024052.62501.qmail@web12406.mail.yahoo.com> Received: from [67.82.134.6] by web12406.mail.yahoo.com via HTTP; Thu, 12 Dec 2002 18:40:52 PST Date: Thu, 12 Dec 2002 18:40:52 -0800 (PST) From: Timir Naik To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [dhcwg] dhcp solaris client error Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I got myself a cable modem and a wireless router D-Link 614+. The route is capable to run dhcp client to get the internet IP address and dhcp server for the clients inside the network. The dhcp server is working great with my windows' client but is giving me this error, "no valid OFFER/BOOTP reply" when I try running dhcp client on my Solaris 8 box. I received the above error message when I ran the following commands: 1. blank hostname.hme0 2. blank dhcp.hme0 3. /sbin/dhcpagent -d 1 -f 1 & 4. ifconfig hme0 dhcp start and this is when I the error "no valid OFFER/BOOTP reply". I was hoping someone can help me out with this problem. Thank you, Tim __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 13 00:09:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03511; Fri, 13 Dec 2002 00:09:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD5BZv12614; Fri, 13 Dec 2002 00:11:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD58fv12448 for ; Fri, 13 Dec 2002 00:08:41 -0500 Received: from lapop.smtp.stsn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03443 for ; Fri, 13 Dec 2002 00:05:34 -0500 (EST) Received: from Barr1LKL501 ([10.0.51.52]) by lapop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Dec 2002 22:16:25 -0700 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] FORCE RENEW questions Date: Thu, 12 Dec 2002 21:09:37 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C2A222.C77497D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 13 Dec 2002 05:16:26.0015 (UTC) FILETIME=[C8DDFAF0:01C2A266] Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C2A222.C77497D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I'm also interested in the answer to question (A) in the original message, so would any responders please post their replies to the DHCWG mailing list.... As an additional point, do the implementations of FORCERENEW also implement DHCP Authentication [RFC 3118] as required by RFC 3203? As to question (B), the NIC is not the DHCP client, so let me restate the question and then answer it: "Is it possible to send a FORCERENEW message to an unconfigured client?" As this message is unicast to a DHCP client, and the client is directed to silently discard multicast messages, it is not possible for an unconfigured client to receive a FORCERENEW message. The DHCP protocol [RFC 2131] describes how a DHCP client may continue broadcasting DHCPDISCOVER messages if a DHCP server has not answered. An unconfigured client must not begin the protocol exchange with a DHCPREQUEST message. RFC 2131 also describes how a previously configured client may recover from loss of contact with the server, but that is a different case than you asked about. --Barr Hibbs -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of tm Sent: Thursday, December 12, 2002 01:22 To: dhcwg@ietf.org Subject: [dhcwg] FORCE RENEW questions Two questions: A) Is DHCP FORCE RENEW supported by any operating system today? Or are there any known plans for it at Microsoft, Linux, BSD, etc.? B) Is it possible to send a FORCE RENEW to a NIC that has not yet been configured with an IP address, that is, a NIC that never received a DHCP reply after reboot? (With the result that the host will do a DHCP request). /TM ------=_NextPart_000_0010_01C2A222.C77497D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm=20 also interested in the answer to question (A) in the original message, = so would=20 any responders please post their replies to the DHCWG mailing = list....  As=20 an additional point, do the implementations of FORCERENEW also implement = DHCP=20 Authentication [RFC 3118] as required by RFC 3203?
 
As to=20 question (B), the NIC is not the DHCP client, so let me restate the = question and=20 then answer it:  "Is it possible to send a FORCERENEW message to an = unconfigured client?"  As this message is unicast to a DHCP client, = and the=20 client is directed to silently discard multicast messages, it is not = possible=20 for an unconfigured client to receive a FORCERENEW message.  The = DHCP=20 protocol [RFC 2131] describes how a DHCP client may continue = broadcasting=20 DHCPDISCOVER messages if a DHCP server has not answered.  An = unconfigured=20 client must not begin the protocol exchange with a DHCPREQUEST = message. =20 RFC 2131 also describes how a previously configured client may recover = from loss=20 of contact with the server, but that is a different case than you asked=20 about.
 
--Barr=20 Hibbs
 
-----Original Message-----
From: = dhcwg-admin@ietf.org=20 [mailto:dhcwg-admin@ietf.org]On Behalf Of tm
Sent: = Thursday,=20 December 12, 2002 01:22
To: = dhcwg@ietf.org
Subject:=20 [dhcwg] FORCE RENEW questions

Two questions:
 
A) Is DHCP FORCE RENEW supported by = any operating=20 system today? Or are there any known plans for it at Microsoft, Linux, = BSD,=20 etc.?
 
B) Is it possible to send a FORCE = RENEW to a NIC=20 that has not yet been configured with an IP address, that is, a NIC = that never=20 received a DHCP reply after reboot? (With the result that the host = will do a=20 DHCP request).
 
/TM
 
 
------=_NextPart_000_0010_01C2A222.C77497D0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 13 20:18:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12218; Fri, 13 Dec 2002 20:18:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBE1KZv26559; Fri, 13 Dec 2002 20:20:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBE1Jxv26478 for ; Fri, 13 Dec 2002 20:19:59 -0500 Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12190; Fri, 13 Dec 2002 20:16:54 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id gBE1JoD29750; Fri, 13 Dec 2002 17:19:50 -0800 (PST) Message-Id: <200212140119.gBE1JoD29750@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, dhcwg@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 13 Dec 2002 17:19:50 -0800 Subject: [dhcwg] RFC 3442 on The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3442 Title: The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 Author(s): T. Lemon, S. Cheshire, B. Volz Status: Standards Track Date: December 2002 Mailbox: Ted.Lemon@nominum.com, rfc@stuartcheshire.org, bernie.volz@ericsson.com Pages: 9 Characters: 19370 Updates: 2132 I-D Tag: draft-ietf-dhc-csr-07.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3442.txt This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. The network destinations in these routes are classless - each routing table entry includes a subnet mask. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Working Group of the IETF. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <021213171741.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3442 --OtherAccess Content-Type: Message/External-body; name="rfc3442.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <021213171741.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Dec 16 13:44:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13761; Mon, 16 Dec 2002 13:44:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGIiHv06844; Mon, 16 Dec 2002 13:44:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGIgBv06787 for ; Mon, 16 Dec 2002 13:42:11 -0500 Received: from chimera.incognito.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13629 for ; Mon, 16 Dec 2002 13:39:03 -0500 (EST) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 18O0Bm-00080k-00 for ; Mon, 16 Dec 2002 10:42:02 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Dec 2002 10:46:07 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A677F8@homer.incognito.com.> From: "Kostur, Andre" To: "'dhcwg@ietf.org'" Date: Mon, 16 Dec 2002 10:46:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2A533.632FB020" Subject: [dhcwg] LeaseQuery draft Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2A533.632FB020 Content-Type: text/plain; charset="iso-8859-1" The draft Atlanta minutes make reference to a draft-ietf-dhc-leasequery-05.txt, but the latest version I can find is -04. Any idea where -05 is? ------_=_NextPart_001_01C2A533.632FB020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LeaseQuery draft

The draft Atlanta minutes make reference to a = draft-ietf-dhc-leasequery-05.txt, but the latest version I can find is = -04.  Any idea where -05 is?

------_=_NextPart_001_01C2A533.632FB020-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Dec 17 08:17:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13285; Tue, 17 Dec 2002 08:17:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHDJov09891; Tue, 17 Dec 2002 08:19:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHDIPv09860 for ; Tue, 17 Dec 2002 08:18:25 -0500 Received: from localhost.prospeed.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13269 for ; Tue, 17 Dec 2002 08:15:24 -0500 (EST) From: rdroms@prospeed.net Received: from Debug (ns2 [63.84.180.20] (may be forged)) by localhost.prospeed.net (8.11.6/8.9.3) with SMTP id gBHDHtX21676; Tue, 17 Dec 2002 08:17:59 -0500 Message-Id: <200212171317.gBHDHtX21676@localhost.prospeed.net> To: , Subject: Re: [dhcwg] LeaseQuery draft Date: Tue, 17 Dec 2002 13:17:59 GMT X-Mailer: Endymion MailMan Professional Edition v3.0.35 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Sorry, that's my mistake. There was confusion about the numbering for that Internet Draft. The latest version is -04. - Ralph > The draft Atlanta minutes make reference to a > draft-ietf-dhc-leasequery-05.txt, but the latest version I can find is -04. > Any idea where -05 is? > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Dec 17 14:55:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21725; Tue, 17 Dec 2002 14:55:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHJvRv32429; Tue, 17 Dec 2002 14:57:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHJtav32361 for ; Tue, 17 Dec 2002 14:55:36 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21624; Tue, 17 Dec 2002 14:52:29 -0500 (EST) Message-Id: <200212171952.OAA21624@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , dhcwg@ietf.org From: The IESG Date: Tue, 17 Dec 2002 14:52:29 -0500 Subject: [dhcwg] Protocol Action: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has approved the Internet-Draft 'Dynamic Host Configuration Protocol for IPv6 (DHCPv6)' 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 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to "IPv6 Stateless Address Autoconfiguration" (RFC2462) and can be used separately or concurrently with the latter to obtain configuration parameters. DHCPv6 offers two modes of operation. In stateful mode, the DHC server maintains per-client configuration information (e.g., addresses). In stateless mode, the DHC server stores no per-client information. Stateless mode is used when the information provided is the same regardless of who asks for it, or because the appropriate configuration information to be returned to a client can be determined idempotently based on the information on the request (e.g., all clients connected to particular links are to use the same set of DNS servers). Working Group Summary There was consensus for this in the WG and no significant issues were raised during the IETF Last Call. Protocol Quality This protocol has been reviewed for the IESG by Thomas Narten. RFC Editor Note: In Section 21.1, delete the following sentence from the first paragraph: > Relay agents and servers MUST support manual configuration and > installation of static keys. In Section 21.1, change the item: > Key management Because the relay agents and servers must be > manually configured, no automated key management > is required. to Key management Because the relay agents and servers are used within an organization, public key schemes are not necessary. Because the relay agents and servers must be manually configured, manually configured key management may suffice, but doesn't provide defense against replayed messages. Accordingly, IKE with preshared secrets SHOULD be supported. IKE with public keys MAY be supported. In Section 23, Security Considerations, add the following new second paragraph, immediately after the first one: Use of manually configured preshared keys for IPsec between relay agents and servers does not defend against replayed DHCP messages. Replayed messages can represent a DOS attack through exhaustion of processing resources, but not through mis-configuration or exhaustion of other resources such as assignable addresses. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Dec 17 15:34:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22921; Tue, 17 Dec 2002 15:34:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHKaAv02113; Tue, 17 Dec 2002 15:36:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHKZ4v02030 for ; Tue, 17 Dec 2002 15:35:04 -0500 Received: from e6.ny.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22815 for ; Tue, 17 Dec 2002 15:31:58 -0500 (EST) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gBHKYwYA013022 for ; Tue, 17 Dec 2002 15:34:58 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gBHKYul8027694 for ; Tue, 17 Dec 2002 15:34:56 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id gBHKWBH20740 for ; Tue, 17 Dec 2002 15:32:11 -0500 Message-Id: <200212172032.gBHKWBH20740@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Tue, 17 Dec 2002 15:32:11 -0500 From: Thomas Narten Subject: [dhcwg] FWD: Re: IESG draft-cheshire-ipv4-acd-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Anyone care to comment on the assertion below regarding a typo in 2131? Thomas - ------- Forwarded Message From: Stuart Cheshire To: "Erik Nordmark" Cc: Date: Fri, 13 Dec 2002 18:45:26 -0800 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt At last, a reply that actually relates to the subject line. >> > But the ongoing conflict detection (causing >> > IP address change when a conflict appears) and broadcast replies looks >> > more like a useful experiment to me. >> >> It has been a five-year experiment by Apple. > >Do you have a pointer to the data that has been collected as part of >that experiment? There is no data. That's the point. After shipping millions of machines per year for five years, the number of reported problems is zero. >How about adding > This document updates RFC 826 and RFC 2132. I added a header line that says "Updates: 826, 2132" >RFC 2131 actually talks about an ARP reply and not the ARP request >with sender=target. See section 4.4.1 in RFC 2131. >So you don't seem to be consistent with RFC 2131. Stevens describes using ARP request. BSD broadcasts an ARP request to announce its address. Mac OS 9 broadcasts an ARP request to announce its address. Mac OS X broadcasts an ARP request to announce its address. Windows broadcasts an ARP request to announce its address. RFC 2131 describes broadcasting an ARP reply, but like many things in RFC 2131, this is probably a typo. As has been pointed out many times by many people, broadcasting an ARP reply is unconventional, and best avoided where not necessary. Therefore I avoided it and followed the behaviour described by Stevens (and implemented on Mac, Windows, Unix, etc.) instead. In any case, the "Packet Reception" rules of RFC 826 are exceedingly clear that checking the packet opcode is the *last* check that is done, after all other packet processing has been completed. Do you have a technical opinion to offer about which you think is best? >I wasn't suggesting a normative reference; that isn't needed since the >document is self-contained. But pointing out the relationship using a >non-normative reference to draft-ietf-zeroconf-ipv6-link-local would be >useful for the implementors that are going to implement both. There is already a non-normative reference to the v4ll draft. If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >> At any time, if a host >> receives an ARP packet (request *or* reply) where the 'sender IP >> address' is the host's own IP address, but the 'sender hardware >> address' does not match any of the host's own interface addresses, >> then this is a conflicting ARP packet > >I fail to find the word "multihoming" or any explicit mention of >multiple interfaces in the above text. The phrase, "any of the host's own interface addresses" is a mention of multiple interfaces. If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >> > I would assume that ACD can >> > operate independently for each interface even though v4LL has some >> > extra stuff related to multi-interface nodes. >> >> No, the specification needs to deal with the case when a host has two >> interfaces (say wireless and Ethernet) on the same link. > >And you claim you can't do that by having the interfaces be configured >independently of eachother? If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >I think my conclusion was that the time should be shorter >than 8 seconds and not longer. 8 seconds is a useless compromise >as far as I can tell since it is unecessarily long when STP isn't triggered >and too short when STP is triggered (with out of the box bridge >configurations.) Thus 2 or 3 seconds should be fine. The document already has specific text allowing shorter timeouts in cases where the implementer has reason to believe that is a wise design choice. The document already has specific text describing how the individual choice of timeout doesn't have any impact on interoperability with other devices. If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >> Most network operators today, with good reason, set their port blocking >> time to five seconds. > >Doesn't match my experience. And doesn't match the IEEE 802.1D >recommendation. If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >Is there a way for the host to reliably detect whether the switches run >RSTP instead of STP? Quoting from Mick Seaman: "Yes, the driver can easily tell the difference between an RSTP and an STP BPDU, they are different 'BPDU types', a type field being defined in the BPDU format." If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >> A Zero Configuration device may want to make use of address conflict >> detection. If address conflict detection requires a mandatory >> user-configuration option, then that means that Zero Configuration >> devices require mandatory user-configuration options, a >> self-contradiction. > >I'd understand that comment if it was about >draft-ietf-zeroconf-ipv4-link-local >but not about the ACD document. Since the addresses are configured either >manually or by DHCP (or some other provisioning protocol) it is possible to >add a knob in the manual config or in DHCP, respectively. So I don't >understand the issue your are concerned about. I don't understand why you think there is a problem. DHCP clients have done address conflict detection for years, and no one has asked for an option to disable address conflict detection there. Macs have done address conflict detection for manual addresses for years, and no one has asked for an option to disable that either. Even Windows tells you if you manually set your IP address to an address that's already in use. If you've ever struggled with a network where two machines were set to the same IP address, you'd think it insane to ever think you'd NOT want to get all the help you can to diagnose and fix that problem. I don't understand why now, after all these years of successful address conflict detection that no one ever complained about, there's suddenly a feeling that we need manual configuration options to disable it. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org - ------- End of Forwarded Message _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Dec 17 16:30:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24415; Tue, 17 Dec 2002 16:30:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHLWUv05782; Tue, 17 Dec 2002 16:32:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHLV9v05714 for ; Tue, 17 Dec 2002 16:31:09 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24345 for ; Tue, 17 Dec 2002 16:28:01 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id gBHLV0W19418; Tue, 17 Dec 2002 15:31:00 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id gBHLV0010757; Tue, 17 Dec 2002 15:31:00 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 17 Dec 2002 15:31:00 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , dhcwg@ietf.org Date: Tue, 17 Dec 2002 15:29:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2A612.A4D50EE6" Subject: [dhcwg] Is RFC 2131 Correct? ARP Request or ARP Reply ... IT IS CORRECT - BOTH ARE SENT!! Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2A612.A4D50EE6 Content-Type: text/plain; charset="ISO-8859-1" RFC 2131 is CORRECT as it is!!! See the text below. The first part talks about an ARP Request. This is used to solicit an ARP reply from another host that might be using that address. If no reply is received, then the client uses the address and THEN sends an ARP reply. The ARP reply causes the caches in all other systems on the LAN to be updated SHOULD THEY have an old mapping for the address (for example, from the previous client that released the address). Perhaps the error in RFC 2131 is that it doesn't make that fully clear. In the last sentence of the text from 2131 below, it should have said that if the client does not receive a reply to ARP request, it uses the address and the client SHOULD broadcast an ARP reply ... If the parameters are acceptable, the client records the address of the server that supplied the parameters from the 'server identifier' field and sends that address in the 'server identifier' field of a DHCPREQUEST broadcast message. Once the DHCPACK message from the server arrives, the client is initialized and moves to BOUND state. The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER message. The client records the lease expiration time as the sum of the time at which the original request was sent and the duration of the lease from the DHCPACK message. The client SHOULD perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request. When broadcasting an ARP request for the suggested address, the client must fill in its own hardware address as the sender's hardware address, and 0 as the sender's IP address, to avoid confusing ARP caches in other hosts on the same subnet. If the Droms Standards Track [Page 38] RFC 2131 Dynamic Host Configuration Protocol March 1997 network address appears to be in use, the client MUST send a DHCPDECLINE message to the server. The client SHOULD broadcast an ARP reply to announce the client's new IP address and clear any outdated ARP cache entries in hosts on the client's subnet. -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Tuesday, December 17, 2002 3:32 PM To: dhcwg@ietf.org Subject: [dhcwg] FWD: Re: IESG draft-cheshire-ipv4-acd-02.txt Anyone care to comment on the assertion below regarding a typo in 2131? Thomas - ------- Forwarded Message From: Stuart Cheshire To: "Erik Nordmark" Cc: Date: Fri, 13 Dec 2002 18:45:26 -0800 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt At last, a reply that actually relates to the subject line. >> > But the ongoing conflict detection (causing >> > IP address change when a conflict appears) and broadcast replies looks >> > more like a useful experiment to me. >> >> It has been a five-year experiment by Apple. > >Do you have a pointer to the data that has been collected as part of >that experiment? There is no data. That's the point. After shipping millions of machines per year for five years, the number of reported problems is zero. >How about adding > This document updates RFC 826 and RFC 2132. I added a header line that says "Updates: 826, 2132" >RFC 2131 actually talks about an ARP reply and not the ARP request >with sender=target. See section 4.4.1 in RFC 2131. >So you don't seem to be consistent with RFC 2131. Stevens describes using ARP request. BSD broadcasts an ARP request to announce its address. Mac OS 9 broadcasts an ARP request to announce its address. Mac OS X broadcasts an ARP request to announce its address. Windows broadcasts an ARP request to announce its address. RFC 2131 describes broadcasting an ARP reply, but like many things in RFC 2131, this is probably a typo. As has been pointed out many times by many people, broadcasting an ARP reply is unconventional, and best avoided where not necessary. Therefore I avoided it and followed the behaviour described by Stevens (and implemented on Mac, Windows, Unix, etc.) instead. In any case, the "Packet Reception" rules of RFC 826 are exceedingly clear that checking the packet opcode is the *last* check that is done, after all other packet processing has been completed. Do you have a technical opinion to offer about which you think is best? >I wasn't suggesting a normative reference; that isn't needed since the >document is self-contained. But pointing out the relationship using a >non-normative reference to draft-ietf-zeroconf-ipv6-link-local would be >useful for the implementors that are going to implement both. There is already a non-normative reference to the v4ll draft. If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >> At any time, if a host >> receives an ARP packet (request *or* reply) where the 'sender IP >> address' is the host's own IP address, but the 'sender hardware >> address' does not match any of the host's own interface addresses, >> then this is a conflicting ARP packet > >I fail to find the word "multihoming" or any explicit mention of >multiple interfaces in the above text. The phrase, "any of the host's own interface addresses" is a mention of multiple interfaces. If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >> > I would assume that ACD can >> > operate independently for each interface even though v4LL has some >> > extra stuff related to multi-interface nodes. >> >> No, the specification needs to deal with the case when a host has two >> interfaces (say wireless and Ethernet) on the same link. > >And you claim you can't do that by having the interfaces be configured >independently of eachother? If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >I think my conclusion was that the time should be shorter >than 8 seconds and not longer. 8 seconds is a useless compromise >as far as I can tell since it is unecessarily long when STP isn't triggered >and too short when STP is triggered (with out of the box bridge >configurations.) Thus 2 or 3 seconds should be fine. The document already has specific text allowing shorter timeouts in cases where the implementer has reason to believe that is a wise design choice. The document already has specific text describing how the individual choice of timeout doesn't have any impact on interoperability with other devices. If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >> Most network operators today, with good reason, set their port blocking >> time to five seconds. > >Doesn't match my experience. And doesn't match the IEEE 802.1D >recommendation. If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >Is there a way for the host to reliably detect whether the switches run >RSTP instead of STP? Quoting from Mick Seaman: "Yes, the driver can easily tell the difference between an RSTP and an STP BPDU, they are different 'BPDU types', a type field being defined in the BPDU format." If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >> A Zero Configuration device may want to make use of address conflict >> detection. If address conflict detection requires a mandatory >> user-configuration option, then that means that Zero Configuration >> devices require mandatory user-configuration options, a >> self-contradiction. > >I'd understand that comment if it was about >draft-ietf-zeroconf-ipv4-link-local >but not about the ACD document. Since the addresses are configured either >manually or by DHCP (or some other provisioning protocol) it is possible to >add a knob in the manual config or in DHCP, respectively. So I don't >understand the issue your are concerned about. I don't understand why you think there is a problem. DHCP clients have done address conflict detection for years, and no one has asked for an option to disable address conflict detection there. Macs have done address conflict detection for manual addresses for years, and no one has asked for an option to disable that either. Even Windows tells you if you manually set your IP address to an address that's already in use. If you've ever struggled with a network where two machines were set to the same IP address, you'd think it insane to ever think you'd NOT want to get all the help you can to diagnose and fix that problem. I don't understand why now, after all these years of successful address conflict detection that no one ever complained about, there's suddenly a feeling that we need manual configuration options to disable it. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org - ------- End of Forwarded Message _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2A612.A4D50EE6 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Is RFC 2131 Correct? ARP Request or ARP Reply ... IT IS CORRECT = - BOTH ARE SENT!!

RFC 2131 is CORRECT as it is!!! See the text = below.

The first part talks about an ARP Request. This is = used to solicit an
ARP reply from another host that might be using that = address. If no
reply is received, then the client uses the address = and THEN sends an
ARP reply. The ARP reply causes the caches in all = other systems on the
LAN to be updated SHOULD THEY have an old mapping = for the address (for
example, from the previous client that released the = address).

Perhaps the error in RFC 2131 is that it doesn't make = that fully clear.
In the last sentence of the text from 2131 below, it = should have said
that if the client does not receive a reply to ARP = request, it uses
the address and the client SHOULD broadcast an ARP = reply ...

   If the parameters are acceptable, the = client records the address of
   the server that supplied the parameters = from the 'server identifier'
   field and sends that address in the = 'server identifier' field of a
   DHCPREQUEST broadcast message.  = Once the DHCPACK message from the
   server arrives, the client is = initialized and moves to BOUND state.
   The DHCPREQUEST message contains the = same 'xid' as the DHCPOFFER
   message.  The client records the = lease expiration time as the sum of
   the time at which the original request = was sent and the duration of
   the lease from the DHCPACK = message.    The client SHOULD perform a
   check on the suggested address to = ensure that the address is not
   already in use.  For example, if = the client is on a network that
   supports ARP, the client may issue an = ARP request for the suggested
   request.  When broadcasting an ARP = request for the suggested address,
   the client must fill in its own = hardware address as the sender's
   hardware address, and 0 as the sender's = IP address, to avoid
   confusing ARP caches in other hosts on = the same subnet.  If the



Droms         &nbs= p;           &nbs= p; Standards = Track           &= nbsp;        [Page 38]
=0C
RFC = 2131          Dynamic Host = Configuration Protocol         = March 1997


   network address appears to be in use, = the client MUST send a
   DHCPDECLINE message to the server. The = client SHOULD broadcast an ARP
   reply to announce the client's new IP = address and clear any outdated
   ARP cache entries in hosts on the = client's subnet.

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Tuesday, December 17, 2002 3:32 PM
To: dhcwg@ietf.org
Subject: [dhcwg] FWD: Re: IESG = draft-cheshire-ipv4-acd-02.txt


Anyone care to comment on the assertion below = regarding a typo in 2131?

Thomas
- ------- Forwarded Message

From: Stuart Cheshire = <cheshire@apple.com>
To: "Erik Nordmark" = <Erik.Nordmark@sun.com>
Cc: <zeroconf@merit.edu>
Date: Fri, 13 Dec 2002 18:45:26 -0800
Subject: Re: IESG = draft-cheshire-ipv4-acd-02.txt

At last, a reply that actually relates to the subject = line.

>> > But the ongoing conflict detection = (causing
>> > IP address change when a conflict = appears) and broadcast replies looks
>> > more like a useful experiment to = me.
>>
>> It has been a five-year experiment by = Apple.
>
>Do you have a pointer to the data that has been = collected as part of
>that experiment?

There is no data. That's the point. After shipping = millions of machines
per year for five years, the number of reported = problems is zero.

>How about adding
>       This = document updates RFC 826 and RFC 2132.

I added a header line that says "Updates: 826, = 2132"

>RFC 2131 actually talks about an ARP reply and = not the ARP request
>with sender=3Dtarget. See section 4.4.1 in RFC = 2131.
>So you don't seem to be consistent with RFC = 2131.

Stevens describes using ARP request.
BSD broadcasts an ARP request to announce its = address.
Mac OS 9 broadcasts an ARP request to announce its = address.
Mac OS X broadcasts an ARP request to announce its = address.
Windows broadcasts an ARP request to announce its = address.

RFC 2131 describes broadcasting an ARP reply, but = like many things in RFC
2131, this is probably a typo. As has been pointed = out many times by many
people, broadcasting an ARP reply is unconventional, = and best avoided
where not necessary. Therefore I avoided it and = followed the behaviour
described by Stevens (and implemented on Mac, = Windows, Unix, etc.)
instead.

In any case, the "Packet Reception" rules = of RFC 826 are exceedingly
clear that checking the packet opcode is the *last* = check that is done,
after all other packet processing has been = completed.

Do you have a technical opinion to offer about which = you think is best?

>I wasn't suggesting a normative reference; that = isn't needed since the
>document is self-contained. But pointing out the = relationship using a
>non-normative reference to draft-ietf-zeroconf-ip= v6-link-local would be
>useful for the implementors that are going to = implement both.

There is already a non-normative reference to the = v4ll draft.

If there is specific text you'd like to see in the = draft, I'd be happy to
consider any suggestions you wish to offer.

>>    At any time, if a = host
>>    receives an ARP packet = (request *or* reply) where the 'sender IP
>>    address' is the host's = own IP address, but the 'sender hardware
>>    address' does not match = any of the host's own interface addresses,
>>    then this is a = conflicting ARP packet
>
>I fail to find the word "multihoming" = or any explicit mention of
>multiple interfaces in the above text.

The phrase, "any of the host's own interface = addresses" is a mention of
multiple interfaces.

If there is specific text you'd like to see in the = draft, I'd be happy to
consider any suggestions you wish to offer.

>> > I would assume that ACD can
>> > operate independently for each = interface even though v4LL has some
>> > extra stuff related to multi-interface = nodes.
>>
>> No, the specification needs to deal with = the case when a host has two
>> interfaces (say wireless and Ethernet) on = the same link.
>
>And you claim you can't do that by having the = interfaces be configured
>independently of eachother?

If there is specific text you'd like to see in the = draft, I'd be happy to
consider any suggestions you wish to offer.

>I think my conclusion was that the time should be = shorter
>than 8 seconds and not longer. 8 seconds is a = useless compromise
>as far as I can tell since it is unecessarily = long when STP isn't triggered
>and too short when STP is triggered (with out of = the box bridge
>configurations.) Thus 2 or 3 seconds should be = fine.

The document already has specific text allowing = shorter timeouts in cases
where the implementer has reason to believe that is = a wise design choice.

The document already has specific text describing how = the individual
choice of timeout doesn't have any impact on = interoperability with other
devices.

If there is specific text you'd like to see in the = draft, I'd be happy to
consider any suggestions you wish to offer.

>> Most network operators today, with good = reason, set their port blocking
>> time to five seconds.
>
>Doesn't match my experience. And doesn't match = the IEEE 802.1D
>recommendation.

If there is specific text you'd like to see in the = draft, I'd be happy to
consider any suggestions you wish to offer.

>Is there a way for the host to reliably detect = whether the switches run
>RSTP instead of STP?

Quoting from Mick Seaman: "Yes, the driver can = easily tell the difference
between an RSTP and an STP BPDU, they are different = 'BPDU types', a type
field being defined in the BPDU format."

If there is specific text you'd like to see in the = draft, I'd be happy to
consider any suggestions you wish to offer.

>> A Zero Configuration device may want to make = use of address conflict
>> detection. If address conflict detection = requires a mandatory
>> user-configuration option, then that means = that Zero Configuration
>> devices require mandatory = user-configuration options, a
>> self-contradiction.
>
>I'd understand that comment if it was about =
>draft-ietf-zeroconf-ipv4-link-local
>but not about the ACD document. Since the = addresses are configured either
>manually or by DHCP (or some other provisioning = protocol) it is possible to
>add a knob in the manual config or in DHCP, = respectively. So I don't
>understand the issue your are concerned = about.

I don't understand why you think there is a = problem.

DHCP clients have done address conflict detection for = years, and no one
has asked for an option to disable address conflict = detection there.

Macs have done address conflict detection for manual = addresses for years,
and no one has asked for an option to disable that = either.

Even Windows tells you if you manually set your IP = address to an address
that's already in use.

If you've ever struggled with a network where two = machines were set to
the same IP address, you'd think it insane to ever = think you'd NOT want
to get all the help you can to diagnose and fix that = problem.

I don't understand why now, after all these years of = successful address
conflict detection that no one ever complained = about, there's suddenly a
feeling that we need manual configuration options to = disable it.

Stuart Cheshire <cheshire@apple.com>
 * Wizard Without Portfolio, Apple Computer, = Inc.
 * Chairman, IETF Zeroconf
 * www.stuartcheshire.org

- ------- End of Forwarded Message

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2A612.A4D50EE6-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Dec 18 13:24:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15119; Wed, 18 Dec 2002 13:24:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBIIQgv21918; Wed, 18 Dec 2002 13:26:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDFfcv24789 for ; Fri, 13 Dec 2002 10:41:38 -0500 Received: from sll_ex1.Canton.SLLBOCES.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26070 for ; Fri, 13 Dec 2002 10:38:34 -0500 (EST) Received: from dell ([163.153.44.29] unverified) by sll_ex1.Canton.SLLBOCES.org with Microsoft SMTPSVC(5.0.2195.3779); Fri, 13 Dec 2002 10:37:45 -0500 From: "L.Skelly" To: Date: Fri, 13 Dec 2002 10:40:15 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal X-OriginalArrivalTime: 13 Dec 2002 15:37:45.0218 (UTC) FILETIME=[9500EE20:01C2A2BD] Content-Transfer-Encoding: 7bit Subject: [dhcwg] win98 no release date Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello. I am curious to know if anyone knows what is responsible for win98 workstations getting an ip address from dhcp. However the workstation looses connectivity and when looking at the winipcfg it has no release date set. A manual release and renew cures this but is terribly distressful for my users. This is a seemingly random occurance, I have re-installed tcp/ip protocol and OS in an effort to cure this but to no avail. Any info is greatly appreciated. Thanks Lori _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 20 07:11:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23171; Fri, 20 Dec 2002 07:11:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKCDSv12006; Fri, 20 Dec 2002 07:13:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKCAkv11899 for ; Fri, 20 Dec 2002 07:10:46 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22599; Fri, 20 Dec 2002 07:07:20 -0500 (EST) Message-Id: <200212201207.HAA22599@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 20 Dec 2002 07:07:20 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-isnsoption-04.txt,.pdf Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Options for Internet Storage Name Service Author(s) : J. Tseng et al. Filename : draft-ietf-dhc-isnsoption-04.txt,.pdf Pages : 13 Date : 2002-12-18 This document describes the DHCP option to allow iSNS clients using DHCP to automatically discover the location of the iSNS server. iSNS provides discovery and management capabilities for iSCSI and Fibre Channel storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-isnsoption-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-isnsoption-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-18131544.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-isnsoption-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-isnsoption-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-18131544.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 20 10:50:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29933; Fri, 20 Dec 2002 10:50:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKFqgv22964; Fri, 20 Dec 2002 10:52:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKFpPv22930 for ; Fri, 20 Dec 2002 10:51:25 -0500 Received: from e33.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29903 for ; Fri, 20 Dec 2002 10:47:57 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gBKFohZn023178; Fri, 20 Dec 2002 10:50:44 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gBKFogA7116452; Fri, 20 Dec 2002 08:50:43 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id gBKFlgj01291; Fri, 20 Dec 2002 10:47:42 -0500 Message-Id: <200212201547.gBKFlgj01291@rotala.raleigh.ibm.com> To: Paul Duffy cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt In-Reply-To: Message from Paul Duffy of "Tue, 22 Oct 2002 22:43:58 EDT." <4.3.2.7.2.20021022180633.04fd38a8@funnel.cisco.com> Date: Fri, 20 Dec 2002 10:47:42 -0500 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I was about to put this document back before the IESG formally, but I notice that the IANA considerations section still talks about future cablelabs suboptions being assigned via "expert review". I thought there was agreement to make this "IETF Consensus". I.e., see: http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01416.html I haven't checked the other edits carefully. Is this document *really* ready for advancement, or did some other things get left out? Also, general comment (not to single this ID out, though it occurs here). When making changes to documents in response to issues that have been raised (especially on the mailing list), it is generally preferable to respond to such comments not just by saying "OK, will be fixed in the next rev", but by saying "OK, here are the text changes I propose -- do they look OK?" The advantage of this approach is you get instant review/feedback on whether the changes are ideal. I mention this here because there was discussion about whether to include a normative reference to the dhc-concat draft, in the case where options are too long to fit in a single option. There was no indication on the mailing list that this change would be made, but there is new text to that effect in the document: {+When the total length of a CCC option exceeds 255 octets, the procedure outlined in [4] SHOULD be employed to split the option into multiple, smaller options.+} My immediate reaction to the text is that this should be a MUST, not a SHOULD. If one goes and reads the definition of SHOULD, it say: > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. In this case, if the CCC option exceeds 255, under what conditions should the SHOULD be ignored? I can't think if any right off. It would have been more efficient to have iterated on this text on the mailing list the point the issue orignally came up. That way, we might have avoided the need for another revision of the document. Note that the same applies for the point above that seems to have been missed. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 20 12:46:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03360; Fri, 20 Dec 2002 12:46:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKHnPv29755; Fri, 20 Dec 2002 12:49:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKHmlv29740 for ; Fri, 20 Dec 2002 12:48:47 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03280 for ; Fri, 20 Dec 2002 12:45:19 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBKHmrYU015378; Fri, 20 Dec 2002 12:48:53 -0500 (EST) Received: from paduffy-w2k.cisco.com (dhcp-161-44-149-126.cisco.com [161.44.149.126]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA25019; Fri, 20 Dec 2002 12:48:18 -0500 (EST) Message-Id: <4.3.2.7.2.20021220115411.02af9638@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Dec 2002 12:47:08 -0500 To: Thomas Narten From: Paul Duffy Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt Cc: dhcwg@ietf.org In-Reply-To: <200212201547.gBKFlgj01291@rotala.raleigh.ibm.com> References: <4.3.2.7.2.20021022180633.04fd38a8@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hello Thomas, Please be aware that a rev 5 was sent to internet-drafts and to yourself several weeks back...it still has not appeared in the DHC WG list. It looks like you're still looking at rev 4. I will re-send the email. At 10:47 AM 12/20/2002 -0500, Thomas Narten wrote: >I was about to put this document back before the IESG formally, but I >notice that the IANA considerations section still talks about future >cablelabs suboptions being assigned via "expert review". I thought >there was agreement to make this "IETF Consensus". I.e., see: > >http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01416.html > >I haven't checked the other edits carefully. Is this document *really* >ready for advancement, or did some other things get left out? This is not my understanding. My understanding is that early on, with Ralph's guidance, we had general consensus for the text as it stands. Some months later a couple questions were raised (noted above). Cablelabs intends to place any new sub-option additions before IETF for approval (witness the recent submission of sub-option 51), but we STRONGLY would prefer to be allowed to assign the sub-option codes. It will make life a bit easier for the component manufacturers, compliance testing, etc. >Also, general comment (not to single this ID out, though it occurs >here). When making changes to documents in response to issues that >have been raised (especially on the mailing list), it is generally >preferable to respond to such comments not just by saying "OK, will be >fixed in the next rev", but by saying "OK, here are the text changes I >propose -- do they look OK?" > >The advantage of this approach is you get instant review/feedback on >whether the changes are ideal. I mention this here because there was >discussion about whether to include a normative reference to the >dhc-concat draft, in the case where options are too long to fit in a >single option. There was no indication on the mailing list that this >change would be made, but there is new text to that effect in the >document: I will adhere to these recommendations in any further correspondence with the list. I would also suggest that this be added to the authors guidelines. > {+When the total length of a CCC option exceeds 255 octets, the > procedure outlined in [4] SHOULD be employed to split the option into > multiple, smaller options.+} > >My immediate reaction to the text is that this should be a MUST, not a >SHOULD. If one goes and reads the definition of SHOULD, it say: > > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course. > >In this case, if the CCC option exceeds 255, under what conditions >should the SHOULD be ignored? I can't think if any right off. The SHOULD resulted from discussions with the device manufacturers. The intent of the SHOULD was to accommodate devices that existed long before this RFC. By making this a MUST, these devices will be non-compliant. PacketCable has been in the works for several years...early field trials are starting. Helps ? Please lets keep this discussion going. With your help, I want to close this draft/RFC up ASAP. Cheers, >It would have been more efficient to have iterated on this text on the >mailing list the point the issue orignally came up. That way, we might >have avoided the need for another revision of the document. Note that >the same applies for the point above that seems to have been missed. >Thomas >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 20 12:49:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03466; Fri, 20 Dec 2002 12:49:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKHq2v29865; Fri, 20 Dec 2002 12:52:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKHp9v29821 for ; Fri, 20 Dec 2002 12:51:09 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03396 for ; Fri, 20 Dec 2002 12:47:39 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBKHpAS7015614; Fri, 20 Dec 2002 12:51:10 -0500 (EST) Received: from paduffy-w2k.cisco.com (dhcp-161-44-149-126.cisco.com [161.44.149.126]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA25202; Fri, 20 Dec 2002 12:50:35 -0500 (EST) Message-Id: <4.3.2.7.2.20021220124900.0480e140@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Dec 2002 12:50:35 -0500 To: dhcwg@ietf.org From: Paul Duffy Cc: ralph Droms , Matt Osman , "Thomas Narten" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_266005525==_" Subject: [dhcwg] Cablelabs Client Configuration Option - draft 5. Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --=====================_266005525==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Please accept the following updated draft for consideration by the DHC working group. The prior version of this draft (4) has just emerged from Last Call, during which several changes were requested. The attached draft contains all these change requests. 1. Sub-option 3 now assigns IP type = 1, FQDN type = 0 (per RFC 3361 convention). 2. Section 13 "valid" changed to "invalid". 3. Reference 14.1.4 is now updated to its proper RFC designation. 4. References 14.2.7 and .8 are updated to proper documents. Thank You, --=====================_266005525==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-dhc-packetcable-05.txt" Internet Engineering Task Force B. Beser INTERNET DRAFT Juniper Networks DHC Working Group P. Duffy (ed.) Document: draft-ietf-dhc-packetcable-05.txt Cisco Systems December 2002 DHCP Option for CableLabs Client Configuration 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This document defines a DHCP option that will be used to configure various devices deployed within CableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). The option content defined within this document will be extended as future CableLabs client devices are developed. 3. Table of Contents 1. Status of this Memo..........................................1 2. Abstract.....................................................1 3. Table of Contents............................................1 4. Conventions used in this document............................2 5. Terminology..................................................2 6. Introduction.................................................2 7. CableLabs Client Configuration Option Format.................4 8. CableLabs Client Configuration Option: Sub-Option Definitions 5 8.1. TSP's DHCP Server Address Sub-Options.......................5 Beser & Duffy 1 Internet Draft DHCP Option for CableLabs Clients December 2002 8.2. TSP's Provisioning Server Address Sub-Option................5 8.3. TSP's AS-REQ/AS-REP Backoff and Retry.......................6 8.4. TSP's AP-REQ/AP-REP Backoff and Retry.......................7 8.5. TSP's Kerberos Realm Name Sub-Option........................7 8.6. TSP's Ticket Granting Server Utilization Sub-Option.........8 8.7. TSP's Provisioning Timer Sub-Option.........................8 9. Informational Description of CCC Option Usage................8 10. IANA Considerations..........................................9 11. Legacy Use Information.......................................9 12. Procedure for Adding Additional Sub-options..................9 13. Security Considerations......................................9 14. References..................................................10 15. Acknowledgments.............................................11 16. Author's Addresses..........................................11 17. Full Copyright Statement....................................11 4. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 5. Terminology Definitions of terms used throughout this document: * "Telephony Service Provider" or "TSP" The business entity from which a subscriber receives telephony service. See RFC 2131[6] for additional DHCP terminology. 6. Introduction Cable Television Laboratories, Inc. (CableLabs) is a non-profit research and development consortium that serves the cable television industry via design and specification of new and emerging broadband service architectures. Several CableLabs initiatives define DHCP clients that have specific DHCP configuration requirements. One such initiative is the PacketCable project. The PacketCable project is aimed at architecting, qualifying, and supporting Internet-based multimedia services over cable-based packet networks. These new multimedia services will include telephony and videoconferencing, delivered using the basic Internet Protocol (IP) technology that is used to send data via the Internet. Beser & Duffy Expires June 2003 2 Internet Draft DHCP Option for CableLabs Clients December 2002 PacketCable 1.0 provides Voice over IP (VoIP) service delivery. The VoIP service is supported at the customer site by two key components: a Cable Modem (CM) and a Media Terminal Adapter (MTA). The CM converts the cable RF signals to/from various IP voice protocols, while the MTA converts the VoIP protocols into analog telephony compatible with a common telephone. The CM and MTA may be packaged together or separately. If packaged together, the unit is referred to as an Embedded-MTA (EMTA - depicted in Figure 1). If packaged separately, the MTA is referred to as a Standalone MTA (SMTA). |----------------------------------------------| | | | |-----------| |-------------| | | | | | | | Telephony | | Media | internal | Cable | | RF Link ---------_|---| Terminal |===========| Modem |----|------- Link | | Adapter | connection| | | | |-----------| |-------------| | | | |----------------------------------------------| Figure 1. PacketCable 1.0 Embedded-MTA The CM and MTA are distinct IP devices: each has its own MAC address and IP configuration. The CM and MTA utilize the DHCP protocol to obtain IP configuration. It is assumed that the CM and MTA may be administered by different business entities. The CM communicates with and is configured by the data access provider's DHCP servers. Likewise, the MTA communicates with and is configured by the Telephony Service Provider's (TSP's) DHCP servers. The PacketCable architecture requires that the business entity controlling configuration of the CM also determines which business entities control the configuration of the MTA. This is similar to the example found in the PSTN system: individuals can pick their long distance carriers even though the ultimate control of their telephone remains with the local carrier. Due to specific needs of the MTA configuration process (described in [7]), a new CableLabs Client Configuration (CCC) option is needed for the DHCP protocol. Both CM and MTA DHCP clients will request this option. When requested, both the CM and TSP DHCP servers will populate this option into DHCP responses. See section 9 for further operational details. It should be noted that, although the CCC option will be initially deployed to support PacketCable VOIP applications, the CCC option will also be used to support various non VOIP applications. Use of the CCC option does not necessarily mean that the service provider is a TSP. Beser & Duffy Expires June 2003 3 Internet Draft DHCP Option for CableLabs Clients December 2002 7. CableLabs Client Configuration Option Format The option begins with a tag octet containing the option code (code TBD). A length octet follows the tag octet. The value of the length octet does not include itself or the tag octet. The length octet is followed by "length" octets of sub-option content (total length, not sub-option count). The option layout is depicted below: +------+--------+--------------+--------------+---+--------------+ | Code | Length | Sub-option 1 | Sub-option 2 |...| Sub-option n | +------+--------+--------------+--------------+---+--------------+ When the total length of a CCC option exceeds 255 octets, the procedure outlined in [4] SHOULD be employed to split the option into multiple, smaller options. A sub-option begins with a tag octet containing the sub-option code. A length octet follows the tag octet. The value of the length octet does not include itself or the tag octet. The length octet is followed by "length" octets of sub-option information. The sub- option layout is depicted below: +-------------------+--------+------------------------+ | Sub-option Code | Length | Sub-option information | +-------------------+--------+------------------------+ The sub-option codes are summarized below. +---------+---------+--------------------------------------------+ | Sub- | Sent to | Description | | option | | | | Code | | | +===================+============================================+ | 1 | CM | TSP's Primary DHCP Server Address | +---------+---------+--------------------------------------------+ | 2 | CM | TSP's Secondary DHCP Server Address | +---------+---------+--------------------------------------------+ | 3 | MTA | TSP's Provisioning Server Address | +---------+---------+--------------------------------------------+ | 4 | MTA | TSP's AS-REQ/AS-REP Backoff and Retry | +---------+---------+--------------------------------------------+ | 5 | MTA | TSP's AP-REQ/AP-REP Backoff and Retry | +---------+---------+--------------------------------------------+ | 6 | MTA | TSP's Kerberos Realm Name | +---------+---------+--------------------------------------------+ | 7 | MTA | TSP's Ticket Granting Server Utilization | +---------+---------+--------------------------------------------+ | 8 | MTA | TSP's Provisioning Timer Value | +---------+---------+--------------------------------------------+ | 9 - 255 | | Reserved for future extensions | +---------+---------+--------------------------------------------+ Beser & Duffy Expires June 2003 4 Internet Draft DHCP Option for CableLabs Clients December 2002 8. CableLabs Client Configuration Option: Sub-Option Definitions The following sections provide detailed descriptions of each sub- option. There are a few general formatting rules: - Fully Qualified Domain Names (FQDNs) MUST be encoded per RFC 1035 [3] section 3.1. Note that a terminating 0 is required. Also note that compression, as described in RFC 1035 [3] section 4.1.4, MUST NOT be applied. - IPv4 addresses MUST be encoded as 4 binary octets in network byte- order (high order byte first). - All multi-octet quantities MUST be encoded per network byte- ordering. 8.1. TSP's DHCP Server Address Sub-Options The TSP DHCP Server Address sub-options identify the DHCP servers from which an MTA is permitted to accept a DHCP OFFER. Sub-option 1 is the address of the TSP's primary DHCP server. Sub-option 2 is the address of the TSP's secondary DHCP server. The sub-option length MUST be 4 and the sub-option MUST include the DHCP server's IPv4 address as follows: Code Len Address +-----+-----+-----+-----+-----+-----+ | 1/2 | 4 | a1 | a2 | a3 | a4 | +-----+-----+-----+-----+-----+-----+ 8.2. TSP's Provisioning Server Address Sub-Option This option contains the address of the TSP's Provisioning server. MTAs communicate with the Provisioning server at various stages in their provisioning process. The address can be configured as either an IPv4 address or as an FQDN. The encoding of sub-option 3 will adhere to one of 2 formats. 1. IPv4 address. The sub-option length MUST be 5. The length octet MUST be followed by a single octet that indicates the specific address type that follows. This type octet MUST be set to 1 to indicate an IPv4 address. The type octet MUST be followed by 4 octets of IPv4 address: Code Len Type Address +-----+-----+-----+-----+-----+-----+-----+ | 3 | 5 | 1 | a1 | a2 | a3 | a4 | +-----+-----+-----+-----+-----+-----+-----+ Beser & Duffy Expires June 2003 5 Internet Draft DHCP Option for CableLabs Clients December 2002 2. FQDN. The length octet MUST be followed by a single octet that indicates the specific address type that follows. This type octet MUST be set to 0 to indicate an FQDN. The type octet MUST be followed by the encoded FQDN: Code Len Type FQDN +-----+-----+-----+-----+-----+ +-----+ | 3 | n+1 | 0 | f1 | f2 |...| fn | +-----+-----+-----+-----+-----+ +-----+ It is not anticipated that additional type codes, beyond IPv4 (1) and FQDN (0), will be required. Thus, IANA will not be required to maintain a registry of type codes. 8.3. TSP's AS-REQ/AS-REP Backoff and Retry This sub-option configures an MTA's Kerberos AS-REQ/AS-REP timeout, backoff, and retry mechanism. RFC-1510 [5] does not define a backoff/retry mechanism to be employed when an AS-REQ/AS-REP message exchange fails. This sub- option contains parameters required by the backoff/retry mechanism outlined in [8]. The encoding of this sub-option is depicted below: Code Len Nom Timeout Max Timeout Max Retries +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 4 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 |r1 |r2 |r3 |r4 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ The length octet of this sub-option MUST contain the value 12. The length octet MUST be followed by 4 octets containing the AS- REQ/AS-REP nominal (initial) timeout value. This value is a 32 bit unsigned quantity in units of seconds. The next 4 octets MUST contain the AS-REQ/AS-REP maximum timeout value. This value is a 32 bit unsigned quantity in units of seconds The final 4 octets MUST contain the AS-REQ/AS-REP maximum retry count. This value is a 32 bit unsigned quantity. Beser & Duffy Expires June 2003 6 Internet Draft DHCP Option for CableLabs Clients December 2002 8.4. TSP's AP-REQ/AP-REP Backoff and Retry This sub-option configures an MTA's Kerberos AP-REQ/AP-REP timeout, backoff, and retry mechanism. RFC-1510 [5] does not define a backoff/retry mechanism to be employed when an AP-REQ/AP-REP message exchange fails. This sub- option contains parameters required by the backoff/retry mechanism outlined in [8]. The encoding of this sub-option is depicted below: Code Len Nom Timeout Max Timeout Max Retries +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 5 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 |r1 |r2 |r3 |r4 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ The length octet of this sub-option MUST contain the value 12. The length octet MUST be followed by 4 octets containing the AP- REQ/AP-REP nominal (initial) timeout value. This value is a 32 bit unsigned quantity in units of seconds. The next 4 octets MUST contain the AP-REQ/AP-REP maximum timeout value. This value is a 32 bit unsigned quantity in units of seconds. The final 4 octets MUST contain the AP-REQ/AP-REP maximum retry count. This value is a 32 bit unsigned quantity. 8.5. TSP's Kerberos Realm Name Sub-Option The PacketCable architecture requires an MTA to authenticate itself to the TSP's network via the Kerberos protocol. A Kerberos Realm name is required at the MTA to permit a DNS lookup for the address of the TSP's Kerberos Key Distribution Center (KDC) entity. The Kerberos Realm name MUST be encoded per the domain style realm name described in RFC 1510 [5]. This realm name MUST be all capital letters and conform to the syntax described in RFC 1035 [3] section 3.1. The sub-option is encoded as follows: Code Len Kerberos Realm Name +-----+-----+-----+-----+ +-----+ | 6 | n | k1 | k2 |...| kn | +-----+-----+-----+-----+ +-----+ Beser & Duffy Expires June 2003 7 Internet Draft DHCP Option for CableLabs Clients December 2002 8.6. TSP's Ticket Granting Server Utilization Sub-Option This sub-option encodes a boolean value which indicates whether an MTA should or should not utilize a TGT (Ticket Granting Ticket) when obtaining a service ticket for one of the PacketCable application servers. The encoding is as follows: Code Len Value +-----+-----+-----+ | 7 | 1 | 1/0 | +-----+-----+-----+ The length MUST be 1. The last octet contains a Boolean value which MUST be either 0 or 1. A value of 1 MUST be interpreted as true. A value of 0 MUST be interpreted as false. 8.7. TSP's Provisioning Timer Sub-Option The provisioning timer defines the maximum time allowed for the MTA provisioning process to complete. If this timer expires before the MTA has completed the provisioning process, the MTA should reset the timer and re-start its provisioning process from the beginning. The sub-option length MUST be 1 and a value between 1 and 30 (minutes, inclusive) MUST be used. If any other value is specified, the MTA MUST treat the sub-option as non-populated. Code Len Value +-----+-----+---------+ | 8 | 1 | (1..30) | +-----+-----+---------+ 9. Informational Description of CCC Option Usage. Cablelabs client devices issue DHCP requests that include DHCP options 55 (Parameter Request List) and 60 (Vendor Class Identifier). Option 55 will request the CCC option from the DHCP server. Option 60 will indicate the specific Cablelabs client device type, thus directing the DHCP server to populate specific CCC sub-option content in its responses. The details of which CCC sub- options are populated for each specific client type are specified in various Cablelabs project specifications. For example, specific usage of the CCC option for the PacketCable project is described in [7]. Note that client devices never populate the CCC option in their DHCP requests. Beser & Duffy Expires June 2003 8 Internet Draft DHCP Option for CableLabs Clients December 2002 10. IANA Considerations IANA has assigned a value of TBD for the DHCP option code described in this document. 11. Legacy Use Information The CableLabs Client Configuration option initially used the site- specific option value of 177 (0xB1). The use of the site-specific option is to be deprecated when IANA issues an official option number. 12. Procedure for Adding Additional Sub-options IANA is requested to maintain a new number space of "CableLabs Client Configuration Sub-options", located in the BOOTP-DHCP Parameters Registry. The initial sub-option codes are described in sections of this document. IANA is requested to register codes for future CableLabs Client Configuration Sub-options with an "Expert Review" approval policy as described in RFC 2434 [2]. Future proposed sub-options will be assigned a numeric code chosen by CableLabs, which will be documented in the Internet Drafts that describe the sub-options. The code assignment will be reviewed by a designated expert from the IETF prior to publication in an RFC. 13. Security Considerations Potential exposures to attack in the DHCP protocol are discussed in section 7 of the DHCP protocol specification [6] and in Authentication for DHCP Messages [9]. The CCC option can be used to misdirect network traffic by providing incorrect DHCP server addresses, incorrect provisioning server addresses, and incorrect Kerberos realm names to a Cablelabs client device. This misdirection can lead to several threat scenarios. A Denial of Service (DoS) attack can result from address information being simply invalid. A man-in-the-middle attack can be mounted by providing addresses to a potential snooper. A malicious TSP can steal customers from the customer selected TSP, by altering the Kerberos realm designation. These threats are mitigated by several factors. Within the cable delivery architecture required by PacketCable, the DHCP client is connected to a network through a cable modem and the CMTS (head-end). The CMTS is explicitly configured with a set of Beser & Duffy Expires June 2003 9 Internet Draft DHCP Option for CableLabs Clients December 2002 DHCP servers to which DHCP requests are forwarded. Further, a correctly configured CMTS will only allow downstream traffic from specific IP addresses/ranges. Assuming that server addresses and Kerberos realm name were successfully spoofed to the point that a malicious client device was able to contact a KDC, the client device must still present valid certificates to the KDC before being service enabled. Given the computational overhead of the certificate validation process, this situation could present a DoS opportunity. Finally, it is possible for a malicious (although certified) TSP to redirect a customer from the customer's selected TSP. It is assumed that all TSP's permitted onto an access providers network are trusted entities that will cooperate to insure peaceful coexistence. If a TSP is found to be redirecting customers, this should be handled as an administrative matter between the access provider and the TSP. 14. References 14.1. Normative 1. S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 2. T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. 3. P. Mockapetris, "Domain Names - Implementation and Specification ", RFC 1035, November 1987 4. T. Lemon and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002. 5. J. Kohl and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. 6. R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, March 1997. 14.2. Informational 7. "PacketCable MTA Device Provisioning Specification", PKT-SP-PROV- I05-021127. http://www.packetcable.com/specifications.html 8. "PacketCable Security Specification", PKT-SP-SEC-I07-021127, http://www.packetcable.com/specifications.html Beser & Duffy Expires June 2003 10 Internet Draft DHCP Option for CableLabs Clients December 2002 9. R. Droms and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001 15. Acknowledgments The authors would like to extend a heartfelt thanks to all those who contributed to the development of the PacketCable Provisioning specifications: Sumanth Channabasappa (Alopa Networks); Angela Lyda, Rick Morris, Rodney Osborne (Arris Interactive); Steven Bellovin and Chris Melle (AT&T); Eugene Nechamkin (Broadcom); John Berg, Maria Stachelek, Matt Osman (CableLabs); Klaus Hermanns, Azita Kia, Michael Thomas, Paul Duffy (Cisco); Deepak Patil (Com21); Jeff Ollis, Rick Vetter (General Instrument/Motorola); Roger Loots, David Walters (Lucent); Peter Bates (Telcordia); Patrick Meehan (Tellabs); Satish Kumar, Itay Sherman, Roy Spitzer (Telogy/TI), Aviv Goren (Terayon); Prithivraj Narayanan (Wipro); and Rich Woundy (AT&T Broadband). 16. Author's Addresses Burcak Beser Juniper Networks 1194 North Matilda Avenue Sunnyvale, CA, 94089 Email: burcak@juniper.net Paul Duffy Cisco Systems 300 Apollo Drive Chelmsford, MA, 01824 Email: paduffy@cisco.com 17. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Beser & Duffy Expires June 2003 11 Internet Draft DHCP Option for CableLabs Clients December 2002 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Beser & Duffy Expires June 2003 12 --=====================_266005525==_ Content-Type: text/plain; charset="us-ascii"; format=flowed -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com --=====================_266005525==_-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 20 12:52:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03577; Fri, 20 Dec 2002 12:52:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKHt6v29979; Fri, 20 Dec 2002 12:55:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKHs4v29928 for ; Fri, 20 Dec 2002 12:54:04 -0500 Received: from e33.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03517 for ; Fri, 20 Dec 2002 12:50:36 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gBKHrWZn023994; Fri, 20 Dec 2002 12:53:32 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gBKHqFA7095304; Fri, 20 Dec 2002 10:52:15 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id gBKHnEG01841; Fri, 20 Dec 2002 12:49:14 -0500 Message-Id: <200212201749.gBKHnEG01841@rotala.raleigh.ibm.com> To: Paul Duffy cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt In-Reply-To: Message from Paul Duffy of "Fri, 20 Dec 2002 12:47:08 EST." <4.3.2.7.2.20021220115411.02af9638@funnel.cisco.com> Date: Fri, 20 Dec 2002 12:49:14 -0500 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > Please be aware that a rev 5 was sent to internet-drafts and to yourself > several weeks back...it still has not appeared in the DHC WG list. You're right. For some reason it hasn't appeared yet. Assume it got lost and needs to be resubmitted.... > It looks like you're still looking at rev 4. I will re-send the > email. The version 05 document (that I have now found my private copy of) seems to have the same issues I mentioned in my earlier note. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 20 13:03:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03790; Fri, 20 Dec 2002 13:03:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKI6Av30316; Fri, 20 Dec 2002 13:06:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKI5Jv30300 for ; Fri, 20 Dec 2002 13:05:19 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03764 for ; Fri, 20 Dec 2002 13:01:51 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBKI5O2d017395; Fri, 20 Dec 2002 13:05:24 -0500 (EST) Received: from paduffy-w2k.cisco.com (dhcp-161-44-149-126.cisco.com [161.44.149.126]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA26295; Fri, 20 Dec 2002 13:04:50 -0500 (EST) Message-Id: <4.3.2.7.2.20021220130206.02af7080@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Dec 2002 13:04:50 -0500 To: Thomas Narten From: Paul Duffy Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt Cc: dhcwg@ietf.org In-Reply-To: <200212201749.gBKHnEG01841@rotala.raleigh.ibm.com> References: <4.3.2.7.2.20021220115411.02af9638@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 12:49 PM 12/20/2002 -0500, Thomas Narten wrote: > > Please be aware that a rev 5 was sent to internet-drafts and to yourself > > several weeks back...it still has not appeared in the DHC WG list. > >You're right. For some reason it hasn't appeared yet. Assume it got >lost and needs to be resubmitted.... > > > It looks like you're still looking at rev 4. I will re-send the > > email. > >The version 05 document (that I have now found my private copy of) >seems to have the same issues I mentioned in my earlier note. We need to get Ralph involved re: IANA considerations section. What's your feeling re: my discussion re: SHOULD on RFC 3396? >Thomas -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 20 13:29:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04980; Fri, 20 Dec 2002 13:29:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKIWEv31929; Fri, 20 Dec 2002 13:32:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKIVgv31890 for ; Fri, 20 Dec 2002 13:31:42 -0500 Received: from e33.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04873 for ; Fri, 20 Dec 2002 13:28:14 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gBKIV6Zn012414; Fri, 20 Dec 2002 13:31:06 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gBKIV5A7091834; Fri, 20 Dec 2002 11:31:05 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id gBKIS4o02210; Fri, 20 Dec 2002 13:28:04 -0500 Message-Id: <200212201828.gBKIS4o02210@rotala.raleigh.ibm.com> To: Paul Duffy cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt In-Reply-To: Message from Paul Duffy of "Fri, 20 Dec 2002 12:47:08 EST." <4.3.2.7.2.20021220115411.02af9638@funnel.cisco.com> Date: Fri, 20 Dec 2002 13:28:04 -0500 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Oops, I didn't respond to the rest of your message. Sorry. Paul Duffy writes: > Hello Thomas, > Please be aware that a rev 5 was sent to internet-drafts and to yourself > several weeks back...it still has not appeared in the DHC WG list. It > looks like you're still looking at rev 4. I will re-send the email. > At 10:47 AM 12/20/2002 -0500, Thomas Narten wrote: > >I was about to put this document back before the IESG formally, but I > >notice that the IANA considerations section still talks about future > >cablelabs suboptions being assigned via "expert review". I thought > >there was agreement to make this "IETF Consensus". I.e., see: > > > >http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01416.html > > > >I haven't checked the other edits carefully. Is this document *really* > >ready for advancement, or did some other things get left out? > This is not my understanding. My understanding is that early on, with > Ralph's guidance, we had general consensus for the text as it stands. Some > months later a couple questions were raised (noted above). Saying there was a consensus in the past, and then *not* responding to the issue when it is raised again saying why you don't want to make change is not consistent with the way the IETF works. In the thread I referenced, there was discussion about how to maybe deal with the concerns Cablelabs had. Ave you had a chance to look at draft-narten-iana-experimental-allocations-02.txt? Does this address any of your concerns? (Or do I still not really understand the concerns behind this?) > Cablelabs intends to place any new sub-option additions before IETF for > approval (witness the recent submission of sub-option 51), but we STRONGLY > would prefer to be allowed to assign the sub-option codes. It will make > life a bit easier for the component manufacturers, compliance > testing, etc. In other words, you want the option number for implementations before the ID has been reviewed and finallized by the community. Isn't this what led to the situation with the current document having sat around for two years before it became urgent to finalize it (and then oops, we've already done it this way, now it's painful to change...). I'll note that the -00 version of this ID appeared in March of 2000. We really need to avoid these types of problems in the future. (And this is a bit of a plea to the WG in general: can we please just finish some of the work that is going on in this WG? Things take a long time becaue folks don't push for closure.) The right way is: 1) propose the option 2) get it reviewed in DHC 3) ship the document to the IESG for approval 4) get a code point assigned. None of the above needs to take years (even if we have examples to the contrary). But if people think a particular document/option is important, then they need to drive it to closure in a timely fashion. I am not a fan of early assignment of code points because I have seen the problems this can lead to, and it futher reduces what little incentive there already seems to be to actually finish a document. > >In this case, if the CCC option exceeds 255, under what conditions > >should the SHOULD be ignored? I can't think if any right off. > The SHOULD resulted from discussions with the device manufacturers. The > intent of the SHOULD was to accommodate devices that existed long before > this RFC. By making this a MUST, these devices will be > non-compliant. PacketCable has been in the works for several years...early > field trials are starting. It is not generally a goal of IETF IDs/RFCs to grandfather earlier implementations. Doing so effectively prevents a document from specifying the correct behavior. Surely you see the problems here. Besides, how can a two year old implementation be compliant with the *current* version of this ID? It seems like we've made a number of signficant changes to it.... > Helps ? Please lets keep this discussion going. With your help, I want to > close this draft/RFC up ASAP. Agreed. Let's get closure and move on. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 20 14:39:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07626; Fri, 20 Dec 2002 14:39:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKJgDv03877; Fri, 20 Dec 2002 14:42:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKJZ4v03005 for ; Fri, 20 Dec 2002 14:35:04 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07398 for ; Fri, 20 Dec 2002 14:31:34 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBKJZ8oM029968; Fri, 20 Dec 2002 14:35:08 -0500 (EST) Received: from paduffy-w2k.cisco.com (dhcp-161-44-149-126.cisco.com [161.44.149.126]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA03330; Fri, 20 Dec 2002 14:34:34 -0500 (EST) Message-Id: <4.3.2.7.2.20021220142915.02902e18@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Dec 2002 14:34:34 -0500 To: Thomas Narten From: Paul Duffy Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt Cc: dhcwg@ietf.org In-Reply-To: <200212201828.gBKIS4o02210@rotala.raleigh.ibm.com> References: <4.3.2.7.2.20021220115411.02af9638@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Thomas, CableLabs/IETF seem to be down to two issues. 1. The IANA considerations section. 2. MUST/SHOULD re: RFC 3396. I'm going to have to discuss this with Cablelabs. I'll try to get these questions answered ASAP, but given the holidays...I'll do what I can. Cheers, At 01:28 PM 12/20/2002 -0500, Thomas Narten wrote: >Oops, I didn't respond to the rest of your message. Sorry. > >Paul Duffy writes: > > > Hello Thomas, > > > Please be aware that a rev 5 was sent to internet-drafts and to yourself > > several weeks back...it still has not appeared in the DHC WG list. It > > looks like you're still looking at rev 4. I will re-send the email. > > > At 10:47 AM 12/20/2002 -0500, Thomas Narten wrote: > > >I was about to put this document back before the IESG formally, but I > > >notice that the IANA considerations section still talks about future > > >cablelabs suboptions being assigned via "expert review". I thought > > >there was agreement to make this "IETF Consensus". I.e., see: > > > > > >http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01416 > .html > > > > > >I haven't checked the other edits carefully. Is this document *really* > > >ready for advancement, or did some other things get left out? > > > This is not my understanding. My understanding is that early on, with > > Ralph's guidance, we had general consensus for the text as it > stands. Some > > months later a couple questions were raised (noted above). > >Saying there was a consensus in the past, and then *not* responding to >the issue when it is raised again saying why you don't want to make >change is not consistent with the way the IETF works. In the thread I >referenced, there was discussion about how to maybe deal with the >concerns Cablelabs had. > >Ave you had a chance to look at >draft-narten-iana-experimental-allocations-02.txt? Does this address >any of your concerns? (Or do I still not really understand the >concerns behind this?) > > > Cablelabs intends to place any new sub-option additions before IETF for > > approval (witness the recent submission of sub-option 51), but we STRONGLY > > would prefer to be allowed to assign the sub-option codes. It will make > > life a bit easier for the component manufacturers, compliance > > testing, etc. > >In other words, you want the option number for implementations before >the ID has been reviewed and finallized by the community. Isn't this >what led to the situation with the current document having sat around >for two years before it became urgent to finalize it (and then oops, >we've already done it this way, now it's painful to change...). I'll >note that the -00 version of this ID appeared in March of 2000. > >We really need to avoid these types of problems in the future. (And >this is a bit of a plea to the WG in general: can we please just >finish some of the work that is going on in this WG? Things take a >long time becaue folks don't push for closure.) > >The right way is: > >1) propose the option >2) get it reviewed in DHC >3) ship the document to the IESG for approval >4) get a code point assigned. > >None of the above needs to take years (even if we have examples to the >contrary). But if people think a particular document/option is >important, then they need to drive it to closure in a timely >fashion. I am not a fan of early assignment of code points because I >have seen the problems this can lead to, and it futher reduces what >little incentive there already seems to be to actually finish a >document. > > > >In this case, if the CCC option exceeds 255, under what conditions > > >should the SHOULD be ignored? I can't think if any right off. > > > The SHOULD resulted from discussions with the device manufacturers. The > > intent of the SHOULD was to accommodate devices that existed long before > > this RFC. By making this a MUST, these devices will be > > non-compliant. PacketCable has been in the works for several > years...early > > field trials are starting. > >It is not generally a goal of IETF IDs/RFCs to grandfather earlier >implementations. Doing so effectively prevents a document from >specifying the correct behavior. Surely you see the problems here. > >Besides, how can a two year old implementation be compliant with the >*current* version of this ID? It seems like we've made a number of >signficant changes to it.... > > > Helps ? Please lets keep this discussion going. With your help, I > want to > > close this draft/RFC up ASAP. > >Agreed. Let's get closure and move on. > >Thomas >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 20 15:38:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09552; Fri, 20 Dec 2002 15:38:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKKfCv07502; Fri, 20 Dec 2002 15:41:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKKeCv07468 for ; Fri, 20 Dec 2002 15:40:12 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09475 for ; Fri, 20 Dec 2002 15:36:42 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBKKeHmA009795; Fri, 20 Dec 2002 15:40:17 -0500 (EST) Received: from paduffy-w2k.cisco.com (dhcp-161-44-149-126.cisco.com [161.44.149.126]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA08486; Fri, 20 Dec 2002 15:39:43 -0500 (EST) Message-Id: <4.3.2.7.2.20021220151206.02af5130@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Dec 2002 15:39:42 -0500 To: Thomas Narten From: Paul Duffy Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt Cc: dhcwg@ietf.org In-Reply-To: <200212201828.gBKIS4o02210@rotala.raleigh.ibm.com> References: <4.3.2.7.2.20021220115411.02af9638@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , ...inline.... >Ave you had a chance to look at >draft-narten-iana-experimental-allocations-02.txt? Does this address >any of your concerns? (Or do I still not really understand the >concerns behind this?) Not sure this helps... > > Cablelabs intends to place any new sub-option additions before IETF for > > approval (witness the recent submission of sub-option 51), but we STRONGLY > > would prefer to be allowed to assign the sub-option codes. It will make > > life a bit easier for the component manufacturers, compliance > > testing, etc. > >In other words, you want the option number for implementations before >the ID has been reviewed and finallized by the community. Isn't this >what led to the situation with the current document having sat around >for two years before it became urgent to finalize it (and then oops, >we've already done it this way, now it's painful to change...). I'll >note that the -00 version of this ID appeared in March of 2000. Is the intent here that IETF wants to insure the sub-option number DOES change (from experimental to official) when a CCC sub-option draft reaches RFC? Forcing a change in the implementations? If that is the case, then this discussion is over and Cablelabs will need to agree to your proposal. Cheers, -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 20 18:42:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15437; Fri, 20 Dec 2002 18:42:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKNidv17979; Fri, 20 Dec 2002 18:44:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKNhVv17958 for ; Fri, 20 Dec 2002 18:43:31 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15367 for ; Fri, 20 Dec 2002 18:40:01 -0500 (EST) Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id gBKNgqvY028789; Fri, 20 Dec 2002 16:42:52 -0700 (MST) Received: from 147.191.89.203 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Fri, 20 Dec 2002 16:42:44 -0700 X-Server-Uuid: 4520D425-5A30-451F-8662-E5DDF307F3B1 Received: by entexchimc01.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 20 Dec 2002 16:42:00 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBD009@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Thomas Narten'" , "Paul Duffy" cc: dhcwg@ietf.org Subject: RE: [dhcwg] draft-ietf-dhc-packetcable-04.txt Date: Fri, 20 Dec 2002 16:42:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 121D757E121767-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thomas, >[Have] you had a chance to look at >draft-narten-iana-experimental-allocations-02.txt? Does this address >any of your concerns? (Or do I still not really understand the >concerns behind this?) It seems that your draft's use of experimental numbers is pretty restrictive. For example, it would allow Paul Duffy to conduct an experiment in his all-Cisco lab, but it doesn't seem that CableLabs could conduct a cross-vendor experiment even in their own lab (forget about any field trials). Quite frankly, I think Paul could just as easily steal a DHCP option code in the 128-254 space for such experimentation. I draw this conclusion from the following paragraphs in your draft, especially the second paragraph: An alternate approach, and the one recommended in this document, is to assign a range of numbers specifically earmarked for testing and experimentation purposes. Mutually consenting devices could use these numbers for whatever purposes they desire, but under the understanding that they are reserved for generic testing purposes, and other implementations may use the same numbers for different experimental uses... From the above, it follows that it would be inappropriate for a group of vendors, a consortia, or another Standards Development Organization to agree amongst themselves to use a particular value for a specific purpose. By definition, experimental numbers are not guaranteed to be unique in any environment other than one where the the local system administrator has chosen to use a particular number for a particular purpose and can ensure that a particular value is not already in use for some other purpose. This comment from the draft could be especially tricky for a headless PacketCable brick: "anyone making use of an experimental number should require the user or customer to explicitly configure the value prior to enabling its usage". -- Rich P.S. Side comment about the draft: is there a reason why there are two different reference numbering schemes (RFC number versus descriptive name) for the two references? [RFC2780] IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers. S. Bradner, V. Paxson. March 2000, RFC 2780. [IANA-CONSIDERATIONS] Guidelines for Writing an IANA Considerations Section in RFCs. T. Narten, H. Alvestrand. October 1998. RFC 2434. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 20 18:42:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15461; Fri, 20 Dec 2002 18:42:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKNikv17997; Fri, 20 Dec 2002 18:44:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKNhav17962 for ; Fri, 20 Dec 2002 18:43:36 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15370 for ; Fri, 20 Dec 2002 18:40:06 -0500 (EST) Received: from mms01-relayb.tci.com (mms01-relayb.broadband.att.com [147.191.90.1]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id gBKNgvvY028808; Fri, 20 Dec 2002 16:42:57 -0700 (MST) Received: from 147.191.90.10 by mms01-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Fri, 20 Dec 2002 16:42:47 -0700 X-Server-Uuid: 90826C58-91B0-45EB-95A5-46B6D42E456F Received: by entexchimc03.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 20 Dec 2002 16:41:59 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBD00A@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Paul Duffy'" , "Thomas Narten" cc: dhcwg@ietf.org Subject: RE: [dhcwg] draft-ietf-dhc-packetcable-04.txt Date: Fri, 20 Dec 2002 16:42:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 121D757D330895-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, >Is the intent here that IETF wants to insure the sub-option number DOES >change (from experimental to official) when a CCC sub-option draft reaches >RFC? Forcing a change in the implementations? If that is the case, then >this discussion is over and Cablelabs will need to agree to your proposal. I wish there was a way to balance IETF's needs to review new suboptions, and CableLabs needs to define new suboptions in a timely fashion. I appreciate the fact that the IETF process allowed the CCC option draft to be cleaned up in many respects (e.g. removing unneeded port numbers, using DHCP option concatenation). At the same time, the IETF process has been relatively slow, compared to CableLabs timelines. Obviously a major part of the problem has been the way the draft was managed -- started in March 2000, suffered long time gaps between drafts, and allowed to expire. But the draft has been fairly actively managed since August 2002 by its two co-authors (one might disagree with their positions, but they have tried to be responsive). If the IESG were to approve the draft in January 2003 and the RFC editor were to publish in March 2003 (being only a little optimistic), that's still seven months since active management -- that's not including the original write-up time. I wonder whether a new suboption could be realistically documented, approved, and published using the standard IETF process within six months. The comparison would be to the CableLabs Change Control process (e.g. ECR/ECO/ECN), in which a change request is typically reviewed and approved by vendors and operators in a 30-day window. The vendors are motivated to review such changes in a timely fashion because it immediately impacts the requirements on products that they produce. However, the CableLabs vendor/operator community often does not have the same technical experience as the IETF audience. The ECx timeframe doesn't sound realistic in an IETF setting, and in fact might be a non-goal. One very messy way to balance between the polar extremes would be that CableLabs throws new experimental suboptions into its non-IETF-endorsed option 177, which suboptions might be ignored or redefined in IETF-endorsed CCC option. But the result is that PacketCable devices and DHCP servers that were serious about the cable market (because they worry about backward compatibility with now-obsolete CableLabs suboptions) would need to implement both option/suboption codes forever. I think we would suffer the same results if some of the CCC suboption space was dedicated to CableLabs-experimental use. Can someone propose something better? -- Rich _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 20 19:46:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16907; Fri, 20 Dec 2002 19:46:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBL0mRv21296; Fri, 20 Dec 2002 19:48:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBL0lnv21272 for ; Fri, 20 Dec 2002 19:47:49 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16891 for ; Fri, 20 Dec 2002 19:44:18 -0500 (EST) Received: from nominum.com (dsl081-147-128.chi1.dsl.speakeasy.net [64.81.147.128]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id gBL0hPq10240; Fri, 20 Dec 2002 18:43:25 -0600 (CST) Date: Fri, 20 Dec 2002 18:47:19 -0600 Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org, "Paul Duffy" , "'Thomas Narten'" To: "Woundy, Richard" From: Ted Lemon In-Reply-To: <6732623D2548D61193C90002A5C88DCC01EBD009@entmaexch02.broadband.att.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I was under the impression that allocation for DHCP relay agent suboptions was not predicated on getting a draft through last call. The rules you're quoting are for mainline DHCP options, which are in short supply. No such problem exists for relay agent suboptions. I can't claim to speak for the WG, but if there is no conflict in the options that were allocated in the CableLabs draft, I don't see any reason why we'd want to change the numbers. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Dec 21 10:49:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08143; Sat, 21 Dec 2002 10:49:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBLFpSv03912; Sat, 21 Dec 2002 10:51:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBLFnOv03856 for ; Sat, 21 Dec 2002 10:49:24 -0500 Received: from e33.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08127 for ; Sat, 21 Dec 2002 10:45:44 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gBLFmfZn028756; Sat, 21 Dec 2002 10:48:41 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-244-208.mts.ibm.com [9.65.244.208]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gBLFmemc091350; Sat, 21 Dec 2002 08:48:40 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id gBLFlrg07073; Sat, 21 Dec 2002 10:47:53 -0500 Message-Id: <200212211547.gBLFlrg07073@cichlid.adsl.duke.edu> To: Paul Duffy cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt In-Reply-To: Message from Paul Duffy of "Fri, 20 Dec 2002 15:39:42 EST." <4.3.2.7.2.20021220151206.02af5130@funnel.cisco.com> Date: Sat, 21 Dec 2002 10:47:53 -0500 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > Is the intent here that IETF wants to insure the sub-option number DOES > change (from experimental to official) when a CCC sub-option draft reaches > RFC? The intent is that the option be reviewed by the community and finalized *before* it becomes either a de facto standard, or one that cablelabs has made a standard through its certification waves. Once it is in effect a standard, - there is little incentive to finish the document - reasonable requests to change the option are rejected as "too late, it's already implemented" - the WG is stuck with a document they may not like, but that they can't do anything about. This is not the way we get good options defined. What we need to figure out how to do is get the IETF to review/bless the option *before* it is needed by cablelabs. > Forcing a change in the implementations? If that is the case, then > this discussion is over and Cablelabs will need to agree to your proposal. Note, the "change" we are talking about is potentially very minor. Just use a different option number. If it is known in advance that it will change, software can be designed to allow it to be changed later. My real concern with the above is the sense that "we can't change even the option number", which to me means that if the IETF asks for changes in the option, its too late as well, since such changes would be even *more* work to make. Right? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Dec 21 10:51:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08174; Sat, 21 Dec 2002 10:51:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBLFrFv03948; Sat, 21 Dec 2002 10:53:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBLFqcv03927 for ; Sat, 21 Dec 2002 10:52:38 -0500 Received: from cichlid.adsl.duke.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08141 for ; Sat, 21 Dec 2002 10:48:58 -0500 (EST) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id gBLFmD107082; Sat, 21 Dec 2002 10:48:14 -0500 Message-Id: <200212211548.gBLFmD107082@cichlid.adsl.duke.edu> To: "Woundy, Richard" cc: "Paul Duffy" , dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt In-Reply-To: Message from "Woundy, Richard" of "Fri, 20 Dec 2002 16:42:39 MST." <6732623D2548D61193C90002A5C88DCC01EBD009@entmaexch02.broadband.att.com> Date: Sat, 21 Dec 2002 10:48:13 -0500 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > It seems that your draft's use of experimental numbers is pretty > restrictive. For example, it would allow Paul Duffy to conduct an experiment > in his all-Cisco lab, but it doesn't seem that CableLabs could conduct a > cross-vendor experiment even in their own lab (forget about any field > trials). That is not the intent. The document is all about permitting experiments. It is not, however, about encouraging general deployment, under the guise of "experiment". > Quite frankly, I think Paul could just as easily steal a DHCP option > code in the 128-254 space for such experimentation. And would that not be an acceptable solution? I *really* would like to understand what the underlying requirement is here. I still feel like perhaps I don't. > I draw this conclusion from the following paragraphs in your draft, > especially the second paragraph: > An alternate approach, and the one recommended in this document, is > to assign a range of numbers specifically earmarked for testing and > experimentation purposes. Mutually consenting devices could use these > numbers for whatever purposes they desire, but under the > understanding that they are reserved for generic testing purposes, > and other implementations may use the same numbers for different > experimental uses... > From the above, it follows that it would be inappropriate for a group > of vendors, a consortia, or another Standards Development > Organization to agree amongst themselves to use a particular value > for a specific purpose. By definition, experimental numbers are not > guaranteed to be unique in any environment other than one where the > the local system administrator has chosen to use a particular number > for a particular purpose and can ensure that a particular value is > not already in use for some other purpose. I can see now the wording above could be better, if your conclusion is that cablelabs can't even test. Experimental use is for testing and experimentation. But, it is not for general deployment. In the latter, one runs the risk of having a chosen number conflict with other usages, so one really needs a dedicated number. So, part of what defines an experiment is what environment it goes into, and whether the scope of the experiment can ensure that use of a number won't conflict with a legitimate use of that number for other authorized purposes (e.g, an official assignment) > This comment from the draft could be especially tricky for a headless > PacketCable brick: "anyone making use of an experimental number should > require the user or customer to explicitly configure the value prior to > enabling its usage". Experimental use numbers are not at all intended for mass deployments or home users to configure their cable modems. If you are shipping modems to home users, you are really not experimenting anymore; you are deploying. > P.S. Side comment about the draft: is there a reason why there are two > different reference numbering schemes (RFC number versus descriptive name) > for the two references? None other than the author is not being consistent and this hadn't been pointed out until now... :-( Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Dec 21 10:55:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08271; Sat, 21 Dec 2002 10:55:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBLFw4v04063; Sat, 21 Dec 2002 10:58:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBLFvZv04044 for ; Sat, 21 Dec 2002 10:57:35 -0500 Received: from cichlid.adsl.duke.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08256 for ; Sat, 21 Dec 2002 10:53:54 -0500 (EST) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id gBLFu6i07518; Sat, 21 Dec 2002 10:56:06 -0500 Message-Id: <200212211556.gBLFu6i07518@cichlid.adsl.duke.edu> To: "Woundy, Richard" cc: "'Paul Duffy'" , dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt In-Reply-To: Message from "Woundy, Richard" of "Fri, 20 Dec 2002 16:42:41 MST." <6732623D2548D61193C90002A5C88DCC01EBD00A@entmaexch02.broadband.att.com> Date: Sat, 21 Dec 2002 10:56:06 -0500 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > I wish there was a way to balance IETF's needs to review new > suboptions, and CableLabs needs to define new suboptions in a timely > fashion. I agree. I am still under the assumption that this is achievable. > I appreciate the fact that the IETF process allowed the CCC option > draft to be cleaned up in many respects (e.g. removing unneeded port > numbers, using DHCP option concatenation). > At the same time, the IETF process has been relatively slow, > compared to CableLabs timelines. Obviously a major part of the > problem has been the way the draft was managed -- started in March > 2000, suffered long time gaps between drafts, and allowed to > expire. But the draft has been fairly actively managed since August > 2002 by its two co-authors (one might disagree with their positions, > but they have tried to be responsive). If the IESG were to approve > the draft in January 2003 and the RFC editor were to publish in > March 2003 (being only a little optimistic), that's still seven > months since active management -- that's not including the original > write-up time. I wonder whether a new suboption could be > realistically documented, approved, and published using the standard > IETF process within six months. I believe it can. IMO, part of the issue here with cablelabs options in particular is a startup issue. We only in August really seriously looked at this document. A number of substantive (and general) issues were raised and have been mostly resolved. (Note also, some of these issues come from bad experiences that have been had in the IPCDN WG, where cablelabs is the main player. I do not believe we can ignore those experiences and just do as has been done in the past, without risking that we are setting ourselves up for failure.) I expect we both have a much better understanding of the needs of the other body, and are in a much better position to move quickly on future documents. Note also, I don't think the delay between IESG approval and RFC publication is a real issue. (If it is we should chat more.) I've been led to understand is that the issue is IESG approval of the document, and IANA assignment of the code points. IANA assigns the code point more-or-less immediately after IESG approval of a document (this can be expedited if it is known to be critical). So the key issue is IESG approval of the document. BTW, despite my grumbling in earlier posting, I did go ahead and put the document in the next IESG telechat (scheduled for next week) so we can hopefully work out the last issues and get IESG review in parallel. So I think we are still quite capable of getting the document approved in January. > The comparison would be to the CableLabs Change Control process > (e.g. ECR/ECO/ECN), in which a change request is typically reviewed > and approved by vendors and operators in a 30-day window. The > vendors are motivated to review such changes in a timely fashion > because it immediately impacts the requirements on products that > they produce. However, the CableLabs vendor/operator community often > does not have the same technical experience as the IETF audience. Are you really saying that the time from initial proposal until the time the spec is finalized is 30 days? I have a hard time believing that. What exactly is "change request" above, and what sorts of changes are allowed? It is one thing to make minor changes, like fixes. It is probably something very different to add something completely new. > The ECx timeframe doesn't sound realistic in an IETF setting, and in > fact might be a non-goal. It is critical that the timeline requirements of cablelabs be exported to the IETF and that the IETF understand what they are. One problem has been that there has been (and still continues to be) confusion about what the real deadlines are. *If* we had firm timelines to look at, we could make a realistic assessment of whether the IETF can do its part within that time frame. We (the WG) can then commit to meeting those needs. This is quite possible, so long as we have a clear understanding of the timelines and we *both* agree to execute on a *realistic* plan. > One very messy way to balance between the polar extremes would be that > CableLabs throws new experimental suboptions into its non-IETF-endorsed > option 177, which suboptions might be ignored or redefined in IETF-endorsed > CCC option. But the result is that PacketCable devices and DHCP servers that > were serious about the cable market (because they worry about backward > compatibility with now-obsolete CableLabs suboptions) would need to > implement both option/suboption codes forever. > I think we would suffer the same results if some of the CCC suboption space > was dedicated to CableLabs-experimental use. Key point: it is the notion that cablelabs takes a pre-finalized version of an option and effectively makes it a standard that is unchangable in practice that is the root problem (this *exact* issue has been a repeating problem in the IPCDN WG). Once you ship something, it becomes *much* harder to modify the option. People say "its not worth it". "We can't change what is already deployed". It is *this* *issue* we need to avoid. We need to get options finalized and through the process prior to them become de facto standards on the cablelabs side. If we can't do that, we might as well just give up. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Dec 23 07:58:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28436; Mon, 23 Dec 2002 07:58:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBND1dv08185; Mon, 23 Dec 2002 08:01:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNCwKv08032 for ; Mon, 23 Dec 2002 07:58:20 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27372; Mon, 23 Dec 2002 07:54:20 -0500 (EST) Message-Id: <200212231254.HAA27372@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 23 Dec 2002 07:54:20 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : KDC Server Address Sub-option Author(s) : K. Luehrs, R. Woundy, J. Bevilacqua Filename : draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt Pages : 4 Date : 2002-12-20 This document defines a new sub-option for the CableLabs Client Configuration (CCC) DHCP option code for conveying the network address of the Key Distribution Center (KDC) server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-20125816.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-20125816.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Dec 23 08:27:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00352; Mon, 23 Dec 2002 08:27:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNDUPv10258; Mon, 23 Dec 2002 08:30:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNDR7v10098 for ; Mon, 23 Dec 2002 08:27:07 -0500 Received: from jupiter.jmi.co.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00042 for ; Mon, 23 Dec 2002 08:23:04 -0500 (EST) Received: (qmail 13121 invoked by uid 525); 23 Dec 2002 22:27:10 +0900 Received: (qmail 13045 invoked from network); 23 Dec 2002 22:27:05 +0900 Received: from unknown (HELO polo.jmi.co.kr) (211.45.79.31) by 0 with SMTP; 23 Dec 2002 22:27:05 +0900 Received: from ran.ietf.org (ran.ietf.org [132.151.6.60]) by polo.jmi.co.kr (8.9.0/8.9.0) with ESMTP id WAA29276 for ; Mon, 23 Dec 2002 22:30:12 +0900 (KST) Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18QSAn-0003dz-00 for ietf-announce-list@ran.ietf.org; Mon, 23 Dec 2002 07:59:09 -0500 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18QSAd-0003ci-00 for all-ietf@ran.ietf.org; Mon, 23 Dec 2002 07:58:59 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27372; Mon, 23 Dec 2002 07:54:20 -0500 (EST) Message-Id: <200212231254.HAA27372@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: hangsang@dreamwiz.com Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 23 Dec 2002 07:54:20 -0500 Precedence: bulk Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : KDC Server Address Sub-option Author(s) : K. Luehrs, R. Woundy, J. Bevilacqua Filename : draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt Pages : 4 Date : 2002-12-20 This document defines a new sub-option for the CableLabs Client Configuration (CCC) DHCP option code for conveying the network address of the Key Distribution Center (KDC) server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-20125816.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-suboptions-kdc-serveraddress-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-20125816.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Dec 23 10:20:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06269; Mon, 23 Dec 2002 10:20:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNFNcv17568; Mon, 23 Dec 2002 10:23:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNFM3v17549 for ; Mon, 23 Dec 2002 10:22:03 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06246 for ; Mon, 23 Dec 2002 10:18:01 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBNFLbvi028449; Mon, 23 Dec 2002 10:21:37 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-137.cisco.com [161.44.149.137]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA29215; Mon, 23 Dec 2002 10:21:01 -0500 (EST) Message-Id: <4.3.2.7.2.20021223101647.0204aed0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 23 Dec 2002 10:20:59 -0500 To: Thomas Narten From: Ralph Droms Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt Cc: "Woundy, Richard" , "'Paul Duffy'" , dhcwg@ietf.org In-Reply-To: <200212211556.gBLFu6i07518@cichlid.adsl.duke.edu> References: <6732623D2548D61193C90002A5C88DCC01EBD00A@entmaexch02.broadband.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , As a way of getting more timely coordination between CableLabs and the IETF, would it be possible to involve the IETF earlier in the process of developing an option? That is, as soon as CableLabs identifies the need for a new sub-option, publish an Internet-Draft describing that sub-option and bring it to the IETF/DHCWG. Development can take place in parallel - Internet-Drafts are cheap - so that the WG has a chance to review the new option and can be prepared to bring it to last call as soon as the CableLabs change control process has the new specs in place. - Ralph At 10:56 AM 12/21/2002 -0500, Thomas Narten wrote: > > I wish there was a way to balance IETF's needs to review new > > suboptions, and CableLabs needs to define new suboptions in a timely > > fashion. > >I agree. I am still under the assumption that this is achievable. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Dec 23 10:44:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07204; Mon, 23 Dec 2002 10:44:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNFlAv18926; Mon, 23 Dec 2002 10:47:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNFkvv18900 for ; Mon, 23 Dec 2002 10:46:57 -0500 Received: from peacock.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07174 for ; Mon, 23 Dec 2002 10:42:54 -0500 (EST) Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id gBNFjYCH006016; Mon, 23 Dec 2002 08:45:34 -0700 (MST) Received: from 147.191.89.201 by mms01-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Mon, 23 Dec 2002 08:45:31 -0700 X-Server-Uuid: 90826C58-91B0-45EB-95A5-46B6D42E456F Received: by entexchimc02.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Mon, 23 Dec 2002 08:45:30 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBD010@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Ted Lemon'" cc: dhcwg@ietf.org, "Paul Duffy" , "'Thomas Narten'" Subject: RE: [dhcwg] draft-ietf-dhc-packetcable-04.txt Date: Mon, 23 Dec 2002 08:45:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1219F011547653-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ted, I thought we were talking about the CCC sub-option numbering space, not the relay information option sub-option numbering space. I'm not even sure that I am advocating that CableLabs "own" the suboption space... -- Rich -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Friday, December 20, 2002 7:47 PM To: Woundy, Richard Cc: dhcwg@ietf.org; Paul Duffy; 'Thomas Narten' Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt I was under the impression that allocation for DHCP relay agent suboptions was not predicated on getting a draft through last call. The rules you're quoting are for mainline DHCP options, which are in short supply. No such problem exists for relay agent suboptions. I can't claim to speak for the WG, but if there is no conflict in the options that were allocated in the CableLabs draft, I don't see any reason why we'd want to change the numbers. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Dec 23 11:41:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08696; Mon, 23 Dec 2002 11:41:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNGiRv22057; Mon, 23 Dec 2002 11:44:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNGhxv21983 for ; Mon, 23 Dec 2002 11:43:59 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08619 for ; Mon, 23 Dec 2002 11:39:55 -0500 (EST) Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id gBNGglvY009908; Mon, 23 Dec 2002 09:42:47 -0700 (MST) Received: from 147.191.89.203 by mms01-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Mon, 23 Dec 2002 09:42:39 -0700 X-Server-Uuid: 90826C58-91B0-45EB-95A5-46B6D42E456F Received: by entexchimc01.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Mon, 23 Dec 2002 09:41:58 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBD011@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Thomas Narten'" cc: "Paul Duffy" , dhcwg@ietf.org Date: Mon, 23 Dec 2002 09:42:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1219E375556167-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] draft-narten-iana-experimental-allocations-03.txt (was Re: [dhcwg ] draft-ietf-dhc-packetcable-04.txt) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thomas, These comments are really about your draft . I thought you were advocating the allocation of a few CCC sub-options for experimentation, not the use of the standard DHCP experimental option space -- which explains this exchange of comments between us: >> Quite frankly, I think Paul could just as easily steal a DHCP option >> code in the 128-254 space for such experimentation. > > And would that not be an acceptable solution? I *really* would like to > understand what the underlying requirement is here. I still feel like > perhaps I don't. So the advice from your draft is to use DHCP experimental options 128-254, and not set aside space for experimental CCC suboptions, right? Now let me consider this exchange: >> This comment from the draft could be especially tricky for a headless >> PacketCable brick: "anyone making use of an experimental number should >> require the user or customer to explicitly configure the value prior to >> enabling its usage". > >Experimental use numbers are not at all intended for mass deployments >or home users to configure their cable modems. If you are shipping >modems to home users, you are really not experimenting anymore; you >are deploying. I don't think you're seeing my real point about headless devices and DHCP option experimentation. Let's disregard cable for this discussion. How does one "explicitly configure the value" on a device without a user interface (i.e. a brick)? Perhaps some devices will obtain an IPv4 link-local address for its testing-accessible interface, and then the device can be configured using an internal web server or SNMP agent -- but that's the ideal (I think). It is perhaps more likely that the only way that the device will know about any DHCP experimental options is if the device has downloaded firmware that understands the option(s). Shouldn't the draft consider this possibility? There's something else that I don't understand: why do you use the term "customers" in your draft? Apparently according to your comments, this term does not apply to broadband Internet customers (cable or otherwise). Then what kinds of customers are "safe"? Why would any "customer" be willing to stop such an experiment, if the experiment helped them resolve some problem or added a feature? -- Rich -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Saturday, December 21, 2002 10:48 AM To: Woundy, Richard Cc: Paul Duffy; dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt > It seems that your draft's use of experimental numbers is pretty > restrictive. For example, it would allow Paul Duffy to conduct an experiment > in his all-Cisco lab, but it doesn't seem that CableLabs could conduct a > cross-vendor experiment even in their own lab (forget about any field > trials). That is not the intent. The document is all about permitting experiments. It is not, however, about encouraging general deployment, under the guise of "experiment". > Quite frankly, I think Paul could just as easily steal a DHCP option > code in the 128-254 space for such experimentation. And would that not be an acceptable solution? I *really* would like to understand what the underlying requirement is here. I still feel like perhaps I don't. > I draw this conclusion from the following paragraphs in your draft, > especially the second paragraph: > An alternate approach, and the one recommended in this document, is > to assign a range of numbers specifically earmarked for testing and > experimentation purposes. Mutually consenting devices could use these > numbers for whatever purposes they desire, but under the > understanding that they are reserved for generic testing purposes, > and other implementations may use the same numbers for different > experimental uses... > From the above, it follows that it would be inappropriate for a group > of vendors, a consortia, or another Standards Development > Organization to agree amongst themselves to use a particular value > for a specific purpose. By definition, experimental numbers are not > guaranteed to be unique in any environment other than one where the > the local system administrator has chosen to use a particular number > for a particular purpose and can ensure that a particular value is > not already in use for some other purpose. I can see now the wording above could be better, if your conclusion is that cablelabs can't even test. Experimental use is for testing and experimentation. But, it is not for general deployment. In the latter, one runs the risk of having a chosen number conflict with other usages, so one really needs a dedicated number. So, part of what defines an experiment is what environment it goes into, and whether the scope of the experiment can ensure that use of a number won't conflict with a legitimate use of that number for other authorized purposes (e.g, an official assignment) > This comment from the draft could be especially tricky for a headless > PacketCable brick: "anyone making use of an experimental number should > require the user or customer to explicitly configure the value prior to > enabling its usage". Experimental use numbers are not at all intended for mass deployments or home users to configure their cable modems. If you are shipping modems to home users, you are really not experimenting anymore; you are deploying. > P.S. Side comment about the draft: is there a reason why there are two > different reference numbering schemes (RFC number versus descriptive name) > for the two references? None other than the author is not being consistent and this hadn't been pointed out until now... :-( Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Dec 23 12:41:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10313; Mon, 23 Dec 2002 12:41:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNHiJv25947; Mon, 23 Dec 2002 12:44:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNHh6v25902 for ; Mon, 23 Dec 2002 12:43:06 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10197 for ; Mon, 23 Dec 2002 12:39:02 -0500 (EST) Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id gBNHfvvY028802; Mon, 23 Dec 2002 10:41:57 -0700 (MST) Received: from 147.191.89.203 by mms01-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Mon, 23 Dec 2002 10:41:47 -0700 X-Server-Uuid: 90826C58-91B0-45EB-95A5-46B6D42E456F Received: by entexchimc01.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Mon, 23 Dec 2002 10:41:06 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBD014@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Ralph Droms'" , "Thomas Narten" cc: "'Paul Duffy'" , dhcwg@ietf.org Subject: RE: [dhcwg] draft-ietf-dhc-packetcable-04.txt Date: Mon, 23 Dec 2002 10:41:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12199551564731-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit OK, let's see how such coordination works with a real example: . This draft defines a single new CCC sub-option for use in so-called "CableHome" devices. It was separated from the CCC option draft due to the timing of the CCC WG last-call, etc. This draft isn't perfect -- e.g. its IANA considerations section is awaiting what happens to the CCC option draft -- but it is pretty close to what CableLabs would be expecting. There has been no complaints about the review schedule of this draft so far, because cable folks realize that the CCC option draft needs to be approved first. If the CCC draft were to be approved in January, how long would it take to get this new draft approved? -- Rich -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, December 23, 2002 10:21 AM To: Thomas Narten Cc: Woundy, Richard; 'Paul Duffy'; dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt As a way of getting more timely coordination between CableLabs and the IETF, would it be possible to involve the IETF earlier in the process of developing an option? That is, as soon as CableLabs identifies the need for a new sub-option, publish an Internet-Draft describing that sub-option and bring it to the IETF/DHCWG. Development can take place in parallel - Internet-Drafts are cheap - so that the WG has a chance to review the new option and can be prepared to bring it to last call as soon as the CableLabs change control process has the new specs in place. - Ralph At 10:56 AM 12/21/2002 -0500, Thomas Narten wrote: > > I wish there was a way to balance IETF's needs to review new > > suboptions, and CableLabs needs to define new suboptions in a timely > > fashion. > >I agree. I am still under the assumption that this is achievable. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Dec 23 13:57:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12590; Mon, 23 Dec 2002 13:57:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNJ0Uv29932; Mon, 23 Dec 2002 14:00:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNIxBv29869 for ; Mon, 23 Dec 2002 13:59:11 -0500 Received: from peacock.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12556 for ; Mon, 23 Dec 2002 13:55:08 -0500 (EST) Received: from mms02-RelayB.tci.com (mms02-relayb.broadband.att.com [147.191.89.213]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id gBNIw1CH007030; Mon, 23 Dec 2002 11:58:01 -0700 (MST) Received: from 147.191.90.10 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Mon, 23 Dec 2002 11:57:54 -0700 X-Server-Uuid: 43374831-6ABA-4273-9165-009ABBFC7FBB Received: by entexchimc03.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Mon, 23 Dec 2002 11:57:04 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBD016@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Thomas Narten'" cc: "'Paul Duffy'" , dhcwg@ietf.org Subject: RE: [dhcwg] draft-ietf-dhc-packetcable-04.txt Date: Mon, 23 Dec 2002 11:57:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12198338215288-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thomas, (Reminder: this discussion is about defining future CCC sub-options, e.g. about the IANA Considerations for draft-ietf-dhc-packetcable-05.txt) The 30-day clock on the CableLabs change control process can be reset for major changes, so everything at CableLabs does not have to be decided in 30 days. It would not have been realistic for all the changes embodied in draft-ietf-dhc-packetcable-04.txt to be approved in one CableLabs 30-day review cycle, which is why I stated: > The ECx timeframe doesn't sound realistic in an IETF setting, and in > fact might be a non-goal. It might be more realistic for the (theoretical) definition of an additional CCC sub-option to be approved by CableLabs in 30 days -- especially if the sub-option were an obvious solution, a "no-brainer" if you will. That was the real concern from my email. But let's talk about the real CableLabs milestones, which revolve around product certification waves. Here are two sources for such information: -- please focus on the Certification Wave dates here Note that the ECR (Engineering Change Request) cut-off date from the second link above is 30 days before the ECN (Engineering Change Notice) acceptance date from the first link above. This is the effect of the CableLabs change control process 30-day clock. The ECR is written at the beginning of the change control process, and the ECN is the output of the change control process. Once a cable-related internet-draft is IESG-approved and has IANA-assigned numbers (e.g. option and sub-option codes), then someone in the CableLabs community writes and submits an appropriate ECR, which would presumably be approved and issued as an ECN 30 days later. The base CableLabs specifications plus the ECNs form the requirements for CableLabs product certification. CableLabs will not certify equipment in a particular wave, unless it meets the requirements from the ECNs that apply to that wave. That's how cable vendors are motivated to implement requirements in their products -- and also why they are motivated to review ECRs within the 30-day window. As you can see from the CableLabs milestones, if a particular ECR/ECN deadline is missed, we suffer a 4-5 month delay on product implementation and deployment. That's why CableLabs would be concerned about timeliness in specification approvals. Hope this helps in our mutual understanding of approval processes. -- Rich -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Saturday, December 21, 2002 10:56 AM To: Woundy, Richard Cc: 'Paul Duffy'; dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt [snip] > The comparison would be to the CableLabs Change Control process > (e.g. ECR/ECO/ECN), in which a change request is typically reviewed > and approved by vendors and operators in a 30-day window. The > vendors are motivated to review such changes in a timely fashion > because it immediately impacts the requirements on products that > they produce. However, the CableLabs vendor/operator community often > does not have the same technical experience as the IETF audience. Are you really saying that the time from initial proposal until the time the spec is finalized is 30 days? I have a hard time believing that. What exactly is "change request" above, and what sorts of changes are allowed? It is one thing to make minor changes, like fixes. It is probably something very different to add something completely new. > The ECx timeframe doesn't sound realistic in an IETF setting, and in > fact might be a non-goal. It is critical that the timeline requirements of cablelabs be exported to the IETF and that the IETF understand what they are. One problem has been that there has been (and still continues to be) confusion about what the real deadlines are. *If* we had firm timelines to look at, we could make a realistic assessment of whether the IETF can do its part within that time frame. We (the WG) can then commit to meeting those needs. This is quite possible, so long as we have a clear understanding of the timelines and we *both* agree to execute on a *realistic* plan. [snip] _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Dec 23 15:15:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14325; Mon, 23 Dec 2002 15:15:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNKIOv01490; Mon, 23 Dec 2002 15:18:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNKHfv01474 for ; Mon, 23 Dec 2002 15:17:41 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14318 for ; Mon, 23 Dec 2002 15:13:36 -0500 (EST) Received: from nominum.com (dialup-64.158.80.160.Dial1.Buffalo1.Level3.net [64.158.80.160]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id gBNKCBq19430; Mon, 23 Dec 2002 14:12:11 -0600 (CST) Date: Mon, 23 Dec 2002 14:16:40 -0600 Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'Thomas Narten'" , "Paul Duffy" , dhcwg@ietf.org To: "Woundy, Richard" From: Ted Lemon In-Reply-To: <6732623D2548D61193C90002A5C88DCC01EBD010@entmaexch02.broadband.att.com> Message-Id: <72A2F8AD-16B3-11D7-8657-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I thought we were talking about the CCC sub-option numbering space, > not the > relay information option sub-option numbering space. D'oh, sorry. The point is still the same - we do not need as draconian a standard as we have for DHCP options. WG consensus that the suboption is okay should be enough to allow assignment of a code - that is, we don't have to agree on the exact final wording of the RFC before you get a code. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Dec 23 16:25:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15482; Mon, 23 Dec 2002 16:25:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNLSUv04272; Mon, 23 Dec 2002 16:28:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNLMGv04140 for ; Mon, 23 Dec 2002 16:22:16 -0500 Received: from peacock.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15439 for ; Mon, 23 Dec 2002 16:18:10 -0500 (EST) Received: from mms02-relaya.tci.com (mms02-relaya.broadband.att.com [147.191.89.206]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id gBNLL5CH019768; Mon, 23 Dec 2002 14:21:05 -0700 (MST) Received: from 147.191.89.201 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Mon, 23 Dec 2002 14:21:02 -0700 X-Server-Uuid: 43374831-6ABA-4273-9165-009ABBFC7FBB Received: by entexchimc02.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Mon, 23 Dec 2002 14:21:01 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBD01A@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Thomas Narten'" , "Paul Duffy" cc: dhcwg@ietf.org Subject: RE: [dhcwg] draft-ietf-dhc-packetcable-04.txt Date: Mon, 23 Dec 2002 14:20:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1219A1B4231847-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thomas, I think I agree with the main points of your email below. First, I agree that it is unreasonable for CableLabs to define a new option/sub-option, to choose a option/sub-option code, to mandate implementation of that option/sub-option in certified products -- and then later to take that specification and to expect to have it rubber-stamped by an IETF working group. That is a waste of time for everyone involved. Second, I agree that the correct direction is for CableLabs to submit drafts for IETF critical review and blessing -- before it is required in certified products. This direction may be sometimes painful culturally for the CableLabs community, but the "pain" should enable the industry to specify new features in a better long-term way (e.g. not having to re-specify the same features). I think our point of divergence is about maintaining some flexibility for CableLabs. Let's suppose, hypothetically, that someone discovers that the cable industry need an additional CCC suboption right now, and writes and submits a new draft today. Also consider the current CableLabs calendar, . If the new draft isn't approved by IANA before February 12th (which I believe is incredibly aggressive), then CableLabs would not certify any products in compliance with the new draft before November 17th, which would imply no significant cable deployments until 2004. If the draft represents a nice-to-have feature, then this delay might be acceptable. If the draft represents an emergency item that would otherwise prevent VoIP over cable deployments in 2003, then the delay would be crushing. For an emergency extension, I can imagine these two possible responses: - CableLabs and the IETF/IESG would work on this draft in "emergency mode" to make a very aggressive date. That seems to be pushing to the limits on an all-volunteer organization such as the IETF. It also begs the question about whether CableLabs and the IETF would agree about what constitutes an "emergency". - CableLabs could define its own interim extension, perhaps with some help from the IETF. The IETF/IESG would approve the draft on its own timetable, on its own terms (e.g. likely changing syntax and option codes). CableLabs vendors in the future would have to support both the CableLabs extension (backward compatibility) and the IETF draft/RFC extension for product certification -- until the CableLabs extension is phased out. Note that the CableLabs vendor implementation penalty for not working through the IETF process would be to implement two similar mechanisms (e.g. two sub-options) for the same extension. That would provide incentive to work as early as possible through the IETF as part of the normal specification process. I hope you see where I am going with this... -- Rich -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Saturday, December 21, 2002 10:48 AM To: Paul Duffy Cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt > Is the intent here that IETF wants to insure the sub-option number DOES > change (from experimental to official) when a CCC sub-option draft reaches > RFC? The intent is that the option be reviewed by the community and finalized *before* it becomes either a de facto standard, or one that cablelabs has made a standard through its certification waves. Once it is in effect a standard, - there is little incentive to finish the document - reasonable requests to change the option are rejected as "too late, it's already implemented" - the WG is stuck with a document they may not like, but that they can't do anything about. This is not the way we get good options defined. What we need to figure out how to do is get the IETF to review/bless the option *before* it is needed by cablelabs. > Forcing a change in the implementations? If that is the case, then > this discussion is over and Cablelabs will need to agree to your proposal. Note, the "change" we are talking about is potentially very minor. Just use a different option number. If it is known in advance that it will change, software can be designed to allow it to be changed later. My real concern with the above is the sense that "we can't change even the option number", which to me means that if the IETF asks for changes in the option, its too late as well, since such changes would be even *more* work to make. Right? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 27 18:12:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16083; Fri, 27 Dec 2002 18:12:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBRNGAJ32232; Fri, 27 Dec 2002 18:16:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBRNDcJ32166 for ; Fri, 27 Dec 2002 18:13:39 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16056 for ; Fri, 27 Dec 2002 18:07:35 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id gBRNAMTp002698; Fri, 27 Dec 2002 16:10:22 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [dhcwg] draft-ietf-dhc-packetcable-04.txt Date: Fri, 27 Dec 2002 16:10:21 -0700 Message-ID: Thread-Topic: [dhcwg] draft-ietf-dhc-packetcable-04.txt Thread-Index: AcKodsugkaANrKoEQt2fA8O9gZvorAFfuXSQ From: "Jean-Francois Mule" To: "Paul Duffy" , "Thomas Narten" , "Woundy, Richard" Cc: X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBRNDdJ32167 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit We should clearly separate (1) the technical comments on the present Internet-draft from (2) the policy question on how IETF would like DHCP options and sub-options to be temporarily assigned for testing. (1) MUST/SHOULD re: RFC 3396. This is related to the CCC and present sub-options. We will get closure on this asap. Personally, I'm ok with changing the current draft to mandate a MUST on 3396. (2) policy question: For now, we have a short term need to get the CCC option approved and passed IESG so that we can update our spec and vendors can start building to it. This is time critical here to implement the IETF RFC by certification wave 26. Couldn't the policy discussion should be eliminated from this draft for now by stating the conclusion of the Oct 15 thread, that is: IANA is requested to register codes for future CableLabs Client Configuration sub-options with an "IETF consensus" approval policy as described in RFC 2434 [2]. Future proposed sub-options will submitted to IETF for review. --> This means: IETF consensus is required and IANA assigns the value. I think the rest of the discussion belongs to draft-narten-iana-experimental-allocations-03.txt. It should not be specific to CableLabs. As long as we address in a future document how we can get some experimental codes to define the functionality and test it while the IETF review process takes place, I think we are ok. Thomas did address some of the concerns I raised on Oct 15 in draft-narten-iana-experimental-allocations-03.txt and Rich made some good points. Jean-Francois. /---------------------- Jean-Francois Mule CableLabs, PacketCable jfm@cablelabs.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Dec 27 18:12:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16107; Fri, 27 Dec 2002 18:12:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBRNH6J32271; Fri, 27 Dec 2002 18:17:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBRNGkJ32243 for ; Fri, 27 Dec 2002 18:16:46 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16066 for ; Fri, 27 Dec 2002 18:10:42 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id gBRNDaTp002745; Fri, 27 Dec 2002 16:13:36 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [dhcwg] draft-ietf-dhc-packetcable-04.txt Date: Fri, 27 Dec 2002 16:13:36 -0700 Message-ID: Thread-Topic: [dhcwg] draft-ietf-dhc-packetcable-04.txt Thread-Index: AcKogcMXCDYY5kcuR9m0EijNWXDCiwFe2yPA From: "Jean-Francois Mule" To: "Woundy, Richard" , "Paul Duffy" , "Thomas Narten" Cc: X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBRNGkJ32244 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit So that this thread does not read like a risk game between CableLabs vs. IETF, note that: (a) references of CableLabs in this thread are sometimes "abusive". It is the intent of CableLabs to work with IETF and rely on IETF for DHCP option/sub-option assignments and review. (b)The CableLabs PacketCable provisioning spec has been clear for quite some time now on this DHCP option code: PKT-SP-PROV-I05-021127 publicly posted states In section 8: "The CM and MTA requirements for DHCP Option Codes 177 [...] are detailed in section 8.1 [...]. These DHCP options are currently defined in a draft proposal submitted to the Internet Engineering Task Force (IETF) DHCP committee [13]." In section 8.1: "DHCP option code 177 is a temporary code that the PacketCable embedded-MTA device can use until a permanent code is assigned by the IETF." Jean-Francois. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Dec 30 18:14:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03756; Mon, 30 Dec 2002 18:14:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUNKWJ03092; Mon, 30 Dec 2002 18:20:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUNILJ02990 for ; Mon, 30 Dec 2002 18:18:21 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03699 for ; Mon, 30 Dec 2002 18:10:48 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBUNEZtj007868; Mon, 30 Dec 2002 18:14:35 -0500 (EST) Received: from paduffy-w2k.cisco.com (dhcp-161-44-149-126.cisco.com [161.44.149.126]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA22982; Mon, 30 Dec 2002 18:13:56 -0500 (EST) Message-Id: <4.3.2.7.2.20021230165226.047f0ea0@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 30 Dec 2002 18:13:55 -0500 To: From: Paul Duffy Subject: [dhcwg] draft-ietf-dhc-packetcable-05.txt Cc: "Thomas Narten" , Ralph Droms In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Thomas/everyone, Regarding the two remaining issues with this draft... 1. MUST/SHOULD re: RFC 3396. There appears to be initial agreement within the Cablelabs community to change this to a MUST. I propose the following text change (top of page 4). Old text... "When the total length of a CCC option exceeds 255 octets, the procedure outlined in [4] SHOULD be employed to split the option into multiple, smaller options." New text... "When the total length of a CCC option exceeds 255 octets, the procedure outlined in [4] MUST be employed to split the option into multiple, smaller options." 2. Section 12 "Procedure for Adding Additional Sub-options". The Cablelabs community desires input into the sub-option code assignments for a couple of reasons. a) the need to get sub-option codes assigned as quickly as the IETF process will allow and b) Cablelabs wishes to partition the sub-option code space amongst various CableLabs projects. For example: sub-options 1 to 50 will be assigned to the PacketCable project, sub-options 51 - 100 assigned to the CableHome project, etc. With these points in mind, I'd like to propose the following text changes to section 12. Old text... "IANA is requested to register codes for future CableLabs Client Configuration Sub-options with an "Expert Review" approval policy as described in RFC 2434 [2]. Future proposed sub-options will be assigned a numeric code chosen by CableLabs, which will be documented in the Internet Drafts that describe the sub-options. The code assignment will be reviewed by a designated expert from the IETF prior to publication in an RFC." New text... "IANA is requested to register codes for future CableLabs Client Configuration Sub-options with an "Expert Review" approval policy as described in RFC 2434 [2]. Future proposed sub-options will be assigned a numeric code chosen by CableLabs immediately following IESG approval of the draft. This code assignment will then be reviewed by an IETF designated expert." The intent of the this text change is to allow Cablelabs to choose the sub-option code assignment, but not until the sub-option draft has cleared IESG approval and the designated expert's review. Thoughts? -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Dec 30 18:45:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04188; Mon, 30 Dec 2002 18:45:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUNpMJ04637; Mon, 30 Dec 2002 18:51:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUNoPJ04605 for ; Mon, 30 Dec 2002 18:50:25 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04154 for ; Mon, 30 Dec 2002 18:42:52 -0500 (EST) Received: from nominum.com (user-0cceg6c.cable.mindspring.com [24.199.64.204]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id gBUNeMq03193; Mon, 30 Dec 2002 17:40:22 -0600 (CST) Date: Mon, 30 Dec 2002 18:45:54 -0500 Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-05.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Ralph Droms , "Thomas Narten" , To: Paul Duffy From: Ted Lemon In-Reply-To: <4.3.2.7.2.20021230165226.047f0ea0@funnel.cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Future proposed sub-options will be assigned a numeric code chosen by > CableLabs immediately following IESG approval of the draft. What does "IETF approval of the draft" mean? If it means that the draft has been adopted by the WG, sounds fine, but if it means that the draft has passed the IESG review, then what's the point of the expert review? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Dec 30 23:26:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07525; Mon, 30 Dec 2002 23:26:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBV4WrJ17297; Mon, 30 Dec 2002 23:32:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBV4VWJ17278 for ; Mon, 30 Dec 2002 23:31:32 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07509 for ; Mon, 30 Dec 2002 23:23:54 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBV4Re8Y004160; Mon, 30 Dec 2002 23:27:40 -0500 (EST) Received: from paduffy-w2k.cisco.com (che-vpn-cluster-2-9.cisco.com [10.86.242.9]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA04106; Mon, 30 Dec 2002 23:27:00 -0500 (EST) Message-Id: <4.3.2.7.2.20021230231439.02c085f8@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 30 Dec 2002 23:27:00 -0500 To: Ted Lemon From: Paul Duffy Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-05.txt Cc: Ralph Droms , "Thomas Narten" , In-Reply-To: References: <4.3.2.7.2.20021230165226.047f0ea0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 06:45 PM 12/30/2002 -0500, Ted Lemon wrote: >>Future proposed sub-options will be assigned a numeric code chosen by >>CableLabs immediately following IESG approval of the draft. > >What does "IETF approval of the draft" mean? If it means that the draft >has been adopted by the WG, sounds fine, but if it means that the draft >has passed the IESG review, then what's the point of the expert review? > Hi Ted, The point I am trying to get across is that the DHC WG, ADs, IESG, etc. approve the technical content/semantics of the sub-option, then Cablelabs would assign the sub-option code. I'm trying to balance CableLab's need for speed with IETF's review of the content of the sub-option. The expert review would be only for the choice of sub-option code assignment(?), not the actual technical content of the draft. So the order of events would be: 1. CCC sub-option draft submitted to DHC WG. 2. DHC WG, AD, IESG review/approve sub-option format and content. 3. Cablelabs assigns sub-option code. 4. IETF expert reviewer approves code assignment. 5a. Cablelabs compliant vendors start implementing sub-option for testing and shipment to customer. 5b. Draft is simultaneously submitted to RFC editor Q. If all goes well, field shipments can commence just about the time the RFC exits the editor Q. I'm grasping for a compromise here. Any suggestions? Cheers, -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Dec 31 08:37:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23275; Tue, 31 Dec 2002 08:37:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBVDi5J22355; Tue, 31 Dec 2002 08:44:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBVDg7J22322 for ; Tue, 31 Dec 2002 08:42:07 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23195 for ; Tue, 31 Dec 2002 08:34:17 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id gBVDbOW14482; Tue, 31 Dec 2002 07:37:24 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id gBVDbO514386; Tue, 31 Dec 2002 07:37:24 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 31 Dec 2002 07:37:24 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Paul Duffy'" , Ted Lemon Cc: Ralph Droms , Thomas Narten , dhcwg@ietf.org Subject: RE: [dhcwg] draft-ietf-dhc-packetcable-05.txt Date: Tue, 31 Dec 2002 07:36:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B0D1.3140D5C2" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2B0D1.3140D5C2 Content-Type: text/plain; charset="iso-8859-1" I think what this means is that instead of having IANA assign and register, IANA would only register. So, when the draft enters the RFC-Editor queue, IANA is contacted as it normally is and IANA would contact CableLabs which would assign the suboption. IANA then registers it. Is that correct? Seems OK by me if IANA is willing. This means CableLabs can start using the suboption as soon as the draft enters the RFC-Editor queue instead of having to await actual publication of the RFC. - Bernie -----Original Message----- From: Paul Duffy [mailto:paduffy@cisco.com] Sent: Monday, December 30, 2002 11:27 PM To: Ted Lemon Cc: Ralph Droms; Thomas Narten; dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-05.txt At 06:45 PM 12/30/2002 -0500, Ted Lemon wrote: >>Future proposed sub-options will be assigned a numeric code chosen by >>CableLabs immediately following IESG approval of the draft. > >What does "IETF approval of the draft" mean? If it means that the draft >has been adopted by the WG, sounds fine, but if it means that the draft >has passed the IESG review, then what's the point of the expert review? > Hi Ted, The point I am trying to get across is that the DHC WG, ADs, IESG, etc. approve the technical content/semantics of the sub-option, then Cablelabs would assign the sub-option code. I'm trying to balance CableLab's need for speed with IETF's review of the content of the sub-option. The expert review would be only for the choice of sub-option code assignment(?), not the actual technical content of the draft. So the order of events would be: 1. CCC sub-option draft submitted to DHC WG. 2. DHC WG, AD, IESG review/approve sub-option format and content. 3. Cablelabs assigns sub-option code. 4. IETF expert reviewer approves code assignment. 5a. Cablelabs compliant vendors start implementing sub-option for testing and shipment to customer. 5b. Draft is simultaneously submitted to RFC editor Q. If all goes well, field shipments can commence just about the time the RFC exits the editor Q. I'm grasping for a compromise here. Any suggestions? Cheers, -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2B0D1.3140D5C2 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] draft-ietf-dhc-packetcable-05.txt

I think what this means is that instead of having IANA assign and register, IANA would only
register. So, when the draft enters the RFC-Editor queue, IANA is contacted as it normally
is and IANA would contact CableLabs which would assign the suboption. IANA then registers it.

Is that correct? Seems OK by me if IANA is willing.

This means CableLabs can start using the suboption as soon as the draft enters the RFC-Editor
queue instead of having to await actual publication of the RFC.

- Bernie

-----Original Message-----
From: Paul Duffy [mailto:paduffy@cisco.com]
Sent: Monday, December 30, 2002 11:27 PM
To: Ted Lemon
Cc: Ralph Droms; Thomas Narten; dhcwg@ietf.org
Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-05.txt


At 06:45 PM 12/30/2002 -0500, Ted Lemon wrote:
>>Future proposed sub-options will be assigned a numeric code chosen by
>>CableLabs immediately following IESG approval of the draft.
>
>What does "IETF approval of the draft" mean?   If it means that the draft
>has been adopted by the WG, sounds fine, but if it means that the draft
>has passed the IESG review, then what's the point of the expert review?
>

Hi Ted,

The point I am trying to get across is that the DHC WG, ADs, IESG, etc.
approve the technical content/semantics of the sub-option, then Cablelabs
would assign the sub-option code.  I'm trying to balance CableLab's need
for speed with IETF's review of the content of the sub-option.  The expert
review would be only for the choice of sub-option code assignment(?), not
the actual technical content of the draft.

So the order of events would be:

1. CCC sub-option draft submitted to DHC WG.
2. DHC WG, AD, IESG review/approve sub-option format and content.
3. Cablelabs assigns sub-option code.
4. IETF expert reviewer approves code assignment.
5a. Cablelabs compliant vendors start implementing sub-option for testing
and shipment to customer.
5b. Draft is simultaneously submitted to RFC editor Q.

If all goes well, field shipments can commence just about the time the RFC
exits the editor Q.

I'm grasping for a compromise here.  Any suggestions?

Cheers,





--

Paul Duffy
Cisco Systems, Inc.
paduffy@cisco.com


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2B0D1.3140D5C2-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg