"John" == John C Klensin <john-ietf(_at_)jck(_dot_)com> writes:
John> --On Wednesday, 28 November, 2007 17:15 -0500 Sam Hartman
John> <hartmans-ietf(_at_)mit(_dot_)edu> wrote:
>>>>>>> "John" == John C Klensin <john-ietf(_at_)jck(_dot_)com> writes:
John> --On Thursday, 29 November, 2007 09:54 +1300 Brian E
John> <brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> 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
>> 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.
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
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.
Ietf mailing list