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