Re: Lets be careful with those XML submissions to the RFC Editor

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

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

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