Code change:
The first is an incorrect change -- "advance configuration" means configured prior to the request, not "advanced". The second is indeed a typo.
Roman Danyliw has entered the following ballot position for draft-ietf-httpbis-semantics-16: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: [x] ** Section 2.2. Per “Additional (social) requirements are placed on implementations …”, what’s a “social” requirement? Editors: removed in (URL)
[x] ** Section 4.2.2. http + https origins on the same host uniformly. Editors: added text in
[x] ** Section 5.1. Convention question. Per “Field names … ought to be registered within the …” HTTP field name registry, I have a question about the strength of the recommendation based on the use of the verb “ought” – is that RECOMMENDED? SHOULD? Section 8.3.1, 8.3.2, 8.4.1, 8.8.3, etc use a similar construct. Editors: we intentionally do not to use normative language for registration requirements.
[x] ** Section 7.2. Does this text allow for the possibility for both a Host and :authority be included? Editors: it's syntactically possible in H2 and H3. It's up to those specs to describe what that would mean.
[x] ** Section 9.2.1. In addition to example of the access logs files filling the disk, there could be significant CPU load if the target is a script. Editors: URL
[x] ** Section 17.1. The text provides helpful caution by stressing that “… the user's local name resolution service [is used] to determine where it can find authoritative responses. This means that any attack on a user's network host table, cached names, or name resolution libraries becomes an avenue for attack on establishing authority for "http" URIs.” The subsequent text highlights DNSSEC as improving authenticity. It seems that the integrity provided by DoT or DoH would also be relevant. Editors: added text in (see also URL)
[x] ** Section 17.2 people who run them; HTTP itself cannot solve this problem. No disagreement with the sentiment, but I would recommend not framing it in term of the trustworthiness of the people (i.e., intermediaries with poor security or privacy practices is not necessarily due to the lack of trustworthiness of the engineers operating the service; perhaps these services are also run in of jurisdictions where confidence in them should be reduced). NEW Users need to be aware that intermediaries are no more trustworthy that the entities that operate them and the policies governing them; HTTP itself cannot solve this problem. Editors: URL
[x] ** Section 17.5. More generically describe the attack OLD NEW Editors: d466398e
** Editorial
[x] -- Section 3.5. Should s/advance configuration choices/advanced configuration choices/? Editors: no, advance has the same meaning as "configuration choices made prior to request"
[x] -- Section 4.2.2. This text goes from referring to “secured” in the first sentence to “[acceptable] cryptographic mechanisms” in the second sentence. To link them, perhaps s/are secured/are cryptographically secured/ Editors: "secured" is a defined term for this spec.
[x] -- Section 6.5. Typo. s/section are are/section are/ Editors: URL
[x] -- Section 11.1. The text (at least when read as a .txt) isn’t showing RFC7617 or RFC7616 as references. Editors: it does in HTML: URL
[x] -- Section 14.1.1. Typo. s/gramar/grammar/ Editors: URL
disk, there could be significant CPU load if the target is a script. Yes. But this is the definition of "safe methods", not a discussion of all potential attack vectors of a server.
user's local name resolution service [is used] to determine where it can find authoritative responses. This means that any attack on a user's network host table, cached names, or name resolution libraries becomes an avenue for attack on establishing authority for "http" URIs.” The subsequent text highlights DNSSEC as improving authenticity. It seems that the integrity provided by DoT or DoH would also be relevant. Understood. Q: do we attempt an exhaustive list here, or just mention examples? If we did mention DoT and DoH, woulkd that be exhaustive?
By nature I don't think we can be exhaustive here. If anything, I'd replace DNSSEC with DoH, as it's getting more adoption (both in implementation and deployment) on the web.
http + https origins on the same host uniformly. We already say that in several places, and I don't think repeating ourselves helps the document become more readable or useful.
There are technical interop requirements for the protocol and social requirements to keep people safe on the Internet (or the Web safe from the people abusing it). This is just a short-hand version of old IETF lore, and probably isn't worth repeating in the spec.

Related discussion:
text: options they provide to operators (especially the default configuration). <del> Users need to be aware that intermediaries are no more trustworthy than the people who run them; HTTP itself cannot solve this problem. </del> <ins> Intermediaries are no more trustworthy than the people and policies under which they operate; HTTP cannot solve this problem. </ins> 17.3.