Olaf M. Kolkman wrote:
-- Issue 3: IESG control over publication of documents.
The I-D implies that the IESG can prevent publication when it thinks
that the publication is damaging to the Internet in section 2. This
text is argued to extend RFC 3932. RFC3932 narrows the IESG review to
review w.r.t. conflict with IETF work and process.
The I-D continues to describe the mechanics of how the IESG can delay
publication in section 4.8.
I think that this discussion if the IESG needs to or is allowed to
block publication did not conclude and we will not be able to complete
it due time. I think that the most reasonable way forward is to
removed the perceived conflict with RFC 3932 from the I-D. Brian's
suggestion d.d. Jul 7 is a reasonable replacement text.
In addition to the IESG review for conflict with IETF work [RFC3932],
individuals in the IESG, or in the IETF community as a whole,
are free to review a draft, and if they have comments of any kind,
including the extreme case of believing the proposal is damaging
to the Internet as whole, these comments should be directed to
the authors and the RFC Editor.
Point remains that there may be situations where a document _is_
damaging and where the IESG has strong reasons to block such document.
I think, how creative, that this again can be addressed in an update
of RFC 3932.
So as to get some discussion on something else than Joe's rants about
"control"...
I remember a bit of case-by-case on this issue when writing RFC 3932.
The decision tree goes something like this:
1. Document is not harmful to the Internet
No problem!
2. Document is harmful to the Internet
2.1 The RFC Editor discovers that it is
2.1.1 The RFC Editor decides not to publish
No problem!
2.1.2 The RFC Editor decides to publish anyway
Problem!
2.2 The RFC Editor does not discover that it is harmful
2.2.1 The RFC Editor decides not to publish for other reasons
No problem!
2.2.2 The RFC Editor sends the document to IESG for review
2.2.2.1 The IESG does not discover that it is harmful
Problem for the Internet, but no conflict
2.2.2.2 The IESG discovers that it is harmful
2.2.2.2.1 The IESG convinces the RFC Editor that it is
harmful
2.2.2.2.1.1 The RFC Editor decides not to publish
No problem!
2.2.2.2.1.2 The RFC Editor decides to publish anyway
Conflict!
2.2.2.2.2 The IESG is not able to convince the RFC
Editor that it is harmful
2.2.2.2.2.1 The RFC Editor decides to not publish
No problem! (but some bad feelings?)
2.2.2.2.2.2 The RFC Editor decides to publish anyway
Conflict!
So the cases where we have a conflict are:
1) The RFC Editor decides to publish documents that it knows are harmful
to the Internet
2) The RFC Editor disagrees with the IESG about whether or not they are
harmful to the Internet
If the first case occurs, I think we have bigger problems than a
conflict with the IESG - we have an RFC Editor who is CONSCIOUSLY
harming the Internet.
I think the second case is rare enough that it doesn't warrant granting
the IESG special powers to block publication - and I'm not at all sure
the IESG will always be right and the RFC Editor always wrong.
Anyway, that was my reasoning at 3932 time...... when rereading
draft-klensin-rfc-independent-02 section 2, I don't see anything that
allows the IESG to block stuff for technical reasons there. So that's
consistent.
Harald
_______________________________________________
INDEPENDENT mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/independent
