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

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

 



Greetings All,

The RFC Editor does retrieve ALL approved IDs and compare our edited text with the originally approved ID, as posted in the internet- drafts repository.

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.

The authors submit their updated files, and we use this file as a starting point for our editorial process. We then create a diff file between the newly edited version (which includes author edits and RFC Editor edits) of the text file and the originally submitted ID. During AUTH48, we provide the .xml, .txt, and -diff.html files to the authors, ADs, and WG chairs. Each time an author requests changes during AUTH48, all of the files get updated and notifications are sent to the authors, ADs, and WG chairs. When we notice unusual changes in these files, we request that the ADs approve the changes before we publish the document. (Therefore, our bugging Jari for approval.)

Ensuring that the resulting text of the submitted XML source match identically the approved ID does not seem correct. 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.

As such, we provide our edited version of the .xml file to the authors during AUTH48, and ask them to edit the file themselves. However, it is at this stage that we often see changes that require AD approval, as opposed to upon XML submission.

The case in particular that started this tread resulted from changes that occurred during AUTH48.

Sandy


On Nov 26, 2007, at 7:03 AM, John C Klensin wrote:



--On Monday, 26 November, 2007 11:21 +0100 Eliot Lear
<lear@xxxxxxxxx> wrote:

This argues that XML files be submitted as the authoritative
source at the time of WGLC, Paul, if they are going to be
submitted at all, and the I-D manager generates the text.  I'm
fine with that, by the way.

Eliot,

I'd urge a little caution on this.   I can't speak for others,
but I tend to extensively annotate my working source extensively
with comments about the source of a change, obsolete or
alternate proposed text, proposals under discussion and what I
think about them, etc.  I generally consider that material
confidential, especially when it responds to comments received
off-list.   I typically remove material of that type before
handing the XML over to the RFC Editor but taking it out of the
working drafts prior to WGLC or even prior to IETF LC (when some
of it might be needed to review discussions of an issues and how
and why it was resolved) risks the loss of important information.

It seems to me that, regardless of whatever else we do, the RFC
Editor should generate a document from the XML and compare it to
whatever the IESG approved before going forward.   Even if we
insert other steps, that is probably a necessary precaution.  I
believe it is also sufficient, which makes it especially
attractive.

     john




_______________________________________________

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]