Re: IETF areas re-organisation steps

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 
<rjsparks(_at_)nostrum(_dot_)com> wrote:

Thanks for the response, Alissa. Some comments inline.


On 1/12/15 5:50 PM, Alissa Cooper 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.

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.

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.

Again, that seems to be an argument for getting rid of the areas, and
isn't specific to this particular subset of areas.


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?

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.

 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.

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?

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.

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.

 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.

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.

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