Telechat Review of draft-ietf-core-dev-urn-09
review-ietf-core-dev-urn-09-iotdir-telechat-thaler-2021-01-07-00

Reviewer: Dave Thaler
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: Dave Thaler
Review Date: 2021-01-07
IETF LC End Date: 2020-12-02
IESG Telechat date: 2021-01-21

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:art@ietf.org 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/

Section 3.2.1:
>   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/