Re: [dhcwg] Murray Kucherawy's No Objection on draft-ietf-dhc-v6only-06: (with COMMENT)

[Jen Linkova <[e-mail]>]

Hi Murray,


On Tue, Aug 11, 2020 at 3:43 PM Murray Kucherawy via Datatracker
<[e-mail]> wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> In Sections 3.2 and 3.3, there are a lot of SHOULDs and a couple of SHOULD
> NOTs, but no guidance about what one might do instead of what they say, or when
> it might be appropriate to deviate from the SHOULD, or what the impact of doing
> so might be.  Since you're providing a choice, I suggest fully developing the
> choice.

Oh. Do you find any specific parts of those sections incomplete w/o
complementing each 'SHOULD' with explanation why it's not a MUST?
I'm not sure we need to clarify the choice for cases like 'the
functionality SHOULD be configurable' - such 'SHOULD's are usually a
balance between usability from the admin/user perspective and efforts
required from the implementers. I'd expect it to be configurable on a
laptop or server OS but for an IoT device it might be a hardcoded
option etc.
Other SHOULDs are usually 'we could have made them 'MUST' but nothing
would be really broken if you don't do this, just the desired
functionality wouldn't be available'.

One place when we shall clarify the text probably is the paragraph
Alvaro also commented on - about returning 0.0.0.0 vs the address in
the pool, as it's the only place when the implementers/administrator
really have a choice.

So I'm considering the following clarification:

OLD TEXT:

The server SHOULD NOT assign an address
   for the pool.  Instead it SHOULD return 0.0.0.0 as the offered
   address.  Alternatively, the server MAY include an available IPv4
   address from the pool into the DHCPOFFER as per recommendations in
   [RFC2131].

NEW TEXT:

The server SHOULD NOT assign an address
   for the pool.  Instead it SHOULD return 0.0.0.0 as the offered
   address.  Alternatively, if offering 0.0.0.0 is not feasible due to
the server or network infrastructure limitations, the server MAY
include an available IPv4
   address from the pool into the DHCPOFFER as per recommendations in
   [RFC2131].
--

Please let me know if you see any other places where the specification
looks ambiguous. Happy to clarify the text.

> And a few nits:
>
> Abstract:
>
> * "... supports an IPv6-only mode and willing to ..." -- s/willing/is willing/

Fixed.

> Section 1.2:
>
> * "This document currently implies that ..." -- Is this document going to imply
> something else later?

OK, I'll remove 'currently' in -07. The idea was to clarify that
currently the most likely scenario for using this option is a network
with NAT64. However it might change in the future, and the next
sentence refers to Section 4 which discusses this topic in more
details.

> * "a deployment scenario when ..." -- s/when/where/

Fixed, thanks!

--
SY, Jen Linkova aka Furry