From nobody Sun Aug 7 02:02: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 98CC812D150; Sun, 7 Aug 2016 02:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 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=-1.247, 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 0v8BlxRPD34q; Sun, 7 Aug 2016 02:02:55 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AD6512D0F5; Sun, 7 Aug 2016 02:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=287; q=dns/txt; s=iport; t=1470560575; x=1471770175; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=U6xPBaDtHw9XIuH0F3QaqFn/LHh/2BNETnqhA96uApY=; b=WogwBE9JGyaRlIzabg1KzOd86BIpA5vt05cSOs6ViN6pPNSpSGuxbtQl +MLkvXE4TueqgZAU58z/DyiExpJ4wvL47GXlEXeu3DSDdGH8/kDTaNWPs Ty70XKfD9U7uTV5D8FTAhgaYgXexxejj/5s1IS/4u4a7g8XoeoQP7U6Ce 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJAgAM+KZX/4ENJK1dg0VWgQO2eIIPg?= =?us-ascii?q?X0khXmBJzgUAQEBAQEBAV0cC4RlOj8SAT5CJwQOiDYOwVABAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEXBYYqgXiKQYIvBZk5AY8JgVUBFYRbiH2QKwEeNoN6hmB/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,483,1464652800"; d="scan'208";a="306983543" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Aug 2016 09:02:53 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u7792rbm028139 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 7 Aug 2016 09:02:53 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 7 Aug 2016 05:02: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.1210.000; Sun, 7 Aug 2016 05:02:53 -0400 From: "Carlos Pignataro (cpignata)" To: "its@ietf.org" Thread-Topic: DRAFT Minutes - ITS, IETF96 Thread-Index: AQHR8Ip6oeskc0amzEqKdDmq0gK/Vg== Date: Sun, 7 Aug 2016 09:02:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.229.99] Content-Type: text/plain; charset="us-ascii" Content-ID: <0C0B15504413234CA9E16D312E07F554@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "its-chairs@ietf.org" Subject: [its] DRAFT Minutes - ITS, IETF96 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: Sun, 07 Aug 2016 09:02:56 -0000 Hi, ITS, Please find draft minutes (with thanks to Alex) posted at: https://www.ietf.org/proceedings/96/minutes/minutes-96-its Please send to the list by reply-all any corrections, omissions, or fixes, = in preparation to posting our final minutes. Thanks, Carlos & Russ. From nobody Mon Aug 8 11:52:13 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 A866C12D12D for ; Mon, 8 Aug 2016 11:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9Sk_0k2ir7d for ; Mon, 8 Aug 2016 11:51:58 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 5966A12D67D for ; Mon, 8 Aug 2016 11:47:20 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id 74so82317716uau.0 for ; Mon, 08 Aug 2016 11:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:from:date:message-id:subject:to:cc; bh=ZSzaCPcpn8WnBPyziDLTwezHWaGggpbvgRlV6XVboMI=; b=kBwDnrxW7MFi/1S/WR8UPj+GH/eZ5TR421pnU7SM3UDW2f3SNZVC5wbAhCQsQybERS DLSJTMf+xZXRyl1krAQU+y7Tq8gEJO3B7Qu9QEdCki+4mhL6j3nuwLJC3hDcMJHmSOm+ ZvNlMvb6mX1TwfPZsumK89P6ZAU/BN1FZFVzvyv4UVpQC8Xx55N9i2fgCDKRVMRJF5Hf KYy06oP9CoNHvDHQPUJKy5fiVYt6X0OBa0b0j3GjbPnGul5wyLhm5KgVUc0UfBRg6D2X lUPHgqsXA+DBGHXQW2nGygZibhbD5DI6gNImsxTm7+9FWlySEuu/C6uJgn1Wmh2yu8L7 eUhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to:cc; bh=ZSzaCPcpn8WnBPyziDLTwezHWaGggpbvgRlV6XVboMI=; b=ObkXQMw6MZ9SXlQmkqmVHjeY9dUOsoM64uk5QCXSMlphvEdupcpqH2erxCq2isrTxZ nKVrWyooy+6UF8c37VDcgrt9W5lVw1I2XWkWKh4s9UsAinFq4BgnMAtcu4WZ/uy0rvF4 c2dx6YAR2Be1aAdRUP2XC/aiMFjNW6dTc6Vx3e2IulNm+Wx2F2fsKmPk6VulGJY0Ihbs Ew7Ukgvb72FtkC2Ykio4pRL1fZA4gdn684zsr79USRg2u2HAZijHBSKrPJBLwpx7jJVl puAscEl/1BYSAQ4nzZioA2Q6ZXPpmmyLt6RPT56iwMsMDUxYn8IXPzFgUM54UJxKFB6s 0xoQ== X-Gm-Message-State: AEkoouvu8NFhXBlslvdFCnmrsSV+h4Kc1fefSynp+wDfjcOLuefa5h5fOR5fJhXTytZhxAbNMjrO3pyWF7JZ9Q== X-Received: by 10.31.3.17 with SMTP id 17mr7677276vkd.20.1470682039413; Mon, 08 Aug 2016 11:47:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.167 with HTTP; Mon, 8 Aug 2016 11:47:18 -0700 (PDT) From: Behcet Sarikaya Date: Mon, 8 Aug 2016 13:47:18 -0500 Message-ID: To: Russ Housley Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "its@ietf.org" Subject: Re: [its] Charter comments X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 18:52:00 -0000 Hi Russ, Regarding the charter, I have a comment: I think that Intelligent Transportation Systems (its), is too generic for this group. I see that the informational item called ITS General Problem Area is something that is being taken up. The standards track work is very specific work and calling it ITS is in my view not appropriate. I suggest calling Vehicule to Internet Communications or vic would be much more appropriate. After all, IETF WGs with too generic names are not good, maybe OK for IRTF like ICN. Regards, Behcet On Thu, Jul 28, 2016 at 9:23 AM, Russ Housley wrote: > I got word from our Area Director that the IESG would like to see a statement in the charter about coordination with IEEE 802.11. I added it. > > Here is the diff: https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart?action=diff&version=19 > > Here is the full charter: https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart > > Russ > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Tue Aug 9 08:13:56 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 3706512D5FB for ; Tue, 9 Aug 2016 08:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, 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 xJIbDBjfMDjQ for ; Tue, 9 Aug 2016 08:13:53 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8662612D848 for ; Tue, 9 Aug 2016 08:13:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 9FC3D621E7; Tue, 9 Aug 2016 11:13:52 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WK6lfwW9gmXt; Tue, 9 Aug 2016 11:13:48 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id D73FD621D9; Tue, 9 Aug 2016 11:13:47 -0400 (EDT) To: sarikaya@ieee.org, Russ Housley References: From: Robert Moskowitz Message-ID: Date: Tue, 9 Aug 2016 11:13:30 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "its@ietf.org" Subject: Re: [its] Charter comments 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, 09 Aug 2016 15:13:55 -0000 Considering what I see presented at ITS World Congress, I have to agree with Behcet on this one. We are focused on Internet to (and perhaps into) the vehicle. Internet to transportation infrastructure is almost a given and perhaps not so interesting. On 08/08/2016 02:47 PM, Behcet Sarikaya wrote: > Hi Russ, > > Regarding the charter, I have a comment: > > I think that > Intelligent Transportation Systems (its), > is too generic for this group. > > I see that the informational item called ITS General Problem Area is > something that is being taken up. The standards track work is very > specific work and calling it ITS is in my view not appropriate. > > I suggest calling Vehicule to Internet Communications or vic would be > much more appropriate. > After all, IETF WGs with too generic names are not good, maybe OK for > IRTF like ICN. > > Regards, > > Behcet > > > On Thu, Jul 28, 2016 at 9:23 AM, Russ Housley wrote: >> I got word from our Area Director that the IESG would like to see a statement in the charter about coordination with IEEE 802.11. I added it. >> >> Here is the diff: https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart?action=diff&version=19 >> >> Here is the full charter: https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart >> >> Russ >> >> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Thu Aug 11 03:01: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 09754127058 for ; Thu, 11 Aug 2016 03:01:42 -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 lLpUSimsq2j5 for ; Thu, 11 Aug 2016 03:01:39 -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 6E94C126579 for ; Thu, 11 Aug 2016 03:01:39 -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 u7BA1bU4025326 for ; Thu, 11 Aug 2016 12:01:37 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0C91F203AD5 for ; Thu, 11 Aug 2016 12:01:37 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 02E54202C63 for ; Thu, 11 Aug 2016 12:01:37 +0200 (CEST) Received: from [132.166.84.70] ([132.166.84.70]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u7BA1aJo001133 for ; Thu, 11 Aug 2016 12:01:36 +0200 To: its@ietf.org References: From: Alexandre Petrescu Message-ID: Date: Thu, 11 Aug 2016 12:01:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.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] Charter comments 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, 11 Aug 2016 10:01:42 -0000 Hi Behcet, I tend to agree with the note, but here is some aspects in defence of 'ITS'. 'ITS' can be too generic, but compared to the other ITS there is a catch: it's at IETF :-) For the V2I aspect: the initial work on problem statement (draft-petrescu-its-problem-03.txt, draft-jeong-its-v2i-problem-statement-02) describe use-cases exhbiting both Vehicle-to-Internet and Vehicle-to-Vehicle communication needs. As such it would be little appropriate to call the group with an acronym based only on V2I. The ongoing Stds Track work is IPv6-over-802.11-OCB which is applied equally well for vehicle-to-vehicle direct communications, and for vehicle-to-Internet (via an RSU). If on the other hand one considers that two directly connected vehicles form already a small island of a small Internet, then a 3rd vehicle connecting to this island _could_ be called V2I. Alex Le 08/08/2016 à 20:47, Behcet Sarikaya a écrit : > Hi Russ, > > Regarding the charter, I have a comment: > > I think that > Intelligent Transportation Systems (its), > is too generic for this group. > > I see that the informational item called ITS General Problem Area is > something that is being taken up. The standards track work is very > specific work and calling it ITS is in my view not appropriate. > > I suggest calling Vehicule to Internet Communications or vic would be > much more appropriate. > After all, IETF WGs with too generic names are not good, maybe OK for > IRTF like ICN. > > Regards, > > Behcet > > > On Thu, Jul 28, 2016 at 9:23 AM, Russ Housley wrote: >> I got word from our Area Director that the IESG would like to see a statement in the charter about coordination with IEEE 802.11. I added it. >> >> Here is the diff: https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart?action=diff&version=19 >> >> Here is the full charter: https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart >> >> Russ >> >> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Mon Aug 15 09:32: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 2A0B512D6A1 for ; Mon, 15 Aug 2016 09:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Feth2t3oCkbV for ; Mon, 15 Aug 2016 09:31:57 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 7496E12D727 for ; Mon, 15 Aug 2016 09:31:57 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id k90so80904140uak.1 for ; Mon, 15 Aug 2016 09:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=caWg19J/w8euWYkf2wurSi0SxThFR1e3BgkkYq4TgO0=; b=pm2yK5uGRi5MAZNWgUfHWE0nwFezN/TEEtBKyRCTPhHoABgSNv+aGy4SM382v0EuCN gfzKzUO9ejDaQOiGvJ4N5lTnzeOZY28v0JCzCubK0xNPb14r+S9OSQIwJuWQa/hNS43b e9IBYNoBDm+PrcmvASIYoK4E+qAJ9Xu9bxzhBzC+11NpLLIlK+55WiurWhUZGY/W3Tj2 GvZvf30NgyXWspB5R5CTtyAcvNmSwm6EuskAyyvui/AvygJ4b+16CGV0m1auqhEthLnV 8fC9nBsyD7dVbhL8TbyaV/qs7svQnNnN14KfA0cf588tSSHsGssFS3rHsOcSlh6U8DNv 0tlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=caWg19J/w8euWYkf2wurSi0SxThFR1e3BgkkYq4TgO0=; b=a8ceTqeIHlar8cEPKZ2DdP+Rxxntf+WjjY7zjokxhjMBQBRW4oYeUEe6qycpQ8b7/H jWK9whXrJd+D2yCnGgoM+L+6wF59SMe7Kg/r9hHzyu914qoQjakghB8t2UcqXNpxVHsa t4Uo6g3hkL/sK7tyHrmBWDEQt58HOPj8R4DsnvFOQjvWq97KjKyxB7t9b7qYQiCOhbnz BRdEFvBx3bdN2Pkse/hULn/UBaa8nKP3BFVcZxd5Q9QwYlHjbwDLUiooKeOCffic/d+P Q1hFekB2Ss7oSkbJ/xDb/c51fD31J/ZPhrMTgDdRrdCtu9SGPYhk+4Lg5/hHrU60yyrv GOhw== X-Gm-Message-State: AEkoous2tkekh/wWwjQ2KHOx48qn+FBo48o9bIzIOp37HFgk0Fc6D/jA8gnd6KbbgqOqG/fd3ejvGiPMhU7Mfg== X-Received: by 10.31.252.141 with SMTP id a135mr37110vki.51.1471278716556; Mon, 15 Aug 2016 09:31:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.167 with HTTP; Mon, 15 Aug 2016 09:31:55 -0700 (PDT) In-Reply-To: References: From: Behcet Sarikaya Date: Mon, 15 Aug 2016 11:31:55 -0500 Message-ID: To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: its@ietf.org Subject: Re: [its] Charter comments X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 16:31:59 -0000 Hi Alex, On Thu, Aug 11, 2016 at 5:01 AM, Alexandre Petrescu wrote: > Hi Behcet, > > I tend to agree with the note, Thanks :-) > but here is some aspects in defence of 'ITS'. > > 'ITS' can be too generic, but compared to the other ITS there is a catch: > it's at IETF :-) Don't understand this? > > For the V2I aspect: the initial work on problem statement > (draft-petrescu-its-problem-03.txt, > draft-jeong-its-v2i-problem-statement-02) describe use-cases exhbiting bo= th > Vehicle-to-Internet and Vehicle-to-Vehicle communication needs. As such = it > would be little appropriate to call the group with an acronym based only = on > V2I. > Only a little. > The ongoing Stds Track work is IPv6-over-802.11-OCB which is applied equa= lly > well for vehicle-to-vehicle direct communications, and for > vehicle-to-Internet (via an RSU). > If standard track work applies to a larger area, it is good for the WG doing the work. > If on the other hand one considers that two directly connected vehicles f= orm > already a small island of a small Internet, then a 3rd vehicle connecting= to > this island _could_ be called V2I. > Yes but no infrastructural nodes are involved? Regards, behcet > Alex > > > > Le 08/08/2016 =C3=A0 20:47, Behcet Sarikaya a =C3=A9crit : >> >> Hi Russ, >> >> Regarding the charter, I have a comment: >> >> I think that >> Intelligent Transportation Systems (its), >> is too generic for this group. >> >> I see that the informational item called ITS General Problem Area is >> something that is being taken up. The standards track work is very >> specific work and calling it ITS is in my view not appropriate. >> >> I suggest calling Vehicule to Internet Communications or vic would be >> much more appropriate. >> After all, IETF WGs with too generic names are not good, maybe OK for >> IRTF like ICN. >> >> Regards, >> >> Behcet >> >> >> On Thu, Jul 28, 2016 at 9:23 AM, Russ Housley >> wrote: >>> >>> I got word from our Area Director that the IESG would like to see a >>> statement in the charter about coordination with IEEE 802.11. I added = it. >>> >>> Here is the diff: >>> https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart?action=3Ddiff&ve= rsion=3D19 >>> >>> Here is the full charter: >>> https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart >>> >>> Russ >>> >>> >>> >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Mon Aug 15 10:00: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 84A9912D508 for ; Mon, 15 Aug 2016 10:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 GqItTDai4ip3 for ; Mon, 15 Aug 2016 10:00:52 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45BA212D611 for ; Mon, 15 Aug 2016 09:59:56 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-09v.sys.comcast.net with SMTP id ZLDqb1xIq1XXBZLEybpXo3; Mon, 15 Aug 2016 16:59:56 +0000 Received: from [10.120.1.193] ([12.1.72.210]) by resomta-ch2-09v.sys.comcast.net with SMTP id ZLCob5p0PSSEjZLCrb6Rul; Mon, 15 Aug 2016 16:57:54 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Tony Li In-Reply-To: Date: Mon, 15 Aug 2016 09:57:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> References: To: sarikaya@ieee.org X-Mailer: Apple Mail (2.3124) X-CMAE-Envelope: MS4wfAdj//u48IpSRVs7/LhqVzH01e/hlVennqC2ma1B30+c15or7dIdRl69dGA1DzwclO5UXFBhDh4+RjE3vsNlCoCNXG9C103k0yop+ZxIrAKo+3/jl1sB SB/bkbYSkwm0nDMqJC1VjKvsQGQM9/vKU53C2yBz0eWaExiYJmCnSVHPuQ1/0ZO/zjy3s6QxNVfPPcvUUk9iJoTpDdCUGkFOyyfIXb3ew7cg98jseuWI+yBw Archived-At: Cc: Alexandre Petrescu , its@ietf.org Subject: Re: [its] Charter comments 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, 15 Aug 2016 17:00:53 -0000 > On Aug 15, 2016, at 9:31 AM, Behcet Sarikaya = wrote: >=20 >> If on the other hand one considers that two directly connected = vehicles form >> already a small island of a small Internet, then a 3rd vehicle = connecting to >> this island _could_ be called V2I. >>=20 > Yes but no infrastructural nodes are involved? Hi there, Sorry I=E2=80=99m late to the discussion, but I=E2=80=99m missing out on = the architectural difference here. What does it matter if a node is a vehicle or infra? What do you = consider a vehicle that=E2=80=99s parked? Seems to me that a node is a node is a node=E2=80=A6 If they are in = range of each other, then they chat. Tony From nobody Mon Aug 15 10:22:35 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 DAC8112D158 for ; Mon, 15 Aug 2016 10:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247] 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 6lEEvzoQl4mg for ; Mon, 15 Aug 2016 10:22:32 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC6E12D0B6 for ; Mon, 15 Aug 2016 10:22:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,526,1464645600"; d="scan'208";a="4475470" Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236]) by drago2i.eurecom.fr with ESMTP; 15 Aug 2016 19:22:31 +0200 Received: from xerus29 (LFbn-1-6946-250.w90-116.abo.wanadoo.fr [90.116.128.250]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtps.eurecom.fr (Postfix) with ESMTPSA id D7045B48; Mon, 15 Aug 2016 19:22:30 +0200 (CEST) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Tony Li'" , References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> In-Reply-To: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> Date: Mon, 15 Aug 2016 19:22:32 +0200 Organization: EURECOM Message-ID: <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLnYvWbuj0Jb9+O5N4XnF9Mh3Dn+wIyijYuAdVBt/YCIplQUZ3uGFHA Content-Language: en-us Archived-At: Cc: 'Alexandre Petrescu' , its@ietf.org Subject: Re: [its] Charter comments 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, 15 Aug 2016 17:22:35 -0000 Dear All, >From a pure L2 link, we should not make a major difference if vehicles = are communicating V2V or V2I (beside the enhanced range available by = RSUs)..a node is a node indeed. But from an IPv6 architecture, this will = make a difference, as the RSU may be connected to the IPv6 backbone and = as such have additional properties (prefix, gateway etc..). It is yet also not as simple to say that when two vehicles are in range = that the communicate...of course they will (at least try), but there = will be different aspects to consider. For example, if the vehicle is = 'involved in traffic' and/or his 'engine is on/key in the ignition', = then it will need to transmit CAM/BSM.=20 So, the IPv6 will need to 'co-exist' with non IP higher priority traffic = (and operate in different channels for instance). But when the car is = not involved in traffic, engine and key off, then IPv6 might use the = full spectrum of the ITS-G5 radio (no 1609.4 channel switching for = instance..) My two cents, Cheers, J=C3=A9r=C3=B4me =20 -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Tony Li Sent: Monday 15 August 2016 18:58 To: sarikaya@ieee.org Cc: Alexandre Petrescu; its@ietf.org Subject: Re: [its] Charter comments > On Aug 15, 2016, at 9:31 AM, Behcet Sarikaya = wrote: >=20 >> If on the other hand one considers that two directly connected=20 >> vehicles form already a small island of a small Internet, then a 3rd=20 >> vehicle connecting to this island _could_ be called V2I. >>=20 > Yes but no infrastructural nodes are involved? Hi there, Sorry I=E2=80=99m late to the discussion, but I=E2=80=99m missing out on = the architectural difference here. What does it matter if a node is a vehicle or infra? What do you = consider a vehicle that=E2=80=99s parked? Seems to me that a node is a node is a node=E2=80=A6 If they are in = range of each other, then they chat. Tony _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Mon Aug 15 11:13:19 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 825F612D0C1 for ; Mon, 15 Aug 2016 11:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rt5w4Zz8sWLb for ; Mon, 15 Aug 2016 11:13:16 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 7483E12D5F0 for ; Mon, 15 Aug 2016 11:13:12 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id 97so85066687uav.3 for ; Mon, 15 Aug 2016 11:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=vyjDLYp8jbimdubig20P/BDEMO1dpQ26UayRulhC9iU=; b=q9D4HM1hBNdAE9r9VxjT4e/yB5Rys0sqo9AoF2IcunHGPaOO6SM/nkniJpBaDcBpJ/ TuK7FHRIUJiE3V6zKDgmc0xxUU5p7JnXoHqVyfCDEkDhpS3ZJnxcs97fqwpgb2+xlBFF +OZZHh4yw17XALwepM6tLKXrWx2faSxjG9FBeGAgwpUIN9376ppJE6hp/icbvNuycxpc cfMRgwRLu68rn+Wto1psKfWJ0iRe0B0D9G1JKshug8hSLge8pnv5ukXPUBcW5g0Q1ler srXO9mWvcM6uBPWgss2J8yiBEXQXKoX+VjphZk5TufbdFs0ab3aHaxeOKW2sPmTta1d5 bdng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=vyjDLYp8jbimdubig20P/BDEMO1dpQ26UayRulhC9iU=; b=BvIrijHJI0bIvnP+jh+JMw8h3lYpALMf58jeaoq0kkrU1jbHobaSTkhIYJT1DjiXgw kgTa5242NB5oSXT2oPgptmMs/D2lss8Z6CFC2Nrs83FNLQml2RfpmcUxw8c4aoCRp9a+ mMfPwQFBZN7meIeiv9h4P1dlfkZtRgwLv/Bg8buzTKjdrEJ/RGlXj3Kb5yUCRaj9fwn5 2iXNEGCzTlUqWHAtdrnBMabaBY8K1aaZd2njGC6gaZMTYRm9Q41t4dpmV8h7bKD7zbo4 yS5mkK5d3kCMJ8vKB0EiSnTbuia6fRArxr+5WSgi55kQMervVH+nX22QGBbvyFN//4LH BaLQ== X-Gm-Message-State: AEkooutskiM1v9/4cd4YLqF3M5ZryDUwO6sApCJ+B6B2cE0NUNmz36ieFTk76ym5Ql/HzP/pnZ5FpjT6CicBSQ== X-Received: by 10.159.35.115 with SMTP id 106mr2894689uae.78.1471284791561; Mon, 15 Aug 2016 11:13:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.167 with HTTP; Mon, 15 Aug 2016 11:13:09 -0700 (PDT) In-Reply-To: <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> From: Behcet Sarikaya Date: Mon, 15 Aug 2016 13:13:09 -0500 Message-ID: To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Alexandre Petrescu , Tony Li , its@ietf.org Subject: Re: [its] Charter comments X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 18:13:17 -0000 I don't think V2V should be an IETF issue. Regarding V2I, if you don't like it, propose another name. Behcet On Mon, Aug 15, 2016 at 12:22 PM, J=C3=A9r=C3=B4me H=C3=A4rri wrote: > Dear All, > > From a pure L2 link, we should not make a major difference if vehicles ar= e communicating V2V or V2I (beside the enhanced range available by RSUs)..a= node is a node indeed. But from an IPv6 architecture, this will make a dif= ference, as the RSU may be connected to the IPv6 backbone and as such have= additional properties (prefix, gateway etc..). > > It is yet also not as simple to say that when two vehicles are in range t= hat the communicate...of course they will (at least try), but there will be= different aspects to consider. For example, if the vehicle is 'involved in= traffic' and/or his 'engine is on/key in the ignition', then it will need = to transmit CAM/BSM. > So, the IPv6 will need to 'co-exist' with non IP higher priority traffic = (and operate in different channels for instance). But when the car is not i= nvolved in traffic, engine and key off, then IPv6 might use the full spectr= um of the ITS-G5 radio (no 1609.4 channel switching for instance..) > > My two cents, > > Cheers, > > J=C3=A9r=C3=B4me > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Tony Li > Sent: Monday 15 August 2016 18:58 > To: sarikaya@ieee.org > Cc: Alexandre Petrescu; its@ietf.org > Subject: Re: [its] Charter comments > > >> On Aug 15, 2016, at 9:31 AM, Behcet Sarikaya wr= ote: >> >>> If on the other hand one considers that two directly connected >>> vehicles form already a small island of a small Internet, then a 3rd >>> vehicle connecting to this island _could_ be called V2I. >>> >> Yes but no infrastructural nodes are involved? > > > Hi there, > > Sorry I=E2=80=99m late to the discussion, but I=E2=80=99m missing out on = the architectural difference here. > > What does it matter if a node is a vehicle or infra? What do you consider= a vehicle that=E2=80=99s parked? > > Seems to me that a node is a node is a node=E2=80=A6 If they are in rang= e of each other, then they chat. > > Tony > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Mon Aug 15 11:20:02 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 DE99E12B014 for ; Mon, 15 Aug 2016 11:19:58 -0700 (PDT) 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 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 Byy0d1paszzG for ; Mon, 15 Aug 2016 11:19:57 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::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 DA4DE12D10B for ; Mon, 15 Aug 2016 11:19:56 -0700 (PDT) Received: by mail-pa0-x229.google.com with SMTP id ti13so18179258pac.0 for ; Mon, 15 Aug 2016 11:19:56 -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 :content-transfer-encoding:message-id:references:to; bh=DOnDiEb6C05RiDpCXenSNOJbn9oHNmCXiAVCSfQThVI=; b=Rb8FmybAXIaBDs0dGQcApLqvmg0Q3EzcVbwASBs/s+0g8CisjNcyEiCB3bPizzWzv8 rVcrrhwtUTh9JgfC9TOpcJqXZbKZcTOSy5sGtVc/5O2ExmIkpQqkqqGkmJuDv8KProjc ptnZCfSNxkkkHTfBod5k7ce/4PX0ttRpARy0eB7GMIjBJIhIpGTdp9zGfnk1owClrpB0 BUFNRva1ny6Uoz2f2ofyd+scy9o6bILB9ZQ66qBs97T1l/QhXbbSF37ujAKElm98v8wM 2vK9GWDj0+H+wJ3n2faQHo3+B3Q6ojRqciT4W1guqA5st3uvKeKhNqANQti57/9Vw0XW u9yQ== 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 :content-transfer-encoding:message-id:references:to; bh=DOnDiEb6C05RiDpCXenSNOJbn9oHNmCXiAVCSfQThVI=; b=VFylp1rvYLrw2byNI+VRX3N7fDswOGcsW61QyosJEEFTNSeh2enFBmwxsWVKK08NtM q8qvxSTmLs+qiLiVQwLZ61nRyPJXxUjbkNz+2AtoiwNsGaxWToiGnaJxh+GoJHUdtzeh nTetjeMSqIWr7U5OrxIihWkzRHKfbBszTBbHbvG8ojoG83iMH4XpIXSemAUfIFl6vrIA QX2MYt/6Akkt3tujx6+do5ytkzYSahPB+L1+xwN34e3GnqbI/1eYLYQm9U6Dn0dUNAia eURP/loEh6zgHT1SzbpdYIvrzBlHF6U9+EdG+Iu23OlqK5bRG0xR6nAMBvYve9HOxwMh iEMw== X-Gm-Message-State: AEkoouszMMfqFj0xsQm0TXJcod/BpBI3d6upX0yp/8xw4EpXAfu0FWePXwrHotCsRrqZDg== X-Received: by 10.66.139.227 with SMTP id rb3mr55997473pab.26.1471285196356; Mon, 15 Aug 2016 11:19:56 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id g24sm33079523pfk.56.2016.08.15.11.19.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 15 Aug 2016 11:19:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: Date: Mon, 15 Aug 2016 11:19:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <313AEC4E-DAC1-4360-B9C2-7174C349A35E@gmail.com> References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Alexandre Petrescu , Tony Li , =?utf-8?Q?J=C3=A9r=C3=B4me_H=C3=A4rri?= , its@ietf.org Subject: Re: [its] Charter comments 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, 15 Aug 2016 18:19:59 -0000 > I don't think V2V should be an IETF issue. I think what you mean Behcet, as others have stated, that maybe Internet = protocols are not suitable and add more risk to the V2V case. Tony, I think what it comes down to is, if the link-layer protocols = interoperate, what value is an IP layer. The application here is very = specific (don=E2=80=99t hit the car in front of me, don=E2=80=99t hit = objects near me, and make this decision very fast) and assigning an = address, doing DAD, and other chit chat before moving the critical app = data may exceed the time budget required. Dino > Regarding V2I, if you don't like it, propose another name. >=20 > Behcet >=20 > On Mon, Aug 15, 2016 at 12:22 PM, J=C3=A9r=C3=B4me H=C3=A4rri = wrote: >> Dear All, >>=20 >> =46rom a pure L2 link, we should not make a major difference if = vehicles are communicating V2V or V2I (beside the enhanced range = available by RSUs)..a node is a node indeed. But from an IPv6 = architecture, this will make a difference, as the RSU may be connected = to the IPv6 backbone and as such have additional properties (prefix, = gateway etc..). >>=20 >> It is yet also not as simple to say that when two vehicles are in = range that the communicate...of course they will (at least try), but = there will be different aspects to consider. For example, if the vehicle = is 'involved in traffic' and/or his 'engine is on/key in the ignition', = then it will need to transmit CAM/BSM. >> So, the IPv6 will need to 'co-exist' with non IP higher priority = traffic (and operate in different channels for instance). But when the = car is not involved in traffic, engine and key off, then IPv6 might use = the full spectrum of the ITS-G5 radio (no 1609.4 channel switching for = instance..) >>=20 >> My two cents, >>=20 >> Cheers, >>=20 >> J=C3=A9r=C3=B4me >>=20 >> -----Original Message----- >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Tony Li >> Sent: Monday 15 August 2016 18:58 >> To: sarikaya@ieee.org >> Cc: Alexandre Petrescu; its@ietf.org >> Subject: Re: [its] Charter comments >>=20 >>=20 >>> On Aug 15, 2016, at 9:31 AM, Behcet Sarikaya = wrote: >>>=20 >>>> If on the other hand one considers that two directly connected >>>> vehicles form already a small island of a small Internet, then a = 3rd >>>> vehicle connecting to this island _could_ be called V2I. >>>>=20 >>> Yes but no infrastructural nodes are involved? >>=20 >>=20 >> Hi there, >>=20 >> Sorry I=E2=80=99m late to the discussion, but I=E2=80=99m missing out = on the architectural difference here. >>=20 >> What does it matter if a node is a vehicle or infra? What do you = consider a vehicle that=E2=80=99s parked? >>=20 >> Seems to me that a node is a node is a node=E2=80=A6 If they are in = range of each other, then they chat. >>=20 >> Tony >>=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 From nobody Mon Aug 15 11:58:15 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 C16FF12D5A4 for ; Mon, 15 Aug 2016 11:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 y34asm32_9sC for ; Mon, 15 Aug 2016 11:58:12 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D14C12B02D for ; Mon, 15 Aug 2016 11:58:12 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-07v.sys.comcast.net with SMTP id ZN5CbOQPzff8qZN5PbQoWv; Mon, 15 Aug 2016 18:58:11 +0000 Received: from [IPv6:2602:306:ccab:b20:e98b:28f5:c2ac:1d24] ([IPv6:2602:306:ccab:b20:e98b:28f5:c2ac:1d24]) by resomta-ch2-11v.sys.comcast.net with SMTP id ZN54belnwZzFlZN59bKoWl; Mon, 15 Aug 2016 18:58:08 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: tony.li@tony.li In-Reply-To: <313AEC4E-DAC1-4360-B9C2-7174C349A35E@gmail.com> Date: Mon, 15 Aug 2016 11:57:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6FA3F7C4-FB3E-4C98-93BC-AAD7AA4C02DA@tony.li> References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <313AEC4E-DAC1-4360-B9C2-7174C349A35E@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3124) X-CMAE-Envelope: MS4wfN4aLOKoTInnbGi9un8qffq00lYHhfdric6wsve0iEfJ9FY7yMM0bZTXiYkSY45txgQ4hA/2ZVn/5fC+NxAGNlQehnyWHWhUh/yG/NLZPLMpUpx+ukVm Ezh3y+QuSciozpJ/H9mn25fJjn/s3ZCUsVvvtWiVorLvxxImreB4NNLfU2Lc63kH5HmPf4Am6ezTo2dnHHAD3f/t7HcpzRVaOz+5Ug8hM8ESt3vYdM1FMzou 8nelEY/Kj0FxOthjB8t1yKelSf48iYCo7VAI4LyHGn8K17ogv2I8n+Jk4/XI94BLiuudYMhFqp7cLjBDwYH4fQ== Archived-At: Cc: sarikaya@ieee.org, =?utf-8?Q?J=C3=A9r=C3=B4me_H=C3=A4rri?= , its@ietf.org, Alexandre Petrescu Subject: Re: [its] Charter comments 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, 15 Aug 2016 18:58:14 -0000 Dino, my dear old friend, > Tony, I think what it comes down to is, if the link-layer protocols = interoperate, what value is an IP layer. As always, no node, or even pair of nodes, is an island. Metcalfe=E2=80=99= s law (sic) strongly suggests that providing a more general connectivity = will prove to be more powerful. > The application here is very specific (don=E2=80=99t hit the car in = front of me, don=E2=80=99t hit objects near me, and make this decision = very fast) and assigning an address, doing DAD, and other chit chat = before moving the critical app data may exceed the time budget required. While safety is of course the paramount concern, over time there are a = myriad number of other applications that can and should be done in the = vehicle. Some of those will want to interact with the broader Internet. = If we do not extend the Internet infrastructure to the vehicle directly, = it will end up happening indirectly, and in a much more awkward manner. As to DAD, it=E2=80=99s not at all clear to me that there needs to be a = lot of latency involved here. Obviously a link local address has a very = high likelihood of being unique. A safety application can always worry = about which system is claiming that there will be an impact after it = tries to avert the impact. And before you start in on security, = authentication should definitely not be bound to link layer or network = layer addressing: as always, that needs crypto. Now, if there are specific reasons why things can=E2=80=99t work with = IP, I=E2=80=99m open to hearing about them. But so far, I haven=E2=80=99t = seen a thing. >> I don't think V2V should be an IETF issue. >=20 > I think what you mean Behcet, as others have stated, that maybe = Internet protocols are not suitable and add more risk to the V2V case. I would welcome specific examples. Seems like old times, Tony From nobody Mon Aug 15 12:53: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 DCDDE12D75C for ; Mon, 15 Aug 2016 12:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 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=-1.247, 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 tPDwkEnX2Oya for ; Mon, 15 Aug 2016 12:53:50 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FDF012D598 for ; Mon, 15 Aug 2016 12:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3252; q=dns/txt; s=iport; t=1471290830; x=1472500430; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PfCUC4omT2Fl1Iiq0Mz77QfI2IzHUOzZn5N8JN0Zju4=; b=dI32LhAbcp2Kb8ZKpprqjY8KGNOH0SRudSfrz+LZJe3nYdPCC+z0PbZl G9bjRHFjkkV7oXidR9XLrIJb+PLyrm/7BkFRYmHoBcSN8TpmddpnxqENn W4O7NUXs4GR/EXrnDBEFcw7+bre4kdgS0MslX7XJipXsaHvvZePUEGl5b o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAgDBHLJX/5ldJa1eg0VWfAe5PYF9J?= =?us-ascii?q?IV5AhyBNTgUAgEBAQEBAQFeHAuEXgEBBAEBASEROgsFCwIBCBgCAiYCAgIlCxU?= =?us-ascii?q?QAgQOBYgpCA6tWpAvAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBAYUpgXiCVYQmG?= =?us-ascii?q?oMBK4IvBZk+AY8Vj0OMN4N3AR42g3puhiV/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,526,1464652800"; d="scan'208";a="137918232" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Aug 2016 19:53:49 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u7FJrn3F003392 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Aug 2016 19:53:49 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 15 Aug 2016 14:53:48 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1210.000; Mon, 15 Aug 2016 14:53:48 -0500 From: "Marc Linsner (mlinsner)" To: "tony.li@tony.li" Thread-Topic: [its] Charter comments Thread-Index: AQHR8aX7SjQAfHK4K0u+inrHw0ckBKBD3zYAgAa2YYCAAAc0AIAABvEAgAAOJICAAAHigIAACpoAgAAPooA= Date: Mon, 15 Aug 2016 19:53:48 +0000 Message-ID: <34BE1564-F274-45C7-BCCE-466D26911A71@cisco.com> References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <313AEC4E-DAC1-4360-B9C2-7174C349A35E@gmail.com> <6FA3F7C4-FB3E-4C98-93BC-AAD7AA4C02DA@tony.li> In-Reply-To: <6FA3F7C4-FB3E-4C98-93BC-AAD7AA4C02DA@tony.li> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.148.99] Content-Type: text/plain; charset="utf-8" Content-ID: <97CCFE0677FD6E4789E0EA3B14D2D46D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sarikaya@ieee.org" , Alexandre Petrescu , =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= , Dino Farinacci , "its@ietf.org" Subject: Re: [its] Charter comments 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, 15 Aug 2016 19:53:52 -0000 VG9ueSwNCg0KSXTigJlzIG5vdCB0aGF0IHRoaW5ncyBjYW7igJl0IHdvcmsgb24gSVAsIGJ1dCwg Zm9yIGV4YW1wbGUsIGZvciB0aGUgc3BlY2lmaWMgc2FmZXR5IG1lc3NhZ2VzIHRoZXJlIGlzIG5v IG5lZWQuICBDaC4gMTcyIGluIHRoZSBVUyBpcyBmb3IgbG93IHBvd2VyIHNhZmV0eSBtZXNzYWdl cyBkZXN0aW5lZCBmb3IgYSAyMDBtICgrLy0pIHJhZGl1cyBmcm9tIHRoZSB2ZWhpY2xlLiAgQWRk aW5nIElQIHRvIHRob3NlIG1lc3NhZ2UgcHJvdmlkZXMgbm8gdmFsdWUgdG8gdGhhdCBhcHBsaWNh dGlvbi4NCg0KLU1hcmMtDQoNCg0KDQo+IE9uIEF1ZyAxNSwgMjAxNiwgYXQgMjo1NyBQTSwgdG9u eS5saUB0b255LmxpIHdyb3RlOg0KPiANCj4gDQo+IERpbm8sIG15IGRlYXIgb2xkIGZyaWVuZCwN Cj4gDQo+IA0KPj4gVG9ueSwgSSB0aGluayB3aGF0IGl0IGNvbWVzIGRvd24gdG8gaXMsIGlmIHRo ZSBsaW5rLWxheWVyIHByb3RvY29scyBpbnRlcm9wZXJhdGUsIHdoYXQgdmFsdWUgaXMgYW4gSVAg bGF5ZXIuDQo+IA0KPiBBcyBhbHdheXMsIG5vIG5vZGUsIG9yIGV2ZW4gcGFpciBvZiBub2Rlcywg aXMgYW4gaXNsYW5kLiBNZXRjYWxmZeKAmXMgbGF3IChzaWMpIHN0cm9uZ2x5IHN1Z2dlc3RzIHRo YXQgcHJvdmlkaW5nIGEgbW9yZSBnZW5lcmFsIGNvbm5lY3Rpdml0eSB3aWxsIHByb3ZlIHRvIGJl IG1vcmUgcG93ZXJmdWwuDQo+IA0KPj4gVGhlIGFwcGxpY2F0aW9uIGhlcmUgaXMgdmVyeSBzcGVj aWZpYyAoZG9u4oCZdCBoaXQgdGhlIGNhciBpbiBmcm9udCBvZiBtZSwgZG9u4oCZdCBoaXQgb2Jq ZWN0cyBuZWFyIG1lLCBhbmQgbWFrZSB0aGlzIGRlY2lzaW9uIHZlcnkgZmFzdCkgYW5kIGFzc2ln bmluZyBhbiBhZGRyZXNzLCBkb2luZyBEQUQsIGFuZCBvdGhlciBjaGl0IGNoYXQgYmVmb3JlIG1v dmluZyB0aGUgY3JpdGljYWwgYXBwIGRhdGEgbWF5IGV4Y2VlZCB0aGUgdGltZSBidWRnZXQgcmVx dWlyZWQuDQo+IA0KPiBXaGlsZSBzYWZldHkgaXMgb2YgY291cnNlIHRoZSBwYXJhbW91bnQgY29u Y2Vybiwgb3ZlciB0aW1lIHRoZXJlIGFyZSBhIG15cmlhZCBudW1iZXIgb2Ygb3RoZXIgYXBwbGlj YXRpb25zIHRoYXQgY2FuIGFuZCBzaG91bGQgYmUgZG9uZSBpbiB0aGUgdmVoaWNsZS4gU29tZSBv ZiB0aG9zZSB3aWxsIHdhbnQgdG8gaW50ZXJhY3Qgd2l0aCB0aGUgYnJvYWRlciBJbnRlcm5ldC4g SWYgd2UgZG8gbm90IGV4dGVuZCB0aGUgSW50ZXJuZXQgaW5mcmFzdHJ1Y3R1cmUgdG8gdGhlIHZl aGljbGUgZGlyZWN0bHksIGl0IHdpbGwgZW5kIHVwIGhhcHBlbmluZyBpbmRpcmVjdGx5LCBhbmQg aW4gYSBtdWNoIG1vcmUgYXdrd2FyZCBtYW5uZXIuDQo+IA0KPiBBcyB0byBEQUQsIGl04oCZcyBu b3QgYXQgYWxsIGNsZWFyIHRvIG1lIHRoYXQgdGhlcmUgbmVlZHMgdG8gYmUgYSBsb3Qgb2YgbGF0 ZW5jeSBpbnZvbHZlZCBoZXJlLiBPYnZpb3VzbHkgYSBsaW5rIGxvY2FsIGFkZHJlc3MgaGFzIGEg dmVyeSBoaWdoIGxpa2VsaWhvb2Qgb2YgYmVpbmcgdW5pcXVlLiBBIHNhZmV0eSBhcHBsaWNhdGlv biBjYW4gYWx3YXlzIHdvcnJ5IGFib3V0IHdoaWNoIHN5c3RlbSBpcyBjbGFpbWluZyB0aGF0IHRo ZXJlIHdpbGwgYmUgYW4gaW1wYWN0IGFmdGVyIGl0IHRyaWVzIHRvIGF2ZXJ0IHRoZSBpbXBhY3Qu IEFuZCBiZWZvcmUgeW91IHN0YXJ0IGluIG9uIHNlY3VyaXR5LCBhdXRoZW50aWNhdGlvbiBzaG91 bGQgZGVmaW5pdGVseSBub3QgYmUgYm91bmQgdG8gbGluayBsYXllciBvciBuZXR3b3JrIGxheWVy IGFkZHJlc3Npbmc6IGFzIGFsd2F5cywgdGhhdCBuZWVkcyBjcnlwdG8uDQo+IA0KPiBOb3csIGlm IHRoZXJlIGFyZSBzcGVjaWZpYyByZWFzb25zIHdoeSB0aGluZ3MgY2Fu4oCZdCB3b3JrIHdpdGgg SVAsIEnigJltIG9wZW4gdG8gaGVhcmluZyBhYm91dCB0aGVtLiBCdXQgc28gZmFyLCBJIGhhdmVu 4oCZdCBzZWVuIGEgdGhpbmcuDQo+IA0KPj4+IEkgZG9uJ3QgdGhpbmsgVjJWIHNob3VsZCBiZSBh biBJRVRGIGlzc3VlLg0KPj4gDQo+PiBJIHRoaW5rIHdoYXQgeW91IG1lYW4gQmVoY2V0LCBhcyBv dGhlcnMgaGF2ZSBzdGF0ZWQsIHRoYXQgbWF5YmUgSW50ZXJuZXQgcHJvdG9jb2xzIGFyZSBub3Qg c3VpdGFibGUgYW5kIGFkZCBtb3JlIHJpc2sgdG8gdGhlIFYyViBjYXNlLg0KPiANCj4gSSB3b3Vs ZCB3ZWxjb21lIHNwZWNpZmljIGV4YW1wbGVzLg0KPiANCj4gU2VlbXMgbGlrZSBvbGQgdGltZXMs DQo+IFRvbnkNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBpdHMgbWFpbGluZyBsaXN0DQo+IGl0c0BpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KDQo= From nobody Mon Aug 15 15:54:34 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 7699D12D796 for ; Mon, 15 Aug 2016 15:54:33 -0700 (PDT) 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 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 w-bFzJDuvUoL for ; Mon, 15 Aug 2016 15:54:32 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::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 0380412D791 for ; Mon, 15 Aug 2016 15:54:32 -0700 (PDT) Received: by mail-pa0-x229.google.com with SMTP id i5so19886834pat.2 for ; Mon, 15 Aug 2016 15:54:31 -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 :content-transfer-encoding:message-id:references:to; bh=XljJqQCJX+OiMLuqz6d+oaqT/BVQJZ6ZPKUFhCxw9xw=; b=0QrONw+rD1Xx1jNL8Kp25K5OgTnRhhsmadAByM5EhDsbI1E5VvuojZreV7PKX0ku2/ il7B3BsQsnz53bIiNn75iODBNV0EbGwcrbdw1sVpIVmn9msiRS3aPtTKNalzg7miubk/ i0YlAqVGc0RUS8fyxJcSnd8MBKwfanEtN7aAvB9m7eJ0krgKWARNvKv2l/Ln6gtM3R47 ufk1IauA/SJwm+S41UKFC9Vbl6eMLSY2O1d0Ii5wFm/uiPHz4SQvRBvyb07T9vkIPJqA kUetmyX8xO2wiqAq5cW5WAtEZSu6ArxCp2fVeAo7k41ZuhV5aCx04m5Trn1gL7d7Wh+v q6gw== 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 :content-transfer-encoding:message-id:references:to; bh=XljJqQCJX+OiMLuqz6d+oaqT/BVQJZ6ZPKUFhCxw9xw=; b=TCjuHMPb1OswOM16XnwV/iV1j94VerhUnui8XTg1aOhMnhWzthl0h8oq0CasYIwf1F 10ISO2VlbFCpTj1IYmu/tz9hEtgfoFyQHzSbV1MOZr5NcGFqfFl0dazTldBhabQ3fZ+j 79ucyMZuX63ScK3BJxtAo47yXpLHZumWIW64T3cSBZh3p+IwT9cTWvCK2s8hIh95WlU/ n2LRBqAI0LISLKce5iqaokG8r597ZBjBpFokFjc5NJ43U1VSxYS5CnfeJXgRUWu8wSqL 2XpwJa5KxoGw4gd+vI7Leg87eW85vElKg1o1Oz551ATS3u5IdmDgW0l4kP5IRFntY19w j/Hg== X-Gm-Message-State: AEkoousccebCRnc2HCpTYDhCx7OQmO5GNkVQQ0RIMor7klG7HKESXvwOGEY/0y/VwjYzzg== X-Received: by 10.66.183.80 with SMTP id ek16mr58552077pac.21.1471301671581; Mon, 15 Aug 2016 15:54:31 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id 6sm33924947pab.11.2016.08.15.15.54.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 15 Aug 2016 15:54:30 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: <6FA3F7C4-FB3E-4C98-93BC-AAD7AA4C02DA@tony.li> Date: Mon, 15 Aug 2016 15:54:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1BB63A81-2529-4240-927A-A5AC922BD9A6@gmail.com> References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <313AEC4E-DAC1-4360-B9C2-7174C349A35E@gmail.com> <6FA3F7C4-FB3E-4C98-93BC-AAD7AA4C02DA@tony.li> To: Tony Li X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sarikaya@ieee.org, =?utf-8?Q?J=C3=A9r=C3=B4me_H=C3=A4rri?= , its@ietf.org, Alexandre Petrescu Subject: Re: [its] Charter comments 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, 15 Aug 2016 22:54:33 -0000 > Dino, my dear old friend, Right on both counts. ;-) >=20 >> Tony, I think what it comes down to is, if the link-layer protocols = interoperate, what value is an IP layer. >=20 > As always, no node, or even pair of nodes, is an island. Metcalfe=E2=80=99= s law (sic) strongly suggests that providing a more general connectivity = will prove to be more powerful. We will need IP for V2I for sure. So if we have it for that, it can be = used for V2V. But I think we need to make IPv6 much more light wait. = Like perhaps, allowing the MAC address of the node be part of the IPv6 = address so address resolution and DAD can be avoided. >> The application here is very specific (don=E2=80=99t hit the car in = front of me, don=E2=80=99t hit objects near me, and make this decision = very fast) and assigning an address, doing DAD, and other chit chat = before moving the critical app data may exceed the time budget required. >=20 > While safety is of course the paramount concern, over time there are a = myriad number of other applications that can and should be done in the = vehicle. Some of those will want to interact with the broader Internet. = If we do not extend the Internet infrastructure to the vehicle directly, = it will end up happening indirectly, and in a much more awkward manner. We will extend infrastructure to vehicles. It simply a question if = vehicle to vehicle should be IP. I think it should and can be, but = others are skeptical. > As to DAD, it=E2=80=99s not at all clear to me that there needs to be = a lot of latency involved here. Obviously a link local address has a = very high likelihood of being unique. A safety application can always = worry about which system is claiming that there will be an impact after = it tries to avert the impact. And before you start in on security, = authentication should definitely not be bound to link layer or network = layer addressing: as always, that needs crypto. Agree on everything you said. But crypto does come at a cost (cost in = time) if key exchange happens. Others could comment but I heard the time = budget is around 10ms. > Now, if there are specific reasons why things can=E2=80=99t work with = IP, I=E2=80=99m open to hearing about them. But so far, I haven=E2=80=99t = seen a thing. Others can chime in. > I don't think V2V should be an IETF issue. >>=20 >> I think what you mean Behcet, as others have stated, that maybe = Internet protocols are not suitable and add more risk to the V2V case. >=20 > I would welcome specific examples. >=20 > Seems like old times, > Tony Definitely. Doesn=E2=80=99t anything really change? ;-) Dino From nobody Mon Aug 15 16:23:59 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 3F07512D1B2 for ; Mon, 15 Aug 2016 16:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 WWtTJFRpRqeI for ; Mon, 15 Aug 2016 16:23:57 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4A412D78C for ; Mon, 15 Aug 2016 16:23:56 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-07v.sys.comcast.net with SMTP id ZREWbOmjbff8qZREabReCH; Mon, 15 Aug 2016 23:23:56 +0000 Received: from [10.120.1.193] ([12.1.72.210]) by resomta-ch2-16v.sys.comcast.net with SMTP id ZRCKboyReumy1ZRCNbS8Dd; Mon, 15 Aug 2016 23:21:54 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: tony.li@tony.li In-Reply-To: <34BE1564-F274-45C7-BCCE-466D26911A71@cisco.com> Date: Mon, 15 Aug 2016 16:21:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <313AEC4E-DAC1-4360-B9C2-7174C349A35E@gmail.com> <6FA3F7C4-FB3E-4C98-93BC-AAD7AA4C02DA@tony.li> <34BE1564-F274-45C7-BCCE-466D26911A71@cisco.com> To: "Marc Linsner (mlinsner)" X-Mailer: Apple Mail (2.3124) X-CMAE-Envelope: MS4wfJQMQKmxAXtoBX9vocC7b2pS5eHQqx+R827Z5kmIc8gAaOz5J6IjHwBwq0H7Trq4nW9VM8XQGlUVzhG3tprTZb9YjJWHgQ3M1b23qK8NStRFi/oj+CuT bXp3ScmAkhbAxYR80WKnkhPoh69NFCv2lninIAprKbdpWWX4dVZHIdndYLZTQQRsIZ69Obz0lVTJ3mwQ15IPV+47LkFNZkzX6vGTVLHqrft7FZRZTe6i9uMN 3A0TmCqwR3mQ4LqcoPs5EE88q0Cz+tfBYzOkiyeeDaG2ccDN9Gb/ilYC+XKDWdJiFPzxg6urg0GMtSNm7LwHWA== Archived-At: Cc: "sarikaya@ieee.org" , "its@ietf.org" , Alexandre Petrescu , Dino Farinacci , =?utf-8?Q?J=C3=A9r=C3=B4me_H=C3=A4rri?= Subject: Re: [its] Charter comments 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, 15 Aug 2016 23:23:58 -0000 > On Aug 15, 2016, at 12:53 PM, Marc Linsner (mlinsner) = wrote: >=20 > It=E2=80=99s not that things can=E2=80=99t work on IP, but, for = example, for the specific safety messages there is no need. Ch. 172 in = the US is for low power safety messages destined for a 200m (+/-) radius = from the vehicle. Adding IP to those message provides no value to that = application. Marc, True enough. However, for many other applications it makes a great deal = of sense and is effectively going to be mandatory. Given that we have to = have that infrastructure and it=E2=80=99s pretty mature, why not use it? Tony From nobody Mon Aug 15 16:38: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 BC46D12D539 for ; Mon, 15 Aug 2016 16:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 zw6mhqCaBdrM for ; Mon, 15 Aug 2016 16:38:54 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B4912D520 for ; Mon, 15 Aug 2016 16:38:54 -0700 (PDT) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-02v.sys.comcast.net with SMTP id ZRSvbzpP10MKRZRT4baZeJ; Mon, 15 Aug 2016 23:38:54 +0000 Received: from [10.120.1.193] ([12.1.72.210]) by resomta-ch2-15v.sys.comcast.net with SMTP id ZRQpb23LqunR5ZRQtblZg3; Mon, 15 Aug 2016 23:36:52 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: tony.li@tony.li In-Reply-To: <1BB63A81-2529-4240-927A-A5AC922BD9A6@gmail.com> Date: Mon, 15 Aug 2016 16:36:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <77E7B3B1-FD04-40F2-AF32-AF6643756998@tony.li> References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <313AEC4E-DAC1-4360-B9C2-7174C349A35E@gmail.com> <6FA3F7C4-FB3E-4C98-93BC-AAD7AA4C02DA@tony.li> <1BB63A81-2529-4240-927A-A5AC922BD9A6@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3124) X-CMAE-Envelope: MS4wfLdDPxlKbulieWHuyEZCdEbUf4QQvMLMmL6zjs026c2jDpDUE/4xfM2+Ox4H3PJPnwGNNzWMpKaPMdV1UGYDw6KxPzlbkVxo3M372n4F3rv6gASU9q70 pbvfIsyyyqTRe9ZsDubSDkrd54HhiuVioaKQtKsTUp8KfKvtuaScQ0dmCMcgJm8YqgMGog0MGjTMFxO1UhzvH1Wt7D8xnNhsKBE91XK6O9bzsRjpdrxSeIyY NT+MY+zQ/sMZX5ap4JML4SrLDSSq6lVfeAQEOrRCJQjrzmQFcOGzJjNhMCZy7u2X Archived-At: Cc: sarikaya@ieee.org, =?utf-8?Q?J=C3=A9r=C3=B4me_H=C3=A4rri?= , its@ietf.org, Alexandre Petrescu Subject: Re: [its] Charter comments 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, 15 Aug 2016 23:38:56 -0000 Dino, > We will need IP for V2I for sure. So if we have it for that, it can be = used for V2V. But I think we need to make IPv6 much more light wait. = Like perhaps, allowing the MAC address of the node be part of the IPv6 = address so address resolution and DAD can be avoided. IPv6 already allows for that. See RFC 4291, section 2.5.6 for link = local addresses, plus section 2.5.1 for Modified EUI-64 interface = identifiers.=20 > We will extend infrastructure to vehicles. It simply a question if = vehicle to vehicle should be IP. I think it should and can be, but = others are skeptical. Let=E2=80=99s show =E2=80=98em why it=E2=80=99s good... > Agree on everything you said. But crypto does come at a cost (cost in = time) if key exchange happens. Others could comment but I heard the time = budget is around 10ms. No argument, but that=E2=80=99s really orthogonal. Regardless of what = layering you select, if you need strong authentication, then it has to = come via crypto of some flavor. Suggest we separate the debates. >> Seems like old times, >=20 > Definitely. Doesn=E2=80=99t anything really change? ;-) Only our hair and wrinkles. ;-) Tony From nobody Mon Aug 15 16:49:42 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 DF5A012D572 for ; Mon, 15 Aug 2016 16:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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 ij9P1hsxF-xd for ; Mon, 15 Aug 2016 16:49:39 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::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 AC34D12D0B3 for ; Mon, 15 Aug 2016 16:49:39 -0700 (PDT) Received: by mail-pa0-x230.google.com with SMTP id i5so20242116pat.2 for ; Mon, 15 Aug 2016 16:49:39 -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 :content-transfer-encoding:message-id:references:to; bh=eAuvJpBgMGuCsJhCXTNKOjK4WhwP/gISvHzFAdHlv+4=; b=Z7s55RQatAlWmonbphsSUzfajcY9NZURKgBTYmjR2OZpmEAiKBCIiB2SN3FzxoZ1lx IWPbYvft8SO3YcGUQKuINbMIh5wj/ppPSDjBkjERgalaxLOR5PxZ13MFkUVqUDT6wXcn CmZWJxojaNLaN5RJ7J8ty3Xnc1y4NKO5oK5/cwFd7xNPsjaIZJ+eBOvmAKmZzx8UzdjL iVo4T3XzGY42QW44qQrlSFl/kOqg3FC21PP6agj4Mqr2ZVVv/O+DFw1EXFqGXeJg1vt8 H3hkA7kR4xfOvoePSf7WbUDCyZBgj/IZw5AmyrwQG//0Dwz+imbfZdHf44zWhBr9AQW9 Gq6Q== 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 :content-transfer-encoding:message-id:references:to; bh=eAuvJpBgMGuCsJhCXTNKOjK4WhwP/gISvHzFAdHlv+4=; b=Z21SL8VwSLAfwPNqT5gO+wEHZjHi3pVR0uIxb/spwa182xiCqkeRKJ3Io6n9BzEs6x PaXqg2Ei4t22CHOyuRQhdMremaNtmrUwBbndiuHXG2lzAj0P3W+TA/wjIKv7mKx6YuCA a+KxuQmZh6Mg3S4Dztnp2N7jqwJx+O6f8tE2JeZpvreoOkASZ3DoWrvBO5BYwY027eHV CfvPQv5NrQ6Olq/vKKxbrLrdoiotLdHnwNqIIrddd0/tnRFAstkotu1io73PyDc2ectA C0wCliQryf7pdoNbMkik/aE4eoCqDAhJJEQ4rK9PiREwIp4sAjFmYfGkCPcAdI8ULvJc JJJw== X-Gm-Message-State: AEkoousbTy5j3KGfQUArNog91VSGFFjTelMt1fvsBmkSvUgbNK3Mu2mCB6fxMuP0wiJKyg== X-Received: by 10.66.156.226 with SMTP id wh2mr6515016pab.116.1471304979283; Mon, 15 Aug 2016 16:49:39 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id r10sm33930473pfk.84.2016.08.15.16.49.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 15 Aug 2016 16:49:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: <77E7B3B1-FD04-40F2-AF32-AF6643756998@tony.li> Date: Mon, 15 Aug 2016 16:49:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8E7DEA2A-E1B8-4BCF-BDB5-D5B7131B6235@gmail.com> References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <313AEC4E-DAC1-4360-B9C2-7174C349A35E@gmail.com> <6FA3F7C4-FB3E-4C98-93BC-AAD7AA4C02DA@tony.li> <1BB63A81-2529-4240-927A-A5AC922BD9A6@gmail.com> <77E7B3B1-FD04-40F2-AF32-AF6643756998@tony.li> To: Tony Li X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sarikaya@ieee.org, =?utf-8?Q?J=C3=A9r=C3=B4me_H=C3=A4rri?= , its@ietf.org, Alexandre Petrescu Subject: Re: [its] Charter comments 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, 15 Aug 2016 23:49:41 -0000 > No argument, but that=E2=80=99s really orthogonal. Regardless of what = layering you select, if you need strong authentication, then it has to = come via crypto of some flavor. Suggest we separate the debates. True, the cost will be paid no matter where it is done. Dino From nobody Tue Aug 16 01:29: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 98DB512D567 for ; Tue, 16 Aug 2016 01:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247] 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 is-_K5rmVXyn for ; Tue, 16 Aug 2016 01:29:37 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id 1665212D187 for ; Tue, 16 Aug 2016 01:29:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,529,1464645600"; d="scan'208";a="4477346" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 16 Aug 2016 10:29:35 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id D85DCC50; Tue, 16 Aug 2016 10:29:35 +0200 (CEST) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: , "'Dino Farinacci'" References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <313AEC4E-DAC1-4360-B9C2-7174C349A35E@gmail.com> <6FA3F7C4-FB3E-4C98-93BC-AAD7AA4C02DA@tony.li> <1BB63A81-2529-4240-927A-A5AC922BD9A6@gmail.com> <77E7B3B1-FD04-40F2-AF32-AF6643756998@tony.li> In-Reply-To: <77E7B3B1-FD04-40F2-AF32-AF6643756998@tony.li> Date: Tue, 16 Aug 2016 10:29:35 +0200 Organization: EURECOM Message-ID: <004e01d1f798$526119c0$f7234d40$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLnYvWbuj0Jb9+O5N4XnF9Mh3Dn+wIyijYuAdVBt/YCIplQUQFlklk6AnsJe3QBS0HvmwHJxDAgAxImit8CFkiDKJ2OI+Ug Content-Language: en-us Archived-At: Cc: sarikaya@ieee.org, 'Alexandre Petrescu' , its@ietf.org Subject: Re: [its] Charter comments 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, 16 Aug 2016 08:29:39 -0000 Dear All, Let's try not to restart the already past debate on IP or not IP. The = charter specifically mentions that this WG will NOT address = safety-critical applications, for which non-IP solutions already exist = and so far are largely sufficient.=20 So, now if you consider that the applications considered by this WG will = be either 'complementary' to safety or not safety-related, there is no = debate related to 'IP or not IP'...IPv6 is required. Period.=20 The only point we need to keep in mind is that IPv6 will need to = co-exist with non-IP mechanisms, and due to the safety-critical nature = of their applications, IPv6 should not create any 'protocol' = interference with non-IP solutions (e.g. overhead, occupying channel, = security/privacy breach etc..).=20 But again, we already had a long discussion on this in the past: neither = IEEE 1609 nor ETSI ITS accept IP (and IPv6) on their safety-critical = channel (ch. 178 in US, ch. 180 in EU), so IPv6-related = applications/services/protocols developed in this WG will be sent on a = different channel.=20 Security is one of the IP-nonIP 'co-existence' challenge we need to = handle. It is not about complexity or time, but to be synch to the = security/privacy fully controlled by the non-IP stack. Said it simple: = when the non-IP stack changes its pseudonym and the ID of all its = layers, so MUST do the IPv6 stack...otherwise we breach the = security/privacy provision created by the non-IP stack..We can thus use = their strategy if it is present (use the non-IP certificate/pseudonyms = if available) or provide an strictly cryptographic equivalent one with = other strategies.. Best Regards, J=C3=A9r=C3=B4me =20 -----Original Message----- From: tony.li@tony.li [mailto:tony.li@tony.li]=20 Sent: Tuesday 16 August 2016 01:37 To: Dino Farinacci Cc: sarikaya@ieee.org; J=C3=A9r=C3=B4me H=C3=A4rri; Alexandre Petrescu; = its@ietf.org Subject: Re: [its] Charter comments Dino, > We will need IP for V2I for sure. So if we have it for that, it can be = used for V2V. But I think we need to make IPv6 much more light wait. = Like perhaps, allowing the MAC address of the node be part of the IPv6 = address so address resolution and DAD can be avoided. IPv6 already allows for that. See RFC 4291, section 2.5.6 for link = local addresses, plus section 2.5.1 for Modified EUI-64 interface = identifiers.=20 > We will extend infrastructure to vehicles. It simply a question if = vehicle to vehicle should be IP. I think it should and can be, but = others are skeptical. Let=E2=80=99s show =E2=80=98em why it=E2=80=99s good... > Agree on everything you said. But crypto does come at a cost (cost in = time) if key exchange happens. Others could comment but I heard the time = budget is around 10ms. No argument, but that=E2=80=99s really orthogonal. Regardless of what = layering you select, if you need strong authentication, then it has to = come via crypto of some flavor. Suggest we separate the debates. >> Seems like old times, >=20 > Definitely. Doesn=E2=80=99t anything really change? ;-) Only our hair and wrinkles. ;-) Tony From nobody Wed Aug 17 12:30: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 34BF512D5CC for ; Wed, 17 Aug 2016 12:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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 k5sFZWUDGsKO for ; Wed, 17 Aug 2016 12:30:09 -0700 (PDT) Received: from mail-pa0-x244.google.com (mail-pa0-x244.google.com [IPv6:2607:f8b0:400e:c03::244]) (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 0F0AD12D0E4 for ; Wed, 17 Aug 2016 12:30:09 -0700 (PDT) Received: by mail-pa0-x244.google.com with SMTP id ez1so7906430pab.3 for ; Wed, 17 Aug 2016 12:30:09 -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 :content-transfer-encoding:message-id:references:to; bh=6VFeu8alMwhah9bgCWMHCNoPCYkILXVjxGtqMik+Ssw=; b=b+p8nNjXM7bNaz5TYkrSW0eBnqiOB7n/NSeE409kvZn6qz1rTpwdcknT71sSpqFjH7 g/fB2RHicBHbcJO7X2eb4nxGMTiqzeT5tLpTe+33H2Yh5naIbRUapiG4PyOxK4sr1Ub5 MNIw+kk02KyDm7bPjCkGZ8wyZMKLmcgwZGOKS/5g42ytzvYfMSNlCe4/FqZgXnhgkNhK Gf9diSqSriKQ/uS2KW3jcfmj8oYi95nw3b7sN8ExmM6vbc435KQj0zEsiYxFQONC67g5 A9Xr+x7f0E48O0U2nIWjQ5s7chiYefnYETC6eiGwAKguEjd5BsRyCBcaJdGN770G4rBo 8NPw== 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 :content-transfer-encoding:message-id:references:to; bh=6VFeu8alMwhah9bgCWMHCNoPCYkILXVjxGtqMik+Ssw=; b=h8t/NNGqUFBEVzgn0mmD8rvkx7I5ycwCcuOrE9165X74A9JCd+81Sa3CE5KQa496c+ 8nj5JXInN53ygkMWpzaa9mO5fbr/p3Ww7xnxY/7G+XtcP0TJH6XMMqkcWQJ23HFqFtFL m7U/o8ZKtbNa28NL3Zuj7qcM/zn7QUXBc02uwMDYbu8hxfj7eu1zTxGe5U7rm4MIk88O o25qH/V/i4kQSPwLCep8gryodXYVrJOB0BWKvxitaEKAYw2sHjl7uFFjXHKbWeBlArXx iNyOPWjEsYMbfeX/9SRGCnw8nk5NNgvsSYQ5mKpoJNtX6I8DOF/BqseM/1YVuBN0yQvV 9Xqw== X-Gm-Message-State: AEkoousHNWrrzOK1OgA1uQyLz2H9HZpULgq4aHWpX3Jjzg+bXocHhdEHJJwZQbqrzW/hJw== X-Received: by 10.66.172.237 with SMTP id bf13mr23307351pac.42.1471462208535; Wed, 17 Aug 2016 12:30:08 -0700 (PDT) Received: from ?IPv6:2601:646:8d01:89f0:5054:a1bf:d2a4:f95? ([2601:646:8d01:89f0:5054:a1bf:d2a4:f95]) by smtp.gmail.com with ESMTPSA id r2sm600906pal.14.2016.08.17.12.30.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Aug 2016 12:30:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: <3E022D2E5CEB4F74AFC91DCB155F8F2D@SRA6> Date: Wed, 17 Aug 2016 12:30:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6BB23F20-7228-441D-A694-CFFCF2F5FBDC@gmail.com> References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <313AEC4E-DAC1-4360-B9C2-7174C349A35E@gmail.com> <3E022D2E5CEB4F74AFC91DCB155F8F2D@SRA6> To: dickroy@alum.mit.edu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sarikaya@ieee.org, Tony Li , Alexandre Petrescu , its@ietf.org, =?utf-8?Q?J=C3=A9r=C3=B4me_H=C3=A4rri?= Subject: Re: [its] Charter comments 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, 17 Aug 2016 19:30:13 -0000 We can make v2v for non-safety use-cases work very simply with IPv6 = defined as EIDs. Here is a possible scenario: (1) Each device is assigned a static/non-changing IPv6 EID. (2) The low-order 64-bits maps to its MAC address. (3) This EID can also be used for v2i use-cases. See my presentation how = to map this EID to a predictive-RLOC set so the mobility problem has = near-0 packet loss. The EID knows what destination it wants to talk to in the v2i case. But = in the v2v case, there needs to be some discovery (what is the IP/MAC in = front of me on the road, what IP/MACs are following me). I presume this = is already solved with the IEEE 1609 protocols. So what if the high-order 64-bits of the IPv6 EID is well-known and = allocated for ITS, then we can reverse map real quickly. For instance: (1) 1609 tells me that a BCM I just received is from MAC 0000-1111-2222 = for a car behind me. (2) That means if I can give a weather report to the car by sending an = IPv6 packet to 2001:5:xxxx::0000.1111.2222 perhaps (I chose 2001:5::/16 = because it has been allocated by IANA for experimental use for LISP = EIDs). (3) And if there is any infra communication and third-party referrals, = the IPv6 EID is the same. And note, if the car is multi-homed, you DON=E2=80=99T need to have = multiple provider assigned addresses. Just one EID, global, static, = non-changing, independent from anything else. Level of indirection, Dino > On Aug 17, 2016, at 11:43 AM, Dick Roy wrote: >=20 > Please do not confuse V2V with application exchanges between vehicles = (and > other devices) for safety purposes. V2V exchanges on Ch172/180 = (sending of > BSMs and CAMs, etc.) is one of many ITS safety related applications. = A V2V > exchange can (and very likely will) involve IP networking at some = point in > the path between source and destination (e.g. sending a "black-ice = warning" > to vehicles "many miles back" is a simple use case). That said, = Dino's > comment below is worth remembering. There will be applications that = do not > require a complex network layer to successfully complete their = mission. > There may be good reasons to NOT use IP networking in such situations. >=20 > RR >=20 > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com]=20 > Sent: Monday, August 15, 2016 2:20 PM > To: sarikaya@ieee.org > Cc: Alexandre Petrescu; Tony Li; J=C3=A9r=C3=B4me H=C3=A4rri; = its@ietf.org > Subject: Re: [its] Charter comments >=20 >> I don't think V2V should be an IETF issue. >=20 > I think what you mean Behcet, as others have stated, that maybe = Internet > protocols are not suitable and add more risk to the V2V case. >=20 > Tony, I think what it comes down to is, if the link-layer protocols > interoperate, what value is an IP layer. The application here is very > specific (don=E2=80=99t hit the car in front of me, don=E2=80=99t hit = objects near me, and > make this decision very fast) and assigning an address, doing DAD, and = other > chit chat before moving the critical app data may exceed the time = budget > required. >=20 > Dino >=20 >> Regarding V2I, if you don't like it, propose another name. >>=20 >> Behcet >>=20 >> On Mon, Aug 15, 2016 at 12:22 PM, J=C3=A9r=C3=B4me H=C3=A4rri = > wrote: >>> Dear All, >>>=20 >>> =46rom a pure L2 link, we should not make a major difference if = vehicles > are communicating V2V or V2I (beside the enhanced range available by > RSUs)..a node is a node indeed. But from an IPv6 architecture, this = will > make a difference, as the RSU may be connected to the IPv6 backbone = and as > such have additional properties (prefix, gateway etc..). >>>=20 >>> It is yet also not as simple to say that when two vehicles are in = range > that the communicate...of course they will (at least try), but there = will be > different aspects to consider. For example, if the vehicle is = 'involved in > traffic' and/or his 'engine is on/key in the ignition', then it will = need to > transmit CAM/BSM. >>> So, the IPv6 will need to 'co-exist' with non IP higher priority = traffic > (and operate in different channels for instance). But when the car is = not > involved in traffic, engine and key off, then IPv6 might use the full > spectrum of the ITS-G5 radio (no 1609.4 channel switching for = instance..) >>>=20 >>> My two cents, >>>=20 >>> Cheers, >>>=20 >>> J=C3=A9r=C3=B4me >>>=20 >>> -----Original Message----- >>> From: its [mailto:its-bounces@ietf.org] On Behalf Of Tony Li >>> Sent: Monday 15 August 2016 18:58 >>> To: sarikaya@ieee.org >>> Cc: Alexandre Petrescu; its@ietf.org >>> Subject: Re: [its] Charter comments >>>=20 >>>=20 >>>> On Aug 15, 2016, at 9:31 AM, Behcet Sarikaya = > wrote: >>>>=20 >>>>> If on the other hand one considers that two directly connected >>>>> vehicles form already a small island of a small Internet, then a = 3rd >>>>> vehicle connecting to this island _could_ be called V2I. >>>>>=20 >>>> Yes but no infrastructural nodes are involved? >>>=20 >>>=20 >>> Hi there, >>>=20 >>> Sorry I=E2=80=99m late to the discussion, but I=E2=80=99m missing = out on the > architectural difference here. >>>=20 >>> What does it matter if a node is a vehicle or infra? What do you = consider > a vehicle that=E2=80=99s parked? >>>=20 >>> Seems to me that a node is a node is a node=E2=80=A6 If they are in = range of > each other, then they chat. >>>=20 >>> Tony >>>=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 >=20 >=20 >=20 From nobody Wed Aug 17 12:45:03 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 25EEA12D594 for ; Wed, 17 Aug 2016 12:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 xLEstjraXu97 for ; Wed, 17 Aug 2016 12:45:00 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB41612D556 for ; Wed, 17 Aug 2016 12:45:00 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-02v.sys.comcast.net with SMTP id a6lib2piQ0MKRa6lobh0Sg; Wed, 17 Aug 2016 19:45:00 +0000 Received: from [10.120.1.193] ([12.1.72.210]) by resomta-ch2-17v.sys.comcast.net with SMTP id a6jSbgPDQrG54a6jVbtgUh; Wed, 17 Aug 2016 19:42:58 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_65568539-5C15-429B-82F4-E204A8DD5BC2" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: tony.li@tony.li In-Reply-To: Date: Wed, 17 Aug 2016 12:42:32 -0700 Message-Id: <4B9DA6BF-02F4-40B3-9AEF-A69787B3BA10@tony.li> References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <313AEC4E-DAC1-4360-B9C2-7174C349A35E@gmail.com> <6FA3F7C4-FB3E-4C98-93BC-AAD7AA4C02DA@tony.li> To: dickroy@alum.mit.edu X-Mailer: Apple Mail (2.3124) X-CMAE-Envelope: MS4wfK7TyYaZn0lAnj19lZQrb242hA8/fUskpKKm6gdEIbpbaC8M9u6cdBTd4hi/y6sUBR+gO+smp27a73eZD6yz3OrqXKiM2IE7tmrhvP+o94q6gdVjJHRK Q4DFc3CzrvaOxg460LiYh9vF2pl9kHm3smT/fNDvO60S6HfrvPMnm4cHDu4bPuN1vLUCDQFy193/3g4LoUM6qVXs1Fsj/XbD8toinIJUjhsO38nbYaZ3u6BT 4ODC+qxilMLraq0cnv1cbNI44NfG55xdlkInPievqnA8buHj2Ielbf0bPIh6W3c0V6Qo2Jjvabi+/EgEnuXzUg== Archived-At: Cc: sarikaya@ieee.org, Alexandre Petrescu , =?utf-8?Q?J=C3=A9r=C3=B4me_H=C3=A4rri?= , Dino Farinacci , its@ietf.org Subject: Re: [its] Charter comments 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, 17 Aug 2016 19:45:02 -0000 --Apple-Mail=_65568539-5C15-429B-82F4-E204A8DD5BC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > As always, no node, or even pair of nodes, is an island. Metcalfe=E2=80=99= s law (sic) strongly suggests that providing a more general connectivity = will prove to be more powerful. > [RR] If they all are on the same LAN, and thereby running the same = layer 2 protocols, then bridging works very well. That was the point = made earlier I believe.=20 Agreed, with well-demonstrated scalability limitations. The point is = that the ability to interact with the broader Internet will be = compelling. =20 > I would welcome specific examples. > [RR] As mentioned several times previously, the minimum 40 octet IPv6 = header is unnecessary overhead for BSMs and significantly adds to = channel congestion (which is already known to be an issue). And I=E2=80=99m happy to stipulate the BSM case. What else? Tony --Apple-Mail=_65568539-5C15-429B-82F4-E204A8DD5BC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
As always, no node, or even pair of nodes, is an island. = Metcalfe=E2=80=99s law (sic) strongly suggests that providing a more = general connectivity will prove to be more powerful.
[RR] If they = all are on the same LAN, and thereby running the same layer 2 protocols, = then bridging works very well.  That was the point made earlier I = believe. 


Agreed, with = well-demonstrated scalability limitations. The point is that the ability = to interact with the broader Internet will be compelling.

 
I would welcome specific examples.
[RR] As mentioned = several times previously, the minimum 40 octet IPv6 header is = unnecessary overhead for BSMs and significantly adds to channel = congestion (which is already known to be an issue).


And I=E2=80=99m happy to = stipulate the BSM case.  What else?

Tony


= --Apple-Mail=_65568539-5C15-429B-82F4-E204A8DD5BC2-- From nobody Wed Aug 17 14:25:28 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 DC17112D771 for ; Wed, 17 Aug 2016 14:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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 KNcIp8HbYd20 for ; Wed, 17 Aug 2016 14:25:24 -0700 (PDT) Received: from mail-pa0-x242.google.com (mail-pa0-x242.google.com [IPv6:2607:f8b0:400e:c03::242]) (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 A975F12D76C for ; Wed, 17 Aug 2016 14:25:19 -0700 (PDT) Received: by mail-pa0-x242.google.com with SMTP id ez1so16727pab.3 for ; Wed, 17 Aug 2016 14:25:19 -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 :content-transfer-encoding:message-id:references:to; bh=SVTe4RdCZdPrJKpP2TB/nEGfDEWCFlbtSz88c/Q1MEo=; b=aIwFnjiYTLCllYVLIBwR4Y7fsluQdFLt9t55ccACNxKWL3KPU8cXw59wLE+eZjFWev UQiXeGxRt6ZQqbDsGCa7Nx4ydKaGuK6WZRlVUXEYJXrwr5s2u1GrJlIyvSTApLTQ1ywp Kb1v5G35dxJ57+P1adWQH5rauTqNoe/dEE6Eg29Bh2yUfSCvEw3rsBOo66u48oPCFvO6 aVV/dd7wol6nRfhRljUG7W6bA918xEPMQu7Rirvyzb3Sxi5s6Qq2RxDPdFoBlFUnpqm/ Um3YmMTyZ1yyk8cFeI5C9GwLQTQIzsf76bF5PjRagdXPtXV0AxfSDFqBGI2EH6dPBQnt hRfQ== 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 :content-transfer-encoding:message-id:references:to; bh=SVTe4RdCZdPrJKpP2TB/nEGfDEWCFlbtSz88c/Q1MEo=; b=j4F4DzlnadkujhDC32qo9G3Y/1nT8gfbGkVZEhUmtT1BdC1VRXoxQLtWCBpzHKfTtX fawGCggITtJR3MqnT+iXiNTy9ZZ8GZKIk+NorP4Qrr0oRzSx+uLzNzbOnrAkioXO2Jcy yQtlqrhi9/4YCRwI7OGOhJwDmkzif6CxByHH8EOBLQqWg8ZfU4fPCoJS9wP3nBJBAizL 8okw770Aohzl0TLoS2DjXUrkL8bSXyCpnxQPbJK+u6fZKkZLomHhHw3YvBbp0Ns3nose eDU3K0sjdI3azx6IDA5omUsA3lwfczQ7vo6mqxNmHhq5yMiFuCUXFSfSagb0K1ygaOa1 e4OA== X-Gm-Message-State: AEkoouufQEGO9c/TmEB10atYCEbcMJijo6vjEc1qzPug45WurIFyWbXSvmgPG9/lY6S/rw== X-Received: by 10.66.74.103 with SMTP id s7mr77318569pav.1.1471469119253; Wed, 17 Aug 2016 14:25:19 -0700 (PDT) Received: from ?IPv6:2601:646:8d01:89f0:5054:a1bf:d2a4:f95? ([2601:646:8d01:89f0:5054:a1bf:d2a4:f95]) by smtp.gmail.com with ESMTPSA id 84sm49382591pfp.59.2016.08.17.14.25.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Aug 2016 14:25:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: Date: Wed, 17 Aug 2016 14:25:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2B1752ED-8152-40D5-9651-E08F39F8A767@gmail.com> References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <313AEC4E-DAC1-4360-B9C2-7174C349A35E@gmail.com> <3E022D2E5CEB4F74AFC91DCB155F8F2D@SRA6> <6BB23F20-7228-441D-A694-CFFCF2F5FBDC@gmail.com> To: dickroy@alum.mit.edu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sarikaya@ieee.org, Tony Li , Alexandre Petrescu , its@ietf.org, =?utf-8?Q?J=C3=A9r=C3=B4me_H=C3=A4rri?= Subject: Re: [its] Charter comments 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, 17 Aug 2016 21:25:27 -0000 > =20 > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com]=20 > Sent: Wednesday, August 17, 2016 3:30 PM > To: dickroy@alum.mit.edu > Cc: sarikaya@ieee.org; Alexandre Petrescu; Tony Li; J=C3=A9r=C3=B4me = H=C3=A4rri; its@ietf.org > Subject: Re: [its] Charter comments > =20 > We can make v2v for non-safety use-cases work very simply with IPv6 = defined as EIDs. Here is a possible scenario: > =20 > (1) Each device is assigned a static/non-changing IPv6 EID. > (2) The low-order 64-bits maps to its MAC address. > [RR] There is no =E2=80=9Cits MAC address=E2=80=9D. They tumble! Yes, = sessions break when they do, so this needs to be taken into account =E2=80= =A6 I mean if I discovered a MAC because because it is broadcasting and I = want to talk back to it, then knowing the MAC address to build frames is = kinda critical to know. ;-) > (3) This EID can also be used for v2i use-cases. See my presentation = how to map this EID to a predictive-RLOC set so the mobility problem has = near-0 packet loss. > =20 > The EID knows what destination it wants to talk to in the v2i case. = But in the v2v case, there needs to be some discovery (what is the = IP/MAC in front of me on the road, what IP/MACs are following me). I = presume this is already solved with the IEEE 1609 protocols. > [RR] Not even close. The IEEE 1609 protocols simply say =E2=80=A6 = =E2=80=9Cdo IPv6 according to RFCXXXX and friends=E2=80=9D (except for = the WRA in the service announcement of course). =20 Well the whole point of this group is to make the protocols at multiple = layers work better together. > So what if the high-order 64-bits of the IPv6 EID is well-known and = allocated for ITS, then we can reverse map real quickly. For instance: > =20 > (1) 1609 tells me that a BCM I just received is from MAC = 0000-1111-2222 for a car behind me. > (2) That means if I can give a weather report to the car by sending an = IPv6 packet to 2001:5:xxxx::0000.1111.2222 perhaps (I chose 2001:5::/16 = because it has been allocated by IANA for experimental use for LISP = EIDs). > [RR] Fine, however, unless the car is out of range, you could simply = have used WSMP and the same MAC address (which only works if the car = behind you has implemented the =E2=80=9Cweather report reception=E2=80=9D = application behind some well-known port). Since you just received a BSM = from him and you are travelling the same direction, you=E2=80=99d = probably get through. Now let=E2=80=99s assume you use IPv6 and send it We can use layer-3 and layer-2 link-local multicast for all apps too. As = long as the app doesn=E2=80=99t care if others in range get the packets. = But I=E2=80=99m probably going to hear from people on this list, that = bandwidth is precious so don=E2=80=99t use it gratituiosuly. > to the address you quote. What MAC address will you use? Probably = the broadcast address, because that=E2=80=99s the only one other than = the transmitter BA that makes sense. What will any receiver of that = packet do with it? Probably pitch it because it does not have IPv6 = forwarding implemented, and even if it did, its routing tables will not = be properly populated to tell it what to do...no time for discovery! = :^)) We are talking about the other applications that could run that Tony was = referring to. The car behind me won=E2=80=99t pitch the packet if it = wants to receive weather reports. It has an app running with an open = listen() socket. Dino > (3) And if there is any infra communication and third-party referrals, = the IPv6 EID is the same. > =20 > And note, if the car is multi-homed, you DON=E2=80=99T need to have = multiple provider assigned addresses. Just one EID, global, static, = non-changing, independent from anything else. > =20 > Level of indirection, > Dino > =20 > > On Aug 17, 2016, at 11:43 AM, Dick Roy wrote: > >=20 > > Please do not confuse V2V with application exchanges between = vehicles (and > > other devices) for safety purposes. V2V exchanges on Ch172/180 = (sending of > > BSMs and CAMs, etc.) is one of many ITS safety related applications. = A V2V > > exchange can (and very likely will) involve IP networking at some = point in > > the path between source and destination (e.g. sending a "black-ice = warning" > > to vehicles "many miles back" is a simple use case). That said, = Dino's > > comment below is worth remembering. There will be applications that = do not > > require a complex network layer to successfully complete their = mission. > > There may be good reasons to NOT use IP networking in such = situations. > >=20 > > RR > >=20 > > -----Original Message----- > > From: Dino Farinacci [mailto:farinacci@gmail.com]=20 > > Sent: Monday, August 15, 2016 2:20 PM > > To: sarikaya@ieee.org > > Cc: Alexandre Petrescu; Tony Li; J=C3=A9r=C3=B4me H=C3=A4rri; = its@ietf.org > > Subject: Re: [its] Charter comments > >=20 > >> I don't think V2V should be an IETF issue. > >=20 > > I think what you mean Behcet, as others have stated, that maybe = Internet > > protocols are not suitable and add more risk to the V2V case. > >=20 > > Tony, I think what it comes down to is, if the link-layer protocols > > interoperate, what value is an IP layer. The application here is = very > > specific (don=E2=80=99t hit the car in front of me, don=E2=80=99t = hit objects near me, and > > make this decision very fast) and assigning an address, doing DAD, = and other > > chit chat before moving the critical app data may exceed the time = budget > > required. > >=20 > > Dino > >=20 > >> Regarding V2I, if you don't like it, propose another name. > >>=20 > >> Behcet > >>=20 > >> On Mon, Aug 15, 2016 at 12:22 PM, J=C3=A9r=C3=B4me H=C3=A4rri = > > wrote: > >>> Dear All, > >>>=20 > >>> =46rom a pure L2 link, we should not make a major difference if = vehicles > > are communicating V2V or V2I (beside the enhanced range available by > > RSUs)..a node is a node indeed. But from an IPv6 architecture, this = will > > make a difference, as the RSU may be connected to the IPv6 backbone = and as > > such have additional properties (prefix, gateway etc..). > >>>=20 > >>> It is yet also not as simple to say that when two vehicles are in = range > > that the communicate...of course they will (at least try), but there = will be > > different aspects to consider. For example, if the vehicle is = 'involved in > > traffic' and/or his 'engine is on/key in the ignition', then it will = need to > > transmit CAM/BSM. > >>> So, the IPv6 will need to 'co-exist' with non IP higher priority = traffic > > (and operate in different channels for instance). But when the car = is not > > involved in traffic, engine and key off, then IPv6 might use the = full > > spectrum of the ITS-G5 radio (no 1609.4 channel switching for = instance..) > >>>=20 > >>> My two cents, > >>>=20 > >>> Cheers, > >>>=20 > >>> J=C3=A9r=C3=B4me > >>>=20 > >>> -----Original Message----- > >>> From: its [mailto:its-bounces@ietf.org] On Behalf Of Tony Li > >>> Sent: Monday 15 August 2016 18:58 > >>> To: sarikaya@ieee.org > >>> Cc: Alexandre Petrescu; its@ietf.org > >>> Subject: Re: [its] Charter comments > >>>=20 > >>>=20 > >>>> On Aug 15, 2016, at 9:31 AM, Behcet Sarikaya = > > wrote: > >>>>=20 > >>>>> If on the other hand one considers that two directly connected > >>>>> vehicles form already a small island of a small Internet, then a = 3rd > >>>>> vehicle connecting to this island _could_ be called V2I. > >>>>>=20 > >>>> Yes but no infrastructural nodes are involved? > >>>=20 > >>>=20 > >>> Hi there, > >>>=20 > >>> Sorry I=E2=80=99m late to the discussion, but I=E2=80=99m missing = out on the > > architectural difference here. > >>>=20 > >>> What does it matter if a node is a vehicle or infra? What do you = consider > > a vehicle that=E2=80=99s parked? > >>>=20 > >>> Seems to me that a node is a node is a node=E2=80=A6 If they are = in range of > > each other, then they chat. > >>>=20 > >>> Tony > >>>=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 > >=20 > >=20 > >=20 From nobody Fri Aug 19 13:14: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 ACC2C12D5BF for ; Fri, 19 Aug 2016 13:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 UOiNLLE-c4oh for ; Fri, 19 Aug 2016 13:14:10 -0700 (PDT) Received: from atl4mhob13.myregisteredsite.com (atl4mhob13.myregisteredsite.com [209.17.115.51]) by ietfa.amsl.com (Postfix) with ESMTP id D4FE112D1D7 for ; Fri, 19 Aug 2016 13:09:09 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob13.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u7JK95l1024586 for ; Fri, 19 Aug 2016 16:09:05 -0400 Received: (qmail 5602 invoked by uid 0); 19 Aug 2016 20:09:05 -0000 X-TCPREMOTEIP: 108.51.227.121 X-Authenticated-UID: fygs@pilotresearch.com Received: from unknown (HELO FrancoisPC) (fygs@pilotresearch.com@108.51.227.121) by 0 with ESMTPA; 19 Aug 2016 20:09:05 -0000 From: "Francois Simon" To: Date: Fri, 19 Aug 2016 16:09:05 -0400 Message-ID: <000001d1fa55$89c55470$9d4ffd50$@pilotresearch.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D1FA34.02B86F60" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdH6VVw0HxQCss7mRQG2BtEr6w96Zg== Content-Language: en-us Archived-At: Subject: [its] Charter Comments 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, 19 Aug 2016 20:14:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D1FA34.02B86F60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >From Francois Simon Charter Comments CHARTER Automobiles and vehicles of all types are increasingly connected to the Internet. Comfort-enhancing entertainment applications, road safety applications using bidirectional data flows, and connected automated driving are but a few new features expected in automobiles to hit the roads from now to year 2020. Today, there are several deployed Vehicle-to-Internet technologies (V2Internet) that make use of embedded Internet modules, or through driver's cellular smartphone: mirrorlink, carplay, android auto. However, Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I, not to be mistaken with V2Internet) communications are still being developed. Some vehicle and infrastructure communications will use IP and others will not. Multiple applications need to share one data link, including non-IP-based protocols sharing the data link with IP-based protocols. Fygs - It is assumed that "data link" here is per ISO/IEC 7498-1 standard definition and not a particular medium channel. Multiple data link instances may use a common medium channel, as well as a single data link instance my use multiple media. This group will work on V2V and V2I use-cases where IP is well-suited as a networking technology, supporting also applications that involve exchanges of safety-related messages between vehicles and infrastructure if necessary. Fygs - Safety-related messages may require to be prioritized based on the source application requirements. (e.g,. announcement of weather conditions 10 km ahead will not have the same urgency than a stopped vehicle 300 m ahead). Depending on the application's priority, decision to use IP or other protocol needs to be assessed. This group will develop IP-based protocols to establish direct and secure connectivity between a vehicle, which is often comprised of moving networks, and other vehicles and stationary systems. Some communications will be extremely short lived, but others will last for many hours or days. Moving network to nearby moving or fixed network communications may involve various kinds of link layers: 802.11-OCB (Outside the Context of a Basic Service Set, also called 802.11p), 802.15.4 with 6lowpan, 802.11ad, VLC (Visible Light Communications), IrDA, LTE-D, LP-WAN. One of the most used link layers for vehicular networks is IEEE 802.11-OCB, as a basis for DSRC. However, IPv6 on 802.11-OCB is not yet defined. Fygs - This paragraph brings in a vast array of questions related to the actual scope of the group developing "IP-based protocols to establish connectivity" between entities in motion and/or stationary. It is not the intention here to open a philosophical discussion of the various entities that may or may not be in scope, but merely to point out the need for precise definitions of entities involved in the "connectivity". Follow are few question examples which comes to mind (no particular order): * Does the entities in motion are related to vehicles only? * Does living entities and/or "things" in motion capable of establishing IP connectivity are excluded? o One can argue that a conveyor belt is a "transportation system". * Which mobile entities are excluded from the scope? * The same type of questions can apply to stationary systems: o Tethered or wireless land connectivity (i.e.; Free Space Optics (FSO) * Etc. The list can be extensive. The group will work only on IPv6 solutions. The group will leverage on technologies for Internet of Things (IoT) which are developed in other IETF and IRTF efforts: 6lo WG, LP-WAN WG, and T2T RG. Co-existence with techniques of infrastructure mobility management will be coordinated with the DMM WG, LISP WG, and other mobility solutions. The SDOs interested in this work are: ISO/TC204, ETSI TC ITS, 3GPP, NHTSA and more. This group will not work on V2V or V2I use-cases where IP is not well-suited. Without re-chartering, this group will not work on Delay-Tolerant Networking nor on Information-Centric Networking. If the group is successful in accomplishing its first goals, then it can be rechartered to work on other things (examples include but are not limited to: a 1-hop mechanism of IP prefix exchange between moving networks, an n-hop extension, naming for moving networks; generalization for trains, air, unmanned and space use-cases). WORK ITEMS 1. Standards Track RFC "IPv6 over 802.11p" Fygs - As reference - It is believed that the actual IEEE Std 802.11p is no longer available. This standard was the amendment of IEEE Std 802.11-2007. The amendment has been incorporated in the current IEEE Std 802.11-2012. Note that the clause references in 802.11-2012 are not in line with 802.11p-2010. 2. Potential Informational RFC "ITS General Problem Area" covering: - What is ITS? -- Explain V2V, V2I, and related terms - Why is IPv6 needed? -- Explain why some traffic will not use IPv6 -- Explain why other traffic will use IPv6 - Use-cases, illustrating the expected areas for initial focus - Informative references, relationship with other SDOs 3. Potential Informational RFC "Problem Statement" covering: - Problem statement - Security considerations - Privacy considerations MILESTONES Oct 2016 - Draft for "IPv6 over 802.11-OCB" adopted by WG Dec 2016 - Draft for "ITS General Problem Area" adopted by WG Mar 2017 - Draft for "Problem Statement" adopted by WG May 2017 - Submit "IPv6 over 802.11-OCB" to IESG Oct 2017 - Submit "ITS General Problem Area" to IESG May 2018 - Submit "Problem Statement" to IESG ------=_NextPart_000_0001_01D1FA34.02B86F60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From Francois Simon

 

Charter = Comments

CHARTER

Automobiles and vehicles of all = types are increasingly connected to the Internet.  = Comfort-enhancing entertainment applications, road safety applications = using bidirectional data flows, and connected automated driving are but = a few new features expected in automobiles to hit the roads from now to = year 2020.

Today, there are several deployed Vehicle-to-Internet = technologies
(V2Internet) that make use of embedded Internet modules, = or through driver's cellular smartphone: mirrorlink, carplay, android = auto.
However, Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure = (V2I, not to be mistaken with V2Internet) communications are still being = developed.

Some vehicle and infrastructure communications will = use IP and others will not.  Multiple applications need to share = one data link, including non-IP-based protocols sharing the data link = with IP-based protocols.

Fygs - It is assumed = that “data link” here is per ISO/IEC 7498-1 standard definition and not a particular medium = channel. Multiple data link instances may use a common medium channel, = as well as a single data link instance my use multiple = media.


This group will work = on V2V and V2I use-cases where IP is well-suited as a networking = technology, supporting also applications that involve exchanges of = safety-related messages between vehicles and infrastructure if = necessary.

Fygs – Safety-related messages may require = to be prioritized based on the source application requirements. (e.g,. = announcement of weather conditions 10 km ahead will not have the same = urgency than a stopped vehicle 300 m ahead). Depending on the = application’s priority, decision to use IP or other protocol needs = to be assessed.

This group will develop IP-based protocols to = establish direct and secure connectivity between a vehicle, which is = often comprised of moving networks, and other vehicles and stationary = systems.  Some communications will be extremely short lived, but = others will last for many hours or days.


Moving network to = nearby moving or fixed network communications may involve various kinds = of link layers: 802.11-OCB (Outside the Context of a Basic Service Set, = also called 802.11p), 802.15.4 with 6lowpan, 802.11ad, VLC (Visible = Light Communications), IrDA, LTE-D, LP-WAN.  One of the most used = link layers for vehicular networks is IEEE 802.11-OCB, as a basis for = DSRC.  However, IPv6 on 802.11-OCB is not yet = defined.

Fygs – This paragraph brings in a vast array = of questions related to the actual scope of the group developing = “IP-based protocols to establish connectivity” between = entities in motion and/or stationary. It is not the intention here to = open a philosophical discussion of the various entities that may or may = not be in scope, but merely to point out the need for precise = definitions of entities involved in the “connectivity”. = Follow are few question examples which comes to mind (no particular = order):

·         = Does = the entities in motion are related to vehicles = only?

·         = Does = living entities and/or “things” in motion capable of = establishing IP connectivity are = excluded?

o   One can argue that a conveyor belt is a = “transportation system”.  =

·         = Which = mobile entities are excluded from the = scope?

·         = The = same type of questions can apply to stationary = systems:

o   Tethered or wireless land connectivity (i.e.; Free = Space Optics (FSO)

·         = Etc.

The list can be = extensive.

 

The group will work only = on IPv6 solutions.

The group will leverage on technologies for = Internet of Things (IoT) which are developed in other IETF and IRTF = efforts: 6lo WG, LP-WAN WG, and T2T RG.  Co-existence with = techniques of infrastructure mobility management will be coordinated = with the DMM WG, LISP WG, and other mobility solutions.

The SDOs = interested in this work are: ISO/TC204, ETSI TC ITS, 3GPP, NHTSA and = more.

This group will not work on V2V or V2I use-cases where IP = is not well-suited.  Without re-chartering, this group will not = work on Delay-Tolerant Networking nor on Information-Centric = Networking.

If the group is successful in accomplishing its first = goals, then it can be rechartered to work on other things (examples = include but are not limited to: a 1-hop mechanism of IP prefix exchange = between moving networks, an n-hop extension, naming for moving networks; = generalization for trains, air, unmanned and space = use-cases).

WORK ITEMS

1. Standards Track RFC "IPv6 = over 802.11p"

Fygs – As reference - It is believed that = the actual IEEE Std 802.11p is no longer available. This standard was = the amendment of IEEE Std 802.11-2007.  The amendment has been = incorporated in the current IEEE Std 802.11-2012.  Note that the = clause references in 802.11-2012 are not in line with = 802.11p-2010.

2. = Potential Informational RFC "ITS General Problem Area" = covering:
 - What is ITS?
    -- Explain V2V, V2I, = and related terms
 - Why is IPv6 needed?
    -- = Explain why some traffic will not use IPv6
    -- Explain = why other traffic will use IPv6
 - Use-cases, illustrating the = expected areas for initial focus
 - Informative references, = relationship with other SDOs

3. Potential Informational RFC = "Problem Statement" covering:
  - Problem = statement
  - Security considerations
  - Privacy = considerations

MILESTONES

Oct 2016 - Draft for "IPv6 = over 802.11-OCB" adopted by WG

Dec 2016 - Draft for = "ITS General Problem Area" adopted by WG

Mar 2017 - = Draft for "Problem Statement" adopted by WG

May 2017 - = Submit "IPv6 over 802.11-OCB" to IESG

Oct 2017 - Submit = "ITS General Problem Area" to IESG

May 2018 - Submit = "Problem Statement" to = IESG

------=_NextPart_000_0001_01D1FA34.02B86F60-- From nobody Mon Aug 22 06:49:56 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 6CCA012D528 for ; Mon, 22 Aug 2016 06:49:55 -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 UGdMXGjH3yhU for ; Mon, 22 Aug 2016 06:49:53 -0700 (PDT) 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 0A4CA12D51F for ; Mon, 22 Aug 2016 06:49:52 -0700 (PDT) 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 u7MDnnGm017257; Mon, 22 Aug 2016 15:49:49 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7AAD62060F5; Mon, 22 Aug 2016 15:49:57 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 698D6206034; Mon, 22 Aug 2016 15:49:57 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u7MDnnXw019555; Mon, 22 Aug 2016 15:49:49 +0200 To: sarikaya@ieee.org, =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> From: Alexandre Petrescu Message-ID: <2b7884f0-27f0-42e6-bbd9-a172e2b0d849@gmail.com> Date: Mon, 22 Aug 2016 15:49:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Tony Li , its@ietf.org Subject: Re: [its] Charter comments 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, 22 Aug 2016 13:49:55 -0000 Le 15/08/2016 à 20:13, Behcet Sarikaya a écrit : > I don't think V2V should be an IETF issue. I dont know what you mean more precisely by "V2V"? Two vehicles exchanging IP datagrams - via more or less infrastructure - is obviously an IETF issue. Some deployed applications already do so (coyote and others). > Regarding V2I, if you don't like it, propose another name. I dont know what you mean more precisely by V2I either. V2I like in Mobile IP would not need development in other than existing WGs. V2I like in a Road-Side Unit broadcasting Points of Interest is not V2Internet (Mobile IP), yet it may use same IP datagrams as in V2V. For these reasons, I believe V2I, V2V and V2Internet are hard to distinguish, and as such it's hard to propose another name. Alex > > Behcet > > On Mon, Aug 15, 2016 at 12:22 PM, Jérôme Härri > wrote: >> Dear All, >> >> From a pure L2 link, we should not make a major difference if >> vehicles are communicating V2V or V2I (beside the enhanced range >> available by RSUs)..a node is a node indeed. But from an IPv6 >> architecture, this will make a difference, as the RSU may be >> connected to the IPv6 backbone and as such have additional >> properties (prefix, gateway etc..). >> >> It is yet also not as simple to say that when two vehicles are in >> range that the communicate...of course they will (at least try), >> but there will be different aspects to consider. For example, if >> the vehicle is 'involved in traffic' and/or his 'engine is on/key >> in the ignition', then it will need to transmit CAM/BSM. So, the >> IPv6 will need to 'co-exist' with non IP higher priority traffic >> (and operate in different channels for instance). But when the car >> is not involved in traffic, engine and key off, then IPv6 might use >> the full spectrum of the ITS-G5 radio (no 1609.4 channel switching >> for instance..) >> >> My two cents, >> >> Cheers, >> >> Jérôme >> >> -----Original Message----- From: its [mailto:its-bounces@ietf.org] >> On Behalf Of Tony Li Sent: Monday 15 August 2016 18:58 To: >> sarikaya@ieee.org Cc: Alexandre Petrescu; its@ietf.org Subject: Re: >> [its] Charter comments >> >> >>> On Aug 15, 2016, at 9:31 AM, Behcet Sarikaya >>> wrote: >>> >>>> If on the other hand one considers that two directly connected >>>> vehicles form already a small island of a small Internet, then >>>> a 3rd vehicle connecting to this island _could_ be called V2I. >>>> >>> Yes but no infrastructural nodes are involved? >> >> >> Hi there, >> >> Sorry I’m late to the discussion, but I’m missing out on the >> architectural difference here. >> >> What does it matter if a node is a vehicle or infra? What do you >> consider a vehicle that’s parked? >> >> Seems to me that a node is a node is a node… If they are in range >> of each other, then they chat. >> >> Tony >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> > From nobody Mon Aug 22 06:51: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 BB2AC12D529 for ; Mon, 22 Aug 2016 06:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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 a_4DhzkRv-Ln for ; Mon, 22 Aug 2016 06:51:37 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 405B412D50A for ; Mon, 22 Aug 2016 06:51:37 -0700 (PDT) Received: by mail-pa0-x233.google.com with SMTP id pp5so37925456pac.3 for ; Mon, 22 Aug 2016 06:51:37 -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 :content-transfer-encoding:message-id:references:to; bh=m7XV7gOb7wcSkkFP/Y23yX1qk00waqhBDMIWztKxMLI=; b=tndNYansRxKZHdeK6aO+Gx0ZyHv3q7B7gQZkDcsqEqcVZaOZYr1ZC8UjC5d1fs6+VJ cCkZ8yNTmbkXyW523AStLZ6efAHnUqOJTAtvYqGz2vcqbbYcBEi1En+QIOAXkfqKhI1k 0vkWl2SmNAaH9KWdzmn80B+v2bJOjL8FRG/WuJl+XqJ/byjPIYqXkyXhWdo7zh9dhhuU LXIxog3cgFP7LYKs5ikOZd+Qzg+0cz8QjUiWOLbwVLjAzlsq9CKF7o/q6YWilG2LMpZ9 /n9HXHVk4hwXks4Z0WrvzGlrYDnnZPQtU8tN8m2HQjTm815aZd8DCEMeKB73/BzN7TUj WHgw== 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 :content-transfer-encoding:message-id:references:to; bh=m7XV7gOb7wcSkkFP/Y23yX1qk00waqhBDMIWztKxMLI=; b=P4L1Q7zSFerwfnXrptK8mYSPGyf8irZpMBbLV5Ii7pcPKlgN5pp3yLHaFjyP8f4sWd 3RaAWQF4KJ+10441GmLFpbW7UNzxC1jLOqVWtq1k8czbhb4un0dqudNM7uRjlstrn1Ba Ug6Mz08F9pIQbAaqTgDEgGrPJGihfZjlvf+s1eB6erPIzf+6JXAzzoEvJXQDuI88NKwZ niV2lAwcbYzaZof05MQRBN3hXyMaVfOH4Dwmv5mYUDRqzloHCMHc7izgn+YNzan7F+0i I2e6nMdrQVb/Nnx8fToYr4zWHJOZLzjNAQfMOxnzud6jcqRpnKSo6rnmJU3elKraVsvS Zy0w== X-Gm-Message-State: AEkoouvUOIX4un0V1NoKG8hV6bzx16A4CqzFX4A6T2F5bpLlbnwvYwJcwx9VbKmy/IWyyQ== X-Received: by 10.66.21.167 with SMTP id w7mr42631714pae.62.1471873896732; Mon, 22 Aug 2016 06:51:36 -0700 (PDT) Received: from [10.45.1.82] ([156.39.10.45]) by smtp.gmail.com with ESMTPSA id z187sm27584685pfz.39.2016.08.22.06.51.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 22 Aug 2016 06:51:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: <2b7884f0-27f0-42e6-bbd9-a172e2b0d849@gmail.com> Date: Mon, 22 Aug 2016 06:51:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <95E1F7FA-A798-4189-945B-DC42F15705B4@gmail.com> References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <2b7884f0-27f0-42e6-bbd9-a172e2b0d849@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sarikaya@ieee.org, Tony Li , =?utf-8?Q?J=C3=A9r=C3=B4me_H=C3=A4rri?= , its@ietf.org Subject: Re: [its] Charter comments 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, 22 Aug 2016 13:51:39 -0000 > V2I like in a Road-Side Unit broadcasting Points of Interest is not > V2Internet (Mobile IP), yet it may use same IP datagrams as in V2V. But I would argue an RSU would be a perfect place as a default router = for hosts (vehicles) to point to. Dino From nobody Mon Aug 22 06:54: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 DA66412D528 for ; Mon, 22 Aug 2016 06:54:53 -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 SNn5SltgsijX for ; Mon, 22 Aug 2016 06:54:52 -0700 (PDT) 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 66AC312D544 for ; Mon, 22 Aug 2016 06:54:52 -0700 (PDT) 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 u7MDsoKG019740; Mon, 22 Aug 2016 15:54:50 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CF78120618D; Mon, 22 Aug 2016 15:54:57 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B23C6202111; Mon, 22 Aug 2016 15:54:57 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u7MDsnp8023107; Mon, 22 Aug 2016 15:54:49 +0200 To: Dino Farinacci References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <2b7884f0-27f0-42e6-bbd9-a172e2b0d849@gmail.com> <95E1F7FA-A798-4189-945B-DC42F15705B4@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 22 Aug 2016 15:54:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <95E1F7FA-A798-4189-945B-DC42F15705B4@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: sarikaya@ieee.org, Tony Li , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , its@ietf.org Subject: Re: [its] Charter comments 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, 22 Aug 2016 13:54:54 -0000 Le 22/08/2016 à 15:51, Dino Farinacci a écrit : >> V2I like in a Road-Side Unit broadcasting Points of Interest is not >> V2Internet (Mobile IP), yet it may use same IP datagrams as in V2V. > > But I would argue an RSU would be a perfect place as a default router for hosts (vehicles) to point to. Certainly, as long as the RSU is connected to Internet and is ready to act as a default router. Alex > > Dino > > From nobody Mon Aug 22 06:57:06 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 979B712D1E6; Mon, 22 Aug 2016 06:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.069 X-Spam-Level: X-Spam-Status: No, score=-115.069 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.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 s3zDBeuC_dr7; Mon, 22 Aug 2016 06:56:33 -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 AD4BB12D51F; Mon, 22 Aug 2016 06:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=958; q=dns/txt; s=iport; t=1471874192; x=1473083792; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3LTy4Ir59ztejpblzbjMjpRCAalFL4Esxr+moWOgmbQ=; b=AZo1aP2lbZjM0tDdbeziTZgn4l44Q4pHVew1Fydpt/YaI1gVNwIbN5k7 ynmA17hHUXmM75k6sAxppXs6gUZQUk0EcOvUz6QD7xSgd2FuWn06Pyzgc WESaLzbSCu0NKV2n5u/LfqEvMC7kFLkSoRLz5bzgBdpyH1vMrgwgR8A7K A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJAgBmA7tX/4wNJK1dg0RWfAe3cYF9J?= =?us-ascii?q?IV5AoFYOBQCAQEBAQEBAV4nhF4BAQQBAQE4NAsFCwIBCBgeECcLJQIEDgWIKQg?= =?us-ascii?q?OvWYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYgjglWEQIMsgi8BBJlIAYYfiH+Bb?= =?us-ascii?q?YRciQeMP4N3AR42g3pwhXx/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,560,1464652800"; d="scan'208";a="313810702" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Aug 2016 13:56:31 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u7MDuVQD008690 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Aug 2016 13:56:31 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 22 Aug 2016 09:56:31 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Mon, 22 Aug 2016 09:56:30 -0400 From: "Cullen Jennings (fluffy)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] AD sponsoring draft-kivinen-802-15-ie-02 Thread-Index: AQHR/Hz8uU6nvhEdjUynKyRH6PCdkg== Date: Mon, 22 Aug 2016 13:56:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.249.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <1F98B1F7A79ACA49A1E09B1D61F421DC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Internet Area , "its@ietf.org" , "iot-dir@ietf.org" , "lpwan@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [its] [Roll] AD sponsoring draft-kivinen-802-15-ie-02 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, 22 Aug 2016 13:56:35 -0000 Seems like the draft needs some more on how the IETF will allocate the subt= ype.=20 > On Jul 18, 2016, at 6:39 AM, Suresh Krishnan wrote: >=20 > Hi all, > I am considering AD sponsoring the following draft >=20 > https://tools.ietf.org/html/draft-kivinen-802-15-ie-02 >=20 > to request the allocation of an 802.15.4 information element from the IEE= E=20 > for use in the IETF protocols that may need it. If you have any concerns= =20 > either with the content of the draft or about requesting the IE at all pl= ease=20 > let me know before 2016/07/29. >=20 > Thanks > Suresh >=20 > NOTE: I have CCed: all the groups that I thought could be potentially=20 > interested in this work. If you think I have missed out some WG(s) please= let=20 > me know. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Mon Aug 22 06:57: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 3F0F312D559 for ; Mon, 22 Aug 2016 06:57:44 -0700 (PDT) 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 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 ctJusl_cjj8Y for ; Mon, 22 Aug 2016 06:57:43 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::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 E063012D54D for ; Mon, 22 Aug 2016 06:57:42 -0700 (PDT) Received: by mail-pa0-x229.google.com with SMTP id fi15so38050527pac.1 for ; Mon, 22 Aug 2016 06:57:42 -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 :content-transfer-encoding:message-id:references:to; bh=FYeUE2f3rh/FdvNvuod5wmVHM4PRVVMBNC3mQtqe5hg=; b=EtZn+dN204pO/ZQvRGU2nZd8f9H33/SHuU1zIE22sf+eWBf6bJXRtV43GViXHv6bIP 3PsLZmFQSwhHTM8UZPWecz2RBcIHLqf++CbspQabnJThqbDrd85ef8YUsdFOb9CcK/L8 p3Cd8sT6LcMobR06UrHx9Ll6lYln5mNuf1FolZiX6BYdEjcqif/T/V/ChgLFwzNYM90I SbKJYIA7EJtCkoMpzWLV91ZNkP5vwscxsizUjoFjhD97OuxzKYe7OuWmwVSkEuMJgh5n ex4khe2zLjWIWQsNPOHAMrzjgQ2NLanT56yIEGEUsdNx6/GK6kReVCzYvxV59TBnWAhv hHMA== 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 :content-transfer-encoding:message-id:references:to; bh=FYeUE2f3rh/FdvNvuod5wmVHM4PRVVMBNC3mQtqe5hg=; b=VUE9V5vEocD7FQxOvMJHbHg4OgYmG3naQU8hFJ1MFuex0qpjA0qArU9eXGmuo267Os IVmL/XIUMxiWg//w/2eH2mERF5ooSQcaxJesXTyI4bB9lOEnUu5bhJqZ0ys/qDBkgk1K Kg57bezC0QDmeUe+1CgkU5CxzKjI6PeAhnFaC8DOhBgAAZpqpS6VtDFKY6FH3oF40Nh/ 19mU8VWu+M+CFwPIu4y0aKk7OzOrzWBjLa/rRJ5WjhF8viLITiQQngtqLdbD6v2JRhNU pNaJR+b+B1i6WV8rU2t6IC9r13e120hktdLqcnmWG3M7+6WWpmOqkIxWuUZZzx/sxwP1 6wCA== X-Gm-Message-State: AEkoouuJw1fcxsKwG0UWZuIF4brQApc5Vag5deHfm65QqWsy+ane5GOQajawi0kLtcHnVA== X-Received: by 10.66.221.229 with SMTP id qh5mr42176467pac.66.1471874262422; Mon, 22 Aug 2016 06:57:42 -0700 (PDT) Received: from [10.45.1.82] ([156.39.10.45]) by smtp.gmail.com with ESMTPSA id a5sm27563907pfc.89.2016.08.22.06.57.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 22 Aug 2016 06:57:41 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: Date: Mon, 22 Aug 2016 06:57:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9C481EA4-6E1D-4558-BFD6-948F5728B86D@gmail.com> References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <2b7884f0-27f0-42e6-bbd9-a172e2b0d849@gmail.com> <95E1F7FA-A798-4189-945B-DC42F15705B4@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sarikaya@ieee.org, Tony Li , =?windows-1252?Q?J=E9r=F4me_H=E4rri?= , its@ietf.org Subject: Re: [its] Charter comments 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, 22 Aug 2016 13:57:44 -0000 By definition a default router, traditionally has good connectivity to = Internet infrastructure. Dino > On Aug 22, 2016, at 6:54 AM, Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 22/08/2016 =E0 15:51, Dino Farinacci a =E9crit : >>> V2I like in a Road-Side Unit broadcasting Points of Interest is not >>> V2Internet (Mobile IP), yet it may use same IP datagrams as in V2V. >>=20 >> But I would argue an RSU would be a perfect place as a default router = for hosts (vehicles) to point to. >=20 > Certainly, as long as the RSU is connected to Internet and is ready to = act as a default router. >=20 > Alex >=20 >>=20 >> Dino >>=20 >>=20 From nobody Mon Aug 22 07:39: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 5910B12D5FD for ; Mon, 22 Aug 2016 07:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] 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 SUKJRmsfL5oI for ; Mon, 22 Aug 2016 07:38:57 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id 61F8912D614 for ; Mon, 22 Aug 2016 07:38:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,560,1464645600"; d="scan'208";a="4498527" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 22 Aug 2016 16:38:55 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 0FC8DB5F; Mon, 22 Aug 2016 16:38:55 +0200 (CEST) From: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" , References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <2b7884f0-27f0-42e6-bbd9-a172e2b0d849@gmail.com> In-Reply-To: <2b7884f0-27f0-42e6-bbd9-a172e2b0d849@gmail.com> Date: Mon, 22 Aug 2016 16:38:54 +0200 Organization: EURECOM Message-ID: <02a301d1fc82$e8b6d7e0$ba2487a0$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLnYvWbuj0Jb9+O5N4XnF9Mh3Dn+wIyijYuAdVBt/YCIplQUQFlklk6AnsJe3QB81lWSZ3KRutw Content-Language: en-us Archived-At: Cc: 'Tony Li' , its@ietf.org Subject: Re: [its] Charter comments 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, 22 Aug 2016 14:38:59 -0000 Gentlemen, When we use V2I or V2V (in the charter as well as in major = publications), this is not to imply any technical detail, but rather to = describe communication patterns: horizontal or vertical. The rest is = just subject to interpretations, which sometimes are not accurate. Just = as V2I does not strongly imply IPv6, V2V does not strongly reject = IPv6... A RSU is an ITS-S in the ETSI/ISO denomination. It may or may not be = static, and may or may not be equipped with a IPv6 Mobile Router. That = should be sufficient to differentiate the 'technical' differences of = V2I... =20 In the charter, V2V and V2I are considered in a general (and simple) = sense: horizontal (direct) vs, indirect (over an = "infrastructure"....whatever it means)...I do not think we need to = change that...but in one of our IDs, we could clarify this in technical = terms. Such taxonomy could help, even beyond the IETF community I would = guess... Best Regards, J=C3=A9r=C3=B4me -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Sent: Monday 22 August 2016 15:50 To: sarikaya@ieee.org; J=C3=A9r=C3=B4me H=C3=A4rri Cc: Tony Li; its@ietf.org Subject: Re: [its] Charter comments Le 15/08/2016 =C3=A0 20:13, Behcet Sarikaya a =C3=A9crit : > I don't think V2V should be an IETF issue. I dont know what you mean more precisely by "V2V"? Two vehicles exchanging IP datagrams - via more or less infrastructure - = is obviously an IETF issue. Some deployed applications already do so (coyote and others). > Regarding V2I, if you don't like it, propose another name. I dont know what you mean more precisely by V2I either. V2I like in Mobile IP would not need development in other than existing = WGs. V2I like in a Road-Side Unit broadcasting Points of Interest is not = V2Internet (Mobile IP), yet it may use same IP datagrams as in V2V. For these reasons, I believe V2I, V2V and V2Internet are hard to = distinguish, and as such it's hard to propose another name. Alex > > Behcet > > On Mon, Aug 15, 2016 at 12:22 PM, J=C3=A9r=C3=B4me H=C3=A4rri=20 > wrote: >> Dear All, >> >> From a pure L2 link, we should not make a major difference if=20 >> vehicles are communicating V2V or V2I (beside the enhanced range=20 >> available by RSUs)..a node is a node indeed. But from an IPv6=20 >> architecture, this will make a difference, as the RSU may be=20 >> connected to the IPv6 backbone and as such have additional properties = >> (prefix, gateway etc..). >> >> It is yet also not as simple to say that when two vehicles are in=20 >> range that the communicate...of course they will (at least try), but=20 >> there will be different aspects to consider. For example, if the=20 >> vehicle is 'involved in traffic' and/or his 'engine is on/key in the=20 >> ignition', then it will need to transmit CAM/BSM. So, the >> IPv6 will need to 'co-exist' with non IP higher priority traffic (and = >> operate in different channels for instance). But when the car is not=20 >> involved in traffic, engine and key off, then IPv6 might use the full = >> spectrum of the ITS-G5 radio (no 1609.4 channel switching for=20 >> instance..) >> >> My two cents, >> >> Cheers, >> >> J=C3=A9r=C3=B4me >> >> -----Original Message----- From: its [mailto:its-bounces@ietf.org] On = >> Behalf Of Tony Li Sent: Monday 15 August 2016 18:58 To: >> sarikaya@ieee.org Cc: Alexandre Petrescu; its@ietf.org Subject: Re: >> [its] Charter comments >> >> >>> On Aug 15, 2016, at 9:31 AM, Behcet Sarikaya=20 >>> wrote: >>> >>>> If on the other hand one considers that two directly connected=20 >>>> vehicles form already a small island of a small Internet, then a=20 >>>> 3rd vehicle connecting to this island _could_ be called V2I. >>>> >>> Yes but no infrastructural nodes are involved? >> >> >> Hi there, >> >> Sorry I=E2=80=99m late to the discussion, but I=E2=80=99m missing out = on the=20 >> architectural difference here. >> >> What does it matter if a node is a vehicle or infra? What do you=20 >> consider a vehicle that=E2=80=99s parked? >> >> Seems to me that a node is a node is a node=E2=80=A6 If they are in = range of=20 >> each other, then they chat. >> >> Tony >> >> _______________________________________________ its mailing list=20 >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> > From nobody Mon Aug 22 07:40:59 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 6811812D5FD for ; Mon, 22 Aug 2016 07:40:57 -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 KxisX13KVauJ for ; Mon, 22 Aug 2016 07:40:56 -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 01D8612D5CF for ; Mon, 22 Aug 2016 07:40:51 -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 u7MEem36023378; Mon, 22 Aug 2016 16:40:48 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8D1272060E9; Mon, 22 Aug 2016 16:40:56 +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 7A1E12060E5; Mon, 22 Aug 2016 16:40:56 +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 u7MEemwF022277; Mon, 22 Aug 2016 16:40:48 +0200 To: Dino Farinacci References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <2b7884f0-27f0-42e6-bbd9-a172e2b0d849@gmail.com> <95E1F7FA-A798-4189-945B-DC42F15705B4@gmail.com> <9C481EA4-6E1D-4558-BFD6-948F5728B86D@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 22 Aug 2016 16:40:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <9C481EA4-6E1D-4558-BFD6-948F5728B86D@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: sarikaya@ieee.org, Tony Li , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , its@ietf.org Subject: Re: [its] Charter comments 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, 22 Aug 2016 14:40:57 -0000 Le 22/08/2016 à 15:57, Dino Farinacci a écrit : > By definition a default router, traditionally has good connectivity > to Internet infrastructure. And that is a difference with many deployed RSUs. Many deployed RSUs are disconnected from the Internet - there is simply no Internet arriving to them. Many RSUs which _are_ connected to the Internet have strong barriers between the interface connected to the Internet and the interface to the vehicles. The interface to the Internet is very necessary for remote management. But the fear of risk of forwarding between the two interfaces is very high. Moreover, some applications are bound to particular hardware, and so RSU is made of multiple boxes, which renders forwarding further complex to a trivial plan. Alex > > Dino > >> On Aug 22, 2016, at 6:54 AM, Alexandre Petrescu >> wrote: >> >> >> >> Le 22/08/2016 à 15:51, Dino Farinacci a écrit : >>>> V2I like in a Road-Side Unit broadcasting Points of Interest is >>>> not V2Internet (Mobile IP), yet it may use same IP datagrams as >>>> in V2V. >>> >>> But I would argue an RSU would be a perfect place as a default >>> router for hosts (vehicles) to point to. >> >> Certainly, as long as the RSU is connected to Internet and is ready >> to act as a default router. >> >> Alex >> >>> >>> Dino >>> >>> > > From nobody Mon Aug 22 07:41: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 581FD12D620; Mon, 22 Aug 2016 07:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 xfgn2nKqsjiK; Mon, 22 Aug 2016 07:41:42 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A85E12D625; Mon, 22 Aug 2016 07:41:41 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u7MEfb6b029182 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Aug 2016 17:41:37 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u7MEfbeI007431; Mon, 22 Aug 2016 17:41:37 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22459.3873.433750.928934@fireball.acr.fi> Date: Mon, 22 Aug 2016 17:41:37 +0300 From: Tero Kivinen To: "Cullen Jennings \(fluffy\)" In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 7 min Archived-At: Cc: Internet Area , "its@ietf.org" , Routing Over Low power and Lossy networks , "iot-dir@ietf.org" , "lpwan@ietf.org" , "core@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org> Subject: Re: [its] [6tisch] [Roll] AD sponsoring draft-kivinen-802-15-ie-02 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, 22 Aug 2016 14:41:44 -0000 Cullen Jennings (fluffy) writes: > Seems like the draft needs some more on how the IETF will allocate > the subtype. If you mean how IETF will get the subtype from the IEEE, then after we have this document approved, we make an request to the IEEE refering to this document, and IEEE 802.15 Assigned Numbers Authority will then follow their own procedures to do the allocation: http://www.ieee802.org/15/ANA.html I think first we just need to specify how we are going to do the subtyping (or at least have belivable plan for it) before we can start the process. What kind of text you think we should add to this document? -- kivinen@iki.fi From nobody Mon Aug 22 07:42:15 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 D7A7112D63F for ; Mon, 22 Aug 2016 07:41:55 -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 vofxXrzhH-c8 for ; Mon, 22 Aug 2016 07:41: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 7086412D660 for ; Mon, 22 Aug 2016 07:41: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 u7MEfme7009163; Mon, 22 Aug 2016 16:41:48 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B27F72060E5; Mon, 22 Aug 2016 16:41:55 +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 A4E86206249; Mon, 22 Aug 2016 16:41:55 +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 u7MEflKk022937; Mon, 22 Aug 2016 16:41:47 +0200 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , sarikaya@ieee.org References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <2b7884f0-27f0-42e6-bbd9-a172e2b0d849@gmail.com> <02a301d1fc82$e8b6d7e0$ba2487a0$@eurecom.fr> From: Alexandre Petrescu Message-ID: <3fb1efcf-c643-894f-f062-9e3dffe47089@gmail.com> Date: Mon, 22 Aug 2016 16:41:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <02a301d1fc82$e8b6d7e0$ba2487a0$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 'Tony Li' , its@ietf.org Subject: Re: [its] Charter comments 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, 22 Aug 2016 14:41:57 -0000 Le 22/08/2016 à 16:38, Jérôme Härri a écrit : > Gentlemen, > > When we use V2I or V2V (in the charter as well as in major > publications), this is not to imply any technical detail, but rather > to describe communication patterns: horizontal or vertical. The rest > is just subject to interpretations, which sometimes are not accurate. > Just as V2I does not strongly imply IPv6, V2V does not strongly > reject IPv6... > > A RSU is an ITS-S in the ETSI/ISO denomination. It may or may not be > static, and may or may not be equipped with a IPv6 Mobile Router. > That should be sufficient to differentiate the 'technical' > differences of V2I... > > In the charter, V2V and V2I are considered in a general (and simple) > sense: horizontal (direct) vs, indirect (over an > "infrastructure"....whatever it means)...I do not think we need to > change that...but in one of our IDs, we could clarify this in > technical terms. Such taxonomy could help, even beyond the IETF > community I would guess... I agree. It sounds like a good idea. Alex > > Best Regards, > > Jérôme > > -----Original Message----- From: Alexandre Petrescu > [mailto:alexandre.petrescu@gmail.com] Sent: Monday 22 August 2016 > 15:50 To: sarikaya@ieee.org; Jérôme Härri Cc: Tony Li; its@ietf.org > Subject: Re: [its] Charter comments > > > > Le 15/08/2016 à 20:13, Behcet Sarikaya a écrit : >> I don't think V2V should be an IETF issue. > > I dont know what you mean more precisely by "V2V"? > > Two vehicles exchanging IP datagrams - via more or less > infrastructure - is obviously an IETF issue. > > Some deployed applications already do so (coyote and others). > >> Regarding V2I, if you don't like it, propose another name. > > I dont know what you mean more precisely by V2I either. > > V2I like in Mobile IP would not need development in other than > existing WGs. > > V2I like in a Road-Side Unit broadcasting Points of Interest is not > V2Internet (Mobile IP), yet it may use same IP datagrams as in V2V. > > For these reasons, I believe V2I, V2V and V2Internet are hard to > distinguish, and as such it's hard to propose another name. > > Alex > >> >> Behcet >> >> On Mon, Aug 15, 2016 at 12:22 PM, Jérôme Härri >> wrote: >>> Dear All, >>> >>> From a pure L2 link, we should not make a major difference if >>> vehicles are communicating V2V or V2I (beside the enhanced range >>> available by RSUs)..a node is a node indeed. But from an IPv6 >>> architecture, this will make a difference, as the RSU may be >>> connected to the IPv6 backbone and as such have additional >>> properties (prefix, gateway etc..). >>> >>> It is yet also not as simple to say that when two vehicles are in >>> range that the communicate...of course they will (at least try), >>> but there will be different aspects to consider. For example, if >>> the vehicle is 'involved in traffic' and/or his 'engine is on/key >>> in the ignition', then it will need to transmit CAM/BSM. So, the >>> IPv6 will need to 'co-exist' with non IP higher priority traffic >>> (and operate in different channels for instance). But when the >>> car is not involved in traffic, engine and key off, then IPv6 >>> might use the full spectrum of the ITS-G5 radio (no 1609.4 >>> channel switching for instance..) >>> >>> My two cents, >>> >>> Cheers, >>> >>> Jérôme >>> >>> -----Original Message----- From: its >>> [mailto:its-bounces@ietf.org] On Behalf Of Tony Li Sent: Monday >>> 15 August 2016 18:58 To: sarikaya@ieee.org Cc: Alexandre >>> Petrescu; its@ietf.org Subject: Re: [its] Charter comments >>> >>> >>>> On Aug 15, 2016, at 9:31 AM, Behcet Sarikaya >>>> wrote: >>>> >>>>> If on the other hand one considers that two directly >>>>> connected vehicles form already a small island of a small >>>>> Internet, then a 3rd vehicle connecting to this island >>>>> _could_ be called V2I. >>>>> >>>> Yes but no infrastructural nodes are involved? >>> >>> >>> Hi there, >>> >>> Sorry I’m late to the discussion, but I’m missing out on the >>> architectural difference here. >>> >>> What does it matter if a node is a vehicle or infra? What do you >>> consider a vehicle that’s parked? >>> >>> Seems to me that a node is a node is a node… If they are in >>> range of each other, then they chat. >>> >>> Tony >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >> > > From nobody Mon Aug 22 07:48:28 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 164A112D66A for ; Mon, 22 Aug 2016 07:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, MIME_QP_LONG_LINE=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 JB-7H_EZYQR7 for ; Mon, 22 Aug 2016 07:48:26 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFBBB12D67F for ; Mon, 22 Aug 2016 07:48:25 -0700 (PDT) Received: by mail-pa0-x22c.google.com with SMTP id ti13so38389790pac.0 for ; Mon, 22 Aug 2016 07:48:25 -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 :content-transfer-encoding:message-id:references:to; bh=13JnEEddmoRIEw/5FM1NhW5PAmliVu2KbNYA52HMfL4=; b=XLQrYTJlChPdoon0/kFaIEV/d1W8/JIan6Oy/y3ez7FV+zadPuwKIGpTnZThvD9RKl bFsFZmxpWTHjDd1xMoyz9sWvS2y+fZIIO8z1CBC0qZj0/8Wk1pd7y6RPTKYmQqwQArIo yVH6U/okr9Rdf6odZCJ99crV5H3ueOoBHDC82BKHfhrn9A6h3ZIgdz8QB6xsWkNJMYoO OZypvUaL0XnlgIcWPNyJCRdO06Ti+2fbQit2QhWqZNrV4dLAP7vsngA41BY+UbndUwVi LU2kS3nMpoR94i+tDE1Wpwnf8JD8xzaj6Qw7mEG3Wlmz3VZPlF5Q5f6qIIPVi7zz0XOQ ljvQ== 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 :content-transfer-encoding:message-id:references:to; bh=13JnEEddmoRIEw/5FM1NhW5PAmliVu2KbNYA52HMfL4=; b=gPUKFR4w+MYXIyS51//QqtNg1tdIAtS0rXHnNHp/6xaNHDhAglFuBlrVh5iddeFCju AtKNVSMrit6IgNsjwiJ2nbkOezAM6GfuaIYUKjI7d2NS0bROy4+lKmUIT1NhZizHRz9+ bPPjddxHgcjWy5ZP4rQmj4Dh+YaLOWqg2TmFqgY9M0nwQIstFjKerdnFbjOpTKCSwFu+ wt9FaJHn95sw8t48/8hxJZ5KQuyYVtOYKfNit+Ck1IY2l3JzCW6qprJZ1FwJf3fZZsLJ 5zVVYqKyHrQxHUO2qIyosO+tqQRr6SWwF39B9SDCDEoTSstildrEYIpAu16xdUNBHa81 ToNg== X-Gm-Message-State: AEkooutC9PfUf76515y1D2Dq60OmPAvjixY9SS6IJ95sl6u1r4vJASqNHgMaDxj7PCdHDQ== X-Received: by 10.66.137.107 with SMTP id qh11mr42878079pab.49.1471877304747; Mon, 22 Aug 2016 07:48:24 -0700 (PDT) Received: from [10.118.5.59] ([166.170.43.110]) by smtp.gmail.com with ESMTPSA id an11sm32927453pac.26.2016.08.22.07.48.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 22 Aug 2016 07:48:23 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-8A261FAF-F8E1-4709-9352-D7C818F0B74F Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (14A5341a) In-Reply-To: Date: Mon, 22 Aug 2016 07:48:22 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <2b7884f0-27f0-42e6-bbd9-a172e2b0d849@gmail.com> <95E1F7FA-A798-4189-945B-DC42F15705B4@gmail.com> <9C481EA4-6E1D-4558-BFD6-948F5728B86D@gmail.com> To: Alexandre Petrescu Archived-At: Cc: sarikaya@ieee.org, Tony Li , =?utf-8?Q?J=C3=A9r=C3=B4me_H=C3=A4rri?= , its@ietf.org Subject: Re: [its] Charter comments 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, 22 Aug 2016 14:48:28 -0000 --Apple-Mail-8A261FAF-F8E1-4709-9352-D7C818F0B74F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > Many RSUs which _are_ connected to the Internet have strong barriers > between the interface connected to the Internet and the interface to the > vehicles. The interface to the Internet is very necessary for remote > management. But the fear of risk of forwarding between the two > interfaces is very high. Moreover, some applications are bound to > particular hardware, and so RSU is made of multiple boxes, which renders > forwarding further complex to a trivial plan. The question is if this ship has already sailed. Today we have decent v2i by= use of our cell phones. So the host (vehicle) is the router as well.=20 Another question is if a RSU, one that is upgraded with a decent amount of b= andwidth, can serve multiple host-only vehicles. Meaning, providing *better*= mobility then the "large subnet everywhere" that cellular mobility provides= today.=20 Note the future is bound to have multiple wireless technologies. And not jus= t LTE and 5G. So mobility across providers is a necessity. This is where a s= marter, router-based, RSU will be needed.=20 Dino= --Apple-Mail-8A261FAF-F8E1-4709-9352-D7C818F0B74F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Many RSUs which _are_ conne= cted to the Internet have strong barriers
between the interface connected to the Internet and the interface to= the
vehicles.  The interface to the Internet is very n= ecessary for remote
management.  But the fear of risk o= f forwarding between the two
interfaces is very high.  = Moreover, some applications are bound to
particular hardware= , and so RSU is made of multiple boxes, which renders
forwar= ding further complex to a trivial plan.

The quest= ion is if this ship has already sailed. Today we have decent v2i by use of o= ur cell phones. So the host (vehicle) is the router as well. 

= Another question is if a RSU, one that is upgraded with a decent amount of b= andwidth, can serve multiple host-only vehicles. Meaning, providing *better*= mobility then the "large subnet everywhere" that cellular mobility provides= today. 

Note the future is bound to have multiple wireless tec= hnologies. And not just LTE and 5G. So mobility across providers is a necess= ity. This is where a smarter, router-based, RSU will be needed. 
<= div style=3D"direction: inherit;">
Dino
= --Apple-Mail-8A261FAF-F8E1-4709-9352-D7C818F0B74F-- From nobody Mon Aug 22 12:01:24 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 A79FE12D7F3 for ; Mon, 22 Aug 2016 12:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wf3DK5uwKonv for ; Mon, 22 Aug 2016 12:01:21 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 7F7D712D827 for ; Mon, 22 Aug 2016 12:00:41 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id n59so205840678uan.2 for ; Mon, 22 Aug 2016 12:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=NG8+YLDIDTJmsjJcrHnBtFkEBAh+y4beic0i5pRa32o=; b=A9onisgjjDZP/Vvqdp9sH+kSGwtCgnfdcYbaCxlk2bCTX0jRmmdgLrDiaOsRS5miZJ QxLWG+F39Id8NelAhWr9yWoQwnBmLs1fLVwCcIT6EBYVEVcdD40olxPzIIHCCcJNY/ON Y5mnVkZErIitUpaMzCEw4ujNkqklI2JM3LTqMYbO1rWwoi0Tf2viCkYVkdEsgXCLIWSE +1rvCrhPX0TAlsTsT0l3liuLq7g3fmCQDFEMpK8Dkr2XU99ZUvteHsY1EtHayoRA/jTq gjg0iPg1eH8I1eeL3MiN9GoxsmIAwk8QTn6x8XhAuWA3wlJJpaHbE4jlFjIUg5r+P+l1 5psA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=NG8+YLDIDTJmsjJcrHnBtFkEBAh+y4beic0i5pRa32o=; b=hK1+CcyYQoEEZNcdzWmLi8GaKqVF5zN60cOJPWY0hCMqG26GQ9v+Z8vQiLmm355XVN aRD/K/u8Zj2mYAfRaQ0X09hmaPiJQ4IbfZ0mCHooniSGF/FIjE/1lRBCm+Cx0ZQfoddr 8fZXuzJzykjw52Z0R4kpvo3KvAzsX+8b+OkuKR+16wN/7nKzOxZ4OYrbuMuEONxM7JtB Nkx6t/bQeEUh9zI2GDh8XjUlOc6u8jsXiAgl0MSWjLYJxk/ycOmmXcRwq//hIOZKw3l4 2hcwcmpOY3H3uqrzGIyPcCZ+YneEYc9+pC9wezdDk3q9n2LIL/uUT9PQCq/AUR75k21a xbXA== X-Gm-Message-State: AEkoouuwMPZSwLF7IXxqX3rJeDLC8Dx/dLcLAjwONPgdmufyAQ0qX17GZPk2FbhoYon9auTpjIAWPRXRm99lPQ== X-Received: by 10.176.68.226 with SMTP id n89mr11865775uan.98.1471892440637; Mon, 22 Aug 2016 12:00:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.167 with HTTP; Mon, 22 Aug 2016 12:00:39 -0700 (PDT) In-Reply-To: <2b7884f0-27f0-42e6-bbd9-a172e2b0d849@gmail.com> References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <2b7884f0-27f0-42e6-bbd9-a172e2b0d849@gmail.com> From: Behcet Sarikaya Date: Mon, 22 Aug 2016 14:00:39 -0500 Message-ID: To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Tony Li , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , its@ietf.org Subject: Re: [its] Charter comments X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 19:01:23 -0000 On Mon, Aug 22, 2016 at 8:49 AM, Alexandre Petrescu wrote: > > > Le 15/08/2016 =C3=A0 20:13, Behcet Sarikaya a =C3=A9crit : >> >> I don't think V2V should be an IETF issue. > > > I dont know what you mean more precisely by "V2V"? What is called horizontal communication. > > Two vehicles exchanging IP datagrams - via more or less infrastructure - > is obviously an IETF issue. > > Some deployed applications already do so (coyote and others). > >> Regarding V2I, if you don't like it, propose another name. > > > I dont know what you mean more precisely by V2I either. > > V2I like in Mobile IP would not need development in other than existing W= Gs. Mobility is out of scope at least in the current charter, I think. > > V2I like in a Road-Side Unit broadcasting Points of Interest is not > V2Internet (Mobile IP), yet it may use same IP datagrams as in V2V. > > For these reasons, I believe V2I, V2V and V2Internet are hard to > distinguish, and as such it's hard to propose another name. > Disagree. I saw this in your draft: Wireless Access in Vehicular Environments, it could be used with a small change like Wireless IP Access in Vehicular Environments I think this name would reflect much better the charter. Maybe in future versions you may use the great word of intelligent :-) Regards, Behcet > Alex > > >> >> Behcet >> >> On Mon, Aug 15, 2016 at 12:22 PM, J=C3=A9r=C3=B4me H=C3=A4rri >> wrote: >>> >>> Dear All, >>> >>> From a pure L2 link, we should not make a major difference if >>> vehicles are communicating V2V or V2I (beside the enhanced range >>> available by RSUs)..a node is a node indeed. But from an IPv6 >>> architecture, this will make a difference, as the RSU may be >>> connected to the IPv6 backbone and as such have additional >>> properties (prefix, gateway etc..). >>> >>> It is yet also not as simple to say that when two vehicles are in >>> range that the communicate...of course they will (at least try), >>> but there will be different aspects to consider. For example, if >>> the vehicle is 'involved in traffic' and/or his 'engine is on/key >>> in the ignition', then it will need to transmit CAM/BSM. So, the >>> IPv6 will need to 'co-exist' with non IP higher priority traffic >>> (and operate in different channels for instance). But when the car >>> is not involved in traffic, engine and key off, then IPv6 might use >>> the full spectrum of the ITS-G5 radio (no 1609.4 channel switching >>> for instance..) >>> >>> My two cents, >>> >>> Cheers, >>> >>> J=C3=A9r=C3=B4me >>> >>> -----Original Message----- From: its [mailto:its-bounces@ietf.org] >>> On Behalf Of Tony Li Sent: Monday 15 August 2016 18:58 To: >>> sarikaya@ieee.org Cc: Alexandre Petrescu; its@ietf.org Subject: Re: >>> [its] Charter comments >>> >>> >>>> On Aug 15, 2016, at 9:31 AM, Behcet Sarikaya >>>> wrote: >>>> >>>>> If on the other hand one considers that two directly connected >>>>> vehicles form already a small island of a small Internet, then >>>>> a 3rd vehicle connecting to this island _could_ be called V2I. >>>>> >>>> Yes but no infrastructural nodes are involved? >>> >>> >>> >>> Hi there, >>> >>> Sorry I=E2=80=99m late to the discussion, but I=E2=80=99m missing out o= n the >>> architectural difference here. >>> >>> What does it matter if a node is a vehicle or infra? What do you >>> consider a vehicle that=E2=80=99s parked? >>> >>> Seems to me that a node is a node is a node=E2=80=A6 If they are in ra= nge >>> of each other, then they chat. >>> >>> Tony >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >> > From nobody Tue Aug 23 02:19: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 328EE12B00B for ; Tue, 23 Aug 2016 02:19:26 -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 tQdWcH8pEyqb for ; Tue, 23 Aug 2016 02:19:24 -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 AC2E312D8D5 for ; Tue, 23 Aug 2016 02:19:23 -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 u7N9JLkm027412 for ; Tue, 23 Aug 2016 11:19:21 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2D70B2068A1 for ; Tue, 23 Aug 2016 11:19:30 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1EDCE200C36 for ; Tue, 23 Aug 2016 11:19:30 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u7N9JKFJ023990 for ; Tue, 23 Aug 2016 11:19:21 +0200 To: its@ietf.org References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <2b7884f0-27f0-42e6-bbd9-a172e2b0d849@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 23 Aug 2016 11:19:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <2b7884f0-27f0-42e6-bbd9-a172e2b0d849@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] Charter comments 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, 23 Aug 2016 09:19:26 -0000 Behcet, I want to clarify that this message was addressed to you, and inform the list as well. I want to clarify that V2V, V2I are terms used differently in different contexts. The frequent misinterpretations make that it's difficult to base a name of the group on one of these terms (I cant respond to your invitation to propose another name based on these terms). Also, if you look at the proposed work items: > 1. Standards Track RFC "IPv6 over 802.11p" > > 2. Potential Informational RFC "ITS General Problem Area" covering: - > What is ITS? -- Explain V2V, V2I, and related terms - Why is IPv6 > needed? -- Explain why some traffic will not use IPv6 -- Explain why > other traffic will use IPv6 - Use-cases, illustrating the expected > areas for initial focus - Informative references, relationship with > other SDOs > > 3. Potential Informational RFC "Problem Statement" covering: - > Problem statement - Security considerations - Privacy considerations you will see that the name ITS can be right: The item 'IPv6 over 802.11p' can be used as much in a V2V, V2I or V2Internet settings; just like IPv6-over-Ethernet is used on datacenters, or on home office, while that group is called '6man' and not 'datacenter'. The informational items describe 'ITS General Problem Area' and 'Problem Statement' which apply in vehicle communications. As such 'ITS' is again a good name. Besides, there are multiple relationships with non-IETF groups which bear the 'ITS' name ('ITS' at US DOT, ETSI TC 'ITS', ISO TC204 'ITS' and more). For the word 'intelligent': I could agree that claiming intelligence may seem too self-important, if not outright pompous. But at the same time, one could read this as a modern capability, which evolved from 'analog' communications to 'digital' and now to 'intelligent'. Alex Le 22/08/2016 à 15:49, Alexandre Petrescu a écrit : > > > Le 15/08/2016 à 20:13, Behcet Sarikaya a écrit : >> I don't think V2V should be an IETF issue. > > I dont know what you mean more precisely by "V2V"? > > Two vehicles exchanging IP datagrams - via more or less > infrastructure - is obviously an IETF issue. > > Some deployed applications already do so (coyote and others). > >> Regarding V2I, if you don't like it, propose another name. > > I dont know what you mean more precisely by V2I either. > > V2I like in Mobile IP would not need development in other than > existing WGs. > > V2I like in a Road-Side Unit broadcasting Points of Interest is not > V2Internet (Mobile IP), yet it may use same IP datagrams as in V2V. > > For these reasons, I believe V2I, V2V and V2Internet are hard to > distinguish, and as such it's hard to propose another name. > > Alex > >> >> Behcet >> >> On Mon, Aug 15, 2016 at 12:22 PM, Jérôme Härri >> wrote: >>> Dear All, >>> >>> From a pure L2 link, we should not make a major difference if >>> vehicles are communicating V2V or V2I (beside the enhanced range >>> available by RSUs)..a node is a node indeed. But from an IPv6 >>> architecture, this will make a difference, as the RSU may be >>> connected to the IPv6 backbone and as such have additional >>> properties (prefix, gateway etc..). >>> >>> It is yet also not as simple to say that when two vehicles are >>> in range that the communicate...of course they will (at least >>> try), but there will be different aspects to consider. For >>> example, if the vehicle is 'involved in traffic' and/or his >>> 'engine is on/key in the ignition', then it will need to transmit >>> CAM/BSM. So, the IPv6 will need to 'co-exist' with non IP higher >>> priority traffic (and operate in different channels for >>> instance). But when the car is not involved in traffic, engine >>> and key off, then IPv6 might use the full spectrum of the ITS-G5 >>> radio (no 1609.4 channel switching for instance..) >>> >>> My two cents, >>> >>> Cheers, >>> >>> Jérôme >>> >>> -----Original Message----- From: its >>> [mailto:its-bounces@ietf.org] On Behalf Of Tony Li Sent: Monday >>> 15 August 2016 18:58 To: sarikaya@ieee.org Cc: Alexandre >>> Petrescu; its@ietf.org Subject: Re: [its] Charter comments >>> >>> >>>> On Aug 15, 2016, at 9:31 AM, Behcet Sarikaya >>>> wrote: >>>> >>>>> If on the other hand one considers that two directly >>>>> connected vehicles form already a small island of a small >>>>> Internet, then a 3rd vehicle connecting to this island >>>>> _could_ be called V2I. >>>>> >>>> Yes but no infrastructural nodes are involved? >>> >>> >>> Hi there, >>> >>> Sorry I’m late to the discussion, but I’m missing out on the >>> architectural difference here. >>> >>> What does it matter if a node is a vehicle or infra? What do you >>> consider a vehicle that’s parked? >>> >>> Seems to me that a node is a node is a node… If they are in >>> range of each other, then they chat. >>> >>> Tony >>> >>> _______________________________________________ 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 Aug 23 07:20:23 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 E800F12DA7D for ; Tue, 23 Aug 2016 07:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QN8H-hMISJDX for ; Tue, 23 Aug 2016 07:20:17 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 CD25712D122 for ; Tue, 23 Aug 2016 07:14:31 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id z190so107571867qkc.0 for ; Tue, 23 Aug 2016 07:14:31 -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=PnIskzplxikmQ1lfPoAoP7lnjHfuAt9GIjfXAO/hwVI=; b=SRmrHRZuxGFUph/uAXICF/jPj/KSe/roUjWTINUtQLo3Y8YnuIP54RwmS8jxv9L7WK q7sAZJWYgGg9F+Lh+yHonbBvuaHpJeG56Wb4kfP+1A0k2GOsXVMt9NCNxmhy9BVR7qeX lIdBw5i7fWeVkA0AnzlHE8zCtq/Lemwsa3MAV/ir4OmthGtZuCtDvx8BaIC4aQ5Y8hTZ CrYG6OmAt8ffBBQl9CsDNBhe98b3ODub7CKPr3nyPSsNCpgESSOpo4rHtmZAUVfNbCUr rRaO0mxAPzO2TZ70Zg0TP008YfixNEMPvkaNEVrOEeYr6pU3ZtnkivO4jWAC24VN0OPb Mezw== 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=PnIskzplxikmQ1lfPoAoP7lnjHfuAt9GIjfXAO/hwVI=; b=YyOYoFWTi2TO8y6yTRqIXlcaHUryJoaNkN9bgrJAWYctqYhsmaRhoWh1iVaTC0q3R6 IKYF/m5sG1jv3EqmNVoFXArdEsUsH7n7cVHKLEAsbBORa66kCGHzrGXZDb79Ag51pXnt mYHJ4bo2D4MWE4OTNgxVPEcAQ9cxYfaaJOqP2m1Hag+8lx+jWz8IRDosGhXPlIhtPO62 vd2kiguqQH9mT/SkP/+tdCmVvzcX+DxtXBv9EQRO53LqBwHizeijlTRoxNaDWriZhBUn mzR/vjw8pXyVPsPuMkU8J+NxXFqgoPfWVi9QPWWC9cfpPJ53OkBcKaPaWsmNS8ZllYdr lVrA== X-Gm-Message-State: AE9vXwONqF+krUyUhRlbtX+5XPe5uUpXy39at7oy2ukdd2Az5BBFzz6NQFA4y0IdM4W/+Z9v+wKZSsq6Lujwvg== X-Received: by 10.55.201.70 with SMTP id q67mr29812819qki.242.1471961670891; Tue, 23 Aug 2016 07:14:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.81.137 with HTTP; Tue, 23 Aug 2016 07:14:30 -0700 (PDT) In-Reply-To: References: From: Abdussalam Baryun Date: Tue, 23 Aug 2016 16:14:30 +0200 Message-ID: To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=001a114798dc84610b053abdc814 Archived-At: Cc: Russ Housley , "its@ietf.org" Subject: Re: [its] Charter comments 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, 23 Aug 2016 14:20:22 -0000 --001a114798dc84610b053abdc814 Content-Type: text/plain; charset=UTF-8 Hi Behcet I don't agree with the change of the name to VIC, the work-purpose of standerdizing is not only of communication but technologies and services. I understand that for the short term you see the work as communication, but that is just a start in a large journey of work. Other WGs are already working on parts that we need to use in our WG. ITS is the correct name for the work because many organisations are using the name and it is about systems not communications. IMHO, the name VIC cannot be used because it suggests working for proposes of interfaces to Internet system, which should be the work of other SDOs, or our work after making our proposal for Vehicle-system. We in IETF think that the IP is the future technology for Vehicles, so let us not market against our system (so ITS is the IP system for vehicles) until market chooses between technologies. AB On Mon, Aug 8, 2016 at 8:47 PM, Behcet Sarikaya wrote: > Hi Russ, > > Regarding the charter, I have a comment: > > I think that > Intelligent Transportation Systems (its), > is too generic for this group. > > I see that the informational item called ITS General Problem Area is > something that is being taken up. The standards track work is very > specific work and calling it ITS is in my view not appropriate. > > I suggest calling Vehicule to Internet Communications or vic would be > much more appropriate. > After all, IETF WGs with too generic names are not good, maybe OK for > IRTF like ICN. > > Regards, > > Behcet > > > On Thu, Jul 28, 2016 at 9:23 AM, Russ Housley > wrote: > > I got word from our Area Director that the IESG would like to see a > statement in the charter about coordination with IEEE 802.11. I added it. > > > > Here is the diff: https://trac.tools.ietf.org/ > wg/its/trac/wiki/WikiStart?action=diff&version=19 > > > > Here is the full charter: https://trac.tools.ietf.org/ > wg/its/trac/wiki/WikiStart > > > > Russ > > > > > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --001a114798dc84610b053abdc814 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Behcet

I don't ag= ree with the change of the name to VIC, the work-purpose of standerdizing i= s not only of communication but=C2=A0technologies and=C2=A0services. I unde= rstand that for the short term you see=C2=A0the work as=C2=A0communication,= but that is just a start in a large journey of work. Other WGs are already= working on parts that we need to use in our WG. ITS is the correct name fo= r the work because many organisations are using the name and it is about sy= stems not communications.

IMHO, the name VIC canno= t be used because it suggests working=C2=A0for proposes of interfaces to In= ternet system, which should be=C2=A0the work of other SDOs, or our work aft= er making our proposal for Vehicle-system. We in IETF think that the IP is = the future=C2=A0technology for Vehicles, so let us not market against our s= ystem (so ITS is the IP system for vehicles)=C2=A0until market chooses betw= een technologies.

AB

On Mon, Aug 8, 2016 at 8:47 PM, Beh= cet Sarikaya <sarikaya2012@gmail.com> wrote:
Hi Russ,

Regarding=C2=A0 the charter, I have a comment:

I think that
Intelligent Transportation Systems (its),
is too generic for this group.

I see that the informational item called ITS General Problem Area is
something that is being taken up. The standards track work is very
specific work and calling it ITS is in my view not appropriate.

I suggest calling Vehicule to Internet Communications or vic would be
much more appropriate.
After all, IETF WGs with too generic names are not good, maybe OK for
IRTF like ICN.

Regards,

Behcet


On Thu, Jul 28, 2016 at 9:23 AM, Russ Housley <housley@vigilsec.com> wrote:
> I got word from our Area Director that the IESG would like to see a st= atement in the charter about coordination with IEEE 802.11.=C2=A0 I added i= t.
>
> Here is the diff: https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart?ac= tion=3Ddiff&version=3D19
>
> Here is the full charter: https://trac.to= ols.ietf.org/wg/its/trac/wiki/WikiStart
>
> Russ
>
>
>
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its

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

--001a114798dc84610b053abdc814-- From nobody Tue Aug 23 08:34:15 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 C3A0912DA3F for ; Tue, 23 Aug 2016 08:34:13 -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 w7G2kuBFRKXo for ; Tue, 23 Aug 2016 08:34:11 -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 7181112D563 for ; Tue, 23 Aug 2016 08:19:35 -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 u7NFJXks017533 for ; Tue, 23 Aug 2016 17:19:33 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5B5F2206E31 for ; Tue, 23 Aug 2016 17:19:42 +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 52660206DD1 for ; Tue, 23 Aug 2016 17:19:42 +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 u7NFJXhc026055 for ; Tue, 23 Aug 2016 17:19:33 +0200 To: its@ietf.org References: <000001d1fa55$89c55470$9d4ffd50$@pilotresearch.com> From: Alexandre Petrescu Message-ID: Date: Tue, 23 Aug 2016 17:19:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <000001d1fa55$89c55470$9d4ffd50$@pilotresearch.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [its] Charter Comments 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, 23 Aug 2016 15:34:13 -0000 Some comments... Le 19/08/2016 à 22:09, Francois Simon a écrit : > From Francois Simon > > > > Charter Comments > > CHARTER [...] > Some vehicle and infrastructure communications will use IP and others > will not. Multiple applications need to share one data link, > including non-IP-based protocols sharing the data link with IP-based > protocols. > > */Fygs - It is assumed that “data link” here is per /**/ISO/IEC > 7498-1 standard definition and not a particular medium channel. > Multiple data link instances may use a common medium channel, as > well as a single data link instance my use multiple media./**//* ISO/IEC 7498-1 may be a good definition of a data link. One can see data link also as an Ethernet cable, or a pipe, on which _packets_ are multiplexed. A single data link would not be run simultaneously on multiple channels. If interested in that, there is a 'banana' effort at IETF that deals with such aspects. (ietf.org/mailman/listinfo/banana). If you are suggesting one should use here the term 'medium channel' instead of 'data link', I think both are equal in my mind. > This group will work on V2V and V2I use-cases where IP is > well-suited as a networking technology, supporting also applications > that involve exchanges of safety-related messages between vehicles > and infrastructure if necessary. > > */Fygs – Safety-related messages may require to be prioritized based > on the source application requirements. (e.g,. announcement of > weather conditions 10 km ahead will not have the same urgency than a > stopped vehicle 300 m ahead). Depending on the application’s > priority, decision to use IP or other protocol needs to be > assessed./** * This prioritization may be a topic in the future. I dont think at this time anyone committed to work on prioritization. Prioritization work can happen here after we got IP-over-80211-OCB right (the first step), otherwise any other prioritization will be specific to that particular SDO: MAC prioritization at IEEE, LTE prioritization at 3GPP, and so on. > This group will develop IP-based protocols to establish direct and > secure connectivity between a vehicle, which is often comprised of > moving networks, and other vehicles and stationary systems. Some > communications will be extremely short lived, but others will last > for many hours or days. > > > Moving network to nearby moving or fixed network communications may > involve various kinds of link layers: 802.11-OCB (Outside the > Context of a Basic Service Set, also called 802.11p), 802.15.4 with > 6lowpan, 802.11ad, VLC (Visible Light Communications), IrDA, LTE-D, > LP-WAN. One of the most used link layers for vehicular networks is > IEEE 802.11-OCB, as a basis for DSRC. However, IPv6 on 802.11-OCB is > not yet defined. > > */Fygs – This paragraph brings in a vast array of questions The list of link layer technologies (instead of just one) is there to suggest that this is heterogeneity and IP should be able to run on any one of these, in the future. Remark also we did not list any link layer technology that is not pertinent to vehicular communications (e.g. FSO). Again, _if_ IPv6-over-80211-OCB gets done, then people may get interested in doing moving network to moving network communications (direct vehicle-to-vehicle, IP direct over MAC); _if_ so there can be interest in doing moving network to moving network using other than 802.11-OCB technology: send IP over Visible Light Communications between vehicles, instead of blinking lights. > related to the actual scope of the group developing “IP-based > protocols to establish connectivity” between entities in motion > and/or stationary. It is not the intention here to open a > philosophical discussion of the various entities that may or may not > be in scope, but merely to point out the need for precise > definitions of entities involved in the “connectivity”. Follow are > few question examples which comes to mind (no particular order):/* > > · */Does the entities in motion are related to vehicles > only?/* At this time the main thrust comes from the automobile industry. But the technology can well be applied in other objects that move with respect to each other, provided they use IP (Internet Protocol). Water, air and space systems have been mentioned on the list. > · */Does living entities and/or “things” in motion capable of > establishing IP connectivity are excluded?/* Well, living entities would first need to implement IP, which is not known other than in April's fool fictitious IP-over-avian-carriers. Things, like in Internet-of-Things, or car-as-a-sensor are in scope. > o */One can argue that a conveyor belt is a “transportation > system”. /* > > · */Which mobile entities are excluded from the scope?/* At this time, some mobile entities are known to not implement 802.11-OCB, and no perspective: smartphones. > · */The same type of questions can apply to stationary > systems:/* > > o */Tethered or wireless land connectivity (i.e.; Free Space Optics > (FSO)/* FSO sounds like it needs sides precisely aligned. During Earthquake their communication would stop, without any possible help from software, but rather re-align the mechanics. For this reason I think they're out of scope here. > · */Etc./* > > */The list can be extensive./* We can see. [...] > 1. Standards Track RFC "IPv6 over 802.11p" > > */Fygs – As reference - It is believed that the actual IEEE Std > 802.11p is no longer available. This standard was the amendment of > IEEE Std 802.11-2007. The amendment has been incorporated in the > current IEEE Std 802.11-2012. Note that the clause references in > 802.11-2012 are not in line with 802.11p-2010/**.* Yes, there is awareness of this movement away from the 802.11p term. That begs a related question: would one consider the new 802.11ad standard in 'old 11p' conditions such as Out of the Context of BSSID, in a 5.9GHz channel, and with a half-rate encoding? That would give an attractive 3.5Gbit/s instead of 16Mbit/s of existing 11p trials. Alex From nobody Tue Aug 23 08:37:28 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 746C212D59D for ; Tue, 23 Aug 2016 08:37:26 -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 EGd477u6rJnb for ; Tue, 23 Aug 2016 08:37:25 -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 EBA3912D5E8 for ; Tue, 23 Aug 2016 08:28:45 -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 u7NFSgrM014596; Tue, 23 Aug 2016 17:28:42 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 39E10206E4C; Tue, 23 Aug 2016 17:28:51 +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 25485206E2F; Tue, 23 Aug 2016 17:28:51 +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 u7NFSffd030354; Tue, 23 Aug 2016 17:28:41 +0200 To: Dino Farinacci References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <2b7884f0-27f0-42e6-bbd9-a172e2b0d849@gmail.com> <95E1F7FA-A798-4189-945B-DC42F15705B4@gmail.com> <9C481EA4-6E1D-4558-BFD6-948F5728B86D@gmail.com> From: Alexandre Petrescu Message-ID: <49a3644e-a3a2-9af1-2a72-0285c42a35c1@gmail.com> Date: Tue, 23 Aug 2016 17:28:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: sarikaya@ieee.org, Tony Li , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , its@ietf.org Subject: Re: [its] Charter comments 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, 23 Aug 2016 15:37:27 -0000 Le 22/08/2016 à 16:48, Dino Farinacci a écrit : > Many RSUs which _are_ connected to the Internet have strong barriers >> between the interface connected to the Internet and the interface >> to the vehicles. The interface to the Internet is very necessary >> for remote management. But the fear of risk of forwarding between >> the two interfaces is very high. Moreover, some applications are >> bound to particular hardware, and so RSU is made of multiple boxes, >> which renders forwarding further complex to a trivial plan. > > The question is if this ship has already sailed. Not at all. > Today we have decent v2i by use of our cell phones. So the host > (vehicle) is the router as well. Some automobiles use owner's cell phones; some other automobiles use built-in M2M modules to get on Internet. The addressed market segment of the automobile dictates this differentiation (it's not simply a question of price). New automobile makers regularly show up regularly, each trying a different formula to fill even more niches. The connectivity aspects are each time very important criteria. No, the ship has not already sailed. > Another question is if a RSU, one that is upgraded with a decent > amount of bandwidth, can serve multiple host-only vehicles. Meaning, > providing *better* mobility then the "large subnet everywhere" that > cellular mobility provides today. I would guess yes, but we should not consider the vehicles to be host-only. There are multiple IP-addressable devices within each vehicle (at least 32). > Note the future is bound to have multiple wireless technologies. And > not just LTE and 5G. So mobility across providers is a necessity. > This is where a smarter, router-based, RSU will be needed. I agree. Alex > > Dino From nobody Tue Aug 23 08:38:18 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 1075C12D556 for ; Tue, 23 Aug 2016 08:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FGNsQt9_EtD for ; Tue, 23 Aug 2016 08:38:14 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 888A612D9DA for ; Tue, 23 Aug 2016 08:29:52 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id 97so250499901uav.3 for ; Tue, 23 Aug 2016 08:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=asEUWq/qtsBn90CHspBIJKHxPCAF8GuSWh7+Wt+p7Pk=; b=nG0kA5lZgekIrlIdaq18UxJ0zHGXd6h/H8RCsnMqh1nQFLjf7+xtKpCqKNJrR/9dwe 3RgahUFOA4K3s/ZpxXryQKzfjhrkx8WqztNnUd8nVmnZAb7LBydfXPelwbUKIklHdKya 7Iq4PXL/R12sJkdIOZL3aItjOouJLOqSytJOoFa1+uf08Tynv0MJwwea0q2r7XZXi6Ei qns4+kEPJVdkVDmCzrifhs393oFJli4EVAHOg0l9ErvkB2eLrSx4MBB2j5f/Y3wPWpM/ 9INlZrSqYmRTK9mwL72tXos7ORD5kYzm8lZRGbxvjK4fLNhq3ZaM5WBBl5Ol+gzTyOJl ru3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=asEUWq/qtsBn90CHspBIJKHxPCAF8GuSWh7+Wt+p7Pk=; b=g+5Qb1nUFISnEAkn/EF6nfvkkm9ZKc10bCNAGo7FvRjwRT6ClpdxZvo6h5dO6UbJJp +R++j7wjCCQZlQNDy7emxKJVYPZyidFbUqtjtBy2NhEAJfHJQWDdAfzD4HnlJpDsSSNB sRvA6n2sy1KtLWA0sr3zVw7rRJCIrwO8VcybQ+8IbiWBIs4FtNV42nRlNo145JPiIWT4 hTXefkAKJO9QXtakT4SUP6nb0G1LRM0gMGLsS3zEMuQZxxLhJsD8o2AG7YOh/L2ORYk5 oCCyipiijQA7VA6/3NjtZrw8EFa6G1OTNiVckaRe24vIYLNfZS71IebI2Qfrb9t4YtJh oPSQ== X-Gm-Message-State: AEkoousLk4w27PRNTSInsUIABWyTnCkCKU7ROjKrEHP1QHlP+HtPQq9wlPm6nRTLYFnsQITX0i11s4fLzyh/dw== X-Received: by 10.31.47.207 with SMTP id v198mr14081931vkv.109.1471966191556; Tue, 23 Aug 2016 08:29:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.167 with HTTP; Tue, 23 Aug 2016 08:29:50 -0700 (PDT) In-Reply-To: References: <48CB0C55-1B1C-4033-A0A2-1F76CF929FE1@tony.li> <001e01d1f719$9bf45860$d3dd0920$@eurecom.fr> <2b7884f0-27f0-42e6-bbd9-a172e2b0d849@gmail.com> From: Behcet Sarikaya Date: Tue, 23 Aug 2016 10:29:50 -0500 Message-ID: To: abdussalambaryun@gmail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Alexandre Petrescu , Tony Li , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , its@ietf.org Subject: Re: [its] Charter comments X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 15:38:16 -0000 Abdussalam, Alex, You are referring to previous mails from me. The mail below is the latest in which I proposed the name wireless IP access in vehicular environments not V* or IP access in vehicular environments If this is (referring to my old mail) is deliberate, I protest it. The other SDOs may use the word intelligent, it is their problem. I think in IETF the name of the group should reflect the work to be done. Regards, Behcet On Mon, Aug 22, 2016 at 2:00 PM, Behcet Sarikaya w= rote: > On Mon, Aug 22, 2016 at 8:49 AM, Alexandre Petrescu > wrote: >> >> >> Le 15/08/2016 =C3=A0 20:13, Behcet Sarikaya a =C3=A9crit : >>> >>> I don't think V2V should be an IETF issue. >> >> >> I dont know what you mean more precisely by "V2V"? > > What is called horizontal communication. > >> >> Two vehicles exchanging IP datagrams - via more or less infrastructure - >> is obviously an IETF issue. >> >> Some deployed applications already do so (coyote and others). >> >>> Regarding V2I, if you don't like it, propose another name. >> >> >> I dont know what you mean more precisely by V2I either. >> >> V2I like in Mobile IP would not need development in other than existing = WGs. > > Mobility is out of scope at least in the current charter, I think. > >> >> V2I like in a Road-Side Unit broadcasting Points of Interest is not >> V2Internet (Mobile IP), yet it may use same IP datagrams as in V2V. >> >> For these reasons, I believe V2I, V2V and V2Internet are hard to >> distinguish, and as such it's hard to propose another name. >> > > Disagree. > I saw this in your draft: > Wireless Access in Vehicular Environments, > it could be used with a small change like > > Wireless IP Access in Vehicular Environments > > I think this name would reflect much better the charter. > Maybe in future versions you may use the great word of intelligent :-) > > Regards, > > Behcet > From nobody Tue Aug 23 08:41:11 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 BB03012D5A0 for ; Tue, 23 Aug 2016 08:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 8cU-cw3M6GJI for ; Tue, 23 Aug 2016 08:41:06 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F9812D5DB for ; Tue, 23 Aug 2016 08:34:55 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-04v.sys.comcast.net with SMTP id cDhVbAjrl8PeacDj5bCIDt; Tue, 23 Aug 2016 15:34:55 +0000 Received: from [10.120.1.193] ([12.1.72.210]) by resomta-ch2-04v.sys.comcast.net with SMTP id cDgtbmVuonqiCcDgwbUArF; Tue, 23 Aug 2016 15:32:53 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_85CB1445-9092-46D6-B63C-596AABCDEF5A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Tony Li In-Reply-To: Date: Tue, 23 Aug 2016 08:32:39 -0700 Message-Id: <5066CCEE-5FD2-4449-8245-98BC306E3FF4@tony.li> References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.3124) X-CMAE-Envelope: MS4wfGB2gIdKv4EINsRSBRrw2Jnh1aRLLGP4zLbEvQjssHNhf4/CJfbcLI8E6gzT/iR6/D0o1+XWDp9RBLajfX7N1osj1ACnZM+uAlo4t3cKhRH+WPzG+Y0Z X0rKek5KsSVwKFWDUAPftvJ0bMvoYLd9ZZ5WRtDE/v4+5F9/N3io69pUb7fkrVZIPV56iCOEUj2aORmrLQwXcb1fgT9euoNDpHjUH6oi7oqiETl7Jbur3f7I 4V9FRU+T+xvL7ePnEEnSYg== Archived-At: Cc: sarikaya@ieee.org, Russ Housley , "its@ietf.org" Subject: Re: [its] Charter comments 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, 23 Aug 2016 15:41:09 -0000 --Apple-Mail=_85CB1445-9092-46D6-B63C-596AABCDEF5A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Folks, If you=E2=80=99re not an IETF old-timer, you may not be aware that we = have a tradition of trying to inject a little humor into our lives by = creative naming of our WGs. ITS and VIC don=E2=80=99t begin to qualify = in that regard. In that direction, I submit to you some alternative = names: IPOD - IP over DSRC ITSIT - Intelligent Transportation Systems with IP Technology = [c.f., It=E2=80=99s-it, a San Francisco ice cream treat] IVY - IP for Vehicles Yesterday VIM - Vehicles with Intelligent Management VICE - Vehicles with IP Controller Enhancement VIP - Vehicles with IP =09 I encourage further creativity. Regards, Tony > On Aug 23, 2016, at 7:14 AM, Abdussalam Baryun = wrote: >=20 > Hi Behcet >=20 > I don't agree with the change of the name to VIC, the work-purpose of = standerdizing is not only of communication but technologies and = services. I understand that for the short term you see the work as = communication, but that is just a start in a large journey of work. = Other WGs are already working on parts that we need to use in our WG. = ITS is the correct name for the work because many organisations are = using the name and it is about systems not communications. >=20 > IMHO, the name VIC cannot be used because it suggests working for = proposes of interfaces to Internet system, which should be the work of = other SDOs, or our work after making our proposal for Vehicle-system. We = in IETF think that the IP is the future technology for Vehicles, so let = us not market against our system (so ITS is the IP system for vehicles) = until market chooses between technologies. >=20 > AB >=20 > On Mon, Aug 8, 2016 at 8:47 PM, Behcet Sarikaya = > wrote: > Hi Russ, >=20 > Regarding the charter, I have a comment: >=20 > I think that > Intelligent Transportation Systems (its), > is too generic for this group. >=20 > I see that the informational item called ITS General Problem Area is > something that is being taken up. The standards track work is very > specific work and calling it ITS is in my view not appropriate. >=20 > I suggest calling Vehicule to Internet Communications or vic would be > much more appropriate. > After all, IETF WGs with too generic names are not good, maybe OK for > IRTF like ICN. >=20 > Regards, >=20 > Behcet >=20 >=20 > On Thu, Jul 28, 2016 at 9:23 AM, Russ Housley > wrote: > > I got word from our Area Director that the IESG would like to see a = statement in the charter about coordination with IEEE 802.11. I added = it. > > > > Here is the diff: = https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart?action=3Ddiff&versi= on=3D19 = > > > > Here is the full charter: = https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart = > > > > Russ > > > > > > > > _______________________________________________ > > 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 = >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --Apple-Mail=_85CB1445-9092-46D6-B63C-596AABCDEF5A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Folks,

If you=E2=80=99re not an IETF = old-timer, you may not be aware that we have a tradition of trying to = inject a little humor into our lives by creative naming of our WGs. ITS = and VIC don=E2=80=99t begin to qualify in that regard. In that = direction, I submit to you some alternative names:

IPOD - IP over = DSRC
ITSIT - Intelligent Transportation = Systems with IP Technology [c.f., It=E2=80=99s-it, a San Francisco ice = cream treat]
IVY - IP for Vehicles = Yesterday
VIM - Vehicles with = Intelligent Management
VICE - Vehicles with IP Controller = Enhancement
VIP - Vehicles with = IP
I encourage = further creativity.

Regards,
Tony


On Aug 23, 2016, at 7:14 AM, = Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Hi Behcet

I don't agree with the = change of the name to VIC, the work-purpose of standerdizing is not only = of communication but technologies and services. I understand = that for the short term you see the work as communication, but = that is just a start in a large journey of work. Other WGs are already = working on parts that we need to use in our WG. ITS is the correct name = for the work because many organisations are using the name and it is = about systems not communications.

IMHO, the name VIC cannot be used = because it suggests working for proposes of interfaces to Internet = system, which should be the work of other SDOs, or our work after = making our proposal for Vehicle-system. We in IETF think that the IP is = the future technology for Vehicles, so let us not market against = our system (so ITS is the IP system for vehicles) until market = chooses between technologies.

AB

On Mon, = Aug 8, 2016 at 8:47 PM, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:
Hi Russ,

Regarding  the charter, I have a comment:

I think that
Intelligent Transportation Systems (its),
is too generic for this group.

I see that the informational item called ITS General Problem Area is
something that is being taken up. The standards track work is very
specific work and calling it ITS is in my view not appropriate.

I suggest calling Vehicule to Internet Communications or vic would be
much more appropriate.
After all, IETF WGs with too generic names are not good, maybe OK for
IRTF like ICN.

Regards,

Behcet


On Thu, Jul 28, 2016 at 9:23 AM, Russ Housley <housley@vigilsec.com> wrote:
> I got word from our Area Director that the IESG would like to see a = statement in the charter about coordination with IEEE 802.11.  I = added it.
>
> Here is the diff: https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart?action=3Ddiff&version=3D19
>
> Here is the full charter: https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart
>
> Russ
>
>
>
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its

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

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

= --Apple-Mail=_85CB1445-9092-46D6-B63C-596AABCDEF5A-- From nobody Tue Aug 23 16:50:40 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 69F6112D83D; Tue, 23 Aug 2016 16:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 5r6wKy1FdpPB; Tue, 23 Aug 2016 16:50:36 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20092.outbound.protection.outlook.com [40.107.2.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2D6712D50B; Tue, 23 Aug 2016 16:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WZAV82L9bfMmPC8QanW53Lo4yjMHHDXnbhe/66hlOak=; b=gTY1Y9eDYIKMmzqzFyrttLC2z8K8e6wEVyXPhXI/2NFFNY/cwk4If+7qppognxklp6Za5cUk/sZ93YyjAHdy7APy7PeyT0HjSlQCgWDxrjCd4Y9GkYGfVz6I+TPYq+Spl7TGJIP2TgKpzosDDACfJOKT5u11wJ/UPAUusTF2o84= Received: from AM5PR0701MB2307.eurprd07.prod.outlook.com (10.169.152.18) by AM5PR0701MB2306.eurprd07.prod.outlook.com (10.169.152.17) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Tue, 23 Aug 2016 23:50:32 +0000 Received: from AM5PR0701MB2307.eurprd07.prod.outlook.com ([10.169.152.18]) by AM5PR0701MB2307.eurprd07.prod.outlook.com ([10.169.152.18]) with mapi id 15.01.0557.027; Tue, 23 Aug 2016 23:50:32 +0000 From: "Ravindran, Parthasarathi (Nokia - IN/Bangalore)" To: "Carlos Pignataro (cpignata)" , "its@ietf.org" Thread-Topic: DRAFT Minutes - ITS, IETF96 Thread-Index: AQHR8Ip6oeskc0amzEqKdDmq0gK/VqBXTVfw Date: Tue, 23 Aug 2016 23:50:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=parthasarathi.ravindran@nokia.com; x-originating-ip: [131.228.2.9] x-ms-office365-filtering-correlation-id: 3b52e9f6-b0c1-4d53-6233-08d3cbb0451e x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2306; 6:alsl7QJodMNbTjMMBzehChUBgD9w2AFwdYZbl1Ze4JkcJ1zxhrFNL/hhlpVx37cgV6MKWjJggnGOBG2ePT5eofjxkVBInmwMXA9ZBmSQR82qm9rb4Yux+1Qq/4DI6o3fYPB32Dx6dYin3qbWUtOlSWYZL7Yjox/JxxTbjag3jl/77s9B7tITqvHoN37FevrqP9aqMCE17YcbIveccI7sSjo/RKLq+Byi6Rrc5d7HTVp+gxdZcdobk9vHI5DNsWYXcMhaK8XRkeaqYYVTgXyS5vrtap+PsDKRWRaEKvGFgXQ44jheOVVZSBR5q+lW5QsNiNDE3nNbdLbd8ROYSPw1gQ==; 5:ww0yUGUFwiW8UwlqmJRyCBPd2VrDkgZPrszEKJhOTdJf2FO5okuqv4XToONiYUTV93TVp6F+ipqKXdUhc5gZwDI7NJTXJ41lRYIwbwYMfME/ZSi7Po7hsasNa30m453mlTZDAOHJU8pkUVPsWdASOw==; 24:CLcyW87GGtn1R5EhfiSsBcpjWq50CNkgLjsAM4iLBRv9aqCgbtfstYcVuNUDi9+VLzfCslksxyCODG6ct8n2G03XBVxS1MXlQcM+puIT+lc=; 7:PbUjsQ7zgzB4XzFdAr7DrGTEucq7dhu+S0QotPXH4rC7eyrNjMLB2fSGy7men76htS2ytX1yOZwPWZfi7UeUsVJGiq56aCQ0CeU++qGJWNnO46ntWDh9Zx8bPlRaq0arb1sHMUMsYLYKi7iZLFCcLGy7O/P1XOVPeTquP6vxn/WM3A6/h5hu/jFLGSLW4uRWjfc1eWu2YJqpUP1YCiQSHE6fFtyi5T0J/VIS1zwyHYMwOyPrd8qsYG+2sX1BDS/4 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0701MB2306; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:AM5PR0701MB2306; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2306; x-forefront-prvs: 004395A01C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(53754006)(199003)(13464003)(76576001)(86362001)(11100500001)(106356001)(105586002)(2950100001)(5002640100001)(2900100001)(15975445007)(189998001)(33656002)(10400500002)(97736004)(7696003)(76176999)(87936001)(77096005)(54356999)(101416001)(122556002)(19580395003)(66066001)(50986999)(5001770100001)(106116001)(2501003)(74316002)(3846002)(3660700001)(305945005)(19580405001)(92566002)(8936002)(3280700002)(4326007)(2906002)(9686002)(7736002)(6116002)(102836003)(81156014)(81166006)(7846002)(586003)(68736007)(5660300001)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2306; H:AM5PR0701MB2307.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2016 23:50:32.3273 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2306 Archived-At: Cc: "its-chairs@ietf.org" Subject: Re: [its] DRAFT Minutes - ITS, IETF96 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, 23 Aug 2016 23:50:39 -0000 Hi all, Sorry for the delay response.=20 IMO, V2X of 3GPP has to the added to the charter now. This supports to cove= r 3GPP V2X specific problem statement, security consideration and privacy a= s well. It is not clear from the minutes whether V2X of 3GPP is within the current = charter scope or not. Could you please confirm. Regards Partha -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpig= nata) Sent: Sunday, August 07, 2016 2:33 PM To: its@ietf.org Cc: its-chairs@ietf.org Subject: [its] DRAFT Minutes - ITS, IETF96 Hi, ITS, Please find draft minutes (with thanks to Alex) posted at: https://www.ietf.org/proceedings/96/minutes/minutes-96-its Please send to the list by reply-all any corrections, omissions, or fixes, = in preparation to posting our final minutes. Thanks, Carlos & Russ. _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Wed Aug 31 13:15:24 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 4F42E12D775 for ; Wed, 31 Aug 2016 13:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01] 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 lTV6x6Jgq7bA for ; Wed, 31 Aug 2016 13:15:19 -0700 (PDT) Received: from atl4mhob13.myregisteredsite.com (atl4mhob13.myregisteredsite.com [209.17.115.51]) by ietfa.amsl.com (Postfix) with ESMTP id E5E0112D773 for ; Wed, 31 Aug 2016 13:15:18 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob13.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u7VKFFTE012412 for ; Wed, 31 Aug 2016 16:15:15 -0400 Received: (qmail 7900 invoked by uid 0); 31 Aug 2016 20:08:35 -0000 X-TCPREMOTEIP: 108.51.227.121 X-Authenticated-UID: fygs@pilotresearch.com Received: from unknown (HELO FrancoisPC) (fygs@pilotresearch.com@108.51.227.121) by 0 with ESMTPA; 31 Aug 2016 20:08:35 -0000 From: "Francois Simon" To: , , Date: Wed, 31 Aug 2016 16:08:36 -0400 Message-ID: <000001d203c3$75404ce0$5fc0e6a0$@pilotresearch.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D203A1.EE345230" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdIDw3TRj9Dl+mEKTfOcW8ISEIRg1A== Content-Language: en-us Archived-At: Subject: [its] ITS Charter Comments 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, 31 Aug 2016 20:15:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D203A1.EE345230 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Please, find my comments on the ITS charter (embedded in the initial = text). If you have any questions, please do not hesitate to contact me. Sincerely, Francois y. Simon Pilot Research, Inc. Tel: 301-404-1663 =20 Intelligent Transportation Systems (its), Charter=20 Chairs=20 Russ Housley=20 Carlos Pignataro =20 Assigned Area Director=20 Suresh Krishnan=20 Mailing list=20 Address: =E2=80=8Bits@ietf.org=20 To Subscribe: = =E2=80=8Bhttps://www.ietf.org/mailman/listinfo/its=20 Archive: = = =E2=80=8Bhttp://www.ietf.org/mail-archive/web/its/current/maillist.html=20 Archive: = =E2=80=8Bhttps://mailarchive.ietf.org/arch/search/?email_list=3Dits=20 Additional web page=20 TBD=20 Charter=20 Automobiles and vehicles of all types are increasingly connected to the Internet. Comfort-enhancing entertainment applications, road safety applications using bidirectional data flows, and connected automated driving are but a few new features expected in automobiles to hit the roads from now to year 2020. [Fygs: Safety applications may not always require bidirectional data = flows. i.e.; Most Safety applications using DSRCS use unidirectional = flow: source to sink.] =20 Today, there are several deployed Vehicle-to-Internet technologies (V2Internet) that make use of embedded Internet modules, or through driver's cellular smartphone: mirrorlink, carplay, android auto. However, Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I, not to be mistaken with V2Internet) communications are still being developed. =20 Some vehicle and infrastructure communications will use IP and others will not. Multiple applications need to share one data link, including non-IP-based protocols sharing the data link with IP-based protocols. =20 This group will work on V2V and V2I use-cases where IP is well-suited as a networking technology, supporting also applications that involve exchanges of safety-related messages between vehicles and infrastructure if necessary. =20 This group will develop IP-based protocols to establish direct and secure connectivity between a vehicle, which is often comprised of moving networks, and other vehicles and stationary systems. Some communications will be extremely short lived, but others will last for many hours or days. [Fygs: =E2=80=9C=E2=80=A6between a vehicle, which is often comprise of = moving network=E2=80=A6=E2=80=9D. This section of the sentence is = somewhat ambiguous: Is it intended to state that a vehicle may contains devices needing = connectivity within the confinement of the vehicle? Which can be true. = Within a vehicle moving in relation to the =E2=80=9Coutside = world=E2=80=9D (e.g.; highway), may also contain moving devices = requiring connectivity (in a relatively limited space and communication = range such as Bluetooth device); or Is it intended to imply that clusters of vehicles = (=E2=80=9Cswarms=E2=80=9D), in motion or stationary which communicate = within a swarm may also require connectivity with individual vehicle, = another swarm, and stationary systems? If this is intended, then the = charter is entrenching in the realm of MANET, which may not be a = =E2=80=9Crabbit whole=E2=80=9D the group wants to be in.] =20 Moving network to nearby moving or fixed network communications may involve various kinds of link layers: 802.11-OCB (Outside the Context of a Basic Service Set, also called 802.11p), 802.15.4 with 6lowpan, 802.11ad, VLC (Visible Light Communications), IrDA, LTE-D, LP-WAN. One of the most used link layers for vehicular networks is IEEE 802.11-OCB, as a basis for DSRC. However, IPv6 on 802.11-OCB is not yet defined. [Fygs =E2=80=93 =E2=80=9Chowever, IPv6 on 802.11-)OCB is not yet = defined=E2=80=9D=20 First, OCB which is MIB attribute within 802.11 is an 802.11 link layer = is an option and is not related to the network layer which may use the = OCB services. IEEE 802.11p standard was carefully crafted so that DSRC = or WAVE were NOT mentioned in the 802.11p standard. Second, FYI, IPv6 is included as a network layer service in the DSRC = protocol stack; see IEEE 1609.3-2016. Note: It may not be as detailed as = the IETF-ITS group would like but it is specified.]=20 =20 The group will work only on IPv6 solutions. =20 The group will leverage on technologies for Internet of Things (IoT) which are developed in other IETF and IRTF efforts: 6lo WG, LP-WAN WG, and T2T RG. Co-existence with techniques of infrastructure mobility management will be coordinated with the DMM WG, LISP WG, and other mobility solutions. =20 The group will coordinate with IEEE 802.11. Other SDOs interested in this work include ISO/TC204, ETSI TC ITS, 3GPP, and NHTSA. =20 This group will not work on V2V or V2I use-cases where IP is not well-suited. Without re-chartering, this group will not work on Delay-Tolerant Networking nor on Information-Centric Networking. =20 [Fygs: FYI: DTN starts to find its way for land based ITS applications.] =20 If the group is successful in accomplishing its first goals, then it can be rechartered to work on other things (examples include but are not limited to: a 1-hop mechanism of IP prefix exchange between moving networks, an n-hop extension, naming for moving networks; generalization for trains, air, unmanned and space use-cases). Work items=20 1. Standards Track RFC "IPv6 over 802.11p" [Fygs: See latest IEEE 1609 = series.} =20 =20 =20 2. Potential Informational RFC "ITS General Problem Area" covering: - What is ITS? -- Explain V2V, V2I, and related terms [Fygs: This a hard one as the three terms mentioned have been in use for = almost two decades worldwide. The logic would dictate that the terms = could be re-defined for today=E2=80=99s views but are likely to be = changed by tomorrow=E2=80=A6. ITS: =E2=80=9CIntelligence=E2=80=9D: Can include anything from = =E2=80=9Chuman-hands-off=E2=80=9D to Artificial Intelligence (AI).=20 =E2=80=9CTransportation=E2=80=9D: It varies from invention of the wheel, = to conveyor belt, and would include skis and horse-and-buggy = :)=E2=80=A6.. Attempting a definition change would be a waste of = resources and unproductive. Let it lie!] =E2=80=9CV2V=E2=80=9D: Has been historically associated with = communications between vehicles for Safety applications. Of course one = can debate to infinitum the definition of =E2=80=9Cvehicles=E2=80=9D = which could change every day. For the purpose of this charter it is = proposed and certainly can be modified by the group as required: =E2=80=9CVehicle-to-vehicle (V2V) communication enables intention = sharing among neighboring vehicles and thereby vehicles' motion can be = coordinated to incorporate collision (or conflict) avoidance=E2=80=9D. = = Intelligent Vehicles Symposium (IV), 2015 IEEE =E2=80=9CV2I=E2=80=9D: Same as above. The following is proposed and can = be modified by the group as required: Vehicle-to-Infrastructure (V2I) Communications for Safety is the = wireless exchange of critical safety and operational data between = vehicles and roadway infrastructure, intended primarily to avoid motor = vehicle crashes. USDOT =E2=80=9CV2X=E2=80=9D: Is a relatively new term.=20 * It started with V2X meaning [V2V + V2I]; * Then, V2X meant V2-pedestrian, -bikes, and -others; * Since IOT became a buzz word, V2X became = Vehicle-to-everything; * Lately, a sub-set of V2X become in vogue:=20 o V2P =E2=80=93 Vehicle-to-Pedestrian o V2D =E2=80=93 Vehicle-to-Device o V2G =E2=80=93 Vehicle-to-Grid In any case, the following definition seems to be the consensus for now: = =E2=80=9CVehicle-to-everything (V2X) communication is the passing of = information from a vehicle to any entity that may affect the vehicle, = and vice versa=E2=80=9D. - Why is IPv6 needed? -- Explain why some traffic will not use IPv6 [Fygs: As DSRC is concerned, exchange of Safety applications data must = be done as close to =E2=80=9Creal-time=E2=80=9D as possible. Anything = which affect the end-to-end latency (source to sink) must be kept to = minimum (data payload size, protocol overhead size, processing time, = etc.). Note that a vehicle traveling at 200 km/h move toward the event = horizon at 55 m/s.] =20 -- Explain why other traffic will use IPv6 - Use-cases, illustrating the expected areas for initial focus - Informative references, relationship with other SDOs=20 =20 3. Potential Informational RFC "Problem Statement" covering: - Problem statement - Security considerations - Privacy considerations Goals and milestones=20 Oct 2016 - Draft for "IPv6 over 802.11-OCB" adopted by WG =20 Dec 2016 - Draft for "ITS General Problem Area" adopted by WG =20 Mar 2017 - Draft for "Problem Statement" adopted by WG =20 May 2017 - Submit "IPv6 over 802.11-OCB" to IESG =20 Oct 2017 - Submit "ITS General Problem Area" to IESG =20 May 2018 - Submit "Problem Statement" to IESG =20 ------=_NextPart_000_0001_01D203A1.EE345230 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Please, find my comments on the ITS charter (embedded = in the initial text).

If you have any = questions, please do not hesitate to contact me.

Sincerely,

Francois = y. Simon

Pilot Research, Inc.

Tel: = 301-404-1663

 

Intelligent Transportation Systems (its), = Charter

Chairs =

Russ Housley
Carlos Pignataro = =C2=A0

Assigned Area Director =

Suresh Krishnan

Mailing list =

Address: =E2=80=8Bits@ietf.org
To = Subscribe: =E2=80=8Bhttps://www.ietf.org/mailman/listinfo/its =
Archive: <= span style=3D'font-family:"Times New = Roman",serif'>=E2=80=8Bhttp://www.ietf.org/mail-archive/web/its/current/m= aillist.html
Archive: =E2=80=8Bhttps://mailarchive.ietf.org/arch/search/?email_li= st=3Dits

Additional web page =

TBD

Charter =

Automobiles and vehicles of all types are increasingly = connected to

the Internet.=C2=A0 Comfort-enhancing entertainment = applications, road

safety applications using bidirectional data flows, = and connected

automated driving are but a few new features expected = in automobiles

to hit the roads from now to year = 2020.

[Fygs: Safety applications may not = always require bidirectional data flows.=C2=A0 i.e.; Most Safety = applications using DSRCS use unidirectional flow: source to = sink.]

 

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

(V2Internet) that make use of embedded Internet = modules, or through

driver's cellular smartphone: mirrorlink, carplay, = android auto.

However, Vehicle-to-Vehicle (V2V) and = Vehicle-to-Infrastructure (V2I,

not to be mistaken with V2Internet) communications are = still being

developed.

 

Some vehicle and infrastructure communications will = use IP and

others will not.=C2=A0 Multiple applications need to = share one data

link, including non-IP-based protocols sharing the = data link with

IP-based protocols.

 

This group will work on V2V and V2I use-cases where IP = is well-suited

as a networking technology, supporting also = applications that involve

exchanges of safety-related messages between vehicles = and

infrastructure if necessary.

 

This group will develop IP-based protocols to = establish direct and

secure connectivity between a vehicle, which is often = comprised of

moving networks, and other vehicles and stationary = systems.=C2=A0 Some

communications will be extremely short lived, but = others will last for

many hours or days.

[Fygs: =E2=80=9C=E2=80=A6between a = vehicle, which is often comprise of moving = network=E2=80=A6=E2=80=9D. This section of the sentence is somewhat = ambiguous:

Is it intended to state that a = vehicle may contains devices needing connectivity within the confinement = of the vehicle? Which can be true. Within a vehicle moving in relation = to the =E2=80=9Coutside world=E2=80=9D (e.g.; highway), may also contain = moving devices requiring connectivity (in a relatively limited space and = communication range such as Bluetooth device); = or

Is it intended to imply that clusters = of vehicles (=E2=80=9Cswarms=E2=80=9D), in motion or stationary which = communicate within a swarm may also require connectivity with individual = vehicle, another swarm, and stationary systems? If this is intended, = then the charter is entrenching in the realm of MANET, which may not be = a =E2=80=9Crabbit whole=E2=80=9D the group wants to be in.]

 

Moving network to nearby moving or fixed network = communications may

involve various kinds of link layers: 802.11-OCB = (Outside the Context

of a Basic Service Set, also called 802.11p), 802.15.4 = with 6lowpan,

802.11ad, VLC (Visible Light Communications), IrDA, = LTE-D, LP-WAN.=C2=A0 One

of the most used link layers for vehicular networks is = IEEE 802.11-OCB,

as a basis for DSRC.=C2=A0 However, IPv6 on 802.11-OCB = is not yet defined.

[Fygs =E2=80=93 =E2=80=9Chowever, = IPv6 on 802.11-)OCB is not yet defined=E2=80=9D =

First, OCB which is MIB attribute = within 802.11 is an 802.11 link layer is an option and is not related to = the network layer which may use the OCB services.=C2=A0 IEEE 802.11p = standard was carefully crafted so that DSRC or WAVE were NOT mentioned = in the 802.11p standard.

Second, FYI, IPv6 is included as a = network layer service in the DSRC protocol stack; see IEEE 1609.3-2016. = Note: It may not be as detailed as the IETF-ITS group would like but it = is specified.]

 

The group will work only on IPv6 = solutions.

 

The group will leverage on technologies for Internet = of Things (IoT)

which are developed in other IETF and IRTF efforts: = 6lo WG, LP-WAN WG,

and T2T RG.=C2=A0 Co-existence with techniques of = infrastructure mobility

management will be coordinated with the DMM WG, LISP = WG, and other

mobility solutions.

 

The group will coordinate with IEEE 802.11.=C2=A0 = Other SDOs interested

in this work include ISO/TC204, ETSI TC ITS, 3GPP, and = NHTSA.

 

This group will not work on V2V or V2I use-cases where = IP is not

well-suited.=C2=A0 Without re-chartering, this group = will not work on

Delay-Tolerant Networking nor on Information-Centric = Networking.

 

[Fygs: FYI: DTN starts to find its way = for land based ITS applications.]

 

If the group is successful in accomplishing its first = goals, then it

can be rechartered to work on other things (examples = include but are

not limited to: a 1-hop mechanism of IP prefix = exchange between moving

networks, an n-hop extension, naming for moving = networks;

generalization for trains, air, unmanned and space = use-cases).

Work items =

1. = Standards Track RFC "IPv6 over 802.11p" = [Fygs: See latest IEEE 1609 series.}

 

 

 

2. Potential Informational RFC "ITS General = Problem Area" covering:

=C2=A0 - What is ITS?

=C2=A0=C2=A0=C2=A0=C2=A0 -- Explain V2V, V2I, and = related terms

[Fygs: This a hard one as the three = terms mentioned have been in use for almost two decades worldwide. The = logic would dictate that the terms could be re-defined for = today=E2=80=99s views but are likely to be changed by = tomorrow=E2=80=A6.

ITS:

=E2=80=9CIntelligence=E2=80=9D: = Can include anything from =E2=80=9Chuman-hands-off=E2=80=9D to = Artificial Intelligence (AI).

=E2=80=9CTransportation=E2=80=9D: It varies = from invention of the wheel, to conveyor belt, and would include skis = and horse-and-buggy J=E2=80=A6.. Attempting a definition change would = be a waste of resources and unproductive.=C2=A0 Let it = lie!]

=E2=80=9CV2V=E2=80=9D: Has been = historically associated with communications between vehicles for Safety = applications. Of course one can debate to infinitum the definition of = =E2=80=9Cvehicles=E2=80=9D which could change every day. For the purpose = of this charter it is proposed and certainly can be modified by the = group as required:

=E2=80=9CVehicle-to-vehicle = (V2V) communication enables intention sharing among neighboring vehicles = and thereby vehicles' motion can be coordinated to incorporate = collision (or conflict) avoidance=E2=80=9D. Intelligent = Vehicles Symposium (IV), 2015 IEEE

=E2=80=9CV2I=E2=80=9D= : Same as above. The following is proposed and can = be modified by the group as required:

Vehicle-to-Infrastructure (V2I) = Communications for Safety is the wireless exchange of critical = safety and operational data between vehicles and roadway = infrastructure, intended primarily to avoid motor vehicle = crashes.=C2=A0 = USDOT

=E2=80=9CV2X=E2=80=9D: Is a relatively new term. =

=C2=B7         = It started=C2=A0 with V2X meaning = [V2V + V2I];

=C2=B7         = Then, V2X meant V2-pedestrian, = -bikes, and -others;

=C2=B7         = Since IOT became a buzz word, V2X = became Vehicle-to-everything;

=C2=B7         = Lately, a sub-set of V2X become = in vogue:

o   = V2P =E2=80=93 = Vehicle-to-Pedestrian

o   = V2D =E2=80=93 = Vehicle-to-Device

o   = V2G =E2=80=93 = Vehicle-to-Grid

In any case, the = following definition seems to be the consensus for now: = =E2=80=9CVehicle-to-everything = (V2X) communication is the passing of information from a vehicle = to any entity that may affect the vehicle, and vice = versa=E2=80=9D.

=C2=A0 - Why is IPv6 needed?

=C2=A0=C2=A0=C2=A0=C2=A0 -- Explain why some traffic = will not use IPv6

[Fygs: As DSRC is concerned, exchange = of Safety applications data must be done as close to = =E2=80=9Creal-time=E2=80=9D as possible. Anything which affect the = end-to-end latency (source to sink) must be kept to minimum (data = payload size, protocol overhead size, processing time, etc.). = Note that a vehicle traveling at 200 = km/h move toward the event horizon at 55 m/s.]=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-- Explain why other = traffic will use IPv6

=C2=A0 - Use-cases, illustrating the expected areas = for initial focus

=C2=A0 - Informative references, relationship with = other SDOs

 

3. Potential Informational RFC "Problem = Statement" covering:

=C2=A0=C2=A0 - Problem = statement

=C2=A0=C2=A0 - Security = considerations

=C2=A0=C2=A0 - Privacy = considerations

Goals and milestones =

Oct 2016 - Draft for "IPv6 over 802.11-OCB" = adopted by WG

 

Dec 2016 - Draft for "ITS General Problem = Area" adopted by WG

 

Mar 2017 - Draft for "Problem Statement" = adopted by WG

 

May 2017 - Submit "IPv6 over 802.11-OCB" to = IESG

 

Oct 2017 - Submit "ITS General Problem Area" = to IESG

 

May 2018 - Submit "Problem = Statement" to IESG

 

------=_NextPart_000_0001_01D203A1.EE345230--