From nobody Thu Mar 3 06:50:32 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D101AD0A9 for ; Thu, 3 Mar 2016 06:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 f-HzVvykJ1-n for ; Thu, 3 Mar 2016 06:50:29 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343DD1AD06A for ; Thu, 3 Mar 2016 06:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6320; q=dns/txt; s=iport; t=1457016629; x=1458226229; h=from:to:subject:date:message-id:mime-version; bh=JxaXWQVHkP6zKilaMG0C+U55aK3UJibTd2+NgWxDmuQ=; b=H8BPouCXjBpIIZAjxV9R480lHbo81TvJblX93VO82MMl3euo/S18sdU1 CLssTgTCqjl7/OggtSvU3O4ziNra/bjoYs8ANrAwh5/40MFTjnzi0FZEG 2XqkDz76sVw1ghsrW0Yy7BabSsUX/7TWSWWFJdXo08BAeK2QChx6cNM49 M=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCBQDkTthW/4gNJK1dgzpSbQa8GyGFb?= =?us-ascii?q?oEtOxEBAQEBAQEBZBwLhEMEASNbDQEGRAI0JwQhDYd+CA4DkSGNOo9djzEBAQE?= =?us-ascii?q?BAQEEAQEBAQEBAREEBIYYgW4IhzCCTiuBDwWHWYVUiW8BgwiBZWyICYFghESIU?= =?us-ascii?q?45MATYsg2RqAYdmJBl+AQEB?= X-IronPort-AV: E=Sophos;i="5.22,532,1449532800"; d="asc'?scan'208";a="245149708" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Mar 2016 14:50:19 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u23EoJoB025552 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 3 Mar 2016 14:50:19 GMT Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 3 Mar 2016 08:50:18 -0600 Received: from xch-aln-020.cisco.com ([173.36.7.30]) by XCH-ALN-020.cisco.com ([173.36.7.30]) with mapi id 15.00.1104.009; Thu, 3 Mar 2016 08:50:18 -0600 From: "Carlos Pignataro (cpignata)" To: "its@ietf.org" Thread-Topic: ITS Charter Thread-Index: AQHRdVwAk2Neqerk2kafhKCC4y9n5g== Date: Thu, 3 Mar 2016 14:50:18 +0000 Message-ID: <113DBE6A-A3DF-4149-8B75-139A2E3780B7@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.238.65] Content-Type: multipart/signed; boundary="Apple-Mail=_185815DA-EF1E-439E-9CC9-04079599BBF4"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: [its] ITS Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 14:50:31 -0000 --Apple-Mail=_185815DA-EF1E-439E-9CC9-04079599BBF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, ITS, It seems this is the most recent message regarding the draft charter: https://mailarchive.ietf.org/arch/msg/its/RJIvo8LQEZXSpbaQ5gDq1WqKcBM Please find below a couple of additional comments for your = consideration, prefixed with =E2=80=9CCMP=E2=80=9D =E2=80=94 these also = include some nits and questions. I would encourage thorough review and list discussion of this charter = text. > ITS (name to change) > Charter CMP: ITS does not seem to expand to =E2=80=9Cname to change=E2=80=9D :-) > Goal > ---- > The goal of this group is to standardize IP protocols for establishing > direct and secure connectivity between moving networks. CMP: My initial reaction was that perhaps this was a bit too broad =E2=80=94= but frankly I think short-and-sweet is good. CMP: Are these =E2=80=9CIP protocols=E2=80=9D or =E2=80=9CIP-based = protocols=E2=80=9D? CMP: Is this between moving networks only, or can one be fixed = (permanently or temporarily)? > Moving Network to Nearby Moving Network Communications > ------------------------------------------------------ > The group is concerned with all situations involving moving network to > nearby moving network communications. For example: vehicle-to-vehicle > communications, nomadic user wearing a PAN and communicating to a > homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a > train, or train-to-intersection signalling. CMP: Again, a small (hopefully non-pedantic) point =E2=80=94 that a home = net or the infrastructure are not moving, likely (reference to the = ground :-). CMP: What is =E2=80=9Cnearby" moving? Might not hurt do scope/define it. > Example from the automobile communications space > ------------------------------------------------ > Automobiles and vehicles of all types are increasingly connected to > the Internet. CMP: Same distinction =E2=80=94 vehicle-to-vehicle, or = vehicle-to-Internet, or vehicle-to-infra? > in automobiles to hit the roads from now to year 2020. Highlighting > increased safety as an immediate result of hyper-connectivity applied > to vehicles, public authorities worldwide are increasingly mandating > communication technology requirements in vehicles. CMP: I=E2=80=99d add =E2=80=9Cmandating *secure* communication = technology requirements=E2=80=9D. > IP communication between vehicles (V2V), and between vehicles and the > immediate infrastructure (V2I), will provide (0) ability to reach the > rest of the world on the Inerenet (1) short and deterministic delays, > (2) fast forwarding through scalable paths of routers, (3) ease of > reuse of existing Internet applications in a vehicular environment. CMP: Typo, s/Inerenet/Internet/. CMP: Now, Isn=E2=80=99t (0) already provided (a few paragraphs above) = with vehicle-to-Internet? CMP: A meta-comment, I am surprised that requirements of =E2=80=9Cdiscover= y=E2=80=9D and =E2=80=9Cnaming=E2=80=9D are not called out. > What kind of solutions? > ----------------------- > The current technical solutions considered to achieve moving network > to nearby moving network communications are of two kinds: IP routing > protocols for n-hop path management and 1-hop link-scoped IP protocol > enhancements. CMP: It would be useful to also here specify scope of solutions in terms = of number of hops =E2=80=94 I thought this was 1-hop. CMP: Also, the Goal above is about =E2=80=9Cconnectivity=E2=80=9D. > In this proposed Working Group the focus is on 1-hop protocols, and > leverage from other Working Groups for the n-hop situations. CMP: Sorry, what follows is this paragraph, forget my previous comment = :-) > Work Items > ---------- > - use-cases for moving network to nearby moving network communications > - Problem Statement for moving network to nearby moving network > communications CMP: Are you thinking of use-cases and problem statements as individual = work items (drafts)? Are these one? And in fact one for V2V and V2I? > - Security and Privacy Requirements for moving network to > nearby moving network communications > - Problem Statement for moving network to infrastructure network > communications, including DNS > - Potentially new protocol, or protocol extensions for establishing IP > paths for 1-hop moving network to nearby moving network = communications. > With MIB and security. CMP: I=E2=80=99d say =E2=80=98Solutions, which might include new = protocols or extensions to existing protocols=E2=80=9D CMP: What is a path in =E2=80=9C1-hop=E2=80=9D? Do you mean = =E2=80=9Cconnectivity=E2=80=9D? CMP: MIBs? https://www.ietf.org/iesg/statement/writable-mib-module.html > - IPv6-over foo, where foo is pertinent for moving network to nearby > moving network communications (e.g. 802.11 OCB, VLC, LTE-D, = 802.11ad) Thanks! I hope these are useful =E2=80=94 Carlos. --Apple-Mail=_185815DA-EF1E-439E-9CC9-04079599BBF4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJW2E8pAAoJEIXgpQGOZny9JL0QAIw5ZI336v51micictWvIkY+ Goe+D+l3mFgHRMmRRcMTogoDIWWQI3aZJ8nhhzY1j7hHEPXfVRmqAru5Sjct3Jbu YSSOn8bpZjjL9gt4Pki5tvpApEdDpOpM9vNZLW+/20IeMWpCbZ7grBNs6FyPvOKU 04JHE0bwQWXNVRS5R3dcKg8p0yWq+Q+OF6Wd4TPfLj7YKfJOa0KAhJAizsjf8MHW sl04pjGJdGqyowVs7Iv2GxfObaamsFMKk1Z9vxr2bgodp4xwujHNL1aDVHKnHjiO FHa2aYUarjJfepQJ94nxW5XMuoyTwyxhTCah0I5Ni1dmq6Vm+aPZ+HbFoaUMVsSh hn0+dwWakbxtLOTKLVelKv1DRF06YYh7ejQyEajfvxxxJW0Q0YBrxyDpaawhutwh Eb6L0YXD/PBHenAK8mMBs32g2icUkUmnzux4wcaRA6eBxF3ncYj4V7BCOzIVydQK xzbb/sgZCXwnVSugQBkXVLQh8DnTFaIOBEXrfqPCQYwac4GV/r0+shCi7MscpONV 04Y92nRCtEYBAiwiHSzOnQQcm95GRqZ/g/FlgQR3GISV8b7f0wPiUHTu3qx0hWK2 nW9elCqdPbtlRUYVuSgBJVm61Vq6xaORUxK/+YSI9URV5VTxrP/oZdgSsYVHoz4L csHJ525xfFAKJmVh4KJP =nDw7 -----END PGP SIGNATURE----- --Apple-Mail=_185815DA-EF1E-439E-9CC9-04079599BBF4-- From nobody Fri Mar 4 02:11:42 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728E01A871E for ; Fri, 4 Mar 2016 02:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 XlkD679XJT25 for ; Fri, 4 Mar 2016 02:11:38 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD5C1A86FC for ; Fri, 4 Mar 2016 02:11:37 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u24ABZoC018328 for ; Fri, 4 Mar 2016 11:11:35 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A7CF2203FD5 for ; Fri, 4 Mar 2016 11:11:56 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9E419203EFA for ; Fri, 4 Mar 2016 11:11:56 +0100 (CET) Received: from [132.166.84.128] ([132.166.84.128]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u24ABYuv008295 for ; Fri, 4 Mar 2016 11:11:35 +0100 To: its@ietf.org References: <113DBE6A-A3DF-4149-8B75-139A2E3780B7@cisco.com> From: Alexandre Petrescu Message-ID: <56D95F56.2050104@gmail.com> Date: Fri, 4 Mar 2016 11:11:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <113DBE6A-A3DF-4149-8B75-139A2E3780B7@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] ITS Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 10:11:40 -0000 Hello Carlos, ITSers, I am travelling right now, sorry. What do the others think about the comments on the Charter? Agreeing on a Charter is highly important. Now that the BoF has been approved (thanks all efforts!) let's continue building our work proposal. Soon, Alex Le 03/03/2016 15:50, Carlos Pignataro (cpignata) a écrit : > Hi, ITS, > > It seems this is the most recent message regarding the draft charter: > > https://mailarchive.ietf.org/arch/msg/its/RJIvo8LQEZXSpbaQ5gDq1WqKcBM > > Please find below a couple of additional comments for your consideration, prefixed with “CMP” — these also include some nits and questions. > > I would encourage thorough review and list discussion of this charter text. > >> ITS (name to change) >> Charter > > CMP: ITS does not seem to expand to “name to change” :-) > >> Goal >> ---- >> The goal of this group is to standardize IP protocols for establishing >> direct and secure connectivity between moving networks. > > CMP: My initial reaction was that perhaps this was a bit too broad — but frankly I think short-and-sweet is good. > > CMP: Are these “IP protocols” or “IP-based protocols”? > > CMP: Is this between moving networks only, or can one be fixed (permanently or temporarily)? > >> Moving Network to Nearby Moving Network Communications >> ------------------------------------------------------ >> The group is concerned with all situations involving moving network to >> nearby moving network communications. For example: vehicle-to-vehicle >> communications, nomadic user wearing a PAN and communicating to a >> homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a >> train, or train-to-intersection signalling. > > CMP: Again, a small (hopefully non-pedantic) point — that a home net or the infrastructure are not moving, likely (reference to the ground :-). > > CMP: What is “nearby" moving? Might not hurt do scope/define it. > >> Example from the automobile communications space >> ------------------------------------------------ >> Automobiles and vehicles of all types are increasingly connected to >> the Internet. > > CMP: Same distinction — vehicle-to-vehicle, or vehicle-to-Internet, or vehicle-to-infra? > >> in automobiles to hit the roads from now to year 2020. Highlighting >> increased safety as an immediate result of hyper-connectivity applied >> to vehicles, public authorities worldwide are increasingly mandating >> communication technology requirements in vehicles. > > CMP: I’d add “mandating *secure* communication technology requirements”. > > >> IP communication between vehicles (V2V), and between vehicles and the >> immediate infrastructure (V2I), will provide (0) ability to reach the >> rest of the world on the Inerenet (1) short and deterministic delays, >> (2) fast forwarding through scalable paths of routers, (3) ease of >> reuse of existing Internet applications in a vehicular environment. > > CMP: Typo, s/Inerenet/Internet/. > > CMP: Now, Isn’t (0) already provided (a few paragraphs above) with vehicle-to-Internet? > > CMP: A meta-comment, I am surprised that requirements of “discovery” and “naming” are not called out. > >> What kind of solutions? >> ----------------------- >> The current technical solutions considered to achieve moving network >> to nearby moving network communications are of two kinds: IP routing >> protocols for n-hop path management and 1-hop link-scoped IP protocol >> enhancements. > > CMP: It would be useful to also here specify scope of solutions in terms of number of hops — I thought this was 1-hop. > > CMP: Also, the Goal above is about “connectivity”. > >> In this proposed Working Group the focus is on 1-hop protocols, and >> leverage from other Working Groups for the n-hop situations. > > CMP: Sorry, what follows is this paragraph, forget my previous comment :-) > >> Work Items >> ---------- >> - use-cases for moving network to nearby moving network communications >> - Problem Statement for moving network to nearby moving network >> communications > > CMP: Are you thinking of use-cases and problem statements as individual work items (drafts)? Are these one? And in fact one for V2V and V2I? >> - Security and Privacy Requirements for moving network to >> nearby moving network communications >> - Problem Statement for moving network to infrastructure network >> communications, including DNS >> - Potentially new protocol, or protocol extensions for establishing IP >> paths for 1-hop moving network to nearby moving network communications. >> With MIB and security. > > CMP: I’d say ‘Solutions, which might include new protocols or extensions to existing protocols” > > CMP: What is a path in “1-hop”? Do you mean “connectivity”? > > CMP: MIBs? https://www.ietf.org/iesg/statement/writable-mib-module.html >> - IPv6-over foo, where foo is pertinent for moving network to nearby >> moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) > > Thanks! I hope these are useful > > — Carlos. > > > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Fri Mar 4 08:33:16 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E621A00FE for ; Fri, 4 Mar 2016 08:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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, SPF_PASS=-0.001] autolearn=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 DdIB0RONu0dS for ; Fri, 4 Mar 2016 08:33:10 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 1F9561A00E7 for ; Fri, 4 Mar 2016 08:33:10 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id p65so35811027wmp.0 for ; Fri, 04 Mar 2016 08:33:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=tkUs/tWYZqeKhxL9o0gYVHMwbgci5BKEetbhKsqEe7c=; b=krER4hFWl4l1ITjt26n9FHN8z9JMdV/UJZv45kj2sym4YvMTd2Ktn0UpAGUHxSriJ7 jmKKwMSAcl6gZyKJrLciXazzzbBAh7wc87WS3yStVpmBLjHwvcEiwj7WZeV/0qJhVA0+ 8z+KXcuD8y9m/F9Z4Y8+KGYUq10FeGvF3WLnUEHxkJDR7pe6u0WzR1lHr0OkMdhgUWG8 qJjTT9pDv6gg66kwVm2rL8tqO65qhPC7mSmEhJnmbDARXLOtoWJMqWZtpmiJ6Lfo4aUt ZUnM9P673pcdW7yzZowCQw3YfzKcwggKkcCIK4u2FHR+mjYwbzrwkARKDf9T4zeJNXS4 3/6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=tkUs/tWYZqeKhxL9o0gYVHMwbgci5BKEetbhKsqEe7c=; b=BGBuYzPPGJsGcR/ig+dIKVn044Baugt+480IMChQV3BqSUzMtF1O0sSswqsVE31h3D +2ppCzmJ4NGumeJTQyNaB3hU3BwyRTnWpQFlXtciuFyZR0EzJFDM4SxIcS0c56f/QY08 a1MgpuOunQAF2z3yDYpgCe1d4o5ewTQAVKzJwc1e3vDyX13L8SZxiq6HSic/ZPl6Tmu9 Dqyzkbh/qF34UI2xmAK64WFBGAA/4LfivKuEZEGFWm9cu8yp+u4rS7d6r7KIkZjL5yA3 8MAm+zf/dbT5yZ6W16YVasY8PprBU6/G4Ur/800tCb9zyujItFgrEPAiGqCOKwYg/fuv afaQ== X-Gm-Message-State: AD7BkJLBZSScDH/+1vJtmYSdvENKU2YT1Z9mXTzuO0BwtgLvzfj6sm++8+XasY7by46JLHF5g2Uh8JU6kn7kvw== MIME-Version: 1.0 X-Received: by 10.28.145.9 with SMTP id t9mr6374898wmd.54.1457109188527; Fri, 04 Mar 2016 08:33:08 -0800 (PST) Received: by 10.28.32.11 with HTTP; Fri, 4 Mar 2016 08:33:08 -0800 (PST) In-Reply-To: <8B07B35E-3FE8-4B1E-9017-7A2E34B320F3@vigilsec.com> References: <56C1D0AB.3020006@gmail.com> <8B07B35E-3FE8-4B1E-9017-7A2E34B320F3@vigilsec.com> Date: Fri, 4 Mar 2016 16:33:08 +0000 Message-ID: From: Nabil Benamar To: Russ Housley Content-Type: multipart/alternative; boundary=001a1146a91e94d27e052d3bab02 Archived-At: Cc: Alexandre Petrescu , "its@ietf.org" Subject: Re: [its] Updated charter - please comment X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 16:33:14 -0000 --001a1146a91e94d27e052d3bab02 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alex, Russ and itsers, The charter looks good for me and it should be noted that a great amount of research papers are focusing on the benefits of car to car communication to solve some relevant issues. Many strategies are proposed to proactively compute re-routing guidance to be pushed to vehicles when signs of congestion are observed on their route. This is beyond the safety issue as stated in the draft charter but it concerns a better driving experience ! Other car manufacturers could be interested by the outcomes of this wg, especially when we think about Autonomous driving. Indeed, one of the main challenges of autonomous driving in urban areas is transition through cross-roads and intersections. In addition to safety concerns, current intersection management technologies such as stop signs and trafic lights can introduce significant trafic delays even under light trafic conditions. V2V and V2I can help avoiding deadlock situations and eventual collisions as well ! Moreover, considering the importance of IPv6 deployment nowadays and all the possibilities and new technologies rising from it, our previous draft can be a good starting point and a work item for the WG: https://datatracker.ietf.org/doc/draft-petrescu-ipv6-over-80211p/ Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 http://nabilbenamar.ipv6-lab.net/ On Wed, Feb 17, 2016 at 6:36 PM, Russ Housley wrote: > Alex: > > Below are my comments on the proposed charter text. > > Russ > > > > ----------------------------------------------------------------------- > > ITS (name to change) > Charter > February 15th, 2016 > http://ietf.org/mailman/listinfo/its > > > Intelligent Transportation Systems (its) > ---------------------------------------- > Current Status: WG forming > > Chairs: > TBD > > Assigned Area Director: > TBD > > Mailing list > Address: its@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/its > Archive: > http://www.ietf.org/mail-archive/web/its/current/maillist.html > > Additional web page > TBD > > Charter: > > Goal > ---- > The goal of this group is to standardize IP protocols for establishing > direct and secure connectivity between moving networks. > > Moving Network to Moving Network Communications > ----------------------------------------------- > The group is concerned with all situations involving moving network to > moving network communications. For example: vehicle-to-vehicle > communications, nomadic user wearing a PAN and communicating to a > homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a > train, or train-to-intersection signalling. > > Example from the automobile communications space > ------------------------------------------------ > Automobiles and vehicles of all types are increasingly connected to > the Internet. Entertainment apps enhancing comfort, reliable data > exchanges for road safety, and automated driving, are commonly seen as > > > Editorial: s/automated driving, are/automated driving are/ > > winning sale arguments for automobiles to hit the roads from now to > year 2020. Emergency apps for new instrumented ambulances carry many > benefits both to the users and to society in general. > > > I think that the "winning sales arguments" is not needed here. Instead, = I > think it > would be valuable to say that these features are coming, and that the > safety > features are expected to become required. > > > Why IP? > ------- > Whereas the Vehicle-to-Internet technologies are considered completed > and deployed in automobiles currently on the roads (e.g. car tethering > through driver's cellular smartphone, live traffic data displayed on > the dashboard, - use of NAT/DHCP and potentially Mobile IP), the > Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are > still in an infancy stage: primitive link-specific data exchanges are > limited to a non-harmonized set of applications, such as ETSI's > CAM/DENM presence signalling; worse, some link-specific messages > exhibit behaviour assimilated to IP behaviour but the systems are > incompatible with the Internet without involving specific gatewaying. > The industry needs to employ IP data exchanges between vehicles, and > between vehicles and the immediate infrastructure, rather than > link-specific exchanges, in order to benefit from advantages such as > (1) short delays, (2) fast forwarding through short paths of dumb > routers (2) ease of reusing of a huge number of a desktop Internet > applications in a vehicular environment (extend the Internet to mobile > platforms). > > > I think this paragraph take too long to get to the main point, which is > why IP is a goog thing in this environment. I suggest: > > Today, there are several deployed Vehicle-to-Internet technologies, > including car tethering through driver's cellular smartphone. However, > Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are still > being developed. To avoid link-specific data exchanges, and enable > independent application sets to share the same links, IP data exchanges > are needed. Enabling IP communication between vehicles (V2V), and > between vehicles and the immediate infrastructure (V2I), will provide > (1) short delays, (2) fast forwarding through short paths of routers, > (3) ease of reuse of existing Internet applications in a vehicular > environment. > > > Moving network to moving network communications involve link layers > > > Add "nearby" here. I think it is important to the scope. > > such as: 802.11 OCB, 802.15.4 with 6lowpan, 802.11ac, VLC (Visible > Light Communications), IrDA, LTE-D. Only the IP protocols are capable > > > s/802.11 OCB/802.11p OCB (Outside the Context of a BSS)/ > > of running on each of these links and establish IP paths across them > in an interoperable manner. > > Scenarios? > ---------- > There are a few scenarios exhibiting the need to communicate from one > moving network to another nearby moving network. > > In the automobile space, the Cooperative Adaptive Cruise Control and > Platooning features consider that vehicles close to each other > exchange data describing their kinematic status. At the cross-roads, > the moving network inside a vehicle exchanges data with the moving > network in the red-light pole. > > Several public safety scenarios involve moving networks. Distinct > organizations deploy different moving networks (in-vehicle, on-person) > at an incident scene. These networks need to interoperate in order to > more effectively understand and deal with the incident scene. > > In connected rail scenarios the moving network deployed in trains > communicate with other moving networks at the cross-points. > > What kind of solutions? > ----------------------- > The current technical solutions considered to achieve moving network > to moving network communications are of two kinds: IP routing > > > Add "nearby" here. I think it is important to the scope. > > protocols for n-hop path management and 1-hop link-scoped IP protocol > enhancements. The 1-hop link-scoped protocols include the protocols > for route establishment involving ICMP Router Advertisements. The > n-hop path management protocols include n-hop path establishment > protocols (e.g. Babel, OSPF) and n-hop path search protocols (most > notably AODV and derivates). > > > My understanding from the phone call was that we were going to focus on > the 1-hop > protocols in this proposed working group, but leverage work from other > groups for the > n-hop situation. > > I think we need to say something here about the duration of some of the > communications. > a vehicle traveling at 80 Km/h is not going to have communications with a > roadside > device for very long. > > > What kind of requirements? > -------------------------- > The requirements for mechanisms for moving network to moving network > > > Add "nearby" here. I think it is important to the scope. > > communications are focusing on low delays of the data paths, reduced > number of messages for path establishment, application friendly, > resilience to attacks, compatibility with DHCP and Mobile IP. > > In addition, some moving network to moving network applications > > > Add "nearby" here. I think it is important to the scope. > > involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the > 1-hop IP moving network to moving netowrk mechanisms will need to > gracefully support IP multicast. > > Due to the inherent characteristics of safety-related communications, > all new moving network to moving network mechanisms must afford > authenticity and confidentiality where necessary. Dynamically > establishing ephemeral communication paths between automobiles in > public areas must offer privacy safeguards for the end users > (passengers). > > Establishing 1-hop IP V2V paths must not break the existing on-board > protocols and applications which communicate with the Internet, > possibly via multiple radios. > > In a moving network deployed in an automobile, typically one exit > point connects the moving network to other moving networks. However, > in a more general manner (and to support reliability) any new > mechanism of moving network to moving network communications should > support multi-homing: one router to use multiple interfaces towards > outside the moving network, or multiple routers. > > Current version of Internet protocols > ------------------------------------- > The version of the IP protocol is IPv6 (witness 10% IPv6 penetration > as of early 2016, mobile operators evolving to IPv6-only, government > IPv6 push, IPv4 exhaust at RIRs); this acommodates the current > generation of Internet protocols. For backwards compatibility, IPv4 > may be considered as well, but not exclusively. Link-local IPv6 > addresses will be used. > > > This it too long. Just say that the groups will only work on IPv6 > solutions. > > > What SDOs may need this work? > ----------------------------- > The requirements and standards for moving network to moving network > communications, often involving IPv6, and novel V2V and V2Infra > concepts, are developed mainly at ISO TC204 "Intelligent Transport > Systems", 3GPP, ETSI, NHTSA and IEEE. For Vehicle-to-Internet > communications, 3GPP LTE and other cellular technologies represent the > long-range connectivity method; for Vehicle-to-Vehicle communications, > LTE Direct is currently specified, as well as OCB mode of IEEE 802.11. > Several use-cases exhibit a need for IPv6 data exchanges between > vehicles: ETSI's Cooperative Adaptive Cruise Control and Platooning. > The IEEE developed a popular link for short-range communications - > IEEE 802.11p "WAVE". The NHTSA wrote a set of requirements for V2V > communications. > > Work Items > ---------- > - use-cases for moving network to moving network communications > - Problem Statement for moving network to moving network communications > - Security and Privacy Requirements for moving network to > moving network communications > - Problem Statement for moving network to infrastructure network > communications, including DNS > - Potentially new protocol, or protocol extensions for establishing IP > paths for 1-hop moving network to moving network communications. > With MIB and security. > - IPv6-over foo, where foo is pertinent for moving network to moving > network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) > > Timeline > -------- > - > > _______________________________________________ > 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 > > --001a1146a91e94d27e052d3bab02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alex, Russ and itsers,
<= div class=3D"gmail_default" style=3D"font-family:verdana,sans-serif">
The charter looks goo= d for me and it should be noted that a great amount of research papers are = focusing on the benefits of car to car communication to solve some relevant= issues. Many=C2=A0strategies = are proposed to proactively compute=C2=A0re-routing guidance to be pushed to vehicles when signs= =C2=A0of congestion are= observed on their route. This is beyond the safety issue as stated in the = draft charter but it concerns a better driving experience !
<= font color=3D"#0b5394">
Other= car manufacturers could be interested by the outcomes of this wg,=C2=A0esp= ecially=C2=A0when we think about=C2=A0Autonomous driving. Indeed, one of the main=C2=A0challenges of autonomous driving in urban areas is transi= tion through cross-roads and i= ntersections. In addition to=C2=A0safety concerns, current intersection management technolo= gies such as stop signs and tr= afic lights can introduce significant trafic delays even under light trafic conditions.

V2V and V2I can help avoiding deadlock = situations and=C2=A0eventual=C2=A0collisions as well !

Moreover, consi= dering the importance of IPv6 deployment=C2=A0nowadays=C2=A0and all the pos= sibilities and new technologies rising from it, our previous draft can be a= good starting point and a work item for the WG:=C2=A0https://datatracke= r.ietf.org/doc/draft-petrescu-ipv6-over-80211p/




<= /font>

Best= regards
Nabil Benamar=
-------------------
=D9=86=D8=A8=D9=8A=D9=84 =D8= =A8=D9=86=D8=B9=D9=85=D8=B1=D9=88
=

On Wed, Feb 17, 2016 at 6:36 PM, Russ Housley <housley@vig= ilsec.com> wrote:
Alex:

Bel= ow are my comments on the proposed charter text.

Russ



=20 =20 =20
-----------------------------------------------------------------------

=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 ITS (name to change)
=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 Charter
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0Februa= ry 15th, 2016
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0http://ietf.org/mailman/listinfo/= its


Intelligent Transportation Systems (its)
----------------------------------------
Current Status: WG forming

Chairs:
=C2=A0=C2=A0 TBD

Assigned Area Director:
=C2=A0=C2=A0 TBD

Mailing list
=C2=A0=C2=A0 Address: its@ietf.org
=C2=A0=C2=A0 To Subscribe: https://www.ietf.org/mailman/listinfo/its=
=C2=A0=C2=A0 Archive:
=C2=A0=C2=A0 http://www.ietf.org/mail-archive/web/i= ts/current/maillist.html

Additional web page
=C2=A0=C2=A0 TBD

Charter:

Goal
----
The goal of this group is to standardize IP protocols for establishing
direct and secure connectivity between moving networks.

Moving Network to Moving Network Communications
-----------------------------------------------
The group is concerned with all situations involving moving network to
moving network communications.=C2=A0 For example: vehicle-to-vehicle<= br> communications, nomadic user wearing a PAN and communicating to a
homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a
train, or train-to-intersection signalling.

Example from the automobile communications space
------------------------------------------------
Automobiles and vehicles of all types are increasingly connected to
the Internet.=C2=A0 Entertainment apps enhancing comfort, reliable da= ta
exchanges for road safety, and automated driving, are commonly seen as
Editorial: =C2=A0s/automa= ted driving, are/automated driving are/

winning sale arguments for automobiles to hit the roads from now to
year 2020.=C2=A0 Emergency apps for new instrumented ambulances carry many
benefits both to the users and to society in general.

I think that the "winning sales ar= guments" is not needed here.=C2=A0 Instead, I think it
would be valuable to say that these features are = coming, and that the safety
featur= es are expected to become required.


Why IP?
-------
Whereas the Vehicle-to-Internet technologies are considered completed
and deployed in automobiles currently on the roads (e.g. car tethering
through driver's cellular smartphone, live traffic data displayed on
the dashboard, - use of NAT/DHCP and potentially Mobile IP), the
Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are
still in an infancy stage: primitive link-specific data exchanges are
limited to a non-harmonized set of applications, such as ETSI's CAM/DENM presence signalling; worse, some link-specific messages
exhibit behaviour assimilated to IP behaviour but the systems are
incompatible with the Internet without involving specific gatewaying.
The industry needs to employ IP data exchanges between vehicles, and
between vehicles and the immediate infrastructure, rather than
link-specific exchanges, in order to benefit from advantages such as
(1) short delays, (2) fast forwarding through short paths of dumb
routers (2) ease of reusing of a huge number of a desktop Internet applications in a vehicular environment (extend the Internet to mobile
platforms).

I think this paragraph take too long to get t= o the main point, which is
why IP = is a goog thing in this environment.=C2=A0 I suggest:

Today, there are several deployed Vehicle-to-Internet technologies,=
including car tethering through driver&#= 39;s cellular smartphone.=C2=A0 However,
= Vehicle-to-Vehicle and Vehicle-to-Infrastructure co= mmunications are still
bein= g developed.=C2=A0 To avoid link-specific data exchanges, and enable=
independent application sets to share th= e same links, IP data exchanges
ar= e needed.=C2=A0 Enabling IP communication between vehicles (V2V), and
between vehicles and the immediate infr= astructure (V2I), will provide
(1)= =C2=A0short delays, (2) fast forwarding through short paths of routers,
(3)=C2=A0ease of reuse of existing In= ternet applications in a vehicular
environment.


Moving network to moving network communications involve link layers

Add "nearby" here.=C2=A0 I think it is i= mportant to the scope.

such as: 802.11 OCB, 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light Communications), IrDA, LTE-D.=C2=A0 Only the IP protocols are capable

s/802.11 O= CB/802.11p OCB=C2=A0(Outside the=C2=A0Context of a BSS)/
<= font color=3D"#0b5394">
of running on each of these links and establish IP paths across them
in an interoperable manner.

Scenarios?
----------
There are a few scenarios exhibiting the need to communicate from one
moving network to another nearby moving network.

In the automobile space, the Cooperative Adaptive Cruise Control and
Platooning features consider that vehicles close to each other
exchange data describing their kinematic status.=C2=A0 At the cross-roads,
the moving network inside a vehicle exchanges data with the moving network in the red-light pole.

Several public safety scenarios involve moving networks.=C2=A0 Distin= ct
organizations deploy different moving networks (in-vehicle, on-person)
at an incident scene.=C2=A0 These networks need to interoperate in order to
more effectively understand and deal with the incident scene.

In connected rail scenarios the moving network deployed in trains
communicate with other moving networks at the cross-points.

What kind of solutions?
-----------------------
The current technical solutions considered to achieve moving network
to moving network communications are of two kinds: IP routing

Add "nearby" here.=C2= =A0 I think it is important to the scope.

protocols for n-hop path m= anagement and 1-hop link-scoped IP protocol
enhancements.=C2=A0 The 1-hop link-scoped protocols include the protocols
for route establishment involving ICMP Router Advertisements.=C2=A0 T= he
n-hop path management protocols include n-hop path establishment
protocols (e.g. Babel, OSPF) and n-hop path search protocols (most notably AODV and derivates).

My understanding from the phone call was that we were going to f= ocus on the 1-hop
protocols in thi= s proposed working group, but leverage work from other groups for the
n-hop situation.

I think we= need to say something here about the duration of some of the communication= s.
a vehicle traveling at 80 Km/h = is not going to have communications with a roadside
device for very long.


What kind of requirements?
--------------------------
The requirements for mechanisms for moving network to moving network

Add "= nearby" here.=C2=A0 I think it is important to the scope.
=

commu= nications are focusing on low delays of the data paths, reduced
number of messages for path establishment, application friendly,
resilience to attacks, compatibility with DHCP and Mobile IP.

In addition, some moving network to moving network applications

Add "nearby" here.= =C2=A0 I think it is important to the scope.

involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the
1-hop IP moving network to moving netowrk mechanisms will need to
gracefully support IP multicast.

Due to the inherent characteristics of safety-related communications,
all new moving network to moving network mechanisms must afford
authenticity and confidentiality where necessary.=C2=A0 Dynamically establishing ephemeral communication paths between automobiles in
public areas must offer privacy safeguards for the end users
(passengers).

Establishing 1-hop IP V2V paths must not break the existing on-board
protocols and applications which communicate with the Internet,
possibly via multiple radios.

In a moving network deployed in an automobile, typically one exit
point connects the moving network to other moving networks.=C2=A0 However,
in a more general manner (and to support reliability) any new
mechanism of moving network to moving network communications should
support multi-homing: one router to use multiple interfaces towards
outside the moving network, or multiple routers.

Current version of Internet protocols
-------------------------------------
The version of the IP protocol is IPv6 (witness 10% IPv6 penetration
as of early 2016, mobile operators evolving to IPv6-only, government
IPv6 push, IPv4 exhaust at RIRs); this acommodates the current
generation of Internet protocols.=C2=A0 For backwards compatibility, IPv4
may be considered as well, but not exclusively.=C2=A0 Link-local IPv6=
addresses will be used.

This it t= oo long.=C2=A0 Just say that the groups will only work on IPv6 solutions.


What SDOs may need this work?
-----------------------------
The requirements and standards for moving network to moving network
communications, often involving IPv6, and novel V2V and V2Infra
concepts, are developed mainly at ISO TC204 "Intelligent Transpo= rt
Systems", 3GPP, ETSI, NHTSA and IEEE.=C2=A0 For Vehicle-to-Inter= net
communications, 3GPP LTE and other cellular technologies represent the
long-range connectivity method; for Vehicle-to-Vehicle communications,
LTE Direct is currently specified, as well as OCB mode of IEEE 802.11.
Several use-cases exhibit a need for IPv6 data exchanges between
vehicles: ETSI's Cooperative Adaptive Cruise Control and Platooning.
The IEEE developed a popular link for short-range communications - IEEE 802.11p "WAVE".=C2=A0 The NHTSA wrote a set of require= ments for V2V
communications.

Work Items
----------
- use-cases for moving network to moving network communications
- Problem Statement for moving network to moving network communications
- Security and Privacy Requirements for moving network to
=C2=A0 moving network communications
- Problem Statement for moving network to infrastructure network
=C2=A0 communications, including DNS
- Potentially new protocol, or protocol extensions for establishing IP
=C2=A0 paths for 1-hop moving network to moving network communication= s.
=C2=A0 With MIB and security.
- IPv6-over foo, where foo is pertinent for moving network to moving
=C2=A0 network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad)=

Timeline
--------
-
_______________________________________________
its mailing list
its@ietf.org
https://ww= w.ietf.org/mailman/listinfo/its


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


--001a1146a91e94d27e052d3bab02-- From nobody Fri Mar 4 08:52:44 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C581A1A1A92 for ; Fri, 4 Mar 2016 08:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, SPF_PASS=-0.001] autolearn=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 nTUV4iSdlhjr for ; Fri, 4 Mar 2016 08:52:40 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c: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 407B41A1A83 for ; Fri, 4 Mar 2016 08:52:38 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id l68so28202496wml.0 for ; Fri, 04 Mar 2016 08:52:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc; bh=hIp9TTJkBPly71mzeP9elkLhdUlsFxoSerdeGbOuWwA=; b=KHbrSZLzQOD4Z2CCsTYaqEL3QeTH3j3ruDnA57LIN+3lfJNp8EwqQmGHIuulFK1c3T jWsNekfERsjEcjMk+nt4wQx3ODin3iryHYst6s/grmsVuBflCy2FDnk89Gx8q5+Xfl0A s2k0H56QYvE3xZgjfpnuG4gC6ifp3IYgQdXKfSBIx8Dj9X+oiacnbKjJ1PPKJPdxu+Lk LlN0vPWhpB9qgz5CdYbJRnXhpyJskFWES0GozR4GEJ2w6cLzgtTi+N2NFv0DybN8ITDn Ntfqy1r08GNEsJBd2hAHwFxNoWpaeK7IWY5VCeMclnGym5ecHtvJN8lviFjIpWwU0hu5 A0GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=hIp9TTJkBPly71mzeP9elkLhdUlsFxoSerdeGbOuWwA=; b=hHZYgR36wUn6KGZVVZiz6DX3qeOYOa0q6M5ZTdhxGy3oHhSjIWzTFTbYjUdNKZ7OPD hbWQoX9C28diUCzclFgXOgKCS+49KdBL3GkSBuSG3aq/GdB6mgW7Nt2vwRmGdxOqGrKc A3OfhR+T1f18/50NXI0I4+XQZkBes++BDkEcuo11kAx3r8FvUNCuUI6dXT4p/llOXJBt VpcQ4DaBIX7mpXCoB5lmL8yTDnlVdYFek3BF2WA1k9H82JeVngXgja7rrNM6xrK6KtHI GmQgM7eBrMmZsy27sLILheuWEseKGgulWzwEWF7dHs47zboGhRU2+iwq59fdksLJ0b9P po1Q== X-Gm-Message-State: AD7BkJKZN0SIQZd1DSYdInh7l4UCWkwH3imDJThvXLa2PDEg5sbtSWjQvh1JDy597mAdK53+kqGRE8cVGFq/xg== MIME-Version: 1.0 X-Received: by 10.28.211.130 with SMTP id k124mr6346649wmg.7.1457110356750; Fri, 04 Mar 2016 08:52:36 -0800 (PST) Received: by 10.28.32.11 with HTTP; Fri, 4 Mar 2016 08:52:36 -0800 (PST) Date: Fri, 4 Mar 2016 16:52:36 +0000 Message-ID: From: Nabil Benamar To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a1146998e367ab5052d3bf159 Archived-At: Cc: "its@ietf.org" Subject: Re: [its] ITS Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 16:52:42 -0000 --001a1146998e367ab5052d3bf159 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, answers in the text. Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 http://nabilbenamar.ipv6-lab.net/ On Thu, Mar 3, 2016 at 2:50 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi, ITS, > > It seems this is the most recent message regarding the draft charter: > > https://mailarchive.ietf.org/arch/msg/its/RJIvo8LQEZXSpbaQ5gDq1WqKcBM > > Please find below a couple of additional comments for your consideration, > prefixed with =E2=80=9CCMP=E2=80=9D =E2=80=94 these also include some nit= s and questions. > > I would encourage thorough review and list discussion of this charter tex= t. > > > ITS (name to change) > > Charter > > CMP: ITS does not seem to expand to =E2=80=9Cname to change=E2=80=9D :-) > > > Goal > > ---- > > The goal of this group is to standardize IP protocols for establishing > > direct and secure connectivity between moving networks. > > CMP: My initial reaction was that perhaps this was a bit too broad =E2=80= =94 but > frankly I think short-and-sweet is good. > =E2=80=8B > =E2=80=8BWhat do you mean by short-and-sweet ?=E2=80=8B =E2=80=8Bwhat kind of sweetness in this context ?=E2=80=8B > =E2=80=8B > > > CMP: Are these =E2=80=9CIP protocols=E2=80=9D or =E2=80=9CIP-based protoc= ols=E2=80=9D? > =E2=80=8BThese are IP protocols and IPv6 more precisely ! =E2=80=8B > > CMP: Is this between moving networks only, or can one be fixed > (permanently or temporarily)? > =E2=80=8BI think that the draft covers all aspects of networks but we are m= ore focusing on V2V, moving networks to moving networks.=E2=80=8B > > > Moving Network to Nearby Moving Network Communications > > ------------------------------------------------------ > > The group is concerned with all situations involving moving network to > > nearby moving network communications. For example: vehicle-to-vehicle > > communications, nomadic user wearing a PAN and communicating to a > > homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a > > train, or train-to-intersection signalling. > > CMP: Again, a small (hopefully non-pedantic) point =E2=80=94 that a home = net or > the infrastructure are not moving, likely (reference to the ground :-). > > CMP: What is =E2=80=9Cnearby" moving? Might not hurt do scope/define it. > =E2=80=8BI think that Link layer media can differ based on the scope of the= signal !=E2=80=8B > > > Example from the automobile communications space > > ------------------------------------------------ > > Automobiles and vehicles of all types are increasingly connected to > > the Internet. > > CMP: Same distinction =E2=80=94 vehicle-to-vehicle, or vehicle-to-Interne= t, or > vehicle-to-infra? > > > in automobiles to hit the roads from now to year 2020. Highlighting > > increased safety as an immediate result of hyper-connectivity applied > > to vehicles, public authorities worldwide are increasingly mandating > > communication technology requirements in vehicles. > > CMP: I=E2=80=99d add =E2=80=9Cmandating *secure* communication technology= requirements=E2=80=9D. > =E2=80=8BAgree=E2=80=8B > > > > IP communication between vehicles (V2V), and between vehicles and the > > immediate infrastructure (V2I), will provide (0) ability to reach the > > rest of the world on the Inerenet (1) short and deterministic delays, > > (2) fast forwarding through scalable paths of routers, (3) ease of > > reuse of existing Internet applications in a vehicular environment. > > CMP: Typo, s/Inerenet/Internet/. > =E2=80=8BAgree=E2=80=8B > > CMP: Now, Isn=E2=80=99t (0) already provided (a few paragraphs above) wit= h > vehicle-to-Internet? > =E2=80=8B > > CMP: A meta-comment, I am surprised that requirements of =E2=80=9Cdiscove= ry=E2=80=9D and > =E2=80=9Cnaming=E2=80=9D are not called out. > =E2=80=8BAgree, since we are mentioning =E2=80=8B =E2=80=8BIPv6 so NDP by default=E2=80=8B > > > What kind of solutions? > > ----------------------- > > The current technical solutions considered to achieve moving network > > to nearby moving network communications are of two kinds: IP routing > > protocols for n-hop path management and 1-hop link-scoped IP protocol > > enhancements. > > CMP: It would be useful to also here specify scope of solutions in terms > of number of hops =E2=80=94 I thought this was 1-hop. > > CMP: Also, the Goal above is about =E2=80=9Cconnectivity=E2=80=9D. > > > In this proposed Working Group the focus is on 1-hop protocols, and > > leverage from other Working Groups for the n-hop situations. > > CMP: Sorry, what follows is this paragraph, forget my previous comment :-= ) > > > Work Items > > ---------- > > - use-cases for moving network to nearby moving network communications > > - Problem Statement for moving network to nearby moving network > > communications > > CMP: Are you thinking of use-cases and problem statements as individual > work items (drafts)? Are these one? And in fact one for V2V and V2I? > =E2=80=8BThis one is a charter, and drafts are the outcomes of the work of = wg members=E2=80=8B. However, the current charter is still a draft that could = be improved base on the comments in the list! > > - Security and Privacy Requirements for moving network to > > nearby moving network communications > > - Problem Statement for moving network to infrastructure network > > communications, including DNS > > - Potentially new protocol, or protocol extensions for establishing IP > > paths for 1-hop moving network to nearby moving network > communications. > > With MIB and security. > > CMP: I=E2=80=99d say =E2=80=98Solutions, which might include new protocol= s or extensions > to existing protocols=E2=80=9D > > CMP: What is a path in =E2=80=9C1-hop=E2=80=9D? Do you mean =E2=80=9Cconn= ectivity=E2=80=9D? > > CMP: MIBs? https://www.ietf.org/iesg/statement/writable-mib-module.html > > - IPv6-over foo, where foo is pertinent for moving network to nearby > > moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad= ) > > Thanks! I hope these are useful > =E2=80=8BVery useful !=E2=80=8B > > =E2=80=94 Carlos. > > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --001a1146998e367ab5052d3bf159 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carlos,

answers in the text.

=
Be= st regards
Nabil Benamar
-------------------
=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9= =D9=85=D8=B1=D9=88


On Thu, Mar 3, 2016 at 2:50 PM, Carlos Pigna= taro (cpignata) <cpignata@cisco.com> wrote:
Hi, ITS,

It seems this is the most recent message regarding the draft charter:

https://mailarchive.ietf.org/ar= ch/msg/its/RJIvo8LQEZXSpbaQ5gDq1WqKcBM

Please find below a couple of additional comments for your consideration, p= refixed with =E2=80=9CCMP=E2=80=9D =E2=80=94 these also include some nits a= nd questions.

I would encourage thorough review and list discussion of this charter text.=

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ITS (name to cha= nge)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Charter

CMP: ITS does not seem to expand to =E2=80=9Cname to change=E2=80=9D :-)
> Goal
> ----
> The goal of this group is to standardize IP protocols for establishing=
> direct and secure connectivity between moving networks.

CMP: My initial reaction was that perhaps this was a bit too broad =E2=80= =94 but frankly I think short-and-sweet is good.
=E2=80=8B

=E2=80=8BWhat do you mean by short= -and-sweet ?=E2=80=8B
=C2=A0
=E2=80=8Bwhat kind of sweetness in this context ?=E2=80=8B
=
=E2=80=8B


CMP: Are these =E2=80=9CIP protocols=E2=80=9D or =E2=80=9CIP-based protocol= s=E2=80=9D?

=E2=80=8BThese are IP protocols and IPv6 more precisely= ! =E2=80=8B
=C2=A0

CMP: Is this between moving networks only, or can one be fixed (permanently= or temporarily)?

=E2=80=8BI think that the draft covers all aspect= s of networks but we are more focusing on V2V, moving networks to moving ne= tworks.=E2=80=8B
=C2=A0

> Moving Network to Nearby Moving Network Communications
> ------------------------------------------------------
> The group is concerned with all situations involving moving network to=
> nearby moving network communications.=C2=A0 For example: vehicle-to-ve= hicle
> communications, nomadic user wearing a PAN and communicating to a
> homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a=
> train, or train-to-intersection signalling.

CMP: Again, a small (hopefully non-pedantic) point =E2=80=94 that a home ne= t or the infrastructure are not moving, likely (reference to the ground :-)= .

CMP: What is =E2=80=9Cnearby" moving? Might not hurt do scope/define i= t.

=E2=80=8BI think that Link layer media can differ based on the= scope of the signal !=E2=80=8B
=C2=A0

> Example from the automobile communications space
> ------------------------------------------------
> Automobiles and vehicles of all types are increasingly connected to > the Internet.

CMP: Same distinction =E2=80=94 vehicle-to-vehicle, or vehicle-to-Internet,= or vehicle-to-infra?

> in automobiles to hit the roads from now to year 2020. Highlighting > increased safety as an immediate result of hyper-connectivity applied<= br> > to vehicles, public authorities worldwide are increasingly mandating > communication technology requirements in vehicles.

CMP: I=E2=80=99d add =E2=80=9Cmandating *secure* communication technology r= equirements=E2=80=9D.

=E2=80=8BAgree=E2=80=8B
=C2=A0


> IP communication between vehicles (V2V), and between vehicles and the<= br> > immediate infrastructure (V2I), will provide (0) ability to reach the<= br> > rest of the world on the Inerenet (1) short and deterministic delays,<= br> > (2) fast forwarding through scalable paths of routers, (3) ease of
> reuse of existing Internet applications in a vehicular environment.
CMP: Typo, s/Inerenet/Internet/.

=E2=80=8BAgree=E2=80=8B
=C2= =A0

CMP: Now, Isn=E2=80=99t (0) already provided (a few paragraphs above) with = vehicle-to-Internet?
= =E2=80=8B
=C2=A0

CMP: A meta-comment, I am surprised that requirements of =E2=80=9Cdiscovery= =E2=80=9D and =E2=80=9Cnaming=E2=80=9D are not called out.
=

=E2=80= =8BAgree, since we are mentioning =E2=80=8B
=C2=A0
=E2=80=8BIPv6 so NDP by default=E2=80=8B

> What kind of solutions?
> -----------------------
> The current technical solutions considered to achieve moving network > to nearby moving network communications are of two kinds: IP routing > protocols for n-hop path management and 1-hop link-scoped IP protocol<= br> > enhancements.

CMP: It would be useful to also here specify scope of solutions in terms of= number of hops =E2=80=94 I thought this was 1-hop.

CMP: Also, the Goal above is about =E2=80=9Cconnectivity=E2=80=9D.

> In this proposed Working Group the focus is on 1-hop protocols, and > leverage from other Working Groups for the n-hop situations.

CMP: Sorry, what follows is this paragraph, forget my previous comment :-)<= br>
> Work Items
> ----------
> - use-cases for moving network to nearby moving network communications=
> - Problem Statement for moving network to nearby moving network
> communications

CMP: Are you thinking of use-cases and problem statements as individual wor= k items (drafts)? Are these one? And in fact one for V2V and V2I?

= =E2=80=8BThis one is a charter, and drafts are the outcomes of the work of = wg members=E2=80=8B. However, the current charter is still a draft that cou= ld be improved base on the comments in the list!
> - Security and Privacy Requirements for moving network to
>=C2=A0 =C2=A0 nearby moving network communications
> - Problem Statement for moving network to infrastructure network
>=C2=A0 =C2=A0 communications, including DNS
> - Potentially new protocol, or protocol extensions for establishing IP=
>=C2=A0 =C2=A0 paths for 1-hop moving network to nearby moving network c= ommunications.
>=C2=A0 =C2=A0 With MIB and security.

CMP: I=E2=80=99d say =E2=80=98Solutions, which might include new protocols = or extensions to existing protocols=E2=80=9D

CMP: What is a path in =E2=80=9C1-hop=E2=80=9D? Do you mean =E2=80=9Cconnec= tivity=E2=80=9D?

CMP: MIBs? https://www.ietf.org/iesg/sta= tement/writable-mib-module.html
> - IPv6-over foo, where foo is pertinent for moving network to nearby >=C2=A0 =C2=A0 moving network communications (e.g. 802.11 OCB, VLC, LTE-= D, 802.11ad)

Thanks! I hope these are useful

=E2=80=8BVery useful !=E2=80=8B=C2=A0

=E2=80=94 Carlos.





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


--001a1146998e367ab5052d3bf159-- From nobody Fri Mar 4 11:41:12 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F04B1A889F for ; Fri, 4 Mar 2016 11:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 77wKa35diskL for ; Fri, 4 Mar 2016 11:41:10 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 010EB1A88AF for ; Fri, 4 Mar 2016 11:41:10 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id 63so40210953pfe.3 for ; Fri, 04 Mar 2016 11:41:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=kRdVKneSwW8dHdryXKR0jGsMqbhujMn7gTl/qu8DPCE=; b=fv/1GHPIJ27/0dYfP3aBA0GLLPpjxMRAywGJShano2rApK5KOI4B8dMOCC5rpO+ttr RF3JjPYX+B0iuK/XTRLfQKMVhIKh4LCNlkvr8MYmYMfcBph8zZLf9QhIQ44o/fFs37E0 p4fVtIwdCRYeX2l+O+DoM6RyXjkJl/IjAvPKk6B12iy4/D+odJfzCH17wLDE1DxwYEdO iMKsu1wnU6GiHZsPZQRQaBivC4U+PmukWsxU3Hmdefss9td5MC+a+lQzVynX5NpaCYUd i5Xsbr3Fb1Wfnp0RLVdyDdIUdl2VIzHUU3+gywT1FJpFszLUHA9qPiUK0nQaYaoDhg0+ z/pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=kRdVKneSwW8dHdryXKR0jGsMqbhujMn7gTl/qu8DPCE=; b=FXtgX4mM9zAQ0ILfJL9V2+V3Pv5DuqpESyCoM4oaekk/8ZnVADV/4VuKirwetJMm9L ITzzzBwM+IrRtdarrX4vU3/u8ArlyPj4fnpZiFTM304uB33Faizg9dSYjsFOCQJYotTL XW7SAW9C4DY1sAKSceBq31zNHUdKERfih0NNnIZPu9374+BfMHfXorcFi9uAS+Wx06sA td8KssP2dzQEIJbSMie5XxfjMQ5Y2rvaug2B9dhLxq/aTmpkuwTgDQQpAXceZhxthu+N BPxweNLGPlFsFlFZDNwwqLz0jh8joCFDaKxE7Fe/Oo3ugPYlfLa3NF29qSTqH5/pCYnG hpfg== X-Gm-Message-State: AD7BkJKApYvNja1LFoNVv/XSGOWBosjPL+1ZZhSX2jOMiCuBK5j/INr51n2By7CTd7ZNlg== X-Received: by 10.98.89.199 with SMTP id k68mr5017470pfj.56.1457120469654; Fri, 04 Mar 2016 11:41:09 -0800 (PST) Received: from ?IPv6:2601:642:c201:788c:c91c:441b:c2ef:eb51? ([2601:642:c201:788c:c91c:441b:c2ef:eb51]) by smtp.gmail.com with ESMTPSA id ez6sm7338866pab.12.2016.03.04.11.41.08 (version=TLS1_2 cipher=AES128-GCM-SHA256 bits=128/128); Fri, 04 Mar 2016 11:41:09 -0800 (PST) Message-ID: <1457120467.2002.173.camel@localhost.localdomain> From: Rex Buddenberg To: Nabil Benamar Date: Fri, 04 Mar 2016 11:41:07 -0800 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "its@ietf.org" Subject: Re: [its] ITS Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 19:41:11 -0000 Nabil, Carlos, There's a sensitivity in here that, from a purely IETF experience, you might not be aware of. In US, National Highway Traffic Safety Agency (part of Dept of Transportation) is mandating a set of standards for vehicle-vehicle communications. The IEEE 1609 committee is trying to respond to this mandate by writing a set of standards. The vehicle-to-vehicle protocol stack voids the network and transport layers and, IMHO, cops out with a single-hop protocol stack (including a catalog of content messages). The single-hop solution has, again IMHO, several shortcomings with reach and discrimination. 1609 has a dual-stack cartoon with IPv6 stack as the second stack (and not much attention to it). Other than that, there's very little internetworking in the discussion or draft standard. My litmus test use case is an instrumented ambulance. You want things like 'virtual siren' to alert other vehicles on the road. But you also want to telemeter casualty data to the ER -- clearly an extend-the-internet case. Putting these in separate standards stovepipes is, again IMHO, a bad idea. Alex is trying to head off some of this in the language he chose. I might not have written it the same way, but this is at least part of the reasoning. On Fri, 2016-03-04 at 16:52 +0000, Nabil Benamar wrote: > > CMP: Are these “IP protocols†or “IP-based protocols� > > > ​These are IP protocols and IPv6 more precisely ! ​ > From nobody Sat Mar 5 23:44:50 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BCB1AD061 for ; Sat, 5 Mar 2016 23:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 oVGbQsB8zMDl for ; Sat, 5 Mar 2016 23:44:46 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 D11851AD062 for ; Sat, 5 Mar 2016 23:44:45 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id r187so62515539oih.3 for ; Sat, 05 Mar 2016 23:44:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=pqPWnR8Ot3BfjiEXMDnyyyr5tzIp9akNbu0R+BxpdOs=; b=hbjY7iWslpR+mLMKeU7tkP2N+qfQSJgAHrZaCsXGHOEVf9vmUe9lP/RcTZ/+N8R87s IfL8VwOz8YavuMaHxCRGv/KnsKf85gP265bJkNSKgFrzv7eUIU6sDUtgAsbz3sUhJI6o spSUsDTpt9bK+J+X6aoUiBmFbb7R+gXdKfxhECwyxzmht2AS6oeSR1dHrjqHlZ5WOEz4 KuGsMK+DqyxcpQvKAeeq4jDZh54/Glex+YlM/qlde627WRg3+TJvdjelrDPqszwy+xNF +QMrbYJkVqAmUN4WVsCNVEEgf/TxsU0XMzqDeYY60jCthq3TjgQUVdtkKwoqZSO0A7Ss 4FAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=pqPWnR8Ot3BfjiEXMDnyyyr5tzIp9akNbu0R+BxpdOs=; b=XRPCzROwhROA8XF+DaMwZ4t9YZlxIl46vRiUgnj5Gtdos6Ds/k0Rhm3M/uoqzKBsEx VMZgAy9obs3ZETWv5JR0sPj8tDPd+/r/vcHnrWMnPZPCLs2BDbowy0Fv7hO1FdGGk1iF oE9CKCR6uKZXDCsz08/4mChuC79lNUw+5s1vZjo9fJxg/fu5w5LOCYQxvOszZEowMA32 OtMmIfiJXcD3nt3XwuSzX9hnr6OJ1HLq7YKwIfFvnH26dCzWN/ElUSKDzDPJyHxIIRxB EufAIlhOSTn21gOIzsXsl+pN0McXovvx5jsyTkQ1vo9SnAo/bs8edwP89rC/S+SyGTzz dz0Q== X-Gm-Message-State: AD7BkJLfC4m/SB0zwhO1yHe5kLxF4RSfDvyUMwCj7LO+NzvM6XahxYBXRF43TF4z9WcVUVnfOIJaDXe1qjmFlw== MIME-Version: 1.0 X-Received: by 10.202.203.77 with SMTP id b74mr10830690oig.56.1457250285067; Sat, 05 Mar 2016 23:44:45 -0800 (PST) Received: by 10.202.104.163 with HTTP; Sat, 5 Mar 2016 23:44:45 -0800 (PST) In-Reply-To: <113DBE6A-A3DF-4149-8B75-139A2E3780B7@cisco.com> References: <113DBE6A-A3DF-4149-8B75-139A2E3780B7@cisco.com> Date: Sun, 6 Mar 2016 15:44:45 +0800 Message-ID: From: Dapeng Liu To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a1134fb449728f9052d5c8558 Archived-At: Cc: "its@ietf.org" Subject: Re: [its] ITS Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2016 07:44:48 -0000 --001a1134fb449728f9052d5c8558 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, Thanks for the comments. Please see my reply inline: 2016-03-03 22:50 GMT+08:00 Carlos Pignataro (cpignata) = : > Hi, ITS, > > It seems this is the most recent message regarding the draft charter: > > https://mailarchive.ietf.org/arch/msg/its/RJIvo8LQEZXSpbaQ5gDq1WqKcBM > > Please find below a couple of additional comments for your consideration, > prefixed with =E2=80=9CCMP=E2=80=9D =E2=80=94 these also include some nit= s and questions. > > I would encourage thorough review and list discussion of this charter tex= t. > > > ITS (name to change) > > Charter > > CMP: ITS does not seem to expand to =E2=80=9Cname to change=E2=80=9D :-) > [Dapeng] ITS (Intelligent Transportation System) is too broad and we are thinking whether there is a better name. > > > Goal > > ---- > > The goal of this group is to standardize IP protocols for establishing > > direct and secure connectivity between moving networks. > > CMP: My initial reaction was that perhaps this was a bit too broad =E2=80= =94 but > frankly I think short-and-sweet is good. > [Dapeng] We can change the wording to clarify that this group will focus on 1-hop communication between nearby moving networks to narrow down the scope= . > > CMP: Are these =E2=80=9CIP protocols=E2=80=9D or =E2=80=9CIP-based protoc= ols=E2=80=9D? > [Dapeng] Should be ""IP-based". > > CMP: Is this between moving networks only, or can one be fixed > (permanently or temporarily)? > [Dapeng] The other one can be fixed network. Will clarify the wording. > > > Moving Network to Nearby Moving Network Communications > > ------------------------------------------------------ > > The group is concerned with all situations involving moving network to > > nearby moving network communications. For example: vehicle-to-vehicle > > communications, nomadic user wearing a PAN and communicating to a > > homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a > > train, or train-to-intersection signalling. > > CMP: Again, a small (hopefully non-pedantic) point =E2=80=94 that a home = net or > the infrastructure are not moving, likely (reference to the ground :-). > > CMP: What is =E2=80=9Cnearby" moving? Might not hurt do scope/define it. > [Dapeng] OK. Will add scope&definition of "nearby". > > > Example from the automobile communications space > > ------------------------------------------------ > > Automobiles and vehicles of all types are increasingly connected to > > the Internet. > > CMP: Same distinction =E2=80=94 vehicle-to-vehicle, or vehicle-to-Interne= t, or > vehicle-to-infra? > > > in automobiles to hit the roads from now to year 2020. Highlighting > > increased safety as an immediate result of hyper-connectivity applied > > to vehicles, public authorities worldwide are increasingly mandating > > communication technology requirements in vehicles. > > CMP: I=E2=80=99d add =E2=80=9Cmandating *secure* communication technology= requirements=E2=80=9D. > [Dapeng] Agree. > > > > IP communication between vehicles (V2V), and between vehicles and the > > immediate infrastructure (V2I), will provide (0) ability to reach the > > rest of the world on the Inerenet (1) short and deterministic delays, > > (2) fast forwarding through scalable paths of routers, (3) ease of > > reuse of existing Internet applications in a vehicular environment. > > CMP: Typo, s/Inerenet/Internet/. > > CMP: Now, Isn=E2=80=99t (0) already provided (a few paragraphs above) wit= h > vehicle-to-Internet? > > > CMP: A meta-comment, I am surprised that requirements of =E2=80=9Cdiscove= ry=E2=80=9D and > =E2=80=9Cnaming=E2=80=9D are not called out. > [Dapeng] Yes, discovery should be considered in the solution. Probably we need to add some text on that. > > > What kind of solutions? > > ----------------------- > > The current technical solutions considered to achieve moving network > > to nearby moving network communications are of two kinds: IP routing > > protocols for n-hop path management and 1-hop link-scoped IP protocol > > enhancements. > > CMP: It would be useful to also here specify scope of solutions in terms > of number of hops =E2=80=94 I thought this was 1-hop. > > CMP: Also, the Goal above is about =E2=80=9Cconnectivity=E2=80=9D. > > > In this proposed Working Group the focus is on 1-hop protocols, and > > leverage from other Working Groups for the n-hop situations. > > CMP: Sorry, what follows is this paragraph, forget my previous comment :-= ) > > > Work Items > > ---------- > > - use-cases for moving network to nearby moving network communications > > - Problem Statement for moving network to nearby moving network > > communications > > CMP: Are you thinking of use-cases and problem statements as individual > work items (drafts)? Are these one? And in fact one for V2V and V2I? > [Dapeng] One draft for all the use-cases and one draft for the problem statement. > > - Security and Privacy Requirements for moving network to > > nearby moving network communications > > - Problem Statement for moving network to infrastructure network > > communications, including DNS > > - Potentially new protocol, or protocol extensions for establishing IP > > paths for 1-hop moving network to nearby moving network > communications. > > With MIB and security. > > CMP: I=E2=80=99d say =E2=80=98Solutions, which might include new protocol= s or extensions > to existing protocols=E2=80=9D > > CMP: What is a path in =E2=80=9C1-hop=E2=80=9D? Do you mean =E2=80=9Cconn= ectivity=E2=80=9D? > [Dapeng] Yes, maybe =E2=80=9Cconnectivity=E2=80=9D is better. > > CMP: MIBs? https://www.ietf.org/iesg/statement/writable-mib-module.html [Dapeng] OK. Will change "MIBs" to "NETCONF/YANG "... > > > - IPv6-over foo, where foo is pertinent for moving network to nearby > > moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad= ) > > Thanks! I hope these are useful > [Dapeng] Thanks, the comments are very helpful. -Dapeng Liu > > =E2=80=94 Carlos. > > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --=20 ------ Best Regards, Dapeng Liu --001a1134fb449728f9052d5c8558 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carlos,

Thanks for the comments. Ple= ase see my reply inline:

2016-03-03 22:50 GMT+08:00 Carlos Pignataro (cpignata) <cpigna= ta@cisco.com>:
Hi, ITS,

It seems this is the most recent message regarding the draft charter:

https://mailarchive.ietf.org/ar= ch/msg/its/RJIvo8LQEZXSpbaQ5gDq1WqKcBM

Please find below a couple of additional comments for your consideration, p= refixed with =E2=80=9CCMP=E2=80=9D =E2=80=94 these also include some nits a= nd questions.

I would encourage thorough review and list discussion of this charter text.=

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ITS (name to cha= nge)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Charter

CMP: ITS does not seem to expand to =E2=80=9Cname to change=E2=80=9D :-)
=C2=A0
[Dapeng] ITS (Intelligent=C2=A0Transpor= tation System) is too broad and we are thinking whether there is a better n= ame.
=C2=A0

> Goal
> ----
> The goal of this group is to standardize IP protocols for establishing=
> direct and secure connectivity between moving networks.

CMP: My initial reaction was that perhaps this was a bit too broad =E2=80= =94 but frankly I think short-and-sweet is good.

<= /div>
[Dapeng] We can=C2=A0change=C2=A0the wording to clarify that this= group will focus on 1-hop communication between nearby moving networks to = narrow down the scope.
=C2=A0

CMP: Are these =E2=80=9CIP protocols=E2=80=9D or =E2=80=9CIP-based protocol= s=E2=80=9D?

[Dapeng] Should be "&q= uot;IP-based".
=C2=A0

CMP: Is this between moving networks only, or can one be fixed (permanently= or temporarily)?

[Dapeng] The other on= e can be fixed network. Will clarify the wording.
=C2=A0

> Moving Network to Nearby Moving Network Communications
> ------------------------------------------------------
> The group is concerned with all situations involving moving network to=
> nearby moving network communications.=C2=A0 For example: vehicle-to-ve= hicle
> communications, nomadic user wearing a PAN and communicating to a
> homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a=
> train, or train-to-intersection signalling.

CMP: Again, a small (hopefully non-pedantic) point =E2=80=94 that a home ne= t or the infrastructure are not moving, likely (reference to the ground :-)= .

CMP: What is =E2=80=9Cnearby" moving? Might not hurt do scope/define i= t.

[Dapeng] OK. Will add scope&defi= nition of "nearby".

> Example from the automobile communications space
> ------------------------------------------------
> Automobiles and vehicles of all types are increasingly connected to > the Internet.

CMP: Same distinction =E2=80=94 vehicle-to-vehicle, or vehicle-to-Internet,= or vehicle-to-infra?

> in automobiles to hit the roads from now to year 2020. Highlighting > increased safety as an immediate result of hyper-connectivity applied<= br> > to vehicles, public authorities worldwide are increasingly mandating > communication technology requirements in vehicles.

CMP: I=E2=80=99d add =E2=80=9Cmandating *secure* communication technology r= equirements=E2=80=9D.

[Dapeng] Agree.
=C2=A0


> IP communication between vehicles (V2V), and between vehicles and the<= br> > immediate infrastructure (V2I), will provide (0) ability to reach the<= br> > rest of the world on the Inerenet (1) short and deterministic delays,<= br> > (2) fast forwarding through scalable paths of routers, (3) ease of
> reuse of existing Internet applications in a vehicular environment.
CMP: Typo, s/Inerenet/Internet/.

CMP: Now, Isn=E2=80=99t (0) already provided (a few paragraphs above) with = vehicle-to-Internet?

=C2=A0
CMP: A meta-comment, I am surprised that requirements of =E2=80=9Cdiscovery= =E2=80=9D and =E2=80=9Cnaming=E2=80=9D are not called out.
=

[Dapeng] =C2=A0Yes, discovery should be considered in t= he solution. Probably we need to add some text on that.

> What kind of solutions?
> -----------------------
> The current technical solutions considered to achieve moving network > to nearby moving network communications are of two kinds: IP routing > protocols for n-hop path management and 1-hop link-scoped IP protocol<= br> > enhancements.

CMP: It would be useful to also here specify scope of solutions in terms of= number of hops =E2=80=94 I thought this was 1-hop.

CMP: Also, the Goal above is about =E2=80=9Cconnectivity=E2=80=9D.

> In this proposed Working Group the focus is on 1-hop protocols, and > leverage from other Working Groups for the n-hop situations.

CMP: Sorry, what follows is this paragraph, forget my previous comment :-)<= br>
> Work Items
> ----------
> - use-cases for moving network to nearby moving network communications=
> - Problem Statement for moving network to nearby moving network
> communications

CMP: Are you thinking of use-cases and problem statements as individual wor= k items (drafts)? Are these one? And in fact one for V2V and V2I?

[Dapeng] One draft for all the use-cases and one= draft for the problem statement.
=C2=A0
> - Security and Privacy Requirements for moving network to
>=C2=A0 =C2=A0 nearby moving network communications
> - Problem Statement for moving network to infrastructure network
>=C2=A0 =C2=A0 communications, including DNS
> - Potentially new protocol, or protocol extensions for establishing IP=
>=C2=A0 =C2=A0 paths for 1-hop moving network to nearby moving network c= ommunications.
>=C2=A0 =C2=A0 With MIB and security.

CMP: I=E2=80=99d say =E2=80=98Solutions, which might include new protocols = or extensions to existing protocols=E2=80=9D

CMP: What is a path in =E2=80=9C1-hop=E2=80=9D? Do you mean =E2=80=9Cconnec= tivity=E2=80=9D?

[Dapeng] Yes, maybe = =E2=80=9Cconnectivity=E2=80=9D is better.

CMP: MIBs? https://www.ietf.org/iesg/sta= tement/writable-mib-module.html

[Dapeng= ] OK. Will change "MIBs" to "NETCON= F/YANG "...

> - IPv6-over foo, where foo is pertinent for moving network to nearby >=C2=A0 =C2=A0 moving network communications (e.g. 802.11 OCB, VLC, LTE-= D, 802.11ad)

Thanks! I hope these are useful

[Dapeng= ] Thanks, the comments are very helpful.

-Dapeng L= iu
=C2=A0

=E2=80=94 Carlos.





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




--

------
Best Regards,
Dapeng Liu
--001a1134fb449728f9052d5c8558-- From nobody Sun Mar 6 10:48:56 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FBC1B30D2 for ; Sun, 6 Mar 2016 10:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001, URIBL_DBL_ABUSE_BOTCC=2.5] autolearn=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 V--BQLkjoO5U for ; Sun, 6 Mar 2016 10:48:52 -0800 (PST) Received: from mail-yk0-x241.google.com (mail-yk0-x241.google.com [IPv6:2607:f8b0:4002:c07::241]) (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 C4BE81B30C7 for ; Sun, 6 Mar 2016 10:48:51 -0800 (PST) Received: by mail-yk0-x241.google.com with SMTP id q2so2846739yka.0 for ; Sun, 06 Mar 2016 10:48:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eRQpm27pABzNOx/LIqA3myGH1dChC/dRd36aqVMfMhs=; b=Mz78c8cUPwhwDo5r6jZZH5Z8LOdeOhq6lxBtxvwxIZZNI9ywGUiXNMvMsg2b39zVbC 3LeXSmVZ/Aw7MpaQV2Rvfj3RbnqSCJmose6paAbxqk8JFA5tAqs953nbpBVhhzhuoQKA QCw0ee8ld6VmCXMgRtyKtgV/zfz93ldR+o47cpaGC/mcwvC6wZ26ks2/0I1WenEGW3a2 hg6ZTdCPFMOKBVnbS5TwwDGR/97ukyoAvJw0P50M7EV2zV1+WSDaKSEO0cEX4t6SVWq8 ev7kKEHdZeLn/KgR1SQKqiE/TrcP+ouyLfE63xP6O6bnz/f4uhh7lE27I2pqHa9IN6mj I8OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eRQpm27pABzNOx/LIqA3myGH1dChC/dRd36aqVMfMhs=; b=Vg83fnWeIkLIwocvZzEjXghUdBKKkVTHZDJkupDEtrRCaGCQvaTtEBVqWFCo1PFJxm wkvYWZfqb7MehKBppSecFRgsxIE2tz+5MDFj6SIT7YiRMlHNgIvMvkz6LCli2BLJ5gZG LJoVipBCAPxF3j4rGa1NvljIplFj2oza+TRoVWBuPrS9b11HRNlQH/2AcFUBK2hd6J7F Ug2ba7E7IfNRRNJQngIpJQx8jxm54K4TmYuzjJjVtQr23p1IRvNAwtS4+4lmgzUIPSxe cmE+PR+NLz1Il8Fjhx04VL/FoBXLg4ftKV3PQ2J4K5G8zdIuIM4CQ/XyDScyRDKiM49l 57HA== X-Gm-Message-State: AD7BkJKOyhXBNzVT2toqkrCZnP8ph83Lwsg5O9N82aGdxIgbuQbfapFpNOUSLsoT+Zsuurarbv905BZjdNOlqw== X-Received: by 10.37.98.195 with SMTP id w186mr10299120ybb.39.1457290130967; Sun, 06 Mar 2016 10:48:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.83.87 with HTTP; Sun, 6 Mar 2016 10:48:21 -0800 (PST) In-Reply-To: <113DBE6A-A3DF-4149-8B75-139A2E3780B7@cisco.com> References: <113DBE6A-A3DF-4149-8B75-139A2E3780B7@cisco.com> From: "Mr. Jaehoon Paul Jeong" Date: Mon, 7 Mar 2016 03:48:21 +0900 Message-ID: To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a1142e7fc9753cd052d65cc77 Archived-At: Cc: "its@ietf.org" Subject: Re: [its] ITS Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2016 18:48:54 -0000 --001a1142e7fc9753cd052d65cc77 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, >CMP: Are you thinking of use-cases and problem statements as individual work items (drafts)? Are these one? And in fact one for V2V and V2I? As Dapeng Liu mentioned, we will work on the use cases for V2V and V2I with one draft and the problem statements for V2V and V2I with another draft. Thanks. Paul --=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 On Thu, Mar 3, 2016 at 11:50 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi, ITS, > > It seems this is the most recent message regarding the draft charter: > > https://mailarchive.ietf.org/arch/msg/its/RJIvo8LQEZXSpbaQ5gDq1WqKcBM > > Please find below a couple of additional comments for your consideration, > prefixed with =E2=80=9CCMP=E2=80=9D =E2=80=94 these also include some nit= s and questions. > > I would encourage thorough review and list discussion of this charter tex= t. > > > ITS (name to change) > > Charter > > CMP: ITS does not seem to expand to =E2=80=9Cname to change=E2=80=9D :-) > > > Goal > > ---- > > The goal of this group is to standardize IP protocols for establishing > > direct and secure connectivity between moving networks. > > CMP: My initial reaction was that perhaps this was a bit too broad =E2=80= =94 but > frankly I think short-and-sweet is good. > > CMP: Are these =E2=80=9CIP protocols=E2=80=9D or =E2=80=9CIP-based protoc= ols=E2=80=9D? > > CMP: Is this between moving networks only, or can one be fixed > (permanently or temporarily)? > > > Moving Network to Nearby Moving Network Communications > > ------------------------------------------------------ > > The group is concerned with all situations involving moving network to > > nearby moving network communications. For example: vehicle-to-vehicle > > communications, nomadic user wearing a PAN and communicating to a > > homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a > > train, or train-to-intersection signalling. > > CMP: Again, a small (hopefully non-pedantic) point =E2=80=94 that a home = net or > the infrastructure are not moving, likely (reference to the ground :-). > > CMP: What is =E2=80=9Cnearby" moving? Might not hurt do scope/define it. > > > Example from the automobile communications space > > ------------------------------------------------ > > Automobiles and vehicles of all types are increasingly connected to > > the Internet. > > CMP: Same distinction =E2=80=94 vehicle-to-vehicle, or vehicle-to-Interne= t, or > vehicle-to-infra? > > > in automobiles to hit the roads from now to year 2020. Highlighting > > increased safety as an immediate result of hyper-connectivity applied > > to vehicles, public authorities worldwide are increasingly mandating > > communication technology requirements in vehicles. > > CMP: I=E2=80=99d add =E2=80=9Cmandating *secure* communication technology= requirements=E2=80=9D. > > > > IP communication between vehicles (V2V), and between vehicles and the > > immediate infrastructure (V2I), will provide (0) ability to reach the > > rest of the world on the Inerenet (1) short and deterministic delays, > > (2) fast forwarding through scalable paths of routers, (3) ease of > > reuse of existing Internet applications in a vehicular environment. > > CMP: Typo, s/Inerenet/Internet/. > > CMP: Now, Isn=E2=80=99t (0) already provided (a few paragraphs above) wit= h > vehicle-to-Internet? > > CMP: A meta-comment, I am surprised that requirements of =E2=80=9Cdiscove= ry=E2=80=9D and > =E2=80=9Cnaming=E2=80=9D are not called out. > > > What kind of solutions? > > ----------------------- > > The current technical solutions considered to achieve moving network > > to nearby moving network communications are of two kinds: IP routing > > protocols for n-hop path management and 1-hop link-scoped IP protocol > > enhancements. > > CMP: It would be useful to also here specify scope of solutions in terms > of number of hops =E2=80=94 I thought this was 1-hop. > > CMP: Also, the Goal above is about =E2=80=9Cconnectivity=E2=80=9D. > > > In this proposed Working Group the focus is on 1-hop protocols, and > > leverage from other Working Groups for the n-hop situations. > > CMP: Sorry, what follows is this paragraph, forget my previous comment :-= ) > > > Work Items > > ---------- > > - use-cases for moving network to nearby moving network communications > > - Problem Statement for moving network to nearby moving network > > communications > > CMP: Are you thinking of use-cases and problem statements as individual > work items (drafts)? Are these one? And in fact one for V2V and V2I? > > - Security and Privacy Requirements for moving network to > > nearby moving network communications > > - Problem Statement for moving network to infrastructure network > > communications, including DNS > > - Potentially new protocol, or protocol extensions for establishing IP > > paths for 1-hop moving network to nearby moving network > communications. > > With MIB and security. > > CMP: I=E2=80=99d say =E2=80=98Solutions, which might include new protocol= s or extensions > to existing protocols=E2=80=9D > > CMP: What is a path in =E2=80=9C1-hop=E2=80=9D? Do you mean =E2=80=9Cconn= ectivity=E2=80=9D? > > CMP: MIBs? https://www.ietf.org/iesg/statement/writable-mib-module.html > > - IPv6-over foo, where foo is pertinent for moving network to nearby > > moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad= ) > > Thanks! I hope these are useful > > =E2=80=94 Carlos. > > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --001a1142e7fc9753cd052d65cc77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carlos,

&= gt;CMP: Are you thinking of use-cases and problem statements as individual = work items (drafts)? Are these one? And in fact one for V2V and V2I?=

As=C2=A0Dapeng Liu mentioned, we wil= l work on the use cases for V2V and V2I with one draft and
the=C2=A0problem statements=C2=A0for= V2V and V2I=C2=A0with another draft.

=
Thanks.

Paul
--=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 UniversityOffice: +82-31-299-4957
Email:=C2=A0jaehoon.paul@gmail.com,=C2=A0pauljeong= @skku.edu
Personal Homepage:=C2=A0http://iotlab.skku.edu/people-j= aehoon-jeong.php


On Thu, Mar 3, 2016 at 11:50 PM, Carlos Pignataro (cpignata) <= span dir=3D"ltr"><cpignata@cisco.com> wrote:
Hi, ITS,

It seems this is the most recent message regarding the draft charter:

https://mailarchive.ietf.org/ar= ch/msg/its/RJIvo8LQEZXSpbaQ5gDq1WqKcBM

Please find below a couple of additional comments for your consideration, p= refixed with =E2=80=9CCMP=E2=80=9D =E2=80=94 these also include some nits a= nd questions.

I would encourage thorough review and list discussion of this charter text.=

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ITS (name to cha= nge)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Charter

CMP: ITS does not seem to expand to =E2=80=9Cname to change=E2=80=9D :-)
> Goal
> ----
> The goal of this group is to standardize IP protocols for establishing=
> direct and secure connectivity between moving networks.

CMP: My initial reaction was that perhaps this was a bit too broad =E2=80= =94 but frankly I think short-and-sweet is good.

CMP: Are these =E2=80=9CIP protocols=E2=80=9D or =E2=80=9CIP-based protocol= s=E2=80=9D?

CMP: Is this between moving networks only, or can one be fixed (permanently= or temporarily)?

> Moving Network to Nearby Moving Network Communications
> ------------------------------------------------------
> The group is concerned with all situations involving moving network to=
> nearby moving network communications.=C2=A0 For example: vehicle-to-ve= hicle
> communications, nomadic user wearing a PAN and communicating to a
> homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a=
> train, or train-to-intersection signalling.

CMP: Again, a small (hopefully non-pedantic) point =E2=80=94 that a home ne= t or the infrastructure are not moving, likely (reference to the ground :-)= .

CMP: What is =E2=80=9Cnearby" moving? Might not hurt do scope/define i= t.

> Example from the automobile communications space
> ------------------------------------------------
> Automobiles and vehicles of all types are increasingly connected to > the Internet.

CMP: Same distinction =E2=80=94 vehicle-to-vehicle, or vehicle-to-Internet,= or vehicle-to-infra?

> in automobiles to hit the roads from now to year 2020. Highlighting > increased safety as an immediate result of hyper-connectivity applied<= br> > to vehicles, public authorities worldwide are increasingly mandating > communication technology requirements in vehicles.

CMP: I=E2=80=99d add =E2=80=9Cmandating *secure* communication technology r= equirements=E2=80=9D.


> IP communication between vehicles (V2V), and between vehicles and the<= br> > immediate infrastructure (V2I), will provide (0) ability to reach the<= br> > rest of the world on the Inerenet (1) short and deterministic delays,<= br> > (2) fast forwarding through scalable paths of routers, (3) ease of
> reuse of existing Internet applications in a vehicular environment.
CMP: Typo, s/Inerenet/Internet/.

CMP: Now, Isn=E2=80=99t (0) already provided (a few paragraphs above) with = vehicle-to-Internet?

CMP: A meta-comment, I am surprised that requirements of =E2=80=9Cdiscovery= =E2=80=9D and =E2=80=9Cnaming=E2=80=9D are not called out.

> What kind of solutions?
> -----------------------
> The current technical solutions considered to achieve moving network > to nearby moving network communications are of two kinds: IP routing > protocols for n-hop path management and 1-hop link-scoped IP protocol<= br> > enhancements.

CMP: It would be useful to also here specify scope of solutions in terms of= number of hops =E2=80=94 I thought this was 1-hop.

CMP: Also, the Goal above is about =E2=80=9Cconnectivity=E2=80=9D.

> In this proposed Working Group the focus is on 1-hop protocols, and > leverage from other Working Groups for the n-hop situations.

CMP: Sorry, what follows is this paragraph, forget my previous comment :-)<= br>
> Work Items
> ----------
> - use-cases for moving network to nearby moving network communications=
> - Problem Statement for moving network to nearby moving network
> communications

CMP: Are you thinking of use-cases and problem statements as individual wor= k items (drafts)? Are these one? And in fact one for V2V and V2I?
> - Security and Privacy Requirements for moving network to
>=C2=A0 =C2=A0 nearby moving network communications
> - Problem Statement for moving network to infrastructure network
>=C2=A0 =C2=A0 communications, including DNS
> - Potentially new protocol, or protocol extensions for establishing IP=
>=C2=A0 =C2=A0 paths for 1-hop moving network to nearby moving network c= ommunications.
>=C2=A0 =C2=A0 With MIB and security.

CMP: I=E2=80=99d say =E2=80=98Solutions, which might include new protocols = or extensions to existing protocols=E2=80=9D

CMP: What is a path in =E2=80=9C1-hop=E2=80=9D? Do you mean =E2=80=9Cconnec= tivity=E2=80=9D?

CMP: MIBs? https://www.ietf.org/iesg/sta= tement/writable-mib-module.html
> - IPv6-over foo, where foo is pertinent for moving network to nearby >=C2=A0 =C2=A0 moving network communications (e.g. 802.11 OCB, VLC, LTE-= D, 802.11ad)

Thanks! I hope these are useful

=E2=80=94 Carlos.





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


--001a1142e7fc9753cd052d65cc77-- From nobody Sun Mar 6 11:07:19 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF941B3130 for ; Sun, 6 Mar 2016 11:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 mCGs8mf7aN4D for ; Sun, 6 Mar 2016 11:07:14 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04CBA1B312D for ; Sun, 6 Mar 2016 11:07:13 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u26J7BLI019083 for ; Sun, 6 Mar 2016 20:07:11 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E5D71202BAA for ; Sun, 6 Mar 2016 20:07:35 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DDA5A200DC2 for ; Sun, 6 Mar 2016 20:07:35 +0100 (CET) Received: from [132.166.84.130] ([132.166.84.130]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u26J7ApN011960 for ; Sun, 6 Mar 2016 20:07:11 +0100 To: its@ietf.org References: <113DBE6A-A3DF-4149-8B75-139A2E3780B7@cisco.com> From: Alexandre Petrescu Message-ID: <56DC7FDE.4060001@gmail.com> Date: Sun, 6 Mar 2016 20:07:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <113DBE6A-A3DF-4149-8B75-139A2E3780B7@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] ITS Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2016 19:07:17 -0000 Le 03/03/2016 15:50, Carlos Pignataro (cpignata) a écrit : > Hi, ITS, > > It seems this is the most recent message regarding the draft > charter: > > https://mailarchive.ietf.org/arch/msg/its/RJIvo8LQEZXSpbaQ5gDq1WqKcBM Yes. > > Please find below a couple of additional comments for your > consideration, prefixed with “CMP” — these also include some nits and > questions. > > I would encourage thorough review and list discussion of this charter > text. > >> ITS (name to change) Charter > > CMP: ITS does not seem to expand to “name to change” :-) Right, but we may need a better name. >> Goal ---- The goal of this group is to standardize IP protocols for >> establishing direct and secure connectivity between moving >> networks. > > CMP: My initial reaction was that perhaps this was a bit too broad — > but frankly I think short-and-sweet is good. > > CMP: Are these “IP protocols” or “IP-based protocols”? I think IP-based protocols. For example ICMP is an IP-based protocol, whereas WAP (Wireless Application Protocol) is not an IP-based protocol because it has no IP headers. > CMP: Is this between moving networks only, or can one be fixed > (permanently or temporarily)? One can be fixed permanently or temporarily. An example is a PAN entering a homenet, or a spacesuit near a spacecraft (in this context it's harder to say what's 'fixed'.) But one can get the idea. >> Moving Network to Nearby Moving Network Communications >> ------------------------------------------------------ The group is >> concerned with all situations involving moving network to nearby >> moving network communications. For example: vehicle-to-vehicle >> communications, nomadic user wearing a PAN and communicating to a >> homenet, vehicle-to-infrastructure communications, wagon-to-wagon >> in a train, or train-to-intersection signalling. > > CMP: Again, a small (hopefully non-pedantic) point — that a home net > or the infrastructure are not moving, likely (reference to the ground > :-). > > CMP: What is “nearby" moving? Might not hurt do scope/define it. I agree. As part of terminology work we will have to define precisely what is moving network, and what is a 'nearby moving network'. >> Example from the automobile communications space >> ------------------------------------------------ Automobiles and >> vehicles of all types are increasingly connected to the Internet. > > CMP: Same distinction — vehicle-to-vehicle, or vehicle-to-Internet, > or vehicle-to-infra? > >> in automobiles to hit the roads from now to year 2020. >> Highlighting increased safety as an immediate result of >> hyper-connectivity applied to vehicles, public authorities >> worldwide are increasingly mandating communication technology >> requirements in vehicles. > > CMP: I’d add “mandating *secure* communication technology > requirements”. I agree. > > >> IP communication between vehicles (V2V), and between vehicles and >> the immediate infrastructure (V2I), will provide (0) ability to >> reach the rest of the world on the Inerenet (1) short and >> deterministic delays, (2) fast forwarding through scalable paths of >> routers, (3) ease of reuse of existing Internet applications in a >> vehicular environment. > > CMP: Typo, s/Inerenet/Internet/. > > CMP: Now, Isn’t (0) already provided (a few paragraphs above) with > vehicle-to-Internet? Well we can discuss. It depends what is the "V2I". An intuitive first thought is that the Internet is all that is fixed. A moving network in an automobile using its GPRS interface is typically connecting to the Internet and there is no new work to do, because it's already there. But the Internet could be reached via other vehicles as well, not necessarily through its own GPRS link. The other day driving on the highway I followed a disneyland bus; my passenger could connect her smartphone to the bus wifi and from there to the Internet. As such I think moving network reaching the Internet (V2I) is more than just using its own cellular link. The other issue with the "V2I" term is that it means "Vehicle-to-Infrastructure" sometimes. And that V2I does not mean Internet. For example a car at toll situation, or a car on an electrical charging station. One IP computer in the car needs to talk to one IP computer among the numerous IP computers in the toll station, or in the CS. And this is a very close server, not on the Internet-at-large. For these reasons in some earlier focused discussion we said it may be simpler to just say "reach the rest of the world on the Internet", and not assume that just "V2I" covers it all. > CMP: A meta-comment, I am surprised that requirements of “discovery” > and “naming” are not called out. I agree they should be. > >> What kind of solutions? ----------------------- The current >> technical solutions considered to achieve moving network to nearby >> moving network communications are of two kinds: IP routing >> protocols for n-hop path management and 1-hop link-scoped IP >> protocol enhancements. > > CMP: It would be useful to also here specify scope of solutions in > terms of number of hops — I thought this was 1-hop. We need to clarify this. It is 1-hop between the moving networks, but each moving network may have several IP hops inside. That 1-IP-hop between moving networks is the only variable characteristic (it's often a WiFi, 11p or other radio link) whereas the IP hops inside the moving networks are very stable. We do not look at more than 1 hop between moving networks - that's MANET. We can not put any Server on that variable 1-hop. There's no DHCP Server on that 1-hop that could do address allocation, nor DNS server that could be discovered with existing link-scoped DNS discovery techniques, and no designated Router that could advertise a prefix of that link - because the link is very short-lived (it's hard to determine quickly prefix ownership on variable links). If there is any such server it must be either in the fixed infrastructure, or in the fixed part inside a moving network. > CMP: Also, the Goal above is about “connectivity”. Yes, connectivity at IP layer, in the sense that an IP device must become able to talk to any other IP device in a nearby (1-hop) moving network. >> In this proposed Working Group the focus is on 1-hop protocols, >> and leverage from other Working Groups for the n-hop situations. > > CMP: Sorry, what follows is this paragraph, forget my previous > comment :-) > >> Work Items ---------- - use-cases for moving network to nearby >> moving network communications - Problem Statement for moving >> network to nearby moving network communications > > CMP: Are you thinking of use-cases and problem statements as > individual work items (drafts)? Are these one? And in fact one for > V2V and V2I? Currently we think 1 PS draft and 1 use-case draft (including V2V and V2I sections). But we need to agree. >> - Security and Privacy Requirements for moving network to nearby >> moving network communications - Problem Statement for moving >> network to infrastructure network communications, including DNS - >> Potentially new protocol, or protocol extensions for establishing >> IP paths for 1-hop moving network to nearby moving network >> communications. With MIB and security. > > CMP: I’d say ‘Solutions, which might include new protocols or > extensions to existing protocols” I agree. > CMP: What is a path in “1-hop”? Do you mean “connectivity”? I think we should say a path is between IP devices and that there may be n hops between them. But there is only one variable part which is the crux of the problem - the 1-hop between moving networks which is typically a radio link (or visible light comms, or IP-over-charge-while-driving rails). The paths are like this: IP1-----Router----Router .... Router---Router----IP2 The dashed lines are fixed links inside the moving networks and the dots are the 1-hop which makes the problem. > CMP: MIBs? > https://www.ietf.org/iesg/statement/writable-mib-module.html I agree we should. >> - IPv6-over foo, where foo is pertinent for moving network to >> nearby moving network communications (e.g. 802.11 OCB, VLC, LTE-D, >> 802.11ad) > > Thanks! I hope these are useful Yes, the charter should be modified accordingly. Alex > > — Carlos. > > > > > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From nobody Sun Mar 6 14:42:49 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24971B3B66 for ; Sun, 6 Mar 2016 14:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 y9_YsUt7zznT for ; Sun, 6 Mar 2016 14:42:46 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 AD8031B3B6A for ; Sun, 6 Mar 2016 14:42:46 -0800 (PST) Received: by mail-pa0-x231.google.com with SMTP id bj10so67181901pad.2 for ; Sun, 06 Mar 2016 14:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=t+sTQoErAqxe8IcQ8/IqN7Pqx5lTOjCJ2Z6bVkHFhuA=; b=V4+7UrE7usaxbWXl5Fj2gNv3voCI2j8WCgDVVComgKFNhKZPwIvXM5cxVPrKJhljgi 9nFUCTg8/SApBfOYrF7J7HurLPM214ySwNPzZ+s7WCC07eote8IJ4agG/8FN7axOwLBS /aSJ51/4PJHAw2JhJhRVcidHlpR5h2ghpw/HIKU0jy2kvtw8dyWKj6zrBW/M/FPOm9zu SmFmuX1TnkGpfvFAATqQ0ujPcrQA3XYCiOhFEkpaxzHGkdDu/aSfauntks1WMo9uD+kh yMPoj+1fKs6lRWVS7itEPbp6k7mHqoLJv0zmS+zZ4+rpjKDPbt+AGT8Miksh71rdtKSH amEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=t+sTQoErAqxe8IcQ8/IqN7Pqx5lTOjCJ2Z6bVkHFhuA=; b=HO58qX50PbkmM4uNUC9W+1N03xh8Vy1kDiR5M6Immr5e3zTtrwrOHD8MVz421SVOqG QO+KFVB9e8HApwhjR43ivk2y85Sn5Ess0HqfIGleIy8MMgo1PaijiaeFWL4zS7o3Uy6H oYjzxnH0bxOHUPueWKN2q2WEtUbkicr79+O3zIkNm5gsdM/gONYuQORLaCcqhc4jE3fZ Mj2KcZxZlNo9VdeGedAHHTfJF2Q0lc5baCWbZQKHfg2+ziXqcfVr30apA0BHWYW0WTeJ 8gBCsw0bE8VjdN7xFsxXn+GhfVJ6mUudXu6ZFF5ku9FAoQzhCM4LeJYz8p9uT21QG4gb nmeA== X-Gm-Message-State: AD7BkJJR9yU7gj9TGHjF2qD3Xmjy0Rbvy6KLy5SsxYlt+PtRl9OjWD2mkSY0VCx4GmNE+w== X-Received: by 10.66.226.238 with SMTP id rv14mr29158319pac.41.1457304166321; Sun, 06 Mar 2016 14:42:46 -0800 (PST) Received: from ?IPv6:2601:642:c201:788c:c91c:441b:c2ef:eb51? ([2601:642:c201:788c:c91c:441b:c2ef:eb51]) by smtp.gmail.com with ESMTPSA id l14sm19690848pfi.23.2016.03.06.14.42.45 (version=TLS1_2 cipher=AES128-GCM-SHA256 bits=128/128); Sun, 06 Mar 2016 14:42:45 -0800 (PST) Message-ID: <1457304164.2002.210.camel@localhost.localdomain> From: Rex Buddenberg To: Alexandre Petrescu Date: Sun, 06 Mar 2016 14:42:44 -0800 In-Reply-To: <56DC7FDE.4060001@gmail.com> References: <113DBE6A-A3DF-4149-8B75-139A2E3780B7@cisco.com> <56DC7FDE.4060001@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Cc: its@ietf.org Subject: Re: [its] ITS Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2016 22:42:48 -0000 On Sun, 2016-03-06 at 20:07 +0100, Alexandre Petrescu wrote: > > An intuitive first thought is that the Internet is all that is fixed. > A > moving network in an automobile using its GPRS interface is typically > connecting to the Internet and there is no new work to do, because > it's > already there. Alex, you are sniffing at what I think are the right things here. Let me sort a bit; I think there are three topics that must be handled, although a good share of such handling is a layer 2 issue (meaning out of scope for IETF): What does 'radio' mean? 1. Topology -- shared medium. The wired internet is almost all point-to-point connectivity so the stitching together of >2 parties is a layer 3 routing problem. But in a radio-WAN, several parties (routers) may be attached to a single segment. (The problem is masked with wireless LANs, or wired LANs for that matter). Rather fundamental topology issue. 2. Economy -- Bandwidth constraint. In the wired internet, we're routinely provisioning at 10s of G. ... and can always add a second fiber pair. In radio, we're spectrum limited and the limits are about 4 orders of magnitude less. 3. with a shared media you need a means to share it -- a MAC. Terrestrial internet technologies (ADSL, DWDM, ...) lack MACs because they don't need them. But we sure need one with radio. (There are only two kinds of MACs out there -- contention and contention-free). 4. multicast. With point-to-point connectivity, which can be overprovisioned, the payoffs to multicast are not obvious. But with a capacity-constrained media, and a shared media at that, the payoffs to multicast are compelling. A thoughtful analysis of the differences between wired and radio media in the internet ought to yield some fruitful charter thinking. Above help? b From nobody Mon Mar 7 01:42:59 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5271B3D7A for ; Mon, 7 Mar 2016 01:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 m8syxipfIeF4 for ; Mon, 7 Mar 2016 01:42:56 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ABB51B3D79 for ; Mon, 7 Mar 2016 01:42:56 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u279gsa3023018 for ; Mon, 7 Mar 2016 10:42:54 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B073620862F for ; Mon, 7 Mar 2016 10:43:19 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A858E20862C for ; Mon, 7 Mar 2016 10:43:19 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u279gsAB014993 for ; Mon, 7 Mar 2016 10:42:54 +0100 To: its@ietf.org References: <1457120467.2002.173.camel@localhost.localdomain> From: Alexandre Petrescu Message-ID: <56DD4D1D.5010103@gmail.com> Date: Mon, 7 Mar 2016 10:42:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1457120467.2002.173.camel@localhost.localdomain> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] ITS Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 09:42:58 -0000 Le 04/03/2016 20:41, Rex Buddenberg a écrit : > Nabil, Carlos, > > > There's a sensitivity in here that, from a purely IETF experience, > you might not be aware of. > > In US, National Highway Traffic Safety Agency (part of Dept of > Transportation) is mandating a set of standards for vehicle-vehicle > communications. Thanks for this. I will add it to draft-petrescu-its-cacc-sdo. > The IEEE 1609 committee is trying to respond to this mandate by > writing a set of standards. The vehicle-to-vehicle protocol stack > voids the network and transport layers and, Right. > IMHO, cops out with a single-hop protocol stack (including a catalog > of content messages). The single-hop solution has, again IMHO, > several shortcomings with reach and discrimination. 1609 has a > dual-stack cartoon with IPv6 stack as the second stack (and not much > attention to it). Other than that, there's very little > internetworking in the discussion or draft standard. I agree. One would be careful qualifying the 1609 work as 1-hop. The 1609 perspective may not consider - currently - that 1-hop to be (exclusively) an IP 1-hop. Prototypes have however exposed a need for the 1-hop to be IP. As the number of in-vehicle specific applications grows relentlessly it becomes harder to add dedicated communication boxes for each. For this reason, some prototypes use 1609 messaging _over_ IP along 1 or 2 IP hops, along with other more classical TCP/IP messages such as web browsing. Additionally, security work in 1609 and elsewhere (ITU) consider the use of certificates. These 'vehicular' certificates are very friendly with being carried over IP. > My litmus test use case is an instrumented ambulance. You want > things like 'virtual siren' to alert other vehicles on the road. But > you also want to telemeter casualty data to the ER -- clearly an > extend-the-internet case. Putting these in separate standards > stovepipes is, again IMHO, a bad idea. I agree. The instrumented ambulance is an important user of these vehicular networks. Their requirements are very strong and with heterogeneous applications. If somebody from the public safety space is attending Buenos Aires, we have a slot for the public safety in the agenda. Alex > Alex is trying to head off some of this in the language he chose. I > might not have written it the same way, but this is at least part of > the reasoning. > > > > On Fri, 2016-03-04 at 16:52 +0000, Nabil Benamar wrote: >> >> CMP: Are these “IP protocols†or “IP-based protocolsâ€? >> >> >> ​These are IP protocols and IPv6 more precisely ! ​ >> > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From nobody Mon Mar 7 07:08:34 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9343F1B4279 for ; Mon, 7 Mar 2016 07:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 RhAKiItdgr4g for ; Mon, 7 Mar 2016 07:08:30 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7761B4270 for ; Mon, 7 Mar 2016 07:08:29 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u27F8QQe014020; Mon, 7 Mar 2016 16:08:26 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AD2BB20C07A; Mon, 7 Mar 2016 16:08:51 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9E9BE20BFFC; Mon, 7 Mar 2016 16:08:51 +0100 (CET) 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 u27F8P13021940; Mon, 7 Mar 2016 16:08:25 +0100 To: Nabil Benamar , Russ Housley References: <56C1D0AB.3020006@gmail.com> <8B07B35E-3FE8-4B1E-9017-7A2E34B320F3@vigilsec.com> From: Alexandre Petrescu Message-ID: <56DD9969.5080307@gmail.com> Date: Mon, 7 Mar 2016 16:08:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "its@ietf.org" Subject: Re: [its] Updated charter - please comment X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 15:08:33 -0000 Le 04/03/2016 17:33, Nabil Benamar a écrit : > Hi Alex, Russ and itsers, > > The charter looks good for me and it should be noted that a great amount > of research papers are focusing on the benefits of car to car > communication to solve some relevant issues. Do you have a list of such research papers? Alex > Many strategies are > proposed to proactively compute re-routing guidance to be pushed to > vehicles when signs of congestion are observed on their route. This is > beyond the safety issue as stated in the draft charter but it concerns a > better driving experience ! > > Other car manufacturers could be interested by the outcomes of this > wg, especially when we think about Autonomous driving. Indeed, one of > the main challenges of autonomous driving in urban areas is transition > through cross-roads and intersections. In addition to safety concerns, > current intersection management technologies such as stop signs and > trafic lights can introduce significant trafic delays even under light > trafic conditions. > > V2V and V2I can help avoiding deadlock situations > and eventual collisions as well ! > > Moreover, considering the importance of IPv6 deployment nowadays and all > the possibilities and new technologies rising from it, our previous > draft can be a good starting point and a work item for the WG: > https://datatracker.ietf.org/doc/draft-petrescu-ipv6-over-80211p/ > > > > > > Best regards > Nabil Benamar > ------------------- > نبيل بنعمرو > > http://nabilbenamar.ipv6-lab.net/ > > On Wed, Feb 17, 2016 at 6:36 PM, Russ Housley > wrote: > > Alex: > > Below are my comments on the proposed charter text. > > Russ > > > >> ----------------------------------------------------------------------- >> >> ITS (name to change) >> Charter >> February 15th, 2016 >> http://ietf.org/mailman/listinfo/its >> >> >> Intelligent Transportation Systems (its) >> ---------------------------------------- >> Current Status: WG forming >> >> Chairs: >> TBD >> >> Assigned Area Director: >> TBD >> >> Mailing list >> Address: its@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/its >> Archive: >> http://www.ietf.org/mail-archive/web/its/current/maillist.html >> >> Additional web page >> TBD >> >> Charter: >> >> Goal >> ---- >> The goal of this group is to standardize IP protocols for establishing >> direct and secure connectivity between moving networks. >> >> Moving Network to Moving Network Communications >> ----------------------------------------------- >> The group is concerned with all situations involving moving network to >> moving network communications. For example: vehicle-to-vehicle >> communications, nomadic user wearing a PAN and communicating to a >> homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a >> train, or train-to-intersection signalling. >> >> Example from the automobile communications space >> ------------------------------------------------ >> Automobiles and vehicles of all types are increasingly connected to >> the Internet. Entertainment apps enhancing comfort, reliable data >> exchanges for road safety, and automated driving, are commonly seen as > > Editorial: s/automated driving, are/automated driving are/ > >> winning sale arguments for automobiles to hit the roads from now to >> year 2020. Emergency apps for new instrumented ambulances carry many >> benefits both to the users and to society in general. > > I think that the "winning sales arguments" is not needed here. > Instead, I think it > would be valuable to say that these features are coming, and that > the safety > features are expected to become required. > >> >> Why IP? >> ------- >> Whereas the Vehicle-to-Internet technologies are considered completed >> and deployed in automobiles currently on the roads (e.g. car tethering >> through driver's cellular smartphone, live traffic data displayed on >> the dashboard, - use of NAT/DHCP and potentially Mobile IP), the >> Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are >> still in an infancy stage: primitive link-specific data exchanges are >> limited to a non-harmonized set of applications, such as ETSI's >> CAM/DENM presence signalling; worse, some link-specific messages >> exhibit behaviour assimilated to IP behaviour but the systems are >> incompatible with the Internet without involving specific gatewaying. >> The industry needs to employ IP data exchanges between vehicles, and >> between vehicles and the immediate infrastructure, rather than >> link-specific exchanges, in order to benefit from advantages such as >> (1) short delays, (2) fast forwarding through short paths of dumb >> routers (2) ease of reusing of a huge number of a desktop Internet >> applications in a vehicular environment (extend the Internet to mobile >> platforms). > > I think this paragraph take too long to get to the main point, which is > why IP is a goog thing in this environment. I suggest: > > Today, there are several deployed Vehicle-to-Internet technologies, > including car tethering through driver's cellular smartphone. However, > Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are > still > being developed. To avoid link-specific data exchanges, and enable > independent application sets to share the same links, IP data exchanges > are needed. Enabling IP communication between vehicles (V2V), and > between vehicles and the immediate infrastructure (V2I), will provide > (1) short delays, (2) fast forwarding through short paths of routers, > (3) ease of reuse of existing Internet applications in a vehicular > environment. > >> >> Moving network to moving network communications involve link layers > > Add "nearby" here. I think it is important to the scope. > >> such as: 802.11 OCB, 802.15.4 with 6lowpan, 802.11ac, VLC (Visible >> Light Communications), IrDA, LTE-D. Only the IP protocols are capable > > s/802.11 OCB/802.11p OCB (Outside the Context of a BSS)/ > >> of running on each of these links and establish IP paths across them >> in an interoperable manner. >> >> Scenarios? >> ---------- >> There are a few scenarios exhibiting the need to communicate from one >> moving network to another nearby moving network. >> >> In the automobile space, the Cooperative Adaptive Cruise Control and >> Platooning features consider that vehicles close to each other >> exchange data describing their kinematic status. At the cross-roads, >> the moving network inside a vehicle exchanges data with the moving >> network in the red-light pole. >> >> Several public safety scenarios involve moving networks. Distinct >> organizations deploy different moving networks (in-vehicle, on-person) >> at an incident scene. These networks need to interoperate in order to >> more effectively understand and deal with the incident scene. >> >> In connected rail scenarios the moving network deployed in trains >> communicate with other moving networks at the cross-points. >> >> What kind of solutions? >> ----------------------- >> The current technical solutions considered to achieve moving network >> to moving network communications are of two kinds: IP routing > > Add "nearby" here. I think it is important to the scope. > >> protocols for n-hop path management and 1-hop link-scoped IP protocol >> enhancements. The 1-hop link-scoped protocols include the protocols >> for route establishment involving ICMP Router Advertisements. The >> n-hop path management protocols include n-hop path establishment >> protocols (e.g. Babel, OSPF) and n-hop path search protocols (most >> notably AODV and derivates). > > My understanding from the phone call was that we were going to focus > on the 1-hop > protocols in this proposed working group, but leverage work from > other groups for the > n-hop situation. > > I think we need to say something here about the duration of some of > the communications. > a vehicle traveling at 80 Km/h is not going to have communications > with a roadside > device for very long. > >> >> What kind of requirements? >> -------------------------- >> The requirements for mechanisms for moving network to moving network > > Add "nearby" here. I think it is important to the scope. > >> communications are focusing on low delays of the data paths, reduced >> number of messages for path establishment, application friendly, >> resilience to attacks, compatibility with DHCP and Mobile IP. >> >> In addition, some moving network to moving network applications > > Add "nearby" here. I think it is important to the scope. > >> involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the >> 1-hop IP moving network to moving netowrk mechanisms will need to >> gracefully support IP multicast. >> >> Due to the inherent characteristics of safety-related communications, >> all new moving network to moving network mechanisms must afford >> authenticity and confidentiality where necessary. Dynamically >> establishing ephemeral communication paths between automobiles in >> public areas must offer privacy safeguards for the end users >> (passengers). >> >> Establishing 1-hop IP V2V paths must not break the existing on-board >> protocols and applications which communicate with the Internet, >> possibly via multiple radios. >> >> In a moving network deployed in an automobile, typically one exit >> point connects the moving network to other moving networks. However, >> in a more general manner (and to support reliability) any new >> mechanism of moving network to moving network communications should >> support multi-homing: one router to use multiple interfaces towards >> outside the moving network, or multiple routers. >> >> Current version of Internet protocols >> ------------------------------------- >> The version of the IP protocol is IPv6 (witness 10% IPv6 penetration >> as of early 2016, mobile operators evolving to IPv6-only, government >> IPv6 push, IPv4 exhaust at RIRs); this acommodates the current >> generation of Internet protocols. For backwards compatibility, IPv4 >> may be considered as well, but not exclusively. Link-local IPv6 >> addresses will be used. > > This it too long. Just say that the groups will only work on IPv6 > solutions. > >> >> What SDOs may need this work? >> ----------------------------- >> The requirements and standards for moving network to moving network >> communications, often involving IPv6, and novel V2V and V2Infra >> concepts, are developed mainly at ISO TC204 "Intelligent Transport >> Systems", 3GPP, ETSI, NHTSA and IEEE. For Vehicle-to-Internet >> communications, 3GPP LTE and other cellular technologies represent the >> long-range connectivity method; for Vehicle-to-Vehicle communications, >> LTE Direct is currently specified, as well as OCB mode of IEEE 802.11. >> Several use-cases exhibit a need for IPv6 data exchanges between >> vehicles: ETSI's Cooperative Adaptive Cruise Control and Platooning. >> The IEEE developed a popular link for short-range communications - >> IEEE 802.11p "WAVE". The NHTSA wrote a set of requirements for V2V >> communications. >> >> Work Items >> ---------- >> - use-cases for moving network to moving network communications >> - Problem Statement for moving network to moving network >> communications >> - Security and Privacy Requirements for moving network to >> moving network communications >> - Problem Statement for moving network to infrastructure network >> communications, including DNS >> - Potentially new protocol, or protocol extensions for establishing IP >> paths for 1-hop moving network to moving network communications. >> With MIB and security. >> - IPv6-over foo, where foo is pertinent for moving network to moving >> network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) >> >> Timeline >> -------- >> - >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Mon Mar 7 08:06:18 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F551B4376 for ; Mon, 7 Mar 2016 08:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 vljmxIIe-811 for ; Mon, 7 Mar 2016 08:06:12 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::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 95E5F1B437A for ; Mon, 7 Mar 2016 08:06:12 -0800 (PST) Received: by mail-pa0-x236.google.com with SMTP id fy10so80600213pac.1 for ; Mon, 07 Mar 2016 08:06:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=QOTZdvdfRVhFX8fkm3XjZFCZN/7Q3n0XGff/4mZhyCU=; b=t7V1bjK1SJhub6FpMwpNAb+7VAJzDD2LgJEk2dx53DyjxG6rN15XCu60b1AmftqRgh gEYsqOPpcJ1t1YZmhaBWphomtspDoKSMA/mFxKPUreIu2LycN5VCQKrju4NH/9YK2hit +M7OqSYaR/KePVLzsXrBc9crTtQVMnUlyZJI64A0wKyiqT7O3Ig7c1Vg8Ho66V4WjUEk IhvLJVoQhTVFTugIyVA/vZcmQUTHTml6cqQU5BjBT5pTjeU4XJcPt9IGwoR5iUHUaaq8 W8N+SZa9yAgwOMDgdO31kQvKgXnUzUf1h2CwhHpGC95Nj2SxOGQmlNgQQpfvpmt/W6OH 8iXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=QOTZdvdfRVhFX8fkm3XjZFCZN/7Q3n0XGff/4mZhyCU=; b=ICS0V4aIKSFGsyO0q0rE5v3hM30kM9Lw1gq2AW7s8aOx9jC4bzLcCMHKWu7xz6YQsE efRxUuunvIVdx7l3tZrgNfR5rmHc8+e+3Lh67cKYrz1poWSPJaY3ljCT3rFIK1PyCzV+ d0ccqQxLxn5EePQhvJXNb9N5onNU9Apvd6EZMU/SOwu3g758vhvD8xp/dXbq5BArOWtY xHsYVHYiymz3LDxkqQv2+7Va98ut77E7WHkFuXF/0IMQbqQ5OsrcLYDRPDtGlkkuqkR6 /LCEJn2X7UAr9N6WQ73dm74FeuoTmjRXmFhfgHhNEMnTgShMpaQYVne927kvKOG6peR7 uKdw== X-Gm-Message-State: AD7BkJLbOojMyOp1jg/5DEEzcJO5eUjbjiKwDBUo+uPndflmZuDD6ytFkhI8To9uFNHtCQ== X-Received: by 10.66.65.109 with SMTP id w13mr34234494pas.142.1457366772122; Mon, 07 Mar 2016 08:06:12 -0800 (PST) Received: from [10.0.1.4] ([121.152.87.242]) by smtp.gmail.com with ESMTPSA id cq4sm25136165pad.28.2016.03.07.08.06.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 07 Mar 2016 08:06:11 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_C5C4E6B2-8545-4A82-8B3A-AF4BD4259F71" From: Jong-Hyouk Lee In-Reply-To: <8B07B35E-3FE8-4B1E-9017-7A2E34B320F3@vigilsec.com> Date: Tue, 8 Mar 2016 01:06:06 +0900 Message-Id: References: <56C1D0AB.3020006@gmail.com> <8B07B35E-3FE8-4B1E-9017-7A2E34B320F3@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Alexandre Petrescu , "its@ietf.org" Subject: Re: [its] Updated charter - please comment X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 16:06:17 -0000 --Apple-Mail=_C5C4E6B2-8545-4A82-8B3A-AF4BD4259F71 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, Short comments below. J. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Feb 18, 2016, at 3:36 AM, Russ Housley = wrote: >=20 > Alex: >=20 > Below are my comments on the proposed charter text. >=20 > Russ >=20 >=20 >=20 >> = ----------------------------------------------------------------------- >>=20 >> ITS (name to change) >> Charter >> February 15th, 2016 >> http://ietf.org/mailman/listinfo/its = >>=20 >>=20 >> Intelligent Transportation Systems (its) >> ---------------------------------------- >> Current Status: WG forming >>=20 >> Chairs: >> TBD >>=20 >> Assigned Area Director: >> TBD >>=20 >> Mailing list >> Address: its@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/its = >> Archive: >> http://www.ietf.org/mail-archive/web/its/current/maillist.html = >>=20 >> Additional web page >> TBD >>=20 >> Charter: >>=20 >> Goal >> ---- >> The goal of this group is to standardize IP protocols for = establishing >> direct and secure connectivity between moving networks. >>=20 >> Moving Network to Moving Network Communications >> ----------------------------------------------- >> The group is concerned with all situations involving moving network = to >> moving network communications. For example: vehicle-to-vehicle >> communications, nomadic user wearing a PAN and communicating to a >> homenet, vehicle-to-infrastructure communications, wagon-to-wagon in = a >> train, or train-to-intersection signalling. >>=20 >> Example from the automobile communications space >> ------------------------------------------------ >> Automobiles and vehicles of all types are increasingly connected to >> the Internet. Entertainment apps enhancing comfort, reliable data >> exchanges for road safety, and automated driving, are commonly seen = as >=20 > Editorial: s/automated driving, are/automated driving are/ >=20 >> winning sale arguments for automobiles to hit the roads from now to >> year 2020. Emergency apps for new instrumented ambulances carry many >> benefits both to the users and to society in general. >=20 > I think that the "winning sales arguments" is not needed here. = Instead, I think it > would be valuable to say that these features are coming, and that the = safety > features are expected to become required. Using IPv6 will not be a better option than the only link-layer use for = the safety features. Due to this reason, the infotainment feature (e.g., = entertainment applications) was emphasised. >=20 >>=20 >> Why IP? >> ------- >> Whereas the Vehicle-to-Internet technologies are considered completed >> and deployed in automobiles currently on the roads (e.g. car = tethering >> through driver's cellular smartphone, live traffic data displayed on >> the dashboard, - use of NAT/DHCP and potentially Mobile IP), the >> Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are >> still in an infancy stage: primitive link-specific data exchanges are >> limited to a non-harmonized set of applications, such as ETSI's >> CAM/DENM presence signalling; worse, some link-specific messages >> exhibit behaviour assimilated to IP behaviour but the systems are >> incompatible with the Internet without involving specific gatewaying. >> The industry needs to employ IP data exchanges between vehicles, and >> between vehicles and the immediate infrastructure, rather than >> link-specific exchanges, in order to benefit from advantages such as >> (1) short delays, (2) fast forwarding through short paths of dumb >> routers (2) ease of reusing of a huge number of a desktop Internet >> applications in a vehicular environment (extend the Internet to = mobile >> platforms). >=20 > I think this paragraph take too long to get to the main point, which = is > why IP is a goog thing in this environment. I suggest: >=20 > Today, there are several deployed Vehicle-to-Internet technologies, > including car tethering through driver's cellular smartphone. = However, > Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are = still > being developed. To avoid link-specific data exchanges, and enable > independent application sets to share the same links, IP data = exchanges > are needed. Enabling IP communication between vehicles (V2V), and > between vehicles and the immediate infrastructure (V2I), will provide > (1) short delays, (2) fast forwarding through short paths of routers, > (3) ease of reuse of existing Internet applications in a vehicular > environment. Thanks, it is much better.=20 >=20 >>=20 >> Moving network to moving network communications involve link layers >=20 > Add "nearby" here. I think it is important to the scope. >=20 >> such as: 802.11 OCB, 802.15.4 with 6lowpan, 802.11ac, VLC (Visible >> Light Communications), IrDA, LTE-D. Only the IP protocols are = capable >=20 > s/802.11 OCB/802.11p OCB (Outside the Context of a BSS)/ >=20 >> of running on each of these links and establish IP paths across them >> in an interoperable manner. >>=20 >> Scenarios? >> ---------- >> There are a few scenarios exhibiting the need to communicate from one >> moving network to another nearby moving network. >>=20 >> In the automobile space, the Cooperative Adaptive Cruise Control and >> Platooning features consider that vehicles close to each other >> exchange data describing their kinematic status. At the cross-roads, >> the moving network inside a vehicle exchanges data with the moving >> network in the red-light pole. >>=20 >> Several public safety scenarios involve moving networks. Distinct >> organizations deploy different moving networks (in-vehicle, = on-person) >> at an incident scene. These networks need to interoperate in order = to >> more effectively understand and deal with the incident scene. >>=20 >> In connected rail scenarios the moving network deployed in trains >> communicate with other moving networks at the cross-points. >>=20 >> What kind of solutions? >> ----------------------- >> The current technical solutions considered to achieve moving network >> to moving network communications are of two kinds: IP routing >=20 > Add "nearby" here. I think it is important to the scope. >=20 >> protocols for n-hop path management and 1-hop link-scoped IP protocol >> enhancements. The 1-hop link-scoped protocols include the protocols >> for route establishment involving ICMP Router Advertisements. The >> n-hop path management protocols include n-hop path establishment >> protocols (e.g. Babel, OSPF) and n-hop path search protocols (most >> notably AODV and derivates). >=20 > My understanding from the phone call was that we were going to focus = on the 1-hop > protocols in this proposed working group, but leverage work from other = groups for the > n-hop situation. >=20 > I think we need to say something here about the duration of some of = the communications. > a vehicle traveling at 80 Km/h is not going to have communications = with a roadside > device for very long. Mentioning 80 Km/h and a very communication chance=E2=80=A6agree. But, = we should think that the long range communications like LTE (license = radio) and LP-WAN (unlicensed radio) are available. N-hop protocol = support at IP can be also thought. Anyway, as you pointed, we need to = put something here. =20 >=20 >>=20 >> What kind of requirements? >> -------------------------- >> The requirements for mechanisms for moving network to moving network >=20 > Add "nearby" here. I think it is important to the scope. >=20 >> communications are focusing on low delays of the data paths, reduced >> number of messages for path establishment, application friendly, >> resilience to attacks, compatibility with DHCP and Mobile IP. >>=20 >> In addition, some moving network to moving network applications >=20 > Add "nearby" here. I think it is important to the scope. >=20 >> involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the >> 1-hop IP moving network to moving netowrk mechanisms will need to >> gracefully support IP multicast. >>=20 >> Due to the inherent characteristics of safety-related communications, >> all new moving network to moving network mechanisms must afford >> authenticity and confidentiality where necessary. Dynamically >> establishing ephemeral communication paths between automobiles in >> public areas must offer privacy safeguards for the end users >> (passengers). >>=20 >> Establishing 1-hop IP V2V paths must not break the existing on-board >> protocols and applications which communicate with the Internet, >> possibly via multiple radios. >>=20 >> In a moving network deployed in an automobile, typically one exit >> point connects the moving network to other moving networks. However, >> in a more general manner (and to support reliability) any new >> mechanism of moving network to moving network communications should >> support multi-homing: one router to use multiple interfaces towards >> outside the moving network, or multiple routers. >>=20 >> Current version of Internet protocols >> ------------------------------------- >> The version of the IP protocol is IPv6 (witness 10% IPv6 penetration >> as of early 2016, mobile operators evolving to IPv6-only, government >> IPv6 push, IPv4 exhaust at RIRs); this acommodates the current >> generation of Internet protocols. For backwards compatibility, IPv4 >> may be considered as well, but not exclusively. Link-local IPv6 >> addresses will be used. >=20 > This it too long. Just say that the groups will only work on IPv6 = solutions. >=20 >>=20 >> What SDOs may need this work? >> ----------------------------- >> The requirements and standards for moving network to moving network >> communications, often involving IPv6, and novel V2V and V2Infra >> concepts, are developed mainly at ISO TC204 "Intelligent Transport >> Systems", 3GPP, ETSI, NHTSA and IEEE. For Vehicle-to-Internet >> communications, 3GPP LTE and other cellular technologies represent = the >> long-range connectivity method; for Vehicle-to-Vehicle = communications, >> LTE Direct is currently specified, as well as OCB mode of IEEE = 802.11. >> Several use-cases exhibit a need for IPv6 data exchanges between >> vehicles: ETSI's Cooperative Adaptive Cruise Control and Platooning. >> The IEEE developed a popular link for short-range communications - >> IEEE 802.11p "WAVE". The NHTSA wrote a set of requirements for V2V >> communications. >>=20 >> Work Items >> ---------- >> - use-cases for moving network to moving network communications >> - Problem Statement for moving network to moving network = communications >> - Security and Privacy Requirements for moving network to >> moving network communications >> - Problem Statement for moving network to infrastructure network >> communications, including DNS >> - Potentially new protocol, or protocol extensions for establishing = IP >> paths for 1-hop moving network to moving network communications. >> With MIB and security. >> - IPv6-over foo, where foo is pertinent for moving network to moving >> network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) >>=20 >> Timeline >> -------- >> - >>=20 >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its = >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its = --Apple-Mail=_C5C4E6B2-8545-4A82-8B3A-AF4BD4259F71 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

Short comments below.

J.
--
Jong-Hyouk Lee, living somewhere between /dev/null = and /dev/random
Protocol Engineering Lab., = Sangmyung University

#email: jonghyouk@gmail.com
#webpage: https://sites.google.com/site/hurryon

On Feb 18, 2016, at 3:36 AM, Russ Housley <housley@vigilsec.com> wrote:

Alex:

Below are my comments on the proposed charter text.

Russ



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

        =              ITS (name to = change)
        =            Charter
            =  February 15th, 2016
    =      http://ietf.org/mailman/list= info/its


Intelligent = Transportation Systems (its)
----------------------------------------
Current = Status: WG forming

Chairs:
   TBD

Assigned Area = Director:
   TBD

Mailing list
   Address: its@ietf.org
   = To Subscribe: https://www.ietf.org/ma= ilman/listinfo/its
   Archive:
   ht= tp://www.ietf.org/mail-archive/web/its/current/maillist.html

Additional web page
   = TBD

Charter:

Goal
----
The goal of this group = is to standardize IP protocols for establishing
direct and = secure connectivity between moving networks.

Moving Network to Moving Network Communications
-----------------------------------------------
The group is concerned with all situations involving moving = network to
moving network communications.  For = example: vehicle-to-vehicle
communications, nomadic user = wearing a PAN and communicating to a
homenet, = vehicle-to-infrastructure communications, wagon-to-wagon in a
train, or train-to-intersection signalling.

Example from the automobile communications space
------------------------------------------------
Automobiles and vehicles of all types are increasingly = connected to
the Internet.  Entertainment apps = enhancing comfort, reliable data
exchanges for road = safety, and automated driving, are commonly seen as

Editorial:  s/automated driving, are/automated = driving are/

winning sale arguments for automobiles to hit the roads from = now to
year 2020.  Emergency apps for new = instrumented ambulances carry many
benefits both to the = users and to society in general.

I think that the "winning sales arguments" is not = needed here.  Instead, I think it
would be valuable to say that these features are coming, and = that the safety
features = are expected to become required.

Using IPv6 will not be a better option than the = only link-layer use for the safety features. Due to this reason, the = infotainment feature (e.g., entertainment applications) = was emphasised.



Why IP?
-------
Whereas the = Vehicle-to-Internet technologies are considered completed
and deployed in automobiles currently on the roads (e.g. car = tethering
through driver's cellular smartphone, live = traffic data displayed on
the dashboard, - use of NAT/DHCP = and potentially Mobile IP), the
Vehicle-to-Vehicle and = Vehicle-to-Infrastructure communications are
still in an = infancy stage: primitive link-specific data exchanges are
limited to a non-harmonized set of applications, such as = ETSI's
CAM/DENM presence signalling; worse, some = link-specific messages
exhibit behaviour assimilated to IP = behaviour but the systems are
incompatible with the = Internet without involving specific gatewaying.
The = industry needs to employ IP data exchanges between vehicles, and
between vehicles and the immediate infrastructure, rather = than
link-specific exchanges, in order to benefit from = advantages such as
(1) short delays, (2) fast forwarding = through short paths of dumb
routers (2) ease of reusing of = a huge number of a desktop Internet
applications in a = vehicular environment (extend the Internet to mobile
platforms).

I think this paragraph = take too long to get to the main point, which is
why = IP is a goog thing in this environment.  I suggest:

Today, there are several deployed Vehicle-to-Internet = technologies,
including car tethering through = driver's cellular smartphone.  However,
Vehicle-to-Vehicle and Vehicle-to-Infrastructure = communications are still
being developed.  To = avoid link-specific data exchanges, and enable
independent application sets to share the same links, IP data = exchanges
are needed.  Enabling IP = communication between vehicles (V2V), and
between = vehicles and the immediate infrastructure (V2I), will provide
(1) short delays, (2) fast forwarding through short = paths of routers,
(3) ease of reuse of = existing Internet applications in a vehicular
environment.
Thanks, it is much better. 



Moving = network to moving network communications involve link layers

Add "nearby" here.  I think it is = important to the scope.

such as: 802.11 OCB, 802.15.4 with = 6lowpan, 802.11ac, VLC (Visible
Light Communications), = IrDA, LTE-D.  Only the IP protocols are capable

s/802.11 OCB/802.11p OCB (Outside the Context = of a BSS)/

of running on each of = these links and establish IP paths across them
in an = interoperable manner.

Scenarios?
----------
There are a few scenarios exhibiting = the need to communicate from one
moving network to another = nearby moving network.

In the automobile = space, the Cooperative Adaptive Cruise Control and
Platooning features consider that vehicles close to each = other
exchange data describing their kinematic = status.  At the cross-roads,
the moving network = inside a vehicle exchanges data with the moving
network in = the red-light pole.

Several public safety = scenarios involve moving networks.  Distinct
organizations deploy different moving networks (in-vehicle, = on-person)
at an incident scene.  These networks need = to interoperate in order to
more effectively understand = and deal with the incident scene.

In = connected rail scenarios the moving network deployed in trains
communicate with other moving networks at the = cross-points.

What kind of solutions?
-----------------------
The current technical = solutions considered to achieve moving network
to moving = network communications are of two kinds: IP routing

Add "nearby" here.  I think it is important to the = scope.

protocols for n-hop path management and 1-hop link-scoped IP = protocol
enhancements.  The 1-hop link-scoped = protocols include the protocols
for route establishment = involving ICMP Router Advertisements.  The
n-hop path = management protocols include n-hop path establishment
protocols (e.g. Babel, OSPF) and n-hop path search protocols = (most
notably AODV and derivates).

My understanding from the phone call was that we were = going to focus on the 1-hop
protocols in this proposed working group, but leverage work = from other groups for the
n-hop= situation.

I think = we need to say something here about the duration of some of the = communications.
a vehicle = traveling at 80 Km/h is not going to have communications with a = roadside
device = for very long.

Mentioning 80 Km/h and a very communication = chance=E2=80=A6agree. But, we should think that the long range = communications like LTE (license radio) and LP-WAN (unlicensed radio) = are available. N-hop protocol support at IP can be also thought. Anyway, = as you pointed, we need to put something here.  



What = kind of requirements?
--------------------------
The requirements for mechanisms for moving network to moving = network

Add "nearby" here.  I think it is important to the = scope.

communications are focusing on low delays of the data paths, = reduced
number of messages for path establishment, = application friendly,
resilience to attacks, compatibility = with DHCP and Mobile IP.

In addition, some = moving network to moving network applications

Add "nearby" here.  I think it is important to the = scope.

involve IP multicast mechanisms (e.g. virtual siren); thus = C-ACC the
1-hop IP moving network to moving netowrk = mechanisms will need to
gracefully support IP = multicast.

Due to the inherent = characteristics of safety-related communications,
all new = moving network to moving network mechanisms must afford
authenticity and confidentiality where necessary.  = Dynamically
establishing ephemeral communication paths = between automobiles in
public areas must offer privacy = safeguards for the end users
(passengers).
Establishing 1-hop IP V2V paths must not break the existing = on-board
protocols and applications which communicate with = the Internet,
possibly via multiple radios.

In a moving network deployed in an automobile, = typically one exit
point connects the moving network to = other moving networks.  However,
in a more general = manner (and to support reliability) any new
mechanism of = moving network to moving network communications should
support multi-homing: one router to use multiple interfaces = towards
outside the moving network, or multiple = routers.

Current version of Internet = protocols
-------------------------------------
The version of the IP protocol is IPv6 (witness 10% IPv6 = penetration
as of early 2016, mobile operators evolving to = IPv6-only, government
IPv6 push, IPv4 exhaust at RIRs); = this acommodates the current
generation of Internet = protocols.  For backwards compatibility, IPv4
may be = considered as well, but not exclusively.  Link-local IPv6
addresses will be used.

This it too long.  Just say that the groups will = only work on IPv6 solutions.


What SDOs may need this work?
-----------------------------
The requirements = and standards for moving network to moving network
communications, often involving IPv6, and novel V2V and = V2Infra
concepts, are developed mainly at ISO TC204 = "Intelligent Transport
Systems", 3GPP, ETSI, NHTSA and = IEEE.  For Vehicle-to-Internet
communications, 3GPP = LTE and other cellular technologies represent the
long-range= connectivity method; for Vehicle-to-Vehicle communications,
LTE Direct is currently specified, as well as OCB mode of = IEEE 802.11.
Several use-cases exhibit a need for IPv6 = data exchanges between
vehicles: ETSI's Cooperative = Adaptive Cruise Control and Platooning.
The IEEE developed = a popular link for short-range communications -
IEEE = 802.11p "WAVE".  The NHTSA wrote a set of requirements for V2V
communications.

Work Items
----------
- use-cases for moving network to = moving network communications
- Problem Statement for = moving network to moving network communications
- Security = and Privacy Requirements for moving network to
  = moving network communications
- Problem Statement for = moving network to infrastructure network
  = communications, including DNS
- Potentially new protocol, = or protocol extensions for establishing IP
  paths = for 1-hop moving network to moving network communications.
  With MIB and security.
- IPv6-over foo, = where foo is pertinent for moving network to moving
  = network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad)

Timeline
--------
-

_______________________________________________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

= --Apple-Mail=_C5C4E6B2-8545-4A82-8B3A-AF4BD4259F71-- From nobody Mon Mar 7 08:14:38 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9FA1B4397 for ; Mon, 7 Mar 2016 08:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 RLcR3pFxxTAw for ; Mon, 7 Mar 2016 08:14:29 -0800 (PST) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 8EAEF1B4396 for ; Mon, 7 Mar 2016 08:14:29 -0800 (PST) Received: by mail-pf0-x230.google.com with SMTP id x188so58376849pfb.2 for ; Mon, 07 Mar 2016 08:14:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=xN5xe7u9k7rHstcHAhz5wKvEY/5sHkLrVJ0A2bhHnsw=; b=WkH/e8ap/0v3WTv8YSPSV8Jhx3E935AU9rd+c9CSAiaiDSyKrjuV2gOukw/KkIB64d hl1+rLZ6MGemcK5YaNxuGS0fWqTuHY0Bb7i+Hr4kjdQdIiTozFJ88fb6E6myNL5NgVzX 2a2KO4BXuOT0ENJ+cf7/pEeoS/DA4Ebb6xDFwnLQQZ+A9AVZJn7/4Gs16k8FRpDN1A6k Z4RhuPzbmcCGuVmVzPkhLuBq85gyuGNW2BQ4dpO0bbgMMKb0CIkTqj/NVegtnxzwvcdF 9ea7Lq0vYFYfqmKwrqfCfRSzVpElx9tIWOx9GsJ2eWsl2o9yEXyFpuPWYqbTbGoNqq0D gh/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=xN5xe7u9k7rHstcHAhz5wKvEY/5sHkLrVJ0A2bhHnsw=; b=FZsnBeJAvNwDVQcWajSFYr1PTIG7HiPtoc5kqd201yyiv3B0+yjjPN1S8Vt5R3CpLs DDX5ndWxMT8QzvZOZoFPOsoWPCPMP+v4tvP5lEgYEDXMG8DdUshTP7rfNLaRBZwu2n1c EaSMoHTagchrz6O7MI7cWnOEmM+vhPHUnEzx0qaHOEQ3Dz26DYdsc3bTxRx91WkfVL6m 3eiQkLUcoyEmrvSCiazJxTKoQkPoDq/g7x/U2/E1kLxigNBIXC/TBg9iUNXPVdmN1VEb +NQmVGCH/Q3WZpF5QbtLD5m/c5iDqJ6TocJLfXOmUT+jPA3GN56trwFkWpXLPO3Ldm2T cN9Q== X-Gm-Message-State: AD7BkJJfNij0qBnPsTszxiMLj8JPNH63VXvB/v3PrEjbr0lG6/OEej/T/rFOma89cJC4og== X-Received: by 10.98.86.146 with SMTP id h18mr8257570pfj.9.1457367269077; Mon, 07 Mar 2016 08:14:29 -0800 (PST) Received: from [10.0.1.4] ([121.152.87.242]) by smtp.gmail.com with ESMTPSA id o2sm25062234pfj.89.2016.03.07.08.14.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 07 Mar 2016 08:14:28 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_F856F710-8EFD-4D28-A74D-D388DAAD6DF5" From: Jong-Hyouk Lee In-Reply-To: <56C603CD.6010809@gmail.com> Date: Tue, 8 Mar 2016 01:14:23 +0900 Message-Id: <279F71D8-5DCD-4EC2-B093-2E0A98855842@gmail.com> References: <56C1D0AB.3020006@gmail.com> <8B07B35E-3FE8-4B1E-9017-7A2E34B320F3@vigilsec.com> <56C603CD.6010809@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Thierry Ernst , its@ietf.org, Russ Housley , "Dr. Hans-Joachim Fischer" , knut.evensen@q-free.com, dickroy@alum.mit.edu Subject: Re: [its] Updated charter - please comment X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 16:14:36 -0000 --Apple-Mail=_F856F710-8EFD-4D28-A74D-D388DAAD6DF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Alex, Some comments are below. J. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Feb 19, 2016, at 2:47 AM, Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 17/02/2016 23:15, Richard Roy a =E9crit : >> My comments are inline below ... >>=20 >> RR >>=20 >> = ------------------------------------------------------------------------ >>=20 >>=20 >>=20 > *From:*Russ Housley [mailto:housley@vigilsec.com = ] *Sent:* Wednesday, >> February 17, 2016 10:36 AM *To:* Alexandre Petrescu *Cc:* >> its@ietf.org *Subject:* Re: [its] Updated = charter - please comment >>=20 >> Alex: >>=20 >> Below are my comments on the proposed charter text. >>=20 >> Russ >>=20 >>=20 >>=20 >> = ----------------------------------------------------------------------- >>=20 >>=20 >>=20 > ITS (name to change) Charter February 15th, 2016 >> http://ietf.org/mailman/listinfo/its >>=20 >>=20 >> Intelligent Transportation Systems (its) >> ---------------------------------------- Current Status: WG forming >>=20 >> Chairs: TBD >>=20 >> Assigned Area Director: TBD >>=20 >> Mailing list Address: its@ietf.org = > To >> Subscribe: https://www.ietf.org/mailman/listinfo/its = Archive: >> http://www.ietf.org/mail-archive/web/its/current/maillist.html = >>=20 >> Additional web page TBD >>=20 >> Charter: >>=20 >> Goal ---- The goal of this group is to standardize IP protocols for >> establishing direct and secure connectivity between moving networks. >>=20 >> */[RR>] Hard to believe that IP protocols need standardizing. Isn't >> the real issue one of an appropriate "profile" for using already >> existing RFCs to implement IPv6 networking "between moving >> subnets"?/* >=20 > Well profiles are for Bluetooth if you wish (which is below IP, or = above > IP) but I can say "adapt" or "improve" IP protocols. >=20 > BEcause I havent much seen the word "profile" in RFCs for the IP = layer. >=20 >> Moving Network to Moving Network Communications >> ----------------------------------------------- The group is >> concerned with all situations involving moving network to moving >> network communications. For example: vehicle-to-vehicle >> communications, nomadic user wearing a PAN and communicating to a >> homenet, vehicle-to-infrastructure communications, wagon-to-wagon in >> a train, or train-to-intersection signalling. >>=20 >> Example from the automobile communications space >> ------------------------------------------------ Automobiles and >> vehicles of all types are increasingly connected to the Internet. >> Entertainment apps enhancing comfort, reliable data exchanges for >> road safety, and automated driving, are commonly seen as >>=20 >> Editorial: s/automated driving, are/automated driving are/ >>=20 >>=20 >>=20 >> winning sale arguments for automobiles to hit the roads from now to >> year 2020. Emergency apps for new instrumented ambulances carry many >> benefits both to the users and to society in general. >>=20 >> I think that the "winning sales arguments" is not needed here. >> Instead, I think it >>=20 >> would be valuable to say that these features are coming, and that >> the safety >>=20 >> features are expected to become required. >>=20 >> */[RR>] Many of the apps to which you allude do not require IPv6 >> networking. If you feel the need to provide use cases, make sure >> they require IPv6 networking in a mobile context./* >=20 > I will try to do that. >=20 > I would like you - if possible - to suggest other use case which > requires IPv6 networking in a mobile context? Thanks. >=20 > Let me explain the reasoning in the paragraph above by listing a few = key > items for IPv6 networking in V2V and V2I, pick one: >=20 > I experienced the need for IP between cells of vehicles moving = together. > The need was there urgent: the programmer in the back car had > absolutely to flush the data in the middle car and the LTE connection > was down. If no flush then risk of accident. The computer that = flushes > is windows with TCP IP on WiFi. The computer to be flushed is a linux > variant on a CAN network. The only way to have that flush work is to > network the two computers IP networked together. >=20 > There is no standard in vehicular communications which requires IPv4. > If ever IP is mentioned it is IPv6. >=20 > The example C-ACC use case is typical illustration of a direct > vehicle-to-vehicle communication of data (as opposed to entertainment > apps which are Vehicle-to-Internet, and 'radar' communication which is > bouncing signals not data). >=20 > A C-ACC standard currently under definition by ETSI is using CAM and > DENM messages. The CAM and DENM messages are understood by some at = the > link-layer and by others at the application-layer. If they are > application-layer, then there is a need of a networking layer. The = only > networking layer is IPv6. >=20 > Vehicles connected to the Internet can only use IPv6 as networking > layer. If we want V2V and V2I to make a V2V2I the only possibility > again is to use IPv6 as the networking layer. >=20 > If we dont use IPv6 as the networking layer in V2V and V2I then we = risk > end up with incompatibilities, seggregation in the deployed vehicles. > This is what happened with WAP in the mobile phone world until IP > arrived. This is what happens these days with consumer electronics > standards which include more and more IP technology as a networking > layer after initial deployments of specific apps without networking = layers. >=20 >> Why IP? ------- Whereas the Vehicle-to-Internet technologies are >> considered completed and deployed in automobiles currently on the >> roads (e.g. car tethering through driver's cellular smartphone, live >> traffic data displayed on the dashboard, - use of NAT/DHCP and >> potentially Mobile IP), the Vehicle-to-Vehicle and >> Vehicle-to-Infrastructure communications are still in an infancy >> stage: primitive link-specific data exchanges are limited to a >> non-harmonized set of applications, such as ETSI's CAM/DENM presence >> signalling; >>=20 >> */[RR>] Using the term non-harmonized here is not only incorrect, >> but inflammatory. Please remove such ill-advised terminology from >> the draft./* >=20 > Ok sorry if offense. >=20 >>=20 >> worse, some link-specific messages exhibit behaviour assimilated to >> IP behaviour >>=20 >> */[RR>] Not sure what the point is here. Messages don't have >> "behaviors", they have information content./* >=20 > Ok. >=20 >>=20 >> but the systems are incompatible with the Internet without involving >> specific gatewaying. >>=20 >> */[RR>] Gateway functionality is above the transport layer, and >> hence out of scope of this effort. /* >=20 > Ok, removed it for clarification. I agree with you. I think I meant > routing. >=20 >> The industry needs to employ IP data exchanges between vehicles, and >> between vehicles and the immediate infrastructure, rather than >> link-specific exchanges, in order to benefit from advantages such as >> (1) short delays, (2) fast forwarding through short paths of dumb >> routers (2) ease of reusing of a huge number of a desktop Internet >> applications in a vehicular environment (extend the Internet to >> mobile platforms). >>=20 >> */[RR>] This list is contradictory and the "necessity of employing" >> is not obvious. If you want fast forwarding, you don't do IP, you >> do MAC bridging at the data link layer where possible. >=20 > It sounds intuitive, but measuring it may surprise: >=20 > Apps running directly on link layer vs on a networking layer are not > necessarily faster. The round-trip time of 1280-byte packets on = 802.11p > is sensibly the same whether or not the 40bytes of the IPv6 header is = used. >=20 > The compute parts of an IP layer does not introduce much delay = compared > to the compute parts of the Ethernet link layer. The comparison of = the > compute-intensive parts in the two layers are the following: > - the CRC is optional in IP but mandatory in Ethernet. > - the table lookup is longest-match in IP (faster in simpler 1-hop > topologies employing default routes) and exact-match in Ethernet > (always same cost regardless topology size and complexity). Generally agree. But, we should think that the use of IPv6 layer will = not only add its basic IPv6 headers, but also requires security (and = possibly privacy related) headers and processing accordingly. Just a = quick thought, think about the big big overhead of IPSec and related key = establishment procedures that invoke the IKE protocols; sure we should = avoid to use these for IPv6 ITS. ;) >=20 >> If you want short delays, make the packets smaller and the >> processing overhead minimal, both of which argue AGAINST IPv6 >> networking protocols. >=20 > I should have been clearer: >=20 > Using IPv6 as networking layer in a string of vehicles allows for fast > and deterministic communications between the frontmost and rearmost > vehicle regardless the size of the string - it scales. Only with an > 802.11p link layer (no IP) that string is bound to a small size of a > few hundred meters, and additional propagation delays due to radio > propagation uncertainties - it doesnt scale. >=20 >> The advantage of IPv6 pure and simple is that using that particular >> networking protocol, most of the rest of the world can be reached! >> There is little debate on this point, and it is sufficient to >> justify pursuing this work. Why not leave it at that?? /* >=20 > I agree Richard. >=20 >> I think this paragraph take too long to get to the main point, which >> is >>=20 >> why IP is a goog thing in this environment. I suggest: >>=20 >> Today, there are several deployed Vehicle-to-Internet technologies, >>=20 >> including car tethering through driver's cellular smartphone. >> However, >>=20 >> Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are >> still >>=20 >> being developed. To avoid link-specific data exchanges, and enable >>=20 >> independent application sets to share the same links, IP data >> exchanges >>=20 >> are needed. Enabling IP communication between vehicles (V2V), and >>=20 >> between vehicles and the immediate infrastructure (V2I), will >> provide >>=20 >> (1) short delays, (2) fast forwarding through short paths of >> routers, >>=20 >> (3) ease of reuse of existing Internet applications in a vehicular >>=20 >> environment. >>=20 >> */[RR>] I would avoid any discussion of link-specific data exchanges >> because they are being mandated, and they have no bearing on this >> work. I'd simply state the obvious advantage of being able to >> leverage off the already deployed Internet and leave it at that./* >=20 > Improved the text. >=20 >>=20 >>=20 >>=20 >>=20 >> Moving network to moving network communications involve link layers >>=20 >> Add "nearby" here. I think it is important to the scope. >>=20 >>=20 >>=20 >> such as: 802.11 OCB, 802.15.4 with 6lowpan, 802.11ac, VLC (Visible >> Light Communications), IrDA, LTE-D. Only the IP protocols are >> capable >>=20 >> s/802.11 OCB/802.11p OCB (Outside the Context of a BSS)/ >>=20 >>> of running on each of these links and establish IP paths across >>> them in an interoperable manner. >>>=20 >>> */[RR>] Fair enough ... see comment above. Clearly there is no >>> need to focus on the data link and physical layers, other than to >>> state the obvious that if a particular MAC&PHY doesn't support the >>> requisite MTU sizes (e.g. 802.15.4), then some accommodations >>> (e.g. 6LoWPAN) will have to be made if possible. Noe of that >>> should affect the work of this group if I understand the goals >>> correctly. /* >>>=20 >>>=20 >>>=20 >>> Scenarios? ---------- There are a few scenarios exhibiting the >>> need to communicate from one moving network to another nearby >>> moving network. >>>=20 >>> In the automobile space, the Cooperative Adaptive Cruise Control >>> and Platooning features consider that vehicles close to each other >>> exchange data describing their kinematic status. At the >>> cross-roads, the moving network inside a vehicle exchanges data >>> with the moving network in the red-light pole. >>>=20 >>> Several public safety scenarios involve moving networks. Distinct >>> organizations deploy different moving networks (in-vehicle, >>> on-person) at an incident scene. These networks need to >>> interoperate in order to more effectively understand and deal with >>> the incident scene. >>>=20 >>> In connected rail scenarios the moving network deployed in trains >>> communicate with other moving networks at the cross-points. >>>=20 >>> */[RR>] The issue of trains and subnets thereon is tricky and the >>> topic of several investigations ongoing in Europe (including ETSI >>> TC RT and ITS (RT-JTFIR)). We may want to steer clear of such use >>> cases for the time being until the dust settles./* >=20 > There is a person from a router manufacturer who expressed high = interest > in the technology for rails. We may get a presentation in Buenos = Aires > to help clarify. >=20 >>>=20 >>>=20 >>>=20 >>> What kind of solutions? ----------------------- The current >>> technical solutions considered to achieve moving network to moving >>> network communications are of two kinds: IP routing >>>=20 >> Add "nearby" here. I think it is important to the scope. >>=20 >>=20 >>=20 >> protocols for n-hop path management and 1-hop link-scoped IP protocol >> enhancements. The 1-hop link-scoped protocols include the protocols >> for route establishment involving ICMP Router Advertisements. The >> n-hop path management protocols include n-hop path establishment >> protocols (e.g. Babel, OSPF) and n-hop path search protocols (most >> notably AODV and derivates). >>=20 >> */[RR>] Are these protocol modfications/additions, or simply >> profiles on existing protocols? I suspect it's the later, but you >> are the experts:^))/* >=20 > It's improving a protocol if possible (tweak its timers, extend some > header) or otherwise make a new one. >=20 > I am not sure about profiling protocols. I need to understand better > this term profiling. >=20 >> My understanding from the phone call was that we were going to focus >> on the 1-hop >>=20 >> protocols in this proposed working group, but leverage work from >> other groups for the >>=20 >> n-hop situation. >>=20 >> I think we need to say something here about the duration of some of >> the communications. >>=20 >> a vehicle traveling at 80 Km/h is not going to have communications >> with a roadside >>=20 >> device for very long. >>=20 >>=20 >>=20 >>=20 >> What kind of requirements? -------------------------- The >> requirements for mechanisms for moving network to moving network >>=20 >> Add "nearby" here. I think it is important to the scope. >>=20 >>=20 >>=20 >> communications are focusing on low delays of the data paths, reduced >> number of messages for path establishment, application friendly, >> resilience to attacks, compatibility with DHCP and Mobile IP. >>=20 >> In addition, some moving network to moving network applications >>=20 >> Add "nearby" here. I think it is important to the scope. >>=20 >> */[RR>] ITS communication security is being addressed in various >> venues (most notably IEEE 1609 and ETSI TC ITS). We should be >> careful not to reinvent the wheel. For example, while there is no >> theoretical problem using IPsec, to secure IPv6 management messages >> as well as data exchanges at the network layer, you might find using >> 1609.2 security functions work just as well if not better, and such >> mechanisms are/will be mandated in all "vehicles", so why not use >> them./* >=20 > YEs, I agree. We need to reuse from 1609, ETSI TC ITS and others. = When > studying some of them we may realize some may come from IETF (the cert > parts is an example). We need to identify the right source of reuse. Security and privacy requirements and concerns caused by the use of IPv6 = should be discussed and addressed at the IETF level. We will reuse the = current IPv6 security protocols; otherwise we define new ones here. ;) >=20 >> involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the >> 1-hop IP moving network to moving netowrk mechanisms will need to >> gracefully support IP multicast. >>=20 >> Due to the inherent characteristics of safety-related communications, >> all new moving network to moving network mechanisms must afford >> authenticity and confidentiality where necessary. Dynamically >> establishing ephemeral communication paths between automobiles in >> public areas must offer privacy safeguards for the end users >> (passengers). >>=20 >> */[RR>] All this has been and continues to be addressed in other >> venues. The solutions derived there are being / will be mandated by >> regulators. We should carefully follow and contribute to those >> efforts here appropriate, but otherwise not try to build a separate >> sand castle! /* >=20 > I agree. We will strive to synchronize with regulators. >=20 >> Establishing 1-hop IP V2V paths must not break the existing on-board >> protocols and applications which communicate with the Internet, >> possibly via multiple radios. >>=20 >> */[RR>] Not sure why this is a concern. >=20 > It's technical: in a car the Mobile Router can only have one default > route. Many V2I trials have that default route used by Mobile IP = these > days (forward everything to the HA). If we come up with a new = technique > for more direct V2V and V2I communications we must make sure we dont > disturb that Mobile IP part. It's a typical multihoming problem. >=20 >> 1-hop V2V doesn't require and in many cases does not use ANY >> networking at all (cf. FNTP, WSMP, HSMP, NNTP, whatever name you want >> to give the null-networking protocol whcih has been standardized in >> IEEE and ISO (cf. IEEE 1609.3, ISO 16460, ISO 29281-1, etc.)./* >=20 > What hop do you think about? >=20 > I think about IP hop. Should I call it 1-IP-hop V2V? >=20 >> In a moving network deployed in an automobile, typically one exit >> point connects the moving network to other moving networks. However, >> in a more general manner (and to support reliability) any new >> mechanism of moving network to moving network communications should >> support multi-homing: one router to use multiple interfaces towards >> outside the moving network, or multiple routers. >>=20 >> Current version of Internet protocols >> ------------------------------------- The version of the IP protocol >> is IPv6 (witness 10% IPv6 penetration as of early 2016, mobile >> operators evolving to IPv6-only, government IPv6 push, IPv4 exhaust >> at RIRs); this acommodates the current generation of Internet >> protocols. For backwards compatibility, IPv4 may be considered as >> well, but not exclusively. Link-local IPv6 addresses will be used. >>=20 >> This it too long. Just say that the groups will only work on IPv6 >> solutions. >>=20 >> */[RR>] Yes. Simpler is better!/* >=20 > Thanks, I agree. Modified accordingly. >=20 > Alex >=20 >>=20 >>=20 >>=20 >>=20 >> What SDOs may need this work? ----------------------------- The >> requirements and standards for moving network to moving network >> communications, often involving IPv6, and novel V2V and V2Infra >> concepts, are developed mainly at ISO TC204 "Intelligent Transport >> Systems", 3GPP, ETSI, NHTSA and IEEE. For Vehicle-to-Internet >> communications, 3GPP LTE and other cellular technologies represent >> the long-range connectivity method; for Vehicle-to-Vehicle >> communications, LTE Direct is currently specified, as well as OCB >> mode of IEEE 802.11. Several use-cases exhibit a need for IPv6 data >> exchanges between vehicles: ETSI's Cooperative Adaptive Cruise >> Control and Platooning. The IEEE developed a popular link for >> short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a >> set of requirements for V2V communications. >>=20 >> Work Items ---------- - use-cases for moving network to moving >> network communications - Problem Statement for moving network to >> moving network communications - Security and Privacy Requirements >> for moving network to moving network communications - Problem >> Statement for moving network to infrastructure network >> communications, including DNS - Potentially new protocol, or protocol >> extensions for establishing IP paths for 1-hop moving network to >> moving network communications. With MIB and security. - IPv6-over >> foo, where foo is pertinent for moving network to moving network >> communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) >>=20 >> */[RR>] The real issue is using IPv6 networking to connect mobile >> LAN subnets ... the data link and physical layer technology is NOT >> directly relevant. Simpler is better!/* >>=20 >>=20 >>=20 >> Timeline -------- - >>=20 >> _______________________________________________ its mailing list >> its@ietf.org > >> https://www.ietf.org/mailman/listinfo/its = >>=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its = --Apple-Mail=_F856F710-8EFD-4D28-A74D-D388DAAD6DF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Alex,

Some comments are below.

J.
--
Jong-Hyouk Lee, living somewhere between /dev/null = and /dev/random
Protocol Engineering Lab., = Sangmyung University

#email: jonghyouk@gmail.com
#webpage: https://sites.google.com/site/hurryon

On Feb 19, 2016, at 2:47 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:



Le 17/02/2016 23:15, Richard Roy a =E9crit = :
My = comments are inline below ...

RR

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



*From:*Russ Housley [mailto:housley@vigilsec.com] *Sent:* = Wednesday,
February = 17, 2016 10:36 AM *To:* Alexandre Petrescu *Cc:*
its@ietf.org *Subject:* Re: [its] = Updated charter - please comment

Alex:

Below are my comments on the proposed charter = text.

Russ



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



ITS (name to change) Charter = February 15th, 2016
http://ietf.org/mailman/listinfo/its


Intelligent Transportation Systems (its)
---------------------------------------- Current Status: WG = forming

Chairs: TBD

Assigned Area Director: TBD

Mailing list Address: its@ietf.org <mailto:its@ietf.org> = To
Subscribe: https://www.ietf.org/mailman/listinfo/its Archive:
http://www.ietf.org/mail-archive/web/its/current/maillist.html<= /a>

Additional web page TBD
Charter:

Goal ---- The goal of = this group is to standardize IP protocols for
establishing = direct and secure connectivity between moving networks.

*/[RR>] Hard to believe that IP protocols need = standardizing.  Isn't
the real issue one of an = appropriate "profile" for using already
existing RFCs to = implement IPv6 networking "between moving
subnets"?/*

Well profiles are for Bluetooth if you wish = (which is below IP, or above
IP) but I can say "adapt" or "improve" IP = protocols.

BEcause I havent much seen = the word "profile" in RFCs for the IP layer.

Moving Network to Moving Network Communications
----------------------------------------------- The group = is
concerned with all situations involving moving network = to moving
network communications.  For example: = vehicle-to-vehicle
communications, nomadic user wearing a = PAN and communicating to a
homenet, = vehicle-to-infrastructure communications, wagon-to-wagon in
a train, or train-to-intersection signalling.
Example from the automobile communications space
------------------------------------------------ Automobiles = and
vehicles of all types are increasingly connected to = the Internet.
Entertainment apps enhancing comfort, = reliable data exchanges for
road safety, and automated = driving, are commonly seen as

Editorial: =  s/automated driving, are/automated driving are/



winning sale arguments for = automobiles to hit the roads from now to
year 2020. =  Emergency apps for new instrumented ambulances carry many
benefits both to the users and to society in general.

I think that the "winning sales arguments" is = not needed here.
Instead, I think it

would be valuable to say that these features are coming, and = that
the safety

features are = expected to become required.

*/[RR>] = Many of the apps to which you allude do not require IPv6
networking.  If you feel the need to provide use cases, = make sure
they require IPv6 networking in a mobile = context./*

I will try to do that.

I would like you - if possible - to = suggest other use case which
requires IPv6 networking in a mobile context? =  Thanks.

Let me explain the = reasoning in the paragraph above by listing a few key
items for IPv6 networking = in V2V and V2I, pick one:

I experienced the need for = IP between cells of vehicles moving together.
The need was there urgent: = the programmer in the back car had
absolutely to flush the data in the = middle car and the LTE connection
was down.  If no flush then risk of = accident.  The computer that flushes
is windows with TCP IP on WiFi.  The = computer to be flushed is a linux
variant on a CAN network.  The only = way to have that flush work is to
network the two computers IP networked = together.

There is no standard in = vehicular communications which requires IPv4.
If ever IP is mentioned it = is IPv6.

The example C-ACC use case = is typical illustration of a direct
vehicle-to-vehicle communication of data = (as opposed to entertainment
apps which are Vehicle-to-Internet, and 'radar' = communication which is
bouncing signals not data).

A C-ACC standard currently under = definition by ETSI is using CAM and
DENM messages.  The CAM and DENM = messages are understood by some at the
link-layer and by others at the = application-layer.  If they are
application-layer, then there is a need = of a networking layer.  The only
networking layer is IPv6.

Vehicles connected to the Internet can = only use IPv6 as networking
layer.  If we want V2V and V2I to make a = V2V2I the only possibility
again is to use IPv6 as the networking = layer.

If we dont use IPv6 as the = networking layer in V2V and V2I then we risk
end up with = incompatibilities, seggregation in the deployed vehicles.
This is what happened with = WAP in the mobile phone world until IP
arrived.  This is what happens these = days with consumer electronics
standards which include more and more IP = technology as a networking
layer after initial deployments of specific apps = without networking layers.

Why IP? ------- Whereas the = Vehicle-to-Internet technologies are
considered completed = and deployed in automobiles currently on the
roads (e.g. = car tethering through driver's cellular smartphone, live
traffic data displayed on the dashboard, - use of NAT/DHCP = and
potentially Mobile IP), the Vehicle-to-Vehicle and
Vehicle-to-Infrastructure communications are still in an = infancy
stage: primitive link-specific data exchanges are = limited to a
non-harmonized set of applications, such as = ETSI's CAM/DENM presence
signalling;

*/[RR>] Using the term non-harmonized here is not only = incorrect,
but inflammatory.  Please remove such = ill-advised terminology from
the draft./*

Ok sorry if offense.


worse, some link-specific messages exhibit behaviour = assimilated to
IP behaviour

*/[RR>] Not sure what the point is here.  Messages = don't have
"behaviors", they have information = content./*

Ok.


but the systems are incompatible with the Internet without = involving
specific gatewaying.

*/[RR>] Gateway functionality is above the transport = layer, and
hence out of scope of this effort. /*

Ok, removed it for clarification.  I agree = with you.  I think I meant
routing.

The = industry needs to employ IP data exchanges between vehicles, and
between vehicles and the immediate infrastructure, rather = than
link-specific exchanges, in order to benefit from = advantages such as
(1) short delays, (2) fast forwarding = through short paths of dumb
routers (2) ease of reusing of = a huge number of a desktop Internet
applications in a = vehicular environment (extend the Internet to
mobile = platforms).

*/[RR>] This list is = contradictory and the "necessity of employing"
is not = obvious.  If you want fast forwarding, you don't do IP, you
do MAC bridging at the data link layer where possible.

It sounds intuitive, but measuring it may = surprise:

Apps running directly on = link layer vs on a networking layer are not
necessarily faster. =  The round-trip time of 1280-byte packets on 802.11p
is sensibly the same = whether or not the 40bytes of the IPv6 header is used.

The compute parts of an IP layer does not = introduce much delay compared
to the compute parts of the Ethernet link layer. =  The comparison of the
compute-intensive parts in the two layers are = the following:
- the CRC is optional in IP but mandatory in = Ethernet.
- the table lookup is longest-match in IP = (faster in simpler 1-hop
 topologies employing default routes) and = exact-match in Ethernet
 (always same cost regardless topology size = and complexity).



If = you want short delays, make the packets smaller and the
processing overhead minimal, both of which argue AGAINST = IPv6
networking protocols.

I should have been = clearer:

Using IPv6 as networking = layer in a string of vehicles allows for fast
and deterministic = communications between the frontmost and rearmost
vehicle regardless the = size of the string - it scales.  Only with an
802.11p link layer (no IP) =  that string is bound to a small size of a
few hundred meters, and = additional propagation delays due to radio
propagation uncertainties - it doesnt = scale.

The advantage of IPv6 pure = and simple is that using that particular
networking = protocol, most of the rest of the world can be reached!
There is little debate on this point, and it is sufficient = to
justify pursuing this work. Why not leave it at that?? = /*

I agree Richard.

I think = this paragraph take too long to get to the main point, which
is

why IP is a goog thing in = this environment.  I suggest:

Today, = there are several deployed Vehicle-to-Internet technologies,

including car tethering through driver's = cellular smartphone.
However,

Vehicle-to-Vehicle and Vehicle-to-Infrastructure = communications are
still

being = developed.  To avoid link-specific data exchanges, and enable

independent application sets to share the same = links, IP data
exchanges

are = needed.  Enabling IP communication between vehicles (V2V), and

between vehicles and the immediate = infrastructure (V2I), will
provide

(1) short delays, (2) fast forwarding through short paths = of
routers,

(3) ease of reuse = of existing Internet applications in a vehicular

environment.

*/[RR>] I would = avoid any discussion of link-specific data exchanges
because= they are being mandated, and they have no bearing on this
work. I'd simply state the obvious advantage of being able = to
leverage off the already deployed Internet and leave it = at that./*

Improved the text.





Moving network = to moving network communications involve link layers

Add "nearby" here.  I think it is important to the = scope.



such = as: 802.11 OCB, 802.15.4 with 6lowpan, 802.11ac, VLC (Visible
Light Communications), IrDA, LTE-D.  Only the IP = protocols are
capable

s/802.11 = OCB/802.11p OCB (Outside the Context of a BSS)/

of running on each of = these links and establish IP paths across
them in an = interoperable manner.

*/[RR>] Fair = enough ... see comment above.  Clearly there is no
need= to focus on the data link and physical layers, other than to
state the obvious that if a particular MAC&PHY doesn't = support the
requisite MTU sizes (e.g. 802.15.4), then some = accommodations
(e.g. 6LoWPAN) will have to be made if = possible. Noe of that
should affect the work of this group = if I understand the goals
correctly. /*



Scenarios? ---------- There are = a few scenarios exhibiting the
need to communicate from = one moving network to another nearby
moving network.

In the automobile space, the Cooperative = Adaptive Cruise Control
and Platooning features consider = that vehicles close to each other
exchange data describing = their kinematic status.  At the
cross-roads, the = moving network inside a vehicle exchanges data
with the = moving network in the red-light pole.

Several= public safety scenarios involve moving networks.  Distinct
organizations deploy different moving networks = (in-vehicle,
on-person) at an incident scene.  These = networks need to
interoperate in order to more effectively = understand and deal with
the incident scene.

In connected rail scenarios the moving network = deployed in trains
communicate with other moving networks = at the cross-points.

*/[RR>] The issue = of trains and subnets thereon is tricky and the
topic of = several investigations ongoing in Europe (including ETSI
TC = RT and ITS (RT-JTFIR)).  We may want to steer clear of such use
cases for the time being until the dust settles./*

There is a person from a router = manufacturer who expressed high interest
in the technology for rails.  We may = get a presentation in Buenos Aires
to help clarify.




What kind of solutions? = ----------------------- The current
technical solutions = considered to achieve moving network to moving
network = communications are of two kinds: IP routing

Add "nearby" here.  I think it is important = to the scope.



protocols for n-hop path management and 1-hop link-scoped IP = protocol
enhancements.  The 1-hop link-scoped = protocols include the protocols
for route establishment = involving ICMP Router Advertisements.  The
n-hop path = management protocols include n-hop path establishment
protocols (e.g. Babel, OSPF) and n-hop path search protocols = (most
notably AODV and derivates).

*/[RR>] Are these protocol modfications/additions, or = simply
profiles on existing protocols?  I suspect = it's the later, but you
are the experts:^))/*

It's improving a protocol if possible (tweak its = timers, extend some
header) or otherwise make a new one.

I am not sure about profiling protocols. =  I need to understand better
this term profiling.

My = understanding from the phone call was that we were going to focus
on the 1-hop

protocols in this = proposed working group, but leverage work from
other = groups for the

n-hop situation.

I think we need to say something here about = the duration of some of
the communications.

a vehicle traveling at 80 Km/h is not going to = have communications
with a roadside

device for very long.




What kind of requirements? = -------------------------- The
requirements for mechanisms = for moving network to moving network

Add = "nearby" here.  I think it is important to the scope.



communications = are focusing on low delays of the data paths, reduced
number= of messages for path establishment, application friendly,
resilience to attacks, compatibility with DHCP and Mobile = IP.

In addition, some moving network to = moving network applications

Add "nearby" = here.  I think it is important to the scope.

*/[RR>] ITS communication security is being addressed in = various
venues (most notably IEEE 1609 and ETSI TC ITS). =  We should be
careful not to reinvent the wheel. =  For example, while there is no
theoretical problem = using IPsec, to secure IPv6 management messages
as well as = data exchanges at the network layer, you might find using
1609.2 security functions work just as well if not better, = and such
mechanisms are/will be mandated in all = "vehicles", so why not use
them./*

YEs, I agree.  We need to reuse from 1609, = ETSI TC ITS and others.  When
studying some of them we may realize some = may come from IETF (the cert
parts is an example).  We need to identify = the right source of reuse.



involve IP multicast = mechanisms (e.g. virtual siren); thus C-ACC the
1-hop IP = moving network to moving netowrk mechanisms will need to
gracefully support IP multicast.

Due to the inherent characteristics of safety-related = communications,
all new moving network to moving network = mechanisms must afford
authenticity and confidentiality = where necessary. Dynamically
establishing ephemeral = communication paths between automobiles in
public areas = must offer privacy safeguards for the end users
(passengers).

*/[RR>] All = this has been and continues to be addressed in other
venues.= The solutions derived there are being / will be mandated by
regulators.  We should carefully follow and contribute = to those
efforts here appropriate, but otherwise not try = to build a separate
sand castle! /*

I agree.  We will strive to synchronize = with regulators.

Establishing 1-hop IP V2V = paths must not break the existing on-board
protocols and = applications which communicate with the Internet,
possibly = via multiple radios.

*/[RR>] Not sure = why this is a concern.

It's technical: in a car = the Mobile Router can only have one default
route.  Many V2I = trials have that default route used by Mobile IP these
days (forward everything = to the HA).  If we come up with a new technique
for more direct V2V and = V2I communications we must make sure we dont
disturb that Mobile IP = part.  It's a typical multihoming problem.

1-hop= V2V doesn't require and in many cases does not use ANY
networking at all (cf. FNTP, WSMP, HSMP, NNTP, whatever name = you want
to give the null-networking protocol whcih has = been standardized in
IEEE and ISO (cf. IEEE 1609.3, ISO = 16460, ISO 29281-1, etc.)./*

What hop do you think = about?

I think about IP hop. =  Should I call it 1-IP-hop V2V?

In a = moving network deployed in an automobile, typically one exit
point connects the moving network to other moving networks. = However,
in a more general manner (and to support = reliability) any new
mechanism of moving network to moving = network communications should
support multi-homing: one = router to use multiple interfaces towards
outside the = moving network, or multiple routers.

Current = version of Internet protocols
------------------------------------- The version of the IP = protocol
is IPv6 (witness 10% IPv6 penetration as of early = 2016, mobile
operators evolving to IPv6-only, government = IPv6 push, IPv4 exhaust
at RIRs); this acommodates the = current generation of Internet
protocols.  For = backwards compatibility, IPv4 may be considered as
well, = but not exclusively.  Link-local IPv6 addresses will be used.

This it too long.  Just say that the = groups will only work on IPv6
solutions.

*/[RR>] Yes. Simpler is better!/*

Thanks, I agree.  Modified = accordingly.

Alex





What SDOs may = need this work? ----------------------------- The
requirements and standards for moving network to moving = network
communications, often involving IPv6, and novel = V2V and V2Infra
concepts, are developed mainly at ISO = TC204 "Intelligent Transport
Systems", 3GPP, ETSI, NHTSA = and IEEE.  For Vehicle-to-Internet
communications, = 3GPP LTE and other cellular technologies represent
the = long-range connectivity method; for Vehicle-to-Vehicle
communications, LTE Direct is currently specified, as well as = OCB
mode of IEEE 802.11. Several use-cases exhibit a need = for IPv6 data
exchanges between vehicles: ETSI's = Cooperative Adaptive Cruise
Control and Platooning. The = IEEE developed a popular link for
short-range = communications - IEEE 802.11p "WAVE".  The NHTSA wrote a
set of requirements for V2V communications.

Work Items ---------- - use-cases for moving network to = moving
network communications - Problem Statement for = moving network to
moving network communications - Security = and Privacy Requirements
for moving network to moving = network communications - Problem
Statement for moving = network to infrastructure network
communications, = including DNS - Potentially new protocol, or protocol
extensions for establishing IP paths for 1-hop moving network = to
moving network communications. With MIB and security. - = IPv6-over
foo, where foo is pertinent for moving network = to moving network
communications (e.g. 802.11 OCB, VLC, = LTE-D, 802.11ad)

*/[RR>] The real issue = is using IPv6 networking to connect mobile
LAN subnets ... = the data link and physical layer technology is NOT
directly = relevant.  Simpler is better!/*



Timeline -------- -

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

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

= --Apple-Mail=_F856F710-8EFD-4D28-A74D-D388DAAD6DF5-- From nobody Mon Mar 7 08:30:35 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA6E1B4408 for ; Mon, 7 Mar 2016 08:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 fc1CwttZpgn3 for ; Mon, 7 Mar 2016 08:30:33 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29571B4403 for ; Mon, 7 Mar 2016 08:30:32 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u27GUS1e003252; Mon, 7 Mar 2016 17:30:28 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0643A20BFB7; Mon, 7 Mar 2016 17:30:54 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E35C0202911; Mon, 7 Mar 2016 17:30:53 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u27GURAR023247; Mon, 7 Mar 2016 17:30:28 +0100 To: Jong-Hyouk Lee References: <56C1D0AB.3020006@gmail.com> <8B07B35E-3FE8-4B1E-9017-7A2E34B320F3@vigilsec.com> <56C603CD.6010809@gmail.com> <279F71D8-5DCD-4EC2-B093-2E0A98855842@gmail.com> From: Alexandre Petrescu Message-ID: <56DDACA3.90105@gmail.com> Date: Mon, 7 Mar 2016 17:30:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <279F71D8-5DCD-4EC2-B093-2E0A98855842@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Thierry Ernst , its@ietf.org, Russ Housley , "Dr. Hans-Joachim Fischer" , knut.evensen@q-free.com, dickroy@alum.mit.edu Subject: Re: [its] Updated charter - please comment X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 16:30:34 -0000 Hi Jong-Hyouk, Many thanks for the reply. Le 07/03/2016 17:14, Jong-Hyouk Lee a écrit : [...] >> The compute parts of an IP layer does not introduce much delay compared >> to the compute parts of the Ethernet link layer. The comparison of the >> compute-intensive parts in the two layers are the following: >> - the CRC is optional in IP but mandatory in Ethernet. >> - the table lookup is longest-match in IP (faster in simpler 1-hop >> topologies employing default routes) and exact-match in Ethernet >> (always same cost regardless topology size and complexity). > > Generally agree. But, we should think that the use of IPv6 layer will > not only add its basic IPv6 headers, but also requires security (and > possibly privacy related) headers and processing accordingly. Just a > quick thought, think about the big big overhead of IPSec and related key > establishment procedures that invoke the IKE protocols; sure we should > avoid to use these for IPv6 ITS. ;) Sure we should keep in mind that the security mechanisms of IPv6 may involve additional overhead. However, I would guess that IPsec has state-of-the-art fast mechanisms as compared to link-layer security mechanisms. [...] >> YEs, I agree. We need to reuse from 1609, ETSI TC ITS and others. When >> studying some of them we may realize some may come from IETF (the cert >> parts is an example). We need to identify the right source of reuse. > > Security and privacy requirements and concerns caused by the use of IPv6 > should be discussed and addressed at the IETF level. We will reuse the > current IPv6 security protocols; otherwise we define new ones here. ;) Agreed. There are currently two inceptive directions that could drive the security work in ITS at IETF: the certificates work (IETF and ITU) and the privacy identifiers work (ETSI). Do you see something else? How should we have security work in ITS at IETF? Alex From nobody Mon Mar 7 08:40:05 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7040A1B4441 for ; Mon, 7 Mar 2016 08:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 4TT5zmbMaYUX for ; Mon, 7 Mar 2016 08:39:23 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 275471B4442 for ; Mon, 7 Mar 2016 08:39:07 -0800 (PST) Received: by mail-pa0-x231.google.com with SMTP id bj10so81646144pad.2 for ; Mon, 07 Mar 2016 08:39:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n+dMvequfH5tcjG8LY1GFPjeG76lc/lKJ12+gzbOik8=; b=jewp8LyUtGX1wpCH9F73NJQKLUWiZqFlgbenbIRq9QNcqvjkTSzdN5NSObzxIfZxOc TV6nw9o+z1IjqGSHW2pN3K6bz6PpkRT1FpPllYOS+t58+0t7M0a/9WQliBeAaK+xTa97 eQql5ue2N0nuVzescBRfia78HbNiBUNIoC13M8RXa7FturGs9BLDJGQy8WxTWmOVG11Z tAdKggpl+FwiPME8iSmAWfi1mENuhYk9UYVsleyBtcZmq8Jac80Y6GdTT0t3eGqvt2It isyU+HqrIYFtQMvFKdmkClOtFmeDrziFCmdKYgz/B3roBBLdi4ixS+0JrHGbrimLDK3C kV7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n+dMvequfH5tcjG8LY1GFPjeG76lc/lKJ12+gzbOik8=; b=RPa+ecwXpFniAyJolxQqZZbbsfh24fY6ceAaCdgF0erwvizy5iS+qhWRBgLZhmOdUD rIXBhAgNY++78zwvqjyDWcnAIXygpydkJNGWA3YfMNpdJrygL5Y+kd02aEmVYWR4gj6i gSh2xqlWmv/dpGURAVPzGqYrw0+jZscjfeCZeIrZTETUTET1mUZjHPWfntgvtkv3pcEL gyQJk5PnPJFk33+7isfpXSfqDDn5WGBKoj9OcF0BYo9elIAQMBna8Et/FOivoethrLlW BT5KO33mVhviYi9RyJ6K3YCDeum/ZmSF3Nh9PVjOgklaByvufOMnuxSZqVPXTK3Hz1EE 0ACA== X-Gm-Message-State: AD7BkJJIoLoLEYP3VZLL/6wFkFrAvHgd9IQu/j9fpq58SqHEZiT4TWWVQGSlBft3UTTAzg== X-Received: by 10.66.65.109 with SMTP id w13mr34467098pas.142.1457368745805; Mon, 07 Mar 2016 08:39:05 -0800 (PST) Received: from [10.0.1.4] ([121.152.87.242]) by smtp.gmail.com with ESMTPSA id y21sm25156149pfa.85.2016.03.07.08.39.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 07 Mar 2016 08:39:04 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: text/plain; charset=windows-1252 From: Jong-Hyouk Lee In-Reply-To: <56DDACA3.90105@gmail.com> Date: Tue, 8 Mar 2016 01:39:00 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <9E46CE90-593B-4266-82B4-7F151BFEC5D1@gmail.com> References: <56C1D0AB.3020006@gmail.com> <8B07B35E-3FE8-4B1E-9017-7A2E34B320F3@vigilsec.com> <56C603CD.6010809@gmail.com> <279F71D8-5DCD-4EC2-B093-2E0A98855842@gmail.com> <56DDACA3.90105@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Thierry Ernst , its@ietf.org, Russ Housley , "Dr. Hans-Joachim Fischer" , knut.evensen@q-free.com, dickroy@alum.mit.edu Subject: Re: [its] Updated charter - please comment X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 16:39:25 -0000 Please see inline; anyway, we will have a face-to-face meeting soon. ;) -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Mar 8, 2016, at 1:30 AM, Alexandre Petrescu = wrote: >=20 > Hi Jong-Hyouk, >=20 > Many thanks for the reply. >=20 > Le 07/03/2016 17:14, Jong-Hyouk Lee a =E9crit : > [...] >>> The compute parts of an IP layer does not introduce much delay = compared >>> to the compute parts of the Ethernet link layer. The comparison of = the >>> compute-intensive parts in the two layers are the following: >>> - the CRC is optional in IP but mandatory in Ethernet. >>> - the table lookup is longest-match in IP (faster in simpler 1-hop >>> topologies employing default routes) and exact-match in Ethernet >>> (always same cost regardless topology size and complexity). >>=20 >> Generally agree. But, we should think that the use of IPv6 layer will >> not only add its basic IPv6 headers, but also requires security (and >> possibly privacy related) headers and processing accordingly. Just a >> quick thought, think about the big big overhead of IPSec and related = key >> establishment procedures that invoke the IKE protocols; sure we = should >> avoid to use these for IPv6 ITS. ;) >=20 > Sure we should keep in mind that the security mechanisms of IPv6 may = involve additional overhead. >=20 > However, I would guess that IPsec has state-of-the-art fast mechanisms = as compared to link-layer security mechanisms. Want to know! >=20 > [...] >=20 >>> YEs, I agree. We need to reuse from 1609, ETSI TC ITS and others. = When >>> studying some of them we may realize some may come from IETF (the = cert >>> parts is an example). We need to identify the right source of = reuse. >>=20 >> Security and privacy requirements and concerns caused by the use of = IPv6 >> should be discussed and addressed at the IETF level. We will reuse = the >> current IPv6 security protocols; otherwise we define new ones here. = ;) >=20 > Agreed. >=20 > There are currently two inceptive directions that could drive the = security work in ITS at IETF: the certificates work (IETF and ITU) and = the privacy identifiers work (ETSI). >=20 > Do you see something else? How should we have security work in ITS at = IETF? As stated, we first build the requirement document for security and = privacy. I=92ll try to find some time to write a draft soon. Regarding = the certificate, it will be one option to use. It will be all depending = on requirements, e.g., some communications/applications do not require = nonrepudiation so that the use of certificate will not be required. = Anyway, as we are working for IPv6 ITS at the IETF first time, we should = put all possible options on the table and analyse them first. In other = words, we should not try to stick with one solution yet. ;) Cheers. >=20 > Alex From nobody Mon Mar 7 15:50:55 2016 Return-Path: X-Original-To: its@ietfc.amsl.com Delivered-To: its@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6BED01CDE7F for ; Mon, 7 Mar 2016 15:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlwnOP_wg6js for ; Mon, 7 Mar 2016 15:50:53 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfc.amsl.com (Postfix) with ESMTP id 09A0C1CDE7E for ; Mon, 7 Mar 2016 15:50:53 -0800 (PST) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id A047C9A400D for ; Mon, 7 Mar 2016 18:50:52 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id Q8+SiX1mQwk2 for ; Mon, 7 Mar 2016 18:38:13 -0500 (EST) Received: from [172.16.1.184] (19.190.138.210.bf.2iij.net [210.138.190.19]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 07B859A400C for ; Mon, 7 Mar 2016 18:50:51 -0500 (EST) From: Russ Housley Content-Type: multipart/alternative; boundary=Apple-Mail-202-198596499 Date: Mon, 7 Mar 2016 18:50:49 -0500 Message-Id: To: its@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: Subject: [its] ITS BOF in Buenos Aires at IETF 95 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 23:50:54 -0000 --Apple-Mail-202-198596499 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii The IESG has approved a BOF slot for ITS, and the draft agenda is out: https://datatracker.ietf.org/meeting/95/agenda (search for "its") I hope to see you there, Russ --Apple-Mail-202-198596499 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii The IESG has approved a BOF slot for ITS, and the draft agenda is out:

https://datatracker.ietf.org/meeting/95/agenda
(search for "its")

I hope to see you there,
  Russ
--Apple-Mail-202-198596499-- From nobody Tue Mar 8 03:06:31 2016 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 89EF312D650 for ; Tue, 8 Mar 2016 03:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uf8Fp7VmDCMn for ; Tue, 8 Mar 2016 03:06:24 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 05FDC12D649 for ; Tue, 8 Mar 2016 03:06:24 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id n186so125933414wmn.1 for ; Tue, 08 Mar 2016 03:06:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=Om7Y3pZqg4g/haqY0kOEYIgi5D/lQWyEAKP1tcmmNyk=; b=uulgTIZdpNj2HGsaqYpOy3Jn68O0DIXX1pFAnHcB1c8TCylO21FhdFDSnpx/9iUuwm +wFZAjcjlO3NE5s7P6uwKl4FHm2Ksu76Kyxwo3Wr4q0mHFl+qzVYEHFsHfV87ocrfZIg XdbfXbCdcMwZaf+1oXmCpDQwFfoL8CkccwqAuC/s6OhQ8f2+kJeWFLM+3zyBtAqF+BWR 1rQ6VlHXOP9HHTje3hJOsc2w4nKrU5lVQ8VSSYkLlqePl/HWmLcBVLQaUcNellEJGucK bvDJimfkcPgpu6Mig3MWZ9anaDVN8bEHxze/O/dLOzUMmv2k47T2p5TSObZdWfFPRJR0 54oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=Om7Y3pZqg4g/haqY0kOEYIgi5D/lQWyEAKP1tcmmNyk=; b=MxMT3cxrmNpe2+CCKolvxmg1nTFojAE8oU/InSkrZA2ZGyt7NTPLSSuVs5A1nSMzMy QGaiPxk72SZluOY2AJdiW3J3ZN72g6qxB7G9V0CFJ1RI4KxhWhpFfTi3urUVEeYcnzEp UAMduurYhYKbCuShFwfhiakDwXLr5/SrDTjpa4V+5OalzVivnkv0VbQGf7mGb/qN+PJf OlAsSHGgUZv9GawWstQOO/2PJdwS7hwz1oTKIAc0kOFQfEiKQpZ62GLQJAUk1WstJCz9 hRsthjBQW+C3m2hm0tbQCtMSq/Tw4CAv1+FZ16e1TiiOt0FR6HZYGLT3F22MbNQ6X2yM Dq8Q== X-Gm-Message-State: AD7BkJJY9wcXi3aQ7Qwg773qgXQg0WE6fKRBEYmwbjZhj/TyrFT/cGKPq7uFP/Vu2+O4XRh5VucgJhgHWYw0KA== MIME-Version: 1.0 X-Received: by 10.28.188.5 with SMTP id m5mr12444820wmf.35.1457435182522; Tue, 08 Mar 2016 03:06:22 -0800 (PST) Received: by 10.28.32.11 with HTTP; Tue, 8 Mar 2016 03:06:22 -0800 (PST) In-Reply-To: <56DD9969.5080307@gmail.com> References: <56C1D0AB.3020006@gmail.com> <8B07B35E-3FE8-4B1E-9017-7A2E34B320F3@vigilsec.com> <56DD9969.5080307@gmail.com> Date: Tue, 8 Mar 2016 11:06:22 +0000 Message-ID: From: Nabil Benamar To: Alexandre Petrescu , "its@ietf.org" Content-Type: multipart/alternative; boundary=001a114b0d68566507052d8792dc Archived-At: Subject: Re: [its] Updated charter - please comment X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 11:06:29 -0000 --001a114b0d68566507052d8792dc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alex, Here is some a non-exhaustive list of some : - Proactive Vehicular Traffic Re-routing for Lower Travel Time. - Reliable Intersection Protocols Using Vehicular Networks. - STIP: Spatio-Temporal Intersection Protocols for Autonomous Vehicles. - Routing protocols in Vehicular Delay Tolerant Networks: A comprehensive survey. - Toward V2I Communication Technology-based Solution for Reducing Road Traffic Congestion in Smart Cities. - - Sensing Traffic Density Combining V2V and V2IWireless Communications. - - Efficient Macroscopic Urban Traffic Models for Reducing Congestion: a PDDL+ Planning Approach. - - On Stochastic Analysis of Greedy Routing in Vehicular Networks. - - Balanced Traffic Routing: Design, Implementation, and Evaluation. - - A Survey on Urban Traffic Management System Using Wireless Sensor Networks. Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 http://nabilbenamar.ipv6-lab.net/ On Mon, Mar 7, 2016 at 3:08 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > Le 04/03/2016 17:33, Nabil Benamar a =C3=A9crit : > >> Hi Alex, Russ and itsers, >> >> The charter looks good for me and it should be noted that a great amount >> of research papers are focusing on the benefits of car to car >> communication to solve some relevant issues. >> > > Do you have a list of such research papers? > > Alex > > Many strategies are >> proposed to proactively compute re-routing guidance to be pushed to >> vehicles when signs of congestion are observed on their route. This is >> beyond the safety issue as stated in the draft charter but it concerns a >> better driving experience ! >> >> Other car manufacturers could be interested by the outcomes of this >> wg, especially when we think about Autonomous driving. Indeed, one of >> the main challenges of autonomous driving in urban areas is transition >> through cross-roads and intersections. In addition to safety concerns, >> current intersection management technologies such as stop signs and >> trafic lights can introduce significant trafic delays even under light >> trafic conditions. >> >> V2V and V2I can help avoiding deadlock situations >> and eventual collisions as well ! >> >> Moreover, considering the importance of IPv6 deployment nowadays and all >> the possibilities and new technologies rising from it, our previous >> draft can be a good starting point and a work item for the WG: >> https://datatracker.ietf.org/doc/draft-petrescu-ipv6-over-80211p/ >> >> >> >> >> >> Best regards >> Nabil Benamar >> ------------------- >> =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 >> >> http://nabilbenamar.ipv6-lab.net/ >> >> On Wed, Feb 17, 2016 at 6:36 PM, Russ Housley > > wrote: >> >> Alex: >> >> Below are my comments on the proposed charter text. >> >> Russ >> >> >> >> >>> ----------------------------------------------------------------------- >>> >>> ITS (name to change) >>> Charter >>> February 15th, 2016 >>> http://ietf.org/mailman/listinfo/its >>> >>> >>> Intelligent Transportation Systems (its) >>> ---------------------------------------- >>> Current Status: WG forming >>> >>> Chairs: >>> TBD >>> >>> Assigned Area Director: >>> TBD >>> >>> Mailing list >>> Address: its@ietf.org >>> >>> To Subscribe: https://www.ietf.org/mailman/listinfo/its >>> Archive: >>> http://www.ietf.org/mail-archive/web/its/current/maillist.html >>> >>> Additional web page >>> TBD >>> >>> Charter: >>> >>> Goal >>> ---- >>> The goal of this group is to standardize IP protocols for >>> establishing >>> direct and secure connectivity between moving networks. >>> >>> Moving Network to Moving Network Communications >>> ----------------------------------------------- >>> The group is concerned with all situations involving moving network >>> to >>> moving network communications. For example: vehicle-to-vehicle >>> communications, nomadic user wearing a PAN and communicating to a >>> homenet, vehicle-to-infrastructure communications, wagon-to-wagon i= n >>> a >>> train, or train-to-intersection signalling. >>> >>> Example from the automobile communications space >>> ------------------------------------------------ >>> Automobiles and vehicles of all types are increasingly connected to >>> the Internet. Entertainment apps enhancing comfort, reliable data >>> exchanges for road safety, and automated driving, are commonly seen >>> as >>> >> >> Editorial: s/automated driving, are/automated driving are/ >> >> winning sale arguments for automobiles to hit the roads from now to >>> year 2020. Emergency apps for new instrumented ambulances carry ma= ny >>> benefits both to the users and to society in general. >>> >> >> I think that the "winning sales arguments" is not needed here. >> Instead, I think it >> would be valuable to say that these features are coming, and that >> the safety >> features are expected to become required. >> >> >>> Why IP? >>> ------- >>> Whereas the Vehicle-to-Internet technologies are considered complet= ed >>> and deployed in automobiles currently on the roads (e.g. car >>> tethering >>> through driver's cellular smartphone, live traffic data displayed o= n >>> the dashboard, - use of NAT/DHCP and potentially Mobile IP), the >>> Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are >>> still in an infancy stage: primitive link-specific data exchanges a= re >>> limited to a non-harmonized set of applications, such as ETSI's >>> CAM/DENM presence signalling; worse, some link-specific messages >>> exhibit behaviour assimilated to IP behaviour but the systems are >>> incompatible with the Internet without involving specific gatewayin= g. >>> The industry needs to employ IP data exchanges between vehicles, an= d >>> between vehicles and the immediate infrastructure, rather than >>> link-specific exchanges, in order to benefit from advantages such a= s >>> (1) short delays, (2) fast forwarding through short paths of dumb >>> routers (2) ease of reusing of a huge number of a desktop Internet >>> applications in a vehicular environment (extend the Internet to >>> mobile >>> platforms). >>> >> >> I think this paragraph take too long to get to the main point, which >> is >> why IP is a goog thing in this environment. I suggest: >> >> Today, there are several deployed Vehicle-to-Internet technologies, >> including car tethering through driver's cellular smartphone. >> However, >> Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are >> still >> being developed. To avoid link-specific data exchanges, and enable >> independent application sets to share the same links, IP data >> exchanges >> are needed. Enabling IP communication between vehicles (V2V), and >> between vehicles and the immediate infrastructure (V2I), will provid= e >> (1) short delays, (2) fast forwarding through short paths of routers= , >> (3) ease of reuse of existing Internet applications in a vehicular >> environment. >> >> >>> Moving network to moving network communications involve link layers >>> >> >> Add "nearby" here. I think it is important to the scope. >> >> such as: 802.11 OCB, 802.15.4 with 6lowpan, 802.11ac, VLC (Visible >>> Light Communications), IrDA, LTE-D. Only the IP protocols are >>> capable >>> >> >> s/802.11 OCB/802.11p OCB (Outside the Context of a BSS)/ >> >> of running on each of these links and establish IP paths across them >>> in an interoperable manner. >>> >>> Scenarios? >>> ---------- >>> There are a few scenarios exhibiting the need to communicate from o= ne >>> moving network to another nearby moving network. >>> >>> In the automobile space, the Cooperative Adaptive Cruise Control an= d >>> Platooning features consider that vehicles close to each other >>> exchange data describing their kinematic status. At the cross-road= s, >>> the moving network inside a vehicle exchanges data with the moving >>> network in the red-light pole. >>> >>> Several public safety scenarios involve moving networks. Distinct >>> organizations deploy different moving networks (in-vehicle, >>> on-person) >>> at an incident scene. These networks need to interoperate in order >>> to >>> more effectively understand and deal with the incident scene. >>> >>> In connected rail scenarios the moving network deployed in trains >>> communicate with other moving networks at the cross-points. >>> >>> What kind of solutions? >>> ----------------------- >>> The current technical solutions considered to achieve moving networ= k >>> to moving network communications are of two kinds: IP routing >>> >> >> Add "nearby" here. I think it is important to the scope. >> >> protocols for n-hop path management and 1-hop link-scoped IP protoco= l >>> enhancements. The 1-hop link-scoped protocols include the protocol= s >>> for route establishment involving ICMP Router Advertisements. The >>> n-hop path management protocols include n-hop path establishment >>> protocols (e.g. Babel, OSPF) and n-hop path search protocols (most >>> notably AODV and derivates). >>> >> >> My understanding from the phone call was that we were going to focus >> on the 1-hop >> protocols in this proposed working group, but leverage work from >> other groups for the >> n-hop situation. >> >> I think we need to say something here about the duration of some of >> the communications. >> a vehicle traveling at 80 Km/h is not going to have communications >> with a roadside >> device for very long. >> >> >>> What kind of requirements? >>> -------------------------- >>> The requirements for mechanisms for moving network to moving networ= k >>> >> >> Add "nearby" here. I think it is important to the scope. >> >> communications are focusing on low delays of the data paths, reduced >>> number of messages for path establishment, application friendly, >>> resilience to attacks, compatibility with DHCP and Mobile IP. >>> >>> In addition, some moving network to moving network applications >>> >> >> Add "nearby" here. I think it is important to the scope. >> >> involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the >>> 1-hop IP moving network to moving netowrk mechanisms will need to >>> gracefully support IP multicast. >>> >>> Due to the inherent characteristics of safety-related communication= s, >>> all new moving network to moving network mechanisms must afford >>> authenticity and confidentiality where necessary. Dynamically >>> establishing ephemeral communication paths between automobiles in >>> public areas must offer privacy safeguards for the end users >>> (passengers). >>> >>> Establishing 1-hop IP V2V paths must not break the existing on-boar= d >>> protocols and applications which communicate with the Internet, >>> possibly via multiple radios. >>> >>> In a moving network deployed in an automobile, typically one exit >>> point connects the moving network to other moving networks. However= , >>> in a more general manner (and to support reliability) any new >>> mechanism of moving network to moving network communications should >>> support multi-homing: one router to use multiple interfaces towards >>> outside the moving network, or multiple routers. >>> >>> Current version of Internet protocols >>> ------------------------------------- >>> The version of the IP protocol is IPv6 (witness 10% IPv6 penetratio= n >>> as of early 2016, mobile operators evolving to IPv6-only, governmen= t >>> IPv6 push, IPv4 exhaust at RIRs); this acommodates the current >>> generation of Internet protocols. For backwards compatibility, IPv= 4 >>> may be considered as well, but not exclusively. Link-local IPv6 >>> addresses will be used. >>> >> >> This it too long. Just say that the groups will only work on IPv6 >> solutions. >> >> >>> What SDOs may need this work? >>> ----------------------------- >>> The requirements and standards for moving network to moving network >>> communications, often involving IPv6, and novel V2V and V2Infra >>> concepts, are developed mainly at ISO TC204 "Intelligent Transport >>> Systems", 3GPP, ETSI, NHTSA and IEEE. For Vehicle-to-Internet >>> communications, 3GPP LTE and other cellular technologies represent >>> the >>> long-range connectivity method; for Vehicle-to-Vehicle >>> communications, >>> LTE Direct is currently specified, as well as OCB mode of IEEE >>> 802.11. >>> Several use-cases exhibit a need for IPv6 data exchanges between >>> vehicles: ETSI's Cooperative Adaptive Cruise Control and Platooning= . >>> The IEEE developed a popular link for short-range communications - >>> IEEE 802.11p "WAVE". The NHTSA wrote a set of requirements for V2V >>> communications. >>> >>> Work Items >>> ---------- >>> - use-cases for moving network to moving network communications >>> - Problem Statement for moving network to moving network >>> communications >>> - Security and Privacy Requirements for moving network to >>> moving network communications >>> - Problem Statement for moving network to infrastructure network >>> communications, including DNS >>> - Potentially new protocol, or protocol extensions for establishing >>> IP >>> paths for 1-hop moving network to moving network communications. >>> With MIB and security. >>> - IPv6-over foo, where foo is pertinent for moving network to movin= g >>> network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) >>> >>> Timeline >>> -------- >>> - >>> >>> _______________________________________________ >>> 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 >> >> >> --001a114b0d68566507052d8792dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alex,

Here is som= e a non-exhaustive list of some :
  • Proactive Vehicular Traffic Re-routing fo= r Lower Travel Time.
  • Reliable Inters= ection Protocols Using Vehicular Networks.
  • STIP: Spatio-Temporal Intersection Protocols for Autonomous Vehicles= .
  • Routing protocols in Vehicular Del= ay Tolerant Networks: A comprehensive survey.
  • Toward V2I Communication Technology-based Solution for Reducing R= oad Traffic Congestion in Smart Cities.
  • Sensing Traffic Density Combining V= 2V and V2IWireless Communications.
  • =
  • Efficient Macroscopic Urban Traffic Models f= or Reducing Congestion: a PDDL+ Planning Approach.
  • On Stochastic Analysis of Gr= eedy Routing in Vehicular Networks.
  • Balanced Traffic Routing: Design, Implement= ation, and Evaluation.
  • A Survey on Urban Traffic Management System Using Wirele= ss Sensor Networks.

    • Best regards
    Nabil Benamar
    --------= -----------
    =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88
    <= br>
    <= /div>

    On Mon, Mar 7, 2016 at 3:08 PM, Alexandre Pe= trescu <alexandre.petrescu@gmail.com> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

    Le 04/03/2016 17:33, Nabil Benamar a =C3=A9crit :
    Hi Alex, Russ and itsers,

    The charter looks good for me and it should be noted that a great amount of research papers are focusing on the benefits of car to car
    communication to solve some relevant issues.

     Do you have a list of such research papers?

    Alex

    Many strategies are
    proposed to proactively compute re-routing guidance to be pushed to
    vehicles when signs of congestion are observed on their route. This is
    beyond the safety issue as stated in the draft charter but it concerns a better driving experience !

    Other car manufacturers could be interested by the outcomes of this
    wg, especially when we think about Autonomous driving. Indeed, one of
    the main challenges of autonomous driving in urban areas is transition
    through cross-roads and intersections. In addition to safety concerns,
    current intersection management technologies such as stop signs and
    trafic lights can introduce significant trafic delays even under light
    trafic conditions.

    V2V and V2I can help avoiding deadlock situations
    and eventual collisions as well !

    Moreover, considering the importance of IPv6 deployment nowadays and all the possibilities and new technologies rising from it, our previous
    draft can be a good starting point and a work item for the WG:
    https://datatracker.ietf.org/doc/dr= aft-petrescu-ipv6-over-80211p/





    Best regards
    Nabil Benamar
    -------------------
    =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88

    http://nabilbenamar.ipv6-lab.net/

    On Wed, Feb 17, 2016 at 6:36 PM, Russ Housley <housley@vigilsec.com
     <mailto:housle= y@vigilsec.com>> wrote:

    =C2=A0 =C2=A0 Alex:

    =C2=A0 =C2=A0 Below are my comments on the proposed charter text.

    =C2=A0 =C2=A0 Russ



    =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=A0ITS (name to change)
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Charter
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0February 15th= , 2016
    =C2=A0 =C2=A0 http://ietf.org/mailman/listinfo/its


    =C2=A0 =C2=A0 Intelligent Transportation Systems (its)
    =C2=A0 =C2=A0 ----------------------------------------
    =C2=A0 =C2=A0 Current Status: WG forming

    =C2=A0 =C2=A0 Chairs:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD

    =C2=A0 =C2=A0 Assigned Area Director:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD

    =C2=A0 =C2=A0 Mailing list
     =C2=A0 =C2=A0 =C2=A0 =C2=A0Address: its@ietf.org <mailto:its@ietf.org>

    =C2=A0 =C2=A0 =C2=A0 =C2=A0To Subscribe: https://www.ietf.o= rg/mailman/listinfo/its
    =C2=A0 =C2=A0 =C2=A0 =C2=A0Archive:
    =C2=A0 =C2=A0 http://www.ietf.org/mail= -archive/web/its/current/maillist.html

    =C2=A0 =C2=A0 Additional web page
    =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD

    =C2=A0 =C2=A0 Charter:

    =C2=A0 =C2=A0 Goal
    =C2=A0 =C2=A0 ----
    =C2=A0 =C2=A0 The goal of this group is to standardize IP protocols for est= ablishing
    =C2=A0 =C2=A0 direct and secure connectivity between moving networks.

    =C2=A0 =C2=A0 Moving Network to Moving Network Communications
    =C2=A0 =C2=A0 -----------------------------------------------
    =C2=A0 =C2=A0 The group is concerned with all situations involving moving n= etwork to
    =C2=A0 =C2=A0 moving network communications.=C2=A0 For example: vehicle-to-= vehicle
    =C2=A0 =C2=A0 communications, nomadic user wearing a PAN and communicating = to a
    =C2=A0 =C2=A0 homenet, vehicle-to-infrastructure communications, wagon-to-w= agon in a
    =C2=A0 =C2=A0 train, or train-to-intersection signalling.

    =C2=A0 =C2=A0 Example from the automobile communications space
    =C2=A0 =C2=A0 ------------------------------------------------
    =C2=A0 =C2=A0 Automobiles and vehicles of all types are increasingly connec= ted to
    =C2=A0 =C2=A0 the Internet.=C2=A0 Entertainment apps enhancing comfort, rel= iable data
    =C2=A0 =C2=A0 exchanges for road safety, and automated driving, are commonl= y seen as

    =C2=A0 =C2=A0 Editorial:=C2=A0 s/automated driving, are/automated driving a= re/

    =C2=A0 =C2=A0 winning sale arguments for automobiles to hit the roads from = now to
    =C2=A0 =C2=A0 year 2020.=C2=A0 Emergency apps for new instrumented ambulanc= es carry many
    =C2=A0 =C2=A0 benefits both to the users and to society in general.

    =C2=A0 =C2=A0 I think that the "winning sales arguments" is not n= eeded here.
    =C2=A0 =C2=A0 Instead, I think it
    =C2=A0 =C2=A0 would be valuable to say that these features are coming, and = that
    =C2=A0 =C2=A0 the safety
    =C2=A0 =C2=A0 features are expected to become required.


    =C2=A0 =C2=A0 Why IP?
    =C2=A0 =C2=A0 -------
    =C2=A0 =C2=A0 Whereas the Vehicle-to-Internet technologies are considered c= ompleted
    =C2=A0 =C2=A0 and deployed in automobiles currently on the roads (e.g. car = tethering
    =C2=A0 =C2=A0 through driver's cellular smartphone, live traffic data d= isplayed on
    =C2=A0 =C2=A0 the dashboard, - use of NAT/DHCP and potentially Mobile IP), = the
    =C2=A0 =C2=A0 Vehicle-to-Vehicle and Vehicle-to-Infrastructure communicatio= ns are
    =C2=A0 =C2=A0 still in an infancy stage: primitive link-specific data excha= nges are
    =C2=A0 =C2=A0 limited to a non-harmonized set of applications, such as ETSI= 's
    =C2=A0 =C2=A0 CAM/DENM presence signalling; worse, some link-specific messa= ges
    =C2=A0 =C2=A0 exhibit behaviour assimilated to IP behaviour but the systems= are
    =C2=A0 =C2=A0 incompatible with the Internet without involving specific gat= ewaying.
    =C2=A0 =C2=A0 The industry needs to employ IP data exchanges between vehicl= es, and
    =C2=A0 =C2=A0 between vehicles and the immediate infrastructure, rather tha= n
    =C2=A0 =C2=A0 link-specific exchanges, in order to benefit from advantages = such as
    =C2=A0 =C2=A0 (1) short delays, (2) fast forwarding through short paths of = dumb
    =C2=A0 =C2=A0 routers (2) ease of reusing of a huge number of a desktop Int= ernet
    =C2=A0 =C2=A0 applications in a vehicular environment (extend the Internet = to mobile
    =C2=A0 =C2=A0 platforms).

    =C2=A0 =C2=A0 I think this paragraph take too long to get to the main point= , which is
    =C2=A0 =C2=A0 why IP is a goog thing in this environment.=C2=A0 I suggest:<= br>
    =C2=A0 =C2=A0 Today, there are several deployed Vehicle-to-Internet technol= ogies,
    =C2=A0 =C2=A0 including car tethering through driver's cellular smartph= one.=C2=A0 However,
    =C2=A0 =C2=A0 Vehicle-to-Vehicle and Vehicle-to-Infrastructure communicatio= ns are
    =C2=A0 =C2=A0 still
    =C2=A0 =C2=A0 being developed.=C2=A0 To avoid link-specific data exchanges,= and enable
    =C2=A0 =C2=A0 independent application sets to share the same links, IP data= exchanges
    =C2=A0 =C2=A0 are needed.=C2=A0 Enabling IP communication between vehicles = (V2V), and
    =C2=A0 =C2=A0 between vehicles and the immediate infrastructure (V2I), will= provide
    =C2=A0 =C2=A0 (1) short delays, (2) fast forwarding through short paths of = routers,
    =C2=A0 =C2=A0 (3) ease of reuse of existing Internet applications in a vehi= cular
    =C2=A0 =C2=A0 environment.


    =C2=A0 =C2=A0 Moving network to moving network communications involve link = layers

    =C2=A0 =C2=A0 Add "nearby" here.=C2=A0 I think it is important to= the scope.

    =C2=A0 =C2=A0 such as: 802.11 OCB, 802.15.4 with 6lowpan, 802.11ac, VLC (Vi= sible
    =C2=A0 =C2=A0 Light Communications), IrDA, LTE-D.=C2=A0 Only the IP protoco= ls are capable

    =C2=A0 =C2=A0 s/802.11 OCB/802.11p OCB (Outside the Context of a BSS)/

    =C2=A0 =C2=A0 of running on each of these links and establish IP paths acro= ss them
    =C2=A0 =C2=A0 in an interoperable manner.

    =C2=A0 =C2=A0 Scenarios?
    =C2=A0 =C2=A0 ----------
    =C2=A0 =C2=A0 There are a few scenarios exhibiting the need to communicate = from one
    =C2=A0 =C2=A0 moving network to another nearby moving network.

    =C2=A0 =C2=A0 In the automobile space, the Cooperative Adaptive Cruise Cont= rol and
    =C2=A0 =C2=A0 Platooning features consider that vehicles close to each othe= r
    =C2=A0 =C2=A0 exchange data describing their kinematic status.=C2=A0 At the= cross-roads,
    =C2=A0 =C2=A0 the moving network inside a vehicle exchanges data with the m= oving
    =C2=A0 =C2=A0 network in the red-light pole.

    =C2=A0 =C2=A0 Several public safety scenarios involve moving networks.=C2= =A0 Distinct
    =C2=A0 =C2=A0 organizations deploy different moving networks (in-vehicle, o= n-person)
    =C2=A0 =C2=A0 at an incident scene.=C2=A0 These networks need to interopera= te in order to
    =C2=A0 =C2=A0 more effectively understand and deal with the incident scene.=

    =C2=A0 =C2=A0 In connected rail scenarios the moving network deployed in tr= ains
    =C2=A0 =C2=A0 communicate with other moving networks at the cross-points.
    =C2=A0 =C2=A0 What kind of solutions?
    =C2=A0 =C2=A0 -----------------------
    =C2=A0 =C2=A0 The current technical solutions considered to achieve moving = network
    =C2=A0 =C2=A0 to moving network communications are of two kinds: IP routing=

    =C2=A0 =C2=A0 Add "nearby" here.=C2=A0 I think it is important to= the scope.

    =C2=A0 =C2=A0 protocols for n-hop path management and 1-hop link-scoped IP = protocol
    =C2=A0 =C2=A0 enhancements.=C2=A0 The 1-hop link-scoped protocols include t= he protocols
    =C2=A0 =C2=A0 for route establishment involving ICMP Router Advertisements.= =C2=A0 The
    =C2=A0 =C2=A0 n-hop path management protocols include n-hop path establishm= ent
    =C2=A0 =C2=A0 protocols (e.g. Babel, OSPF) and n-hop path search protocols = (most
    =C2=A0 =C2=A0 notably AODV and derivates).

    =C2=A0 =C2=A0 My understanding from the phone call was that we were going t= o focus
    =C2=A0 =C2=A0 on the 1-hop
    =C2=A0 =C2=A0 protocols in this proposed working group, but leverage work f= rom
    =C2=A0 =C2=A0 other groups for the
    =C2=A0 =C2=A0 n-hop situation.

    =C2=A0 =C2=A0 I think we need to say something here about the duration of s= ome of
    =C2=A0 =C2=A0 the communications.
    =C2=A0 =C2=A0 a vehicle traveling at 80 Km/h is not going to have communica= tions
    =C2=A0 =C2=A0 with a roadside
    =C2=A0 =C2=A0 device for very long.


    =C2=A0 =C2=A0 What kind of requirements?
    =C2=A0 =C2=A0 --------------------------
    =C2=A0 =C2=A0 The requirements for mechanisms for moving network to moving = network

    =C2=A0 =C2=A0 Add "nearby" here.=C2=A0 I think it is important to= the scope.

    =C2=A0 =C2=A0 communications are focusing on low delays of the data paths, = reduced
    =C2=A0 =C2=A0 number of messages for path establishment, application friend= ly,
    =C2=A0 =C2=A0 resilience to attacks, compatibility with DHCP and Mobile IP.=

    =C2=A0 =C2=A0 In addition, some moving network to moving network applicatio= ns

    =C2=A0 =C2=A0 Add "nearby" here.=C2=A0 I think it is important to= the scope.

    =C2=A0 =C2=A0 involve IP multicast mechanisms (e.g. virtual siren); thus C-= ACC the
    =C2=A0 =C2=A0 1-hop IP moving network to moving netowrk mechanisms will nee= d to
    =C2=A0 =C2=A0 gracefully support IP multicast.

    =C2=A0 =C2=A0 Due to the inherent characteristics of safety-related communi= cations,
    =C2=A0 =C2=A0 all new moving network to moving network mechanisms must affo= rd
    =C2=A0 =C2=A0 authenticity and confidentiality where necessary.=C2=A0 Dynam= ically
    =C2=A0 =C2=A0 establishing ephemeral communication paths between automobile= s in
    =C2=A0 =C2=A0 public areas must offer privacy safeguards for the end users<= br> =C2=A0 =C2=A0 (passengers).

    =C2=A0 =C2=A0 Establishing 1-hop IP V2V paths must not break the existing o= n-board
    =C2=A0 =C2=A0 protocols and applications which communicate with the Interne= t,
    =C2=A0 =C2=A0 possibly via multiple radios.

    =C2=A0 =C2=A0 In a moving network deployed in an automobile, typically one = exit
    =C2=A0 =C2=A0 point connects the moving network to other moving networks. H= owever,
    =C2=A0 =C2=A0 in a more general manner (and to support reliability) any new=
    =C2=A0 =C2=A0 mechanism of moving network to moving network communications = should
    =C2=A0 =C2=A0 support multi-homing: one router to use multiple interfaces t= owards
    =C2=A0 =C2=A0 outside the moving network, or multiple routers.

    =C2=A0 =C2=A0 Current version of Internet protocols
    =C2=A0 =C2=A0 -------------------------------------
    =C2=A0 =C2=A0 The version of the IP protocol is IPv6 (witness 10% IPv6 pene= tration
    =C2=A0 =C2=A0 as of early 2016, mobile operators evolving to IPv6-only, gov= ernment
    =C2=A0 =C2=A0 IPv6 push, IPv4 exhaust at RIRs); this acommodates the curren= t
    =C2=A0 =C2=A0 generation of Internet protocols.=C2=A0 For backwards compati= bility, IPv4
    =C2=A0 =C2=A0 may be considered as well, but not exclusively.=C2=A0 Link-lo= cal IPv6
    =C2=A0 =C2=A0 addresses will be used.

    =C2=A0 =C2=A0 This it too long.=C2=A0 Just say that the groups will only wo= rk on IPv6
    =C2=A0 =C2=A0 solutions.


    =C2=A0 =C2=A0 What SDOs may need this work?
    =C2=A0 =C2=A0 -----------------------------
    =C2=A0 =C2=A0 The requirements and standards for moving network to moving n= etwork
    =C2=A0 =C2=A0 communications, often involving IPv6, and novel V2V and V2Inf= ra
    =C2=A0 =C2=A0 concepts, are developed mainly at ISO TC204 "Intelligent= Transport
    =C2=A0 =C2=A0 Systems", 3GPP, ETSI, NHTSA and IEEE.=C2=A0 For Vehicle-= to-Internet
    =C2=A0 =C2=A0 communications, 3GPP LTE and other cellular technologies repr= esent the
    =C2=A0 =C2=A0 long-range connectivity method; for Vehicle-to-Vehicle commun= ications,
    =C2=A0 =C2=A0 LTE Direct is currently specified, as well as OCB mode of IEE= E 802.11.
    =C2=A0 =C2=A0 Several use-cases exhibit a need for IPv6 data exchanges betw= een
    =C2=A0 =C2=A0 vehicles: ETSI's Cooperative Adaptive Cruise Control and = Platooning.
    =C2=A0 =C2=A0 The IEEE developed a popular link for short-range communicati= ons -
    =C2=A0 =C2=A0 IEEE 802.11p "WAVE".=C2=A0 The NHTSA wrote a set of= requirements for V2V
    =C2=A0 =C2=A0 communications.

    =C2=A0 =C2=A0 Work Items
    =C2=A0 =C2=A0 ----------
    =C2=A0 =C2=A0 - use-cases for moving network to moving network communicatio= ns
    =C2=A0 =C2=A0 - Problem Statement for moving network to moving network
    =C2=A0 =C2=A0 communications
    =C2=A0 =C2=A0 - Security and Privacy Requirements for moving network to
    =C2=A0 =C2=A0 =C2=A0 moving network communications
    =C2=A0 =C2=A0 - Problem Statement for moving network to infrastructure netw= ork
    =C2=A0 =C2=A0 =C2=A0 communications, including DNS
    =C2=A0 =C2=A0 - Potentially new protocol, or protocol extensions for establ= ishing IP
    =C2=A0 =C2=A0 =C2=A0 paths for 1-hop moving network to moving network commu= nications.
    =C2=A0 =C2=A0 =C2=A0 With MIB and security.
    =C2=A0 =C2=A0 - IPv6-over foo, where foo is pertinent for moving network to= moving
    =C2=A0 =C2=A0 =C2=A0 network communications (e.g. 802.11 OCB, VLC, LTE-D, 8= 02.11ad)

    =C2=A0 =C2=A0 Timeline
    =C2=A0 =C2=A0 --------
    =C2=A0 =C2=A0 -

    =C2=A0 =C2=A0 _______________________________________________
    =C2=A0 =C2=A0 its mailing list
    =C2=A0 =C2=A0 its@ietf.or= g <mailto:its@ietf= .org>
    =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/its=


    =C2=A0 =C2=A0 _______________________________________________
    =C2=A0 =C2=A0 its mailing list
    =C2=A0 =C2=A0 its@ietf.or= g <mailto:its@ietf= .org>
    =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/its=



    --001a114b0d68566507052d8792dc-- From nobody Wed Mar 9 09:39:44 2016 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 4F16812D8A0 for ; Wed, 9 Mar 2016 09:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGk1WoP6_jNO for ; Wed, 9 Mar 2016 09:39:36 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::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 8472012D84E for ; Wed, 9 Mar 2016 09:38:25 -0800 (PST) Received: by mail-ob0-x22b.google.com with SMTP id ts10so54365009obc.1 for ; Wed, 09 Mar 2016 09:38:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=uYwmjryZh8aJB9X0XtOJUZGo8FdELEhpC+ik8Bo2LJw=; b=PBRnZueW++zG86oyCtPo6hlN5eE4TcH0xaM6xdYpixOgOqH5vVEjuuStNb8taWH7mE Rg8RQfDyQ6kas+yB3i6m7vUIl2RNQZtC160uH/VNEyBrup76JachqOTckww3lTLuMxGr eqAuA8C2pX8C+SHIpc0WJ2fWBAOyldtzsf50MRYNz8o06UtHcgUQH2mxjl9J8OJwOMPw KieNixKy08Dr3VDtUkkoteY+HovSNzDgailwCOTOfMcYB9n5+cDiC/YEl+2UBApL8U2F 83/h5irDV+7VM39pjGfWbKK5Xl8fmaEpjDlaJ3aKqVss/bHMi+Pc2l2UG7BfN/gAS8GE uV7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=uYwmjryZh8aJB9X0XtOJUZGo8FdELEhpC+ik8Bo2LJw=; b=VPNbUmhIowLjl8FRHmkvcXqQPqVbHpUFyEcU3R0U+lGmVz0367RgZNHrQtkB1MWtV3 17c8yO6WcU4kBLqFmNDEhpgUDlpMXctj7bAIElvBR0f6Ga6UGXAu+gBrQTX2qWAI2JEO 67dIn9Ik4UpI9JHHYLmwFSSnM5y89OAEThDUbfjYlR2jTXqrF/pKfjj+1/Iv30r1jPj2 ILAOQxeYJ/GzRG/nhsO1h2b2RH2S9UHyP/5aBnNnnJml82mZudo9H0dXE/Pw5FtPynlt vPRj5CBri+GcIsMHpSky+HCXWFZ3GbqRfrqEPAasVbN0OTlQ+mOWRpBsoeClpW/Xc+nz JUrQ== X-Gm-Message-State: AD7BkJLfQxm+RFEPaeiA4LL+xWOWa9o34qx/FAeVPE2BJlsTOfX+jfHDYnBsWW2Nqw1zPyOGujNvWjseW3m6uw== X-Received: by 10.60.39.105 with SMTP id o9mr18977518oek.31.1457545104983; Wed, 09 Mar 2016 09:38:24 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dapeng Liu Date: Wed, 09 Mar 2016 17:38:15 +0000 Message-ID: To: Russ Housley , its@ietf.org Content-Type: multipart/alternative; boundary=089e013cc0403a2468052da12a6d Archived-At: Subject: Re: [its] ITS BOF in Buenos Aires at IETF 95 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 17:39:41 -0000 --089e013cc0403a2468052da12a6d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Russ=EF=BC=8C Thanks for your help and guidance. Best regards=EF=BC=8C Dapeng Liu Russ Housley =E4=BA=8E2016=E5=B9=B43=E6=9C=888=E6=97= =A5=E6=98=9F=E6=9C=9F=E4=BA=8C 07:50=E5=86=99=E9=81=93=EF=BC=9A > The IESG has approved a BOF slot for ITS, and the draft agenda is out: > > https://datatracker.ietf.org/meeting/95/agenda > (search for "its") > > I hope to see you there, > Russ > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --089e013cc0403a2468052da12a6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    Hi Russ=EF=BC=8C

    Thanks for your help and guidance.

    Best regards=EF=BC=8C
    Dapeng Liu


    Russ Housley <housley@vigilsec.com>=E4=BA=8E2016=E5= =B9=B43=E6=9C=888=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C 07:50=E5=86=99=E9=81= =93=EF=BC=9A
    =20
    = The IESG has approved a BOF slot for ITS, and th= e draft agenda is out:

    https://datatracker.ietf.org/meeting/95/age= nda
    (search for "its")

    I hope to see you there,
    =C2=A0 Russ
    __= _____________________________________________
    its mailing list
    its@ietf.org
    https://www.ietf.org/mailman/listinfo/its
    --089e013cc0403a2468052da12a6d-- From nobody Fri Mar 11 09:36:43 2016 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 3D94F12D716 for ; Fri, 11 Mar 2016 09:36:41 -0800 (PST) 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_KAM_HTML_FONT_INVALID=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 Wt9SKFDCoo1z for ; Fri, 11 Mar 2016 09:36:38 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 5739A12D5D7 for ; Fri, 11 Mar 2016 09:36:37 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id l68so26686750wml.1 for ; Fri, 11 Mar 2016 09:36:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=7PppVRzVBdkU2+jv/UlSN+fbY1b82X3sp+iJu1VghEk=; b=ABdHCrO7MoGuPhm4C3QGz1LhfW8vFaIIplpy0xMtHS46hIpvL2SIY/XZK8peZOLhMP pBiKDANh9Im+3tjYe7JVoIsxX3WjNGoXoBbWaVqlXCXNoya0WbeI0QYldimMg8J5coAX ++pb+NH9cDu0Roc4EECZZfuAFlNpO8zv66FK/qUnqQ9DbDK+1bEkbfjb0NpQq73hYc/l 5rnA+weMICIuhuadd3es3a8IM4AJf1Sk4nHxnIPDrYTzHhYLx0za8HERtlw82T1V0v5A ZDd5DjfTcChl6WMfD8uOUJYGeX6xodX9xTHUi7npi3GQRpNmzFYvveU+ulwhWzic8l+g NzpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=7PppVRzVBdkU2+jv/UlSN+fbY1b82X3sp+iJu1VghEk=; b=TQVPMCKk86qSu7FXWDLuKmbLOddDhSsXrNMzXkDXaBZRE/g48WaqhUooI2pgftDVOI OEzR/7uqMKVeWaZW+2SIw6VxeyBtdpLQatfWdY99P1At7Mf3WoMfRam+zxodytDeuFxD BdecRfmF72kstzxb/cTc/np3XvZQhyTBDWIshQezc7qWEj/qGmtudPG0QNC59AFau59L YWsVOKpJGBene0pC6ZKfgL4ONyhAFjBiVpA14cL6lrhMbijO/++l8J3NhzUJ4gDGGbza pDhhwpFfkvZkGD+hsO/6irtGf10EHGSGksJlqs76wyUSIjJi46lepm39UZI2jgVkB0Lj UsiQ== X-Gm-Message-State: AD7BkJKIXKx1LKrBjhYztTrNrln2dmDr0GBtC//jvhshoqT9LBOjAbFQEdvgYB1TcysixQ== X-Received: by 10.194.205.103 with SMTP id lf7mr10926751wjc.147.1457717795831; Fri, 11 Mar 2016 09:36:35 -0800 (PST) Received: from [172.22.175.139] ([46.218.58.213]) by smtp.gmail.com with ESMTPSA id e4sm3283066wma.10.2016.03.11.09.36.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 11 Mar 2016 09:36:35 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_9D92A572-A15C-4251-B5E9-134F762D4FDD" From: Jong-Hyouk Lee In-Reply-To: Date: Fri, 11 Mar 2016 18:36:34 +0100 Message-Id: <2BCA8442-92A9-4F38-A6A6-372573D256B3@gmail.com> References: <56C75EEA.6010506@gmail.com> To: Arnaud KAISER X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Alexandre Petrescu , "its@ietf.org" Subject: Re: [its] Updated charter (small correction) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 17:36:41 -0000 --Apple-Mail=_9D92A572-A15C-4251-B5E9-134F762D4FDD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Arnaud Any update regarding the new work item related to privacy at ETSI WG5 ? Cheers. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Feb 25, 2016, at 3:04 PM, Arnaud KAISER = wrote: >=20 > Dear ITSers, > =20 > Concerning privacy aspects in ITS, I would like to inform you that = ETSI WG5 (security and privacy WG) started a work item related to = privacy. More precisely, the WI focus on pseudonym change strategies. = Pseudonyms are used by ITS stations (vehicles, roadside units, etc.) to = identify each other without revealing their true identity. This to = protect private data and also to avoid attacks like tracking of vehicles = for example. > =20 > This aspect may be interesting to study in the context of IPv6 moving = networks. > =20 > > Dr. Arnaud Kaiser > Research Engineer > Institut de Recherche Technologique SystemX > 8, Avenue de la Vauve > 91120 Palaiseau =E2=80=93 FRANCE > =20 > =20 > De : its [mailto:its-bounces@ietf.org] De la part de Alexandre = Petrescu > Envoy=C3=A9 : vendredi 19 f=C3=A9vrier 2016 19:29 > =C3=80 : its@ietf.org > Objet : [its] Updated charter (small correction) > =20 > Updated charter to refer to in the BoF request. >=20 > Alex >=20 >=20 > --------------------------------------------------------------- > ITS (name to change) > Charter > February 19th, 2016 > http://ietf.org/mailman/listinfo/its = >=20 >=20 > Intelligent Transportation Systems (its) > ---------------------------------------- > Current Status: WG forming >=20 > Chairs: > TBD >=20 > Assigned Area Director: > TBD >=20 > Mailing list > Address: its@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/its = > Archive: > http://www.ietf.org/mail-archive/web/its/current/maillist.html = >=20 > Additional web page > TBD >=20 > Charter: >=20 > Goal > ---- > The goal of this group is to standardize IP protocols for establishing > direct and secure connectivity between moving networks. >=20 > Moving Network to Nearby Moving Network Communications > ------------------------------------------------------ > The group is concerned with all situations involving moving network to > nearby moving network communications. For example: vehicle-to-vehicle > communications, nomadic user wearing a PAN and communicating to a > homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a > train, or train-to-intersection signalling. >=20 > Example from the automobile communications space > ------------------------------------------------ > Automobiles and vehicles of all types are increasingly connected to > the Internet. Entertainment apps enhancing comfort, reliable data > exchanges for road safety, and automated driving are features coming > in automobiles to hit the roads from now to year 2020. Highlighting > increased safety as an immediate result of hyper-connectivity applied > to vehicles, public authorities worldwide are increasingly mandating > communication technology requirements in vehicles. >=20 > Emergency apps for new instrumented ambulances carry many benefits > both to the users and to society in general. >=20 > Why IP? > ------- > Today, there are several deployed Vehicle-to-Internet technologies, > including car tethering through driver's cellular smartphone. > However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure > communications are still being developed. To improve on a situation > of link-specific data exchanges, and enable independent application > sets to share the same links, IP data exchanges are needed. Enabling > IP communication between vehicles (V2V), and between vehicles and the > immediate infrastructure (V2I), will provide (0) ability to reach the > rest of the world on the Internet (1) short and deterministic delays, > (2) fast forwarding through scalable paths of routers, (3) ease of > reuse of existing Internet applications in a vehicular environment. >=20 > Moving network to nearby moving network communications involve link > layers such as: 802.11p OCB (Outside the Context of a Basic Service > Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light > Communications), IrDA, LTE-D. Only the IP protocols are capable of > running on each of these links and establish IP paths across them in > an interoperable manner. >=20 > Scenarios? > ---------- > There are a few scenarios exhibiting the need to communicate from one > moving network to another nearby moving network. >=20 > In the automobile space, the Cooperative Adaptive Cruise Control and > Platooning features consider that vehicles close to each other > exchange data describing their kinematic status. At the cross-roads, > the moving network inside a vehicle exchanges data with the moving > network in the red-light pole. >=20 > Several public safety scenarios involve moving networks. Distinct > organizations deploy different moving networks (in-vehicle, on-person) > at an incident scene. These networks need to interoperate in order to > more effectively understand and deal with the incident scene. >=20 > In connected rail scenarios the moving network deployed in trains > communicate with other moving networks at the cross-points. >=20 > What kind of solutions? > ----------------------- > The current technical solutions considered to achieve moving network > to nearby moving network communications are of two kinds: IP routing > protocols for n-hop path management and 1-hop link-scoped IP protocol > enhancements. The 1-hop link-scoped protocols include the protocols > for route establishment involving ICMP Router Advertisements. The > n-hop path management protocols include n-hop path establishment > protocols (e.g. Babel, OSPF) and n-hop path search protocols (most > notably AODV and derivates). >=20 > In this proposed Working Group the focus is on 1-hop protocols, and > leverage from other Working Groups for the n-hop situations. >=20 > In some of the moving network applications the window of opportunity > for exchanging data with the immediate infrastructure may be very > short. For example, a car driving near a road-side unit may have only > 5s to exchange with that RSU (depending on speed, RSU range and > number). (ephemeral connections). >=20 > What kind of requirements? > -------------------------- > The requirements for mechanisms for moving network to nearby moving > network communications are focusing on low delays of the data paths, > reduced number of messages for path establishment, application > friendly, resilience to attacks, compatibility with DHCP and Mobile > IP. >=20 > In addition, some moving network to nearby moving network applications > involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the > 1-hop IP moving network to nearby moving netowrk mechanisms will need > to gracefully support IP multicast. >=20 > Due to the inherent characteristics of safety-related communications, > all new moving network to nearby moving network mechanisms must afford > authenticity and confidentiality where necessary. Dynamically > establishing ephemeral communication paths between automobiles in > public areas must offer privacy safeguards for the end users > (passengers). >=20 > Establishing 1-hop IP V2V paths must not break the existing on-board > protocols and applications which communicate with the Internet, > possibly via multiple radios. >=20 > In a moving network deployed in an automobile, typically one exit > point connects the moving network to other moving networks. However, > in a more general manner (and to support reliability) any new > mechanism of moving network to nearby moving network communications > should support multi-homing: one router to use multiple interfaces > towards outside the moving network, or multiple routers. >=20 > Current version of Internet protocols > ------------------------------------- > The group will only work on IPv6 solutions. >=20 > What SDOs may need this work? > ----------------------------- > The requirements and standards for moving network to nearby moving > network communications, often involving IPv6, and novel V2V and > V2Infra concepts, are developed mainly at ISO TC204 "Intelligent > Transport Systems", 3GPP, ETSI, NHTSA and IEEE. For > Vehicle-to-Internet communications, 3GPP LTE and other cellular > technologies represent the long-range connectivity method; for > Vehicle-to-Vehicle communications, LTE Direct is currently specified, > as well as OCB mode of IEEE 802.11. Several use-cases exhibit a need > for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive > Cruise Control and Platooning. The IEEE developed a popular link for > short-range communications - IEEE 802.11p "WAVE". The NHTSA wrote a > set of requirements for V2V communications. >=20 > Work Items > ---------- > - use-cases for moving network to nearby moving network communications > - Problem Statement for moving network to nearby moving network = communications > - Security and Privacy Requirements for moving network to > nearby moving network communications > - Problem Statement for moving network to infrastructure network > communications, including DNS > - Potentially new protocol, or protocol extensions for establishing IP > paths for 1-hop moving network to nearby moving network = communications. > With MIB and security. > - IPv6-over foo, where foo is pertinent for moving network to nearby > moving network communications (e.g. 802.11 OCB, VLC, LTE-D, = 802.11ad) >=20 > Timeline > -------- > - >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --Apple-Mail=_9D92A572-A15C-4251-B5E9-134F762D4FDD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Arnaud

    Any update regarding the new work item related to privacy at = ETSI WG5 ?

    Cheers.
    --
    Jong-Hyouk Lee, living somewhere between /dev/null = and /dev/random
    Protocol Engineering Lab., = Sangmyung University

    #email: jonghyouk@gmail.com
    #webpage: https://sites.google.com/site/hurryon

    On Feb 25, 2016, at 3:04 PM, Arnaud KAISER <Arnaud.KAISER@irt-systemx.fr> wrote:

    Dear ITSers,
     
    Concerning privacy = aspects in ITS, I would like to inform you that ETSI WG5 (security and = privacy WG) started a work item related to privacy. More precisely, the = WI focus on pseudonym change strategies. Pseudonyms are used by ITS = stations (vehicles, roadside units, etc.) to identify each other without = revealing their true identity. This to protect private data and also to = avoid attacks like tracking of vehicles for example.
     
    This aspect may be = interesting to study in the context of IPv6 moving networks.
     
    <image001.png>
    Dr.= Arnaud Kaiser
    Research Engineer
    Institut de Recherche Technologique SystemX
    8, Avenue de la Vauve
    91120 Palaiseau =E2=80=93 = FRANCE
     
     
    De : its [mailto:its-bounces@ietf.org] De la part = de Alexandre = Petrescu
    Envoy=C3=A9 : vendredi 19 f=C3=A9vrier = 2016 19:29
    =C3=80 : its@ietf.org
    Objet : [its] Updated charter = (small correction)
     

    Updated charter to refer to in the BoF request.

    Alex


    ---------------------------------------------------------------=
              &nb= sp;  ITS (name to change)
              &nb= sp;        Charter
              &nb= sp;  February 19th, 2016
                 http://ietf.org/mailman/listinfo/its


    Intelligent Transportation Systems (its)
    ----------------------------------------
    Current = Status: WG forming

    Chairs:
       TBD

    Assigned Area = Director:
       TBD

    Mailing list
       Address:     its@ietf.org
       To Subscribe:     https://www.ietf.org/mailman/listinfo/its
       Archive:
           http://www.ietf.org/mail-archive/web/its/current/maillist.html<= /span>

    Additional web page
       = TBD

    Charter:

    Goal
    ----
    The goal of this group = is to standardize IP protocols for establishing
    direct and = secure connectivity between moving networks.

    Moving Network to Nearby Moving Network Communications
    ------------------------------------------------------
    The group is concerned with all situations involving moving = network to
    nearby moving network communications.  For = example: vehicle-to-vehicle
    communications, nomadic user = wearing a PAN and communicating to a
    homenet, = vehicle-to-infrastructure communications, wagon-to-wagon in a
    train, or train-to-intersection signalling.

    Example from the automobile communications space
    ------------------------------------------------
    Automobiles and vehicles of all types are increasingly = connected to
    the Internet.  Entertainment apps = enhancing comfort, reliable data
    exchanges for road = safety, and automated driving are features coming
    in = automobiles to hit the roads from now to year 2020.  = Highlighting
    increased safety as an immediate result of = hyper-connectivity applied
    to vehicles, public authorities = worldwide are increasingly mandating
    communication = technology requirements in vehicles.

    Emergency apps for new instrumented ambulances carry many = benefits
    both to the users and to society in general.

    Why IP?
    -------
    Today, there are several deployed Vehicle-to-Internet = technologies,
    including car tethering through driver's = cellular smartphone.
    However, Vehicle-to-Vehicle and = Vehicle-to-Infrastructure
    communications are still being = developed.  To improve on a situation
    of = link-specific data exchanges, and enable independent application
    sets to share the same links, IP data exchanges are = needed.  Enabling
    IP communication between vehicles = (V2V), and between vehicles and the
    immediate = infrastructure (V2I), will provide (0) ability to reach the
    rest of the world on the Internet (1) short and deterministic = delays,
    (2) fast forwarding through scalable paths of = routers, (3) ease of
    reuse of existing Internet = applications in a vehicular environment.

    Moving network to nearby moving network communications = involve link
    layers such as: 802.11p OCB (Outside the = Context of a Basic Service
    Set), 802.15.4 with 6lowpan, = 802.11ac, VLC (Visible Light
    Communications), IrDA, = LTE-D.  Only the IP protocols are capable of
    running = on each of these links and establish IP paths across them in
    an interoperable manner.

    Scenarios?
    ----------
    There are a = few scenarios exhibiting the need to communicate from one
    moving network to another nearby moving network.

    In the automobile space, the Cooperative = Adaptive Cruise Control and
    Platooning features consider = that vehicles close to each other
    exchange data describing = their kinematic status.  At the cross-roads,
    the = moving network inside a vehicle exchanges data with the moving
    network in the red-light pole.

    Several public safety scenarios involve moving = networks.  Distinct
    organizations deploy different = moving networks (in-vehicle, on-person)
    at an incident = scene.  These networks need to interoperate in order to
    more effectively understand and deal with the incident = scene.

    In connected rail scenarios the = moving network deployed in trains
    communicate with other = moving networks at the cross-points.

    What = kind of solutions?
    -----------------------
    The= current technical solutions considered to achieve moving network
    to nearby moving network communications are of two kinds: IP = routing
    protocols for n-hop path management and 1-hop = link-scoped IP protocol
    enhancements.  The 1-hop = link-scoped protocols include the protocols
    for route = establishment involving ICMP Router Advertisements.  The
    n-hop path management protocols include n-hop path = establishment
    protocols (e.g. Babel, OSPF) and n-hop path = search protocols (most
    notably AODV and derivates).

    In this proposed Working Group the focus is on = 1-hop protocols, and
    leverage from other Working Groups = for the n-hop situations.

    In some of the = moving network applications the window of opportunity
    for = exchanging data with the immediate infrastructure may be very
    short.  For example, a car driving near a road-side unit = may have only
    5s to exchange with that RSU (depending on = speed, RSU range and
    number). (ephemeral connections).

    What kind of requirements?
    --------------------------
    The requirements for = mechanisms for moving network to nearby moving
    network = communications are focusing on low delays of the data paths,
    reduced number of messages for path establishment, = application
    friendly, resilience to attacks, compatibility = with DHCP and Mobile
    IP.

    In = addition, some moving network to nearby moving network applications
    involve IP multicast mechanisms (e.g. virtual siren); thus = C-ACC the
    1-hop IP moving network to nearby moving netowrk = mechanisms will need
    to gracefully support IP = multicast.

    Due to the inherent = characteristics of safety-related communications,
    all new = moving network to nearby moving network mechanisms must afford
    authenticity and confidentiality where necessary.  = Dynamically
    establishing ephemeral communication paths = between automobiles in
    public areas must offer privacy = safeguards for the end users
    (passengers).
    Establishing 1-hop IP V2V paths must not break the existing = on-board
    protocols and applications which communicate with = the Internet,
    possibly via multiple radios.

    In a moving network deployed in an automobile, = typically one exit
    point connects the moving network to = other moving networks.  However,
    in a more general = manner (and to support reliability) any new
    mechanism of = moving network to nearby moving network communications
    should support multi-homing: one router to use multiple = interfaces
    towards outside the moving network, or multiple = routers.

    Current version of Internet = protocols
    -------------------------------------
    The group will only work on IPv6 solutions.

    What SDOs may need this work?
    -----------------------------
    The requirements = and standards for moving network to nearby moving
    network = communications, often involving IPv6, and novel V2V and
    V2Infra concepts, are developed mainly at ISO TC204 = "Intelligent
    Transport Systems", 3GPP, ETSI, NHTSA and = IEEE.  For
    Vehicle-to-Internet communications, 3GPP = LTE and other cellular
    technologies represent the = long-range connectivity method; for
    Vehicle-to-Vehicle = communications, LTE Direct is currently specified,
    as well = as OCB mode of IEEE 802.11.  Several use-cases exhibit a need
    for IPv6 data exchanges between vehicles: ETSI's Cooperative = Adaptive
    Cruise Control and Platooning.  The IEEE = developed a popular link for
    short-range communications - = IEEE 802.11p "WAVE".  The NHTSA wrote a
    set of = requirements for V2V communications.

    Work = Items
    ----------
    - use-cases for moving = network to nearby moving network communications
    - Problem = Statement for moving network to nearby moving network communications
    - Security and Privacy Requirements for moving network to
      nearby moving network communications
    - = Problem Statement for moving network to infrastructure network
      communications, including DNS
    - = Potentially new protocol, or protocol extensions for establishing IP
      paths for 1-hop moving network to nearby moving = network communications.
      With MIB and security.
    - IPv6-over foo, where foo is pertinent for moving network to = nearby
      moving network communications (e.g. 802.11 = OCB, VLC, LTE-D, 802.11ad)

    Timeline
    --------
    -

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

    = --Apple-Mail=_9D92A572-A15C-4251-B5E9-134F762D4FDD-- From nobody Sat Mar 12 02:59:31 2016 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 D66E812DDB1; Fri, 11 Mar 2016 15:05:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230527.15028.32549.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:27 -0800 Archived-At: X-Mailman-Approved-At: Sat, 12 Mar 2016 02:59:30 -0800 Cc: brian@innovationslab.net, its@ietf.org Subject: [its] its - Requested session has been scheduled for IETF 95 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:05:28 -0000 Dear Stephanie McCammon, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. its Session 1 (2:00:00) Wednesday, Afternoon Session I 1400-1600 Room Name: Buen Ayre C size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Intelligent Transportation Systems Area Name: Internet Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: lime babel isis ospf rtgarea roll manet dhc 6man dmm 6lo stir saag Special Requests: --------------------------------------------------------- From nobody Thu Mar 17 16:35:00 2016 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 71CDA12DDCC; Thu, 17 Mar 2016 16:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 XSBedjoixYfq; Thu, 17 Mar 2016 16:34:55 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F2DC12DDD9; Thu, 17 Mar 2016 16:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1757; q=dns/txt; s=iport; t=1458257695; x=1459467295; h=from:to:cc:subject:date:message-id:mime-version; bh=SvIYD4q9e5ANuovwlwgwW2rsUWrMXQk4q60aTupxz+Y=; b=UMsaJth7gDPfmv9AtPNFYzyeYqKU3hQP8WBk8sAvkHx3ZQet9D5DEJPX 26MmEDqgZpRr/RXULbmwjx008p3iWT7dTNGJsi9Xk2fCXI8SsdFPyDgg4 Tk/gZzNlTyhdhWgYPsk4/osQTV7oR9rZbMy7rfPBPuKgpJwpbMhPtbBvB Q=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxAgBHPutW/5FdJa1eg0VTdLoDDoFvI?= =?us-ascii?q?YVsgTg4FAEBAQEBAQFkHAuERAQjVhIBSgI0JwQOE4gZDrFpj1cBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQENBASGHoFzhl0RAYMeK4EPBZdVAYMbgWaIf4FPARWESYhYj?= =?us-ascii?q?wIBHgFDg2WKGzR+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,351,1454976000"; d="asc'?scan'208";a="86878879" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Mar 2016 23:34:54 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u2HNYssO007661 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Mar 2016 23:34:54 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 17 Mar 2016 19:34:53 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Thu, 17 Mar 2016 19:34:53 -0400 From: "Carlos Pignataro (cpignata)" To: "its@ietf.org" Thread-Topic: Preliminary ITS Agenda Thread-Index: AQHRgKWbTJVS+HpXIUyUTNWUNL3buw== Date: Thu, 17 Mar 2016 23:34:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.210.149] Content-Type: multipart/signed; boundary="Apple-Mail=_A1F534AB-BF03-49D8-858B-D5C37B3C4156"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "its-chairs@ietf.org" Subject: [its] Preliminary ITS Agenda X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 23:34:58 -0000 --Apple-Mail=_A1F534AB-BF03-49D8-858B-D5C37B3C4156 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, ITS, We just posted the *DRAFT* Intelligent Transportation Systems (ITS) = Agenda: https://www.ietf.org/proceedings/95/agenda/agenda-95-its The ITS BoF was assigned a two-hour slot, and is meeting on Wednesday = afternoon, Session I, at 14:00-16:00. We hope to see you all there! If you have comments or suggestions on the Agenda, please send us = (chairs) an email. Thanks, =E2=80=94 Carlos and Russ. --Apple-Mail=_A1F534AB-BF03-49D8-858B-D5C37B3C4156 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJW6z8cAAoJEIXgpQGOZny90XMP/jxauFMlYMJNOQ3nYoCm93P6 Av3mOjkURAH6ucyM8RXvKObvli7eHMdpuJDPfmmzH3sMSvoWT+E2P4moAYe/0uV2 9M6OB8aPltIgVAM4Mk3XMg/Kta+QrjAQQCnmPinMDhJtV9Et9Fl59BzRqNYjfdHl EK1Ebw+Q08Dq+SQlsDhH9jYAdauTNVzlXPmi0av9EZxkQbobWUMuTjXAPdoxG3uQ cF4aACYm6lCgnyUcP5meC2kOjflRpTlsjTvLnFqF/cZhcVal0nhIQaOKu+SkjS9D TAuH03sHcSIlVB241jbE0rCkiuvYe5PQf9Z0xwQ4tbAnmTB+LXKX01Xz459VjRk1 aHd95jWPY70yEe0Q/VWnikbYjUS79nU9r3VjJJF2/2M/IDdQpHOUSkriikx5cdI6 LMUjTaB5Flt1+s0VYZY/NC1+CLKBEVkAO0k6tNZF/HnJhMmDt4LdDfT337dsLi6n x9y9YL5IRF6sSEL8OsRF3TjJY+4Erws3FI7fg6G4N0grX/Ns6QOPOSnnxFymkxY/ x0uVZqB1beV8KzDgI5uJnQ0Az+OTWgIzAPqv23OapI4AV6n/IY7EKfZw9WaqkHra mrbIrCkncvWvT6SCH3ZO7Dksaqz3Spjk/SBbOk44p4kUyEYyAPJ2raYaHmQU0l0K 42QrU42xw9SeBhRjFmKQ =z635 -----END PGP SIGNATURE----- --Apple-Mail=_A1F534AB-BF03-49D8-858B-D5C37B3C4156-- From nobody Fri Mar 18 11:04:47 2016 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 B647D12D573 for ; Fri, 18 Mar 2016 11:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 9iux64Z35niB for ; Fri, 18 Mar 2016 11:04:45 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C59D12D7CF for ; Fri, 18 Mar 2016 11:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4631; q=dns/txt; s=iport; t=1458324284; x=1459533884; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9YzEaH2TjSMBpMMCxKAHOnUv7GL5uoOle/20n5QzNWI=; b=REpxT7W+QaqyjpMe9AKMyWAPUvoFTL9bINy+KoOcHKybFds8mfjd8BQM l3NM47tk8/Apqv3I9f5kCoAy/sgLNfGgsh/ho/NlyfiW50p4Pd9icsJY+ 7nPTHbub5KfecYhWH7TFj4YO2AazH4/m4bdM65b6SS0Q1oTuEbqkq0WEj Y=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DDAgAyQuxW/5xdJa1eg0RTcga1KIRuD?= =?us-ascii?q?oFvFwEJhWwCgTA4FAEBAQEBAQFkHAuEQQEBAQMBAQEBIEsLBQsCAQgEFCoCAic?= =?us-ascii?q?LJQIEDgUOiBEIDrEUj04BAQEBAQEBAQEBAQEBAQEBAQEBAQENCIYegXOCUYc8K?= =?us-ascii?q?4IrBZMEhFMBgx2BZm2IE4FlS4N/iFiPBQEPDwFDg2VqiWV+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,356,1454976000"; d="asc'?scan'208,217";a="250970449" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Mar 2016 18:04:43 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u2II4fVm012009 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Mar 2016 18:04:41 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 18 Mar 2016 14:04:40 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Fri, 18 Mar 2016 14:04:40 -0400 From: "Carlos Pignataro (cpignata)" To: "its@ietf.org" Thread-Topic: [its] ITS BOF in Buenos Aires at IETF 95 Thread-Index: AQHReMw0yiYgTgWASkuriQlw250t5J9f0r0A Date: Fri, 18 Mar 2016 18:04:40 +0000 Message-ID: <31F99A83-FA0B-49BC-B031-64E70D21071F@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.59] Content-Type: multipart/signed; boundary="Apple-Mail=_B5BF5EB2-9CD2-4AAE-A379-0C78C7B6BC41"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: Russ Housley Subject: Re: [its] ITS BOF in Buenos Aires at IETF 95 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 18:04:46 -0000 --Apple-Mail=_B5BF5EB2-9CD2-4AAE-A379-0C78C7B6BC41 Content-Type: multipart/alternative; boundary="Apple-Mail=_458380FB-9402-462F-A9B5-8CA952528C35" --Apple-Mail=_458380FB-9402-462F-A9B5-8CA952528C35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 ITS, Please also note that Remote Participation tools are available, = including Jabber, Meetecho, Audio Streaming, and others. You can learn more about these tools at = http://ietf.org/meeting/95/index.html, under the =E2=80=9CRemote = Participation=E2=80=9D banner. Thanks! =E2=80=94 Carlos. > On Mar 7, 2016, at 6:50 PM, Russ Housley wrote: >=20 > The IESG has approved a BOF slot for ITS, and the draft agenda is out: >=20 > https://datatracker.ietf.org/meeting/95/agenda = > (search for "its") >=20 > I hope to see you there, > Russ > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --Apple-Mail=_458380FB-9402-462F-A9B5-8CA952528C35 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 ITS,

    Please= also note that Remote Participation tools are available, including = Jabber, Meetecho, Audio Streaming, and others.

    You can learn more about these tools = at http://ietf.org/meeting/95/index.html, under the = =E2=80=9CRemote Participation=E2=80=9D banner.

    Thanks!

    =E2=80=94 Carlos.

    On Mar 7, 2016, at 6:50 PM, Russ Housley <housley@vigilsec.com> wrote:

    The = IESG has approved a BOF slot for ITS, and the draft agenda is out:

    https://datatracke= r.ietf.org/meeting/95/agenda
    (search for "its")

    I hope to see you there,
      = Russ
    _______________________________________________
    its mailing list
    its@ietf.org
    https://www.ietf.org/mailman/listinfo/its

    = --Apple-Mail=_458380FB-9402-462F-A9B5-8CA952528C35-- --Apple-Mail=_B5BF5EB2-9CD2-4AAE-A379-0C78C7B6BC41 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJW7EM4AAoJEIXgpQGOZny9YV8QAIUUTSCC87/eivXSSnjr0jE+ mFsKbBkomPx+kV6r4KQNWS+v8XeucHHqqtUBkV+O+eIDPCSXQH3G7LAP1mvkaCiT hz1souynZRpupDARtVAMmfPmvT/ePHqxqDPtTtoG8UAzFP5QV2pzGE1KwGIMkH0K ltNxlxH3BQbEcraBVR5kCZG2pUV/Uj0zr5qMrT4A4HscK6U/yG+393jZEwroyv4+ /HyRaHCUD7DdcUCGRrUjCqEq2Aeo06bvOZPZR88Iqp4uvi4Mmcs8NBcUXUrQok8x I+S9y6+eSc81WG8EHL3MUn9nENuY/Q0AMlwfWJ9Rxd6cIPDtXYmrrPN3GhdOh1Cj WHup6HTPBErooNff5cTeXwdFXBuj27nszkprbkXWXRgxgsp1rovYzVBY9j0cuSmR 1opVMx3LwvT+w2YEl3kPDs4pE3lYlSnA2bQMgVBHiVsohsmKPm2w5DYS3sVFjfct 7/wGk/98Ptm7bt2u5qhnRKo7FpqBjjBJUUHBd7hcpgQ3zl2Tpyf9l1h/oaaRi1ST WXMTd0zLLJKdTYeeqM8ZomCbe19chRraeA80TYSSzSkzRw61Ai5C8QOrGf1B71Ac maLU1i+Xxs8Cnqs3dZH5Y46fc7beXKWODHtmVwMjqxEJq/2GTfaYCXXsU1nwhDut Xxx2l/7HGh1PU21thUIj =eLe3 -----END PGP SIGNATURE----- --Apple-Mail=_B5BF5EB2-9CD2-4AAE-A379-0C78C7B6BC41-- From nobody Mon Mar 21 17:10:41 2016 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 BAF9D12D58A for ; Mon, 21 Mar 2016 17:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 AOEiR_MfMrNh for ; Mon, 21 Mar 2016 17:10:38 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 B23C812D581 for ; Mon, 21 Mar 2016 17:10:38 -0700 (PDT) Received: from [172.22.227.238] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u2M0Aa59020528 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 21 Mar 2016 17:10:36 -0700 To: its@ietf.org From: Erik Nordmark Message-ID: <56F08D7C.4080208@acm.org> Date: Mon, 21 Mar 2016 17:10:36 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYX/0AfZEmpp1To44zdrZqwc6t/YpdxXjkBaRDhyUijVdmKtGuCfj6ZzaKL8BtoOKqZ5AVi44jmWB4ViT4geBoF X-Sonic-ID: C;+BOTgMLv5RGasJFDXdaMvg== M;LHK6gMLv5RGasJFDXdaMvg== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Subject: [its] Thoughts on source IP addresses in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 00:10:41 -0000 I've looked through draft-jeong-its-v2i-problem-statement and the background on ITS that was given at recent IETF plenary. It seems like there are quite different performance expectations for different types of V2V and V2I which has an impact on what one might want to do in terms of IP address management. Some use cases are about connecting to the Internet, where it seems like one would want a global IP address with some support for mobility. (But there are privacy considerations that probably mean we don't want to keep the IP address for a long time.) Using DHCP to assign such addresses might be reasonable. But for some V2V and vehicle to roadside use cases the performance requirements might not allow for waiting for IP address assignment, while at the same time the communication is entirely local. In such a case there isn't a need for a global IP address. One could even argue that there is no need for an IP address at all if the purpose is to notify neighboring vehicles about a hazard or that I've slammed on the brakes. One could potentially send such a packets using a link-local source address (and multicast them to a link-local group). But that still requires having a link-local address, and concerns about privacy means we need to change that source address. But it wouldn't serve any purpose if the message is unidirectional. I think we could consider sending such packets with the unspecified (all-zeros) IPv6 source address. We typically don't use this (an exception is Duplicate Address Detection) but for local unidirectional traffic it is an option to consider if the performance/privacy of IP address assignment is an issue. Regards, Erik From nobody Mon Mar 21 23:22:26 2016 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 729D812D67C for ; Mon, 21 Mar 2016 23:22:24 -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, HK_NAME_FM_DR=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 9F7XBBWCr5pV for ; Mon, 21 Mar 2016 23:22:23 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::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 99A6B12D55B for ; Mon, 21 Mar 2016 23:22:22 -0700 (PDT) Received: by mail-lb0-x22b.google.com with SMTP id bc4so147622610lbc.2 for ; Mon, 21 Mar 2016 23:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=+QkVslUbW9eDOMnoQoVeu/fF1xgZAwWsJr4J/r6yrs0=; b=UTylfeAGx8Sec9Rend2YSqWkXvjCpDOCSzy06gZhsCYpe+bukB2itC+rAew6altm+w 6RspMHS51+1EbdCv3pD+Wo/Hg2kPB4UrarEhqcgB+CGZiY9S0xAmU8acbBW1AVyDrwDO ZmGsUHJ/pXVHyipnOMhVflwZP8hoIO3IKKGKi8Sg2n1pedl6hTWbYb9USJfJeSHTyxIK mX3fHFePsEQKSxzGjp91/cnOuGUm19iDqnQ1vWjxdm4i3aj8PlXJlAHaq3Ymfl13ONxa kfNFhPfAbjXP3RxTa5PUA3IQUnxjft8c7+NYRkbqtSu9w/dmAIrO6MWvl0Nuc5W2dSDN 3CCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=+QkVslUbW9eDOMnoQoVeu/fF1xgZAwWsJr4J/r6yrs0=; b=nJDXT1lKrUnHCiEsCHcXNwcYLQ025EUab5vM16CQAdiqAKXy+3bg/hjKqnjPt1lkVf h8e8OnE8864If+GsbakUamgyiJONBVBZiTBFkuIQaZaQc7h1nxGuTd0GZFdvnu22N7qK 9Dq9KGlLDyH1v2r5oefpKj3kQMzH0+aZeXsBmjnqRgIFTRQjB5SYU4sstTpA5ZMLfGLW BIOHo/RDEpykmWev8UctWGHY+LcGcSesXwJcXoiz6hb9D4lL7y8aqYHzZk9lJ9B4lAI3 Q//s0ZS4szmtsulLVfCQ/GhVR4E2lcOCZzuimgRJT+gDwkBAZXJIZYReY6B0wdADlUBV uppg== X-Gm-Message-State: AD7BkJIHDT0eeAYkqoxYMIAXHLwjVw4EoQMYXPm/uCtvSkGVQodVEs+H7xDp/zjQPqSPPlr4hjBVH5byDRQMlg== MIME-Version: 1.0 X-Received: by 10.25.33.140 with SMTP id h134mr13034939lfh.159.1458627740730; Mon, 21 Mar 2016 23:22:20 -0700 (PDT) Received: by 10.25.35.88 with HTTP; Mon, 21 Mar 2016 23:22:20 -0700 (PDT) Date: Tue, 22 Mar 2016 11:52:20 +0530 Message-ID: From: "Dr. Karan Verma" To: cpignata@cisco.com, its@ietf.org, housley@vigilsec.com, pauljeong@skku.edu, tom.oh@rit.edu Content-Type: multipart/alternative; boundary=001a114102c0588a73052e9d3c60 Archived-At: Subject: [its] review draft "Problem Statement for vehicle-to- infrastructure networking" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 06:22:24 -0000 --001a114102c0588a73052e9d3c60 Content-Type: text/plain; charset=UTF-8 Hello Jeong, I review draft "Problem Statement for vehicle-to- infrastructure networking" Commends: - Wireless Access for Vehicular Environment (WAVE)-IEEE 1609 protocols are also under development to support mobile communications. -VANET is accompanied by some constraints due to (i) restricted roads; (ii) limited bandwidth due to absence of a central coordinator that controls and manages communications between nodes; (iii) disconnect problems due to frequent network fragmentation; and (iv) fading signals caused by objects that form obstacles between communicating nodes. 1. In draft not explain about OBU (On-Board Unit), it's not possible V2I without communicate with OBU. 2. Not explain how can control the incoming traffic (e.g., collision avoidance) to other vehicle. 3. Not explain distributed RSU request. 4. where you stored incoming IP addresses request. 5. Please included filtration process to distributed incoming traffic (e.g., it's mobile IP or Infrastructure request). 6. not synchronization processes inter-networking given some time may be used time synchronization process. 7. IP addressing process used may be IP-CHOCK. 8. May be used Bloom-fliter system given more secure for DDoS attacks. Thank You -- Best Regards Dr. Karan Verma Assistant Professor Computer Science and Engineering Dept. Central University Rajasthan, India Website: www.drkaranverma.com Phone: +917568169258 This email has been sent from a virus-free computer protected by Avast. www.avast.com <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> --001a114102c0588a73052e9d3c60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hello Jeong,

    I review draft "Problem Statement for vehicle-to- infras= tructure networking"
    Commends:=C2=A0

    =C2=A0-= Wireless Access for Vehicular Environment (WAVE)-IEEE 1609 protocols =C2=A0 =C2=A0are also unde= r development=C2=A0t= o support mobile communications.
    =C2=A0-VANET is=C2=A0 accompanied by some constraints due to (i) restricted roads; (ii) limited bandwidth due to absence of a central coordinator that controls and manages communications between nodes; (iii) disconnect problems due to frequent network fragmentation; and (iv) fading signals caused by objects that form obstacles between communicating nodes.<= /span>


    1. In draft not explain about OBU (On-Board Unit), it's not pos= sible V2I without communicate with OBU.=C2=A0
    2. Not explain how can control the incoming traffic (e.= g., collision avoidance) to other vehicle.
    3. Not explain distributed RSU request.=C2=A0
    4. where you stored incoming IP addresses = request.=C2=A0
    5. Please inc= luded filtration process to distributed incoming traffic (e.g., it's mo= bile IP or Infrastructure request).=C2=A0
    6. not synchronization processes inter-networking given some = time may be used time synchronization process.=C2=A0
    7. IP addressing process used may be IP-CHOCK.
    8. May be used Bloom-fliter sys= tem given more secure for DDoS attacks.=C2=A0

    Thank You =C2=A0=C2=A0

    --
    Best Regards=C2=A0

    Dr. Karan Verma=C2=A0
    Assistant Professor=C2=A0=C2=A0
    Computer Science and Engineering Dept= .
    Central Universi= ty Rajasthan, India=C2=A0
    Phone: +917568169258

    This email has been = sent from a virus-free computer protected by Avast.
    www.avast.com
    --001a114102c0588a73052e9d3c60-- From nobody Mon Mar 21 23:27:05 2016 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 67A6C12D5CF for ; Mon, 21 Mar 2016 23:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 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, HK_NAME_FM_MR_MRS=1.499, 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 3thoJbCz7oWJ for ; Mon, 21 Mar 2016 23:27:02 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC8E212D55B for ; Mon, 21 Mar 2016 23:27:02 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id g127so242403414ywf.2 for ; Mon, 21 Mar 2016 23:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x7fJLl6w/AsA3JirMqbGMjyHXd9NGP1LVxx0naTZ/WI=; b=k4/rzeYDjaZPpRUIqIImepEGF1eOiH3xoZFn/kA36FyMRJAjASSP95h/dDv5O4AbH4 zHESmtjtdFGa7eyeTT+LmfKHoOByUh8LNgtLA84EeLWJ49ca9HYfUXZfeC5UgcctfPum tDvJxlAuGFO28lvbu3/tGVUIZlvBAVLI+HkKE/kbTAm/UUzAtwcA1Wlqa3Yuyxa4cjX9 XrmiBsWJhZSlt6II/B6EVcFP2LK632wiPDRMuUDOozdG/ytWFa6ILbiO/vAgdQP5SO4P tmHNyIukioeNKLOTHy86S+ncaayPOsxeJEG8IPvHqvc1Mt43X52VhGSZd5T+4YmtIfsD 7EEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x7fJLl6w/AsA3JirMqbGMjyHXd9NGP1LVxx0naTZ/WI=; b=CDAimRxIDRvCqZJDsKElNQaM6jwnzMyIc8nCoxB10hnSgUatOP+3JAl+FFDWSn6hic +q4p6+SfUmJx4ypHAQxGtgUTw/QIVduR7HUHj0T6Z+9oWZ5LU3Oo3dWQlNt6363ovfTU qYJ0cUggpGGw9HRiYRWuE6pvIdqdCaEMcbI0/DxJH1x1mJa2jtquJQHyhWwGKKDAfYX/ A0djJG5ATi+P8tewxAuWNJ4EnXPRfVXhVMdL5ctvzSEfasgoNCE9cRGn0fasTUkoMBin uF+Bnyb0p+7m1ojUBFaycjkp6gEylO6r92rrjF+l7yn2NY6c1wKyn15AGwhNQa9k0Vyp 7AgA== X-Gm-Message-State: AD7BkJIfnTasExm2U9f2Ol6mchfMpbhdRxm4l0klZtPYTYGdvUiFg7c77r7QP5tFgfJ8xDcO2BcAHUcz71m3PA== X-Received: by 10.37.86.69 with SMTP id k66mr14137057ybb.39.1458628021866; Mon, 21 Mar 2016 23:27:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.145.80 with HTTP; Mon, 21 Mar 2016 23:26:32 -0700 (PDT) In-Reply-To: References: From: "Mr. Jaehoon Paul Jeong" Date: Tue, 22 Mar 2016 15:26:32 +0900 Message-ID: To: "Dr. Karan Verma" Content-Type: multipart/alternative; boundary=001a1140f5741a54e2052e9d4d3f Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "Prof. Tom Oh" , Russ Housley , "Mr. Jaehoon Paul Jeong" , its@ietf.org Subject: Re: [its] review draft "Problem Statement for vehicle-to- infrastructure networking" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 06:27:04 -0000 --001a1140f5741a54e2052e9d4d3f Content-Type: text/plain; charset=UTF-8 Hi Karen, Thanks for your valuable comments. I will try to reflect your comments on the revision. Thanks. Best Regards, Paul On Tue, Mar 22, 2016 at 3:22 PM, Dr. Karan Verma wrote: > Hello Jeong, > > I review draft "Problem Statement for vehicle-to- infrastructure > networking" > > Commends: > > - Wireless Access for Vehicular Environment (WAVE)-IEEE 1609 protocols > are also under development to support mobile communications. > -VANET is accompanied by some constraints due to (i) restricted roads; > (ii) limited bandwidth due to absence of a central coordinator that > controls and manages communications between nodes; (iii) disconnect > problems due to frequent network fragmentation; and (iv) fading signals > caused by objects that form obstacles between communicating nodes. > > > 1. In draft not explain about OBU (On-Board Unit), it's not possible V2I > without communicate with OBU. > 2. Not explain how can control the incoming traffic (e.g., collision > avoidance) to other vehicle. > 3. Not explain distributed RSU request. > 4. where you stored incoming IP addresses request. > 5. Please included filtration process to distributed incoming traffic > (e.g., it's mobile IP or Infrastructure request). > 6. not synchronization processes inter-networking given some time may be > used time synchronization process. > 7. IP addressing process used may be IP-CHOCK. > 8. May be used Bloom-fliter system given more secure for DDoS attacks. > > > Thank You > > -- > Best Regards > > Dr. Karan Verma > Assistant Professor > Computer Science and Engineering Dept. > Central University Rajasthan, India > Website: www.drkaranverma.com > Phone: +917568169258 > > This email has been sent from a virus-free computer protected by Avast. > www.avast.com > > <#5125783738851981064_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --001a1140f5741a54e2052e9d4d3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi Karen,
    Thanks for your valuable comments.

    I will try to reflect your comments on the revision.
    <= div>
    Thanks.

    Best Regards,
    Paul

    = On Tue, Mar 22, 2016 at 3:22 PM, Dr. Karan Verma <karan.verma.phd@= gmail.com> wrote:
    Hello Jeong,
    <= font face=3D"georgia, serif">
    I review draft "Problem Statement for vehicle-to- infrastructure= networking"

    Commends:=C2=A0
    <= div>
    =C2=A0- Wireless= Access for Vehicular Environment (WAVE)-IEEE 1609 protocols =C2=A0 =C2=A0are also unde= r development=C2=A0t= o support mobile communications.
    =C2=A0-VANET is=C2=A0 accompanied by some constraints due to (i) restricted roads; (ii) limited bandwidth due to absence of a central coordinator that controls and manages communications between nodes; (iii) disconnect problems due to frequent network fragmentation; and (iv) fading signals caused by objects that form obstacles between communicating nodes.<= /span>


    1. In draft not explain about OBU (On-Board Unit), it's not pos= sible V2I without communicate with OBU.=C2=A0
    2. Not explain how can control the incoming traffic (e.= g., collision avoidance) to other vehicle.
    3. Not explain distributed RSU request.=C2=A0
    4. where you stored incoming IP addresses = request.=C2=A0
    5. Please inc= luded filtration process to distributed incoming traffic (e.g., it's mo= bile IP or Infrastructure request).=C2=A0
    6. not synchronization processes inter-networking given some = time may be used time synchronization process.=C2=A0
    7. IP addressing process used may be IP-CHOCK.
    8. May be used Bloom-fliter sys= tem given more secure for DDoS attacks.=C2=A0

    Thank You =C2=A0=C2=A0

    --
    Best Regards=C2= =A0

    Dr. Karan Verma=C2=A0
    Assistant P= rofessor=C2=A0=C2=A0
    Computer Scien= ce and Engineering Dept.
    Central University Rajasthan, India=C2=A0
    Website:=C2=A0www.drkaranverma.com
    Phone: +917568169258

    This email has been = sent from a virus-free computer protected by Avast.
    www.avast.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 ProfessorDepartment of Software
    Sungkyunkwan University
    Office: +82-31-299-4= 957
    Email: j= aehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu<= br>Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
    --001a1140f5741a54e2052e9d4d3f-- From nobody Mon Mar 21 23:28:41 2016 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 20EB912D685 for ; Mon, 21 Mar 2016 23:28:40 -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, HK_NAME_FM_DR=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 UzgMVd-MF73X for ; Mon, 21 Mar 2016 23:28:38 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E714012D55B for ; Mon, 21 Mar 2016 23:28:37 -0700 (PDT) Received: by mail-lb0-x229.google.com with SMTP id bc4so147766859lbc.2 for ; Mon, 21 Mar 2016 23:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=8WgteOPQTr2dM2nn9ERPSLODoQonDFiEuS/ldUCNG2M=; b=DEMJhJ/46BCGxotrRWGlOLk+AgW+pXMJCh8+rd0PYluHvyC3/RPuzvCMtzUyOAAqDk J+dGA/d5LFPP21MJzMlL95LA6cvuNA04OZ7TTt7YqbroO89dNFD9RonHOQJiLNWXzAPH oCS838PRgZsVDnQyXFUUCQFjyhPOpxuWy1qb/ze8CdJeOf8DlRpQ11Mj6V90tv8Z0PDO TvopmWo+aC8zJoQZz5kY3x3YtOg0QIAqC/3x3ls/he2xoVNoHFnVziHgdey5WbLSUD+H LjWErv/Ni+HMLE7k4fmKR3SxwydmybMQbONDzZDq4WEGfMS5KCd3KuVfPhATi+aBhDT9 jj9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=8WgteOPQTr2dM2nn9ERPSLODoQonDFiEuS/ldUCNG2M=; b=ZVahbgCnxoBKG5fCAoeWr/MliR1ldzwUS89rsaiGn5Y/9jNsm/gJko1uI/6BCcAOZi athpBIDjVjYGrDAiQ1/h4VeniIMkX0SlZ14rLRTIXgF0MNuZSdiyGze+JD2/W7vzC55b Em1mZhHs8YmbL7jsTEDoSZiDvUrYbzgkRrrJGDJCXpdufenhtJhqROC/TQKFl1bT3/2t UDY45L+g3vqsSTc7GURPVTnxk7qhPSd0+IaxdcJxpWhyVPEXTWU01j1w05PX0y54rSqw coKn779Cbo8P6c/jwerNJ6SsGBdF2YoEwzhIcqJiqJoX90fVZxJ8fP2OBINzMnAERwbs dEog== X-Gm-Message-State: AD7BkJIaZlIavqJUGqlZ5NwONbxOiCZYpZ5jH3Pfr9TG0+tcc6gAArA7wSia6qHw5t2lsyg9VqhqgY0MdIGdyw== MIME-Version: 1.0 X-Received: by 10.112.140.129 with SMTP id rg1mr12946690lbb.80.1458628116127; Mon, 21 Mar 2016 23:28:36 -0700 (PDT) Received: by 10.25.35.88 with HTTP; Mon, 21 Mar 2016 23:28:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Mar 2016 11:58:36 +0530 Message-ID: From: "Dr. Karan Verma" To: "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary=001a11c26ba8b8a68b052e9d5284 Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "Prof. Tom Oh" , Russ Housley , "Mr. Jaehoon Paul Jeong" , "its@ietf.org" Subject: Re: [its] review draft "Problem Statement for vehicle-to- infrastructure networking" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 06:28:40 -0000 --001a11c26ba8b8a68b052e9d5284 Content-Type: text/plain; charset=UTF-8 Sorry I'm Karan not Karen. On Tuesday 22 March 2016, Mr. Jaehoon Paul Jeong wrote: > Hi Karen, > Thanks for your valuable comments. > > I will try to reflect your comments on the revision. > > Thanks. > > Best Regards, > Paul > > On Tue, Mar 22, 2016 at 3:22 PM, Dr. Karan Verma < > karan.verma.phd@gmail.com > > wrote: > >> Hello Jeong, >> >> I review draft "Problem Statement for vehicle-to- infrastructure >> networking" >> >> Commends: >> >> - Wireless Access for Vehicular Environment (WAVE)-IEEE 1609 protocols >> are also under development to support mobile communications. >> -VANET is accompanied by some constraints due to (i) restricted roads; >> (ii) limited bandwidth due to absence of a central coordinator that >> controls and manages communications between nodes; (iii) disconnect >> problems due to frequent network fragmentation; and (iv) fading signals >> caused by objects that form obstacles between communicating nodes. >> >> >> 1. In draft not explain about OBU (On-Board Unit), it's not possible V2I >> without communicate with OBU. >> 2. Not explain how can control the incoming traffic (e.g., collision >> avoidance) to other vehicle. >> 3. Not explain distributed RSU request. >> 4. where you stored incoming IP addresses request. >> 5. Please included filtration process to distributed incoming traffic >> (e.g., it's mobile IP or Infrastructure request). >> 6. not synchronization processes inter-networking given some time may be >> used time synchronization process. >> 7. IP addressing process used may be IP-CHOCK. >> 8. May be used Bloom-fliter system given more secure for DDoS attacks. >> >> >> Thank You >> >> -- >> Best Regards >> >> Dr. Karan Verma >> Assistant Professor >> Computer Science and Engineering Dept. >> Central University Rajasthan, India >> Website: www.drkaranverma.com >> Phone: +917568169258 >> >> This email has been sent from a virus-free computer protected by Avast. >> www.avast.com >> >> <#-7782309100366217828_5125783738851981064_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> > > > -- > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com > , > pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > -- Best Regards Dr. Karan Verma Assistant Professor Computer Science and Engineering Dept. Central University Rajasthan, India Website: www.drkaranverma.com Phone: +917568169258 --001a11c26ba8b8a68b052e9d5284 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry I'm Karan not Karen.=C2=A0



    On Tuesday = 22 March 2016, Mr. Jaehoon Paul Jeong <    jaehoon.paul@gmail.com> wrote:
    Hi Karen,
    Thanks for your valuable comments.

    I will try to reflect your comments on the revision.<= /div>

    Thanks.

    Best Regards,
    Paul

    On Tue, Mar 22, 2016 at 3:22 PM, Dr. Karan Verma &l= t;karan.verma.phd@gmail.com> wro= te:
    Hello Jeong,
    =
    I review draft "Pr= oblem Statement for vehicle-to- infrastructure networking"
    <= /div>

    Commends:=C2=A0

    =C2=A0- Wireless Access for Vehicular Environment (WAVE)-IEEE 1609 protocols =C2=A0 =C2=A0are also unde= r development=C2=A0t= o support mobile communications.
    =C2=A0-VANET is=C2=A0 accompanied by some constraints due to (i) restricted roads; (ii) limited bandwidth due to absence of a central coordinator that controls and manages communications between nodes; (iii) disconnect problems due to frequent network fragmentation; and (iv) fading signals caused by objects that form obstacles between communicating nodes.<= /span>


    1. In draft not explain about OBU (On-Board Unit), it's not pos= sible V2I without communicate with OBU.=C2=A0
    2. Not explain how can control the incoming traffic (e.= g., collision avoidance) to other vehicle.
    3. Not explain distributed RSU request.=C2=A0
    4. where you stored incoming IP addresses = request.=C2=A0
    5. Please inc= luded filtration process to distributed incoming traffic (e.g., it's mo= bile IP or Infrastructure request).=C2=A0
    6. not synchronization processes inter-networking given some = time may be used time synchronization process.=C2=A0
    7. IP addressing process used may be IP-CHOCK.
    8. May be used Bloom-fliter sys= tem given more secure for DDoS attacks.=C2=A0

    Thank You =C2=A0=C2=A0

    --
    Best Regards=C2=A0

    <= span style=3D"font-size:small">Dr. Karan Verma=C2=A0
    Assistant Professor=C2=A0=C2= =A0
    Computer Science and Engineerin= g Dept.
    Central Un= iversity Rajasthan, India=C2=A0
    Phone: +917568169258

    This email has been = sent from a virus-free computer protected by Avast.
    www.avast.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. J= aehoon (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 Homep= age: http://iotlab.skku.edu/people-jaehoon-jeong.php
    =


    --
    Best Regards=C2=A0

    Dr. Karan Verma=C2=A0
    Assistant Professor=C2=A0=C2=A0
    Computer Science and Engineering Dept.
    Central University Rajast= han, India=C2=A0
    Phone: +917568169258

    --001a11c26ba8b8a68b052e9d5284-- From nobody Mon Mar 21 23:31:14 2016 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 6053A12D62A for ; Mon, 21 Mar 2016 23:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 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, HK_NAME_FM_MR_MRS=1.499, 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 LLv1IC_H9gdw for ; Mon, 21 Mar 2016 23:31:11 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::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 7A0DD12D55B for ; Mon, 21 Mar 2016 23:31:11 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id h65so99690565ywe.0 for ; Mon, 21 Mar 2016 23:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RbKt9isyIss40ITGczomNE8LZ/IDA/8IaONvhkTH15E=; b=0v3uchenukmiaEH2FNQ0h8wEnEgKu34CsJ+QTuU80iJoIHSzyaSTcSfdeoVOYFGq8v CrUJUKI2r0CG8T6w+s4oWyQbPcNMUAabP10UPjA787OdLxGKpatzUMqZxlh50tfpRaFO PhuBYzRinMlt1QK5QReuo628VK7vioqcEF3SN0o4tWjerYpNLHOoUBqj39IzFSY2UFUN Qu1IspXezqbKiOExOEe6CC/RiTUDEV8RIirsft8UxgbiehFAd9BIiq46KQr8boQwmRtq s4mbLPv/r1fIFn3hXlNPTW+eaYiu5asQmVFD4a/Sb3U521XqUizBXcXEGeMqMz3GPfvf gpWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RbKt9isyIss40ITGczomNE8LZ/IDA/8IaONvhkTH15E=; b=Fnd2OIE7dSCfSLY6imDTpqcY9iYtnwfaw6+VaDrwGuO5gEujxjReO6KEMxsKbEAgSz ve+mPBlrGidkFmu5OBRtxJHEj8sIkBG/VaAif3up2BuA4IL+1V/6XtLqjENNRIFHfo07 cM34JRyCqqwV8jFL1aOIwqQrhygJ7sLq78fxqxLiGiN3Wzx2tdXRgnqYH8Gzqa2wkMhe doBhO80+JEt6Ycw2s/aGEy1uYTPSai4miY2RffRGtlgtZ9IIKX61YXRDhE1vBqC1lNX4 c6ja1y/gv2yapOnuk78KEbqW/UKZw7m4KE9zmo7qpUE/f7hHTgldfvqSv6IhsMOhGIwD GITQ== X-Gm-Message-State: AD7BkJIKq9XXYde3lnwuhc0Dne75iVzZPJnE0o7YeDiRtBBWtO2FhQjqyeafyvgBgV07OYQQShzbhWAgw/pRUQ== X-Received: by 10.129.148.2 with SMTP id l2mr15209340ywg.298.1458628270737; Mon, 21 Mar 2016 23:31:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.145.80 with HTTP; Mon, 21 Mar 2016 23:30:41 -0700 (PDT) In-Reply-To: References: From: "Mr. Jaehoon Paul Jeong" Date: Tue, 22 Mar 2016 15:30:41 +0900 Message-ID: To: "Dr. Karan Verma" Content-Type: multipart/alternative; boundary=94eb2c07b516efd91c052e9d5b79 Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "Prof. Tom Oh" , Russ Housley , "Mr. Jaehoon Paul Jeong" , "its@ietf.org" Subject: Re: [its] review draft "Problem Statement for vehicle-to- infrastructure networking" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 06:31:13 -0000 --94eb2c07b516efd91c052e9d5b79 Content-Type: text/plain; charset=UTF-8 Karan, I am sorry for the misspelling. Thanks for your notification. Best Regards, Paul On Tue, Mar 22, 2016 at 3:28 PM, Dr. Karan Verma wrote: > Sorry I'm Karan not Karen. > > > > On Tuesday 22 March 2016, Mr. Jaehoon Paul Jeong > wrote: > >> Hi Karen, >> Thanks for your valuable comments. >> >> I will try to reflect your comments on the revision. >> >> Thanks. >> >> Best Regards, >> Paul >> >> On Tue, Mar 22, 2016 at 3:22 PM, Dr. Karan Verma < >> karan.verma.phd@gmail.com> wrote: >> >>> Hello Jeong, >>> >>> I review draft "Problem Statement for vehicle-to- infrastructure >>> networking" >>> >>> Commends: >>> >>> - Wireless Access for Vehicular Environment (WAVE)-IEEE 1609 protocols >>> are also under development to support mobile communications. >>> -VANET is accompanied by some constraints due to (i) restricted >>> roads; (ii) limited bandwidth due to absence of a central coordinator that >>> controls and manages communications between nodes; (iii) disconnect >>> problems due to frequent network fragmentation; and (iv) fading signals >>> caused by objects that form obstacles between communicating nodes. >>> >>> >>> 1. In draft not explain about OBU (On-Board Unit), it's not possible V2I >>> without communicate with OBU. >>> 2. Not explain how can control the incoming traffic (e.g., collision >>> avoidance) to other vehicle. >>> 3. Not explain distributed RSU request. >>> 4. where you stored incoming IP addresses request. >>> 5. Please included filtration process to distributed incoming traffic >>> (e.g., it's mobile IP or Infrastructure request). >>> 6. not synchronization processes inter-networking given some time may be >>> used time synchronization process. >>> 7. IP addressing process used may be IP-CHOCK. >>> 8. May be used Bloom-fliter system given more secure for DDoS attacks. >>> >>> >>> Thank You >>> >>> -- >>> Best Regards >>> >>> Dr. Karan Verma >>> Assistant Professor >>> Computer Science and Engineering Dept. >>> Central University Rajasthan, India >>> Website: www.drkaranverma.com >>> Phone: +917568169258 >>> >>> This email has been sent from a virus-free computer protected by Avast. >>> www.avast.com >>> >>> <#6387798047367926840_-7782309100366217828_5125783738851981064_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >>> >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>> >>> >> >> >> -- >> =========================== >> Mr. Jaehoon (Paul) Jeong, Ph.D. >> Assistant Professor >> Department of Software >> Sungkyunkwan University >> Office: +82-31-299-4957 >> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >> >> > > > -- > Best Regards > > Dr. Karan Verma > Assistant Professor > Computer Science and Engineering Dept. > Central University Rajasthan, India > Website: www.drkaranverma.com > Phone: +917568169258 > > -- =========================== 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 --94eb2c07b516efd91c052e9d5b79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Karan,
    I am sorry for the misspelling.

    <= /div>
    Thanks for your notification.

    Best Regar= ds,
    Paul

    On Tue, Mar 22, 2016 at 3:28 PM, Dr. Karan Verma <kar= an.verma.phd@gmail.com> wrote:
    Sorry I'm Karan not Karen.=C2=A0



    On Tuesday 22 March 2016, Mr. Jaehoon Paul= Jeong <jaeh= oon.paul@gmail.com> wrote:
    Hi Karen,
    Thanks for your valuable comments.

    I will try to reflect your comments on the revision.
    Thanks.

    Best Regards,
    Paul

    On Tue,= Mar 22, 2016 at 3:22 PM, Dr. Karan Verma <karan.ve= rma.phd@gmail.com> wrote:
    <= div dir=3D"ltr">
    Hello Jeong,

    I review draft "Problem Statement for vehicle-to- infrast= ructure networking"

    Commends:=C2=A0=

    =C2=A0-= Wireless Access for Vehicular Environment (WAVE)-IEEE 1609 protocols =C2=A0 =C2=A0are also unde= r development=C2=A0t= o support mobile communications.
    =C2=A0-VANET is=C2=A0 accompanied by some constraints due to (i) restricted roads; (ii) limited bandwidth due to absence of a central coordinator that controls and manages communications between nodes; (iii) disconnect problems due to frequent network fragmentation; and (iv) fading signals caused by objects that form obstacles between communicating nodes.<= /span>


    1. In draft not explain about OBU (On-Board Unit), it's not pos= sible V2I without communicate with OBU.=C2=A0
    2. Not explain how can control the incoming traffic (e.= g., collision avoidance) to other vehicle.
    3. Not explain distributed RSU request.=C2=A0
    4. where you stored incoming IP addresses = request.=C2=A0
    5. Please inc= luded filtration process to distributed incoming traffic (e.g., it's mo= bile IP or Infrastructure request).=C2=A0
    6. not synchronization processes inter-networking given some = time may be used time synchronization process.=C2=A0
    7. IP addressing process used may be IP-CHOCK.
    8. May be used Bloom-fliter sys= tem given more secure for DDoS attacks.=C2=A0

    Thank You =C2=A0=C2=A0

    --
    Best Regards=C2=A0

    <= span style=3D"font-size:small">Dr. Karan Verma=C2=A0
    Assistant Professor=C2=A0=C2= =A0
    Computer Science and Engineerin= g Dept.
    Central Un= iversity Rajasthan, India=C2=A0
    Phone: +917568169258

    This email has been = sent from a virus-free computer protected by Avast.
    www.avast.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. J= aehoon (Paul) Jeong, Ph.D.
    Assistant Professor
    Department of Software=
    Sungkyunkwan University
    Office: +82-31-299-4957
    Email: jaehoon= .paul@gmail.com,=C2=A0pauljeo= ng@skku.edu
    Personal Homepage: http://iotlab.skku.edu/people-jaeh= oon-jeong.php


    --
    Best Regards=C2=A0

    Dr. Karan Verma=C2=A0
    Assistant Professor=C2=A0=C2=A0
    Computer Science and Engineering Dept.
    Central University Rajast= han, India=C2=A0
    Phone: +917568169258




    --
    =
    =
    =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 Pr= ofessor
    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-jeo= ng.php
    --94eb2c07b516efd91c052e9d5b79-- From nobody Tue Mar 22 04:08:45 2016 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 8649412D7FC for ; Tue, 22 Mar 2016 04:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 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, HK_NAME_FM_MR_MRS=1.499, 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 WOWEbaxPQ42y for ; Tue, 22 Mar 2016 04:08:42 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 181BF12D106 for ; Tue, 22 Mar 2016 04:08:21 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id h129so249273059ywb.1 for ; Tue, 22 Mar 2016 04:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nlox/s00hEZ2z1XnlkAjGFwrfhe0R+WY2HHX4aCf6Pw=; b=nXayqaoleJAjdd/AsctY5skOBcMV0zs/tQbYbEh9x2hWH8CaAH6SzYrTSHJ0GTsMoM eRRPoJXvyi06aCTxxxxp3CdAD7qu2AiZDj9Vu216rcWyjEprhkhiVbFv72j6rf/T/XsJ YYvxrplPXM4jAb4jHuWf6HxRD32EQrG+Fr+wmuD9P6gudvZnVAJLSDt1vdf3PU/y+7e8 5Ev22Z6V+yC6K++D+b+35Wnuk3mW7Sd8LInTThRqi6InS0UWS6FHvjtzYmkuFaFPGvnl Gm3x1GuPOv5ZxKCzzGrv4rV2Bcdsh0qmWuI+5My+U34TZANEvR1DR0lsXt4pvFF+6cN5 pEZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nlox/s00hEZ2z1XnlkAjGFwrfhe0R+WY2HHX4aCf6Pw=; b=khvGxC5dHgmBLy07VVrH1Tw4NGnNt+ntl6EKYTxLMgxcukzAKKsQOXcW/NTthdKkOY aGgsZaGt+wBdZaEJu67RzRfMzSPPBA0XUA+3WuULrQ8QENziLB6LFN3+h7aAhe5RktcS bVZBhfI316Dhk+qAbJ+2MKpjmi4QgDZCGIpToBE/711OxsIBRFYtR9dpZYbu7cTf0wD/ ZXu/OhFCpbh/4JyWRJ3bB5HwG1W0I2vZeA0KR4POhhLNet9CSADLV9fVVDBXYiCj515r S8nx6F4fakukXZt/DWl3Tzmw+KfzFls4F45g/fb/DLJSUX+Qk8fv6LLf73d5VAsvbdz9 K2DA== X-Gm-Message-State: AD7BkJLbl7tfMvR0A1VnsVtlT25SVcKTO1Y1S364BmOI7PEQjrOKSIMMonYuWkcAW248IrObSBL+rB473hscRg== X-Received: by 10.37.90.135 with SMTP id o129mr12419043ybb.27.1458644900242; Tue, 22 Mar 2016 04:08:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.145.80 with HTTP; Tue, 22 Mar 2016 04:07:50 -0700 (PDT) In-Reply-To: <56F08D7C.4080208@acm.org> References: <56F08D7C.4080208@acm.org> From: "Mr. Jaehoon Paul Jeong" Date: Tue, 22 Mar 2016 20:07:50 +0900 Message-ID: To: Erik Nordmark Content-Type: multipart/alternative; boundary=001a1140f55e21ebc0052ea13be2 Archived-At: Cc: its@ietf.org Subject: Re: [its] Thoughts on source IP addresses in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 11:08:44 -0000 --001a1140f55e21ebc0052ea13be2 Content-Type: text/plain; charset=UTF-8 Hi Erik, These are good comments on IP address in V2I and V2V communications. I will also address your comments on the revised version of draft-jeong-its-v2i-problem-statement . Thanks. Best Regards, Paul On Tue, Mar 22, 2016 at 9:10 AM, Erik Nordmark wrote: > I've looked through draft-jeong-its-v2i-problem-statement and the > background on ITS that was given at recent IETF plenary. > > It seems like there are quite different performance expectations for > different types of V2V and V2I which has an impact on what one might want > to do in terms of IP address management. > > Some use cases are about connecting to the Internet, where it seems like > one would want a global IP address with some support for mobility. (But > there are privacy considerations that probably mean we don't want to keep > the IP address for a long time.) Using DHCP to assign such addresses might > be reasonable. > > But for some V2V and vehicle to roadside use cases the performance > requirements might not allow for waiting for IP address assignment, while > at the same time the communication is entirely local. In such a case there > isn't a need for a global IP address. One could even argue that there is no > need for an IP address at all if the purpose is to notify neighboring > vehicles about a hazard or that I've slammed on the brakes. > > One could potentially send such a packets using a link-local source > address (and multicast them to a link-local group). > But that still requires having a link-local address, and concerns about > privacy means we need to change that source address. But it wouldn't serve > any purpose if the message is unidirectional. > > I think we could consider sending such packets with the unspecified > (all-zeros) IPv6 source address. > We typically don't use this (an exception is Duplicate Address Detection) > but for local unidirectional traffic it is an option to consider if the > performance/privacy of IP address assignment is an issue. > > Regards, > Erik > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --001a1140f55e21ebc0052ea13be2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi Erik,
    These are good comments on IP address in V2I = and V2V communications.
    I will also address your comments on the = revised version of=C2=A0
    draft-j= eong-its-v2i-problem-statement=C2= =A0.

    Thanks.

    Best Regards,
    Paul

    On = Tue, Mar 22, 2016 at 9:10 AM, Erik Nordmark <nordmark@acm.org> wrote:
    I've looked through draft-= jeong-its-v2i-problem-statement and the background on ITS that was given at= recent IETF plenary.

    It seems like there are quite different performance expectations for differ= ent types of V2V and V2I which has an impact on what one might want to do i= n terms of IP address management.

    Some use cases are about connecting to the Internet, where it seems like on= e would want a global IP address with some support for mobility. (But there= are privacy considerations that probably mean we don't want to keep th= e IP address for a long time.) Using DHCP to assign such addresses might be= reasonable.

    But for some V2V and vehicle to roadside use cases the performance requirem= ents might not allow for waiting for IP address assignment, while at the sa= me time the communication is entirely local. In such a case there isn't= a need for a global IP address. One could even argue that there is no need= for an IP address at all if the purpose is to notify neighboring vehicles = about a hazard or that I've slammed on the brakes.

    One could potentially send such a packets using a link-local source address= (and multicast them to a link-local group).
    But that still requires having a link-local address, and concerns about pri= vacy means we need to change that source address. But it wouldn't serve= any purpose if the message is unidirectional.

    I think we could consider sending such packets with the unspecified (all-ze= ros) IPv6 source address.
    We typically don't use this (an exception is Duplicate Address Detectio= n) but for local unidirectional traffic it is an option to consider if the = performance/privacy of IP address assignment is an issue.

    Regards,
    =C2=A0 =C2=A0Erik

    _______________________________________________
    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 ProfessorDepartment of Software
    Sungkyunkwan University
    Office: +82-31-299-4= 957
    Email: j= aehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu<= br>Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
    --001a1140f55e21ebc0052ea13be2-- From nobody Tue Mar 22 05:28:57 2016 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 02E8612D1ED for ; Mon, 21 Mar 2016 19:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggrdX5L5KpJd for ; Mon, 21 Mar 2016 19:13:35 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 2DC2812D0CC for ; Mon, 21 Mar 2016 19:13:35 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id g127so237361462ywf.2 for ; Mon, 21 Mar 2016 19:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=QOsvsO2bLY8kCuamkbqoL254WozZY25GubdxUXSvewE=; b=KWMrQly/psxQTRuofQE4qwlteFBtoi1W+/0cOY4GzNC6o67qxv/HgGC08kO8aUZgY5 a+wgEEUvcWXycUF1aurFN41SA3tOjvI35Q3dGz/XW3ygfuD3OKroj/s6Wqt7e224Z3en g1uGXaf1lBixMbpshixeLRJRcoK/UZ7L1CqcjXR12POX5UWX1LQF0aiJxuO+fXPu6TVP J9LFIswlrELeN9/Zmdt5robYrVbcPH4SRA3VC3qg2cHqQNbf20vNF68oPn5pU8hegj2D 7rgmdPoYcKnxRiYuRzp7Vv9XSTQXHBx/ESAKGPEPP/rlEStYHtsaWZbYruH2yA0ldCyj DAzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=QOsvsO2bLY8kCuamkbqoL254WozZY25GubdxUXSvewE=; b=LFa7CmI8gABtVSnBlvwmh/tIhnh+swfiDTJNM/1dHdYttn0XDr9oV0gvBa9k6aX4OJ T+yT6nBOcOZHjjU+7ywA54OaRzt6gT77Vz1Tc8ai9FOXudO5DIcWnlLR2+KwYSpb+fI9 lhuX84n1pUFBm34pcH7tFm8LYQY0M10LiSFOjZuFdG/voG5eSiDaERpwfSgIXcdOoOBD h4iHTTkkaCZQFDpRo+cRs4zHMEPwXLI1QOPlLK7zMhG7TraH4TAPkcxb5gydrIPximqk LvwRgfqV9BfUn3upwbuWbO/+hp1UoecPbGU9rCczIwHS8IyC/amLqIZ8y/131qmWX2VR ZCGA== X-Gm-Message-State: AD7BkJKod9vayx3h3WmKfL1JQsgYUNCrLKi9dooEDhXitam9DjuUYR/tXqdFLu1zH2AytA== X-Received: by 10.13.211.131 with SMTP id v125mr15281573ywd.148.1458612814465; Mon, 21 Mar 2016 19:13:34 -0700 (PDT) Received: from new-host.home (pool-72-74-19-153.bstnma.fios.verizon.net. [72.74.19.153]) by smtp.gmail.com with ESMTPSA id q10sm12067173ywc.27.2016.03.21.19.13.33 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Mar 2016 19:13:33 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_7275B655-D731-41A5-BEF6-FB6510E18345"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Margaret Cullen In-Reply-To: <56F08D7C.4080208@acm.org> Date: Mon, 21 Mar 2016 22:13:32 -0400 Message-Id: References: <56F08D7C.4080208@acm.org> To: Erik Nordmark X-Mailer: Apple Mail (2.1510) Archived-At: X-Mailman-Approved-At: Tue, 22 Mar 2016 05:28:52 -0700 Cc: its@ietf.org Subject: Re: [its] Thoughts on source IP addresses in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 02:13:37 -0000 --Apple-Mail=_7275B655-D731-41A5-BEF6-FB6510E18345 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 21, 2016, at 8:10 PM, Erik Nordmark wrote: >=20 > One could potentially send such a packets using a link-local source = address (and multicast them to a link-local group). > But that still requires having a link-local address, and concerns = about privacy means we need to change that source address. But it = wouldn't serve any purpose if the message is unidirectional. >=20 > I think we could consider sending such packets with the unspecified = (all-zeros) IPv6 source address. > We typically don't use this (an exception is Duplicate Address = Detection) but for local unidirectional traffic it is an option to = consider if the performance/privacy of IP address assignment is an = issue. I think a defined special-use global address (the same for everyone) = would be better for this purpose, as it would not restrict the use of a = multi-link network within the vehicle, or require the receiving stack to = accept packets from the all-zeros address (which some stacks may not = right now). Margaret --Apple-Mail=_7275B655-D731-41A5-BEF6-FB6510E18345 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJW8KpMAAoJEJrxOXzI3ic/mkQIAJeXzh/SDKc3TgYAE8JBdSY5 essZqotlmcLdmqNTUksbese1o00LTjEGb67wYrgG2xHVjv05ZAxPEBT0n18GXCvF 4cDCOiNOMgv1/nl5Sp+4fXosjyKkNVnlexDLDWSq7a2FBN01eWtrvPdrKByZk/Lh jWx96cphUGEs35fsVjILSNP9L/U1Aftj/80bNkaDpPcEh/YItvUaIcx+iDSJ6+UD oY272ZNoZXoeiy7bR4LL7imany0JZc9C5B8ViI9BrCKbPdKivDDAtCanu/IfxO0t 9aMbxSo1ngTQRjyNGChXo9nBUI3qaOWZxvJxcP8ZtRoDTqxWEIzZpqHvb1oJdTA= =C/1X -----END PGP SIGNATURE----- --Apple-Mail=_7275B655-D731-41A5-BEF6-FB6510E18345-- From nobody Tue Mar 22 10:08:14 2016 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 7885912D845 for ; Tue, 22 Mar 2016 10:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, 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 Sy2id3EwhxRe for ; Tue, 22 Mar 2016 10:08:10 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 3596F12D689 for ; Tue, 22 Mar 2016 10:08:10 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id 4so188125033pfd.0 for ; Tue, 22 Mar 2016 10:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=LsLFQUbzefsno0e7E0Bn+d4jjpwWRlYhxNpiCOLJkkY=; b=rHlVTiNacylhInPsVFIOAWYjXaqAnQxPiA0Tt1y7YobfTmbYaiV5qWCFjrjnhDXR1r ieEP9G4KiciWwCKezCLwqa+9CuA49kz1A5OuafAq4aTf7mELrTbBzyBsjSFfLecpP4Fg NTtVgLCYE8NPaeiUxMbLNWQJ3vzDpMxpm54f5VUPUjJ3TJ7YsVv6GQlKVxLGMKKbg8H5 VFm8Tw7t3BnVCcEVbRZhMkCjV7AYzuUeSXdTMuwhI8KZdA6RPbop/GpoJdn0rUX+U7bb /Rz4e5e/5redntwIaT/ij6G+QcpBhu/7rz69KQ+prTCNf7HFF7B6t+/KkTcvh42F/svH ciNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=LsLFQUbzefsno0e7E0Bn+d4jjpwWRlYhxNpiCOLJkkY=; b=lWaxFvdiDBGICcWn5LCvfS64YJwD/9+scODI46m3bYYi7L6fDpr7+8nBz0bg+W0dDj TyNzWy02wYwXFwZ0qWKvgds51P28Hmwqy1NyMRaesZjldwbwOOGUCKrEUlxm2Dqr/P/c FLIn7Q64eVvdVt5R5CipotidezFsuO4x3svTA/a01lZeHgqN0OJrBk1FqUBt1cq8HiIt kO8iqT9i+n+OV/sPsYrwXSoVvkiadjDIUpF6UsaeniHo9d65PvbqFsjNZi3/SIUcIsE9 nMv8++ltYwtlCRDmRNKLIWTXL2MCbhFt+Bygh9ghRET4zhvALfRdIlSOHm01s3QnDXc/ uGHg== X-Gm-Message-State: AD7BkJJRb2qopJk27wL8V6OQjuRRWkQGnmiJDcFU+Auf0AvklPVmlYuQpesyR5my5fHo/w== X-Received: by 10.98.32.136 with SMTP id m8mr55913106pfj.11.1458666489549; Tue, 22 Mar 2016 10:08:09 -0700 (PDT) Received: from ?IPv6:2601:642:c201:788c:c91c:441b:c2ef:eb51? ([2601:642:c201:788c:c91c:441b:c2ef:eb51]) by smtp.gmail.com with ESMTPSA id 8sm49624530pfk.69.2016.03.22.10.08.08 (version=TLS1_2 cipher=AES128-GCM-SHA256 bits=128/128); Tue, 22 Mar 2016 10:08:08 -0700 (PDT) Message-ID: <1458666487.30472.72.camel@localhost.localdomain> From: Rex Buddenberg To: "Mr. Jaehoon Paul Jeong" Date: Tue, 22 Mar 2016 10:08:07 -0700 In-Reply-To: References: <56F08D7C.4080208@acm.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Cc: Erik Nordmark , its@ietf.org Subject: Re: [its] Thoughts on source IP addresses in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 17:08:11 -0000 The vehicle-to-vehicle nomadic topology is exactly what the MANET protocols (OLSR, AODV and ancillaries) cater to. Whatever addressing scheme picked should interface cleanly with those protocols. On Tue, 2016-03-22 at 20:07 +0900, Mr. Jaehoon Paul Jeong wrote: > Hi Erik, > These are good comments on IP address in V2I and V2V communications. > I will also address your comments on the revised version of > draft-jeong-its-v2i-problem-statement . > > > > Thanks. > > > Best Regards, > Paul > > On Tue, Mar 22, 2016 at 9:10 AM, Erik Nordmark > wrote: > I've looked through draft-jeong-its-v2i-problem-statement and > the background on ITS that was given at recent IETF plenary. > > It seems like there are quite different performance > expectations for different types of V2V and V2I which has an > impact on what one might want to do in terms of IP address > management. > > Some use cases are about connecting to the Internet, where it > seems like one would want a global IP address with some > support for mobility. (But there are privacy considerations > that probably mean we don't want to keep the IP address for a > long time.) Using DHCP to assign such addresses might be > reasonable. > > But for some V2V and vehicle to roadside use cases the > performance requirements might not allow for waiting for IP > address assignment, while at the same time the communication > is entirely local. In such a case there isn't a need for a > global IP address. One could even argue that there is no need > for an IP address at all if the purpose is to notify > neighboring vehicles about a hazard or that I've slammed on > the brakes. > > One could potentially send such a packets using a link-local > source address (and multicast them to a link-local group). > But that still requires having a link-local address, and > concerns about privacy means we need to change that source > address. But it wouldn't serve any purpose if the message is > unidirectional. > > I think we could consider sending such packets with the > unspecified (all-zeros) IPv6 source address. > We typically don't use this (an exception is Duplicate Address > Detection) but for local unidirectional traffic it is an > option to consider if the performance/privacy of IP address > assignment is an issue. > > Regards, > Erik > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > -- > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Tue Mar 22 10:46:21 2016 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 EDB7612D564 for ; Tue, 22 Mar 2016 10:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 yzd--sbhzEWp for ; Tue, 22 Mar 2016 10:46:19 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 8E5A512D13C for ; Tue, 22 Mar 2016 10:46:18 -0700 (PDT) Received: from [172.22.227.238] ([162.210.130.3]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u2MHk6bF022127 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 22 Mar 2016 10:46:06 -0700 To: Margaret Cullen , Erik Nordmark References: <56F08D7C.4080208@acm.org> From: Erik Nordmark Message-ID: <56F184DE.6050403@acm.org> Date: Tue, 22 Mar 2016 10:46:06 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYMydqZnQ9qtDw6xodgBQrsgWcdbe/IcHXjbbTuG/B3bKdVBQpAzmnltRgJGpyhot9v3WvRDup58Iq/el7qBegk X-Sonic-ID: C;onBX9FXw5RGBEI36ZLXa/Q== M;eD979FXw5RGBEI36ZLXa/Q== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Cc: its@ietf.org Subject: Re: [its] Thoughts on source IP addresses in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 17:46:20 -0000 On 3/21/16 7:13 PM, Margaret Cullen wrote: > On Mar 21, 2016, at 8:10 PM, Erik Nordmark wrote: >> One could potentially send such a packets using a link-local source address (and multicast them to a link-local group). >> But that still requires having a link-local address, and concerns about privacy means we need to change that source address. But it wouldn't serve any purpose if the message is unidirectional. >> I think we could consider sending such packets with the unspecified (all-zeros) IPv6 source address. >> We typically don't use this (an exception is Duplicate Address Detection) but for local unidirectional traffic it is an option to consider if the performance/privacy of IP address assignment is an issue. > > I think a defined special-use global address (the same for everyone) would be better for this purpose, as it would not restrict the use of a multi-link network within the vehicle, or require the receiving stack to accept packets from the all-zeros address (which some stacks may not right now). Margaret. I suspect we should first discuss the need before going to far down into implementation. I don't claim to understand the performance needs around IP address acquisition for ITS to know whether we need something different than DHCP+SLAAC. But as a quick note, a global anycast source address that you suggest might have operational issues. For instance, you might think you can deliver ICMP errors back to that address, or traceroute towards it, but doing so leads to surprising results. Presumably no stack should respond to an NS or ICMP echo to that address, which means it might need to be marked as 'anycast' in the stack. I haven't checked whether stacks allow such addresses to be used as a source. Thanks, Erik From nobody Tue Mar 22 10:50:50 2016 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 5B0D912D1D0 for ; Tue, 22 Mar 2016 10:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 6E1cJtFVFsp6 for ; Tue, 22 Mar 2016 10:45:42 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 8529E12D13C for ; Tue, 22 Mar 2016 10:45:42 -0700 (PDT) Received: from [172.22.227.238] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u2MHjdMI016555 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 22 Mar 2016 10:45:40 -0700 To: Rex Buddenberg , "Mr. Jaehoon Paul Jeong" References: <56F08D7C.4080208@acm.org> <1458666487.30472.72.camel@localhost.localdomain> From: Erik Nordmark Message-ID: <56F184C3.2050106@sonic.net> Date: Tue, 22 Mar 2016 10:45:39 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1458666487.30472.72.camel@localhost.localdomain> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVb419vvbqwDV4ImwBpL7CgwP6QtlC7D2jKT6dk9bYOQ/Lio2yQdu2abms9TIXcHi2HUQtaaq80IcZniZKjD0ueF X-Sonic-ID: C;lg5T5FXw5RGmO5FDXdaMvg== M;et915FXw5RGmO5FDXdaMvg== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: X-Mailman-Approved-At: Tue, 22 Mar 2016 10:50:49 -0700 Cc: Erik Nordmark , its@ietf.org Subject: Re: [its] Thoughts on source IP addresses in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 17:45:44 -0000 On 3/22/16 10:08 AM, Rex Buddenberg wrote: > The vehicle-to-vehicle nomadic topology is exactly what the MANET > protocols (OLSR, AODV and ancillaries) cater to. Whatever addressing > scheme picked should interface cleanly with those protocols. Rex, The descriptions I've read about some of the ITS use cases leads me to believe that for some of them a link-local multicast is appropriate were one node is sharing some event or state with other nodes in physical proximity. Hence multi-hop IP routing might not be needed? Do the MANET protocols currently support multicast? Thanks, Erik > > > > > On Tue, 2016-03-22 at 20:07 +0900, Mr. Jaehoon Paul Jeong wrote: >> Hi Erik, >> These are good comments on IP address in V2I and V2V communications. >> I will also address your comments on the revised version of >> draft-jeong-its-v2i-problem-statement . >> >> >> >> Thanks. >> >> >> Best Regards, >> Paul >> >> On Tue, Mar 22, 2016 at 9:10 AM, Erik Nordmark >> wrote: >> I've looked through draft-jeong-its-v2i-problem-statement and >> the background on ITS that was given at recent IETF plenary. >> >> It seems like there are quite different performance >> expectations for different types of V2V and V2I which has an >> impact on what one might want to do in terms of IP address >> management. >> >> Some use cases are about connecting to the Internet, where it >> seems like one would want a global IP address with some >> support for mobility. (But there are privacy considerations >> that probably mean we don't want to keep the IP address for a >> long time.) Using DHCP to assign such addresses might be >> reasonable. >> >> But for some V2V and vehicle to roadside use cases the >> performance requirements might not allow for waiting for IP >> address assignment, while at the same time the communication >> is entirely local. In such a case there isn't a need for a >> global IP address. One could even argue that there is no need >> for an IP address at all if the purpose is to notify >> neighboring vehicles about a hazard or that I've slammed on >> the brakes. >> >> One could potentially send such a packets using a link-local >> source address (and multicast them to a link-local group). >> But that still requires having a link-local address, and >> concerns about privacy means we need to change that source >> address. But it wouldn't serve any purpose if the message is >> unidirectional. >> >> I think we could consider sending such packets with the >> unspecified (all-zeros) IPv6 source address. >> We typically don't use this (an exception is Duplicate Address >> Detection) but for local unidirectional traffic it is an >> option to consider if the performance/privacy of IP address >> assignment is an issue. >> >> Regards, >> Erik >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> >> >> >> -- >> =========================== >> Mr. Jaehoon (Paul) Jeong, Ph.D. >> Assistant Professor >> Department of Software >> Sungkyunkwan University >> Office: +82-31-299-4957 >> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > From nobody Tue Mar 22 11:14:39 2016 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 B00E712D116 for ; Tue, 22 Mar 2016 11:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVv6-vRAUAku for ; Tue, 22 Mar 2016 11:14:35 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FED312D0EC for ; Tue, 22 Mar 2016 11:14:35 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u2MIEWPS023274 for ; Tue, 22 Mar 2016 19:14:32 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 65E17204A79 for ; Tue, 22 Mar 2016 19:15:20 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5DE33201ED9 for ; Tue, 22 Mar 2016 19:15:20 +0100 (CET) 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 u2MIEWLb002130 for ; Tue, 22 Mar 2016 19:14:32 +0100 To: its@ietf.org References: <56F08D7C.4080208@acm.org> From: Alexandre Petrescu Message-ID: <56F18B88.1040002@gmail.com> Date: Tue, 22 Mar 2016 19:14:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F08D7C.4080208@acm.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] Thoughts on source IP addresses in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 18:14:37 -0000 Le 22/03/2016 01:10, Erik Nordmark a écrit : > I've looked through draft-jeong-its-v2i-problem-statement and the > background on ITS that was given at recent IETF plenary. > > It seems like there are quite different performance expectations for > different types of V2V and V2I which has an impact on what one might > want to do in terms of IP address management. For example in V2Internet the entertainment apps inside the vehicle may tolerate longer latencies than V2Infrastructure or than V2V. IP address management like in DHCP or SLAAC does involve some additional latency. It is still possible to communicate without involving too long address management operations, like when nodes self-form some of their addresses. > Some use cases are about connecting to the Internet, where it seems > like one would want a global IP address with some support for > mobility. (But there are privacy considerations that probably mean we > don't want to keep the IP address for a long time.) Using DHCP to > assign such addresses might be reasonable. > > But for some V2V and vehicle to roadside use cases the performance > requirements might not allow for waiting for IP address assignment, > while at the same time the communication is entirely local. In such a > case there isn't a need for a global IP address. One could even > argue that there is no need for an IP address at all if the purpose > is to notify neighboring vehicles about a hazard or that I've slammed > on the brakes. > > One could potentially send such a packets using a link-local source > address (and multicast them to a link-local group). Yes, a link-local group may be appropriate between nearbyy vehicles, or between a vehicle and nearby infrastructure like a traffic lights pole. > But that still requires having a link-local address, and concerns > about privacy means we need to change that source address. But it > wouldn't serve any purpose if the message is unidirectional. The privacy aspects are obviously important. A part of the privacy discussion can be geared in the particular context of vehicular communications. We dont care about same privacy concerns in vehicles than in the Internet. For example, we do care about crackers listening to cars passing by and beaconing data. But we trade that against legislation that requires, for example, the windshield to be clear for view as well as the license plate. On another hand, identifiers that change on some dynamic basis, may be advantageously offering privacy, even though crackers can still listen to them. One can think about changing the link-local address dynamically, but not in such a way as to disturb ongoing communications. > I think we could consider sending such packets with the unspecified > (all-zeros) IPv6 source address. We typically don't use this (an > exception is Duplicate Address Detection) but for local > unidirectional traffic it is an option to consider if the > performance/privacy of IP address assignment is an issue. Yes, makes sense to send such packets with the all-zeros src address. However, there is still a need for the receiver to be able to identify the sender somehow, in order to be able to reply better rather than to-everyone (unless they have a dedicated channel which does not noise the others). Alex > > Regards, Erik > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From nobody Tue Mar 22 11:19:38 2016 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 3872812D1E8 for ; Tue, 22 Mar 2016 11:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akNY9Tm-fGQ6 for ; Tue, 22 Mar 2016 11:19:34 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 690DB12D17E for ; Tue, 22 Mar 2016 11:19:34 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u2MIJW5w002031 for ; Tue, 22 Mar 2016 19:19:32 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F1E7020ADC4 for ; Tue, 22 Mar 2016 19:20:19 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EA7D920ADB6 for ; Tue, 22 Mar 2016 19:20:19 +0100 (CET) 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 u2MIJWNp006515 for ; Tue, 22 Mar 2016 19:19:32 +0100 To: its@ietf.org References: <56F08D7C.4080208@acm.org> From: Alexandre Petrescu Message-ID: <56F18CB4.4030705@gmail.com> Date: Tue, 22 Mar 2016 19:19:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] Thoughts on source IP addresses in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 18:19:37 -0000 Le 22/03/2016 03:13, Margaret Cullen a écrit : > > On Mar 21, 2016, at 8:10 PM, Erik Nordmark wrote: >> >> One could potentially send such a packets using a link-local >> source address (and multicast them to a link-local group). But that >> still requires having a link-local address, and concerns about >> privacy means we need to change that source address. But it >> wouldn't serve any purpose if the message is unidirectional. > >> >> I think we could consider sending such packets with the >> unspecified (all-zeros) IPv6 source address. We typically don't use >> this (an exception is Duplicate Address Detection) but for local >> unidirectional traffic it is an option to consider if the >> performance/privacy of IP address assignment is an issue. > > > I think a defined special-use global address (the same for everyone) > would be better for this purpose, as it would not restrict the use > of a multi-link network within the vehicle, I agree - with these moving networks one can not consider multi-link networks beyond the internal structure of the moving network, which is relatively stable. That is because there is a huge difference between the nature of links outside the moving network (outside the vehicle) and inside the moving network (inside a vehicle). For example never there will be LTE _inside_ a moving network to link CAN devices, as much as never there will be a short-range compressed 6lo link outside a fast moving network. > or require the receiving stack to accept packets from the all-zeros > address (which some stacks may not right now). I didnt know that? Would Routers discard RAs from an all-zero src? Alex > > Margaret > > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From nobody Tue Mar 22 11:28:25 2016 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 21E7612D132 for ; Tue, 22 Mar 2016 11:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.333 X-Spam-Level: X-Spam-Status: No, score=-4.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwyRfu_GcVv5 for ; Tue, 22 Mar 2016 11:28:22 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E03912D770 for ; Tue, 22 Mar 2016 11:28:21 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u2MISJN6026868 for ; Tue, 22 Mar 2016 19:28:19 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D1C0520AE3E for ; Tue, 22 Mar 2016 19:29:06 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C92EB20AE3D for ; Tue, 22 Mar 2016 19:29:06 +0100 (CET) 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 u2MISISw013965 for ; Tue, 22 Mar 2016 19:28:19 +0100 To: its@ietf.org References: <56F08D7C.4080208@acm.org> <1458666487.30472.72.camel@localhost.localdomain> From: Alexandre Petrescu Message-ID: <56F18EC2.3090506@gmail.com> Date: Tue, 22 Mar 2016 19:28:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1458666487.30472.72.camel@localhost.localdomain> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] Thoughts on source IP addresses in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 18:28:24 -0000 Le 22/03/2016 18:08, Rex Buddenberg a écrit : > The vehicle-to-vehicle nomadic topology is exactly what the MANET > protocols (OLSR, AODV and ancillaries) cater to. YEs, they try to. But no, in this particular nomadic industry AODV and OLSR are not largely considered. Because they do not deal with stable-structure moving networks that have only 1 fragile IP hop - the one between vehicles. They deal with networks where more IP hops are fragile, in general. That said, if addresses are established ok, then protocols like AODV can certainly take advantage of the addressing architecture. AODV can certainly leverage a potential ITS work: Route Request and obtain correct Route Response in a vehicle-to-vehicle topology as long as the routing table entries are inserted appropriately. > Whatever addressing > scheme picked should interface cleanly with those protocols. YEs, I agree. There can be AODV combined with this work to have a more complete solution. But now let's focus on the ITS first steps. Alex > > > > > On Tue, 2016-03-22 at 20:07 +0900, Mr. Jaehoon Paul Jeong wrote: >> Hi Erik, >> These are good comments on IP address in V2I and V2V communications. >> I will also address your comments on the revised version of >> draft-jeong-its-v2i-problem-statement . >> >> >> >> Thanks. >> >> >> Best Regards, >> Paul >> >> On Tue, Mar 22, 2016 at 9:10 AM, Erik Nordmark >> wrote: >> I've looked through draft-jeong-its-v2i-problem-statement and >> the background on ITS that was given at recent IETF plenary. >> >> It seems like there are quite different performance >> expectations for different types of V2V and V2I which has an >> impact on what one might want to do in terms of IP address >> management. >> >> Some use cases are about connecting to the Internet, where it >> seems like one would want a global IP address with some >> support for mobility. (But there are privacy considerations >> that probably mean we don't want to keep the IP address for a >> long time.) Using DHCP to assign such addresses might be >> reasonable. >> >> But for some V2V and vehicle to roadside use cases the >> performance requirements might not allow for waiting for IP >> address assignment, while at the same time the communication >> is entirely local. In such a case there isn't a need for a >> global IP address. One could even argue that there is no need >> for an IP address at all if the purpose is to notify >> neighboring vehicles about a hazard or that I've slammed on >> the brakes. >> >> One could potentially send such a packets using a link-local >> source address (and multicast them to a link-local group). >> But that still requires having a link-local address, and >> concerns about privacy means we need to change that source >> address. But it wouldn't serve any purpose if the message is >> unidirectional. >> >> I think we could consider sending such packets with the >> unspecified (all-zeros) IPv6 source address. >> We typically don't use this (an exception is Duplicate Address >> Detection) but for local unidirectional traffic it is an >> option to consider if the performance/privacy of IP address >> assignment is an issue. >> >> Regards, >> Erik >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> >> >> >> -- >> =========================== >> Mr. Jaehoon (Paul) Jeong, Ph.D. >> Assistant Professor >> Department of Software >> Sungkyunkwan University >> Office: +82-31-299-4957 >> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Tue Mar 22 12:01:36 2016 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 F3EBC12D8C9 for ; Tue, 22 Mar 2016 12:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 2SwH0tgNU03Q for ; Tue, 22 Mar 2016 12:01:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA0C12DA1E for ; Tue, 22 Mar 2016 12:01:11 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 88E41200A5; Tue, 22 Mar 2016 15:03:50 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E46ED6375A; Tue, 22 Mar 2016 15:01:09 -0400 (EDT) From: Michael Richardson To: Erik Nordmark In-Reply-To: <56F08D7C.4080208@acm.org> References: <56F08D7C.4080208@acm.org> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: its@ietf.org Subject: Re: [its] Thoughts on source IP addresses in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 19:01:34 -0000 --=-=-= Content-Type: text/plain Erik Nordmark wrote: > Some use cases are about connecting to the Internet, where it seems like one > would want a global IP address with some support for mobility. (But there are > privacy considerations that probably mean we don't want to keep the IP > address for a long time.) Using DHCP to assign such addresses might be > reasonable. Or all the privacy enhanced methods... if one cares about privacy, it seems that layer-2 MAC addresses need to be randomized too. > But for some V2V and vehicle to roadside use cases the performance > requirements might not allow for waiting for IP address assignment, while at > the same time the communication is entirely local. In such a case there isn't > a need for a global IP address. One could even argue that there is no need > for an IP address at all if the purpose is to notify neighboring vehicles > about a hazard or that I've slammed on the brakes. I think that the advantage of the IP layer is that we can use route-over mesh network technology to forward the notification to vehicles further away. Stationary roadside warnings, and maybe even public vehicles might actually have opposite privacy implications: i.e. we need to traceability. > One could potentially send such a packets using a link-local source address > (and multicast them to a link-local group). > But that still requires having a link-local address, and concerns about > privacy means we need to change that source address. But it wouldn't serve > any purpose if the message is unidirectional. Why aren't privacy-enhanced link local addresses (7217) useable here? Is the DAD time that you are concerned about? > I think we could consider sending such packets with the unspecified > (all-zeros) IPv6 source address. > We typically don't use this (an exception is Duplicate Address Detection) but > for local unidirectional traffic it is an option to consider if the > performance/privacy of IP address assignment is an issue. I don't quite see the advantage... -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVvGWc4CLcPvd0N1lAQIYlAf6A4u2IrArKCZEHOsoSQ0P+SDq7PtwvI2F Ewt6zRO1Si76owAQvXmX7Ne0MkMJNbpoNTGl+bFGaaHEfSvfHizQAASzzQjTLBZR SPkAWfVAdRcZb5KQ1uJ0jpnNuIFynh5SxOJirTzNSg86+m9kd0xgKAXMGT3YxKDJ 1WEwdFfKqkDZsuD8oO2pVvb4rM0OFzE2rmSwnLLCSTNzzTL1v4YSPN67uxx/JssR Y8/UJu07fRffxM9ne+lzCiq9lUSU25vpP9RWtHEGL+jUMXe0RjtH56av2saydRd9 Rty92Y0Gp1jSHI/Tg6Llh/G3oVRzNI0rXHFt9Q3IS5R1YCYTV7wOhA== =nFam -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 22 14:33:27 2016 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 55CEF12D52E for ; Tue, 22 Mar 2016 14:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, 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 xPVz5l5vRX7Q for ; Tue, 22 Mar 2016 14:33:24 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 AF1A412D558 for ; Tue, 22 Mar 2016 14:33:24 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id 4so196031199pfd.0 for ; Tue, 22 Mar 2016 14:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=I3OnauU9p9kUR61EUiOrSZcc5VV1yprMTpT+DdetoNI=; b=i+u/PxKDmYoIWfe7rBlBdOsusAxexZP7Rthi4kMOYMCGhZPHpJYPDofKJ0nf9bEQDr e0uPgoEwQQkPhbB2tu2ZNKU0oGpemV4x/2dwH0qHOoUMoHBa1/EKZdbyXj3Gy9le97Wq FNIRgNokh862zasgMjcmItdHG0+fK9RxOJUJeKGCh7ZptTLMkvDfp6fcEQO3X622HTeP lIpnxwZWhyCrWkfPhrIBvqRyQvCTUyRCWVz3dY+Md03qOY+oGL1agoLhePZdVzfaWAdI KpuebuMwKMNDBqzI8dNbSYMgYygRtZR7tGrnDFftsaMTcdQ9cgg81+wCIp4uOZzqdWt2 TZ0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=I3OnauU9p9kUR61EUiOrSZcc5VV1yprMTpT+DdetoNI=; b=PZQkWg7z8IKirv01mVbq1OM0ZSUILJNRDKErNZ5xfSgVqNMM25g2wY76X03G7MPqDL qogS9g9ccGboR4MV34oRos55/ZYkt/foEE2T1HQOu7W40/Isv9UvbmL9uEZjUECNxTyt vTpxrLOWri3PVwR3MhbMKTnbQPoKPa4L/Cpx5PSsXoRhDUZ0CCErOguMtYQ8arjHW9Tr V7BJ8mPBDGiQRFP0xGIiEdpE0Ia6l9oRWdKQRjfZqhcgbn6qFOeOJ+HeWb9eF7aE7/mx 2maSs1S4pzyl8FFGYmx5Cq4TsT0NsGG/usdla567/dtMpVToJGsiQ5KcZyZ/57PZO5Ni ypOg== X-Gm-Message-State: AD7BkJIOV4IYU97minNJVI4NASvHaAyLDN6oLWTctRmA1gJjyeSeI7YMy4jrjg03dmIgCw== X-Received: by 10.66.178.238 with SMTP id db14mr57406013pac.157.1458682404223; Tue, 22 Mar 2016 14:33:24 -0700 (PDT) Received: from ?IPv6:2601:642:c201:788c:c91c:441b:c2ef:eb51? ([2601:642:c201:788c:c91c:441b:c2ef:eb51]) by smtp.gmail.com with ESMTPSA id kw10sm50566931pab.0.2016.03.22.14.33.22 (version=TLS1_2 cipher=AES128-GCM-SHA256 bits=128/128); Tue, 22 Mar 2016 14:33:23 -0700 (PDT) Message-ID: <1458682401.30472.78.camel@localhost.localdomain> From: Rex Buddenberg To: Erik Nordmark Date: Tue, 22 Mar 2016 14:33:21 -0700 In-Reply-To: <56F184C3.2050106@sonic.net> References: <56F08D7C.4080208@acm.org> <1458666487.30472.72.camel@localhost.localdomain> <56F184C3.2050106@sonic.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Cc: Erik Nordmark , "Mr. Jaehoon Paul Jeong" , its@ietf.org Subject: Re: [its] Thoughts on source IP addresses in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 21:33:26 -0000 Erik, Several people seem to think that one-hop solves all the problems. I don't believe that. First of all, look inside the automobile. There are likely to be several end systems, therefore a LAN within the vehicle (by whatever name) is likely. If not today, then a year or two. That's the first hop. The second hop is the radio hop. Followed by another hop in the destination vehicle LAN. Second of all, there are a lot of use cases dealing with highway travel like a 'virtual siren' for an ambulance. The difficulty here is that we need to reach around corners -- for example a cross street with RF-obstructing buildings on the corners. Unwarned cross traffic is lethal to ambulances in a hurry. So you have at least two hops of RF. I think trying to wish these requirements away is shortsighted. b On Tue, 2016-03-22 at 10:45 -0700, Erik Nordmark wrote: > On 3/22/16 10:08 AM, Rex Buddenberg wrote: > > The vehicle-to-vehicle nomadic topology is exactly what the MANET > > protocols (OLSR, AODV and ancillaries) cater to. Whatever addressing > > scheme picked should interface cleanly with those protocols. > > Rex, > > The descriptions I've read about some of the ITS use cases leads me to > believe that for some of them a link-local multicast is appropriate were > one node is sharing some event or state with other nodes in physical > proximity. Hence multi-hop IP routing might not be needed? > > Do the MANET protocols currently support multicast? > > Thanks, > Erik > > > > > > > > > > > On Tue, 2016-03-22 at 20:07 +0900, Mr. Jaehoon Paul Jeong wrote: > >> Hi Erik, > >> These are good comments on IP address in V2I and V2V communications. > >> I will also address your comments on the revised version of > >> draft-jeong-its-v2i-problem-statement . > >> > >> > >> > >> Thanks. > >> > >> > >> Best Regards, > >> Paul > >> > >> On Tue, Mar 22, 2016 at 9:10 AM, Erik Nordmark > >> wrote: > >> I've looked through draft-jeong-its-v2i-problem-statement and > >> the background on ITS that was given at recent IETF plenary. > >> > >> It seems like there are quite different performance > >> expectations for different types of V2V and V2I which has an > >> impact on what one might want to do in terms of IP address > >> management. > >> > >> Some use cases are about connecting to the Internet, where it > >> seems like one would want a global IP address with some > >> support for mobility. (But there are privacy considerations > >> that probably mean we don't want to keep the IP address for a > >> long time.) Using DHCP to assign such addresses might be > >> reasonable. > >> > >> But for some V2V and vehicle to roadside use cases the > >> performance requirements might not allow for waiting for IP > >> address assignment, while at the same time the communication > >> is entirely local. In such a case there isn't a need for a > >> global IP address. One could even argue that there is no need > >> for an IP address at all if the purpose is to notify > >> neighboring vehicles about a hazard or that I've slammed on > >> the brakes. > >> > >> One could potentially send such a packets using a link-local > >> source address (and multicast them to a link-local group). > >> But that still requires having a link-local address, and > >> concerns about privacy means we need to change that source > >> address. But it wouldn't serve any purpose if the message is > >> unidirectional. > >> > >> I think we could consider sending such packets with the > >> unspecified (all-zeros) IPv6 source address. > >> We typically don't use this (an exception is Duplicate Address > >> Detection) but for local unidirectional traffic it is an > >> option to consider if the performance/privacy of IP address > >> assignment is an issue. > >> > >> Regards, > >> Erik > >> > >> _______________________________________________ > >> its mailing list > >> its@ietf.org > >> https://www.ietf.org/mailman/listinfo/its > >> > >> > >> > >> > >> -- > >> =========================== > >> Mr. Jaehoon (Paul) Jeong, Ph.D. > >> Assistant Professor > >> Department of Software > >> Sungkyunkwan University > >> Office: +82-31-299-4957 > >> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > >> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > >> > >> _______________________________________________ > >> its mailing list > >> its@ietf.org > >> https://www.ietf.org/mailman/listinfo/its > > > From nobody Wed Mar 23 10:42:52 2016 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 D9A7712D612 for ; Wed, 23 Mar 2016 10:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.465 X-Spam-Level: X-Spam-Status: No, score=-101.465 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_REMOTE_IMAGE=0.01, URIBL_GREY=0.424, USER_IN_WHITELIST=-100] 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 ifoaA9juA3sM for ; Wed, 23 Mar 2016 10:42:48 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 749F512D725 for ; Wed, 23 Mar 2016 10:42:48 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id D6F4CF2401F for ; Wed, 23 Mar 2016 13:42:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id RTCcxjyi2TOZ for ; Wed, 23 Mar 2016 13:28:57 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id F13CAF24035 for ; Wed, 23 Mar 2016 13:42:36 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_FC096240-94D1-4819-961D-F08738B5E71D" Date: Wed, 23 Mar 2016 13:42:35 -0400 References: To: its@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [its] Fwd: Call for Papers: 2016 IEEE Standards Association (IEEE-SA) Ethernet & IP @ Automotive Technology Day X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 17:42:51 -0000 --Apple-Mail=_FC096240-94D1-4819-961D-F08738B5E71D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 FYI > From: "IEEE Standards Association" =20 > Subject: Call for Papers: 2016 IEEE Standards Association (IEEE-SA) = Ethernet & IP @ Automotive Technology Day > Date: March 23, 2016 at 12:36:58 PM EDT > Reply-To: ieee-sa-exec@ieee.org >=20 > Call for Papers: 2016 IEEE Ethernet & IP @ Automotive Technology Day >=20 >=20 >=20 > =20 >=20 > =20 > Call for Papers > 2016 IEEE Ethernet & IP @ Automotive Technology Day =20 > Abstracts Due 22 April 2016 > LEARN MORE =BB > =20 > =20 > IEEE Standards Association (IEEE-SA) wants you to present! >=20 > The IEEE-SA is seeking submissions from individuals interested in = presenting papers at the 2016 IEEE-SA Ethernet & IP Automotive = Technology Day (E&IP@ATD) which will be held 20-21 September 2016 at the = Marriott Rive Gauche Hotel & Conference Center, Paris, France. E&IP@ATD = is the premier venue for Original Equipment Manufacturers (OEMs), = suppliers, semiconductor vendors, and tool providers to receive and = share information on Ethernet in automotive applications. > =20 > Presentation Details > Presentations must provide insights into developments, trends or = solutions with respect to one or more of the following topics: > Applicable use cases of Ethernet for automotive > Role of Ethernet in future E/E architecture > Reliability and quality of Ethernet communication > Ethernet for volume production cars > Cyber security for Ethernet > Additionally, you can submit an abstract for a special session that = will focus on use cases, technical and economic feasibility as well as = timeline of new speed grades that complement the automotive Ethernet PHY = family. >=20 > During the general session, it is intended to allocate 30 minutes to = each speaker for his or her presentation, including 5 minutes Q&A at the = end. However, if it improves the program, the Program Committee reserves = the right to shorten this time. Presentation slides and presentation = language must be English. > =20 > Submissions =20 > To submit an abstract, please download and complete the abstract = submission form(.pdf) (.docx). Please send your completed abstract form = to eipatd-requests@ieee.org. by 22 April 2016. Authors of accepted = papers will be notified in July 2016. Final presentations will be = required by 19 August 2016. >=20 > If you are interested in an exhibit booth, sponsorship opportunities = or need more information in general, please contact = eipatd-requests@ieee.org. > CONTACT US =BB > =20 > =20 > =20 > Copyright 2016 IEEE Standards Association. All Rights Reserved. > IEEE Standards Association | 445 Hoes Lane | Piscataway, NJ = 08854-4141 USA > View Online | Privacy Policy=20 --Apple-Mail=_FC096240-94D1-4819-961D-F08738B5E71D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
    FYI

    Subject: = Call for Papers: = 2016 IEEE Standards Association (IEEE-SA) Ethernet & IP @ Automotive = Technology Day
    Date: = March 23, 2016 at = 12:36:58 PM EDT

    <= div>
    =
    Call for Papers: 2016 IEEE Ethernet & IP @ Automotive = Technology Day


    =
    3D"IEEE
     
    3D"IEEE"
    =
     
    Call for Papers
    2016 IEEE Ethernet & IP = @ Automotive Technology Day  
    Abstracts Due 22 April 2016
    LEARN MORE = =BB
     
     
    IEEE Standards Association (IEEE-SA) wants you to = present!
    3D""
    The IEEE-SA is seeking submissions from individuals = interested in presenting papers at the 2016 IEEE-SA Ethernet & IP = Automotive Technology Day (E&IP@ATD) which will be held 20-21 = September 2016 at the Marriott Rive Gauche Hotel & Conference = Center, Paris, France. E&IP@ATD is the premier venue for Original = Equipment Manufacturers (OEMs), suppliers, semiconductor vendors, and = tool providers to receive and share information on Ethernet in = automotive applications.

     

    Presentation = Details
    Presentations must provide insights into = developments, trends or solutions with respect to one or more of the = following topics:
    • Applicable use cases of Ethernet for = automotive
    • Role of Ethernet in future E/E = architecture
    • Reliability and quality of Ethernet = communication
    • Ethernet for volume production cars
    • Cyber = security for Ethernet
    Additionally, you can submit an abstract for a special = session that will focus on use cases, technical and economic feasibility = as well as timeline of new speed grades that complement the automotive = Ethernet PHY family.

    During the general session, it is intended = to allocate 30 minutes to each speaker for his or her presentation, = including 5 minutes Q&A at the end. However, if it improves the = program, the Program Committee reserves the right to shorten this time. = Presentation slides and presentation language must be English.

     

    Submissions  
    To submit an = abstract, please download and complete the abstract submission form(.pdf) (.docx). Please send your completed abstract form to eipatd-requests@ieee.org. by 22 April = 2016.  Authors of accepted papers will be notified in July 2016. = Final presentations will be required by 19 August 2016.

    If you are interested in an = exhibit booth, sponsorship opportunities or need more information in = general, please contact eipatd-requests@ieee.org.
    CONTACT US = =BB
     
    3D"F"   3D"TW"   3D"YT"   3D"L"
     
    Copyright 2016 IEEE Standards Association. All Rights = Reserved.
    IEEE Standards Association  |  445 Hoes = Lane  |  Piscataway, NJ 08854-4141 USA
    View Online   | &nb= sp; Privacy Policy 

    = --Apple-Mail=_FC096240-94D1-4819-961D-F08738B5E71D-- From nobody Thu Mar 24 11:36:55 2016 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 226DE12D1AC for ; Thu, 24 Mar 2016 11:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.333 X-Spam-Level: X-Spam-Status: No, score=-4.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e22zomHC-G1l for ; Thu, 24 Mar 2016 11:36:53 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0D4B12D0FA for ; Thu, 24 Mar 2016 11:36:52 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u2OIao3J002512 for ; Thu, 24 Mar 2016 19:36:50 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D5833204F04 for ; Thu, 24 Mar 2016 19:37:40 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CD5A8201EDB for ; Thu, 24 Mar 2016 19:37:40 +0100 (CET) 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 u2OIanqQ014686 for ; Thu, 24 Mar 2016 19:36:50 +0100 To: its@ietf.org References: <56F08D7C.4080208@acm.org> <1458666487.30472.72.camel@localhost.localdomain> <56F184C3.2050106@sonic.net> <1458682401.30472.78.camel@localhost.localdomain> From: Alexandre Petrescu Message-ID: <56F433C1.8060203@gmail.com> Date: Thu, 24 Mar 2016 19:36:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1458682401.30472.78.camel@localhost.localdomain> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] Thoughts on source IP addresses in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 18:36:55 -0000 Le 22/03/2016 22:33, Rex Buddenberg a écrit : > Erik, > > Several people seem to think that one-hop solves all the problems. I > don't believe that. > > First of all, look inside the automobile. There are likely to be > several end systems, therefore a LAN within the vehicle (by whatever > name) is likely. If not today, then a year or two. It is today. But how would one compare the fragility of the IP hop between the cars with the solidity of built-in often-wired on-board multiple-subnet IP networks? The problem is how two such 'solid' networks join together for a short oe long while, on relatively known trajectories. This is not a problem of arbitrary movements of nodes on all-wireless links. Alex That's the first > hop. The second hop is the radio hop. Followed by another hop in the > destination vehicle LAN. > > Second of all, there are a lot of use cases dealing with highway travel > like a 'virtual siren' for an ambulance. The difficulty here is that we > need to reach around corners -- for example a cross street with > RF-obstructing buildings on the corners. Unwarned cross traffic is > lethal to ambulances in a hurry. So you have at least two hops of RF. > > I think trying to wish these requirements away is shortsighted. > > b > > > On Tue, 2016-03-22 at 10:45 -0700, Erik Nordmark wrote: >> On 3/22/16 10:08 AM, Rex Buddenberg wrote: >>> The vehicle-to-vehicle nomadic topology is exactly what the MANET >>> protocols (OLSR, AODV and ancillaries) cater to. Whatever addressing >>> scheme picked should interface cleanly with those protocols. >> >> Rex, >> >> The descriptions I've read about some of the ITS use cases leads me to >> believe that for some of them a link-local multicast is appropriate were >> one node is sharing some event or state with other nodes in physical >> proximity. Hence multi-hop IP routing might not be needed? >> >> Do the MANET protocols currently support multicast? >> >> Thanks, >> Erik >> >>> >>> >>> >>> >>> On Tue, 2016-03-22 at 20:07 +0900, Mr. Jaehoon Paul Jeong wrote: >>>> Hi Erik, >>>> These are good comments on IP address in V2I and V2V communications. >>>> I will also address your comments on the revised version of >>>> draft-jeong-its-v2i-problem-statement . >>>> >>>> >>>> >>>> Thanks. >>>> >>>> >>>> Best Regards, >>>> Paul >>>> >>>> On Tue, Mar 22, 2016 at 9:10 AM, Erik Nordmark >>>> wrote: >>>> I've looked through draft-jeong-its-v2i-problem-statement and >>>> the background on ITS that was given at recent IETF plenary. >>>> >>>> It seems like there are quite different performance >>>> expectations for different types of V2V and V2I which has an >>>> impact on what one might want to do in terms of IP address >>>> management. >>>> >>>> Some use cases are about connecting to the Internet, where it >>>> seems like one would want a global IP address with some >>>> support for mobility. (But there are privacy considerations >>>> that probably mean we don't want to keep the IP address for a >>>> long time.) Using DHCP to assign such addresses might be >>>> reasonable. >>>> >>>> But for some V2V and vehicle to roadside use cases the >>>> performance requirements might not allow for waiting for IP >>>> address assignment, while at the same time the communication >>>> is entirely local. In such a case there isn't a need for a >>>> global IP address. One could even argue that there is no need >>>> for an IP address at all if the purpose is to notify >>>> neighboring vehicles about a hazard or that I've slammed on >>>> the brakes. >>>> >>>> One could potentially send such a packets using a link-local >>>> source address (and multicast them to a link-local group). >>>> But that still requires having a link-local address, and >>>> concerns about privacy means we need to change that source >>>> address. But it wouldn't serve any purpose if the message is >>>> unidirectional. >>>> >>>> I think we could consider sending such packets with the >>>> unspecified (all-zeros) IPv6 source address. >>>> We typically don't use this (an exception is Duplicate Address >>>> Detection) but for local unidirectional traffic it is an >>>> option to consider if the performance/privacy of IP address >>>> assignment is an issue. >>>> >>>> Regards, >>>> Erik >>>> >>>> _______________________________________________ >>>> its mailing list >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>>> >>>> >>>> >>>> >>>> -- >>>> =========================== >>>> Mr. Jaehoon (Paul) Jeong, Ph.D. >>>> Assistant Professor >>>> Department of Software >>>> Sungkyunkwan University >>>> Office: +82-31-299-4957 >>>> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >>>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >>>> >>>> _______________________________________________ >>>> its mailing list >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>> >> > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Fri Mar 25 04:12:09 2016 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 43E4612D605 for ; Fri, 25 Mar 2016 04:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfRbY_7gze87 for ; Fri, 25 Mar 2016 04:12:05 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1FCC12D094 for ; Fri, 25 Mar 2016 04:12:04 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u2PBC0qI013852; Fri, 25 Mar 2016 12:12:00 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D45DB200803; Fri, 25 Mar 2016 12:12:51 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C8720200B97; Fri, 25 Mar 2016 12:12:51 +0100 (CET) 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 u2PBC0Wh011422; Fri, 25 Mar 2016 12:12:00 +0100 To: dickroy@alum.mit.edu, its@ietf.org References: <56F08D7C.4080208@acm.org> <1458666487.30472.72.camel@localhost.localdomain> <56F184C3.2050106@sonic.net> <1458682401.30472.78.camel@localhost.localdomain> <56F433C1.8060203@gmail.com> From: Alexandre Petrescu Message-ID: <56F51D00.90802@gmail.com> Date: Fri, 25 Mar 2016 12:12:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] Thoughts on source IP addresses in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 11:12:08 -0000 Le 24/03/2016 23:35, Richard Roy a écrit : > > >> -----Original Message----- From: Alexandre Petrescu >> [mailto:alexandre.petrescu@gmail.com] Sent: Thursday, March 24, >> 2016 11:37 AM To: its@ietf.org Subject: Re: [its] Thoughts on >> source IP addresses in ITS >> >> >> >> Le 22/03/2016 22:33, Rex Buddenberg a écrit : >>> Erik, >>> >>> Several people seem to think that one-hop solves all the >>> problems. I don't believe that. >>> >>> First of all, look inside the automobile. There are likely to >>> be several end systems, therefore a LAN within the vehicle (by >>> whatever name) is likely. If not today, then a year or two. >> >> It is today. >> >> But how would one compare the fragility of the IP hop between the >> cars with the solidity of built-in often-wired on-board >> multiple-subnet IP networks? > > [RR>] That assumes the in-vehicle networks are using IP, which today > they are not. In-vehicle networks _are_ using IP today. A number of office switch manufacturers do offer small-format ruggedized 12V versions of traditional IP-enabled switches to be carried on-board of vehicles including automobiles. Ethernet cables are a reality in many automobiles today. Aftermarket WiFi devices docked on OBDII (VINLI, Samsung) or operator-specific on cigarette lighter (Orange) bring WiFi to the car masses, and IP with it for that matter. This only partially addresses the number 1 feature US consumers are willing to purchase - a WiFi hotspot in the car[ref]. Growth perspectives for more Ethernet and IP presence in more vehicles are easy to detect. > Even if IP does show up, there will still be layer-2 addressing > mechanism (MAC addresses) and bridging/relaying at layer-2 for such > scenarios is mquicker and more bandwidth efficient (over-the-air) so > while one could use IP for such scenarios, it's "provably > suboptimal". Bridging inside a car is an advtageous technique in simplest car networks, inside the car. But certainly bridging must not be used between the inside and the outside of the car. Inside the car: bridging can be cost effective and fast in small in-car networks; but the stronger separation offered by IP routing (rather than MAC bridging) inside a car may offer higher security levels, better safety ensurance: e.g. separate the signal linking the front camera to emergency braking avoiding pedestrians, from the entertainment traffic, inside a car - bridging is less sure for that separation. Bridging between the inside the car and the outside of a car is hardly feasible technically. For one, the MAC traffic outside needs to be clean of the MAC traffic inside the car. Typically the traffic outisde the car is much less intense than inside the car and it should be kept that way: think twice before talking outside the car. More and more designers suggest addition of _their_ application-specific boxes in a car, each with different link types. And their are entitled to, because these modules are so small today. A box already exists there which IP routes between outside and inside (typically the 3G/Ethernet box for driving guidance apps and maps). Then, some app designers want a 802.11p box to realize C-ACC application (80211p/Ethernet box). Then, other designers want a localization app-specific additional box (GNSS/CAN). And so on. It's hard if not impossible to bridge them all. Alex > > Cheers, > > RR > >> >> The problem is how two such 'solid' networks join together for a >> short oe long while, on relatively known trajectories. >> >> This is not a problem of arbitrary movements of nodes on >> all-wireless links. >> >> Alex >> >> That's the first >>> hop. The second hop is the radio hop. Followed by another hop >>> in the destination vehicle LAN. >>> >>> Second of all, there are a lot of use cases dealing with highway >>> travel like a 'virtual siren' for an ambulance. The difficulty >>> here is that we need to reach around corners -- for example a >>> cross street with RF-obstructing buildings on the corners. >>> Unwarned cross traffic is lethal to ambulances in a hurry. So >>> you have at least two hops of RF. >>> >>> I think trying to wish these requirements away is shortsighted. >>> >>> b >>> >>> >>> On Tue, 2016-03-22 at 10:45 -0700, Erik Nordmark wrote: >>>> On 3/22/16 10:08 AM, Rex Buddenberg wrote: >>>>> The vehicle-to-vehicle nomadic topology is exactly what the >>>>> MANET protocols (OLSR, AODV and ancillaries) cater to. >>>>> Whatever addressing scheme picked should interface cleanly >>>>> with those protocols. >>>> >>>> Rex, >>>> >>>> The descriptions I've read about some of the ITS use cases >>>> leads me to believe that for some of them a link-local >>>> multicast is appropriate >> were >>>> one node is sharing some event or state with other nodes in >>>> physical proximity. Hence multi-hop IP routing might not be >>>> needed? >>>> >>>> Do the MANET protocols currently support multicast? >>>> >>>> Thanks, Erik >>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, 2016-03-22 at 20:07 +0900, Mr. Jaehoon Paul Jeong >>>>> wrote: >>>>>> Hi Erik, These are good comments on IP address in V2I and >>>>>> V2V communications. I will also address your comments on >>>>>> the revised version of >>>>>> draft-jeong-its-v2i-problem-statement . >>>>>> >>>>>> >>>>>> >>>>>> Thanks. >>>>>> >>>>>> >>>>>> Best Regards, Paul >>>>>> >>>>>> On Tue, Mar 22, 2016 at 9:10 AM, Erik Nordmark >>>>>> wrote: I've looked through >>>>>> draft-jeong-its-v2i-problem-statement >> and >>>>>> the background on ITS that was given at recent IETF > plenary. >>>>>> >>>>>> It seems like there are quite different performance >>>>>> expectations for different types of V2V and V2I which has >> an >>>>>> impact on what one might want to do in terms of IP address >>>>>> management. >>>>>> >>>>>> Some use cases are about connecting to the Internet, where >> it >>>>>> seems like one would want a global IP address with some >>>>>> support for mobility. (But there are privacy >>>>>> considerations that probably mean we don't want to keep the >>>>>> IP address for >> a >>>>>> long time.) Using DHCP to assign such addresses might be >>>>>> reasonable. >>>>>> >>>>>> But for some V2V and vehicle to roadside use cases the >>>>>> performance requirements might not allow for waiting for >>>>>> IP address assignment, while at the same time the >> communication >>>>>> is entirely local. In such a case there isn't a need for a >>>>>> global IP address. One could even argue that there is no >> need >>>>>> for an IP address at all if the purpose is to notify >>>>>> neighboring vehicles about a hazard or that I've slammed >>>>>> on the brakes. >>>>>> >>>>>> One could potentially send such a packets using a link- >> local >>>>>> source address (and multicast them to a link-local group). >>>>>> But that still requires having a link-local address, and >>>>>> concerns about privacy means we need to change that source >>>>>> address. But it wouldn't serve any purpose if the message >> is >>>>>> unidirectional. >>>>>> >>>>>> I think we could consider sending such packets with the >>>>>> unspecified (all-zeros) IPv6 source address. We typically >>>>>> don't use this (an exception is Duplicate >> Address >>>>>> Detection) but for local unidirectional traffic it is an >>>>>> option to consider if the performance/privacy of IP >>>>>> address assignment is an issue. >>>>>> >>>>>> Regards, Erik >>>>>> >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- =========================== Mr. Jaehoon (Paul) Jeong, >>>>>> Ph.D. Assistant Professor Department of Software >>>>>> Sungkyunkwan University Office: +82-31-299-4957 Email: >>>>>> jaehoon.paul@gmail.com, pauljeong@skku.edu Personal >>>>>> Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>>> >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>> >>>> >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >> > > > From nobody Fri Mar 25 10:04:58 2016 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 05B0212D58C for ; Fri, 25 Mar 2016 10:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 zzjnfzxuaaha for ; Fri, 25 Mar 2016 10:04:54 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id AC6D612D1D6 for ; Fri, 25 Mar 2016 10:04:54 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 2F73DF24069; Fri, 25 Mar 2016 13:04:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id FziK+KWflIFo; Fri, 25 Mar 2016 12:51:06 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id A5742F24062; Fri, 25 Mar 2016 13:04:53 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <56F08D7C.4080208@acm.org> Date: Fri, 25 Mar 2016 13:04:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56F08D7C.4080208@acm.org> To: Erik Nordmark X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: its@ietf.org Subject: Re: [its] Thoughts on source IP addresses in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 17:04:56 -0000 Erik: > I've looked through draft-jeong-its-v2i-problem-statement and the = background on ITS that was given at recent IETF plenary. >=20 > It seems like there are quite different performance expectations for = different types of V2V and V2I which has an impact on what one might = want to do in terms of IP address management. >=20 > Some use cases are about connecting to the Internet, where it seems = like one would want a global IP address with some support for mobility. = (But there are privacy considerations that probably mean we don't want = to keep the IP address for a long time.) Using DHCP to assign such = addresses might be reasonable. >=20 > But for some V2V and vehicle to roadside use cases the performance = requirements might not allow for waiting for IP address assignment, = while at the same time the communication is entirely local. In such a = case there isn't a need for a global IP address. One could even argue = that there is no need for an IP address at all if the purpose is to = notify neighboring vehicles about a hazard or that I've slammed on the = brakes. >=20 > One could potentially send such a packets using a link-local source = address (and multicast them to a link-local group). > But that still requires having a link-local address, and concerns = about privacy means we need to change that source address. But it = wouldn't serve any purpose if the message is unidirectional. >=20 > I think we could consider sending such packets with the unspecified = (all-zeros) IPv6 source address. > We typically don't use this (an exception is Duplicate Address = Detection) but for local unidirectional traffic it is an option to = consider if the performance/privacy of IP address assignment is an = issue. Interesting thought. As I understand the MAC address management, the = MAC address is being changed every 5 minutes. Isn=92t there a IPv6 = address construction that api;d let us construct a link-local address = from that short-lived MAC address? Russ From nobody Tue Mar 29 07:19:14 2016 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 73F3E12D862 for ; Tue, 29 Mar 2016 07:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97MMRp5vMvD9 for ; Tue, 29 Mar 2016 07:19:10 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49CC112D860 for ; Tue, 29 Mar 2016 07:18:54 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u2TEIo3n012509; Tue, 29 Mar 2016 16:18:50 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C3805200B3F; Tue, 29 Mar 2016 16:19:47 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B6FAF20080B; Tue, 29 Mar 2016 16:19:47 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u2TEIoup015496; Tue, 29 Mar 2016 16:18:50 +0200 To: dickroy@alum.mit.edu, its@ietf.org References: <56F08D7C.4080208@acm.org> <1458666487.30472.72.camel@localhost.localdomain> <56F184C3.2050106@sonic.net> <1458682401.30472.78.camel@localhost.localdomain> <56F433C1.8060203@gmail.com> <56F51D00.90802@gmail.com> From: Alexandre Petrescu Message-ID: <56FA8ECA.2090201@gmail.com> Date: Tue, 29 Mar 2016 16:18:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] brdiging (was: Thoughts on source IP addresses in ITS) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 14:19:13 -0000 Le 26/03/2016 00:36, Richard Roy a écrit : > > >> -----Original Message----- From: Alexandre Petrescu >> [mailto:alexandre.petrescu@gmail.com] Sent: Friday, March 25, 2016 >> 4:12 AM To: dickroy@alum.mit.edu; its@ietf.org Subject: Re: [its] >> Thoughts on source IP addresses in ITS >> >> >> >> Le 24/03/2016 23:35, Richard Roy a écrit : >>> >>> >>>> -----Original Message----- From: Alexandre Petrescu >>>> [mailto:alexandre.petrescu@gmail.com] Sent: Thursday, March >>>> 24, 2016 11:37 AM To: its@ietf.org Subject: Re: [its] Thoughts >>>> on source IP addresses in ITS >>>> >>>> >>>> >>>> Le 22/03/2016 22:33, Rex Buddenberg a écrit : >>>>> Erik, >>>>> >>>>> Several people seem to think that one-hop solves all the >>>>> problems. I don't believe that. >>>>> >>>>> First of all, look inside the automobile. There are likely >>>>> to be several end systems, therefore a LAN within the vehicle >>>>> (by whatever name) is likely. If not today, then a year or >>>>> two. >>>> >>>> It is today. >>>> >>>> But how would one compare the fragility of the IP hop between >>>> the cars with the solidity of built-in often-wired on-board >>>> multiple-subnet IP networks? >>> >>> [RR>] That assumes the in-vehicle networks are using IP, which >>> today they are not. >> >> In-vehicle networks _are_ using IP today. >> >> A number of office switch manufacturers do offer small-format >> ruggedized 12V versions of traditional IP-enabled switches to be >> carried on-board of vehicles including automobiles. >> >> Ethernet cables are a reality in many automobiles today. > > [RR>] I have been informed by people who actually build vehicle that > ethernets are only in very few high-end models, and even in those > models, the ethernet portion is still small. Yes, there is a trend in > toward the all-ethernet in-vehicle network, but they are a decade > away. > >> >> Aftermarket WiFi devices docked on OBDII (VINLI, Samsung) or >> operator-specific on cigarette lighter (Orange) bring WiFi to the >> car masses, and IP with it for that matter. This only partially >> addresses the number 1 feature US consumers are willing to purchase >> - a WiFi hotspot in the car[ref]. >> >> Growth perspectives for more Ethernet and IP presence in more >> vehicles are easy to detect. >> >>> Even if IP does show up, there will still be layer-2 addressing >>> mechanism (MAC addresses) and bridging/relaying at layer-2 for >>> such scenarios is mquicker and more bandwidth efficient >>> (over-the-air) so while one could use IP for such scenarios, it's >>> "provably suboptimal". >> >> Bridging inside a car is an advtageous technique in simplest car >> networks, inside the car. > > [RR>] That's how in-vehicle networks work today; whether they call > it bridging or something else doesn't matter. > >> But certainly bridging must not be used between the inside and the >> outside of the car. > > [RR>] I don't understand why you say "must not be used". > Technically, there is nothing preventing bridging between a LAN in > the vehicle and a LAN on the roadside for example. And if you are > concerned about layer-2 security, 802.1X works quite well. 802.1x is good for security, but here the worry is about channel occupation and noise. One doesnt want the numerous packets inside the car to be replicated outside. Because (some of) the outside channels should be kept freer of noise. With pure bridging all data traffic inside the car is transmitted on the outside of the car too. That's noise. On another hand, data traffic from the outside of the car would advantageously be transmitted towards a device inside the car. For example the 79GHz sensor and Road-Side Unit deployed as "mirror" at an intersection would send IP packets to cars' OBUs, which would bridge these packets further down to a device inside the car. This latter direction (from RSU to OBU) is what some people call "bridging" today, and nothing else. But they forget that the car may want to reply back (e.g. OBU asks the RSU the size of the obstacle). And because this direction (from OBU to RSU) is neglected the IP routing capacity of avoiding noise overlooked. >> Inside the car: bridging can be cost effective and fast in small >> in-car networks; but the stronger separation offered by IP routing >> (rather than MAC bridging) inside a car may offer higher security >> levels, > > [RR>] I would disagree. Security should be applied at the > application layer) if you really want end-to-end security. Security > at any lower layer is more prone to attack as we all know, and it > doesn't matter if it's at layer-1, layer-2, layer-3, or higher. I didnt mean security. I meant separation between subnets which is afforded by IP routing as opposed to bridging. I meant to keep packet noise away from fragile places where packet loss may be too risky. This is what bridging can not do. > >> better safety ensurance: e.g. separate the signal linking the front >> camera to emergency braking avoiding pedestrians, from the >> entertainment traffic, inside a car - bridging is less sure for >> that separation. > > [RR>] Again, I would disagree. Whether layer-2 (bridging) or > layer-3 (routing) addressing is used to direct traffic does not > provide any advantage in "signal separation". YEs it does. There are different sets of software dealing with MAC addressing or IP addressing. If one wants to separate outside/inside by just using bridging then one has to a particularly difficult kind of software (kernel, link-layer drivers) which only works on particular links: all IEEE yes, but can't bridge LTE, USB, CAN and others. On the contrary, if one wants to separate the outside/inside of a car by IP routing then one has to simply configure tables which are available on a very wide range of platforms and link layers. Besides, IP routing has much better scalability and discovery characteristics than MAC IEEE bridging. > >> >> Bridging between the inside the car and the outside of a car is >> hardly feasible technically. For one, the MAC traffic outside >> needs to be clean of the MAC traffic inside the car. Typically the >> traffic outisde the car is much less intense than inside the car >> and it should be kept that way: think twice before talking outside >> the car. > > [RR>] Bridging between the inside and the outside of a vehicle is > absolutely technically feasible. Yes, as long as we talk 802.11OCB (aka 802.11p) and Ethernet or WiFi. But one can't bridge a mix containing CAN, USB or LTE. These link types are also highly used in vehicular networks. > The separation of MAC traffic inside and outside the vehicle is > precisely the function of the bridge. Traffic inside the car stays > inside the car. The only traffic that enters the vehicle is that > which is intended for a station/destination in the vehicle. You > don't send ADUs over the air unless they are destined for an entity > outside the vehicle. That depends on how the bridging is configured. The easiest bridge configuration is to replicate everything. If one wants to separate then one has to be explicit about use of MAC protocols for MAC spanning trees. These are either not supported or not cared of in the vehicular settings I have seen. Besides, they dont work with other than IEEE interfaces. >> More and more designers suggest addition of _their_ >> application-specific boxes in a car, each with different link >> types. And their are entitled to, because these modules are so >> small today. A box already exists there which IP routes between >> outside and inside (typically the 3G/Ethernet box for driving >> guidance apps and maps). Then, some app designers want a 802.11p >> box to realize C-ACC application (80211p/Ethernet box). Then, >> other designers want a localization app-specific additional box >> (GNSS/CAN). And so on. It's hard if not impossible to bridge them >> all. > > [RR>] The difficulty arises from the silo thinking of all these > designers! It's however technically feasible to bridge them as long > as there is a one-to-one map between the layer-2 addresses on each > LAN. The real issue is that most these designers think in silos and > want "their" system completely separate from any other system ... > they want complete control ... they don't WANT their system to be > part of a bridged LAN. I agree. > As the number of wireless interfaces proliferates however, the > performance of the systems will monotonically degrade until such time > as none of them function properly. But that's another story for > another day :^))) I agree. Alex > > Cheers, > > RR > >> >> Alex >> >>> >>> Cheers, >>> >>> RR >>> >>>> >>>> The problem is how two such 'solid' networks join together for >>>> a short oe long while, on relatively known trajectories. >>>> >>>> This is not a problem of arbitrary movements of nodes on >>>> all-wireless links. >>>> >>>> Alex >>>> >>>> That's the first >>>>> hop. The second hop is the radio hop. Followed by another >>>>> hop in the destination vehicle LAN. >>>>> >>>>> Second of all, there are a lot of use cases dealing with >>>>> highway travel like a 'virtual siren' for an ambulance. The >>>>> difficulty here is that we need to reach around corners -- >>>>> for example a cross street with RF-obstructing buildings on >>>>> the corners. Unwarned cross traffic is lethal to ambulances >>>>> in a hurry. So you have at least two hops of RF. >>>>> >>>>> I think trying to wish these requirements away is >>>>> shortsighted. >>>>> >>>>> b >>>>> >>>>> >>>>> On Tue, 2016-03-22 at 10:45 -0700, Erik Nordmark wrote: >>>>>> On 3/22/16 10:08 AM, Rex Buddenberg wrote: >>>>>>> The vehicle-to-vehicle nomadic topology is exactly what >>>>>>> the MANET protocols (OLSR, AODV and ancillaries) cater >>>>>>> to. Whatever addressing scheme picked should interface >>>>>>> cleanly with those protocols. >>>>>> >>>>>> Rex, >>>>>> >>>>>> The descriptions I've read about some of the ITS use cases >>>>>> leads me to believe that for some of them a link-local >>>>>> multicast is appropriate >>>> were >>>>>> one node is sharing some event or state with other nodes >>>>>> in physical proximity. Hence multi-hop IP routing might not >>>>>> be needed? >>>>>> >>>>>> Do the MANET protocols currently support multicast? >>>>>> >>>>>> Thanks, Erik >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, 2016-03-22 at 20:07 +0900, Mr. Jaehoon Paul >>>>>>> Jeong wrote: >>>>>>>> Hi Erik, These are good comments on IP address in V2I >>>>>>>> and V2V communications. I will also address your >>>>>>>> comments on the revised version of >>>>>>>> draft-jeong-its-v2i-problem-statement . >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> >>>>>>>> Best Regards, Paul >>>>>>>> >>>>>>>> On Tue, Mar 22, 2016 at 9:10 AM, Erik Nordmark >>>>>>>> wrote: I've looked through >>>>>>>> draft-jeong-its-v2i-problem-statement >>>> and >>>>>>>> the background on ITS that was given at recent IETF >>> plenary. >>>>>>>> >>>>>>>> It seems like there are quite different performance >>>>>>>> expectations for different types of V2V and V2I which >>>>>>>> has >>>> an >>>>>>>> impact on what one might want to do in terms of IP >>>>>>>> address management. >>>>>>>> >>>>>>>> Some use cases are about connecting to the Internet, >>>>>>>> where >>>> it >>>>>>>> seems like one would want a global IP address with >>>>>>>> some support for mobility. (But there are privacy >>>>>>>> considerations that probably mean we don't want to keep >>>>>>>> the IP address for >>>> a >>>>>>>> long time.) Using DHCP to assign such addresses might >>>>>>>> be reasonable. >>>>>>>> >>>>>>>> But for some V2V and vehicle to roadside use cases the >>>>>>>> performance requirements might not allow for waiting >>>>>>>> for IP address assignment, while at the same time the >>>> communication >>>>>>>> is entirely local. In such a case there isn't a need >>>>>>>> for a global IP address. One could even argue that >>>>>>>> there is no >>>> need >>>>>>>> for an IP address at all if the purpose is to notify >>>>>>>> neighboring vehicles about a hazard or that I've >>>>>>>> slammed on the brakes. >>>>>>>> >>>>>>>> One could potentially send such a packets using a >>>>>>>> link- >>>> local >>>>>>>> source address (and multicast them to a link-local >>>>>>>> group). But that still requires having a link-local >>>>>>>> address, and concerns about privacy means we need to >>>>>>>> change that source address. But it wouldn't serve any >>>>>>>> purpose if the message >>>> is >>>>>>>> unidirectional. >>>>>>>> >>>>>>>> I think we could consider sending such packets with >>>>>>>> the unspecified (all-zeros) IPv6 source address. We >>>>>>>> typically don't use this (an exception is Duplicate >>>> Address >>>>>>>> Detection) but for local unidirectional traffic it is >>>>>>>> an option to consider if the performance/privacy of IP >>>>>>>> address assignment is an issue. >>>>>>>> >>>>>>>> Regards, Erik >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- =========================== Mr. Jaehoon (Paul) >>>>>>>> Jeong, Ph.D. Assistant Professor Department of >>>>>>>> Software Sungkyunkwan University Office: >>>>>>>> +82-31-299-4957 Email: jaehoon.paul@gmail.com, >>>>>>>> pauljeong@skku.edu Personal Homepage: >>>>>>>> http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>> >>>> >>> >>> >>> >> > > > From nobody Wed Mar 30 13:55:16 2016 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 4B00512D676 for ; Wed, 30 Mar 2016 13:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 6pGnmeahT9a7 for ; Wed, 30 Mar 2016 13:55:13 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA1612D0B8 for ; Wed, 30 Mar 2016 13:55:13 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 00A0AF24041 for ; Wed, 30 Mar 2016 16:55:12 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id nJOElZ4tqtZN for ; Wed, 30 Mar 2016 16:41:05 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 8AAEDF2402A for ; Wed, 30 Mar 2016 16:55:12 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Mar 2016 16:55:11 -0400 References: <20160330202243.4795.63685.idtracker@ietfa.amsl.com> To: its@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [its] Fwd: Remote Participation for IETF 95: Meetecho Details X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 20:55:15 -0000 > From: IETF Secretariat > Subject: [95all] Remote Participation for IETF 95: Meetecho Details > Date: March 30, 2016 at 4:22:43 PM EDT > To: "IETF Announcement List" > Cc: wgchairs@ietf.org, recentattendees@ietf.org, 95all@ietf.org > Reply-To: ietf@ietf.org >=20 > You may use Meetecho to participate in or just observe any session = being held in Buenos Aires. Here are the requirements and details.=20 >=20 > 1. Individuals are required to register for the meeting to observe or = participate via Meetecho. > - Individuals are required to enter registration I.D and name when = logging into a session via Meetecho > - The name must match that used to register for the meeting > - Please register even if you are participating as part of remote hub > - There is no cost to register as a remote attendee. Register = here:http://ietf.org/meeting/register.html.=20 >=20 > 2. Participation includes the ability to transmit audio and video via = the Meetecho virtual queue. > - The virtual queue permits remote attendees to share audio and video = if they choose, see here for more information: = https://ietf95.conf.meetecho.com/index.php/UMPIRE_Project > - Anyone who thinks they may want to participate by transmitting audio = / video should perform the Meetecho self-test prior to the start of the = session: http://ietf95.conf.meetecho.com/index.php/Self_Test >=20 > 3. WG Chairs will control the virtual queue, unmuting and muting of = remote participants >=20 > 4. The agenda for the WG sessions, as well as more detail on how to = use Meetecho to participate, can be found here: = https://ietf95.conf.meetecho.com/index.php/. >=20