Change:
mandatory to understand fields.  New version numbers can only be defined in an RFC that updates this specification or it successors. <del> The Name value is concatenated to the Base Name value to get the name of the sensor.  The resulting name needs to uniquely identify and differentiate the sensor from all others.  It is RECOMMENDED that the full names are represented as URIs RFC3986 or URNs RFC2141.  One way to create a unique name is to include some bit string that has guaranteed uniqueness (such as a 1-wire address) that is assigned to the device.  Some of the examples in this draft use the device URN type as specified in I-D.arkko-core-dev-urn.  UUIDs RFC4122 are another way to generate a unique name.  See sec-privacy for privacy considerations that apply to the use of long-term stable unique identifiers. The resulting concatenated name MUST consist only of characters out of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", "/", or "_" and it MUST start with a character out of the set "A" to "Z", "a" to "z", or "0" to "9".  This restricted character set was chosen so that these names can be directly used in other types of URI including segments of an HTTP path with no special encoding and can be directly used in many databases and analytic systems.  RFC5952 contains advice on encoding an IPv6 address in a name. </del> <ins> The Name value is concatenated to the Base Name value to yield the name of the sensor.  The resulting concatenated name needs to uniquely identify and differentiate the sensor from all others.  The concatenated name MUST consist only of characters out of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", "/", and "_"; furthermore, it MUST start with a character out of the set "A" to "Z", "a" to "z", or "0" to "9".  This restricted character set was chosen so that concatenated names can be used directly within various URI schemes (including segments of an HTTP path with no special encoding) and can be used directly in many databases and analytic systems.  RFC5952 contains advice on encoding an IPv6 address in a name.  See sec-privacy for privacy considerations that apply to the use of long-term stable unique identifiers. Although it is RECOMMENDED that concatenated names are represented as URIs RFC3986 or URNs RFC2141, the restricted character set specified above puts strict limits on the URI schemes and URN namespaces that can be used.  As a result, implementers need to take care in choosing the naming scheme for concatenated names, because such names both need to be unique and need to conform to the restricted character set.  One approach is to include a bit string that has guaranteed uniqueness (such as a 1-wire address).  Some of the examples within this document use the device URN namespace as specified in I-D.arkko- core-dev-urn.  UUIDs RFC4122 are another way to generate a unique name.  However, the restricted character set does not allow the use of many URI schemes in names as such.  The use of URIs with characters incompatible with this set, and possible mapping rules between the two, are outside of the scope of the present document. </ins> If the Record has no Unit, the Base Unit is used as the Unit.  Having no Unit and no Base Unit is allowed.

Discussion:
This PR should be merged only after PR
That looks good. Please note that RFC 2141 has been obsoleted by RFC 8141.
NAME Indeed, we fixed the RFC 2141 reference in -11. If you can have a look at URL and send some comments to the mailing list, that would be highly appreciated; we'd like to push this to the IESG now.
From Peter's review: characters allowed for URIs in general (RFC 3986) or URNs in particular (RFC 8141). At the least it would be helpful to point this out, because AFAICS it will limit the URI schemes or URN namespaces that can be used. characters allowed in URIs. The restricted set was chosen to enable efficient and safe use of names in various systems (e.g., as database keys)." care needs to be taken in the choice of URIs or URNs as SenML names." Furthermore, if someone wants to use a URI scheme that allows characters outside that set (e.g., the 'tag' scheme), then do those characters need to be encoded somehow? (Ick.) If not, then we should say so. One should not try to put "full URIs" into the names. Rather the names can be used as part of a URI. Perhaps something we should be more clear about.
Also ABNF of the set
Clarify that dev:urn URIs are OK because they match the charset
so I think we have dealt with this and can close it.
Peter's proposal for updated text is here: URL The PR applies the new text with slight modifications.
LGTM On 7/20/17 4:36 PM, Ari Keränen wrote: Excellent! So I'll repeat my concern: How do we handle such URLs? Are they forbidden? If they are not forbidden, do characters like brackets get escaped somehow? (I hope we don't go down that road.) If they are forbidden, then most URI schemes and URN namespaces won't be usable. For example, URIs schemes such as 'tag' (RFC 4151) and 'ni' (RFC 6920) don't conform to the restricted character set, and there are characters allowed in URN syntax (e.g., 'NAME '%', '?

', '[', ']', '#', '~', '+', '=', '&') that don't conform either. Thus it might even be misleading to say that names are URIs because so few URI schemes or URN namespaces can be employed here. We might need to say something like this... OLD The Name value is concatenated to the Base Name value to get the name of the sensor. The resulting name needs to uniquely identify and differentiate the sensor from all others. It is RECOMMENDED that the full names are represented as URIs [RFC3986] or URNs [RFC2141]. One way to create a unique name is to include some bit string that has guaranteed uniqueness (such as a 1-wire address) that is assigned to the device. Some of the examples in this draft use the device URN type as specified in [I-D.arkko-core-dev-urn]. UUIDs [RFC4122] are another way to generate a unique name. Note that long-term stable unique identifiers are problematic for privacy reasons and should be used with care or avoided as described in [RFC7721]. The resulting concatenated name MUST consist only of characters out of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", "/", or "" and it MUST start with a character out of the set "A" to "Z", "a" to "z", or "0" to "9". This restricted character set was chosen so that these names can be directly used as in other types of URI including segments of an HTTP path with no special encoding and can be directly used in many databases and analytic systems. [RFC5952] contains advice on encoding an IPv6 address in a name. NEW The Name value is concatenated to the Base Name value to yield the name of the sensor. The resulting concatenated name needs to uniquely identify and differentiate the sensor from all others. The concatenated name MUST consist only of characters out of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", "/", and ""; furthermore, it MUST start with a character out of the set "A" to "Z", "a" to "z", or "0" to "9".

This restricted character set was chosen so that concatenated names can be used directly within various URI schemes (including segments of an HTTP path with no special encoding) and can be used directly in many databases and analytic systems. [RFC5952] contains advice on encoding an IPv6 address in a name. Although it is RECOMMENDED that concatenated names are represented as URIs [RFC3986] or URNs [RFC8141], the restricted character set specified above puts strict limits on the URI schemes and URN namespaces that can be used. As a result, implementers need to take care in choosing the naming scheme for concatenated names, because such names both need to be unique and need to conform to the restricted character set. One approach is to include a bit string that has guaranteed uniqueness (such as a 1-wire address). Another, shown in some of the examples within this document, is to use the device URN namespace as specified in [I-D.arkko-core-dev-urn]. A third approach is to use UUIDs [RFC4122]. Unfortunately, the restricted character set does not allow the use of some URI schemes that might otherwise be attractive, such as the 'tag' scheme [RFC4151] and the 'ni' scheme [RFC6920]. Note also that long-term, stable, unique identifiers are problematic for privacy reasons and should be used with care or avoided entirely as described in [RFC7721]. See above for proposed text. OK, I will take a closer look at the text and propose some improvements. Peter