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

From: "Roni Even" <[email-masked]>
Date: Sat, 28 Feb 2015 13:53:29 +0200

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you
may receive.

Document:  draft-ietf-dhc-dhcpv6-stateful-issues-11

Reviewer: Roni Even

Review Date:2015-2-28

IETF LC End Date: 2015-3-4

IESG Telechat date: 

Summary: This draft is ready for publication as an Standard Track  RFC.

Major issues:

Minor issues:

Nits/editorial comments:

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

---

From: Ted Lemon <[email-masked]>
Date: Sat, 28 Feb 2015 08:40:10 -0500

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: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 28 Feb 2015 23:02:35 +0000

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

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.

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