Re: [dhcwg] additional option for dhcpv6
Vijay Bhaskar A K <vijayak@india.hp.com> Wed, 23 January 2002 16:47 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 LAA15866 for <dhcwg-archive@odin.ietf.org>; Wed, 23 Jan 2002 11:47:18 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04086 for dhcwg-archive@odin.ietf.org; Wed, 23 Jan 2002 11:47:21 -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 LAA03534; Wed, 23 Jan 2002 11:32:35 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03509 for <dhcwg@optimus.ietf.org>; Wed, 23 Jan 2002 11:32:32 -0500 (EST)
Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15185 for <dhcwg@ietf.org>; Wed, 23 Jan 2002 11:32:29 -0500 (EST)
Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by atlrel8.hp.com (Postfix) with ESMTP id 1EC51E003DC; Wed, 23 Jan 2002 11:32:00 -0500 (EST)
Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id WAA03344; Wed, 23 Jan 2002 22:06:17 +0530 (IST)
From: Vijay Bhaskar A K <vijayak@india.hp.com>
Message-Id: <200201231636.WAA03344@dce.india.hp.com>
Subject: Re: [dhcwg] additional option for dhcpv6
To: mjs@cisco.com
Date: Wed, 23 Jan 2002 22:06:16 +0530
Cc: vijayak@india.hp.com, dhcwg@ietf.org
In-Reply-To: <4.3.2.7.2.20020121092051.021d8468@goblet.cisco.com> from Mark Stapp at Jan "21, " 2002 "09:44:31" am
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
> Vijay, > > 1) FQDN Option. I really think that we should use a single option that can > convey both a complete FQDN or a partial 'hostname'. It's unnecessary to > try to specify two options and the relationship between them. Certainly, > there's no need to include the RCODE fields that were part of the v4 FQDN > option: like the two name encodings in the v4 version, those fields were > left in place because there was a large base of deployed clients who > expected those fields to be present. I'd suggest that we specify the same > method that's used in the v4 option to distinguish between fully-qualified > and unqualified names: if the last label in the name field is null-length, > the name is fully-qualified. If a client believes it knows a complete FQDN, > it sends that name and terminates it accordingly. If it only knows a > partial name, it sends the labels it knows. Agreed. But, i feel that, insteading of discussing now on the fields needed for FQDN option, we can finalise the DDNS updates and then come back to format definition for FQDN option. > >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. > > I think that the specification must be clear about the behavior that the > paragraph in your reply describes. The server MAY consider the subnet > specified as it considers the other information available to it about its > allocation policies and about the client. I will include whatever i have explained in the text for this option. > > > > > > > > 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. > > There are so many examples of the field len/field value convention that I > think it's much clearer to continue using that convention unless there's a > very good reason not to. I don't think that there is such a reason in this > case, and I think that it will make the specification and implementation of > this option more robust if we retain that convention. I assumed SLP DA address and scope list as data, i didn't want put an len field in between. -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ______Ph:_2051424________ ____Telnet:_847_1424_____ ___Pager:_9624_371137____ _______________________________________________ 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