Subject: Re: [Dhcpv6bis] [dhcpv6bis] #14 (XML 3315): Fred Templin's review of RFC 3315 (28 points!)

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Wed, 21 Jan 2015 09:01:32 -0000

#14: Fred Templin's review of RFC 3315 (28 points!)

Comment (by [email-masked]):

 Issue 22 - RESOLVED - reworded the sentence to be "The Options fields of
 the IA_NA or IA_TA option are specific to this address."

 Issue 23 - NOT ACCEPTED - a reasonable deployment is NOT use both SLAAC
 and DHCP to manage the SAME address space. However, if it happened so, the
 lifetime from ND should have priority. It is out of scope for DHCP
 document. Leaving text as is.

 Issue 24 - NOT ACCEPTED - "relay agent options" represents any options
 that may added by relay agents. It is an understandable terms now. There
 are many of them.

 Issue 25 - RESOLVED - added some recommendation text for releasing unused
 text.

 Issue 26 - RESOLVED - obsoleted references have been checked. RFC Editors
 would check it again when this bis document gets published.

 Issue 27 - NOT ACCEPTED - there is no ways for the server to detect the
 new client until the client sends a confirm message, which must be after
 the client has decided it moves into a new link. DHCP protocol is a
 protocol based on client initiation. After received the confirm message,
 the server can use NotOnLink to tell the client that its previous
 address/prefix are no longer valid, see section 18.2.2. Leaving text as
 is.

 Issue 28 - RESOLVED - it would be combined to solve with Issue #73.

-- 
------------------------------+--------------------------------------------
 Reporter:  [email-masked]    |       Owner:  [email-masked]
     Type:  editorial-change  |      Status:  new
 Priority:  P4 minor          |   Milestone:  B moderate, apply after merge
Component:  XML 3315          |  Resolution:
 Keywords:                    |    Due Date:
------------------------------+--------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/14#comment:7>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Thu, 22 Jan 2015 03:52:09 -0000

Issue 11 - RESOLVED - Rewritten to be "the prefixes/addresses assigned to
 the interfaces on that link" because both prefix and address become valid
 after we combine prefix delegation into this DHCP base document.

 Issue 12- RESOLVED - It is possible a solicit message may include a IA_*A
 and IA Address as hit. It is confirmed from in the section 17.2.2 "If the
 client has included addresses in the IAs in the Solicit message".

 Issue 13 - NOT ACCEPTED - Leaving text as is. Also this text may not be
 very useful, it should not be harmful either.

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/14#comment:8>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Fri, 23 Jan 2015 06:22:55 -0000

Issue 15 - NOT ACCEPTED - Leaving text as is. There are more than 40
 instance of such usage. It is well understood and would not cause any
 misunderstanding.

 Issue 16 - RESOLVED - replaced several "site-local" with "site-scoped".

 Issue 17 - NOT ACCEPTED - Leaving text as is. This section describes the
 relay-rely messages, both relay-reply messages that contain Reconfigure
 messages and other relay-reply messages are created by server. The relay-
 reply messages that contain Reconfigure messages are a subset of relay-
 reply messages.

 Issue 18 - RESOLVED – Remove the availability content regarding to IPSec
 implementation in DHCPv6, in section 22.1 "Security of Messages Sent
 Between Servers and Relay Agents". The IPSec support in IPv6 has become
 optional since RFC 6434. So the availability for IPSec is not clear now.

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/14#comment:9>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Wed, 28 Jan 2015 08:19:07 -0000

Issue 19 - RESOLVED - Added text to clarify the delayed auth. protocol
 cannot work with 2-message exchange. This protocol uses Solicit/Advertise
 exchange as key and server selection process. So, real DHCPv6 procedures
 can only be made in the follow-up messages.

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/14#comment:10>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Fri, 30 Jan 2015 07:09:29 -0000

Issue 14 -  NOT ACCEPTED - Leaving text as is. The second paragraph of
 section 18.2.4 does explain the follow up behaviors in the failure cases.

 Issue 21 – RESOLVED – add the same text to section 22.4. This
 consideration is also validated to IA_TA.

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/14#comment:11>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>