Subject: [core] Roman Danyliw's No Objection on draft-ietf-core-dev-urn-10: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 20 Jan 2021 06:34:30 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-core-dev-urn-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-dev-urn/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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 …