Subject: RE: area directors at risk

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Mon, 19 Nov 2001 17:26:44 -0600

> 
> It might be worthwhile to admit additional hierarchy in
> the administrative structure to scale the organization 
> and reduce the work-load on area directors. 

The smaller the hierarchy, the faster a decision is reached.
Adding more hierarchy to the structure of the IETF may make
it more ineffective.

> 
> One possibility is to introduce the concept of assistant 
> (or deputy) Area Directors, reporting directly to Area 
> Directors and responsible for a subset of working groups 
> within an area. 
> 

Increasing the number of ADs for a certain area depending on the
number of WGs and activity within that area may be of greater
benefit. 

> This may also turn out to be an excellent way to cultivate
> future leaders for the IETF.
> 
> Cheers,
> /Dan
> 

-Basavaraj

---

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

Raj,

> number of WGs and activity within that area may be of greater

I agree with this assessment.

The only issue I could see here is that the more people involved in
decision making, the more difficult it is to come to agreement, but I
don't think that adding one more or possibly even two more area
directors would make all that much difference.

Another possibility would be to split areas where there is too much
workload for current ADs and start new ones.

I agree that adding another layer of hierarchy, or even sub-areas, is
rather more likely to add delay into the process.

            jak

---

From: Fred Baker <[email-masked]>
Date: Tue, 20 Nov 2001 11:10:58 -0800

>directors would make all that much difference.

adding one or two probably doesn't; adding one or two per area (which is 
the end case of the proposal) could add quite a bit.

personally, what I would like to see is some combination of:

1) additional tools to support area director's work; we have had some in
    development, and that seems to have fallen by the wayside. One place where
    things bog down is in ensuring that comments made are addressed and get
    resolved in a timely fashion.
2) additional ADs where necessary;
3) more active directorates supporting the ADs; I'd like to see a lot of the
    draft commentary come from the directorates rather than from the AD. That's
    not reality today.
4) better management of the working groups by the working group chairs, as
    someone suggested.

a combination of (1) and (4) would come back to charters; I'd like to see 
the WG's charter updated at least annually, with appropriate 
problem-statement and milestone twiddling, and then the WGs hew pretty 
close to their charters.

---

From: Stuart Staniford <[email-masked]>
Date: Tue, 20 Nov 2001 12:12:37 -0800

> problem-statement and milestone twiddling, and then the WGs hew pretty

Mmmm.  Wouldn't this just be more work for already overwhelmed ADs?  My
understanding right now is the AD and IESG have to approve a charter
revision.

Stuart.
  
-- 
Stuart Staniford     ---     President     ---     Silicon Defense
         ** Silicon Defense: Technical Support for Snort **
mailto:[email-masked]  http://www.silicondefense.com/
(707) 445-4355 x 16                           (707) 445-4222 (FAX)

---

From: Fred Baker <[email-masked]>
Date: Tue, 20 Nov 2001 13:22:30 -0800

>understanding right now is the AD and IESG have to approve a charter

It would make different work, but in the end it would likely be less work. 
I'll observe that the areas that we get these complaints from least are the 
ones that seem most religious in ensuring that charters are up to date and 
that milestones are observed at least in passing. This is management 101; 
an activity general achieves what it plans to achieve, and the working 
group charter is the thing that even resembles a plan for a working groups 
activity.

Let me take what I consider to be a particularly egregious example. My 
objective here is to make a general point, not a specific one about an AD, 
the area, or the working group. But ask yourself why Authenticated Firewall 
Traversal is meeting (if in fact it is; it's not on the current draft 
agenda) based on its charter: 
http://www.ietf.org/html.charters/aft-charter.html. What is the working 
group chair planning to do in the next six months? If he asks for a slot to 
meet in, what justification is there to say "yes"? Is this a solved 
problem, or does it remain to be solved? Taking it sentence by sentence:

>         The goal of the Authenticated Firewall Traversal Working Group is to
>         specify a protocol to address the issue of application-layer support
>         for firewall traversal. The working group intends to specify a 
> traversal
>         protocol supporting both TCP and UDP applications with a general 
> framework
>         for authentication of the firewall traversal.

OK, it did that: the current version is SOCKS V

>         To promote interoperability, the group will also propose a base
>         authentication technique for use within the general authentication
>         framework.

What authentication technique is that? Is that a clear-text password? 
RADIUS? SSL? DIAMETER? IPSEC? It focuses on authentication; where does 
authorization fit in (e.g., now that I know who you are, how do I know what 
privileges you have, and specifically whether you're allowed to do what 
you're asking me to help you do?)? Is that still something the working 
group plans to deliver? What proposals are in place?

>         The output of the group will consist of a standards-track RFC(s)
>         describing the traversal protocol, the base authentication 
> methods and a
>         reference implementation of the protocol, and base authentication 
> methods.

The protocol is SOCKS, and there is a reference implementation. Talk to me 
about authentication? (and by the way, discuss English composition...)

>The working group will start with the SOCKS system described by David 
>Koblas in his paper presented at the 1992 Usenix Security Symposium.

It probably did. That was almost ten years ago.

I don't know whether the working group is done with its work, and it is for 
someone other than me to comment on whether it should expire. I claim that 
this is an example of an out of date charter, and so from it I can't tell 
what the plan is - and neither can the AD or the working group chair.

Starting from an existing approved charter and saying "this work item no 
longer makes sense, that needs to be added, and here's how it jiggles the 
milestones" is a lot simpler than having to remember why it is that a 
working group whose most recent milestones are long since completed is 
still on the map.

---

From: Stuart Staniford <[email-masked]>
Date: Tue, 20 Nov 2001 14:27:15 -0800

My working group charter (IDWG) is also badly out of date.  Some time back,
we sent a revision in.  We never heard back.  We assumed the IESG is too
busy to get to charter revisions, and we haven't tried again since.

Making the process of charter revision and milestone tracking more
efficient will probably have the effect of prodding the WGs to deliver
their documents faster.  That will make more work for the ADs and the
IESG.  If the ADs are having a hard time handling their workload now, it
will only get worse.  I think to solve this problem, you have to talk about
how to increase the bandwidth of the IESG and the area directors.  That
requires changing the structure.

Requesting that the quality of documents improve is likely to have limited
effect.  The quality of documents is largely set by the quality and
availability of the  individuals drawn to IETF work.  That cannot be
changed by exhorting them to be different.  In general, the IETF is a
system.  If one wants the system to work differently, one has to change its
structure (the relationship of the pieces and the incentives of those
pieces).  My belief is that asking a system to work in an unchanged way,
but harder or better, rarely causes much sustainable difference.

Stuart.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 20 Nov 2001 15:54:12 -0800

Stuart,

> but harder or better, rarely causes much sustainable difference.

The quality of the document is dependent both on the quality of the
ideas
expressed in them and the quality of the writing that goes into the
documents.
The individuals involved in a particular working group may be world
class
experts but if their writing skills are limited (as is unfortunately
often the case
with talented engineers) the resulting specifications will be unreadable
and
largely unusable for people who were not involved in the original design
team.

Getting people with good writing skills involved in IETF may help, but
typically technical writers don't tend to hang out at IETF and companies
don't want to send their technical writers because technical
documentation
is usually the gating item in whether a product gets delivered on time
or not,
since it must be completed after the product is finished. So tech
writers are
always on the critical path. Other SDOs I've worked with aren't so
constrained,
and companies often agree to send good technical writers to make sure
the
specification is readable.

                jak

---

From: "Kastenholz, Frank" <[email-masked]>
Date: Wed, 21 Nov 2001 07:57:12 -0500

>largely unusable for people who were not involved in the original design

Pardon me for being blunt, but this is pure rubbish.
The typical attendee of the IETF these days is someone
whose job is writing documents. It is not unreasonable
to expect them to have some basic level of skills in
their chosen field of work.  We expect programmers to
know C/C++/... and to be able to write working code.
Why should we not expect spec-writers to have the
same qualifications?

Frank Kastenholz
Chief Executive Grump

---

From: "James Seng/Personal" <[email-masked]>
Date: Wed, 21 Nov 2001 21:35:41 +0800

Not everyone who has the neccessary technical skill has the language
skill to express him/her idea properly. This is one area which the wg
chairs should be able to help.

-James Seng

---

From: Randy Bush <[email-masked]>
Date: Wed, 21 Nov 2001 07:39:21 -0800

> whose job is writing documents. 

this is not the itu yet, frank.  and the contributors
here are not necessarily fluent with english as their
language of primary expertise.  for some it is greek
and others geek.

randy

---

From: Derek Atkins <[email-masked]>
Date: 21 Nov 2001 11:45:04 -0500

> language of primary expertise.  for some it is greek

I still consider "C" to be my primany language; English is my second ;)

> randy

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: "James Kempf" <[email-masked]>
Date: Wed, 21 Nov 2001 08:59:31 -0800

Frank,

> Pardon me for being blunt, but this is pure rubbish.

Sorry, but I find this style somewhat unprofessional.

> Why should we not expect spec-writers to have the

I do not know what your experience is, but I have been involved
over the last year in rewriting three drafts by people who were
excellent engineers but whose writing skills were not up to
the task of generating an understandable engineering specification.
In two cases, the drafts were written more like narrative prose,
without any concept of information mapping, so that someone
who was not involved in doing the draft would be completely
unable to implement from it. In the third case, I was asked
by the Area Director to rewrite the draft after it was rejected
during IESG review because it was very vague and lacking in
information directed at the problem that it was attempting to
describe. Involvement by someone whose profession was
mapping technical information into a form that is understandable
by programmers at an earlier phase would have saved me, the
Working Groups, and the IESG alot of time, which is, after
all, what this thread was originally about.

Transferring technical information is a skill that is completely
separate from programming in my experience. There are people in
Silicon Valley who are highly paid to do this, and only this, and
good technical documentation can make the difference between
a product that is easy for engineers to build on and one that is
difficult or impossible. Now, this is not to say that programmers
can't excel at it as well, and I also know engineers that are very good
at technical writing, several of which are in the IETF.

If there is some resistence or reluctance to getting technical writers
involved, then perhaps the solution is to make a stronger effort to
identify engineers that are also good writers and are willing to be
 involved in doing the specs.

                jak

---

From: Stuart Staniford <[email-masked]>
Date: Wed, 21 Nov 2001 11:44:09 -0800

> Why should we not expect spec-writers to have the

We are, of course, free to expect anything we want.  It's just that our
expectations won't make any actual difference just because we have them. 
If they aren't in line with reality, then all they do is give us permission
to complain when other people don't meet those expectations.  Blaming the
document authors might make us feel better, but does nothing to solve the
problem.  We can complain till we are blue in the face, and it will make
very little sustained difference to the average quality of the documents. 
That is set by the typical abilities and available time of the typical
person who volunteers to write documents in the typical working group (with
some influence from the rest of the WG, especially the chairs).

Our expectations only become part of the solution if we do something to
change the systems of of the IETF in a way that is likely to modify the
ability and/or availability of document authors and other players.  For
example, we could create a certification for IETF authors which required
them to demonstrate ability to write a document in the way we would like,
and have a rule that only certified folks could be document authors. 
That's a structural change in the IETF.  It has advantages (it might raise
the quality of documents) and disadvantages (it might reduce the number of
available authors and increase the overhead and bureaucracy of the
organization).

Alternatively, we could pay professional technical writers to improve the
quality of the documents before the IESG has to try to digest them.  That's
another structural change.  It has advantages (better documents, maybe more
timely documents), and disadvantages (now the IETF needs a larger revenue
stream to pay for these services).

I'm not really advocating these particular solutions.  I'm making the
larger point that simply complaining and demanding that parts of the system
work better is generally not useful.  Only changing the way the system
works makes a difference.  

(I know that the IETF is mainly made up of technical folks, but it might be
of interest to realize that management thinkers have done a lot of work
trying to develop ways to reason about these kinds of organizational
issues.  A good book is "The Fifth Discipline" by Peter Senge).

Stuart.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 21 Nov 2001 16:35:00 -0500

It has occasionally been suggested and seriously considered that the IESG 
(IETF) hire a tech-writer).  The obstacle I always saw was 
logistics.  Getting the right information to the tech writer so that they 
could do a good job re-writing the I-D is a non-trivial task.  If anyone 
can come up with a way to actually make this work, I would strongly support 
re-examination.
Yours,
Joel M. Halpern

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 21 Nov 2001 18:00:13 -0500

> can come up with a way to actually make this work, I would strongly support

The SIP WG is currently experimenting with this. One of the companies
that contributes a lot of technical contributors also offered the
services of one of their tech writers. The techies maintain change
control (i.e., the tech writer asks before making more major changes),
but the outside perspective has been very helpful so far, ranging from
diction to just ferreting out undefined terms or inconsistently used
terms.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Stuart Staniford <[email-masked]>
Date: Wed, 21 Nov 2001 23:07:56 -0800

Here is my favored solution:

1) Place an absolute limit on the number of IETF working groups that is
significantly smaller than the number now.  There are presently about 134
working groups (plus or minus a few).  I propose a cap of 75 working groups, to
be achieved in stages during a two year phase-in.  Once the cap was in place,
new working groups could only be created when old ones finished.  If there were
more successful BOFs than slots at a particular IETF, the IESG would have to
decide which potential WGs were most worthy of a slot.

2) Working groups would have an initial maximum life of two years.  The working
group would *automatically* expire after that time unless it was finished with
its work earlier.  The WG could only be extended for one year at a time by
explicit IESG action (ie the WG would die unless the IESG could reach consensus
to extend it, something that would generally be rare).

This solution would:

	* Reduce the load on the IESG without requiring an 
	  additional layer of hierarchy (which is otherwise 
	  *inevitable* sooner or later as the number of WGs 
	  continues to grow). 

	* Would force the IETF to prioritize more carefully what 
	  standards really need to be created.

	* Would reduce the problem of WGs drifting interminably.

Stuart.

---

From: Lars-Johan Liman <[email-masked]>
Date: Thu, 22 Nov 2001 12:47:03 +0100 (MET)

> 1) Place an absolute limit on the number of IETF working groups ...

> 2) Working groups would have an initial maximum life of two years. ...

> 	* Reduce the load on the IESG without requiring an ...

> 	* Would reduce the problem of WGs drifting interminably.

The Internet grows at a rate no one has perceived. More and more
people find more and more uses for the net.

It seems to me that your suggestion would limit the amount of work
that the IETF can perform, not allow for more, which is not in
parallel with my statement above. The work needs to be done, and will
be done anyhow - outside the IETF, if the IETF can't cope, thus
creating non-standard and even proprietary ways of doing things. I
think that's worse than doing it inside the IETF.

Your suggestion would (probaly) reduce the work load of the IESG. It
would definitely reduce the problem of drifting WGs, but at the cost
of killing off ones that do good work that just happens to take
time. If you want shorter lives for the WGs, you have to have more of
them, not fewer, else we'll end up with too little work getting
done. ;-)

(And yes, I agree that AD work load should be reduced, and that
drifting WGs is a problem. I'm the chair of one. :-)

				Cheers,
				  /Liman
#----------------------------------------------------------------------
# Lars-Johan Liman		! E-mail: [email-masked]
# Senior Systems Specialist     ! HTTP  : //www.autonomica.se/
# Autonomica AB, Stockholm 	! Voice : +46 8 - 615 85 72
#----------------------------------------------------------------------

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 22 Nov 2001 12:46:07 +0000

as with any form of congestion, there are several approaches to removing the
bad effects

1/
increase capacity at the bottleneck - more ADs, ADs with more time

2/
rate limit/feedback control source - less i-ds/rfcss/wgs
	one option is here content "thinning" - we
	are seeign far too many submissions of work without
	a real sponsor, implementation or clue

3/
spread load over multiple paths - multi-talented multi-area ADs
	could take workload off (similar to 1 queue for multiple servers)
	when their own area is idle

what doesn't help is more hops (e.g. hierarchy)  - it scales other
thing (management) but not throughput or latency.

doing nothing is not gonna be an option since we are starting to see
signs of congestive collapse (there's more time talking about the
problem than solving it)

In message <[email-masked]>, Lars-Johan Liman typ

 >>drifting WGs is a problem. I'm the chair of one. :-)

 cheers

   jon

---

From: Randy Bush <[email-masked]>
Date: Thu, 22 Nov 2001 05:29:32 -0800

it would be interesting to do a histogram of the mean number of bytes per
rfc, say clumped every 100 rfc numbers or every quarter or year.

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 22 Nov 2001 05:35:49 -0800

> signs of congestive collapse (there's more time talking about the

not by ads.  so what is congesting here is not the channel in question.

<grin>

randy

---

From: Aaron Falk <[email-masked]>
Date: Thu, 22 Nov 2001 11:24:58 -0500

On Wed, Nov 21, 2001 at 11:07:56PM -0800, Stuart Staniford wrote:
> 1) Place an absolute limit on the number of IETF working groups 
>
> 2) Working groups would have an initial maximum life of two years.  
>

Stuart-

I'm afraid you are throwing the baby out with the bathwater.  One of
the reasons the Internet and the IETF have succeded so far is
flexibility.  (1) will serve to drive people away from the IETF making
the organization less relevant.  (2) will result in lots of unfinished
work.

--aaron

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 22 Nov 2001 10:43:55 -0800

In addition, we must always be receptive to new ideas. Otherwise important 
Internet protocols will be created elsewhere and not receive IETF review. 
That doesn't mean we create a new WG for every crazy idea out there. It 
just means that we can't shut people out because we are too busy.

---

From: Stuart Staniford <[email-masked]>
Date: Thu, 22 Nov 2001 01:44:44 -0800

Aaron Falk wrote:

> I wrote:

> the organization less relevant.  (2) will result in lots of unfinished

Well, I'm a security guy.  I view the Internet as a massive security nightmare
already, and the more protocols there are, the worse it gets.  I'd rather the
IETF produce fewer, better, simpler protocols.  However, I'm willing to grant
that my perspective shouldn't be dispositive on that.  

But, if we want to support ever more WGs producing ever more protocols, then we
must abandon the present document review structure.  It has reached the limit of
its scalabality (everyone seems to agree on that much), and certainly cannot
accomodate future growth.  Better technology is only going to make a minor
difference - it will not solve the fundamental problem that the system is now
operating beyond the scale where it works well.  The time required to review a
technical document is mainly thinking time, which technology can do nothing to
reduce.

If you guys don't want a cap on WGs, then you need to think of a different
organizational structure that can handle a lot more WGs and lead to high-quality
review of all the documents they produce.  It is useless to blame the document
authors, useless to blame the WG chairs, and useless to blame the ADs.  This is
not a symptom of bad people anywhere in the system, but instead is a problem
with the configuration of the organizational system itself, and can only be
fixed at that level.

Stuart.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 22 Nov 2001 22:54:20 -0800 (PST)

> just means that we can't shut people out because we are too busy.

In practice, our ability to be receptive to new ideas will be improved if
the hold time within the system were to be reduced. Just like a University
is less able to admit new students if the average graduation time grows
continually longer, the IETF becomes less able to innovate as the
document time to completion lengthens. 

In general, I've found that the longer a document is being worked on, the
*less* likely it is to get the kind of detailed review that is
needed. Short intense efforts can often generate significant enthusiasm
because, while painful, people have a sense that the pain will be
short lived and that the chance of accomplishing something is high. 

On the other hand, long drawn out document development saps editor and
contributor interest. Often people change jobs or companies and the longer
a document takes to be completed, the more likely it is that priorities 
will change. 

Long drawn out documents also are less likely to be read by WG
participants with each and every revision. Once a document has been under
development for a few years, it can easily become a Zombie, sleep walking
through the IETF process, only to be discovered dead on arrival at the
IESG. 

This phenomena also applies to WGs that have been in place a long
time. Eventually, the level of interest and enthusiasm subsides until only
a hard "core" of interested parties remains. Without a continual injection
of new blood, stagnation and inbreeding is often the result, and after
enough time has elapsed, even the most focussed WGs tend to demonstrate
signs of senility. 

A quick glance through the list of IETF WGs demonstrates that 30-50% of
them could potentially be closed within a year. Giving these WGs an
ultimatum would be likely either to reinvigorate them, or to result in the
cancellation of efforts that just aren't high enough priority at the
moment to make much forward progress. 

In my experience, such quiesscent WGs, even if they don't meet actively, 
consume considerable resources. Because older WGs have a heightened
vulnerability to senility, these WGs must be closely monitored. 
mailing list activity needs to be tracked, etc.  Just like in the health
care system patients often consume most of the care in the last phases of
life, terminal WGs are often very costly in  terms of IETF resources
consumed, even though their productivity is often relatively low.

---

From: Matt Holdrege <[email-masked]>
Date: Fri, 23 Nov 2001 16:17:08 -0800

>a document takes to be completed, the more likely it is that priorities

And there you have the method for killing an I-D that you don't like. Just 
find a way to filibuster or delay and you will eventually kill the effort. 
That's one abuse I would really like to see closed off somehow. I've heard 
this has been a problem in the IESG in the past, but it is a serious 
problem in some WG's too.

---

From: avri <[email-masked]>
Date: Sat, 24 Nov 2001 12:21:52 -0500

In reading this discussion, a two things struck
me as necessary:

- AD's using well formed directorates to help them get
their work done is a necessary condition to having an
effective area.

- Cross editing between areas is necessary to achieve
a quality RFC product.

Another thing seems obvious, the ADs cannot possibly review
all of the documents themselves in good time and adequate
detail.  I also don't believe that it is realistic to believe
that wholesale reduction in IETF focus or RFC output is about
to happen in my lifetime.

I have two alternative suggestions:

- The ADs could remain responsible for doing adequate and timely
review of all drafts, but could delegate the task to their
directorates.

- The IESG could create a draft review 'directorate' that would
be composed of literate technical specialists who were willing
to report to the IESG on draft quality in a timely and adequate
manner.

Neither of these suggestions would mean that ADs could not also
read an i-d, but it would take some of the burden off them
without creating another level of hierarchy.  In order to speed up
the work, folks from the directorates (either suggestion) could
be assigned/volunteered to follow the progress of drafts as they
made their way through the WG process.  It would be the responsibility
of WG chairs to notify their ADs of documents that were entering
the 'solidification' stage so this early intervention could occur.

a.

---

From: Marc Blanchet <[email-masked]>
Date: Sat, 24 Nov 2001 19:25:08 -0500

What about some (additional) IESG people being 
identified/responsible/reference for helping the process:
- charter writing/revision
- intellectual property
- help wg for wg business
- some AD administrativa
...

just an idea.

Marc.

--On mardi, novembre 20, 2001 14:27:15 -0800 Stuart Staniford 
<[email-masked]> wrote:

> My working group charter (IDWG) is also badly out of date.  Some time
> back, we sent a revision in.  We never heard back.  We assumed the IESG
> is too busy to get to charter revisions, and we haven't tried again since.
>
> will only get worse.  I think to solve this problem, you have to talk
> about how to increase the bandwidth of the IESG and the area directors.
> That requires changing the structure.
>
> system.  If one wants the system to work differently, one has to change
> its structure (the relationship of the pieces and the incentives of those
>> > > a combination of (1) and (4) would come back to charters; I'd like
>> > > to see the WG's charter updated at least annually, with appropriate
>> > > problem-statement and milestone twiddling, and then the WGs hew
>> > > pretty close to their charters.
>> >
>> It would make different work, but in the end it would likely be less
>> work. I'll observe that the areas that we get these complaints from
>> least are the ones that seem most religious in ensuring that charters
>> are up to date and that milestones are observed at least in passing.
>> This is management 101; an activity general achieves what it plans to
>> achieve, and the working group charter is the thing that even resembles
>> a plan for a working groups activity.
>>
>> objective here is to make a general point, not a specific one about an
>> AD, the area, or the working group. But ask yourself why Authenticated
>> Firewall Traversal is meeting (if in fact it is; it's not on the current
>> draft agenda) based on its charter:
>> group chair planning to do in the next six months? If he asks for a slot
>> to meet in, what justification is there to say "yes"? Is this a solved
>> >         The goal of the Authenticated Firewall Traversal Working Group
>> >         is to specify a protocol to address the issue of
>> >         application-layer support for firewall traversal. The working
>> >         group intends to specify a traversal
>> >         protocol supporting both TCP and UDP applications with a
>> >         general framework
>> >         authentication technique for use within the general
>> >         authentication framework.
>>
>> authorization fit in (e.g., now that I know who you are, how do I know
>> what privileges you have, and specifically whether you're allowed to do
>> what you're asking me to help you do?)? Is that still something the
>> working group plans to deliver? What proposals are in place?
>>
>> >         The output of the group will consist of a standards-track
>> >         RFC(s) describing the traversal protocol, the base
>> >         authentication
>> > methods and a
>> >         reference implementation of the protocol, and base
>> >         authentication methods.
>>
>> The protocol is SOCKS, and there is a reference implementation. Talk to
>> me about authentication? (and by the way, discuss English composition...)
>>
>> I don't know whether the working group is done with its work, and it is
>> for someone other than me to comment on whether it should expire. I
>> claim that this is an example of an out of date charter, and so from it
>> I can't tell what the plan is - and neither can the AD or the working
>> group chair.
>>

---

From: Marc Blanchet <[email-masked]>
Date: Sat, 24 Nov 2001 19:25:08 -0500

just an idea.

Marc.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 26 Nov 2001 10:25:23 +0100

--On 23. november 2001 16:17 -0800 Matt Holdrege 
<[email-masked]> wrote:

> And there you have the method for killing an I-D that you don't like.
> Just find a way to filibuster or delay and you will eventually kill the
> effort. That's one abuse I would really like to see closed off somehow.
> I've heard this has been a problem in the IESG in the past, but it is a
> serious problem in some WG's too.

It requires a certain brutality on the part of the WG Chair.
I've more often counselled WG chairs to declare rough consensus than I've
counselled them to delay the process for a single gratuitous objector.

in general, I think our chairs are strongly focused on being fair to all 
and finding consensus - perhaps sometimes a little bit of brutality might 
be better.
But this is VERY much a judgment call.

("that is why we pay you the big bucks" :-)

---

From: Andy Bierman <[email-masked]>
Date: Tue, 27 Nov 2001 23:58:26 -0800

>the organization less relevant.  (2) will result in lots of unfinished

I agree.

The way to increase the probability that quality work will be 
produced in a timely fashion is to staff the project for 
success from the start. 

Identify all cross-domain issues up front and line up 
committed volunteers from the requisite domains up front, 
or else don't grant the charter.  Don't bring in the cross-domain 
experts at the end of the process (IETF Last Call) and ask them to
clean up a mess that the original WG doesn't even want cleaned up. 

Figure out how WGs can have their own milestones within the same project.
Joint meetings of 2 or more WGs should be encouraged, and would be
needed for shared projects. There's even a chance that cooperation
and shared ownership will reduce redundant standards over time.

>--aaron

Andy