Re: IESG evaluation of our documents, current version

[Harald Tveit Alvestrand <[e-mail]>]

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 
<[e-mail]> 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
>
> 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.

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

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

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

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

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?

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

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

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

>
>
>
>
> ^L
> ---- following is a DRAFT of message to be sent AFTER approval ---
> From: The IESG <[e-mail] <mailto:[e-mail]>>
> To: IETF-Announce <[e-mail] <mailto:[e-mail]>>
> Cc: Internet Architecture Board <[e-mail] <mailto:[e-mail]>>,
>     RFC Editor <[e-mail]
> <mailto:[e-mail]>>,      ipr mailing list
> <[e-mail] <mailto:[e-mail]>>,      ipr chair
> <[e-mail] <mailto:[e-mail]>> 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.

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.

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

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

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