ietf
[Top] [All Lists]

Re: Appointment of a Transport Area Director

2013-03-05 08:17:47
<inline>
----- Original Message -----
From: <l(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)uk>
To: <daedulus(_at_)btconnect(_dot_)com>; 
<martin(_dot_)stiemerling(_at_)neclab(_dot_)eu>
Cc: <hartmans-ietf(_at_)mit(_dot_)edu>; <ietf(_at_)ietf(_dot_)org>
Sent: Tuesday, March 05, 2013 12:53 PM

Ah, the 'but security, unlike transport,  is actually important'
argument.

Having seen subscribers to that philosophy unsuccessfully attempt to
design
transport protocols (and raise the MD5 issue repeatedly, because it's
considered a security issue, and they're at home with security), I would
argue
that there is a lack of appreciation and understanding  of the nuances
of
transport protocol issues in the IETF. Reliability, implications of the
end-to-end protocol, feedback loops...
<snip>
But watching security people make a hash of transport protocol
design really isn't fun. That and the lack of transport expertise
concerns me.

<tp>
We are not talking of transport protocol design - SCTP, DCCP,  ... -
but of Congestion Control design.  The question is can we do with a
Transport Area Director whose congestion control skills are limited; I
am suggesting we can, because of all the work over the years in
congestion control and the relative stability of the topic.

Transport matters, congestion control matters, I am just suggesting that
the latter is not developping so much that we need an AD who is abreast
of the research in it.

Tom Petch

Lloyd Wood
http://sat-net.com/L.Wood/dtn


Congestion control is essential else we have congestive collapse,
which
I have had to find and fix in my time; but I am positing that for most
of the IETF, congestion control is a solved topic and little expertise
is needed, in contrast to Security which is for ever changing (SHA2 or
SHA3 or will MD5 still suffice?).  Yes, a high-level of skill exists,
especially in the ICCRG (and I struggle to follow it) but I wonder if
we
need that skill in the IETF ie a basic familiarity with what TCP
offers
and UDP does not will serve most of our work.