Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

["Bernie Volz (volz)" <[e-mail]>]

I believe Wes' and Hemant's issues were:

Wes (message on Thu 8/16/2012):

   Why MUST the client ignore an Advertise message with no bindings?
   What if stateful and stateless options are carried in the same message?
   Does this mean the stateless options will be ignored just because the stateful Options failed?

---

Ole's answer was that basically this is how RFC 3315 operates today and we didn't want to change this (we are fixing what happens if IA_NA and IA_PD are requested in a Solicit and only one of these is available) -- which is different than the no bindings at all case. RFC 3315 basically expects clients to use Information-Request in this case.

A while back, Ralph and I considered that this might be a good change - especially given the case when M says to use stateful but the server is not configured to give (the requesting client) any stateful bindings. Server could effectively respond with the other configuration options. But an Advertise is not the same as a Reply, so if the client was going to do a Request/Reply, we'd have to change that processing to and so why doesn't the client just do an Information-Request? (Sure, if Rapid Commit is requested, server would just Reply and client would be done.)

If the WG feels that would be a useful change, we can certainly do this change. But for this particular work, we didn't feel that change was warranted. And, it might be best to do under a separate document? Or something for a 3315bis?


Hemant (message on 8/17/2012) and Ole's response (using Ole's email on 8/20/2012):

> +1 to Wes' comment that this document is addressing a very important problem space and the solutions are needed urgently.  However, more thought is required for the solutions.
> 
> In regards to section 4.4, if the server only checks the network configuration to reply to a Confirm message, how is it possible for most network configurations that the server determines an IA_PD is on-link?   I suspect that is why RFC 3633 prohibited use of the Confirm for the IA_PD.  In any case this document should explain why did RFC 3633 have a restriction on using the Confirm for the IA_PD.  Or does network configuration include looking up the prefix pool configured on the server for allocation?  In contrast, to make an on-link determination for an IA_NA IA_Address, all the server has to do is match (longest-prefix match) all IPv6 addresses configured on the machine that the server is running on.  These addresses are clearly network configuration.  

right, either the server has the binding, or the server has configuration that it can look up in, to verify if the client has moved or not. if it has no information it MUST not reply.

> Section 4.1:  
> 
> # In relation to the first paragraph the document is addressing the fact that one server replies with, say, an IA_NA, while another server replies back with only the IA_PD.   Then why in section 4.7 the case of section 4.1 is deemed out of scope?   I also do not understand what does "equal" in section 4.7 mean.  Does it mean each server replies with all IAs that the deployment needs?

the assumption in 3315/3633 is that a client is connected to a single administrative dhc domain on an interface.
scenarios where a client finds two DHCP servers, that are administered by two different entities, are outside of the scope of 3315/3633 and therefore also outside the scope of this update. there is as far as I know separate work in progress on this.

> # In relation to the text in the last paragraph of section 4.1, if the client does not restart the Solicit retransmissions timers, what does the client do?

continues with the timers it has.
otherwise as the text says, a received advertise with a consequent restart of solicit timers would result in a solicit storm.

> 
> # Other comment:  Shouldn't the header of the document have an Updates tag to signify this document updates RFC 3315?

good point. both 3315 and 3633.

---

I guess the one change that I see is to assure we update the document header. We can respin the document for this change.

Section 4.4 is just extending the Confirm to include prefixes - this issue is already covered in RFC 3315 for Confirm processing:

                                                               If the server is unable to perform
   this test (for example, the server does not have information about
   prefixes on the link to which the client is connected), or there were
   no addresses in any of the IAs sent by the client, the server MUST
   NOT send a reply to the client.

The section 4.1 / 4.7 issue is the single vs multiple provisioning domains - we assume a single in this document.


If Wes or Hemant would like other changes to clarify any of their concerns, we would appreciate text to be added/modified.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[e-mail]] 
Sent: Friday, September 07, 2012 11:38 AM
To: Bernie Volz (volz)
Cc: dhc WG
Subject: Re: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

On Sep 7, 2012, at 11:09 AM, Bernie Volz (volz) <[e-mail]> wrote:
> Where does this Last Call stand? August 24th has passed ...

There were a lot of comments in the WGLC, and lot of support for what is to be accomplished here, but several people raised concerns as well.   There were a few responses in favor of advancing the current document; Hemant Singh had some suggestions, to which Ole responded.   I do not know if the responses satisfied Hemant's concerns.   I raised some concerns which were not really addressed.   Wes Beebe raised a concern which Ole responded to, but again I don't know if Wes was satisfied with Ole's response.


So I think this is borderline.   There's clearly widespread support for what this draft is trying to do; I would like to hear from Hemant and Wes as to whether they are satisfied with Ole's responses.   I tend to agree with Wes' sentiment that we need to think this through very carefully; I would like to see a new draft that addresses Hemant's and Wes' concerns, if possible, and then do a second last call to get more review.   Does that work for the authors?