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

From: Ole Troan <[email-masked]>
Date: Fri, 1 Feb 2013 10:35:21 +0100

Ted,

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

if I didn't say so, my apologies. I'm biased as one of the authors though.

the combination of RFC3315 and RFC3633 is broken. this document fixes that. I really think we should advance this.

cheers,
Ole

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 1 Feb 2013 14:16:30 +0000

+1
I would like to see this draft published.
Barbara

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ole Troan
> Sent: Friday, February 01, 2013 4:35 AM
> To: Ted Lemon
> Cc: dhc WG
> Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03
> 
> Ted,
> 
> >> 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.
> >>
> > 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?
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Tim Chown <[email-masked]>
Date: Fri, 1 Feb 2013 16:59:33 +0000

I support publication.

---

From: "Leaf Yeh" <[email-masked]>
Date: Mon, 18 Feb 2013 15:33:02 +0800

E1. Editorial - How about change the title of the draft to be 'Updates of
RFC 3315 and RFC3633 with multiple stateful options'?

The updates could be summarized as follows:
a. Client should keep a single session with the multiple stateful options
(in subsequent messages, Request, Renew, and Rebind, to the server.) 
b. Ideally the Status Code option should be encapsulated in the IA option
for all DHCP messages. This makes Advertisement messages equal to Reply
messages. (A new recommendation to the server though there is a issue for
backwards compatibility)
c. The server SHOULD set the T1/T2 timers in all IA options in Reply and
Advertise messages to the same value. (A new recommendation to the server)
d. makes the server's IA processing of Renew and Rebind similar to the
Request processing (but ORO sounds also make it).
e. Allow the Confirm message work for DHCPv6-PD.

Right?

E2. Editorial - Page 3 - Section 3 
< snip >Each IA holds one type of IA option; for example, ... </ snip >

Does it mean IA_NA and IA-PD will never share the same IA? I guess the
better text could be 'Each IA option holds one type, for example,... '

T1. Page 7 - Section 4.4

<snip>The client also includes an IA option for each binding it desires but
has been unable to obtain. </snip>

Could the above text be replaced by the original text in RFC3315? 
'The client MUST include an Option Request option (see section 22.7)
to indicate the options the client is interested in receiving. The
client MAY include options with data values as hints to the server
about parameter values the client would like to have returned.'

T2. Technical - Page 7- Section 4.4
<snip>If the server cannot find a client entry for the IA the server
creates the bindings for that client according to the server's
policy and configuration information and records the IAs and
other information requested by the client. </snip>

Not sure the above sounds a necessary behavior of the server. What is the
issue if the server doesn't create the bindings for that client when the
server cannot find a client entry for the IA?

E3. Editorial - Page 7 - Section 4.4

<snip>However, it MUST limit the frequency at which is does this to no more
often than the renewal frequency. </snip>

I guess the right text sounds '...at which it does this to... '.

E4. Editorial - Page 8 - Section 4.5

<snip> If such verification is needed the requesting router MUST initiate
a Confirm message exchange as described in section 18.1.2,
"Creation and Transmission of Confirm Messages" of RFC 3315.</snip>

The above text sounds '...MUST initiate a Confirm/Reply message
exchange...'.

E5. Editorial - Saw many 'should's have not been in the format of 'SHOULD'
yet.

Best Regards,
Leaf

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

>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.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. 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).

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

- Bud

> 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
> Of Bud Millwood
> Sent: Monday, January 21, 2013 10:28 AM
> To: Gaurav Halwasia (ghalwasi)
> Cc: dhc WG; Bernie Volz (volz); Ted Lemon
> 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
>
>
> On Wed, Jan 16, 2013 at 5:43 AM, Gaurav Halwasia (ghalwasi)
<[email-masked]> wrote:
>> Thanks for taking care of comments. I agree with you point regarding
point (3).
>> -Gaurav
>> 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:
>>
>> 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
>> 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
>> 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"
>>
>> BV> Yes.
>>
>> 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.
>>
>> BV> Yes. Might be best to use (i.e.) too so that it is clear that this is
just a partial list.
>>
>> 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>
>>
>> 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: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Ted Lemon
>> Sent: Tuesday, January 15, 2013 1:04 AM
>> To: dhc WG
>> Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03
>>
>> On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) <[email-masked]> wrote:
>>> 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.

---

From: "Leaf Yeh" <[email-masked]>
Date: Mon, 18 Feb 2013 15:33:02 +0800

Request logic.
unknown bindings.
>Perhaps new #2 is the best as it matches the Request ... Renew and Request
are really very similar anyway

#2 & # 3 sounds roughly the same to me. Could the client directly interpret
the 'NoBinding' to be 'NoAddrsAvail (or NoPrefixAvail)' here?

Bernie - 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.

Do we need more text on REBIND here? Sounds like the same behavior as the
RENEW at server side: (referring to section 18.2.3 of RFC3315)

a. If the server cannot find a client entry for the IA, the server returns
the IA containing with a Status Code option set to NoBinding in the Reply
message.
b. The server may choose to change the list of addresses/prefixes and their
lifetimes in IAs that are returned to the client. (I think we'd mention
IA_PD in the updates of RFC3315)

Best Regards,
Leaf

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

Request logic.
unknown bindings.
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

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

>> Regarding 4.2, how is that? It always means no addresses available but
may mean prefixes available.
the IA_*.
>
> - Bud
>
>> 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.
>> Behalf Of Bud Millwood
"binding" and "reply".
point (3).
>>> Let's wait until the 28th before I draft the -04 version. Hopefully
there will be more comments!
forward.
>>>
>>> BV> Yes. Might be best to use (i.e.) too so that it is clear that this
is just a partial list.
>>>
>>> 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: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 18 Feb 2013 16:10:20 +0000

Hi:

Thanks for the thorough review.

Some comments below (BV>).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leaf Yeh
Sent: Monday, February 18, 2013 2:33 AM
To: Bernie Volz (volz)
Cc: 'dhc WG'
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03

BV> While we could change the title, I don't really see this as that critical.

Right?

BV> Yes, except for D and ORO. (See below.)

BV> I am not sure what you are asking here. An instance of an IA is a IA_NA or IA_PD. IA is short for Identity Association. Note that this just updates RFC 3315's definition which was address based.

T1. Page 7 - Section 4.4

BV> ORO are not used for IA_NA/IA_PD/IA_TA. As the client must assign an IAID so it must send the IA_* option.

BV> Interesting point and the text should probably be revised to allow the older behavior as servers might not be updated.

BV> Yes. This should be it, not is.

BV> Yes. To we should add /Reply.

BV> There may be a few that could be changed to SHOULD. In general, only the proposed solution and changes would have these capitalized per RFC 2119. I think there are only 2 to consider for should -> SHOULD - in 4. and 4.4.  in proposed solution text. For must -> MUST, 4.6. There are a few grey areas that may also switch the case ... I think for the discuss text we may want to lower case. I'll discuss this with Ole and see what we do for a revised draft. If someone has a strong opinion one way or the other, please let us know.

Best Regards,
Leaf

-----Original Message-----

Opinions?

- Bernie

-----Original Message-----

mean prefixes available.

- Bud

"binding" and "reply".
point (3).
will be more comments!
forward.
just a partial list.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 18 Feb 2013 16:28:09 +0000

Hi again:

#1 and #2 are probably 'equal'.

The REBIND case is an interesting one and while #2 and #3 are probably close to the same result in terms of the client's behavior, I wonder what existing servers do -- I would guess that they are more likely to return #3 (matching Renew) if they aren't willing to 'create' the binding?

The subtle difference between #2 and #3 may be:
- #2 means that the server would be willing to assign the binding a lease if it had a lease to give.
- #3 means that the server would not be willing to assign the binding a lease because it has no record of the binding and would not create one.

For #2, the message is clear that the client can continue to try. Whereas for #3, it may be that the client needs to return to Solicit if it ever hopes to get the binding.

I think that may be the key to this ... NoBinding means that the server will not assign a new binding except via Solicit/... whereas NoAddrsAvail/NoPrefixAvail means that the server has nothing to give the client but would otherwise accept the binding.

I think we should make Renew and Rebind the same here (i.e. return #2 and #3 depending on the situation). What the client does with this information is likely:
- If NoBinding, return to Solicit.
- If NoAddrsAvail/NoPrefixAvail, continue to Renew/Rebind with the existing leases (at T1/T2 times). If no leases, return to Solicit.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leaf Yeh
Sent: Monday, February 18, 2013 2:33 AM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03

Request logic.
unknown bindings.

Best Regards,
Leaf

-----Original Message-----

Request logic.
unknown bindings.
proposing to change.

- Bud

the IA_*.
"binding" and "reply".
point (3).
forward.
is just a partial list.

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 19 Feb 2013 00:58:03 +0800

LY> Does it mean IA_NA and IA-PD will never share the same IA? I guess the
better text could be 'Each IA option holds one type, for example,... '
BV> I am not sure what you are asking here. An instance of an IA is a IA_NA
or IA_PD. IA is short for Identity Association. Note that this just updates
RFC 3315's definition which was address based.

IA(Identity Association) is specified by IAID, which sounds associated with
the client's interface. My question is whether a IA-NA and a IA_PD could
have the same IAID? If yes, my text might be better.

T1. Page 7 - Section 4.4

LY> Could the above text be replaced by the original text in RFC3315? 

'The client MUST include an Option Request option (see section 22.7) to
indicate the options the client is interested in receiving. The client MAY
include options with data values as hints to the server about parameter
values the client would like to have returned.'

BV> ORO are not used for IA_NA/IA_PD/IA_TA. 

Not 100% sure about this point. I can't find the referenced text in RFC3315
yet.

BV> As the client must assign an IAID so it must send the IA_* option.

The might mean that IA_xx should also be included after ORO. 

I meant the original text in RFC3315 might cover the case of the above new
suggested text in the new draft.

Best Regards,
Leaf

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Tuesday, February 19, 2013 12:10 AM
To: Leaf Yeh
Cc: 'dhc WG'
Subject: RE: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03

Hi:

- Bernie

-----Original Message-----
Leaf Yeh

BV> While we could change the title, I don't really see this as that
critical.

The updates could be summarized as follows:
a. Client should keep a single session with the multiple stateful options
(in subsequent messages, Request, Renew, and Rebind, to the server.) b.
Ideally the Status Code option should be encapsulated in the IA option for
all DHCP messages. This makes Advertisement messages equal to Reply
messages. (A new recommendation to the server though there is a issue for
backwards compatibility) c. The server SHOULD set the T1/T2 timers in all IA
options in Reply and Advertise messages to the same value. (A new
recommendation to the server) d. makes the server's IA processing of Renew
and Rebind similar to the Request processing (but ORO sounds also make it).
e. Allow the Confirm message work for DHCPv6-PD.

Right?

BV> I am not sure what you are asking here. An instance of an IA is a IA_NA
or IA_PD. IA is short for Identity Association. Note that this just updates
RFC 3315's definition which was address based.

T1. Page 7 - Section 4.4

Could the above text be replaced by the original text in RFC3315? 
'The client MUST include an Option Request option (see section 22.7) to
indicate the options the client is interested in receiving. The client MAY
include options with data values as hints to the server about parameter
values the client would like to have returned.'

BV> ORO are not used for IA_NA/IA_PD/IA_TA. As the client must assign an
IAID so it must send the IA_* option.

T2. Technical - Page 7- Section 4.4
<snip>If the server cannot find a client entry for the IA the server creates
the bindings for that client according to the server's policy and
configuration information and records the IAs and other information
requested by the client. </snip>

BV> Interesting point and the text should probably be revised to allow the
older behavior as servers might not be updated.

<snip> If such verification is needed the requesting router MUST initiate a
Confirm message exchange as described in section 18.1.2, "Creation and
Transmission of Confirm Messages" of RFC 3315.</snip>

BV> There may be a few that could be changed to SHOULD. In general, only the
proposed solution and changes would have these capitalized per RFC 2119. I
think there are only 2 to consider for should -> SHOULD - in 4. and 4.4.  in
proposed solution text. For must -> MUST, 4.6. There are a few grey areas
that may also switch the case ... I think for the discuss text we may want
to lower case. I'll discuss this with Ole and see what we do for a revised
draft. If someone has a strong opinion one way or the other, please let us
know.

Best Regards,
Leaf

-----Original Message-----

Opinions?

- Bernie

-----Original Message-----

- Bud

> when
"binding" and "reply".
point (3).
forward.
>>
>> BV> Yes. Might be best to use (i.e.) too so that it is clear that 
>> BV> this is
just a partial list.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 18 Feb 2013 17:29:05 +0000

An IA is an identity association which consists of the type (NA, TA, PD) and the IAID. IAID value is only unique to IA type. So, a client can well specify IA_NA IAID 1 and IA_PD IAID 1.

Here's the RFC 3315 text:

      Identity association (IA) A collection of addresses assigned to
                                a client.  Each IA has an associated
                                IAID.  A client may have more than one
                                IA assigned to it; for example, one for
                                each of its interfaces.
                                Each IA holds one type of address;
                                for example, an identity association
                                for temporary addresses (IA_TA) holds
                                temporary addresses (see "identity
                                association for temporary addresses").
                                Throughout this document, "IA" is used
                                to refer to an identity association
                                without identifying the type of
                                addresses in the IA.

Here's the draft text to define this to make it more generic:

   Identity association (IA):  A collection of stateful options assigned
                               to a client.  Each IA has an associated
                               IAID.  A client may have more than one IA
                               assigned to it; for example, one for each
                               of its interfaces.  Each IA holds one
                               type of IA option; for example, an
                               identity association for temporary
                               addresses (IA_TA) holds temporary
                               addresses (see "identity association for
                               temporary addresses").  Throughout this
                               document, "IA" is used to refer to an
                               identity association without identifying
                               the type of stateful option in the IA.

I think the text in question (Each IA holds one type of IA option) is supposed to mean IAADDR or IAPREFIX (but it could also have referred to IA_NA, IA_TA, IA_PD)? We don't want to enumerate the types as there could be more defined in the future. (I think Ole wrote this text in the initial version of the draft, so perhaps he can clarify; but it may also have been tweaked along the way.) 

Perhaps to relate this better to the RFC 3315 definition of 'binding' we instead use:

   Identity association (IA):  A collection of stateful options assigned
                               to a client.  Each IA has an IA-type and associated
                               IAID.  A client may have more than one IA
                               assigned to it; for example, one for each
                               of its interfaces.  Each IA holds one
                               type of stateful options; for example, an
                               identity association for temporary
                               addresses (IA_TA) holds temporary
                               addresses (see "identity association for
                               temporary addresses").  Throughout this
                               document, "IA" is used to refer to an
                               identity association without identifying
                               the type of stateful option in the IA.

>Not 100% sure about this point. I can't find the referenced text in RFC3315 yet.

I'm not sure that text is there, but neither is there text to say to add it. (Our server ignores IA_NA, IA_PD, IA_TA in the ORO if it is there because there is EXPLICIT processing for this already in RFC 3315/3633 so there is no need to do anything based on the ORO for these options. Some clients do add it.)

Note that there is no text that the ORO should include the Server-ID option; a server is REQUIRED to add this always.

The requirement for adding options into the ORO is really for those options that have no explicit processing (such as the DNS resolver address). 

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leaf Yeh
Sent: Monday, February 18, 2013 11:58 AM
To: Bernie Volz (volz)
Cc: 'dhc WG'
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03

LY> Does it mean IA_NA and IA-PD will never share the same IA? I guess 
LY> the
better text could be 'Each IA option holds one type, for example,... '
BV> I am not sure what you are asking here. An instance of an IA is a 
BV> IA_NA
or IA_PD. IA is short for Identity Association. Note that this just updates RFC 3315's definition which was address based.

IA(Identity Association) is specified by IAID, which sounds associated with the client's interface. My question is whether a IA-NA and a IA_PD could have the same IAID? If yes, my text might be better.

T1. Page 7 - Section 4.4
<snip>The client also includes an IA option for each binding it desires but has been unable to obtain. </snip>

'The client MUST include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. The client MAY include options with data values as hints to the server about parameter values the client would like to have returned.'

Not 100% sure about this point. I can't find the referenced text in RFC3315 yet.

I meant the original text in RFC3315 might cover the case of the above new suggested text in the new draft.

Best Regards,
Leaf

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Tuesday, February 19, 2013 12:10 AM
To: Leaf Yeh
Cc: 'dhc WG'
Subject: RE: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03

Hi:

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leaf Yeh
Sent: Monday, February 18, 2013 2:33 AM
To: Bernie Volz (volz)
Cc: 'dhc WG'
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03

E1. Editorial - How about change the title of the draft to be 'Updates of RFC 3315 and RFC3633 with multiple stateful options'?

The updates could be summarized as follows:
a. Client should keep a single session with the multiple stateful options (in subsequent messages, Request, Renew, and Rebind, to the server.) b.
Ideally the Status Code option should be encapsulated in the IA option for all DHCP messages. This makes Advertisement messages equal to Reply messages. (A new recommendation to the server though there is a issue for backwards compatibility) c. The server SHOULD set the T1/T2 timers in all IA options in Reply and Advertise messages to the same value. (A new recommendation to the server) d. makes the server's IA processing of Renew and Rebind similar to the Request processing (but ORO sounds also make it).
e. Allow the Confirm message work for DHCPv6-PD.

Right?

Does it mean IA_NA and IA-PD will never share the same IA? I guess the better text could be 'Each IA option holds one type, for example,... '

BV> I am not sure what you are asking here. An instance of an IA is a 
BV> IA_NA
or IA_PD. IA is short for Identity Association. Note that this just updates RFC 3315's definition which was address based.

T1. Page 7 - Section 4.4

<snip>The client also includes an IA option for each binding it desires but has been unable to obtain. </snip>

Could the above text be replaced by the original text in RFC3315? 
'The client MUST include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. The client MAY include options with data values as hints to the server about parameter values the client would like to have returned.'

T2. Technical - Page 7- Section 4.4
<snip>If the server cannot find a client entry for the IA the server creates the bindings for that client according to the server's policy and configuration information and records the IAs and other information requested by the client. </snip>

Not sure the above sounds a necessary behavior of the server. What is the issue if the server doesn't create the bindings for that client when the
server cannot find a client entry for the IA?	

BV> Interesting point and the text should probably be revised to allow 
BV> the
older behavior as servers might not be updated.

<snip>However, it MUST limit the frequency at which is does this to no more often than the renewal frequency. </snip>

<snip> If such verification is needed the requesting router MUST initiate a Confirm message exchange as described in section 18.1.2, "Creation and Transmission of Confirm Messages" of RFC 3315.</snip>

The above text sounds '...MUST initiate a Confirm/Reply message exchange...'.

BV> There may be a few that could be changed to SHOULD. In general, only 
BV> the
proposed solution and changes would have these capitalized per RFC 2119. I think there are only 2 to consider for should -> SHOULD - in 4. and 4.4.  in proposed solution text. For must -> MUST, 4.6. There are a few grey areas that may also switch the case ... I think for the discuss text we may want to lower case. I'll discuss this with Ole and see what we do for a revised draft. If someone has a strong opinion one way or the other, please let us know.

Best Regards,
Leaf

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

>The original text says to return an IA_* with no addr/prefix and a 
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.

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.) 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?

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

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

- Bud

> Regarding 4.5, ok one of those edits can be done in a -04 (after 28th 
WGLC ends). Usually the RFC-Editor also catches things like this, but best to give them a better document to start with.
"binding" and "reply".
point (3).
forward.
just a partial list.
>> 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.

---

From: "Leaf Yeh" <[email-masked]>
Date: Wed, 20 Feb 2013 00:08:07 +0800

BV> Identity association (IA):  A collection of stateful options assigned
                               to a client.  Each IA has an IA-type and
associated

The above new text sounds not the best yet. :-)

Per the above text, IA is a 'A collection of stateful options (eg. IA_xx)
assigned to a client.', which sounds "Each 'IA_xx' holds one type of
stateful options." Right?

BV> Our server ignores IA_NA, IA_PD, IA_TA in the ORO.

Got it.

Best Regards,
Leaf

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Tuesday, February 19, 2013 1:29 AM
To: Leaf Yeh
Cc: 'dhc WG'
Subject: RE: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03

An IA is an identity association which consists of the type (NA, TA, PD) and
the IAID. IAID value is only unique to IA type. So, a client can well
specify IA_NA IAID 1 and IA_PD IAID 1.

I think the text in question (Each IA holds one type of IA option) is
supposed to mean IAADDR or IAPREFIX (but it could also have referred to
IA_NA, IA_TA, IA_PD)? We don't want to enumerate the types as there could be
more defined in the future. (I think Ole wrote this text in the initial
version of the draft, so perhaps he can clarify; but it may also have been
tweaked along the way.) 

Perhaps to relate this better to the RFC 3315 definition of 'binding' we
instead use:

                               to a client.  Each IA has an IA-type and
associated

yet.

I'm not sure that text is there, but neither is there text to say to add it.
(Our server ignores IA_NA, IA_PD, IA_TA in the ORO if it is there because
there is EXPLICIT processing for this already in RFC 3315/3633 so there is
no need to do anything based on the ORO for these options. Some clients do
add it.)

Note that there is no text that the ORO should include the Server-ID option;
a server is REQUIRED to add this always.

The requirement for adding options into the ORO is really for those options
that have no explicit processing (such as the DNS resolver address). 

- Bernie

-----Original Message-----

T1. Page 7 - Section 4.4

Best Regards,
Leaf

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Tuesday, February 19, 2013 12:10 AM
To: Leaf Yeh
Cc: 'dhc WG'
Subject: RE: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03

Hi:

- Bernie

-----Original Message-----

Right?

T1. Page 7 - Section 4.4

Best Regards,
Leaf

-----Original Message-----

Opinions?

- Bernie

-----Original Message-----

- Bud

"binding" and "reply".
point (3).
forward.
just a partial list.

---

From: "Leaf Yeh" <[email-masked]>
Date: Wed, 20 Feb 2013 09:40:00 +0800

BV> I think we should make Renew and Rebind the same here 

Agreed. 

BV> If NoBinding, return to Solicit.

I guess this 'Nobinding' sounds in the "global" scope of the message.

BV> If NoAddrsAvail/NoPrefixAvail, continue to Renew/Rebind with the
existing leases (at T1/T2 times). If no leases, return to Solicit.

I guess the above 'lease' is associated with the IA, 'A collection of
stateful options(IA_xx) assigned to a client('s interface)'. Right?

Best Regards,
Leaf

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Tuesday, February 19, 2013 12:28 AM
To: Leaf Yeh
Cc: [email-masked]
Subject: RE: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03

Hi again:

The REBIND case is an interesting one and while #2 and #3 are probably close
to the same result in terms of the client's behavior, I wonder what existing
servers do -- I would guess that they are more likely to return #3 (matching
Renew) if they aren't willing to 'create' the binding?

The subtle difference between #2 and #3 may be:
- #2 means that the server would be willing to assign the binding a lease if
it had a lease to give.
- #3 means that the server would not be willing to assign the binding a
lease because it has no record of the binding and would not create one.

For #2, the message is clear that the client can continue to try. Whereas
for #3, it may be that the client needs to return to Solicit if it ever
hopes to get the binding.

I think that may be the key to this ... NoBinding means that the server will
not assign a new binding except via Solicit/... whereas
NoAddrsAvail/NoPrefixAvail means that the server has nothing to give the
client but would otherwise accept the binding.

I think we should make Renew and Rebind the same here (i.e. return #2 and #3
depending on the situation). What the client does with this information is
likely:
- If NoBinding, return to Solicit.
- If NoAddrsAvail/NoPrefixAvail, continue to Renew/Rebind with the existing
leases (at T1/T2 times). If no leases, return to Solicit.

- Bernie

-----Original Message-----

Request logic.
unknown bindings.

Best Regards,
Leaf

-----Original Message-----

Request logic.
unknown bindings.
proposing to change.

- Bud

the IA_*.
"binding" and "reply".
point (3).
forward.
>>> BV> this
is just a partial list.

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 22 Feb 2013 17:46:39 +0100

On 22.01.2013 00:24, Bernie Volz (volz) wrote:
>> 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.
Agree. Include IA_* with status code (#2 or #3, depending on the
situation) in it is my preference as well. Ideally we should do that for
every response server generates, regardless of the message type that
triggered it (solicit, request, renew, rebind, but also decline and
confirm).

A question about NoAddrsAvail status. The typical meaning is obvious (we
run out of addresses), but some implementations (e.g. dibbler) allows
you to specify that each client can get up to specified maximum number
of addresses. If you configure that to two, and client sends three
IA_NAs, two of them will be assigned and the third one will get
NoAddrsAvail status (within 3rd IA_NA). Is this allowed behavior within
the proposed text?

The text should clarify that while there are currently 3 IA types
defined (IA_NA, IA_TA, IA_PD), there may be more defined in the future
and the same approach will apply to them. I'm not sure how likely new IA
types are, but there's one DHC draft that defines IA_PA and it seems to
be alive (draft-ietf-dhc-host-gen-id-04).

Another aspect I'd like this draft to clarify is whether REPLY sent as a
response to REQUEST must include exactly the addresses/prefixes sent in
REQUEST. Currently strict interpretation of the 18.2.1 section of
RFC3315 (6th paragraph) says that is must reject it:

   If the server cannot assign any addresses to an IA in the message
   from the client, the server MUST include the IA in the Reply message
   with no addresses in the IA and a Status Code option in the IA
   containing status code NoAddrsAvail.

We should update that text to allow other addresses being assigned if
that specified address/prefix is no longer available. Here's a rationale
for it. Currently when server sends Advertise, it should keep the
addresses and prefixes in a not well defined state. They are not leased
yet (there's specific text that forbids forming lease at that time), but
they are reserved for a short time with the expectation that the client
will send Request shortly. This short-term reservation is annoying and
unnecessary. It would be much simpler if the server sends address X in
Advertise, but when the client sends Request with X in it, server sends
Reply with address Y instead. ("sorry, someone else got X, here's Y for
you"). There's a specific scenario, where this is very helpful. Imagine
a case where large network recovers after blackout and you have
thousands of clients trying to get addresses. Server will respond faster
if it only needs to complete address/prefix selection and send the
advertise (without needing to update its database to mark the address as
temporary reserved).

Also, some comments about specific sections of the text:

Section 4.2
It would be better to says failure status codes (i.e. other than
Success), rather than enumerate them explicitly.

As said above, I very much prefer to include status codes in IA. I think
the argument about status codes in global scope in somewhat dubious. Old
clients that will not find status code in global scope will try to get
an address from IA and find out that it is not there.

Anyway, if you care about backward compability, I propose to add the
following text: Server MUST include status code in each IA and MAY
include in global scope.

Imagine a case, where client requests IA_NA, IA_TA and IA_PD. Server
assigns only non-temporary (NA) address, but no temporary or prefix.
What would the global status be: Success, NoAddrsAvail or NoPrefixAvail?
There's no valid answer to that question.

Section 4.5
Since this proposal extends CONFIRM to cover IA_PD as well, it would be
useful to have the capability to say: this address is valid here, but
that prefix is not. For the we need the capability to provide per IA
response. I would like to have section 18.2.2 of RFC3315 updated.

We can add the same text as proposed in section 4.2 (MUST include status
in IA, MAY include in global scope). I think this approach would be
backwards compatible - old clients would just ignore received extra IA
options in CONFIRM.

Section 4.6
How would the "client get back a lease" work? This is all happening on
the server side, right? The server remembers that the client used
address X last time and since it is free when client tries to renew it,
server may as well assign it again. That's my interpretation and I hope
you meant that. The other interpretation would be "the client can use
its address past its expiration time, just needs to send RENEW". We
should reword this section to make it clear that this is not the case.
I think rewording it as "A client can attempt to get back a lease by
using RENEW message, but must adhere to server's response". This is
basic common sense for anyone dealing with DHCP, but I've heard scary
ideas on more than one occasion, so it's better to be very clear.

I would very much prefer that client that released address or prefix
used Request rather than Renew. I don't like the idea, but since Renew
and Request will be almost identical, I can live with it.

I strongly support this work going forward (with or without my comments).

Tomek

p.s.
A request for Bernie and Ole: Once you guys are done with this draft,
please don't throw away your notes and comments that you chose to not
include. They'll be useful once we decide to start rfc3315bis work.

> 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.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.
> 
> 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. 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
>> 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
>> 
>> 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.
>> 
>> 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.
>> 
>>> 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:
>>> 
>>> 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
>>> 
>>> 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"
>>> 
>>> BV> Yes.
>>> 
>>> 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.
>>> 
>>> this is just a partial list.
>>> 
>>> 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>
>>> 
>>> 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.
>>> 
>>> Thanks, Gaurav -----Original Message----- From:
>>> [email-masked] [mailto:[email-masked]] On Behalf
>>> Of Ted Lemon Sent: Tuesday, January 15, 2013 1:04 AM To: dhc WG 
>>> 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
>>> _______________________________________________ dhcwg mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg 
>>> _______________________________________________ dhcwg mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg 
>>> _______________________________________________ dhcwg mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>> _______________________________________________ dhcwg mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg 
>> _______________________________________________ dhcwg mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________ dhcwg mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg 
> _______________________________________________ dhcwg mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 22 Feb 2013 17:49:38 +0100

> We will evaluate consensus after January 28.   Thanks!
Oh, I forgot one minor comment.

The draft should clarify that IAID values are distinct number spaces for
each IA type, so IA_NA and IA_PD may both have iaid=1 and they are
definitely different. That is a common understanding, but there are
questions about that occasionally, so it would be nice to have a clear
text to point to.

Tomek