A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)
draft-ietf-dnsext-dhcid-rr-13

[Ballot discuss]
re draft-ietf-dnsext-dhcid-rr-10.txt

From dialogue between Gen-ART reviewer Harald Alvestrand and author
Bernie Volz:

>> The document gives three ways in which a DHCID RR
>> can be created based on data from a client request. Section 3.4 does not
>> specify which of the three to choose.
>
> I don't believe this is a problem. For DHCPv6, there is only the DUID
> that can be used. So, there's no issue here.
>
> For DHCPv4, all three forms could be used (once
> draft-ietf-dhc-3315id-for-v4-05.txt is an RFC and implementations
> support it).
>
> However, the DHCPv4 server knows which format to use as it is using that
> same information to associate the client with a lease.
>
> In general, a DHCPv4 server would:
> - Use the DUID format if the client and server both support
> draft-ietf-dhc-3315id-for-v4-05.txt and the client presents a
> client-identifier option formatted as a DUID. (Note that
> draft-ietf-dhc-3315id-for-v4-05.txt documents some issues with migrating
> to clients/servers that support
> draft-ietf-dhc-3315id-for-v4-05.txt.)
> - Use the Client Identifier option from the client if the client
> included this option in its messages.
> - Use the htype/chaddr otherwise.
...

If you include that little list in this document, I'm fine with it...


[Harald also noted the MD5 issue that's covered by Sam's DISCUSS]

[Ballot comment]
re draft-ietf-dhc-fqdn-option-11.txt

Comments from Gen-ART review by Harald Alverstrand:

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).


-------------------------

Many lesser comments on the document set at these URLs:
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-dnsext-dhcid-rr-10-alvestrand.txt
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-dhc-ddns-resolution-10-alvestrand.txt

IANA Last Call Comments:
Upon approval of this document the IANA will assign a RR type number for the DHCID record type in the following registry:
http://www.iana.org/assignments/dns-parameters

The IANA will also create a new registry for the 16-bit type codes associated with the DHCID RR.  Three initial values are assigned in Section 3.3 of this document and the value 0xFFFF is reserved for future use.  We understand the registration rules to be as follows:
New DHCID RR type codes are tentatively assigned after the specification for the associated type code, published as an Internet Draft, has received expert review by a designated expert. 
The final assignment of DHCID RR type codes is through Standards Action, as defined in RFC 2434 [6].

A designated expert will need to be appointed.