Applicability and Use Cases for IPv6 over Networks of Resource-constrained Nodes (6lo)
draft-ietf-6lo-use-cases-16
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-26
|
16 | Gunter Van de Velde | Request closed, assignment withdrawn: Nagendra Nainar Telechat OPSDIR review |
2024-01-26
|
16 | Gunter Van de Velde | Closed request for Telechat review by OPSDIR with state 'Team Will not Review Version': Cleaning up stale OPSDIR queue |
2023-09-06
|
16 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2023-08-08
|
16 | (System) | RFC Editor state changed to AUTH48 |
2023-05-19
|
16 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2023-04-10
|
16 | (System) | RFC Editor state changed to EDIT |
2023-04-10
|
16 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2023-04-10
|
16 | (System) | Announcement was received by RFC Editor |
2023-04-10
|
16 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2023-04-10
|
16 | (System) | IANA Action state changed to In Progress |
2023-04-10
|
16 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2023-04-10
|
16 | Amy Vezza | IESG has approved the document |
2023-04-10
|
16 | Amy Vezza | Closed "Approve" ballot |
2023-04-10
|
16 | Amy Vezza | Ballot approval text was generated |
2023-04-08
|
16 | (System) | Removed all action holders (IESG state changed) |
2023-04-08
|
16 | Erik Kline | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2023-04-05
|
16 | Roman Danyliw | [Ballot comment] Thank you to Robert Sparks for the SECDIR review. Thank you for addressing my DISCUSS and COMMENT feedback. |
2023-04-05
|
16 | Roman Danyliw | Ballot comment text updated for Roman Danyliw |
2023-04-05
|
16 | Yong-Geun Hong | New version available: draft-ietf-6lo-use-cases-16.txt |
2023-04-05
|
16 | Yong-Geun Hong | New version accepted (logged-in submitter: Yong-Geun Hong) |
2023-04-05
|
16 | Yong-Geun Hong | Uploaded new revision |
2023-03-15
|
15 | Roman Danyliw | [Ballot comment] Thank you to Robert Sparks for the SECDIR review. Thanks for addressing my DISCUSS and my substantive COMMENTs. == ** Section 2.7 … [Ballot comment] Thank you to Robert Sparks for the SECDIR review. Thanks for addressing my DISCUSS and my substantive COMMENTs. == ** Section 2.7 The following table shows the dominant parameters of each use case corresponding to the 6lo link layer technology. Is NFC “dominantly” only used in “health-care services”? Is there a basis for that assertion. |
2023-03-15
|
15 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2023-03-13
|
15 | (System) | Changed action holders to Erik Kline (IESG state changed) |
2023-03-13
|
15 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-03-13
|
15 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2023-03-13
|
15 | Yong-Geun Hong | New version available: draft-ietf-6lo-use-cases-15.txt |
2023-03-13
|
15 | (System) | New version approved |
2023-03-13
|
15 | (System) | Request for posting confirmation emailed to previous authors: Abdur Sangi , Carles Gomez , Samita Chakrabarti , Yong-Geun Hong , Younghwan Choi |
2023-03-13
|
15 | Yong-Geun Hong | Uploaded new revision |
2022-12-15
|
14 | (System) | Changed action holders to Samita Chakrabarti, Yong-Geun Hong, Carles Gomez, Erik Kline, Younghwan Choi, Abdur Sangi (IESG state changed) |
2022-12-15
|
14 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2022-12-15
|
14 | Zaheduzzaman Sarker | [Ballot comment] Thanks for working on this document. This was a good read for me. #Comments - The comparison table in section 2.7 seems … [Ballot comment] Thanks for working on this document. This was a good read for me. #Comments - The comparison table in section 2.7 seems nice one, however, as there is no description given on how to interpret the Low or Moderate, frequent or infrequent. It kind of fails to provided the intended comparison. Like the scale is not YES and NO which cloud be easily interpreted, but No, Low, Moderate, High and perhaps Yes. If there is such scale already available in RFC or other documents would be nice to provide references. - There are terms used like 4G, LTE in this document, I don't think those need to be that much of generation specific and could easily be replaces by "cellular" unless we see an need to mention a particular cellular access generation for some specific reasons. - |
2022-12-15
|
14 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2022-12-15
|
14 | Murray Kucherawy | [Ballot comment] The GENART review was particularly well done. Please give it its due attention. I concur with Alvaro on all of his points. I … [Ballot comment] The GENART review was particularly well done. Please give it its due attention. I concur with Alvaro on all of his points. I feel like at a bare minimum, RFC 8200 should be a normative reference here. Please expand "OFDM" on first use and/or provide a reference. I see Eric found a bunch of others; the authors might want to review all of your acronyms for proper resolution at or before first use. |
2022-12-15
|
14 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2022-12-14
|
14 | Paul Wouters | [Ballot comment] Like Roman, I am a bit concerned about the security aspects. As this is a use cases document, I've limited my issues to … [Ballot comment] Like Roman, I am a bit concerned about the security aspects. As this is a use cases document, I've limited my issues to comments. But it would have to be satisfied in any further specification RFCs. Security and Encryption: Though 6LoWPAN basic specifications do not address security at the network layer, the assumption is that L2 security must be present. While I do understand that some L2 security is possible, eg via pairing, there is still a gap for some technologies - eg NFC where I wouldn't know which payment terminal I really connect to. End-to-end communication is expected to be secured by means of common mechanisms, such as IPsec, TLS/DTLS or object security [RFC8613]. EDHOC (draft-ietf-lake-edhoc) could also be a good match Note that while the common mechanism is a good start, it only presents the use of a technology. Those technologies have requirements that might not be usable in the context of 6lo (eg when there is no internet connection to verify X.509 certificates (OCSP or CRLs) or DNS identifiers). |
2022-12-14
|
14 | Paul Wouters | [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters |
2022-12-14
|
14 | Alvaro Retana | [Ballot comment] (1) This datatracker page should indicate that this document replaces draft-hong-6lo-use-cases. (2) No references are included for BLE, DECT-ULE, NFC, and PLC. (3) … [Ballot comment] (1) This datatracker page should indicate that this document replaces draft-hong-6lo-use-cases. (2) No references are included for BLE, DECT-ULE, NFC, and PLC. (3) There are several references to specific IETF WGs. This is not a good practice because the WGs may change, be re-chartered, or even cease to exist. (4) No references are listed as Normative. I find this hard to believe, given the characterization described here [1]. Please review the references and move the ones that "must be read to understand...the technology" to be Normative. [1] https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ |
2022-12-14
|
14 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2022-12-13
|
14 | Roman Danyliw | [Ballot discuss] Section 3 Security and Encryption: Though 6LoWPAN basic specifications do not address security at the network layer, the assumption is … [Ballot discuss] Section 3 Security and Encryption: Though 6LoWPAN basic specifications do not address security at the network layer, the assumption is that L2 security must be present. In addition, application-level security is highly desirable. The working groups [IETF_ace] and [IETF_core] should be consulted for application and transport level security. The 6lo working group has worked on address authentication [RFC8928] and secure bootstrapping is also being discussed in the IETF. However, there may be other security mechanisms available in a deployment through other standards such as hardware-level security or certificates for the initial booting process. Encryption is important if the implementation can afford it. With the exception of authentication and secure bootstrapping, this text is vague on what security properties are to be considered. Likewise, saying “encryption” is not informative as it can help provide specific (but unnamed) security properties. What is intended is not clear. Specifically: -- What is the “L2 security” that “must be present” specifically? What properties are being addressed (e.g., confidentiality? Authenticity?) -- What is “application-level security” that is “desirable”? -- “Affordability” on what dimension per the supporting encryption? Is that a notional budget for the application, power/battery, etc? |
2022-12-13
|
14 | Roman Danyliw | [Ballot comment] Thank you to Robert Sparks for the SECDIR review. ** Section 1. Running IPv6 on constrained node networks presents challenges, due to … [Ballot comment] Thank you to Robert Sparks for the SECDIR review. ** Section 1. Running IPv6 on constrained node networks presents challenges, due to the characteristics of these networks such as small packet size, low power, low bandwidth, low cost, Why is “lost cost” a challenge to running IPv6 on a constrained network? It seems like a desirable property. ** Section 2. Editorial. Inconsistent descriptions of the protocols: -- Data rate: not mentioned in Section 2.2. -- Range: not mentioned in Sections 2.1, 2.2, 2.3, 2.5 ** Section 2.2. Editorial. Could references to Bluetooth 4.0, 4.1, and IPSP please be provided. ** Section 2.3. Editorial. Please provide a reference to DECT-ULE. ** Section 2.5. NFC technology enables simple and safe two-way interactions between electronic devices Are the other protocols in Section 2.* not “simple” or “safe”? ** Section 2.7 The following table shows the dominant parameters of each use case corresponding to the 6lo link layer technology. Is NFC “dominantly” only used in “health-care services”? Is there a basis for that assertion. ** Section 3. ... L2-address-derived IPv6 addresses are specified in [RFC4944], but there exist implications for privacy. Explicitly state those privacy implications. ** Section 4.2. Section 4.* is titled “deployment scenarios”. Section 4.1, 4.3, and 4.4 explicitly state where they are deployed. This section described Thread, but omits describing the envisioned deployment. ** Section 4.2. Editorial. The term “future-proof designs” seems like marketing. ** Section 4.* and 5.*. Editorial. I don’t understand the difference between a “deployment scenario” and a “6lo use case”. ** Section 5.1. Security support is required, especially for safety- related communication. What is a “security support”? Is “security” not desirable in the other use cases such as Section 5.2 - 5.4 |
2022-12-13
|
14 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2022-12-12
|
14 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from No Record |
2022-12-12
|
14 | Lars Eggert | [Ballot comment] # GEN AD review of draft-ietf-6lo-use-cases-14 CC @larseggert Thanks to Peter E. Yee for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/6HVrWkU6KnjgzrFF5ITZGBqsDBA … [Ballot comment] # GEN AD review of draft-ietf-6lo-use-cases-14 CC @larseggert Thanks to Peter E. Yee for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/6HVrWkU6KnjgzrFF5ITZGBqsDBA). ## Comments ### Section 9, paragraph 8 ``` [IEEE802154] IEEE standard for Information Technology, "IEEE Standard for Low-Rate Wireless Networks". ``` No URL or other metadata? ### 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 `master`; alternatives might be `active`, `central`, `initiator`, `leader`, `main`, `orchestrator`, `parent`, `primary`, `server` * Term `slave`; alternatives might be `follower`, `peripheral`, `replica`, `responder`, `secondary`, `standby`, `worker` * Term `traditional`; alternatives might be `classic`, `classical`, `common`, `conventional`, `customary`, `fixed`, `habitual`, `historic`, `long-established`, `popular`, `prescribed`, `regular`, `rooted`, `time-honored`, `universal`, `widely used`, `widespread` * Term `native`; alternatives might be `built-in`, `fundamental`, `ingrained`, `intrinsic`, `original` * Term `blinds`; alternatives might be `visually impaired`, `unmindful of`, `unconcerned about`, `negligent of`, `unaware`, `uncomprehending`, `unaware`, `uncritical`, `unthinking`, `hasty`, `blocked`, `opaque` ## 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. ### Outdated references Document references `draft-ietf-6lo-nfc-18`, but `-19` is the latest available revision. ### URLs These URLs in the document did not return content: * https://standards.ieee.org/findstds/standard/1901.2-2013.html * http://www.g3-plc.com/home/ * http://groups.homeplug.org/tech/Netricity These URLs in the document can probably be converted to HTTPS: * http://www.techstreet.com/ashrae/standards/ashrae-135-2016?product_id=1918140#jumps * http://www.wi-sun.org ### Grammar/style #### Section 5.2, paragraph 3 ``` w-cost, multi-drop field bus to inter connect the most numerous elements (sen ^^^^^^^^^^^^^ ``` This word is normally spelled as one. #### Section 5.3, paragraph 1 ``` infrastructure, and thus it falls outside of the constrained node network sco ^^^^^^^^^^ ``` This phrase is redundant. Consider using "outside". #### Section 5.6, paragraph 2 ``` ove. Note that NFC is often considered to offer intrinsic security propertie ^^^^^^^^^^^^^^^^^^^ ``` The verb "considered" is used with the gerund form. #### Section 7, paragraph 2 ``` ommunication Union, "Short range narrow-band digital radiocommunication trans ^^^^^^^^^^^ ``` This word is normally spelled as one. ## 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-12
|
14 | Lars Eggert | Ballot comment text updated for Lars Eggert |
2022-12-11
|
14 | Éric Vyncke | [Ballot comment] # Éric Vyncke, INT AD, comments for draft-ietf-6lo-use-cases-14 CC @evyncke Thank you for the work put into this document. Please find below some … [Ballot comment] # Éric Vyncke, INT AD, comments for draft-ietf-6lo-use-cases-14 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points, and some nits. Special thanks to Shwetha Bhandari for the shepherd's detailed write-up including the WG consensus *but* the justification of the intended status is missing. Other thanks to Carlos Bernardos, the Internet directorate reviewer (at my request), please consider this int-dir review: https://datatracker.ietf.org/doc/review-ietf-6lo-use-cases-14-intdir-telechat-bernardos-2022-11-17/ and I have seen Yong-Geun's reply. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### Abstract The mix of acronyms (e.g., "MS/TP") and standards (e.g., IEEE or ITU) or expanded names (e.g., "Bluetooth Low Energy") in the abstract is a little weird. Suggest to expand the acronyms. ### Section 2.5 `safe two-way interactions` what is meant by "safe" in this context ? Should "secure" be used ? Also puzzling is "two-way" as it is not mentioned in other sub-sections. What makes NFC unique here ? Is it more because it is only a 2 party link ? ### Section 2.6 `This standard addresses the requirements with high data rates such as Internet, HDTV, audio, gaming.` s/Internet/Internet access/ ? What does "OFDM" mean ? ### Section 2.7 "BLE" was not expanded before The "Usage" row is very specific and not explained, e.g., I wonder whether NFC is only used in health care. ### Section 3 Should there be a reference about "multicast being harmful" ? Please expand/explain "ESC". ### Section 4 Should the section title better reflects the actual content ? E.g., "6LowPAN Usages" The difference between sections 4 and 5 is also unclear, or is the latter an explanation of section 2.7 ? If so, the flow looks weird (suggest to move section 2.7 inn section 5). ### Section 4.1 This section has a marketing twist that is unusual in IETF drafts. ### Section 4.3 Should there be a mention of the work done in the SNAC WG ? ## NITS ### Section 2.6 "AMI' acronym is defined at least 3 times in the document. Suggest to expand it only once ### Section 5.6 A lot of acronyms are defined and either never used or used only once. Please consider not defining those acronyms and use the full text. ## 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. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments |
2022-12-11
|
14 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2022-12-03
|
14 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Nagendra Nainar |
2022-12-03
|
14 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Nagendra Nainar |
2022-12-03
|
14 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2022-11-22
|
14 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2022-11-17
|
14 | Carlos Jesús Bernardos | Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Carlos Bernardos. Sent review to list. |
2022-11-17
|
14 | Robert Sparks | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Robert Sparks. Sent review to list. |
2022-11-05
|
14 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Robert Sparks |
2022-11-05
|
14 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Robert Sparks |
2022-11-04
|
14 | Carlos Jesús Bernardos | Request for Telechat review by INTDIR is assigned to Carlos Bernardos |
2022-11-04
|
14 | Carlos Jesús Bernardos | Request for Telechat review by INTDIR is assigned to Carlos Bernardos |
2022-11-04
|
14 | Éric Vyncke | Requested Telechat review by INTDIR |
2022-11-04
|
14 | Cindy Morgan | Placed on agenda for telechat - 2022-12-15 |
2022-11-04
|
14 | Erik Kline | Ballot has been issued |
2022-11-04
|
14 | Erik Kline | [Ballot Position Update] New position, Yes, has been recorded for Erik Kline |
2022-11-04
|
14 | Erik Kline | Created "Approve" ballot |
2022-11-04
|
14 | Erik Kline | IESG state changed to IESG Evaluation from Waiting for Writeup |
2022-11-04
|
14 | Erik Kline | Ballot writeup was changed |
2022-10-24
|
14 | Yong-Geun Hong | New version available: draft-ietf-6lo-use-cases-14.txt |
2022-10-24
|
14 | (System) | New version approved |
2022-10-24
|
14 | (System) | Request for posting confirmation emailed to previous authors: 6lo-chairs@ietf.org, Abdur Sangi , Carles Gomez , Samita Chakrabarti , Yong-Geun Hong |
2022-10-24
|
14 | Yong-Geun Hong | Uploaded new revision |
2022-07-11
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2022-07-11
|
13 | Yong-Geun Hong | New version available: draft-ietf-6lo-use-cases-13.txt |
2022-07-11
|
13 | (System) | New version approved |
2022-07-11
|
13 | (System) | Request for posting confirmation emailed to previous authors: 6lo-chairs@ietf.org, Abdur Sangi , Carles Gomez , Samita Chakrabarti , Yong-Geun Hong , Younghwan Choi |
2022-07-11
|
13 | Yong-Geun Hong | Uploaded new revision |
2022-04-06
|
12 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2022-04-05
|
12 | Peter Yee | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Peter Yee. Sent review to list. |
2022-04-05
|
12 | Robert Sparks | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Robert Sparks. Review has been revised by Robert Sparks. |
2022-04-05
|
12 | Robert Sparks | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Robert Sparks. Sent review to list. |
2022-03-28
|
12 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2022-03-28
|
12 | (System) | (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-6lo-use-cases-12, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-6lo-use-cases-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. Thank you, Michelle Thangtamsatid IANA Services Specialist |
2022-03-25
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
2022-03-25
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
2022-03-24
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Robert Sparks |
2022-03-24
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Robert Sparks |
2022-03-24
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Fred Baker |
2022-03-24
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Fred Baker |
2022-03-23
|
12 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2022-03-23
|
12 | Cindy Morgan | The following Last Call announcement was sent out (ends 2022-04-06): From: The IESG To: IETF-Announce CC: 6lo-chairs@ietf.org, 6lo@ietf.org, draft-ietf-6lo-use-cases@ietf.org, ek.ietf@gmail.com, shwetha.bhandari@gmail.com … The following Last Call announcement was sent out (ends 2022-04-06): From: The IESG To: IETF-Announce CC: 6lo-chairs@ietf.org, 6lo@ietf.org, draft-ietf-6lo-use-cases@ietf.org, ek.ietf@gmail.com, shwetha.bhandari@gmail.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (IPv6 over Constrained Node Networks (6lo) Applicability & Use cases) to Informational RFC The IESG has received a request from the IPv6 over Networks of Resource-constrained Nodes WG (6lo) to consider the following document: - 'IPv6 over Constrained Node Networks (6lo) Applicability & Use cases' as Informational RFC 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-04-06. 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 document describes the applicability of IPv6 over constrained node networks (6lo) and provides practical deployment examples. In addition to IEEE Std 802.15.4, various link layer technologies such as ITU-T G.9959 (Z-Wave), Bluetooth Low Energy, DECT-ULE, MS/TP, NFC, and PLC are used as examples. The document targets an audience who would like to understand and evaluate running end-to-end IPv6 over the constrained node networks for local or Internet connectivity. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-6lo-use-cases/ No IPR declarations have been submitted directly on this I-D. |
2022-03-23
|
12 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2022-03-23
|
12 | Cindy Morgan | Last call announcement was generated |
2022-03-22
|
12 | Erik Kline | Changed consensus to Yes from Unknown |
2022-03-22
|
12 | Erik Kline | Last call was requested |
2022-03-22
|
12 | Erik Kline | Last call announcement was generated |
2022-03-22
|
12 | Erik Kline | Ballot approval text was generated |
2022-03-22
|
12 | Erik Kline | Ballot writeup was generated |
2022-03-22
|
12 | Erik Kline | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2022-03-22
|
12 | Erik Kline | # Internet AD comments for draft-ietf-6lo-use-cases-12 CC @ekline This is an attempt to provide review using [this syntaxt]( https://github.com/mnot/ietf-comments/blob/main/format.md), but likely has formatting issues. … # Internet AD comments for draft-ietf-6lo-use-cases-12 CC @ekline This is an attempt to provide review using [this syntaxt]( https://github.com/mnot/ietf-comments/blob/main/format.md), but likely has formatting issues. Below are some comments to consider, but none of them are strong enough to warrant waiting any further for moving to IETF LC. Please consider them, but with no special urgency relative to, say, other LC comments. Thanks! ## Comments ### blemesh? Should blemesh get a mention in here? Perhaps it's not relevant; I don't know. ### S3, Addressing Model privacy recommendations In addition to the reference to RFC 8065, consider whether any of RFCs 7217, 7721, 8064, and 8981 are applicable or worth mentioning. ### S4.3, "massive deployments" Making a claim like "has got massive deployments" invites the reader to ask "where is the citation for this?" If there is a citation to add here, that might be helpful. ### S5.5, /senior citizen/patient (in general)/? I wonder if "senior citizen" is important, or if the same statements are all equally compelling for any patient. ### S5.5, don't tempt the security dragons I'm no security expert, but a strong statement like "cannot gather the personal data" might require an equally strong reference. Maybe just "cannot as easily gather"? |
2022-03-22
|
12 | Erik Kline | IESG state changed to AD Evaluation::AD Followup from AD Evaluation |
2022-02-09
|
12 | Erik Kline | IESG state changed to AD Evaluation from Publication Requested |
2022-02-09
|
12 | (System) | Changed action holders to Erik Kline (IESG state changed) |
2022-02-09
|
12 | Erik Kline | Responsible AD changed to Erik Kline |
2022-02-09
|
12 | Erik Kline | Intended Status changed to Informational |
2022-02-09
|
12 | Erik Kline | IESG process started in state Publication Requested |
2022-02-09
|
12 | Erik Kline | Working group state set to Submitted to IESG for Publication |
2022-02-09
|
12 | Erik Kline | Mailarchive search link: https://mailarchive.ietf.org/arch/browse/6lo/?q=draft-ietf-6lo-use-cases |
2022-02-09
|
12 | Erik Kline | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2022-01-28
|
12 | Shwetha Bhandari | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes the applicability of IPv6 over constrained node networks (6lo) and provides practical deployment examples. In addition to IEEE Std 802.15.4, various link layer technologies such as ITU-T G.9959 (Z-Wave), Bluetooth Low Energy, DECT-ULE, MS/TP, NFC, and PLC are used as examples. The document targets an audience who would like to understand and evaluate running end-to-end IPv6 over the constrained node networks for local or Internet connectivity. Working Group Summary: The discussion and evolution of the document has been smooth with workgroup consensus. It is worth noting that the draft was adopted in 2016 and has evolved to include 6lo use cases over this period of time. Document Quality: This is an Informational draft describing use cases and examples of 6lo deployments. It described various IETF and IEEE developed standards in the examples. The following work group participants have done reviews and provided feedback to help shape the document: Thomas Watteyne, Pascal Thubert, Xavier Vilajosana, Daniel Migault, Jianqiang Hou, Kerry Lynn, S.V.R. Anand, Seyed Mahdi Darroudi and Tero kivinen have provided valuable feedback for this draft. Personnel: Who is the Document Shepherd? Shwetha Bhandari Who is the Responsible Area Director? Erik Kline (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have read the document and based on the publicly available reference material it appears to capture the use cases and example accurately. It is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR was disclosed related to this draft. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The workgroup as a whole agrees to publish this Informational document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.) None. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Table 2 in Section 2.7 has the following nit: ** There are 35 instances of too long lines in the document, the longest one being 4 characters in excess of 72. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. Not applicable (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? None (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. None. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No, this document will not influence status of any existing documents, (17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). No IANA considerations. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No IANA considerations. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. No formal language in this draft. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342? No yang module in the draft. |
2022-01-25
|
12 | Yong-Geun Hong | New version available: draft-ietf-6lo-use-cases-12.txt |
2022-01-25
|
12 | (System) | New version approved |
2022-01-25
|
12 | (System) | Request for posting confirmation emailed to previous authors: 6lo-chairs@ietf.org, Abdur Sangi , Carles Gomez , Samita Chakrabarti , Yong-Geun Hong |
2022-01-25
|
12 | Yong-Geun Hong | Uploaded new revision |
2022-01-24
|
11 | Shwetha Bhandari | Notification list changed to Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, shwetha.bhandari@gmail.com from Gabriel Montenegro <Gabriel.Montenegro@microsoft.com> because the document shepherd was set |
2022-01-24
|
11 | Shwetha Bhandari | Document shepherd changed to Shwetha Bhandari |
2022-01-13
|
11 | (System) | Document has expired |
2021-07-12
|
11 | Yong-Geun Hong | New version available: draft-ietf-6lo-use-cases-11.txt |
2021-07-12
|
11 | (System) | New version approved |
2021-07-12
|
11 | (System) | Request for posting confirmation emailed to previous authors: Abdur Sangi , Carles Gomez , Samita Chakrabarti , Yong-Geun Hong |
2021-07-12
|
11 | Yong-Geun Hong | Uploaded new revision |
2021-02-21
|
10 | Yong-Geun Hong | New version available: draft-ietf-6lo-use-cases-10.txt |
2021-02-21
|
10 | (System) | New version approved |
2021-02-21
|
10 | (System) | Request for posting confirmation emailed to previous authors: 6lo-chairs@ietf.org, Abdur Sangi , Carles Gomez , Samita Chakrabarti , Take Aanstoot , Yong-Geun Hong |
2021-02-21
|
10 | Yong-Geun Hong | Uploaded new revision |
2021-02-21
|
10 | (System) | Request for posting confirmation emailed to previous authors: 6lo-chairs@ietf.org, Abdur Sangi , Carles Gomez , Samita Chakrabarti , Take Aanstoot , Yong-Geun Hong |
2021-02-21
|
10 | Yong-Geun Hong | Uploaded new revision |
2021-01-14
|
09 | (System) | Document has expired |
2020-07-13
|
09 | Yong-Geun Hong | New version available: draft-ietf-6lo-use-cases-09.txt |
2020-07-13
|
09 | (System) | New version approved |
2020-07-13
|
09 | (System) | Request for posting confirmation emailed to previous authors: Take Aanstoot , Samita Chakrabarti , Yong-Geun Hong , Abdur Sangi , 6lo-chairs@ietf.org, Carles Gomez |
2020-07-13
|
09 | Yong-Geun Hong | Uploaded new revision |
2020-05-07
|
08 | (System) | Document has expired |
2019-11-04
|
08 | Yong-Geun Hong | New version available: draft-ietf-6lo-use-cases-08.txt |
2019-11-04
|
08 | (System) | New version approved |
2019-11-04
|
08 | (System) | Request for posting confirmation emailed to previous authors: 6lo-chairs@ietf.org, Yong-Geun Hong , Samita Chakrabarti , Take Aanstoot , Abdur Sangi , Carles Gomez |
2019-11-04
|
08 | Yong-Geun Hong | Uploaded new revision |
2019-09-10
|
07 | Yong-Geun Hong | New version available: draft-ietf-6lo-use-cases-07.txt |
2019-09-10
|
07 | (System) | New version approved |
2019-09-10
|
07 | (System) | Request for posting confirmation emailed to previous authors: 6lo-chairs@ietf.org, Yong-Geun Hong , Samita Chakrabarti , Take Aanstoot , Abdur Sangi , Carles Gomez |
2019-09-10
|
07 | Yong-Geun Hong | Uploaded new revision |
2019-03-11
|
06 | Yong-Geun Hong | New version available: draft-ietf-6lo-use-cases-06.txt |
2019-03-11
|
06 | (System) | New version approved |
2019-03-11
|
06 | (System) | Request for posting confirmation emailed to previous authors: 6lo-chairs@ietf.org, Yong-Geun Hong , Samita Chakrabarti , Take Aanstoot , Abdur Sangi , Carles Gomez |
2019-03-11
|
06 | Yong-Geun Hong | Uploaded new revision |
2019-01-02
|
05 | (System) | Document has expired |
2018-11-04
|
05 | Gabriel Montenegro | IETF WG state changed to In WG Last Call from WG Document |
2018-07-01
|
05 | Yong-Geun Hong | New version available: draft-ietf-6lo-use-cases-05.txt |
2018-07-01
|
05 | (System) | New version approved |
2018-07-01
|
05 | (System) | Request for posting confirmation emailed to previous authors: 6lo-chairs@ietf.org, Yong-Geun Hong , Samita Chakrabarti , Take Aanstoot , Abdur Sangi , Carles Gomez |
2018-07-01
|
05 | Yong-Geun Hong | Uploaded new revision |
2018-05-31
|
04 | Gabriel Montenegro | Notification list changed to Gabriel Montenegro <Gabriel.Montenegro@microsoft.com> |
2018-05-31
|
04 | Gabriel Montenegro | Document shepherd changed to Gabriel Montenegro |
2018-03-05
|
04 | Yong-Geun Hong | New version available: draft-ietf-6lo-use-cases-04.txt |
2018-03-05
|
04 | (System) | New version approved |
2018-03-05
|
04 | (System) | Request for posting confirmation emailed to previous authors: 6lo-chairs@ietf.org, Yong-Geun Hong , Samita Chakrabarti , Take Aanstoot , Abdur Sangi , Carles Gomez |
2018-03-05
|
04 | Yong-Geun Hong | Uploaded new revision |
2017-10-30
|
03 | Yong-Geun Hong | New version available: draft-ietf-6lo-use-cases-03.txt |
2017-10-30
|
03 | (System) | New version approved |
2017-10-30
|
03 | (System) | Request for posting confirmation emailed to previous authors: 6lo-chairs@ietf.org, Yong-Geun Hong , Samita Chakrabarti , Take Aanstoot , Abdur Sangi , Carles Gomez |
2017-10-30
|
03 | Yong-Geun Hong | Uploaded new revision |
2017-07-03
|
02 | Yong-Geun Hong | New version available: draft-ietf-6lo-use-cases-02.txt |
2017-07-03
|
02 | (System) | New version approved |
2017-07-03
|
02 | (System) | Request for posting confirmation emailed to previous authors: Abdur Sangi , Take Aanstoot , 6lo-chairs@ietf.org, Carles Gomez , Yong-Geun Hong |
2017-07-03
|
02 | Yong-Geun Hong | Uploaded new revision |
2017-03-13
|
01 | Yong-Geun Hong | New version available: draft-ietf-6lo-use-cases-01.txt |
2017-03-13
|
01 | (System) | New version approved |
2017-03-13
|
01 | (System) | Request for posting confirmation emailed to previous authors: 6lo-chairs@ietf.org, Carles Gomez , Yong-Geun Hong |
2017-03-13
|
01 | Yong-Geun Hong | Uploaded new revision |
2016-12-02
|
00 | Yong-Geun Hong | New version available: draft-ietf-6lo-use-cases-00.txt |
2016-12-02
|
00 | (System) | WG -00 approved |
2016-11-29
|
00 | Yong-Geun Hong | Set submitter to "Yong-Geun Hong ", replaces to (none) and sent approval email to group chairs: 6lo-chairs@ietf.org |
2016-11-29
|
00 | Yong-Geun Hong | Uploaded new revision |