Subject: Lawyer's advice on boilerplate in RFCs and I-Ds

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 15 Mar 2007 16:41:07 +0100

The following advice is from Jorge Contreras:

1 - The legal theory the IETF operates under is that people who contribute 
to the IETF process know they are doing so.

They should know this because of widespread distribution of the NOTE WELL 
statement and the clearly posted IETF process ruels that apply to all 
participation in IETF activities.

Therefore, they are bound by the IETF requirements for such contributions - 
including the grant of rights to make derivative works, license such 
derivative works and so on.

2 - There is no legal requirement for ANY boilerplate to appear in a 
contribution to the IETF. This includes internet-drafts.

The only exception might be the notification whereby a contributor 
withholds the right to make derivative works, such as when he/she submits a 
purely informational I-D.

3 - It is a nice touch to add an acknowledgement that a submission is 
submitted in full knowledge of the rules ("this document is submitted in 
conformance with BCP47" or equivalent), nice enough that it might be 
reasonable to make it mandatory for I-Ds, but it is NOT legally required.

4 - For RFCs, it is good to add boilerplate such as a copyright for the 
IETF trust, disclaimer of fitness-for-purpose and so on but this can be 
added by the RFC Editor; it doesn't need to be in the I-D.

                   Harald, Steve and Jorge

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

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 15 Mar 2007 17:05:42 +0100

Harald Tveit Alvestrand wrote:

 [Skipping point 1 because it doesn't surprise me]
 
> withholds the right to make derivative works, such as when he/she
> submits a purely informational I-D.

I'd really love it if ipr="full...." results in a minimum of "...."
(e.g. a one liner containing an URL) in all normal I-Ds (excl. the 
mentioned special cases)

> 3 - It is a nice touch to add an acknowledgement that a submission
> is submitted in full knowledge of the rules
[...]
> nice enough that it might be reasonable to make it mandatory for 
> I-Ds, but it is NOT legally required.

Authors confirming that they would submit known IPR issues immediately
isn't too bad.  But actually that could be also noted in the feedback
mail from internet-drafts-reply@ietf and under the same URL as above.

Readers _finding_ the IPR boilerplate in an I-D (and trying to take
it literally) are probably rare.  If it was only one case in the last 
three years I'd know its ticket number.

Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Mar 2007 11:15:03 +0100

> three years I'd know its ticket number.

There are readers who really take this seriously. They are corporate
IPR lawyers. It's immensely useful to show a corporate lawyer
the words in a draft that say
    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.
when explaining to them that their company has an absolute obligation
to disclose a patent [application]. Been there, done that.

So even if it is strictly speaking redundant to include, it would IMHO
be a serious error to remove it.

Many of the other concerns could be reduced, I think, by inserting words
like:

The following paragraphs will apply to this document if it is
published as an RFC:

    Full Copyright Statement

    Copyright (C) The IETF Trust (2007).
    ...blah blah blah...

       Brian

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 16 Mar 2007 11:38:30 +0100

Brian E Carpenter wrote:

> So even if it is strictly speaking redundant to include,
> it would IMHO be a serious error to remove it.

Sigh... so far for that attempt to replace the "fullsh*t"
by a mere one liner containing an URL.   

> Many of the other concerns could be reduced, I think, by
> inserting words like:

> The following paragraphs will apply to this document if
> it is published as an RFC:
 
[...]

"Inserting" and "this document" doesn't sound like a plan
to reduce the boilerplates in I-Ds, did I miss something ?

Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Mar 2007 12:23:27 +0100

> to reduce the boilerplates in I-Ds, did I miss something ?

No, except possibly that we have no consensus to reduce
boilerplate yet, as far as I know; just a discussion.

My personal opinion is that the boilerplate doen't bother
me in the least. I see no value in reducing it as such. I do
see John's point that some of it really doesn't logically
apply to I-Ds. Thus, I see value in the disclaimer I suggested.
I also see value in a reader *knowing* that if the document
becomes an RFC, it will contain the boilerplate.

Remember that many people read I-Ds who will never in their
lives read BCP 78 and BCP 79. I think it is correct to give
those readers fair warning.

     Brian

---

From: Pekka Savola <[email-masked]>
Date: Fri, 16 Mar 2007 13:40:49 +0200 (EET)

> mail from internet-drafts-reply@ietf and under the same URL as above.

Note that this is a much more stricter statement than BCP 79 section 6
specifies (unfortunately).

Among other things, you're allowed to delay the IPR disclosure for 
months for a duration you consider reasonable ("as soon as reasonably 
possible after .. publication") or until the contribution is accepted 
by the IETF if the contribution is not a draft of your own ("has been 
incorporated into a submission to be published in an I-D.. or 
seriously being discussed in a WG... strong encouraged to make .. 
preliminary disclosure").

This was one instance of why the approval of 
draft-housley-tls-authz-extns was withdrawn on Feb 26 2007.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 16 Mar 2007 13:21:19 +0100

> me in the least. I see no value in reducing it as such.

I _hate_ EULAs and anything in their direction, they always
end up in saying "you lose", no matter in what position,
reader, author, implementor, I-D collector, or what else.

IIRC you also liked that this stuff isn't required in IONs.

Admittedly there could be worse things like adding a legal
disclaimer to each mail redistributed by IETF mailing lists.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 16 Mar 2007 14:05:44 +0100

> specifies (unfortunately).

Okay, s/immediately/promptly/  (3.2.1 A)

> you're allowed to delay the IPR disclosure for months for a duration
> you consider reasonable

Not exactly my interpretation of "as soon as reasonably possible".  It
sounds like a SHOULD, e.g. not while you're offline, no matter how long
that takes.  But "offline" isn't reasonable for a contributor (3.2.1 B).

> until the contribution is accepted by the IETF if the contribution is
> not a draft of your own

Yes, that's less clear.  Some excuses I'd have wrt 4407 is that I don't
believe in their IPR, they did submit it for an earlier I-D, and I did
a.s.a.p. (= two days after the ASRG cochair resigned when Caller-ID was
added to the MARID agenda as "late surprise").

Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Mar 2007 14:56:09 +0100

> Okay, s/immediately/promptly/  (3.2.1 A)

"Immediately" is unreasonable.

"Promptly" seems to me to mean exactly the same as "as soon as
reasonably possible." And note that it can easily take a couple
of months for a company to perform due diligence to decide whether
it believes that a patent does or doesn't read on a draft. Patent
claims are written in such bizarre English that ordinary people
generally can't make this decision. This often includes the ordinary
engineer who originally made the invention that underlies the
bizarre English.

     Brian

---

From: John C Klensin <[email-masked]>
Date: Fri, 16 Mar 2007 11:11:38 -0400

> those readers fair warning.

So do I. But I'd think that --especially for I-Ds-- "fair
warning" could easily be an introductory sentence to the effect
of "this document and its content are covered by some special
rules about IPR and disclosure" (I'll let the lawyers draft
language) and a pointer to the BCPs, rather than pages of
boilerplate.  If people are interested in that information, they
will look it up.  If they are not interested, they not look at
the boilerplate either. 

Remember that BCPs and BCP-like documents have a major advantage
over boilerplate: they can contain explicit backtrace and change
log information that explains what changed and when.  If we
like, they can also contain both plain-English explanations and
lawyer-ese.   In addition, if we reference RFC numbers, the
check for "is there any chance that this has changed since the
last time I actually read it" requires a four-digit string
comparison. 

By contrast, if we insert boilerplate into a document, someone
who thinks that they know what that boilerplate is about will
sometimes need to make a side-by-side comparison --a virtual
full-text diff-- to be sure.

So, you can consider that a proposal to take the boilerplate
out... especially from the I-Ds.

    john

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 16 Mar 2007 12:16:30 -0400

On Fri, 16 Mar 2007 11:11:38 -0400

> last time I actually read it" requires a four-digit string
This is precisely what we have in mind, including quite specifically
using the RFC number rather than the BCP number, to eliminate any
ambiguity about date and hence effective version.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: "todd glassey" <[email-masked]>
Date: Fri, 16 Mar 2007 11:43:12 -0700

The problem Steve is that documents are tied to specific instances of RFC's 
which could be revised and the previous T's and C's changed as such. Since 
there is no real "RFC ver XX" scale in place it is impossible to tell 
retroactively what was in place when some conveyance was accomplished.

Todd

----- Original Message ----- 
From: "Steven M. Bellovin" <[email-masked]>
To: "John C Klensin" <[email-masked]>
Cc: "Frank Ellermann" <[email-masked]>; "Brian E Carpenter" 
<[email-masked]>; <[email-masked]>
Sent: Friday, March 16, 2007 9:16 AM
Subject: Re: Lawyer's advice on boilerplate in RFCs and I-Ds

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 16 Mar 2007 14:53:22 -0400

On Fri, 16 Mar 2007 11:43:12 -0700
"todd glassey" <[email-masked]> wrote:

> The problem Steve is that documents are tied to specific instances of
> RFC's which could be revised and the previous T's and C's changed as
> such. Since there is no real "RFC ver XX" scale in place it is
> impossible to tell retroactively what was in place when some
> conveyance was accomplished.
> 

Todd, that's precisely why we're going to use RFC numbers rather than
BCPs, because RFCs never change once issued.  There is no such thing as
"RFC xxx Version yyy" -- period.

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 17 Mar 2007 12:01:50 +0100

> out... especially from the I-Ds.

That is my preference too, although having pointers to documents that
explain the situation would be useful.

This made me realize that there is no RFC that explain several things
that Jorge has explained to us on the list, in simple language
intended for those who are interested to understand what the IETF
rules mean.  For example:

 * what the copyright notice in RFCs actually mean (boilerplate),

 * that authors do retain the full copyright to the text,

 * that BCP 78 3.3 (E) is about giving rights to third parties,

 * and possibly more that I don't recall now.

Writing such a document, possibly as an ION, may be useful.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 17 Mar 2007 12:01:50 +0100

/Simon

---

From: John C Klensin <[email-masked]>
Date: Sat, 17 Mar 2007 07:58:45 -0400

--On Saturday, 17 March, 2007 12:01 +0100 Simon Josefsson
<[email-masked]> wrote:

> That is my preference too, although having pointers to
> documents that explain the situation would be useful.

Agreed.

> This made me realize that there is no RFC that explain several
> things that Jorge has explained to us on the list, in simple
> language intended for those who are interested to understand
> what the IETF rules mean.  For example:
> 

While I am not volunteering at this point (too much else on the
plate), I think this would be very helpful.

    john

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 17 Mar 2007 14:16:04 +0100

> plate), I think this would be very helpful.

A part of it is apparently covered by
http://iaoc.ietf.org/docs/TrustFAQv1.2.txt

Normally I find my way from www.ietf.org to anything I consider
as "interesting", but this time I needed Google to find the link
to the Trust FAQ.  Is there no link from the main IETF pages to
the IAOC yet, or where would I find an existing link ?

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 17 Mar 2007 15:02:19 +0100

[update]
> http://iaoc.ietf.org/docs/TrustFAQv1.2.txt

The IAOC homepage <http://iaoc.ietf.org/> has a link
to the trust hommepage <http://trustee.ietf.org/>, and 
there I found <http://trustee.ietf.org/24.html>, the  
"FAQ for reproduction RFCs"

That FAQ covers another part of Simon's proposal for
the "old" (3978) rules.  In the form of an HTML page 
with no links at all - it could be improved by using
the rfcmarkup output for text ION input, or by manual
editing for a future version covering the "new" rules.

Frank

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 17 Mar 2007 17:03:29 +0100

> http://iaoc.ietf.org/docs/TrustFAQv1.2.txt
...
> "FAQ for reproduction RFCs"

I believe those documents are misleading and contains mistakes.  There
is no contact or authorship information, and the text has been
modified several times (possibly because I sent comments on the FAQ
earlier, but I never got a reply on my comments).

For example, the FAQ currently claims that the IETF Trust will
tolerate fair use of, e.g., text in RFCs.  But the IETF Trust does not
necessarily own copyright on such text, and its opinion is thus
irrelevant.  This misleads people to think that there is no problem.

I wish that a document to describe these matters would be developed
with feedback from the community, and have clear authorship.  It would
be useful to find out when (date) and who changed such a document and
in what way, and for what reason.  Publishing them as ION would be an
improvement, but doesn't (as far as I know) address making it easy to
find out when the document changed, what changed and why it changed.

/Simon

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 17 Mar 2007 21:23:30 +0100

Simon Josefsson wrote:
 
> There is no contact or authorship information

The trustee page says trustees@, and the IAOC page iaoc@

Maybe both pages are not yet ready for curious visitors,
I ran into a "404 error document not found" after trying
to get robots.txt, after iaoc.ietf.org/docs/ said "not 
authorized".  A search in the IAOC minutes with a query
"FAQ site:iaoc.ietf.org" finally answered that question
wrt the Trust FAQ (and reality as defined by googlebot),
nothing's wrong with that FAQ.

 [FAQ for reproduction RFCs] 
> For example, the FAQ currently claims that the IETF Trust
> will tolerate fair use of, e.g., text in RFCs.  But the
> IETF Trust does not necessarily own copyright on such
> text, and its opinion is thus irrelevant.  This misleads
> people to think that there is no problem.

It says that it's about the state in June 2006 (RFC 3978).

The opinion of the IETF Trust as far as they're concerned
in "6. Am I allowed to reproduce extracts from RFCs" isn't
irrelevant.  That part of the answer starts with "generally
speaking", and I'm led to believe that the Trust won't try
to bite me if I reproduce extracts from an RFC indicating
the source and any original copyright statement.

It doesn't mislead me to believe that the IETF Trust is the
only possibile entity trying to bite me, FAQ 7 mentions the
original authors, and FAQ 10 mentions non-IETF RFCs.

> Publishing them as ION would be an improvement, but doesn't
> (as far as I know) address making it easy to find out when
> the document changed, what changed and why it changed.

When and what, see http://www.ietf.org/IESG/content/ions.html
There's a repository with "approved", "draft", and "dated"
IONs, click on "revision log" to find other revisions of a
given ION.  That could also answer "why", each revision has
a comment.

It's as easy as it gets with a Wiki or SVN resp. (ok., I don't
find a global "recent changes" page immediately, but I'd bet
that it exists somewhere.)

Frank

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 18 Mar 2007 10:54:34 +0100

> Writing such a document, possibly as an ION, may be useful.

I still have some hope that -incoming, which will OBSOLETE 3938, will be 
that document.
Obviously, if the copyright notice isn't there, the explanation for it can 
be short :-)

         Harald

---

From: "todd glassey" <[email-masked]>
Date: Sun, 18 Mar 2007 11:43:18 -0700

Steven - Thanks for responding!

I would like to respectfully disagree with your retort... RFC's like any 
other document published in the IETF are regularly upgraded and republished, 
and with those updates, and/or changes in the language come issues with 
whether the same contractual process meets the same set of Terms and 
Conditions it used to. Clearly also since there is no contractual release 
allowing the IETF to change its contractual status with participants once 
underway, this is an issue too.

My point is that a contract which is composed of a specific set of terms and 
conditions remains the same when those conditions are republished as the 
next generation of whatever unless there is a process to get a new agreement 
from the participants...

As such, the issue I pointed out  stands - that the RFC numbering system 
alone IMHO is not granular enough to actually identify all of the components 
of the Participation Contract that one must be fully disclosed for one to 
participate in a knowing and informed manner.

Sorry - but it is what it is... There are too many documents and no process 
for managing changes in them. The RFC model is broken IMHO with regard to 
organization processes.

What this IETF needs is ONE document that is the Participation Contract with 
the IETF. The IETF then needs also the Uniform 3rd Party Reliance 
Release/License for those people implementing the IP in whatever form. The 
point is fewer documents is better. Easier managed, and more readily 
disclosed.

Todd

----- Original Message ----- 
From: "Steven M. Bellovin" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "John C Klensin" <[email-masked]>; "Frank Ellermann" 
<[email-masked]>; "Brian E Carpenter" <[email-masked]>; 
<[email-masked]>
Sent: Friday, March 16, 2007 11:53 AM
Subject: Re: Lawyer's advice on boilerplate in RFCs and I-Ds

---

From: "todd glassey" <[email-masked]>
Date: Sun, 18 Mar 2007 12:04:15 -0700

----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
To: "Simon Josefsson" <[email-masked]>
Cc: "Frank Ellermann" <[email-masked]>; "Brian E Carpenter" 
<[email-masked]>; <[email-masked]>
Sent: Saturday, March 17, 2007 4:58 AM
Subject: Re: Lawyer's advice on boilerplate in RFCs and I-Ds

>> documents that explain the situation would be useful.

This is only true if the pointers contain revision information too - since 
any revision to the documents in those pointers may invalidate the contents 
or T's and C's of the contractual framework.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Mar 2007 10:01:36 +0100

On 2007-03-17 17:03, Simon Josefsson wrote:
> I believe those documents are misleading and contains mistakes.

You may believe that, but they were written with legal advice.

>  There

I'm not sure the FAQ has ever been updated. The author is the
Trust, obviously. (I was editor but the text came from several
people including counsel.)

> For example, the FAQ currently claims that the IETF Trust will

s/claims/states/

> irrelevant. 

Not at all. FAQ #6 is explicitly about code extracts, which are
freely usable. FAQ #7 is explicitly about text extracts where
users are advised to contact authors for permission.

> This misleads people to think that there is no problem.

I don't think so. Read FAQ #1 and #5.

> find out when the document changed, what changed and why it changed.

Yes, it may well be reasonable for future versions of the Trust FAQs
to become IONs. ION editorship is listed in each ION. ION update
history will be archived in http://www.ietf.org/IESG/content/ions/dated/
(No IONs have been revised yet, so there is no history...).

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Mar 2007 10:08:15 +0100

>> documents that explain the situation would be useful.

I believe we need to end up, minimally, with roughly what
we have today at the front of an I-D, and statement at the
back saying approximately:

   If published as an RFC, this document will incorporate
   all the formal notices, including IETF Trust copyright
   and disclaimer of warranty, whose latest version can be
   found at <somewhere>.

(let's not wordsmith those words here and now; this is
just to indicate the level of detail I think we need.)

     Brian

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 19 Mar 2007 11:40:34 -0400

On Sun, 18 Mar 2007 11:43:18 -0700
"todd glassey" <[email-masked]> wrote:

> I would like to respectfully disagree with your retort... RFC's like
> any other document published in the IETF are regularly upgraded and
> republished

Yes, but the RFC number is changed when that happens.  That's precisely
my point.  See http://www.cs.columbia.edu/~smb/rfcdiff.html for the
best-known example -- a one-word change resulted in RFC 1409 being
replaced by RFC 1416.

---

From: "todd glassey" <[email-masked]>
Date: Tue, 20 Mar 2007 11:54:41 -0700

Steve - I understand the intent - Let me one question... is this true of all 
RFC's today? i.e. that any time they are revised that a new work and not a 
BIS is created? The reason is that I seem to recall several RFC's that were 
revised numerous times without obsolescing the previous document RFC number.

My feeling is that if this is true then this model is inconsistent across 
all WG's and all issued RFC's.

As to what needs to happen, the 100,000 meter goal should be to create some 
readily navigable and easily described set of T's and C's for participating 
in the program. To that end I might suggest that a new class of Internet 
Document be created to complement the ION's and that would be a IETF/IESG 
Policy Document or IPD. These would be specific to the Policies and 
Management Processes of the Entity and would be separated in that they could 
be based on RFC's but also carry revision dates. That would allow the number 
of documents in the process to be limited so that it doesn't take someone 
like Jorge two weeks of formal review as a General Counsel to understand 
what the T's and C's and impact on their Organization would be.

My intent in this is to bring to light that while RFC's are an amazing 
process for group collaboration that there are other aspects of contractual 
process that make it better to "keep it as simple and easily understood as 
possible"...

Just my two cents.

Todd

----- Original Message ----- 
From: "Steven M. Bellovin" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "John C Klensin" <[email-masked]>; "Frank Ellermann" 
<[email-masked]>; "Brian E Carpenter" <[email-masked]>; 
<[email-masked]>
Sent: Monday, March 19, 2007 8:40 AM
Subject: Re: Lawyer's advice on boilerplate in RFCs and I-Ds

---

From: "todd glassey" <[email-masked]>
Date: Tue, 20 Mar 2007 15:56:08 -0700

Harald and Jorge - did you really say this?

Harald I believe you would say this, but not you Counsel since it violates 
what I see as the envelope of the CR SS107 Exemptions.

----- Original Message ----- 
From: "Harald Tveit Alvestrand" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, March 15, 2007 8:41 AM
Subject: Lawyer's advice on boilerplate in RFCs and I-Ds

> to the IETF process know they are doing so.

That's not clean nor is it reasonable since very few of the actual 
contributor's hold any power of attorney for their sponsers anyway. If this 
isnt an issue now we can make it one in a hurry.

> participation in IETF activities.

NOTE WELL is probably not enforceable without an agreement to be bound by it 
IMHO.

>
> Therefore, they are bound by the IETF requirements for such 
> contributions - including the grant of rights to make derivative works, 
> license such derivative works and so on.

ONLY if they make what is called an Informed Consent Decision... without 
proper disclosure there is no informed consent.

> contribution to the IETF. This includes internet-drafts.

That would depend on whether the IETF is claiming that all republication of 
its works is covered under the Copyright Section 107 exemptions. I dont 
believe this is true and I am betting that you cant get Jorge to formally 
make a statement that it is...  See also 108 to notice the limitation of 
Libraries/Archives in their reproduction rights (which will include anyone's 
downloading anything from them).

http://www.copyright.gov/title17/92chap1.html#107

> withholds the right to make derivative works, such as when he/she submits 
> a purely informational I-D.

Not true. The US Copyright Section 107 Exemptions are for research only. 
Research ends when the Standard and Work in the IETF concludes on any 
document. So the actual publishing of the document as an RFC would be the 
last form of development that was going on in the IETF.

In fact its arguable that the 107 exemptions only apply to work in process 
(in the IETF Standards Stream and when the Standard is finally published 
that that work ends... and so does the exemption)...

So when Sun or Debian publishes a copy of anything the IETF is doing it is 
no longer research. Especially for all those copies of the IETF's past 
works. Likewise, ANY use of those materials outside the Standards Process 
are not covered either... So "Any and All" language doesnt work there 
either.

Sorry...

> reasonable to make it mandatory for I-Ds, but it is NOT legally required.

True.

> added by the RFC Editor; it doesn't need to be in the I-D.

yes, and in fact the diaclaimer may be critical...

Todd

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 20 Mar 2007 23:57:49 +0100

--On 20. mars 2007 11:54 -0700 todd glassey <[email-masked]> wrote:

> Steve - I understand the intent - Let me one question... is this true of
> all RFC's today? i.e. that any time they are revised that a new work and
> not a BIS is created? The reason is that I seem to recall several RFC's
> that were revised numerous times without obsolescing the previous
> document RFC number.

Todd,

once an RFC is issued, with an RFC number, that RFC number refers to that 
specific text.
Forever.

If you want to claim that this practice, which is at the core of the IETF 
document handling, has been deviated from in the last 15 years, "I seem to 
recall" is not good enough.

Produce evidence, or shut up.

               Harald

---

From: "todd glassey" <[email-masked]>
Date: Tue, 20 Mar 2007 16:14:23 -0700

Harald - always nice to be told to "Shutup" by you when I am asking a
question.
\
----- Original Message ----- 
From: "Harald Tveit Alvestrand" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 20, 2007 3:57 PM
Subject: Re: Lawyer's advice on boilerplate in RFCs and I-Ds

> once an RFC is issued, with an RFC number, that RFC number refers to that

 of course it does. But have any ever been revised or changed after 
vetting???

> Produce evidence, or shut up.

So lets see - I asked a question.  You responded to it as though it was an 
assertion which means either you didnt read it or you didnt understand the 
question as it was aksed...

As such, let me re-ask it - how many RFC's have had BIS  variants produced? 
For instance I seem to recall several revisions of any number of documents 
including fixing typos and the like. I have also noticed other BCP documents 
as well that get reved...

For instance, how many revisions of RFC3161 were there ??? I seem to recall 
the answer is three.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 21 Mar 2007 09:31:22 +0100

> Harald - always nice to be told to "Shutup" by you when I am asking a

Todd, your question has been answered many times over. RFCs (as identified 
by RFC numbers) are not changed.

Your continuing to harp on this subject, including your "I seem to recall" 
is an accusation that the WG chairs of this group are lying to you.

Such accusations, unbacked by evidence, are not considered normal or 
acceptable behaviour in IETF working groups.

                       Harald

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 21 Mar 2007 12:16:31 +0100

Harald Tveit Alvestrand <[email-masked]> writes:

> once an RFC is issued, with an RFC number, that RFC number refers to
> that specific text.
> Forever.
>
> If you want to claim that this practice, which is at the core of the
> IETF document handling, has been deviated from in the last 15 years,
> "I seem to recall" is not good enough.
>

Since you ask, RFC 4071 ('BCP 101 Update for IPR Trust') have been
modified after its publication, by appending RFC 4371 to it.

I don't know what lead to that decision, or who made it, but it breaks
the assumption that RFCs related to IETF IPR rules remains the same
once published, which sets a bad example.  I'm not aware of other
examples, but I have not looked carefully.

Compare:

http://www.ietf.org/rfc/rfc4071.txt
SHA-1 16e529147fd13dbcc8c6a3aa9491600d106e87c1

http://www.faqs.org/rfcs/rfc4071.html

I couldn't find a text version of the old file, but maybe someone have
it on their local computer and could publish the SHA-1 hash of their
copy for future reference.

/Simon

---

From: Colin Perkins <[email-masked]>
Date: Wed, 21 Mar 2007 12:30:13 +0100

> copy for future reference.

archive.org has the old version:

http://web.archive.org/web/20051130065636/http://www.ietf.org/rfc/ 
rfc4071.txt
MD5 = 8d5270c9e6b05ca5305982e1aa93e950

http://web.archive.org/web/20060411074747/http://www.ietf.org/rfc/ 
rfc4071.txt
MD5 = 5eb1b693a24fc3f6bd3a74c6d3c9578c

Colin

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 21 Mar 2007 15:33:17 +0100

There seems to be an inconsistency here.

The RFC Editor's official copy, 
<ftp://ftp.rfc-editor.org/in-notes/rfc4071.txt>, has not been damaged, but 
the document at <ftp://ftp.rfc-editor.org/in-notes/bcp/bcp101.txt> shows 
the same concatenation - plus an additional note at the top.

I've notified some people of the issue.

              Harald

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 21 Mar 2007 15:38:57 +0100

--On 21. mars 2007 15:33 +0100 Harald Tveit Alvestrand 
<[email-masked]> wrote:

> <ftp://ftp.rfc-editor.org/in-notes/rfc4071.txt>, has not been damaged,
> but the document at <ftp://ftp.rfc-editor.org/in-notes/bcp/bcp101.txt>
> shows the same concatenation - plus an additional note at the top.
>

Correction: There was an erroneous change at the RFC Editor's web site 
(operator error). But they had fixed it before I checked it (they were 
among the people I notified).

RFC 4071 should now be exactly what it was when it was published (and is 
intended to stay that way).

              Harald

---

From: "todd glassey" <[email-masked]>
Date: Wed, 21 Mar 2007 09:31:54 -0700

Joel - then let me ask this, who is responsible for tracking what process 
RFC's obsolete what? That is to say, is it the Editor's Desk that is 
responsible, or the Author's or the WG Chair or who?

What I am looking for is a road-map of all of the T's and C's documents for 
participation. The intent is that somewhere in this wide-wonderful IETF 
world there should be a listing of all of the 'in-force' document's which 
constrain the participation, the processes used in the IETF and its 
oversight processes and that document, since its a living thing probably 
shouldn't be a RFC in my opinion for the very reason that every time a 
revision to its content happens a new RFC would need to be issued.

I do understand the idea that all IP wants to be individually tracked but 
there are issues with the concept that a new RFC is issued from any updates, 
typo fixes and minor content changes. It creates a mad-house in tracking 
exactly what happened.

So lets see... We have protocol A and its published as RFC XYZ1, now some 
months later that same protocol (Protocol A) is extended by adding something 
else to it, like RADIUS or some PKI Enhancements from PKIX... So how is the 
genesis of the evolution tracked. There is no DELTA ("RFC XYZ1" or  "RFC 
XYZ1+PKIX XYZZY") for instance... where XYZZY is any random PKIX protocol 
like RFC3161 for instance.

The intent of this numbering system is to create a simple and easily managed 
process for tracking IP development. That's cool - but in instances where 
continuous evolution takes place (as in IETF process documents) this doesn't 
work as well.

Just my two cents.

Todd

----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
To: "todd glassey" <[email-masked]>
Sent: Tuesday, March 20, 2007 4:47 PM
Subject: Re: Lawyer's advice on boilerplate in RFCs and I-Ds

>I do not know on what basis you are getting this conclusion.  At least as 
>long as I have been involved in the IETF (more than 17 years) RFCs once 
>published have been unchangeable.  Any change gets a new number.
> Yours,
> Joel M. Halpern
>
> At 02:54 PM 3/20/2007, you wrote:
>>that were revised numerous times without obsolescing the previous document 
>>RFC number.
>

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 21 Mar 2007 14:38:23 -0400

The RFC index lists which RFCs update or are updated by, or replace or
are replaced by, other RFCs.  See, for example,
http://www.rfc-editor.org/rfc-index2.html which says for 2026:

	2026 	The Internet Standards Process -- Revision 3 S.
	Bradner [ October 1996 ] ( TXT = 86731 bytes)(Obsoletes RFC1602,
	RFC1871)(Updated by RFC3667, RFC3668, RFC3932, RFC3979,
	RFC3978)(Also BCP9)

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 21 Mar 2007 19:37:35 +0100

todd glassey wrote:

> let me re-ask it - how many RFC's have had BIS  variants produced?

Something like "3066bis", "2821bis", "2822upd", or "son-of-1036" are
informal names for Internet Drafts (or memos not published as I-D).

I-Ds have an "offical" name, it starts with draft- and ends with a
version number (or a version number + file extension like .txt), e.g.
draft-klensin-rfc2821bis-01

Some I-Ds are approved by the IESG to be published as RFC.  At this
time the ID still has its "official" I-D name, but it's actually an
approved RFC waiting for its number.

Authors and RFC-editor under the oversight of a responsible document
shepherd will fix some editorial issues like replacing "RFC xxxx" by
the number (assigned by the RFC editor), so that last I-D can still
be edited before it's eventually published as RFC.

After publication RFCs don't change, typos etc. can be submitted as
errata, but the master copy and its RFC number are frozen forever.

As an example the I-D informally called 3066bis is now RFC 4646, and
the only things that can be changed about it are the "status" (now a
BCP, or rather a part of a BCP) and any errata published separately.

Of course new I-Ds like "4646bis" are free to claim that they would
obsolete RFC 4646, but if and when that happens this "4646bis" would
get its own RFC number.

The numbers are not used strictly sequentially, there can be gaps
without published RFC, and RFC x with x < y can be published after
RFC y.

> I have also noticed other BCP documents as well that get reved...

BCP numbers, STD numbers, and FYI numbers are a different issue:

The BCP known as "BCP 47" used to be RFC 3066 for some years, now
BCP 47 is RFC 4646 + RFC 4647 (a BCP with two RFCs).  These BCP
numbers actually stand for sets of published RFCs, and these sets
can be modified.  I can't tell if they've ever been modified to an
empty set so far, check it out.

Frank

---

From: John C Klensin <[email-masked]>
Date: Wed, 21 Mar 2007 20:30:44 -0400

--On Wednesday, March 21, 2007 19:37 +0100 Frank Ellermann 
<[email-masked]> wrote:

> Something like "3066bis", "2821bis", "2822upd", or
> "son-of-1036" are informal names for Internet Drafts (or memos
> not published as I-D).
>
> I-Ds have an "offical" name, it starts with draft- and ends
> with a version number (or a version number + file extension
> like .txt), e.g. draft-klensin-rfc2821bis-01

But this is completely arbitrary stuff, often just author 
preference.    Taking the example you cite, had my mood been 
different on the day I submitted the initial version, it could 
have easily have been
   draft-klensin-rfc821ter-00
   draft-klensin-smtpupd-00 (normally, that would have been the 
I-D that became 2821, but _that_ I-D had a draft-ietf-drums... 
name)
   or any number of less mnemonic things.

This clearly does not have any IPR implications are all, since 
the IETF doesn't own nearly enough trademark rights to prevent 
posting of an I-D with "rfc" and some digits imbedded in its 
name.  I hope we never get into enough silly states that the 
IESG has to impose specific approval conditions for posting 
something named draft-AUTHORNAME-rfcNNNNbis but, even if they 
did, that would be a rule about file names for posting, not an 
IPR issue.

So the point was?

      john

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 22 Mar 2007 08:36:41 +0100

John C Klensin <[email-masked]> writes:

> This clearly does not have any IPR implications are all, since the
> IETF doesn't own nearly enough trademark rights to prevent posting of
> an I-D with "rfc" and some digits imbedded in its name.

Jorge said the Trust copyright notice covers "the RFC numbering
series".  See question 2 on <http://trustee.ietf.org/24.html>.  What
does that mean?  I read it to mean something like you suggest here,
although I also realize that a short word and digits is not creative
enough to be copyrightable.

I believe it would be useful to clarify exactly what the copyright
notice means.  In particular:

  * What does copyright on a "result of collective work" means?  As
    far as I understood, all contributors retain their individual
    bits, and the collective work is a combined work of their
    individual bits.  (I have a vague memory that a "combined work" is
    copyrightable in the US, but not so elsewhere.  Further, not all
    RFCs is the product of "combined work", which should be clarified
    as well.)

  * What does copyright on "the RFC numbering series" mean?  Do the
    Trust claims that a phrase 'rfc4711' is copyrighted by the Trust?

/Simon

---

From: John C Klensin <[email-masked]>
Date: Thu, 22 Mar 2007 04:09:46 -0400

b

--On Thursday, March 22, 2007 08:36 +0100 Simon Josefsson 
<[email-masked]> wrote:

> I believe it would be useful to clarify exactly what the
> copyright notice means.

I agree, although I fear that the answer may be "very little", 
since Jorge has told use that such notices are not in general 
useful outside the US.   At least, I think that is what he told 
us.

> In particular:
>
>   * What does copyright on a "result of collective work"
> means?  As     far as I understood, all contributors retain
> their individual     bits, and the collective work is a
> combined work of their     individual bits.  (I have a vague
> memory that a "combined work" is     copyrightable in the US,
> but not so elsewhere.  Further, not all     RFCs is the
> product of "combined work", which should be clarified     as
> well.)

Since the RFC editing process includes the addition of text and 
removal of other text and thereby changes the work from the last 
pre-RFC I-D, I would imagine that every RFC would be a combined 
work except, possibly, those created from beginning to end by 
the RFC Editor team.

>   * What does copyright on "the RFC numbering series" mean?
> Do the     Trust claims that a phrase 'rfc4711' is copyrighted
> by the Trust?

Beats me.  If read in English, it would assume it would assert 
copyright on a hypothetical document whose content was
   RFC 1
   RFC 2
   RFC 3
     ...
   RFC aleph-null
Interesting, but not useful.  I can't guess what it might mean 
in legalese, but I'm pretty sure the concept of how to number 
RFCs isn't subject to copyright.

     john

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 22 Mar 2007 09:23:49 +0100

John C Klensin <[email-masked]> writes:

> pre-RFC I-D, I would imagine that every RFC would be a combined work
> except, possibly, those created from beginning to end by the RFC
> Editor team.

Ah, the editing done by the RFC editor may likely be owned by the
Trust, yes.  (I wonder if that is in the RFC Editor contract.)
Although describing that as "result of collective work" seems
confusing to me, and I wonder whether not something else was meant
instead.  Such as the "collective work" by having many different
authors contribute minor corrections.

/Simon

---

From: "todd glassey" <[email-masked]>
Date: Thu, 22 Mar 2007 12:24:04 -0700

----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: "John C Klensin" <[email-masked]>
Cc: "Frank Ellermann" <[email-masked]>; <[email-masked]>
Sent: Thursday, March 22, 2007 12:36 AM
Subject: Re: Lawyer's advice on boilerplate in RFCs and I-Ds

> does that mean?  I read it to mean sometps://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: "todd glassey" <[email-masked]>
Date: Thu, 22 Mar 2007 12:24:04 -0700

----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: "John C Klensin" <[email-masked]>
Cc: "Frank Ellermann" <[email-masked]>; <[email-masked]>
Sent: Thursday, March 22, 2007 12:36 AM
Subject: Re: Lawyer's advice on boilerplate in RFCs and I-Ds

> enough to be copyrightable.

Not necessarily - the Derivative Rights may in fact give some of this away. 
Likewise, if a technological concept is vetted publicly on the IETF mailing 
list that IP is the property of the IETF totally as far as I can tell...

>    Trust claims that a phrase 'rfc4711' is copyrighted by the Trust?

It (the phrase "copyright on the RFC numbering series") refers to a 
copyright on the document that created the RFC processes and framework as 
far as I can tell... Jorge?

The IETF may also want to file 'process' (aka utility) patents against it's 
processes as well to protect those aspects of its larger IP dilemma.

hing like you suggest here,
> enough to be copyrightable.

Not necessarily - the Derivative Rights may in fact give some of this away. 
Likewise, if a technological concept is vetted publicly on the IETF mailing 
list that IP is the property of the IETF totally as far as I can tell...

>    Trust claims that a phrase 'rfc4711' is copyrighted by the Trust?

It (the phrase "copyright on the RFC numbering series") refers to a 
copyright on the document that created the RFC processes and framework as 
far as I can tell... Jorge?

The IETF may also want to file 'process' (aka utility) patents against it's 
processes as well to protect those aspects of its larger IP dilemma.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 22 Mar 2007 21:53:24 +0100

> So the point was?

The point was to answer Todd's question about those
"RFCs have had BIS variants" he has seen:  Informal
names.

As you said you could also pick rfc821ter as part of
the draft name, the LTRU folks seriously discussed
3066ter while working on 3066bis (now 4646), I tried
to convince Martin to split his "mailto-bis" into a
"2368bis" and a later "2368ter", anybody is free to
post a draft-name-rfc2821bis-00.txt (for values of
name != klensin), and nothing of this has anything
to do with modifying the content of published RFCs.

Published RFCs are frozen forever, only the status on
the cover page might change.  Apparently Todd didn't
know / believe this.

Frank

---

From: "todd glassey" <[email-masked]>
Date: Thu, 22 Mar 2007 14:47:53 -0700

----- Original Message ----- 
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, March 22, 2007 1:53 PM
Subject: Re: Lawyer's advice on boilerplate in RFCs and I-Ds

> the cover page might change.  Apparently Todd didn't

I just wasnt sure it had always been adhered to was all. The text saying so 
is pretty clear.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Mar 2007 15:05:43 +0200

> Trust, yes.  (I wonder if that is in the RFC Editor contract.)

It is known as "work for hire" in contractual terms, and the
rights in such work do belong to the IETF Trust, obtained
via ISOC or directly, since 1998.

    Brian

---

From: "Bill Fenner" <[email-masked]>
Date: Mon, 26 Mar 2007 18:45:00 -0400

> MD5 = 5eb1b693a24fc3f6bd3a74c6d3c9578c

That's shocking to me.  I had no idea that the ietf.org site could
have versions of RFCs that are different than the RFC Editor's.

The canonical version from the RFC Editor hasn't changed.

Presumably the correct answer is for the ietf.org/rfc/ pages to
faitfully mirror the RFC Editor's, but it'd be useful to understand
how they got to this divergent state.

  Bill

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 26 Mar 2007 21:31:25 -0700 (PDT)

On Mon, 26 Mar 2007, Bill Fenner wrote:
>>  http://web.archive.org/web/20051130065636/http://www.ietf.org/rfc/rfc4071.txt
>>  http://web.archive.org/web/20060411074747/http://www.ietf.org/rfc/rfc4071.txt

http://web.archive.org/web/20051130065636/http://www.ietf.org/rfc/rfc4071.txt

agrees with the canonical version on the RFC Editor's web site.

http://web.archive.org/web/20060411074747/http://www.ietf.org/rfc/rfc4071.txt,

which represents the current contents of http://www.ietf.org/rfc/rfc4071.txt,
consists of the concatenation of RFC 4071 and RFC 4371, which together form
BCP 101.

This appears to be well-intentioned but misguided meddling.

//cmh

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 27 Mar 2007 00:52:10 -0400

Hi,

I used the rfc search page
http://www.rfc-editor.org/cgi-bin/rfcsearch.pl, and searched for
rfc4071. You are presented with links to rfc4071, rfc4371 (in the More
Info field), and to bcp101. the rfc4071 link goes to
ftp://ftp.rfc-editor.org/in-notes/rfc4071.txt; the rfc4371 link goes
to ftp://ftp.rfc-editor.org/in-notes/rfc4371.txt; the bcp 101 link
goes to ftp://ftp.rfc-editor.org/in-notes/bcp/bcp101.txt where rfc
4071 and 4371 are concatenated, with a warning at the top of the page
that says [Note that this file is a concatenation of more than one
RFC.] 

I don't see any change to an rfc. 

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> -----Original Message-----
> From: C. M. Heard [mailto:[email-masked]] 
> Sent: Tuesday, March 27, 2007 12:31 AM
> To: [email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 27 Mar 2007 07:33:25 +0200

> This appears to be well-intentioned but misguided meddling.
As I said in my message on the 21st, this was an error at the RFC 
Editor, and has been reverted (the RFC has been restored from backup 
from a time before the error was made).

I don't know how long it will take before the IETF mirror picks up the fix.

                   Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Mar 2007 12:18:53 +0200

> have versions of RFCs that are different than the RFC Editor's.

Apparently, ietf.org runs an occasional sync.

> The canonical version from the RFC Editor hasn't changed.

Actually, it's changed back. It was wrong for a while.
Operator error.

> how they got to this divergent state.

Because the sync is too occasional? Maybe somebody can send a
ticket.

    Brian

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 27 Mar 2007 06:13:40 -0700 (PDT)

> I don't see any change to an rfc.

Look at http://www.ietf.org/rfc/rfc4071.txt

//cmh

---

From: Russ Housley <[email-masked]>
Date: Tue, 27 Mar 2007 10:53:19 -0400

I sent a ticket....

---

From: "todd glassey" <[email-masked]>
Date: Tue, 27 Mar 2007 09:22:23 -0700

Isnt there a formal policy on the Mirrors and their accuracy? - this is a 
real problem since if someone was to take policy statements from a Mirror 
that wasn't synched properly they would get bad policy and procedure info 
eh?

T.
----- Original Message ----- 
From: "Harald Alvestrand" <[email-masked]>
To: "C. M. Heard" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 26, 2007 10:33 PM
Subject: RFC 4071 (Re: Lawyer's advice on boilerplate in RFCs and I-Ds)

> As I said in my message on the 21st, this was an error at the RFC Editor, 
> and has been reverted (the RFC has been restored from backup from a time 
> before the error was made).
>