Re: Last Call: <draft-bradner-rfc3979bis-10.txt> (Intellectual Property Rights in IETF Technology) to Best Current Practice

Russ Housley <housley@vigilsec.com> Sun, 22 January 2017 18:07 UTC

Return-Path: <housley@vigilsec.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 2AB541297CF for <ietf@ietfa.amsl.com>; Sun, 22 Jan 2017 10:07:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 In3koLcaSi9P for <ietf@ietfa.amsl.com>; Sun, 22 Jan 2017 10:07:43 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D341297CE for <ietf@ietf.org>; Sun, 22 Jan 2017 10:07:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 160B2300270 for <ietf@ietf.org>; Sun, 22 Jan 2017 12:57:27 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MWhhLG8MaeJn for <ietf@ietf.org>; Sun, 22 Jan 2017 12:57:24 -0500 (EST)
Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 4EB69300209; Sun, 22 Jan 2017 12:57:24 -0500 (EST)
Subject: Re: Last Call: <draft-bradner-rfc3979bis-10.txt> (Intellectual Property Rights in IETF Technology) to Best Current Practice
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_CE3F0565-E534-4BE4-97A0-26EF7263DB4A"; protocol="application/pgp-signature"; micalg=pgp-sha1
X-Pgp-Agent: GPGMail
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <73B2C33B-EC3F-411E-8F2D-959C4996A3D3@piuha.net>
Date: Sun, 22 Jan 2017 13:07:33 -0500
Message-Id: <D536B36A-B8A6-4B89-A2CE-7AFB38C6DCE0@vigilsec.com>
References: <148474911031.2261.11881119527780959351.idtracker@ietfa.amsl.com> <875519DD-685D-4642-A1D4-0F5D82502E21@piuha.net> <27F46F35-2E43-4BB8-A246-3516DA90A89D@vigilsec.com> <73B2C33B-EC3F-411E-8F2D-959C4996A3D3@piuha.net>
To: Jari Arkko <jari.arkko@piuha.net>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Su83KtIiQK08l12yIE9ZntRE1dM>
Cc: draft-bradner-rfc3979bis@ietf.org, 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: Sun, 22 Jan 2017 18:07:45 -0000

Jari:

> 
>>> * Russ Housley’s concern re: “IETF sanctioned” was resolved
>>> per Brian’s and Harald's suggestions (Brian's mail on March 26).
>> 
>> I do not think that the change here is sufficient based on my reading of the thread that followed my comments.  I think my comment is addressed, but not all of the points that are made in that thread.  In particular, the output of the design team is the contribution, not every alternative that is discarded before being written down or presented.  Also, the reference to BCP 25 seems to scope this the design teams in working groups, not all design teams.
> 
> Hmm. I think I agree with regards to BCP 25 (do you have alternative
> references or words?)
> 
> But I re-read the thread this morning, and a number of important
> points were made along the way in the discussion. However, I
> viewed some of those points as possible alternative ways to
> tackle the original concerns, and there was a lot of back-and-
> forth regarding them. For instance, John Klensin argued
> that an output would necessarily be a contribution anyway.
> 
> The difficulty here is of course that we want to enable what
> John and Brian and Sam talked about, that there are
> gatherings that we want to enable that are not yet
> IETF design teams but whose discussion may eventually
> lead to some IETF design team or submission. Many of
> my discussions with other industry people are that way:
> “do you have this problem” or “how can we work together
> to connect our gear”… and only some fraction of the time
> these result in ideas for standards and IETF standards in
> particular.
> 
> Ultimately, you have to draw a line somewhere. “This
> is where IETF work starts and you are now under the
> IETF IPR rules”.
> 
> Harald’s email from spring I thought outlined this in
> practise very nicely:
> 
> If the documents clearly define the term "design team" as teams that are
> created by a decision in an IETF process, I have very few problem
> extending "IETF contribution" to contributions to the design team.
> 
> If (as I've sometimes seen) everyone who meets to hash out an idea wants
> to call themselves + their friends is a "design team", then I see a
> problem with the extension.
> 
> The lunchtime "bar BOF" would be a nice test case - arranged by WG
> chairs over the WG (or IETF non-WG) mailing list, it would be an IETF
> activity with IETF contribution; arranged between friends on the way out
> of the preceding WG meeting, it would (I think) not be.
> 
> So where does all this leave us?
> 
> I’d argue that the output/non-output distinction isn’t the crucial
> one. Outputs from design teams that go to the IETF are in any
> case covered. But how do we want to cover the design team
> discussion (incl. any silly alternatives), without impacting
> my ability to have a discussion with my customer for instance?
> 
> I think I’d be happy if w extended the BCP 25 reference to
> some other text that covers also non-WG design teams, for
> instance teams that call themselves IETF design teams (whether
> “sanctioned" or not).
> 
> But your suggestions are welcome.

I agree with the message you quote from Harald.

Text suggestions: … WG design teams [see BCP 25] and other design teams …

>>> * Russ Housley’s concern re: changes from the previous RFC
>>> section is valid (Russ’s mail on March 25), and we will be acting
>>> on that as explained above.
>> 
>> I look forward to seeing this text.  Since it does not exist yet, I think the IETF Last Call should be extended for two weeks beyond the availability of this text.
> 
> We are working on it. My hope is that we’ll get it done soon enough for
> there to be more than two weeks left of the last call, but if not we will
> certainly extend the Last Call.

Thanks.

Russ