Subject: Re: IETF areas re-organisation steps

From: Robert Sparks <[email-masked]>
Date: Tue, 06 Jan 2015 15:15:07 -0600

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"? 
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).

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.

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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 6 Jan 2015 16:43:27 -0600

Hi, Robert,

On Jan 7, 2015 5:15 AM, "Robert Sparks" <[email-masked]> wrote:
> 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"? 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.

Speaking as 1/15th of the problem, thanks for mentioning this during the
discussion.

I can confirm that the IESG is aware of RFC 5727 and the definition of
DISPATCH therein.

I have asked that the IESG identify any other changes to active BCPs that
would be required with various organizational changes being discussed.

I would offer that the IESG has
https://datatracker.ietf.org/doc/draft-dawkins-iesg-one-or-more/ on this
week's telechat agenda, which did a full IETF consensus call about changing
one word in a definition that appears in two key process BCPs, as evidence
that we take the concern you're raising here seriously.

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

Thanks for the background. As you would remember, I was a fan of the
DISPATCH concept when it was put in place, and ended up chairing two
working groups that were DISPATCHed (MARTINI and SIPCLF), but I wasn't as
involved in RAI after joining the IAB in 2010. So, that's helpful for me.

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

Indeed. Indeed.

Please keep that feedback coming in.

Spencer

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 12 Jan 2015 15:50:24 -0800

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 <[email-masked]> wrote:

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

---

From: Ted Hardie <[email-masked]>
Date: Tue, 13 Jan 2015 11:51:56 -0800

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 <[email-masked]> 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.
>
> 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.
>
> 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.
>
> problem the organization is really going to solve - the resulting ADs will
> have to behave the same regardless of their label.
> >
> 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.
>
> >
> 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
>
> >

---

From: Robert Sparks <[email-masked]>
Date: Tue, 13 Jan 2015 14:50:43 -0600

Thanks for the response, Alissa. Some comments inline.

> 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 gi…
So it's just a matter of circumstance that you're not throwing SEC into 
the bucket. Nothing special about TSV other than "it's been hard to 
recruit ADs for that area"?
>
> 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?
That seems to argue for no areas at all, more than it does this 
particular subsetting.
> 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.
>
Again, that seems to be an argument for getting rid of the areas, and 
isn't specific to this particular subset of areas.
> Will it really be so much harder to avoid than it already is?
It will be different. I can't say "so much harder", but I can say that 
you're trading one established set of ways for structuring discussions 
off for some you'll have to invent. It may well be you find better ones.
> 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.
>
I wish you had focused some of your response right here. I think the 
essence of your response is that it will make recruiting ADs easier, but 
that you don't believe it will appreciably change what they ADs actually 
do. Did I get that right?
> I have not personally found the “which area will this group live in?” discussions to be useful.
Where I remember it being useful most recently wrt RAI and TSV was in 
the _very_ early discussions working out the scope for the group that 
ended up being rmcat.
> 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.
That's not an argument for or against the proposal is it? (But it is 
something that the IESG might poke more at - perhaps just moving some 
groups between areas would have had just as much effect as assigning an 
out-of-area AD?)
>   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.
>
I'm sorry, but I lose you at this point.

I don't see anything being fixed, given this argument, beyond perhaps 
being able to recruit more ADs (and I find that questionable, but I 
agree that it won't make it harder to recruit folks).

I do see you introducing an opportunity to make it more confusing for 
people wanting to get protocol work done (which process in the new area 
should they engage?).

I see it making it _harder_ for the ADs of that area (hopefully only a 
little) as they work through that confusion.

Maybe there's easier on the other side of that, but it's not obvious 
that it will be _significantly_ easier.

It occurs to me that one thing that might help add clarity to this 
discussion is to see the description of the new area (as would be handed 
to the nomcom for filling positions) written down. Has someone tried 
that yet?

Until this message, I've been asking questions and pointing to potential 
ramifications that it's not clear the IESG considered. I haven't been 
trying to say "I support" or "I don't support" the proposal. I think 
there's a way to combine the three areas that can work, but I think 
you'll need to do more as part of that combination for it to not be 
_more_ work for the IESG, even in the long run.

If the IESG proceeds with the proposal as currently written, the only 
place I see it having a chance of really improving things is with the 
possibility of attracting more ADs. I haven't seen anything in the 
proposal that reduces AD workload (have I missed something?), which 
makes the chances of attracting a bigger pool of candidates smaller. You 
write above that "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." The hitch in that is that 
this AD will be doing _more work_ than they would have done just as a 
transport AD. The argument seems to be counting on the "web-focused 
group or two" work being so much more valuable that these sponsors would 
be willing to pay the TSV-time tax.

So, to be explicit - I don't oppose the reorganization, but I think you 
need to do more work or the result will be somewhere between "no 
difference" and "a little more work for the ADs than we have right now". 
I'd again encourage writing down the area description as a good step.

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 14 Jan 2015 10:01:47 +0000

FWIW, this is very close to how I break down the architecture in my head, and I agree with Ted that if we are opening the door to restructure the areas, we might as well be a bit more radical.

On 2015-1-13, at 20:51, Ted Hardie <[email-masked]> wrote:
> 
> 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 applications create flows and what those flows' exchanges should be.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 14 Jan 2015 13:32:14 +0200

Ted, Alissa,

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

I just wanted to say that I for one agree with this. And I think the IESG fully agrees as well.

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

I can confirm from my own observations that workload is a key issue for volunteering to do AD and other work at the IETF. (To be more specific, the issue is not that people are scared of work, there are lot of people willing to contribute tremendous amount of effort. The issue is largely the ability to do that while still also doing something else in your day job.)

Anyway, I also think that we must get both right - the workload *and* the areas. The areas need to make sense for both the participants (as you point out above) and the ADs.

Jari

---

From: Dave Crocker <[email-masked]>
Date: Wed, 14 Jan 2015 07:32:06 -0800

> FWIW, this is very close to how I break down the architecture in my head, and I agree with Ted that if we are opening the door to restructure the areas, we might as well be a bit more radical.

This could be interesting...

As a list, the wording style is creative and maybe fun, but I'm not
clear how to apply each of these bullets in practical terms.

So let's pursue this a bit deeper, for better understanding and possibly

>> The bit that works on how network elements behave

     How does this differ from the one before?

   Besides 'what path flows use', what other aspects of 'behave' are
intended to be contained in this?

>> The bit that works on how network operators work.

   They work highly variable hours, often with wakeup emergencies in the
middle of the night.  Oh? That's not what this bullet means?

   Seriously, what is the practical scope of this?  There's probably an
existing description somewhere that can be pointed to?

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

   This is probably meant to cover basic object encryption that is
independent of networks and flows, but its phrasing might only mean
channel-based protection, especially since the IETF often focuses on TLS
to the exclusion of object-based methods.

   Please clarify.

>> The bit that works on node configuration and bootstrapping

   Should this include application initialization, too?  Might be useful
to aggregate that set of issues into the same place.

   By the way, as we use our concern for pervasive monitoring and
compromised infrastructure, we might want to make it easier to have most
configuration info come from someone other than the local access provider.

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

   This sounds quite interesting, but I don't understand it.

   Please clarify what sorts of issues there are here, beyond different
link-level device drivers.

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

   Second reference to flows, with maybe bullet two implying a third.  I
don't understand why this is separated from the first (and maybe
second.)  Please clarify.

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

   This is the only reference to applications and it's only in reference
to the interface to a flows mechanism.

   That's can't possibly be the only applications-related IETF work.
(And of course, it isn't.)

d/

ps.  Ted's note to Jari, on Boxing Day (12/26) raises a number of
substantive concerns about what I will call the incompleteness of the
IESG's proposal.  He offers some very basic questions that strike me as
not just reasonable, but essential.  For any proposal at
re-organization, those questions need good answers and good community
understanding and agreement on those answers.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Brian Trammell <[email-masked]>
Date: Thu, 15 Jan 2015 12:23:31 +0100

Hi Ted, Alissa, all,

Hopefully-coherent ramblings inline.

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

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.

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

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

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

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 pi…

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

Cheers,

Brian

---

From: Mary Barnes <[email-masked]>
Date: Thu, 15 Jan 2015 10:36:14 -0600

FWIW, I totally agree with Robert as well as the concerns Ted has raised.
In particular, I totally share Robert's concern about the confusion to the
community as to where new work should go.   One of the huge advantages we
achieved with the formation of the DISPATCH WG was that unless it was
crystal clear what WG the work was most relevant to, individuals (for the
most part) came to the DISPATCH WG/chairs.  Prior to that, we would have
people WG shopping and there was one situation where the same draft was
presented in 3 different WGs.

IMHO, the workload issue could be much more effectively handled by taking
better advantage of directorates.  The RAI area directorate is not at all
been utilized as it could be.

Regards,
Mary.

On Tue, Jan 13, 2015 at 2:50 PM, Robert Sparks <[email-masked]> wrote:

> the bucket. Nothing special about TSV other than "it's been hard to recruit
> ADs for that area"?
>
>>
>> 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?
>>
> That seems to argue for no areas at all, more than it does this particular
> subsetting.
>
>> 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.
>>
> you're trading one established set of ways for structuring discussions off
> for some you'll have to invent. It may well be you find better ones.
>
>> 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.
>>
>> discussions to be useful.
>>
> Where I remember it being useful most recently wrt RAI and TSV was in the
> _very_ early discussions working out the scope for the group that ended up
> being rmcat.
>
>> 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.
>>
>> 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.
>>
> being able to recruit more ADs (and I find that questionable, but I agree
> that it won't make it harder to recruit folks).
>
> Maybe there's easier on the other side of that, but it's not obvious that
> it will be _significantly_ easier.
>
> discussion is to see the description of the new area (as would be handed to
> the nomcom for filling positions) written down. Has someone tried that yet?
>
> there's a way to combine the three areas that can work, but I think you'll
> need to do more as part of that combination for it to not be _more_ work
> for the IESG, even in the long run.
>
> possibility of attracting more ADs. I haven't seen anything in the proposal
> that reduces AD workload (have I missed something?), which makes the
> chances of attracting a bigger pool of candidates smaller. You write above
> that "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." The hitch in that is that this AD will be
> doing _more work_ than they would have done just as a transport AD. The
> argument seems to be counting on the "web-focused group or two" work being
> so much more valuable that these sponsors would be willing to pay the
> TSV-time tax.
>

---

From: Dave Crocker <[email-masked]>
Date: Thu, 15 Jan 2015 08:54:04 -0800

On 1/15/2015 8:36 AM, Mary Barnes wrote:
> IMHO, the workload issue could be much more effectively handled by
> taking better advantage of directorates.

+1   (well, really, +10)

d/

---

From: Ben Campbell <[email-masked]>
Date: Thu, 15 Jan 2015 16:56:06 -0600

> On Jan 15, 2015, at 10:36 AM, Mary Barnes <[email-masked]> wrote:
> 
> FWIW, I totally agree with Robert as well as the concerns Ted has raised.   In particular, I totally share Robert's concern about the confusion to the community as to where new work should go.   One of the huge advantages we achieved with the formation of the DISPATCH WG was that unless it was crystal clear what WG the work was most relevant to, individuals (for the most part) came to the DISPATCH WG/chairs.  Prior to that, we would have people WG shopping and there was one situation where the same draft was presented in 3 different WGs.

I also agree with Robert, Ted, and I guess now Mary :-)

I see an advantage merging APPS and RAI. I don't see the advantage of adding TSV to the mix.

As it happens, and I think mainly due to the luck of the draw, I've chaired multiple "frontier" working groups, that is, groups that had significant cross-area participation and dependencies. SIMPLE started in APPS, then moved into RAI when that area was formed. XMPP has major dependencies on APPS work, and its participants have as much (or more) APPS experience as RAI experience. I agree with Ted's statements that the divide between APPS and RAI is rather artificial. (They both even have "applications" in their names.)

The other working group that I chaired was DART, which was a cross-area effort between RAI and TSV. I think this was important work, and needed to happen. That need will reoccur from time to time, and should probably be easier to make that sort of work happen.  But DART also made it clear that these two groups do not have nearly as much in common technically as do RAI and APPS. If the goal of such a merger is to bridge that technical divide, then there might be value in doing this. But if the goal is to lighten the workload of the responsible ADs, I think merging TSV with RAI might actually make things worse, at least for the near future.

>   
> 
> IMHO, the workload issue could be much more effectively handled by taking better advantage of directorates.  The RAI area directorate is not at all been utilized as it could be. 
> 

I agree on both points. There might be value in also making more use of technical advisors to working groups.

> Mary.

[...]

---

From: Benoit Claise <[email-masked]>
Date: Fri, 16 Jan 2015 14:53:42 +0100

>> taking better advantage of directorates.
And taking better advantage of the doc. shepherds, WG chairs, and WGs 
... basically, the entire community.

Coming back to the directorate, I'm proud of the OPS-DIR these days.

This really helps in terms of AD load.

Regards, Benoit

---

From: Larry Masinter <[email-masked]>
Date: Mon, 19 Jan 2015 01:28:36 +0000

In the APP, RAI, TSV area reconfiguration, a suggestion to consider:

Carve out a "WEB" area which covers work that should coordinate with browsers and W3C.   Other apps (real-time or not) and transport questions could be one super-group which wouldn't be as big as all three.  

In Web: HTTP, URI/URL, WebRTC
In non-Web: email, xmpp
Could go either, but better in WEB:  MIME, encodings

The idea is to improve alignment and coordination, and get more participation.

Larry
--
http://larry.masinter.net

---

From: Yoav Nir <[email-masked]>
Date: Mon, 19 Jan 2015 11:40:09 +0200

Hi, Larry.

> On Jan 19, 2015, at 3:28 AM, Larry Masinter <[email-masked]> wrote:
> 

What started this process was that there was not enough work in APP to justify a whole area. What you are suggesting here is a mini-area with around 5 working groups. Doesn’t this make it worse?

Yoav

---

From: Larry Masinter <[email-masked]>
Date: Mon, 19 Jan 2015 19:24:57 +0000

> What you are suggesting here is a mini-area with
> around 5 working groups. Doesn’t this make it worse?

Of current working groups I'd count 9.5, not 5, 
Appsawg .5, Httpbis, Hybi, Json, Urn, Websec, Rtcweb, Webpush, Jose, Oauth

And perhaps some of OPS work, too.

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 19 Jan 2015 14:35:12 -0500

Hi Larry,

> Appsawg .5, Httpbis, Hybi, Json, Urn, Websec, Rtcweb, Webpush, Jose, Oauth

JOSE is in Sec right now and is very close to being done, I hope
before Dallas and if not, soon after.  Oauth is in Sec too right now
and has more work to finish.

Kathleen

-- 

Best regards,
Kathleen

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 19 Jan 2015 21:55:00 -0500

Before we go too far with this, it just occurred to me that implicit in the
discussion to date has been the notion that an AD spends most of their time
managing WGs.

That might be the case for some areas but there are others where there is a
huge amount of out of area work. Security for example.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 19 Jan 2015 20:55:31 -0800

On 1/19/15 6:55 PM, Phillip Hallam-Baker wrote:
> Before we go too far with this, it just occurred to me that implicit in
> the discussion to date has been the notion that an AD spends most of
> their time managing WGs.

There's an enormous fraction of this activity that is devoted to
spherding documents through post-working group stages, reviewing other
documents prior to the telechat's that punctuate iesg review. and
triaging  documents where there are seriously problems. Those are not
by-in-large tied up in working group management.

> That might be the case for some areas but there are others where there
> is a huge amount of out of area work. Security for example.
> 
>

---

From: Larry Masinter <[email-masked]>
Date: Tue, 20 Jan 2015 07:41:16 +0000

I didn't start with working group count, I was just responding. Current working groups aren't what you really want, since it's future work, and lots of AD time isn't on working group management, but if you want to know "how much does the workload of TSV compare to the workload of RAI", one measure to approximate relative workload is the count of working groups.

More significantly, it's not like we're done with web and security, or web and privacy or web and payments or ...
The work lacks focus. "Origin" left websec, moved to WHATWG, but it's back now in URL. 

I'm imagining the workload of WEB ADs would include more liaison. 

Larry

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Jan 2015 13:51:39 +0100

> The idea is to improve alignment and coordination, and get more participation.

+1

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 20 Jan 2015 09:55:45 -0500

> by-in-large tied up in working group management.

Absolutely. But the point I was making is that every draft has security
implications while an application draft that has routing implications
almost certainly needs slapping with something.

Sorry to sound like a broken record on this, but I think we are making a
lot of work for ourselves by not having a reference architecture. This
creates work at the WG level as each WG goes off and makes its own
interpretation of the architectural principles. Then the IESG starts with a
set of divergent documents and tries to make sense of them.

I have been trying to do write a reference architecture to describe it to
non Internet folk and I am rather surprised to find that the Internet
architecture as currently deployed can be described in a reasonably compact
and clean model[*] without resorting to calling firewalls, NAT, VPN, SDN
etc. blasphemies.

It is counterproductive to have a WG spend time deciding how to apply JSON,
etc. and then have those decisions overridden at the IESG level to get
consistency between specs. I want the consistency, just at a lower human
cost.

One approach that might help would be for the IESG to maintain a wiki with
prior feedback from ADs sorted into some form of structure. This would then
serve as precedent folk could look up. Another pathology I really dislike
is when certain individuals wait till the AD is out of the room and then
tell the WG what the IESG is going to demand (which is frequently rather
different to what they actually say). So basically the same thing as
minutes but structured somehow.

[*] About the same number of elements as the standard model of particle
physics.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Jan 2015 09:06:25 +1300

On 21/01/2015 01:51, Julian Reschke wrote:
>> Carve out a "WEB" area which covers work that should coordinate with browsers and W3C.   Other apps (real-time or not) and
>> transport questions could be one super-group which wouldn't be as big as all three.
>>

Well, it's a grouping that is a bit small to have an AD of its own
and overlaps with other specialisations. The traditional solution
for that would be to have a small cross-area directorate. If we're
going to loosen the boundaries of Areas, I suspect we'll need more
small directorates.

    Brian

---

From: t.p. <[email-masked]>
Date: Wed, 21 Jan 2015 17:00:11 +0000

----- Original Message -----
From: "Larry Masinter" <[email-masked]>
To: "Yoav Nir" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, January 19, 2015 7:24 PM

> And perhaps some of OPS work, too.

While a count of WGs is one measure of the load on an AD, another,
suggested by reports from the IESG itself, would be of how many I-Ds are
being handled.  Thus a WG like v6ops, which might have 60 I-Ds on the
go, could be an order of magnituude harder to manage that appsawg, which
limited itself to six.  This could be quantified by running a script
against tools, to list for each WG how many I-Ds it has adopted and how
many others are currently listed as not yet adopted; and a trend of this
over time might be a measure of how well a WG is coping.

The length of time an I-D is in the system would be another measure of
the load on management so another script could measure how many months
it is from the date when an I-D was adopted to the present date, summing
all the values for a given WG.  Again, a trend over time could be a
measure of how well a WG is faring.

Tom Petch