Let me synthesize one new argument, though I've implied it before, but I think making it explicit may be useful:
The cost of making the requested changes is fixed and can be estimated -- measured even, after the fact. I argue that cost is low. But the cost/risk of not making the requested changes is intangible -- could be very high, or barely more (but not less) than the cost of making the changes. We'd have to be sanguine to dismiss my estimate of the cost/risk of fixing this later. Perhaps that's right anyways, but it can plausibly be very large too, and that surely should trump a small fixed cost, therefore we're better off taking this hit now. I might clarify other points on the main thread, but, really, for me, the whole thing boils down to: are we looking out for the future, and is our contention of risk to future DANE deployment even plausible. It won't surprise anyone that I believe my estimate of the risk to future DANE deployment is not merely plausible. It won't surprise anyone either that I believe that even if the likelihood of reduction of future DANE deployment were low, we, the IETF, and in particular the IESG, ought to care about making our protocols sufficiently generic when the cost of doing so is low, as surely it would be here. We've already incurred what should be much of the cost of making the requested changes. A wee bit little more won't hurt. Let us now then proceed to proposed text. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls