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

"CTO YAN Renxiang" <Renxiang.Yan@alcatel-sbell.com.cn> Thu, 10 March 2005 01:50 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14876 for <dhcwg-web-archive@ietf.org>; Wed, 9 Mar 2005 20:50:07 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9CrB-0000MU-8W for dhcwg-web-archive@ietf.org; Wed, 09 Mar 2005 20:52:57 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Clg-0007fh-Va; Wed, 09 Mar 2005 20:47:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Clf-0007fc-9w for dhcwg@megatron.ietf.org; Wed, 09 Mar 2005 20:47:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14632 for <dhcwg@ietf.org>; Wed, 9 Mar 2005 20:47:09 -0500 (EST)
Received: from nat1.alcatel-sbell.com.cn ([202.96.203.177] helo=mail.alcatel-sbell.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9CoI-0000I2-9U for dhcwg@ietf.org; Wed, 09 Mar 2005 20:49:59 -0500
Received: from bellnet-mail4.sbell.com.cn (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.12.11/8.12.11/Alcanet1.0) with ESMTP id j2A1jkK4025702; Thu, 10 Mar 2005 09:45:46 +0800
Received: from asbmail2.sbell.com.cn ([172.24.208.62]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Thu, 10 Mar 2005 09:46:45 +0800
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Date: Thu, 10 Mar 2005 09:46:45 +0800
Message-ID: <9570C1261494D54D9D3115BC2C83429A0BB6BA@asbmail2.sbell.com.cn>
Thread-Topic: comments on draft-yan-dhc-dhcpv6-opt-dnszone-02.txt
Thread-Index: AcUlBrM2C8cdd3DqR7aRXYbjVOa6aAABHtZA
From: CTO YAN Renxiang <Renxiang.Yan@alcatel-sbell.com.cn>
To: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>
X-OriginalArrivalTime: 10 Mar 2005 01:46:45.0619 (UTC) FILETIME=[04456430:01C52513]
X-imss-version: 2.012
X-imss-result: Passed
X-imss-approveListMatch: *@alcatel-sbell.com.cn
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.org, CTO Jiang YingLan <YingLan.Jiang@alcatel-sbell.com.cn>
Subject: [dhcwg] re: comments on draft-yan-dhc-dhcpv6-opt-dnszone-02.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Content-Transfer-Encoding: 7bit

> Hello,
> 
> I've read the draft, but I simply cannot be sure whether I can support
> this document as a wg item.
> 
> 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. 

> 
> 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 also understand most of Section 2.1:
> 
>    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.

> 
> Similarly,
> 
>    In stateless DHCPv6, the zone suffix option can appear in the 
>    client's message options field in the transaction.
> 
> I'm not sure what "stateless DHCPv6" specifies here.  I also don't
> understand what are "the client's message options".
>

It means it will be used as an options field in the message sent by server to client.
Comparing with the usage in stateful DHCPv6, it doesn't need to be placed in the options
field (suboption) of other options.

> 
> Here are miscellaneous editorial comments I happen to notice:
> 
The typo errors will be corrected in ver03. Thank you.

> - In abstract
> 
>    This document specifies a new DHCPv6 (DHCP for IPv6) 
> option which is 
>    passed from an DHCPv6 server to an DHCPv6 client to specify the 
>    zone suffix name used to construct and perform domain name update.
> 
>    => s/an DHCPv6/a DHCPv6/
> 
> - I cannot parse the second paragraph of Section 3.0:
> 
>    The zone suffix name can then be used to construct can 
> update domain
>    name for the hosts in subscriber network, by an embedded DHCPv6
>    server in CPE or by other means of DNS update mechanism 
> for stateless
>    IPv6 configuration.
> 
>  I suspect there's a grammatical error here.
> 
> - In the last paragraph of Section 3.0,
> 
>    [...]
>    in which an unique zone suffix name prefix, called "home name", are
>    negotiated between user and ISP when subscribing. For example, 
>    "user1.example.com" and "user2.example.com". 
> 
>   => s/are negotiated/is negotiated/
>   => s/an unique/a unique/
> 
> 					JINMEI, Tatuya
> 					Communication Platform Lab.
> 					Corporate R&D Center, 
> Toshiba Corp.
> 					jinmei@isl.rdc.toshiba.co.jp
> 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg