Feedback on draft-mm-wg-effect-encrypt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]