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

From: Jyrki Soini <[email-masked]>
Date: Tue, 28 Dec 2004 17:50:07 +0200

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?

    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.

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?

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?

--
Jyrki

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