Re: [dhcwg] additional option for dhcpv6
Vijay Bhaskar A K <vijayak@india.hp.com> Sun, 20 January 2002 14:36 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10927 for <dhcwg-archive@odin.ietf.org>; Sun, 20 Jan 2002 09:36:01 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA18022 for dhcwg-archive@odin.ietf.org; Sun, 20 Jan 2002 09:36:06 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17965; Sun, 20 Jan 2002 09:30:47 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17936 for <dhcwg@optimus.ietf.org>; Sun, 20 Jan 2002 09:30:46 -0500 (EST)
Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10868 for <dhcwg@ietf.org>; Sun, 20 Jan 2002 09:30:38 -0500 (EST)
Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by palrel12.hp.com (Postfix) with ESMTP id 6D112E00CAD; Sun, 20 Jan 2002 06:30:06 -0800 (PST)
Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id UAA22474; Sun, 20 Jan 2002 20:04:24 +0530 (IST)
From: Vijay Bhaskar A K <vijayak@india.hp.com>
Message-Id: <200201201434.UAA22474@dce.india.hp.com>
Subject: Re: [dhcwg] additional option for dhcpv6
To: mjs@cisco.com
Date: Sun, 20 Jan 2002 20:04:24 +0530
Cc: vijayak@india.hp.com, dhcwg@ietf.org
In-Reply-To: <4.3.2.7.2.20020118165044.019a0ef0@goblet.cisco.com> from Mark Stapp at Jan "18, " 2002 "05:07:29" pm
X-Mailer: ELM [$Revision: 1.17.214.2 $]
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
Content-Transfer-Encoding: 7bit
Mark, Thanks for your thorough review. See my comments inline. ~ Vijay > 1) The FQDN option needs, I think, to look a lot like the FQDN option for > dhcpv4. The option i defined here is, for just transfering the FQDN releated to temporary address. It is similar to hostname option in DHCPv4. I will rename it to hostname option. I feel like, since the DDNS updates are still TBD, we can define the FQDN option with appropriate fields needed later, once DDNS specs are finalised. > The name encoding must be specified. Yes. It is needed. I will add the appropriate text. > There needs to be > specification about hosts who do not initially know their entire fqdn. > There needs to be a way to communicate about which party (if any) will be > updating DNS. It's probably on my plate to produce that, actually. For the temporary addresses, DNS update is done by server. So, these fields are not necessary. > > 2) The subnet-selection option text should not compel the server to somehow > obey the client's suggestion. It should be explict that the server > administrator's configuration takes precedence, and that the client's > indication that it desires a specific subnet can only be a hint that's > considered along with all of the other information available to the server. This is the only way the client can tell its prefernce for the prefix. If the server is not supposed to allocate address for that prefix, then it wont. If the client is not very particular about the prefix, it should not use this option. This option will be more helpful in the network with two prefixes and the client wants a particular one. > > A nit: isn't the option-len sufficient to determine the prefix length? Is > the prefix-len byte necessary? No, it is not sufficient. Without the prefix-len field, you cannot find out the exact prefix length. For example, you can identify whether the prefix length is between 57 and 64. You cannot find out the exact prefix length. > > 3) The encoding for the domain names in the NIS and NIS+ Domain Name > options should be DNS encoding, shouldn't it? That seems more robust than > ASCII to me. Agreed. > > 4) The 'Service Location Protocol Directory Agent Option' places the > 'typed-scope-list-len' field before the 'DA address', rather than before > the 'typed scope list'. Couldn't the length of the list immediately precede > the list? I think, it won't make any difference. Let me know, if there are any serious issues on this. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] additional option for dhcpv6 Vijay Bhaskar A K
- Re: [dhcwg] additional option for dhcpv6 Ted Lemon
- Re: [dhcwg] additional option for dhcpv6 Mark Stapp
- RE: [dhcwg] additional option for dhcpv6 Bernie Volz (EUD)
- Re: [dhcwg] additional option for dhcpv6 Vijay Bhaskar A K
- RE: [dhcwg] additional option for dhcpv6 Bernie Volz (EUD)
- RE: [dhcwg] additional option for dhcpv6 Vijayabhaskar A K
- RE: [dhcwg] additional option for dhcpv6 Jim Bound
- RE: [dhcwg] additional option for dhcpv6 Jim Bound
- RE: [dhcwg] additional option for dhcpv6 Bernie Volz (EUD)
- Re: [dhcwg] additional option for dhcpv6 Mark Stapp
- RE: [dhcwg] additional option for dhcpv6 Terrance Humphries
- Re: [dhcwg] additional option for dhcpv6 Vijay Bhaskar A K
- RE: [dhcwg] additional option for dhcpv6 Richard Barr Hibbs
- [dhcwg] SLPv2 DHCPv6 options (was: additional opt… Erik Guttman
- [dhcwg] RE: SLPv2 DHCPv6 options (was: additional… Richard Barr Hibbs