Static Context Header Compression over Narrowband Internet of Things
draft-ietf-lpwan-schc-over-nbiot-15
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2023-04-12
|
15 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2023-04-10
|
15 | (System) | RFC Editor state changed to AUTH48 |
2023-02-22
|
15 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2023-01-26
|
15 | Bernie Volz | Closed request for Last Call review by INTDIR with state 'Overtaken by Events' |
2022-12-24
|
15 | Barry Leiba | Request closed, assignment withdrawn: Henry Thompson Last Call ARTART review |
2022-12-24
|
15 | Barry Leiba | Closed request for Last Call review by ARTART with state 'Overtaken by Events': Document has finished IESG processing |
2022-12-22
|
15 | (System) | RFC Editor state changed to EDIT |
2022-12-22
|
15 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2022-12-22
|
15 | (System) | Announcement was received by RFC Editor |
2022-12-22
|
15 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2022-12-22
|
15 | (System) | IANA Action state changed to In Progress |
2022-12-21
|
15 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2022-12-21
|
15 | Amy Vezza | IESG has approved the document |
2022-12-21
|
15 | Amy Vezza | Closed "Approve" ballot |
2022-12-21
|
15 | Amy Vezza | Ballot approval text was generated |
2022-12-21
|
15 | (System) | Removed all action holders (IESG state changed) |
2022-12-21
|
15 | Éric Vyncke | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2022-12-21
|
15 | Lars Eggert | [Ballot comment] # GEN AD review of draft-ietf-lpwan-schc-over-nbiot-12 CC @larseggert ## Comments ### Section 5, paragraph 4 ``` This I-D identifies the use … [Ballot comment] # GEN AD review of draft-ietf-lpwan-schc-over-nbiot-12 CC @larseggert ## Comments ### Section 5, paragraph 4 ``` This I-D identifies the use cases of SCHC over the NB-IoT architecture. ``` I-D -> document ### Section 5.2, paragraph 1 ``` This section consists of IETF suggestions to the 3GPP. ``` See above on not giving suggestions to other SDOs via documents. ### Inclusive language Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term `natively`; alternatives might be `built-in`, `fundamental`, `ingrained`, `intrinsic`, `original` ## Nits 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. ### Duplicate references Duplicate informative references to: `https://www.3gpp.org/ftp/Specs/archive/36_series/36.321/36321-d20.zip`. ### Grammar/style #### Section 3, paragraph 20 ``` istics in terms of bandwidths, acknowledgments, and layer-2 reliability and s ^^^^^^^^^^^^^^^ ``` Do not mix variants of the same word ("acknowledgment" and "acknowledgement") within a single text. (Also elsewhere.) #### Section 5, paragraph 2 ``` radio transmission where, see section Section 5.1, the Dev-UE and the RGW-eN ^^^^^^^^^^^^^^^ ``` Possible typo: you repeated a word. #### Section 5.2, paragraph 4 ``` The same principles as for the section Section 5.1 apply here as well. Becaus ^^^^^^^^^^^^^^^ ``` Possible typo: you repeated a word. #### Section 5.2, paragraph 5 ``` ce compared to the radio link, section Section 5.1, is the physical placing o ^^^^^^^^^^^^^^^ ``` Possible typo: you repeated a word. #### Section 5.2.1, paragraph 2 ``` IPv6 and IPv4 deployment may force to get more rules to deal with each case ^^^^^^ ``` Did you mean "getting"? Or maybe you should add a pronoun? In active voice, "force" + "to" takes an object, usually a pronoun. #### Section 5.3, paragraph 7 ``` if needed, including reliability. Hence the packet size is limited by the M ^^^^^ ``` A comma may be missing after the conjunctive/linking adverb "Hence". #### Section 5.3, paragraph 11 ``` C fragmentation parameters see section Section 5.4.2. 5.4. SCHC over Non-IP ^^^^^^^^^^^^^^^ ``` Possible typo: you repeated a word. #### Section 5.4.1, paragraph 11 ``` gmentation mode is in use, and section Section 5.3 defines the RuleID size. ^^^^^^^^^^^^^^^ ``` Possible typo: you repeated a word. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool |
2022-12-21
|
15 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss |
2022-12-15
|
15 | Ana Minaburo | New version available: draft-ietf-lpwan-schc-over-nbiot-15.txt |
2022-12-15
|
15 | Ana Minaburo | New version approved |
2022-12-15
|
15 | (System) | Request for posting confirmation emailed to previous authors: Ana Minaburo , Edgar Ramos |
2022-12-15
|
15 | Ana Minaburo | Uploaded new revision |
2022-12-13
|
14 | (System) | Changed action holders to Éric Vyncke (IESG state changed) |
2022-12-13
|
14 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-12-13
|
14 | Ana Minaburo | New version available: draft-ietf-lpwan-schc-over-nbiot-14.txt |
2022-12-13
|
14 | Ana Minaburo | New version approved |
2022-12-13
|
14 | (System) | Request for posting confirmation emailed to previous authors: Ana Minaburo , Edgar Ramos |
2022-12-13
|
14 | Ana Minaburo | Uploaded new revision |
2022-12-05
|
13 | Éric Vyncke | As we have received a review from 3GPP CT1, https://mailarchive.ietf.org/arch/msg/lp-wan/T2Dq0vvxR6z4o1Io01lz52uY5gY/, the comments should be taken into account. |
2022-12-05
|
13 | (System) | Changed action holders to Éric Vyncke, Edgar Ramos, Ana Minaburo (IESG state changed) |
2022-12-05
|
13 | Éric Vyncke | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
2022-11-06
|
13 | (System) | Changed action holders to Éric Vyncke (IESG state changed) |
2022-11-06
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-11-06
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2022-11-06
|
13 | Ana Minaburo | New version available: draft-ietf-lpwan-schc-over-nbiot-13.txt |
2022-11-06
|
13 | Ana Minaburo | New version accepted (logged-in submitter: Ana Minaburo) |
2022-11-06
|
13 | Ana Minaburo | Uploaded new revision |
2022-10-27
|
12 | Jean Mahoney | Closed request for Last Call review by GENART with state 'Overtaken by Events': Gen AD has already balloted |
2022-10-27
|
12 | Jean Mahoney | Assignment of request for Last Call review by GENART to Pete Resnick was marked no-response |
2022-10-27
|
12 | (System) | Changed action holders to Éric Vyncke, Edgar Ramos, Ana Minaburo (IESG state changed) |
2022-10-27
|
12 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2022-10-27
|
12 | Zaheduzzaman Sarker | [Ballot comment] Thanks for working on this specification. (This has a good description of 3GPP system and networking) I have looked into transport related issues … [Ballot comment] Thanks for working on this specification. (This has a good description of 3GPP system and networking) I have looked into transport related issues and I haven't any serious or obvious one. Please resolve the TSVART reviewer's comments and it has some good observations. Thanks Spencer Dawkins for his review. I actually kind of agree with other AD's observation regarding why in IETF we are doing it and if this is the correct RFC state. However, I am also wondering if this issues have been discussed in the working group and if there is consensus in the working group to actually process with this publication as standard track. As this document has came this far in the process I assume an affirmative answer and it is worth discussing the working group's view on these points. |
2022-10-27
|
12 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2022-10-26
|
12 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2022-10-26
|
12 | Warren Kumari | [Ballot comment] Firstly, thank you to the authors for writing this -- I found it fascinating. I'd also like to thank Sarah Banks for the … [Ballot comment] Firstly, thank you to the authors for writing this -- I found it fascinating. I'd also like to thank Sarah Banks for the helpful/insightful OpsDir review; there is now a liaison statement related to this topic, and Lars has a (somewhat) related DISCUSS position. It's really nice when the OpsDir process works well. Thanks again to both the authors and Sarah, W |
2022-10-26
|
12 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2022-10-26
|
12 | Lars Eggert | [Ballot discuss] # GEN AD review of draft-ietf-lpwan-schc-over-nbiot-12 CC @larseggert ## Discuss ### Intended status SCHC is an IETF standard. The IETF should not standardize … [Ballot discuss] # GEN AD review of draft-ietf-lpwan-schc-over-nbiot-12 CC @larseggert ## Discuss ### Intended status SCHC is an IETF standard. The IETF should not standardize how another SDO should use SCHC in their architecture, unless that other SDO has specifically asked the IETF to do so. Has 3GPP done so? ### "Abstract", paragraph 1 ``` The 3rd Generation Partnership Project (3GPP) and the Narrowband Internet of Things (NB-IoT) architectures may adopt SCHC to improve their capacities. ``` Would 3GPP be surprised to see this recommendation by the IETF? Has this work item been liaised to and coordinated with 3GPP? Do they expect us to deliver it and do they agree on the content? ### Section 5.1, paragraph 1 ``` This section consists of IETF suggestions to the 3GPP. ``` The IETF isn't typically giving suggestions to other SDOs by publishing documents. We do that through liaison activities. Has this work item be liaised to 3GPP? Do they expect us to complete and publish the work so they can normatively refer to it? |
2022-10-26
|
12 | Lars Eggert | [Ballot comment] ## Comments ### Section 5, paragraph 4 ``` This I-D identifies the use cases of SCHC over the NB-IoT … [Ballot comment] ## Comments ### Section 5, paragraph 4 ``` This I-D identifies the use cases of SCHC over the NB-IoT architecture. ``` I-D -> document ### Section 5.2, paragraph 1 ``` This section consists of IETF suggestions to the 3GPP. ``` See above on not giving suggestions to other SDOs via documents. ### Inclusive language Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term `natively`; alternatives might be `built-in`, `fundamental`, `ingrained`, `intrinsic`, `original` ## Nits 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. ### Duplicate references Duplicate informative references to: `https://www.3gpp.org/ftp/Specs/archive/36_series/36.321/36321-d20.zip`. ### Grammar/style #### Section 3, paragraph 20 ``` istics in terms of bandwidths, acknowledgments, and layer-2 reliability and s ^^^^^^^^^^^^^^^ ``` Do not mix variants of the same word ("acknowledgment" and "acknowledgement") within a single text. (Also elsewhere.) #### Section 5, paragraph 2 ``` radio transmission where, see section Section 5.1, the Dev-UE and the RGW-eN ^^^^^^^^^^^^^^^ ``` Possible typo: you repeated a word. #### Section 5.2, paragraph 4 ``` The same principles as for the section Section 5.1 apply here as well. Becaus ^^^^^^^^^^^^^^^ ``` Possible typo: you repeated a word. #### Section 5.2, paragraph 5 ``` ce compared to the radio link, section Section 5.1, is the physical placing o ^^^^^^^^^^^^^^^ ``` Possible typo: you repeated a word. #### Section 5.2.1, paragraph 2 ``` IPv6 and IPv4 deployment may force to get more rules to deal with each case ^^^^^^ ``` Did you mean "getting"? Or maybe you should add a pronoun? In active voice, "force" + "to" takes an object, usually a pronoun. #### Section 5.3, paragraph 7 ``` if needed, including reliability. Hence the packet size is limited by the M ^^^^^ ``` A comma may be missing after the conjunctive/linking adverb "Hence". #### Section 5.3, paragraph 11 ``` C fragmentation parameters see section Section 5.4.2. 5.4. SCHC over Non-IP ^^^^^^^^^^^^^^^ ``` Possible typo: you repeated a word. #### Section 5.4.1, paragraph 11 ``` gmentation mode is in use, and section Section 5.3 defines the RuleID size. ^^^^^^^^^^^^^^^ ``` Possible typo: you repeated a word. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool |
2022-10-26
|
12 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded for Lars Eggert |
2022-10-25
|
12 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2022-10-25
|
12 | Paul Wouters | [Ballot comment] No comments beyond what has already been pointed out by Rob and Roman. |
2022-10-25
|
12 | Paul Wouters | [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters |
2022-10-24
|
12 | Roman Danyliw | [Ballot comment] Thank you to Barry Lieba for the SECDIR review. Lacking the background on why we are making suggestions to another SDO who didn’t … [Ballot comment] Thank you to Barry Lieba for the SECDIR review. Lacking the background on why we are making suggestions to another SDO who didn’t solicit our feedback, I share Rob Wilton’s curiosity on why this is a proposed standard status document. ** Editorial. This document refers to itself as an “I-D” in a number of places. When published as an RFC, it will not be an I-D anymore. Please replace “I-D” with document or something similar to save future search-and-replace for the RFC Editor. ** Section 5.2.1. Typo. s/section Section 5.1/Section 5.1/. Multiple places. ** Section 5.4.2. Also, the ACK-on-Error mode COULD be desirable to keep track of all the SCHC packets delivered. “COULD” is being used like it is an RFC2119 key word. It is not. Should this an “SHOULD”? |
2022-10-24
|
12 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2022-10-24
|
12 | Martin Duke | [Ballot comment] Please respond to Spencer Dawkins's editorial comments in the TSVART review (and thanks to him for that review). |
2022-10-24
|
12 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2022-10-24
|
12 | Robert Wilton | [Ballot comment] Hi, Thanks for this document. Like, Sarah in her OPSDIR review, I also questioned whether standards track is really the right category for … [Ballot comment] Hi, Thanks for this document. Like, Sarah in her OPSDIR review, I also questioned whether standards track is really the right category for this document rather than informational, particularly because it seems somewhat unclear whether 3GPP will make use of it. But perhaps it needs to be standard track for 3GPP to consider it in the first place? Regards, Rob Also, thank you to Sarah for the OPSDIR review. |
2022-10-24
|
12 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2022-10-19
|
12 | Spencer Dawkins | Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Spencer Dawkins. Sent review to list. |
2022-10-17
|
12 | Erik Kline | [Ballot comment] # Internet AD comments for {draft-ietf-lpwan-schc-over-nbiot-12} CC @ekline Update/2022.10.17: please also see the feedback from the IoT-DIR review. ## Comments ### … [Ballot comment] # Internet AD comments for {draft-ietf-lpwan-schc-over-nbiot-12} CC @ekline Update/2022.10.17: please also see the feedback from the IoT-DIR review. ## Comments ### S5.3 * What exactly is meant here? ... The IPv6 and IPv4 deployment may force to get more rules to deal with each case. Does this just mean that dual-stack deployments require more rules than either IPv6-only or IPv4-only deployments? ### Appendix B * "16000 bytes" Is this 16000 correct? Or should it be 1600? ## Nits ### S5.4.2 * "COULD" is not in the 8174 list of meaningfully capitalized words. Even attempting to interpret as a "MAY" doesn't really apply in this wording. Suggestion: lowercase is fine. ### Appendix A.2 * Perhaps: s/octets aligned/octet-aligned/ ### Appendix A.3 * "HARQ" isn't defined until Appendix B. Consider fully expanding the initialism here. |
2022-10-17
|
12 | Erik Kline | Ballot comment text updated for Erik Kline |
2022-10-17
|
12 | Mališa Vučinić | Request for Last Call review by IOTDIR Completed: Ready with Nits. Reviewer: Mališa Vučinić. Sent review to list. |
2022-10-15
|
12 | Erik Kline | [Ballot comment] # Internet AD comments for {draft-ietf-lpwan-schc-over-nbiot-12} CC @ekline ## Comments ### S5.3 * What exactly is meant here? … [Ballot comment] # Internet AD comments for {draft-ietf-lpwan-schc-over-nbiot-12} CC @ekline ## Comments ### S5.3 * What exactly is meant here? ... The IPv6 and IPv4 deployment may force to get more rules to deal with each case. Does this just mean that dual-stack deployments require more rules than either IPv6-only or IPv4-only deployments? ### Appendix B * "16000 bytes" Is this 16000 correct? Or should it be 1600? ## Nits ### S5.4.2 * "COULD" is not in the 8174 list of meaningfully capitalized words. Even attempting to interpret as a "MAY" doesn't really apply in this wording. Suggestion: lowercase is fine. ### Appendix A.2 * Perhaps: s/octets aligned/octet-aligned/ ### Appendix A.3 * "HARQ" isn't defined until Appendix B. Consider fully expanding the initialism here. |
2022-10-15
|
12 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2022-10-11
|
12 | Johan Stenstam | Request for Telechat review by DNSDIR Completed: Ready with Nits. Reviewer: Johan Stenstam. Sent review to list. |
2022-10-10
|
12 | Jim Reid | Request for Telechat review by DNSDIR is assigned to Johan Stenstam |
2022-10-10
|
12 | Jim Reid | Request for Telechat review by DNSDIR is assigned to Johan Stenstam |
2022-10-08
|
12 | Éric Vyncke | Placed on agenda for telechat - 2022-10-27 |
2022-10-08
|
12 | Éric Vyncke | Ballot has been issued |
2022-10-08
|
12 | Éric Vyncke | [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke |
2022-10-08
|
12 | Éric Vyncke | Created "Approve" ballot |
2022-10-08
|
12 | Éric Vyncke | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2022-10-08
|
12 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2022-10-07
|
12 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2022-10-07
|
12 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-lpwan-schc-over-nbiot-12, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-lpwan-schc-over-nbiot-12, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, Sabrina Tanamal Lead IANA Services Specialist |
2022-10-07
|
12 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Spencer Dawkins |
2022-10-07
|
12 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Spencer Dawkins |
2022-10-07
|
12 | Magnus Westerlund | Assignment of request for Last Call review by TSVART to Bernard Aboba was marked no-response |
2022-10-05
|
12 | Pascal Thubert | # Document Shepherd Writeup for draft-ietf-lpwan-schc-over-nbiot-10 * based on the 8 April 2022 version of the template .* Thank you for your service as a … # Document Shepherd Writeup for draft-ietf-lpwan-schc-over-nbiot-10 * based on the 8 April 2022 version of the template .* Thank you for your service as a document shepherd. Among the responsibilities is answering the questions in this writeup to give helpful context to Last Call and Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in completing it, is appreciated. The full role of the shepherd is further described in [RFC 4858][2], and informally. You will need the cooperation of authors to complete these checks. Note that some numbered items contain multiple related questions; please be sure to answer all of them. ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? There was no opposition but the group involvement was limited beyond a few usual suspects. The good news is that those were deeply involved in the WG products, so we chairs believe that the document is good enough for good RFC. We need a strong signal to 3GPP that we can do IPv6 on the NB-IoT non-IP data channel at little extra cost. This is the only known method to achieve this. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? None 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? No ### Additional Reviews 5. Does this document need review from other IETF working groups or external organizations? Have those reviews occurred? No 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. None. Not that the document does not contain complex algorithms but rather a plain application of SCHC to match the criteria/capabilitioes of NB-IoT. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? N/A 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. N/A ### Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Completely 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. Do any such issues remain that would merit specific attention from subsequent reviews? Fragmentation is discussed, and for the rest, it's all inherited from RFC 8724 11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Proposed Standard, which makes sense for such content which has MUST statements that are necessary for interop. Datatracker state attributes are correct. 12. Has the interested community confirmed that any and all appropriate IPR disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not, explain why. If yes, summarize any discussion and conclusion regarding the intellectual property rights (IPR) disclosures, including links to relevant emails. Yes, and there is no IPR against that document. 13. Has each Author or Contributor confirmed their willingness to be listed as such? If the number of Authors/Editors on the front page is greater than 5, please provide a justification. Yes 14. Identify any remaining I-D nits in this document. (See [the idnits tool][9] and the checkbox items found in Guidelines to Authors of Internet-Drafts). Simply running the idnits tool is not enough; please review the entire guidelines document. All good now 15. Should any informative references be normative or vice-versa? There are a number of 3GPP references. They are not mandatory reading to understand and implement the specification so IO suggested to move them to the informative references section. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? No such, the 3GPP references are downloadable from the provided links. Also, we provided a liaison statement that was passed to 3GPP at https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2022-09-27-lpwan-3gpp-liaison-statement-from-the-ietf-lpwan-wg-to-3gpp-attachment-1.docx 17. Are there any normative downward references (see [RFC 3967][10], [BCP 97][11])? If so, list them. None 18. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If they exist, what is the plan for their completion? None such 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][12]). No IANA consideration 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. N/A [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp78 [8]: https://www.rfc-editor.org/info/bcp79 [9]: https://www.ietf.org/tools/idnits/ [10]: https://www.rfc-editor.org/rfc/rfc3967.html [11]: https://www.rfc-editor.org/info/bcp97 [12]: https://www.rfc-editor.org/rfc/rfc8126.html |
2022-10-04
|
12 | Ines Robles | Request for Last Call review by IOTDIR is assigned to Mališa Vučinić |
2022-10-04
|
12 | Ines Robles | Request for Last Call review by IOTDIR is assigned to Mališa Vučinić |
2022-10-04
|
12 | Ines Robles | Assignment of request for Last Call review by IOTDIR to János Farkas was rejected |
2022-10-04
|
12 | Éric Vyncke | Ballot writeup was changed |
2022-10-03
|
12 | Bernie Volz | Request for Last Call review by INTDIR is assigned to David Lamparter |
2022-10-03
|
12 | Bernie Volz | Request for Last Call review by INTDIR is assigned to David Lamparter |
2022-10-03
|
12 | Ines Robles | Request for Last Call review by IOTDIR is assigned to János Farkas |
2022-10-03
|
12 | Ines Robles | Request for Last Call review by IOTDIR is assigned to János Farkas |
2022-10-03
|
12 | Éric Vyncke | Requested Last Call review by IOTDIR |
2022-10-03
|
12 | Éric Vyncke | Requested Last Call review by INTDIR |
2022-09-29
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2022-09-29
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2022-09-28
|
12 | Sarah Banks | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Sarah Banks. Sent review to list. |
2022-09-28
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Sarah Banks |
2022-09-28
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Sarah Banks |
2022-09-26
|
12 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Bernard Aboba |
2022-09-26
|
12 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Bernard Aboba |
2022-09-25
|
12 | Barry Leiba | Request for Last Call review by ARTART is assigned to Henry Thompson |
2022-09-25
|
12 | Barry Leiba | Request for Last Call review by ARTART is assigned to Henry Thompson |
2022-09-24
|
12 | Barry Leiba | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Barry Leiba. Sent review to list. |
2022-09-23
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Barry Leiba |
2022-09-23
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Barry Leiba |
2022-09-23
|
12 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2022-09-23
|
12 | Amy Vezza | The following Last Call announcement was sent out (ends 2022-10-07): From: The IESG To: IETF-Announce CC: draft-ietf-lpwan-schc-over-nbiot@ietf.org, evyncke@cisco.com, lp-wan@ietf.org, lpwan-chairs@ietf.org, pthubert@cisco.com … The following Last Call announcement was sent out (ends 2022-10-07): From: The IESG To: IETF-Announce CC: draft-ietf-lpwan-schc-over-nbiot@ietf.org, evyncke@cisco.com, lp-wan@ietf.org, lpwan-chairs@ietf.org, pthubert@cisco.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (SCHC over NBIoT) to Proposed Standard The IESG has received a request from the IPv6 over Low Power Wide-Area Networks WG (lpwan) to consider the following document: - 'SCHC over NBIoT' 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 2022-10-07. 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 Static Context Header Compression and Fragmentation (SCHC) specification, RFC8724, describes header compression and fragmentation functionalities for Low Power Wide Area Networks (LPWAN) technologies. The 3rd Generation Partnership Project (3GPP) and the Narrowband Internet of Things (NB-IoT) architectures may adopt SCHC to improve their capacities. This I-D describes the use of SCHC over the NB-IoT architecture and provides the configuration in each case. If 3GPP adopts SCHC, then this I-D recommends some values. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lpwan-schc-over-nbiot/ No IPR declarations have been submitted directly on this I-D. |
2022-09-23
|
12 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2022-09-23
|
12 | Éric Vyncke | Last call was requested |
2022-09-23
|
12 | Éric Vyncke | Ballot approval text was generated |
2022-09-23
|
12 | Éric Vyncke | Ballot writeup was generated |
2022-09-23
|
12 | Éric Vyncke | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2022-09-23
|
12 | Éric Vyncke | Last call announcement was generated |
2022-09-23
|
12 | Éric Vyncke | Last call announcement was generated |
2022-09-22
|
12 | (System) | Changed action holders to Éric Vyncke (IESG state changed) |
2022-09-22
|
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-09-22
|
12 | Ana Minaburo | New version available: draft-ietf-lpwan-schc-over-nbiot-12.txt |
2022-09-22
|
12 | Ana Minaburo | New version accepted (logged-in submitter: Ana Minaburo) |
2022-09-22
|
12 | Ana Minaburo | Uploaded new revision |
2022-09-21
|
11 | Éric Vyncke | Minor fixes to be done, see https://mailarchive.ietf.org/arch/msg/lp-wan/ZXPEhtE8ngs5JioHRUPBL3-hayM/ |
2022-09-21
|
11 | (System) | Changed action holders to Éric Vyncke, Edgar Ramos, Ana Minaburo (IESG state changed) |
2022-09-21
|
11 | Éric Vyncke | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2022-09-20
|
11 | (System) | Changed action holders to Éric Vyncke (IESG state changed) |
2022-09-20
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-09-20
|
11 | Ana Minaburo | New version available: draft-ietf-lpwan-schc-over-nbiot-11.txt |
2022-09-20
|
11 | Ana Minaburo | New version accepted (logged-in submitter: Ana Minaburo) |
2022-09-20
|
11 | Ana Minaburo | Uploaded new revision |
2022-08-29
|
10 | Éric Vyncke | AD review sent https://mailarchive.ietf.org/arch/msg/lp-wan/zLfE5Rm-ndYa_CaxbOAKSUjJ3Sg/ 3GPP relationship should be made clear. |
2022-08-29
|
10 | (System) | Changed action holders to Éric Vyncke, Edgar Ramos, Ana Minaburo (IESG state changed) |
2022-08-29
|
10 | Éric Vyncke | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2022-07-12
|
10 | Pascal Thubert | # Document Shepherd Writeup for draft-ietf-lpwan-schc-over-nbiot-10 * based on the 8 April 2022 version of the template .* Thank you for your service as a … # Document Shepherd Writeup for draft-ietf-lpwan-schc-over-nbiot-10 * based on the 8 April 2022 version of the template .* Thank you for your service as a document shepherd. Among the responsibilities is answering the questions in this writeup to give helpful context to Last Call and Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in completing it, is appreciated. The full role of the shepherd is further described in [RFC 4858][2], and informally. You will need the cooperation of authors to complete these checks. Note that some numbered items contain multiple related questions; please be sure to answer all of them. ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? There was no opposition but the group involvement was limited beyond a few usual suspects. The good news is that those were deeply involved in the WG products, so we chairs believe that the document is good enough for good RFC. We need a strong signal to 3GPP that we can do IPv6 on the NB-IoT non-IP data channel at little extra cost. This is the only known method to achieve this. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? None 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? No ### Additional Reviews 5. Does this document need review from other IETF working groups or external organizations? Have those reviews occurred? No 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. None. Not that the document does not contain complex algorithms but rather a plain application of SCHC to match the criteria/capabilitioes of NB-IoT. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? N/A 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. N/A ### Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Completely 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. Do any such issues remain that would merit specific attention from subsequent reviews? Fragmentation is discussed, and for the rest, it's all inherited from RFC 8724 11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Proposed Standard, which makes sense for such content which has MUST statements that are necessary for interop. Datatracker state attributes are correct. 12. Has the interested community confirmed that any and all appropriate IPR disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not, explain why. If yes, summarize any discussion and conclusion regarding the intellectual property rights (IPR) disclosures, including links to relevant emails. Yes, and there is no IPR against that document. 13. Has each Author or Contributor confirmed their willingness to be listed as such? If the number of Authors/Editors on the front page is greater than 5, please provide a justification. Yes 14. Identify any remaining I-D nits in this document. (See [the idnits tool][9] and the checkbox items found in Guidelines to Authors of Internet-Drafts). Simply running the idnits tool is not enough; please review the entire guidelines document. I signaled the lack of RFC 2119 boilerplate and suggested to move references to informative. Apart from that, no nit. 15. Should any informative references be normative or vice-versa? There are a number of 3GPP references. They are not mandatory reading to understand and implement the specification so IO suggested to move them to the informative references section. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? No such, the 3GPP references are downloadable from the provided links. 17. Are there any normative downward references (see [RFC 3967][10], [BCP 97][11])? If so, list them. None 18. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If they exist, what is the plan for their completion? None such 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][12]). No IANA consideration 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. N/A [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp78 [8]: https://www.rfc-editor.org/info/bcp79 [9]: https://www.ietf.org/tools/idnits/ [10]: https://www.rfc-editor.org/rfc/rfc3967.html [11]: https://www.rfc-editor.org/info/bcp97 [12]: https://www.rfc-editor.org/rfc/rfc8126.html |
2022-07-11
|
10 | Éric Vyncke | Doc shepherd write-up should be updated to justify the intended status. Expect AD review before IETF-114. -éric |
2022-07-11
|
10 | Éric Vyncke | IESG state changed to AD Evaluation from Publication Requested |
2022-07-11
|
10 | Pascal Thubert | # Document Shepherd Writeup for draft-ietf-lpwan-schc-over-nbiot-10 * based on the 8 April 2022 version of the template .* Thank you for your service as a … # Document Shepherd Writeup for draft-ietf-lpwan-schc-over-nbiot-10 * based on the 8 April 2022 version of the template .* Thank you for your service as a document shepherd. Among the responsibilities is answering the questions in this writeup to give helpful context to Last Call and Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in completing it, is appreciated. The full role of the shepherd is further described in [RFC 4858][2], and informally. You will need the cooperation of authors to complete these checks. Note that some numbered items contain multiple related questions; please be sure to answer all of them. ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? There was no opposition but the group involvement was limited beyond a few usual suspects. The good news is that those were deeply involved in the WG products, so we chairs believe that the document is good enough for good RFC. We need a strong signal to 3GPP that we can do IPv6 on the NB-IoT non-IP data channel at little extra cost. This is the only known method to achieve this. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? None 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? No ### Additional Reviews 5. Does this document need review from other IETF working groups or external organizations? Have those reviews occurred? No 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. None. Not that the document does not contain complex algorithms but rather a plain application of SCHC to match the criteria/capabilitioes of NB-IoT. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? N/A 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. N/A ### Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Completely 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. Do any such issues remain that would merit specific attention from subsequent reviews? Fragmentation is discussed, and for the rest, it's all inherited from RFC 8724 11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Proposed Standard; the datatracker is correct on that. 12. Has the interested community confirmed that any and all appropriate IPR disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not, explain why. If yes, summarize any discussion and conclusion regarding the intellectual property rights (IPR) disclosures, including links to relevant emails. Yes, and there is no IPR against that document. 13. Has each Author or Contributor confirmed their willingness to be listed as such? If the number of Authors/Editors on the front page is greater than 5, please provide a justification. Yes 14. Identify any remaining I-D nits in this document. (See [the idnits tool][9] and the checkbox items found in Guidelines to Authors of Internet-Drafts). Simply running the idnits tool is not enough; please review the entire guidelines document. I signaled the lack of RFC 2119 boilerplate and suggested to move references to informative. Apart from that, no nit. 15. Should any informative references be normative or vice-versa? There are a number of 3GPP references. They are not mandatory reading to understand and implement the specification so IO suggested to move them to the informative references section. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? No such, the 3GPP references are downloadable from the provided links. 17. Are there any normative downward references (see [RFC 3967][10], [BCP 97][11])? If so, list them. None 18. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If they exist, what is the plan for their completion? None such 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][12]). No IANA consideration 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. N/A [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp78 [8]: https://www.rfc-editor.org/info/bcp79 [9]: https://www.ietf.org/tools/idnits/ [10]: https://www.rfc-editor.org/rfc/rfc3967.html [11]: https://www.rfc-editor.org/info/bcp97 [12]: https://www.rfc-editor.org/rfc/rfc8126.html |
2022-07-11
|
10 | Pascal Thubert | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2022-07-11
|
10 | Pascal Thubert | IESG state changed to Publication Requested from I-D Exists |
2022-07-11
|
10 | (System) | Changed action holders to Éric Vyncke (IESG state changed) |
2022-07-11
|
10 | Pascal Thubert | IESG process started in state Publication Requested |
2022-07-11
|
10 | Pascal Thubert | # Document Shepherd Writeup for draft-ietf-lpwan-schc-over-nbiot-10 * based on the 8 April 2022 version of the template .* Thank you for your service as a … # Document Shepherd Writeup for draft-ietf-lpwan-schc-over-nbiot-10 * based on the 8 April 2022 version of the template .* Thank you for your service as a document shepherd. Among the responsibilities is answering the questions in this writeup to give helpful context to Last Call and Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in completing it, is appreciated. The full role of the shepherd is further described in [RFC 4858][2], and informally. You will need the cooperation of authors to complete these checks. Note that some numbered items contain multiple related questions; please be sure to answer all of them. ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? There was no opposition but the group involvement was limited beyond a few usual suspects. The good news is that those were deeply involved in the WG products, so we chairs believe that the document is good enough for good RFC. We need a strong signal to 3GPP that we can do IPv6 on the NB-IoT non-IP data channel at little extra cost. This is the only known method to achieve this. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? None 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? No ### Additional Reviews 5. Does this document need review from other IETF working groups or external organizations? Have those reviews occurred? No 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. None. Not that the document does not contain complex algorithms but rather a plain application of SCHC to match the criteria/capabilitioes of NB-IoT. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? N/A 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. N/A ### Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Completely 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. Do any such issues remain that would merit specific attention from subsequent reviews? Fragmentation is discussed, and for the rest, it's all inherited from RFC 8724 11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Proposed Standard; the datatracker is correct on that. 12. Has the interested community confirmed that any and all appropriate IPR disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not, explain why. If yes, summarize any discussion and conclusion regarding the intellectual property rights (IPR) disclosures, including links to relevant emails. Yes, and there is no IPR against that document. 13. Has each Author or Contributor confirmed their willingness to be listed as such? If the number of Authors/Editors on the front page is greater than 5, please provide a justification. Yes 14. Identify any remaining I-D nits in this document. (See [the idnits tool][9] and the checkbox items found in Guidelines to Authors of Internet-Drafts). Simply running the idnits tool is not enough; please review the entire guidelines document. I signaled the lack of RFC 2119 boilerplate and suggested to move references to informative. Apart from that, no nit. 15. Should any informative references be normative or vice-versa? There are a number of 3GPP references. They are not mandatory reading to understand and implement the specification so IO suggested to move them to the informative references section. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? No such, the 3GPP references are downloadable from the provided links. 17. Are there any normative downward references (see [RFC 3967][10], [BCP 97][11])? If so, list them. None 18. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If they exist, what is the plan for their completion? None such 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][12]). No IANA consideration 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. N/A [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp78 [8]: https://www.rfc-editor.org/info/bcp79 [9]: https://www.ietf.org/tools/idnits/ [10]: https://www.rfc-editor.org/rfc/rfc3967.html [11]: https://www.rfc-editor.org/info/bcp97 [12]: https://www.rfc-editor.org/rfc/rfc8126.html |
2022-07-11
|
10 | Ana Minaburo | New version available: draft-ietf-lpwan-schc-over-nbiot-10.txt |
2022-07-11
|
10 | (System) | New version approved |
2022-07-11
|
10 | (System) | Request for posting confirmation emailed to previous authors: Ana Minaburo , Edgar Ramos |
2022-07-11
|
10 | Ana Minaburo | Uploaded new revision |
2022-06-30
|
09 | Pascal Thubert | # Document Shepherd Writeup *This version is dated 8 April 2022.* Thank you for your service as a document shepherd. Among the responsibilities is answering … # Document Shepherd Writeup *This version is dated 8 April 2022.* Thank you for your service as a document shepherd. Among the responsibilities is answering the questions in this writeup to give helpful context to Last Call and Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in completing it, is appreciated. The full role of the shepherd is further described in [RFC 4858][2], and informally. You will need the cooperation of authors to complete these checks. Note that some numbered items contain multiple related questions; please be sure to answer all of them. ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? There was no opposition but the group involvement was limited beyond a few usual suspects. The good news is that those were deeply involved in the WG products, so we chairs believe that the document is good enough for good RFC. We need a strong signal to 3GPP that we can do IPv6 on the NB-IoT non-IP data channel at little extra cost. This is the only known method to achieve this. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? None 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? No ### Additional Reviews 5. Does this document need review from other IETF working groups or external organizations? Have those reviews occurred? No 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. None. Not that the document does not contain complex algorithms but rather a plain application of SCHC to match the criteria/capabilitioes of NB-IoT. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? N/A 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. N/A ### Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Completely 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. Do any such issues remain that would merit specific attention from subsequent reviews? Fragmentation is discussed, and for the rest, it's all inherited from RFC 8724 11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Proposed Standard; the datatracker is correct on that. 12. Has the interested community confirmed that any and all appropriate IPR disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not, explain why. If yes, summarize any discussion and conclusion regarding the intellectual property rights (IPR) disclosures, including links to relevant emails. Yes, and there is no IPR against that document. 13. Has each Author or Contributor confirmed their willingness to be listed as such? If the number of Authors/Editors on the front page is greater than 5, please provide a justification. Yes 14. Identify any remaining I-D nits in this document. (See [the idnits tool][9] and the checkbox items found in Guidelines to Authors of Internet-Drafts). Simply running the idnits tool is not enough; please review the entire guidelines document. I signaled the lack of RFC 2119 boilerplate and suggested to move references to informative. Apart from that, no nit. 15. Should any informative references be normative or vice-versa? There are a number of 3GPP references. They are not mandatory reading to understand and implement the specification so IO suggested to move them to the informative references section. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? No such, the 3GPP references are downloadable from the provided links. 17. Are there any normative downward references (see [RFC 3967][10], [BCP 97][11])? If so, list them. None 18. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If they exist, what is the plan for their completion? None such 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][12]). No IANA consideration 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. N/A [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp78 [8]: https://www.rfc-editor.org/info/bcp79 [9]: https://www.ietf.org/tools/idnits/ [10]: https://www.rfc-editor.org/rfc/rfc3967.html [11]: https://www.rfc-editor.org/info/bcp97 [12]: https://www.rfc-editor.org/rfc/rfc8126.html |
2022-06-28
|
09 | Ana Minaburo | New version available: draft-ietf-lpwan-schc-over-nbiot-09.txt |
2022-06-28
|
09 | Ana Minaburo | New version accepted (logged-in submitter: Ana Minaburo) |
2022-06-28
|
09 | Ana Minaburo | Uploaded new revision |
2022-05-19
|
08 | Ana Minaburo | New version available: draft-ietf-lpwan-schc-over-nbiot-08.txt |
2022-05-19
|
08 | Ana Minaburo | New version accepted (logged-in submitter: Ana Minaburo) |
2022-05-19
|
08 | Ana Minaburo | Uploaded new revision |
2022-05-03
|
07 | Pascal Thubert | IETF WG state changed to In WG Last Call from WG Document |
2022-05-03
|
07 | Pascal Thubert | Notification list changed to pthubert@cisco.com because the document shepherd was set |
2022-05-03
|
07 | Pascal Thubert | Document shepherd changed to Pascal Thubert |
2022-05-03
|
07 | Pascal Thubert | Changed consensus to Yes from Unknown |
2022-05-03
|
07 | Pascal Thubert | Intended Status changed to Proposed Standard from None |
2022-02-22
|
07 | Ana Minaburo | New version available: draft-ietf-lpwan-schc-over-nbiot-07.txt |
2022-02-22
|
07 | (System) | New version approved |
2022-02-22
|
07 | (System) | Request for posting confirmation emailed to previous authors: Ana Minaburo , Edgar Ramos |
2022-02-22
|
07 | Ana Minaburo | Uploaded new revision |
2021-10-25
|
06 | Ana Minaburo | New version available: draft-ietf-lpwan-schc-over-nbiot-06.txt |
2021-10-25
|
06 | (System) | New version approved |
2021-10-25
|
06 | (System) | Request for posting confirmation emailed to previous authors: Ana Minaburo , Edgar Ramos |
2021-10-25
|
06 | Ana Minaburo | Uploaded new revision |
2021-07-25
|
05 | Ana Minaburo | New version available: draft-ietf-lpwan-schc-over-nbiot-05.txt |
2021-07-25
|
05 | (System) | New version approved |
2021-07-25
|
05 | (System) | Request for posting confirmation emailed to previous authors: Ana Minaburo , Edgar Ramos |
2021-07-25
|
05 | Ana Minaburo | Uploaded new revision |
2021-01-19
|
04 | Ana Minaburo | New version available: draft-ietf-lpwan-schc-over-nbiot-04.txt |
2021-01-19
|
04 | (System) | New version approved |
2021-01-19
|
04 | (System) | Request for posting confirmation emailed to previous authors: Ana Minaburo , Edgar Ramos |
2021-01-19
|
04 | Ana Minaburo | Uploaded new revision |
2021-01-14
|
03 | (System) | Document has expired |
2020-07-13
|
03 | Edgar Ramos | New version available: draft-ietf-lpwan-schc-over-nbiot-03.txt |
2020-07-13
|
03 | (System) | New version approved |
2020-07-13
|
03 | (System) | Request for posting confirmation emailed to previous authors: Edgar Ramos , Ana Minaburo |
2020-07-13
|
03 | Edgar Ramos | Uploaded new revision |
2020-05-22
|
02 | Éric Vyncke | Shepherding AD changed to Éric Vyncke |
2020-05-17
|
02 | Ana Minaburo | New version available: draft-ietf-lpwan-schc-over-nbiot-02.txt |
2020-05-17
|
02 | (System) | New version approved |
2020-05-17
|
02 | (System) | Request for posting confirmation emailed to previous authors: Edgar Ramos , Ana Minaburo |
2020-05-17
|
02 | Ana Minaburo | Uploaded new revision |
2019-11-16
|
01 | Ana Minaburo | New version available: draft-ietf-lpwan-schc-over-nbiot-01.txt |
2019-11-16
|
01 | (System) | New version approved |
2019-11-16
|
01 | (System) | Request for posting confirmation emailed to previous authors: Ana Minaburo , Edgar Ramos |
2019-11-16
|
01 | Ana Minaburo | Uploaded new revision |
2019-05-06
|
00 | Pascal Thubert | This document now replaces draft-minaburo-lpwan-nbiot-hc instead of None |
2019-05-06
|
00 | Ana Minaburo | New version available: draft-ietf-lpwan-schc-over-nbiot-00.txt |
2019-05-06
|
00 | (System) | WG -00 approved |
2019-05-04
|
00 | Ana Minaburo | Set submitter to "Ana Minaburo ", replaces to draft-minaburo-lpwan-nbiot-hc and sent approval email to group chairs: lpwan-chairs@ietf.org |
2019-05-04
|
00 | Ana Minaburo | Uploaded new revision |