ietf
[Top] [All Lists]

Third RTG AD [Was: IETF areas re-organisation steps]

2014-12-27 10:23:23
II.  ADDING A THIRD RTG AD
[snip]

I'm a little bit surprised that the RTG area load has gone up like this,
and so quickly.  Is it the various SDN things that are pushing this, or is it
that the RTG area currently has the most enthusiasm for YANG work?

It's a mixture of things combined with RTG already being at the very
top edge of workload.

Alia catches a point there.
I don't think that the load has gone up dramatically. Rather that the load was 
at or close to its maximum but there have been recent WGs replacing those 
closing down (SPRING, SFC, NVO3) and a continued background of BoFs. You are 
right that the YANG work increases the load too, and Alia is right that 
absorbing 3 WGs from INT also increases the load.

You might like to look at a page count or a document count of publication 
requests as a useful measure (in addition to the bald count of WGs). Also you 
can see the hours of meeting chart that Jari had in HI.

The point, however, is that despite the good turnout of candidates for RTG AD 
it still remains a stretch that an AD should be putting up more than 85% of his 
or her time. That is a huge investment (donation) by the sponsor company and 
means that the AD is too close to being a "standards professional" and too 
removed from the real world of implementation. Of course, I don't know the 
workings of the minds of the nominees nor what they told the NomCom, but I'd 
guess that many of them think that, notwithstanding the description provided to 
NomCom, they could squeeze the job into 75% or less of their normal working 
week. I think we all think that, and then reality clicks in :-)

I would argue that the 3rd RTG AD is a short term fix in two dimensions. 
Firstly, it should not be assumed that the AD position will last long. 
Secondly, it is not a fix to the wider problem of IESG overload. Thus, the 3rd 
RTG AD provides resource within the current framework to alleviate a pinch 
point, but we should assume that a more realistic and thoughtful reorganisation 
of the IESG and the IETF over the next few years should balance workloads and 
restructure more carefully.

Adrian


<Prev in Thread] Current Thread [Next in Thread>
  • Third RTG AD [Was: IETF areas re-organisation steps], Adrian Farrel <=