Re: [ipwave] Some review comments for draft-ietf-ipwave-vehicular-networking-11
"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Mon, 18 November 2019 03:01 UTC
Return-Path: <jaehoon.paul@gmail.com>
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 347A112088E for <its@ietfa.amsl.com>; Sun, 17 Nov 2019 19:01:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] 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 VOM7Vu7m7xRQ for <its@ietfa.amsl.com>; Sun, 17 Nov 2019 19:01:36 -0800 (PST)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 81EDB12089A for <its@ietf.org>; Sun, 17 Nov 2019 19:01:35 -0800 (PST)
Received: by mail-wm1-x332.google.com with SMTP id f3so17031222wmc.5 for <its@ietf.org>; Sun, 17 Nov 2019 19:01:35 -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=ibYiKkIcAmuOiV+xzm7zucIzU5pJLEWGwrByd2I0IW4=; b=TuzZknw2xv1Mniis14xpvuSNGgKvlpmXYdZrqoGZkRIRP/HxBJlW9CMqZu77ecNDUm 60kdQ22Pb66WoGI84GGzcyPwaY9ongMXo4fZSXedkWL0Q97Jf8tPvrG2/DWJS0m7ZwXN l+3fQQnuf3DMIbQzHAP9ebYU5cC7L3BJjafyrliOL3FH+mWiYQpchb/0s+FkiT3IZvLz btbSrISvGxQRSam50/Ci6vvc4m2dE5GeAziIhkOzxRUbuLy6b8nw+VTn+7/Rxc0oYjVq /T5lHxcMHJR6Ed+v6mJa6XLGMX4rgFKmIfa6MDozkCl86Y7aGp2Pw8xuuvKx8rLMioW5 czgA==
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=ibYiKkIcAmuOiV+xzm7zucIzU5pJLEWGwrByd2I0IW4=; b=s0M8Danop+J3m0GlQT41r+hQhILdeq5XNygh97sMXzp06qoaeuv+f7MwCDxUnAaJd3 JJ6zCA86rN/POe9QGEym1796qPRmrYZ8YL1AfF2BKkBTgtKqAPGJ7pC+eDqNcMr372cB RUmNVcNttHPgj1ZllB/43zscvpWXfMZyVbabBAYaIMOOMmossHAabT/81RbCsQuW4sR/ dW6zg/eFCvCVTE/7BvkA0FFWZmeVC9Zkod79r5o23e4ttu2IRc2wD21NvMYw79YPLjM3 OBZsfM88eY3Bsx5o2T/MhGSztNhmySrSCabxBkWntidRPxaM+g6h5/kyJ0I4tWDG02BZ 6B8Q==
X-Gm-Message-State: APjAAAX3D5sDWi2tBX+FCI4d9QROrp2Qw0j7dey1onyNIqdG+pM1cT33 SuWa16uGbThzbfL3SEpvtpicRvNfZurLmRjCmPs39eip
X-Google-Smtp-Source: APXvYqySUn6ugdsei84w02KEVnfeY1nhPN6FG7Jg2JZT3diEIXrd7+C/SPqAC06XWnXgYHmKbA6id/9DS4j9Djten5E=
X-Received: by 2002:a05:600c:2041:: with SMTP id p1mr25688082wmg.11.1574046093779; Sun, 17 Nov 2019 19:01:33 -0800 (PST)
MIME-Version: 1.0
References: <a93e3290-e31f-dbd2-a39c-2895026f59ee@earthlink.net> <CAPK2Dexd=Zo9B3GfoHEvTUGCVyK1X+spVS168ONzWO8tDrp1OQ@mail.gmail.com> <CAPK2DexXyT0pdu6Bjptj3AZL8VwsNbK=K1-UGkKyYL+1eQFquQ@mail.gmail.com> <CALypLp8c6kOf1MVP9vvk3-77PVQco_FWkc0cstBzVfdFUEtufg@mail.gmail.com> <CAPK2DexyKTyfZaUR81YFHEWrFREutoXVmsZQ8Q2pCud5Wx_Cww@mail.gmail.com> <CALypLp--W7gGE6-2A90ZBrGvQui0rRQhRF4XRYvQa6Ss0jn2Lg@mail.gmail.com> <CAPK2DezuRL7BggRF5UNC0OnDNEGinRKg8+S4Uh-yHrF-af6BOg@mail.gmail.com> <CALypLp-vTw8Wa=uip0g1gSJswjdNkv7-8iqJGs6mxsYCUkn--A@mail.gmail.com> <CAPK2Dey-65zPc_zn+P3=+0warWyLMQp1z66V7-FjhYznfKLMZg@mail.gmail.com> <CALypLp9yA9NZDQvoCeYOmJMjGECzr+KX8OGDtN90E7G+Mo0GZA@mail.gmail.com>
In-Reply-To: <CALypLp9yA9NZDQvoCeYOmJMjGECzr+KX8OGDtN90E7G+Mo0GZA@mail.gmail.com>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Mon, 18 Nov 2019 12:00:57 +0900
Message-ID: <CAPK2DeyDgzOinbSVzKYLMSAcuA+2oj9tO8gfy2rvwioUcn_8xg@mail.gmail.com>
To: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Cc: Russ Housley <housley@vigilsec.com>, Suresh Krishnan <Suresh@kaloom.com>, its <its@ietf.org>, skku-iotlab-members@googlegroups.com, 김증일 글로벌R&D마스터 <endland@hyundai.com>
Content-Type: multipart/alternative; boundary="00000000000047a6f70597962a60"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/ptjMR6WgTeF14T1Z5ZAfomP1eYs>
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 <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Nov 2019 03:01:46 -0000
Hi Carlos, Let's meet at 3pm at Terminal Room 2. Before the meeting, I will try to address your comments and revise the draft. During the meeting with you, I want to improve the revision and submit it to the IETF repository. I will ask the IPWAVE WG to review it and give us the feedback. Thanks. Paul On Sun, Nov 17, 2019 at 11:08 AM CARLOS JESUS BERNARDOS CANO < cjbc@it.uc3m.es> wrote: > Hi Paul, > > Sure we can meet this week. Tuesday at 15h might be an option. > > But based on my comments, I doubt we will be able to close all the issues > by Singapore. Remember that this is a WG document, so its content should > reflect the consensus of the WG. You need to ask for feedback on the > changes you'll make, and there are quite some that you need to do. > > Thanks, > > Carlos > > On Sat, Nov 16, 2019 at 1:24 PM Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > >> Carlos, >> Thanks for your detailed comments. >> >> I will prepare for the revision with your comments early next week. >> Could we have a meeting to review my new revision, and revise it for WGLC >> before the end of this IETF-106 meeting? >> >> I will be available next Tuesday and Wednesday, so please let me know >> your available time. >> >> Thanks. >> >> Paul >> >> On Sat, Nov 16, 2019 at 2:06 PM CARLOS JESUS BERNARDOS CANO < >> cjbc@it.uc3m.es> 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 < >>> 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 <jaehoon.paul@gmail.com> >>>>>>>> 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 <charles.perkins@earthlink.net> >>>>>>>> Cc: its@ietf.org <its@ietf.org>, Sandra Cespedes < >>>>>>>> scespedes@ing.uchile.cl>, <skku-iotlab-members@skku.edu>, Mr. >>>>>>>> Jaehoon Paul Jeong <jaehoon.paul@gmail.com> >>>>>>>> >>>>>>>> >>>>>>>> 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 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 >>>>>>>>> its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> =========================== >>>>>>>> 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 >>>>>>>> <http://cpslab.skku.edu/people-jaehoon-jeong.php> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> =========================== >>>>>>>> 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 >>>>>>>> <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: +82-31-299-4957 >>>>>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >>>>>> 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: +82-31-299-4957 >>>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >>>> 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: +82-31-299-4957 >> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >> 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: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
- [ipwave] Some review comments for draft-ietf-ipwa… Charlie Perkins
- Re: [ipwave] Some review comments for draft-ietf-… Alexandre Petrescu
- Re: [ipwave] Some review comments for draft-ietf-… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Some review comments for draft-ietf-… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Some review comments for draft-ietf-… CARLOS JESUS BERNARDOS CANO
- Re: [ipwave] Some review comments for draft-ietf-… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Some review comments for draft-ietf-… CARLOS JESUS BERNARDOS CANO
- Re: [ipwave] Some review comments for draft-ietf-… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Some review comments for draft-ietf-… CARLOS JESUS BERNARDOS CANO
- Re: [ipwave] Some review comments for draft-ietf-… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Some review comments for draft-ietf-… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Some review comments for draft-ietf-… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Some review comments for draft-ietf-… CARLOS JESUS BERNARDOS CANO
- Re: [ipwave] Some review comments for draft-ietf-… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Some review comments for draft-ietf-… Mr. Jaehoon Paul Jeong