Subject: IESG evaluation of our documents, current version

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 10 Jun 2008 01:34:12 +0200

I enclose here the current evaluation record of the IESG for the two IPR 
documents.

As you can see, Cullen Jennings has chosen to raise a DISCUSS comment; I 
will respond to his points in a later message.

                  Harald

To: Internet Engineering Steering Group <[email-masked]>
From: IESG Secretary <[email-masked]>
Reply-To: IESG Secretary <[email-masked]>
Subject: Evaluation: draft-ietf-ipr-3978-incoming-09.txt to BCP
         draft-ietf-ipr-outbound-rights-06.txt to Informational
         
--------

Evaluation for draft-ietf-ipr-3978-incoming-09.txt  draft-ietf-ipr-outbound-rights-06.txt can be found at
https://datatracker.ietf.org/idtracker/ballot/2731/ 

Last Call to expire on: 2008-04-07

        Please return the full line with your position.

                      Yes  No-Objection  Discuss  Abstain
Jari Arkko           [ X ]     [   ]     [   ]     [   ]
Ron Bonica           [   ]     [ X ]     [   ]     [   ]
Ross Callon          [   ]     [ X ]     [   ]     [   ]
Lisa Dusseault       [   ]     [ X ]     [   ]     [   ]
Lars Eggert          [ X ]     [   ]     [ . ]     [   ]
Pasi Eronen          [   ]     [ X ]     [   ]     [   ]
Russ Housley         [ X ]     [   ]     [   ]     [   ]
Cullen Jennings      [   ]     [   ]     [ X ]     [   ]
Chris Newman         [   ]     [ X ]     [ . ]     [   ]
Jon Peterson         [   ]     [ X ]     [   ]     [   ]
Tim Polk             [   ]     [ X ]     [   ]     [   ]
Dan Romascanu        [   ]     [ X ]     [   ]     [   ]
Mark Townsley        [   ]     [ X ]     [   ]     [   ]
David Ward           [   ]     [ X ]     [   ]     [   ]
Magnus Westerlund    [   ]     [ X ]     [   ]     [   ]

"Yes" or "No-Objection" positions from 2/3 of non-recused ADs, 
with no "Discuss" positions, are needed for approval.

DISCUSSES AND COMMENTS:
======================
Jari Arkko:

Comment [2008-05-21]:
The legend URL is currently non-existent. It should be created when the document
is approved.

Lisa Dusseault:

Comment [2008-06-03]:

It may be the case that I have been involved in too many process discussions
last week.  I'm left reading the definition of RFC and the section on Non-IETF
documents and not sure we're all talking about the same things.

The definition of "RFC" (section 1.k) implies that all RFCs are IETF documents
though it does not state it.  This could be fixed with

OLD: k. "RFC": the basic publication series for the IETF.

NEW: k. "RFC": the publication series used by the IETF among others.

Section 4 limits rights assignment to "IETF Standards Process".  This may be OK
but I think "IETF Processes" would be better here.  Not all of our work is
creating standards (some of it is process-changing work) but I believe the
rights assignment applies to drafts on process changes.  Like this one.

Lars Eggert:

Comment [2008-05-21]:

Cullen Jennings:

Discuss [2008-06-04]:

These documents are not the type of thing I read every day so they were slow
going for me and I may have just missed things. I expect some of these issues
are probably just my confusion but I want to check them anyways.

First the high level points:

1) the ietf needs for a person to be able to take an RFC and start creating a
modify bis version of it. I don't see how the outbound rights allow for this but
this may be due to my confusion in the next point

2)  I'm concerned about the order of how things happen and making sure that we
continue to be able to do things like take email contributions and include them
in a draft. Section 5.4 of incoming states the Trust "will" do some things. I'm
assuming that the use of "will" here means that some time in the future the
Trust will publish a document or license that grants the rights described in
section 5.3. If this is the case, it seems like we would have a problem with
approving this document which obsoletes the old documents before this new
sublicense from the Trust was in place. [Note - I've read the sentence "This
license is expressly granted under a license agreement
   issued by the IETF
Trust and must contain a pointer to the full IETF
   Trust agreement." over and
over and don't understand what it means so it may be you just have to explain
that to me].  I also find the restriction of these rights for "use within the
IETF Standards process" very hard to understand. Does that mean some vendor
could not use something that was limited to "within the IETF Standards process"
to create an early implementation. If so, that would be a problem.

3) Section 3.3 of incoming, 2nd para, last sentence. This says that sublicense
of derivate works will be covered in outbound but outbound does not seem to
grant any such rights. Given how we modify draft other people wrote, and paste
email other people wrote into drafts, it seems we need the Trust to grant the
right to create derivative works of Contributions. It is not clear to me that
this is provided in outbound.

4) In outbound, the term contributions never seems to be defined. I think it
would be good to make it very clear it was the definition form incoming and
consistently have it start with a capital later to indicate it was the same
term.

5) outbound section 4.2. Title implies this is about Contributions but text
implies it is only about IETF documents. Which is it? This should be made
consistent to avoid future debates. Similarly section 4.4 implies Contributions
in title but only seems to talk about RFCs.

6) outbound section 4.3, para 2, where it says "used by anyone in any way
desired." Clearly we don't want people to be able to use it in a way that
removes the liability limitation in license legend. Are we expecting that the
legend would be reproduced in any license that contained extracted code? I find
this whole topic very murky in the current document and do not understand what
we are telling the Trust they need to do.

Comment [2008-06-04]:

It might be good to add an appendix to this document that contains the initial
text that needs to be placed at the legends URL so there are no delays or
surprises figuring that out. (Or if that is just a direct copy of something
else, provide a pointer to it).

In outbound, section 4.3, do you want to add "pseudo code" to the list. I seem
to recall some IETF preference to pseudo code over any particular programming
language.

Section 4.5 of outbound. I've asked three other people to read section 4.5 and
they have all come to somewhat different conclusions about what it means. You
should consider if you need to make it more explicit - perhaps an example.

Incoming section 3.4, 2nd para, "the" -> "The"

Tim Polk:

Comment [2008-06-05]:
I believe that the text on IETF contributions probably covers WG charters
already, but I support
adding it to the definition for "Contribution" (1.a) in
-incoming.

I also note that the iab has explicitly requested that the iab stream be in
scope.  That made me
wonder about the -iesg drafts.  I know that -iesg documents
should be considered in scope for the IETF stream, but I can't find a reference
that clearly specifies that.  Do we need to make a
declaration like that in
section 11 for our

^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <[email-masked] <mailto:[email-masked]>>
To: IETF-Announce <[email-masked] <mailto:[email-masked]>>
Cc: Internet Architecture Board <[email-masked] <mailto:[email-masked]>>,
    RFC Editor <[email-masked] <mailto:[email-masked]>>, 
    ipr mailing list <[email-masked] <mailto:[email-masked]>>, 
    ipr chair <[email-masked] <mailto:[email-masked]>>
Subject: Protocol Action: 'Rights Contributors provide to the 
         IETF Trust' to BCP 

The IESG has approved the following document:

- 'Rights Contributors provide to the IETF Trust '
   <draft-ietf-ipr-3978-incoming-08.txt> as a BCP

This document is the product of the Intellectual Property Rights Working
Group. 

The IESG contact person is Russ Housley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipr-3978-incoming-08.txt

Technical Summary

  The IETF policies about intellectual property rights in Contributions
  to the IETF are designed to ensure that such Contributions can be made
  available to the IETF and Internet communities while permitting the
  authors to retain as many rights as possible.  Of course, Contributors
  grant some rights to the IETF.  The IETF trust holds and manages those
  rights on behalf of the IETF.  The Trustees of the IETF Trust are
  responsible for that management.  This management includes granting
  the licenses to copy, implement and otherwise use IETF contributions,
  among them Internet-Drafts and RFCs.  The Trustees of the IETF Trust
  accepts direction from the IETF regarding the rights to be granted.

  draft-ietf-ipr-3978-incoming (destined for BCP) details the IETF
  policies on rights in Contributions to the IETF.  It also describes
  the objectives that the policies are designed to meet.

  draft-ietf-ipr-outbound-rights (destined for Informational) describes
  the desires of the IETF regarding outbound rights to be granted by the
  IETF Trust in IETF Contributions.

Working Group Summary

  This document is the product of the IPR Working Group.

  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.

Protocol Quality

  The documents were reviewed by the IPR Working Group and by IETF
  counsel.

  The documents were reviewed by Russ Housley for the IESG.

RFC Editor Note

  Please add the followinf title page header lines:

    Obsoletes: 3978, 4748
    Updates: 2026

  In section 1, item k should include a more encompassing definition
  for "RFC":

  OLD

   k. "RFC": the basic publication series for the IETF.

  NEW

   k. "RFC": the publication series used by the IETF among others.

  Section 4 should not limits rights assignment to "IETF Standards
  Process", rather it should address all "IETF Processes" since not all
  of the work in the IETF is about creating standards.  For example,
  some of the work in the IETF is about process change.

  OLD

   4.  Non-IETF documents

   This document only relates to Contributions made as part of the IETF
   Standards Process  Other documents that are referred to as Internet-
   Drafts and RFCs may be submitted to and published by the RFC Editor
   independently of the IETF Standards Process.  Such documents are not
   covered by this document, unless the controlling entity for that
   document stream, as described in [RFC 4844] chooses to apply these
   rules.   Non-IETF Contributions must be marked appropriately as
   described in the Legend Instructions.  See the RFC Editor web page
   for information about the policies concerning rights in RFC Editor
   Documents; for other document streams, the controlling entity must be
   contacted. See Section 11 for a declaration from the IAB on this
   matter.

  NEW

   4.  Non-IETF documents

   This document only relates to Contributions made as part of the IETF
   Processes.  Other documents that are referred to as Internet-Drafts
   and RFCs may be submitted to and published by the RFC Editor
   independently of the IETF Standards Process.  Such documents are not
   covered by this document, unless the controlling entity for that
   document stream, as described in [RFC 4844] chooses to apply these
   rules.  Non-IETF Contributions must be marked appropriately as
   described in the Legend Instructions.  See the RFC Editor web page
   for information about the policies concerning rights in RFC Editor
   Documents; for other document streams, the controlling entity must be
   contacted. See Section 11 for a declaration from the IAB on this
   matter.

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 12 Jun 2008 06:04:19 +0200

Cullen,

I'll attempt to comment on your points below - just a few words first about 
the format.

I'm trying to figure out, for each of the comments of your DISCUSS, whether 
it falls into one or the other case of:

- There's unclear language in the document, and it needs improvement before 
approval
- You have an opinion that is different from the consensus of the WG

On reviewing the text below, I think the "difference of opinion" is 
contained in your "comments" section, while the "DISCUSS" section is a 
matter of clarity of writing, and a couple of errors in the text.

If you (and the WG, and the rest of the IESG) agree with my understanding 
on these points, I'll ask the editors to prepare revised versions of the 
drafts incorporating the required changes. We may need to discuss the 
specific form of the changes some more.

--On Tuesday, June 10, 2008 01:34:12 AM +0200 Harald Tveit Alvestrand 
<[email-masked]> wrote:

> DISCUSSES AND COMMENTS:
> ======================
> Jari Arkko:
>
> Comment [2008-05-21]:
> The legend URL is currently non-existent. It should be created when the
> document is approved.

Actually it should be created when the Trust has text to put there. I'm 
told this is work in progress.
It's up to the IESG (which has people who are also on the Trust) whether or 
not they feel comfortable approving the document before the Trust has put 
text at the Legends URL.

> Lisa Dusseault:
>
> Comment [2008-06-03]:
>
> It may be the case that I have been involved in too many process
> discussions last week.  I'm left reading the definition of RFC and the
> section on Non-IETF documents and not sure we're all talking about the
> same things.
>
> The definition of "RFC" (section 1.k) implies that all RFCs are IETF
> documents though it does not state it.  This could be fixed with
>
> Section 4 limits rights assignment to "IETF Standards Process".  This may
> be OK but I think "IETF Processes" would be better here.  Not all of our
> work is creating standards (some of it is process-changing work) but I
> believe the rights assignment applies to drafts on process changes.  Like
> this one.

The "IETF Standards Process" is defined in section 1 (term g), as 
encompassing what I think is essentially all the IETF's work. It's 
important to have a consistent terminology, even when it's not immediately 
the obvious one.
This term has been used a lot - and not consistently across documents; the 
initial usage in RFC 1310 seems to be focused on "the making of standards", 
so one could argue that the usage in this draft is not the same as that 
earlier usage, but this definition is unchanged from RFC 3667 (2004).

So I see two alternatives:

- Keep the document as it is
- Replace "IETF Standards Process" with "IETF Process" throughout both 
documents

I'd like to hear commentary from both the WG and the IESG on what 
terminology they think best. As chair, I'll just have to insist on 
consistent use of the term.

> Cullen Jennings:
>
> Discuss [2008-06-04]:
>
> These documents are not the type of thing I read every day so they were
> slow going for me and I may have just missed things. I expect some of
> these issues are probably just my confusion but I want to check them
> anyways.
>
> 1) the ietf needs for a person to be able to take an RFC and start
> creating a modify bis version of it. I don't see how the outbound rights
> allow for this but this may be due to my confusion in the next point

This is the single right that is granted by a license described in the 
-incoming document (a BCP, which the Trust is expected to be obliged to 
follow) and not in the -outgoing document (an Info, which is intended as 
guidance to the Trust, and may be departed from if the Trust has to). 
Section 5.4 of -incoming.

> 2)  I'm concerned about the order of how things happen and making sure
> that we continue to be able to do things like take email contributions
> and include them in a draft. Section 5.4 of incoming states the Trust
> "will" do some things. I'm assuming that the use of "will" here means
> that some time in the future the Trust will publish a document or license
> that grants the rights described in section 5.3. If this is the case, it
> seems like we would have a problem with approving this document which
> obsoletes the old documents before this new sublicense from the Trust was
> in place.

This WG has asked the Trust to prepare such text; it's up to the IESG 
whether or not they will hold these documents until the license text is 
available. Of course, the license texts can only enter into effect after 
these documents have been approved.
The WG has not been informed by the Trust of their intended timeline for 
this work.

> [Note - I've read the sentence "This license is expressly
> granted under a license agreement
>    issued by the IETF
> over and don't understand what it means so it may be you just have to
> explain that to me].

The Trust Agreement is the document at 
<http://iaoc.ietf.org/docs/IETF-Trust-Agreement-Executed-12-15-05.pdf> - I 
assume that this needs to be pointed to in order to show that the Trust is 
the repository of all IETF IPR - but I'm not sure why the pointer needs to 
exist either, and would like commentary on that from the WG.

>  I also find the restriction of these rights for
> "use within the IETF Standards process" very hard to understand. Does
> that mean some vendor could not use something that was limited to "within
> the IETF Standards process" to create an early implementation. If so,
> that would be a problem.

The vendor would have to use the license granted under -outgoing for such 
an implementation. The crucial difference from the license granted for work 
within the IETF Standards Process is that the vendor preparing an 
implementation can modify the code, but not modify the text of the 
contribution he is quoting from, in preparing his implementation.

> 3) Section 3.3 of incoming, 2nd para, last sentence. This says that
> sublicense of derivate works will be covered in outbound but outbound
> does not seem to grant any such rights. Given how we modify draft other
> people wrote, and paste email other people wrote into drafts, it seems we
> need the Trust to grant the right to create derivative works of
> Contributions. It is not clear to me that this is provided in outbound.

The text you're referring to says

   The IETF Trust's policies concerning the
   granting of sublicenses to make derivative works will be guided by
   RFC [-outbound].

The language used in -outbound section 4 is:

   The IETF grants rights to copy and modify parts of IETF contributions
   in order to meet the objectives described earlier.

This uses "grants rights" and "copy and modify" instead of the words 
"sublicense" and "derivative works". I see very good argument that we 
should harmonize the two - does the WG, the IESG or the IETF Lawyer have 
any strong opinion on which way we harmonize them?
(I like "grants rights to copy and modify" myself, but there may be others 
with a different opinion)

>
> 4) In outbound, the term contributions never seems to be defined. I think
> it would be good to make it very clear it was the definition form
> incoming and consistently have it start with a capital later to indicate
> it was the same term.

I have asked the -outbound editor to explicitly state that terminology is 
imported from -incoming, and to declare -incoming a normative reference.
It was always the intent to use the same terminology in both documents, but 
we'd forgotten to be explicit about it.

> 5) outbound section 4.2. Title implies this is about Contributions but
> text implies it is only about IETF documents. Which is it? This should be
> made consistent to avoid future debates. Similarly section 4.4 implies
> Contributions in title but only seems to talk about RFCs.

The text is wrong; both sections are intended to apply to IETF 
Contributions.
(the legal basis, if anyone should turn totally rabid and assert something 
different, for me assuming permission to quote from the text I'm quoting in 
this message, is that the DISCUSS text is a "contribution" to the IETF, and 
I'm therefore allowed to quote freely from it under these paragraphs' 
grant).

> removes the liability limitation in license legend. Are we expecting that
> the legend would be reproduced in any license that contained extracted
> code? I find this whole topic very murky in the current document and do
> not understand what we are telling the Trust they need to do.

The WG discussed all sorts of limitations that one could imagine we'd want, 
including the "legends must be preserved", and ended up with the current 
language. We couldn't think of any restriction of this type that would not 
be totally ludicrous in some context or other - so the WG ended up not 
recommending anything.

The documents try to be clear that legends are stuff that the Trust can 
insist on inserting into special kinds of contributions, to make it simple 
for users to figure out that these rules apply - a contribution without the 
legends is still a contribution, has an implicit grant of license, and can 
be sublicensed by the IETF Trust - the legends are a convenience for the 
reader, not a requirement for getting the right things to happen. We expect 
the Trust to require legends in I-Ds, but we don't expect the Trust to 
require legends on emails to the IETF list; but the same rights are granted 
in both cases.

Any suggestions on how to make this clearer?

> Comment [2008-06-04]:
>
> It might be good to add an appendix to this document that contains the
> initial text that needs to be placed at the legends URL so there are no
> delays or surprises figuring that out. (Or if that is just a direct copy
> of something else, provide a pointer to it).

I'd prefer not to - this was discussed in the WG, and recommended against. 
Any copy that is in the RFC will be an opportunity for confusion in the 
case where the current text is different from the one in the RFC.

> In outbound, section 4.3, do you want to add "pseudo code" to the list. I
> seem to recall some IETF preference to pseudo code over any particular
> programming language.

The WG discussed pseudocode, and explicitly rejected the notion of 
including it. Most of the arguments for allowing modification of code don't 
apply to pseudocode; any casting of a pseudocode algorithm into a specific 
programming language is going to be a rewriting, not a modification.

> Section 4.5 of outbound. I've asked three other people to read section
> 4.5 and they have all come to somewhat different conclusions about what
> it means. You should consider if you need to make it more explicit -
> perhaps an example.

What were the differences in opinions?

> Incoming section 3.4, 2nd para, "the" -> "The"

I can find only one para in incoming section 3.4. Misalignment?

> adding it to the definition for "Contribution" (1.a) in

Since charter drafts are certainly "statements to the IETF", I think this 
is covered. At the moment, section 1a doesn't mention any class of document 
explicitly, concentrating instead on the form and addressee of 
communication; I'd like to keep it that way.

>
> I also note that the iab has explicitly requested that the iab stream be
> in scope.  That made me
> should be considered in scope for the IETF stream, but I can't find a
> reference that clearly specifies that.  Do we need to make a
> declaration like that in
> section 11 for our

This is out of scope for the WG to have opinions about....

>     RFC Editor <[email-masked]
> <mailto:[email-masked]>>,      ipr mailing list
> <[email-masked] <mailto:[email-masked]>>,      ipr chair
> <[email-masked] <mailto:[email-masked]>> Subject:
> Protocol Action: 'Rights Contributors provide to the
>          IETF Trust' to BCP
>

I would remove "among others" here to make the language work better; 
others' use of the RFC series is not a defining criterion.

Apart from that, I like this change.

>    contacted. See Section 11 for a declaration from the IAB on this

See commentary above; the change here does not go far enough to resolve the 
issue.

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 12 Jun 2008 08:04:49 +0200

>> NEW: k. "RFC": the publication series used by the IETF among others.

Makes sense (see below)

---
> important to have a consistent terminology, even when it's not
> immediately the obvious one.

1(g) is rather convoluted with a backwards reference to 1(a), which
are the contributions, boiling down to various cases of "note well".

> - Replace "IETF Standards Process" with "IETF Process" throughout
> both documents

That's clearer.

---
> <http://iaoc.ietf.org/docs/IETF-Trust-Agreement-Executed-12-15-05.pdf>
> - I assume that this needs to be pointed to in order to show that the
> Trust is the repository of all IETF IPR - but I'm not sure why the 
> pointer needs to exist either, and would like commentary on that from
> the WG.

RFC 4748 has a link to the Trust PDF, maybe the draft tries to preserve
this.  RFC 4371 also has this link, the draft has a normative reference
to RFC 4371, and RFC 4371 has a normative reference to the Trust PDF. 
    
I have no clear idea what the statement found by Cullen means, can the
editors please explain what it says ?  Could this simply be removed ?

---
> I like "grants rights to copy and modify" myself

+1  

---
> We expect the Trust to require legends in I-Ds

Oh yes, preferably at the end and after a "--<SP>" tear line.
 
> Any suggestions on how to make this clearer?

No.  The Trust is not going to pull the upper case disclaimer
in I-Ds based on the use of "in any way" found by Cullen.  If
folks don't have this disclaimer in their derivative work it's
their problem, not the problem of the Trust.

--- 
 
> I can find only one para in incoming section 3.4. Misalignment?

3.4, s/2nd para/2nd statement/ => /the IETF makes/The IETF makes/

BTW, the ToC in incoming is broken, it has no pages, resulting in
no links with rfcmarkup, that needs to be fixed.  

---
>> I know that -iesg documents should be considered in scope for
>> the IETF stream, but I can't find a reference that clearly
>> specifies that.  Do we need to make a declaration like that in
>> section 11 for our
 
> This is out of scope for the WG to have opinions about....

We're asked for an opinion, aren't we ?  There are no "IESG" RFCs,
they are just ordinary non-WG IETF RFCs with individual author(s).
If the IESG could really write their own RFCs they would have to
be approved by the IAB, that's far too convoluted for ersatz-IONs.
And they won't approve wannabe-IESG RFCs if they don't like them.

---
 
> others' use of the RFC series is not a defining criterion.

Also fine.

---
 Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Jun 2008 09:43:36 +1200

On 2008-06-12 16:04, Harald Tveit Alvestrand wrote:
...
> consistent use of the term.

I think we should follow counsel's advice on this point. It will
only really matter if a dispute ends up in court and if the document
concerned spent some or all of its life *not* on the standards
track. I also think that consistency with RFC 3979, which defines
and mainly uses "IETF Standards Process" (but uses "IETF process"
twice), is desirable.

...
> exist either, and would like commentary on that from the WG.

I would think that a clear pointer to the legal entity is useful,
to convince an outside reader that there really is such an entity.
But again, I suggest we do exactly what counsel advises on this.

> contribution he is quoting from, in preparing his implementation.

iirc this was quite a rough consensus call, but there was a clear
preference in the WG to restrict text modifications, to avoid vendors
using language similar to but subtly (and deceptively) different
from an RFC in product documentation.

    Brian

---

From: "TSG" <[email-masked]>
Date: Thu, 12 Jun 2008 15:16:25 -0700

Brian

> and mainly uses "IETF Standards Process" (but uses "IETF process"

the issue is not whether a dispute ends up in Court, but rather when the
first one winds up in Court and what the liability profile of the IETF is
then.

Todd Glassey

---

From: "Contreras, Jorge" <[email-masked]>
Date: Wed, 18 Jun 2008 18:48:09 -0400

> and mainly uses "IETF Standards Process" (but uses "IETF process"

Either "IETF Processes" or "IETF Standards Process" would be fine.  
The term will be defined formally, so the choice of labels should be
 whatever makes the most sense.  Note that "IETF Standards Process" 
has been used previously in RFC 3978, so there could be some benefit
in the historical consistency.

> But again, I suggest we do exactly what counsel advises on this.

Unlike a corporation, a trust does not have a charter filed with the
state.  
Thus, the only document "authenticating" its existence is the Trust
Agreement.  
I do not believe it's necessary to link to the Trust Agreement, but see
no harm 
in doing so, as the document is publicly-available.
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipr-wg

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 23 Jun 2008 23:30:59 -0700

Hi Herald,

I'd been waiting for Jorge's reply before responding to this but  
sounds like we are pretty much on the same page. Few things inline. My  
apologies for this taking so long.

The only signifiant issue in my inline comments is about the timing of  
approving this vs. the timing of the Trust approving it's licensing  
document. It would be good to get the WG's advice on what the IESG  
needed to do for this. It sort of sounds like they need to be done at  
the same time.

Cullen

On Jun 11, 2008, at 9:04 PM, Harald Tveit Alvestrand wrote:

> Cullen,
>
> I'll attempt to comment on your points below - just a few words  
> first about the format.
>
> I'm trying to figure out, for each of the comments of your DISCUSS,  
> whether it falls into one or the other case of:
>
> - There's unclear language in the document, and it needs improvement  
> before approval

I'd probably say it *might* need improvement or some of these could  
just be a case of I did not read it carefully enough. For things in  
the later, I'm happy to have people point out how it works and clear  
the discuss with no change to the document.

> - You have an opinion that is different from the consensus of the WG

I hope there are none of these - I don't think there are. If there  
are, educate me on what the WG wanted and I can correct the DISCUSS.

> contained in your "comments" section,

I view all my comments as things the authors & wg can consider but  
don't need to reply to me in any way about them - if they want to make  
a change because of them, fine, if they don't want to change anything  
because of them, that is fine too.

> while the "DISCUSS" section is a matter of clarity of writing, and a  
> couple of errors in the text.
>
> If you (and the WG, and the rest of the IESG) agree with my  
> understanding on these points, I'll ask the editors to prepare  
> revised versions of the drafts incorporating the required changes.  
> We may need to discuss the specific form of the changes some more.
>
> --On Tuesday, June 10, 2008 01:34:12 AM +0200 Harald Tveit  
> Alvestrand <[email-masked]> wrote:
>
>> Cullen Jennings:
>>
>> Discuss [2008-06-04]:
>>
> This is the single right that is granted by a license described in  
> the -incoming document (a BCP, which the Trust is expected to be  
> obliged to follow) and not in the -outgoing document (an Info, which  
> is intended as guidance to the Trust, and may be departed from if  
> the Trust has to). Section 5.4 of -incoming.

I was mistakenly looking for this in outbound. Thanks for clearing  
this up for me.

> This WG has asked the Trust to prepare such text; it's up to the  
> IESG whether or not they will hold these documents until the license  
> text is available. Of course, the license texts can only enter into  
> effect after these documents have been approved.

Does the WG have any suggestions on what the IESG should do here? Or  
to put it another way, if the IESG approves these, will contributes be  
in violation of the license agreements up until the time that the  
Trust does something that complies with section 5.4 of incoming?

>
> The WG has not been informed by the Trust of their intended timeline  
> for this work.
>
> The Trust Agreement is the document at <http://iaoc.ietf.org/docs/IETF-Trust-Agreement-Executed-12-15-05.pdf 
> > - I assume that this needs to be pointed to in order to show that  
> the Trust is the repository of all IETF IPR - but I'm not sure why  
> the pointer needs to exist either, and would like commentary on that  
> from the WG.

ok - I'm fine with however this gets clarified but it seems like it  
might need a slight change

> The vendor would have to use the license granted under -outgoing for  
> such an implementation. The crucial difference from the license  
> granted for work within the IETF Standards Process is that the  
> vendor preparing an implementation can modify the code, but not  
> modify the text of the contribution he is quoting from, in preparing  
> his implementation.

sounds good. Again this came out of my confusion about the inbound/ 
outbound split so this make sense now

> "sublicense" and "derivative works". I see very good argument that  
> we should harmonize the two - does the WG, the IESG or the IETF  
> Lawyer have any strong opinion on which way we harmonize them?
> (I like "grants rights to copy and modify" myself, but there may be  
> others with a different opinion)

Makes sense - I'm fine with however this get resolved assuming that  
both Jorge and WG are happy with it.
> I have asked the -outbound editor to explicitly state that  
> terminology is imported from -incoming, and to declare -incoming a  
> normative reference.
> It was always the intent to use the same terminology in both  
> documents, but we'd forgotten to be explicit about it.

thanks

> (the legal basis, if anyone should turn totally rabid and assert  
> something different, for me assuming permission to quote from the  
> text I'm quoting in this message, is that the DISCUSS text is a  
> "contribution" to the IETF, and I'm therefore allowed to quote  
> freely from it under these paragraphs' grant).

works for me. So will this be updated slightly to clarify it is  
Contributions?
> The WG discussed all sorts of limitations that one could imagine  
> we'd want, including the "legends must be preserved", and ended up  
> with the current language. We couldn't think of any restriction of  
> this type that would not be totally ludicrous in some context or  
> other - so the WG ended up not recommending anything.
>
> The documents try to be clear that legends are stuff that the Trust  
> can insist on inserting into special kinds of contributions, to make  
> it simple for users to figure out that these rules apply - a  
> contribution without the legends is still a contribution, has an  
> implicit grant of license, and can be sublicensed by the IETF Trust  
> - the legends are a convenience for the reader, not a requirement  
> for getting the right things to happen. We expect the Trust to  
> require legends in I-Ds, but we don't expect the Trust to require  
> legends on emails to the IETF list; but the same rights are granted  
> in both cases.
>

Nope, you have fully clarified how murky this is :-) After talking to  
a few people about the discussions in the WG I understand how you  
arrived at this text and am fine with it as is.

> I'd prefer not to - this was discussed in the WG, and recommended  
> against. Any copy that is in the RFC will be an opportunity for  
> confusion in the case where the current text is different from the  
> one in the RFC.

OK

> including it. Most of the arguments for allowing modification of  
> code don't apply to pseudocode; any casting of a pseudocode  
> algorithm into a specific programming language is going to be a  
> rewriting, not a modification.

Fair enough.

> What were the differences in opinions?

One person thought it meant that GPL licensed code could be put in a  
draft (and marked as GPL) because that did not restrict the rights.  
One person thought it meant that GPL could not because it could not be  
used in all things that IETF code might be able to but something like  
BSD license code could be. The third argued that code under pretty  
much any of the standard source code license could not be included  
because the license was different than the IETF licenses.

The argument centered around the meaning of "any
    additional license referred to by permitted additional text must not
    in any way restrict the rights the IETF intends to grant to others
    for using the contents of IETF contributions."

The last person argued that it was impossible to have any meaningful  
license that was compliant with the above sentence. The other two  
people argued that fact you had a whole section about this and it did  
not start with "Additional license are not allowed." meant that some  
license must be allowed.

All three were engineers/geeks and not not lawyers and none had  
followed the WG.

> I can find only one para in incoming section 3.4. Misalignment?

Oops meant 2nd sentence in first para of 3.4 - trivial typo the RFC Ed  
will catch

OLD
  their Contributions. the IETF
NEW
  their Contributions. The IETF

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Jun 2008 09:33:45 +1200

On 2008-06-24 18:30, Cullen Jennings wrote:
> 
> Hi Herald,
> 
> I'd been waiting for Jorge's reply before responding to this but sounds
> like we are pretty much on the same page. Few things inline. My

The Trust needs to tell us how long it thinks this will take, but it seems
to me that the IESG could proceed with approval with a condition
attached ("this approval becomes effective when the Trust does X"),
to avoid a deadly embrace. Then it will still be necessary to synchronise
the RFC Editor with the Trust (and the I-D tools too, which was
the hardest thing last time we changed the boilerplate), but at least
the IESG will be out of the loop.

    Brian

    Brian
>> I'll attempt to comment on your points below - just a few words first
>> about the format.
>>
> I'd probably say it *might* need improvement or some of these could just
> be a case of I did not read it carefully enough. For things in the
> later, I'm happy to have people point out how it works and clear the
> discuss with no change to the document.
> 
>>
> I hope there are none of these - I don't think there are. If there are,
> educate me on what the WG wanted and I can correct the DISCUSS.
> 
>>
>>
> I view all my comments as things the authors & wg can consider but don't
> need to reply to me in any way about them - if they want to make a
> change because of them, fine, if they don't want to change anything
>> understanding on these points, I'll ask the editors to prepare revised
>> versions of the drafts incorporating the required changes. We may need
>> to discuss the specific form of the changes some more.
>>
>> -incoming document (a BCP, which the Trust is expected to be obliged
>> to follow) and not in the -outgoing document (an Info, which is
>> intended as guidance to the Trust, and may be departed from if the
>> Trust has to). Section 5.4 of -incoming.
> 
> I was mistakenly looking for this in outbound. Thanks for clearing this
> up for me.
> 
>>
>>
>> whether or not they will hold these documents until the license text
>> is available. Of course, the license texts can only enter into effect
>> after these documents have been approved.
> 
> Does the WG have any suggestions on what the IESG should do here? Or to
> put it another way, if the IESG approves these, will contributes be in
> violation of the license agreements up until the time that the Trust
> does something that complies with section 5.4 of incoming?
> 
>>
>> granted for work within the IETF Standards Process is that the vendor
>> preparing an implementation can modify the code, but not modify the
>> text of the contribution he is quoting from, in preparing his
>> implementation.
> 
> sounds good. Again this came out of my confusion about the
> inbound/outbound split so this make sense now
> 
>>
>>
>> should harmonize the two - does the WG, the IESG or the IETF Lawyer
>> have any strong opinion on which way we harmonize them?
> Makes sense - I'm fine with however this get resolved assuming that both
> Jorge and WG are happy with it.
>>
>>
>>>
>> I have asked the -outbound editor to explicitly state that terminology
>> is imported from -incoming, and to declare -incoming a normative
>> reference.
>> something different, for me assuming permission to quote from the text
>> I'm quoting in this message, is that the DISCUSS text is a
>> "contribution" to the IETF, and I'm therefore allowed to quote freely
>> from it under these paragraphs' grant).
> 
>> The WG discussed all sorts of limitations that one could imagine we'd
>> want, including the "legends must be preserved", and ended up with the
>> current language. We couldn't think of any restriction of this type
>> that would not be totally ludicrous in some context or other - so the
>> WG ended up not recommending anything.
>>
>> implicit grant of license, and can be sublicensed by the IETF Trust -
>> the legends are a convenience for the reader, not a requirement for
>> getting the right things to happen. We expect the Trust to require
>> legends in I-Ds, but we don't expect the Trust to require legends on
>> emails to the IETF list; but the same rights are granted in both cases.
>>
> Nope, you have fully clarified how murky this is :-) After talking to a
> few people about the discussions in the WG I understand how you arrived
> at this text and am fine with it as is.
> 
>>
>>
>>> Comment [2008-06-04]:
>>>
>> confusion in the case where the current text is different from the one
>> in the RFC.
> 
> OK
> 
>>
>>
>> including it. Most of the arguments for allowing modification of code
>> don't apply to pseudocode; any casting of a pseudocode algorithm into
>> a specific programming language is going to be a rewriting, not a
>> modification.
> 
> Fair enough.
> 
>>
>>
> draft (and marked as GPL) because that did not restrict the rights. One
> person thought it meant that GPL could not because it could not be used
> in all things that IETF code might be able to but something like BSD
> license code could be. The third argued that code under pretty much any
> of the standard source code license could not be included because the
> license was different than the IETF licenses.
> 
> license that was compliant with the above sentence. The other two people
> argued that fact you had a whole section about this and it did not start
> with "Additional license are not allowed." meant that some license must
> be allowed.
> 
> All three were engineers/geeks and not not lawyers and none had followed
> the WG.
> 
>>
>>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 27 Jun 2008 10:12:15 -0700

> the IESG will be out of the loop.

This sounds like a good plan - I'm trying to think of the mechanics of  
how to cause this to happen. What about  we ask the the RFC Editor to  
hold this in Auth 48 until the authors have verified that the Trust  
has published a license agreement that meets the requirements of this  
document. Then we add a note to the document that this document will  
come into force only when published by the RFC Editor and not  as soon  
as it is approved by IESG. Seems like this would solve the sequencing  
issues and would also avoid the IESG having to keep track of when the  
trust documents got finished.

Sound reasonable? Could you propose a RFC Editor and IESG note that  
could be attached? Or propose some other plan that looks like a good  
one to you. I'm happy with any plan that solves this problem. I'd need  
to make sure other IESG folks were OK but I don't anticipate any  
problems.

Cullen

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 28 Jun 2008 11:04:46 +0200

Cullen Jennings wrote:
  
> has published a license agreement that meets the requirements of 
> this document
[...]
> Sound reasonable?

Yes. 

 > propose a RFC Editor and IESG note

Your text above is fine, s/authors/authors and responsible AD/ for the
RFC editor note.  Add "the IESG note shall be removed on publication",
with an IESG note stating that "the RFC shall be considered in force
when it is published" or similar (as opposed to when it is approved).

 Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Jun 2008 09:45:36 +1200

> when it is published" or similar (as opposed to when it is approved).

I agree, cut and paste into the tracker ;-)

    Brian