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

[John C Klensin <[e-mail]>]

--On Thursday, 29 November, 2007 01:18 -0800 Eric Rescorla
<[e-mail]> wrote:

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

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

> At Thu, 29 Nov 2007 01:56:51 -0500,
> John C Klensin wrote:
>> 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.
> 
> 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.

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




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