Reviewer: Dave Thaler Review result: Almost Ready I reviewed this document as part of the IoT Directorate's effort to IoT-related IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Internet Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-core-dev-urn-09 Reviewer: Dave Thaler Review Date: 2021-01-07 IETF LC End Date: 2020-12-02 IESG Telechat date: 2021-01-21 Summary: Almost Ready Major Concerns: 1) Section 3.1: > DEV URNs are > scoped to be globally applicable (see [RFC8141] Section 6.4.1) and > enable systems to use these identifiers from multiple sources in an > interoperable manner. If they’re “scoped to be globally applicable” MUST they be used only with globally unique device-specific identifiers and not with say MAC addresses with the U/L bit set to local? Clarify. 2) Section 5: > urn:dev:newsubtype:example-1-2-3_comp # A yet-to-be-defined > # subtype Section 7 does not make “newsubtype” be a reserved value. Hence there could be problems if it ever got allocated in a way that way incompatible with the rest of the URN in this example. Recommend changing “newsubtype” to “example” or similar, and making it be reserved for documentation. 3) Section 7 says: > Additional subtypes for DEV URNs can be defined through Specification > Required or IESG Approval [RFC8126]. Question: Why burden the IESG, rather than say Expert Review? For comparison, URI schemes use: > Expert Review for Permanent and Historical registrations, > First Come First Served for Provisional registrations Given that a requester could get a new URI scheme and use that with any app that supports URIs (and not just URNs), it would seem unnecessarily burdensome to me to put this on the IESG rather than following the URI scheme name precedent for permanent registrations. 4) Section 8.1: > [OW] IEEE, "Overview of 1-Wire(R) Technology and Its Use", > MAXIM > http://www.maxim-ic.com/app-notes/index.mvp/id/1796, June > 2008, > . This URL does not resolve for me. Since this reference is normative, this seems like a potential blocker. Minor Concerns: 5) Abstract and introduction sections both say: > A URN-based > representation can be easily passed along in any application that > needs the information This is overstated. If you have an application designed to pass around IP addresses (in protocols, file formats etc. with fields that can only fit IP addresses), then a URN-based representation cannot be “easily” passed along in “any” application. Such applications might be common in some IoT contexts. The intro extends the above sentence with the phrase > as it fits in protocols > mechanisms that are designed to carry URNs Which highlights my point. “any” != ones "that are designed to carry URNs” 6) Intro says: > Using URNs in these formats is often preferable > as they are universally recognized and self-describing, and therefore > avoid the need for agreeing to interpret an octet string as a > specific form of a MAC address, for instance. True. But for things using CBOR instead of JSON, URNs can be carried but would consume more space and so may be less desirable for some constrained use cases. If my previous comment above is addressed, the text here may be ok because it is at least prefixed with “often” which is fine. Whether you call out the downside of making the CBOR larger is up to you, but personally I think it would be fair to mention it. 7) Section 3 says: > Registrant: IETF and the CORE working group. Should the working > group cease to exist, discussion should be directed to the general > IETF discussion forums or the IESG. Why the general IETF discuss list and not an area specific list like mailto:art@ietf.org since core is in the art area? For example, when an int area WG closes, discussion defaults back to int-area. Why would this be different? And regarding the “or”: One answer is better than two divergent answers. Why not drop the “or the IESG”? This is related to my IANA allocation policy comment #3. 8) Section 4.4 says: > Editor's Note (Please remove before publication): The DEV URN "os" > subtype has originally been defined in the LwM2M standard, but has > been incorporated here to collect all syntax associated with DEV > URNs in one place. At the same time, the syntax of this subtype > was changed to avoid the possibility of characters that are not > allowed in SenML Name field (see [RFC8428] Section 4.5.1). > > Organizations are also encouraged to select serial number formats > that avoid possibility for ambiguity, in the form of leading > zeroes or otherwise. Above implies all the text in those two paragraphs should be deleted before publication. But much of it is useful to keep, especially since section 4.5 first and last paragraphs keep most of the same information for “ops”. Recommend making section 4.4 match section 4.5 in terms of what to keep/drop. 9) Section 5: > urn:dev:ow:10e2073a01080063 # The 1-Wire temperature > # sensor in Jari's > # kitchen Why is “in Jari’s kitchen” stated? The location is not relevant in any other example, and as far as I can tell there’s nothing in the URL that identifies a location 10) Section 5: > urn:dev:ow:264437f5000000ed_humidity # The laundry sensor's > # humidity part What in the URL identifies this as laundry? As opposed to “the humidity part of a 1-wire device”? 11) Appendix A does not say whether it is to be removed before publication. I’m guessing it is intended to be removed. Nits: Section 1: > support MAC addresses as one of type of an identifier. However, s/one of type of/one type of/ Section 3.2.1: > i.e,. two URNs are URN-equivalent if their assigned-name portions are s/i.e,./i.e.,/ Section 3.3: > (and often does) have multiple identifiers, e.g,. identifiers s/e.g,./e.g.,/ Section 4.2: Mostly it’s “1-Wire” in this section but once it’s capitalized “1-wire”. Be consistent. Many places: document mixes “organization” and “organisation” (z vs s) throughout. Be consistent. Section 4.5: > does not specify how thy are allocated. s/thy/they/