ietf
[Top] [All Lists]

Re: IETF areas re-organisation steps

2015-01-15 05:24:27
Hi Ted, Alissa, all,

Hopefully-coherent ramblings inline.

On 13 Jan 2015, at 20:51, Ted Hardie <ted(_dot_)ietf(_at_)gmail(_dot_)com> 
wrote:

Hi Alissa,

Thanks for the notes below; though addressed to Robert, they address some of 
the issues I also raised.

To cut quickly to the chase, I think you have identified why you see the need 
for change here well, but not why the change identified is the right one.  
Your reasons on why the change is the right one seem to focus primarily on 
the IESG mechanics and recruiting.  They may be right, but if I may gently 
remind you, the areas are composed of much larger groups than the ADs and 
candidate ADs.  This reorganization needs to make sense for both the IESG and 
the broad set of participants and potential participants who use the Area's 
organizing principles to guide their work.

To use ELI5 style language, we could create simple descriptions like these:

The bit that works on how to determine what path flows use to get from one 
part of the network to another

The bit that works on how network elements behave

The bit that works on how network operators work.

The bit that works to protect the networks or flows from attackers

The bit that works on node configuration and bootstrapping

The bit that works on how to run the network on different kinds of links

The bit that works on how the flows behave on the network to each other

One can reduce the ELI5 "the bit that works on how the flows behave on the 
network to each other" to renaming the TSV area "Internet Congestion Control". 
That is, much of the area deals with the design, implementation, and 
maintenance of congestion controlled protocols, or with the operation of 
protocols that have an impact on congestion in the Internet (this explains why 
storage is in TSV). Now, there's a lot of work in RAI (split out of TSV) and in 
APP that also has impacts on congestion control, so at first glance the NAPP 
proposal makes sense.

Put another way, one of the purposes of TSV as an area is to make sure there is 
an AD or two who will stick a DISCUSS on any protocol that gets congestion 
control wrong in a way that might be harmful to the Internet, just as one of 
the purposes of the security area is to make sure there are two ADs who will 
stick a DISCUSS on any draft that will make the Internet less secure. The 
corresponding directorates, if all goes well, provide review early enough to 
make sure that it doesn't come to that.

This leads to the two reasons I'm skeptical of NAPP (or RAT or TAR... hm, has 
anyone proposed ART yet?) as proposed: one, I think we do need to make sure we 
don't lose the AD backstop on proposals that lead to uncontrolled 
packet-firehoses (which can be adequately ensured by making sure there's at 
least one, preferably two, CC experts as NAPP ADs). Two, even if we do combine 
these areas at the AD level, I think there is an argument that a NAPP 
directorate makes somewhat less sense than a TSV one.

The bit that works on how applications create flows and what those flows' 
exchanges should be.

Done that way, it does get hard to see why you would carve out "applications 
which are real time" from other applications.  The reasons we would have 
given when RAI was create might have included both external requirements 
(interop with the PSTN was a big driver) and the presumption of a signalling 
protocol being used to set up the flows (which was not present in most APPs 
work).  Combining all of applications work into a single area makes sense to 
me, given this description of our fundamental work.

But combining that with "the bit that works on how the flows behave on the 
network to each other" doesn't have the natural relationship _unless_ we 
believe that this behaviour is going to move more into the applications 
control.  

So I, for one, *do* believe that we want to move some control over transport up 
the stack, and to widen the interface between what we traditionally think of as 
layers 4 and 7 (I say "traditionally" because there are many (mostly non-IETF) 
layer 7 protocols that already roll their own transport when the commonly 
available ones don't meet their requirements). This widening of interfaces is 
the point of the TAPS WG, and of a chunk of the work in stackevo.

Gazing into my cloudy crystal call, in a world where TAPS has completed and is 
a success, and there is deployment of new transport protocols atop whatever 
shim layer or shim-layer-like-thing eventually falls out of the stackevo work 
(assuming one does), then the boundaries among APP, RAI, and TSV will have 
blurred to the point that a NAPP area makes organizational sense. I'm not 
convinced we're there yet.

If we were making this change because we wanted to move the Internet model in 
that direction, I would see a much more strong "why this change" than has 
been articulated to date.  But if we presume we have apps on one side of an 
interface and a small set of transports with fixed behaviour on the other, I 
don't think the proposal benefits the bit that works on how the flows behave 
on the network to each other nearly so much as it may seem.  Fundamentally, 
that work doesn't care what application emitted a flow if the applications' 
behaviour can't change the treatment of the flow (imagine how little TCP 
cares whether the flow contains XML or JSON....).  If we presume the apps can 
change the flow behaviour in fundamental ways, that changes.

I think the other bit pushing this, the number of willing and available 
candidates who would work as ADs in that area, is actually more of a question 
of AD workload.  I know at least two who declined because of the perceived 
workload, despite being deeply engaged in the work of the area.  I continue 
to believe that making changes which improve that aspect of IESG's 
organization is going to achieve more flexibility and sustainability than 
this sort of reorganization.

My two cents,

Ted Hardie


On Mon, Jan 12, 2015 at 3:50 PM, Alissa Cooper <alissa(_at_)cooperw(_dot_)in> 
wrote:
Robert,

I’d like to share a few thoughts on the proposal to merge the upper layer 
areas and then respond to your note below.

From my perspective, there are three issues that the merger helps to resolve:

1) Declining amount of work in the current APP area
2) Increasing amount of web-related work in the RAI area
3) Ongoing difficulty in finding multiple willing candidates to serve as TSV 
AD for the last 5 years at least

To my mind fixing that third item in particular should be a key goal of the 
re-org, and is the reason why leaving the areas largely as they are now, or 
just merging APP and RAI without changing anything about TSV, is not a good 
enough solution.

All of what I said above notwithstanding, it's clear that something does need 
to change about TSV. 

Furthermore, I think folks might be reading more into the three-merged-areas 
proposal than is really there. The main benefits I see from an organizational 
standpoint are threefold. First, in any given year we can ask the nomcom to 
help us fill in the expertise gaps that exist on the IESG without being stuck 
into rigid RAI/APP/TSV buckets. IMO, across those three areas there are 
certain areas of expertise that absolutely must be represented on the IESG 
(or where at least one AD has enough clue to appropriately leverage a 
directorate), e.g., congestion control, internationalization, web protocols, 
and job descriptions could be tailored to make sure those areas were always 
represented while being more flexible about what other expertise to seek out 
or accept.

Second, the ADs in the merged area can share WG responsibilities according to 
their areas of expertise (just like the out-of-area AD proposal, except 
confined to the three areas). There are plenty of groups in all three areas 
that could be just as capably shepherded by any of the other five currently 
seated ADs — why create artificial barriers to that? And it’s not obvious to 
me that this will require much more inter-AD conference calls or coordination 
as has been suggested elsewhere on the thread. Granted I’ve only been serving 
for less than a year, but as far as I can tell excessive inter-AD 
coordination is only necessary when some crisis arises, not on any sort of 
regular basis.

I think this could just as well point to a need to expand the out-of-area AD 
experiment across the RAI APP TSV boundaries as it does a need to create a 
super-area. I may be a little biased here, as the working groups I've been 
active and/or lurking in tend to straddle area boundaries: IPPM, LMAP, MILE, 
TAPS... none of these fit squarely into a single area, all have a fair amount 
of cross-area participation, all create pain for an area-centric scheduling 
algorithm. So maybe I'm less convinced of areas as an organizing principle (as 
opposed to directorates as a concentration of a coherent set of expertise and 
review effort, or the specific requirements for AD expertise as given to 
nomcom, both of which I think are good ideas).

Finally, the AD job can possibly obtain more appeal as something employers 
want to support because the job has a slightly more general purview. An AD 
mostly focused on transport might be able to pick up a web-focused group or 
two, making the time commitment easier to justify and more appealing to an 
employer.

On the other hand, this is a very good argument in favor of NAPP in the near 
term.

Cheers,

Brian