[ipwave] Robert Wilton's Abstain on draft-ietf-ipwave-vehicular-networking-28: (with COMMENT)
Robert Wilton via Datatracker <noreply@ietf.org> Thu, 07 April 2022 11:10 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 073ED3A17BA; Thu, 7 Apr 2022 04:10:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton 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: Robert Wilton <rwilton@cisco.com>
Message-ID: <164932980700.8548.5907974851337616041@ietfa.amsl.com>
Date: Thu, 07 Apr 2022 04:10:07 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/wzfOyXgjilmzIcS698YtKhGt9vc>
Subject: [ipwave] Robert Wilton's Abstain 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: Thu, 07 Apr 2022 11:10:08 -0000
Robert Wilton has entered the following ballot position for draft-ietf-ipwave-vehicular-networking-28: Abstain 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: ---------------------------------------------------------------------- I'm not an expect on these areas of technology, but I find parts of this document to be quite uncompelling. However, it is an informational document, where considerable latitude is allowed. Although I'm happy for the authors to correct my misunderstandings below, if they wish, I'm doubtful that such a discussion will really be helpful, hence my abstain ballot. Some of my concerns when reviewing this document: (1) It feels like quite a lot of these problems are (or could be) solved today using the existing wireless networks and GPS already included in cars. E.g., presumably they are already making use of IP over 4G-LTE without needing these proposed protocol changes? I.e., how many of the problems described here can really be most efficiently solved by having a local dynamic network? (2) Having some sort of bitcoin/blockchain based micropayment scheme for sharing sensor data between vehicles feels highly implausible to me, given that the world hasn't seemed to manage a micropayment scheme for websites which seems like an easier problem to solve. (3) Would vehicles even be able to safely trust sensor data coming from other vehicles? E.g., hacked vehicles that randomly occasionally inject false sensor readings. Who would have legal liability if your vehicle takes some action based on unreliable 3rd party sensor data? I appreciate that it outside this type of technical document, but I think that it limits the likely hood of solving this in an ad hoc network. (4) I struggle to understand how the V2X use cases really work. In a street (at least in the UK) there would often be people in very close proximity to a vehicle (e.g., walking on the pavement [sidewalk] next to a vehicle, and presumably it is only people in front of the vehicle that are potential collision problems, and for these cases, are radar/lidar/cameras/sensors not a more robust choice (and are already deployed today, and seemingly improving every year). I would think that the only way that this could work with a smartphone is if it sharing very precise (0.1 m) location data all the time to everything around it, which would probably degrade the battery and would also seem to have some serious privacy considerations. (5) In Appendix D, I don't understand how the AERO/OMNI service solves the MTU problem. It seems to be just introducing another layer to solve exactly the problem that are already solved by existing transport layer protocols. If there is some data illustrating how TCP over OAL (with IP parcels) is more efficient that straight TCP over IP then that would be worth sharing. Regards, Rob
- [ipwave] Robert Wilton's Abstain on draft-ietf-ip… Robert Wilton via Datatracker