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

Eliot Lear <lear@cisco.com> Fri, 06 March 2015 15:53 UTC

Return-Path: <lear@cisco.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 04CE21ACEE4 for <ietf@ietfa.amsl.com>; Fri, 6 Mar 2015 07:53:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 fjPEfvwsdo_r for <ietf@ietfa.amsl.com>; Fri, 6 Mar 2015 07:53:02 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B59341ACED8 for <ietf@ietf.org>; Fri, 6 Mar 2015 07:53:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4394; q=dns/txt; s=iport; t=1425657181; x=1426866781; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=LxInm78scm9/k42BFQnv6bE0Juxi52cQ+R0IracVsLc=; b=JARwAb51ioTC4xDNJX3DacvwMcGq3PW/a8DfvytUOAfjjDCe66SllQoC dVsY4f0ao9SpTOyWAgR0hKK24htFL7j8COSjkwLgiAU2NX3f5E/xy+zK6 f2pL3AB2sphUTeu1zJI0IRuJu+YaLgciUnuNvCe7Yh/TeG0Y9jSm1ASCU w=;
X-Files: signature.asc : 486
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AKBgDBzPlU/xbLJq1chDKDCsRYAoIGAQEBAQEBfIQQAQEEHQZIAQoCARALGAkWBAcCAgkDAgECAUUGAQwBBQIBARCIG7NRmlgBAQEBAQEBAQEBAQEBAQEBAQEBGYsXhG4HgmiBQwWRa4EugRuFIIEahVmMfCOCAhwUgT09MYJDAQEB
X-IronPort-AV: E=Sophos;i="5.11,353,1422921600"; d="asc'?scan'208";a="376122712"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 06 Mar 2015 15:52:58 +0000
Received: from [10.61.197.228] ([10.61.197.228]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t26FqvtG025558; Fri, 6 Mar 2015 15:52:57 GMT
Message-ID: <54F9CD58.9060806@cisco.com>
Date: Fri, 06 Mar 2015 16:52:56 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.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
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> <6EA8980660D2F439A02A006A@JcK-HP8200.jck.com>
In-Reply-To: <6EA8980660D2F439A02A006A@JcK-HP8200.jck.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="gWITOExfcSvmbGrIa9j9KuQwp8ksSMfKk"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/HxkXMFwhLtyKnd979vHZzdSRExg>
X-Mailman-Approved-At: Fri, 06 Mar 2015 08:08:56 -0800
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, ietf@ietf.org, Fältström Patri k <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:53:07 -0000

I would agree that on the whole we want people to register RR types
through the standardization process.  However, if someone actually
followed our process, as Patrik did, and defined the RR type and
documented it, and then this document sat around for eight years, as it
did, I don't think it's reasonable to hold Patrik accountable for that,
and I think it discourages others from bringing work to the IETF.

On 3/6/15 4:22 PM, John C Klensin wrote:
> --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.
>
>
>