Re: last call discussion status on draft-iab-2870bis

Mark Andrews <> Thu, 05 March 2015 04:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 777361A8742 for <>; Wed, 4 Mar 2015 20:41:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5hk6gDf839BZ for <>; Wed, 4 Mar 2015 20:41:27 -0800 (PST)
Received: from ( [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A2FFD1A874C for <>; Wed, 4 Mar 2015 20:41:26 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4B66D3493BF; Thu, 5 Mar 2015 04:41:24 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id 5C4FB160055; Thu, 5 Mar 2015 04:48:24 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTPSA id E40FB160050; Thu, 5 Mar 2015 04:48:23 +0000 (UTC)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 4185F2AEEC2D; Thu, 5 Mar 2015 15:41:22 +1100 (EST)
To: Jari Arkko <>
From: Mark Andrews <>
References: <> <> <>
Subject: Re: last call discussion status on draft-iab-2870bis
In-reply-to: Your message of "Thu, 05 Mar 2015 05:43:49 +0200." <>
Date: Thu, 05 Mar 2015 15:41:21 +1100
Message-Id: <>
Archived-At: <>
Cc: IAB <>,
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Mar 2015 04:41:28 -0000

In message <>et>, Jari Arkko writes:
> 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.

I suspect this is because the root servers actually correctly
implement EDNS.  If a server was changed to a implementation that
failed to correctly implement EDNS that would change.  There are a
number of drafts before dnsop at the moment that require EDNS to
be properly implement.  I'm a co-author of one of them.

> 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

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: