Crypto-agility isn't just the ability to substitute one algorithm for another, it should include the jettisoning any unnecessary baggage that might've been appropriate (or required) for one algorithm if it's not appropriate (or required) for another.
Let's just say that crypto-agility includes negotiation of parameters relating to the cryptographic algorithms, as well as the algorithms themselves.
One question that I'd like to understand is the extent to which the negotiation can be protected in either of the proposals.
WIth DTLS, in the absence of DNSSEC, I think that an attacker in the middle could subvert the DTLS up-negotiation, so as to cause a client and server that support DTLS to negotiate plain RADIUS. So some sort of policy pre-configuration is required (e.g. RADIUS server requires DTLS on these NASes). With DNSSEC, it is possible to specify whether a NAS/Server supports DTLS in a DNS SRV RR, so it seems like protected negotiation would be possible.
I'm not sure about the level of protection provided in draft-zorn. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/>