Subject: [newtrk] Re: Work effort? (Re: Proposed Standard and Perfection)

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 15 Mar 2004 07:23:12 -0600

This really is NEWTRK material, but I think part of the question is
"how long is it SUPPOSED to take to get to Proposed?"

I happen to like the idea that you could write an I-D during one IETF
meeting cycle, talk to people about it at the meeting, rev it a couple
of times on a mailing list during the next meeting cycle, and forward
it for publication after discussion at the next meeting. That's a
six-month to eight-month interval, more or less.

People have told me I'm hopelessly optimistic. Note that my timeline
omits "update charter to include this work item", for instance.

Please followup to NEWTRK. It's been too quiet there anyway, and
that's the chartered WG for this topic...

Spencer

From: "Conroy, Lawrence (SMTP)" <[email-masked]>

>   When I pass my driving test, the Examiner doesn't consider me to
be a
> good driver; merely that
> I'm unlikely to kill someone so readily.
>
> I had thought that this was the analogy for Proposed, but this
hasn't
> been my experience; protocol quality
> is often considered before we get that far.
>
> Given the amount of time we take to raise things to Proposed, *if
> people are serious about the protocol*
> then there may well be implementations out there already - a number
of
> protocols have had interoperation
> tests whilst still I-Ds, simply due to the glacial nature of the
> process (i.e. people are overloaded)
> and the requirement for quality (or "perfection", depending on who's
> saying it).

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Keith Moore <[email-masked]>
Date: Mon, 15 Mar 2004 11:17:45 -0500

> six-month to eight-month interval, more or less.

An individual _can_ do this - provided that the author can be very
responsive to feedback during that time and provided that the proposal
is neither complex nor controversial.  

OTOH it's very unlikely that you can do this if you have to form a
new working group.  It takes about as much time to get a WG charter
approved as it takes to get a simple document approved.   This scrutiny
is necessary, because every new working group is a potential Pandora's
box.

IF there is an existing working group and IF the new I-D fits well
into that WG's charter, and IF the WG is not already overloaded,
you might be able to get a document done in six to eight months.
However that's a pretty narrow set of conditions.  WGs with 
broad charters tend to take on too many documents and make snail's 
progress on all of them.  And WGs that have many spare cycles probably
aren't doing much useful work anyway - which means that (a) they're
not likely to be productive on a new document and (b) they probably 
need a mercy killing.

Keith
.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 15 Mar 2004 19:33:38 +0200 (EET)

Hi,

Stripped off the IETF list.. However, I've added the solutions list, 
as IMHO there is not that much newtrk can do about it.  Follow-ups 
might consider removing newtrk.

You raise a good questions.  This is my personal favourite topic, as
doing a lot of stuff and committing a lot of time to different kinds
of IETF activities, I see a lot of "stalling" in the process (whether
intended or not), when -- for all I could see -- the work could go on
much faster with very little effort.

And from my perception, the part where you request publication of an
I-D from the IESG is actually the one which is typically the most
straightforward and fastest one in the process -- and this is the part
that gets IMHO too much heat (and attention in the IETF improvement
process as well) in the process.. when folks should be looking at the
mirror.

I present no solutions, only hint at some of them, so maybe the right 
forum should have been problem-statement list, but let's let that 
sleeping dog lie for now..

Warning: a long message.
 
> omits "update charter to include this work item", for instance.

Yep.  This is my pet peeve.  It appears that most time in the process 
is typically spent on:
 - waiting for the editor to revise the document
 - waiting for someone to review the document
   ("send a pointer to the list and wait if someone brings up 
     anything")
 - waiting on resolution on where the work belongs
 - waiting for the document to be accepted as WG item
   ("wait until the next meeting", "there were objections.. let's 
     discuss it again, if we have time, in the next-to-next meeting")
 - waiting for the document to be WG last called (when it's in 
   reasonably good shape)
 - being able to resolve issues fast enough
   ("WG concensus process") -- especially when "difficult" issues have 
   been raised and/or sufficiently many WG participants aren't 
   voicing their opinion on a specific issue (that is, should one make 
   fundamental changes to the document (editor disagreeing) when 
   suggested by one person, but not supported or spoken against by 
   anyone?
 - being able to resolve big/architectural issues, which have crept up 
   during the process, e.g., at IESG review, which should have been 
   addressed much earlier.

However, when the editor (and hopefully the WG chair) is active, I
still believe this is not too high optimism.  It just requires a lot
of effort.  Where it may not work that well, though, are the very
widely-scoped problems which just seem to take time to resolve
properly.  

But sufficiently narrow-scoped proposals, at least, have a very good
chance of going through (with the editor/chair caveats above).  
Actually, in many cases, I think that if you want to fast-track the
process, you may want to do an Individual Submission to an AD even if
there was a WG which might be the right place to do the job.  It's
just so much faster, esp. if no WG clearly "owns" the problem space.  
See more of this below.

Ok -- a few words of some of the most important issues, raised above, 
below.

Revising the document:

In many cases, the editors may be busy with other stuff for weeks, 
months, or an IETF meeting cycle.  They may require significant 
pushing to make them revise the document in a timely fashion.  One 
problem here may be that difficult issues have been raised and the 
editor doesn't know how to resolve it.  Depending on the roles of 
editors/chairs, it's uncertain on whose turf this belongs to.  Issue 
tracking probably helps in that it teases apart the role which is 
often what WG chair is responsible for.  Root causes seem to be many, 
at least:
 - uncertainty of WG chair / editor roles in the process
 - lack of time/energy from the editor / WG chair for edits/issue 
closing
 - lack of input from the WG when trying to get closure in a diffucult 
issue

Reviewing the document:

When you send a pointer about a new draft on a list, in many cases you
don't get any replies in days, weeks, months or even an IETF cycle.  
The idea may be good, but nobody has time/energy to read it or send
feedback.  Often, going 1-on-1 on some potential reviewers makes them
feel guilty for not responding, and you may be able to get feedback.  
But this relies on those people giving the feedback, and knowing who
to approach in getting the review.  This is also a particular problem
in the WG process: when someone raises an issue [e.g., in an ops or
internet area] "I think this should have more discussion on SCTP", but
nobody knows about it, and the document pointer is sent to the SCTP WG
ml and/or chairs and ADs for feedback, typically nothing happens even
though prodded multiple times. (SCTP was just an example. :)  So,
intra-area and inter-area review solicitation doesn't work that well.  
Root causes seem to be at least:
 - people don't have sufficient time/energy to look at the proposals
 - many proposals are so bad that you don't feel you have energy to
kill it, so you'll leave it to someone else, who never does or never
appears (and the document lingers on for months or years) -- really a
subissue of the above
 - nobody seems to be responsible for ensuring that something gets 
done in the area which is the recipient of inter-area review 
solicitation
 - people may not know when the request for review is "serious" and 
really important and when not ("is this the right time to review it -- 
have bad ideas been killed off already?")
 - people don't know enough intra-area (or even intra-WG) people who
they could approach 1-on-1 to ask for feedback (hoping better
results), and inter-area is even more difficult.

Where the document belongs:

If there is a very clear indication which WG should be working on the
document, life is easy.  In many cases, this is not the case.  The
problem may be related to one or more WG(s), which might even reside
in different areas.  Trying to figure out which WG the works belongs
to usually takes a LOT of time, including negotiations with WG chairs
and ADs, and the non-responsiveness of all the concerned parties.  One 
reason for that may be that so many ideas come to them that they don't 
know how to kill what they consider bad ideas.  So they shove them 
from WG to another, or fail to reply to a question where the work 
should be done.  In this case, it may be often easiest to go 
Invididual Submission to the AD (if the AD believes the work is 
important).  A BOF process might also be kickstarted, but that would 
usually take quite a while.  Root problems seem to be:
 - inability to kill (or know how to do it) bad ideas early
 - WG chair/AD energy/time commitment issues
 - inability of the author to find which WG would be most appropriate 
for the work (s)he's proposing
 - "informal BOF" (e.g., mailing list setup etc.) isn't used often 
enough (or maybe it doesn't work well enough).  This might be good 
means to try to gather folks interested in a subject when the subject 
doesn't clearly fall inside a WG.

WG adoption:

The current procedures seem to require presenting the idea at the
meeting for adoption as WG work item (if you want to have it as WG
work item, that is).  The process does not require this, but in
practice, this may take quite long -- especially if the chairs don't
want to take the work on on their own (e.g., ask whether there are
objections to taking on the work in the mailing list, or ask whether
there is support for the proposal in the mailing list; note the
difference between the two).  The core problem may be the inability to
have good means for determining WG consensus (for new work) outside of
the meeting (and even at the meeting).

"What's going to happen next" state:

Another fast-track killer appears to be the document waiting in a
"what's going to happen next" -state.  This is very common.  All the
issues have been addressed [or another nuance: waiting for issue
writeup from someone else, which is not delivered], but nothing
happens.  Maybe the document should be last-called ASAP to get "speak
now, or be forever quiet"  -approach from the start. Core problem
seems to be either that:
 - the process "driver" is sleeping, i.e., WG chair doesn't push the 
document through when there are no objections or,
 - if there hasn't yet been much review (yet the document seems good 
from the WG chair), how do you get more -- or should you just move 
forward when it looks good enough and there are no objections (i.e., 
no knowledge how to handle WG inactivity)? (see the review issue 
above)

Resolving Big Issues:

When smaller issues are raised, the editor, if willing to spend the
cycles, is able to resolve them pretty well; issue tracker helps if
used properly.  However, bigger issues may cause other kinds of
show-stoppers: this is typically either: 1) stopping the effort
altogether or 2) changing its direction significantly.  Each of these
usually require a lot of convincing.  These often cause a WG process
stalemate: the chair (or the editor, if he doesn't have support from
the chair) doesn't know how to measure the inactivity on the list on
which way to proceed: for example, only 2-3 persons might be voicing
their opinions, and they might be opposite ones.  An active
chair/editor might be able to keep up the discussion and/or steer it
in the right direction so that people might be able to go to a
compromise.  But the inability to do so (and sometimes a compromise is
not possible) often leads to delays.  The core issues seem to be at
least:
 - difficulty in measuring WG consensus, esp. on the list
 - low participation from the WG in responding to or resolving the 
issues [maybe some kind of web-based unanonymous voting-like system 
might be useful, but it might have problems as well]
 - current lack of being able to kill bad ideas earlier when there 
might not yet be too much momentum to change the document.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

.

---

From: John Leslie <[email-masked]>
Date: Mon, 15 Mar 2004 19:25:45 -0500

> might consider removing newtrk.

   Whether or not newtrk can "do much about it", I believe newtrk
should discuss this.

> It appears that most time in the process > is typically spent on:

   When acting as an editor, I find that the biggest time sink is
hoping for inspiration on how to restate something where consensus
is especially "rough". This can be overwhelming if you're asked to
"fix" language on a half-dozen areas of "ultra-rough" consensus in
preparation for a last-call.

   Perhaps such situations could be avoided?

>  - waiting for someone to review the document

   When acting as a reviewer, I find I can almost instantly point
to particular sentences which need work, but explaining _what_
work they need requires a search for my "round tuit".

   Is it possible to make do with something closer to pass/fail?

>  - waiting on resolution on where the work belongs

   This shouldn't be happening. We should be enabling near-parallel
work or actually-in-parallel work with communication between groups.

>  - waiting for the document to be accepted as WG item

   This seems pointless. Work should not have to wait for some
group to run out of other things to do.

>  - waiting for the document to be WG last called (when it's in 

   This is the delay we _should_ have. There should be a cooling-off
period after a document is ready for last-call.

   OTOH, there might be a need for formal review which wasn't done
earlier. Can we ensure that formal review starts before a WG is
ready to last-call something?

>  - being able to resolve issues fast enough

   Which do you want: "resolve issues" or "fast enough"?

   My advice is to go for "resolve issues". Whenever you settle
for "fast enough", consensus starts breaking down.

>    -- especially when "difficult" issues have been raised and/or
>       sufficiently many WG participants aren't voicing their
>       opinion on a specific issue

   It's not _actually_ a problem when few participants speak up,
but it certainly leads to _perception_ of a problem. This is
where a WG chair needs to decide whether consensus is attainable
or whether the issue needs to be "routed around", possibly by
allowing both sides what they want for now and postponing a
decision.

   It's quite natural for people to keep fairly silent when a
disagreement surfaces, hoping that the parties to the disagreement
will work out their differences. Responsibility should, IMHO,
rest on the WG Chair, the parties to the disagreement, and the
document editor.

>       (that is, should one make fundamental changes to the
>       document (editor disagreeing) when suggested by one person,
>       but not supported or spoken against by anyone?

   Generally not -- but you've listed "editor disagreeing" -- it's
a different story with "editor neutral".

   In the "editor neutral" case, the editor SHOULD make it clear
how much work is involved (and beg, if necessary, for guidance
from WG members).

>  - being able to resolve big/architectural issues, which have
>    crept up during the process, e.g., at IESG review, which
>    should have been addressed much earlier.

   Isn't that what formal reviews are intended to fix?

> Ok -- a few words of some of the most important issues, raised
> above, below...
> 
> Reviewing the document:
> ...

   Then these are not the ones who should be held responsible.

>  - many proposals are so bad that you don't feel you have energy
>    to kill it, so you'll leave it to someone else...

   It is certainly standard in many organizations to kill bad ideas
by delaying tactics.

   That is not, IMHO, a good idea here: people with good ideas will
misinterpret each delay as an intent to kill the idea.

   I hesitate to mention it, but assigning a "research" task is
another time-honored method of treating bad ideas...

   We would be well advised to design a process for "killing" (or
at least delaying) "bad" ideas -- this shouldn't be the IESG's job.

>  - nobody seems to be responsible for ensuring that something
>    gets done in the area which is the recipient of inter-area
>    review solicitation

   This needs more definition: do you mean coordination with some
other WG?

>  - people may not know when the request for review is "serious"
>    and really important and when not...

   This will take time to adapt to. The quick answer is that if
the WG chair OR AD says so, it's important.

>    ("is this the right time to review it -- have bad ideas been
>    killed off already?")

   IMHO, there's no obligation to kill of bad ideas before sending
something to a reviewer. (YMMV)

> ...
> Root problems seem to be:

   I suggest that NEWTRK consider this seriously.

>  - inability of the author to find which WG would be most
>    appropriate for the work (s)he's proposing

   Why isn't the default to form a new WG?

   (I don't mean to rule out WG subgroups: I just believe that
constantly heaping new work onto existing WGs is begging for
trouble.)

>  - "informal BOF" (e.g., mailing list setup etc.) isn't used
>    often enough (or maybe it doesn't work well enough). 

   Is there documentation on how it's "supposed" to work?

> Resolving Big Issues:
> ...
> The core issues seem to be at least:

   Well, of course, that's where consensus MUST be measured...

   IMHO, we worry about consensus too _often_. Some people are not
going to speak up until WG last-call. The fact that nobody raised
the issue earlier simply means that nobody raised it earlier: not
that anyone's trying to spoil the stew.

   WG last-call _works_ to judge consensus. Why are we worrying so
much about judging consensus before that?

--
John Leslie <[email-masked]>
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Keith Moore <[email-masked]>
Date: Mon, 15 Mar 2004 20:18:19 -0500

> work or actually-in-parallel work with communication between groups.

Sometimes that's a lot more difficult than it sounds, particularly when 
groups have different vocabularies and/or conflicting agendas.

That, and accepting input from "outsiders" apparently slows the group 
down (only to have the group's work held up later).

> group to run out of other things to do.

It seems even more pointless to expect a small set of people to work on 
everything at once.

When I was on IESG it never ceased to amaze me how many people thought 
that IETF *owed* it to them to do whatever it took to standardize 
_their_ idea - and whether it was a good idea or bad, simple or 
complex, whether it's effects were localized or whether it would affect 
every host or protocol on the Internet, whether it required a new 
working group to be chartered, or whether it fit into some existing 
group's already overcrowded agenda - all of these things were 
irrelevant.

> ready to last-call something?

We need formal review long before a WG ever starts to write anything 
resembling a protocol specification.

> but it certainly leads to _perception_ of a problem.

Well, it might or might not be a problem.  If the task at hand is 
simple and the proposed solution is straightforward and appears to have 
few complications, it's probably not a problem.  OTOH if the task is 
complex and bewildering, and/or the solution has lots of loose ends, 
the lack of response is probably an indication that the proposal is not 
well understood.  Or if the group has labored for years while still 
failing to resolve basic problems the lack of response may be a sign of 
exhaustion.

> another time-honored method of treating bad ideas...

Trying to kill the idea gives its proponents more incentive - it puts 
their backs to the wall, so to speak.

All too often we try to kill dubious ideas but eventually cave into 
pressure to form a WG to pursue those same ideas.  Then that WG goes 
off and works for a couple of years without really solving the problems 
and insists that IESG must approve its work.  And all too often, after 
many months of deliberation (trying to make a silk purse out of a sow's 
ear) IESG does approve the work, after insisting on only minor changes 
to what is really a fundamentally flawed specification, based on a 
fundamentally flawed idea.

> at least delaying) "bad" ideas -- this shouldn't be the IESG's job.

I'm not sure what kind of process you have in mind, but basically - the 
buck has to stop somewhere, and in anything resembling our current 
structure that looks a lot like IESG.

>    This needs more definition: do you mean coordination with some

There might or might not be a current WG to coordinate with.  That 
doesn't mean that coordination isn't necessary.

>    Why isn't the default to form a new WG?

In many areas we have too many WGs already.   There is a limited number 
of people in IESG; more generally, there is a limited number of clueful 
people in IETF.  The more WGs we have, the lower the clue density.

> much about judging consensus before that?

Because if you work two years until Last Call only to find out that 
you've got fundamental problems, nobody wants to scrap the whole thing 
and start over.

.

---

From: David Meyer <[email-masked]>
Date: Tue, 16 Mar 2004 07:57:55 -0800

>> preparation for a last-call.

	Or can't even find the "ultra-rough" consensus position
	(because an equal number of camps have provided
	contradictory text; c.f. MSDP). In any event, I agree
	that this is one of the biggest time sinks.
>> work they need requires a search for my "round tuit".

	I agree with Pekka here, and this goes (a little) to the
	icar stuff. In fact, I get frequently get reviews *after*
	a document is published (i.e., after IETF last call,
	after RFC editor processing, ...). In any event, this one
	seems to belongs at least partially in icar.

>>    Is it possible to make do with something closer to pass/fail?

	Generally I find the reviews of three general classes:

	(i).	Editorial nits

	(ii).	Technical substance

	(iii).	No problem (i.e., "pass"). Note that the "fail"
		part of this would violate one of the things that
		has always made the IETF process work so well
		(and that we on many occasions seem to have
		forgotten), namely, that in order to stop a
		document from proceeding you needed either
		(a). firm technical reasons why it shouldn't,
		and/or (b). a better proposal).
		
>> group to run out of other things to do.

	This has also not been a huge problem in my experience.

>> ready to last-call something?
   
	icar?

>> allowing both sides what they want for now and postponing a

	I'm not sure what issue Pekka was trying to surface here,
	but there is a problem with new (or even some long time)
	participants coming into the IETF and not wanting to
	speak in public (or even on mailing lists). 

>> how much work is involved (and beg, if necessary, for guidance

	I would say that it really depends. It is always possible
	for someone to come up with a point that no one else has
	seen, so that needs to be accounted for.

>> >  - people don't have sufficient time/energy to look at the

	No argument.

>> at least delaying) "bad" ideas -- this shouldn't be the IESG's job.

	I would venture to guess that in what is supposed to be
	an organization with open and transparent processes, any
	such parliamentary maneuvering (e.g. stalling tactic)
	would degrade the confidence the rank and file have in
	the process, and more generally, waste time. BTW, I've
	only seen this (stalling to kill a document) happen once,
	and we're still trying to deal with the aftermath. 

	Summary: Sanctioning actions as opaque as stalling to
	kill a document will go along way towards killing the
	IETF as an open and process transparent SDO. I haven't
	talked to anyone wants that.

>>    This needs more definition: do you mean coordination with some

	Pekka makes an excellent point here. Over in MBONED,
	we've realized the problem and started a cross-IETF
	coordination effort to handle just this case (among
	others). The problem(s) you run into include:

	(i).	Why isn't this a directorate?

		Well, because a directorate serves at the request
		of an AD, and in this case we haven't been asked
		by an AD; we just see the problem and want to
		solve it.

	(ii).	OPS WGs don't do protocols

		Protocol WGs worry about an OPS WG doing protocol
		(or in some cases, even providing requirements,
		as strange as that may sound) 

	(iii).	Some kind of power consolidation

		I don't really understand this one, but folks
		seem to worry about cross-IETF actvities as
		consolidating some kind of power (I'm not even
		sure what power).

>>    I suggest that NEWTRK consider this seriously.

	Agree.

>> constantly heaping new work onto existing WGs is begging for

	Really depends on the scope and breadth of the WG
	charter. A little truth in advertising (IMO): Even though
	one might argue that the charters themselves are really
	informal documents, and beyond the dates in the
	milestones (that much is at least measurable), what is 
	unclear (undocumented) is exactly what bound by the
	charter. 

>> much about judging consensus before that?

	You make a good point (and as I mention above, is common
	experience). It seems, however, that WGLC is kind of late
	in the process to try and judge consensus. By this point
	we generally think the document is close to ready (or at
	least that has been my experience; I should add as a
	caveat that on several occasions I have mentioned that no
	one is reading this or that document, and an AD has said
	"Just WGLC it; people will speak up then"). 

	Maybe its just a fact of life in a volunteer operation
	like the IETF, people won't speak up until they have to?
	
	So, question back to everyone: What is the real function
	of the WGLC (in your opinion, of course), and  is using
	WGLC as a mechanism to judge consensus consistent with
	that functionality? 

	Dave
.

---

From: Eric Rosen <[email-masked]>
Date: Tue, 16 Mar 2004 11:04:03 -0500

Keith> In many areas we have too many WGs already.  There is a limited number 
Keith> of people in IESG; more generally, there is a limited number of clueful 
Keith> people in IETF.  The more WGs we have, the lower the clue density. 

This argument presupposes that the number of clueful people remains constant
as the number of WGs varies.  That's just not true.  Many people participate
in the IETF  when there is work being  done in an area of  interest to them,
and  stop participating  when there  is no  work being  done in  an  area of
interest to them.   So adding WGs does not  necessarily decrease the average
clue density, and subtracting WGs does not necessarily increase it.

So I don't see anything wrong with adding WGs as needed, as long as there is
some reason to  believe that the new WG will have  enough clues.  Of course,
there is  a difference between  "the WG is  clueless" and "the  IESG doesn't
agree  with  its  ideas/direction/solution".   Failure  to  attend  to  this
difference is the source of much conflict. 

.

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Mar 2004 12:27:53 -0500

> 
> Keith> In many areas we have too many WGs already.  There is a limited
> number Keith> of people in IESG; more generally, there is a limited
> number of clueful Keith> people in IETF.  The more WGs we have, the
> lower the clue density. 
> 
> This argument presupposes that the number of clueful people remains
> constant as the number of WGs varies.  That's just not true. 

Okay, I'll be more specific.  The clue space is not one-dimensional. 
There are detail clues and architectural clues.  The detail clue density
might remain relatively constant, but it probably decreases slightly
overall  as the population increases just because you get more varation
in clue level - work that used to attract only the brightest now
attracts people with a wider range of skill levels.  Also, the more
variation in clue level the more frustrated the clueful become,
as they get tired of explaining things to people who can't understand
them.  so they tend to opt out. 

OTOH, architectural clue density does decrease significantly as the
overall population increases, because (in proportion to the set of
people with detail clues) there are far fewer people who have a "big
picture" understanding of how things fit together.  

You really need a balance of detail clue and architectural clue.

> So I don't see anything wrong with adding WGs as needed

Then again, you've never tried to co-manage 28 working groups in a
single area.

> Of course, there is  a difference between  "the WG is 
> clueless" and "the  IESG doesn't agree  with  its 
> ideas/direction/solution".  

Actually the people who make the latter statement are quite often
lacking in clue.  So what looks like a conflict may actually be
multiple indications of the same thing.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Eric Rosen <[email-masked]>
Date: Tue, 16 Mar 2004 13:02:04 -0500

Eric> Of course, there is  a difference between  "the WG is 
Eric> clueless" and "the  IESG doesn't agree  with  its 
Eric> ideas/direction/solution".  

Keith> Actually the people who make the latter statement are quite often
Keith> lacking in clue.  

Aha, now I get  it, the reason I disagree with you so  often is that I'm one
of the clueless ones!  Well, what other possible reasons could there be? ;-)

I think  you have a  somewhat romantic viewpoint,  in which the  IETF should
consist of the 100 brightest people in the world, and should not take on any
work  that  they cannot  do  among themselves.   I  think  that position  is
somewhat eccentric, but no doubt  that's a reflection of my own cluelessness
;-)

One might think,  on the other hand, that as the  Internet grows, the number
of people who understand it grows also.  

.

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Mar 2004 13:24:59 -0500

> of the clueless ones!  Well, what other possible reasons could there be? ;-)

If you are clueful, you can probably think of other reasons.  If not, well...
:)

> work  that  they cannot  do  among themselves.  

No, clearly that does not scale.  Let me try to reword what you are saying and
see if it fits better:

The early Internet protocols, and IETF in its early days, had the benefit of
input from some exceptionally clueful people, who had the luxury and the
motiviation to try to get a lot of details (both high- and low-level) right.

Circumstances have changed.  These days, specification development is more
likely to be funded by companies who have to meet short-term expectations 
in order to deliver product and keep their stock prices up.  Rarely these days 
do many IETF participants see the need or feel that they have the luxury
of sorting out architectural issues or resolving conflicts beyond those needed 
to reach an immediate short-term goal.  And yet the Internet has suffered
tremendously in recent years due to lack of architectural guidance in protocol 
development.

IETF has inherited an organizational structure and ways of working that were
successful when used by people with both architectural and detail clue.  It
doesn't work so well for people with fewer clues, or only detail clues.

--
Power corrupts.  PowerPoint corrupts absolutely.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html