Subject: comments on ipr-submission-rights-06

From: Pekka Savola <[email-masked]>
Date: Sat, 12 Jul 2003 15:01:19 +0300 (EEST)

Hi,

Sorry for missing the WG LC deadline, but luckily enough these comments 
aren't show-stoppers, just clarifications etc.  The issues in the 
definitions apply equally to the other documents as well, of course.

substantial
-----------

   f. "RFC Editor Contribution": An Internet-Draft intended by the    
      Contributor to be submitted to the RFC Editor for publication as 
      an Informational or Experimental RFC but not intended to be part
      of the IETF Standards Process.

==> I don't genuinely understand this.  Are all submissions direct to the 
RFC-Editor RFC Editor Contributions (even though they wouldn't be 
proprietary protocols, republication of other SDOs' work, etc.)?  The 
latter part of the definition might suggest that some I-D's submitted to 
RFC-ed might actually be intended to be part of the IETF Standards 
Process.

I wonder if this should be clarified or that I'm just confused..

      (C) unless explicitly disallowed in the notices contained in an 
         Contribution [as per Section 5.2 below], to prepare derivative
         works (other than translations) that are based on or
         incorporate all or part of the Contribution, or comment upon   
         it, within the IETF Standards Process, the license to such
         derivative works to be of a scope no wider than the license to
         the original Contribution, and

==> I'm having trouble parsing the intent of "of a scope no wider than the 
license to the original Contribution".  How could the license to be of 
wider scope?

5.3 Publication Limitation

   If the Contributor only wants the IETF Contribution to be made
   available as an Internet-Draft (i.e. does not want the IETF
   Contribution to be published as an RFC) then the Contributor may 
   include the following notice in the Status of Memo section of the
   Internet-Draft.

      "This document may only be posted as an Internet-Draft."

   This notice can be used on IETF Contributions that are intended to
   provide background information to educate and to facilitate
   discussions within IETF working groups but are not intended to be
   published as an RFCs.

==> I fail to see *any* valid use for this policy, and it seems totally 
useless.  It's not as if someone would publish your I-D as RFC without 
your approval.  And if you don't want to do that, you can put the "no 
derivative works" on it anyway.

Can anyone think of cases where this may be useful?

semi-editorial
--------------

   b. "IETF Standards Process": the activities undertaken by the IETF in
      any of the settings described in 1(c) below.

   c. "IETF Contribution": any submission to the IETF intended by the
       Contributor for publication as an Internet-Draft or RFC (except
      for RFC Editor Contributions described below) and any statement
      made within the context of an IETF Standards Process. [...]

==> there appears to be a slight circular definition wrt. IETF Standards 
Process.  A slight rewording might fix that?

      Statements made outside of an IETF session, mailing list or other
      function, that are clearly not intended to be input to an IETF
      activity, group or function, are not Contributions in the context
      of this document.

==> is the choice of "Contributions" intentional, or should this be "IETF 
Contributions" ?

   No information or document that is subject to any requirement of
   confidentiality or any restriction on its dissemination may be
   submitted as an Contribution or otherwise considered in any part of
   the Standards Process, and there must be no assumption of any

==> s/Standards Process/IETF Standards Process/ (following the definitins 
section...)

4.2   Granting of Rights and Permissions

   By submission of an Contribution, each person actually submitting the
   Contribution, and each named co-Contributor, is deemed to agree to
   the following terms and conditions, and to grant the following
   rights, on his or her own behalf and on behalf of the organization   
   the Contributor represents or is sponsored by (if any) when
   submitting the Contribution.

==> there is a lot of text duplication in 4.2; it's basically section 3.3 
with one sentence modified and some cases missing.  This may be good for 
understanding the bigger picture of RFC-Ed. contributions, but one might 
also be able to reword it slightly.

         "Copyright (C) <year> The Internet Society.  This version of   
         this MIB module is part of RFC XXXX;  see the RFC itself for
         full legal notices."

         "Copyright (C) <year> The Internet Society.  The initial
         version of this MIB module was published in RFC XXXX; for full
         legal notices see the RFC itself or see:
         http://www.ietf.org/copyrights/ianamib.html."

==> note that elsewhere the format of the ISOC copyright is:

      "Copyright (C) The Internet Society (year). This document is

   .. we should have only one way of putting it, and unless there are 
specific reasons, I think the latter is probably more commonplace.

   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.

==> one could add something like below to the end:

   These cases are described at more length below.

   Certain documents, including those produced by the U.S. government  
   and those which are in the public domain, may not be protected by the
   same copyright and other legal rights as other documents.
   Nevertheless, we ask each Contributor to grant to the IETF the same
   rights as he or she would grant, and to make the same
   representations, as though the IETF Contribution were a proprietary
   document.

==> am I confused or is "proprietary document" used to refer to all
non-public domain and non-USgovt contributions [or documents which no
change control is given, I'm assuming the former]?  This conflicts with
the other use of "proprietary documents" in the memo, and should be
reworded.
 
editorial:
----------

3. Rights in IETF Contributions

   The following are the rights the IETF requires in all IETF
   Contributions:.

==> remove either the : or .

      removed.  Note that Internet-Drafts are archived many places on 
      the Internet, not all of these places remove expired Internet-   
      Drafts.  Internet-Drafts that are under active consideration by

==> s/not all/but not all/

  submitted as an Contribution or otherwise considered in any part of

==> s/an Contribution/a Contribution/g (a lot of this)

   a. To the extent that an Contribution or any portion thereof is 
      protected by copyright and other rights of authorship, the   
      Contributor, and each named co-contributor, and the organization
      he or she represents or is sponsored by (if any) grant a
      perpetual, irrevocable, non-exclusive, royalty-free, world-wide
      right and license to the ISOC and the IETF under all intellectual 
      property rights in the Contribution.

      (A) to copy, publish, display and distribute the Contribution as
         part of the IETF Standards Process or as an Internet-Draft,

==> s/Contribution./Contribution:/

3.4  Representations and Warranties.

==> s/s./s/

   c. There are no limits to the Contributor's ability to make the

   d.  The Contributor has not intentionally included in the

   e.  All trademarks, trade names, service marks and other proprietary

==> s/d.  /d. /
==> s/e.  /e. /

   The following are the rights the IETF, as the publisher of Internet-
   Drafts, requires in all RDC Editor Contributions:

==> s/RDC/RFC/

      (B) unless explicitly disallowed in the notices contained in an
         Contribution (as per Section 5.4 below), to prepare derivative
         works (other than translations) that are based on or   
         incorporate all or part of the Contribution, or comment upon it
         the license to such derivative works to be of a scope no wider
         than the license to the original Contribution, and

==> should 5.4 have been 5.2 ?
==> "or comment upon it the license [...]" ==> something missing from 
editing out the difference to 3.3 a(B) ? :-)

5.2 Derivative Works Limitation

   If the Contributor desires to eliminate the IETF's right to make
   modifications and derivative works of an Contribution (other than
   translations), one of the two the following notices may be included  
   in the Status of memo section of an Internet-Draft and included in a
   published RFC:

==> s/memo/this Memo/
==> s/a published RFC/the published RFC/ ? (are there really any RFC's 
except april 1 ones which haven't been published as I-D's first??)

5.6 Exceptions.

==> s/s./s/

   There are security considerations when adopting any technology.  But
   there are no known issues of security with IETF Contribution rights
   policies.

==> s/.  But/, but/

   [RFC 2026]  Bradner, S.[ed], "The Internet Standards Process --
      Revision 3", RFC 2026, October 1996

   [RFC 2418] Bradner, S. (ed), "Working Group Guidelines and
      Procedures", RFC 2518, September 1998

   [IETF IPR] Bradner, S.[ed] "Intellectual Property Rights in IETF
      Technology", work in progress: draft-iprwg-technology-00.txt

==> there seem to be two styles to add (ed) or [ed]
==> s/.[ed]/. [ed]/
==> the last one's I-D name is wrong.

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

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

---

From: Scott Bradner <[email-masked]>
Date: Sat, 12 Jul 2003 08:48:29 -0400 (EDT)

responses to some of the notes - the rest I'll just fix in the text

> substantial

I'm not sure how to clarify - the point is that an RFC Ed contribution
is an ID that is not intended to be a part of the IETF stds process
I do not see how you could read into the text what you do

please suggest text to clarify

> license to the original Contribution".  How could the license to be of 

the intent is to say that the non-exclusive licence granted by the
author is not changed by the creation of a derivative work

> Can anyone think of cases where this may be useful?

this has been used a number of times - one example use is called out in
sec 7.3 of the ID (see 4th paragraph of sec 7.3) 

[ some comments skipped }

> ==> is the choice of "Contributions" intentional, or should this be "IETF 

I tried to be careful in the use of "Contributions" vs "IETF Contributions"
and "RFC Editor Contributions" but I'll check them all

[ some comments skipped }

> the other use of "proprietary documents" in the memo, and should be

the intent is to say that we are asking for the authors of those documents,
like the US government docs, to follow the same process as for other documents

please suggest text if that is not clear

Scott

---

From: John C Klensin <[email-masked]>
Date: Sat, 12 Jul 2003 10:12:08 -0400

--On Saturday, 12 July, 2003 08:48 -0400 Scott Bradner 
<[email-masked]> wrote:

>...
>>    f. "RFC Editor Contribution": An Internet-Draft intended
>>    by the     Contributor to be submitted to the RFC Editor
>>       for publication as  an Informational or Experimental
>>       RFC but not intended to be part of the IETF Standards
>>       Process.
>>
>> ==> I don't genuinely understand this.  Are all submissions
>> direct to the  RFC-Editor RFC Editor Contributions (even
>> though they wouldn't be  proprietary protocols, republication
>> of other SDOs' work, etc.)?  The  latter part of the
>> definition might suggest that some I-D's submitted to  RFC-ed
>> might actually be intended to be part of the IETF Standards
>> Process.
>>
> I'm not sure how to clarify - the point is that an RFC Ed
> contribution is an ID that is not intended to be a part of the
> IETF stds process I do not see how you could read into the
> text what you do
>

Pekka, please remember that the procedures give the IESG the 
ability to say to the RFC Editor "regardless of how that 
document was presented, and whether that was intentional or 
unintentional, it has an interaction with the standards process 
and we want to refer it to WG XYZ".  In practice, that is the 
end of any plan about RFC publication unless the WG signs off. 
So, if I understand the problem you are concerned about, it 
isn't a problem.

But I may not understand your concern.

   john

---

From: Pekka Savola <[email-masked]>
Date: Sat, 12 Jul 2003 18:13:42 +0300 (EEST)

> But I may not understand your concern.

My fundamental confusion stems from the fact that AFAICS, there is no way 
a random guy reading the Internet-Draft can know whether it is a 
"RFC Editor I-D" or "IETF I_D", and consequently, cannot know which rights 
have been given (e.g. can he translate it (can't do with RFC Ed I-D's), or 
extract MIB/PIB modules from it).

Is there something I'm missing?

Or are "RFC Editor Internet-Drafts" used to refer to those theoretical 
I-D's which have never been submitted to [email-masked] 
(doubtful)?

---

From: Scott Bradner <[email-masked]>
Date: Sat, 12 Jul 2003 11:22:04 -0400 (EDT)

> Is there something I'm missing?

in general I (for one) know when I write a ID if I'm going to submit 
it to a IETF WG (or try to get a WG going based on it) or if I'm
just going to ask the RFC Editor to publish it as an info or exp RFC

> I-D's which have never been submitted to [email-masked] 

all IDs go through [email-masked]

Scott

---

From: Pekka Savola <[email-masked]>
Date: Sat, 12 Jul 2003 18:32:22 +0300 (EEST)

> just going to ask the RFC Editor to publish it as an info or exp RFC

You may know, but what about those who can't read your mind? :-)

Really, it *seems* to be a bit of a difficult decision to make.   Today, 
in some contexts I've seen at least a few cases where the author intends 
to have an I-D as part of the IETF Standards Process, but the contribution 
is not accepted as part of that (for any reason), and then turns to RFC 
Editor to make it an RFC Editor contribution.

This could even be the same revision of the I-D.

So, it seems to me that it's difficult to make the distiction, especially 
a distinction that the others would notice too.  (A "solution" would be to 
make this distinction formal, and require different kinds of boilerplates 
for different types of I-D so it would be clear what the specific rev of 
I-D is, but I'm not sure whether that'd fix all the problems.)

---

From: Pekka Savola <[email-masked]>
Date: Sat, 12 Jul 2003 19:01:43 +0300 (EEST)

> responses to some of the notes - the rest I'll just fix in the text

Thanks.

> author is not changed by the creation of a derivative work

Ok; so is the scenario this is done for is "if I make a contribution which 
allows derivative works, derivative works from that must also allow 
derivative works" ?

In that case, I'd say "narrower", not "wider"?

Or are you referring to other licenses granted by a contribution (e.g. 
that with derivative works, one doesn't guarantee free use of 
trade/service marks, IPR, etc.) ?

Is there a problem of just saying that the license must be the same? 
(Could be simpler that way..)

> sec 7.3 of the ID (see 4th paragraph of sec 7.3) 

Yes, I noticed that.  But my point is that AFAICS, the limitation not to 
publish I-D as RFC is only a subset of "no rights to create derivative 
works" -- and that if you're worried about those cases listed in 4th para 
of 7.3, I'd imagine everyone would want to have the "no rights to create 
derivative works" anyway -- thus making the "no RFC publication" seems 
redundant and useless.

Are there some cases where this does not hold?

> please suggest text if that is not clear

In:

   document.  We ask for these grants and representations only to the

replace:

   representations, as though the IETF Contribution were a proprietary
   document.  We ask for these grants and representations only to the

with:

   representations, as though the IETF Contribution were protected by the 
same legal rights as other documents, and as though the Contributor could 
be able to grant these rights. We ask for these grants and representations 
only to the

and continuing, in:

   extent that the IETF Contribution may be protected. We believe they
   are necessary to protect the ISOC, the IETF, the IETF Standards
   Process and all IETF participants, and also because the IETF does not
   have the resources or wherewithal to make any independent
   investigation as to the actual proprietary status of any document
   submitted to it.

replace the two last lines with:

   investigation as to the actual copyright and other legal right status 
   of any document submitted to it.