Subject: [core] 🔔 WGLC on draft-ietf-core-coap-senml

From: Jaime Jiménez <[email-masked]>
Date: Wed, 5 Jul 2017 11:23:45 +0000

Dear CoRE WG,

The core-senml draft has gotten to a state that the authors feel is in good shape for WGLC. 
We will do a 2 week WGLC before next IETF. 

https://tools.ietf.org/html/draft-ietf-core-senml-10

Best Regards,
- - Jaime Jiménez

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 5 Jul 2017 15:38:26 +0200

> https://tools.ietf.org/html/draft-ietf-core-senml-10

As an author, let me add:

One question that we also want to decide in this WGLC is whether to keep the link extension in this Proposed-Standard-to-be, or whether it merits its own document.  It is not in the same state of completion as the rest of the document, and it has served a bit of its purpose making sure that the extension mechanism is in place and can be used.  It’s just that the extension itself may not yet be ready for prime time, and it may become better from spending a bit more time in a separate document.
Please send your comments on this question as well as the typical WGLC comments to [email-masked] (or, for purely editorial comments, to [email-masked], but do indicate that you have read the document to [email-masked]).

Grüße, Carsten

---

From: Peter Saint-Andre - Filament <[email-masked]>
Date: Sat, 15 Jul 2017 21:00:37 -0600

On 7/5/17 5:23 AM, Jaime Jiménez wrote:
> _https://tools.ietf.org/html/draft-ietf-core-senml-10_

Please consider the following comments.

Section 1

Where is the urn:dev namespace defined? I don't see it listed in the
registry <https://www.iana.org/assignments/urn-namespaces/>. If it's
being defined in this specification, please refer to RFC 8141 for the
most up-to-date guidelines regarding URN namespace registration. If
you're just using an arbitrary namespace for examples, please use the
urn:example namespace defined in RFC 6963. [See also below.]

Section 2

   The design goal is to be able to send simple sensor measurements in
   small packets on mesh networks from large numbers of constrained
   devices.

It's not clear to me why the network topology (e.g., a "mesh" network)
is relevant here. I suggest removing "on mesh networks".

   Keeping the total size of payload under 80 bytes makes this
   easy to use on a wireless mesh network.

Why was 80 bytes chosen instead of, say, 50 bytes or 64 bytes or 100
bytes? (Here again I'd remove the text about mesh networks.)

Also, the payload size will vary depending on the encoding (JSON, CBOR,
XML, EXI, etc.), and it's not clear which one is being implicitly
referenced here.

Section 4.3

   It is RECOMMENDED that the
   full names are represented as URIs [RFC3986] or URNs [RFC2141].

Well, URNs *are* URIs. Also, RFC 2141 has been replaced by RFC 8141.

   Some of the examples in this draft use the device URN
   type as specified in [I-D.arkko-core-dev-urn].

Aha. But why? That's an expired informational I-D which never actually
registered the urn:dev namespace. I suggesting using urn:example URNs
instead. (If there's a desire to advance draft-arkko-core-dev-urn, then
let's do that - although note that registration is easier now that we've
published RFC 8141, and we wouldn't need to advance the I-D in order to
register the namespace. In any case, having lots of examples of an
unregistered namespace seems like bad form.)

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

Shall we define this in terms of ABNF, perhaps?

Please note that this set is more restricted than the range of
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.

Section 4.4

   In addition the records need to be in chronological order.

If there are multiple records with the same value of "t", does their
order matter?

Section 4.6

Up to this point in the document, SenML has been defined as a format for
representing sensor measurements. Given that a sensor measures something
in the world, what does it mean to *set* the value of a sensor or a
sensor measurement?

   SenML can also be used for configuring parameters and controlling
   actuators.  When a SenML Pack is sent (e.g., using a HTTP/CoAP POST
   or PUT method) and the semantics of the target are such that SenML is
   interpreted as configuration/actuation, SenML Records are interpreted
   as a request to change the values of given (sub)resources (given as
   names) to given values at the given time(s).

This is underspecified.

In particular, how does a sender know that "the semantics of the target
are such that SenML is interpreted as configuration/actuation"? And
aren't configuration and actuation quite different use cases?

At the very least, a forward reference to Section 5.1.7 would be helpful.

Section 9

   To select a single SenML Record, the "rec" scheme followed by a
   single number is used.

It's confusing to use the term "scheme" here - I realize it's the term
used in XPointer, but RFC 3986 uses the term "parameter" instead.

Section 9.1

   The 3rd SenML Record from "coap://example.com/temp" resource can be
   selected with:

   coap://example.com/temp#rec=3

But RFC 7252 says:

   Note: Fragments ([RFC3986], Section 3.5) are not part of the request
   URI and thus will not be transmitted in a CoAP request.

Is there a conflict here?

Section 12.1

   Units marked with an
   asterisk are NOT RECOMMENDED to be produced by new implementations,
   but are in active use and SHOULD be implemented by consumers that can
   use the related base units.

This advice seems unrealistic and likely unnecessary.

Section 12.1

Although one could quibble with some of the choices here (lat and lon
but no alt?), that's what registration procedures are for. :-)

Speaking of which:

   New entries can be added to the registration by either Expert Review
   or IESG Approval as defined in [RFC5226].

Why define two policies? That's just introducing the possibility of
confusion.

Note that RFC 5226 has been replaced by RFC 8126.

Section 12.2

See above on having multiple policies.

Peter

-- 
Peter Saint-Andre
https://filament.com/

---

From: Ari Keränen <[email-masked]>
Date: Sun, 16 Jul 2017 22:16:50 +0000

Thank's Peter! See comments and questions inline.

> On 16 Jul 2017, at 5.00, Peter Saint-Andre - Filament <[email-masked]> wrote:
> 

(addressed below)

> bytes? (Here again I'd remove the text about mesh networks.)

These two points, mesh and 80 bytes, are related. 802.15.4 (6LoWPAN) mesh networks result in about 80 bytes of usable payload per packet without fragmentation.

I did find it useful to have some justification why we care about shaving bytes here (e.g.,, not having excessive amount of metadata inline), but I don't have strong opinion on whether we should keep this text.

> XML, EXI, etc.), and it's not clear which one is being implicitly

This is not about particular encoding but in general justification why size matters. All SenML encodings can go below 80 bytes with moderate amount of Records and short-enough names.

> Well, URNs *are* URIs. Also, RFC 2141 has been replaced by RFC 8141.

Since we specifically use URNs in examples, perhaps the URN reference is still justified. But this text could be changed to "[...] as URIs [RFC3986], such as URNs [RFC8141]".

> unregistered namespace seems like bad form.)

That draft was just recently resurrected (https://tools.ietf.org/html/draft-arkko-core-dev-urn-04), but unfortunately only after we submitted the SenML draft. Good comments for that draft.

> Shall we define this in terms of ABNF, perhaps?

Makes sense.

> AFAICS it will limit the URI schemes or URN namespaces that can be used.

Good point. I'd suggest text: 

"Note that the character set for SenML names is a subset of the 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)."

> If there are multiple records with the same value of "t", does their

Should not matter. Will clarify.

> in the world, what does it mean to *set* the value of a sensor or a

I guess this needs to be elaborated also in the intro (it's hinted in the abstract).

> aren't configuration and actuation quite different use cases?

These semantics need to be established out of band from SenML point of view. Could be something like CoRE interface type or LwM2M resource type that accepts SenML for this purpose. But we don't want to be prescriptive here. Perhaps giving example(s) is good approach?

> At the very least, a forward reference to Section 5.1.7 would be helpful.

Agreed.

> used in XPointer, but RFC 3986 uses the term "parameter" instead.

Parameter works for me.

> Is there a conflict here?

Nope. The "selection" happens in the client, just like with CSV records.

> This advice seems unrealistic and likely unnecessary.

Why unrealistic?

> but no alt?), that's what registration procedures are for. :-)

Actually "alt" could make sense. But yes, it's by design easy to extend this.

> Why define two policies? That's just introducing the possibility of

I think "IESG approval" is usually good to have as a backup if the main policy can not be exercised for some reason. Perhaps not that important with the Expert Review policy though, but I don't see too much harm here. I'd expect IESG to consult expert(s) anyway if they end up being asked about this.

> Note that RFC 5226 has been replaced by RFC 8126.

Thanks!

> See above on having multiple policies.

ACK. And thanks once more for the thorough review!

Cheers,
Ari

---

From: Peter Saint-Andre - Filament <[email-masked]>
Date: Sun, 16 Jul 2017 16:37:22 -0600

On 7/16/17 4:16 PM, Ari Keränen wrote:
>>> The core-senml draft has gotten to a state that the authors feel
>>> is in good shape for WGLC. We will do a 2 week WGLC before next
>>> IETF.
>>> 
>> Where is the urn:dev namespace defined? I don't see it listed in
>> the registry <https://www.iana.org/assignments/urn-namespaces/>. If
>> it's being defined in this specification, please refer to RFC 8141
>> for the most up-to-date guidelines regarding URN namespace
>> registration. If you're just using an arbitrary namespace for
>> examples, please use the urn:example namespace defined in RFC 6963.
>> [See also below.]
> 
> (addressed below)
> 
>> 
>> Section 2
>> 
>> The design goal is to be able to send simple sensor measurements
>> in small packets on mesh networks from large numbers of
>> constrained devices.
>> 
>> It's not clear to me why the network topology (e.g., a "mesh"
>> network) is relevant here. I suggest removing "on mesh networks".
>> 
>> Keeping the total size of payload under 80 bytes makes this easy to
>> use on a wireless mesh network.
>> 
>> Why was 80 bytes chosen instead of, say, 50 bytes or 64 bytes or
>> 100 bytes? (Here again I'd remove the text about mesh networks.)
> 
> These two points, mesh and 80 bytes, are related. 802.15.4 (6LoWPAN)
> mesh networks result in about 80 bytes of usable payload per packet
> without fragmentation.

That makes sense. In which case it would be good to mention this, so
that readers understand the rationale.

> I did find it useful to have some justification why we care about
> shaving bytes here (e.g.,, not having excessive amount of metadata
> inline), but I don't have strong opinion on whether we should keep
> this text.
> 
>> Also, the payload size will vary depending on the encoding (JSON,
>> CBOR, XML, EXI, etc.), and it's not clear which one is being
>> implicitly referenced here.
> 
> This is not about particular encoding but in general justification
> why size matters. All SenML encodings can go below 80 bytes with
> moderate amount of Records and short-enough names.
> 
>> Section 4.3
>> 
>> It is RECOMMENDED that the full names are represented as URIs
>> [RFC3986] or URNs [RFC2141].
>> 
> Since we specifically use URNs in examples, perhaps the URN reference
> is still justified. But this text could be changed to "[...] as URIs
> [RFC3986], such as URNs [RFC8141]".
> 
>> Some of the examples in this draft use the device URN type as
>> specified in [I-D.arkko-core-dev-urn].
>> 
>> Aha. But why? That's an expired informational I-D which never
>> actually registered the urn:dev namespace. I suggesting using
>> urn:example URNs instead. (If there's a desire to advance
>> draft-arkko-core-dev-urn, then let's do that - although note that
>> registration is easier now that we've published RFC 8141, and we
>> wouldn't need to advance the I-D in order to register the
>> namespace. In any case, having lots of examples of an unregistered
>> namespace seems like bad form.)
> 
> That draft was just recently resurrected
> (https://tools.ietf.org/html/draft-arkko-core-dev-urn-04), but
> unfortunately only after we submitted the SenML draft. Good comments
> for that draft.

Thanks for the pointer. I'm one of the expert reviewers for URN
namespace registrations, so I'll provide separate comments about that
I-D soon.

If that I-D will be a normative reference here or we are depending on
registration of the urn:dev namespace before progressing SenML, then the
WG might consider using the urn:example namespace for now.

>> 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".
>> 
>> 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.
> 
> "Note that the character set for SenML names is a subset of the
> 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)."

I suggest that we also say something like "The restrictions imply that
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.

>> If there are multiple records with the same value of "t", does
>> their order matter?
> 
>> Up to this point in the document, SenML has been defined as a
>> format for representing sensor measurements. Given that a sensor
>> measures something in the world, what does it mean to *set* the
>> value of a sensor or a sensor measurement?
> 

That's the barest of hints. :-) I almost provided a comment about it,
but let it go.

>> actuators.  When a SenML Pack is sent (e.g., using a HTTP/CoAP
>> POST or PUT method) and the semantics of the target are such that
>> SenML is interpreted as configuration/actuation, SenML Records are
>> interpreted as a request to change the values of given
>> (sub)resources (given as names) to given values at the given
>> time(s).
>> 
>> This is underspecified.
>> 
>> In particular, how does a sender know that "the semantics of the
>> target are such that SenML is interpreted as
>> configuration/actuation"? And aren't configuration and actuation
>> quite different use cases?
> 
> These semantics need to be established out of band from SenML point
> of view. Could be something like CoRE interface type or LwM2M
> resource type that accepts SenML for this purpose. But we don't want
> to be prescriptive here. Perhaps giving example(s) is good approach?

Examples of such discovery methods would be helpful.

>> It's confusing to use the term "scheme" here - I realize it's the
>> term used in XPointer, but RFC 3986 uses the term "parameter"
>> instead.
> 
> Parameter works for me.
> 
>> Section 9.1
>> 
>> The 3rd SenML Record from "coap://example.com/temp" resource can
>> be selected with:
>> 
>> Note: Fragments ([RFC3986], Section 3.5) are not part of the
>> request URI and thus will not be transmitted in a CoAP request.
>> 

OK.

>> Section 12.1
>> 
>> Units marked with an asterisk are NOT RECOMMENDED to be produced by
>> new implementations, but are in active use and SHOULD be
>> implemented by consumers that can use the related base units.
>> 

Because we're saying "hey you new implementations, don't do this, but
everyone else before you does it". Developers of new implementations
won't want to miss out on this feature (if it's important).

>> Section 12.1
>> 
>> Although one could quibble with some of the choices here (lat and
>> lon but no alt?), that's what registration procedures are for. :-)
> 
>> New entries can be added to the registration by either Expert
>> Review or IESG Approval as defined in [RFC5226].
>> 
>> Why define two policies? That's just introducing the possibility
>> of confusion.
> 
> I think "IESG approval" is usually good to have as a backup if the
> main policy can not be exercised for some reason. Perhaps not that
> important with the Expert Review policy though, but I don't see too
> much harm here. I'd expect IESG to consult expert(s) anyway if they
> end up being asked about this.

Right, so let's simplify it while we have the chance. :-)

> ACK. And thanks once more for the thorough review!

Thanks for considering the feedback.

Peter

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 17 Jul 2017 16:28:49 +0200

Thank for the great review... Ari and I working on it but just to add to this one point. 

> On Jul 17, 2017, at 12:37 AM, Peter Saint-Andre - Filament <[email-masked]> wrote:
> 
>>> 

How about we say keeping it small is good and quote examples of 802.15.4 has about 80 byte payload and  that LoRa has 51 byte of applications payload in long range mode and just remove any reference to "mesh"

---

From: Peter Saint-Andre - Filament <[email-masked]>
Date: Mon, 17 Jul 2017 08:30:55 -0600

On 7/17/17 8:28 AM, Cullen Jennings wrote:
>> On Jul 17, 2017, at 12:37 AM, Peter Saint-Andre - Filament
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>>
> How about we say keeping it small is good and quote examples of 802.15.4
> has about 80 byte payload and  that LoRa has 51 byte of applications
> payload in long range mode and just remove any reference to "mesh"

+1

Peter

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Jul 2017 11:54:38 +0200

> On Jul 16, 2017, at 5:00 AM, Peter Saint-Andre - Filament <[email-masked]> wrote:
> 
> Speaking of which:
> 

There have been times in the past where the Expert was did not respond in a timely fashion. This allows the IESG to quickly take care of a one off event. Of course the IESG can always just replace the Expert with someone new but that tends to be a bit more heavy weight and take longer. 

I don't care if we move this to only Expert Review but slightly prefer both. I would strongly object to making this only IESG Approval as we need to be able to add new things in a light weight and quick way.

---

From: Ari Keränen <[email-masked]>
Date: Wed, 19 Jul 2017 12:45:42 +0000

Hi Peter,

See inline for comments on the remaining issues not discussed in other parts of this thread.

> On 17 Jul 2017, at 0.37, Peter Saint-Andre - Filament <[email-masked]> wrote:
[...]
> WG might consider using the urn:example namespace for now.

It's only informative reference and used only as examples.

But I don't have strong preference either way (except that not changing things is always easier ;).

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

Now: https://github.com/core-wg/senml-spec/issues/73

> That's the barest of hints. :-) I almost provided a comment about it,

Admittedly :) Do you have any proposal how to make it better?

[...]

> won't want to miss out on this feature (if it's important).

You don't really gain anything implementing the "legacy way", so I don't think that's really a problem. 

Cheers,
Ari

---

From: Peter Saint-Andre - Filament <[email-masked]>
Date: Wed, 19 Jul 2017 08:15:53 -0600

On 7/19/17 3:54 AM, Cullen Jennings wrote:
> 
>> On Jul 16, 2017, at 5:00 AM, Peter Saint-Andre - Filament
> There have been times in the past where the Expert was did not respond
> in a timely fashion. 

That's a management problem. Replace or augment the Expert Reviewer team.

> This allows the IESG to quickly take care of a one
> off event. Of course the IESG can always just replace the Expert with
> someone new but that tends to be a bit more heavy weight and take longer. 

That's a proactive management problem. :-)

> I don't care if we move this to only Expert Review but slightly prefer
> both. I would strongly object to making this only IESG Approval as we
> need to be able to add new things in a light weight and quick way. 

I have no deep objections to both, but now we have two code paths when
one might have been enough.

Peter

---

From: Peter Saint-Andre - Filament <[email-masked]>
Date: Wed, 19 Jul 2017 08:31:49 -0600

> It's only informative reference and used only as examples.

We know that sometimes implementers just look at the examples. Copy and
paste - it must be right, it's in an RFC!

> But I don't have strong preference either way (except that not changing things is always easier ;).

My preference would be to progress with the urn:dev namespace because it
seems useful and with the new registration procedure in RFC 8141 we
don't even need an RFC to register the namespace, so registering it
shouldn't hold up the SenML work.

If that's not going to happen in a timely fashion, then using the
urn:example namespace would be better than using an unregistered
namespace (that sets a bad precedent and violates the spirit and letter
of how URNs are defined).

> One should not try to put "full URIs" into the names. Rather the names can be used as part of a URI. 

I'm confused. What I see in the draft right now is that names (whether
"Name" or "Base Name + Name" = concatenated name) are URIs, with URIs
from the URN scheme used as examples. Is that a misunderstanding on my part?

> Perhaps something we should be more clear about.

Yes, clarity would be good.

> Admittedly :) Do you have any proposal how to make it better?

One option is to remove the configuration and actuation use cases. They
seem to be an afterthought. Perhaps define them more carefully in a
separate I-D that re-uses SenML, thus not holding up the core SenML work
any further.

If people really want to support these use cases now and in the core
spec, then I can suggest improvements to the text.

> You don't really gain anything implementing the "legacy way", so I don't think that's really a problem. 

I just don't think this advice is all that actionable or helpful, and it
complicates the registry. But it's not a hill for me to die on. :-)

Peter

---

From: Ari Keränen <[email-masked]>
Date: Thu, 20 Jul 2017 22:36:39 +0000

> On 19 Jul 2017, at 16.31, Peter Saint-Andre - Filament <[email-masked]> wrote:
> 

OK. The urn:dev is now progressing in CoRE so I guess we can do the allocation for that and move forward with it.

> from the URN scheme used as examples. Is that a misunderstanding on my part?

URIs that conform to the restricted character set ("A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", "/", "_"), such as urn:dev, are OK. For example URL with brackets would not be OK (see section 5.1.6 for example with IPv6 address). 

> Yes, clarity would be good.

Will add clarification about the URIs.

> spec, then I can suggest improvements to the text.

There is already use for these so I think we should include the functionality in the base spec.

> complicates the registry. But it's not a hill for me to die on. :-)

OK. If anyone else feels more strongly about this, please let us know :)

Cheers,
Ari

---

From: Peter Saint-Andre - Filament <[email-masked]>
Date: Thu, 20 Jul 2017 17:11:57 -0600

>> On 7/19/17 6:45 AM, Ari Keränen wrote:

<snip/>

> OK. The urn:dev is now progressing in CoRE so I guess we can do the
> allocation for that and move forward with it.

Excellent!

>>>>>> Please note that this set is more restricted than the range
>>>>>> of 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.
>>>>> 
>>>>> "Note that the character set for SenML names is a subset of
>>>>> the 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)."
>>>> 
>>>> I suggest that we also say something like "The restrictions
>>>> imply that 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.
>>> 
>> I'm confused. What I see in the draft right now is that names
>> (whether "Name" or "Base Name + Name" = concatenated name) are
>> URIs, with URIs from the URN scheme used as examples. Is that a
>> misunderstanding on my part?
> 
> URIs that conform to the restricted character set ("A" to "Z", "a" to
> "z", "0" to "9", "-", ":", ".", "/", "_"), such as urn:dev, are OK.
> For example URL with brackets would not be OK (see section 5.1.6 for
> example with IPv6 address).

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., '@', '%', '?', '[', ']', '#',
'~', '+', '=', '&') 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].

> Will add clarification about the URIs.

See above for proposed text.

>>>>>> Up to this point in the document, SenML has been defined as
>>>>>> a format for representing sensor measurements. Given that a
>>>>>> sensor measures something in the world, what does it mean
>>>>>> to *set* the value of a sensor or a sensor measurement?
>>>>> 
>>>> That's the barest of hints. :-) I almost provided a comment
>>>> about it, but let it go.
>>> 
>> One option is to remove the configuration and actuation use cases.
>> They seem to be an afterthought. Perhaps define them more carefully
>> in a separate I-D that re-uses SenML, thus not holding up the core
>> SenML work any further.
>> 
>> If people really want to support these use cases now and in the
>> core spec, then I can suggest improvements to the text.
> 

OK, I will take a closer look at the text and propose some improvements.

Peter