Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt

On Jul 17, 2012, at 10:00 AM, Steve Crocker wrote:

> There is a subtle point that may be helpful to recall.  The primary purpose of advertisement of which algorithms are understood by the resolver is to provide a measure of the adoption of new algorithms.  In the broad, slow cycle of introduction of new algorithms and the presumed phasing out of old algorithms, operators on the signing side of the equation will be choosing when to sign with a new algorithm and when to stop signing with an old algorithm.  They can sign with a new algorithm whenever they feel ready to do so, but they cannot rationally stop signing with the old algorithm until they have evidence that essentially all of the resolvers understand the new algorithm.  

Fully agree with all that.

> Thus, as I said, the primary purpose of this protocol extension is to provide measurable assessment of the uptake of a new algorithm.  From this perspective, the order of the algorithms within the resolver's advertisement is irrelevant.

And that too, of course.

> Subordinate to this primary purpose is the potential for also advertising a preference.  Whether the responding system pays attention to the order is up to the responding system.  Also, as you suggest, the querying system may or may not have a real preference.  

Nowhere in this document or any other DNSSEC RFC do we give any advice on why a resolver should have a preference. And that's a good thing.

> I don't think we have enough information to say one way or the other,

We disagree, strongly. Until you can show that more than a small fraction of the users of this will have a preference, saying that all of them need to have a preference in order to express it in a list adds a layer of complexity that you cannot show has any value.

> and the perfect is the enemy of the good.  

Thats a convenient way of saying "I don't know, but I liked this feature before, so let's leave it in". Some of us prefer not to add superfluous features and would use different trite saying to back our opinions.

> Let's move this forward and revisit your concern when there is some implementation and deployment experience to examine.  

Errr, how? Under what criteria could that evaluation be made? I propose that there are none possible.

> I hope is that this is the worst issue we will have to deal with.

Fully agree.

--Paul Hoffman

_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext