>>>>> On Mon, 24 Feb 2003 08:00:00 -0500,
>>>>> Ralph Droms <[EMAIL PROTECTED]> said:
> 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.
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
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
