--On Monday, 05 March, 2007 19:32 +0000 Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote: >... >> (2) Providing good documentation that recognizes the >> origins of an idea and its date, even if there were some >> changes from the original version, can be very helpful >> in defending our work against patent vultures who try to >> make filings on work that the IETF has had under >> development for some time. Personally, I've reached the >> point that I would favor having most protocol >> specification RFCs contain a sentence of the form of >> "The work described here derives from a series of >> earlier drafts, including [ref, ref, ref] the first of >> which was circulated in 1968." > > I think something along these lines might be ok, so long as > its not a significant barrier to progress - I'd hate if every > new author had to be an I-D historian, or if anyone who wanted > to slow down a document could play the system using this. I > have a hard time seeing how that can be done. > > Anyway, I think this is an area where the tools team could > come to the rescue yet again, given the right set of > requirements, maybe e.g. including a link to an auto > generated list with the IETF LC announcement. (Before > anyone asks: I'm not volunteering, but would be happy > to chat about it over beer in Prague.) I'd be happy to join in that chat. However, I generally hate it when we make rules when "this is usually a good idea, please do it if appropriate" would suffice. If I can write an Acknowledgements section, I can put in a sentence, or extra paragraph, that identifies history. I don't think it is necessary or useful to construct a complete history; I do think enough information to warn someone that the history exists and where to start looking for it is sufficient. As with IPR issues, what I really don't know about doesn't count for this purpose (and we don't need more hair-splitting about that either). On the same theory that causes me to lock my car and turn on the alarm in the hope that any would-be thief is looking for targets of opportunity and will go elsewhere, a sentence that provides a strong, and easily-checked, clue that the document is based on prior versions and prior art that goes back 20 years is likely to cause a patent vulture to head somewhere else. Historian? No. But, if I'm generating draft-ietf-foo-bar-baz-19.txt for a Last Call, it doesn't take a lot of effort for me to (i) figure out that there was probably a -00, (ii) find it and figure out when it was posted, (iii) maybe take a fast look at it and see if there is more than a passing resemblance between the first and 20th versions. For the first two of these, it takes even less effort if I start remembering when -01 is posted. Similarly, if I'm producing version 3 of something and pick up a key idea from some other draft, it seems to me that a reference to that version of that draft, at that point, is both easy and arguably required. Or if draft-ietf-weeds-wandering-00 is really the successor to draft-aenewman-wandering-weeds-05 after the WG gets going, I think we can and should encourage Alfred Newman (who is probably the author or editor of both) to insert a note -- in the Acknowledgments or some obvious other place -- that identifies the chain. This theory does require a small amount of consideration and work on the part of the RFC Editor (as the setter of style and manager of 2223bis) and those who manage tools to generate RFCs and I-Ds. There are really two types of references to I-Ds (and to documents more generally, including RFCs). One is our usual variety, where we are pointing to another document for more or less current information. For those references, I-Ds are appropriately described as Smith, J, "Examining the Weeds", Work in progress... The second is an unambiguously historical record. When I say "the ideas in this specification derive from 'foo'", I'm making a historical reference and a target of a particular draft, date, version, and file name are, IMO, entirely appropriate. While I'm sympathetic to Michael's suggestion of putting that information inline into the Acknowledgements, I'd prefer a slightly different reference format along the lines above (I hope we don't need "Historical References" in addition to "Normative" and "Informative" ones, but will leave that up to the RFC Editor). For whatever it is worth, the ability to tag an I-D or RFC (or other) reference as "historical" would have another advantage. I had occasion to push draft-klensin-rfc2821bis-01 through Bill's xml2rfc validator last week. Because of what it is, that document contains a bunch of references to the original RFC 821 and 822. I probably didn't need the validator to warn me that RFC 821 had been superceded by 2821. But the right solution to that, IMO, is not an exception list or ignoring the warnings, it is to mark these references as historic and therefore static. john _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf