ietf
[Top] [All Lists]

Re: Update on the re-organisation steps

2015-01-16 16:00:33
I agree that this is much improved as an initial plan.

Thanks!

Ben.

On Jan 16, 2015, at 3:43 PM, Black, David 
<david(_dot_)black(_at_)emc(_dot_)com> wrote:

+1, Thanks, --David
 
From: WGChairs [mailto:wgchairs-bounces(_at_)ietf(_dot_)org] On Behalf Of 
Mary Barnes
Sent: Friday, January 16, 2015 11:59 AM
To: ietf
Cc: IETF WG Chairs; IETF Announcement List
Subject: Re: Update on the re-organisation steps
 
I like this proposal a lot.  Thanks for all the efforts in considering and 
incorporating community feedback.
 
Regards,
Mary
 
On Fri, Jan 16, 2015 at 9:56 AM, IETF Chair <chair(_at_)ietf(_dot_)org> wrote:

The IESG has discussed the re-organisation proposal and the comments
that we have received. Thank you for providing feedback!

We have decided to move forward with two parts of the original proposal,
continue thinking about the third one, and have identified a fourth item that
needs even more focus:

1. We are asking the Nomcom to seat a third AD for the Routing Area. The
desired expertise for this position is the same as the one already used for 
the
position that was open noting an increase in YANG related work in the RTG
Area, and the three working groups that will move from INT to RTG. The
position is for two years. This change addresses changes in work that is
coming to IETF, making the management of this work easier, and it is
anticipated that the work-load for RTG Areas will be normalized as a result.

2. We have been implementing a change in how flexible the assignment of
ADs is to areas. This is necessary in order to ensure that we have sufficient
agility to perform our management tasks, and is demonstrated by our
re-assignment of some of the OPS Area working groups to non-OPS ADs
as one of the OPS  ADs has taken on broader responsibility for IETF
YANG work.

As we rebalance, this change will affect how WGs are assigned to ADs,
and this will require changes in how the IESG operates as well as changes
to some of the data tracker tools.

Note that this is a change with regards to which AD manages specific working
groups. The assignment of working groups to areas will not change as a result
of this procedural change. An AD can be the most suitable manager for the
working group, even when the working group itself remains associated with a
different area. An area is not merely about the ADs managing it, it is also
category of topics on a particular branch of technology, a designation in our
agendas, usually overseen by one or multiple directorates, and scheduled so
as to avoid too many conflicts within the area. Areas are also loose 
collections
of people working together, and the assignment of ADs to particular working
groups should not have an effect on any of these other aspects of an area.

This change relates only to agility, and the IESG fully recognises the
observation that a key focus for organizational changes in the IETF should
be in moving work from the IESG to working groups or other entities.

3. We have heard the feedback from the community that there is concern
about creating a "mega-area" formed by combining APP, RAI, and TSV. We
will think about this proposal further and will come back either with a
stronger rationale or an alternative plan of more normal-sized areas: any
proposal for structural change will reflect the feedback you have given us.

4. With respect to ensuring that AD workload is suitable for a broad of class
contributors willing to take on the task, the IESG clearly needs to take
additional steps. Agility and right area structure helps spread the workload
better across ADs, but other changes are needed. But this is a continuous
process. Our desire to push document approval Comment and Discuss
resolution more to the working groups and e-mail has significantly reduced
the length of our tele chats in recent years, for instance, and we are 
starting
a project to eliminate errata processing as an AD task. We will return to this
topic with further proposals later as well.

Jari Arkko for the IESG


<Prev in Thread] Current Thread [Next in Thread>