Subject: [dhcwg] Pete Resnick's No Objection on draft-ietf-dhc-dhcpv6-stateful-issues-11: (with COMMENT)

From: "Pete Resnick" <[email-masked]>
Date: Wed, 11 Mar 2015 16:18:11 -0700

Pete Resnick has entered the following ballot position for
draft-ietf-dhc-dhcpv6-stateful-issues-11: 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 http://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:
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

These comments are put in terms of MUST/SHOULD/MAY, but really it is
about the meaning you are trying to convey; the particular 2119
terminology is not the main point.

4: I admit to be a little baffled by some of the language in the top
level of this section. You say:

   Resetting the state machine and continuing to send Solicit messages
   may result in the client never completing DHCP and is generally not
   considered a good solution.  It can also result in a packet storm if
   the client does not appropriately rate limit its sending of Solicit
   messages or there are many clients on the network.

Cool. That seems like a real problem that needs to be kept in mind when
doing implementation. So why then do you follow this with:
   
   Client
   implementors that follow this approach, are strongly advised to
   implement the updates to RFC-3315 specified in [RFC7083].
   
"Strongly advised"? Sounds like they MUST implement the 7083 updates,
lest they fail to interoperate or cause serious damage to the net. If
there are ways to avoid a packet storm without the 7083 update, but you
had better know what you are doing, then that means that you SHOULD
implement the 7083 updates. Why "strongly advised"?

You then go on to explain the problems with separate DHCP sessions, and
explain why single session is mostly better (with some caveats), but then
conclude with:

   While all approaches have their own pros and cons, we recommend and
   focus on approach 3 for this document because it is deemed to work
   best for common cases of the mixed use of IA_NA and IA_PD.  But this
   document does not exclude other approaches.

"recommend and focus on approach 3"? How about, "approach 3 SHOULD be
used" or "approach 3 is RECOMMENDED". If there are reasons to choose one
of the other approaches, you had better know why you've chosen them, but
that's exactly what SHOULD/RECOMMENDED means.

Any reason for this low-key mushy way of talking in this section?

4.1:

"MUST be prepared to handle" strikes me funny. Any reason not to simply
say "MUST handle" or "MUST accept"?

OLD
   Servers MUST return the Status Code option of NoAddrsAvail
   encapsulated in an IA_NA/IA_TA options and not as a top-level Status
   Code option of NoAddrsAvail when no addresses will be assigned (1 in
   the above list).

The "not" in there seems like something that shouldn't be missed. Can I
suggest strengthening it as follows?

NEW
   Servers MUST return the Status Code option of NoAddrsAvail
   encapsulated in an IA_NA/IA_TA options and MUST NOT return it as a
   top-level Status Code option of NoAddrsAvail when no addresses will
   be assigned (1 in the above list).

4.2:

OLD
       - MAY display any associated status message(s) to the user.

The "MUST ignore" seems to have an implicit "for protocol processing
purposes". Displaying the status to the user is not protocol processing,
and therefore I think the MAY (which implies a protocol option) isn't
quite right (and wasn't quite right in 3315 either). Simply saying, "Of
course, a client can display any associated status message(s) to the
user." seems better. Similarly with the last paragraph of 4.2 and the
first paragraph of 4.4.5.

4.4.1 and 4.4.2, last paragraph of each: Don't change these blindly; this
is just a question: Is there a reason the "should"s and the "may" are not
"SHOULD"s and "MAY"? These sure sound like interoperability claims.

4.6: Isn't "It is recommended that a client SHOULD NOT send" redundant?
How about just "A client SHOULD NOT send"?