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

Jari Arkko <jari.arkko@piuha.net> Wed, 18 January 2017 14:52 UTC

Return-Path: <jari.arkko@piuha.net>
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 0AC3712943B; Wed, 18 Jan 2017 06:52:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level:
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 NeDg0EVnqkAv; Wed, 18 Jan 2017 06:52:25 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id EDD63129420; Wed, 18 Jan 2017 06:52:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4B9692CD02; Wed, 18 Jan 2017 16:52:24 +0200 (EET) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYUYI_kVva7Z; Wed, 18 Jan 2017 16:52:23 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 19DAE2CCAF; Wed, 18 Jan 2017 16:52:22 +0200 (EET) (envelope-from jari.arkko@piuha.net)
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=_AEA196D5-7DCD-4692-9C0A-28BE6197FEDD"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <148474911031.2261.11881119527780959351.idtracker@ietfa.amsl.com>
Date: Wed, 18 Jan 2017 16:52:22 +0200
Message-Id: <875519DD-685D-4642-A1D4-0F5D82502E21@piuha.net>
References: <148474911031.2261.11881119527780959351.idtracker@ietfa.amsl.com>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/oeItz8pMfVVl7IAmB4Bq4qSq41I>
Cc: draft-bradner-rfc3979bis@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: Wed, 18 Jan 2017 14:52:27 -0000

You’ve seen the last call message come through, but as
the AD responsible for this document, I wanted to follow-up
with a description of where I think we are with the document.

This document went through a last call process in spring 2016,
with a fair number of comments. We’ve taken the feedback
in, and being less busy with the transition work that was undergoing
last summer, have returned with a new document that we
believe addresses those issues. The changes are substantial
enough though that we think that a new last call is necessary.

Note that given some textual reorganisation, the document is
difficult to compare to the original RFC. There is a changes
section, but having a more detailed listing would be beneficial.
We have promised to provide this detailed section, and will do
so within a week from now.

The spring 2016 comments have been listed in

https://www.ietf.org/mail-archive/web/ietf/current/msg100236.html

along with some tentative solutions that were given
for the editors. With some further discussion, I’m listing
the main changes to the document from the previous
last call below:

* Stephen Farrell’s concern re: remote vs. in-person attendees
  was resolved without text changes (Jari’s mail on March 22)

* Russ Housley’s concern re: “IETF sanctioned” was resolved
  per Brian’s and Harald's suggestions (Brian's mail on March 26).

* 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.

* Gonzalo Camarillo’s concern re: ADs being assumed to read
  all documents in their area seemed valid and was fixed.

  We think that is incorrect if the future BCP on this topic explicitly
  rules everything in the area to be something where the AD
  participates in, even if he or she might not even be the AD
  for the group in question.

  We used a variation Spencer’s wording (Spencer’s mail on
  March 30).

  OLD:
  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.
  NEW:
  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 working groups
  he or she is responsible for in an area.

* A follow-up to Gonzalo’s concern was raised later in the
  discussion re: ADs often seeing the materials late in the process.
  There seemed to be support for adding this to the document, which
  we have done:

  NEW:
  By the nature of their office, IETF area directors may become
  aware of Contributions late in the process (for example at IETF
  Last Call or during IESG review) and, therefore and in such
  cases, cannot be expected to disclose any IPR Covering those
  Contributions until they become aware of them.

* Alissa Cooper’s editorial comments from her mail on April 1
  were acted up, except the first issue which was follow-up to
  Gonzalo’s issue.

* There was some discussion of including the IRTF in the document
   in the same go, but the authors and the AD came to the
   conclusion that it introduces too many dependencies.

   Also, worth discussing during the last call, is that the new document
   refers to stream managers that have not really been well defined
   elsewhere.

* Pete Resnick suggested to put back in the three principles to
  Section 2 that were deleted from the previous RFC (April 11).
  We’ve done so; we should only make substantive changes
  to the original RFC when there’s clear consensus to do so.

* Pete Resnick suggested to put back the material from
  RFC 3979 Section 4.1 that were deleted from the
  previous RFC (April 11), which we’ve also done.

* Note that Pete Resnick had a concern on forcing people to
  document applicability to the contribution 5.4.2 (April 11). This may
  require further discussion, although I personally am inclined to agree
  with Pete. I had posted a response on April 25, for which there
  was no other response. Needs further discussion during 2nd last call.

* Pete Resnick had a concern on adding the word “all” to Section 7
  (April 11). This was an oversight, and has been corrected.

* Section 7 has been amended to be clear that its latter part is for
  information only.

The changes to spring 2016 version of the I-D can be seen here:
https://www.ietf.org/rfcdiff?url1=draft-bradner-rfc3979bis-08&url2=draft-bradner-rfc3979bis-10

Jari Arkko, sponsoring AD for draft-bradner-rfc3979bis