Skip to main content

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 revision No specific revision (document currently at 11)
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 Fluffy Jennings , Zach Shelby
I-D 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
Request Telechat review on draft-ietf-core-dev-urn by Internet of Things Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/iot-directorate/tuv3TRsN_QUoV4qTBaaxuOltmUA
Reviewed revision 09 (document currently at 11)
Result Almost ready
Completed 2021-01-06
review-ietf-core-dev-urn-09-iotdir-telechat-housley-2021-01-06-00
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."