Re: [dhcwg] additional option for dhcpv6

> 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