Re: [core] RobW comments on draft-ietf-core-senml-more-units-04

[Carsten Bormann <[e-mail]>]

Hi Rob,

sorry for not processing the comments in order of arrival.

> I’m providing some comments as an incoming Ops and Mgmt AD.
>  
> I found this document well written but think that it may be helpful to highlight the protocol usage of secondary units earlier in the document, i.e. in the introduction.
>  
> My understanding is that this document introduces both extra primary unit names, and also a new concept of secondary unit names, which I presume came about from deployment considerations.
>  
> Comments:
> 	• As per above, I think that it would be useful to add a comment in the introduction about how secondary units could be used.  E.g. may be extend
>  
> “The document also defines a registry for secondary Unit names that
>    cannot be in SenML's main registry as they are derived by linear
>    transformation from units already in that registry.”
>  
> with the sentence “Although SenML version 10 [RFC8428] does not allow for the direct use of secondary units, they are planned to be supported via the use of SenML protocol extensions, such as [I-D.bormann-core-senml-versions].”

Very nice addition.  Slightly edited now in
https://github.com/core-wg/senml-more-units/commit/344430b74f738213a541f087baede716c1afed30
 
> 	• The introduction introduces the term “primary Unit names”, but then doesn’t refer to them using this term in the rest of the document.  It might be helpful if the title of section 2 was changed from “New Units” to “New primary Units”, and the description could be changed from “… assign new units …” to “… assign new primary unit names …”.

I’m with you here except for the instruction to IANA: That’s not agreeing with the name of that registry, and I wasn’t trying to change that.
 
> 	• My reading of the “3. Rationale” section is that it relates to the new primary units, rather than secondary units.  The structure of the document might be clearer if this was made a subsection of the section 2 rather than its own top level section.

I made it a Section 2.1.  (OCD would require making it section 2.2, but then we’d need glue to properly anchor section 2.1.)
 
> 	• I would suggest renaming the section 4 title from “New Registry” to “New Registry for Secondary Units”.

Yes!
 
> 	• Regarding section 4 on secondary units:
> 		• I observe that these are not using a generalized mechanism of using SI prefixes for scaling, but propose a separate custom mapping instead, which in some cases are just making use of SI prefixes.  I presume that there is a good reason for not wanting to generically use SI prefixes, perhaps for a bit more homogeneity in the scaling factors, but it might be helpful for the document to explain the rationale behind this.

Actually, I’d like to push back a bit on this, as SI prefixes are not an obvious way to handle many of the secondary units that are being proposed by other SDOs.

(Defining a scheme for parsing unit names would have been a possibility, but with ambiguities like m (milli) vs. m (meter) this is just too hard to get right.)

> 		• I note that you have similar units but with different scaling factors (e.g. KiB, GB, Mbit/s, MB/s).  Do we anticipate other scaling factors of these units?  E.g. if MB was requested as a secondary unit, then would that be added?  

Yes.  The list that is in this draft is somewhat incidental: It is what is needed to allow LWM2M/IPSO to use the SenML registry.  And they happened not to have MB (which today rarely is useful).

> Would it make sense to define any more of these common scaling factors now?

Yes, we could go for some proactive registration, e.g. where we have one SI range prefix, we could register all reasonable ones.

> 		• I also note that the names of some of the secondary units would overlap with SI prefixes (e.g. “min”) for minutes.  This is okay, but would likely be an annoyance if it was ever desirable to use SI prefixes in a generic way.

Yes, so it is better to have a designated expert look at each registration.

> 		• I wasn’t sure whether “h” is really a great shorthand for hour, I would have gone for “hr” instead, but perhaps this is already widely used elsewhere?

It is the standard one, as in km/h etc.
(See Section 6.5.6 of ISO 80000-1:2009, which apparently is not online.)

The structural/heading changes I took from this are in:
https://github.com/core-wg/senml-more-units/commit/08c3edc91883569cb1f48bc216c3049d77ea962e

We could additionally go ahead with some more proactive registration.
I propose to wait for the telechat with deciding whether we should.

Grüße, Carsten