Re: Proposal for Consolidating Parts of the ART & TSV Areas

["touch@xxxxxxxxxxxxxx" <touch@xxxxxxxxxxxxxx>]

For better or worse, a lot of the IETF is based on naming from the OSI reference model.

“Transport” alone is often shorthand for “transport layer in the OSI model”, which his fairly well defined.

Picking a new name is the opposite of the point of a reference model. The “reference” part is what we’re doing - we refer to the model for the name.

If we need a new name because the grouping doesn’t match that of the OSI model, sure.

But then we need to consider two things:

- does the new group have anything in common that a name would indicate (e.g., more clearly than transport layer?)

- would the expertise needed to manage the WGs in that group be more readily identifiable than the current one?

I don’t see this new grouping helping anything but the org chart of the IETF, while making finding ADs more difficult if not at least more confusing.

Joe

—

Dr. Joe Touch, temporal epistemologist

www.strayalpha.com

On Sep 18, 2023, at 6:52 AM, Scharf, Michael <Michael.Scharf@xxxxxxxxxxxxxxx> wrote:

One minor comment only regarding the proposed naming:

 

The word “transport” is used inside the IETF in different ways. Most notably, in RTG the word “transport” could refer to an optical network (“transport network”). In addition, other terms such as “packet transport” may also be used in such context. In contrast, terms such as “transport protocol” or “transport layer” traditionally refer to TCP, UDP, etc., as introduced e.g. in RFC 1122.

 

I believe there has been some confusion about these different meanings of “transport” in the IETF in the past, e.g., in IETF last calls, since the TSV and RTG communities are mostly disjoint. 

 

I am not a native speaker. As far as I can tell, “Web and Application Transport” would be unambiguous, but this term might be very application-centric. In “Transport and Web Applications”, transport protocol topics would be more prominent, but it could perhaps be a bit less clear what the term “transport” refers to. There might be other alternatives, e.g., including the term “transport protocol”.

 

If a new name is needed, it would make sense to pick it carefully.

 

Michael

 

 

From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of Martin Duke
Sent: Friday, September 8, 2023 4:44 PM
To: tsv-chairs@xxxxxxxx; art-chairs@xxxxxxxx; ietf@xxxxxxxx; IETF-Announce <ietf-announce@xxxxxxxx>; wg-chairs@xxxxxxxx
Subject: Proposal for Consolidating Parts of the ART & TSV Areas

 

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.

 

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 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