Dear all,
hi Mark,
...hm, apparently I *will* comment on the structure of the current document, inline below...
On 01 May 2017, at 05:45, Mark Nottingham <mnot@xxxxxxxx> wrote:
Overall, this document reads as if it was originally written to highlight the downsides of increased use of encryption, and then rewritten to be more neutral in tone. Unfortunately, some of the original intent posited there still seeps through.
In doing so, it often fails to convey that there are any options other than "this has to be done by the network." I know that this has been cast as a survey of potential impacts, and therefore doesn't necessary need to enumerate alternatives, but the way that it's written could easily lead a reader to think that there aren't alternatives. It also is odd that alternatives are not enumerated when they're often well-known, and the really interesting issues are in the tradeoffs between doing something in the network (i.e., as a third party) vs. by one of the endpoints (a first party to communication) or their delegates.
I think the statement of alternatives is a different document, though; it's one that needs to be written, yes, but the division of problem space and solution space is IMO useful here.
I would agree.
The operators are used to manage their network in a certain way.
The change for more encrypted traffic will force a change of those
operational practices.
This document should serve as for a starting point to have this debate
at the IETF, based on the documentation of those operational practices.
I see this as the analogous to the split between RFC 7624 and draft-iab-privsec-confidentiality-mitigations. It was quite useful in having the former as a complete statement of what we think the problem is (in more detail that 7258's declaration) before recommending solutions. And, indeed, it's entirely possible that an IETF consensus statement on the solutions available for a given problem is "we have decided that this is not actually a problem we should design for", as in RFC 2804.
And again agree. Not all problems in this document are valid IETF
problems. It doesn't mean that we should not document them.
Regards, Benoit
Cheers,
Brian