Re: I-D ACTION:draft-ietf-ipr-3978-incoming-00.txt

I don't much care whether the rationale comes before
or after the normative content, but they need to be
very clearly separated and labelled as such. For example
the trademark section is hidden after the rationale.

> 2. Introduction
...
>    In order for works to be used within the IETF Standards Process or to
>    be published as Internet-Drafts, certain limited rights in all
>    Contributions must be granted to the IETF Trust and the IETF. In
>    addition, Contributors must make representations to IETF Trust and
>    the IETF regarding their ability to grant these rights. These
>    necessary rights and representations have until now been laid out in
>    Section 10 of [RFC2026]. In the years since [RFC2026] was published
>    there have been a number of times when the exact intent of Section 10
>    has been the subject of vigorous debate within the IETF community.
>    The aim of this document is to clarify various ambiguities in Section
>    10 of [RFC2026] that led to these debates and to amplify the policy
>    in order to clarify what the IETF is currently doing.

This text needs to be updated to refer to RFC 4748, 3978 and 3667.

> 2.1 No Retroactive Effect
>    This memo does not retroactively obtain additional rights from
>    Contributions that predate the publication of this memo as a RFC.

I would prefer this to read
   "that predate the approval for publication..."
so that we don't have an ambiguous interregnum while this document
is in the RFC queue.

> 2.2 Boilerplate updates by the IETF Trust
>    In the past the IETF has had to publish new RFCs to make editorial or
>    other minor updates to the boilerplate required on IETF Internet
>    Drafts.  This memo grants to the IETF Trust the explicit right to
>    approve minor boilerplate changes as long as any such changes are
>    consistent with philosophical goals of the current versions of the
>    BCPs defining the IETF's philosophical goals for contributions.  The
>    IETF Trust is also authorized to handle special cases and fix minor
>    errors.

Two problems.

(1) What is "minor" and who adjudicates? What happens if the Trust makes
a minor change and a community member claims it's major? At least
make it clear that the decision is appealable.

(2) I think it needs to be more explicit that this document contains an
initial version of the boilerplate and that it's expected that the Trust
will tune it.

(3) Boilerplate is scattered throughout the document. I'd rather
see all the boilerplate gathered in a single Appendix with very clear
statements about where it must appear in drafts and RFCs. Tool writers
will greatly appreciate this.

> 3.3. Rights Granted by Contributors to the IETF Trust
...
>       [editor question - since the IETF trust does not actually make
>       modified versions etc - should this say "permit the copying,
>       publication,  ... of the Contribution ..."]

Yes, I think so.

> 4. Rights in RFC Editor Contributions

Since draft-iab-rfc-editor clearly separates out responsibility
for non-IETF documents, I do not believe that this material
can be included here, without explicit IAB agreement.

> 5.4. Copyright Notice (required for all IETF Documents)
...
>    Copyright notices from other organizations or individuals are not
>    permitted in IETF Documents except in the case where such document is
>    the product of a joint development effort between the IETF and
>    another standards development organization or the document is a
>    republication of the work of another standards organization. Such
>    exceptions must be approved on an individual basis by the IAB.

Two points:

(1) I believe we should propose to give this authority to
the IESG. It's clumsy and time-wasting to go to the IAB.
The IAB establishes liaisons with other bodies, but the IESG
mainly operates them.

(2) I believe experience shows that the outright ban on other
copyright related statements is often misunderstood as restricting
authors' rights in some way. I'd suggest adding something like

   If an author wishes to allow republication or modification under
   more permissive conditions than those normally granted by the
   IETF, this should be accomplished outside the RFC process.

(this might need more explanatory text, but the point needs
to be made somehow)

      Brian