Re: [ipwave] Some review comments for draft-ietf-ipwave-vehicular-networking-11

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Hi Charlie,
I have addressed your comments below and your editorial changes, submitting
the revision:
https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-12

Also, I addressed Sandra's comments about the definition of an RSU as an
edge computing system
having multiple routers and servers (including DNS server), as shown in
Figure 2.

I attach the revision letter for your double-checking.

Thanks for your valuable and constructive comments.

Best Regards,
Paul


On Mon, Sep 16, 2019 at 1:08 PM Charlie Perkins <
[e-mail]> wrote:

> Hello folks,
>
> I made a review of the document
> draft-ietf-ipwave-vehicular-networking-11.txt.  Besides editorial
> comments, I had some other more substantive comments on the document, as
> follows.
>
> First, I thought that the document should contain an easily identifiable
> problem statement.  Here is some text that I devised for that purpose,
> which could fit naturally at the beginning of Section 5.
>
>     In order to specify protocols using the abovementioned architecture
>     for VANETs, IPv6 core protocols have to be adapted to overcome certain
>     challenging aspects of vehicular networking.  Since the vehicles are
>     likely to be moving at great speed, protocol exchanges need to be
>     completed in a time relatively small compared to the lifetime of a
>     link between a vehicle and an RSU, or between two vehicles.  This
>     has a major impact on IPv6 neighbor discovery. Mobility management
>     is also vulnerable to disconnections that occur before the completion
>     of identify verification and tunnel management.  This is especially
>     true given the unreliable nature of wireless communications.  Finally,
>     and perhaps most importantly, proper authorization for vehicular
> protocol
>     messages must be assured in order to prevent false reports of accidents
>     or other mishaps on the road, which would cause horrific misery in
>     modern urban environments.
>
> ----------------------------------------------
>
> Although geographic routing is mentioned early in the document, it is
> not discussed in later sections.  This makes me wonder whether the early
> mention is really relevant.  In fact, for fast moving objects, I think
> it is already questionable whether geographic routing has value.  For
> the RSUs, it is a lot easier to imagine a good use for geographic
> routing, or perhaps some other use of geographic information to
> establish links between application endpoints.  If geographic algorithms
> are mentioned at all, a lot more development is needed to establish
> relevance to the problem statement.
>
> ---------------------------------------------
>
> More description is needed for OCB in the Terminology section. It would
> also be a good idea to include definitions for "context-aware" and for
> platooning.
>
> class-based safety plan needs a definition and a list of classes.
>
> ---------------------------------------------
>
> As a general comment, it seems to me that a proposed architecture is
> usually considered to be part of the solution, not the problem
> statement.  In the case of this document, the architecture is really a
> depiction of IPv6 as it might be normally considered to live in a
> multi-network deployment (e.g., between a lot of cars and RSUs).  But
> anyway some care has to be taken so that the proposed architecture
> doesn't otherwise place strong limits on acceptable solutions.  So, for
> example, in section 4.1, it needs to be clear whether or not a single
> subnet prefix can span multiple vehicles.  This is an important choice.
>
> ---------------------------------------------
>
> In section 5.1.1., a claim is made that a new link model is required.  I
> think this is a very ambitious claim, and I am not even quite sure what
> is meant.  IPv6 already provides for "on-link" and "off-link" variations
> on subnet operation.  Unless I am missing something here, the claim
> should be made much more clear (or else retracted).
>
> Similarly, the suggestion that VANETs need to be merging and
> partitioning as part of the problem statement seems at least ambitious
> and might present a very high bar that could disqualify otherwise
> suitable solutions.
>
> ---------------------------------------------
>
> It would be nice to have a citation about why current implementations of
> address pseudonyms are insufficient for the purposes described in
> section 5.1.2.
>
> ---------------------------------------------
>
> It seems to me that the discussion in section 5.1.3 lives almost
> entirely in solution space.
>
> ---------------------------------------------
>
> In section 5.1.4, it was not clear to me about why Neighbor Discovery
> really needs to be extended into being a routing protocol.
>
> --------------------------------------------
>
> It seems to me that section 5.3 really belongs in section 6. Also, even
> a perfectly authorized and legitimate vehicle might be persuaded somehow
> to run malicious applications.  I think that this point is not
> sufficiently covered in the current text.
>
> Regards,
> Charlie P.
> Blue Sky Networks
>
>
>
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its
>


-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: [phone]
Email: [e-mail], [e-mail]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>