Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-03.txt - Respond by Oct 13, 2014
Marcin Siodelski <msiodelski@gmail.com> Mon, 13 October 2014 11:51 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 AE0361A8996 for <dhcwg@ietfa.amsl.com>; Mon, 13 Oct 2014 04:51:01 -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 i96ulp75I3WY for <dhcwg@ietfa.amsl.com>; Mon, 13 Oct 2014 04:50:59 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C3081A8998 for <dhcwg@ietf.org>; Mon, 13 Oct 2014 04:50:59 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id em10so7189841wid.7 for <dhcwg@ietf.org>; Mon, 13 Oct 2014 04:50:58 -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=elx7JCqVwND31bScpblthdfgFK0ldReYS4k/AZgYtT8=; b=qrZpHqEG74YBLCII0Vx0v5Yz+kYu0YRc5C0oR+dIwBFlGUZnj+bTuRge17VOdGeXBs kzSkV1eXoTBGgHpiEWUeLgd/w7iEz4OphO58otr8I0gzjlpuGhUUci9/yq/wc5NfeGbB XV1r6IEb1/9qpU+cXzDZ1YPmkRK32/fnnPOsLXh6VlJknG/erRhbqux71IG6+JUHNHqU 9K9aA+M8DmE4dvHxl2KLjgeUqhxGUOKo4XS1byfKUM0FTVTBa7ypRquFDenq1AdoS5h/ AgsJnqdPIlurTCKCEYHce+XrGq81MQfYPOvB+feo9jAiZbx7wBvi3yon6BlXP59TeAfZ gPIA==
X-Received: by 10.194.110.10 with SMTP id hw10mr2170998wjb.102.1413201058018; Mon, 13 Oct 2014 04:50:58 -0700 (PDT)
Received: from [192.168.10.11] (89-79-26-47.dynamic.chello.pl. [89.79.26.47]) by mx.google.com with ESMTPSA id ji10sm11929620wid.7.2014.10.13.04.50.56 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Oct 2014 04:50:57 -0700 (PDT)
Message-ID: <543BBCA0.9010903@gmail.com>
Date: Mon, 13 Oct 2014 13:50:56 +0200
From: Marcin Siodelski <msiodelski@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: "Bernie Volz (volz)" <volz@cisco.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>
References: <489D13FBFA9B3E41812EA89F188F018E1B6ABDD8@xmb-rcd-x04.cisco.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B6ABDD8@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/4Pf2ISozenzKLnT9ukKSOdv5QJI
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-03.txt - Respond by Oct 13, 2014
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: <http://www.ietf.org/mail-archive/web/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, 13 Oct 2014 11:51:01 -0000
I have read the draft, I think it is useful work and I support it move forward. A couple of comments, mostly editorial. There is nothing really major. Section 3: The title of this section sounds ambiguous. IMO, the better name would be "Identifying Client's Location by DHCP servers". In case you think the current name is better, I'd put a short paragraph explaining the purpose of the whole section 3 at the beginning of this section to provide a context for the analysis of the figures. Otherwise I stare at the figures first without an understanding why I am doing it. OLD: "DHCP clients are assumed not to have routable IP addresses when they are attempting to obtain configuration information". NEW: "It is assumed that DHCP clients may not have routable IP addresses when they are attempting to obtain configuration information." OLD: "this relay agent, which has a routable IP address, then forwards the DHCP requests to the DHCP server". NEW: "this relay agent, which has a routable IP address, then forwards the DHCP requests to the DHCP server (directly or via other relays)". The following statement: "In DHCPv6 that is also possible in case where the server is configured with a Server Unicast option and client's are able to take advantage of it." contradicts with the assumption that clients don't have routable addres, because they need to have a routable address to use unicast: This is another reason why it should be said that the clients may not have an routable IP address, rather than they don't have routable IP address. Since, the draft combines the use cases for DHCPv4 and DHCPv6 it is sometimes not clear whether "DHCP server" refers to DHCPv4 server or both DHCPv4 and DHCPv6. For example: "In all cases, the DHCP server is able to obtain IP address that it knows is on-link [...]". >From the examples following the colon I understand that this is about the DHCPv4 server. But, the use of DHCP term doesn't seem to be consistent. In some cases the DHCP server refers to both. I'd suggest that the "DHCP server" is used as a term for "any" server. And, DHCPv4 and DHCPv6 for respective servers. One may argue that RFC2131 defines a DHCP protocol (not DHCPv4), but the use of terms could be cleared in the topo-conf terminology. Having said that, I think that section 3 would be far better readable if it was split to 2 distinct sections. One for DHCPv4, another for DHCPv6. Otherwise, the text jumps back and forth between the two contexts. This paragraph sounds awkward: " In all cases, the DHCP server is able to obtain an IP address that it knows is on-link for the link to which the DHCP client is connected: either the DHCPv4 client's routable IPv4 address, or the relay agent's IPv4 address on the link to which the client is connected. So in every case the server is able to determine the client's point of attachment and select appropriate subnet- or link-specific configuration." It would be better to say: " 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." Or something similar. But the key is that the server extracts the IP address for the purpose, and the purpose should be stated first. In the original text is sounds like the ability to select a subnet or link-specific configuration is a side effect of doing something else. I'd remove the "Somewhat contrary to its name [...]". The name is the name and it is not the intent of this draft to resolve issues with names defined elsewhere. I don't understand this: "In normal circumstances this is the solution that is the easiest to maintain." In particular, I don't understand what exact aspects of "maintenance" are the easiest here? Or, what the maintenance is in this context? Section 4: In the JSON example there is on-link["a"]. Shouldn't it be on-link["A"] ? Marcin On 29/09/14 16:36, 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-03, document as an Informational RFC. The > authors believe that this version is ready. > > > > The draft is available here: > > http://tools.ietf.org/html/draft-ietf-dhc-topo-conf-03 > > > > Please send your comments by October 13th, 2014. 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 > > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg >
- [dhcwg] WGLC for draft-ietf-dhc-topo-conf-03.txt … Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-03.… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-03.… Tomek Mrugalski
- Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-03.… JF Tremblay
- Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-03.… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-03.… Marcin Siodelski
- Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-03.… Qi Sun
- Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-03.… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-03.… Tomek Mrugalski
- Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-03.… Tomek Mrugalski
- Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-03.… Tomek Mrugalski
- Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-03.… Tomek Mrugalski
- Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-03.… 神明達哉