Subject: Appointment of a Transport Area Director

From: IETF Chair <[email-masked]>
Date: Sun, 3 Mar 2013 00:00:11 -0500

Dear IETF Community,

The 2012-2013 IETF nomination process has not yet filled the Transport
Area Director position despite several attempts to broaden the pool of
nominees.  The whole community conveys our most sincere gratitude to the
existing nominees for this position.  However, it seems that no candidate
has yet been found that meets the specific IESG-provided requirements and
is also able to make the necessary time commitment.

Requirements for IESG positions can be found at:
https://www.ietf.org/group/nomcom/2012/iesg-requirements

The TSVAREA session at IETF 86 will include a discussion on the
difficulty in locating a Transport Area Director candidate that meets
these position requirements and is also able to make the necessary time
commitment.  The outcome of the discussion cannot be predicted in
advance.  Since this discussion could lead to a change in the IESG
requirements, the IESG encourages the community to take part in this
discussion so that any changes are based on broad community input.

On behalf of the IESG,
 Russ Housley

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 03 Mar 2013 07:53:29 +0000

On 03/03/2013 05:00, IETF Chair wrote:
...
> discussion so that any changes are based on broad community input.

When there is a choice between nominating nobody, and nominating someone
with excellent IETF experience and management skills, but who is not a
recognised specialist in the narrow technical area concerned, I believe
that standing advice to the NomCom should be to appoint such a candidate.

Also the standing advice to the confirming body should be to confirm
such a nominee.

We are too hung up on our narrow specialisations in the IETF.

   Brian

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 3 Mar 2013 11:15:57 +0200

Brian, you are essentially saying that the Nomcom should "ignore the requirements". 

I believe we would attract more candidates right from the beginning if we lower the requirements.

The transport area has historically had a this strong emphasis on congestion control expertise for at least one of the serving transport ADs and this requirement seems to reduce the pool of available candidates quite severely. 

Ciao
Hannes

---

From: Eric Burger <[email-masked]>
Date: Sun, 3 Mar 2013 07:37:59 -0500

There are two other interpretations of this situation, neither of which I think is true, but we should consider the possibility. The first is the TSV is too narrow a field to support an area director and as such should be folded in with another area. The second is if all of the qualified people have moved on and no one is interested in building the expertise the IESG feels is lacking, then industry and academia have voted with their feet: the TSV is irrelevant and should be closed.

Since I believe neither is the case, it sounds like the IESG requirements are too tight.

---

From: "Eggert, Lars" <[email-masked]>
Date: Sun, 3 Mar 2013 12:50:13 +0000

> Since I believe neither is the case, it sounds like the IESG requirements are too tight.

I don't believe the requirements are too tight. *Someone* one the IESG needs to understand congestion control.

The likely possibility is that many qualified people failed to get sufficient employer support to be able to volunteer. It's at least a 50% time committment.

Lars

---

From: Eric Burger <[email-masked]>
Date: Sun, 3 Mar 2013 07:56:54 -0500

The 50% time commitment is an IESG-imposed requirement. If that is really the problem, we have had areas with more than two ADs.

---

From: John C Klensin <[email-masked]>
Date: Sun, 03 Mar 2013 09:00:37 -0500

--On Sunday, March 03, 2013 12:50 +0000 "Eggert, Lars"
<[email-masked]> wrote:

> The likely possibility is that many qualified people failed to
> get sufficient employer support to be able to volunteer. It's
> at least a 50% time commitment.

Yes.  And with emphasis on "at least".   See below.

--On Sunday, March 03, 2013 07:56 -0500 Eric Burger
<[email-masked]> 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.

Eric,

You say that as if the IESG sat down and said "let's make up a
50% requirement" and could have as easily said "let's make up a
25% requirement". That number is supposed to be IESG's best
estimate about the time commitment required, not a requirement
they have somehow set.   While I've often been critical of the
IESG, I have no reason to believe that they fudged the number
upward.   From observations of how much time and energy several
ADs put in, I would, if anything, suspect that a 50% estimate is
too low.

You also know better than to believe that adding another AD slot
would have much influence on this.  First, ADs spend significant
time on areas other than their own.  Unless the review rules
were changed so that only one AD from a given area even needed
to look at a document or perhaps even participate in IESG calls
and discussions, increasing the number of ADs in an area doesn't
help with that source of time commitment.   Possibly dividing up
the area's working groups three ways rather than two would help,
but I note that Transport doesn't have a disproportionately
large number of WGs.

Whether you think the Parkinson or the Brooks analysis are the
most relevant, work expands to fill the available time.

I do think there is a problem with that 50% number (or the large
number that I suspect is more realistic).  I've explained that
concern several times on this list (and more times in various
process WGs).  In essence, I think that IESG members who take
their responsibilities very seriously (a good thing, up to a
point) and who are able to spend most of their time on the IETF,
have, together, gradually taken on more tasks and
responsibilities for the IESG. Those tasks, in turn, have made
the job bigger.  I believe that the IESG should be managed, and
manage itself, so that each new task and each new BOF or WG, is
evaluated on the assumption that IESG time is a scarce resource
and that increased workload is not acceptable.  And I believe
that sunset provisions should be applied to existing tasks and
procedures with an overall goal of getting the IESG job back
down to the level that it could be done alongside a realistic
day job with real design, product, or implementation
commitments, not instead of one (once upon a time, that was the
norm).   

There are other ways to accomplish the same thing and to do so
more quickly.  For example, while I'm not recommending it, one
could, in principle, separate WG and IETF management and
"steering" functions and document review and approval functions
off into separate bodies.  But no one seems to even want to
discuss that one, perhaps for good reason (or not).

I'm certainly not either the first or the only person who has
suggested guidelines or mechanisms that would make the above
feasible.  It is perhaps interesting that none of the various
proposals have even been allowed to make it into IETF Last Call.

I believe strongly that a smaller size of commitment would get
us more applicants for _all_ AD slots, if only because it would
make the commitment from an employer or sponsor significantly
smaller.   But accomplishing that requires that the IESG reverse
the trend toward ever more responsibilities and an ever larger
job and time commitment.  Nomcoms could help with that by
selecting IESG members who are committed to a reduction in IESG
functions and workload as a goal (something I said every year
until I concluded that no one was listening).  But there is no
quick fix like juggling numbers or adding ADs: the first of
those would accomplish nothing and risk mid-term resignations
and the second would be likely to, in the long run, make things
worse.

The only thing that surprises me is that this is coming up in
only one particular area.  Given the implications of going to an
employer and saying what amounts to 

	"How about you help the IETF out by giving up the
	services of someone whom we presume is a highly-skilled
	designer for, realistically, four or six years, while
	continuing to pay him (or, better, her) full salary and
	supplying essentially unconstrained travel and other
	support resources.  During that time, you can certainly
	use her as an internal consultant or equivalent, but
	don't expect any real company work to get done.  And, by
	the way, you also have to protect that person's job,
	role, and advancement path within the company or no one
	sane would take the position."

...we should probably be pleasantly surprised that anyone, or at
least anyone who is professionally competent and useful, is ever
allowed to volunteer for any AD job these days.

      john

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 03 Mar 2013 14:25:53 +0000

Hannes,

> The transport area has historically had a this strong emphasis on congestion control expertise for at least one of the serving transport ADs and this requirement seems to reduce the pool of availab…

The IESG guidance to NomCom uses "should" extensively, and includes a request
to NomCom to seek "the best possible balance". So, while having one AD out
of two who has limited expertise in the area has very obvious downsides, so
does having only one AD, given current workloads.

Clearly the NomCom felt it was between a rock and a hard place; I just
want to assert the principle that balancing both managerial and technical
abilities is within NomCom's remit.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 03 Mar 2013 14:35:24 +0000

Lars,

Let's try that statement parametrised:

"*Someone* on the IESG needs to understand X."

I think there are many plausible values of X, certainly including
congestion control. But what do we do when, for some value of X,
there is no such AD?

What I'm getting at is that this line of argument doesn't scale.
The only solution I see is to replace it by
"Several people on the Y Directorate need to understand X."

That probably does scale. Of course, it implies that ADs consult
and trust the relevant Directorate.

Regards
   Brian

On 03/03/2013 12:50, Eggert, Lars wrote:
> Lars.

---

From: "Eggert, Lars" <[email-masked]>
Date: Sun, 3 Mar 2013 15:55:39 +0000

Hi,

> "Several people on the Y Directorate need to understand X."

only if the Y directorate reviews all IDs going through the IESG. Which in itself is a scaling issue. It may work for some topics, but things will fall through the cracks for various reasons. 

IMO congestion control is important and fundamental enough that the IESG itself needs to have the knowledge. YEs, I'm biased.

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Sun, 3 Mar 2013 15:58:58 +0000

Hi,

On Mar 3, 2013, at 13:56, Eric Burger <[email-masked]> wrote:
> The 50% time commitment is an IESG-imposed requirement.

it isn't. The The IETF process (which the IESG cannot unilaterally change) requires an AD to manage his or her area, and review all documents going through the IESG. The later is typically what constitutes the bulk of the work, at least for the areas that aren't RAI or INT.

> If that is really the problem, we have had areas with more than two ADs.

We could do that, but then we need to tell the NomCom that it's OK to pick people for the job who will focus on only one or a few aspects of the overall job description.

Lars

---

From: Dave Crocker <[email-masked]>
Date: Sun, 03 Mar 2013 08:14:19 -0800

> 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

---

From: Mary Barnes <[email-masked]>
Date: Sun, 3 Mar 2013 10:32:33 -0600

Lars,

Do you not have individuals in the directorate that are experts on
congestion control (that aren't document authors) that can review for
technical sanity of the proposal?  ISTM that some of the TSV nominees
have broad technical skills, including management that could be quite
useful.  Certainly, we have an example where a Nomcom appointed
someone with little expertise for a specific area and the result was
not good. However, I believe that was far more to do with how the
individual approached the role - authoritarian versus understanding
that from a technical perspective they should really listen to the
experts.  IMHO, that's the most important skill that some ADs lack -
i.e., listening.

In my experience at not all ADs carefully scrutinize WG items and they
tend to rely on the write-up of the shepherd.  While the shepherd is
most often the WG chair, if they do their job properly, I believe that
the problems that an AD might encounter are fewer.   I will note that
from what I have seen not all shepherds actually review the documents
themselves, which is a problem unto itself. There is often quite
visible when one does gen-art reviews.   ISTM, there is a way for the
process to work with an AD that is not the technical expert in
specific areas IF others down the chain do their jobs properly.  Of
course, IETF is really bad at managing down the chain when there are
weak links. IMHO, someone with decent project management and people
management skills can make a huge difference.

Regards,
Mary.

---

From: Scott Brim <[email-masked]>
Date: Sun, 3 Mar 2013 17:37:43 +0000

I see three different factors being discussed together.

  - whether an AD needs technical expertise across the area

  - whether an AD's work hours can be decreased

  - what is TSV's problem anyway

The size of the job is mostly orthogonal from the level of technical
expertise required.  Most of the work is done by a directorate.  However,
even if that's true, it would be a mistake to have an AD overseeing a
directorate without understanding the issues the directorate deliberates.
I really disagree with some who believe the job should be reduced to
something more administrative and less technical, as a way to make it more
"appealing".  Someone has to set priorities, expedite, and make decisions
(lots of them - do not depend on directorates for your decisions).  That
requires technical competence.  Not deep knowledge of every protocol
field, but certainly an understanding of the issues each WG is grappling
with, and enough to ask difficult questions and understand the answers.

Is that too much for one AD?  Is the area too complex?  Then split the
area.  We must have leaders, and we must have them comprehend what they
are leading, so size the work for that while also keeping up the quality
of the leadership.

Scott

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 03 Mar 2013 12:42:59 -0500

Gaving discussed TCP Congestion behavior with the TCP folks, and tried 
to understand the issues, it seems to be very hard.

And if the AD is not well-versed in it, there is a serious issue.  It 
seems to me that unless we restructure the entire way the IESG operates 
(maybe a good idea, but a VERY different question) the AD needs to have 
significant understanding of the technical questions of his area.

Otherwise, the AD gets a directorate review calling out congestion 
problems.  He puts in the discuss.  And can not discuss it with the 
other ADs.  It is not his discuss.  He can not work out how to resolve it.

Directorates are critical.  I would hope tat all areas can move to a 
situation where finding the issues rests primarily with the 
directorates.  But the AD has to have enough details in his area to deal 
with it.

Yours,
Joel

---

From: Michael Richardson <[email-masked]>
Date: Sun, 03 Mar 2013 15:14:21 -0500

>>>>> "Eric" == Eric Burger <[email-masked]> writes:
    Eric> There are two other interpretations of this situation, neither
    Eric> of which I think is true, but we should consider the
    Eric> possibility. The first is the TSV is too narrow a field to
    Eric> support an area director and as such should be folded in with
    Eric> another area. The second is if all of the qualified people
    Eric> have moved on and no one is interested in building the
    Eric> expertise the IESG feels is lacking, then industry and
    Eric> academia have voted with their feet: the TSV is irrelevant and
    Eric> should be closed.

To be considered qualified the candidate needed to:
  a) have demonstrated subject matter expertise (congestion in this case)
  b) have demonstrated IETF management expertise (current/former WG chair)
  c) have time available

Generally speaking, people who can not satisfy (c) do not show up on the
list of nominees, as they have to decline the nomination.   
There definitely are many people who have (a) and (b), but not (c). 

Were money not an issue, filing this position would be easy.  

The nomcom then needs to look at the remaining candidates and along with
the confirming body (the IAB) determine if they can compromise on (a)
or (b).

Brian has suggested that (b) is more important than (a).

===

Of course, this HHGG quote might apply. (I seem to be listening to the
radio play this afternoon...)
     To summarize: it is a well known fact that those people who most
     want to rule people are, ipso facto, those least suited to do
     it. To summarize the summary: anyone who is capable of getting
     themselves made President should on no account be allowed to do the
     job. To summarize the summary of the summary: people are a problem.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Scott Brim <[email-masked]>
Date: Sun, 3 Mar 2013 20:24:58 +0000

On 03/03/13 15:14, "Michael Richardson" <[email-masked]> allegedly
>  a) have demonstrated subject matter expertise (congestion in this case)

(I just want to nit on this: I hope people don't think TSV is just about
congestion.)

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Mar 2013 06:52:09 +0900

> IMO congestion control is important and fundamental enough that the
> IESG itself needs to have the knowledge. Yes, I'm biased.

as an operator and as an ex area director, i have the same bias.
transport is the waist of the hourglass.  "importand and fundamental"
are a good choice of words.

<digression>

as an area director, it was not the technical load which was hard, and i
read every single draft (draft load has grown since).  it was the social
and political 'work'.

randy

---

From: John Leslie <[email-masked]>
Date: Sun, 3 Mar 2013 20:36:10 -0500

Joel M. Halpern <[email-masked]> wrote:
> 
> Having discussed TCP Congestion behavior with the TCP folks, and tried 

   True -- most of us mis-understand congestion control in TCP. :^(

> And if the AD is not well-versed in it, there is a serious issue.

   You're in danger of limiting the field to maybe a dozen academic
types in the entire world. I suggest a lower bar.

   Folks are experimenting in congestion metrics all over the place:
I doubt there is even one person in the world who understands _all_
of them.

   IMHO, it's important to understand congestion-collapse and hysteresis
in feedback systems. A smattering of delay-based inferring of congestion
would be helpful if it gives insight into their weaknesses.

   It's worth noting that there is an Internet Research Group on
congestion control, charged to investigate the safety of congestion
control proposals. Fortunately they don't have to report very often --
these _are_ experts, and they find it hard.

> It seems to me that unless we restructure the entire way the IESG
> operates (maybe a good idea, but a VERY different question) the AD
> needs to have significant understanding of the technical questions
> of his area.

   One would hope that each AD's knowledge of the area grows...

> other ADs.

   Joel listens to most IESG telechats. He knows that discussion of
the technical details of congestion control is rare!

> It is not his discuss.  He can not work out how to resolve it.

   I must disagree! If he knows _who_ understands the issue, he can
suggest particular folks to work it out in email. That is how the
complicated issues tend to get resolved anyway.

> directorates.  But the AD has to have enough details in his area to
> deal with it.

   _Just_ enough -- yes.

====

   I'd like to introduce the actual "requirements", from:

] TRANSPORT AREA
] --------------
] 
] The Transport Area works on mechanisms related to end-to-end data
] transport as well as technologies for network storage and peer-to-peer
] applications. Transport protocols support Internet applications and
] services that exchange potentially large volumes of traffic at
] potentially high bandwidths.
] 
] Together, the two Transport ADs are expected to understand how transport
] technologies (layer 4) interact with IP layer technologies and protocols
] (layer 3) technologies, and with the end-to-end aspects of various
] applications and application-layer protocols (layer 7).

   Up to here, we're pretty safe, though we're entering an area where
jitter is a significant interaction, and that area is not well understood
yet.

] A Transport AD should have a good understanding of core end-to-end
] transport topics such as congestion control, flow control, real-time
] transport protocols, NATs, firewalls.

   Interaction of transport with real-time applications is a black art.
The folks who understand it best say that separate queues for bulk
and real-time traffic are needed. Alas, we have no way to require them.

] These include mechanisms to detect and react to congestion in the
] Internet, such as the congestion control algorithms in transport
] control protocols such as TCP, SCTP, MPTCP, and DCCP,

   "Such as" may be a saving grace here -- few folks have worked with
all of these.

] as well as congestion management schemes such as CONEX.

   ConEx really doesn't belong here. The WG participants barely
understand it.

] Some topics in transport mechanisms have strong ties to the research
] community, therefore some research background can be very helpful.

   Hmm... What is the NomCom supposed to _do_ about this?

] A Transport AD should also understand how transport layer technologies
] and protocols, such as NATs and firewalls,

   Not all of us consider these legitimate "transport layer technologies"
(as opposed to "damage")...

] impact the end-to-end effectiveness of applications,

   Damage those cause doesn't feel like something we should ask an AD
to fix!

] and how transport technologies and protocols can help to improve the
] end-to-end effectiveness of various applications.

   I'm nervous about "can help" -- transport should be a generic tool,
not something we diddle to make a particular application work better.

] Intserv (RSVP) technologies reserve resources to improve quality of
] service; Diffserv is an inline mechanism to request a quality of
] service during forwarding;

   Again, what do we expect NomCom to _do_ about this?

] Network-attached storage (NAS and NFS), and storage area networks
] (SAN, iSCSI, and Fibre Channel) help coordinate storage inside and
] between data centers, for virtualized environments, for large
] streaming applications, and remote replication for high availability;

   I'm having trouble even parsing this... Do we believe 2013 ADs
need any expertise in NFS, etc.?

] Signaling and control protocols for peer-to-peer traffic optimization
] help to avoid congestion in the Internet, by using trackers,
] background transfers, and in-network storage.

   These are legitimate TSV areas of work; but do ADs need prior
expertise in these?

] Current and new transport work includes congestion signaling and
] reporting, forward error correction, QoS and reservation signaling,
] DiffServ and congestion control for unresponsive flows,

   These certainly belong in TSV; but I really doubt we need ADs with
prior expertise in each of these.

] NAT regularization and specification, storage protocols for the Internet,
] peer-to-peer streaming, performance metrics for Internet paths,
] experimentation with congestion control schemes developed in the IRTF,

   I guess these belong in TSV, but IMHO they shouldn't gate on the
expertise of the TSV ADs.

] multipath extensions to existing transport protocols, congestion control
] for "background" bulk transfers, and extensions to the IETF protocols
] for multimedia transport.

   I don't consider these "core" TSV work...

] The Transport Area intersects most frequently with Internet Area, the
] Applications Area, the RAI Area, the Security Area, and several IRTF
] research groups.

   Of course...

] Cross-area expertise in any of those Areas would be particularly useful.

... but what do we expect the NomCom to _do_ about this?

====

   Presumably this part of the "requirements" will be discussed during
IETF week; and I do hope that will be helpful. But I suggest on-list
discussion before then will be even more helpful -- especially if we
can draw in some NomCom chairs to explain which parts of this have been
hardest to satisfy.

--
John Leslie <[email-masked]>

---

From: "Leaf Yeh" <[email-masked]>
Date: Mon, 4 Mar 2013 14:58:07 +0800

Michael - The nomcom then needs to look at the remaining candidates and
along with the confirming body (the IAB) determine if they can compromise on
(a) or (b).

Technically right. :-)

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Richardson
Sent: Monday, March 04, 2013 4:14 AM
To: IETF
Cc: Eric Burger
Subject: Re: Appointment of a Transport Area Director

The nomcom then needs to look at the remaining candidates and along with the
confirming body (the IAB) determine if they can compromise on (a) or (b).

===

Of course, this HHGG quote might apply. (I seem to be listening to the radio
play this afternoon...)

---

From: Eliot Lear <[email-masked]>
Date: Mon, 04 Mar 2013 08:35:02 +0100

> that standing advice to the NomCom should be to appoint such a candidate.

It seems to me that the standing advice should be to consult with the
IESG about the matter to determine an appropriate course of action.  The
result in this case was that the IESG wants to openly consult with the
transport area before moving forward.  I think that's quite wise.

Eliot

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 4 Mar 2013 07:57:50 +0000

On Mar 3, 2013, at 18:42, Joel M. Halpern <[email-masked]> wrote:
> Otherwise, the AD gets a directorate review calling out congestion problems.  He puts in the discuss. And can not discuss it with the other ADs.  It is not his discuss.  He can not work out how to resolve it.
> 
> Directorates are critical.  I would hope tat all areas can move to a situation where finding the issues rests primarily with the directorates.  But the AD has to have enough details in his area to deal with it.

+1

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 4 Mar 2013 08:07:17 +0000

Hi,

> Were money not an issue, filing this position would be easy.  

it's not money issue. There are basically two pools of qualified people for a TSV AD position that requires a CC background: academia and industry.

Academia typically means folks on tenure track. Putting that on hold for 2-4 years - even if someone (e.g., ISOC) would pay for the involvement - is not going to happen. You'd be severely risking getting tenure. Even for someone that already is tenured, the time commitment is too high.

There are qualified people in the industry, and that's where most of the past ADs have come from. In the last few years, it's been increasingly harder to get them to step forward, because their employers are reluctant to let them spend the time. I actually think that this is because employers realize that these skills are important and rare to find, and so you want these guys to work on internal things and not donate them to the IETF.

Lars

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 04 Mar 2013 08:18:29 +0000

> Brian has suggested that (b) is more important than (a).

What I'm saying is that if you have nobody that satisfies all three
constraints, you have to make a choice, and the choice of (b)+(c)
is a legitimate judgment call. I don't know whether NomCom did this
and submitted it to the confirming body, or whether the NomCom failed
to make a choice.

Incidentally, while mulling this over, it occurred to me that RFC 3777
doesn't (I believe) talk about conflict of interest within the
confirming bodies. I do recall members of the IAB and the ISOC Board
recusing themselves from confirmation discussions on occasion, but that
was done on an ad hoc basis. I wonder whether we should write something
down about this.

    Brian

---

From: Melinda Shore <[email-masked]>
Date: Sun, 03 Mar 2013 23:24:09 -0900

> was done on an ad hoc basis. I wonder whether we should write something

I tend to be unenthusiastic about publishing more process document
but this sort of thing seems very worthwhile.  If nothing else it
seems worthwhile to think about and clarify our own policies.

Melinda

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 4 Mar 2013 12:45:00 +0200

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:

> 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

---

From: Eric Burger <[email-masked]>
Date: Mon, 4 Mar 2013 07:18:04 -0500

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.

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 4 Mar 2013 13:07:09 +0000

Hi,

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

what is "the fix"?

The IETF is set up so that the top level leadership requires technical expertise. It is not only a management job. This is a key differentiator to other SDOs, and IMO it shows in the quality of the output we produce. The reason the RFCs are typically of very good quality is that the same eyeballs go over all documents before they go out. This creates a level of uniformity that is otherwise difficult to achieve. But it requires technical expertise on the top, and it requires a significant investment of time.

I don't see how we can maintain the quality of our output if we turn the AD position into a management job. Especially when technical expertise is delegated to bodies that rely on volunteers. Don't get me wrong, the work done in the various directorates is awesome, but it's often difficult to get them to apply a uniform measure when reviewing, and it's also difficult to get them to stick to deadlines. They're volunteers, after all. 

And, as Joel said earlier, unless we delegate the right to raise and clear discusses to the directorates as well, the AD still needs to be able to understand and defend a technical argument on behalf of a reviewer. If there is a controversy, the time for that involvement dwarfs the time needed for the initial review.

There is no easy fix. Well, maybe the WGs could stop wanting to publish so many documents...

Lars

---

From: Ralph Droms <[email-masked]>
Date: Mon, 4 Mar 2013 08:38:06 -0500

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

I think part of the fix is to consider more than just the IESG.  We need to take look at the work across the IETF that goes into producing our documents and see if we can redistribute or reduce that work to lessen the workload on ADs ... if the goal is, indeed, to reduce the time commitment on individual ADs.

> 
> The IETF is set up so that the top level leadership requires technical expertise. It is not only a management job. This is a key differentiator to other SDOs, and IMO it shows in the quality of the output we produce. The reason the RFCs are typically of very good quality is that the same eyeballs go over all documents before they go out.

But that model doesn't scale.  What about, for example, ensuring the quality in the documents as they come out of the WGs?, which distributes the work rather than concentrating it in IESG?

> This creates a level of uniformity that is otherwise difficult to achieve. But it requires technical expertise on the top, and it requires a significant investment of time.

Agreed.
> 
> I don't see how we can maintain the quality of our output if we turn the AD position into a management job.
> Especially when technical expertise is delegated to bodies that rely on volunteers. Don't get me wrong, the work done in the various directorates is awesome, but it's often difficult to get them to apply a uniform measure when reviewing, and it's also difficult to get them to stick to deadlines. They're volunteers, after all. 
> 

Sure, for any specific issue.  My personal experience is that I spend more time on the ordinary review processes than I do summing up the time on extra-ordinary technical arguments.

> There is no easy fix. Well, maybe the WGs could stop wanting to publish so many documents...

- Ralph

---

From: Eric Burger <[email-masked]>
Date: Mon, 4 Mar 2013 08:39:42 -0500

There is obviously no easy fix.  If there was, we would have fixed it, obviously.

What I find interesting is after saying there is nothing we can do, you go on to make a few concrete proposals, like bringing the directorates more into the process.  It is thinking like that, how to do things different, that will get us out of the bind we have made for ourselves.

Note that I am not married to the idea of expanding the role of directorates. I am married to the idea that we can think ourselves outside of the box.

---

From: Hector Santos <[email-masked]>
Date: Mon, 04 Mar 2013 09:10:52 -0500

One item to consider is to lower the work load of the AD, in particular 
in reviewing docs towards of the end of projects.  Issues and dilemmas 
are piled on.   I think one approach to lowering appeals, for example, 
is  to address unresolved delicate WG issues much faster, in particular 
the tough ones that reach an impasse and no normal "Rough" WG 
consensus.  This is where the AD may and has helped but I also suggest 
we have a group of peers that can quickly resolve (make decisions) the 
more  delicate WG issues that tends to hold back progress and piled more 
work on people to do which runs the risk of lower quality result and 
also apathy (give up on the work). It may better to ignore it to avoid 
endorsing a controversial direction.   I have had two ADs in the past 
both apologize for not dealing with issues (reading the I-D) a lot sooner.

Perhaps, we should look at some of the IETF activities that makes it 
less appealing to even "apply" for the "job."

On 3/4/2013 8:07 AM, Eggert, Lars wrote:
> Hi,
>
> On Mar 4, 2013, at 13:18, Eric Burger<[email-masked]>  wrote:

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 04 Mar 2013 14:34:56 +0000

Brian

There is a subtly in the manager vs technical expert debate that is
worth noting.

There are some technical managers who could do the job by leveraging
the use of experts and coming up to speed on the key issues very quickly.
However I would suggest that they are at least as rare and certainly at
least as valuable to their employers as  technical experts pool that
we normally draw on.

The level of competence needed would put such managers on a xVP
or C* trajectory, and it seems to me that they are likely to be even
more reluctant to take a career  gap than the academic community.

So it's not that the managers concept does not work, it's that it is
even harder to identify them with some degree of certainly and
then recruit the ones that the IETF would need.

- Stewart

---

From: John Leslie <[email-masked]>
Date: Mon, 4 Mar 2013 09:57:57 -0500

Eggert, Lars <[email-masked]> wrote:
>> 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.
> 
> what is "the fix"?

   There is an obvious place to look for ideas: the directorates. See:

http://www.ietf.org/iesg/directorate.html

   We see that there are a number of differing implementations of these,
even if the explanations try to follow RFC 2418. Variety is good!

> The IETF is set up so that the top level leadership requires technical
> expertise. It is not only a management job.

   Indeed -- we reject traditional management almost as much as kings
and presidents. ;^)

> This is a key differentiator to other SDOs, and IMO it shows in the
> quality of the output we produce. The reason the RFCs are typically
> of very good quality is that the same eyeballs go over all documents
> before they go out.

   (which doesn't scale...)

> This creates a level of uniformity that is otherwise difficult to
> achieve. But it requires technical expertise on the top, and it
> requires a significant investment of time.

   Wearing the hat of senior Narrative Scribe, I have watched the IESG
deal with the increase in the number of documents they must review.
I see a lot of variety, including folks saying, "I'm not reviewing
this one." I've been seeing a lot more reliance on the RFC Editor to
work with authors based on "notes" attached to approved drafts.

   I will agree we need a broad range of expertise at the top; but we
are learning to work around holes in that broad range. This does not
bother me -- I date back to when there was _no_ barrier to publishing
an RFC.

   Other folks worry about this more than I do -- that's fine. But
wishing does not make it so.

   Directorates _could_ fill some of these holes; but it's not obvious
that they always do. I suggest that those of us who worry about the
holes put more effort into _how_ directorates could fill them, since
we have long passed the point where fifteen experts can cover the
whole field.

> the AD position into a management job.

   (I really don't think there's much danger of that.)

> Especially when technical expertise is delegated to bodies that rely
> on volunteers.

   We're _all_ volunteers!

> Don't get me wrong, the work done in the various directorates is
> awesome, but it's often difficult to get them to apply a uniform
> measure when reviewing,

   How important is that, really?

> and it's also difficult to get them to stick to deadlines. They're
> volunteers, after all. 

   I don't think we really "believe in" deadlines. I suspect we think
of deadlines as "damage we need to route around." ;^) Nonetheless, we
could improve the overall result with any of a number of management
tools. (Fundamentally, there will be a typical distribution of time-
in-queue for directorate reviewers; and ADs waiting for reviews could
prod before the scheduling becomes critical. Also, a system of noting
review opportunities to the whole directorate, and accepting partial
reviews from multiple members would improve information flow...)

> And, as Joel said earlier,

   (Joel has pointed out in private email how I misunderstood what he
was saying... my apologies.)

> unless we delegate the right to raise and clear discusses to the
> directorates as well,

   I don't think anyone wants to go there!

> the AD still needs to be able to understand and defend a technical
> argument on behalf of a reviewer.

   Indeed, that is a common belief... but it has scaling problems.

   We might note that almost every DISCUSS by IETF Chair Russ Housley
refers to a particular Gen-ART reviewer. I can't offhand recall a
single case where Russ was asked to "defend" a technical argument of
a Gen-ART reviewer. (Sometimes, he does add his own description: does
that count?)

   The General Area is the most obvious place where scaling has hit
us: the IETF Chair has grown so far beyond full-time that something
has to give. Russ, I believe, reads Gen-ART reviews, not the original
documents, and points out areas that rise to DISCUSS level. He asks
for text to "address" these issues, and tends to clear his DISCUSS
once the issue is better understood. (I should perhaps note that
today's IESG has made great progress in trusting each other to put
significant concerns in RFC Editor notes instead of continuing to
block documents.)

> If there is a controversy, the time for that involvement dwarfs the
> time needed for the initial review.

   I don't believe that's entirely true. Perhaps some IESG members can
offer more information here.

> publish so many documents...

   ;^)

---

From: Mary Barnes <[email-masked]>
Date: Mon, 4 Mar 2013 09:11:58 -0600

>> The IETF is set up so that the top level leadership requires technical expertise. It is not only a management job. This is a key differentiator to other SDOs, and IMO it shows in the quality of th…
[MB] Personally, I'm not at all seeing this concept of uniformity in
terms of the output. I don't even see consistency amongst documents
for specific WGs.  We can't even agree how normative language should
be used in documents.  I've been a gen-art reviewer for 9.5 years and
we don't even come close to producing consistent documents.  I fully
agree that there is significant value in the cross area reviews, in
particular for security.  But, I personally think that can happen as
effectively at the directorate review as at the IESG level of review.
[/MB]
>> I don't see how we can maintain the quality of our output if we turn the AD position into a management job.
[MB] I don't think anyone is suggesting to turn it into just a
management job.  It still requires someone with significant technical
expertise in other areas. I don't think there's anyone hanging around
in IETF that's being considered for IESG positions that doesn't have
significant technical expertise in some areas.  This problem has been
around since I was Nomcom chair, so it seems that there is no easy
solution - would there be a way to split the role, so that you do have
a solid technical advisor, they just have to bother with reviewing
documents unless they are brought to their attention and they don't
have to worry about managing the day to day activities of WGs.  I
would be curious to know the typically time split between these two
tasks for the average AD.   [/MB]

Especially when technical expertise is delegated to bodies that rely
on volunteers. Don't get me wrong, the work done in the various
directorates is awesome, but it's often difficult to get them to apply
a uniform measure when reviewing, and it's also difficult to get them
to stick to deadlines. They're volunteers, after all.
[MB] This is where some people management skills come into place. [/MB]
>>
>> And, as Joel said earlier, unless we delegate the right to raise and clear discusses to the directorates as well, the AD still needs to be able to understand and defend a technical argument on behalf of a reviewer.
[MB] That's true, but the effort is typically in identifying the
discuss and my perspective would be that the AD would consult with the
reviewer before clearing a discuss.  I do find it quite puzzling that
folks seem to think the ADs are the only ones qualified to review and
identify issues in documents at this stage.  For my documents, while I
think the ADs might have identified gaps or areas where clarification
would be useful, but I haven't found those to be of more value than
gen-art reviews, for example.
[/MB]
If there is a controversy, the time for that involvement dwarfs the
time needed for the initial review.

---

From: Mary Barnes <[email-masked]>
Date: Mon, 4 Mar 2013 09:18:07 -0600

> more reluctant to take a career  gap than the academic community.
[MB] I totally disagree. Not everyone aspires to be an xVP or anywhere
near C* role. [/MB]
> then recruit the ones that the IETF would need.
[MB] I think the issue is that this community has great difficulty
recognizing these folks, because they don't have those skills
themselves and the technical expertise is generally the primary and
sometimes only criteria in appointing IESG members.  The Nomcom
process does not require that the voting members have any experience
at all in hiring - for some folks this may be the first time they've
ever interviewed someone for a position and that's been clear to me in
interviews I've had with NOmcom..   Certainly, the nomcom chair can
try to compensate somewhat for this inexperience since the primary
skill needed by an Nomcom chair is the ability to manage a process and
people. [/MB]

---

From: Russ Housley <[email-masked]>
Date: Mon, 4 Mar 2013 10:26:24 -0500

The leadership in the ITU does not read the documents.  Why?  Their job is to make sure that the process was followed.

The IESG needs to make sure the process was followed too.  But, the IESG also has a quality check job.  I would hate for this debate to lead to a step toward the ITU model.

Russ

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Mar 2013 10:37:10 -0500

I think tasking the IESG to look at how to reduce the time commitment
would be an incredibly good idea.  I'd feel a lot more comfortable with
the community giving the IESG clear guidance that we'd like them to
solve that problem than with the community trying to come up with the
solution.

That said, note that there are a number of AD candidates who do take
explicit advantage of the full-time nature of the job.  They get
involved in IETF tools development, coordination between the IETF and
other organizations, process reform, unstucking major issues that need
to be unstuck.
That's all great, but it does all take time.

I'd like to  live in an IETF where we have room for people who do want
to spend a lot of time on all those issues as well as a place where ADs
can take responsibility for the technical work in their area  and
minimize time commitments.

I think the balance between personal review and trusting others is
something that will shift both for individual ADs and over time.  I'd
hate to see the community over-constrain that.

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 4 Mar 2013 15:42:07 +0000

Hi,

>> Especially when technical expertise is delegated to bodies that rely

right, but ADs are basically full-time volunteers of whom the community expects a certain timeliness in terms of their actions and decisions. If those actions are delegated to volunteer bodies that feel less strongly about timeliness, the community isn't going to be very happy with the delays, or the review quality is going down (because some don't happen).

>   How important is that, really?

I feel it is important. If some IDs get discusses for a certain problems and others slide under the radar, that's not a great result.

>   I don't think we really "believe in" deadlines.

Really? After all the scribing you've done, surely you know that almost all the IESG reviewing happens on very strict deadlines. Two weeks, and in rare cases a defer adds another two weeks. Reviews not in by that time come too late.

It *is* a challenge to get directorate reviews to appear within that timeframe. When Magnus and me ran the TSV directorate, we tried to schedule directorate reviews during IETF LC, and still quite a number didn't arrive by the IESG telechat date.

> significant concerns in RFC Editor notes instead of continuing to

I think SAAG is a better example. The general area has no technical focus area it's responsible for, and so the reviews are all over the place. (But they are still useful! More eyes help.) But even with the large amount of quality reviewing SAAG is doing, the expertise of the SEC ADs is still crucial. I wouldn't want to only rely on SAAG.

If a "management AD" wanted to substitute directorate expertise for personal expertise, that particular directorate would as a whole need to operate under the timeliness, consistency and quality constraints that a "technical expert AD" would. I simply don't see that happening.

Lars

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 4 Mar 2013 10:42:41 -0500 (EST)

> From: Randy Bush <[email-masked]>
> 

One possibility might be to split TSV into two areas, so the workload
on the TSV ADs (both technical and social) is reduced.

Dale

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 4 Mar 2013 16:47:25 +0100

+1, if anything we need to  move away from the ITU model. 

/Loa

Skickat från min iPhone

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 4 Mar 2013 15:48:09 +0000

> on the TSV ADs (both technical and social) is reduced.

Doesn't help much. Management of ones area takes some time, but at least as much time is spend on dealing with document review and discussions outside the area.

Lars

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 04 Mar 2013 16:21:15 +0000

+1 to Mary's comments.. few words in line..

Elwyn Davies
> effectively at the directorate review as at the IESG level of review.
[EBD] I have also been a gen-art reviewer for about a long as Mary and I
totally agree that consistency is not what we get, especially on the
quality front.  However really the only consistencies that are really
vital are comprehensibility and technical quality.  Variations in style
make life a little more entertaining and I would prefer not to resort to
some sort of uniform legalese - in any case, not all drafts are talking
about the same sort of thing. And, yes, multiple reviews with different
points of view do help. [/EBD]

> tasks for the average AD.   [/MB]

[EBD] Maybe the difference between what I do and the AD's reviewing job
is context.  Mine is diffuse - I have a general idea what is going on
and enough background to recognize when something might be broken; I
also have enough understanding to recognize when a novice would get lost
in a document that has its head down in the sands of jargon and
groupthink. We call ADs AREA Directors presumably because they have the
context of their area in mind when reviewing; I don't. Hopefully, an AD
is not seeing a doc that comes to the IESG for the very first time
because s/he has got some idea of what is going on in the WG or has
sponsored a doc. Hopefully (again) this gives the AD some context in
which to view the document, know its importance overall, interpret
comments from others and home in on key areas where they anticipate
there might be concerns; so there is synergy between the managemnt and
technical reviewing tasks.  Area directorates probably fall in between
on the context scale.  But ultimately the AD is called upon to make one
or more judgment calls both as regards documents and the performance of
WGs.  I would be extremely unhappy if these calls were purely management
exercises - they need a combination of technical nous, management acumen
and wider understanding of the importance of what is being done to allow
ADs to put their limited brain cycles into the most valuable work.
[Do I here somebody saying "And how do we define most valuable?" -
perhaps we come down to that difficult to hire characteristic.. common
sense.]   Doubtless this is hopelessly utopian, but having an AD with
his or her finger on the technical and value pulses of the area seems to
be the key to having an effective AD - they aren't just reviewing
machines! [/EBD]

> >> There is no easy fix. Well, maybe the WGs could stop wanting to publish so many documents...
[EBD] .. and be a little more succinct in how they say things. :-)
[/EBD]

---

From: Dave Crocker <[email-masked]>
Date: Mon, 04 Mar 2013 08:40:19 -0800

> The IESG needs to make sure the process was followed too.  But, the IESG also has a quality check job.  I would hate for this debate to lead to a step toward the ITU model.

As specious lines of logic go, your note was pretty efficient.  It 
ignored the specifics of the concerns being raised in this thread, their 
merits, and the suggestions being made, and it invokes a cliche'd 
bogeyman.

For example, the suggestions being made do not intent or imply that 
there would be no technical content to the work of an AD. Also note that 
there are many things that the ITU does; are we supposed to make a point 
of not doing any of them, simply because the ITU does them?

The IETF culture, structure and process are massively different from the 
ITU's.  None of the changes being proposed would turn the IETF into the 
ITU or even move us towards them.

If the merit of a suggestion is good or bad, let's focus on that, rather 
than on who else is or is not doing it.

But if you really want to focus on ITU fear, take a look at the time it 
now takes to produce IETF specs, their increased complexity and the 
degree of their eventual industry deployment.  A comparison on the style 
and substance of IETF vs. ITU technical work might prove enlightening...

d/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 04 Mar 2013 09:42:22 -0700

On 3/4/13 6:38 AM, Ralph Droms wrote:
>> The IETF is set up so that the top level leadership requires 
>> technical expertise. It is not only a management job. This is a
>> key differentiator to other SDOs, and IMO it shows in the quality
>> of the output we produce. The reason the RFCs are typically of
>> very good quality is that the same eyeballs go over all documents
>> before they go out.
> 
> But that model doesn't scale.  What about, for example, ensuring
> the quality in the documents as they come out of the WGs?, which 
> distributes the work rather than concentrating it in IESG?

There is technical work other than late-stage document reviews. We
might get a larger return on investment if community members who are
temporarily serving in the area director role were to spend more of
their combined technical and management talent on making sure that our
working groups are solving the right engineering problems for the
long-term health of Internet. If that leads to fewer working groups
producing higher-quality output, so be it.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Allison Mankin <[email-masked]>
Date: Tue, 5 Mar 2013 00:45:58 +0800

> hate to see the community over-constrain that.

I strongly agree with Sam's point here.  When we have these
discussions, we often try to over-engineer the people aspects.
Especially given our nomcom process (versus the hiring process that
proceeds from inside a management or a standing board),
over-constraining is pretty doomed.

Allison

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 4 Mar 2013 11:50:04 -0500

> producing higher-quality output, so be it.

I'd go further and say, "That's a bonus."

A

-- 
Andrew Sullivan
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 04 Mar 2013 17:10:56 +0000

Russ,

I would never argue for non-technical ADs. But when we are short
of candidates, it may be necessary to appoint technically expert ADs
who are not deep experts in the specific area. It's a practical
matter.

Regards
   Brian

---

From: Randy Bush <[email-masked]>
Date: Tue, 05 Mar 2013 02:11:28 +0900

> producing higher-quality output, so be it.

It's perfectly appropriate to be upset.  I thought of it in a slightly
different way -- like a space that we were exploring and, in the early
days, we figured out this consistent path through the space: IP, TCP,
and so on.  What's been happening over the last few years is that the
IETF is filling the rest of the space with every alternative approach,
not necessarily any better.  Every possible alternative is now being
written down.  And it's not useful.  -- Jon Postel

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 4 Mar 2013 11:25:30 -0600

My humble suggestion is to go with a single AD for Transport Area. I think
it could work.

Regards,

Behcet

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Mar 2013 12:34:34 -0500

Brian> Russ, I would never argue for non-technical ADs. But when we
    Brian> are short of candidates, it may be necessary to appoint
    Brian> technically expert ADs who are not deep experts in the
    Brian> specific area. It's a practical matter.

I actually think expecting ADs to learn a fair bit on the IESG is part
of coming up to speed on the IESG.  I'm aware of people who served on
the IESG with me who had significant gaps in material their area
covered.  In some cases, this was solved by splitting work load.  In
some cases it was covered by having the AD learn a lot.  In one case the
AD came in having huge gaps in half of the area in question. Today that
person is considered an expert in one of the areas where he had the
largest gaps and is focusing most of his effort there.

I wouldn't want someone  on the IESg without a strong technical presence
in the IETF.
It matters less to me whether it's in the area in question.

And yes, I've thought about how I'd feel if someone jumped from another
area to security. I can think of a number of APS or RAI ADs who I think
could succeed in the security area if they decided to put in the effort
to learn on the job. It would be a huge investment in effort, but it
could succeed.

IESG-level review of a document really is a skill that can be
learned. It helps to have a lot to draw on, but I don't believe anyone
can (or does) have coverage of all the areas they are reviewing. The
huge part of the skill is to figure out how to do the technical job even
given that.
It involves trusting others sometimes, reading discussions, learning new
things. Sometimes though, you do just have to spend the effort to
understand some particular issue well enough to make an informed
opinion.

Having experts in areas doesn't escape this. When there's an appeal or a
disagreement between areas it can be important for ADs to come up to
speed on an issue outside their area and make an informed decision about
it.

So in conclusion, I strongly value technical contribution and
demonstrated ability to pick up new knowledge in an AD. I do not highly
value knowing all the things going on in a specific area at the time the
AD joins the IESG.

--Sam

---

From: Mary Barnes <[email-masked]>
Date: Mon, 4 Mar 2013 11:37:55 -0600

> value knowing all the things going on in a specific area at the time the
[MB] I totally agree.  That's one of the points I've been trying to
make (in a far less succinct manner). [/MB]

---

From: Russ Housley <[email-masked]>
Date: Mon, 4 Mar 2013 12:44:39 -0500

Dave:

> As specious lines of logic go, your note was pretty efficient.  It ignored the specifics of the concerns being raised in this thread, their merits, and the suggestions being made, and it invokes a cliche'd bogeyman.
> 
> For example, the suggestions being made do not intent or imply that there would be no technical content to the work of an AD. Also note that there are many things that the ITU does; are we supposed to make a point of not doing any of them, simply because the ITU does them?
> 
> The IETF culture, structure and process are massively different from the ITU's.  None of the changes being proposed would turn the IETF into the ITU or even move us towards them.
> 
> If the merit of a suggestion is good or bad, let's focus on that, rather than on who else is or is not doing it.
> 
> But if you really want to focus on ITU fear, take a look at the time it now takes to produce IETF specs, their increased complexity and the degree of their eventual industry deployment.  A comparison on the style and substance of IETF vs. ITU technical work might prove enlightening...

Several people suggested that the AD could be a manager with little technical clue.  I raised the extreme of that line of thinking.

It is clear that no single person has all of the detailed knowledge to review every aspect of every IETF document.  That said, it is very important that the AD have enough clue to detect a probable concern, and then they can turn to appropriate experts in the form of directorates, personal contacts, or even a plea for the right mail list.  This requires some insight into the core technologies for the area and good working relationships within the area.

Russ

---

From: Mary Barnes <[email-masked]>
Date: Mon, 4 Mar 2013 11:51:40 -0600

> Several people suggested that the AD could be a manager with little technical clue.  I raised the extreme of that line of thinking.
[MB] I don't think anyone has said an AD could be a manager with
little technical clue.  I think Sam said it extremely well in his
email.  What some of us have been proposing is that someone with
proven technical skills in another area that also is good at managing
projects/people could do a reasonable job.  From what I have seen this
has certainly been the case in other areas - i.e., ADs that don't have
depth of knowledge in all the WGs in their areas, but are strong
technical individuals in other areas.  The problem seems to be that
folks value the technical expertise far more than they do project and
people management skills.   The end result is that there are some
really strong technical people in leadership roles that have little
ability to manage things well and very poor people interaction skills.
 The latter is certainly a very negative personality trait when it
comes to motivating and managing volunteers. [/MB]

---

From: Scott Brim <[email-masked]>
Date: Mon, 4 Mar 2013 18:19:40 +0000

On 03/04/13 12:51, "Mary Barnes" <[email-masked]> allegedly
wrote:
>projects/people could do a reasonable job.

Yes because they have demonstrated technical clue and therefore have
already demonstrated that they can pick up the essence of the issues in an
area, enough to ask the right questions and have insight into priorities -
otherwise they couldn't have got where they are.  We've done this before.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 04 Mar 2013 20:14:48 +0100

Mary:

On 3/4/13 6:51 PM, Mary Barnes wrote:

> technical individuals in other areas. 
>

I am very sorry to have to say this, but we are all dancing around the
issue that we have experience of where the above has been shown to
simply not work well.  And this is why it is important for a NOMCOM that
gets into such a situation to do exactly what this NOMCOM did: consult
with the IESG to determine the need to "have a body" versus have the
right person.

>  The problem seems to be that

That happens from time to time, let's agree.  And maybe it is the price
we pay for the model we have.  And maybe that's a trade-off worth
having.  This is not to say that the IESG shouldn't evolve its working
methods, by the way.  But it is possible to get it wrong.

Eliot

---

From: Russ Housley <[email-masked]>
Date: Mon, 4 Mar 2013 14:19:24 -0500

>> value knowing all the things going on in a specific area at the time the

We mostly agree.  We both agree that strong technical contribution is an important aspect of the qualification.  However, I believe that some basic clue in the Area is needed.

Could you image serving with a Security Co-AD that could not explain how cryptography could be used for authentication?

Without some fundamental understanding, I do not see how the AD would know when to seek additional expert review.

Russ

---

From: Eliot Lear <[email-masked]>
Date: Mon, 04 Mar 2013 20:33:52 +0100

Sam,

> largest gaps and is focusing most of his effort there.

We're here because of the extremely specialized nature of transport. 
PhDs who specialize in it have gotten it wrong.  One such person drove
Van Jacobson into the field, as I recall. There are very few people who
get it right.  And yet it's so close to the waist of the hour glass that
it's critical to get right.  Security has a lot of visibility and so it
will never have this very same problem.

> value knowing all the things going on in a specific area at the time the

Please let's not overgeneralize.  I'm not on the NOMCOM but I know it is
not every area we are having this problem, it's transport.

Eliot

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Mar 2013 14:58:58 -0500

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> Sam,
    Eliot> On 3/4/13 6:34 PM, Sam Hartman wrote:

    Eliot> We're here because of the extremely specialized nature of
    Eliot> transport.  PhDs who specialize in it have gotten it wrong.
    Eliot> One such person drove Van Jacobson into the field, as I
    Eliot> recall. There are very few people who get it right.  And yet
    Eliot> it's so close to the waist of the hour glass that it's
    Eliot> critical to get right.  Security has a lot of visibility and
    Eliot> so it will never have this very same problem.

I absolutely agree that there are few people who can design certain
aspects of transport protocols.
(I'll note that security has this problem too: designing crypto is
really hard; I wouldn't be too quick to be sure that transport is so
much more difficult than the hardest problems of other areas.)

Fortunately, an AD need not do all the work in their area; they only
need to review it.

The entire IETF is founded on the idea of consensus. Central to that is
the idea that we can get together as a group and by doing so we'll come
up with better specifications.  Not every person will be able to design
the inputs to that process: new proposals and discoveries of problems in
existing proposals.  Some aspects of that really do require expert
knowledge.

my claim is that the AD skill set should be focused around evaluating
these inputs, coming up with an opinion, and explaining that opinion to
others. I don't believe that reviewing internet-drafts in transport,
reviewing reviews of thoes drafts, evaluating whether enough review has
happened, making an informed opinion about issues that were raised and
explaining that opinion to the community requires the same level of
expertise in transport as designing TCP.  It does require significant
experience, both technical and management.

I stand behind my original comments.

---

From: Mary Barnes <[email-masked]>
Date: Mon, 4 Mar 2013 14:09:59 -0600

> with the IESG to determine the need to "have a body" versus have the
[MB] I mentioned in another email that yes, indeed, we do have
experience where appointing someone that didn't have the depth of
knowledge did not work well. But, as I said in my email, I don't so
much think it was because the filling of the position with an
individual so much as it was the fact that there is no way for a
Nomcom to anticipate how an individual will actually behave once they
are appointed. We've had some exceptionally talented technical people
that have been appointed AD that haven't performed nearly as well as
one might anticipate.

Since, this is also the exact same situation faced by the Nomcom that
I chaired and the issue was actually highlighted in my Nomcom report:
http://tools.ietf.org/id/draft-barnes-nomcom-report-2009-00.txt
It's not clear to me that the IESG every seriously considered the
problem nor put a plan in place to avoid it in the future.  I don't
think anyone was surprised when Wes didn't re-up that it was going to
be extremely difficult to find the right replacement.
[/MB]

---

From: Mary Barnes <[email-masked]>
Date: Mon, 4 Mar 2013 14:11:12 -0600

And, I continue to support Sam's position as well.

To me the question at hand is whether it will do more harm to fill the
position with someone that doesn't have the specific expertise that
his being sought than to leave the position unfilled.   Having dealt
with the exact same issue when I was Nomcom chair, I thoroughly
understand the issue at hand.  And, certainly, there was a lot of
criticism of the choice of the Nomcom I chaired, but we really are
between a rock and a hard place yet again.

Regards,
Mary.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Mar 2013 15:26:46 -0500

>>>>> "Mary" == Mary Barnes <[email-masked]> writes:

    Mary> And, I continue to support Sam's position as well.  To me the
    Mary> question at hand is whether it will do more harm to fill the
    Mary> position with someone that doesn't have the specific expertise
    Mary> that his being sought than to leave the position unfilled.
    Mary> Having dealt with the exact same issue when I was Nomcom
    Mary> chair, I thoroughly understand the issue at hand.  And,
    Mary> certainly, there was a lot of criticism of the choice of the
    Mary> Nomcom I chaired, but we really are between a rock and a hard
    Mary> place yet again.

I think it would be really useful to get someone like Lars or the chair
of the tcpm working group to comment on how much congestion control
experience we're talking about as a requirement.

When I read Lars's messages, I'm not actually sure he and I are
disagreeing.  

There's a lot of things it could mean for the IESG to have congestion
control expertise.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Mar 2013 16:12:27 -0500

>>>>> "Russ" == Russ Housley <[email-masked]> writes:

    Russ> Sam:
    >>> demonstrated ability to pick up new knowledge in an AD. I do not
    >>> highly value knowing all the things going on in a specific area
    >>> at the time the AD joins the IESG.

    Russ> We mostly agree.  We both agree that strong technical
    Russ> contribution is an important aspect of the qualification.
    Russ> However, I believe that some basic clue in the Area is needed.

    Russ> Could you image serving with a Security Co-AD that could not
    Russ> explain how cryptography could be used for authentication?

Russ, we both served with someone who joined the IESG with gaps this big
(not security).  It worked out OK, although it was quite rough for the
person involved and for the co-ad.
I also have some experience helping people learn about security.
I do think I can imagine serving with someone like that, yes; it's frightening.

While I think I have an existence proof that it can work with big gaps
like that, no it would not be my choice to serve  with someone who had
those gaps.

To use security examples we're both familiar with, my claim is that
there are a lot of people outside the security area who have used
security technologies and who could explain for example how
cryptographic authentication works. There are a lot of people running
around RAI with a fair bit of security clue.  Some of those people might
have enough implementation or other experience to understand significant
details of a couple of security protocols. It wouldn't surprise me if
some of those folks had the skills to know when additional review was
required and to learn fast enough that it would work out for them to be
security ADs.
(Now why they'd want to do that to themselves is another story
entirely:-)

No, I don't think you can drop someone who is unfamiliar with an area
into an AD job. I do think you can potentially throw  someone into an AD
job who has broad IETF experience and who has some familiarity with the
area in question.
I am having a hard time characterizing how much experience is needed,
but I think it's a lot lower than "world expert," but very much higher
than "couldn't follow important discussions in the area."

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 4 Mar 2013 16:48:41 -0500

The problem with this argument is that it appears that we have a choice between "limited knowledge of congestion control" and "an empty seat".  Which one is more likely to be able to learn about it?

Margaret

---

From: Russ Housley <[email-masked]>
Date: Mon, 4 Mar 2013 17:05:30 -0500

> The problem with this argument is that it appears that we have a choice between "limited knowledge of congestion control" and "an empty seat".  Which one is more likely to be able to learn about it?

If that were the extent of this discussion, then the answer would be obvious.  It is not that simple.

This is not the first time we have experienced difficulty in filling the Transport AD seat.  Frankly, since RAI was extracted from Transport this has been a recurring concern.  At various points over the last three years, there have been discussions about reorganization.  That topic has come up on this thread already.

So, the community is faced with two choices:
(1) fill the seat with someone with limited knowledge of congestion control, but adequate time commitment to do the job; or
(2) reorganize the areas in some fashion.

Russ

---

From: Dave Crocker <[email-masked]>
Date: Mon, 04 Mar 2013 14:19:55 -0800

> The problem with this argument is that it appears that we have a choice between "limited knowledge of congestion control" and "an empty seat".  Which one is more likely to be able to learn about it?

Carefully considering the tradeoffs and requirements seems to be the 
corre challenge here.

To extend this point further:

      We've defined job requirements that produce an extremely small 
pool of candidates.  In the case of TSV, the pool is zero, but in others 
it is also problematic.  This is a long-standing problem, but we keep 
ignoring it.

      Rather than carefully consider the essential job requirements -- 
in terms of the core work that must be done by an AD -- we seem to think 
that we can continue with unchanged job requirements.

      ADs do not 'lead' the work of their area.  They do not initiate 
the work, produce the charters or write the specifications.  Work that 
fails or succeeds does so because it has community consensus and demand, 
not because an AD was diligent or clever.  The job of an AD is to 
facilitate community efforts, not to direct them.

      Technical expertise in a technical manager is essential as an 
adjunct to the management.  We keep confusing this essential requirement 
with the kind of work that an individual contributor does.

As long as we maintain that confusion, we will define a job that is too 
demanding, and demands too many of the wrong skills.

d/

---

From: Mary Barnes <[email-masked]>
Date: Mon, 4 Mar 2013 16:28:16 -0600

> (2) reorganize the areas in some fashion.
[MB] Can you expand on this reorganization? This wasn't explicitly
stated in your original email.  How would this make up for not having
someone with Congestion Control expertise, which seemed to be the core
issue that has been discussed on this thread?   Note, I'm not debating
there might be other value in the reorganization, I'm just puzzled as
to how it solves this specific problem.
[/MB]

---

From: Allison Mankin <[email-masked]>
Date: Tue, 5 Mar 2013 06:44:25 +0800

Hi, Russ,

Was there something causative about extracting RAI from Transport?

Allison

---

From: Benoit Claise <[email-masked]>
Date: Tue, 05 Mar 2013 00:05:07 +0100

> http://www.ietf.org/iesg/directorate.html
That would help if the AD job would not be a full time job. Sure.
And I see some suggestions in this email thread to rely more on the 
directorates. That makes sense (but reviews vary greatly, however)
One track not mentioned in this thread is the document shepherd.
The document shepherd job, when done according to RFC 4858 (see 
specifically section 3.2 and 3.3) would save a huge amount of time to 
the AD.
Recently, for a single draft, I spent hoouuurrrssss trying to track all 
the open issues from the directorates and the IESG, and chasing the 
authors. On top of taking some time, I had to be become expert for every 
single aspect of the specification to evaluate whether the answer was 
right... while the document shepherd has already the expertise.
We should probably stress (again) the importance of document shepherd 
function...

Regards, Benoit

---

From: Alia Atlas <[email-masked]>
Date: Mon, 4 Mar 2013 18:11:58 -0500

Perhaps even dedicate a WG-Chairs lunch meeting to it?  I think the
role has grown
over the years.

Alia

On Mon, Mar 4, 2013 at 6:05 PM, Benoit Claise <[email-masked]> wrote:
> The document shepherd job, when done according to RFC 4858 (see specifically
> section 3.2 and 3.3) would save a huge amount of time to the AD.
> Recently, for a single draft, I spent hoouuurrrssss trying to track all the
> open issues from the directorates and the IESG, and chasing the authors. On
> top of taking some time, I had to be become expert for every single aspect
> of the specification to evaluate whether the answer was right... while the
> document shepherd has already the expertise.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 05 Mar 2013 00:19:52 +0100

Considering that mainly WG chairs are document shepherds (*), that would 
be a good start.

(*) but this is absolutely not a requirement. See 
http://www.ietf.org/iesg/statement/document-shepherds.html

Regards, Benoit

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 04 Mar 2013 21:30:07 -0500

On 3/4/2013 3:07 AM, Eggert, Lars wrote:
> There are qualified people in the industry, and that's where most of
> the past ADs have come from. In the last few years, it's been
> increasingly harder to get them to step forward, because their
> employers are reluctant to let them spend the time. I actually think
> that this is because employers realize that these skills are
> important and rare to find, and so you want these guys to work on
> internal things and not donate them to the IETF.

When the TSV ADs asked the directorate about this topic, one of
the things we heard is that transport "features" don't strongly
associate with product lines or features.  So there may also be
a case where management doesn't identify with the value in TSV,
and maybe companies aren't internally developing people as much
for TSV expertise as for other topics.

Also, sponsoring an AD does not seem to be generally feasible for
small companies or services-based companies (compared to product-
based companies) without some outside support, since otherwise
the hours spent ADing are overhead.  This further limits the pool.

-- 
Wes Eddy
MTI Systems

---

From: Russ Housley <[email-masked]>
Date: Mon, 4 Mar 2013 22:24:07 -0500

> to how it solves this specific problem.

The original email point to the requirements for the positions that NomCom is to fill.  A reorganization could change the positions or change the requirements.

Russ

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 5 Mar 2013 10:21:04 +0000

We had such a WG-Chairs session dedicated exactly to this topic (document shepherding) at IETF-82 - including a panel of document shepherds and ADs sharing experience and discussing ways to improve the process and make the shepherds role more efficient. 

Dan

> Alia Atlas
> Sent: Tuesday, March 05, 2013 1:12 AM
> To: Benoit Claise
> Cc: John Leslie; IETF IETF
> Perhaps even dedicate a WG-Chairs lunch meeting to it?  I think the role
> has grown over the years.
> 
> Alia
> 
> >>>> 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.
> >>>
> >>> what is "the fix"?
> >>
> > directorates. That makes sense (but reviews vary greatly, however) One
> > track not mentioned in this thread is the document shepherd.
> > Recently, for a single draft, I spent hoouuurrrssss trying to track
> > all the open issues from the directorates and the IESG, and chasing
> > the authors. On top of taking some time, I had to be become expert for
> > every single aspect of the specification to evaluate whether the
> > answer was right... while the document shepherd has already the
> expertise.

---

From: t.p. <[email-masked]>
Date: Tue, 5 Mar 2013 10:38:08 +0000

----- Original Message -----
From: "Sam Hartman" <[email-masked]>
To: "Mary Barnes" <[email-masked]>
Cc: "Sam Hartman" <[email-masked]>; "IETF" <[email-masked]>
Sent: Monday, March 04, 2013 8:26 PM

> experience we're talking about as a requirement.

Not much, based on my experience:-(

The I-Ds I have been closely involved with have typically drawn DISCUSS
from Security and Transport and while those from Security have usually
given me pause, enlightened me, made me do my homework, those for
Transport seem to be saying that you must not give any encouragement to
the use of UDP and nothing more than that.  I do track TCPM and ICCRG
and have some insight into the sophistication of modern control
mechanisms, but outside those groups, the application of congestion
control seems basic; TCP and its (friendly) derivatives OK, anything
else not OK.

Tom Petch

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 5 Mar 2013 12:03:53 +0100

Hi Dave,

On 03/04/2013 11:19 PM, Dave Crocker wrote:
>> The problem with this argument is that it appears that we have a
>> choice between "limited knowledge of congestion control" and "an
>> empty seat".  Which one is more likely to be able to learn about
>> it?
>
>
> We've defined job requirements that produce an extremely small pool
> of candidates.  In the case of TSV, the pool is zero, but in others
> Rather than carefully consider the essential job requirements -- in
> terms of the core work that must be done by an AD -- we seem to think

Not fully true:
There will be a discussion in the TSVAREA session at the IETF-86 meeting 
in Orlando, exactly discussing the job requirements for the TSV AD position:
https://datatracker.ietf.org/meeting/86/agenda/tsvarea/

   Martin

>
> ADs do not 'lead' the work of their area.  They do not initiate the
> work, produce the charters or write the specifications.  Work that
> fails or succeeds does so because it has community consensus and
> demand, not because an AD was diligent or clever.  The job of an AD
> is to facilitate community efforts, not to direct them.
>
> Technical expertise in a technical manager is essential as an adjunct
> to the management.  We keep confusing this essential requirement with
> the kind of work that an individual contributor does.
>
> As long as we maintain that confusion, we will define a job that is
> too demanding, and demands too many of the wrong skills.
>
> d/
>

-- 
[email-masked]

NEC Laboratories Europe
NEC Europe Limited
Registered Office:
Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB
Registered in England 2832014

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 5 Mar 2013 12:13:33 +0100

Hi Tom,

On 03/05/2013 11:38 AM, t.p. wrote:
> ----- Original Message ----- From: "Sam Hartman"
> <[email-masked]> To: "Mary Barnes"
> <[email-masked]> Cc: "Sam Hartman"
> <[email-masked]>; "IETF" <[email-masked]> Sent: Monday, March
> 04, 2013 8:26 PM
>
>> Mary> chair, I thoroughly understand the issue at hand.  And, Mary>
>> certainly, there was a lot of criticism of the choice of the Mary>
>> Nomcom I chaired, but we really are between a rock and a
> hard
>> Mary> place yet again.
>>
>> of the tcpm working group to comment on how much congestion
>> control experience we're talking about as a requirement.
>
> The I-Ds I have been closely involved with have typically drawn
> DISCUSS from Security and Transport and while those from Security
> have usually given me pause, enlightened me, made me do my homework,
> those for Transport seem to be saying that you must not give any
> encouragement to the use of UDP and nothing more than that.  I do

Can you clarify about what point of time you're talking about? There are 
multiple instances of the IESG and also the TSV ADs and handling of the 
issue might have changed over the years.

The recent instance is good with using UDP, but the draft needs to 
clearly state how it addresses congestion control and that is the point 
where a lot of draft fail.

This has been also the case in the past, when I remember right.

> track TCPM and ICCRG and have some insight into the sophistication of
> modern control mechanisms, but outside those groups, the application
> of congestion control seems basic; TCP and its (friendly) derivatives
> OK, anything else not OK.

Also a very shortened view.

However, TCP and derivatives are well understood in large-scale 
deployments, e.g., in the Internet, others are too, e.g., SCTP, while 
some aren't.

   Martin

>> There's a lot of things it could mean for the IESG to have
>> congestion control expertise.
>
>

NEC Laboratories Europe
NEC Europe Limited
Registered Office:

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 5 Mar 2013 12:22:02 +0100

Brian,

> and trust the relevant Directorate.

Even if the directorate is doing all of its reviews there is still 
plenty of follow-ups to be done by the responsible ADs, e.g., discussing 
with the draft authors on how to address the comments, check the updated 
drafts, discuss with the IESG about this, etc.

This won't go away, even if the directorate is reviewing each and every 
draft.

   Martin

NEC Laboratories Europe
NEC Europe Limited
Registered Office:

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 5 Mar 2013 12:33:20 +0100

Mary,

> technical sanity of the proposal?  ISTM that some of the TSV nominees

We have individuals in the directorate that are experts on congestion 
control and we will have also knowledge in the IESG after Wes will step 
down in the next week, i.e., which is me.

I am not a full congestion control expert like some individuals out of 
the directorate and also the community. But I do understand the topic 
well enough and do know whom to ask in the case of doubt.

However, it is always good to have multiple eyes/2 ADs with a congestion 
control background, as the topic is so sensitive to the proper operation 
of the Internet and sometimes things slip through for a number or 
reasons, i.e., for eyes see more than two eyes.

> experts.  IMHO, that's the most important skill that some ADs lack -

I agree and disagree:
An AD must be a good manager and be able to listen.

But, an AD must have a broad knowledge about the Area's technical 
topics, as the time to dig into all fields is just too scare once you 
are an AD. I.e., there is not enough time to arrive as a manager and to 
learn all the tech topics.

Regards,

   Martin

NEC Laboratories Europe
NEC Europe Limited
Registered Office:

---

From: t.p. <[email-masked]>
Date: Tue, 5 Mar 2013 11:43:01 +0000

----- Original Message -----
From: "Martin Stiemerling" <[email-masked]>
To: "t.p." <[email-masked]>
Cc: "Sam Hartman" <[email-masked]>; "IETF" <[email-masked]>
Sent: Tuesday, March 05, 2013 11:13 AM

Martin

I am looking back over a number of years (eg SNMP, syslog).  A
perspective over many years, in any area, is that some problems become
solved, with changes in technology.  What is post graduate research
becomes the next generation's seventh grade homework.

Congestion control is essential else we have congestive collapse, which
I have had to find and fix in my time; but I am positing that for most
of the IETF, congestion control is a solved topic and little expertise
is needed, in contrast to Security which is for ever changing (SHA2 or
SHA3 or will MD5 still suffice?).  Yes, a high-level of skill exists,
especially in the ICCRG (and I struggle to follow it) but I wonder if we
need that skill in the IETF ie a basic familiarity with what TCP offers
and UDP does not will serve most of our work.

Tom Petch

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 5 Mar 2013 12:27:43 +0000

On Mar 5, 2013, at 12:43, t.p. <[email-masked]> wrote:
> but I am positing that for most
> is needed

I have seen too many WGs trying to build "lightweight" UDP-based application protocols that do not correctly back off under loss to agree with you here.

It's solved IFF a standard transport like TCP is used. Not otherwise. (And even when TCP is used, questions like "how many parallel connections" remain.)

Lars

---

From: <[email-masked]>
Date: Tue, 5 Mar 2013 12:53:13 +0000

Ah, the 'but security, unlike transport,  is actually important' argument.

Having seen subscribers to that philosophy unsuccessfully attempt to design
transport protocols (and raise the MD5 issue repeatedly, because it's
considered a security issue, and they're at home with security), I would argue
that there is a lack of appreciation and understanding  of the nuances of
transport protocol issues in the IETF. Reliability, implications of the
end-to-end protocol, feedback loops...

Today's crypto hash is tomorrow's probably-not-a-collision error detection,
with no claims to security or protection against deliberate attacks.
MD5 has made that transition, just because some collisions can be
calculated. Better protocols will follow, because collisions will
eventually be found. Considering entropy suggests this.

Ethernet CRCs have collisions, but they have a useful role in error
detection. Checksums are not secure, but that is not what they are
used for. And they suffice for that purpose.

No-one complains about Ethernet CRCs or one's complement
checksums (OMG you can swap entire bvtes in TCP and just swap
addresses and the echo server still works!) being insecure. Perhaps
they still should. Being adequate for purpose is not enough if
they're not secure!

I find it difficult to care about the digest function fashion of the day.
(For MD5, see RFC6151.)

But watching security people make a hash of transport protocol
design really isn't fun. That and the lack of transport expertise
concerns me.

Lloyd Wood
http://sat-net.com/L.Wood/dtn

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 5 Mar 2013 08:25:41 -0500

Hi Russ,

> If that were the extent of this discussion, then the answer would be obvious.  It is not that simple.

I understand.  I was responding only to the discussion of the fact that we couldn't find a candidate with expertise in congestion control, so we shouldn't appoint anyone.

If we absolutely need someone with that expertise on the IESG, that isn't likely to be resolved by proposals to reorganize the IESG and/or eliminate this position, either. 

Margaret

---

From: t.p. <[email-masked]>
Date: Tue, 5 Mar 2013 14:10:49 +0000

<inline>
----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 05, 2013 12:53 PM

Ah, the 'but security, unlike transport,  is actually important'
argument.

Having seen subscribers to that philosophy unsuccessfully attempt to
design
transport protocols (and raise the MD5 issue repeatedly, because it's
considered a security issue, and they're at home with security), I would
argue
that there is a lack of appreciation and understanding  of the nuances
of
transport protocol issues in the IETF. Reliability, implications of the
end-to-end protocol, feedback loops...
<snip>
But watching security people make a hash of transport protocol
design really isn't fun. That and the lack of transport expertise
concerns me.

<tp>
We are not talking of transport protocol design - SCTP, DCCP,  ... -
but of Congestion Control design.  The question is can we do with a
Transport Area Director whose congestion control skills are limited; I
am suggesting we can, because of all the work over the years in
congestion control and the relative stability of the topic.

Transport matters, congestion control matters, I am just suggesting that
the latter is not developping so much that we need an AD who is abreast
of the research in it.

Tom Petch

Lloyd Wood

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 5 Mar 2013 15:58:14 +0100

Hi Tom

> and UDP does not will serve most of our work.

I have to disagree here and recommend to take a look to the RMCAT 
working group. Congestion control isn't completely done and there are 
always new or changed challenges.

   Martin

NEC Laboratories Europe
NEC Europe Limited
Registered Office:

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 5 Mar 2013 16:18:17 +0000

On Mar 5, 2013, at 15:10, t.p. <[email-masked]> wrote:
> The question is can we do with a

Martin already mentioned RMCAT. And I mentioned Wgs wanting to build "lightweight" UDP-based protocols, which are hitting transport issues incl. congestion control all the time.

See these slides (mostly done by Magnus) for some of those issues. We want someone on the IESG who is very familiar with them: http://eggert.org/talks/ietf73-wgchairs-training.pdf

Lars

---

From: Russ Housley <[email-masked]>
Date: Tue, 5 Mar 2013 11:18:20 -0500

Allison:

The split between Transport and RAI was needed.  Together it is too much work for one Area.

The rest of your question ought to be discussed at the TSVAREA meeting in Orlando.

Russ

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 5 Mar 2013 16:42:06 +0000

Hi,

> Was there something causative about extracting RAI from Transport?

a lot of thought went into making sure that the WGs that went on to form RAI formed a cohesive whole. In hindsight, we should have thought more about how cohesive the set of WGs was that ended up remaining in TSV. After the split, TSV consisted of an assortment of odd WGs without much of a shared identity. 

Moreover, all the WGs that had any sort of direct relation to product features were moved into RAI. (With the exception of storage, but they are their own little clique.) That severely limited the pool of AD candidates from industry, because it's difficult to construct a business case to one's management.

That has been changing over the last year or two, with Google, Apple and others beginning some serious work on extending and enhancing transport protocols in an attempt to improve latencies. Unfortunately, the transport folks at such employers are probably to valuable internally to be able to volunteer.

Finally, let's not forget that this year was a special case, because the incumbent was forced to pull out at a very late stage of the process. This left the community very little time to come up with alternatives. I believe that if that had happened earlier, we would have been able to deepen the pool.

Lars

---

From: Dave Crocker <[email-masked]>
Date: Tue, 05 Mar 2013 08:46:10 -0800

On 3/5/2013 8:42 AM, Eggert, Lars wrote:
> Finally, let's not forget that this year was a special case,

I'm going to strongly suggest that that is both wrong and 
counter-productive to claim.

As Mary (and I) noted, TSV has been at a crisis level to fill for some 
years now, but I believe it is merely the most extreme of a broader 
problem.

Other areas often have very, very thin candidate pools.  And none of 
this is new.

d/

---

From: PFRC - jhaas <[email-masked]>
Date: Tue, 5 Mar 2013 11:48:58 -0500

> If we absolutely need someone with that expertise on the IESG, that isn't likely to be resolved by proposals to reorganize the IESG and/or eliminate this position, either. 

I must agree with Margaret here.  As with code refactoring, eventually you've refactored away the simpler bits.  Usually you are left with a core of something that was too hard to refactor.

Even if we agree that the IESG has work that could be redistributed in some fashion, it's arguable this solves the problem at hand.

-- Jeff

---

From: Bob Braden <[email-masked]>
Date: Tue, 05 Mar 2013 09:58:33 -0800

> Martin already mentioned RMCAT. And I mentioned Wgs wanting to build "lightweight" UDP-based protocols, which are hitting transport issues incl. congestion control all the time.

Which is why we learned 30 years ago that building a transport protocol 
at the application layer is generally a Bad Idea. Why do the same bad 
ideas keep being reinvented?

Bob Braden

---

From: t.p. <[email-masked]>
Date: Tue, 5 Mar 2013 18:04:14 +0000

---- Original Message -----
From: "Eggert, Lars" <[email-masked]>
To: "t.p." <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, March 05, 2013 4:18 PM
> congestion control and the relative stability of the topic.

Martin already mentioned RMCAT. And I mentioned Wgs wanting to build
"lightweight" UDP-based protocols, which are hitting transport issues
incl. congestion control all the time.

See these slides (mostly done by Magnus) for some of those issues. We
want someone on the IESG who is very familiar with them:
http://eggert.org/talks/ietf73-wgchairs-training.pdf

<tp>
And the concluding slide of that presentation says
Use a Standard Tranport!
while earlier it says

There are some standard building blocks available
AIMD
TFRC

so I am not persuaded that for Congestion Control, an AD needs  need any
more than a working knowledge, perhaps of 10 years ago, of what TCP
does. (Unlike security, where the 2013 thinking on, say, SHA3 is
necessary)

Tom Petch

Lars

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Mar 2013 10:28:52 -0800

On 3/4/2013 2:19 PM, Dave Crocker wrote:
...
> facilitate community efforts, not to direct them.

ADs also comprise the IESG, which reviews RFCs before publication.

We should not expect to appoint IESG members that need a tutorial on 
basic protocol principles. Further, if the TSV AD can't stand up for 
cong control and other TSV-specific work or TSV-specific concerns raised 
on other drafts, then who will?

Joe

---

From: Dave Crocker <[email-masked]>
Date: Tue, 05 Mar 2013 10:33:21 -0800

Joe,

> on other drafts, then who will?

If you can explain how your note relates to mine, I'd appreciate it.

You appear to be responding to a point that has been raised elsewhere in 
the discussion (by others), but has nothing at all to do with the points 
I was making.

Best I can guess is that you somehow think that because I didn't mention 
something I meant that it didn't matter.  If so, please re-target your 
note because that would be a bad reading.

d/

---

From: Melinda Shore <[email-masked]>
Date: Tue, 05 Mar 2013 09:38:11 -0900

On 3/5/13 9:28 AM, Joe Touch wrote:
> basic protocol principles. 

I haven't seen anybody propose appointing someone who needs a
tutorial on "basic protocol principles."  The discussion so far
has seemed mostly to be whether or not to appoint someone who
has something short of specialist-level knowledge.

Melinda

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Mar 2013 10:38:27 -0800

> If you can explain how your note relates to mine, I'd appreciate it.

I took your point as suggesting that an AD could get by with less 
background because they weren't leaders. In the past, ADs have either 
been people who do lead, or have led in the recent past.

If that's not your intent, I still stand by my post as relating to the 
overall thread, but apologize for any confusion.

Joe

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 5 Mar 2013 22:12:43 +0100

On Mar 5, 2013, at 18:58, Bob Braden <[email-masked]> wrote:

> Which is why we learned 30 years ago that building a transport protocol at the application layer is generally a Bad Idea. Why do the same bad ideas keep being reinvented?

Because we don't have a good selection of transport protocols at the transport layer.

I'm chairing one of the WGs with a UDP-based application protocol.
TCP's congestion control, even if we could use TCP, wouldn't do much for us.

Now here is my point:
I need TSV ADs that are strong on the technical side.
A weak TSV AD might be
-- too cautious, listening to all kinds of Cassandras that haven't bothered to look at the actual protocol, slowing us down unneededly, or
-- too bold, allowing us to deploy a protocol that causes a congestion collapse that can only be alleviated by physically chiseling nodes out of walls.

Clearly, I want neither of these to happen.
(Now, we have received pretty good transport input in 2012, but the IESG will look at this in 2013, and that's where a highly educated decision has to be made.)

Grüße, Carsten

---

From: David Kessens <[email-masked]>
Date: Tue, 5 Mar 2013 14:25:09 -0800

Russ,

> The split between Transport and RAI was needed.  Together it is too much

Not everybody believed at the time, and still believes that increasing the
size of a committee makes the committee function better.

David Kessens
---

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 5 Mar 2013 17:52:33 -0500

While the IETF is unique in many ways, the staff-volunteer issue isn't all that unique. Many organizations face this. As one example, organizations like IEEE and ACM struggle with this. (For example, they have, over the years, delegated many functions in conference management that used to be done by volunteers to paid staff.) Even government regulatory bodies operate with a mixture of volunteer labor (advisory councils) and paid staff. The solution space seems rather constrained:

(1) Fish in the shallow pool of full-time "volunteers" who have a large corporate sponsor. Risk that the corporate sponsor wants something in return.

(2) Pay the person a salary while on leave from their home institution/employer. As an example, NSF and DARPA do this for their program managers. The employer still takes a hit and there's some risk to the person that they won't get their job back, but it allows a larger number of individuals to participate.

(3) Scale back the responsibilities of the individual to make it a 10-20% job. Senior technical or regulatory staff don't read every document line-by-line or, for a conference chair, read every paper, but focus on key issues, by asking questions and relying on more junior staff/volunteers to prepare briefings, for example.

Financially, (1) and (2) aren't all that different financially, except that the money flow is more opaque than an explicit "tax".

I don't think that adding tools helps except at the margins, and only in combination with changing the process. Also, this is not likely to work for just one area. You can't easily have one AD do grammar and spelling corrections on every IANA registration draft, and another just do big-think.

Henning

On Mar 5, 2013, at 11:46 AM, Dave Crocker <[email-masked]> wrote:

> I'm going to strongly suggest that that is both wrong and counter-productive to claim.
> 
> As Mary (and I) noted, TSV has been at a crisis level to fill for some years now, but I believe it is merely the most extreme of a broader problem.
> 
> Other areas often have very, very thin candidate pools.  And none of this is new.
> 
> d/
> -- 
> Dave Crocker

---

From: Jari Arkko <[email-masked]>
Date: Wed, 6 Mar 2013 15:24:55 +0200

A few personal thoughts follows. For the record this is completely at the general level, I have no inside knowledge about the nomination process.

I am of the opinion that ADs should not be selected based on them being rare super experts. The ability to learn, as Sam pointed out, is perhaps most important. Along with some "basic clue" about the area, as Russ put it. But it is important to note that the ADs are not just reviewers or quality checkers. In a lot of cases they are and they should be leading, helping the area move to whatever direction is necessary for the Internet to be a better place. It is the S or Steering in IESG. And I believe this is why the selection is not usually easy. It does take some, perhaps significant familiarity with the area to be able to do that. You'll be helped by everyone on that, but it cannot be entirely outsourced. (And note that this ability is not the same as detailed knowledge of protocol bits or algorithms, which may be needed as well, but you'll need a view about the industry's direction, a grasp of real-life Internet user situation and many other things as well.) So in the end maybe it is more than "basic clue".

Some "generalists" have that or could develop it. Some don't. Earlier in the thread we had an argument from Eliot and others about whether we've had success or not when picking generalists. The problem with bringing up specific cases from the past is that you don't know why those cases succeeded or failed. I can think of situations where a generalist could have worked well, but the particular person didn't have it. But I can also think of situations where a super expert didn't manage the area as well as it should have been managed. FWIW, I think there would be several generalist IETFers who would do a great job as TSV AD even if their specific congestion control knowledge is not rated at the expert level - at the moment.

In any case, I think we've now experienced the same problem for a number of years in transport. I do not think it is a one time problem, we need to make a decision about what to do this in a more long-term fashion than just for this year. This is why it is important that the discussion was brought out in the open, rather than, say, noncom just making a particular decision or the IESG just silently on changing its requirements.

And I think we should have a broader view about this than just updating the requirements for the seat. There are a couple of other aspects to consider as well. First, perhaps the way that we have organised TSV is contributing to the problems. Would a different organisation, say, a different grouping of the working groups to areas help businesses see a bigger value in sponsoring an AD for the area? Should the area be merged with something else, and if we did that, would that change available funding or expertise? Or do we have the right number of ADs to begin with? Second, are there more general things that we could do about the AD role, making it easier to do the job, e.g., as an academic and on the side of your other duties? This might also increase the number of available candidates in other areas.

Jari

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 6 Mar 2013 08:34:32 -0500

Hi Jari,

> And I think we should have a broader view about this than just updating the requirements for the seat. There are a couple of other aspects to consider as well. First, perhaps the way that we have o…

I completely agree with this.

The shortage of candidates is not only a problem in the Transport area, even though it might be more obvious in this area, so I think we should focus on this as a general problem not a specific one.

However, I question the wisdom of choosing to work on this issue _right now_ in the middle of the nomcom selection process, rather than choosing the best candidates we can and working on this problem for next year, or for future years.  It doesn't seem likely that there are any quick fixes here.

If the IESG does decide to reorganize the TSV area(s) and/or reduce the number of seats right now, I think you need to seriously consider the possibility that all of the ADs in the affected/related areas should resign, so that the nomcom can pick the best set of ADS to cover the area(s) given the remaining seats.  So, even that sort of change isn't likely to solve the problem next week.

I'd like to receive some explanation (privately or publicly) about why we are doing this in the middle of the nomcom process that makes any sense to me...

Margaret

---

From: Jari Arkko <[email-masked]>
Date: Wed, 6 Mar 2013 15:50:09 +0200

Margaret,

> I'd like to receive some explanation (privately or publicly) about why we are doing this in the middle of the nomcom process that makes any sense to me…

I didn't want to imply that we necessarily couple the actions we take.

I agree of course that right now we have an issue to solve. I agree that we should do whatever to complete the current process, and that waiting for a reorganisation would be a bad idea. 

However, given that I feel that I've been through varying levels of similar issues for last couple of years, I would also like to ensure that we do something more permanent. Counting backwards from various deadlines, if we are going to make a change for 2014, then the IESG requirements and area descriptions need to be given to noncom by July this year. That is coming up very fast. If we would do something bigger, that needs a lot of discussion in the community. Not saying we necessarily should reorganise, but we need to consider the options.

Hope this clarifies,

Jari

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 6 Mar 2013 09:12:51 -0500

> I agree of course that right now we have an issue to solve. I agree that we should do whatever to complete the current process, and that waiting for a reorganisation would be a bad idea. 

Thanks for the clarification, Jari.  I support doing thing in this order.  

It is very important that we resolve the current Transport AD selection issues as quickly as possible.  I don't have much visibility into what is happening there, despite being a candidate, but I hope some progress can be made on this issue in the TSV area meeting.

It is also important that we make whatever changes we can to improve the overall situation, both within the Transport Area and across the board, and it would be great if we could make some progress in this area in time for the next NomCom cycle.  

Thanks,
Margaret

---

From: Michael StJohns <[email-masked]>
Date: Wed, 06 Mar 2013 11:44:09 -0500

At 08:50 AM 3/6/2013, Jari Arkko wrote:

>However, given that I feel that I've been through varying levels of similar issues for last couple of years, I would also like to ensure that we do something more permanent. 

Once upon a time we contemplated allowing the Nomcom - in rare circumstances - to nominate someone for a short term of 1 year (e.g. probation).  This was part of the discussion some 13-16 years ago when we were expanding the IESG and dealing with some term imbalances and trying to figure out whether giving someone a 3 year term to even out the number of nominees per year was what we should be doing.

Unfortunately, while the 3 year term stuff made it into 3777, the 1 year term stuff didn't.  It's too bad as it may have been a useful option here (or not - I haven't reviewed the list of transport AD candidates).

I would suggest that it's probably time to re-convene the "how do we select people" working group.  Given the number of issues - recall, IAOC, this, ineligible others  - we've encountered lately, I don't think just cutting and pasting a new RFC over 3777 to patch holes makes sense.

Mike

---

From: Joe Touch <[email-masked]>
Date: Wed, 06 Mar 2013 12:14:27 -0800

On 3/5/2013 2:52 PM, Henning Schulzrinne wrote:
> While the IETF is unique in many ways, the staff-volunteer issue
> isn't all that unique. Many organizations face this. As one example,
> organizations like IEEE and ACM struggle with this. (For example,
> they have, over the years, delegated many functions in conference
> management that used to be done by volunteers to paid staff.) Even
> government regulatory bodies operate with a mixture of volunteer
> labor (advisory councils) and paid staff. The solution space seems
> rather constrained:
...
> (2) Pay the person a salary while on leave from their home
> institution/employer. As an example, NSF and DARPA do this for their
> program managers. The employer still takes a hit and there's some risk
> to the person that they won't get their job back, but it allows a larger
> number of individuals to participate.

In the US government version of this (IPA), the person remains 
officially an employee of their home institution; it's a grant/contract 
to the home institution.

So I would break this into two sub-categories:

	a) pay the person while "on leave"

	b) pay the home institution for the person's work as a
	contract/grant
		(this is closer to how the NSF, DARPA, and other
		US govt visiting positions work)

They work out quite differently; the latter means you're paying 
overhead, and can be quite costly but might be more attractive.

Joe

---

From: SM <[email-masked]>
Date: Wed, 06 Mar 2013 14:06:48 -0800

Hi Mike,
At 08:44 06-03-2013, Michael StJohns wrote:
>I would suggest that it's probably time to re-convene the "how do we 
>select people" working group.  Given the number of issues - recall, 
>IAOC, this, ineligible others  - we've encountered lately, I don't 
>think just cutting and pasting a new RFC over 3777 to patch holes makes sense.

There are some issues which may have to be addressed at some 
point.  Patching holes creates an incomprehensible BCP.

There are some interesting details in RFC 3777.  I don't know whether 
they have been exercised.  Anyway, the question is about "how do they 
select people".  It has been mentioned previously that:

   "One former chair pointed out that the NomCom moved pretty quickly
    from a model where a random sample of the community selects
    leadership based on personal experience to a model where the random
    sample of the IETF is expected to survey a large and increasing
    percentage of the total community in order to select leadership."

And:

   "It is possible for either the Nomcom or a confirming body  to wedge
    the process in a way where it cannot proceed."

One item which is not mentioned is that public lynching of candidates 
should never be encouraged.

The Nominating and Recall Committees have the latitude to get the 
work done.  They are supposed to get the work done.  When the 
selection process reaches a point where a working group slot is 
necessary to poke at people who have accepted to work for free, is 
there something wrong.  When an impossible event turns out to be 
possible, is there something wrong?

Regards,
-sm

---

From: joel jaeggli <[email-masked]>
Date: Wed, 06 Mar 2013 14:23:58 -0800

On 3/6/13 2:06 PM, SM wrote:
> There are some issues which may have to be addressed at some point.  
> Patching holes creates an incomprehensible BCP.
>
Or the nomcom unless you want to insure that the pool of volunteers 
shrinks in the the future.
> The Nominating and Recall Committees have the latitude to get the work 
> done.  They are supposed to get the work done. When the selection 
> process reaches a point where a working group slot is necessary to 
> poke at people who have accepted to work for free, is there something 
> wrong.  When an impossible event turns out to be possible, is there 
> something wrong?
>
> Regards,
> -sm

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 6 Mar 2013 20:41:47 -0800

+1 +1 +1

---

From: S Moonesamy <[email-masked]>
Date: Wed, 06 Mar 2013 21:42:36 -0800

Dear IAB and NomCom 2012,

In a message dated February 6, the NomCom Chair requested feedback 
from the IETF Community for the TSV Area Director position.  In a 
message dated March 3, the IETF Chair mentioned that it might be that 
no candidate has yet been found that meets the specific IESG-provided 
requirements.  There wasn't any further communication about the subject.

BCP 10 describes an advice and consent model.  What may have been 
missed, in my opinion, is that the action or non-action is a 
significant change to the model.

This is a highly unusual situation.  I suggest that the appropriate 
party takes any corrective action it deems fit or else there will be 
requests for changes to the model in future.

Please note that I do not have any affiliation in common with anyone 
impacted by the appointment decision or any direct or indirect 
financial interest in the outcome.

Regards,
S. Moonesamy

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 6 Mar 2013 21:58:11 -0800

> IMO congestion control is important and fundamental enough that the IESG itself needs to have the knowledge. YEs, I'm biased.

Searching for "Congestion Control Expert" on google shows no real matches at all before
this discussion thread. I could find "Unicorn expert" though. I wonder if those would make a good TSV AD.

Would you mind to describe how to evaluate someone to meet the bar to be CCE in your opinion ? 
I ask because starting to populate this new term into googles cache doesn't mean its clear
whether the community would even have a common idea of what it would mean. Independent of
whether the community thinks its a good bar for TSV-AD in the first place.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 6 Mar 2013 22:55:52 -0800

Really ? You don't think a good AD should primarily look for factual evidence
(lab, simulation, interop, ..) results produced by others to judge whether
sufficient work was done to proof that the known entry critera are met 
(like no congestion cllapse) - instead of trying to judge those solely
by himself/herself ? 

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 7 Mar 2013 09:47:38 +0100

> (like no congestion cllapse) - instead of trying to judge those solely

How do you judge the evidence without understanding it?
(E,g,. I wouldn't want an AD taking in lab/simulation/interop input as "factual evidence"...
I also wouldn't want an AD to wait for "proof" of anything in this space.)

Grüße, Carsten

PS.: I just spent a day at CeBIT.  One guy there reported to that he has seen 35000 active devices on his WiFi snooper.
I'm not quite sure what that means, but he seemed to be implying "at a specific point in time".
Go congestion control that.  And then "prove" that your solution works.
Somehow, we still seem to be deploying WiFi, nonetheless, and some even consider WiFi a success.
Would your hypothetical AD waiting for "sufficient work was done" have approved WiFi?  In 1998?

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 7 Mar 2013 09:21:41 -0500

Hi Russ,

> The rest of your question ought to be discussed at the TSVAREA meeting in Orlando.

I have looked at the agenda of the TSV Area Open Meeting (on Wednesday from 9:00am to 11:30am), and it includes the following item:

"- Open Mic about "Area Expectations for the TSV ADs" -- 60 minutes
The questions we will ask the community:
  - what is the existing description we gave to NomCom.
  - does the community agree with it?
  - is it reasonable, or are we asking too much?"

By "description we gave to the NomCom" do you mean the IESG's list of desired criteria?  Is the NomCom also going to report on the criteria that they came up with, after considering the IESG's input and whatever input they received from the community?

I am a little bit confused about the purpose of this meeting.  Is it for the IESG to get feedback on their desired criteria, so that those criteria could potentially be updated for future years?  Or is it for the nomcom to get further information from the community in order to determine the actual criteria the nomcom will use (based on input from both the IESG and the community) to fill the open TSV AD position this year?

I would like to know the purpose of the meeting, because I believe it would be appropriate for me to participate in a discussion of the former topic, but not the latter.

Margaret

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 7 Mar 2013 06:57:36 -0800

> How do you judge the evidence without understanding it?

Because it came and was agreed upon by sufficiently many experts in the field.

> I also wouldn't want an AD to wait for "proof" of anything in this space.)

Correct me if i am wrong, but the way i remember mostly from the outside how
GDoI was moved forward in the IETF was to have simulations be done through IRTF
which was provided as evidence to answer to questions raised by the IETF process,
like for example scalability and dynamic behavior.

In general, i think an AD needs to know what questions about a problem had to be raised and
answered positively by experts for proposals to move forward and in the first place
make sure this process (defining and answering questions) happens in the first place.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 7 Mar 2013 07:09:47 -0800

> Go congestion control that.  And then "prove" that your solution works.

Bear proof ?

802.11 CSMA/CA does make sure that every participants gets so little bandwidth 
in this situation that L3 congestion control is not the issue.

(I don't have to proof that i am faster than the bear, just that there is somebody slower)

> Somehow, we still seem to be deploying WiFi, nonetheless, and some even consider WiFi a success.

Its being used and continues to make money, and there is nothing else that works better
because otherwise that would have been successfull.

> Would your hypothetical AD waiting for "sufficient work was done" have approved WiFi?  In 1998?

Do you think with your type of AD requirements we would have better WiFi today ?

Seriously, i think you're overthinking it. There are expert group participants, there are WG-Chairs
and there are ADs. I think this discussion circulates way too much around thinking that we must
shift technical expertise two layers up the management chain. Its a nice concept, it gives a warm
and fuzzy community feeling, we had the luxury enjoying it in many areas in the past, but it
does not scale nor is there IMHO any good proof that it works better than what i described
and what commercial companies exercise. In addition i would contend it tends to burn great
technical experts in the AD role. Yes, i can see how its cool to be burned fast with all the
stuff you get to see and judge in an AD role - for a while.

Cheers
    Toerless

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 7 Mar 2013 16:11:27 +0100

Hi Margaret,

I will answer as the agenda below is out of the TSVAREA session.

On 03/07/2013 03:21 PM, Margaret Wasserman wrote:
> I have looked at the agenda of the TSV Area Open Meeting (on
> Wednesday from 9:00am to 11:30am), and it includes the following
> item:
>
> The questions we will ask the community: - what is the existing
> description we gave to NomCom. - does the community agree with it? -
> is it reasonable, or are we asking too much?"
>
> By "description we gave to the NomCom" do you mean the IESG's list of
> desired criteria?  Is the NomCom also going to report on the criteria
> that they came up with, after considering the IESG's input and
> whatever input they received from the community?

The IESG has sent these requirements [1] to the nomcom, as stated on 
that site. That's what is meant with "what is the existing
description we gave to NomCom".

The idea of the meeting is to gather community feedback about the 
requirements for the TSV AD position. It is not an IESG steered 
discussion, but the intention is give to time and space to let the 
community discuss.

I have to confess that the wording isn't fully fledged on the TSVAREA 
agenda and can be misunderstood. I will work on that.

>
> I am a little bit confused about the purpose of this meeting.  Is it
> for the IESG to get feedback on their desired criteria, so that those
> criteria could potentially be updated for future years?  Or is it for
> the nomcom to get further information from the community in order to
> determine the actual criteria the nomcom will use (based on input
> from both the IESG and the community) to fill the open TSV AD
> position this year?

That is a good question and my personal answer would be definitely for 
future years, as we cannot tell anything about the details of this 
year's outcome, as the work of the nomcom is confidential.

>
> I would like to know the purpose of the meeting, because I believe it
> would be appropriate for me to participate in a discussion of the
> former topic, but not the latter.

I would like to see you there, as well as many other interested 
community members.

Thanks,

   Martin

[1] https://www.ietf.org/group/nomcom/2012/iesg-requirements

NEC Laboratories Europe
NEC Europe Limited
Registered Office:

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 7 Mar 2013 07:21:36 -0800

Btw: RFC3777 3.7.2 seems to define only the criteria to be applied by 
NomCom, not for the confirming body.

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 7 Mar 2013 07:41:20 -0800

> stuff you get to see and judge in an AD role - for a while.

Well said, Toerless.

Greg

---

From: Sam Hartman <[email-masked]>
Date: Thu, 07 Mar 2013 10:41:55 -0500

>>>>> "Martin" == Martin Stiemerling <[email-masked]> writes:

    Martin> Hi Margaret, I will answer as the agenda below is out of the
    Martin> TSVAREA session.

    Martin> On 03/07/2013 03:21 PM, Margaret Wasserman wrote:
    >> "- Open Mic about "Area Expectations for the TSV ADs" -- 60
    >> minutes The questions we will ask the community: - what is the
    >> existing description we gave to NomCom. - does the community
    >> agree with it? - is it reasonable, or are we asking too much?"
    >> 
    >> By "description we gave to the NomCom" do you mean the IESG's
    >> list of desired criteria?  Is the NomCom also going to report on
    >> the criteria that they came up with, after considering the IESG's
    >> input and whatever input they received from the community?

    Martin> The IESG has sent these requirements [1] to the nomcom, as
    Martin> stated on that site. That's what is meant with "what is the
    Martin> existing description we gave to NomCom".

Hi, after reading your message I still don't understand the answer to
Margaret's question.

Also, I'd like to remind you that the IESg does not send requirements to
the nomcom.  According to RFC 3777 the IESG sends a set of desired
expertise.  The nomcom develops a set of required qualifications based
on these and community input.

It's not just a semantic point.  I think over the years the IESG has
started to believe that the IESG rather the community sets the job
requirements for ADs.  I'd like to ask IESG members especially to be
very careful about the terminology and to respect the process.

---

From: David Kessens <[email-masked]>
Date: Thu, 7 Mar 2013 10:24:06 -0800

Sam,

Can we please stop the hairsplitting ?

It is not the IESG's fault if you feel that the nomcom is taking the IESG
input as absolute software style 'requirements' as opposed to often more
lightly interpreted 'job requirements' as desirable from the IESG's
perspective. Please take that message to the nomcom if you wish.

The grander picture here is that there will be a session where the community
can discuss the topic of what to do with the TSV area director position. You
are part of that community and I have no doubt that you will be given a
chance to speak up. This session is clearly not about the finer details of
the nomcom process.

David Kessens
---

David Kessens
---

---

From: Sam Hartman <[email-masked]>
Date: Thu, 07 Mar 2013 13:32:59 -0500

>>>>> "David" == David Kessens <[email-masked]> writes:

    David> Sam,

    David> Can we please stop the hairsplitting ?

    David> It is not the IESG's fault if you feel that the nomcom is
    David> taking the IESG input as absolute software style
    David> 'requirements' as opposed to often more lightly interpreted
    David> 'job requirements' as desirable from the IESG's
    David> perspective. Please take that message to the nomcom if you
    David> wish.

I don't think there is hair splitting going on here; I think the issues
that are being raised are quite real and important.  It's not the IESG's
fault if the nomcom does x.  It is the IESG's fault if the IESG takes on
tasks delegated to the nomcom in RFC 3777.  As you are aware, I have
taken concerns I believe are best handled by the IAB and nomcom to the
IAB and nomcom.

---

From: David Kessens <[email-masked]>
Date: Thu, 7 Mar 2013 10:40:32 -0800

Sam,

> taken concerns I believe are best handled by the IAB and nomcom to the

The nomcom makes the appointments. There is nothing the IESG can take away
from that. It is the nomcom that interprets the "requirements" from the
IESG. There is nothing the IESG can do about that. If you are unhappy how
the nomcom does the interpretation, contact the nomcom. 

David Kessens
---

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 7 Mar 2013 10:50:01 -0800

:gs/nomcom/nomcom process/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 07 Mar 2013 12:01:49 -0800

On 3/7/2013 10:32 AM, Sam Hartman wrote:
> that are being raised are quite real and important.

I agree it's not hairsplitting and that it is vitally important.

Unfortunately, Sam, your model is simply wrong.

The IESG defines the job requirements.  The Nomcom selects according to 
those criteria.

I'm been in a number of Nomcom's that wished for some flexibility 
concerning job requirements, but each of these Nomcoms was very clear 
that it did not have a mandate to make changes in job criteria.

That is, the Nomcoms each viewed themselves as executing IESG policy, 
rather than formulating policy.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 07 Mar 2013 15:14:12 -0500

>>>>> "Dave" == Dave Crocker <[email-masked]> writes:

    Dave> I agree it's not hairsplitting and that it is vitally
    Dave> important.

    Dave> Unfortunately, Sam, your model is simply wrong.

    Dave> The IESG defines the job requirements.  The Nomcom selects
    Dave> according to those criteria.

    Dave> I'm been in a number of Nomcom's that wished for some
    Dave> flexibility concerning job requirements, but each of these
    Dave> Nomcoms was very clear that it did not have a mandate to make
    Dave> changes in job criteria.

When you say my model is wrong, I think you're talking about the model
in practice.  I wrote a note last night explaining why I believe my
model is right according to RFC 3777.
If you think I got that wrong please ignore the rest of this message and
explain what I missed.

If you are saying that the nomcom feels pressure to take the desired
expertise provided by the IESG and treat it as  the required
qualification in RFC 3777, then I absolutely agree you're right, and
personally I consider that a significant problem.

Because I believe that's wrong, I've been working here to try and set
the expectation that we should be following the RFC 3777 model.  I've
also been talking to the nomcom and IESg members about the issue.

It's a really serious problem.  The nomcom I served on believe the IESg
got the desired expertise wrong in a number of ways.  We wanted to ask
the community about the set of qualifications we planned on using.  Our
nomcom was strong-willed enough that we were going to use our
qualifications if they were supported by community input.  However we
got pushback from the IESG on circulating our text, so we just went
ahead and used a set of qualifications that no one (until the IAB) got
to see.
Ah joy!

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 7 Mar 2013 15:49:01 -0500 (EST)

On Thu, 7 Mar 2013, Dave Crocker wrote:

> The IESG defines the job requirements.  The Nomcom selects according to those 
> criteria.
>
> I'm been in a number of Nomcom's that wished for some flexibility concerning 
> job requirements, but each of these Nomcoms was very clear that it did not 
> have a mandate to make changes in job criteria.
>
> That is, the Nomcoms each viewed themselves as executing IESG policy, rather 
> than formulating policy.

I have not been on a NomCom with Dave Crocker.  When I was on Nomcom 
(without Dave), I recall explicitly questioning some of the IESG's 
stated job requirements.

In general, I think it is entirely appropriate for NomComs to 
second-guess the IESG's job requirements, and some nomcoms (or at 
least some nomcom members) have done so.

-- Sam

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 8 Mar 2013 10:16:06 +0100

Sam,

> Hi, after reading your message I still don't understand the answer to

Can you point out what is unclear?

> on these and community input.

It is the 'desired expertise', you are right.  Thanks for the reminder.

> very careful about the terminology and to respect the process.

To be honestly, it is more than appropriate to use the right 
terminology, but I personally (this is **not** the opinion of the IESG) 
do see it disproportionate to judge about the whole IESG, or subparts of 
it, to say that the IESG is believing to be tasked to set the requirements.

The wording wasn't correct and it is good that you have pointed this out.

It is clearly that the community is the driver, no doubt about it. And 
by the way that is also the reason for explicitly giving time to the 
community in the Transport Area Open meeting.

Regards,

   Martin

NEC Laboratories Europe
NEC Europe Limited
Registered Office:

---

From: Sam Hartman <[email-masked]>
Date: Fri, 08 Mar 2013 07:44:48 -0500

>Can you point out what is unclear?

margaret asked Russ whether we were talking about the future of the area
or n whether we were talking about requirements/expertise nomcom should
use for this year.  After reading your message I still don't understand
which it is.

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 8 Mar 2013 09:43:01 -0500

On Mar 7, 2013, at 3:01 PM, Dave Crocker <[email-masked]> wrote:
> The IESG defines the job requirements.  The Nomcom selects according to those criteria.
> 
> I'm been in a number of Nomcom's that wished for some flexibility concerning job requirements, but each of these Nomcoms was very clear that it did not have a mandate to make changes in job criteria.

Dave, this isn't what  RFC 3777 says…

RFC 3777 says that the IESG submits the IESG's desired criteria, that the nomcom gets input from the community on what the criteria should be, and that the nomcom decides (based on both inputs) what criteria the nomcom will use to select candidates.

This is why I do support the nomcom asking the community for further input if it is unclear what the requirements should be.

IMO, nomcoms don't do a very good job of asking the community about what the criteria should be.  The entire input-gathering process is focused on the individual candidates, and the community can't really offer feedback on candidates they don't know.  

Based on your message and other things that have been said about this year's process, I think the community has lost track of the nomcom's job in setting the criteria.  For years, I have been choosing to give the nomcom free-form feedback on the criteria via e-mail or during interviews, and now I understand why I've been getting blank stares or silence in return.

Margaret

---

From: Martin Stiemerling <[email-masked]>
Date: Sat, 9 Mar 2013 13:54:53 +0100

> use for this year.  After reading your message I still don't understand

Here is the clarification:

The 'Open Mic about "Area Expectations for the TSV ADs"' part in the 
TSVAREA session has been put in place by the Transport ADs with the 
intention to let the community discuss the requirements of the Transport 
AD positions.

The discussion of the requirements is for the future, not about the 
current NOMCOM process.

We did notice that there issues with finding Transport ADs just from the 
publicly available information, i.e., two calls for candidates after the 
first, regular call.

Neither of us (IESG nor community) does know about the internals of the 
NOMCOM. And there is no intention to interfere with the NOMCOM process.

  Martin