Joe Touch <[email protected]> wrote: > On 6/1/2015 10:44 PM, Martin Stiemerling wrote: >> >> The current text aims at keeping the balance between naming a number of >> must haves, but is deliberately not going into more details. >> >> Is there a good term that would cover most of the points, i.e., the text >> says core transport topics, but indeed lacks an item that covers the >> transport 101 points, like MTU issues. > > I really wish there were. My point is that "transport" is more than > "congestion and flow control".
Most assuredly it does. > To say the above in a more generic format: > > - connection state coordination > - interaction with path properties > - interaction of with router data plane > - error detection and recovery > - data boundary coordination This describes (in general terms) what TSV WGs do (and does so pretty well). My point (beyond making the NomCom's job possible) is that no TSV _participant_ needs to know all these things: even the things s/he does need to know can generally be learned while participating in the WG. Surely an AD doesn't need to know _everything_... > The current list states the same concept too many different ways and can > be condensed: I don't agree that such condensation will help the NomCom. (Indeed, the NomCom "need-to-know" list doesn't cover how to evaluate expertise in all topics -- it's more like "who to ask"... > WAS: > - congestion, control loops and hysteresis, > flow control, queuing and latency > MAYBE: > - congestion and flow control IMHO, bad idea to condense these. "congestion" by itself is too broad a topic -- what is it about congestion we're asking ADs to know? (I've been alarmed to find how little the average IETF participant understands about hyteresis.) Likewise, "queuing and latency" are moving targets which it seems helpful to have ADs try to follow. I wouldn't ask for _much_ expertise there; but these are topics where outdated information may be less than helpful... > WAS: > - transport connection and reliability issues > IMO SHOULD BE: > - connection state coordination > - error detection and recovery This may be an improvement. We generally think in terms of state transitions at the two ends of a connection -- though I'm not certain that _all_ transports must work that way... The details of error detection can overwhelm _any_ of us. I really don't know what level of knowledge of error detection is reasonable to expect of ADs. > WAS: > - interactions with the network layer, > the application layer, and middleboxes. > (IMO OK) (I'd rather let sleeping dogs lie...) > The full list, IMO, should be (in no particular order): > > - connection state coordination > - interaction with path properties > - interaction of with router data plane > - error detection and recovery > - data boundary coordination > - congestion and flow control > - interactions with the network layer, > the application layer, and middleboxes I truly worry that expecting all that will be too severe a limit on available candidates. Remember that ADs aren't expected to do the work: they're expected to manage the WGCs and coordinate discussion of issues that arise during IETF-wide LastCall. They will have access to expertise in the Area Directorate -- they need to know what questions to ask; not the answers to all those questions. (And conversely, I'm not convinced that a NomCom reading that list would actually ask candidates about, e.g., hysteresis or latency.) > IMO that should appear in one paragraph, not split across two paragraphs > that are not adjacent. No strong opinion there: NomComs have proven very skilled at reading these job descriptions carefully. > Finally, the last paragraph should compress down the congestion/flow > control issues to one item (not 4) and should also specifically list MTU > interactions and ICMP interactions. Sounds like we're going to disagree there. I see nothing wrong with four items within "congestion/flow-control". But I'm ready to agree that "MTU interactions" is probably worth adding. I honestly don't know whether it's good to expect expertise in "ICMP interactions". That is a moving target: granted, we've ignored it more often than we should; but I believe implementers react to these problems during testing -- thus I wouldn't require ADs to field such issues. Perhaps I'm more sensitive than I need to be about limiting the field of candidates. But I've watched NomComs struggle for too long to quietly agree to increasing the requiriments for Transport ADs. And I've watched the chaos which ensues when they fail to find a nominee to recommend. -- John Leslie <[email protected]>
