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" <duerst@xxxxxxxxxxxxxxx> 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 (iesg@xxxxxxxx) by 2023-04-30. >> >> Multiplexed Application Substrate over QUIC Encryption >> (masque) >> ------------------------------------------------------------- >> ---------- Current status: Active WG >> >> Chairs: >> Christopher Wood <caw@xxxxxxxxxxxxxxx> >> Eric Kinnear <ekinnear@xxxxxxxxx> >> >> Assigned Area Director: >> Martin Duke <martin.h.duke@xxxxxxxxx> >> >> Transport Area Directors: >> Martin Duke <martin.h.duke@xxxxxxxxx> >> Zaheduzzaman Sarker <Zaheduzzaman.Sarker@xxxxxxxxxxxx> >> >> Mailing list: >> Address: masque@xxxxxxxx >> 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 >> IETF-Announce@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ietf-announce >
