Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt

From: Ralph Droms <[email-masked]>
Date: Mon, 24 Feb 2003 08:00:00 -0500

Reminder and note: there has been not response to this WG last 
call.  Please review draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt and 
reply with comments.  If you recommend the document for advancement without 
revision, please respond with a quick acknowledgment.  No response will be 
interpreted as a lack of support for advancing the document.

-----

This message announces a WG last call on "IPv6 Prefix Options for DHCPv6" 
<draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt>.  The last call will 
conclude on Friday, 2/28.

Note that this is a parallel WG last call in the dhc and ipv6 WGs.

draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt describes new DHCPv6 
options and a mechanism through which a "delegating router" (e.g., an ISP 
aggregation device) can assign and delegate one or more prefixes to a 
"requesting router" (e.g., CPE).  This draft is available as 
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt

- Ralph Droms 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Mon, 24 Feb 2003 08:51:01 -0500

Please ignore the first sentence of this reminder - it was queued for 
transmission before the round of discussion that began at the end of last 
week...

- Ralph

At 08:00 AM 2/24/2003 -0500, Ralph Droms wrote:
>call.  Please review draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt 
>and reply with comments.  If you recommend the document for advancement 
>without revision, please respond with a quick acknowledgment.  No response 
>will be interpreted as a lack of support for advancing the document.
>
>-----
>
>--------------------------------------------------------------------
>IETF IPng Working Group Mailing List
>IPng Home Page:                      http://playground.sun.com/ipng
>FTP archive:                      ftp://playground.sun.com/pub/ipng
>Direct all administrative requests to [email-masked]
>--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 25 Feb 2003 02:40:10 +0900

>>>>> On Mon, 24 Feb 2003 08:51:01 -0500, 
>>>>> Ralph Droms <[email-masked]> said:

>> will be interpreted as a lack of support for advancing the document.

I basically support the idea of the draft, but I have several issues
to be discussed before advancing it.  I'll re-read the latest revision
and send a list of issues in a few days.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 26 Feb 2003 16:55:12 +0900

>>>>> On Mon, 24 Feb 2003 08:00:00 -0500, 

> Please review draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt and 

I've finally reviewed the latest draft.  As I said before, I basically
support the document.  However, I don't think the current revision is
ready to be published.  IMO, it is still incomplete and has not fully
addressed open issues.

Detailed comments follow:

1. Issues about the preferred and valid lifetimes were not fully
   addressed.  I've not seen consensus on this in the dhc-wg ML.
   Please re-check the thread entitled "PD lifetimes" that started on
   Thu, 23 Jan 2003 19:18:57 +0900.

2. Section 11.1 now specifies the requesting router to use
   Rebind/Reply exchanges to verify an existing binding (instead of
   Renew/Reply exchanges).  According to the very recent
   clarifications on the base DHCPv6 spec, however, I'm not sure if
   Rebind is appropriate here; the server should drop the Rebind
   message unless it has an explicit knowledge about the validity or
   invalidity of the prefix, which should not be the case (e.g.) when
   the upstream link flaps.

3. Section 10.2 contains the following sentence (newly added in the
   latest revision):

     If the delegating router cannot delegate any prefixes to an IA_PD in
     the message from the requesting router, the delegating router MUST
     include the IA_PD in the Reply message with no prefixes in the IA_PD
     and a Status Code option in the IA_PD containing status code
     NoPrefixAvail.

   I guess the "Reply" should be "Advertisement" here, because this
   section is talking about "Delegating Router Solicitation."  I also
   guess the sentence was added in response to a question of mine in
   the ML.  If so, a similar clarification should be introduced to
   Section 11.2 as well.  Additionally, the corresponding client
   behaviors should also be documented.

4. The PD draft should reflect some parts of
   draft-ietf-dhc-dhcpv6-interop-00.txt.  With a quick look, Sections
   1, 2, 3, 4, 5, 6, 9, 10, and 11 should also apply to the PD draft.
   We may be able to omit some of them as trivial clarifications, but
   we should reflect some other part of them because the base DHCPv6
   spec (and thus the clarifications for it) is too specific to
   address assignment.  In some cases, implementors can use analogy of
   the base spec to implement the PD draft, but we should basically
   provide comprehensive information in the PD draft itself to ensure
   better interoperability.  (As some people, including me, have
   repeatedly pointed out, the best approach would be to make the base
   spec generic so that each stateful method can just refer to the
   base spec.  Since we could not make it due to the "it's too late"
   reason, we should be responsible to implementors for providing
   detailed information within the PD specification).

					JINMEI, Tatuya

---

From: Ole Troan <[email-masked]>
Date: Fri, 28 Feb 2003 00:46:37 +0000

Jinmei-san,

thanks for your comments! answers inline.

>    Thu, 23 Jan 2003 19:18:57 +0900.

what specifically are you referring to here? in my opinion we reached
consensus that:

 - both preferred and valid lifetimes are needed
 - prefixes or addresses derived from the prefix MUST not be used
   beyond the valid lifetime
 - adding P and V bits to specify if a prefix advertised in an RA
   should use a fixed lifetime or a real time lifetime, is not needed
   as it does not seem to add value or solve any specific problem.

>    invalidity of the prefix, which should not be the case (e.g.) when

Rebind now behaves just like Confirm. if by link flap you mean change
of link to another delegating router, the delegating router can reply
to a Rebind even without a binding if it knows through explicit
configuration that the prefixes in the IA_PD is not valid for the link.

>    behaviors should also be documented.

yes, well spotted.

>    1, 2, 3, 4, 5, 6, 9, 10, and 11 should also apply to the PD draft.

I have made the changes where appropriate, i.e where we already have
cut and pasted text from the DHCPv6 base specification.

>    detailed information within the PD specification).

the PD specification is not meant to be complete and needs to be read
in conjunction with the base DHCP specification.

/ot