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

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Mon, 10 Aug 2020 22:42:17 -0700

Murray Kucherawy has entered the following ballot position for
draft-ietf-dhc-v6only-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-v6only/

----------------------------------------------------------------------
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.

And a few nits:

Abstract:

* "... supports an IPv6-only mode and willing to ..." -- s/willing/is willing/

Section 1.2:

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

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

---

From: Jen Linkova <[email-masked]>
Date: Tue, 11 Aug 2020 18:04:37 +1000

Hi Murray,

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.

> * "... supports an IPv6-only mode and willing to ..." -- s/willing/is willing/

Fixed.

> * "This document currently implies that ..." -- Is this document going to imply

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