On Wed, 15 Sep 2021, Paul Hoffman wrote:
On 15 Sep 2021, at 17:17, Daniel Migault wrote:
This draft provides the ability to register code points for non standard
algorithms and I would like to understand how this non standard status
affects the interoperability compared to the standard ones. If it does not
impact interoperability we should say and explain why.
As the draft clearly states, all DNSSEC algorithm types other than the two in
this draft already do not require standards track. This draft just adds two
more DNSSEC algorithm types to that list. I do not think that this draft
should explain the earlier IETF decisions to not require standards track for
those algorithms; those earlier RFCs already did as much as needed.
I agree with PaulH here, as the draft clearly states:
The rationale for these changes is to bring the requirements for DS
records and for the hash algorithms used in NSEC3 in line with the
requirements for all other DNSSEC algorithms.
My comment is that the document should clarify how introducing a
nonstandard algorithm differs from a standard algorithm.
That would be the task of RFC 8624bis, not this draft. Although this
draft already does provide a general advise:
and updates RFC 8624 to say that algorithms that are described in RFCs
that are not on standards track are only at the "MAY" level of implementation
recommendation.
A new "non standard" algorithm could only appear at the MAY level.
That is a strong hint that it is not wise to solely rely on it. If
it breaks, you get to keep both pieces. If one strongly feels it
should gain more support/momentum, go and push it through as standards
track document after the initiating non-standard publication.
I don't think this draft would enable unexpected unsafe deployments of
new algorithms.
The question was whether RFC 8624 can recommend or not a nonstandard
algorithm, not providing the recommendation itself.
After this draft is a standard, an update to RFC 8624 can make such a
recommendation. That is what Section 3 says.
RFC 8624 can only recommend what it recommends in the document at
publication time. A successor to 8624, which would require going
through the working group on standards track, can recommend whatever
the working group decides at the time.
Paul
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
