Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-stateful-issues-09 - Respond by December 12th, 2014

From: 神明達哉 <[email-masked]>
Date: Thu, 4 Dec 2014 10:07:32 -0800

At Wed, 26 Nov 2014 14:59:10 +0000,
"Bernie Volz (volz)" <[email-masked]> wrote:

> This message starts the DHC working group last call to advance
> "Issues and Recommendations with Multiple Stateful DHCPv6 Options",
> draft-ietf-dhc-dhcpv6-stateful-issues-09.txt, document as a
> Standards Track (Proposed Standard) RFC. The authors believe that
> this version is ready.

I see this version has been improved quite a lot.  But I think we
still need some more discussion and, possibly, revisions before
publication.

One main issue is that there still seem to be cases where we (might)
end up having multiple DHCPv6 sessions for different IAs.  I thought
that's not the intention of this proposal, and assuming this
understanding correct: if the currently described proposal can lead to
that situation, we should definitely fix that; if this is because I
misunderstood what's written in the document, it may suggest the need
for some editorial clarification.  I'll make specific comments on the
relevant text of the draft below.

Specific comments on the draft text:

- Abstract: I still think this could be a bit more friendly,
  especially for first time readers.  Specifically, I'd suggest
  including major recommendation(s) in the abstract, rather than just
  stating that it updates some RFCs.  My specific suggested text is
  something like this:

   [...]  Implementation experience of the CPE
   model described in RFC 7084 has shown multiple issues with the DHCPv6
   protocol in supporting multiple stateful options.  This document
   updates RFC 3315 and RFC 3633 to address the identified issues.
   Specifically, it requires multiple stateful options be handled
   in a single DHCPv6 session as a set, and makes clarifications and
   changes to the prior RFCs to meet the requirement.

- Section 4: I wouldn't be opposed to the decision itself, but the
  justification doesn't seem to be strong enough:

   This leaves a single DHCP session and state machine which is the
   proposed solution.  Here, the client can use what it is able to
   obtain and can continue to request what it was previously unable to
   obtain while maintaining a single session and state machine.

  Simply because other options has drawbacks doesn't automatically
  mean a single DHCP session is inevitably the solution, unless that
  solution has no drawback.  In fact, it does: for example, we could
  end up having an incomplete set of bindings (only one of IA_NA or
  IA_PD has a binding), while we could have bindings for both from
  different servers if we use multiple DHCPv6 sessions.  Likewise, if
  either IA_NA or IA_BD is temporarily unavailable, the client will
  need to wait until the first RENEW/REPLY exchange; with
  multiple-session approach we may be able to get both binding much
  quicker.  I would probably buy the conclusion if all these pros and
  cons are listed and considered, but it's just unconvincing to jump
  to a conclusion by simply listing drawbacks for other options.

- Section 4.4.3:

     The server controls the time at which the client contacts the
     server to extend the lifetimes on assigned addresses through the T1
     and T2 parameters assigned to an IA.  However, as the client
     Renews/Rebinds all IAs from the server at the same time, the client
     MUST select a T1 and T2 time from all IA options which will
     guarantee that the client will send Renew/Rebind messages not later
     than at the T1/T2 times associated with any of the client's
     bindings.

  I'd suggest adding a note that with the updated protocol T1 and T2
  are expected to be the same for all IAs and the choice at the client
  side should be trivial, referring to (the replaced version of)
  RFC3315 Section 18.2.3.

- Section 4.4.5: my previous comment on this doesn't seem to be
  addressed.

     When the client receives a NotOnLink status from the server in
     response to a Confirm message, the client performs DHCP server
     solicitation, as described in section 17, and client-initiated
     configuration as described in section 18.

  See http://www.ietf.org/mail-archive/web/dhcwg/current/msg15934.html
  This is related to the "main issue" I mentioned at the top of my
  comments above.

- Section 4.4.5: Likewise.

     -  Tries another server (by restarting the DHCP server discovery
        process).

- Section 4.4.5:

     When the client receives a Reply message in response to a Renew or
     Rebind message, for each IA in the original Renew or Rebind
     message, the client:

     -  Sends a Request message [...]

     -  Sends a Renew/Rebind [...]

  What exactly does "for each IA, ...sends a Request message" mean?
  Would the client sends a Request containing only that specific IA?
  If so, isn't it against the sense of managing all IAs in a single
  DHCPv6 session?  For example, the client could send multiple such
  Renews, and different Replys to them may have different other (so
  called stateless, such as DNS server address) options.  Section 4
  seems to argue that avoiding these is actually the point of this
  proposal.

- Section 4.4.8: this paragraph doesn't make sense to me, or is so
  confusing that I totally misunderstand it:

      For the Renew or Rebind, if the IA_PD contains no prefixes, i.e.
      contains no IA Prefix option or the IPv6 prefix field in the IA
      Prefix option is set to 0, the delegating router SHOULD assign
      prefixes to the IA_PD according to the delegating router's
      explicit configuration information.  In this case, when the server
      assigns new prefixes to the IA_PD, the server MAY use the value in
      the prefix-length field of the IA Prefix option as a hint for the
      length of the prefixes being assigned.

  It says: "if the IA_PD contains no prefixes" and then "the server
  MAY use the value in the prefix-length field of the IA Prefix
  option".  If the assumption is IA_PD contains no prefixes (which I
  interpret means no IA prefix option), how would the server find the
  "prefix-length" field?

  BTW: if this is a replacement for RFC3633, "server" would have to be
  "delegating router".

- Section 4.5: s/server/delegating router/, s/client/requesting router/?

   IA_PD requires verification that the server has the binding for the
   IAs.  In that case a client MUST use the Rebind message in place of
   the Confirm message and it MUST include all of its bindings, even
   address IAs.

   IA_PD requires verification that the server has the binding for the
   IAs.  In that case a client MUST use the Rebind message in place of
   the Confirm message and it MUST include all of its bindings, even
   address IAs.

 (Unlike the case of replacement text for RFC3633, "server"/"client"
 might be a better choice for the body of this document for
 consistency.  But I'm pointing it out just in case).

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 6 Dec 2014 04:59:14 +0000

Reminder regarding this WGLC. Please review.

>From the IETF-91 minutes (http://www.ietf.org/proceedings/91/minutes/minutes-91-dhc):

Asking for additional reviewers: Suresh Krishnan, Ted Lemon, Tim Winters and Tomek Mrugalski signed up.

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, November 26, 2014 9:59 AM
To: [email-masked]
Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-stateful-issues-09 - Respond by December 12th, 2014

Hi all,

This message starts the DHC working group last call to advance "Issues and Recommendations with Multiple Stateful DHCPv6 Options", draft-ietf-dhc-dhcpv6-stateful-issues-09.txt, document as a Standards Track (Proposed Standard) RFC. The authors believe that this version is ready.

The draft is available here:

http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-09

Please send your comments by December 12th, 2014. If you do not feel this document should advance, please state your reasons why.

There are no IPR claims reported at this time.

Tomek is the assigned shepherd for this document.

- Tomek & Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 11 Dec 2014 21:50:19 +0000

Final reminder - PLEASE Review!

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Friday, December 05, 2014 11:59 PM
To: [email-masked]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-stateful-issues-09 - Respond by December 12th, 2014

-          Bernie

Hi all,

- Tomek & Bernie

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 12 Dec 2014 06:11:29 +0000

I am not in the volunteer reviewer list since I know I don’t have time to review the whole document in details. I do have a quick look through today and feel good for this document. So, I support to move it forward.

However, I do have a couple of questions for the follow-up regarding to 3315bis. The document state “the changes described in this document are intended to be  incorporated in a new revision of the DHCPv6 protocol specification 3315bis”, and I know the 3315bis team does have plan to include them.

Will 3315bis obsolete this document? My understand is yes. Then this document would have a very short life time like one year.

The mature of this document implies that we have solved these stateful issues. Why there are still open tickets in 3315bis issue tracker? There are 9 of tickets titled with “stateful issues” and all of them are in C category “awaiting consensus”. By now, shouldn’t they be closed or at least moved into A/B category?

Best regards,

Sheng

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, November 26, 2014 10:59 PM
To: [email-masked]
Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-stateful-issues-09 - Respond by December 12th, 2014

Hi all,

This message starts the DHC working group last call to advance "Issues and Recommendations with Multiple Stateful DHCPv6 Options”, draft-ietf-dhc-dhcpv6-stateful-issues-09.txt, document as a Standards Track (Proposed Standard) RFC. The authors believe that this version is ready.

- Tomek & Bernie

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 12 Dec 2014 09:11:41 +0100

On 12.12.2014 07:11, Sheng Jiang wrote:
> I am not in the volunteer reviewer list since I know I don’t have time
> to review the whole document in details. I do have a quick look through
> today and feel good for this document. So, I support to move it forward.
Thanks a lot for your support.

> Will 3315bis obsolete this document? My understand is yes. Then this
> document would have a very short life time like one year.
Yes. My understanding is that the idea here is to solve the stateful as
soon as possible and have them published, so vendors can start
implementing them. Once we incorporate them into 3315bis and publish it,
then we'll obsolete stateful-issues RFC, but the nature of those
improvements will not change.

> The mature of this document implies that we have solved these stateful
> issues. Why there are still open tickets in 3315bis issue tracker? There
> are 9 of tickets titled with “stateful issues” and all of them are in C
> category “awaiting consensus”. By now, shouldn’t they be closed or at
> least moved into A/B category?
We'll move them to B category as soon as stateful-issues passes WGLC and
is sent to IESG. That's a realistic point at which we can assume that
the changes have consensus and the text will not change much anymore.
Hopefully that will happen before end of 2014.

If you (generic you) would like to see this happen, please review
stateful-issues and comment on it. If you don't have time, at least take
a quick look and say whether you'd like this work to move forward.

Tomek

---

From: Timothy Winters <[email-masked]>
Date: Fri, 12 Dec 2014 09:27:16 -0500

I volunteered to review draft-ietf-dhc-dhcpv6-stateful-issues-09 during IETF-91.

Overall I support this going forward, I do have a some areas were we might want to clarify some text.

1) Section 4 Last paragraph:
"Proposed solution: the client should keep a single session with the
   server and include the missing options in subsequent messages
   (Request, Renew, and Rebind) to the server."

Is there a reason this is a should?  The rest of document seems to be built on premise so MUST might make more sense, unless we have a good reason for the should.

2) Section 4.1:
Is says clients MUST handle...Advertise containing a top-level Status Code option (of
       NoAddrsAvail) and IA_NAs and/or IA_TAs with a Status Code option
       (of NoAddrsAvail).

How?  Are they suppose to ignore IA_PDs in this case?   I'm wondering what a client should do when a legacy server that still puts the NoAddrsAvail top-level?

3) Section 4.4.3
"The message exchange is terminated when the valid lifetimes of all addresses across all IAs have expired, at which time the client may use a Solicit message to locate a new DHCP server and send a
     Request for the expired IAs to the new server."

Client may choose to use a Solicit, what are the other options?   Is do nothing ok?

~Tim

> On Dec 11, 2014, at 4:50 PM, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Final reminder – PLEASE Review!
>  
> -          Bernie
>  
> From: dhcwg [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Bernie Volz (volz)
> To: [email-masked] <mailto:[email-masked]>
> From the IETF-91 minutes (http://www.ietf.org/proceedings/91/minutes/minutes-91-dhc <http://www.ietf.org/proceedings/91/minutes/minutes-91-dhc>):
>  
> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-09 <http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-09>
>  
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 12 Dec 2014 15:43:50 +0100

On 26.11.2014 15:59, Bernie Volz (volz) wrote:
> *Please send your comments by December 12th, 2014. If you do not feel
> this document should advance, please state your reasons why.*
I reviewed version -09 of this draft and I strongly support it moving
forward. I do have several comments, but they minor and should not hold
this document.

Abstract (also repeated in Section 1):
"since shoe-horned a new option" =>
"since shoe-horned new options" (there are two: 25 and 26)

Section 1:
"modify the DHCP protocol" => "modify the DHCPv6 protocol". You're not
trying to put IA_PD in DHCPv4, are you? ;)

Section 1:
"The changes described in this document are intended to be
incorporated in a new revision of the DHCPv6 protocol specification
([I-D.dhcwg-dhc-rfc3315bis]).". You should add something along the lines
of "Until 3315bis is published, this document should stand on its own."
Otherwise IESG may think that they are not expected to send this draft
to RFC editor on its own.

Section 4, the last paragraph. This looks like a left-over and it states
the same as the previous one. If you want to keep it, I think it would
be good to remove "proposed" out of it. Once it is published as RFC,
this will no longer be a proposal.

Section 4.1 has a list of 3 choices the client must be able to handle.
I'd reorder them. The number two is the proposed way forward, so it
should be listed first. The other two (current #1 and #3) should be
marked as "This is backward compatibility with servers that hasn't been
updated to this change.".

Section 4.1 (paragraph starting with "Servers MUST return the Status
Code option...") also mentions where the server should put the status
codes when something fails. There are implementations that put status
code = Success in their responses. They should also be bound by the
rules you define here.

Section 4.2, the last proposed replacement proposes to replace the text
with "...such as the available options advertised in IAs.". Maybe it
would be better to say "...such as the available resources advertised in
IAs.". The "resources" naming convention is something we decided to use
in 3315bis. Maybe it's a good time to start using it? You could add it
to the terminology and explain that an allocatable resource is an
address, a prefix or any other resource governed by the server that is
assignable on a per client basis. (It's just an idea. I don't insist on
it. If you don't like it, it will wait till 3315bis is released.)

Section 4.3: "client MUST select a T1 and T2 time from all IA options
which will guarantee that the client will send Renew/Rebind messages not
later than at the T1/T2 times associated with any of the client's
bindings.". In simpler language, "use the smallest T1/T2 values.". Is
that what you want to say?

I don't like the idea of using 0s in the example in Section 4.3. There
was a discussion in 3315bis whether we should forbid 0 as that was
confusing to implementors and packet storms were observed. This brings
the topic of T1 set to 0. Since you mentioned 0 times, have you
considered adding a clarification that "at client's discretion"
explicitly excludes "immediately".

Section 4.4.3. The part that explains what T1=T2=0 means, after " should
add after "...at the client's discretion.": Client MUST NOT initiate the
transmission immediately. (In my opinion it is ok to point it out in
several places. It should be obvious, yet several implementors missed
that point.)

Section 4.4.5 says "If the client finds no usable addresses in any of
the IAs, it may either try another server (by restarting the DHCP server
discovery process) or use the Information-request message to obtain
other configuration information only.". That's not the only option. It's
possible that the client received additional Advertises from other
servers, just the server it picked didn't return anything useful. This
is somewhat obscure, but valid scenario. See Section 17.1.3 of RFC3315,
the paragraph starting with "If the client needs to select an alternate
server...".

Section 4.4.5 also says "The client uses addresses and other information
from any IAs that do not contain a Status Code option with the
NoAddrsAvail code.". I think it would be better to say non-success
status code. That blank statement would cover valid cases like
NoPrefixAvail in IA_PD, UnspecFail or NoBinding in IA_NA, but also
server bugs like when a server sets other error code that is not allowed
here.

Section 4.4.7 says "If the server finds the addresses in the IA for the
client and the server determines that the addresses in the IA are
appropriate for the link to which the client's interface is attached
according to the server's explicit configuration information, the server
SHOULD send back the IA to the client with new lifetimes and, if
applicable, T1/T2 times." What do you mean by "the server finds the
addresses in the IA"? That there are IA address options in the client's
message or that the server found those addresses in its lease database?

Editorial comment: links in section 4.4.8 should say Section 12.1 of RFC
3633. Right now the html version attempts to link to section 12.1 of
stateful-issues.

Section 4.7 may bring to the reader's attention a somewhat obscure
feature mentioned in RFC3315, section 17.1.3. It say says that the
client picks one *or more* Advertise messages. Obviously, how to use
that capability is outside of scope here.

Ok, that's it. Thanks a lot for doing this work. I find those
corrections very useful.

Tomek

---

From: Suresh Krishnan <[email-masked]>
Date: Sun, 14 Dec 2014 01:17:50 +0000

Hi all,
   I went through this document and I support this work moving forward. 
The document is easy to read and understand. I do have a few comments 
and proposed text changes and would appreciate it if the authors can go 
over them. Most of them are clarity related but I do have two material 
issues that would probably require WG discussion.

Section 1:

s/stateless address assignment/stateless address auto-configuration/

Section 4:

OLD:
DHCPv6 was written

NEW:
The original DHCPv6 specification [RFC3315] was written

OLD:

DHCPv6 PD describes how to extend the DHCPv6 protocol to handle
prefix delegation, but [RFC3633] did not consider how DHCP
address assignment and prefix delegation could co- exist.

NEW:

DHCPv6 Prefix Delegation (PD) [RFC3633] describes how to extend
the DHCPv6 protocol to handle prefix delegation, but does not
clearly specify how DHCP address assignment and prefix delegation
co-exist.

s/has a number/causes a number/

OLD:
'collisions' between other configuration options

NEW:

unnecessary duplication of other configuration options and
potential for conflict.

Section 4.1

OLD:

In Advertise messages the Status Code option with the
NoAddrsAvail code is in the top level.

NEW:

In Advertise messages though, the NoAddrsAvail code is returned
at the top level.

Why do we need option 3 of the client behavior? Neither existing 
compliant servers and new servers following this spec will send such 
messages

Section 4.2:

OLD:

A client requesting both IA_NA and IA_PD, with a server that only
offers one of them, is not supported in the current protocol
specification.

NEW:

Thus a client requesting both IA_NA and IA_PD, from a server that
only offers an IA_PD is not supported in the current protocol
specifications.

OLD:

A client SHOULD only ignore an Advertise message when all IA
options include no offered addresses or delegated prefixes.

NEW:

A client SHOULD only ignore an Advertise message when none of the
requested IA options are offered by the server.

* The text change for Section 17.1.3 of RFC3315 is ambiguous. I
   think it incorrectly associates displaying of status messages
   with the presence of the RFC7083 options.

* Section 4.3

I think we need an additional restriction on the server side
regarding the T1 and T2 times.

The T2 times for all of the IA options need to be larger than the
T1 times for all of the IA options. This is required to ensure
that the client does not try to contact other servers before
trying renewal.

* Section 4.4.1

What subsquent messages?

* Section 4.4.3.

Please see my comment on Section 4.3. My contention is that

"the client MUST select a T1 and T2 time from all IA options
which will guarantee that the client will send Renew/Rebind
messages not later than at the T1/T2 times associated with any of
the client's bindings."

cannot always be satisfied until we put in a restriction on the
T1/T2 times.

* Section 4.7

Does it make sense to add a reference to
draft-ietf-mif-mpvd-arch-07 and/or
draft-ietf-mif-mpvd-dhcp-support-00 here?

Thanks
Suresh

On 11/26/2014 09:59 AM, Bernie Volz (volz) wrote:
> Hi all,
>
> This message starts the DHC working group last call to advance "Issues
> and Recommendations with Multiple Stateful DHCPv6 Options”,
> draft-ietf-dhc-dhcpv6-stateful-issues-09.txt, document as a Standards
> Track (Proposed Standard) RFC. The authors believe that this version is
> ready.
>

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 18 Dec 2014 19:11:54 +0100

On 26.11.2014 15:59, Bernie Volz (volz) wrote:
> *Please send your comments by December 12th, 2014.
As Bernie is co-author of this draft, I did assess this WGLC on my own.
We did receive a substantial support and very good feedback for this
last call. I'm very happy to announce that this WGLC is a successful one.

Having said that, there were many comments received, so authors are
requested to address them and upload an updated version. In my opinion
none of the comments received was substantial enough to warrant another
WGLC. Therefore, once an updated version appears and the reviewers
confirm that their comments are addressed, we'll be sending this to the
IESG.

Thanks to everyone who contributed to this effort.

Tomek