[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[INDEP] Last Call Summary of rfc-independent


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 editor

There 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. RFC3932upd

The 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
   rfc-editor at rfc-editor.org.  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 Revision

RFC 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 that
the 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 in
Section 6. The RFC Editor may also share reviews with the Editorial
Board.




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 healthy
technical dialog among the author and the reviewer(s), is fully
appropriate. Consensus followed by document revision is the desired
outcome.

   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 may
request 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 the



Klensin Expires June 24, 2007 [Page 7]
Internet-Draft Independent Submissions December 2006


issues listed in RFC 3932 or its successors, presumably from the
perspective outlined above in Section 1.2. That is, the evaluation
should focus exclusively on conflicts or confusion with IETF process
and 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 be
developed 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 free
to review a draft and, if they have comments of any kind -- including
the 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 publication
of 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 of
up to six months and, if necessary, to renew that request twice, for
a total possible delay of 18 months.

If the IESG concludes that the document should not be published as an
RFC, 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 the
IESG's request to delay or not publish the document and request that
the IAB provide an additional opinion. Such a request will be made
public 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 2006


Information about any IESG-requested publication delay or request to
not 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 policy
advice. The membership list of the Editorial Review Board is public
and 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 new
appointees from the IAB and other sources and will seek IAB comments
on 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 the
community in having any significant dissents from published documents
available to the community with the same degree of scrutiny that the
original documents received. To this end, reviews and information
about reviewers will be made public under the following
circumstances. 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 document
does so on condition of giving consent to handling of the reviews as
outlined in this section. In special cases, individual arrangements
may 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 document
authors (with possible editing to remove any extreme language). The
names 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 messages
to 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 )



   Nothing 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



This section and the next one are a significant rewrite of the text in section 6



   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 author
request must be timely, generally within 14 days of the notification
of 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 Publication

In considering whether to make review materials public for documents
accepted 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/



Attachment: PGP.sig
Description: This is a digitally signed message part

_______________________________________________
INDEPENDENT mailing list
INDEPENDENT at ietf.org
https://www1.ietf.org/mailman/listinfo/independent