Re: [dhcwg] additional option for dhcpv6

[Mark Stapp <[e-mail]>]

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.

 > 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.


As I said, I think that DNS updates will be performed by different parties 
in different environments, just as they are in IP4 networks. The option 
must contain enough information to permit a network's administrators to 
influence the choice of updater for zones that are under their control.

Like Bernie, I don't know what you mean here when you claim that no 
additional data is necessary. Your claim that temporary addresses' updates 
will be done by servers is a little confusing to me. Why do you assume 
that? You imply that non-temporary updates are clearly understood to be the 
responsibility of one party. I disagree: I think that the years of field 
experience we have demonstrates that there are a variety of valid dns 
update models.

> >
> > 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.

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.


> >
> > 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.

-- Mark


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg