headers
todd glassey | 4 Aug 2006 22:51
Picon
Favicon

Re: problems caused by rules-update-07

Yo Frank - all
----- Original Message ----- 
From: "Frank Ellermann" <nobody <at> xyzzy.claranet.de>
To: <ipr-wg <at> ietf.org>
Sent: Saturday, July 29, 2006 2:34 PM
Subject: Re: problems caused by rules-update-07

> 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.

So then why the Trust at all?

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

>
> 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Simon Josefsson | 6 Aug 2006 11:48

Re: Terms used in rules-update-07

"Bill Fenner" <fenner <at> gmail.com> writes:

> On 7/29/06, Simon Josefsson <jas <at> extundo.com> 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
Permalink | Reply | 0 comments |
headers
Simon Josefsson | 6 Aug 2006 12:19

Re: problems caused by rules-update-07

"Contreras, Jorge" <Jorge.Contreras <at> wilmerhale.com> writes:

>> Given that we don't know what the outbound license from the IETF
>> should be, I believe we shouldn't restrict the IETF Trust from
>> following the IETF's wishes in this area.
>
> This is not being restricted.  I agree that there are some outbound
> rights on which consensus has not been reached, but these are being
> neither precluded nor permitted by this draft.

The draft do restrict the IETF Trust from releasing rights to
documents that the IETF later on decides that it would be a good thing
to have released the rights to.

It is two-sided sword: either give the IETF Trust too much power, or
give it too little so it cannot later on carry out the IETF's wishes.

This affect rights granted to IETF Participants too.  If it later on
turns out that rules-update-07 does not grant the IETF Trust nor IETF
Participants sufficient rights to publish an updated version of a
document within the IETF, we will have to rewrite the document to move
forward.

/Simon
Permalink | Reply | 0 comments |
headers
Simon Josefsson | 6 Aug 2006 12:11

Re: Terms used in rules-update-07

Frank Ellermann <nobody <at> xyzzy.claranet.de> writes:

> 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".

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.

>> 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
(Continue reading)

Permalink | Reply | 8 comments |
headers
Frank Ellermann | 6 Aug 2006 18:03
Picon
Picon

Re: problems caused by rules-update-07

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
Permalink | Reply | 0 comments |
headers
Frank Ellermann | 6 Aug 2006 19:00
Picon
Picon

Re: Terms used in rules-update-07

Simon Josefsson wrote:

>>> 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.

> 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
Permalink | Reply | 0 comments |
headers
Brian E Carpenter | 7 Aug 2006 10:21
Picon
Favicon

Origin of RFCs [Re: Terms used in rules-update-07]


> 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. 

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
Permalink | Reply | 6 comments |
headers
Todd Glassey | 7 Aug 2006 18:49
Picon
Favicon

Re: Origin of RFCs [Re: Terms used in rules-update-07]

Pardon my jumping in again - but since the IETF sort of has some subliminal idea that people will want to keep
up to snuff (up to date) with the latest and greatest release of an RFC's description, but since there are
also no real test plans or release confirmation/interoperability models from release to release, it
makes it really really important to be able to track a specific protocol instance to a RFC instance, and
without the versioning number ... well - we all have experience with code-managment without proper
Collaboration tools.

T.

-----Original Message-----
>From: todd glassey <tglassey <at> earthlink.net>
>Sent: Jul 7, 2006 5:22 AM
>To: Brian E Carpenter <brc <at> zurich.ibm.com>, Simon Josefsson <jas <at> extundo.com>
>Cc: ipr-wg <at> ietf.org
>Subject: Re: Origin of RFCs [Re: Terms used in rules-update-07]
>
>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
>----- Original Message ----- 
>From: "Brian E Carpenter" <brc <at> zurich.ibm.com>
>To: "Simon Josefsson" <jas <at> extundo.com>
>Cc: <ipr-wg <at> ietf.org>
>Sent: Monday, August 07, 2006 1:21 AM
>Subject: Origin of RFCs [Re: Terms used in rules-update-07]
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fred Baker | 7 Aug 2006 22:14
Picon
Favicon

Re: Origin of RFCs [Re: Terms used in rules-update-07]

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.

On Aug 7, 2006, at 1:21 AM, Brian E Carpenter wrote:

>
>> 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.
>
> 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
>
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wg <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ipr-wg
(Continue reading)

Permalink | Reply | 4 comments |
headers
Simon Josefsson | 8 Aug 2006 13:07

Re: Origin of RFCs [Re: Terms used in rules-update-07]

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

Fred Baker <fred <at> cisco.com> writes:

> 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.
>
> On Aug 7, 2006, at 1:21 AM, Brian E Carpenter wrote:
>
>>
>>> 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.
>>
>> 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.
>>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane