Re: What is an IETF Last Call (was: Last Call: draft-carpenter-rfc2026-changes [...])

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--On Tuesday, 22 January, 2008 14:16 +0100 Frank Ellermann
<nobody@xxxxxxxxxxxxxxxxx> wrote:

> 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,

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


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]