Issue 3 (Re: [INDEP] Forward with independent)

[Harald Alvestrand <harald at alvestrand.no>]

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
INDEPENDENT at ietf.org
https://www1.ietf.org/mailman/listinfo/independent