On Thu, 16 Jan 2025, Philip Homburg wrote:
b) Is step 3b (a short RFC that points to a specific version of an
expired draft) acceptable? If not, what would be needed, given that
the original author didn't want to progress their document?
When it comes to using a cryptographic algorithm in DNSSEC there are two parts
in the specification. The first is a general description of the
cryptographic algorithm that applies to all contexts not just DNSSEC.
Which can be a normative reference to a document outside the IETF.
The second is how the algorithm should be used in DNSSEC. Something about
parameters and encoding of inputs and results.
We can assume that cryptographic algorithms will be developed outside the
IETF and that by the time we make such an algorithm a SHOULD or RECOMMENDED a
stable reference will be avaliable. So the thing the IETF needs to add is
the second part.
I don't think that is often needed. For example, RFC 8080 only really
contains 4 lines of information that is available elsewhere.
So I think the requirement is obvious. If a cryptographic algorithm is to be
listed as SHOULD or RECOMMENDED then a standard track specification of the
second part is required.
I think only a document that is Standards Track is needed to change the
SHOULD or RECOMMENDED values as a group - eg talking about all the
available algorithms as a group and recommend. It should try to avoid
making those decisions on a case to case basis because these are often
happening too soon (eg when the draft is written without deployment
experience) and otherwise don't happen in the context of other
algorithms.
That means that if the code point was allocated based on a draft then a new
draft that is intended for standards track needs to be created that copies the
relevant material of the original draft.
Not if we cluster the recommendations of multple drafts/algorithms into
1 document that is bis'ed every couple of years.
What I do not know, can a draft request IANA to update the reference for a
previously allocated code point?
AFAIK, no. Only "early code points" assignments or RFCs can set those
fields.
Paul
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
