Discussion:
[core] feedback on draft-ietf-core-dev-urn-01
Peter Saint-Andre
2018-05-02 20:44:08 UTC
Permalink
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

Loading...