last call discussion status on draft-iab-2870bis

Jari Arkko <jari.arkko@piuha.net> Thu, 05 March 2015 03:43 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7207C1A8ADA for <ietf@ietfa.amsl.com>; Wed, 4 Mar 2015 19:43:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 av1hUorR5uTO for <ietf@ietfa.amsl.com>; Wed, 4 Mar 2015 19:43:49 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 69F3C1A8ACD for <ietf@ietf.org>; Wed, 4 Mar 2015 19:43:48 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BBE232CC5D; Thu, 5 Mar 2015 05:43:47 +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 bXTiYe5BVVfc; Thu, 5 Mar 2015 05:43:47 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 1FF4D2CC4D; Thu, 5 Mar 2015 05:43:47 +0200 (EET) (envelope-from jari.arkko@piuha.net)
Content-Type: multipart/signed; boundary="Apple-Mail=_660754D8-8252-4FE1-849A-04642D6CBCB3"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: last call discussion status on draft-iab-2870bis
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <500031A0-DF45-409E-AACB-F79C32032E38@viagenie.ca>
Date: Thu, 05 Mar 2015 05:43:49 +0200
Message-Id: <4B545BEB-EA0E-4BA8-A45E-15AF12CDB1EC@piuha.net>
References: <20140520204238.21772.64347.idtracker@ietfa.amsl.com> <500031A0-DF45-409E-AACB-F79C32032E38@viagenie.ca>
To: Marc Blanchet <marc.blanchet@viagenie.ca>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/mImEQOEJbRsrR97D3skNErSSxSY>
Cc: IAB <iab@iab.org>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 05 Mar 2015 03:43:50 -0000

I wanted to come back to the status of the discussions.

We have an ongoing discussion of the changes Marc made on the -02. My read of the feedback is that the update has done the right things, but:

1) Paul Hoffman’s clarifications & editorial changes seem useful, but I would like to hear what others think. Marc, you should respond to those as well.

2) Mark Andrews’ suggestion of further requirements regarding reserved bits was discussed, but should proceed separately.

3) Mark Andrews' suggestion of further requirements regarding EDNS0 has not been discussed, but I would note that at this stage we should not add major requirements without substantial community portion indicating that this is needed. I’m not hearing it.

4) I’ve also received feedback from IESG members that the text about moving 2870 to Historic in Section 1.1 could be problematic. While I’m not sure that is necessarily the case, I think this draft merely replaces 2870, so I am not sure we need to say anything more. I have confirmed with the IAB that it does not believe the part about moving 2870 to Historic is necessary. Does anyone object to this change?

With regards to the earlier discussions in the last call in the summer, Marc’s message discussed some of the things where an agreement was clearly found. I don’t think I need to report further on that. However, I wanted to highlight a few other items:

I believe there is rough consensus to publish an updated BCP (subject to some detailed clarifications, still ongoing). There was some discussion about whether it is appropriate for the IETF to do this, but my read of the discussion is that the topic was explored and that a reasonable division of work between the RSSAC and IETF exists, even with some roughness of the opinions within the group. The IETF role in this case is to provide high-level requirements for the service. Specifically for this service, even if some broader statements have been made about all nodes previously. But is not our role to enforce anything or deal with the operational issues.

There was some discussion of the meaning of the requirements currently in the document, and whether clarifying text was needed to specify whether they apply to individual nodes or the service. Michael Richardsson (among others) has supported the current text as it really is about the service. This is another topic where there is some roughness in the group, but I believe the initial question has been adequately answered and has at least some support in the group.

A big problem last summer was that we did not yet have a document from the RSSAC. With the stable RSSAC document now available, it is possible to proceed.

From my read of the commentary, the following items may deserve further thought. Marc, can you deal with these?

* Joe Abley’s comment about qualifying the requirement to answer queries from any valid IP address with respect to operational events (such as attacks). While I believe the operational issues are indeed in the RSSAC scope, I think we should qualify our requirement to be subject to operational issues.

* Klaas Wieranga’s Secdir review made a suggestion about privacy related to root queries, and how caching mitigates some of the concerns. Text could be added about this, although it is of course somewhat obvious state of affairs. I’ll leave it to the editor’s discretion what to do here.

Jari