Subject: [core] feedback on draft-ietf-core-dev-urn-01

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 2 May 2018 14:44:08 -0600

Here is a bit more feedback on the URN namespace for device identifiers:

1. Let's drop the pointer to RFC 3406, which was obsoleted by RFC 8141.

2. The text about not expecting these URNs to be resolved, and about not
using r-components from RFC 8141, seems appropriate.

3. As to q-components (RFC 8141, Section 2.3.2), I don't see a need for
passing parameters to devices identified by DEV URNs, so the text about
not using q-components also seems appropriate. However, I'm curious if
other folks know of scenarios where this functionality might be useful.

4. What about f-components? Consider these examples from the spec:

       urn:dev:ow:264437f5000000ed_humidity    # The laundry sensor's
                                               # humidity part

       urn:dev:ow:264437f5000000ed_temperature # The laundry sensor's
                                               # temperature part

The fact that these are "parts" of a sensor makes me wonder if using
f-components would be better:

       urn:dev:ow:264437f5000000#ed_humidity

       urn:dev:ow:264437f5000000#ed_temperature

5. The organization-defined identifiers (Section 4.3) concern me. I've
seen many unregistered, invalid URN "namespaces" (e.g., "urn:cisco:foo"
while I was at Cisco). This is a bad idea all around, yet I expect that
many people will take the easy way out. Can we strike this section from
the spec and recommend use of the urn:example namespace (BCP 183)?

Peter