From nobody Wed Apr 16 07:44:02 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 38FE51A0132 for ; Wed, 16 Apr 2014 07:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.624 X-Spam-Level: X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272] 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 4OMhiH2L4dYQ for ; Wed, 16 Apr 2014 07:43:52 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id A6A571A019B for ; Wed, 16 Apr 2014 07:43:50 -0700 (PDT) X-IronPort-AV: E=Sophos; i="4.97,872,1389740400"; d="scan'208,217"; a="24289584" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 16 Apr 2014 16:43:47 +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.0123.003; Wed, 16 Apr 2014 16:43:46 +0200 From: "Wissingh, B.F. (Bastiaan)" To: Carl Reed , Melinda Shore , Alexandru Petrescu , "its@ietf.org" Thread-Topic: [geonet/its] Comments on Geonet problem statement Thread-Index: AQHPN8jGmXzajsQRLEGx2jIHdzU5E5sUlPQA Date: Wed, 16 Apr 2014 14:43:46 +0000 Message-ID: References: <03A8A16D362C468399F38665C4187C53@OfficeHP> In-Reply-To: <03A8A16D362C468399F38665C4187C53@OfficeHP> 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: multipart/alternative; boundary="_000_CF746050861Fbastiaanwissinghtnonl_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/its/ZW0LyYMB9gQsyD9CWQKpBPOPlig 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: Wed, 16 Apr 2014 14:43:57 -0000 --_000_CF746050861Fbastiaanwissinghtnonl_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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_CF746050861Fbastiaanwissinghtnonl_ Content-Type: text/html; charset="Windows-1252" Content-ID: <23A6DA139898FD468BAA8452B9E573C4@tno.nl> Content-Transfer-Encoding: quoted-printable
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 Aan: Bastiaan Wissingh <bastiaan.wissingh@tno.nl>, Meli= nda Shore <melinda.shore@gmai= l.com>, Alexandru Petrescu <alexandru.petrescu@gmail.com>
CC: "its@ietf.org" <its@ietf.= org>
Onderwerp: Re: [geonet/its] Comment= s 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 specif= ied 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/rfc5491). Not sur= e 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 pr=
otocol solutions are needed for
   the accurate r=
epresentation 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 pr=
otocol solutions are needed to ensure
   that the =
IP addresses of access routers, roadside unit
  =
 (RSUs), and so on can be accurately mapped to geographic
&n=
bsp;  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 pr=
otocol solutions are needed to ensure
   that data=
 packets generated by source nodes placed
   arbit=
rarily in the Internet can be forwarded over
   mu=
ltiple hops by using, where possible, geographic
  =
; physical coordinates of (1) the destination node(s)
 =
  and/or (2) the intermediate nodes for the routing
&nb=
sp;  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 so=
urce
   to destination nodes are able to forward p=
ackets using
   the geo-coordinates of (1) the des=
tination node(s) and/or
   (2) the intermediate no=
des for the routing
   decisions. This is emphasiz=
ed 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 p=
rovide accurate representation of
   geographic ar=
eas using (1) standardized geolocators where
   av=
ailable and/or (2) geographic physical coordinates.
 
o) MUST be able to ensure that geographical area information<=
/div>
   (geo-locators, names and geographic physical co=
ordinates)
   is accurately mapped to an IP addres=
s, even if the
   relation between geographical ar=
ea information and IP
   address is not a one-to-o=
ne relationship.
 
o) MUST be able to en=
sure that an IP address can be
   accurately map=
ped to a geographic area information
   (geo-locat=
ors, names and geographic physical
   coordinates)=
, even if the relation between locator and
   geog=
raphical information is not a one-to-one
   relati=
onship.
 
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
w=
ireless access routers are selected based on geographical location
information, and traffic is routed to them using the IPv6 address o=
f
the router and conventional IP routing. Each of the dest= ination
access routers then copies and broadcasts the recei= ved 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 Traffi=
c Safety, Efficiency, Management and Infotainment
 
A source node, which may be located anywhere, sends traffic s=
afety,
traffic efficiency and management, and infotainment =
type of vehicular
information to Road Side Units (RSUs) thr=
ough the Internet.
 
Those RSUs are pr=
eselected based on the geographical location 
information =
of the destination geographic area. The vehicular data
traf=
fic 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 road for vehicles; an RSU gets a static
geographical location which will most likely not be changed until the d=
evice either reaches its end of 
life or is no longer neede=
d at that location; at that time it would be "torn down=94 before movi=
ng to another
location (other cases may apply).  
 
A so called 'Mobile Roadside Unit' on th=
e other hand is portable and not =93torn down" while moving, meaning <=
/div>
that among other settings its geographical position adjusts=
 according to the location where it is positioned.  
S=
uch a 'Mobile Roadside Unit=92 is very flexible for use in multiple situati=
ons.  Examples of such situations include 
when a permanent=
ly installed unit fails and needs a temporarily backup unit or during road =
construction. In the 
latter case when at some location alo=
ng 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 r=
oad works site, and start sending so called
'Road Works War=
ning=92 messages with detailed information about the road works. Furthermor=
e, in some cases the
geographical position of it could chan=
ge if the road works are slowly moving.
 
Additionally, while data traffic could be forwarded along mobile RSUs i=
n a multi-hop manner, less congested paths 
May use the fix=
ed 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 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
ar=
e 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 t=
o
disseminate packets sent by a sender located anywhere in =
the Internet
to nodes that are located in the area specifie=
d by these geography
parameters.
 
The ECRIT WG mainly focusses mainly on how location data and c=
all
routing information are used to enable communication be=
tween a user
and a relevant emergency response center. In p=
articular, the ECRIT WG
has specified protocols to map emer=
gency 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 lo=
cation 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
 




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 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 result= ing from the risks inherent to the electronic transmission of messages.

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