Re: IETF areas re-organisation steps

[Brian Trammell <[e-mail]>]

Hi Ted, Alissa, all,

Hopefully-coherent ramblings inline.

> On 13 Jan 2015, at 20:51, Ted Hardie <[e-mail]> 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 <[e-mail]> 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