Subject: Re: Terms used in rules-update-07

From: Frank Ellermann <[email-masked]>
Date: Sun, 30 Jul 2006 00:52:18 +0200

Simon Josefsson wrote:

> Ok, so now the rights granted to third parties only cover
> documents on the standards track.  No rights whatsoever are
> granted to third parties for Informational or Experimental
> RFCs.

No, I don't read it that way.  All RFCs can be IETF documents,
not only standards track or BCP.  But the opposite works, if
it's standards track or BCP it can't be "only" an "RFC editor
contribution".

That's why they started the "independent" list as a spin off
from "techspec", trying to get a grip on those "independent"
documents.

Somewhat frustrating from my POV, because it completely misses
the one point I'm interested in, will anybody ever try to fix
the completely broken "errata" procedure ?  Or will they abuse
this as an opportunity to kill the "independent" submissions ?

> For whatever reason, many important RFCs are published as
> Informational today.

Without starting to dig I could only say 3696 (+ errata), and
seriously fixing the messy "LDH" + "TLD" stuff, throwing in
issues like IDNA for TLDs and the odd expired 2606bis draft,
that's more than five minutes.

Or do you include non-technical RFCs like 3710 in your count ?
In that case it can't and shouldn't be more than informational
for various reasons.

> important examples are RFCs for cryptographic primitives.
> These often contain source code which are useful to extract.
> For example, RFC 3610, RFC 4493, and the recently approved
> HMAC-SHA-2 document.

Yes, that's a bit odd.  There are similar "not invented here"
documents qualifying as e.g. STD 63,  I can only guess that
it's both traditional, and a question of change control, going
back to 1321 and before.  1321 provides info for the Internet
community, but doesn't specify an Internet standard.  Whatever
that means - it certainly has no port number.

> Another important example are socket APIs, e.g., RFC 3542,
> RFC 3678, RFC 4584.  These often contain C header prototypes
> which are useful to extract.

Yes.  You're not forced to use sockets, maybe that's the point.
Somebody wishing to use OSI NSAPs or what else is free to do
so, and of course you're also not forced to use C.  At least
back to 2132 that used to be informational.  It's not "on the
wire", maybe they were stricter about this in the past (guess).

> I believe having different policies for code and text is not
> useful,

Can't judge this.  I certainly want to be free to extract code
snippets from RFCs, and if I modify them it's okay if I can't
claim that the modified code still "is" the RFC, in that case
it's only inspired by the RFC.  And maybe I seriously broke it.

> I believe it not useful to have different policies for
> standards track and non-standards track documents.

AFAIK that's not the case, and the difference is only about
IETF vs. independent.  The IETF can't decree rules for the
independent documents without the consent of the RFC editor.

Bye, Frank

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

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 29 Jul 2006 23:34:24 +0200

Simon Josefsson wrote:

> We can solve this by removing the text from the first
> paragraph that I highlighted above.

Why should we ?  The Trust gets some irrecovable rights from
the "contributors" (I read that as mainly the authors), and
can't later make up additional rights unilaterally.

Among other things they're not entitled to sell these rights.
Or to add "ads" of sponsors, Todd seriously proposed this.

I'd really love it if I could simply "stamp" a text with a
CC-BY-SA, and be done with it.  For any legalese above that
level I'd need a copyright lawyer, and it does not help that
BCP 79 explicitly confirms this fear.

> There may be other fatal problems in -07 that will restrict
> the IETF Trust from implementing the IETF's wishes for
> documents published under the rules-update-07 policy.

I'd care more about your wishes as author of your documents,
and IMO the IETF should respect your wishes.  After that I'd
care about the wishes of readers and potential implementors
of say 3548bis, up to simple cases like "I have that text in
my Web space, is that allowed, could you forbid it ?"

So far I hope that it's allowed, but you could forbid it -
after all it's only a draft at this time.  For an RFC I hope
that you couldn't forbit it.

> One week to review a legal document is not enough.

I won't really understand what those legal documents try to 
say also after a decade.  Just keep it as simple as possible,
and delete the part identified by Bill as unused from BCP 78.

Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 30 Jul 2006 00:52:18 +0200

Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 29 Jul 2006 23:34:24 +0200

Bye, Frank

---

From: "todd glassey" <[email-masked]>
Date: Fri, 4 Aug 2006 13:51:46 -0700

Yo Frank - all
----- Original Message ----- 
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, July 29, 2006 2:34 PM
Subject: Re: problems caused by rules-update-07

> Or to add "ads" of sponsors, Todd seriously proposed this.

So then why the Trust at all?

By the way - I figure the IP library is conservatively worth 2-3B USD.

> and IMO the IETF should respect your wishes.

So Frank - if the IETF doesnt get to give the entire package of rights
away - then what does it get to do? (BTW - I like the language)...

> After that I'd

How about we merge 78, 79 RFC2026 and a couple of others too?

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 06 Aug 2006 11:48:17 +0200

"Bill Fenner" <[email-masked]> writes:

> On 7/29/06, Simon Josefsson <[email-masked]> wrote:
>> Ok, so now the rights granted to third parties only cover documents on
>> the standards track.  No rights whatsoever are granted to third
>> parties for Informational or Experimental RFCs.
>
> There are Informational or Experimental RFCs that are IETF Documents.
> Standards Track documents can only be IETF Documents; Informational
> and Experimentals can be IETF Documents or RFC Editor Contributions.

Ah, right, thanks.

> (Note that I have no real idea how to tell that RFC 4554 is an IETF
> Document and RFC 4559 is an RFC Editor Contribution

Indeed, and that is worrying.  It must be clear which license applies
to a particular document.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 06 Aug 2006 12:11:41 +0200

> it's standards track or BCP it can't be "only" an "RFC editor

Yes, I see now.  It would be good if the documents themselves made it
clear what status they have, and thus consequently which license
applies to it.  Right now, every document reference BCP 78 which has
multiple licenses, and I have to find it out somewhere else which of
them applies to the particular document I read.

> In that case it can't and shouldn't be more than informational

No, I meant documents that influence technical work.  The examples I
gave should be sufficient to prove my point.

> that means - it certainly has no port number.

Yes.  Although I don't think a port number should be the criteria to
judge whether something is important for the operation of the
Internet.

> wire", maybe they were stricter about this in the past (guess).

You are not forced to use a Internet Standard protocol either, so I
don't buy this point.  There are multiple ways to do the same with
Internet Standards, and that's fine.  For comparison, GSS-API also
specifies an API, and it is on the standards track.

However, my point was not to argue which documents should be on the
standards track, just to show that many important and widely used
specifications are not on the standards track.

If the license for standards track and non-standards track are
different, this would be serious.  Now it seems only non-IETF
non-standards track documents have different licenses.  I don't really
know how to list which RFCs fall into this category...  it would be
interesting to find out if any widely used protocols are defined in
such documents.

> IETF vs. independent.

Not exactly right either, since some independent submissions are "IETF
products" too (i.e., go through a last call and IESG review).

/Simon

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 06 Aug 2006 18:03:01 +0200

todd glassey wrote:

>> Just keep it as simple as possible, and delete the part
>> identified by Bill as unused from BCP 78.
 
> How about we merge 78, 79 RFC2026 and a couple of others too?

That would be a rather long and hard to understand document.

Better extract relevant pieces, like the draft discussing
anything related to appeals.  For BCP 78 + 79 a similar
piece could be anything related to independent submissions
(= independent of the IETF, directly to the RFC editor).

Another piece could cover general contributions (anything
that's no I-D, like messages on mailing lists).  Another
part could be anything relevant for authors who didn't and
wont't patent the ideas they've published.

And a final part (or more) with the fine print for authors
sponsored by organizations interested in software patents.

For the two simple s/ISOC/IETF Trust/ proposals here I've
no idea which is "better", isn't that just a formality (?)

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 06 Aug 2006 19:00:08 +0200

> Not exactly right either, since some independent submissions
> are "IETF products" too (i.e., go through a last call and
> IESG review).

AFAIK that's called "individual submission", anything not from
a WG or the IAB (and others, but not including the IRTF at this
time).  

The xml2rfc (1.31) experimental.html page says:
| New <rfc submissionType="..."> attribute with values "IETF"
| (default) and "independent" (a.k.a. RFC Editor contribution).

Testing what it actually does I found that "independent" adds
"and at http://www.rfc-editor.org/copyright.html" to BCP 78 in
the copyright statement.

The next difference would be probably the publication request,
either to an AD / the IESG, or to the RFC editor (?)

Frank

---

From: "todd glassey" <[email-masked]>
Date: Thu, 6 Jul 2006 13:14:49 -0700

Frank the reason it is so long and hard to understand is that the collection
of documents were designed by people who don't understand contracts - the
documents try to both create contract terms for participation, but then they
go much farther and try framing the operations of the Organization in
response to those terms. That is the key problem with the current
documents - they are created as 'technical observations' as to some system,
and not as part of that systems processes.

The 'terms for participating and the participation contract' should be ONE
(1) document including all the ugly stuff no one wants to talk about like
the 'participants responsibilities' section, or the 'hold-harmless' section
as examples. Otherwise how can anyone - including any of the technical
wizards who walk on water herein be capable or even competent to develop an
understanding as to who owns what - something that in the real  world is the
basis of what is called Informed Consent - something critical to contracts
where property and intellectual property rights are transferred or protected
therein.

Todd

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 07 Aug 2006 10:21:23 +0200

> applies to it. 

In fact the "Status of this memo" section does define the status
of an RFC, but not its origin, which is the missing information
for non-standards-track, non-BCP documents.

I suggest this is a problem which this WG cannot fix - but this
WG could certainly send a strong recommendation to the IAB that
the RFC Editor should be requested to ensure that every future RFC
clearly indicates its origin, and that as far as possible, the index
should clearly indicate the origin of all RFCs.

    Brian

---

From: "todd glassey" <[email-masked]>
Date: Fri, 7 Jul 2006 05:22:16 -0700

Brian - the documents also need a revision code on them as well - this is
critical since RFC's are published with "Any and All" licenses against them,
so any use of an earlier version of a protocol or BCP needs to be able to
tie that use to a specific version of a document to uniquely identify the
version of the documents content's used in any effort.

Todd

---

From: Fred Baker <[email-masked]>
Date: Mon, 7 Aug 2006 13:14:15 -0700

huh? If a document is made a draft standard and later becomes  
historic, you're saying that the "status" section will indicate draft  
standard status and later historic status?

I understood that an RFC is a frozen point in time and is never  
changed in any way.

---

From: "todd glassey" <[email-masked]>
Date: Fri, 7 Jul 2006 14:16:56 -0700

Hey Fred - you have just demonstrated my point as to why the IETF's contract
documents need to be collapsed into a single document. If you as one of the
key experts here DONT KNOW these things off the top of your head then there
is an issue. Same for Brian and the rest of this entity...

Todd Glassey

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 08 Aug 2006 13:07:06 +0200

The origin of a RFC doesn't change.  RFCs are either produced through
the IETF process or they are not.  Re-classifying a RFC as historic
doesn't change where it came from, so the documents could contain a
note about its origin.

Without this information, it is more difficult and more unreliable to
find out exactly which license text applies to a particular document.

/Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Aug 2006 13:51:35 +0200

Correct - we can't change the text of an RFC once it's in the archive,
so any reclassification (advancing in the standards track, or
becoming Historic) can only be reflected in the index.

     Brian