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

[Ole Troan <[e-mail]>]

Jinmei-san,

thanks for your comments! answers inline.

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

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.

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

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.

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

yes, well spotted.

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

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

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

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

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