From nobody Mon Jun 16 05:28:09 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5ACD1A0004 for ; Mon, 16 Jun 2014 05:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.084 X-Spam-Level: X-Spam-Status: No, score=-3.084 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDW8aRh9ncaS for ; Mon, 16 Jun 2014 05:27: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 9FC611A0009 for ; Mon, 16 Jun 2014 05:27:57 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s5GCRsix009922 for ; Mon, 16 Jun 2014 14:27:54 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5021D206087 for ; Mon, 16 Jun 2014 14:29:38 +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 EFD172060B3 for ; Mon, 16 Jun 2014 14:29:37 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s5GCReX2019011 for ; Mon, 16 Jun 2014 14:27:53 +0200 Message-ID: <539EE2BC.4070906@gmail.com> Date: Mon, 16 Jun 2014 14:27:40 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/fmksX0vWndbB0l2V0HJ_Uz4MiQM Subject: [geonet/its] Announcing draft-karagiannis-geonet-problem-statement-00 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 12:28:03 -0000 Hello GeoNetters, We are pleased to announce the submission of draft-karagiannis-geonet-problem-statement-00 http://tools.ietf.org/html/draft-karagiannis-geonet-problem-statement-00 It is a brand new draft whose contents further refines the Problem Statement for GeoNet. It results from discussions in London, and all other private discussions since January 2014. It will soon be followed by some use-case drafts. Please comment on this Problem Statement draft. Alex From nobody Thu Jun 19 07:07:14 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB281A03A8 for ; Thu, 19 Jun 2014 07:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.443 X-Spam-Level: * X-Spam-Status: No, score=1.443 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1E7TC58dHek for ; Thu, 19 Jun 2014 07:07:01 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 198971A03C0 for ; Thu, 19 Jun 2014 07:06:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,507,1400018400"; d="scan'208";a="27227451" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 19 Jun 2014 16:06:55 +0200 Received: from EXC-MBX02.tsn.tno.nl ([fe80::5836:4645:c512:f964]) by EXC-CASHUB03.tsn.tno.nl ([fe80::6d39:f277:173e:a926%13]) with mapi id 14.03.0174.001; Thu, 19 Jun 2014 16:06:54 +0200 From: "Wissingh, B.F. (Bastiaan)" To: "its@ietf.org" Thread-Topic: [geonet/its] Announcing draft-wissingh-disseminate-to-rsu-00 Thread-Index: Ac+LxxbDXSuDgbMUQpWPD54JJ6DazQ== Date: Thu, 19 Jun 2014 14:06:53 +0000 Message-ID: <4896674DE9FA8C4A99F872FB8EC34E3D0B8053EB@EXC-MBX02.tsn.tno.nl> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/its/Hh3NoZOxEMW1fpD0wCSNqVIsN5I Subject: [geonet/its] Announcing draft-wissingh-disseminate-to-rsu-00 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 14:07:03 -0000 HI all, In addition to the recently announced submission of the brand new Problem S= tatement draft for GeoNet, we are pleased to announce that we also submitte= d: draft-wissingh-disseminate-to-rsu-00 http://tools.ietf.org/html/draft-wissingh-disseminate-to-rsu-00 This new draft results from earlier discussions held in London, on the mail= ing list as well as other private discussions and identifies several use ca= ses related to the dissemination of Intelligent Transport System (ITS) info= rmation to Road-Side Units. Please comment on this use case draft. Bastiaan _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de = wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verban= d houdt met risico's verbonden aan het elektronisch verzenden van berichten. = This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. From nobody Mon Jun 23 06:05:52 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E9C1B2AB8 for ; Mon, 23 Jun 2014 06:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPSMLwuArsT1 for ; Mon, 23 Jun 2014 06:05:45 -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 7C7BA1B2AB5 for ; Mon, 23 Jun 2014 06:05:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s5ND5Zwx022621; Mon, 23 Jun 2014 15:05:35 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 66043204694; Mon, 23 Jun 2014 15:07:29 +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 567F9204690; Mon, 23 Jun 2014 15:07:29 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s5ND5Uuu026220; Mon, 23 Jun 2014 15:05:34 +0200 Message-ID: <53A8261A.4020804@gmail.com> Date: Mon, 23 Jun 2014 15:05:30 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Wissingh, B.F. (Bastiaan)" , Melinda Shore References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/B1o9GlL9ARyO3rTAd46A16uAMHw Cc: "its@ietf.org" Subject: Re: [geonet/its] Comments on Geonet problemstatement X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 13:05:50 -0000 Hi Bastiaan, Sorry for late reply. I hoped participants to reply to your comments. Absent that please allow me to reply. Le 04/03/2014 16:33, Wissingh, B.F. (Bastiaan) a écrit : > Hi Alex, Melinda, All: > > After the discussions about the geonet charter held yesterday during the > side meeting, I wanted to post some additional comments I have related > to the current version of the geonet problemstatement to the mailing > list in order to try and improve the problemstatement. Some of the > comments are more related to textual improvements, while some are more > content related. I’ve copied the related parts of the problem statement > below. > > o) Mechanisms and protocol solutions are needed for > the accurate representation of geographic areas using (1) > geo-locators such as names and (2) geographiic physical coordinates. > > > In the last sentence above, geographic is misspelled in the above part. Right. I think it is no longer the case in the geonet problem statement draft. > o) Mechanisms and protocol solutions are needed to ensure > that the IP addresses of access routers, roadside unit > (RSUs), and so on can be accurately mapped to geographic > area information (geo-locators, names, and geographic > physical coordinates). Mapping data bases can be > maintained at the source nodes, intermediate or edge > nodes, and at specific IP locator nodes. > > > Seems like it should be “roadside units” on the second line in the above > part. Right. > o) Mechanisms and protocol solutions are needed to ensure > that data packets generated by source nodes placed > arbitrarily in the Internet can be forwarded over > multiple hops by using, where possible, geographic > physical coordinates of (1) the destination node(s) > and/or (2) the intermediate nodes for the routing > decisions, instead of using their IP addresses. (Note > that in order to solve the above challenge it is NOT > mandated that all nodes located on the path from source > to destination nodes are able to forward packets using > the geo-coordinates of (1) the destination node(s) and/or > (2) the intermediate nodes for the routing > decisions. This is emphasized by using the words "where > possible".) > > > As came forward a bit during the discussion yesterday, the above bullet > seems to me that it suggests we want to be defining a new Routing > Protocol or something. Maybe it’s just me, but as it was also suggested > during the discussion yesterday would it be good to reformulate the > above bullet tekst? Yes, this worry about Routing Protocol may be a blocking issue. I will extract this in a separate email. > o) MUST be able to provide accurate representation of > geographic areas using (1) standardized geolocators where > available and/or (2) geographic physical coordinates. > > o) MUST be able to ensure that geographical area information > (geo-locators, names and geographic physical coordinates) > is accurately mapped to an IP address, even if the > relation between geographical area information and IP > address is not a one-to-one relationship. > > o) MUST be able to ensure that an IP address can be > accurately mapped to a geographic area information > (geo-locators, names and geographic physical > coordinates), even if the relation between locator and > geographical information is not a one-to-one > relationship. > > > It is a bit unclear/vague to me what exactly is meant by the term > “accurate”. Is it more related to having the mapping up-to-date, or for > example that the mapping needs to be “square-meter” or > “square-centimeter” precise? What are the ideas on this? The square-meter/centimeter would be "precision". Here at IETF we would not focus on higher and higher precision. In a sense, IP addresses are already 100% precise. Accuracy would be as simple as knowing where a particular IP address is situated (compared to today's situation where we dont know much about it), and maybe to have the mapping up-to-date. Or, otherwise, we can discuss the word accuracy, and see the levels of accuracy of current system (we know some IP addresses belong to some countries - accuracy==hundred square kilometers), and targeted levels of accuracy (to equal that of GPS, of Galileo, of Baidou, or that of imagery sattelites). > > o) Dissemination to a particular area > > In this use case a source node, which may be located anywhere, sends > packets to a wireless access router through the Internet. Those > wireless access routers are selected based on geographical location > information, and traffic is routed to them using the IPv6 address of > the router and conventional IP routing. Each of the destination > access routers then copies and broadcasts the received packets to > listeners within its radio coverage area. > > > Do we really need to explicitly mention the using of the IPv6 address > here? Or can we make it more general and call it an IP address? I would agree to call it an IP address. > o) Vehicular Traffic Safety, Efficiency, Management and Infotainment > > A source node, which may be located anywhere, sends traffic safety, > traffic efficiency and management, and infotainment type of vehicular > information to Road Side Units (RSUs) through the Internet. > > Those RSUs are preselected based on the geographical location > information of the destination geographic area. The vehicular data > traffic is routed to a RSU using its IPv6 address. > > > Regarding the terminology throughout the Charter and the Problem > statement, I don’t think we need to put definitions for all the terms we > use yet, but at least be consistent in the terminology. For example the > term "Roadside Unit” has passed the documents in multiple manners, e.g. > Road-side unit, Road Side Unit, as well as Roadside Unit. I would “vote” > for using the latter one, so Roadside Unit. I agree. It is good to have "Roadside Unit" throughout. > And again, do we need to explicitly state the IPv6 address, or can we > just say IP address? IP address should be fine. > Below, I’ve “tuned” the Mobile RSU use-case a bit, see below. Does it > need some additional text explaining why an geonet mapping is important > for this use-case? > > o) Mobile RSU > > Typically a Roadside Unit (RSU) is placed somewhere alongside a road for > vehicles; an RSU gets a static > geographical location which will most likely not be changed until the > device either reaches its end of > life or is no longer needed at that location; at that time it would be > "torn down” before moving to another > location (other cases may apply). > > A so called 'Mobile Roadside Unit' on the other hand is portable and not > “torn down" while moving, meaning > that among other settings its geographical position adjusts according to > the location where it is positioned. > Such a 'Mobile Roadside Unit’ is very flexible for use in multiple > situations. Examples of such situations include > when a permanently installed unit fails and needs a temporarily backup > unit or during road construction. In the > latter case when at some location along a road there is ongoing road > works, an operator could take a 'Mobile > Roadside Unit', position it on a car at the beginning of the road works > site, and start sending so called > 'Road Works Warning’ messages with detailed information about the road > works. Furthermore, in some cases the > geographical position of it could change if the road works are slowly > moving. > > Additionally, while data traffic could be forwarded along mobile RSUs in > a multi-hop manner, less congested paths > May use the fixed edge geonet-enabled routers of the Internet (off-loading). > > > Last time the Mobile RSU use-case has been discussed, it has been > decided to combine an additional use-case I mentioned about > “off-loading” with the Mobile RSU use-case. In the meantime I have been > thinking some more about that off-loading case, and as it is not > explicitly related to a Mobile RSU I am wondering whether we should > combine it or take it as separate use case? Let me give a brief example > again: > > For example, a car detects an accident in front of him on a certain > high-way. In response it sends a “warning" message via 802.11p to the > nearest roadside unit. Maybe there is some logic there that predicts a > traffic jam based on that info and based on that wants to forward the > warning message to a certain geographical location (for example earlier > on the high-way where for example the high-way splits up), so that cars > arriving at that geographical location can make a decision to continue > their way and end up in the traffic jam, or take the split and avoid the > traffic jam. Bastiaan - is the I-D "Dissemination to RSU" including your description above? The description above makes sense to me. > > The LISP WG mainly focusses mainly on network-layer-based protocol > solutions that enable the separation of routing locators (where you > are attached to the network) and identifiers (who you are) in one > number space. Geonet mainly focusses on how IP routing and addressing > uses geography parameters, like geographical coordinates to > disseminate packets sent by a sender located anywhere in the Internet > to nodes that are located in the area specified by these geography > parameters. > > The ECRIT WG mainly focusses mainly on how location data and call > routing information are used to enable communication between a user > and a relevant emergency response center. In particular, the ECRIT WG > has specified protocols to map emergency services identifiers and > geodetic or civic location information to service contact URIs. > Geonet mainly focusses on how IP routing and addressing uses geodetic > or civic location information to disseminate packets sent by a sender > located anywhere in the Internet to nodes that are located in the area > specified by this geodetic or civic location information. > > > Both the above paragraphs contain the word “mainly” one time too much in > the first sentence. I agree. It is too much use of word "mainly". I think we should modify the Internet Draft: http://tools.ietf.org/html/draft-karagiannis-geonet-problem-statement-00 Alex > > Hope this helps in getting forward, also if I can be of any help, please > let me know! > > Bastiaan > > https://github.com/MelindaShore/geonet/blob/master/problemstatement.txt > > ** > > > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u > niet de geadresseerde bent of dit bericht abusievelijk aan u is > toegezonden, wordt u verzocht dat aan de afzender te melden en het > bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de > inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor schade, > van welke aard ook, die verband houdt met risico's verbonden aan het > elektronisch verzenden van berichten. > > This message may contain information that is not intended for you. If > you are not the addressee or if this message was sent to you by mistake, > you are requested to inform the sender and delete the message. TNO > accepts no liability for the content of this e-mail, for the manner in > which you use it and for damage of any kind resulting from the risks > inherent to the electronic transmission of messages. > From nobody Mon Jun 23 06:11:10 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA0C1B292E for ; Mon, 23 Jun 2014 06:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.983 X-Spam-Level: X-Spam-Status: No, score=-6.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pp0wJf9Fu1AW for ; Mon, 23 Jun 2014 06:11:03 -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 92A521B27AA for ; Mon, 23 Jun 2014 06:11:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s5NDAdgY003622; Mon, 23 Jun 2014 15:10:39 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 53A11204690; Mon, 23 Jun 2014 15:12:33 +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 415BE200B3B; Mon, 23 Jun 2014 15:12:33 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s5NDAckq030195; Mon, 23 Jun 2014 15:10:38 +0200 Message-ID: <53A8274E.8030509@gmail.com> Date: Mon, 23 Jun 2014 15:10:38 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Carl Reed , "Wissingh, B.F. (Bastiaan)" , Melinda Shore References: <03A8A16D362C468399F38665C4187C53@OfficeHP> In-Reply-To: <03A8A16D362C468399F38665C4187C53@OfficeHP> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/Me61iiMtgd0IRMQFiNJZcXHe4II Cc: its@ietf.org Subject: Re: [geonet/its] Comments on Geonet problem statement X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 13:11:09 -0000 Hi Carl, Thank you for the comment. Please see below my comments. Le 04/03/2014 17:13, Carl Reed a écrit : > Alex and Melinda > Another minor nit for “mechanisms and protocol” sentence. remove > “physical”. This is redundant. The definition of a geographic coordinate > system is: > “a coordinate system that enables every location on the Earth to be > specified by a set of numbers or letters.” That makes sense. I will ask Georgios to update this in the current problem statement draft. http://tools.ietf.org/html/draft-karagiannis-geonet-problem-statement-00 > Also, the PIDF Location Object (LO) uses the term “geodetic coordinate” > (https://tools.ietf.org/html/rfc5491). Not sure if you wish to be > consistent. I think we should be consistent. I think we should agree between the name geographic coordinate system, and geodetic coordinate. I think the latter would make more sense. Additionally, I have another comment about this. I worry about "Geo" in geodetic/geographic refering to planet Earth. But IP is known to work outside that space (e.g. in space near and far), at which point our 'geonet' work would not be inapplicable. Alex > Regards > > Carl > *From:* Wissingh, B.F. (Bastiaan) > *Sent:* Tuesday, March 04, 2014 8:33 AM > *To:* Melinda Shore ; Alexandru > Petrescu > *Cc:* its@ietf.org > *Subject:* [geonet/its] Comments on Geonet problemstatement > Hi Alex, Melinda, All: > After the discussions about the geonet charter held yesterday during the > side meeting, I wanted to post some additional comments I have related > to the current version of the geonet problemstatement to the mailing > list in order to try and improve the problemstatement. Some of the > comments are more related to textual improvements, while some are more > content related. I’ve copied the related parts of the problem statement > below. > > o) Mechanisms and protocol solutions are needed for > the accurate representation of geographic areas using (1) > geo-locators such as names and (2) geographiic physical coordinates. > > In the last sentence above, geographic is misspelled in the above part. > > o) Mechanisms and protocol solutions are needed to ensure > that the IP addresses of access routers, roadside unit > (RSUs), and so on can be accurately mapped to geographic > area information (geo-locators, names, and geographic > physical coordinates). Mapping data bases can be > maintained at the source nodes, intermediate or edge > nodes, and at specific IP locator nodes. > > Seems like it should be “roadside units” on the second line in the above > part. > > o) Mechanisms and protocol solutions are needed to ensure > that data packets generated by source nodes placed > arbitrarily in the Internet can be forwarded over > multiple hops by using, where possible, geographic > physical coordinates of (1) the destination node(s) > and/or (2) the intermediate nodes for the routing > decisions, instead of using their IP addresses. (Note > that in order to solve the above challenge it is NOT > mandated that all nodes located on the path from source > to destination nodes are able to forward packets using > the geo-coordinates of (1) the destination node(s) and/or > (2) the intermediate nodes for the routing > decisions. This is emphasized by using the words "where > possible".) > > As came forward a bit during the discussion yesterday, the above bullet > seems to me that it suggests we want to be defining a new Routing > Protocol or something. Maybe it’s just me, but as it was also suggested > during the discussion yesterday would it be good to reformulate the > above bullet tekst? > > o) MUST be able to provide accurate representation of > geographic areas using (1) standardized geolocators where > available and/or (2) geographic physical coordinates. > o) MUST be able to ensure that geographical area information > (geo-locators, names and geographic physical coordinates) > is accurately mapped to an IP address, even if the > relation between geographical area information and IP > address is not a one-to-one relationship. > o) MUST be able to ensure that an IP address can be > accurately mapped to a geographic area information > (geo-locators, names and geographic physical > coordinates), even if the relation between locator and > geographical information is not a one-to-one > relationship. > > It is a bit unclear/vague to me what exactly is meant by the term > “accurate”. Is it more related to having the mapping up-to-date, or for > example that the mapping needs to be “square-meter” or > “square-centimeter” precise? What are the ideas on this? > > o) Dissemination to a particular area > In this use case a source node, which may be located anywhere, sends > packets to a wireless access router through the Internet. Those > wireless access routers are selected based on geographical location > information, and traffic is routed to them using the IPv6 address of > the router and conventional IP routing. Each of the destination > access routers then copies and broadcasts the received packets to > listeners within its radio coverage area. > > Do we really need to explicitly mention the using of the IPv6 address > here? Or can we make it more general and call it an IP address? > > o) Vehicular Traffic Safety, Efficiency, Management and Infotainment > A source node, which may be located anywhere, sends traffic safety, > traffic efficiency and management, and infotainment type of vehicular > information to Road Side Units (RSUs) through the Internet. > Those RSUs are preselected based on the geographical location > information of the destination geographic area. The vehicular data > traffic is routed to a RSU using its IPv6 address. > > Regarding the terminology throughout the Charter and the Problem > statement, I don’t think we need to put definitions for all the terms we > use yet, but at least be consistent in the terminology. For example the > term "Roadside Unit” has passed the documents in multiple manners, e.g. > Road-side unit, Road Side Unit, as well as Roadside Unit. I would “vote” > for using the latter one, so Roadside Unit. > And again, do we need to explicitly state the IPv6 address, or can we > just say IP address? > Below, I’ve “tuned” the Mobile RSU use-case a bit, see below. Does it > need some additional text explaining why an geonet mapping is important > for this use-case? > > o) Mobile RSU > Typically a Roadside Unit (RSU) is placed somewhere alongside a road for > vehicles; an RSU gets a static > geographical location which will most likely not be changed until the > device either reaches its end of > life or is no longer needed at that location; at that time it would be > "torn down” before moving to another > location (other cases may apply). > A so called 'Mobile Roadside Unit' on the other hand is portable and not > “torn down" while moving, meaning > that among other settings its geographical position adjusts according to > the location where it is positioned. > Such a 'Mobile Roadside Unit’ is very flexible for use in multiple > situations. Examples of such situations include > when a permanently installed unit fails and needs a temporarily backup > unit or during road construction. In the > latter case when at some location along a road there is ongoing road > works, an operator could take a 'Mobile > Roadside Unit', position it on a car at the beginning of the road works > site, and start sending so called > 'Road Works Warning’ messages with detailed information about the road > works. Furthermore, in some cases the > geographical position of it could change if the road works are slowly > moving. > Additionally, while data traffic could be forwarded along mobile RSUs in > a multi-hop manner, less congested paths > May use the fixed edge geonet-enabled routers of the Internet (off-loading). > > Last time the Mobile RSU use-case has been discussed, it has been > decided to combine an additional use-case I mentioned about > “off-loading” with the Mobile RSU use-case. In the meantime I have been > thinking some more about that off-loading case, and as it is not > explicitly related to a Mobile RSU I am wondering whether we should > combine it or take it as separate use case? Let me give a brief example > again: > For example, a car detects an accident in front of him on a certain > high-way. In response it sends a “warning" message via 802.11p to the > nearest roadside unit. Maybe there is some logic there that predicts a > traffic jam based on that info and based on that wants to forward the > warning message to a certain geographical location (for example earlier > on the high-way where for example the high-way splits up), so that cars > arriving at that geographical location can make a decision to continue > their way and end up in the traffic jam, or take the split and avoid the > traffic jam. > > The LISP WG mainly focusses mainly on network-layer-based protocol > solutions that enable the separation of routing locators (where you > are attached to the network) and identifiers (who you are) in one > number space. Geonet mainly focusses on how IP routing and addressing > uses geography parameters, like geographical coordinates to > disseminate packets sent by a sender located anywhere in the Internet > to nodes that are located in the area specified by these geography > parameters. > The ECRIT WG mainly focusses mainly on how location data and call > routing information are used to enable communication between a user > and a relevant emergency response center. In particular, the ECRIT WG > has specified protocols to map emergency services identifiers and > geodetic or civic location information to service contact URIs. > Geonet mainly focusses on how IP routing and addressing uses geodetic > or civic location information to disseminate packets sent by a sender > located anywhere in the Internet to nodes that are located in the area > specified by this geodetic or civic location information. > > Both the above paragraphs contain the word “mainly” one time too much in > the first sentence. > Hope this helps in getting forward, also if I can be of any help, please > let me know! > Bastiaan > https://github.com/MelindaShore/geonet/blob/master/problemstatement.txt > > ** > > > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u > niet de geadresseerde bent of dit bericht abusievelijk aan u is > toegezonden, wordt u verzocht dat aan de afzender te melden en het > bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de > inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor schade, > van welke aard ook, die verband houdt met risico's verbonden aan het > elektronisch verzenden van berichten. > > This message may contain information that is not intended for you. If > you are not the addressee or if this message was sent to you by mistake, > you are requested to inform the sender and delete the message. TNO > accepts no liability for the content of this e-mail, for the manner in > which you use it and for damage of any kind resulting from the risks > inherent to the electronic transmission of messages. > > ------------------------------------------------------------------------ > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Mon Jun 23 10:06:57 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9E71B2BA9 for ; Mon, 23 Jun 2014 10:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcDDghqtgJfr for ; Mon, 23 Jun 2014 10:06: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 E8BC01B2B7E for ; Mon, 23 Jun 2014 09:58:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s5NGwKpJ025830 for ; Mon, 23 Jun 2014 18:58:20 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 55FA0204885 for ; Mon, 23 Jun 2014 19:00:15 +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 43E07204864 for ; Mon, 23 Jun 2014 19:00:15 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s5NGw9Ac021480 for ; Mon, 23 Jun 2014 18:58:20 +0200 Message-ID: <53A85CA1.60805@gmail.com> Date: Mon, 23 Jun 2014 18:58:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/Azo1b71XfNWbBPdu-Gc4QYuKCn4 Subject: [geonet/its] blocking points X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 17:06:55 -0000 Hello participants to geonet/its, We are trying to understand what are the blocking points before moving on. We stepped back for a moment, analyzing recent discussions. We think currently there are three blocking points: 1. The re-use of DNS is pereceived as a blocking point; a possible way out is to propose a system-specific resolution mechanism, with a loose-coupling hook to DNS? 2. Forwarding/L3 packet processing based on geonet (rather than IP addresses) is a blocking point; the best we could expect is a overlay style mechanism à la multicast or Mobile IP, where a "gateway function" would be required? 3. Relationship to Geopriv WG may block because it suggests the functions we propose in geonet are maybe more adequate at application layer; maybe Geopriv may deliver an encoding-independent document which would enable consistence in the representation of geolocators and areas? What do you think? Alex From nobody Mon Jun 23 12:42:43 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5681B296F for ; Mon, 23 Jun 2014 12:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcwZoz48NGgw for ; Mon, 23 Jun 2014 12:42:34 -0700 (PDT) Received: from out61-ams.mf.surf.net (out61-ams.mf.surf.net [145.0.1.61]) (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 CEAC11A038D for ; Mon, 23 Jun 2014 12:42:33 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id s5NJgUJ8002627; Mon, 23 Jun 2014 21:42:31 +0200 Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 23 Jun 2014 21:42:32 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.31]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Mon, 23 Jun 2014 21:42:30 +0200 From: To: Thread-Topic: Carl, please let me konw if you have more comments on the problem statement draft? Thread-Index: AQHPjxtEnZ8mkRzHWkq6C/zt6kf/pQ== Date: Mon, 23 Jun 2014 19:42:30 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [95.224.118.204] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F493895EXMBX23adutwent_" MIME-Version: 1.0 X-Bayes-Prob: 0.9999 (Score 4.7, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.49; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0bMhTGv0C - 6ae40f29a1e8 - 20140623 X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/its/uXMAHSw8DaNO2fJKn0OySVGWJhE Cc: its@ietf.org Subject: [geonet/its] Carl, please let me konw if you have more comments on the problem statement draft? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 19:42:41 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F493895EXMBX23adutwent_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Carl, Please note that I have included your definition regarding the geographic c= oordinate system in the current version of the problem statement draft! However, in the text I am still using the term: geographic physical coordinates Do you want me to channge this to the following term: georgraphic coordinate? Can you please review the currend version of the draft, see below, and let= me know if you would like me to implement more changes? http://www.ietf.org/id/draft-karagiannis-geonet-problem-statement-00.txt Best regards, Georgios ________________________________ Van: its [its-bounces@ietf.org] namens Carl Reed [creed@opengeospatial.org] Verzonden: dinsdag 4 maart 2014 17:13 Aan: Wissingh, B.F. (Bastiaan); Melinda Shore; Alexandru Petrescu CC: its@ietf.org Onderwerp: Re: [geonet/its] Comments on Geonet problem statement Alex and Melinda Another minor nit for =93mechanisms and protocol=94 sentence. remove =93phy= sical=94. This is redundant. The definition of a geographic coordinate syst= em is: =93a coordinate system that enables every location on the Earth to be speci= fied by a set of numbers or letters.=94 Also, the PIDF Location Object (LO) uses the term =93geodetic coordinate=94= (https://tools.ietf.org/html/rfc5491). Not sure if you wish to be consiste= nt. Regards Carl From: Wissingh, B.F. (Bastiaan) Sent: Tuesday, March 04, 2014 8:33 AM To: Melinda Shore ; Alexandru Petrescu Cc: its@ietf.org Subject: [geonet/its] Comments on Geonet problemstatement Hi Alex, Melinda, All: After the discussions about the geonet charter held yesterday during the si= de meeting, I wanted to post some additional comments I have related to the= current version of the geonet problemstatement to the mailing list in orde= r to try and improve the problemstatement. Some of the comments are more re= lated to textual improvements, while some are more content related. I=92ve = copied the related parts of the problem statement below. o) Mechanisms and protocol solutions are needed for the accurate representation of geographic areas using (1) geo-locators such as names and (2) geographiic physical coordinates. In the last sentence above, geographic is misspelled in the above part. o) Mechanisms and protocol solutions are needed to ensure that the IP addresses of access routers, roadside unit (RSUs), and so on can be accurately mapped to geographic area information (geo-locators, names, and geographic physical coordinates). Mapping data bases can be maintained at the source nodes, intermediate or edge nodes, and at specific IP locator nodes. Seems like it should be =93roadside units=94 on the second line in the abov= e part. o) Mechanisms and protocol solutions are needed to ensure that data packets generated by source nodes placed arbitrarily in the Internet can be forwarded over multiple hops by using, where possible, geographic physical coordinates of (1) the destination node(s) and/or (2) the intermediate nodes for the routing decisions, instead of using their IP addresses. (Note that in order to solve the above challenge it is NOT mandated that all nodes located on the path from source to destination nodes are able to forward packets using the geo-coordinates of (1) the destination node(s) and/or (2) the intermediate nodes for the routing decisions. This is emphasized by using the words "where possible".) As came forward a bit during the discussion yesterday, the above bullet see= ms to me that it suggests we want to be defining a new Routing Protocol or = something. Maybe it=92s just me, but as it was also suggested during the di= scussion yesterday would it be good to reformulate the above bullet tekst? o) MUST be able to provide accurate representation of geographic areas using (1) standardized geolocators where available and/or (2) geographic physical coordinates. o) MUST be able to ensure that geographical area information (geo-locators, names and geographic physical coordinates) is accurately mapped to an IP address, even if the relation between geographical area information and IP address is not a one-to-one relationship. o) MUST be able to ensure that an IP address can be accurately mapped to a geographic area information (geo-locators, names and geographic physical coordinates), even if the relation between locator and geographical information is not a one-to-one relationship. It is a bit unclear/vague to me what exactly is meant by the term =93accura= te=94. Is it more related to having the mapping up-to-date, or for example = that the mapping needs to be =93square-meter=94 or =93square-centimeter=94 = precise? What are the ideas on this? o) Dissemination to a particular area In this use case a source node, which may be located anywhere, sends packets to a wireless access router through the Internet. Those wireless access routers are selected based on geographical location information, and traffic is routed to them using the IPv6 address of the router and conventional IP routing. Each of the destination access routers then copies and broadcasts the received packets to listeners within its radio coverage area. Do we really need to explicitly mention the using of the IPv6 address here?= Or can we make it more general and call it an IP address? o) Vehicular Traffic Safety, Efficiency, Management and Infotainment A source node, which may be located anywhere, sends traffic safety, traffic efficiency and management, and infotainment type of vehicular information to Road Side Units (RSUs) through the Internet. Those RSUs are preselected based on the geographical location information of the destination geographic area. The vehicular data traffic is routed to a RSU using its IPv6 address. Regarding the terminology throughout the Charter and the Problem statement,= I don=92t think we need to put definitions for all the terms we use yet, b= ut at least be consistent in the terminology. For example the term "Roadsid= e Unit=94 has passed the documents in multiple manners, e.g. Road-side unit= , Road Side Unit, as well as Roadside Unit. I would =93vote=94 for using th= e latter one, so Roadside Unit. And again, do we need to explicitly state the IPv6 address, or can we just = say IP address? Below, I=92ve =93tuned=94 the Mobile RSU use-case a bit, see below. Does it= need some additional text explaining why an geonet mapping is important fo= r this use-case? o) Mobile RSU Typically a Roadside Unit (RSU) is placed somewhere alongside a road for ve= hicles; an RSU gets a static geographical location which will most likely not be changed until the devic= e either reaches its end of life or is no longer needed at that location; at that time it would be "tor= n down=94 before moving to another location (other cases may apply). A so called 'Mobile Roadside Unit' on the other hand is portable and not = =93torn down" while moving, meaning that among other settings its geographical position adjusts according to th= e location where it is positioned. Such a 'Mobile Roadside Unit=92 is very flexible for use in multiple situat= ions. Examples of such situations include when a permanently installed unit fails and needs a temporarily backup unit= or during road construction. In the latter case when at some location along a road there is ongoing road works,= an operator could take a 'Mobile Roadside Unit', position it on a car at the beginning of the road works sit= e, and start sending so called 'Road Works Warning=92 messages with detailed information about the road wo= rks. Furthermore, in some cases the geographical position of it could change if the road works are slowly movin= g. Additionally, while data traffic could be forwarded along mobile RSUs in a = multi-hop manner, less congested paths May use the fixed edge geonet-enabled routers of the Internet (off-loading)= . Last time the Mobile RSU use-case has been discussed, it has been decided t= o combine an additional use-case I mentioned about =93off-loading=94 with t= he Mobile RSU use-case. In the meantime I have been thinking some more abou= t that off-loading case, and as it is not explicitly related to a Mobile RS= U I am wondering whether we should combine it or take it as separate use ca= se? Let me give a brief example again: For example, a car detects an accident in front of him on a certain high-wa= y. In response it sends a =93warning" message via 802.11p to the nearest ro= adside unit. Maybe there is some logic there that predicts a traffic jam ba= sed on that info and based on that wants to forward the warning message to = a certain geographical location (for example earlier on the high-way where = for example the high-way splits up), so that cars arriving at that geograp= hical location can make a decision to continue their way and end up in the = traffic jam, or take the split and avoid the traffic jam. The LISP WG mainly focusses mainly on network-layer-based protocol solutions that enable the separation of routing locators (where you are attached to the network) and identifiers (who you are) in one number space. Geonet mainly focusses on how IP routing and addressing uses geography parameters, like geographical coordinates to disseminate packets sent by a sender located anywhere in the Internet to nodes that are located in the area specified by these geography parameters. The ECRIT WG mainly focusses mainly on how location data and call routing information are used to enable communication between a user and a relevant emergency response center. In particular, the ECRIT WG has specified protocols to map emergency services identifiers and geodetic or civic location information to service contact URIs. Geonet mainly focusses on how IP routing and addressing uses geodetic or civic location information to disseminate packets sent by a sender located anywhere in the Internet to nodes that are located in the area specified by this geodetic or civic location information. Both the above paragraphs contain the word =93mainly=94 one time too much i= n the first sentence. Hope this helps in getting forward, also if I can be of any help, please le= t me know! Bastiaan https://github.com/MelindaShore/geonet/blob/master/problemstatement.txt Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de = wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verban= d houdt met risico's verbonden aan het elektronisch verzenden van berichten= . This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. ________________________________ _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F493895EXMBX23adutwent_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Carl,

 

Please note that I have included your definition regarding the geographi= c coordinate system in the current version of the problem statement draft!<= /p>

 

However, in the text I am still using the term:

 

geographic physical coordinates

 

Do you want me to channge this to the following term:

 

georgraphic coordinate?

 

Can you please review the currend version of the draft, see below,  = ;and let me know if you would like me to implement more changes?

 

http://www.ietf.org/id/draft-karagiannis-geonet-problem-statem= ent-00.txt

 

 

Best regards,

Georgios

 

Van: its [its-bounces@ietf.org] namens Car= l Reed [creed@opengeospatial.org]
Verzonden: dinsdag 4 maart 2014 17:13
Aan: Wissingh, B.F. (Bastiaan); Melinda Shore; Alexandru Petrescu CC: its@ietf.org
Onderwerp: Re: [geonet/its] Comments on Geonet problem statement

Alex and Melinda
 
Another minor nit for =93mechanisms and protocol=94 sentence. remove = =93physical=94. This is redundant. The definition of a geographic coordinat= e system is:
 
=93a coordinate system that enables= every location on the Earth to be specified by a set of numbers or letters= .=94
 
Also, the PIDF Location Object (LO) uses the term =93geodetic coordina= te=94 (https://tools.ietf.org/html/rfc= 5491). Not sure if you wish to be consistent.
 
Regards

Carl
 
 
Sent: Tuesday, March 04, 2014 8:33 AM
Subject: [geonet/its] Comments on Geonet problemstatement
 
Hi Alex, Melinda, All:
 
After the discussions about the geonet charter held yesterday during the si= de meeting, I wanted to post some additional comments I have related to the= current version of the geonet problemstatement to the mailing list in orde= r to try and improve the problemstatement. Some of the comments are more related to textual improvements, while some = are more content related. I=92ve copied the related parts of the problem st= atement below.
 
o) Mechanisms and protocol solutions are needed for
   the accurate re=
presentation of geographic areas using (1)
   geo-locators such as names a=
nd (2) geographiic physical coordinates.
 
In the last sentence above, geographic is misspelled in the above part.
 
o) Mechanisms and protocol solutions are needed to ensure
   that the =
IP addresses of access routers, roadside unit
   (RSUs), and so on can be =
accurately mapped to geographic
   area information (geo-locators, names=
, and geographic
   physical coordinates).  Mapping data bases can be
  =
; maintained at the source nodes, intermediate or edge
   nodes, and at sp=
ecific IP locator nodes.
 
Seems like it should be =93roadside units=94 on the second line in the abov= e part.
 
o) Mechanisms and protocol solutions are needed to ensure
   that data=
 packets generated by source nodes placed
   arbitrarily in the Internet c=
an be forwarded over
   multiple hops by using, where possible, geographic=

 &n=
bsp; physical coordinates of (1) the destination node(s)
   and/or (2) the=
 intermediate nodes for the routing
   decisions, instead of using their I=
P addresses.  (Note
   that in order to solve the above challenge it is NO=
T
 &=
nbsp; mandated that all nodes located on the path from source
   to destin=
ation nodes are able to forward packets using
   the geo-coordinates of (1=
) the destination node(s) and/or
   (2) the intermediate nodes for the ro=
uting
&nb=
sp;  decisions. This is emphasized by using the words "where
   =
possible".)
 
As came forward a bit during the discussion yesterday, the above bullet see= ms to me that it suggests we want to be defining a new Routing Protocol or = something. Maybe it=92s just me, but as it was also suggested during the di= scussion yesterday would it be good to reformulate the above bullet tekst?
 
o) MUST be able to provide accurate representation of
   geographic =
areas using (1) standardized geolocators where
   available and/or (2) geo=
graphic physical coordinates.
 
o) MUST be able to ensure that geographical area informa=
tion
&nbs=
p;  (geo-locators, names and geographic physical coordinates)
   is a=
ccurately mapped to an IP address, even if the
   relation between geograp= hical area information and IP
   address is not a one-to-one relationship.=
 
o) MUST be= able to ensure that an IP address can be
   accurately mapped to a geogra= phic area information
   (geo-locators, names and geographic physical
   = coordinates), even if the relation between locator and
   geographical inf= ormation is not a one-to-one
   relationship.
 
It is a bit unclear/vague to me what exactly is meant by the term =93accura= te=94. Is it more related to having the mapping up-to-date, or for example = that the mapping needs to be =93square-meter=94 or =93square-centimeter=94 = precise? What are the ideas on this?
 
o) Dissemination to a particular area
 
In this use case a source node, which may=
 be located anywhere, sends
packets to a wireless access router through the Interne=
t.  Those
wireless access routers are selected based on geographical location
=

information, =
and traffic is routed to them using the IPv6 address of
the router and conventional=
 IP routing.  Each of the destination
access routers then copies and broadcasts the=
 received packets to
listeners within its radio coverage area.
 
Do we really need to explicitly mention the using of the IPv6 address here?= Or can we make it more general and call it an IP address?
 
o) Vehicular Traffic Safety, Efficiency, Management and Infotainment
 
A source n=
ode, which may be located anywhere, sends traffic safety,
traffic efficiency and =
management, and infotainment type of vehicular
information to Road Side Units (RSUs=
) through the Internet.
 
Those RSUs are preselected based on the geographical locatio=
n 
infor=
mation of the destination geographic area. The vehicular data
traffic is routed to =
a RSU using its IPv6 address.
 
Regarding the terminology throughout the Charter and the Problem statement,= I don=92t think we need to put definitions for all the terms we use yet, b= ut at least be consistent in the terminology. For example the term "Ro= adside Unit=94 has passed the documents in multiple manners, e.g. Road-side unit, Road Side Unit, as well as Roadside= Unit. I would =93vote=94 for using the latter one, so Roadside Unit.
 
And again, do we need to explicitly state the IPv6 address, or can we just = say IP address?
 
Below, I=92ve =93tuned=94 the Mobile RSU use-case a bit, see below. Does it= need some additional text explaining why an geonet mapping is important fo= r this use-case?
 
o) Mobile RSU
 
Typically a Roadside Unit (RSU) is placed somewhere alongside a r=
oad for vehicles; an RSU gets a static
geographical location which will most likely=
 not be changed until the device either reaches its end of 
life or is no longer ne=
eded at that location; at that time it would be "torn down=94 before m=
oving to another
location (other cases may apply).  
 
A so called 'Mobile Roadside Unit=
' on the other hand is portable and not =93torn down" while moving, me=
aning 
t=
hat among other settings its geographical position adjusts according to the=
 location where it is positioned.  
Such a 'Mobile Roadside Unit=92 is very fl=
exible for use in multiple situations.  Examples of such situations include=
 
when a=
 permanently installed unit fails and needs a temporarily backup unit or du=
ring road construction. In the 
latter case when at some location along a road th=
ere is ongoing road works, an operator could take a 'Mobile
Roadside Unit', positio=
n it on a car at the beginning of the road works site, and start sending so=
 called
=
'Road Works Warning=92 messages with detailed information about the road wo=
rks. Furthermore, in some cases the
geographical position of it could change if the=
 road works are slowly moving.
 
Additionally, while data traffic could be forwarded a=
long mobile RSUs in a multi-hop manner, less congested paths 
May use the fixed edg=
e geonet-enabled routers of the Internet (off-loading).
 
Last time the Mobile RSU use-case has been discussed, it has been decided t= o combine an additional use-case I mentioned about =93off-loading=94 with t= he Mobile RSU use-case. In the meantime I have been thinking some more abou= t that off-loading case, and as it is not explicitly related to a Mobile RSU I am wondering whether we should co= mbine it or take it as separate use case? Let me give a brief example again= :
 
For exampl= e, a car detects an accident in front of him on a certain high-way. In resp= onse it sends a =93warning" message via 802.11p to the nearest roadsid= e unit. Maybe there is some logic there that predicts a traffic jam based on that info and based on that wants to forwa= rd the warning message to a certain geographical location (for example earl= ier on the high-way where for example the high-way splits up), so that cars= arriving at that  geographical location can make a decision to continue their way and end up in the traff= ic jam, or take the split and avoid the traffic jam.
 
The LISP WG mainly focusses mainly on network-layer-based protocol
solutions t=
hat enable the separation of routing locators (where you
are attached to the networ=
k) and identifiers (who you are) in one
number space.  Geonet mainly focusses on ho=
w IP routing and addressing
uses geography parameters, like geographical coordinate=
s to
dis=
seminate packets sent by a sender located anywhere in the Internet
to nodes that ar=
e located in the area specified by these geography
parameters.
 
The ECRIT WG mainly focusses =
mainly on how location data and call
routing information are used to enable communi=
cation between a user
and a relevant emergency response center. In particular, the =
ECRIT WG
has specified protocols to map emergency services identifiers and
geodetic or civi=
c location information to service contact URIs.
Geonet mainly focusses on how IP ro= uting and addressing uses geodetic
or civic location information to disseminate pac= kets sent by a sender
located anywhere in the Internet to nodes that are located in= the area
specified by this geodetic or civic location information.
 
Both the above paragraphs contain the word =93mainly=94 one time too much i= n the first sentence.
 
Hope this helps in getting forward, also if I can be of any help, please le= t me know!
 
Bastiaan
 




Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor sc= hade, van welke aard ook, die verband houdt met risico's verbonden aan het = elektronisch verzenden van berichten.

 

This message may contain inform= ation that is not intended for you. If you are not the addressee or if this= message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no = liability for the content of this e-mail, for the manner in which you use i= t and for damage of any kind resulting from the risks inherent to the elect= ronic transmission of messages.

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F493895EXMBX23adutwent_-- From nobody Mon Jun 23 12:45:41 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA61F1B2B22 for ; Mon, 23 Jun 2014 12:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DL4s3UiXF2vL for ; Mon, 23 Jun 2014 12:45:31 -0700 (PDT) Received: from out64-ams.mf.surf.net (out64-ams.mf.surf.net [145.0.1.64]) (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 5F43B1B28F5 for ; Mon, 23 Jun 2014 12:45:31 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id s5NJjRRB002827; Mon, 23 Jun 2014 21:45:28 +0200 Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 23 Jun 2014 21:45:28 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.31]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.03.0181.006; Mon, 23 Jun 2014 21:45:27 +0200 From: To: Thread-Topic: Bastiaan, can you please let me know if all your comments have been addressed? Thread-Index: AQHPjxutfVZ/EPdCSESB8SnCWyV8fQ== Date: Mon, 23 Jun 2014 19:45:26 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [95.224.118.204] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4938A6EXMBX23adutwent_" MIME-Version: 1.0 X-Bayes-Prob: 0.9999 (Score 4.7, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.48; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0bMhTJs1A - 6c18c16696cf - 20140623 X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/its/ZfLqJZtwEbkZaU7EM9pwwhbGD0A Cc: its@ietf.org Subject: [geonet/its] Bastiaan, can you please let me know if all your comments have been addressed? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 19:45:40 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4938A6EXMBX23adutwent_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bastiaan, I think that I have worked out all your comments in the current version of = the problem statement daft! Can you please review the current version of the draft, see below, and let = me know if you have any other comments? Best regards, Georgios ________________________________ Van: its [its-bounces@ietf.org] namens Wissingh, B.F. (Bastiaan) [bastiaan.= wissingh@tno.nl] Verzonden: woensdag 16 april 2014 16:43 Aan: Carl Reed; Melinda Shore; Alexandru Petrescu; its@ietf.org Onderwerp: Re: [geonet/its] Comments on Geonet problem statement Hi All, During the last IETF Meeting in Londen I sent around some feedback on the = =93Geonet problem statement=94 text, but as it has been relatively quiet on= the mailinglist since the last IETF Meeting I was wondering what the curre= nt state of the =93Geonet problem statement=94 is? Has one of you been able= to process the below feedback on the problem statement for example? Or wou= ld help with that be appreciated? Looking forward to a response, Kind regards, Bastiaan Wissingh Van: Carl Reed > Organisatie: OGC Datum: dinsdag 4 maart 2014 18:13 Aan: Bastiaan Wissingh >, Melinda Shore >, Alexandru Petrescu > CC: "its@ietf.org" > Onderwerp: Re: [geonet/its] Comments on Geonet problem statement Alex and Melinda Another minor nit for =93mechanisms and protocol=94 sentence. remove =93phy= sical=94. This is redundant. The definition of a geographic coordinate syst= em is: =93a coordinate system that enables every location on the Earth to be speci= fied by a set of numbers or letters.=94 Also, the PIDF Location Object (LO) uses the term =93geodetic coordinate=94= (https://tools.ietf.org/html/rfc5491). Not sure if you wish to be consiste= nt. Regards Carl From: Wissingh, B.F. (Bastiaan) Sent: Tuesday, March 04, 2014 8:33 AM To: Melinda Shore ; Alexandru Petrescu Cc: its@ietf.org Subject: [geonet/its] Comments on Geonet problemstatement Hi Alex, Melinda, All: After the discussions about the geonet charter held yesterday during the si= de meeting, I wanted to post some additional comments I have related to the= current version of the geonet problemstatement to the mailing list in orde= r to try and improve the problemstatement. Some of the comments are more re= lated to textual improvements, while some are more content related. I=92ve = copied the related parts of the problem statement below. o) Mechanisms and protocol solutions are needed for the accurate representation of geographic areas using (1) geo-locators such as names and (2) geographiic physical coordinates. In the last sentence above, geographic is misspelled in the above part. o) Mechanisms and protocol solutions are needed to ensure that the IP addresses of access routers, roadside unit (RSUs), and so on can be accurately mapped to geographic area information (geo-locators, names, and geographic physical coordinates). Mapping data bases can be maintained at the source nodes, intermediate or edge nodes, and at specific IP locator nodes. Seems like it should be =93roadside units=94 on the second line in the abov= e part. o) Mechanisms and protocol solutions are needed to ensure that data packets generated by source nodes placed arbitrarily in the Internet can be forwarded over multiple hops by using, where possible, geographic physical coordinates of (1) the destination node(s) and/or (2) the intermediate nodes for the routing decisions, instead of using their IP addresses. (Note that in order to solve the above challenge it is NOT mandated that all nodes located on the path from source to destination nodes are able to forward packets using the geo-coordinates of (1) the destination node(s) and/or (2) the intermediate nodes for the routing decisions. This is emphasized by using the words "where possible".) As came forward a bit during the discussion yesterday, the above bullet see= ms to me that it suggests we want to be defining a new Routing Protocol or = something. Maybe it=92s just me, but as it was also suggested during the di= scussion yesterday would it be good to reformulate the above bullet tekst? o) MUST be able to provide accurate representation of geographic areas using (1) standardized geolocators where available and/or (2) geographic physical coordinates. o) MUST be able to ensure that geographical area information (geo-locators, names and geographic physical coordinates) is accurately mapped to an IP address, even if the relation between geographical area information and IP address is not a one-to-one relationship. o) MUST be able to ensure that an IP address can be accurately mapped to a geographic area information (geo-locators, names and geographic physical coordinates), even if the relation between locator and geographical information is not a one-to-one relationship. It is a bit unclear/vague to me what exactly is meant by the term =93accura= te=94. Is it more related to having the mapping up-to-date, or for example = that the mapping needs to be =93square-meter=94 or =93square-centimeter=94 = precise? What are the ideas on this? o) Dissemination to a particular area In this use case a source node, which may be located anywhere, sends packets to a wireless access router through the Internet. Those wireless access routers are selected based on geographical location information, and traffic is routed to them using the IPv6 address of the router and conventional IP routing. Each of the destination access routers then copies and broadcasts the received packets to listeners within its radio coverage area. Do we really need to explicitly mention the using of the IPv6 address here?= Or can we make it more general and call it an IP address? o) Vehicular Traffic Safety, Efficiency, Management and Infotainment A source node, which may be located anywhere, sends traffic safety, traffic efficiency and management, and infotainment type of vehicular information to Road Side Units (RSUs) through the Internet. Those RSUs are preselected based on the geographical location information of the destination geographic area. The vehicular data traffic is routed to a RSU using its IPv6 address. Regarding the terminology throughout the Charter and the Problem statement,= I don=92t think we need to put definitions for all the terms we use yet, b= ut at least be consistent in the terminology. For example the term "Roadsid= e Unit=94 has passed the documents in multiple manners, e.g. Road-side unit= , Road Side Unit, as well as Roadside Unit. I would =93vote=94 for using th= e latter one, so Roadside Unit. And again, do we need to explicitly state the IPv6 address, or can we just = say IP address? Below, I=92ve =93tuned=94 the Mobile RSU use-case a bit, see below. Does it= need some additional text explaining why an geonet mapping is important fo= r this use-case? o) Mobile RSU Typically a Roadside Unit (RSU) is placed somewhere alongside a road for ve= hicles; an RSU gets a static geographical location which will most likely not be changed until the devic= e either reaches its end of life or is no longer needed at that location; at that time it would be "tor= n down=94 before moving to another location (other cases may apply). A so called 'Mobile Roadside Unit' on the other hand is portable and not = =93torn down" while moving, meaning that among other settings its geographical position adjusts according to th= e location where it is positioned. Such a 'Mobile Roadside Unit=92 is very flexible for use in multiple situat= ions. Examples of such situations include when a permanently installed unit fails and needs a temporarily backup unit= or during road construction. In the latter case when at some location along a road there is ongoing road works,= an operator could take a 'Mobile Roadside Unit', position it on a car at the beginning of the road works sit= e, and start sending so called 'Road Works Warning=92 messages with detailed information about the road wo= rks. Furthermore, in some cases the geographical position of it could change if the road works are slowly movin= g. Additionally, while data traffic could be forwarded along mobile RSUs in a = multi-hop manner, less congested paths May use the fixed edge geonet-enabled routers of the Internet (off-loading)= . Last time the Mobile RSU use-case has been discussed, it has been decided t= o combine an additional use-case I mentioned about =93off-loading=94 with t= he Mobile RSU use-case. In the meantime I have been thinking some more abou= t that off-loading case, and as it is not explicitly related to a Mobile RS= U I am wondering whether we should combine it or take it as separate use ca= se? Let me give a brief example again: For example, a car detects an accident in front of him on a certain high-wa= y. In response it sends a =93warning" message via 802.11p to the nearest ro= adside unit. Maybe there is some logic there that predicts a traffic jam ba= sed on that info and based on that wants to forward the warning message to = a certain geographical location (for example earlier on the high-way where = for example the high-way splits up), so that cars arriving at that geograp= hical location can make a decision to continue their way and end up in the = traffic jam, or take the split and avoid the traffic jam. The LISP WG mainly focusses mainly on network-layer-based protocol solutions that enable the separation of routing locators (where you are attached to the network) and identifiers (who you are) in one number space. Geonet mainly focusses on how IP routing and addressing uses geography parameters, like geographical coordinates to disseminate packets sent by a sender located anywhere in the Internet to nodes that are located in the area specified by these geography parameters. The ECRIT WG mainly focusses mainly on how location data and call routing information are used to enable communication between a user and a relevant emergency response center. In particular, the ECRIT WG has specified protocols to map emergency services identifiers and geodetic or civic location information to service contact URIs. Geonet mainly focusses on how IP routing and addressing uses geodetic or civic location information to disseminate packets sent by a sender located anywhere in the Internet to nodes that are located in the area specified by this geodetic or civic location information. Both the above paragraphs contain the word =93mainly=94 one time too much i= n the first sentence. Hope this helps in getting forward, also if I can be of any help, please le= t me know! Bastiaan https://github.com/MelindaShore/geonet/blob/master/problemstatement.txt Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de = wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verban= d houdt met risico's verbonden aan het elektronisch verzenden van berichten= . This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. ________________________________ _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4938A6EXMBX23adutwent_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Bastiaan,

 

I think that I have worked out all your comments in the current version = of the problem statement daft!

 

Can you please review the current version of the draft, see below, and l= et me know if you have any other comments?

 

Best regards,

Georgios

Van: its [its-bounces@ietf.org] namens Wis= singh, B.F. (Bastiaan) [bastiaan.wissingh@tno.nl]
Verzonden: woensdag 16 april 2014 16:43
Aan: Carl Reed; Melinda Shore; Alexandru Petrescu; its@ietf.org
Onderwerp: Re: [geonet/its] Comments on Geonet problem statement

Hi All,

During the last IETF Meeting in Londen I sent around some feedback on = the =93Geonet problem statement=94 text, but as it has been relatively quie= t on the mailinglist since the last IETF Meeting I was wondering what the c= urrent state of the =93Geonet problem statement=94 is? Has one of you been able to process the below feedback on= the problem statement for example? Or would help with that be appreciated?=

Looking forward to a response,

Kind regards,
Bastiaan Wissingh

Van: Carl Reed <creed@opengeospatial.org= >
Organisatie: OGC
Datum: dinsdag 4 maart 2014 18:13<= br> Aan: Bastiaan Wissingh <bastiaan.wissingh@tn= o.nl>, Melinda Shore <melinda.shore@gmail.com>, Alexandru Petrescu <alexandru.petrescu@gmail.com>
CC: "its@ietf.org" <its@ietf.org>
Onderwerp: Re: [geonet/its] Commen= ts on Geonet problem statement

Alex and Melinda
 
Another minor nit for =93mechanisms and protocol=94 sentence. remove = =93physical=94. This is redundant. The definition of a geographic coordinat= e system is:
 
=93a coordinate system that enables= every location on the Earth to be specified by a set of numbers or letters= .=94
 
Also, the PIDF Location Object (LO) uses the term =93geodetic coordina= te=94 (https://tools.ietf.org/html/rfc= 5491). Not sure if you wish to be consistent.
 
Regards

Carl
 
 
Sent: Tuesday, March 04, 2014 8:33 AM
Subject: [geonet/its] Comments on Geonet problemstatement
 
Hi Alex, Melinda, All:
 
After the discussions about the geonet charter held yesterday during the si= de meeting, I wanted to post some additional comments I have related to the= current version of the geonet problemstatement to the mailing list in orde= r to try and improve the problemstatement. Some of the comments are more related to textual improvements, while some = are more content related. I=92ve copied the related parts of the problem st= atement below.
 
o) Mechanisms and protocol solutions are needed for
   the accurate re=
presentation of geographic areas using (1)
   geo-locators such as names a=
nd (2) geographiic physical coordinates.
 
In the last sentence above, geographic is misspelled in the above part.
 
o) Mechanisms and protocol solutions are needed to ensure
   that the =
IP addresses of access routers, roadside unit
   (RSUs), and so on can be =
accurately mapped to geographic
   area information (geo-locators, names=
, and geographic
   physical coordinates).  Mapping data bases can be
  =
; maintained at the source nodes, intermediate or edge
   nodes, and at sp=
ecific IP locator nodes.
 
Seems like it should be =93roadside units=94 on the second line in the abov= e part.
 
o) Mechanisms and protocol solutions are needed to ensure
   that data=
 packets generated by source nodes placed
   arbitrarily in the Internet c=
an be forwarded over
   multiple hops by using, where possible, geographic=

 &n=
bsp; physical coordinates of (1) the destination node(s)
   and/or (2) the=
 intermediate nodes for the routing
   decisions, instead of using their I=
P addresses.  (Note
   that in order to solve the above challenge it is NO=
T
 &=
nbsp; mandated that all nodes located on the path from source
   to destin=
ation nodes are able to forward packets using
   the geo-coordinates of (1=
) the destination node(s) and/or
   (2) the intermediate nodes for the ro=
uting
&nb=
sp;  decisions. This is emphasized by using the words "where
   =
possible".)
 
As came forward a bit during the discussion yesterday, the above bullet see= ms to me that it suggests we want to be defining a new Routing Protocol or = something. Maybe it=92s just me, but as it was also suggested during the di= scussion yesterday would it be good to reformulate the above bullet tekst?
 
o) MUST be able to provide accurate representation of
   geographic =
areas using (1) standardized geolocators where
   available and/or (2) geo=
graphic physical coordinates.
 
o) MUST be able to ensure that geographical area informa=
tion
&nbs=
p;  (geo-locators, names and geographic physical coordinates)
   is a=
ccurately mapped to an IP address, even if the
   relation between geograp= hical area information and IP
   address is not a one-to-one relationship.=
 
o) MUST be= able to ensure that an IP address can be
   accurately mapped to a geogra= phic area information
   (geo-locators, names and geographic physical
   = coordinates), even if the relation between locator and
   geographical inf= ormation is not a one-to-one
   relationship.
 
It is a bit unclear/vague to me what exactly is meant by the term =93accura= te=94. Is it more related to having the mapping up-to-date, or for example = that the mapping needs to be =93square-meter=94 or =93square-centimeter=94 = precise? What are the ideas on this?
 
o) Dissemination to a particular area
 
In this use case a source node, which may=
 be located anywhere, sends
packets to a wireless access router through the Interne=
t.  Those
wireless access routers are selected based on geographical location
=

information, =
and traffic is routed to them using the IPv6 address of
the router and conventional=
 IP routing.  Each of the destination
access routers then copies and broadcasts the=
 received packets to
listeners within its radio coverage area.
 
Do we really need to explicitly mention the using of the IPv6 address here?= Or can we make it more general and call it an IP address?
 
o) Vehicular Traffic Safety, Efficiency, Management and Infotainment
 
A source n=
ode, which may be located anywhere, sends traffic safety,
traffic efficiency and =
management, and infotainment type of vehicular
information to Road Side Units (RSUs=
) through the Internet.
 
Those RSUs are preselected based on the geographical locatio=
n 
infor=
mation of the destination geographic area. The vehicular data
traffic is routed to =
a RSU using its IPv6 address.
 
Regarding the terminology throughout the Charter and the Problem statement,= I don=92t think we need to put definitions for all the terms we use yet, b= ut at least be consistent in the terminology. For example the term "Ro= adside Unit=94 has passed the documents in multiple manners, e.g. Road-side unit, Road Side Unit, as well as Roadside= Unit. I would =93vote=94 for using the latter one, so Roadside Unit.
 
And again, do we need to explicitly state the IPv6 address, or can we just = say IP address?
 
Below, I=92ve =93tuned=94 the Mobile RSU use-case a bit, see below. Does it= need some additional text explaining why an geonet mapping is important fo= r this use-case?
 
o) Mobile RSU
 
Typically a Roadside Unit (RSU) is placed somewhere alongside a r=
oad for vehicles; an RSU gets a static
geographical location which will most likely=
 not be changed until the device either reaches its end of 
life or is no longer ne=
eded at that location; at that time it would be "torn down=94 before m=
oving to another
location (other cases may apply).  
 
A so called 'Mobile Roadside Unit=
' on the other hand is portable and not =93torn down" while moving, me=
aning 
t=
hat among other settings its geographical position adjusts according to the=
 location where it is positioned.  
Such a 'Mobile Roadside Unit=92 is very fl=
exible for use in multiple situations.  Examples of such situations include=
 
when a=
 permanently installed unit fails and needs a temporarily backup unit or du=
ring road construction. In the 
latter case when at some location along a road th=
ere is ongoing road works, an operator could take a 'Mobile
Roadside Unit', positio=
n it on a car at the beginning of the road works site, and start sending so=
 called
=
'Road Works Warning=92 messages with detailed information about the road wo=
rks. Furthermore, in some cases the
geographical position of it could change if the=
 road works are slowly moving.
 
Additionally, while data traffic could be forwarded a=
long mobile RSUs in a multi-hop manner, less congested paths 
May use the fixed edg=
e geonet-enabled routers of the Internet (off-loading).
 
Last time the Mobile RSU use-case has been discussed, it has been decided t= o combine an additional use-case I mentioned about =93off-loading=94 with t= he Mobile RSU use-case. In the meantime I have been thinking some more abou= t that off-loading case, and as it is not explicitly related to a Mobile RSU I am wondering whether we should co= mbine it or take it as separate use case? Let me give a brief example again= :
 
For exampl= e, a car detects an accident in front of him on a certain high-way. In resp= onse it sends a =93warning" message via 802.11p to the nearest roadsid= e unit. Maybe there is some logic there that predicts a traffic jam based on that info and based on that wants to forwa= rd the warning message to a certain geographical location (for example earl= ier on the high-way where for example the high-way splits up), so that cars= arriving at that  geographical location can make a decision to continue their way and end up in the traff= ic jam, or take the split and avoid the traffic jam.
 
The LISP WG mainly focusses mainly on network-layer-based protocol
solutions t=
hat enable the separation of routing locators (where you
are attached to the networ=
k) and identifiers (who you are) in one
number space.  Geonet mainly focusses on ho=
w IP routing and addressing
uses geography parameters, like geographical coordinate=
s to
dis=
seminate packets sent by a sender located anywhere in the Internet
to nodes that ar=
e located in the area specified by these geography
parameters.
 
The ECRIT WG mainly focusses =
mainly on how location data and call
routing information are used to enable communi=
cation between a user
and a relevant emergency response center. In particular, the =
ECRIT WG
has specified protocols to map emergency services identifiers and
geodetic or civi=
c location information to service contact URIs.
Geonet mainly focusses on how IP ro= uting and addressing uses geodetic
or civic location information to disseminate pac= kets sent by a sender
located anywhere in the Internet to nodes that are located in= the area
specified by this geodetic or civic location information.
 
Both the above paragraphs contain the word =93mainly=94 one time too much i= n the first sentence.
 
Hope this helps in getting forward, also if I can be of any help, please le= t me know!
 
Bastiaan
 




Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor sc= hade, van welke aard ook, die verband houdt met risico's verbonden aan het = elektronisch verzenden van berichten.

 

This message may contain information that is not intended for you. = If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and del= ete the message. TNO accepts no liability for the content of this e-mail, f= or the manner in which you use it and for damage of any kind resulting from= the risks inherent to the electronic transmission of messages.

_______________________________________________
its mailing list
its@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/its
--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4938A6EXMBX23adutwent_-- From nobody Mon Jun 23 12:48:41 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F3D1B2C11 for ; Mon, 23 Jun 2014 12:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.966 X-Spam-Level: X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FS_START_DOYOU2=1.633, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJExVBJgVQz8 for ; Mon, 23 Jun 2014 12:48:33 -0700 (PDT) Received: from out61-ams.mf.surf.net (out61-ams.mf.surf.net [145.0.1.61]) (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 802831B2B22 for ; Mon, 23 Jun 2014 12:48:33 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id s5NJmVb5003062 for ; Mon, 23 Jun 2014 21:48:32 +0200 Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 23 Jun 2014 21:48:33 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.31]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.03.0181.006; Mon, 23 Jun 2014 21:48:31 +0200 From: To: Thread-Topic: do you have more comments on the geonet problem statement draft? Thread-Index: AQHPjxwcZngcSTSjEk2EO6XsXye1wA== Date: Mon, 23 Jun 2014 19:48:31 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [95.224.118.204] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4938BAEXMBX23adutwent_" MIME-Version: 1.0 X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.49; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0bMhTMw2z - bf68698a8f4b - 20140623 X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/its/3XoOKETX4T9TBYTrQPnkMhMXhr4 Subject: [geonet/its] do you have more comments on the geonet problem statement draft? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 19:48:34 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4938BAEXMBX23adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Please note that I have tried to work out all the comments in the current v= ersion of the Geonet problem statement draft. If you have any other comments, please let me know! Best regards, Georgios --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4938BAEXMBX23adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Please note that I have tried to work out all the comments in the curren= t version of the Geonet problem statement draft.

 

If you have any other comments, please let me know!

 

Best regards,

Georgios

 

 

 

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4938BAEXMBX23adutwent_-- From nobody Tue Jun 24 15:45:38 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D30F1B294D for ; Tue, 24 Jun 2014 15:45:36 -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 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 cFpNFu5a4OoE for ; Tue, 24 Jun 2014 15:45:34 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890441B2941 for ; Tue, 24 Jun 2014 15:45:34 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id ft15so804968pdb.21 for ; Tue, 24 Jun 2014 15:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UYmM06+Nizankw3tRD4/TltmyF308ZkD36vEP/DYtds=; b=tfmIc7gL652FfNyPZoYWXDmQIErx1YXglEJfss2mYtDoO5a0N41Q9CYUyVKKqaOuny qeB68iUVrypS7t2WIzj17hDHyIcpVpIjXoCXnimPKn/02gjLlsAYl4AeEQ9KFxQEbc9X wBvTaHmAe3J/ME9ucBjrMorXLCNniWC7g1rhxIutp1msnEBHtHl3ojc2vLMp9osz4ZNt qoJQp1i9sueQU72tys/u7PoBIrK1qFuoktLvX13IArm39vh65vKNlMSa+aOInT7Y/hed gZKKS4toOfREqwROJDjU/lPdRuQ6nlcQd2VJTAjAoKycJ+aNHdJtKXx0meY1Vs+IE5x0 pcvQ== X-Received: by 10.66.151.144 with SMTP id uq16mr5899572pab.68.1403649934054; Tue, 24 Jun 2014 15:45:34 -0700 (PDT) Received: from dino-macbook.wp.comcast.net (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id vy5sm7701807pac.13.2014.06.24.15.45.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Jun 2014 15:45:33 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: Date: Tue, 24 Jun 2014 15:45:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <479CDE82-19BD-4FF2-9F33-3BBC847E7613@gmail.com> References: To: karagian@cs.utwente.nl X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/its/riPLf-ef-9TUQMrJEA_I71t8I3A Cc: its@ietf.org Subject: Re: [geonet/its] do you have more comments on the geonet problem statement draft? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 22:45:36 -0000 I have no comments. Dino On Jun 23, 2014, at 12:48 PM, karagian@cs.utwente.nl wrote: > Hi all, > =20 > Please note that I have tried to work out all the comments in the = current version of the Geonet problem statement draft. > =20 > If you have any other comments, please let me know! > =20 > Best regards, > Georgios > =20 > =20 > =20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Tue Jun 24 23:14:47 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA3D1B2AE5 for ; Tue, 24 Jun 2014 23:14:45 -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 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 NLj4krEFajFV for ; Tue, 24 Jun 2014 23:14:42 -0700 (PDT) Received: from out49-ams.mf.surf.net (out49-ams.mf.surf.net [145.0.1.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F6E1B2AE4 for ; Tue, 24 Jun 2014 23:14:42 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s5P6Ed1p011220; Wed, 25 Jun 2014 08:14:39 +0200 Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 25 Jun 2014 08:14:43 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.31]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Wed, 25 Jun 2014 08:14:38 +0200 From: To: Thread-Topic: [geonet/its] do you have more comments on the geonet problem statement draft? Thread-Index: AQHPjxwcZngcSTSjEk2EO6XsXye1wJuAvEIAgACe7NU= Date: Wed, 25 Jun 2014 06:14:37 +0000 Message-ID: References: , <479CDE82-19BD-4FF2-9F33-3BBC847E7613@gmail.com> In-Reply-To: <479CDE82-19BD-4FF2-9F33-3BBC847E7613@gmail.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [95.224.118.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.49; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0vMiueDfP - e68ae36c41fc - 20140625 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/its/sRIlDsvq6mQDkccFPsIwtoYj_pE Cc: its@ietf.org Subject: Re: [geonet/its] do you have more comments on the geonet problem statement draft? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 06:14:46 -0000 Hi Dino, Thanks! Best regards, Georgios ________________________________________ Van: Dino Farinacci [farinacci@gmail.com] Verzonden: woensdag 25 juni 2014 0:45 Aan: Karagiannis, G. (EWI) CC: its@ietf.org Onderwerp: Re: [geonet/its] do you have more comments on the geonet problem= statement draft? I have no comments. Dino On Jun 23, 2014, at 12:48 PM, karagian@cs.utwente.nl wrote: > Hi all, > > Please note that I have tried to work out all the comments in the current= version of the Geonet problem statement draft. > > If you have any other comments, please let me know! > > Best regards, > Georgios > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its= From nobody Wed Jun 25 07:00:59 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3071B2CB0 for ; Wed, 25 Jun 2014 07:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.244 X-Spam-Level: ** X-Spam-Status: No, score=2.244 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44zL5QKobSZW for ; Wed, 25 Jun 2014 07:00:53 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 338241B2CAF for ; Wed, 25 Jun 2014 07:00:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,546,1400018400"; d="scan'208";a="27501925" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 25 Jun 2014 16:00:41 +0200 Received: from EXC-MBX02.tsn.tno.nl ([fe80::5836:4645:c512:f964]) by EXC-CASHUB01.tsn.tno.nl ([fe80::b855:be6:1aa8:4d0f%13]) with mapi id 14.03.0174.001; Wed, 25 Jun 2014 16:00:40 +0200 From: "Wissingh, B.F. (Bastiaan)" To: Alexandru Petrescu , Melinda Shore Thread-Topic: [geonet/its] Comments on Geonet problemstatement Thread-Index: AQHPN78Sux7+MZW43k+Mw3063a/Rrpt/NpgAgANVmQA= Date: Wed, 25 Jun 2014 14:00:40 +0000 Message-ID: References: <53A8261A.4020804@gmail.com> In-Reply-To: <53A8261A.4020804@gmail.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="iso-8859-1" Content-ID: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/its/WMk3LPCWi4X3pnS8JrATz6B1ujw Cc: "its@ietf.org" Subject: Re: [geonet/its] Comments on Geonet problemstatement X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 14:00:57 -0000 Hi Alex, No problem at all, thanks for your reply! > Bastiaan - is the I-D "Dissemination to RSU" including your description > above? The description above makes sense to me. About the =B3off-loading=B2 cases, it is currently not described within the I-D =B3Dissemination to RSU=B2 as I=B9m not sure whether it is specifically= for RSU=B9s as there might be other use-cases. But we can add it to a next version. Best regards, Bastiaan Op 23-06-14 15:05 schreef Alexandru Petrescu : >Hi Bastiaan, > >Sorry for late reply. I hoped participants to reply to your comments. >Absent that please allow me to reply. > >Le 04/03/2014 16:33, Wissingh, B.F. (Bastiaan) a =E9crit : >> Hi Alex, Melinda, All: >> >> After the discussions about the geonet charter held yesterday during the >> side meeting, I wanted to post some additional comments I have related >> to the current version of the geonet problemstatement to the mailing >> list in order to try and improve the problemstatement. Some of the >> comments are more related to textual improvements, while some are more >> content related. I=B9ve copied the related parts of the problem statement >> below. >> >> o) Mechanisms and protocol solutions are needed for >> the accurate representation of geographic areas using (1) >> geo-locators such as names and (2) geographiic physical coordinates. >> >> >> In the last sentence above, geographic is misspelled in the above part. > >Right. I think it is no longer the case in the geonet problem statement >draft. > >> o) Mechanisms and protocol solutions are needed to ensure >> that the IP addresses of access routers, roadside unit >> (RSUs), and so on can be accurately mapped to geographic >> area information (geo-locators, names, and geographic >> physical coordinates). Mapping data bases can be >> maintained at the source nodes, intermediate or edge >> nodes, and at specific IP locator nodes. >> >> >> Seems like it should be =B3roadside units=B2 on the second line in the a= bove >> part. > >Right. > >> o) Mechanisms and protocol solutions are needed to ensure >> that data packets generated by source nodes placed >> arbitrarily in the Internet can be forwarded over >> multiple hops by using, where possible, geographic >> physical coordinates of (1) the destination node(s) >> and/or (2) the intermediate nodes for the routing >> decisions, instead of using their IP addresses. (Note >> that in order to solve the above challenge it is NOT >> mandated that all nodes located on the path from source >> to destination nodes are able to forward packets using >> the geo-coordinates of (1) the destination node(s) and/or >> (2) the intermediate nodes for the routing >> decisions. This is emphasized by using the words "where >> possible".) >> >> >> As came forward a bit during the discussion yesterday, the above bullet >> seems to me that it suggests we want to be defining a new Routing >> Protocol or something. Maybe it=B9s just me, but as it was also suggested >> during the discussion yesterday would it be good to reformulate the >> above bullet tekst? > >Yes, this worry about Routing Protocol may be a blocking issue. I will >extract this in a separate email. > >> o) MUST be able to provide accurate representation of >> geographic areas using (1) standardized geolocators where >> available and/or (2) geographic physical coordinates. >> >> o) MUST be able to ensure that geographical area information >> (geo-locators, names and geographic physical coordinates) >> is accurately mapped to an IP address, even if the >> relation between geographical area information and IP >> address is not a one-to-one relationship. >> >> o) MUST be able to ensure that an IP address can be >> accurately mapped to a geographic area information >> (geo-locators, names and geographic physical >> coordinates), even if the relation between locator and >> geographical information is not a one-to-one >> relationship. >> >> >> It is a bit unclear/vague to me what exactly is meant by the term >> =B3accurate=B2. Is it more related to having the mapping up-to-date, or = for >> example that the mapping needs to be =B3square-meter=B2 or >> =B3square-centimeter=B2 precise? What are the ideas on this? > >The square-meter/centimeter would be "precision". Here at IETF we would >not focus on higher and higher precision. In a sense, IP addresses are >already 100% precise. > >Accuracy would be as simple as knowing where a particular IP address is >situated (compared to today's situation where we dont know much about >it), and maybe to have the mapping up-to-date. > >Or, otherwise, we can discuss the word accuracy, and see the levels of >accuracy of current system (we know some IP addresses belong to some >countries - accuracy=3D=3Dhundred square kilometers), and targeted levels = of >accuracy (to equal that of GPS, of Galileo, of Baidou, or that of >imagery sattelites). > >> >> o) Dissemination to a particular area >> >> In this use case a source node, which may be located anywhere, sends >> packets to a wireless access router through the Internet. Those >> wireless access routers are selected based on geographical location >> information, and traffic is routed to them using the IPv6 address of >> the router and conventional IP routing. Each of the destination >> access routers then copies and broadcasts the received packets to >> listeners within its radio coverage area. >> >> >> Do we really need to explicitly mention the using of the IPv6 address >> here? Or can we make it more general and call it an IP address? > >I would agree to call it an IP address. > >> o) Vehicular Traffic Safety, Efficiency, Management and Infotainment >> >> A source node, which may be located anywhere, sends traffic safety, >> traffic efficiency and management, and infotainment type of vehicular >> information to Road Side Units (RSUs) through the Internet. >> >> Those RSUs are preselected based on the geographical location >> information of the destination geographic area. The vehicular data >> traffic is routed to a RSU using its IPv6 address. >> >> >> Regarding the terminology throughout the Charter and the Problem >> statement, I don=B9t think we need to put definitions for all the terms = we >> use yet, but at least be consistent in the terminology. For example the >> term "Roadside Unit=B2 has passed the documents in multiple manners, e.g. >> Road-side unit, Road Side Unit, as well as Roadside Unit. I would =B3vot= e=B2 >> for using the latter one, so Roadside Unit. > >I agree. It is good to have "Roadside Unit" throughout. > >> And again, do we need to explicitly state the IPv6 address, or can we >> just say IP address? > >IP address should be fine. > >> Below, I=B9ve =B3tuned=B2 the Mobile RSU use-case a bit, see below. Does= it >> need some additional text explaining why an geonet mapping is important >> for this use-case? >> >> o) Mobile RSU >> >> Typically a Roadside Unit (RSU) is placed somewhere alongside a road for >> vehicles; an RSU gets a static >> geographical location which will most likely not be changed until the >> device either reaches its end of >> life or is no longer needed at that location; at that time it would be >> "torn down=B2 before moving to another >> location (other cases may apply). >> >> A so called 'Mobile Roadside Unit' on the other hand is portable and not >> =B3torn down" while moving, meaning >> that among other settings its geographical position adjusts according to >> the location where it is positioned. >> Such a 'Mobile Roadside Unit=B9 is very flexible for use in multiple >> situations. Examples of such situations include >> when a permanently installed unit fails and needs a temporarily backup >> unit or during road construction. In the >> latter case when at some location along a road there is ongoing road >> works, an operator could take a 'Mobile >> Roadside Unit', position it on a car at the beginning of the road works >> site, and start sending so called >> 'Road Works Warning=B9 messages with detailed information about the road >> works. Furthermore, in some cases the >> geographical position of it could change if the road works are slowly >> moving. >> >> Additionally, while data traffic could be forwarded along mobile RSUs in >> a multi-hop manner, less congested paths >> May use the fixed edge geonet-enabled routers of the Internet >>(off-loading). >> >> >> Last time the Mobile RSU use-case has been discussed, it has been >> decided to combine an additional use-case I mentioned about >> =B3off-loading=B2 with the Mobile RSU use-case. In the meantime I have b= een >> thinking some more about that off-loading case, and as it is not >> explicitly related to a Mobile RSU I am wondering whether we should >> combine it or take it as separate use case? Let me give a brief example >> again: >> >> For example, a car detects an accident in front of him on a certain >> high-way. In response it sends a =B3warning" message via 802.11p to the >> nearest roadside unit. Maybe there is some logic there that predicts a >> traffic jam based on that info and based on that wants to forward the >> warning message to a certain geographical location (for example earlier >> on the high-way where for example the high-way splits up), so that cars >> arriving at that geographical location can make a decision to continue >> their way and end up in the traffic jam, or take the split and avoid the >> traffic jam. > >Bastiaan - is the I-D "Dissemination to RSU" including your description >above? The description above makes sense to me. > >> >> The LISP WG mainly focusses mainly on network-layer-based protocol >> solutions that enable the separation of routing locators (where you >> are attached to the network) and identifiers (who you are) in one >> number space. Geonet mainly focusses on how IP routing and addressing >> uses geography parameters, like geographical coordinates to >> disseminate packets sent by a sender located anywhere in the Internet >> to nodes that are located in the area specified by these geography >> parameters. >> >> The ECRIT WG mainly focusses mainly on how location data and call >> routing information are used to enable communication between a user >> and a relevant emergency response center. In particular, the ECRIT WG >> has specified protocols to map emergency services identifiers and >> geodetic or civic location information to service contact URIs. >> Geonet mainly focusses on how IP routing and addressing uses geodetic >> or civic location information to disseminate packets sent by a sender >> located anywhere in the Internet to nodes that are located in the area >> specified by this geodetic or civic location information. >> >> >> Both the above paragraphs contain the word =B3mainly=B2 one time too muc= h in >> the first sentence. > >I agree. It is too much use of word "mainly". I think we should modify >the Internet Draft: >http://tools.ietf.org/html/draft-karagiannis-geonet-problem-statement-00 > >Alex > >> >> Hope this helps in getting forward, also if I can be of any help, please >> let me know! >> >> Bastiaan >> >> https://github.com/MelindaShore/geonet/blob/master/problemstatement.txt >> >> ** >> >> >> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u >> niet de geadresseerde bent of dit bericht abusievelijk aan u is >> toegezonden, wordt u verzocht dat aan de afzender te melden en het >> bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de >> inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor schade, >> van welke aard ook, die verband houdt met risico's verbonden aan het >> elektronisch verzenden van berichten. >> >> This message may contain information that is not intended for you. If >> you are not the addressee or if this message was sent to you by mistake, >> you are requested to inform the sender and delete the message. TNO >> accepts no liability for the content of this e-mail, for the manner in >> which you use it and for damage of any kind resulting from the risks >> inherent to the electronic transmission of messages. >> > > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de = wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verban= d houdt met risico's verbonden aan het elektronisch verzenden van berichten. = This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. From nobody Sun Jun 29 02:47:36 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6F21A0444 for ; Sun, 29 Jun 2014 02:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bm6jwqDvQGL3 for ; Sun, 29 Jun 2014 02:47:30 -0700 (PDT) Received: from out26-ams.mf.surf.net (out26-ams.mf.surf.net [145.0.1.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A183E1A043D for ; Sun, 29 Jun 2014 02:47:28 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s5T9lOk8022771; Sun, 29 Jun 2014 11:47:24 +0200 Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 29 Jun 2014 11:47:33 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.31]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Sun, 29 Jun 2014 11:47:24 +0200 From: To: , , Thread-Topic: [geonet/its] Comments on Geonet problemstatement Thread-Index: AQHPjuPfPKH+gGURXUiMY03JB7UIXZuBvGIAgAYjtcQ= Date: Sun, 29 Jun 2014 09:47:23 +0000 Message-ID: References: <53A8261A.4020804@gmail.com>, In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.91.134.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Bayes-Prob: 0.9999 (Score 4.7, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.48; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0uMk9Loyh - ba2db24474cf - 20140629 X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/its/kniDc7DIzQ07W6G3YQc_sgouP5w Cc: its@ietf.org Subject: Re: [geonet/its] Comments on Geonet problemstatement X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 09:47:34 -0000 Hi Bastiaan, Thanks!=20 I agree, before we update the problem statement draft we need to find out i= f the "off-loading" case is a new use case or not! Best regards, Georgios ________________________________________ Van: its [its-bounces@ietf.org] namens Wissingh, B.F. (Bastiaan) [bastiaan.= wissingh@tno.nl] Verzonden: woensdag 25 juni 2014 16:00 Aan: Alexandru Petrescu; Melinda Shore CC: its@ietf.org Onderwerp: Re: [geonet/its] Comments on Geonet problemstatement Hi Alex, No problem at all, thanks for your reply! > Bastiaan - is the I-D "Dissemination to RSU" including your description > above? The description above makes sense to me. About the =B3off-loading=B2 cases, it is currently not described within the I-D =B3Dissemination to RSU=B2 as I=B9m not sure whether it is specifically= for RSU=B9s as there might be other use-cases. But we can add it to a next version. Best regards, Bastiaan Op 23-06-14 15:05 schreef Alexandru Petrescu : >Hi Bastiaan, > >Sorry for late reply. I hoped participants to reply to your comments. >Absent that please allow me to reply. > >Le 04/03/2014 16:33, Wissingh, B.F. (Bastiaan) a =E9crit : >> Hi Alex, Melinda, All: >> >> After the discussions about the geonet charter held yesterday during the >> side meeting, I wanted to post some additional comments I have related >> to the current version of the geonet problemstatement to the mailing >> list in order to try and improve the problemstatement. Some of the >> comments are more related to textual improvements, while some are more >> content related. I=B9ve copied the related parts of the problem statemen= t >> below. >> >> o) Mechanisms and protocol solutions are needed for >> the accurate representation of geographic areas using (1) >> geo-locators such as names and (2) geographiic physical coordinates. >> >> >> In the last sentence above, geographic is misspelled in the above part. > >Right. I think it is no longer the case in the geonet problem statement >draft. > >> o) Mechanisms and protocol solutions are needed to ensure >> that the IP addresses of access routers, roadside unit >> (RSUs), and so on can be accurately mapped to geographic >> area information (geo-locators, names, and geographic >> physical coordinates). Mapping data bases can be >> maintained at the source nodes, intermediate or edge >> nodes, and at specific IP locator nodes. >> >> >> Seems like it should be =B3roadside units=B2 on the second line in the a= bove >> part. > >Right. > >> o) Mechanisms and protocol solutions are needed to ensure >> that data packets generated by source nodes placed >> arbitrarily in the Internet can be forwarded over >> multiple hops by using, where possible, geographic >> physical coordinates of (1) the destination node(s) >> and/or (2) the intermediate nodes for the routing >> decisions, instead of using their IP addresses. (Note >> that in order to solve the above challenge it is NOT >> mandated that all nodes located on the path from source >> to destination nodes are able to forward packets using >> the geo-coordinates of (1) the destination node(s) and/or >> (2) the intermediate nodes for the routing >> decisions. This is emphasized by using the words "where >> possible".) >> >> >> As came forward a bit during the discussion yesterday, the above bullet >> seems to me that it suggests we want to be defining a new Routing >> Protocol or something. Maybe it=B9s just me, but as it was also suggeste= d >> during the discussion yesterday would it be good to reformulate the >> above bullet tekst? > >Yes, this worry about Routing Protocol may be a blocking issue. I will >extract this in a separate email. > >> o) MUST be able to provide accurate representation of >> geographic areas using (1) standardized geolocators where >> available and/or (2) geographic physical coordinates. >> >> o) MUST be able to ensure that geographical area information >> (geo-locators, names and geographic physical coordinates) >> is accurately mapped to an IP address, even if the >> relation between geographical area information and IP >> address is not a one-to-one relationship. >> >> o) MUST be able to ensure that an IP address can be >> accurately mapped to a geographic area information >> (geo-locators, names and geographic physical >> coordinates), even if the relation between locator and >> geographical information is not a one-to-one >> relationship. >> >> >> It is a bit unclear/vague to me what exactly is meant by the term >> =B3accurate=B2. Is it more related to having the mapping up-to-date, or = for >> example that the mapping needs to be =B3square-meter=B2 or >> =B3square-centimeter=B2 precise? What are the ideas on this? > >The square-meter/centimeter would be "precision". Here at IETF we would >not focus on higher and higher precision. In a sense, IP addresses are >already 100% precise. > >Accuracy would be as simple as knowing where a particular IP address is >situated (compared to today's situation where we dont know much about >it), and maybe to have the mapping up-to-date. > >Or, otherwise, we can discuss the word accuracy, and see the levels of >accuracy of current system (we know some IP addresses belong to some >countries - accuracy=3D=3Dhundred square kilometers), and targeted levels = of >accuracy (to equal that of GPS, of Galileo, of Baidou, or that of >imagery sattelites). > >> >> o) Dissemination to a particular area >> >> In this use case a source node, which may be located anywhere, sends >> packets to a wireless access router through the Internet. Those >> wireless access routers are selected based on geographical location >> information, and traffic is routed to them using the IPv6 address of >> the router and conventional IP routing. Each of the destination >> access routers then copies and broadcasts the received packets to >> listeners within its radio coverage area. >> >> >> Do we really need to explicitly mention the using of the IPv6 address >> here? Or can we make it more general and call it an IP address? > >I would agree to call it an IP address. > >> o) Vehicular Traffic Safety, Efficiency, Management and Infotainment >> >> A source node, which may be located anywhere, sends traffic safety, >> traffic efficiency and management, and infotainment type of vehicular >> information to Road Side Units (RSUs) through the Internet. >> >> Those RSUs are preselected based on the geographical location >> information of the destination geographic area. The vehicular data >> traffic is routed to a RSU using its IPv6 address. >> >> >> Regarding the terminology throughout the Charter and the Problem >> statement, I don=B9t think we need to put definitions for all the terms = we >> use yet, but at least be consistent in the terminology. For example the >> term "Roadside Unit=B2 has passed the documents in multiple manners, e.g= . >> Road-side unit, Road Side Unit, as well as Roadside Unit. I would =B3vot= e=B2 >> for using the latter one, so Roadside Unit. > >I agree. It is good to have "Roadside Unit" throughout. > >> And again, do we need to explicitly state the IPv6 address, or can we >> just say IP address? > >IP address should be fine. > >> Below, I=B9ve =B3tuned=B2 the Mobile RSU use-case a bit, see below. Does= it >> need some additional text explaining why an geonet mapping is important >> for this use-case? >> >> o) Mobile RSU >> >> Typically a Roadside Unit (RSU) is placed somewhere alongside a road for >> vehicles; an RSU gets a static >> geographical location which will most likely not be changed until the >> device either reaches its end of >> life or is no longer needed at that location; at that time it would be >> "torn down=B2 before moving to another >> location (other cases may apply). >> >> A so called 'Mobile Roadside Unit' on the other hand is portable and not >> =B3torn down" while moving, meaning >> that among other settings its geographical position adjusts according to >> the location where it is positioned. >> Such a 'Mobile Roadside Unit=B9 is very flexible for use in multiple >> situations. Examples of such situations include >> when a permanently installed unit fails and needs a temporarily backup >> unit or during road construction. In the >> latter case when at some location along a road there is ongoing road >> works, an operator could take a 'Mobile >> Roadside Unit', position it on a car at the beginning of the road works >> site, and start sending so called >> 'Road Works Warning=B9 messages with detailed information about the road >> works. Furthermore, in some cases the >> geographical position of it could change if the road works are slowly >> moving. >> >> Additionally, while data traffic could be forwarded along mobile RSUs in >> a multi-hop manner, less congested paths >> May use the fixed edge geonet-enabled routers of the Internet >>(off-loading). >> >> >> Last time the Mobile RSU use-case has been discussed, it has been >> decided to combine an additional use-case I mentioned about >> =B3off-loading=B2 with the Mobile RSU use-case. In the meantime I have b= een >> thinking some more about that off-loading case, and as it is not >> explicitly related to a Mobile RSU I am wondering whether we should >> combine it or take it as separate use case? Let me give a brief example >> again: >> >> For example, a car detects an accident in front of him on a certain >> high-way. In response it sends a =B3warning" message via 802.11p to the >> nearest roadside unit. Maybe there is some logic there that predicts a >> traffic jam based on that info and based on that wants to forward the >> warning message to a certain geographical location (for example earlier >> on the high-way where for example the high-way splits up), so that cars >> arriving at that geographical location can make a decision to continue >> their way and end up in the traffic jam, or take the split and avoid the >> traffic jam. > >Bastiaan - is the I-D "Dissemination to RSU" including your description >above? The description above makes sense to me. > >> >> The LISP WG mainly focusses mainly on network-layer-based protocol >> solutions that enable the separation of routing locators (where you >> are attached to the network) and identifiers (who you are) in one >> number space. Geonet mainly focusses on how IP routing and addressing >> uses geography parameters, like geographical coordinates to >> disseminate packets sent by a sender located anywhere in the Internet >> to nodes that are located in the area specified by these geography >> parameters. >> >> The ECRIT WG mainly focusses mainly on how location data and call >> routing information are used to enable communication between a user >> and a relevant emergency response center. In particular, the ECRIT WG >> has specified protocols to map emergency services identifiers and >> geodetic or civic location information to service contact URIs. >> Geonet mainly focusses on how IP routing and addressing uses geodetic >> or civic location information to disseminate packets sent by a sender >> located anywhere in the Internet to nodes that are located in the area >> specified by this geodetic or civic location information. >> >> >> Both the above paragraphs contain the word =B3mainly=B2 one time too muc= h in >> the first sentence. > >I agree. It is too much use of word "mainly". I think we should modify >the Internet Draft: >http://tools.ietf.org/html/draft-karagiannis-geonet-problem-statement-00 > >Alex > >> >> Hope this helps in getting forward, also if I can be of any help, please >> let me know! >> >> Bastiaan >> >> https://github.com/MelindaShore/geonet/blob/master/problemstatement.txt >> >> ** >> >> >> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u >> niet de geadresseerde bent of dit bericht abusievelijk aan u is >> toegezonden, wordt u verzocht dat aan de afzender te melden en het >> bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de >> inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor schade, >> van welke aard ook, die verband houdt met risico's verbonden aan het >> elektronisch verzenden van berichten. >> >> This message may contain information that is not intended for you. If >> you are not the addressee or if this message was sent to you by mistake, >> you are requested to inform the sender and delete the message. TNO >> accepts no liability for the content of this e-mail, for the manner in >> which you use it and for damage of any kind resulting from the risks >> inherent to the electronic transmission of messages. >> > > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de = wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verban= d houdt met risico's verbonden aan het elektronisch verzenden van berichten= . This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its= From nobody Sun Jun 29 04:50:08 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD2E1A046A for ; Sun, 29 Jun 2014 04:50:06 -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 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 2z2vcG0R295K for ; Sun, 29 Jun 2014 04:50:02 -0700 (PDT) Received: from out28-ams.mf.surf.net (out28-ams.mf.surf.net [145.0.1.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01BAF1A0467 for ; Sun, 29 Jun 2014 04:50:01 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s5TBnxF4002130 for ; Sun, 29 Jun 2014 13:49:59 +0200 Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 29 Jun 2014 13:50:08 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.31]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.03.0181.006; Sun, 29 Jun 2014 13:49:58 +0200 From: To: Thread-Topic: New Version Notification for draft-karagiannis-geonet-dissemination-geo-areas-00.txt Thread-Index: AQHPk4+PjG0sSwwC20SEEFKnurMYO5uH+DJ9 Date: Sun, 29 Jun 2014 11:49:58 +0000 Message-ID: References: <20140629114441.19807.17147.idtracker@ietfa.amsl.com> In-Reply-To: <20140629114441.19807.17147.idtracker@ietfa.amsl.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.91.134.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.48; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0uMkbNX5G - 8a3a02819171 - 20140629 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/its/00HXfoMKNTnkFlTjXuj3AYt1724 Subject: [geonet/its] FW: New Version Notification for draft-karagiannis-geonet-dissemination-geo-areas-00.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 11:50:06 -0000 Hi all, Please note that we have submitted the following Internet draft that descri= bes the use case where IP packets are disseminated to geographical areas, b= ased on geographical location information. A source node, which may be loca= ted anywhere, sends packets to an access router through the Internet. Those= access routers are selected based on geographical location information, an= d traffic is routed to them using the IP address of the router and conventi= onal IP routing. Each of the destination access routers then copies and bro= adcasts the received packets to listeners within its (1) radio coverage fo= r wireless access routers or (2) IP subnet for wired access routers. The URL is: http://www.ietf.org/internet-drafts/draft-karagiannis-geonet-dissemination= -geo-areas-00.txt =20 Comments are welcome! Best regards, Georgios ________________________________________ Van: internet-drafts@ietf.org [internet-drafts@ietf.org] Verzonden: zondag 29 juni 2014 13:44 Aan: Geert Heijenk; Karagiannis, G. (EWI); Geert Heijenk; Karagiannis, G. (= EWI) Onderwerp: New Version Notification for draft-karagiannis-geonet-disseminat= ion-geo-areas-00.txt A new version of I-D, draft-karagiannis-geonet-dissemination-geo-areas-00.t= xt has been successfully submitted by Georgios Karagiannis and posted to the IETF repository. Name: draft-karagiannis-geonet-dissemination-geo-areas Revision: 00 Title: Use case: Dissemination of IP packets to geographical areas Document date: 2014-06-30 Group: Individual Submission Pages: 5 URL: http://www.ietf.org/internet-drafts/draft-karagiannis-geone= t-dissemination-geo-areas-00.txt Status: https://datatracker.ietf.org/doc/draft-karagiannis-geonet-d= issemination-geo-areas/ Htmlized: http://tools.ietf.org/html/draft-karagiannis-geonet-dissemi= nation-geo-areas-00 Abstract: This document describes the use case where IP packets are disseminated to geographical areas, based on geographical location information. A source node, which may be located anywhere, sends packets to an access router through the Internet. Those access routers are selected based on geographical location information, and traffic is routed to them using the IP address of the router and conventional IP routing. Each of the destination access routers then copies and broadcasts the received packets to listeners within its (1) radio coverage for wireless access routers or (2) IP subnet for wired access routers. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat=