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

Patrik Fältström <paf@netnod.se> Thu, 26 February 2015 14:57 UTC

Return-Path: <paf@netnod.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 B1B5B1A0252 for <ietf@ietfa.amsl.com>; Thu, 26 Feb 2015 06:57:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.96
X-Spam-Level:
X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 RCXa3hLUoUqt for <ietf@ietfa.amsl.com>; Thu, 26 Feb 2015 06:57:39 -0800 (PST)
Received: from mail.netnod.se (mail.netnod.se [192.71.80.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0F91C1A0217 for <ietf@ietf.org>; Thu, 26 Feb 2015 06:57:39 -0800 (PST)
Received: from vpn-client-208.netnod.se (vpn-client-208.netnod.se [192.71.80.208]) (Authenticated sender: paf) by mail.netnod.se (Postfix) with ESMTPSA id F36607C0BD; Thu, 26 Feb 2015 15:57:37 +0100 (CET)
Subject: Re: (long/architectural version) Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_03A8DFA6-B8E4-43F5-9801-83A55B912EB4"; protocol="application/pgp-signature"; micalg="pgp-sha1"
X-Pgp-Agent: GPGMail 2.5b5
From: Patrik Fältström <paf@netnod.se>
In-Reply-To: <20150225231404.605752A5E872@rock.dv.isc.org>
Date: Thu, 26 Feb 2015 15:57:36 +0100
Message-Id: <F10A9CC2-1963-4CA1-A89F-B47425DF78BF@netnod.se>
References: <63E6A7996E894E4167393345@JcK-HP8200.jck.com> <20150225231404.605752A5E872@rock.dv.isc.org>
To: Mark Andrews <marka@isc.org>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/n-3UOuu2lI61vn1Yq-rxdtWFS5E>
X-Mailman-Approved-At: Thu, 26 Feb 2015 08:12:10 -0800
Cc: John Klensin <john-ietf@jck.com>, 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, 26 Feb 2015 14:57:41 -0000

> On 26 Feb 2015, at 00:14, Mark Andrews <marka@isc.org> wrote:
> 
>> (1)  Integrity of the standards process.
>> 
>> For many years, it was a key IETF principle that standardization
>> of a particular technology meant that the community had been
>> able to review all of the details, make changes where needed,
>> and then reach rough consensus on the result.  The notion of
>> registering an RRTYPE via Expert Review and then turning around
>> and asking that it be standardized while claiming that details
>> (or even design principles) cannot be changed because it is
>> already registered and in use represents a fundamental departure
>> from and threat to our historical standardization model.  No
>> malice is implied here, just a bad sequence of steps.   I don't
>> know that it makes a lot of difference how this particular spec
>> is classified, but, noting that the same situation could apply
>> to a number of other specifications where registration is by
>> expert review (Media Types come to mind as do URIs and, if
>> 2141bis is approved in more or less its current form, URNs), it
>> seems to me that the IETF needs to address this issue, perhaps
>> confining specifications for already registered names to
>> Informational or Experimental categories and figuring out an
>> alternative to expert review for specs that people will want on
>> the standards track.
> 
> There is no requirement to use expert review.  The full blown rfc
> process is still available.  If you use expert review however the
> format of the record is fixed when the review is done.  [ For the
> record the format of the record changed which was annoying for those
> of us that wrote explict code to handle the type.  The reference
> for the type will need to be updated if it hasn't been done. ]

I think there are a number of things we have problems with in the IETF. Like cross-area-review and because of this design. Each area look at things from their perspective and hold hard to their ideas on the future of the world.

In this specific case, sure, like many other definitions by IETF it was not optimal when the review happened, but maybe it is wrong to have the later published RFC on standards track as it seems to end up? Maybe it should be "just" informational (if that matters).

Regarding the change that Mark point out in this case, the clarification that was made from an earlier draft to what we now have have are I claim not incompatible with what is in the application for an RRType that was applied for. The difference is that we now clarify that the URI is "just bytes" to the end of the RDATA field. It is not an (as defined in DNS) text string which has limited length. I.e. we all remember a TXT RRType can have multiple text strings in the RDATA field.

This clarification was made in cooperation and in coordination with people that implement URI (which was when this was discovered).

At least that is what I think you do talk about Mark?

   Patrik