Dear Colleagues,
I have reviewed the discussion on the independent list and conclude that there is general consensus to publish draft-klensin- independent. The IAB has agreed to shepherd this document through its publication stream, and have offered an editor to help finish editing this document to the consensus perspective (see details of currently proposed edits below). After the modifications have been made we will post the document once more (as draft-iab-rfc-independent) and announce it on this list. We will move for publication shortly after the document has been announced; if people want to review draft-iab-rfc-independent-00 they should carefully watch the announcement here.
ould carefully watch the announcement here. Thanks to John for his zeal and patience during editorship!Below are a number of distinct issues that came up during last call and a summary of what I see as (emerging) consensus. If there is no feedback on these within this week the editor will be asked to work on the text along the instructions below.
Substantive issues.1. Is Independent Submission track is solely for publication of Informational/Experimental RFC?
Add a few clarifying words (informative language) to indicate that the stream is only intended to Informational/Experimental issues, possibly refer to 2026 to clarify that BCPs and standards track documents must be discussed in the IETF and approved by the IESG.
2. Use of the word "Historically"(see http://www1.ietf.org/mail-archive/web/independent/current/ msg00194.html) There does not seem to be consensus that the use of the word "historically" is a problem.
3. The interaction between "independent" and modifications and/or creation of IANA registries.
There seems consensus that the document should not try to solve these issues and that these issues will in practice be caught by the RFC editor or IESG review. It has been suggested to raise awareness about possible interactions with a reference to RFC2434 but it seems (my opinion) that that sort of instruction is to detailed for this level of document. I therefore propose not to include text along those lines.
4. Independent publication of documents resulting from IETF process.My reading of the discussion is that this issue is a hot topic that does not necessarily needs to be covered in the document. Under the current independent text the RFC editor has sufficient flexibility to set its own policy on publication of this set of document.
I am carefully using the words "my reading of" since I am not sure if consensus is reached. I would like to invite people that disagree with dismissing this issue, to send in text.
5. Requests to not publish the document by the IESG.The consensus in this (reappearing) discussion is that the IESG should be able to provide their arguments against publication to the RFC-editor. It is the RFC-editor has the purview for deciding on publication.
The inconsistency between 2 and 4.8 will need to be resolved with appropriate text.
7. Exact timing of interaction between IESG and RFC editorThere seems to be consensus for the idea posted by John in point [1] in http://www1.ietf.org/mail-archive/web/independent/current/ msg00226.html
6. RFC3932updThe references to 3932upd should be removed. I suggest that removing the first paragraph of 1.2 is sufficient in this context and that the second paragraph of 1.2 and the text in the second paragraph of 4.2 reflect the consensus that I described in issue 5.
Editorial issues: * RFC 3978 vs RFC 4748.IPR related text in section 7 will need small mods to reflect the state of the world as of RFC 4748. (See suggestions in http://www1.ietf.org/mail-archive/web/independent/ current/msg00194.html)
* Additional editorial issues.I am aware that John received a number of editorial nits. One of the bigger ones (suggested by Bob Braden) is replicated below. The annotations are mine and I've tried to indicate the change with respect to version 5. I copied these here because I think that they do not contain substantive changes but are a significant enough rewrite that they may come as a surprise when folk see the final draft.
Thanks to all that have participated, --Olaf
4.2. Request for Publication After the normal opportunity for community review and feedback provided by the submission of the I-D and the I-D repository announcement thereof, the author or editor sends a request for consideration for publication to the RFC Editor at [EMAIL PROTECTED] That request should note any community discussion or reviews of the document that have occurred before submission, as well as the desired document category.
Adding "as well as the desired document category."
4.3. Initial RFC Editor Review and RevisionRFC Editor staff performs an initial check on the document. If they believe there is a high likelihood of conflicts or other interactions with IETF efforts (including believing that the document is one thatthe IESG should probably process), they may forward it to the IESG, or relevant ADs, for preliminary evaluation and comment.
The following paragraph has been added:
At any time during the process, the RFC Editor may make general and/or specific suggestions to the author on how to improve the editorial quality of the document and note any specific violations of the rules. The author will be expected to make the suggested updates, submit a new version, and inform the RFC Editor. This may be repeated as often as necessary to obtain an acceptable editorial quality.
A bit of reordering.. the original 4.4 "Document Rejection moved"
4.4. Review and Evaluation The RFC Editor arranges for one or more reviews of the document. This may include Editorial Board (see Section 5) reviews or reviews by others.
The next paragraph is moved from the original 6.2
At minimum, the author of every document shall receive a written summary of the review(s). Reviewer anonymity is discussed inSection 6. The RFC Editor may also share reviews with the EditorialBoard.
The original 4.4 on document rejection contained some words on working with the author to improve the document. That concept has been removed from that section and placed here.
An author rebuttal to some aspect of a review, followed by a healthytechnical dialog among the author and the reviewer(s), is fullyappropriate. Consensus followed by document revision is the desiredoutcome. The RFC Editor is expected to consider all competent reviews carefully, and in the absence of some unusual circumstance, a preponderance of favorable reviews should lead to publication. Unsolicited reviews from parties independent of the author are welcome at any time. Unsolicited reviews will be shared with the author, including the identity of the reviewer. 4.5 Additional Reviews
This paragraph has been rewritten. The last sentence is a new clarification.
If the author is unsatisfied with one or more revies, the author mayrequest that the RFC Editor solicit additional reviews. In exceptional circumstances, the author may request that the IAB review the document. Such requests to the IAB, and any reviews the IAB chooses to perform, will occur according to procedures of the IAB's choosing. The IAB is not required to initiate a review or comply with a request for one: a request to the IAB for a review is not an appeal process. 4.6 Document Rejection
As previously mentioned, the part about iterating towards success has been moved up.
If any stage of the review process just described leads to the
conclusion that the document is not publishable, the RFC Editor may
reject the document ("Do Not Publish" or "DNP"). Such rejection
would normally be based on the conclusion that the submission does
not meet the technical or editorial standards of the RFC Series or
is not relevant to the areas that the series covers.
If a document is rejected by the RFC Editor, the author may request
an additional review from the IAB, as described above, but the IAB
is not obligated to do that review, nor is the RFC Editor obligated
to publish even with a favorable IAB review.
The "Final IESG Review" paragraph was copied entirely.
4.7. Final IESG Review Once the RFC Editor has made a tentative decision to publish, the document is forwarded to the IESG for evaluation with a relatively short timeout. The IESG evaluation is not a technical one. Instead, it covers theKlensin Expires June 24, 2007 [Page 7] Internet-Draft Independent Submissions December 2006issues listed in RFC 3932 or its successors, presumably from the perspective outlined above in Section 1.2. That is, the evaluationshould focus exclusively on conflicts or confusion with IETF processand attempts to subvert ("end run") working group activities. At the time the document is forwarded to the IESG, the RFC Editor will post an indication on its web pages that the document is under IESG review and that comments on conflicts can be sent to the IESG with copies to the RFC Editor. Additional mechanisms may bedeveloped from time to time to inform a community that a document is entering formal prepublication review. Comments not directly related to IETF procedures or conflicts may be sent directly to the author(s)and RFC Editor. In addition to the IESG review for conflict with IETF work, individuals in the IESG, or in the broader IETF community, are freeto review a draft and, if they have comments of any kind -- includingthe extreme case of believing that the proposal is damaging to the Internet as a whole-- these comments should be directed to the authors and the RFC Editor.If the IESG, after completing its review, concludes that publicationof the document should be delayed for a reasonable period of time, the RFC Editor will grant that request. The current agreement between the RFC Editor and the IESG on requested delays is expected to continue. That agreement permits the IESG to ask for a delay ofup to six months and, if necessary, to renew that request twice, fora total possible delay of 18 months.If the IESG concludes that the document should not be published as anRFC, it will request that the RFC Editor not publish and provide appropriate justification for that request. The RFC Editor will consider the request to not publish the document. The RFC Editor or the author may request that the IAB review theIESG's request to delay or not publish the document and request thatthe IAB provide an additional opinion. Such a request will be madepublic via the RFC Editor web site. As with the IESG review itself,the IAB's opinion, if any, will be advisory. And, as with author requests for an IAB technical review (see Section 4.7), the IAB is not obligated to perform this type of review and may decline the request. 4.8. Final Decision and Notification In all cases, the ultimate decision to publish or not publish, and with what language, rests with the RFC Editor.
The following sentence has been added (Nit: "communicate the final decision communicated")
The RFC Editor will communicate the final decision communicated to the author and the Editorial Board. For a rejection, there will be a summary of the reason(s) for the action.Klensin Expires June 24, 2007 [Page 8] Internet-Draft Independent Submissions December 2006Information about any IESG-requested publication delay or request tonot publish a document will be posted to the RFC Editor web site to supplement document status information.
No change in the following paragraphs
4.9. Final Editing and Publication Once a document is approved for publication, it is edited and published in a fashion similar to other RFCs, with principles about priorities worked out with the IAB as appropriate. 5. The Editorial Review Board The RFC Editor appoints and maintains an Editorial Review Board which, much like the Editorial Boards of professional journals and publishers, provides the RFC Editor with both advice and reviews of particular proposed publications and general and strategic policyadvice. The membership list of the Editorial Review Board is publicand can be found at http://www.rfc-editor.org/edboard.html. Editorial Board members serve at the pleasure of the RFC Editor. From time to time, the RFC Editor will solicit suggestions for newappointees from the IAB and other sources and will seek IAB commentson those to be appointed and on the effectiveness of the review process and the quality of documents being published and criteria applied. However, to ensure the independence of the independent submission process, the final decision to appoint (or not appoint) Editorial Board members rests with the RFC Editor. 6. Status and Availability of Reviews The RFC Editor will conduct the reviews discussed above with the intent of balancing fairness to authors, transparancy of the review process to the general community, protection of reviewers from possible retaliation or undue pressure, and the interest of thecommunity in having any significant dissents from published documents available to the community with the same degree of scrutiny that theoriginal documents received. To this end, reviews and information about reviewers will be made public under the followingcircumstances. In special cases in which other considerations apply,the RFC Editor may adopt special provisions after reviewing the circumstances and proposed action with the IAB. Any reviewer participating in the process outlined in this documentdoes so on condition of giving consent to handling of the reviews as outlined in this section. In special cases, individual arrangementsmay be worked out in advance with the RFC Editor.
Text below is significantly modified.
As described in 4.4, all reviews will be shared with the documentauthors (with possible editing to remove any extreme language). Thenames of the reviewers will normally accompany these reviews, but reviewers will be granted anonymity upon request to the RFC Editor.The RFC Editor will in any case forward any author rebuttal messagesto the reviewer.Klensin Expires June 24, 2007 [Page 9] Internet-Draft Independent Submissions December 2006
The following pragraph moved up from one of the subsections. (Nit: subsections below )
This section and the next one are a significant rewrite of the text in section 6Nothing in this section or the subsections above precludes private communications between reviewers, the Editorial Board, and the RFC Editor; such communications will remain confidential. 6.1 Posted Reviews
Once a final accept or reject decision has been made on a document, the RFC Editor may choose to post the full set of reviews (and author rebuttals, if any) associated with a document, if doing so would be in the best interest of the community. The author may request earlier posting of reviews and rebuttals, to inspire additional unsolicited reviews, for example. The names of the reviewers will accompany their reviews, except for a reviewer who requested anonymity. The author will be notified of the intent to post the final reviews in advance. The author may then request that the document be withdrawn and the reviews kept private. However, such authorrequest must be timely, generally within 14 days of the notificationof intent to post. 6.2. Rejected Documents If the RFC Editor rejects a document, the author has the following recourses. o Request one or more additional reviews (Section 4.5) followed by a reconsideration. o Request an IAB-initiated review (Sections 4.5, 4.6) followed by a reconsideration. o Request that the reviews be published on the RFC Editor web site.
The following subsection was created from original text.
6.3. Documents Approved for PublicationIn considering whether to make review materials public for documentsaccepted for publication, the RFC Editor is expected to note that the best way to comment on, or dissent from, an RFC is generally another RFC; that reviews critical of a document are not themselves reviewed; that the review and refutation process is necessarily fragmentary; and that a reviewer who feels strongly about a subject about which a review has already been written often would not need to do significant additional work to produce an RFC-format document from that review.
-- ----------------------------------------------------------- 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
