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

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 05 March 2015 16:48 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 26C111A014A; Thu, 5 Mar 2015 08:48:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 qq7KJEMryuvW; Thu, 5 Mar 2015 08:48:50 -0800 (PST)
Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1E31A1B22; Thu, 5 Mar 2015 08:41:57 -0800 (PST)
Received: from [10.20.30.109] (142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t25GfsP8093132 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2015 09:41:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: proper.com: Host 142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245] claimed to be [10.20.30.109]
Subject: Re: last call discussion status on draft-iab-2870bis
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_ADE7D629-210C-4FF1-BAF0-6F08A2121D00"; protocol="application/pgp-signature"; micalg="pgp-sha1"
X-Pgp-Agent: GPGMail 2.5b5
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <EC564286-9A5E-4702-A8ED-B2C8E404E68A@piuha.net>
Date: Thu, 05 Mar 2015 08:41:50 -0800
Message-Id: <6056F80B-2188-4E52-AE18-35E84BA98147@vpnc.org>
References: <20140520204238.21772.64347.idtracker@ietfa.amsl.com> <500031A0-DF45-409E-AACB-F79C32032E38@viagenie.ca> <4B545BEB-EA0E-4BA8-A45E-15AF12CDB1EC@piuha.net> <20150305044122.4185F2AEEC2D@rock.dv.isc.org> <EC564286-9A5E-4702-A8ED-B2C8E404E68A@piuha.net>
To: Jari Arkko <jari.arkko@piuha.net>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/G3MqdDmSvE7jW3osZPorn3pDngQ>
Cc: IAB <iab@iab.org>, IETF Discussion List <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 16:48:51 -0000

On Mar 5, 2015, at 12:47 AM, Jari Arkko <jari.arkko@piuha.net> wrote:
>>> 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.
> 
> Perhaps. What do others think?

Mark's proposed addition of EDNS0 is a very nice thing to have. If all the root servers always responding to queries that have EDNS0 with EDNS0 in their responses, the DNS would be operationally more stable, particularly as response sizes increase over time.

However, it seems inappropriate for the IETF to say "and here is the exact list of protocol bits that we require for the root service" when we are sure that servers using few of those bits will work adequately. Also, it is important to note that RSSAC-001 says:

[E.3.2 - A] Individual Root Servers will adopt or continue to implement the current DNS protocol and associated best practices through appropriate software and infrastructure choices.

EDNS0 very clearly falls under "best practices": no one can deny that. So, to some extent, the expectation is already on the root server operators to use EDNS0. It's not clear if the IETF saying "here's a thing we insist on" will help the cause.

Further note: just saying "EDNS0" is not sufficient: we would have to say which features, options, and extensions would be needed. This is "obvious" to many folks, and not at all clear to others.

--Paul Hoffman