Change:
This talks about the odd case where target and gateway are separate. The primary insight here is that the target is just a regular HTTP resource and the requests from the gateway aren't special. Problems only occur if the gateway is privileged in some way. If abuse comes via the gateway, then the target would ordinary block the client, which tends to affect a bunch of bystanders in this model. So there is pressure to do something special for the gateway. In that case, the target is trusting the gateway in some way. Explain that. The heading here is the only case where we use the short names of the entities, but I can't stand short headings.
The changes are a big step forward in the right direction, but the flow seems a little weird as the text in the first part of the security section is about co-located gateway/target. Strongly suggest to move the added new text at the end of the whole section and add a forward reference in the text: (from the intro in the security section)
And, just to be clear, the PR text addresses my concern. My comment about the flow is just editorial.
I've taken the suggestion to move the text (with forward references) and made a few tweaks: Rebased. Moved and rewritten some text from the top of the security considerations that better fit the new section. Added a forward reference to this section. Moved and rewritten text added in to the applicability section. (Originally this was just to correct a misspelling, but I think this makes more sense in the new home.) NAME can you double-check my work. With this, I think we're ready to revise the draft and ask the IESG to finalize their ballot.

Discussion:
between the and the . While the is a distinct HTTP resource from the , they are both logically under the control of the Oblivious Gateway, since the can unilaterally dictate the responses returned from the to <del> the . This arrangement is shown in fig-overview.  See security for more information about and Oblivious Relay, and Oblivous Gateway resources in running this protocol. </del> <ins> the . This arrangement is shown in fig-overview. </ins> 2.1.

location-specific content (such as retrieving tiles of a map display). <ins> In addition to these limitations, security describes operational constraints that are necessary to realize the goals of the protocol. </ins> 2.2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

A server operates both the and the <ins> separate-target discusses the security implications for a case where different servers operate the and . </ins> Requests from the to and from to MUST use HTTPS in order to provide <del> unlinkability in the presence of a network observer.  The scheme of the determines what is used between the Oblivious Gateway and Target Resources, though using HTTPS is RECOMMENDED; see server- responsibilities. </del> <ins> unlinkability in the presence of a network observer. </ins> To achieve the stated privacy goals, the cannot be operated by the same entity as the . However, colocation of the and simplifies the

considerations of HTTP also apply to the handling of the content of these media types. <ins> 6.10. This document generally assumes that the same entity operates the and the .  However, as the performs generic HTTP processing, the use of forwarding cannot be completely precluded. The scheme specified in the determines the security requirements for any protocol that is used between the Oblivious Gateway and Target Resources.  Using HTTPS is RECOMMENDED; see server-responsibilities. A that is operated on a different server from the is an ordinary HTTP resource.  A can privilege requests that are forwarded by a given if it trusts the operator of the to only forward requests that meet the expectations of the .  Otherwise, the treats requests from an no differently than any other HTTP client. For instance, an might - possibly with the help of - be trusted not to forward an excessive volume of requests.  This might allow the to accept a greater volume of requests from that relative to other HTTP clients. An could implement policies that improve the ability of the to implement policy exemptions, such as only forwarding requests toward specific Target Resources according to an allowlist; see server- responsibilities. </ins> 7. One goal of this design is that independent requests are only