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

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(_at_)cisco(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf