Or alternatively, as happened to me on DPRIV, after attempting
to do something very similar a few years earlier, various browser providers
told me their red lines (page load latency cannot increase) which I
relayed to the group which promptly ignored them.
Deployment issues do create red lines for many parties whose buy-in
is often necessary to make a protocol successful.
<snip>
In general, a red line is not a personal constraint, it is an external one.
I think the point here is that in engineering contexts we talk about
constraints, rather than diplomatic "red lines". If a deployable system
has a constraint (page load time cannot increase), then it is very
important that the constraint be clear to everyone working on the system.
But it is also clear that in the IETF engineering context, we have to look
at the engineering context outside a single implementation or protocol
exchange. If we accept that not meeting a constraint will hinder
deployment, we have to look at the whole system to see how to meet it.
That may mean that work increases to cover both the core aim and the work
to meet the constraint. If increasing the privacy of the DNS by setting up
cryptographic contexts increases latency in a naive implementation, then
the work to use long-lived connections or pre-emptive cache fill or other
latency-reducing tricks may have to be done along the way.
The tricky bit there is that the overall driver for the core work may have
to cover the implementation and deployment costs of the adjunct work, which
can be difficult to assess. This gets even harder, of course, when the
adjunct work shifts whose ox gets gored.
To put this another way, I think the IETF has ways of dealing with its
issues in ways which parallel Inaba style processes, but that they are
expressed more as constraints and re-contextualization in our world.
regards,
Ted