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

Sam Hartman <hartmans-ietf@mit.edu> Thu, 29 November 2007 13:40 UTC

Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxjcY-0006Pz-7h; Thu, 29 Nov 2007 08:40:02 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxjcV-0006Ne-WA; Thu, 29 Nov 2007 08:40:00 -0500
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxjcV-000819-7D; Thu, 29 Nov 2007 08:39:59 -0500
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 575E34815; Thu, 29 Nov 2007 08:39:55 -0500 (EST)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: John C Klensin <john-ietf@jck.com>
References: <E1IxTPt-0006r4-ST@ietf.org> <474DD597.9040208@gmail.com> <CC3C6CC7EE08DA90C239082B@p3.JCK.COM> <tslve7mc8z7.fsf@mit.edu> <5EE5D61D555DB9EE083036ED@p3.JCK.COM>
Date: Thu, 29 Nov 2007 08:39:55 -0500
In-Reply-To: <5EE5D61D555DB9EE083036ED@p3.JCK.COM> (John C. Klensin's message of "Thu, 29 Nov 2007 01:56:51 -0500")
Message-ID: <tslbq9d891w.fsf@mit.edu>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: iab@ietf.org, iesg@ietf.org, ietf@ietf.org
Subject: Re: Should the RFC Editor publish an RFC in less than 2 months?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

>>>>> "John" == John C Klensin <john-ietf@jck.com> writes:

    John> --On Wednesday, 28 November, 2007 17:15 -0500 Sam Hartman
    John> <hartmans-ietf@mit.edu> wrote:

    >>>>>>> "John" == John C Klensin <john-ietf@jck.com> writes:
    >>
    John> --On Thursday, 29 November, 2007 09:54 +1300 Brian E
    John> Carpenter
    John> <brian.e.carpenter@gmail.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
    >> 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.

    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.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf