Re: Lets be careful with those XML submissions to the RFC Editor
Ned Freed wrote: 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. 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? 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? Obviously you don't submit XML source up until that point. 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
--On Thursday, 29 November, 2007 10:16 +0100 Julian Reschke [EMAIL PROTECTED] wrote: 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. 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. 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
Re: Lets be careful with those XML submissions to the RFC Editor
Ned Freed wrote: ... 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. ... That's true. But at some point of time, XML source *was* fed into 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 submitted; submitting something that needs additional non-standard preprocessing seems a bit pointless to me. *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. Only when the document is finished does it make sense to generate a self-contained XML source for it. 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. 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? Obviously you don't submit XML source up until that point. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
Ned Freed wrote: That's true. But at some point of time, XML source *was* fed into 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. That's why I have been arguing all the time that documents like these (non-standalone) should not be allowed to be submitted. I would argue that *that* XML source should be submitted; submitting something that needs additional non-standard preprocessing seems a bit pointless to me. *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. Only when the document is finished does it make sense to generate a self-contained XML source for it. 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. 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. 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? 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
Ned Freed wrote: That's true. But at some point of time, XML source *was* fed into 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. That's why I have been arguing all the time that documents like these (non-standalone) should not be allowed to be submitted. WFM. I would argue that *that* XML source should be submitted; submitting something that needs additional non-standard preprocessing seems a bit pointless to me. *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. Only when the document is finished does it make sense to generate a self-contained XML source for it. 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. 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. Sure, but my point is people probably don't want to do this all the time. 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? Obviously you don't submit XML source up until that point. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
On 2007-11-25, at 23:51, ext Paul Hoffman wrote: They still should (strongly) consider checking the validity of the 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Lets be careful with those XML submissions to the RFC Editor
W.r.t. 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 [EMAIL PROTECTED] 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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
Paul Hoffman [EMAIL PROTECTED] writes: At 11:58 PM +0200 11/25/07, Jari Arkko wrote: 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. 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. 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. -derek -- Derek Atkins 617-623-3745 [EMAIL PROTECTED] www.ihtfp.com Computer and Internet Security Consultant ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
Marshall, 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. 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. And all of this, incidentally, is what the RFC Editor and ADs do... Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
On 27-Nov-2007, at 12:16, Marshall Rose wrote: 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. And all of this, incidentally, is what the RFC Editor and ADs do... 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
Marshall, ok, so the current process is adequate, we just need to be a little 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
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. And all of this, incidentally, is what the RFC Editor and ADs do... ok, so the current process is adequate, we just need to be a little more careful in following it, right? /mtr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
Ned Freed wrote: ... 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. ... 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. Only when the document is finished does it make sense to generate a 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
Paul Hoffman wrote: At 11:58 PM +0200 11/25/07, Jari Arkko wrote: 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. 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
--On Monday, 26 November, 2007 11:21 +0100 Eliot Lear [EMAIL PROTECTED] 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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
At Mon, 26 Nov 2007 11:21:05 +0100, Eliot Lear wrote: At Mon, 26 Nov 2007 11:21:05 +0100, Eliot Lear wrote: Paul Hoffman wrote: At 11:58 PM +0200 11/25/07, Jari Arkko wrote: 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. 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. 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
--On Monday, 26 November, 2007 11:21 +0100 Eliot Lear [EMAIL PROTECTED] 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. 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. 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. +1 Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Lets be careful with those XML submissions to the RFC Editor
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 PROTECTED] 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 --On Monday, 26 November, 2007 11:21 +0100 Eliot Lear [EMAIL PROTECTED] 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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Lets be careful with those XML submissions to the RFC Editor
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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
Paul Hoffman wrote: 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
Hi Julian, On 2007-11-25 22:26 Julian Reschke said the following: Paul Hoffman wrote: 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. 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
At 10:26 PM +0100 11/25/07, Julian Reschke wrote: Paul Hoffman wrote: 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
At 11:58 PM +0200 11/25/07, Jari Arkko wrote: 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. 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. (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.) 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
Clarification below: On 2007-11-25 22:39 Henrik Levkowetz said the following: Hi Julian, On 2007-11-25 22:26 Julian Reschke said the following: Paul Hoffman wrote: 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. 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. 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
At Sun, 25 Nov 2007 14:09:37 -0800, Paul Hoffman wrote: At 11:58 PM +0200 11/25/07, Jari Arkko wrote: 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. 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. I agree with Paul here. The TXT is what the IESG approved. The XML is just a convenience. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
Hi Julian, On 2007-11-25 22:26 Julian Reschke said the following: Paul Hoffman wrote: 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. 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf 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 PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
Hi Mark, On 2007-11-25 23:52 Mark Andrews said the following: ... 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. I don't see this. Could you send more specifics off-list (with cc: [EMAIL PROTECTED]) ? 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
