Change:
4.1. <ins> Unlike CONNECT-UDP requests, which require specifying a target host, CONNECT-IP requests can allow endpoints to send arbitrary IP packets to any host.  The client can choose to restrict a given request to a specific host or IP protocol by adding parameters to its request. When the server knows that a request is scoped to a target host or protocol, it can leverage this information to optimize its resource allocation; for example, the server can assign the same public IP address to two CONNECT-IP requests that are scoped to different hosts and/or different protocols. </ins> CONNECT-IP uses URI template variables (client-config) to determine the scope of the request for packet proxying.  All variables defined here are optional, and have default values if not included.

Discussion:
The current text in this draft needs to be updated to match the changes from URL I'll write up a PR once existing conflicting PRs are merged.
NAME is this unblocked now?
I continue to struggle with our difference in how we consider IP addressing and assumption on IP topology. I can't really determine which functionality is necessary to support the use cases. I think it would actually help if we actually detailed a couple of IP addressing examples for some use cases as an appendix to the draft. I am willing to help write such text. In this figure, are there any cases where we need to provide an proxy's external address to the client, rather than having the proxy act as a router of all addresses assigned to client's for packet arriving on its right side interface. The reason I ask, is in many tunnel protocols one can actually ping so to say the remote side of the tunnel, we haven't discussed if that should be possible. Also the discussion around the default route, in many cases that corresponds to all addresses except the subnet's IP range for a leaf network. I do think we would all be helped by actually drawing a couple of pictures and include subnet addresses in these to clarify the assumptions of the roles.
In QBONE today, the proxy's service address (aka "frontend address") acts as a normal reachable IP. If you wish to reach the proxy through the tunnel/flow, we provide a link-local address. In many cases, the proxy does not have a single external address that it can use as per your diagram, so it doesn't make sense to provide it. In general, I think modelling the proxy as having a single external address is detrimental. In the full tunnel mode, the proxy does not need to have any external address at all, as it may be making network routing advertisements on behalf of its clients. In the flow-based mode, it likely has more than 1 address onto which requests are mapped.
NAME I think you are confirming my point quite well. In flow-based mode, for a single flow the above picture represents terminology that is useful. However, I am not disagreeing with you on the VPN case where the model likely as you say you have a network, likely a IPv4 private address network, or an IPv6 subnet. Where the former will need a NAT device for external reachability.

My point is that unless we actually draw up a couple of representing use cases when it comes to address usages we are going to miss things, or at least spend more time talking past each other about why a particular functionality is necessary. That is why I am advocating that we spend some time at least drawing these deployment cases.
I think that adding multiple diagrams to the document that show some example use cases would be helpful.
I support diagrams; my comment above was merely pointing out some issues with the initial proposed diagram and explaining some prior art in the space.
Adding details and diagrams to expand the examples section would help here.
I don't understand how the UDP Listen Flow Example works. Unless I'm missing something, for this example to work you would need a way to convey the client's UDP port number. Since we decided that this was out of scope, perhaps we should remove this example?
This example was more about saying we can do UDP listening on an address, but all ports. So, it's binding just the protocol and address. It is something that is begging for a port extension to scope down further, but it still shows how you can do protocol listening, without being a full IP tunnel. Essentially, saying "I only implement user space UDP and can handle that, I don't want anything else".
This is the first time I've ever heard of "UDP listening on all ports". I'm not saying it isn't useful, but perhaps our examples should be focused on use-cases that people have a clear use for?
So our draft had mechanism for the client to specify traffic selectors for what it actually considers to be individual IP flows. Think about how the rules to create IPv6 flow label works. MASQUE would need something that allows the client to indicate the necessary traffic selector that results in a IP flow, without having the local API interaction that for examples enables an stack to convert sockets into flows. I think this is the question we have here. And I don't think IP proto/next header is sufficient selector here.
RFC 6437 seems to say "Packet classifiers can use the triplet of Flow Label, Source Address, and Destination Address" which suggests to me that source address + destination address are the scopes within which flow label is evaluated. As a result, I don't see what changes we'd need here to support flow labels?

It seems fine to pass them through unmodified here. If some extension wanted to add further traffic selectors that limit things by flow label, that would be possible without adding anything to the base draft.
NAME yes, for an on path device that does packet classification the flow label is scoped by the source and destination address. And that would be true in the case one only encapsulates whole IPv6 packets. However, as soon as the MASQUE endpoint becomes more flow aware one have to discuss a bit more on how this flow awareness is created. In endpoints the setting of IPv6 flow label is clearly created based on transport protocol flows. Also IPv6 flow labels could be a selector that would only work for IPv6. There is no IPv4 equivalent, and also what to do with zero flow label becomes interesting.
The protocol contains a mechanism that allows limiting the scope of the request, but doesn't explain why it would be desirable to do so. Can we add text explaining when a client would want to limit itself, and how a server can leverage this information?
Sure. I think the examples provide some insight here, but we should spell it out.
I still think that reasoning about this as a differ mode of operation helps. Depending on the use case, you either always or never want to limit the scope of your requests. There might be use case where both is used but I think the common mode of operation might be doing one or the other. In any case I agree that providing more reasoning is useful. Maybe this is part of an applicability section?
Yes, I think explaining a bit for what mechanism makes sense in which usages would help a lot.
Latest text LGTM