Change:
Comments and discussion are found in issue . The proposed changes are minimal.
Once this is processed one way or another, I would like to publish a revised draft.
Thanks for clearly writing down attacks and requirements in this document. One small technical comment on this sentence: Sec 2.3: "Per-stream QoS can be provided by a combination of packet marking and end-to-end agreements." If this sentence is meant to mean use of DSCP, I don't think this is true, as DSCP is usually not available end-to-end but most often gets changed or bleached somewhere on the path. And two editorial comments: Sec 2.1: "The SNI was defined to facilitate management of servers, though the developers of middleboxes soon found out that they could take advantage of the information." "soon found out" does sound a bit story-telling like to me. I recommend a more objective phrasing like: "The SNI was defined to facilitate management of servers, though other usages by middleboxes also take advantage of the information." or something similar... Also sec 2.1: "The SNI is probably also included in the general collection of metadata by pervasive surveillance actors." This sentence is phrased a bit speculatively and at the same kind seems inherently true as a "pervasive surveillance actor" usually just collect all available data/traffic... I guess the more interesting question would be if and how this information is used. Anyway I recommend some rephrasing like: "The SNI could also be utilised by the general collection of metadata by pervasive surveillance actors."
Hi Christian, Please see below. From my point of view „some time after“ wouldn’t make it much better because I think the important part of the information of this sentence is that middleboxes use that information (for good or bad) and not who had the idea when. But again just a comment... Yes, removing end-to-end does help but it also sounds a bit as if that is a solution ready to use which I don’t think is the case. Maybe also say “could” instead “can” (to propose another minimal change)? Mirja >
Addressed in PR

Discussion:
2.1. <del> The SNI was defined to facilitate management of servers, though the developers of middleboxes soon found out that they could take advantage of the information.  Many examples of such usage are reviewed in RFC8404.  They include: </del> <ins> The SNI was defined to facilitate management of servers, but the developers of middleboxes found out that they could take advantage of the information.  Many examples of such usage are reviewed in RFC8404.  They include: </ins> The SNI is probably also included in the general collection of <del> metadata by pervasive surveillance actors. </del> <ins> metadata by pervasive surveillance actors, for example to identify services used by surveillance targets. </ins> 2.2.

described as legitimate.  Most of these functions can, however, be realized by other means.  For example, some DNS service providers offer customers the provision to "opt in" filtering services for <del> parental control and phishing protection.  Per-stream QoS can be </del> <ins> parental control and phishing protection.  Per-stream QoS could be </ins> provided by a combination of packet marking and end-to-end agreements.  As SNI encryption becomes common, we can expect more deployment of such "end-to-end" solutions.