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

Yong-Geun Hong <yonggeun.hong@gmail.com> Tue, 14 March 2023 11:21 UTC

Return-Path: <yonggeun.hong@gmail.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A38C13AE3B; Tue, 14 Mar 2023 04:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jn7c3TCPrqpX; Tue, 14 Mar 2023 04:21:15 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A443AC1522B9; Tue, 14 Mar 2023 04:21:15 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id f16so15614140ljq.10; Tue, 14 Mar 2023 04:21:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678792874; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=s7th0rluvpJtEAxeNhUjHR5If8ZZnBrdVqoP62DdDKM=; b=ex5QppWRo5SsMBNvVF1Q3pxeGKA+nsvWDYP6tzQSzd2qm+mcItZrZ5eZRDT1/rWEzG PQDXyZyv0WQgv9f0m4BZjRcdZ5UZTtFkDMGJO9s4RdyX7rep0Mu9seuFz/JvqIdOJilx TFECF+ge9zjUIKScpqol0/0txnJAFt9+y4xyqlKyur8Fbvk5NwF6bF4NcFiTLruGWbcC El2MdaCh4zY+xqteROUAhP2DcKFqVNgFaPa8eEfXkZcUPTbzyZ5Uzv2qCXfczW6oUPq7 xU0aqRxyyrAoBUDU9FlPQmPI38A3qlTJtj6PKktnMe9Wbiz1dYbsy+YohAe0TDu6dYmR FeGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678792874; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=s7th0rluvpJtEAxeNhUjHR5If8ZZnBrdVqoP62DdDKM=; b=68PhMYfbhUIBU541720h+dYIBQql+j4Z+mld7wzwjsqrdFvk7d3pUWCGGn9tVcw9EW AMuds5qBYTPto8wcL4dxmVbkHvhCi8pSvbIjdl8A64FUP0x4neMvgKrjGuf/aDwYsrdo a3K9F5iSD04h0C7YBwNijQ9bRpNLAAdddqe7MUdS4pJZQBJZvCq3VaJch277zlyXzQcV GPgBCBZzR1uv1epGT12Z8vH92O/yurnyJLSxwosxdZ2TmCXSS4UOJjgvwfiiiG4UAPEv OhqYAufKGynvjkCQNCsj2vTGqwED+3neVNu2fo5zcxPcp6kr6+UpGlQKdjLjjvxdKzOo G/hA==
X-Gm-Message-State: AO0yUKUDjxAV2dHEf5rxt6KDXRf10+KRZl/okLWCJvqyi8tNr2ZeWyeh 2ug+Nh4Y4ao9ixJB7g09OUOKL/53WiU/gj+UNDwwxgbhPbUoiw==
X-Google-Smtp-Source: AK7set9Unc7KSFusuAFP2sLYn5MPPbIUFQnub6Ifp9RmYZW5ONohiwA44clBzqeO/uHCtNEqpt9K2Gl+6IGNmScPdwM=
X-Received: by 2002:a2e:a612:0:b0:295:d632:ba22 with SMTP id v18-20020a2ea612000000b00295d632ba22mr11786269ljp.8.1678792873779; Tue, 14 Mar 2023 04:21:13 -0700 (PDT)
MIME-Version: 1.0
References: <167097330864.46451.16737695388174276673@ietfa.amsl.com>
In-Reply-To: <167097330864.46451.16737695388174276673@ietfa.amsl.com>
From: Yong-Geun Hong <yonggeun.hong@gmail.com>
Date: Tue, 14 Mar 2023 20:21:01 +0900
Message-ID: <CACt2foFQrmQswNwXAiVMB63dF4d0-JDTj0FUhUtRusSXnLMUoA@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-6lo-use-cases@ietf.org, 6lo-chairs@ietf.org, 6lo@ietf.org, shwetha.bhandari@gmail.com
Content-Type: multipart/mixed; boundary="000000000000e4b22a05f6da6c01"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/3OrhHM568Yj44hTxOGdsDh1dOW0>
Subject: Re: [6lo] Roman Danyliw's Discuss on draft-ietf-6lo-use-cases-14: (with DISCUSS and COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2023 11:21:19 -0000

Dear   Roman Danyliw.

Thanks for your valuable comments and sorry for the late response.

To resolve your comments, I updated the draft as an attached file.
Because there are lots of comments, I used an excel file to resolve
comments.

And, I submitted the revision draft based on your comments.
https://www.ietf.org/archive/id/draft-ietf-6lo-use-cases-15.html

It is appreciated to check again and let me know any missing points.

Best regards.

Yong-Geun.

2022년 12월 14일 (수) 오전 8:15, Roman Danyliw via Datatracker <noreply@ietf.org>님이
작성:

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