--On Monday, 05 March, 2007 19:32 +0000 Stephen Farrell
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf