First, I have a personal opinion. I did not get the same impression from the draft as you did Eliot that other considerations are excluded. But I do think that "where possible" is broader than mere theoretical feasibility. An example: One of the debates in a WG that wanted to do more for security of their application was about which one of two possible technical solutions would result in a bigger practical impact. When we actually go and do something about our protocols we have to make decisions like that, and they all are ultimately weighed decisions of how important we think various aspects are, or predictions about future things. Normal course of work in our WGs. I do get however Stephen's reluctance to make a too soft statement. Because I think we do as a community want to improve on the technical protection against pervasive surveillance. And I think it would be a bad idea to water the statement down too much - I compare the situation to the time that we wrote the strong crypto BCP, and at that time it might be been arguably "practical" to just use weak crypto given all export regulations and other hassles. But we prevailed, and we need to push boundaries again today. FWIW, I was never particularly fond of the text that talked about network management and monitoring. I could probably personally live with a broader statement only that said something like "where technically feasible and can provide improved security in practical deployments". YMMV. Second, as the sponsoring AD I wanted to remind everyone that we're trying to determine the IETF's opinion on this matter. This may involve text changes. At the plenary Brian reminded us that it took a long time to get the previous BCPs done (even if I think the IETF started acting accordingly pretty soon). We do want to get this right, and the BCP needs to make as much sense in the future as some of the older BCPs make sense today. Also, since this is about the IETF's opinion, neither mine, the authors, or individual commenter's opinion may be exactly reflected in the end result. Jari