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