Skip to main content

Uniform Resource Names for Device Identifiers
draft-ietf-core-dev-urn-11

Yes

Erik Kline
(Barry Leiba)

No Objection

Murray Kucherawy
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Magnus Westerlund)
(Martin Duke)
(Martin Vigoureux)

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

Erik Kline
Yes
Warren Kumari
Yes
Comment (2021-01-20 for -10) Sent
Thank you for this document -- it is both interesting and useful.

I'd also like to thank Dan for the helpful OpsDir review.
Murray Kucherawy
No Objection
Roman Danyliw
No Objection
Comment (2021-01-20 for -10) Sent
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) Sent
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,

Regards,

-éric

== COMMENTS ==


-- 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 IESG member
Yes
Yes (for -09) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -10) Not sent

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -10) Not sent

                            
Benjamin Kaduk Former IESG member
No Objection
No Objection (2021-01-20 for -10) Sent
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
https://www.openmobilealliance.org/release/LightweightM2M/V1_2-20190124-C/OMA-RD-LightweightM2M-V1_2-20190124-C.pdf
(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?
Deborah Brungard Former IESG member
No Objection
No Objection (for -10) Not sent

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (for -10) Not sent

                            
Martin Duke Former IESG member
No Objection
No Objection (for -10) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -10) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (2021-01-18 for -10) Not sent
Thank you for this useful document, and Dan for the ops area review.