RE: [dhcwg] additional option for dhcpv6

Please remove me from your list.

Thanks,

Terrance Humphries
Network Security and 
Administration Manager
Tjay@byu.edu
801-224-7513

-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of
Vijay Bhaskar A K
Sent: Sunday, January 20, 2002 7:34 AM
To: mjs@cisco.com
Cc: vijayak@india.hp.com; dhcwg@ietf.org
Subject: Re: [dhcwg] additional option for dhcpv6

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 mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg