Thank you, Roman, for the review. Authors: I believe we're waiting for someone to produce one or more updates that collectively address the comments provided.
Thanks, -ek On Tue, Dec 13, 2022 at 3:15 PM Roman Danyliw via Datatracker <[email protected]> wrote: > > Roman Danyliw has entered the following ballot position for > draft-ietf-6lo-use-cases-14: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6lo-use-cases/ > > > > ---------------------------------------------------------------------- > 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? > > > ---------------------------------------------------------------------- > 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 > > > _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
