Re: [Iot-directorate] Iotdir telechat review of draft-ietf-core-dev-urn-09

[Jari Arkko <[e-mail]>]

Thanks for your review, Dave.

Updates are in https://arkko.com/ietf/core/draft-ietf-core-dev-urn-from--09.diff.html

Further discussion inline:

> 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.

Ok.

The new text reads:

   … DEV URNs are
   scoped to be globally applicable (see [RFC8141] Section 6.4.1) and,
   in general, enable systems to use these identifiers from multiple
   sources in an interoperable manner.  Note that in some deployments,
   ensuring uniqueness requires care if manual or local assignment
   mechanisms are used, as discussed in Section 3.3).

> 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.

Makes sense. Thanks.

> 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?

In my experience, it has been useful to specify explicitly “or IESG Approval” in IANA rules so that if there’s ever a special case that can be dealt with. There is no need for expert review as Specification Required is sufficient for allocations in all the normal cases. There is no need to burned the IESG or the Expert in those cases.

For ajprevous example, see https://tools.ietf.org/html/rfc5237

> 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,
>>             <http://www.maxim-ic.com/app-notes/index.mvp/id/1796>.
> 
> This URL does not resolve for me.  Since this reference is normative, this seems like a potential blocker.

Updated. The 1-wire material is, however, getting scarce. I think the reference that I’m using now is sufficient.

> 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”

Ok. I changed the wording.

> 
> 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.

I changed the above comment, and added some words here as well.

There’s a general tradeoff here with generality (pass any URN) vs. specificity and efficiency (e.g., pass 4 byte IP address).

New text:

   A URN-based representation can be passed along in applications that
   need the information.  It fits particularly well for protocols
   mechanisms that are designed to carry URNs [RFC7230], [RFC7540],
   [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
   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.  Passing URNs may
   consume additional bytes compared to, for instance, passing 4-byte
   binary IPv4 addresses, but offers some flexibility in return.


> 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:[e-mail] 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.

See above for the IESG part of it.

I don’t have a strong opinion about which mailing list to advice people turn to. In reality they would google for the appropriate forum or person anyway.

I generalised the text. It now reads:

      Should the working
      group cease to exist, discussion should be directed to the application
      area or general IETF discussion forums, or the IESG.

> 
> 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.

Ok

> 
> 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

:-)

Because that was what the original spec said :-)

But I can remove it.

> 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”

As above. The text was clarified.

> 11) Appendix A does not say whether it is to be removed before publication.  I’m guessing it is intended to be removed.

Added.

> 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/

All updated.

Jari