Re: [urn] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice

Adam Roach <adam@nostrum.com> Tue, 07 January 2020 16:35 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96375120855; Tue, 7 Jan 2020 08:35:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level:
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
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 d05P0sxs3B5X; Tue, 7 Jan 2020 08:35:22 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68DFD120851; Tue, 7 Jan 2020 08:35:18 -0800 (PST)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 007GZEEY063997 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 7 Jan 2020 10:35:16 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1578414917; bh=kh6+P4K8azbFqbi6ACYIBh3BOFCHbZc1rccEKnmGM0A=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=TDf+0KU4w5wgOd6b0WPrKO0xIbU/DD0d7eEr+PG1cQXNYXNtUdCcFNV0jDgAL4De3 6KkWoZf38deb3FsVYydMxXdm3v4P/L1sUvue8E/836iG8eWgUW5TomcufbkQbPwzf0 2wHAQJpFo5KSt5gVTnAnXSOk5rPdChZKWXxRHE9I=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: John C Klensin <john-ietf@jck.com>, iesg@ietf.org
Cc: art@ietf.org, mnot@mnot.net, urn@ietf.org, ietf@ietf.org
References: <87E116C31DAF1434C3C3937F@PSB>
From: Adam Roach <adam@nostrum.com>
Message-ID: <a267e8d7-e88f-fe84-a3d4-eb12b88a46ad@nostrum.com>
Date: Tue, 07 Jan 2020 10:35:09 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <87E116C31DAF1434C3C3937F@PSB>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/5J6Ss0w9OaQeE57Aboyda_Kn5Co>
Subject: Re: [urn] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2020 16:35:28 -0000

To help with framing this conversation, the changes from RFC 7320 are 
highlighted here:

https://www.ietf.org/rfcdiff?url1=rfc7320&url2=draft-nottingham-rfc7320bis-03

I have some rather extensive thoughts on the process of creating bis 
documents [1]. While I'm not going to reiterate all of them here, I want 
to highlight a specific passage that seems to bear on John's comments:

>    One major concern that drives these incremental document updates is
>    that an attempt to republish an RFC as originally described in RFC
>    2026 can result in such an effort being bogged down by issues that
>    exist in text unrelated to the desired changes.  Such issues can
>    arise from a change in the consensus of the IETF around best current
>    practices, such as in the areas of security, privacy, or
>    architectural design of an underlying protocol.  This complication
>    arises from the fact that processing of an updated full version of an
>    RFC is procedurally identical to processing of a green-field
>    definition of a new protocol: review by the IETF at large, and review
>    by the IESG, are performed on the entire document, leaving legacy
>    text open to comments that will delay - and occasionally block -
>    publication of such documents.


/a

____
[1] https://tools.ietf.org/html/draft-roach-bis-documents-00

On 1/7/20 12:57 AM, John C Klensin wrote:
> Hi.
>
> My apologies for the extreme lateness of this note.  I have
> tried to pass URN work on to others since RFCs 8141 and 8254 and
> had assumed that someone else would check through this document
> to be sure that it appropriately covered both locator-type and
> name-type URIs (particularly URNs) (see RFC 3986 Section 1.1.3).
> I had assumed that reviews within the ART area and/or a specific
> ART Area Review would address that topic but, AFAICT, they may
> not have done so.
>
> I've had occasion to look through the document and I'm actually
> not sure about the name-locator distinction as it may apply to
> it.  This note will be short and is rather more about asking the
> IESG to be sure that any possible issues are addressed than to
> try to do a detailed review of the issues.
>
> AFAICT, the focus of the I-D is to be sure that applications and
> elaborations of any URI scheme be firmly under the control and
> management of the owner of that scheme and that possible
> deviations from that principle are well-controlled.
> http://www.w3.org/TR/2004/REC-webarch-20041215, Section 2.2.2.1,
> cited in the draft as [webarch] is clear that the ownership of a
> URN is delegated to the owners of URN Namespaces rather than
> being bound to the "urn" URI scheme itself.  I believe it is
> possible to read this document in a way that has no impact on
> URNs and URN namespaces.   However, it appears to me that, if
> read without appropriate care, some of the restrictions imposed
> on queries and fragments may be inconsistent with mechanisms and
> syntax for use in particular URN Namespaces or URNs generally
> that were contemplated and extensively discussed during the
> development of RFC 8141.  Those ideas were deferred by the WG
> for future work but the mechanisms may well be in use in
> important URN namespaces.  Because the last paragraph of Section
> 1.1 of this I-D essentially declares any existing specification,
> even a standards-track one or one adopted by other bodies, that
> does not comply with the recommendations of the I-D to be
> incorrect and in need of correction, the effects of a reading
> that retroactively restricts URN Namespace practices that are
> under the control of the Namespace owners could be quite serious.
>
> My preference would be that someone who has been more active
> with URN work and Namespace registrations in the last couple of
> years do a careful review of the document to determine whether
> my concerns justify some tuning of the text.  However, given how
> late it is in the review process (again, my apologies for not
> catching the issue until now), a reasonable alternative would be
> to simply insert a sentence early in the I-D that says that it
> applies primarily to locator-type URIs although name-type ones
> may find it useful as general guidance _or_ to explicitly call
> out the difference in ownership between URNs and other URI
> schemes.
>
>   thanks,
>     john
>
> p.s. It would be, IMO, helpful if the IESG and the community
> would think about the implications of BCP (or IETF-stream
> Informational) documents that effectively obsolete or deprecate
> existing standards without identifying them or explicitly
> updating them and whose responsibility it is to find the
> discrepancies.
>