Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard

John C Klensin <john-ietf@jck.com> Fri, 06 March 2015 15:22 UTC

Return-Path: <john-ietf@jck.com>
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 E43FF1ACE7C for <ietf@ietfa.amsl.com>; Fri, 6 Mar 2015 07:22:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 q3e3kIKN4vA1 for <ietf@ietfa.amsl.com>; Fri, 6 Mar 2015 07:22:46 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9F81ACE73 for <ietf@ietf.org>; Fri, 6 Mar 2015 07:22:46 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YTu58-000Lq6-7v; Fri, 06 Mar 2015 10:22:30 -0500
Date: Fri, 06 Mar 2015 10:22:25 -0500
From: John C Klensin <john-ietf@jck.com>
To: Eliot Lear <lear@cisco.com>, Pete Resnick <presnick@qti.qualcomm.com>
Subject: Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard
Message-ID: <6EA8980660D2F439A02A006A@JcK-HP8200.jck.com>
In-Reply-To: <54F994BD.8090306@cisco.com>
References: <54C9DA42.5040901@cisco.com> <9EB44D8A-278B-42FC-A542-1C182AD43128@netnod.se> <A74A30F4D1214630918FD4CA@JcK-HP8200.jck.com> <20150223153757.GI1260@mournblade.imrryr.org> <20150223155241.GJ1260@mournblade.imrryr.org> <tsl8ufoh9ko.fsf@mit.edu> <2DF7230C-D1D8-4B21-9003-B336108A38CB@vpnc.org> <20150224172649.GX1260@mournblade.imrryr.org> <tslvbircj0d.fsf@mit.edu> <0325DF3F-17F3-4400-BDEA-EDB5334BF35C@frobbit.se> <20150225180227.GT1260@mournblade.imrryr.org> <7AB921D35A7F9B23A53BD11A@JcK-HP8200.jck.com> <tslvbip8io6.fsf@mit.edu> <54F09A35.9060506@qti.qualcomm.com> <54F78650.6070503@qti.qualcomm.com> <54F994BD.8090306@cisco.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/iVIyabGBba_UKCk4BXsLELgEvOs>
X-Mailman-Approved-At: Fri, 06 Mar 2015 08:08:20 -0800
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, ietf@ietf.org, =?UTF-8?Q?F=C3=A4ltstr=C3=B6m_Patrik?= <paf@frobbit.se>, Mark Nottingham <mnot@mnot.net>, Sam Hartman <hartmans-ietf@mit.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 15:22:48 -0000

--On Friday, March 06, 2015 12:51 +0100 Eliot Lear
<lear@cisco.com> wrote:

> I just wanted to say that I think it's a bad idea to make this
> thing informational.  The fact is that URI has been kicking
> around for years upon years, and what we are doing now is
> documenting existing practice.  PS is a perfectly fine
> instrument to gain experience, warts and all, with URI.

Eliot,

The counterargument is that we've gotten into a trap.  In
theory, PS implies something that we can use, as you say, to
gain experience, etc.  But that experience is useless unless the
IETF has practical change control and can make alterations
dictated by community review (before PS approval or after that
experience accumulates).

Because this RRTYPE is already registered and the registration
cannot be changed in an incompatible way, that condition doesn't
apply -- any experience we gain could only be used to inform an
Applicability Statement that might say "don't use this" or "use
this only if if series of other conditions have been met".  Such
an Applicability Statement (or nearly-equivalent BCP) could
perfectly well be issued against an Informational document.

The various Last Call design reviews have identified several
changes that people would like to make to the RRTYPE itself (I
am not claiming consensus for any of them because they haven't
been discussed sufficiently).  However, this cannot be a normal
Last Call for a normal would-be PS spec, because those changes
[1] cannot be considered and, if appropriate, made.

I think this "register by Expert Review, freeze technical
content, and then discuss standardization" path is a problem,
potentially a serious one, for the IETF.  But I think the place
to sort it out is in our norms for Expert Review leading to
registrations, e.g., in draft-leiba-cotton-iana-5226bis or in
changes to the (IIR, unwritten) "IETF has change control" and
the very explicit "known defects" rule in 2026.  Until and
unless such changes occur, I just don't see a way to put this on
the standards track that does not result in worse problems.

best,
    john

[1] While most of the focus of the discussions has been on
security, there are some other substantive issues too.  For
example, (i) given that this RRTYPE moves the service being
requested from the RDATA to the Owner of the DNS entry, is
"Weight" still justified and is it likely to cause more trouble
than it is worth or (ii) given recent controversies about kinds
and uses of URIs, including the debate about how much different
URNs should be from URLs and generic (but presumably
location-oriented) URIs, should there be restrictions on the
type and/or content of URIs that are considered appropriate for
use with the RRTYPE?    The issue isn't what the answer to those
question should it; it is that they can't really be asked.