Subject: Status of issues, November 13

From: Harald Alvestrand <[email-masked]>
Date: Tue, 13 Nov 2007 21:35:01 +0100

Here's what I have in the tracker at the moment:

- Issue 1212, 1273 and 1338 have all been punted to the "Legends" 
instructions to be prepared by the IETF trust, as informed by this WG's 
deliberation. Their titles:

1212    Legends: Copyright statements in I-Ds and RFCs
1273    Legends: How do we usefully define "excerpt"?
1338    Legends: Notices "normally placed at the end"

- Issue 1339 has been punted to the trust, since it is a question about 
what the current licenses permit, and the trust is the current holder of 
all the rights the IETF can permit use of.
Title:* 1339 <https://rt.psg.com/Ticket/Display.html?id=1339>**Trust: 
Does RFC 3978 3.3.a.(E) grant third parties rights to modify source 
<https://rt.psg.com/Ticket/Display.html?id=1339>

- *Issue 1500: *Outgoing LC 6.3: SW licensing 
<https://rt.psg.com/Ticket/Display.html?id=1500> has the following 
resolution, which I think was agreed to in Chicago:

Text proposed by David Black on the list, July 18 2007:

The IETF Trust should avoid adding software license
obligations beyond those already present in a contribution,
so as to strictly maintain the broadest possible rights
of extraction, modification and use by anyone in any way
desired. Extraction, modification and use of code outside
the IETF includes creation of further derived works
that may carry additional license obligations.

*As of outgoing -04, this is section 5.3, with the following text:

As such, the rough consensus is that the IETF Trust is to grant
rights such that code components of IETF contributions can be
extracted, modified, and used by anyone in any way desired. To
enable the broadest possible extraction, modification and usage, the
IETF Trust should avoid adding software license obligations beyond
those already present in a contribution. The granted rights to
extract, modify and use code should allow creation of derived works
outside the IETF that may carry additional license obligations. As
the IETF trust can not grant rights it does not receive, the rights
to extract, modify and use code described in this paragraph can not
be granted in IETF contributions that are explicitly marked as not
permitting derivative works.

If anyone thinks that this issue is not resolved, speak up.

- Issue 1511,  Incoming 5.10: Back-license to document authors in 
resulting RFCs, has the following recorded proposed resolution:

5.10. Contributors retention of rights

Although contributors provide specific rights to the IETF, it
is not intended that this should deprive them of any rights
in their contributions. To underwrite this principle, the
IETF Trust is requested to issue a form of license to contributors
which ensures that they may each make use of their contributed
material as published in an RFC in any way they wish, subject only
to the restriction that no contributor has the right to represent
any document as an RFC, or equivalent to an RFC, if it is not a
full and complete copy or translation of the published RFC.

This will be included in version -03 of -incoming, when that gets 
through the I-D publication system (which still has a few issues).

A suggested change is to modify "the IETF Trust is requested" to "the 
IETF Trust is directed".

That's all at this time.... WG Last Call on the documents (not on the 
issues punted to "legends") will be sent out as soon as -03 hits the I-D 
directories.

                         Harald

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 14 Nov 2007 11:03:11 +0100

> As such, the rough consensus is that the IETF Trust is to grant
[...]

Nit, it's a "rough consensus of the WG" at the moment when you
say so.  

The "rough (or not) consensus of the IETF" will be determined
after a Last Call by the IESG.

  Frank

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 Nov 2007 11:03:51 -0500

We went through this before.
The document is written as "the rough consensus of the IETF" because
otherwise we have to change the document after the last call, which is
not what is supposed to happen.
It is understood that the document does not reflect IETF rough consensus
until that last call has happened.
But then, the documented is not approved (i.e. confirmed to represent
any rough consensus) until after that last call.

Joel

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 15 Nov 2007 15:49:55 +0100

There is a semantic difference between getting consensus about X, and
getting consensus about that there is consensus about X.

Normally, documents are written to state X as true, and the consensus
process verifies that we have consensus around X being true.

This seems like a minor problem, but it does seems real to me.  The way
to resolve it is to remove the text that claim there is consensus around
X, and simply state X instead.

/Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Nov 2007 07:45:58 +1300

I disagree. The draft is a draft RFC and should contain
the words we want to see in the RFC. It is the act of
IESG approval of the draft text following an IETF
Last Call that declares IETF consensus.

      Brian

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 19 Nov 2007 08:26:29 +0100

> We went through this before.

Yes, and we kind of agreed to disagree.

Harald needs to know how "rough" it will get, and when 
I wrote "nit" he can deduce that it is not too hot for a 
Last Call attempt.

On the other hand when somebody, I fear it was me, 
suspected "stupidity or corruption" four characters in 
Sender ID had to be checked by the IAB. :-|

Likewise "can of worms and suicidal" about a recent 
attempt of LTRU to endorse new country codes could
be interpreted as "process failure in progress". :-(

 Frank