From: Jari Arkko <jari.arkko@piuha.net>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_DCDA0CBF-6200-4080-9CFE-A0B94F02F03F";
 protocol="application/pgp-signature"; micalg=pgp-sha512
Subject: status of draft-bradner-rfc3979bis
Date: Wed, 21 Dec 2016 14:27:24 +0200
Message-Id: <444A4B09-8865-4B7E-9562-1273B9523F37@piuha.net>
To: IETF Discussion <ietf@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/gKfgRlWdztX6qQ8awmDrMpyf_Zg>
Precedence: list


--Apple-Mail=_DCDA0CBF-6200-4080-9CFE-A0B94F02F03F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I wanted to provide on update on where we are with this.

We had a lengthy last call discussion in the spring, which raised a =
number of issues that we will have to deal with. Unfortunately, a lot of =
my time was consumed in other matters so we didn=92t make immediate =
conclusions. But after IETF97 I have instructed the authors to take into =
account what I saw as the feedback in the last call. Please see my =
conclusions below and let me know if you there=92s anything amiss.

The authors will be revising the document, and once that happens there =
will be another last call. Note that there are a few issues that will =
require further discussion on that last call.

Jari Arkko, as responsible AD for the document

=97=97

Stephen Farrell=92s concern re: remote vs. in-person attendees was =
resolved I think without text changes (Jari=92s mail on March 22)

Russ Housley=92s concern re: =93IETF sanctioned=94 should be resolved =
per Brian=92s and Harald's suggestions (Brian's mail on March 26).

Russ Housley=92s concern re: changes from the previous RFC section is =
basically valid (Russ=92s mail on March 25), and you guys need to act on =
that. Maybe my diffs from earlier are helpful in gathering an =
explanation of changes.

Gonzalo Camarillo=92s concern re: ADs being assumed to read all =
documents in their area seems valid and needs to be fixed. There was no =
unanimous opinion on this, but I think enough people commented that felt =
it was an issue (Spencer, Jari, Gonzalo, Alissa, Barry, Ben vs. Brian =
and Stephan). Stephan makes an argument on April 4 that =93reasonably =
and personally=94 includes awareness of the documents, but I 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. Finally, I don=92t=
 think the suggestion from John Klensin and others on ADs sending notes =
of recusal works well because, frankly, how would you recuse when the =
initial problem we had was that you might not read enough about the =
other half WG=92s work to recognise there=92s an issue. The suggestion =
from John was also opposed by Joel.

I=92d suggest using a variation Spencer=92s wording (Spencer=92s mail on =
March 30) or alternatively you can work out suitable words yourselves. I =
don=92t think the general language from Barry works (April 4) because =
the WG chairs and ADs are really in a different position, and it is =
better to separate them in the text. Here=92s my suggestion:

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=92s 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. I think it may make sense to =
add this too, though I think the previous change is the fundamental =
thing. Here=92s the suggested additional text:
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.

Michael Cameron suggested the removal of the =93reasonably=94 language =
in his April 5 email. I did not see sufficient backing for this =
particular change, but since he initiated it I think due to the =
discussion of the AD role requirements, I think the above changes cover =
that original reason for his issue. I think there were other issues too, =
however, and I=92m not sure we=92ve adequately discussed those yet. =
There was a distinction on =93covers=94 vs. =93ultimately covers=94 for =
instance. May need more discussion during the new last call.

John Klensin suggested in his April 5 mail that the document be changed =
to become more of an ethical obligations than a legalistic rules one. I =
did not see enough support for this change. Brian Carpenter=92s =
suggestion (April 6) on draft-ymbk-ietf-ethics seemed a reasonable one.

Alissa Cooper=92s editorial comments from her mail on April 1: These =
need to be acted upon (except the first issue which was follow-up to =
Gonzalo=92s issue).

Lars Eggert=92s editorial comments from his mail on April 4: These need =
to be acted upon. In addition, there were a number of more substantial =
issues in his email:

- including IRTF and RGs within the definition of =93IETF documents=94. =
This is tricky, because the IETF can=92t specify what IRTF wants. =
However, I think we can do this, *if* we also extend the last call and =
point this out to IRTF participants explicitly, if we don't have =
differing rules.

- relaxing rules regarding not including terms: I=92d suggest we not =
need new text for this. I also don=92t want to make exceptions for IRTF, =
unless we have to. I think the current text supports the running code on =
the IRTF side as well.

- irtf stream manager: I=92d suggest we take out the following text: =
"(i.e., the Internet Architecture Board (IAB), Internet Research =
Steering Group (IRSG) and Independent Submission Editor)."

Pete Resnick suggested to put back in the three principles to Section 2 =
that were deleted from the previous RFC (April 11). These should be =
adopted, lacking evidence to the contrary (since we are doing a -bis; we =
should only make substantive changes when there=92s 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). These should be =
adopted, lacking evidence to the contrary (since we are doing a -bis).

Pete Resnick had editorial suggestions on Sections 5.2.1, 5.4.2, and 5.5 =
(April 11). These should be adopted.

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 =93all=94 to Section 7 =
(April 11). This seems like an oversight to me, and should be corrected.

Finally, on my personal re-read of the document, I=92d suggest the =
following:

In Section 7,
OLD:
This paragraph is provided for information only:
NEW:
The following paragraphs are provided for information only:

(I think the rest of the section is informative, correct?)

--Apple-Mail=_DCDA0CBF-6200-4080-9CFE-A0B94F02F03F
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJYWnUtAAoJEM80gCTQU46qnk0P/AhxnZh21CJDOcVd+dCqqWbv
qqv207Z2nLaJMjPLju300yIEbLBnREeHE72w19cNKHpa+2o7fjmY+T3U0lQxsRVs
N7SozEw4EI9LPH2QutLPttznqNkEDgFd1Rpthlh7NfqI2tZaQ8ECssp03qI8fa9U
Lp0KuuFi1Xjq7nO/evqykJYwlDdklJvj+nEPvGUBvv4chUncIW864VeBFCNRhkmx
OLjMuAtzL7UVKWRZIgF57iswvHktduSxTxp2FWq2QeiqxyoE7L4s1b8ene6K/BN2
L9WjJHAsBkfOjys07Jhey9saAcgfvkj2VAUwULuoIdDepQ3RcIZsMUlWVmjpbJ24
lsmWIRtD6sAQWJZk/ng0cFMo0dbWd7g+ZvGEh7rTuICCxj5/2LV3qxOArg4ezvTe
4aFDVl7OdCov2hj4G0j49ZYzeDsRbGsAaW6er8kSTjeVAdzII0SoQjnamwCsa77R
w3xJY+nZ9ensQzh1Ixi3v+Nad/kyFeMuTfe/iQjXxYTf+Ggj/+hr1z2ptjpNdaGa
v6loQDhz+pvxKnXvqGnazc4c2bkYjqT77b47K2sR6SOZEJ2R7h5RTYipVdYGgsdh
4Fck6SmIV2/H9QZ2AdOj9+dBUt+tHJkpeExuPtQI2NXmYQAROmnme4dfevkjNcaA
5JFF2nXSzhkX3rlzJYl0
=R0vH
-----END PGP SIGNATURE-----

--Apple-Mail=_DCDA0CBF-6200-4080-9CFE-A0B94F02F03F--