Kind Colleagues,
After the IAB plenary discussion the open issues concerning the independent stream were presented[1]. We offered the possibility to provide feedback and directed people to this mailinglist to (re)voice their arguments. It has been a bit quiet.
I think that it is fair to say that there is a consensus that the independent stream is an important part of the mix and that it for now will remain part of the RFC editor's responsibility to facilitate the stream.
In the remainder of this mail I will re-iterate the issues and provide my idea about a way forward.
You will notice that there are a couple of issues that are not being put forward as issues but that were mentioned on this list and in the plenary. Those are related to exact boilerplate text and making distinction between the RFCs from the independent stream and the other streams. Those issues are currently out of scope. We are trying to describe the status quo and the ways to go forward with the independent publication process.
When mentioning the I-D below I refer to draft-klensin-rfc- independent-02.
-- Issue 1 and Issue 2 The IETF does/says/thinksCurrent boilerplate and other texts should carefully word if a statement is made on behalf of the IETF, if a statement is made on behalf of the IETF there should be IETF consensus.
The I-D identifies this issue in its appendix. And suggests ways to fix this issue that contradict RFC3932. It seems, although there has been little feedback, that the appendix of the I-D catches the spirit of the way forward, except that this I-D is not the place to fix RFC 3932. I therefore think that the way forward is to remove the appendix from the I-D and that RFC 3932 is to be updated. The RFP does not seem to be dependent of the outcome of that process.
-- 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.
--Issue 4: Editorial boardWhere is the accountability of the editorial board and who gets to hire and fire the editorial board.
The I-D clearly puts the responsibility for hiring and firing with the the RFC editor but only after soliciting input from the IAB and others (section 5).
On the first part of this issue, accountability, the document describes that reviews are on which decisions by the RFC-editor are based are in general posted publicly albeit possibly anonymous (section 4-5). This section only solves part of the accountability issue since it does not allow a feed-back on the posted reviews, there has been a bit of discussion on the mailinglist. I propose that the document states that the RFC-editor will solicit feed-back on review process and quality as part of the process to for seeking new appointees to the review board.
----Concluding, the I-D will need to be trimmed and it seems that an update of RFC3932bis is required, or at least should be discussed. If there are no objections to this we will proceed by asking John to update the I-D according to the outline above. The I-D will then be published as an iab document.
rfc-iab-rfc-editor-01 will describe how the IAB will play a facilitating role when changing the procedures with RFC3932-bis. In other words changes can happen.
Kind regards, --OlafPS: I wrote this mail in the role of moderator trying to find an outcome that satisfies community needs, for which there is rough consensus and with which the IAB can run.
[1] Plenary slides are at http://www3.ietf.org/proceedings/06jul/ slides/plenaryt-3.pdf
----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ INDEPENDENT mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/independent
