ietf
[Top] [All Lists]

Re: IETF areas re-organisation steps

2015-01-11 18:47:14
Hi Ted,

Thanks for your thoughtful mail.

​Are these roughly in order of importance to the IESG?  If so, I think
the order is wrong. 

Speaking personally, I did not think of the set of principles as being ordered.
Certainly, as you argue, there are some differences in how they should be
weighed. The IESG did not attempt to prioritise them, but rather wanted to
point out what key issues we want to keep in mind.

​So, I think this increasing your flexibility, but does nothing much for 
sustainability.
You still are having the same pool of bodies do the work, simply taking AD 
capacity
from one area and using it another.  That may be nice, but it increases the
level of cooperation needed between the area management and the visiting
ADs, so it is really only a marginal gain even for the area getting the 
outside talent.

To make a dent in this, you actually have to increase the number of bodies
available to do the work.  And to do that, you have to reformulate some of 
the 
work so that bodies who do it don't have to have the tag AD.  (The document
shepherd opening up to non WG chairs is a good example here).​

I agree, but not all specific actions that we suggested may affect all the 
things
we want to have an effect on.

Increasing flexibility is important. Again in my personal opinion, 
sustainability
is largely about two other factors. One, that you can distribute work in the
organisation, and by this I do not mean to the other ADs :-) Two, that you have
ADs that are overseeing and managing work that the world determines to be
of high value.

​This justification seems to hint at a "Model Language AD" who
can serve the whole IETF as a shepherd of YANG work across areas.
Why is that not a better answer here?

That would be another way to do it, but in my personal opinion we
have a long-term growth in the routing-related work and that is not
solely about model languages, even though that topic indeed is a
key topic.

Noting that you are short of routing AD attention and shifting other
work into the area after fixing that problem also seems to ignore the
"out of area" AD mechanism introduced above--why is that not 
sufficient?

Again, I think flexibility is useful for us to react, and the kind of “small 
scale”
flexibility that out-of-area ADs for instance provides, is useful to address
the day to day needs of the IESG to organise its work. Nevertheless, the
definition of our areas still has to evolve, and in my mind that addresses
the bigger scale changes. If you have an organisation that can use
experts from anywhere when an issue comes up, that is flexible. Still,
if that organisation embarks on a big project, they probably should
hire the staff for it.

I also note that the proposed shift changes the useful
skillsets for both routing and INT, and that doing so at this point in
the nomcom cycle isn't exactly optimal.

Noted. Finding the optimal point to make changes is not easy, however.
I think the IESG feels that the benefits of making changes outweighs
the downsides.

​So, I thoroughly agree that the name here is distractingly bad, but I
also believe that you're building the wrong bike shed.

Thank you for focusing on the substance :-)

As it stands, coordinating
four or five people's schedules to have calls and agree on document 
processing either
means a fairly large investment in time spent on Doodle polls or allowing
the area to have "mini-Areas" whose coordination remains loose.

I think having mini-areas would probably mean that an organisational change
did not really get implemented as intended, which is bad. 

As Robert Sparks pointed out, the failure to use common methods (like 
DISPATCH)
is going to run into trouble and exacerbate that.  ​

Noted, and I agree.

​There are a lot organizational principles possible here. RAI was organized 
more or
less as a topic area with "all those things relating to Internet Telephony 
(plus a few)"​
as the topic.  This meta-area doesn't seem to have such an organizational 
principle,
and the "there are overlaps" argument doesn't seem that strong given the 
large number
of _other_ overlaps.  I understand that folks are tempted by the "select a 
bunch of generalists" 
and let them work it out as a free-form approach to the AD job, and that this 
could be
a mini version of that.   Personally, though,  I think having set areas 
remains valuable, in
part because it shows how the overall organization understands the way the 
work interconnects. 
Putting too much in a single bucket muddies the interconnection into 
incomprehnsibility,
at least to me.

I think I at least agree on your principles, i.e., areas remain as valuable 
entities, and that
putting too much or too different topics in the single bucket would not be 
optimal. Point
noted, although, of course, the question we need to think about is whether the 
proposed
area crosses that line or not. The IESG will for sure discuss this.

To return a moment to the question of sustainability, I think the key element 
is always offload.
When all the site selection and contract work left the IESG and was taken up 
by the IAOC,
the IESG gained cycles over all.  That might have been hard to see at the 
time because of
the overall transition, but it is obvious now.  I think the IESG might get 
more bang for its
re-organizational buck if it focused on areas where its tasks could be handed 
over to new
bodies.  As a very small example, if the conflict review work were done by a 
different group,
with each area sending a delegate, would that hurt anything much?  Would it 
gain any real
time?  This may be a small example, but I think the principle is 
general--please focus on
areas where the IESG can differentiate its workload and then delegate the 
bits that
can be done elsewhere.

Good advice, and thanks. I will add that the IESG certainly believes this as 
well,
and wants to proceed in this direction as well. (But see above about my two 
aspects
of sustainability. Also, the ability to offload work does not relieve us from 
the need
to have the right organisational structure or the right areas.)

Jari

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail