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