For those who don't already know, it is probably also highlighting that we do have a pretty good coordination with IEEE. The IETF and IEEE leadership have a standing meeting every 4 months to discuss new work (on both sides) and any hot or relevant issues between the IETF and IEEE work. From my perspective, this relatively light touch approach seems to work reasonably well to keep everyone informed and avoid surprises, although I agree with Brian that most of the "real" liaison work happens in the WGs by cross participation and discussions where needed. We don't have the same standing meeting with the ITU, but we do have appointed people acting as liaisons to the ITU, along with several other relevant SDOs, all managed by the IAB. Hence, I don't really see any great benefit in trying to align our organization structures to some other SDOs. I think that we should try and create the organizational structure that makes the most sense for the IETF, and use the existing mechanisms to interface with other SDOs. Regards, Rob > -----Original Message----- > From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of Brian E Carpenter > Sent: Wednesday, September 20, 2023 10:04 PM > To: Dave Taht <dave.taht@xxxxxxxxx> > Cc: Christian Huitema <huitema@xxxxxxxxxxx>; ietf@xxxxxxxx; Martin Duke > <martin.h.duke@xxxxxxxxx> > Subject: External overlap [Re: Proposal for Consolidating Parts of the ART & TSV > Areas] > > Dave, > > I've cut down the Cc and changed the subject accordingly. > > This isn't a new topic, in fact it goes back to about 1993 when Vint Cerf > arranged formal liaison between the Internet Society (on behalf of the IETF) > and several ISO committees. For the formalities, see > https://www.ietf.org/about/liaisons/ > > Of course, real liaison isn't achieved by formal relationships but by overlapping > participants, and that isn't something the IETF can control - there's a pretty > large amount of luck involved. > > One thing I realised when thinking about it is that the choice of topics and WGs > in the IETF is very much a bottom-up process: it's rare that the initiative for a > BOF or a new WG comes from the IESG or the IAB. So there is no systematic > management of overlaps with other SDOs. It's usually more of an afterthought > during the chartering process. > > In terms of scope, it's always been pretty clear that the IETF is "above the > hardware" (the main challenge being that MPLS is right on the boundary) and > "up to generic applications" (the main challenge being the HTTP/HTML and URI > boundary). > > The Linux Foundation is a special case. The IETF certainly aims to be O/S- > independent, despite the current prevalence of Linux. But getting code into > Linux is important. > > Regards > Brian (writing with no authority whatever) > > On 20-Sep-23 17:40, Dave Taht wrote: > > It often seems to me that the IETF should be looking outward, rather than > inward, to align itself better with the rest of the networking orgs. > > > > What is the overlap, if any, on the w3c working groups? > > > > ITU? > > > > 802.1? > > > > 802.11? > > > > Linux Foundation? > > > > On Mon, Sep 11, 2023 at 3:25 PM Christian Huitema <huitema@xxxxxxxxxxx > <mailto:huitema@xxxxxxxxxxx>> wrote: > > > > Apart from WG overlap, there is also topic overlap. Many congestion > > control issues are in fact application issues: how many transport > > connections in parallel, how often should new connections be started, > > dealing with thundering herds, adapting to variable delays, adapting to > > variable capacity, etc. > > > > -- Christian Huitema > > > > On 9/9/2023 3:00 PM, Bron Gondwana wrote: > > > It seems to me in the topic of "which groups belong in the same area" > > > that we have the blue sheets and the mailing list memberships, so we > > > could do clustering analysis to see what groups have the most overlap of > > > participants! > > > > > > (not to mention session conflict and key participant lists) > > > > > > Bron. > > > > > > On Sat, Sep 9, 2023, at 00:52, touch@xxxxxxxxxxxxxx > <mailto:touch@xxxxxxxxxxxxxx> > > > <mailto:touch@xxxxxxxxxxxxxx <mailto:touch@xxxxxxxxxxxxxx>> wrote: > > >> Hi, all, > > >> > > >> I don’t think this works at all. Transport protocol issues and web > > >> (which is app) issues are completely different skillsets. Putting them > > >> into a group doesn’t magically increase the pool of skilled > > >> participants or chairs. IMO, it would only amplify the gap. > > >> > > >> Although I appreciate that transport is a difficult area to get chairs > > >> from, the key here seems to be finding a way to reduce the workload > > >> (so it isn’t nearly a full time job) and finding ways to support the > > >> position (so we can get candidates outside the pool of commercial > > >> employees). > > >> > > >> Joe > > >> — > > >> Dr. Joe Touch, temporal epistemologist > > >> www.strayalpha.com <http://www.strayalpha.com> > > >> > > >>> On Sep 8, 2023, at 7:44 AM, Martin Duke <martin.h.duke@xxxxxxxxx > <mailto:martin.h.duke@xxxxxxxxx>> wrote: > > >>> > > >>> The IESG proposes to reorganize the areas by merging the web-related > > >>> working groups in ART with most of the transport area to create a new > > >>> area called either “Web and Application Transport” (WAT) or > > >>> “Transport and Web Applications” (TWA), effective at IETF 119. The > > >>> IESG invites community comment on this change. > > > > > > What is the overlap, if any, on the w3c working groups? > > > > >>> The Transport area (TSV) is the smallest area in terms of working > > >>> groups. More importantly, it has been extremely difficult to find > > >>> candidates for the two Transport AD positions for many years. > > >>> Although the Transport Area could be managed by one AD, the IESG > > >>> strongly feels that having a partner is very important for vacation > > >>> coverage, managing working groups, handling conflicts of interest, > > >>> and so on. > > >>> > > >>> Meanwhile, the Applications and Real Time (ART) area has been > > >>> growing. The IESG has already requested a third AD position for ART > > >>> to be seated by the NomCom in 2024. One of these three ART ADs > would > > >>> move to the new area, together with one AD from TSV. Concurrently > > >>> eliminating a position prevents growth in the overall size of the IESG. > > >>> > > >>> Similar to the OPS area, this new area would have two centers of > > >>> gravity (transport layer and web applications), so that one AD would > > >>> have transport expertise and the other would have HTTP expertise. > > >>> Thematically, this new area would have cohesion around traditional > > >>> Transport subjects and ART protocols that are often used as > > >>> transports (especially HTTP). These groups tend to have significant > > >>> attendance overlaps. > > >>> > > >>> *Affected Working Groups* > > >>> > > >>> The following working groups would move outside both ART and the > new > > >>> area: > > >>> > > >>> * > > >>> ALTO to OPS > > >>> * > > >>> DTN to INT > > >>> * > > >>> IPPM to OPS > > >>> * > > >>> SCIM to SEC > > >>> * > > >>> TIGRESS to SEC > > >>> > > >>> > > >>> The new area would consist of the following working groups: > > >>> > > >>> * > > >>> AVTCORE > > >>> * > > >>> CDNI > > >>> * > > >>> CCWG > > >>> * > > >>> CORE > > >>> * > > >>> HTTPAPI > > >>> * > > >>> HTTPBIS > > >>> * > > >>> MASQUE > > >>> * > > >>> MOQ > > >>> * > > >>> NFSV4 > > >>> * > > >>> QUIC > > >>> * > > >>> RTCWEB > > >>> * > > >>> TAPS > > >>> * > > >>> TCPM > > >>> * > > >>> TSVAREA (to be renamed in accordance with the new area and an > > >>> updated description/purpose) > > >>> * > > >>> TSVWG (this may require a minor recharter, but would retain the > > >>> same competencies) > > >>> * > > >>> WEBTRANS > > >>> > > >>> > > >>> All other ART working groups would remain in place. > > >>> > > >>> The Transport Area Review Team (TSVART) would not change its > purpose, > > >>> scope, or operations. The Transport-focused AD would have primary > > >>> responsibility for managing this team. The HTTP Directorate would > > >>> also remain as-is and would be overseen by the HTTP-oriented AD of > > >>> the new area. Details about ARTART are TBD. > > >>> > > >>> *Transition Plan* > > >>> The IESG would request that NomCom not fill the open TSV AD > position > > >>> currently occupied by Martin Duke. Francesca Palombini and Zahed > > >>> Sarker would be the initial ADs for the new area. > > >>> > > >>> The IESG would also request that one of the two ART openings be > > >>> filled for only a one-year term, so as to stagger future ART AD terms. > > >>> > > >>> The new area’s AD terms would initially also end at the same time. In > > >>> the 2024-2025 NomCom cycle, the IESG would request that the > NomCom > > >>> fill two slots, one with transport expertise and one with HTTP > > >>> expertise, either of which could be a one-year term (but not both). > > >>> > > >>> *Next Steps* > > >>> Please submit any comments on this plan, including the > name/acronym > > >>> to iesg@xxxxxxxx <mailto:iesg@xxxxxxxx> <mailto:iesg@xxxxxxxx > <mailto:iesg@xxxxxxxx>>no later than 20 Sep 2023 > > >>> (anywhere on Earth). > > >>> > > >>> Concurrently, the IESG will work on updated job descriptions to be > > >>> transmitted to the NomCom. It anticipates this update will be > > >>> relatively minor. > > >>> > > >>> On Behalf of the IESG, > > >>> Martin Duke > > >>> Transport AD > > > > > > -- > > > Bron Gondwana, CEO, Fastmail Pty Ltd > > > brong@xxxxxxxxxxxxxxxx <mailto:brong@xxxxxxxxxxxxxxxx> > > > > > > > > > > > -- > > Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music- > bof.html <https://netdevconf.info/0x17/news/the-maestro-and-the-music- > bof.html> > > Dave Täht CSO, LibreQos
