RE: [dhcwg] comments on draft-ietf-dhc-dhcpv6-27.txt
"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> Tue, 29 October 2002 22:22 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29600 for <dhcwg-archive@odin.ietf.org>; Tue, 29 Oct 2002 17:22:36 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9TMOYF10852 for dhcwg-archive@odin.ietf.org; Tue, 29 Oct 2002 17:24:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TMOYv10847 for <dhcwg-web-archive@optimus.ietf.org>; Tue, 29 Oct 2002 17:24:34 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29579 for <dhcwg-web-archive@ietf.org>; Tue, 29 Oct 2002 17:22:04 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TMMIv10764; Tue, 29 Oct 2002 17:22:18 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TMKpv10672 for <dhcwg@optimus.ietf.org>; Tue, 29 Oct 2002 17:20:51 -0500
Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29406 for <dhcwg@ietf.org>; Tue, 29 Oct 2002 17:18:22 -0500 (EST)
Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g9TMKid00773; Tue, 29 Oct 2002 16:20:44 -0600 (CST)
Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9TMKhG16360; Tue, 29 Oct 2002 16:20:43 -0600 (CST)
Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <41PDWSZ1>; Tue, 29 Oct 2002 16:20:43 -0600
Message-ID: <A1DDC8E21094D511821C00805F6F706B0499F924@eamrcnt715.exu.ericsson.se>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: 'Richard Hussong' <rhussong@juniper.net>, dhcwg@ietf.org
Subject: RE: [dhcwg] comments on draft-ietf-dhc-dhcpv6-27.txt
Date: Tue, 29 Oct 2002 16:19:43 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27F99.470676C8"
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Richard: Thanks for the corrections ... The prefix delegation came after much of the core work on the DHCPv6 protocol was far along. And, as it is still debated as to how best to accomplish this, we felt it best to keep it out of the base specification. Regarding 18.1.5, see 17.1.2 as this explains the delay start. Perhaps we should add a reference to 17.1.2 here or cut and paste the text. If a -28 is done (or during the RFC editing process assuming the IESG accepts this draft), we will look to clarify this (and the other corrections). Regarding 17.1.1 and 22.7 (ORO option), I think we can change it to a SHOULD for the Solicit message. I don't see that this is a MUST. (Section 15.2 does not indicate that no ORO means drop the message.) Regarding 17.1.1 and Reconfigure Accept option, this is an error and should be modified to read that the option is included only if the client desires to have the server make use of Reconfigure. At one time this option contained a flag byte which indicated whether Reconfigure was or was not supported and this was not properly updated then the option was changed. Regarding the issue with Section 22.4, a T1/T2 of 0 means don't renew. It is client implementation specific as to how it deals with this (whether it uses 0 to mean don't renew and don't start a timer) or does something else (such as using very large values). - Bernie -----Original Message----- From: Richard Hussong [mailto:rhussong@juniper.net] Sent: Tuesday, October 29, 2002 4:43 PM To: dhcwg@ietf.org Subject: [dhcwg] comments on draft-ietf-dhc-dhcpv6-27.txt To: Ralph Droms <rdroms@cisco.com> I have some comments on the new DHCPv6 draft. I think the changes have improved its clarity quite a bit, but I still see a few problems. Actually, some of these were in the previous draft; I'm sorry I didn't find them there and bring them to your attention, but I haven't been on this stuff for long. First, a general comment: since IPv6 has stateless address auto-configuration, and small routers are becoming increasingly common, even in homes, isn't it possible, even likely, that the main use of DHCPv6 will be for prefix delegation rather than address assignment? If this is the case, it seems unfortunate that prefix delegation is not in this document, since that fact makes it appear that it is of lower status or importance than the address assignment that is in the document. I am sure there are sound historical reasons for putting prefix delegation in a separate document (including the controversy over whether prefix delegation should be handled by DHCPv6 at all), but there are so many parallels between address assignment and prefix delegation that it seems a shame not to treat them in a parallel fashion. The rest of the comments are on particular sections of the draft. ============= Section 1.3, "Client-server Exchanges Involving Four Messages" Typo in Paragraph 2: "the client sends a Renew messages ..."; "messages" should be "message". ============= Section 16. Client Source Address and Interface Selection Typo in Paragraph 1: "... is certain the two interface are ..."; "interface" should be "interfaces". ============= Section 17.1.1. Creation of Solicit Messages In Paragraph 4: The client MUST include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. This states that the Option Request option is required in a Solicit message. However, Section 22.7 says: A client MAY include an Option Request option in a Solicit, Request, Renew, Rebind, Confirm or Information-request message to inform the server about options the client wants the server to send to the client. This implies that the Option Request option is not required in a Solicit message. Should the server treat a Solicit message without an Option Request option as invalid? If the client includes instances of particular options without listing their codes in the Option Request option, should those options be ignored? ============= Section 17.1.1. Creation of Solicit Messages In Paragraph 5: The client MUST include a Reconfigure Accept option (see section 22.20) indicating whether or not the client is willing to accept Reconfigure messages from the server. This states that the Reconfigure Accept option is required in a Solicit message. However, Section 22.20 says: The default behavior, in the absence of this option, means unwillingness to accept Reconfigure messages, or instruction not to accept Reconfigure messages, for the client and server messages, respectively. This implies that the Reconfigure Accept option is not required in a Solicit message. Should the server treat a Solicit message without a Reconfigure Accept option as invalid? ============= Section 18.1.5. Creation and Transmission of Information Request Messages In Paragraph 5: The first Information-request message from the client on the interface MUST be delayed by a random amount of time between 0 and INF_MAX_DELAY. It is not specified what event defines the start of the delay period. I imagine the intent is that the delay starts from the "interface up" event. Is that true, and would there be any value in making it explicit? ============= Section 18.1.8. Receipt of Reply Messages Paragraph 3, bullet 4: - Discard any addresses from the IA as recorded by the client that have a lifetime of 0 in the IA Address option Just for clarity, perhaps "lifetime" should be "valid lifetime"? ============= Section 18.2.8. Transmission of Reply Messages Typo in Paragraph 2: "see Section!22.10" should be "see Section 22.10". ============= Section 22.4. Identity Association for Non-temporary Addresses Option In the next-to-last paragraph, In a message sent by a server to a client, the client MUST use the values in the T1 and T2 fields for the T1 and T2 parameters. However, in the last paragraph, If the time at which the addresses in an IA_NA are to be renewed is to be left to the discretion of the client, the server sets T1 and T2 to 0. I suspect the intent of the extract from the next-to-last paragraph is something like "In a message sent by a server to a client, the client MUST use the values in the T1 and T2 fields for the T1 and T2 parameters, unless they are 0", right? ============= Section 22.6. IA Address Option In Paragraph 3: In a message sent by a server to a client, the client MUST use the values in the preferred and valid lifetime fields for the preferred and valid lifetimes. Just for clarity, it might be useful to note here than a valid lifetime field value of 0 has the special meaning of "stop using this address", even though that is the natural consequence of a valid lifetime of 0. It would be even handier if a cross-reference were included to Section 18.1.8, which discusses the Reply message that might actually use such 0 lifetime values. ============= Section 22.6. IA Address Option Typo in Paragraph 3: "More than one IA Address Options can appear"; "Options" should be "Option". ============= - Richard Hussong _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] comments on draft-ietf-dhc-dhcpv6-27.txt Richard Hussong
- RE: [dhcwg] comments on draft-ietf-dhc-dhcpv6-27.… Bernie Volz (EUD)