From nobody Mon Apr 2 07:27:02 2018 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 CA674127909 for ; Mon, 2 Apr 2018 07:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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_LOW=-0.7, 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 RAm8IZcsSqZm for ; Mon, 2 Apr 2018 07:26:58 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 14078127869 for ; Mon, 2 Apr 2018 07:26:58 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id v194-v6so18564525itb.0 for ; Mon, 02 Apr 2018 07:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0skGwwVe7XV+1RoXIjzWGaIBVXodrBMo7xZwVqrFY04=; b=WMsOohN7s/ldAqgyclmLe46WKgj3ZJCfJ5SrW/+2K9KLmwN5IcysG39rmLG4MLkJeL L4bF1kTCvGZ2nPyIeXp9xY9z9o2wAj7sSaQW0j1mBZ6tRuy/u26FYfpuFqMkWX9QXBRP CxWtUNjb5hylz4AzoVVK9k91iOzEuE4DdN9d14NodQHPtSWwH4ppgACMzz1+x0ZuyOIL 8EKoFTY2pX7lIuBNB1X4K6pHKkUO9jW0FMK425EPLHEOxoHD7TWTGwOgtWiRszIpjhge w9vTDVCNSFpYH7o+uouuMjJRrwxTyoIXxKCVlZpEWzz7o9sX8E332rqSXtVjTn0ccs8W JivA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0skGwwVe7XV+1RoXIjzWGaIBVXodrBMo7xZwVqrFY04=; b=S1EYLHxrD+TcQjLq4vGvJZB0UzE/aSbjIMIKuVvFjEBgmLNxbuY8YqNbGx5zDCBxrx AkLBDc2g2IQDTxOL52w2kRlhcP4YyWUf5fhy3JTcVLDcbkI3S9i78Wdg6/g1iIwph8ej mWxpMjsQBszeJdS+fiDTc/vdntfvDcuGdrwQy34+AJZbhlcbj5AuNICEEooCg35lRBmv TQdOYVZXKb+/uqwLt8aHmFyjwy7zDgoL2uxzwqRrfGiz3GDbkxafYIv0M4sju4s5oZSk D7TCFprbW6gWXblBDSdxMqErY60MTXGWRj7IYXXxZUlXmEUE0yPA/vVcWkGeOWiL9aSw 1Xaw== X-Gm-Message-State: ALQs6tBA/I2ZUjBnjF38XPgf8Je+Ikw9TTTbF1qOMXmXz5Svy7RBjA75 qDDl4aJPaARm4xNj4R84YbMrUynfY/lzn6fCp8U= X-Google-Smtp-Source: AIpwx482I59jiOus/iWPGOXA0MV/qKpw4IvQlhKkOojeXmIQjv8bq3ZrJob0MOwXAUKMlZP4DgZYXrvsCWATdszXBeA= X-Received: by 2002:a24:53c4:: with SMTP id n187-v6mr1185245itb.107.1522679217283; Mon, 02 Apr 2018 07:26:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.246.87 with HTTP; Mon, 2 Apr 2018 07:26:26 -0700 (PDT) In-Reply-To: <05afff15f1c94cedabaa20212e3385b1@HE105715.emea1.cds.t-internal.com> References: <1522010744.2694.42.camel@gmail.com> <05afff15f1c94cedabaa20212e3385b1@HE105715.emea1.cds.t-internal.com> From: "Mr. Jaehoon Paul Jeong" Date: Mon, 2 Apr 2018 23:26:26 +0900 Message-ID: To: Abdussalam Baryun , Sandra Cespedes , Rex Buddenberg , Dirk.von-Hugo@telekom.de Cc: its@ietf.org, skku_iotlab_seminar@googlegroups.com, "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="000000000000da67ab0568de61dd" Archived-At: Subject: Re: [ipwave] Restructuring of the Problem Statement Document X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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, 02 Apr 2018 14:27:01 -0000 --000000000000da67ab0568de61dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi AB, Sandra, Rex, and Dirk, Thanks for your comments. With your comments, I will revise the contents of the problem statement document this week and let you know the revised one this week. Thanks. Best Regards, Paul On Tue, Mar 27, 2018 at 1:08 AM, wrote: > Dear all, > regarding the mentioned 'other aspects/problems of interest/future scope' > I think it would be worth to add a section for 5G / C-V2X (also revealed = as > an important technology) also with respect to interoperability and access > heterogeneity (and since IEEE 802.11whatsoever may be widely seen as part > of 5G access variants) and include it in the charter discussion. > Thanks! > Best Regards > Dirk > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Rex Buddenberg > Sent: Sonntag, 25. M=C3=A4rz 2018 22:46 > To: Sandra C=C3=A9spedes ; its@ietf.org > Subject: Re: [ipwave] Restructuring of the Problem Statement Document > > Agree with Sandra's observation. Recommend specifically include multicas= t > within the charter. > > > On Fri, 2018-03-23 at 21:23 -0300, Sandra C=C3=A9spedes wrote: > > > > > > On 3/23/2018 5:55 PM, Abdussalam Baryun wrote: > > > > > > > > > On Fri, Mar 23, 2018 at 11:50 AM, Mr. Jaehoon Paul Jeong > > paul@gmail.com> wrote: > > > > Hi IPWAVEers, > > > > Here is a proposed restructuring of the Problem Statement > > > > Document: > > > > https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networkin > > > > g-02 > > > > > > > > Sri and I discussed the current structure of the document. We > > > > thought the current document is too big with unnecessary content > > > > (i.e., 52 pages). > > > > We think we should reduce it to around 10 pages with concise > > > > content with > > > > > > > even if it gets to 20p it can be ok, > > > > > > > key problems for our IPWAVE WG. > > > > We come with the following structure with the revised title. > > > > > > > > --------------------------------------------------------------- > > > > --------------------------------------------- > > > > Title: IP Wireless Access in Vehicular Environments (IPWAVE): > > > > Problem Statement and Use Cases > > > > > > > I prefer we start with use cases then problems, so title: > > > > > > Title: IP Wireless Access in Vehicular Environments (IPWAVE): Use > > > Cases and Problem Statements > > > > > > > > > > > Abstract > > > > 1. Introduction > > > > 2. Terminology > > > > //each item: at most 4 lines > > > > 3. Use Cases: V2V, V2I, V2X > > > > 4. Current Architectures and Protocols > > > > - General Problems: Latency, No security, No pseudonym handling, > > > > No IP support, ... > > > > > > > why architecture in this draft, I suggest take this out, it is > > > better in another draft, just focus on the aim an objectives of the > > > draft, the architecture needs another draft so if we update in > > > future we just update architecture or update use cases, > > > > > > > > > > 5. Problem Exploration > > > > - IPv6 over IEEE 802.11-OCB > > > > - Neighbor Discovery > > > > . Link Model > > > > .. MAC Address Pseudonym > > > > . Prefix Dissemination/Exchange > > > > . Routing > > > > - Mobility Management > > > > . E2E Connectivity over V2I > > > > - Vehicle Identity Management > > > > - Multihop V2X > > > > - Service Discovery > > > > - Security and Privacy > > > > - Others > > > > > > > please make them as problem statements sections so 5.1, 5.2, ..... > > > also they need to cover our available charter only, > > During the meeting in London the suggestion was to consider not only > > the current charter but also other aspects/problems of interest/future > > scope for this group. > > > > > > > 6. Security Considerations > > > > --------------------------------------------------------------- > > > > --------------------------------------------- > > > > > > > > Please give us your comments on it. > > > > > > > > With the agreed content, we authors will move forward for the > > > > documentation.. > > > > > > > > > > > thanks > > > > > > AB > > > > > > > > > > Thanks. > > > > > > > > Best Regards, > > > > Paul > > > > -- > > > > =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. > > > > Assistant 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.ph > > > > p > > > > > > > > _______________________________________________ > > > > its mailing list > > > > its@ietf.org > > > > https://www.ietf.org/mailman/listinfo/its > > > > > > > > > > > > > > > > > _______________________________________________ > > > its mailing list > > > its@ietf.org > > > https://www.ietf.org/mailman/listinfo/its > > Libre de virus. www.avast.com > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --=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. Assistant 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 --000000000000da67ab0568de61dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi AB, Sandra, Rex, and Dirk,
Thanks for your comments= .

With your comments, I will revise the contents o= f the problem statement document=C2=A0
this week and let you know= the revised one this week.

Thanks.

=
Best Regards,
Paul
On Tue, Mar 27, 2018 at 1:08 AM, <Dirk= .von-Hugo@telekom.de> wrote:

-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On Behalf Of Rex Buddenberg
Sent: Sonntag, 25. M=C3=A4rz 2018 22:46
To: Sandra C=C3=A9spedes <scespedes@ing.uchile.cl>; its@ietf.org
Subject: Re: [ipwave] Restructuring of the Problem Statement Document

Agree with Sandra's observation.=C2=A0 Recommend specifically include m= ulticast within the charter.


On Fri, 2018-03-23 at 21:23 -0300, Sandra C=C3=A9spedes wrote:
>
> =C2=A0
> On 3/23/2018 5:55 PM, Abdussalam Baryun wrote:
> >
> >
> > On Fri, Mar 23, 2018 at 11:50 AM, Mr. Jaehoon Paul Jeong <jaeh= oon..
> > paul@gmail.co= m> wrote:
> > > Hi IPWAVEers,
> > > Here is a proposed restructuring of the Problem Statement > > > Document:
> > > https://tools.ietf.o= rg/html/draft-ietf-ipwave-vehicular-networkin
> > > g-02
> > >
> > > Sri and I discussed the current structure of the document. W= e
> > > thought the current document is too big with unnecessary con= tent
> > > (i.e., 52 pages).
> > > We think we should reduce it to around 10 pages with concise=
> > > content with
> > >
> > even if it gets to 20p it can be ok,
> > =C2=A0
> > > key problems for our IPWAVE WG.
> > > We come with the following structure with the revised title.=
> > >
> > > -------------------------------------------------------= --------
> > > ---------------------------------------------
> > > Title: IP Wireless Access in Vehicular Environments (IPWAVE)= :
> > > Problem Statement and Use Cases
> > >
> > I prefer we start with use cases then problems, so title:
> >
> > =C2=A0Title: IP Wireless Access in Vehicular Environments (IPWAVE= ): Use
> > Cases and Problem Statements
> > =C2=A0
> > >
> > > Abstract
> > > 1. Introduction
> > > 2. Terminology
> > > =C2=A0 =C2=A0//each item: at most 4 lines
> > > 3. Use Cases: V2V, V2I, V2X
> > > 4. Current Architectures and Protocols
> > > =C2=A0- General Problems: Latency, No security, No pseudonym= handling,
> > > No IP support, ...
> > >
> > why architecture in this draft, I suggest take this out, it is > > better in another draft, just focus on the aim an objectives of t= he
> > draft, the architecture needs another draft so if we update in > > future we just update architecture or update use cases,
> >
> > =C2=A0
> > > 5. Problem Exploration
> > > =C2=A0- IPv6 over IEEE 802.11-OCB
> > > =C2=A0- Neighbor Discovery
> > > =C2=A0 =C2=A0. Link Model
> > > =C2=A0 =C2=A0.. MAC Address Pseudonym
> > > =C2=A0 =C2=A0. Prefix Dissemination/Exchange
> > > =C2=A0 =C2=A0. Routing
> > > =C2=A0- Mobility Management
> > > =C2=A0 =C2=A0. E2E Connectivity over V2I
> > > =C2=A0- Vehicle Identity Management
> > > =C2=A0- Multihop V2X
> > > =C2=A0- Service Discovery
> > > =C2=A0- Security and Privacy
> > > =C2=A0- Others
> > >
> > please make them as problem statements sections so 5.1, 5.2, ....= .
> > also they need to cover our available charter only,
> =C2=A0During the meeting in London the suggestion was to consider not = only
> the current charter but also other aspects/problems of interest/future=
> scope for this group.
> > =C2=A0
> > > =C2=A06. Security Considerations
> > > -------------------------------------------------------= --------
> > > ---------------------------------------------
> > >
> > > Please give us your comments on it.
> > >
> > > With the agreed content, we authors will move forward for th= e
> > > documentation..
> > >
> > >
> > thanks
> >
> > AB
> >
> > =C2=A0
> > > Thanks.
> > >
> > > Best Regards,
> > > Paul
> > > --
> > > =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.
> > > Assistant 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.ph
> > > p
> > >
> > > _______________________________________________
> > > its mailing list
> > > its@ietf.o= rg
> > > https://www.ietf.org/mailman/listinfo/i= ts
> > >
> > >
> >
> >
> > _______________________________________________
> > its mailing list
> > its@ietf.org
> > https://www.ietf.org/mailman/listinfo/its
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Libre de virus. www.avast.com
> =C2=A0_______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
_______________________________________________
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.
Assistant Professor
Departm= ent of Software
Sungkyunkwan University
Office: +82-31-299-4957
Em= ail: jaehoon.pa= ul@gmail.com,=C2=A0pauljeong@skku.edu
P= ersonal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
--000000000000da67ab0568de61dd-- From nobody Sat Apr 7 18:24:03 2018 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 6088912741D for ; Sat, 7 Apr 2018 18:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_PASS=-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 invw1gT8YpRR for ; Sat, 7 Apr 2018 18:23:59 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 ECCCB12711A for ; Sat, 7 Apr 2018 18:23:58 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id l18so5386072qtj.1 for ; Sat, 07 Apr 2018 18:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=MRMagi2WqsppLimaWreIj5cXZEm+L+gFFhCUo1Ed8Mc=; b=A5hchtJjsXJRTad9fSORGDI0fdm99aG4EcrRL/yKbdrndy31c9BxShiXNyvrLxS5Tx gJUOk8ANnrb80vCIGIFF0c4OdqEJuy79Sxyg3xS6OBJcTMJ84nrow0rCbQyLn0PAkQr8 W9daFvs7OBaO4bUlxu9r0yZOlp/o/NT7XuHDQI2hFSAkVzqo6RC4+UUagFH/4gCpnwB0 bdBoN4mXvvFfWkVjJ+/7PUZykObb68+7WU5GncDDsTxHsTAIG30XhhUibI5qla/JKLiq 7K33P0yMVPGXDYz9GRa9BiUSBFHmeNu6gErToz80R1U5UFJ8SBPMtauy2Wb/v8h6VeOP SElg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=MRMagi2WqsppLimaWreIj5cXZEm+L+gFFhCUo1Ed8Mc=; b=NpTWwKUr/Ui18JOz1lKxyMCgzhsp0UsX7OqmVUEOu7AFhq12xjyHb6pCR+rmWPGNzT IZHcd3D9EZ+CHBDRkV8A02mt3Yl6qH9/G8I4URHKUQIoiKYTGmxj6g0ykeXWqaNXqVGH /MSJlKsS9Q/XloDmeKnG39KEjdMX0iWzwshnfYo6y5n02NWaWmQNa7RD5icIkKSDGozR KYE8K5wNzIVZ/ueRy9ZUELVe/ayS/dsLEaTkw9s3XkuZWgFgBrV51LZ5Juxj45cTKciv oZenZjDpfP1Lv5QYfK3iZ/7j75hEr92drodBQy372so6yYnTGc0wY3SiuujxaDL3pm8Q J4+Q== X-Gm-Message-State: ALQs6tB8bIXRVUgxGuAFMcUy801KnSs2XWcmcECaiwk8Wwfy+anGLXyZ ep7SDCVnEy/LagmO/Df909E= X-Google-Smtp-Source: AIpwx4+3uwUdtCBhvinfUQU6c0LrKrbj1X/8imL1DF1A7JlxRLK04eN39hpv9/cisw9EmWz9by8OUA== X-Received: by 10.237.58.131 with SMTP id o3mr18446803qte.4.1523150638149; Sat, 07 Apr 2018 18:23:58 -0700 (PDT) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id r41sm11057379qtc.76.2018.04.07.18.23.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Apr 2018 18:23:57 -0700 (PDT) From: =?UTF-8?Q?Fran=C3=A7ois_Simon?= To: , Cc: "'Russ Housley'" , References: <660BFCF2CF184B2C8ACA0743EA9BBB54@SRA6> <006a01d3c056$43e26fb0$cba74f10$@gmail.com> In-Reply-To: Date: Sat, 7 Apr 2018 21:23:56 -0400 Message-ID: <021601d3ced8$43e7d140$cbb773c0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0217_01D3CEB6.BCD63140" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHXMIgblr0a3rEHaZ5YiKmP3jMrRwMGPU2vAh/dJ4gBJhV6ygG1LWmWAfQF/7cDKPxyCKOGW4PQ Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 08 Apr 2018 01:24:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0217_01D3CEB6.BCD63140 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable .... on Ch172.... and Ch184. -----Original Message----- From: dickroy@intellicommunications.com = =20 Sent: Tuesday, March 20, 2018 10:43 AM To: tony.li@tony.li Cc: Fran=C3=83=C2=A7ois Simon ; Russ Housley = ; its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data Highest priority is ensured by channel usage regulations ... e.g. only = V2V and V2I safety on Ch172 and on that channel, using the various = priorities can be useful for priority-relative safety apps. All other = channels can be prioritized as well as they are service channels. That said, ANYTHING the IETF says about this will be ignored, believe = me.=20 J2945/1 and others will apply and they are m ost assuredly using ALL = prioities. > > What would make more sense? You do not want people using higher = priority. > If you don=C3=A2=E2=82=AC=E2=84=A2t say MUST, then everything will be = marked as voice. > > T > > >> On Mar 20, 2018, at 2:18 PM, Fran=C3=83=C2=A7ois Simon = > wrote: >> >> MUST ..... AC_BK does not make sense. Fygs >> >> -----Original Message----- >> From: its > On = Behalf Of Russ Housley >> Sent: Monday, March 19, 2018 11:14 AM >> To: its@ietf.org =20 >> Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data >> >> In the session earlier today, Alex offered text to resolve this = topic. >> He said: >> >> The IPv6 packet transmitted on 802.11-OCB MUST be immediately = preceded >> by a Logical Link Control (LLC) header and an 802.11 header. In = the >> LLC header, and in accordance with the EtherType Protocol >> Discrimination (EPD), the value of the Type field MUST be set to >> 0x86DD (IPv6). In the 802.11 header, the value of the Subtype >> sub-field in the Frame Control field MUST be set to 8 (i.e. 'QoS >> Data'); the value of the Traffic Identifier (TID) sub-field of the = QoS >> Control field of the 802.11 header MUST be set to binary 001 (i.e. >> User Priority 'Background', QoS Access Category 'AC_BK'). >> >> No one in the room raised any concern with this text. If you have a=20 >> concern, please speak on the list now. >> >> In a another part of the meeting, J=C3=83=C2=A9r=C3=83=C2=B4me talked = about Mapping IP to=20 >> Access Category in 802.11-OCB. It was pointed out that RFC 8325 was=20 >> recently published on the standards track. Tony Li pointed out that=20 >> there is no integrity protection for these bits. >> >> As an individual, I wonder if it would be better to say something = like: >> If DiffServ is being used, set the QoS Access Category as described=20 >> in RFC 8325, otherwise set the QoS Access Category of 'AC_BK'. >> >> What do others think? >> >> Russ >> >> _______________________________________________ >> its mailing list >> its@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/its >> >> _______________________________________________ >> its mailing list >> its@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ > its mailing list > its@ietf.org =20 > https://www.ietf.org/mailman/listinfo/its > ------=_NextPart_000_0217_01D3CEB6.BCD63140 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable RE: [ipwave] 802.11 Data vs 802.11 QoS Data

.... on Ch172.... and Ch184.

-----Original = Message-----
From: dickroy@intellicommunications.com = <dickroy@intellicommunications.com>
Sent: Tuesday, March 20, 2018 10:43 AM
To: tony.li@tony.li
Cc: Fran=C3=83=C2=A7ois Simon <fygsimon@gmail.com>; Russ Housley = <housley@vigilsec.com>; its@ietf.org
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data

Highest = priority is ensured by channel usage regulations ... e.g. only V2V and = V2I safety on Ch172 and on that channel, using the various priorities = can be useful for priority-relative safety apps.  All other = channels can be prioritized as well as they are service = channels.

That said, = ANYTHING the IETF says about this will be ignored, believe me. =

J2945/1 and = others will apply and they are m ost assuredly using ALL = prioities.

>

> What would = make more sense?  You do not want people using higher = priority.

> If you = don=C3=A2=E2=82=AC=E2=84=A2t say MUST, then everything will be marked as = voice.

>

> = T

>

>

>> On Mar = 20, 2018, at 2:18 PM, Fran=C3=83=C2=A7ois Simon <fygsimon@gmail.com> wrote:

>>

>> MUST = ..... AC_BK does not make sense.    = Fygs

>>

>> = -----Original Message-----

>> From: = its <its-bounces@ietf.org> On Behalf Of Russ Housley

>> Sent: = Monday, March 19, 2018 11:14 AM

>> = To: its@ietf.org

>> = Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data

>>

>> In the = session earlier today, Alex offered text to resolve this = topic.

>> He = said:

>>

>>   The IPv6 packet transmitted on = 802.11-OCB MUST be immediately preceded

>>   by a Logical Link Control (LLC) = header and an 802.11 header.  In the

>>   LLC header, and in accordance with = the EtherType Protocol

>>   Discrimination (EPD), the value of = the Type field MUST be set to

>>   0x86DD (IPv6).  In the 802.11 = header, the value of the Subtype

>>   sub-field in the Frame Control = field MUST be set to 8 (i.e. 'QoS

>>   Data'); the value of the Traffic = Identifier (TID) sub-field of the QoS

>>   Control field of the 802.11 header = MUST be set to binary 001 (i.e.

>>   User Priority 'Background', QoS = Access Category 'AC_BK').

>>

>> No one = in the room raised any concern with this text.  If you have a =

>> = concern, please speak on the list now.

>>

>> In a = another part of the meeting, J=C3=83=C2=A9r=C3=83=C2=B4me talked about = Mapping IP to

>> Access = Category in 802.11-OCB.  It was pointed out that RFC 8325 was =

>> = recently published on the standards track.  Tony Li pointed out = that

>> there = is no integrity protection for these bits.

>>

>> As an = individual, I wonder if it would be better to say something = like:

>> If = DiffServ is being used, set the QoS Access Category as described =

>> in RFC = 8325, otherwise set the QoS Access Category of = 'AC_BK'.

>>

>> What = do others think?

>>

>> = Russ

>>

>> = _______________________________________________

>> its = mailing list

>> its@ietf.org

>> https://www.ietf.org/mailman/listinfo/its<= SPAN LANG=3D"en-us">

>>

>> = _______________________________________________

>> its = mailing list

>> its@ietf.org

>> https://www.ietf.org/mailman/listinfo/its<= SPAN LANG=3D"en-us">

>

> = _______________________________________________

> its = mailing list

> its@ietf.org

> https://www.ietf.org/mailman/listinfo/its<= SPAN LANG=3D"en-us">

>

------=_NextPart_000_0217_01D3CEB6.BCD63140-- From nobody Sun Apr 8 18:19:34 2018 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 1DFC6126C83 for ; Sun, 8 Apr 2018 18:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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_LOW=-0.7, 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 Zz-M_1fQwaqE for ; Sun, 8 Apr 2018 18:19:29 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 F2DA1126BF0 for ; Sun, 8 Apr 2018 18:19:28 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id x77so7691437ioi.2 for ; Sun, 08 Apr 2018 18:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JKiEqOETX5lXLEntYGzjJaq8oROTrDj19o3zzkFuQQw=; b=ZA/2sZXmnrzw3iPb1UsYtNAOPN7HcJN34+4MYR6RenNuutcpdZ9R7nvaccdZBbmeCq Squn/q3HKMR3H5DQyuGxYw3ZUXPOASeGbe1VpTF5x62RyOdpvwHeQDvxkpi022DmeKk7 b5e12J43hWHy46hpnTb8I1yu+BUIkobhr9lYexSVnlxCGa5ysZ+hb2fgPvtNhXy+lJix okgyAm7bgLHPVElMjGg/CYbaCTuiIQeRxTnVytPFhWDHpNrpnV28S0HVoM0hRh2nhsMQ oSatjSweKEf3nMGF1O0FgsgHJKkcJoBnayXZlPeOzfb3kYHAqtbW8MTeUiXL0f5fIOhT v5rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JKiEqOETX5lXLEntYGzjJaq8oROTrDj19o3zzkFuQQw=; b=AVoquZBreF8MggyR1E6CQUfmmZzzjmFAVte0Yv3K/BdzN3Z7Cq57qU1tkw/hWnIbfB ZeB7jxTOAXqyO1zvOOtFzzaqQ8M0k44wdBVBrWpn9f4K4fIch5mpseKyK43Bl5O6HXqM p3+HPjhcptNpe1EOMwGXXixV/orjwzD77O9ZBQxlE6vU4pMrrizXXWsWKcBxYI/lu5RB +jjI7woiM/B83s7T2dX6RdxAohdcer4xPc7dpvVCa1HBZ0wmghTKocGaolk6xn5vgQMQ OOZpAgOr6qBn4G/5lTyuTdSTui8K0Wlq40CC+ki8HheUxTIvGYDrnTDArjjzOYdn7FF8 zimw== X-Gm-Message-State: AElRT7FkjO9OPt2LxamTjRxMBthn5lqHm/ddcJz80CWevAcL2WuaWqmm dIg0v60D14e4MJIoGacapmY0Kq268gSRf4pUmuEGqg== X-Google-Smtp-Source: AIpwx48wpvmoP0FFdVQy49XzuGZGGCogMQinjhUjgVgmQC86AG+HM6yK/G/Q9bd+x5N/M3FhRBzuF7q8pmdT9gJ5Xc4= X-Received: by 10.107.58.11 with SMTP id h11mr33562986ioa.283.1523236767975; Sun, 08 Apr 2018 18:19:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.246.87 with HTTP; Sun, 8 Apr 2018 18:18:57 -0700 (PDT) In-Reply-To: References: <1522010744.2694.42.camel@gmail.com> <05afff15f1c94cedabaa20212e3385b1@HE105715.emea1.cds.t-internal.com> From: "Mr. Jaehoon Paul Jeong" Date: Mon, 9 Apr 2018 10:18:57 +0900 Message-ID: To: its@ietf.org, Abdussalam Baryun , Sandra Cespedes , Rex Buddenberg , Dirk.von-Hugo@telekom.de Cc: skku_iotlab_seminar@googlegroups.com, "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="001a114aca7476cbff05696032ca" Archived-At: Subject: Re: [ipwave] Restructuring of the Problem Statement Document X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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, 09 Apr 2018 01:19:32 -0000 --001a114aca7476cbff05696032ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi IPWAVEers, Here is the revised contents structure for our problem statement document, based on the comments from AB, Sandra, Rex, and Dirk: ---------------------------------------------------------------------------= -------------------- Title: IP Wireless Access in Vehicular Environments (IPWAVE): Use Cases and Problem Statement Abstract 1. Introduction 2. Terminology (Note: each item has at most 4 lines.) 3. Use Cases 3.1 V2V 3.2 V2I 3.3 V2X 4. Analysis for Current Protocols 4.1 Current Protocols for Vehicular Networking 4.2 General Problems . Latency . No Security . No Pseudonym Handling . No IP Support 5. Problem Exploration 5.1 IPv6 over IEEE 802.11-OCB 5.2 Neighbor Discovery . Link Model . MAC Address Pseudonym . Prefix Dissemination/Exchange . Routing 5.3 Mobility Management . E2E Connectivity over V2I 5.4 Vehicle Identity Management 5.5 Multihop V2X 5.6 Multicast 5.7 DNS Naming Services and Service Discovery 5.8 IPv6 over Cellular Networks . Cellular V2X (C-V2X) Using 4G-LTE . Cellular V2X (C-V2X) Using 5G 5.9 Security and Privacy 6. Security Considerations ---------------------------------------------------------------------------= -------------------- If you don't have further comments, I will work for the revision of our document with the above contents along with the co-authors. Thanks. Best Regards, Paul On Mon, Apr 2, 2018 at 11:26 PM, Mr. Jaehoon Paul Jeong < jaehoon.paul@gmail.com> wrote: > Hi AB, Sandra, Rex, and Dirk, > Thanks for your comments. > > With your comments, I will revise the contents of the problem statement > document > this week and let you know the revised one this week. > > Thanks. > > Best Regards, > Paul > > On Tue, Mar 27, 2018 at 1:08 AM, wrote: > >> Dear all, >> regarding the mentioned 'other aspects/problems of interest/future scope= ' >> I think it would be worth to add a section for 5G / C-V2X (also revealed= as >> an important technology) also with respect to interoperability and acces= s >> heterogeneity (and since IEEE 802.11whatsoever may be widely seen as par= t >> of 5G access variants) and include it in the charter discussion. >> Thanks! >> Best Regards >> Dirk >> >> -----Original Message----- >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Rex Buddenberg >> Sent: Sonntag, 25. M=C3=A4rz 2018 22:46 >> To: Sandra C=C3=A9spedes ; its@ietf.org >> Subject: Re: [ipwave] Restructuring of the Problem Statement Document >> >> Agree with Sandra's observation. Recommend specifically include >> multicast within the charter. >> >> >> On Fri, 2018-03-23 at 21:23 -0300, Sandra C=C3=A9spedes wrote: >> > >> > >> > On 3/23/2018 5:55 PM, Abdussalam Baryun wrote: >> > > >> > > >> > > On Fri, Mar 23, 2018 at 11:50 AM, Mr. Jaehoon Paul Jeong > > > paul@gmail.com> wrote: >> > > > Hi IPWAVEers, >> > > > Here is a proposed restructuring of the Problem Statement >> > > > Document: >> > > > https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networkin >> > > > g-02 >> > > > >> > > > Sri and I discussed the current structure of the document. We >> > > > thought the current document is too big with unnecessary content >> > > > (i.e., 52 pages). >> > > > We think we should reduce it to around 10 pages with concise >> > > > content with >> > > > >> > > even if it gets to 20p it can be ok, >> > > >> > > > key problems for our IPWAVE WG. >> > > > We come with the following structure with the revised title. >> > > > >> > > > --------------------------------------------------------------- >> > > > --------------------------------------------- >> > > > Title: IP Wireless Access in Vehicular Environments (IPWAVE): >> > > > Problem Statement and Use Cases >> > > > >> > > I prefer we start with use cases then problems, so title: >> > > >> > > Title: IP Wireless Access in Vehicular Environments (IPWAVE): Use >> > > Cases and Problem Statements >> > > >> > > > >> > > > Abstract >> > > > 1. Introduction >> > > > 2. Terminology >> > > > //each item: at most 4 lines >> > > > 3. Use Cases: V2V, V2I, V2X >> > > > 4. Current Architectures and Protocols >> > > > - General Problems: Latency, No security, No pseudonym handling, >> > > > No IP support, ... >> > > > >> > > why architecture in this draft, I suggest take this out, it is >> > > better in another draft, just focus on the aim an objectives of the >> > > draft, the architecture needs another draft so if we update in >> > > future we just update architecture or update use cases, >> > > >> > > >> > > > 5. Problem Exploration >> > > > - IPv6 over IEEE 802.11-OCB >> > > > - Neighbor Discovery >> > > > . Link Model >> > > > .. MAC Address Pseudonym >> > > > . Prefix Dissemination/Exchange >> > > > . Routing >> > > > - Mobility Management >> > > > . E2E Connectivity over V2I >> > > > - Vehicle Identity Management >> > > > - Multihop V2X >> > > > - Service Discovery >> > > > - Security and Privacy >> > > > - Others >> > > > >> > > please make them as problem statements sections so 5.1, 5.2, ..... >> > > also they need to cover our available charter only, >> > During the meeting in London the suggestion was to consider not only >> > the current charter but also other aspects/problems of interest/future >> > scope for this group. >> > > >> > > > 6. Security Considerations >> > > > --------------------------------------------------------------- >> > > > --------------------------------------------- >> > > > >> > > > Please give us your comments on it. >> > > > >> > > > With the agreed content, we authors will move forward for the >> > > > documentation.. >> > > > >> > > > >> > > thanks >> > > >> > > AB >> > > >> > > >> > > > Thanks. >> > > > >> > > > Best Regards, >> > > > Paul >> > > > -- >> > > > =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. >> > > > Assistant 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.ph >> > > > p >> > > > >> > > > _______________________________________________ >> > > > its mailing list >> > > > its@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/its >> > > > >> > > > >> > > >> > > >> > > _______________________________________________ >> > > its mailing list >> > > its@ietf.org >> > > https://www.ietf.org/mailman/listinfo/its >> > Libre de virus. www.avast.com >> > _______________________________________________ >> > its mailing list >> > its@ietf.org >> > https://www.ietf.org/mailman/listinfo/its >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> _______________________________________________ >> 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. > Assistant 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 > > --=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. Assistant 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 --001a114aca7476cbff05696032ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi IPWAVEers,
Here is the revised contents structure f= or our problem statement document,=C2=A0
based on the comments fr= om AB, Sandra, Rex, and Dirk:

--------------------= ---------------------------------------------------------------------------=
Title: IP Wireless Access in Vehicular Environments (IPWAVE= ): Use Cases and Problem Statement

Abstract
<= div>1. Introduction
2. Terminology
=C2=A0 =C2=A0(Note: = each item has at most 4 lines.)
3. Use Cases
=C2=A03.1 = V2V
=C2=A03.2 V2I
=C2=A03.3 V2X
4. Analysis f= or Current Protocols
=C2=A04.1 Current Protocols for Vehicular Ne= tworking
=C2=A04.2 General Problems
=C2=A0 =C2=A0. Late= ncy
=C2=A0 =C2=A0. No Security
=C2=A0 =C2=A0. No Pseudo= nym Handling
=C2=A0 =C2=A0. No IP Support=C2=A0
5. Prob= lem Exploration
=C2=A05.1 IPv6 over IEEE 802.11-OCB
=C2= =A05.2 Neighbor Discovery
=C2=A0 =C2=A0. Link Model
=C2= =A0 =C2=A0. MAC Address Pseudonym
=C2=A0 =C2=A0. Prefix Dissemina= tion/Exchange
=C2=A0 =C2=A0. Routing
=C2=A05.3 Mobility= Management
=C2=A0 =C2=A0. E2E Connectivity over V2I
= =C2=A05.4 Vehicle Identity Management=C2=A0=C2=A0
=C2=A05.5 Multi= hop V2X
=C2=A05.6 Multicast
=C2=A05.7 DNS Naming Servic= es and Service Discovery
=C2=A05.8 IPv6 over Cellular Networks
=C2=A0 =C2=A0. Cellular V2X (C-V2X) Using 4G-LTE
=C2=A0 = =C2=A0. Cellular V2X (C-V2X) Using 5G=C2=A0
=C2=A05.9 Security an= d Privacy
=C2=A06. Security Considerations
-------------------------------------------------= ----------------------------------------------=C2=A0
=C2= =A0 =C2=A0
If you don't have further comments, I will work = for the revision of our document=C2=A0
with the above contents al= ong with the co-authors.

Thanks.

Best Regards,
Paul
=
On Mon, Apr 2, 2018 at 11:26 PM, Mr. Jaehoon= Paul Jeong <jaehoon.paul@gmail.com> wrote:
Hi AB, Sandra, Rex, and Dirk,
T= hanks for your comments.

With your comments, I wil= l revise the contents of the problem statement document=C2=A0
thi= s week and let you know the revised one this week.

Thanks.

Best Regards,
Paul

O= n Tue, Mar 27, 2018 at 1:08 AM, <Dirk.von-Hugo@telekom.de><= /span> wrote:
Dear all,
regarding the mentioned 'other aspects/problems of interest/future scop= e' I think it would be worth to add a section for 5G / C-V2X (also reve= aled as an important technology) also with respect to interoperability and = access heterogeneity (and since IEEE 802.11whatsoever may be widely seen as= part of 5G access variants) and include it in the charter discussion.
Thanks!
Best Regards
Dirk

-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On Behalf Of Rex Buddenberg
Sent: Sonntag, 25. M=C3=A4rz 2018 22:46
To: Sandra C=C3=A9spedes <scespedes@ing.uchile.cl>; its@ietf.org
Subject: Re: [ipwave] Restructuring of the Problem Statement Document

Agree with Sandra's observation.=C2=A0 Recommend specifically include m= ulticast within the charter.


On Fri, 2018-03-23 at 21:23 -0300, Sandra C=C3=A9spedes wrote:
>
> =C2=A0
> On 3/23/2018 5:55 PM, Abdussalam Baryun wrote:
> >
> >
> > On Fri, Mar 23, 2018 at 11:50 AM, Mr. Jaehoon Paul Jeong <jaeh= oon..
> > paul@gmail.co= m> wrote:
> > > Hi IPWAVEers,
> > > Here is a proposed restructuring of the Problem Statement > > > Document:
> > > https://tools.ietf.o= rg/html/draft-ietf-ipwave-vehicular-networkin
> > > g-02
> > >
> > > Sri and I discussed the current structure of the document. W= e
> > > thought the current document is too big with unnecessary con= tent
> > > (i.e., 52 pages).
> > > We think we should reduce it to around 10 pages with concise=
> > > content with
> > >
> > even if it gets to 20p it can be ok,
> > =C2=A0
> > > key problems for our IPWAVE WG.
> > > We come with the following structure with the revised title.=
> > >
> > > -------------------------------------------------------= --------
> > > ---------------------------------------------
> > > Title: IP Wireless Access in Vehicular Environments (IPWAVE)= :
> > > Problem Statement and Use Cases
> > >
> > I prefer we start with use cases then problems, so title:
> >
> > =C2=A0Title: IP Wireless Access in Vehicular Environments (IPWAVE= ): Use
> > Cases and Problem Statements
> > =C2=A0
> > >
> > > Abstract
> > > 1. Introduction
> > > 2. Terminology
> > > =C2=A0 =C2=A0//each item: at most 4 lines
> > > 3. Use Cases: V2V, V2I, V2X
> > > 4. Current Architectures and Protocols
> > > =C2=A0- General Problems: Latency, No security, No pseudonym= handling,
> > > No IP support, ...
> > >
> > why architecture in this draft, I suggest take this out, it is > > better in another draft, just focus on the aim an objectives of t= he
> > draft, the architecture needs another draft so if we update in > > future we just update architecture or update use cases,
> >
> > =C2=A0
> > > 5. Problem Exploration
> > > =C2=A0- IPv6 over IEEE 802.11-OCB
> > > =C2=A0- Neighbor Discovery
> > > =C2=A0 =C2=A0. Link Model
> > > =C2=A0 =C2=A0.. MAC Address Pseudonym
> > > =C2=A0 =C2=A0. Prefix Dissemination/Exchange
> > > =C2=A0 =C2=A0. Routing
> > > =C2=A0- Mobility Management
> > > =C2=A0 =C2=A0. E2E Connectivity over V2I
> > > =C2=A0- Vehicle Identity Management
> > > =C2=A0- Multihop V2X
> > > =C2=A0- Service Discovery
> > > =C2=A0- Security and Privacy
> > > =C2=A0- Others
> > >
> > please make them as problem statements sections so 5.1, 5.2, ....= .
> > also they need to cover our available charter only,
> =C2=A0During the meeting in London the suggestion was to consider not = only
> the current charter but also other aspects/problems of interest/future=
> scope for this group.
> > =C2=A0
> > > =C2=A06. Security Considerations
> > > -------------------------------------------------------= --------
> > > ---------------------------------------------
> > >
> > > Please give us your comments on it.
> > >
> > > With the agreed content, we authors will move forward for th= e
> > > documentation..
> > >
> > >
> > thanks
> >
> > AB
> >
> > =C2=A0
> > > Thanks.
> > >
> > > Best Regards,
> > > Paul
> > > --
> > > =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.
> > > Assistant 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.ph
> > > p
> > >
> > > _______________________________________________
> > > its mailing list
> > > its@ietf.o= rg
> > > https://www.ietf.org/mailman/listinfo/i= ts
> > >
> > >
> >
> >
> > _______________________________________________
> > its mailing list
> > its@ietf.org
> > https://www.ietf.org/mailman/listinfo/its
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Libre de virus. www.avast.com
> =C2=A0_______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
_______________________________________________
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.
Assistant= 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



--
=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) Jeon= g, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan U= niversity
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.s= kku.edu/people-jaehoon-jeong.php
--001a114aca7476cbff05696032ca-- From nobody Mon Apr 9 06:31:30 2018 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 58C38127873 for ; Mon, 9 Apr 2018 06:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=us-toyota-itc-com.20150623.gappssmtp.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 pkqA1HcL9dS5 for ; Mon, 9 Apr 2018 06:31:20 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 BC9821270AB for ; Mon, 9 Apr 2018 06:31:20 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id m134-v6so11008651itb.3 for ; Mon, 09 Apr 2018 06:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=us-toyota-itc-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=00QozSB+YM4DaTNO8P8a1iweWB3sSn/luE4bluWE0Zk=; b=txyTp3NFOb3arEwUjhMvSFKEN695OQxNgOXfeGJn/oMq4oOV2DBkRrHv184x/bfCCx ltNIv0EHCvXm5+Ve1wTnVe22i+MhYNgwgcRCDFgpnr4b2caLlxM6e7eSQrmKJuUCEd+J dzN5QBqEHHZRPbZTGqnMjv1XJaVT9O8pZt1n/gzi+qJAddODQniYsA6V2KixacF7+sR0 ci1PbBsBGWi2k6KcnUcZ+kxxGikl70zw+ktqY0jA5n8YgsbaRxvEKzDoEQNwLyKFX6Tp LZtpmSEFq1vCbbjSZwXftX3caXAbGMPcaAz5Xuhap+0D4UPdW2dPypEzIBkHKyICK4aj yC6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=00QozSB+YM4DaTNO8P8a1iweWB3sSn/luE4bluWE0Zk=; b=GMtoabKliep2l3te4sjVhaO9H49al6YahexxRgzcQiLuCuhInZKzDv2LzcFCaOfItJ d1F/ol8hHaqgB7CPKYm6asjA9whiQfodV3xNNPKLdFho/Fx8LDzXLlP0VgoLjuyz9G2O GY5tobAippsRZS45BEn/aXLrB0Ie/8ito5tBzIpk+KKhyjbiMjpzDXqUXH+TACSB3EB7 CoK4EA0Fq+e6P/oaERhCyj4Ka9o+3radqcOyj8zs7rVr00zDzfzcRKuthqSR4FvcTr0K +XaencQL9sHr7dVHSsnCW77xtSCrP74/ZKUrJzFYzXJK+o05vop0K4BNrJhCmiFFPx1d 56Ag== X-Gm-Message-State: ALQs6tCG5/wXoIc7cRLW5mh4WdZtkF37PZIvy+QdfBacK1RepzL3kX9h rscJb61PisqT7KMHo3FVHa3JVIOLmJ1J4dKRIn9AGg== X-Google-Smtp-Source: AIpwx4/A2zc4qBM6O6kQg7bXWvo+XDyPn9Zyw3tHnYPSNUkuwwI4nAO6gLjV+dUtmWOxGbyprUPoRBT6D2DnvThoIz0= X-Received: by 2002:a24:2c52:: with SMTP id i79-v6mr29944693iti.101.1523280679670; Mon, 09 Apr 2018 06:31:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.24.213 with HTTP; Mon, 9 Apr 2018 06:31:19 -0700 (PDT) In-Reply-To: References: <1522010744.2694.42.camel@gmail.com> <05afff15f1c94cedabaa20212e3385b1@HE105715.emea1.cds.t-internal.com> From: John Kenney Date: Mon, 9 Apr 2018 06:31:19 -0700 Message-ID: To: "Mr. Jaehoon Paul Jeong" Cc: its , Abdussalam Baryun , Sandra Cespedes , Rex Buddenberg , Dirk.von-Hugo@telekom.de, skku_iotlab_seminar@googlegroups.com Content-Type: multipart/alternative; boundary="000000000000ce2aa105696a6bbb" Archived-At: Subject: Re: [ipwave] Restructuring of the Problem Statement Document X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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, 09 Apr 2018 13:31:28 -0000 --000000000000ce2aa105696a6bbb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jaehoon, Reading the contents outline, I could infer that IETF considers that a "general problem" with "current protocols for vehicular networking" is that there is "no security." Is that a correct inference? If yes, then I disagree. Current protocols clearly include security. If my inference is incorrect, then I suggest the wording of the contents outline be modified to avoid that impression. I have the same comment about the other "general problems". Thanks, John Kenney On Sun, Apr 8, 2018 at 6:18 PM, Mr. Jaehoon Paul Jeong < jaehoon.paul@gmail.com> wrote: > Hi IPWAVEers, > Here is the revised contents structure for our problem statement document= , > based on the comments from AB, Sandra, Rex, and Dirk: > > ------------------------------------------------------------ > ----------------------------------- > Title: IP Wireless Access in Vehicular Environments (IPWAVE): Use Cases > and Problem Statement > > Abstract > 1. Introduction > 2. Terminology > (Note: each item has at most 4 lines.) > 3. Use Cases > 3.1 V2V > 3.2 V2I > 3.3 V2X > 4. Analysis for Current Protocols > 4.1 Current Protocols for Vehicular Networking > 4.2 General Problems > . Latency > . No Security > . No Pseudonym Handling > . No IP Support > 5. Problem Exploration > 5.1 IPv6 over IEEE 802.11-OCB > 5.2 Neighbor Discovery > . Link Model > . MAC Address Pseudonym > . Prefix Dissemination/Exchange > . Routing > 5.3 Mobility Management > . E2E Connectivity over V2I > 5.4 Vehicle Identity Management > 5.5 Multihop V2X > 5.6 Multicast > 5.7 DNS Naming Services and Service Discovery > 5.8 IPv6 over Cellular Networks > . Cellular V2X (C-V2X) Using 4G-LTE > . Cellular V2X (C-V2X) Using 5G > 5.9 Security and Privacy > 6. Security Considerations > ------------------------------------------------------------ > ----------------------------------- > > If you don't have further comments, I will work for the revision of our > document > with the above contents along with the co-authors. > > Thanks. > > Best Regards, > Paul > > On Mon, Apr 2, 2018 at 11:26 PM, Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > >> Hi AB, Sandra, Rex, and Dirk, >> Thanks for your comments. >> >> With your comments, I will revise the contents of the problem statement >> document >> this week and let you know the revised one this week. >> >> Thanks. >> >> Best Regards, >> Paul >> >> On Tue, Mar 27, 2018 at 1:08 AM, wrote: >> >>> Dear all, >>> regarding the mentioned 'other aspects/problems of interest/future >>> scope' I think it would be worth to add a section for 5G / C-V2X (also >>> revealed as an important technology) also with respect to interoperabil= ity >>> and access heterogeneity (and since IEEE 802.11whatsoever may be widely >>> seen as part of 5G access variants) and include it in the charter >>> discussion. >>> Thanks! >>> Best Regards >>> Dirk >>> >>> -----Original Message----- >>> From: its [mailto:its-bounces@ietf.org] On Behalf Of Rex Buddenberg >>> Sent: Sonntag, 25. M=C3=A4rz 2018 22:46 >>> To: Sandra C=C3=A9spedes ; its@ietf.org >>> Subject: Re: [ipwave] Restructuring of the Problem Statement Document >>> >>> Agree with Sandra's observation. Recommend specifically include >>> multicast within the charter. >>> >>> >>> On Fri, 2018-03-23 at 21:23 -0300, Sandra C=C3=A9spedes wrote: >>> > >>> > >>> > On 3/23/2018 5:55 PM, Abdussalam Baryun wrote: >>> > > >>> > > >>> > > On Fri, Mar 23, 2018 at 11:50 AM, Mr. Jaehoon Paul Jeong >> > > paul@gmail.com> wrote: >>> > > > Hi IPWAVEers, >>> > > > Here is a proposed restructuring of the Problem Statement >>> > > > Document: >>> > > > https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networkin >>> > > > g-02 >>> > > > >>> > > > Sri and I discussed the current structure of the document. We >>> > > > thought the current document is too big with unnecessary content >>> > > > (i.e., 52 pages). >>> > > > We think we should reduce it to around 10 pages with concise >>> > > > content with >>> > > > >>> > > even if it gets to 20p it can be ok, >>> > > >>> > > > key problems for our IPWAVE WG. >>> > > > We come with the following structure with the revised title. >>> > > > >>> > > > --------------------------------------------------------------- >>> > > > --------------------------------------------- >>> > > > Title: IP Wireless Access in Vehicular Environments (IPWAVE): >>> > > > Problem Statement and Use Cases >>> > > > >>> > > I prefer we start with use cases then problems, so title: >>> > > >>> > > Title: IP Wireless Access in Vehicular Environments (IPWAVE): Use >>> > > Cases and Problem Statements >>> > > >>> > > > >>> > > > Abstract >>> > > > 1. Introduction >>> > > > 2. Terminology >>> > > > //each item: at most 4 lines >>> > > > 3. Use Cases: V2V, V2I, V2X >>> > > > 4. Current Architectures and Protocols >>> > > > - General Problems: Latency, No security, No pseudonym handling, >>> > > > No IP support, ... >>> > > > >>> > > why architecture in this draft, I suggest take this out, it is >>> > > better in another draft, just focus on the aim an objectives of the >>> > > draft, the architecture needs another draft so if we update in >>> > > future we just update architecture or update use cases, >>> > > >>> > > >>> > > > 5. Problem Exploration >>> > > > - IPv6 over IEEE 802.11-OCB >>> > > > - Neighbor Discovery >>> > > > . Link Model >>> > > > .. MAC Address Pseudonym >>> > > > . Prefix Dissemination/Exchange >>> > > > . Routing >>> > > > - Mobility Management >>> > > > . E2E Connectivity over V2I >>> > > > - Vehicle Identity Management >>> > > > - Multihop V2X >>> > > > - Service Discovery >>> > > > - Security and Privacy >>> > > > - Others >>> > > > >>> > > please make them as problem statements sections so 5.1, 5.2, ...... >>> > > also they need to cover our available charter only, >>> > During the meeting in London the suggestion was to consider not only >>> > the current charter but also other aspects/problems of interest/futur= e >>> > scope for this group. >>> > > >>> > > > 6. Security Considerations >>> > > > --------------------------------------------------------------- >>> > > > --------------------------------------------- >>> > > > >>> > > > Please give us your comments on it. >>> > > > >>> > > > With the agreed content, we authors will move forward for the >>> > > > documentation.. >>> > > > >>> > > > >>> > > thanks >>> > > >>> > > AB >>> > > >>> > > >>> > > > Thanks. >>> > > > >>> > > > Best Regards, >>> > > > Paul >>> > > > -- >>> > > > =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. >>> > > > Assistant 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.ph >>> > > > p >>> > > > >>> > > > _______________________________________________ >>> > > > its mailing list >>> > > > its@ietf.org >>> > > > https://www.ietf.org/mailman/listinfo/its >>> > > > >>> > > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > its mailing list >>> > > its@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/its >>> > Libre de virus. www.avast.com >>> > _______________________________________________ >>> > its mailing list >>> > its@ietf.org >>> > https://www.ietf.org/mailman/listinfo/its >>> >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>> _______________________________________________ >>> 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. >> Assistant 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. > Assistant 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 > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --=20 John Kenney Director and Principal Researcher Toyota InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. Mobile: 650-224-6644 --000000000000ce2aa105696a6bbb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jaehoon,

Reading the contents outlin= e, I could infer that IETF considers that a "general problem" wit= h "current protocols for vehicular networking" is that there is &= quot;no security."=C2=A0 Is that a correct inference?=C2=A0=C2=A0

If yes, then I disagree. Current protocols clearly inc= lude security.=C2=A0=C2=A0

If my inference is inco= rrect, then I suggest the wording of the contents outline be modified to av= oid that impression.=C2=A0 I have the same comment about the other "ge= neral problems".

Thanks,=C2=A0
John= Kenney


On Sun, Apr 8, 2018 at 6:18 PM, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> wrote:
Hi IPWAVEers,
Here is the revised contents str= ucture for our problem statement document,=C2=A0
based on the com= ments from AB, Sandra, Rex, and Dirk:

------------= -----------------------------------------------------------------= ------------------
Title: IP Wireless = Access in Vehicular Environments (IPWAVE): Use Cases and Problem Statement<= /div>

Abstract
1. Intr= oduction
2. Terminology
=C2=A0 =C2=A0(Note: each= item has at most 4 lines.)
3. Use Cases
=C2=A03.1 V2V<= /div>
=C2=A03.2 V2I
=C2=A03.3 V2X
4. Analysis for C= urrent Protocols
=C2=A04.1 Current Protocols for Vehicular Networ= king
=C2=A04.2 General Problems
=C2=A0 =C2=A0. Latency<= /div>
=C2=A0 =C2=A0. No Security
=C2=A0 =C2=A0. No Pseudonym = Handling
=C2=A0 =C2=A0. No IP Support=C2=A0
5. Problem = Exploration
=C2=A05.1 IPv6 over IEEE 802.11-OCB
=C2=A05= .2 Neighbor Discovery
=C2=A0 =C2=A0. Link Model<= /div>
=C2=A0 =C2=A0. MAC Address Pseudonym
=C2=A0 =C2=A0. Pre= fix Dissemination/Exchange
=C2=A0 =C2=A0. Routing
=C2=A05.3 Mobility Management
=C2=A0 =C2=A0. E= 2E Connectivity over V2I
=C2=A05.4 Vehicle Identity Manage= ment=C2=A0=C2=A0
=C2=A05.5 Multihop V2X
=C2=A05.6 Multi= cast
=C2=A05.7 DNS Naming Services and Service Discovery
=C2=A05.8 IPv6 over Cellular Networks
=C2=A0 =C2=A0. Cellular V= 2X (C-V2X) Using 4G-LTE
=C2=A0 =C2=A0. Cellular V2X (C-V2X) Using= 5G=C2=A0
=C2=A05.9 Security and Privacy
=C2=A06. Secur= ity Considerations
--------------------------------------------= ---------------------------------------------------=C2=A0<= /div>
=C2=A0 =C2=A0
If you don't have further comments, I will work = for the revision of our document=C2=A0
with the above contents al= ong with the co-authors.

Thanks.

Best Regards,
Paul
=
On Mon, Apr 2, 2018 at 11:2= 6 PM, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> w= rote:
Hi AB, Sandra, Rex, and Dirk,
Thanks for your comments.

With your comments, I will revise t= he contents of the problem statement document=C2=A0
this week and= let you know the revised one this week.

Thanks.

Best Regards,
Paul

On Tue, Mar 27, 2018 at 1:08 AM, <= span dir=3D"ltr"><Dirk.von-Hugo@telekom.de> wrote:
Dear all,
regarding the mentioned 'other aspects/problems of interest/future scop= e' I think it would be worth to add a section for 5G / C-V2X (also reve= aled as an important technology) also with respect to interoperability and = access heterogeneity (and since IEEE 802.11whatsoever may be widely seen as= part of 5G access variants) and include it in the charter discussion.
Thanks!
Best Regards
Dirk

-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On Behalf Of Rex Buddenberg
Sent: Sonntag, 25. M=C3=A4rz 2018 22:46
To: Sandra C=C3=A9spedes <scespedes@ing.uchile.cl>; its@ietf.org
Subject: Re: [ipwave] Restructuring of the Problem Statement Document

Agree with Sandra's observation.=C2=A0 Recommend specifically include m= ulticast within the charter.


On Fri, 2018-03-23 at 21:23 -0300, Sandra C=C3=A9spedes wrote:
>
> =C2=A0
> On 3/23/2018 5:55 PM, Abdussalam Baryun wrote:
> >
> >
> > On Fri, Mar 23, 2018 at 11:50 AM, Mr. Jaehoon Paul Jeong <jaeh= oon..
> > paul@gmail.co= m> wrote:
> > > Hi IPWAVEers,
> > > Here is a proposed restructuring of the Problem Statement > > > Document:
> > > https://tools.ietf.o= rg/html/draft-ietf-ipwave-vehicular-networkin
> > > g-02
> > >
> > > Sri and I discussed the current structure of the document. W= e
> > > thought the current document is too big with unnecessary con= tent
> > > (i.e., 52 pages).
> > > We think we should reduce it to around 10 pages with concise=
> > > content with
> > >
> > even if it gets to 20p it can be ok,
> > =C2=A0
> > > key problems for our IPWAVE WG.
> > > We come with the following structure with the revised title.=
> > >
> > > -------------------------------------------------------= --------
> > > ---------------------------------------------
> > > Title: IP Wireless Access in Vehicular Environments (IPWAVE)= :
> > > Problem Statement and Use Cases
> > >
> > I prefer we start with use cases then problems, so title:
> >
> > =C2=A0Title: IP Wireless Access in Vehicular Environments (IPWAVE= ): Use
> > Cases and Problem Statements
> > =C2=A0
> > >
> > > Abstract
> > > 1. Introduction
> > > 2. Terminology
> > > =C2=A0 =C2=A0//each item: at most 4 lines
> > > 3. Use Cases: V2V, V2I, V2X
> > > 4. Current Architectures and Protocols
> > > =C2=A0- General Problems: Latency, No security, No pseudonym= handling,
> > > No IP support, ...
> > >
> > why architecture in this draft, I suggest take this out, it is > > better in another draft, just focus on the aim an objectives of t= he
> > draft, the architecture needs another draft so if we update in > > future we just update architecture or update use cases,
> >
> > =C2=A0
> > > 5. Problem Exploration
> > > =C2=A0- IPv6 over IEEE 802.11-OCB
> > > =C2=A0- Neighbor Discovery
> > > =C2=A0 =C2=A0. Link Model
> > > =C2=A0 =C2=A0.. MAC Address Pseudonym
> > > =C2=A0 =C2=A0. Prefix Dissemination/Exchange
> > > =C2=A0 =C2=A0. Routing
> > > =C2=A0- Mobility Management
> > > =C2=A0 =C2=A0. E2E Connectivity over V2I
> > > =C2=A0- Vehicle Identity Management
> > > =C2=A0- Multihop V2X
> > > =C2=A0- Service Discovery
> > > =C2=A0- Security and Privacy
> > > =C2=A0- Others
> > >
> > please make them as problem statements sections so 5.1, 5.2, ....= ..
> > also they need to cover our available charter only,
> =C2=A0During the meeting in London the suggestion was to consider not = only
> the current charter but also other aspects/problems of interest/future=
> scope for this group.
> > =C2=A0
> > > =C2=A06. Security Considerations
> > > -------------------------------------------------------= --------
> > > ---------------------------------------------
> > >
> > > Please give us your comments on it.
> > >
> > > With the agreed content, we authors will move forward for th= e
> > > documentation..
> > >
> > >
> > thanks
> >
> > AB
> >
> > =C2=A0
> > > Thanks.
> > >
> > > Best Regards,
> > > Paul
> > > --
> > > =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.
> > > Assistant 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.ph
> > > p
> > >
> > > _______________________________________________
> > > its mailing list
> > > its@ietf.o= rg
> > > https://www.ietf.org/mailman/listinfo/i= ts
> > >
> > >
> >
> >
> > _______________________________________________
> > its mailing list
> > its@ietf.org
> > https://www.ietf.org/mailman/listinfo/its
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Libre de virus. www.avast.com
> =C2=A0_______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
_______________________________________________
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) Jeon= g, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan U= niversity
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iot= lab.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.
Assistant 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-je= ong.php

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




--
=
John Kenney
Director and Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644
--000000000000ce2aa105696a6bbb-- From nobody Mon Apr 9 06:46:11 2018 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 7879C1270AB for ; Mon, 9 Apr 2018 06:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 i0teeHy30Okp for ; Mon, 9 Apr 2018 06:46:08 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 ED296128959 for ; Mon, 9 Apr 2018 06:46:01 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id v26so271611pge.11 for ; Mon, 09 Apr 2018 06:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vmBb7Uxqyu9FoeeviVQTI7XxTD1sIzXjzLkcHcfSrvo=; b=jXUY7qYj3uu+U8MYOPSoVtSy+8tRBogwIs6RyS2rQQN/vC2+p8X0TriQRkum0GAjqh dS4bTnV7SdnHfTqV+8W5XGoRNba/flWjeFf+gXFBpPOSfTWDdK3TYkgmLB/lRCfQoBQr 67BRR93bCrCwq2aqtInJLLS5z2MtwdnDlPoqiREHAquHufWrZ16rqKOuEF+xEejtnR8/ tBgWntvAo0skw9YS/hMbYtNvZAzQwAWhnm0j/dbrc1TXIW3DXrnv9ZhhVQvoOwuDp8wU q2UA5xkXsg0yGHNcS8XxZ1Ef47PenrUAApbkPJfcaR1Xcyk3XDBawY4j6Ul8NvEFOR/I ZpNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=vmBb7Uxqyu9FoeeviVQTI7XxTD1sIzXjzLkcHcfSrvo=; b=GR2Z1sb2vvVFoVDDDZRsusntOB531a6HjJRrIdwSk716aC1F7kcssOx/CPSjSSiMgm oLjlCDgm8Nw4cTnUAYYfTGO+/QsgYIzLizOCfE5+Cl06CmOMpbhTwjIvlSCKPMngQ4Db yEMVhilWXu7CJl1Q8WEkx11Y/ks0WHBr2Q0Jw67OAdLgh8QZGKqJLdLZsFR8rSoln/7t 3gE6k/P7eOcgB7XD6P9WYKMcgOLaqcjTudDlS4vO1NV/lNpWlUGRP7ZpBt7YGwEJSXbi syLlr1xAE5pOXELsIUmtHKblF1BmZvTqMn4Tf8DxfBK710YeX1EM9tKHR37RQUq7xYMx iF2w== X-Gm-Message-State: AElRT7EwczLOvoifQLAz3Wv7B5/TEKppFRXUIcaNT7DLXLJ45s1Zodyw fqdQigofAyEvQ9ze6TaX+kM= X-Google-Smtp-Source: AIpwx48xtpRpj8MWeTR+iNAi7XQFec8S5LVjusAiNZdTjOKDDE2YCah00aCdcgEW7rPLkquUz7ME4w== X-Received: by 10.98.160.92 with SMTP id r89mr29097835pfe.235.1523281561558; Mon, 09 Apr 2018 06:46:01 -0700 (PDT) Received: from [192.168.1.3] (c-24-130-209-5.hsd1.ca.comcast.net. [24.130.209.5]) by smtp.gmail.com with ESMTPSA id a3sm846728pgv.14.2018.04.09.06.45.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Apr 2018 06:46:00 -0700 (PDT) Sender: Tony Li Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: tony.li@tony.li In-Reply-To: Date: Mon, 9 Apr 2018 06:45:58 -0700 Cc: "Mr. Jaehoon Paul Jeong" , Rex Buddenberg , skku_iotlab_seminar@googlegroups.com, its , Sandra Cespedes , Dirk.von-Hugo@telekom.de, Abdussalam Baryun Content-Transfer-Encoding: quoted-printable Message-Id: <8C1BD1DF-A761-4A26-821E-46B524E27B20@tony.li> References: <1522010744.2694.42.camel@gmail.com> <05afff15f1c94cedabaa20212e3385b1@HE105715.emea1.cds.t-internal.com> To: John Kenney X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [ipwave] Restructuring of the Problem Statement Document X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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, 09 Apr 2018 13:46:09 -0000 >=20 > Reading the contents outline, I could infer that IETF considers that a = "general problem" with "current protocols for vehicular networking" is = that there is "no security." Is that a correct inference? =20 >=20 > If yes, then I disagree. Current protocols clearly include security. =20= >=20 > If my inference is incorrect, then I suggest the wording of the = contents outline be modified to avoid that impression. I have the same = comment about the other "general problems=E2=80=9D. I think it would be more fair to say that what we=E2=80=99ve seen of = security proposals break all things IP. But it=E2=80=99s probably not worth worrying about the wording of the = outline. I suggest we wait to see the text. T From nobody Mon Apr 9 07:51:22 2018 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 19BCC126C25 for ; Mon, 9 Apr 2018 07:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 YnAva7qNahsO for ; Mon, 9 Apr 2018 07:51:19 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 057D51242F5 for ; Mon, 9 Apr 2018 07:51:19 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id j3so343563pgf.2 for ; Mon, 09 Apr 2018 07:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Qtq/m2FvOANtepGoRmGTCEyr9xlLqCSwwYjQoBsPKVo=; b=aouBm+4kcmr5zVz+jVIbB5dFFl5TeIsAFrfWdMNabwZUiyaLjdjRyyVCMKM5vuUhPW vJ2RqdI7EiojUixbdDBDZaqgEGj0X+yyA26LiOkK4GLFbWVH5iQvdt9V0ajsETG0orz4 JzdqS+MdSlHw/Otw3SSUUyqy6Ix6qUu0BUJa8b8//7JEuh1zpUgqXhuVJ5r+RyWHyH8P 7ok3wYiE9oZBV/B8HeVjeQ/IETRySD0qcsmMZKcTg8IbdE3Cs6CDLtBdtW4qyquSSl1A B4WR0SiXYH2ZfCuPuZgmOs1XE2VaCEi8QWJZms4E0Zm1Hg+5pUrp5Bdc3rnkwtUiMaOA e/NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=Qtq/m2FvOANtepGoRmGTCEyr9xlLqCSwwYjQoBsPKVo=; b=CwQBdvdeOV1SuN0/6H+CLbll+3YbCSDK8SIsxMSClNYrHcMsqw3sGm7jhQAZDLSNev Sh3e8NoTHSHgDrhL4V1Nmdi79MAndnFOVWjgtgc4x43axPC/vHrnHGETrmqN51QZz42Q LwXglPQ+NKzAQcNznsaL4L/pCAqfZ/W0vy4s80OTkWzCv/RCaN8ok27uxdgCUKalbBBA 3P2v0pRH/NcrnUdhJqmQFo5t6qu/3lv/YsXJDXkk3CvVpMV1PCn6DPwOcbX2RTz+vjI8 uYMBOv8D34rGYwCSh5w6u/wqC16rlUpYfHkHewxPdA6AaTYeGuMFJD2gw5UECA6Cd0E+ 53mA== X-Gm-Message-State: ALQs6tC0CgNLcsmiu3vybWqr03HS19bsITe8sVkR/R7QzOQb7Jk6WrDt ZsbJSwbj8bo5vhsxfJxbMrw= X-Google-Smtp-Source: AIpwx4/US12qWrxFXJbzlGNxduFen6z0xRUlO73huT8+hkcfiQRKdJBEsJgCOcG79eZBKOdpQk9THw== X-Received: by 10.99.101.66 with SMTP id z63mr15470398pgb.383.1523285478405; Mon, 09 Apr 2018 07:51:18 -0700 (PDT) Received: from [10.95.85.179] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id k5sm1054287pgs.79.2018.04.09.07.51.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Apr 2018 07:51:17 -0700 (PDT) Sender: Tony Li Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: tony.li@tony.li In-Reply-To: Date: Mon, 9 Apr 2018 07:51:15 -0700 Cc: John Kenney , Rex Buddenberg , skku_iotlab_seminar@googlegroups.com, its , Sandra Cespedes , Dirk.von-Hugo@telekom.de, "Mr. Jaehoon Paul Jeong" , Abdussalam Baryun Content-Transfer-Encoding: quoted-printable Message-Id: References: <1522010744.2694.42.camel@gmail.com> <05afff15f1c94cedabaa20212e3385b1@HE105715.emea1.cds.t-internal.com> <8C1BD1DF-A761-4A26-821E-46B524E27B20@tony.li> To: dickroy@alum.mit.edu X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [ipwave] Restructuring of the Problem Statement Document X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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, 09 Apr 2018 14:51:21 -0000 Again, I look forward to seeing the text. The mechanisms that I=E2=80=99ve seen implement privacy by rotating the = MAC address. AFAICT, that=E2=80=99s pretty much fatal to everything = above it. And I=E2=80=99ll be the first to stipulate that there is no security in = IP anyway. Partly because we can=E2=80=99t get people to deploy it. = ;-) Tony > On Apr 9, 2018, at 7:14 AM, Dick Roy wrote: >=20 > FYI, NOTHING about the current ITS security standards or their > implementation "breaks anything IP"! I have no idea where that = thought came > from, however it is simply wrong. 1609.2 is essentially "application = level" > security. While nothing prevents lower layers from using those = security > services, there is NO implementation to date that does so, nor is = there a > good reason to do so. =20 >=20 > Perhaps the issue is with IPsec? That after all is network layer = security:^) >=20 > RR >=20 > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of tony.li@tony.li > Sent: Monday, April 9, 2018 6:46 AM > To: John Kenney > Cc: Rex Buddenberg; skku_iotlab_seminar@googlegroups.com; its; Sandra > Cespedes; Dirk.von-Hugo@telekom.de; Mr. Jaehoon Paul Jeong; Abdussalam > Baryun > Subject: Re: [ipwave] Restructuring of the Problem Statement Document >=20 >>=20 >> Reading the contents outline, I could infer that IETF considers that = a > "general problem" with "current protocols for vehicular networking" is = that > there is "no security." Is that a correct inference? =20 >>=20 >> If yes, then I disagree. Current protocols clearly include security. =20= >>=20 >> If my inference is incorrect, then I suggest the wording of the = contents > outline be modified to avoid that impression. I have the same comment = about > the other "general problems". >=20 >=20 > I think it would be more fair to say that what we've seen of security > proposals break all things IP. >=20 > But it's probably not worth worrying about the wording of the outline. = I > suggest we wait to see the text. >=20 > T >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its >=20 From nobody Mon Apr 9 08:41:56 2018 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 F298312025C for ; Mon, 9 Apr 2018 08:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 znfplMscUniL for ; Mon, 9 Apr 2018 08:41:53 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 8005A12AAB6 for ; Mon, 9 Apr 2018 08:41:53 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id r14so398746pgq.4 for ; Mon, 09 Apr 2018 08:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=PH2uZTnoIIe+Yz6wE7PnVMKRrE8swmye+y6+HJ+cqBk=; b=JmcySCPaSA5d2AYWfRIDNeLGAz49bFcFWYhHFWrfgzz2BQrx8EParat+MikBPrRh6M P1ovsQfpraQ2CMNa2DZOLeIQ++b4XDdxiIvZaNT5thweAOvEqbiZU76Del+vZ5d+ySZi axrX3cGeyUMqCB/LuMFNG4j3+xvTr/iTKP2ICcbJPR2+G49NcZ+EgUmRj2qydOYYV45L OEMXLlnG5AmwSaeeGejQr7VcGd/ioB7vn5pb/08TS45WwB+NyhKfwPJ4SDRm2A+zWwuV GMps2B4+Lb5WzrvkfSDBR39x6gKzkTmj6LvonVDGT8TraiTIcj/WnsLlPQCaq6JE82QQ 1YVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=PH2uZTnoIIe+Yz6wE7PnVMKRrE8swmye+y6+HJ+cqBk=; b=dD59x9xustJ8vneoE8NXVQTQ0cm7rsPZE/cjCKZsFaIaauVbXuR1qG3r6eDP35lEk6 umXD33QyyXDhDS2A83iEaLlOMOoJJ47Jk/QCyzc1OnhaHuUJgpo8SbvLYoU6u1TrWLXU mkEQXolPRkabjyC/q/EJqojOSvnpzS3CQweOvbntUEg98ke8sxNkoCXDqGlS8XLGd+Zu Z8lgRmYfg3xDgdzBAoyLIZbLXoz1OzQF2oEMjCkLlqAy2/fx2pJ3L4iGP6UkKJ0n8l3F FTqJrxQBcydUL85GZ7EAKSCYB1OUQh6Z1Ej8GtJ3X0OBy4riPvLFgkwqvkfv8Bj65VDi g5PA== X-Gm-Message-State: AElRT7E6MzJCfLZj0zpu20HVUnNZ8Zy6mDyxOJbv4AfPAZVpODB8/iba flLtt052hTVSSCMOdUftf34= X-Google-Smtp-Source: AIpwx49NlOU3QQkY4priQ+/57v27XKMwk1ZBX49Eom9pGYQxNBnSRiqSUEOnnWrgB/elcWm6hgj7sQ== X-Received: by 10.101.99.149 with SMTP id h21mr25821646pgv.345.1523288513027; Mon, 09 Apr 2018 08:41:53 -0700 (PDT) Received: from [10.95.85.179] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id k73sm1342393pgc.55.2018.04.09.08.41.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Apr 2018 08:41:52 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: <0F39CE7C-A461-4D2A-869A-750602F0F1FA@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_BCBD952A-D1A6-4CF1-A17B-90D43764AD26" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 9 Apr 2018 08:41:13 -0700 In-Reply-To: <336267158D7445CE877EE320F54320B6@SRA6> Cc: Rex Buddenberg , skku_iotlab_seminar@googlegroups.com, its , Sandra Cespedes , John Kenney , Dirk.von-Hugo@telekom.de, "Mr. Jaehoon Paul Jeong" , Abdussalam Baryun To: dickroy@alum.mit.edu References: <1522010744.2694.42.camel@gmail.com> <05afff15f1c94cedabaa20212e3385b1@HE105715.emea1.cds.t-internal.com> <8C1BD1DF-A761-4A26-821E-46B524E27B20@tony.li> <336267158D7445CE877EE320F54320B6@SRA6> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [ipwave] Restructuring of the Problem Statement Document X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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, 09 Apr 2018 15:41:55 -0000 --Apple-Mail=_BCBD952A-D1A6-4CF1-A17B-90D43764AD26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > When sessions of any kind are established, tumbling of MAC addresses = is > either suspended, or the session terminates abruptly. It's up to = station > management to decide which of the outcomes is optimal, then execute on = that > plan. Generally, tumbling will be suspended until the session = terminates > normally, but that doesn't have to be the case! What happens in the case of long-lived sessions? Streaming comes to mind as a common case in point. If tumbling is suspended, then privacy protection is effectively = disabled. That seems problematic. It tumbling isn=E2=80=99t suspended, = then the phone rings with irate users saying the network doesn=E2=80=99t = work. Tony --Apple-Mail=_BCBD952A-D1A6-4CF1-A17B-90D43764AD26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

When sessions = of any kind are established, tumbling of MAC addresses is
either suspended, or the session = terminates abruptly.  It's up to station
management to decide which of = the outcomes is optimal, then execute on that
plan.  Generally, tumbling = will be suspended until the session terminates
normally, but that doesn't have = to be the case!


What happens in the case = of long-lived sessions?

Streaming comes to mind as a common case in point.

If tumbling is = suspended, then privacy protection is effectively disabled. That seems = problematic.  It tumbling isn=E2=80=99t suspended, then the phone = rings with irate users saying the network doesn=E2=80=99t = work.

Tony

= --Apple-Mail=_BCBD952A-D1A6-4CF1-A17B-90D43764AD26-- From nobody Mon Apr 9 09:36:25 2018 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 E966B1270A0 for ; Mon, 9 Apr 2018 09:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[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_PASS=-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 Pyb4nIJSsrYI for ; Mon, 9 Apr 2018 09:36:22 -0700 (PDT) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (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 78FD9124217 for ; Mon, 9 Apr 2018 09:36:22 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id 23-v6so9327935otj.0 for ; Mon, 09 Apr 2018 09:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7fyiW1VP5RdwLv3et9kfwW9z7tAzT1AMV0OJwQ8PIYU=; b=ibGHv7xyPNIbLKE1nAesWPKe4vHI2JW7qcMkx50/cTeMgrT412LnmMBUqBZo9E0niy RoeFFeAnsesCz+egSV+YuM6VqeWij+XVUKvTlE9JmMhoUgQk3Sjx+iEqR+pxCe7JEow+ OgvFkauJSUCNYMPqWVkNO7hxSEWjdbdisi11ccb3GlIOY9qEIicaalfq9ad9OB73Z9JW MliApjR6VDXNE+3bNJT/SlW8siFP1kAlMzOzSLhLF5O1e7oVx6+eBrH0aKmZ7TJRek0B GoYfhTU+4fE1Yrtnm+HlOq8+mpaIIamv6Q3BKRfXvbV4Gxptav119sXGTYM5rDFhe3L4 3oyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7fyiW1VP5RdwLv3et9kfwW9z7tAzT1AMV0OJwQ8PIYU=; b=eIueLZpkmrjuUnrsSSgY4rzgCqwJNnNMzHtlwlKTeuaxCundTGGChEE5CYKlXpUgsm oSg1XD7d5LiIjS/9FpRjapiR7/Ow21XKRp8AK0yK1qCZJAUj6tvgi65kIpqVCwY8qCFc XRKruN486TfqMKK8D7qL/ZJk+oPtn1K99ycoR98/owbmYMq6+WTF0rWtXiCcZ7O2sKDo rETVhJkIvGcemLyNeSMc2dDZXr/72BAEWeQvNfnwCknrJzNQxyqRusv1tKX8K4L4ekP5 Esi+oaj3gYGVfPifVUOZu5Ipe9FJjz+l8/yTX3gXuKdjcd5EQnefJpFTLDaH8VE3uL6n C1cw== X-Gm-Message-State: ALQs6tBnsv+rs2CX0cyPWjRdux1pfZAIdvTCqKOuImar4ybIJVi8gKBD V+6mmV/y/hLWGziwGDpiPr53IWF75lAQAocy5PM= X-Google-Smtp-Source: AIpwx4/k5HeeucSHQd/WD1T5Giptb8W0sxbgekbUhYyIJoj5EinMrHKpq8VSelkgdTZllV0ocdWLIoWHOhgqph91eSU= X-Received: by 2002:a9d:400d:: with SMTP id m13-v6mr4480366ote.391.1523291781910; Mon, 09 Apr 2018 09:36:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:3166:0:0:0:0:0 with HTTP; Mon, 9 Apr 2018 09:36:21 -0700 (PDT) In-Reply-To: References: <1522010744.2694.42.camel@gmail.com> <05afff15f1c94cedabaa20212e3385b1@HE105715.emea1.cds.t-internal.com> From: Abdussalam Baryun Date: Mon, 9 Apr 2018 18:36:21 +0200 Message-ID: To: John Kenney Cc: "Mr. Jaehoon Paul Jeong" , its , Sandra Cespedes , Rex Buddenberg , Dirk.von-Hugo@telekom.de, skku_iotlab_seminar@googlegroups.com Content-Type: multipart/alternative; boundary="0000000000008cd4bb05696d0160" Archived-At: Subject: Re: [ipwave] Restructuring of the Problem Statement Document X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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, 09 Apr 2018 16:36:24 -0000 --0000000000008cd4bb05696d0160 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 9, 2018 at 3:31 PM, John Kenney wrote: > Hi Jaehoon, > > Reading the contents outline, I could infer that IETF considers that a > "general problem" with "current protocols for vehicular networking" is that > there is "no security." Is that a correct inference? > IMO we should agree on this, because IETF considers what we in this WG will decide. > > > If yes, then I disagree. Current protocols clearly include security. > I support that, thanks > > If my inference is incorrect, then I suggest the wording of the contents > outline be modified to avoid that impression. I have the same comment > about the other "general problems". > I agree, so we are able to edit the draft. Please send your ideas and edits to the draft so we discuss them, AB --0000000000008cd4bb05696d0160 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 9, 2018 at 3:31 PM, John Kenney <jkenney@us.toyota= -itc.com> wrote:
Hi Ja= ehoon,

Reading the contents outline, I could infer that = IETF considers that a "general problem" with "current protoc= ols for vehicular networking" is that there is "no security."= ;=C2=A0 Is that a correct inference?=C2=A0
IMO we should=C2=A0agree on=C2=A0this, because IETF considers w= hat we in this WG will decide.
=C2=A0
=C2=A0

If yes, then I disagree. C= urrent protocols clearly include security.=C2=A0=C2=A0

I support=C2=A0that, thanks
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-= left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-le= ft-style:solid">

If my inference is inc= orrect, then I suggest the wording of the contents outline be modified to a= void that impression.=C2=A0 I have the same comment about the other "g= eneral problems".

I agree,= so we are able to edit the draft. Please send your ideas and edits to the = draft so we discuss them,


AB
<= span>


--0000000000008cd4bb05696d0160-- From nobody Mon Apr 9 09:39:58 2018 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 133E212D777 for ; Mon, 9 Apr 2018 09:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 HVWEaufoVwkw for ; Mon, 9 Apr 2018 09:39:52 -0700 (PDT) Received: from mailout34.telekom.de (MAILOUT34.telekom.de [194.25.225.146]) (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 096621270A0 for ; Mon, 9 Apr 2018 09:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1523291992; x=1554827992; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=juQQ/MAtQXoJT1dmr7+bVn3SpM8QjaWxI6egdGE8w4A=; b=FTsytiXTPx/Cqlk76ZmR5WXh+EzkWcdc9xbJxk587rnDzS2kLN1wz/O6 djfRk2JPdy4z+1mu15I08TFrkKWbjRE5cykyKUFqhJ9JXt0lultzEiDwO TiMka1HU+bZgkwR/Pffz0drzz9G6ZxF9908hFxagzwL8fBNOvoF48G6Rw k4YPL5WqgsYTkSwuAt3tiwObqb7mzlabTuVtd1+x2T9qTjG6H1KRZP7LJ syS9x4T+UafDsXGKVTLVfxI4Cu+ZrPTVJWCoiZHgM6j6asyo42H/rLHF0 KuBig77tCfX/M2671EuVrt3wz1H7eZfZybd8vn/7JSvzytUd4NIAUzM7y Q==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Apr 2018 18:39:49 +0200 X-IronPort-AV: E=Sophos;i="5.48,405,1517871600"; d="scan'208,217";a="215610349" Received: from he105717.emea1.cds.t-internal.com ([10.169.118.53]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 09 Apr 2018 18:39:49 +0200 Received: from HE105715.EMEA1.cds.t-internal.com (10.169.118.51) by HE105717.emea1.cds.t-internal.com (10.169.118.53) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 9 Apr 2018 18:39:48 +0200 Received: from HE105715.EMEA1.cds.t-internal.com ([fe80::e4a0:cc4:20d4:3019]) by HE105715.emea1.cds.t-internal.com ([fe80::e4a0:cc4:20d4:3019%26]) with mapi id 15.00.1365.000; Mon, 9 Apr 2018 18:39:48 +0200 From: To: , , , , , CC: Thread-Topic: [ipwave] Restructuring of the Problem Statement Document Thread-Index: AQHTwoyIVK+C+CQKxEyFxBkkkaRsRKPePKmAgAA6CwCAAtcpAIAA9dfAgAsy1gCACiRMgIAA3yWAgABCodA= Date: Mon, 9 Apr 2018 16:39:48 +0000 Message-ID: <7c14e776964c48f98b22528c4325597b@HE105715.emea1.cds.t-internal.com> References: <1522010744.2694.42.camel@gmail.com> <05afff15f1c94cedabaa20212e3385b1@HE105715.emea1.cds.t-internal.com> <4F3B9E1AA90A4BDCAD50600843783AFB@SRA6> In-Reply-To: <4F3B9E1AA90A4BDCAD50600843783AFB@SRA6> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.30.104] Content-Type: multipart/alternative; boundary="_000_7c14e776964c48f98b22528c4325597bHE105715emea1cdstintern_" MIME-Version: 1.0 Archived-At: Subject: Re: [ipwave] Restructuring of the Problem Statement Document X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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, 09 Apr 2018 16:39:56 -0000 --_000_7c14e776964c48f98b22528c4325597bHE105715emea1cdstintern_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, perhaps we should say: 'no optimum/efficient support' since for IP on appli= cation layer there is a lot of tunneling and encapsulation in between ... Thanks! Best Regards Dirk From: Dick Roy [mailto:dickroy@alum.mit.edu] Sent: Montag, 9. April 2018 16:38 To: 'Mr. Jaehoon Paul Jeong' ; its@ietf.org; 'Abdus= salam Baryun' ; 'Sandra Cespedes' ; 'Rex Buddenberg' ; von Hugo, Dirk Cc: skku_iotlab_seminar@googlegroups.com Subject: RE: [ipwave] Restructuring of the Problem Statement Document Also, where did the idea that there is currently no support for IP come fro= m? The current ITS standards and implementations all support IP(v^). RR ________________________________ From: its [mailto:its-bounces@ietf.org] On Behalf Of Mr. Jaehoon Paul Jeong Sent: Sunday, April 8, 2018 6:19 PM To: its@ietf.org; Abdussalam Baryun; Sandra Cespedes; = Rex Buddenberg; Dirk.von-Hugo@telekom.de Cc: skku_iotlab_seminar@googlegroups.com; Mr. Jaehoon Paul Jeong Subject: Re: [ipwave] Restructuring of the Problem Statement Document Hi IPWAVEers, Here is the revised contents structure for our problem statement document, based on the comments from AB, Sandra, Rex, and Dirk: ---------------------------------------------------------------------------= -------------------- Title: IP Wireless Access in Vehicular Environments (IPWAVE): Use Cases and= Problem Statement Abstract 1. Introduction 2. Terminology (Note: each item has at most 4 lines.) 3. Use Cases 3.1 V2V 3.2 V2I 3.3 V2X 4. Analysis for Current Protocols 4.1 Current Protocols for Vehicular Networking 4.2 General Problems . Latency . No Security . No Pseudonym Handling . No IP Support 5. Problem Exploration 5.1 IPv6 over IEEE 802.11-OCB 5.2 Neighbor Discovery . Link Model . MAC Address Pseudonym . Prefix Dissemination/Exchange . Routing 5.3 Mobility Management . E2E Connectivity over V2I 5.4 Vehicle Identity Management 5.5 Multihop V2X 5.6 Multicast 5.7 DNS Naming Services and Service Discovery 5.8 IPv6 over Cellular Networks . Cellular V2X (C-V2X) Using 4G-LTE . Cellular V2X (C-V2X) Using 5G 5.9 Security and Privacy 6. Security Considerations ---------------------------------------------------------------------------= -------------------- If you don't have further comments, I will work for the revision of our doc= ument with the above contents along with the co-authors. Thanks. Best Regards, Paul On Mon, Apr 2, 2018 at 11:26 PM, Mr. Jaehoon Paul Jeong > wrote: Hi AB, Sandra, Rex, and Dirk, Thanks for your comments. With your comments, I will revise the contents of the problem statement doc= ument this week and let you know the revised one this week. Thanks. Best Regards, Paul On Tue, Mar 27, 2018 at 1:08 AM, > wrote: Dear all, regarding the mentioned 'other aspects/problems of interest/future scope' I= think it would be worth to add a section for 5G / C-V2X (also revealed as = an important technology) also with respect to interoperability and access h= eterogeneity (and since IEEE 802.11whatsoever may be widely seen as part of= 5G access variants) and include it in the charter discussion. Thanks! Best Regards Dirk -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Beh= alf Of Rex Buddenberg Sent: Sonntag, 25. M=E4rz 2018 22:46 To: Sandra C=E9spedes >; its@ietf.org Subject: Re: [ipwave] Restructuring of the Problem Statement Document Agree with Sandra's observation. Recommend specifically include multicast = within the charter. On Fri, 2018-03-23 at 21:23 -0300, Sandra C=E9spedes wrote: > > > On 3/23/2018 5:55 PM, Abdussalam Baryun wrote: > > > > > > On Fri, Mar 23, 2018 at 11:50 AM, Mr. Jaehoon Paul Jeong > paul@gmail.com> wrote: > > > Hi IPWAVEers, > > > Here is a proposed restructuring of the Problem Statement > > > Document: > > > https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networkin > > > g-02 > > > > > > Sri and I discussed the current structure of the document. We > > > thought the current document is too big with unnecessary content > > > (i.e., 52 pages). > > > We think we should reduce it to around 10 pages with concise > > > content with > > > > > even if it gets to 20p it can be ok, > > > > > key problems for our IPWAVE WG. > > > We come with the following structure with the revised title. > > > > > > --------------------------------------------------------------- > > > --------------------------------------------- > > > Title: IP Wireless Access in Vehicular Environments (IPWAVE): > > > Problem Statement and Use Cases > > > > > I prefer we start with use cases then problems, so title: > > > > Title: IP Wireless Access in Vehicular Environments (IPWAVE): Use > > Cases and Problem Statements > > > > > > > > Abstract > > > 1. Introduction > > > 2. Terminology > > > //each item: at most 4 lines > > > 3. Use Cases: V2V, V2I, V2X > > > 4. Current Architectures and Protocols > > > - General Problems: Latency, No security, No pseudonym handling, > > > No IP support, ... > > > > > why architecture in this draft, I suggest take this out, it is > > better in another draft, just focus on the aim an objectives of the > > draft, the architecture needs another draft so if we update in > > future we just update architecture or update use cases, > > > > > > > 5. Problem Exploration > > > - IPv6 over IEEE 802.11-OCB > > > - Neighbor Discovery > > > . Link Model > > > .. MAC Address Pseudonym > > > . Prefix Dissemination/Exchange > > > . Routing > > > - Mobility Management > > > . E2E Connectivity over V2I > > > - Vehicle Identity Management > > > - Multihop V2X > > > - Service Discovery > > > - Security and Privacy > > > - Others > > > > > please make them as problem statements sections so 5.1, 5.2, ...... > > also they need to cover our available charter only, > During the meeting in London the suggestion was to consider not only > the current charter but also other aspects/problems of interest/future > scope for this group. > > > > > 6. Security Considerations > > > --------------------------------------------------------------- > > > --------------------------------------------- > > > > > > Please give us your comments on it. > > > > > > With the agreed content, we authors will move forward for the > > > documentation.. > > > > > > > > thanks > > > > AB > > > > > > > Thanks. > > > > > > Best Regards, > > > Paul > > > -- > > > =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. > > > Assistant Professor > > > Department of Software > > > Sungkyunkwan University > > > Office: +82-31-299-4957 > > > Email: jaehoon.paul@gmail.com, pauljeo= ng@skku.edu Personal > > > Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.ph > > > p > > > > > > _______________________________________________ > > > its mailing list > > > its@ietf.org > > > https://www.ietf.org/mailman/listinfo/its > > > > > > > > > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > Libre de virus. www.avast.com > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its _______________________________________________ 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. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skk= u.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. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skk= u.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --_000_7c14e776964c48f98b22528c4325597bHE105715emea1cdstintern_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

perhaps we should say: ‘no optimum/efficient support’ sinc= e for IP on application layer there is a lot of tunneling and encapsulation in between …

Thanks!

Best Regards
Dirk

 = ;

From: = Dick Roy [mailto:dickroy@alum.mit.edu]
Sent: Montag, 9. April 2018 16:38
To: 'Mr. Jaehoon Paul Jeong' <jaehoon.paul@gmail.com>; its@iet= f.org; 'Abdussalam Baryun' <abdussalambaryun@gmail.com>; 'Sandra Cesp= edes' <scespedes@ing.uchile.cl>; 'Rex Buddenberg' <buddenbergr@gma= il.com>; von Hugo, Dirk <Dirk.von-Hugo@telekom.de>
Cc: skku_iotlab_seminar@googlegroups.com
Subject: RE: [ipwave] Restructuring of the Problem Statement Documen= t

 

Also, where did the idea th= at there is currently no support for IP come from?  The current ITS st= andards and implementations all support IP(v^).

 

RR

 

From: it= s [mailto:its-bounces@ietf.org] On Behalf Of Mr. Jaehoon Paul Jeong
Sent: Sunday, April 8, 2018 6:19 PM
To: its@ietf.org; Abdussalam Bar= yun; Sandra Cespedes; Rex Buddenberg; Dirk.von-Hugo@telekom.de Cc: skku_iot= lab_seminar@googlegroups.com; Mr. Jaehoon Paul Jeong
Subject: Re: [ipwave] Restructuring of the Problem Statement Documen= t

 

Hi IPWAVEers,=

Here is the revised contents st= ructure for our problem statement document, 

based on the comments from AB, = Sandra, Rex, and Dirk:

 

-------------------------------= ----------------------------------------------------------------=

Title: IP Wireless Access in Ve= hicular Environments (IPWAVE): Use Cases and Problem Statement

 

Abstract

1. Introduction

2. Terminology

   (Note: each item h= as at most 4 lines.)

3. Use Cases<= /p>

 3.1 V2V=

 3.2 V2I=

 3.3 V2X=

4. Analysis for Current Protoco= ls

 4.1 Current Protocols for= Vehicular Networking

 4.2 General Problems=

   . Latency

   . No Security=

   . No Pseudonym Han= dling

   . No IP Support&nb= sp;

5. Problem Exploration

 5.1 IPv6 over IEEE 802.11= -OCB

 5.2 Neighbor Discovery

   . Link Model<= /o:p>

   . MAC Address Pseu= donym

   . Prefix Dissemina= tion/Exchange

   . Routing

 5.3 Mobility Management

   . E2E Connectivity= over V2I

 5.4 Vehicle Identity Mana= gement  

 5.5 Multihop V2X

 5.6 Multicast<= /span>

 5.7 DNS Naming Services a= nd Service Discovery

 5.8 IPv6 over Cellular Ne= tworks

   . Cellular V2X (C-= V2X) Using 4G-LTE

   . Cellular V2X (C-= V2X) Using 5G 

 5.9 Security and Privacy<= o:p>

 6. Security Consideration= s

------------------------= ----------------------------------------------------------------------- 

   =

If you don't have further comme= nts, I will work for the revision of our document 

with the above contents along w= ith the co-authors.

 

Thanks.

 

Best Regards,=

Paul

 

On Mon, Apr 2, 2018 at 11:26 PM= , Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> wrote:

Hi AB, Sandra, Rex, and Dirk,

Thanks for your comments.<= /o:p>

 

With your comments, I will revi= se the contents of the problem statement document 

this week and let you know the = revised one this week.

 

Thanks.

 

Best Regards,=

Paul

 

On Tue, Mar 27, 2018 at 1:08 AM= , <Dirk.vo= n-Hugo@telekom.de> wrote:

Dear all,
regarding the mentioned 'other aspects/problems of interest/future scope' I= think it would be worth to add a section for 5G / C-V2X (also revealed as = an important technology) also with respect to interoperability and access h= eterogeneity (and since IEEE 802.11whatsoever may be widely seen as part of 5G access variants) and include it in the ch= arter discussion.
Thanks!
Best Regards
Dirk


-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On Behalf Of Rex Buddenberg
Sent: Sonntag, 25. M=E4rz 2018 22:46
To: Sandra C=E9spedes <scespedes@ing.uchile.cl>; its@ietf.org
Subject: Re: [ipwave] Restructuring of the Problem Statement Document

Agree with Sandra's observation.  Recommend specifically include multi= cast within the charter.


On Fri, 2018-03-23 at 21:23 -0300, Sandra C=E9spedes wrote:
>
>  
> On 3/23/2018 5:55 PM, Abdussalam Baryun wrote:
> >
> >
> > On Fri, Mar 23, 2018 at 11:50 AM, Mr. Jaehoon Paul Jeong <jaeh= oon..
> > paul@gmail.co= m> wrote:
> > > Hi IPWAVEers,
> > > Here is a proposed restructuring of the Problem Statement > > > Document:
> > > https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networkin
> > > g-02
> > >
> > > Sri and I discussed the current structure of the document. W= e
> > > thought the current document is too big with unnecessary con= tent
> > > (i.e., 52 pages).
> > > We think we should reduce it to around 10 pages with concise=
> > > content with
> > >
> > even if it gets to 20p it can be ok,
> >  
> > > key problems for our IPWAVE WG.
> > > We come with the following structure with the revised title.=
> > >
> > > ------------------------------------------------------------= ---
> > > ---------------------------------------------
> > > Title: IP Wireless Access in Vehicular Environments (IPWAVE)= :
> > > Problem Statement and Use Cases
> > >
> > I prefer we start with use cases then problems, so title:
> >
> >  Title: IP Wireless Access in Vehicular Environments (IPWAVE= ): Use
> > Cases and Problem Statements
> >  
> > >
> > > Abstract
> > > 1. Introduction
> > > 2. Terminology
> > >    //each item: at most 4 lines
> > > 3. Use Cases: V2V, V2I, V2X
> > > 4. Current Architectures and Protocols
> > >  - General Problems: Latency, No security, No pseudonym= handling,
> > > No IP support, ...
> > >
> > why architecture in this draft, I suggest take this out, it is > > better in another draft, just focus on the aim an objectives of t= he
> > draft, the architecture needs another draft so if we update in > > future we just update architecture or update use cases,
> >
> >  
> > > 5. Problem Exploration
> > >  - IPv6 over IEEE 802.11-OCB
> > >  - Neighbor Discovery
> > >    . Link Model
> > >    .. MAC Address Pseudonym
> > >    . Prefix Dissemination/Exchange
> > >    . Routing
> > >  - Mobility Management
> > >    . E2E Connectivity over V2I
> > >  - Vehicle Identity Management
> > >  - Multihop V2X
> > >  - Service Discovery
> > >  - Security and Privacy
> > >  - Others
> > >
> > please make them as problem statements sections so 5.1, 5.2, ....= ..
> > also they need to cover our available charter only,
>  During the meeting in London the suggestion was to consider not = only
> the current charter but also other aspects/problems of interest/future=
> scope for this group.
> >  
> > >  6. Security Considerations
> > > ------------------------------------------------------------= ---
> > > ---------------------------------------------
> > >
> > > Please give us your comments on it.
> > >
> > > With the agreed content, we authors will move forward for th= e
> > > documentation..
> > >
> > >
> > thanks
> >
> > AB
> >
> >  
> > > Thanks.
> > >
> > > Best Regards,
> > > Paul
> > > --
> > > =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.
> > > Assistant 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.ph
> > > p
> > >
> > > _______________________________________________
> > > its mailing list
> > > its@ietf.o= rg
> > > https://www.ietf.org/mailman/listinfo/its
> > >
> > >
> >
> >
> > _______________________________________________
> > its mailing list
> > its@ietf.org
> > https://www.ietf.org/mailman/listinfo/its
>       Libre de virus. www.avast.com
>  _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its

_______________________________________________
its mailing list
its@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/its
_______________________________________________
its mailing list
its@ietf.org
htt= ps://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.
Assistant 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.
Assistant 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

--_000_7c14e776964c48f98b22528c4325597bHE105715emea1cdstintern_-- From nobody Mon Apr 9 11:26:22 2018 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 01D10129C51 for ; Mon, 9 Apr 2018 11:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 wzxITf_6Q8jI for ; Mon, 9 Apr 2018 11:26:19 -0700 (PDT) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (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 DB4301273B1 for ; Mon, 9 Apr 2018 11:26:18 -0700 (PDT) Received: by mail-pl0-x235.google.com with SMTP id b6-v6so5680297pla.11 for ; Mon, 09 Apr 2018 11:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=rMlFCF9y/gZD1CU1nMYxe7E3kfm+BeQ/PyWVBvADifg=; b=Ul6aXbkLxdIBk9GnQQtbG8EihCu9gLGod1UrvvpCE4+wdBVw1+IhAO6A2PDLFSabdS kErgLxgCOmbWc5BgjY7D3yeBB/4LgfIaAS2/PsVUlhdGOGTcUS+N5Biaw9PMQJDJUoyx Y2IVQsNRI+owXhZfbANkof/SEII1bd9K28s4Jq2PmRPs6tq6F25HIH7RvbG2se//+1+X GaHpZWH1ksHFmynGimVkTq6UqwrbNp1PqaHxCswkbvTXdtVrcucE7ZhVEEdwJ8NtjROz 5zP4FhN2CoBMCZO/MhTxPVtru+whAmCECDrW3WbHlrsrdqO/3ncv5bi+r2kTw4ppR7jr qKHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=rMlFCF9y/gZD1CU1nMYxe7E3kfm+BeQ/PyWVBvADifg=; b=iFNlDblB7RLIVo75GWJAkD7QfNr1qhYCHUPEOEFvrqvMLdT8w97GQSg+DX4u5jIZtJ IU0JCRlGomK6Ytjjbua4pWHFmSay6bMbkfliptJeAuoctwgCoDa9LeEXMxg7z/ij+4GG /wVGQXfnnySBe+V8GluExSIEIpjnH3haVXD1bemFJEfxDcujqTwJqE40QdeTHZubeqvo L79EFDiCuguNVOGgBmjotlRPz4kX9fWdLtgUjm7qToycT4+Lv2a18luLhXKrvIe1mwrm 4F/xe8Gw1a+rDiqcQKKrPLYPwHzb3Ea75UFcJNUgh5ghu4DHGBVaD2WQ8u/iAoKqpP03 xG1A== X-Gm-Message-State: AElRT7FOabIxjnNKnx/2cEojWxPWWCITOSYLYEdyyj/P6VFFgAz0I3kd NdLquCfzSy7Jj0yC/9M+PpQ= X-Google-Smtp-Source: AIpwx4+bwYQ/vTtSAhZk/v1dxsdyUYYb6tRdDoj2KHaicKZfNfEXIpGgLef6zEHyDWxpK2SyGOvDiw== X-Received: by 2002:a17:902:14cb:: with SMTP id y11-v6mr40606743plg.23.1523298378402; Mon, 09 Apr 2018 11:26:18 -0700 (PDT) Received: from localhost.localdomain (c-71-198-163-21.hsd1.ca.comcast.net. [71.198.163.21]) by smtp.gmail.com with ESMTPSA id f64sm1706266pfa.154.2018.04.09.11.26.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 09 Apr 2018 11:26:17 -0700 (PDT) Message-ID: <1523298376.2408.36.camel@gmail.com> From: Rex Buddenberg To: tony.li@tony.li, dickroy@alum.mit.edu Cc: John Kenney , skku_iotlab_seminar@googlegroups.com, its , Sandra Cespedes , Dirk.von-Hugo@telekom.de, "Mr. Jaehoon Paul Jeong" , Abdussalam Baryun Date: Mon, 09 Apr 2018 11:26:16 -0700 In-Reply-To: References: <1522010744.2694.42.camel@gmail.com> <05afff15f1c94cedabaa20212e3385b1@HE105715.emea1.cds.t-internal.com> <8C1BD1DF-A761-4A26-821E-46B524E27B20@tony.li> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Restructuring of the Problem Statement Document X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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, 09 Apr 2018 18:26:21 -0000 Tony, You're right -- Paul was just publishing an outline, not the text. Secondly, you're right in that we have good security tools, but they're not deployed/used.  I've advised myself hoarse about security nazis busily (and arrogantly) solving the wrong problem... To get constructive -- RR has things right: The first problem is lack of a sorting model.  The short version is that any security measures at layers 1-5 protect infrastructure.  Layer 6/7 security measures protect data ... and are infrastructure independent and agnostic.   The second problem is defining requirements.  IPSec is indeed layer 3 -- good for VPN tunnels.  That doesn't get security that's particularly useful in the use case.  The discussion seems to mix security and privacy without ever defining the terms.  Further, security usually seems to mean confidentiality.  I share your dubiousness about MAC address rotation -- convince me first that it doesn't make the message security problem worse.      The foundation security problem is authenticity of the data. Therefore, _message signing_ is the first solution; anything else is secondary. b On Mon, 2018-04-09 at 07:51 -0700, tony.li@tony.li wrote: > Again, I look forward to seeing the text. > > The mechanisms that I’ve seen implement privacy by rotating the MAC > address. AFAICT, that’s pretty much fatal to everything above it. > > And I’ll be the first to stipulate that there is no security in IP > anyway.  Partly because we can’t get people to deploy it.  ;-) > > Tony > > > > > > On Apr 9, 2018, at 7:14 AM, Dick Roy wrote: > > > > FYI, NOTHING about the current ITS security standards or their > > implementation "breaks anything IP"!  I have no idea where that > > thought came > > from, however it is simply wrong. 1609.2 is essentially > > "application level" > > security.  While nothing prevents lower layers from using those > > security > > services, there is NO implementation to date that does so, nor is > > there a > > good reason to do so.   > > > > Perhaps the issue is with IPsec? That after all is network layer > > security:^) > > > > RR > > > > -----Original Message----- > > From: its [mailto:its-bounces@ietf.org] On Behalf Of tony.li@tony.l > > i > > Sent: Monday, April 9, 2018 6:46 AM > > To: John Kenney > > Cc: Rex Buddenberg; skku_iotlab_seminar@googlegroups.com; its; > > Sandra > > Cespedes; Dirk.von-Hugo@telekom.de; Mr. Jaehoon Paul Jeong; > > Abdussalam > > Baryun > > Subject: Re: [ipwave] Restructuring of the Problem Statement > > Document > > > > > > > > > > > Reading the contents outline, I could infer that IETF considers > > > that a > > "general problem" with "current protocols for vehicular networking" > > is that > > there is "no security."  Is that a correct inference?   > > > > > > > > > If yes, then I disagree. Current protocols clearly include > > > security.   > > > > > > If my inference is incorrect, then I suggest the wording of the > > > contents > > outline be modified to avoid that impression.  I have the same > > comment about > > the other "general problems". > > > > > > I think it would be more fair to say that what we've seen of > > security > > proposals break all things IP. > > > > But it's probably not worth worrying about the wording of the > > outline. I > > suggest we wait to see the text. > > > > T > > > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > From nobody Mon Apr 16 06:29:19 2018 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 2D2C3126FDC for ; Mon, 16 Apr 2018 06:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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_LOW=-0.7, 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 JW_AGaMyKLZy for ; Mon, 16 Apr 2018 06:29:14 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 529231243F3 for ; Mon, 16 Apr 2018 06:29:14 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id s14so1277407ioc.0 for ; Mon, 16 Apr 2018 06:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0+2U6p27DrEAQsED3RJqrUnFFzDiYxoIH+yHMRWsoZE=; b=a83q9aZwzHIcTHaalGbr1rq9NLSV590OGZgcnxeXp+XLyZ1gJF6ji4gF5d8UdHRKnW UIaa6p7poYXqbZc2iTtJ4Vn3a4/zW5ATypiU+4jJy/msYi+jYTZO4/5SXEZ/RCvMJSSO pD6A27CZpF0zHH1IM4ZCYP1kRqohh/8SxD30uxH5aYNvyld8KMhoLgnRPuH17jWEq1DA TgUa5Q5t7b7rd6TJiwtjLhVB72YxunxCw/NLlB0at+lixoKlo2ct/K0VdchKgkRkMY7V PJlnBkcj8tcumUWiuP/7ywl06gf4NFdbPtUd9MsvC9RrmvwYxf2SDDX3dogsF3JJCVJP esyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0+2U6p27DrEAQsED3RJqrUnFFzDiYxoIH+yHMRWsoZE=; b=pGBNXDmThEHhAGv9iRlTis4HuImsFbh1NiP4bxQVjFytNZaMZS6YsDuNpCNaUZ2HkU qD02XUN7FNGtPZLJUPpZ/Z1NzgozV2f4uekLT8iEh0Mq7hm265WEhRvUWIz4AAUUAic2 AP1cKEEj87b5FaRXi9JoM11t4kQ0Jq9PxIxNJjUL1du+AAxnzGOLG7oOkQYyce0YaLQk +hooOKAv+1rOlFOTbYLvJThwyXrNav/9qquodx/mNO4UylrUFvUJk7HCGUky/ce0q0US /rWlcSCQucORkbsy8B8GR7vFu9wwBNhGIDm8mtawq/OTZ1J+tfWLvInTHshkBN+WfGWR wVfg== X-Gm-Message-State: ALQs6tDoNPT99x+1HB07wCp0Ry8PXSiSsH30AaneY6Jo/HL2myZ8I1zP /rE4E1m1IEFOcAK19+mTWV3IA1zlfb39+1WH1uk= X-Google-Smtp-Source: AIpwx48usOsjobNx0JN1FTHIT9GEpZJI2wvnUb8UxSmyzbQAsAVgpx2gzb/ba7x6pCqHR+VbiS74kppd5osY8mY+Vs0= X-Received: by 10.107.58.11 with SMTP id h11mr23969322ioa.283.1523885353353; Mon, 16 Apr 2018 06:29:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.130.134 with HTTP; Mon, 16 Apr 2018 06:28:42 -0700 (PDT) In-Reply-To: References: <1522010744.2694.42.camel@gmail.com> <05afff15f1c94cedabaa20212e3385b1@HE105715.emea1.cds.t-internal.com> From: "Mr. Jaehoon Paul Jeong" Date: Mon, 16 Apr 2018 22:28:42 +0900 Message-ID: To: John Kenney Cc: its , Abdussalam Baryun , Sandra Cespedes , Rex Buddenberg , Dirk.von-Hugo@telekom.de, skku_iotlab_seminar@googlegroups.com Content-Type: multipart/alternative; boundary="001a114aca742a4da70569f73595" Archived-At: Subject: Re: [ipwave] Restructuring of the Problem Statement Document X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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, 16 Apr 2018 13:29:18 -0000 --001a114aca742a4da70569f73595 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John, I am sorry for late reply because I was busy with my university work. You are right. The current protocols for vehicular networking have some levels of security= . In this document, we will address what security aspects will be addressed and investigated more. Thanks. Best Regards, Paul On Mon, Apr 9, 2018 at 10:31 PM, John Kenney wrote: > Hi Jaehoon, > > Reading the contents outline, I could infer that IETF considers that a > "general problem" with "current protocols for vehicular networking" is th= at > there is "no security." Is that a correct inference? > > If yes, then I disagree. Current protocols clearly include security. > > If my inference is incorrect, then I suggest the wording of the contents > outline be modified to avoid that impression. I have the same comment > about the other "general problems". > > Thanks, > John Kenney > > > On Sun, Apr 8, 2018 at 6:18 PM, Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > >> Hi IPWAVEers, >> Here is the revised contents structure for our problem statement >> document, >> based on the comments from AB, Sandra, Rex, and Dirk: >> >> ------------------------------------------------------------ >> ----------------------------------- >> Title: IP Wireless Access in Vehicular Environments (IPWAVE): Use Cases >> and Problem Statement >> >> Abstract >> 1. Introduction >> 2. Terminology >> (Note: each item has at most 4 lines.) >> 3. Use Cases >> 3.1 V2V >> 3.2 V2I >> 3.3 V2X >> 4. Analysis for Current Protocols >> 4.1 Current Protocols for Vehicular Networking >> 4.2 General Problems >> . Latency >> . No Security >> . No Pseudonym Handling >> . No IP Support >> 5. Problem Exploration >> 5.1 IPv6 over IEEE 802.11-OCB >> 5.2 Neighbor Discovery >> . Link Model >> . MAC Address Pseudonym >> . Prefix Dissemination/Exchange >> . Routing >> 5.3 Mobility Management >> . E2E Connectivity over V2I >> 5.4 Vehicle Identity Management >> 5.5 Multihop V2X >> 5.6 Multicast >> 5.7 DNS Naming Services and Service Discovery >> 5.8 IPv6 over Cellular Networks >> . Cellular V2X (C-V2X) Using 4G-LTE >> . Cellular V2X (C-V2X) Using 5G >> 5.9 Security and Privacy >> 6. Security Considerations >> ------------------------------------------------------------ >> ----------------------------------- >> >> If you don't have further comments, I will work for the revision of our >> document >> with the above contents along with the co-authors. >> >> Thanks. >> >> Best Regards, >> Paul >> >> On Mon, Apr 2, 2018 at 11:26 PM, Mr. Jaehoon Paul Jeong < >> jaehoon.paul@gmail.com> wrote: >> >>> Hi AB, Sandra, Rex, and Dirk, >>> Thanks for your comments. >>> >>> With your comments, I will revise the contents of the problem statement >>> document >>> this week and let you know the revised one this week. >>> >>> Thanks. >>> >>> Best Regards, >>> Paul >>> >>> On Tue, Mar 27, 2018 at 1:08 AM, wrote: >>> >>>> Dear all, >>>> regarding the mentioned 'other aspects/problems of interest/future >>>> scope' I think it would be worth to add a section for 5G / C-V2X (also >>>> revealed as an important technology) also with respect to interoperabi= lity >>>> and access heterogeneity (and since IEEE 802.11whatsoever may be widel= y >>>> seen as part of 5G access variants) and include it in the charter >>>> discussion. >>>> Thanks! >>>> Best Regards >>>> Dirk >>>> >>>> -----Original Message----- >>>> From: its [mailto:its-bounces@ietf.org] On Behalf Of Rex Buddenberg >>>> Sent: Sonntag, 25. M=C3=A4rz 2018 22:46 >>>> To: Sandra C=C3=A9spedes ; its@ietf.org >>>> Subject: Re: [ipwave] Restructuring of the Problem Statement Document >>>> >>>> Agree with Sandra's observation. Recommend specifically include >>>> multicast within the charter. >>>> >>>> >>>> On Fri, 2018-03-23 at 21:23 -0300, Sandra C=C3=A9spedes wrote: >>>> > >>>> > >>>> > On 3/23/2018 5:55 PM, Abdussalam Baryun wrote: >>>> > > >>>> > > >>>> > > On Fri, Mar 23, 2018 at 11:50 AM, Mr. Jaehoon Paul Jeong >>> > > paul@gmail.com> wrote: >>>> > > > Hi IPWAVEers, >>>> > > > Here is a proposed restructuring of the Problem Statement >>>> > > > Document: >>>> > > > https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networki= n >>>> > > > g-02 >>>> > > > >>>> > > > Sri and I discussed the current structure of the document. We >>>> > > > thought the current document is too big with unnecessary content >>>> > > > (i.e., 52 pages). >>>> > > > We think we should reduce it to around 10 pages with concise >>>> > > > content with >>>> > > > >>>> > > even if it gets to 20p it can be ok, >>>> > > >>>> > > > key problems for our IPWAVE WG. >>>> > > > We come with the following structure with the revised title. >>>> > > > >>>> > > > --------------------------------------------------------------- >>>> > > > --------------------------------------------- >>>> > > > Title: IP Wireless Access in Vehicular Environments (IPWAVE): >>>> > > > Problem Statement and Use Cases >>>> > > > >>>> > > I prefer we start with use cases then problems, so title: >>>> > > >>>> > > Title: IP Wireless Access in Vehicular Environments (IPWAVE): Use >>>> > > Cases and Problem Statements >>>> > > >>>> > > > >>>> > > > Abstract >>>> > > > 1. Introduction >>>> > > > 2. Terminology >>>> > > > //each item: at most 4 lines >>>> > > > 3. Use Cases: V2V, V2I, V2X >>>> > > > 4. Current Architectures and Protocols >>>> > > > - General Problems: Latency, No security, No pseudonym handling= , >>>> > > > No IP support, ... >>>> > > > >>>> > > why architecture in this draft, I suggest take this out, it is >>>> > > better in another draft, just focus on the aim an objectives of th= e >>>> > > draft, the architecture needs another draft so if we update in >>>> > > future we just update architecture or update use cases, >>>> > > >>>> > > >>>> > > > 5. Problem Exploration >>>> > > > - IPv6 over IEEE 802.11-OCB >>>> > > > - Neighbor Discovery >>>> > > > . Link Model >>>> > > > .. MAC Address Pseudonym >>>> > > > . Prefix Dissemination/Exchange >>>> > > > . Routing >>>> > > > - Mobility Management >>>> > > > . E2E Connectivity over V2I >>>> > > > - Vehicle Identity Management >>>> > > > - Multihop V2X >>>> > > > - Service Discovery >>>> > > > - Security and Privacy >>>> > > > - Others >>>> > > > >>>> > > please make them as problem statements sections so 5.1, 5.2, .....= . >>>> >>>> > > also they need to cover our available charter only, >>>> > During the meeting in London the suggestion was to consider not onl= y >>>> > the current charter but also other aspects/problems of interest/futu= re >>>> > scope for this group. >>>> > > >>>> > > > 6. Security Considerations >>>> > > > --------------------------------------------------------------- >>>> > > > --------------------------------------------- >>>> > > > >>>> > > > Please give us your comments on it. >>>> > > > >>>> > > > With the agreed content, we authors will move forward for the >>>> > > > documentation.. >>>> > > > >>>> > > > >>>> > > thanks >>>> > > >>>> > > AB >>>> > > >>>> > > >>>> > > > Thanks. >>>> > > > >>>> > > > Best Regards, >>>> > > > Paul >>>> > > > -- >>>> > > > =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. >>>> > > > Assistant 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.ph >>>> > > > p >>>> > > > >>>> > > > _______________________________________________ >>>> > > > its mailing list >>>> > > > its@ietf.org >>>> > > > https://www.ietf.org/mailman/listinfo/its >>>> > > > >>>> > > > >>>> > > >>>> > > >>>> > > _______________________________________________ >>>> > > its mailing list >>>> > > its@ietf.org >>>> > > https://www.ietf.org/mailman/listinfo/its >>>> > Libre de virus. www.avast.com >>>> > _______________________________________________ >>>> > its mailing list >>>> > its@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/its >>>> >>>> _______________________________________________ >>>> its mailing list >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>>> _______________________________________________ >>>> 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. >>> Assistant 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. >> Assistant 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 >> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> > > > -- > John Kenney > Director and Principal Researcher > Toyota InfoTechnology Center, USA > 465 Bernardo Avenue > > Mountain View, CA 94043 > > Tel: 650-694-4160. Mobile: 650-224-6644 > --=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. Assistant 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 --001a114aca742a4da70569f73595 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,
I am sorry for late reply because I was busy = with my university work.

You are right.
= The current protocols for vehicular networking have some levels of security= .
In this document, we will address what security aspects will be= addressed and investigated more.

Thanks.

Best Regards,
Paul

On Mon, Apr 9, 2018 at 10:31 PM, John Ken= ney <jkenney@us.toyota-itc.com> wrote:
Hi Jaehoon,

Readin= g the contents outline, I could infer that IETF considers that a "gene= ral problem" with "current protocols for vehicular networking&quo= t; is that there is "no security."=C2=A0 Is that a correct infere= nce?=C2=A0=C2=A0

If yes, then I disagree. Current = protocols clearly include security.=C2=A0=C2=A0

If= my inference is incorrect, then I suggest the wording of the contents outl= ine be modified to avoid that impression.=C2=A0 I have the same comment abo= ut the other "general problems".

Thanks,= =C2=A0
John Kenney


On Sun, Apr 8,= 2018 at 6:18 PM, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com&= gt; wrote:
Hi IPWAVEers,
Here is the revised contents= structure for our problem statement document,=C2=A0
based on the= comments from AB, Sandra, Rex, and Dirk:

--------= -----------------------------------------------------------------= ----------------------
Title: IP Wireless Access = in Vehicular Environments (IPWAVE): Use Cases and Problem Statement

Abstract
1. Introduction
2. Terminology
=C2=A0 =C2=A0(Note: each item has at most = 4 lines.)
3. Use Cases
=C2=A03.1 V2V
=C2=A03.= 2 V2I
=C2=A03.3 V2X
4. Analysis for Current Protocols
=C2=A04.1 Current Protocols for Vehicular Networking
=C2= =A04.2 General Problems
=C2=A0 =C2=A0. Latency
=C2=A0 = =C2=A0. No Security
=C2=A0 =C2=A0. No Pseudonym Handling
=C2=A0 =C2=A0. No IP Support=C2=A0
5. Problem Exploration
=
=C2=A05.1 IPv6 over IEEE 802.11-OCB
=C2=A05.2 Neighbor Disco= very
=C2=A0 =C2=A0. Link Model
=C2=A0 =C2=A0. MAC= Address Pseudonym
=C2=A0 =C2=A0. Prefix Dissemination/Exchange
=C2=A0 =C2=A0. Routing
=C2=A05.3 Mobility Managem= ent
=C2=A0 =C2=A0. E2E Connectivity over V2I
=C2=A05.4 Vehicle Identity Management=C2=A0=C2=A0
=C2=A05.5 Mu= ltihop V2X
=C2=A05.6 Multicast
=C2=A05.7 DNS Naming Ser= vices and Service Discovery
=C2=A05.8 IPv6 over Cellular Networks=
=C2=A0 =C2=A0. Cellular V2X (C-V2X) Using 4G-LTE
=C2= =A0 =C2=A0. Cellular V2X (C-V2X) Using 5G=C2=A0
=C2=A05.9 Securit= y and Privacy
=C2=A06. Security Considerations
--------------------------------------------= ---------------------------------------------------=C2=A0<= /div>
=C2=A0 =C2=A0
If you don't have further comments, I will work = for the revision of our document=C2=A0
with the above contents al= ong with the co-authors.

Thanks.

Best Regards,
Paul

On = Mon, Apr 2, 2018 at 11:26 PM, Mr. Jaehoon Paul Jeong <= jaehoon.paul@gm= ail.com> wrote:
Hi AB, Sandra, Rex, a= nd Dirk,
Thanks for your comments.

With your comments, I will revise the contents of the problem statement d= ocument=C2=A0
this week and let you know the revised one this wee= k.

Thanks.

Best Regards,<= /div>
Paul
=

On Tue, Mar 27, 2018 at 1:08 AM, <Dirk.von-Hugo@telekom.de= > wrote:
<= div class=3D"h5">Dear all,
regarding the mentioned 'other aspects/problems of interest/future scop= e' I think it would be worth to add a section for 5G / C-V2X (also reve= aled as an important technology) also with respect to interoperability and = access heterogeneity (and since IEEE 802.11whatsoever may be widely seen as= part of 5G access variants) and include it in the charter discussion.
Thanks!
Best Regards
Dirk
<= div>

-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On Behalf Of Rex Buddenberg
Sent: Sonntag, 25. M=C3=A4rz 2018 22:46
To: Sandra C=C3=A9spedes <scespedes@ing.uchile.cl>; its@ietf.org
Subject: Re: [ipwave] Restructuring of the Problem Statement Document

Agree with Sandra's observation.=C2=A0 Recommend specifically include m= ulticast within the charter.


On Fri, 2018-03-23 at 21:23 -0300, Sandra C=C3=A9spedes wrote:
>
> =C2=A0
> On 3/23/2018 5:55 PM, Abdussalam Baryun wrote:
> >
> >
> > On Fri, Mar 23, 2018 at 11:50 AM, Mr. Jaehoon Paul Jeong <jaeh= oon..
> > paul@gmail.co= m> wrote:
> > > Hi IPWAVEers,
> > > Here is a proposed restructuring of the Problem Statement > > > Document:
> > > https://tools.ietf.o= rg/html/draft-ietf-ipwave-vehicular-networkin
> > > g-02
> > >
> > > Sri and I discussed the current structure of the document. W= e
> > > thought the current document is too big with unnecessary con= tent
> > > (i.e., 52 pages).
> > > We think we should reduce it to around 10 pages with concise=
> > > content with
> > >
> > even if it gets to 20p it can be ok,
> > =C2=A0
> > > key problems for our IPWAVE WG.
> > > We come with the following structure with the revised title.=
> > >
> > > -------------------------------------------------------= --------
> > > ---------------------------------------------
> > > Title: IP Wireless Access in Vehicular Environments (IPWAVE)= :
> > > Problem Statement and Use Cases
> > >
> > I prefer we start with use cases then problems, so title:
> >
> > =C2=A0Title: IP Wireless Access in Vehicular Environments (IPWAVE= ): Use
> > Cases and Problem Statements
> > =C2=A0
> > >
> > > Abstract
> > > 1. Introduction
> > > 2. Terminology
> > > =C2=A0 =C2=A0//each item: at most 4 lines
> > > 3. Use Cases: V2V, V2I, V2X
> > > 4. Current Architectures and Protocols
> > > =C2=A0- General Problems: Latency, No security, No pseudonym= handling,
> > > No IP support, ...
> > >
> > why architecture in this draft, I suggest take this out, it is > > better in another draft, just focus on the aim an objectives of t= he
> > draft, the architecture needs another draft so if we update in > > future we just update architecture or update use cases,
> >
> > =C2=A0
> > > 5. Problem Exploration
> > > =C2=A0- IPv6 over IEEE 802.11-OCB
> > > =C2=A0- Neighbor Discovery
> > > =C2=A0 =C2=A0. Link Model
> > > =C2=A0 =C2=A0.. MAC Address Pseudonym
> > > =C2=A0 =C2=A0. Prefix Dissemination/Exchange
> > > =C2=A0 =C2=A0. Routing
> > > =C2=A0- Mobility Management
> > > =C2=A0 =C2=A0. E2E Connectivity over V2I
> > > =C2=A0- Vehicle Identity Management
> > > =C2=A0- Multihop V2X
> > > =C2=A0- Service Discovery
> > > =C2=A0- Security and Privacy
> > > =C2=A0- Others
> > >
> > please make them as problem statements sections so 5.1, 5.2, ....= ..

> > also they need to cover our available charter only,
> =C2=A0During the meeting in London the suggestion was to consider not = only
> the current charter but also other aspects/problems of interest/future=
> scope for this group.
> > =C2=A0
> > > =C2=A06. Security Considerations
> > > -------------------------------------------------------= --------
> > > ---------------------------------------------
> > >
> > > Please give us your comments on it.
> > >
> > > With the agreed content, we authors will move forward for th= e
> > > documentation..
> > >
> > >
> > thanks
> >
> > AB
> >
> > =C2=A0
> > > Thanks.
> > >
> > > Best Regards,
> > > Paul
> > > --
> > > =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.
> > > Assistant 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.ph
> > > p
> > >
> > > _______________________________________________
> > > its mailing list
> > > its@ietf.o= rg
> > > https://www.ietf.org/mailman/listinfo/i= ts
> > >
> > >
> >
> >
> > _______________________________________________
> > its mailing list
> > its@ietf.org
> > https://www.ietf.org/mailman/listinfo/its
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Libre de virus. www.avast.com
> =C2=A0_______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
_______________________________________________
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.
Assist= ant Professor
Department of Software
Sungkyunkwan University
Offic= e: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@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.
Assistant Professor
Depa= rtment of Software
Sungkyunkwan University
Office: +82-31-299-4957Email: jaehoon= .paul@gmail.com,=C2=A0pauljeong@skku.eduPersonal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.ph= p

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




--
John Kenney
Director and Principal Researcher
Toyota InfoTechnology Center, USA
Tel: 650-694-4160. Mobile: 650-224-6644


--
=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) Jeon= g, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan U= niversity
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.s= kku.edu/people-jaehoon-jeong.php
--001a114aca742a4da70569f73595-- From nobody Tue Apr 17 10:58:05 2018 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C0212D959; Tue, 17 Apr 2018 10:58:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: housley@vigilsec.com, suresh@kaloom.com, its@ietf.org, ipwave-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152398788417.11555.16421947970899885923.idtracker@ietfa.amsl.com> Date: Tue, 17 Apr 2018 10:58:04 -0700 Archived-At: Subject: [ipwave] ipwave - New Meeting Session Request for IETF 102 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 17 Apr 2018 17:58:04 -0000 A new meeting session request has just been submitted by Russ Housley, a Chair of the ipwave working group. --------------------------------------------------------- Working Group Name: IP Wireless Access in Vehicular Environments Area Name: Internet Area Session Requester: Russ Housley Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: dmm detnet nfvrg lamps stir intarea 6lo 6man manet rtgarea saag l2sm suit Second Priority: sfc cfrg dhc roll i2nsf secdispatch Third Priority: mtgvenue iasa20 People who must be present: Russ Housley Suresh Krishnan Carlos J. Bernardos Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Apr 18 11:39:21 2018 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 32343124BE8 for ; Wed, 18 Apr 2018 11:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 S6CNC6qxBWR2 for ; Wed, 18 Apr 2018 11:39:17 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B5831200FC for ; Wed, 18 Apr 2018 11:39:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6A46E300687 for ; Wed, 18 Apr 2018 14:39:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id y-FxPyYmcSFx for ; Wed, 18 Apr 2018 14:39:14 -0400 (EDT) Received: from [172.20.3.209] (unknown [65.216.167.67]) by mail.smeinc.net (Postfix) with ESMTPSA id 8ABA03002AD for ; Wed, 18 Apr 2018 14:39:14 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <5F0CC237-5B49-477D-9FF2-D03840AC6D26@vigilsec.com> Date: Wed, 18 Apr 2018 14:39:15 -0400 To: its X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [ipwave] IPWAVE Recharter Topics? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 18 Apr 2018 18:39:19 -0000 I saw very little excitement for rechartering the IPWAVE WG. There were a small number of people want to do something, but most people felt that other standards bodies should tackle non-IP topics. Are there any IP-related topics that need to be tackled? If so, is there enough interest and energy among the IPWAVE WG participants to tackle them? Russ From nobody Wed Apr 18 14:13:01 2018 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 940FD126CD6 for ; Wed, 18 Apr 2018 14:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 NvIiIpnMU0X6 for ; Wed, 18 Apr 2018 14:12:54 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 93DDE126C3D for ; Wed, 18 Apr 2018 14:12:54 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id s70so3305754qks.13 for ; Wed, 18 Apr 2018 14:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=h1QZbGXDTv1aH+clU6qj+JZpC9yYfIKmx6Nk4NbMmVA=; b=QWvUO+doGdL1KdWZnGqQbtjNUFxuznFrtQmizpo/WBCjdSPJR2+SxnJF+XRZpwGpWU hfVqmnc0d5KnjSpi2HuzJs1Jo4bsaOucYBUpmLj8BLb6U4WHJyqCXvZaD3QBUVzM0zCu J5r3eVqTmkxKDoioBEBJT+cMByOkcmL/UAFOIomcSbS75odqL+n36p8Kumf2SI3MzJQS TuEmCdgXBIVxbfiQ/JuVLNOcmFX+kExPC4SyofbbLNz8+KoVqImVBsSgRoND+xzZa2IO mtmRtIMOynuXHotHAJpJKVtmGF2hKvvGKd5NZoRKQPdSph7sMnBFpRiW7dkb29kIWPmX kO9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=h1QZbGXDTv1aH+clU6qj+JZpC9yYfIKmx6Nk4NbMmVA=; b=XzeM3Go1mPCWeuzus94Rnk5PJURIGa6Yhiu/7voG7/Id+BlkoLjlovKCJlh5NxprKW hgWsxXsCl5UKDcpTE+SuG/93VT6LbCKmfRW0ZjP7aThsLBVDkMh7CPpq32lGXWH4RuVQ papERJlweBi/GqbrdTRBlFXrq3WizBNytTXIjaHxAAtgatM13Jfep9nmGpcuNL66kFbi fJD6AYUHpvHQFC7uwWdGR77dhtC+OWofvm5A/OI8Kcdw/Byt+RvW5MvyNTA2X28/RG7e xyM25BJKheQA6OOz5GEu2nFIvlTMMwrX2D8MFgf7x665xpQ0QxiELxW5LiVDxC22mnEB ypOw== X-Gm-Message-State: ALQs6tD+cRSsxd4MGqQ9zCnmfRmXBcFN8bpd0CR8/6Ry1IWWjjaPQEWK 5oePjjGQvArBi9gDfX6Y7RY= X-Google-Smtp-Source: AIpwx4+OoioALFyy/ogwr+p/6bH60vN3BGa/XAmkoP57e4WU8ybEsZ0NOUM3G66ludWlQZyOAFWX1w== X-Received: by 10.55.31.8 with SMTP id f8mr3169603qkf.402.1524085973666; Wed, 18 Apr 2018 14:12:53 -0700 (PDT) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id z7sm1554514qke.19.2018.04.18.14.12.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Apr 2018 14:12:52 -0700 (PDT) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Mr. Jaehoon Paul Jeong'" , , "'Abdussalam Baryun'" , "'Sandra Cespedes'" , "'Rex Buddenberg'" , Cc: References: <1522010744.2694.42.camel@gmail.com> <05afff15f1c94cedabaa20212e3385b1@HE105715.emea1.cds.t-internal.com> In-Reply-To: Date: Wed, 18 Apr 2018 17:12:50 -0400 Message-ID: <003001d3d75a$03921490$0ab63db0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01D3D738.7C852F80" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKA5BPEl+P48ljs5vuiSqqfRHdaYgGmTZVpAW74hy8CX832tAGOUI4bAm7EU5AByYvGv6JRBOVg Content-Language: en-us Archived-At: Subject: Re: [ipwave] Restructuring of the Problem Statement Document X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 18 Apr 2018 21:12:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0031_01D3D738.7C852F80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Comments in the e-mail text. Fygs. =20 From: its On Behalf Of Mr. Jaehoon Paul Jeong Sent: Sunday, April 08, 2018 9:19 PM To: its@ietf.org; Abdussalam Baryun ; Sandra = Cespedes ; Rex Buddenberg = ; Dirk.von-Hugo@telekom.de Cc: skku_iotlab_seminar@googlegroups.com; Mr. Jaehoon Paul Jeong = Subject: Re: [ipwave] Restructuring of the Problem Statement Document =20 Hi IPWAVEers, Here is the revised contents structure for our problem statement = document,=20 based on the comments from AB, Sandra, Rex, and Dirk: =20 -------------------------------------------------------------------------= ---------------------- Title: IP Wireless Access in Vehicular Environments (IPWAVE): Use Cases = and Problem Statement =20 [Fygs: Actually, this re-structure of the IPWAVE document as per outline = make more sense. The =E2=80=9Capplications=E2=80=9D (use cases) are = being analyzed first and from the application requirements, a = communication service is identified to meet the requirements (e.g.; IPv6 = and OCB).]. =20 Abstract 1. Introduction 2. Terminology (Note: each item has at most 4 lines.) 3. Use Cases [Fygs: Is not really possible to cover all cases. Personally, I prefer = logical and/or mathematical models as it permits analysis of most = cases.] 3.1 V2V 3.2 V2I 3.3 V2X 4. Analysis for Current Protocols 4.1 Current Protocols for Vehicular Networking 4.2 General Problems . Latency [Fygs: This is not a =E2=80=9Cproblem=E2=80=9D but a fact = in any system.] . No Security [Fygs: actually, Security is addressed in most current = protocols] . No Pseudonym Handling . No IP Support [Fygs: This is not a really a general problem.] 5. Problem Exploration 5.1 IPv6 over IEEE 802.11-OCB [Fygs: I do not think the purpose = (applications) of the communication services offered by IPv6 and IEEE = 802.11 =E2=80=93 OCB has been seriously explored.] 5.2 Neighbor Discovery [Fygs: Sorry about my ignorance on this = subject.] . Link Model . MAC Address Pseudonym . Prefix Dissemination/Exchange . Routing 5.3 Mobility Management . E2E Connectivity over V2I 5.4 Vehicle Identity Management =20 5.5 Multihop V2X 5.6 Multicast 5.7 DNS Naming Services and Service Discovery 5.8 IPv6 over Cellular Networks [Fygs: Originally, cellular and other = communications services where to be addressed separately from IEEE = 802.11-OCB.] . Cellular V2X (C-V2X) Using 4G-LTE . Cellular V2X (C-V2X) Using 5G=20 5.9 Security and Privacy 6. Security Considerations -------------------------------------------------------------------------= ----------------------=20 =20 If you don't have further comments, I will work for the revision of our = document=20 with the above contents along with the co-authors. =20 Thanks. =20 Best Regards, Paul =20 On Mon, Apr 2, 2018 at 11:26 PM, Mr. Jaehoon Paul Jeong = > wrote: Hi AB, Sandra, Rex, and Dirk, Thanks for your comments. =20 With your comments, I will revise the contents of the problem statement = document=20 this week and let you know the revised one this week. =20 Thanks. =20 Best Regards, Paul =20 On Tue, Mar 27, 2018 at 1:08 AM, > wrote: Dear all, regarding the mentioned 'other aspects/problems of interest/future = scope' I think it would be worth to add a section for 5G / C-V2X (also = revealed as an important technology) also with respect to = interoperability and access heterogeneity (and since IEEE = 802.11whatsoever may be widely seen as part of 5G access variants) and = include it in the charter discussion. Thanks! Best Regards Dirk -----Original Message----- From: its [mailto:its-bounces@ietf.org ] = On Behalf Of Rex Buddenberg Sent: Sonntag, 25. M=C3=A4rz 2018 22:46 To: Sandra C=C3=A9spedes >; its@ietf.org =20 Subject: Re: [ipwave] Restructuring of the Problem Statement Document Agree with Sandra's observation. Recommend specifically include = multicast within the charter. On Fri, 2018-03-23 at 21:23 -0300, Sandra C=C3=A9spedes wrote: > > =20 > On 3/23/2018 5:55 PM, Abdussalam Baryun wrote: > > > > > > On Fri, Mar 23, 2018 at 11:50 AM, Mr. Jaehoon Paul Jeong > paul@gmail.com > wrote: > > > Hi IPWAVEers, > > > Here is a proposed restructuring of the Problem Statement > > > Document: > > > https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networkin > > > g-02 > > > > > > Sri and I discussed the current structure of the document. We > > > thought the current document is too big with unnecessary content > > > (i.e., 52 pages). > > > We think we should reduce it to around 10 pages with concise > > > content with > > > > > even if it gets to 20p it can be ok, > > =20 > > > key problems for our IPWAVE WG. > > > We come with the following structure with the revised title. > > > > > > --------------------------------------------------------------- > > > --------------------------------------------- > > > Title: IP Wireless Access in Vehicular Environments (IPWAVE): > > > Problem Statement and Use Cases > > > > > I prefer we start with use cases then problems, so title: > > > > Title: IP Wireless Access in Vehicular Environments (IPWAVE): Use > > Cases and Problem Statements > > =20 > > > > > > Abstract > > > 1. Introduction > > > 2. Terminology > > > //each item: at most 4 lines > > > 3. Use Cases: V2V, V2I, V2X > > > 4. Current Architectures and Protocols > > > - General Problems: Latency, No security, No pseudonym handling, > > > No IP support, ... > > > > > why architecture in this draft, I suggest take this out, it is > > better in another draft, just focus on the aim an objectives of the > > draft, the architecture needs another draft so if we update in > > future we just update architecture or update use cases, > > > > =20 > > > 5. Problem Exploration > > > - IPv6 over IEEE 802.11-OCB > > > - Neighbor Discovery > > > . Link Model > > > .. MAC Address Pseudonym > > > . Prefix Dissemination/Exchange > > > . Routing > > > - Mobility Management > > > . E2E Connectivity over V2I > > > - Vehicle Identity Management > > > - Multihop V2X > > > - Service Discovery > > > - Security and Privacy > > > - Others > > > > > please make them as problem statements sections so 5.1, 5.2, ...... > > also they need to cover our available charter only, > During the meeting in London the suggestion was to consider not only > the current charter but also other aspects/problems of interest/future > scope for this group. > > =20 > > > 6. Security Considerations > > > --------------------------------------------------------------- > > > --------------------------------------------- > > > > > > Please give us your comments on it. > > > > > > With the agreed content, we authors will move forward for the > > > documentation.. > > > > > > > > thanks > > > > AB > > > > =20 > > > Thanks. > > > > > > Best Regards, > > > Paul > > > -- > > > = =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. > > > Assistant 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.ph > > > p > > > > > > _______________________________________________ > > > its mailing list > > > its@ietf.org =20 > > > https://www.ietf.org/mailman/listinfo/its > > > > > > > > > > > > _______________________________________________ > > its mailing list > > its@ietf.org =20 > > https://www.ietf.org/mailman/listinfo/its > Libre de virus. www.avast.com =20 > _______________________________________________ > its mailing list > its@ietf.org =20 > https://www.ietf.org/mailman/listinfo/its _______________________________________________ its mailing list its@ietf.org =20 https://www.ietf.org/mailman/listinfo/its _______________________________________________ its mailing list its@ietf.org =20 https://www.ietf.org/mailman/listinfo/its =20 --=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. Assistant 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 = =20 =20 --=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. Assistant 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 = =20 ------=_NextPart_000_0031_01D3D738.7C852F80 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Comments = in the e-mail text.=C2=A0 Fygs.

 

From: = its <its-bounces@ietf.org> On Behalf Of Mr. Jaehoon Paul = Jeong
Sent: Sunday, April 08, 2018 9:19 PM
To: = its@ietf.org; Abdussalam Baryun <abdussalambaryun@gmail.com>; = Sandra Cespedes <scespedes@ing.uchile.cl>; Rex Buddenberg = <buddenbergr@gmail.com>; Dirk.von-Hugo@telekom.de
Cc: = skku_iotlab_seminar@googlegroups.com; Mr. Jaehoon Paul Jeong = <jaehoon.paul@gmail.com>
Subject: Re: [ipwave] = Restructuring of the Problem Statement Document

 

Hi = IPWAVEers,

Here is the revised = contents structure for our problem statement = document, 

based on = the comments from AB, Sandra, Rex, and Dirk:

 

-------------------------------------------------------= ----------------------------------------

Title: IP Wireless Access in Vehicular Environments = (IPWAVE): Use Cases and Problem Statement

 

[Fygs: = Actually, this re-structure of the IPWAVE document as per outline make = more sense.=C2=A0 The =E2=80=9Capplications=E2=80=9D (use cases) are = being analyzed first and from the application requirements, a = communication service is identified to meet the requirements (e.g.; IPv6 = and OCB).].

 

Abstract

1. Introduction

2. Terminology

   (Note: each item has at most 4 = lines.)

3. Use = Cases

[Fygs: Is not really = possible to cover all cases. Personally, I prefer logical and/or = mathematical models as it permits analysis of most = cases.]

 3.1 = V2V

 3.2 = V2I

 3.3 = V2X

4. Analysis for = Current Protocols

 4.1 Current Protocols for Vehicular = Networking

 4.2 = General Problems

  =  . Latency [Fygs: This is not a =E2=80=9Cproblem=E2=80=9D but a = fact in any system.]

   . No Security [Fygs: actually, = Security is addressed in most current = protocols]

  =  . No Pseudonym Handling

   . No IP Support [Fygs: This is = not a really a general problem.]

5. Problem Exploration

 5.1 IPv6 over IEEE 802.11-OCB [Fygs: I do not = think the purpose (applications) of the communication services offered = by IPv6 and IEEE 802.11 =E2=80=93 OCB has been seriously = explored.]

 5.2 = Neighbor Discovery [Fygs: Sorry about my ignorance on this = subject.]

  =  . Link Model

  =  . MAC Address Pseudonym

   . Prefix = Dissemination/Exchange

   . Routing

 5.3 Mobility = Management

   . = E2E Connectivity over V2I

 5.4 Vehicle Identity = Management  

 5.5 Multihop V2X

 5.6 Multicast

 5.7 DNS Naming Services and Service = Discovery

 5.8 IPv6 = over Cellular Networks [Fygs: Originally, cellular and other = communications services where to be addressed separately from IEEE = 802.11-OCB.]

  =  . Cellular V2X (C-V2X) Using 4G-LTE

   . Cellular V2X (C-V2X) Using = 5G 

 5.9 = Security and Privacy

 6. Security = Considerations

---------------------------------------------------------= -------------------------------------- 

<= div>

   

If you don't have further comments, I will work for = the revision of our document 

with the above contents along with the = co-authors.

 

Thanks.

 

Best Regards,

Paul

 

On Mon, = Apr 2, 2018 at 11:26 PM, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> = wrote:

Hi AB, Sandra, Rex, and = Dirk,

Thanks for your = comments.

 

With your comments, I will revise the contents of the = problem statement document 

this week and let you know the revised one this = week.

 

Thanks.

 

Best Regards,

Paul

 

On Tue, = Mar 27, 2018 at 1:08 AM, <Dirk.von-Hugo@telekom.de> = wrote:

Dear all,
regarding the mentioned 'other = aspects/problems of interest/future scope' I think it would be worth to = add a section for 5G / C-V2X (also revealed as an important technology) = also with respect to interoperability and access heterogeneity (and = since IEEE 802.11whatsoever may be widely seen as part of 5G access = variants) and include it in the charter discussion.
Thanks!
Best = Regards
Dirk


-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On Behalf Of Rex = Buddenberg
Sent: Sonntag, 25. M=C3=A4rz 2018 22:46
To: Sandra = C=C3=A9spedes <scespedes@ing.uchile.cl>; its@ietf.org
Subject: Re: [ipwave] = Restructuring of the Problem Statement Document

Agree with = Sandra's observation.  Recommend specifically include multicast = within the charter.


On Fri, 2018-03-23 at 21:23 -0300, Sandra = C=C3=A9spedes wrote:
>
>  
> On 3/23/2018 5:55 = PM, Abdussalam Baryun wrote:
> >
> >
> > On = Fri, Mar 23, 2018 at 11:50 AM, Mr. Jaehoon Paul Jeong = <jaehoon..
> > paul@gmail.com> wrote:
> > > Hi = IPWAVEers,
> > > Here is a proposed restructuring of the = Problem Statement
> > > Document:
> > > https://tools.ietf.org/html/draft-ietf-ipwave-vehicular= -networkin
> > > g-02
> > >
> > = > Sri and I discussed the current structure of the document. = We
> > > thought the current document is too big with = unnecessary content
> > > (i.e., 52 pages).
> > = > We think we should reduce it to around 10 pages with = concise
> > > content with
> > >
> > = even if it gets to 20p it can be ok,
> >  
> > = > key problems for our IPWAVE WG.
> > > We come with the = following structure with the revised title.
> > >
> = > > = ---------------------------------------------------------------
> = > > ---------------------------------------------
> > = > Title: IP Wireless Access in Vehicular Environments = (IPWAVE):
> > > Problem Statement and Use Cases
> > = >
> > I prefer we start with use cases then problems, so = title:
> >
> >  Title: IP Wireless Access in = Vehicular Environments (IPWAVE): Use
> > Cases and Problem = Statements
> >  
> > >
> > > = Abstract
> > > 1. Introduction
> > > 2. = Terminology
> > >    //each item: at most 4 = lines
> > > 3. Use Cases: V2V, V2I, V2X
> > > 4. = Current Architectures and Protocols
> > >  - General = Problems: Latency, No security, No pseudonym handling,
> > > = No IP support, ...
> > >
> > why architecture in = this draft, I suggest take this out, it is
> > better in = another draft, just focus on the aim an objectives of the
> > = draft, the architecture needs another draft so if we update in
> = > future we just update architecture or update use cases,
> = >
> >  
> > > 5. Problem = Exploration
> > >  - IPv6 over IEEE 802.11-OCB
> = > >  - Neighbor Discovery
> > >    . = Link Model
> > >    .. MAC Address = Pseudonym
> > >    . Prefix = Dissemination/Exchange
> > >    . Routing
> = > >  - Mobility Management
> > >    . = E2E Connectivity over V2I
> > >  - Vehicle Identity = Management
> > >  - Multihop V2X
> > > =  - Service Discovery
> > >  - Security and = Privacy
> > >  - Others
> > >
> > = please make them as problem statements sections so 5.1, 5.2, = ......
> > also they need to cover our available charter = only,
>  During the meeting in London the suggestion was to = consider not only
> the current charter but also other = aspects/problems of interest/future
> scope for this = group.
> >  
> > >  6. Security = Considerations
> > > = ---------------------------------------------------------------
> = > > ---------------------------------------------
> > = >
> > > Please give us your comments on it.
> > = >
> > > With the agreed content, we authors will move = forward for the
> > > documentation..
> > = >
> > >
> > thanks
> >
> > = AB
> >
> >  
> > > Thanks.
> = > >
> > > Best Regards,
> > > Paul
> = > > --
> > > = =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.
> > = > Assistant 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.ph
&= gt; > > p
> > >
> > > = _______________________________________________
> > > its = mailing list
> > > its@ietf.org
> > > https://www.ietf.org/mailman/listinfo/its
> = > >
> > >
> >
> >
> > = _______________________________________________
> > its mailing = list
> > its@ietf.org
> > https://www.ietf.org/mailman/listinfo/its
>&n= bsp;      Libre de virus. www.avast.com
> =  _______________________________________________
> its = mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its

__= _____________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
______= _________________________________________
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.
Assistant = 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.
Assistant = 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

------=_NextPart_000_0031_01D3D738.7C852F80-- From nobody Thu Apr 19 08:38:19 2018 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 6ED0512D87E for ; Thu, 19 Apr 2018 08:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham 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 jLYXJtpXqZK2 for ; Thu, 19 Apr 2018 08:38:16 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 1050212D80E for ; Thu, 19 Apr 2018 08:38:15 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w3JFcEPS020631 for ; Thu, 19 Apr 2018 17:38:14 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 031242067A0 for ; Thu, 19 Apr 2018 17:38:14 +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 ED0B62064A4 for ; Thu, 19 Apr 2018 17:38:13 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w3JFcDhF005804 for ; Thu, 19 Apr 2018 17:38:13 +0200 To: its@ietf.org References: <5F0CC237-5B49-477D-9FF2-D03840AC6D26@vigilsec.com> From: Alexandre Petrescu Message-ID: <7ea5c1eb-69fc-9262-e84b-5d830078aad5@gmail.com> Date: Thu, 19 Apr 2018 17:38:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <5F0CC237-5B49-477D-9FF2-D03840AC6D26@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] IPWAVE Recharter Topics? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 19 Apr 2018 15:38:18 -0000 I think there are several things on the table: - QoS OCB-Ethernet, - ND over OCB, - XER-CAM/UDP/IP (instead of UPER-CAM/Geonet), - RA prefix exchanges for V2V, - 65-SLAAC (instead of 64-SLAAC), - IPv6-over-802.11-NGV, - IP Discovery of nearby vehicles, - Security. There is also some comment in 6man that deserves consideration with respect to ND. Le 18/04/2018 à 20:39, Russ Housley a écrit : > I saw very little excitement for rechartering the IPWAVE WG. There were > a small number of people want to do something, but most people felt that > other standards bodies should tackle non-IP topics. > > Are there any IP-related topics that need to be tackled? If so, is > there enough interest and energy among the IPWAVE WG participants to > tackle them? > > Russ > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Thu Apr 19 08:59:26 2018 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 7D8A0120227 for ; Thu, 19 Apr 2018 08:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham 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 ahgOLfw8ggoH for ; Thu, 19 Apr 2018 08:59:22 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 BA7AC12DA6F for ; Thu, 19 Apr 2018 08:59:11 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w3JFxAql026600 for ; Thu, 19 Apr 2018 17:59:10 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 24FDB2067E5 for ; Thu, 19 Apr 2018 17:59:10 +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 19FF12067DD for ; Thu, 19 Apr 2018 17:59:10 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w3JFx9Q3013705 for ; Thu, 19 Apr 2018 17:59:10 +0200 To: its@ietf.org References: <5F0CC237-5B49-477D-9FF2-D03840AC6D26@vigilsec.com> <7ea5c1eb-69fc-9262-e84b-5d830078aad5@gmail.com> From: Alexandre Petrescu Message-ID: Date: Thu, 19 Apr 2018 17:59:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <7ea5c1eb-69fc-9262-e84b-5d830078aad5@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] IPWAVE Recharter Topics? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 19 Apr 2018 15:59:24 -0000 For the XER-CAM/UDP/IP/Ethernet topic we have an interoperable implementation with a partner; that implementation couples to UPER-CAM/Geonet and soon will couple to XER-CAM/UDP/IP/LTE and potentially to XER-CAM/UDP/IP/OCB. We need to reserve a UDP port number for it, as now we just do it between 'consenting adults' 52000 decimal. Should we request it to IANA, or just continue between 'consenting adults' for the duration of the project trial prototype. Or maybe just wait a few months to have more confirmation. For those who wonder what is 'XER' it is an encoding rule specified by ITU, in a same family like 'UPER'. XER is like XML human readable and UPER is Unaligned Packed Encoding Rules which is more compressed. UPER is preferred by CAM but makes little sense to humans; worse - UPER-CAM is ambiguously specified from a purely formal standpoint. ITU and others would like one day to join JSON into these encoding rules, maybe as a XER derivative. We now have a recipe about how to make CAMs and DENMs for almost free (no money) that I could publish easily, although I will not publish code. That recipe relies entirely on the gratuituous open source software called asn1c, on freely accessible grammars from asn1-playground and marben websites. We tested on several platforms of different endianness (endianness is important for embedded and for UPER). We applied the recipe from one partner to another and it worked. A few things that still are in the way towards making cheap interoperable stack for ITS are: - various licensing conditions on geonet and a few other ITS-related ETSI messages still risk knocking at the door asking. - price tag of the SPAT grammar at SAE (in the order of hundred(s) dollars). Alex Le 19/04/2018 à 17:38, Alexandre Petrescu a écrit : > I think there are several things on the table: > > - QoS OCB-Ethernet, > - ND over OCB, > - XER-CAM/UDP/IP (instead of UPER-CAM/Geonet), > - RA prefix exchanges for V2V, > - 65-SLAAC (instead of 64-SLAAC), > - IPv6-over-802.11-NGV, > - IP Discovery of nearby vehicles, > - Security. > > There is also some comment in 6man that deserves consideration with > respect to ND. > > Le 18/04/2018 à 20:39, Russ Housley a écrit : >> I saw very little excitement for rechartering the IPWAVE WG.  There were >> a small number of people want to do something, but most people felt that >> other standards bodies should tackle non-IP topics. >> >> Are there any IP-related topics that need to be tackled?  If so, is >> there enough interest and energy among the IPWAVE WG participants to >> tackle them? >> >> Russ >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Thu Apr 19 09:22:05 2018 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 1A906126E64 for ; Thu, 19 Apr 2018 09:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 gwH-0c57PoO8 for ; Thu, 19 Apr 2018 09:22:02 -0700 (PDT) Received: from mail-pl0-x230.google.com (mail-pl0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (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 9C32F1200E5 for ; Thu, 19 Apr 2018 09:22:02 -0700 (PDT) Received: by mail-pl0-x230.google.com with SMTP id f7-v6so3544554plr.4 for ; Thu, 19 Apr 2018 09:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tYubAAmlAZAEpp0VLJvsPqRPqgXCIDnasKR70+Qxmwk=; b=CNdShxWZzqANtXxfjJpNEr4dctyl5ULAzSyaBqDZygAicH2y5HzBVcy4sxJorIMAnH YXCglI/5hcXjxC42oN8k22aHkuLD66wmwpmg38BpZY0FkdOmw4hUCxt2tHoQWjPvjcWK n04k3V6Fd5UkVWbCqYhp7sDgsEBikYkpj+IWCSBr45FWqrM7bmibt1q+6Iljnf1SnXtz 1ia6q6cDDoxru6OHcDtjL3QUbGal2TM+uUIzLHgTgx/lXzYeSJsN8jOWXRIKsQCWZw88 kv6d6n+6PW+vszZ39W9BlM9cCR+B0JrnzhgX/TkT2Boxrp2Sxn4S60yfjoA+fYCmTqxi 5fqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=tYubAAmlAZAEpp0VLJvsPqRPqgXCIDnasKR70+Qxmwk=; b=lXnfp9zQlqEP3OPCyZExglRq0Pa8ujlJib5Au+XNCKliI1vFr0/XHTA3VeviTy1G7v 4wAxPyQ7syPj1ayk1+Yt+cq1jwTlw58m9fLVzvRCbslAL7xT6hp5MCN7CFIob18+EAah b3TjMX2uR8atU5KYQ+DiGQEu+wpZHSw6CsvTh9+GZNTHe4wdg+J8TOguxxAj0EITFn5F 7PuTLQVMTwpx4XkK1vbmWiTREFPjfYFKYvv1Pg4/MgxJxAeETkvino+mxuIpY+tG8vCz vaHs+VVQ3NzfpWMhKdJuqoDKXFMrF2ycjhvI3x5YL4gD6ScopJ+Yns39uq0XYqASIVE6 4yhA== X-Gm-Message-State: ALQs6tC/h7EL/hPr2eQvUrF4w9ePxt+Zu6E00SPhgaJypS4i0a7rQ0fG OXUERLfUZZBl4Dgz5ANwrxI= X-Google-Smtp-Source: AIpwx4+cfX/iUa//a7W4RNna7nOIvIarQPWikTkGIOBBHWp/2I5lpBFdbQVBJR74ny3CS1s9l7Q/gw== X-Received: by 2002:a17:902:a717:: with SMTP id w23-v6mr6664986plq.342.1524154922249; Thu, 19 Apr 2018 09:22:02 -0700 (PDT) Received: from [10.95.90.29] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id e19sm6770388pff.169.2018.04.19.09.22.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 09:22:01 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: <24B9B2AA-F0E3-4D4C-874A-CC1F5CF1B694@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_98B0C9B5-E42B-4F3F-AB05-E99A4237E341" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 19 Apr 2018 09:22:00 -0700 In-Reply-To: Cc: its@ietf.org To: Alexandre Petrescu References: <5F0CC237-5B49-477D-9FF2-D03840AC6D26@vigilsec.com> <7ea5c1eb-69fc-9262-e84b-5d830078aad5@gmail.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [ipwave] IPWAVE Recharter Topics? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 19 Apr 2018 16:22:04 -0000 --Apple-Mail=_98B0C9B5-E42B-4F3F-AB05-E99A4237E341 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 19, 2018, at 8:59 AM, Alexandre Petrescu = wrote: >=20 > We need to reserve a UDP port number for it, as now we just do it = between 'consenting adults' 52000 decimal. >=20 > Should we request it to IANA, or just continue between 'consenting = adults' for the duration of the project trial prototype. Before you ask IANA for a UDP port number, you=E2=80=99ll need an = Internet draft that describes the protocol running on top of it. =46rom what you=E2=80=99ve said, this is unlikely to be in the Internet = area and more likely in Applications. Thus, a different WG... Tony --Apple-Mail=_98B0C9B5-E42B-4F3F-AB05-E99A4237E341 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 19, 2018, at 8:59 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

We need to reserve a UDP port = number for it, as now we just do it between 'consenting adults' 52000 = decimal.

Should we = request it to IANA, or just continue between 'consenting adults' for the = duration of the project trial = prototype.



Before you ask IANA for a UDP port number, you=E2=80=99ll = need an Internet draft that describes the protocol running on top of = it.

=46rom = what you=E2=80=99ve said, this is unlikely to be in the Internet area = and more likely in Applications.  Thus, a different WG...

Tony

= --Apple-Mail=_98B0C9B5-E42B-4F3F-AB05-E99A4237E341-- From nobody Thu Apr 19 10:09:07 2018 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 83252127522 for ; Thu, 19 Apr 2018 10:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham 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 gPWnFQ89RO4c for ; Thu, 19 Apr 2018 10:08:58 -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 A71FA1200C5 for ; Thu, 19 Apr 2018 10:08:57 -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 w3JH8rHs025408; Thu, 19 Apr 2018 19:08:53 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5299920682B; Thu, 19 Apr 2018 19:08:53 +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 454D8206815; Thu, 19 Apr 2018 19:08:53 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w3JH8qJc003628; Thu, 19 Apr 2018 19:08:52 +0200 To: dickroy@alum.mit.edu, its@ietf.org References: <5F0CC237-5B49-477D-9FF2-D03840AC6D26@vigilsec.com> <7ea5c1eb-69fc-9262-e84b-5d830078aad5@gmail.com> From: Alexandre Petrescu Message-ID: <38d17010-ae2d-bf3a-9188-898e220c6da6@gmail.com> Date: Thu, 19 Apr 2018 19:08:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] IPWAVE Recharter Topics? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 19 Apr 2018 17:09:00 -0000 :-) We're in Europe it must be GeoNetworking :-) Or I must redirect 1000 people to you :-) Alex Le 19/04/2018 à 18:45, Dick Roy a écrit : > The use of GeoNotworking or IP to send broadcast single-hop CAMs, DENMs, > BSMs, etc. is a total waste of resources. GeoNotworking is the absolute > worst possible choice, followed closely by IP. There is not a system > engineer worth his weight in salt that would specify such nonsense. Why are > you guys proposing to do something so ridiculous? > > RR > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Thursday, April 19, 2018 8:59 AM > To: its@ietf.org > Subject: Re: [ipwave] IPWAVE Recharter Topics? > > For the XER-CAM/UDP/IP/Ethernet topic we have an interoperable > implementation with a partner; that implementation couples to > UPER-CAM/Geonet and soon will couple to XER-CAM/UDP/IP/LTE and > potentially to XER-CAM/UDP/IP/OCB. > > We need to reserve a UDP port number for it, as now we just do it > between 'consenting adults' 52000 decimal. > > Should we request it to IANA, or just continue between 'consenting > adults' for the duration of the project trial prototype. > > Or maybe just wait a few months to have more confirmation. > > For those who wonder what is 'XER' it is an encoding rule specified by > ITU, in a same family like 'UPER'. XER is like XML human readable and > UPER is Unaligned Packed Encoding Rules which is more compressed. UPER > is preferred by CAM but makes little sense to humans; worse - UPER-CAM > is ambiguously specified from a purely formal standpoint. ITU and > others would like one day to join JSON into these encoding rules, maybe > as a XER derivative. > > We now have a recipe about how to make CAMs and DENMs for almost free > (no money) that I could publish easily, although I will not publish > code. That recipe relies entirely on the gratuituous open source > software called asn1c, on freely accessible grammars from > asn1-playground and marben websites. We tested on several platforms of > different endianness (endianness is important for embedded and for > UPER). We applied the recipe from one partner to another and it worked. > > A few things that still are in the way towards making cheap > interoperable stack for ITS are: > - various licensing conditions on geonet and a few other ITS-related > ETSI messages still risk knocking at the door asking. > - price tag of the SPAT grammar at SAE (in the order of hundred(s) > dollars). > > Alex > > Le 19/04/2018 à 17:38, Alexandre Petrescu a écrit : >> I think there are several things on the table: >> >> - QoS OCB-Ethernet, >> - ND over OCB, >> - XER-CAM/UDP/IP (instead of UPER-CAM/Geonet), >> - RA prefix exchanges for V2V, >> - 65-SLAAC (instead of 64-SLAAC), >> - IPv6-over-802.11-NGV, >> - IP Discovery of nearby vehicles, >> - Security. >> >> There is also some comment in 6man that deserves consideration with >> respect to ND. >> >> Le 18/04/2018 à 20:39, Russ Housley a écrit : >>> I saw very little excitement for rechartering the IPWAVE WG.  There were >>> a small number of people want to do something, but most people felt that >>> other standards bodies should tackle non-IP topics. >>> >>> Are there any IP-related topics that need to be tackled?  If so, is >>> there enough interest and energy among the IPWAVE WG participants to >>> tackle them? >>> >>> Russ >>> >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Thu Apr 19 10:09:34 2018 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 BBA79127522 for ; Thu, 19 Apr 2018 10:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham 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 N9rf_7dcKv2w for ; Thu, 19 Apr 2018 10:09:29 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 D62151200C5 for ; Thu, 19 Apr 2018 10:09:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w3JH9O4C079268; Thu, 19 Apr 2018 19:09:24 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D436220682B; Thu, 19 Apr 2018 19:09:24 +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 C6D7E203BBD; Thu, 19 Apr 2018 19:09:24 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w3JH9OAl003748; Thu, 19 Apr 2018 19:09:24 +0200 To: dickroy@alum.mit.edu, its@ietf.org References: <5F0CC237-5B49-477D-9FF2-D03840AC6D26@vigilsec.com> <7ea5c1eb-69fc-9262-e84b-5d830078aad5@gmail.com> <2DFD5FB26F4D4B818176F83EB4A3CE90@SRA6> From: Alexandre Petrescu Message-ID: <4fafade0-c786-fea4-a556-31d1b1842b55@gmail.com> Date: Thu, 19 Apr 2018 19:09:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <2DFD5FB26F4D4B818176F83EB4A3CE90@SRA6> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] IPWAVE Recharter Topics? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 19 Apr 2018 17:09:32 -0000 XER on 5G at 4Gbps yes XER on 802.11 NGV at 1GBps yes Le 19/04/2018 à 18:47, Dick Roy a écrit : > XER for broadcasting CAMs on a resource constrained channel??? Are you > seriously considering such a thing? > > RR > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Thursday, April 19, 2018 8:38 AM > To: its@ietf.org > Subject: Re: [ipwave] IPWAVE Recharter Topics? > > I think there are several things on the table: > > - QoS OCB-Ethernet, > - ND over OCB, > - XER-CAM/UDP/IP (instead of UPER-CAM/Geonet), > - RA prefix exchanges for V2V, > - 65-SLAAC (instead of 64-SLAAC), > - IPv6-over-802.11-NGV, > - IP Discovery of nearby vehicles, > - Security. > > There is also some comment in 6man that deserves consideration with > respect to ND. > > Le 18/04/2018 à 20:39, Russ Housley a écrit : >> I saw very little excitement for rechartering the IPWAVE WG. There were >> a small number of people want to do something, but most people felt that >> other standards bodies should tackle non-IP topics. >> >> Are there any IP-related topics that need to be tackled? If so, is >> there enough interest and energy among the IPWAVE WG participants to >> tackle them? >> >> Russ >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Thu Apr 19 10:10:23 2018 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 318EB12D871 for ; Thu, 19 Apr 2018 10:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham 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 G3si-Et1haOc for ; Thu, 19 Apr 2018 10:10:19 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 7910C1200C5 for ; Thu, 19 Apr 2018 10:10:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w3JHADSG079454; Thu, 19 Apr 2018 19:10:13 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 034F620682B; Thu, 19 Apr 2018 19:10:13 +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 E2A45203BBD; Thu, 19 Apr 2018 19:10:12 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w3JHACWK004006; Thu, 19 Apr 2018 19:10:12 +0200 To: dickroy@alum.mit.edu, its@ietf.org Cc: knut.evensen@q-free.com, thierry.ernst@yogoko.fr, hjfischer@fischer-tech.eu References: <5F0CC237-5B49-477D-9FF2-D03840AC6D26@vigilsec.com> <7ea5c1eb-69fc-9262-e84b-5d830078aad5@gmail.com> <322A422C36FB44A09322D670B1505779@SRA6> From: Alexandre Petrescu Message-ID: <85494ae2-94ab-c398-c4ba-0c3d2fdc2296@gmail.com> Date: Thu, 19 Apr 2018 19:10:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <322A422C36FB44A09322D670B1505779@SRA6> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] IPWAVE Recharter Topics? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 19 Apr 2018 17:10:22 -0000 Le 19/04/2018 à 18:59, Dick Roy a écrit : > Alex et. al., > > The only thing SAE charges for is the document, not the code. You can code > the SPaT message yourself for free assuming you have the ASN.1 for the > message. The ASN.1 grammar of SPAT is not available elsewhere than on that SAE paywall. Alex > > As for GeoNotworking and the patents thereon, ABSOLUTELY DO NOT use that > networking protocol ... EVER ... for anything. It is useless and > encumbered. Instead, work to get any mention of that dysfunctional protocol > removed from ALL your RFCs, and more importantly, from every mandate issued > by the EC! Anyone who thinks paying royalties for something that simply > does not work and NEVER WILL has serious problems. Allowing the companies > that foisted this travesty on the ITS community to get away with this > blatant abuse of the standards process is nothing sort of complicity! > > Cheers, > > RR > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Thursday, April 19, 2018 8:59 AM > To: its@ietf.org > Subject: Re: [ipwave] IPWAVE Recharter Topics? > > For the XER-CAM/UDP/IP/Ethernet topic we have an interoperable > implementation with a partner; that implementation couples to > UPER-CAM/Geonet and soon will couple to XER-CAM/UDP/IP/LTE and > potentially to XER-CAM/UDP/IP/OCB. > > We need to reserve a UDP port number for it, as now we just do it > between 'consenting adults' 52000 decimal. > > Should we request it to IANA, or just continue between 'consenting > adults' for the duration of the project trial prototype. > > Or maybe just wait a few months to have more confirmation. > > For those who wonder what is 'XER' it is an encoding rule specified by > ITU, in a same family like 'UPER'. XER is like XML human readable and > UPER is Unaligned Packed Encoding Rules which is more compressed. UPER > is preferred by CAM but makes little sense to humans; worse - UPER-CAM > is ambiguously specified from a purely formal standpoint. ITU and > others would like one day to join JSON into these encoding rules, maybe > as a XER derivative. > > We now have a recipe about how to make CAMs and DENMs for almost free > (no money) that I could publish easily, although I will not publish > code. That recipe relies entirely on the gratuituous open source > software called asn1c, on freely accessible grammars from > asn1-playground and marben websites. We tested on several platforms of > different endianness (endianness is important for embedded and for > UPER). We applied the recipe from one partner to another and it worked. > > A few things that still are in the way towards making cheap > interoperable stack for ITS are: > - various licensing conditions on geonet and a few other ITS-related > ETSI messages still risk knocking at the door asking. > - price tag of the SPAT grammar at SAE (in the order of hundred(s) > dollars). > > Alex > > Le 19/04/2018 à 17:38, Alexandre Petrescu a écrit : >> I think there are several things on the table: >> >> - QoS OCB-Ethernet, >> - ND over OCB, >> - XER-CAM/UDP/IP (instead of UPER-CAM/Geonet), >> - RA prefix exchanges for V2V, >> - 65-SLAAC (instead of 64-SLAAC), >> - IPv6-over-802.11-NGV, >> - IP Discovery of nearby vehicles, >> - Security. >> >> There is also some comment in 6man that deserves consideration with >> respect to ND. >> >> Le 18/04/2018 à 20:39, Russ Housley a écrit : >>> I saw very little excitement for rechartering the IPWAVE WG.  There were >>> a small number of people want to do something, but most people felt that >>> other standards bodies should tackle non-IP topics. >>> >>> Are there any IP-related topics that need to be tackled?  If so, is >>> there enough interest and energy among the IPWAVE WG participants to >>> tackle them? >>> >>> Russ >>> >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Fri Apr 20 00:53:37 2018 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 7B787126CB6 for ; Fri, 20 Apr 2018 00:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham 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 78fDbYpVXOpX for ; Fri, 20 Apr 2018 00:53:33 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 983561204DA for ; Fri, 20 Apr 2018 00:53:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w3K7rVqi021476 for ; Fri, 20 Apr 2018 09:53:31 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CF7DE201016 for ; Fri, 20 Apr 2018 09:53:31 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C4CDD2007F3 for ; Fri, 20 Apr 2018 09:53:31 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w3K7rVdE015150 for ; Fri, 20 Apr 2018 09:53:31 +0200 To: its@ietf.org References: <5F0CC237-5B49-477D-9FF2-D03840AC6D26@vigilsec.com> <7ea5c1eb-69fc-9262-e84b-5d830078aad5@gmail.com> <38d17010-ae2d-bf3a-9188-898e220c6da6@gmail.com> From: Alexandre Petrescu Message-ID: Date: Fri, 20 Apr 2018 09:53:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <38d17010-ae2d-bf3a-9188-898e220c6da6@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] IPWAVE Recharter Topics? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 20 Apr 2018 07:53:36 -0000 Dick, I tend to agree that the use of GeoNotWorking to send broadcast single-hop CAMs, DENMs is a waste of resources. In particular, it has the overhead of sending two times the position value (once in the GeoNotWorking header and once in the CAM payload - both are mandatory). The licensing risk is that whoever implements the GeoNotWorking header risks a few companies to knock at their door to ask for rights, be they 'reasonable'. On another hand, the GeoNotWorking is such a mandatory protocol in Europe at ETSI and, consequently by the uniformisation process at each country level. So many people implement it - be it functional or just pretending to function. This is what I meant by the '1000 person' metaphor. Given this situation, we locally have decided to also implement the GeoNotWorking header. But we set the values in this header to 0. This is non-functional too, just like GeoNotWorking is. The receivers of these CAM/GeoNotWorking that we send dont complain and are happy. The receivers care a lot about what is in the CAM payload. We also implement IPv6-over-OCB without the GeoNotWorking header and that is useful for connecting the car to the Internet. Alex Le 19/04/2018 à 19:08, Alexandre Petrescu a écrit : [...] > > Le 19/04/2018 à 18:45, Dick Roy a écrit : >> The use of GeoNotworking or IP to send broadcast single-hop CAMs, DENMs, >> BSMs, etc. is a total waste of resources.  GeoNotworking is the absolute >> worst possible choice, followed closely by IP.  There is not a system >> engineer worth his weight in salt that would specify such nonsense. >> Why are >> you guys proposing to do something so ridiculous? >> >> RR >> >> -----Original Message----- >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu >> Sent: Thursday, April 19, 2018 8:59 AM >> To: its@ietf.org >> Subject: Re: [ipwave] IPWAVE Recharter Topics? >> >> For the XER-CAM/UDP/IP/Ethernet topic we have an interoperable >> implementation with a partner; that implementation couples to >> UPER-CAM/Geonet and soon will couple to XER-CAM/UDP/IP/LTE and >> potentially to XER-CAM/UDP/IP/OCB. >> >> We need to reserve a UDP port number for it, as now we just do it >> between 'consenting adults' 52000 decimal. >> >> Should we request it to IANA, or just continue between 'consenting >> adults' for the duration of the project trial prototype. >> >> Or maybe just wait a few months to have more confirmation. >> >> For those who wonder what is 'XER' it is an encoding rule specified by >> ITU, in a same family like 'UPER'.  XER is like XML human readable and >> UPER is Unaligned Packed Encoding Rules which is more compressed.  UPER >> is preferred by CAM but makes little sense to humans; worse - UPER-CAM >> is ambiguously specified from a purely formal standpoint.  ITU and >> others would like one day to join JSON into these encoding rules, maybe >> as a XER derivative. >> >> We now have a recipe about how to make CAMs and DENMs for almost free >> (no money) that I could publish easily, although I will not publish >> code.  That recipe relies entirely on the gratuituous open source >> software called asn1c, on freely accessible grammars from >> asn1-playground and marben websites.  We tested on several platforms of >> different endianness (endianness is important for embedded and for >> UPER).  We applied the recipe from one partner to another and it worked. >> >> A few things that still are in the way towards making cheap >> interoperable stack for ITS are: >> - various licensing conditions on geonet and a few other ITS-related >>     ETSI messages still risk knocking at the door asking. >> - price tag of the SPAT grammar at SAE (in the order of hundred(s) >>     dollars). >> >> Alex >> >> Le 19/04/2018 à 17:38, Alexandre Petrescu a écrit : >>> I think there are several things on the table: >>> >>> - QoS OCB-Ethernet, >>> - ND over OCB, >>> - XER-CAM/UDP/IP (instead of UPER-CAM/Geonet), >>> - RA prefix exchanges for V2V, >>> - 65-SLAAC (instead of 64-SLAAC), >>> - IPv6-over-802.11-NGV, >>> - IP Discovery of nearby vehicles, >>> - Security. >>> >>> There is also some comment in 6man that deserves consideration with >>> respect to ND. >>> >>> Le 18/04/2018 à 20:39, Russ Housley a écrit : >>>> I saw very little excitement for rechartering the IPWAVE WG.  There >>>> were >>>> a small number of people want to do something, but most people felt >>>> that >>>> other standards bodies should tackle non-IP topics. >>>> >>>> Are there any IP-related topics that need to be tackled?  If so, is >>>> there enough interest and energy among the IPWAVE WG participants to >>>> tackle them? >>>> >>>> Russ >>>> >>>> _______________________________________________ >>>> its mailing list >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>>> >>> >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Fri Apr 20 01:03:03 2018 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 ADEF812704A for ; Fri, 20 Apr 2018 01:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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_LOW=-0.7, T_HK_NAME_DR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fischer-tech.eu 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 Ttn1RdL3tU2a for ; Fri, 20 Apr 2018 01:02:55 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::10]) (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 2834D1204DA for ; Fri, 20 Apr 2018 01:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1524211372; s=strato-dkim-0002; d=fischer-tech.eu; h=Content-Type:In-Reply-To:Date:Message-ID:From:References:To:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=mDl6mrMjbEF4vG51tVwZWrphQ22ckBjFnaVrxEQGuwg=; b=bUaJtjgQ+5g4J1LphT9QDcTmgDD4c+s2enmmjsY6fbs6w1LHqek5b+giqCKrc6r3+K 8gtZJ95xqBKjy/gNR6u/43ct0K10w5FwNb3xHav6RoYspV4M+WplnWbPVjvCw7JwWK6a 7TRneEvhBrdPA+5nXqTrk5wkYkqm1r453a69tlLUNvBkRmABqmkaUaJm6hhzXwnUvqOL iCqLYNj+kWpDHUY1A2C6EH8tJez6ttlDkZoAziu1EQKXfpb5iizViPI5B5y6zEBtdktu RHJccXbuHJoJPVRMw5U+DWg9jk3EGW71c2TtMI6nJkOnD/NGT+LJKFQ9QF2SdftcE80y 0pNA== X-RZG-AUTH: :JGYCfFOrc/o0m7eTcArWz0wjmOawaLakL8gsnQVmzXBs/kysHP8WeUE0sQcvY8PAWSJdtjsmGi0ld1/vHArOnzfEFcdH/5ev5QT9AHv0lXWp/Q== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2003:a:1511:b400:4085:51fd:4cc4:dfcb] by smtp.strato.de (RZmta 43.2 AUTH) with ESMTPSA id I00ce2u3K82pbo7 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Fri, 20 Apr 2018 10:02:51 +0200 (CEST) To: its@ietf.org References: <5F0CC237-5B49-477D-9FF2-D03840AC6D26@vigilsec.com> <7ea5c1eb-69fc-9262-e84b-5d830078aad5@gmail.com> <38d17010-ae2d-bf3a-9188-898e220c6da6@gmail.com> From: "Dr. Hans-Joachim Fischer" Organization: ESF GmbH Message-ID: <83b89418-d4c8-1f61-a027-acc71f934185@fischer-tech.eu> Date: Fri, 20 Apr 2018 10:02:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A25D0FE448834447B38B9F20" Archived-At: Subject: Re: [ipwave] IPWAVE Recharter Topics? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 20 Apr 2018 08:03:02 -0000 This is a multi-part message in MIME format. --------------A25D0FE448834447B38B9F20 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Well, everybody understands the problem with GeoNetworking. GN was a nice scientific exercise, but it failed in the very narrow channels at 5,9 GHz. There is an easy migration possibel from GN to both WSMP (IEEE 1609.3) and FNTP (ISO 29281-1:2018). WSMP and FNTP are efficiently structured, using the same message format, and thus are interoperable. Remote SW update in ITS stations can do the job. Some hints on remote station management are given in ISO 24102-2:2018. My two cents. Hans-Joachim Am 20.04.2018 um 09:53 schrieb Alexandre Petrescu: > Dick, > > I tend to agree that the use of GeoNotWorking to send broadcast > single-hop CAMs, DENMs is a waste of resources.  In particular, it has > the overhead of sending two times the position value (once in the > GeoNotWorking header and once in the CAM payload - both are mandatory). > > The licensing risk is that whoever implements the GeoNotWorking header > risks a few companies to knock at their door to ask for rights, be > they 'reasonable'. > > On another hand, the GeoNotWorking is such a mandatory protocol in > Europe at ETSI and, consequently by the uniformisation process at each > country level.  So many people implement it - be it functional or just > pretending to function.  This is what I meant by the '1000 person' > metaphor. > > Given this situation, we locally have decided to also implement the > GeoNotWorking header.  But we set the values in this header to 0.  > This is non-functional too, just like GeoNotWorking is.  The receivers > of these CAM/GeoNotWorking that we send dont complain and are happy.  > The receivers care a lot about what is in the CAM payload. > > We also implement IPv6-over-OCB without the GeoNotWorking header and > that is useful for connecting the car to the Internet. > > Alex > > > Le 19/04/2018 à 19:08, Alexandre Petrescu a écrit : > [...] >> >> Le 19/04/2018 à 18:45, Dick Roy a écrit : >>> The use of GeoNotworking or IP to send broadcast single-hop CAMs, >>> DENMs, >>> BSMs, etc. is a total waste of resources.  GeoNotworking is the >>> absolute >>> worst possible choice, followed closely by IP.  There is not a system >>> engineer worth his weight in salt that would specify such nonsense.  >>> Why are >>> you guys proposing to do something so ridiculous? >>> >>> RR >>> >>> -----Original Message----- >>> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu >>> Sent: Thursday, April 19, 2018 8:59 AM >>> To: its@ietf.org >>> Subject: Re: [ipwave] IPWAVE Recharter Topics? >>> >>> For the XER-CAM/UDP/IP/Ethernet topic we have an interoperable >>> implementation with a partner; that implementation couples to >>> UPER-CAM/Geonet and soon will couple to XER-CAM/UDP/IP/LTE and >>> potentially to XER-CAM/UDP/IP/OCB. >>> >>> We need to reserve a UDP port number for it, as now we just do it >>> between 'consenting adults' 52000 decimal. >>> >>> Should we request it to IANA, or just continue between 'consenting >>> adults' for the duration of the project trial prototype. >>> >>> Or maybe just wait a few months to have more confirmation. >>> >>> For those who wonder what is 'XER' it is an encoding rule specified by >>> ITU, in a same family like 'UPER'.  XER is like XML human readable and >>> UPER is Unaligned Packed Encoding Rules which is more compressed.  UPER >>> is preferred by CAM but makes little sense to humans; worse - UPER-CAM >>> is ambiguously specified from a purely formal standpoint.  ITU and >>> others would like one day to join JSON into these encoding rules, maybe >>> as a XER derivative. >>> >>> We now have a recipe about how to make CAMs and DENMs for almost free >>> (no money) that I could publish easily, although I will not publish >>> code.  That recipe relies entirely on the gratuituous open source >>> software called asn1c, on freely accessible grammars from >>> asn1-playground and marben websites.  We tested on several platforms of >>> different endianness (endianness is important for embedded and for >>> UPER).  We applied the recipe from one partner to another and it >>> worked. >>> >>> A few things that still are in the way towards making cheap >>> interoperable stack for ITS are: >>> - various licensing conditions on geonet and a few other ITS-related >>>     ETSI messages still risk knocking at the door asking. >>> - price tag of the SPAT grammar at SAE (in the order of hundred(s) >>>     dollars). >>> >>> Alex >>> >>> Le 19/04/2018 à 17:38, Alexandre Petrescu a écrit : >>>> I think there are several things on the table: >>>> >>>> - QoS OCB-Ethernet, >>>> - ND over OCB, >>>> - XER-CAM/UDP/IP (instead of UPER-CAM/Geonet), >>>> - RA prefix exchanges for V2V, >>>> - 65-SLAAC (instead of 64-SLAAC), >>>> - IPv6-over-802.11-NGV, >>>> - IP Discovery of nearby vehicles, >>>> - Security. >>>> >>>> There is also some comment in 6man that deserves consideration with >>>> respect to ND. >>>> >>>> Le 18/04/2018 à 20:39, Russ Housley a écrit : >>>>> I saw very little excitement for rechartering the IPWAVE WG.  >>>>> There were >>>>> a small number of people want to do something, but most people >>>>> felt that >>>>> other standards bodies should tackle non-IP topics. >>>>> >>>>> Are there any IP-related topics that need to be tackled? If so, is >>>>> there enough interest and energy among the IPWAVE WG participants to >>>>> tackle them? >>>>> >>>>> Russ >>>>> >>>>> _______________________________________________ >>>>> its mailing list >>>>> its@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/its >>>>> >>>> >>>> _______________________________________________ >>>> its mailing list >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>> >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>> >>> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its -- Dr. Hans-Joachim Fischer Managing Director -------------------------------------------------------------------------------- ESF News edition 2018/1 https://fischer-tech.eu/Feeds/News/ESF-News-2018-01.pdf -------------------------------------------------------------------------------- Towards deployment of C-ITS based on proven technology Avoid risks and delay by looking on potential future technologies. The real advocate on ITS is ISO TC204! -------------------------------------------------------------------------------- + + + Instaurare omnia in Christo + + + -------------------------------------------------------------------------------- The information contained in this message is confidential and may be legally privileged. This email is intended for the addressee(s). Addressees may be individual persons or members of mailing list. If you are not an addressee, you are hereby notified that any use, dissemination, or reproduction of this email and its optional attachements is strictly prohibited and may be unlawful. If you are not an addressee, please contact the sender by return e-mail and destroy all copies of the original message. -------------------------------------------------------------------------------- ESF GmbH Fichtenweg 9 89143 Blaubeuren +49 (7344) 175340 (Direct line Dr. Fischer) +49 (7344) 919188 (Central office) +49 (7344) 919123 (Fax) https://fischer-tech.eu : Main web of ESF GmbH http://its-standards.eu : News on cooperative ITS standardization http://its-testing.org : International consultancy for cooperative ITS -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- ESF online-news: http://fischer-tech.eu/Feeds/esf.rss C-ITS online news: http://its-standards.info/Feeds/cits.rss ESF Online Nachrichten: http://fischer-tech.de/Feeds/esfD.rss ------------------------------------------------------------------------------- --------------A25D0FE448834447B38B9F20 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


Well, everybody understands the problem with GeoNetworking. GN was a nice scientific exercise, but it failed in the very narrow channels at 5,9 GHz. There is an easy migration possibel from GN to both WSMP (IEEE 1609.3) and FNTP (ISO 29281-1:2018). WSMP and FNTP are efficiently structured, using the same message format, and thus are interoperable.

Remote SW update in ITS stations can do the job. Some hints on remote station management are given in ISO 24102-2:2018.


My two cents.
Hans-Joachim


Am 20.04.2018 um 09:53 schrieb Alexandre Petrescu:
Dick,

I tend to agree that the use of GeoNotWorking to send broadcast single-hop CAMs, DENMs is a waste of resources.  In particular, it has the overhead of sending two times the position value (once in the GeoNotWorking header and once in the CAM payload - both are mandatory).

The licensing risk is that whoever implements the GeoNotWorking header risks a few companies to knock at their door to ask for rights, be they 'reasonable'.

On another hand, the GeoNotWorking is such a mandatory protocol in Europe at ETSI and, consequently by the uniformisation process at each country level.  So many people implement it - be it functional or just pretending to function.  This is what I meant by the '1000 person' metaphor.

Given this situation, we locally have decided to also implement the GeoNotWorking header.  But we set the values in this header to 0.  This is non-functional too, just like GeoNotWorking is.  The receivers of these CAM/GeoNotWorking that we send dont complain and are happy.  The receivers care a lot about what is in the CAM payload.

We also implement IPv6-over-OCB without the GeoNotWorking header and that is useful for connecting the car to the Internet.

Alex


Le 19/04/2018 à 19:08, Alexandre Petrescu a écrit :
[...]

Le 19/04/2018 à 18:45, Dick Roy a écrit :
The use of GeoNotworking or IP to send broadcast single-hop CAMs, DENMs,
BSMs, etc. is a total waste of resources.  GeoNotworking is the absolute
worst possible choice, followed closely by IP.  There is not a system
engineer worth his weight in salt that would specify such nonsense.  Why are
you guys proposing to do something so ridiculous?

RR

-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu
Sent: Thursday, April 19, 2018 8:59 AM
To: its@ietf.org
Subject: Re: [ipwave] IPWAVE Recharter Topics?

For the XER-CAM/UDP/IP/Ethernet topic we have an interoperable
implementation with a partner; that implementation couples to
UPER-CAM/Geonet and soon will couple to XER-CAM/UDP/IP/LTE and
potentially to XER-CAM/UDP/IP/OCB.

We need to reserve a UDP port number for it, as now we just do it
between 'consenting adults' 52000 decimal.

Should we request it to IANA, or just continue between 'consenting
adults' for the duration of the project trial prototype.

Or maybe just wait a few months to have more confirmation.

For those who wonder what is 'XER' it is an encoding rule specified by
ITU, in a same family like 'UPER'.  XER is like XML human readable and
UPER is Unaligned Packed Encoding Rules which is more compressed.  UPER
is preferred by CAM but makes little sense to humans; worse - UPER-CAM
is ambiguously specified from a purely formal standpoint.  ITU and
others would like one day to join JSON into these encoding rules, maybe
as a XER derivative.

We now have a recipe about how to make CAMs and DENMs for almost free
(no money) that I could publish easily, although I will not publish
code.  That recipe relies entirely on the gratuituous open source
software called asn1c, on freely accessible grammars from
asn1-playground and marben websites.  We tested on several platforms of
different endianness (endianness is important for embedded and for
UPER).  We applied the recipe from one partner to another and it worked.

A few things that still are in the way towards making cheap
interoperable stack for ITS are:
- various licensing conditions on geonet and a few other ITS-related
    ETSI messages still risk knocking at the door asking.
- price tag of the SPAT grammar at SAE (in the order of hundred(s)
    dollars).

Alex

Le 19/04/2018 à 17:38, Alexandre Petrescu a écrit :
I think there are several things on the table:

- QoS OCB-Ethernet,
- ND over OCB,
- XER-CAM/UDP/IP (instead of UPER-CAM/Geonet),
- RA prefix exchanges for V2V,
- 65-SLAAC (instead of 64-SLAAC),
- IPv6-over-802.11-NGV,
- IP Discovery of nearby vehicles,
- Security.

There is also some comment in 6man that deserves consideration with
respect to ND.

Le 18/04/2018 à 20:39, Russ Housley a écrit :
I saw very little excitement for rechartering the IPWAVE WG.  There were
a small number of people want to do something, but most people felt that
other standards bodies should tackle non-IP topics.

Are there any IP-related topics that need to be tackled?  If so, is
there enough interest and energy among the IPWAVE WG participants to
tackle them?

Russ

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


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

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



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

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

-- 
Dr. Hans-Joachim Fischer
Managing Director

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

               ESF News edition 2018/1
https://fischer-tech.eu/Feeds/News/ESF-News-2018-01.pdf

-------------------------------------------------------------------------------- 
      Towards deployment of C-ITS based on proven technology
Avoid risks and delay by looking on potential future technologies.

               The real advocate on ITS is ISO TC204!
-------------------------------------------------------------------------------- 
+ + + Instaurare omnia in Christo + + +
-------------------------------------------------------------------------------- 
The information contained in this message is confidential and may be legally 
privileged. This email is intended for the addressee(s). Addressees may be 
individual persons or members of mailing list. 
If you are not an addressee, you are hereby notified that any use, 
dissemination, or reproduction of this email and its optional attachements is 
strictly prohibited and may be unlawful. If you are not an addressee, please 
contact the sender by return e-mail and destroy all copies of the original 
message. 
-------------------------------------------------------------------------------- 
ESF GmbH
Fichtenweg 9
89143 Blaubeuren
+49 (7344) 175340 (Direct line Dr. Fischer)
+49 (7344) 919188 (Central office)
+49 (7344) 919123 (Fax)
https://fischer-tech.eu :  Main web of ESF GmbH
http://its-standards.eu : News on cooperative ITS standardization
http://its-testing.org :  International consultancy for cooperative ITS
-------------------------------------------------------------------------------- 

-------------------------------------------------------------------------------- 
ESF online-news:        http://fischer-tech.eu/Feeds/esf.rss
C-ITS online news:      http://its-standards.info/Feeds/cits.rss
ESF Online Nachrichten: http://fischer-tech.de/Feeds/esfD.rss
-------------------------------------------------------------------------------
--------------A25D0FE448834447B38B9F20-- From nobody Fri Apr 20 01:17:48 2018 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 2A5CA127010 for ; Fri, 20 Apr 2018 01:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham 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 xS1trT1rmgO7 for ; Fri, 20 Apr 2018 01:17:44 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 7DBFA1204DA for ; Fri, 20 Apr 2018 01:17:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w3K8HMXT035679; Fri, 20 Apr 2018 10:17:22 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 16FE4203C62; Fri, 20 Apr 2018 10:17:22 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0222D201994; Fri, 20 Apr 2018 10:17:22 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w3K8HLde031897; Fri, 20 Apr 2018 10:17:21 +0200 To: dickroy@alum.mit.edu Cc: its@ietf.org, knut.evensen@q-free.com, thierry.ernst@yogoko.fr, hjfischer@fischer-tech.eu References: <5F0CC237-5B49-477D-9FF2-D03840AC6D26@vigilsec.com> <7ea5c1eb-69fc-9262-e84b-5d830078aad5@gmail.com> <322A422C36FB44A09322D670B1505779@SRA6> From: Alexandre Petrescu Message-ID: <7bf701dc-3b8e-8221-17a7-4b3fac418397@gmail.com> Date: Fri, 20 Apr 2018 10:17:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <322A422C36FB44A09322D670B1505779@SRA6> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] IPWAVE Recharter Topics? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 20 Apr 2018 08:17:47 -0000 Dick, Let me detail a bit about this. Le 19/04/2018 à 18:59, Dick Roy a écrit : > Alex et. al., > > The only thing SAE charges for is the document, not the code. You > can code the SPaT message yourself for free assuming you have the > ASN.1 for the message. The document that SAE charges for is a grammar (ASN.1). That grammar feeds the reader called asn1c, an open-source freely available tool. That asn1c generates the C code; this code has no license. That C code is further compiled to generate an executable that will create a SPAT message according to the grammar. Without the grammar it is impossible to generate a SPAT. Sure, it could be possible for a human to read the SPAT spec and write the ASN.1 grammar. I believe the SPAT spec is another document that the SPAT grammar, more human readable and commented hopefully with jokes. I believe that SPAT spec is also paying. However, a human to read the non-grammar SPAT specification is a complex operation that takes time. Because the SPAT message format is not as simple as CAM. The SPAT message format is complicated because it wants to express the complicated situation which is an intersection. The urban intersections I deal with may have up to 20 traffic lights for one controller. So a programmer must not only understand the intersection but understand the SPAT specification too. It's absurd to even try. It's like if programmer needed to understand Assembler in order to program in Java. There is an additional detail : SPAT is a US format used in America, whereas Europe rather says 'SPAT-EM' which is a SPAT encapsulated with a specific ETSI ITS header (which is itself weakly specified with respect to time representation). The SPAT-EM ASN.1 grammar is freely accessible but it is useless without the SPAT ASN.1 grammar (it says "IMPORT SPAT"). Last but not least: the traffic lights in the country where I live do have the ability to program the intersection, represent its state, and so on. However, that uses a country-specific protocol which is called 'DIASER'. Originally DIASER was for RS-232 lines, but recently one can send DIASER messages over IP, and presumably over IPv6. This 'DIASER' is not related at all to 'SPAT' yet they do the same thing. Worse, just like SPAT, the DIASER spec is paying, and more expensive than the SPAT. I can guess that Germany has its equivalent for DIASER that may be called something else. In this situation, I dont understand why not using any other than SPAT format to do the intersection management. Or maybe if SPAT wants to succeed over DIASER then make the SPAT spec open and put it over IP. Alex > > As for GeoNotworking and the patents thereon, ABSOLUTELY DO NOT use > that networking protocol ... EVER ... for anything. It is useless > and encumbered. Instead, work to get any mention of that > dysfunctional protocol removed from ALL your RFCs, and more > importantly, from every mandate issued by the EC! Anyone who thinks > paying royalties for something that simply does not work and NEVER > WILL has serious problems. Allowing the companies that foisted this > travesty on the ITS community to get away with this blatant abuse of > the standards process is nothing sort of complicity! > > Cheers, > > RR > > -----Original Message----- From: its [mailto:its-bounces@ietf.org] > On Behalf Of Alexandre Petrescu Sent: Thursday, April 19, 2018 8:59 > AM To: its@ietf.org Subject: Re: [ipwave] IPWAVE Recharter Topics? > > For the XER-CAM/UDP/IP/Ethernet topic we have an interoperable > implementation with a partner; that implementation couples to > UPER-CAM/Geonet and soon will couple to XER-CAM/UDP/IP/LTE and > potentially to XER-CAM/UDP/IP/OCB. > > We need to reserve a UDP port number for it, as now we just do it > between 'consenting adults' 52000 decimal. > > Should we request it to IANA, or just continue between 'consenting > adults' for the duration of the project trial prototype. > > Or maybe just wait a few months to have more confirmation. > > For those who wonder what is 'XER' it is an encoding rule specified > by ITU, in a same family like 'UPER'. XER is like XML human > readable and UPER is Unaligned Packed Encoding Rules which is more > compressed. UPER is preferred by CAM but makes little sense to > humans; worse - UPER-CAM is ambiguously specified from a purely > formal standpoint. ITU and others would like one day to join JSON > into these encoding rules, maybe as a XER derivative. > > We now have a recipe about how to make CAMs and DENMs for almost free > (no money) that I could publish easily, although I will not publish > code. That recipe relies entirely on the gratuituous open source > software called asn1c, on freely accessible grammars from > asn1-playground and marben websites. We tested on several platforms > of different endianness (endianness is important for embedded and for > UPER). We applied the recipe from one partner to another and it > worked. > > A few things that still are in the way towards making cheap > interoperable stack for ITS are: - various licensing conditions on > geonet and a few other ITS-related ETSI messages still risk knocking > at the door asking. - price tag of the SPAT grammar at SAE (in the > order of hundred(s) dollars). > > Alex > > Le 19/04/2018 à 17:38, Alexandre Petrescu a écrit : >> I think there are several things on the table: >> >> - QoS OCB-Ethernet, - ND over OCB, - XER-CAM/UDP/IP (instead of >> UPER-CAM/Geonet), - RA prefix exchanges for V2V, - 65-SLAAC >> (instead of 64-SLAAC), - IPv6-over-802.11-NGV, - IP Discovery of >> nearby vehicles, - Security. >> >> There is also some comment in 6man that deserves consideration with >> respect to ND. >> >> Le 18/04/2018 à 20:39, Russ Housley a écrit : >>> I saw very little excitement for rechartering the IPWAVE WG. >>> There were a small number of people want to do something, but >>> most people felt that other standards bodies should tackle >>> non-IP topics. >>> >>> Are there any IP-related topics that need to be tackled? If so, >>> is there enough interest and energy among the IPWAVE WG >>> participants to tackle them? >>> >>> Russ >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From nobody Fri Apr 20 04:22:38 2018 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 EFE3B1270AE for ; Fri, 20 Apr 2018 04:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham 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 6Da1xWPD6mfA for ; Fri, 20 Apr 2018 04:22:34 -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 009FF1241F8 for ; Fri, 20 Apr 2018 04:22:33 -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 w3KBMUqA017135 for ; Fri, 20 Apr 2018 13:22:31 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E67FC203F12 for ; Fri, 20 Apr 2018 13:22:30 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DD1D6203EF2 for ; Fri, 20 Apr 2018 13:22:30 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w3KBMUQE029834 for ; Fri, 20 Apr 2018 13:22:30 +0200 To: its@ietf.org References: <5F0CC237-5B49-477D-9FF2-D03840AC6D26@vigilsec.com> <7ea5c1eb-69fc-9262-e84b-5d830078aad5@gmail.com> <322A422C36FB44A09322D670B1505779@SRA6> <7bf701dc-3b8e-8221-17a7-4b3fac418397@gmail.com> From: Alexandre Petrescu Message-ID: <52491e5a-c133-75ff-7e80-2408b665053b@gmail.com> Date: Fri, 20 Apr 2018 13:22:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <7bf701dc-3b8e-8221-17a7-4b3fac418397@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] IPWAVE Recharter Topics? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 20 Apr 2018 11:22:37 -0000 I stand corrected: it is the 'MAP' message that describes the intersection, not SPAT. Alex Le 20/04/2018 à 10:17, Alexandre Petrescu a écrit : > Dick, > > Let me detail a bit about this. > > Le 19/04/2018 à 18:59, Dick Roy a écrit : >> Alex et. al., >> >> The only thing SAE charges for is the document, not the code.  You can >> code the SPaT message yourself for free assuming you have the ASN.1 >> for the message. > > The document that SAE charges for is a grammar (ASN.1).  That grammar > feeds the reader called asn1c, an open-source freely available tool. > That asn1c generates the C code; this code has no license.  That C code > is further compiled to generate an executable that will create a SPAT > message according to the grammar. > > Without the grammar it is impossible to generate a SPAT. > > Sure, it could be possible for a human to read the SPAT spec and write > the ASN.1 grammar.  I believe the SPAT spec is another document that the > SPAT grammar, more human readable and commented hopefully with jokes.  I > believe that SPAT spec is also paying. > > However, a human to read the non-grammar SPAT specification is a complex > operation that takes time.  Because the SPAT message format is not as > simple as CAM.  The SPAT message format is complicated because it wants > to express the complicated situation which is an intersection.  The > urban intersections I deal with may have up to 20 traffic lights for one > controller. > > So a programmer must not only understand the intersection but understand > the SPAT specification too.  It's absurd to even try.  It's like if > programmer needed to understand Assembler in order to program in Java. > > There is an additional detail : SPAT is a US format used in America, > whereas Europe rather says 'SPAT-EM' which is a SPAT encapsulated with a > specific ETSI ITS header (which is itself weakly specified with respect > to time representation).  The SPAT-EM ASN.1 grammar is freely accessible > but it is useless without the SPAT ASN.1 grammar (it says "IMPORT SPAT"). > > Last but not least: the traffic lights in the country where I live do > have the ability to program the intersection, represent its state, and > so on.  However, that uses a country-specific protocol which is called > 'DIASER'.  Originally DIASER was for RS-232 lines, but recently one can > send DIASER messages over IP, and presumably over IPv6.  This 'DIASER' > is not related at all to 'SPAT' yet they do the same thing.  Worse, just > like SPAT, the DIASER spec is paying, and more expensive than the SPAT. > > I can guess that Germany has its equivalent for DIASER that may be > called something else. > > In this situation, I dont understand why not using any other than SPAT > format to do the intersection management.  Or maybe if SPAT wants to > succeed over DIASER then make the SPAT spec open and put it over IP. > > Alex > > > >> >> As for GeoNotworking and the patents thereon, ABSOLUTELY DO NOT use >> that networking protocol ... EVER ... for anything.  It is useless and >> encumbered.  Instead, work to get any mention of that dysfunctional >> protocol removed from ALL your RFCs, and more importantly, from every >> mandate issued by the EC!  Anyone who thinks paying royalties for >> something that simply does not work and NEVER WILL has serious >> problems.  Allowing the companies that foisted this travesty on the >> ITS community to get away with this blatant abuse of the standards >> process is nothing sort of complicity! >> >> Cheers, >> >> RR >> >> -----Original Message----- From: its [mailto:its-bounces@ietf.org] >> On Behalf Of Alexandre Petrescu Sent: Thursday, April 19, 2018 8:59 >> AM To: its@ietf.org Subject: Re: [ipwave] IPWAVE Recharter Topics? >> >> For the XER-CAM/UDP/IP/Ethernet topic we have an interoperable >> implementation with a partner; that implementation couples to >> UPER-CAM/Geonet and soon will couple to XER-CAM/UDP/IP/LTE and >> potentially to XER-CAM/UDP/IP/OCB. >> >> We need to reserve a UDP port number for it, as now we just do it >> between 'consenting adults' 52000 decimal. >> >> Should we request it to IANA, or just continue between 'consenting >> adults' for the duration of the project trial prototype. >> >> Or maybe just wait a few months to have more confirmation. >> >> For those who wonder what is 'XER' it is an encoding rule specified by >> ITU, in a same family like 'UPER'.  XER is like XML human >> readable and UPER is Unaligned Packed Encoding Rules which is more >> compressed. UPER is preferred by CAM but makes little sense to >> humans; worse - UPER-CAM is ambiguously specified from a purely >> formal standpoint. ITU and others would like one day to join JSON >> into these encoding rules, maybe as a XER derivative. >> >> We now have a recipe about how to make CAMs and DENMs for almost free >> (no money) that I could publish easily, although I will not publish >> code.  That recipe relies entirely on the gratuituous open source >> software called asn1c, on freely accessible grammars from >> asn1-playground and marben websites.  We tested on several platforms >> of different endianness (endianness is important for embedded and for >> UPER).  We applied the recipe from one partner to another and it worked. >> >> A few things that still are in the way towards making cheap >> interoperable stack for ITS are: - various licensing conditions on >> geonet and a few other ITS-related ETSI messages still risk knocking >> at the door asking. - price tag of the SPAT grammar at SAE (in the >> order of hundred(s) dollars). >> >> Alex >> >> Le 19/04/2018 à 17:38, Alexandre Petrescu a écrit : >>> I think there are several things on the table: >>> >>> - QoS OCB-Ethernet, - ND over OCB, - XER-CAM/UDP/IP (instead of >>> UPER-CAM/Geonet), - RA prefix exchanges for V2V, - 65-SLAAC (instead >>> of 64-SLAAC), - IPv6-over-802.11-NGV, - IP Discovery of nearby >>> vehicles, - Security. >>> >>> There is also some comment in 6man that deserves consideration with >>> respect to ND. >>> >>> Le 18/04/2018 à 20:39, Russ Housley a écrit : >>>> I saw very little excitement for rechartering the IPWAVE WG. There >>>> were a small number of people want to do something, but most people >>>> felt that other standards bodies should tackle >>>> non-IP topics. >>>> >>>> Are there any IP-related topics that need to be tackled?  If so, is >>>> there enough interest and energy among the IPWAVE WG participants to >>>> tackle them? >>>> >>>> Russ >>>> >>>> _______________________________________________ its mailing list >>>>  its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Mon Apr 23 02:39:08 2018 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 7C3041200C1 for ; Mon, 23 Apr 2018 02:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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_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 dx6vyG5FVxb8 for ; Mon, 23 Apr 2018 02:39:04 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 7154F1200A0 for ; Mon, 23 Apr 2018 02:39:04 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id d24-v6so7828941iob.5 for ; Mon, 23 Apr 2018 02:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1UarYLS/1Dx2JGQxVnsr+2t2tXGEdKp7tZ5DPpE4zXE=; b=mMSTG1aIm79ropk5Zi+Ed0ywK33CrgArgiBUawZ4BspvEuIUIfoo3vTIEpfyFCbiLi XEJqk/KDggNdkpKrdSw9HWw+XwxkP+gk5AbzL/XDlNRtQgfF1Ho9+jDCeywUSllUnd99 JfkTFJI/wg3n8lBXy13bh7N9wgMLYsVJMFdEW5Yb/ivw7vOb2NOblDoxCUlcLaiX80TC 7SNfbVXbNzfi8+qR3plxsZWa6OnxE1U/x0XcrNyVKFspIxqolFj+L8LjlBwNTJ+Vk3w5 S6m7+0D3fS9ucuaWYqgW24X1PbZZIV7mBEPOg619ZH+Zs7bIRkON5wsV9Tlhs3AK3kfX tn4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1UarYLS/1Dx2JGQxVnsr+2t2tXGEdKp7tZ5DPpE4zXE=; b=eLlPFgRVvLNf9H58vye/QF3ElWa0auxaZD6I/2jd6VpdmZB66es4VNGPlYHmyO3vbk JbhP/bwOhN+g2z4XTkbJamgIyVEb4pxghXAwnyuo6m02NCf+61qS5l9PXzQixSDz1BaR /zuWkIUerYOie6M1Hoikl982r2uMZjbcbCs5wJPHLLW/0d8s5lLuvWkIWK0TJ8Ok3e4e O7ljy4UNGoEHw6MeYUqqPuYIZ423YzUelOgiCcRB5sIzztvr36FLoC5vFzxrHM7fcyo5 VB1RMQqLBUL6mthm96ofYjXkDfCY0zWUfIRiVQkzzpNxR8QEMx2cCYC6kEtLy6h/goDb Y+3Q== X-Gm-Message-State: ALQs6tCADcwXzqTuDGINMNrBb8vOJpA85ZGRqEwl7VnntKR0OhlWY5ZU 13GW0EKNuBY/mDN6UcDKzKGCsg1EDM6eqQVgg8I= X-Google-Smtp-Source: AB8JxZpdNoIdtVMWSW7bd1i3VYxoCzHZ2dynlbrQ34QDGZiKumDVSV71ysnBoXR3cp5Rlb+ThnC0QlCQJhBHZIsvss8= X-Received: by 2002:a6b:80d5:: with SMTP id k82-v6mr20764375ioi.253.1524476343758; Mon, 23 Apr 2018 02:39:03 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:8286:0:0:0:0:0 with HTTP; Mon, 23 Apr 2018 02:38:33 -0700 (PDT) In-Reply-To: <5F0CC237-5B49-477D-9FF2-D03840AC6D26@vigilsec.com> References: <5F0CC237-5B49-477D-9FF2-D03840AC6D26@vigilsec.com> From: "Mr. Jaehoon Paul Jeong" Date: Mon, 23 Apr 2018 18:38:33 +0900 Message-ID: To: Russ Housley Cc: its@ietf.org, "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="000000000000f038ab056a80ce3c" Archived-At: Subject: Re: [ipwave] IPWAVE Recharter Topics? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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, 23 Apr 2018 09:39:06 -0000 --000000000000f038ab056a80ce3c Content-Type: text/plain; charset="UTF-8" Hi Russ, As you know, I am working for the Problem Statement document for next steps. I think the topics in the content will be next steps for IPWAVE WG. I will try to have a revised document by May 11, 2018 and share it with IPWAVE WG. Thanks. Best Regards, Paul Paul On Thu, Apr 19, 2018 at 3:39 AM, Russ Housley wrote: > I saw very little excitement for rechartering the IPWAVE WG. There were > a small number of people want to do something, but most people felt that > other standards bodies should tackle non-IP topics. > > Are there any IP-related topics that need to be tackled? If so, is > there enough interest and energy among the IPWAVE WG participants to > tackle them? > > Russ > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant 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 --000000000000f038ab056a80ce3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Russ,
As you know, I am working for the Problem Sta= tement document for next steps.
I think the topics in the content= will be next steps for IPWAVE WG.

I will try to h= ave a revised document by May 11, 2018 and share it with IPWAVE WG.

Thanks.

Best Regards,
= Paul
Paul

On Thu, Apr 19, 2018 at 3:39 AM, Russ Housley <housley@vi= gilsec.com> wrote:
I saw ve= ry little excitement for rechartering the IPWAVE WG.=C2=A0 There were
a small number of people want to do something, but most people felt that other standards bodies should tackle non-IP topics.

Are there any IP-related topics that need to be tackled?=C2=A0 If so, is there enough interest and energy among the IPWAVE WG participants to
tackle them?

Russ

_______________________________________________
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) Jeon= g, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan U= niversity
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.s= kku.edu/people-jaehoon-jeong.php
--000000000000f038ab056a80ce3c-- From nobody Mon Apr 23 12:32:54 2018 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 345C912D810 for ; Mon, 23 Apr 2018 12:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham 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 qxc5fCwYoHNj for ; Mon, 23 Apr 2018 12:32:51 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AF14126B6E for ; Mon, 23 Apr 2018 12:32:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4DA82300A0D for ; Mon, 23 Apr 2018 15:32:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MDO1nt0_I4bm for ; Mon, 23 Apr 2018 15:32:47 -0400 (EDT) Received: from new-host-4.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 9B9A3300434; Mon, 23 Apr 2018 15:32:47 -0400 (EDT) From: Russ Housley Message-Id: <3FA36819-02A7-4849-8A5C-A3E484213CD6@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2E2FD49B-4C5B-4640-8BA7-9F9E0C6682B0" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 23 Apr 2018 15:32:48 -0400 In-Reply-To: Cc: its To: "Mr. Jaehoon Paul Jeong" References: <5F0CC237-5B49-477D-9FF2-D03840AC6D26@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ipwave] IPWAVE Recharter Topics? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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, 23 Apr 2018 19:32:53 -0000 --Apple-Mail=_2E2FD49B-4C5B-4640-8BA7-9F9E0C6682B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Paul: I am trying to summarize the discussion from the end of the WG session = in London. We talked about things that the WG might do next, and this = thread gives people that were not there an opportunity to share their = view. Russ > On Apr 23, 2018, at 5:38 AM, Mr. Jaehoon Paul Jeong = wrote: >=20 > Hi Russ, > As you know, I am working for the Problem Statement document for next = steps. > I think the topics in the content will be next steps for IPWAVE WG. >=20 > I will try to have a revised document by May 11, 2018 and share it = with IPWAVE WG. >=20 > Thanks. >=20 > Best Regards, > Paul > Paul >=20 > On Thu, Apr 19, 2018 at 3:39 AM, Russ Housley > wrote: > I saw very little excitement for rechartering the IPWAVE WG. There = were > a small number of people want to do something, but most people felt = that > other standards bodies should tackle non-IP topics. >=20 > Are there any IP-related topics that need to be tackled? If so, is > there enough interest and energy among the IPWAVE WG participants to > tackle them? >=20 > Russ >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its = >=20 >=20 >=20 > --=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. > Assistant 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 = > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --Apple-Mail=_2E2FD49B-4C5B-4640-8BA7-9F9E0C6682B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Paul:

I = am trying to summarize the discussion from the end of the WG session in = London.  We talked about things that the WG might do next, and this = thread gives people that were not there an opportunity to share their = view.

Russ


On Apr 23, 2018, at 5:38 AM, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> wrote:

Hi Russ,
As you know, I am working for the = Problem Statement document for next steps.
I think = the topics in the content will be next steps for IPWAVE WG.

I will try to have a = revised document by May 11, 2018 and share it with IPWAVE WG.

Thanks.

Best Regards,
Paul
Paul

On Thu, = Apr 19, 2018 at 3:39 AM, Russ Housley <housley@vigilsec.com> wrote:
I saw very little = excitement for rechartering the IPWAVE WG.  There were
= a small number of people want to do something, but most people felt = that
other standards bodies should tackle non-IP topics.

Are there any IP-related topics that need to be tackled?  If so, = is
there enough interest and energy among the IPWAVE WG participants to
tackle them?

Russ

_______________________________________________
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.
Assistant 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
_______________________________________________
its = mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its

= --Apple-Mail=_2E2FD49B-4C5B-4640-8BA7-9F9E0C6682B0-- From nobody Mon Apr 23 17:10:07 2018 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 91C4512DA73 for ; Mon, 23 Apr 2018 17:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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_LOW=-0.7, 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 TwqEnupMBTo8 for ; Mon, 23 Apr 2018 17:10:03 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 8C5F312DA6A for ; Mon, 23 Apr 2018 17:10:03 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id m134-v6so13279432itb.3 for ; Mon, 23 Apr 2018 17:10:03 -0700 (PDT) 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=nMKPmZU78Fn2Odn9dRvzI6c+UfI9nGk3+Ke/Y8Vcx8U=; b=YyAUsTvx1mnhyPpsxqPRHvNVHBl8bKTu4xIkqGVtvrhKAKdzC9R7NWOaEBM5YJL+2X LA/Lhln+CL32nDqV/6p98FGeOGk+UC8U/0ct4+C/XcTjArVIrBUhIaNetumP9AHLTqaP SMh/Bevpe6MWyq0slDRkfSjLgTqiLF3x5tLP2gRpmhHxA4X6itQAswYXrofEce9vgLEh spoxXarZMFL7iYZoxu8lj6Gf19d5UBwpg3oqx0Nhsrwcm50iqyO7mbEx+3Ei5l4WHRG1 6+Or2jNRTV9hGsojCeOYzYCCx8gsyc0lenOwPUtI53whd9XisYcTk4V0i2iTdZAONpPb pWpQ== 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=nMKPmZU78Fn2Odn9dRvzI6c+UfI9nGk3+Ke/Y8Vcx8U=; b=qpPudDwjgoctaswl+8p1NDewh48Cuif/+Bru2fxyS+UwmWzWGMeU7PnnnS1ozlv4n5 BMEjY5Yi+Am0aElMBZvmKzkxsOZ/Z8K6ZT48uN76tfSdlcuLLS7soZ0WDL+Dn3+shCRb r8FITuw0KXtveHifeLSyyUjyRS2x00sIlvmx4woWQVqCsPYIAwOPRfdqlLhho5IGGIk7 MY9JPo5Banf2bRZ6/i+UMrgTVNohZ7Vm3+CReezY+cB5ORlOL3LfTBsXQv9d+ancmk9F z6akvJADaIoC4GnyeHHxlcbz+lhI/XTxQuwP32606UIG6CTO2YfBqjPF1WkEVbSJv+Bz QFbw== X-Gm-Message-State: ALQs6tAUgJFv/9xmJNbZMpmBtxS9x9AiDEQtrbAsBSMsiUOV9ndKdZmF Myu8jPu9yAEB5iPoe8FSJuPm72QGhyLsXTcZFjM= X-Google-Smtp-Source: AIpwx49sgDWPHNPJkp/G+pDNOQ1FjNj+zvYFTRW8No6wqO5VhpoC/E80nOCH/e+7RXRFSZixR7xvgHBnxKTVrLj4/zo= X-Received: by 2002:a24:6c0f:: with SMTP id w15-v6mr15310063itb.29.1524528602814; Mon, 23 Apr 2018 17:10:02 -0700 (PDT) MIME-Version: 1.0 References: <5F0CC237-5B49-477D-9FF2-D03840AC6D26@vigilsec.com> <3FA36819-02A7-4849-8A5C-A3E484213CD6@vigilsec.com> In-Reply-To: <3FA36819-02A7-4849-8A5C-A3E484213CD6@vigilsec.com> From: "Mr. Jaehoon Paul Jeong" Date: Tue, 24 Apr 2018 00:09:52 +0000 Message-ID: To: Russ Housley Cc: its , skku_iotlab_seminar@googlegroups.com, Jaehoon Jeong Content-Type: multipart/alternative; boundary="000000000000d21f11056a8cf9ed" Archived-At: Subject: Re: [ipwave] IPWAVE Recharter Topics? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 24 Apr 2018 00:10:05 -0000 --000000000000d21f11056a8cf9ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Russ, I see. :) If there are important items with certain consensus for our Problem Statement document from this, I will include them into the revised document= . Thanks. Best Regards, Paul 2018=EB=85=84 4=EC=9B=94 24=EC=9D=BC (=ED=99=94) =EC=98=A4=EC=A0=84 4:32, R= uss Housley =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > Paul: > > I am trying to summarize the discussion from the end of the WG session in > London. We talked about things that the WG might do next, and this threa= d > gives people that were not there an opportunity to share their view. > > Russ > > > On Apr 23, 2018, at 5:38 AM, Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > > Hi Russ, > As you know, I am working for the Problem Statement document for next > steps. > I think the topics in the content will be next steps for IPWAVE WG. > > I will try to have a revised document by May 11, 2018 and share it with > IPWAVE WG. > > Thanks. > > Best Regards, > Paul > Paul > > On Thu, Apr 19, 2018 at 3:39 AM, Russ Housley > wrote: > >> I saw very little excitement for rechartering the IPWAVE WG. There were >> a small number of people want to do something, but most people felt that >> other standards bodies should tackle non-IP topics. >> >> Are there any IP-related topics that need to be tackled? If so, is >> there enough interest and energy among the IPWAVE WG participants to >> tackle them? >> >> Russ >> >> _______________________________________________ >> 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. > Assistant 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 > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > --000000000000d21f11056a8cf9ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Russ,
I see. :)
<= div dir=3D"auto">
If there are important items w= ith certain consensus for our Problem Statement document from this, I will = include them into the revised document.

Thanks.

= Best Regards,
Paul

2018=EB=85=84 4=EC=9B=94 24=EC=9D=BC (=ED=99=94) = =EC=98=A4=EC=A0=84 4:32, Russ Housley <housley@vigilsec.com>=EB= =8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1:
Paul:

I am trying t= o summarize the discussion from the end of the WG session in London.=C2=A0 = We talked about things that the WG might do next, and this thread gives peo= ple that were not there an opportunity to share their view.

<= /div>
Russ


=
On Apr 23, 2018, at 5:38 AM, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> wrote:

H= i Russ,
As you know, I am working for the Problem Statement document fo= r next steps.
I think the topics in the content will be next step= s for IPWAVE WG.

I will try to have a revised docu= ment by May 11, 2018 and share it with IPWAVE WG.

= Thanks.

Best Regards,
Paul
Pau= l

On T= hu, Apr 19, 2018 at 3:39 AM, Russ Housley <housley@vigilsec.com> wrote:
I saw very little excitement for rechartering the IPWAVE WG.=C2=A0 Ther= e were
a small number of people want to do something, but most people felt that other standards bodies should tackle non-IP topics.

Are there any IP-related topics that need to be tackled?=C2=A0 If so, is there enough interest and energy among the IPWAVE WG participants to
tackle them?

Russ

_______________________________________________
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.
Assistant Professo= r
Department of Software
Sungkyunkwan University
Office: +82-31-29= 9-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal = Homepage: http://iotlab.skku.edu/people-= jaehoon-jeong.php
_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailma= n/listinfo/its

--000000000000d21f11056a8cf9ed--