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

CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> Sun, 17 November 2019 02:08 UTC

Return-Path: <cjbc@it.uc3m.es>
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 B85DB12081A for <its@ietfa.amsl.com>; Sat, 16 Nov 2019 18:08:41 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 4eJQ2hppn43O for <its@ietfa.amsl.com>; Sat, 16 Nov 2019 18:08:38 -0800 (PST)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 5BA1612081B for <its@ietf.org>; Sat, 16 Nov 2019 18:08:37 -0800 (PST)
Received: by mail-ed1-x533.google.com with SMTP id r16so10669885edq.2 for <its@ietf.org>; Sat, 16 Nov 2019 18:08:37 -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=HV8pn6PF3ylUIrcEK7A6pWSpr3hhRHtYvQddaX479O4=; b=EochgLEhA3NsROdbT8sgi388wdBpWSv1WZwqQK1A1lNmFOzpvS2blkg4f1HyEBN8l6 th9oWlcrbkYgroZtpLeU426mBhoLqh23RVijM5vB2Ijzt4iYDmFGU5Y1l2PQKCWlabEe y9LUSH05BBZKAQ9jQjuuJo3tgfdx0gE0C32y4cp9KQtERdOCymPVnzdVLbN2Jlmn04z+ /iBIuA1692VKxSeownpAVpfWNXwLg6/xdXHskFgRkY8tSAFSLuNrx2k7jeJRzHcDYU2A V4zuicgbgcRRf5nK/dPTe/jPJdZJiehEb0voIN0JBfShNzFGAgduViyHSS087oe9/mNs pkvg==
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=HV8pn6PF3ylUIrcEK7A6pWSpr3hhRHtYvQddaX479O4=; b=N2egiIsQ6GjK+TwcJaCqucB/IZ2PbzOii+uLOvwNHwFLob8Mkhcjw5/znak+bT7n/7 oO2zQfVFBE8oOD3VYmwO7zmT+MS7EJ5Z1juoncmuzaSMnzRrDUDCwSGXQ13wHjEdo4oD UHmlXwv3sYvsqtEEAu//g9Ff7d0JEfptRl/SI2fBdDnwgx2MGOWS5qRBxu72iJ5X1TjL 21lFkI+61s8t+l2PnBuemMB0ITZsoRB9ja7fLn1F+9ZZg63Ggxtmpj6pv7CxIuqcjZz8 U79JtgjxyO8+Gv3J600cFtC+5X3w9IitkoSkArMSRpBrKS7U6IbxUU561k7kw2zriP5P YaDw==
X-Gm-Message-State: APjAAAVpbAQFg4g21GhvtLpDNMsl7uGxCViggKCJnnzoRD2ZIFoysciG VDXpbF1pPpnwGPlTrR3PX3vXOA8/UHce9doddPrsOg==
X-Google-Smtp-Source: APXvYqz50P24XvM0HMfwgozS3M68z5z1hrmY6WRSIoegz2mLs/t8hcuUopE5+zbrNLrgN3kWBkyznfEkAioTbZ3Sbhk=
X-Received: by 2002:a17:906:d72:: with SMTP id s18mr14784568ejh.29.1573956515506; Sat, 16 Nov 2019 18:08:35 -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>
In-Reply-To: <CAPK2Dey-65zPc_zn+P3=+0warWyLMQp1z66V7-FjhYznfKLMZg@mail.gmail.com>
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Sun, 17 Nov 2019 10:08:18 +0800
Message-ID: <CALypLp9yA9NZDQvoCeYOmJMjGECzr+KX8OGDtN90E7G+Mo0GZA@mail.gmail.com>
To: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
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="000000000000ffce490597814eaa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/NsTwtaMFHyHKuNiFFKGYaXb6S6w>
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: Sun, 17 Nov 2019 02:08:42 -0000

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