Re: RFC Editor and IESG DNP requests

[Aaron Falk <falk@isi.edu>]

Ted Hardie wrote:
> Aaron,
> 	I think I understand this well enough, but to clarify two things:
> 
> 1) The author is told they may re-submit after six months, and it is up
> to the author to decide to re-submit.  That is, this is not in any way
> automatic or a default of the process, but requires the author
> to take the initiative to do so.  If and when they resubmit, the
> IESG can ask for a second (and last) six months delay.  This delay
> timer starts on the receipt of the resubmission (which means that
> the total delay may be over six + six months, if the author chooses
> to delay resubmission).

This is basically correct.  Except that my thinking is that the delay
timer would start from the date of the DNP.

> 
> 2) The IESG retains the right to add a note describing its view
> of the document.  This note may make references to specific documents
> in process in working groups; the RFC Editor intends to treat all
> such references as informative, so that publication may proceed
> without waiting on the documents to complete.
> 

Correct.

> 	If that is a correct understanding, I am willing to go along,
> but I don't think it is the best approach.  The IESG has
> historically been able to refer work that came in via the RFC editor
> to a working group writing specifications in that area.  This
> mechanism essentially eliminates that ability.

I disagree.  This is a procedure to handle the "DNP until the working
group is finished" case.  If an individual submission comes in which
belongs in a working group, the IESG recommendation can be that the
author should take the document to the working group.  After that has
occured and the author can come back to the RFC Editor with an
individual submission and the IESG reccomdation could be "DNP,
resubmit after working group output or six months have passed
whichever is sooner."  We don't want to establish a process where
authors can completely ignore related working groups and get RFCs
published.  Or publish duplicate work.  


>  If, for example, the SLC working group is working on IP over
> stretched leather cord and a document comes in describing IP over
> suede, the IESG should be able to say: "Hi, do this work over in the
> SLC working group, so that we have a standard that works over smooth
> and napped leather."  If the SLC working group says "this work is
> subsumed by another approach in progress", that strikes me as the
> right thing _for the working group_ to do.  Under this process, the
> RFC editor could get that document (possibly again), start these
> timers, and the IP over suede document would eventually be published
> as distinct from the "IP over napped and un-napped leather"
> documents.

Yes.  I think we are in agreement.  

>
> 	I argued at the retreat and I continue to believe that the
> right idea is to have a different archival series that documents
> alternate solutions, rejected ideas, and the output of the loyal
> opposition.  I would personally value the work of the independent
> RFC editor in editing such a series.

So, I think you are asking to break the RFCs into an IESG-approved
series and everything else.  This would be a major change to the
archive and needs discussion.


>  I believe that at the moment, though, we are using the same series
> for too many different things.  To make a parallel to physical
> manufacturing, we are currently using the same output as an escape
> valve and a production line.  That worked in the past only because
> folks carefully read the labels on the output; we're pretty
> convinced now that they don't.

Is there any anecdotal evidence to support this?

> Again, if there is consensus that the timer + notes approach is the
> best way to go forward, I will go along.  Thanks for listening to my
> alternate solution, rejected idea, and comment from the loyal
> opposition, best regards, Ted Hardie

Thanks for your thoughts, Ted.  Always welcome.

--aaron


> 
> 
> On Tuesday, May 6, 2003, at 01:47 PM, Aaron Falk wrote:
> 
> >ADs-
> >
> >I had a chance to chat with the rest of the RFC Editor crew about the
> >issue of document authors taking drafts which were rejected by a
> >working group and sending them to us as individual submissions.
> >
> >We understand that the feeling in the IESG is that, in some cases,
> >this can be damaging to the working group process by removing the
> >social engineering tool of forcing wg participants to achieve
> >consensus in order to get a solution published.  We also understand
> >that there is a perception in the IESG that publishing individual
> >solutions before working groups complete can be damaging to the
> >Internet by confusing the marketplace (although we would really like
> >some evidence where this has occurred).
> >
> >It was clear to me at the retreat that the IESG recognizes the value
> >of an independent RFC Editor and an archive of alternate, rejected,
> >and known bad solutions and would like to see these documents
> >published eventually.
> >
> >So, with all that in mind, I want to clarify the RFC Editor's position
> >on the issue at hand.  The IESG may request that publication of an
> >individual submission may be delayed by six months by sending RFC
> >Editor a "Do Not Publish" (DNP) note containing description of the
> >risks posed by the document.  In other words, we would like to
> >understand the specifics of the request.
> >
> >The author will receive a note including the IESG DNP message and an
> >explanation that the draft may be resubmitted in six months.  We feel
> >that a timed delay is important since some working groups do not
> >complete their work.  When the draft is re-submitted, the IESG may
> >request one additional six month delay if there is sufficient reason
> >to believe the working group will deliver it's output in that time.
> >
> >Just to be clear: the RFC Editor *will* honor an IESG DNP request.  We
> >would like to understand the specifics and hope that these are rare
> >occurrences.  I'm happy to discuss this further if you have questions.
> >
> >--aaron (for the RFC Editor)
> >