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

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

Carlos,
Great!

Sure you soon in Singapore.

Thanks.

Paul

On Thu, Nov 7, 2019 at 9:08 AM CARLOS JESUS BERNARDOS CANO <[e-mail]>
wrote:

> 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
>
>

-- 
===========================
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>