Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-05.txt - Respond by July 29, 2015
Marcin Siodelski <msiodelski@gmail.com> Mon, 27 July 2015 09:08 UTC
Return-Path: <msiodelski@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23AC1AD34C for <dhcwg@ietfa.amsl.com>; Mon, 27 Jul 2015 02:08:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8l8LKqjwTYa for <dhcwg@ietfa.amsl.com>; Mon, 27 Jul 2015 02:08:54 -0700 (PDT)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 285A01AD33F for <dhcwg@ietf.org>; Mon, 27 Jul 2015 02:08:54 -0700 (PDT)
Received: by lbbyj8 with SMTP id yj8so49049681lbb.0 for <dhcwg@ietf.org>; Mon, 27 Jul 2015 02:08:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xw/kG9DkjukbZjLgfjl2kE1M/3pNB6NaIWK2fwgcklI=; b=kCF3Zd+TKtJHZVU8NcNbU3/sBm8o9IX6v4Z+/y4wMAE8zQ3lTEQWqoaf9n7uhMaYGj zdarSfp+cZM7Rjo637jyiBu/glzOwnqxE1m4c+0tKKcGGqc7LJqAeyDqPbB0GPZ8P4pP eDM+g9/bV2AjHStuT1iWve3/NwypwpxyZuz1OJV7vm+lJtEb4Le2XeOyIyb+odix6Yup EIh3XsAvJCy/wTRLNv+E30UT/vBJti3xA5ayPWKfQ+U7sKkK5d266WkRFzT8zQ2Hb9bQ +SWVPBCYs9SL+i0rLvXlSt2vWoLqLeNwT5Y3HWiqLmyyaoW9FjpKcX1c8dWziRKzQf4f KrKA==
X-Received: by 10.152.203.233 with SMTP id kt9mr22848414lac.99.1437988132679; Mon, 27 Jul 2015 02:08:52 -0700 (PDT)
Received: from MacBook-Pro-Marcin.local (apn-31-1-70-111.dynamic.gprs.plus.pl. [31.1.70.111]) by smtp.googlemail.com with ESMTPSA id u6sm2575701laz.49.2015.07.27.02.08.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jul 2015 02:08:52 -0700 (PDT)
Message-ID: <55B5F54D.6090902@gmail.com>
Date: Mon, 27 Jul 2015 11:09:33 +0200
From: Marcin Siodelski <msiodelski@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "Bernie Volz (volz)" <volz@cisco.com>, DHC WG <dhcwg@ietf.org>
References: <489D13FBFA9B3E41812EA89F188F018E1CB65DB6@xmb-rcd-x04.cisco.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1CB65DB6@xmb-rcd-x04.cisco.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/aj70zVD2qRlmyDQJWBG7rGQzTdU>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-05.txt - Respond by July 29, 2015
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2015 09:08:56 -0000
On 08.07.2015 23:15, Bernie Volz (volz) wrote: > Hi all, > > > > This message starts the DHC working group last call to advance > "Customizing DHCP Configuration on the Basis of Network Topology”, > draft-ietf-dhc-topo-conf-05, document as an Informational RFC. The > authors believe that this version is ready. We did a WGLC for the 03 > draft in October 2014, which raised some issues and resulted in the > updates. At that time, we felt the document did not pass WGLC. > > > > The draft is available here: > > http://tools.ietf.org/html/draft-ietf-dhc-topo-conf-05 > > > > Please send your comments by July 29th, 2015. If you do not feel this > document should advance, please state your reasons why. > > > > There are no IPR claims reported at this time. > > > > Bernie Volz is the assigned shepherd for this document. > > > > - Tomek & Bernie > > > I have read the document and I support advancing it. It provides useful guidelines to the DHCP servers' users/administrators. It gathers information from multiple documents in a single place, which makes DHCP configuration use cases easy to understand. Here are a few suggestions, that I had while reading this text... ---- The document describes various techniques for selecting the subnet in case of both DHCPv4 and DHCPv6. Most of the sections provide the combined text for both protocols, describing similarities and differences. That's ok. However, in this case it seems important to have a clear distinction whenever we talk specifically about DHCPv4 and when we talk about DHCPv6. In all cases, when this document talks about both protocols (general text), it should refer to them as DHCP. For example: - Section 3.1 is about the "DHCPv4 specific behavior", but often uses the term "DHCP" rather than "DHCPv4". - Section 3.2 is about the "DHCPv6 specific behavior", but often uses the term "DHCP" rather than DHCPv6, e.g. "What this means in practice is that the DHCP server..." or "In all cases, then, the DHCP server will...". In Section 7: "In this example, when a request comes in to the DHCP server... " and so on. Having said that, it may be worthwhile putting this naming scheme into the terminology, or mention it in the introductory text. In section 3: "Sometimes it is useful for the relay agents to provide additional about the topology". ---- Something is missing here. Perhaps it was meant to say: "... to provide additional information about the topology...". Suggest using 'giaddr', rather than GIADDR as the former is the form used in the RFC2131. ---- The section 3.2 says this: "In the DHCPv6 protocol, there are two core mechanisms defined in [RFC3315] that allow server to distinguish which link the relay agent is connected to." Then it goes through the long description of the first mechanism and it doesn't mark the beginning of the description of the second mechanism. Perhaps modify this: "If for whatever reason that is not feasible (e.g. because the relay agent does not have a global address or ULA [RFC4193] configured on the client-facing interface), ... " with: "The second mechanism uses Interface Id option (see Section 22.18 of [RFC3315]) inserted by the relay agent, which identifies the link that the client is connected to. This mechanism may be used for example, when the relay agent does not have a global address or ULA [RFC4193] configured on the client facing interface, thus making the first mechanism not feasible. Alternatively: "In the DHCPv6 protocol, there are two core mechanisms defined in [RFC3315] that allow server to distinguish which link the relay agent is connected to. First is using the link-address carried in the Relay-forward and Relay-reply messages. Second is using the Interface Id option inserted by the relay agent. ---- The following paragraph is confusing: "The DHCP server uses an IP address from the client's message which is on the same link as the client to perform address assignment decisions or to select subnet-specific configuration for the client. The address that the server uses is the DHCP client's routable IP address or the client facing address of the relay agent. The server is then able to determine the client's point of attachment and select appropriate subnet- or link-specific configuration." Specifically, the first sentence could be removed for two reasons: - it mostly duplicates the second and third sentence - it is unclear where the "IP address" the first sentence refers to is assigned. It can be a relay or the client, but it doesn't say so. How about: "To determine the client's point of attachment and link specific configuration, the server typically uses the client facing IP address of the relay agent. In some cases the server may use the routable IP address of the client, if the client has the routable IP address assigned to its interface and it is transmitted in the DHCP message." ---- I am confused with the following text: " It should be noted that there the link- specific identifier is unique only within the scope of the link- identifying IP address. For example, link-specific indentifier of "eth0" for a relay agent with IPv4 address 192.0.2.1 means something different than "eth0" for a relay agent with address 192.0.2.123." because I don't know why this example (using IPv4 addresses) is provided in the section that discusses "DHCPv6 specific behavior". I am also not quite sure what it is intended to say. Marcin
- [dhcwg] WGLC for draft-ietf-dhc-topo-conf-05.txt … Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-05.… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-05.… Marcin Siodelski
- Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-05.… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-05.… 神明達哉