Subject: WG Last Call for IPR -incoming document

From: Harald Alvestrand <[email-masked]>
Date: Mon, 26 Nov 2007 11:23:11 +0100

This is the WG Last Call for the following document:

"Rights Contributors provide to the IETF Trust"
draft-ietf-ipr-3978-incoming-03.txt, dated November 13, 2007

with the modification that in section 5.10, the word "requested" is 
changed to "directed".
(The document describes a model that is somewhat different from the one
that has traditionally been assumed with regard to authors' rights to 
use text; the change to "directed" emphasizes that the WG thinks that it 
is essential to have the Trust do as directed here.)

The WG Last Call includes the option of raising issues with the outgoing
document, draft-ietf-ipr-outbound-rights-04.txt, which had a WG Last 
Call in July of this year, as long as those issues are concerned with:

1) Resolution of issues raised at that Last Call
2) Changes between version -03 and -04
3) Issues that pertain to the relationship between "-outgoing" and
"-incoming".

This last call starts today, Monday, November 26, and will run until
Monday, December 17, 2007 - a time period that includes an IETF meeting 
and a face-to-face meeting of the working group. This allows us an 
opportunity to discuss specific issues at the face-to-face meeting, if 
participants desire to do so.

The call is three weeks, to make room for the fact that not much review 
happens during the IETF meeting. We emphasize that in order to have 
issues discussed during the meeting, they must be raised on the mailing 
list BEFORE the WG meeting.

To raise an issue, please send a message to the WG mailing list with the
subject line "ISSUE: <incoming|outgoing> <section>: <short description> -
for instance "ISSUE: incoming 6: missing comma".

If the WG chair accepts the issue, or support is shown by other
participants for accepting the issue, a tracker number will be assigned.

For strictly editorial issues, please send mail directly to the editors.

Happy reviewing!

                        Harald Alvestrand, WG chair

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 26 Nov 2007 13:30:58 +0100

> Happy reviewing!

1.I http://www.ietf.org/legends (404)  
How about s/Legend instructions/Boilerplates/ ?
Of course that would also affect later uses of this term.

1.L s/submitted t/submitted to/ + s/Section4/Section 4/
3.1 s/See Section 5.3/see Section 5.3/
3.2 s/IETF and/The IETF and/ + s/IETF asks/The IETF asks/

| two exceptions to this requirement: documents describing proprietary
| technologies and documents that are republications of the work of
| other standards organizations.

What about GPLed (BSDed, GFDLed, CCed, etc.) technologies ?
IIRC an example was Simon's new B64 RFC without sample code.

3.4 s/grant IETF Trust/grant the IETF Trust/
    s/requires each/requires (from|that) each/ (???)
    s/authorize IETF/authorize the IETF/

Okay, enough of that, just check all "IETF" for missing
articles, or ignore any case of bad DEnglish on my side.

3.6
| the copyright in documents that are published as RFCs 
| (other than Informational RFCs and RFCs that are submitted
| as RFC Editor Contributions).

Why exclude _all_ "Informational RFCs" ?  Some are quite
important (e.g. 1591 or 3696).

4. RFC Editor Documents

Did anybody bother to ask them if they wish to adopt the
same rules ?  I once tried to create a "minimal legalese"
draft, and somebody informed me that the RFC editor does
not use the old exceptional rules for independent drafts.

5.3
| provided that when reproducing Contributions, trademark
| and service mark identifiers used in the Contribution,
| including TM and (R), will be preserved.

What does that mean ?  Somebody proposed that I add a four-
letter word starting with U and ending with X to a draft,
in how much trouble am I or is the IETF Trust after this
modification ?  Not containing any (R) or TM or what else,
just the four-letter word.  It used to be an nroff-macro
more than a decade ago automatically adding legalese, but
that was still about the old old owner (ATT).

In another draft now published as RFC somebody used the
term "Sender ID", meaning something that's NOT related
to the same or similar trademark in a part of the world.
Is that a problem, and if yes, whose problem, author, or
IETF, or IETF Trust ?

5.4 [TRUST LICENSE DOCUMENT].

Missing reference.  Does this already exist, or is it
something the Trust is expected to create based on this
draft (+ outgoing, etc.) ?

5.6d
| The Contributor has not intentionally included in the
| Contribution any material which is defamatory or untrue

BTW, a recently Last Called draft claims that ISO uses a
"democratic framework".  

5.6e
| All trademarks, trade names, service marks and other
| proprietary names used in the Contribution that are
| reasonably and personally known to the Contributor are
| clearly designated as such where reasonable.

Ugh, okay, I'll remove the U-word a.s.a.p. from my draft.
Won't help with the already published RFC 3977.  Don't we
have a ploicy somewhere that RFCs should NOT mention any
trademarks, because the concepts vary wildly in different
parts of the world ?  Besides RFCs _MUST_NOT_ be spam :-(

5.8 Trademarks

Again that topic, why isn't that a part of 5.3 D ?  This
section apparently (ab)uses an RFC 3797 procedure without
an "updates 3979", I'm not sure if that's okay.

5.9  That section was apparently written by somebody else,
please limit the use of "such" somehow:  "such contributor"
tends to be confused by EULAs, and in doubt ignores them ;-)

6. Legends ("boilerplates")

Didn't we agree on adding boilerplates at the end in the
future ?  I miss that detail in the draft.  I hope it's
also clear that editors and authors must have the right to
withdraw their text before publication, if they don't agree
with any added "notices", notably any "IESG notes".

| 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 organization.  Such exceptions must be approved on an
| individual basis by the IAB.

See above, what about GPLed etc. code samples ?  (Disclaimer,
I never used it for one of my own texts except from some dual-
licensed contributions on the openspf.org pages, and maybe on
wikipedia)

7
| there are no known issues of security with IETF Contribution
| rights policies.

Please replace that by an earlier note in the introduction:

| This document is not intended as legal advice. Readers are
| advised to consult their own legal advisors if they would
| like a legal interpretation of their rights or the rights of
| the IETF Trust in any Contributions they make.

 Frank

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 26 Nov 2007 14:54:55 +0100

Intro: I'm not tracking any of these as "issues" at the moment. Since 
you didn't use the "ISSUE" protocol, I'm assuming that you intend this 
as editorial comment and input for discussion.

Commentary below.

> Of course that would also affect later uses of this term.
The secretariat will not create this until the document has been approved.
> 3.2 s/IETF and/The IETF and/ + s/IETF asks/The IETF asks/
I take this as editorial nits.
> IIRC an example was Simon's new B64 RFC without sample code.
All those aren't technologies, they're licenses. What did you want to say?
> articles, or ignore any case of bad DEnglish on my side.
Editorial. Thanks.
> not use the old exceptional rules for independent drafts.
The RFC Editor has to do what the RFC Editor does.
We've tried once before (3978) with the "and btw the same rules are used 
for the RFC Editor", and IMHO it was just additional confusion.
> that was still about the old old owner (ATT).
I think that by submitting the contribution, you have asserted that all 
trademarks that need to be acknowledged are acknowledged. Others might 
disagree with you. But I still don't add the (TM) every time I say "Unix".
> Is that a problem, and if yes, whose problem, author, or
I don't know.
> draft (+ outgoing, etc.) ?
The Trust is expected to create that. Separate agenda item for Vancouver.
> BTW, a recently Last Called draft claims that ISO uses a
I guess the submitter believed it, then....
> parts of the world ?  Besides RFCs _MUST_NOT_ be spam :-(
"where reasonable" covers a multitude of sins :-)
> an "updates 3979", I'm not sure if that's okay.
Which RFC were you pointing to?
5.3 (D) is a right granted by the contributor. 5.8 is an assurance.
> future ?  I miss that detail in the draft. 
All punted to "Legend Instructions".
>  I hope it's
It's not clear to me. The RFC Editor's procedures say so for individual, 
but in the case of a WG document, I think the rights of a contributor 
are limited to having his name taken off the author list if he doesn't 
like the WG output. Anyway, I don't think it's a matter for THIS document.
> licensed contributions on the openspf.org pages, and maybe on
They're not permitted. Most deliberately.
> | the IETF Trust in any Contributions they make.
That's not "security" as ommonly understood. But worth repeating.

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 27 Nov 2007 09:00:32 +0100

Harald Alvestrand wrote:
 
> you didn't use the "ISSUE" protocol

Actually I wanted to use your "REVIEW" protocol, but then I 
forgot to change the subject, and you didn't announce it here
as possibility. ;-)

>>> Happy reviewing!
[...]

> All those aren't technologies, they're licenses. What did you

I wanted to say that "GPLed" is just a variant of "proprietary",
if defined as "not public domain".  There are various special
rules for "proprietary" or "other SDO", and I don't see why
these special rules can't be used for say "GPLed" code samples,
or whatever it takes to get Simon's sample code in Simon's RFC.

> We've tried once before (3978) with the "and btw the same
> rules are used for the RFC Editor", and IMHO it was just
> additional confusion.

That's not how I recall it.  3978 has several special rules
for independent submissions, those weren't used by the RFC
editor, they used the "same" (= corresponding) rules as for
IETF RFCs.  If that's what they really want the "incoming"
RFC could be simplified.  Assuming that the IETF Trust gets
_all_ RFCs finally.

  [5.8]
>> why isn't that a part of 5.3 D ?  This section apparently
>> (ab)uses an RFC 3797 procedure without an "updates 3979",
>> I'm not sure if that's okay.
   
> Which RFC were you pointing to?

RFC 3979, the IPR procedure.  Extended by the -outgoing I-D
to trademarks.

> in the case of a WG document, I think the rights of a
> contributor are limited to having his name taken off the
> author list if he doesn't like the WG output.

Okay, makes sense, and for a WG document any "IESG note" is
hopefully limited.

>> what about GPLed etc. code samples ?
[...]   
> They're not permitted. Most deliberately.

Then it *IS* an issue, if there's a loophole for proprietary
code samples there should be exactly the same "IAB-loophole"
for GPLed (or similar) code samples.

  [security consideration]
>> | like a legal interpretation of their rights or the rights
>> | of the IETF Trust in any Contributions they make.
   
> That's not "security" as ommonly understood. But worth repeating.

In a draft about legal issues the "security considerations"
can be about legal issues.  Better than hiding this disclaimer
somewhere deep in the intro.

 Frank