[core] Benjamin Kaduk's No Objection on draft-ietf-core-dev-urn-10: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk 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:
----------------------------------------------------------------------

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?