Skip to main content

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