Ballot for draft-ietf-core-dev-urn
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
Thank you for this document -- it is both interesting and useful. I'd also like to thank Dan for the helpful OpsDir review.
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 …
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/ ?
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?
Thank you for this useful document, and Dan for the ops area review.