Subject: Re: [dhcwg] Gen-ART LC review of draft-ietf-dhc-dhcpv6-stateful-issues-11

From: "Roni Even" <[email-masked]>
Date: Sun, 1 Mar 2015 08:11:08 +0200

Bernie thanks,
Inline
Roni

> -----Original Message-----
> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: 01 March, 2015 1:03 AM
> To: Ted Lemon; [email-masked]
> Cc: Roni Even; Jari Arkko
> Subject: RE: [dhcwg] Gen-ART LC review of draft-ietf-dhc-dhcpv6-stateful-
> issues-11
> 
> Ted, et al:
> 
> > 	* The document defines the terms "Identity association (IA)" and "IA
> option types" different from RFC3315 yet in the document sometimes this
> terms are as specified in RFC3315 including the IA_TA option. An example
is for
> section with text changes.
> 
> I don't believe RFC 3315 has "IA option types".

[Roni Even] For example the following text from section 4.4.1 "In multiple
IA option type model, the client may include multiple IA
   options in the Request message, and the server may create bindings   only
for a subset of the IA options included by the client." Does this talk only
about IA_NA and IA_PD.  My reading of section 18.1.1 of RFC3315 " The client
uses a Request message to populate IAs with addresses and
   obtain other configuration information.  The client includes one or  more
IA options in the Request message." Is that IA options and IA option types
have the same meaning, so in this case it includes IA_TA

> 
> The problem with the RFC 3315 definition of "Identity association (IA)" is
that it
> is just for addresses. And, prior to the 08 version (Oct 2014), we had
extended
> the definition to include prefix delegation, but in the 08 draft (I
believe
> primarily based on comments from Jinmei) we restricted it to IA_NA and
IA_PD
> because that is primarily what this document deals with. We left out IA_TA
> because as stated in the Introduction, IA_TAs are really a bit different
as they
> generally have their own lifecycle (and thus are less likely to be
obtained
> together - except perhaps initially). Also, while it is possible that
Customer Edge
> Routers use temporary addresses, it is less likely that they generally
would as
> they aren't as likely to "move" around the Internet (to various access
points)
> and even if they did, they generally wouldn't be used for web browsing and
the
> like that might require temporary addresses.
> 
> In looking at the usage of "IA" (as opposed to "IA_xx" or "IA option
types"), I
> really don't see any harm if we went with something that covered IA_TA as
well
> (in fact a few of the uses of "IA" imply this). So:
> 
>    Identity association (IA):      Throughout this document, "IA" is
>                                    used to refer to the Identity
>                                    Association containing addresses or
>                                    prefixes assigned to a client and
>                                    carried in the IA_NA, IA_TA, or IA_PD
>                                    options.
> 
> Again, even this is different from RFC 3315 since RFC 3315 did not include
> prefix delegation or IA_PD.
> 
> > 	* For clarification: Is this document going to be obsolete by draft-
> dhcwg-dhc-rfc3315bis, there are some sections that include changes to
> RFC3315 and RFC3633 and my reading is that this changes will be
incorporated
> un the rfc3315bis draft. I am not sure about sections that provides
clarifications
> and do not propose text changes.
> 
> Yes, the intent is for this to be incorporated into
draft-dhcwg-dhc-rfc3315bis,
> but that document is still a work in progress and will take a while before
it is
> "done", and we'd rather get these changes into the DHCPv6 standard well
> before then. We have not yet done these changes to draft-dhcwg-dhc-
> rfc3315bis as we are awaiting them to be approved before assuming we can
> make those changes (draft-dhcwg-dhc-rfc3315bis is a revised standards
> document and we are not trying to introduce new or different capabilities
in
> that document).
> 
> - Bernie
> 
> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]]
> Sent: Saturday, February 28, 2015 8:40 AM
> To: [email-masked]
> Cc: Roni Even; Jari Arkko
> Subject: Re: [dhcwg] Gen-ART LC review of draft-ietf-dhc-dhcpv6-stateful-
> issues-11
> 
> On Feb 28, 2015, at 6:53 AM, Roni Even <[email-masked]> wrote:
> >
> > 	* The document defines the terms "Identity association (IA)" and "IA
> option types" different from RFC3315 yet in the document sometimes this
> terms are as specified in RFC3315 including the IA_TA option. An example
is for
> section with text changes.
> 
> Authors, can you look into this and see if there's a way to fix it?
> 
> > 	* For clarification: Is this document going to be obsolete by draft-
> dhcwg-dhc-rfc3315bis, there are some sections that include changes to
> RFC3315 and RFC3633 and my reading is that this changes will be
incorporated
> un the rfc3315bis draft. I am not sure about sections that provides
clarifications
> and do not propose text changes.
> 
> I think this is an action item to carry forward to 3315bis.   We have at
least
> been attempting to do this, but a final pass through this document before
> submitting 3315bis for publication should be one of the action items for
that
> document.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 12 Mar 2015 12:03:26 +0200

Many thanks for your review, Roni.

Jari