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

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

Hi Carlos,
Thanks for your valuable comments.
I will work on the revision with your comments.

Best Regards,
Paul

On Mon, Feb 24, 2020 at 5:16 PM CARLOS JESUS BERNARDOS CANO <[e-mail]>
wrote:

> Hi Paul,
>
> I've checked version -13, and it has certainly improved compared to -12.
> However, there are still comments that have not been completely addressed.
> Please find below the main ones I still have.
>
> - 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. This
> comment still applies. The term MA is not a standard one and the need for
> it is not properly explained.
>
> - The use cases section still does not help much on identifying
> requirements. Vehicular Neighbor Discovery (VND), Vehicular Mobility
> Management (VMM), and Vehicular Security and Privacy (VSP) in vehicular
> networks appear as “new” functions, but what the use cases should reflect
> is the gaps of current IPv6 mechanisms that need to be addressed. We don’t
> need to define new “vehicular-specific” functions, but rather to identify
> the extensions to existing protocols that vehicular scenarios bring.
>
> - Section 4 should introduce a generic vision of what vehicular networks
> architectures might look like, again to help the purpose of identifying
> requirements. Current section is still making quite a lot of assumptions
> about how the architecture looks like without properly justifying them.The
> text now mentions that it is “an exemplary architecture” to support the use
> cases, which might be OK, but I’m afraid it might raise many questions on
> why we don’t try to use existing known architectures and pinpointing where
> there are gaps.
>
> - “For an IPv6 communication between an IP-OBU and an IP-RSU or between
> two neighboring IP-OBUs, network parameters need to be shared among them,
> such as MAC layer and IPv6 layer information.  The MAC layer information
> includes wireless link layer parameters, transmission power level, the MAC
> address of an external network interface for the internetworking with
> another IP-OBU or IP-RSU.  The IPv6 layer information includes the IPv6
> address and network prefix of an external network interface for the
> internetworking with another IP-
> OBU or IP-RSU.” --> I still don’t see a clear justification on the need
> for exchanging prefix information... I'm not judging if this is needed or
> not, just saying that the draft does not really backs that need.
>
> - There are multiple assumptions in the draft about the way IPv6
> addressing will be used (e.g., multiple vehicles sharing a prefix in Figure
> 1, control and data separation, certain network topologies in Figure 2)
> that are not explained. Why those assumptions and not others? Any reference
> supporting them? The document kind of assumes a prefix model that is not
> properly introduced. Issues cannot be derived from the use of a prefix
> model that is not well introduced.
>
> - All the discussion on ND timers is again very much solution specific and
> should be avoided.
>
> Thanks,
>
> Carlos
>
> On Mon, Jan 6, 2020 at 6:49 PM 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>