Subject: [INDEP] Last Call Summary of rfc-independent

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 8 Feb 2007 11:10:30 +0100

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
>    [email-masked].  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/

_______________________________________________
INDEPENDENT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/independent

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 Feb 2007 15:10:50 +0200

> of document. I therefore propose not to include text along those lines.
Are you saying RFC 3932 is the normative rule on that? I can
buy that. But remember that these documents do not exist
just to document the rules for our process. They will also be
read by people who are considering submitting an RFC to
one of the streams. To help them make the right decision
I think it is essential to point to the IANA rules. We should
not repeat the rules or start elaborating anything stated
in RFC 3932, 2434 or any of the Standards Track RFCs that
lay out the rules for IANA considerations in any specific
case. But even from a truth-in-marketing point of view the
document needs to warn people that they have to check
whether the IANA rules allow non-IETF submissions.
> consensus is reached. I would like to invite people that disagree with
> dismissing this issue, to send in text.

This is indeed a hot topic, and one where we may still
be learning for quite a while. Perhaps after that
learning process we should write another RFC on
the treatment of documents resulting from unsuccessfully
terminated IETF processes.

My take would be to provide a fairly small amount of
guidance and without any hard rules about this topic
in both draft-klensin and draft-iesg. I think we already
do that, though as I recall there was a slight tone
difference between the documents.

Text needed. I feel responsible and promise to send
some.
> The consensus in this (reappearing) discussion is that the IESG should
> be able to provide their arguments against publication to the

Right.
> in
> http://www1.ietf.org/mail-archive/web/independent/current/msg00226.html
>
Ack.
> reflect the consensus that I described in issue 5.
Yep.

Jari

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 13 Feb 2007 15:25:31 +0100

> Thanks for summarizing. Responding to a couple of points inline:

Thanks for the response, apologies for my late reply.

> whether the IANA rules allow non-IETF submissions.

I was not precise enough when saying "trying to solve these issues".

"these issues" were mainly referring to the discussion who has the
responsibility to catch problems with IANA considerations the RFC  
editor or
the IESG during 3932 review.

Raising awareness of possible problems with IANA considerations,
as a reminder to independent authors certainly does not hurt but I do  
not
immediately see where such text would fit naturally.

(While writing the above I stumbled upon one case is not clear to  
myself:
can an independent submission  'create' a new registry? I personally do
not see any reason why it shouldn't-- at least within bounds of what the
assignment criteria of the values in that namespace would be-- but I  
cannot
find normative text)

> Text needed. I feel responsible and promise to send

Looking forward to that... could you give an ETA?

--Olaf

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Feb 2007 17:23:41 +0100

On 2007-02-13 15:25, Olaf M. Kolkman wrote:
...
> (While writing the above I stumbled upon one case is not clear to myself:
> assignment criteria of the values in that namespace would be-- but I cannot
> find normative text) 

IANA operates under a formal MoU (available as RFC 2860) that says it
follows RFCs, but takes guidance from the IESG in case of doubt:

    4.1. The IANA will assign and register Internet protocol parameters
    only as directed by the criteria and procedures specified in RFCs,
    including Proposed, Draft and full Internet Standards and Best
    Current Practice documents, and any other RFC that calls for IANA
    assignment.
    ...

    If in doubt or in case of a technical dispute, IANA will seek and
    follow technical guidance exclusively from the IESG. Where
    appropriate the IESG will appoint an expert to advise IANA.

So I think it's fairly clear that any RFC could create a registry,
but if it creates a problem, it comes to the IESG.

      Brian

---

From: John C Klensin <[email-masked]>
Date: Tue, 13 Feb 2007 13:21:46 -0500

--On Tuesday, 13 February, 2007 17:23 +0100 Brian E Carpenter
<[email-masked]> wrote:

>...
> So I think it's fairly clear that any RFC could create a
> registry, but if it creates a problem, it comes to the IESG.

Brian,

FWIW, my feeling is that, if the IANA and IESG have a good
working relationship, the IANA ought to be able to say "this
independent submission draft is about to create a registry, if
you have any serious objections, say so" to the IESG and get (or
not get) an equally informal response.   Given a good working
relationship, I don't see any need to establish a formal
procedure for that, especially not one that needs to be
reflected in the "independent" draft.  And, of course, if there
isn't a good working relationship, then this issue is rather far
down on the list of problems that will need to be solved.

In addition, as far as I can tell, ICANN can direct IANA to
establish other sorts of registries, or to create procedures for
establishing other sorts of registries.  To do so consistent
with the MOU, all they would need to do is to define those
registries as not being about "Internet protocol parameters".
For example, IANA does not today consider the database
associated with ccTLD administrations to be a protocol parameter
registry.

As far as the text is concerned, I think this topic is best left
alone.

Speaking just for myself, of course.

    john

---

From: JFC Morfin <[email-masked]>
Date: Wed, 14 Feb 2007 04:12:46 +0100

At 19:21 13/02/2007, John C Klensin wrote:
>For example, IANA does not today consider the database associated 
>with ccTLD administrations to be a protocol parameter registry.

The ICANN/IANA/IETF RFC 2860 MoU says that ICANN is responsible for 
names and numbers. So, which is the IANA database that 
IANA/ICANN/IETF consider as a contry code protocol parameter registry?

This was actively discussed at the IGF today. Questions I noted:

1) can a Dynamic Coalition introduce independent Draft, or should 
they be better introduced as for a Draft for information?
2) in many cases the need would rather be for BCP (in order to 
maintain a unique BCP number when updating documents)
3) interoperability between ISO based documents and IANA RFC 4646 LSER.
4) common forum (in order to avoid one liaison MoU per Dynamic 
Coalition and more complex relations)?
5) case of a submission documenting a non IANA registry: what should 
the IANA do: implement a mirror, have a table of links, enter the 
links in the IANA RFC 4646 LSER (Extension Registry meant to register 
external links)?

All the best
jfc

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Feb 2007 09:47:24 +0100

I agree completely, including your conclusion.

     Brian

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 14 Feb 2007 09:59:32 +0100

I agree (and already mentioned) that there is consensus on not  
documenting the IANA/IESG/RFC editor interaction on this issue. But  
there where several people that asked for at least a reference so  
that independent contributors are being made aware of the  
interaction. As said, I also do not know exactly where that text  
should go maybe Dave has a bright idea :-)

Brian, thanks for that pointer. That was indeed what I was looking  
for and it provided the familiar Deja Vu :-).

--Olaf