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