Feedback on draft-mm-wg-effect-encrypt

[Gorry Fairhurst <[e-mail]>]

Al and Kathleen,
I read the above draft as part of my preparation to think through the 
implications of encrypting transport-layer information, and this is 
therefore a very late post (sorry).

I have a few very top level comments, which I hope may help:

* I think this sort of Informational document from a slightly different 
perspective is really important to publish for the  community. It 
raises-up a myriad of topics and starts to expose areas that require 
thought in the design of protocols, operational procedures, etc. The 
greatest strength is that the scope is wide-ranging. This does not 
replace the need for more focussed infromation at each protocol layer.

* It is important to think about current operational support when we 
discuss monitoring, otherwise I fear the discussion will tend to focus 
on what is perceived as malicous monitoring. It could be easy to simply 
lump all monitoring, middleboxes, etc as bad for all, and all encryption 
as helpful to all. We need to understand the implications on design, and 
how now to best operate networks.

There are actually still quite a lot of NiTs, and I'm assuming these 
will be fixed to make this more readable):

* A few places "?" has been substituted for an apostrophe:-)
* "a reasonable
        assumption is that the DSCP markings would be withheld from the
        outer IP header to further obscure which packets belong to each
        application flow."
- Is this true. I know I worked on HAIPE (IPsec) and they allowed DSCP 
through, after a struggle, because it was such a powerful tool for 
running their networks and piroritising flows? So I question whether 
this is a given, or just a consideration that needs to be weighed? 
Actually in a mobile context we haven't observed a lot of DSCP support 
in networks... but maybe some operators do this well? (I think they 
should start!)
* Some of the mobile stuff seemed that it was jargon-rich, and more 
general wording would help where this happens. (That also may make it 
accessible to people working on Enterprise wireless, anb other network 
technologies with varying managed capacity).
* /QAM/ - I think this should be modulation/coding scheme, to be less 
technology-specific?
* /PGP/ /SMTP/ /TLS/ /DTLS/ /iSCSI/ /KPIs/ /KQI/ /QOE/ /DRM/  etc, define?
* /TCP transmitter/ /TCP sender/
* /TCP Pipelining/Session Multiplexing/ - does using a VPN also have the 
same effect?

Some sarcastic or colloqual sentences will I think make this hard to 
follow for someone who doesn't agree or does not have English as a first 
language. The key value of a survey is that it is accessible to others.

My last comment is probably the one that I think most concerns me: The 
abstract doesn't say that this is from an operational perspective - or - 
based on experience of service providers - or - something that sets the 
context, I think it is important to call-out this sort of detail for any 
informational document, to really differentiate it from publishing IETF 
consensus (e.g., BCP).

Thanks for writing this,

Best wishes,

Gorry