Uniform Resource Names for Device Identifiers
RFC 9039

Note: This ballot was opened for revision 09 and is now closed.

Erik Kline Yes

Warren Kumari Yes

Comment (2021-01-20 for -10)
Thank you for this document -- it is both interesting and useful.

I'd also like to thank Dan for the helpful OpsDir review.

Alvaro Retana No Objection

Benjamin Kaduk No Objection

Comment (2021-01-20 for -10)
What's the relationship of urn:dev:os: and urn:dev:ops to the stuff
already done by OMA LwM2M?  Section 4.4 has a note that it was
originally defined there, but the template in Section 3 says this is the
initial registration.  This seems particularly important if we are also
changing the syntax at the same time.  The referenced [LwM2M] document
seems to be
(based solely on the google results for the title and comparing the
revision number+date), which mentions neither "private enterprise
number" nor "dev:", "serial", etc.  I see a brief mention of this action
in the change log in Appendix A, but no clear indication of specific
change-control transfer or similar.

Do we really want to reference some "tutorials" from
www.maximintegrated.com as the normative reference for 1-Wire?

Thanks to Brian Weis for the secdir review, and thanks for updating the
document in response to it!

Section 1

   This document describes a new Uniform Resource Name (URN) [RFC8141]
   namespace for hardware device identifiers.  A general representation
   of device identity can be useful in many applications, such as in
   sensor data streams and storage [RFC8428], or equipment inventories
   [RFC7252], [I-D.ietf-core-resource-directory].

I'm not sure why RFC 7252 and [I-D.ietf-core-resource-directory] appear
to be getting used as references for "equipment inventories" when
neither mentions either term.

   [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

Similarly, RFC 8428 appears to be unrelated to either the XML or JSON
formats directly.

   Future device identifier types can extend the device URN type defined
   here, or define their own URNs.

Do we want a forward-reference to Section 7 here (we have one later on
where a similar statement appears)?

Section 6

We might mention again the case-sensitivity issue, and that in many
cases it is easy for an attacker to create collisions.  But neither of
those seems particularly earth-shattering.

Section 7

Do we anticipate the future allocation of a "null" subtype? ;)

On a more serious note, though, "Specification Required" comes with
Expert Review -- is there more guidance we should give to the experts
about when to reject or accept a proposed new subtype other than "there
is a new namespace with stable reference"?  Perhaps a bias towards
accepting all proposals that even weakly meet that criterion and are not abusive,
even if not in broad use?

Martin Duke No Objection

Martin Vigoureux No Objection

Murray Kucherawy No Objection

Robert Wilton No Objection

Comment (2021-01-18 for -10)
No email
send info
Thank you for this useful document, and Dan for the ops area review.

Roman Danyliw No Objection

Comment (2021-01-20 for -10)
Thank you to Brian Weis for the SECDIR review.

** Section 1.  Per “UUID-based identifiers are recommended for all general purpose uses when MAC addresses are available as identifiers”, this recommendation (non-normative) to use UUIDs without any context seems too strong.  To me, it read like, “if you have a MAC then this is perfectly acceptable UUID”.

** Section 3.3.  Per “The DEV URN type SHOULD only be used for persistent identifiers, such as hardware-based identifiers”, I have a few comments around the notion of “persistent”.  

-- Shouldn’t the text be s/persistent identifiers/hardware device identifiers/ as this is the definition from the first sentences of Sections 1 and 3.1?

-- It seems like the document should acknowledge that “hardware-based identifiers” come in different flavors of permanence

-- What would be the case for the DEV URNs to be used as ephemeral identifiers (as permitted by this text not using a MUST?)

** Section 6.  Repeating the caution from Section 6 of RFC4122 seems applicable here – (paraphrasing as this urn is more generic than RFC4122) without deferring to the policies governing particular sub-types and their delegated assignees (through PENs, etc.), no assumptions should be made that these URNs are “hard to guess”.

** Section 6.1.  Per “Also, usually here is no easy way to change the identifiers”, this reads a bit too strong of a statement.  Given the virtualization and OS privacy features, MACs are trivial to change and urn:dev:org is defined with sufficient ambiguity (which makes sense) that it isn’t clear what rules govern it.

** Section 6.2.  It would be useful to unpack “illegitimate entities on the path” – are this malicious entities which put themselves on the path, entities expected to be on the path that are acting contrary to the intent of the end points, compromised on-path infrastructure, etc …

Éric Vyncke No Objection

Comment (2021-01-18 for -10)
Thank you for the work put into this document. I just wonder why this document is the work of CORE as it is quite generic and could be used outside of CORE (but, this is not a problem at all as it is an IETF stream document and had an IETF last call).

There have been two IoT directorate reviews by:
- Dave Thaler https://datatracker.ietf.org/doc/review-ietf-core-dev-urn-09-iotdir-telechat-thaler-2021-01-07/
- Russ Housley: https://datatracker.ietf.org/doc/review-ietf-core-dev-urn-09-iotdir-telechat-housley-2021-01-06/
both reviews have a status of 'Almost Ready' that translates into authors SHOULD really address the comments (and I have seen already many email messages on those reviews).

Please find below some non-blocking COMMENT points (but replies would be appreciated), and one nit.

I hope that this helps to improve the document,




-- Section 4.1 --
Should "FFFF" be replaced by "0xffff" especially as there is some text before (section 3.2.1) suggesting to use lowercase of MAC addresses ?

More important: can MAC address be part of an identifier in the world of random MAC address (or on the spot generated MAC address -- think VM) ? I suggest to add some text around MAC address randomization impact.

== NITS ==

-- Section 4.2 --
s/64 bit identifier/64-bit identifier/ ?

(Barry Leiba; former steering group member) Yes

Yes ( for -09)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection ( for -10)
No email
send info