I just had a conversation on the phone with Sam Hartman, which I hope will
turn out to have been constructive. Basically, Sam agrees that it's
unlikely that we will need to change the hash algorithm in the future, but
won't go so far as to say that he's sure we won't.

So what he asked us to do is to put an algorithm identifier on the DHCID, but
not make any other changes (we could change to SHA-1 or SHA-256 as our
initial algorithm, and that might mollify some folks; since it's basically a
search and replace on the document, I think it's worth doing).

The idea is that in the unlikely event that we at some future date need to
change the hash, then AT THAT TIME we write a draft that tells us how to do
updates in the transitional state where more than one hash might still be
present in the DNS. For now, we just put the identifier there and don't
change anything else.

This seems like a reasonable compromise - since we're claiming that we're
never going to need the additional complexity, hopefully this postpones the
work to describe and implement that complexity forever; if it turns out that
we're wrong, we have a path forward.

I can go more into the reasons why we agreed on this particular approach if
anyone's interested, but unless you are, I'll just leave it at that.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: