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

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

Hi Paul,

I have to do my review first. You'll have it by the Singapore meeting so we
can discuss there.

Thanks,

Carlos

On Wed, Nov 6, 2019 at 3:29 AM Mr. Jaehoon Paul Jeong <
[e-mail]> wrote:

> Hi Carlos,
> I am wondering what next steps our IPWAVE PS draft will take.
> If you are satisfied with my revision, could you do the WG Last Call on
> this version?
> https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-12
>
> Thanks.
>
> Best Regards,
> Paul
>
> On Fri, Oct 4, 2019 at 1:19 AM CARLOS JESUS BERNARDOS CANO <
> [e-mail]> wrote:
>
>> Hi Paul,
>>
>> Thanks for the revision. I'll review the document and let you know about
>> next steps.
>>
>> Carlos
>>
>> On Thu, Oct 3, 2019 at 12:12 PM Mr. Jaehoon Paul Jeong <
>> [e-mail]> wrote:
>>
>>> Hi Russ and Carlos,
>>> I have submitted the revision (-12) of IPWAVE PS draft as you know.
>>> https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-12
>>>
>>> Will you review the revision and move forward to the WGLC or wait for
>>> Charlie's another review?
>>>
>>> BTW, my SKKU team are working for IETF-106 IPWAVE Hackathon Project to
>>> show the data delivery
>>> between two 802.11-OCB embedded systems such as the text and web-camera
>>> video.
>>> We will work to demonstrate the IPv6 over 802.11-OCB.
>>> This is a collaboration work with Hyundai Motors.
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>> Paul
>>>
>>> ---------- Forwarded message ---------
>>> From: Mr. Jaehoon Paul Jeong <[e-mail]>
>>> Date: Thu, Oct 3, 2019 at 6:57 PM
>>> Subject: Re: [ipwave] Some review comments for
>>> draft-ietf-ipwave-vehicular-networking-11
>>> To: Charlie Perkins <[e-mail]>
>>> Cc: [e-mail] <[e-mail]>, Sandra Cespedes <
>>> [e-mail]>, <[e-mail]>, 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>
>>>
>>>
>>> --
>>> ===========================
>>> 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>
>>>
>>
>>
>> --
>> Special Issue "Beyond 5G Evolution":
>> https://www.mdpi.com/journal/electronics/special_issues/beyond_5g
>>
>>
>
> --
> ===========================
> 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>
>


-- 
Special Issue "Beyond 5G Evolution":
https://www.mdpi.com/journal/electronics/special_issues/beyond_5g