On Mon, 14 Nov 2005, The IESG wrote:
> The IESG has received a request from the Dynamic Host Configuration WG to
> consider the following documents:
>
> - 'A DNS RR for Encoding DHCP Information (DHCID RR) '
>   <draft-ietf-dnsext-dhcid-rr-10.txt> as a Proposed Standard
> - 'Resolution of FQDN Conflicts among DHCP Clients '
>   <draft-ietf-dhc-ddns-resolution-10.txt> as a Proposed Standard
> - 'The DHCP Client FQDN Option '
>   <draft-ietf-dhc-fqdn-option-11.txt> as a Proposed Standard
> - 'The DHCPv6 Client FQDN Option '
>   <draft-ietf-dhc-dhcpv6-fqdn-03.txt> as a Proposed Standard

I read draft-ietf-dhc-dhcpv6-fqdn-03.txt.  I believe most of the 
comments also apply to the DHCPv4 option.  I think the document set 
was overall well written, though there seemed to be a couple of issues 
which need to be resolved.

substantial
-----------

    The Client FQDN option MUST only appear in a message's options field
    and applies to all addresses for all IA_NA bindings in the
    transaction.

==> shouldn't this be rather specified the other way around, i.e., in 
which cases the receivers MUST discard Client FQDN options?  Sooner or 
later someone will send the option in a wrong place, and it makes 
sense to guard against this in the receiver's implementation.

    o  Otherwise, if the client's "S" bit is 1 and the servers's
       configuration allows it to honor the client's request for the
       server to initiate AAAA RR DNS updates and if it has the necessary
       credentials, the server sets the "S" to 1.  If the server's "S"
       bit does not match the client's "S" bit, the server sets the "O"
       bit to 1.

==> the server cannot know, before it has tried DNS update, whether it has
"the necessary credentials", right?

    The server MAY perform these updates even if the client's message did
    not carry the Client FQDN option.  The server MUST NOT initiate DNS
    updates when responding with an ADVERTISE message to the client.

    The server MAY complete its DNS updates (PTR RR or PTR and AAAA RR)
    before the server sends the REPLY message to the client.
    Alternatively, the server MAY send the REPLY message to the client
    without waiting for the update to be completed.  Whether the DNS
    update occurs before or after the REPLY is sent is entirely up to the
    DHCPv6 server's configuration.

    If the server's AAAA RR DNS update does not complete until after the
    server has replied to the DHCPv6 client, the server's interaction
    with the DNS server MAY cause the DHCPv6 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
    [8].  In such cases, the domain name that the server returns to the
    DHCPv6 client would change between two DHCPv6 exchanges.

==> does the first paragraph work with Rapid Commit, as there are no
messages beyond Advertise?

==> actually, the 2nd sentence of 1st paragraph should maybe be placed at
the end of the second paragraph -- it'd seem more logical there.

==> how does the resolution process described in 3rd paragraph work with
Rapid Commit?  If DNS update is done after the last communication with the
client, it's not clear how you signal the changed FQDN to the client?

9.  Security Considerations

==> this section should provide a pointer to ddns-resolution's 
security considerations section, highlighting the necessity of 
implementing conflict resolution properly.  For example, something 
like,

    It is critical to implement proper conflict resolution, and the
    security properties of conflict resolution apply [8].  For example,
    a DHCP-client from example.com should not be able to override,
    e.g., www.example.com.

editorial
---------

    Depending on the prescence of or type of authentication used with the

==> s/prescence/presence/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg