Skip to main content

IESG Procedures for Handling of Independent and IRTF Stream Submissions
draft-housley-iesg-rfc3932bis-12

Revision differences

Document history

Date Rev. By Action
2012-08-22
12 (System) post-migration administrative database adjustment to the Yes position for Jari Arkko
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Adrian Farrel
2009-11-20
12 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2009-11-20
12 (System) IANA Action state changed to No IC from In Progress
2009-11-20
12 (System) IANA Action state changed to In Progress
2009-11-20
12 Amy Vezza IESG state changed to Approved-announcement sent
2009-11-20
12 Amy Vezza IESG has approved the document
2009-11-20
12 Amy Vezza Closed "Approve" ballot
2009-11-20
12 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::External Party by Amy Vezza
2009-11-19
12 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss by Jari Arkko
2009-11-16
12 (System) New version available: draft-housley-iesg-rfc3932bis-12.txt
2009-11-12
11 (System) New version available: draft-housley-iesg-rfc3932bis-11.txt
2009-10-16
12 Jari Arkko State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko
2009-10-16
12 Jari Arkko Waiting for the discussion on the list and with the IAB to finish
2009-09-30
10 (System) New version available: draft-housley-iesg-rfc3932bis-10.txt
2009-09-18
12 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-09-18
09 (System) New version available: draft-housley-iesg-rfc3932bis-09.txt
2009-09-10
12 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2009-09-10
12 Dan Romascanu [Ballot comment]
2009-09-10
12 Dan Romascanu [Ballot discuss]
2009-09-10
12 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Yes by Magnus Westerlund
2009-09-10
12 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to Yes from No Objection by Magnus Westerlund
2009-09-09
12 Cullen Jennings [Ballot discuss]
2009-09-09
12 (System) State Changes to IESG Evaluation from IESG Evaluation - Defer by system
2009-08-28
12 (System) Removed from agenda for telechat - 2009-08-27
2009-08-27
12 Cullen Jennings State Changes to IESG Evaluation - Defer from IESG Evaluation::External Party by Cullen Jennings
2009-08-27
12 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Undefined from No Objection by Cullen Jennings
2009-08-24
12 Jari Arkko State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko
2009-08-24
12 Jari Arkko Waiting for Cullen to say something about the new situation.
2009-08-20
12 Jari Arkko Placed on agenda for telechat - 2009-08-27 by Jari Arkko
2009-08-19
12 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-08-19
08 (System) New version available: draft-housley-iesg-rfc3932bis-08.txt
2009-08-13
12 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead by Cindy Morgan
2009-08-13
12 Jari Arkko [Ballot discuss]
Holding a Discuss until -08 is posted and the IESG (including Cullen) has
had a chance to look at the document.
2009-08-13
12 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to Discuss from Yes by Jari Arkko
2009-08-13
12 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov
2009-08-12
12 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings
2009-08-05
12 Jari Arkko
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 …
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.
2009-08-05
12 Jari Arkko Placed on agenda for telechat - 2009-08-13 by Jari Arkko
2009-06-29
12 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-06-25
12 Michelle Cotton IANA Last Call comments:

We understand this document to have no IANA actions.
2009-06-03
12 Jari Arkko Reminder sent to Cullen and others in the IESG to participate the
discussion, but no luck so far.
2009-06-03
12 Jari Arkko New Last Call was initiated, and there is some amount of discussion, mostly
from the usual people involved in this topic.
2009-06-03
12 Jari Arkko Heads-up sent to the IAB about this new Last Call.
2009-06-01
12 Amy Vezza Last call sent
2009-06-01
12 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2009-06-01
12 Jari Arkko
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 …
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.
2009-06-01
12 Jari Arkko State Changes to Last Call Requested from IESG Evaluation::AD Followup by Jari Arkko
2009-06-01
12 Jari Arkko Last Call was requested by Jari Arkko
2009-05-29
12 Jari Arkko [Note]: 'There is no document shepherd' added by Jari Arkko
2009-05-13
12 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss by Adrian Farrel
2009-05-13
12 Adrian Farrel
[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 …
[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"
2009-05-12
07 (System) New version available: draft-housley-iesg-rfc3932bis-07.txt
2009-05-07
12 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2009-05-05
12 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2009-05-05
12 Jari Arkko Placed on agenda for telechat - 2009-05-07 by Jari Arkko
2009-05-03
12 Cullen Jennings
[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 …
[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.
2009-04-23
12 Adrian Farrel
[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 …
[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"
2009-04-23
12 Adrian Farrel
[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 …
[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"
2009-04-23
12 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded by Adrian Farrel
2009-04-23
12 Adrian Farrel
[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 …
[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"
2009-04-23
12 Jari Arkko State Changes to IESG Evaluation::AD Followup from Approved-announcement to be sent by Jari Arkko
2009-04-23
12 Jari Arkko Oops, not yet. Cullen hasn't cleared, and we are missing votes.
2009-04-23
12 Jari Arkko State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Jari Arkko
2009-04-23
12 Jari Arkko State Changes to IESG Evaluation::AD Followup from IESG Evaluation::External Party by Jari Arkko
2009-04-23
12 Jari Arkko looking at the latest rev and discussing with Olaf
2009-01-20
12 Jari Arkko State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko
2009-01-20
12 Jari Arkko Waiting on final word from IAB on the h&b resolution
2009-01-20
12 Jari Arkko Note field has been cleared by Jari Arkko
2009-01-08
12 Cindy Morgan State Changes to IESG Evaluation::AD Followup from IESG Evaluation::External Party by Cindy Morgan
2009-01-07
12 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2008-12-19
12 Jari Arkko Placed on agenda for telechat - 2009-01-08 by Jari Arkko
2008-12-19
12 Jari Arkko State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko
2008-12-19
12 Jari Arkko Waiting on rfc-interest discussion results
2008-12-04
12 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2008-12-04
12 Dan Romascanu
[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 …
[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.
2008-12-04
12 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu
2008-12-04
12 David Ward [Ballot Position Update] New position, No Objection, has been recorded by David Ward
2008-12-04
12 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2008-12-04
12 Ross Callon [Ballot comment]
I agree with the DISCUSS comments by Cullen and Dan, but will let them hold the DISCUSS votes.
2008-12-04
12 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2008-12-04
12 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2008-12-04
12 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2008-12-04
12 Dan Romascanu
[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 …
[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.
2008-12-04
12 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu
2008-12-04
12 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2008-12-03
12 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2008-12-02
12 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2008-12-02
12 Russ Housley [Ballot Position Update] New position, Recuse, has been recorded by Russ Housley
2008-12-02
12 Cullen Jennings
[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 …
[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.
2008-12-02
12 Cullen Jennings [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings
2008-12-02
12 Cullen Jennings [Ballot comment]
2008-12-02
12 Cullen Jennings
[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 …
[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?
2008-12-01
12 Cullen Jennings
[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 …
[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.
2008-12-01
12 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2008-11-28
12 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2008-11-28
12 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2008-11-28
12 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2008-11-25
12 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Sam Weiler.
2008-11-25
12 Jari Arkko State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Jari Arkko
2008-11-19
06 (System) New version available: draft-housley-iesg-rfc3932bis-06.txt
2008-11-18
12 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-11-04
12 Jari Arkko Placed on agenda for telechat - 2008-12-04 by Jari Arkko
2008-10-27
05 (System) New version available: draft-housley-iesg-rfc3932bis-05.txt
2008-10-23
12 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sam Weiler
2008-10-23
12 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sam Weiler
2008-10-21
12 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-10-21
12 Jari Arkko Last Call was requested by Jari Arkko
2008-10-21
12 Jari Arkko State Changes to Last Call Requested from AD Evaluation::External Party by Jari Arkko
2008-10-07
04 (System) New version available: draft-housley-iesg-rfc3932bis-04.txt
2008-10-02
03 (System) New version available: draft-housley-iesg-rfc3932bis-03.txt
2008-09-30
12 Amanda Baber IANA Evaluation comments:

We understand this document to have NO IANA Actions.
2008-09-25
12 Jari Arkko State Changes to AD Evaluation::External Party from AD Evaluation by Jari Arkko
2008-09-25
12 Jari Arkko Waiting for a few selected reviewers to state their opinion.
2008-09-25
12 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2008-09-25
12 Jari Arkko Ballot has been issued by Jari Arkko
2008-09-25
12 Jari Arkko Created "Approve" ballot
2008-09-25
12 (System) Ballot writeup text was added
2008-09-25
12 (System) Last call text was added
2008-09-25
12 (System) Ballot approval text was added
2008-09-25
12 Jari Arkko [Note]: 'Diff: http://www.arkko.com/ietf/iesg/rfc3932bisdiff.html' added by Jari Arkko
2008-09-25
12 Jari Arkko State Changes to AD Evaluation from Publication Requested by Jari Arkko
2008-09-22
12 Russ Housley
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 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.
2008-09-22
12 Russ Housley State Change Notice email list have been change to housley@vigilsec.com, harald@alvestrand.no from housley@vigilsec.com, harald@alvestrand.no, draft-housley-iesg-rfc3932bis@tools.ietf.org
2008-09-22
12 Jari Arkko Russ asked me to sponsor this, as he cannot do it as an author.
2008-09-22
12 Jari Arkko Draft Added by Jari Arkko in state Publication Requested
2008-09-09
02 (System) New version available: draft-housley-iesg-rfc3932bis-02.txt
2008-08-21
01 (System) New version available: draft-housley-iesg-rfc3932bis-01.txt
2008-07-31
00 (System) New version available: draft-housley-iesg-rfc3932bis-00.txt