Subject: area directors at risk

From: Aaron Falk <[email-masked]>
Date: Mon, 19 Nov 2001 16:43:14 -0500

Harald, John, et al-

At the last IETF plenary I asked the IESG to comment on the work load
for area directors and got what I thought was a less than satisfactory
response.  I understand that it's hard being put on the spot so I'm
bringing the issue up again on this list to enable some more
thoughtful dialog (I hope :).

As a working group chair, I know that the attention and guidance of a
good area director can do a lot to make a working group more
productive as well as training good working group chairs.  Area
directors bring a larger perspective from other IETF activities into
working groups and advise the chairs on procedure.  I've been
privileged to work with, IMHO, three excellent Transport Area
Directors and have learned from all of them.

Currently the area director position is a demanding half- to
two-thirds-time unpaid commitment.  Indeed, there are more Internet
drafts and working groups than ever and it appears that the time
required to do the job is only increasing.  I'm concerned that area
directors seem to be much busier than they used to be and have less
time for monitoring working group mailing lists and shepherding working
group documents through the IETF review process.

I wanted to raise the issue again now that the nomcom process has been
kicked off.  Specifically, I'm concerned that the time commitment will
eliminate otherwise competent AD candidates.  I'd like very much to
hear that IESG and the secretariat are looking at ways to organize the
way work is done in the IETF so that we can attract and retain
talented ADs, they are critical to maintaining the high quality of the
IETF protocols.  Let's not wait until the current ADs are burned out
and we are unable attract qualified replacements to examine this
issue.

--aaron

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 19 Nov 2001 17:35:33 -0800

First, I think the IETF process/WG guidelines are fine and I
think the ADs are doing a very hard job quite well.

I have few suggestions, suggestions which I am sure the
ADs have heard repeatedly and trying to implementing.

1) Delegate,
2) Be more aggressive in rechartering/concluding
   floundering groups,
3) Be more aggressive in replacing chairs who repeatedly
   let their groups wonder beyond their charter, and
4) Be more demanding for narrow charters.

But I do note that we (WG chairs) also need to do our job
to decrease the amount of time it takes to review our
documents.  In particular, we need to more to improve the
quality of I-Ds we progress to our ADs.  Good documents
are easier (and faster) to review and poor documents are
harder (and slower) to review.

Kurt

---

From: Randy Bush <[email-masked]>
Date: Mon, 19 Nov 2001 18:11:40 -0800

[ note drop of iesg and iab cc:s ]

> 4) Be more demanding for narrow charters.

you left at least one out.  i do not necessarily advocete it, but it is
worth a thought.  so this is a floater, not a proposal.

we have had a philosophy of nurturing parallel/competing efforts.  should
we exercise more architectural constraint?  if so, how would we develop
consensus over the architectural decisions?  the nearest we get to this
consensus-building today is informal chat, directorate discussions, hard-
assed area directors, and so forth.

randy

---

From: Aaron Falk <[email-masked]>
Date: Mon, 19 Nov 2001 21:33:00 -0500

Hmmm, in case anybody is counting, when I wrote:

> I've been privileged to work with, IMHO, three excellent Transport
> Area Directors and have learned from all of them.

I was referring to the three assigned Transport Area Directors for
TCPSAT and PILC, i.e., Allyn, Vern, and Allison, with whome I've
worked quite closely on creating and managing two rather unusual
working groups.  I hope that no one got the impression that I was
implying that any AD I've worked with has been less than excellent.
In fact, I have a rather boring habit of quoting past and present ADs
during working group discussions.

--aaron

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 19 Nov 2001 18:52:26 -0800

At 06:11 PM 2001-11-19, Randy Bush wrote:
>... this is a floater, not a proposal.
>

Given two reasonable (sets of) I-Ds on the same topic, I believe
the IETF should generally nurture parallel/competing efforts.  Often
its better to let each camp produce the best damn proposal they can
and then let a WG reach consensus by the removing function and
features causing contention.  And sometimes, it best to publish
competing works on the same topic.

Of course, there are some cases where the operation of the Internet
demands a single solution and, hence, we must exercise appropriate
architectural constraint.

Kurt

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Nov 2001 14:04:34 +0100

Kurt's suggestions all look right to me. On "delegate",
remember that the IESG today takes collegial responsibility
for RFC decisions - even for Informationals, not just
standards track. The only way to increase delegation, I
think, is to change that: allow Areas to take the final
decision (creating Directorates or AADs to do so). This
would
 a) reduce IESG workload by eliminating collegial document reveiw
 b) reduce mutual sanity checks between areas 

    Brian

---

From: John C Klensin <[email-masked]>
Date: Tue, 20 Nov 2001 08:39:53 -0500

Kurt,

(i) In principle at least, we are in complete agreement about
how to handle parallel efforts and competing proposals.

(ii) However, this strategy requires a good deal of careful
consideration and judgement -- about WGs, about documents, about
when consensus has been achieved -- and all of that takes up
IESG time.

Your suggestion was?  :-(

     john

p.s. IESG has "busy" periods and "impossibly busy" periods.  The
latter tend to occur just before and just after IETF meetings.
While I understand the nomcom timing part of this, it is not the
best time to start discussions of this type if one is trying to
create less load on them.

   john

--On Monday, 19 November, 2001 18:52 -0800 "Kurt D. Zeilenga"
<[email-masked]> wrote:

> Given two reasonable (sets of) I-Ds on the same topic, I
> believe the IETF should generally nurture parallel/competing
> efforts.  Often its better to let each camp produce the best
> damn proposal they can and then let a WG reach consensus by
> the removing function and features causing contention.  And
> sometimes, it best to publish competing works on the same
> topic.
> 
> Of course, there are some cases where the operation of the
> Internet demands a single solution and, hence, we must
> exercise appropriate architectural constraint.
> 
> Kurt
> 
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Nov 2001 15:05:36 +0100

> competing works on the same topic.

When two approaches surface in the same WG, sure, as long as the WG
chairs can guide towards a consensus which is not a messy compromise.

The hard part is deciding which WGs to create when there are orthogonal
approaches around and no chance at all of a consensus. For very major
issues (e.g. IPng in 1993) we can put a special directorate in place,
but for less global issues, Randy asks a good question. 

> architectural constraint.

And "we" is who?

   Brian

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 20 Nov 2001 07:24:24 -0800

>> architectural constraint.

Individuals, WG members, WG chairs, ADs, IESG, and IAB.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 20 Nov 2001 08:23:16 -0800

>when consensus has been achieved -- and all of that takes up

We (WG chairs) need to do our part in reducing AD workload.
By proposing better charters, better documents, being better
consensus builders, and to avoid pushing issues upon the ADs
unnecessarily.

My point is simple,
  The ADs are at risk because we place them at risk!

Kurt

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 20 Nov 2001 08:27:43 -0800 (PST)

The problem with parallel/competing efforts is that it generates
twice (or more) amount of work for a given topic.  While this
works great in a capitalistic marketplace, it is of doubtful
value in a standards organization.  The value of a *standard*
is diluted if there isn't a single standard.  Moreover, you
get religious wars, confusion among the customers, ...  Finally,
the IETF "customer" is generally silent until the "standards"
are implemented, at which point the decision is usually made on
non-technical grounds.

Case in point: IS-IS vs. OSPF.  Twice the work, twice the number
of WGs, twice as many IDs to write/review/progress.  At least
here there is a fairly even split among users.

Case in point: RSVP-TE vs. CR-LDP.  Again, twice as much work.
Here there is unanimity in the marketplace.  However, we (the
IETF) continue to pursue both.

Perhaps some great good comes of doing multiple standards, but
not at zero cost.

Kireeti.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 20 Nov 2001 08:27:56 -0800

Kurt,

> competing works on the same topic.

I agree. However, I've seen cases recently where the WG has failed to
reach concensus on removing function and
features causing contention, resulting in two protocols having roughly
similar functionality in the same draft.
In such cases, it may require alot of work from people who care to prove
that one or the other is better, and,
in some cases, the amount of work required may take a long time. Perhaps
this is as it should be, but it does tend to
increase the amount of time required to come to a decision, and this can
be a hardship, particularly when there are many groups waiting on the
RFC in order to implement and deploy it.

> architectural constraint.

I guess I have trouble seeing how architecture would dictate a specific
protocol solution. In my experience, the architecture sets out the broad
guidelines for how the system should be designed, while the protocols
embody the actual design. The details of what the design should
accomplish are contained within the requirements for the protocol, which
is part of the architecture. Two protocols can satisfy the requirements
and be consistent with the architecture and still be in competition. But
that is my particular view on architecture, I'm sure others would
disagree.

            jak

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Nov 2001 15:27:37 +0100

> Kurt,
...
> protocol solution. 

Parsing alert: Kurt said "single" not "specific". For example, we all 
know what a mess it was before SMTP dominated: the architecture demands
a single mail transfer protocol. It doesn't demand the specifics
of SMTP.

   Brian