>>>>> On Fri, 28 Feb 2003 00:46:37 +0000,
>>>>> Ole Troan <[EMAIL PROTECTED]> said:
>> 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.
I don't think it's enough. For example, Section 8 of
prefix-delegation-02 is almost the exact copy of Section 22.4 of
dhcpv6-28, with s/IA_NA/IA_PD/g and s/address/prefix/g.
Since Section 2 of dhcpv6-interop-00 proposes to "add" paragraphs to
Section 22.4 of dhcpv6-28, corresponding paragraphs should be added to
Section 8 of prefix-delegation.
I've not gone thorough the entire issues of the interop draft, but I'm
quite sure that there still exist similar cases. (If you are not
convinced, I'll try to make a complete list.)
>> 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.
I know (and agree), but I'm saying the PD specification should be
clear wherever a difference between address assignment and prefix
delegation exist. We should be rather redundant than leave the
difference ambiguous. At least please reconsider each issue in the
interop draft and merge necessary changes from it.
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]
--------------------------------------------------------------------
