Re: IETF areas re-organisation steps

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

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.

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.
>
> 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.
>
> 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.
>
> All of these benefits concern the role of the AD vis a vis the area, not
> the other aspects of “areaness” (scheduling, directorates,
> DISPATCH/TSVWG/APPSAWG, etc.). That’s why I don’t think these other aspects
> need to fundamentally change.
>
> More below.
>
> On Jan 6, 2015, at 1:15 PM, Robert Sparks <rjsparks(_at_)nostrum(_dot_)com> 
> wrote:
>
> > I'd like to focus for a moment on another part of Jari's original
> message.
> > On 12/25/14 1:16 PM, Jari Arkko wrote:
> > > Dear Community:
> > >
> > > In October, we let you know that we would be coming up with some
> proposals
> > <trim/>
> > > III.  MERGING OF UPPER LAYER PROTOCOL AREAS
> > <trim/>
> > > DISPATCH, TSVWG, and APPSAWG
> > > would continue to function much as they currently do.
> > I see this as problematic.
> >
> > RAI is currently operating following RFC 5727, where dispatch is
> defined. It is a consensus document describing how the area decided to
> behave. It does not seem right to say _parts_ of the new combined area will
> follow that consensus. How are you planning to avoid "well, that's the APPs
> part of <newareaname> and we do things like this over there”?
>
> Will it really be so much harder to avoid than it already is? We haven’t
> merged the areas yet, and yet we just went through this exact debate with
> webpush. DISPATCH is the mechanism we use for dispatching real-time
> application work — I don’t see the need to change that. There is fuzziness
> at the edges now, and there will be with a merged area too. Nothing we do
> organizationally will rid us of the fuzziness.
>
> > If you're not planning to avoid that, then it's not really clear what
> problem the organization is really going to solve - the resulting ADs will
> have to behave the same regardless of their label.
> > The arguments in the past about whether a group belonged in transport or
> RAI, while occasionally silly, were _usually_ helpful in clarifying the
> problem that the proposed group was starting to circle around. Some of the
> comments from active TSV members have touched on aspects of this already.
> As proposed, we will lose that tension, and I think we'll end up with
> muddier charters as a result. (There are other ways to preserve that
> tension, of course, but we would need to explicitly put them in place).
>
> I have not personally found the “which area will this group live in?”
> discussions to be useful. And honestly there are lots of existing groups
> where the rationale for having them in their current areas is just as
> weak/strong as the rationale for having them in other areas. We’ll end up
> with muddier charters if the people involved in the chartering let them
> become muddy, not if they have different area labels on them.
>
> > If the thought of developing something like dispatch-related parts of
> RFC 5727 to describe how a new combined area (whatever its ingredients)
> plans to operate seems onerous, or too heavyweight, I'd take it as a
> warning that we're headed for something unpleasant, or that has no real
> effect on organization, improving the efficiency of making standards,
> making recruiting ADs easier, or reducing AD load.
>
> It’s not that it’s too onerous or heavyweight, it’s that it’s unnecessary.
> DISPATCH works well now. The three items I listed above are not working
> well now, or could be improved. The merger proposal tries to fix the things
> that are broken and leave the things that are working in their current
> state.
>
> Alissa
>
> > Rather than that, I hope we could fairly quickly come up with a good
> description of how such a combined area would behave, and I hope that's not
> "just like the pieces do now".
> > RjS