IETF Logo Mail Archive

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

David Conrad <drc@virtualized.org> Thu, 29 May 2014 18:29 UTC

Return-Path: <drc@virtualized.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 A2FC91A0A3D for <ietf@ietfa.amsl.com>; Thu, 29 May 2014 11:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 LgzU1TdX6l5a for <ietf@ietfa.amsl.com>; Thu, 29 May 2014 11:29:52 -0700 (PDT)
Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8B01A0A28 for <ietf@ietf.org>; Thu, 29 May 2014 11:29:52 -0700 (PDT)
Received: by mail-pa0-f52.google.com with SMTP id bj1so443220pad.25 for <ietf@ietf.org>; Thu, 29 May 2014 11:29:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=AJtmXJzc0Zl751TjAdidchRcYmBOQJcb2qrc/g6Xjgc=; b=T2zgyyJoG2lsdzscTYlf+l6gR35y4DRJoUkUAjE6P6UM1KfgrOHQWw6QL43C4sXU9U sZ2QfVaWhLB3KWKabqJAtDBnxu4aWBSzv0sQQyAhlQtsKvlC0wt1IxTth2kltvL3Uqnh yYIYPLk9iRqgMdxgAV4Hy0vcJeoZIvEbBFympm2E/falJRdAlj7BIH3lPL81MlVO7FuM IkgW8XFTk0r9HImTfFRfBGA7TJfvOm0QTm5TrmoPZTEwtEcPlRmCly8V3wONENERCdfv fiG/8MYxLcug6Y79k7x8aiChnlwiphtWgzArVlI2y62C0QSA+PkqgUDW7W/kaI5Sj/qC LOEQ==
X-Gm-Message-State: ALoCoQl8H8v8CmSYRRbpK7ROPFBs+8WDhziUBwXoaUKY2wBVBHKEWZ9qlU9DOXDsqPmX/MudQC8J
X-Received: by 10.68.172.193 with SMTP id be1mr11191989pbc.31.1401388188461; Thu, 29 May 2014 11:29:48 -0700 (PDT)
Received: from [10.0.1.3] (c-24-6-168-86.hsd1.ca.comcast.net. [24.6.168.86]) by mx.google.com with ESMTPSA id ci4sm2381877pbb.50.2014.05.29.11.29.47 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 11:29:47 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_22BC77BA-8154-4B6D-ACE4-576886CB5437"; 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: David Conrad <drc@virtualized.org>
In-Reply-To: <C8E791BD-E0A6-437E-B531-A1274DAED970@frobbit.se>
Date: Thu, 29 May 2014 11:29:39 -0700
Message-Id: <BAE7E773-EAE6-4E81-826C-AAA5AF8F5519@virtualized.org>
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>
To: Patrik Fältström <paf@frobbit.se>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/DRT8otPuNp1p058qea8fAost6ms
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 18:29:56 -0000

Patrik,

On May 29, 2014, at 2:41 AM, Patrik Fältström <paf@frobbit.se> wrote:
>> Just for clarity, the root server operators are under no obligation to do anything.
> But that is not the problem of the IETF.

True, which is sort of my point.

> If the IETF come to conclusion that root server services "must" support IPv4 and IPv6, so be it. It should be in the RFC.

BCP177 would appear to cover the IETF's interest in ensuring both IPv4 and IPv6 is supported. 

> Policing will not happen without a spec that services can be compared against.

My impression is that the IETF hasn't been particularly effective in coming up with operational service specifications.

> 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?

Regards,
-drc

v2.23.0 | Report a Bug | By Email