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

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

Carlos,
Thanks for your detailed comments.

I will prepare for the revision with your comments early next week.
Could we have a meeting to review my new revision, and revise it for WGLC
before the end of this IETF-106 meeting?

I will be available next Tuesday and Wednesday, so please let me know your
available time.

Thanks.

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>