Re: [Iot-directorate] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09

John C Klensin <john-ietf@jck.com> Wed, 13 January 2021 00:16 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: iot-directorate@ietfa.amsl.com
Delivered-To: iot-directorate@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38EF3A14AA; Tue, 12 Jan 2021 16:16:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 9GfaARhh_1CN; Tue, 12 Jan 2021 16:16:13 -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 DDC253A14B4; Tue, 12 Jan 2021 16:16:12 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1kzTpZ-0009g5-EB; Tue, 12 Jan 2021 19:16:09 -0500
Date: Tue, 12 Jan 2021 19:16:03 -0500
From: John C Klensin <john-ietf@jck.com>
To: Jari Arkko <jari.arkko@piuha.net>
cc: Russ Housley <housley@vigilsec.com>, iot-directorate@ietf.org, last-call@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, core@ietf.org
Message-ID: <D8003464FF064C592F73FB65@PSB>
In-Reply-To: <959CAC2A-A973-4302-842F-5A2955378F99@piuha.net>
References: <160996930502.21827.5533521556349871834@ietfa.amsl.com> <B091AE313126430286B0902C@PSB> <959CAC2A-A973-4302-842F-5A2955378F99@piuha.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-directorate/mIVEvvCLAGlx4WLYrPlpg7kXwf8>
Subject: Re: [Iot-directorate] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09
X-BeenThere: iot-directorate@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mailing list for the IoT Directorate Members <iot-directorate.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-directorate/>
List-Post: <mailto:iot-directorate@ietf.org>
List-Help: <mailto:iot-directorate-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jan 2021 00:16:15 -0000

Jari,

I think that your proposed text is ok.  Some more detailed
comments inline below, probably more for information than a
suggestion for further changes but others may disagree...

--On Wednesday, January 13, 2021 00:21 +0200 Jari Arkko
<jari.arkko@piuha.net> wrote:

> Hi John, nice to hear from you. Inline:
> 
>> Sorry I, or someone in the URN registration review process,
>> didn't catch this, but I think it is a little more complicated
>> than a nit.  When what became RFC 8141 was being developed,
>> several people made very clear to the WG that there was no
>> possible way for a URN specification to make an exception to
>> the syntax rules for URIs, including the rules about
>> percent-encoding in Sections 2.1 and 2.4 of RFC 3986.  
> 
> Thanks for bringing this point up. 
> 
> I'm not entirely sure that if we dug deeper, what the actual
> precedence rules between requirements from different RFCs
> would be*. Be that as it may, I'm not sure we need to have
> that debate.

In general, I would agree that precedence rules are often
debatable.  However, 3986 asserts that URNs are a type of URIs,
something the URN WG did not seriously consider trying to change
(and, I'm convinced, would not have been allowed to change had
it wanted to).   And draft-ietf-core-dev-urn asserted that these
are, after all, URNs.  Now suppose that, instead, the document
had been titled "FiddleFrobs for Device Identifiers".  Then I
think the WG could have had (and probably would have been forced
into) an absolutely fascinating discussion as to whether
FiddleFrobs where really URIs in disguise and hence should be
bound by 3986 and, if so and they were name-type URIs, whether
they were URNs or some other name-type creature [1].
Personally, the only thing I've confident about in terms of such
a discussion is that I would want to be as far away from it as
possible.


> How would people feel about the following text which I think
> describes the correct situation with respect to the percent
> encoding in DEV URNs, and does not claim to change any rules
> on 8141:
> 
>    … Due to the SenML RFC 8428
>    Section 4.5.1 rules, it is not desirable to use
> percent-encoding in    DEV URNs, and the subtypes defined in
> this specification do not    really benefit from
> percent-encoding.  However, this specification    does not
> deviate from the general syntax of URNs or their processing
> and normalization rules as specified in [RFC8141].

As I said above, I think it works.  However, since the rules
that set this discussion off are actually in 3986, I'd be
slightly more comfortable, and I think it would serve your
readers better in the long run, if you referenced 3986 as well
as 8141.  I don't think there is any point in going further than
that, e.g., by identifying the sections involved.


> This text is in my soon-to-be-submitted version -10, available
> here:
>  
> https://arkko.com/ietf/core/draft-ietf-core-dev-urn-from--09.d
> iff.html
> 
> Jari
> 
> *) One could for instance also argue that all URN subtype
> specifications are narrowing down of the general syntax,
> although one might equally well point out that there are some
> real-life limitations of e.g. software processing that occurs
> before handing a URN to a particular module, which might
> dictate that some general URN processing rules are adhered to.
> Or there's some other reason that prevents the particular
> narrowing down that's in -09.

But that is similar or identical to the arguments the URNBIS WG
tried to make vis-a-vis 3986, i.e., that we could take what 3986
allowed and further restrict the syntax and/or provide more
specific interpretations of semantics. As I suggested, and
Martin Dürst affirmed, that didn't get us very far.  I strongly
suggest that you take your proposed paragraph above (preferably
with the additional reference), run with it, and put this little
blip behind you and behind the WG :-)

best,
   john



[1] See Section 1.1.3 of RFC 3986.