IESG evaluation of our documents, current version

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

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 <[e-mail]>
From: IESG Secretary <[e-mail]>
Reply-To: IESG Secretary <[e-mail]>
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 <[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.


  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
[e-mail]
https://www.ietf.org/mailman/listinfo/ipr-wg