Subject: Feedback request: The desired expertise of a Transport Area Director

From: Martin Stiemerling <[email-masked]>
Date: Thu, 11 Jul 2013 21:38:32 +0200

Hi all,

The IESG makes a write-up about the desired expertise of Area Directors 
in general and also for each area. This write-up is sent to the NOMCOM.

You can find the write-up for the last round here:
https://www.ietf.org/group/nomcom/2012/iesg-requirements

The desired expertise was also discussed during the Transport Area Open 
Meeting at the IETF-86 meeting in Orlando. Please check the meeting 
minutes for the feedback the community provided:
http://www.ietf.org/proceedings/86/minutes/minutes-86-tsvarea

There is now a new write-up for the upcoming deliberations of the 
NOMCOM, taking the comments received in the IETF-86 area meeting into 
account:
http://trac.tools.ietf.org/group/iesg/trac/wiki/TransportExpertise

The general part, as well as the write-ups for the other areas, is 
available here:
http://trac.tools.ietf.org/group/iesg/trac/wiki/DesiredExpertise

Please note that these write-ups are reflecting the view of the IESG and 
not of the NOMCOM or the community at large.

However, Spencer and I are requesting your feedback about the Transport 
Area Director part.

Please send your feedback either to the TSV-Area list, directly to 
Spencer and/or me, or to the IESG until

      ***Thursday, 2013-07-18 10am EDT***

This is the deadline for the IESG to approve what the IESG sends to NOMCOM.

You can always send feedback about the desired expertise to the NOMCOM!
After that date/time, please send feedback about any of the IESG 
position descriptions to the NOMCOM.

Your Transport ADs

   Spencer and Martin

-- 
[email-masked]

NEC Laboratories Europe
NEC Europe Limited
Registered Office:
Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB
Registered in England 2832014

---

From: John Leslie <[email-masked]>
Date: Thu, 11 Jul 2013 22:17:27 -0400

Martin Stiemerling <[email-masked]> wrote:
>... 

   The IESG wants to finalize their input to NOMCOM on July 18. There
will be an additional period for comments _after_ it goes to NOMCOM...

   But this is worth discussing on this list now. For at least the last
four years, NOMCOM has had serious trouble finding candidates that
meet the desired expertise.

   For now I'll concentrate on this paragraph:
] 
] A Transport AD should have a broad understanding of core end-to-end
] transport topics such as congestion control, flow control, real-time
] transport protocols, NATs and firewalls, and related topics such as
] storage protocols. It is not necessarily important to be an expert
] in any of these, as it is much more important to be knowledgable in
] the principles of these transport topics, such as congestion control
] and congestoin management, Intserv and Diffserv. A Transport AD
] should have good relationships with the topic experts in the
] Transport area and also other areas, which in turn requires good
] soft skills.

   This is already an improvement over last year's version, which
listed a number of specifics which I, at least, had suggested were
no longer required or of limited duration.

   But I direct everyone's attention to David Harrington's message
about the problems he faced as Transport AD:

http://www.ietf.org/mail-archive/web/ietf/current/msg77860.html

   The whole post is well worth reading, but I particularly note:
] 
] You'll need enough understanding of the TSV issues to be able to
] spot bad transport-related decisions in documents coming from
] elsewhere in the IETF. You (and your co-AD) are effectively the
] reviewer of last resort for TSV issues. If you don't understand
] control loops, congestion control techniques, etc., you will
] NEED to rely on your directorate for assistance in this role.

   I suggest that "understand control loops" deserves specific
mention in the desired expertise. Personally, I'd add "hysteresis
in control loops".

   "Congestion control techniques" is definitely something the NOMCOM
should look for candidates to understand. But to me, that wording is
open-ended; and we don't need an expert on all such techniques.

   I think we need someone who understands the basic "additive
increase; multiplicative decrease" mechanism of vanilla TCP; but
that other _control_ techniques are too varied -- a Transport AD
will need to have Directorate members help with those.

   I'd like to see some mention of understanding "congestion
signaling". We've evolved quite a bit from the days when packet
drop was the only congestion signal. ECN is in active, if limited,
use. There are a number of delay-based indicators now: mostly
inferring queueing delay from transit time, but recently actually
measuring time-in-queue (such as CoDel and PIE). All of these
signals involve trade-offs, if not outright guessing; so we
shouldn't look for expert-level understanding, but a basic
understanding of congestion signals seems important to me.

   David Harrington dwells at length on his experience with the
Transport Directorate. We might tweak the last sentence of the
paragraph I quoted from the desired expertise:
" 
" A Transport AD should have good relationships with the topic
" experts in the Transport area and also other areas, which in turn
" requires good soft skills.

to indicate actual management skills in keeping the Directorate
functioning well.

   As for the other items listed in the desired expertise:
" 
" topics such as congestion control, flow control, real-time
" transport protocols, NATs and firewalls, and related topics
" such as storage protocols.

I'd really prefer that others comment first on what level of
understanding we should ask for. They are all interesting (though
I personally regard NATs as damage to route around), but I don't
know how essential they are to a Transport AD. Recall that we
_need_ to make the NOMCOM's job possible!

--
John Leslie <[email-masked]>

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 15 Jul 2013 15:27:57 +0000

> There is now a new write-up for the upcoming deliberations of 
> the NOMCOM, taking the comments received in the IETF-86 area 
> meeting into
> account:

For what it is worth...

>    The Transport Area works on mechanisms related to end-to-end data transport as well as technologies for network storage and peer-to-peer applications. Transport protocols support Internet applications and services that exchange potentially large volumes of traffic at potentially high bandwidths.

I wonder if the first sentence indeed includes CDNI, IPPM, and possibly new AQM work?

For instance, what about "The Transport Area works on end-to-end transport protocols, mechanisms related to performance and congestion control, as well as technologies for network storage, content delivery, and peer-to-peer applications" ?

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

>    Current and new transport work includes congestion signaling and reporting, QoS and reservation signaling, DiffServ? and congestion control for unresponsive flows, NAT regularization and specification, storage protocols for the Internet, peer-to-peer streaming, performance metrics for Internet paths, experimentation with congestion control schemes developed in the IRTF, multipath extensions to existing transport protocols, and congestion control algorithms for interactive real time media.

Well, TCPM is currently pretty busy with "extensions to existing transport protocols". And not all of them are about congestion signaling or multipath ;)

>    A Transport AD should have a broad understanding of core end-to-end transport topics such as congestion control, flow control, real-time transport protocols, NATs and firewalls, and related topics such as storage protocols. It is not necessarily important to be an expert in any of these, as it is much more important to be knowledgable in the principles of these transport topics, such as congestion control and congestoin management, Intserv and Diffserv. A Transport AD should have good relationships with the topic experts in the Transport area and also other areas, which in turn requires good soft skills.

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. For instance: s/NATs and firewalls/middleboxes such as NATs and firewalls/ ?

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

Editorial nit: s/congestoin/congestion/

Michael

>    Some topics in transport mechanisms have strong ties to the research community, therefore some research background can be very helpful.
>
>    Together, the two Transport ADs are expected to understand how transport technologies (layer 4) interact with IP layer technologies and protocols (layer 3) technologies, and with the end-to-end aspects of various applications and application-layer protocols (layer 7).

---

From: John Leslie <[email-masked]>
Date: Mon, 15 Jul 2013 12:17:13 -0400

Scharf, Michael (Michael) <[email-masked]> wrote:
> [Martin Stiemerling <[email-masked]> wrote:] 
>> 
>> The Transport Area works on...
> 
> what about "The Transport Area works on end-to-end transport protocols,
> mechanisms related to performance and congestion control, as well as
> technologies for network storage, content delivery, and peer-to-peer
> applications" ?

   This strikes me as reasonable.

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

   I don't see the need for this. ICCRG is almost joined-at-the-hip,
but interaction with other IRTF groups is the exception.

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

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

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 15 Jul 2013 16:42:16 +0000

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

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

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

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Jul 2013 09:50:44 -0700

FWIW, I don't think transport == congestion control.

There are a lot of other issues in connection semantics, service IDs, 
etc. that are integral to the transport layer which are equally critical.

And I don't think a transport AD needs to be an expert on this, but they 
cannot rely on TSVDIR to point out key issues or concerns either; TSVDIR 
isn't on every IESG telechat, nor attending every IESG meeting at the IETF.

TSVDIR aren't "guide dogs" for the (transport-)blind. ;-)

We can help dig into details, but if the AD doesn't know to put the 
brakes on or raise an issue, by the time we get a doc it will be far too 
late.

Joe

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 15 Jul 2013 12:18:53 -0500

On 7/15/2013 11:17 AM, John Leslie wrote:

I might have opinions about the details, but want to strongly encourage 
people to take John's words to heart:

    "True, but we need to make the NOMCOM's job possible."

What I'd like to see, is a description that some reasonable number of 
nominees are willing to be considered against.  If some willing nominees 
have additional areas of expertise and experience that would be helpful 
for a TSV AD, great -and please tell the Nomcom that. But Nomcom need to 
start with a list of willing nominees that they can ask for feedback on.

Spencer

---

From: Jim Gettys <[email-masked]>
Date: Mon, 15 Jul 2013 13:42:44 -0400

> FWIW, I don't think transport == congestion control.

Joe is exactly correct about this.

>
> There are a lot of other issues in connection semantics, service IDs, etc.
> that are integral to the transport layer which are equally critical.
>

Another example, a large part of fq_codel's gains are over the sort of flow
queuing it does, rather than congestion control. Our experience is
congestion control is necessary, but not sufficient to deal with
bufferbloat (see my recent blog article at:
http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/
).

> We can help dig into details, but if the AD doesn't know to put the brakes
> on or raise an issue, by the time we get a doc it will be far too late.

I don't think the IETF can find people who know everything in depth (the
person doesn't exist, probably); but nodding familiarity with a wide range
of the issues is desirable.
                            - Jim

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Jul 2013 10:49:13 -0700

On 7/15/2013 10:42 AM, Jim Gettys wrote:
...
> person doesn't exist, probably); but nodding familiarity with a wide
> range of the issues is desirable.
>                              - Jim

IMO, the paucity of candidates isn't just due to depth or breadth of 
knowledge. The intersection of the following is vanishingly small:

		- deep knowledge about cong control
		- deep knowledge about non-CC transport issues
		- supported to participate in the IETF
		- supported to travel to IETF meetings
		- willing to serve as AD

Joe

---

From: "Black, David" <[email-masked]>
Date: Tue, 16 Jul 2013 00:45:28 -0400

> start with a list of willing nominees that they can ask for feedback on.

I guess I ought to introduce myself, although I see that Dave Harrington's
already gotten that off to a fine start in his description of his experiences
as a TSV AD ...

 TSV has responsibility for storage protocols that need to operate over the
 Internet. These include NFS, and Internet interfaces for SCSI and Fibre
 Channel. All of these were developed elsewhere. Sun, of course, developed
 NFS and donated version 4 for standardization. SCSI and Fiber Channel are
 standardized by other SDOs, and we develop the interfaces to the Internet
 (iSCSI, FCIP, etc.), and provide feedback to the SCSI and FC SDOs. The IETF
 standards for these run in the 300-page document range, and are largely
 unrelated to other IETF work. The chairs and the editors really understand
 their stuff, and TSV ADs can generally just "let them run" - until they
 submit their 300-page documents for IESG review.

That sure sounds like it includes me, especially as I just asked Martin to
(finally) send the 300+ page storm WG draft that consolidates and revises
the iSCSI specs off to the RFC Editor ;-).

I've also done quite a bit of other transport work, including QoS and
congestion control (RFCs in both topic areas), plus the things I ride
herd on as a tsvwg chair, as well as having multiple published RFCs in
other IETF areas, e.g., Security.  So, looking at the description (which
I agree is already much improved over last year's), with an eye to how
it fits me, the following two paragraphs appear to be the core of the
matter - description of expected technical background/expertise:

-----------------------

    A Transport AD should have a broad understanding of core end-to-end transport topics such as congestion control, flow control, real-time transport protocols, NATs and firewalls, and related topics such as storage protocols. It is not necessarily important to be an expert in any of these, as it is much more important to be knowledgeable in the principles of these transport topics, such as congestion control and congestion management, Intserv and Diffserv. A Transport AD should have good relationships with the topic experts in the Transport area and also other areas, which in turn requires good soft skills.
-----------------------

The first paragraph is scary - I see ten listed areas of activity, about
half of which I can reasonably claim some expertise in.  As John Leslie
noted:

> TSV ADs are not expected to have expertise in the work of _every_ TSV WG.

The second paragraph is much better, so I'd suggest adding a disclaimer
sentence at the end of the first paragraph to capture John's point and
help focus attention on the second paragraph.  For example:

 Transport ADs are not expected to be experts on all or even most of
 these topics, but rather to work well with the Transport Area participants
 who are, and to have enough familiarity to exercise their own good judgment
 about what should be done and why.

In the second paragraph, I foresee problems with "and related topics such
as storage protocols".  While I fit those words rather well ;-), I'm a bit
unusual in that regard - Dave Harrington's comment (quoted above) on
storage protocols is apt:

	The IETF standards for these ... are largely unrelated to other
      IETF work.	The [storage] chairs and the editors really understand
	their stuff, and TSV ADs can generally just "let them run".

As I said in the tsvarea meeting in Orlando, I've never had to turn any of
the many TSV ADs whom I've worked with into SCSI, Fibre Channel or storage
experts - both they and the storage communities in the WGs that I've chaired
are better off for that not having been necessary.  I might change those
words to "and related topics such as application use of transport protocols".
That would involve considerations around topics such as head-of-line
blocking and multiple parallel transport connections - that overall topic
area applies to transport-related issues in WGs such as core and httpbis.

Thanks,
--David
p.s. I'd include Diffserv in the description, as there is enough active
diffserv-related work, at least at the moment.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Martin Stiemerling
> Sent: Thursday, July 11, 2013 3:39 PM
> To: [email-masked]
> Subject: Feedback request: The desired expertise of a Transport Area Director
> 
> Hi all,
>

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 16 Jul 2013 15:52:00 -0500

Thanks to everyone who provided feedback on our proposed job description.

After reading through the excellent suggestions, your ADs did a more 
extensive editing session, resulting in what you see below. Our goal was 
to make Nomcom's job (and, of course, the IAB-as-confirming-body's job) 
possible, and we tried to distinguish more clearly between

- stuff ADs have to know, and
- stuff ADs have to be able to find someone who knows, and understand 
what they're saying about it

We need to provide our description to the just-seated Nomcom (if you'll 
be serving on this Nomcom, congratulations, and best wishes) by 
something like the morning (CDT) of Thursday, July 18.

We're open to comments until we hand the description over, but if you're 
reading this after we've sent it to Nomcom, please let Nomcom know about 
your feedback on the job description itself.  (You don't have to 
convince us, you just have to convince Nomcom :-)

Again, thank you, and if your travel plans include IETF 87, we'll see 
you in Berlin.

Spencer and Martin

2013 Transport Expertise

The Transport Area works on mechanisms related to end-to-end data 
transport as well as technologies for network storage, content 
distribution networks, and peer-to-peer applications. Many transport 
protocols support Internet applications and services that exchange 
potentially large volumes of traffic at potentially high bandwidths.

A Transport AD should have a broad understanding of core end-to-end 
transport topics such as congestion control, congestion signaling and 
congestion management, control loops and hysterisis, flow control, and 
middleboxes such as NATs and firewalls. Transport ADs are not expected 
to be experts on all or even most of these topics, but rather to work 
well with the Transport Area participants who are, and to have enough 
familiarity with the principles involved to exercise their own good 
judgment about what should be done and why.

A Transport AD should have good relationships with the topic experts in 
the Transport area, including members of the Transport Area Directorate 
and RSVP Directorate, and with topic experts in other areas, and this 
requires good soft skills, including the ability to maintain these 
directorates.

Together, the two Transport ADs are expected to understand how transport 
technologies (layer 4) interact with IP layer technologies and protocols 
(layer 3) technologies, and with the end-to-end aspects of various 
applications and application-layer protocols (layer 7).

Together, the two Transport ADs are expected to effectively charter, 
manage and review current and new transport work, indcluding congestion 
signaling and reporting, QoS and reservation signaling, DiffServ/Intserv 
and congestion control for unresponsive flows, NAT regularization and 
specification, storage protocols for the Internet, peer-to-peer 
streaming, performance metrics for Internet paths, experimentation with 
congestion control schemes developed in the IRTF, unicast and multipath 
extensions to existing transport protocols, and congestion control 
algorithms for interactive real time media.

The Transport Area intersects most frequently with Internet Area, the 
Applications Area, the RAI Area, the Security Area, and 
Transport-related IRTF research groups, especially ICCRG. Cross-area 
experience in any of those Areas would be particularly useful.

Because many Transport working groups have strong ties to the research 
community, some research background can be very helpful.

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 Jul 2013 15:40:00 -0700

Hi, Spencer,

On 7/16/2013 1:52 PM, Spencer Dawkins wrote:
> middleboxes such as NATs and firewalls.

As I said, this is insufficient. IMO, it focuses far too much on the 
congestion issue and not enough on reliability, connection issues, 
network layer interactions, and application layer interactions.

I would suggest rewording it to avoid repeated reference to congestion, 
and include these other issues:

A Transport AD should have a broad understanding of core end-to-end
transport topics such as congestion, control loops and hysteresis, flow 
control, reliability issues, connection issues, and interactions with 
the network layer, the application layer, and middleboxes.

---

From: Jim Gettys <[email-masked]>
Date: Tue, 16 Jul 2013 20:38:33 -0400

On Tue, Jul 16, 2013 at 6:40 PM, Joe Touch <[email-masked]> wrote:

> congestion issue and not enough on reliability, connection issues, network
> layer interactions, and application layer interactions.
>

Yes.  I must agree with Joe again, having written in my blog about the
misconceptions that many networking engineers and researchers have about
applications last week.

> control, reliability issues, connection issues, and interactions with the
> network layer, the application layer, and middleboxes.
>

There are two words missing entirely that are key:

Queuing and, even more important, Latency

                                        - Jim

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 16 Jul 2013 21:13:01 -0500

On 7/16/2013 7:38 PM, Jim Gettys wrote:
>
>
>
> On Tue, Jul 16, 2013 at 6:40 PM, Joe Touch <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I would suggest rewording it to avoid repeated reference to
>     congestion, and include these other issues:
>
>
>     transport topics such as congestion, control loops and hysteresis,
>     flow control, reliability issues, connection issues, and
>     interactions with the network layer, the application layer, and
>     middleboxes.
>
>

Thank you both, Joe and Jim, for quick and actionable suggestions!

Spencer

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 17 Jul 2013 04:56:55 +0000

I understand technical skills are very important, but they comprise most of the list. There is mention of "and this requires good soft skills" but I wonder if we can say something more concrete?

How about "management experience" ? Without detracting from the technical requirements, in my opinion given an AD role soft skills are as important. ADs should have "strong soft skills".  This is a good opportunity to balance things a bit more.

thanks,

Reinaldo

________________________________
From: [email-masked] [[email-masked]] on behalf of Spencer Dawkins [[email-masked]]
Sent: Tuesday, July 16, 2013 7:13 PM
To: Jim Gettys
Cc: Martin Stiemerling; [email-masked]
Subject: Re: Feedback request: The desired expertise of a Transport Area Director (updated)

On Tue, Jul 16, 2013 at 6:40 PM, Joe Touch <[email-masked]<mailto:[email-masked]>> wrote:
I would suggest rewording it to avoid repeated reference to congestion, and include these other issues:

A Transport AD should have a broad understanding of core end-to-end
transport topics such as congestion, control loops and hysteresis, flow control, reliability issues, connection issues, and interactions with the network layer, the application layer, and middleboxes.

Spencer

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 17 Jul 2013 07:52:24 -0500

On 7/16/2013 11:56 PM, Reinaldo Penno (repenno) wrote:
> I understand technical skills are very important, but they comprise 
> most of the list. There is mention of "and this requires good soft 
> skills" but I wonder if we can say something more concrete?
>
> How about "management experience" ? Without detracting from the 
> technical requirements, in my opinion given an AD role soft skills are 
> as important. ADs should have "strong soft skills".  This is a good 
> opportunity to balance things a bit more.

Hi, Reinaldo,

Although Martin included this pointer to a "Generic Expertise" write-up 
in his earlier e-mail asking for feedback, I didn't include it in the 
e-mail you replied to (sorry!)

http://trac.tools.ietf.org/group/iesg/trac/wiki/GenericExpertise

We're thinking that the "Generic Expertise" section captures much of 
what we needed to say about the needed "soft skills" for TSV ADs, but 
your note reminded us that the TSVAREA Nomcom discussion at IETF 86 ALSO 
skipped over the "Generic Expertise" material, so we're adding a 
back-reference to "Generic Expertise" in the TSV description.

So, thank you for sending your note - it had an effect.

Spencer and Martin

> thanks,
>
> Reinaldo
>
> ------------------------------------------------------------------------
> *From:* [email-masked] [[email-masked]] on 
> behalf of Spencer Dawkins [[email-masked]]
> *Sent:* Tuesday, July 16, 2013 7:13 PM
> *To:* Jim Gettys
> *Cc:* Martin Stiemerling; [email-masked]
> *Subject:* Re: Feedback request: The desired expertise of a Transport 
> Area Director (updated)
>
>>     transport topics such as congestion, control loops and
>>     hysteresis, flow control, reliability issues, connection issues,
>>     and interactions with the network layer, the application layer,
>>     and middleboxes.
>>
>>