Re: [ipwave] Éric Vyncke's No Objection on draft-ietf-ipwave-vehicular-networking-29: (with COMMENT)
Erik Kline <ek.ietf@gmail.com> Sat, 25 June 2022 21:02 UTC
Return-Path: <ek.ietf@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4041BC14CF04; Sat, 25 Jun 2022 14:02:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 gGeJUDojaTwf; Sat, 25 Jun 2022 14:02:31 -0700 (PDT)
Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 EC249C14F725; Sat, 25 Jun 2022 14:02:30 -0700 (PDT)
Received: by mail-vk1-xa36.google.com with SMTP id b4so2760836vkh.6; Sat, 25 Jun 2022 14:02:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CNTtQk6gVoMSs4iKOq4OkikdTZlJ8+GPK5iUWRLB8Jc=; b=VRtZIfCDfRAcSBvpNtRysOhVXvxCWumTYh9m4ihl+y2rByakbg4HzVd9q6XLCStQaO RKgEprTJXZZsZzrY1UyW65m5wMsE7qSz9SFldMqYwF215cg2f7a5mzrLToAFoYnkf2Wq iJnBs17v0zE9ZiXyJbLY4nZhrhA9svfxqBy4aYTVupGkbej4ohZhXK8X2koakGUcoHKi 5Vxz/DZpmjUQBDS4ltzJx4X3uxYsqLeNakExoLek/3w2AlQxQzu3XbqEyOVgGPAaJbS0 RAwtS8XMpNG+PhLimjsTLVNghesYdw/TKdt59ZM1iGiR3QURPh4KxQXz8GRoU2vavi29 28gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CNTtQk6gVoMSs4iKOq4OkikdTZlJ8+GPK5iUWRLB8Jc=; b=J17Zx5LSLXNf7vz9H5OQJensk2Z1kIXvNbx9y99wdSJiuGpcwxJfGeFT1e2K8wClA/ Eia+7xIUpj4vClvPcOCPJWYak+BoX5URe6hm4TAbyiAmv9qC3jqd93rYbFZ2IJ7hclBt PUPHtql+lgTpmaeJe1mZOzpqH4fhCVnRZ+LLUs+LXgNA5Ar0mcyiEbenHK4c++6ITkAo V3v/BHvfazHjhQUCGEMqQ29IY39FcljpiWG04aHu/EKGEqg8tt6z3hekRvrPNRyOYJB+ UinqfCnl1d/ycMaXXxIfOc9HrkwD3S832lgq60j7m7Sg41EDauuTDUs9Of41l7NITHvi YaaQ==
X-Gm-Message-State: AJIora/ugZbj5xcosoF/wBzIuY40ZvEgVJRX2tumT+9rU2kGoFlpm6rC 7T6yR/j+Jxh2QAYhm7PTBpIMFyJyhSniD87pVvWcxsIt
X-Google-Smtp-Source: AGRyM1uu5+s1mwqStTt1EN2ZxfyJK4FwALOQ2m8bsU4YRp/55DuOG1PxsZsMparLL39j3MIOjGe+4h7Jlu3KQAPxw38=
X-Received: by 2002:a1f:1886:0:b0:36c:c60b:a4ef with SMTP id 128-20020a1f1886000000b0036cc60ba4efmr1952940vky.29.1656190949595; Sat, 25 Jun 2022 14:02:29 -0700 (PDT)
MIME-Version: 1.0
References: <165614191142.5418.10384462930853095856@ietfa.amsl.com>
In-Reply-To: <165614191142.5418.10384462930853095856@ietfa.amsl.com>
From: Erik Kline <ek.ietf@gmail.com>
Date: Sat, 25 Jun 2022 14:02:18 -0700
Message-ID: <CAMGpriX8wq_pVR1baaE7p=a-6iLzC4bw8VVDGqtNx5e1HTShwQ@mail.gmail.com>
To: Éric Vyncke <evyncke@cisco.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-ipwave-vehicular-networking@ietf.org, ipwave-chairs@ietf.org, its@ietf.org, Carlos Bernardos <cjbc@it.uc3m.es>
Content-Type: multipart/alternative; boundary="0000000000003b1f1a05e24c01cd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/rlpCcitOY5J1Ybdycf_Wy-4xJNc>
Subject: Re: [ipwave] Éric Vyncke's No Objection on draft-ietf-ipwave-vehicular-networking-29: (with COMMENT)
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
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: Sat, 25 Jun 2022 21:02:33 -0000
Thank you Eric, and thank you Paul! On Sat, Jun 25, 2022 at 12:25 AM Éric Vyncke via Datatracker < noreply@ietf.org> wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-ipwave-vehicular-networking-29: 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: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. I found the use cases part > of > section 3.1 very interesting to read even if some of them seem very far > fetched > ;-) > > I have now cleared my previous blocking DISCUSS points as you have > addressed > them as well as all but one of my previous non-blocking COMMENTs. Thanks > for > your reaction. > > I have kept below the DISCUSS & COMMENT points just for archiving, please > ignore them. > > Special thanks to > > - Carlos Bernardos for the shepherd's write-up even if a justification for > the > informational status would have been welcome but the WG consensus > description > is appreciated. > > - Pascal Thubert for his IETF last call INT directorate review at: > > https://datatracker.ietf.org/doc/review-ietf-ipwave-vehicular-networking-20-intdir-lc-thubert-2021-06-18/ > and for his IESG telechat INT directorate review > > https://datatracker.ietf.org/doc/review-ietf-ipwave-vehicular-networking-27-intdir-telechat-thubert-2022-02-28/ > Pascal's Last Call & telechat reviews were (at least partially) acted upon > by > Paul ;-) > > I hope that this helps to improve the document, > > Regards, > > -éric > > # DISCUSS (just for archiving) > > As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a > DISCUSS ballot is a request to have a discussion on the following topics: > > ## Abstract & Section 1 > > "then enumerates requirements for the extensions of those IPv6 protocols" > does > not match any IPWAVE WG work item, i.e., it is outside the scope of the > charter > of IPWAVE WG. As the document does not explicitly specify requirements, I > strongly suggest to use the word "gaps" rather than "requirements" in the > abstract and section 1. > > ## Section 4.1 > > Using an IPv6 address out of a ULA prefix still requires DAD. So the text > below > should be updated to be corrected: > "their own IPv6 Unique Local Addresses > (ULAs) [RFC4193] over the wireless network, which does not require > the messaging (e.g., Duplicate Address Detection (DAD)) of IPv6 > Stateless Address Autoconfiguration (SLAAC) [RFC4862]." > > ## Section 4.2 > > Very similar comment as above (i.e., DAD & MLD must be done for all IPv6 > addresses of an interface and not only for the global one): > "... When global IPv6 > addresses are used, wireless interface configuration and control > overhead for DAD" > > ## Section 5.2 > "... If DHCPv6 is used to assign > a unique IPv6 address to each vehicle in this shared link, DAD is not > required. " > This is incorrect and must be changed (see section 18.2.10.1. of RFC 8415) > > # COMMENTS (just for archiving) > > "100km/h as the speed limit in highway" will make many European drivers > smile > as it is really slow... > > ## Section 1 > > "Most countries and regions in the world have adopted the same frequency > allocation for vehicular networks." but there are TWO frequency allocations > described just before, so, which one has been adopted ? > > ## Section 2 > > "GPS" is just the USA commercial example of the more generic "global > navigation > satellite system" (GNSS), GNSS should be used in this document. > > As IP-RSU have at least 2 interfaces, should "Also, it may have *the* third > IP-enabled wireless interface" be replaced by "Also, it may have *a* third > IP-enabled wireless interface" ? > > LiDAR ... "by measuring the reflected pulsed light" but on which kind of > metrics ? > > ## Section 3.1 > > Should the 1st and 5th bullets be grouped together ? > > Please describe "UAM" (e.g., in the terminology section) as it is unclear > to > the reader whether it is a crewed / uncrewed aircraft. > > If both road and air vehicles are use case, what about river / sea ships or > trains ? > > Does the paragraph about "reward system" belong to the use case ? It rather > sounds like a business requirement. Suggest to remove this part. > > Like written by Pascal Thubert in his telechat review, the last paragraph > "IPv6-based packet exchange and secure" should be clear that this is not > only > about data plane traffic but also control plane L2/L3 ones. Please also > use the > Oxford comma, i.e., add a "," after "exchange". > > ## Section 3.2 > > Suggest to also mention "5G" after "IP-RSU or 4G-LTE networks" > > How is the UAM use case different from a driverless terrestrial EV ? > Suggest to > merge those use cases. > > ## Section 4.1 > > As noted by other ADs, "Existing network architectures," the list should > not > include OMNI yet as it is not deployed and would probably not be described > as > an architecture. > > "the wireless media interfaces are autoconfigured with a global IPv6 > prefix", > is it the same shared prefix or multiple prefixes ? > > Is "RSU" the same concept as "IP-RSU" ? > > The last paragraph is about TCP session continuity, but does not explain > why > multi-path TCP or QUIC session resumption cannot be used. > > ## Section 4.2 > > The computation about "dwell time" is interesting even if it is computed > in the > best case. But, I really wonder whether using IPv6 and routing are > applicable > to the use case as opposed to more layer-2 + tunnel solutions (like 3GPP) > with > such short time for hand-over. I am a strong supporter of layer-3 (IPv6 and > routing), but I cannot refrain from thinking that IPv6 is the wrong > technical > solution for those use cases... Was this discussed in the WG ? > > ## Section 5.1 > > What is "legacy DAD" ? > > "...the NA interval needs to be > dynamically adjusted according to a vehicle's speed so that the > vehicle can maintain its neighboring vehicles in a stable way" > With the issues linked to multicast over wireless, are the authors and the > WG > sure that increasing the amount of multicast will not aggravate the > problem ? > See RFC 9119 (cited as a normative down reference) > > ## Section 5.1.2 > > Please add some references to the MADINAS WG current work items. The > authors > may also consider adding this use case to the MADINAS use case. > > "The pseudonym of a MAC address affects an IPv6 address based on the MAC > address", nearly no implementations use EUI-64 anymore so this part should > probably be removed from the document. But, the change of MAC address > probably > has other impact on the IP stack, e.g., the neighbour cache. > > ## Section 5.1.3 > > AFAIK, RPL relies on messages to discover the topology and I am afraid > that in > such a moving / dynamic environment, there will be too many of RPL > messages. > Will RPL scale in this ever changing network ? Please note that I am not a > RPL > expert. > > ## Section 6.1 > > Some explanations on how SEND protects against DAD flooding would be > welcome. > > Is "classical IPv6 ND" the same as the previously used "legacy ND" ? > > Wondering why "Vehicle Identification Number (VIN)" is suggested to be > used as > SubjectAltName in a certificate rather than a car manufacturer cert ? > > ## Section 6.3 > > The part about bitcoin and blockchain errs probably too far away from the > IETF > remit. > > ## Appendix B > > I fail to understand how RPL and OMNI can be compared as they are vastly > different technologies (routing vs. tunneling). > > "In OMNI protocol, each wireless media interface is configured with an IPv6 > Unique Local Address (ULA)" but from my last read of OMNI drafts (1+ year > ago), > the OMNI virtual interface can have a ULA indeed but the wireless physical > ones > are using any prefix. > > ## Appendix D > > What will be the impact of high packet loss rate (that I am expecting on > such > networks) on IP parcels ? > > # NITS > > Please check that all IPv6 addresses are in lowercase (e.g., in section > 4.1). > > > >
- [ipwave] Éric Vyncke's No Objection on draft-ietf… Éric Vyncke via Datatracker
- Re: [ipwave] Éric Vyncke's No Objection on draft-… Erik Kline
- Re: [ipwave] Éric Vyncke's No Objection on draft-… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Éric Vyncke's No Objection on draft-… Mr. Jaehoon Paul Jeong