[ipwave] Robert Wilton's Abstain on draft-ietf-ipwave-vehicular-networking-28: (with COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

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