Document: draft-ietf-dhc-dhcpv6-fqdn-03.txt  
[also includes review of draft-ietf-dhc-fqdn-option-11.txt]
Reviewer: Harald Alvestrand
Date: Nov 28, 2005
Telechat Date:  Thursday 12/01/2005

Summary: Mostly Ready - one piece missing or misplaced

These documents appear to be competently written and describe their 
functionality in a reasonable manner. They have also been a long time in 
coming - the first FQDN option (then named "dhcp-dns") seems to have 
occured in February 1996.

These procedures can be practiced without the conflict-resolution 
procedure, and it's appropriate to do so in the quite common case of one 
DHCP server being responsible for a domain; thus, I find the placement of 
"ddns-resolution" in the normative references puzzling.
(The SHOULD reference to ddns-resolution in section 6 is in a dependent 
clause with a couple of big preconditions - so it's hard to justify a 
normative reference based on this).

The one big piece of missing material I find in these documents is the 
treatment of the TTL field; there is a good presentation of this in 
draft-ietf-dhc-ddns-resolution section 5, which I think would be better 
placed in these two documents, since TTLs must be set properly even if 
ddns-resolution is not in use.

A smaller piece of missing material is this, from section 3.3.1 of the v4 
document:

   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 [10]
   character encoding.  This specification does not require any support
   for UTF-8.

Given DNS experts' insistence that the DNS protocol does not place any 
limits on character sets, it would be good to have a clearer pointer to 
what recommendations are intended here.
Given that it's in section 3.3.1 (Deprecated ASCII encoding), one can 
assume that this refers to a character set recommendation for characters in 
the ASCII encoding; a DNS encoded name should probably be used "as is", no 
matter what it contains (although it would be good if the doc said so).

It's also unclear from the text whether or not there's a trailing dot on 
the name in the deprecated ASCII encoding (there's no need for one, since a 
non-FQDN name can only be one component, but other fields of use have done 
this in the past, so it's best to be clear that this field does not do so).

Reasonable documents.