Issues and Recommendations with Multiple Stateful DHCPv6 Options
draft-ietf-dhc-dhcpv6-stateful-issues-12

For the sake of documenting Ron's (OPS DIR) review...
Nits:

The Nit-checker complains about a malformed reference on line 606. It complains because this document has no reference [17]. However, the text in question is UPDATING RFC 3315, which does have a reference [17]. So, I recommend that we let this nit slide and let the RFC editor figure out what to do about it.

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"?

I was able to follow this document fairly well, except in this text:

   The single session and state machine allows the client to use the
   best configuration it is able to obtain from a single DHCP server
   during the configuration exchange.  Note, however, that the server
   may not be configured to deliver the entire configuration requested
   by the client.  In that case the client could continue to operate
   only using the configuration received, even if other servers can
   provide the missing configuration.  
   
I THINK I'm getting tripped up on "could continue to operate". Is this intended to say "_will_ continue to operate only using the configuration received"? "Could" says, to me, that the client might do that, or might do something else that's not specified, that I saw. But I'm guessing.

Otherwise, for a document that's updating a bunch of RFCs, this draft was very clear.