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

From: Jari Arkko <[email-masked]>
Date: Sun, 25 Nov 2007 22:45:01 +0200

As many of you know, when a draft is approved and sent to the RFC
Editor, authors are asked for the XML source of the draft. This makes
the subsequent editing easier, if XML2RFC has been used.

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. I know I at least keep several
versions of my source files around. If there are multiple authors they
might forget who was the last one with the submitted source, and so on.

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. Amusingly, the RFC Editor though that the changes had
been introduced intentionally by the authors, and the authors thought
that the changes were introduced by the RFC Editor. Luckily we did catch
the error eventually, because the RFC Editor kept bugging me to approve
the changes. While the changes in this case were not catastrophic, this
was one of those drafts where the precise wording had been debated at
length. It would have been unfortunate to publish something else than
what had been agreed to.

I'm telling this story in order to alert people to be careful. In
particular, please be careful in submitting your XML file that it indeed
corresponds to the draft that was approved. Also, AUTH48 review is,
perhaps contrary to expectations, useful.

Jari

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 25 Nov 2007 13:18:22 -0800

At 10:45 PM +0200 11/25/07, Jari Arkko wrote:
>I'm telling this story in order to alert people to be careful.

Another option is that the RFC Editor should be more careful. It 
really isn't that hard for the RFC Editor to run xml2rfc on the XML 
file and wdiff it against the draft that is approved by the IESG, and 
bring noticeable differences to the two parties.

--Paul Hoffman, Director
--VPN Consortium

---

From: Julian Reschke <[email-masked]>
Date: Sun, 25 Nov 2007 22:26:20 +0100

Paul Hoffman wrote:
> Another option is that the RFC Editor should be more careful. It really 
> isn't that hard for the RFC Editor to run xml2rfc on the XML file and 
> wdiff it against the draft that is approved by the IESG, and bring 
> noticeable differences to the two parties.

This sounds to me that the submission process should ask *either* for 
the TXT file or the XML file, and when the XML file was sent, use 
xml2rfc to produce the TXT file.

BR, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 25 Nov 2007 22:39:38 +0100

Hi Julian,

> xml2rfc to produce the TXT file.

Accepting only the TXT version is what the original spec says (see 
RFC 4228) for the first version of the tool.  Accepting and running the
XML file and verifying the txt file if one was supplied is part of a later
version of the tool.  After multiple suggestions indicating that it would
be valuable to make it possible to upload the XML file also in the first
version, we made that change.

In other words, yes, this is a sensible suggestion, and it's part of the
spec, but it hasn't been implemented yet.

	Henrik

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 25 Nov 2007 13:51:20 -0800

At 10:26 PM +0100 11/25/07, Julian Reschke wrote:
>>file and wdiff it against the draft that is approved by the IESG, 
>>and bring noticeable differences to the two parties.
>
>This sounds to me that the submission process should ask *either* 
>for the TXT file or the XML file, and when the XML file was sent, 
>use xml2rfc to produce the TXT file.

They still should (strongly) consider checking the validity of the 
XML by comparing it to what the IESG approved.

--Paul Hoffman, Director
--VPN Consortium

---

From: Jari Arkko <[email-masked]>
Date: Sun, 25 Nov 2007 23:58:09 +0200

Paul,

>
> They still should (strongly) consider checking the validity of the XML
> by comparing it to what the IESG approved.

Yes, and they do compare to what IESG approved. Substantial changes are
brought to the AD's approval. This is what caused us to find the problem
in this case.

(But note drafts are often approved with some remaining "Comments" from
the IESG review. It is up to the AD in charge and the authors to
determine whether those should be addressed. And that could happen by
submitting a new draft version before the approval announcement is sent,
with RFC Editor notes, in AUTH48, or perhaps even by tweaks in the XML
file. In all cases the AD should be checking that no inappropriate
changes are being done.)

Jari

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 25 Nov 2007 14:09:37 -0800

>brought to the AD's approval. This is what caused us to find the problem

I'm confused. Why should the RFC Editor accept XML with any 
substantial changes? That's inherently prone to error. They should 
start with what was approved.

>file. In all cases the AD should be checking that no inappropriate

The "tweaks in the XML file" seems like a Really Bad Idea. I have 
never seen IESG comments that would take the RFC Editor more than 
half an hour to incorporate by hand from the IESG announcement.

--Paul Hoffman, Director
--VPN Consortium

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 25 Nov 2007 23:09:55 +0100

Clarification below:

> spec, but it hasn't been implemented yet.

Since the draft submission tool is accepting XML files in addition to
TXT files, I'm referring to that procedure above.  I completely agree
that it makes sense for the RFC Editor to check that the recievied XML
files correspond to the received and approved TXT file.

	Henrik

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 25 Nov 2007 14:17:08 -0800

At Sun, 25 Nov 2007 14:09:37 -0800,
> start with what was approved.

I agree with Paul here. The TXT is what the IESG approved.
The XML is just a convenience.

-Ekr

---

From: Mark Andrews <[email-masked]>
Date: Mon, 26 Nov 2007 09:52:15 +1100

> spec, but it hasn't been implemented yet.

While discussing the submission tool, there needs to be a button
in the confirmation stage.  Just opening the page really leaves the
process open to submission race attacks.

You should be able to view prior to final acceptance/rejection.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 25 Nov 2007 23:57:56 +0100

Hi Mark,

On 2007-11-25 23:52 Mark Andrews said the following:
...
> process open to submission race attacks.

I don't see this.  Could you send more specifics off-list (with
cc: [email-masked]) ?

> You should be able to view prior to final acceptance/rejection.

More details is needed to understand this too.  It doesn't match
my understanding of the pages and views.  Please provide, as above?

	Henrik

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 Nov 2007 11:21:05 +0100

> start with what was approved.

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

---

From: John C Klensin <[email-masked]>
Date: Mon, 26 Nov 2007 10:03:41 -0500

--On Monday, 26 November, 2007 11:21 +0100 Eliot Lear
<[email-masked]> 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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 Nov 2007 06:59:02 -0800

At Mon, 26 Nov 2007 11:21:05 +0100,
Eliot Lear wrote:
At Mon, 26 Nov 2007 11:21:05 +0100,
> the I-D manager generates the text.  I'm fine with that, by the way.

Actually I think this is backwards.

The text file is the authoritative reference, as always. The XML
file, when processed with xml2rfc, must generate text which is
identical to the text file.

-Ekr

---

From: Ned Freed <[email-masked]>
Date: Mon, 26 Nov 2007 07:31:42 -0800 (PST)

> and why it was resolved) risks the loss of important information.

Another potential problem is that document generation from XML source may
involve more than just running xml2rfc. Some documents are built up from
multiple files in complex ways that cannot easily be duplicated by the I-D
manager.

Only when the document is finished does it make sense to generate a
self-contained XML source for it.

> believe it is also sufficient, which makes it especially

+1

				Ned

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 26 Nov 2007 09:57:19 -0800

One clarification,
 
A computer program should do this for the RFC Editor.
 
I don't want to see even more manual processing steps introduced into this procedure. 
 
It should be pretty easy to derive a diff from the canonical XML source minus comments. I don't think that the RFC XML should contain comments by the way, looks like a covert channel to me. All manner of bad things could occur.

________________________________

From: John C Klensin [mailto:[email-masked]]
Sent: Mon 26/11/2007 10:03 AM
To: Eliot Lear; Paul Hoffman
Cc: Working Group Chairs; Jari Arkko; IETF Discussion
Subject: Re: Lets be careful with those XML submissions to the RFC Editor

Eliot,

     john

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 26 Nov 2007 19:55:24 -0800

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:
>source file. Its an easy mistake to make.
>. . .
>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

---

From: Lars Eggert <[email-masked]>
Date: Tue, 27 Nov 2007 10:19:33 +0200

> XML by comparing it to what the IESG approved.

I agree with Paul. The IESG approves the text version of a draft, so  
the text version is definitive.

Making the XML available to the RFC Editor is for their convenience  
*only*.

The submission system should run xml2rfc on any submitted XML, compare  
the generated to the submitted text version, and yell if they aren't  
identical.

(If we want to get more complicated, the submission system could offer  
a "submit anyway" option, which should raise a flag to the RFC Editor  
that means "check XML against text version manually.")

Lars

---

From: "WIJNEN, Bert \(Bert\)" <[email-masked]>
Date: Tue, 27 Nov 2007 10:32:03 +0100

W.r.t.
> It does to many people who responded on this thread.

Let me inform you all, then when we did the experiment a few years
back, I was monitoring/steering that experiment. And I did ALWAYS
check the XML file by generating an I-D out of it, comparing it 
with the I-D we were supposed to be submitting XML for, and whenever
there was a mismatch, flags would get raised and diffs would be 
carefully checked.

I agree, once the IESG approves a doc, any changes should be handled 
very carefully. What seems editorial to one person may not seem so 
to someone else.

Bert

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 27 Nov 2007 07:32:06 -0800

At 9:46 AM -0500 11/27/07, Derek Atkins wrote:
>The problem is that it's the TXT that's approved, not the XML..
>This whole thread is about making sure that the XML received by
>the RFC Editor matches the Text that was approved by the IESG.
>Starting with what was approved necessarily means ignoring the
>XML and starting with the TXT, unless they validate that the
>XML generates the approved TXT.

...which is trivial to do. wdiff continues to be our friend.

--Paul Hoffman, Director
--VPN Consortium

---

From: Sandy Ginoza <[email-masked]>
Date: Mon, 26 Nov 2007 18:26:52 -0800

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)

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.

Sandy

---

From: Marshall Rose <[email-masked]>
Date: Mon, 26 Nov 2007 08:44:35 -0800

> and bring noticeable differences to the two parties.

agreed. at the risk of stating the obvious: the problem is identical  
to the one where the authors submit nroff source to the rfc-editor.

it's always a good idea to run the toolchain, and then diff the text  
against the I-D approved by the IESG. if there's a difference, the  
relevant ADs and authors need to get on the same page.

/mtr

---

From: Derek Atkins <[email-masked]>
Date: Tue, 27 Nov 2007 09:46:01 -0500

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Marshall Rose <[email-masked]>
Date: Mon, 26 Nov 2007 08:44:35 -0800

/mtr

---

From: Derek Atkins <[email-masked]>
Date: Tue, 27 Nov 2007 09:46:01 -0500

-derek

---

From: Jari Arkko <[email-masked]>
Date: Tue, 27 Nov 2007 18:08:58 +0200

Marshall,

> relevant ADs and authors need to get on the same page.

And all of this, incidentally, is what the RFC Editor and ADs do...

Jari

---

From: Dave Crocker <[email-masked]>
Date: Tue, 27 Nov 2007 08:57:09 -0800

> XML generates the approved TXT.

Right.

My own question is:  Is it the job of the RFC Editor to verify that what is 
published matches what the IETF approved?

I think it shouldn't be, in that quality control on IETF-approved documents 
belongs in the IETF, not the publication operator.

The RFC Editor needs a control point within the IETF that asserts that the 
submitted document is the right version.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Joe Abley <[email-masked]>
Date: Tue, 27 Nov 2007 12:26:05 -0500

On 27-Nov-2007, at 12:16, Marshall Rose wrote:

> ok, so the current process is adequate, we just need to be a little  
> more careful in following it, right?

That's how it looked to me. (I was the author who stupidly attached  
the wrong piece of XML in response to the RFC editor's request for XML  
at the start of AUTH48, for which I partly apologise, and partly take  
a bow for exposing opportunities to improve the workflow :-)

Joe

---

From: Jari Arkko <[email-masked]>
Date: Tue, 27 Nov 2007 19:34:26 +0200

Marshall,

> more careful in following it, right?

Mainly yes, but I'm sure processes could be improved, too.

The reason why I sent my initial e-mail was to warn authors. And to ask
them to check to make sure they're sending the right file. This falls
under the category of "be more careful". Similarly, chairs and ADs
should be careful about checking AUTH48 results -- clearly, accidents
can happen and people should not just assume that there was a good
reason for a change.

With regards to process improvements, there might be some ideas as well.
For instance, automated tools -- send the XML from the ID submission
tool directly to the RFC Editor, eliminating author errors and e-mail
roundtrip delays. Other ideas played around in this thread include
prohibiting any XML change. Or immediate checking after reception at the
RFC Editor side that the file is correct.  But I'd be a little bit more
cautious here. I'd like to give some room for the RFC Editor to organize
and order their work the best way they see fit, as long as all the steps
that are needed will be taken care of. And as an AD I would rather deal
with one question from the RFC Editor about the appropriateness of
changes, rather than separately for approval, RFC Editor's own process,
and AUTH48 stages.

Jari

---

From: Marshall Rose <[email-masked]>
Date: Tue, 27 Nov 2007 09:16:31 -0800

/mtr

---

From: Julian Reschke <[email-masked]>
Date: Tue, 27 Nov 2007 17:28:42 +0100

> multiple files in complex ways that cannot easily be duplicated by the I-D

That's true. But at some point of time, XML source *was* fed into 
xml2rfc, right? I would argue that *that* XML source should be 
submitted; submitting something that needs additional non-standard 
preprocessing seems a bit pointless to me.

> self-contained XML source for it.

I don't agree with that.

But anyway, if you think it doesn't make sense to generate 
self-contained XML for each I-D, why submit the non-self-contained XML 
source at all?

Confused,

Julian

---

From: Ned Freed <[email-masked]>
Date: Wed, 28 Nov 2007 13:47:02 -0800 (PST)

> xml2rfc, right?

Sure, but what about things like locally defined entity references? xml2rfc
handles these but they create an external reference that has to be there
alongside the main source.

> I would argue that *that* XML source should be

*That* XML source is still not necessarily self-contained. Indeed, one
model I've seen people use is to preprocess included materials but not
the main XML source.

> I don't agree with that.

Then you need to provide a viable alternative, because what you're suggesting
isn't compatible with how some people use the tools.

> self-contained XML for each I-D, why submit the non-self-contained XML

Obviously you don't submit XML source up until that point.

				Ned

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Nov 2007 23:18:46 +0100

> alongside the main source.

That's why I have been arguing all the time that documents like these 
(non-standalone) should not be allowed to be submitted.

> isn't compatible with how some people use the tools.

Whatever people feed into xml2rfc can be made stand-alone by running it 
once through an XML parser and reserializing; or be applying an identity 
XSLT transformation.

> Obviously you don't submit XML source up until that point.

I thought people did and that was a problem. Did I misunderstand something?

BR, Julian

---

From: Ned Freed <[email-masked]>
Date: Wed, 28 Nov 2007 14:38:53 -0800 (PST)

> (non-standalone) should not be allowed to be submitted.

WFM.

> once through an XML parser and reserializing; or be applying an identity

Sure, but my point is people probably don't want to do this all the time.

> I thought people did and that was a problem. Did I misunderstand something?

Yes, you're taking this entire line of commentary completely out of context.
This was all in response to Eliot's suggestion that XML versions of the
document should be required at the time of WGLC. John K responded to that
advising caution for various reasons and I chimed in with the additional reason
that this will force people to generate standalone intermediary versions
for submission.

				Ned

---

From: Julian Reschke <[email-masked]>
Date: Thu, 29 Nov 2007 10:16:07 +0100

> Sure, but my point is people probably don't want to do this all the time.

I've got a Makefile for that. Should I share it?

> that this will force people to generate standalone intermediary versions

I'm aware of what started the discussion.

However, when I use the submission tool today, I may not even know 
whether a particular version I submit will be a WGLC version. So I think 
whatever is the right answer for WGLC or LC is also the right answer for 
any ID version.

BR, Julian

---

From: John C Klensin <[email-masked]>
Date: Thu, 29 Nov 2007 08:41:21 -0500

--On Thursday, 29 November, 2007 10:16 +0100 Julian Reschke
<[email-masked]> wrote:

>> This was all in response to Eliot's suggestion that XML
>> versions of the document should be required at the time of
>> WGLC. John K responded to that advising caution for various
>> reasons and I chimed in with the additional  reason
>> that this will force people to generate standalone
>> intermediary versions for submission.
> 
> However, when I use the submission tool today, I may not even
> know whether a particular version I submit will be a WGLC
> version. So I think whatever is the right answer for WGLC or
> LC is also the right answer for any ID version.

In most of the WGs I've worked with in the last few years, the
editor (and usually everyone else) know because there is an
explicit discussion about which version is going to be used for
for WGLC before it is posted.   But assume my experience is
abnormal.

First, alternate cures for that problem include:

	(i) Permitting posting the XML when it becomes clear
	that a particular version is going to be the WGLC
	version, even after the text version has already been
	posted.  (Whoops, not permitted by current automated
	tools and raises all of the same issues about proving
	synchronization that started this discussion.)
	
	(ii) Simply posting a new I-D, in both text and (for the
	first time) XML versions, once the WG concludes that it
	wants to initiate a WGLC.   With I-D posting times now
	measured in minutes, rather than days, this is quite
	plausible, even if the only the date and version number
	change.  (Whoops, we still have the synchronization
	problem -- if an editor wants to smuggle something in,
	nothing in the current tools checks that a posted text
	version is identical to XML, HTML, or PDF versions posted with
	it.)

But WGLC is still the wrong time to _require_ posting XML, at
least as long as we treat the text version as authoritative for
review and approval purposes.  The right time to post the XML is
whenever the author or editor believes is the right time to post
the XML, with the understanding that posting it earlier rather
than later may be convenient for some WG members or reviewers
but that there are many reasons to delay its posting, many of
which Ned and I have 
summarized.  

If anyone, including the RFC Editor, is going to use an XML
version for anything in, or at the end of, the approval process,
they clearly have the responsibility to verify that it is a
reasonable match for the text and, if there are differences,
that those differences are acceptable.    Note that this same
issue arises when an editor submits a revised text form to the
RFC Editor or to an AD for editing/ review convenience -- it
ultimately has little to do with whether XML is involved and
both happen.

If one is looking for a guarantee that an XML version matches
the published text without verifying it oneself, that guarantee
comes only when the RFC Editor posts the XML.  Even that
reflects only textual identity because it is perfectly plausible
for the RFC Editor to process the XML into nroff (or the
formatting language of their choice) and then use the nroff to
fine-tune details of page layout.  XML generally, and xml2rfc in
particular, do not specify page format to nearly the degree that
may be appropriate for a published RFC.  To "fix" them to do so
would remove much of the attraction of generic markup.

So, at least in retrospect, the whole theme of this thread seems
to me to have been misguided.  What we have is:

	(1) When XML is submitted to the RFC Editor, it would be
	helpful to the RFC Editor if the editor supplied a note
	indicating how, if at all, it differed from the posted
	version.   With or without such warnings, the RFC Editor
	needs to verify things submitted to them in XML form to
	verify that they adequately match the text -- and that
	is true both of initial submission versions and anything
	comes back in from AUTH48 correspondence.
	Fortunately, being sensible and careful people, the RFC
	Editor is doing that already.
	
	(2) If the RFC Editor accepts changes from an author (or
	AD) that they should not be accepting, it is a problem
	that has little to do with whether those changes are
	submitted in the XML, in text, in the old "change this
	to that" form, or over the telephone.   Opinions differ
	in the community as to the extent of changes the RFC
	Editor should be able to make without asking for
	permission and the changes an AD should be able to
	approve without asking for a new Last Call, but those
	are not XML submission issues.
	
	(3) Authors, editors, and WG Chairs should figure out
	the appropriate maturity level of drafts for getting XML
	posted, with considerations that Ned and I have
	mentioned figuring into that consideration along with WG
	and Editor convenience in pasting in text, as well as
	the fact that we still do not require that documents be
	produced with XML or that XML _ever_ be produced as part
	of the editing process.
	
	(4) If the RFC Editor, or WG Chairs or ADs, want
	summaries of how the editor believes that the XML form
	of an I-D differs from the text form, it might not be a
	bad idea for them to specify the form in which they want
	that information (e.g., out of band in email versus an
	XML comment in a particular place versus a special sort
	of comment element).  I hope we can avoid getting
	sufficiently bureaucratic that we have to make such a
	thing a requirement.

None of the above requires new procedures, just the copious
application of good sense on a case-by-case basis.  If we lack
the good sense, and the good will needed to apply it, we have
far bigger problems than whether XML source matches the
authoritative text form or not.

     john