I think that consideration of perpass at the architectural level, being prepared to justify decisions, and seeking adequate review of those decision early enough to make changes if we're wrong are critical to this document. strongly object to publication of this document without that. I value integrity and honesty very highly and am feel sick when I think about claiming to the world that we're going to address perpass mitigations without being willing to commit to ourselves to do the architectural work. You cannot simply take a protocol and mitigate these sorts of issues. Many of our existing technologies leak a lot of information to attackers. One of the most important decisions when we start work on new protocols in terms of perpass mitigation will be what building blocks we use. If we're not willing to commit to having those discussions up front, reviewing them and when questions arise during that review , I don't think we're being truthful or acting with integrity if we claim that we're mittigating perpass threats. I'd much rather us be honest that we're not willing to do what it takes to deal with perpass threats than to claim to try and mitigate them with a solution that I think will be unsuccessful. I do understand being concerned and worried that an AD would block something late in the process because of bad architecture. If the architecture was appropriately reviewed, I think that's the right wrong approach. I'd support language making that more clear. If the architecture was inadequately reviewed, I strongly feel that should be handled like any process problem. Some process problems are blocking; some cases of inadequate review of an architecture also should be blocking. Yes, some of that is subjective and needs to be argued by the IESG and community if there is conflict.