Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-fqdn-01.txt

From: [email-masked]
Date: Tue, 25 Jan 2005 16:01:39 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: The DHCPv6 Client FQDN Option
	Author(s)	: B. Volz
	Filename	: draft-ietf-dhc-dhcpv6-fqdn-01.txt
	Pages		: 13
	Date		: 2005-1-25
	
This document specifies a new Dynamic Host Configuration Protocol for
   IPv6, DHCPv6, option which can be used to exchange information about
   a DHCPv6 client's fully-qualified domain name and about
   responsibility for updating DNS RRs related to the client's address
   assignments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-fqdn-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-dhcpv6-fqdn-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-dhcpv6-fqdn-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Jan 2005 13:50:33 -0700

I just gave this one a thorough reread in anticipation of the last call.
There is still an outstanding issue.   On page 7, section 5.1, it says 
"the client MAY originate an update for the AAAA RRs (..) unless the 
server has set the S bit to one.   If the "S" is 1, the DHCPV6 client 
MUST NOT initiate an update for the name in the Domain Name field."

I don't think this is valid.   The one case where I am willing to 
accept this is valid is where the name is different than the name 
provided by the client.   However, if the name is the same as the one 
supplied by the client, and the client is configured to update the AAAA 
record on that name, the client should be entitled to update it 
regardless of what the server says.   The only exception I can think of 
to this is that if the name is in a site-local IP address space.   In 
this case, I think it shouldn't do the update, regardless of the 
setting of the 'S' bit.

So I would suggest changing the text to read this way:

    If a client that owns/maintains its own FQDN wants to be responsible
    for updating the FQDN to IPv6 address mapping for the FQDN and
    address(es) used by the client, the client MUST include the Client
    FQDN option in the SOLICIT with Rapid Commit, REQUEST, RENEW, and
    REBIND message originated by the client.  A client MAY choose to
    include the Client FQDN option in its SOLICIT messages.  The "S" bit
    in the Flags field in the option MUST be 0.  The "O" and "N" bits
    MUST be 0.

    Once the client's DHCPv6 configuration is completed (the client
    receives a REPLY message and successfully completes a final check on
    the parameters passed in the message), the client MAY originate an
    update for the AAAA RRs (associated with the client's FQDN), with the
    following restrictions:

     1. If the name returned by the server in the Client FQDN option is
        not identical to the name send by the client, the client MUST NOT
        use the name returned by the server in its update.   This 
includes,
        for example, the case where a client sends an unqualified name, 
and
        the server returns a fully-qualified name.
     2. If the IP address that the client received is not global in 
scope,
        the client MUST NOT insert a AAAA record in the DNS for that IP
        address.

Otherwise, despite the verbiage to the contrary in the introduction, we 
are specifying policy, not mechanism.

In section 7 on page 10, it says "conflicts SHOULD NOT occur."   This 
is a prediction of what will happen, not a requirement, so it would be 
better to say "will not occur".   If you want to say "should not" it 
shouldn't be uppercased.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Jan 2005 14:34:30 -0700

I gave this draft a read as well, since it's in last call already.   It 
seems to have the same problem as the DHCPv6 FQDN draft.   I'm copying 
the text of my previous message so you don't have to refer to it; I 
apologize for the repetition.   The suggested replacement text is 
different in accordance with the differences between v4 and v6 
addressing.

On page 8, section 4.2, it says "the client MAY originate an update for 
the A RR (..) unless the server has set the S bit to one.   If the "S" 
is 1, the DHCP client MUST NOT initiate an update for the name in the 
Domain Name field."

As with the DHCPv6 client FQDN draft, I don't think this is valid.   
The one case where I am willing to accept this is valid is where the 
name is different than the name provided by the client.   However, if 
the name is the same as the one supplied by the client, and the client 
is configured to update the A record on that name, the client should be 
entitled to update it regardless of what the server says.   The only 
exception I can think of to this is that if the name is in a non-global 
IP address space such as 10.* or 192.168.*.   In this case, I think it 
shouldn't do the update, regardless of the setting of the 'S' bit.

     1. If the name returned by the server in the Client FQDN option is
        not identical to the name send by the client, the client MUST NOT
        use the name returned by the server in its update.   This 
includes,
        for example, the case where a client sends an unqualified name, 
and
        the server returns a fully-qualified name.
     2. If the IP address that the client received is not global in 
scope,
        for example because it is in the 10.0.0.0/8 subnet or the 
192.168/16
        subnet, the client MUST NOT insert an A record in the DNS for 
that IP
        address.

In section 6 on page 11, it says "conflicts SHOULD NOT occur."   This 
is a prediction of what will happen, not a requirement, so it would be 
better to say "will not occur".   If you want to say "should not" it 
shouldn't be uppercased.

Otherwise it looks good - thanks for the hard work on this!   If we can 
fix these two issues (I don't really care about the second one, but 
it's trivial, so might as well get fixed) in last call, I'm happy to 
see the draft advance.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Jan 2005 15:18:10 -0700

> So I would suggest changing the text to read this way:

Er, in cutting and pasting I neglected to change a number of instances 
of AAAA to A and DHCPv6 to DHCPv4.  Sorry about that.