So... having written a bunch of stuff, someone has suggested to me an
alternative compromise offlist, as follows:
OLD:
In particular, architectural decisions, including which existing
technology is re-used, may significantly impact the vulnerability of
a protocol to PM. Those developing IETF specifications therefore
need to consider mitigating PM when making these architectural
decisions and be prepared to justify their decisions. Getting
adequate, early review of architectural decisions including whether
appropriate mitigation of PM can be made is important. Revisiting
these architectural decisions late in the process is very costly.
NEW:
In particular, architectural decisions, including which existing
technology is re-used, may significantly impact the vulnerability of
a protocol to PM. Those developing IETF specifications therefore
need to consider mitigating PM when making these architectural
decisions. Getting
adequate, early review of architectural decisions including whether
appropriate mitigation of PM can be made is important. Revisiting
these architectural decisions late in the process is very costly.
I can live with this, largely because everything there is true at the
general level. We're all going to learn to provide more specific advice
than this, however. As I wrote, I am hoping that the STRING workshop
will help us make some headway.
Eliot