Additional Units for Sensor Measurement Lists (SenML)
draft-ietf-core-senml-more-units-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-06-22
|
06 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-06-15
|
06 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-05-04
|
06 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-03-26
|
06 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2020-03-24
|
06 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2020-03-24
|
06 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-03-24
|
06 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-03-24
|
06 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-03-23
|
06 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-03-20
|
06 | (System) | RFC Editor state changed to EDIT |
2020-03-20
|
06 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-03-20
|
06 | (System) | Announcement was received by RFC Editor |
2020-03-19
|
06 | Carsten Bormann | New version available: draft-ietf-core-senml-more-units-06.txt |
2020-03-19
|
06 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2020-03-19
|
06 | Carsten Bormann | Uploaded new revision |
2020-03-19
|
05 | (System) | IANA Action state changed to In Progress |
2020-03-19
|
05 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-03-19
|
05 | Amy Vezza | IESG has approved the document |
2020-03-19
|
05 | Amy Vezza | Closed "Approve" ballot |
2020-03-19
|
05 | Amy Vezza | Ballot approval text was generated |
2020-03-19
|
05 | Alexey Melnikov | IESG state changed to Approved-announcement to be sent from IESG Evaluation::Revised I-D Needed |
2020-03-19
|
05 | Alissa Cooper | [Ballot comment] With everything going on I'm not going to have time to dig into this again before the new IESG is seated, so I've … [Ballot comment] With everything going on I'm not going to have time to dig into this again before the new IESG is seated, so I've changed my ballot position to abstain. I do not think it is sound to publish this as-is with the reliance on a versioning scheme specified in an individual draft that does not have consensus, but I seem to be the only person who thinks that, so I will not stand in the way of publication. |
2020-03-19
|
05 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to Abstain from Discuss |
2020-02-20
|
05 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-02-20
|
05 | Michelle Cotton | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-02-20
|
05 | Valery Smyslov | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Valery Smyslov. Sent review to list. |
2020-02-20
|
05 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Valery Smyslov |
2020-02-20
|
05 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Valery Smyslov |
2020-02-20
|
05 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2020-02-19
|
05 | Alvaro Retana | [Ballot comment] I support Alissa's DISCUSS. |
2020-02-19
|
05 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-02-19
|
05 | Barry Leiba | [Ballot comment] You have a typo in section 4: "obove", where "above" is meant. + + + + + + + + + + + … [Ballot comment] You have a typo in section 4: "obove", where "above" is meant. + + + + + + + + + + + + + + + + + + + + The following are comments from Murray Kucherawy, incoming ART AD. Murray is getting an early start on doing reviews, and I’m including his comments into my ballots during the overlap period before he’s officially an Area Director. - - - - - - - - - - - - - - - - - - - - Section 2: Just out of curiosity, why are some of the newly registered "VA"s all-caps and some all-lowercase? Section 4: I'm a bit uneasy about saying the rules for this new registry are the same as for that older registry, with exceptions. That means if the rules for the old registry change, someone needs to remember to consider whether the rules for the new registry should change in parallel, or whether something else should happen. But if there's precedent for doing that, or the result is unambiguous, then we're probably fine. Also, "six columns" followed by five bullets... I think I'd rather coax the scale/offset line apart. Seems to me that Section 2 and all but the last two paragraphs of Section 4 should be in Section 7. I've never seen an "IANA Considerations" section be a complete indirection like that. But if we allow that, then OK. |
2020-02-19
|
05 | Barry Leiba | Ballot comment text updated for Barry Leiba |
2020-02-19
|
05 | Warren Kumari | [Ballot comment] No objection, but the inability to use '%' makes me sad.... :-( |
2020-02-19
|
05 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2020-02-19
|
05 | Adam Roach | [Ballot comment] Balloting "No Objection" in the sense of "I trust the sponsoring AD, and have no time this ballot cycle to read the document." … [Ballot comment] Balloting "No Objection" in the sense of "I trust the sponsoring AD, and have no time this ballot cycle to read the document." I have skimmed the document for typical ART-area gotchas, and found none. |
2020-02-19
|
05 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2020-02-19
|
05 | Alissa Cooper | [Ballot discuss] I have some questions and comments about the text below, which seems like it creates significant scope for interoperability failures: "Where the benefits … [Ballot discuss] I have some questions and comments about the text below, which seems like it creates significant scope for interoperability failures: "Where the benefits of directly using a secondary unit in a SenML pack outweigh the above considerations, the use of secondary units in "u" fields MAY be enabled by indicating a new SenML version that specifically allows this and/or by using a field with a label name that ends with the "_" character ("must-understand" field) whose definition specifically allows this. The definition of these versions and fields is outside the scope of the present specification; one such definition is proposed in [I-D.bormann-core-senml-versions]." Do I understand correctly that this allows secondary units in (1) SenML packs that use some version number besides 10, and (2) SenML fields named with "_" that are in packs where the version number is 10? What is the motivation for providing two different mechanisms to signal that secondary units are in use? I.e., why isn't one or the other of these mechanisms sufficient? Without defining either a new version that supports secondary units or fields with "_", I don't understand how this update to RFC 8428 is complete enough to be implementable. It says other versions and fields are out of scope, but don't some need to be defined in order for the normative MAY in this text to be actionable? The label names registry policy is Expert Review, which does not require formal documentation of the registry entry. Where is the "definition [that] specifically allows this" expected to occur? Presumably some implementations are already using SenML. What is an implementation supposed to do if it encounters a label name containing "_" that it does not understand in a version 10 pack? It looks like this text went in a week ago but it's a pretty significant change to the extensibility story for SenML, so I'm wondering if the WG had a chance to come to consensus on it? I'm not super familiar with SenML so apologies if the answers to some of these questions are obvious. |
2020-02-19
|
05 | Alissa Cooper | [Ballot comment] 'The unit "degrees" is in wide use in practice for plane angles (as in heading, bearing, etc.). It is marked with an … [Ballot comment] 'The unit "degrees" is in wide use in practice for plane angles (as in heading, bearing, etc.). It is marked with an asterisk because the preferred coherent SI unit is radian ("rad").' Is this asterisk notation meant to be common across all units that have this same property? If so, that seems worth specifying more generally, not just for degrees. |
2020-02-19
|
05 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2020-02-19
|
05 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my Discuss and Comment points! |
2020-02-19
|
05 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2020-02-19
|
05 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-02-19
|
05 | Carsten Bormann | New version available: draft-ietf-core-senml-more-units-05.txt |
2020-02-19
|
05 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2020-02-19
|
05 | Carsten Bormann | Uploaded new revision |
2020-02-19
|
04 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-02-18
|
04 | Suresh Krishnan | [Ballot comment] I could not read the normative references to IEC-80000-6 and 13 as I do not have access . I trust the sponsoring AD … [Ballot comment] I could not read the normative references to IEC-80000-6 and 13 as I do not have access . I trust the sponsoring AD to have gone through them and verified that the item number references are correct. Also the following text in Section 3 seems very handwavy and not particularly helpful. Is this necessary? " It is not presently known to this author how the upcoming revision of IEC 80000-6 will update this, but it has became clear that there is strong interest in using this unit specifically for the imaginary content of complex power, reactive power [IEEE-1459]" |
2020-02-18
|
04 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2020-02-18
|
04 | Benjamin Kaduk | [Ballot discuss] +-----------+-------------------+-------+-----------+-----+---------+ | secondary | description | SenML | scale | off | refer- | | unit … [Ballot discuss] +-----------+-------------------+-------+-----------+-----+---------+ | secondary | description | SenML | scale | off | refer- | | unit | | unit | | set | ence | +-----------+-------------------+-------+-----------+-----+---------+ [...] | km | kilometer | km | 1000 | 0 | RFCthis | The associated SenML unit would be just 'm', not 'km'. |
2020-02-18
|
04 | Benjamin Kaduk | [Ballot comment] I appreciate the compromise position that was achieved after the long last-call discussions questioning the need for this work. It seems like a … [Ballot comment] I appreciate the compromise position that was achieved after the long last-call discussions questioning the need for this work. It seems like a reasonably shaped "escape hatch" to me. Section 2 I assume this is just a product of my personal background, but I am more used to "mass density" than "mass concentration" for dimensionalities such as kg/m3. Section 3 o The Byte. [IEC-80000-13] defines both the bit (item 13-9.b) and the byte (item 13-9.c, also called octet) as alternative names for the coherent unit one for the purpose of giving storage capacity and related quantities. While the name octet is associated with nit: is "one" misplaced, here? Section 4 o scale, offset: two rational numbers, expressed in decimal (optionally, with a decimal exponent given) or as a fraction divided by a "/" character. nit: doesn't "a fraction divided by a '/' character" involve two '/' characters? That is, "1/2" is a fraction, so "1/2 divided by a '/' character" would be like "1/2/" or "1/2/2" or something nonsensical like that. It's a little surprising to see kibibyte and gigabyte defined but not gibibyte. names. Guidelines to the difference between units (which can go into the registry) and quantities are widely available, see for instance [RS] and [BIPM]. I suggest a parenthetical "(which cannot)" after "quantities". Where the benefits of directly using a secondary unit in a SenML pack outweigh the obove considerations, the use of secondary units in "u" nit: s/obove/above/ specifically allows this and/or by using a field with a label name that ends with the "_" character ("must-understand" field) that specifically allows this. The definition of these versions and I suggest "whose definition specifically allows this". fields is outside the scope of the present specification; one such definition is provided in [I-D.bormann-core-senml-versions]. nit: I suggest "proposed definition" or "possible definition", as internet-drafts are "works in progress". Section 5 potential single point of failure. Instead of pulling the registry in each individual instance of the code, the software update mechanism (or a similar, less frequently triggered mechanism) SHOULD be used to disseminate updated units registries obtained from IANA towards the instances via common repositories. I like how this blandly assumes that a software update mechanism is available. Optimistic for the present-day world, but still probably the right thing to say. nit: as written, "less frequently triggered mechanism" means "less frequently triggered than the software update mechanism", which I suspect is not the intent. Section 6 I suggest reiterating the implications of the requirements at the end of section 4, namely, that use of new units is "fail-safe", in that an implementation processing a pack using secondary units is guaranteed to have been developed with an awareness of the risks of having multiple units available for the same logical type. (It is not, of course, guaranteed to know about the specific secondary unit in question when just the "SenML Version" check is used, in the same way that current SenML applications are not guaranteed to know about units not in the initial allocation from RFC 8428.) The security considerations of [RFC8428] apply. The introduction of new measurement units poses no additional security considerations except from a possible potential for additional confusion about the proper unit to use. Nitpicking, but I think there's a related risk of confusion in terms of what quantity has been measured and is indicated in a SenML pack, as alluded to by the previous mention of "trigger[ing] on the presence of a quantity in a certain unit". |
2020-02-18
|
04 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2020-02-18
|
04 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2020-02-18
|
04 | Mirja Kühlewind | |
2020-02-18
|
04 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2020-02-16
|
04 | Éric Vyncke | [Ballot comment] Short, simple, and easy to read while being useful. Just a nit, please use a section on its own for acknowledgments (at least … [Ballot comment] Short, simple, and easy to read while being useful. Just a nit, please use a section on its own for acknowledgments (at least the HTML version does not show it was a section) Thank you for the time writing this doc -éric |
2020-02-16
|
04 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-02-16
|
04 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2020-02-14
|
04 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-02-13
|
04 | Barry Leiba | [Ballot comment] You have a typo in section 4: "obove", where "above" is meant. |
2020-02-13
|
04 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2020-02-13
|
04 | Amy Vezza | Placed on agenda for telechat - 2020-02-20 |
2020-02-13
|
04 | Alexey Melnikov | IESG state changed to IESG Evaluation from Waiting for Writeup |
2020-02-13
|
04 | Alexey Melnikov | Ballot has been issued |
2020-02-13
|
04 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2020-02-13
|
04 | Alexey Melnikov | Created "Approve" ballot |
2020-02-13
|
04 | Alexey Melnikov | Ballot writeup was changed |
2020-02-11
|
04 | Carsten Bormann | New version available: draft-ietf-core-senml-more-units-04.txt |
2020-02-11
|
04 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2020-02-11
|
04 | Carsten Bormann | Uploaded new revision |
2020-02-03
|
03 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2020-01-19
|
03 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Jon Mitchell was marked no-response |
2019-11-04
|
03 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-11-04
|
03 | Carsten Bormann | New version available: draft-ietf-core-senml-more-units-03.txt |
2019-11-04
|
03 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2019-11-04
|
03 | Carsten Bormann | Uploaded new revision |
2019-11-01
|
02 | Sabrina Tanamal | I reviewed the units in Table 1 and they are OK for registration in the SenML units registry. However, "seconds", "degrees", and "kilograms" in the … I reviewed the units in Table 1 and they are OK for registration in the SenML units registry. However, "seconds", "degrees", and "kilograms" in the descriptions should not be in plural but in singular ("second", "degree", "kilogram"). The author acknowledged this was a typo and this will be fixed in the next revision of the draft. |
2019-11-01
|
02 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2019-11-01
|
02 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2019-10-31
|
02 | Linda Dunbar | Request for Last Call review by GENART Completed: Ready. Reviewer: Linda Dunbar. Sent review to list. |
2019-10-30
|
02 | Sabrina Tanamal | IANA Experts State changed to Reviews assigned |
2019-10-30
|
02 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2019-10-30
|
02 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-core-senml-more-units-02. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-core-senml-more-units-02. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete. First, in the SenML Units registry on the Sensor Measurement Lists (SenML) registry page located at: https://www.iana.org/assignments/senml/ four early registrations in the registry will have their references changed to [ RFC-to-be ]: Sym Description Type Reference ---+-------------------------------------+-----+------------- B Byte (information content) float [ RFC-to-be ] VA volt-ampere (Apparent Power) float [ RFC-to-be ] var volt-ampere reactive (Reactive Power) float [ RFC-to-be ] J/m joule per meter (Energy per distance) float [ RFC-to-be ] Second, also in the SenML Units registry on the Sensor Measurement Lists (SenML) registry page located at: https://www.iana.org/assignments/senml/ four new registrations will be added to the registry as follows: Symbol: VAs Description: volt-ampere seconds (Apparent Energy) Type: float Reference: [ RFC-to-be ] Symbol: vars Description: volt-ampere reactive seconds (Reactive Energy) Type: float Reference: [ RFC-to-be ] Symbol: kg/m3 Description: kilograms per cubic meter (mass concentration) Type: float Reference: [ RFC-to-be ] Symbol: deg Description: degrees (angle)* Type: float Reference: [ RFC-to-be ] As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Third, a new registry is to be created called the Secondary Units registry. The new registry will be located on the Sensor Measurement Lists (SenML) registry page located at: https://www.iana.org/assignments/senml/ The new registry will be managed via Expert Review as defined in RFC 8126. There are initial registrations in the new registry as follows: +-----------+-------------------+-------+-----------+-----+-------------+ | secondary | description | SenML | scale | off | Reference | | unit | | unit | | set | | +-----------+-------------------+-------+-----------+-----+-------------+ | ms | millisecond | s | 1/1000 | 0 | [RFC-to-be] | | min | minute | s | 60 | 0 | [RFC-to-be] | | h | hour | s | 3600 | 0 | [RFC-to-be] | | kW | kilowatt | W | 1000 | 0 | [RFC-to-be] | | kVA | kilovolt-ampere | VA | 1000 | 0 | [RFC-to-be] | | kvar | kilovar | var | 1000 | 0 | [RFC-to-be] | | Ah | ampere-hour | C | 3600 | 0 | [RFC-to-be] | | Wh | watt-hour | J | 3600 | 0 | [RFC-to-be] | | kWh | kilowatt-hour | J | 3600000 | 0 | [RFC-to-be] | | varh | var-hour | vars | 3600 | 0 | [RFC-to-be] | | kvarh | kilovar-hour | vars | 3600000 | 0 | [RFC-to-be] | | kVAh | kilovolt-ampere- | VAs | 3600000 | 0 | [RFC-to-be] | | | hour | | | | | | Wh/km | watts-hour per | J/m | 3.6 | 0 | [RFC-to-be] | | | kilometer | | | | | | KiB | kibibyte | B | 1024 | 0 | [RFC-to-be] | | mV | millivolt | V | 1/1000 | 0 | [RFC-to-be] | | mA | milliampere | A | 1/1000 | 0 | [RFC-to-be] | | dBm | decibel | dBW | 1 | -30 | [RFC-to-be] | | | (milliwatt) | | | | | | ug/m3 | micrograms per | kg/m3 | 1e-9 | 0 | [RFC-to-be] | | | cubic meter | | | | | | mm/h | millimeter per | m/s | 1/3600000 | 0 | [RFC-to-be] | | | hour | | | | | | ppm | parts per million | / | 1e-6 | 0 | [RFC-to-be] | | hPa | hectopascal | Pa | 100 | 0 | [RFC-to-be] | | mm | millimeter | m | 1/1000 | 0 | [RFC-to-be] | | km | kilometer | km | 1000 | 0 | [RFC-to-be] | | km/h | kilometer per | m/s | 1/3.6 | 0 | [RFC-to-be] | | | hour | | | | | +-----------+-------------------+-------+-----------+-----+-------------+ The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-10-30
|
02 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-10-22
|
02 | Valery Smyslov | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Valery Smyslov. |
2019-10-18
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Valery Smyslov |
2019-10-18
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Valery Smyslov |
2019-10-18
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jon Mitchell |
2019-10-18
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jon Mitchell |
2019-10-17
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Linda Dunbar |
2019-10-17
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Linda Dunbar |
2019-10-16
|
02 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2019-10-16
|
02 | Amy Vezza | The following Last Call announcement was sent out (ends 2019-10-30): From: The IESG To: IETF-Announce CC: core-chairs@ietf.org, draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez , jaime@iki.fi, … The following Last Call announcement was sent out (ends 2019-10-30): From: The IESG To: IETF-Announce CC: core-chairs@ietf.org, draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez , jaime@iki.fi, core@ietf.org, alexey.melnikov@isode.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Additional Units for SenML) to Proposed Standard The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Additional Units for SenML' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-10-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented. This short document registers a number of additional unit names in the IANA registry for Units in SenML. It also defines a registry for secondary units that cannot be in SenML's main registry as they are derived by linear transformation from units already in that registry; RFC 8428 is updated to also accept these units. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-senml-more-units/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-core-senml-more-units/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-10-16
|
02 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2019-10-16
|
02 | Alexey Melnikov | Last call was requested |
2019-10-16
|
02 | Alexey Melnikov | Last call announcement was generated |
2019-10-16
|
02 | Alexey Melnikov | Ballot approval text was generated |
2019-10-16
|
02 | Alexey Melnikov | Ballot writeup was generated |
2019-10-16
|
02 | Alexey Melnikov | IESG state changed to Last Call Requested from AD Evaluation |
2019-10-16
|
02 | Alexey Melnikov | IESG state changed to AD Evaluation from Publication Requested |
2019-10-15
|
02 | Jaime Jimenez | ## Shepherd Writeup The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented. This short document registers a number … ## Shepherd Writeup The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented. This short document registers a number of additional unit names in the IANA registry for Units in SenML. It also defines a registry for secondary units that cannot be in SenML's main registry as they are derived by linear transformation from units already in that registry. The SenML RFC (RFC8428) is updated to also accept these units. ### Summary Document Shepherd: Jaime Jiménez Area Director: Alexey Melnikov This very short document essentially creates a sub-registry of derived SenML Units, which will be used by other SDOs like OMA. The document is intended for Standards Track and updates RFC8428. ### Review and Consensus Most of the discussions on this document dealt with which units to add and the formatting particularities for them. Part of the discussion was too on the authoritative sources for units, and the role of IANA on that. Ultimately the document has gone through multiple expert reviews and has been discussed on multiple IETF meetings. ### Intellectual Property Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG. ### Other Points The document creates a sub-registry for SenML and updates the SenML RFC (RFC8428). ### Checklist [x] Means cleared. [-] Means done but there are comments that should be checked by IESG. [ ] Means not done. - [x] Does the shepherd stand behind the document and think the document is ready for publication? - [-] Is the correct RFC type indicated in the title page header? The current draft says "Network Working Group" and should be changed to "CoRE Working Group" - [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary? - [x] Is the intent of the document accurately and adequately explained in the introduction? - [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed? - [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests? - [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79? - [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified? - [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state? - [-] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction? This draft updates 8428 and is stated so in the Abstract and the header. Idinits warns on the update but it shouldn't be a problem. IMO the document is very clear in other sections about which are the updates to the current SenML registry. Please check if the current text is sufficiently explicit. https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-core-senml-more-units-02.txt - [x] If this is a "bis" document, have all of the errata been considered? `Does not apply` **IANA** Considerations: - [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions. - [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries? - [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)? - [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries? - [-] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call? The primary Designated Expert for the SenML Units is author of the document, but there is no specific mailing list as with core-parameters. - [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives? - [x] Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified? |
2019-10-15
|
02 | Jaime Jimenez | Responsible AD changed to Alexey Melnikov |
2019-10-15
|
02 | Jaime Jimenez | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2019-10-15
|
02 | Jaime Jimenez | IESG state changed to Publication Requested from I-D Exists |
2019-10-15
|
02 | Jaime Jimenez | IESG process started in state Publication Requested |
2019-10-15
|
02 | Jaime Jimenez | ## Shepherd Writeup The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented. This short document registers a number … ## Shepherd Writeup The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented. This short document registers a number of additional unit names in the IANA registry for Units in SenML. It also defines a registry for secondary units that cannot be in SenML's main registry as they are derived by linear transformation from units already in that registry. The SenML RFC (RFC8428) is updated to also accept these units. ### Summary Document Shepherd: Jaime Jiménez Area Director: Alexey Melnikov This very short document essentially creates a sub-registry of derived SenML Units, which will be used by other SDOs like OMA. The document is intended for Standards Track and updates RFC8428. ### Review and Consensus Most of the discussions on this document dealt with which units to add and the formatting particularities for them. Part of the discussion was too on the authoritative sources for units, and the role of IANA on that. Ultimately the document has gone through multiple expert reviews and has been discussed on multiple IETF meetings. ### Intellectual Property Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG. ### Other Points The document creates a sub-registry for SenML and updates the SenML RFC (RFC8428). ### Checklist [x] Means cleared. [-] Means done but there are comments that should be checked by IESG. [ ] Means not done. - [x] Does the shepherd stand behind the document and think the document is ready for publication? - [-] Is the correct RFC type indicated in the title page header? The current draft says "Network Working Group" and should be changed to "CoRE Working Group" - [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary? - [x] Is the intent of the document accurately and adequately explained in the introduction? - [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed? - [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests? - [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79? - [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified? - [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state? - [-] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction? This draft updates 8428 and is stated so in the Abstract and the header. Idinits warns on the update but it shouldn't be a problem. IMO the document is very clear in other sections about which are the updates to the current SenML registry. Please check if the current text is sufficiently explicit. https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-core-senml-more-units-02.txt - [x] If this is a "bis" document, have all of the errata been considered? `Does not apply` **IANA** Considerations: - [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions. - [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries? - [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)? - [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries? - [-] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call? The primary Designated Expert for the SenML Units is author of the document, but there is no specific mailing list as with core-parameters. - [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives? - [x] Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified? |
2019-10-14
|
02 | Jaime Jimenez | Intended Status changed to Proposed Standard from Internet Standard |
2019-10-14
|
02 | Jaime Jimenez | Changed consensus to Yes from Unknown |
2019-10-14
|
02 | Jaime Jimenez | Intended Status changed to Internet Standard from None |
2019-10-14
|
02 | Jaime Jimenez | Notification list changed to Jaime Jimenez <jaime@iki.fi> |
2019-10-14
|
02 | Jaime Jimenez | Document shepherd changed to Jaime Jimenez |
2019-10-14
|
02 | Jaime Jimenez | ## Shepherd Writeup The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented. This short document registers a number … ## Shepherd Writeup The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented. This short document registers a number of additional unit names in the IANA registry for Units in SenML. It also defines a registry for secondary units that cannot be in SenML's main registry as they are derived by linear transformation from units already in that registry; The SenML RFC (RFC8428) is updated to also accept these units. ### Summary Document Shepherd: Jaime Jiménez Area Director: Alexey Melnikov This very short document essentially creates a sub-registry of derived SenML Units, which will be used by other SDOs like OMA. The document is intended for Standards Track and updates RFC8428. ### Review and Consensus Most of the discussions on this document dealt with which units to add and the formatting particularities for them. Part of the discussion was too on the authoritative sources for units, and the role of IANA on that. Ultimately the document has gone through multiple expert reviews and has been discussed on multiple IETF meetings. ### Intellectual Property Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG. ### Other Points The document creates a sub-registry for SenML and updates the SenML RFC (RFC8428). ### Checklist [x] Means cleared. [-] Means done but there are comments that should be checked by IESG. [ ] Means not done. - [x] Does the shepherd stand behind the document and think the document is ready for publication? - [-] Is the correct RFC type indicated in the title page header? The current draft says "Network Working Group" and should be changed to "CoRE Working Group" - [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary? - [x] Is the intent of the document accurately and adequately explained in the introduction? - [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed? - [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests? - [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79? - [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified? - [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state? - [-] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction? This draft updates 8428 and is stated so in the Abstract and the header. Idinits warns on the update but it shouldn't be a problem. IMO the document is very clear in other sections about which are the updates to the current SenML registry. Please check if the current text is sufficiently explicit. https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-core-senml-more-units-02.txt - [x] If this is a "bis" document, have all of the errata been considered? `Does not apply` **IANA** Considerations: - [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions. - [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries? - [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)? - [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries? - [-] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call? A request has been made to "core-parameters", we are awaiting the response. - [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives? - [x] Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified? |
2019-10-12
|
02 | Carsten Bormann | New version available: draft-ietf-core-senml-more-units-02.txt |
2019-10-12
|
02 | (System) | New version approved |
2019-10-12
|
02 | (System) | Request for posting confirmation emailed to previous authors: Carsten Bormann |
2019-10-12
|
02 | Carsten Bormann | Uploaded new revision |
2019-09-24
|
01 | Carsten Bormann | New version available: draft-ietf-core-senml-more-units-01.txt |
2019-09-24
|
01 | (System) | New version approved |
2019-09-24
|
01 | (System) | Request for posting confirmation emailed to previous authors: Carsten Bormann |
2019-09-24
|
01 | Carsten Bormann | Uploaded new revision |
2019-09-24
|
01 | Carsten Bormann | Uploaded new revision |
2019-09-02
|
00 | Jaime Jimenez | This document now replaces draft-bormann-senml-more-units instead of None |
2019-09-02
|
00 | Carsten Bormann | New version available: draft-ietf-core-senml-more-units-00.txt |
2019-09-02
|
00 | (System) | WG -00 approved |
2019-09-02
|
00 | Carsten Bormann | Set submitter to "Carsten Bormann ", replaces to (none) and sent approval email to group chairs: core-chairs@ietf.org |
2019-09-02
|
00 | Carsten Bormann | Uploaded new revision |