Re: [secdir] secdir review of draft-ietf-dnsext-dnssec-alg-allocation-02

[Paul Hoffman <[e-mail]>]

At 6:46 PM -0500 3/2/10, Samuel Weiler wrote:
>On Tue, 2 Mar 2010, Andrew Sullivan wrote:
>
>>The text of this draft currently explicitly notes that it doesn't
>>change the rules for making an algorithm mandatory to implement.
>>Since making an algorithm mandatory to implement would update 4034, I
>>therefore think that it would still require standards action, which
>>punts the whole business right back to the same process in place
>>today.  Does that make you less uneasy?
>
>It still leaves me uneasy.  As a casual reader of this doc (and casual author of an algorithm definition doc), I'd be inclinded to assume that an algorithm definition doc, even if not standards track, could at least specify the requirement status for the algorithm it's defining.

That line of logic would mean that any Informational RFC on any topic can "specify the requirement status". The IETF has never worked that way, and never will.

>As I pointed out when reviewing draft-ietf-dnsext-dnssec-registry-fixes, I'm worried about the possibility of an independent submission (=RFC Editor stream document) creating a new "MANDATORY" algorithm or of changing the requirement status of other new algorithms, even if those were defined on the standards track.  I proposed some text for the registry-fixes doc to resolve that, and I suggest repeating it here:
>
>"Unless specified in a Standards Track RFC, new algorithms will have a requirements status of OPTIONAL.  Only a Standards Track RFC may set or change a requirements status of ENCOURAGED or MANDATORY."

Mixing the contents of these two documents is a terrible idea. It puts the rules for the registry in two documents instead of one.

>At the very least, rather than say "This document does not change the requirements for when an algorithm because (sic) mandatory to implement. Such requirements should come in a separate, focused document.", actually tell people what the mechanism/threshhold for setting a requirement level is.  I don't think it's currently obvious.

It is not because that mechanism is in a different document, as it should be.