Dave said what I was thinking, but with many more words. *We* have put
ourselves in a box. If we work the way we worked when we published 100 RFC's a
year, we are sure to fail. As a side note, there are over 100 drafts in the
RFC Editor queue this instant.
As Dave and Hannes have pointed out, the IESG has effectively created the
unwritten requirement, "must work for a very large company." Look at the
current IESG. Two thirds are directly employed by large companies. Of the
five remaining, two have their IETF participation paid for by the US government
and one has their participation paid for by the EU. One AD looks like he comes
from academia, but really works in their FFRDC, which is a fancy term for a
large company owned by a university.
So, out of 15 Area Directors, we have precisely one who comes from a company or
organization with less than $1B in revenues or direct government support.
As has been pointed out numerous times, the 50% effort figure rapidly
approaches 100%. That means we are telling the community that only people for
whom their day job is being on the IESG are eligible to apply. Note my careful
use of the word 'eligible.' How many people have been passed over for an AD
nomination because they were unsure of where they would be working in a year or
if they had employer support? The answer is a substantial number.
I will say it again - the IETF is organized by us. Therefore, this situation
is created by us. We have the power to fix it. We have to want to fix it.
Saying there is nothing we can do because this is the way it is is the same as
saying we do not WANT to fix it.
On Mar 4, 2013, at 5:45 AM, Hannes Tschofenig
<hannes(_dot_)tschofenig(_at_)gmx(_dot_)net> wrote:
The time commitment is a very good point, Dave.
If we want to also involve people who do not work for big corporations (or
get otherwise sponsored by big organizations) then the idea of having ADs
review every document may need to get a bit relaxed. Today, almost all of the
ADs (and IAB members) work for major enterprises.
In companies managers typically do not get involved in every little technical
detail but rather need to ensure that the work gets done. Maybe ADs could
delegate more tasks to directorates, as it is done in the security area
already. This also avoids the problem that an AD becomes the bottleneck in
understanding the work that working groups produce. This happened in the past
as well.
Ciao
Hannes
On Mar 3, 2013, at 6:14 PM, Dave Crocker wrote:
On 3/3/2013 4:56 AM, Eric Burger wrote:
The 50% time commitment is an IESG-imposed requirement. If that is really
the problem, we have had areas with more than two ADs.
Finding qualified Transport ADs has been a continuing problem for a number
of years. This year's impasse was inevitable. Whatever the problem, it's
deep-seated.[*]
While the problem for Transport is extreme, it's generally difficult to find
a good range of qualified candidates for AD. A major barrier is the time
commitment to the job. And it's not really a 50% slot; the reality for most
ADs seemed to be in the 75-100% range.
This is a massive cost to their employer, both in raw dollars and
opportunity cost -- ADs are typically senior contributors. That means
removing a strategic resource from the company's main activities. To take a
senior contributor away usually requires that the company be very large and
have a very deep bench of talent.
That's an onerous burden, in my view, and significantly reduces the pool of
available candidates.
The IESG needs to decide that the job is a 25% job -- an actual terms -- and
then decide what tasks are essential to perform within that amount of time.
This will require a significant change in the way ADs do their work.
Reducing the real, budgeted time for an ADs job should significantly
increase the pool of available candidates. As a side benefit, it should
also significantly improve the diversity of the pool, along most parameters.
As an obvious example of what to change, it means that ADs need to change
their paradigm for document review.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
signature.asc
Description: Message signed with OpenPGP using GPGMail