[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC Editor and IESG DNP requests

At 10:00 AM -0700 5/7/03, Aaron Falk wrote:
<snip>

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

Okay.


 such references as informative, so that publication may proceed
 >

 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

 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.

I think I see the distinction here, and you're right.  There is still
a step that the IESG can take to point them at the right working group.
I was concerned that the working group's decision on the merits
of an idea can still be run around, but I agree that having that step
and the IESG notes handles the majority of these issues.





  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 think we actually already did that, but that the break hasn't been effective.
Or, rather, it isn't effective any more.

We have RFCs which are Standards track and a variety of other
RFCs (Informational and Experimental being the salient ones here).
While people were reading the labelling carefully, that was enough.
I think there is ample evidence that people have blurred this
distinction, both inside the IETF and outside.  Splitting the
series in a more effective way looks to me like a necessary step.

Note that it isn't always end-runs at stake.  There are cases I see where the
actions of a dominant individual causes folks to cease pushing good ideas
onto the standards track and to accept that they go forward as individual
submissions for Informational, just because they don't see a real difference
in their particular world's view of the series.  That blurs the line as well.









  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?



There may not be evidence that people carefully read the
labels in the past (smiley).  There is evidence in RFPs and
marketing dross not only that there are people who don't
understand the distinction, but that there are people who
are intentionally blurring the distinction.





 > 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



And thank you for your considered reply.

				regards,
					Ted







 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)
 >