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

[Zaheduzzaman Sarker via Datatracker <[e-mail]>]

Zaheduzzaman Sarker 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:
----------------------------------------------------------------------

Thanks for working on this informational document.

I found this document a good read from the vehicular connectivity and
networking point of view, however, there are some cases where the descriptions
are not clear to convey the message and required ask.  Specially in section 4
and section 6. I think Roman already have covered most of those. Hence
supporting his discuss points regarding  those sections.

I also have following observation/comments which I believe if addressed will
improve the document-

* Abstract: I actually didn't find enumerated requirements form the problem
statements that obviously. Hence, I would suggest to remove this part ("then
enumerates requirements for the extensions of those IPv6 protocols for
IPv6-based vehicular networking") from the abstract. Lets stick to what the
title says.  Otherwise, I would expect a numbered list of requirements that the
wg would like to refer to and fulfill in future works.

* Please add V2P (and X2P) definitions like others in the terminology section.

* Section 3.1: it says -

     "To encourage more vehicles to participate in this cooperative
     environmental sensing, a reward system will be needed. Sensing activities
     of each vehicle need to be logged in either a central way through a
     logging server (e.g., TCC) in the vehicular cloud or a distributed way
     (e.g., blockchain [Bitcoin]) through other vehicles or infrastructure. In
     the case of a blockchain, each sensing message from a vehicle can be
     treated as a transaction and the neighboring vehicles can play the role of
     peers in a consensus method of a blockchain
     [Bitcoin][Vehicular-BlockChain]."

   This seems like a misfit to the use case section and felt more like belongs
   to some sort of requirement for a reward system. I would suggest to just
   remove this paragraph.

* Section 5: it says -

    "Since the vehicles are likely to be moving at great speed, protocol
    exchanges need to be completed in a relatively short time compared to the
    lifetime of a link between a vehicle and an IP-RSU, or between two vehicles"

  While it is true that vehicles can move with "great speed", it is also true
  that the relative speeds between vehicles might not be that "great", e.g.
  platooning case. And when vehicles passes each other or a IP-RSU really fast
  there might not be enough time to setup the link layer connection and V2I
  communication becomes more important. I found the quoted section of problem
  statement to be ignorant of these facts and missing the potential relation
  among V2V, V2I and V2X connectivity and communication.

*  I would note that, fro, the use case and problem statement, tranport-layer
session mobility and usage of available bandwidth mentioned in the document.
However, those are not discussed with details but I understand would play vital
role to support the discussed application use cases and architecture. I assume
this might be due to  the scope of the document but this document should say
something about those aspect, at least mention as potential future work that
need to fulfill the envisioned use cases.