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

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 28 May 2014 16:47 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 94A691A0A08; Wed, 28 May 2014 09:47:42 -0700 (PDT)
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 oijflbEPfw8p; Wed, 28 May 2014 09:47:41 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667311A09E2; Wed, 28 May 2014 09:47:41 -0700 (PDT)
Received: from [10.20.30.90] (50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s4SGlZvp038441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 May 2014 09:47:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90] claimed to be [10.20.30.90]
Content-Type: text/plain; charset="us-ascii"
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: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <B590E9AF-057A-46A3-975F-1EE5F70201A5@vigilsec.com>
Date: Wed, 28 May 2014 09:47:34 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <3B9F4CB0-A69C-4560-AF00-8D27918A78B0@vpnc.org>
References: <20140520204238.21772.64347.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140521194638.06eaf508@resistor.net> <5246800F-6822-4607-9F73-1199C77FDAEC@vpnc.org> <B590E9AF-057A-46A3-975F-1EE5F70201A5@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/x3hU75Aj5E_yqkG0GcOFwLo9HCE
Cc: IESG <iesg@ietf.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: Wed, 28 May 2014 16:47:42 -0000

On May 28, 2014, at 9:29 AM, Russ Housley <housley@vigilsec.com> wrote:

> You have asked a question in a manner that assumes a technical assessment can be made.  

Correct. You (the IAB) are asking the IETF to obsolete a BCP (which means it has the same requirements as a standards-track document). The BCP asserts some technical properties; the IETF should be able to determine whether or not the new technical properties are an appropriate replacement for the old ones.

> I do not think that is the situation.  Instead, I think the question is whether the IETF is the proper organization to write a BCP about protocol requirements for root servers and RSSAC is the right organization to write a document about operational requirements for root servers.  In short, this more of a political question than a technical one.  Back when RFC 2870 was written, the IETF (rightly or wrongly) included both requirement sets in the same document.

That seems fine, as long as the new document says that, which it does not. If the IETF is going to replace this BCP with one that has a smaller scope, it should say that up front and *not* refer to a document that we cannot yet read and may, in fact, have very different properties than the one in the references in this draft.

Current:
   The operational requirements are defined in [RSSAC-001].  This
   document defines the protocol requirements and some deployment
   requirements.

Proposed:
   This document only defines the protocol requirements and some
   deployment requirements; the operational requirements that were
   defined in RFC 2870 are removed. It is expected that ICANN's
   RSSAC [RSSAC] will define the operational requirements.

   [RSSAC] DNS Root Server System Advisory Committee,
           http://www.icann.org/en/groups/rssac


>> From my perspective, IETF is the proper organization to write a BCP about protocol requirements.

Yes, definitely.

> RSSAC has been going through a restructuring process.  Assuming that a functional organization emerges from that process, RSSAC will be a fine organization to handle the operational requirements.

Yep. But that doesn't mean that this BCP should have a reference to a document we can't evaluate.

--Paul Hoffman