RE: Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs

[Ólafur Guðmundsson /DNSEXT co-chair <[e-mail]>]

Margaret,

The publication of dhcid-12 resolves all DNSEXT issues with this document
set, raised in the IETF last call and IESG discussion on the documents.
DNSEXT consider these documents complete and requests they be forwarded to
the RFC editor ASAP. Links to the new documents at the bottom of this message.


Sam Hartman,
Does the new document set address all the issues you voiced in your
discuss messages ?

Ralph, Stig,
Does this document set close all DHC issues ?

         Olafur (who wants this finished before Dallas IETF meeting)


At 13:20 25/02/2006, Ólafur Guðmundsson /DNSEXT wrote:
>At 22:57 22/02/2006, Bernie Volz \(volz\) wrote:
>
>>Hi:
>>
>>I have just submitted revised versions of the 
>>drafts. Copies of what I submitted are available at:
>>
>>Ralph had sent a list of 11 issues to the 
>>mailing list. And, then followed up with 19 
>>more raised by Pekka Savola but that list of 
>>issues did not go to the DHC WG. Both emails 
>>are below so you can see the full list of 30 issues.
>>
>>I believe I have addressed all of them.
>
><DNSEXT chair-hat=on>
>Bernie,  thank you for your diligent work on getting the document
>set updated.
>
>
>>Some key changes are that the DHCID RR now has 
>>an additional field to specify the digest type 
>>and we've switched to using SHA-256 instead of MD5.
>
><DNSEXT chair-hat=off>
>To give a little background on this change.
>During the document revision there was a off-list discussion that involved
>Ralph Droms, Olafur Gudmundsson, David Harkins, Sam Hartman, Ted Lemon
>and Bernie Volz. This recollection is mine apologies to anyone that I
>misrepresent/misunderstood/omitted.
>
>This results of discussion need to be documented, and I'm doing that here.
>   1. Without obfuscation of the client ID, it is trivial to track clients
>         as the move around.
>   1.5 No protocol change can protect a client that exposes its Client ID
>       over a public network, such as the IETF wireless net. But obfuscation
>       still provides large number of clients with increased privacy.
>
>   2. In the overall schema of things he cost difference between using MD5,
>      SHA1 and SHA256 is not that great, thus 
> the strongest one should be used.
>
>   3. Changing obfuscation functions over time can either
>      be accomplished by using a new field in DHCID or new RR type.
>      It is better not having to do a type code rollover. The rollover
>      to a new digest function MUST be defined by the NEW definition,
>      by this document. The reason for this is we are not sure if there
>      is ever a need so spending time on that right now is not productive,
>      and by selecting the one of the strongest functions available
>      right now we hope to push this far into the future, i.e. after
>      Ted, Ralph and I retire from the ietf :-).
>
>
>>We need to figure out what the next step is -- 
>>do we need another DHC / DNSEXT WG last-call or 
>>do we send these to the IESG directly?
>
>
>
><DNSEXT chair-hat=on>
>Most of the changes are "minor" and I do not see need for a last call,
>either at the WG level or IETF.
>Scanning the documents I'm concerned that the examples are TBD, thus
>I request that at least 3 parties calculate the new digests and post
>their results. After which the DHCID document is needs to be updated.
>
>>If there is strong demand, I can develop diff 
>>files but as there were a lot of minor edits 
>>and changes to references, it likely will be rather large set of differences.
>
>Diffs and (partial history are available at
>http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-dhcid-rr/
>
>http://tools.ietf.org/wg/dhc/draft-ietf-dhc-ddns-resolution/
>
>http://tools.ietf.org/wg/dhc/draft-ietf-dhc-fqdn-option/
>
>http://tools.ietf.org/wg/dhc/draft-ietf-dhc-dhcpv6-fqdn/
>
>         Ólafur
>
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/dhcwg
>