Subject: draft-bradner-rfc-extracts-00 and the risk of "false RFCs"

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 18 Feb 2005 18:13:52 +0100

"Extracting RFCs", draft-bradner-rfc-extracts-00, says:

> It would clearly be confusing if someone could take an IETF standard
> such as RFC 3270 (MPLS Support of Differentiated Services), change a
> few key words and republish it, maybe in a textbook, as the
> definitive standards for MPLS Support of Differentiated Services.

I owe to Glenn Maynard what seems to be a fatal flaw in that
reasoning. Glenn said:

> Further, nothing prevents me from writing up my own bogus standard
> and calling it "RFC 3270 (MPLS Support of Differentiated Services)";
> since it's not a derivative work of the other RFC 3270, its
> copyright license is irrelevant.

So, the restriction on modification of RFCs does *not* prevent
misrepresentation. Copyright only prevents you to *modify* a RFC, not
to *pose* as such.

It seems the only protections against this misrepresentation are
trademarks ("do not dare to call your thing Coca-Cola!"), which are
used, for instance, by some free software projects (Mozilla and
NetBSD, for instance) or may be legal action for deception (I'm not
sure of the legal word in english, but, in France, you can certainly
sue for "tromperie" if someone publishes a text posing as a standard).

Comments?

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

---

From: "Lawrence Rosen" <[email-masked]>
Date: Fri, 18 Feb 2005 10:40:15 -0800

Stephane,

Your analysis is correct. There is no threat to anyone from modification of
RFC documents after they are published, and the only meaningful way to
protect the "authentic" from the "forked" standard is to use trademarks.

/Larry

Lawrence Rosen
Rosenlaw & Einschlag, technology law offices (www.rosenlaw.com)
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242  ●  fax: 707-485-1243
Author of “Open Source Licensing: Software Freedom 
               and Intellectual Property Law” (Prentice Hall 2004)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stephane Bortzmeyer
> Sent: Friday, February 18, 2005 9:14 AM
> To: [email-masked]
> Subject: draft-bradner-rfc-extracts-00 and the risk of "false RFCs"
>

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 18 Feb 2005 14:29:17 -0500

On Fri, 2005-02-18 at 13:40, Lawrence Rosen wrote:

> There is no threat to anyone from modification of
> RFC documents after they are published, 

I don't think that's supportable; the threats posed by carelessly or
maliciously modified RFC's include at the very least end user 
confusion and failure of interoperability.  

The latter is particularly offensive to the core values of long term 
IETF participants.

						- Bill

---

From: "Lawrence Rosen" <[email-masked]>
Date: Fri, 18 Feb 2005 11:39:15 -0800

I don't disagree with the principle that says that IETF standards should not
be changed by each implementer. My email was not well phrased. I meant only
to suggest that (1) as Stephane Bortzmeyer pointed out, onerous copyright
restrictions won't suffice to prevent the evil you see, and (2) trademark
protection can work to establish the authenticity of IETF standards. So if
you don't like forking, discourage it in a way that is compatible with
software freedom. Use trademarks to protect the "official" standard, and
don't restrict the freedom to copy and modify software.

/Larry

Lawrence Rosen

> From: Bill Sommerfeld [mailto:[email-masked]]
> Sent: Friday, February 18, 2005 11:29 AM
> To: [email-masked]
> Cc: 'Stephane Bortzmeyer'; [email-masked]
> Subject: RE: draft-bradner-rfc-extracts-00 and the risk of "false RFCs"
>

---

From: "todd glassey" <[email-masked]>
Date: Fri, 18 Feb 2005 11:54:40 -0800

I have a dumb question - what's to stop anyone from taking an RFC and
rewriting part of it and re-filing it with the IETF as the next instance in
that RFC's evolution??? I have seen absolutely nothing in any of the IETF
process documents that would prohibit this. The IETF could claim that they
were not going to publish it, but since they had already established a chain
of history for publishing an earlier instance, then this would be specific
to refusing to accept materials from one person while accepting those from
another.

Todd

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 18 Feb 2005 15:17:06 -0500

I think that the argument being made is not that there is no threat, but 
that the current counter-measure does not prevent the threat.

I would observe that while it does not completely prevent the treat, it 
does significantly ameliorate it.  If that were not true, the folks wanting 
wider access to the documents than the current policy permits would not 
have a problem.

My impression is that the current rules do help control the problem.  It 
may be sensible to relax the rules, but this should be done with 
sensitivity to the impact on the necessary goal of maintaining 
interoperability and avoiding end user confusion.

Yours,
Joel M. Halpern

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 18 Feb 2005 15:27:02 -0500

In message <[email-masked]>, "Lawrence Rosen
>protect the "authentic" from the "forked" standard is to use trademarks.

Several of us have already wondered if we should explore trademarks.  I 
suspect, though, that that's more an issue for the newtrk working group 
than for this one.  Harald?

		--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 18 Feb 2005 15:37:00 -0500

On Fri, 2005-02-18 at 14:54, todd glassey wrote:
> that RFC's evolution??? 

Nothing, and nothing should.

That's known as "participating in the IETF standards process".

							- Bill

---

From: [email-masked] (Scott Bradner)
Date: Fri, 18 Feb 2005 15:47:03 -0500 (EST)

> process documents that would prohibit this.

maybe because that is specifically permitted

Scott

---

From: "todd glassey" <[email-masked]>
Date: Fri, 18 Feb 2005 13:44:34 -0800

So then what happens when the original authors try and rework their
document? now there are two separate documents with the same identity
progressing... Really smart eh? - So then no one ever really needs to draft
a I-D - just pick some RFC and strip ALL of the content out of it and
install new content.

Just as Scott says, there is nothing in the IETF process to prevent this
type of Hijack.

Todd

----- Original Message ----- 
From: "Scott Bradner" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Friday, February 18, 2005 12:47 PM
Subject: Re: draft-bradner-rfc-extracts-00 and the risk of "false RFCs"

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Feb 2005 17:05:23 -0500

--On Friday, 18 February, 2005 15:27 -0500 "Steven M. Bellovin"
<[email-masked]> wrote:

> In message
> <[email-masked]>, "Lawrence
> Rosen " writes:
>> Stephane,
>> 
>> Your analysis is correct. There is no threat to anyone from
>> modification of RFC documents after they are published, and
>> the only meaningful way to protect the "authentic" from the
>> "forked" standard is to use trademarks.
>> 
> 
> Several of us have already wondered if we should explore
> trademarks.  I  suspect, though, that that's more an issue for
> the newtrk working group  than for this one.  Harald?

FWIW, there is no conceivable way to trademark "RFC".   If we
wanted to go down that path, the right thing to do would
probably be to rename the "ISD" proposal that is now working its
way through newtrk to something unique and distinguishable and
trademark that.

And I agree that, beyond the above, this is probably a newtrk
matter.

   john

---

From: Don Armstrong <[email-masked]>
Date: Fri, 18 Feb 2005 17:02:11 -0800

On Fri, 18 Feb 2005, Lawrence Rosen wrote:
> modification of RFC documents after they are published, and the only
> meaningful way to protect the "authentic" from the "forked" standard
> is to use trademarks.

Why bother to use legal means to do this at all, when there are
perfectly adequate technical measures to identify an official RFC from
an unofficial one?

The IETF should sign the official variant of an RFC with a key (PGP or
similar) to demarcate the official RFC.

Don Armstrong

-- 
Taxes are not levied for the benefit of the taxed.
 -- Robert Heinlein _Time Enough For Love_ p250

http://www.donarmstrong.com              http://rzlab.ucr.edu

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 18 Feb 2005 20:44:22 -0500

> perfectly adequate technical measures to identify an official RFC from

the people most likely to be harmed by an unofficial RFC would be the
ones who would not know how to check the signature.

---

From: Matthew Garrett <[email-masked]>
Date: Sat, 19 Feb 2005 02:03:59 +0000

> confusion and failure of interoperability.  

Perhaps a better way of thinking about this is to work out what you
actually want to prevent, and then see if it's possible to do this while
still allowing desirable goals. It's obviously the case that attempting
to pass off a modified RFC as the original is bad and incompatible with
the idea of creating standards. However, there is currently little (or
nothing) stopping me from writing a completely new text and then
claiming that it's RFC 2821 except that it would take some time and
effort. If I'm actively malicious, this isn't going to stop me.

So the current situation makes it somewhat harder to pervert the idea of
standardisation, but doesn't make it impossible. It also makes it harder
to produce useful works. As an example, we can hypothesise a company
that has an internal instant messaging protocol loosely based on SMTP.
The easiest way of documenting this would be to modify RFC 2821 and
clearly mark it as a document describing an internal standard not
intended for wider use. The alternative would be to have a separate
document detailing the differences between the protocol and SMTP (which
would make implementation awkward), or to write a new document from
scratch (which is duplication of effort).

Rather than focus on making documents unmodifiable (which reduces but
doesn't remove the potential for fake RFCs, and also makes useful
modifications impossible), why not focus on preventing people from
passing off fake RFCs as the real thing? A license that requires
renaming after modification would be acceptable to the open source
community and would offer the same level of protection as the current
policy. Further protection of some aspect of the RFC identification
would make all passing off impossible without preventing any useful
modifications.

-- 
Matthew Garrett | [email-masked]

---

From: Don Armstrong <[email-masked]>
Date: Fri, 18 Feb 2005 18:11:08 -0800

On Fri, 18 Feb 2005, Bill Sommerfeld wrote:
> the people most likely to be harmed by an unofficial RFC would be
> the ones who would not know how to check the signature.

Are such people even capable of writing software that actually
conforms to an RFC?

Lets take a step back. Are they even capable of reading and
understanding an RFC at all?

I mean, it's not like it's all that difficult to run:

   gpg --verify foorfcsig foorfc; 

surely this is much less complicated than operating a compiler
properly.

Don Armstrong

-- 
Tell me something interesting about yourself.
Lie if you have to.
 -- hugh macleod http://www.gapingvoid.com/archives/batch20.php

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 18 Feb 2005 22:23:54 -0500

> Are such people even capable of writing software that actually

you have an unrealistically narrow view of the target audience of IETF
documents.

---

From: Don Armstrong <[email-masked]>
Date: Fri, 18 Feb 2005 19:42:28 -0800

[Please refrain from Cc:'ing me. I'm subscribed.]

On Fri, 18 Feb 2005, Bill Sommerfeld wrote:
> > > the people most likely to be harmed by an unofficial RFC would
> > > be the ones who would not know how to check the signature.
> > 
> you have an unrealistically narrow view of the target audience of
> IETF documents.

Perhaps I do have unrealistic assumptions about the average
intelligence of the target audience of IETF documents,[1] but assuming
the target audience of IETF documents is capable of the following:

  1) reading and understanding them
  2) following simple directions to verify the authenticity of the
  document

then I really don't see the difficulty. It really is quite trivial to
verify a PGP signature, as I demonstrated previously. Surely anyone
for whom the accuracy of an RFC was important would be capable of
undertaking such a simple task.

This also has the added advantage of taking care of malicious RFC-look
alikes that aren't derivative works of an actual RFC and thus aren't
covered by the license at all.

Don Armstrong

1: It wouldn't be the first time that I've been surprised by assuming
an audience was capable of rather rudementary tasks...
-- 
DIE!
 -- Maritza Campos http://www.crfh.net/d/20020601.html

---

From: "'Stephane Bortzmeyer'" <[email-masked]>
Date: Mon, 21 Feb 2005 12:31:20 +0100

On Fri, Feb 18, 2005 at 03:27:02PM -0500,
 Steven M. Bellovin <[email-masked]> wrote 
 a message of 15 lines which said:

> Several of us have already wondered if we should explore trademarks.

Trademarks is only one of the ways we could fight "rogue" RFCs. Other
ways (non-exclusive, BTW) have been mentioned in that thread:

- "You have to rename" licence (widely used: Mozilla, LaTeX, NetBSD)

- Certification ("ISOC-approved")

- Cryptographic signatures 

None is perfect (nothing is ever perfect in law) but they are lighter
than the trademark process (specially since "RFC" may be
non-trademarkable). 

What is clear is that preventing the modification of RFCs has
*nothing* to do with the fight against rogue RFCs.

---

From: "Lawrence Rosen" <[email-masked]>
Date: Mon, 21 Feb 2005 09:29:35 -0800

> Trademarks is only one of the ways we could fight "rogue" RFCs.

Someone recently suggested the mark "RFC" for IETF documents. Another person
responded, probably correctly, that "RFC may be non-trademarkable."

But I believe you already have a common law trademark, "IETF", which could
be applied to authentic and approved RFCs to distinguish them from standards
proposed by any other organization. [The mark "IETF Secretariat" is already
registered to CNRI as a service mark.]

An "IETF standard" or "IETF RFC" is a uniquely authoritative standards
specification that modified versions are not. So you needn't forbid
modifications, just prevent them from being called "IETF specs" without your
permission.

/Larry

Lawrence Rosen

> Of 'Stephane Bortzmeyer'
> Sent: Monday, February 21, 2005 3:31 AM
> To: Steven M. Bellovin
> Cc: [email-masked]; [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Thu, 24 Feb 2005 17:46:56 -0500

>>>>> "Lawrence" == Lawrence Rosen <[email-masked]> writes:

    >> Trademarks is only one of the ways we could fight "rogue" RFCs.
    Lawrence> Someone recently suggested the mark "RFC" for IETF
    Lawrence> documents. Another person responded, probably correctly,
    Lawrence> that "RFC may be non-trademarkable."

    Lawrence> But I believe you already have a common law trademark,
    Lawrence> "IETF", which could be applied to authentic and approved
    Lawrence> RFCs to distinguish them from standards proposed by any
    Lawrence> other organization. [The mark "IETF Secretariat" is
    Lawrence> already registered to CNRI as a service mark.]

I think this is part of the solution.  I don't see any problems with
copyright licenses that require derivatives to be clearely marked either.

--Sam