Subject: Re: IETF Last Call for two IPR WG Dcouments

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 25 Mar 2008 21:30:54 -0600

Russ Housley wrote:
> During the Wednesday Plenary at IETF 71, I gave the IETF community a 
> "heads up" on two documents from the IPR WG that were nearing IETF 
> Last Call.  Both of the documents have now reached IETF Last 
> call.  The Last Call announcements are attached.  Please review and comment.

I've given these drafts a first reading. The following comments may
represent a misunderstanding on my part, but I provide them in the
interest of clarifying the meaning of these drafts.

One concern I have is the distinction between text and code. Where and
how is that line drawn? What about, for example, protocol examples (of
which there are many in most RFCs)? Are they text or code?

Another concern is the limitation on copying of text. It seems quite
reasonable for developers to include snippets of text in their programs
(think literate programming), and under many code licenses it is
difficult if not impossible to separately license the code and any
copied text when bundled together.

Regarding the copying of text, Section 4.4 of the outgoing draft says:

   There is no consensus at this time to permit the use of text from
   RFCs in contexts where the right to modify the text is required.  The
   authors of IETF contributions may be able and willing to grant such
   rights independently of the rights they have granted to the IETF by
   making the contribution.

But Section 6 of the incoming draft says:

   It is also important to note that additional copyright notices 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 development
   organization.  Such exceptions must be approved on an individual
   basis by the IAB.

So it's not clear to me how contributors could (easily) grant the right
to modify text that is copied from an RFC -- unless they do so outside
the Internet Standards Process (based, I suppose, on the rights retained
by the contributors). However, it seems that each implementor would need
to separately approach the contributors in order to do that (and how
would they know that the contributors are approachable in that way if
not through inclusion of some kind of notice in the relevant RFC -- and
would such a notice comprise an "additional copyright notice" as
described in Section 6 fo the incoming draft?).

Finally, the outbound draft merely provides recommendations regarding
license text and other materials, final definition of which seems to be
under the sole purview of the Trustees of the IETF Trust. However, the
outbound draft does not specify if the work of the Trustees shall be
subject to review by the IPR WG, the IESG, the IAB, or the IETF
community (e.g., in the form of an Internet-Draft) before it takes effect.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 26 Mar 2008 00:23:16 -0400

Comments in response to your comments on -outbound...
Firstly, thank you for reading these.
Second, what follows are my understandings of the reasons / contents.

> which there are many in most RFCs)? Are they text or code?

The document provides two ways to distinguish code from text.  It lists 
a set of constructs that are considered code.  Recognizing that things 
change, the draft indicates that the trustees shall maintain a list of 
such code.  The also says that the trustees shall come up with a marking 
mechanism so working groups can mark other things that need to be 
considered code, since there are often special cases.

This distinction was the working group rough consensus (as determined by 
the chairs), after MUCH discussion.

> copied text when bundled together.

The question of whether to allow arbitrary modifications of all text 
from RFCs was discussed.  While there are some drawbacks of the 
agreement that was reached, in terms of the ability to use text from the 
RFC as documentation in programs which by license are subject to 
arbitrary change, there are also serious concerns about allowing 
arbitrary changes of text.  The text of RFCs often represents careful 
work to get the right meaning.  Arbitrary, well intentioned changes, may 
often introduce unintended problems.  (The discussion covered many 
related aspects, many of which I can not recreate on the fly.)
Obviously, this is closely related to the decision to create the code / 
text distinction.

> described in Section 6 fo the incoming draft?).
Indeed, any such grant would have to be outside the IETF process.  A 
legal notice is not what is needed to let folks know there are other 
options.  An informational note is quite different from a legal notice.

> community (e.g., in the form of an Internet-Draft) before it takes effect.

The decision to exclude legal text from the outbound document was a 
deliberate working group decision.  Having working groups write legal 
text has produced problems repeatedly.  So we concluded that was a bad 
way to proceed.  The question of how the trust will proceed to do its 
job is outside of this working groups purview.  The trustees have said 
it will take direction from the IETF.  I presume they will come up with 
a reasonable strategy for verifying that what they produce does what the 
community has said it wants.
In the worst case, if the community concludes that the trustees actions 
aren't what we want, we can either replace the trustees or write another 
IETF RFC.  Trying to work that out in this draft did not seem productive.

> Peter

Yours,
Joel M. Halpern

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 26 Mar 2008 15:25:29 +0100

> which there are many in most RFCs)? Are they text or code?

the -outgoing draft contains this text:

   IETF contributions often include components intended to be directly
   processed by a computer.  Examples of these include ABNF definitions,
   XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values,
   MIBs, ASN.1, or classical programming code.

And, recognizing that it's impossible to come up with a closed list of such
items that is valid for all time:

   While it is up to the Trustees of the IETF Trust to determine the
   best way of meeting this objective, two mechanisms are suggested here
   that are believed to be helpful in documenting the intended grant to
   readers and users of IETF contributions.

   Firstly, the Trustees of the IETF Trust should maintain, in a
   suitable, easily accessible fashion, a list of common RFC components
   which will be considered to be code.  To start, this list should
   include at least the items listed above.  The Trustees of the IETF
   Trust will add to this list as they deems suitable or as it is
   directed by the IETF.

   Additionally, the Trustees of the IETF Trust should define a textual
   representation to be included in an IETF contribution to indicate
   that a portion of the document is considered by the authors (and
   later the working group, and upon approval the IETF) to be code, and
   to be subject to the permissions granted to use code.

I don't think protocol examples are code - they're not written in a 
parseable language. OTOH, if someone were to write protocol examples using 
an ASCII representation of ITU-T's TTCN, that would probably be code, and 
the IETF Trust should update their list to include that format.

> described in Section 6 fo the incoming draft?).

Exactly; this is no change from the current copying conditions for RFCs. In 
fact, the code copying conditions are more permissive than the status quo 
ante.

A note claiming that "this text is also available from source X, check 
copying conditions there" would not be a copyright notice.
I don't think "this text is also available under GFDL from source X" is a 
copyright notice either; it's a license, not a copyright notice.

> community (e.g., in the form of an Internet-Draft) before it takes effect.

No, it does not. I'd like someone from the Trust to speak up about their 
thoughts about suitable review processes.

Note that the IPR WG can't do the review going forward; once these 
documents are approved (if they are), I intend to ask that the group is 
shut down.

                Harald

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 26 Mar 2008 14:14:31 -0600

Harald Tveit Alvestrand wrote:
> parseable language. OTOH, if someone were to write protocol examples
> using an ASCII representation of ITU-T's TTCN, that would probably be
> code, and the IETF Trust should update their list to include that format.
> 
> Exactly; this is no change from the current copying conditions for RFCs.
> In fact, the code copying conditions are more permissive than the status
> quo ante.
> 
> I don't think "this text is also available under GFDL from source X" is
> a copyright notice either; it's a license, not a copyright notice.

OK, thanks for the clarification. I just wanted to be sure.

> thoughts about suitable review processes.

Yes, that would be appreciated.

> documents are approved (if they are), I intend to ask that the group is

That seems sensible.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Mar 2008 10:06:20 +1300

>> <[email-masked]> wrote:

<snip>

>> documents are approved (if they are), I intend to ask that the group is

Also note that appeal and recall procedures for the IAOC are
defined in RFC 4071, and that clearly includes Trust actions,
since the Trustees are by definition the IAOC members. So if
the IETF doesn't like the final result, there is recourse.

    Brian

---

From: Sam Hartman <[email-masked]>
Date: Thu, 27 Mar 2008 00:08:24 -0400

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:

    Brian> Also note that appeal and recall procedures for the IAOC
    Brian> are defined in RFC 4071, and that clearly includes Trust
    Brian> actions, since the Trustees are by definition the IAOC
    Brian> members. So if the IETF doesn't like the final result,
    Brian> there is recourse.

However much less recourse than normal.  The appeal of the IAOC
decisions is intentionally fairly limited.  Honestly, I think our real
recourse if the IETF didn't agree with the trust's general policy is
to hit them over the head with a BCP.