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

Reply via email to