[DNSOP] Re: [Ext] An unofficial DNSSEC algorithm testing registry

> part       text/plain                1606 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.

It seems that people want to do too many different things.

Some people just want a unique code point because that make life easy.

253 and 254 have identifier spaces that is big enough for everything but
some people don't want extra bytes so they want to have a registry for
short names in 253. Which they can also do outside the IETF. 

We have an 8-bit space that is small but far from full. But people worry about
cluttering the register with obsolete algorithms.


_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]