Subject: Re: Last Call: draft-carpenter-rfc2026-changes (Changes to the ..

From: [email-masked] (Scott O. Bradner)
Date: Mon, 21 Jan 2008 16:50:52 -0500 (EST)

sorry - it does not make any sense at all to last call this document 

it has had no meaningful discussion - we should not be updating our
core process documents this flippantly 

Scott

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

---

From: Russ Housley <[email-masked]>
Date: Mon, 21 Jan 2008 17:07:10 -0500

Scott:

There have been several attempts to generate discussion on prior 
versions of this document by its author.  Very little resulted.  I am 
using the Last Call to make sure that discussion happens, and it has 
worked.  It has generated review, and not just superficial 
review.  And the resulting comments are generating interesting discussion.

I'd like to see you contribute to the discussion.  As author of RFC 
2026, your thoughts are quite pertinent.

Russ

---

From: John C Klensin <[email-masked]>
Date: Mon, 21 Jan 2008 17:07:33 -0500

--On Monday, 21 January, 2008 16:50 -0500 "Scott O. Bradner"
<[email-masked]> wrote:

> it has had no meaningful discussion - we should not be
> updating our core process documents this flippantly 

FWIW, while I don't see anything flippant in either the author's
intentions or in the Last Call announcement, I have to agree
with Scott.  Only a couple of people commented on this prior to
the Last Call announcement.  I fear that confirms my hypothesis
that the community has gotten burned out on process work and
that it is going to be very hard to get meaningful consensus on
changes across the community (rather than among those who get
excited about process issues).

Even ignoring the issue of how meaningful consensus is to be
determined, my recollection is that some of the few comments
pointed out problems and suggested changes which the author
agreed to make.  That would suggest that we should at least see
a revision (to -03) that reflects the author's latest thinking
before a Last Call is announced.

Significant changes to 2026 --even changes that the author
believes are just updates to reflect current practice-- are
important enough to justify, e.g., a plenary presentation and
discussion in Philadelphia.  We've got too much experience
making changes to process documents that seemed reasonable, did
not get careful and extensive review, and that turned out to
have significant unintended consequences.  A conclusion that the
document isn't important enough to justify plenary discussion or
the equivalent is, for me, a conclusion that we don't need it
right now.

    john

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 21 Jan 2008 14:24:22 -0800

As a procedural matter, I agree with Scott and John. This
document should not be considered for advancement at this
time nor until such time as there is real evidence of
widespread consensus.

As a substantive issue, renaming PS and DS to Preliminary
and Deplyable strikes me as a terrible idea. Whatever the
merits of the current names, they are the ones we have and
changing them now will only create confusion. Deployable
is a particularly bad choice since PSs are regularly
deployed.

-Ekr

At Mon, 21 Jan 2008 17:07:33 -0500,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Jan 2008 12:03:50 +1300

> time nor until such time as there is real evidence of

Actually, I agree too, but I also agree with Russ that the
discussion needed something noticeable to trigger it.

> is a particularly bad choice since PSs are regularly

I will listen to the consensus view on this, of course.
I think we have to recognize that the original roles
intended for PS and DS have been changed in practice,
and that may be hard for newcomers to appreciate.

    Brian

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 21 Jan 2008 15:08:10 -0800

At Tue, 22 Jan 2008 12:03:50 +1300,
> discussion needed something noticeable to trigger it.

I agree with Scott that this is not an appropriate use of
Last Call.

> I will listen to the consensus view on this, of course.

I think this has the burden backwards: there needs to be
strong consensus to make major changes, not just weak
opposition.

> and that may be hard for newcomers to appreciate.

Yes, but I don't think your renaming helps that.

-Ekr

---

From: Brian Dickson <[email-masked]>
Date: Mon, 21 Jan 2008 18:35:14 -0500

> is a particularly bad choice since PSs are regularly
How about:

PS = Published Standard (how it starts life - being published)
DS = Deployed Standard (reaches this *after* interoperable deployments 
exist)

Brian Dickson

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 22 Jan 2008 01:23:10 +0100

Russ Housley skrev:
> worked.  It has generated review, and not just superficial review. 
> And the resulting comments are generating interesting discussion.
Call a BOF on it. If not a WG.

The discussion of a focused charter that could encompass this should be
interesting.

Using a Last Call as a wakeup call is a Bad Move.

               Harald

---

From: John C Klensin <[email-masked]>
Date: Tue, 22 Jan 2008 06:10:18 -0500

> discussion needed something noticeable to trigger it.

Brian,

I feel so strongly that it is inappropriate to try to use a Last
Call as a means to stimulate community discussion and interest
on this document that it is hard for me to comment
substantively.  I have even found myself speculating on whether
an appeal is in order (because a Last Call is an IESG action,
such an appeal is clearly possible procedurally).

However, one general observation...

> and that may be hard for newcomers to appreciate.

I think we all recognize that.   But subtle changes in
terminology will tend to confuse everyone rather than help.
Many newcomers and many of those who have been involved for a
longer period will  encounter both sets of terminology and will
wonder if something has actually changed or if we are just
playing with words.  Others will encounter only one and make
whatever assumptions they make.

In retrospect, I think we made a serious mistake when we started
using "standard" and "proposed" as part of the same phrase.  As
Scott pointed out, it is a little late to try to change that
now.  In an odd way, it has worked to our advantage: we don't
hear "you shouldn't use that because it isn't a Standard" nearly
as often as we might had we chosen terms for PS that don't
involve the term "standard" at all.

I certainly agree that 2026 needs significant work.  I agree
with the comments of several others that we need to revise it
and, probably, divide it into pieces in the process rather than
working on a patch document.   But therein lies the main problem
I see with your draft: it tries to patch and push little changes
through instead of addressing issues head-on.    

This terminology change is a good example.  While we may differ
on whether it needs to be fixed (and when) and what the fix
should be, I believe there are very few people in the community
who believe that the maturity levels in 2026 reflect both
current reality and what, given current reality, we would like
the levels to be and represent.  While consensus probably
extends that far, recent years have seen a large number of
attempts to actually change things.  We've had proposals for one
step and for two, proposals to change the way we think about
things by bundling the documents and associating the concept of
"standard" with the bundles rather than individual maturity
levels, at least one proposal to change how we number and when,
and so on.  While the reasons differ, the thing that all of
those proposals have in common is that they didn't go anywhere.
It seems to me that trying to bypass whatever perceived problems
stimulated those proposals by tweaking terminology is a waste of
energy at best.

    john

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 22 Jan 2008 14:16:02 +0100

John C Klensin wrote:

> I have even found myself speculating on whether an appeal
> is in order (because a Last Call is an IESG action, such
> an appeal is clearly possible procedurally).

I've seen see how not issuing a Last Call can cause harm.
I didn't understand why the Jabber-ID Last Call vanished
in a black hole without stating a compelling reason here.

But I fail to see how starting a Last Call too early can
cause harm, or why you felt tempted to file an appeal.

About three years ago you explained that appeals against
proposed actions make no sense, and the earliest moment to
stop a draft by appeal is its approval, not its Last Call.

At some point in time authors need to know if investing
more time in a draft is justified, and a Last Call is one
way of a reality check.  If author + 3rd party (sponsor)
think that a draft is ready, what else should they do ?

 Frank

---

From: Ned Freed <[email-masked]>
Date: Thu, 24 Jan 2008 10:31:47 -0800 (PST)

> time nor until such time as there is real evidence of

I have to agree with Scott, John and Ekr about this. It's not that change isn't
needed, but rather that this set of changes hasn't received sufficient review
and comment. I also agree with John's assessment that insufficient review given
to process change has in the past opened the door to unintended consequences of
various sorts.

> is a particularly bad choice since PSs are regularly

I'm by no means a fan of the current names (draft standard is IMO particularly
problematic) but I agree with Ekr that this change is liable to cause more
problems than it solves.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Thu, 24 Jan 2008 14:40:44 -0500

> think that a draft is ready, what else should they do ?

Frank,

Everyone has their own favorite issues with RFC 2026 and most of
us have problems with it that they believe are serious enough to
fix.  What we have seen in this discussion (and many before it)
is that there is little consensus on which issues are the most
important, nor about what should be done about them.  

One of my favorites is that 2026 applies exactly the same
processes to development of, and changes to, IETF procedures
that we apply to technical documents (standards track and
otherwise).   While others may disagree, I believe we've got a
large number of worked examples of where having the two models
be the same has caused harm.   Some would even argue that the
entire Newtrk WG process was an example of the problem.  Others
might point to the fact that the IESG can block consideration of
any changes to the IESG or its role, confusion about what "Best
Current Practice" means when applied to a procedure we haven't
used yet, whether the RFC series is the best place and mechanism
to publish IETF procedures (a topic that IONs address part, but
not all, of), and so on.

So, yes, I've said on many occasions that I believe the IESG
should be able to generate a Last Call on virtually anything,
for any reason, on which it wants a community opinion.  I
continue to believe that about technical specifications and
related informational materials.  Even then, I believe that the
IESG has some obligation to be clear in the Last Call
announcement what sort of input they are asking for.  While I
don't believe the community would be helped by trying to codify
forms of Last Call, there is a difference between "we are
considering standardizing this, speak up if you have strong
opinions, especially negative ones", "we are considering
publishing this...", and "we are looking for community comment
on whether this is worth pursuing".  I think Last Call
announcements should reflect those differences.  For technical
documents, they generally do (although obviously not in those
words).

However, I think procedural documents are different.  The
activity of considering and discussing them is disruptive of the
community.  Because they affect how we do things across the
board, I think a Last Call --especially a Last Call that implies
that the IESG is seriously considering adoption and that
community silence might be construed as assent-- is
inappropriate in the absence of clear indications of community
support for, and interest in, the work.  Making procedural
changes on the basis of a small number of comments, especially
procedural changes that are essentially patchwork modifications,
seems to me to be much too dangerous, and much too costly in
terms of the time it takes to consider them, to move into Last
Call without evidence of community consensus that there is
interest in the issues, that a document has sufficient support
to be worth a larger review, and that there broad willingness to
review it carefully and evaluate it.   In this case, I don't see
those conditions as having been met before the Last Call was
launched.  

Discussions subsequent to the last call being issued have
reinforced my impression that the Last Call was inappropriate,
premature, or both.  There has been little discussion except
among the handful of people in the community who can be counted
on to comment on almost any procedural issues (that includes you
and, unfortunately, me).  Much of the discussion has focused on
"this is the wrong way to approach the topic" and not on issues
with the document itself and how it can be approved.  Unless
those questions have been raised before and somehow resolved, I
would contend that is almost always a sign that a Last Call on a
procedural proposal is premature.

   john

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 29 Jan 2008 02:39:29 +0100

> important, nor about what should be done about them.

Yes, and after various attempts to create a 2026bis failed I think
Brian's approach to "fix" only a few low hanging fruits is fine.

In theory, of course some arguments (example) against renaming PS
and DS here convinced me that those are not "low hanging fruits".

> Some would even argue that the entire Newtrk WG process was an
> example of the problem.

I only hope that "PUFI" uses one of the existing PESCI (or was it
PECSI ?), newtrk, etc. mailing lists instead of starting its own.

> there is a difference between "we are considering standardizing
> this, speak up if you have strong opinions, especially negative
> ones", "we are considering publishing this...", and "we are
> looking for community comment on whether this is worth pursuing".
> I think Last Call announcements should reflect those differences.
> For technical documents, they generally do (although obviously
> not in those words).

They didn't explicitly say that the 2821bis Last Call was actually
only a call to finish 2822upd... ;-)  

> I think procedural documents are different.  The activity of 
> considering and discussing them is disruptive of the community.

I guess that's because you feel they are very important.  Often 
I think about topics I consider as very important, "oh no, I have
no time for this, why must they screw *now* with it, nothing is
horribly wrong with how it is", etc.

> I think a Last Call --especially a Last Call that implies that
> the IESG is seriously considering adoption and that community
> silence might be construed as assent-- is inappropriate in the
> absence of clear indications of community support for, and
> interest in, the work.

I thought that "Last Call" means that *one* AD prepares a later
IESG decision.  Not that the IESG collectively considers adoption,
or has necessarily an idea what the Last Call is about before the
various voluntary review teams create an "executive summary".

> There has been little discussion except among the handful of
> people in the community who can be counted on to comment on
> almost any procedural issues (that includes you and, 
> unfortunately, me).

Yes, changing the rules makes me nervous for the known reasons.
But if an author, here Brian, tries to fix some known problems,
then that's good, and at some point in time the author needs to
know what others think about the proposed fixes.

 Frank

---

From: John C Klensin <[email-masked]>
Date: Mon, 28 Jan 2008 21:20:03 -0500

--On Tuesday, 29 January, 2008 02:39 +0100 Frank Ellermann
<[email-masked]> wrote:

> I guess that's because you feel they are very important.
> Often  I think about topics I consider as very important, "oh
> no, I have no time for this, why must they screw *now* with
> it, nothing is horribly wrong with how it is", etc.

No, it is for another reason entirely.   My personal criterion
for when it is reasonable to approve, e.g., a standards-track
document is when that document represents rough consensus among
those who care, are materially concerned, and have sufficient
competence to have an opinion.  That implies that, if there is a
piece of technical work about which I do not care and am not
concerned, it is reasonable for me to ignore it and keep working
on things I do care about.  

Because process documents --especially ones that propose to make
fairly fundamental to 2026-- affect every one of us and
everything we do in the IETF, a Last Call on one should be
construed as a statement by the IESG that the topic is important
enough that we should all lay aside whatever technical work we
are doing and review it.  That "laying aside" process is a big
enough deal (and disruptive enough of other work) that I believe
there should be at least some minimal evidence that the
community cares and believes that the proposed solution is
either the correct one or one on which we can reasonably build.  

Incidentally, the reason I tend to oppose, or think we should be
very cautious about, process BOFs is a corollary of the above:
I'm uncomfortable having process decisions made by the subset of
the community who would rather spend their time in process BOFs
or at face to face process WG meetings, rather than the whole
community.   At the risk of prompting a note from Spencer, I
would almost prefer that we tell people that, by registering for
an IETF meeting, they agree to run the risk of having to spend
some time in a process meeting, then select an appropriate
number of people at random and make them come.  It would almost
certainly not work, but it would at least be far more
representative than what happens when we schedule a process BOF
against substantive WG sessions.

   john