Sensor Measurement Lists (SenML) Features and Versions
draft-ietf-core-senml-versions-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-26
|
05 | Gunter Van de Velde | Request closed, assignment withdrawn: Nagendra Nainar Last Call OPSDIR review |
2024-01-26
|
05 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2021-08-13
|
05 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-07-22
|
05 | (System) | RFC Editor state changed to AUTH48 |
2021-07-02
|
05 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-06-30
|
05 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2021-06-30
|
05 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2021-06-30
|
05 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-06-16
|
05 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-06-11
|
05 | (System) | RFC Editor state changed to EDIT |
2021-06-11
|
05 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2021-06-11
|
05 | (System) | Announcement was received by RFC Editor |
2021-06-11
|
05 | (System) | IANA Action state changed to In Progress |
2021-06-11
|
05 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2021-06-11
|
05 | Amy Vezza | IESG has approved the document |
2021-06-11
|
05 | Amy Vezza | Closed "Approve" ballot |
2021-06-11
|
05 | Amy Vezza | Ballot approval text was generated |
2021-06-11
|
05 | Amy Vezza | IESG state changed to Approved-announcement to be sent from Approved-announcement sent |
2021-06-11
|
05 | (System) | Removed all action holders (IESG state changed) |
2021-06-11
|
05 | Francesca Palombini | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup |
2021-06-10
|
05 | Cindy Morgan | Changed action holders to Francesca Palombini (New version posted) |
2021-06-04
|
05 | Carsten Bormann | New version available: draft-ietf-core-senml-versions-05.txt |
2021-06-04
|
05 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2021-06-04
|
05 | Carsten Bormann | Uploaded new revision |
2021-06-04
|
04 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-06-04
|
04 | Carsten Bormann | New version available: draft-ietf-core-senml-versions-04.txt |
2021-06-04
|
04 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2021-06-04
|
04 | Carsten Bormann | Uploaded new revision |
2021-06-03
|
03 | (System) | Changed action holders to Carsten Bormann (IESG state changed) |
2021-06-03
|
03 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2021-06-02
|
03 | Murray Kucherawy | [Ballot comment] I only have a few nits to contribute here. In Section 2: The present specification defines "SenML Features", each identified by … [Ballot comment] I only have a few nits to contribute here. In Section 2: The present specification defines "SenML Features", each identified by a "feature name" (a text string) and a "feature code", an unsigned integer less than 53. Why is the former descriptive clause parenthetical, while the latter is separated by a comma? In Section 2.1, I think all the instances of "less" should actually be "fewer". |
2021-06-02
|
03 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2021-06-02
|
03 | Warren Kumari | [Ballot comment] Thank you for writing this, and in such a clear, understandable (and concise!) manner. I have a nit on the -03 version - … [Ballot comment] Thank you for writing this, and in such a clear, understandable (and concise!) manner. I have a nit on the -03 version - in the "image" we have a misrender: ⋅ 2 |
2021-06-02
|
03 | Warren Kumari | [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari |
2021-06-02
|
03 | Benjamin Kaduk | [Ballot comment] Thanks, this is nicely written and a reasonable approach. Section 3 I think I'm supposed to interpret this as being "the exact bit … [Ballot comment] Thanks, this is nicely written and a reasonable approach. Section 3 I think I'm supposed to interpret this as being "the exact bit pattern 1010 in the last four bits indicates support for the base SenML version defined in RFC 8428; any other bitstring in that position cannot be taken as an indication of support for the base version". In other words, we're still getting a one-bit signal, just encoded in four bits. Is that right? Or maybe just "it's an error to see any other values for those four bits"? (If so, do we reject the entire pack?) Section 5 I'd consider adding a sentence "the assignment of new feature bits is done in a backwards-compatible manner, so existing implementations will not erroneously assume support for a version (feature) that is defined in the future" in the vein of an avoided security consideration. |
2021-06-02
|
03 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2021-06-02
|
03 | Roman Danyliw | [Ballot comment] Thanks to Joe Salowey for the SECDIR review. Nit: -- Section 2.1. Typo. s/sightly/slightly/ -- Section 4. Editorial. s/be be/be/ |
2021-06-02
|
03 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2021-06-02
|
03 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2021-06-02
|
03 | Zaheduzzaman Sarker | [Ballot comment] Thanks for the effort here and thanks to all the reviewers. |
2021-06-02
|
03 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2021-06-02
|
03 | Robert Wilton | [Ballot comment] Hi, Thanks for the this document. Just a couple of minor comments. It looked like the equation in section 2 was mucked up … [Ballot comment] Hi, Thanks for the this document. Just a couple of minor comments. It looked like the equation in section 2 was mucked up in the text version of the doc. Presumably this will get fixed during the editing process: I.e., __ 52 fc version = \ present(fc) ⋅ 2 /__ fc = 0 Quantitatively, the expert could for instance steer the allocation to not allocate more than 10 % of the remaining set per year. Rather than setting this is a limit, I would suggest that it is better to set this as a target. E.g., if it turns out that there is a good justification for an extension, it would be a shame if it had to be delayed by a year merely to fit into a somewhat arbitrary rate limiting scheme. Besides, if you end up with 53 different optional extensions, then I suspect that the bigger problem will be that there are too many variants of what is supported by different implementations which will reduce interop, and you'll probably want to end up with batches of extensions that are expected to be supported together, i.e., some sort of hybrid between completely independent extensions and a strict linear version scheme. Rob |
2021-06-02
|
03 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2021-05-31
|
03 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Please find below one non-blocking COMMENT points (but replies would be appreciated), and some … [Ballot comment] Thank you for the work put into this document. Please find below one non-blocking COMMENT points (but replies would be appreciated), and some nits. Thanks to Jaime Jiménez for his shepherd's write-up (including the WG consensus) even if I regret that no motivation is given about the intended RFC status. Thank you Carsten for acknowledging Jaime's work. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 2.2 -- While the motivation for the update is explained, is there any reason why the usual OLD TEXT / NEW TEXT is not used here? == NITS == -- Section 2 -- Even with the warning in section 1.1, it took me a while to 'see' the Sigma sign (and the were not helping). Suggest to 'show' it in section 1.1. OTOH, congratulations for using the XMLv3 features for the SVG equivalent, quite neat. The whole text of this section is quite convoluted as it is a plain bit mask. |
2021-05-31
|
03 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2021-05-29
|
03 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2021-05-26
|
03 | Martin Duke | [Ballot comment] Given the very constrained space, I wonder if it's wise to reserve 0 and 2 for no real purpose. IIUC these would still … [Ballot comment] Given the very constrained space, I wonder if it's wise to reserve 0 and 2 for no real purpose. IIUC these would still result in version numbers > 10 and therefore not break anything, yes? |
2021-05-26
|
03 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2021-05-26
|
03 | Lars Eggert | [Ballot comment] Section 7.1, paragraph 4, comment: > [IANA.senml] > IANA, "Sensor Measurement Lists (SenML)", > … [Ballot comment] Section 7.1, paragraph 4, comment: > [IANA.senml] > IANA, "Sensor Measurement Lists (SenML)", > . Not sure if a normative reference to an IANA registry page is technically OK; it should probably cite the RFC that created that registry instead, and maybe add an informative reference to the registry page? ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 2.1, paragraph 4, nit: - decimal numbers, e.g. 26 (0b11010, 0x1a) for a version that adds the + decimal numbers, e.g., 26 (0b11010, 0x1a) for a version that adds the + + The text version of this document contains these HTML entities, which might indicate issues with its XML source: Section 1, paragraph 2, nit: > es additional features over time. However in the case of SenML it is expecte > ^^^^^^^ Did you forget a comma after a conjunctive/linking adverb? Section 3, paragraph 2, nit: > secondary unit names [RFC8798] MAY be be used in the "u" field of SenML Reco > ^^^^^ Possible typo: you repeated a word These URLs in the document can probably be converted to HTTPS: * http://www.iana.org/assignments/senml |
2021-05-26
|
03 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2021-05-25
|
03 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-05-25
|
03 | Amy Vezza | Placed on agenda for telechat - 2021-06-03 |
2021-05-25
|
03 | Francesca Palombini | Ballot has been issued |
2021-05-25
|
03 | Francesca Palombini | [Ballot Position Update] New position, Yes, has been recorded for Francesca Palombini |
2021-05-25
|
03 | Francesca Palombini | Created "Approve" ballot |
2021-05-25
|
03 | (System) | Changed action holders to Francesca Palombini (IESG state changed) |
2021-05-25
|
03 | Francesca Palombini | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2021-05-09
|
03 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-05-09
|
03 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-05-09
|
03 | Carsten Bormann | New version available: draft-ietf-core-senml-versions-03.txt |
2021-05-09
|
03 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2021-05-09
|
03 | Carsten Bormann | Uploaded new revision |
2021-05-05
|
02 | Francesca Palombini | Waiting on an update to address Elwyn Davies Gen-ART review: https://mailarchive.ietf.org/arch/msg/core/3RxA4_BivnMN3zVbb8pmZoRKnr4/ |
2021-05-05
|
02 | (System) | Changed action holders to Carsten Bormann, Francesca Palombini (IESG state changed) |
2021-05-05
|
02 | Francesca Palombini | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2021-05-03
|
02 | Elwyn Davies | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Elwyn Davies. Sent review to list. |
2021-05-03
|
02 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2021-05-01
|
02 | Joseph Salowey | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Joseph Salowey. Sent review to list. |
2021-04-28
|
02 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2021-04-28
|
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-versions-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-versions-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 is a single action which we must complete. A new registry is to be created called the SenML Features 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 Specification Required as defined by RFC 8126. There are initial registrations in the new registry as follows: +==============+=================+===============+ | Feature code | Feature name | Specification | +==============+=================+===============+ | 0 | Reserved0 | RFC-to-be | +--------------+-----------------+---------------+ | 1 | Reserved1 | RFC-to-be | +--------------+-----------------+---------------+ | 2 | Reserved2 | RFC-to-be | +--------------+-----------------+---------------+ | 3 | Reserved3 | RFC-to-be | +--------------+-----------------+---------------+ | 4 | Secondary Units | RFC-to-be | +--------------+-----------------+---------------+ | 5-53 | Unassigned | +--------------+-----------------+---------------+ The IANA Functions Operator understands that this is the only action 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 |
2021-04-22
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2021-04-22
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2021-04-22
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
2021-04-22
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
2021-04-22
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Nagendra Nainar |
2021-04-22
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Nagendra Nainar |
2021-04-19
|
02 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2021-04-19
|
02 | Amy Vezza | The following Last Call announcement was sent out (ends 2021-05-03): From: The IESG To: IETF-Announce CC: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-senml-versions@ietf.org, francesca.palombini@ericsson.com, jaime@iki.fi … The following Last Call announcement was sent out (ends 2021-05-03): From: The IESG To: IETF-Announce CC: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-senml-versions@ietf.org, francesca.palombini@ericsson.com, jaime@iki.fi Reply-To: last-call@ietf.org Sender: Subject: Last Call: (SenML Features and Versions) to Proposed Standard The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'SenML Features and Versions' 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 last-call@ietf.org mailing lists by 2021-05-03. 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 This short document updates RFC 8428, Sensor Measurement Lists (SenML), by specifying the use of independently selectable "SenML Features" and mapping them to SenML version numbers. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/ No IPR declarations have been submitted directly on this I-D. |
2021-04-19
|
02 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2021-04-19
|
02 | Amy Vezza | Last call announcement was changed |
2021-04-18
|
02 | Francesca Palombini | Last call was requested |
2021-04-18
|
02 | Francesca Palombini | Last call announcement was generated |
2021-04-18
|
02 | Francesca Palombini | Ballot approval text was generated |
2021-04-18
|
02 | Francesca Palombini | IESG state changed to Last Call Requested from AD Evaluation |
2021-04-05
|
02 | (System) | Changed action holders to Francesca Palombini (IESG state changed) |
2021-04-05
|
02 | Francesca Palombini | IESG state changed to AD Evaluation from Publication Requested |
2021-04-05
|
02 | Francesca Palombini | Ballot writeup was changed |
2021-04-05
|
02 | Jaime Jimenez | ## Shepherd Writeup This short document updates RFC8428 by specifying how to express versions for SenML. A version is a bitmap calculated based on which … ## Shepherd Writeup This short document updates RFC8428 by specifying how to express versions for SenML. A version is a bitmap calculated based on which SenML "features" are active. Feature codes are used to express which features are available. The document registers feature codes 0,1,2,3 for the first 4 reserved features the 5th feature code is reserved for when RFC8798 is used. A new subregistry is created within the SenML IANA registry, named "SenML features". The document sets a hard limit for the number of SenML features that can be registered (with only 48 codes left). Expert reviewers should then be very conservative with the allocation of the remaining feature codes. ### Summary Document Shepherd: Jaime Jiménez Area Director: Francesca Palombini This document specifies how SenML versions are represented and creates a sub-registry of SenML Features, which are used to calculate the SenML version. The document is intended for Standards Track and updates RFC8428. ### Review and Consensus The document was reviewed (https://mailarchive.ietf.org/arch/msg/core/5cWnixOE8nX4HTIy5w3rE4Whpo8/ ) and discussed in several IETF meetings. Most of the comments were regarding the hard limit to feature codes and therefore of version numbers. ### 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 named "SenML features" and updates the SenML RFC (RFC8428). The draft is easy to implement, there is one implementation from Ericsson. ### 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? - [x] Is the correct RFC type indicated in the title page header? - [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? - [-] 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? Idnits shows 13 errors https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-core-senml-versions-02.txt however the tool seems to be broken. - [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. IMO the document is very clear in other sections about which are the updates to the current SenML registry and how they are updated. Please check if the current text is sufficiently explicit. - [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? - [x] 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? - [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? |
2021-04-05
|
02 | Jaime Jimenez | Responsible AD changed to Francesca Palombini |
2021-04-05
|
02 | Jaime Jimenez | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2021-04-05
|
02 | Jaime Jimenez | IESG state changed to Publication Requested from I-D Exists |
2021-04-05
|
02 | Jaime Jimenez | IESG process started in state Publication Requested |
2021-04-05
|
02 | Jaime Jimenez | ## Shepherd Writeup This short document updates RFC8428 by specifying how to express versions for SenML. A version is a bitmap calculated based on which … ## Shepherd Writeup This short document updates RFC8428 by specifying how to express versions for SenML. A version is a bitmap calculated based on which SenML "features" are active. Feature codes are used to express which features are available. The document registers feature codes 0,1,2,3 for the first 4 reserved features the 5th feature code is reserved for when RFC8798 is used. A new subregistry is created within the SenML IANA registry, named "SenML features". The document sets a hard limit for the number of SenML features that can be registered (with only 48 codes left). Expert reviewers should then be very conservative with the allocation of the remaining feature codes. ### Summary Document Shepherd: Jaime Jiménez Area Director: Francesca Palombini This document specifies how SenML versions are represented and creates a sub-registry of SenML Features, which are used to calculate the SenML version. The document is intended for Standards Track and updates RFC8428. ### Review and Consensus The document was reviewed (https://mailarchive.ietf.org/arch/msg/core/5cWnixOE8nX4HTIy5w3rE4Whpo8/ ) and discussed in several IETF meetings. Most of the comments were regarding the hard limit to feature codes and therefore of version numbers. ### 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 named "SenML features" and updates the SenML RFC (RFC8428). The draft is easy to implement, there is one implementation from Ericsson. ### 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? - [x] Is the correct RFC type indicated in the title page header? - [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? - [-] 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? Idnits shows 13 errors https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-core-senml-versions-02.txt however the tool seems to be broken. - [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. IMO the document is very clear in other sections about which are the updates to the current SenML registry and how they are updated. Please check if the current text is sufficiently explicit. - [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? - [x] 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? - [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? |
2021-03-29
|
02 | Jaime Jimenez | Changed consensus to Yes from Unknown |
2021-03-29
|
02 | Jaime Jimenez | Intended Status changed to Proposed Standard from None |
2021-03-29
|
02 | Jaime Jimenez | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2021-03-29
|
02 | Jaime Jimenez | Notification list changed to jaime@iki.fi because the document shepherd was set |
2021-03-29
|
02 | Jaime Jimenez | Document shepherd changed to Jaime Jimenez |
2021-03-12
|
02 | Marco Tiloca | WG Last Call ends on 2021-03-26 |
2021-03-12
|
02 | Marco Tiloca | IETF WG state changed to In WG Last Call from WG Document |
2021-02-27
|
02 | Marco Tiloca | Added to session: IETF-110: core Fri-1300 |
2021-02-21
|
02 | Carsten Bormann | New version available: draft-ietf-core-senml-versions-02.txt |
2021-02-21
|
02 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2021-02-21
|
02 | Carsten Bormann | Uploaded new revision |
2020-11-15
|
01 | Carsten Bormann | New version available: draft-ietf-core-senml-versions-01.txt |
2020-11-15
|
01 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2020-11-15
|
01 | Carsten Bormann | Uploaded new revision |
2020-11-14
|
00 | Marco Tiloca | Added to session: IETF-109: core Fri-1600 |
2020-09-10
|
00 | Marco Tiloca | Changed document external resources from: [] to: github_repo https://github.com/core-wg/senml-versions (Working Group Repo) |
2020-07-25
|
00 | Marco Tiloca | Added to session: IETF-108: core Tue-1410 |
2020-05-13
|
00 | Carsten Bormann | This document now replaces draft-bormann-core-senml-versions instead of None |
2020-05-13
|
00 | Carsten Bormann | New version available: draft-ietf-core-senml-versions-00.txt |
2020-05-13
|
00 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2020-05-13
|
00 | Carsten Bormann | Uploaded new revision |