Discussion:
[core] dev-urn draft update
Jari Arkko
2017-11-03 07:25:28 UTC
Permalink
We updated this draft last month.

Current version: https://tools.ietf.org/html/draft-arkko-core-dev-urn-05 <https://tools.ietf.org/html/draft-arkko-core-dev-urn-05>
Changes: https://tools.ietf.org/rfcdiff?url2=draft-arkko-core-dev-urn-05.txt <https://tools.ietf.org/rfcdiff?url2=draft-arkko-core-dev-urn-05.txt>

And below is a copy of the writeup on what got changed. Discussion
on these changes would be welcome. We’ve changed the ‘;’ syntax
for instance to avoid issues with SenML. And added a way to do
local/organisation specific identifiers. Thoughts?

(And can I ask for the document to be formally posted as draft-ietf-core draft
soon?)
Version -05 made a change to the delimiter for parameters within a
DEV URN. Given discussions on allowed character sets in SenML
[I-D.ietf-core-senml <https://tools.ietf.org/html/draft-arkko-core-dev-urn-05#ref-I-D.ietf-core-senml>], we would like to suggest that the "_"
character be used instead of ";", to avoid the need to translate DEV
URNs in SenML-formatted communications or files. However, this
reverses the earlier decision to not use unreserved characters. This
also means that device IDs cannot use "_" characters, and have to
employ other characters instead. Feedback on this decision is
sought.
Version -05 also introduced local or organisation-specific device
identifiers. Organisations are identified by their PEN number
(although we considered FQDNs as a potential alternative. The
authors belive an organisation-specific device identifier type will
make experiments and local use easier, but feedback on this point and
the choice of PEN numbers vs. other possible organisation identifiers
would be very welcome.
Version -05 also added some discussion of privacy concerns around
long-term stable identifiers.
Finally, version -05 clarified the situations when new allocations
within the registry of possible device identifier subtypes is
appropriate.
Peter Saint-Andre
2017-11-06 22:24:06 UTC
Permalink
Post by Jari Arkko
We updated this draft last month.
Current version: https://tools.ietf.org/html/draft-arkko-core-dev-urn-05
RFC 8141 has obsoleted RFC 2141. As a result, the registration template
and process have changed. Please refer to RFC 8141 for instructions.
This will require modifications to Section 3.

The syntactic structure definition says "The identifier is expressed in
ASCII (UTF-8) characters", but it's not clear why UTF-8 is cited here.
It's all just ASCII, no?

The changes between -04 and -05 look reasonable to me.

Peter
Jari Arkko
2017-11-06 23:06:25 UTC
Permalink
Thanks for your comments, Peter!

RFC 8141 reference was already updated in my private copy (thanks for the PR, Ari).

I see your point Peter about the UTF-8 reference. Have edited my copy again.

Jari
Peter Saint-Andre
2017-11-06 23:09:30 UTC
Permalink
Post by Jari Arkko
Thanks for your comments, Peter!
RFC 8141 reference was already updated in my private copy (thanks for the PR, Ari).
It's not just the reference - the registration template changed, too.

Peter
Jari Arkko
2017-11-14 04:45:03 UTC
Permalink
In today’s meeting I have a brief slot to discuss the DEV URN draft. I’ve previously posted about the changes in -05, and gotten on- and off-list feedback. Thanks!

My slides for today list the following topics for discussion:

• Thoughts on the delimiter change? Breaks any existing usage?

• Thoughts on local device identifiers?

• Adding device IDs specified in OneM2M and LWM2M (urn:dev:os and urn:dev:ops)? And would BBF USP protocol identifiers be useful to add as well?

• Peter: Needs to use the new URN registration template

• Fix a mistake in ABNF (org: vs. dn:)

• Draft adoption? Was briefly discussed last time, but we haven’t actually done it, either as AD sponsored or as WG draft… I think the latter would be the way to go, personally.

Jari
Peter Saint-Andre
2017-11-20 17:09:51 UTC
Permalink
• Draft adoption? Was briefly discussed last time, but we haven’t actually done it, either as AD sponsored or as WG draft
 I think the latter would be the way to go, personally.
Agreed on making it a WG document (not that it's strictly necessary).

Peter

Loading...