[ipwave] Lars Eggert's No Objection on draft-ietf-ipwave-vehicular-networking-28: (with COMMENT)

Lars Eggert via Datatracker <noreply@ietf.org> Tue, 05 April 2022 13:53 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: its@ietf.org
Delivered-To: its@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A36553A07C1; Tue, 5 Apr 2022 06:53:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Lars Eggert via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ipwave-vehicular-networking@ietf.org, ipwave-chairs@ietf.org, its@ietf.org, Carlos Bernardos <cjbc@it.uc3m.es>, cjbc@it.uc3m.es
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Lars Eggert <lars@eggert.org>
Message-ID: <164916678663.21153.10350104368537169496@ietfa.amsl.com>
Date: Tue, 05 Apr 2022 06:53:06 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/Fj76FECWmRSd_gG8x7_IgVTLgIY>
Subject: [ipwave] Lars Eggert's No Objection on draft-ietf-ipwave-vehicular-networking-28: (with COMMENT)
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2022 13:53:07 -0000

Lars Eggert has entered the following ballot position for
draft-ietf-ipwave-vehicular-networking-28: No Objection

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-ipwave-vehicular-networking/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1. , paragraph 5, comment:
>    Along with these WAVE standards and C-V2X standards, regardless of a
>    wireless access technology under the IP stack of a vehicle, vehicular
>    networks can operate IP mobility with IPv6 [RFC8200] and Mobile IPv6
>    protocols (e.g., Mobile IPv6 (MIPv6) [RFC6275], Proxy MIPv6 (PMIPv6)
>    [RFC5213], Distributed Mobility Management (DMM) [RFC7333], Network
>    Mobility (NEMO) [RFC3963], Locator/ID Separation Protocol (LISP)
>    [I-D.ietf-lisp-rfc6830bis], and Automatic Extended Route Optimization
>    based on the Overlay Multilink Network Interface (AERO/OMNI)
>    [I-D.templin-6man-aero] [I-D.templin-6man-omni]).  In addition, ISO
>    has approved a standard specifying the IPv6 network protocols and
>    services to be used for Communications Access for Land Mobiles (CALM)
>    [ISO-ITS-IPv6][ISO-ITS-IPv6-AMD1].

Isn't it a bit premature to list AERO and OMNI alongside a number of published
standards from the IETF and other organizations? As far as I know they are
individual documents that have not been adopted? (Here and elsewhere in the
document.)

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "invalid"; alternatives might be "not valid", "unenforceable", "not
   binding", "inoperative", "illegitimate", "incorrect", "improper",
   "unacceptable", "inapplicable", "revoked", "rescinded".

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

Section 5.2. , paragraph 7, nit:
-    home.  There is nonnegligible control overhead to set up and maintain
+    home.  There is non-negligible control overhead to set up and maintain
+                       +

Section 1. , paragraph 3, nit:
> 9.4 [WAVE-1609.4] specifies the multi-channel operation. IEEE 802.11p was fi
>                                 ^^^^^^^^^^^^^
This word is normally spelled as one.

Section 4.1. , paragraph 7, nit:
> arty. To minimize this kind of risk, an reinforced identification and verific
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 4.3. , paragraph 17, nit:
> livered to relevant vehicles in an efficient way (e.g., multicasting). With
>                              ^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "efficiently" to avoid
wordiness.

Section 4.3. , paragraph 17, nit:
> layers (e.g., IPv6, TCP, and UDP). Hence the bandwidth selection according t
>                                    ^^^^^
A comma may be missing after the conjunctive/linking adverb "Hence".

Section 5.1.1. , paragraph 4, nit:
> y with standard IPv6 links in an efficient fashion to support IPv6 DAD, MLD a
>                            ^^^^^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "efficiently" to avoid
wordiness.

Section 5.1.2. , paragraph 2, nit:
> ergy constraints, RPL does not suggest to use a proactive mechanism (e.g., k
>                                ^^^^^^^^^^^^^^
The verb "suggest" is used with the gerund form.

Section 5.2. , paragraph 4, nit:
> lic Key Infrastructure (PKI) in an efficient way. To provide safe interactio
>                              ^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "efficiently" to avoid
wordiness.

Section 5.2. , paragraph 5, nit:
> other servers behind an IP-RSU in a secure way. Even though a vehicle is per
>                                ^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "securely" to avoid wordiness.

Section 5.2. , paragraph 8, nit:
> eceived ND message, which requires to use the CGA ND option in the ND protoc
>                                    ^^^^^^
Did you mean "using"? Or maybe you should add a pronoun? In active voice,
"require" + "to" takes an object, usually a pronoun.

Section 6. , paragraph 3, nit:
>  taking a safe maneuver. Since cyber security issues in vehicular networks ma
>                                ^^^^^^^^^^^^^^
The word "cybersecurity" is spelled as one.

Section 6.1. , paragraph 4, nit:
> ensus algorithm needs to be developed or an existing consensus algorithm need
>                                      ^^^
Use a comma before "or" if it connects two independent clauses (unless they are
closely connected and short).

Section 8.2. , paragraph 7, nit:
>  Device-free human counting through WiFi fine-grained subcarrier information
>                                     ^^^^
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

Section 8.2. , paragraph 23, nit:
> unction (called OF), which allows to adapt the activity of the routing proto
>                                   ^^^^^^^^
Did you mean "adapting"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

"Appendix B. ", paragraph 5, nit:
> ST, CEA Saclay, Gif-sur-Yvette, Ile-de-France 91190, France, Phone: +33169089
>                                 ^^^^^^^^^^^^^
"Ile-de-France" is an imported foreign expression, which originally has a
diacritic. Consider using "Île-de-France".

Uncited references: [RFC3849].