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

[Peter Saint-Andre - Filament <[e-mail]>]

On 7/19/17 6:45 AM, Ari Keränen wrote:
> 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 <[e-mail]> wrote:
>> On 7/16/17 4:16 PM, Ari Keränen wrote:
> [...]
>>>> 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.
> 
> 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).

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

> Now: https://github.com/core-wg/senml-spec/issues/73
> 
>>>> 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?
>>>
>>> I guess this needs to be elaborated also in the intro (it's hinted in
>>> the abstract).
>>
>> That's the barest of hints. :-) I almost provided a comment about it,
>> but let it go.
> 
> 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.

> [...]
> 
>>>> 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.
>>>
>>> Why unrealistic?
>>
>> 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).
> 
> 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