Subject: [newtrk] IETF Process discussions - next steps

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Aug 2006 11:42:21 +0200

Here are my conclusions from the plenary discussion
and the General Area open meeting at IETF 66.

1. Conclusions from plenary discussion on Newtrk issues
(draft-carpenter-newtrk-questions-00.txt)

A clear theme in the plenary discussion in Montreal was "declare victory."
Unfortunately, in reading the notes and listening to the audio
recording, and reading subsequent emails, it is also clear that
different speakers meant different things by this phrase - anywhere
from clarifying today's standards track, through reducing it to two
or one stages, to simply sitting down and shutting up. Although
on the order of 40 people out of several hundred in the plenary
appeared to believe that formal changes to the standards process
should be made, and some people are ready to do work (thanks!)
there was no firm consensus for a given direction (as there never has
been in the Newtrk WG).

One useful observation was that there is nothing in present
rules and procedures to prevent the writing and publication
of overview standards documents ("ISDs" in Newtrk parlance),
as long as they fit into RFC 2026 rules as Applicability
Statements.

A need was observed for lightweight documentation of the real
world deployment status of individual standards, as concrete
feedback from running code. Again, no rule prevents this today,
but neither do we have guidelines as to the format, status
and indexing of such documents.

My conclusions are that:

1.1. There is insufficient pressure and energy in the community
to justify the effort of reaching consensus on formal changes
to the standards process at this time.

1.2. For complex standards where a normative or informative
overview document would be beneficial, nothing in today's
rules and procedures prevents interested parties from
writing and submitting such documents within the rules set
by RFC 2026, and such efforts should be welcomed.

1.3. The community should be encouraged to produce documentation
of deployment and interoperability of individual IETF standards,
even if there is no proposal to advance them on the standards track.
Such documents should be directed towards efforts to update
IETF standards and/or to document errata and operational issues.
A more systematic framework than today's implementation reports
would be beneficial.

1.4. The newtrk WG should be closed.

2. Conclusion from GenArea mini-BOF on IESG structure and charter.

It seemed clear in the room that people felt there was not a serious
enough problem with RFC 3710 to justify a significant effort.
There was some support for undertaking at least the first step:
  * List Tasks that Currently Gate on the IESG
in order to document whether there is in fact a problem worth
solving.

My conclusion is to ask John Leslie to lead a small team to carry out this
very specific task for the information of the community.

3. Conclusion from GenArea mini-BOF on WG Procedures (RFC 2418)

It seems there is some feeling that the RFC is beginning to show
its age, and would be worth updating.

My conclusion is that the best first step is to ask Margaret
Wasserman to lead a small team to survey participants and build
a list of issues that need updating. Of course, any actual
update to RFC 2418 would then have to follow normal IETF
consensus process.

3. Conclusion from GenArea mini-BOF on mailing list management procedures.
(draft-galvin-maillists-00.txt)

It seems clear from recent experience with RFC 3683 that something
needs to happen in this area and that feelings run deep on this issue.
However, the energy to work on this in the community is limited despite
some support in the mini-BOF for doing so.

My conclusion is, as experiments under draft-hartman-mailinglist-experiment
are possible immediately, there is no urgency to start an organized
effort right now - but it should be considered over the coming
months. Meanhwile I would like to ask Jim Galvin to update
his draft according to the discussion, for future reference.

A suggestion was made during the meeting to rapidly declare RFC 3683
obsolete.

     Brian Carpenter
     General Area Director

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 Aug 2006 12:38:46 +0200

Brian,

Your logic omits two substantial problems that NEWTRK was chartered to
address:

    * We are not practicing what we preach.  The IESG continues to
      ignore and violate Section 6.2 of RFC 2026 by not reviewing the
      state of PS and DS standards.
    * We again do not practice what we preach when we say that there are
      three tracks.  Running code largely indicates one.

Hence we need an update to indicate what it is we do practice. 
Otherwise, particularly for the first item, people can and should
legitimately ask what *other* requirements the IESG finds inconvenient. 
Furthermore, it leaves us open to people coming in and saying, "You
don't follow your own process, so please don't hide behind it when you
take an action I don't like."  The IESG must correct this issue.

In the process of doing so, we should recognize that the three step
process is obsolete.  Anyone who disgrees with that statement is
ignoring the evidence.  Our tradition as an organization is to attempt
to rectify our specifications based on running code.  Let us please do
so in this instance.

Finally, you have repeatedly failed to heed my recommendation of letting
Scott simply propose an update to the specification.  We as an
organization have trusted him and his words for a long time.  We are now
in a debacle because the IESG can't seem trust either this working group
or him.  And now we are going around endlessly through process hoops.

To say I am utterly disappointed at where we are would be an understatement.

Eliot
.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Aug 2006 13:59:47 +0200

Eliot,

I specifically do not believe there were any signs of newtrk reaching
a consensus on the first two points you mention and I specifically
do not believe that there is enough interest in the community to
justify a clarification update of 2026.

I wish it were otherwise. I have personally (co)authored several drafts
in this area over the last several years, namely
  draft-ietf-newtrk-proposals
  draft-carpenter-newtrk-twostep
  draft-carpenter-ietf-disputes
  draft-carpenter-rfc2026-critique
but without an emerging consensus for specific change we are at the end of
the road.

BTW I have just submitted an update of draft-carpenter-rfc2026-critique
which is somewhat reoriented:

    This document discusses how RFC 2026, the current description of the
    IETF standards process, operates in practice.  Its main purpose is to
    document, for information only, how actual practice interprets the
    formal rules.

There's a preview at
http://www.geocities.com/be1carpenter/draft-carpenter-rfc2026-critique-02.html

Comments welcome.

     Brian

.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 10 Aug 2006 16:06:54 +0300 (EEST)

On Thu, 10 Aug 2006, Brian E Carpenter wrote:
> I wish it were otherwise. [...]

I wish as well.  However, I agree on your reading of the rough 
consensus, and I think it's good to put the somewhat tiring process 
process to rest (for now, at least).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: John Leslie <[email-masked]>
Date: Thu, 10 Aug 2006 09:38:08 -0400

>   state of PS and DS standards.

   I'd appreciate input on whether such a task "gates on" the IESG.
RFC 2026 says:
" 
" 6.2  Advancing in the Standards Track
"... 
"  When a standards-track specification has not reached the Internet
"  Standard level but has remained at the same maturity level for
"  twenty-four (24) months, and every twelve (12) months thereafter
"  until the status is changed, the IESG shall review the viability of
"  the standardization effort responsible for that specification and the
"  usefulness of the technology. Following each such review, the IESG
"  shall approve termination or continuation of the development effort,
"  at the same time the IESG shall decide to maintain the specification
"  at the same maturity level or to move it to Historic status.  This
"  decision shall be communicated to the IETF by electronic mail to the
"  IETF Announce mailing list to allow the Internet community an
"  opportunity to comment. This provision is not intended to threaten a
"  legitimate and active Working Group effort, but rather to provide an
"  administrative mechanism for terminating a moribund effort.

   This looks a lot like it should be included in a list of "Tasks that
Currently Gate on the IESG". These are "IESG shall" tasks in a RFC
which is widely considered current and in effect. At first blush, I
would feel obliged to include these.

   Comments?

--
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: [email-masked] (Scott Bradner)
Date: Thu, 10 Aug 2006 09:47:48 -0400 (EDT)

>  I'd appreciate input on whether such a task "gates on" the IESG.

since its not being done (nor has it been done in the past) I'd say "no"

Scott
.

---

From: Scott W Brim <[email-masked]>
Date: Thu, 10 Aug 2006 10:18:58 -0400

Eliot Lear wrote:
>       ignore and violate Section 6.2 of RFC 2026 by not reviewing
>       the state of PS and DS standards.
>     * We again do not practice what we preach when we say that there
>       are three tracks.  Running code largely indicates one.

Brian E Carpenter wrote:
> I specifically do not believe there were any signs of newtrk
> reaching a consensus on the first two points you mention

There was certainly consensus on the first one.  It's a simple fact.
Let's stick to that.

> and I specifically

... which is to say, there's lots of interest but not enough to
overcome the huge barriers to success.

> since its not being done (nor has it been done in the past) I'd say

... which brings me to why I'm replying.  The purpose of the "gates
on" list is to assist thinking about the structure of IETF activity.
The fact that we are not doing something doesn't mean we shouldn't be.
IIRC most people thought standards should go through periodic review,
but we didn't have a good process for doing so.  So this item is still
on the list of things which _should_ be done, and the fact that we
don't know how to do it effectively doesn't change that.  I believe
this should go on John's list.

swb
.

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 10 Aug 2006 11:37:24 -0500

>this should go on John's list.

fully agree

.

---

From: John C Klensin <[email-masked]>
Date: Thu, 10 Aug 2006 23:18:29 -0400

> since its not being done (nor has it been done in the past)

Hmm.  Since the IESG has the option of doing it --indeed a 
requirement to do it which they have decided to not take 
seriously-- I'd say "yes"... independent of whether that 
decision is wise or not.  The relevant gate is just 
semi-permanently closed.

    john

.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Aug 2006 11:58:33 +0200

John C Klensin wrote:
> Hmm.  Since the IESG has the option of doing it --indeed a requirement 
> to do it which they have decided to not take seriously--

I can't stop myself wryly observing that this goes back a long way,
to when Certain Persons Here Present were in the IESG. In other words,
it isn't a frivolous decision by recently appointed ADs, and there's
probably a reason for it.

     Brian

  I'd say
> "yes"... independent of whether that decision is wise or not.  The 
> relevant gate is just semi-permanently closed.
> 
>    john
> 
> 
> 
> .
.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Aug 2006 11:56:23 +0200

> There was certainly consensus on the first one.  It's a simple fact.

Er, yes, what I meant of course was that there was no consensus about
what to do about those phenonema. Sorry about the careless translation
from thinking to typing.

> this should go on John's list.

In any case, when the community (typically but not always a
conscientious WG) decides to aim for DS or STD status, the IESG
approving the implementation reports and the possibly updated RFC
becomes a gating factor.

A related observation is that the doctrine for some years has been
"when a WG is done, close it." An alternative doctrine could be
"when a WG is done, recharter it to nurture its standards and when
appropriate, recommend them for promotion."  But in fact, the energy
*is* lacking in most cases, and the IESG has always been scared
of perpetual WGs that do work for work's sake.

     Brian
.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 11 Aug 2006 13:09:29 +0300 (EEST)

On Thu, 10 Aug 2006, John C Klensin wrote:
> Hmm.  Since the IESG has the option of doing it --indeed a requirement to do 
> it which they have decided to not take seriously-- I'd say "yes"... 
> independent of whether that decision is wise or not.  The relevant gate is 
> just semi-permanently closed.

Well, we recently completed a task of looking at some PS documents and 
making quite a few of them Historic.

Are folks interested in continuing that exercise for DS and newer PS 
documents?  I'd certainly be willing to spend some time in doing so. 
That way this doesn't really _need_ to gate on IESG.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 11 Aug 2006 12:20:14 +0200

> what to do about those phenonema. Sorry about the careless translation

If we simply tackle the first point and ignore the second, the IESG can
say that they are following a documented process.  The process, however,
is still a bad one because...
> But in fact, the energy

BINGO.  So there are many options to improve matters:

    * Simply combine draft and full (e.g., drop draft);
    * Drop both draft AND full; or
    * Drop both draft and full AND go with ISDs.

I really don't care which one you do but pick one, Brian, and run with
it.  The NEWTRK group has done a lot of thought here and would prefer
the latter.  All I care is that we be mindful of the words you wrote
just above "BINGO" and that we at least attempt to follow whatever
process we set down.

Eliot
.

---

From: <[email-masked]>
Date: Fri, 11 Aug 2006 13:38:34 +0300

>If we simply tackle the first point and ignore the second, the 
>IESG can say that they are following a documented process.  
>The process, however, is still a bad one because...
>> But in fact, the energy
>> *is* lacking in most cases, and the IESG has always been scared of 
>> perpetual WGs that do work for work's sake.
>
>I really don't care which one you do but pick one, Brian, and 
>run with it.  The NEWTRK group has done a lot of thought here 
>and would prefer the latter.  All I care is that we be mindful 
>of the words you wrote just above "BINGO" and that we at least 
>attempt to follow whatever process we set down.

I'm with Eliot on this one. I still think we should put our money
where our procedures are. Either follow them, or update them.  I would 
prefer either 2 or 3 from Eliots list.

Drafts get DISCUSSes if the draft doesn't follow any number of
documented 
(and sometimes undocumented) procedures.  Could we (the NEWTRK WG) issue

a DISCUSS on the entire IESG about not following 2026?

John Loughney 

Too many John's in the this group.  Everyone in the Security Area is
Steve, I
guess in the General Area, its John ...

.

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 11 Aug 2006 07:21:17 -0400

Hi John,

On Aug 10, 2006, at 11:18 PM, John C Klensin wrote:
> seriously-- I'd say "yes"... independent of whether that decision  
> is wise or not.  The relevant gate is just semi-permanently closed.

The only time that we've ever done this, to my knowledge, the work  
was completed by a design team and reviewed on the newtrk list.  The  
IESG merely had to approve the document that was produced by the  
team.  So, it is possible that the IESG could handle this  
responsibility by the periodic (perhaps annual?) appointment of a  
team to handle this for them.

I think it would be much more true to the description in RFC 2026,  
though, if we had an automated process that added a list of PS  
documents "for review" to the IESG agenda every two weeks, so that  
these documents actually were reviewed by the IESG 24 months after  
publication and every 12 months thereafter.  IMO, in addition to  
deprecating standards that are not implemented, the IESG should be  
authorized to promote standards that are known to be widely  
implemented, but that doesn't seem to be supported by RFC 2026.

The other alternative, if we don't think that this would be a useful  
way for the IESG to spend their time, is to do an update to RFC 2026  
to remove this requirement.

This points out one of the biggest flaws in our appeal process -- it  
isn't really possible to appeal a non-action, so there is no official  
way (short of a recall, which would seem awfully overblown in most  
situations) for the community to insist that individual ADs or the  
IESG as a whole do something that they haven't done or are not doing.

Margaret

.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Aug 2006 14:03:03 +0200

The review is a no-op unless the people who care have produced
an implementation report. I think that's why there is basically
no reason to do anything except encourage implementation reports.
The workload is self-regulating.

     Brian

Margaret Wasserman wrote:
>> requirement to do it which they have decided to not take  seriously-- 
>> I'd say "yes"... independent of whether that decision  is wise or 
>> not.  The relevant gate is just semi-permanently closed.
> 
> 
> The only time that we've ever done this, to my knowledge, the work  was 
> completed by a design team and reviewed on the newtrk list.  The  IESG 
> merely had to approve the document that was produced by the  team.  So, 
> it is possible that the IESG could handle this  responsibility by the 
> periodic (perhaps annual?) appointment of a  team to handle this for them.
> 
> way for the IESG to spend their time, is to do an update to RFC 2026  to 
> remove this requirement.
> 
> situations) for the community to insist that individual ADs or the  IESG 
> as a whole do something that they haven't done or are not doing.
> 
> Margaret
> 
> 
> 
> 
> .
.

---

From: Bill Fenner <[email-masked]>
Date: Fri, 11 Aug 2006 06:59:08 -0700

>publication and every 12 months thereafter.

An automated process to get this info has existed forever (*), but may be so
underpublicized that I'm the only person (including the rest of the IESG)
that knows about it: http://www.ietf.org/iesg/1old_standards.txt

There's a bit of a startup problem with the proposal of having them
automatically on the IESG agenda - there are 61 Draft Standards and
696 Proposed Standards on the list.

  Bill

(*) - web.archive.org sees a version from 2001; my recollection is that
it existed before that
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Aug 2006 17:00:16 +0200

Margaret Wasserman wrote:
> Still?  I thought that the whole point of the "cruft" exercise was to  
> clear out the backlog, so that we would be able to start fresh...  On  
> second thought, I doubt there is any way for you tool to tell which  
> documents were intentionally retained by the "cruft" exercise and  don't 
> have to be reviewed again for several months.
> 
> Of course with 750 PS and DS documents in circulation and ~25  telechats 
> per year, we're talking about having the IESG review the  status of an 
> average of 30 documents per telechat, which might be  fairly daunting 
> even after we hit steady state.

And pointless. The only ones that should ever get on an agenda are
ones supported by an implementation report (for DS), a deployment
report (for STD) or a disuse report (for Historic).

     Brian
.

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 11 Aug 2006 11:27:58 -0400

On Aug 11, 2006, at 11:00 AM, Brian E Carpenter wrote:

>> Of course with 750 PS and DS documents in circulation and ~25   
>> telechats per year, we're talking about having the IESG review  
>> the  status of an average of 30 documents per telechat, which  
>> might be  fairly daunting even after we hit steady state.
>

I agree.  Personally, I would favor a short update to RFC 2026 to  
remove this responsibility from the IESG.  In the meantime, I am not  
personally bothered by the fact that the IESG is ignoring this  
responsibility.

Margaret

.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 11 Aug 2006 17:34:48 +0200

I don't want the IESG to do such a costly review either.  I agree it is
pointless.  But let us also recognize that it should be a nail in the
coffin of a three stage standards process, and it should also seriously
bring into question the viability of a two stage process.  But I'll try
anything once.

Eliot
.

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 11 Aug 2006 10:05:25 -0400

Still?  I thought that the whole point of the "cruft" exercise was to  
clear out the backlog, so that we would be able to start fresh...  On  
second thought, I doubt there is any way for you tool to tell which  
documents were intentionally retained by the "cruft" exercise and  
don't have to be reviewed again for several months.

Of course with 750 PS and DS documents in circulation and ~25  
telechats per year, we're talking about having the IESG review the  
status of an average of 30 documents per telechat, which might be  
fairly daunting even after we hit steady state.

Margaret
.

---

From: John Leslie <[email-masked]>
Date: Fri, 11 Aug 2006 12:02:36 -0400

> report (for STD) or a disuse report (for Historic).

   Might I suggest an ION stating an IESG procedure that in the absence
of an implementation, deployment, or disuse report every PS or DS due
for IESG review shall be placed on a single agenda item to maintain
them at the same maturity level for the following 12 months?

---

From: Douglas Otis <[email-masked]>
Date: Fri, 11 Aug 2006 18:27:55 -0700

On Aug 11, 2006, at 8:27 AM, Margaret Wasserman wrote:

> remove this responsibility from the IESG.  In the meantime, I am  
> not personally bothered by the fact that the IESG is ignoring this  
> responsibility.

Would that be declaring victory, or admitting defeat?  John made a  
fairly good point.  Repeated failures in addressing an issue only  
makes the system appear less functional.  Declaring victory sounds  
more like "Stay the course."

An overlay name.serial_number reference mechanism for tracking a  
progression of RFCs in coherent sets will offer useful information.   
This reference mechanism should actually reduce administrative  
burdens as well.  As Brian suggested, such a reference mechanism does  
not require procedural change to existing processes.

The application of RFC related information is often focused upon what  
is "current" for development, and what is "stable" for production.   
While the IESG may be in a good position to declare currently  
accepted documents, a dependency upon vendors is required to  
determine the set offering "stable" interchange.  To be more  
productive and to introduce fewer conflicts, provide an easier means  
for these vendors to succinctly describe the set of RFCs used in  
their releases.  A release may indicate that it is based upon foo.37  
and bar.5.  Perhaps foo.40 and bar.6 is currently published.

Once a reference scheme is instantiated and it offers meaningful  
utility, supplanting the RFC category process may become the logical  
next step.  Currently, this path appears to be unclear.

-Doug

.

---

From: John C Klensin <[email-masked]>
Date: Sat, 12 Aug 2006 01:22:25 -0400

--On Friday, August 11, 2006 1:09 PM +0300 Pekka Savola 
<[email-masked]> wrote:

> Well, we recently completed a task of looking at some PS
> documents and making quite a few of them Historic.
>
> Are folks interested in continuing that exercise for DS and
> newer PS documents?  I'd certainly be willing to spend some
> time in doing so. That way this doesn't really _need_ to gate
> on IESG.

If the same process is followed as was used for the "decruft" 
process, the IESG still has to sign off.   That sort of small 
team effort may take the IESG (at least temporarily) out of the 
critical path, but, if I understand the concept of "gating", it 
doesn't change that fact.

   john

.

---

From: John C Klensin <[email-masked]>
Date: Sat, 12 Aug 2006 01:26:50 -0400

--On Friday, August 11, 2006 11:58 AM +0200 Brian E Carpenter 
<[email-masked]> wrote:

>> seriously--
> it isn't a frivolous decision by recently appointed ADs, and
> there's probably a reason for it.

Of course there is a reason for it.  There are probably, by now, 
several.  But the facts remain that:

(1) the written rules are not being followed.

(2) those rules put the IESG in the critical path

(3) the IESG has not raised a finger to change the rules

(4) the discussion and near/ rough consensus in Newtrk led to a 
proposal that would have significantly changed the situation, 
but the then-IESG didn't like it, so it got permanently stalled.

IMO, the next move is up to the IESG, and debating the precise 
definition of "gating" won't help anyone get to it.  And the 
only other way to make progress starts with a change in the way 
process rules/ changes are reviewed and approved.

     john

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 12 Aug 2006 19:32:47 -0500

> If the same process is followed as was used for the "decruft" process, the 
> IESG still has to sign off.   That sort of small team effort may take the 
> IESG (at least temporarily) out of the critical path, but, if I understand 
> the concept of "gating", it doesn't change that fact.
>
>   john

One thing I liked about decruft is that the IESG was delegating all the work 
except approval. "Gating" matters, but so does who does most of the work.

I would not be offended to see process change that delegates some approvals, 
but delegating work right up to the point of approval doesn't require 
process change, and somehow seems to "gate less" on the IESG.

Thanks,

Spencer 

.

---

From: John C Klensin <[email-masked]>
Date: Sat, 12 Aug 2006 22:16:15 -0400

--On Saturday, August 12, 2006 7:32 PM -0500 Spencer Dawkins 
<[email-masked]> wrote:

>> process, the  IESG still has to sign off.   That sort of
>> small team effort may take the  IESG (at least temporarily)
>> out of the critical path, but, if I understand  the concept
>> of "gating", it doesn't change that fact.
>>
>>   john
>
> One thing I liked about decruft is that the IESG was
> delegating all the work except approval. "Gating" matters, but
> so does who does most of the work.
>
> I would not be offended to see process change that delegates
> some approvals, but delegating work right up to the point of
> approval doesn't require process change, and somehow seems to
> "gate less" on the IESG.

Spencer,

This is precisely why I wish that, instead of talking about 
"gating", we were doing a serious critical path analysis of IETF 
workflow(s).

     john

.

---

From: Scott W Brim <[email-masked]>
Date: Sat, 12 Aug 2006 22:30:17 -0400

On 08/12/2006 22:16 PM, John C Klensin allegedly wrote:
> This is precisely why I wish that, instead of talking about "gating", we
> were doing a serious critical path analysis of IETF workflow(s).

Isn't "talking about 'gating'" part of that?  What would you do for a
"serious critical path analysis"?
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: John C Klensin <[email-masked]>
Date: Sat, 12 Aug 2006 23:59:37 -0400

--On Saturday, August 12, 2006 10:30 PM -0400 Scott W Brim 
<[email-masked]> wrote:

>> "gating", we were doing a serious critical path analysis of
>> IETF workflow(s).
>
> Isn't "talking about 'gating'" part of that?  What would you
> do for a "serious critical path analysis"?

It has become clear to me during the last several days of 
discussion that we don't have a clear idea / consensus about 
what "gating" means.  And a critical path analysis might point 
the finger at places other than the IESG, while this "gating" 
discussion starts with the IESG as the answer and works (IMO) 
backwards.

     john

.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 13 Aug 2006 13:41:15 +0200

Dear All,

As a reminder, the decruft process was as follows:

   1. Select a group of Proposed Standards from RFCs numbered less than
      2000;
   2. Present that list to an open mailing list that has been widely
      announced;
   3. To remove an entry from the list, someone merely needed to send a
      note saying that a particular specification was still necessary
      for some reason.  We did NO validation of the reasons;
   4. Present the trimmed list to other interested parties (e.g., rinse
      & repeat);
   5. Last call to the IETF (e.g., rinse and repeat); and finally
   6. Approval

Possible next steps include any or all of the following:

   1. Go on to PS for RFCs 2000 to, say, RFC 3830, which brings us to
      two years prior to now, and approximately the same number of
      documents as the last time;
   2. Take a look at DS for RFCs < 2000;
   3. Develop a BCP for the bunch
   4. First figure out what to do with the standards process and then
      circle back to this.

I prefer (d).

My primary reason for doing this was to allow the IESG to make true use
of PS, such that if something less than useful slips through the cracks
we can catch it in a next pass.  Before we advance any of the three
options I would want guidance from the IESG that they would find these
approaches useful.  I did so the last time based on an interest from the
IETF chair who co-authored the document and hosted the old-standards
mailing list. 

But my agreement with Harald had a second part to it, which said that we
had to make forward progress on fixing the standards track.  Obviously
Harald is not in the position he was.  However, I once again urge the
IESG to recognize that RFC 2026 needs fixing.  We need to evolve as an
organization.  It does not bode well that our processes have ossified so
much in the face of a huge amount of evidence that they need fixing.

Eliot

---

From: Douglas Otis <[email-masked]>
Date: Sun, 13 Aug 2006 09:10:11 -0700

On Aug 13, 2006, at 4:41 AM, Eliot Lear wrote:

> However, I once again urge the IESG to recognize that RFC 2026  
> needs fixing.  We need to evolve as an organization.  It does not  
> bode well that our processes have ossified so much in the face of a  
> huge amount of evidence that they need fixing.

While this may be a valid concern, document categorization has not  
been attempted as an ongoing process, most likely because it  
represents an effort best achieved by those using the information.   
Moving documents to historic asked a simple question, does anyone  
still use this document?  This first required defining the document's  
relationships with other documents by way of call-out or by formal  
reference.  The final grouping, or sets of RFCs were then  
considered.  The categorization of a small percentage of documents to  
historic offers a modicum of guidance for ongoing endeavours, where  
even this process was still highly speculative.

What should be clear is that there is greater value in being able to  
view these documents in sets as they relate to stages of various  
endeavours.  A better goal would be to first organize the information  
into a meaningful structure.  This structure alone can easily  
supplant any value that might be achieved by a categorization process  
that requires more time and knowledge than available to a small group  
attempting to administer the process.  As the number and diversity of  
endeavours increase, categorization becomes more difficult.

There are critical areas that must be watched closely and relate to  
stability of the Internet itself.  This might include careful  
evaluation of experimental efforts or dealing with new security  
issues.  Once again, knowing a document's relationship with other  
documents at various stages development would aid the focusing of  
attention on these more pressing issues.  The organization of the  
information would also provide stable references, improve  
coordination with other groups, or the discovery of the latest  
information will be made easier when more complex subjects are  
reviewed in literature.  There was a lesson to be learned in the  
decruft effort.

-Doug

.

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 13 Aug 2006 12:37:30 -0700 (PDT)

On Sun, 13 Aug 2006, Eliot Lear wrote:
> [ ... ] I once again urge the IESG to recognize that RFC 2026
> needs fixing.  We need to evolve as an organization.  It does
> not bode well that our processes have ossified so much in the
> face of a huge amount of evidence that they need fixing.

Previously, Brian E Carpenter wrote:
> I [ ... ] do not believe there were any signs of newtrk reaching
> a consensus [on] what to do about those phenonema.

Despite some suggestions to the contrary, I would have to say that
I agree with Brian's assessment.  Maybe one way forward would be
for the IESG to recharter newtrk with the specific mandate of
simply documenting what we actually practice.

//cmh

.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Aug 2006 10:56:50 +0200

Replying to three messages in one...

John Leslie wrote:
...
> Might I suggest an ION stating an IESG procedure that in the absence of an implementation, deployment, or disuse report every
> PS or DS due for IESG review shall be placed on a single agenda item to maintain them at the same maturity level for the
> following 12 months?

I'm more motivated to actively encourage the community to post
implementation, deployment, or disuse reports as a matter of course.
I think if we could get that into our DNA, the rest would flow
as a matter of course.

John C Klensin wrote:
> It has become clear to me during the last several days of discussion that we don't have a clear idea / consensus about what
> "gating" means.  And a critical path analysis might point the finger at places other than the IESG, while this "gating"
> discussion starts with the IESG as the answer and works (IMO) backwards.

I think that is true, and I ask John Leslie to take account of it.

C. M. Heard wrote:
...
> simply documenting what we actually practice.

Well, my latest update to draft-carpenter-rfc2026-critique was made
in that spirit. From that exercise, I'm not convinced a WG effort
is really needed for this, but I agree it's worth finishing :-)

     Brian
.

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Aug 2006 06:57:51 -0400

--On Thursday, 10 August, 2006 12:38 +0200 Eliot Lear
<[email-masked]> wrote:

> In the process of doing so, we should recognize that the three
> step process is obsolete.  Anyone who disgrees with that
> statement is ignoring the evidence.  Our tradition as an
> organization is to attempt to rectify our specifications based
> on running code.  Let us please do so in this instance.

Eliot,

I don't know whether it is worth prolonging this discussion, but
suggest there is a counter-hypothesis --or a least a positive
feedback cycle-- that could explain "the evidence" other than
"the three step process is obsolete".    With the understanding
that I'm no longer convinced that we need more than two steps
--at least without a drastic change in the Draft-> Full model--
the intent about Proposed was that the approval process be
fairly lightweight in all cases that didn't appear to pose a
serious danger to the Internet.  The threshold for Proposed has
grown higher and higher, with more and more nit-picking and
hoop-jumping to get a document through the system.  Under the
counter-hypothesis, this has driven  the incentives to move
beyond Proposed down because of some or all of 

	(i) It is so exhausting to get something to Proposed
	that there is no energy left.
	
	(ii) It takes so long to get to Proposed that product
	cycles dictate implementing and deploying there and then
	stopping.
	
	(iii) Documents are required to be so "finished" to get
	to Proposed that there is little point putting effort
	into trying to make an improved form.

And so on.

If any or all of those are a significant part of the problem,
then the fix may lie in lowering the effective barriers to
Proposed for lots of cases, not in major changes to the
Standards track.  And that fix does not require changes to 2026,
indeed, it is completely consistent with it.

    john

.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Aug 2006 15:00:57 +0200

There's been some good discussion but nothing that changes my
opinion that closing this WG is the right thing to do, for
the reasons I gave, above all the lack of a broad consensus
for any specific major change.

The discussion can certainly continue, and I will ask for this
list to be retained if possible, at least for a while.

I would like to thank Scott Bradner for his willingness to
chair this WG, even when things got tricky or frustrating.
Also thanks go to everyone who contributed drafts or ideas.

    Brian Carpenter
    General Area Director
.