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

Lars-Johan Liman <liman@netnod.se> Fri, 06 March 2015 12:27 UTC

Return-Path: <liman@netnod.se>
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 B7B081ACDE0; Fri, 6 Mar 2015 04:27:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.95
X-Spam-Level:
X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_21=0.6] 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 fXDODTHwwb9X; Fri, 6 Mar 2015 04:27:09 -0800 (PST)
Received: from mail.cafax.se (mail.cafax.se [IPv6:2a00:801:11:53::4]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 476B11ACDE6; Fri, 6 Mar 2015 04:27:09 -0800 (PST)
Received: from limac.netnod.se ([IPv6:2a01:3f0:1:0:129a:ddff:fe5a:d3f8]) by mail.cafax.se (8.15.1/8.15.1) with ESMTPS id t26CR6bi022986 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Mar 2015 13:27:07 +0100 (MET)
Received: from limac.netnod.se (localhost [127.0.0.1]) by limac.netnod.se (Postfix) with ESMTP id 36470A14D4D; Fri, 6 Mar 2015 13:27:10 +0100 (CET)
From: Lars-Johan Liman <liman@netnod.se>
To: Mark Andrews <marka@isc.org>
Subject: Re: last call discussion status on draft-iab-2870bis
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> <6056F80B-2188-4E52-AE18-35E84BA98147@vpnc.org> <D205D042-1285-46D5-B9A1-E732B23A8861@piuha.net> <D1E3F194-34AD-4968-8ACE-7E8D7990413B@isi.edu> <20150305220328.5B3B42AF8AC8@rock.dv.isc.org>
Date: Fri, 06 Mar 2015 13:27:10 +0100
In-Reply-To: <20150305220328.5B3B42AF8AC8@rock.dv.isc.org> (Mark Andrews's message of "Fri, 06 Mar 2015 09:03:27 +1100")
Message-ID: <2261aes44h.fsf@limac.netnod.se>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (darwin)
MIME-Version: 1.0
Content-Type: text/plain
X-Scanned-By: MIMEDefang 2.71 on IPv6:2a00:801:11:53:0:0:0:4
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/PIKkrgkmghVKPUSyyCVnuHVv1aQ>
Cc: IAB <iab@iab.org>, IETF Discussion List <ietf@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>, manning bill <bmanning@isi.edu>
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: Fri, 06 Mar 2015 12:27:10 -0000

bmanning@isi.edu:
>> EDNS is essential for the implementation of DNS Security Extensions.
>> All roots support DNSSEC.
>> Calling out EDNS0 at this time is moot.

marka@isc.org:
> Actually there are implementations that do DNSSEC fine but botch
> EDNS.  We have drafts coming through the IETF that expect full EDNS
> version 0 compliance to work without having to do gross hacks like
> dealing with incorrectly returned FORMERR, BADVERS and queries being
> dropped because they happen to try to use a extension.

Man, you must see a lot of bad sh*t in your professional life. :-) I
cannot even wrap my head around the concept of doing DNSSEC fine while
botching EDNS, but I know you well enough to take your word for it. :-)

> The current root servers get this right.  This is about preventing
> things going wrong in the future.  It is also about TLDs and others
> that use the root server requirements as a basis for their
> requirements.

I do note that the current draft specifies "MUST do DNSSEC", which to me
sounds like "and therefore needs to do EDNS". I wouldn't really mind
adding EDNS to the draft, except, as noted earlier, it's just a
framework, and specifying which parts of it must be implemented isn't a
friendly slope to slide along. It also begs for other stuff to be
listed, and we (again) risk ending up with legalese like "... including,
but not limited to ..." - which I don't favour.

And there's the text in RSSAC-001.

I think I agree with Jari (if this is what you meant, Jari? ;-), that
the current wording in _these_ documents (draft + RSSAC-001) is
sufficient, and that work should be put into firming up the DNS specs in
general, so that the "rubber wheel" clauses in RSSAC-001 get some "real
tarmac" to work with and get good traction.

So my current inclination wrt. this, is to leave the relevant text parts
unchanged for -03 (which we seem to have to produce ...).

				Cheers,
				  /Liman
#----------------------------------------------------------------------
# Lars-Johan Liman, M.Sc.               !  E-mail: liman@netnod.se
# Senior Systems Specialist             !  Tel: +46 8 - 562 860 12
# Netnod Internet Exchange, Stockholm   !  http://www.netnod.se/
#----------------------------------------------------------------------