Re: Last Call on draft-bradner-rfc3979bis-08.txt ("Intellectual Property Rights in IETF Technology")
Pete Resnick <presnick@qti.qualcomm.com> Mon, 11 April 2016 17:17 UTC
Return-Path: <presnick@qti.qualcomm.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7333812F1D3 for <ietf@ietfa.amsl.com>; Mon, 11 Apr 2016 10:17:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.017
X-Spam-Level:
X-Spam-Status: No, score=-8.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKSlQr1Yd_Fs for <ietf@ietfa.amsl.com>; Mon, 11 Apr 2016 10:17:27 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9511812F1DA for <ietf@ietf.org>; Mon, 11 Apr 2016 10:17:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1460395047; x=1491931047; h=from:to:subject:date:message-id:in-reply-to:references: mime-version; bh=2ar7WMPqksOvD2NIK9g3YzSiQG71bRS8n1wNXKhmXM8=; b=ABHWRPcEvDaHLfRMN0v2z4UfohtpDZtpbjpaGnPha5xc3n/S50AMqyi7 cVlzEQWs5WJgGXDFjKyXyyUwDihwHgugdNJhKXoAO9vh07eqa3QahGkAG H/AmnVMYiEIT0D3ruEjCTz+cULKlKmTxSV3Qm6HtX2lfOoDBIelj1ZShn A=;
X-IronPort-AV: E=Sophos;i="5.24,462,1455004800"; d="scan'208";a="279174864"
Received: from ironmsg03-r-new.qualcomm.com (HELO Ironmsg03-R.qualcomm.com) ([10.53.140.107]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Apr 2016 10:17:23 -0700
X-IronPort-AV: E=McAfee;i="5700,7163,8132"; a="1119815764"
Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 Apr 2016 10:17:23 -0700
Received: from [10.64.163.124] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 11 Apr 2016 10:17:22 -0700
From: Pete Resnick <presnick@qti.qualcomm.com>
To: IETF <ietf@ietf.org>
Subject: Re: Last Call on draft-bradner-rfc3979bis-08.txt ("Intellectual Property Rights in IETF Technology")
Date: Mon, 11 Apr 2016 12:17:21 -0500
Message-ID: <E7E31E22-1C86-40C4-BC5B-F65132015EF5@qti.qualcomm.com>
In-Reply-To: <0000431F-F977-4A24-BA4D-064F740977A0@piuha.net>
References: <0000431F-F977-4A24-BA4D-064F740977A0@piuha.net>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.4r5239)
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To NASANEXM01F.na.qualcomm.com (10.85.0.32)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/-eWKxFmGug1so4Hy5YkiGP81tUs>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2016 17:17:29 -0000
Some questions and comments, much of them editorial, though nonetheless important: - Section 2: The third paragraph of 3979 section 2 (with the 2026 "principles") was deleted. I kinda liked it. Can we put it back in? So basically I'm suggesting: OLD Section 1 defines... NEW RFC 2026, Section 10 established three basic principles regarding the IETF dealing with claims of Intellectual Property Rights: (a) the IETF will make no determination about the validity of any particular IPR claim (b) the IETF following normal processes can decide to use technology for which IPR disclosures have been made if it decides that such a use is warranted (c) in order for the working group and the rest of the IETF to have the information needed to make an informed decision about the use of a particular technology, all those contributing to the working group's discussions must disclose the existence of any IPR the Contributor or other IETF participant believes Covers or may ultimately Cover the technology under discussion. This applies to both Contributors and other participants, and applies whether they contribute in person, via email or by other means. The requirement applies to all IPR of the participant, the participant's employer, sponsor, or others represented by the participants, that is reasonably and personally known to the participant. No patent search is required. Section 1 defines... END - Section 4: A bunch of (D) (what was section 4.1 from 3979) was deleted. It seemed like sensible stuff. Why was it removed? Was it just the 2026 reference? Couldn't we just update that to refer to 6410? - Section 5.2.1 (A): The stuff after the first sentence is more completely described in 5.4.2. How about a forward reference here instead: OLD For example, if the Contribution is an update to a Contribution for which an IPR disclosure has already been made and the applicability of the disclosure is not changed by the new Contribution, then no new disclosure is required. But if the Contribution is a new one, or is one that changes an existing Contribution such that the revised Contribution is no longer Covered by the disclosed IPR or would be Covered by new or different IPR, then a new disclosure must be made. NEW See section 5.4.2 for a discussion of when updates need to be made for an existing disclosure. END - Section 5.4.2(A): A couple of cleanups items in this section, and one concern. First, the cleanup: Clause (2) could use the same "unless" clause that (1) and (3) have; if you've got enough info regarding the patent application in the disclosure to find that it's been abandoned, there shouldn't be a hard requirement to update the disclosure. Also, clause (4) says "causes the Disclosure to be covered" when it should say "causes the Contribution to be covered". But even leaving that aside, clause (4) is a really a noop: If there is a material change to the document, that is in and of itself a new contribution, and is therefore addressed by section 5.1 or the "inherited by revisions" sentence at the bottom of 5.4.2(A). So, for the first part of 5.4.2(A), I suggest the following: OLD A. An IPR disclosure must be updated or a new disclosure made promptly after any of the following has occurred: (1) the publication of a previously unpublished patent application, (unless sufficient information to identify the published application was disclosed when the unpublished application was disclosed), (2) the abandonment of a patent application (3) the issuance of a patent on a previously disclosed patent application (unless sufficient information to identify the issued patent was disclosed when the patent application was disclosed), (4) a material change to the IETF Document covered by the Disclosure that causes the Disclosure to be covered by additional IPR. NEW A. An IPR disclosure must be updated or a new disclosure made promptly after any of the following has occurred unless sufficient information was provided when the original disclosure was made to discover the status of the patent or patent application: (1) the publication of a previously unpublished patent application, (2) the abandonment of a patent application, or (3) the issuance of a patent on a previously disclosed patent application. END As far as the concern, the second part of the next sentence in 5.4.2(A) is worrisome: If a patent has issued, then the new IPR disclosure must include the patent number and, if the claims of the granted patent differ from those of the application in manner material to the relevant Contribution, the IPR disclosure must describe any differences in applicability to the Contribution. The first part is fine, though it repeats what's in 5.4.1 already, so I think it can be dropped. But the second part is what I'm concerned about. We've never before required disclosures to determine and discuss the applicability of the disclosure to the Contribution, and nowhere else in this document is that mentioned. Indeed, we go to great lengths to say that the leadership of the IETF doesn't try to figure out applicability, and that even WGs or the IESG can only take into account their opinions of what the applicability is. As a general rule, I don't think we can ask people who disclose to do the analysis to determine what parts of the patent do or do not apply to a particular contribution. As we say elsewhere, that's really up to a court. So I think the above should just be dropped. A few editorial ones suggested by some lawyer friends. They all seem eminently sensible to me: - Section 5.5(A): s/i.e./e.g. - Section 5.5(B): s/royalty rates/royalties. I'm told that there are royalties that might not have "rates" associated with them. - Section 5.5(C): Two things: OLD and will attach to the associated IPR NEW and will attach, to the extent permissible by law, to the associated IPR END I'm told that there are some jurisdictions where you may not be able to do that. OLD must ensure that such commitments are binding on any subsequent transferee of the relevant IPR. NEW must ensure that such commitments are binding on a transferee of the relevant IPR, and that such transferee will use reasonable efforts to ensure that such commitments are binding on a subsequent transferee of the relevant IPR, and so on. END The object of the "subsequent" wasn't clear, so this just spells it out. Wordy, but more precise. - Section 7, paragraph 6: The only change in this paragraph from 3979 was to add the word "all" in the second-to-last sentence. My lawyer friends tell me that this little change is opening a can of worms, having to do with licensing to makers of parts instead of implementers of the whole specification. I don't think we meant to change the meaning from the 3979 meaning, and I certainly don't think that we meant to change some implication about whether folks in general needed to license to people that make parts where they wouldn't have before. Was there something unclear about that sentence that needed the word "all" added to it? We aren't making a substantive change, are we? Can we just strike it? It seemed pretty clear to me before. pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478
- Last Call on draft-bradner-rfc3979bis-08.txt ("In… Jari Arkko
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Russ Housley
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Scott Bradner
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Brian E Carpenter
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … John C Klensin
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … John C Klensin
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Sam Hartman
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … John C Klensin
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Harald Alvestrand
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … John C Klensin
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Brian E Carpenter
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Sam Hartman
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Gonzalo Camarillo
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Scott Bradner
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Spencer Dawkins at IETF
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Russ Housley
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Jari Arkko
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Scott O. Bradner
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Scott O. Bradner
- RE: Last Call on draft-bradner-rfc3979bis-08.txt … Michael Cameron
- RE: Last Call on draft-bradner-rfc3979bis-08.txt … Michael Cameron
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Scott O. Bradner
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Brian E Carpenter
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Alissa Cooper
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Brian E Carpenter
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … joel jaeggli
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Stephan Wenger
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Brian E Carpenter
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Eggert, Lars
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Stephan Wenger
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Barry Leiba
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Stephan Wenger
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Barry Leiba
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Barry Leiba
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Spencer Dawkins at IETF
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … John C Klensin
- RE: Last Call on draft-bradner-rfc3979bis-08.txt … Michael Cameron
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Ben Campbell
- RE: Last Call on draft-bradner-rfc3979bis-08.txt … John C Klensin
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … John C Klensin
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Stephan Wenger
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Brian E Carpenter
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Jari Arkko
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Scott Bradner
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Stephan Wenger
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Barry Leiba
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … joel jaeggli
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … John C Klensin
- RE: Last Call on draft-bradner-rfc3979bis-08.txt … Michael Cameron
- RE: Last Call on draft-bradner-rfc3979bis-08.txt … John C Klensin
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Stephan Wenger
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … joel jaeggli
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Pete Resnick
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Alissa Cooper
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … John C Klensin
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Alissa Cooper
- RE: Last Call on draft-bradner-rfc3979bis-08.txt … Michael Cameron
- RE: Last Call on draft-bradner-rfc3979bis-08.txt … John C Klensin
- RE: Last Call on draft-bradner-rfc3979bis-08.txt … Michael Cameron
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Joel M. Halpern
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Stephan Wenger
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Brian E Carpenter
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Brian E Carpenter
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … John C Klensin
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … John C Klensin
- RE: Last Call on draft-bradner-rfc3979bis-08.txt … S Moonesamy
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Jari Arkko
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Stephan Wenger
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Pete Resnick
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Stephan Wenger
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Stewart Bryant
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Brian E Carpenter
- Re: Last Call on draft-bradner-rfc3979bis-08.txt … Pete Resnick