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

Request Review of draft-ietf-core-dev-urn
Requested rev. no specific revision (document currently at 10)
Type Telechat Review
Team Internet of Things Directorate (iotdir)
Deadline 2021-01-17
Requested 2021-01-05
Requested by Éric Vyncke
Authors Jari Arkko, Cullen Jennings, Zach Shelby
Draft last updated 2021-01-06
Completed reviews Secdir Last Call review of -08 by Brian Weis (diff)
Genart Last Call review of -08 by Christer Holmberg (diff)
Opsdir Last Call review of -08 by Dan Romascanu (diff)
Iotdir Telechat review of -09 by Dave Thaler (diff)
Iotdir Telechat review of -09 by Russ Housley (diff)
Genart Telechat review of -09 by Christer Holmberg (diff)
Comments
As this 20-page document could be used in the IoT world, I would appreciate it if one IoT directorate reviewer read and commented this document.

Thank you and Happy New Year

-éric
Assignment Reviewer Russ Housley 
State Completed
Review review-ietf-core-dev-urn-09-iotdir-telechat-housley-2021-01-06
Posted at https://mailarchive.ietf.org/arch/msg/iot-directorate/tuv3TRsN_QUoV4qTBaaxuOltmUA
Reviewed rev. 09 (document currently at 10)
Review result Almost Ready
Review completed: 2021-01-06

Review
review-ietf-core-dev-urn-09-iotdir-telechat-housley-2021-01-06

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