Subject: As Promised, an attempt at 2026bis

From: Eliot Lear <[email-masked]>
Date: Wed, 27 Sep 2006 11:48:39 +0200

Please find in draft-lear-ietf-rfc2026bis-00.txt a preliminary revision
of, well, RFC 2026.  It contains the following changes:

   1. A new two step process for standardization where the second step
      is optional.  In other words, you get an STD # at the first step. 
      This is a bit of compromise position.  The idea is to reflect
      reality of the existing ONE STEP process but allow that some might
      wish to indicate that a standard is indeed more mature.
   2. A suggested mapping from PS/DS/IS is included.
   3. A request is made for appropriate relabelling.
   4. There is no mandatory timeline for the IESG to reconsider
      standards on that first step, but they may do so in a manner of
      their choosing after the two year mark.
   5. Intellectual Property considerations have been removed and now
      reference BCPs 78 and 79.  These documents have changed several
      times and I imagine will evolve again.  There should be no need to
      rev or update 2026bis based on such changes.
   6. RFC 2026 actually says that one needn't submit an Internet-Draft
      in order for the RFC Editor to consider publishing an independent
      submission, but it DOES say that if you submit just a text the
      Editor will create an Internet Draft.  We've changed that so all
      RFCs should first be Internet Drafts.
   7. Some examples are updated to refer to more relevant standards
      (e.g., Goodbye, DECNET).

There are other modest changes.  At this point in time, Scott Bradner
and I solicit community input.  While discussion on the IETF main list
might be a good starting point, if it seems to go on for some period of
time, we will find another list for this purpose.  If we find
substantial support, we will ask the IESG to advance the document.

Scott and I argue that 2026 must be revised and not merely updated
because standards maturity issues are splattered across 2026.

There are a few known problems with the draft:

    * Currently the new maturity levels are Level 1 and Level 2.  The
      problem with this is that if someone in the future for some reason
      wants to try a three step process, there's no room for another
      level.  We'll come up with schnazzier names (your suggestions
      welcome - perhaps we could have a name that standard standard
      contest ;-).
    * As currently written the document does not specify how to handle
      the case when one is updating a mature version of a standard with
      an immature version.  Take for example RFCs 82[12] and 28[12].  I
      have some ideas as to how to handle this case, but your comments
      are most welcome.
    * There is a typo in the draft- my intention was for L2 standards to
      require two interoperable implementations, not three.
    * The Acknowledgment section needs updating already.  Mike O'Dell
      first and Fred Baker later have espoused ideas that come close to
      this, Ran Atkinson advised a similar proposal this year, and Scott
      Brim has spotted some existing problems.

If you would like a set of imperfect contextual diffs, you can find them
at http://www.ofcourseimright.com/pages/lear/2026bisdiffs.txt.

Regards,

Eliot

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Sep 2006 23:22:28 -0400

I support the textual descriptions of the changes Eliot made.  However
I'm concerned that as with any effort to revise RFC 2026, there will
llikely be changes in wording that have unintended consequences.  I am
not personally convinced that the value of revising RFC 2026 justifies
the risk of problems in these changes.

I'm quite convinced that if we choose to revise RFC 2026 we should do
so with a small set of goal changes--probably no more than Eliot and
Scott have proposed.  I will resist adding my pet improvements to 2026
to the list.  I encourage others who don't want this effort to drown
under its own weight to do the same.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 28 Sep 2006 06:28:40 +0200

Eliot Lear wrote:
 
> we will find another list for this purpose.

Please consider to pick an existing list like pesci or newtrk
or similar, creating new lists for everything is just bad.
 
> 2026 must be revised and not merely updated

Your points (4) to (7) sound good, but not (1) to (3).  I've
not yet read it, is your draft based on a state after Brian's
"IETF dispute draft" extracted the appeals stuff ?

> Take for example RFCs 82[12] and 28[12].

A 2822bis DS shouldn't be too difficult, unless it's the big
one integrating MIME (Bruce proposed this IIRC).  Matter of
taste, many small steps can be confusing, and one giant step
could take years (and fail).

> http://www.ofcourseimright.com/pages/lear/2026bisdiffs.txt

Thanks, that helps.

Frank

---

From: John C Klensin <[email-masked]>
Date: Thu, 28 Sep 2006 09:07:41 -0400

--On Wednesday, 27 September, 2006 23:22 -0400 Sam Hartman
<[email-masked]> wrote:

> I support the textual descriptions of the changes Eliot made.
> However I'm concerned that as with any effort to revise RFC
> 2026, there will llikely be changes in wording that have
> unintended consequences.  I am not personally convinced that
> the value of revising RFC 2026 justifies the risk of problems
> in these changes.

I share this concern.  See below.

> I'm quite convinced that if we choose to revise RFC 2026 we
> should do so with a small set of goal changes--probably no
> more than Eliot and Scott have proposed.  I will resist adding
> my pet improvements to 2026 to the list.  I encourage others
> who don't want this effort to drown under its own weight to do
> the same.

While I agree with that, I suggest that we are in something of a
conundrum.  Right now, 2026 is badly out of date in a number of
areas.  It reflects procedures and modes that we no longer
follow, only a fraction of which are addressed by Eliot's draft.
There is general community understanding and acceptance that we
are operating, not by the letter of 2026, but by the combination
of 2026 and a certain amount of, largely undocumented, oral
tradition (I expect to hear from the usual suspects on that
assertion, but it is the way it is).  To make things worse, we
have some BCPs that effectively amend 2026  but that are not
referenced in Eliot's draft -- I've pointed out some of them to
him, which I assume will be fixed, but may have missed others.

If we produce a 2026bis that does not address some of those
changes in procedure, we risk getting ourselves into a royal
mess in which it isn't clear whether the authority for unchanged
sections is 2026-as-modified, 2026-plus-oral-tradition, or
whether the new document reinstates the long-abandoned
procedures.  That situation could easily bury us in procedural
lawyers (probably the usual amateurs) and dickering... and we
have enough of those problems already, at least IMO.

I suggest, that if we are going to try to replace 2026 with this
sort of incremental change, the new document needs to be
organized in one of two ways:

(1) Every single section or subsection that is unchanged, and
most of those that are not completely rewritten to conform
exactly to current practice or deliberately changed to create a
new authority contain an explicit disclaimer that indicates that
the document does not change, reinstate, or ratify the
historical combination of 2026, formal and informal updates, and
contemporary practice and that the text is included merely for
convenience.  That would be ugly.  It would also be something we
have never done before and it is not clear to me that starting
it with 2026bis would be a good idea.  But it might do the job.

(2) 2026bis, itself, is reduced to nothing more than a list of
section headings, each one pointing to the document where the
authoritative material for that section can be found, probably
with appropriate disclaimers about some portions of 2026.  Such
a document would not update any section of 2026, deliberately or
accidentally, that it did not intend to update and would not
drop us into the conundrum.   It would make "the procedures
manual" into a lot more documents, but that has advantages as
well as disadvantages.  It would also have the small advantage
that the substantive changes Eliot proposes --such as the move
to a two-step standards process-- could be processed, and
consensus demonstrated, separately, on their own rather than
entangled with each other and with the 2026 revision.

I don't see how we can get real consensus any other way,
especially in the presence of community burnout with process
issues (my perception) and the fears that many of us share about
inadvertent changes to sections that don't get careful attention.

Just my opinion.
     john

---

From: Ned Freed <[email-masked]>
Date: Thu, 28 Sep 2006 06:29:27 -0700 (PDT)

> him, which I assume will be fixed, but may have missed others.

If that's indeed the case, the first order of business needs to be to document
current practice. I see no chance of making forward progress on actual changes
without first having a consensus as to what our current state is.

We've been in this position many times before when we've taken up protocol
specifications that have lain fallow for some period of time. In several of
these cases the exercise of getting agreement on what's actually being used
uncovered basic disagreements about the state of play of things in the world
that would have made forward progress very difficult. I think it is reasonable
to believe that this is even more important when things shift away from the
technical and towards the poltical.

				Ned

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Sep 2006 10:23:02 -0400

> without first having a consensus as to what our current state is.

I was just about to reply to John's message saying exactly the same 
thing.  My belief is that any attempt to revise 2026 is likely to 
introduce a kind of second-system effect - there is so much pent-up 
demand for changes to our process that everyone has his own idea about 
how to do it.  The only way we have any hope of getting real consensus 
on a path forward is to first get a shared understanding of where we are 
now.

Keith

---

From: Eliot Lear <[email-masked]>
Date: Thu, 28 Sep 2006 16:53:51 +0200

Hi Keith, 

> on a path forward is to first get a shared understanding of where we
> are now.

As I replied to Ned privately, our intent is to go in that direction in
general.  I believe in Brian Kantor's mantra: document existing
practices.  Furthermore, an Internet-Draft without rough consensus of
the community is just two opinions.  To that end, I'm putting aside my
own opinion on a bunch of issues in favor of trying to find that
consensus.  I think we should make additional changes to this document
that reflect reality.  Several of John's suggestions meet that criteria.

I could also imagine VERY incremental changes that are agreed to be
non-controversial.  My suggestion is that we first start by getting
agreement on the changes in the draft that are there, including two-step
process Scott & I have proposed, which I believe is a compromise between
the reality of a one step process and some peoples' desires.  I then
propose that we address other issues that have been raised
individually.  If there is consensus for a change we make it.  If not,
we don't.  I want to be that robotic in the hopes that what we end up
with will be an improvement over what we have today but with the frank
understanding that each of us would have probably wanted something just
a bit more (but in differing ways).

I also think we should also be VERY mindful of Sam Hartman's concerns
about unintended changes.

Eliot

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Sep 2006 11:19:40 -0400

-------- Original Message --------

> Hi Keith,
> 
>>> If that's indeed the case, the first order of business needs to
>>> be to document current practice. I see no chance of making
>>> forward progress on actual changes without first having a
>>> consensus as to what our current state is.
>>  demand for changes to our process that everyone has his own idea
>> about how to do it.  The only way we have any hope of getting real
>> consensus on a path forward is to first get a shared understanding
>> of where we are now.
> 
> As I replied to Ned privately, our intent is to go in that direction
> in general.  I believe in Brian Kantor's mantra: document existing 
>  the community is just two opinions.  To that end, I'm putting aside
> my own opinion on a bunch of issues in favor of trying to find that 
> consensus.  I think we should make additional changes to this
> document that reflect reality.  Several of John's suggestions meet
> that criteria.
> 
> non-controversial.

this is often how the second-system effect starts, and it nearly always 
works out badly.

> My suggestion is that we first start by getting agreement on the
> changes in the draft that are there, including two-step process Scott
> & I have proposed, which I believe is a compromise between the
> reality of a one step process and some peoples' desires. 

well, I have my own idea about how to revise the standards process, 
which, while not totally dissimilar to yours, is different enough that 
you and I are not likely to be able to agree on a compromise without a 
fair amount of discussion.  and a few dozen other people probably have 
similar ideas.  so no, I don't think that getting agreement on your 
proposal is a good first step.

it's one thing to try to get convergence between different people's 
ideas when there's a vacuum to fill, quite another to  get that 
convergence when there's something already in place and a pent-up desire 
to change it.  if you want an example of the latter, consider the IPng 
effort.  (and for an example of the former, consider the DRUMS WG - 
which was difficult enough as it turned out, but was only made easier by 
the fact that the charter expressly forbid new functionality and the 
chairs could beat people over the heads with that)

Keith

---

From: John C Klensin <[email-masked]>
Date: Thu, 28 Sep 2006 11:51:51 -0400

--On Thursday, 28 September, 2006 06:29 -0700 Ned Freed
<[email-masked]> wrote:

>> While I agree with that, I suggest that we are in something
>> of a conundrum.  Right now, 2026 is badly out of date in a
>> number of areas.  It reflects procedures and modes that we no
>> longer follow, only a fraction of which are addressed by
>> Eliot's draft. There is general community understanding and
>> acceptance that we are operating, not by the letter of 2026,
>> but by the combination of 2026 and a certain amount of,
>> largely undocumented, oral tradition (I expect to hear from
>> the usual suspects on that assertion, but it is the way it
>> is).  To make things worse, we have some BCPs that
>> effectively amend 2026  but that are not referenced in
>> Eliot's draft -- I've pointed out some of them to him, which
>> I assume will be fixed, but may have missed others.
> 
> If that's indeed the case, the first order of business needs
> to be to document current practice. I see no chance of making
> We've been in this position many times before when we've taken
> up protocol specifications that have lain fallow for some
> period of time. In several of these cases the exercise of
> getting agreement on what's actually being used uncovered
> basic disagreements about the state of play of things in the
> world that would have made forward progress very difficult. I
> think it is reasonable to believe that this is even more
> important when things shift away from the technical and
> towards the poltical.

I could not agree more.

My comments about breaking the document up so that some things
could be left unresolved were only to suggest a path forward if
Eliot was going to try to resolve and identify current practice
in some areas and not in others and others agreed that approach
was desirable.  I'm not sure that is feasible, but it might be
worth exploring if tackling all of 2026 proves infeasible.  

In either event, I concur with other comments that trying to
update 2026 to document current practice while trying to slip in
a few substantive procedural changes in opens the door to all
sorts of failure modes.

The "current practice" version of the three-step standards
process would be, IMO, to leave the three steps there (we
clearly have them and use them, even if not often) but either
remove the periodic review and timeout provisions or replace
them with some words that indicate that regular review and
advancement/demotion still reflect community desire but that, in
practice, we never do it.  Speaking personally, I could live
with either of those as a description of current status, even
though they seem contradictory, so I see some hope of getting
agreement on some very careful wording.

But a two-step process with new words and threshold conditions
isn't "current practice"; it is a new idea with all of the
difficulties in getting consensus that Keith identified and all
of the risks of inadvertent change that Sam identified.  Trying
to do that as a "current practice, except we ignore some things
that are not and slip a few new ideas in" document seems to me
to be a recipe for disaster or at least for endless wandering in
the weeds.

    john

---

From: Eliot Lear <[email-masked]>
Date: Thu, 28 Sep 2006 17:55:00 +0200

Keith,
> this is often how the second-system effect starts, and it nearly
> always works out badly.

I think the intersection of people and potentially agreeable changes is
incredibly small.  So do you apparently, as you discuss below.
> proposal is a good first step.

Propose your own.  I'm not stopping you.  And I think you're being
presumptuous about whether or not I'd like it or that we couldn't come
to some agreement.

Eliot

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Sep 2006 12:01:21 -0400

> presumptuous about whether or not I'd like it or that we couldn't come

you and I could probably agree substantially within a few days or weeks. 
  what I'm worried about is trying to get pairwise agreement or even 
rough consensus among several dozen people.  and the devil is in the 
details.

also, I'm a bit reluctant to offer my own proposal at this point out of 
concern that discussion of the relative merits of proposals to do new 
things would distract from the worthwhile effort of documenting current 
practice - especially if the discussion got heated.

but I will attempt to write down what is in my head and then decide 
whether it's something I want to make public at this time.

Keith

---

From: John Leslie <[email-masked]>
Date: Thu, 28 Sep 2006 12:26:27 -0400

I appreciate Eliot announcing his I-D here, and I am hopeful it can
lead to a better understanding of what we're facing here.

   OTOH, I find myself in agreement with John Klensin about the difficulty
of the task; and I find myself very much in agreement with Brian Carpenter
that the commitment by a broad selection of IETF folks to tackle the issue
is lacking.

   I most strongly urge Eliot to move the discussion of this draft to
another mailing-list.

   IN the absence of Eliot specifying otherwise, I suggest the NEWTRK list:

http://darkwing.uoregon.edu/~llynch/newtrk.html

--
John Leslie <[email-masked]>

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 28 Sep 2006 12:37:12 -0700 (PDT)

>       their choosing after the two year mark.

I could get behind this proposal.  However, for me the key parts 
are that you get a STD number upon entry to the standards track
and that advancement is encouraged but optional.  Indeed, I would be
just as happy with a proposal that did this but retained PS/DS/IS,
since that would be sufficient to bring the process document into
alignment with current practice.

On Thu, 28 Sep 2006, Ned Freed wrote:
>[John Klensin wrote:]

Brian Carpenter has written draft-carpenter-rfc2026-critique-02.txt
which does exactly that, and he has repeatedly solicited comments on
it.  If you think that it would be helpful to have it published as
an informational RFC before undertaking to make normative changes
to our standards procedures, please say so.

> agreement on some very careful wording.

As I noted above, I would be OK with an update to 2026 that did
just that and nothing else.  It would be a big improvement on
the current situation.

Mike

---

From: Sam Hartman <[email-masked]>
Date: Thu, 28 Sep 2006 15:47:33 -0400

>>>>> "John" == John C Klensin <[email-masked]> writes:

    John> --On Wednesday, 27 September, 2006 23:22 -0400 Sam Hartman

    >> the value of revising RFC 2026 justifies the risk of problems

    John> I share this concern.  See below.

    >> should do so with a small set of goal changes--probably no more
    >> than Eliot and Scott have proposed.  I will resist adding my
    >> pet improvements to 2026 to the list.  I encourage others who
    >> don't want this effort to drown under its own weight to do the
    >> same.

    John> While I agree with that, I suggest that we are in something
    John> of a conundrum.  Right now, 2026 is badly out of date in a
    John> number of areas.  It reflects procedures and modes that we
    John> no longer follow, only a fraction of which are addressed by
    John> Eliot's draft.  There is general community understanding and
    John> acceptance that we are operating, not by the letter of 2026,
    John> but by the combination of 2026 and a certain amount of,
    John> largely undocumented, oral tradition (I expect to hear from
    John> the usual suspects on that assertion, but it is the way it
    John> is).  To make things worse, we have some BCPs that
    John> effectively amend 2026 but that are not referenced in
    John> Eliot's draft -- I've pointed out some of them to him, which
    John> I assume will be fixed, but may have missed others.

    John> If we produce a 2026bis that does not address some of those
    John> changes in procedure, we risk getting ourselves into a royal
    John> mess in which it isn't clear whether the authority for
    John> unchanged sections is 2026-as-modified,
    John> 2026-plus-oral-tradition, or whether the new document
    John> reinstates the long-abandoned procedures.  That situation
    John> could easily bury us in procedural lawyers (probably the
    John> usual amateurs) and dickering... and we have enough of those
    John> problems already, at least IMO.

This is exactly my concern.  Trying to revise 2026 and getting it
partially wrong could be more expensive than living with oral
tradition.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 29 Sep 2006 05:32:23 +0200

> Just my opinion.

+1

Deprecating RFC 2026 section by section until nothing is left,
or the rest is simple, is a good strategy.  Brian's "dispute"
I-D would eliminate another big part of RFC 2026.

Paul's updates of RFC 1738 together with RFCs 3986 and 2396
are an example how this might finally work, about six more
URI schemes, and RFC 1738 can be buried with all honours.

This could be also a strategy for RFC 2821.  I'm firmly in
the "getting it right in less than three steps is inhuman"
camp, but for say RFC 4234, what's missing ?  There are no
pending errata I'm aware of, one CrLf objection has merits,
but it would be a huge mistake in practice, and the other
objection wrt sticky ABNF comments is "nice to have", but
no fundamental issue.

Can I now just send a mail to the IESG asking them to move
RFC 4234 to STD, or does this require a dummy I-D to create
a tracker token ?

Frank

---

From: Eliot Lear <[email-masked]>
Date: Fri, 29 Sep 2006 08:20:34 +0200

John,
> to be a recipe for disaster or at least for endless wandering in

What it requires is that people who want all their pet changes to go
into a draft to simply show some discipline and accept that not
everything will be fixed at once.  Current practice is a ONE STEP
process that is NOT documented.  Your and others' obstruction brings us
to a place where nothing moves forward and we are left in an ossified
state.  Rough consensus and running code.  Well running code requires
that we document what works.  Rough consensus requires that people come
to agreements, likely through compromises.  Right now we have neither.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Fri, 29 Sep 2006 09:16:28 +0200

I wrote
> Your and others' obstruction brings us
> state.  

This is an overstatement.  I don't think John has obstructed the process.

Eliot

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Sep 2006 03:39:58 -0400

> everything will be fixed at once. 

wtf?  no, you can't make incremental changes and expect the result to 
work better than what we have now.  in all probability it will work 
worse, much worse.  the standards process has to balance various factors 
(e.g quality vs. timeliness).  if you change one aspect at a time 
without changing the others you throw the thing out of balance.  John's 
right - it's a recipe for disaster, and it's completely unacceptable as 
a means of moving forward.

> Current practice is a ONE STEP process that is NOT documented.  Your and others' obstruction brings us

who gets to decide what is progress and what is obstruction?

Keith

---

From: Eliot Lear <[email-masked]>
Date: Fri, 29 Sep 2006 09:49:02 +0200

Keith,
> worse, much worse.  the standards process has to balance various
> factors (e.g quality vs. timeliness).  if you change one aspect at a
> time without changing the others you throw the thing out of balance. 
> John's right - it's a recipe for disaster, and it's completely
> unacceptable as a means of moving forward.

And this is fear mongering with a complete lack of specifics.  Send
text, not fear.

Eliot

---

From: Dave Cridland <[email-masked]>
Date: Fri, 29 Sep 2006 11:41:48 +0100

On Fri Sep 29 07:20:34 2006, Eliot Lear wrote:
> process that is NOT documented.

I'm not actually sure that our current standardization process *is* 
one step. In fact, I'm pretty sure that it is very far from one step. 
I readily agree that it's not documented, though.

Consider this: RFC3501 is a Proposed Standard. RFC2244 is, however, 
merely a Proposed Standard.

One is considered mature and stable by the community, and is widely 
used. The other is very rarely used, and is a considerably less 
mature specification. Neither, of course, is considered as stable, 
mature, and provenly interoperable as RFC2821, which, befitting its 
status, is at Proposed Standard.

None of this is documented, and a reader might be led to believe that 
they are all, in fact, at the same stage in the standardization 
process. This is a ludicrous idea, of course, and anyone familiar 
with email with correct them rapidly, knowing the actual status of 
these specifications.

What *is* one step is that there is only one step of our formal 
standardization process that usually gets used, in no small part 
because is has effectively been replaced by an entirely different 
standards track which operates by word of mouth.

I firmly believe that we should have documents whose status 
adequately describes the reality of their status, rather than trying 
to simplify the existing status until it happens to fit. Otherwise we 
might as well abandon the document status entirely, since it becomes 
more and more meaningless.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Sep 2006 09:34:15 -0400

> And this is fear mongering with a complete lack of specifics.  Send

And again, if we get into arguments about how to change things then we 
lose the opportunity to document current practice.  I am not sure how 
bad that is in this particular case.  If we were talking about a 
computer-to-computer protocol that was in widespread use, that would be 
a considerable loss.

In this case I suspect (though I could be wrong) that both 2026 and the 
reality that is practiced are fairly well understood here, so as long as 
we can describe new proposals in terms of how they would change things 
from 2026, people in IETF will be able to understand them and evaluate 
how much better or worse they will work than current practice.  It's 
much more difficult to read an entirely new proposal that states things 
in different terms, and evaluate how it will work against an 
organizational culture that is very much steeped in 2026.

Note that there's an important difference between describing a new 
process in relation to 2026 - but describing all of those changes at 
once - and trying to make one change at a time.  I thought you were 
proposing the latter, but I may have misunderstood.

Keith

p.s. As an aside, I do not believe that standards - be they process or 
computer protocol standards - should document current practice.  I 
believe they should document realistic and desirable practice.   the 
standard should be a benchmark that real world implementations strive to 
meet.  Sometimes they will fail.  That's not by itself a justification 
for degrading the standard.  Of course if the standard is unrealistic or 
infeasible, or if it doesn't reflect desirable practice, that's an 
argument to change the standard.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 29 Sep 2006 15:51:49 +0200

> proposing the latter, but I may have misunderstood.
I was not proposing the latter but perhaps I was not clear ;-)

Eliot

---

From: John C Klensin <[email-masked]>
Date: Fri, 29 Sep 2006 10:46:10 -0400

Eliot,

Ignoring most of the hyperbole and all of the accusations for
the moment...

--On Friday, 29 September, 2006 08:20 +0200 Eliot Lear
<[email-masked]> wrote:

>...
> Current practice is a ONE STEP process that is NOT documented.
>...

That assertion is part of the problem that prompted my earlier
note.  It simply is not true.  While we don't do periodic
reviews and don't time documents out to historic (see my earlier
suggestion about documenting that as current practice), and, as
Dave Cridland points out, we've got documents at all sort of
practical maturity levels in Proposed, we do, periodically, have
documents advancing to Draft and even to Full Standard.  

You may conclude that there aren't enough of those to count and
hence that they can be ignored.  I am not sure you would get
consensus about that conclusion.   But you cannot deny that they
exist, and exist in fairly recent practice (a quick scan shows
RFC 4502 going to Draft and RFC 4506 going to Standard as
recently as May).

>From my point of view --and this is intended to be constructive,
not obstructionist-- hyperbole like the above assertion about
current practice is one of the things that causes fears about
unintended changes.    If you had said, e.g., "current practice
is that we use the second and third levels of the process so
little that we need to adjust their descriptions to match", I'd
assume that the resulting document would be structured to deal
with them fairly, to contain a plan about any needed
transitions, etc.  But, when you assert that there is really a
one-step process now, I worry that whatever document is produced
will treat the current maturity levels in a fashion that would
have undesirable side-effects and would take multiple rounds of
straightening out.

The solution to this is not for you to say "send text".  That is
a reasonable comment if one is, e.g., a document editor
appointed by a WG whose effort has become an IETF community
effort by virtue of chartering, etc.   Without that support
structure, your pushing this draft in the way you are doing
seems to me to be a way to force the rest of the community to do
work in order to prevent you from doing damage.  

That is unattractive, especially in the presence of an
hypothesis that the community needs a break from major process
work for a while and that, without such a break, the quality of
reviews is not likely to meet the standard we need.  I don't
claim that hypothesis has consensus, but it has received some
explicit support and there are several symptoms that could be
interpreted as reinforcing it.  Those symptoms could be
interpreted in other ways as well, including that the IETF is
dying before our eyes, but...

      john

---

From: Thomas Narten <[email-masked]>
Date: Fri, 29 Sep 2006 11:29:23 -0400

> to agreements, likely through compromises.  Right now we have neither.

Let me just observe that the above sort of "you're with us or against
us" language is deeply poisoning to making progress on this overall
topic. It's divisive, and it is a cheap substitute for real discussion
of substance/issues.

I can tell you that I personally am very interested/concerned about
process improvements. But since I was once part of the "big bad
self-serving IESG", who are regularly blamed by some for all the
failures to make progress here, I have been loath to get involved. I
know that it is pretty much inevitable that I will be tarred with the
same brush at some point. When I ask myself "do I really want to deal
with this?", the answer so far has been "no, I have plenty of other
things I'd rather do." That does not mean I don't care deeply about
the topic, however.

Thomas

---

From: Eric Rosen <[email-masked]>
Date: Fri, 29 Sep 2006 11:43:22 -0400

On  the issue  of whether  we have  a de  facto one-step  process,  the real
question is not  whether subsequent steps are ever  invoked, but whether the
subsequent steps  actually have any  practical impact on the  Internet.  One
can certainly  point to a  handful of cases  where the subsequent  steps are
invoked,  but the  point is  that  it makes  no difference  to the  Internet
whether the  subsequent steps are  invoked or not.   So I think it  is quite
accurate to say that we have a de facto one-step process. 

It is thus logical for advocates of the one-step process to argue that we in
fact have more  or less what we  need, and to be skeptical  of anything that
might result in giving more credence  to (or even calling more attention to)
the subsequent steps.

The real problem with the process  is that a protocol can be widely deployed
in multiple interoperable implementations for  six or seven years before its
specification even achieves  this one step.  This can  happen because the WG
gets inundated with idiots, and/or because companies are using the IETF as a
marketing  battleground,  and/or  because  the IESG  deliberately  tries  to
obstruct progress, and/or because the security ADs require you to figure out
the insanely complicated endsystem-oriented security architecture so you can
explain why  you don't need to  adhere to it.   I'm pretty sure there  is no
IESG-wide consensus on how to address  these issues, but if one has suffered
through any of these multiple year  delays, one is likely to oppose anything
that reeks  of "more process".  This can  lead one to be  suspicious even of
writeups  that claim  to  be  "descriptive", as  the  writeups may  (whether
intended to do so or not)  serve to extend the life of various problematical
processes that might wither away faster if they were never written down.

Sometimes it's just better to leave well enough alone.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 29 Sep 2006 23:28:56 +0200

John,

Rather than discuss what's hyperbole and what's not, I direct your
attention to http://www.ofcourseimright.com/pages/lear/spy.jpg.  One
could argue that things worked about  as one would have expected perhaps
through 1996 for draft standard.  Beyond that it's clear that things
went off the rail.  For full, it's hard to argue they were ever really
on the rail.  Either that or we're truly producing a lot of schlock.  I
don't believe the latter.  I think in general we're doing good work, and
decruft hinted at that (although it couldn't conclusively demonstrate it
because of the bounds of the experiment).

For what it's worth, the methodology used was gluing bibliographical
lines together from rfc-index.txt and then grepping "$YEAR." and each
standard level out, followed by a word count for the result.  This might
possibly under-report PS documents that have been marked Historic
through the decruft experiment.  I haven't checked.  Code available upon
request.

My point here is that the three step process is not used as intended. 
Existing practice clearly demonstrates that the vast majority of our
work - far more than intended - never reaches beyond PS.  This is
reality.  Simply documenting that fact in a new RFC2026bis would be to
say, "Our standards are broken and we know they're broken."  That's not
what motivated me to write a draft.  What motivated me to write a draft
was that it's important that we say what we do and we do what we say. 
The 2nd step for me is a compromise, on the off chance someone really
wants to demonstrate a higher level of interoperability, but the
economic motivations not to mention the headaches involved with getting
there do not lead me to have a lot of faith that it will be used
either.  But that didn't stop me from including it.

Finally, I have no vote on the IESG, nor does my co-author.  Our work
carries only the moral authority you and others believe it should.  The
phrase "send text" is an invitation to the community to make it and our
current state of affairs better, and by no means a threat.  Rough
consensus prevents most dumb ideas from getting through, but not all.  I
share your concerns that it is possible to make things worse, and I
trust you'll be vocal as you have been if you believe that we're moving
in the wrong direction.

Eliot

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 29 Sep 2006 18:14:39 -0400

> was that it's important that we say what we do and we do what we say.

Then write that.  We have a process which defines three stages and what has 
to happen to progress to each stage.  Where reality diverges from RFC2026 
is that 2026 specifies particular timelines for reviewing documents and 
progressing them along the standards track, while what actually happens is 
that documents are progressed only when someone cares enough about them to 
make it happen.  As your graph shows, we published documents at all three 
levels last year.

We could eliminate one or both of the extra steps entirely, or become more 
agressive about actually making them happen, or do any of a wide variety of 
other things to make them happen.  But none of those would be consistent 
with current practice, which is to progress documents beyond PS if and only 
if someone cares enough to make it happen.

---

From: John C Klensin <[email-masked]>
Date: Fri, 29 Sep 2006 18:49:44 -0400

--On Friday, 29 September, 2006 18:14 -0400 Jeffrey Hutzelman
<[email-masked]> wrote:

> On Friday, September 29, 2006 11:28:56 PM +0200 Eliot Lear
> <[email-masked]> wrote:
> 
>...
>> My point here is that the three step process is not used as
>> intended. Existing practice clearly demonstrates that the
>> vast majority of our work - far more than intended - never
>> reaches beyond PS.  This is reality.  Simply documenting that
>> fact in a new RFC2026bis would be to say, "Our standards are
>> broken and we know they're broken."

Actually, there is no evidence, in your graph or otherwise, that
"our standards are broken".  There is evidence that some
particular provisions of 2026 are being ignored, i.e., are not
consistent with current practice.   That is, IMO, rather
different.   If you want to reflect current practice, you remove
or correct those provisions  of 2026, you don't try to change
the definitions of the standards track itself, nor suggest that
the other stages are unused.

>>  That's not what
>> motivated me to write a draft.  What motivated me to write a
>> draft was that it's important that we say what we do and we
>> do what we say.

We are in agreement about that, assuming it can be done safely
and without either unintentional changes or changes, however
well intentioned, that go beyond current practice.

> Then write that.  We have a process which defines three stages
> and what has to happen to progress to each stage.  Where
> reality diverges from RFC2026 is that 2026 specifies
> particular timelines for reviewing documents and progressing
> them along the standards track, while what actually happens is
> that documents are progressed only when someone cares enough
> about them to make it happen.  As your graph shows, we
> published documents at all three levels last year.
> 
> We could eliminate one or both of the extra steps entirely, or
> become more agressive about actually making them happen, or do
> any of a wide variety of other things to make them happen.
> But none of those would be consistent with current practice,
> which is to progress documents beyond PS if and only if
> someone cares enough to make it happen.

+1

    john