Re: Gen-ART Review of draft-ietf-forces-mib-07

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

 




--On Tuesday, 02 September, 2008 16:08 -0500 Spencer Dawkins
<spencer@xxxxxxxxxxxxxxxxx> wrote:

> To John and Steve,
> 
>>> It occurs to me that people may have been saying "could be
>>> resolved in AUTH48" when they really meant "could be
>>> resolved in an RFC Editor note".
> 
> I would not be a bit surprised if I meant that ;-)
> 
>> Personally, I don't even like RFC Editor notes for things
>> that can and should be corrected by the author.  As both an
>> author and an AD, I much preferred clean new copies.
> 
> My own AD feels the same way, for reasonable reasons.
> 
> I do note that spinning revisions also activates all the
> review team reviewers to figure out what's changed since (in
> this case) 07. It's worth noting that although the ID
> submission tool has made submitting a 08 version very cheap,
> it's not free...

And that is why I've come to prefer the following sequence of
events:

	(i) Presumably-final draft goes to Last Call and
	Reviewers.
	
	(ii) Possible new draft, with changes clearly
	identified, as the result of Last Call (and Reviewer)
	comments.
	
	(iii) IESG review, which might produce a draft note,
	historically known as an RFC Editor note, along with
	approval.  If the IESG returns the document to the
	authors or WG instead, restart at (i) with a new draft.
	
	(iv) If that note is acceptable to the authors/ editors/
	WG/ etc., generation of a document that incorporates the
	changes.  That version is, or is not, posted at the
	discretion of the RFC Editor and/or WG Chair and/or AD.

In other words, the document editor prepares a clean draft with
the RFC Editor note(s) incorporated, rather than expecting the
RFC Editor to do so.  If a draft is posted at (ii), it implies
that significant changes have occurred and may trigger the
re-review to which Spencer refers.  The IESG approval at (iii)
is considered final and the document at (iv) simply an editorial
matter of splicing the changes in.  If that latter document is
posted at all, it is with the understanding that additional
substantive comments, or even post-IESG fine-tuning, are
inherently disruptive and time-consuming and that they should
not be accepted unless they raise new, very significant,
showstopper-level issues.  Otherwise, we would never finish
anything.

     john

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]