headers
Internet-Drafts | 1 Mar 2007 21:50
Picon
Favicon

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

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Intellectual Property Rights Working Group of the IETF.

	Title		: Rights Contributions provide to the IETF Trust
	Author(s)	: S. Bradner, J. Contreras
	Filename	: draft-ietf-ipr-3978-incoming-00.txt
	Pages		: 18
	Date		: 2007-3-1
	

   The IETF policies about rights in Contributions to the IETF are
   designed to ensure that such Contributions can be made available to
   the IETF and Internet communities while permitting the authors to
   retain as many rights as possible. This memo details the IETF
   policies on rights in Contributions to the IETF. It also describes
   the objectives that the policies are designed to meet.  This memo
   obsoletes RFC 3978 and, with RFC 3979 and RFC xxx (-outgoing),
   replaces Section 10 of RFC 2026.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipr-3978-incoming-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
(Continue reading)

Permalink | Reply | 5 comments |
headers
Brian E Carpenter | 2 Mar 2007 11:26
Picon
Favicon

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian E Carpenter | 2 Mar 2007 12:07
Picon
Favicon

Re: IANA-maintained MIB copyright question

On 2007-01-29 19:33, Harald Tveit Alvestrand wrote:
> 
> 
> --On 29. januar 2007 09:48 +0100 Brian E Carpenter <brc <at> zurich.ibm.com> 
> wrote:
> 
>> I believe Jorge has recommended (2003-2007), which would
>> require an annual update.
>>
>> I fear it can't be an ION for the simple reason that the
>> existing URL is embedded in the MIBs concerned.
> 
> Not logical. The MIBs don't say anything about what's at the other end 
> of that URL.
> It could be a pointer to an ION as easily as it could be any other web 
> page. (And if the ION experiment is deemed a failure, we just point the 
> pointer somewhere else).
> 
>> And I
>> think in the end it's an operational detail that the
>> Trust and IASA should take care of.
> 
> Agreed.
> 

For now, following the approval of draft-heard-rfc4181-update-00.txt,
I have asked the secretariat to make the necessary update of
http://www.ietf.org/copyrights/ianamib.html

     Brian
(Continue reading)

Permalink | Reply | 1 comment |
headers
Simon Josefsson | 2 Mar 2007 12:16
Favicon
Gravatar

Section 7 of draft-ietf-ipr-3978-incoming-00.txt normative or not?

Please clarify whether section 7 is normative or not.

I recall that Scott Bradner referenced to section 7 as an argument
that the IETF policy grants third parties various rights, but I
believe such an argument is flawed.  The title of section 7 is:

7. Exposition of Why These Procedures Are the Way They Are

Thus I believe the entire chapter was intended to be non-normative.

It is unfortunate that text in section 7 may not appear to say the
same as the normative part of the document, but making it clear that
section 7 is non-normative would be a good starting point.  We can fix
the factual problems in section 7 later.

Therefor, I suggest inserting as the first sentence in section 7 the
following:

   This entire section is not normative.  Thus, in case of conflict
   with normative text on a subject, the normative text has priority.

What do you think?

/Simon
Permalink | Reply | 0 comments |
headers
Simon Josefsson | 2 Mar 2007 12:43
Favicon
Gravatar

Third parties rights grants in draft-ietf-ipr-3978-incoming-00.txt

All,

As far as I can see, this document leaves no rights granted to third
parties.  That is against both RFC 2026 and RFC 3978.  RFC 2026 grants
third parties rights in the boiler plate, section 10.4

         This document and translations of it may be copied and
         furnished to others, and derivative works that comment on or
                      ^^^^^^
         otherwise explain it or assist in its implmentation may be
         prepared, copied, published and distributed, in whole or in
         ...

RFC 3978 section 3.3 was intended to do the same, but the wordings
were poorly chosen, and the third parties now granted rights only
include the loosely defined recipient "IETF":

   a. To the extent that a Contribution or any portion thereof is
      protected by copyright and other rights of authorship, the
      Contributor, and each named co-Contributor, and the organization
      he or she represents or is sponsored by (if any) grant a
      perpetual, irrevocable, non-exclusive, royalty-free, world-wide
      right and license to the ISOC and the IETF under all intellectual
                                            ^^^^
      property rights in the Contribution:

However, to clarify, Jorge has said that the following term in RFC
3978 section 3.3 give third parties additional rights directly:

      (E) to extract, copy, publish, display, distribute, modify and
(Continue reading)

Permalink | Reply | 3 comments |
headers
Joel M. Halpern | 2 Mar 2007 14:29

Re: Third parties rights grants in draft-ietf-ipr-3978-incoming-00.txt

I apparently understand the goal slightly differently from the way Simon does.
I agree that -incoming does not talk about direct grants of third 
party rights in documents.
That's because we (the working group) agreed on the -incoming / 
-outbound split whereby the -outbound document describes all rights 
granted to others in IETF contributions, while -inbound talks about 
the rights the authors grant to the IETF in 
contributions.  (-incoming rights clearly needing to be a superset of 
-outbound.)  Hence, it is almost inevitable that this is going to 
tighten up the 3978 language that provides indirect grants.

Yours,
Joel M. Halpern

At 06:43 AM 3/2/2007, Simon Josefsson wrote:
>All,
>
>As far as I can see, this document leaves no rights granted to third
>parties.  That is against both RFC 2026 and RFC 3978.  RFC 2026 grants
>third parties rights in the boiler plate, section 10.4
>
>          This document and translations of it may be copied and
>          furnished to others, and derivative works that comment on or
>                       ^^^^^^
>          otherwise explain it or assist in its implmentation may be
>          prepared, copied, published and distributed, in whole or in
>          ...
>
>RFC 3978 section 3.3 was intended to do the same, but the wordings
>were poorly chosen, and the third parties now granted rights only
(Continue reading)

Permalink | Reply | 1 comment |
headers
todd glassey | 2 Mar 2007 14:36
Picon
Favicon

Re: IANA-maintained MIB copyright question

Jorge - doesn't the (C) belong at the bottom of this page and not the top?
Also this page is a tad twisted in that it talks about its own copyright in
the same language as what its trying to impart to the MIBS...

Not concerning those changes mandated by 4181, I would do something like 
this
to make it clearer than what is at:
http://www.ietf.org/copyrights/ianamib.html now.

---
Orig:
---

Full Copyright Statement for IANA maintained MIB modules.

Copyright (C) The Internet Society (2003). All Rights Reserved.

An IANA MIB module and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all such
copies and derivative works. However, this MIB module itself may not be
modified in any way, such as by removing the copyright notice or references
to the Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian E Carpenter | 2 Mar 2007 15:53
Picon
Favicon

Re: Third parties rights grants in draft-ietf-ipr-3978-incoming-00.txt

If we are strict, the normative text in -incoming must only
obtain rights, to be vested in the IETF Trust, and then the
Trust must give the outgoing rights, in accordance with
the advice in -outbound. But logically, -incoming could
meet this test by saying the equivalent of

   Contributor must grant to the Trust necessary and
   sufficient rights for the Trust to be able to grant the
   following outbound rights to third parties: XXXX, YYYY, ...

      Brian

On 2007-03-02 14:29, Joel M. Halpern wrote:
> I apparently understand the goal slightly differently from the way Simon 
> does.
> I agree that -incoming does not talk about direct grants of third party 
> rights in documents.
> That's because we (the working group) agreed on the -incoming / 
> -outbound split whereby the -outbound document describes all rights 
> granted to others in IETF contributions, while -inbound talks about the 
> rights the authors grant to the IETF in contributions.  (-incoming 
> rights clearly needing to be a superset of -outbound.)  Hence, it is 
> almost inevitable that this is going to tighten up the 3978 language 
> that provides indirect grants.
> 
> Yours,
> Joel M. Halpern
> 
> At 06:43 AM 3/2/2007, Simon Josefsson wrote:
>> All,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Harald Alvestrand | 3 Mar 2007 12:16
Picon

Re: Third parties rights grants in draft-ietf-ipr-3978-incoming-00.txt

Simon Josefsson wrote:
> All,
>
> As far as I can see, this document leaves no rights granted to third
> parties. 
The intent of this document is that it should say what rights others 
grant to the IETF Trust, so that the IETF Trust can follow the 
instructions in -outgoing and grant rights to third parties according to 
current IETF policy. (Currently, I believe -outgoing says that those 
grants should be irrevocable - just mentioning that so that nobody feels 
they have to raise the issue of revocation again).

So if you can't find any rights granted in this document, the document 
is as was intended. If you can help us find and remove any text that 
seems to say that the document should have granted rights to others, 
that is a Good Thing.

                 Harald
Permalink | Reply | 0 comments |
headers
Frank Ellermann | 3 Mar 2007 14:47
Picon
Picon

Re: Case study: SHA2

Simon Josefsson wrote:

> How this looks to me is that we have a patented technology published
> in an RFC with code licensed in a way that is incompatible with the
> IETF copying conditions, major free software licenses, and several
> proprietary software licenses.

Yes, something is odd with SHA and RFC 4634.  Thanks for submitting
<https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=795>

Frank
Permalink | Reply | 1 comment |

Gmane