From dhcwg-bounces@ietf.org Fri Sep 02 18:50:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBKMm-0008NU-Cb; Fri, 02 Sep 2005 18:50:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBKMG-00088C-3A; Fri, 02 Sep 2005 18:50:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08607; Fri, 2 Sep 2005 18:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBKOT-000612-BP; Fri, 02 Sep 2005 18:52:21 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EBKMD-0001aK-Gw; Fri, 02 Sep 2005 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 02 Sep 2005 18:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-ddns-resolution-10.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --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 : Resolution of FQDN Conflicts among DHCP Clients Author(s) : M. Stapp, B. Volz Filename : draft-ietf-dhc-ddns-resolution-10.txt Pages : 15 Date : 2005-9-2 DHCP provides a mechanism for host configuration that includes dynamic assignment of IP addresses and fully qualified domain names. To maintain accurate name to IP address and IP address to name mappings in the DNS, these dynamically assigned addresses and fully qualified domain names require updates to the DNS. This document identifies situations in which conflicts in the use of fully qualified domain names may arise among DHCP clients and servers, and describes a strategy for the use of the DHCID DNS resource record in resolving those conflicts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-resolution-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ddns-resolution-10.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-ddns-resolution-10.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: <2005-9-2163422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-ddns-resolution-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-ddns-resolution-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-2163422.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Mon Sep 05 06:37:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECEMJ-0006ub-Uw; Mon, 05 Sep 2005 06:37:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECEMH-0006uT-Pp for dhcwg@megatron.ietf.org; Mon, 05 Sep 2005 06:37:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08954 for ; Mon, 5 Sep 2005 06:37:46 -0400 (EDT) Received: from relay-pt1.siemens.pt ([194.145.62.202] helo=relay2.siemens.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECEP1-0002S0-2K for dhcwg@ietf.org; Mon, 05 Sep 2005 06:40:40 -0400 Received: from fw-mta1.siemens.pt (fw-mta1.siemens.pt [141.29.156.201]) by relay2.siemens.pt (8.12.8/8.12.9) with ESMTP id j85ADof5015322 for ; Mon, 5 Sep 2005 11:13:51 +0100 Received: from lisi053a.siemens.pt (lisi053a.siemens.pt [141.29.156.193]) by fw-mta1.siemens.pt (Hvm) with ESMTP id j85ASSY23003 for ; Mon, 5 Sep 2005 11:28:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Sep 2005 11:36:58 +0100 Message-ID: <75A70F733E36B648A492A827EFA3B84095D91F@lisi053a.siemens.pt> Thread-Topic: IPv6 "Agent Circuit ID Sub-option" Thread-Index: AcWyBb59xZpj7DwjSQ6Nu7CiJj3hLg== From: "Tiago Camilo (Ext_PDM &FC, LDA.)" To: X-Spam-Score: 0.5 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [dhcwg] IPv6 "Agent Circuit ID Sub-option" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1973601542==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1973601542== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5B205.BDF4E110" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5B205.BDF4E110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I was reading the DHCPv6 RFC and the IDs with the DHCPv6 options, but I was unable to find a correspondence with the sub-option 82, from the DHCP (v4), "Agent Circuit ID Sub-option". Is this work in progress? Or you will not support it? Thanks, Tiago Camilo ------_=_NextPart_001_01C5B205.BDF4E110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IPv6 "Agent Circuit ID Sub-option"

Hi,
I was reading the = DHCPv6 RFC and the IDs with the DHCPv6 options, but I was unable to find = a correspondence with the sub-option 82, from the DHCP (v4), "Agent = Circuit ID Sub-option". Is this work in progress? Or you will not = support it?

Thanks,
Tiago = Camilo

------_=_NextPart_001_01C5B205.BDF4E110-- --===============1973601542== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1973601542==-- From dhcwg-bounces@ietf.org Mon Sep 05 09:15:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECGpF-0003mv-Gw; Mon, 05 Sep 2005 09:15:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECGpD-0003mq-BG for dhcwg@megatron.ietf.org; Mon, 05 Sep 2005 09:15:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15785 for ; Mon, 5 Sep 2005 09:15:49 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECGrz-0006Up-9k for dhcwg@ietf.org; Mon, 05 Sep 2005 09:18:43 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 05 Sep 2005 06:15:43 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j85DFZQM002821; Mon, 5 Sep 2005 06:15:35 -0700 (PDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Sep 2005 09:15:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dhcwg] IPv6 "Agent Circuit ID Sub-option" Date: Mon, 5 Sep 2005 09:15:36 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB218E183C@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] IPv6 "Agent Circuit ID Sub-option" Thread-Index: AcWyBb59xZpj7DwjSQ6Nu7CiJj3hLgAFge7g From: "Bernie Volz \(volz\)" To: "Tiago Camilo \(Ext_PDM &FC, LDA.\)" , X-OriginalArrivalTime: 05 Sep 2005 13:15:39.0125 (UTC) FILETIME=[E8E72250:01C5B21B] X-Spam-Score: 0.6 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0649339999==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0649339999== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5B21B.E8BD6A2A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5B21B.E8BD6A2A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See RFC 3315's Interface-Id option. This essentially is what the DHCPv4 Relay Agent Circuit ID Sub-Option was for. =20 - Bernie ________________________________ From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tiago Camilo (Ext_PDM &FC, LDA.) Sent: Monday, September 05, 2005 6:37 AM To: dhcwg@ietf.org Subject: [dhcwg] IPv6 "Agent Circuit ID Sub-option" =09 =09 Hi,=20 I was reading the DHCPv6 RFC and the IDs with the DHCPv6 options, but I was unable to find a correspondence with the sub-option 82, from the DHCP (v4), "Agent Circuit ID Sub-option". Is this work in progress? Or you will not support it? Thanks,=20 Tiago Camilo=20 ------_=_NextPart_001_01C5B21B.E8BD6A2A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IPv6 "Agent Circuit ID Sub-option"
See RFC 3315's Interface-Id option. This = essentially is=20 what the DHCPv4 Relay Agent Circuit ID Sub-Option was = for.
 
- Bernie

From: dhcwg-bounces@ietf.org=20 [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tiago Camilo = (Ext_PDM=20 &FC, LDA.)
Sent: Monday, September 05, 2005 6:37=20 AM
To: dhcwg@ietf.org
Subject: [dhcwg] IPv6 "Agent = Circuit=20 ID Sub-option"

Hi, =
I was reading the DHCPv6 RFC and = the IDs with=20 the DHCPv6 options, but I was unable to find a correspondence with the = sub-option 82, from the DHCP (v4), "Agent Circuit ID Sub-option". Is = this work=20 in progress? Or you will not support it?

Thanks, =
Tiago Camilo

------_=_NextPart_001_01C5B21B.E8BD6A2A-- --===============0649339999== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0649339999==-- From dhcwg-bounces@ietf.org Tue Sep 06 09:41:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECdhu-0001rL-1W; Tue, 06 Sep 2005 09:41:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECdht-0001rG-2n for dhcwg@megatron.ietf.org; Tue, 06 Sep 2005 09:41:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27567 for ; Tue, 6 Sep 2005 09:41:47 -0400 (EDT) Received: from enterprise58.opnet.com ([192.104.65.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECdkq-0005XU-IR for dhcwg@ietf.org; Tue, 06 Sep 2005 09:44:54 -0400 Received: from mpdomain (netscreen3020.opnet.com [172.16.1.39]) by enterprise58.opnet.com (8.12.10/8.12.10) with ESMTP id j86DdngV013804 for ; Tue, 6 Sep 2005 09:39:49 -0400 Message-ID: <004b01c5b2e9$177c8dd0$e80e10ac@opnet.com> From: "Kevin Purser" To: Date: Tue, 6 Sep 2005 09:44:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-OPNET-MailScanner: Found to be clean X-MailScanner-From: kpurser@opnet.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [dhcwg] stateless DHCP question X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hey folks, Quick question about stateless DHCPv6 that I couldn't seem to find in the drafts or mailing list: Section 5.1 of RFC 3736 states that the messages required for stateless DHCP are the Information-request and Reply messages. However, does the client first need to solicit a particular server with the Solicit message, or can it simply send the Information-request to the ALL_DHCP_Relay_Agents_and_Servers multicast address and accept the config returned by any server? Or is this up to the implementer? Thanks in advance! Kev _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 07 17:58:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED7w2-0005SG-U2; Wed, 07 Sep 2005 17:58:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED7w1-0005SB-78 for dhcwg@megatron.ietf.org; Wed, 07 Sep 2005 17:58:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24266 for ; Wed, 7 Sep 2005 17:58:22 -0400 (EDT) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED7zF-0005Xh-T2 for dhcwg@ietf.org; Wed, 07 Sep 2005 18:01:47 -0400 Received: from cacexg13.americas.cpqcorp.net (cacexg13.americas.cpqcorp.net [16.92.1.76]) by palrel11.hp.com (Postfix) with ESMTP id EA2C97010 for ; Wed, 7 Sep 2005 14:58:21 -0700 (PDT) Received: from cacexc06.americas.cpqcorp.net ([16.92.1.28]) by cacexg13.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Sep 2005 14:57:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Sep 2005 14:57:52 -0700 Message-ID: <00F4781551324E47A32BAF37B6E420B50282EB5D@cacexc06.americas.cpqcorp.net> Thread-Topic: FQDN internet drafts Thread-Index: AcWy/R7SP0nktM1YQMqBbqlCSPtNDQA+ZfDg From: "Borz, John (IPG-Roseville R&D)" To: X-OriginalArrivalTime: 07 Sep 2005 21:57:52.0897 (UTC) FILETIME=[321CCF10:01C5B3F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] FQDN internet drafts X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org =20 Hello, Looks like these internet drafts have expired. Are there plans to update them? http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-10.txt http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-fqdn-02.txt thanks, John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 08 08:24:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDLSO-0003tc-CI; Thu, 08 Sep 2005 08:24:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDLSN-0003tR-0N for dhcwg@megatron.ietf.org; Thu, 08 Sep 2005 08:24:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15972 for ; Thu, 8 Sep 2005 08:24:41 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDLVh-00026I-Er for dhcwg@ietf.org; Thu, 08 Sep 2005 08:28:12 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 08 Sep 2005 05:24:31 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j88CNt5K019649; Thu, 8 Sep 2005 05:24:26 -0700 (PDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Sep 2005 08:24:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Sep 2005 08:23:51 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21947BE4@xmb-rtp-20a.amer.cisco.com> Thread-Topic: draft-ietf-dhc-ddns-resolution-10.txt Thread-Index: AcW0cCudp1a9SakwREesFf0NFmPc5A== From: "Bernie Volz \(volz\)" To: "Ralph Droms \(rdroms\)" , "Stig Venaas" X-OriginalArrivalTime: 08 Sep 2005 12:24:13.0931 (UTC) FILETIME=[393923B0:01C5B470] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org Subject: [dhcwg] draft-ietf-dhc-ddns-resolution-10.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ralph/Stig: =20 Do we need another last call on draft-ietf-dhc-ddns-resolution-10.txt? Or can we advance this to the IESG so that the entire package of FQDN related drafts can finally move forward? =20 - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 12 05:07:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEkI6-0000de-GV; Mon, 12 Sep 2005 05:07:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEkI3-0000cq-F8 for dhcwg@megatron.ietf.org; Mon, 12 Sep 2005 05:07:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05649 for ; Mon, 12 Sep 2005 05:07:39 -0400 (EDT) Received: from xproxy.gmail.com ([66.249.82.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEkM2-0005Ha-K8 for dhcwg@ietf.org; Mon, 12 Sep 2005 05:11:59 -0400 Received: by xproxy.gmail.com with SMTP id i31so2343282wxd for ; Mon, 12 Sep 2005 02:07:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=t515hSwchhJ4NLc0bSC17ODWE/AwafgoAHmPb6hTxb+FTTGjk+WkdzlhXQLbcy6dbZqVdj5khR0j30VgY1guPqwHXFKIzS8oaAt0BVba1DKR6pN1iConJvwydqucxBAXcrcUa7gVVZWcn75aPEAU9zfYa7i4Tz0180l/c3xDSPs= Received: by 10.70.110.1 with SMTP id i1mr106537wxc; Mon, 12 Sep 2005 02:07:30 -0700 (PDT) Received: by 10.70.116.16 with HTTP; Mon, 12 Sep 2005 02:07:30 -0700 (PDT) Message-ID: <71b311480509120207301ce1b1@mail.gmail.com> Date: Mon, 12 Sep 2005 17:07:30 +0800 From: Yin LU To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.9 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] [NEED Help] How to assign an block of addresses to the requesting router via DHCPv4 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lu.yin.2004@gmail.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi, Is there someone kindly enough to tell me some clues about assignning an block of addresses (or a subnet) to the router via DHCPv4, just like the way of Prefix Delegatinon Options in DHCPv6? It seems that I failed to find something about this function in DHCPv4 RFC.Any suggestion would be greatly appreciated. LU Yin Nanjing University China _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 12 07:54:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEmtN-0006Hh-II; Mon, 12 Sep 2005 07:54:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEmtL-0006Hc-Li for dhcwg@megatron.ietf.org; Mon, 12 Sep 2005 07:54:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12794 for ; Mon, 12 Sep 2005 07:54:30 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEmxW-0000uL-Iy for dhcwg@ietf.org; Mon, 12 Sep 2005 07:58:51 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Sep 2005 04:54:20 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,99,1125903600"; d="scan'208"; a="9307197:sNHT19835576" Received: from [68.50.138.194] (che-vpn-cluster-1-121.cisco.com [10.86.240.121]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8CBsHQl025317; Mon, 12 Sep 2005 07:54:18 -0400 (EDT) In-Reply-To: <71b311480509120207301ce1b1@mail.gmail.com> References: <71b311480509120207301ce1b1@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8d5c694cf6dc4776915eb19a9f296029@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [dhcwg] [NEED Help] How to assign an block of addresses to the requesting router via DHCPv4 Date: Mon, 12 Sep 2005 07:54:12 -0400 To: lu.yin.2004@gmail.com X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I suspect what you are looking for is draft-ietf-dhc-subnet-alloc-03.txt John On Sep 12, 2005, at 5:07 AM, Yin LU wrote: > > Is there someone kindly enough to tell me some clues about assignning > an block of addresses (or a subnet) to the router via DHCPv4, just > like the way of Prefix Delegatinon Options in DHCPv6? It seems that I > failed to find something about this function in DHCPv4 RFC. Any > suggestion would be greatly appreciated. > > LU Yin > Nanjing University > China _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 12 08:35:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEnXA-0004t4-9K; Mon, 12 Sep 2005 08:35:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEnX5-0004sT-2m for dhcwg@megatron.ietf.org; Mon, 12 Sep 2005 08:35:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14960 for ; Mon, 12 Sep 2005 08:35:26 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEnb8-00026d-4C for dhcwg@ietf.org; Mon, 12 Sep 2005 08:39:47 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 12 Sep 2005 05:35:17 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8CCYaKc015323; Mon, 12 Sep 2005 05:35:14 -0700 (PDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Sep 2005 08:34:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] [NEED Help] How to assign an block of addresses to therequesting router via DHCPv4 Date: Mon, 12 Sep 2005 08:34:21 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21948366@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] [NEED Help] How to assign an block of addresses to therequesting router via DHCPv4 Thread-Index: AcW3esqZCxmG7xgcTqq3CA1v0hd+FgAG392g From: "Bernie Volz \(volz\)" To: , X-OriginalArrivalTime: 12 Sep 2005 12:34:21.0856 (UTC) FILETIME=[4D3A2200:01C5B796] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org See http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-alloc-03.txt.=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Yin LU > Sent: Monday, September 12, 2005 5:08 AM > To: dhcwg@ietf.org > Subject: [dhcwg] [NEED Help] How to assign an block of=20 > addresses to therequesting router via DHCPv4 >=20 > Hi, >=20 > Is there someone kindly enough to tell me some clues about assignning > an block of addresses (or a subnet) to the router via DHCPv4, just > like the way of Prefix Delegatinon Options in DHCPv6? It seems that I > failed to find something about this function in DHCPv4 RFC.Any > suggestion would be greatly appreciated. >=20 > LU Yin > Nanjing University > China >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 12 13:14:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EErsv-0000ji-KT; Mon, 12 Sep 2005 13:14:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EErst-0000jU-Mx for dhcwg@megatron.ietf.org; Mon, 12 Sep 2005 13:14:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02796 for ; Mon, 12 Sep 2005 13:14:21 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EErx7-0002II-8L for dhcwg@ietf.org; Mon, 12 Sep 2005 13:18:46 -0400 Received: by rproxy.gmail.com with SMTP id i8so371645rne for ; Mon, 12 Sep 2005 10:14:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BW0z92AY4/DYT6Jkc9LKsY/mR51nLQ/pOT5/MqXJ+TH2lAJkl9w5wo1/AVIuCOC0Wh+NhHy8xjgr936ufQltXynGNEYeKiQ0Yp9ANkrmopc2pvI2VNiMT3/y0wPbjxOQAf67LRuTAHMkOBOCzYcN31270p4bz89lDmsR/RfkbrM= Received: by 10.39.2.22 with SMTP id e22mr340577rni; Mon, 12 Sep 2005 10:14:19 -0700 (PDT) Received: by 10.70.116.16 with HTTP; Mon, 12 Sep 2005 10:13:49 -0700 (PDT) Message-ID: <71b311480509121013429cd6ab@mail.gmail.com> Date: Mon, 12 Sep 2005 10:13:49 -0700 From: Yin LU To: "Bernie Volz (volz)" Subject: Re: [dhcwg] [NEED Help] How to assign an block of addresses to therequesting router via DHCPv4 In-Reply-To: <8E296595B6471A4689555D5D725EBB21948366@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <8E296595B6471A4689555D5D725EBB21948366@xmb-rtp-20a.amer.cisco.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lu.yin.2004@gmail.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Thank you all! Your suggestions would be very helpful.=20 But I think the very thing I wanna find is how to get several individual addresses, instead of continuous addresses in an assigned subnet, in a single session (say, 2 roundtrips typically) between the router and the server via DHCPv4. Subnet Delegation may be not very flexible after all, especially in the small-scale remoting access scenario. Is there any extended options will do? 2005/9/12, Bernie Volz (volz) : > See > http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-alloc-03.txt. >=20 > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > > On Behalf Of Yin LU > > Sent: Monday, September 12, 2005 5:08 AM > > To: dhcwg@ietf.org > > Subject: [dhcwg] [NEED Help] How to assign an block of > > addresses to therequesting router via DHCPv4 > > > > Hi, > > > > Is there someone kindly enough to tell me some clues about assignning > > an block of addresses (or a subnet) to the router via DHCPv4, just > > like the way of Prefix Delegatinon Options in DHCPv6? It seems that I > > failed to find something about this function in DHCPv4 RFC.Any > > suggestion would be greatly appreciated. > > > > LU Yin > > Nanjing University > > China > > > > _______________________________________________ > > 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-bounces@ietf.org Mon Sep 12 13:17:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EErvk-0000z8-UD; Mon, 12 Sep 2005 13:17:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EErvj-0000yj-T9 for dhcwg@megatron.ietf.org; Mon, 12 Sep 2005 13:17:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02894 for ; Mon, 12 Sep 2005 13:17:17 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EErzx-0002MP-Hy for dhcwg@ietf.org; Mon, 12 Sep 2005 13:21:42 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Sep 2005 10:17:10 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,101,1125903600"; d="scan'208"; a="9358456:sNHT23015120" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8CHGgRB019346; Mon, 12 Sep 2005 13:17:07 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Sep 2005 13:16:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] [NEED Help] How to assign an block of addresses to therequesting router via DHCPv4 Date: Mon, 12 Sep 2005 13:16:55 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB219484ED@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] [NEED Help] How to assign an block of addresses to therequesting router via DHCPv4 Thread-Index: AcW3vYLWs4mUyqjcSJyHSwJIdg39zwAADS4A From: "Bernie Volz \(volz\)" To: X-OriginalArrivalTime: 12 Sep 2005 17:16:55.0970 (UTC) FILETIME=[C6AAA020:01C5B7BD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org You can't do this with DHCPv4. You can get multiple addresses, but you'll need to use a unique client identifier for each address. - Bernie=20 > -----Original Message----- > From: Yin LU [mailto:lu.yin.2004@gmail.com]=20 > Sent: Monday, September 12, 2005 1:14 PM > To: Bernie Volz (volz) > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] [NEED Help] How to assign an block of=20 > addresses to therequesting router via DHCPv4 >=20 > Thank you all! Your suggestions would be very helpful.=20 >=20 > But I think the very thing I wanna find is how to get several > individual addresses, instead of continuous addresses in an assigned > subnet, in a single session (say, 2 roundtrips typically) between the > router and the server via DHCPv4. >=20 > Subnet Delegation may be not very flexible after all, especially in > the small-scale remoting access scenario. Is there any extended > options will do? >=20 >=20 > 2005/9/12, Bernie Volz (volz) : > > See > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-allo c-03.txt. > >=20 > > > -----Original Message----- > > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > > > On Behalf Of Yin LU > > > Sent: Monday, September 12, 2005 5:08 AM > > > To: dhcwg@ietf.org > > > Subject: [dhcwg] [NEED Help] How to assign an block of > > > addresses to therequesting router via DHCPv4 > > > > > > Hi, > > > > > > Is there someone kindly enough to tell me some clues=20 > about assignning > > > an block of addresses (or a subnet) to the router via DHCPv4, just > > > like the way of Prefix Delegatinon Options in DHCPv6? It=20 > seems that I > > > failed to find something about this function in DHCPv4 RFC.Any > > > suggestion would be greatly appreciated. > > > > > > LU Yin > > > Nanjing University > > > China > > > > > > _______________________________________________ > > > dhcwg mailing list > > > dhcwg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 12 13:31:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEs9T-0003q5-AR; Mon, 12 Sep 2005 13:31:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEs9R-0003pt-Uu for dhcwg@megatron.ietf.org; Mon, 12 Sep 2005 13:31:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03524 for ; Mon, 12 Sep 2005 13:31:17 -0400 (EDT) Received: from xproxy.gmail.com ([66.249.82.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEsDU-0002j4-JJ for dhcwg@ietf.org; Mon, 12 Sep 2005 13:35:42 -0400 Received: by xproxy.gmail.com with SMTP id i31so2459742wxd for ; Mon, 12 Sep 2005 10:31:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Nz3hmOniUelu3xI6CkA4Cvau2a/hZd49TjczIdWmxn2pIZjTMevjarajp0xt68sDx8cSCJQkRBSAqjDVkalAIy2XdBgqq7XCyQfzG2pYGEBygUHJyvI2pips9soxX1lxH6W1AZs+3Uzpz2yQnXQXomrSeFuGTz5rP8buYFSm0kA= Received: by 10.70.110.1 with SMTP id i1mr1174wxc; Mon, 12 Sep 2005 10:31:08 -0700 (PDT) Received: by 10.70.116.16 with HTTP; Mon, 12 Sep 2005 10:31:08 -0700 (PDT) Message-ID: <71b31148050912103155da483a@mail.gmail.com> Date: Mon, 12 Sep 2005 10:31:08 -0700 From: Yin LU To: "Bernie Volz (volz)" Subject: Re: [dhcwg] [NEED Help] How to assign an block of addresses to therequesting router via DHCPv4 In-Reply-To: <8E296595B6471A4689555D5D725EBB219484ED@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <8E296595B6471A4689555D5D725EBB219484ED@xmb-rtp-20a.amer.cisco.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lu.yin.2004@gmail.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org That's to say, I could only get one address per requesting session via DHCPv4, and I should use client identifier option to tell the server how to distinguish the binding relationships between the multi-requests, isn't it? 2005/9/12, Bernie Volz (volz) : > You can't do this with DHCPv4. >=20 > You can get multiple addresses, but you'll need to use a unique client > identifier for each address. >=20 > - Bernie >=20 > > -----Original Message----- > > From: Yin LU [mailto:lu.yin.2004@gmail.com] > > Sent: Monday, September 12, 2005 1:14 PM > > To: Bernie Volz (volz) > > Cc: dhcwg@ietf.org > > Subject: Re: [dhcwg] [NEED Help] How to assign an block of > > addresses to therequesting router via DHCPv4 > > > > Thank you all! Your suggestions would be very helpful. > > > > But I think the very thing I wanna find is how to get several > > individual addresses, instead of continuous addresses in an assigned > > subnet, in a single session (say, 2 roundtrips typically) between the > > router and the server via DHCPv4. > > > > Subnet Delegation may be not very flexible after all, especially in > > the small-scale remoting access scenario. Is there any extended > > options will do? > > > > > > 2005/9/12, Bernie Volz (volz) : > > > See > > > > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-allo > c-03.txt. > > > > > > > -----Original Message----- > > > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > > > > On Behalf Of Yin LU > > > > Sent: Monday, September 12, 2005 5:08 AM > > > > To: dhcwg@ietf.org > > > > Subject: [dhcwg] [NEED Help] How to assign an block of > > > > addresses to therequesting router via DHCPv4 > > > > > > > > Hi, > > > > > > > > Is there someone kindly enough to tell me some clues > > about assignning > > > > an block of addresses (or a subnet) to the router via DHCPv4, just > > > > like the way of Prefix Delegatinon Options in DHCPv6? It > > seems that I > > > > failed to find something about this function in DHCPv4 RFC.Any > > > > suggestion would be greatly appreciated. > > > > > > > > LU Yin > > > > Nanjing University > > > > China > > > > > > > > _______________________________________________ > > > > 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-bounces@ietf.org Mon Sep 12 13:38:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEsFv-00057H-Pc; Mon, 12 Sep 2005 13:38:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEsFr-00056Y-1T for dhcwg@megatron.ietf.org; Mon, 12 Sep 2005 13:38:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04008 for ; Mon, 12 Sep 2005 13:37:58 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEsJw-0002yZ-Qy for dhcwg@ietf.org; Mon, 12 Sep 2005 13:42:22 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 12 Sep 2005 10:37:49 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,101,1125903600"; d="scan'208"; a="9361926:sNHT22895316" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8CHb9Ta020730; Mon, 12 Sep 2005 13:37:46 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Sep 2005 13:37:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] [NEED Help] How to assign an block of addresses to therequesting router via DHCPv4 Date: Mon, 12 Sep 2005 13:37:40 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21948501@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] [NEED Help] How to assign an block of addresses to therequesting router via DHCPv4 Thread-Index: AcW3v89WWBuhamMFS8+dNfiwO9frZwAANpEQ From: "Bernie Volz \(volz\)" To: X-OriginalArrivalTime: 12 Sep 2005 17:37:40.0916 (UTC) FILETIME=[ACB64F40:01C5B7C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Yes, that's it.=20 > -----Original Message----- > From: Yin LU [mailto:lu.yin.2004@gmail.com]=20 > Sent: Monday, September 12, 2005 1:31 PM > To: Bernie Volz (volz) > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] [NEED Help] How to assign an block of=20 > addresses to therequesting router via DHCPv4 >=20 > That's to say, I could only get one address per requesting session via > DHCPv4, and I should use client identifier option to tell the server > how to distinguish the binding relationships between the > multi-requests, isn't it? >=20 > 2005/9/12, Bernie Volz (volz) : > > You can't do this with DHCPv4. > >=20 > > You can get multiple addresses, but you'll need to use a=20 > unique client > > identifier for each address. > >=20 > > - Bernie > >=20 > > > -----Original Message----- > > > From: Yin LU [mailto:lu.yin.2004@gmail.com] > > > Sent: Monday, September 12, 2005 1:14 PM > > > To: Bernie Volz (volz) > > > Cc: dhcwg@ietf.org > > > Subject: Re: [dhcwg] [NEED Help] How to assign an block of > > > addresses to therequesting router via DHCPv4 > > > > > > Thank you all! Your suggestions would be very helpful. > > > > > > But I think the very thing I wanna find is how to get several > > > individual addresses, instead of continuous addresses in=20 > an assigned > > > subnet, in a single session (say, 2 roundtrips typically)=20 > between the > > > router and the server via DHCPv4. > > > > > > Subnet Delegation may be not very flexible after all,=20 > especially in > > > the small-scale remoting access scenario. Is there any extended > > > options will do? > > > > > > > > > 2005/9/12, Bernie Volz (volz) : > > > > See > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-allo > > c-03.txt. > > > > > > > > > -----Original Message----- > > > > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > > > > > On Behalf Of Yin LU > > > > > Sent: Monday, September 12, 2005 5:08 AM > > > > > To: dhcwg@ietf.org > > > > > Subject: [dhcwg] [NEED Help] How to assign an block of > > > > > addresses to therequesting router via DHCPv4 > > > > > > > > > > Hi, > > > > > > > > > > Is there someone kindly enough to tell me some clues > > > about assignning > > > > > an block of addresses (or a subnet) to the router via=20 > DHCPv4, just > > > > > like the way of Prefix Delegatinon Options in DHCPv6? It > > > seems that I > > > > > failed to find something about this function in DHCPv4 RFC.Any > > > > > suggestion would be greatly appreciated. > > > > > > > > > > LU Yin > > > > > Nanjing University > > > > > China > > > > > > > > > > _______________________________________________ > > > > > dhcwg mailing list > > > > > dhcwg@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > > > > > > > > > >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 12 13:42:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEsKE-0005yo-3k; Mon, 12 Sep 2005 13:42:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEsKD-0005yS-EA for dhcwg@megatron.ietf.org; Mon, 12 Sep 2005 13:42:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04276 for ; Mon, 12 Sep 2005 13:42:26 -0400 (EDT) Received: from xproxy.gmail.com ([66.249.82.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEsOE-0003GB-U1 for dhcwg@ietf.org; Mon, 12 Sep 2005 13:46:50 -0400 Received: by xproxy.gmail.com with SMTP id i31so2462765wxd for ; Mon, 12 Sep 2005 10:42:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qDXdvVI1whIhqQ19tFvbMwj9MUBSXswRvGKp+p75rDVUDYqr5EWWQEr6k3v2LI6f/fR7HcKUvXKB1Hfd/zJR6XJ2Bj04kcI/oqzUOcdoP1WNNANCQVK7iOVT6ONN5p9mK79qq768CzSwj3b3P4OhV2DGf45z4p5msDXZeLFXSck= Received: by 10.70.76.12 with SMTP id y12mr1508wxa; Mon, 12 Sep 2005 10:42:14 -0700 (PDT) Received: by 10.70.116.16 with HTTP; Mon, 12 Sep 2005 10:42:14 -0700 (PDT) Message-ID: <71b3114805091210426a68c320@mail.gmail.com> Date: Mon, 12 Sep 2005 10:42:14 -0700 From: Yin LU To: "Bernie Volz (volz)" Subject: Re: [dhcwg] [NEED Help] How to assign an block of addresses to therequesting router via DHCPv4 In-Reply-To: <8E296595B6471A4689555D5D725EBB21948501@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <8E296595B6471A4689555D5D725EBB21948501@xmb-rtp-20a.amer.cisco.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lu.yin.2004@gmail.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Your comments help me a lot. Thank you very much! LU Yin 2005/9/12, Bernie Volz (volz) : > Yes, that's it. >=20 > > -----Original Message----- > > From: Yin LU [mailto:lu.yin.2004@gmail.com] > > Sent: Monday, September 12, 2005 1:31 PM > > To: Bernie Volz (volz) > > Cc: dhcwg@ietf.org > > Subject: Re: [dhcwg] [NEED Help] How to assign an block of > > addresses to therequesting router via DHCPv4 > > > > That's to say, I could only get one address per requesting session via > > DHCPv4, and I should use client identifier option to tell the server > > how to distinguish the binding relationships between the > > multi-requests, isn't it? > > > > 2005/9/12, Bernie Volz (volz) : > > > You can't do this with DHCPv4. > > > > > > You can get multiple addresses, but you'll need to use a > > unique client > > > identifier for each address. > > > > > > - Bernie > > > > > > > -----Original Message----- > > > > From: Yin LU [mailto:lu.yin.2004@gmail.com] > > > > Sent: Monday, September 12, 2005 1:14 PM > > > > To: Bernie Volz (volz) > > > > Cc: dhcwg@ietf.org > > > > Subject: Re: [dhcwg] [NEED Help] How to assign an block of > > > > addresses to therequesting router via DHCPv4 > > > > > > > > Thank you all! Your suggestions would be very helpful. > > > > > > > > But I think the very thing I wanna find is how to get several > > > > individual addresses, instead of continuous addresses in > > an assigned > > > > subnet, in a single session (say, 2 roundtrips typically) > > between the > > > > router and the server via DHCPv4. > > > > > > > > Subnet Delegation may be not very flexible after all, > > especially in > > > > the small-scale remoting access scenario. Is there any extended > > > > options will do? > > > > > > > > > > > > 2005/9/12, Bernie Volz (volz) : > > > > > See > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-allo > > > c-03.txt. > > > > > > > > > > > -----Original Message----- > > > > > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > > > > > > On Behalf Of Yin LU > > > > > > Sent: Monday, September 12, 2005 5:08 AM > > > > > > To: dhcwg@ietf.org > > > > > > Subject: [dhcwg] [NEED Help] How to assign an block of > > > > > > addresses to therequesting router via DHCPv4 > > > > > > > > > > > > Hi, > > > > > > > > > > > > Is there someone kindly enough to tell me some clues > > > > about assignning > > > > > > an block of addresses (or a subnet) to the router via > > DHCPv4, just > > > > > > like the way of Prefix Delegatinon Options in DHCPv6? It > > > > seems that I > > > > > > failed to find something about this function in DHCPv4 RFC.Any > > > > > > suggestion would be greatly appreciated. > > > > > > > > > > > > LU Yin > > > > > > Nanjing University > > > > > > China > > > > > > > > > > > > _______________________________________________ > > > > > > 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-bounces@ietf.org Mon Sep 12 15:03:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEta8-0004Qb-OF; Mon, 12 Sep 2005 15:03:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEta6-0004Po-Of for dhcwg@megatron.ietf.org; Mon, 12 Sep 2005 15:03:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08013 for ; Mon, 12 Sep 2005 15:02:55 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEteB-0005ln-AF for dhcwg@ietf.org; Mon, 12 Sep 2005 15:07:20 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j8CJ2nhi000856 for ; Mon, 12 Sep 2005 21:02:49 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j8CJ2mw3004977 for ; Mon, 12 Sep 2005 21:02:49 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j8CJ2m7F004976 for dhcwg@ietf.org; Mon, 12 Sep 2005 21:02:48 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 12 Sep 2005 21:02:48 +0200 From: Stig Venaas To: dhcwg@ietf.org Message-ID: <20050912190248.GA4793@storhaugen.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Subject: [dhcwg] Fwd: Gen-Art Review: draft-ietf-dhc-bcmc-options-02 (and 01) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Here is Elwyn's review. Much of this has been addressed. There are a number of questions that are not necessarily issues. It does discuss multiple fqdns which is one of the outstanding issues to be discussed. Stig ----- Forwarded message from Elwyn Davies ----- Date: Fri, 01 Jul 2005 15:19:46 +0100 From: Elwyn Davies Subject: Gen-Art Review: draft-ietf-dhc-bcmc-options-02 (and 01) [...] Background for those on the CC list, who may be unaware of GenART: GenART is the Area Review Team for the General Area of the IETF. We advise the General Area Director (i.e. the IETF/IESG chair) by providing more in depth reviews than he could do himself of documents that come up for final decision in IESG telechat. I was selected as the GenART member to review this document. Below is my review, which was written specifically with an eye to the GenART process, but since I believe that it will be useful to have these comments more widely distributed, others outside the GenART group are being copied. [Note: I produced a review of version -01 for the IETF last call. I had just finished this and was about to submit it on a just-in-time basis for the end of last call ;-), when I gathered that a new version -02 has been produced and is on the IESG agenda for 7 July 2005. So the main review was of v01: I have added some notes about v02. Essentially my conclusions are unchanged, but the details are a little different, in that some problems have been fixed but the fixes have introduced some new problems, and not all the old problems were fixed.] Document: draft-ietf-dhc-bcmc-options-02.txt Intended Status: Proposed Standard Shepherding AD: Margaret Wasserman Review Trigger: IESG Telechat 7/7/05 Summary for version -02: This document is certainly not ready for publication. Indeed it may (still) be fundamentally flawed: Two questions need to be answered regarding the new version: - My question to v01, as to whether this is fundamentally flawed, remains on the table (Does it need multiple domain names or can it just use multiple SRV records for the one wireless access domain - in which case do we really need DHCP(v6) options at all?).. the authors need to explain why multiple domain names are needed because I couldn't tell from the BCSMS document and the wording seems to imply one domain would be enough. - As a result of the update, 2 DHCP code points are needed: Is there enough DHCP option space available for this request to get 2 code points, rather than the one which was RFC3361 got? Detailed review for v02: The editorial state of the document (apart from s5) is much improved after Margaret Wasserman's review. The majority of my comments are substantive, and so I didn't separate out the few editorial nits. s1: The acronyms 3GPP, 3GPP2 and OMA need expansion. Abstract/s1/s2: These sections imply that the options have wider application than the main focus which is 3GPP2. Whilst it is true that 3GPP is also considering broadcast services, I can find no evidence that either 3GPP or OMA are actively considering the use of DHCP options as part of their configuration process. Maybe the implications of wider applicability need to be toned down a little. [S4.1/4.3 etc: Clearly the 'enc' problem and the compression problems idwentified for v01 have gone away as the document now stands.] s4.1: The example at the end of 4.1 is now differently broken: the length byte for the second 'example' component is at the end of the structure rather than between the 0 for the end of the first domain name and the 'e' for the start of example. s4.1/4.2: ' Use of multiple domain names is not meant to replace the SRV records, but rather to allow a single DHCP/DHCPv6 server to indicate the broadcast controllers in the access provider's network.' This sentence has been adapted from a similar sentence in RFC3319 and RFC3361 - 'Use of multiple domain names is not meant to replace NAPTR and SRV records, but rather to allow a single DHCP server to indicate outbound proxy servers operated by multiple providers.' I am unclear about why multiple domain names would be needed for '*the* access provider's network'. This needs better explanation - and if it can't be provided then maybe this work is not needed at all: multiple SRV records would provide all that is needed perhaps. s4.5/4.6: Now that there are two separate options for IPv4, all the stuff in 4.5 and 4.6 which just talks about v6 needs to be duplicated for v4. s4.6: A reference to s3.1 or RFC1035 might also help regarding encoding of domain names and comparisons. s5: At least: s/applies/apply/, s/spec/specification/, s/in-transist/in transit/, s/&/and/ Personally I would redraft this section: This document does not introduce any new security concerns beyond those specified in the basic DHCP [RFC2131] and DHCPv6 [RFC3315] specifications. In the absence of message integrity protection for these options, an attacker could modify the option values to frustrate or divert requests for broadcast service. =============================================== Document: draft-ietf-dhc-bcmc-options-01.txt Intended Status: Proposed Standard Review Trigger: IETF Last Call, ending 30/6/05 Summary for v01: This document is not ready for publication or submission to the IESG: It may possibly be fundamentally flawed! The draft proposes to define two options each for DHCP and DHCPv6. The options and formats, I discovered after a little ferreting, are essentially the same as those defined in RFC 3361 and RFC3319 which define options to specify FQDNs or IP addresses for SIP servers. This is clearly a good idea since the idea is to provide FQDNs or IP addresses for locating 3GPP2 broadcast servers. The possibly fundamental point is that I really do not understand why the options need to allow for multiple domain names at all! The document talks about controllers in 'the wireless access provider's [singular - my comment] network' - it needs to be explained why multiple domain names are needed: the specifications which were used to provide the layouts talk about accesing SIP proxies in multiple providers, but here we are talking about a single provider network apparently. I may have misunderstood what is going on, but I think better explanation is needed: if in fact we are just talking about multiple controllers in one domain then surely all that are needed are multiple SRV records?? [These next two paragraphs have been fixed in v02] Assuming that multiple domain names are actually needed, there are still some problems: Unfortunately, in copying particularly from RFC3361, it appears that the authors have not fully grasped what was going on, i.e. that in order to save on DHCP option numbers (which are a relatively scarce resource) the two possible encodings of the server locations (FQDN, IP Address) are selected by an 'enc' byte in a single option type. This draft propagates the 'enc' bit idea but doesn't explain it properly and then asks for two separate DHCP option numbers from IANA. Also the domain name example for DHCP omits the enc byte altogether! It also appears that the implementation of Margaret Wasserman's AD comments on v00 of the draft has actually broken the proposal. Margaret commented that it was not terribly sensible specifying a MUST implement for a compression facility for FQDNs (in the DHCP IPv4 case) that was then explicitly stated to offer little real prospect of saving space (in the particular circumstances of this option). However, the change that has been drafted, states that the *client* MAY implement the compression option. I would assume that the MAY should apply to the server - the client MUST continue to support it if there is a chance that the server MAY unless some sort of option negotiation is specified. Also, there is a degree of uncertainty (inherited from RFC3319) as to whether the IPv6 case also allows for RFC1035 compression. Another revision is needed to sort out these problems before the draft proceeds to the IESG. Detailed Review: ============ The editorial state of the document (apart from s5) is much improved after Margaret Wasserman's review. The majority of my comments are substantive, and so I didn't separate out the few editorial nits. s1: The acronyms 3GPP, 3GPP2 and OMA need expansion. Abstract/s1/s2: These sections imply that the options have wider application than the main focus which is 3GPP2. Whilst it is true that 3GPP is also considering broadcast services, I can find no evidence that either 3GPP or OMA are actively considering the use of DHCP options as part of their configuration process. Maybe the implications of wider applicability need to be toned down a little. s4: The basic layout for the options and significant amounts of descriptive text have been lifted from the corresponding work for specifying SIP server locations in RFC3361 (for IPv4) and RFC3319 (for IPv6). This is entirely sensible since the aims are largely similar. Indeed I did at one point wonder if a whole lot of text could be saved by just referencing these RFCs and giving new names and codepoints, but there are a few differences which make it slightly awkquard, and it would create an inappropraite dependency. Unfortunately the 'lifting' has not worked as well as it ought, particularly in respect of IPv4. s4.1/4.3/6: In RFC3361, it is implicitly acknowledged (and RFC3319 states that IPv6 doesn't have the same problem) that DHCP option code points are now a scarce resource. In order to minimise the number of new code points requested, RFC3361 includes an 'enc' byte in a single option to distinguish the case where the servers are located by FQDNs from the case of IP addresses. This draft perpetuates the use of the enc byte but does not explain why it is used and then compounds the problem by asking for two DHCP option numbers in s6, and not linking the the specifications of the two options in s4. This needs fixing up, presumably by *really* duplicating what is defined in RFC3361. s4.1: The example encoding at the end of the section doesn't match the specification - the 'enc' byte is missing!!! s4.1: As mentioned in Magaret Wasserman's AD review, requiring support of a compression capability (from RFC1035) that is unlikely to actually provide any reduction in data volume seems a little silly. Unfortunately the fix that has been applied between v00 and v01 of this draft is broken. The MAY needs to apply to the server side which will be generating the option field. If compression is available and not negotiated, the client side MUST support it. The compression business has been propagated from RFC3361 where it is a required feature, although again it is acknowledged that it is unlikely to provide much saving. [Presumably there was some idea in the minds of the authors that allowing compression might allow code to be used unchanged from DNS servers.] I would suggest that this draft should be changed as follows (see also next comment): - for s4.1: Do not say anything about clients or servers. Just specify that RFC1035 compression MAY be used in the list of domain names. (or alternatively say that it MUST NOT be used) - for s4.5: If RFC1035 compression is allowed at all, say clients MUST support it. - for s4.6: If RFC1035 compression is allowed at all, say servers MAY support it. s4.2: As with RFC3319, the use of RFC1035 compression is not mentioned one way or the other for the DHCPv6 case. Presumably the implication for RFC3319 is that compression MUST NOT be used, since s3.1 of RFC1035 doesn't talk about compression. Since RFC1035 compression is mentioned in this draft for IPv4, it should be made absolutely clear whether it is or is not available for IPv6. Overall, IMO it would appear sensible to just drop the idea of compression from both DHCP and DHCPv6! s4.1/s4.2: The common text about using the domain names to do SRV lookups, etc would be better placed in the client considerations section (or maybe a separate section on the interpretation of multiple domain names). s4.1/4.2: ' Use of multiple domain names is not meant to replace the SRV records, but rather to allow a single DHCP/DHCPv6 server to indicate the broadcast controllers in the access provider's network.' This sentence has been adapted from a similar sentence in RFC3319 and RFC3361 - 'Use of multiple domain names is not meant to replace NAPTR and SRV records, but rather to allow a single DHCP server to indicate outbound proxy servers operated by multiple providers.' I am unclear about why multiple domain names would be needed for '*the* access provider's network'. This needs better explanation - and if it can't be provided then maybe this work is not needed at all: multiple SRV records would provide all that is needed perhaps. s4.2: s/Boradcast/Broadcast/ s4.4: Since s4.2 specifies constraints on the length of the DHCP option, it would be appropriate to specify similar constraints for the DHCPv6 option (ie. at least one address, multiples of 16 plus base). s4.5/s4.6: (knock on from the mix up over one or two DHCP options): Nothing is said here about how servers and clients handle the two different DHCP cases: The text from the last paragraph of s3 of RFC3319 needs to be reproduced in this document, assuming the intention is to ask for one DHCP option. If two DHCP options are asked for the text for DHCPv6 needs to be expanded to cover the DHCP case as well. s5: At least: s/applies/apply/, s/spec/specification/, s/in-transist/in transit/ Personally I would redraft this section: This document does not introduce any new security concerns beyond those specified in the basic DHCP [RFC2131] and DHCPv6 [RFC3315] specifications. In the absence of message integrity protection for these options, an attacker could modify the option values to frustrate or divert requests for broadcast service. ----- End forwarded message ----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 12 15:08:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEtfA-0004zO-V1; Mon, 12 Sep 2005 15:08:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEtf9-0004yr-KI for dhcwg@megatron.ietf.org; Mon, 12 Sep 2005 15:08:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08491 for ; Mon, 12 Sep 2005 15:08:10 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEtjG-0005t4-Uy for dhcwg@ietf.org; Mon, 12 Sep 2005 15:12:35 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j8CJ89hi002247 for ; Mon, 12 Sep 2005 21:08:09 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j8CJ8907004995 for ; Mon, 12 Sep 2005 21:08:09 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j8CJ89jT004994 for dhcwg@ietf.org; Mon, 12 Sep 2005 21:08:09 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 12 Sep 2005 21:08:09 +0200 From: Stig Venaas To: dhcwg@ietf.org Message-ID: <20050912190809.GB4793@storhaugen.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [dhcwg] Further comments from Elwyn X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Here are some further comments from Elwyn after talking to author at last wg meeting. Stig ----- Forwarded message from elwynd@dial.pipex.com ----- Date: Thu, 4 Aug 2005 11:13:55 +0100 From: elwynd@dial.pipex.com Subject: Re: New Version Notification - draft-ietf-dhc-bcmc-options-03.txt I just had a long chat with one of the authors outside the DHC wg meeting. It appears that the situation is as follows (please correct me if I am wrong): - A mobile has no other way of finding out the domain name of the place(s) where broadcast servers can be found and hence may well need a DHCP/DHCPv6 option to find the domain name to locate its server(s). - It is not clear to me even after the discussion whether more than one domain name is needed - the 3GPP2 architecture allows the server to be either in the visited domain or the home domain (although the wording in the BCMCS document refers to the access network in a way that I would interpret as the access network that the mobile is using at that moment). This seems to imply to me that the network operator has a choice to offer one or the other but the mobile has to take what it is given. WHETHER OR NOT THIS IS THE CASE (BOTH) DOCUMENTS NEED TO BE IMPROVED to explain what is going on. - Thus it may be the case that this option is needed but it is still a matter of discussion whether it should offer one or several domain options. - The operators in 3GPP2 claim there is a need for both FQDN and address options. There was pushback in the meeting about this but the authors claim that this has been previously discussed in the wg and the dual approach agreed. The wg chairs need to rule on this one. - The authors believe that they have been told that there is no longer a shortage of DHCP options (due to the extension mechanism) so that requesting two options is not a problem. Once all this has been sorted out, the rest of the document needs to reflect the decisions made: - If multiple domain names/addresses can be offered, the logic for determining which one of them the client should select needs to be specified in such a way that it can be implemented algorithmically and deterministically - as Brian writes below and others commented in the meeting, the new wording in v3 is unsatisfactory. The v2 wording was better and acceptable to me (it reflects the corresponding sip wording). - If two DHCP options are used: - If extension codes are used, then the new options will only work with servers that support extension codes. - The text in 4.5 and 4.6 has to be upgraded to explain how to decide whether to send address or FQDN replies for DHCP in the same way as it is explained for DHCPv6 currently. - If only one option is to be used, then 4.5 and 4.6 need to be revised to remove text about the alternatives. The authors are going to talkj to the wg chairs and other commenters after the meeting and try to get this sorted out post haste. Regards, Elwyn [...] ----- End forwarded message ----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 12 15:12:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEtix-0005YA-Kt; Mon, 12 Sep 2005 15:12:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEtiv-0005Xj-Ev for dhcwg@megatron.ietf.org; Mon, 12 Sep 2005 15:12:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08863 for ; Mon, 12 Sep 2005 15:12:04 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEtn1-0005yU-KL for dhcwg@ietf.org; Mon, 12 Sep 2005 15:16:29 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j8CJC2hi003149 for ; Mon, 12 Sep 2005 21:12:02 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j8CJC2W7005021 for ; Mon, 12 Sep 2005 21:12:02 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j8CJC2Vr005020 for dhcwg@ietf.org; Mon, 12 Sep 2005 21:12:02 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 12 Sep 2005 21:12:02 +0200 From: Stig Venaas To: dhcwg@ietf.org Message-ID: <20050912191202.GC4793@storhaugen.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: e8ea636ec013593313c7b28da6453598 Subject: [dhcwg] bcmc status mail from Kuntal Chowdhury X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org ----- Forwarded message from "Chowdhury, Kuntal" ----- Subject: RE: New Version Notification - draft-ietf-dhc-bcmc-options-03.txt Date: Fri, 9 Sep 2005 17:53:12 -0400 From: "Chowdhury, Kuntal" [...] Here is the list of the open comments and the responses summarized from the email threads: DISCUSSES AND COMMENTS: ====================== Brian Carpenter: Discuss [2005-07-07]: Extracts from Gen-ART review by Elwyn Davies: ---------------------------------------------------------------------- Comment #1: ========== "... Summary for version -02: This document is certainly not ready for publication. Indeed it may (still) be fundamentally flawed: Two questions need to be answered regarding the new version: - My question to v01, as to whether this is fundamentally flawed, remains on thetable (Does it need multiple domain names or can it just use multiple SRV records for the one wireless access domain. - in which case do we really need DHCP(v6) options at all?).. the authors need to explain why multiple domain names are needed because I couldn't tell from the BCSMS document and the wording seems to imply one domain would be enough. " Response: --------- Multiple domain names should be allowed. If the operator supports only one domain, the option will contain only a domain name. In the future there will be cases where the operator has one or more partners/resellers (Mobile Virtual Network Operators (MVNO) model) for broadcast and multicast service. In that case, the operator (access service provider) should be able to use the same DHCP option to send multiple of those domain names (MVNOs). There is no need to restrict the option to contain only one domain name. If there is only one domain name supported by the access service provider, it will contain one domain name, otherwise it may contain a list of domains to support resellers and partner network operators. Subsequent Comment: ------------------- > I just had a long chat with one of the authors outside the DHC wg meeting. > > It appears that the situation is as follows (please correct me if I am > wrong): > - A mobile has no other way of finding out the domain name of the > place(s) where broadcast servers can be found and hence may well need > a DHCP/DHCPv6 option to find the domain name to locate its server(s). > - It is not clear to me even after the discussion whether more than > one domain name is needed - the 3GPP2 architecture allows the server > to be either in the visited domain or the home domain (although the > wording in the BCMCS document refers to the access network in a way > that I would interpret as the access network that the mobile is using > at that moment). This seems to imply to me that the network operator > has a choice to offer one or the other but the mobile has to take what > it is given. WHETHER OR NOT THIS IS THE CASE (BOTH) DOCUMENTS NEED TO > BE IMPROVED to explain what is going on. Response: --------- I don't get it. What is the problem if more than one domain name is allowed in the option? If the operator has no partnership such as MVNO, there will be one domain name returned. If the operator supports MVNOs (BTW most of the 3G wireless operators in North America do) they will provision different domain names for its own BCMCS service and for that of the MVNOs e.g. operator.com; mvno1.com, mvno2.com etc. Based on the user's preference (setting) in the BCMCS client, it may choose to use one of the domain names to fetch the appropriate BCMCS controller address. If no preferred domain name is found in the list, the client may use a default setting e.g. use the first one in the list. BTW, the client setting should be controlled by the user; this document should not mandate any particular behavior, IMHO. Change made: None. ----------- Comment #2: =========== " - As a result of the update, 2 DHCP code points are needed: Is there enough DHCP option space available for this request to get 2 code points, rather than the one which was RFC3361 got? " Response: --------- I think there is enough codes available. At least that was my understanding. Change made: None. ----------- Comment #3: ========== " Detailed review for v02: The editorial state of the document (apart from s5) is much improved after Margaret Wasserman's review. The majority of my comments are substantive... Abstract/s1/s2: These sections imply that the options have wider application than the main focus which is 3GPP2. Whilst it is true that 3GPP is also considering broadcast services, I can find no evidence that either 3GPP or OMA are actively considering the use of DHCP options as part of their configuration process. Maybe the implications of wider applicability need to be toned down a little. " Response: -------- Not sure what needs to be toned down here. The purpose of the text in the abstract is to educate the reader that the broadcast and multicast services are being standardized in some of the SDOs such as 3GPP, OMA and 3GPP2. This is a true statement. There is no hint or mention in the draft that all these SDOs embraced DHCP as the way to configure the mobile devices at this time. Change made: None. ----------- Comment #4: =========== " s4.1: The example at the end of 4.1 is now differently broken: the length byte for the second 'example' component is at the end of the structure rather than between the 0 for the end of the first domain name and the 'e' for the start of example. " Response: the example was beaten to death even though it is a ditto copy from RFC 3361. There is a note added to the RFC editor to fix it as well. " Change made: ----------- -02 version: +----+----+----+----+----+----+----+----+----+----+----+ |TBD1| 26 | 7 | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'| 3 | +----+----+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+----+----+ |'c' | 'o'| 'm'| 0 | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'| +----+----+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+ | 3 | 'n'| 'e'| 't'| 0 | 7 | +----+----+----+----+----+----+ -03 version: +----+----+----+----+----+----+----+----+----+----+----+ |TBD1| 26 | 7 | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'| 3 | +----+----+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+----+----+ |'c' |'o'| 'm'| 0 | 7 | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| +----+----+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+ |'e' | 3 | 'n'| 'e'| 't'| 0 | +----+----+----+----+----+----+ Comment #5: =========== " s4.1/4.2: ' Use of multiple domain names is not meant to replace the SRV records, but rather to allow a single DHCP/DHCPv6 server to indicate the broadcast controllers in the access provider's network.' This sentence has been adapted from a similar sentence in RFC3319 and RFC3361 - 'Use of multiple domain names is not meant to replace NAPTR and SRV records, but rather to allow a single DHCP server to indicate outbound proxy servers operated by multiple providers.' I am unclear about why multiple domain names would be needed for '*the* access provider's network'. This needs better explanation - and if it can't be provided then maybe this work is not needed at all: multiple SRV records would provide all that is needed perhaps. " Response: --------- The need for multiple domain names has been explained before. Change made: None. ----------- Comment #6: =========== " s4.5/4.6: Now that there are two separate options for IPv4, all the stuff in 4.5 and 4.6 which just talks about v6 needs to be duplicated for v4. " Response: --------- Nope...DHCPv4 and DHCPv6 protocols do not work in the same fashion. There is no such thing as ORO in DHCPv4. Besides, s4.6 talks about IPv4 options. Change made: None. ----------- Comment #7: =========== " s4.6: A reference to s3.1 or RFC1035 might also help regarding encoding of domain names and comparisons. " Response: -------- RFC1035 is referenced in s4.6. Is there anything more that is absolutely necessary? Change made: None. ----------- Comment #8: =========== " s5: At least: s/applies/apply/, s/spec/specification/, s/in-transist/in transit/, s/&/and/ Personally I would redraft this section: This document does not introduce any new security concerns beyond those specified in the basic DHCP [RFC2131] and DHCPv6 [RFC3315] specifications. In the absence of message integrity protection for these options, an attacker could modify the option values to frustrate or divert requests for broadcast service. " Response: --------- OK...I will adopt this suggested rewrite. Change made: ----------- -02 version: 5. Security Considerations The security considerations in the base DHCP spec [RFC2131] applies. An attacker may change information of the BCMCS Controller in packets that are in-tranist from DHCP server to the MN, if integrity protection is not in place. In that event, the user of the Broadcast & Multicast service may be diverted to a rogue BCMCS controller. -03 version: 5. Security Considerations This document does not introduce any new security concerns beyond those specified in the basic DHCP [RFC2131] and DHCPv6 [RFC3315] specifications. In the absence of message integrity protection for these options, an attacker could modify the option values to frustrate or divert requests for broadcast service. ---------------------------------------------------------------------- David Kessens: Discuss [2005-07-07]: I received the following comments from the Ops directorate by Pekka Savola that needs to be addressed: Comment #9: =========== " substantial ----------- +----+----+----+----+----+----+----+----+----+----+----+ |TBD1| 26 | 7 | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'| 3 | +----+----+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+----+----+ |'c' | 'o'| 'm'| 0 | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'| +----+----+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+ | 3 | 'n'| 'e'| 't'| 0 | 7 | +----+----+----+----+----+----+ ==> is the example encoding correct? Based on the description, I thought it should have been: +----+----+----+----+----+----+----+----+----+----+----+ |TBD1| 26 | 7 | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'| 3 | +----+----+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+----+----+ |'c' | 'o'| 'm'| 0 | 7 |' e'| 'x'| 'a'| 'm'| 'p'| 'l'| +----+----+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+ |'e' | 3 | 'n'| 'e'| 't'| 0 | +----+----+----+----+----+----+ ... " Response: --------- The example will be updated as noted in "Note to RFC Editor". I will fix it in -03 version. Change made: ----------- -02 version: +----+----+----+----+----+----+----+----+----+----+----+ |TBD1| 26 | 7 | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'| 3 | +----+----+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+----+----+ |'c' | 'o'| 'm'| 0 | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'| +----+----+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+ | 3 | 'n'| 'e'| 't'| 0 | 7 | +----+----+----+----+----+----+ -03 version: +----+----+----+----+----+----+----+----+----+----+----+ |TBD1| 26 | 7 | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'| 3 | +----+----+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+----+----+----+ |'c' |'o'| 'm'| 0 | 7 | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| +----+----+----+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+ |'e' | 3 | 'n'| 'e'| 't'| 0 | +----+----+----+----+----+----+ Comment #10: ============ " If the length of the domain list exceeds the maximum permissible length within a single option (254 octets), then the domain list MUST be represented in the DHCPv4 message as specified in [RFC3396] . ==> is this really needed? Is there really a perceived usage case where the list would be longer than that? This seems to be just inviting a case which is not implemented or tested, and will break when used. I'd suggest forbidding the long options for simplicity unless there exists an appropriate usage case for them.. " Response: --------- This draft is very similar to RFC3361 from every perspective. The sentence in question is there in that RFC as well. Please note that BCMCS service is not deployed as of now. How the service will be deployed and how it will turn out to be in future are anybody's guess. So, I would like to keep as much flexibility in the options as possible. Change made: None. ----------- Comment #11: ============ " If a client receives both the BCMCS Controller Domain Name List and IPv6 Address options, it SHOULD use the Domain Name List option. In this case, the client MAY use the BCMCS Controller IPv6 Address option only if the servers in the BCMCS Controller Domain Name List can not be resolved or reached. ==> is it clear which level of normativeness you mean with the use of 'MAY' in this context? Did you mean, "In this case, the client MUST NOT use the ... unless the servers in ..." ? Using MUST NOT or SHOULD NOT seems clearer, because 'MAY' in this context can be interpreted differently. " Response: --------- I see your point. I will use "SHOULD NOT use..." in -03 version. Change made: ------------ -02 version: If a client receives both the BCMCS Controller Domain Name List and IPv6 Address options, it SHOULD use the Domain Name List option. In this case, the client MAY use the BCMCS Controller IPv6 Address option only if the servers in the BCMCS Controller Domain Name List can not be resolved or reached. -03 version: If a client receives both the BCMCS Controller Domain Name List and IPv6 Address options, it SHOULD use the Domain Name List option. In this case, the client SHOULD NOT use the BCMCS Controller IPv6 Address option unless the servers in the BCMCS Controller Domain Name List can not be resolved or reached. Comment #12: =========== " 6. IANA Considerations [...] The DHCP options should be registered in http://www.iana.org/assignments/bootp-dhcp-extensions The DHCPv6 options should be registered in http://www.iana.org/assignments/dhcpv6-parameters ==> (these would probably be removed by the RFC-editor, but..) I think it's inappropriate to include this kind of URLs in an RFC. I'd suggest removing these two paragraphs; I'd hope that IANA can find the right registries without this guidance :) " Response: --------- Well...these two were added upon suggestion by one of the reviewers. I will remove these as you suggest and hope for the better. Change made: ------------ -02 version: The DHCP options should be registered in http://www.iana.org/assignments/bootp-dhcp-extensions The DHCPv6 options should be registered in http://www.iana.org/assignments/dhcpv6-parameters -03 version: These two lines are deleted. Comment #13: =========== " Comment [2005-07-07]: I received the folloing comments from the Ops directorate by Pekka Savola: BCMCS Control Server Domain Name List: Identical content as in Section 4.1 ... while 4.1 had: The general format of the BCMCS Controller Domain list option for DHCPv4 is as follows: Code Len FQDN(s) of BCMCS Controller +-----+-----+-----+-----+-----+-----+-----+-- | TBD1| n | s1 | s2 | s3 | s4 | s5 | ... +-----+-----+-----+-----+-----+-----+-----+-- ==> it seems obvious but I guess one could take the "Identical content" statement literally and include also the Code and Len bytes to the domain name list part? Shouldn't be an issue for those with brains turned on. Not sure if this could use a wording tweak or not. " Response: --------- How about "BCMCS Control Server Domain Name List: Identical content as in Section 4.1 (except the Code and Len fields)."? Change made: ------------ -02 version: BCMCS Control Server Domain Name List: Identical content as in Section 4.1 -03 version: BCMCS Control Server Domain Name List: Identical content as in Section 4.1 (except the Code and Len fields). Comment #14: ============ " | | | BCMCS Control server-1 address (IPv6 address) | ==> the right spacing before '|' should be fixed " Response: --------- Fixed. Change made: ------------ -02 version: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_BCMCS_SERVER_A | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | BCMCS Control server-1 address (IPv6 address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | BCMCS Control server-2 address (IPv6 address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -03 version: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_BCMCS_SERVER_A | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | BCMCS Control server-1 address (IPv6 address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | BCMCS Control server-2 address (IPv6 address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Comment #15: ============ " An attacker may change information of the BCMCS Controller in packets that are in-tranist from DHCP server to the MN, if integrity ==> s/tranist/transit/ " Response: --------- This section is re-written based on Elwyn Davies's comment. Change made: None. ----------- Bert Wijnen: Comment [2005-07-06]: ------------------------------------------------------------------------ - Comment #16: ============ " Needs a normative reference and a citation (in sect 3) to RFC2119 " Response: --------- Added. Change made: -02 version: 8. Normative References [BCMCS] 3GPP2, www.3gpp2.org, ftp://ftp.3gpp2.org/TSGX/Projects/X.P0022 2ndV&V.zip, "X.S0022, Broadcast and Multicast Service in cdma2000 Wireless IP Network. (pending publication)", December 2004. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002. -03 version: [BCMCS] 3GPP2, www.3gpp2.org, ftp://ftp.3gpp2.org/TSGX/Projects/X.P0022 2ndV&V.zip, "X.S0022, Broadcast and Multicast Service in cdma2000 Wireless IP Network. (pending publication)", December 2004. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002. Some Additional Comments from Elwyn Davies on -3 version: ------------------------------------------------------------------------ Comment #17: ============ " > - The operators in 3GPP2 claim there is a need for both FQDN and > address options. There was pushback in the meeting about this but the > authors claim that this has been previously discussed in the wg and > the dual approach agreed. > The wg chairs need to rule on this one. " Response: --------- I don't understand what the problem here is. The draft had both the FQDN and the address options since day one. Several people reviewed it and nobody had any issue with that. The two options are there for obvious reason. We want to give the operators provisioning flexibility. Change made: None ------------ Comment #18: ============ " > - If multiple domain names/addresses can be offered, the logic for > determining which one of them the client should select needs to be > specified in such a way that it can be implemented algorithmically and > deterministically - as Brian writes below and others commented in the > meeting, the new wording in v3 is unsatisfactory. The v2 wording was > better and acceptable to me (it reflects the corresponding sip > wording). " Response: --------- The client should be able to choose the preferred domain based on the user's setting. There are tons of clients out there that do operate exactly this way, e.g. the wi-fi clients allow the user to set the preferred SSID or network type. We can certainly add a sentence if it helps. Change made: TBD. ------------ Comment #19: ============ " > - If two DHCP options are used: > - If extension codes are used, then the new options will only work with > servers that support extension codes. > - The text in 4.5 and 4.6 has to be upgraded to explain how to decide whether > to send address or FQDN replies for DHCP in the same way as it is explained > for DHCPv6 currently. " Response: --------- Hmmm...I think I did explain this to you before. In DHCP, there is no ORO. Therefore, the only thing the server can use to decide whether to send one or the other or both the options is to use its provisioned policy. Change made: None ------------ Comment #20: ============ " > The -03 draft says: > > The option MAY contain multiple domain names, but these domain names > SHOULD be used to construct SRV lookups as specified in [BCMCS], > rather than querying for different A records. The client can try any > or ALL of the domain names to construct the SRV lookups. The list of > domain names MAY conatin the domain name of the access provider and > it's partner networks that also offer broadcast and multicast > service. > > This is not algorithmic. It does not say when it is appropriate to > exercise either of the MAYs and does not say when it is justified to > ignore the SHOULD. But an implementor needs these explanations to know > what to code or configure. This is especially important for the SHOULD > - do I write code to try all of the names, all but three, or only the fifth one? " Response: --------- Ideally, the implementer should write sw code in such a way that allows the user to set his/her preference if more than one domain names are received. If I am the user I would expect my client to let me set my preference: 1st preference: foo1.com 2nd preference: foo2.com If no match found...try all starting from the first one. I can add this example if it helps. Change made: TBD. ------------ Comment #21: ============ " > > [Nits: two typos (conatin and it's) in the last sentence. "ALL" is > > capitalised for no obvious reason.] " Response: ---------- OK, I will fix them. Change made: TBD. ------------ > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com] > Sent: Friday, September 09, 2005 9:01 AM > To: elwynd@dial.pipex.com > Cc: Stig Venaas; Chowdhury, Kuntal; rdroms@cisco.com; > margaret@thingmagic.com; david.kessens@nokia.com; pyegani@cisco.com; > Lila.Madour@ericsson.com > Subject: Re: New Version Notification - draft-ietf-dhc-bcmc-options-03.txt > > Any progress on this discussion? I'm still holding a discuss > until I hear back. > > Brian > > > > Brian E Carpenter wrote: > > Please do take it to the list, but don't forget the comment > > I made - the key thing when a document contains options and > > SHOULDs and MAYs is that it should then also contain enough > > information for the implementer (writing code or defining > > configuration) to decide what to actually *do* with each option: > > > > 1: when is it OK to ignore a SHOULD? > > 2: when is it useful to implement a MAY? > > 3: how to choose when more than one data element is present? > > ("local policy" is a fine answer) > > > > I think it's because these three things aren't clear that we > > are having this conversation. > > > > Brian > > > > Stig Venaas wrote: > > > >> I suggest we take the discussion to the dhc wg list. We should get > input > >> from the wg on this. > >> > >> Elwyn, can you post your issues to the list? > >> > >> Kuntal, once Elwyn has done that, could you then post this response? > >> > >> IMO what you write below clarifies a lot and it would help to have > >> some text like this in the draft. > >> > >> Stig > >> > >> On Sat, Aug 06, 2005 at 05:48:40PM -0400, Chowdhury, Kuntal wrote: > >> > >>> Please see inline [KC]>.... > >>> > >>> Thanks, > >>> Kuntal > >>> > >>> > >>>> -----Original Message----- > >>>> From: elwynd@dial.pipex.com [mailto:elwynd@dial.pipex.com] > >>>> Sent: Thursday, August 04, 2005 5:14 AM > >>>> To: Brian E Carpenter > >>>> Cc: Elwyn Davies; rdroms@cisco.com; venaas@uninett.no; > >>>> margaret@thingmagic.com; david.kessens@nokia.com; Chowdhury, Kuntal; > >>>> pyegani@cisco.com; Lila.Madour@ericsson.com > >>>> Subject: Re: New Version Notification - > >>> > >>> > >>> draft-ietf-dhc-bcmc-options-03.txt > >>> > >>>> I just had a long chat with one of the authors outside the DHC wg > >>> > >>> > >>> meeting. > >>> > >>>> It appears that the situation is as follows (please correct me if I > am > >>>> wrong): > >>>> - A mobile has no other way of finding out the domain name of the > >>> > >>> > >>> place(s) > >>> > >>>> where > >>>> broadcast servers can be found and hence may well need a DHCP/DHCPv6 > >>>> option to > >>>> find the domain name to locate its server(s). > >>>> - It is not clear to me even after the discussion whether more than > >>> > >>> > >>> one > >>> > >>>> domain > >>>> name is needed - the 3GPP2 architecture allows the server to be > either > >>> > >>> > >>> in > >>> > >>>> the > >>>> visited domain or the home domain (although the wording in the BCMCS > >>>> document > >>>> refers to the access network in a way that I would interpret as the > >>> > >>> > >>> access > >>> > >>>> network that the mobile is using at that moment). This seems to > imply > >>> > >>> > >>> to > >>> > >>>> me > >>>> that the network operator has a choice to offer one or the other but > >>> > >>> > >>> the > >>> > >>>> mobile > >>>> has to take what it is given. WHETHER OR NOT THIS IS THE CASE (BOTH) > >>>> DOCUMENTS > >>>> NEED TO BE IMPROVED to explain what is going on. > >>> > >>> > >>> [KC>] I don't get it. What is the problem if more than one domain name > >>> is allowed in the option? If the operator has no partnership such as > >>> MVNO, there will be one domain name returned. If the operator supports > >>> MVNOs (BTW most of the 3G wireless operators in North America do) they > >>> will provision different domain names for its own BCMCS service and > for > >>> that of the MVNOs e.g. operator.com; mvno1.com, mvno2.com etc. Based > on > >>> the user's preference (setting) in the BCMCS client, it may choose to > >>> use one of the domain names to fetch the appropriate BCMCS controller > >>> address. If no preferred domain name is found in the list, the client > >>> may use a default setting e.g. use the first one in the list. BTW, the > >>> client setting should be controlled by the user; this document should > >>> not mandate any particular behavior, IMHO. > >>> > >>> > >>>> - Thus it may be the case that this option is needed but it is still > a > >>>> matter of > >>>> discussion whether it should offer one or several domain options. > >>>> - The operators in 3GPP2 claim there is a need for both FQDN and > >>> > >>> > >>> address > >>> > >>>> options. There was pushback in the meeting about this but the > authors > >>>> claim > >>>> that this has been previously discussed in the wg and the dual > >>> > >>> > >>> approach > >>> > >>>> agreed. > >>>> The wg chairs need to rule on this one. > >>> > >>> > >>> [KC>] Again, I don't understand what the problem here is. The draft > had > >>> both the FQDN and the address options since day one. Several people > >>> reviewed it and nobody had any issue with that. The two options are > >>> there for obvious reason. We want to give the operators provisioning > >>> flexibility. > >>> > >>>> - The authors believe that they have been told that there is no > longer > >>> > >>> > >>> a > >>> > >>>> shortage of DHCP options (due to the extension mechanism) so that > >>>> requesting two > >>>> options is not a problem. > >>>> > >>>> Once all this has been sorted out, the rest of the document needs to > >>>> reflect the > >>>> decisions made: > >>>> - If multiple domain names/addresses can be offered, the logic for > >>>> determining > >>>> which one of them the client should select needs to be specified in > >>> > >>> > >>> such a > >>> > >>>> way > >>>> that it can be implemented algorithmically and deterministically - as > >>>> Brian > >>>> writes below and others commented in the meeting, the new wording in > >>> > >>> > >>> v3 > >>> > >>>> is > >>>> unsatisfactory. The v2 wording was better and acceptable to me (it > >>>> reflects the > >>>> corresponding sip wording). > >>> > >>> > >>> [KC>] The client should be able to choose the preferred domain based > on > >>> the user's setting. There are tons of clients out there that do > operate > >>> exactly this way, e.g. the wi-fi clients allow the user to set the > >>> preferred SSID or network type. We can certainly add a sentence if it > >>> helps. > >>> > >>> > >>>> - If two DHCP options are used: > >>>> - If extension codes are used, then the new options will only work > >>> > >>> > >>> with > >>> > >>>> servers that support extension codes. > >>>> - The text in 4.5 and 4.6 has to be upgraded to explain how to > >>> > >>> > >>> decide > >>> > >>>> whether > >>>> to send address or FQDN replies for DHCP in the same way as it is > >>>> explained > >>>> for DHCPv6 currently. > >>> > >>> > >>> [KC>] Hmmm...I think I did explain this to you before. In DHCP, there > is > >>> no ORO. Therefore, the only thing the server can use to decide whether > >>> to send one or the other or both the options is to use its provisioned > >>> policy. > >>> > >>>> - If only one option is to be used, then 4.5 and 4.6 need to be > >>> > >>> > >>> revised to > >>> > >>>> remove text about the alternatives. > >>>> > >>> > >>> [KC>] Both the options should be used. > >>> > >>> > >>>> The authors are going to talkj to the wg chairs and other commenters > >>> > >>> > >>> after > >>> > >>>> the > >>>> meeting and try to get this sorted out post haste. > >>>> > >>>> Regards, > >>>> Elwyn > >>>> Quoting Brian E Carpenter : > >>>> > >>>> > >>>>> (WG chairs - please forward this to the WG if appropriate.) > >>>>> > >>>>> Elwyn, > >>>>> > >>>>> Does this version resolve your main review comments? I don't > >>>>> seem to have been copied on any discussion since my DISCUSS > >>>>> was registered. > >>>>> > >>>>> Elwyn said: > >>>>> > >>>>> > >>>>>> - My question to v01, as to whether this is fundamentally flawed, > >>>> > >>>> > >>>> remains > >>>> > >>>>> on the > >>>>> > >>>>>> table (Does it need multiple domain names or can it just use > >>> > >>> > >>> multiple > >>> > >>>>>> SRV records for the one wireless access domain - in which case do > >>> > >>> > >>> we > >>> > >>>>>> really need DHCP(v6) options at all?).. the authors need to > >>> > >>> > >>> explain > >>> > >>>> why > >>>> > >>>>>> multiple domain names are needed because I couldn't tell from the > >>>> > >>>> > >>>> BCSMS > >>>> > >>>>>> document and the wording seems to imply one domain would be > >>> > >>> > >>> enough. > >>> > >>>>> > >>>>> The -03 draft says: > >>>>> > >>>>> The option MAY contain multiple domain names, but these domain > >>> > >>> > >>> names > >>> > >>>>> SHOULD be used to construct SRV lookups as specified in [BCMCS], > >>>>> rather than querying for different A records. The client can > >>> > >>> > >>> try > >>> > >>>> any > >>>> > >>>>> or ALL of the domain names to construct the SRV lookups. The > >>> > >>> > >>> list > >>> > >>>> of > >>>> > >>>>> domain names MAY conatin the domain name of the access provider > >>> > >>> > >>> and > >>> > >>>>> it's partner networks that also offer broadcast and multicast > >>>>> service. > >>>>> > >>>>> This is not algorithmic. It does not say when it is appropriate to > >>>> > >>>> > >>>> exercise > >>>> > >>>>> either of the MAYs and does not say when it is justified to ignore > >>>>> the SHOULD. But an implementor needs these explanations to know what > >>> > >>> > >>> to > >>> > >>>>> code or configure. This is especially important for the SHOULD - do > >>> > >>> > >>> I > >>> > >>>> write > >>>> > >>>>> code to try all of the names, all but three, or only the fifth one? > >>>>> > >>> > >>> [KC>] Ideally, the implementer should write sw code in such a way that > >>> allows the user to set his/her preference if more than one domain > names > >>> are received. If I am the user I would expect my client to let me set > my > >>> preference: 1st preference: foo1.com 2nd preference: foo2.com > >>> If no match found...try all starting from the first one. I can add > this > >>> example if it helps. > >>> > >>> > >>> > >>>>> [Nits: two typos (conatin and it's) in the last sentence. "ALL" is > >>>>> capitalised for no obvious reason.] > >>>>> [KC>] OK, I will fix them. > >>> > >>> > >>> > >>>>> Elwyn's second major comment: > >>>>> > >>>>> > >>>>>> - As a result of the update, 2 DHCP code points are needed: Is > >>> > >>> > >>> there > >>> > >>>>> > enough DHCP option space available for this request to get 2 code > >>>>> > points, rather than the one which was RFC3361 got? > >>>>> > >>> > >>> [KC>] This was already discussed and agreed, AFAIK. > >>> > >>> > >>>>> Was this answered during the discussion of Elwyn's review? > >>>>> > >>>>> Brian > >>>>> > >>>>> ID Tracker wrote: > >>>>> > >>>>>> New version (-03) has been submitted for > >>>>> > >>>>> > >>>>> draft-ietf-dhc-bcmc-options-03.txt. > >>>>> > >>> http://www.ietf.org/internet-drafts/draft-ietf-dhc-bcmc-options-03.txt > >>> > >>>>> > >>>> > >>>> -- > >>> > >>> > >>> > >>> "This email message and any attachments are confidential information > >>> of Starent Networks, Corp. The information transmitted may not be > >>> used to create or change any contractual obligations of Starent > >>> Networks, Corp. Any review, retransmission, dissemination or other > >>> use of, or taking of any action in reliance upon this e-mail and its > >>> attachments by persons or entities other than the intended recipient > >>> is prohibited. If you are not the intended recipient, please notify > >>> the sender immediately -- by replying to this message or by sending > >>> an email to postmaster@starentnetworks.com -- and destroy all copies > >>> of this message and any attachments without reading or disclosing > >>> their contents. Thank you." > >> > >> > >> > > ----- End forwarded message ----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 12 15:15:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEtmQ-0006K6-PF; Mon, 12 Sep 2005 15:15:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEtmP-0006JM-Pe for dhcwg@megatron.ietf.org; Mon, 12 Sep 2005 15:15:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09291 for ; Mon, 12 Sep 2005 15:15:40 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEtqT-00065R-6T for dhcwg@ietf.org; Mon, 12 Sep 2005 15:20:05 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j8CJFThi004085 for ; Mon, 12 Sep 2005 21:15:29 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j8CJFTuE005042 for ; Mon, 12 Sep 2005 21:15:29 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j8CJFTCr005041 for dhcwg@ietf.org; Mon, 12 Sep 2005 21:15:29 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 12 Sep 2005 21:15:28 +0200 From: Stig Venaas To: dhcwg@ietf.org Message-ID: <20050912191528.GD4793@storhaugen.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [dhcwg] bcmc status and issues X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org As was discussed in the wg meeting, a lot has changed in the bcmc draft since it passed wglc, and there are several outstanding issues. Here is my take on the status and the remaining issues. The two drafts draft-ietf-dhc-bcmcv4-option-00.txt and draft-ietf-dhc-bcmcv6-option-00.txt passed wglc in February. They were replaced by a common draft draft-ietf-dhc-bcmc-options-00.txt at end of March. Later in May, June and August we got rev 01, 02 and 03 resp. See http://tools.ietf.org/wg/dhc/draft-ietf-dhc-bcmc-options/ for diffs. draft-ietf-dhc-bcmc-options-01.txt through IETF LC in June. Thomas Narten posted his review comments of 01 to DHC list June 16th. Version 02 was made to address those. Elwyn Davies reviewed 01 and 02 June/July and had a number of issues. I'm sending that in a separate mail. There is also an additional mail I will forward from Elwyn after talking to author this last IETF. I'm also posting a mail from Kuntal Chowdhury where he lists the issues and resolutions in 03. Below are the main outstanding issues / discussion points I'm aware of. See also the i-d tracker. In addition Ralph and I have some minor issues (I think just typos and minor textual improvements), but the below issues are what I think we need to discuss at this point. I1 FQDNs Should FQDNs be allowed and is it ok to have multiple? If FQDNs are allowed, is it okay using two different option codes as proposed? I2 Clarifications regarding MAYs/SHOULDs From mail from Brian Carpenter: > The -03 draft says: > > The option MAY contain multiple domain names, but these domain names > SHOULD be used to construct SRV lookups as specified in [BCMCS], > rather than querying for different A records. The client can try any > or ALL of the domain names to construct the SRV lookups. The list of > domain names MAY conatin the domain name of the access provider and > it's partner networks that also offer broadcast and multicast > service. > > This is not algorithmic. It does not say when it is appropriate to exercise > either of the MAYs and does not say when it is justified to ignore > the SHOULD. But an implementor needs these explanations to know what to > code or configure. This is especially important for the SHOULD - do I write > code to try all of the names, all but three, or only the fifth one? Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 12 16:29:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEuw0-0006zb-Ny; Mon, 12 Sep 2005 16:29:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEuvz-0006ua-HM for dhcwg@megatron.ietf.org; Mon, 12 Sep 2005 16:29:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18909 for ; Mon, 12 Sep 2005 16:29:38 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEv08-0001kY-PO for dhcwg@ietf.org; Mon, 12 Sep 2005 16:34:05 -0400 Received: by zproxy.gmail.com with SMTP id l1so373009nzf for ; Mon, 12 Sep 2005 13:29:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=qWI/ComdRJh7KgMEiSklBiVH/kzkAMn8TOo0RP5Q8Lw9tW2qLj5OaNXrCxT+L5yTpQrMmYLsGN8wLzqBavc0hEuInr8yqJiwuNDQ80CGQSuXZbOnAgNs4E9mGn23GDhjtbDQuPqxuQd6gwGxscf0pfiQPhfhbjHU+3xyTFP5gYU= Received: by 10.36.23.6 with SMTP id 6mr226012nzw; Mon, 12 Sep 2005 13:29:30 -0700 (PDT) Received: by 10.36.55.8 with HTTP; Mon, 12 Sep 2005 13:29:28 -0700 (PDT) Message-ID: Date: Tue, 13 Sep 2005 03:29:29 +0700 From: Nguyen Dinh Nam To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] Ideas on public key (X.509) authentication for ARP and DHCP X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nguyendinhnam@gmail.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I'm trying to design an authentication mechanism for ARP, it uses a feature of DHCP so I post the question here. Currently ARP is unaunthentic, leaving space for ARP spoofing, I think that the natural way to add authentication to a protocol it is to add digital signature to it. There is an approach published by the author of Ettercap (the famous ARP spoofing tool) - "S-ARP: a Secure Address Resolution Protocol" http://www.acsac.org/2003/papers/111.pdf. But that protocol is not very applicable because it doesn't use any existing PKI. I want to propose an extension to ARP that uses the X.509 certificate to sign ARP replies. Tradditionally, the sender signs his own messages. ARP is stateless, so the signer's certificate must be included in the ARP reply (for the receiver to verify the signature). Usually, the size of an X.509 certificate is bigger than the size of an ehternet frame, so the "sender signs" approach won't work. Each network has an entity (I call it LAN Authority, LANA should be known by all nodes on that network) which assigns IP addresses to all nodes, either using DHCP or configure each node manually. That entity knows all IP adress to hardware address mappings, so it can sign the mappings, and deliver a corresponding signature to each node which will include it in the data field of ARP replies later. The LANA is known by all nodes so it's certificate is known, and it's unnecessary to include it in ARP reply (in fact, it may be necessary to include the identifier - such as the hash - of the LANA's certificate). On a network using DHCP, the DHCP server knowns IP address to hardware address mappings, so it matches the functionality of the LANA, and the signature seems to be a part of node's configuration, so I think that DHCP WG has the responsibility. For the ARP problem, I want to define a DHCP option to deliver the signature. LANA has to deliver its certificate to nodes as well, so they can verify the signature, hence it needs another DHCP option. I think that it's quite a waste if we don't use that signature for DHCP authentication (RFC 3138). Currently, only a shared secret mechanism is defined for DHCP authentication. It's not perfect since the host may travel to a new network, and shared secret doesn't work. If we define a public key authentication mechanism, the travelling host only has to know the root CA (such as Verisign, which signs DHCP servers' certificates) to be able to authenticate DHCP replies of unknown networks. These are just my ideas, I really want DHCP WG to give comments and suggestions, and if it's suitable to make some new RFCs, it's cool if some seniors will supervise me to do it, since it's the first time I do this kind of work, I feel a little hesistant. Regards, Nam _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 12 16:44:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEvAN-0003Yv-EC; Mon, 12 Sep 2005 16:44:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEvAL-0003Yp-Ru for dhcwg@megatron.ietf.org; Mon, 12 Sep 2005 16:44:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22668 for ; Mon, 12 Sep 2005 16:44:35 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEvEc-0003DQ-2M for dhcwg@ietf.org; Mon, 12 Sep 2005 16:49:02 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 12 Sep 2005 16:44:29 -0400 X-IronPort-AV: i="3.97,102,1125892800"; d="scan'208"; a="69928731:sNHT40029552" Received: from [68.50.138.194] (che-vpn-cluster-1-121.cisco.com [10.86.240.121]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8CKiQT6008516 for ; Mon, 12 Sep 2005 16:44:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v622) To: DHCP discussion list Message-Id: From: John Schnizlein Date: Mon, 12 Sep 2005 16:44:26 -0400 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Subject: [dhcwg] Fwd: [Geopriv] I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0777952968==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0777952968== Content-Type: multipart/alternative; boundary=Apple-Mail-7-74294407 --Apple-Mail-7-74294407 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: September 12, 2005 3:50:02 PM EDT > To: i-d-announce@ietf.org > Cc: geopriv@ietf.org > Subject: [Geopriv] I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Geographic Location/Privacy Working > Group of the IETF. > > Title : Dynamic Host Configuration Protocol (DHCPv4 > and DHCPv6) Option for Civic Addresses > Configuration Information > Author(s) : H. Schulzrinne > Filename : draft-ietf-geopriv-dhcp-civil-07.txt > Pages : 22 > Date : 2005-9-12 > > This document specifies a Dynamic Host Configuration Protocol (DHCPv4 > and DHCPv6) option containing the civic location of the client or > the > DHCP server. The Location Configuration Information (LCI) includes > information about the country, administrative units such as states, > provinces and cities, as well as street addresses, postal community > names and building information. The option allows multiple > renditions of the same address in different scripts and languages. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil > -07.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-geopriv-dhcp-civil-07.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-geopriv-dhcp-civil-07.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. > --Apple-Mail-7-74294407 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Begin forwarded message: 0000,0000,0000From: Internet-Drafts@ietf.org 0000,0000,0000Date: September 12, 2005 3:50:02 PM EDT 0000,0000,0000To: i-d-announce@ietf.org 0000,0000,0000Cc: geopriv@ietf.org 0000,0000,0000Subject: [Geopriv] I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Geographic Location/Privacy Working Group of the IETF. Title : Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information Author(s) : H. Schulzrinne Filename : draft-ietf-geopriv-dhcp-civil-07.txt Pages : 22 Date : 2005-9-12 This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or the DHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces and cities, as well as street addresses, postal community names and building information. The option allows multiple renditions of the same address in different scripts and languages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-geopriv-dhcp-civil-07.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-geopriv-dhcp-civil-07.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. --Apple-Mail-7-74294407-- --===============0777952968== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0777952968==-- From dhcwg-bounces@ietf.org Tue Sep 13 04:09:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF5r7-0005vL-Ku; Tue, 13 Sep 2005 04:09:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EExsb-0000gl-1B for dhcwg@megatron.ietf.org; Mon, 12 Sep 2005 19:38:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08941 for ; Mon, 12 Sep 2005 19:38:18 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EExwk-0001QS-UW for dhcwg@ietf.org; Mon, 12 Sep 2005 19:42:47 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 12 Sep 2005 16:38:12 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8CNbcKg005873 for ; Mon, 12 Sep 2005 16:38:10 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Sep 2005 16:38:08 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.122.166]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Sep 2005 16:38:08 -0700 Message-Id: <4.3.2.7.2.20050912181411.03163c48@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Sep 2005 18:38:07 -0500 To: dhcwg@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 12 Sep 2005 23:38:08.0268 (UTC) FILETIME=[079E54C0:01C5B7F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [dhcwg] New ID for downloading URIs via DHCP X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org DHC WG To let folks know - a new individual submission Internet Draft has been announced regarding using DHCP for downloaded (or requesting for, then downloading) URIs to a DHC client here: http://www.ietf.org/internet-drafts/draft-polk-dhc-uri-00.txt with this abstract This document defines a new Dynamic Host Configuration Protocol (DHC) Option to allow one or more URIs to be transmitted from a server to a client within one or more messages, and for one or more URIs, each with a unique purpose, to be specifically requested by a client of a server. Included in this Option is a purpose field to identify the type of URI being requested by the client, or the type of URI in the DHCP message from the server. Of interest, I hope, to the DHC WG is that this proposed Option requests the use of a single DHCP Option to be used for URIs of multiple purposes, each identified by a sub-option code called a "purpose". This is done a little differently than in RFC 3396 where the sub-options are smaller. I don't believe I violated any length rules of 2131 or 3396, and I believe I articulate how to address lengths and concatenation in this document for longer URIs, and for how to include more than one URI - each of a different purpose - in the same DHCP message, or in the same IP datagram (with the same Option value - but different purposes). The focus of the proposed URIs are primarily surrounding the Geopriv and ECRIT WGs There are 11 URIs currectly defined in this ID (acronym explosion and definitions are in the ID): Purpose = 1 (Primary PSAP URI) Purpose = 2 (Secondary PSAP URI) Purpose = 3 (Location By-Reference of Client) Purpose = 4 (ESGW URI of Client) Purpose = 5 (ESRP URI of Client) Purpose = 6 (Organization Providing Location for Client) Purpose = 7 (URI of Geocoding/Reverse Geocoding) Purpose = 8 (Primary URI of Geo Mapping Service) Purpose = 9 (Secondary URI of Geo Mapping Service) Purpose = 10 (Primary URI of Civic Mapping Service) Purpose = 11 (Secondary URI of Civic Mapping Service) Others can be added based on consensus discussion of this document I just spoke with the Ralph Droms, and open discussion of this ID on the ECRIT list is fine with him. The formal syntax and encoding of the option proposal is to be discussed on the DHC list for those interested here, but the URI meanings don't need to be discussed on this list where emergency calling and location conveyance/conversion is of fairly little concern, as ECRIT is the primary WG of interest for this effort initially. That said, newly proposed URIs with completely different purposes can be included in this document. I am not suggesting a limitation (other than the one byte purpose length field of 255 ;-) BTW - I have no range set aside for private purposes. Is this needed? Reviews and comments are appreciated cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 13 12:35:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFDka-0002f6-3V; Tue, 13 Sep 2005 12:35:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF1W7-00028n-6i for dhcwg@megatron.ietf.org; Mon, 12 Sep 2005 23:31:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16910 for ; Mon, 12 Sep 2005 23:31:28 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EF1aP-0006Ak-UU for dhcwg@ietf.org; Mon, 12 Sep 2005 23:35:59 -0400 Received: by zproxy.gmail.com with SMTP id l1so442029nzf for ; Mon, 12 Sep 2005 20:31:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tK0+Em6NFTaLawKVyO4gfdG3vJRBkF/A2O36tyTMb0PU/Hh9is34QTXxzNtfYp6IRtKqOSN2Jm2lXVclTdTFU11cm2S07smNZQp/LwKamWvoMaECa6D7u7PZbOpgfSU56vc1SzdurjRvjXVFLj3uJF6kFBzItIWoZUDyeI7ueXQ= Received: by 10.36.58.16 with SMTP id g16mr232651nza; Mon, 12 Sep 2005 20:30:25 -0700 (PDT) Received: by 10.36.55.8 with HTTP; Mon, 12 Sep 2005 20:31:15 -0700 (PDT) Message-ID: Date: Tue, 13 Sep 2005 10:31:15 +0700 From: Nguyen Dinh Nam To: DHCP discussion list Subject: Re: [dhcwg] Fwd: [Geopriv] I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nguyendinhnam@gmail.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org * This draft defines a set of CAtypes. I think that using (Relative) Object Identifier to identify CAtypes may be a good alternative to the IANA registry. * Using ASN.1 to define this protocol make it much clearer, and it's easy to define formats of CAvalues when necessary. For example, the value of CAtype 27 (floor) should be numerical instead of an arbitrary value. And ANS.1 is extremely helpful when implementing the protocol. * The author mentioned a security consideration: "Where critical decisions might be based on the value of this GEOCONF_CIVIC option". If the DHCP server is authenticated separatedly from the GEOCONF_CIVIC, it can fake random GEOCONF_CIVIC options because no binding between the DHCP server's identity and GEOCONF_CIVIC options which the DHCP server can provide. If GEOCONF_CIVIC options are authentic, it'll help separate good DHCP server from rogue ones. For example, in the dorm, the authentic GEOCONF_CIVIC options don't allow a famous cafe shop next to the dorm (where many students visit regularly, and they let the DHCP server there assigns configurations automatically) to advertise itself as the dorm's DHCP server. This draft is closely related to what I've been working on - authenticating ARP and DHCP so I would like to help - if the author agrees. Regards, Nam On 9/13/05, John Schnizlein wrote: >=20 >=20 > Begin forwarded message: >=20 > > From: Internet-Drafts@ietf.org > > Date: September 12, 2005 3:50:02 PM EDT > > To: i-d-announce@ietf.org > > Cc: geopriv@ietf.org > > Subject: [Geopriv] I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Geographic Location/Privacy Working > > Group of the IETF. > > > > Title : Dynamic Host Configuration Protocol (DHCPv4 > > and DHCPv6) Option for Civic Addresses > > Configuration Information > > Author(s) : H. Schulzrinne > > Filename : draft-ietf-geopriv-dhcp-civil-07.txt > > Pages : 22 > > Date : 2005-9-12 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 13 12:35:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFDka-0002fV-GK; Tue, 13 Sep 2005 12:35:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF1XD-0002Nh-Qq for dhcwg@megatron.ietf.org; Mon, 12 Sep 2005 23:32:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16917 for ; Mon, 12 Sep 2005 23:32:29 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EF1bO-0006Be-Pp for dhcwg@ietf.org; Mon, 12 Sep 2005 23:37:00 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 12 Sep 2005 20:32:21 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8D3WIKE018359 for ; Mon, 12 Sep 2005 20:32:20 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Sep 2005 20:32:12 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.96.139]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Sep 2005 20:32:11 -0700 Message-Id: <4.3.2.7.2.20050912223208.02e7b108@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Sep 2005 22:32:10 -0500 To: dhcwg@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 13 Sep 2005 03:32:11.0809 (UTC) FILETIME=[BA38A110:01C5B813] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [dhcwg] New ID for downloading URIs via DHCP X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org DHC WG To let folks know - a new individual submission Internet Draft has been announced regarding using DHCP for downloaded (or requesting for, then downloading) URIs to a DHC client here: http://www.ietf.org/internet-drafts/draft-polk-dhc-uri-00.txt with this abstract This document defines a new Dynamic Host Configuration Protocol (DHC) Option to allow one or more URIs to be transmitted from a server to a client within one or more messages, and for one or more URIs, each with a unique purpose, to be specifically requested by a client of a server. Included in this Option is a purpose field to identify the type of URI being requested by the client, or the type of URI in the DHCP message from the server. Of interest, I hope, to the DHC WG is that this proposed Option requests the use of a single DHCP Option to be used for URIs of multiple purposes, each identified by a sub-option code called a "purpose". This is done a little differently than in RFC 3396 where the sub-options are smaller. I don't believe I violated any length rules of 2131 or 3396, and I believe I articulate how to address lengths and concatenation in this document for longer URIs, and for how to include more than one URI - each of a different purpose - in the same DHCP message, or in the same IP datagram (with the same Option value - but different purposes). The focus of the proposed URIs are primarily surrounding the Geopriv and ECRIT WGs There are 11 URIs currectly defined in this ID (acronym explosion and definitions are in the ID): Purpose = 1 (Primary PSAP URI) Purpose = 2 (Secondary PSAP URI) Purpose = 3 (Location By-Reference of Client) Purpose = 4 (ESGW URI of Client) Purpose = 5 (ESRP URI of Client) Purpose = 6 (Organization Providing Location for Client) Purpose = 7 (URI of Geocoding/Reverse Geocoding) Purpose = 8 (Primary URI of Geo Mapping Service) Purpose = 9 (Secondary URI of Geo Mapping Service) Purpose = 10 (Primary URI of Civic Mapping Service) Purpose = 11 (Secondary URI of Civic Mapping Service) Others can be added based on consensus discussion of this document I just spoke with the Ralph Droms, and open discussion of this ID on the ECRIT list is fine with him. The formal syntax and encoding of the option proposal is to be discussed on the DHC list for those interested here, but the URI meanings don't need to be discussed on this list where emergency calling and location conveyance/conversion is of fairly little concern, as ECRIT is the primary WG of interest for this effort initially. That said, newly proposed URIs with completely different purposes can be included in this document. I am not suggesting a limitation (other than the one byte purpose length field of 255 ;-) BTW - I have no range set aside for private purposes. Is this needed? Reviews and comments are appreciated cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 13 15:31:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGVV-00047z-1W; Tue, 13 Sep 2005 15:31:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF89q-0003kK-Gy for dhcwg@megatron.ietf.org; Tue, 13 Sep 2005 06:37:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13799 for ; Tue, 13 Sep 2005 06:36:45 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EF8E2-00072N-8g for dhcwg@ietf.org; Tue, 13 Sep 2005 06:41:20 -0400 Received: by zproxy.gmail.com with SMTP id l1so553247nzf for ; Tue, 13 Sep 2005 03:36:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Hv/+xmlaAZwuQQsQ1TiLGghUmyzhXLoyLKvc+qv49WFsJbcj2k736NQtjzijPNRmkZmYMOkPVQNUaNbNXCmeLSPa5mvs52jfI3G6pC3I1jYF667Si28W9ODDnq4VyAtBVOV3gZbmcegcgcW10C91e73GCRvttfNazMtXHkdsW+I= Received: by 10.36.250.53 with SMTP id x53mr551137nzh; Tue, 13 Sep 2005 03:36:37 -0700 (PDT) Received: by 10.36.55.8 with HTTP; Tue, 13 Sep 2005 03:36:37 -0700 (PDT) Message-ID: Date: Tue, 13 Sep 2005 17:36:37 +0700 From: Nguyen Dinh Nam To: dhcwg@ietf.org Subject: Re: [dhcwg] Fwd: [Geopriv] I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt In-Reply-To: Mime-Version: 1.0 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Henning Schulzrinne X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nguyendinhnam@gmail.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0839837966==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0839837966== Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Content-Transfer-Encoding: base64 VGhpcyBlbWFpbCBkaWRuJ3Qgc2VlbSB0byByZWFjaCB0aGUgbWFpbGluZyBsaXN0IHNvIEkgcmVz ZW5kIGl0LCBzb3JyeQppZiBpdCdzIGR1cGxpY2F0ZWQKLS0tLS0KCiogVGhpcyBkcmFmdCBkZWZp bmVzIGEgc2V0IG9mIENBdHlwZXMuIEkgdGhpbmsgdGhhdCB1c2luZyAoUmVsYXRpdmUpCk9iamVj dCBJZGVudGlmaWVyIHRvIGlkZW50aWZ5IENBdHlwZXMgbWF5IGJlIGEgZ29vZCBhbHRlcm5hdGl2 ZSB0byB0aGUKSUFOQSByZWdpc3RyeS4KCiogVXNpbmcgQVNOLjEgdG8gZGVmaW5lIHRoaXMgb3B0 aW9uIHdpbGwgbWFrZSBpdCBjbGVhcmVyLCBhbmQgaXQncwplYXN5IHRvIGRlZmluZSBmb3JtYXRz IG9mIENBdmFsdWVzIHdoZW4gbmVjZXNzYXJ5LiBGb3IgZXhhbXBsZSwgdGhlCnZhbHVlIG9mIENB dHlwZSAyNyAoZmxvb3IpIHNob3VsZCBiZSBudW1lcmljYWwgaW5zdGVhZCBvZiBhbiBhcmJpdHJh cnkKdmFsdWUuIEFuZCBBTlMuMSBpcyBleHRyZW1lbHkgaGVscGZ1bCB3aGVuIGltcGxlbWVudGlu ZyB0aGUgcHJvdG9jb2wuCkhvd2V2ZXIsIEFTTi4xIG1heSBiZSBvdmVya2lsbC4KCiogVGhlIGF1 dGhvciBtZW50aW9uZWQgYSBzZWN1cml0eSBjb25zaWRlcmF0aW9uOiAiV2hlcmUgY3JpdGljYWwK ZGVjaXNpb25zIG1pZ2h0IGJlIGJhc2VkIG9uIHRoZSB2YWx1ZSBvZiB0aGlzIEdFT0NPTkZfQ0lW SUMgb3B0aW9uIi4KSWYgdGhlIERIQ1Agc2VydmVyIGlzIGF1dGhlbnRpY2F0ZWQgc2VwYXJhdGVk bHkgZnJvbSB0aGUKR0VPQ09ORl9DSVZJQywgaXQgY2FuIGZha2UgcmFuZG9tIEdFT0NPTkZfQ0lW SUMgb3B0aW9ucyBiZWNhdXNlIG5vCmJpbmRpbmcgYmV0d2VlbiB0aGUgREhDUCBzZXJ2ZXIncyBp ZGVudGl0eSBhbmQgR0VPQ09ORl9DSVZJQyBvcHRpb25zCndoaWNoIHRoZSBESENQIHNlcnZlciBj YW4gcHJvdmlkZS4gSWYgR0VPQ09ORl9DSVZJQyBvcHRpb25zIGFyZQphdXRoZW50aWMsIGl0J2xs IGhlbHAgc2VwYXJhdGUgZ29vZCBESENQIHNlcnZlciBmcm9tIHJvZ3VlIG9uZXMuIEZvcgpleGFt cGxlLCBpbiB0aGUgZG9ybSwgdGhlIGF1dGhlbnRpYyBHRU9DT05GX0NJVklDIG9wdGlvbnMgZG9u J3QgYWxsb3cKYSBmYW1vdXMgY2FmZSBzaG9wIG5leHQgdG8gdGhlIGRvcm0gKHdoZXJlIG1hbnkg c3R1ZGVudHMgdmlzaXQKcmVndWxhcmx5LCBhbmQgdGhleSBsZXQgdGhlIERIQ1Agc2VydmVyIHRo ZXJlIGFzc2lnbnMgY29uZmlndXJhdGlvbnMKYXV0b21hdGljYWxseSkgdG8gYWR2ZXJ0aXNlIGl0 c2VsZiBhcyB0aGUgZG9ybSdzIERIQ1Agc2VydmVyLgoKVGhpcyBkcmFmdCBpcyBjbG9zZWx5IHJl bGF0ZWQgdG8gd2hhdCBJJ3ZlIGJlZW4gd29ya2luZyBvbiAtCmF1dGhlbnRpY2F0aW5nIEFSUCBh bmQgREhDUCBzbyBJIHdvdWxkIGxpa2UgdG8gaGVscCAtIGlmIHRoZSBhdXRob3IKYWdyZWVzLgoK UmVnYXJkcywKTmFtCgpPbiA5LzEzLzA1LCBKb2huIFNjaG5pemxlaW4gPGpzY2huaXpsQGNpc2Nv LmNvbT4gd3JvdGU6Cj4KPgo+IEJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOgo+Cj4gPiBGcm9tOiBJ bnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmcKPiA+IERhdGU6IFNlcHRlbWJlciAxMiwgMjAwNSAzOjUw OjAyIFBNIEVEVAo+ID4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZwo+ID4gQ2M6IGdlb3ByaXZA aWV0Zi5vcmcKPiA+IFN1YmplY3Q6IFtHZW9wcml2XSBJLUQgQUNUSU9OOmRyYWZ0LWlldGYtZ2Vv cHJpdi1kaGNwLWNpdmlsLTA3LnR4dAo+ID4KPiA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2 YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cwo+ID4gZGlyZWN0b3JpZXMu Cj4gPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBHZW9ncmFwaGljIExvY2F0aW9u L1ByaXZhY3kgV29ya2luZwo+ID4gR3JvdXAgb2YgdGhlIElFVEYuCj4gPgo+ID4gICAgICAgVGl0 bGUgICAgICAgICAgIDogRHluYW1pYyBIb3N0IENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgKERIQ1B2 NAo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBhbmQgREhDUHY2KSBPcHRpb24gZm9yIENp dmljIEFkZHJlc3Nlcwo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBDb25maWd1cmF0aW9u IEluZm9ybWF0aW9uCj4gPiAgICAgICBBdXRob3IocykgICAgICAgOiBILiBTY2h1bHpyaW5uZQo+ ID4gICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1nZW9wcml2LWRoY3AtY2l2aWwt MDcudHh0Cj4gPiAgICAgICBQYWdlcyAgICAgICAgICAgOiAyMgo+ID4gICAgICAgRGF0ZSAgICAg ICAgICAgIDogMjAwNS05LTEyCg== --===============0839837966== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0839837966==-- From dhcwg-bounces@ietf.org Tue Sep 13 15:32:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGWJ-0004ek-2L; Tue, 13 Sep 2005 15:32:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFBUo-0003cZ-NB for dhcwg@megatron.ietf.org; Tue, 13 Sep 2005 10:10:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23151 for ; Tue, 13 Sep 2005 10:10:41 -0400 (EDT) Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFBZ5-0003LI-4l for dhcwg@ietf.org; Tue, 13 Sep 2005 10:15:17 -0400 Received: from openexchange.incognito.com ([192.168.77.70]) by chimera.incognito.com with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EFBUN-0007ub-Vx; Tue, 13 Sep 2005 07:10:25 -0700 Received: from [192.168.75.75] (unknown [192.168.75.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by openexchange.incognito.com (Postfix) with ESMTP id 8B63519231; Tue, 13 Sep 2005 07:21:22 -0700 (PDT) Message-ID: <4326DDCF.9060708@openexchange.incognito.com> Date: Tue, 13 Sep 2005 07:10:23 -0700 From: Andre Kostur Organization: Incognito Software Inc. User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [dhcwg] New ID for downloading URIs via DHCP References: <4.3.2.7.2.20050912181411.03163c48@email.cisco.com> In-Reply-To: <4.3.2.7.2.20050912181411.03163c48@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -5.9 (-----) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org James M. Polk wrote: > DHC WG > > To let folks know - a new individual submission Internet Draft has > been announced regarding using DHCP for downloaded (or requesting for, > then downloading) URIs to a DHC client here: > > http://www.ietf.org/internet-drafts/draft-polk-dhc-uri-00.txt > > with this abstract > > This document defines a new Dynamic Host Configuration Protocol > (DHC) Option to allow one or more URIs to be transmitted from a > server to a client within one or more messages, and for one or more > URIs, each with a unique purpose, to be specifically requested by a > client of a server. Included in this Option is a purpose field to > identify the type of URI being requested by the client, or the type > of URI in the DHCP message from the server. > > Of interest, I hope, to the DHC WG is that this proposed Option > requests the use of a single DHCP Option to be used for URIs of > multiple purposes, each identified by a sub-option code called a > "purpose". This is done a little differently than in RFC 3396 where > the sub-options are smaller. I don't believe I violated any length > rules of 2131 or 3396, and I believe I articulate how to address > lengths and concatenation in this document for longer URIs, and for > how to include more than one URI - each of a different purpose - in > the same DHCP message, or in the same IP datagram (with the same > Option value - but different purposes). > Well.. after a brief read, here's what I can see: 1) Why only 1 byte for the URI purpose? Do you only ever see the possibility of 255 different purposes for an URI? I would suggest extending that to a 2-byte field 2) The way you are currently encoding the data is almost going out of its way to break RFC 3396. Why not either have a 2-byte length value for each URI, or define that URIs are 0-terminated and the client can break up the full option at the 0s to get the individual sub-options? 3) You don't define how a client "requests" these options. Do they supply 0-length URIs with the purposes that they are interested in? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 13 15:33:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGWd-0004sr-F6; Tue, 13 Sep 2005 15:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFCPs-0004uC-Bs for dhcwg@megatron.ietf.org; Tue, 13 Sep 2005 11:09:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26492 for ; Tue, 13 Sep 2005 11:09:45 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFCUH-0004i3-F6 for dhcwg@ietf.org; Tue, 13 Sep 2005 11:14:22 -0400 Received: by zproxy.gmail.com with SMTP id l1so611378nzf for ; Tue, 13 Sep 2005 08:09:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jQNnBNQJlSmem91kcReKsI8An1lfin4Um6S/vr9bFnp5ellzkrOB9P/FOjttJp/6mXo/TsevqOo+ekWqei4fQufZoU4tC5f9JmEBm5/2PpH+lLEb40c8+SaGILKQebyTmvMvQ4Bd450ULYprPd39OuyACUNaygePGbVw6jORTqc= Received: by 10.36.222.18 with SMTP id u18mr798583nzg; Tue, 13 Sep 2005 08:09:27 -0700 (PDT) Received: by 10.36.55.8 with HTTP; Tue, 13 Sep 2005 08:09:25 -0700 (PDT) Message-ID: Date: Tue, 13 Sep 2005 22:09:25 +0700 From: Nguyen Dinh Nam To: Henning Schulzrinne Subject: Re: [dhcwg] Fwd: [Geopriv] I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt In-Reply-To: <4326D318.9000702@cs.columbia.edu> Mime-Version: 1.0 References: <4326D318.9000702@cs.columbia.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nguyendinhnam@gmail.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1428333070==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1428333070== Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Content-Transfer-Encoding: base64 T24gOS8xMy8wNSwgSGVubmluZyBTY2h1bHpyaW5uZSA8aGdzQGNzLmNvbHVtYmlhLmVkdT4gd3Jv dGU6Cj4gVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBJIHdpbGwgcG9pbnQgb3V0IHRoYXQgdGhp cyBkcmFmdCBoYXMgYmVlbiBpbgo+IHdvcmtpbmcgZ3JvdXAgYW5kIElFVEYgbGFzdCBjYWxsIGFs cmVhZHkuIEl0IGhhcyBiZWVuIGF2YWlsYWJsZSBmb3IKPiByZXZpZXcgc2luY2UgRGVjZW1iZXIg MjAwMiwgaS5lLiwgYWxtb3N0IHRocmVlIHllYXJzIGFnby4gVGh1cywKPiB1bnJvbGxpbmcgbWFu eSBvZiB0aGUgYWdyZWVtZW50cyB0aGF0IHR3byB3b3JraW5nIGdyb3VwcyAoR0VPUFJJViBhbmQK PiBESENQKSBoYXZlIGFycml2ZWQgYXQgc2luY2Ugb25lIGNvdWxkIGRvIHRoaW5ncyBkaWZmZXJl bnRseSBzZWVtcyBsZXNzCj4gYXR0cmFjdGl2ZSBpZiB0aGUgSUVURiBhdHRhY2hlcyBhbnkgdmFs dWUgdG8gZXZlciBjb21wbGV0aW5nIGFuIGVmZm9ydC4KPgo+IElBTkEgaGFzIHRvIHJlZ2lzdGVy IHRoZXNlIG1hcHBpbmcgaW4gZWl0aGVyIGV2ZW50LiBXZSBjb3VsZCBtYWtlIHRoZQo+IHNhbWUg YXJndW1lbnQgZm9yIGFueSBudW1lcmljIGNvbnN0YW50IGluIGFueSBwcm90b2NvbC4gQXMgZmFy IGFzIEkKPiBrbm93LCBubyBvdGhlciBESENQIG9wdGlvbiBoYXMgY2hvc2VuIHRoaXMgYXBwcm9h Y2guCj4KPiBBZ2FpbiwgSSdtIHNvcnJ5IHRvIHNheSB0aGF0IEkgZmFpbCB0byBzZWUgdGhlIGFk dmFudGFnZS4gQVNOLjEgd291bGQKPiBsaWtlbHkgbWVhbiBhIHZhcmlhYmxlLWxlbmd0aCBpZGVu dGlmaWVyLCBhbmQgb25lIHRoYXQgaXMgc2lnbmlmaWNhbnRseQo+IGxvbmdlciB0aGFuIG9uZSBi eXRlLiBEdXJpbmcgdGhlIGRlc2lnbiwgc3BhY2UgZWZmaWNpZW5jeSB3YXMgYSBwcmltZQo+IGNv bnNpZGVyYXRpb24uCj4KPiBBcyB5b3UgcG9pbnQgb3V0LCB0aGlzIGlzIGEgZ2VuZXJpYyBESENQ IHByb2JsZW0gd2hpY2gsIEkgYmVsaWV2ZSwKPiBzaG91bGQgYmUgc29sdmVkIGdlbmVyaWNhbGx5 IHJhdGhlciB0aGFuIGZvciBvbmUgcGFydGljdWxhciBESENQIG9wdGlvbi4KPiBJZiB0aGUgREhD UCB3b3JraW5nIGdyb3VwIGNhbiBhZ3JlZSBvbiBzdWNoIGEgbWVjaGFuaXNtLCB0aGlzIG9wdGlv biwKPiBhcyB3ZWxsIGFzIG1hbnkgb3RoZXJzLCBiZW5lZml0LCBidXQgaXQgc2VlbXMgdW5oZWxw ZnVsIHRvIGRlbGF5Cj4gY29tcGxldGlvbiBvZiB0aGlzIGVmZm9ydCBieSB3YWl0aW5nIGZvciBh IG11Y2ggbW9yZSBhbWJpdGlvdXMgdW5kZXJ0YWtpbmcuCgpTb3JyeSwgSSB3YXMgYnJhbmQgbmV3 IHRvIHRoZSBESENXRyBzbyBJIHdhcyB0b28gZWFnZXIgdG8gZ2l2ZSBjb21tZW50cyA6KQoKQ3Vy cmVudGx5LCB0aGUgREhDUCBhdXRoZW50aWNhdGlvbiBvcHRpb24gaXMgYXZhaWxhYmxlIChhbHRo b3VnaCBub3QKeWV0IGltcGxlbWVudGVkKS4gQSBzaGFyZWQgc2VjcmV0IHNjaGVtYSBpcyBkZWZp bmVkIGFuZCBJIHRoaW5rIHRoYXQgYQpwdWJsaWMga2V5IGF1dGhlbnRpY2F0aW9uIChQS0EpIHNj aGVtYSB3aWxsIGJlIGF2YWlsYWJsZSwgc29vbmVyIG9yCmxhdGVyLiBJdCdzIGltcG9ydGFudCBi ZWNhdXNlIG9ubHkgdGhlIFBLQSBzY2hlbWEgY2FuIGhlbHAgcGVvcGxlCmF1dGhlbnRpY2F0ZSB1 bmtub3duIERIQ1Agc2VydmVycywganVzdCBsaWtlIHRoZSBjYXNlIG9mIEhUVFBTCndlYnNpdGVz LgoKU28gSSBhc3N1bWUgdGhhdCB3ZSB3aWxsIGhhdmUgdGhlIENlcnRpZmljYXRpb24gQXV0aG9y aXR5IHRvIHNpZ24gdGhlCkRIQ1Agc2VydmVyJ3MgWC41MDkgY2VydGlmaWNhdGUuIFRoaXMgY2Vy dGlmaWNhdGUgU0hBTEwgbGltaXQgdGhlIERIQ1AKc2VydmVyIGZyb20gcHJvdmlkaW5nIHJhbmRv bSBvcHRpb25zIHRvIGNsaWVudHMuIENlcnRhaW5seSwgdGhlIENBClNIT1VMRCBub3Qgc2lnbiBh bGwgb3B0aW9ucywgc28gaXQncyAqbm90IGEgZ2VuZXJpYyBwcm9ibGVtKiwgZWFjaApvcHRpb24g aGFzIHRvIGdldCBpdHMgb3duIGNvbnNpZGVyYXRpb24hIEFuZCBJIHRoaW5rIHRoYXQgeW91cgpH RU9DT05GX0NJVklDIHdpbGwgZ2V0IHRvcCBwcmlvcml0eSBiZWNhdXNlIGl0IG1heSBiZSB0aGUg bW9zdAppbXBvcnRhbnQgKGlmIG5vdCB0aGUgb25seSBvbmUpIHRvIHJlY29nbml6ZSByb2d1ZSBE SENQIHNlcnZlcnMuCgpJZiB5b3UgYWdyZWUgd2l0aCBteSBhcmd1bWVudHMsIHRoZW4gdGhlIGNv b3BlcmF0aW9uIGJldHdlZW4KR0VPQ09ORl9DSVZJQyBhbmQgWC41MDkgaXMgaW1wb3J0YW50LiBT byB1c2luZyBPSUQgdG8gaWRlbnRpZnkgQ0F0eXBlcwptYXkgaGF2ZSBhIGJlbmVmaXQ6IHdlIGRv bid0IGhhdmUgdG8gaW52ZW50IHNvbWUgaWRlbnRpZmllcnMgdGhhdApleGlzdGVkLCB0aGVuIGNy ZWF0ZSB0aGUgbWFwcGluZyBiZXR3ZWVuIHRoZW0gKE9JRCBhbmQgdGhlIElBTkEKcmVnaXN0cnkp LCBzdWNoIGFzCjIuNS40LjYgY291bnRyeU5hbWUgPC0tPiBDQXR5cGU9MAoyLjUuNC44IHN0YXRl T3JQcm92aW5jZU5hbWUgPC0tPiBDQXR5cGU9MQouLi4KQWxtb3N0IGV2ZXJ5dGhpbmcgaGFzIHRy YWRlLW9mZnMsIHN1cmVseSwgdGhlIGRpc2FkdmFudGFnZSBpcyB0aGF0IE9JRAppcyB0aGF0IGl0 J3MgYmlnZ2VyLgpKdXN0IG15IDIgY2VudHMuCk5hbQo= --===============1428333070== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1428333070==-- From dhcwg-bounces@ietf.org Tue Sep 13 15:33:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGXM-0005AU-UK; Tue, 13 Sep 2005 15:33:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFDDL-0005DB-2V for dhcwg@megatron.ietf.org; Tue, 13 Sep 2005 12:00:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28754 for ; Tue, 13 Sep 2005 12:00:43 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFDHc-0005uB-Iu for dhcwg@ietf.org; Tue, 13 Sep 2005 12:05:21 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 13 Sep 2005 09:00:36 -0700 X-IronPort-AV: i="3.97,106,1125903600"; d="scan'208"; a="341239491:sNHT30772084" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8DG08KU010398; Tue, 13 Sep 2005 09:00:32 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Sep 2005 09:00:27 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.145.188]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Sep 2005 09:00:26 -0700 Message-Id: <4.3.2.7.2.20050913104545.0295fff0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Sep 2005 11:00:25 -0500 To: Andre Kostur From: "James M. Polk" Subject: Re: [dhcwg] New ID for downloading URIs via DHCP In-Reply-To: <4326DDCF.9060708@openexchange.incognito.com> References: <4.3.2.7.2.20050912181411.03163c48@email.cisco.com> <4.3.2.7.2.20050912181411.03163c48@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 13 Sep 2005 16:00:26.0830 (UTC) FILETIME=[41BD2EE0:01C5B87C] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Andre Thanks for the quick review - comments below At 07:10 AM 9/13/2005 -0700, Andre Kostur wrote: >James M. Polk wrote: >> >>Of interest, I hope, to the DHC WG is that this proposed Option requests >>the use of a single DHCP Option to be used for URIs of multiple purposes, >>each identified by a sub-option code called a "purpose". This is done a >>little differently than in RFC 3396 where the sub-options are smaller. I >>don't believe I violated any length rules of 2131 or 3396, and I believe >>I articulate how to address lengths and concatenation in this document >>for longer URIs, and for how to include more than one URI - each of a >>different purpose - in the same DHCP message, or in the same IP datagram >>(with the same Option value - but different purposes). >Well.. after a brief read, here's what I can see: > >1) Why only 1 byte for the URI purpose? Do you only ever see the >possibility of 255 different purposes for an URI? Well, the thought was: how many URIs are foreseen as configuration data type URIs? 255 seems like a whole lot (even multiples more than I expect to ever be defined). That said, adding another byte to this is very easy. I was looking for general feedback if this is a good thing to modify. >I would suggest extending that to a 2-byte field > >2) The way you are currently encoding the data is almost going out of its >way to break RFC 3396. I view this as moving the rules of 2131 and 3396 down one level of hierarchy to applying to the sub-options (purposes), instead of to the full Options themselves. 3396 states that if the same DHC Option appears more than once in the same message, the two values are to be concatenated (to get around the 255 byte rule of 2131). This is a limitation that shouldn't be present in the URI case, in which concatenation could be across more than one 255 byte boundary, yet be one of seveval URIs in the same datagram. This avoided the extra bytes necessary for what you wrote below: having the single DHCP Option value with an overall message length field, then sub-option identifiers with their own length fields. >Why not either have a 2-byte length value for each URI, or define that >URIs are 0-terminated and the client can break up the full option at the >0s to get the individual sub-options? I would prefer the former if given the choice >3) You don't define how a client "requests" these options. oops - sorry >Do they supply 0-length URIs with the purposes that they are interested in? Is this acceptable as the means for requesting which URIs a client wants? cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 13 15:34:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGXZ-0005I8-W8; Tue, 13 Sep 2005 15:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFDgD-0001ty-7Y for dhcwg@megatron.ietf.org; Tue, 13 Sep 2005 12:30:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00522 for ; Tue, 13 Sep 2005 12:30:21 -0400 (EDT) Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFDkI-0006iQ-Sn for dhcwg@ietf.org; Tue, 13 Sep 2005 12:35:00 -0400 Received: from openexchange.incognito.com ([192.168.77.70]) by chimera.incognito.com with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EFDfe-0008Ik-3G; Tue, 13 Sep 2005 09:30:10 -0700 Received: from [192.168.75.75] (unknown [192.168.75.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by openexchange.incognito.com (Postfix) with ESMTP id 3A2E219250; Tue, 13 Sep 2005 09:41:10 -0700 (PDT) Message-ID: <4326FE91.5050709@openexchange.incognito.com> Date: Tue, 13 Sep 2005 09:30:09 -0700 From: Andre Kostur Organization: Incognito Software Inc. User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [dhcwg] New ID for downloading URIs via DHCP References: <4.3.2.7.2.20050912181411.03163c48@email.cisco.com> <4.3.2.7.2.20050912181411.03163c48@email.cisco.com> <4.3.2.7.2.20050913104545.0295fff0@email.cisco.com> In-Reply-To: <4.3.2.7.2.20050913104545.0295fff0@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -5.9 (-----) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org James M. Polk wrote: > Andre > >> 2) The way you are currently encoding the data is almost going out of >> its way to break RFC 3396. > > > I view this as moving the rules of 2131 and 3396 down one level of > hierarchy to applying to the sub-options (purposes), instead of to the > full Options themselves. > > 3396 states that if the same DHC Option appears more than once in the > same message, the two values are to be concatenated (to get around the > 255 byte rule of 2131). This is a limitation that shouldn't be present > in the URI case, in which concatenation could be across more than one > 255 byte boundary, yet be one of seveval URIs in the same datagram. > > This avoided the extra bytes necessary for what you wrote below: > having the single DHCP Option value with an overall message length > field, then sub-option identifiers with their own length fields. However, you are changing 3396 (and 2131) in doing so. According to this draft, it would have 3396 apply to every option except this one. As in, every other option is supposed to be concatenated together before processing, but this one must not. >> Do they supply 0-length URIs with the purposes that they are >> interested in? > > > Is this acceptable as the means for requesting which URIs a client wants? > Offhand I don't see why not... but let's see what the other WG members have to say about it... _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 13 15:34:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGYQ-0005pI-Km; Tue, 13 Sep 2005 15:34:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFFo0-0006D0-66 for dhcwg@megatron.ietf.org; Tue, 13 Sep 2005 14:46:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06004 for ; Tue, 13 Sep 2005 14:46:47 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFFsK-0001OA-5q for dhcwg@ietf.org; Tue, 13 Sep 2005 14:51:25 -0400 Received: by zproxy.gmail.com with SMTP id l1so2433nzf for ; Tue, 13 Sep 2005 11:46:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZVma0eeLpuuzfDE74iCEXZDuryhXa2zAjCNJ9FjatjoAZag7Myadg+oGccAKaUHyHG9dBvJAVMkW6uIryPPQA71UAuqpcJPx36FkEGNMoOT8IU3AIWLOuDwPqqpUHBtuk6gGsMb4oWQDad00kbmwyuUk35fa4D6jkC79QmMDcWk= Received: by 10.36.3.6 with SMTP id 6mr30370nzc; Tue, 13 Sep 2005 11:46:36 -0700 (PDT) Received: by 10.36.55.8 with HTTP; Tue, 13 Sep 2005 11:46:35 -0700 (PDT) Message-ID: Date: Wed, 14 Sep 2005 01:46:35 +0700 From: Nguyen Dinh Nam To: Henning Schulzrinne Subject: Re: [dhcwg] Fwd: [Geopriv] I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt In-Reply-To: <43271401.3050606@cs.columbia.edu> Mime-Version: 1.0 References: <4326D318.9000702@cs.columbia.edu> <43271401.3050606@cs.columbia.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nguyendinhnam@gmail.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2031786133==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============2031786133== Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Content-Transfer-Encoding: base64 SSBmb3VuZCB0aGF0IEkgZ290IGl0IHdyb25nLiBJbml0aWFsbHksIEkgdGhvdWdodCB0aGF0IHRo ZSBwdWJsaWMga2V5CmF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSBTSEFMTCByZWx5IG9uIHlvdXIg b3B0aW9uIHRvIGRldGVjdCByb2d1ZQpzZXJ2ZXJzLCBidXQgZm9yIG5vdywgSSB0aGluayB0aGF0 IGl0J3MgdGhlIGJhZCBwcmFjdGljZS4KCkNlcnRhaW5seSwgYSBjZXJ0aWZpY2F0ZSBjYW4gYmUg Y3JhZnRlZCB0byBjb250YWluIGV2ZXJ5dGhpbmcKR0VPQ09ORl9DSVZJQyBkb2VzIC0gaW4gdGhl IHN1YmplY3QgKFJETlNlcXVlbmNlIC0gUkZDIDI0NTkpIC0KcHJvdmlkaW5nIHRoZSBzdXBlcnNl dCBvZiBmZWF0dXJlcyBwbHVzIGV2ZXJ5dGhpbmcgaXMgYXV0aGVudGljLCBidXQKaXQncyBvdXQg b2YgdGhlIHNjb3BlIG9mIHRoZSBjb21tZW50cyBvZiB5b3VyIHByb3Bvc2FsLgoKU29ycnkgZm9y IHdhc3RpbmcgeW91ciB0aW1lLApOYW0KCj4gU2luY2UgdGhlcmUgZG9lc24ndCBzZWVtIHRvIGJl IGEgREhDUCBXRyBJbnRlcm5ldCBkcmFmdCBvbiB5b3VyCj4gcHJvcG9zYWwsIEkgdGhpbmsgSSB3 aWxsIHJlZnJhaW4gZnJvbSBmdXJ0aGVyIGNvbW1lbnRzIGFzIEknbSBsaWtlbHkgdG8KPiBtaXNz IHRoZSBwb2ludCBvZiB5b3VyIHByb3BvYWwuCg== --===============2031786133== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============2031786133==-- From dhcwg-bounces@ietf.org Tue Sep 13 16:54:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFHn9-0002H5-P3; Tue, 13 Sep 2005 16:54:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFHn8-0002H0-QY for dhcwg@megatron.ietf.org; Tue, 13 Sep 2005 16:54:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25860 for ; Tue, 13 Sep 2005 16:54:07 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFHra-0000ke-K6 for dhcwg@ietf.org; Tue, 13 Sep 2005 16:58:48 -0400 Received: from [66.93.162.100] (mdzod.fugue.com [66.93.162.100]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 7FB13568BA; Tue, 13 Sep 2005 13:53:53 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <4326FE91.5050709@openexchange.incognito.com> References: <4.3.2.7.2.20050912181411.03163c48@email.cisco.com> <4.3.2.7.2.20050912181411.03163c48@email.cisco.com> <4.3.2.7.2.20050913104545.0295fff0@email.cisco.com> <4326FE91.5050709@openexchange.incognito.com> Mime-Version: 1.0 (Apple Message framework v745) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <220D7DCF-0758-41F5-BEFC-84D429D7FD17@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] New ID for downloading URIs via DHCP Date: Tue, 13 Sep 2005 13:53:50 -0700 To: James Polk X-Mailer: Apple Mail (2.745) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Sep 13, 2005, at 9:30 AM, Andre Kostur wrote: > However, you are changing 3396 (and 2131) in doing so. According > to this draft, it would have 3396 apply to every option except this > one. As in, every other option is supposed to be concatenated > together before processing, but this one must not. Actually, it's slightly worse than that - it is necessary to concatenate, according to this draft, but in order to determine whether or not to concatenate, one must look at the purpose field within the option. This is really an unacceptable plan - it requires quite a bit of special complexity to support one option. Absent some good reason for doing this, which I don't see, we should use a method that requires no extra complexity to implement. What I would suggest is that you just have a length field for the URI text, make the other stuff fixed-length (which it is anyway) and allow multiple URIs to be represented in a single URI option. In general you don't *want* to send long URIs via DHCP - if the URI is that long, it probably isn't going to fit in the DHCP packet. So it would be very good to encourage shorter URIs, and to forbid a URI to be longer than 255 bytes. In general I'm not big on encoding limitations into specs, but in this case I think 255 bytes is plenty, and it's easy enough to rewrite a URI to be shorter if you need to, so I just don't see a lot of value in being flexible about long URIs in DHCP packets. I would make this option a concatenation-requiring option (see RFC3396). So now if you have two URIs in an option, it would likely look like this: [code] [length] [purpose] [uri length] [uri text] [purpose] [uri length] [uri text] _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 13 17:07:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFI09-0007ES-Ub; Tue, 13 Sep 2005 17:07:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFI08-0007E0-At for dhcwg@megatron.ietf.org; Tue, 13 Sep 2005 17:07:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27123 for ; Tue, 13 Sep 2005 17:07:33 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFI4b-0001Mp-Bh for dhcwg@ietf.org; Tue, 13 Sep 2005 17:12:13 -0400 Received: from [66.93.162.100] (mdzod.fugue.com [66.93.162.100]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id C2C2B568BA; Tue, 13 Sep 2005 14:07:26 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <4.3.2.7.2.20050913104545.0295fff0@email.cisco.com> References: <4.3.2.7.2.20050912181411.03163c48@email.cisco.com> <4.3.2.7.2.20050912181411.03163c48@email.cisco.com> <4.3.2.7.2.20050913104545.0295fff0@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v745) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4BD14081-2A0F-412B-9A7C-FB8B7CADD76A@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] New ID for downloading URIs via DHCP Date: Tue, 13 Sep 2005 14:07:24 -0700 To: "James M. Polk" X-Mailer: Apple Mail (2.745) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Sep 13, 2005, at 9:00 AM, James M. Polk wrote: >> 2) The way you are currently encoding the data is almost going out >> of its way to break RFC 3396. > > I view this as moving the rules of 2131 and 3396 down one level of > hierarchy to applying to the sub-options (purposes), instead of to > the full Options themselves. > > 3396 states that if the same DHC Option appears more than once in > the same message, the two values are to be concatenated (to get > around the 255 byte rule of 2131). This is a limitation that > shouldn't be present in the URI case, in which concatenation could > be across more than one 255 byte boundary, yet be one of seveval > URIs in the same datagram. > > This avoided the extra bytes necessary for what you wrote below: > having the single DHCP Option value with an overall message length > field, then sub-option identifiers with their own length fields. Right, but the additional complexity is substantial - it may be easy to express as a move down a hierarchy, but in fact it's just going to require some additional, fairly hairy special-case code in both the client and the server, and this will happen over my dead body. Well, anyway, my loudly flaming body. >> Why not either have a 2-byte length value for each URI, or define >> that URIs are 0-terminated and the client can break up the full >> option at the 0s to get the individual sub-options? > I would prefer the former if given the choice I agree with you that using a NUL-terminated string is a mistake. I agree in principle also that using a two-byte length makes some sense. However, if you use a two-byte length, you're placing an additional implementation burden on clients and servers, although the burden is significantly smaller than the burden imposed by your current proposal. This is because clients and servers currently support length-specified strings where the length is specified in a single byte. So I would argue against using two bytes. Is there some reason why you think URIs longer than 255 bytes are really crucial? Another reason that I say that you should really constrain the length is that in practice what's going to happen if you don't is that someone is going to use a really long URI with a bunch of HTML forms junk in it, because that's easier than doing a custom HTML script, and then this poor bastard is going to wonder why the URI option isn't getting sent, and call your support guys or ours on the phone and demand answers. The answer will be "your URI won't fit in the packet - use a shorter one." But IMHO it's better to force that constraint on them then to have to figure out precisely what's going wrong at support call time - it could actually take a bit of thinking for the support person to make the right connection, because these things *really* aren't obvious when seen from that perspective. Now, in DHCPv6-land, you *should* use two-byte lengths, because in DHCPv6-land that's what everything uses. But you should still tell the user to keep URIs short. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 13 18:21:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFJ9Q-0005o0-FP; Tue, 13 Sep 2005 18:21:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAv5A-00045I-GY for dhcwg@megatron.ietf.org; Thu, 01 Sep 2005 15:50:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26617 for ; Thu, 1 Sep 2005 15:50:42 -0400 (EDT) Received: from enterprise58.opnet.com ([192.104.65.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAv7A-0002dX-8S for dhcwg@ietf.org; Thu, 01 Sep 2005 15:52:49 -0400 Received: from mpdomain (netscreen3020.opnet.com [172.16.1.39]) by enterprise58.opnet.com (8.12.10/8.12.10) with ESMTP id j81JmwIQ027479 for ; Thu, 1 Sep 2005 15:48:58 -0400 Message-ID: <002e01c5af2d$ab95fd90$e80e10ac@opnet.com> From: "Kevin Purser" To: Date: Thu, 1 Sep 2005 15:45:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-OPNET-MailScanner: Found to be clean X-MailScanner-From: kpurser@opnet.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 13 Sep 2005 18:21:07 -0400 Subject: [dhcwg] stateless DHCP question X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hey folks, Quick question about stateless DHCPv6 that I couldn't seem to find in the drafts or mailing list: Section 5.1 of RFC 3736 states that the messages required for stateless DHCP are the Information-request and Reply messages. However, does the client first need to solicit a particular server with the Solicit message, or can it simply send the Information-request to the ALL_DHCP_Relay_Agents_and_Servers multicast address and accept the config returned by any server? Or is this up to the implementer? Thanks in advance! Kev _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 13 18:21:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFJ9S-0005p6-Px; Tue, 13 Sep 2005 18:21:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECIzL-0004a6-Lq for dhcwg@megatron.ietf.org; Mon, 05 Sep 2005 11:34:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21698 for ; Mon, 5 Sep 2005 11:34:25 -0400 (EDT) Received: from web60822.mail.yahoo.com ([209.73.178.230]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ECJ27-0000zW-Kc for dhcwg@ietf.org; Mon, 05 Sep 2005 11:37:21 -0400 Received: (qmail 73516 invoked by uid 60001); 5 Sep 2005 15:34:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2xMt1r3Ec+O6q3Q7saBCZhUXqxk7dk7tmzLdJSwXcXSaw2NA59J2BrbqrcAGQlJ2LYlB4PZcnqq55IqB/ywlr5TR60U19VnTMUi2VVR5S3Urj/64qZO0M0DroQF8nXL7hs2egOj7pO+GEHr87H+QLVfsMZzP6rKGzgHlIA4+v0E= ; Message-ID: <20050905153415.73514.qmail@web60822.mail.yahoo.com> Received: from [219.95.211.165] by web60822.mail.yahoo.com via HTTP; Mon, 05 Sep 2005 08:34:15 PDT Date: Mon, 5 Sep 2005 08:34:15 -0700 (PDT) From: LB Ngau To: dhcwg@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-Mailman-Approved-At: Tue, 13 Sep 2005 18:21:05 -0400 Subject: [dhcwg] Minimum bandwidth and latency requirement for DHCP X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0467396639==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0467396639== Content-Type: multipart/alternative; boundary="0-1986371058-1125934455=:70002" Content-Transfer-Encoding: 8bit --0-1986371058-1125934455=:70002 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi There, I would like to implement DHCP over VSAT link, the average latency for the link is 600ms. Is there any bandwidth and latency requirement for DHCP? Thank you in advance your help. Really appreciate it. Regards, Lih Bin --------------------------------- Click here to donate to the Hurricane Katrina relief effort. --0-1986371058-1125934455=:70002 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi There,
 
I would like to implement DHCP over VSAT link, the average latency for the link is 600ms.
 
Is there any bandwidth and latency requirement for DHCP?
 
Thank you in advance your help. Really appreciate it.
 
Regards,
Lih Bin

Click here to donate to the Hurricane Katrina relief effort. --0-1986371058-1125934455=:70002-- --===============0467396639== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0467396639==-- From dhcwg-bounces@ietf.org Tue Sep 13 18:21:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFJ9T-0005qG-C8; Tue, 13 Sep 2005 18:21:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFAlw-0004LI-8h for dhcwg@megatron.ietf.org; Tue, 13 Sep 2005 09:24:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21081 for ; Tue, 13 Sep 2005 09:24:18 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFAqD-0002PB-Ey for dhcwg@ietf.org; Tue, 13 Sep 2005 09:28:53 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j8DDOHKk014082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Sep 2005 09:24:18 -0400 (EDT) Message-ID: <4326D318.9000702@cs.columbia.edu> Date: Tue, 13 Sep 2005 09:24:40 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nguyendinhnam@gmail.com Subject: Re: [dhcwg] Fwd: [Geopriv] I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 13 Sep 2005 18:21:06 -0400 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Nguyen Dinh Nam wrote: > This email didn't seem to reach the mailing list so I resend it, Thanks for your comments. I will point out that this draft has been in working group and IETF last call already. It has been available for review since December 2002, i.e., almost three years ago. Thus, unrolling many of the agreements that two working groups (GEOPRIV and DHCP) have arrived at since one could do things differently seems less attractive if the IETF attaches any value to ever completing an effort. > sorryif it's duplicated----- * This draft defines a set of CAtypes. I > think that using (Relative)Object Identifier to identify CAtypes may > be a good alternative to theIANA registry. Why would this help? IANA has to register these mapping in either event. We could make the same argument for any numeric constant in any protocol. As far as I know, no other DHCP option has chosen this approach. > * Using ASN.1 to define this option will make it clearer, and > it'seasy to define formats of CAvalues when necessary. For example, > thevalue of CAtype 27 (floor) should be numerical instead of an > arbitraryvalue. And ANS.1 is extremely helpful when implementing the > protocol.However, ASN.1 may be overkill. Again, I'm sorry to say that I fail to see the advantage. ASN.1 would likely mean a variable-length identifier, and one that is significantly longer than one byte. During the design, space efficiency was a prime consideration. > * The author mentioned a security consideration: "Where > criticaldecisions might be based on the value of this GEOCONF_CIVIC > option".If the DHCP server is authenticated separatedly from > theGEOCONF_CIVIC, it can fake random GEOCONF_CIVIC options because > nobinding between the DHCP server's identity and GEOCONF_CIVIC > optionswhich the DHCP server can provide. If GEOCONF_CIVIC options > areauthentic, it'll help separate good DHCP server from rogue ones. > Forexample, in the dorm, the authentic GEOCONF_CIVIC options don't > allowa famous cafe shop next to the dorm (where many students > visitregularly, and they let the DHCP server there assigns > configurationsautomatically) to advertise itself as the dorm's DHCP > server. This draft is closely related to what I've been working on > -authenticating ARP and DHCP so I would like to help - if the > authoragrees. As you point out, this is a generic DHCP problem which, I believe, should be solved generically rather than for one particular DHCP option. If the DHCP working group can agree on such a mechanism, this option, as well as many others, benefit, but it seems unhelpful to delay completion of this effort by waiting for a much more ambitious undertaking. Henning _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 13 18:21:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFJ9T-0005rR-SE; Tue, 13 Sep 2005 18:21:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFF7E-0006sP-HS for dhcwg@megatron.ietf.org; Tue, 13 Sep 2005 14:02:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04376 for ; Tue, 13 Sep 2005 14:02:24 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFFBM-0000QC-UC for dhcwg@ietf.org; Tue, 13 Sep 2005 14:07:02 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j8DI26Wk005894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Sep 2005 14:02:06 -0400 (EDT) Message-ID: <43271401.3050606@cs.columbia.edu> Date: Tue, 13 Sep 2005 14:01:37 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nguyendinhnam@gmail.com Subject: Re: [dhcwg] Fwd: [Geopriv] I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt References: <4326D318.9000702@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 13 Sep 2005 18:21:06 -0400 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Nguyen Dinh Nam wrote: > Sorry, I was brand new to the DHCWG so I was too eager to give > comments :) Comments are always helpful, but there is a danger of delaying any draft forever - we could go about re-visiting design decisions forever, particularly those involving codin. > Currently, the DHCP authentication option is available (although > notyet implemented). A shared secret schema is defined and I think > that apublic key authentication (PKA) schema will be available, > sooner orlater. It's important because only the PKA schema can help > peopleauthenticate unknown DHCP servers, just like the case of > HTTPSwebsites. Since I don't track all the work items within the DHCP working group, I don't know what status this work has within the WG. > So I assume that we will have the Certification Authority to sign > theDHCP server's X.509 certificate. This certificate SHALL limit the > DHCPserver from providing random options to clients. Certainly, the > CASHOULD not sign all options, so it's *not a generic problem*, > eachoption has to get its own consideration! And I think that > yourGEOCONF_CIVIC will get top priority because it may be the > mostimportant (if not the only one) to recognize rogue DHCP servers. I'm sorry to say that if each option has its own signing issues, then the mechanism may not be particularly suitable for DHCP. > If you agree with my arguments, then the cooperation > betweenGEOCONF_CIVIC and X.509 is important. So using OID to identify > CAtypesmay have a benefit: we don't have to invent some identifiers > thatexisted, then create the mapping between them (OID and the > IANAregistry), such as2.5.4.6 countryName <--> CAtype=02.5.4.8 > stateOrProvinceName <--> CAtype=1...Almost everything has trade-offs, > surely, the disadvantage is that OIDis that it's bigger.Just my 2 > cents.Nam I fail to see the helpfulness of such a mapping. Since there doesn't seem to be a DHCP WG Internet draft on your proposal, I think I will refrain from further comments as I'm likely to miss the point of your propoal. Regards, Henning _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 13 18:28:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFJGN-0008Vv-R2; Tue, 13 Sep 2005 18:28:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFJGM-0008Vn-64 for dhcwg@megatron.ietf.org; Tue, 13 Sep 2005 18:28:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03079 for ; Tue, 13 Sep 2005 18:28:22 -0400 (EDT) Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFJKp-0003ld-53 for dhcwg@ietf.org; Tue, 13 Sep 2005 18:33:04 -0400 Received: from openexchange.incognito.com ([192.168.77.70]) by chimera.incognito.com with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EFJG6-00012p-VX; Tue, 13 Sep 2005 15:28:11 -0700 Received: from [192.168.75.75] (unknown [192.168.75.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by openexchange.incognito.com (Postfix) with ESMTP id 2661AD68C; Tue, 13 Sep 2005 15:39:15 -0700 (PDT) Message-ID: <4327527A.1030801@openexchange.incognito.com> Date: Tue, 13 Sep 2005 15:28:10 -0700 From: Andre Kostur Organization: Incognito Software Inc. User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: LB Ngau Subject: Re: [dhcwg] Minimum bandwidth and latency requirement for DHCP References: <20050905153415.73514.qmail@web60822.mail.yahoo.com> In-Reply-To: <20050905153415.73514.qmail@web60822.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -5.9 (-----) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org LB Ngau wrote: > Hi There, > > I would like to implement DHCP over VSAT link, the average latency for > the link is 600ms. > > Is there any bandwidth and latency requirement for DHCP? Well... not specifically written. But we're talking about a protocol where the client sends a 300-576 byte packet up to the server, and it probably expects a response somewhere in the 2-4 second range. So we're not talking about huge packets, nor really tight timing constraints. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 13 22:23:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFMw1-00055K-Eb; Tue, 13 Sep 2005 22:23:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFMvz-000534-Uj for dhcwg@megatron.ietf.org; Tue, 13 Sep 2005 22:23:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17626 for ; Tue, 13 Sep 2005 22:23:37 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFN0U-0002e8-St for dhcwg@ietf.org; Tue, 13 Sep 2005 22:28:20 -0400 Received: from impact.jinmei.org (unknown [2001:200:0:8002:18a6:a6be:fb5:e635]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 690A21521A; Wed, 14 Sep 2005 11:23:11 +0900 (JST) Date: Thu, 14 Sep 2000 11:23:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Kevin Purser" Subject: Re: [dhcwg] stateless DHCP question In-Reply-To: <002e01c5af2d$ab95fd90$e80e10ac@opnet.com> References: <002e01c5af2d$ab95fd90$e80e10ac@opnet.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.2 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Thu, 1 Sep 2005 15:45:08 -0400, >>>>> "Kevin Purser" said: > Section 5.1 of RFC 3736 states that the messages required for stateless DHCP > are the Information-request and Reply messages. However, does the client > first need to solicit a particular server with the Solicit message, or can > it simply send the Information-request to the > ALL_DHCP_Relay_Agents_and_Servers multicast address and accept the config > returned by any server? Or is this up to the implementer? The client can simply send the Information-request (rather, it probably *should* do so instead of sending Solicit first, because if the server only supports the RFC3736 subset of RFC3315 (i.e., stateless DHCPv6), it may ignore the Solicit message, causing unnecessary delay or even failure of expected exchanges). One may think this is not very clear from the specification, but, I personally think Section 18.1.5 of RFC3315 (in the context of the entire RFC) is clear enough on this. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 14 16:51:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFeEI-0005Gq-Kz; Wed, 14 Sep 2005 16:51:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFeED-0005GY-DX; Wed, 14 Sep 2005 16:51:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10720; Wed, 14 Sep 2005 16:51:35 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFeIs-0007pQ-4r; Wed, 14 Sep 2005 16:56:27 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j8EKpVWk014928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Sep 2005 16:51:32 -0400 (EDT) Message-ID: <43288D35.5020908@cs.columbia.edu> Date: Wed, 14 Sep 2005 16:51:01 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Linsner References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: 'GEOPRIV' , dhcwg@ietf.org Subject: [dhcwg] Re: draft-ietf-geopriv-dhcp-civil-07 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Marc, I'm just the "transmitter" in this case. The text was provided to me as part of resolving the IESG comments. Maybe those more closely involved with its drafting can provide additional input on your concerns. Henning Marc Linsner wrote: > Henning, > > Wrt: > > "This document only defines the delivery of location information from the > DHCP server to the client, due to security concerns related to using DHCP to > update the database. Within the GEOPRIV architecture as defined by RFC 3693 > [10], the defined mechanism in this document for conveying initial location > information is known as a "sighting" function. Sighting functions are not > required to have security capabilities and are only intended to be > configured in trusted and controlled environments. (A classic example of > the sighting function is a Global Positioning System wired directly to a > network node.) After initial location information has been introduced, it > MUST be afforded the protections defined in RFC 3694 [11]. Therefore, > location information MUST NOT be sent from a DHCP client to a DHCP server as > is normally allowed by DHCP." > > Correct me if I've interpreted this wrong. I derived from this text (at > least) 3 issues: > > 1) Due to [wiremap] database security concerns, we must disallow client to > dhcp server [upstream] communication of this LCI. > > 2) This DHCP LCI mechanism falls under the 'sighting' category as defined in > the geopriv architecture used in trusted and controlled environments. > > 3) Communication of location information outside of this special 'sighting' > category must be afforded the protections defined in RFC 3694. > > I'd like clarification on: > > 1) Since neither this document nor RFC 3825 defines the wiremap database > architecture, I don't understand this db security concern. How can the > transport of a db record be a security risk to the effecting of database > change within the unknown database architecture? Is this not a concern for > the database administration? We should not disallow this function solely > based on the assumption of poor database administration design. > > 2) Since upstream communication of this LCI information would still take > place within the confines of the 'sighting' category, a trusted and > controlled environment, what has happened that has made this upstream > communication fall under issue #3 (above)? This LCI option can only contain > information allowed by the draft, whether it's upstream or downstream. > > > Thanks, > > -Marc- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 14 17:39:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFeyE-0004hu-UH; Wed, 14 Sep 2005 17:39:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFeyD-0004hj-Bk; Wed, 14 Sep 2005 17:39:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13560; Wed, 14 Sep 2005 17:39:06 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFf2t-0000wZ-BE; Wed, 14 Sep 2005 17:43:59 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 14 Sep 2005 14:39:01 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j8ELcJWT021330; Wed, 14 Sep 2005 14:38:55 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 14:38:56 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.121.125]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 14:38:55 -0700 Message-Id: <4.3.2.7.2.20050914160915.0301adc8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Sep 2005 16:38:54 -0500 To: "Marc Linsner" From: "James M. Polk" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Sep 2005 21:38:55.0963 (UTC) FILETIME=[B556B2B0:01C5B974] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: dhcwg@ietf.org, 'ECRIT' Subject: [dhcwg] Re: draft-polk-dhc-uri-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org At 08:48 AM 9/14/2005 -0400, Marc Linsner wrote: >James, > >Would you please provide the basis for your text below regarding the timing >of psap determination, I can't seem to match it up with any of the >requirements within ecrit or geopriv. When something is urgent, do you want to invoke more processing complexity or less processing complexity? More typically means "more prone to errors", less typically means "less prone to errors". Everyone hear is assuming that the UA providing location will get mapped to the appropriate PSAP within a reasonable call set-up timeframe. This document suggests an optimization - to do the "mapping" before time is wasted doing the mapping just to set-up the call. The ECRIT Charter says: (item #1) "Successful delivery of an emergency service call within those systems requires both an association of the physical location of the originator with an appropriate emergency service center and call routing to deliver the call to the center." and (item #2) "Calls placed using Internet technologies do not use the same systems to achieve those goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting them more challenging. There are, however, Internet technologies available to describe location and to manage call routing. This working group will describe when these may be appropriate and how they may be used." and (item #3) "The group will show how the availability of location data and call routing information at different steps in session setup would enable communication between a user and a relevant emergency response center. " Item # 1 talks the association of user location and the appropriate PSAP. - This ID describes this by using the same Link provider that knows the UA's location (and give the UA its location. Item #2 talks about describing location and managing call routing - specifically "when" these may be appropriate. - This ID describes accomplishing this mapping before call set-up. - I don't remember reading a requirement in either WG that says "this mapping function MUST take place *only* during call set-up". Item #3 talks about different information at different times in the session set-up. - This ID provides the Request-URI for the INVITE message, plus provides an alternate Request-URI, plus the URI of the ESGW and ESRP. SIP Proxies will determine if a route is available or not, and reroute around any problems if there are any. A URI is not an IP Address, of which there is one. The same URI can go to many difference locations in times of overload or error. Webservers have been doing this function for better than 5 years now. >"One example of this URI download would be one specifically for the SIP or >SIPS URI of the appropriate Public Safety Answer Point (PSAP) for the client >when the user of that client calls for emergency help (911 or 112-type of >help). This is not a transaction that should take place when a voice >application wants to make such a critical call set-up. It is more >appropriate that this information be downloaded to the client when the voice >(or other) application boots up in case it is needed at a later time." > >Thanks, > >-Marc- cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 14 19:31:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFgjM-0008QP-Ct; Wed, 14 Sep 2005 19:31:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFgjJ-0008Nh-VU for dhcwg@megatron.ietf.org; Wed, 14 Sep 2005 19:31:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19243 for ; Wed, 14 Sep 2005 19:31:50 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFgo0-0003hw-Vn for dhcwg@ietf.org; Wed, 14 Sep 2005 19:36:45 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 14 Sep 2005 16:31:44 -0700 X-IronPort-AV: i="3.97,111,1125903600"; d="scan'208"; a="659852639:sNHT31917948" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8ENVg4u009548; Wed, 14 Sep 2005 16:31:42 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 16:31:42 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.121.125]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 16:31:41 -0700 Message-Id: <4.3.2.7.2.20050914175207.03f67558@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Sep 2005 18:31:40 -0500 To: Ted Lemon From: "James M. Polk" Subject: Re: [dhcwg] New ID for downloading URIs via DHCP In-Reply-To: <220D7DCF-0758-41F5-BEFC-84D429D7FD17@nominum.com> References: <4326FE91.5050709@openexchange.incognito.com> <4.3.2.7.2.20050912181411.03163c48@email.cisco.com> <4.3.2.7.2.20050912181411.03163c48@email.cisco.com> <4.3.2.7.2.20050913104545.0295fff0@email.cisco.com> <4326FE91.5050709@openexchange.incognito.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Sep 2005 23:31:41.0344 (UTC) FILETIME=[75D1EA00:01C5B984] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ted Thanks for the (blunt) comments... several comments below, but first: OK, ok - I give.... "uncle" I'll fix the doc to be more in line with 3396 I'll go with this depiction: >[code] [length] [purpose] [uri length] [uri text] [purpose] [uri >length] [uri text] but have a few comments about what else you said that might impact this pseudo-format above At 01:53 PM 9/13/2005 -0700, Ted Lemon wrote: >On Sep 13, 2005, at 9:30 AM, Andre Kostur wrote: >>However, you are changing 3396 (and 2131) in doing so. According >>to this draft, it would have 3396 apply to every option except this >>one. As in, every other option is supposed to be concatenated >>together before processing, but this one must not. > >Actually, it's slightly worse than that - it is necessary to >concatenate, according to this draft, but in order to determine >whether or not to concatenate, one must look at the purpose field >within the option. This is really an unacceptable plan - it >requires quite a bit of special complexity to support one option. see above > >Absent some good reason for doing this, which I don't see, we should >use a method that requires no extra complexity to implement. ok >What I would suggest is that you just have a length field for the URI >text, make the other stuff fixed-length (which it is anyway) and >allow multiple URIs to be represented in a single URI option. ok >In >general you don't *want* to send long URIs via DHCP - if the URI is >that long, it probably isn't going to fit in the DHCP packet. 255 (max for a single option) seems like a bit of a different than 576 (DHCP's message maximum) - unless Ive gotten the numbers revered >So it >would be very good to encourage shorter URIs, I can state this >and to forbid a URI to >be longer than 255 bytes. This is a bit more difficult as we cannot foresee the implementation usage that far into the future, can we? > In general I'm not big on encoding >limitations into specs, but in this case I think 255 bytes is plenty, How about a "...SHOULD NOT have URIs longer than 255..." >and it's easy enough to rewrite a URI to be shorter if you need to, >so I just don't see a lot of value in being flexible about long URIs >in DHCP packets. OK, but how about a compromise between what you have here, and what I had originally, like this: Go with this pseudo-format [code] [length] [purpose] [uri length] [uri text] [purpose] [uri length] [uri text] [etc] Say: "SHOULD NOT have URIs longer than 255" But: you MAY have a longer URI with the following (rough) rules: #1 - (all of 3396 applies) #2 - because of the difference between 255 and 576, allow more that one "purpose" group (meaning [purpose] [uri length] [uri text] ) in the same overall message, but this falls under the concatenation-required before processing rule of 3396 #3 - allow more URIs in their own "purpose" group ( [purpose] [uri length] [uri text] ) fill up the remaining bytes left in the message, not to exceed 2131 limits This will allow a URI to be up to 576 minus required bytes (which is still very large) while overcoming the 255 limit (which some have foreseen as "pushing it" in the future), and allowing more than one URI in the same message only if there is room. For example: [code] [length] [purpose=1] [200] [uri text] [purpose=1] [125] [uri text] [purpose=2] [180] [uri text] [purpose=7] [30] [uri text] This allows two URI fields (one of 200 bytes and one of 125 bytes) to be concatenated as one 325 byte URI (the primary PSAP URI), one 180 byte URI (the secondary PSAP) and one Geocoding URI of 30 bytes to be in the same DHCP message to the client. This makes 535 bytes of URIs plus 6 more bytes of overhead bytes = 541 bytes Is this concept acceptable? > I would make this option a concatenation-requiring >option (see RFC3396). > >So now if you have two URIs in an option, it would likely look like >this: > >[code] [length] [purpose] [uri length] [uri text] [purpose] [uri >length] [uri text] cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 15 15:39:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFzZb-0006VS-QD; Thu, 15 Sep 2005 15:39:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFzZZ-0006U3-9G; Thu, 15 Sep 2005 15:39:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00304; Thu, 15 Sep 2005 15:39:02 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFzeP-0002EI-O0; Thu, 15 Sep 2005 15:44:07 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 15 Sep 2005 12:38:21 -0700 X-IronPort-AV: i="3.97,114,1125903600"; d="scan'208"; a="342101868:sNHT965693498" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8FJcH4X019877; Thu, 15 Sep 2005 12:38:19 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Sep 2005 12:38:13 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Sep 2005 12:38:11 -0700 From: "Marc Linsner" To: "'James M. Polk'" Date: Thu, 15 Sep 2005 15:38:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW5dLaN0VyI7mkQSh6csVrk6ft3hgABF6jg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <4.3.2.7.2.20050914160915.0301adc8@email.cisco.com> Message-ID: X-OriginalArrivalTime: 15 Sep 2005 19:38:11.0993 (UTC) FILETIME=[02025890:01C5BA2D] X-Spam-Score: 1.1 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, 'ECRIT' Subject: [dhcwg] RE: draft-polk-dhc-uri-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org James, Thanks for your answer. My question was about the basis for your assertion that it is 'more appropriate' to perform location to psap uri mapping at host configuration setup time vs. emergency call setup time. I derive from your answer that your basis for this assertion is getting this task done prior to call setup, making call setup faster and possibly more reliable. More comments in-line.... > At 08:48 AM 9/14/2005 -0400, Marc Linsner wrote: > >James, > > > >Would you please provide the basis for your text below regarding the > >timing of psap determination, I can't seem to match it up > with any of > >the requirements within ecrit or geopriv. > > When something is urgent, do you want to invoke more > processing complexity or less processing complexity? More > typically means "more prone to errors", less typically means > "less prone to errors". No one can argue that simple is good, but there must be a balance with all requirements. > Everyone hear is assuming that the UA > providing location will get mapped to the appropriate PSAP > within a reasonable call set-up timeframe. This assumption is based on years of experience, it's the way things have work for 30+ years. There is every expectation of success in duplicating a like mechanism using Internet techologies. If that wasn't possible, we wouldn't be having this conversation as there would not be a PSTN-like capability on the Internet. > > This document suggests an optimization - to do the "mapping" > before time is wasted doing the mapping just to set-up the call. It is not clear such optimization is necessary. We don't have a 'failed' mechanism (yet). -Marc- > > The ECRIT Charter says: > > (item #1) "Successful delivery of an emergency service call > within those systems requires both an association of the > physical location of the originator with an appropriate > emergency service center and call routing to deliver the call > to the center." > > and > > (item #2) "Calls placed using Internet technologies do not > use the same systems to achieve those goals, and the common > use of overlay networks and tunnels (either as VPNs or for > mobility) makes meeting them more challenging. There are, > however, Internet technologies available to describe location > and to manage call routing. This working group will describe > when these may be appropriate and how they may be used." > > and > > (item #3) "The group will show how the availability of > location data and call routing information at different steps > in session setup would enable communication between a user > and a relevant emergency response center. " > > Item # 1 talks the association of user location and the > appropriate PSAP. > - This ID describes this by using the same Link > provider that knows the > UA's location (and give the UA its location. > > Item #2 talks about describing location and managing call > routing - specifically "when" these may be appropriate. > - This ID describes accomplishing this mapping > before call set-up. > - I don't remember reading a requirement in either > WG that says > "this mapping function MUST take place *only* during > call set-up". > > Item #3 talks about different information at different times > in the session set-up. > - This ID provides the Request-URI for the INVITE > message, plus provides > an alternate Request-URI, plus the URI of the ESGW and ESRP. > > SIP Proxies will determine if a route is available or not, > and reroute around any problems if there are any. A URI is > not an IP Address, of which there is one. The same URI can go > to many difference locations in times of overload or error. > Webservers have been doing this function for better than > 5 years now. > > > >"One example of this URI download would be one specifically > for the SIP > >or SIPS URI of the appropriate Public Safety Answer Point (PSAP) for > >the client when the user of that client calls for emergency > help (911 > >or 112-type of help). This is not a transaction that should > take place > >when a voice application wants to make such a critical call > set-up. It > >is more appropriate that this information be downloaded to > the client > >when the voice (or other) application boots up in case it is > needed at a later time." > > > >Thanks, > > > >-Marc- > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Sep 16 09:11:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGFzj-00084h-4k; Fri, 16 Sep 2005 09:11:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGFzf-00083P-Re; Fri, 16 Sep 2005 09:11:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15116; Fri, 16 Sep 2005 09:11:05 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGG4f-0005Wl-Pd; Fri, 16 Sep 2005 09:16:19 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 16 Sep 2005 06:10:57 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8GDAq4X025792; Fri, 16 Sep 2005 06:10:55 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 06:10:54 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 06:10:53 -0700 From: "Marc Linsner" To: "'James M. Polk'" Date: Fri, 16 Sep 2005 09:10:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW6wA8NEISDSVZ7QciL47vDe81Zpw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 16 Sep 2005 13:10:53.0731 (UTC) FILETIME=[1156B730:01C5BAC0] X-Spam-Score: 1.1 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, 'ECRIT' Subject: [dhcwg] draft-polk-dhc-uri-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org James, Can you expand on the following topics wrt uri purposes 1, 2, 4 in your draft.... 1) How does the dhcp server (or admin) derive the PSAP/ESGW uri(s)? 2) How can the PSAP effect a routing change, therefore a change to the PSAP/ESGW uri information that a particular dhcp server is passing on to it's clients (in support of the ecrit requirement that PSAPs control the routing db)? Thanks, -Marc- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Sep 16 10:35:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGHJZ-0007EJ-Re; Fri, 16 Sep 2005 10:35:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGHJY-0007Bj-1d for dhcwg@megatron.ietf.org; Fri, 16 Sep 2005 10:35:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20846 for ; Fri, 16 Sep 2005 10:35:41 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGHOX-0007t6-84 for dhcwg@ietf.org; Fri, 16 Sep 2005 10:40:56 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 16 Sep 2005 07:35:31 -0700 X-IronPort-AV: i="3.97,117,1125903600"; d="scan'208"; a="342335587:sNHT105235960" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8GEZMKG028927 for ; Fri, 16 Sep 2005 07:35:27 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 10:35:14 -0400 Received: from [161.44.65.139] ([161.44.65.139]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 10:35:14 -0400 Message-ID: <432AD813.5080900@cisco.com> Date: Fri, 16 Sep 2005 10:34:59 -0400 From: Mark Stapp User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [dhcwg] New ID for downloading URIs via DHCP References: <4.3.2.7.2.20050912223208.02e7b108@email.cisco.com> In-Reply-To: <4.3.2.7.2.20050912223208.02e7b108@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Sep 2005 14:35:14.0407 (UTC) FILETIME=[D9BC9770:01C5BACB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org James, this proposal binds this ECRIT/geo data pretty tightly to dhcp configuration. the entire catalogue of 'purposes' is exposed in the option, and in the dhcp configuration details. is that really desirable? to me, it seems as if this data is pretty domain-specific, and coupling it so tightly to dhcp could be a limitation going forward. 1. adding, deprecating, or changing a 'purpose' means another interaction with dhcp or iana. 2. as proposed, some entities have to get this information via dhcp. are there other entities in a real system who will have to get the same data some other way? if some of the parts of a system have to get critical data by dhcp, and some other parts have to be configured some other way, it becomes harder for the whole system to undergo coordinated changes. could that be an issue? 3. getting an initial version of this info to dhcp clients will be easy. but there's no good way to signal clients if there are changes. the clients can only find out if something changes as they renew, and the dhcp server of course doesn't control that very tightly, without resorting to micro lease times anyway. would it be more useful to the ecrit or geo folks if dhcp were used to tell client about some other server or point of contact where the client could learn this information? that would de-couple this info from dhcp and the dhcp protocol, and make it possible to change what info is distributed and to signal changes independently of dhcp interactions (and limitations). my apologies if this has already been resolved on one of the other lists. Regards, Mark James M. Polk wrote: > DHC WG > > To let folks know - a new individual submission Internet Draft has > been announced regarding using DHCP for downloaded (or requesting for, > then downloading) URIs to a DHC client here: > > http://www.ietf.org/internet-drafts/draft-polk-dhc-uri-00.txt > > with this abstract > > This document defines a new Dynamic Host Configuration Protocol > (DHC) Option to allow one or more URIs to be transmitted from a > server to a client within one or more messages, and for one or more > URIs, each with a unique purpose, to be specifically requested by a > client of a server. Included in this Option is a purpose field to > identify the type of URI being requested by the client, or the type > of URI in the DHCP message from the server. > > Of interest, I hope, to the DHC WG is that this proposed Option > requests the use of a single DHCP Option to be used for URIs of > multiple purposes, each identified by a sub-option code called a > "purpose". This is done a little differently than in RFC 3396 where > the sub-options are smaller. I don't believe I violated any length > rules of 2131 or 3396, and I believe I articulate how to address > lengths and concatenation in this document for longer URIs, and for > how to include more than one URI - each of a different purpose - in > the same DHCP message, or in the same IP datagram (with the same > Option value - but different purposes). > > The focus of the proposed URIs are primarily surrounding the Geopriv > and ECRIT WGs > > There are 11 URIs currectly defined in this ID (acronym explosion and > definitions are in the ID): > > Purpose = 1 (Primary PSAP URI) > Purpose = 2 (Secondary PSAP URI) > Purpose = 3 (Location By-Reference of Client) > Purpose = 4 (ESGW URI of Client) > Purpose = 5 (ESRP URI of Client) > Purpose = 6 (Organization Providing Location for Client) > Purpose = 7 (URI of Geocoding/Reverse Geocoding) > Purpose = 8 (Primary URI of Geo Mapping Service) > Purpose = 9 (Secondary URI of Geo Mapping Service) > Purpose = 10 (Primary URI of Civic Mapping Service) > Purpose = 11 (Secondary URI of Civic Mapping Service) > > Others can be added based on consensus discussion of this document > > I just spoke with the Ralph Droms, and open discussion of this ID on > the ECRIT list is fine with him. The formal syntax and encoding of > the option proposal is to be discussed on the DHC list for those > interested here, but the URI meanings don't need to be discussed on > this list where emergency calling and location conveyance/conversion > is of fairly little concern, as ECRIT is the primary WG of interest > for this effort initially. > > That said, newly proposed URIs with completely different purposes can > be included in this document. I am not suggesting a limitation (other > than the one byte purpose length field of 255 ;-) > > BTW - I have no range set aside for private purposes. Is this needed? > > Reviews and comments are appreciated > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented. > > _______________________________________________ > 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-bounces@ietf.org Mon Sep 19 13:15:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHPF4-0007uc-Fb; Mon, 19 Sep 2005 13:15:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHPF2-0007uU-2b for dhcwg@megatron.ietf.org; Mon, 19 Sep 2005 13:15:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08360 for ; Mon, 19 Sep 2005 13:15:40 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHPKg-0006L8-2M for dhcwg@ietf.org; Mon, 19 Sep 2005 13:21:35 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 Sep 2005 13:15:34 -0400 X-IronPort-AV: i="3.97,123,1125892800"; d="scan'208"; a="70854148:sNHT31464784" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8JHEuTe006577; Mon, 19 Sep 2005 13:15:31 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 13:15:24 -0400 Received: from 10.86.241.40 ([10.86.241.40]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 Sep 2005 17:15:24 +0000 Received: from localhost.localdomain by email.cisco.com; 19 Sep 2005 13:15:28 -0400 From: Ralph Droms To: DHCP discussion list In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 19 Sep 2005 13:15:27 -0400 Message-Id: <1127150128.9688.68.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) X-OriginalArrivalTime: 19 Sep 2005 17:15:24.0842 (UTC) FILETIME=[B93DD8A0:01C5BD3D] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: Ted Hardie , Scott Hollenbeck , Margaret Wasserman , "W.MarkTownsley" , Stig Venaas , andy@hxr.us Subject: [dhcwg] Re: I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Following up on the announcement of the publication of draft-ietf- geopriv-dhcp-civil-07.txt, which John Schnizlein forwarded to the mailing list, the -04 revision of this draft was reviewed by the dhc WG several months ago, in a joint last call with the geopriv WG. The draft was then submitted to the IESG. draft-ietf-geopriv-dhcp-civil-07.txt includes changes in response to comments received during the IESG review. Because this specification involves DHCP, the dhc WG has an opportunity for a final review of the draft. Accordingly, if you have any comments about the draft, please respond by 1700EDT on Thu, 9/22. I will forward any responses to the IESG and the geopriv WG chairs. I prepared a diff of the -04 and -07 versions, but haven't sent it with this announcement because it's about 200KB (using side-by-side rfcdiff tool). Let me know if you'd like me to send you an individual copy. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 19 13:17:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHPGV-0008Jc-Hp; Mon, 19 Sep 2005 13:17:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHPGS-0008Id-Oq for dhcwg@megatron.ietf.org; Mon, 19 Sep 2005 13:17:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08463 for ; Mon, 19 Sep 2005 13:17:09 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHPM5-0006NA-EW for dhcwg@ietf.org; Mon, 19 Sep 2005 13:23:04 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8JHGiIr021833; Mon, 19 Sep 2005 10:16:44 -0700 (PDT) Received: from [192.168.1.4] (carbuncle.qualcomm.com [129.46.225.108]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8JHGeoY020795; Mon, 19 Sep 2005 10:16:41 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <1127149927.9688.62.camel@localhost.localdomain> References: <1127149927.9688.62.camel@localhost.localdomain> Date: Mon, 19 Sep 2005 10:16:39 -0700 To: Ralph Droms , DHCP discussion list From: Ted Hardie Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ithilien.qualcomm.com id j8JHGiIr021833 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: Margaret Wasserman , "W.MarkTownsley" , Scott Hollenbeck , Stig Venaas , andy@hxr.us Subject: [dhcwg] Re: I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Thanks to Ralph for forwarding this to the group. There may be a further= revision, however, as David Kessens still has an outstanding discuss which is not y= et resolved. David has agreed to update the discuss text to indicate more c= learly the points of discussion but has not yet done so. Until that is complete= , it is not clear whether further changes to this aspect of the document will be = requested. Your review of this draft is, of course, appreciated, but please be aware= that there may be a second request. regards, Ted Hardie At 1:12 PM -0400 9/19/05, Ralph Droms wrote: >Following up on the announcement of the publication of draft-ietf- >geopriv-dhcp-civil-07.txt, which John Schnizlein forwarded to the >mailing list, the -04 revision of this draft was reviewed by the dhc WG >several months ago, in a joint last call with the geopriv WG. The draft >was then submitted to the IESG. draft-ietf-geopriv-dhcp-civil-07.txt >includes changes in response to comments received during the IESG >review. Because this specification involves DHCP, the dhc WG has an >opportunity for a final review of the draft. Accordingly, if you have >any comments about the draft, please respond by 1700EDT on Thu, 9/22. I >will forward any responses to the IESG and the geopriv WG chairs. > >I prepared a diff of the -04 and -07 versions, but haven't sent it with >this announcement because it's about 200KB (using side-by-side rfcdiff >tool). Let me know if you'd like me to send you an individual copy. > >- Ralph > > > >Attachment converted: Macintosh HD:geopriv-dhcp-diff 1.html (TEXT/=ABIC=BB= ) (0033FA45) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 19 19:55:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHVU2-00007x-1N; Mon, 19 Sep 2005 19:55:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHVU0-00007n-BQ for dhcwg@megatron.ietf.org; Mon, 19 Sep 2005 19:55:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08967 for ; Mon, 19 Sep 2005 19:55:34 -0400 (EDT) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHVZh-0001vp-PL for dhcwg@ietf.org; Mon, 19 Sep 2005 20:01:31 -0400 Received: from cacexg12.americas.cpqcorp.net (cacexg12.americas.cpqcorp.net [16.92.1.72]) by palrel11.hp.com (Postfix) with ESMTP id DCA975139A for ; Mon, 19 Sep 2005 16:55:30 -0700 (PDT) Received: from cacexc06.americas.cpqcorp.net ([16.92.1.28]) by cacexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 16:54:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Sep 2005 16:54:48 -0700 Message-ID: <00F4781551324E47A32BAF37B6E420B50282EBBA@cacexc06.americas.cpqcorp.net> Thread-Topic: FQDN internet drafts Thread-Index: AcWy/R7SP0nktM1YQMqBbqlCSPtNDQA+ZfDg From: "Borz, John (IPG-Roseville R&D)" To: X-OriginalArrivalTime: 19 Sep 2005 23:54:48.0730 (UTC) FILETIME=[84D4F7A0:01C5BD75] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] FQDN internet drafts X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org =20 Hello, Looks like these internet drafts have expired. Are there plans to update them? http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-10.txt http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-fqdn-02.txt thanks, John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 19 20:15:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHVnQ-0006Qx-RX; Mon, 19 Sep 2005 20:15:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHVnO-0006QW-Gj; Mon, 19 Sep 2005 20:15:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09991; Mon, 19 Sep 2005 20:15:36 -0400 (EDT) From: volz@cisco.com Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHVt6-0002Se-82; Mon, 19 Sep 2005 20:21:33 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 19 Sep 2005 17:15:28 -0700 X-IronPort-AV: i="3.97,124,1125903600"; d="scan'208"; a="660634630:sNHT30618166" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8K0F758008613; Mon, 19 Sep 2005 17:15:23 -0700 (PDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 20:15:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] FQDN internet drafts Date: Mon, 19 Sep 2005 20:15:21 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB219AFE34@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] FQDN internet drafts Thread-Index: AcWy/R7SP0nktM1YQMqBbqlCSPtNDQA+ZfDgAmA9hNA= To: , , "Stig Venaas" X-OriginalArrivalTime: 20 Sep 2005 00:15:24.0257 (UTC) FILETIME=[65436D10:01C5BD78] X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, "Borz, John \(IPG-Roseville R&D\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Perhaps we can get these 2 drafts and draft-ietf-dnsext-dhcid-rr-09.txt back as they have passed WG Last Call and are just waiting for the Conflict Resolution draft (http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-resolution-10.t xt) to be set to the IESG -- an I believe that draft is ready to go so hopefully the entire package can go (Ralph/Stig?)? It would be nice to finish up this work (barring IESG comments). - Bernie=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Borz, John (IPG-Roseville R&D) > Sent: Monday, September 19, 2005 7:55 PM > To: dhcwg@ietf.org > Subject: [dhcwg] FQDN internet drafts >=20 > =20 > Hello, >=20 > Looks like these internet drafts have expired. Are there plans to > update them? >=20 > http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-10.txt > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-fqdn-02.txt >=20 > thanks, > John >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 20 15:21:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHnfw-0001lD-D6; Tue, 20 Sep 2005 15:21:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHnfu-0001ky-4N for dhcwg@megatron.ietf.org; Tue, 20 Sep 2005 15:21:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25194 for ; Tue, 20 Sep 2005 15:21:01 -0400 (EDT) Received: from [32.97.110.152] (helo=e34.co.us.ibm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHnlj-0007L1-HH for dhcwg@ietf.org; Tue, 20 Sep 2005 15:27:08 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id j8KJJYx5021187 for ; Tue, 20 Sep 2005 15:19:34 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8KJKqOt518892 for ; Tue, 20 Sep 2005 13:20:52 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j8KJKqnq016689 for ; Tue, 20 Sep 2005 13:20:52 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-238-95.mts.ibm.com [9.65.238.95]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j8KJKpkL016637; Tue, 20 Sep 2005 13:20:51 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j8KJKogM023254; Tue, 20 Sep 2005 15:20:50 -0400 Message-Id: <200509201920.j8KJKogM023254@cichlid.raleigh.ibm.com> To: Stig Venaas Subject: Re: [dhcwg] bcmc status and issues In-Reply-To: Message from Stig Venaas of "Mon, 12 Sep 2005 21:15:28 +0200." <20050912191528.GD4793@storhaugen.uninett.no> Date: Tue, 20 Sep 2005 15:20:50 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org FWIW, I've been fairly heavily involved in the changes leading to -02. I had a number of review comments on -01 that got put into -02. -03 is in response to the IESG comments. Modulo the issues that were raised on the -02 draft during IESG review, I think this document is ready to go. (I'll comment on those issues separately.) Indeed, 3GPP2 needed this some time ago, so it would really be good to get closure and move on. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 20 15:51:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHo9a-0001n3-Lj; Tue, 20 Sep 2005 15:51:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHo9Z-0001mq-7F for dhcwg@megatron.ietf.org; Tue, 20 Sep 2005 15:51:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27039 for ; Tue, 20 Sep 2005 15:51:40 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHoFQ-00088s-5c for dhcwg@ietf.org; Tue, 20 Sep 2005 15:57:48 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j8KJpFYY017334 for ; Tue, 20 Sep 2005 15:51:15 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8KJpT2T094666 for ; Tue, 20 Sep 2005 15:51:29 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j8KJpTdn006320 for ; Tue, 20 Sep 2005 15:51:29 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-238-95.mts.ibm.com [9.65.238.95]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j8KJpSwO006252; Tue, 20 Sep 2005 15:51:28 -0400 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j8KJpRsq024629; Tue, 20 Sep 2005 15:51:27 -0400 Message-Id: <200509201951.j8KJpRsq024629@cichlid.raleigh.ibm.com> To: Stig Venaas Subject: Re: [dhcwg] Further comments from Elwyn In-Reply-To: Message from Stig Venaas of "Mon, 12 Sep 2005 21:08:09 +0200." <20050912190809.GB4793@storhaugen.uninett.no> Date: Tue, 20 Sep 2005 15:51:27 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org > I just had a long chat with one of the authors outside the DHC wg meeting. > It appears that the situation is as follows (please correct me if I > am wrong): > - A mobile has no other way of finding out the domain name of the > place(s) where broadcast servers can be found and hence may well > need a DHCP/DHCPv6 option to find the domain name to locate its > server(s). That is consistent with my understanding, indeed, that is the general reason for using DHC to provide clients with DNS names... > - It is not clear to me even after the discussion whether more than > one domain name is needed - the 3GPP2 architecture allows the server > to be either in the visited domain or the home domain (although the > wording in the BCMCS document refers to the access network in a way > that I would interpret as the access network that the mobile is > using at that moment). This seems to imply to me that the network > operator has a choice to offer one or the other but the mobile has > to take what it is given. WHETHER OR NOT THIS IS THE CASE (BOTH) > DOCUMENTS NEED TO BE IMPROVED to explain what is going on. I'm not entirely convinced that support for more than one DNS name is needed, but I am not willing to block the document on this point. To some degree, if the customers of this work want it, let them have it. They seem to say so (and I pushed on this issue when I reviewed the -01 document). I'll also note that there is precendent in other RFCs for this. E.g., in the case of SIP, see RFC 3263 & 3361. Finally, when I raised the general issue about multiple DNS SRV names to DNS folk, I couldn't get anyone very excited about arguing it shouldn't be done. So, at this point, I think its time to move on w.r.t. this topic. > - The authors believe that they have been told that there is no > longer a shortage of DHCP options (due to the extension mechanism) > so that requesting two options is not a problem. That is my understanding. > - If multiple domain names/addresses can be offered, the logic for > determining which one of them the client should select needs to be > specified in such a way that it can be implemented algorithmically > and deterministically - as Brian writes below and others commented > in the meeting, the new wording in v3 is unsatisfactory. The v2 > wording was better and acceptable to me (it reflects the > corresponding sip wording). I tend to agree. In -02, the algorithm was "use them in order, and only use the next one if the SRV algorithm for the previous name fails". That is clear in terms of what to implement. However, I understand that this probably doesn't mesh well with an operator advertising multiple services who hopes the client intelligently picks one. Unfortunately, the wording in -03 leaves the client algorithm pretty much unspecified. > - If two DHCP options are used: > - If extension codes are used, then the new options will only work with > servers that support extension codes. > - The text in 4.5 and 4.6 has to be upgraded to explain how to decide whether > to send address or FQDN replies for DHCP in the same way as it is explained > for DHCPv6 currently. > - If only one option is to be used, then 4.5 and 4.6 need to be revised to > remove text about the alternatives. I see no reason not to use separate options, per above. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 20 16:00:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHoHh-0003Sf-8I; Tue, 20 Sep 2005 16:00:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHoHf-0003Rw-GP for dhcwg@megatron.ietf.org; Tue, 20 Sep 2005 16:00:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28134 for ; Tue, 20 Sep 2005 16:00:05 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHoNT-0000HW-IB for dhcwg@ietf.org; Tue, 20 Sep 2005 16:06:12 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 20 Sep 2005 15:59:53 -0400 X-IronPort-AV: i="3.97,127,1125892800"; d="scan'208"; a="71051186:sNHT30088532" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8KJxUR1022619; Tue, 20 Sep 2005 15:59:51 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 15:59:33 -0400 Received: from 161.44.65.238 ([161.44.65.238]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Sep 2005 19:59:33 +0000 Received: from dhcp-guest-bxb22-64-102-164-29.cisco.com by email.cisco.com; 20 Sep 2005 19:59:38 +0000 Subject: Re: [dhcwg] bcmc status and issues From: Ralph Droms To: Thomas Narten In-Reply-To: <200509201920.j8KJKogM023254@cichlid.raleigh.ibm.com> References: <200509201920.j8KJKogM023254@cichlid.raleigh.ibm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 20 Sep 2005 15:59:37 -0400 Message-Id: <1127246378.9190.41.camel@dhcp-guest-bxb22-64-102-164-29.cisco.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) X-OriginalArrivalTime: 20 Sep 2005 19:59:33.0511 (UTC) FILETIME=[D1EB3970:01C5BE1D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Stig Venaas X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Stig posted e-mail to the dhcwg mailing list a few days ago with some outstanding issues: http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05371.html He also posted a status summary from Kuntal: http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05370.html I also have a specific comment about one of Kuntal's comment: Comment #6: =========== "s4.5/4.6: Now that there are two separate options for IPv4, all the stuff in 4.5 and 4.6 which just talks about v6 needs to be duplicated for v4." Response: --------- Nope...DHCPv4 and DHCPv6 protocols do not work in the same fashion. There is no such thing as ORO in DHCPv4. Besides, s4.6 talks about IPv4 options. Change made: None. ----------- There is, in fact, the equivalent of the DHCPv6 ORO is the DHCPv4 "Parameter Request List" (code 55). - Ralph On Tue, 2005-09-20 at 15:20 -0400, Thomas Narten wrote: > FWIW, I've been fairly heavily involved in the changes leading to > -02. I had a number of review comments on -01 that got put into -02. > > -03 is in response to the IESG comments. > > Modulo the issues that were raised on the -02 draft during IESG > review, I think this document is ready to go. (I'll comment on those > issues separately.) > > Indeed, 3GPP2 needed this some time ago, so it would really be good to > get closure and move on. > > 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-bounces@ietf.org Tue Sep 20 16:00:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHoIU-0003fb-9w; Tue, 20 Sep 2005 16:00:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHoIS-0003fN-Au for dhcwg@megatron.ietf.org; Tue, 20 Sep 2005 16:00:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28314 for ; Tue, 20 Sep 2005 16:00:54 -0400 (EDT) Received: from [32.97.110.149] (helo=e31.co.us.ibm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHoOK-0000LL-9a for dhcwg@ietf.org; Tue, 20 Sep 2005 16:07:01 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id j8KK0T7x031222 for ; Tue, 20 Sep 2005 16:00:29 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8KK0jOt536892 for ; Tue, 20 Sep 2005 14:00:45 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j8KK0jib019898 for ; Tue, 20 Sep 2005 14:00:45 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-238-95.mts.ibm.com [9.65.238.95]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j8KK0ikg019868; Tue, 20 Sep 2005 14:00:45 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j8KK0gLv024689; Tue, 20 Sep 2005 16:00:43 -0400 Message-Id: <200509202000.j8KK0gLv024689@cichlid.raleigh.ibm.com> To: Stig Venaas Subject: Re: [dhcwg] bcmc status mail from Kuntal Chowdhury In-Reply-To: Message from Stig Venaas of "Mon, 12 Sep 2005 21:12:02 +0200." <20050912191202.GC4793@storhaugen.uninett.no> Date: Tue, 20 Sep 2005 16:00:42 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org More on multiple DNS names in the option: > Response: > --------- > I don't get it. What is the problem if more than one domain name is > allowed in the option? The basic issue is that SRV is intended to do away with the need for "multiple names". I.e., one SRV name returns you a list of servers you can try contacting. So you don't need multiple names. Allowing multiple SRV names raises the question of which name do you pick? What algorithm should the client use when selecting a server to try and contact? You can't "merge" the two names and let the client try them both. That doesn't really make sense in the SRV context. And if the client isn't implementing an algorithm with predictable behavior when multiple names are provided, an operator probably won't be happy with the results of advertising multiple DNS names. Hence, the details really do matter! What it sounds like is wanted is a way for the server to advertise multiple names, and an intelligent client that has some other knowledge that helps it pick the service it wants. But the document says nothing about that. Also, if the client is preconfigured with "prefered BCMC servers" it should use, that sort of (though not entirely) begs the question of why a DHC option is needed in the first place. I.e., just try looking up the SRV record for the "preconfigured" service. What more is needed? :-) > If the operator has no partnership such as MVNO, > there will be one domain name returned. If the operator supports MVNOs > (BTW most of the 3G wireless operators in North America do) they will > provision different domain names for its own BCMCS service and for that > of the MVNOs e.g. operator.com; mvno1.com, mvno2.com etc. Based on the > user's preference (setting) in the BCMCS client, it may choose to use > one of the domain names to fetch the appropriate BCMCS controller > address. This is the missing info. The current document say nothing about this being either possible or the intended usage. I'd feel better if something about the above went into the document. > If no preferred domain name is found in the list, the client > may use a default setting e.g. use the first one in the list. BTW, the > client setting should be controlled by the user; this document should > not mandate any particular behavior, IMHO. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 21 16:43:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIBQy-0005AU-9Z; Wed, 21 Sep 2005 16:43:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIBQu-00059s-AN; Wed, 21 Sep 2005 16:43:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28171; Wed, 21 Sep 2005 16:43:10 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIBX0-0001L9-6n; Wed, 21 Sep 2005 16:49:30 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8LKgSn25232; Wed, 21 Sep 2005 13:42:28 -0700 (PDT) Message-Id: <200509212042.j8LKgSn25232@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 21 Sep 2005 13:42:28 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] RFC 4174 on The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4174 Title: The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service Author(s): C. Monia, J. Tseng, K. Gibbons Status: Standards Track Date: September 2005 Mailbox: charles_monia@yahoo.com, joshtseng@yahoo.com, kevin.gibbons@mcdata.com Pages: 13 Characters: 29485 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-isnsoption-13.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4174.txt This document describes the Dynamic Host Configuration Protocol (DHCP) option to allow Internet Storage Name Service (iSNS) clients to discover the location of the iSNS server automatically through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) 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 to that of a storage area network. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. 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. 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: <050921134116.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4174 --OtherAccess Content-Type: Message/External-body; name="rfc4174.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050921134116.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Thu Sep 22 01:44:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIJsI-0002UO-BW; Thu, 22 Sep 2005 01:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIJsE-0002Q0-0y for dhcwg@megatron.ietf.org; Thu, 22 Sep 2005 01:44:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24692 for ; Thu, 22 Sep 2005 01:43:54 -0400 (EDT) Received: from [207.47.106.194] (helo=ixca-ex1.ixiacom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIJyL-0005rg-GP for dhcwg@ietf.org; Thu, 22 Sep 2005 01:50:18 -0400 Received: by ixca-ex1.ixiacom.com with Internet Mail Service (5.5.2657.72) id ; Wed, 21 Sep 2005 22:43:38 -0700 Message-ID: From: Soumava Das To: dhcwg@ietf.org Date: Wed, 21 Sep 2005 22:43:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Subject: [dhcwg] Query regarding DHCPREQUEST time windows X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1539382335==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org 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. --===============1539382335== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5BF38.936395EB" 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_01C5BF38.936395EB Content-Type: text/plain Hello Evrybody, I need clarifications regarding the time windows for the DHCPREQUEST messages. 1. DHCPREQUEST (from INIT_REBOOT state): The RFC says this message is send by the client to verify a previously allocated, cached configuration. So, can such a message be send after the lease period has expired (and the client is aware of this fact)? 2. DHCPREQUEST (from RENEWING state): Can such a message be send after the expiry of the T2 time? Is it a RFC violation if the message is send after the T2 expiry? It seems neither the Windows 2003 DHCP server or ISC dhcpd really cares. 3. DHCPREQUEST (from REBINDING state): Can such a message be send before T2 expiry? RFC does not clarify this point. It only mentions that the clients may extent or renew the lease before T1 expiry. I would be grateful if someone can provide a clarification on the above issues. Regards, Soumava ------_=_NextPart_001_01C5BF38.936395EB Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Hello Evrybody,

         = ;   I need clarifications regarding the time windows for the DHCPREQUEST messages.

 

  1. DHCPREQUEST (from = INIT_REBOOT state): The RFC says this message is send by the client to verify = a previously allocated, cached configuration. So, can such a message be send after the lease period has = expired (and the client is aware of this fact)?

 

  1. DHCPREQUEST (from = RENEWING state): Can such a message be = send after the expiry of the T2 time? Is it a RFC violation if the = message is send after the T2 expiry? It seems neither the Windows 2003 = DHCP server or ISC dhcpd really cares.

 

  1. DHCPREQUEST (from = REBINDING state): Can such a message be = send before T2 expiry? RFC does not clarify this point. It only = mentions that the clients may extent or renew the lease before T1 = expiry.

 

 

I would = be grateful if someone can provide a clarification on the above = issues.

 

Regards,

Soumava

------_=_NextPart_001_01C5BF38.936395EB-- --===============1539382335== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1539382335==-- From dhcwg-bounces@ietf.org Thu Sep 22 10:09:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIRlc-0000cs-NK; Thu, 22 Sep 2005 10:09:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIRlZ-0000cE-9D for dhcwg@megatron.ietf.org; Thu, 22 Sep 2005 10:09:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02043 for ; Thu, 22 Sep 2005 10:09:35 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIRrn-00028i-9A for dhcwg@ietf.org; Thu, 22 Sep 2005 10:16:04 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 22 Sep 2005 07:09:25 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8ME8c59013279; Thu, 22 Sep 2005 07:09:22 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 07:09:21 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 07:09:20 -0700 From: "Marc Linsner" To: "'James M. Polk'" , "'Andrew Newton'" Date: Thu, 22 Sep 2005 10:09:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcW+qEKJhK612bWESJaS0weyYgCQ3gACL1bAADOBhMA= Message-ID: X-OriginalArrivalTime: 22 Sep 2005 14:09:20.0712 (UTC) FILETIME=[3A240C80:01C5BF7F] X-Spam-Score: 1.1 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: [dhcwg] FW: draft-polk-dhc-uri-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org What is the incentive for a dhcp operator to take on the responsibility of emergency call routing? One can think of several disincentives (liability)! 1) It is common knowledge that routing of an emergency call requires knowing the location of the caller. 2) The 2nd best entity to know this location information is the access (layer 2) provider. 3) RFC 3825 & Geopriv's civil lci draft are simply *one* mechansim for the L2 provider to advise the end device of this location information. 4) Until now, it has been accepted knowledge that the entity offering a 'telephony' service should be responsible for such service working properly, including accuracy of call routing. -Marc- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 22 15:02:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIWLQ-00056q-8S; Thu, 22 Sep 2005 15:02:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIWLM-00055G-0w for dhcwg@megatron.ietf.org; Thu, 22 Sep 2005 15:02:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17901 for ; Thu, 22 Sep 2005 15:02:49 -0400 (EDT) Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIWRY-0001Oa-8X for dhcwg@ietf.org; Thu, 22 Sep 2005 15:09:21 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1EIWJS-0008KN-1P for dhcwg@ietf.org; Thu, 22 Sep 2005 21:00:56 +0200 Received: from 216.191.74.170 ([216.191.74.170]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Sep 2005 21:00:54 +0200 Received: from mcr by 216.191.74.170 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Sep 2005 21:00:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: dhcwg@ietf.org From: Michael Richardson Date: Thu, 22 Sep 2005 14:27:00 -0400 Lines: 98 Message-ID: References: <6.2.1.2.2.20050922112954.06cddd40@mail.binhost.com> Mime-Version: 1.0 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 216.191.74.170 User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.17 (Jumbo Shrimp, linux) Cancel-Lock: sha1:+Zae8SOc2qg+hb622MSNfq6BlLc= X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ipsec@lists.tislabs.com.cnri.reston.va.us Subject: [dhcwg] Re: Authentication of DHCP Relay Agent Options Using IPsec X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1690560739==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1690560739== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >>>>> "Russ" =3D=3D Russ Housley writes: Russ> The following document is on the agenda for the IESG telechat next Russ> week for approval as a Proposed Standard. I would appreciate Russ> review from the members of this mail list in the next week. Russ> Authentication of DHCP Relay Agent Options Using IPsec Russ> draft-ietf-dhc-relay-agent-ipsec-02.txt I think that I read this some time ago and commented about lack of clear statement about how to do the keying. I have re-read it, and I still find the key management section too unclea= r: > 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 does not provide defense against replayed > messages. Accordingly, if replay protection is required, > IKE [4] with preshared secrets must be used. IKE with > public keys may be used. Are replays an issue? I think that threat model said clearly that they were, so it seems to me that IKE "MUST" be used. I would like to see more clear statement about how to use IKE. In particular, I think the DHCP relay agents are rather small boxes, and so the full complexity of IKE is probably not desireable. My suggestions are: 1) support IKE main mode only, and cookie-mode of IKEv2. 2) support PSK authentication only. This works fine with MainMode in IKEv1 if your DHC relays are at known, non-changing addresses.=20 (If that isn't the case, please say so. I can think of situations where it might not be the case) 3) I suggest modp1024 and modp1536 be supported. This is clearly easy to upgrade if you stick to mainmode, but if you decide you need aggressive mode, you have to pick one mode only. 4) the relay does not need to support NAT-T, DPD, xauth, modecfg. 5) in IKEv2, the relay does not need to support simultaneous SAs with the same selectors. 6) phase 1 IDs of ID_IPV4_ADDR or ID_IPV6_ADDR will be supported. phase 2 IDs of ID_IPV4_ADDR (vs ID_IPV4_ADDR_RANGE with /32) will be supported.=20 7) You said transport mode already. Is fragmentation supported? Remember that the relay is adding stuff, and then you get to add ESP.=20 8) please recommend IKEv1 lifetimes, since they are not negotiated, and a mis-match still causes failure in many devices. (IKEv2 does not have this problem) 9) The agent will support a PSK of between 16 and 64 bytes, and will accept hex (0x) and base64 (0s) encoded strings for entering the PSK in its' admin interface. This will encourage stronger PSKs and you won't find yourself in situation where you can only type a printable phrase. A 3-4 character hash of the PSK will be generated at each end to aid in confirming that the PSK has been entered correctly. =20=20=20=20=20=20=20=20 I think that #6 is critical to specify if you actually want this security feature turned on during deployment. =2D-=20 ] ON HUMILITY: to err is human. To moo, bovine. | firewall= s [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net archit= ect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device dri= ver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"= ); [ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iQCVAwUAQzL3fIqHRg3pndX9AQFcmAP5AYtGPcRdL7AuJiyGCvaV/7198D1ZMyzJ Zl8r+pLDXo7TQq6YQbuXKv+cKYhOGvGhLJVvfYeLyHNycs4ZAfo5WkeT1ZSXscV0 qbPIWyg19SjE7Ye4NsmaPJpWfx26lPVp3jDQDV909X+dMVjDUY/FpfaVQfGXmvQd dmwOZfhhur8= =Izgg -----END PGP SIGNATURE----- --=-=-=-- --===============1690560739== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1690560739==-- From dhcwg-bounces@ietf.org Thu Sep 22 15:52:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIX75-0002FS-Sq; Thu, 22 Sep 2005 15:52:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIX75-0002FN-C5 for dhcwg@megatron.ietf.org; Thu, 22 Sep 2005 15:52:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22764 for ; Thu, 22 Sep 2005 15:52:08 -0400 (EDT) Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIXDL-00034s-Sg for dhcwg@ietf.org; Thu, 22 Sep 2005 15:58:41 -0400 Received: from openexchange.incognito.com ([192.168.77.70]) by chimera.incognito.com with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EIX6h-0000ct-NY; Thu, 22 Sep 2005 12:51:52 -0700 Received: from [192.168.75.75] (unknown [192.168.75.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by openexchange.incognito.com (Postfix) with ESMTP id 12C9D19208; Thu, 22 Sep 2005 12:33:06 -0700 (PDT) Message-ID: <433303CA.1040102@openexchange.incognito.com> Date: Thu, 22 Sep 2005 12:19:38 -0700 From: Andre Kostur Organization: Incognito Software Inc. User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soumava Das Subject: Re: [dhcwg] Query regarding DHCPREQUEST time windows References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -5.9 (-----) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Soumava Das wrote: > Hello Evrybody, > > I need clarifications regarding the time windows for the > DHCPREQUEST messages. > > > > 1. DHCPREQUEST (from INIT_REBOOT state): The RFC says this message > is send by the client to verify a previously allocated, cached > configuration. So, *can such a message be send after the lease > period has expired* (and the client is aware of this fact)? > No. INIT-REBOOT is for when the client "knows" that its lease is still valid, but wishes to verify. If the client "knows" that its lease has expired, it should use a Discover. > > > 2. DHCPREQUEST (from RENEWING state): *Can such a message be send > after the expiry of the T2 time?* Is it a RFC violation if the > message is send after the T2 expiry? It seems neither the > Windows 2003 DHCP server or ISC dhcpd really cares. > I don't see why not. Although it's really for the client's benefit that they change from unicast to broadcast at T2. (OK, I'm assuming that you're asking about sending a unicast Request after T2...) > > > 3. DHCPREQUEST (from REBINDING state): *Can such a message be send > before T2 expiry?* RFC does not clarify this point. It only > mentions that the clients may extent or renew the lease before > T1 expiry. > I'm not sure which type of Request you're talking about in this one. Unicast or Broadcast? In either case, I don't see why not. It would probably be "rude" behaviour to ignore the T1/T2 sent by the server, but almost everything in DHCP is unsolicited anyway.... _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 22 23:58:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIehI-0003yb-ER; Thu, 22 Sep 2005 23:58:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIehG-0003xM-9D for dhcwg@megatron.ietf.org; Thu, 22 Sep 2005 23:58:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04329 for ; Thu, 22 Sep 2005 23:57:59 -0400 (EDT) From: somenath.pal@wipro.com Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIenZ-0000hx-JJ for dhcwg@ietf.org; Fri, 23 Sep 2005 00:04:37 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 5EF33205E3 for ; Fri, 23 Sep 2005 09:16:10 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 42032205E0 for ; Fri, 23 Sep 2005 09:16:10 +0530 (IST) Received: from BLR-EC-MBX03.wipro.com ([10.201.50.161]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Sep 2005 09:27:46 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 Sep 2005 09:27:10 +0530 Message-ID: <8EFA81424BDADF4EB943E5A53420D7E3871B51@BLR-EC-MBX03.wipro.com> Thread-Topic: How to reload dhcpd.conf with out stopping/starting dhcpd Thread-Index: AcW/8t/di7jzQ0YhQXCV4lavFw7UrA== To: X-OriginalArrivalTime: 23 Sep 2005 03:57:46.0661 (UTC) FILETIME=[F531F550:01C5BFF2] X-Spam-Score: 0.4 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Subject: [dhcwg] How to reload dhcpd.conf with out stopping/starting dhcpd X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0498257899==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0498257899== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5BFF2.F5165238" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5BFF2.F5165238 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 I need to write program which will configure dhcp server.But I need to make this configuration changes effective with out restarting the dhcpd. Can any body help me. =20 Thanks. Regards, Somenath =20 =20 =20 ------_=_NextPart_001_01C5BFF2.F5165238 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I need to write program which will configure dhcp = server.But I need to make this configuration changes effective with out restarting = the dhcpd.

Can any body help me.

 

Thanks.

Regards,

Somenath

 

 

 

------_=_NextPart_001_01C5BFF2.F5165238-- --===============0498257899== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0498257899==-- From dhcwg-bounces@ietf.org Fri Sep 23 12:54:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqoq-0004qk-22; Fri, 23 Sep 2005 12:54:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqon-0004qd-Te for dhcwg@megatron.ietf.org; Fri, 23 Sep 2005 12:54:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25039 for ; Fri, 23 Sep 2005 12:54:34 -0400 (EDT) Received: from kaboom.isc.org ([204.152.187.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIqvF-0003AP-UF for dhcwg@ietf.org; Fri, 23 Sep 2005 13:01:19 -0400 Received: by kaboom.isc.org (Postfix, from userid 10200) id 4E21CB246E; Fri, 23 Sep 2005 09:53:39 -0700 (PDT) Date: Fri, 23 Sep 2005 09:53:39 -0700 From: "David W. Hankins" To: somenath.pal@wipro.com Subject: Re: [dhcwg] How to reload dhcpd.conf with out stopping/starting dhcpd Message-ID: <20050923165339.GA21999@isc.org> References: <8EFA81424BDADF4EB943E5A53420D7E3871B51@BLR-EC-MBX03.wipro.com> Mime-Version: 1.0 In-Reply-To: <8EFA81424BDADF4EB943E5A53420D7E3871B51@BLR-EC-MBX03.wipro.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1364701970==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1364701970== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 23, 2005 at 09:27:10AM +0530, somenath.pal@wipro.com wrote: > I need to write program which will configure dhcp server.But I need to > make this configuration changes effective with out restarting the dhcpd. >=20 > Can any body help me. The DHC WG mailing list isn't really a good place to discuss this. Going out on a limb and guessing you're asking about ISC's DHCP implementation, I would suggest the dhcp-server@isc.org mailing list. You can subscribe here; http://www.isc.org/sw/dhcp/dhcp-lists.php --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --mYCpIKhGyMATD0i+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFDNDMScXeLeWu2vmoRAmDzAJ9lVZ7x/1oGoL41pCBmfK8iqax9zgCfSdA+ Ng3xJHThEFFGTL0oFcnrFmk= =UslU -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+-- --===============1364701970== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1364701970==-- From dhcwg-bounces@ietf.org Fri Sep 23 16:03:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EItlT-0006sz-RK; Fri, 23 Sep 2005 16:03:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EItlR-0006oe-RX for dhcwg@megatron.ietf.org; Fri, 23 Sep 2005 16:03:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05389 for ; Fri, 23 Sep 2005 16:03:20 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EItrt-00082p-0o for dhcwg@ietf.org; Fri, 23 Sep 2005 16:10:02 -0400 Received: from lion.cs.columbia.edu (IDENT:z4sCEOL4Iyo5OTG9E3lT5YYIn4EciO5Q@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j8NK3Esw015074 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 23 Sep 2005 16:03:15 -0400 (EDT) Received: from [128.59.19.228] (dhcp28.cs.columbia.edu [128.59.19.228]) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id j8NK3EhM021881 for ; Fri, 23 Sep 2005 16:03:14 -0400 Message-ID: <43345F0B.2070900@cs.columbia.edu> Date: Fri, 23 Sep 2005 16:01:15 -0400 From: Andrea G Forte User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [dhcwg] DAD in DHCPv6. X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi everyone, I have a question about DHCPv6 and the statefull address configuration. It seems that DAD is performed only in the stateless procedure and no DAD at all is performed in the stateful procedure. How can the DHCP server be sure that the IP address that is going to assign has not been manually configured by someone other client? (Which is the reason for having DAD in DHCPv4). Thank you, Andrea _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Sep 23 16:13:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EItvU-0003os-Pn; Fri, 23 Sep 2005 16:13:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EItvS-0003nO-K7 for dhcwg@megatron.ietf.org; Fri, 23 Sep 2005 16:13:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08796 for ; Fri, 23 Sep 2005 16:13:40 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIu1s-0000st-R4 for dhcwg@ietf.org; Fri, 23 Sep 2005 16:20:25 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Sep 2005 13:13:28 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,141,1125903600"; d="scan'208"; a="11027147:sNHT21047400" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8NKDGTE000816; Fri, 23 Sep 2005 16:13:26 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Sep 2005 16:13:24 -0400 Received: from 161.44.65.238 ([161.44.65.238]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Fri, 23 Sep 2005 20:13:24 +0000 Received: from dhcp-guest-bxb22-64-102-164-26.cisco.com by email.cisco.com; 23 Sep 2005 16:13:32 -0400 Subject: Re: [dhcwg] DAD in DHCPv6. From: Ralph Droms To: Andrea G Forte In-Reply-To: <43345F0B.2070900@cs.columbia.edu> References: <43345F0B.2070900@cs.columbia.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 23 Sep 2005 16:13:31 -0400 Message-Id: <1127506412.9624.16.camel@dhcp-guest-bxb22-64-102-164-26.cisco.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) X-OriginalArrivalTime: 23 Sep 2005 20:13:24.0815 (UTC) FILETIME=[40A765F0:01C5C07B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >From RFC 3315, section 18.1.8: The client SHOULD perform duplicate address detection [17] on each of the addresses in any IAs it receives in the Reply message before using that address for traffic. If any of the addresses are found to be in use on the link, the client sends a Decline message to the server as described in section 18.1.7. - Ralph On Fri, 2005-09-23 at 16:01 -0400, Andrea G Forte wrote: > Hi everyone, > > I have a question about DHCPv6 and the statefull address configuration. It > seems that DAD is performed only in the stateless procedure and no DAD > at all is performed in the stateful procedure. How can the DHCP server > be sure that the IP address that is going to assign has not been > manually configured by someone other client? (Which is the reason for > having DAD in DHCPv4). > > Thank you, > Andrea > > > _______________________________________________ > 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-bounces@ietf.org Fri Sep 23 16:35:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIuGO-0007tQ-5I; Fri, 23 Sep 2005 16:35:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIuGM-0007tL-39 for dhcwg@megatron.ietf.org; Fri, 23 Sep 2005 16:35:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12182 for ; Fri, 23 Sep 2005 16:35:16 -0400 (EDT) From: volz@cisco.com Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIuMq-0002G7-GZ for dhcwg@ietf.org; Fri, 23 Sep 2005 16:42:01 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 23 Sep 2005 13:35:08 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j8NKYeWB014928 for ; Fri, 23 Sep 2005 13:35:03 -0700 (PDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Sep 2005 16:34:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Sep 2005 16:34:49 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21A1E97E@xmb-rtp-20a.amer.cisco.com> Thread-Topic: Updated Drafts - FQDN & DHCID RR Thread-Index: AcXAfOXvNJWMQn9GRL+UWVSfiGM6nAAADtiQ To: X-OriginalArrivalTime: 23 Sep 2005 20:34:49.0709 (UTC) FILETIME=[3E82A9D0:01C5C07E] X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] Updated Drafts - FQDN & DHCID RR X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org As the previous versions of these drafts had recently expired, I've resubmitted them with NO substantive changes - I only changed the date, draft version, boiler plate to latest BCP 78/79, and updated dates on draft references. Margaret suggested to have these 3 drafts and http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-resolution-10.tx t go through a DHC & DNSEXT WG Last Call as a package and then hopefully go to the IESG. - Bernie -----Original Message----- From: Bernie Volz [volz@cisco.com]=20 Sent: Friday, September 23, 2005 4:25 PM To: 'internet-drafts@ietf.org' Cc: Ralph Droms [rdroms@cisco.com]; Stig Venaas; Olafur Gudmundsson; Olaf Kolkman Subject:=20 Hello: =20 Please publish the following three updated drafts as the previous version had just expired. =20 draft-ietf-dhc-dhcpv6-fqdn-03.txt -- ftp://ftp-eng.cisco.com/ftp/volz/draft-ietf-dhc-dhcpv6-fqdn-03.txt draft-ietf-dhc-fqdn-option-11.txt -- ftp://ftp-eng.cisco.com/ftp/volz/draft-ietf-dhc-fqdn-option-11.txt draft-ietf-dnsext-dhcid-rr-10.txt -- ftp://ftp-eng.cisco.com/ftp/volz/draft-ietf-dnsext-dhcid-rr-10.txt Thanks in advance. - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Sep 24 00:06:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJ1JN-0004NA-6Q; Sat, 24 Sep 2005 00:06:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJ1JK-0004N2-Tv for dhcwg@megatron.ietf.org; Sat, 24 Sep 2005 00:06:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02222 for ; Sat, 24 Sep 2005 00:06:47 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJ1Ps-0003jL-Hs for dhcwg@ietf.org; Sat, 24 Sep 2005 00:13:37 -0400 Received: from [192.168.2.105] (206-169-64-119.vtc.net [206.169.64.119]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 1103F5689E; Fri, 23 Sep 2005 21:06:24 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <43345F0B.2070900@cs.columbia.edu> References: <43345F0B.2070900@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <38F872ED-2C57-458A-9EF3-8D1423F27F00@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] DAD in DHCPv6. Date: Fri, 23 Sep 2005 21:01:52 -0700 To: Andrea G Forte X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Sep 23, 2005, at 1:01 PM, Andrea G Forte wrote: > I have a question about DHCPv6 and the statefull address > configuration. It seems that DAD is performed only in the stateless > procedure and no DAD at all is performed in the stateful procedure. > How can the DHCP server be sure that the IP address that is going > to assign has not been manually configured by someone other client? > (Which is the reason for having DAD in DHCPv4). Nodes are not supposed to do stateless autoconf using prefixes that are managed (that is, prefixes announced in router advertisements where the 'M' bit is set). Unfortunately, every IPv6 implementation I've seen so far except Solaris ignores the 'M' bit entirely, so you are right to be concerned. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Sep 24 00:22:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJ1Ya-0007xK-SO; Sat, 24 Sep 2005 00:22:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJ1YY-0007v6-HU for dhcwg@megatron.ietf.org; Sat, 24 Sep 2005 00:22:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02789 for ; Sat, 24 Sep 2005 00:22:31 -0400 (EDT) From: volz@cisco.com Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJ1f6-00042t-LY for dhcwg@ietf.org; Sat, 24 Sep 2005 00:29:21 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 24 Sep 2005 00:22:24 -0400 X-IronPort-AV: i="3.97,142,1125892800"; d="scan'208"; a="71600907:sNHT30223536" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8O4MKT6028543; Sat, 24 Sep 2005 00:22:21 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 24 Sep 2005 00:22:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] DAD in DHCPv6. Date: Sat, 24 Sep 2005 00:22:19 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21A1EA09@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] DAD in DHCPv6. Thread-Index: AcXAva/97Dc/SkIjSpiFfF+5sd1UVAAAQ7OA To: "Ted Lemon" , "Andrea G Forte" X-OriginalArrivalTime: 24 Sep 2005 04:22:20.0844 (UTC) FILETIME=[8E4A2EC0:01C5C0BF] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Actually, the 'M' bit has nothing to do with stateless. It is the 'A' bit in a Prefix Information Option in the RA: A 1-bit autonomous address-configuration flag. When set indicates that this prefix can be used for autonomous address configuration as specified in [ADDRCONF]. As Ralph already pointed out, RFC 3315 strongly suggests (SHOULD) that clients do DAD. It is also one of the reasons we have a DECLINE message -- a client may find that an address is already in use and therefore should notify the DHCP server of that fact so the address can be taken out of circulation. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ted Lemon > Sent: Saturday, September 24, 2005 12:02 AM > To: Andrea G Forte > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] DAD in DHCPv6. >=20 > On Sep 23, 2005, at 1:01 PM, Andrea G Forte wrote: > > I have a question about DHCPv6 and the statefull address =20 > > configuration. It seems that DAD is performed only in the=20 > stateless =20 > > procedure and no DAD at all is performed in the stateful=20 > procedure. =20 > > How can the DHCP server be sure that the IP address that is going =20 > > to assign has not been manually configured by someone other=20 > client? =20 > > (Which is the reason for having DAD in DHCPv4). >=20 > Nodes are not supposed to do stateless autoconf using prefixes that =20 > are managed (that is, prefixes announced in router advertisements =20 > where the 'M' bit is set). >=20 > Unfortunately, every IPv6 implementation I've seen so far except =20 > Solaris ignores the 'M' bit entirely, so you are right to be=20 > concerned. >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 26 02:27:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJmSL-0007VV-UY; Mon, 26 Sep 2005 02:27:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJmSE-0007Uk-Nq for dhcwg@megatron.ietf.org; Mon, 26 Sep 2005 02:27:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06921 for ; Mon, 26 Sep 2005 02:26:41 -0400 (EDT) Received: from dmzraw5.extranet.tce.com ([157.254.234.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJmYj-0002h3-Tl for dhcwg@ietf.org; Mon, 26 Sep 2005 02:33:56 -0400 Received: from indyvss1.am.thmulti.com (unknown [157.254.92.60]) by dmzraw5.extranet.tce.com (Postfix) with ESMTP id EE5CAC09; Mon, 26 Sep 2005 06:26:13 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by indyvss1.am.thmulti.com (Postfix) with ESMTP id DDC784FF83; Mon, 26 Sep 2005 06:26:13 +0000 (GMT) Received: from indyvss1.am.thmulti.com ([127.0.0.1]) by localhost (indyvss1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29390-01-83; Mon, 26 Sep 2005 06:26:09 +0000 (GMT) Received: from smtprelay2.indy.tce.com (smtprelay2.indy.tce.com [157.254.96.95]) by indyvss1.am.thmulti.com (Postfix) with ESMTP id 1E48B4FF81; Mon, 26 Sep 2005 06:26:09 +0000 (GMT) Received: from boulsmailbh01.eu.thmulti.com (localhost [127.0.0.1]) by smtprelay2.indy.tce.com (8.12.9/8.12.8) with ESMTP id j8Q6P4h1021210; Mon, 26 Sep 2005 06:26:08 GMT Received: from edgmsmail01.eu.thmulti.com ([141.11.248.9]) by boulsmailbh01.eu.thmulti.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Sep 2005 08:25:40 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [dhcwg] Re: Authentication of DHCP Relay Agent Options Using IPsec Date: Mon, 26 Sep 2005 08:25:40 +0200 Message-ID: <1F5308C5923F3B4DAA51D189BF255006BC7CA3@edgmsmail01.eu.thmulti.com> Thread-Topic: [dhcwg] Re: Authentication of DHCP Relay Agent Options Using IPsec Thread-Index: AcW/qLU8JPBMUrt6QRSdQsYez21GEQCugvxg From: "Van Aken Dirk" To: "Michael Richardson" , X-OriginalArrivalTime: 26 Sep 2005 06:25:40.0862 (UTC) FILETIME=[1DDED1E0:01C5C263] X-Virus-Scanned: amavisd-new at thomson.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Cc: ipsec@lists.tislabs.com.cnri.reston.va.us X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi Michael, How do you come to the conclusion that DHCP relays are rather "small boxes" and as a consequence don't need a full IKE implementation ? As far as I know DHCP Relays are to be found in the complete range of IP nodes which can range from very small to "huge". Best regards - Dirk > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of > Michael Richardson > Sent: donderdag 22 september 2005 20:27 > To: dhcwg@ietf.org > Cc: ipsec@lists.tislabs.com.cnri.reston.va.us > Subject: [dhcwg] Re: Authentication of DHCP Relay Agent Options Using > IPsec >=20 >=20 > >>>>> "Russ" =3D=3D Russ Housley writes: > Russ> The following document is on the agenda for the IESG telechat > next > Russ> week for approval as a Proposed Standard. I would appreciate > Russ> review from the members of this mail list in the next week. >=20 > Russ> Authentication of DHCP Relay Agent Options Using IPsec > Russ> draft-ietf-dhc-relay-agent-ipsec-02.txt >=20 > I think that I read this some time ago and commented about lack of clear > statement about how to do the keying. >=20 > I have re-read it, and I still find the key management section too > unclear: >=20 > > 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 does not provide defense against replayed > > messages. Accordingly, if replay protection is required, > > IKE [4] with preshared secrets must be used. IKE with > > public keys may be used. >=20 > Are replays an issue? I think that threat model said clearly that they > were, so it seems to me that IKE "MUST" be used. >=20 > I would like to see more clear statement about how to use IKE. In > particular, I think the DHCP relay agents are rather small boxes, and so > the > full complexity of IKE is probably not desireable. >=20 > My suggestions are: > 1) support IKE main mode only, and cookie-mode of IKEv2. >=20 > 2) support PSK authentication only. This works fine with MainMode > in IKEv1 if your DHC relays are at known, non-changing addresses. > (If that isn't the case, please say so. I can think of situations > where it might not be the case) >=20 > 3) I suggest modp1024 and modp1536 be supported. This is clearly easy > to upgrade if you stick to mainmode, but if you decide you need > aggressive mode, you have to pick one mode only. >=20 > 4) the relay does not need to support NAT-T, DPD, xauth, modecfg. >=20 > 5) in IKEv2, the relay does not need to support simultaneous SAs > with the same selectors. >=20 > 6) phase 1 IDs of ID_IPV4_ADDR or ID_IPV6_ADDR will be supported. > phase 2 IDs of ID_IPV4_ADDR (vs ID_IPV4_ADDR_RANGE with /32) > will be supported. >=20 > 7) You said transport mode already. Is fragmentation supported? > Remember that the relay is adding stuff, and then you get to add > ESP. >=20 > 8) please recommend IKEv1 lifetimes, since they are not negotiated, > and a mis-match still causes failure in many devices. > (IKEv2 does not have this problem) >=20 > 9) The agent will support a PSK of between 16 and 64 bytes, and > will accept hex (0x) and base64 (0s) encoded strings for entering > the PSK in its' admin interface. This will encourage stronger PSKs > and you won't find yourself in situation where you can only type > a printable phrase. > A 3-4 character hash of the PSK will be generated at each end to > aid > in confirming that the PSK has been entered correctly. >=20 > I think that #6 is critical to specify if you actually want this > security feature turned on during deployment. >=20 > -- > ] ON HUMILITY: to err is human. To moo, bovine. | > firewalls [ > ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net > architect[ > ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device > driver[ > ] panic("Just another Debian GNU/Linux using, kernel hacking, security > guy"); [ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 26 06:26:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJqBN-0002Zb-Mi; Mon, 26 Sep 2005 06:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJqBL-0002ZF-E8 for dhcwg@megatron.ietf.org; Mon, 26 Sep 2005 06:25:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16785 for ; Mon, 26 Sep 2005 06:25:49 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJqIE-0008O9-2m for dhcwg@ietf.org; Mon, 26 Sep 2005 06:33:07 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8QAP3x07359 for ; Mon, 26 Sep 2005 12:25:03 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8QAP350000714 for ; Mon, 26 Sep 2005 12:25:03 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509261025.j8QAP350000714@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: dhcwg@ietf.org Date: Mon, 26 Sep 2005 12:25:03 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [dhcwg] DHCPv6 relay ports X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org RFC 3315 is not very clear about the ports to use for DHCPv6 relays. I assume we'd like to use the same ports in exchanges (i.e., the source port in one way should be the destination one in the other way) and, either the same box may run a server and relays, or a relay and clients, without too many constraints about multiple bindings to the same address/ port. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 26 08:54:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJsVQ-00052h-5t; Mon, 26 Sep 2005 08:54:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJsVM-00051Z-1O for dhcwg@megatron.ietf.org; Mon, 26 Sep 2005 08:54:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24439 for ; Mon, 26 Sep 2005 08:54:39 -0400 (EDT) From: volz@cisco.com Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJscG-00047Z-DN for dhcwg@ietf.org; Mon, 26 Sep 2005 09:01:57 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 26 Sep 2005 08:54:29 -0400 X-IronPort-AV: i="3.97,146,1125892800"; d="scan'208"; a="71754309:sNHT28176124" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8QCruRF027856; Mon, 26 Sep 2005 08:54:27 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Sep 2005 08:54:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] DHCPv6 relay ports Date: Mon, 26 Sep 2005 08:54:23 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21A1EB5B@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] DHCPv6 relay ports Thread-Index: AcXChU9Reatv1SheQqC9/XU2bGJzjwAE9JKQ To: "Francis Dupont" , X-OriginalArrivalTime: 26 Sep 2005 12:54:24.0191 (UTC) FILETIME=[6BA864F0:01C5C299] X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Francis: What's unclear about: 5.2. UDP Ports Clients listen for DHCP messages on UDP port 546. Servers and relay agents listen for DHCP messages on UDP port 547.=20 - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Francis Dupont > Sent: Monday, September 26, 2005 6:25 AM > To: dhcwg@ietf.org > Subject: [dhcwg] DHCPv6 relay ports >=20 > RFC 3315 is not very clear about the ports to use for DHCPv6 relays. > I assume we'd like to use the same ports in exchanges (i.e.,=20 > the source > port in one way should be the destination one in the other way) and, > either the same box may run a server and relays, or a relay=20 > and clients, > without too many constraints about multiple bindings to the=20 > same address/ > port. >=20 > Regards >=20 > Francis.Dupont@enst-bretagne.fr >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 26 09:20:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJsuF-0003gg-Dn; Mon, 26 Sep 2005 09:20:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJsuC-0003f0-Nq for dhcwg@megatron.ietf.org; Mon, 26 Sep 2005 09:20:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25841 for ; Mon, 26 Sep 2005 09:20:27 -0400 (EDT) From: volz@cisco.com Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJt1D-0004sQ-SC for dhcwg@ietf.org; Mon, 26 Sep 2005 09:27:46 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 26 Sep 2005 06:20:17 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j8QDJbvE026829; Mon, 26 Sep 2005 06:20:14 -0700 (PDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Sep 2005 09:20:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] DHCPv6 relay ports Date: Mon, 26 Sep 2005 09:20:11 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21A1EB77@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] DHCPv6 relay ports Thread-Index: AcXCm3ixpq+fvJYEQ2mWaBHMb4Xa/wAARF+A To: X-OriginalArrivalTime: 26 Sep 2005 13:20:12.0583 (UTC) FILETIME=[06924370:01C5C29D] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Yes, that is true but that wasn't an issue that was raised to the DHC WG with the existing DHCPv4 architecture and isn't something that we considered. It also makes client implementations more complex because the obvious solution would be to send to both ports, and that seems rather wastely for what I suspect is a rare configuration. You always have the ability to bind per interface, but if you have both running on a single interface, you're likely to need some special software anyway to decide which to process and which to relay. - Bernie=20 > -----Original Message----- > From: Francis.Dupont@enst-bretagne.fr=20 > [mailto:Francis.Dupont@enst-bretagne.fr]=20 > Sent: Monday, September 26, 2005 9:08 AM > To: Bernie Volz [volz@cisco.com] > Subject: Re: [dhcwg] DHCPv6 relay ports=20 >=20 > In your previous mail you wrote: >=20 > What's unclear about: > =20 > 5.2. UDP Ports > =20 > Clients listen for DHCP messages on UDP port 546. =20 > Servers and relay > agents listen for DHCP messages on UDP port 547.=20 > =20 > =3D> this can give impossible or assymetrical bind()s when a server = and > some relays run on the same node. Just try the relay-forward/reply > exchange between a server and a relay on the same node. > BTW I have a running solution, my problem is I'd like to interoperate > in the general case too. >=20 > Thanks >=20 > Francis.Dupont@enst-bretagne.fr >=20 > > Subject: [dhcwg] DHCPv6 relay ports > >=20 > > RFC 3315 is not very clear about the ports to use for=20 > DHCPv6 relays. > > I assume we'd like to use the same ports in exchanges (i.e.,=20 > > the source > > port in one way should be the destination one in the=20 > other way) and, > > either the same box may run a server and relays, or a relay=20 > > and clients, > > without too many constraints about multiple bindings to the=20 > > same address/ > > port. >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 26 09:34:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJt7P-0006yc-Le; Mon, 26 Sep 2005 09:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJt7L-0006vK-Tz for dhcwg@megatron.ietf.org; Mon, 26 Sep 2005 09:34:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26541 for ; Mon, 26 Sep 2005 09:34:02 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJtEO-0005E4-9b for dhcwg@ietf.org; Mon, 26 Sep 2005 09:41:21 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8QDXgD24523; Mon, 26 Sep 2005 15:33:42 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8QDXgG2001716; Mon, 26 Sep 2005 15:33:42 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509261333.j8QDXgG2001716@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: volz@cisco.com Subject: Re: [dhcwg] DHCPv6 relay ports In-reply-to: Your message of Mon, 26 Sep 2005 09:20:11 EDT. <8E296595B6471A4689555D5D725EBB21A1EB77@xmb-rtp-20a.amer.cisco.com> Date: Mon, 26 Sep 2005 15:33:42 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org In your previous mail you wrote: Yes, that is true but that wasn't an issue that was raised to the DHC WG with the existing DHCPv4 architecture and isn't something that we considered. => so now you can see the issue... It also makes client implementations more complex because the obvious solution would be to send to both ports, and that seems rather wastely for what I suspect is a rare configuration. => IMHO this is not a good solution. You always have the ability to bind per interface, => this works only for unicast (this one part of the problem: unicast and multicast constraints are very different). but if you have both running on a single interface, => this is not the case: a relay can run only on a real interface so the loopback is free for the server (not pretty but this works :-). you're likely to need some special software anyway to decide which to process and which to relay. => this is exactly what I'd like to avoid... Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 26 10:46:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuFh-0007Cx-LL; Mon, 26 Sep 2005 10:46:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFWyj-0005qX-IT; Wed, 14 Sep 2005 09:07:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09286; Wed, 14 Sep 2005 09:07:07 -0400 (EDT) Message-Id: <200509141307.JAA09286@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFX3K-0001Se-8V; Wed, 14 Sep 2005 09:11:55 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EFWyT-0005ii-SW; Wed, 14 Sep 2005 08:06:54 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "'James M. Polk'" Date: Wed, 14 Sep 2005 09:06:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW5KorsmQH2Zt7mSeGHMUYjwmQSmwAAZvCA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 26 Sep 2005 10:46:39 -0400 Cc: dhcwg@ietf.org, 'ECRIT' Subject: [dhcwg] RE: [Ecrit] draft-polk-dhc-uri-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I've previously argued that while getting it when you boot (i.e. run DHCP) is a good idea, it would be best if you did the mapping from location to URI just before the call, because, due to failures or other disaster related effects, the mapping may have changed. It IS a transaction you want to do when you want to make a call setup, because you want the most recent data. You also want to make certain that you refresh this data periodically. Daily is probably the minimum, and you know that some DHCP lease times are on the order of weeks. So, I would like this wording significantly changed. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Wednesday, September 14, 2005 8:48 AM To: 'James M. Polk' Cc: dhcwg@ietf.org; 'ECRIT' Subject: [Ecrit] draft-polk-dhc-uri-00 James, Would you please provide the basis for your text below regarding the timing of psap determination, I can't seem to match it up with any of the requirements within ecrit or geopriv. "One example of this URI download would be one specifically for the SIP or SIPS URI of the appropriate Public Safety Answer Point (PSAP) for the client when the user of that client calls for emergency help (911 or 112-type of help). This is not a transaction that should take place when a voice application wants to make such a critical call set-up. It is more appropriate that this information be downloaded to the client when the voice (or other) application boots up in case it is needed at a later time." Thanks, -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 26 10:46:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuFi-0007DM-Uy; Mon, 26 Sep 2005 10:46:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFXbE-0006ao-Ib; Wed, 14 Sep 2005 09:46:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11377; Wed, 14 Sep 2005 09:46:53 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFXfn-0002Ou-F5; Wed, 14 Sep 2005 09:51:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Sep 2005 15:50:21 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B213B@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] draft-polk-dhc-uri-00 Thread-Index: AcW5KorsmQH2Zt7mSeGHMUYjwmQSmwAAZvCAAAFlANA= From: "Stastny Richard" To: , "Marc Linsner" , "James M. Polk" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 26 Sep 2005 10:46:39 -0400 Cc: dhcwg@ietf.org, ECRIT Subject: [dhcwg] RE: [Ecrit] draft-polk-dhc-uri-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Brian, good you brought this up: > ...because, due to failures or other disaster related > effects, the mapping may have changed. It IS a transaction you want to do > when you want to make a call setup, because you want the most recent data. You may add organisational changes. This implies that there MUST be an authoritative source for the PSAP URI - and this can only be the mapping database (LCMS) and there MUST also be defined a TTL for the PSAP URI. 1. for the mapping database itself, if caches are used (e.g. if it is DNS-based) and=20 2. for all other "caches". Any PSAP URI for a given location out of the mapping database is in principle a "cached" information. If the URI is provided say by DHCP from the box responsible to provide the IP-address, the box itself has to go back and query the mapping database periodically to update his information. It then MUST set the TTL (lease-time) appropriately that the information is distributed further in a timely manner. Richard > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Wednesday, September 14, 2005 3:07 PM > To: 'Marc Linsner'; 'James M. Polk' > Cc: dhcwg@ietf.org; 'ECRIT' > Subject: RE: [Ecrit] draft-polk-dhc-uri-00 >=20 > I've previously argued that while getting it when you boot (i.e. run DHCP) > is a good idea, it would be best if you did the mapping from location to > URI > just before the call, because, due to failures or other disaster related > effects, the mapping may have changed. It IS a transaction you want to do > when you want to make a call setup, because you want the most recent data. >=20 > You also want to make certain that you refresh this data periodically. > Daily is probably the minimum, and you know that some DHCP lease times are > on the order of weeks. >=20 > So, I would like this wording significantly changed. >=20 > Brian >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Marc Linsner > Sent: Wednesday, September 14, 2005 8:48 AM > To: 'James M. Polk' > Cc: dhcwg@ietf.org; 'ECRIT' > Subject: [Ecrit] draft-polk-dhc-uri-00 >=20 > James, >=20 > Would you please provide the basis for your text below regarding the > timing > of psap determination, I can't seem to match it up with any of the > requirements within ecrit or geopriv. >=20 > "One example of this URI download would be one specifically for the SIP or > SIPS URI of the appropriate Public Safety Answer Point (PSAP) for the > client > when the user of that client calls for emergency help (911 or 112-type of > help). This is not a transaction that should take place when a voice > application wants to make such a critical call set-up. It is more > appropriate that this information be downloaded to the client when the > voice > (or other) application boots up in case it is needed at a later time." >=20 > Thanks, >=20 > -Marc- >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 26 10:46:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuFj-0007Dl-K8; Mon, 26 Sep 2005 10:46:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFWgc-0000qD-BF; Wed, 14 Sep 2005 08:48:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08179; Wed, 14 Sep 2005 08:48:24 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFWlC-0000w1-PJ; Wed, 14 Sep 2005 08:53:12 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 14 Sep 2005 05:48:14 -0700 X-IronPort-AV: i="3.97,109,1125903600"; d="scan'208"; a="341558829:sNHT29746328" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8ECm450028764; Wed, 14 Sep 2005 05:48:11 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 05:48:08 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 05:48:08 -0700 From: "Marc Linsner" To: "'James M. Polk'" Date: Wed, 14 Sep 2005 08:48:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW5KorsmQH2Zt7mSeGHMUYjwmQSmw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 14 Sep 2005 12:48:08.0502 (UTC) FILETIME=[8EC5CD60:01C5B92A] X-Spam-Score: 1.1 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 26 Sep 2005 10:46:40 -0400 Cc: dhcwg@ietf.org, 'ECRIT' Subject: [dhcwg] draft-polk-dhc-uri-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org James, Would you please provide the basis for your text below regarding the timing of psap determination, I can't seem to match it up with any of the requirements within ecrit or geopriv. "One example of this URI download would be one specifically for the SIP or SIPS URI of the appropriate Public Safety Answer Point (PSAP) for the client when the user of that client calls for emergency help (911 or 112-type of help). This is not a transaction that should take place when a voice application wants to make such a critical call set-up. It is more appropriate that this information be downloaded to the client when the voice (or other) application boots up in case it is needed at a later time." Thanks, -Marc- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 26 10:46:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuFk-0007EE-97; Mon, 26 Sep 2005 10:46:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFYcc-0005TT-5v; Wed, 14 Sep 2005 10:52:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15300; Wed, 14 Sep 2005 10:52:23 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFYhE-0003xt-J8; Wed, 14 Sep 2005 10:57:12 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 14 Sep 2005 07:52:16 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8EEpbKg017296; Wed, 14 Sep 2005 07:52:06 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 07:52:14 -0700 Received: from MLINSNER ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 07:52:13 -0700 From: "Marc Linsner" To: "'Henning Schulzrinne'" Date: Wed, 14 Sep 2005 10:52:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW5O+HMlXhEiZqLRAuqYti41FfORg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 14 Sep 2005 14:52:13.0573 (UTC) FILETIME=[E4617B50:01C5B93B] X-Spam-Score: 1.1 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 26 Sep 2005 10:46:40 -0400 Cc: 'GEOPRIV' , dhcwg@ietf.org Subject: [dhcwg] draft-ietf-geopriv-dhcp-civil-07 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Henning, Wrt: "This document only defines the delivery of location information from the DHCP server to the client, due to security concerns related to using DHCP to update the database. Within the GEOPRIV architecture as defined by RFC 3693 [10], the defined mechanism in this document for conveying initial location information is known as a "sighting" function. Sighting functions are not required to have security capabilities and are only intended to be configured in trusted and controlled environments. (A classic example of the sighting function is a Global Positioning System wired directly to a network node.) After initial location information has been introduced, it MUST be afforded the protections defined in RFC 3694 [11]. Therefore, location information MUST NOT be sent from a DHCP client to a DHCP server as is normally allowed by DHCP." Correct me if I've interpreted this wrong. I derived from this text (at least) 3 issues: 1) Due to [wiremap] database security concerns, we must disallow client to dhcp server [upstream] communication of this LCI. 2) This DHCP LCI mechanism falls under the 'sighting' category as defined in the geopriv architecture used in trusted and controlled environments. 3) Communication of location information outside of this special 'sighting' category must be afforded the protections defined in RFC 3694. I'd like clarification on: 1) Since neither this document nor RFC 3825 defines the wiremap database architecture, I don't understand this db security concern. How can the transport of a db record be a security risk to the effecting of database change within the unknown database architecture? Is this not a concern for the database administration? We should not disallow this function solely based on the assumption of poor database administration design. 2) Since upstream communication of this LCI information would still take place within the confines of the 'sighting' category, a trusted and controlled environment, what has happened that has made this upstream communication fall under issue #3 (above)? This LCI option can only contain information allowed by the draft, whether it's upstream or downstream. Thanks, -Marc- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 26 10:46:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuFl-0007GF-3S; Mon, 26 Sep 2005 10:46:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFYvQ-0002Go-W4; Wed, 14 Sep 2005 11:11:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16347; Wed, 14 Sep 2005 11:11:50 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFZ01-0004W2-Of; Wed, 14 Sep 2005 11:16:40 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 14 Sep 2005 11:11:42 -0400 X-IronPort-AV: i="3.97,110,1125892800"; d="scan'208"; a="70204832:sNHT30504116" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8EFBARF006716; Wed, 14 Sep 2005 11:11:39 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 11:11:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Sep 2005 11:11:37 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E38FA176@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] draft-polk-dhc-uri-00 Thread-Index: AcW5KorsmQH2Zt7mSeGHMUYjwmQSmwAAZvCAAARarBA= From: "Michael Hammer \(mhammer\)" To: , "Marc Linsner \(mlinsner\)" , "James Polk \(jmpolk\)" X-OriginalArrivalTime: 14 Sep 2005 15:11:38.0508 (UTC) FILETIME=[9ABC74C0:01C5B93E] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 26 Sep 2005 10:46:41 -0400 Cc: dhcwg@ietf.org, ECRIT Subject: [dhcwg] RE: [Ecrit] draft-polk-dhc-uri-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Brian, First, PSAPs should have operational constraints to migrate operations gracefully so they can not arbitrarily change mappings at a faster pace than say 24 hours. Second, disaster-related effects should be handled by proper high availability design. Non-respone from the primar PSAP URI should result in fail-over to an alternate IP address located in a different geographic area. What is invalid here is not the URI but the underlying PSAP network design. And yes, the client should have some maximum time beyond which it must refresh. But, it might also be more predictable for the voice system if the network managed when the refreshes occurred before the deadline such that there is no avalanche from clients. Thus, clients would always find themselves inside that (24 hour?) window. Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Brian Rosen > Sent: Wednesday, September 14, 2005 9:07 AM > To: Marc Linsner (mlinsner); James Polk (jmpolk) > Cc: dhcwg@ietf.org; 'ECRIT' > Subject: RE: [Ecrit] draft-polk-dhc-uri-00 >=20 > I've previously argued that while getting it when you boot=20 > (i.e. run DHCP) is a good idea, it would be best if you did=20 > the mapping from location to URI just before the call,=20 > because, due to failures or other disaster related effects,=20 > the mapping may have changed. It IS a transaction you want=20 > to do when you want to make a call setup, because you want=20 > the most recent data. >=20 > You also want to make certain that you refresh this data periodically. > Daily is probably the minimum, and you know that some DHCP=20 > lease times are on the order of weeks. >=20 > So, I would like this wording significantly changed. >=20 > Brian >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Marc Linsner > Sent: Wednesday, September 14, 2005 8:48 AM > To: 'James M. Polk' > Cc: dhcwg@ietf.org; 'ECRIT' > Subject: [Ecrit] draft-polk-dhc-uri-00 >=20 > James, >=20 > Would you please provide the basis for your text below=20 > regarding the timing of psap determination, I can't seem to=20 > match it up with any of the requirements within ecrit or geopriv. >=20 > "One example of this URI download would be one specifically=20 > for the SIP or SIPS URI of the appropriate Public Safety=20 > Answer Point (PSAP) for the client when the user of that=20 > client calls for emergency help (911 or 112-type of help). =20 > This is not a transaction that should take place when a voice=20 > application wants to make such a critical call set-up. It is=20 > more appropriate that this information be downloaded to the=20 > client when the voice (or other) application boots up in case=20 > it is needed at a later time." >=20 > Thanks, >=20 > -Marc- >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 26 10:46:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuFl-0007Ge-Nh; Mon, 26 Sep 2005 10:46:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZEd-0007fr-9n; Wed, 14 Sep 2005 11:31:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17265; Wed, 14 Sep 2005 11:31:40 -0400 (EDT) Message-Id: <200509141531.LAA17265@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFZJG-00052q-0j; Wed, 14 Sep 2005 11:36:30 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EFZEQ-0004qx-BF; Wed, 14 Sep 2005 10:31:30 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Marc Linsner \(mlinsner\)'" , "'James Polk \(jmpolk\)'" Date: Wed, 14 Sep 2005 11:29:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E38FA176@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW5KorsmQH2Zt7mSeGHMUYjwmQSmwAAZvCAAARarBAAAJRF8A== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 26 Sep 2005 10:46:39 -0400 Cc: dhcwg@ietf.org, 'ECRIT' Subject: [dhcwg] RE: [Ecrit] draft-polk-dhc-uri-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Michael I'm not sure what your experience is. Mine is that disasters don't go according to plan. You plan for disasters, and then you deal with what actually happens. Often, what you thought would work, doesn't. You are making an assumption that the URI you get from mapping is always good for, say, 24 hours, and any problems encountered can be solved by changing the resolution of the URI. I'm not so sure. Maybe we do want all calls that were going to a specific URI to go somewhere else. Maybe we want to change routing of some of them. Maybe we are unable, for some reason, to change the resolution of the URI. It's probably true that a 24 hour old mapping will work in most cases. I'm pretty unhappy with "probably" and "most", because of the consequences of getting wrong and the uncertainty of being able to manipulate a limited number of levers when lots of infrastructure is failing. This whole subject is about probabilities of getting the right thing to happen, and I think we should take every opportunity to improve the odds. Brian -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Wednesday, September 14, 2005 11:12 AM To: br@brianrosen.net; Marc Linsner (mlinsner); James Polk (jmpolk) Cc: dhcwg@ietf.org; ECRIT Subject: RE: [Ecrit] draft-polk-dhc-uri-00 Brian, First, PSAPs should have operational constraints to migrate operations gracefully so they can not arbitrarily change mappings at a faster pace than say 24 hours. Second, disaster-related effects should be handled by proper high availability design. Non-respone from the primar PSAP URI should result in fail-over to an alternate IP address located in a different geographic area. What is invalid here is not the URI but the underlying PSAP network design. And yes, the client should have some maximum time beyond which it must refresh. But, it might also be more predictable for the voice system if the network managed when the refreshes occurred before the deadline such that there is no avalanche from clients. Thus, clients would always find themselves inside that (24 hour?) window. Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Wednesday, September 14, 2005 9:07 AM > To: Marc Linsner (mlinsner); James Polk (jmpolk) > Cc: dhcwg@ietf.org; 'ECRIT' > Subject: RE: [Ecrit] draft-polk-dhc-uri-00 > > I've previously argued that while getting it when you boot > (i.e. run DHCP) is a good idea, it would be best if you did > the mapping from location to URI just before the call, > because, due to failures or other disaster related effects, > the mapping may have changed. It IS a transaction you want > to do when you want to make a call setup, because you want > the most recent data. > > You also want to make certain that you refresh this data periodically. > Daily is probably the minimum, and you know that some DHCP > lease times are on the order of weeks. > > So, I would like this wording significantly changed. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Marc Linsner > Sent: Wednesday, September 14, 2005 8:48 AM > To: 'James M. Polk' > Cc: dhcwg@ietf.org; 'ECRIT' > Subject: [Ecrit] draft-polk-dhc-uri-00 > > James, > > Would you please provide the basis for your text below > regarding the timing of psap determination, I can't seem to > match it up with any of the requirements within ecrit or geopriv. > > "One example of this URI download would be one specifically > for the SIP or SIPS URI of the appropriate Public Safety > Answer Point (PSAP) for the client when the user of that > client calls for emergency help (911 or 112-type of help). > This is not a transaction that should take place when a voice > application wants to make such a critical call set-up. It is > more appropriate that this information be downloaded to the > client when the voice (or other) application boots up in case > it is needed at a later time." > > Thanks, > > -Marc- > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 26 10:46:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuFm-0007H3-9y; Mon, 26 Sep 2005 10:46:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZV8-0003EJ-5k; Wed, 14 Sep 2005 11:48:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18114; Wed, 14 Sep 2005 11:48:43 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFZZl-0005WI-3Z; Wed, 14 Sep 2005 11:53:33 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 14 Sep 2005 08:48:36 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,110,1125903600"; d="scan'208"; a="9674554:sNHT25257788" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8EFlxRJ017563; Wed, 14 Sep 2005 11:48:33 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 11:48:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Sep 2005 11:48:32 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E38FA1A9@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] draft-polk-dhc-uri-00 Thread-Index: AcW5KorsmQH2Zt7mSeGHMUYjwmQSmwAAZvCAAARarBAAAJRF8AAAlyWw From: "Michael Hammer \(mhammer\)" To: , "Marc Linsner \(mlinsner\)" , "James Polk \(jmpolk\)" X-OriginalArrivalTime: 14 Sep 2005 15:48:32.0913 (UTC) FILETIME=[C29FD810:01C5B943] X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 26 Sep 2005 10:46:41 -0400 Cc: dhcwg@ietf.org, ECRIT Subject: [dhcwg] RE: [Ecrit] draft-polk-dhc-uri-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Brian, My early experience is military. You design networks with disaster in mind. You have a plan B... and C, and D, and ... We used to play war games where we would arbitrarily knock out communications sites, and then say, now what? We would do this for single and multiple points of failure. Of course, there is a cost to having backups, but having no plan or backups whatsoever is no plan at all, especially for emergency aid organizations. We have voice features that say, if you ring me in NY and don't get an answer, ring me at this alternate site in Boston, all without changing the called URI. Such capabilities exist at multiple layers of the protocols, we only need to use them. Why would you assume that a PSAP network would not be designed to take advantage of such capabilities? Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, September 14, 2005 11:29 AM > To: Michael Hammer (mhammer); Marc Linsner (mlinsner); James=20 > Polk (jmpolk) > Cc: dhcwg@ietf.org; 'ECRIT' > Subject: RE: [Ecrit] draft-polk-dhc-uri-00 >=20 > Michael >=20 > I'm not sure what your experience is. Mine is that disasters=20 > don't go according to plan. You plan for disasters, and then=20 > you deal with what actually happens. Often, what you thought=20 > would work, doesn't. >=20 > You are making an assumption that the URI you get from=20 > mapping is always good for, say, 24 hours, and any problems=20 > encountered can be solved by changing the resolution of the=20 > URI. I'm not so sure. =20 >=20 > Maybe we do want all calls that were going to a specific URI=20 > to go somewhere else. Maybe we want to change routing of=20 > some of them. Maybe we are unable, for some reason, to=20 > change the resolution of the URI.=20 >=20 > It's probably true that a 24 hour old mapping will work in=20 > most cases. I'm pretty unhappy with "probably" and "most",=20 > because of the consequences of getting wrong and the=20 > uncertainty of being able to manipulate a limited number of=20 > levers when lots of infrastructure is failing. This whole=20 > subject is about probabilities of getting the right thing to=20 > happen, and I think we should take every opportunity to=20 > improve the odds. =20 >=20 > Brian >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, September 14, 2005 11:12 AM > To: br@brianrosen.net; Marc Linsner (mlinsner); James Polk (jmpolk) > Cc: dhcwg@ietf.org; ECRIT > Subject: RE: [Ecrit] draft-polk-dhc-uri-00 >=20 > Brian, >=20 > First, PSAPs should have operational constraints to migrate=20 > operations gracefully so they can not arbitrarily change=20 > mappings at a faster pace than say 24 hours. >=20 > Second, disaster-related effects should be handled by proper=20 > high availability design. Non-respone from the primar PSAP=20 > URI should result in fail-over to an alternate IP address=20 > located in a different geographic area. What is invalid here=20 > is not the URI but the underlying PSAP network design. >=20 > And yes, the client should have some maximum time beyond=20 > which it must refresh. But, it might also be more=20 > predictable for the voice system if the network managed when=20 > the refreshes occurred before the deadline such that there is=20 > no avalanche from clients. Thus, clients would always find=20 > themselves inside that (24 hour?) window. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Brian Rosen > > Sent: Wednesday, September 14, 2005 9:07 AM > > To: Marc Linsner (mlinsner); James Polk (jmpolk) > > Cc: dhcwg@ietf.org; 'ECRIT' > > Subject: RE: [Ecrit] draft-polk-dhc-uri-00 > >=20 > > I've previously argued that while getting it when you boot=20 > (i.e. run=20 > > DHCP) is a good idea, it would be best if you did the mapping from=20 > > location to URI just before the call, because, due to failures or=20 > > other disaster related effects, the mapping may have=20 > changed. It IS a=20 > > transaction you want to do when you want to make a call=20 > setup, because=20 > > you want the most recent data. > >=20 > > You also want to make certain that you refresh this data=20 > periodically. > > Daily is probably the minimum, and you know that some DHCP=20 > lease times=20 > > are on the order of weeks. > >=20 > > So, I would like this wording significantly changed. > >=20 > > Brian > >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Marc Linsner > > Sent: Wednesday, September 14, 2005 8:48 AM > > To: 'James M. Polk' > > Cc: dhcwg@ietf.org; 'ECRIT' > > Subject: [Ecrit] draft-polk-dhc-uri-00 > >=20 > > James, > >=20 > > Would you please provide the basis for your text below=20 > regarding the=20 > > timing of psap determination, I can't seem to match it up=20 > with any of=20 > > the requirements within ecrit or geopriv. > >=20 > > "One example of this URI download would be one specifically for the=20 > > SIP or SIPS URI of the appropriate Public Safety Answer=20 > Point (PSAP)=20 > > for the client when the user of that client calls for=20 > emergency help=20 > > (911 or 112-type of help). > > This is not a transaction that should take place when a voice=20 > > application wants to make such a critical call set-up. It is more=20 > > appropriate that this information be downloaded to the=20 > client when the=20 > > voice (or other) application boots up in case it is needed=20 > at a later=20 > > time." > >=20 > > Thanks, > >=20 > > -Marc- > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 26 10:46:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuFm-0007HS-Ty; Mon, 26 Sep 2005 10:46:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFzsu-0002n5-Ve; Thu, 15 Sep 2005 15:59:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02065; Thu, 15 Sep 2005 15:59:02 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFzxl-0003Af-DK; Thu, 15 Sep 2005 16:04:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Sep 2005 21:58:47 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4516@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] RE: draft-polk-dhc-uri-00 Thread-Index: AcW5dLaN0VyI7mkQSh6csVrk6ft3hgABF6jgAC2zVW4= From: "Stastny Richard" To: "Marc Linsner" , "James M. Polk" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 26 Sep 2005 10:46:39 -0400 Cc: dhcwg@ietf.org, ECRIT Subject: [dhcwg] RE: [Ecrit] RE: draft-polk-dhc-uri-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Is there a possibility to get this question back to facts: what will the average call setup delay be for lets say one additional DNS query to the x queries required to do the call-setup from the client to the PSAP, eventually via an ESRP and a ESGW in the first place? Richard ________________________________ Von: ecrit-bounces@ietf.org im Auftrag von Marc Linsner Gesendet: Do 15.09.2005 21:38 An: 'James M. Polk' Cc: dhcwg@ietf.org; 'ECRIT' Betreff: [Ecrit] RE: draft-polk-dhc-uri-00 James, Thanks for your answer. My question was about the basis for your = assertion that it is 'more appropriate' to perform location to psap uri mapping at host configuration setup time vs. emergency call setup time. I derive = from your answer that your basis for this assertion is getting this task done prior to call setup, making call setup faster and possibly more = reliable. More comments in-line.... > At 08:48 AM 9/14/2005 -0400, Marc Linsner wrote: > >James, > > > >Would you please provide the basis for your text below regarding the > >timing of psap determination, I can't seem to match it up > with any of > >the requirements within ecrit or geopriv. > > When something is urgent, do you want to invoke more > processing complexity or less processing complexity? More > typically means "more prone to errors", less typically means > "less prone to errors". No one can argue that simple is good, but there must be a balance with = all requirements. > Everyone hear is assuming that the UA > providing location will get mapped to the appropriate PSAP > within a reasonable call set-up timeframe. This assumption is based on years of experience, it's the way things = have work for 30+ years. There is every expectation of success in = duplicating a like mechanism using Internet techologies. If that wasn't possible, we wouldn't be having this conversation as there would not be a PSTN-like capability on the Internet. > > This document suggests an optimization - to do the "mapping" > before time is wasted doing the mapping just to set-up the call. It is not clear such optimization is necessary. We don't have a = 'failed' mechanism (yet). -Marc- > > The ECRIT Charter says: > > (item #1) "Successful delivery of an emergency service call > within those systems requires both an association of the > physical location of the originator with an appropriate > emergency service center and call routing to deliver the call > to the center." > > and > > (item #2) "Calls placed using Internet technologies do not > use the same systems to achieve those goals, and the common > use of overlay networks and tunnels (either as VPNs or for > mobility) makes meeting them more challenging. There are, > however, Internet technologies available to describe location > and to manage call routing. This working group will describe > when these may be appropriate and how they may be used." > > and > > (item #3) "The group will show how the availability of > location data and call routing information at different steps > in session setup would enable communication between a user > and a relevant emergency response center. " > > Item # 1 talks the association of user location and the > appropriate PSAP. > - This ID describes this by using the same Link > provider that knows the > UA's location (and give the UA its location. > > Item #2 talks about describing location and managing call > routing - specifically "when" these may be appropriate. > - This ID describes accomplishing this mapping > before call set-up. > - I don't remember reading a requirement in either > WG that says > "this mapping function MUST take place *only* during > call set-up". > > Item #3 talks about different information at different times > in the session set-up. > - This ID provides the Request-URI for the INVITE > message, plus provides > an alternate Request-URI, plus the URI of the ESGW and ESRP. > > SIP Proxies will determine if a route is available or not, > and reroute around any problems if there are any. A URI is > not an IP Address, of which there is one. The same URI can go > to many difference locations in times of overload or error. > Webservers have been doing this function for better than > 5 years now. > > > >"One example of this URI download would be one specifically > for the SIP > >or SIPS URI of the appropriate Public Safety Answer Point (PSAP) for > >the client when the user of that client calls for emergency > help (911 > >or 112-type of help). This is not a transaction that should > take place > >when a voice application wants to make such a critical call > set-up. It > >is more appropriate that this information be downloaded to > the client > >when the voice (or other) application boots up in case it is > needed at a later time." > > > >Thanks, > > > >-Marc- > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 26 10:46:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuFn-0007Hr-I0; Mon, 26 Sep 2005 10:46:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJdJY-00028o-SC for dhcwg@megatron.ietf.org; Sun, 25 Sep 2005 16:41:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01674 for ; Sun, 25 Sep 2005 16:41:26 -0400 (EDT) Received: from bay106-f11.bay106.hotmail.com ([65.54.161.21] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJdQL-0007dN-Eg for dhcwg@ietf.org; Sun, 25 Sep 2005 16:48:37 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 25 Sep 2005 13:41:18 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sun, 25 Sep 2005 20:41:18 GMT X-Originating-IP: [65.54.161.200] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: dhcwg@ietf.org Date: Sun, 25 Sep 2005 13:41:18 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 25 Sep 2005 20:41:18.0812 (UTC) FILETIME=[7B4291C0:01C5C211] X-Spam-Score: 0.8 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Mon, 26 Sep 2005 10:46:39 -0400 Subject: [dhcwg] Simplification of DNAv4 specification X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org It has been suggested that the DNAv4 specification can be simplified by recommending that implementations simultaneously test reachability to one or more networks in parallel with attempting to obtain a configuration via DHCPv4. While the current specification allows this, it is optional rather than recommended behavior, and so the specification still has to accomodate the case where an implementation attempts to obtain configuration serially. By assuming that the implementation attempts to obtain configuration by multiple mechanisms in parallel, it can be guaranteed that DNAv4 will not take longer than DHCPv4 to obtain a configuration. It also simplifies the DNAv4 client implementation, since the client can determine the set of networks for which it has an operable configuration, and select a subset of that for reachability testing without having to consider link layer hints. For example, if a host has a still-valid DHCP leases on three networks, it can do 3 reachability tests in parallel with attempting to obtain a configuration via DHCPv4. The downside of this approach is the extra traffic. However, this risk can probably be mitigated via rate limiting, jittering and exponential backoff. Therefore, it appears to me that the benefits of this approach, in terms of a simplified implementation and improved performance and robustness are worth the costs. Before making the sugested edits to the document, I thought I would gauge WG reaction first. A strawman draft is available here: http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-ipv4-16.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 26 10:51:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuKV-00088k-8s; Mon, 26 Sep 2005 10:51:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuIy-0007j5-Mk; Mon, 26 Sep 2005 10:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02157; Mon, 26 Sep 2005 10:50:06 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJuPx-0007LQ-PC; Mon, 26 Sep 2005 10:57:23 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EJuIs-0006en-MI; Mon, 26 Sep 2005 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 26 Sep 2005 10:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-fqdn-option-11.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --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 : The DHCP Client FQDN Option Author(s) : M. Stapp, et al. Filename : draft-ietf-dhc-fqdn-option-11.txt Pages : 16 Date : 2005-9-26 This document specifies a DHCP for IPv4, DHCPv4, option which can be used to exchange information about a DHCPv4 client's fully-qualified domain name and about responsibility for updating the DNS RR related to the client's address assignment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-fqdn-option-11.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-fqdn-option-11.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: <2005-9-26103738.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-fqdn-option-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-fqdn-option-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-26103738.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Tue Sep 27 14:05:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKJq1-0002Qq-2I; Tue, 27 Sep 2005 14:05:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKJpz-0002QY-PS for dhcwg@megatron.ietf.org; Tue, 27 Sep 2005 14:05:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28111 for ; Tue, 27 Sep 2005 14:05:54 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKJxH-0004lh-5m for dhcwg@ietf.org; Tue, 27 Sep 2005 14:13:28 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j8RI5heV023565 for ; Tue, 27 Sep 2005 20:05:43 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j8RI5hCr001823 for ; Tue, 27 Sep 2005 20:05:43 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j8RI5h1R001822 for dhcwg@ietf.org; Tue, 27 Sep 2005 20:05:43 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 27 Sep 2005 20:05:42 +0200 From: Stig Venaas To: dhcwg@ietf.org Message-ID: <20050927180542.GF1742@storhaugen.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [dhcwg] FYI: Internet-Drafts Submission Cutoff Dates for Vancouver X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I'm sure most of you have seen the cutoff dates, but anyway... Stig ----- Forwarded message from ietf-secretariat@ietf.org ----- To: ietf-announce@ietf.org From: ietf-secretariat@ietf.org Date: Fri, 23 Sep 2005 00:00:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: Internet-Drafts Submission Cutoff Dates for the 64th IETF Meeting in Vancouver, British Columbia, Canada X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on tyholt.uninett.no X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.63 X-Spam-Level: There are two (2) Internet-Draft cutoff dates for the 64th IETF Meeting in Vancouver, British Columbia, Canada: October 17th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, October 17th at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, October 10th at 9:00 AM ET. October 24th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, October 24th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, November 7th at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 64th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_64.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ----- End forwarded message ----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 28 12:35:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKeta-0000Y8-HX; Wed, 28 Sep 2005 12:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKetY-0000Xt-Rs for dhcwg@megatron.ietf.org; Wed, 28 Sep 2005 12:35:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18443 for ; Wed, 28 Sep 2005 12:34:58 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKf10-0001re-5s for dhcwg@ietf.org; Wed, 28 Sep 2005 12:42:45 -0400 Received: from lion.cs.columbia.edu (IDENT:nK98YkKrq8lnLnxzrpOf+IJMVhRSUM9h@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j8SGYGsw025133 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 28 Sep 2005 12:34:17 -0400 (EDT) Received: from [128.59.19.228] (dhcp28.cs.columbia.edu [128.59.19.228]) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id j8SGYGhM019975; Wed, 28 Sep 2005 12:34:16 -0400 Message-ID: <433AC59A.10508@cs.columbia.edu> Date: Wed, 28 Sep 2005 12:32:26 -0400 From: Andrea G Forte User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Droms Subject: Re: [dhcwg] DAD in DHCPv6. References: <43345F0B.2070900@cs.columbia.edu> <1127506412.9624.16.camel@dhcp-guest-bxb22-64-102-164-26.cisco.com> In-Reply-To: <1127506412.9624.16.camel@dhcp-guest-bxb22-64-102-164-26.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Thank you for your response. I have to say though that this is rather confusing as [17] is referring to the statless configuration (and this misleaded me in the beginning). Furthermore in [17] DAD MUST be performed in either stateful, stateless or manual, while in RFC 3315 DAD SHOULD be performed. Which one of the two is it? Thank you, -Andrea Ralph Droms wrote: >>From RFC 3315, section 18.1.8: > > The client SHOULD perform duplicate address detection [17] on each of > the addresses in any IAs it receives in the Reply message before > using that address for traffic. If any of the addresses are found to > be in use on the link, the client sends a Decline message to the > server as described in section 18.1.7. > >- Ralph > >On Fri, 2005-09-23 at 16:01 -0400, Andrea G Forte wrote: > > >>Hi everyone, >> >>I have a question about DHCPv6 and the statefull address configuration. It >>seems that DAD is performed only in the stateless procedure and no DAD >>at all is performed in the stateful procedure. How can the DHCP server >>be sure that the IP address that is going to assign has not been >>manually configured by someone other client? (Which is the reason for >>having DAD in DHCPv4). >> >>Thank you, >>Andrea >> >> >>_______________________________________________ >>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-bounces@ietf.org Wed Sep 28 12:53:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKfB3-0005Z5-LZ; Wed, 28 Sep 2005 12:53:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKfB3-0005Z0-48 for dhcwg@megatron.ietf.org; Wed, 28 Sep 2005 12:53:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19602 for ; Wed, 28 Sep 2005 12:53:02 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKfIV-0002LL-Ee for dhcwg@ietf.org; Wed, 28 Sep 2005 13:00:49 -0400 Received: from [66.93.162.100] (mdzod.fugue.com [66.93.162.100]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 4654E5688A; Wed, 28 Sep 2005 09:52:42 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <433AC59A.10508@cs.columbia.edu> References: <43345F0B.2070900@cs.columbia.edu> <1127506412.9624.16.camel@dhcp-guest-bxb22-64-102-164-26.cisco.com> <433AC59A.10508@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v745) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] DAD in DHCPv6. Date: Wed, 28 Sep 2005 09:52:34 -0700 To: Andrea G Forte X-Mailer: Apple Mail (2.745) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Ralph Droms X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Sep 28, 2005, at 9:32 AM, Andrea G Forte wrote: > I have to say though that this is rather confusing as [17] is > referring to the statless configuration (and this misleaded me in > the beginning). Furthermore in [17] DAD MUST be performed in either > stateful, stateless or manual, while in RFC 3315 DAD SHOULD be > performed. Which one of the two is it? I guess the presumption is that in stateless, the chances of an address conflict are significantly higher than in stateful, thus a MUST for stateless, and a SHOULD for stateful. In general we try to avoid saying MUST if it's not necessary; for example, in a mobile phone environment, where battery life is affected by how many packets the phone transmits, you really want to be able to avoid sending extra packets. In this environment, the operator has much more control over what happens on the link, so there's no real need for DAD, and in that case we'd expect the cell phone DHCPv6 implementation to violate the SHOULD. It's probably the case that in the next rev of these RFCs, there should be some harmonization work done - it's really very early days for the DHCPv6 protocol, as you've no doubt noticed, and there are a few rough edges left to sand down. :'} _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 28 14:03:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKgHI-0004gS-U9; Wed, 28 Sep 2005 14:03:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKgHH-0004gN-NQ for dhcwg@megatron.ietf.org; Wed, 28 Sep 2005 14:03:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26097 for ; Wed, 28 Sep 2005 14:03:34 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKgOk-0005Cn-6j for dhcwg@ietf.org; Wed, 28 Sep 2005 14:11:20 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j8SI2iBT014422; Wed, 28 Sep 2005 11:02:44 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j8SI2cZ5018709; Wed, 28 Sep 2005 11:02:38 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j8SI2bpg018704; Wed, 28 Sep 2005 11:02:38 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 28 Sep 2005 11:02:37 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: DHC WG Subject: RE: [dhcwg] RFC 3942 notice: GNU GRUB, DHCP option 150 In-Reply-To: <200503121425.10060.okuji@gnu.org> <200503121807.APT64160@flask.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "Richard A. Johnson" , Bernie Volz , BUG-GRUB , "Yoshinori K. Okuji" , Ralph Droms X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Saturday, March 12, 2005 8:25 AM Yoshinori K. Okuji wrote: Okuji> I would like to notify that GNU GRUB uses the DHCP option Okuji> 150, according to Okuji> RFC 3942. Okuji> Okuji> GNU GRUB Configuration Path Okuji> Okuji> This specifies the path-name that contains a configuration Okuji> for GNU GRUB. Okuji> Okuji> The code for this option is 150. Its minimum length is 1. Okuji> Okuji> Code Len Configuration Pathname Okuji> +-----+-----+-----+-----+-----+-----+-- Okuji> | 150 | n | n1 | n2 | n3 | n4 | ... Okuji> +-----+-----+-----+-----+-----+-----+-- >>>>> On Sat, 12 Mar 2005 13:07:35 -0500 Bernie Volz replied: Bernie> Looks like we now have 3 "users" of Option 150: Bernie> Bernie> 1. GNU GRUB Bernie> 2. DRAFT-RAJ-DHC-TFTP-ADDR-OPTION-00.TXT Bernie> 3. Etherboot In http://www.iana.org/assignments/bootp-dhcp-parameters, however, I see the following: 150 TFTP server address (Tentatively Assigned - 23 Jun 2005) 150 Etherboot 150 GRUB configuration path name This seems to contradict RFC 3942, which says that if multiple vendors come forward none will be assigned the option: NOTE: If multiple vendors of an option number come forward and can demonstrate that their usage is in reasonably wide use, none of the vendors will be allowed to keep the current option number, and they MUST go through the normal process of getting a publicly assigned option [RFC2939]. What gives? //cmh _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 28 14:33:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKgkG-00046A-7P; Wed, 28 Sep 2005 14:33:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKgkF-000465-0m for dhcwg@megatron.ietf.org; Wed, 28 Sep 2005 14:33:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27656 for ; Wed, 28 Sep 2005 14:33:29 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKgrk-00061J-HC for dhcwg@ietf.org; Wed, 28 Sep 2005 14:41:16 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 Sep 2005 14:33:22 -0400 X-IronPort-AV: i="3.97,154,1125892800"; d="scan'208"; a="72161305:sNHT32413700" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8SIWaTg012983; Wed, 28 Sep 2005 14:33:19 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Sep 2005 14:33:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RFC 3942 notice: GNU GRUB, DHCP option 150 Date: Wed, 28 Sep 2005 14:33:06 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21A81EDB@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] RFC 3942 notice: GNU GRUB, DHCP option 150 Thread-Index: AcXEVvJLf8S616HNRVOoOjamFEmzMAAAy5bQ From: "Bernie Volz \(volz\)" To: "C. M. Heard" , "DHC WG" X-OriginalArrivalTime: 28 Sep 2005 18:33:07.0239 (UTC) FILETIME=[11F6EB70:01C5C45B] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: BUG-GRUB , "Richard Johnson \(raj\)" , "Yoshinori K. Okuji" , "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Well, what you like us to do? Software is shipping with these codes, and documenting the fact that there are conflicts are useful. What the 3942 is saying is that when these folks go for an "IETF"/"IANA" assigned option for non-conflicting use, they won't be able to use 150. The I-Ds that they write should document the historic usage (that option 150 was/is in use). But, they should also request a NEW official IANA assignment. And, IANA obviously can't put option 150 in the pool for future options. Given what we know today, RFC 3942 could certainly have documented more of this, but it also would have greatly complicated the description. - Bernie =20 > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com]=20 > Sent: Wednesday, September 28, 2005 2:03 PM > To: DHC WG > Cc: Bernie Volz (volz); Ralph Droms (rdroms); Richard Johnson=20 > (raj); Timothy Legge; Yoshinori K. Okuji; BUG-GRUB > Subject: RE: [dhcwg] RFC 3942 notice: GNU GRUB, DHCP option 150 >=20 > >>>>> On Saturday, March 12, 2005 8:25 AM Yoshinori K. Okuji wrote: > Okuji> I would like to notify that GNU GRUB uses the DHCP option > Okuji> 150, according to > Okuji> RFC 3942. > Okuji> > Okuji> GNU GRUB Configuration Path > Okuji> > Okuji> This specifies the path-name that contains a configuration > Okuji> for GNU GRUB. > Okuji> > Okuji> The code for this option is 150. Its minimum length is 1. > Okuji> > Okuji> Code Len Configuration Pathname > Okuji> +-----+-----+-----+-----+-----+-----+-- > Okuji> | 150 | n | n1 | n2 | n3 | n4 | ... > Okuji> +-----+-----+-----+-----+-----+-----+-- >=20 > >>>>> On Sat, 12 Mar 2005 13:07:35 -0500 Bernie Volz replied: > Bernie> Looks like we now have 3 "users" of Option 150: > Bernie>=20 > Bernie> 1. GNU GRUB > Bernie> 2. DRAFT-RAJ-DHC-TFTP-ADDR-OPTION-00.TXT > Bernie> 3. Etherboot >=20 > In http://www.iana.org/assignments/bootp-dhcp-parameters, however, > I see the following: >=20 > 150 TFTP server address (Tentatively Assigned - 23 Jun 2005) > 150 Etherboot=09 > 150 GRUB configuration path name >=20 > This seems to contradict RFC 3942, which says that if multiple vendors > come forward none will be assigned the option: >=20 > NOTE: If multiple vendors of an option number come=20 > forward and can > demonstrate that their usage is in reasonably wide use, none of > the vendors will be allowed to keep the current option=20 > number, and > they MUST go through the normal process of getting a publicly > assigned option [RFC2939]. =20 >=20 > What gives? >=20 > //cmh >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 28 14:55:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKh5U-0001gp-Pi; Wed, 28 Sep 2005 14:55:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKh5T-0001fV-Eo for dhcwg@megatron.ietf.org; Wed, 28 Sep 2005 14:55:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28758 for ; Wed, 28 Sep 2005 14:55:26 -0400 (EDT) Received: from kaboom.isc.org ([204.152.187.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKhCw-0006WM-7w for dhcwg@ietf.org; Wed, 28 Sep 2005 15:03:13 -0400 Received: by kaboom.isc.org (Postfix, from userid 10200) id 750BCB246E; Wed, 28 Sep 2005 11:54:27 -0700 (PDT) Date: Wed, 28 Sep 2005 11:54:27 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] RFC 3942 notice: GNU GRUB, DHCP option 150 Message-ID: <20050928185427.GC39648@isc.org> References: <8E296595B6471A4689555D5D725EBB21A81EDB@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <8E296595B6471A4689555D5D725EBB21A81EDB@xmb-rtp-20a.amer.cisco.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0688063330==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0688063330== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eJnRUKwClWJh1Khz" Content-Disposition: inline --eJnRUKwClWJh1Khz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 28, 2005 at 02:33:06PM -0400, Bernie Volz (volz) wrote: > Well, what you like us to do? I think he is concerned about the words 'tentatively assigned' that appears only on the 'TFTP Server Address' incarnation of the option. A simple misunderstanding, I think. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --eJnRUKwClWJh1Khz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFDOubjcXeLeWu2vmoRAtqGAJ4wz7cJ88m8ZaC8VczbzBCN7iY8SgCgp0/+ RPnxzZov0Fl3UqUELo7eSbE= =EgDK -----END PGP SIGNATURE----- --eJnRUKwClWJh1Khz-- --===============0688063330== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0688063330==-- From dhcwg-bounces@ietf.org Wed Sep 28 15:07:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKhGi-0004Vi-8s; Wed, 28 Sep 2005 15:07:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKhGg-0004UZ-LF for dhcwg@megatron.ietf.org; Wed, 28 Sep 2005 15:07:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29633 for ; Wed, 28 Sep 2005 15:07:01 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKhOB-0006sH-9p for dhcwg@ietf.org; Wed, 28 Sep 2005 15:14:48 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 28 Sep 2005 12:06:52 -0700 X-IronPort-AV: i="3.97,154,1125903600"; d="scan'208"; a="215556456:sNHT30602732" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j8SJ6Wuu026557; Wed, 28 Sep 2005 12:06:50 -0700 (PDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Sep 2005 15:06:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RFC 3942 notice: GNU GRUB, DHCP option 150 Date: Wed, 28 Sep 2005 15:06:27 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21A81F13@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] RFC 3942 notice: GNU GRUB, DHCP option 150 Thread-Index: AcXEXtFUTBlsPAQYRhSXAvrg8L8qbwAAElIQ From: "Bernie Volz \(volz\)" To: "David W. Hankins" , X-OriginalArrivalTime: 28 Sep 2005 19:06:28.0318 (UTC) FILETIME=[BAB357E0:01C5C45F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Oh, OK. That was just a choice not to repeat tentatively assigned for each of the entries when there was more than one for a single option number. - Bernie=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of David W. Hankins > Sent: Wednesday, September 28, 2005 2:54 PM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] RFC 3942 notice: GNU GRUB, DHCP option 150 >=20 > On Wed, Sep 28, 2005 at 02:33:06PM -0400, Bernie Volz (volz) wrote: > > Well, what you like us to do? >=20 > I think he is concerned about the words 'tentatively assigned' that > appears only on the 'TFTP Server Address' incarnation of the option. >=20 > A simple misunderstanding, I think. >=20 > --=20 > David W. Hankins "If you don't do it right the=20 > first time, > Software Engineer you'll just have to do=20 > it again." > Internet Systems Consortium, Inc. -- Jack T. Hankins >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 28 15:21:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKhV6-0008Ut-0L; Wed, 28 Sep 2005 15:21:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKhV3-0008Pu-Ia for dhcwg@megatron.ietf.org; Wed, 28 Sep 2005 15:21:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01211 for ; Wed, 28 Sep 2005 15:21:51 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKhcW-0007HW-9t for dhcwg@ietf.org; Wed, 28 Sep 2005 15:29:39 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j8SJLYBT006077; Wed, 28 Sep 2005 12:21:34 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j8SJLJah007446; Wed, 28 Sep 2005 12:21:19 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j8SJLJ1L007443; Wed, 28 Sep 2005 12:21:19 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 28 Sep 2005 12:21:19 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: "Bernie Volz (volz)" Subject: RE: [dhcwg] RFC 3942 notice: GNU GRUB, DHCP option 150 In-Reply-To: <8E296595B6471A4689555D5D725EBB21A81EDB@xmb-rtp-20a.amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "Richard Johnson \(raj\)" , BUG-GRUB , DHC WG , "Yoshinori K. Okuji" , "Ralph Droms \(rdroms\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Wed, 28 Sep 2005, Bernie Volz (volz) wrote: > Well, what you like us to do? > > Software is shipping with these codes, and documenting the fact that > there are conflicts are useful. > > What the 3942 is saying is that when these folks go for an "IETF"/"IANA" > assigned option for non-conflicting use, they won't be able to use 150. > The I-Ds that they write should document the historic usage (that option > 150 was/is in use). But, they should also request a NEW official IANA > assignment. > > And, IANA obviously can't put option 150 in the pool for future options. > > Given what we know today, RFC 3942 could certainly have documented more > of this, but it also would have greatly complicated the description. The reason I raised the issue is because the registry entry in http://www.iana.org/assignments/bootp-dhcp-parameters seems to suggest the option is tentatively assigned to one of the three vendor-specific uses: | 150 TFTP server address (Tentatively Assigned - 23 Jun 2005) | 150 Etherboot | 150 GRUB configuration path name My apologies if I misread the intent. //cmh _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 28 15:50:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKhwn-0007YF-TL; Wed, 28 Sep 2005 15:50:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKhwL-0007OV-KV; Wed, 28 Sep 2005 15:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02861; Wed, 28 Sep 2005 15:50:03 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKi3o-0007w6-RR; Wed, 28 Sep 2005 15:57:49 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EKhwH-00012o-Qr; Wed, 28 Sep 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Sep 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-bcmc-options-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --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 Broadcast and Multicast Control Servers Author(s) : K. Chowdhury, et al. Filename : draft-ietf-dhc-bcmc-options-04.txt Pages : 15 Date : 2005-9-28 This document defines new options to discover the Broadcast and Multicast Service (BCMCS) controller in an IP network. BCMCS is being developed for 3rd generation (3G) cellular telephone networks. Users of the service interact with a controller in the network via the Mobile Node (MN) to derive information required to receive broadcast and multicast service. Dynamic Host Configuration Protocol can be used to configure the MN to access a particular controller. This document defines the related options and option codes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-bcmc-options-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-bcmc-options-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-bcmc-options-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: <2005-9-28131915.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-bcmc-options-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-bcmc-options-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-28131915.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Thu Sep 29 13:06:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL1rs-0002W1-Mx; Thu, 29 Sep 2005 13:06:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL1rq-0002Vw-OE for dhcwg@megatron.ietf.org; Thu, 29 Sep 2005 13:06:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22854 for ; Thu, 29 Sep 2005 13:06:43 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL1zX-0007cV-4w for dhcwg@ietf.org; Thu, 29 Sep 2005 13:14:44 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 29 Sep 2005 10:06:37 -0700 X-IronPort-AV: i="3.97,158,1125903600"; d="scan'208"; a="662720823:sNHT29668592" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8TH6S52013226 for ; Thu, 29 Sep 2005 10:06:35 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 10:06:33 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.161]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 10:06:33 -0700 Message-Id: <4.3.2.7.2.20050929115545.034ed820@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Sep 2005 12:06:02 -0500 To: dhcwg@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 29 Sep 2005 17:06:33.0568 (UTC) FILETIME=[24B55E00:01C5C518] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [dhcwg] Updated ID notice: draft-polk-dhc-uri-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org DHC WG For those interested... http://www.ietf.org/internet-drafts/draft-polk-dhc-uri-01.txt I've updated this ID to -01 with the following changes: - added a second URI to the main bit format in Figure 1. - Added several requirements - Deleted several rules surrounding how to get around RFC3396 (silly me!), which are no longer necessary, because I... - brought this document in line with RFC3396, including the sub-option length parameter per URI - removed the ability to concatenate fields As a result of the above bullet, I don't like the side effect of limiting the total Option field length to 253 bytes. I'd like to be able to have more than one URI in a message (up to 576 bytes - if there is room), but 3396 limits more than one instance of a Option to being a concatenated field. Any suggestions on getting around that would be helpful. - modified the doc to limit the size of a URI to 253 bytes max - Added a section on how multiple URIs are derived - Added a section on how a client requests one or more URIs - Edited terms to be more consistent with the ECRIT Reqs ID - Added new concerns to the Security Considerations Comments area appreciated cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 29 13:15:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL20Y-0005Vm-K3; Thu, 29 Sep 2005 13:15:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL20X-0005VN-7M for dhcwg@megatron.ietf.org; Thu, 29 Sep 2005 13:15:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23315 for ; Thu, 29 Sep 2005 13:15:41 -0400 (EDT) Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL28D-0007s8-Mj for dhcwg@ietf.org; Thu, 29 Sep 2005 13:23:43 -0400 Received: from openexchange.incognito.com ([192.168.77.70]) by chimera.incognito.com with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EL20D-0001fk-FW; Thu, 29 Sep 2005 10:15:25 -0700 Received: from [192.168.75.75] (unknown [192.168.75.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by openexchange.incognito.com (Postfix) with ESMTP id 2245E19977; Thu, 29 Sep 2005 10:30:43 -0700 (PDT) Message-ID: <433C212C.6030009@openexchange.incognito.com> Date: Thu, 29 Sep 2005 10:15:24 -0700 From: Andre Kostur Organization: Incognito Software Inc. User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [dhcwg] Updated ID notice: draft-polk-dhc-uri-01 References: <4.3.2.7.2.20050929115545.034ed820@email.cisco.com> In-Reply-To: <4.3.2.7.2.20050929115545.034ed820@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -5.9 (-----) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org James M. Polk wrote: > I've updated this ID to -01 with the following changes: > > - added a second URI to the main bit format in Figure 1. > > - Added several requirements > > - Deleted several rules surrounding how to get around RFC3396 > (silly me!), which are no longer necessary, because I... > > - brought this document in line with RFC3396, including the > sub-option length parameter per URI > > - removed the ability to concatenate fields > > As a result of the above bullet, I don't like the side effect of > limiting the total Option field length to 253 bytes. I'd like to be > able to have more than one URI in a message (up to 576 bytes - if > there is room), but 3396 limits more than one instance of a Option to > being a concatenated field. Any suggestions on getting around that > would be helpful. How does this limit the total Option field to 253 bytes? You can just keep re-specifying your uri option over and over again, each one supplying an URI. The client concatenates all of the URI options together (for a total length of up to n * 253 bytes), and uses the individual uri lengths to break out the individual URIs... _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 29 13:32:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL2Gu-000198-BZ; Thu, 29 Sep 2005 13:32:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL2Gs-00017K-Gq for dhcwg@megatron.ietf.org; Thu, 29 Sep 2005 13:32:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24113 for ; Thu, 29 Sep 2005 13:32:34 -0400 (EDT) Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL2OZ-0008LF-2G for dhcwg@ietf.org; Thu, 29 Sep 2005 13:40:36 -0400 Received: from openexchange.incognito.com ([192.168.77.70]) by chimera.incognito.com with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EL2Gg-0001jG-LL; Thu, 29 Sep 2005 10:32:28 -0700 Received: from [192.168.75.75] (unknown [192.168.75.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by openexchange.incognito.com (Postfix) with ESMTP id 7C49A19981; Thu, 29 Sep 2005 10:47:44 -0700 (PDT) Message-ID: <433C252A.4070703@openexchange.incognito.com> Date: Thu, 29 Sep 2005 10:32:26 -0700 From: Andre Kostur Organization: Incognito Software Inc. User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [dhcwg] Updated ID notice: draft-polk-dhc-uri-01 References: <4.3.2.7.2.20050929115545.034ed820@email.cisco.com> In-Reply-To: <4.3.2.7.2.20050929115545.034ed820@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -5.9 (-----) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org James M. Polk wrote: > > http://www.ietf.org/internet-drafts/draft-polk-dhc-uri-01.txt > Other more general comments: Section 1: A client may request more than one URI be sent to it within the same DHCPDISCOVER or DHCPREQUEST message. Each URI will be inside its own payload container with an Option number, a length field and a purpose field. This means that if more than one URI is being requested or downloaded, there can be more than one DHCP Option XXX (this document's option number) in the same IP message. Each URI will be inside the DHCP Option payload shown in section 2 of this document. There is no meaning to the order of URIs in a message. Why does this imply that there is a mapping of 1 URI to 1 DHCP Option XXX? If one has 4 10-byte URIs, why can't all 4 be in the same instance of the Option? Section 2.1: - [RFC2131] limits the size of an Option to 255 bytes, and this Option is no different. If there are more than one URI to be sent to a client, and the aggregate byte count is greater than 255 bytes, the URIs will be sent in more than one message to the client. You don't get multiple messages. Only 1 message. This statement seems to imply that if the server wanted to send many URIs to the client, it could send multiple DHCPACKs to the client to transmit them all. You probably mean to say: "the URIs will be sent in more than one instance of the URI option" (or something similar). Section 2.1: - Server responses to a request for more than one URI MAY be in separate messages (i.e. one URI per message), at the server's discretion Same as above. Section 2.3: Conceivably though, each available URI purpose MAY be in a DHC message. The client MUST be prepared to receive each URI requested, even in separate messages from the server. The client MUST NOT request the same URI purpose more than once in the same message. Same as above. Also, this specification doesn't say what format URI's are in. And perhaps it should carry a reference to RFC 3986 - "Uniform Resrouce Identifier (URI): Generic Syntax"? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 29 13:35:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL2JX-0002Qe-D4; Thu, 29 Sep 2005 13:35:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL2JU-0002QZ-W8 for dhcwg@megatron.ietf.org; Thu, 29 Sep 2005 13:35:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24247 for ; Thu, 29 Sep 2005 13:35:19 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL2RB-0008QY-Kt for dhcwg@ietf.org; Thu, 29 Sep 2005 13:43:18 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 29 Sep 2005 10:35:09 -0700 X-IronPort-AV: i="3.97,158,1125903600"; d="scan'208"; a="662728215:sNHT31707012" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8THYqKK010638; Thu, 29 Sep 2005 10:35:01 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 10:35:00 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.161]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 10:34:59 -0700 Message-Id: <4.3.2.7.2.20050929122932.04520380@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Sep 2005 12:34:58 -0500 To: Andre Kostur From: "James M. Polk" Subject: Re: [dhcwg] Updated ID notice: draft-polk-dhc-uri-01 In-Reply-To: <433C212C.6030009@openexchange.incognito.com> References: <4.3.2.7.2.20050929115545.034ed820@email.cisco.com> <4.3.2.7.2.20050929115545.034ed820@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 29 Sep 2005 17:34:59.0881 (UTC) FILETIME=[1DC01190:01C5C51C] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org At 10:15 AM 9/29/2005 -0700, Andre Kostur wrote: >James M. Polk wrote: >> - removed the ability to concatenate fields >> >>As a result of the above bullet, I don't like the side effect of limiting >>the total Option field length to 253 bytes. I'd like to be able to have >>more than one URI in a message (up to 576 bytes - if there is room), but >>3396 limits more than one instance of a Option to being a concatenated >>field. Any suggestions on getting around that would be helpful. > >How does this limit the total Option field to 253 bytes? You can just >keep re-specifying your uri option over and over again, each one supplying >an URI. The client concatenates all of the URI options together (for a >total length of up to n * 253 bytes), and uses the individual uri lengths >to break out the individual URIs... Really? I didn't read this facet/flexibility from 3396 so, I have to admit, I had no idea this was possible. This is great if true - and I have no reason not to believe you. I see an -02 coming very soon then with this clarification. Thank you, Andre! cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 29 13:56:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL2dX-0007Kd-08; Thu, 29 Sep 2005 13:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL2dV-0007KP-MS for dhcwg@megatron.ietf.org; Thu, 29 Sep 2005 13:56:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25135 for ; Thu, 29 Sep 2005 13:55:59 -0400 (EDT) Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL2lD-0000U9-DQ for dhcwg@ietf.org; Thu, 29 Sep 2005 14:03:59 -0400 Received: from openexchange.incognito.com ([192.168.77.70]) by chimera.incognito.com with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EL2dL-0001np-9v; Thu, 29 Sep 2005 10:55:51 -0700 Received: from [192.168.75.75] (unknown [192.168.75.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by openexchange.incognito.com (Postfix) with ESMTP id 679771998B; Thu, 29 Sep 2005 11:11:09 -0700 (PDT) Message-ID: <433C2AA4.50206@openexchange.incognito.com> Date: Thu, 29 Sep 2005 10:55:48 -0700 From: Andre Kostur Organization: Incognito Software Inc. User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [dhcwg] Updated ID notice: draft-polk-dhc-uri-01 References: <4.3.2.7.2.20050929115545.034ed820@email.cisco.com> <4.3.2.7.2.20050929115545.034ed820@email.cisco.com> <4.3.2.7.2.20050929122932.04520380@email.cisco.com> In-Reply-To: <4.3.2.7.2.20050929122932.04520380@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -5.9 (-----) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org James M. Polk wrote: > At 10:15 AM 9/29/2005 -0700, Andre Kostur wrote: > >> James M. Polk wrote: >> >>> - removed the ability to concatenate fields >>> >>> As a result of the above bullet, I don't like the side effect of >>> limiting the total Option field length to 253 bytes. I'd like to be >>> able to have more than one URI in a message (up to 576 bytes - if >>> there is room), but 3396 limits more than one instance of a Option >>> to being a concatenated field. Any suggestions on getting around >>> that would be helpful. >> >> >> How does this limit the total Option field to 253 bytes? You can >> just keep re-specifying your uri option over and over again, each one >> supplying an URI. The client concatenates all of the URI options >> together (for a total length of up to n * 253 bytes), and uses the >> individual uri lengths to break out the individual URIs... > > > Really? > > I didn't read this facet/flexibility from 3396 so, I have to admit, I > had no idea this was possible. > > This is great if true - and I have no reason not to believe you. > > I see an -02 coming very soon then with this clarification. > > Thank you, Andre! > Take a look at RFC 3396, section 8. It shows an example of a 13-byte Option 67 being split into two instances of option 67, one with 7 bytes, one with 8 bytes. On the client side, it would reassemble that into a single Option 67 with an aggregate length of 13 bytes. In your case you could have an URI Option of length 500 bytes. The server would need to split it into one of 255 bytes, and one of 245 bytes (or split it into 3 options of 200, 200, and 100 bytes... as long as it adds up to the 500 bytes, and no single instance is longer than 255, it's fine). On the client side, it would need to reassemble all of the pieces back into the aggregate 500 byte option. Then it can parse through it to recover the individual URIs as necessary. (Oh.. also assuming that the client can accept that large of a DHCP packet... but that's a different consideration. Recall that clients may negotiate a larger DHCP packet side.... see RFC 2132, section 9.10). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 29 15:50:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL4QM-0006Qf-Ci; Thu, 29 Sep 2005 15:50:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL4Ps-0006Gc-QH; Thu, 29 Sep 2005 15:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01572; Thu, 29 Sep 2005 15:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL4XZ-00039D-GM; Thu, 29 Sep 2005 15:58:02 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EL4Pp-00066x-Ri; Thu, 29 Sep 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 29 Sep 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dna-ipv4-16.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --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 : Detecting Network Attachment (DNA) in IPv4 Author(s) : B. Aboba Filename : draft-ietf-dhc-dna-ipv4-16.txt Pages : 12 Date : 2005-9-29 The time required to detect movement between networks, and to obtain (or continue to use) an IPv4 configuration may be significant as a fraction of the total handover latency in moving between points of attachment. This document synthesizes from experience in the deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses a set of steps known as Detecting Network Attachment for IPv4 (DNAv4), in order to decrease the handover latency in moving between points of attachment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-16.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-dna-ipv4-16.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-dna-ipv4-16.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: <2005-9-29111758.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dna-ipv4-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dna-ipv4-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-29111758.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Fri Sep 30 15:28:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQY7-0007je-BS; Fri, 30 Sep 2005 15:28:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQY6-0007jM-4b for dhcwg@megatron.ietf.org; Fri, 30 Sep 2005 15:28:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01910 for ; Fri, 30 Sep 2005 15:28:00 -0400 (EDT) Received: from smtp113.sbc.mail.mud.yahoo.com ([68.142.198.212]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ELQfx-0007Kq-NO for dhcwg@ietf.org; Fri, 30 Sep 2005 15:36:13 -0400 Received: (qmail 97644 invoked from network); 30 Sep 2005 19:27:48 -0000 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.88.238 with login) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 30 Sep 2005 19:27:48 -0000 From: "Barr Hibbs" To: Subject: RE: [dhcwg] Simplification of DNAv4 specification Date: Fri, 30 Sep 2005 12:27:48 -0700 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.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rbhibbs@pacbell.net List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I basically agree with rewording DNAv4 to permit multiple parallel efforts to configure the client. We are rapidly entering an era when network bandwidth is sufficient to all but eliminate the concern about extra traffic. Would it be appropriate to add a guideline such as: "clients on a 10 or 11 Mbit/s network SHOULD NOT attempt more than two (2) parallel reachability attempts (DHCPv4 and link local), clients on a 54 or 100 Mbit/s network SHOULD NOT attempt more than five (5), and clients operating on networks above 500 Mbits/s MAY attempt as many as they wish?" The idea being to suggest a bit of self-restraint without mandating an inflexible limit. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg