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

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

Hi Carlos,
Did you have a change to check my revision?

We need to go forward.

Thanks.

Best Regards,
Paul

On Tue, Jan 7, 2020 at 2:48 AM Mr. Jaehoon Paul Jeong <
[e-mail]> wrote:

> Hi Carlos and Russ,
> Here is the revision -13 of our IPWAVE PS draft according to Carlos'
> comments:
> https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-13
>
> I attach the revision letter to show how I addressed comments in the
> revision.
>
> If you are satisfied with my revision, please let me know.
>
> I will ask five reviewers to review this version for WGLC.
>
> Thanks.
>
> Best Regards,
> Paul
>
> On Sat, Nov 16, 2019 at 2:06 PM CARLOS JESUS BERNARDOS CANO <
> [e-mail]> wrote:
>
>> Hi Paul,
>>
>> I’ve reviewed the draft. I think the draft is in better shape than last
>> time I checked, but it is not yet ready. I’m afraid I have quite some
>> comments. Please see below:
>>
>> - I think the title (and the text in many parts of the document) should
>> be changed to refer to IPv6, instead of IP, as the document (and the WG) is
>> IPv6 specific. Another example: we should not mention Mobile IPv4 in the
>> document (as done currently in page 2).
>>
>> - Page 4 (but also later in different parts of the doc): Mobility Anchor
>> (MA): is this term coined somewhere you can reference? It is mentioned as a
>> component of a vehicular architecture, but it is not discussed why, not
>> even why an IPv6 mobility solution is needed in a vehicular scenario. It
>> might seem like straightforward, but you need to present that need.
>>
>> - Page 4: the terms OBU and RSU should be aligned with what the basic OCB
>> draft uses (IP-OBU and IP-RSU) and probably refer to that document. Besides
>> I understand OBU and RSUs as single IP devices, not set of nodes as the
>> document currently defines.
>>
>> - Page 5: V2I2P and V2I2V deserve additional explanation.
>>
>> - The use cases should serve not only to present areas where vehicular
>> networks can be used, but also to support requirements for IPv6 in such
>> environments. Current text does not help much on identifying requirements.
>>
>> - Section 4 should introduce a generic vision of what vehicular networks
>> architectures might look like, again to help the purpose of identifying
>> requirements. I’m afraid current section is making quite a lot of
>> assumptions about how the architecture looks like without properly
>> justifying them. Examples are: the presence of a Mobility Anchor, using
>> Ethernet links to interconnect RSUs or the subnet/prefix model. I think the
>> proposed architecture might make sense, but it is not THE architecture (if
>> it was, we should be referring to the doc where it is specified), but an
>> example of potential architecture. It’d be right to present an exemplary
>> architecture to support the use cases and problem statement, but the
>> document should clearly state that.
>>
>> - Related to the former, the document assumes that IPv6 mobility is a key
>> requirement. While I don’t disagree with that, the document should support
>> that assumption backed up by requirements from use cases.
>>
>> - Figure 2: the vision of the RSU having multiple routers, hosts, etc,
>> inside... where does it come from? It’s new to me. Similarly, on the
>> vehicle I’d expect Router1 to be an IP-OBU. Related to this comment, first
>> paragraph of Section 4.2 talks about the RSU architecture without providing
>> any reference. Why is it needed to have a DNS server internally? I don’t
>> see why this is needed or specific to vehicular networks.
>>
>> - Page 12: all the discussion about the need for exchanging prefix
>> information comes out of the blue, there is no proper discussion why this
>> is a requirement. And then the document gets into mentioning an example of
>> solution for this, which is something that should be avoided (this document
>> is not about solution space), unless we were analyzing different approaches
>> to solve a given problem.
>>
>> - Page 12: as mentioned above, I don’t see why we need the DNS discussion.
>>
>> - Figure 2 makes assumptions on network topology and subnetting that is
>> not explained.
>>
>> - Page 14: the discussion on prevention of false reports of accidents is
>> application-layer specific, not IPv6 specific, and therefore it is not in
>> the scope of this document.
>>
>> - Section 5.1 is a critical one (actually the whole section 5) and I
>> think it needs significant work. I’d discuss link model issues before going
>> into neighbor discovery protocol specific issues. Current text seem to have
>> already a solution in mind when describing the issues, while what it should
>> do is derive requirements, and explain why current solutions are not
>> sufficient. For example, it should not start saying that DAD and ND-related
>> parameters need to be extended before introducing why current DAD and ND is
>> not sufficient.
>>
>> - All the discussion on ND timers is again very much solution specific
>> and should be avoided. And the discussion about NHTSA and the collision is
>> also not appropriate, as one thing is the delay at application layer and a
>> different thing is the timers used for ND.
>>
>> - Page 16 and page 17: the text assumes a prefix model for a vehicular
>> network that is not properly introduced and justified. Issues cannot be
>> derived from the use of a prefix model that is not well introduced.
>>
>> - Page 18: the discussion about notifying changes on the IP address
>> should be removed if it is assumed that there is an IPv6 mobility protocol
>> in place (which seems to be the case) as this is taken care by it.
>>
>> - Section 5.1.3: again it goes too much into solution space without
>> presenting the scenario and the issues. This document is not about talking
>> solutions.
>>
>> - Section 5.2: same comment as before. Solution space specifics should be
>> removed.
>>
>> - Section 6 needs significant work as well. First, I’d like to have some
>> kind of structure in terms of presenting the security and privacy issues
>> that are specific to the vehicular environment. And then, we need to have a
>> list of issues/requirements instead of again going too much into solution
>> space.
>>
>> We can sit together in Singapore to discuss about how to address these
>> comments.
>>
>> Thanks,
>>
>> Carlos
>>
>> On Thu, 7 Nov 2019 at 08:30, Mr. Jaehoon Paul Jeong <
>> [e-mail]> wrote:
>>
>>> 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>
>>>
>> --
>> Sent from a mobile device, please excuse any brevity or typing errors.
>>
>
>

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