ietf
[Top] [All Lists]

Re: Should the RFC Editor publish an RFC in less than 2 months?

2007-11-28 23:53:20
IETF Chair skrev:
Dear IETF Community:

Due to a lot of hard work, the RFC Editor is publishing approved
Internet-Drafts more quickly.  Overall this is just what we want to
happen.  However, I am concerned that the RFC Editor is might be getting
too quick.  Anyone can appeal the approval of a document in the two months
following the approval.  In the past, there was not any danger of the RFC
Editor publishing a document before this timer expired, and the only
documents that became RFCs in less than 60 days were the ones where the
IESG explicitly asked for expedited processing.  The recent improvements
by the RFC Editor make it likely that all documents will be moving through
the publication process in less than two months.
  
My short reply: Bad idea.

In my opinion, placing such a hold on documents is a triumph of process
over sanity.

We have already lost the opportunity to restrict the circulation of the
text when we published the I-D, which anyone in the world can copy. So
the further aggravation of having copies out there of a document with an
RFC number that isn't in the index any more is, if it is a difference at
all, an extremely marginal one.

So the remedy of "making the text not published" is already unavailable.

In that case, the only difference between "holding an approved document
and then not publishing it" and "publishing an RFC and then withdrawing
it" is that in the latter case, we're left with a permanent mark in our
RFC Index saying "This RFC was withdrawn". (I know this option does not
exist now, as Leslie pointed out. I have big problems seeing a situation
where it would be appropriate, but if people really argue that we need
it once we admit that we can't "unpublish" an I-D, we can change the rules.)

If we err so egregriously as to end up in a situation where a retraction
is the appropriate remedy (as opposed to the situation where we can
publish another RFC saying "on further consideration, the idea we
approved in RFC 6666 was stupid, and we regret doing it; it's now
Historic"), having to live with the blame for such a mark "forever" is
appropriate and just punishment.

We're ALREADY in a no-hold situation in many cases; when someone appeals
the decision on an appealed approval, we do NOT, in general, hold the
publication of the RFC, even though we are not just afraid there'll be
an appeal, we positively *know* that there is an appeal. The same thing
applies for appeals against the RFC Editor/WG chair/author's decision to
approve an AUTH48 change.

Such a hold is a dumb idea, and we shouldn't do it. Just publish, and if
we turn out to have made the wrong decision, make a public statement
saying that; one form of public statement is leaving a hole in the RFC
Index.

(As to the ideas for further complexity in the process with
"provisional" markers considered by Brian and John: My opinion is that
they add cost, and in practice provide zero value. Just publish, and if
needed, unlist.)

                     Harald



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf