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