At 6:26 PM -0800 11/26/07, Sandy Ginoza wrote:
Often times, authors send us the XML file, and let us know that they
have updated the file to reflect the requested RFC Editor notes,
that they have updated the authors addresses section, or that they
did a bit of editorial clean-up because of some last call comments
or because they received comments from x, y, & z. The RFC Editor
does not usually have a problem accepting these types of changes.
That list mixes up many types of changes that an author might make.
From the other responses on this thread, it might be good to be a bit
more conservative in what you accept after the IESG has approved an
Internet Draft.
It seems risky for the RFC Editor to accept the author's view of the
requested RFC Editor notes instead of the RFC Editor acting on those
notes directly. It certainly seems risky to let authors do "a bit of
editorial clean-up because of some last call comments or because they
received comments from x, y, & z" after the IESG has reviewed the
document, at least without asking the IESG if that clean-up changes
the technical meaning of parts of the document that the IESG
discussed.
Ensuring that the resulting text of the submitted XML source match
identically the approved ID does not seem correct.
It does to many people who responded on this thread.
I thought that part of the reason for the RFC Editor to move toward
the use of XML2RFC was because (among others, but those relevant
here)
1) it would be easier and more efficient for authors, and
2) the authors would like to have the ability to alter the text
during AUTH48 themselves, instead of sending changes in the RFC
Editor requested format.
The first is certainly true; the second is questionable. There is
nothing preventing authors from asking the RFC Editor to make changes
from the IESG-approved Internet Draft during the editing process,
preceding the (still inappropriately named) AUTH48 review. Those
edits can be vetted by the RFC Editor for appropriateness. This also
reduces the likelihood that some edits desired by authors will be
reversed during the normal copyedit pass.
The case in particular that started this tread resulted from changes
that occurred during AUTH48.
While that's good to hear, it contradicts the first message in this thread:
At 10:45 PM +0200 11/25/07, Jari Arkko wrote:
Recently, one of the drafts that I am responsible for had an interesting
problem with this. The authors mistakenly submitted wrong version of the
source file. Its an easy mistake to make.
. . .
What made this particular incident nasty was that the wrong file was
merely a wrong candidate for the final submission, not an earlier draft
version with a different version number. So things went forward all the
way to AUTH48.
Regardless, it seems like a good policy for the RFC Editor to start
with XML that matches what the IESG approved and start editing from
there, and to keep copies of the state at various stages of editing
intact, at least until the RFC is issued.
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf