[Masque] Rechartering WGs (was: Re: WG Review: Multiplexed Application Substrate over QUIC Encryption (masque))

[John C Klensin <[e-mail]>]

Picking up on the MASQUE proposal and Martin's note as an
example of a more general issue...

--On Friday, April 21, 2023 20:01 +0900 "Martin J. Dürst"
<[e-mail]> wrote:

> In a case like the one below, it would be extremely helpful to
> have a (pointer to a) diff between the current and the
> proposed charter.

Agreed.  And, fwiw, it would be even more helpful if, in
addition to the diff, there was a report from the WG about what
they have accomplished, what additional work they see as
necessary (and, if it was not originally anticipated and
reflected in the prior charter, why), and how long they see the
work continuing (e.g., will this rechartering be the last
because the work will be done when the new milestones are met.  

I don't know what Martin had in mind by "a case like the one
below", but I think that sort of explanation should be required
for every rechartering request, certainly ones that are "not
intended to be [a] long-lived".

If, as reported in earlier threads, ADs are working at capacity
and the IESG's steering/management theory relies on "trust the
WG Chairs" then somewhat more reporting to the community along
with a request for comments about recharter requests is one of
the few opportunities for community oversight without
significantly increasing the IESG workload.  

Also, at a slight increase to that workload, I think it is
reasonable to expect that ADs will engage Chairs in performance
reviews as part of the rechartering process before renewing
their appointments.  I have no reason to believe there is any
problem with the leadership of this particular WG (and some
reason to believe things are in good shape in that regard).
However, we have sometimes heard times from other ADs about
other working groups that an underperforming WG Chair cannot be
replaced because there are no other candidates. If that
situation exists in a WG for which rechartering is needed, it is
probably a good time to ask whether, if there isn't sufficient
community interest to produce appropriate volunteers, extending
the WG with a new charter and schedule is appropriate.

best,
   john

> On 2023-04-21 06:51, The IESG wrote:
>> The Multiplexed Application Substrate over QUIC Encryption
>> (masque) WG in the Transport Area of the IETF is undergoing
>> rechartering. The IESG has not made any determination yet.
>> The following draft charter was submitted, and is provided
>> for informational purposes only. Please send your comments to
>> the IESG mailing list ([e-mail]) by 2023-04-30.
>> 
>> Multiplexed Application Substrate over QUIC Encryption
>> (masque)
>> -------------------------------------------------------------
>> ---------- Current status: Active WG
>> 
>> Chairs:
>>    Christopher Wood <[e-mail]>
>>    Eric Kinnear <[e-mail]>
>> 
>> Assigned Area Director:
>>    Martin Duke <[e-mail]>
>> 
>> Transport Area Directors:
>>    Martin Duke <[e-mail]>
>>    Zaheduzzaman Sarker <[e-mail]>
>> 
>> Mailing list:
>>    Address: [e-mail]
>>    To subscribe: https://www.ietf.org/mailman/listinfo/masque
>>    Archive: https://mailarchive.ietf.org/arch/browse/masque/
>> 
>> Group page: https://datatracker.ietf.org/group/masque/
>> 
>> Charter: https://datatracker.ietf.org/doc/charter-ietf-masque/
>> 
>> Many network topologies lead to situations where transport
>> protocol proxying is beneficial. For example, proxying
>> enables endpoints to communicate when end-to-end connectivity
>> is not possible or to apply additional encryption where
>> desirable (such as a VPN). Proxying can also improve client
>> privacy, e.g., by hiding a client's IP address from a target
>> server. Proxying technologies such as SOCKS and HTTP(S)
>> CONNECT exist, albeit with their own shortcomings. For
>> example, SOCKS signalling is not encrypted and HTTP CONNECT
>> is currently limited to TCP.
>> 
>> The primary goal of this working group is to develop
>> mechanism(s) that allow configuring and concurrently running
>> multiple proxied stream- and datagram-based flows inside an
>> HTTP connection. The group has specified CONNECT-UDP and
>> CONNECT-IP, collectively known as MASQUE, to enable this
>> functionality. MASQUE leverages the HTTP request/response
>> semantics, multiplexes flows over streams, uses a unified
>> congestion controller, encrypts flow metadata, and enables
>> unreliable delivery suitable for UDP and IP-based
>> applications.
>> 
>> The MASQUE working group will now develop HTTP extensions,
>> which might be specific to the HTTP version, to the core
>> client-initiated CONNECT-UDP and CONNECT-IP functionality.
>> Services that a proxy initiates without any prompt from a
>> client are out of scope.
>> 
>> Exercising the extension points defined by CONNECT-UDP and
>> CONNECT-IP helps to make it easier to support new use cases
>> or accommodate changes in the environment in which these
>> protocols are deployed. The initial set of extensions will be
>> in support of UDP listening, and CONNECT-UDP proxying
>> optimizations when the UDP traffic is QUIC. Additional
>> extensions that provide missing functionality, improve
>> performance, or otherwise ease deployability for use cases
>> may be adopted where there are multiple implementation and/or
>> deployment proponents. The intended status is Standards
>> Track, but the WG may downgrade if it believes that is
>> appropriate for the ultimate document maturity level.
>> 
>> Extensions to HTTP Datagrams will be coordinated with
>> HTTPBIS. Extensions that solely relate to generic proxying
>> functionality, and are not specific to the core MASQUE
>> documents, are out of scope.
>> 
>> Specifying proxy server discovery mechanisms is out of scope.
>> New congestion control and loss recovery algorithms are also
>> out of scope. However, the working group will consider
>> implications of tunneling protocols with congestion control
>> and loss recovery over MASQUE proxies, and may issue
>> recommendations accordingly.
>> 
>> The working group will consider how the protocols it defines
>> might operate over versions of HTTP that use TCP rather than
>> QUIC, for use when QUIC is unavailable. This might include
>> defining alternative extensions specifically for use in these
>> HTTP versions.
>> 
>> IP multicast is out of scope. Designs need not explicitly
>> preclude multicast, but they will not focus on
>> multicast-specific features.
>> 
>> Impacts on address migration, NAT rebinding, and future
>> multipath mechanisms of QUIC are not anticipated. However,
>> the working group should document these impacts, or those of
>> any other QUIC developments, if they arise.
>> 
>> The group will coordinate closely with other working groups
>> responsible for maintaining relevant protocol extensions,
>> such as HTTPBIS, QUIC, or TLS. It will also coordinate
>> closely with ICCRG and TSVWG on congestion control and loss
>> recovery considerations, and intarea for IP Proxying.
>> 
>> MASQUE is not intended to be a long-lived working group.
>> 
>> Milestones:
>> 
>>     - Submit an extension for UDP listeners
>> 
>>     - Submit an extension for QUIC-aware proxying
>> 
>> 
>> 
>> _______________________________________________
>> IETF-Announce mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>