Re: Last Call on draft-bradner-rfc3979bis-08.txt ("Intellectual Property Rights in IETF Technology")

Stephan Wenger <stewe@stewe.org> Mon, 04 April 2016 20:07 UTC

Return-Path: <stewe@stewe.org>
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 D341B12D75E for <ietf@ietfa.amsl.com>; Mon, 4 Apr 2016 13:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 LoCPSrkMuPh9 for <ietf@ietfa.amsl.com>; Mon, 4 Apr 2016 13:07:15 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0707.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:707]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 620F612D14B for <ietf@ietf.org>; Mon, 4 Apr 2016 13:07:15 -0700 (PDT)
Received: from BLUPR17MB0275.namprd17.prod.outlook.com (10.162.235.146) by BLUPR17MB0274.namprd17.prod.outlook.com (10.162.235.145) with Microsoft SMTP Server (TLS) id 15.1.447.15; Mon, 4 Apr 2016 20:06:56 +0000
Received: from BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) by BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) with mapi id 15.01.0447.027; Mon, 4 Apr 2016 20:06:56 +0000
From: Stephan Wenger <stewe@stewe.org>
To: Barry Leiba <barryleiba@computer.org>
Subject: Re: Last Call on draft-bradner-rfc3979bis-08.txt ("Intellectual Property Rights in IETF Technology")
Thread-Topic: Last Call on draft-bradner-rfc3979bis-08.txt ("Intellectual Property Rights in IETF Technology")
Thread-Index: AQHRhDTbKR9yu1RueEWA9RrAiHSISp9yLyaAgAAKyYCAAE/KAIAAXo6AgAb/NoD//9ajAIAANauAgAADRgCAAClHgA==
Date: Mon, 04 Apr 2016 20:06:56 +0000
Message-ID: <972C83CB-99B7-4278-9962-9AF67CFE890E@stewe.org>
References: <0000431F-F977-4A24-BA4D-064F740977A0@piuha.net> <56FBF599.9080605@ericsson.com> <ACC702C9-C33F-4D38-B47A-8BC293D24621@sobco.com> <DCA1B6AC-6221-4CF5-A726-E1E98DBFAC27@vigilsec.com> <56FC90E5.1050908@gmail.com> <CAC4RtVD3Pxm_vZgdCCgPgDwNfnYeKFJ5_Ys3QQPezrHzTGJE+Q@mail.gmail.com> <C5F35DA9-C530-4EC6-B175-C4B0A18872D7@stewe.org> <CALaySJ+1rvxXnXmLxk1UJ88t-e2p24OyMhR3f6P0peA5fLhRGA@mail.gmail.com> <CALaySJKBrjKEdu-qd067Eb7A+nZFObB3TdwSV=od9GDjhDOecQ@mail.gmail.com>
In-Reply-To: <CALaySJKBrjKEdu-qd067Eb7A+nZFObB3TdwSV=od9GDjhDOecQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: computer.org; dkim=none (message not signed) header.d=none;computer.org; dmarc=none action=none header.from=stewe.org;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [31.133.179.232]
x-ms-office365-filtering-correlation-id: 26541a95-90be-4bea-b04a-08d35cc4ac5f
x-microsoft-exchange-diagnostics: 1; BLUPR17MB0274; 5:k6bLnRZIYBq74pSBDNNk0y/3XT5vfCI1cDn8/baJXKzCWZIs/v9pO/o2UdgAK0L1iFQlzwDQyYHwywmxso9i32vroVlDnhH8YHGPxuuH96sZ9kCNWqsQHB1lkDsa5ARtzqNRLOkpuXbJFgM2cDds1A==; 24:CdIQrb2Lk3scapAQdVw6s8FAPuiZUJ3OSArNSLDHLvlUnsk5KFEwVt6SjzQmRvrqxVpmUscFvMsZcs7yp56UNVrTmsxJ2fvcYfCry3mGbdI=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR17MB0274;
x-microsoft-antispam-prvs: <BLUPR17MB02747FB7C9AC5B99CA0CB85AAE9D0@BLUPR17MB0274.namprd17.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040046)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041046)(6043046); SRVR:BLUPR17MB0274; BCL:0; PCL:0; RULEID:; SRVR:BLUPR17MB0274;
x-forefront-prvs: 0902222726
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(53754006)(377454003)(24454002)(50986999)(2950100001)(76176999)(4326007)(54356999)(3280700002)(5008740100001)(2906002)(2900100001)(66066001)(36756003)(87936001)(1220700001)(81166005)(1096002)(10400500002)(77096005)(3846002)(92566002)(102836003)(586003)(11100500001)(6116002)(19580395003)(19580405001)(99286002)(16236675004)(83716003)(82746002)(33656002)(122556002)(5004730100002)(110136002)(189998001)(86362001)(3660700001)(106116001)(5002640100001)(230783001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR17MB0274; H:BLUPR17MB0275.namprd17.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_972C83CB99B7427899629AF67CFE890Esteweorg_"
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2016 20:06:56.2481 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR17MB0274
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/icR2koD2u45x-5ZF6EfedlSR3nQ>
Cc: IETF <ietf@ietf.org>
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, 04 Apr 2016 20:07:18 -0000

Hi all,

Barry and I had a chat about this.  I also had offline conversations with Mike Cameron and a chat with Joel.  Barry and I at least agree on the problems.  The solutions are mine for now, and they absolutely are in need of wordsmithing...

Based on the discussion so far, there seem to be a need for the following:

1. A clarification that an AD, by the nature of his/her office, regularly becomes aware of Contributions late in the process (for example at IETF Last Call) and, therefore, cannot be expected to disclose any IPR Covering those Contributions until such late time in the process.
To fix this point, a simple explanatory sentence somewhere in section 5.2.2 would suffice.  For example “By the nature of their office, IETF area directors regularly become aware of Contributions late in the process (for example at IETF Last Call) and, therefore and in such cases, cannot be expected to disclose any IPR Covering those Contributions until such late time in the process.”

The purpose of this sentence is to protect an AD and its sponsoring company from allegations, both within the IETF and in courts, that they disclosed late against policy.

2. A clarification or, more likely, a substantial change that, like any other individual in the IETF, also an AD has the option to recuse himself from involving himself/herself in the decision making process of a document, even a document in his own area. For example, an AD that did never comment on a document and abstained during the IETF Last Call would not incur a disclosure obligation, even if the Contribution were in his/her own area.

This second point is more tricky.  Is the formulation currently in the draft, which defines ADs as Participants, inline with what’s written in point 2?  I’m coming around to think that it does not.  Instead, I think we have a contradiction in the current draft—on one hand, an AD who intentionally stays away from influencing the decision process regarding a Contribution should not incur an obligation based on the underlying principle of the policy—no more than anyone else; but the text about ADs being Participants rules out that interpretation.  Having contradictions in patent policies is a Very Bad Idea since at least Rambus (ca. 2003).  Is that correct so far?

Based on the current formulation, and without violating the policy, an AD who is under the gun of his IPR department not to disclose a specific IPR has only the option to step down.  Is this what we want in each and every case?  Or would we rather be pragmatic and allow an AD to recuse himself/herself occasionally?  If yes, I think we need language indicating that such a mechanism is available, but also is meant to be used sparsely, and at least implying that ADs who are forced to use it more than under exceptional circumstances are indeed to step down.

The paragraph below tries to express this.  The markup will probably only be visible if you choose to view the HTML version of this email.

“
k. "Participating in an IETF discussion or activity": means making a
Contribution, as described above, or in any other way acting in
order to influence the outcome of a discussion relating to the
IETF Standards Process. Without limiting the generality of the
foregoing, acting as a working group chair or Area Director
constitutes "Participating" in all activities of the relevant
working group or area. "Participant" and "IETF Participant" mean
any individual Participating in an IETF discussion or activity.  Under
extraordinary circumstances only, an AD may choose not to Participate
in the discussion or activity of his/her area, recuse himself/herself
from IESG deliberations of related documents, and abstain during
the IESG ballot process, thereby not incurring the obligations based
on Participating.
"

Stephan


On 4/4/16, 11:39, "barryleiba@gmail.com<mailto:barryleiba@gmail.com> on behalf of Barry Leiba" <barryleiba@gmail.com<mailto:barryleiba@gmail.com> on behalf of barryleiba@computer.org<mailto:barryleiba@computer.org>> wrote:

A follow-up here:

I'd be more comfortably with something more waffly, something more like this:

Without limiting the generality of the foregoing, acting as a working
group chair or Area Director can often be considered "Participating"
in all activities of the relevant working group or area; as such,
working group chairs and Area Directors are expected to make a best,
good-faith effort to carry out the responsibilities of Participants.

Or perhaps we want to separate WGCs from ADs here, and the text needs
more work in any case, but I hope people see the general point.

Barry

On Mon, Apr 4, 2016 at 10:27 AM, Barry Leiba <barryleiba@computer.org<mailto:barryleiba@computer.org>> wrote:
The "reasonably and personally aware" applies to the IPR, not to the
participation.

I think this is incorrect.

According to section 5.1.2 (disclosure requirement based on
Participation, not own IPR), a disclosure obligation exists if “the
Participant believes Covers or may ultimately Cover that
Contribution”.  I don’t think anyone could argue that an AD has a
“believe” in a patent or application he/she is aware of Covers a
Contribution when he has never seen the Contribution.

Would you accept "I didn't read the draft" as an acceptable reason
that someone engaged in active discussion on a draft didn't disclose?

We don't have different levels of Contributor here.  Someone making a
Contribution has an obligation to disclose, even if s/he was one of
those who said, "I didn't read the draft, but...."  If we declare the
ADs to be Contributors, why does the same not apply to them?

A late disclosure is better than no disclosure

I hope we all agree on that!

clearly, an AD
has a much better justification of making such a late disclosure.  I
would hope that no one would complain if an AD makes a late disclosure
and, when asked for the reason of lateness, he says “I was not
responsible AD; I came across this during final review in IETF last
call, and just identified this. “  In fact, people should appreciate
this.

Maybe so, but as it stands now in the document, it's still a late
disclosure, and there might still be backlash, legal concerns by
employers, and reluctance to put people in that position.

If that's the consensus, then there we have it... but I think we
should be very careful about unintended consequences of this one.

Barry