Subject: RE: [dhcwg] Comments on draft-ietf-dhc-fqdn-option-08.txt

From: "Bernie Volz" <[email-masked]>
Date: Tue, 11 Jan 2005 18:12:39 -0500

Hi:

Thanks for the review comments.

See comments below.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Jyrki Soini
> Sent: Tuesday, December 28, 2004 10:50 AM
> To: [email-masked]; [email-masked]
> Subject: [dhcwg] Comments on draft-ietf-dhc-fqdn-option-08.txt
> 
> 
> The new version of draft is much easier to read, especially the flag 
> field description.
> 
> Here are some comments:
> 
> 3. The Client FQDN Option
> 
>     Clients MAY send the Client FQDN option, setting appropriate Flags
>     values, in both their DHCPDISCOVER and DHCPREQUEST messages.  If a
>     client sends the Client FQDN option in its DHCPDISCOVER 
> message, it
>     MUST send the option in subsequent DHCPREQUEST messages.
> 
> - May client change the FQDN or flags between DHCPDISCOVER and
>    DHCPREQUEST messages?

Yes, it may. I'll add some language to that effect.

> 
>     Only one FQDN MAY appear in a message.  As per [13], multiple
>     instances of this option in a message SHOULD be concatentated.
> 
> - ... As per [13] option may be splitted during encoding and later
>    multiple instance of this option in a message SHOULD( or MUST) be
>    concatenated in decode phase.

I'll rework this paragraph a bit.

> 
> 3.1 The Flag Field
> 
>     ... 0 indicates
>     a now deprecated ASCII encoding.  Servers MUST use the 
> same encoding
>     as received from the client.
> 
> - Could clarify this by copying from 3.3.1:
>     "Servers that are not prepared to
>     return an ASCII encoded version MUST ignore the Client 
> FQDN option 
> (if the "E" bit is 0)."
> 
>     ... Server implementers SHOULD note that
>     earlier draft versions of this specification permitted an ASCII
>     encoding of the domain name and this encoding MUST be 
> used if the "E"
>     bit is 0.
> 
> - Use of SHOULD? I would delete "Server implementers SHOULD note that"
>    and start: "Earlier draft versions..."
> 
> 3.3.1  Deprecated ASCII Encoding
> 
>     The DNS encoding specified above MUST be supported by 
> DHCP servers.
> 
> - This sentence is in wrong chapter.
> 
>     ... Server implementations SHOULD be aware that clients which ...
>     ... Server implementers SHOULD also be aware that some client
>     software could be using UTF-8 [9] character encoding.
> 
> - Use of SHOULD?

I'll rework the "E" bit description and 3.3.1.

> 
> 5.1  When to Perform DNS Updates
> 
>     If the server's A RR DNS update does not complete until after the
>     server has replied to the DHCP client, the server's 
> interaction with
>     the DNS server MAY cause the DHCP server to change the domain name
>     that it associates with the client.  This can occur, for 
> example, if
>     the server detects and resolves a domain-name conflict 
> [6].  In such
>     cases, the domain name that the server returns to the DHCP client
>     would change between two DHCP exchanges.
> 
> - Should the server send a new DHCPACK message once it 
> notices FQDN change?

No! This is not valid to do as part of the DHCP protocol. The server will
send the name on the next client initiated transaction.

> --
> Jyrki

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