Subject: Re: [v6ops] Calling the question: draft-ietf-v6ops-host-addr-availability-03.txt

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 4 Jan 2016 12:16:16 +0900

On Thu, Dec 17, 2015 at 3:37 PM, David Farmer <[email-masked]> wrote:

> On 12/16/15 07:09 , Lorenzo Colitti wrote:
>
>> Again, let's make sure we're agree on the scope of this document. What
>> we're talking about is how the network provides addresses, not how the
>> recipient of such addresses behaves. Yes?
>>
>
> Yes, I agree.  However, I think the subtly of that distinction is easily
> lost on casual readers of the document.  That is why earlier I was trying
> to suggest you should be more explicit about what is out-of scope.  Instead
> of what I suggested last time, maybe add something like the following "It
> does not specify any changes to protocols or end host behavior" to the end
> of the Introduction;
>
>    This document describes the benefits of providing multiple addresses
>    per host and the problems with not doing so.  It recommends that
>    networks provide general-purpose end hosts with multiple global
>    addresses when they attach, and lists current options for doing so.
>    It does not specify any changes to protocols or end host behavior.
>
> I think that reinforces and clarifies the scope by being explicit about
> what is out-of scope.
>
> Also you seem to frequently stray into talking about things from a host
> perspective, instead of clearly a network perspective, this is probably
> confusing this issue a bit.
>
> Generally, hosts "obtain" addresses, networks "provide" addresses,
> "assigning" while correct, might be a little passive, I think "providing"
> more clearly communicating a network perspective.  So, a few specific
> suggestions for combating this host vs. network confusion;
>
> 1. Section 1, "Introduction", the last paragraph starts with "This
> document describes the benefits of assigning multiple addresses per
> host..." I think "This document describes the benefits of providing
> multiple addresses per host..." would be more strongly focused on the
> network perspective.
>
> 2. Section 3 is is titled "Benefits of multiple addresses". "Benefits of
> providing multiple addresses" is more clearly projects a network
> perspective.
>
> 3. Section 4 is is titled "Problems with assigning a restricted number of
> addresses per host", I think "Problems with restricting the number of
> addresses per host" is stronger, but this one is a bit of a coin flip.
>
> 4. Section 6 is titled "Options for obtaining more than one address", and
> starts with "Multiple IPv6 addresses can be obtained in...".  This is
> clearly confusing the perspective and should be changed to "Options for
> providing more than one address", and start with "Multiple IPv6 addresses
> can be provided in..."
>
> 5. Section 9.3 in the middle paragraph; "...However, switching to a DHCPv6
> PD model with one /64 prefix per host resolves these scaling
> limitations..." And the last paragraph starts with; "Also, a DHCPv6 PD
> model with a dedicated /64 per host makes...". Again these is a little
> passive, how about "... However, switching to a DHCPv6 PD model providing
> one /64 prefix per host resolves these scaling limitations.." and "Also, a
> DHCPv6 PD model providing a dedicated /64 per host makes..." is more
> actively about the network.
>

Thanks. We've applied these suggestions in -04.

Yes, this is all true, but most people still have the impression that
> DHCPv6 PD is primarily intended for configuring routers or CPE and not
> hosts. If you read the introduction RFC 3633, it is easy to see why people
> have that impression.  Even the example you site is related to Internet
> Connection Sharing (ICS) where Windows is basically acting like a CPE
> router. I'm not sure what to do about it though, but it probably shouldn't
> be ignored.
>

I added the following text to -04:

      While [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6
      PD itself does not require that the client forward IPv6 packets
      not addressed to itself, and thus does not require that the client
      be an IPv6 router as defined in [RFC2460].

Better?

---

From: David Farmer <[email-masked]>
Date: Sun, 3 Jan 2016 23:54:15 -0600

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

> On Jan 3, 2016, at 21:16, Lorenzo Colitti <[email-masked]> wrote:
>> Yes, this is all true, but most people still have the impression that DHCPv6 PD is primarily intended for configuring routers or CPE and not hosts. If you read the introduction RFC 3633, it is easy to see why people have that impression.  Even the example you site is related to Internet Connection Sharing (ICS) where Windows is basically acting like a CPE router. I'm not sure what to do about it though, but it probably shouldn't be ignored.
> 

Yes, that helps a lot.

A suggestion, use it if you like, I think what you have is sufficient, I just think this would be even better:

   While [RFC3633] refers to the DHCPv6 client is a "requesting router", ....

Also, we should make sure similar clarifying language gets into rfc3315bis which as far as I can tell will incorporate and obsolete RFC3633.

Thanks.
-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================