Re: Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice

Patrik Fältström <paf@frobbit.se> Thu, 29 May 2014 19:12 UTC

Return-Path: <paf@frobbit.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 DFF281A0408 for <ietf@ietfa.amsl.com>; Thu, 29 May 2014 12:12:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 pcs2z8YWSTTT for <ietf@ietfa.amsl.com>; Thu, 29 May 2014 12:12:18 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7010A1A01D5 for <ietf@ietf.org>; Thu, 29 May 2014 12:12:18 -0700 (PDT)
Received: from [192.168.1.32] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 2D9F51FF88; Thu, 29 May 2014 21:12:11 +0200 (CEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_C3384210-2A56-4E8E-AB8A-A8B8A4EA7650"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
Subject: Re: Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice
From: Patrik Fältström <paf@frobbit.se>
In-Reply-To: <BAE7E773-EAE6-4E81-826C-AAA5AF8F5519@virtualized.org>
Date: Thu, 29 May 2014 21:12:07 +0200
Message-Id: <41C69E89-26DA-45EB-BDC6-38C404C615F2@frobbit.se>
References: <20140520204238.21772.64347.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140521194638.06eaf508@resistor.net> <1111FB79-012A-414B-B8CD-0BBDAE8BD6A8@hopcount.ca> <6.2.5.6.2.20140522095317.0c5fd648@elandnews.com> <5C02BCCA-79D7-40A5-BFB0-26284A667E78@vpnc.org> <DC9ED318-2352-4AF0-8A43-29D237C32B64@vigilsec.com> <924045CD-DC34-423B-8702-CD99CF687D46@vpnc.org> <31344.1401304682@sandelman.ca> <850B843A-3346-408B-9D8B-65D0879A2498@virtualized.org> <C8E791BD-E0A6-437E-B531-A1274DAED970@frobbit.se> <BAE7E773-EAE6-4E81-826C-AAA5AF8F5519@virtualized.org>
To: David Conrad <drc@virtualized.org>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/jdrfTfvJT9haoGM3nU_M6MRt6lo
Cc: 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, 29 May 2014 19:12:20 -0000

On 29 maj 2014, at 20:29, David Conrad <drc@virtualized.org> wrote:

>> And lack of policing (which seems to be what you talk about) is I think a separate issue.
> 
> That's not really what I'm talking about.  What I am saying is that it I don't really see the point in the IETF attempted to demand stuff outside of its control. In most standardization/protocol definition contexts, the IETF specifying "MUST" or "MUST NOT" usually makes sense since folks generally have a choice in obtaining equipment/software/service that is implementing those standards. 
> 
> This is NOT the case with the root servers. 
> 
> By and large, the Internet community gets what the root server operators deem at their sole discretion (perhaps informed by outside-the-IETF contractual or other obligations) within their interests to provide, nothing more and nothing less. 
> 
> In April 2012, the IETF, via BCP177, already stated "IPv6 is required" yet B, E, and G still do not support IPv6 (yes, I'm sure there are reasons, that's not the point). RFC 2010 was published in 1996 and was mostly ignored by the root server operators. RFC 2870 was published in 2000 and was mostly ignored by the root server operators. What has changed that makes you believe a new RFC is going to have a different impact?

I do not think it has a different impact. I am more nervous over what the impact will be if IETF stop saying IPv6 is required. If IETF do not say so it is impossible to say that B, E and G does not live up to whatever requirement IETF set.

I.e. I do not think it is wrong that IETF require what IETF want to require. The error is elsewhere.

   Patrik