From nobody Mon Feb 24 00:16:12 2020 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A699E3A0868 for ; Mon, 24 Feb 2020 00:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_BlGj8bm_76 for ; Mon, 24 Feb 2020 00:16:05 -0800 (PST) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C27D3A08A6 for ; Mon, 24 Feb 2020 00:16:05 -0800 (PST) Received: by mail-ed1-x535.google.com with SMTP id v28so10822403edw.12 for ; Mon, 24 Feb 2020 00:16:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D8NBj8+36a0xzzbDKNb93gPfDQEnZvpwU0X03okjWCM=; b=OYFF+7I7UYGoGidk/9DaLwFbI92nmuy8vi3dK4XAfFwoUXMOBy/BMsgTRVSvLc6MaO ByLMg3+ZItFtT69ctXBYb/RD6g2XGuoSWPGRjm1F9IgaYNQPRlrTUYwM4Q1sPbjHrENU LKBU5wPrV8sVhbtRyclZl65EcOgjjCnrR4d1S1yjG2SDjAgAropA6oTsLCZ5pKmVNtjr PwB0COrHfHgjshfmxiNxgAU2A+bevpxrk/GHW9qmkoeEpXOVqX5Ao3dIz6aJPhhLO74J Fylrd9bYlWc9dJt9e8cGFBE2AqaoDX+V1U1CmQvet2/z5PZuPtWV4XaPN9TeaoFWQtkp 30qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D8NBj8+36a0xzzbDKNb93gPfDQEnZvpwU0X03okjWCM=; b=aOLe/vKbJIIwJ/pi+oba1+dk8GODP9YvzfCH4cHQ3kesgXrhGc4GA63BtRQ6AipCLo PkMmmnROYPLwuQMCMOby3u7/5M9OyQBko5/g+XQngv0uhEvEf5488sPSIkCVAooLfe2l m9aQFR08xLRLropjAZbuufVtj3m3oODiMMMjT9DRDD7IiMeSIJBcOlQQPuHCKPTlGrx8 IYhP7wJWgH4uNSX3rlyaY+LNaV3YYPmldejyG+kknbRTHygDTu/w5Q1wM0WU1KqzM/T5 fUPt9Urg44+B2FrkbBrRW2C73PUBiwJvfBr/Q8W42edlrEq3sLHv70HD93578DP3w9UD xQ/Q== X-Gm-Message-State: APjAAAU4ypNG8Oq+pYYaoNunShswvTr9fN0nsburGQY56QJKI1p9XmwH d9qiw3RSh6hBZ+YavvD1zwAV4z4enDcC1t5sthW1kW4imjcA6Q== X-Google-Smtp-Source: APXvYqxkSTY+TEfa2dwe7Ozozd/Y7YgzX2PBXifJMjZMP+yUaaHPgWx5qes3pXMMd3Lx+ZX7Be04LbiCXpaJXxhV4Rc= X-Received: by 2002:a17:906:2653:: with SMTP id i19mr44361393ejc.287.1582532163386; Mon, 24 Feb 2020 00:16:03 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: CARLOS JESUS BERNARDOS CANO Date: Mon, 24 Feb 2020 09:15:47 +0100 Message-ID: To: "Mr. Jaehoon Paul Jeong" Cc: Russ Housley , Suresh Krishnan , its , skku-iotlab-members , =?UTF-8?B?6rmA7Kad7J28IOq4gOuhnOuyjFImROuniOyKpO2EsA==?= , =?UTF-8?B?6rmA7KCV7ZiEIO2VmeyDnQ==?= Content-Type: multipart/alternative; boundary="00000000000071de17059f4dfbd3" Archived-At: Subject: Re: [ipwave] Some review comments for draft-ietf-ipwave-vehicular-networking-11 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 08:16:11 -0000 --00000000000071de17059f4dfbd3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =E2=80=9Cnew=E2=80=9D functions, but what the use cases = should reflect is the gaps of current IPv6 mechanisms that need to be addressed. We don=E2= =80=99t need to define new =E2=80=9Cvehicular-specific=E2=80=9D functions, but rath= er 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 =E2=80=9Can exemplary architecture=E2=80=9D to= support the use cases, which might be OK, but I=E2=80=99m afraid it might raise many questi= ons on why we don=E2=80=99t try to use existing known architectures and pinpointin= g where there are gaps. - =E2=80=9CFor an IPv6 communication between an IP-OBU and an IP-RSU or bet= ween 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.=E2=80=9D --> I still don=E2=80=99t 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 < jaehoon.paul@gmail.com> 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 < > cjbc@it.uc3m.es> wrote: > >> Hi Paul, >> >> I=E2=80=99ve reviewed the draft. I think the draft is in better shape th= an last >> time I checked, but it is not yet ready. I=E2=80=99m 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 a= s 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 OC= B >> draft uses (IP-OBU and IP-RSU) and probably refer to that document. Besi= des >> 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 requirement= s. >> >> - Section 4 should introduce a generic vision of what vehicular networks >> architectures might look like, again to help the purpose of identifying >> requirements. I=E2=80=99m afraid current section is making quite a lot o= f >> 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=E2=80=99d be right to present an e= xemplary >> 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 ke= y >> requirement. While I don=E2=80=99t disagree with that, the document shou= ld 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=E2=80=99s new to me. Similarly, on= the >> vehicle I=E2=80=99d expect Router1 to be an IP-OBU. Related to this comm= ent, first >> paragraph of Section 4.2 talks about the RSU architecture without provid= ing >> any reference. Why is it needed to have a DNS server internally? I don= =E2=80=99t >> 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 thi= s >> is a requirement. And then the document gets into mentioning an example = of >> solution for this, which is something that should be avoided (this docum= ent >> is not about solution space), unless we were analyzing different approac= hes >> to solve a given problem. >> >> - Page 12: as mentioned above, I don=E2=80=99t see why we need the DNS d= iscussion. >> >> - 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 i= n >> 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=E2=80=99d discuss link model issues b= efore going >> into neighbor discovery protocol specific issues. Current text seem to h= ave >> already a solution in mind when describing the issues, while what it sho= uld >> do is derive requirements, and explain why current solutions are not >> sufficient. For example, it should not start saying that DAD and ND-rela= ted >> 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 protoc= ol >> 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 talki= ng >> solutions. >> >> - Section 5.2: same comment as before. Solution space specifics should b= e >> removed. >> >> - Section 6 needs significant work as well. First, I=E2=80=99d like to h= ave 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 hav= e a >> list of issues/requirements instead of again going too much into solutio= n >> 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 < >> jaehoon.paul@gmail.com> wrote: >> >>> Carlos, >>> Great! >>> >>> Sure you soon in Singapore. >>> >>> Thanks. >>> >>> Paul >>> >>> On Thu, Nov 7, 2019 at 9:08 AM CARLOS JESUS BERNARDOS CANO < >>> cjbc@it.uc3m.es> 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 < >>>> jaehoon.paul@gmail.com> 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 < >>>>> cjbc@it.uc3m.es> 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 < >>>>>> jaehoon.paul@gmail.com> 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 >>>>>>> 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 >>>>>>> Cc: its@ietf.org , Sandra Cespedes < >>>>>>> scespedes@ing.uchile.cl>, , Mr. >>>>>>> Jaehoon Paul Jeong >>>>>>> >>>>>>> >>>>>>> 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 show= n >>>>>>> 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 < >>>>>>> charles.perkins@earthlink.net> 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 miser= y >>>>>>>> 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 establis= h >>>>>>>> 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 clai= m >>>>>>>> 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 >>>>>>>> its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>>>> Mr. Jaehoon (Paul) Jeong, Ph.D. >>>>>>> Associate Professor >>>>>>> Department of Software >>>>>>> Sungkyunkwan University >>>>>>> Office: +82-31-299-4957 >>>>>>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >>>>>>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>>>> Mr. Jaehoon (Paul) Jeong, Ph.D. >>>>>>> Associate Professor >>>>>>> Department of Software >>>>>>> Sungkyunkwan University >>>>>>> Office: +82-31-299-4957 >>>>>>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >>>>>>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Special Issue "Beyond 5G Evolution": >>>>>> https://www.mdpi.com/journal/electronics/special_issues/beyond_5g >>>>>> >>>>>> >>>>> >>>>> -- >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>>> Mr. Jaehoon (Paul) Jeong, Ph.D. >>>>> Associate Professor >>>>> Department of Software >>>>> Sungkyunkwan University >>>>> Office: +82-31-299-4957 >>>>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >>>>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>> >>>>> >>>> >>>> >>>> -- >>>> Special Issue "Beyond 5G Evolution": >>>> https://www.mdpi.com/journal/electronics/special_issues/beyond_5g >>>> >>>> >>> >>> -- >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>> Mr. Jaehoon (Paul) Jeong, Ph.D. >>> Associate Professor >>> Department of Software >>> Sungkyunkwan University >>> Office: +82-31-299-4957 >>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >>> >>> >> -- >> Sent from a mobile device, please excuse any brevity or typing errors. >> > > --00000000000071de17059f4dfbd3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Paul,

I've checked version -13, = and it has certainly improved compared to -12. However, there are still com= ments that have not been completely addressed. Please find below the main o= nes I still have.

- Page 4 (but also later in diff= erent parts of the doc): Mobility Anchor (MA): is this term coined somewher= e you can reference? It is mentioned as a component of a vehicular architec= ture, but it is not discussed why, not even why an IPv6 mobility solution i= s needed in a vehicular scenario. It might seem like straightforward, but y= ou need to present that need. This comment still applies. The term MA is no= t a standard one and the need for it is not properly explained.

- Th= e use cases section still does not help much on identifying requirements. V= ehicular Neighbor Discovery (VND), Vehicular Mobility Management (VMM), and= Vehicular Security and Privacy (VSP) in vehicular networks appear as =E2= =80=9Cnew=E2=80=9D functions, but what the use cases should reflect is the = gaps of current IPv6 mechanisms that need to be addressed. We don=E2=80=99t= need to define new =E2=80=9Cvehicular-specific=E2=80=9D functions, but rat= her to identify the extensions to existing protocols that vehicular scenari= os bring.

- Section 4 should introduce a generic vision of what vehi= cular networks architectures might look like, again to help the purpose of = identifying requirements. Current section is still making quite a lot of as= sumptions about how the architecture looks like without properly justifying= them.The text now mentions that it is =E2=80=9Can exemplary architecture= =E2=80=9D to support the use cases, which might be OK, but I=E2=80=99m afra= id it might raise many questions on why we don=E2=80=99t try to use existin= g known architectures and pinpointing where there are gaps.

- =E2=80= =9CFor 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.=C2=A0 The MAC layer information i= ncludes wireless link layer parameters, transmission power level, the MAC a= ddress of an external network interface for the internetworking with anothe= r IP-OBU or IP-RSU.=C2=A0 The IPv6 layer information includes the IPv6 addr= ess and network prefix of an external network interface for the internetwor= king with another IP-
OBU or IP-RSU.=E2=80=9D --> I still don=E2=80= =99t see a clear justification on the need for exchanging prefix informatio= n... I'm not judging if this is needed or not, just saying that the dra= ft does not really backs that need.

- There are multiple assumptions= in the draft about the way IPv6 addressing will be used (e.g., multiple ve= hicles sharing a prefix in Figure 1, control and data separation, certain n= etwork topologies in Figure 2) that are not explained. Why those assumption= s and not others? Any reference supporting them? The document kind of assum= es 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 t= he discussion on ND timers is again very much solution specific and should = be avoided.

Thanks,

C= arlos

On Mon, Jan 6, 2020 at 6:49 PM Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> wrote:
=
Hi Carlos and Russ,
Here is the revision -13 of our IP= WAVE PS draft according to Carlos' comments:

I attach the revision lett= er 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 &l= t;cjbc@it.uc3m.es&= gt; wrote:
=
Hi Paul,

I=E2=80=99ve reviewed the draft. I think the draft is in better s= hape than last time I checked, but it is not yet ready. I=E2=80=99m afraid = I have quite some comments. Please see below:

- I think the title (and the text in many parts of th= e document) should be changed to refer to IPv6, instead of IP, as the docum= ent (and the WG) is IPv6 specific. Another example: we should not mention M= obile IPv4 in the document (as done currently in page 2).

- Page 4 (but also later in different par= ts 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 t= o present that need.

- P= age 4: the terms OBU and RSU should be aligned with what the basic OCB draf= t uses (IP-OBU and IP-RSU) and probably refer to that document. Besides I u= nderstand OBU and RSUs as single IP devices, not set of nodes as the docume= nt currently defines.

- = Page 5: V2I2P and V2I2V deserve additional explanation.

- The use cases should serve not only to pr= esent areas where vehicular networks can be used, but also to support requi= rements for IPv6 in such environments. Current text does not help much on i= dentifying requirements.

- Section 4 should introduce a generic vision of what vehicular networks a= rchitectures might look like, again to help the purpose of identifying requ= irements. I=E2=80=99m afraid current section is making quite a lot of assum= ptions about how the architecture looks like without properly justifying th= em. Examples are: the presence of a Mobility Anchor, using Ethernet links t= o interconnect RSUs or the subnet/prefix model. I think the proposed archit= ecture might make sense, but it is not THE architecture (if it was, we shou= ld be referring to the doc where it is specified), but an example of potent= ial architecture. It=E2=80=99d be right to present an exemplary architectur= e to support the use cases and problem statement, but the document should c= learly state that.

- Rel= ated to the former, the document assumes that IPv6 mobility is a key requir= ement. While I don=E2=80=99t disagree with that, the document should suppor= t that assumption backed up by requirements from use cases.

- Figure 2: the vision of the RSU hav= ing multiple routers, hosts, etc, inside... where does it come from? It=E2= =80=99s new to me. Similarly, on the vehicle I=E2=80=99d 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 need= ed to have a DNS server internally? I don=E2=80=99t see why this is needed = or specific to vehicular networks.

- Page 12: all the discussion about the need for exchanging pref= ix information comes out of the blue, there is no proper discussion why thi= s is a requirement. And then the document gets into mentioning an example o= f solution for this, which is something that should be avoided (this docume= nt is not about solution space), unless we were analyzing different approac= hes to solve a given problem.

- Page 12: as mentioned above, I don=E2=80=99t see why we need the DN= S discussion.

- Figure 2= makes assumptions on network topology and subnetting that is not explained= .

- Page 14: the discuss= ion on prevention of false reports of accidents is application-layer specif= ic, not IPv6 specific, and therefore it is not in the scope of this documen= t.

- Section 5.1 is a cr= itical one (actually the whole section 5) and I think it needs significant = work. I=E2=80=99d discuss link model issues before going into neighbor disc= overy protocol specific issues. Current text seem to have already a solutio= n in mind when describing the issues, while what it should do is derive req= uirements, and explain why current solutions are not sufficient. For exampl= e, 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 t= imers is again very much solution specific and should be avoided. And the d= iscussion about NHTSA and the collision is also not appropriate, as one thi= ng is the delay at application layer and a different thing is the timers us= ed for ND.

- Page 16 and= page 17: the text assumes a prefix model for a vehicular network that is n= ot 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 o= n the IP address should be removed if it is assumed that there is an IPv6 m= obility protocol in place (which seems to be the case) as this is taken car= e by it.

- Section 5.1.3= : again it goes too much into solution space without presenting the scenari= o and the issues. This document is not about talking solutions.

- Section 5.2: same comment as befo= re. Solution space specifics should be removed.

=
- Section 6 needs significant work as well. First, = I=E2=80=99d 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 g= oing too much into solution space.

We can sit together in Singapore to discuss about how to address= these comments.

Thanks,=

Carlos

On Thu, 7 No= v 2019 at 08:30, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> wrote:
Carlos,=
Great!

Sure you soon in Singapore.
=
Thanks.

Paul=

On Thu, Nov 7, 2019 at 9:08 AM CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> wrot= e:
Hi Paul,

I have to do my review first. You'll ha= ve 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 <jaehoon.paul@gmail.com> wrote:
Hi Carlos,
I = am wondering what next steps our IPWAVE PS draft will take.
If yo= u are satisfied=C2=A0with my revision, could you do the WG Last Call on thi= s version?

=
Thanks.

Best Regards,
Paul

On Fri, Oct 4, 2019 at 1:19 AM CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> wrote= :
Hi Paul,

Thanks for the revision. I'll review the= document and let you know about next=C2=A0steps.

= Carlos

On Thu, Oct 3, 2019 at 12:12 PM Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.= com> wrote:
Hi Russ and Carlos,
I have submitted the revision (= -12) of IPWAVE PS draft as you know.

Will you review the revision and mov= e forward to the WGLC or wait for Charlie's another review?
<= br>
BTW, my SKKU team are working for IETF-106 IPWAVE Hackathon P= roject to show the data delivery=C2=A0
between two 802.11-OCB emb= edded 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.

<= /div>
Best Regards,
Paul

---------- Forwarded message ---------<= br>From: Mr. Jaehoon Paul J= eong <jaehoon.paul@gmail.com>
Date: Thu, O= ct 3, 2019 at 6:57 PM
Subject: Re: [ipwave] Some review comments for dra= ft-ietf-ipwave-vehicular-networking-11
To: Charlie Perkins <charles.perkins= @earthlink.net>
Cc: its@ietf.org <its@ietf.org>, Sandra Cespedes <scespedes@ing.uchile.cl>, <skku-iotlab-memb= ers@skku.edu>, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com>
<= br>
Hi Charlie,
I have addressed your comments belo= w and your editorial changes, submitting the revision:

Also, I addressed Sa= ndra's comments about the definition of an RSU as an edge computing sys= tem
having multiple routers and servers (including DNS server), a= s shown in Figure 2.

I attach the revision letter = for your double-checking.

Thanks for your valuable= and constructive=C2=A0comments.

Best Regards,
Paul


On Mon, Sep 16, 2019 at 1:08 PM Charlie Per= kins <charles.perkins@earthlink.net> wrote:
Hello folks,

I made a review of the document
draft-ietf-ipwave-vehicular-networking-11.txt.=C2=A0 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.=C2=A0 Here is some text that I devised for that purpose,=
which could fit naturally at the beginning of Section 5.

=C2=A0=C2=A0=C2=A0 In order to specify protocols using the abovementioned a= rchitecture
=C2=A0=C2=A0=C2=A0 for VANETs, IPv6 core protocols have to be adapted to ov= ercome certain
=C2=A0=C2=A0=C2=A0 challenging aspects of vehicular networking.=C2=A0 Since= the vehicles are
=C2=A0=C2=A0=C2=A0 likely to be moving at great speed, protocol exchanges n= eed to be
=C2=A0=C2=A0=C2=A0 completed in a time relatively small compared to the lif= etime of a
=C2=A0=C2=A0=C2=A0 link between a vehicle and an RSU, or between two vehicl= es.=C2=A0 This
=C2=A0=C2=A0=C2=A0 has a major impact on IPv6 neighbor discovery. Mobility = management
=C2=A0=C2=A0=C2=A0 is also vulnerable to disconnections that occur before t= he completion
=C2=A0=C2=A0=C2=A0 of identify verification and tunnel management.=C2=A0 Th= is is especially
=C2=A0=C2=A0=C2=A0 true given the unreliable nature of wireless communicati= ons.=C2=A0 Finally,
=C2=A0=C2=A0=C2=A0 and perhaps most importantly, proper authorization for v= ehicular
protocol
=C2=A0=C2=A0=C2=A0 messages must be assured in order to prevent false repor= ts of accidents
=C2=A0=C2=A0=C2=A0 or other mishaps on the road, which would cause horrific= misery in
=C2=A0=C2=A0=C2=A0 modern urban environments.

----------------------------------------------

Although geographic routing is mentioned early in the document, it is
not discussed in later sections.=C2=A0 This makes me wonder whether the ear= ly
mention is really relevant.=C2=A0 In fact, for fast moving objects, I think=
it is already questionable whether geographic routing has value.=C2=A0 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.=C2=A0 If geographic algorith= ms
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" an= d 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.=C2=A0 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).=C2=A0 But =
anyway some care has to be taken so that the proposed architecture
doesn't otherwise place strong limits on acceptable solutions.=C2=A0 So= , for
example, in section 4.1, it needs to be clear whether or not a single
subnet prefix can span multiple vehicles.=C2=A0 This is an important choice= .

---------------------------------------------

In section 5.1.1., a claim is made that a new link model is required.=C2=A0= I
think this is a very ambitious claim, and I am not even quite sure what is meant.=C2=A0 IPv6 already provides for "on-link" and "off= -link" variations
on subnet operation.=C2=A0 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.=C2=A0 I think that this point is not
sufficiently covered in the current text.

Regards,
Charlie P.
Blue Sky Networks



_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate ProfessorDepartment of Software
Sungkyunkwan University
Office: +82-31-299-4= 957
Email: j= aehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal = Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<= /div>


--
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department= of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email= : jaehoon.paul@= gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<= /div>


--


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate ProfessorDepartment of Software
Sungkyunkwan University
Office: +82-31-299-4= 957
Email: j= aehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal = Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<= /div>


--


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate ProfessorDepartment of Software
Sungkyunkwan University
Office: +82-31-299-4= 957
Email: j= aehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal = Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<= /div>
--
Sent from a mobile device,= please excuse any brevity or typing errors.
=

--00000000000071de17059f4dfbd3-- From nobody Mon Feb 24 00:36:11 2020 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798283A08DC for ; Mon, 24 Feb 2020 00:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyODgUOUiHQl for ; Mon, 24 Feb 2020 00:36:06 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 125723A08DA for ; Mon, 24 Feb 2020 00:36:05 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id o15so9091398ljg.6 for ; Mon, 24 Feb 2020 00:36:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qM6R2xGQdKjTFh4jXjULF0wI0VR7lHqPGhqKaDYAh9c=; b=VN34h46/dwCHQ2eNvL3kfeTXt54G6pWGhpG0wM5QvRaEPOxB/tKtu1zYLEEHQxf3vp +b7webPAUHD6gVUrqF+JnppTFDc6VUwvmYmxoe8YGC+tzG8bObiCLVSdstE09037ojsm 5ZKLOt3Jp8meEI4V+h0k1YqKk0aXjGROyNPKQGV1YCJlv9pXHAubNrkwfbaxciJGZW+y Nhz2RLPMJ+fMDbDNvHXhnZhJOddZP2QttcZ2o15l0lEI+mg0vA36NuxB0Xu8GeRht12x NJBwqPm5Vr5nSaSt9/jV7nobzdiy1t3nWtnu/zzwktapn1Oct8pBV/rMCT1RMirlx8M7 EJUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qM6R2xGQdKjTFh4jXjULF0wI0VR7lHqPGhqKaDYAh9c=; b=AsEC8FGnWKaYLqU58k+3X3io8+ygt3SxcHPB8kvSD3nd/AVtFunqHlNqPIUSU0wf/F k2AyJ9/nA1tLR8BHytNCuJdp+zTHcdGbCJE66GfBlLlRWPBWkQZz6KJMCIIpkI9AeyLG NB+4Rz5T9OwIt14tYU+1s2720jgmpSkc4ah9fN0SBmWgyVlwXaoW2FbjNO2ffG3wlBl9 BMJB+Qin0Q9jyTbSqoF2dMExPmuyqPd0bfuPIG4vmyeg2skMAAMn12rUaAWZW8PdAN1k KYWzSl1N8Jb5iEfTY1rDMKTFXcVAm1wXIpNeXkrd0EROG/7WdGqCePVOjm8H5TyIchug 2KjA== X-Gm-Message-State: APjAAAUoup7aZszUJ6WkCNFiNs1PhMMzOb/Sg3IyCQHTAkJeqe0bElYm CKfkdo9wKaso30YMKX8BWEnbQb6jrlQCKORiQ3Q= X-Google-Smtp-Source: APXvYqwiyACu2AP2Sm6BFTZ3ZjrLfVTkG1Qthme5AemsNuNSrvqC3hTVvUyYa12Phw+9UoMEbYkvPaMRGPGM4XUR/z0= X-Received: by 2002:a05:651c:327:: with SMTP id b7mr5253437ljp.22.1582533363895; Mon, 24 Feb 2020 00:36:03 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Mr. Jaehoon Paul Jeong" Date: Mon, 24 Feb 2020 17:35:51 +0900 Message-ID: To: CARLOS JESUS BERNARDOS CANO Cc: Russ Housley , Suresh Krishnan , its , skku-iotlab-members , =?UTF-8?B?6rmA7Kad7J28IOq4gOuhnOuyjFImROuniOyKpO2EsA==?= , =?UTF-8?B?6rmA7KCV7ZiEIO2VmeyDnQ==?= , "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="000000000000001163059f4e43db" Archived-At: Subject: Re: [ipwave] Some review comments for draft-ietf-ipwave-vehicular-networking-11 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 08:36:11 -0000 --000000000000001163059f4e43db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 =E2=80=9Cnew=E2=80=9D functions, but what the use case= s should reflect > is the gaps of current IPv6 mechanisms that need to be addressed. We don= =E2=80=99t > need to define new =E2=80=9Cvehicular-specific=E2=80=9D functions, but ra= ther 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.Th= e > text now mentions that it is =E2=80=9Can exemplary architecture=E2=80=9D = to support the use > cases, which might be OK, but I=E2=80=99m afraid it might raise many ques= tions on > why we don=E2=80=99t try to use existing known architectures and pinpoint= ing where > there are gaps. > > - =E2=80=9CFor an IPv6 communication between an IP-OBU and an IP-RSU or b= etween > 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 MA= C > 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.=E2=80=9D --> I still don=E2=80=99t see a clear justificati= on 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 Figu= re > 1, control and data separation, certain network topologies in Figure 2) > that are not explained. Why those assumptions and not others? Any referen= ce > 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 an= d > should be avoided. > > Thanks, > > Carlos > > On Mon, Jan 6, 2020 at 6:49 PM Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> 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 < >> cjbc@it.uc3m.es> wrote: >> >>> Hi Paul, >>> >>> I=E2=80=99ve reviewed the draft. I think the draft is in better shape t= han last >>> time I checked, but it is not yet ready. I=E2=80=99m afraid I have quit= e 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 th= e >>> document (as done currently in page 2). >>> >>> - Page 4 (but also later in different parts of the doc): Mobility Ancho= r >>> (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. I= t >>> 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 node= s 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 requiremen= ts. >>> >>> - Section 4 should introduce a generic vision of what vehicular network= s >>> architectures might look like, again to help the purpose of identifying >>> requirements. I=E2=80=99m 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 a= n >>> example of potential architecture. It=E2=80=99d 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=E2=80=99t 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=E2=80=99s new to me. Similarly, o= n the >>> vehicle I=E2=80=99d expect Router1 to be an IP-OBU. Related to this com= ment, first >>> paragraph of Section 4.2 talks about the RSU architecture without provi= ding >>> any reference. Why is it needed to have a DNS server internally? I don= =E2=80=99t >>> 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 th= is >>> is a requirement. And then the document gets into mentioning an example= of >>> solution for this, which is something that should be avoided (this docu= ment >>> is not about solution space), unless we were analyzing different approa= ches >>> to solve a given problem. >>> >>> - Page 12: as mentioned above, I don=E2=80=99t 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 i= s >>> 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=E2=80=99d 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 sh= ould >>> do is derive requirements, and explain why current solutions are not >>> sufficient. For example, it should not start saying that DAD and ND-rel= ated >>> parameters need to be extended before introducing why current DAD and N= D 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 an= d 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 proto= col >>> 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 talk= ing >>> solutions. >>> >>> - Section 5.2: same comment as before. Solution space specifics should >>> be removed. >>> >>> - Section 6 needs significant work as well. First, I=E2=80=99d like to = have some >>> kind of structure in terms of presenting the security and privacy issue= s >>> that are specific to the vehicular environment. And then, we need to ha= ve a >>> list of issues/requirements instead of again going too much into soluti= on >>> 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 < >>> jaehoon.paul@gmail.com> wrote: >>> >>>> Carlos, >>>> Great! >>>> >>>> Sure you soon in Singapore. >>>> >>>> Thanks. >>>> >>>> Paul >>>> >>>> On Thu, Nov 7, 2019 at 9:08 AM CARLOS JESUS BERNARDOS CANO < >>>> cjbc@it.uc3m.es> 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 < >>>>> jaehoon.paul@gmail.com> 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-1= 2 >>>>>> >>>>>> >>>>>> Thanks. >>>>>> >>>>>> Best Regards, >>>>>> Paul >>>>>> >>>>>> On Fri, Oct 4, 2019 at 1:19 AM CARLOS JESUS BERNARDOS CANO < >>>>>> cjbc@it.uc3m.es> 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 < >>>>>>> jaehoon.paul@gmail.com> 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 Projec= t >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> Cc: its@ietf.org , Sandra Cespedes < >>>>>>>> scespedes@ing.uchile.cl>, , Mr. >>>>>>>> Jaehoon Paul Jeong >>>>>>>> >>>>>>>> >>>>>>>> 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 < >>>>>>>> charles.perkins@earthlink.net> 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 overcom= e >>>>>>>>> certain >>>>>>>>> challenging aspects of vehicular networking. Since the >>>>>>>>> vehicles are >>>>>>>>> likely to be moving at great speed, protocol exchanges need t= o >>>>>>>>> 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, i= t >>>>>>>>> is >>>>>>>>> not discussed in later sections. This makes me wonder whether th= e >>>>>>>>> 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" an= d >>>>>>>>> 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 architectur= e >>>>>>>>> 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 sur= e >>>>>>>>> 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 >>>>>>>>> its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>>>>> Mr. Jaehoon (Paul) Jeong, Ph.D. >>>>>>>> Associate Professor >>>>>>>> Department of Software >>>>>>>> Sungkyunkwan University >>>>>>>> Office: +82-31-299-4957 >>>>>>>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >>>>>>>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>>>>> Mr. Jaehoon (Paul) Jeong, Ph.D. >>>>>>>> Associate Professor >>>>>>>> Department of Software >>>>>>>> Sungkyunkwan University >>>>>>>> Office: +82-31-299-4957 >>>>>>>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >>>>>>>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Special Issue "Beyond 5G Evolution": >>>>>>> https://www.mdpi.com/journal/electronics/special_issues/beyond_5g >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>>> Mr. Jaehoon (Paul) Jeong, Ph.D. >>>>>> Associate Professor >>>>>> Department of Software >>>>>> Sungkyunkwan University >>>>>> Office: +82-31-299-4957 >>>>>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >>>>>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Special Issue "Beyond 5G Evolution": >>>>> https://www.mdpi.com/journal/electronics/special_issues/beyond_5g >>>>> >>>>> >>>> >>>> -- >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>> Mr. Jaehoon (Paul) Jeong, Ph.D. >>>> Associate Professor >>>> Department of Software >>>> Sungkyunkwan University >>>> Office: +82-31-299-4957 >>>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >>>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >>>> >>>> >>> -- >>> Sent from a mobile device, please excuse any brevity or typing errors. >>> >> >> --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --000000000000001163059f4e43db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 JE= SUS BERNARDOS CANO <cjbc@it.uc3m.es> wrote:
Hi Paul,

I've checked version -13, an= d it has certainly improved compared to -12. However, there are still comme= nts that have not been completely addressed. Please find below the main one= s I still have.

- Page 4 (but also later in differ= ent parts of the doc): Mobility Anchor (MA): is this term coined somewhere = you can reference? It is mentioned as a component of a vehicular architectu= re, 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. Veh= icular Neighbor Discovery (VND), Vehicular Mobility Management (VMM), and V= ehicular Security and Privacy (VSP) in vehicular networks appear as =E2=80= =9Cnew=E2=80=9D functions, but what the use cases should reflect is the gap= s of current IPv6 mechanisms that need to be addressed. We don=E2=80=99t ne= ed to define new =E2=80=9Cvehicular-specific=E2=80=9D functions, but rather= to identify the extensions to existing protocols that vehicular scenarios = bring.

- Section 4 should introduce a generic vision of what vehicul= ar networks architectures might look like, again to help the purpose of ide= ntifying requirements. Current section is still making quite a lot of assum= ptions about how the architecture looks like without properly justifying th= em.The text now mentions that it is =E2=80=9Can exemplary architecture=E2= =80=9D to support the use cases, which might be OK, but I=E2=80=99m afraid = it might raise many questions on why we don=E2=80=99t try to use existing k= nown architectures and pinpointing where there are gaps.

- =E2=80=9C= For an IPv6 communication between an IP-OBU and an IP-RSU or between two ne= ighboring IP-OBUs, network parameters need to be shared among them, such as= MAC layer and IPv6 layer information.=C2=A0 The MAC layer information incl= udes wireless link layer parameters, transmission power level, the MAC addr= ess of an external network interface for the internetworking with another I= P-OBU or IP-RSU.=C2=A0 The IPv6 layer information includes the IPv6 address= and network prefix of an external network interface for the internetworkin= g with another IP-
OBU or IP-RSU.=E2=80=9D --> I still don=E2=80=99t= 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 d= oes not really backs that need.

- There are multiple assumptions in = the draft about the way IPv6 addressing will be used (e.g., multiple vehicl= es sharing a prefix in Figure 1, control and data separation, certain netwo= rk topologies in Figure 2) that are not explained. Why those assumptions an= d not others? Any reference supporting them? The document kind of assumes a= prefix model that is not properly introduced. Issues cannot be derived fro= m the use of a prefix model that is not well introduced.

- All the d= iscussion on ND timers is again very much solution specific and should be a= voided.

Thanks,

Carlo= s

On Mon, Jan 6, 2020 at 6:49 PM Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> wrote:
If you are satisfied with my revision, please let me know.=

I will ask five reviewers to review this version = for WGLC.

Thanks.

Best Re= gards,
Paul

On Sat, Nov 16, 2019 at 2:06 PM CARLOS JESUS BER= NARDOS CANO <cjbc@i= t.uc3m.es> wrote:
Hi Paul,
I=E2=80=99ve reviewed the draft. I think the draft= is in better shape than last time I checked, but it is not yet ready. I=E2= =80=99m 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 shou= ld 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 s= omewhere you can reference? It is mentioned as a component of a vehicular a= rchitecture, but it is not discussed why, not even why an IPv6 mobility sol= ution 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 th= e basic OCB draft uses (IP-OBU and IP-RSU) and probably refer to that docum= ent. Besides I understand OBU and RSUs as single IP devices, not set of nod= es as the document currently defines.

- Page 5: V2I2P and V2I2V deserve additional explanation.

- The use cases should serv= e not only to present areas where vehicular networks can be used, but also = to support requirements for IPv6 in such environments. Current text does no= t help much on identifying requirements.

<= div dir=3D"auto">- Section 4 should introduce a generic vision of what vehi= cular networks architectures might look like, again to help the purpose of = identifying requirements. I=E2=80=99m afraid current section is making quit= e a lot of assumptions about how the architecture looks like without proper= ly 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 e= xample of potential architecture. It=E2=80=99d be right to present an exemp= lary architecture to support the use cases and problem statement, but the d= ocument should clearly state that.

- Related to the former, the document assumes that IPv6 mobility= is a key requirement. While I don=E2=80=99t disagree with that, the docume= nt 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 com= e from? It=E2=80=99s new to me. Similarly, on the vehicle I=E2=80=99d expec= t Router1 to be an IP-OBU. Related to this comment, first paragraph of Sect= ion 4.2 talks about the RSU architecture without providing any reference. W= hy is it needed to have a DNS server internally? I don=E2=80=99t see why th= is is needed or specific to vehicular networks.

=
- Page 12: all the discussion about the need for ex= changing prefix information comes out of the blue, there is no proper discu= ssion 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 diff= erent approaches to solve a given problem.

- Page 12: as mentioned above, I don=E2=80=99t see why w= e 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.

- Sectio= n 5.1 is a critical one (actually the whole section 5) and I think it needs= significant work. I=E2=80=99d discuss link model issues before going into = neighbor discovery protocol specific issues. Current text seem to have alre= ady a solution in mind when describing the issues, while what it should do = is derive requirements, and explain why current solutions are not sufficien= t. For example, it should not start saying that DAD and ND-related paramete= rs need to be extended before introducing why current DAD and ND is not suf= ficient.

- All the discu= ssion on ND timers is again very much solution specific and should be avoid= ed. And the discussion about NHTSA and the collision is also not appropriat= e, 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 netw= ork 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 notif= ying changes on the IP address should be removed if it is assumed that ther= e is an IPv6 mobility protocol in place (which seems to be the case) as thi= s is taken care by it.

-= Section 5.1.3: again it goes too much into solution space without presenti= ng the scenario and the issues. This document is not about talking solution= s.

- Section 5.2: same c= omment as before. Solution space specifics should be removed.

- Section 6 needs significant work as= well. First, I=E2=80=99d like to have some kind of structure in terms of p= resenting the security and privacy issues that are specific to the vehicula= r environment. And then, we need to have a list of issues/requirements inst= ead 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 <jaehoon.paul@gmail.com> w= rote:
Carlos,
Great!

Sure you soon in Singa= pore.

Thanks.
Paul

On Thu, Nov 7, 2019 at 9:08 AM CARLOS JESUS BERNARDOS= CANO <cjbc@it.uc3m= .es> wrote:
Hi Paul,

I have to do my review firs= t. 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 <jaehoon.paul@gmail.com> wrote:
H= i Carlos,
I am wondering what next steps our IPWAVE PS draft will take.=
If you are satisfied=C2=A0with my revision, could you do the WG = Last Call on this version?

Thanks.

Best Regards,
Paul

On Fri, Oct 4, 2019 at 1:19 AM CARLOS JESUS BERNARDOS CA= NO <cjbc@it.uc3m.es= > wrote:
=
Hi Paul,

Thanks for the revision. I'= ;ll review the document and let you know about next=C2=A0steps.
<= br>
Carlos

On Thu, Oct 3, 2019 at 12:12 PM Mr. Jaehoon Paul = Jeong <jaeho= on.paul@gmail.com> wrote:
Hi Russ and Carlos,
I have submitted = the revision (-12) of IPWAVE PS draft as you know.

Will you review the rev= ision and move forward to the WGLC or wait for Charlie's another review= ?

BTW, my SKKU team are working for IETF-106 IPWAV= E Hackathon Project to show the data delivery=C2=A0
between two 8= 02.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 messa= ge ---------
From: Mr. J= aehoon Paul Jeong <jaehoon.paul@gmail.com>Date: Thu, Oct 3, 2019 at 6:57 PM
Subject: Re: [ipwave] Some review com= ments for draft-ietf-ipwave-vehicular-networking-11
To: Charlie Perkins = <char= les.perkins@earthlink.net>
Cc: its@ietf.org <its@ietf.org>, Sandra Cespedes <scespedes@ing.uchile.cl>, &= lt;skku-i= otlab-members@skku.edu>, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com><= br>


Hi Charlie,
I have addressed your com= ments below and your editorial changes, submitting the revision:

Also, I ad= dressed Sandra's comments about the definition of an RSU as an edge com= puting system
having multiple routers and servers (including DNS = server), as shown in Figure 2.

I attach the revisi= on letter for your double-checking.

Thanks for you= r valuable and constructive=C2=A0comments.

Best Re= gards,
Paul


On Mon, Sep 16, 2019 at 1:08 PM C= harlie Perkins <charles.perkins@earthlink.net> wrote:
Hello folks,

I made a review of the document
draft-ietf-ipwave-vehicular-networking-11.txt.=C2=A0 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.=C2=A0 Here is some text that I devised for that purpose,=
which could fit naturally at the beginning of Section 5.

=C2=A0=C2=A0=C2=A0 In order to specify protocols using the abovementioned a= rchitecture
=C2=A0=C2=A0=C2=A0 for VANETs, IPv6 core protocols have to be adapted to ov= ercome certain
=C2=A0=C2=A0=C2=A0 challenging aspects of vehicular networking.=C2=A0 Since= the vehicles are
=C2=A0=C2=A0=C2=A0 likely to be moving at great speed, protocol exchanges n= eed to be
=C2=A0=C2=A0=C2=A0 completed in a time relatively small compared to the lif= etime of a
=C2=A0=C2=A0=C2=A0 link between a vehicle and an RSU, or between two vehicl= es.=C2=A0 This
=C2=A0=C2=A0=C2=A0 has a major impact on IPv6 neighbor discovery. Mobility = management
=C2=A0=C2=A0=C2=A0 is also vulnerable to disconnections that occur before t= he completion
=C2=A0=C2=A0=C2=A0 of identify verification and tunnel management.=C2=A0 Th= is is especially
=C2=A0=C2=A0=C2=A0 true given the unreliable nature of wireless communicati= ons.=C2=A0 Finally,
=C2=A0=C2=A0=C2=A0 and perhaps most importantly, proper authorization for v= ehicular
protocol
=C2=A0=C2=A0=C2=A0 messages must be assured in order to prevent false repor= ts of accidents
=C2=A0=C2=A0=C2=A0 or other mishaps on the road, which would cause horrific= misery in
=C2=A0=C2=A0=C2=A0 modern urban environments.

----------------------------------------------

Although geographic routing is mentioned early in the document, it is
not discussed in later sections.=C2=A0 This makes me wonder whether the ear= ly
mention is really relevant.=C2=A0 In fact, for fast moving objects, I think=
it is already questionable whether geographic routing has value.=C2=A0 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.=C2=A0 If geographic algorith= ms
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" an= d 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.=C2=A0 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).=C2=A0 But =
anyway some care has to be taken so that the proposed architecture
doesn't otherwise place strong limits on acceptable solutions.=C2=A0 So= , for
example, in section 4.1, it needs to be clear whether or not a single
subnet prefix can span multiple vehicles.=C2=A0 This is an important choice= .

---------------------------------------------

In section 5.1.1., a claim is made that a new link model is required.=C2=A0= I
think this is a very ambitious claim, and I am not even quite sure what is meant.=C2=A0 IPv6 already provides for "on-link" and "off= -link" variations
on subnet operation.=C2=A0 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.=C2=A0 I think that this point is not
sufficiently covered in the current text.

Regards,
Charlie P.
Blue Sky Networks



_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate ProfessorDepartment of Software
Sungkyunkwan University
Office: +82-31-299-4= 957
Email: j= aehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal = Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<= /div>


--
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department= of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email= : jaehoon.paul@= gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<= /div>


--


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate ProfessorDepartment of Software
Sungkyunkwan University
Office: +82-31-299-4= 957
Email: j= aehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal = Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<= /div>


--


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate ProfessorDepartment of Software
Sungkyunkwan University
Office: +82-31-299-4= 957
Email: j= aehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal = Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<= /div>
--
Sent from a mobile device,= please excuse any brevity or typing errors.
=



--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.= D.
Associate Professor
Department of Software
Sungkyunkwan Univers= ity
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeon= g@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaeho= on-jeong.php
--000000000000001163059f4e43db--