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

From: Russ Housley via Datatracker <[email-masked]>
Date: Wed, 06 Jan 2021 13:41:45 -0800

Reviewer: Russ Housley
Review result: Almost Ready

I reviewed this document as part of the IoT Directorate's effort to
IoT-related IETF documents being processed by the IESG.  These comments
were written primarily for the benefit of the Internet Area Directors.
Document authors, document editors, and WG chairs should treat these
comments just like any other IETF Last Call comments.

Document: draft-ietf-core-dev-urn-09
Reviewer: Russ Housley
Review Date: 2021-01-06
IETF LC End Date: 2020-12-02
IESG Telechat date: 2021-01-21

A review from the IoT Directorate was requested on 2021-01-05, which is
after the IETF Last Call ended.  I assume that the Internet ADs want
this review to help inform them during IESG Evaluation.

Summary: Almost Ready

Major Concerns:

Section 3.2 says:

   The optional underscore-separated components following the hexstring
   are strings depicting individual aspects of a device.

Not all of the DEV URN forms contain a hexstring; however, all of them
are allowed to end with underscore-separated components.  I suggest:

   The optional underscore-separated components at the end of the
   DEV URN depict individual aspects of a device.

Section 3.2.1 says:

   ... and a MAC address could be represented either with
   uppercase or lowercase hexadecimal digits.

This is not allowed by the ABNF:

   hexstring = 1*(hexdigit hexdigit)
   hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"

If both cases are to be supported, the upper case letters need to be
added to the ABNF to permit them.

Section 4.2 says:

   ... 
   64-bit identifier that consists of 8 byte family code, 48 bit
   identifier unique within a family, and 8 bit CRC code [OW].

The math does not work.  I suspect: s/8 byte/8 bit/

Section 6 says:

   ... An implementation of the DEV URN MUST NOT
   change these properties from what they were intended.

It is not clear to me the meaning of "they" in this sentence.
Please clarify.

Minor Concerns:

Section 3.2 says:

   DEV URNs do not use r-, q-, or f-components.

I would have liked a bit more context here.  I suggest:

   DEV URNs do not use r-, q-, or f-components as defined in [RFC8141].

Section 3.2.1 refers to "BASE64".  Please add an informative reference
to RFC 4648 to be clear.

Section 4.1 uses the term "Ethernet" in two places.  I think both of
them should be replaced by "MAC-48".

Nits:

Section 3.2 says:

   However, due to the SenML RFC 8428 Section 4.5.1 rules, DEV URNs
   do not support percent-encoding.
   
This does not seem like a "however" statement to me.  Perhaps, it is
a "Note that" statement.  Or, just drop "However".

Section 4.1: s/rests within the IEEE/
              /rests with the IEEE Registration Authority/
              
Section 7 includes: "publicly available specification that can
be pointed to."  It is sufficient to say: ""publicly available
specification."

---

From: Barry Leiba <[email-masked]>
Date: Wed, 6 Jan 2021 16:49:55 -0500

Thanks for the quick review, Russ, and good catches here.

> added to the ABNF to permit them.

Actually not: quoted letters in ABNF are case-insensitive, so “a” matches
both lowercase a and uppercase A.

Barry

---

From: John C Klensin <[email-masked]>
Date: Wed, 06 Jan 2021 20:00:41 -0500

Russ, Barry, 

Another small catch...

--On Wednesday, January 6, 2021 13:41 -0800 Russ Housley via
Datatracker <[email-masked]> wrote:

> Nits:
> 
> Section 3.2 says:
> 
>    However, due to the SenML RFC 8428 Section 4.5.1 rules, DEV
> URNs    do not support percent-encoding.
>    
> This does not seem like a "however" statement to me.  Perhaps,
> it is a "Note that" statement.  Or, just drop "However".

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.  I can't
speak to what the URNBIS WG would have done had it been allowed
to consider the options that might have been opened by
developing different requirements for locators and names and, in
particular, whether any such changes would have affected
percent-encoding.   However, it was painfully clear that no URN,
much less any particular URN namespace definition, can alter
those rules.

At this point, the most obvious option would be to change the
statement in  draft-ietf-core-dev-urn to note that the RFC 3986
rules apply and explain (inline or by reference) how
percent-encoding works.  Such a statement might explain that,
given the characters permitted in RFC 8428 Section 4.5.1,
percent-encoding should never be necessary within a DEV URN.
However, because the list in 8428 includes characters that are
defined as "Reserved Characters" in Section 2.2 of RFC 3986,
notably including ":" and "/", the possibility of their being
percent-encoded by some process allowed by 3986 cannot be
eliminated.  

Other alternatives involve updating RFC 8141 and 3986, but I
wouldn't recommend going there, especially if the CORE WG would
like to see the current spec published in 2021.  The narrowest
of those updates would be to change the rather relaxed-sounding
language of RFC 3986 Section 2.1: 

	"used to represent a data octet in a component when that
	octet's corresponding character is outside the allowed
	set or is being used as a delimiter of, or within, the
	component."

To say that percent-encoding MUST NOT be used unless actually
required, but I'd guess that would not go over well with
existing implementations.   

Or, I suppose, the IESG could decide either that 3986 does not
count or that an interpretation that disallowed URN namespaces
prohibiting things that it allows is incorrect.  But someone
would probably take that as a commitment to allow a revision to
8141 that would codify the options that would imply.

     john

p.s. This not being spotted earlier may be a contribution to the
discussion that is now occurring on the IETF list of early
cross-area review and how important it is to facilitate, rather
than discourage, such reviews.  Or not.

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 7 Jan 2021 20:17:08 +0900

Hello everybody,

> much less any particular URN namespace definition, can alter

John is completely correct here, many thanks for spotting this. Please 
also note the sentence

"The lexical equivalence of the DEV URNs is defined as an exact and
case sensitive string match.".

Apart from the fact that this would be better written as "an exact case 
sensitive string match", lexical equivalence has to take into account 
percent-escaping. That means that e.g.

urn:dev:mac:0024beffff804ff1 and
urn:dev:mac:0024beffff804ff%31

are equivalent. I'm sorry I don't have the time to read the whole spec; 
it would be good if some of the authors went over it again with a fine 
comb after rereading RFC 3986 and understanding how percent-escaping 
works. If they have questions, the URN mailing list ([email-masked]) or 
the URI mailing list ([email-masked]) would be the best places to ask for 
advice.

Regards,   Martin.

---

From: Russ Housley <[email-masked]>
Date: Thu, 7 Jan 2021 08:06:34 -0500

Barry:

You are, of course, correct.  RFC 5234 says:

      ABNF strings are case insensitive and the character set for these
      strings is US-ASCII.

However, that raises a different issue:

   The DEV URN syntax allows both upper and lower case characters.  The
   URN-equivalence of the DEV URNs is defined per [RFC8141] Section 3.1,
   i.e,. two URNs are URN-equivalent if their assigned-name portions are
   octet-by-octet equal after applying case normalization to the URI
   scheme ("urn") and namespace identifier ("dev").

So, the ABNF should be changed so that the "mac:", "ow:", "org:", "os:", and "ops:" are required to be lowercase.  I guess that means replacing each letter with the appropriate value in the %x61-7A range.  That will not be as easy to read...

Russ

> On Jan 6, 2021, at 4:49 PM, Barry Leiba <[email-masked]> wrote:
> 
> Actually not: quoted letters in ABNF are case-insensitive, so “a” matches both lowercase a and uppercase A.
> 
> Barry
> 
> On Wed, Jan 6, 2021 at 4:41 PM Russ Housley via Datatracker <[email-masked] <mailto:[email-masked]>> wrote:
> Reviewer: Russ Housley
> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Jan 2021 08:30:56 -0500

> So, the ABNF should be changed so that the "mac:", "ow:", "org:", "os:", and "ops:" are required to
> be lowercase.  I guess that means replacing each letter with the appropriate value in the %x61-7A
> range.  That will not be as easy to read...

Not if it's done that way, indeed.  But RFC 7405 helps us here.

Barry

---

From: Russ Housley <[email-masked]>
Date: Thu, 7 Jan 2021 08:33:13 -0500

> Not if it's done that way, indeed.  But RFC 7405 helps us here.

Indeed, I forgot about RFC 7405.  Much better solution.

Russ

---

From: Ãric Vyncke (evyncke) <[email-masked]>
Date: Thu, 7 Jan 2021 14:20:20 +0000

Thank you Russ for your review, it was indeed for a telechat review

Regards

-éric

-----Original Message-----
From: Iot-directorate <[email-masked]> on behalf of Russ Housley via Datatracker <[email-masked]>
Reply-To: Russ Housley <[email-masked]>
Date: Wednesday, 6 January 2021 at 22:42
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Iot-directorate] Iotdir telechat review of draft-ietf-core-dev-urn-09

    Reviewer: Russ Housley

    Summary: Almost Ready

    Major Concerns:

    Section 3.2 says:

    Section 3.2.1 says:

    Section 4.2 says:

       ... 

    Section 6 says:

    Minor Concerns:

    Section 3.2 says:

    Nits:

    Section 3.2 says:

    -- 
    Iot-directorate mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/iot-directorate

---

From: Jari Arkko <[email-masked]>
Date: Thu, 7 Jan 2021 20:50:43 +0200

Many thanks for your very useful review, Russ!

Some discussion inline, but I have a set of tentative changes at https://arkko.com/ietf/core/draft-ietf-core-dev-urn-from--09.diff.html

I plan to submit a new version, as soon as I’ve gone through the new full thread. The changes so far only relate to your comments, Russ.

>   DEV URN depict individual aspects of a device.

Yes. I changed this.

> added to the ABNF to permit them.

As pointed out by Barry, this is indeed possible. I’m not entirely sure how necessary it was to restrict the subtypes to lower case — RFC 8141 is clear that types can be both cases — but I’ve tentatively done that.

> The math does not work.  I suspect: s/8 byte/8 bit/

Good catch! Corrected.

> It is not clear to me the meaning of "they" in this sentence.

I made a small change, but I’m not sure how else to express this. We are talking about whether identifiers are modifiable for instance. The whole paragraph reads now:

On most devices, the user can display device identifiers. Depending
on circumstances, device identifiers may or may not be modified or
tampered with by the user. An implementation of the DEV URN MUST NOT change
such limitations or behaviour from what they were intended. In particular, a device
identifier that is intended to be immutable should not become mutable
as a part of implementing the DEV URN type. More generally, nothing in
this document should be construed to override what the relevant device
specifications have already said about the identifiers.

>   DEV URNs do not use r-, q-, or f-components as defined in [RFC8141].

That would be good. Changed.

> Section 3.2.1 refers to "BASE64".  Please add an informative reference

Good idea. Done.

> them should be replaced by "MAC-48”.

Right. Done.

> a "Note that" statement.  Or, just drop "However”.

Ok (I have not yet considered John’s comments).

>              /rests with the IEEE Registration Authority/

Thanks.

> specification.”

Ok. Changed.

Jari

---

From: Dave Thaler <[email-masked]>
Date: Thu, 7 Jan 2021 20:55:02 +0000

>    added to the ABNF to permit them.

That is not correct.  It is already allowed by the ABNF.

RFC 5234 explains:

      strings is US-ASCII.

   Hence:

         rulename = "abc"

   and:

         rulename = "aBc"

   will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and

   "ABC".

      To specify a rule that is case sensitive, specify the characters

      individually.

   For example:

         rulename    =  %d97 %d98 %d99

   or

         rulename    =  %d97.98.99

   will match only the string that comprises only the lowercase

   characters, abc.

Dave

---

From: Dave Thaler <[email-masked]>
Date: Thu, 7 Jan 2021 21:49:54 +0000

(I didn’t get an assignment in the datatracker so just sending using manually crafted email)

Reviewer: Dave Thaler

Reviewer: Dave Thaler
Review Date: 2021-01-07

Summary: Almost Ready

Major Concerns:

1) Section 3.1:

> DEV URNs are
> scoped to be globally applicable (see [RFC8141] Section 6.4.1) and
> enable systems to use these identifiers from multiple sources in an
> interoperable manner.

If they’re “scoped to be globally applicable” MUST they be used only with globally unique device-specific identifiers and
not with say MAC addresses with the U/L bit set to local?   Clarify.

2) Section 5:

> urn:dev:newsubtype:example-1-2-3_comp   # A yet-to-be-defined
>                                         # subtype

Section 7 does not make “newsubtype” be a reserved value.
Hence there could be problems if it ever got allocated in a way that way incompatible with the rest of the URN in this example.
Recommend changing “newsubtype” to “example” or similar, and making it be reserved for documentation.
  
3) Section 7 says:

> Additional subtypes for DEV URNs can be defined through Specification
> Required or IESG Approval [RFC8126].  

Question: Why burden the IESG, rather than say Expert Review?

For comparison, URI schemes use:
> Expert Review for Permanent and Historical registrations, 
> First Come First Served for Provisional registrations

Given that a requester could get a new URI scheme and use that with any app that supports URIs (and not just URNs),
it would seem unnecessarily burdensome to me to put this on the IESG rather than following the URI scheme name
precedent for permanent registrations.

4) Section 8.1:

>   [OW]       IEEE, "Overview of 1-Wire(R) Technology and Its Use",
>              MAXIM
>              http://www.maxim-ic.com/app-notes/index.mvp/id/1796, June
>              2008,
>              <http://www.maxim-ic.com/app-notes/index.mvp/id/1796>.

This URL does not resolve for me.  Since this reference is normative, this seems like a potential blocker.

Minor Concerns:
   
5) Abstract and introduction sections both say: 
>  A URN-based
> representation can be easily passed along in any application that
> needs the information

This is overstated.  If you have an application designed to pass around IP addresses (in protocols,
file formats etc. with fields that can only fit IP addresses), then a URN-based representation cannot
be “easily” passed along in “any” application.  Such applications might be common in some IoT contexts.

The intro extends the above sentence with the phrase
> as it fits in protocols
> mechanisms that are designed to carry URNs 

Which highlights my point.  “any” != ones "that are designed to carry URNs”

6) Intro says:
> Using URNs in these formats is often preferable
> as they are universally recognized and self-describing, and therefore
>  avoid the need for agreeing to interpret an octet string as a
>  specific form of a MAC address, for instance.

True.  But for things using CBOR instead of JSON, URNs can be carried but would consume more
space and so may be less desirable for some constrained use cases.   If my previous comment
above is addressed, the text here may be ok because it is at least prefixed with “often” which
is fine.  Whether you call out the downside of making the CBOR larger is up to you, but 
personally I think it would be fair to mention it.

7) Section 3 says:
>   Registrant: IETF and the CORE working group.  Should the working
>  group cease to exist, discussion should be directed to the general
>  IETF discussion forums or the IESG.

Why the general IETF discuss list and not an area specific list like mailto:[email-masked] since core is in the art area?
For example, when an int area WG closes, discussion defaults back to int-area.  Why would this be different?
And regarding the “or”: One answer is better than two divergent answers.  Why not drop the “or the IESG”? 
This is related to my IANA allocation policy comment #3.

8) Section 4.4 says:
>      Editor's Note (Please remove before publication): The DEV URN "os"
>      subtype has originally been defined in the LwM2M standard, but has
>      been incorporated here to collect all syntax associated with DEV
>      URNs in one place.  At the same time, the syntax of this subtype
>      was changed to avoid the possibility of characters that are not
>      allowed in SenML Name field (see [RFC8428] Section 4.5.1).
>
>      Organizations are also encouraged to select serial number formats
>      that avoid possibility for ambiguity, in the form of leading
>      zeroes or otherwise.

Above implies all the text in those two paragraphs should be deleted before publication.
But much of it is useful to keep, especially since section 4.5 first and last paragraphs keep
most of the same information for “ops”.  Recommend making section 4.4 match section 4.5
in terms of what to keep/drop.

9) Section 5:
>       urn:dev:ow:10e2073a01080063             # The 1-Wire temperature
>                                               # sensor in Jari's
>                                               # kitchen

Why is “in Jari’s kitchen” stated?  The location is not relevant in any other example, and as far as I can tell there’s nothing in the URL that identifies a location

10) Section 5:
>       urn:dev:ow:264437f5000000ed_humidity    # The laundry sensor's
>                                               # humidity part

What in the URL identifies this as laundry?  As opposed to “the humidity part of a 1-wire device”?

11) Appendix A does not say whether it is to be removed before publication.  I’m guessing it is intended to be removed.

Nits:

Section 1:
>    support MAC addresses as one of type of an identifier.  However,

s/one of type of/one type of/
   
>   i.e,. two URNs are URN-equivalent if their assigned-name portions are

s/i.e,./i.e.,/

Section 3.3:

>   (and often does) have multiple identifiers, e.g,. identifiers

s/e.g,./e.g.,/

Section 4.2: Mostly it’s “1-Wire” in this section but once it’s capitalized “1-wire”.  Be consistent.

Many places: document mixes “organization” and “organisation” (z vs s) throughout.  Be consistent.

Section 4.5:

>  does not specify how thy are allocated.

s/thy/they/

---

From: Russ Housley <[email-masked]>
Date: Fri, 8 Jan 2021 11:44:15 -0500

Jari:

All but one of my comments are resolved.

> specifications have already said about the identifiers.

I am still unsure what an implementer would do to comply the MUST NOT statement.  Maybe it will helpful to turn it into a MUST statement.  Does this work for you?

On most devices, the user can display device identifiers. Depending
on circumstances, device identifiers may or may not be modified or
tampered with by the user. An implementation of the DEV URN MUST preserve
such limitations and behaviors associated with the device identifiers. In particular,
a device identifier that is intended to be immutable should not become mutable
as a part of implementing the DEV URN type. More generally, nothing in
this document should be construed to override what the relevant device
specifications have already said about the identifiers.

Russ

---

From: Jari Arkko <[email-masked]>
Date: Fri, 8 Jan 2021 20:59:07 +0200

Thanks for your review, Dave.

Updates are in https://arkko.com/ietf/core/draft-ietf-core-dev-urn-from--09.diff.html

> not with say MAC addresses with the U/L bit set to local?   Clarify.

Ok.

The new text reads:

   … DEV URNs are
   scoped to be globally applicable (see [RFC8141] Section 6.4.1) and,
   in general, enable systems to use these identifiers from multiple
   sources in an interoperable manner.  Note that in some deployments,
   ensuring uniqueness requires care if manual or local assignment
   mechanisms are used, as discussed in Section 3.3).

> Recommend changing “newsubtype” to “example” or similar, and making it be reserved for documentation.

Makes sense. Thanks.

> Question: Why burden the IESG, rather than say Expert Review?

In my experience, it has been useful to specify explicitly “or IESG Approval” in IANA rules so that if there’s ever a special case that can be dealt with. There is no need for expert review as Specification Required is sufficient for allocations in all the normal cases. There is no need to burned the IESG or the Expert in those cases.

For ajprevous example, see https://tools.ietf.org/html/rfc5237

> This URL does not resolve for me.  Since this reference is normative, this seems like a potential blocker.

Updated. The 1-wire material is, however, getting scarce. I think the reference that I’m using now is sufficient.

> Which highlights my point.  “any” != ones "that are designed to carry URNs”

Ok. I changed the wording.

> personally I think it would be fair to mention it.

I changed the above comment, and added some words here as well.

There’s a general tradeoff here with generality (pass any URN) vs. specificity and efficiency (e.g., pass 4 byte IP address).

New text:

   A URN-based representation can be passed along in applications that
   need the information.  It fits particularly well for protocols
   mechanisms that are designed to carry URNs [RFC7230], [RFC7540],
   [RFC3261], [RFC7252].  Finally, URNs can also be easily carried and
   stored in formats such as XML [W3C.REC-xml-19980210] or JSON
   [RFC8259] [RFC8428].  Using URNs in these formats is often preferable
   as they are universally recognized and self-describing, and therefore
   avoid the need for agreeing to interpret an octet string as a
   specific form of a MAC address, for instance.  Passing URNs may
   consume additional bytes compared to, for instance, passing 4-byte
   binary IPv4 addresses, but offers some flexibility in return.

> This is related to my IANA allocation policy comment #3.

See above for the IESG part of it.

I don’t have a strong opinion about which mailing list to advice people turn to. In reality they would google for the appropriate forum or person anyway.

I generalised the text. It now reads:

      Should the working
      group cease to exist, discussion should be directed to the application
      area or general IETF discussion forums, or the IESG.

> in terms of what to keep/drop.

Ok

> Why is “in Jari’s kitchen” stated?  The location is not relevant in any other example, and as far as I can tell there’s nothing in the URL that identifies a location

:-)

Because that was what the original spec said :-)

But I can remove it.

> What in the URL identifies this as laundry?  As opposed to “the humidity part of a 1-wire device”

As above. The text was clarified.

> 11) Appendix A does not say whether it is to be removed before publication.  I’m guessing it is intended to be removed.

Added.

>> does not specify how thy are allocated.

All updated.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 8 Jan 2021 21:01:01 +0200

Hi Russ,

> specifications have already said about the identifiers.

That sounds very good. Thanks!

Updated in the draft.

Jari

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 8 Jan 2021 20:26:40 +0100

On 2021-01-08, at 19:59, Jari Arkko <[email-masked]> wrote:
> 
> no need for expert review as Specification Required is sufficient

FYI: “Specification required” implies expert review.

RFC 8126:

4.6.  Specification Required

   For the Specification Required policy, review and approval by a
   designated expert (see Section 5) is required, and the values and
   […]

https://tools.ietf.org/html/rfc8126#section-4.6

Grüße, Carsten

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Jan 2021 00:21:03 +0200

Hi John, nice to hear from you. Inline:

> 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.

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].

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.diff.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.

---

From: Russ Housley <[email-masked]>
Date: Tue, 12 Jan 2021 17:22:33 -0500

That looks good to me.

Russ

> On Jan 12, 2021, at 5:21 PM, Jari Arkko <[email-masked]> wrote:
>

---

From: John C Klensin <[email-masked]>
Date: Tue, 12 Jan 2021 19:16:03 -0500

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
<[email-masked]> wrote:

>> possible way for a URN specification to make an exception to
>> the syntax rules for URIs, including the rules about
> 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:
> 
>    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

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.

> *) 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.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Jan 2021 09:53:29 +0200

Thanks, John. I will add the other reference and submit the draft.

Jari

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 13 Jan 2021 10:39:33 +0100

One nit on -10:
I don’t believe RFC 7405 allows whitespace after %s.

(The version of bap that I’m using doesn’t support RFC 7405 yet, so I can’t easily validate this belief.)

Grüße, Carsten

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Jan 2021 16:03:01 +0200

Thanks Carsten, and I think you are right. 

(I was also suffering from the same issue, so I was only able to verify the ABNF by removing the RFC 7405 syntax, hence didn’t catch this. Of course I should have paid more attention when writing it, though. RFC 7405 is clear that there’s no whitespace.)

Jari

---

From: Russ Housley <[email-masked]>
Date: Wed, 13 Jan 2021 10:35:08 -0500

https://tools.ietf.org/tools/bap/abnf.cgi

It seems to work properly if the space is dropped after the %s.

Russ

> On Jan 13, 2021, at 4:39 AM, Carsten Bormann <[email-masked]> wrote:
> 
> One nit on -10: