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

["Leaf Yeh" <[e-mail]>]

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


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:[e-mail]] 
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.

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.


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

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: [e-mail] [mailto:[e-mail]] 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

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

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>

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:[e-mail]]
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:

Thanks for the thorough review.

Some comments below (BV>).

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 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'?

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> Yes, except for D and ORO. (See below.)


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,... '

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

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>

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.


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

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

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

BV> Yes. To we should add /Reply.

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

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: [e-mail] [mailto:[e-mail]] 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: [e-mail] [mailto:[e-mail]] 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
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 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.
>
> 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)
<[e-mail]> wrote:
>> 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:
>>
>> 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: [e-mail] [mailto:[e-mail]] 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 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 
>> BV> 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
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] 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) <[e-mail]> 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.
>>
>> We will evaluate consensus after January 28.   Thanks!
>>
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg

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

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