Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-topo-conf-06 changes

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 2 Nov 2015 16:06:51 +0900

Hi,
The updated topo-conf draft has been published two weeks ago, but it
seems that authors never described the changes, so there they are:
- updated terminology section
- updated DHCPv6 to DHCP where the text applies to both v4 and v6
- fixed several typos
- clarified the relation between subnet selection based on addresses vs.
  selecting the subnet based on interface-id
- updated example in the DHCPv6 section to use IPv6 addresses
- Removed section 8 about dynamic lookup (added reference to
  appropriate section in RFC7227 that discusses the issue)
- added examples that explain why shared subnets may be warranted

Authors believe that those changes addresses previous comments made by
Jinmei, Marcin and Bernie. I would appreciate if you could confirm that
this is really the case (or point out what I have missed).

Thanks,
Tomek

On 20/10/15 05:53, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.
> 
>         Title           : Customizing DHCP Configuration on the Basis of Network Topology
>         Authors         : Ted Lemon
>                           Tomek Mrugalski
> 	Filename        : draft-ietf-dhc-topo-conf-06.txt
> 	Pages           : 17
> 	Date            : 2015-10-19
> 
> Abstract:
>    DHCP servers have evolved over the years to provide significant
>    functionality beyond that which is described in the DHCP base
>    specifications.  One aspect of this functionality is support for
>    context-specific configuration information.  This memo describes some
>    such features and makes recommendations as to how they can be used.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dhc-topo-conf/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dhc-topo-conf-06
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-topo-conf-06
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Marcin Siodelski <[email-masked]>
Date: Tue, 3 Nov 2015 10:46:19 +0900

Most of my issues have been addressed. Thanks.

These are some little outstanding things.

There seem to be some copy-paste errors in section 3.2:

"This mechanism may be used for
   example, when the relay agent does not have a globally unique address
   or ULA [RFC4193] configured on the client-facing interface) on the
   client facing interface, thus making the first mechanism not
   feasible."

Further in section 3.2:

" 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 identifier of
   "eth0" for a relay agent with IPv4 address 2001:db8::1 means
   something different than "eth0" for a relay agent with address
   2001:db8::2."

There is a typo: "that there link-specific..." - extraneous "there".
Another typo: "IPv4 address". It should be "IPv6 address".

I wonder if the second sentence could be slightly changed:

"For example, link-specific identifier of "eth0" assigned to a relay
agent using IPv6 address 2001:db8::1 is distinct from a "eth0"
identifier used by a different relay agent with address 2001:db8::2"

There is still some mixed use of "DHCP" vs "DHCPv6" in the "7. Regional
Configuration Example".

Marcin

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 15 Nov 2015 16:31:01 +0000

Hi:

I looked back over my comments (from 7/27) and it looks like they were addressed.

I do have one minor edit I would recommend (and this is from text I had supplied on 7/27):

In section 8, replace "delegated is" with "assigned are"?

   The third use case covers allocating addresses (or delegation
   prefixes) that are not the same as topological information.  For
   example, the link-address is on prefix X and the addresses to be
   delegated is on prefix Y.  This could be based on differentiating
   ^^^^^^^^^ assigned are?
   information (i.e., whether device is CPE or CM in DOCSIS) or just
   because the link-address/giaddr is different from the actual
   allocation space.

Another minor nit is in section 3.2 where "can not" should be replaced with "cannot":

                                                                                                   If the interface-id
   values are not unique, the Interface-id option can not be used to
   determine the client's point of attachment.

And, also Unspecified be lower case?

   DHCPv6 also has support for more finely grained link identification,
   using Lightweight DHCPv6 Relay Agents [RFC6221] (LDRA).  In this
   case, the link-address field is set to Unspecified_address (::), but
   the DHCPv6 server also receives an Interface-Id option from the relay
   agent that can be used to more precisely identify the client's
   location on the network.

And, just a reminder to also make the correction Marcin reported (on 11/2 - see below).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Marcin Siodelski
Sent: Monday, November 02, 2015 8:46 PM
To: Tomek Mrugalski <[email-masked]>; [email-masked]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-topo-conf-06 changes

Further in section 3.2:

Marcin

---

From: 神明達哉 <[email-masked]>
Date: Wed, 18 Nov 2015 09:57:33 -0800

At Mon, 2 Nov 2015 16:06:51 +0900,

> seems that authors never described the changes, so there they are:
[...]

This point doesn't seem to be addressed:

>> - Section 3:
>>
>>    Figure 2 illustrates a more complex case.  [...
>>    ...]  Note that some nodes act as routers (which forward all
>>    IPv6 traffic) and some are relay agents (i.e. run DHCPv6 specific
>>    software that forwards only DHCPv6 traffic).
>>
>> Until we see discussions in Section 7 it's not obvious just from
>> Figure 2 that this is an example of IPv6 network using DHCPv6.  It
>> would be more reader-friendly to explain this is an example case using
>> IPv6 (and DHCPv6) explicitly here.

And this one (there are still some upper-cased textual addresses in
the 06 version):

>> - Section 7, Figure 4: Unless there's a specific reason, I'd suggest
>>   using "2001:db8::/40" etc, instead of "2001:db8:0:0::/40" based on
>>   the recommendation of RFC5952.  For the same reason, I'd replace
>>   "2001:DB8:0:0::/40" with "2001:db8::/40", etc, in the text that
>>   follows.

I also noticed a typo in the revised text.

- Section 3.2 s/may still able/may still be able/

   link, with additional configuration information the server may still
   able to select the proper link.  That requires the DHCP server

--
JINMEI, Tatuya