IESG Procedures for Handling of Independent and IRTF Stream Submissions
RFC 5742

Received changes through RFC Editor sync (changed abstract to 'This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the Independent Submission and IRTF streams.

This document updates procedures described in RFC 2026 and RFC 3710. This memo documents an Internet Best Current Practice.')

I am putting this back to the agenda so that we can discuss what to do. The Last Call passed, and I need to make a judgment call on what the results were. This is forthcoming.

This draft needs a second last call, as the IESG had no consensus to
approve the draft in its previous version. Some draft changes and a new
discussion in the community is needed.

[Ballot discuss]
Discuss resolved in -07 and through emails.

Updated to remove one of the four issues.

I support the content of this document and would have voted "Yes" except for these relatively minor issues. I think they are basically editorial, but are necessary to resolve for a process document that should not be ambiguous.

A. Section 1
  These RFCs, and any
  other IETF-generated Informational or Experimental documents, are
  reviewed by appropriate IETF bodies and published as part of the IETF
  Stream.
This text must either define "appropriate" or reference it (internal to
this document, or as defined in another document). The reader cannot be
left not knowing what is appropriate.

B. Section 1
  Therefore, the IETF disclaims, for any of the non-IETF
  Stream documents, any knowledge of the fitness of those RFCs for any
  purpose.

  This memo is only concerned with the IESG processing of the last two
  categories, which comprise the Independent Submission Stream and the
  IRTF Document Stream, respectively [N1].

The first paragraph makes a strong statement about IAB stream documents,
but the second paragraph says that the document is limited to IRTF and
independent streams. This is a contradiction.

You could probably get away with "The remainder of this memo" in the
second paragraph, although given the title and Abstract it the first
paragraph should not make a definitive statement about the IAB stream.

If you can find a referenece for the assertion then that will be fine.
Otherwise suggest changing to...

  Therefore, the IETF disclaims, for any of the IRTF and Independent
  Submission Stream documents, any knowledge of the fitness of those
  RFCs for any purpose.

[This issues is removed. I misread the text
#C. Section 1
#  This document describes only the review process done by the IESG when
#  the RFC Editor or the IRTF requests that review.
#No, it describes more than that. It also describes the handling of
#documents on the Independent Stream.
#How about:
#  For IRTF Document Stream documents, this memo describes only the
#  review process done by the IESG when the RFC Editor or the IRTF
#  requests that review.]

D. Section 3
  changed or extended in an unanticipated way
"Unanticipated" by whom? Clearly the authors of the document in question
anticipated it.
You will have to be more specific. Possibly you mean "in a way that was
not anticipated by the WG that produced the original protocol
specification"

[Ballot discuss]
Now the headers and boiler plates is more or less finalized, i think we are ready to actually review this document. The important points is the headers and boiler plate did not end up actually adding significant text about the limitations of non IETF reviewed documents.

We need to understand that from the external worlds point of view, all the RFC streams we are talking about are viewed as coming from the IETF. The wikipedia definition of an RFC starts with "In computer network engineering, a Request for Comments (RFC) is a memorandum published by the Internet Engineering Task Force (IETF) describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems." Vendors just quote a RFC number and say they support it, they never even get into if it IRTF or IETF. One of the biggest consumers of our specifications, 3GPP and 3GPP2 don't even bother to care if the document if standards track on informational. If we expect people to continue viewing IETF standards as high quality, we need to clearly say in the text in the document what sort of  review has not happened and possible quality implications.

With that soap box opening complete, I think we should continue to have default IESG notes in some documents. This proposal is going to take us straight back to the pre 2004 situation where a separate IESG note had to be constructed for every document that came along.  I don't know about you but I find myself with plenty of better uses of my time. The default mandatory notes were quick and efficient and avoided the problem of the IESG having to work on what the note was for every document. Note I am fine with the IESG deciding to change a note as appropriate or even decide to have no note, but I think having some defaults ones to select from was very efficient.


On to specific items:

Section 1.1 claims
  "This label eliminates the need for a mandatory IESG note on all
  Independent Submission and IRTF Stream documents."
This is nuts, I have no idea how a small label that no one reads will do this.

In section 3, you have
  then the RFC Editor is responsible for
  judging the technical merits for that submission, including
  considerations of possible harm to the Internet.

I don't think this is necessarily one of the goals of the RFC Editor. The recent plan to put this out for bid does require that the RFC Editor be able to do this. Thought the current RFC Editor might be able to do this, I don't believe this is a requirement for future RFC Editors. If we did believe they could do this, they could also make sure it did not violate any IETF procedures and the IESG would not need to check that either.


In section 4, the draft has
      with a clear disclaimer note saying that "the IETF
      technology for this function is X".
Again, this just points to the need for IESG notes.


The document is unclear on if the IESG can add a note at all or when it might do that or how it would decide. That lack of clarity needs to be fixed regardless of if we are adding notes or not.

We need to talk about if there is IETF consensus for this document.

[Ballot discuss]
Updated to remove one of the four issues.

I support the content of this document and would have voted "Yes" except for these relatively minor issues. I think they are basically editorial, but are necessary to resolve for a process document that should not be ambiguous.

A. Section 1
  These RFCs, and any
  other IETF-generated Informational or Experimental documents, are
  reviewed by appropriate IETF bodies and published as part of the IETF
  Stream.
This text must either define "appropriate" or reference it (internal to
this document, or as defined in another document). The reader cannot be
left not knowing what is appropriate.

B. Section 1
  Therefore, the IETF disclaims, for any of the non-IETF
  Stream documents, any knowledge of the fitness of those RFCs for any
  purpose.

  This memo is only concerned with the IESG processing of the last two
  categories, which comprise the Independent Submission Stream and the
  IRTF Document Stream, respectively [N1].

The first paragraph makes a strong statement about IAB stream documents,
but the second paragraph says that the document is limited to IRTF and
independent streams. This is a contradiction.

You could probably get away with "The remainder of this memo" in the
second paragraph, although given the title and Abstract it the first
paragraph should not make a definitive statement about the IAB stream.

If you can find a referenece for the assertion then that will be fine.
Otherwise suggest changing to...

  Therefore, the IETF disclaims, for any of the IRTF and Independent
  Submission Stream documents, any knowledge of the fitness of those
  RFCs for any purpose.

[This issues is removed. I misread the text
#C. Section 1
#  This document describes only the review process done by the IESG when
#  the RFC Editor or the IRTF requests that review.
#No, it describes more than that. It also describes the handling of
#documents on the Independent Stream.
#How about:
#  For IRTF Document Stream documents, this memo describes only the
#  review process done by the IESG when the RFC Editor or the IRTF
#  requests that review.]

D. Section 3
  changed or extended in an unanticipated way
"Unanticipated" by whom? Clearly the authors of the document in question
anticipated it.
You will have to be more specific. Possibly you mean "in a way that was
not anticipated by the WG that produced the original protocol
specification"

[Ballot discuss]
I support the content of this document and would have voted "Yes" except for these relatively minor issues. I think they are basically editorial, but are necessary to resolve for a process document that should not be ambiguous.

A. Section 1
  These RFCs, and any
  other IETF-generated Informational or Experimental documents, are
  reviewed by appropriate IETF bodies and published as part of the IETF
  Stream.
This text must either define "appropriate" or reference it (internal to
this document, or as defined in another document). The reader cannot be
left not knowing what is appropriate.

B. Section 1
  Therefore, the IETF disclaims, for any of the non-IETF
  Stream documents, any knowledge of the fitness of those RFCs for any
  purpose.

  This memo is only concerned with the IESG processing of the last two
  categories, which comprise the Independent Submission Stream and the
  IRTF Document Stream, respectively [N1].

The first paragraph makes a strong statement about IAB stream documents,
but the second paragraph says that the document is limited to IRTF and
independent streams.

You could probably get away with "The remainder of this memo" in the
second paragraph, although given the title and Abstract it the first
paragraph should not make a definitive statement about the IAB stream.

If you can find a referenece for the assertion then that will be fine.
Otherwise suggest changing to...

  Therefore, the IETF disclaims, for any of the IRTF and Independent
  Submission Stream documents, any knowledge of the fitness of those
  RFCs for any purpose.

C. Section 1
  This document describes only the review process done by the IESG when
  the RFC Editor or the IRTF requests that review.
No, it describes more than that. It also describes the handling of
documents on the Independent Stream.
How about:
  For IRTF Document Stream documents, this memo describes only the
  review process done by the IESG when the RFC Editor or the IRTF
  requests that review.

D. Section 3
  changed or extended in an unanticipated way
"Unanticipated" by whom? Clearly the authors of the document in question
anticipated it.
You will have to be more specific. Possibly you mean "in a way that was
not anticipated by the WG that produced the original protocol
specification"

[Ballot comment]
A bunch of comments. The RFC Editor might catch some of these, but not all. Check carefully because some of them have a subtle effect on the meaning.

1. Abstract
The Abstract contains an unnecessary note to the RFC Editor
  {{{ RFC Editor: Please change "RFC XXXX" to the number assigned to
  this document prior to publication. }}}
There is no reference to "RFC XXXX" in the document.

2. Section 1
  Documents published in streams other than the IETF Stream may not
s/may/might/

3. Section 1
  Once these procedures are fully adopted, the IESG will continue to be
  responsible only for checking for conflicts between the work of the
s/will continue to be responsible only/will be responsible only/

4. Section 2
s/IRTF stream/IRTF Stream/

5. Section 3
s/publications as RFC/publication as RFCs/

6. Section 3
s/types of conclusions/types of conclusion/

7. Section 3
s/for /for WG /

8. General
Would be nice to consistent about "Independent Stream" or "Independent
Submission Stream"

[Ballot comment]
The current combination of rfc3932bis and 'IAB Headers and Boilerplate' leaves out an important message that was included in the IESG Note.

Let us take the text for IRTF stream documents. The text in draft-iab-streams-headers-boilerplates-04.txt

>    IRTF Stream:  "This document is a product of the Internet Research
      Task Force (IRTF).  The IRTF publishes the results of Internet-
      related research and development activities.  These results might
      not be suitable for deployment.  This document has been approved
      for publication by the IRSG.  It is not a product of the IETF and
      is therefore not a candidate for any level of Internet Standard;
      see section Section 2 of RFCXXXX."

is much weaker IMO than the text in the RFC 3932 IESG note:

>  This RFC is not a candidate for any level of
      Internet Standard.  The IETF disclaims any knowledge of the
      fitness of this RFC for any purpose and in particular notes that
      the decision to publish is not based on IETF review for such
      things as security, congestion control, or inappropriate
      interaction with deployed protocols. 

Missing to say 'is not based on IETF review' is essential IMO.

I sent a note to the IAB, as the fix should be in the IAB document.

[Ballot discuss]
I have similar concerns as expressed by Cullen. At this point in time I am not ready to approve this document without seeing what is the specific text that the documents that define the other streams include and make mandatory in order to make clear that the RFC is not the product of the IETF and did not undergo an IETF review process.

For example the text included at this point in time in draft-irtf-rfcs is requires an IRTF stream document to include some text

o  It must also be very clear throughout the document that it is not
      an IETF product and is not a standard.

This is much weaker and less clear than the current IESG note and makes no requirement of a boilerplate type of text that would make the statement clear and place it at a standard and visible place.

I know that we discontinued bringing documents as a package at ballot, but in this case i think we cannot approve this document before we see exactly the impact on the documents defining the process for the other RFC streams.

[Ballot discuss]
I think it is important that the non IETF stream documents are not in way confusable with an IETF standard by people unfamiliar with I* process. This document asserts that the stream-header draft will do that but if that text is still changing, I sort of like to see that text at same time as approving this. Is that text locked down at this point? I expect to clear this discuss with no changes to this document but I would like to make sure we don't have an issue here before proceeding with removing IESG notes on non IETF stream documents.

[Ballot comment]
I think it is important that the non IETF stream documents are not in way confusable with an IETF standard by people unfamiliar with I* process. This document asserts that the stream-header draft will do that but if that text is still changing, I sort of like to see that text at same time as approving this. Is that text locked down at this point?

[Ballot comment]
I have two concerns around this document, both of which will probably result in zero text changes to the document.

1) I think it is critical that the non IETF stream documents are not in way confusable with an IETF standard by people unfamiliar with I* process. This document asserts that the stream-header draft will do that but if that text is still changing, I sort of like to see that text at same time as approving this. Is that text locked down at this point?


2) The statement that "the IESG will offer the author the opportunity" is going to cause endless confusion in the future. How is that different that any other draft today. Do we offer this to anyone or is this somehow different. The fact we explicitly mentioned it will be read in the future as being somehow relevant. I'm not sure how to make the intent clearer here but this seems like words that will haunt some future IESG.

Document Shepherd Write-Up for draft-housley-iesg-rfc3932bis-02.txt

(1.a)  Who is the Document Shepherd for this document?  Has the
  Document Shepherd personally reviewed this version of the document
  and, in particular, does he or she believe this version is ready
  for forwarding to the IESG for publication?

  Russ Housley is the Document Shepherd and co-author.


(1.b)  Has the document had adequate review both from key members of
  the interested community and others?  Does the Document Shepherd
  have any concerns about the depth or breadth of the reviews that
  have been performed?

  The document is intended for publication as a BCP.  It has been
  reviewed by several community members, and it has been discussed
  with the IAB and the IRTF Chair.  This document needs to be
  published at the same time as two other companion documents:

      - draft-irtf-rfcs
      - draft-iab-streams-headers-boilerplates


(1.c)  Does the Document Shepherd have concerns that the document
  needs more review from a particular or broader perspective, e.g.,
  security, operational complexity, someone familiar with AAA,
  internationalization or XML?

  No concerns.


(1.d)  Does the Document Shepherd have any specific concerns or
  issues with this document that the Responsible Area Director
  and/or the IESG should be aware of?  For example, perhaps he or
  she is uncomfortable with certain parts of the document, or has
  concerns whether there really is a need for it.  In any event, if
  the interested community has discussed those issues and has
  indicated that it still wishes to advance the document, detail
  those concerns here.

  No concerns.


(1.e)  How solid is the consensus of the interested community behind
  this document?  Does it represent the strong concurrence of a few
  individuals, with others being silent, or does the interested
  community as a whole understand and agree with it?

  No concerns.  I believe that the removal of the IESG Note that
  is required by RFC 3932 is most welcome by anyone that writes
  documents for the IRTF or the Individual Submission Streams.


(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarise the areas of conflict in
  separate email messages to the Responsible Area Director.  (It
  should be in a separate email because this questionnaire is
  entered into the ID Tracker.)

  No.


(1.g)  Has the Document Shepherd personally verified that the
  document satisfies all ID nits?  (See
  http://www.ietf.org/ID-Checklist.html and
  http://tools.ietf.org/tools/idnits/).  Boilerplate checks are not
  enough; this check needs to be thorough.  Has the document met all
  formal review criteria it needs to, such as the MIB Doctor, media
  type and URI type reviews?

  Yes.  No problems with ID-Checklist were noticed.  ID-Nits did
  flag an error.  ID-Nits reports:
 
    The document seems to lack an RFC 3979 Section 5, para 1 IPR
    Disclosure Acknowledgement -- however, there's a paragraph with
    a matching beginning. Boilerplate error?

  There is no need for any formal review from the MIB Doctors or
  any other such group.


(1.h)  Has the document split its references into normative and
  informative?  Are there normative references to documents that are
  not ready for advancement or are otherwise in an unclear state?
  If such normative references exist, what is the strategy for their
  completion?  Are there normative references that are downward
  references, as described in [RFC3967]?  If so, list these downward
  references to support the Area Director in the Last Call procedure
  for them [RFC3967].

  References are split.  As said above, this document needs to be
  published at the same time as two other companion documents:

      - draft-irtf-rfcs
      - draft-iab-streams-headers-boilerplates


(1.i)  Has the Document Shepherd verified that the document IANA
  consideration section exists and is consistent with the body of
  the document?  If the document specifies protocol extensions, are
  reservations requested in appropriate IANA registries?  Are the
  IANA registries clearly identified?  If the document creates a new
  registry, does it define the proposed initial contents of the
  registry and an allocation procedure for future registrations?
  Does it suggested a reasonable name for the new registry?  See
  [RFC5226].  If the document describes an Expert Review process has
  the Shepherd conferred with the Responsible Area Director so that
  the IESG can appoint the needed Expert during the IESG Evaluation?

  No IANA actions are required.


(1.j)  Has the Document Shepherd verified that sections of the
  document that are written in a formal language, such as XML code,
  BNF rules, MIB definitions, etc., validate correctly in an
  automated checker?

  No formal language is used.


(1.k)  The IESG approval announcement includes a Document
  Announcement Write-Up.  Please provide such a Document
  Announcement Writeup?  Recent examples can be found in the
  "Action" announcements for approved documents.  The approval
  announcement contains the following sections:

  Technical Summary

    This document describes the procedures used by the IESG for handling
    documents submitted for RFC publication on the Independent and IRTF
    streams.

    This document updates procedures described in RFC 2026 and RFC 3710.

  Working Group Summary

    This document is not the product of any IETF working group.

  Document Quality

    This document, in conjunction with its two companion documents,
    clarifies the IESG process for handling documents submitted for
    RFC publication on the Independent and IRTF streams.  The removal
    of the IESG Note that is required by RFC 3932 is most welcome by
    authors of documents in these two RFC streams.