|
Re: Last Call: 'The IESG and RFC Editor documents: Procedures' to BCP
2004-05-12 01:14:34
--On Tuesday, May 11, 2004 12:39 PM -0400 Scott Bradner
<sob(_at_)harvard(_dot_)edu> wrote:
in general that seems OK though I'd like to see "including the
possibility of the author pursuing the work within the IETF"
added
Clearly I intended that option to be included. I didn't state
it for two reasons. First, I thought it was obvious. Second,
it felt like it was looking for trouble to identify one example
("pursue the work within the IETF" while not identifying any
others. And, bluntly, the obvious other example is "the IESG
beats the author (I hope only intellectually and metaphorically)
to a pulp and convinces him that the document is really stupid
and will cause him embarrassment for the rest of his life". I
don't want to go anywhere near that in this sort of document,
but avoiding doing anything that would permit someone to
complain that AD administration of a clue-by-four (even
aggressively) is inappropriate.
Much more broadly and IMO, if the IETF is going to be worth
anything a few years from now, the ADs have to be enabled to
educate, and encouraged and expected to do so, even when the
subject of such education is unwilling. As long as "education"
doesn't shift into "intimidation", if the side effect of such
education is withdrawal of a dumb document, then I think it is
wonderful. This isn't the critical mainstream for this
document, with or without the suggested modifications, but,
based on the experience of the last few years, I get really
worried about text -- especially new text-- in these procedural
documents that enables or encourages potential protocol
lawyers... whether they are inside the IESG or outside the core
IETF community.
john
--On Tuesday, May 11, 2004 12:39 PM -0400 Scott Bradner
<sob(_at_)harvard(_dot_)edu> wrote:
in general that seems OK though I'd like to see "including the
possibility of the author pursuing the work within the IETF"
added
----
From john-ietf(_at_)jck(_dot_)com Tue May 11 12:18:30 2004
X-Original-To: sob(_at_)newdev(_dot_)harvard(_dot_)edu
Delivered-To: sob(_at_)newdev(_dot_)harvard(_dot_)edu
Date: Tue, 11 May 2004 12:18:20 -0400
From: John C Klensin <john-ietf(_at_)jck(_dot_)com>
To: Scott Bradner <sob(_at_)harvard(_dot_)edu>, harald(_at_)alvestrand(_dot_)no,
iesg(_at_)ietf(_dot_)org, ietf(_at_)ietf(_dot_)org
Subject: Re: Last Call: 'The IESG and RFC Editor documents:
Procedures' to BCP
In-Reply-To:
<20040511135704(_dot_)3E2D51E97E8(_at_)newdev(_dot_)harvard(_dot_)edu>
References:
<20040511135704(_dot_)3E2D51E97E8(_at_)newdev(_dot_)harvard(_dot_)edu>
X-Mailer: Mulberry/3.1.3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Scott, Harald,
It seems to me that this problem/ disagreement could be easily
solved while preserving the (IMO, valid) points both of you
are making, by including a sentence somewhere to the effect
of...
Of course, the IESG or individual ADs may have
discussions with the author during this period about
other possible ways to handle the document. Should that
discussion result in a voluntary action by the author to
drop the request to the RFC Editor to publist, the
document moves immediately outside the scope of this
specification.
Now, that may not be the right phrasing in context, and can
certainly be improved. But I think it covers the full range
of from "we really think this should be standardized, why not
let us process it that way" to "if you insist on publishing
that thing, I'm going to break both of your legs". The
question of whether those actions are appropriate is a
separate issue, but the IESG has never been able to insist on
either standardization or withdrawal. And, as far as I know,
both actions are identical as far as the RFC Editor is
concerned: the document is spontaneously withdrawn as an
individual submission.
john
--On Tuesday, May 11, 2004 9:57 AM -0400 Scott Bradner
<sob(_at_)harvard(_dot_)edu> wrote:
Anything else should (IMHO) be advice to the RFC Editor and
the author, and not be part of the formal position-taking
the IESG makes.
we may be debating termonology
your ID says "The IESG may return five different responses"
that seems to eliminate the possibility of communicating any
such advice
Because in the past, we've seriously bogged down independent
publications because we were debating (with or without the
author) whether or not they should be IETF work.
And we need to stop doing that.
beware of tossing too much away just to "stop doing that"
I still fail to see why this document cannot say that one of
the outcomes could be that the author could agree with the
IESG to bring the work into the IETF - it seems a bit
dogmatic to refuse to say that (and counter to the intent of
2026)
Scott
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
----
From john-ietf(_at_)jck(_dot_)com Tue May 11 12:18:30 2004
X-Original-To: sob(_at_)newdev(_dot_)harvard(_dot_)edu
Delivered-To: sob(_at_)newdev(_dot_)harvard(_dot_)edu
Date: Tue, 11 May 2004 12:18:20 -0400
From: John C Klensin <john-ietf(_at_)jck(_dot_)com>
To: Scott Bradner <sob(_at_)harvard(_dot_)edu>, harald(_at_)alvestrand(_dot_)no,
iesg(_at_)ietf(_dot_)org, ietf(_at_)ietf(_dot_)org
Subject: Re: Last Call: 'The IESG and RFC Editor documents:
Procedures' to BCP
In-Reply-To:
<20040511135704(_dot_)3E2D51E97E8(_at_)newdev(_dot_)harvard(_dot_)edu>
References:
<20040511135704(_dot_)3E2D51E97E8(_at_)newdev(_dot_)harvard(_dot_)edu>
X-Mailer: Mulberry/3.1.3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Scott, Harald,
It seems to me that this problem/ disagreement could be easily
solved while preserving the (IMO, valid) points both of you
are making, by including a sentence somewhere to the effect
of...
Of course, the IESG or individual ADs may have
discussions with the author during this period about
other possible ways to handle the document. Should that
discussion result in a voluntary action by the author to
drop the request to the RFC Editor to publist, the
document moves immediately outside the scope of this
specification.
Now, that may not be the right phrasing in context, and can
certainly be improved. But I think it covers the full range
of from "we really think this should be standardized, why not
let us process it that way" to "if you insist on publishing
that thing, I'm going to break both of your legs". The
question of whether those actions are appropriate is a
separate issue, but the IESG has never been able to insist on
either standardization or withdrawal. And, as far as I know,
both actions are identical as far as the RFC Editor is
concerned: the document is spontaneously withdrawn as an
individual submission.
john
--On Tuesday, May 11, 2004 9:57 AM -0400 Scott Bradner
<sob(_at_)harvard(_dot_)edu> wrote:
Anything else should (IMHO) be advice to the RFC Editor and
the author, and not be part of the formal position-taking
the IESG makes.
we may be debating termonology
your ID says "The IESG may return five different responses"
that seems to eliminate the possibility of communicating any
such advice
Because in the past, we've seriously bogged down independent
publications because we were debating (with or without the
author) whether or not they should be IETF work.
And we need to stop doing that.
beware of tossing too much away just to "stop doing that"
I still fail to see why this document cannot say that one of
the outcomes could be that the author could agree with the
IESG to bring the work into the IETF - it seems a bit
dogmatic to refuse to say that (and counter to the intent of
2026)
Scott
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
|
|