Eric Allman wrote:
[By the way, there was also some confusion about whether transitions are
O(years) or O(days). Changing selector records is O(days), whether or
not those selectors change algorithms, but changing algorithms requires
software updates and hence is O(years).]
Important distinction. Thanks.
It's probably worth noting that a catastrophe with a deployed algorithm, so
that a rapid transition is required, has no precedent in the large-scale, open
Internet, and probably would take considerably more effort and mechanism than
anything we are discussing here.
As such, building in anything designed a) to deal with highly problematic,
systemic failures, and b) incurring overhead for most/much regular traffic in
anticipation of that catastrophe is probably not such a good idea.
As we have seen in other such algorithm transitions for mechanisms in
end-points -- rather than infrastructure -- they tend to have a distinctive
characteristic:
While it is O(years) to achieve very broad adoption, it can be O(months
or even weeks) to gain a useful degree of adoption, within smaller communities
of interchange.
In general, this means that slower algorithm transitions are acceptable and
can be handled in the same way as we handle other transitions on the Internet.
None of them include a publication mechanism.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html