Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-stateful-issues-10.txt

From: 神明達哉 <[email-masked]>
Date: Mon, 2 Feb 2015 09:48:39 -0800

At Fri, 30 Jan 2015 20:03:28 +0000,
"Bernie Volz (volz)" <[email-masked]> wrote:

> For those that are interested in the issues raised and resolution, please see the attached PDF (of the Google docs spreadsheet Marcin and I used to record the issues and determine our actions). Note: If the PDF fails to make it through, I will send an update with a URL (once I find a good place to put it).
>
> Please review this updated version to assure you are happy with it.

(resnding the same content that I sent to the authors offlist)

I've only checked the updates related to my previous comments; I've
not read the entire text.

#53: it's not clear why my comment was rejected, and the revised
     abstract still seems to be awkward/not so helpful for first time
     or potential readers.  But it looks like I've been failing to
     persuading the authors on this point, so I won't insist on it
     anymore.
#54: likewise.  the justification still looks weak to me (note that
     I'm not opposed to the choice itself, even if it's just a matter
     of preference).  But I won't insist.
#55: it's not clear why it's rejected.
#56 and #57: does this mean we defer the fix to dhcpv6bis even if the
     points are deemed to be an issue?  If so, I don't think it a good
     idea especially now that I understand the intent of this work is
     to publish it as a standalone RFC.

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 4 Feb 2015 15:25:40 +0000

Jinmei:

Regarding #53, we took Ted's suggested re-write of the Abstract, so perhaps if you want to have this changed, you can work something out with Ted (you did say you won't insist, so we will leave it to you to follow up with Ted if you want to). This is one issue with multiple reviewers providing conflicting changes.

Regarding #54, we feel that the text is OK as is. If you want to follow up, please suggest explicitly what you want the text to read and we can reconsider.

Regarding #55, again, we feel that the changes in total are sufficient regarding this and further clarification is not required.

Regarding #56 & 57 - While the draft is titled "stateful issues", it is not designed to cover all stateful issues (this is just a short name and given everything we know today, a different title would likely have been better). In this work, we are just trying to address the CPE IA_NA/IA_PD issues. So, if the problem isn't specific to that case, we want to defer all other issues to the DHCPv6bis work. We need to draw the line somewhere, otherwise we could continue this particular draft "forever". If you do feel strongly that these issues deserve more prompt attention than the DHCPv6bis effort, perhaps you are willing to start another document to address these (and perhaps) other issues.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Monday, February 02, 2015 12:49 PM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-stateful-issues-10.txt

I've only checked the updates related to my previous comments; I've not read the entire text.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Fri, 6 Feb 2015 10:35:02 -0800

At Wed, 4 Feb 2015 15:25:40 +0000,
"Bernie Volz (volz)" <[email-masked]> wrote:

> Regarding #56 & 57 - While the draft is titled "stateful issues", it
> is not designed to cover all stateful issues (this is just a short
> name and given everything we know today, a different title would
> likely have been better). In this work, we are just trying to
> address the CPE IA_NA/IA_PD issues. So, if the problem isn't
> specific to that case, we want to defer all other issues to the
> DHCPv6bis work.

Depending on the rationale for deferring specific points, I can live
with that.  But I'd at least like to understand why it's okay to
defer.  Regarding #56, or more specifically, on the following text of
stateful-issues-10:

     When the client receives a NotOnLink status from the server in
     response to a Request, the client can either re-issue the Request
     without specifying any addresses or restart the DHCP server
     discovery process (see section 17).

Specifically why is it okay to defer it?  Because a CPE-type client
isn't supposed to be a mobile device and is unlikely to get NotOnLink
(or for that matter it's even unlikely for the client to send Confirm
in the first place)?

What about #57?  I guess the relevant text in stateful-issues-10 is
now this one:

     If the client cannot operate without the addresses for the IAs for
     which it received the NoAddrsAvail status code, the client may try
     another server (perhaps by restarting the DHCP server discovery
     process).

Why can we dismiss it (in terms of #57)?  Perhaps because it's assumed
to be unlikely that the client (= CPE) gets a prefix but not an
address?

BTW: as for the title, I guess I previously suggested to rename it so
it matches what's actually described better, e.g, "Clarification on
Mixed Use of DHCPv6 Address Assignment and Prefix Delegation".  For
people discussing this drafts here (like you and me), this doesn't
matter much since we know all the history of how this document has
evolved into the current form.  But if we publish it as an RFC, it
will be more important to make it clearer and less confusing for
future readers who don't have the background context.  In that sense I
personally it's worth doing if we can find a better title, and I don't
think it's too late yet.

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 6 Feb 2015 20:13:25 +0000

Jinmei:

For #56, how is this text much different from what is in RFC 3315:

"When the client receives a NotOnLink status from the server in response to a Request, the client can either re-issue the Request without specifying any addresses or restart the DHCP server discovery process (see section 17<http://tools.ietf.org/html/rfc3315#section-17>)."

For #57, from 3315:

"When the client receives a NotOnLink status from the server in
   response to a Request, the client can either re-issue the Request
   without specifying any addresses or restart the DHCP server discovery
   process (see section 17<http://tools.ietf.org/html/rfc3315#section-17>)."

How is what we are saying any different? That is why this is a general RFC 3315 issue and we drew the line not to address it in stateful issues. Again, this draft is to address a subset of the entire set of issues.

Feel free to start a new draft if you wish to start work on discussing these issues; we are planning to request adoption of the 3315bis work shortly, so that is another venue.

We will rediscuss title change.

- Bernie (from iPad)

On Feb 6, 2015, at 1:35 PM, 神明達哉 <[email-masked]<mailto:[email-masked]>> wrote:

At Wed, 4 Feb 2015 15:25:40 +0000,
"Bernie Volz (volz)" <[email-masked]<mailto:[email-masked]>> wrote:

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Mon, 9 Feb 2015 10:18:20 -0800

At Fri, 6 Feb 2015 20:13:25 +0000,
"Bernie Volz (volz)" <[email-masked]> wrote:

> How is what we are saying any different?

The main difference is that dhcpv6-stateful-issues now specifies that
clients use a single DHCPv6 session for all IA options, and not
clarifying these can break the integrity of the specification.  See,
e.g., the very last paragraph of
http://www.ietf.org/mail-archive/web/dhcwg/current/msg15934.html

On the other hand, in RFC3315 it's simply unclear and (implicitly)
left to the implementation.   To me, these two are very different
kinds of issues.  I can leave the latter open, but not the former.

> Feel free to start a new draft if you wish to start work on discussing these issues; we are planning to request adoption of the 3315bis work shortly, so that is another venue.

I'm fine with deferring the resolution to 3315bis (also, I don't think
it's worth a separate draft).  But I'd at least like dhcpv6-stateful-issues
to clearly state these points are open issues and will be handled in
later document(s).  Otherwise it will confuse implementors of this
specification.  If you don't mind adding such text, I'm willing to
volunteer to propose a possible small subsection for that.  But to do
so, I first wanted to understand why these are minor enough and we can

--
JINMEI, Tatuya

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 10 Feb 2015 21:27:30 +0100

> kinds of issues.  I can leave the latter open, but not the former.
How about adding this sentence at the end of the 4.3 section:
"This change effectively will cause clients to make all renewals in a
single exchange." Would that be sufficient?

> later document(s).
Personally, I think it's a bit redundant (no RFC could make a promise of
never being updated in the future), but for the sake of moving forward
we can consider adding the following at the end of the section:

OLD:
  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]).
NEW:
  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]), which will also address additional open
  issues.

Would that be sufficiently clear? I'd really like this document to move
forward sooner rather than later.

On a related note, we plan to start adoption call for 3315bis in a bit
over a week from now. To have it adopted by Dallas, we'll need to start
it around Feb. 18th.

I have minor comments about the draft, both are related to idnits:
1. idnits reports one mis-capitalisation: "MUST not" => "MUST NOT"

2. You're proposing updates to several sections of RFCs that were
published prior to RFC5378 and I think you haven't obtained approvals
from all original authors to move to the BCP78 rights. Therefore you
should use pre-RFC5378 boilerplate. Don't worry, it's easy to do.
Changing in the xml ipr="Trust200902" to ipr="pre5378Trust200902" should
do the trick.

3. Reference update is required draft-ietf-mif-mpvd-arch-09 => -10.

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 10 Feb 2015 22:03:43 +0000

I've done the nits (so xml is -11, fixed MUST not, and changed to pre5378Trust200902).

I've not touched the other issues.

I'm thinking that we really need to be careful about hinting at other issues as IESG may ask why not fix those too. But perhaps Ted has some advice here?

And, we still have the draft title to resolve.

Once Jinmei or others comment on the propose for 4.3 text ...

It would be good to get this done now so that Ted can raise and discuss at IESG, but alas perhaps that will not be possible and we'll just have to let things develop as they will. (I sure would like to get this effort over and done with too ... it has been a long slow process - it is never easy putting things in words.)

- Bernie

-----Original Message-----
From: Tomek Mrugalski [mailto:[email-masked]] 
Sent: Tuesday, February 10, 2015 3:27 PM
To: 神明達哉; Bernie Volz (volz)
Cc: [email-masked]; Ted Lemon ([email-masked])
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-stateful-issues-10.txt

How about adding this sentence at the end of the 4.3 section:
"This change effectively will cause clients to make all renewals in a single exchange." Would that be sufficient?

> it's worth a separate draft).  But I'd at least like 
> dhcpv6-stateful-issues to clearly state these points are open issues 
> and will be handled in later document(s).
Personally, I think it's a bit redundant (no RFC could make a promise of never being updated in the future), but for the sake of moving forward we can consider adding the following at the end of the section:

OLD:

Would that be sufficiently clear? I'd really like this document to move forward sooner rather than later.

On a related note, we plan to start adoption call for 3315bis in a bit over a week from now. To have it adopted by Dallas, we'll need to start it around Feb. 18th.

2. You're proposing updates to several sections of RFCs that were published prior to RFC5378 and I think you haven't obtained approvals from all original authors to move to the BCP78 rights. Therefore you should use pre-RFC5378 boilerplate. Don't worry, it's easy to do.
Changing in the xml ipr="Trust200902" to ipr="pre5378Trust200902" should do the trick.

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Feb 2015 18:32:25 -0500

> single exchange." Would that be sufficient?

I don't think this really helps, because as Marcin said, there is an actual change in expected behavior here.   I think we just ("just!") need to say what we think the right behavior is in the case he describes.

I must confess however, that I consider this a weakness to the whole proposal, and consequently I don't actually have advice.   It seems to me that you can have any of the following DHCP server behaviors:

a: a DHCP server will offer IA_NA but not IA_PD
b: a DHCP server will offer IA_PD but not IA_NA
c: a DHCP server will offer both IA_PD and IA_NA if requested

Suppose you have servers corresponding to (a), (b) and (c) configured on a particular network.   A client that attempts to get an IA_NA and an IA_PD may not succeed in contacting server c, perhaps because it is offline.   It could get full service from (a) and (b) combined, but we've said that that's not how DHCPv6 is supposed to work.   So it has to pick one.

Now suppose (c) comes online and responds to a subsequent request, because the client has chosen one of (a) or (b) but is not satisfied.   In this case, the client has to either switch to (c) and lose whatever it got from (a) or (b), or else it has to continue with its existing configuration.   Presumably it will switch, because otherwise why would it have persisted in trying to get a new configuration?

The alternative is to say that when possible, DHCP clients will keep the state machines for IA_NA and IA_PD in sync, but if it can't get a full configuration that way, and can get a full configuration by running two separate state machines, it should.   We could add that when (c) appears, it should do a soft renumber to (c), deprecating the address(es) it got either from (a) or (b), but should maintain two state machines during the interim.

I don't have a strong preference.   I think you get better behavior with the alternative, but the implementation is easier if we say that the client maintains only one state machine.

I haven't read the draft in a while, so I realize that what I just wrote may be out of sync with what the draft currently says, but I think what I just described represents the two possible ways of addressing this concern, and I am okay with either approach.   I think leaving it unspecified isn't a great solution, and addressing it with a single sentence as Tomek proposed will likely not be understood by many client implementors.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Feb 2015 18:35:53 -0500

> I'm thinking that we really need to be careful about hinting at other issues as IESG may ask why not fix those too. But perhaps Ted has some advice here?

We can just tell them the 3315bis work is in progress, and will sweep up other changes; this draft captures the ones that we considered most urgent.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 11 Feb 2015 03:06:29 +0000

Just to be clear, the draft only recommends that clients use a single state machine and it makes that better because it offers clients the ability to Renew more than the IAs they got (and to keep renewal times in sync). Nothing in the draft requires that a client only maintain one state machine. The goal was never to prohibit this, just to make it more likely that it would work out correctly. That was the primary motivation for the draft long ago.

The key text is:

      We have chosen to recommend that clients use the remaining option:
      a single DHCP session and state machine.  The client maintains a
      single session and state machine. It uses the best configuration it
      is able to obtain during any configuration exchange.   But it
      continues, in each subsequent configuration exchange, to request all
      the configuration information it is programmed to try to obtain,
      including any stateful configuration options for which no results
      were returned in previous exchanges.

Clients already face the issue with how they handle these cases today.

I'm not so sure we can solve this issue - it will really be up to the client implementers as to what they consider 'required' for minimum service and how they handle degraded service (when only NA or PD, not both are available). For example, a home gateway should likely be fine without an NA - just needs a PD (at least to provide the basic routing service).

Also, while anything is possible, in many cases where NA + PD are used (SP networks), it would likely be rare that you'd have combinations of the servers - except for misconfigured cases. And in those, when the server with the broken configuration is fixed, this single state machine still works since on the next Renewal the missing NA or PD will be requested. The reason for the draft is again that in some cases the lifetimes of NAs can drift from those of PD (or be configured differently) and then you can end up in cases where this requires separate state machines.

Perhaps  we can add something regarding this and just explain the issue(s) and that it would be up to implementation to decide how best to proceed.

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Feb 2015 22:39:26 -0500

> Perhaps  we can add something regarding this and just explain the issue(s) and that it would be up to implementation to decide how best to proceed.

Sure.   Bear in mind that situations encountered rarely are precisely the ones that it's good to describe in the document so that people code for them and don't get surprised by them later.

---

From: Ole Troan <[email-masked]>
Date: Wed, 11 Feb 2015 08:55:52 +0100

Ted,

> Now suppose (c) comes online and responds to a subsequent request, because the client has chosen one of (a) or (b) but is not satisfied.   In this case, the client has to either switch to (c) and l…

it is hard to see why that isn't a misconfiguration.
you could make up the same failure scenario with other configuration options as well.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Feb 2015 07:46:53 -0500

> you could make up the same failure scenario with other configuration options as well.

It could be that more than one administrative domain is offering service on the wire.  But I tend to agree that it's a bad way to configure things; the question is what the client does when things are configured that way.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Feb 2015 07:47:38 -0500

> Perhaps  we can add something regarding this and just explain the issue(s) and that it would be up to implementation to decide how best to proceed.

This is probably the right approach.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 11 Feb 2015 09:08:13 -0800

(Jumping to this point)

At Wed, 11 Feb 2015 07:47:38 -0500,

> This is probably the right approach.

I think it works for me, too.

Commenting on a few more points that may be related:

At Wed, 11 Feb 2015 03:06:29 +0000,
"Bernie Volz (volz)" <[email-masked]> wrote:

> Just to be clear, the draft only recommends that clients use a
> single state machine and it makes that better because it offers
> clients the ability to Renew more than the IAs they got (and to keep
> renewal times in sync). Nothing in the draft requires that a client
> only maintain one state machine.

Hmm, that intent was not clear, at least to me.  Certainly, it doesn't
explicitly prohibit other options than the single DHCPv6 session, but
I basically interpret the overall tone of Section 4 that way.  One
background reason for that is probably because it just talks about
drawbacks of other options and then leads to the text pasted below
(this is also related one of my other comments, which was rejected, to
which I wouldn't be opposed at this point).

>       were returned in previous exchanges.

If this is intended to mean clients can choose (or may end up
choosing) other options, the intent wasn't clear to me either.

If, for example, section 4 was revised to read like this, I think my
concern will be addressed:

  There can be several choices on how to handle multiple IA options
  (and, specifically IA_NA and IA_PD) including 1-3.  All choices
  have their own pors and cons, but this document focuses on choice #3
  (using a single DHCPv6 session for both IA_NA and IA_PD) because
  it's deemed to work best for common cases of the mixed use of IA_NA
  and IA_PD.  But this document doesn't exclude other choices.  Also,
  in some corner cases it may not feasible to maintain a single DHCPv6
  session for both IA_NA and IA_PD.  These general and corner cases
  are beyond the scope of the discussion and will be deferred to the
  next revision of the base DHCPv6 specification (i.e., 3315bis).

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Feb 2015 09:38:15 -0500

On Feb 12, 2015, at 9:34 AM, Marcin Siodelski <[email-masked]> wrote:
>   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 if there are very many DHCP clients on the network.

---

From: Marcin Siodelski <[email-masked]>
Date: Thu, 12 Feb 2015 15:40:10 +0100

> Or if there are very many DHCP clients on the network.
duly noted

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Feb 2015 09:45:22 -0500

>> Or if there are very many DHCP clients on the network.

The point being that this gets into the rate limiting problem that RFC 7083 addresses; it might be worth putting a reference to RFC 7083 here and advising implementors who go with this option that they must also implement RFC 7083.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 12 Feb 2015 09:31:32 -0800

At Thu, 12 Feb 2015 15:34:36 +0100,
Marcin Siodelski <[email-masked]> wrote:

> As a result of this discussion, we have come up with the following text
> for the section 4. This new text is now being included in the version
> -11 of the draft, but we're holding off the publication until we hear
> from you. However, it would be great if you could review and respond
> today, so as we can publish it and meet the deadlines we have set with Ted.

Thanks, it seems to address my concern.

One editorial point: the added paragraph seems to be mostly a verbatim
copy of my summary text and looks a bit awkward if placed in the
middle of the section.  For example, the first sentence looks
redundant (the section already mentioned that there are several
choices).

And, one minor nit (an error from my own text):

>    choices.  Also, in some corner cases it may not feasible to maintain

s/may not feasible/may not be feasible/

Combining these, I suggest revising the paragraph as follows:

   While all choices have their own pros and cons, we recommend and
   focus on choice 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 choices.  Also, in some corner
   cases it may not be feasible to maintain a single DHCPv6 session
   for both IA_NA and IA_PD.  These corner cases are beyond the scope
   of this document and may depend on the network in which the client
   (CER) is designed to operate and on the functions the client is
   required to perform.

Also, although it doesn't seem to be critical in terms of my main
point and I wouldn't consider it a blocking issue, this paragraph is
not easy to understand to me:

>    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.  If the server is not configured
>    to deliver the entire configuration requested by the client, the
>    client could continue to operate using the configuration received.
>    But ideally it then continues, in each subsequent configuration
>    exchange, to request all the configuration information it is
>    programmed to try to obtain, including any stateful configuration
>    options for which no results were returned in previous exchanges.
>    However, this is difficult with the current DHCPv6 specifications.

Does it try to say something like this?

    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.  In practice,
    especially in the case of handling IA_NA and IA_PD, this situation
    should be rare or a temporary operational error.  So, it is more
    likely for the client to get all configuration if it continues, in
    each subsequent configuration exchange, to request all the
    configuration information it is programmed to try to obtain,
    including any stateful configuration options for which no results
    were returned in previous exchanges.

    One major issue of this last approach is that it is difficult to
    allow it with the current DHCPv6 specifications; in some cases
    it is not clear enough, and in other cases existing restrictions
    can make it impossible.  This document introduces some
    clarifications and small modifications to the current
    specification to address this concern.

(The second paragraph is my attempt of rephrasing the very last
sentence of the original paragraph based on my the seeming intent of
it)

If so, and if you think my text is clearer, please feel free to use
it.  If you believe the original text is clear enough (and especially
if others also think so), I'm okay with keeping the original
paragraph.

--
JINMEI, Tatuya

---

From: Marcin Siodelski <[email-masked]>
Date: Thu, 12 Feb 2015 18:56:18 +0100

> Thanks, it seems to address my concern.

That's great!

>    (CER) is designed to operate and on the functions the client is

That looks ok to me.

> if others also think so), I'm okay with keeping the original

We will discuss this with Bernie and decide to what extent we will use
your text.

Many thanks for the prompt response!

Marcin

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 12 Feb 2015 18:38:03 +0000

let's just go with it.

- Bernie (from iPhone)

> On Feb 12, 2015, at 12:56 PM, Marcin Siodelski <[email-masked]> wrote:
> 
>

---

From: Marcin Siodelski <[email-masked]>
Date: Thu, 12 Feb 2015 15:34:36 +0100

>   next revision of the base DHCPv6 specification (i.e., 3315bis).

Jinmei et al.

I have also attached the (unpublished) version -11 in the text format.

Many thanks!
Marcin

-------------------

   The DHCPv6 specification [RFC3315] was written with the assumption
   that the only stateful options were for assigning addresses.  DHCPv6
   Prefix Delegation [RFC3633] describes how to extend the DHCPv6
   protocol to handle prefix delegation, but does not clearly specify
   how the DHCP address assignment and prefix delegation co-exist.

   If a client requests multiple IA option types, but the server is
   configured to only offer a subset of them, the client could react in
   several ways:

   1.  Reset the state machine and continue to send Solicit messages,

   2.  Create separate DHCP sessions for each IA option type and
       continue to Solicit for the unfulfilled IA options, or

   3.  The client could continue with the single session, and include
       the unfulfilled IA options in subsequent messages to the server.

   Creating a separate DHCP session (separate instances of the client
   state machine) per IA option type, while conceptually simple, causes
   a number of issues: additional host resources required to create and
   maintain multiple instances of the state machine in clients,
   additional DHCP protocol traffic, unnecessary duplication of other
   configuration options and the potential for conflict, divergence in
   that each IA option type specification specifies its 'own' version of
   the DHCP protocol.

   There are several choices on how to handle multiple IA options (and,
   specifically IA_NA and IA_PD) including 1-3 above.  Each choice has
   its own pros and cons.  For this document, we recommend and focus on
   choice 3 (using a single DHCPv6 session for both IA_NA and IA_PD)
   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
   choices.  Also, in some corner cases it may not feasible to maintain
   a single DHCPv6 session for both IA_NA and IA_PD.  These corner cases
   are beyond the scope of this document and may depend on the network
   in which the client (CER) is designed to operate and on the functions
   the client is required to perform.

   The sections which follow update RFC 3315 and RFC 3633 to accommodate
   the recommendation, though many of the changes are also applicable
   even if other choices are used.

-----

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 12 Feb 2015 23:21:07 +0000

I have published a -11 version of the draft that hopefully addresses Jinmei's and Ted's most recent comments.

The wording was tweaked slightly from that discussed.

Please see the -11 draft. http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues.

The copyright notice was also adjusted as pointed out by Tomek as we are referencing text from pre 2008 RFCs.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

- Bernie (and Marcin and Ole)

-----Original Message-----
From: Marcin Siodelski [mailto:[email-masked]] 
Sent: Thursday, February 12, 2015 12:56 PM
To: 神明達哉
Cc: Ted Lemon; [email-masked]; Bernie Volz (volz)
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-stateful-issues-10.txt

On 12/02/15 18:31, 神明達哉 wrote:
> > As a result of this discussion, we have come up with the following 
> > text for the section 4. This new text is now being included in the 
> > version
> > -11 of the draft, but we're holding off the publication until we 
> > hear from you. However, it would be great if you could review and 
> > respond today, so as we can publish it and meet the deadlines we 
> > have set
> with Ted.
>

That's great!

That looks ok to me.

> if others also think so), I'm okay with keeping the original 

We will discuss this with Bernie and decide to what extent we will use your text.

Marcin

---

From: 神明達哉 <[email-masked]>
Date: Fri, 13 Feb 2015 09:54:54 -0800

At Thu, 12 Feb 2015 23:21:07 +0000,

> Please see the -11 draft. http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues.

In case an explicit confirmation was expected: I have no objection to
shipping it.

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 13 Feb 2015 17:57:32 +0000

Thanks!

I think Tomek should be ready to provide Ted the shepherd write-up and submit for publication - so hopefully it will happen shortly!

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Friday, February 13, 2015 12:55 PM
To: Bernie Volz (volz)
Cc: Marcin Siodelski; [email-masked]; Ted Lemon
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-stateful-issues-10.txt

> Please see the -11 draft. http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues.

In case an explicit confirmation was expected: I have no objection to shipping it.

--
JINMEI, Tatuya