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

From: IETF Chair <[email-masked]>
Date: Wed, 28 Nov 2007 15:21:53 -0500

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.

If we receive an appeal before the RFC is published, we can put a hold on
the document, preventing pblication until the appeal has been studied. 
However, we have no way to pull an RFC back if it is published before the
appeal arrives.  As we all know, once an RFC is published, it cannot be
changed.  Thus, the RFCs form an archival series.  If we find a bug in an
RFC, we write a revised RFC that obsoletes the one that contains the
error.  So, what should we do if there is a successful appeal after the
RFC is published?

While we figure out what policy we want, I have asked the RFC Editor to
not publish any IESG approved documents until their appeal timer has
expired.  I also challenged the RFC Editor to move things along so fast
that this matters.  I suspect they can.  Which means that the whole IETF
community needs to help the leadership figure out the appropriate policy
before the rapid processing of Internet-Draft documents into RFCs becomes
the norm.

Russ

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Nov 2007 09:54:47 +1300

On 2007-11-29 09:21, IETF Chair wrote:
...
> error.  So, what should we do if there is a successful appeal after the

I thought about this a bit when the RFC Editor started to catch up and
accelerate; it's excellent news that it's no longer a theoretical
question, so kudos to the Editor team (and IANA, who also have a role
to play in getting many RFCs out).

My conclusion is that the number of appeals is relatively low. I'd hate
for the low risk of having to roll back an approval to slow down all
publications. So my personal preference is to not hold up publication
(unless there is good reason to expect an appeal), but to add a new
RFC status, let's call it PROVISIONAL for the sake of argument, that
would be applied if an appeal is received within the 2 month window
but after publication. If the appeal succeeds, the status can be
changed as appropriate (likely to HISTORIC), and if the appeal fails
it can revert to its original value.

      Brian

---

From: John C Klensin <[email-masked]>
Date: Wed, 28 Nov 2007 16:02:48 -0500

> it can revert to its original value.

I'd like to see something like the above combined with a shorter
window, maybe at two levels ("hold publication until..." and
"provisional until...").  Of course, if an appeal is actually
filed, it would be sensible to hold publication until it is
resolved.  I don't see any possible reason why we need to give
people two months to get an appeal filed: a month or, at most,
six weeks ought to be more than sufficient.

     john

---

From: "Wassim Haddad" <[email-masked]>
Date: Wed, 28 Nov 2007 16:15:33 -0500

Hi, 

=> I also think that in general, an approach like the above is needed.
However, in some cases when for example, there is a consensus call on a 
"sensitive" draft on a specific ML, we get _sometime_ the opportunity to 
meet people who have never posted an email before to the specific ML... 
Of course, people complained about that as they just confuse the process.

My point is that the appeal will/should also be carefully examined before it 
impacts a particular RFC or ...?

Regards,

Wassim H.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Nov 2007 13:14:12 -0800

At Thu, 29 Nov 2007 09:54:47 +1300,
> it can revert to its original value.

So, obviously it's important not conflate statements about what the
rules *should* say with what they *do say*, but with that in mind, my
reading of 2026 is that this isn't necessarily sufficient. Here's
the relevant passage:

S 6.5.2.
   If circumstances warrant, the IAB may direct that an IESG decision be
   annulled, and the situation shall then be as it was before the IESG
   decision was taken. The IAB may also recommend an action to the IESG,
   or make such other recommendations as it deems fit. The IAB may not,
   however, pre-empt the role of the IESG by issuing a decision which
   only the IESG is empowered to make.

It seems to me that the situation of an existing RFC marked HISTORIC
is pretty different from that of no RFC existing at all, so what
ISTM that what you propose would require a change to 2026.

-Ekr

---

From: Ted Hardie <[email-masked]>
Date: Wed, 28 Nov 2007 13:26:56 -0800

At 4:02 PM -0500 11/28/07, John C Klensin wrote:
>So my personal preference is to not hold up
> > publication

At first I thought you meant that all RFCs would be "PROVISIONAL"
for two months, but on a second reading, what I understand you to
mean is:

1) Anything published before the appeal window closes normally gets
whatever status it would have had before (Proposed, Draft, Info, Exp).

2) Anything that gets appealed before the appeal window closed and
for which the desired remedy relates to the document's status or language
gets marked "provisional"

3) Anything for which the appeal succeeds and the remedy calls for
the document to change or the status to change sees the document
status go from "provisional" to "historic" and a new document with
a new RFC number go out with the change/new status.

I'm more-or-less okay with this, given that it does not hold up normal
processing, but I note the difference between this and just publishing
the docs and later changing their status is pretty small.  I'd personally
be willing to take the small number of cases where a document is
published but quickly moved to historic as a corner case that doesn't
need a special status.  Appeals tend to be pretty big news within our
community, and the rest of the world implements the internet drafts
anyway....

This eliminates one possible remedy:  removing something from
publication.  It's replaced with updating a document's status or
publishing an update to it saying "withdrawn as a result of appeal".
I think that's okay as a consequence of avoiding self-imposed
delay, but I do expect someone to squawk.

>six weeks ought to be more than sufficient.
 
I also agree that shortening that appeal time is a reasonable
idea, though it might require a two-stage "Notify IESG of intent
to appeal" and "File final language"; there are some two month
periods that have large dead zones (August in Europe, Christmas
season in others).

The real problem is often that the *combination* of the two month
appeal window and the IESG response time can stretch to half a
year or longer, especially when the IESG has to do significant work
to answer an appeal.  That's the only reason I think having a
special status indicating the problem is reasonable.

			Ted

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Nov 2007 10:37:20 +1300

> At Thu, 29 Nov 2007 09:54:47 +1300,

<snip>

> ISTM that what you propose would require a change to 2026.

Very possibly. It's always struck me that "the situation shall
then be as it was before" is a rather unrealistic goal, since you
can't un-send email, un-publish a draft, cancel a past mailing
list suspension, etc. Decisions can be revoked, but their
physical consequences sometimes can't be. So in any case, that
phrase in 2026 probably needs qualification. (For example,
"insofar as this is materially possible".)

     Brian

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 28 Nov 2007 17:02:12 -0500

There are a few things I think people should keep in
mind while discussing this:

Russ has presented the IETF-particular case.  If the
solution lies in IETF process (i.e., update to RFC2026),
that's fine.  If the solution lies in adjusting RFC process,
then we need to make sure there is agreement on how
that impacts the whole RFC series (i.e., wider than IETF
audience involved).

For example -- shortening the appeal window (or going
to a 2-stage process, as Ted noted) is an IETF process
change.    Determining that "withdrawing a published
RFC" meets appeal-resolution requirements is an IETF
process discussion.

Changing the status of documents, or withdrawing them
entirely, impacts the RFC series (RFC4844 and related).
A wider discussion will be needed. (Note -- that wider
discussion might be needed *anyway*, if there is belief
that the ability to withdraw a published RFC is
needed for other reasons.)

Leslie.

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: Russ Housley <[email-masked]>
Date: Wed, 28 Nov 2007 17:05:18 -0500

John:

RFC 2026 gives two months to appeal any decision.  IESG approval of a 
document publication is one such decision.  RFC 2026, section 6.5.4 says:

    All appeals must be initiated within two months of the public
    knowledge of the action or decision to be challenged.

So, the two month timer begins when the approval announcement is sent.

Russ

At 04:02 PM 11/28/2007, John C Klensin wrote:
>I don't see any possible reason why we need to give

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 28 Nov 2007 14:14:37 -0800

What happens if the appeal is claiming that changes made in Auth 48  
should have been reviewed by the working group and go against WG  
consensus? Given some of the changes I have seen between IESG  
approval and published RFC, this seems like a reasonable plausible  
scenario.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 28 Nov 2007 17:15:40 -0500

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

    John> --On Thursday, 29 November, 2007 09:54 +1300 Brian E
    John> Carpenter
    John> <[email-masked]> wrote:

    John> I'd like to see something like the above combined with a
    John> shorter window, maybe at two levels ("hold publication
    John> until..." and "provisional until...").  Of course, if an
    John> appeal is actually filed, it would be sensible to hold
    John> publication until it is resolved.  

I disagree that it is always sensible to hold publication until the
appeal is resolved, particularly for expedited publication drafts.

We've had some very bogus appeals and writing up the responses is not
always our top priority.

I agree that it is almost always desirable to delay publication once
an appeal is filed.

One critical assumption in my evaluation is that RFCs can be
withdrawn.  I'm quite confident that given a court order the RFC
editor, the IETF website, etc, would find a way to remove an RFC.  As
such, we as a community can establish our own processes for
withdrawing an RFC.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Nov 2007 14:32:34 -0800

At Wed, 28 Nov 2007 17:15:40 -0500,
> We've had some very bogus appeals and writing up the responses is not

I'm actually very concerned by this reasoning. Upon deciding an
appeal, the IESG owes the appellant a prompt response. If they don't
have time to write up a response, then that's fine, they can treat the
appeal as undecided but the document should be held pending the IESG
getting time to do that.

Remember that the appellant cannot appeal to the IAB until the IESG
has responded to his appeal (S 6.5.2.). Given that many appeals are
appeals *of IESG actions* and therefore that the IESG is not a 
neutral party, it seems quite problematic to allow the IESG
to in effect decide the appeal but simply not respond, thus denying
the appellant any avenue of recourse to a neutral body. 

In the limit, the IESG could simply internally decide to proceed as if
the appeal had been denied, but hold the appeal response indefinitely,
thus indefinitely denying the appellant further recourse under 2026.

> such, we as a community can establish our own processes for

So, clearly we need some way to withdraw documents *from the
repository*, for instance for copyright reasons, but I think that's
fundamentally a different issue from retracting them. Let's say
that document X is published at PS, but contains some purely
informational example source code. If it were later determined
that that code was improperly licensed, X would need to be
removed from the repository, but we would not treat it as if
it didn't exist. If, for instance, document Y had a normative
dependency on X, we wouldn't feel the need to go back and mark
Y HISTORIC/WITHDRAWN/whatever. We'd just go and do a noninfringing
document that obsoleted X.

By contrast, if document Z depends on document W and W is subject
to a successful appeal, we would need to withdraw Z, any documents
that depended on it, and ultimately the transitive closure of
any documents depending on W.

So, I think these cases are quite different.

-Ekr

---

From: Tim Polk <[email-masked]>
Date: Wed, 28 Nov 2007 18:02:56 -0500

I can think of an example where a minor clarification was made in  
AUTH 48.  The appropriate AD confirmed the
change but it still proved to be very controversial.  (For the life  
of me, I have *never* understood why.  I have read that
sentence a thousand times, and I still don't see the problem.  Not  
that it matters here, of course.)  I don't know
if an appeal for AUTH 48 changes has ever been filed, but I could  
certainly see it happening.

There is no way to ensure that documents aren't published until *all*  
the appeals timers expire.  Given that, let's
encourage the RFC Editor to publish when ready, and we can  
concentrate on establishing a process that works
when the appeal concerns a published document.

Tim

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 28 Nov 2007 15:18:34 -0800

One easy solution to the problem is to not change anything in the 
current IETF or RFC rules. If an RFC has been published before the 
appeal is brought, and that appeal is ultimately successful, a new 
RFC is issued that obsoletes the old RFC. That new RFC can 
essentially be a NULL, although hopefully it would have an 
explanation why an empty RFC is obsoleting a non-empty one. That new 
RFC can also be partially populated; for example, if the resolution 
of the appeal is to pull a contentious section or appendix.

Given the extreme rarity of the situation where an appeal leads to 
non-publication or changed publication, it seems wasteful to create 
new rules (and spend lots of time arguing about them) when no new 
rules are needed.

--Paul Hoffman, Director
--VPN Consortium

---

From: Sam Hartman <[email-masked]>
Date: Wed, 28 Nov 2007 19:08:53 -0500

>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:

    Eric> At Wed, 28 Nov 2007 17:15:40 -0500,
    John> --On Thursday, 29 November, 2007 09:54 +1300 Brian E
    John> Carpenter
    John> <[email-masked]> wrote:
    >>  I disagree that it is always sensible to hold publication
    >> until the appeal is resolved, particularly for expedited
    >> publication drafts.
    >> 
    >> We've had some very bogus appeals and writing up the responses
    >> is not always our top priority.

    Eric> I'm actually very concerned by this reasoning. Upon deciding
    Eric> an appeal, the IESG owes the appellant a prompt response. If
    Eric> they don't have time to write up a response, then that's
    Eric> fine, they can treat the appeal as undecided but the
    Eric> document should be held pending the IESG getting time to do
    Eric> that.

I was sloppy in my wording and thought process.

In the American legal system, there is a concept of a preliminary
injunction--a leagel procedure to stop some action pending the outcome
of some legal action.

The idea is that there are some cases where it is desirable to hold
things pending an outcome being determined, and some cases where there
is a desire to clean up the mess later if there ends up being a
problem.

I think that for some of the same reasons preliminary injunctions make
sense in the IETF, it is sometimes desirable to say that the
probability that withdrawing a document is going to be the right
solution is low enough that the appeal should not block the process.

The IESG typically doesn't "decide appeals" without actually having
response text in front of it; I think that is right and proper.

However, the IESG does sometimes know what direction it is likely to
consider in drafting response text and does have an idea about how
probable it is that publishing a document and later the IESG or IAB
realizing that a mistake was made is harmful.

I think there are cases where it is appropriate not to allow an
pending appeal to block publication.

It might be reasonable for the IAB to be able to hold publication
before an appeal had formally reached them.  Personally I think the
current IAB would be too conservative in applying this power and I'd
like the community to come up with some guidance to give the IAB if
they were going to do that regularly.  I have confidence that if the
community could agree on guidance the IAB would do a fine job of
applying that and I have confidence that absent guidance the IAB would
use their best judgment.  I just think the IAB tends to be more
conservative than would be appropriate in this case.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 28 Nov 2007 19:10:02 -0500

>>>>> "Paul" == Paul Hoffman <[email-masked]> writes:

    Paul> One easy solution to the problem is to not change anything
    Paul> in the current IETF or RFC rules. If an RFC has been
    Paul> published before the appeal is brought, and that appeal is
    Paul> ultimately successful, a new RFC is issued that obsoletes
    Paul> the old RFC. That new RFC can essentially be a NULL,
    Paul> although hopefully it would have an explanation why an empty
    Paul> RFC is obsoleting a non-empty one. That new RFC can also be
    Paul> partially populated; for example, if the resolution of the
    Paul> appeal is to pull a contentious section or appendix.

I would be happy with this solution.

    Paul> Given the extreme rarity of the situation where an appeal
    Paul> leads to non-publication or changed publication, it seems
    Paul> wasteful to create new rules (and spend lots of time arguing
    Paul> about them) when no new rules are needed.

I agree.

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 29 Nov 2007 01:31:51 +0100

John C Klensin wrote:

> Of course, if an appeal is actually filed, it would
> be sensible to hold publication until it is resolved.

+1  

That would be two months, plus another two months after
the decision if an appeal was filed and its resolution
was unsatisfactory - after all the IESG checks its own
approval, it should be unusual that the first round has
any other effect than an "are you sure ?" question for
very simple problems.

> people two months to get an appeal filed: a month or,
> at most, six weeks ought to be more than sufficient.

Now with Brian's procdoc ION six weeks might be enough.

It took me longer without it to find RFC 3710 and its
"incompatibility" with RFC 2418 more than 3 years ago.

 Frank

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Nov 2007 16:33:58 -0800

At Wed, 28 Nov 2007 19:08:53 -0500,
> solution is low enough that the appeal should not block the process.

Yes, I've been thinking about this analogy as well, but I think it
cuts the opposite way from what you're arguing. In a legal proceeding,
the two parties argue their case before a presumptively neutral
arbiter (the judge). As you say, the judge can choose to issue
a preliminary injunction while the case is being heard and
pending the final outcome. This works because at least in theory the
judge is neutral--you wouldn't let the plaintiff or the defendant
decide on whether the PI should be granted.

A 2026 appeal is an entirely different case, namely, that the
party hearing the appeal (the IESG) isn't neutral at all. On
the contrary, they're the party who's decision is being appealed! 
So, no, I don't think they can be allowed to make a decision about
whether the appellant is likely to prevail or the damage that
is likely to be done if the appeal is later upheld. 

> realizing that a mistake was made is harmful.

It seems to me that if the IESG has enough confidence about the
"direction it is likely to consider" to proceed with document
publication, they have in effect decided the appeal, regardless
of whether the response text has actually been drafted.
And if not, then they should stop publication until they have
decided the appeal.

As for the IESG's ability to predict whether the IAB will eventually
uphold an appeal, my experience is that it's not actually that
great, and, given the inherent COI involved, I don't see how
they can be allowed to make that judgement, regardless of its
expected accuracy.

> pending appeal to block publication.

That may be so. What I'm saying is that the IESG shouldn't get
to make that decision.

> conservative than would be appropriate in this case.

Well, that's not what I proposed: rather, I said there should be
a hard rule. 

That said, regardless of whether the IAB is too conservative or
not, they're at least in principle neutral, which makes them
a far more appropriate body to make this decision than the IESG,
which is not.

-Ekr

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 29 Nov 2007 07:52:20 +0100

> 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

---

From: John C Klensin <[email-masked]>
Date: Thu, 29 Nov 2007 01:56:51 -0500

--On Wednesday, 28 November, 2007 17:15 -0500 Sam Hartman
<[email-masked]> wrote:

>     John> I'd like to see something like the above combined
> with a     John> shorter window, maybe at two levels ("hold
> publication     John> until..." and "provisional until...").
> Of course, if an     John> appeal is actually filed, it would
> be sensible to hold     John> publication until it is
> resolved.  
> 
> I agree that it is almost always desirable to delay
> publication once an appeal is filed.
> 
> withdrawn.  I'm quite confident that given a court order the
> RFC editor, the IETF website, etc, would find a way to remove
> an RFC.  As such, we as a community can establish our own
> processes for withdrawing an RFC.

There would be copies floating around somewhere and it would
violate some important precedents.   I agree that we could do
this, but I hope it would only occur in response to an external
and binding order (such as the court order of your example)
rather than an IETF/IESG adoption of some version of newspeak.

Let me try to restate what I was trying to suggest (with some
changes after thinking about subsequent comments).

Historically and going back to the dawn of IETF time, when the
IESG has asked the RFC Editor to delay publication and given a
reason, the RFC Editor has complied.  I don't see any reason why
that should change, and I don't see any reason why we need to
adopt new rules and procedures for the IESG to make the request
or requiring the RFC Editor to honor it.

Independent of how long it takes the IESG to make a final
decision about an appeal, agree about text, etc., I believe that
they are able to quickly make a decision about whether or not
the appeal is totally without merit (a criterion we have
discussed before and one that is very different from "direction
it is likely to consider" or other form of pre-judgment).  I
also believe that the IESG is able to ask the IAB to quickly
consider a "totally without merit" conclusion and reach their
own conclusion about it.  

If an appeal of a standards action that would lead to RFC
publication appears to be substantive, then I really don't seem
much harm in delaying publication until the issues can be
resolved.   In reaching that conclusion, I'm drawing heavily on
two things.  The first is that we have, relatively speaking, few
appeals that get far enough to merit full IESG consideration.
We also see long delays due to IESG consideration of issues
raised during or after Last Call, sometimes by IESG members, and
working out the resolution of those issues.  It doesn't seem to
me to make a tremendous difference whether we suffer publication
delay due to pre-approval delays and negotiation or due to
delays brought on by an appeal.   In addition, while I have been
saddened by the typical length of time between approval and
publication in the last several years, and am delighted that we
are now forced to ask this question, I think there is little
evidence that the earlier publication cycles have caused us
serious harm (except, perhaps, in further reducing the
motivation to advance things along the standards track).  

The second is that, while the IESG has often taken months to
getting around to considering an appeal, generating and agreeing
on response text, etc., there is no requirement for such long
delays.  If the IESG doesn't want a lengthy publication delay,
then let it move expeditiously.

To be specific, suppose we adopted the following model, which I
believe requires no change to 2026 (some refinements are
possible if we start making modifications):

	*  If someone intends to appeal, and wants to make a
	case for publication delay until the appeal is resolved,
	they must give notice of that intent with an outline of
	issues within a month (for example).  Such a notice
	would generally result in a publication delay, at least
	for the rest of the two-month limit to permit an actual
	appeal to be filed.
	
	* When an appeal is filed, it may contain a request that
	publication be delayed until the appeal is resolved and
	an explanation as to why that action would be
	appropriate.  If it does not, publication will not be
	delayed (unless the IESG decides to block it on its own,
	which it can do at any time, with or without a pending
	appeal).   If it does contain such a request, the
	request must be granted unless the IESG concludes that
	either the appeal, or the publication delay request, is
	totally without merit _and_ gets the IAB to agree.  

Note that a publication delay request could be totally without
merit even if the appeal itself had substance if, e.g., the
appeal addressed some small issues and there was no evidence
that harm would result from publication followed by issuance of
a revised RFC.   It is also worth noting that many appeals
aren't against Standards Actions.  Even of those that are, many
don't seek to block publication, but to have some issue or
decision adjusted.  And, in most of the latter cases, there
would not be substantial harm from proceeding with publication,
especially if the IESG attached a note indicating that the
relevant features or issues were still under review, with a new,
updating, RFC to be issued later with a clarification,
correction, or affirmation of the initial text.  Whether or not
to attach such a note may, I think, be sensibly left up to the
IESG's discretion but we could expect the IESG to announce what
it was doing and, if needed, devise a fast-track appeal on that
issue along.   

Again, none of this requires a procedural change at the 2026
level, only that the IESG establish reasonable guidelines for
its own behavior, acts openly, and follows those guidelines.  If
they could not or would not do that, we have other problems.
And, incidentally, I believe that discussions about inherent
conflicts of interest in the current appeals process are
irrelevant to this discussion, for two reasons.   First, as
others have repeatedly pointed out, our appeals mechanisms are
an important tool for reaching and establishing consensus, not a
judicial procedure.  And second, if there are conflicts of
interest that we believe are unacceptable, and that belief is
based on experience rather than theory or hypothetical
situations, then we need to fix 2026 and the appeals process for
reasons and in ways that have little to do with the publication
delay question.

    john

---

From: Norbert Bollow <[email-masked]>
Date: Thu, 29 Nov 2007 09:52:51 +0100 (CET)

John C Klensin <[email-masked]> wrote:

> I don't see any possible reason why we need to give people two
> months to get an appeal filed: a month or, at most, six weeks ought
> to be more than sufficient.

+1

Greetings,
Norbert.

-- 
Norbert Bollow <[email-masked]>                      http://Norbert.ch
President of the Swiss Internet User Group SIUG    http://SIUG.ch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 29 Nov 2007 10:08:07 +0100

> new rules (and spend lots of time arguing about them) when no new  

++

Especially since presumably, an appealer would be motivated to stop  
publication of the RFC and file an appeal without delay rather than  
after 59 days.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 29 Nov 2007 01:18:43 -0800

John, I agree with just about everything you say here, except
for this:

At Thu, 29 Nov 2007 01:56:51 -0500,
John C Klensin wrote:
> judicial procedure.

Yes, it's not a judicial procedure, but nevertheless, an appeal of an
IESG action inherently involves the claim that the IESG has made a
mistake, and the IESG is not exactly in a position to judge that
neutrally. Yes, the IESG does sometimes reverse itself, but there have
also been times where the IESG has denied an appeal, the appellant has
appealled to the IAB, and the IAB has upheld it. Having been involved
in such cases, I don't think I would characterize them as 
"establishing consensus".

> And second, if there are conflicts of

I didn't say that there were COIs that were unacceptable. I said
they needed to be mitigated by ensuring that the appellant had
an opportunity to have a hearing before a neutral (or as neutral
as possible) party. I think the current 2026 procedures more
or less do that, but in this particular case there is a bug
in the process. It's not one I'd ordinarily spend a lot of time
agitating to fix, but since Russ raised the topic of delaying
publication, it's worth getting this aspect of it straight.

-Ekr

---

From: Dave Crocker <[email-masked]>
Date: Thu, 29 Nov 2007 07:20:59 -0500

Tim Polk wrote:
> There is no way to ensure that documents aren't published until *all* the
> appeals timers expire.  Given that, let's encourage the RFC Editor to
> publish when ready, and we can concentrate on establishing a process that
> works when the appeal concerns a published document.

+1

RFCs are "withdrawn" for a variety of reasons, already.  A successful appeal 
would be merely one more.  While no, "historic" is not metemantically 
identical to nevering having been published, it is sufficient that it means 
"not approved by the IETF".  Approval-vs-nonApproval seems like the most 
pragmatic test of "reversal".

The IETF approval process already has significant points of review and 
control.  While this final-stage appeal potential is real, it does not happen 
with any frequency and the dangerous community impact of publishing an RFC 
that quickly gets moved to historic are small, possibly nil.

Hence, no new mechanisms are need, although I do think it was useful to raise 
the question for discussion in this thread.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 29 Nov 2007 13:00:18 +0000

Dave Crocker wrote:

>> the
> RFCs are "withdrawn" for a variety of reasons, already.  A successful 
> appeal would be merely one more.  While no, "historic" is not 
> metemantically identical to nevering having been published, it is 
> sufficient that it means "not approved by the IETF".  
> Approval-vs-nonApproval seems like the most pragmatic test of "reversal".
>
> control.  While this final-stage appeal potential is real, it does not 
> happen with any frequency and the dangerous community impact of 
> publishing an RFC that quickly gets moved to historic are small, 
> possibly nil.

Indeed, let's optimize for the common case.

> Hence, no new mechanisms are need, although I do think it was useful 
> to raise the question for discussion in this thread.

+1.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 29 Nov 2007 15:33:12 +0200

I agree with what Dave, Tim, and Harald said. Besides, if we really
wanted a delay, we should pay the RFC Editor less and ask them to
provide slower service :-) But please keep this as a secret from the IAOC...

I would also like to point out its not the bits that are dangerous in a
mistakenly or inappropriately approved document. It is the status that
the IETF gives to these bits that matter. E.g., Proposed Standard,
product of such and such WG. The bits are already out there in many
places; we cannot withdraw them. What we can control is the status that
the IETF gives for those bits. The modern tools we have for viewing IETF
documents can make it plainly obvious to people what the status of an
RFC is.

But I would also caution a little bit against thinking that the
solutions are easy. I think we should have a short deadline for
notifying intent to appeal. However, a 5 page document may still get
through the RFC Editor in a surprisingly small amount of time. And we
can move a document to historic, but what about the other documents that
referred to it? We can delay only the documents that we know will be
appealed, but this appears to have obvious DoS problems.

Nevertheless, I think repairing damage if it occurs is probably the
right answer. Possibly combined with a short intent-to-appeal period, so
that we can try to do the right thing as soon as possible.

Jari

---

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Nov 2007 08:39:55 -0500

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

    John> --On Wednesday, 28 November, 2007 17:15 -0500 Sam Hartman

    John> --On Thursday, 29 November, 2007 09:54 +1300 Brian E
    John> Carpenter
    John> <[email-masked]> wrote:
    >> publication John> until..." and "provisional until...").  Of
    >> course, if an John> appeal is actually filed, it would be
    >> sensible to hold John> publication until it is resolved.
    >> 
    >> I disagree that it is always sensible to hold publication until
    >> the appeal is resolved, particularly for expedited publication
    >> drafts.
    >> 
    >> I agree that it is almost always desirable to delay publication
    >> once an appeal is filed.
    >> 

    John> There would be copies floating around somewhere and it would
    John> violate some important precedents.  

I agree that their would be copies floating around.  I'm not sure how
important I consider the precedents to be, although I agree they
exist.

    John> I agree that we could do
    John> this, but I hope it would only occur in response to an
    John> external and binding order (such as the court order of your
    John> example) rather than an IETF/IESG adoption of some version
    John> of newspeak.

    John> Let me try to restate what I was trying to suggest (with
    John> some changes after thinking about subsequent comments).

However with two minor points I agree with your thoughts on how we
should handle this situation.  In particular, I strongly agree that
with the possible exception of one appeal, publication delay was
desirable for all past IESG appeals.  I agree that 2026 does not need
to be changed and that your proposed model seems reasonable.

    John> Independent of how long it takes the IESG to make a final
    John> decision about an appeal, agree about text, etc., I believe
    John> that they are able to quickly make a decision about whether
    John> or not the appeal is totally without merit (a criterion we
    John> have discussed before and one that is very different from
    John> "direction it is likely to consider" or other form of
    John> pre-judgment).  I also believe that the IESG is able to ask
    John> the IAB to quickly consider a "totally without merit"
    John> conclusion and reach their own conclusion about it.

It is not clear to me that 

1) The IAB would be willing to engage in such a dialogue with the IESG
   on an outstanding appeal.
2) If they engaged in the dialogue they would be willing to  consider such a question or come to a decision.

The IAB's stanse on appeals handling has always confused me.  Section
6.5 of RFC 2026 talks about an open appeals process, but the IAB
members involved in the IESG process have always wanted to make sure
they don't have access to information related to an appeal even when
that creates inconvenience.  IAB members have created back pressure
against IESG considering involving the community in discussing open
appeals.  I get the feeling that if we discussed an appeal at the
plenary, some IAB mem members might object and the IAB might feel that
it had to ask its members not to get involved in the discussion.

I don't think the IAB or its members are being unreasonable.  I think
that the goals of the appeals process are confusing and that it would
be useful for the community to  give guidance on what it wants.
On how to balance neutrality vs openness and on how to balance  appeals process as a consensus tool against appeals process as something else.

In practice things seem to work and so it doesn't bother me if these
issues are never particularly resolved.

---

From: John C Klensin <[email-masked]>
Date: Thu, 29 Nov 2007 09:00:08 -0500

> John, I agree with just about everything you say here, except

We may not even disagree completely about that.  The key to my
comment was "irrelevant to _this_ discussion" (emphasis added).
More below.

>> an important tool for reaching and establishing consensus,
>> not a judicial procedure.
> 
> Yes, it's not a judicial procedure, but nevertheless, an
> appeal of an IESG action inherently involves the claim that
> the IESG has made a mistake, and the IESG is not exactly in a
> position to judge that neutrally. Yes, the IESG does sometimes
> reverse itself, but there have also been times where the IESG
> has denied an appeal, the appellant has appealled to the IAB,
> and the IAB has upheld it. Having been involved in such cases,
> I don't think I would characterize them as  "establishing
> consensus".

I agree.  See below.

>> situations, then we need to fix 2026 and the appeals process
>> for reasons and in ways that have little to do with the
>> publication delay question.
> 
> I didn't say that there were COIs that were unacceptable. I
> said they needed to be mitigated by ensuring that the
> appellant had an opportunity to have a hearing before a
> neutral (or as neutral as possible) party. I think the current
> 2026 procedures more or less do that, but in this particular
> case there is a bug in the process. It's not one I'd
> ordinarily spend a lot of time agitating to fix, but since
> Russ raised the topic of delaying publication, it's worth
> getting this aspect of it straight.

Well, the place where I think we disagree is _only_ about
whether introducing the timing issue and the possible conditions
for delaying publication changes anything.  

I'm not prepared to suggest a change to the procedures, in part
because I'm not convinced it is a good idea and in part because
I'm trying to go out of the business of suggesting new procedure
models (partially for personal reasons and partially because I
have come to believe that any significant change is impossible
without first changing the approval procedure for such changes).
However, I think that, for at least some cases, the appeals
procedure should be redesigned so that:

	* we identify the body that is actually responsible for
	the decision being appealed.  Sometimes that will be a
	WG Chair, sometimes an AD, sometimes the IESG.
	Empirically, it is typically the last person or body who
	has carefully considered a question (or should have)
	before the appeal about the decision on that question is
	initiated.
	
	* that body is neither expected nor permitted to make a
	formal writeup or response.  The only question for it is
	"does the content of this appeal raise issues that you
	didn't consider before, or didn't consider in enough
	depth, that, given its content you want to reopen the
	question and reconsider your own decision".  The answer
	to that question requires reading the appeal and
	responding "yes" or "no", not a long and agonizing
	process of writing and evaluating response text.
	Presumably, if they say "yes", timers start running to
	prevent rejecting an appeal by sitting on it.
	
	* actual appeal processing then starts with the next
	body up the line or with an independent appeals-review
	body.  That body can ask questions of the
	decision-making body and expect answers, but is not
	working from a record the decision-making body has
	prepared to refute the appeal.

Actually changing to something like this would require sorting
out a lot of details that I haven't even started to think about.
But it might yield a somewhat cleaner and faster process.  Then
again, it might not, or it might not be worth the effort to
design.

     john

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 29 Nov 2007 07:57:11 -0800

At 3:33 PM +0200 11/29/07, Jari Arkko wrote:
>And we
>can move a document to historic,

Note that there are two different "no process change needed" 
proposals on the table: obsoleting with NULL (or a bit of 
explanation) and moving to Historic. Obsoleting a document is much 
easier for the outside world to understand than changing its status 
to Historic, given that we have many different reasons for Historic.

--Paul Hoffman, Director
--VPN Consortium

---

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Nov 2007 11:09:12 -0500

Paul> At 3:33 PM +0200 11/29/07, Jari Arkko wrote:
    >> And we can move a document to historic,

    Paul> Note that there are two different "no process change needed"
    Paul> proposals on the table: obsoleting with NULL (or a bit of
    Paul> explanation) and moving to Historic. Obsoleting a document
    Paul> is much easier for the outside world to understand than
    Paul> changing its status to Historic, given that we have many
    Paul> different reasons for Historic.

I'd assume that you want to do both.  Remember that obseleting a
document does not imply it goes to historic.  I've never fully agreed
with that bit of rfc-editor-process trivia.

---

From: "Tom.Petch" <[email-masked]>
Date: Fri, 30 Nov 2007 11:11:12 +0100

---- Original Message -----
From: "Harald Alvestrand" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, November 29, 2007 7:52 AM
Subject: Re: Should the RFC Editor publish an RFC in less than 2 months?

<snip>
> saying that; one form of public statement is leaving a hole in the RFC

I recall a recent occasion when the IESG withdrew its approval, for
 draft-housley-tls-authz-extns
a document that both before and after its approval generated a lot of heat,
within and without a WG.

Presumably the expedited process would, or at least could, have seen that
published as an RFC.

With that example in mind, a 60 day hold seems rather a good idea.

Tom Petch

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 30 Nov 2007 12:45:38 +0100

> With that example in mind, a 60 day hold seems rather a good idea.
In that case, it went into the RFC Editor queue on June 30,, 2006, and 
was yanked from the queue on February 26, 2007 - 8 months later.

According to the "third last call" announcement:

On June 27, 2006, the IESG approved "Transport Layer Security (TLS)
Authorization Extensions," (draft-housley-tls-authz-extns) as a
proposed standard. On November 29, 2006, Redphone Security (with whom
Mark Brown, a co-author of the draft is affiliated) filed IETF IPR
disclosure 767.

it was five months between approval and the IPR disclosure.

A two-month hold wouldn't have caught it.
(No idea why it was still hanging there long enough for the IPR disclosure to catch up with it...)

               Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 01 Dec 2007 08:26:17 +1300

> disclosure to catch up with it...)

In any case, I would much rather have seen that published and later
declared Historic than hold up all other RFCs. It isn't as if the
IETF can control what actually gets implemented and deployed
in any case - so why on earth does it *matter*? Whereas getting
the vast majority of RFCs published promptly *does* matter.

     Brian

---

From: Bob Hinden <[email-masked]>
Date: Fri, 30 Nov 2007 11:57:19 -0800

> the vast majority of RFCs published promptly *does* matter.

I agree.  I don't think there should be any additional delay in RFC  
publication.  It takes long enough as is.

Unless we hold them up till any possible patent expires (e.g., 17+  
years).....

Bob