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