Re: DNSEXT WG Last Call: EDNS0.5

[Paul A Vixie <vixie@mfnx.net>]

>   | The problem with EDNS was that its mechanism is very coarse grained, so 
>   | that we cannot do (for instance) negotiated tests with the next Binary 
>   | Label-type extension without going through the heavyweight procedure of 
>   | assigning a new EDNS number.
> 
> I think that's a feature (of EDNS0).  It makes it very hard to add new
> stuff, not something that can be easily done.  What's more because it
> adds a difficult mechanism to add new features, it actually makes it more
> difficult than before EDNS0 when there was no mechanism at all (so
> something relatively simple could be invented - like "no-one currently
> sets this bit" - and maybe it would work).

It's definitely the case that EDNS was designed to allow protocol evolution
rather than protocol brownian motion.  We should not be standardizing
things we're not sure of.  The EDNS weakness identified by the 0.5 draft
is that because there's a numerical comparison of version numbers, it's
somewhat difficult to _experimentally_ deploy new elements.  However once they
aren't experimental any more, the protocol should not support their withdrawal.


to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.