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 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. Cheers, Brian
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail