Rights Contributors Provide to the IETF Trust
draft-ietf-ipr-3978-incoming-09

[Ballot discuss]
Only remanning issue is the topic of when these documents come into to force and if that needs to be after the publication of the Trust statement.

[Ballot comment]
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

[Ballot comment]
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"

[Ballot discuss]
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.

[Ballot comment]
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.

[Ballot comment]
The legend URL is currently non-existent. Was this intentional, i.e., that the content be created once this document has been approved, or is this a mistake?

[Ballot discuss]
draft-ietf-ipr-3978-incoming, Abstract
>    This memo
>    obsoletes RFC 3978 and 4748 and, with BCP 79 and RFC xxx (rfc editor
>    - replace with the RFC # of -outgoing), replaces Section 10 of RFC
>    2026.

  DISCUSS: "Obsoletes" and "Updates" relations should be indicated in
  the document header.


draft-ietf-ipr-3978-incoming, Section 11., paragraph 0:
> 11. Declaration from the IAB

  Discuss-discuss: Do we want to make a similar declaration from the
  IESG?

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.