Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-stateful-issues-03

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 14 Jan 2013 19:15:20 +0000

A 2nd Query regarding this as I heard nothing since the first.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Sunday, December 02, 2012 8:26 PM
To: [email-masked]
Subject: [dhcwg] draft-ietf-dhc-dhcpv6-stateful-issues-03

Hi:

I think I had addressed the issues raised to date ... Can a last call be started? Or, what else needs to be done to move this forward?

- Bernie

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Jan 2013 19:34:23 +0000

> A 2nd Query regarding this as I heard nothing since the first.

Oops, sorry about that, Bernie.

Folks, the authors of this draft feel it's ready for a WGLC.   There's been substantial discussion and comment already.   This is pretty important IPv6 deployment work, so more eyes are better.   Please review the draft and indicate whether or not you feel it is ready to be published.   We have been getting very anemic responses to working group messages recently.   Your response matters, so please do respond.

We will evaluate consensus after January 28.   Thanks!

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Tue, 15 Jan 2013 03:46:44 +0000

I read/reviewed this document and I support this document to move forward.

I do have some comments and it would be good if authors can consider them. Even otherwise I support this document. 

1.) In Abstract :-

"Implementation experience of the CPE model
   described in has shown multiple issues"
I think you wanted to specify RFC6204 after "described in"

2.) Section 4.2 Placement of Status codes.
  In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink,
   NoBinding) are encapsulated in the IA option.
I think we should include "NoPrefixAvail" as well in the above line. I see no reason why it should not be.

3.) For Confirm message. As I understand, we are now allowing CONFIRM message for IA_PD. I think we should update the definition of CONFIRM message in RFC3315 which currently only talks about *address*

<snip>
      CONFIRM (4)        A client sends a Confirm message to any
                         available server to determine whether the
                         addresses it was assigned are still appropriate
                         to the link to which the client is connected.
</snip>

Thanks,
Gaurav

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 15 Jan 2013 21:07:50 +0000

Hi:

Thanks for the comments, I've made some comments below (BV>).

Let's wait until the 28th before I draft the -04 version. Hopefully there will be more comments!

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gaurav Halwasia (ghalwasi)
Sent: Monday, January 14, 2013 10:47 PM
To: Ted Lemon; dhc WG
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03

1.) In Abstract :-

BV> Yes. 

BV> Yes. Might be best to use (i.e.) too so that it is clear that this is just a partial list.

<snip>

BV> Well this is a bit tricky as RFC 3315 knows nothing of prefix allocation. A RFC 3315bis would definitely want to reword it as such (as I would expect it to combine 3315 and 3633). This really falls into the changes to RFC 3633 that it would extend Confirm to include prefixes. We tried (I hope) to keep the RFC 3315 changes consistent with what RFC 3315 contained and PD changes to RFC 3633. There might be more we could add to RFC 3633, but do we really think that is necessary? I guess we could replace "addresses" with something more generic ("configuration information explicitly assigned to the client", which comes from the definition of binding in RFC 3315), but I think that doesn't really improve anything.

BV> Thus, I will not make this change.

Thanks,
Gaurav

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Wed, 16 Jan 2013 04:43:20 +0000

Thanks for taking care of comments. I agree with you point regarding point (3).

-Gaurav

-----Original Message-----
From: Bernie Volz (volz) 
Sent: Wednesday, January 16, 2013 2:38 AM
To: Gaurav Halwasia (ghalwasi); Ted Lemon; dhc WG
Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03

Hi:

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gaurav Halwasia (ghalwasi)
Sent: Monday, January 14, 2013 10:47 PM
To: Ted Lemon; dhc WG
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03

1.) In Abstract :-

BV> Yes. 

<snip>

Thanks,
Gaurav

---

From: Bud Millwood <[email-masked]>
Date: Mon, 21 Jan 2013 16:28:20 +0100

4.2: Proposed solution: No change.  For backwards compatibility, the
   NoAddrsAvail Status Code option when no addresses are available will
   be kept in the global scope for Advertise messages.

Question: Does it need to be further clarified that in Advertise,
"NoAddrsAvail" now may mean "SomeAddrsAvail"?

4.4: Note that clients that communicate with servers that do not support
   this updated Renew processing will receive the NoBinding status for
   the IA which had no bindings.

Question: isn't this also a valid response if the server does support
updated Renew processing, but cannot fulfill the binding for the IA?

4.5: It lets a server without a binding to reply to
   the message, under the assumption that the server only needs
   knowledge about the prefix(es) on the link, to inform the client that
   the address is likely valid or not.

- Change "lets" to "enables" or "allows", alt. remove "to" between
"binding" and "reply".

- Bud

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 21 Jan 2013 15:54:11 +0000

Hi:

Regarding 4.2, how is that? It always means no addresses available but may mean prefixes available.

Regarding 4.4, I would expect the server to return the IA_* option but without any IAADDR/IAPREFIX options. (The server would not really create a record of this binding since it has no leases.) Perhaps the text should be clarified regarding this. Note that perhaps a question exists as to which behavior to document for the Reply in this case:
1. Return the IA_* option, empty.
2. Do not return the IA_* option.
Either approach would work. 1 may provide more information to the client (but client implementers may prefer 2) -- it is also sending back what the client sent (since it had no IAADDR/IAPREFIXes to include).

Regarding 4.5, ok one of those edits can be done in a -04 (after 28th when WGLC ends). Usually the RFC-Editor also catches things like this, but best to give them a better document to start with.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bud Millwood
Sent: Monday, January 21, 2013 10:28 AM
To: Gaurav Halwasia (ghalwasi)
Cc: dhc WG; Bernie Volz (volz); Ted Lemon
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03

Question: Does it need to be further clarified that in Advertise, "NoAddrsAvail" now may mean "SomeAddrsAvail"?

Question: isn't this also a valid response if the server does support updated Renew processing, but cannot fulfill the binding for the IA?

- Change "lets" to "enables" or "allows", alt. remove "to" between "binding" and "reply".

- Bud

On Wed, Jan 16, 2013 at 5:43 AM, Gaurav Halwasia (ghalwasi) <[email-masked]> wrote:
> 3.) For Confirm message. As I understand, we are now allowing CONFIRM 
> message for IA_PD. I think we should update the definition of CONFIRM 
> message in RFC3315 which currently only talks about *address*
>
> <snip>

---

From: Bud Millwood <[email-masked]>
Date: Mon, 21 Jan 2013 23:52:25 +0100

> Regarding 4.2, how is that? It always means no addresses available but may mean prefixes available.

Yes of course; I should have reviewed 3633.

> Regarding 4.4, I would expect the server to return the IA_* option but without any IAADDR/IAPREFIX options. (The server would not really create a record of this binding since it has no leases.) Perhaps the text should be clarified regarding this.

The original text says to return an IA_* with no addr/prefix and a
status code "NoBinding". Now, if we cannot fulfill the binding, we do
the same thing, but we don't include a status code. Is that right?

> Note that perhaps a question exists as to which behavior to document for the Reply in this case:

(1) makes more sense to me because the server is explicitly
acknowledging the IA_*.

- Bud

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 21 Jan 2013 23:24:30 +0000

>The original text says to return an IA_* with no addr/prefix and a status code "NoBinding". Now, if we cannot fulfill the binding, we do the same thing, but we don't include a status code. Is that right?

Hum ... perhaps it is best to follow the Request and return NoAddrsAvail status in the IA_* option (of course we'd need to update RFC 3633 text then as well to return NoPrefixAvail).

The choices now seem to be:
1. Just return the IA_* option (empty).
2. Return IA_* option with NoAddrsAvail (or NoPrefixAvail) -- following Request logic.
3. Return IA_* option with NoBinding -- following existing Renew logic for unknown bindings.
4. Don't return the IA_* option (I think this is not a good choice and believe you don't either).

Perhaps new #2 is the best as it matches the Request ... Renew and Request are really very similar anyway - the main differences were:
- We are telling the server the client is renewing (thus is using the leases)
- No new bindings were 'allowed' -- this is now not true and what we are proposing to change.

We could do the same for the Rebind.

BTW: The case for a Rebind where the server can't find the client entry for the IA is not covered in RFC 3315 (it is if the addresses are no longer appropriate, but not otherwise). In some ways, this missing text leaves it up to the server (which for some cases, may be good - for example, Failover may trust the client and if there is no conflict, the server may want to respond -- that is what we do in V4). In other instances, the server might want to drop the Rebind or respond with NoBindings to force client back to Solicit? Also, the Rebind is missing the text that allows the server to change the addresses as appears in Renew. 

Opinions?

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bud Millwood
Sent: Monday, January 21, 2013 5:52 PM
To: Bernie Volz (volz)
Cc: dhc WG; Ted Lemon
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03

> Regarding 4.4, I would expect the server to return the IA_* option but without any IAADDR/IAPREFIX options. (The server would not really create a record of this binding since it has no leases.) Per…

The original text says to return an IA_* with no addr/prefix and a status code "NoBinding". Now, if we cannot fulfill the binding, we do the same thing, but we don't include a status code. Is that right?

> Either approach would work. 1 may provide more information to the client (but client implementers may prefer 2) -- it is also sending back what the client sent (since it had no IAADDR/IAPREFIXes to…

(1) makes more sense to me because the server is explicitly acknowledging the IA_*.

- Bud

---

From: Bud Millwood <[email-masked]>
Date: Tue, 22 Jan 2013 02:22:18 +0100

> - No new bindings were 'allowed' -- this is now not true and what we are proposing to change.

I think #2 is best approach. Since we can now create bindings in
Renew, and a client should be prepared to obtain a new lease at this
time, it's basically the same thing as Request from the standpoint of
the protocol. And judging by the names of the error codes,
NoAddrsAvail and NoPrefixAvail seem better because they reflect the
server's inability to create a binding. "NoBinding" seems more like
"No info, can't proceed" (which is more suited the previous behavior).

> We could do the same for the Rebind.

I suppose my argument in favor of this is the same as above. If the
client must be prepared to accept a new lease at this time, it's like
a "deferred Request".

> BTW: The case for a Rebind where the server can't find the client entry for the IA is not covered in RFC 3315 (it is if the addresses are no longer appropriate, but not otherwise). In some ways, th…

Maybe it's important to distinguish between not being able to create a
new binding for a non-existent lease (NoAddrsAvail/NoPrefixAvail) and
not being able to create a new binding for an existing lease? (Or for
that matter, for the latter, not being able to rebind the addr/prefix
in question due to lack of information).

- Bud

---

From: Ted Lemon <[email-masked]>
Date: Fri, 1 Feb 2013 03:56:30 +0000

> We will evaluate consensus after January 28.   Thanks!

Bud offered some comment.   Aside from that, nobody said they wanted the draft to advance, and nobody objected.   By default this means it fails the last call and will not advance.   Is that really the outcome that people want, or was everybody just asleep when the WGLC went out?

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Fri, 1 Feb 2013 04:03:07 +0000

Just in case it got missed, I replied saying that I want this document to move forward (I also had some comments and Bernie replies to that as well).

As it stands today, I am in favor of advancing this draft.

-Gaurav