Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients
RFC 4703

[Ballot comment]
In: draft-ietf-dnsext-dhcid-rr-12.txt

- sect 3.6.1.
    client.example.com.  A      10.0.0.1
  IP address in examples ought to be from 192.0.2.0/24 range as
  per RFC3330

- sect 3.6.2
  A DHCP server allocates the IPv4 address 10.0.12.99 to a client which
  and
    chi.example.com.      A      10.0.12.99
  Same here, IP address should be from 192.0.2.0/24 range as per
  RFC3330

- Sect 3.6.4
    A DHCP server allocates the IPv6 address 2000::1234:5678 to a client
  and
    chi.example.com.      A      10.0.12.99
  IPv6 addresses in examples should be in the  2001:DB8::/32 range as
  per RFC3849.

[Ballot discuss]
I received a few very detailed reviews from the DNS review team. The number of isssues is that large that I believe that a revised ID is warranted. However,
I don't believe that any issue in itself is enough to block this document, there
are just too many of them that can easily fixed with RFC editor notes or
in 48 hours.

Therefore, my DISCUSS is as follows:

---

Please consider the reviews form the DNS review team and update the documents where you believe it makes sense. I explicitly am not requiring you to make the
proposed changes, I only want you to consider them and make the updates where you believe it makes sense.

I actually ran out of space in the COMMENTs section to include all reviews so I am going to forward them to you seperately.

I am also willing to clear my DISCUSS with the condition that the shepherding
AD will take this issue up and deal with the revised ID.

----

[Ballot comment]
I received a few very detailed reviews from the DNS review team. The number of isssues is that large that I believe that a revised ID is warranted. However,
I don't believe that any issue in itself is enough to block this document, there
are just too many of them that can easily fixed with RFC editor notes or
in 48 hours.

Therefore, my DISCUSS is as follows:

---

Please consider the reviews form the DNS review team and update the documents where you believe it makes sense. I explicitly am not requiring you to make the
proposed changes, I only want you to consider them and make the updates where you believe it makes sense.

I actually ran out of space here to include all reviews so I am going to forward them to you seperately.

I am also willing to clear my DISCUSS with the condition that the shepherding
AD will take this issue up and deal with the revised ID.

----

I received the following comments from the DNS review team by Roy Arends that you might want to consider:

This is a review of draft-ietf-dnsext-dhcid-rr-12:

In general, an informative reference needs to be fixed. Terminology           
and examples need to be fixed, and the input construction for the             
digest algorithm is not clear. 

Review of draft-ietf-dhc-ddns-resolution-11:                                   
                                                                               
There is some wording that needs to be fixed, i.e. "update query" and         
the likes. Some references need to be fixed.

Review of DRAFT-IETF-DHC-FQDN-OPTION-12:                   
                                                                             
In general, draft-ietf-dhc-dhcpv6-fqdn-04.txt is mostly the same as           
this document. As I only review this wrt DNS, my comments will               
apply to both documents.



---

Detailed review draft-ietf-dnsext-dhcid-rr-12:

  1.  Terminology                                                             
                                                                               
  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",         
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this       
  document are to be interpreted as described in RFC 2119 [2].               
                                                                               
please put terminology after intro.

  The DHCID RR is defined with mnemonic DHCID and type code [TBD].           
  The                                                                           
  DHCID RR is only defined in the IN class.  DHCID RRs cause no               
  additional section processing.  The DHCID RR is not a singleton             
  type.                                                                         
                                                                               
The term "singleton type" is not a DNS term. Where is it defined ?

  In DNS master files, the RDATA is represented as a single block in         
  base 64 encoding identical to that used for representing binary data       
  in RFC 3548 [7].                                                           
                                                                               
There are two alphabets in RFC3548 for base 64. Which one is used here ? 

  The DHCID RR Digest Type Code is an identifier for the digest               
  algorithm used.  The digest is calculated over an identifier and the       
  canonical FQDN as described in the next section.                           
                                                                               
Is it ? How do I exactly calculate the digest ? See next section for           
more comments.

  The input to the digest hash function is defined to be:                     
                                                                               
      digest = SHA-256(< identifier > < FQDN >)                               
                                                                               
what is  ?                                                         
                                                                               
This is terribly unclear.                                                     
                                                                               
  The FQDN is represented in the buffer in unambiguous canonical form         
                                                                               
"unambiguous canonical form" is a pleonasm. Please use "Canonical             
Wire Format"                                                                   
                                                                               
  as described in RFC 4034 [8], section 6.1.                                 
                                                                               
RFC 4034 section 6.1 deals with canonical ordering of names. Please           
refer to 6.2.

  The identifier type code                                                   
  and the identifier are related as specified in Section 3.3: the             
  identifier type code describes the source of the identifier.               
                                                                               
  A DHCPv4 updater uses the 0x0002 type code if a Client Identifier           
  option is present in the DHCPv4 messages and it is encoded as               
  specified in [12].                                                         
                                                                               
[12] is informative, not normative. If one is required to know the             
encoding to determine a type-code, please refer to the encoding as             
normative.


  the client.  The DHCID RDATA is composed by setting the two type           
  octets to zero, the 1-octet digest type to 1 for SHA-256, and               
  performing an SHA-256 hash computation across a buffer containing           
  the                                                                           
  Ethernet MAC type octet,                                                   
                                                                               
What is the Ethernet Mac type octet ? is that "htype, chaddr from a           
DHCPv4 client's DHCPREQUEST" ?

  If the DHCID RR type is not supported, the RDATA would be encoded           
  [13] as:                                                                   
                                                                               
    \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283         
            fffedeb3f75e6 )                                                   
                                                                               
I tried to this, and this is my result:                                       
                                                                               
\# 35                                                                         
000001457811a1e592b6f52a81e6a7767281fb4b1379fbf2cc9645d5a2ffc9b1dd54f7         
                                                                               
The input I used, exactly following the description in the example is         
as follows (base 16 string):                                                   
                                                                               
00000101020304050606636c69656e74076578616d706c6503636f6d00                     
                                                                               
Which breaks down to  0000 identifier type code                                                     
    01 digest type                                                           
      010203040506 The six octets of the mac address                         
                                                                               
and the wireformat of client.example.com, which is                             
                                                                               
                  (6)c l i e n t(7)e x a m p l e(3)c o m(0)                   
                  06636c69656e74076578616d706c6503636f6d00                   
                                                                               
When I follow the construction as specified in the previous chapter,           
I do not need to use the identifier type code and the digest type as           
input for the hash function.                                                   
               
I tried that too, but again, different results from what you have:           
                                                                               
\# 35                                                                         
0000016388f0e5221a5faa6b109dab9bdd4c2f1a3408d59c3c60b8fb45c5b6e4f0ed94         
                                                                               
Please tell me what I did wrong.                                               
                         
  type to 1 for SHA-256, and performing a SHA-256 hash computation           
  across a buffer containing the seven octets from the client-id             
option                                                                         
  and the FQDN (represented as specified in Section 3.5).                     
                                                                               
In this example, the input buffer does not contain the identifier             
type and the digest type, which seems correct to me.                           
                                                                               
    chi.example.com.      A      10.0.12.99                                 
    chi.example.com.      DHCID  ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW         
                                    L3b/NaiUDlW2No= )                         
                                                                               
  If the DHCID RR type is not supported, the RDATA would be encoded           
  [13] as:                                                                   
                                                                               
    \# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd         
            6a2503956d8da )                                                   
                                                                               
Okay, perfect. I got the same result. 

=========================================================================

Detailed review draft-ietf-dnsext-dhcid-rr-12:

  of the DNS data is entirely dependent on the accuracy of the               
  configuration procedure.  Sites that deploy Secure DNS [11] may             
                                                                               
[11] (rfc 2535) reference is updated by rfc 4033/4034/4035                     
                 
  configure credentials for each client and its assigned FQDN in a way       
  that is more error-resistant, as both the FQDN and credentials must         
  match.                                                                     
                                                                               
rfc 2535 and its replacements deal with origin authentication and             
data integrity. This is, the actual DNS data. If you mean                     
"transaction security" such as SIG(0) and TSIG for dynamic updates,           
please refer to Secure Dynamic Update [10].                                   
               
  Certain RCODEs defined in RFC 2136 [3] indicate that the destination       
                                                                               
Nit: Don't use names and references together.  please just say                 
"Certain RCODEs defined in [3] indicate that the destination"                 
               
  Because these errors may indicate a         
  misconfiguration of the updater or of the DNS server, the updater           
  MAY                                                                           
  attempt to signal to its administrator that an error has occurred,         
  e.g. through a log message.                                                 
                                                                               
What about errorcodes specific for TSIG or SIG(0) ?

  5.3.  Adding A and/or AAAA RRs to DNS                                       
                                                                               
  When a DHCP client or server intends to update A and/or AAAA RRs, it       
  starts with the update query in Section 5.3.1.                             
                                                                               
A DNS message is either a Request or Response. The Request has an             
opcode. This opcode can be UPDATE or QUERY. So update query is                 
confusing. This should be update request.                                     
                               
===========================================================

Detailed review DRAFT-IETF-DHC-FQDN-OPTION-12:                   

  This document specifies a Dynamic Host Configuration Protocol for         
  IPv4, DHCPv4, option which can be used to exchange information             
  about                                                                         
  a DHCPv4 client's fully-qualified domain name and about                   
  responsibility for updating the DNS RR related to the client's             
  address assignment.                                                       
                                                                             
I understand this option already exists, and this document updates           
and extends its use. I would rephrase this to:                               
                                                                             
This document updates and extends the DHCP Client FQDN option for the         
Dynamic Host Configuration Protocol IPv4.  This option can be used to         
exchange information about the a DHCPv4 client's fully qualified             
domain name. This information includes the FQDN and information about         
the responsibility for updating the DNS RR related to the client's           
address assignment.

Please put terminology after the introduction.                               
                                                                             
  1.  Terminology                                                           
                                                                             
  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",       
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in                   
  this                                                                         
  document are to be interpreted as described in RFC 2119 [1].               
 
  In any case, whether a site permits all, some, or no DHCP               
  servers and                                                                   
  clients to perform DNS updates into the zones which it controls is         
  entirely a matter of local administrative policy.                         
                                                                             
Please rephrase to:                                                           
                                                                             
It is considered local policy to permit DHCP clients and servers to            perform DNS updates to zones.                                               

  This document does                                                         
  not require any specific administrative policy, and does not               
  propose                                                                       
  one.                                                                       
                                                                             
Yet, the document continues to specify a range of possible policies:         
                                                                              >             
    The range of possible policies is very broad, from sites where       
    only the DHCP servers have been given credentials that the DNS             
    servers will accept, to sites where each individual DHCP client has       
    been configured with credentials which allow the client to                 
    modify its                                                                   
  own domain name.  Compliant implementations may support some or all       
  of these possibilities.  Furthermore,                                     
                                                                             
I'd delete the previous paragraph. 
       
  This document describes a new DHCP option which a client can use to       
                                                                             
Is it new ? If it is new, why are there deprecated elements ?                 
                                                                             
  convey all or part of its domain name to a DHCP server.  Site-             
  specific policy determines whether DHCP servers use the names that         
  clients offer or not, and what DHCP servers may do in cases where         
  clients do not supply domain names.                                       
                                                                             
Note that a 'part of its domain name' is not a FQDN.                         

      client sends the Client FQDN option in its DHCPDISCOVER message, it       
  MUST send the option in subsequent DHCPREQUEST messages though the         
  contents of the option MAY change.                                         
                                                                             
  Only one Client FQDN option MAY appear in a message.                       
                                                                             
What if a client has more than one name ? It is possible to have             
more than one PTR per address.                                               
                                                                             
  The code for this option is 81.  Its minimum length is 3 (octets).         
                                                                             
To avoid ambiguity, please specify that the length is excluding the           
Code and Len field.

        Code  Len    Flags  RCODE1 RCODE2  Domain Name                     
      +------+------+------+------+------+------+--                         
      |  81  |  n  |      |      |      |      ...                         
      +------+------+------+------+------+------+--                         
                                                                             
Please state somewhere that the above convention restrict name               
lengths to 253. In DNS, a name has a maximum length of 255. 

  MUST send the option in subsequent DHCPREQUEST messages though the         
  contents of the option MAY change.                                         
                                                                             
  Only one Client FQDN option MAY appear in a message.                       
                                                                             
What if a client has more than one name ? It is possible to have             
more than one PTR per address.                                               

  The format of the Client FQDN option is:                                   
                                                                             
        Code  Len    Flags  RCODE1 RCODE2  Domain Name                     
      +------+------+------+------+------+------+--                         
      |  81  |  n  |      |      |      |      ...                         
      +------+------+------+------+------+------+--                         
                                                                             
Please state somewhere that the above convention restrict name               
lengths to 253. In DNS, a name has a maximum length of 255.                   
                                           
  The format of the 1-octet Flags field is:                                 
                                                                             
        0 1 2 3 4 5 6 7                                                       
      +-+-+-+-+-+-+-+-+                                                     
      |  MBZ  |N|E|O|S|                                                     
      +-+-+-+-+-+-+-+-+                                                     
                                                                             
The order of the flags below is not as it appears in the field.               
                                                                             
Does "S" indicate "Server" ?                                                 
                                                                             
Please be consistent in using "Flags" or "Bits"                               
       

  in the reply from the server indicates the action to be taken by           
  the                                                                           
  server; if 1, the server has taken responsibility for A RR updates         
  for the FQDN.                                                             
                                                                             
Does "O" indicate "Override" ?

  The "O" bit indicates whether the server has overridden the               
  client's                                                                     
  preference for the "S" bit.  A client MUST set this bit to 0.  A           
  server MUST set this bit to 1 if the "S" bit in its reply to the           
  client does not match the "S" bit received from the client.               
                                                                             
What does "N" indicate ?

[Ballot comment]
I received the following comments from the DNS review team by Roy Arends that you might want to consider:

This is a review of draft-ietf-dnsext-dhcid-rr-12:

In general, an informative reference needs to be fixed. Terminology           
and examples need to be fixed, and the input construction for the             
digest algorithm is not clear. 

Review of draft-ietf-dhc-ddns-resolution-11:                                   
                                                                               
There is some wording that needs to be fixed, i.e. "update query" and         
the likes. Some references need to be fixed.

Review of DRAFT-IETF-DHC-FQDN-OPTION-12:                   
                                                                             
In general, draft-ietf-dhc-dhcpv6-fqdn-04.txt is mostly the same as           
this document. As I only review this wrt DNS, my comments will               
apply to both documents.

---

Detailed review draft-ietf-dnsext-dhcid-rr-12:

  1.  Terminology                                                             
                                                                               
  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",         
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this       
  document are to be interpreted as described in RFC 2119 [2].               
                                                                               
please put terminology after intro.

  The DHCID RR is defined with mnemonic DHCID and type code [TBD].           
  The                                                                           
  DHCID RR is only defined in the IN class.  DHCID RRs cause no               
  additional section processing.  The DHCID RR is not a singleton             
  type.                                                                         
                                                                               
The term "singleton type" is not a DNS term. Where is it defined ?

  In DNS master files, the RDATA is represented as a single block in         
  base 64 encoding identical to that used for representing binary data       
  in RFC 3548 [7].                                                           
                                                                               
There are two alphabets in RFC3548 for base 64. Which one is used here ? 

  The DHCID RR Digest Type Code is an identifier for the digest               
  algorithm used.  The digest is calculated over an identifier and the       
  canonical FQDN as described in the next section.                           
                                                                               
Is it ? How do I exactly calculate the digest ? See next section for           
more comments.

  The input to the digest hash function is defined to be:                     
                                                                               
      digest = SHA-256(< identifier > < FQDN >)                               
                                                                               
what is  ?                                                         
                                                                               
This is terribly unclear.                                                     
                                                                               
  The FQDN is represented in the buffer in unambiguous canonical form         
                                                                               
"unambiguous canonical form" is a pleonasm. Please use "Canonical             
Wire Format"                                                                   
                                                                               
  as described in RFC 4034 [8], section 6.1.                                 
                                                                               
RFC 4034 section 6.1 deals with canonical ordering of names. Please           
refer to 6.2.

  The identifier type code                                                   
  and the identifier are related as specified in Section 3.3: the             
  identifier type code describes the source of the identifier.               
                                                                               
  A DHCPv4 updater uses the 0x0002 type code if a Client Identifier           
  option is present in the DHCPv4 messages and it is encoded as               
  specified in [12].                                                         
                                                                               
[12] is informative, not normative. If one is required to know the             
encoding to determine a type-code, please refer to the encoding as             
normative.


  the client.  The DHCID RDATA is composed by setting the two type           
  octets to zero, the 1-octet digest type to 1 for SHA-256, and               
  performing an SHA-256 hash computation across a buffer containing           
  the                                                                           
  Ethernet MAC type octet,                                                   
                                                                               
What is the Ethernet Mac type octet ? is that "htype, chaddr from a           
DHCPv4 client's DHCPREQUEST" ?

  If the DHCID RR type is not supported, the RDATA would be encoded           
  [13] as:                                                                   
                                                                               
    \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283         
            fffedeb3f75e6 )                                                   
                                                                               
I tried to this, and this is my result:                                       
                                                                               
\# 35                                                                         
000001457811a1e592b6f52a81e6a7767281fb4b1379fbf2cc9645d5a2ffc9b1dd54f7         
                                                                               
The input I used, exactly following the description in the example is         
as follows (base 16 string):                                                   
                                                                               
00000101020304050606636c69656e74076578616d706c6503636f6d00                     
                                                                               
Which breaks down to  0000 identifier type code                                                     
    01 digest type                                                           
      010203040506 The six octets of the mac address                         
                                                                               
and the wireformat of client.example.com, which is                             
                                                                               
                  (6)c l i e n t(7)e x a m p l e(3)c o m(0)                   
                  06636c69656e74076578616d706c6503636f6d00                   
                                                                               
When I follow the construction as specified in the previous chapter,           
I do not need to use the identifier type code and the digest type as           
input for the hash function.                                                   
               
I tried that too, but again, different results from what you have:           
                                                                               
\# 35                                                                         
0000016388f0e5221a5faa6b109dab9bdd4c2f1a3408d59c3c60b8fb45c5b6e4f0ed94         
                                                                               
Please tell me what I did wrong.                                               
                         
  type to 1 for SHA-256, and performing a SHA-256 hash computation           
  across a buffer containing the seven octets from the client-id             
option                                                                         
  and the FQDN (represented as specified in Section 3.5).                     
                                                                               
In this example, the input buffer does not contain the identifier             
type and the digest type, which seems correct to me.                           
                                                                               
    chi.example.com.      A      10.0.12.99                                 
    chi.example.com.      DHCID  ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW         
                                    L3b/NaiUDlW2No= )                         
                                                                               
  If the DHCID RR type is not supported, the RDATA would be encoded           
  [13] as:                                                                   
                                                                               
    \# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd         
            6a2503956d8da )                                                   
                                                                               
Okay, perfect. I got the same result. 

=========================================================================

Detailed review draft-ietf-dnsext-dhcid-rr-12:

  of the DNS data is entirely dependent on the accuracy of the               
  configuration procedure.  Sites that deploy Secure DNS [11] may             
                                                                               
[11] (rfc 2535) reference is updated by rfc 4033/4034/4035                     
                 
  configure credentials for each client and its assigned FQDN in a way       
  that is more error-resistant, as both the FQDN and credentials must         
  match.                                                                     
                                                                               
rfc 2535 and its replacements deal with origin authentication and             
data integrity. This is, the actual DNS data. If you mean                     
"transaction security" such as SIG(0) and TSIG for dynamic updates,           
please refer to Secure Dynamic Update [10].                                   
               
  Certain RCODEs defined in RFC 2136 [3] indicate that the destination       
                                                                               
Nit: Don't use names and references together.  please just say                 
"Certain RCODEs defined in [3] indicate that the destination"                 
               
  Because these errors may indicate a         
  misconfiguration of the updater or of the DNS server, the updater           
  MAY                                                                           
  attempt to signal to its administrator that an error has occurred,         
  e.g. through a log message.                                                 
                                                                               
What about errorcodes specific for TSIG or SIG(0) ?

  5.3.  Adding A and/or AAAA RRs to DNS                                       
                                                                               
  When a DHCP client or server intends to update A and/or AAAA RRs, it       
  starts with the update query in Section 5.3.1.                             
                                                                               
A DNS message is either a Request or Response. The Request has an             
opcode. This opcode can be UPDATE or QUERY. So update query is                 
confusing. This should be update request.                                     
                               
===========================================================

Detailed review DRAFT-IETF-DHC-FQDN-OPTION-12:                   

  This document specifies a Dynamic Host Configuration Protocol for         
  IPv4, DHCPv4, option which can be used to exchange information             
  about                                                                         
  a DHCPv4 client's fully-qualified domain name and about                   
  responsibility for updating the DNS RR related to the client's             
  address assignment.                                                       
                                                                             
I understand this option already exists, and this document updates           
and extends its use. I would rephrase this to:                               
                                                                             
This document updates and extends the DHCP Client FQDN option for the         
Dynamic Host Configuration Protocol IPv4.  This option can be used to         
exchange information about the a DHCPv4 client's fully qualified             
domain name. This information includes the FQDN and information about         
the responsibility for updating the DNS RR related to the client's           
address assignment.

Please put terminology after the introduction.                               
                                                                             
  1.  Terminology                                                           
                                                                             
  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",       
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in                   
  this                                                                         
  document are to be interpreted as described in RFC 2119 [1].               
 
  In any case, whether a site permits all, some, or no DHCP               
  servers and                                                                   
  clients to perform DNS updates into the zones which it controls is         
  entirely a matter of local administrative policy.                         
                                                                             
Please rephrase to:                                                           
                                                                             
It is considered local policy to permit DHCP clients and servers to            perform DNS updates to zones.                                               

  This document does                                                         
  not require any specific administrative policy, and does not               
  propose                                                                       
  one.                                                                       
                                                                             
Yet, the document continues to specify a range of possible policies:         
                                                                              >             
    The range of possible policies is very broad, from sites where       
    only the DHCP servers have been given credentials that the DNS             
    servers will accept, to sites where each individual DHCP client has       
    been configured with credentials which allow the client to                 
    modify its                                                                   
  own domain name.  Compliant implementations may support some or all       
  of these possibilities.  Furthermore,                                     
                                                                             
I'd delete the previous paragraph. 
       
  This document describes a new DHCP option which a client can use to       
                                                                             
Is it new ? If it is new, why are there deprecated elements ?                 
                                                                             
  convey all or part of its domain name to a DHCP server.  Site-             
  specific policy determines whether DHCP servers use the names that         
  clients offer or not, and what DHCP servers may do in cases where         
  clients do not supply domain names.                                       
                                                                             
Note that a 'part of its domain name' is not a FQDN.                         

      client sends the Client FQDN option in its DHCPDISCOVER message, it       
  MUST send the option in subsequent DHCPREQUEST messages though the         
  contents of the option MAY change.                                         
                                                                             
  Only one Client FQDN option MAY appear in a message.                       
                                                                             
What if a client has more than one name ? It is possible to have             
more than one PTR per address.                                               
                                                                             
  The code for this option is 81.  Its minimum length is 3 (octets).         
                                                                             
To avoid ambiguity, please specify that the length is excluding the           
Code and Len field.

        Code  Len    Flags  RCODE1 RCODE2  Domain Name                     
      +------+------+------+------+------+------+--                         
      |  81  |  n  |      |      |      |      ...                         
      +------+------+------+------+------+------+--                         
                                                                             
Please state somewhere that the above convention restrict name               
lengths to 253. In DNS, a name has a maximum length of 255. 

  MUST send the option in subsequent DHCPREQUEST messages though the         
  contents of the option MAY change.                                         
                                                                             
  Only one Client FQDN option MAY appear in a message.                       
                                                                             
What if a client has more than one name ? It is possible to have             
more than one PTR per address.                                               

  The format of the Client FQDN option is:                                   
                                                                             
        Code  Len    Flags  RCODE1 RCODE2  Domain Name                     
      +------+------+------+------+------+------+--                         
      |  81  |  n  |      |      |      |      ...                         
      +------+------+------+------+------+------+--                         
                                                                             
Please state somewhere that the above convention restrict name               
lengths to 253. In DNS, a name has a maximum length of 255.                   
                                           
  The format of the 1-octet Flags field is:                                 
                                                                             
        0 1 2 3 4 5 6 7                                                       
      +-+-+-+-+-+-+-+-+                                                     
      |  MBZ  |N|E|O|S|                                                     
      +-+-+-+-+-+-+-+-+                                                     
                                                                             
The order of the flags below is not as it appears in the field.               
                                                                             
Does "S" indicate "Server" ?                                                 
                                                                             
Please be consistent in using "Flags" or "Bits"                               
       

  in the reply from the server indicates the action to be taken by           
  the                                                                           
  server; if 1, the server has taken responsibility for A RR updates         
  for the FQDN.                                                             
                                                                             
Does "O" indicate "Override" ?

  The "O" bit indicates whether the server has overridden the               
  client's                                                                     
  preference for the "S" bit.  A client MUST set this bit to 0.  A           
  server MUST set this bit to 1 if the "S" bit in its reply to the           
  client does not match the "S" bit received from the client.               
                                                                             
What does "N" indicate ?

[Ballot comment]
No further objection, but in relation to how you design the hash RR for the DHC ID - I
don't understand why the dnsext WG would not sync the dhcid with the NSEC3 RR format
since that format will be implemented with hash agility and virtually the same format.
Too much compartmentailization?

I take Bill's point that DHCP is fearful of the hash agility, but it's actually not the
case that DNS knows how to signal a new hash function either, so the hash type field there
is for future-proofing really.  I think we should push the WG to use its own good design
for both RRs.

[Ballot comment]
No further objection, but in relation to how you design the hash RR for the DHC ID - the
dnsext WG is working full steam ahead, including testing, on a record with very similar functions
that stores hashed addresses, with agility, the NSEC3 RR.  It would be good sync up the
DHC ID work with this, once the other issues get cleared up.

[Ballot discuss]
The section 2 of draft-ietf-dnsext-dhcid-rr-10 says:
  >
  > A successful attack of MD5's weakness does not reveal the original
  > data that was used to generate the signature, but rather ...
  >
  The term "signature" is incorrect.  The output of MD5 is referred to
  as a message digest or a hash value.

  The section 2 of draft-ietf-dnsext-dhcid-rr-10 goes on to say:
  >
  > Because we are using the MD5 hash to conceal the original data, the
  > fact that an attacker could produce a different plaintext resulting
  > in the same MD5 output is not significant concern.
  >
  This is not the attack that is of concern in this context.  Since the
  hash value computation does not include any random secret values, the
  hash value becomes a straightforward way to verify a guess.  Once the
  hash value is fetched from the DNS, the attacker tries various
  Ethernet MAC address guesses until the data value matches, for
  example:

    data = MD5(<0x01>)

  If the target Ethernet MAC address is known to the attacker, then all
  of the inputs to the MD5 are readily available to the attacker.  The
  attacker has very little work to do to figure out which FQDN is
  being used by that target at a particular time.

  It is unclear to me what work factor is necessary to provide the
  needed privacy protection, especially given the cooperative nature
  of the overall resolution mechanism.  At a minimum, this work factor
  needs to be discussed in the security considerations section.  Also,
  the fact that MD5 is more efficient than SHA-1 and SHA-256 means that
  each guess tested by the attacker is more efficient.  The work factor
  analysis may show that a less efficient function is highly desirable.

[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]

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

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

[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 Russ's DISCUSS]

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

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

[Ballot comment]
In the introduction to fqdn-option, the document says:

DNS ([2], [3]) maintains (among other things) the information about
  the mapping between hosts' Fully Qualified Domain Names (FQDNs) [8]
  and IP addresses assigned to the hosts.  The information is
  maintained in two types of Resource Records (RRs): A and PTR.

Obviously, there are AAAA records as well.  Since they are being treated
together, an informative pointer from this document to dhcpv6-fqdn seems like
a good idea, especially since the ddns-resolution doc cites consistency among
A, AAAA, and PTR records as one of its issues.

In draft-ietf-dhc-ddns-resolution, the language in 6.3.2 was hard to follow for
the case where a DHC client has multiple interfaces and wishes to associate
AAAA or records containing the same fqdn with the v6 or v4 addresses associated
with those interfaces.

[Ballot discuss]
I have two problems with this draft.  First, md5 should not be used as
the mandatory-to-implement hash.  Secondly, you need to have hash agility: you need to have some mechanism for deploying a new hash  function.

The document argues that the only attacks against md5 are collision
attacks and that since md5 is being used to hide information this is
not a concern. We don't actually have good models for what it means to
hide information using a hash function.  The first model we have is
the primage assumption: is the hash function good enough to prevent
you from finding an entire input given an output.  That is not
affected by the current attacks, but it's also not an appropriate
model for this use of md5.  The goal is not to prevent the attacker
from finding out all the bits of the input: we need to do something
stronger and prevent the attacker from finding enough bits to identify
and track a client.  If the attacker can find out the low order bits
in a ethernet MAC, they may well be able to track a client.  So, you
need a stronger model of information hiding.  The only model we have
available stronger than preimage resistance is the random oracle
model.  However the random oracle model is clearly stronger than
collision resistance.  So, the argument that the collision attacks
don't raise concerns about the use of md5 to hide information seems
flawed from a security standpoint.  Thus, I think the mandatory to
implement hash should be sha-1 or sha-256.  If you choose sha-1 please
confirm first that Russ will not require sha-256.

You need to have some mechanism of deploying a new hash function.
Here's a sketch about one way to do it.  Feel free to adopt a better
solution.  First, you will need an algorithm identifier to describe
which hash function is being used and a registration procedure for new
hash functions.  Someone proposed using the DS registry; that might
work.  Then you will need to allow multiple DHCP ID records to exist
and describe updater behavior.  Updaters should be able to read any
hash they understand and should generate at least the current and next
new hash.  The tricky thing is what to do when an updater is looking
at a record for which there is a dhcp id, but for which the updater
cannot understand the hash.

[Note]: 'The following documents need to be coordinated:
� draft-ietf-dnsext-dhcid-rr-06.txt
� draft-ietf-dhc-fqdn-option-05.txt
� draft-ietf-dhc-ddns-resolution-05.txt
There is on-going mailing list discussion now (2003-06-05)' added by Dinara Suleymanova

Ralph & I and others had private discussion on getting issues out on the table. Result is set of mail messages to mailing list on 2003-06-05.