[INDEP] Re: comments on draft-klensin-independent-05.txt

[Bob Braden <[e-mail]>]

----- Begin Included Message -----

>From [e-mail]  Wed Jan 10 12:47:23 2007
X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 
	autolearn=ham version=3.1.0
From: Bob Braden <[e-mail]>
Date: Wed, 10 Jan 2007 12:46:32 -0800 (PST)
To: [e-mail]
Subject: Re: comments on draft-klensin-independent-05.txt
Cc: [e-mail], [e-mail]
X-ISI-4-43-8-MailScanner: Found to be clean


  *> 
  *> 
  *> Network Working Group                                    J. Klensin, Ed.
  *> Internet-Draft                                         December 21, 2006
  *> Intended status: Informational
  *> Expires: June 24, 2007
  *> 
  *> 
  *>                Independent Submissions to the RFC Editor
  *>                  draft-klensin-rfc-independent-05.txt
  *> 
  *> Status of this Memo
  *> 
  *>    By submitting this Internet-Draft, each author represents that any
  *>    applicable patent or other IPR claims of which he or she is aware
  *>    have been or will be disclosed, and any of which he or she becomes
  *>    aware will be disclosed, in accordance with Section 6 of BCP 79.
  *> 
  *>    Internet-Drafts are working documents of the Internet Engineering
  *>    Task Force (IETF), its areas, and its working groups.  Note that
  *>    other groups may also distribute working documents as Internet-
  *>    Drafts.
  *> 
  *>    Internet-Drafts are draft documents valid for a maximum of six months
  *>    and may be updated, replaced, or obsoleted by other documents at any
  *>    time.  It is inappropriate to use Internet-Drafts as reference
  *>    material or to cite them other than as "work in progress."
  *> 
  *>    The list of current Internet-Drafts can be accessed at
  *>    http://www.ietf.org/ietf/1id-abstracts.txt.
  *> 
  *>    The list of Internet-Draft Shadow Directories can be accessed at
  *>    http://www.ietf.org/shadow.html.
  *> 
  *>    This Internet-Draft will expire on June 24, 2007.
  *> 
  *> Copyright Notice
  *> 
  *>    Copyright (C) The Internet Society (2006).
  *> 
  *> Abstract
  *> 
  *>    There is a long-term tradition in the Internet community, predating
  *>    the IETF by many years, of use of the RFC series to publish materials
  *>    that are not rooted in the IETF standards process and its review and
  *>    approval mechanisms.  These documents, known as "independent
  *>    submissions", serve a number of important functions for the Internet
  *>    community, both inside and outside of the community of active IETF
  *>    participants.  This document discusses the independent submission
  *>    model and some reasons why it is important.  It then describes
  *> 
  *> 
  *> 
  *> Klensin                   Expires June 24, 2007                 [Page 1]
  *> 
  *> Internet-Draft           Independent Submissions           December 2006
  *> 
  *> 
  *>    editorial and processing norms that can be used for independent
  *>    submissions as the community goes forward into new relationships
  *>    between the IETF community and its primary technical publisher.
  *> 
  *> 
  *> Table of Contents
  *> 
  *>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  *>      1.1.  Terminology Note . . . . . . . . . . . . . . . . . . . . .  3
  *>      1.2.  Context and Philosophical Assumptions  . . . . . . . . . .  4
  *>    2.  The Role of Independent Submissions  . . . . . . . . . . . . .  4
  *>    3.  Document Submission  . . . . . . . . . . . . . . . . . . . . .  5
  *>    4.  The Review Process . . . . . . . . . . . . . . . . . . . . . .  6
  *>      4.1.  Posting of Draft . . . . . . . . . . . . . . . . . . . . .  6
  *>      4.2.  Request for Publication  . . . . . . . . . . . . . . . . .  6
  *>      4.3.  Initial RFC Editor Review  . . . . . . . . . . . . . . . .  6
  *>      4.4.  Document Rejection . . . . . . . . . . . . . . . . . . . .  7
  *>      4.5.  Review and Evaluation  . . . . . . . . . . . . . . . . . .  7
  *>      4.6.  Unsolicited Reviews  . . . . . . . . . . . . . . . . . . .  7
  *>      4.7.  Additional Reviews . . . . . . . . . . . . . . . . . . . .  7
  *>      4.8.  Final IESG Review  . . . . . . . . . . . . . . . . . . . .  7
  *>      4.9.  Final Decision and Notification  . . . . . . . . . . . . .  8
  *>      4.10. Final Editing and Publication  . . . . . . . . . . . . . .  9
  *>    5.  The Editorial Review Board . . . . . . . . . . . . . . . . . .  9
  *>    6.  Status and Availability of Reviews . . . . . . . . . . . . . .  9
  *>      6.1.  Documents in process or rejected . . . . . . . . . . . . . 10
  *>      6.2.  Published Documents and Documents Approved for
  *>            Publication  . . . . . . . . . . . . . . . . . . . . . . . 10
  *>    7.  Intellectual Property Rights . . . . . . . . . . . . . . . . . 10
  *>    8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
  *>    9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
  *>    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
  *>    11. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 12
  *>      11.1. Changes between version -02 and version -03  . . . . . . . 12
  *>      11.2. Changes for -04  . . . . . . . . . . . . . . . . . . . . . 13
  *>      11.3. Changes for -05  . . . . . . . . . . . . . . . . . . . . . 14
  *>    12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
  *>      12.1. Normative References . . . . . . . . . . . . . . . . . . . 14
  *>      12.2. Informative References . . . . . . . . . . . . . . . . . . 14
  *>    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
  *>    Intellectual Property and Copyright Statements . . . . . . . . . . 16
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> Klensin                   Expires June 24, 2007                 [Page 2]
  *> 
  *> Internet-Draft           Independent Submissions           December 2006
  *> 
  *> 
  *> 1.  Introduction
  *> 
  *>    There is a long-term tradition in the Internet community, predating
  *>    the IETF by many years, of use of the RFC series to publish materials
  *>    that are not rooted in the IETF standards process and its review and
  *>    approval mechanisms.  These documents, known as "independent
  *>    submissions", serve a number of important functions for the Internet
  *>    community, both inside and outside of the community of active IETF
  *>    participants.  This document discusses the independent submission
  *>    model and some reasons why it is important.  It then describes
  *>    editorial and processing norms that can be used for independent
  *>    submissions as the community goes forward into new relationships
  *>    between the IETF community and its primary technical publisher.
  *> 
  *>    To understand the perspective of this document, it is important to
  *>    remember that the RFC-Editor function predates the creation of the
  *>    IETF.  As of the time of this writing, the RFC series goes back 36
  *>    years 

     insert reference: [RFC2555]

  *>    while the IETF is celebrating its 20th anniversary.  All of the
  *>    documents that were published before the IETF was created, and for
  *>    some years thereafter, would be considered independent submissions
  *>    today.  As the IETF evolved, the IAB and then the IETF itself chose
  *>    to publish IETF documents as RFCs while fully understanding that the
  *>    RFC-Editor function was an independent publication mechanism.  Other
  *>    decisions were possible: e.g., the IETF could have decided to create
  *>    it own publication series.  It was felt that there was considerable
  *>    value in continuing to publish the IETF work in the same series as
  *>    the one used to publish the basic protocols for the Internet.
  *> 
  *> 1.1.  Terminology Note
  *> 
  *>    This document describes what have historically been referred to as
  *>    "independent submissions".  That term is distinguished from those
  *>    IETF and IAB community documents that originate from formal groups --
  *>    IAB, IRTF, IETF WGs -- and from submissions submitted to the IESG for
  *>    standards-track, informational, or experimental processing.
  *>    Documents produced by individuals, rather than IETF WGs or others
  *>    IETF-affiliated groups, but submitted for publication under Area
  *>    Director sponsorship, have been known historically as "individual

s/have been known historicall/are known/

  *>    submissions".
  *> 
  *>    For convenience and obvious historical reasons, the editor and
  *>    publisher of documents that are not processed through the IETF is
  *>    known below as the "RFC Editor".  The RFC Editor will typically be an
  *>    organization or one or more senior people and associated staff, and

s/staff/editorial staff/

  *>    the term is used collectively below.  That term is not intended to
  *>    predict the future, either in terms of who does the job or what they,
  *>    or the document series, are called.
  *> 
  *> 
  *> 
  *> 
  *> Klensin                   Expires June 24, 2007                 [Page 3]
  *> 
  *> Internet-Draft           Independent Submissions           December 2006
  *> 
  *> 
  *> 1.2.  Context and Philosophical Assumptions
  *> 
  *>    This document contains text that, if agreed to by the community, may
  *>    suggest a reexamination of and a corresponding update to RFC 3932
  *>    [RFC3932].  Those issues, and proposals for changes, are discussed in
  *>    a different document [RFC3932upd], but they are semi-independent of
  *>    the content of this document, which focuses on the review and
  *>    approval process for independent submissions.
  *> 
  *>    This document complements the discussion and guidelines in [RFC4714],
  *>    which focuses on standards track documents.  It takes a somewhat
  *>    stronger view than the discussions that lead up to that document,

s/lead to/led/

  *>    starting from the belief that independent submissions are most
  *>    valuable if they are, in fact, independent of the IETF process.  From
  *>    the perspective of the IETF, independent submissions are especially
  *>    important as checks on the IETF processes even though such checks are
  *>    not the only, or even a common, reason for them.  That role is
  *>    compromised if IETF-related entities are able to block or deprecate
  *>    such documents to a degree beyond that needed to avoid difficulties
  *>    with the standards process.
  *> 
  *> 
  *> 2.  The Role of Independent Submissions
  *> 
  *>    When the RFC series was fairly new, RFCs could be used to publish

s/could be/were/

  *>    general papers on networking as well as the types of documents we
  *>    would describes as standards today.  Those roles also developed as

s/describes/describe/

"also"?


  *>    part of the early design and development of the ARPANET, long before
  *>    anyone dreamt of the IETF and when the distinction between, e.g.,
  *>    standards and informational documents was less precisely drawn.  In
  *>    more recent years, independent submissions have become important for
  *>    multiple reasons, some of them relatively new.  They include:
  *> 
  *>    o  Discussion of Internet-related technologies that are not part of
  *>       the IETF agenda.
  *>    o  Introduction of important new ideas as a bridge publication venue
  *>       between academia and IETF engineering.
  *>    o  Informational discussions of technologies, options, or experience
  *>       with protocols.
  *>    o  Informational publication of vendor-specific protocols.
  *>    o  Critiques and discussions of alternatives to IETF standards-track
  *>       protocols.  The potential for such critiques provides an important
  *>       check on the IETF's standards processes and should be seen in that
  *>       light.
  *>    o  Documents considered by IETF Working Groups but not standardized.
  *>       While many documents of this type are published via the IESG
  *>       approval path (see RFC 3932, Section 1 [RFC3932]), the independent
  *>       submission path has traditionally been open to them.  Because of
  *> 
  *> 
  *> 
  *> Klensin                   Expires June 24, 2007                 [Page 4]
  *> 
  *> Internet-Draft           Independent Submissions           December 2006
  *> 
  *> 
  *>       their intimate connection to the IETF Standards Process and WG
  *>       activites and the consequent sensitivity to exact statements of
  *>       relationships and to timing, there is reason to believe that all
  *>       such documents should be published only at IESG request.  In any
  *>       event, these documents are published for the historical record.
  *>    o  Satirical materials.
  *>    o  Meeting notes and reports (RFC 164 [RFC0164] is the earliest, 1109
  *>       [RFC1109] probably the most important).
  *>    o  Editorials (the best example is IEN-137, not an RFC).

Please insert reference:

[IEN137] Cohen, D., "On Holy Wars and a Quest for Peace", IEN 137,
         April 1980.

  *>    o  Eulogies (RFC 2441 [RFC2441])
  *>    o  Technical contributions (e.g., RFC 1810 [RFC1810]) and,
  *>       historically,
  *>    o  RFC Editor and, at least prior to the handoff between ISI and
  *>       ICANN and the June 2000 MOU [RFC2860], IANA Policy Statements
  *>       (e.g., [RFC2223] and RFC 1591 [RFC1591]).
  *> 
  *>    It should be clear from the list above that, to be effective, the
  *>    review and approval process for independent submissions should be
  *>    largely independent of the IETF.  As a important principle that has
  *>    been applied historically, the RFC Editor should seek advice from the

s/should seek/seeks/

  *>    IESG about possible relationships and conflicts with IETF work.  The
  *>    IESG may ask that, as a courtesy, publication of particular documents
  *>    be deferred because their untimely publication could cause confusion
  *>    or other harm with proposals under consideration for standardization.
  *>    Absent compelling arguments to the contrary, the RFC Editor will
  *>    honor such requests.  Similarly, any submission that constitutes an
  *>    alternative to, or is in conflict with, an IETF Standard or proposal
  *>    for standards-track adoption must clearly indicate that relationship.
  *>    The IESG may identify such conflicts as part of its review.  If the
  *>    IESG identifies issues, it may recommend explanatory or qualifying
  *>    text for the RFC Editor to include in the document if it is
  *>    published.
  *> 
  *>    The specific procedures to be followed in review are described in
  *>    Section 4.
  *> 
  *> 
  *> 3.  Document Submission
  *> 
  *>    Independent submissions are submitted directly to the RFC Editor.
  *>    They must first be posted as Internet Drafts, so the submission is
  *>    typically simply a note requesting that the RFC Editor consider a
  *>    particular Internet Draft for publication.  The process is described
  *>    in more detail in [RFC2223] and a working draft of an update to it
  *>    [RFC2223bis].
  *> 
  *>    Any document that meets the requirements of this specification, of
  *>    [RFC2223] and its successors, and of any intellectual property or
  *> 
  *> 
  *> 
  *> Klensin                   Expires June 24, 2007                 [Page 5]
  *> 
  *> Internet-Draft           Independent Submissions           December 2006
  *> 
  *> 
  *>    other conditions that may be established from time to time, may be
  *>    submitted to the RFC Editor for consideration as an Independent
  *>    Submission.  However, the RFC Editor prefers that documents created
  *>    through IETF processes (e.g., working group output) be considered by
  *>    the IESG and submitted using this path only if a working group, or
  *>    the IESG, decline to publish it.  In the latter cases, the review
  *>    process is likely to be more efficient if the authors provide a

s/is likely to be/will be/

  *>    history of consideration and reviews of the document at the time of
  *>    submission.
  *> 
  *> 
  *> 4.  The Review Process
  *> 
  *>    While this document is consistent with the broad outline of
  *>    independent submission and review as practiced over the years, it
  *>    specifies some new arrangements in RFC Editor processing that will
  *>    improve the balance between openness and independent decisions.
  *> 

I have a little trouble with "specifies new arrangements" -- I would
prefer "clarify and documents procedures", but if you are going to say
"new arrangements", it seems to me you need to summarize what the new
arrangements are, so all parties can agree.

  *>    In general, the steps in the review process are identified in the
  *>    subsections below.  Any of them may be iterated and, at the
  *>    discretion of the RFC Editor, steps after the first may be taken out
  *>    of order.
  *> 
  *> 4.1.  Posting of Draft
  *> 
  *>    The author(s) or editor(s) of a document post it as an Internet
  *>    Draft.
  *> 
  *> 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
  *>    [e-mail].  That request should note any community
  *>    discussion or reviews of the document that have occurred before
  *>    submission.
  *> 
  *> 4.3.  Initial RFC Editor Review
  *> 
  *>    RFC Editor Staff perform an initial check on the document.  If they

s/Staff perform/staff performs/

  *>    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.
  *> 

Comment: Nice theory, but in practice some IESG members have been
less than responsive to such requests from the RFC Editor.

  *> 
  *> 
  *> 
  *> 
  *> 
  *> Klensin                   Expires June 24, 2007                 [Page 6]
  *> 
  *> Internet-Draft           Independent Submissions           December 2006
  *> 
  *> 
  *> 4.4.  Document Rejection
  *> 
  *>    If the document does not appear publishable, the RFC Editor may
  *>    reject a submitted document at any point in the process specified
  *>    here.  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.  Alternatively, the RFC Editor Staff may, at their
  *>    discretion, iterate with the author on the document to improve its
  *>    quality. 

Comment: While the above is factually correct, the community should be
aware that the RFC Editor often expends considerable effort and sometimes
3-65 go-arounds with authors to get their submissions up to publishable
quality.  Unlike IETF documents, which have received considerable
scrutiny before they are submitted to us, independent submissions
are more likely to come from a single author, often isolated from the
IETF, with revision level -00.  We just like to receive credit for
what we do.

  *>    If a document is rejected by the RFC Editor, the author may
  *>    request an additional review from the IAB, as described below, but
  *>    the IAB is not obligated to do that review, nor is the RFC Editor
  *>    obligated to publish even with a favorable IAB review.
  *> 
  *> 4.5.  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
  *>    evaluation of reviews by others.
  *> 
  *> 4.6.  Unsolicited Reviews
  *> 
  *>    Unsolicited reviews from parties independent of the author are
  *>    welcome at any time and will be handled as above.  Unsolicited
  *>    reviews will be shared with the author including the identity of the
  *>    reviewer.
  *> 

   s/author including/author, including/

The last sentence seems to belong in Section 6, or maybe it should
be repeated there.


  *> 4.7.  Additional Reviews
  *> 
  *>    If the author is unsatisfied with the review(s), the author may
  *>    request that the RFC Editor solicit additional reviews.  In
  *>    exceptional circumstances, the author may request that the IAB review
  *>    the documents.  Such requests to the IAB, and any reviews the IAB
  *>    chooses to perform, will occur according to procedures of the IAB's
  *>    choosing.  However, 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.  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.
  *> 
  *> 4.8.  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

s/will post/posts/   [explanation: TO state in queue]

  *>    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.

Comment: a balanced document would include transparency requirements on
the IESG, in this process, although that is covered elsewhere, I
guess.

  *> 
  *>    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.9.  Final Decision and Notification
  *> 
  *>    In all cases, the ultimate decision to publish or not publish, and
  *>    with what language, rests with the RFC Editor.
  *> 
  *> 
  *> 
  *> 
  *> Klensin                   Expires June 24, 2007                 [Page 8]
  *> 
  *> Internet-Draft           Independent Submissions           December 2006
  *> 
  *> 
  *>    Information about the 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.
  *> 
  *> 4.10.  Final Editing and Publication
  *> 
  *>    Once a document is approved for publication, it is handled 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.
  *> 
  *> 
  *> 
  *> 
  *> Klensin                   Expires June 24, 2007                 [Page 9]
  *> 
  *> Internet-Draft           Independent Submissions           December 2006
  *> 
  *> 
  *> 6.1.  Documents in process or rejected
  *> 
  *>    For documents in process, reviews may be made public and posted on
  *>    the RFC Editor web site at the request of the author.  The names of

I don't understand this discussion of documents in progress.
There is a bit of a time warp here.  The RFC Editor (or the author)
cannot know whether 6.1 or 6.2 applies until the end of the review
process, so reviews cannot be posted until that time, if at all.
The time warp gets worse if the author appeals to the IAB.

Question: Section 6.2 says the RFC Editor has an option of not posting
a review, but there is no such statement for 6.1; is the implication
that the RFC Editor is obliged to publish negative reviews?  Must the
reviewer(s) be identified?

  *>    reviewers associated with each review will normally accompany their
  *>    reviews, but may be withheld at the request of the reviewer.
  *> 
  *>    If the RFC Editor declines to publish a document, the document author

/s/If the RFC Editor declines to publish a document,/For rejected documents,/

  *>    may request that reviews be made public, as above, However, that
  *>    request must be timely, generally within thirty days of the author's
  *>    notification that the document would not be published.
  *> 
  *>    With or without a document author request, the RFC Editor may post
  *>    the full set of reviews associated with a document in process or
  *>    rejected for publication if they conclude that doing so would be in
  *>    the best interest of the community.  The author will be notified that
  *>    this action is about to be taken and may optionally request that the
  *>    request to publish the document be withdrawn and the reviews kept
  *>    private.  Under normal circumstances, the RFC Editor will honor that
  *>    request.
  *> 
  *> 6.2.  Published Documents and Documents Approved for Publication
  *> 
  *>    For documents that are published, either the author or any reviewer
  *>    may request that reviews be made public.  The RFC Editor may, but is
  *>    not required to, do so.  In considering whether to make review
  *>    materials public, the RFC Editor is expected to note, first, 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
  *>    and that the author generally does not have the right to publish a
  *>    refutation to an unfavorable review; 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.
  *> 
  *>    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.  At minimum,
  *>    the author of either an accepted or rejected document shall receive a
  *>    written summary of the review(s).
  *> 

The last sentence above seems important enough to appears much earlier and
not be an afterthought.

 
(I had no comments after this point).

Bob Braden


----- End Included Message -----


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