Re: [ipwave] Commenting on the FCC plan, and a note I saw at 5GAA

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 15 September 2021 16:27 UTC

Return-Path: <alexandre.petrescu@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 209AC3A20D8 for <its@ietfa.amsl.com>; Wed, 15 Sep 2021 09:27:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.67
X-Spam-Level: *
X-Spam-Status: No, score=1.67 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001, URI_DOTEDU=1] autolearn=no autolearn_force=no
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 WGk9hH02KtMm for <its@ietfa.amsl.com>; Wed, 15 Sep 2021 09:27:07 -0700 (PDT)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCF193A20D2 for <its@ietf.org>; Wed, 15 Sep 2021 09:27:05 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 18FGR115014426; Wed, 15 Sep 2021 18:27:01 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3CC96204A40; Wed, 15 Sep 2021 18:27:01 +0200 (CEST)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 24206204830; Wed, 15 Sep 2021 18:27:01 +0200 (CEST)
Received: from [10.14.0.102] ([10.14.0.102]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 18FGQw4u005005; Wed, 15 Sep 2021 18:26:58 +0200
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
To: dickroy@alum.mit.edu
Cc: 'its' <its@ietf.org>
References: <EED81985-1D4C-41B2-8CCA-A46B96390A18@vigilsec.com> <ad3ccd6c-cd99-c47a-d0df-bfb94b5ab40f@gmail.com> <CADnDZ8_wwa91-5UWeqxhJy=nMBp8kwu4ZvfxsAojZCY9DG8jSA@mail.gmail.com> <92850021-914f-ab6a-f8d2-ab793179fa1b@gmail.com> <00d601d5b4ee$01cc9ae0$0565d0a0$@eurecom.fr> <47f48fca-07b9-5657-4cb5-54cc5d63d2e3@gmail.com> <b9ea5f34-0129-614b-d644-0ab95437f6ac@gmail.com> <7664b128-91b7-8fef-1e13-b681b45b1958@gmail.com> <61f9d6f6-1e37-6e15-3a48-48e7047f0fe1@gmail.com> <CADnDZ88tsTvRdr4_jpWxnT0X_3ihTJ8=783-6M-kFNS+uMnA3Q@mail.gmail.com> <b7d40c34-ccdd-2617-0598-62a4b7faf994@gmail.com> <7f2e764a-8d75-a3a8-cd4e-a4406dd8e321@gmail.com> <038fea3b-cdd3-dbe3-04f9-fbe873661cf1@gmail.com> <0e29e730-e62a-f864-ad10-81f5e524bf33@gmail.com> <b8c89459-0778-9c50-64d7-0373e38cfb17@gmail.com> <50d6bbf8-da70-15f3-ff19-3103393aa35a@gmail.com> <CAL1T1NEvuAU86cvTZ+agD3OpgBuehn6xBwP7LQQ-7KY6PS=Rig@mail.gmail.com> <65730212-5b24-1! ace-9aa2- 9bc8ab4f1a15@g mail.com> <72D79BAADEB744678E8B5A62F64F4A40@SRA6>
Message-ID: <1070e6b7-e56f-88f3-58db-13c7a6b1b47a@gmail.com>
Date: Wed, 15 Sep 2021 18:26:58 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <72D79BAADEB744678E8B5A62F64F4A40@SRA6>
Content-Type: multipart/alternative; boundary="------------5E922B99DA30E5DFF65CC1AF"
Content-Language: fr
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/Gjs3W-9a4eBcly5NtrfV6HqYuC4>
Subject: Re: [ipwave] Commenting on the FCC plan, and a note I saw at 5GAA
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: Wed, 15 Sep 2021 16:27:12 -0000

[sorry, I trimmed several email addresses from the Cc list, for the 
common interest]

Le 10/09/2021 à 18:36, Dick Roy a écrit :
>
> If the Europeans fall for this, shame on them.  It is bloody obvious 
> to anyone with the capacity to think that this global disinformation 
> campaign has been orchestrated by one company to force people who are 
> trying to save lives to deploy an inferior technology … why … simple … 
> because that company gets $3/DSRC (aka Wi-Fi) module and $32/C-V2X 
> module in license and royalty fees. Amazing!
>

It sounds reasonable to think that might happen, from a certain 
standpoint.  There might indeed be IPRs on C-V2X owned at Qualcomm who 
is known to having enforced that extensively in the past (requesting 
license fees) on high potential growth technos, was it on 'digital 
radios' at a time, like 2G in Europe and that of an American standard 
with another name.

But that reasoning has some questions that could be doubted.

This 5GAA band position targets Europe markets; in 5GAA one can find 
both Qualcomm and Huawei.  These two are known to not get along each 
other, at least in USA and in China; there is a politically correct form 
of expressing that, and I should have used it, but I forgot how.

A common position between two organisations is a great achievement and 
should be applauded.  However, the quirk is how to assimilate that a 
same company requesting paying licenses for dollars/module accepts to 
share that opportunity with another company?  If so, then it might 
accept to share it with many others?  If there are very many then the 
gain would really approach zero; this would contradict the first 
assumption that the mess is motivated exclusively by the need of gain money.

This is why I dont think it is very simple to say that the C-V2X band 
occupation at 5.9GHz (kicking off OCB) is a matter as simple as cupidity 
or greed of a particular private interest neglecting human life worries, 
in this particular 5GAA and EU case (I dont know for USA).

Then, even if the 5GAA frequency band position plan goes on, it is so 
different than the already implemented plan of FCC at 5.9GHz in America 
- channels are different, C-V2X is out of question, LTE-V2X is in, etc.  
That is a problem; ideally both EU and USA should have a very similar 
frequency plan at 5.9Ghz.  It would make it easier for car manufacturers 
to sell cars to both areas - less risks of software errors and 
incompatibilities.  Failure to negotiate this leads to headaches to 
implementers, more expenses to be paid to software.

IMHO this is a messy situation, but IP might help with it.  IP runs ok 
on OCB (RFC8691).  If we make sure it runs ok over C-V2X too, then there 
might be a winning situation for Internet and automobiles.

That is not easy to do, because 5GAA does not consider IPv6 in the first 
place, and because 3GPP normal implementations do not allow for a /56 to 
be delegated to a User Terminal (3GPP modem implementations (both 
Qualcomm and Huawei) only give a /64 to an end user, whereas  a car 
using a single modem needs more than just one /64, e.g. a /56; a person, 
err, tells me that Russian hackers did hack into a Hisilicon (of 
Huawei!) modem into making this happen, but that is in Russian, and it 
is about a little bit a 'hack', i.e. not official, see 
https://4pda.to/forum/index.php?showtopic=678549&st=17700#entry90297458 
).   If 5GAA and FCC and Qualcomm and/or Huawei fight so much for this 
C-V2X or LTE-V2X but they neglect that without Internet all these C-V2X 
and LTE-V2X dont mean anything, then it is a bigger problem.  If they 
continue to assume that 'Internet' is not IPv6, then their 
misunderstanding is even bigger.

They struggle for something that might be completely changed by looking 
at it from the IPv6 perspective.


> I guess $3 is just not enough when human lives are at stake when you 
> can get 10 times that amount even if it costs more people their lives!
>

This is an important point that should always be kept in mind, maybe put 
it upfront.  Make sure everyone assumes it.

Alex


> I suggest that if this proposal is adopted, the European Commission 
> should pass a law that 95% of all C-V2X license and royalty fees be 
> confiscated and put into a trust fund for all of the victims and 
> relatives of pedestrian and motorist accidents and fatalities over the 
> last 6 years and counting, a significant percentage of which could 
> have been prevented if not for the greed of this company. 
>  Unfortunately, I personally have a long list of people, including 
> myself and one of my sons, who could make good use of those 
> reparations.  The family of Ashley Diaz (45) who died last week while 
> saving a child from getting run over by an SUV in a school crossing in 
> a nearby city could also use some help with funeral expenses.  And 
> then there’s the 13-yearold boy that was run over this last Monday by 
> an SUV in a crosswalk in my neighborhood on his way to school.  
> Fortunately, he survived, but it will take a few operations to get his 
> leg back together. If none of this sickens you, you should check to 
> make sure you still have a pulse. This entire debacle has passed the 
> level of unethical and amoral and has transcended to the disgusting 
> and putrid!
>
> May God have mercy on the souls of those responsible for this … and 
> you know who you are!
>
> ------------------------------------------------------------------------
>
> *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Alexandre Petrescu
> *Sent:* Friday, September 10, 2021 6:49 AM
> *To:* Chris Shen
> *Cc:* its
> *Subject:* Re: [ipwave] Commenting on the FCC plan, and a note I saw 
> at 5GAA
>
> To let you know a position I learn from 5GAA about proposal for 
> allocation for
>
> Alex
>
> Le 26/01/2021 à 06:02, Chris Shen a écrit :
>
>> Hi Alex,
>>
>> Thank you for your provided information.
>>
>> I scanned the FCC document you shared.
>>
>> I believe that the new change is to divide the previous ITS spectrum 
>> into two parts:
>>
>>   * *5.850GHz - 5.895GHz:**Unlicensed band (5MHz + 40MHz)*
>>   * *5.895GHz - 5.925GHz:**ITS band (30MHz, B47)*, *requiring to use
>>     C-V2X (5G-V2X) at the end of this transition.*
>>
>> Two weeks ago, in the CCNC 2021, one of the keynote speakers from 
>> Qualcomm shared some information about this latest transition.
>>
>> I share one of the slides in the keynote related to this transition here.
>>
>> ITS-band-transition-202101.png
>>
>> The whole slides can be found here:
>>
>> https://whova.com/xems/whova_backend/get_event_s3_file_api/?eventkey=d292f69137f1ea29bd6dd11e18771c3d6a6d97e93ef7a2ded585ac68b40d5e59&event_id=iccnc_202101&file_url=https://whova.com/xems/whova_backend/get_event_s3_file_api/?event_id=iccnc_202101&eventkey=d292f69137f1ea29bd6dd11e18771c3d6a6d97e93ef7a2ded585ac68b40d5e59&file_url=https://d1keuthy5s86c8.cloudfront.net/static/ems/upload/files/eevcg_Connected_Car_CCNC_2021_Lansford_Keynote.pdf 
>> <https://whova.com/xems/whova_backend/get_event_s3_file_api/?eventkey=d292f69137f1ea29bd6dd11e18771c3d6a6d97e93ef7a2ded585ac68b40d5e59&event_id=iccnc_202101&file_url=https://whova.com/xems/whova_backend/get_event_s3_file_api/?event_id=iccnc_202101&eventkey=d292f69137f1ea29bd6dd11e18771c3d6a6d97e93ef7a2ded585ac68b40d5e59&file_url=https://d1keuthy5s86c8.cloudfront.net/static/ems/upload/files/eevcg_Connected_Car_CCNC_2021_Lansford_Keynote.pdf>
>>
>> Thanks!
>>
>> Chris
>>
>> On Tue, Jan 26, 2021 at 2:43 AM Alexandre Petrescu 
>> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> 
>> wrote:
>>
>>     I was pointed in private that a new plan is there
>>     https://www.fcc.gov/document/fcc-modernizes-59-ghz-band-improve-wi-fi-and-automotive-safety-0
>>     <https://www.fcc.gov/document/fcc-modernizes-59-ghz-band-improve-wi-fi-and-automotive-safety-0>
>>
>>     My quick read tells me that is potentially a significant change in
>>     spectrum use.
>>
>>     Le 25/01/2021 à 17:58, Alexandre Petrescu a écrit :
>>     > Hi, IPWAVErs,
>>     >
>>     > Do you know what is the result of this plan of allocating
>>     5.9GHz bands
>>     > for C-V2X?
>>     >
>>     > Have I missed a follow up of it?
>>     >
>>     >
>>     https://www.fcc.gov/document/fcc-seeks-promote-innovation-59-ghz-band-0
>>     <https://www.fcc.gov/document/fcc-seeks-promote-innovation-59-ghz-band-0>
>>     >
>>     > Alex
>>     >
>>     >
>>     > Le 10/07/2020 à 14:42, Alexandre Petrescu a écrit :
>>     >> Hello,
>>     >>
>>     >> I would like to know wheher FCC advanced well while seeking to
>>     promote
>>     >> innovation in the 5.9GHz band?
>>     >>
>>     >> In particular, is now IPv6 allowed to run on the control channel
>>     >> 5895-5905MHz on 802.11 in OCB mode?
>>     >>
>>     >> The URL to the FCC document stating that seeking of promotion of
>>     >> innovation is this, but I cant figure out a conclusion of it(?)
>>     >>
>>     https://www.fcc.gov/document/fcc-seeks-promote-innovation-59-ghz-band-0
>>     <https://www.fcc.gov/document/fcc-seeks-promote-innovation-59-ghz-band-0>
>>     >>
>>     >> Alex
>>     >>
>>     >> Le 24/01/2020 à 15:11, Alexandre Petrescu a écrit :
>>     >>> for information, the filing is now visible at
>>     >>> https://www.fcc.gov/ecfs/filing/10115292918548
>>     <https://www.fcc.gov/ecfs/filing/10115292918548>
>>     >>>
>>     >>>
>>     >>> Le 15/01/2020 à 21:34, Alexandre Petrescu a écrit :
>>     >>>> I submitted the comments that are shown in the attached file.
>>     >>>>
>>     >>>> It is possible to submit more comments, maybe with more help
>>     from
>>     >>>> interested parties, or to clarify other things.  It's the
>>     same URL
>>     >>>> https://www.fcc.gov/ecfs/filings
>>     <https://www.fcc.gov/ecfs/filings>
>>     >>>>
>>     >>>> Alex
>>     >>>>
>>     >>>> Le 15/01/2020 à 21:11, Alexandre Petrescu a écrit :
>>     >>>>> 6. "In support of its waiver request, 5GAA submitted
>>     studies of
>>     >>>>> using 10- and 20-megahertz-wide channels for C-V2X that
>>     found that
>>     >>>>> allowing operation on a single 20-megahertz channel will
>>     support
>>     >>>>> the introduction
>>     >>>>> of services “that [will] enable many important safety
>>     applications,
>>     >>>>> such as red light warnings, basic safety messages, emergency
>>     >>>>> alerts, and others, to enhance traffic systems and
>>     operations.”"
>>     >>>>>
>>     >>>>> My comment is the following: one would benefit from
>>     considering
>>     >>>>> carefully the statements from 5GAA.  Depending how it is
>>     >>>>> interpreted it might be advantageous or not.  For my part,
>>     I do
>>     >>>>> think that some of the claims of 5GAA in some trials make
>>     >>>>> confusions about cellular technology and DSRC technology. I do
>>     >>>>> think that there is at least one publicly demonstrated
>>     trial under
>>     >>>>> the banner of 5GAA which uses DSRC but it claims cellular
>>     technology.
>>     >>>>>
>>     >>>>> That said, with respect to the use of the term "C-V2X": it
>>     is not
>>     >>>>> very clear throughout the FCC Notice whether C-V2X means the
>>     >>>>> traditional traits of cellular technology that
>>     distinguishes it
>>     >>>>> from WiFi (i.e. use cellular frequencies, use a SIM, specific
>>     >>>>> codecs, mandatory base station, etc.) or otherwise it means
>>     some
>>     >>>>> more generic "3GPP" technology.  The only place where C-V2X is
>>     >>>>> defined more properly is when, on page 37, it refers to 3GPP
>>     >>>>> Release 14. There is no pointer to a particular 3GPP Rel 14
>>     >>>>> document.  This lets open the imagination to think that it
>>     might
>>     >>>>> mean the WiFi aspects of 3GPP. 3GPP is known to spec things by
>>     >>>>> stepping into WiFi domain very often, even though in
>>     practice there
>>     >>>>> are no 3GPP deployments on WiFi - and that, since 3G
>>     onwards :-)
>>     >>>>> In this sense, it might be that 'C-V2X' already means
>>     something
>>     >>>>> from WiFi, and why not C-V2X to mean 802.11-OCB and BSM
>>     messages?
>>     >>>>>
>>     >>>>> This lack of precision in mentioning "C-V2X" is what adds a
>>     lot to
>>     >>>>> the confusion - should one accept C-V2X in 5.9GHz bands?
>>     Well yes,
>>     >>>>> provided 'C-V2X' means a WiFi issued by 3GPP by
>>     copy/pasting IEEE.
>>     >>>>> Well no, if 'C-V2X' means a pure cellular interface with a
>>     SIM card
>>     >>>>> or software, mandatory base station, cellular codecs and
>>     specific
>>     >>>>> expensive specific IPR from well-known particular companies.
>>     >>>>>
>>     >>>>> 7. "With this Notice, we propose that ITS in this band
>>     continue to
>>     >>>>> provide safety of life services. We seek comment on this
>>     proposal."
>>     >>>>>
>>     >>>>> This is my comment, and backed by a colleague from IETF: on
>>     which
>>     >>>>> channel should we run IPv6-over-OCB? (RFC 8691)
>>     >>>>>
>>     >>>>> 8. "C-V2X in the 5.905-5.925 GHz band. Specifically, we
>>     propose to
>>     >>>>> authorize C-V2X operations in the upper 20 megahertz of the
>>     band
>>     >>>>> (5.905-5.925 GHz). We seek specific and detailed comment on
>>     this
>>     >>>>> proposal that can fully inform our decision."
>>     >>>>>
>>     >>>>> This is my detailed comment: when one wants to authorize a
>>     >>>>> particular technology on a particular band, then one would
>>     like to
>>     >>>>> make sure that technology is fully specified and
>>     understood.  It is
>>     >>>>> not the case now with 'C-V2X'.  It is a rather new term. 
>>     Is it
>>     >>>>> only the V2X part of 3GPP?  Is it the WiFi part of it? 
>>     Which spec
>>     >>>>> is meant more precisely?
>>     >>>>>
>>     >>>>> This is why, in return, I would like to comment and request to
>>     >>>>> publicize what more precisely is it meant by C-V2X?
>>     >>>>>
>>     >>>>> 8. "We seek comment on the available technical studies on
>>     C-V2X
>>     >>>>> that should inform our consideration of C-V2X, including
>>     any recent
>>     >>>>> studies
>>     >>>>> that provide information about how C-V2X would operate in
>>     the 5.9
>>     >>>>> GHz band."
>>     >>>>>
>>     >>>>> Where are these technical studies?  Which ones?
>>     >>>>>
>>     >>>>> 9. "We first seek comment on whether to authorize C-V2X
>>     operations
>>     >>>>> in the 5.895-5.905 GHz band."
>>     >>>>>
>>     >>>>> My answer is no. C-V2X is not specified, and it is a too
>>     wide term
>>     >>>>> that might mean too many things.  If C-V2X means the WiFi
>>     part of
>>     >>>>> 3GPP, and in particular 802.11-2016, in particular OCB
>>     mode, in
>>     >>>>> particular BSM messages, then the answer is yes,
>>     definitely.  This
>>     >>>>> would also allow RFC 8691 IPv6 over 802.11-OCB to work.
>>     >>>>>
>>     >>>>> 10. "Commenters should provide detailed justification to
>>     support
>>     >>>>> specific band plan options, including the types of services
>>     that
>>     >>>>> could or could not be delivered by unlicensed use or by
>>     >>>>> vehicularrelated
>>     >>>>> services under each option."
>>     >>>>>
>>     >>>>> The type of the service that I need is the following:
>>     forming of
>>     >>>>> convoy of 3 self-driving cars - they use IPv6 over
>>     802.11-OCB on 3
>>     >>>>> distinct 5.9GHz channels in order to minimize
>>     interference.   This
>>     >>>>> could not be delivered if only one channel was available
>>     for RFC
>>     >>>>> 8691 IPv6-over-802.11-OCB.  The demo is filmed and publicly
>>     >>>>> available on the web.
>>     >>>>>
>>     >>>>> 11. "(a) DSRCS Roadside Units (RSUs) operating in the
>>     5895-5905 MHz
>>     >>>>> band must comply with the technical standard Institute of
>>     >>>>> Electrical and Electronics Engineers (IEEE) 802.11p-2010."
>>     >>>>>
>>     >>>>> This forgets that 802.11p is an old name and no longer in
>>     use.  The
>>     >>>>> users of this name neglect that IEEE 802.11-2016 is the
>>     current
>>     >>>>> spec, and which covers old 802.11p behaviour with an 'OCB'
>>     mode
>>     >>>>> (Outside the Context of a BSSID).  That is the standard
>>     that should
>>     >>>>> be referred to by this FCC Notice and not 802.11p.
>>     >>>>>
>>     >>>>> Additionally, I suggest to add the keyword 'IPv6'.  I
>>     suggest to
>>     >>>>> add a reference to RFC 8691 titled "Basic Support for IPv6
>>     Networks
>>     >>>>> Operating Outside the Context of a Basic Service Set over
>>     IEEE Std
>>     >>>>> 802.11" which is publicly available on the web.
>>     >>>>
>>     >>>> _______________________________________________
>>     >>>> its mailing list
>>     >>>> its@ietf.org <mailto:its@ietf.org>
>>     >>>> https://www.ietf.org/mailman/listinfo/its
>>     <https://www.ietf.org/mailman/listinfo/its>
>>     >>>>
>>     >>>
>>     >>> _______________________________________________
>>     >>> its mailing list
>>     >>> its@ietf.org <mailto:its@ietf.org>
>>     >>> https://www.ietf.org/mailman/listinfo/its
>>     <https://www.ietf.org/mailman/listinfo/its>
>>     >>
>>     >> _______________________________________________
>>     >> its mailing list
>>     >> its@ietf.org <mailto:its@ietf.org>
>>     >> https://www.ietf.org/mailman/listinfo/its
>>     <https://www.ietf.org/mailman/listinfo/its>
>>     >
>>     > _______________________________________________
>>     > its mailing list
>>     > its@ietf.org <mailto:its@ietf.org>
>>     > https://www.ietf.org/mailman/listinfo/its
>>     <https://www.ietf.org/mailman/listinfo/its>
>>
>>     _______________________________________________
>>     its mailing list
>>     its@ietf.org <mailto:its@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/its
>>     <https://www.ietf.org/mailman/listinfo/its>
>>
>>
>> -- 
>>
>> Yiwen (Chris) Shen, Ph.D. Candidate
>>
>> Homepage: https://chrisshen.github.io <https://chrisshen.github.io>
>>
>> IoT Lab: _http://iotlab.skku.edu <http://iotlab.skku.edu/>_
>>
>> SungkyunkwanUniversity, Suwon, South Korea
>>
>> Mobile:+82-(0)10-6871-8103
>>
>> Email: chrisshen@skku.edu
>> <mailto:chrisshen@skku.edu>
>>