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
>