[dhcwg] Re: comments on draft-yan-dhc-dhcpv6-opt-dnszone-02.txt

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

>>>>> On Thu, 10 Mar 2005 09:46:45 +0800, 
>>>>> "CTO YAN Renxiang" <[e-mail]> said:

>> My first question is whether it's typical for the "subscriber" to use
>> the ISP's (sub) domain (suffix) for its internal host names.  This
>> would make it hard to change providers (they'd rename host names as
>> well as renumber addresses), so don't they rather want to use an
>> independent domain space?  Perhaps I'm just unfamiliar with this area,
>> so this is not an objection to the proposal; rather it's just a
>> question.

> This option just provides a method to transfer the domain suffix from DHCPv6 server
> to DHCPv6 client. The word "provider" is used as an example to illustrate the 
> applicability, you certainly can use an independent domain space, but typically, to reduce
> management cost, the allocation of this indenpendent domain space is performed 
> by the network service provider. 

Thanks for the explanation, but this does not really address my
concern.  What I wanted to see is an explanation on how this is
realistic in the actual operational usage, rather than "this could
work in theory this way".  As you seemed to indicate, providing an
independent name space from the upstream ISP does not seem feasible to
me.

>> I also understand most of Section 2.1:

(Oops, sorry, I actually meant "I also don't understand" here, BTW)

>> Also, I cannot be sure how an end host using stateless address
>> autoconfiguration can update its host name using this mechanism (e.g.,
>> how can the node know the appropriate "suffix"?).  I hope this draft
>> will provide a bit more details on this.

> This document does not address this issue, the host's address can be configured
> using DHCPv6 or stateless autoconfiguration. The FQDN option provide a method 
> to update domain name for the host configured using DHCPv6. The domain name 
> update mechnism for the node whose address is configured using stateless 
> autoconfiguration remains an ongoing issue, you can refer to another draft in:
> http://www.ietf.org/internet-drafts/draft-yan-ipv6-ra-dns-00.txt

??? I'm now totally confused...According to this explanation,

- for a host using DHCPv6 for address configuration, we use the FQDN
  option.
- a host using stateless address autoconfiguration is not in the scope
  of the zone suffix option.

then why do we need the new option in the first place?

Please be more specific on the expected usage.

>> In stateful DHCPv6, the zone suffix option MUST only appear in 
>> IA_PD-options field of IA_PD option (see [3]) and apply to all 
>> prefixes for that binding.  One IA_PD-options field MUST 
>> include none
>> or only one zone suffix option.
>> 
>> What does "stateful DHCPv6" mean in this context?  Does this specify
>> address allocation (at end nodes) by DHCPv6?  Or does this mean prefix
>> delegation?

> It means "prefix delegation" using DHCPv6. Such kind of usage has been discussed
> in the DHC mailing list before.

> The term "Stateful DHCPv6" is compared with "stateless DHCPv6", they are 
> specified respectively in RFC3315 and RFC3736.

Of course I know those wording and RFCs.  But in my understanding,
stateful / stateless are typically used in the context of address
configuration.  In the context of prefix delegation, there's no
"stateless" counterpart.  That's why I was confused.

But I'm afraid it doesn't make sense to continue disucssing the
wording issue unless the expected usage is clarified (see above).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[e-mail]

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