Subject: [dhcwg] draft-ietf-dhc-fqdn-option-09.txt

From: "Bernie Volz" <[email-masked]>
Date: Mon, 24 Jan 2005 14:40:35 -0500

Hi:

I've made some minor edits to draft-ietf-dhc-fqdn-option-08.txt for a new
revision. These are based on comments made by Jyrki Soini and Stig Venaas.

I have requested the new version to be published and until then it can be
found at ftp://ftp-eng.cisco.com/volz/draft-ietf-dhc-fqdn-option-09.txt.

I'd like to have this version submitted for the DHC WG last call that was
postponed a few weeks back.

The changes are (old shown first, new shown second) as follows:

Section 3:

<    MUST send the option in subsequent DHCPREQUEST messages.
---
>    MUST send the option in subsequent DHCPREQUEST messages though the
>    contents of the option MAY change.

<    Only one FQDN MAY appear in a message.  As per [13], multiple
<    instances of this option in a message SHOULD be concatentated.
---
>    Only one Client FQDN option MAY appear in a message.

<    The code for this option is 81.  Its minimum length is 3.
---
>    The code for this option is 81.  Its minimum length is 3 (octets).

<    The Format of the Client FQDN Option is:
---
>    The format of the Client FQDN option is:

>    The above figure follows the conventions of [8].

Section 3.1:

<    The Format of the Flags Field is:
---
>    The format of the 1-octet Flags field is:

<    DNS updates.  A server sets the "N" bit to indicate whether it SHALL
<    (0) or SHALL NOT (1) perform DNS updates.  If the "N" bit is 1, the
<    "S" bit MUST be 0.
---
>    DNS updates.  A server sets the "N" bit to indicate whether the
>    server SHALL (0) or SHALL NOT (1) perform DNS updates.  If the "N"
>    bit is 1, the "S" bit MUST be 0.

<    described in RFC 1035 [3] and SHOULD be used by clients.  0 indicates
<    a now deprecated ASCII encoding.  Servers MUST use the same encoding
<    as received from the client.  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.  Clients which implemented this encoding were deployed
<    before this specification was completed.  Server implementers which
<    need to support these clients need to see the section on the
<    deprecated ASCII encoding (Section 3.3.1).
---
>    described in RFC 1035 [3].  This encoding SHOULD be used by clients
>    and MUST be supported by servers.  0 indicates a now deprecated ASCII
>    encoding (see Section 3.3.1).  A server MUST use the same encoding as
>    that used by the client.  A server that does not support the
>    deprecated ASCII encoding MUST ignore Client FQDN options that use
>    that encoding.

Section 3.3.1:

<    The DNS encoding specified above MUST be supported by DHCP servers.
<    However, a substantial population of clients implemented an earlier
<    draft version of this specification, which permitted an ASCII
<    encoding of the Domain Name field.  Server implementations SHOULD be
<    aware that clients which send the Client FQDN option with the "E" bit
<    set to 0 are using an ASCII encoding of the Domain Name field.
<    Servers MAY be prepared to return an ASCII encoded version of the
<    Domain Name field to such clients.  Servers that are not prepared to
<    return an ASCII encoded version MUST ignore the Client FQDN option if
<    the "E" bit is 0.  The use of ASCII encoding in this option SHOULD be
<    considered deprecated.
---
>    A substantial population of clients implemented an earlier draft
>    version of this specification, which permitted an ASCII encoding of
>    the Domain Name field.  Server implementations SHOULD be aware that
>    clients which send the Client FQDN option with the "E" bit set to 0
>    are using an ASCII encoding of the Domain Name field.  Servers MAY be
>    prepared to return an ASCII encoded version of the Domain Name field
>    to such clients.  Servers that are not prepared to return an ASCII
>    encoded version MUST ignore the Client FQDN option if the "E" bit is
>    0.  The use of ASCII encoding in this option SHOULD be considered
>    deprecated.

<    the Domain Name field, excluding the "." (dot) character.  Such
<    clients SHOULD follow the character-set recommendations of RFC 1034
<    [2] and RFC 1035 [3].
< 
<    Server implementers SHOULD also be aware that some client software
<    could be using UTF-8 [9] character encoding.  This information is
<    included for informational purposes only; this specification does not
<    require any support for UTF-8.
---
>    the Domain Name field, excluding the "." (dot) character.
> 
>    Clients and servers SHOULD follow the character-set recommendations
>    of RFC 1034 [2] and RFC 1035 [3].  However, implementers SHOULD also
>    be aware that some client software could be using UTF-8 [9] character
>    encoding.  This specification does not require any support for UTF-8.

- Bernie

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

---

From: "Bernie Volz" <[email-masked]>
Date: Mon, 24 Jan 2005 17:18:04 -0500

Hi:

I've just submitted draft-ietf-dhc-dhcpv6-fqdn-01.txt (available temporarily
at ftp://ftp-eng.cisco.com/volz/draft-ietf-dhc-dhcpv6-fqdn-01.txt).

This updates the DHCPv6 Client FQDN draft to match the comments received for
the DHCPv4 Client FQDN draft.

And, perhaps more significantly, the option is now only used at the message
level (not encapsulated within IA_NA or IA_TA options) and applies to all
IA_NA's in the transaction. If a client wants different FQDNs for each
binding, it MUST use multiple transactions (one for each IA_NA) instead of
combining them in one transaction.

- Bernie