From nobody Fri Sep 2 05:51: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 548B612B00F for ; Fri, 2 Sep 2016 05:51:01 -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 zPWvUWM9Sw1K for ; Fri, 2 Sep 2016 05:50:58 -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 3440112D80F for ; Fri, 2 Sep 2016 05:50:57 -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 u82CoseM022472 for ; Fri, 2 Sep 2016 14:50:54 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9032020C36B for ; Fri, 2 Sep 2016 14:50:54 +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 86C2820C0D2 for ; Fri, 2 Sep 2016 14:50:54 +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 u82CosZR026763 for ; Fri, 2 Sep 2016 14:50:54 +0200 To: its@ietf.org References: <000001d203c3$75404ce0$5fc0e6a0$@pilotresearch.com> From: Alexandre Petrescu Message-ID: Date: Fri, 2 Sep 2016 14:50:54 +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: <000001d203c3$75404ce0$5fc0e6a0$@pilotresearch.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [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: Fri, 02 Sep 2016 12:51:02 -0000 Hi, Allow me to take advantage of the message on the list to reply publicly. Le 31/08/2016 à 22:08, Francois Simon a écrit : > 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 > > *Assigned Area Director* > > Suresh Krishnan > > *Mailing list* > > Address: ​its@ietf.org > To Subscribe: ​https://www.ietf.org/mailman/listinfo/its > > Archive: ​http://www.ietf.org/mail-archive/web/its/current/maillist.html > > Archive: ​https://mailarchive.ietf.org/arch/search/?email_list=its > > > *Additional web page* > > TBD > > *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. > > [Fygs: Safety applications may not always require bidirectional data > flows. i.e.; Most Safety applications using DSRCS use unidirectional > flow: source to sink.] I can agree that some if not all DSRC messages are unidirectional. I would like to add that realization of safety can happen (in addition to DSRC) through non-DSRC messages: Coyote messaging (vehicle-to-infra-to-vehicle) is using cellular links and it signals various safety-related events on the road. Other demonstrated IP-based bidirectional messaging is for safety too: video streaming from front to rear vehicle for see-through applications to prepare safe overcoming of a vehicle. So, I agree with you about DSRC unidirectionality, and I also think the above text should stay that way unless we have strong reason to change. > 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. > > > > 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. Some > > communications will be extremely short lived, but others will last for > > many hours or days. > > [Fygs: “…/between a vehicle, which is often comprise of moving > network…/”. 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. YEs, that's the intention: each vehicle is comprised of at least two distinct IP subnets (if not more), and there are at least 32 distinct IP addresses within each vehicle. > Within a vehicle moving in relation to the “outside world” (e.g.; > highway), may also contain moving devices requiring connectivity (in a > relatively limited space and communication range such as Bluetooth > device); or There are a few cases in scope: - vehicle moves with respect to RSU - vehicle following other vehicles, in a homogeneous manner - vehicle moves with respect to incoming or overcoming vehicles - user moves around stationary vehicle (remote door open) - vehicles moves around stationary user There are a few clarifications: - if both user and vehicle move then it's at relatively low speed (5kmph) - the road-side units are typically fixed while operated, although they may move during temporary road works. These characteristics of movement could be further described in a document. Would you be interested? > > Is it intended to imply that clusters of vehicles (“swarms”), 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 “rabbit whole” the group wants to be in.] We need to avoid rabbit holes, and ratholes. In MANET there is no clear number of hops between end nodes. In moving network-to-moving network communication of this group there are at most 3, with the innovative protocol changes happening on only 1-hop: between immediately neighboring vehicles. Each one of these moving networks has a stable fixed structure (there is little or no mobility _inside_ a vehicle while it moves). In MANET there is no such stability. We need to stay within this 1-hop protocol innovation, at most 3 hop in vehicle-to-vehicle (Host=Router-Router=Host). That would keep us from holes. > 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 – “/however, IPv6 on 802.11-)OCB is not yet defined/” > > 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. I agree. 'IPv6-on-80211OCB' text above is supposed to read like existing 'IPv6-on-Ethernet' text in other IETF documents. We heard 802.11p, then told 802.11p is no longer, so needed a name for this link-layer technology, so we proposed 802.11-OCB. I understand "802.11-OCB" is not an IEEE term like 802.11b is, but we who put IP on it need a short name for it. And 'OCB MIB attribute 802.11' is not a short name for a link layer. I am still interested to hear better names to replace '802.11p'? > 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.] I can agree. But here a specification means something we could freely give to an implementer and write open-source running code for it. The way IEEE talks about putting IPv6 on a network layer of DSRC is not something easy to implement. BEsides it's not freely and publicly available. > 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 group will coordinate with IEEE 802.11. 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. 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.] I can agree, there are demonstrations. At this time in this group there is no interest. > 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: > > - 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’s views but are likely to be changed by > tomorrow…. We could work together to make a proposal. > ITS: > > “/Intelligence/”: Can include anything from “human-hands-off” to > Artificial Intelligence (AI). Ah! > “/Transportation/”: It varies from invention of the wheel, to conveyor > belt, and would include skis and horse-and-buggy J….. Attempting a > definition change would be a waste of resources and unproductive. Let > it lie!] > > “/V2V/”: Has been historically associated with communications between > vehicles for Safety applications. Of course one can debate to infinitum > the definition of “vehicles” which could change every day. For the > purpose of this charter it is proposed and certainly can be modified by > the group as required: > > /“Vehicle-to-vehicle (V2V) communication enables intention sharing among > neighboring vehicles and thereby vehicles' motion can be coordinated to > incorporate collision (or conflict) avoidance”./Intelligent Vehicles > Symposium (IV), 2015 IEEE > > > /“V2I”/: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 > > /“V2X”/: Is a relatively new term. > > · 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: > > o V2P – Vehicle-to-Pedestrian > > o V2D – Vehicle-to-Device > > o V2G – Vehicle-to-Grid > > In any case, the following definition seems to be the consensus for now: > “/Vehicle-to-everything (*V2X*) communication is the passing of > information from a vehicle to any entity that may affect the vehicle, > and vice versa/”. It is a good point deserving expression in addition to others. > - 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 “real-time” 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.] Noted. Remark, this is the typical text we hear from many sources. If we analyze the text closely we see oranges compared to apples. If only we could do orange-orange. Keeping data payload size minimum - use reduced-size IP packets and avoid unnecessary headers. Protocol overhead size - what is it? Processing time - it's a matter of CPU, and typically the compute and communication capabilities available inside a car are huge. We talk Gbit Ethernet twisted-pair inside a car, whereas DSRC is only 16mbit/s outside the car. A vehicle 200km/h with 55m/s give no direct clue about the above requirements. One would have to say how many 50byte IP messages are possibly exchanged between two crossing vehicles during that time, at 7Gb/s (the bandwidth of 802.11ad in OCB mode). We dont know that. So it looks like apples compared to oranges. In no case could we say that IP is not adapted because too slow for 200km/h vehicles. Let's work to clarify these things in the Internet Drafts. Alex > > -- 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 > > *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 > > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Mon Sep 19 05:16:21 2016 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEB012B095; Mon, 19 Sep 2016 05:16:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147428737373.31218.9674519507533362881.idtracker@ietfa.amsl.com> Date: Mon, 19 Sep 2016 05:16:13 -0700 Archived-At: Cc: its@ietf.org, ipwave-chairs@ietf.org Subject: [its] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_charter-?= =?utf-8?q?ietf-ipwave-00-01=3A_=28with_COMMENT=29?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 12:16:14 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-ipwave-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipwave/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- To be honest, to me it's more clear from the charter what the wg will not do than what the will do, however that's okay. One question though: the charter says "This group will develop IP-based protocols...". Is it right to use the plural here? Will they work on multipe protocols or just one? From nobody Tue Sep 27 05:59:39 2016 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A5C12B151; Tue, 27 Sep 2016 05:59:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147498117737.20756.7813123375737308739.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 05:59:37 -0700 Archived-At: Cc: its@ietf.org, ipwave-chairs@ietf.org Subject: [its] Benoit Claise's No Objection on charter-ietf-ipwave-00-01: (with COMMENT) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 12:59:37 -0000 Benoit Claise has entered the following ballot position for charter-ietf-ipwave-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipwave/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- To forward the feedback I sent previously: "Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I, not to be mistaken with V2Internet) communications are still being developed." I read the charter multiple times, and I'm still not sure what the infrastructure is in V2I. A sentence or two with background would be useful. "Other SDOs interested in this work include ISO/TC204, ETSI TC ITS, 3GPP, and NHTSA." Sure, it's interesting to know but what is the message for the ipwave group? Liaison, coordination, something else? From nobody Tue Sep 27 14:15:22 2016 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D282126FDC; Tue, 27 Sep 2016 14:15:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147501092054.11772.10776384522920241988.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 14:15:20 -0700 Archived-At: Cc: its@ietf.org, ipwave-chairs@ietf.org Subject: [its] Kathleen Moriarty's No Objection on charter-ietf-ipwave-00-01: (with COMMENT) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 21:15:20 -0000 Kathleen Moriarty has entered the following ballot position for charter-ietf-ipwave-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipwave/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Benoit and Mirja, I had to read the charter a few times to get an idea of what this group might work on, but the milestones seem like high-level goals, so I think that is okay. From the text, the development of a protocol is not clear to me and I think it's because of the following two sentences: However, IPv6 on 802.11-OCB is not yet defined. The group will work only on IPv6 solutions. Then, you see that development of a draft for IPv6 on 802.11-OCB is a milestone. Could this be made more clear in the charter text? From nobody Tue Sep 27 16:17:00 2016 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6FF12B51C; Tue, 27 Sep 2016 16:16:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147501820041.11696.13481208167933670709.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 16:16:40 -0700 Archived-At: Cc: its@ietf.org, ipwave-chairs@ietf.org Subject: [its] Spencer Dawkins' Block on charter-ietf-ipwave-00-01: (with BLOCK) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 23:16:41 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-ipwave-00-01: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipwave/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- I was intrigued by "Without re-chartering, this group will not work on Delay-Tolerant Networking nor on Information-Centric Networking." For DTN - I wouldn't be a bit surprised to see IPWAVE *using* the DTN protocols, but do the IPWAVE people have a sense that what DTN is doing now is potentially useful, but not usable in its current form, so that IPWAVE would need to "work on" the protocols DTN is producing? If part of IPWAVE is a DTN application, that could be a good thing, but if DTN is producing a "close but not close enough for IPWAVE" protocol set, that would be great to know. For ICN - this is still in ICNRG, isn't it? But even if it comes to the IETF, I'd think ICN would be out of scope for IPWAVE to "work on", although (as with DTN) I could see IPWAVE *using* ICN protocols as they are standardized. Are you seeing people who want to work on these topics in the IPWAVE space now? If so, we should definitely talk! Maybe that conversation should happen during External Review, or maybe we should chat about it now? From nobody Wed Sep 28 08:18:30 2016 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B048E12B18B; Wed, 28 Sep 2016 08:18:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147507590867.16632.11178398820825580706.idtracker@ietfa.amsl.com> Date: Wed, 28 Sep 2016 08:18:28 -0700 Archived-At: Cc: its@ietf.org, ipwave-chairs@ietf.org Subject: [its] Alissa Cooper's Block on charter-ietf-ipwave-00-01: (with BLOCK and COMMENT) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 15:18:29 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-ipwave-00-01: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipwave/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- Further to Mirja, Kathleen, and Benoit's comments, I think this charter needs to more explicitly declare what work is in scope for the WG before the charter goes for external review. If I recall correctly the narrowing of the scope down to v6-over-802.11-OCB (as the initial deliverable) took several rounds of BoFs to achieve, and yet it still isn't clear from the charter if that is the only standards track deliverable expected from this WG before re-chartering, or if there is some wider space of standards track specs that fall within the current charter. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- What is a "general problem area"? Does this group really need both a problem area and a problem statement? Do they really both need to be RFCs, or will one or both serve their purpose as discussion documents for the WG that can be bookmarked in the I-D repository once the WG comes to consensus on them? From nobody Wed Sep 28 10:45:17 2016 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F9F12B1BC; Wed, 28 Sep 2016 10:45:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Alvaro Retana" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147508471237.16544.15417366537377981898.idtracker@ietfa.amsl.com> Date: Wed, 28 Sep 2016 10:45:12 -0700 Archived-At: Cc: its@ietf.org, ipwave-chairs@ietf.org Subject: [its] Alvaro Retana's Block on charter-ietf-ipwave-00-01: (with BLOCK) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 17:45:12 -0000 Alvaro Retana has entered the following ballot position for charter-ietf-ipwave-00-01: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipwave/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- My objection to this charter is not about the chartered work (as others have mentioned, and I agree with), but about the mention of potential future items: "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)." The mentioned "a 1-hop mechanism of IP prefix exchange between moving networks" and "an n-hop extension" sound too much like routing to me. A set of 1-hop connections can easily become n-hops... I understand the potential constraints in connection times that may exist in the applications, but other IETF work have similar constraints, also address moving network and general applicability such as “trains, air…”. For example, the manet WG also deals with applications that have similar requirements/constrains and applications. I would prefer if the expectation of future work is not part of this initial charter, and we deal with future items when/if the time comes. At that point we can figure if existing protocols or WGs meet the proper requirements or not. To be clear: I'm not objecting to the future work, but to setting the expectation without taking into account existing work and WGs. From nobody Wed Sep 28 14:39:44 2016 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E32127076; Wed, 28 Sep 2016 14:39:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147509878293.16652.7913087041437806161.idtracker@ietfa.amsl.com> Date: Wed, 28 Sep 2016 14:39:42 -0700 Archived-At: Cc: its@ietf.org, ipwave-chairs@ietf.org Subject: [its] Ben Campbell's Block on charter-ietf-ipwave-00-01: (with BLOCK and COMMENT) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 21:39:43 -0000 Ben Campbell has entered the following ballot position for charter-ietf-ipwave-00-01: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipwave/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- "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." If by "safety related messages", we are talking about use cases where life or property may be lost in failure cases, then I think this needs more clarity about the scope of such cases. I don't think "if necessary" is appropriate here; do we not already know what's necessary? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share the concerns others have mentioned regarding clarity of expected work items. - "This group will develop IP-based protocols to establish direct and secure connectivity between a vehicle, which is often comprised of moving networks..." s/comprised of/comprises - Does the group really expect to leverage technologies developed in t2trg? - Is the last paragraph needed? Any group can be rechartered. From nobody Wed Sep 28 14:39:56 2016 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB12127076; Wed, 28 Sep 2016 14:39:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147509878805.16586.9485855478540265582.idtracker@ietfa.amsl.com> Date: Wed, 28 Sep 2016 14:39:48 -0700 Archived-At: Cc: its@ietf.org, ipwave-chairs@ietf.org Subject: [its] Stephen Farrell's Yes on charter-ietf-ipwave-00-01: (with COMMENT) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 21:39:49 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-ipwave-00-01: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipwave/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think the charter ought also recognise the privacy sensitivity of potentially tracking people and their vehicles. So I'd suggest adding something like: "The WG will pay particular attention to the privacy characteristics of protocols it develops (or re-uses) in order to as far as possible ensure that IP in vehicles does not offer unwanted tracking opportunities." From nobody Wed Sep 28 15:57:32 2016 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 953B612B1E9; Wed, 28 Sep 2016 15:57:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Deborah Brungard" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147510344757.16696.12963727254991963773.idtracker@ietfa.amsl.com> Date: Wed, 28 Sep 2016 15:57:27 -0700 Archived-At: Cc: its@ietf.org, ipwave-chairs@ietf.org Subject: [its] Deborah Brungard's No Objection on charter-ietf-ipwave-00-01: (with COMMENT) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 22:57:27 -0000 Deborah Brungard has entered the following ballot position for charter-ietf-ipwave-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipwave/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Supportive of the work though as others mentioned, the description is quite vague. Agree with Alvaro, prefer future work not to be mentioned at this time as seems more appropriate for routing. The first paragraph was difficult to parse as appropriate for a charter (too commercial), the second paragraph seems to be a better start. >From the first paragraph, "safety applications using bidirectional data flows" seems to fit better with the later text on safety-related messages to describe what is needed. From nobody Thu Sep 29 04:04:16 2016 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6266512B4CB; Thu, 29 Sep 2016 04:04:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147514705436.18539.188905376493509826.idtracker@ietfa.amsl.com> Date: Thu, 29 Sep 2016 04:04:14 -0700 Archived-At: Cc: its@ietf.org, ipwave-chairs@ietf.org Subject: [its] Alissa Cooper's Yes on charter-ietf-ipwave-00-02: (with COMMENT) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 11:04:14 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-ipwave-00-02: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipwave/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Updated text is much improved, thanks. From nobody Thu Sep 29 06:15:07 2016 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D97412B0E2; Thu, 29 Sep 2016 06:15:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147515490547.18597.10607843680155826476.idtracker@ietfa.amsl.com> Date: Thu, 29 Sep 2016 06:15:05 -0700 Archived-At: Cc: its@ietf.org, ipwave-chairs@ietf.org Subject: [its] Spencer Dawkins' Yes on charter-ietf-ipwave-00-02: (with COMMENT) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 13:15:05 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-ipwave-00-02: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipwave/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the significant rework resulting in 00-02. I'm happy to ballot Yes on the result. The following might not have been clear in my previous BLOCK on 00-01, so let me try again :-) As the responsible AD for DTN, I am very interested in any thoughts the IPWAVE community has about the suitability of DTN's chartered work in the IPWAVE space, and welcome that conversation. My concern in my previous BLOCK was that the IPWAVE community might have already looked at DTN's chartered work and found it unsuited for deployments that will be based on IPWAVE. If that's happened, I'd love to hear more. If it hasn't happened, my apologies for misunderstanding. From nobody Thu Sep 29 06:56:49 2016 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7376012B105; Thu, 29 Sep 2016 06:56:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147515740745.18535.8778633613603491802.idtracker@ietfa.amsl.com> Date: Thu, 29 Sep 2016 06:56:47 -0700 Archived-At: Cc: its@ietf.org, ipwave-chairs@ietf.org Subject: [its] Ben Campbell's Yes on charter-ietf-ipwave-00-02: (with COMMENT) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 13:56:47 -0000 Ben Campbell has entered the following ballot position for charter-ietf-ipwave-00-02: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipwave/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the updates version. I think this one is better. From nobody Fri Sep 30 11:07:35 2016 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5536312B1C9; Fri, 30 Sep 2016 11:07:31 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147525885133.20369.17120514015353713406.idtracker@ietfa.amsl.com> Date: Fri, 30 Sep 2016 11:07:31 -0700 Archived-At: Cc: its@ietf.org Subject: [its] WG Review: IP Wireless Access in Vehicular Environments (ipwave) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.17 List-Id: ITS at IETF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2016 18:07:31 -0000 A new IETF WG has been proposed in the Internet Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2016-10-10. IP Wireless Access in Vehicular Environments (ipwave) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Suresh Krishnan Internet Area Directors: Terry Manderson Suresh Krishnan Mailing list: Address: its@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/its Archive: https://www.ietf.org/mail-archive/web/its/current/maillist.html Charter: https://datatracker.ietf.org/doc/charter-ietf-ipwave/ 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 an occupant's cellular smartphone: mirrorlink, carplay, android auto. Vehicle-to-Infrastructure (V2I, not to be mistaken with V2Internet) Communications are used for wireless exchange of critical safety and operational data between vehicles and roadway infrastructure, intended primarily to avoid motor vehicle crashes. Similarly, Vehicle-to-Vehicle Communications (V2V) are used for short-range communications between vehicles to exchange vehicle information such as vehicle speed, headng and braking status. However, V2V and V2I communications are still in the process of being developed. Some forms of vehicle and infrastructure communications will use IP and others will not. Thus, 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 and will develop an IPv6 based solution to establish direct and secure connectivity between a vehicle and other vehicles or stationary systems. V2V and V2I 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 Dedicated short-range communications (DSRC). Several of these link-layers already provide support for IPv6. However, IPv6 on 802.11-OCB is yet to be defined. This group's primary deliverable (and the only Standards track item) will be a document that will specify the mechanisms for transmission of IPv6 datagrams over IEEE 802.11p OCB mode. The group will work on an informational document that will explain the state of the art in the field and describe the use cases that will use IPv6 in order to focus the work of the group. The group will also work on informational document that describes the problem statement and the associated security and privacy considerations. The working group will decide at a future point whether these informational documents need to be published separately as RFCs or if they maybe combined. The group will try to reuse relevant technologies for Internet of Things (IoT) and infrastructure mobility that have been developed in other IETF and IRTF groups. The WG will pay particular attention to the privacy characteristics of solution it develops in order to minimize unwanted tracking opportunities. The group will closely coordinate with IEEE 802.11. The work produced by this group may be of interest to other SDOs such as ISO/TC204, ETSI TC ITS, 3GPP, and NHTSA. No formal co-ordination is anticipated with these groups at this point but work done in these SDOs may end up becoming relevant to the WG deliverables in the future. 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 From nobody Fri Sep 30 11:30: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 6E8AB12B1D0 for ; Fri, 30 Sep 2016 11:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 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, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y90YvpjaoHmT for ; Fri, 30 Sep 2016 11:30:52 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D31A12B0F4 for ; Fri, 30 Sep 2016 11:30:52 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id z126so111621596vkd.0 for ; Fri, 30 Sep 2016 11:30: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:cc; bh=GRjOQTJGqQUYUPClPI0FFwtuewLH08Veaisa+uayNnc=; b=O8bd+Lw2v2BDIB1mZwa99U5k0G2AFCdPU22roWOi5Dx9HijIk7mSxZhSZYI2HuFQWk 4FVVcTHbWmjBI39obFPk8MGnYbZ+kS7VNrM/soZPFGAHoQSBg0RnLNQZfn/8+ZTU3/Jw OapxXoASWm0BTlRGxXXGpZVHyo1/hKw1KPB6MxC4HFvMB4sAMRJdtwHB2zJ3TR+vZ+Hr 3LXOrId6GXYQPr+VS3zJqq0qs2dj0JiigolhjfJAQWhh339E8LhzBrGhQ8pK6x+oDHUD Y/gFZiwowyaJtdbWyDPa9LKhaHCxsULoeVi7aoJao/VPDNke43u6jBJNDwaWOxO1tRVF uB0Q== 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:cc; bh=GRjOQTJGqQUYUPClPI0FFwtuewLH08Veaisa+uayNnc=; b=evYmLNz42kv8b162Yr8NnXDIMkM2hPjFULYjS5J8mb91RYuwk+aO0TS69BH8H8lC76 d3Il3j9m5wnqysRygxiKHgWXgwwW8GfjqBc7QZkM/Is5NCNoNgHBJ2btPiPE7QI2kUnI POlJa7X1ok2AF512wiKFfHwFbOaR8QGLfPnWm0fDkHZVemmKDw75X96kP965y8LbNU7P re2tJnwebYDZvVsmVZHl7nOXUVmPpsHntjQQDwCUXLGauiH6QBliG9vyfgmipK9J/DZn vzpcK9nzwiAOYqNVL2zhS1Ww4nrEZA3cUBiOar6swdpJDYrtBCaDxGr3rajNMCjmfQAg 9VdA== X-Gm-Message-State: AA6/9Rkcuqfb3i5pho9cffECKLYrMmSL14hieMmNmnjUKFrY5z4Z6+P476BbhnAgv1LA7RQOtLSn9oUeozgWhQ== X-Received: by 10.31.73.71 with SMTP id w68mr5488343vka.13.1475260251351; Fri, 30 Sep 2016 11:30:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.85.30 with HTTP; Fri, 30 Sep 2016 11:30:50 -0700 (PDT) In-Reply-To: <147525885133.20369.17120514015353713406.idtracker@ietfa.amsl.com> References: <147525885133.20369.17120514015353713406.idtracker@ietfa.amsl.com> From: Behcet Sarikaya Date: Fri, 30 Sep 2016 13:30:50 -0500 Message-ID: Cc: its@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [its] WG Review: IP Wireless Access in Vehicular Environments (ipwave) 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: Fri, 30 Sep 2016 18:30:54 -0000 Thanks to IESG for changing the name ITS. Regards, Behcet On Fri, Sep 30, 2016 at 1:07 PM, The IESG wrote: > A new IETF WG has been proposed in the Internet Area. The IESG has not > made any determination yet. The following draft charter was submitted, > and is provided for informational purposes only. Please send your > comments to the IESG mailing list (iesg@ietf.org) by 2016-10-10. > > IP Wireless Access in Vehicular Environments (ipwave) > ----------------------------------------------------------------------- > Current status: Proposed WG > > Chairs: > TBD > > Assigned Area Director: > Suresh Krishnan > > Internet Area Directors: > Terry Manderson > Suresh Krishnan > > Mailing list: > Address: its@ietf.org > To subscribe: https://www.ietf.org/mailman/listinfo/its > Archive: > https://www.ietf.org/mail-archive/web/its/current/maillist.html > > Charter: https://datatracker.ietf.org/doc/charter-ietf-ipwave/ > > 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 an > occupant's cellular smartphone: mirrorlink, carplay, android > auto. Vehicle-to-Infrastructure (V2I, not to be mistaken with > V2Internet) Communications are used for wireless exchange of critical > safety and operational data between vehicles and roadway > infrastructure, intended primarily to avoid motor vehicle > crashes. Similarly, Vehicle-to-Vehicle Communications (V2V) are used > for short-range communications between vehicles to exchange vehicle > information such as vehicle speed, headng and braking status. However, > V2V and V2I communications are still in the process of being > developed. > > Some forms of vehicle and infrastructure communications will use IP > and others will not. Thus, 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 and will develop an > IPv6 based solution to establish direct and secure connectivity > between a vehicle and other vehicles or stationary systems. > > V2V and V2I 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 > Dedicated short-range communications (DSRC). Several of these > link-layers already provide support for IPv6. However, IPv6 on > 802.11-OCB is yet to be defined. > > This group's primary deliverable (and the only Standards track item) > will be a document that will specify the mechanisms for transmission > of IPv6 datagrams over IEEE 802.11p OCB mode. The group will work on > an informational document that will explain the state of the art in > the field and describe the use cases that will use IPv6 in order to > focus the work of the group. The group will also work on informational > document that describes the problem statement and the associated > security and privacy considerations. The working group will decide at > a future point whether these informational documents need to be > published separately as RFCs or if they maybe combined. > > The group will try to reuse relevant technologies for Internet of > Things (IoT) and infrastructure mobility that have been developed in > other IETF and IRTF groups. The WG will pay particular attention to > the privacy characteristics of solution it develops in order to > minimize unwanted tracking opportunities. The group will closely > coordinate with IEEE 802.11. The work produced by this group may be of > interest to other SDOs such as ISO/TC204, ETSI TC ITS, 3GPP, and > NHTSA. No formal co-ordination is anticipated with these groups at > this point but work done in these SDOs may end up becoming relevant to > the WG deliverables in the future. > > 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 > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Fri Sep 30 12:21:49 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 C51C712B1B8 for ; Fri, 30 Sep 2016 12:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uug5Nx7VHTYX for ; Fri, 30 Sep 2016 12:21:45 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9765012B13F for ; Fri, 30 Sep 2016 12:21:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 004A7300A2D for ; Fri, 30 Sep 2016 15:21:44 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iXWVXLlsVekD for ; Fri, 30 Sep 2016 15:21:43 -0400 (EDT) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 55A09300525 for ; Fri, 30 Sep 2016 15:21:43 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <147525885133.20369.17120514015353713406.idtracker@ietfa.amsl.com> Date: Fri, 30 Sep 2016 15:21:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1AB7FD67-0A90-468D-B179-1FD83DE2B65A@vigilsec.com> References: <147525885133.20369.17120514015353713406.idtracker@ietfa.amsl.com> To: its@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [its] WG Review: IP Wireless Access in Vehicular Environments (ipwave) 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, 30 Sep 2016 19:21:48 -0000 The IESG is proposing to move forward with a scope of work that this = narrower than the draft charter proposed by this group. If this is a = concern to you, please send comments to the IESG mailing list = (iesg@ietf.org) by 2016-10-10. Similarly, if you support this more = narrow charter, please send comments to the IESG mailing list = (iesg@ietf.org) by 2016-10-10. Russ On Sep 30, 2016, at 2:07 PM, The IESG wrote: > A new IETF WG has been proposed in the Internet Area. The IESG has not > made any determination yet. The following draft charter was submitted, > and is provided for informational purposes only. Please send your > comments to the IESG mailing list (iesg@ietf.org) by 2016-10-10. >=20 > IP Wireless Access in Vehicular Environments (ipwave) > = ----------------------------------------------------------------------- > Current status: Proposed WG >=20 > Chairs: > TBD >=20 > Assigned Area Director: > Suresh Krishnan >=20 > Internet Area Directors: > Terry Manderson > Suresh Krishnan >=20 > Mailing list: > Address: its@ietf.org > To subscribe: https://www.ietf.org/mailman/listinfo/its > Archive: > https://www.ietf.org/mail-archive/web/its/current/maillist.html >=20 > Charter: https://datatracker.ietf.org/doc/charter-ietf-ipwave/ >=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. >=20 > Today, there are several deployed Vehicle-to-Internet technologies > (V2Internet) that make use of embedded Internet modules, or an > occupant's cellular smartphone: mirrorlink, carplay, android > auto. Vehicle-to-Infrastructure (V2I, not to be mistaken with > V2Internet) Communications are used for wireless exchange of critical > safety and operational data between vehicles and roadway > infrastructure, intended primarily to avoid motor vehicle > crashes. Similarly, Vehicle-to-Vehicle Communications (V2V) are used > for short-range communications between vehicles to exchange vehicle > information such as vehicle speed, headng and braking status. However, > V2V and V2I communications are still in the process of being > developed. >=20 > Some forms of vehicle and infrastructure communications will use IP > and others will not. Thus, 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 and will develop an > IPv6 based solution to establish direct and secure connectivity > between a vehicle and other vehicles or stationary systems. >=20 > V2V and V2I 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 > Dedicated short-range communications (DSRC). Several of these > link-layers already provide support for IPv6. However, IPv6 on > 802.11-OCB is yet to be defined. >=20 > This group's primary deliverable (and the only Standards track item) > will be a document that will specify the mechanisms for transmission > of IPv6 datagrams over IEEE 802.11p OCB mode. The group will work on > an informational document that will explain the state of the art in > the field and describe the use cases that will use IPv6 in order to > focus the work of the group. The group will also work on informational > document that describes the problem statement and the associated > security and privacy considerations. The working group will decide at > a future point whether these informational documents need to be > published separately as RFCs or if they maybe combined. >=20 > The group will try to reuse relevant technologies for Internet of > Things (IoT) and infrastructure mobility that have been developed in > other IETF and IRTF groups. The WG will pay particular attention to > the privacy characteristics of solution it develops in order to > minimize unwanted tracking opportunities. The group will closely > coordinate with IEEE 802.11. The work produced by this group may be of > interest to other SDOs such as ISO/TC204, ETSI TC ITS, 3GPP, and > NHTSA. No formal co-ordination is anticipated with these groups at > this point but work done in these SDOs may end up becoming relevant to > the WG deliverables in the future. >=20 > 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 >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Fri Sep 30 19:28: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 AA98912B1A4 for ; Fri, 30 Sep 2016 19:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZKriUNVGK8y for ; Fri, 30 Sep 2016 19:27:59 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 53BBF12B1A1 for ; Fri, 30 Sep 2016 19:27:59 -0700 (PDT) X-AuditID: c618062d-743ff700000009b8-db-57ef21bfbc22 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by (Symantec Mail Security) with SMTP id FF.D6.02488.FB12FE75; Sat, 1 Oct 2016 04:38:58 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0301.000; Fri, 30 Sep 2016 22:27:55 -0400 From: Suresh Krishnan To: "its@ietf.org" Thread-Topic: WG Review: IP Wireless Access in Vehicular Environments (ipwave) Thread-Index: AQHSG0WRCp18Y9NShEC1ZQIFbK0Ulg== Date: Sat, 1 Oct 2016 02:27:54 +0000 Message-ID: References: <147525885133.20369.17120514015353713406.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyuXRPoO4hxffhBrP+WlhcnP+OxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGY8vPmAteKZdcaD5J2sD4yqVLkZODgkBE4kjey4zdzFycQgJ bGCUuLC+hwnCWc4osefUUhaQKjagqg07PzOB2CICihJb1vexg9jCAr4SfxftZYaIB0gsPHGG EcLWk3gwbxFYPYuAisSOx/+Bajg4eIHqG5eFgYSFBPwkjh2dAzaGUUBM4vupNWDlzALiEree zGeCOE5AYsme88wQtqjEy8f/WCFsJYk5r68xQ9TrSCzY/YkNwtaWWLbwNVicV0BQ4uTMJywT GIVnIRk7C0nLLCQts5C0LGBkWcXIUVpckJObbmSwiREYyMck2HR3MN6f7nmIUYCDUYmH90H+ u3Ah1sSy4srcQ4wSHMxKIrwZMu/DhXhTEiurUovy44tKc1KLDzFKc7AoifPGrb4fLiSQnliS mp2aWpBaBJNl4uCUamA8oPTyZZcH1x/16usnJ/66Pmt7lUGRn7yP9bLW/fP41rF1ls9/U/nH ZW10WFSr6IUNkQwSrV+ORt/6W2uyJK9zrULayl898l6MvQ4CcwX8qyqe/hSLdshYc1B5tYLc +ifJWT8YrLbu9mdxsPg2syi4Pfai9rqDOQG/S05Krr/3WK/ALGVhIpMSS3FGoqEWc1FxIgBr ezhrYAIAAA== Archived-At: Subject: Re: [its] WG Review: IP Wireless Access in Vehicular Environments (ipwave) 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: Sat, 01 Oct 2016 02:28:02 -0000 Hi all,=0A= If you have any questions or comments about this charter that was =0A= approved after IESG internal review, please feel free to send a note to the= =0A= IESG list before October 10. We will be discussing any comments that are = =0A= received on the October 13th telechat and try to get the WG formed right af= ter.=0A= =0A= Thanks=0A= Suresh=0A= =0A= On 09/30/2016 02:07 PM, The IESG wrote:=0A= > A new IETF WG has been proposed in the Internet Area. The IESG has not=0A= > made any determination yet. The following draft charter was submitted,=0A= > and is provided for informational purposes only. Please send your=0A= > comments to the IESG mailing list (iesg@ietf.org) by 2016-10-10.=0A= >=0A= > IP Wireless Access in Vehicular Environments (ipwave)=0A= > -----------------------------------------------------------------------= =0A= > Current status: Proposed WG=0A= >=0A= > Chairs:=0A= > TBD=0A= >=0A= > Assigned Area Director:=0A= > Suresh Krishnan =0A= >=0A= > Internet Area Directors:=0A= > Terry Manderson =0A= > Suresh Krishnan =0A= >=0A= > Mailing list:=0A= > Address: its@ietf.org=0A= > To subscribe: https://www.ietf.org/mailman/listinfo/its=0A= > Archive:=0A= > https://www.ietf.org/mail-archive/web/its/current/maillist.html=0A= >=0A= > Charter: https://datatracker.ietf.org/doc/charter-ietf-ipwave/=0A= >=0A= > Automobiles and vehicles of all types are increasingly connected to=0A= > the Internet. Comfort-enhancing entertainment applications, road=0A= > safety applications using bidirectional data flows, and connected=0A= > automated driving are but a few new features expected in automobiles=0A= > to hit the roads from now to year 2020.=0A= >=0A= > Today, there are several deployed Vehicle-to-Internet technologies=0A= > (V2Internet) that make use of embedded Internet modules, or an=0A= > occupant's cellular smartphone: mirrorlink, carplay, android=0A= > auto. Vehicle-to-Infrastructure (V2I, not to be mistaken with=0A= > V2Internet) Communications are used for wireless exchange of critical=0A= > safety and operational data between vehicles and roadway=0A= > infrastructure, intended primarily to avoid motor vehicle=0A= > crashes. Similarly, Vehicle-to-Vehicle Communications (V2V) are used=0A= > for short-range communications between vehicles to exchange vehicle=0A= > information such as vehicle speed, headng and braking status. However,=0A= > V2V and V2I communications are still in the process of being=0A= > developed.=0A= >=0A= > Some forms of vehicle and infrastructure communications will use IP=0A= > and others will not. Thus, multiple applications need to share one=0A= > data link, including non-IP-based protocols sharing the data link with=0A= > IP-based protocols. This group will work on V2V and V2I use-cases=0A= > where IP is well-suited as a networking technology and will develop an=0A= > IPv6 based solution to establish direct and secure connectivity=0A= > between a vehicle and other vehicles or stationary systems.=0A= >=0A= > V2V and V2I communications may involve various kinds of link layers:=0A= > 802.11-OCB (Outside the Context of a Basic Service Set, also called=0A= > 802.11p), 802.15.4 with 6lowpan, 802.11ad, VLC (Visible Light=0A= > Communications), IrDA, LTE-D, LP-WAN. One of the most used link=0A= > layers for vehicular networks is IEEE 802.11-OCB, as a basis for=0A= > Dedicated short-range communications (DSRC). Several of these=0A= > link-layers already provide support for IPv6. However, IPv6 on=0A= > 802.11-OCB is yet to be defined.=0A= >=0A= > This group's primary deliverable (and the only Standards track item)=0A= > will be a document that will specify the mechanisms for transmission=0A= > of IPv6 datagrams over IEEE 802.11p OCB mode. The group will work on=0A= > an informational document that will explain the state of the art in=0A= > the field and describe the use cases that will use IPv6 in order to=0A= > focus the work of the group. The group will also work on informational=0A= > document that describes the problem statement and the associated=0A= > security and privacy considerations. The working group will decide at=0A= > a future point whether these informational documents need to be=0A= > published separately as RFCs or if they maybe combined.=0A= >=0A= > The group will try to reuse relevant technologies for Internet of=0A= > Things (IoT) and infrastructure mobility that have been developed in=0A= > other IETF and IRTF groups. The WG will pay particular attention to=0A= > the privacy characteristics of solution it develops in order to=0A= > minimize unwanted tracking opportunities. The group will closely=0A= > coordinate with IEEE 802.11. The work produced by this group may be of=0A= > interest to other SDOs such as ISO/TC204, ETSI TC ITS, 3GPP, and=0A= > NHTSA. No formal co-ordination is anticipated with these groups at=0A= > this point but work done in these SDOs may end up becoming relevant to=0A= > the WG deliverables in the future.=0A= >=0A= > Milestones:=0A= > Oct 2016 - Draft for "IPv6 over 802.11-OCB" adopted by WG=0A= > Dec 2016 - Draft for "ITS General Problem Area" adopted by WG=0A= > Mar 2017 - Draft for "Problem Statement" adopted by WG=0A= > May 2017 - Submit "IPv6 over 802.11-OCB" to IESG=0A= > Oct 2017 - Submit "ITS General Problem Area" to IESG=0A= > May 2018 - Submit "Problem Statement" to IESG=0A= >=0A= >=0A= >=0A= =0A= From nobody Fri Sep 30 23:18:25 2016 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADC112B04D for ; Fri, 30 Sep 2016 23:18:23 -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 qoDY6BTzcFl8 for ; Fri, 30 Sep 2016 23:18:20 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 3E42112B054 for ; Fri, 30 Sep 2016 23:18:20 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id n189so52369406qke.0 for ; Fri, 30 Sep 2016 23:18:20 -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=kBjBYXE2yxiT+/U/ppLGFJzhMuwoF+yoyAYYA5b8v1w=; b=oVHxpEjKDAc5Ob72I8aKz1wHTK8QotfRqpntRJmtCmhygxKbj5eyfUyFXm5udOHR7q ENgCk6BQnHS1GMKGHTOhN8pNSWM2ca/aQToPXB9n/Ge335pu8kFqM4Au2SHQO52r9mYw fYt85TnOpgpyvipOI2zfG6FapvLlLYBp9OP/nYWlEncAj7TXZpNGfAORsGSaFmOG0eII jjmg7yJJqB7toDRWBeUU/uwM70tZNa3QqU+VEuF2h3VXvU6Iz7xXNj5NVCoCbt5mLvoh OnMdC2FEeTMgNBgzDfMVvQvQBRky3+GB012sc6urMd4gbHu8G+FGwPJBxbqooacEh+9m +RVw== 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=kBjBYXE2yxiT+/U/ppLGFJzhMuwoF+yoyAYYA5b8v1w=; b=Ui6J4pki3ldJyQMC/DiVoovwrWBravpCSjwuZOmzB17067H1Txlz0/+6KLCSpwk1Oy 5kRS9sg/4qleK2aBAzEE/C7l7c7lMttA3B+aoYUVcC/9L7Et6D6XW2+6wzzcMEWn0Oji +DzcdSwWfuYgmuauTws7oFRSy50a7fJ699sNtSKkxCTyLUimiGhPe1ngJW+Ah0hTAxLZ ze/ExFcZpMGVfwErTgG1fGZd/Vo62HpTTIa6S45eCRG20DeD2CdnKj16YQ7mW+Qhf4fp uiQ5JbfMREcPtxw3X9XbrAMpLYWiKnqQ7SEpalrmhZKLI9U/IzJ31HR16vPdR9tFcGkQ eObQ== X-Gm-Message-State: AA6/9RmDkiq1vKAYFli947ot0+MXiP1vRt8NrJ/aph29WP4q+ukUg7XENvf+R/Dsu71npzdou8jA6+je7JJlkQ== X-Received: by 10.55.26.87 with SMTP id a84mr10220577qka.187.1475302699410; Fri, 30 Sep 2016 23:18:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.21 with HTTP; Fri, 30 Sep 2016 23:18:18 -0700 (PDT) In-Reply-To: References: <147525885133.20369.17120514015353713406.idtracker@ietfa.amsl.com> From: Abdussalam Baryun Date: Sat, 1 Oct 2016 08:18:18 +0200 Message-ID: To: Suresh Krishnan Content-Type: multipart/alternative; boundary=001a1146838055ad8e053dc7ad27 Archived-At: Cc: "its@ietf.org" Subject: Re: [its] WG Review: IP Wireless Access in Vehicular Environments (ipwave) 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: Sat, 01 Oct 2016 06:18:23 -0000 --001a1146838055ad8e053dc7ad27 Content-Type: text/plain; charset=UTF-8 Hi Suresh, is there possibility that the wg can meet in ietf97? Best regards AB On Sat, Oct 1, 2016 at 4:27 AM, Suresh Krishnan < suresh.krishnan@ericsson.com> wrote: > Hi all, > If you have any questions or comments about this charter that was > approved after IESG internal review, please feel free to send a note to the > IESG list before October 10. We will be discussing any comments that are > received on the October 13th telechat and try to get the WG formed right > after. > > Thanks > Suresh > > On 09/30/2016 02:07 PM, The IESG wrote: > > A new IETF WG has been proposed in the Internet Area. The IESG has not > > made any determination yet. The following draft charter was submitted, > > and is provided for informational purposes only. Please send your > > comments to the IESG mailing list (iesg@ietf.org) by 2016-10-10. > > > > IP Wireless Access in Vehicular Environments (ipwave) > > ----------------------------------------------------------------------- > > Current status: Proposed WG > > > > Chairs: > > TBD > > > > Assigned Area Director: > > Suresh Krishnan > > > > Internet Area Directors: > > Terry Manderson > > Suresh Krishnan > > > > Mailing list: > > Address: its@ietf.org > > To subscribe: https://www.ietf.org/mailman/listinfo/its > > Archive: > > https://www.ietf.org/mail-archive/web/its/current/maillist.html > > > > Charter: https://datatracker.ietf.org/doc/charter-ietf-ipwave/ > > > > 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 an > > occupant's cellular smartphone: mirrorlink, carplay, android > > auto. Vehicle-to-Infrastructure (V2I, not to be mistaken with > > V2Internet) Communications are used for wireless exchange of critical > > safety and operational data between vehicles and roadway > > infrastructure, intended primarily to avoid motor vehicle > > crashes. Similarly, Vehicle-to-Vehicle Communications (V2V) are used > > for short-range communications between vehicles to exchange vehicle > > information such as vehicle speed, headng and braking status. However, > > V2V and V2I communications are still in the process of being > > developed. > > > > Some forms of vehicle and infrastructure communications will use IP > > and others will not. Thus, 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 and will develop an > > IPv6 based solution to establish direct and secure connectivity > > between a vehicle and other vehicles or stationary systems. > > > > V2V and V2I 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 > > Dedicated short-range communications (DSRC). Several of these > > link-layers already provide support for IPv6. However, IPv6 on > > 802.11-OCB is yet to be defined. > > > > This group's primary deliverable (and the only Standards track item) > > will be a document that will specify the mechanisms for transmission > > of IPv6 datagrams over IEEE 802.11p OCB mode. The group will work on > > an informational document that will explain the state of the art in > > the field and describe the use cases that will use IPv6 in order to > > focus the work of the group. The group will also work on informational > > document that describes the problem statement and the associated > > security and privacy considerations. The working group will decide at > > a future point whether these informational documents need to be > > published separately as RFCs or if they maybe combined. > > > > The group will try to reuse relevant technologies for Internet of > > Things (IoT) and infrastructure mobility that have been developed in > > other IETF and IRTF groups. The WG will pay particular attention to > > the privacy characteristics of solution it develops in order to > > minimize unwanted tracking opportunities. The group will closely > > coordinate with IEEE 802.11. The work produced by this group may be of > > interest to other SDOs such as ISO/TC204, ETSI TC ITS, 3GPP, and > > NHTSA. No formal co-ordination is anticipated with these groups at > > this point but work done in these SDOs may end up becoming relevant to > > the WG deliverables in the future. > > > > 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 > > > > > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --001a1146838055ad8e053dc7ad27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Suresh,

is there possibil= ity that the wg can meet in ietf97?

Best regards
AB

On Sat, Oct 1, 2016 at 4:27 AM, Suresh Krishnan <= ;suresh.k= rishnan@ericsson.com> wrote:
Suresh

On 09/30/2016 02:07 PM, The IESG wrote:
> A new IETF WG has been proposed in the Internet Area. The IESG has not=
> made any determination yet. The following draft charter was submitted,=
> and is provided for informational purposes only. Please send your
> comments to the IESG mailing list (ie= sg@ietf.org) by 2016-10-10.
>
> IP Wireless Access in Vehicular Environments (ipwave)
> ------------------------------------------------------------= -----------
> Current status: Proposed WG
>
> Chairs:
>=C2=A0 =C2=A0TBD
>
> Assigned Area Director:
>=C2=A0 =C2=A0Suresh Krishnan <suresh.krishnan@ericsson.com>
>
> Internet Area Directors:
>=C2=A0 =C2=A0Terry Manderson <terry.manderson@icann.org>
>=C2=A0 =C2=A0Suresh Krishnan <suresh.krishnan@ericsson.com>
>
> Mailing list:
>=C2=A0 =C2=A0Address: its@ietf.org<= br> >=C2=A0 =C2=A0To subscribe: https://www.ietf.org/mailman= /listinfo/its
>=C2=A0 =C2=A0Archive:
> https://www.ietf.org/mail-a= rchive/web/its/current/maillist.html
>
> Charter: https://datatracker.ietf.org/doc/charter-ietf-ipwave/
>
> 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.
>
> Today, there are several deployed Vehicle-to-Internet technologies
> (V2Internet) that make use of embedded Internet modules, or an
> occupant's cellular smartphone: mirrorlink, carplay, android
> auto. Vehicle-to-Infrastructure (V2I, not to be mistaken with
> V2Internet) Communications are used for wireless exchange of critical<= br> > safety and operational data between vehicles and roadway
> infrastructure, intended primarily to avoid motor vehicle
> crashes. Similarly, Vehicle-to-Vehicle Communications (V2V) are used > for short-range communications between vehicles to exchange vehicle > information such as vehicle speed, headng and braking status. However,=
> V2V and V2I communications are still in the process of being
> developed.
>
> Some forms of vehicle and infrastructure communications will use IP > and others will not.=C2=A0 Thus, multiple applications need to share o= ne
> 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 and will develop an=
> IPv6 based solution to establish direct and secure connectivity
> between a vehicle and other vehicles or stationary systems.
>
> V2V and V2I 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<= br> > layers for vehicular networks is IEEE 802.11-OCB, as a basis for
> Dedicated short-range communications (DSRC). Several of these
> link-layers already provide support for IPv6. However, IPv6 on
> 802.11-OCB is yet to be defined.
>
> This group's primary deliverable (and the only Standards track ite= m)
> will be a document that will specify the mechanisms for transmission > of IPv6 datagrams over IEEE 802.11p OCB mode. The group will work on > an informational document that will explain the state of the art in > the field and describe the use cases that will use IPv6 in order to > focus the work of the group. The group will also work on informational=
> document that describes the problem statement and the associated
> security and privacy considerations. The working group will decide at<= br> > a future point whether these informational documents need to be
> published separately as RFCs or if they maybe combined.
>
> The group will try to reuse relevant technologies for Internet of
> Things (IoT) and infrastructure mobility that have been developed in > other IETF and IRTF groups. The WG will pay particular attention to > the privacy characteristics of solution it develops in order to
> minimize unwanted tracking opportunities. The group will closely
> coordinate with IEEE 802.11. The work produced by this group may be of=
> interest to other SDOs such as ISO/TC204, ETSI TC ITS, 3GPP, and
> NHTSA. No formal co-ordination is anticipated with these groups at
> this point but work done in these SDOs may end up becoming relevant to=
> the WG deliverables in the future.
>
> Milestones:
>=C2=A0 =C2=A0Oct 2016 - Draft for "IPv6 over 802.11-OCB" adop= ted by WG
>=C2=A0 =C2=A0Dec 2016 - Draft for "ITS General Problem Area" = adopted by WG
>=C2=A0 =C2=A0Mar 2017 - Draft for "Problem Statement" adopted= by WG
>=C2=A0 =C2=A0May 2017 - Submit "IPv6 over 802.11-OCB" to IESG=
>=C2=A0 =C2=A0Oct 2017 - Submit "ITS General Problem Area" to = IESG
>=C2=A0 =C2=A0May 2018 - Submit "Problem Statement" to IESG >
>
>


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

--001a1146838055ad8e053dc7ad27-- From nobody Fri Sep 30 23:22:22 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 7FECB12B0A9 for ; Fri, 30 Sep 2016 23:22:20 -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 jrD-amE4XbQh for ; Fri, 30 Sep 2016 23:22:19 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0061912B092 for ; Fri, 30 Sep 2016 23:22:18 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id z190so125542636qkc.3 for ; Fri, 30 Sep 2016 23:22:18 -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=1SCvL5AFMh2iTaaEeNr8PQIysQU+vUuCpqw4NmwygoY=; b=fUut76Gjkvp1xX0u5GnVuAQ+tzlfhgHj5dsCPpz5HbWML/7MniVALJxJHNRRvpYWeT 8q/TNne/RctVImerQXWJPFEi6p5TAd0RFwa7eB/x5FAhAhoUUIi2D8DTv0JS1TFitcRu UWxtZQsXX0fqe5gEDX/KaFUKQs0R+rDtXTFZZ7jdrhbFRU7CbcgWPAcr0XJX/blvDhaf BoDT808fTz4YRrsEXfLli1wRAoT5sXw83ftQEqG/8YHRqjugJEnQPJv/aokCp9k3MO2Q 6C+rVWRssXzM9u5JQLiUqVJwrK3OXPbDRaPchX+PLBuWIFeZDrymNTjCGK9j3U3MWnND wGcQ== 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=1SCvL5AFMh2iTaaEeNr8PQIysQU+vUuCpqw4NmwygoY=; b=iBi3MU8SxtCnY4DjY7WFztFZHPNiipWRkmV0hAdr7l2H72JsERoY5IgQKHydOcOrW/ +u9uXaeyWM1hgc2/Gq9W1cgODa450jg3jFhhSwgrdiB2AnzrOkYr0OGJj7HcoeW9Pkn/ PFUvb8kxpUyWXbi7BYkChiv8oOKXKm4iKyzA9P+PHfPFuIve5imQfikaQUUcNZyJTaKs Z3bMJXkriV+QyJ9s+fiyenhd9fuehZEbsJQYYYLcND4ZtZedfeVCdsHtBvaJpfXP23I2 CKORTxx4nPq3VBEB11WislRXApNz4fskE06hFh9Hi5cJ8hR6gbqyyFMQSmTnAKiPreGp mb5A== X-Gm-Message-State: AA6/9Rm/Hp1eXdtwkyIagaErOhpjTXl4U84lzpeQf/SDQsPMGTKtoNXXVTrjI+2yHVKaZsiG8JGkTU/S5M7G4g== X-Received: by 10.55.129.71 with SMTP id c68mr11735141qkd.189.1475302938222; Fri, 30 Sep 2016 23:22:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.21 with HTTP; Fri, 30 Sep 2016 23:22:17 -0700 (PDT) In-Reply-To: References: <147525885133.20369.17120514015353713406.idtracker@ietfa.amsl.com> From: Abdussalam Baryun Date: Sat, 1 Oct 2016 08:22:17 +0200 Message-ID: To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=94eb2c06266a91a63c053dc7bb22 Archived-At: Cc: its Subject: Re: [its] WG Review: IP Wireless Access in Vehicular Environments (ipwave) 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: Sat, 01 Oct 2016 06:22:20 -0000 --94eb2c06266a91a63c053dc7bb22 Content-Type: text/plain; charset=UTF-8 Even if iesg and ietf calls the ITS as ipwave, still others around the world may still name it ITS. Therefore, we need to make the definition clear that they are the same so others know what we are talking about otherwise we may not be able to communicate with others, AB On Fri, Sep 30, 2016 at 8:30 PM, Behcet Sarikaya wrote: > Thanks to IESG for changing the name ITS. > > Regards, > > Behcet > > > --94eb2c06266a91a63c053dc7bb22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Even if iesg and ietf calls the ITS as ipwave, still = others around the world may still name it ITS. Therefore, we need to make t= he definition clear that they are the same so others know what we are talki= ng about otherwise we may not be able to communicate with others,

AB

On Fri, Sep 30, 2016 at 8:30 PM, Behcet Sarikaya <sarikaya= 2012@gmail.com> wrote:
=C2=A0Thanks to IE= SG for changing the name ITS.

Regards,

Behcet



--94eb2c06266a91a63c053dc7bb22--