Subject: #1167 Excerpt labelling

From: Harald Alvestrand <[email-masked]>
Date: Tue, 25 Apr 2006 13:51:56 +0200

Based on discussion in Dallas...

I suggest that we resolve this ticket by saying (in Joel's draft):

- All excerpts SHOULD be labelled with source - at least the RFC number 
or draft name - unless it's unreasonable in the context of the publication.

- For text that is modified from its original, the words "based on" or 
an equivalent SHOULD be included in the label - it MUST be made clear 
that the text is not the original text.

Resolution of this issue does NOT resolve what modified texts are 
permitted - just how they're labelled....

Comments?

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 25 Apr 2006 07:58:14 -0500

Hi, Harald,

> - All excerpts SHOULD be labelled with source - at least the RFC number or 
> draft name - unless it's unreasonable in the context of the publication.

A picky detail: you mean "at least RFC $number", don't you? I've been 
getting pushback from people when I just say "2026", etc.

A less picky non-detail: where did the "or draft name" come from? I wasn't 
in the meeting in Dallas ("doing real work"), but we sure haven't discussed 
this on the list that I saw. So, I'm OK with "or draft name" if a draft has 
NOT been published as an RFC, but since essentially all RFCs are published 
as drafts first, I'd at least include "RFC $number (or, if the text has not 
been published as an RFC, the draft name)" here.

> - For text that is modified from its original, the words "based on" or an 
> equivalent SHOULD be included in the label - it MUST be made clear that 
> the text is not the original text.

Maybe I've been seeing too many reviews of "Flight 93", but "based on a true 
story" doesn't quite capture the point for me - perhaps "a modification of" 
would be more obvious.

> permitted - just how they're labelled....

Always...

Spencer

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 25 Apr 2006 15:10:14 +0200

Spencer Dawkins wrote:

>> - All excerpts SHOULD be labelled with source - at least the RFC 
>> number or draft name - unless it's unreasonable in the context of the 
>> publication.
>
>

Good pick. I meant "RFC xxxx" - if some other discussions converge, we 
might even consider if we want "IETF RFC xxxx".

>
> A less picky non-detail: where did the "or draft name" come from? I 
> wasn't in the meeting in Dallas ("doing real work"), but we sure 
> haven't discussed this on the list that I saw. So, I'm OK with "or 
> draft name" if a draft has NOT been published as an RFC, but since 
> essentially all RFCs are published as drafts first, I'd at least 
> include "RFC $number (or, if the text has not been published as an 
> RFC, the draft name)" here.

I was thinking about excerpts from drafts. I'm pretty sure we want to 
permit those.

>
>
>> - For text that is modified from its original, the words "based on" 
>> or an equivalent SHOULD be included in the label - it MUST be made 
>> clear that the text is not the original text.
>
>
> Maybe I've been seeing too many reviews of "Flight 93", but "based on 
> a true story" doesn't quite capture the point for me - perhaps "a 
> modification of" would be more obvious.

Makes sense to me...

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 25 Apr 2006 15:52:15 +0200

todd glassey wrote:

>Harald - Does the IETF Claim an inherent claim to the TM say "RFC2026" for
>instance, just curiosity...
>  
>
If we had a trademark on the term "RFC", that would make some things 
simpler.
But we don't.

                          Harald

---

From: "todd glassey" <[email-masked]>
Date: Tue, 25 Apr 2006 06:47:01 -0700

Todd

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 25 Apr 2006 16:37:05 +0200

> permitted - just how they're labelled....

I like this, but doesn't it seem incompatible with a document that
invoke section 5.2 of RFC 3978?

   If the Contributor desires to eliminate the IETF's right to make
   modifications and derivative works of an IETF Contribution (other
   than translations), one of the two of the following notices may be
   included in the Status of Memo section of an Internet-Draft and
   included in a published RFC:
...
   b. "This document may not be modified, and derivative works of it may
      not be created."

I'm assuming here, which I believe is correct, that an "excerpt" is in
general a "derivative work".

Thanks,
Simon

---

From: "todd glassey" <[email-masked]>
Date: Tue, 25 Apr 2006 06:41:39 -0700

Harald... in response to the suggestion for Excerpt Labeling... "This
doesn't address the need to honor external copyright, TM,  or patent
filings."

The reason is that you MUST force the acceptance of the republishing rights
as offered, and that means the use of the term MUST in place of SHOULD. The
underlying reason is that the IETF cannot alter copyrights for other
documents which require the inclusion of a specific set of language in the
release.

Any and all externally controlled materials that are quoted or excerpted
MUST have their IP ground-rules and constraints observed in full otherwise
this compromises the integrity of the IP processes for including
externally-controlled IP into IETF processes.

Todd

----- Original Message ----- 
From: "Harald Alvestrand" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, April 25, 2006 4:51 AM
Subject: #1167 Excerpt labeling

> - All excerpts SHOULD be labeled with source - at least the RFC number
> permitted - just how they're labeled....
>
> Comments?
>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 25 Apr 2006 18:11:04 +0200

>invoke section 5.2 of RFC 3978?
I think this relates to #1166, not #1167, since the status of an excerpt 
is the same no matter what it's labelled - I've updated the subject line 
accordingly.

>general a "derivative work".
I'll leave Jorge to answer that.

If #1166 resolves the way I suggested, it means that we want to allow 
excerpts.
If Jorge says that excerpts are a kind of derived work, then we need to 
obsolete this part of 3978; if excerpts are not a derived work, there is 
no issue.

We're still at the stage of figuring out what rights the IETF wishes to 
grant; which parts of 3978 we have to update/obsolete  to get there is a 
later step.

                          Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Apr 2006 14:12:29 +0200

>    b. "This document may not be modified, and derivative works of it may

Ah, but then it isn't what I think of as an IETF RFC. So I suspect that
the IETF doesn't care. The RFC Editor may care, but that is a separate
issue.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Apr 2006 14:30:10 +0200

> might even consider if we want "IETF RFC xxxx".

Given that www.acronymfinder.com finds 57 meanings for RFC, I think we'd
better require "IETF RFC". Also, since the IETF can't claim any rights
in RFCs not published via the IETF process, this distinction is important
in its own right. (An interesting challenge is to find out algorithimically
which RFCs published since January 1986 are in fact IETF RFCs.)

>> RFC, the draft name)" here.

Internet-Drafts all carry the phrase 'It is inappropriate to use
Internet-Drafts as reference material or to cite them other than
as "work in progress."' So it is very unclear to me whether we
should even mention them in a way that appears to sanction
referring to them except as a "work in progress" reference.

> I was thinking about excerpts from drafts. I'm pretty sure we want to 

See John Klensin's comments on #1166.

>> modification of" would be more obvious.

Or "translated from the original English" if appropriate.

    Brian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 27 Apr 2006 07:33:33 -0500

> the IETF doesn't care. The RFC Editor may care, but that is a separate

I'm looking a couple of paragraphs further down:

   These notices may not be used with any standards-track document or
   with most working group documents, except as discussed in Section 7.3
   below, since the IETF must retain change control over its documents
   and the ability to augment, clarify and enhance the original IETF
   Contribution in accordance with the IETF Standards Process.

I'm assuming that the relevant part of 7.3 is

   The right to produce derivative works is required for all IETF
   standards track documents and for most IETF non-standards track
   documents.  There are two exceptions to this requirement:  documents
   describing proprietary technologies and documents that are
   republications of the work of other standards organizations.

So it looks like any standards-track RFC, or any informational RFC that 
isn't (1) a proprietary technology or (2) published by another SDO, that 
contains this limitation would be an error. I wish I had time to check for 
this, of course, but believe that I agree with Brian here.

Thanks,

Spencer

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 27 Apr 2006 15:26:13 +0200

Brian E Carpenter <[email-masked]> writes:

> the IETF doesn't care.

Ah, yes, right.

However, RFC 3978 does not seem to completely preclude IETF RFC's from
carrying those notices:

It says nothing about documents with status INFORMATIONAL.

I cannot find any published RFC that invoke 5.2 b)...

This may be a corner-case now, and might not be worth spending more
time on.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 27 Apr 2006 15:57:14 +0200

"Spencer Dawkins" <[email-masked]> writes:

> So it looks like any standards-track RFC, or any informational RFC
> that isn't (1) a proprietary technology or (2) published by another
> SDO, that contains this limitation would be an error. I wish I had
> time to check for this, of course, but believe that I agree with Brian
> here.

When I read those two paragraphs, it doesn't seem like Informational
RFCs (a non-standards track maturity level) are prevented from
carrying those notices, even if it isn't (1) or (2).

The first paragraph says that standards-track/WG document cannot carry
the notices, except for some cases explained in 7.3.  So the first
paragraph doesn't say anything about informational documents.

/Simon

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 27 Apr 2006 09:24:58 -0500

I know very clearly that I don't understand everything that goes on around 
here (for any interesting defintion of "around here"), but ...

From: "Simon Josefsson" <[email-masked]>

> paragraph doesn't say anything about informational documents.

At least at the steady state (ignoring what may have happened pre-RFC 3978), 
I think Brian was saying, "well, if it's not a standards-track RFC, and no 
working group adopted it, do we care about it?"

Which does make me wonder about AD-sponsored Informationals, which seem like 
they would slide through this crack, but I'll ignore that and go back to my 
day job (and this isn't my day job)...

Thanks,

Spencer

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 27 Apr 2006 17:04:45 +0200

"Spencer Dawkins" <[email-masked]> writes:

> At least at the steady state (ignoring what may have happened pre-RFC
> 3978), I think Brian was saying, "well, if it's not a standards-track
> RFC, and no working group adopted it, do we care about it?"
>
> Which does make me wonder about AD-sponsored Informationals, which
> seem like they would slide through this crack, but I'll ignore that
> and go back to my day job (and this isn't my day job)...

This may very well be a corner case, but my RFC 3548 and RFC 4027 are
two documents in that corner.

Both are technical documents, not proprietary or published by another
SDO, they have the Informational maturity level (for reasons I no
longer recall, or never understood, in retrospect probably because
publishing a non-WG standards track document was too difficult), went
through technical review by the IETF and the IESG, but there were no
appropriate WG for it.

About a third of the published RFCs since RFC 3000 appear to be
"informational".  I don't know how many of them were non-WG documents,
but I'd be surprised of there weren't many of them.

/Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Apr 2006 17:21:19 +0200

Spencer Dawkins wrote:
> I know very clearly that I don't understand everything that goes on 
> around here (for any interesting defintion of "around here"), but ...
> 
> Which does make me wonder about AD-sponsored Informationals, which seem 
> like they would slide through this crack, but I'll ignore that and go 
> back to my day job (and this isn't my day job)...

This is one of the cracks in RFC 2026 in fact, but I would say a working
definition of an IETF RFC is one that has been approved by the IESG
or IAB. That consciously excludes IRTF documents and individual submissions
to the RFC Editor.

      Brian

---

From: "todd glassey" <[email-masked]>
Date: Thu, 27 Apr 2006 11:21:23 -0700

----- Original Message ----- 
From: "Spencer Dawkins" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, April 27, 2006 7:24 AM
Subject: Re: #1167 Excerpt labelling

> >>>>    b. "This document may not be modified, and derivative works of it

Which prevents the IETF or anyone from implementing this protocol as well.
Was that the intent? Without the derivative works licenseing, the ports
cannot be documented.

> >>   Contribution in accordance with the IETF Standards Process.

So then if the document's sponsor's have declared their effort as a
standards track effort, then what? - how does this change these rules? It
seems to me that all IETF efforts are supposed to be standards track efforts
and the failing of the IETF to force this disctinction is how we got to
where we are today. The IETF exists to create Internet Standards not BCP's
or Audit Guideline Statements, or Chicken Sandwhich Recipes for that matter.
The point is that the IETF is a Standards Body and nothing less would be of
use to the world. Further if the IETF wants to become something other than a
Standards Body alone, then it needs to get permission from those that
created it and represent itself as such.

> >>   republications of the work of other standards organizations.

No - ANYTHING that is published as a standard needs derivative works rights
against the entire standard... which eliminates the use of other IP in IETF
Standards. Sorry - its just the way it is.

> At least at the steady state (ignoring what may have happened pre-RFC
3978),
> Which does make me wonder about AD-sponsored Informationals, which seem
like