Change:
protocol is similar to UDP proxying in HTTP, but allows transmitting arbitrary IP packets.  More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an <del> HTTP server that acts as a proxy. </del> <ins> HTTP server that acts as a proxy.  This document updates RFC 9298. </ins> 1.

Discussion:
See
LGTM, thanks. Might be worth mentioning that those are relative to .well-known explicitly in the registry def?
Have we checked with the expert NAME what the preferred way of documenting that multiple document specify different part of the sub-path after the initial prefix? I would feel that we need to be clearer that we want IANA to add this information to what is already existing. The use of just update can easily mean replace which would not be correct. I also wonder if this should be an additional entry line or just kept in the same entry is unclear to me. I could see that one actually split the current masque entry into two, one for masque/udp and one for masque/ip
So for clarity this is about this section: https://ietf-wg-URL
I imagine this should imitate what CONNECT-UDP published for its RFC?
NAME the issue I see her is the fact that UDP and IP tries to share the same well known suffix of "masque". So the question that arises here is how we are tracking the sub-identifiers and their references in this registry. So UDP created this registry, but does not specify a sub-registry, if it did that would be the registry we would add "ip" to. Instead it appears the current intention are adding both references into the same registry entry. And if we are doing that we need to be more careful in our instructions to IANA. A third way forward would be to register "masque/ip" as the well known suffix and get a separate entry into the table. URL I also think we haven't discussed this much, and I think we should rope in the expert into this discussion. I think we will have to move to email for that. But I want to check with the other authors first, I think we especially want NAME thoughts here about it. I am willing to drive the question towards the MASQUE WG, the IANA expert (Mark Nottingham) and I assume it is HTTPBIS WG that might have additional input into this.
The registry cannot and will not allow strings like -- the only registrable string is what's legal as a path segment. Managing the space "under" the registered path segment is up to the registrant. You could create a sub-registry, or you could just update the registering document when you need to expand it.

Thanks NAME thus I think this is an issue we need to take to the MASQUE WG to discuss how to bet handle and if there should be put in place some additional registries under the masque suffix.
Started discussion on the masque mailing list: URL WG, When doing a review of the connect-ip draft and its IANA consideration I realized that we will have to clarify a bit how to handle the well-known names URI suffix “masque”. So Connect-UDP (RFC 9298) registers the “masque” suffix. But the draft is also clear that it only uses the masque/udp path. Connect IP wants to use the masque/ip path. However, the suffix registry only allows registering a suffix for a single path element, i.e. “masque”. Thus, arise the question of the future management of this sub-space of “masque”. It is likely that some additional extended connect usages will be specified in the future for other protocols. Thus, others will likely follow in the track of what we do with Connect-IP. The main goal here as I see it is to ensure that we track what is in use to avoid collisions and that one can reverse look up this name space back to specification. For these purposes I see two routes that appear compatible with the existing registry. We update the URL entry for “masque” to list all currently known usages and specifications. We create a sub-registry for the masque space and in that add “udp” and “ip” as entries and update the existing well known uris registry to reference the changing spec and the new sub-registry. I think A) is clearly easier at this point. However, if we forsee that more than one or two more protocols will register additional sub-entries then I think we really should consider B). And doing B) now is simpler than doing it later when you have more RFCs that will not be aligned with this usage. Opinions? Cheers Magnus Westerlund