> >> The Transport Area intersects most frequently with > Internet Area, the > >> Applications Area, the RAI Area, the Security Area, and the > > IRTF ICCRG research groups. Cross-area expertise in any of > those Areas > > would be particularly useful. > > > > s/IRTF ICCRG research groups/IRTF research groups such as ICCRG/ ? > > I don't see the need for this. ICCRG is almost > joined-at-the-hip, but interaction with other IRTF groups is > the exception.
these days there is also ICNRG, which has "Congestion control, QoS approaches" in its charter, and there are recent coding discussions in IRTF, which are not entirely unrelated to TCP(M) as well... This is why I could imagine that a future AD might have to interact with RGs other than ICCRG, too. > >> Current and new transport work includes... > > > > TCPM is currently pretty busy with "extensions to existing > transport > > protocols". And not all of them are about congestion signaling or > > multipath ;) > > True; but this is not text we expect to revise every year. > TSV ADs are not expected to have expertise in the work of > _every_ TSV WG. True, but "extensions to existing transport protocols" is more generic than any specific extension that is this year's hype topic of the community. > >> A Transport AD should have a broad understanding... > > > > At least TCPM also has to be aware of middleboxes other > than NATs and > > firewalls, including gateways that mess up TCP options, all > kinds of > > load balancers, transparent caches, etc. > > The WG needs such expertise, but does the AD need it? > > > For instance: s/NATs and firewalls/middleboxes such as NATs and > > firewalls/ ? > > For myself, I'd prefer not to require middlebox expertise > of TSV ADs. > > > I also have the impression that TSV work is often related > to operation > > system design and implementation issues. There is a lot of > literature > > on the principles of congestion control. Unfortunately, > there is much > > less literature that provides insight whether a given RFC > can indeed > > be implemented robustly in a production TCP/IP stack or a > real network > > element... > > True, but we need to make the NOMCOM's job possible. IMHO, > we shouldn't ask TSV ADs to be experts on implementation issues. I have not said that we need an "expert". Those may be rare, indeed. Michael
