headers
Harald Tveit Alvestrand | 6 Jul 16:02
Picon

WG LAST CALL on the -outgoing document

As of last week, the community has been able to see what I hope closely 
approximates a final version of our -incoming rights document: 
draft-ietf-ipr-3978-incoming-01, published June 28.

Given that this is now present, I believe it is time to start the WG Last 
Call on draft-ietf-ipr-outbound-rights-03.txt, published April 30.

This Last Call will run from today, July 6, 2007, and end in 2 weeks, on 
Friday, July 20, 2007, just prior to the next IETF meeting, where the IPR 
WG has a scheduled slot on Monday, July 23.

The list of issues raised against -outgoing will form one part of the 
agenda in Chicago; the other part of the agenda will be looking at 
-incoming.

IF YOU HAVE AN ISSUE WITH draft-ietf-ipr-outbound-rigths-03 going to the 
IESG for processing as a BCP document, please do the following:

- Send a message to the IPR WG list with a subject line of the format "LC 
ISSUE: OUTGOING <section>: <your issue>".

If you have an issue with the principles of the -incoming document, please 
do NOT use this format, but rather use a descriptive subject line, and have 
discussion on the list.

The chair will attempt to get all issues so noted into the issue tracker 
before Chicago, and we will go through them there.

The chair reserves the possiblity of not recording some issues, if that 
seems like obviously the right thing to do (for instance, if two people
(Continue reading)

Permalink | Reply | 20 comments |
headers
Brian E Carpenter | 12 Jul 09:59
Picon

LC ISSUE: OUTGOING Sections 2 and 3: Editorial [Re: WG LAST CALL on the -outgoing document]

It's inappropriate to use RFC 2119 terminology in this document.
Section 2 should be deleted and any use of the capitalized words
should become lower case.
(draft-peterson-informational-normativity-00.txt will tell you why.)

Section 3 is completely redundant and should be deleted.

Otherwise, I support this version for BCP.

     Brian

On 2007-07-06 16:02, Harald Tveit Alvestrand wrote:
> As of last week, the community has been able to see what I hope closely 
> approximates a final version of our -incoming rights document: 
> draft-ietf-ipr-3978-incoming-01, published June 28.
> 
> Given that this is now present, I believe it is time to start the WG 
> Last Call on draft-ietf-ipr-outbound-rights-03.txt, published April 30.
> 
> This Last Call will run from today, July 6, 2007, and end in 2 weeks, on 
> Friday, July 20, 2007, just prior to the next IETF meeting, where the 
> IPR WG has a scheduled slot on Monday, July 23.
> 
> The list of issues raised against -outgoing will form one part of the 
> agenda in Chicago; the other part of the agenda will be looking at 
> -incoming.
> 
> IF YOU HAVE AN ISSUE WITH draft-ietf-ipr-outbound-rigths-03 going to the 
> IESG for processing as a BCP document, please do the following:
>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Black_David | 12 Jul 17:19

LC ISSUE: OUTGOING Section 6.3: vague s/w licensing guidance

I asked a lawyer to review the -outgoing document, and the following
text in Section 6.3 turned up a concern:

   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. 

The concern is that the software licensing implications of that
text are not clear to someone who has not been following our
discussions and hence the text could be *misread* as permitting or
encouraging the use of licenses with copyleft (aka viral or
share-alike) and/or patent license provisions.

While it should be the case that code in IETF RFCs can be placed
under almost any software license, (including those with copyleft
and patent license provisions), the IETF Trust should not be doing
so on its own initiative.

Hence, in the outbound document, I think it would be good to add
a statement that the IETF Trust should avoid adding software license
obligations beyond those already present in a contribution, and noting
that both copyleft and patent license provisions in software licenses
depart from the goal of "extracted, modified and used by anyone in
any way desired," but also noting that the ability to place extracted
code under such licenses is an important aspect of "use in any
way desired."

This also impacts the inbound document, but that'll be a separate
thread.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Black_David | 12 Jul 17:52

Incoming - software licenses

I just sent a Last Call issue on software licenses and the -outgoing
document, which I think is a clarification issue.  The interaction
of software licenses and the incoming document is more "interesting".
I should apologize in advance to Simon, as I think he's been over this
ground in much more detail, and I have not had the time to review
what he's done.

There should be a general goal that if incoming code has a software
license, then that license should be consistent with the following
provision of the outbound document:

   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.

and so use of licenses that are not consistent (e.g., copyleft,
patent provisions) ought to be discouraged when there's an alternative.
When there's no alternative, things appear to get "interesting".
Some of these licenses could prevent contribution of code to IETF
because they restrict the copyright grant to the IETF Trust
(Section 5.3 of -incoming) in a fashion that cannot be dealt
with by prohibiting derivative works.

Let me stop here to allow the WG chair to determine whether
discussion of the "interesting" consequences is in scope.  At a
minimum, we probably ought to agree on goals (e.g., do we want to
be able to accept GPL-licensed code in contributions?, should this
be a normal or exceptional procedure?) before discussing mechanisms
to achieve the goals.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Scott Brim | 12 Jul 19:47
Picon
Favicon

Re: LC ISSUE: OUTGOING Sections 2 and 3: Editorial [Re: WG LAST CALL on the -outgoing document]

On 07/12/2007 03:59 AM, Brian E Carpenter allegedly wrote:
> It's inappropriate to use RFC 2119 terminology in this document.
> Section 2 should be deleted and any use of the capitalized words
> should become lower case.
> (draft-peterson-informational-normativity-00.txt will tell you why.)

The problem that Jon points to is that requirements documents aren't
normative but standards track RFCs reference them as normative because
they have what he (not 2026 or 2119) has decided to call "normative"
terminology.  Here we have a rather different problem, which is that
the definitions of must, should etc. in 2119 refer to
"specifications".  The spirit of use it the same -- this document is a
requirements document (just don't ask me to define that) and clearly
defining the use of must, should, etc. is a good idea, but the
definitions in 2119 make assumptions.  If you want to do it completely
correctly, you might copy the definitions from 2119 but removing
references to "the specification".
Permalink | Reply | 2 comments |
headers
John C Klensin | 12 Jul 20:43

Re: LC ISSUE: OUTGOING Sections 2 and 3: Editorial [Re: WG LAST CALL on the -outgoing document]


--On Thursday, 12 July, 2007 13:47 -0400 Scott Brim
<sbrim <at> cisco.com> wrote:

> On 07/12/2007 03:59 AM, Brian E Carpenter allegedly wrote:
>> It's inappropriate to use RFC 2119 terminology in this
>> document. Section 2 should be deleted and any use of the
>> capitalized words should become lower case.
>> (draft-peterson-informational-normativity-00.txt will tell
>> you why.)
> 
> The problem that Jon points to is that requirements documents
> aren't normative but standards track RFCs reference them as
> normative because they have what he (not 2026 or 2119) has
> decided to call "normative" terminology.  Here we have a
> rather different problem, which is that the definitions of
> must, should etc. in 2119 refer to "specifications".  The
> spirit of use it the same -- this document is a requirements
> document (just don't ask me to define that) and clearly
> defining the use of must, should, etc. is a good idea, but the
> definitions in 2119 make assumptions.  If you want to do it
> completely correctly, you might copy the definitions from 2119
> but removing references to "the specification".

Scott,

Thanks for bringing this up, but I think the problem runs a
little deeper.  As you point out, we are in danger of playing
word games here, ones in which terminology is given a specific
(and retroactive and individual) definition and that definition
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian E Carpenter | 13 Jul 09:39
Picon

Re: LC ISSUE: OUTGOING Sections 2 and 3: Editorial [Re: WG LAST CALL on the -outgoing document]

...

>    The fact is that we have
> extensive precedents for the use of "RFC 2119 language", or at
> least uses of the words for which RFC 2119 offers a definition,
> in administrative and procedural documents.  We can stop doing
> that, but it seems to me that making elimination of that usage
> into a hard requirement requires community consensus, not just
> posting of an I-D.

Completely agree. But I stick to my comment, and to the fact that
it's editorial. I have no objection to the MUSTs in the outgoing
draft but citing 2119 to justify them seems wrong to me. In fact,
I don't see what the document would lose if they were in lower
case.

    Brian
Permalink | Reply | 0 comments |
headers
Harald Tveit Alvestrand | 15 Jul 18:35
Picon

Re: LC ISSUE: OUTGOING Sections 2 and 3: Editorial [Re: WG LAST CALL on the -outgoing document]

Thanks for alerting me to Jon Peterson's document.

I'll try to get it read ASAP, and will try to tone my reaction down by 
about 7 orders of magnitude from my initial reaction.

What is the proper mailing list for discussing Jon's proposed text?

                 Harald

--On 12. juli 2007 09:59 +0200 Brian E Carpenter 
<brian.e.carpenter <at> gmail.com> wrote:

> It's inappropriate to use RFC 2119 terminology in this document.
> Section 2 should be deleted and any use of the capitalized words
> should become lower case.
> (draft-peterson-informational-normativity-00.txt will tell you why.)
>
> Section 3 is completely redundant and should be deleted.
>
> Otherwise, I support this version for BCP.
>
>      Brian
>
>
> On 2007-07-06 16:02, Harald Tveit Alvestrand wrote:
>> As of last week, the community has been able to see what I hope closely
>> approximates a final version of our -incoming rights document:
>> draft-ietf-ipr-3978-incoming-01, published June 28.
>>
>> Given that this is now present, I believe it is time to start the WG
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian E Carpenter | 16 Jul 09:43
Picon

Re: LC ISSUE: OUTGOING Sections 2 and 3: Editorial [Re: WG LAST CALL on the -outgoing document]


> What is the proper mailing list for discussing Jon's proposed text?

No idea...

For this WG, please forget I mentioned it. My point is only that "must"
is a perfectly clear English word and all we need for our draft.

     Brian
Permalink | Reply | 0 comments |
headers
Harald Alvestrand | 17 Jul 15:42
Picon

#1499 Outgoing LC 2 3: RFC 2119 terminology

Issue #1499 has been assigned to this issue.

Brian E Carpenter wrote:
> It's inappropriate to use RFC 2119 terminology in this document.
> Section 2 should be deleted and any use of the capitalized words
> should become lower case.
> (draft-peterson-informational-normativity-00.txt will tell you why.)
>
> Section 3 is completely redundant and should be deleted.
>
> Otherwise, I support this version for BCP.
>
>     Brian
>
>
> On 2007-07-06 16:02, Harald Tveit Alvestrand wrote:
>> As of last week, the community has been able to see what I hope 
>> closely approximates a final version of our -incoming rights 
>> document: draft-ietf-ipr-3978-incoming-01, published June 28.
>>
>> Given that this is now present, I believe it is time to start the WG 
>> Last Call on draft-ietf-ipr-outbound-rights-03.txt, published April 30.
>>
>> This Last Call will run from today, July 6, 2007, and end in 2 weeks, 
>> on Friday, July 20, 2007, just prior to the next IETF meeting, where 
>> the IPR WG has a scheduled slot on Monday, July 23.
>>
>> The list of issues raised against -outgoing will form one part of the 
>> agenda in Chicago; the other part of the agenda will be looking at 
>> -incoming.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane