Subject: Request for advancement of IPR documents

From: Harald Alvestrand <[email-masked]>
Date: Tue, 19 Feb 2008 08:57:02 +0100

Enclosed is our writeup for the advancement of the IPR Working Group's
documents on handling of copyright in the IETF.

With this submission, I believe the IPR WG has completed its charter as
stated; our mailing list remains open in order to deal with any
questions and issues raised in IETF Last Call, but we have no more work
on our schedule at this time.

Information supplied outside of the template:

Documents:
- draft-ietf-ipr-3978-incoming-07.txt, destined for BCP
- draft-ietf-ipr-outbound-rights-05.txt, destined for Informational

  (1.a)  Who is the Document Shepherd for this document?  Has the
         Document Shepherd personally reviewed this version of the
         document and, in particular, does he or she believe this
         version is ready for forwarding to the IESG for publication?

	Harald Tveit Alvestrand. Yes.

  (1.b)  Has the document had adequate review both from key WG members
         and from key non-WG members?  Does the Document Shepherd have
         any concerns about the depth or breadth of the reviews that
         have been performed?

	The WG review has been adequate.
	The document has been reviewed while in production by IETF
        counsel, and IETF counsel
	has been asked to do a last review before IETF Last Call
        finishes.

  (1.c)  Does the Document Shepherd have concerns that the document
         needs more review from a particular or broader perspective,
         e.g., security, operational complexity, someone familiar with
         AAA, internationalization or XML?

	Apart from review by counsel, no.

  (1.d)  Does the Document Shepherd have any specific concerns or
         issues with this document that the Responsible Area Director
         and/or the IESG should be aware of?  For example, perhaps he
         or she is uncomfortable with certain parts of the document, or
         has concerns whether there really is a need for it.  In any
         event, if the WG has discussed those issues and has indicated
         that it still wishes to advance the document, detail those
         concerns here.  Has an IPR disclosure related to this document
         been filed?  If so, please include a reference to the
         disclosure and summarize the WG discussion and conclusion on
         this issue.

	No.

  (1.e)  How solid is the WG consensus behind this document?  Does it
         represent the strong concurrence of a few individuals, with
         others being silent, or does the WG as a whole understand and
         agree with it?

	The WG contains one individual who flamboyantly disagrees with
        the approach taken.
	Other individuals think that the IETF does not go far enough in
        allowing reuse of its text, which is a problem in some free
        software contexts, or that the IETF sets too stringent
        requirements for inclusion of code with restrictive licenses
        in documents.

	I believe there is strong consensus that the current documents
	represent the best compromise position we can find at this time.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
         discontent?  If so, please summarise the areas of conflict in
         separate email messages to the Responsible Area Director.  (It
         should be in a separate email because this questionnaire is
         entered into the ID Tracker.)

	One person has indicated extreme discontent with the approach
        taken.
	A few other people have indicated discontent with the free
        software consequences.

  (1.g)  Has the Document Shepherd personally verified that the
         document satisfies all ID nits?  (See
         http://www.ietf.org/ID-Checklist.html and
         http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
         not enough; this check needs to be thorough.  Has the document
         met all formal review criteria it needs to, such as the MIB
         Doctor, media type and URI type reviews?

	Yes.

  (1.h)  Has the document split its references into normative and
         informative?  Are there normative references to documents that
         are not ready for advancement or are otherwise in an unclear
         state?  If such normative references exist, what is the
         strategy for their completion?  Are there normative references
         that are downward references, as described in [RFC3967]?  If
         so, list these downward references to support the Area
         Director in the Last Call procedure for them [RFC3967].

	-outbound has only informative references.
	-incoming has split.

	-incoming has a normative reference on a document to be produced
        by the IETF trust. Both documents reference each other; apart
        from that, all references are stable.

  (1.i)  Has the Document Shepherd verified that the document IANA
         consideration section exists and is consistent with the body
         of the document?  If the document specifies protocol
         extensions, are reservations requested in appropriate IANA
         registries?  Are the IANA registries clearly identified?  If
         the document creates a new registry, does it define the
         proposed initial contents of the registry and an allocation
         procedure for future registrations?  Does it suggest a
         reasonable name for the new registry?  See [RFC2434].  If the
         document describes an Expert Review process has Shepherd
         conferred with the Responsible Area Director so that the IESG
         can appoint the needed Expert during the IESG Evaluation?

	Yes, there are no IANA actions.

  (1.j)  Has the Document Shepherd verified that sections of the
         document that are written in a formal language, such as XML
         code, BNF rules, MIB definitions, etc., validate correctly in
         an automated checker?

	Yes, there are no such sections.

  (1.k)  The IESG approval announcement includes a Document
         Announcement Write-Up.  Please provide such a Document
         Announcement Write-Up?  Recent examples can be found in the
         "Action" announcements for approved documents.  The approval
         announcement contains the following sections:

     Technical Summary
        The "incoming" memo details the IETF
        policies on rights in Contributions to the IETF. It also
        describes the objectives that the policies are designed to meet.

	The "outgoing" memo describes the desires of the IETF regarding
        outbound rights to be granted in IETF contributions, as managed
        by the Trust.

     Working Group Summary

	The most contentious part of the debate was on whether or not to
        freely allow the production of modified versions of the material
        outside the IETF context. The rough consensus was that code has
        to be modifiable in order to be useful, while the arguments for
        allowing modification of prose text were not compelling for the
        WG's participants

    Document Quality

        The documents have been reviewed by the working group and by
        IETF counsel.

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

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 27 Feb 2008 18:42:38 +0100

>         from that, all references are stable.

Is the intention to last call this document without having the IETF
trust develop the normative reference first?

Is there a draft version of the document produced by the IETF trust
available?

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 27 Feb 2008 18:56:04 +0100

> trust develop the normative reference first?
It is the intention to ask the AD for consideration of this document.
I believe most substantive points of feedback from the IETF community do 
not depend on the existence of that document (what it should say is 
pretty constrained), so I personally don't see a reason for delaying the 
start of the IETF Last Call.

I would be happier with having the (possibly draft) document available 
before the end of Last Call than I would be with not seeing it before 
that, but it's up to the Trust to decide when they do this; the AD for 
this WG is also a trustee of the Trust, so he should definitely be in a 
position to figure out how to go forward with this.
> Is there a draft version of the document produced by the IETF trust
If there is, nobody's mentioned it to me.

                Harald

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 27 Feb 2008 19:50:56 +0100

> position to figure out how to go forward with this.

I just noticed that the latest version (-07) removed the Trust Agreement
from the reference section.  It is still referenced from the text in the
document though.

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=http://tools.ietf.org/id/draft-ietf-ipr-3978-incoming-07.txt

I think it would be unfortunate to last call a document of this
importance without having the community be able to read one of its
normative references.

/Simon

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 27 Feb 2008 20:44:13 +0100

> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=http://tools.ietf.org/id/draft-ietf-ipr-3978-incoming-07.txt
actually it was never there.... and none of the nits checkers (human or 
mechanical) caught the fact that this section:

5.4.  Sublicenses by IETF Trust
   The IETF Trust will sublicense the rights granted to it under Section
   5.3 to all IETF participants for use within the IETF Standards
   Process.  This license is expressly granted under [TRUST LICENSE
   DOCUMENT].

contains a reference that isn't in the references section.

We'll get that fixed somehow.

                Harald

---

From: Russ Housley <[email-masked]>
Date: Wed, 27 Feb 2008 14:46:46 -0500

I have asked the IETF Trustees to review this document, but I 
seriously doubt that they will generate a document before the IETF 
Last Call demonstrates consensus for the things proposed in these documents.

Russ

At 12:56 PM 2/27/2008, Harald Tveit Alvestrand wrote:
>I believe most substantive points of feedback from the IETF 
>community do not depend on the existence of that document (what it 
>should say is pretty constrained), so I personally don't see a 
>reason for delaying the start of the IETF Last Call.
>
>I would be happier with having the (possibly draft) document 
>available before the end of Last Call than I would be with not 
>seeing it before that, but it's up to the Trust to decide when they 
>do this; the AD for this WG is also a trustee of the Trust, so he 
>should definitely be in a position to figure out how to go forward with this.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Feb 2008 09:57:00 +1300

How about suggesting to the Trust that they should generate
a public statement that they have understood the IETF's
wishes and undertake to publish a draft and then final
license by given dates?

    Brian

---

From: "todd glassey" <[email-masked]>
Date: Wed, 27 Feb 2008 13:00:45 -0800

I dont think its smart or legally-enforceable to create a process like this 
without permanently linking the various pieces of the contract together so a 
normal mortal can read and understand where all of the participation rules 
live.  This isn't true currently with any IETF document's and its a flaw in 
the licensing and use model which prevents Informed Consent Decisions from 
being made.

Informed Consent (IC)
-------------------
My concern about spreading the Contract for Participation across multiple 
document's which are always in a state of flux & which have with no linkage 
in them is that this makes it impossible to demonstrate an informed and 
properly-executed consent type model for the conveyance of the IP.

The challenge
------------
So rather than having someone like Jorge or one of the IETF's other 
participating attorney's reviewing that process, someone who has NO 
EXPERIENCE with the IETF should be tasked to traverse and document the 
process of participating as well as the 'key controls' of that process.

If an attorney with no experience in the IETF can understand and then put in 
place those requirements, then the IETF would have actually succeeded in 
making a system which can be proven to be capable of being understood and 
properly participated in.

IC isn't possible with the current model
---------------------------------
What I am willing to bet money on is that this is not possible. & The text 
below from Harald document's this concern "that this group is grossly 
incompetent to create contracts" in the first place.

Just my two cents...

Todd Glassey

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 27 Feb 2008 22:59:08 +0100

> wishes and undertake to publish a draft and then final

Slight variation, there could be two Last Calls:  One with
the missing normative reference, and if that got consensus
the Trust knows that an attempt to create the missing draft
will be likely no waste of their time.  A second Last Call
could then confirm that all is fine as far as the community
is concerned.

 Frank

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 28 Feb 2008 12:15:27 +0100

On Wed, Feb 27, 2008 at 10:59:08PM +0100,
 Frank Ellermann <[email-masked]> wrote 
 a message of 15 lines which said:

> Slight variation, there could be two Last Calls: One with the
> missing normative reference, and if that got consensus the Trust
> knows that an attempt to create the missing draft will be likely no
> waste of their time.  A second Last Call could then confirm that all
> is fine as far as the community is concerned.

It seems reasonable. Issuing a Last Call without being able to read
the actual text written by the IETF Trust seems like asking a blank
cheque. It is scary enough to let the IETF Trust decide of the actual
text, now, we should even trust them to translate the RFC principles
without even knowing what they will write?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 Feb 2008 07:26:34 -0500

I am missing something in these discussion.
The purpose of these documents is to define what we want the trust to do.
The purpose of the last call is to confirm that we have defined what the 
IETF would like the trust to do.

I don't need to see the trust documents to decide if the I-Ds under 
discussion properly define what we want to have happen.

As a separate, procedural, matter between the IETF and the Trust there 
is the matter of determining whether the trust is actually doing what we 
want.  That takes review.  In general, it doesn't even take a last call. 
  If anyone observes that the trust documents don't match what the IPR 
documents call for, they can ask on the IETF list (once the trust says 
that they think they are doing the right thing.)

It may be sensible for the first time the trust drafts language to match 
our goals to ask that they explicitly run the language by the IETF. 
Remember that one of the specific goals was to make it easy to fix the 
language if we find it isn't quite right.  Without a full working group 
process.  So I would expect the IETF leadership and the IAOC (acting on 
behalf of the trust, in their role as trustees) to work out a procedure 
for ongoing validation that the trust language meets the IETF goals.
That procedure is not part of either the incoming or outgoing RFCs, and 
not part of the IETF last calls that need to take place.

Yours,
Joel

---

From: [email-masked]
Date: Thu, 28 Feb 2008 10:27:03 -0500

> without even knowing what they will write?

I support this two-Last-Calls approach.  Ensuring that the goals
have community consensus before the Trust starts drafting the actual
text makes a great deal of sense.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipr-wg

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 28 Feb 2008 17:05:24 +0100

> The purpose of these documents is to define what we want the trust to do.

I think that is false for the reference under discussion, -incoming-07
says:

As far as I am aware, the requirements or constraint on how that license
should look are not discussed anywhere.

The -outgoing document discuss, if I understand correctly, the rights
given to others.  As far as I can see, it never discuss how rights are
going to be licensed to IETF participants.

Treating IETF participants and "others" differently leads to complexity.

One right that IETF participants needs to be able to update an RFC would
be the ability to modify the document.  This is not discussed in
-outgoing.

> that they think they are doing the right thing.)

Sure, but as far as I understand, there is no IPR document that explain
what should go into the license to IETF participants.

/Simon

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 28 Feb 2008 17:33:59 +0100

> what should go into the license to IETF participants.
What about the text below? Seems to me it's trying to explain what 
should go into the license to IETF participants....

3.3. Right to Produce Derivative Works
   The IETF needs to be able to evolve IETF Documents in response to
   experience gained in the deployment of the technologies described in
   such IETF Documents, to incorporate developments in research and to
   react to changing conditions on the Internet and other IP networks.
   The IETF may also decide to permit others to develop derivative works
   based on Contributions.  In order to do this, the IETF must be able
   to produce derivatives of its documents; thus the IETF must obtain
   the right from Contributors to produce derivative works.  Note that
   the right to produce translations is required before any Contribution
   can be published as an RFC to ensure the widest possible distribution
   of the material in RFCs.  The right to produce derivative works, in
   addition to translations,  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.

   The right to produce derivative works must be granted in order for an
   IETF working group to accept a Contribution as a working group
   document or otherwise work on it. For non-working group Contributions
   where the Contributor requests publication as a standards track RFC,
   the right to produce derivative works must be granted before the IESG
   will issue an IETF Last-Call and, for most non-standards track non-
   working group Contributions, before the IESG will consider the
   Internet-Draft for publication.  Occasionally a Contributor may not
   want to grant publication rights or the right to produce derivative
   works before finding out if a Contribution has been accepted for
   development in the IETF Standards Process. In these cases the
   Contributor may include a limitation on the right to make derivative
   works in the form specified in the Legend Instructions. A working
   group can discuss the Contribution with the aim to decide if it
   should become a working group document, even though the right to
   produce derivative works or to publish the Contribution as an RFC has
   not yet been granted.  However, if the Contribution is accepted for
   development, the Contributor must resubmit the Contribution without
   the limitation notices before a working group can formally adopt the
   Contribution as a working group document.  The IETF Trust may
   establish different policies for granting sublicenses with respect to
   different types of Contributions and content within Contributions
   (such as executable code versus descriptive text or references to
   third party materials).  The IETF Trust's policies concerning the
   granting of sublicenses to make derivative works will be guided by
   RFC [-outbound].

   The IETF has historically encouraged organizations to publish details
   of their technologies, even when the technologies are proprietary,
   because understanding how existing technology is being used helps
   when developing new technology. But organizations that publish
   information about proprietary technologies are frequently not willing
   to have the IETF produce revisions of the technologies and then
   possibly claim that the IETF version is the "new version" of the
   organization's technology. Organizations that feel this way can
   specify that a Contribution be published with the other rights
   granted under this document but may withhold the right to produce
   derivative works other than translations.

   In addition, IETF Documents frequently make normative references to
   standards or recommendations developed by other standards
   organizations. Since the publications of some standards organizations
   are not public documents, it can be quite helpful to the IETF to
   republish, with the permission of the other standards organization,
   some of these documents as RFCs so that the IETF community can have
   open access to them to better understand what they are referring to.
   In these cases the RFCs can be published without the right for the
   IETF to produce derivative works.  In both of the above cases in
   which the production of derivative works is excluded, the Contributor
   must include a special legend in the Contribution, as specified in
   the Legend Instructions, in order to notify IETF participants about
   this restriction.

3.4. Rights to Use Trademarks
   Contributors may wish to seek trademark or service mark protection on
   any terms that are coined or used in their Contributions. IETF makes
   no judgment about the validity of any such trademark rights.
   However, the IETF requires each Contributor, under the licenses
   described in Section 5.3 below, to grant IETF Trust a perpetual
   license to use any such trademarks or service marks solely in
   exercising rights to reproduce, publish, discuss and modify the IETF
   Contribution. This license does not authorize IETF or others to use
   any trademark or service mark in connection with any product or
   service offering.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 28 Feb 2008 17:50:39 +0100

> 3.3. Right to Produce Derivative Works

That text is from -incoming.  Section 3 of -incoming is not normative.
The title of section 3 is:

3. Exposition of Why These Procedures Are the Way They Are

As far as I can tell, the trust is not bound to abide by a non-normative
section in a document that is not directed to the trust.

The section is not written in the form of requirements, but rather as
explanation of procedures that are documented elsewhere.  Only that
there is no elsewhere.  I believe the title of the section confirms this
impression.

The text in 3.3 itself gives a good overview, but it leaves out many
details that I think are needed in order to write a good license.

I suggest that section 3.3 on this matters is moved to -outgoing.  That
is the document where the IETF tells the Trust how to write the license.

/Simon

---

From: "todd glassey" <[email-masked]>
Date: Thu, 28 Feb 2008 10:56:56 -0800

----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: "Harald Tveit Alvestrand" <[email-masked]>
Cc: "Joel M. Halpern" <[email-masked]>; <[email-masked]>
Sent: Thursday, February 28, 2008 8:50 AM
Subject: Re: Request for advancement of IPR documents

> 3. Exposition of Why These Procedures Are the Way They Are

You mean "Explanation" right? An Exposition is a meeting of people like a 
conference.

> there is no elsewhere.

Making the contract itself unenforceable and void. Nice move guys.

> I believe the title of the section confirms this
> impression.
>

I suggest that ALL of the document's for participation are merged into a 
single document. That means that BCP78 and 79 need to be the same document 
and that RFC2026 or whatever parts of it or its successor documents are in 
effect also combined into that single document.

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 28 Feb 2008 21:00:50 +0100

> You mean "Explanation" right? An Exposition is a meeting of
> people like a conference.

<http://pda.leo.org/ende?lp=ende&search=Schaustellung> has it
together with exhibit, display, ostentation.  Supported by 
among others <http://en.wiktionary.org/wiki/exposition> and
<http://www.merriam-webster.com/thesaurus/exposition> (3).

Ordinary US legal slang if Grisham got it right, like we say
"memo" when we mean standard, because there is a standard
stating that we must not say standard before the memo is a
standard.

 Frank

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 28 Feb 2008 23:49:06 +0100

> That text is from -incoming.  Section 3 of -incoming is not normative.
Your words were "there is no IPR document that explain...." - you did 
not say "there is no IPR document that commands....".

Remember that the Trust is supposed to be working for the good of the 
IETF too.

               Harald

---

From: "TS Glassey" <[email-masked]>
Date: Thu, 28 Feb 2008 17:21:33 -0800

Harald

> Remember that the Trust is supposed to be working for the good of the 

What does that mean?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Feb 2008 14:54:22 +1300

Joel,

> discussion properly define what we want to have happen.

I agree. The confusion seems to come from the dangling reference in
the Incoming draft, which Harald has acknowledged needs to be fixed:
   This license is expressly granted under [TRUST LICENSE
   DOCUMENT].
That is a reference to a document that by definition doesn't exist
until after the IETF has issued the present document and the Trust has
taken the required action. Obviously, our axiom is that we trust the
Trust to do so promptly, but the reference is a bug.

    Brian

---

From: "TS Glassey" <[email-masked]>
Date: Thu, 28 Feb 2008 17:59:29 -0800

There is another missing policy, and that is a statement about "how  that 
requests for information" on an IP issue must be answered within some 
expiable period and there must be an escalation process for what to do when 
the IETF drags its feet about responding.

Todd Glassey