From nobody Mon Apr 3 22:14:21 2017 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 0D1A712940C for ; Mon, 3 Apr 2017 22:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTx9ou9bOauC for ; Mon, 3 Apr 2017 22:14:17 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002: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 014DB126B6D for ; Mon, 3 Apr 2017 22:14:16 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id l201so38908531ybf.0 for ; Mon, 03 Apr 2017 22:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=023FevZikqRG3roEBE8aLBheNh6s79Rk6PwZxVSpmLM=; b=DH01f69ihxd9WU4RNhA2QIlDvtmlGl9N7v6y0Sm346PKtFWvWMyEoNTSb//69823EL rFhdcxwZwmulrjJGfPMqOgStkzs1LANpfn+vtuszUok1OZXmvi9c0FhzAx5orDrwPkxD sXsH0AXWCUIwaGxTlfEzGMaOWS3FPT0VIMg5g2CzczMmdvBh9hFmlzRTiQp3w0S4btqg UUPMLhQl9agkt2t9CqkQdot7vvI74nKlPYyVDOkQNqlxkzSkR2mUl6IkNyXQPdgkvYpI SMXfy/hiT8EH9UbV5qjVeENbgMGws7RPwa9Rnpp6dAGgYxpJQYz6htClm3jFdL+aCetQ nVPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=023FevZikqRG3roEBE8aLBheNh6s79Rk6PwZxVSpmLM=; b=ayWFSYLdOQMQHc+NPXefLLSa+ZPgjF5ededt4dDTYxta4G7TMDdp7jorijEdvPKkqe wTrdqI3NG82xEbxQUFYI1oLgmhGV/TgVDu5iCmDAI149aq+d0ADDUXv78f7aJAfRSrCY fIcyBai5kviwhInQoG/0f/+HaccbX+SNG90gJmWVpvHPW47odu+ITz5ondRI0H2kVgT/ VmWLQpRCYIGPYh7+xbr/7nkmCNf0aqscvD6yfec9e/Zo1PiZY/SHHGVINRoIGevMDW+V rrSbMhlEXxUikKGFQxNvPKQzYsYS3AfVj7TGbCn3YB5vFqVZEK6XuzjaTcwN9iSjGEOJ t8kA== X-Gm-Message-State: AFeK/H3eH7IB5rDnOCrir0Bf90NArkGKW4urLqUM1iKUHPfxT00z/t7E64OoWFt64phOdDnrrkyvcesDopc/YQ== X-Received: by 10.13.224.196 with SMTP id j187mr14407578ywe.318.1491282856076; Mon, 03 Apr 2017 22:14:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.210.4 with HTTP; Mon, 3 Apr 2017 22:13:45 -0700 (PDT) From: "Mr. Jaehoon Paul Jeong" Date: Tue, 4 Apr 2017 14:13:45 +0900 Message-ID: To: its@ietf.org Cc: skku_iotlab_seminar@googlegroups.com, "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary=94eb2c066c94e56c92054c505822 Archived-At: Subject: [ipwave] Request for Reading ITS Survey Draft 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, 04 Apr 2017 05:14:20 -0000 --94eb2c066c94e56c92054c505822 Content-Type: text/plain; charset=UTF-8 Hi IPWAVE WG, As discussed the last IETF-98 Chicago meeting, the ITS survey draft below will be considered as the working group document for "ITS General Problem Area" according to our WG's charter and milestones. The draft link: https://tools.ietf.org/html/draft-jeong-ipwave-vehicular-networking-survey-02 The slides link: https://www.ietf.org/proceedings/98/slides/slides-98-ipwave-survey-on-ip-based-vehicular-networking-for-its-01.pdf IPWAVE WG chairs will send the WG document adoption call a week later. Thanks. Best Regards, Paul -- =========================== 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 --94eb2c066c94e56c92054c505822 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi IPWAVE WG,
As discussed the last IETF-98 Chicago me= eting,
the ITS survey draft below will be considered as the worki= ng group document=C2=A0
for "ITS General Problem Area" = according to our WG's charter and milestones.

= The draft link:

The slides link:

<= div>IPWAVE WG chairs will send the WG document adoption call a week later.<= /div>

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 Univ= ersity
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0paulj= eong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-ja= ehoon-jeong.php
--94eb2c066c94e56c92054c505822-- From nobody Tue Apr 4 12:34:38 2017 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 E509412949E for ; Tue, 4 Apr 2017 12:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.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 GT0Q6tR7hQvw for ; Tue, 4 Apr 2017 12:34:34 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 190B3129471 for ; Tue, 4 Apr 2017 12:34:34 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id t189so36991457wmt.1 for ; Tue, 04 Apr 2017 12:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:organization :mime-version:content-transfer-encoding; bh=sh9zLYnr3oLevh0SHwLBxTnoRIxmiaVZAPpoVRgqN60=; b=KipgDZ7pkCHxuNr11iestbFMxl+ixGjRELe9OAcuF/eVqvt+kyMtA6+S03IJdqI6CF mTYGLOiSpEdt99BjvEJUwz/73ErZzSg6F2I86Dj/Tj/qXViMvP4NVxAV7HTHABQwTJBh B381RHVyP3C6ZwLh2udaIQEofxL48ZaknJbrdCQ2vn+BRkfGNZRsz+9+txsq6OBGp1aW aiEECT9QHtD8c+mxOkvw74rvMolDnftu6RAHehD5sl0MbPyAOezU1ba0C4FDJ825JTWx Nk140PKCF918I+rVyC8BsJu/QmLH2INMcnjSRObBdWPyUdghiNYLbrBNBAgoYgRN4fyo +oSw== 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:reply-to:to:cc:date :organization:mime-version:content-transfer-encoding; bh=sh9zLYnr3oLevh0SHwLBxTnoRIxmiaVZAPpoVRgqN60=; b=GYcSVPoXiPq4WZMB0PrxJb9EPPuGm1evPMCrm1W6EbyK0Nc3xjEDkvndl7gQ8Doa+6 ZdmyjLusfAxXD5Csz3zJdiaMv5JSkflSgAH/IS3FTOA4ZLSXJGXjLPE8Q1qmJn+rCJC3 M9wSEIzci9XyKqBNGEJDICljoMVxHA70sH8yY5AEY0mTP4WwDh7bbw6Z+tSHX/x6+OZJ Vbo+VFP8gQXSZ1xPHEGP+YsfJhoJKa0FsMCtK7WDG9w6/vKzw9M3PXerAWRh+ABDiuqN PEGp2KgSZ8ntmm30IEoGqh8II5sH9Dj/5QGR0dYXLmisHn8wTl9c+yKIZzhInSKDNesj 1jqw== X-Gm-Message-State: AFeK/H2xzcDl8Vzv+8xVIWUapwNaC48zhAreclrMbwKRYnf0a7UQv9BLBvfwpPAgfHfaxAdk X-Received: by 10.28.7.144 with SMTP id 138mr16465146wmh.125.1491334472397; Tue, 04 Apr 2017 12:34:32 -0700 (PDT) Received: from cjbc_dell.lan (85.251.161.16.dyn.user.ono.com. [85.251.161.16]) by smtp.gmail.com with ESMTPSA id m29sm23449767wrm.4.2017.04.04.12.34.31 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 04 Apr 2017 12:34:31 -0700 (PDT) Message-ID: <1491334470.3575.9.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: its@ietf.org Cc: Russ Housley Date: Tue, 04 Apr 2017 21:34:30 +0200 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.5-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: [ipwave] Draft minutes of IPWAVE@IETF98 available 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, 04 Apr 2017 19:34:38 -0000 Hi, We've just posted the minutes: https://www.ietf.org/proceedings/98/minutes/minutes-98-ipwave-01 Please send corrections/comments by Friday, Apr 7th. Thanks a lot to Danny and Bob for taking the minutes! Cheers, Carlos & Russ From nobody Wed Apr 5 03:22:33 2017 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 3D70A12785F for ; Wed, 5 Apr 2017 03:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ApvHpOk0bLbK for ; Wed, 5 Apr 2017 03:22:29 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 F27A0129432 for ; Wed, 5 Apr 2017 03:22:24 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id d191so3792582ywe.2 for ; Wed, 05 Apr 2017 03:22:24 -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=sQWB1AcWgF7oi+81QMGUeRtuf7Zhwf6U9GMqLBvtgeg=; b=u7dkt1GE6krKOYQJXLTstfuivqyAuquqpqa4cBqO2GSUTQmAsTTVH8drn/3OTQa046 V50c4lfY5UWTM0hRLJBe0Gk/mTbFQjZF4XRaev8cZaebxHekjq1S6MDsyYnsqNDbSlar RL5AEgOHapXXvTAsmDxRY8KRDdl+oUaCqQNXaF4Lh1zKYVLN/TAdusLJv3J4OXm+Y0lH tF7hu+SoMCKVq+QTiSBh9ws/zFTiYAOatV5NkVY2aXFqAyA1DWU5wASL/6Mi8LOK546b Py0DyuhNK1tFrPTGFWQw+U1nQ144TlfYG1E2U0Tmws7PTp+iVlPrb5v+ZvF6JOA/QxRe IpiA== 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=sQWB1AcWgF7oi+81QMGUeRtuf7Zhwf6U9GMqLBvtgeg=; b=EdkkwpiRyhmV2Pe2snumdY1ORatrXze4M0D2yyCryfnfmHZMktC9+1KErDE4p9+rjv eCgP3Ggoe2qAByO40QdHHv2fjE9yQabBYJe+/ftK+E2mFopmVSAuqUtACvMVMKBYjopp lZZ5wsMkiLRxKWmwQQ4yKGrxZ6vnZdjHoMcjvS5oi+4xmr8Mmmoy0heS17F3OoSMVY3G Q/kiS4E2NmXNpEnl37VMicQD7yoSE9XwFhBketavNCU43t0XgzKLZ+cBLISaLUW1rxPJ 5Z1OR3XZV/7RH2cAFsYkTMy8lttVrJZ+1B9W5LtqVc6WDqSypspk+N4Suos6wDJga2Wu Hnrw== X-Gm-Message-State: AFeK/H1TrmfXxslWR5CyZmYmqJ30I0D1/JmutSKx4uFScnhENkDq+SBfD6SLk/f/PWjLN/rzOawYPHjo4p5vYA== X-Received: by 10.13.214.20 with SMTP id y20mr19703397ywd.49.1491387744146; Wed, 05 Apr 2017 03:22:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.210.206 with HTTP; Wed, 5 Apr 2017 03:22:23 -0700 (PDT) In-Reply-To: <1491334470.3575.9.camel@it.uc3m.es> References: <1491334470.3575.9.camel@it.uc3m.es> From: Michelle Wetterwald Date: Wed, 5 Apr 2017 12:22:23 +0200 Message-ID: To: cjbc@it.uc3m.es Cc: its@ietf.org, Russ Housley Content-Type: multipart/alternative; boundary=94eb2c076a38b65c67054c68c413 Archived-At: Subject: Re: [ipwave] Draft minutes of IPWAVE@IETF98 available 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, 05 Apr 2017 10:22:31 -0000 --94eb2c076a38b65c67054c68c413 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, Thank you very much for these minutes. I would like to ask for update on the notes about the survey discussion. I think it was said that "802.2 does not exist anymore". rather than "1609.2 does not exist anymore." Best regards, Michelle 2017-04-04 21:34 GMT+02:00 Carlos Jes=C3=BAs Bernardos Cano : > Hi, > > We've just posted the minutes: > > https://www.ietf.org/proceedings/98/minutes/minutes-98-ipwave-01 > > Please send corrections/comments by Friday, Apr 7th. > > Thanks a lot to Danny and Bob for taking the minutes! > > Cheers, > > Carlos & Russ > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --=20 Michelle Wetterwald michelle.wetterwald@gmail.com --94eb2c076a38b65c67054c68c413 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carlos,

Thank you very mu= ch for these minutes.

I would like to ask for upda= te on the notes about the survey discussion.

I thi= nk it was said that "802.2 does not exist anymore". rather than &= quot;1609.2 does not exist anymore."

Best reg= ards,
Michelle


2017-04-04 21:34 GMT+02:00 Carlos = Jes=C3=BAs Bernardos Cano <cjbc@it.uc3m.es>:
Hi,

We've just posted the minutes:

https://www.ietf.org/proceeding= s/98/minutes/minutes-98-ipwave-01

Please send corrections/comments by Friday, Apr 7th.

Thanks a lot to Danny and Bob for taking the minutes!

Cheers,

Carlos & Russ

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



--
--94eb2c076a38b65c67054c68c413-- From nobody Wed Apr 5 04:21:21 2017 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 645D7129476 for ; Wed, 5 Apr 2017 04:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=it-uc3m-es.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 T1SrofUeypu6 for ; Wed, 5 Apr 2017 04:21:16 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 4AE241274D2 for ; Wed, 5 Apr 2017 04:21:15 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id w43so9272809wrb.0 for ; Wed, 05 Apr 2017 04:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=hJYeXHGRCGAQwkvWQHnArbc5JeMr21XqEeRA85ZFLMc=; b=ifC43OpX/aLB7bhfz3kxTqMhhJ1UWy/ExNEauhSGZvY89x+HL18ytz1ll26pfAVpSO 3L4j4hL/+2gHIG4TtPVhCAGIBLi/glyJwIERV3igNR7pUaIYYKlqRSOcRH0xLRJa9xA9 2dLUXYHEHYXc7IzEaBnRuDG5b1QpryNw3mRi3t/aaGGe7W9PCyVrf7O7StjakQTpirZe hY8MFRM2FFvo0gsIRws+h1jDPd8bCrYmJEVd5vpsT5PAjZVmFIQOwBsMx53fzSCk8eFy OvB3gX4ny1mWUpoC9e5douDmSnJ3W/mAivtc5hqM0iDSm4P5nHw1Xob2ACZJVQmqnYfS /0IQ== 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:reply-to:to:cc:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=hJYeXHGRCGAQwkvWQHnArbc5JeMr21XqEeRA85ZFLMc=; b=tuJsfM9FXT54AJtHSM0UE4Bdfsomrfd4oWkj2b+oQOsnhG8C05fKDSe6bV29PLYS2h pN6TotBff198yTMNAOJYLDVQoiwmGokRbvURNqbmfIMMvtsTTwWKJxZsxXRoQ3yUi8Um OR6L6WTARIQs9rhQknySkOljAL3I1iBMmpB9WvUnqx9pwz3nYNTZX2V2Ne3GAQFddfME DvqQK+3fV5mCFGKHwtcGC0Wd6eHCtB41pX18GDpZzOmkMFiGMKVLJ1fcp5Go8FpK3YZT 0bd2u4M4sN8Xxdj0MzzM8sZdd7E/U+kftWr94uZi+1t7WtxM1PtT8bZQY3NXZ3IDrstj OLbQ== X-Gm-Message-State: AFeK/H2ZsOjyyAVTinnVxPgEzRiz96l32/wJNozs85SMQOOOk7R2AVMTuKNAIh0TqLU6i7cR X-Received: by 10.28.157.150 with SMTP id g144mr19308470wme.89.1491391272943; Wed, 05 Apr 2017 04:21:12 -0700 (PDT) Received: from wifi-216-148.uc3m.es (wifi-216-148.uc3m.es. [163.117.216.148]) by smtp.gmail.com with ESMTPSA id c18sm18292368wre.48.2017.04.05.04.21.11 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 05 Apr 2017 04:21:12 -0700 (PDT) Message-ID: <1491391261.2517.4.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: dickroy@alum.mit.edu, its@ietf.org Cc: 'Russ Housley' , 'Alexandre Petrescu' Date: Wed, 05 Apr 2017 13:21:01 +0200 In-Reply-To: <8057466055914FB89C1597E66E42926B@SRA6> References: <1491334470.3575.9.camel@it.uc3m.es> <8057466055914FB89C1597E66E42926B@SRA6> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Draft minutes of IPWAVE@IETF98 available 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, 05 Apr 2017 11:21:19 -0000 Hi Dick, What is the status of solving the issue with the mail reflector? I think we need to try to solve this so you can engage into discussion on the mailing list. I believe your contributions would be really helpful to the WG. Thanks, Carlos On Tue, 2017-04-04 at 16:40 -0700, Dick Roy wrote: > All, > > These are comments only, as I was not present at the meeting. > > 1) While there are such things as IEEE 802.11 beacons, they are NOT > sent > when dot11OCBActivated is true. > > 2) IEEE Std1609.2 DOES exist. > > 3) I would definitely NOT call the LLC sublayer "interface" between > the > 802.11 MAC and the IPv6 networking layer SNAP.  SNAP is on its way > out, > along with all the other 802.2 LLC functionality, AND most > importantly, > communications in the 5.9GHz in the US use type encoding (EPD if you > are an > IEEE Std802 O&M fan).  Call it what it is: "EPD". > > 4) No single set of standards is going to "resolve the privacy > concern". > Privacy is a system concept the takes a lot of effort at every layer > in the > system to properly implement.   > > 5) STAs operating OCB are NOT STAs operating in ad hoc mode; thus, > OCB STAs > should not be labeled as ad hoc STAs.  > > Hope this helps. > > RR > > PS.  Alex, I don't believe the reflector problem has been resolved > yet, so > forward this if you feel it's appropriate. > > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Carlos Jesús > Bernardos > Cano > Sent: Tuesday, April 4, 2017 12:35 PM > To: its@ietf.org > Cc: Russ Housley > Subject: [ipwave] Draft minutes of IPWAVE@IETF98 available > > Hi, > > We've just posted the minutes: > > https://www.ietf.org/proceedings/98/minutes/minutes-98-ipwave-01 > > Please send corrections/comments by Friday, Apr 7th. > > Thanks a lot to Danny and Bob for taking the minutes! > > Cheers, > > Carlos & Russ > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Wed Apr 5 04:26:19 2017 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 F3AC6129452 for ; Wed, 5 Apr 2017 04:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=it-uc3m-es.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 t7n1cf-X1KfE for ; Wed, 5 Apr 2017 04:26:15 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 B288B1201F8 for ; Wed, 5 Apr 2017 04:26:14 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id t20so9821566wra.1 for ; Wed, 05 Apr 2017 04:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=itM3vM7JPYmTQ9AqTomZhFWjFxfHYDCtAUaN+Z53zMQ=; b=aUzEe8UWJa+vhk6vVWL5RfLtBj61L7xgUMnRE375qZx4VilysTSYFLsWB3OLPUxqtS bINW13Ag/lHwB3V/k37Y8328MiAphvqQsj1WrtKhQNq0xq4V2wwaGM4I1Lxxp9M/yCPq fqNmU748GvDw9FILN0acNGNxla5EtL3L+yCxQruqakNxujIesU57/0/C0DcTIKgUDQCv Cv5DvLgn4fkcpAb8hoQoyFafFPoIYX5VksdTqb1DDymOh7wsLaJdW+FHqdyxgUSBmDo3 LPFNVozae0qMw2Lh/2/m9bA53eLvHEc46AxTdCnDQ9CADRQ5fFQRWQhJHKRhdQ/w8Erw uAUQ== 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:reply-to:to:cc:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=itM3vM7JPYmTQ9AqTomZhFWjFxfHYDCtAUaN+Z53zMQ=; b=HCAdCS/FcgKz6jHPbvy8X0yss/mbbEd4zb8s2bfGago4jMSt95S4Lz0He+UHiQirXl uofTUb8EV9UJjAPEkqdmF5zfMEYd508VjkxEy+U2YbarE4gi8cPs2e1RVgxiNIOurJeJ 8iQ4osiPallnVIT/ajuTthwYXN+YPsOO8c69Yoy3aFd5SlpuzGihpzCAGaZDx53vDK4W v0kcmns1uBWaghGgUcR9ZLz1F7JG0q4keGIu2ZTuwT8Oo+z5Ew3dTttG1QxwTQtUMQfc Qph6QMAP1dM70HPYHIP7GJQIo88AG4GIz2zHJj8+tQ0VH27vRX7O1hnfH3HaW7tPwxuh Tf0g== X-Gm-Message-State: AFeK/H3L37qZMdhEDRwXLjbHsA40ozxdXh6iDZzkjsmvNHh9AQ0wCC22b7XyVb6Yjx46F2u8 X-Received: by 10.223.164.141 with SMTP id g13mr14081002wrb.82.1491391573182; Wed, 05 Apr 2017 04:26:13 -0700 (PDT) Received: from wifi-216-148.uc3m.es (wifi-216-148.uc3m.es. [163.117.216.148]) by smtp.gmail.com with ESMTPSA id t79sm22003559wmd.29.2017.04.05.04.26.12 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 05 Apr 2017 04:26:12 -0700 (PDT) Message-ID: <1491391567.2517.6.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: Michelle Wetterwald Cc: its@ietf.org, Russ Housley Date: Wed, 05 Apr 2017 13:26:07 +0200 In-Reply-To: References: <1491334470.3575.9.camel@it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Draft minutes of IPWAVE@IETF98 available 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, 05 Apr 2017 11:26:17 -0000 Hi Michelle, Thanks for your comment. I've updated the minutes, but I'd like Bob to confirm (as he is the one that made that comment). Thanks, Carlos On Wed, 2017-04-05 at 12:22 +0200, Michelle Wetterwald wrote: > Hi Carlos, > > Thank you very much for these minutes. > > I would like to ask for update on the notes about the survey > discussion. > > I think it was said that "802.2 does not exist anymore". rather than > "1609.2 does not exist anymore." > > Best regards, > Michelle > > > 2017-04-04 21:34 GMT+02:00 Carlos Jesús Bernardos Cano es>: > > Hi, > > > > We've just posted the minutes: > > > > https://www.ietf.org/proceedings/98/minutes/minutes-98-ipwave-01 > > > > Please send corrections/comments by Friday, Apr 7th. > > > > Thanks a lot to Danny and Bob for taking the minutes! > > > > Cheers, > > > > Carlos & Russ > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > > > > > From nobody Wed Apr 5 08:06:22 2017 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 99188127241 for ; Wed, 5 Apr 2017 08:06:20 -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 asY4SxIt2grF for ; Wed, 5 Apr 2017 08:06:18 -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 CC6EA128854 for ; Wed, 5 Apr 2017 08:06:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F240D300436 for ; Wed, 5 Apr 2017 11:06:17 -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 SnZ1ysj21PzK for ; Wed, 5 Apr 2017 11:06:16 -0400 (EDT) Received: from new-host-7.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id A634130028A; Wed, 5 Apr 2017 11:06:16 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: <1491391567.2517.6.camel@it.uc3m.es> Date: Wed, 5 Apr 2017 11:06:24 -0400 Cc: Michelle Wetterwald , its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1491334470.3575.9.camel@it.uc3m.es> <1491391567.2517.6.camel@it.uc3m.es> To: =?utf-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [ipwave] Draft minutes of IPWAVE@IETF98 available 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, 05 Apr 2017 15:06:21 -0000 My memory is that Bob said something like: * BM: 802.2 does not exist anymore, so the diagram should not show = it. Russ > On Apr 5, 2017, at 7:26 AM, Carlos Jes=C3=BAs Bernardos Cano = wrote: >=20 > Hi Michelle, >=20 > Thanks for your comment. I've updated the minutes, but I'd like Bob to > confirm (as he is the one that made that comment). >=20 > Thanks, >=20 > Carlos >=20 > On Wed, 2017-04-05 at 12:22 +0200, Michelle Wetterwald wrote: >> Hi Carlos, >>=20 >> Thank you very much for these minutes. >>=20 >> I would like to ask for update on the notes about the survey >> discussion. >>=20 >> I think it was said that "802.2 does not exist anymore". rather than >> "1609.2 does not exist anymore." >>=20 >> Best regards, >> Michelle >>=20 >>=20 >> 2017-04-04 21:34 GMT+02:00 Carlos Jes=C3=BAs Bernardos Cano = > es>: >>> Hi, >>>=20 >>> We've just posted the minutes: >>>=20 >>> https://www.ietf.org/proceedings/98/minutes/minutes-98-ipwave-01 >>>=20 >>> Please send corrections/comments by Friday, Apr 7th. >>>=20 >>> Thanks a lot to Danny and Bob for taking the minutes! >>>=20 >>> Cheers, >>>=20 >>> Carlos & Russ >>>=20 >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>>=20 >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Wed Apr 5 08:25:41 2017 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 8101B12894E for ; Wed, 5 Apr 2017 08:25:39 -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 fk6WWPVWxMm4 for ; Wed, 5 Apr 2017 08:25:37 -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 D7E79128854 for ; Wed, 5 Apr 2017 08:25:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 47CBC300455 for ; Wed, 5 Apr 2017 11:25:37 -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 16_8J_lr_bGH for ; Wed, 5 Apr 2017 11:25:36 -0400 (EDT) Received: from new-host-7.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 1D3E630028A; Wed, 5 Apr 2017 11:25:36 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: <1491334470.3575.9.camel@it.uc3m.es> Date: Wed, 5 Apr 2017 11:25:43 -0400 Cc: its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <76D2CB3E-80F1-4F01-8AD0-348DBBA57A2E@vigilsec.com> References: <1491334470.3575.9.camel@it.uc3m.es> To: =?utf-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [ipwave] Draft minutes of IPWAVE@IETF98 available 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, 05 Apr 2017 15:25:39 -0000 I=E2=80=99m editing the minutes for a few very minor things. 1) It honor the line-lenght conventions usually used in RFCs. 2) Finish this sentence: * SK, as AD: but the WG is not chartered to write more documents. = Either re-charter or=20 I made it: * SK, as AD: but the WG is not chartered to write more documents. To = do so would require the WG to re-charter=20 3) Correct the reference to BSS (Basic Service Set) * BM: sow add in SS mode (figure a). * Dorothy Stanley (DS): figure a is infrastructure mode (and then, = AP is correct). I make it: * BM: also add in BSS (Basic Service Set) mode in figure a. * Dorothy Stanley (DS): figure a illustrates infrastructure mode, so AP is correct. 4) IEEE 802.11 Beacons * DS: there are IEEE Beacons -- fix the text. I made it: * DS: there are IEEE 802.11 Beacons; please fix the text. > On Apr 4, 2017, at 3:34 PM, Carlos Jes=C3=BAs Bernardos Cano = wrote: >=20 > Hi, >=20 > We've just posted the minutes: >=20 > https://www.ietf.org/proceedings/98/minutes/minutes-98-ipwave-01 >=20 > Please send corrections/comments by Friday, Apr 7th. >=20 > Thanks a lot to Danny and Bob for taking the minutes! >=20 > Cheers, >=20 > Carlos & Russ >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Wed Apr 5 20:08:08 2017 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 2B64B128B37 for ; Wed, 5 Apr 2017 20:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.988 X-Spam-Level: X-Spam-Status: No, score=-0.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, URIBL_BLOCKED=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 HGrvvVQ60V-6 for ; Wed, 5 Apr 2017 20:08:05 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::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 2C5521288B8 for ; Wed, 5 Apr 2017 20:08:05 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id m133so7640928ybb.1 for ; Wed, 05 Apr 2017 20:08:05 -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=KfjlEqYrcu4g1j4JadBIB/sxBCLV9d/4SaGcOk3XMys=; b=s0JPuJlbztnfidSEvWA/MKZKEa1oyXGqky97RGMGMgIVoJHXLJCrpbZKjmJlid8dNW wTfuI0UWwveebDBdOrrsOAm8GRori+pGWlHefB9VhKYzWOOI5V6FpN4+oY5ai6fK1Ap2 fyuY8kbzeEjqP72/ikeySs7u82ZOwXibqFy1NlPtZGJCedFQhbjWfVtKhw2AtyaaIVOg Vji9M//C8Rh21eJTsqrntNCvYbTJeZZtJG2mqSpYdPEd4mv5XMOpCwiNFqGLAvyaqKrI ELLFjZbCBERRyQ6UU6NO1bmENEHqcjmgNNfvuSbfifAHoxg13/Gt1aSe4ZTP5F84mQ5d Kw2w== 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=KfjlEqYrcu4g1j4JadBIB/sxBCLV9d/4SaGcOk3XMys=; b=ZEXwTWhJpm/KAW5K5tIS5DxfRJ+eJkAHNzUCkJUh5A9I/Q036JO3qv8txOSt2s4+Lq N0Si94rseHCUXJv9jQxS0MWFYrFa3xuDyq9sWcuDOhx+cTlpphsY24EilWnNSyPOunj5 bRdvLv9KIiWpYfa/2z4zDzojFKadB5cR+xgPwIucFvr+ts0ZlyaFV3oa8vbGHSAroujL 0V5cgPEZadq5N/Kfxe8YdjP0VEdxYhmMWVoiu/sbzbbXAWJuPCmTua5iP1cBvpukKI8R hpk+xOEEWm2o3vmyQhrBRG+ZGfRdAOqjxzkGQ3v60EynaeDhkMKjzTjT+ZKkVvPBaGuh zfhg== X-Gm-Message-State: AFeK/H1TZacX8ftWhwS77eB9H4AY3wpi8jbrzT4XqIQU3hmE1t2zpMFozMNEmZxwtF4Nx5m2SlG11m/4qGvKVw== X-Received: by 10.37.192.2 with SMTP id c2mr12992463ybf.195.1491448084052; Wed, 05 Apr 2017 20:08:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.210.4 with HTTP; Wed, 5 Apr 2017 20:07:33 -0700 (PDT) In-Reply-To: References: <1491334470.3575.9.camel@it.uc3m.es> From: "Mr. Jaehoon Paul Jeong" Date: Thu, 6 Apr 2017 12:07:33 +0900 Message-ID: To: Michelle Wetterwald Cc: CARLOS JESUS BERNARDOS CANO , Russ Housley , its@ietf.org Content-Type: multipart/alternative; boundary=001a113a16b6404ac1054c76d165 Archived-At: Subject: Re: [ipwave] Draft minutes of IPWAVE@IETF98 available 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, 06 Apr 2017 03:08:07 -0000 --001a113a16b6404ac1054c76d165 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, Though IEEE 802.2 LLC is not used by WAVE Protocol Stack, LLC is part of WAVE Networking Services specified by IEEE 1609.3. That is, WAVE LLC is slightly different from IEEE 802.2 LLC. The functions of Networking Services in IEEE 1609.3 are as follows: 1. Data Plane at WAVE Protocol Stack - Logical Link Control (LLC) - IPv6, and transport layer protocols (e.g., TCP and UDP) - WAVE Short Message Protocol (WSMP) Transport protocols/Networking protocols 2. Management Plane at WAVE Management Entity (WME) - Service requests and channel access assignment - WAVE Service Advertisement monitoring - IPv6 configuration - MIB maintenance Thanks. Best Regards, Paul On Wed, Apr 5, 2017 at 7:22 PM, Michelle Wetterwald wrote: > Hi Carlos, > > Thank you very much for these minutes. > > I would like to ask for update on the notes about the survey discussion. > > I think it was said that "802.2 does not exist anymore". rather than > "1609.2 does not exist anymore." > > Best regards, > Michelle > > > > 2017-04-04 21:34 GMT+02:00 Carlos Jes=C3=BAs Bernardos Cano : > >> Hi, >> >> We've just posted the minutes: >> >> https://www.ietf.org/proceedings/98/minutes/minutes-98-ipwave-01 >> >> Please send corrections/comments by Friday, Apr 7th. >> >> Thanks a lot to Danny and Bob for taking the minutes! >> >> Cheers, >> >> Carlos & Russ >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> > > > > -- > Michelle Wetterwald > michelle.wetterwald@gmail.com > > _______________________________________________ > 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 --001a113a16b6404ac1054c76d165 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,
Though IEEE 802.2 LLC is not used by WAVE Prot= ocol Stack,
LLC is part of WAVE Networking Services specified by = IEEE 1609.3.
That is, WAVE LLC is slightly different from IEEE 80= 2.2 LLC.

The functions of Networking Services in I= EEE 1609.3 are as follows:

1. Data Plane at W= AVE Protocol Stack
=C2=A0- Logical Link Control (LLC)
= =C2=A0- IPv6, and transport layer protocols (e.g., TCP and UDP)
= =C2=A0- WAVE Short Message Protocol (WSMP) Transport protocols/Networking p= rotocols

2. Management Plane at WAVE Management En= tity (WME)
=C2=A0- Service requests and channel access assignment=
=C2=A0- WAVE Service Advertisement monitoring
=C2=A0- = IPv6 configuration
=C2=A0- MIB maintenance

Thanks.

Best Regards,
Paul
=C2=A0

On Wed, Apr 5, 2017 at 7:22 PM, Michelle Wetterwald <mlwetterw= ald@gmail.com> wrote:
Hi Carlos,

Thank you very much fo= r these minutes.

I would like to ask for update on= the notes about the survey discussion.

I think it= was said that "802.2 does not exist anymore". rather than "= 1609.2 does not exist anymore."

Best regards,=
Michelle


2017-04-04 21:34= GMT+02:00 Carlos Jes=C3=BAs Bernardos Cano <cjbc@it.uc3m.es>:
Hi,

We've just posted the minutes:

https://www.ietf.org/proceeding= s/98/minutes/minutes-98-ipwave-01

Please send corrections/comments by Friday, Apr 7th.

Thanks a lot to Danny and Bob for taking the minutes!

Cheers,

Carlos & 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




--
=
=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) J= eong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwa= n 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
--001a113a16b6404ac1054c76d165-- From nobody Wed Apr 5 22:52:48 2017 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 9C350128D8B for ; Wed, 5 Apr 2017 22:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WeyOiuWFzZo for ; Wed, 5 Apr 2017 22:52:43 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92FCB128BB6 for ; Wed, 5 Apr 2017 22:52:43 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id i203so15691748ywc.3 for ; Wed, 05 Apr 2017 22:52:43 -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=QEzRb4oCgCw/CHEtu0EF2a1ShTQBhg7xyasE0O7kB6c=; b=MdcjcaVZTd9Cd9Qh3wZM/jnsFvLTbkQVoQ9kYz7p9quyxq63c/eiEJ++6avV6dBS3/ 3Ir/1FYCQc0syBzIA5ldSpdGdSsNIHLF4Of5IW3tOc0u6cL9Qcc1yIkJd/LBMWZZmUNY sE+IGYaowmNPHpTotUr4Vv0CKRoB9SNz/SSdK6J8mgIPmijtvIO35DGtwACXHnUW53Dz +Xq90Yvu/5WsVIOlQpn4hXpecvwqdfErlc9o6m6U5a4DB/dV1GfiJcBQyENxT/rME04O de/4Ur2M4gEIxFrgSDfy9DUtj5IJuMbug32is1v96Zy/S1/crTXfqAUmi6EE8GLcFgP1 px4Q== 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=QEzRb4oCgCw/CHEtu0EF2a1ShTQBhg7xyasE0O7kB6c=; b=UOh+HNw7lX/iiLEUFPp0Qv23u7J5lTri776GyDLCb+ZVcFr0kX0NGxIqd+0Xbj2GyM 9gSe4qNQuh1uqxf/RrYIgZm5+DB2FWNJ4e+RSFlFiV8TvjgbZbsx+pojEShlOzjPsR66 /XC7Bgz6piHAzbmLxjFNsh6Ib9VAP4/Q8piFLADk/dty6rIggxXgzN2TqL/Rcha5Rxww gLQO5R/TLvslWgO12gk0mQtcWEvr5i5mR1ZlPS9mH1cVHXLyj9zmjNiBf/srg3U4Ammg f4JPNaVb1Jh6CNQ6ROKztRU/DY2Lwv0TeIUiwYxDDjYf98DZYKdTHCmFEtReKAe/Pgi4 PD1g== X-Gm-Message-State: AFeK/H13XpgDMbFmb3hP3WKL+J8dJ/j4+HqcJi9kruc502OacWqL+VyJBx65pMz8r8uBc0XWalJi/mUCPkkobg== X-Received: by 10.13.222.66 with SMTP id h63mr21522222ywe.347.1491457962558; Wed, 05 Apr 2017 22:52:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.234.200 with HTTP; Wed, 5 Apr 2017 22:52:12 -0700 (PDT) In-Reply-To: <4BE1CC94247D4E2791FB831B50E2BEFA@SRA6> References: <1491334470.3575.9.camel@it.uc3m.es> <4BE1CC94247D4E2791FB831B50E2BEFA@SRA6> From: "Mr. Jaehoon Paul Jeong" Date: Thu, 6 Apr 2017 14:52:12 +0900 Message-ID: To: Richard Roy Cc: Michelle Wetterwald , Russ Housley , its@ietf.org, CARLOS JESUS BERNARDOS CANO Content-Type: multipart/alternative; boundary=94eb2c07d6400e4985054c791ea8 Archived-At: Subject: Re: [ipwave] Draft minutes of IPWAVE@IETF98 available 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, 06 Apr 2017 05:52:47 -0000 --94eb2c07d6400e4985054c791ea8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Dick, Thanks for this clarification. It will be helpful. Best Regards, Paul On Thu, Apr 6, 2017 at 2:44 PM, Dick Roy wrote: > WAVE LLC is not =E2=80=9Cslightly=E2=80=9D different than 802.2 LLC, it i= s NOT compatible > with it. It could not be more different. Do not confuse the Logical Lin= k > Control (LLC) sublayer with the protocols used therein. There are > essentially two; EPD and LPD (see IEEE Std802). > > > > Also, there are 1609 transport layer services that you should not forget! > See IEEE 1609.3-2016 or its ISO equivalent (which has a few more transpor= t > layer and network layer functions defined). > > > > Hope this is helpful =E2=80=A6 > > > RR > > > > > ------------------------------ > > *From:* its [mailto:its-bounces@ietf.org] *On Behalf Of *Mr. Jaehoon Paul > Jeong > *Sent:* Wednesday, April 5, 2017 8:08 PM > *To:* Michelle Wetterwald > *Cc:* Russ Housley; its@ietf.org; CARLOS JESUS BERNARDOS CANO > *Subject:* Re: [ipwave] Draft minutes of IPWAVE@IETF98 available > > > > Hi all, > > Though IEEE 802.2 LLC is not used by WAVE Protocol Stack, > > LLC is part of WAVE Networking Services specified by IEEE 1609.3. > > That is, WAVE LLC is slightly different from IEEE 802.2 LLC. > > > > The functions of Networking Services in IEEE 1609.3 are as follows: > > > > 1. Data Plane at WAVE Protocol Stack > > - Logical Link Control (LLC) > > - IPv6, and transport layer protocols (e.g., TCP and UDP) > > - WAVE Short Message Protocol (WSMP) Transport protocols/Networking > protocols > > > > 2. Management Plane at WAVE Management Entity (WME) > > - Service requests and channel access assignment > > - WAVE Service Advertisement monitoring > > - IPv6 configuration > > - MIB maintenance > > > > Thanks. > > > > Best Regards, > > Paul > > > > > > On Wed, Apr 5, 2017 at 7:22 PM, Michelle Wetterwald < > mlwetterwald@gmail.com> wrote: > > Hi Carlos, > > > > Thank you very much for these minutes. > > > > I would like to ask for update on the notes about the survey discussion. > > > > I think it was said that "802.2 does not exist anymore". rather than > "1609.2 does not exist anymore." > > > > Best regards, > > Michelle > > > > > > 2017-04-04 21:34 GMT+02:00 Carlos Jes=C3=BAs Bernardos Cano : > > Hi, > > We've just posted the minutes: > > https://www.ietf.org/proceedings/98/minutes/minutes-98-ipwave-01 > > Please send corrections/comments by Friday, Apr 7th. > > Thanks a lot to Danny and Bob for taking the minutes! > > Cheers, > > Carlos & Russ > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > -- > > Michelle Wetterwald > > michelle.wetterwald@gmail.com > > > _______________________________________________ > 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 --94eb2c07d6400e4985054c791ea8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dick,
Thanks for this clarification.
It w= ill be helpful.

Best Regards,
Paul
=

On Thu, Apr= 6, 2017 at 2:44 PM, Dick Roy <dickroy@alum.mit.edu> wrot= e:

WAVE LLC is not = =E2=80=9Cslightly=E2=80=9D different than 802.2 LLC, it is NOT compatible with it.=C2=A0 It could not = be more different.=C2=A0 Do not confuse the Logical Link Control (LLC) sublayer wit= h the protocols used therein.=C2=A0 There are essentially two; EPD and LPD (see I= EEE Std802).

=C2=A0

Also, there are 16= 09 transport layer services that you should not forget! See IEEE 1609.3-2016 or its ISO equiva= lent (which has a few more transport layer and network layer functions defined).=

=C2=A0

Hope this is helpf= ul =E2=80=A6


RR

=C2=A0

=C2=A0

From: its [mailto:its-bounc= es@ietf.org] On Behalf Of Mr. Jaehoon Paul Jeong
Sent: Wednesday, April 5, 20= 17 8:08 PM
To: Michelle Wetterwald
Cc: Russ Housley; its@ietf.org; CARLOS JESUS BERNARDOS CANO
Subject: Re: [ipwave] Draft minutes of IPWAVE@IETF98 available

=C2=A0

Hi all,

Though IEEE 802.2 LLC is not used by WAVE Protocol S= tack,

LLC is part of WAVE Networking Services specified by= IEEE 1609.3.

That is, WAVE LLC is slightly different from IEEE 80= 2.2 LLC.

=C2=A0

The functions of Networking Services in IEEE 1609.3 = are as follows:

=C2=A0

1. Data Plane at WAVE Protocol Stack

=C2=A0- Logical Link Control (LLC)

=C2=A0- IPv6, and transport layer protocols (e.g., T= CP and UDP)

=C2=A0- WAVE Short Message Protocol (WSMP) Transport protocols/Networking protocols

=C2=A0

2. Management Plane at WAVE Management Entity (WME)<= u>

=C2=A0- Service requests and channel access assignme= nt

=C2=A0- WAVE Service Advertisement monitoring=

=C2=A0- IPv6 configuration

=C2=A0- MIB maintenance<= /p>

=C2=A0

Thanks.

=C2=A0

Best Regards,

Paul

=C2=A0

=C2=A0

On Wed, Apr 5, 2017 at 7:22 PM, Michelle Wetterwald = <mlwetterwal= d@gmail.com> wrote:

Hi Carlos,

=C2=A0

Thank you very much for these minutes.=

=C2=A0

I would like to ask for update on the notes about th= e survey discussion.

=C2=A0

I think it was said that "802.2 does not exist = anymore". rather than "1609.2 does not exist anymore."=

=C2=A0

Best regards,

Michelle

=C2=A0

=C2=A0

2017-04-04 21:34 GMT+02:00 Carlos Jes=C3=BAs Bernard= os Cano <cjbc@it.uc= 3m.es>:

Hi,

We've just posted the minutes:

https://www.ietf.org/proceedings/98/minutes/minute= s-98-ipwave-01

Please send corrections/comments by Friday, Apr 7th.

Thanks a lot to Danny and Bob for taking the minutes!

Cheers,

Carlos & Russ

_______________________________________________
its mailing list
its@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/its=



--

Michelle Wetterwald<= /span>


_______________________________________________
its mailing list
its@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/its=



=C2=A0

--

=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<= /a>




--
--94eb2c07d6400e4985054c791ea8-- From nobody Thu Apr 6 04:44:01 2017 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 61CBF128896 for ; Thu, 6 Apr 2017 04:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 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, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifmVuXzPY9xd for ; Thu, 6 Apr 2017 04:43: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 ECC571293E9 for ; Thu, 6 Apr 2017 04:43: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 v36BhrsJ031272; Thu, 6 Apr 2017 13:43:53 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DE15C203006; Thu, 6 Apr 2017 13:43:53 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CC1FC202934; Thu, 6 Apr 2017 13:43:53 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v36Bhri5031241; Thu, 6 Apr 2017 13:43:53 +0200 To: dickroy@alum.mit.edu, cjbc@it.uc3m.es, its@ietf.org References: <1491334470.3575.9.camel@it.uc3m.es> <8057466055914FB89C1597E66E42926B@SRA6> Cc: "'Russ Housley'" From: Alexandre Petrescu Message-ID: <4d8204ff-44d5-ff3c-9c2f-3b54a90ace9a@gmail.com> Date: Thu, 6 Apr 2017 13:43:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8057466055914FB89C1597E66E42926B@SRA6> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Draft minutes of IPWAVE@IETF98 available 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, 06 Apr 2017 11:44:00 -0000 Dick, Le 05/04/2017 à 01:40, Dick Roy a écrit : > All, > > These are comments only, as I was not present at the meeting. > > 1) While there are such things as IEEE 802.11 beacons, they are NOT > sent when dot11OCBActivated is true. Agreed. The text is so too. > 2) IEEE Std1609.2 DOES exist. > > 3) I would definitely NOT call the LLC sublayer "interface" between > the 802.11 MAC and the IPv6 networking layer SNAP. SNAP is on its > way out, along with all the other 802.2 LLC functionality, AND most > importantly, communications in the 5.9GHz in the US use type > encoding (EPD if you are an IEEE Std802 O&M fan). Call it what it > is: "EPD". Ok, we will keep the "EPD" layer in the figure. Additionally, as presented in Chicago (slide 4), and based on your SNAP comment above, I suggest the following SNAP text below: > In addition to the description of interface between IP and MAC using > "Ethernet Adaptation Layer" and "Ethernet Protocol Discrimination > (EPD)" it is worth mentioning that SNAP [RFC1042] was used earlier to > carry the IPv6 Ethertype. [...] > 4) No single set of standards is going to "resolve the privacy > concern". Privacy is a system concept the takes a lot of effort at > every layer in the system to properly implement. > > 5) STAs operating OCB are NOT STAs operating in ad hoc mode; thus, > OCB STAs should not be labeled as ad hoc STAs. Agreed. OCB STAs will be labeled just "STA". Alex > > Hope this helps. > > RR > > PS. Alex, I don't believe the reflector problem has been resolved > yet, so forward this if you feel it's appropriate. > > > -----Original Message----- From: its [mailto:its-bounces@ietf.org] > On Behalf Of Carlos Jesús Bernardos Cano Sent: Tuesday, April 4, > 2017 12:35 PM To: its@ietf.org Cc: Russ Housley Subject: [ipwave] > Draft minutes of IPWAVE@IETF98 available > > Hi, > > We've just posted the minutes: > > https://www.ietf.org/proceedings/98/minutes/minutes-98-ipwave-01 > > Please send corrections/comments by Friday, Apr 7th. > > Thanks a lot to Danny and Bob for taking the minutes! > > Cheers, > > Carlos & Russ > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From nobody Thu Apr 6 20:14:38 2017 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 A0AA3127449 for ; Thu, 6 Apr 2017 20:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 xFx0lsHIm4v5 for ; Thu, 6 Apr 2017 20:14:33 -0700 (PDT) Received: from mail228-169.sinamail.sina.com.cn (mail228-169.sinamail.sina.com.cn [60.28.228.169]) by ietfa.amsl.com (Postfix) with SMTP id 8BEFB127058 for ; Thu, 6 Apr 2017 20:14:32 -0700 (PDT) Received: from webmail-2-150.pop3.fmail.tg.sinanode.com (HELO webmail.sinamail.sina.com.cn)([172.16.201.150]) by sina.com with SMTP 7 Apr 2017 11:14:30 +0800 (CST) X-Sender: langziwumingzhimi@sina.com X-SMAIL-MID: 47006960031065 Received: by webmail.sinamail.sina.com.cn (Postfix, from userid 496) id 57DD1C80853; Fri, 7 Apr 2017 11:14:30 +0800 (CST) Date: Fri, 07 Apr 2017 11:14:30 +0800 Received: from langziwumingzhimi@sina.com([221.130.253.135]) by m0.mail.sina.com.cn via HTTP; Fri, 07 Apr 2017 11:14:30 +0800 (CST) Reply-To: langziwumingzhimi@sina.com From: To: "its" Cc: "Russ Housley" , "cjbc" MIME-Version: 1.0 X-Priority: 3 X-MessageID: 58e70416c9753a2 X-Originating-IP: [172.16.201.150] X-Mailer: Sina WebMail 4.0 Content-Type: multipart/alternative; boundary="=-sinamail_alt_d87cde9804ed807752a84c57e3dbeb74" Message-Id: <20170407031430.57DD1C80853@webmail.sinamail.sina.com.cn> Archived-At: Subject: [ipwave] =?gbk?b?u9i4tKO6IERyYWZ0IG1pbnV0ZXMgb2YgSVBXQVZFQElFVEY5?= =?gbk?q?8_available?= 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, 07 Apr 2017 03:14:37 -0000 --=-sinamail_alt_d87cde9804ed807752a84c57e3dbeb74 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksSSBmb3VuZCBteSBjb21tZW50IGlzIG1pc3NlZCBpbiB0aGUgbWludXRlcy4gCkZvciBTdXJ2 ZXkgb24gSVAtYmFzZWQgVmVoaWN1bGFyIE5ldHdvcmtpbmcgZm9yIElUUywgSSBoYXZlIGNvbW1l bnQgb24gaXRzIGFzc3VtcHRpb24uIEkgcG9pbnQgb3V0IHRoYXQgSUVFRSA4MDIuMTFwIGlzIGNv bnNpZGVyZWQgYXMgTUFDIHByb3RvY29sIGJ1dCBOT1QgT05MWSBvbmUgdG8gYmUgY29uc2lkZXJl ZC4gIEFuZCBJIHJlbWVtYmVyZWQgSm9obiByZXNwb25kZWQgdGhhdCBoZSB3aWxsIGludm9sdmUg b3RoZXJzIGludG8gZHJhZnQuCkJScyxNaW5wZW5nCgotLS0tLSDljp/lp4vpgq7ku7YgLS0tLS0K 5Y+R5Lu25Lq677yaQ2FybG9zIEplc8O6cyBCZXJuYXJkb3MgQ2FubyA8Y2piY0BpdC51YzNtLmVz PgrmlLbku7bkurrvvJppdHNAaWV0Zi5vcmcK5oqE6YCB5Lq677yaUnVzcyBIb3VzbGV5IDxob3Vz bGV5QHZpZ2lsc2VjLmNvbT4K5Li76aKY77yaW2lwd2F2ZV0gRHJhZnQgbWludXRlcyBvZiBJUFdB VkVASUVURjk4IGF2YWlsYWJsZQrml6XmnJ/vvJoyMDE35bm0MDTmnIgwNeaXpSAwM+eCuTM05YiG CgoKSGksCldlJ3ZlIGp1c3QgcG9zdGVkIHRoZSBtaW51dGVzOgpodHRwczovL3d3dy5pZXRmLm9y Zy9wcm9jZWVkaW5ncy85OC9taW51dGVzL21pbnV0ZXMtOTgtaXB3YXZlLTAxClBsZWFzZSBzZW5k IGNvcnJlY3Rpb25zL2NvbW1lbnRzIGJ5IEZyaWRheSwgQXByIDd0aC4KVGhhbmtzIGEgbG90IHRv IERhbm55IGFuZCBCb2IgZm9yIHRha2luZyB0aGUgbWludXRlcyEKQ2hlZXJzLApDYXJsb3MgJiBS dXNzCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCml0cyBt YWlsaW5nIGxpc3QKaXRzQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaXRzCg== --=-sinamail_alt_d87cde9804ed807752a84c57e3dbeb74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5IaSw8L2Rpdj48ZGl2PkkgZm91bmQgbXkgY29tbWVudCBpcyBtaXNzZWQgaW4gdGhlIG1p bnV0ZXMuJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Gb3ImbmJzcDs8c3BhbiBzdHls ZT0id2hpdGUtc3BhY2U6IHByZS13cmFwOyI+U3VydmV5IG9uIElQLWJhc2VkIFZlaGljdWxhciBO ZXR3b3JraW5nIGZvciBJVFM8L3NwYW4+LCBJIGhhdmUgY29tbWVudCBvbiBpdHMgYXNzdW1wdGlv bi4gSSBwb2ludCBvdXQgdGhhdCBJRUVFIDgwMi4xMXAgaXMgY29uc2lkZXJlZCBhcyBNQUMgcHJv dG9jb2wgYnV0IE5PVCBPTkxZIG9uZSB0byBiZSBjb25zaWRlcmVkLiAmbmJzcDtBbmQgSSByZW1l bWJlcmVkIEpvaG4gcmVzcG9uZGVkIHRoYXQgaGUgd2lsbCBpbnZvbHZlIG90aGVycyBpbnRvIGRy YWZ0LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QlJzLDwvZGl2PjxkaXY+TWlucGVuZzwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgaWQ9Im9yaWdib2R5Ij48ZGl2IHN0 eWxlPSJiYWNrZ3JvdW5kOiAjZjJmMmYyOyI+LS0tLS0g5Y6f5aeL6YKu5Lu2IC0tLS0tPGJyPuWP keS7tuS6uu+8mkNhcmxvcyBKZXPDunMgQmVybmFyZG9zIENhbm8gJmx0O2NqYmNAaXQudWMzbS5l cyZndDs8YnI+5pS25Lu25Lq677yaaXRzQGlldGYub3JnPGJyPuaKhOmAgeS6uu+8mlJ1c3MgSG91 c2xleSAmbHQ7aG91c2xleUB2aWdpbHNlYy5jb20mZ3Q7PGJyPuS4u+mimO+8mltpcHdhdmVdIERy YWZ0IG1pbnV0ZXMgb2YgSVBXQVZFQElFVEY5OCBhdmFpbGFibGU8YnI+5pel5pyf77yaMjAxN+W5 tDA05pyIMDXml6UgMDPngrkzNOWIhjxicj48L2Rpdj48YnI+PGJyPkhpLDxicj5XZSd2ZSBqdXN0 IHBvc3RlZCB0aGUgbWludXRlczo8YnI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv OTgvbWludXRlcy9taW51dGVzLTk4LWlwd2F2ZS0wMTxicj5QbGVhc2Ugc2VuZCBjb3JyZWN0aW9u cy9jb21tZW50cyBieSBGcmlkYXksIEFwciA3dGguPGJyPlRoYW5rcyBhIGxvdCB0byBEYW5ueSBh bmQgQm9iIGZvciB0YWtpbmcgdGhlIG1pbnV0ZXMhPGJyPkNoZWVycyw8YnI+Q2FybG9zICZhbXA7 IFJ1c3M8YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+aXRzIG1haWxpbmcgbGlzdDxicj5pdHNAaWV0Zi5vcmc8YnI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pdHM8YnI+PC9kaXY+ --=-sinamail_alt_d87cde9804ed807752a84c57e3dbeb74-- From nobody Fri Apr 7 02:46:30 2017 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 43163127011 for ; Fri, 7 Apr 2017 02:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 S_l_rOAKnC0i for ; Fri, 7 Apr 2017 02:46:24 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 A7ADE128ACA for ; Fri, 7 Apr 2017 02:46:24 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id c45so14779907qtb.1 for ; Fri, 07 Apr 2017 02:46:24 -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=+0GOdovK8J/LCXK6H2cJFT7mg47JGOt4UxRoG2He0ro=; b=cLvqTxV502zZQNIsmy23pUfC63RBVwZtiK6/U3rdwFUCybZBut1R21NBB/unHqpH9p wLppEY5B9botp9/lM5u8AD+ng0f1ypYpTIDxXvpwf6DrYk3iHnyJHj39a0buC9ynz1J1 tGsQ8tsd/f20PLkU3fZGBHoKoHIKMXQrPj2IPN0+2oiuhhAt/I2/dOODzGdUu8rxTMYi hkQMBo79jgI9YNlGogpl4GVGInyTka3soMNvWR+WUYP+97G2Tvf4a5sUAjxQHh7xAj3V 6BJdL9kGmJiWgsjjVOfly6gUME9kErilaqFqdGTDhJLw1uw2EFaZLHTgdYQhIEzAG1Pq xlOA== 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=+0GOdovK8J/LCXK6H2cJFT7mg47JGOt4UxRoG2He0ro=; b=Z986Sjmi5WxD75xwse4a6zt9PQCxx7NaTVTJzkpW4u3OAA4tkAUSjwnbYXAEd74mPo 9zfAZiCiDsZPKjEDzT5d8zl2qX07k+NTb38QsB9wa/+LvJYifexUVvv5t+vybykGvAsV +JjUPMwkApY6mR6CSk2WHCwSZZzVI76+jpvoyjm04PQ5+J0lFuWr5ubfQy8TcGps2W4S j+tLK0AO4heb6SK2Me2ZmuoRiHqchwZLFl+9BtDj4FlyrZTZs6HNSXPg+xLEWEmMxRan e8PokdgALfU6aX6Q1rJGUwoJNbRlAyWNDlrGrNnKuLciKgZcDECy447GhvkkX+Mbq5Lc TPyw== X-Gm-Message-State: AFeK/H0ZSTIKOZVgpEgwW1dX1Xh7LMwMp1EgePdwLvwbVljAXSUB5K0CGH/dGN53XZbtDw== X-Received: by 10.237.61.52 with SMTP id g49mr44182172qtf.79.1491558383595; Fri, 07 Apr 2017 02:46:23 -0700 (PDT) Received: from FrancoisPC (pool-108-51-227-221.washdc.fios.verizon.net. [108.51.227.221]) by smtp.gmail.com with ESMTPSA id d30sm2715123qtb.18.2017.04.07.02.46.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 02:46:22 -0700 (PDT) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Mr. Jaehoon Paul Jeong'" Cc: , References: <1491334470.3575.9.camel@it.uc3m.es> In-Reply-To: Date: Fri, 7 Apr 2017 05:46:19 -0400 Message-ID: <049601d2af83$cfa0e390$6ee2aab0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0497_01D2AF62.48929EF0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIxkudGJDk4xJox+nqkh+h/rYz2kgHfCabgAsnhzeKg1pPL8A== Content-Language: en-us Archived-At: Subject: Re: [ipwave] Draft minutes of IPWAVE@IETF98 available 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, 07 Apr 2017 09:46:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0497_01D2AF62.48929EF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0498_01D2AF62.48929EF0" ------=_NextPart_001_0498_01D2AF62.48929EF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Mr. Jaehoon, =20 Please, find my comments on the minutes attached. I was not present at = the meeting. Also find additional comments below. =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Mr. Jaehoon Paul = Jeong Sent: Wednesday, April 05, 2017 11:08 PM To: Michelle Wetterwald Cc: Russ Housley ; its@ietf.org; CARLOS JESUS = BERNARDOS CANO Subject: Re: [ipwave] Draft minutes of IPWAVE@IETF98 available =20 Hi all, Though IEEE 802.2 LLC is not used by WAVE Protocol Stack, LLC is part of WAVE Networking Services specified by IEEE = 1609.3.Fygs:=E2=80=93 Per OSI, LLC is a sub-layer of the Data Link Layer = (it happen to be specified in 1609.3.] That is, WAVE LLC is slightly different from IEEE 802.2 LLC. =E2=80=93 = [Fygs =E2=80=93 Is not =E2=80=9Cslightly=E2=80=9D it is = different=E2=80=9D the LLC in US for 5.9 GHz is EtherType Protocol = Discrimination (EPD]. =20 The functions of Networking Services in IEEE 1609.3 are as follows: =20 1. Data Plane at WAVE Protocol Stack - Logical Link Control (LLC) =E2=80=93 [Fygs: EPD] - IPv6, and transport layer protocols (e.g., TCP and UDP) - WAVE Short Message Protocol (WSMP) Transport protocols/Networking = protocols =20 2. Management Plane at WAVE Management Entity (WME) - Service requests and channel access assignment - WAVE Service Advertisement monitoring - IPv6 configuration - MIB maintenance [Fygs: MIBs are within the Layer Management Entity = (LME) associated with EACH layer] - [Fygs: Security is included in the System = Management Entity (SME)] =20 Thanks. =20 Best Regards, Paul =20 =20 On Wed, Apr 5, 2017 at 7:22 PM, Michelle Wetterwald = > wrote: Hi Carlos, =20 Thank you very much for these minutes. =20 I would like to ask for update on the notes about the survey discussion. =20 I think it was said that "802.2 does not exist anymore". rather than = "1609.2 does not exist anymore." =20 Best regards, Michelle =20 =20 2017-04-04 21:34 GMT+02:00 Carlos Jes=C3=BAs Bernardos Cano = >: Hi, We've just posted the minutes: https://www.ietf.org/proceedings/98/minutes/minutes-98-ipwave-01 Please send corrections/comments by Friday, Apr 7th. Thanks a lot to Danny and Bob for taking the minutes! Cheers, Carlos & Russ _______________________________________________ its mailing list its@ietf.org =20 https://www.ietf.org/mailman/listinfo/its --=20 Michelle Wetterwald michelle.wetterwald@gmail.com =20 _______________________________________________ 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 ------=_NextPart_001_0498_01D2AF62.48929EF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Mr. Jaehoon,

 

Please, find my comments on the minutes attached.=C2=A0 I was not = present at the meeting.=C2=A0 Also find additional comments = below.

 

From:<= /b> = its [mailto:its-bounces@ietf.org] On Behalf Of Mr. Jaehoon Paul = Jeong
Sent: Wednesday, April 05, 2017 11:08 PM
To: = Michelle Wetterwald <mlwetterwald@gmail.com>
Cc: Russ = Housley <housley@vigilsec.com>; its@ietf.org; CARLOS JESUS = BERNARDOS CANO <cjbc@it.uc3m.es>
Subject: Re: [ipwave] = Draft minutes of IPWAVE@IETF98 available

 

Hi = all,

Though IEEE 802.2 LLC is = not used by WAVE Protocol Stack,

LLC is part of WAVE Networking Services specified by = IEEE 1609.3.Fygs:=E2=80=93 Per OSI, LLC is = a sub-layer of the Data Link Layer (it happen to be specified in = 1609.3.]

That is, = WAVE LLC is slightly different from IEEE 802.2 LLC. =E2=80=93 [Fygs =E2=80=93 Is not = =E2=80=9Cslightly=E2=80=9D it is different=E2=80=9D the LLC in US for = 5.9 GHz is EtherType Protocol Discrimination = (EPD].

 

The functions of Networking Services in IEEE 1609.3 = are as follows:

 

1. Data Plane at WAVE Protocol = Stack

 - Logical Link = Control (LLC) =E2=80=93 [Fygs: = EPD]

 - IPv6, = and transport layer protocols (e.g., TCP and = UDP)

 - WAVE Short = Message Protocol (WSMP) Transport protocols/Networking = protocols

 

2. Management Plane at WAVE Management Entity = (WME)

 - Service = requests and channel access assignment

 - WAVE Service Advertisement = monitoring

 - IPv6 = configuration

 - MIB = maintenance [Fygs: MIBs are within the = Layer Management Entity (LME) associated with EACH = layer]

-           = ;           = [Fygs: Security is included in = the System Management Entity = (SME)]

 

Thanks.

 

Best Regards,

Paul

 

 

On Wed, = Apr 5, 2017 at 7:22 PM, Michelle Wetterwald <mlwetterwald@gmail.com> = wrote:

Hi Carlos,

 

Thank you very much for these = minutes.

 

I = would like to ask for update on the notes about the survey = discussion.

 

I = think it was said that "802.2 does not exist anymore". rather = than "1609.2 does not exist = anymore."

 

Best regards,

Michelle

 
 
2017-04-04 21:34 GMT+02:00 Carlos Jes=C3=BAs Bernardos =
Cano <cjbc@it.uc3m.es>:
Hi,

We've just posted the minutes:

https://www.ietf.org/proceedings/98/minutes/minutes-98-=
ipwave-01

Please send corrections/comments by Friday, Apr =
7th.

Thanks a lot to Danny and Bob for taking the =
minutes!

Cheers,

Carlos & =
Russ

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


-- =

Michelle =
Wetterwald


______________________________________= _________
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

------=_NextPart_001_0498_01D2AF62.48929EF0-- ------=_NextPart_000_0497_01D2AF62.48929EF0 Content-Type: text/plain; name="IPWAVE_MINUTES_COMMENTS_040717.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="IPWAVE_MINUTES_COMMENTS_040717.txt" 04/07/17 [Fygs: Comments] [Indicated below item as [fygs:.......] Minutes of the IPWAVE WG meeting at IETF 98 FRIDAY, March 31, 2017 0900-1130 Morning Session I, Zurich E/F Chairs: Russ Housley, Carlos J. Bernardos Minute takers: Danny Moses, Robert Moskowitz Jabber scribe: Robert Sparks 09:00 Administrativia Presenter: Chairs - Note-Well, Blue Sheets, Scribes. - Agenda run-through; no bashes. - Status update: one WG document, two milestone documents not yet with a WG document adopted. ** IPWAVE WG documents 09:10 Transmission of IPv6 Packets over IEEE 802.11 Networks in mode=20 Outside the Context of a Basic Service Set (IPv6-over-80211ocb) Presenter: Alex Petrescu (AP) Draft: draft-ietf-ipwave-ipv6-over-80211ocb This is currently the only WG adopted document (adopted in Seoul). Issues solved seeking confirmation from the WG: - New figures - Ethernet adaptation layer, and interface between the = IPv6 and MAC as seen by IEEE. - Propose to call the interface SNAP. [Fygs: This is a Service Access Point (SAP). I does not necessary = implies an interface] - Add the 802.11 Trailer (Frame Check Sequence) to the Ethernet = Adaptation Layer. [Fygs: Would it be CRC and not FCS?] - The =93Address Mapping =96 Unicast=94 section is empty. The reason = for that is that the authors are waiting for RFC2464bis to be more = advanced. * Bob Hinden (BH): (editor of 2464bis) yes, the draft is in working, = will look at the issues being raised. * Bob Moskowitz (BM): have at 1609 to resolve the privacy concern.=20 * Suresh Krishnan (SK), area director: this section should discuss = how IP addressed are created using MAC addresses. The text (that Alex = thought is confusing) is correct, but not necessary (or relevant). - IPv6 prohibition status. * Michelle Wetterwald (MW): some channels are used for safety = message only so change the text accordingly (without indicating = specifically which channels prohibit IPv6. [Fygs: From the 802.11 OCB MAC and PHY there is no restrictions on = IPv6 on any channel]=20 * BM: channel utilization is national-specific and there are various = geos. So propose to use the term =91national channels=92 and refer to = national-specific channel utilization docs. [Fygs: why not use the recognized internation term of "bearer = channels"?] - RSU -- Road Side Unit -- this is the term that was select (there = were other suggestions). * Carlos J. Bernardos (CB): prefers the term 'Router'. * Andrew: yes, I like =91Router=92 here. Fygs: [Fygs: RSU as defined does not support router functions; = period] * Georg: RSU is used in 3GPP for other means, so make sure there is = no confusion.=20 - The rest of the issues were resolved -- not seeking confirmation. - Multi-channel issue -- recommendation to handle multi-channel in = another document. - Handovers -- likewise -- write another document. * Russ Housley (RH): add a reference for IP security layer. - TCLAS -- mapping from/to IPv6 Traffic Class field -- likewise -- = another document - Certificates -- another doc * SK, as AD: but the WG is not chartered to write more documents. = Either re-charter or=20 - ETSI CAM and IP -- removed the appendix about non-IP communication. - Privacy -- refer in function addressed in IEEE 1609.3 clause 5.5.1 = and IEEE 1609.4 clause 6.7. * BM: add the year of the spec. * MW: +1 for removing the appendix. - Improved privacy paragraph. Emphasis on the issue of being = tracked... - New figures -- showing message flows of IEEE802.11 and 802.11 OCB = (the OCB figure is the new one). * RH: figure (a) does not show bidirectional messages (should be = fixed). * BM: AP should be changed to STA (in ad-hoc mode). [Fygs: OCB is not ad-hoc mode] * BM: does this figure have any value. * AP: yes for fast readers. * BM: sow add in SS mode (figure a). * Dorothy Stanley (DS): figure a is infrastructure mode (and then, = AP is correct). - EtherType -- add a description of what the bit string means: = EtherType 0x86DD. - 802.11 OCB and Beacons. * DS: there are IEEE Beacons -- fix the text. - Multiple interfaces -- added text referencing RFC5648. * SK: why is it useful? I prefer the previous text. * AP: OK. RH, as chair: The draft should be ready for WGLC before Prague. Please = pick up the paste. ** IPWAVE charter related items. 09:35 Survey on IP-based Vehicular Networking for ITS Presenter: J. Jeong (JJ) Draft: draft-jeong-ipwave-vehicular-networking-survey-02 This is about a survey. - Updates section 4.4 (cross-layer identities management in ITS = stations) and section 9 (standard activities about vehicular networks). - Describe objectives, assumptions on Vehicular NWs, the different = categories and various standard activities. - IEEE 1609 -- a suite of standards for WAVE. - Provide a high-level for the various 1609 specs. * BM: 1609.2 does not exist anymore. [Fygs: 1609.2 IS ALIVE AND LIVING IN 1609 SERIES - Security] - Describe ETSI ITS specs. - Describe ISO ITS specs. - Next steps: Requests adoption by the WG as a "ITS General Problem = Area". * AP: Is there a charter for ITS General Problem Area? * JJ: yes. * AP: so I support the adoption. * CB, as chair: How many people read the doc? About 5.=20 * CB, as chair: Need additional people to read the doc before an = adoption call. 09:50 Problem Statement for Vehicle-to-Infrastructure Networking Presenter: J. Jeong Draft: draft-jeong-ipwave-v2i-problem-statement-00 - Updated the security and privacy sections - The draft discuss Vehicle to infrastructure networking: Objective = and assumption of V2I. - Authentication and access control, Periodic change of MAC and IP = addresses and Confidential data exchange - Plans to merge with the V2V Problem Statement draft = (draft-petrescu-its-problem). - Next steps: Requests adoption by the WG as a "Problem statement". * CB, as chair: How many people read the doc? About 5.=20 * CB, as chair: Need additional people to read the doc before an = adoption call. ------=_NextPart_000_0497_01D2AF62.48929EF0-- From nobody Fri Apr 7 02:53:50 2017 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 938ED1200DF for ; Fri, 7 Apr 2017 02:53:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 qUcBFoTn2pqP for ; Fri, 7 Apr 2017 02:53:46 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AECA12783A for ; Fri, 7 Apr 2017 02:53:46 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id c45so14886183qtb.1 for ; Fri, 07 Apr 2017 02:53:46 -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:content-transfer-encoding:thread-index :content-language; bh=+dszM1/kxSxQjk0HQ/rsTIkBcI4efWB2XrewJfQYdgA=; b=jRRfUkgofDsGc27i9PoJHXIHdKfI5hHwhy8c1DTlosRfgCHSFoUCvZIKMehoUODjNB coWfdLFP8FsMc3M2XvwDKYfokkLqFQmIcVBSiOqdxMJoO07td89DHkCNbJHEiXsb+C0x lLDRYS3COiny28/CsQUVXa5WgXHk1g/jm3DGgTE8d0Y2gxxLBqw8QVEc3rgqsPl4GJ0A j9mI/UBzN8onxEx3uO3/5WPNCOl2+ndaSGFBnSTVD8e0Gjcda3/Q5OqnGzTFqv53xPvs H4PYDIaFFH4NHTymA6FWm1Tkni9lZatBMGQCaqjEIC7/uncv0Bgym+QWE6nuSwAH1Maa kJ1A== 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:content-transfer-encoding:thread-index :content-language; bh=+dszM1/kxSxQjk0HQ/rsTIkBcI4efWB2XrewJfQYdgA=; b=mn70tsI24a1en5Pb1Fa3Y76WKXoSGR6HSakM5uSstGfq6zDmoDA+FzsQolAwzoF9Zp JHGR4u/GZroZgEnOt6YY54DO0XrbVOMZH/dn/1QWVPdsJfBWij5scvLr0QmZvtMx7C5X H81R7L/Rjf8kVLhBtPB3Cfif93bOYG+r85KvPPdnNMW05D5FJ4CWiQUgLepn2EIHZUQu HzAmOSt5A0JRPqwzcdD9r3B3QA6DeICB4UOtgnKsB66ZqjwJw+TTwG6W86eNrU2RR32+ jaLZAHS4wS48cbtxgu+BGeEZpy8HKkBHx/zxhygjorUoDD0Tj3SeQqmT9TrhHAz/Pcqu vdQg== X-Gm-Message-State: AFeK/H14s+hDK5siabObJHAi6gmMDGEAY/3TnqSiwaCm8QbqUHPRQ6rFt0OKk9mJ2C/qng== X-Received: by 10.200.50.165 with SMTP id z34mr38016040qta.205.1491558825255; Fri, 07 Apr 2017 02:53:45 -0700 (PDT) Received: from FrancoisPC (pool-108-51-227-221.washdc.fios.verizon.net. [108.51.227.221]) by smtp.gmail.com with ESMTPSA id i140sm2714793qke.22.2017.04.07.02.53.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 02:53:44 -0700 (PDT) From: =?iso-8859-1?Q?Fran=E7ois_Simon?= To: "'Alexandre Petrescu'" , , , , Cc: "'Russ Housley'" References: <1491334470.3575.9.camel@it.uc3m.es> <8057466055914FB89C1597E66E42926B@SRA6> <4d8204ff-44d5-ff3c-9c2f-3b54a90ace9a@gmail.com> In-Reply-To: <4d8204ff-44d5-ff3c-9c2f-3b54a90ace9a@gmail.com> Date: Fri, 7 Apr 2017 05:53:41 -0400 Message-ID: <000201d2af84$d7222a10$85667e30$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIxkudGJDk4xJox+nqkh+h/rYz2kgJU2rCcAk9/94ag1sDDMA== Content-Language: en-us Archived-At: Subject: Re: [ipwave] Draft minutes of IPWAVE@IETF98 available 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, 07 Apr 2017 09:53:50 -0000 Agree with all Dr. Roy's comments. Fygs -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Thursday, April 06, 2017 7:44 AM To: dickroy@alum.mit.edu; cjbc@it.uc3m.es; its@ietf.org Cc: 'Russ Housley' Subject: Re: [ipwave] Draft minutes of IPWAVE@IETF98 available Dick, Le 05/04/2017 =E0 01:40, Dick Roy a =E9crit : > All, > > These are comments only, as I was not present at the meeting. > > 1) While there are such things as IEEE 802.11 beacons, they are NOT=20 > sent when dot11OCBActivated is true. Agreed. The text is so too. > 2) IEEE Std1609.2 DOES exist. > > 3) I would definitely NOT call the LLC sublayer "interface" between=20 > the 802.11 MAC and the IPv6 networking layer SNAP. SNAP is on its way = > out, along with all the other 802.2 LLC functionality, AND most=20 > importantly, communications in the 5.9GHz in the US use type encoding=20 > (EPD if you are an IEEE Std802 O&M fan). Call it what it > is: "EPD". Ok, we will keep the "EPD" layer in the figure. Additionally, as presented in Chicago (slide 4), and based on your SNAP comment above, I suggest the following SNAP text below: > In addition to the description of interface between IP and MAC using=20 > "Ethernet Adaptation Layer" and "Ethernet Protocol Discrimination=20 > (EPD)" it is worth mentioning that SNAP [RFC1042] was used earlier to=20 > carry the IPv6 Ethertype. [...] > 4) No single set of standards is going to "resolve the privacy=20 > concern". Privacy is a system concept the takes a lot of effort at=20 > every layer in the system to properly implement. > > 5) STAs operating OCB are NOT STAs operating in ad hoc mode; thus, OCB = > STAs should not be labeled as ad hoc STAs. Agreed. OCB STAs will be labeled just "STA". Alex > > Hope this helps. > > RR > > PS. Alex, I don't believe the reflector problem has been resolved=20 > yet, so forward this if you feel it's appropriate. > > > -----Original Message----- From: its [mailto:its-bounces@ietf.org] On=20 > Behalf Of Carlos Jes=FAs Bernardos Cano Sent: Tuesday, April 4, > 2017 12:35 PM To: its@ietf.org Cc: Russ Housley Subject: [ipwave]=20 > Draft minutes of IPWAVE@IETF98 available > > Hi, > > We've just posted the minutes: > > https://www.ietf.org/proceedings/98/minutes/minutes-98-ipwave-01 > > Please send corrections/comments by Friday, Apr 7th. > > Thanks a lot to Danny and Bob for taking the minutes! > > Cheers, > > Carlos & Russ > > _______________________________________________ its mailing list=20 > 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 7 10:13:04 2017 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 EF8DE129505 for ; Fri, 7 Apr 2017 10:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FILL_THIS_FORM=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 pn1cUiYfR6PN for ; Fri, 7 Apr 2017 10:12:55 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 00BCA12942F for ; Fri, 7 Apr 2017 10:12:54 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id f133so51002394qke.2 for ; Fri, 07 Apr 2017 10:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version:thread-index :content-language; bh=ftO0zPT0F2Xp4m5e3xFDdW4xJIegwzRhEFWG6b/Rr+k=; b=A5Sqw1e7f5EYB0ZxV41a8hpp6OZ6SXHzvbSU/341qFQRBaugAdcLb6A567qvkakcbr DSAiDnKrEqnfzsqaWneIWD8h2ou4LbNn37uVthPZd0lFyFo7PEFQkPZv0tUhmEIdboUQ NWPF5WhZX0ondN8KcDzIKEufGZWgls0wSEVDzr4oJwLtlJc4icPCjkjzg1LaRUK/W0/A z5xB1WVzyYhHlsOfFxdeTSLcfleRfDncDx47rE79XSEul8NcIfdiPqYnmOHO8OioDGZ5 xB1/l9VgPr7E6ba2MeWreSOxBLdZQbyRU8BRqaXFNqvq7HPwM6FKar7xu4mblB0Lbz9y G+iQ== 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:subject:date:message-id:mime-version :thread-index:content-language; bh=ftO0zPT0F2Xp4m5e3xFDdW4xJIegwzRhEFWG6b/Rr+k=; b=PdKCKf2VDrn6vO86d+Q7WGXAD3Ou9cFUNIoX7Kl3xdk6emYC+MoIMPMLFF/+3570l6 xpIn/j++lg2ItJatMAKyG86FFKESzofbBuUJsUDJtFVdWBHjkl+6xbmUeGXViWNIQ7a4 eHfzHTowAmT3B3ywRZygdH5wwyI6ndhjek/6qGSwKtwAOaiJ92nbfMQJxL2AW9odk4vg nJqjwb+VHcPHs6DF8/dg/ceJdFtdeFx7BBMD+b4474gisZfGpoGTcRjiR3NkXx6NCitc FVYT0yLig2njo40vFDDkW7HjVGdhPZvo+hIXFGbfXGhqfMF+qM6SiXx1mHhRH64LWijL Gctw== X-Gm-Message-State: AFeK/H0kYNKVg5qQXclvdMrataHc/QVPnZrGuaDCooPoE7IQUW3pa9PnHcmDNJUHcQs1PQ== X-Received: by 10.55.75.70 with SMTP id y67mr37957313qka.153.1491585174199; Fri, 07 Apr 2017 10:12:54 -0700 (PDT) Received: from FrancoisPC (pool-108-51-227-221.washdc.fios.verizon.net. [108.51.227.221]) by smtp.gmail.com with ESMTPSA id 137sm521845qkd.48.2017.04.07.10.12.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 10:12:52 -0700 (PDT) From: =?iso-8859-1?Q?Fran=E7ois_Simon?= To: , Cc: Date: Fri, 7 Apr 2017 13:12:49 -0400 Message-ID: <003701d2afc2$2fc21350$8f4639f0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0038_01D2AFA0.A8B07350" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdKvweeVdZSOgNORRmuNUyQDo/MuYw== Content-Language: en-us Archived-At: Subject: [ipwave] draft-jeong-ipwave-vehicular-networking-survey-02 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, 07 Apr 2017 17:13:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0038_01D2AFA0.A8B07350 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0039_01D2AFA0.A8B07350" ------=_NextPart_001_0039_01D2AFA0.A8B07350 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sir, Find a few comments related to the document referenced above. If you have any questions, please let me know. Sincerely, Francois Simon ------=_NextPart_001_0039_01D2AFA0.A8B07350 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Sir,

 

Find a few = comments related to the document referenced above.

 

If you have = any questions, please let me know.

 

Sincerely,

 

Francois = Simon

------=_NextPart_001_0039_01D2AFA0.A8B07350-- ------=_NextPart_000_0038_01D2AFA0.A8B07350 Content-Type: text/plain; name="IPWAVE_SURVEY_IP_VEHICULAR_COMMENT_040717.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="IPWAVE_SURVEY_IP_VEHICULAR_COMMENT_040717.txt" Network Working Group J. Jeong Internet-Draft Sungkyunkwan University Intended status: Standards Track S. Cespedes Expires: October 1, 2017 Universidad de Chile N. Benamar Moulay Ismail University J. Haerri EURECOM M. Wetterwald FBConsulting March 30, 2017 [Francois Y, Simon Comments stated as "[Fygs:........] =20 Survey on IP-based Vehicular Networking for Intelligent Transportation =20 Systems =20 draft-jeong-ipwave-vehicular-networking-survey-02 Abstract This document surveys the IP-based vehicular networks, which are considered a key component of Intelligent Transportation Systems (ITS). The main topics of vehicular networking are vehicle-to- vehicle (V2V), vehicle-to-infrastructure (V2I), and infrastructure- to-vehicle (I2V) networking. This document deals with some critical aspects in vehicular networking, such as IP address autoconfiguration, vehicular network architecture, routing, mobility management, and security. This document also surveys standard activities for vehicular networks. Finally, this document summarizes and analyzes the previous research activities that use IPv4 or IPv6 for vehicular networking. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. Jeong, et al. Expires October 1, 2017 [Page 1] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 1, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. IP Address Autoconfiguration . . . . . . . . . . . . . . . . . 5 4.1. Automatic IP Address Configuration in VANETs . . . . . . . 5 4.2. Routing and Address Assignment using Lane/Position Information in a Vehicular Ad-hoc Network . . . . . . . . 5 4.3. GeoSAC: Scalable Address Autoconfiguration for VANET Using Geographic Networking Concepts . . . . . . . . . . . 6 4.4. Cross-layer Identities Management in ITS Stations . . . . 7 4.5. Key Observations . . . . . . . . . . . . . . . . . . . . . 7 5. Vehicular Network Architecture . . . . . . . . . . . . . . . . 8 5.1. VIP-WAVE: On the Feasibility of IP Communications in 802.11p Vehicular Networks . . . . . . . . . . . . . . . . 8 5.2. IPv6 Operation for WAVE - Wireless Access in Vehicular Environments . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. A Framework for IP and non-IP Multicast Services for Vehicular Networks . . . . . . . . . . . . . . . . . . . . 10 5.4. Joint IP Networking and Radio Architecture for Vehicular Networks . . . . . . . . . . . . . . . . . . . . 10 5.5. Mobile Internet Access in FleetNet . . . . . . . . . . . . 11 5.6. A Layered Architecture for Vehicular Delay-Tolerant Networks . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.7. Key Observations . . . . . . . . . . . . . . . . . . . . . 13 6. Vehicular Network Routing . . . . . . . . . . . . . . . . . . 13 6.1. An IP Passing Protocol for Vehicular Ad Hoc Networks Jeong, et al. Expires October 1, 2017 [Page 2] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 with Network Fragmentation . . . . . . . . . . . . . . . . 13 6.2. Experimental Evaluation for IPv6 over VANET Geographic Routing . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.3. Key Observations . . . . . . . . . . . . . . . . . . . . . 15 7. Mobility Management in Vehicular Networks . . . . . . . . . . 15 7.1. A Hybrid Centralized-Distributed Mobility Management for Supporting Highly Mobile Users . . . . . . . . . . . . 15 7.2. A Hybrid Centralized-Distributed Mobility Management Architecture for Network Mobility . . . . . . . . . . . . 16 7.3. NEMO-Enabled Localized Mobility Support for Internet Access in Automotive Scenarios . . . . . . . . . . . . . . 17 7.4. Network Mobility Protocol for Vehicular Ad Hoc Networks . 18 7.5. Performance Analysis of PMIPv6-Based Network MObility for Intelligent Transportation Systems . . . . . . . . . . 18 7.6. A Novel Mobility Management Scheme for Integration of Vehicular Ad Hoc Networks and Fixed IP Networks . . . . . 19 7.7. SDN-based Distributed Mobility Management for 5G Networks . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.8. IP Mobility Management for Vehicular Communication Networks: Challenges and Solutions . . . . . . . . . . . . 20 7.9. Key Observations . . . . . . . . . . . . . . . . . . . . . 21 8. Vehicular Network Security . . . . . . . . . . . . . . . . . . 22 8.1. Securing Vehicular IPv6 Communications . . . . . . . . . . 22 8.2. Providing Authentication and Access Control in Vehicular Network Environment . . . . . . . . . . . . . . 22 8.3. Key Observations . . . . . . . . . . . . . . . . . . . . . 23 9. Standard Activities for Vehicular Networks . . . . . . . . . . 23 9.1. IEEE Guide for Wireless Access in Vehicular Environments (WAVE) - Architecture . . . . . . . . . . . . 23 9.2. IEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Networking Services . . . . . . . . 24 9.3. ETSI Intelligent Transport Systems: Transmission of IPv6 Packets over GeoNetworking Protocols . . . . . . . . 25 9.4. ISO Intelligent Transport Systems: Communications Access for Land Mobiles (CALM) Using IPv6 Networking . . . 25 10. Summary and Analysis . . . . . . . . . . . . . . . . . . . . . 26 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . . 27 13.2. Informative References . . . . . . . . . . . . . . . . . . 28 Appendix A. Changes from draft-jeong-ipwave-vehicular-networking-survey-01 . . 32 Jeong, et al. Expires October 1, 2017 [Page 3] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 1. Introduction Nowadays vehicular networks have been focused on the driving safety, driving efficiency, and infotainment in road networks. For the driving safety, IEEE has standardized Wireless Access in Vehicular Environments (WAVE) standards, such as IEEE 802.11p, IEEE 1609.3, and IEEE 1609.4 [VIP-WAVE]. Along with these WAVE standards, IPv6 and Mobile IP protocols (e.g., MIPv4 and MIPv6) can be extended to vehicular networks. [Fygs: IEEE 802.11p is no longer available. It has been inncluded in IEEE 802.11-2012 and IEEE 802.11-2016. In the scope of IPWAVE,=20 the mode of operation has been stated as 802.11 Outside the BSS contect (OCB. The term "VIP-WAVE" is unknown and not defined. IEEE 1609.2 = (Security) is part of the IEEE 1609 suites of protocol.] This document surveys the IP-based vehicular networking for Intelligent Transportation Systems (ITS), such as IP address autoconfiguration, vehicular network architecture, vehicular network routing (for multi-hop V2V, V2I, and V2V), mobility management, and security. This document summarizes and analyzes the previous research activities using IPv4 or IPv6 for vehicular networking. [Fygs: "(for multi-hop V2V, V2I, and V2V)", it is assume the second instance of V2V should be "I2V".] Based on the survey of this document, we can specify the requirements for vehicular networks for the intended purposes, such as the driving safety, driving efficiency, and infotainment. As a consequence, this will make it possible to design the network architecture and protocols for vehicular networking. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Terminology This document defines the following new terms: o Road-Side Unit (RSU): A node that has Dedicated Short-Range Communications (DSRC) device for wireless communications with vehicles and is connected to the Internet. An RSU is usually deployed at an intersection. [Fygs: An RSU is not connected to the Internet, a router is=20 required to do so.] Intersection is only one instance where=20 RSU can be used.] o Vehicle: A node that has DSRC device for wireless communications with vehicles and RSUs. A vehicle may also have a GPS-navigation system for efficient driving. [Fygs: Avehicle is not a node. The OBU whithin the vehicle is. It is assumed, in most cases that a GPS will be included in the vehicle.] o Traffic Control Center (TCC): A node that maintains road infrastructure information (e.g., RSUs and traffic signals), vehicular traffic statistics (e.g., average vehicle speed and vehicle inter-arrival time per road segment), and vehicle information (e.g., a vehicle's identifier, position, direction, speed, and trajectory as a navigation path). TCC is included in a Jeong, et al. Expires October 1, 2017 [Page 4] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 vehicular cloud for vehicular networks. [Fygs: TCC is defined as Traffic Management Center (TMC) in the US. The TMC as many functions depending on its type - Single jurisdiction=20 TMC, Regional or district TMC, Statewide TMC. Functions are various=20 and adapted to their respective regions. Examples are Management of=20 evacuation routes, detection and monitoring of pedestrians and bike traffic, monitor transit operations in real time, real-time responsive=20 traffic signal systems. It is the nerve center of most freeway = management sytems; data is collected, processed, fused with other operational and=20 control data, synthesize to produce "information" distributed to = stakeholders, other agencies, and traveling public.] 4. IP Address Autoconfiguration This section surveys IP address autoconfiguration schemes for vehicular networks. 4.1. Automatic IP Address Configuration in VANETs Fazio et al. proposed a vehicular address configuration called VAC for automatic IP address configuration in Vehicular Ad Hoc Networks (VANET) [Address-Autoconf]. VAC uses a distributed dynamic host configuration protocol (DHCP). This scheme uses a leader playing a role of a DHCP server within a cluster having connected vehicles within a VANET. In a connected VANET, vehicles are connected with each other with the communication range. In this VANET, VAC dynamically elects a leader-vehicle to quickly provide vehicles with unique IP addresses. The leader-vehicle maintains updated information on configured addressed in its connected VANET. It aims at the reduction of the frequency of IP address reconfiguration due to mobility. VAC defines the concept of SCOPE as a delimited geographic area where IP addresses are guaranteed to be unique. When it is allocated an IP address from a leader-vehicle with a scope, a vehicle is guaranteed to have a unique IP address while moving within the scope of the leader-vehicle. If it moves out of the scope of the leader vehicle, it needs to ask for another IP address from another leader-vehicle so that its IP address can be unique within the scope of the new leader- vehicle. This approach may allow for less frequent change of an IP address than the address allocation from a fixed Internet gateway. Thus, VAC can support a feasible address autoconfiguration for V2V scenarios, but the overhead to guarantee the uniqueness of IP addresses is not ignorable under high-speed mobility. 4.2. Routing and Address Assignment using Lane/Position Information in a Vehicular Ad-hoc Network Kato et al. proposed an IPv6 address assignment scheme using lane and position information [Address-Assignment]. In this addressing scheme, each lane of a road segment has a unique IPv6 prefix. When it moves in a lane in a road segment, a vehicle autoconfigures its IPv6 address with its MAC address and the prefix assigned to the lane. A group of vehicles constructs a connected VANET within the same subnet such that their IPv6 addresses have the same prefix. Whenever it moves to another lane, a vehicle updates its IPv6 address with the prefix corresponding to the new lane and also joins the Jeong, et al. Expires October 1, 2017 [Page 5] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 group corresponding to the lane. However, this address autoconfiguration scheme may have much overhead in the case where vehicles change their lanes frequently in highway. 4.3. GeoSAC: Scalable Address Autoconfiguration for VANET Using Geographic Networking Concepts Baldessari et al. proposed an IPv6 scalable address autoconfiguration scheme called GeoSAC for vehicular networks [GeoSAC]. GeoSAC uses geographic networking concepts such that it combines the standard IPv6 Neighbor Discovery (ND) and geographic routing functionality. It matches geographically-scoped network partitions to individual IPv6 multicast-capable links. In the standard IPv6, all nodes within the same link must communicate with each other, but due to the characteristics of wireless links, this concept of a link is not clear in vehicular networks. GeoSAC defines a link as a geographic area having a network partition. This geographic area can have a connected VANET. Thus, vehicles within the same VANET in a specific geographic area are regarded as staying in the same link, that is, an IPv6 multicast link. This paper identifies four key requirements of IPv6 address autoconfiguration for vehicular networks: (i) the configuration of globally valid addresses, (ii) a low complexity for address autoconfiguration, (iii) a minimum signaling overhead of address autoconfiguration, (iv) the support of network mobility through movement detection, (v) an efficient gateway selection from multiple RSUs, (vi) a fully distributed address autoconfiguration for network security, (vii) the authentication and integrity of signaling messages, and (viii) the privacy protection of vehicles' users. To support the proposed link concept, GeoSAC performs ad hoc routing for geographic networking in a sub-IP layer called Car-to-Car (C2C) NET. Vehicles within the same link can receive an IPv6 router advertisement (RA) message transmitted by an RSU as a router, so they can autoconfigure their IPv6 address based on the IPv6 prefix contained in the RA and perform Duplicate Address Detection (DAD) to verify the uniqueness of the autoconfigured IP address by the help of the geographic routing within the link. [Fygs: Here also, an RSU is not a router by can be associated with = one.] For location-based applications, to translate between a geographic area and an IPv6 prefix belonging to an RSU, this paper takes advantage of an extended DNS service, using GPS-based addressing and routing along with geographic IPv6 prefix format [GeoSAC]. Thus, GeoSAC can support the IPv6 link concept through geographic routing within a specific geographic area. Jeong, et al. Expires October 1, 2017 [Page 6] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 4.4. Cross-layer Identities Management in ITS Stations ITS and vehicular networks are built on the concept of an ITS station (e.g., vehicle and RSU), which is a common reference model inspired from the Open Systems Interconnection (OSI) standard [Identities-Management]. In vehicular networks using multiple access network technologies through a cross-layer architecture, a vehicle may have multiple identities corresponding to the access network interfaces. Wetterwald et al. conducted a comprehensive study of the cross-layer identity management in vehicular networks using multiple access network technologies, which constitutes a fundamental element of the ITS architecture [Identities-Management]. [Fygs: keeping with object defined in this context; An OBE is an "on-board unit (OBE) presumably located within the vehicle. It is=20 not clear what cross-layer architecture is. However, it seems that a router cabable of multiple interface, RF and others,would provide the required functions.] Besides considerations related to the case where ETSI GeoNetworking [ETSI-GeoNetworking] is used, this paper analyzes the major requirements and constraints weighing on the identities of ITS stations, e.g., privacy and compatibility with safety applications and communications. The concerns related to security and privacy of the users need to be addressed for vehicular networking, considering all the protocol layers simultaneously. In other words, for security and privacy constraints to be met, the IPv6 address of a vehicle should be derived from a pseudonym-based MAC address and renewed simultaneously with that changing MAC address. This dynamically changing IPv6 address can prevent the ITS station from being tracked by a hacker. However, this address renewal cannot be applied at any time because in some situations, the continuity of the knowledge about the surrounding vehicles is required. Also, this paper defines a cross-layer framework that fulfills the requirements on the identities of ITS stations and analyzes systematically, layer by layer, how an ITS station can be identified uniquely and safely, whether it is a moving station (e.g., car and bus using temporary trusted pseudonyms) or a static station (e.g., RSU and central station). This paper has been applied to the specific case of the ETSI GeoNetworking as the network layer, but an identical reasoning should be applied to IPv6 over 802.11 in Outside the Context of a Basic Service Set (OCB) mode now. 4.5. Key Observations High-speed mobility should be considered for a light-overhead address autoconfiguration. A cluster leader can have an IPv6 prefix [Address-Autoconf]. Each lane in a road segment can have an IPv6 prefix [Address-Assignment]. A geographic region under the communication range of an RSU can have an IPv6 prefix [GeoSAC]. IPv6 ND should be extended to support the concept of a link for an IPv6 prefix in terms of multicast. Ad Hoc routing is required for Jeong, et al. Expires October 1, 2017 [Page 7] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 the multicast in a connected VANET with the same IPv6 prefix [GeoSAC]. A rapid DAD should be supported to prevent or reduce IPv6 address conflicts. In the ETSI GeoNetworking, for the sake of security and privacy, an ITS station (e.g., vehicle) can use pseudonyms for its network interface identities and the corresponding IPv6 addresses [Identities-Management]. For the continuity of an end-to-end transport session, the cross-layer identity management should be performed carefully. 5. Vehicular Network Architecture This section surveys vehicular network architectures based on IP along with various ratio technologies. [Fygs: What is a ratio technology?] 5.1. VIP-WAVE: On the Feasibility of IP Communications in 802.11p Vehicular Networks Cespedes et al. proposed a vehicular IP in WAVE called VIP-WAVE for I2V and V2I networking [VIP-WAVE]. IEEE 1609.4 specified a WAVE stack of protocols and includes IPv6 as a network layer protocol in data plane. The standard WAVE does not support DAD, seamless communications for Internet services, and multi-hop communications between a vehicle and an infrastructure node (e.g., RSU). To overcome these limitations of the standard WAVE for IP-based networking, VIP-WAVE enhances the standard WAVE by the following three schemes: (i) an efficient mechanism for the IPv6 address assignment and DAD, (ii) on-demand IP mobility based on Proxy Mobile IPv6 (PMIPv6), and (iii) one-hop and two-hop communications for I2V and V2I networking. [Fygs:As mapping IEEE 1609 series to OSI model, IEEE 1609.4 does=20 not include IPv6 as a network layer; IEEE 1609.3 does. IEEE 1609.4 is an extension of the MAC to deal with multiple channels; it is actually a SME functions controlling multiple queues on the=20 MAC data plane.] In WAVE, IPv6 ND protocol is not recommended due to the overhead of ND against the timely and prompt communications in vehicular networking. By WAVE service advertisement (WAS) management frame, an RSU can provide vehicles with IP configuration information (e.g., IPv6 prefix, prefix length, gateway, router lifetime, and DNS server) without using ND. However, WAVE devices may support readdressing to provide pseudonymity, so a MAC address of a vehicle may be changed or randomly generated. This update of the MAC address may lead to the collision of an IPv6 address based on a MAC address, so VIP-WAVE includes a light-weight, on-demand ND to perform DAD. For IP-based Internet services, VIP-WAVE adopts PMIPv6 for network- based mobility management in vehicular networks. In VIP-WAVE, RSU plays a role of mobile anchor gateway (MAG) of PMIPv6, which performs the detection of a vehicle as a mobile node in a PMIPv6 domain and registers it into the PMIPv6 domain. For PMIPv6 operations, VIP-WAVE Jeong, et al. Expires October 1, 2017 [Page 8] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 requires a central node called local mobility anchor (LMA), which assigns IPv6 prefixes to vehicles as mobile nodes and forwards data packets to the vehicles moving in the coverage of RSUs under its control through tunnels between MAGs and itself. For two-hop communications between a vehicle and an RSU, VIP-WAVE allows an intermediate vehicle between the vehicle and the RSU to play a role of a packet relay for the vehicle. When it becomes out of the communication range of an RSU, a vehicle searches for another vehicle as a packet relay by sending a relay service announcement. When it receives this relay service announcement and is within the communication range of an RSU, another vehicle registers itself into the RSU as a relay and notifies the relay-requester vehicle of a relay maintenance announcement. Thus, VIP-WAVE is a good candidate for I2V and V2I networking, supporting an enhanced ND, handover, and two-hop communications through a relay. 5.2. IPv6 Operation for WAVE - Wireless Access in Vehicular Environments Baccelli et al. provided an analysis of the operation of IPv6 as it has been described by the IEEE WAVE standards 1609 [IPv6-WAVE]. Although the main focus of WAVE has been the timely delivery of safety related information, the deployment of IP-based infotainment applications is also considered. Thus, in order to support infotainment traffic, WAVE supports IPv6 and transport protocols such as TCP and UDP. In the analysis provided in [IPv6-WAVE], it is identified that the IEEE 1609.3 standard's recommendations for IPv6 operation over WAVE are rather minimal. Protocols on which the operation of IPv6 relies for IP address configuration and IP-to-link-layer address translation (e.g., IPv6 NP protocol) are not recommended in the standard. Additionally, IPv6 works under certain assumptions for the link model that do not necessarily hold in WAVE. For instance, IPv6 assumes symmetry in the connectivity among neighboring interfaces. However, interference and different levels of transmission power may cause unidirectional links to appear in a WAVE link model. Also, in an IPv6 link, it is assumed that all interfaces which are configured with the same subnet prefix are on the same IP link. Hence, there is a relationship between link and prefix, besides the different scopes that are expected from the link-local and global types of IPv6 addresses. Such a relationship does not hold in a WAVE link model due to node mobility and highly dynamic topology. Baccellii et al. concluded that the use of the standard IPv6 protocol Jeong, et al. Expires October 1, 2017 [Page 9] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 stack, as the IEEE 1609 family of specifications stipulate, is not sufficient. Instead, the addressing assignment should follow considerations for ad-hoc link models, defined in [RFC5889], which are similar to the characteristics of the WAVE link model. In terms of the supporting protocols for IPv6, such as ND, DHCP, or stateless auto-configuration, which rely largely on multicast, do not operate as expected in the case where the WAVE link model does not have the same behavior expected for multicast IPv6 traffic due to nodes' mobility and link variability. Additional challenges such as the support of pseudonimity through MAC address change along with the suitability of traditional TCP applications are discussed by the authors since they require the design of appropriate solutions. 5.3. A Framework for IP and non-IP Multicast Services for Vehicular Networks Jemaa et al. presented a framework that enables deploying multicast services for vehicular networks in Infrastructure-based scenarios [Vehicular-Network-Framework]. This framework deals with two phases: (i) Initialization or bootstrapping phase that includes a geographic multicast auto-configuration process and a group membership building method and (ii) Multicast traffic dissemination phase that includes a network selecting mechanism on the transmission side and a receiver- based multicast delivery in the reception side. To this end, authors define a distributed mechanism that allows the vehicles to configure a common multicast address: Geographic Multicast Address Auto- configuration (GMAA), which allows a vehicle to configure its own address without signaling. A vehicle may also be able to change the multicast address to which it is subscribed when it changes its location. This framework suggests a network selecting approach that allows IP and non-IP multicast data delivery in the sender side. Then, to meet the challenges of multicast address auto-configuration, the authors propose a distributed geographic multicast auto-addressing mechanism for multicast groups of vehicles, and a simple multicast data delivery scheme in hybrid networks from a server to the group of moving vehicles. However, this study lacks simulations related to performance assessment. 5.4. Joint IP Networking and Radio Architecture for Vehicular Networks Petrescu et al. defined the joined IP networking and radio architecture for V2V and V2I communication in [Joint-IP-Networking]. The paper proposes to consider an IP topology in a similar way as a radio link topology, in the sense that an IP subnet would correspond to the range of 1-hop vehicular communication. The paper defines three types of vehicles: Leaf Vehicle (LV), Range Extending Vehicle Jeong, et al. Expires October 1, 2017 [Page 10] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 (REV), and Internet Vehicle (IV). The first class corresponds to the largest set of communicating vehicles (or network nodes within a vehicle), while the role of the second class is to build an IP relay between two IP-subnet and two sub-IP networks. Finally, the last class corresponds to vehicles being connected to Internet. Based on these three classes, the paper defines six types of IP topologies corresponding to V2V communication between two LVs in direct range, or two LVs over a range extending vehicle, or V2I communication again either directly via an IV, via another vehicles being IV, or via an REV connecting to an IV. Considering a toy example of a vehicular train, where LV would be in- wagon communicating nodes, REV would be inter-wagon relays, and IV would be one node (e.g., train head) connected to Internet. Petrescu et al. defined the required mechanisms to build subnetworks, and evaluated the protocol time that is required to build such networks. Although no simulation-based evaluation is conducted, the initial analysis shows a long initial connection overhead, which should be alleviated once the multi-wagon remains stable. However, this approach does not describe what would happen in the case of a dynamic multi-hop vehicular network, where such overhead would end up being too high for V2V/V2I IP-based vehicular applications. One other aspect described in this paper is to join the IP-layer relaying with radio-link channels. This paper suggests to separate different subnetworks in different WiFi/ITS-G5 channels, which could be advertised by the REV. Accordingly, the overall interference could be controlled within each subnetwork. This statement is similar to multi-channel topology management proposals in multi-hop sensor networks, yet adapted to an IP topology. In conclusion, this paper proposes to classify an IP multi-hop vehicular network in three classes of vehicles: Leaf Vehicle (LV), Range Extending Vehicle (REV), and Internet Vehicle (IV). It suggests that the generally complex multi-hop IP vehicular topology could be represented by only six different topologies, which could be further analyzed and optimized. A prefix dissemination protocol is proposed for one of the topologies. 5.5. Mobile Internet Access in FleetNet Bechler et al. described the FleetNet project approach to integrate Internet Access in future vehicular networks [FleetNet]. The paper is most probably one of the first paper to address this aspect, and in many ways, introduces concepts that will be later used in MIPv6 or other subsequent IP mobility management schemes. The paper describes a V2I architecture consisting of Vehicles, Internet Gateways (IGW), Proxy, and Corresponding Nodes (CN). Considering that vehicular Jeong, et al. Expires October 1, 2017 [Page 11] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 networks are required to use IPv6 addresses and also the new wireless access technology ITS-G5 (new at that time), one of the challenges is to bridge the two different networks (i.e., VANET and IP4/IPv6 Internet). Accordingly, the paper introduces a Fleetnet Gateway (FGW), which allows vehicles in IPv6 to access the IPv4 Internet and to bridge two types of networks and radio access technologies. Another challenge is to keep the active addressing and flows while vehicles move between FGWs. Accordingly, the paper introduces a proxy node, a cranked-up MIP Home Agent, which can re-route flows to the new FGW as well as acting as a local IPv4-IPv6 NAT. The authors from the paper mostly observed two issues that VANET brings into the traditional IP mobility. First, VANET vehicles must mostly be addressed from the Internet directly, and do not specifically have a Home Network. Accordingly, VANET vehicles require a globally (predefined) unique IPv6 address, while an IPv6 co-located care-of address (CCoA) is a newly allocated IPv6 address every time a vehicle would enter a new IGW radio range. Second, VANET links are known to be unreliable and short, and the extensive use of IP tunneling on-the-air was judged not efficient. Accordingly, the first major architecture innovation proposed in this paper is to re-introduce a foreign agent (FA) in MIP located at the IGW, so that the IP-tunneling would be kept in the back-end (between a Proxy and an IGW) and not on the air. Second, the proxy has been extended to build an IP tunnel and be connected to the right FA/IWG for an IP flow using a global IPv6 address. This is a pioneer paper, which contributed to changing MIP and led to the new IPv6 architecture currently known as Proxy-MIP and the subsequent DMM-PMIP. Three key messages can be yet kept in mind. First, unlike the Internet, vehicles can be more prominently directly addressed than the Internet traffic, and do not have a Home Network in the traditional MIP sense. Second, IP tunneling should be avoided as much as possible over the air. Third, the protocol-based mobility (induced by the physical mobility) must be kept hidden to both the vehicle and the correspondent node (CN). 5.6. A Layered Architecture for Vehicular Delay-Tolerant Networks Soares et al. addressed the case of delay tolerant vehicular network [Vehicular-DTN]. For delay tolerant or disruption tolerant networks, rather than building a complex VANET-IP multi-hop route, vehicles may also be used to carry packets closer to the destination or directly at the destination. The authors built the well-accepted DTN Bundle architecture and protocol to propose a VANET extension. They introduced three types of VANET nodes: (i) terminal nodes (requiring data), (ii) mobile nodes (carrying data along their routes), and (iii) relay nodes (storing data at cross-roads of mobile nodes as Jeong, et al. Expires October 1, 2017 [Page 12] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 data hotspot). The major innovation in this paper is to propose a DTN VANET architecture separating a Control plane and a Data plane. The authors claimed it to be designed to allow full freedom to select the most appropriate technology, as well as allow to use out-of-band communication for small Control plane packets and use DTN in-band for the Data plane. The paper then further describes the different layers from the Control and the Data planes. One interesting aspect is the positioning of the Bundle layer between L2 and L3, rather than above TCP/IP as for the DTN Bundle architecture. The authors claimed this to be required first to keep bundle aggregation/disaggregation transparent to IP, as well as to allow bundle transmission over multiple access technologies (described as MAC/PHY layers in the paper). Although the DTN architectures evolved since the paper has been written, this paper addresses IP mobility management from a different approach. The innovative aspect is an early proposal to separate the Control from the Data plane to allow a large flexibility in a Control plane to coordinate a heterogeneous radio access technology (RAT) Data plane. =09 [Fygs: Note Separation of Control and data plane is really nothing new. All switched protocols since the mid 1960 where actually based on three planes: Control, Data, and Management planes. The three planes may be = in-band embeded with the data or out-band (sparate channel.] 5.7. Key Observations Unidirectional links exist and must be considered. Control Plane must be separated from Data Plane. ID/Pseudonym change requires a lightweight DAD. IP tunneling should be avoided. Vehicles do not have a Home Network. Protocol-based mobility must be kept hidden to both the vehicle and the correspondent node (CN). An ITS architecture may be composed of three types of vehicles: Leaf Vehicle, Range Extending Vehicle, and Internet Vehicle. 6. Vehicular Network Routing This section surveys routing in vehicular networks. 6.1. An IP Passing Protocol for Vehicular Ad Hoc Networks with Network Fragmentation Chen et al. tackled the issue of network fragmentation in VANET environments [IP-Passing-Protocol]. The paper proposes a protocol that can postpone the time to release IP addresses to the DHCP server and select a faster way to get the vehicle's new IP address, when the vehicle density is low or the speeds of vehicles are varied. In such circumstances, the vehicle may not be able to communicate with the intended vehicle either directly or through multi-hop relays as a consequence of network fragmentation. Jeong, et al. Expires October 1, 2017 [Page 13] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 The paper claims that although the existing IP passing and mobility solutions may reduce handoff delay, but they cannot work properly on VANET especially with network fragmentation. This is due to the fact that messages cannot be transmitted to the intended vehicles. When network fragmentation occurs, it may incur longer handoff latency and higher packet loss rate. The main goal of this study is to improve existing works by proposing an IP passing protocol for VANET with network fragmentation. The paper makes the assumption that on the highway, when a vehicle moves to a new subnet, the vehicle will receive broadcast packet from the target Base Station (BS), and then perform the handoff procedure. The handoff procedure includes two parts, such as the layer-2 handoff (new frequency channel) and the layer-3 handover (a new IP address). The handoff procedure contains movement detection, DAD procedure, and registration. In the case of IPv6, the DAD procedure is time consuming and may cause the link to be disconnected. This paper proposes another handoff mechanism. The handoff procedure contains the following phases. The first is the information collecting phase, where each mobile node (vehicle) will broadcast its own and its neighboring vehicles' locations, moving speeds, and directions periodically. The remaining phases are, the fast IP acquiring phase, the cooperation of vehicle phase, the make before break phase, and the route redirection phase. Simulations results show that for the proposed protocol, network fragmentation ratio incurs less impact. Vehicle speed and density has great impact on the performance of the IP passing protocol because vehicle speed and vehicle density will affect network fragmentation ratio. A longer IP lifetime can provide a vehicle with more chances to acquire its IP address through IP passing. Simulation results show that the proposed scheme can reduce IP acquisition time and packet loss rate, so extend IP lifetime with extra message overhead. [Fygs: FYI examples of Vehicle Density / Vehicle Speed (derived from = the US Highway Capacity Manual - 2010 (HCM210): Freeway - Vehicule Density per km per lane =3D 29 Multi-lane Highway - Free Flow Speed (FSS) =3D 72 km/h; Number of travel lane =3D 4 Segment length =3D .5 Vehicle density =3D 98 Two-lane Highway - Average Speed in both direction =3D 64 km/h, = Vehicle density: 3200/hr Urban Street - Speed 20 km/h, Vehicle density per lane per hour =3D = 1900]. 6.2. Experimental Evaluation for IPv6 over VANET Geographic Routing Tsukada et al. presented a work that aims at combining IPv6 networking and a Car-to-Car Network routing protocol (called C2CNet) proposed by the Car2Car Communication Consortium (C2C-CC), which is an architecture using a geographic routing protocol [VANET-Geo-Routing]. In C2C-CC architecture, C2CNet layer is located between IPv6 and link layers. Thus, an IPv6 packet is delivered with outer C2CNet header, which introduces the challenge of how to support the communication types defined in C2CNet in IPv6 layer. The main goal of GeoNet is to enhance these specifications and create Jeong, et al. Expires October 1, 2017 [Page 14] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 a prototype software implementation interfacing with IPv6. C2CNet is specified in C2C-CC as a geographic routing protocol. In order to assess the performance of this protocol, the authors measured the network performance with UDP and ICMPv6 traffic using iperf and ping6. The test results show that IPv6 over C2CNet does not have too much delay (less than 4ms with a single hop) and is feasible for vehicle communication. In the outdoor testbed, they developed AnaVANET to enable hop-by-hop performance measurement and position trace of the vehicles. The combination of IPv6 multicast and GeoBroadcast was implemented, however, the authors did not evaluate the performance with such a scenario. One of the reasons is that a sufficiently high number of receivers are necessary to properly evaluate multicast but experimental evaluation is limited in the number of vehicles (4 in this study). 6.3. Key Observations IP address autoconfiguration should be manipulated to support the efficient networking. Due to network fragmentation, vehicles cannot communicate with each other temporarily. IPv6 ND should consider the temporary network fragmentation. IPv6 link concept can be supported by Geographic routing to connect vehicles with the same IPv6 prefix. 7. Mobility Management in Vehicular Networks This section surveys mobility management schemes in vehicular networks to support handover. 7.1. A Hybrid Centralized-Distributed Mobility Management for Supporting Highly Mobile Users Nguyen et al. proposed a hybrid centralized-distributed mobility management called H-DMM to support highly mobile vehicles [H-DMM]. The legacy DMM is not suitable for high-speed scenarios because it requires additional registration delay proportional to the distance between a vehicle and its anchor network. H-DMM is designed to satisfy a set of requirements, such as service disruption time, end- to-end delay, packet delivery cost, and tunneling cost. H-DMM adopts a central node called central mobility anchor (CMA), which plays the role of a local mobility anchor (LMA) in PMIPv6. When it enters a mobile access router (MAR) as an access router, a vehicle obtains a prefix from the MAR (called MAR-prefix) according to the legacy DMM protocol. In addition, it obtains another prefix from the CMA (called LMA-prefix) for a PMIPv6 domain. Whenever it Jeong, et al. Expires October 1, 2017 [Page 15] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 performs a handover between the subnets for two adjacent MARs, a vehicle keeps the LMA-prefix while obtaining a new prefix from the new MAR. For a new data exchange with a new CN, the vehicle can select the MAR-prefix or the LMA-prefix for its own source IPv6 address. If the number of active prefixes is greater than a threshold, the vehicle uses the LMA-prefix-based IPv6 address as its source address. In addition, it can continue receiving data packets with the destination IPv6 addresses based on the previous prefixes through the legacy DMM protocol. Thus, H-DMM can support an efficient tunneling for a high-speed vehicle that moves fast across the subnets of two adjacent MARs. However, when H-DMM asks a vehicle to perform DAD for the uniqueness test of its configured IPv6 address in the subnet of the next MAR, the activation of the configured IPv6 address for networking will take a delay. This indicates that a proactive DAD by a network component (i.e., MAR and LMA) can shorten the address configuration delay of the current DAD triggered by a vehicle. 7.2. A Hybrid Centralized-Distributed Mobility Management Architecture for Network Mobility Nguyen et al. proposed H-NEMO, a hybrid centralized-distributed mobility management scheme to handle IP mobility of moving vehicles [H-NEMO]. The standard Network Mobility (NEMO) basic support, which is a centralized scheme for network mobility, provides IP mobility for a group of users in a moving vehicle, but also inherits the drawbacks from Mobile IPv6, such as suboptimal routing and signaling overhead in nested scenarios as well as reliability and scalability issues. On the contrary, distributed schemes such as the recently proposed Distributed Mobility Management (DMM) locates the mobility anchor at the network edge and enables mobility support only to traffic flows that require such support. However, in high speed moving vehicles, DMM may suffer from high signaling cost and high handover latency. The proposed H-NEMO architecture is not designed for a specific wireless technology. Instead, it defines a general architecture and signaling protocol so that a mobile node can obtain mobility from fixed locations or mobile platforms, and also allows the use of DMM or Proxy Mobile IPv6 (PMIPv6), depending on flow characteristics and mobility patterns of the node. For IP addressing allocation, a mobile router (MR) or the mobile node (MN) connected to an MR in a NEMO obtain two sets of prefixes: one from the central mobility anchor and one from the mobile access router (MAR). In this way, the MR/MN may choose a more stable prefix for long-lived flows to be routed via the central mobility anchor and the MAR-prefix for short- lived flows to be routed following the DMM concept. The multi-hop Jeong, et al. Expires October 1, 2017 [Page 16] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 scenario is considered under the concept of a nested-NEMO. Nguyen et al. did not provide simulation-based evaluations, but they provided an analytical evaluation that considered signaling and packet delivery costs, and showed that H-NEMO outperforms the previous proposals, which are either centralized or distributed ones with NEMO support. In particular cases, such as the signaling cost, H-NEMO is more costly than centralized schemes when the velocity of the node is increasing, but behaves better in terms of packet delivery cost and handover delay. 7.3. NEMO-Enabled Localized Mobility Support for Internet Access in Automotive Scenarios In [NEMO-LMS], authors proposed an architecture to enable IP mobility for moving networks in a network-based mobility scheme based on PMIPv6. In PMIPv6, only mobile terminals are provided with IP mobility. Different from host-based mobility, PMIPv6 shifts the signaling to the network side, so that the mobile access gateway (MAG) is in charge of detecting connection/disconnection of the mobile node, upon which the signaling to the Local Mobility Anchor (LMA) is triggered to guarantee a stable IP addressing assignment when the mobile node performs handover to a new MAG. Soto et al. proposed NEMO support in PMIPv6 (N-PMIP). In this scheme, the functionality of the MAG is extended to the mobile router (MR), also called a mobile MAG (mMAG). The functionality of the mobile terminal remains unchanged, but it can receive an IPv6 prefix belonging to the PMIPv6 domain through the new functionality of the mMAG. Therefore, in N-PMIP, the mobile terminal connects to the MR as if it is connecting to a fixed MAG, and the MR connects to the fixed MAG with the standardized signaling of PMIPv6. When the mobile terminal roams to a new MAG or a new MR, the network forwards the packets through the LMA. Hence, N-PMIP defines an extended functionality in the LMA that enables a recursive lookup. First, it locates the binding entry corresponding to the mMAGr. Next, it locates the entry corresponding to the fixed MAG, after which the LMA can encapsulate packets to the mMAG to which the mobile terminal is currently connected. The performance of N-PMIP was evaluated through simulations and compared to a NEMO+MIPv6+PMIPv6 scheme, with better results obtained in N-PMIP. The work did not consider the case of multi-hop connectivity in the vehicular scenario. In addition, since the MR should be a trusted entity in the PMIP domain, it requires specific security associations that were not addressed in [NEMO-LMS]. Jeong, et al. Expires October 1, 2017 [Page 17] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 7.4. Network Mobility Protocol for Vehicular Ad Hoc Networks Chen et al. proposed a network mobility protocol to reduce handoff delay and maintain Internet connectivity to moving vehicles in a highway [NEMO-VANET]. In this work, vehicles can acquire IP addresses from other vehicles through V2V communications. At the time the vehicle goes out of the coverage of the base station, another vehicle may assist the roaming car to acquire a new IP address. Also, cars on the same or opposite lane are entitled to assist the vehicle to perform a pre-handoff. Authors assumed that the wireless connectivity is provided by WiFi and WiMAX access networks. Also, they considered scenarios in which a single vehicle, i.e., a bus, may need two mobile routers in order to have an effective pre-handoff procedure. Evaluations are performed through simulations and the comparison schemes are the standard NEMO Basic Support protocol and the fast NEMO Basic Support protocol. Authors did not mention applicability of the scheme in other scenarios such as in urban transport schemes. 7.5. Performance Analysis of PMIPv6-Based Network MObility for Intelligent Transportation Systems Lee et al. proposed P-NEMO, which is an IP mobility management scheme to maintain the Internet connectivity at the vehicle as a mobile network, and provides a make-before-break mechanism when vehicles switch to a new access network [PMIPv6-NEMO-Analysis]. Since the standard PMIPv6 only supports mobility for a single node, the solution in [PMIPv6-NEMO-Analysis] adapts the protocol to reduce the signaling when a local network is to be served by the in-vehicle mobile router. To achieve this, P-NEMO extends the binding update lists at both MAG and LMA, so that the mobile router (MR) can receive a home network prefix (HNP) and a mobile network prefix (MNP). The latter prefix enables mobility for the moving network, instead of a single node as in the standard PMIPv6. An additional feature is proposed by Lee et al. named fast P-NEMO (FP-NEMO). It adopts the fast handover approach standardized for PMIPv6 in [RFC5949] with both predictive and reactive modes. The difference of the proposed feature with the standard version is that by using the extensions provided by P-NEMO, the predictive transferring of the context from the old MAG to the new MAG also includes information for the moving network, i.e., the MNP, so that mobility support can be achieved not only for the mobile router, but also for mobile nodes traveling with the vehicle. The performance of P-NEMO and F-NEMO is only evaluated through an analytical model that is compared to the standard NEMO-BS. No Jeong, et al. Expires October 1, 2017 [Page 18] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 comparison was provided to other schemes that enable network mobility in PMIPv6 domains, such as the one presented in [NEMO-LMS]. 7.6. A Novel Mobility Management Scheme for Integration of Vehicular Ad Hoc Networks and Fixed IP Networks Peng et al. proposed a novel mobility management scheme for integration of VANET and fixed IP networks [Vehicular-Network-MM]. The proposed scheme deals with mobility of vehicles based on a street layout instead of a general two dimensional ad hoc network. This scheme makes use of the information provided by vehicular networks to reduce mobility management overhead. It allows multiple base stations that are close to a destination vehicle to discover the connection to the vehicle simultaneously, which leads to an improvement of the connectivity and data delivery ratio without redundant messages. The performance was assessed by using a road traffic simulator called SUMO (Simulation of Urban Mobility). 7.7. SDN-based Distributed Mobility Management for 5G Networks Nguyen et al. extended their previous works on a vehicular adapted DMM considering a Software-Defined Networking (SDN) architecture [SDN-DMM]. On one hand, in their previous work, Nguyen et al. proposed DMM-PMIP and DMM-MIP architectures for VANET. The major innovation behind DMM is to distribute the Mobility Functions (MF) through the network instead of concentrating them in one bottleneck MF, or in a hierarchically organized backbone of MF. Highly mobile vehicular networks impose frequent IP route optimizations that lead to suboptimal routes (detours) between CN and vehicles. The suboptimality critically increases by nested or hierarchical MF nodes. Therefore, flattening the IP mobility architecture significantly reduces detours, as it is the role of the last MF to get the closest next MF (in most cases nearby). Yet, with an MF being distributed throughout the network, a Control plane becomes necessary in order to provide a solution for CN to address vehicles. The various solutions developed by Nguyen at al. not only showed the large benefit of a DMM approach for IPv6 mobility management, but also emphasized the critical role of an efficient Control plane. One the other hand, SDN recently appeared and gained a big attention from the Internet Networking community due to its capacity to provide a significantly higher scalability of highly dynamic flows, which is required by future 5G dynamic networks. In particular, SDN also suggests a strict separation between a Control plane (SDN-Controller) and a Data plane (OpenFlow Switches) based on the OpenFlow standard. Such an architecture has two advantages that are critical for IP mobility management in VANET. First, unlike traditional routing mechanisms, OpenFlow focuses on flows rather than optimized routes. Jeong, et al. Expires October 1, 2017 [Page 19] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 Accordingly, they can optimize routing based on flows (grouping multiple flows in one route, or allowing one flow to have different routes), and can detect broken flows much earlier than the traditional networking solutions. Second, SDN controllers may dynamically reprogram (reconfigure) OpenFlow Switches (OFS) to always keep an optimal route between CN and a vehicular node. Nguyen et. al observed the mutual benefits IPv6 DMM could obtain from an SDN architecture, and then proposed an SDN-based DMM for VANET. In their proposed architecture, a PMIP-DMM is used, where MF is OFS for the Data plane, and one or more SDN controllers handle the Control plane. The evaluation and prototype in the paper prove that the proposed architecture can provide a higher scalability than the standard DMM. This paper makes several observations leading to a strong suggestions that IP mobility management should be based on an SDN architecture. First, SDN will be integrated into future Internet and 5G in a near future. Second, after separating the Identity and Routing addressing, IP mobility management further requires to separate the Control from the Data plane if it needs to remain scalable for VANET. Finally, Flow-based routing (in particular OpenFlow standard) will be required in future heterogeneous vehicular networks (e.g., multi-RAT and multi-protocol) and the SDN coupled with DMM provides a double benefit of dynamic flow detection/reconfiguration and short(-er) route optimizations. 7.8. IP Mobility Management for Vehicular Communication Networks: Challenges and Solutions Cespedes et al. provided a survey of the challenges for NEMO Basic Support for VANET [Vehicular-IP-MM]. NEMO allows the management of a group of nodes (a mobile network) rather than a single node. However, although a vehicle and even a platoon of vehicles could be seen as a group of nodes, NEMO has not been designed considering the particularities of VANET. For example, NEMO builds a tunnel between an MR (on board of a vehicle) and its HA, which in a VANET context is suboptimal, for instance due to over-the-air tunneling cost, the detour taken to pass by the MR's HA even if the CN is nearby, or the route optimization when the MR moves to a new AR. Cespedes et al. first summarize the requirements of IP mobility management, such as reduced power at end-device, reduced handover event, reduced complexity, or reduced bandwidth consumption. VANET adds the following requirements, such as minimum signaling for route optimization (RO), per-flow separability, security and binding privacy protection, multi-homing, and switching HA. As observed, these provide several challenges to IP mobility and NEMO BS for Jeong, et al. Expires October 1, 2017 [Page 20] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 VANET. Cespedes et al. then describe various optimization schemes available for NEMO BS. Considering a single hop connection to CN, one major optimization direction is to avoid the HA detour and reach the CN directly. In that direction, a few optimizations are proposed, such as creating an IP tunnel between the MR and the CR directly, creating an IP tunnel between the MR and a CR (rather than the HA), a delegation mechanism allowing Visiting Nodes to use MIPv6 directly rather than NEMO or finally intra-NEMO optimization for a direct path within NEMO bypassing HAs. Specific to VANET, multi-hop connection is possible to the fixed network. In that case, NEMO BS must be enhanced to avoid that the path to immediate neighbors must pass by the respective HAs instead of directly. More specifically, two approaches are proposed to rely on VANET sub-IP multi-hop routing to hide a NEMO complex topology (e.g., Nested NEMO) and provide a direct route between two VANET nodes. Generally, one major challenge is security and privacy when opening a multi-hop route between a VANET and a CN. Heterogeneous multi-hop in a VANET (e.g., relying on various access technologies) corresponds to another challenge for NEMO BS as well. Cespedes et al. conclude their paper with an overview of critical research challenges, such as Anchor Point location, the optimized usage of geographic information at the subIP as well as at the IP level to improve NEMO BS, security and privacy, and the addressing allocation schema for NEMO. In summary, this paper illustrates that NEMO BS for VANET should avoid the HA detour as well as opening IP tunnels over the air. Also, NEMO BS could use geographic information for subIP routing when a direct link between vehicles is required to reach an AR, but also anticipate handovers and optimize ROs. From an addressing perspective, dynamic MNP assignments should be preferred, but should be secured in particular during binding update (BU). 7.9. Key Observations Mobility Management (MM) solution design varies, depending on scenarios: highway vs. urban roadway. Hybrid schemes (NEMO + PMIP, PMIP + DMM, etc.) usually show better performance than pure schemes. Most schemes assume that IP address configuration is already set up. Most schemes have been tested only at either simulation or analytical level. SDN can be considered as a player in the MM solution. Jeong, et al. Expires October 1, 2017 [Page 21] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 8. Vehicular Network Security This section surveys security in vehicular networks. 8.1. Securing Vehicular IPv6 Communications Fernandez et al. proposed a secure vehicular IPv6 communication scheme using Internet Key Exchange version 2 (IKEv2) and Internet Protocol Security (IPsec) [Securing-VCOMM]. This scheme aims at the security support for IPv6 Network Mobility (NEMO) for in-vehicle devices inside a vehicle via a Mobile Router (MR). An MR has multiple wireless interfaces, such as 3G, IEEE 802.11p, WiFi, and WiMAX. The proposed architecture consists of Vehicle ITS Station (Vehicle ITS-S), Roadside ITS Station (Roadside ITS-S), and Central ITS Station (Central ITS-S). Vehicle ITS-S is a vehicle having a mobile Network along with an MR. Roadside ITS-S is an RSU as a gateway to connect vehicular networks to the Internet. Central ITS-S is a TCC as a Home Agent (HA) for the location management of vehicles having their MR. The proposed secure vehicular IPv6 communication scheme sets up IPsec secure sessions for control and data traffic between the MR in a Vehicle ITS-S and the HA in a Central ITS-S. Roadside ITS-S plays a role of an Access Router (AR) for Vehicle ITS-S's MR to provide the Internet connectivity for Vehicle ITS-S via wireless interfaces, such as IEEE 802.11p, WiFi, and WiMAX. In the case where Roadside ITS-S is not available to Vehicle ITS-S, Vehicle ITS-S communicates with Central ITS-S via cellular networks (e.g., 3G). The secure communication scheme enhances the NEMO protocol that interworks with IKEv2 and IPsec in network mobility in vehicular networks. The authors implemented their scheme and evaluated its performance in a real testbed. This testbed supports two wireless networks, such as IEEE 802.11p and 3G. The in-vehicle devices (or hosts) in Vehicle ITS-S are connected to an MR of Vehicle ITS-S via IEEE 802.11g. The test results show that their scheme supports promising secure IPv6 communications with a low impact on communication performance. 8.2. Providing Authentication and Access Control in Vehicular Network Environment Moustafa et al. proposed a security scheme providing authentication, authorization, and accounting (AAA) services in vehicular networks [VNET-AAA]. This secuirty scheme aims at the support of safe and reliable data services in vehicular networks. It authenticates vehicles as mobile clients to use the network access and various services that are provided by service providers. Also, it ensures a confidential data transfer between communicating parties (e.g., Jeong, et al. Expires October 1, 2017 [Page 22] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 vehicle and infrastructure node) by using IEEE 802.11i (i.e., WPA2) for secure layer-2 links. The authors proposed a vehicular network architecture consisting of three entities, such as Access network, Wireless mobile ad hoc networks (MANETs), and Access Points (APs). Access network is the fixed network infrastructure forming the back-end of the architecture. Wireless MANETs are constructed by moving vehicles forming the front-end of the architecture. APs is the IEEE 802.11 WLAN infrastructure forming the interface between the front-end and back-end of the architecture. For AAA services, the proposed architecture uses a Kerberos authentication model that authenticates vehicles at the entry point with the AP and also authorizes them to the access of various services. Since vehicles are authenticated by a Kerberos Authentication Server (AS) only once, the proposed security scheme can minimize the load on the AS and reduce the delay imposed by layer 2 using IEEE 802.11i. 8.3. Key Observations The security for vehicular networks should provide vehicles with AAA services in an efficient way. It should consider not only horizontal handover, but also vertical handover since vehicles have multiple wireless interfaces. 9. Standard Activities for Vehicular Networks This section surveys standard activities for vehicular networks in standards developing organizations. 9.1. IEEE Guide for Wireless Access in Vehicular Environments (WAVE) - Architecture IEEE 1609 is a suite of standards for Wireless Access in Vehicular Environments (WAVE) developed in the IEEE Vehicular Technology Society (VTS). They define an architecture and a complementary standardized set of services and interfaces that collectively enable secure vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) wireless communications. IEEE 1609.0 provides a description of the WAVE system architecture and operations (called WAVE reference model) [WAVE-1609.0]. The reference model of a typical WAVE device includes two data plane protocol stacks (sharing a common lower stack at the data link and physical layers): (i) the standard Internet Protocol Version 6 (IPv6) and (ii) the WAVE Short Message Protocol (WSMP) designed for Jeong, et al. Expires October 1, 2017 [Page 23] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 optimized operation in a wireless vehicular environment. WAVE Short Messages (WSM) may be sent on any channel. IP traffic is only allowed on service channels (SCHs), so as to offload high-volume IP traffic from the control channel (CCH). The Layer 2 protocol stack distinguishes between the two upper stacks by the Ethertype field. Ethertype is a 2-octet field in the Logical Link Control (LLC) header, used to identify the networking protocol to be employed above the LLC protocol. In particular, it specifies the use of two Ethertype values (i.e., two networking protocols), such as IPv6 and WSMP. Regarding the upper layers, while WAVE communications use standard port numbers for IPv6-based protocols (e.g., TCP, UDP), they use a Provider Service Identifier (PSID) as an identifier in the context of WSMP. 9.2. IEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Networking Services IEEE 1609.3 defines services operating at the network and transport layers, in support of wireless connectivity among vehicle-based devices, and between fixed roadside devices and vehicle-based devices using the 5.9 GHz Dedicated Short-Range Communications/Wireless Access in Vehicular Environments (DSRC/WAVE) mode [WAVE-1609.3]. WAVE Networking Services represent layer 3 (networking) and layer 4 (transport) of the OSI communications stack. The purpose is then to provide addressing and routing services within a WAVE system, enabling multiple stacks of upper layers above WAVE Networking Services and multiple lower layers beneath WAVE Networking Services. Upper layer support includes in-vehicle applications offering safety and convenience to users. The WAVE standards support IPv6. IPv6 was selected over IPv4 because IPv6 is expected to be a viable protocol into the foreseeable future. Although not described in the WAVE standards, IPv4 has been tunnelled over IPv6 in some WAVE trials. The document provides requirements for IPv6 configuration, in particular for the address setting. It specifies the details of the different service primitives, among which is the WAVE Routing Advertisement (WRA), part of the WAVE Service Advertisement (WSA). When present, the WRA provides information about infrastructure internetwork connectivity, allowing receiving devices to be configured to participate in the advertised IPv6 network. For example, an RSU can broadcast in the WRA portion of its WSA all the information necessary for an OBU to access an application-service Jeong, et al. Expires October 1, 2017 [Page 24] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 available over IPv6 through the RSU as a router. This feature removes the need for an IPv6 Router Advertisement message, which are based on ICMPv6. 9.3. ETSI Intelligent Transport Systems: Transmission of IPv6 Packets over GeoNetworking Protocols ETSI published a standard specifing the transmission of IPv6 packets over the ETSI GeoNetworking (GN) protocol [ETSI-GeoNetworking] [ETSI-GeoNetwork-IPv6]. IPv6 packet transmission over GN is defined in ETSI EN 302 636-6-1 [ETSI-GeoNetwork-IPv6] using a protocol adaptation sub-layer called "GeoNetworking to IPv6 Adaptation Sub- Layer (GN6ASL)". It enables an ITS station (ITS-S) running the GN protocol and an IPv6-compliant protocol layer to: (i) exchange IPv6 packets with other ITS-S; (ii) acquire globally routable IPv6 unicast addresses and communicate with any IPv6 host located in the Internet by having the direct connectivity to the Internet or via other relay ITS stations; (iii) perform operations as a Mobile Router for network mobility [RFC3963]. The document introduces three types of virtual link, the first one providing symmetric reachability by means of stable geographically scoped boundaries and two others that can be used when the dynamic definition of the broadcast domain is required. The combination of these three types of virtual link in the same station allows running the IPv6 ND protocol including Stateless Address Autoconfiguration (SLAAC) [RFC4862] as well as to distribute other IPv6 link-local multicast traffic and, at the same time, to reach nodes that are outside specific geographic boundaries. The IPv6 virtual link types are provided by the GN6ASL to IPv6 in the form of virtual network interfaces. The document also describes how to support bridging on top of the GN6ASL, how IPv6 packets are encapsulated IN GN packets and delivered, as well as the support of IPv6 multicast and anycast traffic, and neighbour discovery. For latency reasons, the standard strongly recommends to use SLAAC for the address configuration. Finally, the document includes the required operations to support the change of pseudonym, e.g., changing IPv6 addresses when the GN address is changed, in order to prevent attackers from tracking the ITS-S. 9.4. ISO Intelligent Transport Systems: Communications Access for Land Mobiles (CALM) Using IPv6 Networking ISO published a standard specifying the IPv6 network protocols and services [ISO-ITS-IPv6]. These services are necessary to support the Jeong, et al. Expires October 1, 2017 [Page 25] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 global reachability of ITS stations (ITS-S), the continuous Internet connectivity for ITS-S, and the handover functionality required to maintain such connectivity. This functionality also allows legacy devices to effectively use an ITS-S as an access router to connect to the Internet. Essentially, this specification describes how IPv6 is configured to support ITS-S and provides the associated management functionality. The requirements apply to all types of nodes implementing IPv6: personal, vehicle, roadside, or central node. The standard defines IPv6 functional modules that are necessary in an IPv6 ITS-S, covering IPv6 forwarding, interface between IPv6 and lower layers (e.g., LAN interface), mobility management, and IPv6 security. It defines the mechanisms to be used to configure the IPv6 address for static nodes as well as for mobile nodes, while maintaining the addressing reachability from the Internet. 10. Summary and Analysis This document surveyed state-of-the-arts technologies for IP-based vehicular networks, such as IP address autoconfiguration, vehicular network architecture, vehicular network routing, and mobility management. Through this survey, it is learned that IPv6-based vehicular networking can be well-aligned with IEEE WAVE standards for various vehicular network applications, such as driving safety, efficient driving, and infotainment. However, since the IEEE WAVE standards do not recommend to use the IPv6 ND protocol for the communication efficiency under high-speed mobility, it is necessary to adapt the ND for vehicular networks with such high-speed mobility. The concept of a link in IPv6 does not match that of a link in VANET because of the physical separation of communication ranges of vehicles in a connected VANET. That is, in a linear topology of three vehicles (Vehicle-1, Vehicle-2, and Vehicle-3), Vehicle-1 and Vehicle-2 can communicate directly with each other. Vehicle-2 and Vehicle-3 can communicate directly with each other. However, Vehicle-1 and Vehicle-3 cannot communicate directly with each other due to the out-of-communication range. For the link in IPv6, all of three vehicles are on a link, so they can communicate directly with each other. On the other hand, in VANET, this on-link communication concept is not valid in VANET. Thus, the IPv6 ND should be extended to support this multi-link subnet of a connected VANET through either ND proxy or VANET routing. For IP-based networking, IP address autoconfiguration is a prerequisite function. Since vehicles can communicate intermittently Jeong, et al. Expires October 1, 2017 [Page 26] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 with TCC via RSUs through V2I communications, TCC can play a role of a DHCP server to allocate unique IPv6 addresses to the vehicles. This centralized address allocation can remove the delay of the DAD procedure for testing the uniqueness of IPv6 addresses. For routing and mobility management, most of vehicles are equipped with a GPS navigator as a dedicated navigation system or a smartphone App. With this GPS navigator, vehicles can share their current position and trajectory (i.e., navigation path) with TCC. TCC can predict the future positions of the vehicles with their mobility information (i.e., the current position, speed, direction, and trajectory). With the prediction of the vehicle mobility, TCC supports RSUs to perform data packet routing and handover proactively. 11. Security Considerations Security and privacy are important aspects in vehicular networks. Only valid vehicles should be allowed to participate in vehicular networking. Vehicle Identification Number (VIN) and user certificate can be used to authenticate a vehicle and user through road infrastructure, such as Road-Side Unit (RSU) connected to an authentication server in Traffic Control Center (TCC). 12. Acknowledgements This work was supported by Institute for Information & communications Technology Promotion (IITP) grant funded by the Korea government (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence Technology Development for the Customized Security Service Provisioning). This work was supported in part by ICT R&D program of MSIP/IITP (14-824-09-013, Resilient Cyber-Physical Systems Research) and the DGIST Research and Development Program (CPS Global Center) funded by the Ministry of Science, ICT & Future Planning. This work was supported in part by the French research project DataTweet (ANR- 13-INFR-0008) and in part by the HIGHTS project funded by the European Commission I (636537-H2020). 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad Hoc Networks", Jeong, et al. Expires October 1, 2017 [Page 27] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 RFC 5889, September 2010. [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, September 2010. 13.2. Informative References [Address-Autoconf] Fazio, M., Palazzi, C., Das, S., and M. Gerla, "Automatic IP Address Configuration in VANETs", ACM International Workshop on Vehicular Inter-Networking, September 2016. [Address-Assignment] Kato, T., Kadowaki, K., Koita, T., and K. Sato, "Routing and Address Assignment using Lane/Position Information in a Vehicular Ad-hoc Network", IEEE Asia-Pacific Services Computing Conference, December 2008. [GeoSAC] Baldessari, R., Bernardos, C., and M. Calderon, "GeoSAC - Scalable Address Autoconfiguration for VANET Using Geographic Networking Concepts", IEEE International Symposium on Personal, Indoor and Mobile Radio Communications, September 2008. [Identities-Management] Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer Identities Management in ITS Stations", 10th International Conference on ITS Telecommunications, November 2010. [VIP-WAVE] Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the Feasibility of IP Communications in 802.11p Vehicular Networks", IEEE Transactions on Intelligent Transportation Systems, March 2013. [IPv6-WAVE] Baccelli, E., Clausen, T., and R. Wakikawa, "IPv6 Operation for WAVE - Wireless Access in Vehicular Environments", IEEE Vehicular Jeong, et al. Expires October 1, 2017 [Page 28] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 Networking Conference, December 2010. [Vehicular-Network-Framework] Jemaa, I., Shagdar, O., and T. Ernst, "A Framework for IP and non-IP Multicast Services for Vehicular Networks", Third International Conference on the Network of the Future, November 2012. [Joint-IP-Networking] Petrescu, A., Boc, M., and C. Ibars, "Joint IP Networking and Radio Architecture for Vehicular Networks", 11th International Conference on ITS Telecommunications, August 2011. [FleetNet] Bechler, M., Franz, W., and L. Wolf, "Mobile Internet Access in FleetNet", 13th Fachtagung Kommunikation in verteilten Systemen, February 2001. [Vehicular-DTN] Soares, V., Farahmand, F., and J. Rodrigues, "A Layered Architecture for Vehicular Delay-Tolerant Networks", IEEE Symposium on Computers and Communications, July 2009. [IP-Passing-Protocol] Chen, Y., Hsu, C., and W. Yi, "An IP Passing Protocol for Vehicular Ad Hoc Networks with Network Fragmentation", Elsevier Computers & Mathematics with Applications, January 2012. [VANET-Geo-Routing] Tsukada, M., Jemaa, I., Menouar, H., Zhang, W., Goleva, M., and T. Ernst, "Experimental Evaluation for IPv6 over VANET Geographic Routing", IEEE International Wireless Communications and Mobile Computing Conference, June 2010. [H-DMM] Nguyen, T. and C. Bonnet, "A Hybrid Centralized-Distributed Mobility Management for Supporting Highly Mobile Users", IEEE International Conference on Communications, June 2015. [H-NEMO] Nguyen, T. and C. Bonnet, "A Hybrid Jeong, et al. Expires October 1, 2017 [Page 29] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 Centralized-Distributed Mobility Management Architecture for Network Mobility", IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks, June 2015. [NEMO-LMS] Soto, I., Bernardos, C., Calderon, M., Banchs, A., and A. Azcorra, "NEMO- Enabled Localized Mobility Support for Internet Access in Automotive Scenarios", IEEE Communications Magazine, May 2009. [NEMO-VANET] Chen, Y., Hsu, C., and C. Cheng, "Network Mobility Protocol for Vehicular Ad Hoc Networks", Wiley International Journal of Communication Systems, November 2014. [PMIPv6-NEMO-Analysis] Lee, J., Ernst, T., and N. Chilamkurti, "Performance Analysis of PMIPv6-Based Network MObility for Intelligent Transportation Systems", IEEE Transactions on Vehicular Technology, January 2012. [Vehicular-Network-MM] Peng, Y. and J. Chang, "A Novel Mobility Management Scheme for Integration of Vehicular Ad Hoc Networks and Fixed IP Networks", Springer Mobile Networks and Applications, February 2010. [SDN-DMM] Nguyen, T., Bonnet, C., and J. Harri, "SDN-based Distributed Mobility Management for 5G Networks", IEEE Wireless Communications and Networking Conference, April 2016. [Vehicular-IP-MM] Cespedes, S., Shen, X., and C. Lazo, "IP Mobility Management for Vehicular Communication Networks: Challenges and Solutions", IEEE Communications Magazine, May 2011. [Securing-VCOMM] Fernandez, P., Santa, J., Bernal, F., and A. Skarmeta, "Securing Vehicular Jeong, et al. Expires October 1, 2017 [Page 30] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 IPv6 Communications", IEEE Transactions on Dependable and Secure Computing, January 2016. [VNET-AAA] Moustafa, H., Bourdon, G., and Y. Gourhant, "Providing Authentication and Access Control in Vehicular Network Environment", IFIP TC- 11 International Information Security Conference, May 2006. [WAVE-1609.0] IEEE 1609 Working Group, "IEEE Guide for Wireless Access in Vehicular Environments (WAVE) - Architecture", IEEE Std 1609.0-2013, March 2014. [WAVE-1609.3] IEEE 1609.3 Working Group, "IEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Networking Services", IEEE Std 1609.3- 2016, April 2016. [ETSI-GeoNetworking] ETSI Technical Committee Intelligent Transport Systems, "Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 4: Geographical addressing and forwarding for point-to-point and point-to- multipoint communications; Sub-part 1: Media-Independent Functionality", ETSI EN 302 636-4-1, May 2014. [ETSI-GeoNetwork-IPv6] ETSI Technical Committee Intelligent Transport Systems, "Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 6: Internet Integration; Sub-part 1: Transmission of IPv6 Packets over GeoNetworking Protocols", ETSI EN 302 636-6-1, October 2013. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Jeong, et al. Expires October 1, 2017 [Page 31] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 Autoconfiguration", RFC 4862, September 2007. [ISO-ITS-IPv6] ISO/TC 204, "Intelligent Transport Systems - Communications Access for Land Mobiles (CALM) - IPv6 Networking", ISO 21210:2012, June 2012. Appendix A. Changes from draft-jeong-ipwave-vehicular-networking-survey-01 The following changes are made from draft-jeong-ipwave-vehicular-networking-survey-01: o In Section 4.4, cross-layer identities management in ITS stations is added for the IP address autoconfiguration of ITS stations (e.g., vehicles) in vehicular networks using multiple access network technologies. o Typos are corrected. Authors' Addresses Jaehoon Paul Jeong Department of Software Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 440-746 Republic of Korea Phone: +82 31 299 4957 Fax: +82 31 290 7996 EMail: pauljeong@skku.edu URI: http://iotlab.skku.edu/people-jaehoon-jeong.php Sandra Cespedes Department of Electrical Engineering Universidad de Chile Av. Tupper 2007, Of. 504 Santiago, 8370451 Chile Phone: +56 2 29784093 EMail: scespede@niclabs.cl Jeong, et al. Expires October 1, 2017 [Page 32] =20 Internet-Draft IP-based Vehicular Networking Survey March 2017 Nabil Benamar Department of Computer Sciences High School of Technology of Meknes Moulay Ismail University Morocco Phone: +212 6 70 83 22 36 EMail: benamar73@gmail.com Jerome Haerri Communication Systems Department EURECOM Sophia-Antipolis France Phone: +33 4 93 00 81 34 EMail: jerome.haerri@eurecom.fr Michelle Wetterwald FBConsulting 21, Route de Luxembourg Wasserbillig, Luxembourg L-6633 Luxembourg EMail: Michelle.Wetterwald@gmail.com Jeong, et al. Expires October 1, 2017 [Page 33] Html markup produced by rfcmarkup 1.121, available from = https://tools.ietf.org/tools/rfcmarkup/ ------=_NextPart_000_0038_01D2AFA0.A8B07350-- From nobody Fri Apr 7 12:00:52 2017 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 C3E14129613 for ; Fri, 7 Apr 2017 12:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 r5iCoEgMG_ds for ; Fri, 7 Apr 2017 12:00:48 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 72B83129890 for ; Fri, 7 Apr 2017 12:00:40 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id t20so115041054wra.1 for ; Fri, 07 Apr 2017 12:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=YPZmHmOOrGFCb6TrOK64NfnEoyILFzP5gt68Fm8cGAI=; b=TB9LDQv+A6EMZPrQity6iiAqARgZxmNK8/zmpVtwt1da7+m0zWqZIk7USlh8l5l6PD HCuzzEAuI8esnDzRNRMlFhVvnuCg5jb5Uc20iqOGCw8qivWWBONfbRx1TRFJTLWNLfQy Ko/BVkIiximKtHNIuEZXwZmC1uftD8KXtSGnB7CRAPHuIK8vqUYsIhDZ8jwM3fgi66qu gWZEVP3e5eZGT3JZAOAraKvvo882U6FduFRcOnvlndkmsq7omkCyK4h0VU+rjdYMg53p tQVBSrBRbsOZgsNxmkLNpdbr10IWw7QoynBAC3D7SqU47klPfjKrz9ZYtD50aAFz7Byv LyvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YPZmHmOOrGFCb6TrOK64NfnEoyILFzP5gt68Fm8cGAI=; b=PMvl6dLHcGU5vESDi8BJDJFccKX71j9Fe/39Iha8R7icUtb0nZKa1LeUw2a0qy4NI9 J2H1q9WarCPiF97dugZ+7TFge0WDKhVUUmtZKdnWRzkx/r4w+1lSScERawYn4l8UCNmM OA4UvwGea9CkViNFJZEi/QOE4l3X1O8nJVadHSpWD7p55f9Yb/MJKXAC8r1fSbrrYikO IBU3psdNT6XPs7t6t1RtzgKplVHTHFOudZQGS5nddfywUIpdm1wLK+/w1xnmQ7bRwuTw XPVHriCRJ5kAQmwRUVDnxckVu0P9CGPcJrJOQBWgFW630vt493PuiRNR5o+53UcaPCq3 uFPw== X-Gm-Message-State: AFeK/H2fV6/xVwf4hlJyGqNM6v0SImqIeg4XnkbhbW2uFkeIMtOec+8NoI8tJKQ0bdpx0jz8m9rZ3w5/lRPW7w== X-Received: by 10.223.150.120 with SMTP id c53mr8550286wra.85.1491591638621; Fri, 07 Apr 2017 12:00:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.175.82 with HTTP; Fri, 7 Apr 2017 12:00:38 -0700 (PDT) From: Dorothy Stanley Date: Fri, 7 Apr 2017 12:00:38 -0700 Message-ID: To: its@ietf.org Content-Type: multipart/alternative; boundary=001a113e1156c52685054c983d36 Archived-At: Subject: [ipwave] Comment on https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb - 802.11 document reference 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, 07 Apr 2017 19:00:51 -0000 --001a113e1156c52685054c983d36 Content-Type: text/plain; charset=UTF-8 Propose to change "IEEE Std 802.11 -2012" references to "IEEE Std 802.11-2016". In particular, section 1: "In the following text we use the term "802.11p" to mean 802.11-2012 OCB." should refer to the 2016 version (the 2016 version uses Ethertype Protocol Discrimination (EDP) rather than LLC Protocol Discrimination (LPD) in the 5.9 GHz bands). Dorothy ---------------------- Dorothy Stanley Hewlett Packard Enterprise dorothy.stanley@hpe.com dstanley1389@gmail.com +1 630-363-1389 <630-363-1389> --001a113e1156c52685054c983d36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Propose to change "IEEE Std 802.11 -2012" refe= rences to "IEEE Std 802.11-2016".
In particul= ar, section 1: "In the following text we use the term "= ;802.11p" to mean 802.11-2012 OCB."
sh= ould refer to the 2016 version (the 2016 version uses Ethertype Protocol Di= scrimination (EDP) rather than LLC P= rotocol Discrimination (LPD) in the 5.9 = GHz bands).
Dorothy
--001a113e1156c52685054c983d36-- From nobody Fri Apr 7 23:36:48 2017 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 063011204DA for ; Fri, 7 Apr 2017 23:36:47 -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 T0Fbur86qbn5 for ; Fri, 7 Apr 2017 23:36:44 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 F1C141289B0 for ; Fri, 7 Apr 2017 23:36:43 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id l189so5212532ywb.0 for ; Fri, 07 Apr 2017 23:36:43 -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=JGBWWTpdQdLQU3X07SRkXqDPlligF21xP6rCM5pK8j0=; b=ULkZ3pBxOmtJj0kbAafqoQo4/rYUWJEOuHigGjHWghUuDaZPMFm+42tyJeFLBJgLNW zeNtreUObBzhK0Fs9/cIPHs7FG639ie7j/4i9C9eelRZZZW702wvAjAdALzPcOtkmSXb 57mE8suSpIxu+PNils9ahJFrf7ZlAUrjnCvGqab67l828su5eFXvqpPkGUIYpZ5Caw+L 9y9cEX9FvzU6dq06vTNE8D1aDk8N7MflMYHAuBYxbNlSnSSdlsm7PqyzbABxJ2FUuf+n K/QNmUp7w9delRmEkZ2VgE70JZwF3Ec9psu2nBXA0dxh7LrBA7fVP+JWOV8wI9Dhby0c A3fQ== 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=JGBWWTpdQdLQU3X07SRkXqDPlligF21xP6rCM5pK8j0=; b=fYnBjEGPArQzAYk0Og9fIQUdMVXeU4KrQcGLVHsDcwZvynO1zLAveTudUMYsNZVeVV c4bhMKj68IGNfdaWHez741Wu30lZJ9ZpWzvbZcvOJofEfXXQM6pIAZEHVcZ41afVp3QU K+jGy/ZUFYpwCyJZDQ5vfZslDW8b+A6gGoNFuyOcdzhYmA2DS3veHAbtbEkyzQq3Co4Q bR9SZcjoUtVVpahN2K8qehLmG5/GpveymEJuBD/uEQKbIMj0zH28EUtU22eXtOTFBVN9 rGTQqcFHGAuFe0a8NGEEC8wKh5/1v4uUkORqok/eL1/d936QzmzxUTFCW4CjoHNIYhKQ x/WQ== X-Gm-Message-State: AFeK/H03iRwW3Ua5sKwAxRe3BPKvuL2uwYeHxqJcqdPHXttCSXUGEebBiKd4JfLz7fK8eKZSp5hl2CLEldHDJg== X-Received: by 10.129.71.130 with SMTP id u124mr28650142ywa.294.1491633403137; Fri, 07 Apr 2017 23:36:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.210.4 with HTTP; Fri, 7 Apr 2017 23:36:12 -0700 (PDT) In-Reply-To: <049601d2af83$cfa0e390$6ee2aab0$@gmail.com> References: <1491334470.3575.9.camel@it.uc3m.es> <049601d2af83$cfa0e390$6ee2aab0$@gmail.com> From: "Mr. Jaehoon Paul Jeong" Date: Sat, 8 Apr 2017 15:36:12 +0900 Message-ID: To: =?UTF-8?Q?Fran=C3=A7ois_Simon?= Cc: its@ietf.org Content-Type: multipart/alternative; boundary=001a114d7496211366054ca1f71d Archived-At: Subject: Re: [ipwave] Draft minutes of IPWAVE@IETF98 available 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: Sat, 08 Apr 2017 06:36:47 -0000 --001a114d7496211366054ca1f71d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Fran=C3=A7ois, Thanks for your feedback. Best Regards, Paul On Fri, Apr 7, 2017 at 6:46 PM, Fran=C3=A7ois Simon wr= ote: > Mr. Jaehoon, > > > > Please, find my comments on the minutes attached. I was not present at > the meeting. Also find additional comments below. > > > > *From:* its [mailto:its-bounces@ietf.org] *On Behalf Of *Mr. Jaehoon Paul > Jeong > *Sent:* Wednesday, April 05, 2017 11:08 PM > *To:* Michelle Wetterwald > *Cc:* Russ Housley ; its@ietf.org; CARLOS JESUS > BERNARDOS CANO > *Subject:* Re: [ipwave] Draft minutes of IPWAVE@IETF98 available > > > > Hi all, > > Though IEEE 802.2 LLC is not used by WAVE Protocol Stack, > > LLC is part of WAVE Networking Services specified by IEEE 1609.3.Fygs:=E2= =80=93 > Per OSI, LLC is a sub-layer of the Data Link Layer (it happen to be > specified in 1609.3.] > > That is, WAVE LLC is slightly different from IEEE 802.2 LLC. =E2=80=93 [F= ygs =E2=80=93 Is > not =E2=80=9Cslightly=E2=80=9D it is different=E2=80=9D the LLC in US for= 5.9 GHz is *EtherType > Protocol Discrimination (EPD].* > > > > The functions of Networking Services in IEEE 1609.3 are as follows: > > > > 1. Data Plane at WAVE Protocol Stack > > - Logical Link Control (LLC) =E2=80=93 [Fygs: EPD] > > - IPv6, and transport layer protocols (e.g., TCP and UDP) > > - WAVE Short Message Protocol (WSMP) Transport protocols/Networking > protocols > > > > 2. Management Plane at WAVE Management Entity (WME) > > - Service requests and channel access assignment > > - WAVE Service Advertisement monitoring > > - IPv6 configuration > > - MIB maintenance [Fygs: MIBs are within the Layer Management Entity > (LME) associated with EACH layer] > > - [Fygs: Security is included in the System > Management Entity (SME)] > > > > Thanks. > > > > Best Regards, > > Paul > > > > > > On Wed, Apr 5, 2017 at 7:22 PM, Michelle Wetterwald < > mlwetterwald@gmail.com> wrote: > > Hi Carlos, > > > > Thank you very much for these minutes. > > > > I would like to ask for update on the notes about the survey discussion. > > > > I think it was said that "802.2 does not exist anymore". rather than > "1609.2 does not exist anymore." > > > > Best regards, > > Michelle > > > > > > 2017-04-04 21:34 GMT+02:00 Carlos Jes=C3=BAs Bernardos Cano : > > Hi, > > We've just posted the minutes: > > https://www.ietf.org/proceedings/98/minutes/minutes-98-ipwave-01 > > Please send corrections/comments by Friday, Apr 7th. > > Thanks a lot to Danny and Bob for taking the minutes! > > Cheers, > > Carlos & Russ > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > -- > > Michelle Wetterwald > > michelle.wetterwald@gmail.com > > > _______________________________________________ > 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 --001a114d7496211366054ca1f71d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Fran=C3=A7ois,
Thanks for your feedback.
=
Best Regards,
Paul

On Fri, Apr 7, 2017 at 6:46 PM, Fran= =C3=A7ois Simon <fygsimon@gmail.com> wrote:

Mr. Jaehoon,

=C2=A0

Please, find my comments on the minutes attached.=C2=A0 I was not prese= nt at the meeting.=C2=A0 Also find additional comments below.=

=C2=A0

From: its [mailto:its-bounces@ietf.org] On Behalf Of Mr. = Jaehoon Paul Jeong
Sent: Wednesday, April 05, 2017 11:08 PM
To: Michelle Wetterwald <mlwetterwald@gmail.com>
Cc: Russ Housley= <housley@vigi= lsec.com>; its@iet= f.org; CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Subject: Re: [ipwave= ] Draft minutes of IPWAVE@IETF98 available

=C2=A0

Hi all,

Though IEEE 8= 02.2 LLC is not used by WAVE Protocol Stack,

=

LLC is part of WAVE Networking Services specifi= ed by IEEE 1609.3.Fygs:=E2=80=93 Per OSI, LLC= is a sub-layer of the Data Link Layer (it happen to be specified in 1609.3= .]

That is, WAVE = LLC is slightly different from IEEE 802.2 LLC. =E2=80=93 [Fygs =E2=80=93 Is not =E2=80=9Cslightly=E2=80=9D it is differe= nt=E2=80=9D the LLC in US for 5.9 GHz is EtherType Protoc= ol Discrimination (EPD].

=C2=A0

The functions of Networking Services in IEEE 1609.3 are as f= ollows:

=C2=A0=

1. D= ata Plane at WAVE Protocol Stack

=C2=A0- Logical Link Control (LLC) =E2=80=93 [Fygs: EPD]

=

=C2=A0- IPv6, and transport layer protocols (e.= g., TCP and UDP)

=C2=A0-= WAVE Short Message Protocol (WSMP) Transport protocols/Networking protocol= s

=C2=A0

2. Management Plane at WAVE Management = Entity (WME)

=C2=A0- Ser= vice requests and channel access assignment

=C2=A0- WAVE Service Advertisement monitoring=

=C2=A0- IPv6 configuration=

=C2=A0- MIB maintenance= [Fygs: MIBs are within the Layer Management = Entity (LME) associated with EACH layer]

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [F= ygs: Security is included in the System Management Entity (SME)]<= /u>

=C2=A0<= /p>

Thanks.

=C2=A0

Best Regards,

Paul

=C2=A0

<= /div>

=C2=A0=

On Wed, Apr 5, 2017 at 7:22 PM, Mich= elle Wetterwald <mlwetterwald@gmail.com> wrote:

Hi Ca= rlos,

=C2=A0

Thank you very much for these minut= es.

=C2=A0=

I would like to ask for update on the= notes about the survey discussion.

=C2=A0

I thi= nk it was said that "802.2 does not exist anymore". rather than &= quot;1609.2 does not exist anymore."

=C2=A0

Best regards,

Michelle<= u>

=C2=A0

=C2=A0

2017-0= 4-04 21:34 GMT+02:00 Carlos Jes=C3=BAs Bernardos Cano <cjbc@it.uc3m.es>:<= /p>

Hi,

We've just posted the minutes:

https://www.ietf.org/proceedings/98/minutes/minutes-98-ipwave-01=

Please send corrections/comments by Friday, Apr 7th.

Tha= nks a lot to Danny and Bob for taking the minutes!

Cheers,

Ca= rlos & Russ

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



-- =


_____________________________________________= __
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its=



=

=C2=A0

--

=

=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

<= /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 Professor
Departm= ent of Software
Sungkyunkwan University
Office: +82-31-299-4957
Em= ail: jaehoon.pa= ul@gmail.com,=C2=A0pauljeong@skku.edu
Person= al Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
--001a114d7496211366054ca1f71d-- From nobody Fri Apr 7 23:38:48 2017 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 8A14C124D37 for ; Fri, 7 Apr 2017 23:38:46 -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=unavailable 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 EfDlsXB__Gwn for ; Fri, 7 Apr 2017 23:38:45 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 C523E127419 for ; Fri, 7 Apr 2017 23:29:27 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id d191so42760308ywe.2 for ; Fri, 07 Apr 2017 23:29:27 -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=S44UhsbXzON8i2+OhojTzsImOMp5ppDthqLvt4SyfXA=; b=RZZd3lM38ozYWb/1wViFCgODnyT8JqGz9ICz/qa+cQbJulSJiseWPOiG+uxbhpVAxz uWJIAwZVZA/WrPrM7M1xtu51CmVj/r3XD37n5h+KwEBVP9fVsdim502iB0e1R3hjWj/n InAgo2NFhOvM9UPgZ5yCtsmBG4HVRh12FtxOYogUhj/0TWVl5zm9rFFCuKtvc+3iyy8U ZQDCPorj6LyL9rReKA+43YeuVK/Wa2kKoHnst3BjuTpusmfD61k51wgZnAO3vmil+jl5 GGJ/IE/zuQ1w2eL7KyxBi/vpLqQ4nme0UhF9CaRK8yNlphdoUj4TUoC3CKSQYkN5GwHL uguw== 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=S44UhsbXzON8i2+OhojTzsImOMp5ppDthqLvt4SyfXA=; b=ePd1J7bnexOTY6racclpUlNi6E3aedZOvr29S+wiETOb9+S51bgRMNdGKgd/0JIUAr xg9HoBVfbdTv3x6KE+bfnC4MI0WWkDs6HPJCa4HmqoE8rB8lU8kyge0kb5JB8ibyL25k uIz5tZAE1vC5pjNkq9jc3kstNqnCL/GJY3GpPiAJsRS7SfAW/w3NjLHNWgdVgIascPnk X0rdj+mHOG86/2cb5ZXbdodxZK5moJV9pABnjq5cj7+2l2/J2ab1NpK+UUFQmsbm1gMW sibjMg9x9QLoHY2bvr8YmMKQt2uvJXusMVzjHtve36vR1NrIABnYwSPzxqR5NupLL9tr d7mg== X-Gm-Message-State: AFeK/H0BXD2JanqAmrYJt75/7vQLXxtPdD0X61BMJPYyxk22oIbv6YGZEsX7azXY+IZoV99EYevaTuQS4tT37g== X-Received: by 10.13.222.66 with SMTP id h63mr29237614ywe.347.1491632966977; Fri, 07 Apr 2017 23:29:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.210.4 with HTTP; Fri, 7 Apr 2017 23:28:56 -0700 (PDT) In-Reply-To: <003701d2afc2$2fc21350$8f4639f0$@gmail.com> References: <003701d2afc2$2fc21350$8f4639f0$@gmail.com> From: "Mr. Jaehoon Paul Jeong" Date: Sat, 8 Apr 2017 15:28:56 +0900 Message-ID: To: =?UTF-8?Q?Fran=C3=A7ois_Simon?= Cc: "Jaehoon (Paul) Jeong" , its@ietf.org Content-Type: multipart/alternative; boundary=94eb2c07d64021d00a054ca1ddcf Archived-At: Subject: Re: [ipwave] draft-jeong-ipwave-vehicular-networking-survey-02 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: Sat, 08 Apr 2017 06:38:47 -0000 --94eb2c07d64021d00a054ca1ddcf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Thanks for your detailed comments, I will consider and reflect yours on the revision. Best Regards, Paul On Sat, Apr 8, 2017 at 2:12 AM, Fran=C3=A7ois Simon wr= ote: > Sir, > > > > Find a few comments related to the document referenced above. > > > > If you have any questions, please let me know. > > > > Sincerely, > > > > Francois Simon > > _______________________________________________ > 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 --94eb2c07d64021d00a054ca1ddcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi=C2=A0

Thanks for your detailed comme= nts,

I will consider and reflect yours on the revi= sion.

Best Regards,
Paul

<= /div>

On Sat= , Apr 8, 2017 at 2:12 AM, Fran=C3=A7ois Simon <fygsimon@gmail.com>= wrote:

Sir,

<= u>=C2=A0

Find a few comments related t= o the document referenced above.

=C2=A0

If you have any questions, ple= ase let me know.

=C2=A0

Sincerely,

=C2=A0

Francois Simon


_____________________________________________= __
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) J= eong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwa= n 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
--94eb2c07d64021d00a054ca1ddcf-- From nobody Mon Apr 10 08:29:44 2017 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 72115128BA2 for ; Mon, 10 Apr 2017 08:29:42 -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 rkw7j13_3iQ2 for ; Mon, 10 Apr 2017 08:29:41 -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 E135A12952C for ; Mon, 10 Apr 2017 08:29:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 583B130044A for ; Mon, 10 Apr 2017 11:29:40 -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 fBvUklwXk9VQ for ; Mon, 10 Apr 2017 11:29:39 -0400 (EDT) Received: from new-host-5.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 0DD2E300098; Mon, 10 Apr 2017 11:29:38 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley X-Priority: 3 In-Reply-To: <20170407031430.57DD1C80853@webmail.sinamail.sina.com.cn> Date: Mon, 10 Apr 2017 11:29:38 -0400 Cc: its , =?utf-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= Content-Transfer-Encoding: quoted-printable Message-Id: <1CD05859-E913-4BF3-A123-A55B63B8DDE3@vigilsec.com> References: <20170407031430.57DD1C80853@webmail.sinamail.sina.com.cn> To: langziwumingzhimi@sina.com X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ipwave] Draft minutes of IPWAVE@IETF98 available 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, 10 Apr 2017 15:29:42 -0000 I tried to add this to the minutes. Russ > On Apr 6, 2017, at 11:14 PM, langziwumingzhimi@sina.com wrote: >=20 > Hi, > I found my comment is missed in the minutes.=20 >=20 > For Survey on IP-based Vehicular Networking for ITS, I have comment on = its assumption. I point out that IEEE 802.11p is considered as MAC = protocol but NOT ONLY one to be considered. And I remembered John = responded that he will involve others into draft. >=20 > BRs, > Minpeng >=20 >=20 > ----- =E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6 ----- > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9ACarlos Jes=C3=BAs Bernardos Cano = > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9Aits@ietf.org > =E6=8A=84=E9=80=81=E4=BA=BA=EF=BC=9ARuss Housley = > =E4=B8=BB=E9=A2=98=EF=BC=9A[ipwave] Draft minutes of IPWAVE@IETF98 = available > =E6=97=A5=E6=9C=9F=EF=BC=9A2017=E5=B9=B404=E6=9C=8805=E6=97=A5 = 03=E7=82=B934=E5=88=86 >=20 >=20 > Hi, > We've just posted the minutes: > https://www.ietf.org/proceedings/98/minutes/minutes-98-ipwave-01 > Please send corrections/comments by Friday, Apr 7th. > Thanks a lot to Danny and Bob for taking the minutes! > Cheers, > Carlos & Russ > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Mon Apr 10 21:09:05 2017 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 45727129456 for ; Mon, 10 Apr 2017 21:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZiMCEbZIspl for ; Mon, 10 Apr 2017 21:09:00 -0700 (PDT) Received: from mail2-187.sinamail.sina.com.cn (mail2-187.sinamail.sina.com.cn [60.28.2.187]) by ietfa.amsl.com (Postfix) with SMTP id 7C19A1293FB for ; Mon, 10 Apr 2017 21:08:59 -0700 (PDT) Received: from webmail-2-49.pop3.fmail.tg.sinanode.com (HELO webmail.sinamail.sina.com.cn)([172.16.201.49]) by sina.com with SMTP 11 Apr 2017 12:08:58 +0800 (CST) X-Sender: langziwumingzhimi@sina.com X-SMAIL-MID: 1805595505589 Received: by webmail.sinamail.sina.com.cn (Postfix, from userid 496) id 0C2FEB000D0; Tue, 11 Apr 2017 12:08:58 +0800 (CST) Date: Tue, 11 Apr 2017 12:08:58 +0800 Received: from langziwumingzhimi@sina.com([221.130.253.135]) by m0.mail.sina.com.cn via HTTP; Tue, 11 Apr 2017 12:08:58 +0800 (CST) Reply-To: langziwumingzhimi@sina.com From: To: "Russ Housley" Cc: =?UTF-8?B?Q2FybG9zX0plc8O6c19CZXJuYXJkb3NfQ2Fubw==?= , "its" , MIME-Version: 1.0 X-Priority: 3 X-MessageID: 58ec56dadf4aab X-Originating-IP: [172.16.201.49] X-Mailer: Sina WebMail 4.0 Content-Type: multipart/alternative; boundary="=-sinamail_alt_fd71eb5f44b918248dbad3a7daf305b4" Message-Id: <20170411040858.0C2FEB000D0@webmail.sinamail.sina.com.cn> Archived-At: Subject: [ipwave] =?gbk?b?u9i4tKO6UmU6ICBEcmFmdCBtaW51dGVzIG9mIElQV0FWRUBJ?= =?gbk?q?ETF98_available?= 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, 11 Apr 2017 04:09:03 -0000 --=-sinamail_alt_fd71eb5f44b918248dbad3a7daf305b4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline VGhhbmtzIFJ1c3MuCkFuZCBJIGZvdW5kIEkgbWlzdGFrZW5seSBzcGVsbGVkIEplb25nJ3MgbmFt ZSBhcyBKb2huLiBJJ20gc29ycnkgYWJvdXQgdGhhdC4KQlJzLE1pbnBlbmcKLS0tLS0g5Y6f5aeL 6YKu5Lu2IC0tLS0tCuWPkeS7tuS6uu+8mlJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5j b20+CuaUtuS7tuS6uu+8mmxhbmd6aXd1bWluZ3poaW1pQHNpbmEuY29tCuaKhOmAgeS6uu+8mkNh cmxvc19KZXPDunNfQmVybmFyZG9zX0Nhbm8gPGNqYmNAaXQudWMzbS5lcz4sIGl0cyA8aXRzQGll dGYub3JnPgrkuLvpopjvvJpSZTogW2lwd2F2ZV0gRHJhZnQgbWludXRlcyBvZiBJUFdBVkVASUVU Rjk4IGF2YWlsYWJsZQrml6XmnJ/vvJoyMDE35bm0MDTmnIgxMOaXpSAyM+eCuTMw5YiGCgpJIHRy aWVkIHRvIGFkZCB0aGlzIHRvIHRoZSBtaW51dGVzLgpSdXNzCj4gT24gQXByIDYsIDIwMTcsIGF0 IDExOjE0IFBNLCBsYW5neml3dW1pbmd6aGltaUBzaW5hLmNvbSB3cm90ZToKPiAKPiBIaSwKPiBJ IGZvdW5kIG15IGNvbW1lbnQgaXMgbWlzc2VkIGluIHRoZSBtaW51dGVzLiAKPiAKPiBGb3IgU3Vy dmV5IG9uIElQLWJhc2VkIFZlaGljdWxhciBOZXR3b3JraW5nIGZvciBJVFMsIEkgaGF2ZSBjb21t ZW50IG9uIGl0cyBhc3N1bXB0aW9uLiBJIHBvaW50IG91dCB0aGF0IElFRUUgODAyLjExcCBpcyBj b25zaWRlcmVkIGFzIE1BQyBwcm90b2NvbCBidXQgTk9UIE9OTFkgb25lIHRvIGJlIGNvbnNpZGVy ZWQuICBBbmQgSSByZW1lbWJlcmVkIEpvaG4gcmVzcG9uZGVkIHRoYXQgaGUgd2lsbCBpbnZvbHZl IG90aGVycyBpbnRvIGRyYWZ0Lgo+IAo+IEJScywKPiBNaW5wZW5nCj4gCj4gCj4gLS0tLS0g5Y6f 5aeL6YKu5Lu2IC0tLS0tCj4g5Y+R5Lu25Lq677yaQ2FybG9zIEplc8O6cyBCZXJuYXJkb3MgQ2Fu byA8Y2piY0BpdC51YzNtLmVzPgo+IOaUtuS7tuS6uu+8mml0c0BpZXRmLm9yZwo+IOaKhOmAgeS6 uu+8mlJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+Cj4g5Li76aKY77yaW2lwd2F2 ZV0gRHJhZnQgbWludXRlcyBvZiBJUFdBVkVASUVURjk4IGF2YWlsYWJsZQo+IOaXpeacn++8mjIw MTflubQwNOaciDA15pelIDAz54K5MzTliIYKPiAKPiAKPiBIaSwKPiBXZSd2ZSBqdXN0IHBvc3Rl ZCB0aGUgbWludXRlczoKPiBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85OC9taW51 dGVzL21pbnV0ZXMtOTgtaXB3YXZlLTAxCj4gUGxlYXNlIHNlbmQgY29ycmVjdGlvbnMvY29tbWVu dHMgYnkgRnJpZGF5LCBBcHIgN3RoLgo+IFRoYW5rcyBhIGxvdCB0byBEYW5ueSBhbmQgQm9iIGZv ciB0YWtpbmcgdGhlIG1pbnV0ZXMhCj4gQ2hlZXJzLAo+IENhcmxvcyAmIFJ1c3MKPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IGl0cyBtYWlsaW5nIGxp c3QKPiBpdHNAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2l0cwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwppdHMg bWFpbGluZyBsaXN0Cml0c0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2l0cwo= --=-sinamail_alt_fd71eb5f44b918248dbad3a7daf305b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5UaGFua3MgUnVzcy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkFuZCBJIGZvdW5kIEkg bWlzdGFrZW5seSBzcGVsbGVkIEplb25nJ3MgbmFtZSBhcyBKb2huLiBJJ20gc29ycnkgYWJvdXQg dGhhdC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkJScyw8L2Rpdj48ZGl2Pk1pbnBlbmc8L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2IGlkPSJvcmlnYm9keSI+PGRpdiBzdHlsZT0iYmFja2dyb3Vu ZDogI2YyZjJmMjsiPi0tLS0tIOWOn+Wni+mCruS7tiAtLS0tLTxicj7lj5Hku7bkurrvvJpSdXNz IEhvdXNsZXkgJmx0O2hvdXNsZXlAdmlnaWxzZWMuY29tJmd0Ozxicj7mlLbku7bkurrvvJpsYW5n eml3dW1pbmd6aGltaUBzaW5hLmNvbTxicj7mioTpgIHkurrvvJpDYXJsb3NfSmVzw7pzX0Jlcm5h cmRvc19DYW5vICZsdDtjamJjQGl0LnVjM20uZXMmZ3Q7LCBpdHMgJmx0O2l0c0BpZXRmLm9yZyZn dDs8YnI+5Li76aKY77yaUmU6IFtpcHdhdmVdIERyYWZ0IG1pbnV0ZXMgb2YgSVBXQVZFQElFVEY5 OCBhdmFpbGFibGU8YnI+5pel5pyf77yaMjAxN+W5tDA05pyIMTDml6UgMjPngrkzMOWIhjxicj48 L2Rpdj48YnI+SSB0cmllZCB0byBhZGQgdGhpcyB0byB0aGUgbWludXRlcy48YnI+UnVzczxicj4m Z3Q7IE9uIEFwciA2LCAyMDE3LCBhdCAxMToxNCBQTSwgbGFuZ3ppd3VtaW5nemhpbWlAc2luYS5j b20gd3JvdGU6PGJyPiZndDsgPGJyPiZndDsgSGksPGJyPiZndDsgSSBmb3VuZCBteSBjb21tZW50 IGlzIG1pc3NlZCBpbiB0aGUgbWludXRlcy4gPGJyPiZndDsgPGJyPiZndDsgRm9yIFN1cnZleSBv biBJUC1iYXNlZCBWZWhpY3VsYXIgTmV0d29ya2luZyBmb3IgSVRTLCBJIGhhdmUgY29tbWVudCBv biBpdHMgYXNzdW1wdGlvbi4gSSBwb2ludCBvdXQgdGhhdCBJRUVFIDgwMi4xMXAgaXMgY29uc2lk ZXJlZCBhcyBNQUMgcHJvdG9jb2wgYnV0IE5PVCBPTkxZIG9uZSB0byBiZSBjb25zaWRlcmVkLiAg QW5kIEkgcmVtZW1iZXJlZCBKb2huIHJlc3BvbmRlZCB0aGF0IGhlIHdpbGwgaW52b2x2ZSBvdGhl cnMgaW50byBkcmFmdC48YnI+Jmd0OyA8YnI+Jmd0OyBCUnMsPGJyPiZndDsgTWlucGVuZzxicj4m Z3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IC0tLS0tIOWOn+Wni+mCruS7tiAtLS0tLTxicj4mZ3Q7IOWP keS7tuS6uu+8mkNhcmxvcyBKZXPDunMgQmVybmFyZG9zIENhbm8gJmx0O2NqYmNAaXQudWMzbS5l cyZndDs8YnI+Jmd0OyDmlLbku7bkurrvvJppdHNAaWV0Zi5vcmc8YnI+Jmd0OyDmioTpgIHkurrv vJpSdXNzIEhvdXNsZXkgJmx0O2hvdXNsZXlAdmlnaWxzZWMuY29tJmd0Ozxicj4mZ3Q7IOS4u+mi mO+8mltpcHdhdmVdIERyYWZ0IG1pbnV0ZXMgb2YgSVBXQVZFQElFVEY5OCBhdmFpbGFibGU8YnI+ Jmd0OyDml6XmnJ/vvJoyMDE35bm0MDTmnIgwNeaXpSAwM+eCuTM05YiGPGJyPiZndDsgPGJyPiZn dDsgPGJyPiZndDsgSGksPGJyPiZndDsgV2UndmUganVzdCBwb3N0ZWQgdGhlIG1pbnV0ZXM6PGJy PiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvbWludXRlcy9taW51dGVz LTk4LWlwd2F2ZS0wMTxicj4mZ3Q7IFBsZWFzZSBzZW5kIGNvcnJlY3Rpb25zL2NvbW1lbnRzIGJ5 IEZyaWRheSwgQXByIDd0aC48YnI+Jmd0OyBUaGFua3MgYSBsb3QgdG8gRGFubnkgYW5kIEJvYiBm b3IgdGFraW5nIHRoZSBtaW51dGVzITxicj4mZ3Q7IENoZWVycyw8YnI+Jmd0OyBDYXJsb3MgJmFt cDsgUnVzczxicj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPiZndDsgaXRzIG1haWxpbmcgbGlzdDxicj4mZ3Q7IGl0c0BpZXRmLm9yZzxicj4m Z3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzPGJyPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPml0cyBtYWlsaW5nIGxp c3Q8YnI+aXRzQGlldGYub3JnPGJyPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXRzPGJyPjwvZGl2Pg== --=-sinamail_alt_fd71eb5f44b918248dbad3a7daf305b4-- From nobody Thu Apr 20 20:42:36 2017 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 8FDAB126D85 for ; Thu, 20 Apr 2017 20:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.922 X-Spam-Level: X-Spam-Status: No, score=-0.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id An9JMiO8vtM9 for ; Thu, 20 Apr 2017 20:42:32 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id C2E1C129401 for ; Thu, 20 Apr 2017 20:42:31 -0700 (PDT) Received: from yanzhiwei (unknown [218.241.111.47]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0A5QeGSf_lYSV6iKg--.20747S2; Fri, 21 Apr 2017 11:42:10 +0800 (CST) Date: Fri, 21 Apr 2017 11:42:08 +0800 From: "=?utf-8?B?Wi5XLiBZYW4=?=" To: "=?utf-8?B?aXRz?=" Cc: "=?utf-8?B?Sm9uZy1IeW91ayBMZWU=?=" Message-ID: <201704211142085733907@cnnic.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon756015151535_=====" X-CM-TRANSID: AQAAf0A5QeGSf_lYSV6iKg--.20747S2 X-Coremail-Antispam: 1UD129KBjvJXoW7tw1xCw4kuFyrWF1xtrWUArb_yoW8AF13pa n2qw47GwnYvrs2g397Xr1UuF15Ga9rX397GF12yry0yan8GF1IvryIkayYg3srZr13Kryq vw4xZwn8urn5X3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBvb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40Eb7x2 x7xS6r1j6r4UMc02F40Ew4AK048IF2xKxVWUJVW8JwAqx4xG6xAIxVCFxsxG0wAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lc2xSY4AK67AK6r48MxAIw2 8IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWl x2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrw CI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI 42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I 8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07jrZ2fUUUUU= X-CM-SenderInfo: x1dqqupqqluhdfq/ Archived-At: Subject: [ipwave] =?utf-8?q?Fw=3A_New_Version_Notification_for_draft-yan-i?= =?utf-8?q?pwave-nd-00=2Etxt?= 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, 21 Apr 2017 03:42:34 -0000 This is a multi-part message in MIME format. --=====003_Dragon756015151535_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGFsbCwNCldlIHVwZGF0ZWQgdGhlIGRyYWZ0IGFib3V0IG5laWdoYm9yIGRpc2NvdmVyeSBi YXNlZCBvbiBETlMtU0QvbUROUyBhbmQgcG9zdCB0aGlzIHZlcnNpb24gaW4gdGhlIElQV0FWRSBX Ry4NCkluIHRoaXMgdmVyc2lvbiwgd2UgZGVzY3JpYmUgdGhlIHByZWZpeCBtYW5hZ2VtZW50IG9m IG5hbWUgYW5kIGFkZHJlc3MgaW4gSVRTIGFuZCBpbGx1c3RyYXRlIHRoZSBwcm9jZWR1cmUgb2Yg DQpuZWlnaGJvciBub2RlIGFuZCBzZXJ2aWNlIGRpc2NvdmVyIGJhc2VkIG9uIEROUy1TRC9tRE5T IHVuZGVyIGRpZmZlcmVudCBzY2VuYXJpb3MuDQoNCldlbGNvbWUgYW55IGNvbW1lbnRzIGFuZCBp bnRlcmVzdC4NCkJSLA0KWmhpd2VpIFlhbg0KMjAxNy0wNC0yMQ0KDQoNCg0K5Y+R5Lu25Lq677ya IGludGVybmV0LWRyYWZ0cw0K5Y+R6YCB5pe26Ze077yaIDIwMTctMDQtMjEgMTE6MzU6MTcNCuaU tuS7tuS6uu+8miBaaGl3ZWkgWWFuOyBKb25nLUh5b3VrIExlZQ0K5oqE6YCB77yaIA0K5Li76aKY 77yaIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteWFuLWlwd2F2ZS1uZC0wMC50 eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXlhbi1pcHdhdmUtbmQtMDAudHh0DQpo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFpoaXdlaSBZYW4gYW5kIHBvc3RlZCB0 byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCk5hbWU6IGRyYWZ0LXlhbi1pcHdhdmUtbmQNClJldmlz aW9uOiAwMA0KVGl0bGU6IE5laWdoYm9yIGRpc2NvdmVyeSBpbiBJVFMNCkRvY3VtZW50IGRhdGU6 IDIwMTctMDQtMjANCkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiA3DQpVUkw6 ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXlh bi1pcHdhdmUtbmQtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQteWFuLWlwd2F2ZS1uZC8NCkh0bWxpemVkOiAgICAgICBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteWFuLWlwd2F2ZS1uZC0wMA0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQteWFuLWlwd2F2 ZS1uZC0wMA0KQWJzdHJhY3Q6DQogICBGb3IgQy1BQ0MsIHBsYXRvb25pbmcgYW5kIG90aGVyIHR5 cGljYWwgdXNlIGNhc2VzIGluIElUUywgYSBkaXJlY3QgSVANCiAgIGNvbW11bmljYXRpb24gYmV0 d2VlbiBuZWlnaGJvciB2ZWhpY2xlcyBpcyByZXF1aXJlZCB0aGF0IHBvc2VzIHRoZQ0KICAgZm9s bG93aW5nIHR3byBpc3N1ZXM6IDEpIGhvdyB0byBkaXNjb3ZlciB0aGUgbmVpZ2hib3IgdmVoaWNs ZSBhbmQgdGhlDQogICByZXF1aXJlZCBzZXJ2aWNlOyBhbmQgMikgaG93IHRvIGRpc2NvdmVyIHRo ZSBsaW5rLWxheWVyIGFkZHJlc3Mgb2YNCiAgIHRoZSBuZWlnaGJvciB2ZWhpY2xlIGFuZCBzZXJ2 ZXIuICBUaGlzIGRyYWZ0IHByZXNlbnRzIGEgc29sdXRpb24gdG8NCiAgIHRoZXNlIHByb2JsZW1z IGJhc2VkIG9uIEROUy1TRC9tRE5TIFtSRkM2NzYyXVtSRkM2NzYzXS4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQpUaGUgSUVURiBT ZWNyZXRhcmlhdA0K --=====003_Dragon756015151535_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNv bnRlbnQ9Ik1TSFRNTCA4LjAwLjc2MDEuMTc1MTQiPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZv bnQtZmFtaWx5OiDlrovkvZM7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogVmVyZGFu YTsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBA5a6L5L2TOw0KfQ0KQHBhZ2UgU2Vj dGlvbjEge3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBw dCA5MC4wcHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpV U1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20g MGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVw dA0KfQ0KTEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVY VC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1l cyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVY VC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjog MGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAx MC41cHQNCn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJs aW5lDQp9DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElP TjogdW5kZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JB VElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjog cHVycGxlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcg ew0KCUZPTlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiB3aW5k b3d0ZXh0OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1z dHlsZS10eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNl Y3Rpb24xDQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0K CU1BUkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9 DQpPTCB7DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglN QVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4N CjxCT0RZIHN0eWxlPSJNQVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hOyBGT05ULVNJ WkU6IDEwcHQiPjxGT05UIA0KY29sb3I9IzAwMDAwMCBzaXplPTIgZmFjZT1WZXJkYW5hPg0KPERJ Vj48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ1ZlcmRhbmEnLHNhbnMtc2VyaWY7IENPTE9S OiBibGFjazsgRk9OVC1TSVpFOiAxMHB0OyBtc28tYmlkaS1mb250LWZhbWlseTog5a6L5L2TOyBt c28tZm9udC1rZXJuaW5nOiAwcHQiIA0KbGFuZz1FTi1VUz48P3htbDpuYW1lc3BhY2UgcHJlZml4 ID0gbyBucyA9IA0KInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgLz48 bzpwPg0KPERJVj5IaSwmbmJzcDthbGwsPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5XZSZuYnNw O3VwZGF0ZWQmbmJzcDt0aGUmbmJzcDtkcmFmdCZuYnNwO2Fib3V0Jm5ic3A7bmVpZ2hib3ImbmJz cDtkaXNjb3ZlcnkmbmJzcDtiYXNlZCZuYnNwO29uJm5ic3A7RE5TLVNEL21ETlMmbmJzcDthbmQm bmJzcDtwb3N0Jm5ic3A7dGhpcyZuYnNwO3ZlcnNpb24mbmJzcDtpbiZuYnNwO3RoZSZuYnNwO0lQ V0FWRSZuYnNwO1dHLjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+SW4mbmJzcDt0aGlzJm5ic3A7 dmVyc2lvbiwmbmJzcDt3ZSZuYnNwO2Rlc2NyaWJlJm5ic3A7dGhlJm5ic3A7cHJlZml4Jm5ic3A7 bWFuYWdlbWVudCZuYnNwO29mJm5ic3A7bmFtZSZuYnNwO2FuZCZuYnNwO2FkZHJlc3MmbmJzcDtp biZuYnNwO0lUUyZuYnNwO2FuZCZuYnNwO2lsbHVzdHJhdGUmbmJzcDt0aGUmbmJzcDtwcm9jZWR1 cmUmbmJzcDtvZiZuYnNwOzwvRElWPg0KPERJVj5uZWlnaGJvciZuYnNwO25vZGUmbmJzcDthbmQm bmJzcDtzZXJ2aWNlJm5ic3A7ZGlzY292ZXImbmJzcDtiYXNlZCZuYnNwO29uJm5ic3A7RE5TLVNE L21ETlMmbmJzcDt1bmRlciZuYnNwO2RpZmZlcmVudCZuYnNwO3NjZW5hcmlvcy48L0RJVj4NCjxE SVY+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5XZWxjb21lJm5ic3A7YW55Jm5ic3A7 Y29tbWVudHMmbmJzcDthbmQmbmJzcDtpbnRlcmVzdC48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElW PkJSLDwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+Wmhpd2VpJm5ic3A7WWFuPC9ESVY+DQo8RElW PjwvRElWPjwvbzpwPjwvU1BBTj48Rk9OVCBjb2xvcj0jYzBjMGMwIHNpemU9MiANCmZhY2U9VmVy ZGFuYT4yMDE3LTA0LTIxPC9GT05UPjwvRElWPg0KPEhSIGNvbG9yPSNiNWM0ZGYgU0laRT0xPg0K DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz7lj5Hku7bkurrvvJo8L1NU Uk9ORz4gDQppbnRlcm5ldC1kcmFmdHM8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBm YWNlPVZlcmRhbmE+PFNUUk9ORz7lj5HpgIHml7bpl7TvvJo8L1NUUk9ORz4gDQoyMDE3LTA0LTIx Jm5ic3A7MTE6MzU6MTc8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRh bmE+PFNUUk9ORz7mlLbku7bkurrvvJo8L1NUUk9ORz4gWmhpd2VpIFlhbjsgSm9uZy1IeW91ayAN CkxlZTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05H PuaKhOmAge+8mjwvU1RST05HPiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNl PVZlcmRhbmE+PFNUUk9ORz7kuLvpopjvvJo8L1NUUk9ORz4gTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciANCmRyYWZ0LXlhbi1pcHdhdmUtbmQtMDAudHh0PC9GT05UPjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT4NCjxESVY+PC9ESVY+ DQo8RElWPkEmbmJzcDtuZXcmbmJzcDt2ZXJzaW9uJm5ic3A7b2YmbmJzcDtJLUQsJm5ic3A7ZHJh ZnQteWFuLWlwd2F2ZS1uZC0wMC50eHQ8L0RJVj4NCjxESVY+aGFzJm5ic3A7YmVlbiZuYnNwO3N1 Y2Nlc3NmdWxseSZuYnNwO3N1Ym1pdHRlZCZuYnNwO2J5Jm5ic3A7Wmhpd2VpJm5ic3A7WWFuJm5i c3A7YW5kJm5ic3A7cG9zdGVkJm5ic3A7dG8mbmJzcDt0aGU8L0RJVj4NCjxESVY+SUVURiZuYnNw O3JlcG9zaXRvcnkuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5OYW1lOiBkcmFmdC15YW4taXB3 YXZlLW5kPC9ESVY+DQo8RElWPlJldmlzaW9uOiAwMDwvRElWPg0KPERJVj5UaXRsZTogTmVpZ2hi b3ImbmJzcDtkaXNjb3ZlcnkmbmJzcDtpbiZuYnNwO0lUUzwvRElWPg0KPERJVj5Eb2N1bWVudCZu YnNwO2RhdGU6IDIwMTctMDQtMjA8L0RJVj4NCjxESVY+R3JvdXA6IEluZGl2aWR1YWwmbmJzcDtT dWJtaXNzaW9uPC9ESVY+DQo8RElWPlBhZ2VzOiA3PC9ESVY+DQo8RElWPlVSTDombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteWFuLWlwd2F2 ZS1uZC0wMC50eHQ8L0RJVj4NCjxESVY+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXlhbi1pcHdhdmUtbmQvPC9ESVY+DQo8RElWPkh0bWxpemVkOiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2h0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC15YW4taXB3YXZlLW5kLTAwPC9ESVY+DQo8RElWPkh0bWxpemVkOiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQteWFuLWlwd2F2ZS1uZC0wMDwvRElWPg0KPERJVj48L0RJVj4NCjxE SVY+PC9ESVY+DQo8RElWPkFic3RyYWN0OjwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDtG b3ImbmJzcDtDLUFDQywmbmJzcDtwbGF0b29uaW5nJm5ic3A7YW5kJm5ic3A7b3RoZXImbmJzcDt0 eXBpY2FsJm5ic3A7dXNlJm5ic3A7Y2FzZXMmbmJzcDtpbiZuYnNwO0lUUywmbmJzcDthJm5ic3A7 ZGlyZWN0Jm5ic3A7SVA8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Y29tbXVuaWNhdGlv biZuYnNwO2JldHdlZW4mbmJzcDtuZWlnaGJvciZuYnNwO3ZlaGljbGVzJm5ic3A7aXMmbmJzcDty ZXF1aXJlZCZuYnNwO3RoYXQmbmJzcDtwb3NlcyZuYnNwO3RoZTwvRElWPg0KPERJVj4mbmJzcDsm bmJzcDsmbmJzcDtmb2xsb3dpbmcmbmJzcDt0d28mbmJzcDtpc3N1ZXM6Jm5ic3A7MSkmbmJzcDto b3cmbmJzcDt0byZuYnNwO2Rpc2NvdmVyJm5ic3A7dGhlJm5ic3A7bmVpZ2hib3ImbmJzcDt2ZWhp Y2xlJm5ic3A7YW5kJm5ic3A7dGhlPC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwO3JlcXVp cmVkJm5ic3A7c2VydmljZTsmbmJzcDthbmQmbmJzcDsyKSZuYnNwO2hvdyZuYnNwO3RvJm5ic3A7 ZGlzY292ZXImbmJzcDt0aGUmbmJzcDtsaW5rLWxheWVyJm5ic3A7YWRkcmVzcyZuYnNwO29mPC9E SVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwO3RoZSZuYnNwO25laWdoYm9yJm5ic3A7dmVoaWNs ZSZuYnNwO2FuZCZuYnNwO3NlcnZlci4mbmJzcDsmbmJzcDtUaGlzJm5ic3A7ZHJhZnQmbmJzcDtw cmVzZW50cyZuYnNwO2EmbmJzcDtzb2x1dGlvbiZuYnNwO3RvPC9ESVY+DQo8RElWPiZuYnNwOyZu YnNwOyZuYnNwO3RoZXNlJm5ic3A7cHJvYmxlbXMmbmJzcDtiYXNlZCZuYnNwO29uJm5ic3A7RE5T LVNEL21ETlMmbmJzcDtbUkZDNjc2Ml1bUkZDNjc2M10uPC9ESVY+DQo8RElWPjwvRElWPg0KPERJ Vj48L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9ESVY+ DQo8RElWPjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+UGxlYXNlJm5ic3A7bm90ZSZuYnNwO3Ro YXQmbmJzcDtpdCZuYnNwO21heSZuYnNwO3Rha2UmbmJzcDthJm5ic3A7Y291cGxlJm5ic3A7b2Ym bmJzcDttaW51dGVzJm5ic3A7ZnJvbSZuYnNwO3RoZSZuYnNwO3RpbWUmbmJzcDtvZiZuYnNwO3N1 Ym1pc3Npb248L0RJVj4NCjxESVY+dW50aWwmbmJzcDt0aGUmbmJzcDtodG1saXplZCZuYnNwO3Zl cnNpb24mbmJzcDthbmQmbmJzcDtkaWZmJm5ic3A7YXJlJm5ic3A7YXZhaWxhYmxlJm5ic3A7YXQm bmJzcDt0b29scy5pZXRmLm9yZy48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPlRoZSZuYnNwO0lF VEYmbmJzcDtTZWNyZXRhcmlhdDwvRElWPg0KPERJVj48L0RJVj48L0ZPTlQ+PC9ESVY+PC9GT05U PjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon756015151535_=====-- From nobody Fri Apr 21 06:45:33 2017 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 A5F331205F1; Fri, 21 Apr 2017 06:45:31 -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: suresh.krishnan@gmail.com, housley@vigilsec.com, its@ietf.org, ipwave-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149278233158.22315.8633495889226176529.idtracker@ietfa.amsl.com> Date: Fri, 21 Apr 2017 06:45:31 -0700 Archived-At: Subject: [ipwave] ipwave - New Meeting Session Request for IETF 99 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: Fri, 21 Apr 2017 13:45:32 -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: l2sm saag rtgarea manet 6man 6lo intarea stir lamps nfvrg detnet Second Priority: lime isis i2nsf ospf roll dhc cfrg sfc People who must be present: Russ Housley Suresh Krishnan Carlos J. Bernardos Resources Requested: Special Requests: ---------------------------------------------------------