Subject: Re: Referencing BCPs [Re: ion-procdocs open for public comment]

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Feb 2007 10:14:49 +0100

On 2007-01-31 18:47, John C Klensin wrote:
> 
> --On Wednesday, 31 January, 2007 17:02 +0000 "Steven M.
> Bellovin" <[email-masked]> wrote:
> 
>> On Wed, 31 Jan 2007 11:54:26 -0500
>> John C Klensin <[email-masked]> wrote:
>>
>>> Except for the fact that the material being cited contains the
>>> specifics of license and IPR releases, and promises to abide
>>> by certain rules, by the authors.  Authors can't reasonably be
>>> asked to agree to something that might be published under the
>>> BCP number in the indefinite future, so you are either stuck
>>> with a document (RFC) number or a BCP as of a specific date,
>>> which amounts to the same thing and is harder to track down.

I agree. If someone says "where are the IETF copyright rules?"
the citation is BCP 78. If they say "where are the copyright
rules for RFC 3704?" the citation is RFC 3667.

>>>
>> I'll let Jorge correct me if I'm wrong, but referencing by
>> <number,date> is the norm in the legal world, since statutes
>> do get amended without necessarily being renumbered.
> 
> I believe that is correct.  The problem here is that, as a
> consequence of that referencing system, they have taken measures
> to be sure that the version corresponding to the reference is
> readily available.  We don't do that: finding out what was
> actually BCP NNN on some particular date requires both skill and
> out of band knowledge.
> 
>> I do agree we want to make it easy for non-lawyers.  I've
>> suggested a date-stamped archive of each version of each such
>> document, for precisely that reason. 
> 
> That, of course, would do that job and eliminate all of my
> objections.  But it does mean that, for many purposes, we can't
> use a reference to "BCP nnnn", it must be a reference to "BCP
> nnnn as of yyyymmdd" or its equivalent.

I simply observe that we are experimenting with date stamping
in the case of IONs, with the latest versions in
http://www.ietf.org/IESG/content/ions/ and the dated versions in
http://www.ietf.org/IESG/content/ions/dated/.
We'll see how that works for us.

     Brian

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

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 01 Feb 2007 20:06:55 +0100

Brian Carpenter wrote:

> http://www.ietf.org/IESG/content/ions/drafts/ion-procdocs.html

I liked the I-D better, the xml2rfc HTML output is hard to read.
For an ION you could probably remove the dummy chapters 3 and 4.

Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Feb 2007 11:44:32 +0100

> I liked the I-D better, the xml2rfc HTML output is hard to read.

Really? I find the links in the HTML version invaluable.

> For an ION you could probably remove the dummy chapters 3 and 4.

Correct, thanks.

    Brian

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 02 Feb 2007 16:54:10 +0100

> Really? I find the links in the HTML version invaluable.

Me too, but I prefer the "rfcmarkup" HTML version of the I-D, for
starters it uses a monospaced font, it doesn't spice the output
with character references not supported by my stoneage mozilla-3,
and where it uses comma-separated lists of RFCs or I-Ds they are
visually clearly separated:

http://tools.ietf.org/html/draft-carpenter-procdoc-roadmap

Maybe you could get a similar effect if you pipe the "unpaginated"
xml2rfc output into "rfcmarkup".  This procedure would kill UTF-8
and meta data, however.  Something is missing, probably xml2rfc
needs an additional output style XHTML resulting in an emulation
of rfcmarkup style, but using UTF-8, and preserving any meta data.

Frank