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

["Adrian Farrel" <[e-mail]>]

>>> 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