Subject: last call on several documents

From: Steve Bellovin <[email-masked]>
Date: Wed, 23 Apr 2003 12:18:45 -0400

It's time for a working group last call on the three charter-mandated 
documents:

	draft-ietf-ipr-submission-rights-04.txt
	draft-ietf-ipr-technology-rights-05.txt
	draft-ietf-ipr-wg-guidelines-03.txt

Does anyone have any final change requests for these documents?  (Note:
given that the charter calls for these documents to clarify the 
current IPR policy; objections to them on the grounds that they don't
call for RF are out of scope.)

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 24 Apr 2003 11:18:55 +0300 (EEST)

On Wed, 23 Apr 2003, Steve Bellovin wrote:
> Does anyone have any final change requests for these documents?

In summary, I think technology rights and wg guidelines should be revised 
and submission rights is pretty close to OK.

Submission rights:
------------------

 * pretty much OK
 * in places, editorial quality could be better
 * there are two instances of section 12

Technology rights:
------------------

 * see the first two bullets above
 * A few problems

6.1.1  A Contributor's IPR in his or her Contribution
   Any Contributor who reasonably and personally knows of IPR meeting
   the conditions of Section 6.6 which the Contributor believes Covers
   or may ultimately Cover his or her Contribution, or which the
   Contributor reasonably and personally knows his or her employer or
   sponsor intends to enforce against Implementing Technologies based on
   such Contribution, must make a disclosure in accordance with this
   Section 6.

==> "intends to enforce against Implementing Technologies" seems very
subjective.  Shouldn't a disclosure be always necessary even when (with
the current knowledge of a contributor), there is no intention to enforce
it at the moment?  What is the purpose of this particular case? Seems like
a potential loophole.  Similar in 6.1.2.

6.3  How must a disclosure be made?
   IPR disclosures are made by following the instructions at
   http://www.ietf.org/ipr-instructions.

==> no such instructions exist (gives a 404)

11.  No IPR disclosures in IETF documents
[...]
   Contribution.  (http://www.ietf.org/ipr/)

==> this doesn't exist, it's /ipr or /ipr.html 
(as strange as it seems)

wg-guidelines
-------------

 * a few comments:

   This memo lays out a conceptual framework and rules of thumb useful
   for working groups dealing with IPR issues. It documents specific
   examples of how IPR issues have been dealt with in the IETF.

==> spell out IPR.

==> it would be best to include also like the following at the end of the 
abstract:

 "The document does not make rules on how IPR issues must be dealt with in
the working groups, or give recommendations on how they should be done in
the future."

(the first part is IMO more important than the last one) -- slightly 
similar in the introduction.

   This memo lays out a conceptual framework and rules of thumb to
   assist working groups dealing with IPR issues.  The goal is to
   achieve a balance between the needs of IPR claimants and the
   implementers of the Internet which is appropriate to current times.

 ==> missing "standards" around Internet ? (is there a more generic term 
applicable here also including exp/info..)

5. General Principles

==> I recommend adding a sub-paragraph, like:

5.1 General Policy

   In all matters of intellectual property rights, copyright, and
   document procedures, the intent is to benefit the Internet community 
   and the public at large, while respecting the legitimate rights of 
   others [2].

   In particular, the working groups should also consider the impacts of 
   their decision from the point of view of the Internet community and the 
   public at large, including also those possible future implementers and  
   users which do not participate in the working group process when the 
   standardization is taking place.

(I want to highlight that what seems to have happened in CDI is not in 
general acceptable: "we know each other, licensing is ok for all of us" 
does not give any consideration to those who are not *at the moment* 
participating (and which might result in being blocked out.)

5.3 IPR as a Technology Evaluation Factor

==> I'm not satisfied with this section.  In particular, I dislike the 
third paragraph:

   Similarly, when evaluating a technology, working group participants
   consider IPR claims on it (including possible copyright issues with
   text describing it).  The issue is not whether a particular piece of
   technology is IPR-impacted -- we use IPR-impacted technology every
   minute.  The question is how much the IPR protection will limit the
   technology's usefulness in building a robust, highly useful Internet.
   Thus, the only significant questions are: is the IPR claim relevant,
   and if so what are the terms under which the technology can be used?
   When technology is free from IPR protection the answer is easy.  When
   it is IPR-impacted, some terms make the IPR issues insignificant
   compared to the engineering issues.  Other terms can make a  
   technology unusable even if it is perfect otherwise.

.. as this seems too "recommendative" to me, in addition to downplaying 
the implications of IPR.

  beforehand (see Section 5.7.1). third-party disclosure is a potential

==> s/third/Third/

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Apr 2003 12:11:09 +0200

I have no problems with the documents as they stand, although
most of Pekka's comments would improve them. I disagree with Pekka
on a couple of points:

Pekka Savola wrote:

...
> a potential loophole.  Similar in 6.1.2.

I don't see the problem. The two conditions are joined by "or". If you know of
a relevant claim, *or* if you know of a claim that your company intends 
to enforce, you must disclose. The first part covers all relevant claims
you know about; the second part expands the scope to cover cases where
you may not believe the claim is relevant, but your company's IPR department
has a different opinion.

...
> .. as this seems too "recommendative" to me, in addition to downplaying

Don't agree. I think this is fine. It attempts to point out that it
isn't the existence of IPR that's a problem (if it is we can just go
home now). It attempts to point out that if IPR is both relevant
and only available under onerous terms, you have to think carefully.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Thu, 24 Apr 2003 15:00:22 +0300 (EEST)

> you may not believe the claim is relevant, but your company's IPR department

Ok, with further thinking this seems reasonable -- however, I'd really
like splitting the sentence down a bit, so that different key issues (3 it
seems) would be even clearer.  Perhaps a bullet list?

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 24 Apr 2003 11:54:32 -0400

In message <[email-masked]>, Steve Bellovi
>call for RF are out of scope.)

It's been pointed out that I forgot to specify the end of the Last Call 
period.  It will run for two weeks, until May 7.

---

From: John C Klensin <[email-masked]>
Date: Thu, 24 Apr 2003 17:57:29 -0400

Since most of the energy in the last several months seems to 
have gone into the IPR document, I decided to take a careful 
look at "submission rights".  I think it needs more attention.

One major issue is that it uses terms like "within the IETF 
process", "IETF documents", and "submissions to the IETF" 
without precisely defining any of those terms (at least where 
I've been able to find the definitions).  Unless we want to have 
future arguments about whether every mailing list posting must 
bear an explicit copyright transfer to ISOC, etc., we need to 
clarify these terms.  Attempts at some of the definitions appear 
in section 4, but it is customary to define terms _before_ they 
are used, or at least to include forward pointers to the 
definitions, rather than using the terms and then defining them, 
more or less, some sections later.

The I-D issue is even more important.   We have claimed for some 
time that Internet Drafts expire after six months.   The notion 
of expiration is meaningless in the presence of a permanent and 
irrevocable transfer of rights to reproduce and disseminate to 
ISOC. And, given that six month principle, there is no 
justification for a sweeping and permanent transfer under the 
principle of "benefit the Internet community and the public at 
large, while respecting the legitimate rights of others" much 
less the even stronger statement of 5.1.   Instead, IMO, this 
document should more clearly differentiate between working 
documents (I-Ds and, perhaps, document-like contributions to 
mailing lists) and archival documents (e.g., RFCs).  Similarly, 
it may be useful to distinguish between documents that are 
intended as contributions to something going on in a WG, or to 
some process that is intended (or hoped) to produce some 
standards-track actions, and individual contributions intended 
for the general information of the community about work or 
thinking that is not directly "IETF-as-SDO" related.

For those latter documents, the best interests of the community 
may well be served by encouraging maximum exposure, even if for 
a limited period.   And that goal may be best served in some 
cases --without harm to our principles if we believe in the "six 
month" rule-- by requiring copyright transfers and long-term 
dissemination and (usually) derived work rights only late in the 
process.  A requirement for statements in an I-D of intent (and 
obligation) to grant those rights if ISOC or the RFC Editor 
decides to publish archivally, and permission for ISOC, IETF, or 
the RFC Editor to make that decision, would be quite reasonable. 
To require these transfers of rights at first I-D submission 
time is not reasonable and is not consistent with the notion of 
a six-month timeout.

These issues, and the definitional one, seem to require 
reexamination, and possibly changes, to the following sections 
of the document (there may be others, depending on the intent of 
some of the undefined terms and vague language):

2.2 "Any restriction on its dissemination"

2.3a "perpetual, irrevocable,... under all intellectual property 
rights..."

2.3a(A) "part of the IETF standards process" is not defined in 
this context, and may be either too narrow or too broad.  Note 
that section 4 seems to define anything discussed in any IETF 
context as part of the standards process.

2.3a(B) makes a forward reference to section 3.3.  There is no 
section 3.3.  If section 3.2 is intended, see the note on 
section 4 below.

2.4 For Internet-Drafts, some of these provisions, particularly 
that of free disclosure of any information, should be revocable 
on expiration of the document.  (Editorially, I don't believe 
that provision belongs in this section -- it is a grant of 
rights, while the rest of the section  (and its title) is about 
representations and warranties.)

3.  This section applies (only?) to "IETF documents" without a 
clear prior definition of what documents do and do not fall into 
that category (a definition does appear in section 4, but it 
defines _all_ I-Ds as IETF documents).  The first real paragraph 
("The IETF requires...") is a nice statement of principle, but 
is inconsistent with 3.1.1 and 3.1.2, which don't say a word 
about primary ISOC copyright claims on some aspects of the 
document, and which do assert _exclusive_ ISOC copyright (given 
the prohibition on "additional copyright notices" statement of 
the next paragraph and the "no dual or joint copyrights, 
unless..." notes that appear elsewhere).

It is my impression that there is controversy in the digital 
rights community as to whether copying a document from one 
medium to another constitutes a modification.   It would be well 
to review the boilerplate carefully to be sure it is robust 
against possible future interpretations and would prohibit some 
forms of dissemination that we want to encourage on the grounds 
that they constituted "modification" of the document in some way.

3.2(c) ("does not provide the IETF with any rights other than to 
publish as an Internet-Draft...") is inconsistent with the 
grants of copyright and unlimited and permanent dissemination 
rights in the earlier sections.   We should not require grants 
of rights that we don't need -- that is inconsistent with both 
the best interests of the community and preserving maximum 
rights for authors.   Also, we have repeated insisted elsewhere 
that Internet-Drafts are not "published" but rather "posted". 
It has been my understanding that having the IETF act as the 
"publisher" of an Internet Draft may create some 
responsibilities and risks that we neither want nor need.

Also in 3.2, a narrow reading of our publication and approval 
process, especially in conjunction with 
draft-rfc-editor-rfc2223bis-04.txt, would define "submitted for 
Standards Track publication" as applying only to the drafts of 
the documents actually forwarded to the IESG for review and 
approval and not to any earlier draft.   It could be read even 
more narrowly as describing only those documents which the IESG 
forwards to the RFC Editor with a request/instructions for 
publication on the Standards Track.   Our intent is probably 
broader and there is no reason why this text should be the 
slightest bit ambiguous.

While the job has not been assigned to this WG (the IESG and the 
appropriate AD are invited to take that as a hint), I believe 
that the 2223bis document should be verified to be consistent 
with this one and with our intent. At present, it is not 
(comments have already been sent to the relevant parties as part 
of the Last Call process).

And I continue to contend that it should be possible to post an 
I-D with a "no rights other than to post or to consider for RFC 
publication, with required additional rights to be granted if 
the decision is make to publish it" statement, essentially 
midway between (b) and (c).

4. These definitions are somewhat circular.  Moreover, they can 
be read, in conjunction with previous sections, as requiring IPR 
(technology) signoffs, etc., on every single "contribution" 
including, possibly, this note. If 2.3a(B) really refers to 3.2, 
it implies, along with these definitions, that one of those 
statements can be (perhaps is required to be) included with 
every contribution, even though 3.2 itself requires that text 
only for I-Ds.  Similarly, since the IESG discusses 
non-standards-track individual contributions, and the IAB 
discusses all sorts of things including (shudder) politics and 
relationships with other groups, this definition of "IETF 
Standards Process" makes all such discussions part of the 
Standards Process and hence subject to unlimited disclosure and 
dissemination.  So much for internal IESG or IAB mailing lists. 
Probably that isn't our intent.

The "IETF Standards Process" definition also refers to "4 
above".  Since the definition appears in section 4, this 
reference is not well-formed.

The definition of an Internet Draft, and the explanation of the 
expiration process, are not a clarification to 2026, they are 
new policy.  I don't believe the new policy is appropriate -- 
under the current rules, as an author, I believe that I have the 
right to claim that the ISOC rights expire with the document and 
that I can issue "notice and takedown" letters to any archival 
site I find should I be perverse enough to want to do so.  I 
don't believe that we should take that right away from authors, 
especially of "commentary" I-Ds, unless we have substantive 
reason to do so.  In any event, it _is_ a change in policy and 
hence is out of scope for this WG.

5.1 "publishing" of I-Ds again.  But note that this section says 
"only the non-exclusive rights that are needed ...in the 
standards process while leaving all other rights with the 
authors".  That statement is inconsistent with the text in 
section 4 discussed above and several other sections that 
require I-D authors to release rights that are not required for 
the purposes identified.

Again, we do not "publish" I-Ds.  We have provisions for text 
within I-Ds that repudiate some of the rights claimed as 
required under b and c.  And none of these rights need extend 
beyond I-D expiration -- expecially for non-WG, 
non-Standards-Track documents.

5.3 Should be tuned to recognize that, section 4 
notwithstanding, not all I-Ds are "IETF documents".  The last 
sentence of the third paragraph of this section probably 
reflects existing practice.  However, it is an existing practice 
that has never been agreed to by the community. It contradicts 
2026 and, I think, 2223bis, and the IESG has never been given 
permission to alter provisions of 2026 (or any other BCP) 
without community review through a Last Call.  Those documents 
provide that individual contribution (non-standards-track) I-Ds 
that are desired to be published are submitted to the RFC 
Editor.  As I read them, the RFC Editor is then responsible for 
determining that it has adequate permissions to publish, and 
does not need to require that those permissions appear in the 
text of the I-D submitted for review.  The RFC Editor then sends 
the document to the IESG for review, but the IESG review is only 
for end-runs on the standards process and for suggestions that, 
if implemented, are likely to create damage or serious risks to 
the Internet.  Nothing gives them the right to decide to not 
review a document (or to discourage the RFC Editor from moving 
forward with publication) because they do not like the format or 
boilerplate on an I-D.  So this text is either wrong or, if it 
is taken as normative rather than explanatory, exceeds the WG's 
charter.

5.5 The statement starting with "However" and extending at least 
through "institutions of such individuals" seems to me to be 
confusing and an invitation to many tedious and unpleasant 
conversations.  If our intent is to say that some of the rights 
(e.g., dissemination and disclosure) are public and that others 
(perhaps, e.g., creation of derived works) apply only in IETF 
contexts, let's just say that.

6. "...as though the Contribution were a proprietary document". 
But 2.3 and 2.4 essentially prohibit proprietary documents from 
entering the process.    I think this section should be 
referring to "documents for which these special rules about 
copyright and public status apply", or words to that effect, not 
"proprietary" or not.

7.  For clarity, there should be a forward pointer to the 
exceptions in section 7 in those sections that seem to specify 
that these notices must be included in all IETF documents.

--------------------------

For the record, I believe that most, if not all, of these issues 
--in generic, rather than specific textual, form-- have 
previously been raised with the WG, in the broader context of 
the Problem-Statement WG effort, or with the document editor.

regards,
    john

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 25 Apr 2003 08:26:49 +0200

John,

as the culprit for asking Scott to move the definitions back in the 
document, I'll have to confess.. I asked for that, because I thought it 
made the document scan better.

I was probably wrong. Scott Bradner, if you want to, you have my permission 
to move it back.

WRT your point about the publication rights grants in I-Ds:
There are a number of scenarios, including legal wrangles about prior art, 
where ISOC and the IETF would be at a great disadvantage if it had to say 
"I know about this internet-draft that we made available 6 months ago, but 
I'm not allowed to show it to you".
I see MANY cans of worms opening up by attempting to delineate what's 
proper and improper publication of I-Ds and attempting to capture this in 
terms of rights granted to ISOC, so I'd like to ask the opposite question: 
what is the scenario where the irrevocability of the publication rights 
granted to ISOC becomes a disadvantage to any parts of the community?

I do agree that we should codify - make into rules the IETF organizational 
structure has to follow - the handling of I-Ds. But we have already been in 
trouble with the cases where we find it sensible to change those rules, and 
find that we can't without a major wrangle, because we have been too narrow 
in the implicit grant of rights in the past. (Yes, I'm thinking in 
particular of the expired I-D archive.)

                   Harald

--On torsdag, april 24, 2003 17:57:29 -0400 John C Klensin 
<[email-masked]> wrote:

> Since most of the energy in the last several months seems to have gone
> into the IPR document, I decided to take a careful look at "submission
> rights".  I think it needs more attention.
>
> One major issue is that it uses terms like "within the IETF process",
> "IETF documents", and "submissions to the IETF" without precisely
> defining any of those terms (at least where I've been able to find the
> definitions).  Unless we want to have future arguments about whether
> every mailing list posting must bear an explicit copyright transfer to
> ISOC, etc., we need to clarify these terms.  Attempts at some of the
> definitions appear in section 4, but it is customary to define terms
> _before_ they are used, or at least to include forward pointers to the
> definitions, rather than using the terms and then defining them, more or
> less, some sections later.
>
> The I-D issue is even more important.   We have claimed for some time
> that Internet Drafts expire after six months.   The notion of expiration
> is meaningless in the presence of a permanent and irrevocable transfer of
> rights to reproduce and disseminate to ISOC. And, given that six month
> principle, there is no justification for a sweeping and permanent
> transfer under the principle of "benefit the Internet community and the
> public at large, while respecting the legitimate rights of others" much
> less the even stronger statement of 5.1.   Instead, IMO, this document
> should more clearly differentiate between working documents (I-Ds and,
> perhaps, document-like contributions to mailing lists) and archival
> documents (e.g., RFCs).  Similarly, it may be useful to distinguish
> between documents that are intended as contributions to something going
> on in a WG, or to some process that is intended (or hoped) to produce
> some standards-track actions, and individual contributions intended for
> the general information of the community about work or thinking that is
> not directly "IETF-as-SDO" related.
>
> For those latter documents, the best interests of the community may well
> be served by encouraging maximum exposure, even if for a limited period.
> And that goal may be best served in some cases --without harm to our
> principles if we believe in the "six month" rule-- by requiring copyright
> transfers and long-term dissemination and (usually) derived work rights
> only late in the process.  A requirement for statements in an I-D of
> intent (and obligation) to grant those rights if ISOC or the RFC Editor
> decides to publish archivally, and permission for ISOC, IETF, or the RFC
> Editor to make that decision, would be quite reasonable. To require these
> transfers of rights at first I-D submission time is not reasonable and is
> not consistent with the notion of a six-month timeout.
>
> These issues, and the definitional one, seem to require reexamination,
> and possibly changes, to the following sections of the document (there
> may be others, depending on the intent of some of the undefined terms and
> vague language):
>
> 2.3a(A) "part of the IETF standards process" is not defined in this
> context, and may be either too narrow or too broad.  Note that section 4
> seems to define anything discussed in any IETF context as part of the
> standards process.
>
> 2.3a(B) makes a forward reference to section 3.3.  There is no section
> 3.3.  If section 3.2 is intended, see the note on section 4 below.
>
> 2.4 For Internet-Drafts, some of these provisions, particularly that of
> free disclosure of any information, should be revocable on expiration of
> the document.  (Editorially, I don't believe that provision belongs in
> this section -- it is a grant of rights, while the rest of the section
> (and its title) is about representations and warranties.)
>
> 3.  This section applies (only?) to "IETF documents" without a clear
> prior definition of what documents do and do not fall into that category
> (a definition does appear in section 4, but it defines _all_ I-Ds as IETF
> documents).  The first real paragraph ("The IETF requires...") is a nice
> statement of principle, but is inconsistent with 3.1.1 and 3.1.2, which
> don't say a word about primary ISOC copyright claims on some aspects of
> the document, and which do assert _exclusive_ ISOC copyright (given the
> prohibition on "additional copyright notices" statement of the next
> paragraph and the "no dual or joint copyrights, unless..." notes that
> appear elsewhere).
>
> It is my impression that there is controversy in the digital rights
> community as to whether copying a document from one medium to another
> constitutes a modification.   It would be well to review the boilerplate
> carefully to be sure it is robust against possible future interpretations
> and would prohibit some forms of dissemination that we want to encourage
> on the grounds that they constituted "modification" of the document in
> some way.
>
> 3.2(c) ("does not provide the IETF with any rights other than to publish
> as an Internet-Draft...") is inconsistent with the grants of copyright
> and unlimited and permanent dissemination rights in the earlier sections.
> We should not require grants of rights that we don't need -- that is
> inconsistent with both the best interests of the community and preserving
> maximum rights for authors.   Also, we have repeated insisted elsewhere
> that Internet-Drafts are not "published" but rather "posted". It has been
> my understanding that having the IETF act as the "publisher" of an
> Internet Draft may create some responsibilities and risks that we neither
> want nor need.
>
> Also in 3.2, a narrow reading of our publication and approval process,
> especially in conjunction with draft-rfc-editor-rfc2223bis-04.txt, would
> define "submitted for Standards Track publication" as applying only to
> the drafts of the documents actually forwarded to the IESG for review and
> approval and not to any earlier draft.   It could be read even more
> narrowly as describing only those documents which the IESG forwards to
> the RFC Editor with a request/instructions for publication on the
> Standards Track.   Our intent is probably broader and there is no reason
> why this text should be the slightest bit ambiguous.
>
> appropriate AD are invited to take that as a hint), I believe that the
> 2223bis document should be verified to be consistent with this one and
> with our intent. At present, it is not (comments have already been sent
> to the relevant parties as part of the Last Call process).
>
> And I continue to contend that it should be possible to post an I-D with
> a "no rights other than to post or to consider for RFC publication, with
> required additional rights to be granted if the decision is make to
> publish it" statement, essentially midway between (b) and (c).
>
>
> 4. These definitions are somewhat circular.  Moreover, they can be read,
> in conjunction with previous sections, as requiring IPR (technology)
> signoffs, etc., on every single "contribution" including, possibly, this
> note. If 2.3a(B) really refers to 3.2, it implies, along with these
> definitions, that one of those statements can be (perhaps is required to
> be) included with every contribution, even though 3.2 itself requires
> that text only for I-Ds.  Similarly, since the IESG discusses
> non-standards-track individual contributions, and the IAB discusses all
> sorts of things including (shudder) politics and relationships with other
> groups, this definition of "IETF Standards Process" makes all such
> discussions part of the Standards Process and hence subject to unlimited
> disclosure and dissemination.  So much for internal IESG or IAB mailing
> lists. Probably that isn't our intent.
>
> The "IETF Standards Process" definition also refers to "4 above".  Since
> the definition appears in section 4, this reference is not well-formed.
>
> expiration process, are not a clarification to 2026, they are new policy.
> I don't believe the new policy is appropriate -- under the current rules,
> as an author, I believe that I have the right to claim that the ISOC
> rights expire with the document and that I can issue "notice and
> takedown" letters to any archival site I find should I be perverse enough
> to want to do so.  I don't believe that we should take that right away
> from authors, especially of "commentary" I-Ds, unless we have substantive
> reason to do so.  In any event, it _is_ a change in policy and hence is
> out of scope for this WG.
>
> 5.1 "publishing" of I-Ds again.  But note that this section says "only
> the non-exclusive rights that are needed ...in the standards process
> while leaving all other rights with the authors".  That statement is
> inconsistent with the text in section 4 discussed above and several other
> sections that require I-D authors to release rights that are not required
> for the purposes identified.
>
> Again, we do not "publish" I-Ds.  We have provisions for text within I-Ds
> that repudiate some of the rights claimed as required under b and c.  And
> none of these rights need extend beyond I-D expiration -- expecially for
> non-WG, non-Standards-Track documents.
>
> 5.3 Should be tuned to recognize that, section 4 notwithstanding, not all
> I-Ds are "IETF documents".  The last sentence of the third paragraph of
> this section probably reflects existing practice.  However, it is an
> existing practice that has never been agreed to by the community. It
> contradicts 2026 and, I think, 2223bis, and the IESG has never been given
> permission to alter provisions of 2026 (or any other BCP) without
> community review through a Last Call.  Those documents provide that
> individual contribution (non-standards-track) I-Ds that are desired to be
> published are submitted to the RFC Editor.  As I read them, the RFC
> Editor is then responsible for determining that it has adequate
> permissions to publish, and does not need to require that those
> permissions appear in the text of the I-D submitted for review.  The RFC
> Editor then sends the document to the IESG for review, but the IESG
> review is only for end-runs on the standards process and for suggestions
> that, if implemented, are likely to create damage or serious risks to the
> Internet.  Nothing gives them the right to decide to not review a
> document (or to discourage the RFC Editor from moving forward with
> publication) because they do not like the format or boilerplate on an
> I-D.  So this text is either wrong or, if it is taken as normative rather
> than explanatory, exceeds the WG's charter.
>
> 5.5 The statement starting with "However" and extending at least through
> "institutions of such individuals" seems to me to be confusing and an
> invitation to many tedious and unpleasant conversations.  If our intent
> is to say that some of the rights (e.g., dissemination and disclosure)
> are public and that others (perhaps, e.g., creation of derived works)
> apply only in IETF contexts, let's just say that.
>
> 6. "...as though the Contribution were a proprietary document". But 2.3
> and 2.4 essentially prohibit proprietary documents from entering the
> process.    I think this section should be referring to "documents for
> which these special rules about copyright and public status apply", or
> words to that effect, not "proprietary" or not.
>
> 7.  For clarity, there should be a forward pointer to the exceptions in
> section 7 in those sections that seem to specify that these notices must
> be included in all IETF documents.
>
> For the record, I believe that most, if not all, of these issues --in
> generic, rather than specific textual, form-- have previously been raised
> with the WG, in the broader context of the Problem-Statement WG effort,
> or with the document editor.
>
> regards,
>     john
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: Scott Bradner <[email-masked]>
Date: Fri, 25 Apr 2003 07:12:43 -0400 (EDT)

> I was probably wrong. Scott Bradner, if you want to, you have my permission 

yes sir  :-)

(also with the technology doc?)

Scott

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 25 Apr 2003 14:12:37 +0200

--On fredag, april 25, 2003 07:12:43 -0400 Scott Bradner <[email-masked]> 
wrote:

>> I was probably wrong. Scott Bradner, if you want to, you have my
>> permission  to move it back.
>
> yes sir  :-)
>

no objections from me on doing so.

           Harald

---

From: John C Klensin <[email-masked]>
Date: Fri, 25 Apr 2003 09:37:34 -0400

--On Friday, 25 April, 2003 08:26 +0200 Harald Tveit Alvestrand 
<[email-masked]> wrote:

> John,
>
> as the culprit for asking Scott to move the definitions back
> in the document, I'll have to confess.. I asked for that,
> because I thought it made the document scan better.
>
> I was probably wrong. Scott Bradner, if you want to, you have
> my permission to move it back.

While I would personally prefer to see it up front (I think we 
want to encourage end-to-end sequential reading of documents 
like this, and buried definitions work against that goal), if 
you really prefer this ordering, then it would be a huge help if

	(i) the introduction _prominently_ provided a forward
	pointer, as did the first use of special terminology.
	E.g., the second paragraph of the Introduction, might
	use "IETF Process", rather than "IETF Process" and
	contain a parenthetical note that indicated that the
	document uses a number of special terms, that the
	special terms are always capitalized ("IETF Process",
	"Contribution", "IETF Document") and/or quoted on first
	occurrence, and that definitions of them them appear in
	the Definitions section, section NN.
	
	(ii) There were a table of contents for this 13 or 14
	page document, which I suspect is over the RFC Editor's
	limit for a TOC requirement.

Given that the Introduction is over a page long and contains 
some of the special terms, those might be good ideas even if the 
definitions are placed as section 2.

Of course, moving text around doesn't help with the quality of 
the definitions.

> There are a number of scenarios, including legal wrangles
> about prior art, where ISOC and the IETF would be at a great
> disadvantage if it had to say "I know about this
> internet-draft that we made available 6 months ago, but I'm
> not allowed to show it to you". I see MANY cans of worms
> opening up by attempting to delineate what's proper and
> improper publication of I-Ds and attempting to capture this in
> terms of rights granted to ISOC, so I'd like to ask the
> opposite question: what is the scenario where the
> irrevocability of the publication rights granted to ISOC
> becomes a disadvantage to any parts of the community?

In the last several months, I've had interactions with three 
separate organizations/groups, in different parts of the world, 
who have been reluctant to post I-Ds, or even to make in-depth 
comments on mailing lists, without extensive prior (invisible to 
the IETF) review and validation.  In each case, the reason for 
this has been stated as some variation on "we don't want to put 
out an idea that we later decide was silly and be held publicly 
responsible for it forever".   That concern has been reinforced 
by the habit of some posters to the IETF and other lists who 
regularly drag text, out of context, from years-old documents 
and postings to ridicule current positions or imply conspiracies 
about them.

This hurts the IETF, since it is in our interest to get ideas 
out there as early as possible -- both the good ones (for the 
obvious reasons) and even the dubious ones, because they may 
stimulate useful discussion, alternate ideas, or refinement of 
more "mainstream" ideas and documents.  If the ideas have merit, 
even if only as commentary or discussion-stimulating strawmen, 
then delaying getting them posted can cause the sorts of "late 
surprises" that we all seem to think are undesirable.

It also doesn't help with the prior art questions, since it 
delays the date of public disclosure of something that might be 
considered to be in that category.   And, at the other end, 
making I-Ds permanent and permanently public, doesn't help 
make/keep our model that the RFCs are our only archival 
publication series plausible.

That is the damage.  It might or might not be sufficient to 
overwhelm the question you raise if those were the only choices, 
but they don't appear to me to be.   The statements in the 
document feel to me as if the lawyers were asked "how can we 
prevent this problem" rather than "how, consistent with asking 
the authors to give up the absolute minimum of rights (i.e., 
consistent with what the document claims we are doing) can we 
avoid this problem".

I don't have a problem with an expired I-D archive that is not 
generally available or "public".  I don't have a problem with 
such an archive being made selectively available in response to 
an appropriate court order or other legal action, nor even with 
its being made available to responsible researchers for 
background research purposes, nor to having something pulled out 
and made available as part of a patent search.  I don't think it 
is practical or desirable for the secretariat to take any 
responsibility at all for ensuring that archives maintained by 
other organizations are taken down, but I believe that, after 
six months, authors should have the right to track those 
archives down on their own and request (or, under the law in 
some countries, including the US, insist), that the public 
copies be taken down.  I don't even have a problem with obsolete 
I-Ds being included in the IETF's search system, as long as the 
links lead to information about how the documents may be 
obtained if needed, rather than to the documents themselves 
(unless the author voluntarily permits the latter).    Nor would 
I discourage anyone from granting permanent distribution rights 
if they want to do that --in almost all cases, I would encourage 
it.  But we do not help ourselves by insisting on long-term 
grants as a prerequisite for I-D postings.  (I am assuming that 
the technology IPR disclosure requirements would stay in place 
even after a document expires and disappears from public access, 
and that may require some careful wording too.)

Now, if those sorts of principles and guidelines are the ones we 
_really_ want, then let's try to get legal advice as to the 
right words to give them --and no more-- to us.   For example, I 
don't know if the secretariat can maintain a permanent, but 
non-public, I-D archive under fair use provisions, but, if that 
isn't clearly ok, we may need an explicit release for that 
purpose  And, if the language gets long and complicated, let's 
see if we can incorporate as much of it as possible it into a 
form/ agreement to be filled out by the author as part of the 
I-D submission process, filed by the secretariat, and pointed to 
as appropriate.  Reducing the percentage information content of 
I-Ds by adding more and more complex boilerplate doesn't 
encourage efficient review of those documents, and, IMO, we want 
to do everything we can to encourage widespread and efficient 
review.

> I do agree that we should codify - make into rules the IETF
> organizational structure has to follow - the handling of I-Ds.
> But we have already been in trouble with the cases where we
> find it sensible to change those rules, and find that we can't
> without a major wrangle, because we have been too narrow in
> the implicit grant of rights in the past. (Yes, I'm thinking
> in particular of the expired I-D archive.)

See above.  I suggest that we have gotten into those wrangles 
because the rules have been unclear and that new rules have been 
adopted, or existing ones changed, without any attempt at 
obtaining community assent and inconsistent with the principles 
of giving the IETF minimal rights needed to do its work and that 
of six-month expiration.

And, if we are not going to tighten/reduce the grant of rights, 
then I suggest that we should redefine the "expiration" rules 
(much more than the current draft does) and restate the 
principles to make it clear that our major goal is to make 
things as public, permanent, and convenient for the IETF as 
possible and that the authors get to keep whatever is left over.

But I continue to believe that those changes, and these much 
broader requirements for permanent rights transfers, aren't 
clarifications of 2026 et al, but _changes_.  And changes, I 
think,  require rechartering.   I note that your comment above 
-- "cases where we find it sensible to change those rules-- 
reinforces the view that these are changes... especially since 
it is, at best, unclear, that the IESG has the right to make 
substantive changes to requirements laid out in a BCP without 
producing a document and conducting a Last Call on it. 
Whoops, that belongs in the problem-statement group, doesn't it? 
Except that it is already on the list.

      john

---

From: John C Klensin <[email-masked]>
Date: Fri, 25 Apr 2003 09:59:55 -0400

This is, as it stands, a nice piece of work, and I'm finding 
myself with only one comment, which is a largely philosophical 
one.

The case studies, while clear, helpful, and illustrative are 
vaguely unsatisfying to read.   This is because, while some of 
the cases are several years old, the descriptions stop with the 
WG actions and don't move forward to describing how things 
worked out, or seem to be working out.  E.g., if a WG decided to 
move forward in spite of IPR claims, did anyone get sued?  Go to 
jail?

I think there are rational reasons for not going into those 
ultimate outcomes, some of which were, I believe, discussed on 
this mailing list.  But, IMO, a sentence in section 4 that 
explains that it was a deliberate decision (and maybe "why") 
would make the text that follows read more smoothly.

     john

---

From: Scott Bradner <[email-masked]>
Date: Fri, 25 Apr 2003 10:15:24 -0400 (EDT)

> clarifications of 2026 et al, but _changes_.  And changes, I 

note that the aim of this WG is not just to clartify 2026 but
to also say what the IETF has been actually doing

from charter:
  1. Document existing IPR practice in the IETF

I tried to be carefull to only include things that I felt were 
what I (as an AD) felt was what IETF running code is

in the specific case of non-expiring rights to IDs - this is
an issue that first came up in the mid '90s (when a document editor
wanted to take his text and run) - discussion at that time
and at various times since have always come to the conclusion 
that it was not in the IETF's best interest to have revokeable 
rights (wherein the IETF can not be sure that it will be OK to
continue to build future work on an ID even when the author is
no longer involved)

i.e., this is one of the places I write down what I felt was running
code rathyer than just what 2026 said

Scott

---

From: John C Klensin <[email-masked]>
Date: Fri, 25 Apr 2003 10:42:38 -0400

Scott,

Two comments...

(i) Then change the text that describes the principles and let's 
open the question as to whether the WG needs rechartering to 
review those principles.

(ii) Or, better, start making some distinctions that may be 
important and that the document glosses over.  I specifically 
identified most of the differences between an I-D and an RFC. 
But your text below points specifically to a document editor and 
WG documents.  I think it may be (and probably is) reasonable to 
require permanent releases on any WG document, any document for 
which a formal appointment of an editor is involved (probably a 
subset of WG documents, but I can imagine some special cases), 
and, possibly, even any document that is submitted into a WG as 
commentary.  I think some narrowing of "IETF document" might be 
in order, one that would permit authors of documents that are 
not expected to evolve into standards track materials, or to 
contribute directly to WG processes, somewhat more flexibility.

        john

--On Friday, 25 April, 2003 10:15 -0400 Scott Bradner 
<[email-masked]> wrote:

> an issue that first came up in the mid '90s (when a document
> editor wanted to take his text and run) - discussion at that
> time and at various times since have always come to the
> conclusion  that it was not in the IETF's best interest to
> have revokeable  rights (wherein the IETF can not be sure that
> it will be OK to continue to build future work on an ID even
> when the author is no longer involved)
>
> i.e., this is one of the places I write down what I felt was
> running code rathyer than just what 2026 said
>
> Scott

---

From: John C Klensin <[email-masked]>
Date: Fri, 25 Apr 2003 11:31:41 -0400

This seems to me to be in much better shape than 
"submission-rights".  I think this is due to more discussion on 
the list and to adhering much more closely to published norms 
and practices, rather than IESG creative reinterpretation over 
the years.

The comments about placement of definitions apply here too, but 
I assume that is a dead horse that doesn't need kicking.

Some substantive quibbles...

Section 3.1 "assurance of reasonable and non-discriminatory 
terms" would be strengthened by adding "or any other assertions 
about terms".  That has always, AFIK, been the intent.

Section 6.1.1, para 2.  "negates" should probably be "negates or 
alters".   "Negates" is too narrow and likely to lead to silly 
discussions about what is intended.   "Alters" forces disclosure 
in doubtful situations.

Section 6.1.3.  The "as soon as possible" provision of this 
section seems to contradict/ override the reasonable and rather 
nice discussion of third-party issues in sections 5.7 and 5.8 of 
ipr-wg-guidelines-03.  The discussions anticipated there would 
not be possible if the requirement as that disclosure of all 
such IPR be disclosed as soon as the connection is realized.

Section 10.  "they have no indications" should probably be "they 
have no plausible indications" or something to that effect.  "No 
indications" leaves us too open to denial of service attacks.

Section 11.  The definition of "Contribution" in section 5 
includes almost anything that is said or done in an IETF 
context.  Prohibiting "mention of specific IPR" in any 
Contribution would therefore prohibit WG discussion of claims 
and assertions, as well as statements about which licenses have 
been exercised as part of an implementation/interoperability 
statement.  Probably "IETF documents" is intended here, rather 
than "Contributions", as the title for this section implies.

Editorial...

Section 5, definition of "IPR" probably needs
  s/data rights/data rights that/

Section 8, first paragraph.  The sentence starting "An IETF 
consensus has developed" is very hard to read, and even to 
parse.  Some reorganization, or perhaps a numbered or bulleted 
list, might be in order.

Section 8, second paragraph, second "sentence"... is a fragment 
that looks as if it should either have a predicate.  Or perhaps 
the intent was to drop it entirely.

Section 8, third paragraph, first sentence.  I think "underlying 
IPR" should be "claimed IPR" or something to that effect. 
"Underlying" can be read as a presumption that there is actually 
something there.

Section 9, third paragraph, parenthetical note/sentence.  Either 
the period after "assignments or encapsulations" should be 
removed and placed after the parenthetical note (with its 
terminating period being discarded) or "(e.g.," should be 
"(E.g.,".

    john