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