Re: [dnsext] Publication request: draft-ietf-dnsext-dnssec-registry-fixes-07

[Thomas Narten <[e-mail]>]

Thanks Paul. I agree with they way you have layed out the basic
issues.

> The philosophical / operational tussle here is whether the
>  definitive list of crypto algorithms and their implementation
>  requirements should be kept in:

> a) an IANA registry for the growing list of algorithms, and a single
>  RFC for the implementation requirements

That is (IMO) the normal way the IETF have done things.

> b) an IANA registry for the growing list of algorithms, and a set of
>  loosely coupled RFCs for the implementation requirements

Actually, IETF does this too, but I agree it's not great. Making
people hunt through many RFCs to find things tends to not help. Choice
a) would be better, though we often don't bother.

> c) an IANA registry for a growing list of algorithms that is tied to
>  a single RFC for the implementation requirements

And I have to wonder why we even need a registry, when the contents of
the registry are effectively kept in a single RFC, with some types of
updates to the registry effectively requiring reissuing the RFC and
replacing the entire IANA registry.

> Some WGs have gone with (a), and some with with (b). The current
>  draft proposes (c) for this protocol. It is a modification of the
>  idea in (a), and it gives the implementer less chance of getting it
>  wrong because they will find the exact same set of implementation
>  requirements in "the" RFC and the IANA registry.

I think we are deceiving ourselves if we think putting the compliance
info into the IANA registry will make any difference at all.

The important thing is to have the requirements in one place, where
they are easily findable by anyone who has even a small amount of
clue. If implementors won't find them in a BCP IETF document, I
suspect there is very little we can do to make things easier for them.

And implementors will implement what is in RFPs and the like, and they
will point to the RFC stating the requirements, not the IANA registry.

> To me, this is different and a bit weird, but could make sense for
>  getting better interoperability because of better understanding on
>  the part of developers. It seems worth a try and, if it turns out
>  to be more confusing than (a) or (b), the WG can drop back to one
>  of them.

To me, the work to be done is the same: layout the implementation
recommendations in a BCP RFC. I don't see much value in putting that
info into the IANA registry itself, and I very much dislike the idea
of trying to have the IANA registry be where implementation
recommendations are captured. It seems like the wrong mechanism to
bring about a particular result.

Thomas