Re: [6lo] Roman Danyliw's Discuss on draft-ietf-6lo-use-cases-14: (with DISCUSS and COMMENT)

[Yong-Geun Hong <[e-mail]>]

Dear Erik.

Thanks for your reminder.

As you mentioned, we are preparing the draft update.

Before the next meeting or ASAP, we will update the draft and submit.

Best regards.

Yong-Geun.

2023년 2월 1일 (수) 오후 3:49, Erik Kline <[e-mail]>님이 작성:

> 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
> <[e-mail]> 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
> >
> >
> >
>