# 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

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.

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).

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.

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.

  -

# É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

(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/