[DNSOP] Re: [Ext] An unofficial DNSSEC algorithm testing registry
Petr Špaček <[email protected]> Tue, 14 Jul 2026 15:20:19 +0200
| Newsgroups | gmane.ietf.dnsop |
|---|---|
| Message-ID | <[email protected]> |
On 27. 06. 26 14:28, Philip Homburg wrote: >> Not only that, no. Given the problems that other groups have had >> well-documented problems with experimental ranges (code $experimental1 >> is used for FALCON testing, later FALCON is assigned code $real1, >> now developers have to guess how long to keep using $experimental1), >> we think that using 253-with-lead-in is actually better for the >> community. > >>From a developer point of view, this is exactly the same problem. For the > question how long to support $experimental1 it doesn't matter whether it is > an expiremental code point or a third-party registry built on top of a > an extension mechanism for private algorithms. I think the fundamental problem is: The registry range is too limited so we need to care. If we had registry and 32 bit value with FCFS allocation policy, we could just allocate a new algorithm number every week and still have plenty. And if the algorithm did not took or/was retracted by NIST, who cares, just leave the number in there and move on. 253 and 254 can do the same but have their own quirks which are people seemingly unwilling to fix. Would it help if we extended the range by allocating one value which says 'EXTENDED-ALGORITHM' followed by 4 bytes unsigned int, which would be present in DNSKEY/DS/RRSIG payload? Should be simple enough if people are actually willing to do any work at code at all. -- Petr Špaček _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]