From nobody Tue Mar 4 07:33: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 BDE1F1A00AD for ; Tue, 4 Mar 2014 07:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.548 X-Spam-Level: * X-Spam-Status: No, score=1.548 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] 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 qLIjpQ5P6k3g for ; Tue, 4 Mar 2014 07:33:32 -0800 (PST) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6B51A00F1 for ; Tue, 4 Mar 2014 07:33:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.97,585,1389740400"; d="scan'208,217";a="3540662" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 04 Mar 2014 16:33:21 +0100 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; Tue, 4 Mar 2014 16:33:21 +0100 From: "Wissingh, B.F. (Bastiaan)" To: Melinda Shore , Alexandru Petrescu Thread-Topic: [geonet/its] Comments on Geonet problemstatement Thread-Index: AQHPN78Sux7+MZW43k+Mw3063a/Rrg== Date: Tue, 4 Mar 2014 15:33:20 +0000 Message-ID: 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_CF3B8F456D7Fbastiaanwissinghtnonl_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/its/J5QSlw3ZQEBpmFlWxQ4hXzXRSv0 Cc: "its@ietf.org" Subject: [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: Tue, 04 Mar 2014 15:33:38 -0000 --_000_CF3B8F456D7Fbastiaanwissinghtnonl_ MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable 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. --_000_CF3B8F456D7Fbastiaanwissinghtnonl_ Content-ID: <8704BB75412B7E408DF47AE0798BFB21@tno.nl> MIME-Version: 1.0 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
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 an=
d protocol solutions are needed for
   the a=
ccurate representation of geographic areas using (1)
 =
  geo-locators such as names and (2) geographiic physical coordin=
ates.

In the last sentence above, geographic is misspelled in the above part. 

o) Mechanisms an=
d protocol solutions are needed to ensure
   =
;that the IP addresses of access routers, roadside unit
&nb=
sp;  (RSUs), and so on can be accurately mapped to geographic
   area information (geo-locators, names, and g=
eographic
   physical coordinates).  Mapping=
 data bases can be
   maintained at the sour=
ce nodes, intermediate or edge
   nodes, a=
nd at specific IP locator nodes.

Seems like it should be =93roadside units=94 on the second line in the abov= e part.

o) Mechanisms an=
d protocol solutions are needed to ensure
   =
;that data packets generated by source nodes placed
 &=
nbsp; arbitrarily in the Internet can be forwarded over
   physical coordinates of (1) the destination n=
ode(s)
   and/or (2) the intermediate nodes =
for the routing
   decisions, instead of usi=
ng their IP addresses.  (Note
   that in ord=
er to solve the above challenge it is NOT
   =
;mandated that all nodes located on the path from source
&n=
bsp;  to destination nodes are able to forward packets using
   the geo-coordinates of (1) the destination no=
de(s) and/or
   (2) the intermediate nodes f=
or the routing
   decisions. This is emphasi=
zed by using the words "where
   possib=
le".)

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
   geo=
graphic areas using (1) standardized geolocators where
&nbs=
p;  available and/or (2) geographic physical coordinates.

o) MUST be = able to ensure that geographical area information
 &nb= sp; (geo-locators, names and geographic physical coordinates)
   is accurately mapped to an IP address, even if th= e
   relation between geographical area info= rmation and IP
   address is not a one-to-on= e 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 physic= al
   coordinates), even if the relation bet= ween locator and
   geographical information= is not a one-to-one
   relationship.
<= /pre>

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) Disseminatio=
n to a particular area

In this use case a source node, which may be located a=
nywhere, sends
packets to a wireless access router through=
 the Internet.  Those
wireless access routers are selected=
 based on geographical location
information, and traffic i=
s routed to them using the IPv6 address of
the router and =
conventional IP routing.  Each of the destination
access r=
outers then copies and broadcasts the received packets to







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 Tr=
affic Safety, Efficiency, Management and Infotainment

A source node, which ma=
y be located anywhere, sends traffic safety,
traffic effic=
iency and management, and infotainment type of vehicular
i=
nformation to Road Side Units (RSUs) through the Internet.
Those RSUs are preselected based on the geographica=
l 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 "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

Typ=
ically a Roadside Unit (RSU) is placed somewhere alongside a road for vehic=
les; 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 ti=
me it would be "torn down=94 before moving to another

A so called 'Mobile Roadside Unit' on the other hand is portable and=
 not =93torn down" while moving, meaning 
that a=
mong other settings its geographical position adjusts according to the loca=
tion where it is positioned.  
Such a 'Mobile Roadsid=
e Unit=92 is very flexible for use in multiple situations.  Examples of suc=
h situations include 
when a permanently installed un=
it fails and needs a temporarily backup unit or during road construction. I=
n 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 work=
s site, and start sending so called
'Road Works Warning=92=
 messages with detailed information about the road works. Furthermore, in s=
ome cases the
geographical position of it could change if =
the road works are slowly moving.

Additionally, while data traffic could be f=
orwarded along mobile RSUs in a multi-hop manner, less congested paths =
;
May use the fixed edge geonet-enabled routers of the Int=
ernet (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 example=
, a car detects an accident in front of him on a certain high-way. In respo=
nse it sends a =93warning" 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 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 mai=
nly focusses mainly on network-layer-based protocol
soluti=
ons 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 add=
ressing
uses geography parameters, like geographical coord=
inates to
disseminate packets sent by a sender located any=
where in the Internet
to nodes that are located in the are=
a specified by these geography
parameters.

The ECRIT WG mai=
nly focusses mainly on how location data and call
routing =
information are used to enable communication between a user
has specified protocols to map emergency services identifiers=
 and
geodetic or civic location information to service con=
tact URIs.
Geonet mainly focusses on how IP routing and ad=
dressing uses geodetic
or civic location information to di=
sseminate 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 b=
ericht 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. TN=
O 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 hou=
dt met risico's verbonden aan het elektronisch verzenden van berichten.
=



 


This m=
essage 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 reque=
sted 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 tran=
smission of messages.




--_000_CF3B8F456D7Fbastiaanwissinghtnonl_--


From nobody Tue Mar  4 08:42:28 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 30C8E1A01A8 for ; Tue,  4 Mar 2014 08:42:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.322
X-Spam-Level: 
X-Spam-Status: No, score=0.322 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, 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 g6uVz1_FbjOj for ; Tue,  4 Mar 2014 08:42:21 -0800 (PST)
Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id 624681A01EE for ; Tue,  4 Mar 2014 08:42:21 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 8ACE094159; Tue,  4 Mar 2014 11:42:17 -0500 (EST)
X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net
Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdD3mupdYYEn; Tue,  4 Mar 2014 11:42:15 -0500 (EST)
Received: from mail2.standardsmail.org (mail2.standardsmail.org [66.244.86.41]) by mail.opengeospatial.org (Postfix) with ESMTP id B972B9414E; Tue,  4 Mar 2014 11:42:15 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by mail2.standardsmail.org (Postfix) with ESMTP id B2EB2FA5673; Tue,  4 Mar 2014 11:42:15 -0500 (EST)
Received: from mail2.standardsmail.org ([127.0.0.1]) by localhost (mail2.standardsmail.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id gulgx9q7isih; Tue,  4 Mar 2014 11:42:13 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by mail2.standardsmail.org (Postfix) with ESMTP id D28BDFA566B; Tue,  4 Mar 2014 11:42:13 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail2.standardsmail.org
Received: from mail2.standardsmail.org ([127.0.0.1]) by localhost (mail2.standardsmail.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id frVLdKGaf-u8; Tue,  4 Mar 2014 11:42:13 -0500 (EST)
Received: from OfficeHP (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail2.standardsmail.org (Postfix) with ESMTPSA id 0C45EFA5481; Tue,  4 Mar 2014 11:42:12 -0500 (EST)
Message-ID: <03A8A16D362C468399F38665C4187C53@OfficeHP>
From: "Carl Reed" 
To: "Wissingh, B.F. \(Bastiaan\)" , "Melinda Shore" , "Alexandru Petrescu" 
References: 
In-Reply-To: 
Date: Tue, 4 Mar 2014 09:13:26 -0700
Organization: OGC
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0CB4_01CF378A.00376A80"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3555.308
X-MIMEOLE: Produced By Microsoft MimeOLE V15.4.3555.308
Archived-At: http://mailarchive.ietf.org/arch/msg/its/Oka-SfYLuDnYrTlN5_tYe0Ei0Lg
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: Tue, 04 Mar 2014 16:42:26 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0CB4_01CF378A.00376A80
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Alex and Melinda

Another minor nit for =93mechanisms and protocol=94 sentence. remove =
=93physical=94. This is redundant. The definition of a geographic =
coordinate 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 =
coordinate=94 (https://tools.ietf.org/html/rfc5491). Not sure if you =
wish to be consistent.

Regards

Carl


From: Wissingh, B.F. (Bastiaan)=20
Sent: Tuesday, March 04, 2014 8:33 AM
To: Melinda Shore ; Alexandru Petrescu=20
Cc: its@ietf.org=20
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=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 =
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=92s 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 =
=93accurate=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, sendspackets to a wireless access router =
through the Internet.  Thosewireless access routers are selected based =
on geographical locationinformation, and traffic is routed to them using =
the IPv6 address ofthe router and conventional IP routing.  Each of the =
destinationaccess routers then copies and broadcasts the received =
packets tolisteners 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 vehicularinformation =
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 datatraffic 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, but at least be consistent in the terminology. For example =
the term "Roadside 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 for this use-case?

o) Mobile RSU Typically a Roadside Unit (RSU) is placed somewhere =
alongside a road for vehicles; an RSU gets a staticgeographical 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=94 before moving to anotherlocation (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 the location =
where it is positioned.  Such a 'Mobile Roadside Unit=92 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 'MobileRoadside Unit', position 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 works. Furthermore, in =
some cases thegeographical 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 =
=93off-loading=94 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 =93warning" 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 =
protocolsolutions that enable the separation of routing locators (where =
youare attached to the network) and identifiers (who you are) in =
onenumber space.  Geonet mainly focusses on how IP routing and =
addressinguses geography parameters, like geographical coordinates =
todisseminate packets sent by a sender located anywhere in the =
Internetto nodes that are located in the area specified by these =
geographyparameters. The ECRIT WG mainly focusses mainly on how location =
data and callrouting information are used to enable communication =
between a userand a relevant emergency response center. In particular, =
the ECRIT WGhas specified protocols to map emergency services =
identifiers andgeodetic or civic location information to service contact =
URIs.Geonet mainly focusses on how IP routing and addressing uses =
geodeticor civic location information to disseminate packets sent by a =
senderlocated anywhere in the Internet to nodes that are located in the =
areaspecified by this geodetic or civic location information.
Both the above paragraphs contain the word =93mainly=94 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.


=20

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

------=_NextPart_000_0CB4_01CF378A.00376A80
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable









Alex and Melinda


 


Another minor nit for =93mechanisms and protocol=94 sentence. =
remove=20
=93physical=94. This is redundant. The definition of a geographic =
coordinate system=20
is:


 


=93a coordinate=20
system that enables every location on the Earth to be specified by a =
set of=20
numbers or letters.=94


 


Also, the PIDF Location Object (LO) uses the term =93geodetic =
coordinate=94 (https://tools.ietf.org/html/=
rfc5491).=20
Not sure if you wish to be consistent.


 


Regards



Carl


 





 





Sent: Tuesday, March 04, 2014 8:33 AM


To: Melinda Shore ; Alexandru Petrescu =




Subject: [geonet/its] Comments on Geonet=20
problemstatement


 


Hi=20
Alex, Melinda, All:

 
After=20 the discussions about the geonet charter held yesterday during the side = meeting,=20 I wanted to post some additional comments I have related to the current = version=20 of the geonet problemstatement to the mailing list in order to try and = improve=20 the problemstatement. Some of the comments are more related to textual=20 improvements, while some are more content related. I=92ve copied the = related parts=20 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=20 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=20 like it should be =93roadside units=94 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=20 came forward a bit during the discussion yesterday, the above bullet = seems to me=20 that it suggests we want to be defining a new Routing Protocol or = something.=20 Maybe it=92s just me, but as it was also suggested during the discussion = yesterday=20 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=20 is a bit unclear/vague to me what exactly is meant by the term = =93accurate=94. Is it=20 more related to having the mapping up-to-date, or for example that the = mapping=20 needs to be =93square-meter=94 or =93square-centimeter=94 precise? What = are the ideas on=20 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=20 we really need to explicitly mention the using of the IPv6 address here? = Or can=20 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=20 the terminology throughout the Charter and the Problem statement, I = don=92t think=20 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=94 = has passed=20 the documents in multiple manners, e.g. Road-side unit, Road Side Unit, = as well=20 as Roadside Unit. I would =93vote=94 for using the latter one, so = Roadside=20 Unit.   And=20 again, do we need to explicitly state the IPv6 address, or can we just = say IP=20 address?   Below,=20 I=92ve =93tuned=94 the Mobile RSU use-case a bit, see below. Does it = need some=20 additional text explaining why an geonet mapping is important for this=20 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=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 the =
location where it is positioned.  
Such a =
'Mobile Roadside Unit=92 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=92 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=20 time the Mobile RSU use-case has been discussed, it has been decided to = combine=20 an additional use-case I mentioned about =93off-loading=94 with the = Mobile RSU=20 use-case. In the meantime I have been thinking some more about that = off-loading=20 case, and as it is not explicitly related to a Mobile RSU I am wondering = whether=20 we should combine it or take it as separate use case? Let me give a = brief=20 example again:   For example, a = car detects=20 an accident in front of him on a certain high-way. In response it sends = a=20 =93warning" message via 802.11p to the nearest roadside unit. Maybe = there is some=20 logic there that predicts a traffic jam based on that info and based on = that=20 wants to forward the warning message to a certain geographical location = (for=20 example earlier on the high-way where for example the high-way splits = up), so=20 that cars arriving at that  geographical location can make a = decision to=20 continue their way and end up in the traffic jam, or take the split and = avoid=20 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=20 the above paragraphs contain the word =93mainly=94 one time too much in = the first=20 sentence.   Hope=20 this helps in getting forward, also if I can be of any help, please let = me=20 know!   Bastiaan   https://github.com/MelindaShore/geonet/blob/master/problemstateme= nt.txt




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

 

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

_______________________________________________
its mailing=20 list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
------=_NextPart_000_0CB4_01CF378A.00376A80-- From nobody Sat Mar 8 14:53:15 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 2C7A31A02F0 for ; Sat, 8 Mar 2014 14:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0wHMP0aD9qb for ; Sat, 8 Mar 2014 14:53:00 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id 353011A02A8 for ; Sat, 8 Mar 2014 14:53:00 -0800 (PST) Received: from sandelman.ca (unknown [209.87.252.140]) by relay.sandelman.ca (Postfix) with ESMTPS id DF0E922077; Sat, 8 Mar 2014 17:52:54 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 85E43CA0F0; Sat, 8 Mar 2014 15:03:42 -0500 (EST) From: Michael Richardson To: Alexandru Petrescu In-reply-to: <527AE393.3090502@gmail.com> References: <527AE393.3090502@gmail.com> Comments: In-reply-to Alexandru Petrescu message dated "Thu, 07 Nov 2013 01:49:23 +0100." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sat, 08 Mar 2014 15:03:42 -0500 Message-ID: <11979.1394309022@sandelman.ca> Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/its/B3pttMu1aVDFCI8xTlosKY2yK-I Cc: "its@ietf.org" Subject: Re: [geonet/its] [its] minutes of the 'geonet' BoF meeting - please correct where wrong 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: Sat, 08 Mar 2014 22:53:03 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Alexandru Petrescu wrote: > Please see below the minutes of the 'geonet' BoF. Please correct were > necessary. ... > Question: IEEE 1609 does not make the documents available. We need to > make them available. Because its related. > Answer: this is an issue and we need help with the liason with IEEE. > Liaison: we will address it. did documents become available? =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJTG3ebAAoJEKD0KQ7Gj3P2puAH/AkH60zkFZ3Z9S0ufu4uMLKP CApjAC3ex0+cXp7VAo93vBKB12Nmk4AhymatxasSYkGidXizt9R4qD7TDkTh5XTi 7b3BivwTy6i9X20feQ6Y2JUR9mMdqsv25yxWMqOLFVlRCfwuiPKE8Z+Vg+DiRwFv 2euTearnNM8l6kz5vxXZSAx4T5FXcEiWF4CYNWJSvWLZXq2nmtuYPkymwB1w9sGP WJSmjOk6A7gDotUn3ovtmpB/SbURvvqz+k+Ma3mqKLUVYrwH1/k+SLv1yIXk0scM w8/6ZIl9V8h8yS3hDd3w5BxnTpS4+pKIP6TFcL7XM+7yM5XiGZZYlJvr47V/gbQ= =LGtz -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Mar 8 19:23:48 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 ED0F51A030B for ; Sat, 8 Mar 2014 19:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYMpnU3tVudn for ; Sat, 8 Mar 2014 19:23:43 -0800 (PST) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D25821A0309 for ; Sat, 8 Mar 2014 19:23:42 -0800 (PST) Received: by mail-yh0-f44.google.com with SMTP id f10so1251712yha.31 for ; Sat, 08 Mar 2014 19:23:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZKJ2adxonI0xHHjsoIHNLMg8CWcm2wfN2H9M7j+SL4A=; b=O5PPys0mwGcdYpVa8JcZqZ2g2iSyl24+cYOm8Vs4zJg+Ih1neSOLiQWEX+4d5XkNKm MmTu4wVvFnILvNmnwqeJXZ2OM4DB1CIvVxXTbZmxK/XYtvL88v/Iang88VckAYTC9bT7 JFJu3CRx9Bc8qsnVfxMe4DKSvQsweR213ngWhz1HBAK1pJnbjCimotU6YblOjGpaKkIA zFxk2sYVXF3Is50HN1kzcMwjJAPEE9cISWlR88duMAVzO+rIQVc0RwvzCEhy/+Jj1f2T 5rBkp1AC9hmqRip9fWDhtiFwpcFzR2KtK5PQWwE/vfhqAOkX7NyAE+gev9ryCMp1pz37 feYA== MIME-Version: 1.0 X-Received: by 10.236.90.65 with SMTP id d41mr34904916yhf.28.1394335417688; Sat, 08 Mar 2014 19:23:37 -0800 (PST) Received: by 10.170.202.7 with HTTP; Sat, 8 Mar 2014 19:23:37 -0800 (PST) In-Reply-To: <527AE393.3090502@gmail.com> References: <527AE393.3090502@gmail.com> Date: Sun, 9 Mar 2014 03:23:37 +0000 Message-ID: From: Abdussalam Baryun To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=20cf3010e53544e71904f42403db Archived-At: http://mailarchive.ietf.org/arch/msg/its/7WCgFfaFRttbQXUCOmxhv5wf6TY Cc: "its@ietf.org" Subject: Re: [geonet/its] [its] minutes of the 'geonet' BoF meeting - please correct where wrong 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, 09 Mar 2014 03:23:46 -0000 --20cf3010e53544e71904f42403db Content-Type: text/plain; charset=ISO-8859-1 Hi Alex Thanks for the update. The minutes is not showing names of who asked what. Is It it one person asking and answering. It seems like the agenda did not focus discussion on the ITS documents and its active docs. Why not? Comments below AB On Thursday, November 7, 2013, Alexandru Petrescu wrote: > Hello ITSers, > > Thanks to the minute takers. > > Please see below the minutes of the 'geonet' BoF. Please correct were > necessary. > > Following these correcitons I must upload them on the Proceedings of the > IETF88 soon. > > Thanks, > > Alex > ----------------------------------------------------------------------- > > IETF Geonet BOF minutes > > Nov 5 2013 > > 1:00 to 2:00 PM pacific time > > Note taker: Mike Kallas > > Agenda shown > Note Well slide displayed to room. > Margaret could not make it > Agenda shown > Webex is up > > Alex: Introductions. > > Internet wide geo networking > > Explained other related work by other groups > > Disseminating IP packets to geographical areas. Or receiving IP > packets from a geographical area. > > Problem statement draft presented by Georgios Karagiannis > > Georgios: Challenges presented in the problem statement is not > addressed by IETF or any other bodies > > Lost protocol: Location to service mapping > > Two solution presented have actual implementations > > Suggestion: List all the related working groups > Answer: no working group working on the exact same problem > > Question: both use cases similar to ETSI scope. I don t see a wider > coverage than the ad hoc implementation. Which use case? What is AD hoc implementation? > Why not use ETSI Answer: > short range only. Source has to be close to the area. This is internet > wide solution: provide that ability to any source on the internet to > send information to geographic areas. > > Question: Bob (Verizon) this is how things work right. What about when > things go wrong? What about malicious events. Like to see attack > review, failure nodes scenarios. Answer: Security and privacy are > very important. We have to focus on it Disagree, we focus on solutions for each use case or each problem statement. We then focus such solution with scenarios if things go wrong of attacks only in security consideration section. > > Next on the Agenda: implementation Interest: presentation. > > Last topic: IPv6 over 802.11p. Presentation > > End of presentation part. Who presented and what did the presenter say. This is not minute writing, I did not attend but did not benefit from this minute. Minutes are written for others who did not attend so they understand what was said exactly. > > Interest, clarifications. > > Question: problem not well defined. Is it: enumerate IP addresses that > are currently in a geographical area to send to. > > Answer: its is one of the potential solutions. > > Answer: need to better define the problem statement. Need to learn > geographic proximity of certain devices and leave it at a high level > (not just IP) other options are possible. Agree > > Answer: looking at a relationship between IP addresses and locations > of Access Routers. Agree, This is our solutions aim. > > Question: requirements around trust model on the geographic database? > Are the set of networks all part of the same organization or people > who don't trust each other? Multiple network providers? Could > affect trust model > > Answer: both are relevant. Security is very important. Trust with > respect to positioning is different from security as defined in > IETF. Precision is also a factor. Trust of position: precision should > be part of the discussion. Main concern not who owns IP but where it > is > > Question: uniqueness vs non uniqueness and indirection in > addressing. For example who is moving and who is not. ILNP tries to do > indirection. Other issues are privacy: present information without > identifying person. You may not want symmetric behavior V2x different > mechanism from x2V. > > Answer: thank you. Agree on non symmetry. Need to take ILNP into > account in addition to others. DNS, LOST > > Question: Guarantees. Are you only sending to the area. Is it ok it > reaches outside the area? Are you expecting error messages if the > message does not reach? > > Answer: Reliability of delivery important > > Question: one of the use cases was querying? How do you identify what > nodes you want to query? > > Answer: example fire detectors, temperature, wind > > Question: translation between geo and IP very important. What about > translating from IP address to geo? May be nice to have the solution > for both. > > Answer: yes > > Question: IEEE 1609 does not make the documents available. We need to > make them available. Because its related. > > Answer: this is an issue and we need help with the liason with IEEE. > Liaison: we will address it. > > Question: skeptical about problem. Geographical routing vs optimal routing. > > Answer: an optimal IP routing is different from geographic > positioning. Optimal route may not be possible > > > Stop discussion: need to figure out what will happen next > > How many people read the problem statement: only a few > How many saw the charter: a few Why few, I think because the group did not progress in leadership skills. We need leadership documents or someone who can lead the group to one vision. Then we are work together toward that vision. Hope that IESG did not discourage our before agreed vision. > Is there work appropriate to the ietf: a few, some reluctance > Not appropriate for IETF: one person only Not understood, please help, what is the document related? > > Scope seems to still be too broad. Is it ready? What is the scope please point to something? > > Who is interested in working on this? Several people (20) Add me so 21. > > There is a mailing list including discussing scope > http://ietf.org/mailman/listinfo/its > > Question: there is interest but are we ready to say go? We should not > drop it. Is the next step another BOF? I recommend the next step is to stick to one vision of use cases and possible solutions that have clear scope (the word scope was the reason why the group did not make it to IESG mind as far as information announced). > > Interesting in a broad sense but the scope is too wide. Need to narrow > scope. Is there application level stuff needed. Who is capable of > handling the received data. Yes, I want to ask Alex to handle the scope issues, please. > > Ted: have heard there is interest, haven't heard there is a go, but > there honestly this is not a drop issue, next step is maybe another > bof. Thanks. > > Last word: thanks to BOF chairs. Couple of very interesting problems: > actions to move it forward: I recommend a vision for solutions direction, so please one direction. Then each solution to be scoped, then each scope documented in one document. Please note that IESG should clarify do they want us to scope the problems or scope the solutions, I think they want all, IMHO, we should have few main problems, and each problem may have different issues to address. Each document has a solution. > > Crisp problem statement, a little of solutioneering, iteration on > problems and solutions need to be gone through. More detailed problem > statement more specifity. Look for any existing work. And help limit > the scope of things needed to be done. I don't see any decision made by the group, we need to make decisions to progress our action or scope every thing ;-) --20cf3010e53544e71904f42403db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alex

Thanks for the update.=A0The minutes is not = showing names of who asked what. Is=A0It it one person asking and answering= . It seems like the agenda did not focus discussion on the ITS documents an= d its active docs. Why not?

Comments below

AB
On Thursday, November 7, 2013, Alexandru Petrescu wrote:
Hello ITSers,

Thanks to the minute takers.

Please see below the minutes of the 'geonet' BoF. =A0Please correct= were necessary.

Following these correcitons I must upload them on the Proceedings of the IE= TF88 soon.

Thanks,

Alex
-------------------------------------------------------------= ----------

IETF Geonet BOF minutes

Nov 5 2013

1:00 to 2:00 PM pacific time

Note taker: Mike Kallas

Agenda shown
Note Well slide displayed to room.
Margaret could not make it
Agenda shown
Webex is up

Alex: Introductions.

Internet wide geo networking

Explained other related work by other groups

Disseminating IP packets to geographical areas. Or receiving IP
packets from a geographical area.

Problem statement draft presented by Georgios Karagiannis

Georgios: Challenges presented in the problem statement is not
addressed by IETF or any other bodies

Lost protocol: Location to service mapping

Two solution presented have actual implementations

Suggestion: List all the related working groups
Answer: no working group working on the exact same problem

Question: both use cases similar to ETSI scope. I don t see a wider
coverage than the ad hoc implementation.=A0

Which use case?
Wh= at is AD hoc implementation?
=A0
Why not use ETSI Answer:
short range only. Source has to be close to the area. This is internet
wide solution: provide that ability to any source on the internet to
send information to geographic areas.

Question: Bob (Verizon) this is how things work right. What about when
things go wrong? What about malicious events. Like to see attack
review, failure nodes scenarios. =A0Answer: Security and privacy are
very important. We have to focus on it

Disa= gree, we focus on solutions for each use case or each problem statement. We= then focus such solution with scenarios if things go wrong of attacks only= in security consideration section. =A0=A0

Next on the Agenda: implementation Interest: presentation.

Last topic: IPv6 over 802.11p. Presentation

End of presentation part.

Who presented and= what did the presenter say. This is not minute writing,=A0=A0I did not att= end but did not benefit from this minute. Minutes are written for others wh= o did not attend so they understand what was said exactly.=A0

Interest, clarifications.

Question: problem not well defined. Is it: enumerate IP addresses that
are currently in a geographical area to send to.

Answer: its is one of the potential solutions.

Answer: need to better define the problem statement. Need to learn
geographic proximity of certain devices and leave it at a high level
(not just IP) other options are possible.

A= gree
=A0

Answer: looking at a relationship between IP addresses and locations
of Access Routers.

Agree,=A0This is our sol= utions aim.=A0
=A0

Question: requirements around trust model on the geographic database?
Are the set of networks all part of the same organization or people
who don't trust each other? Multiple network providers? Could
affect trust model

Answer: both are relevant. Security is very important. Trust with
respect to positioning is different from security as defined in
IETF. Precision is also a factor. Trust of position: precision should
be part of the discussion. Main concern not who owns IP but where it
is

Question: uniqueness vs non uniqueness and indirection in
addressing. For example who is moving and who is not. ILNP tries to do
indirection. Other issues are privacy: present information without
identifying person. You may not want symmetric behavior V2x different
mechanism from x2V.

Answer: thank you. Agree on non symmetry. Need to take ILNP into
account in addition to others. DNS, LOST

Question: Guarantees. Are you only sending to the area. Is it ok it
reaches outside the area? Are you expecting error messages if the
message does not reach?

Answer: Reliability of delivery important

Question: one of the use cases was querying? How do you identify what
nodes you want to query?

Answer: example fire detectors, temperature, wind

Question: translation between geo and IP very important. What about
translating from IP address to geo? May be nice to have the solution
for both.

Answer: yes

Question: IEEE 1609 does not make the documents available. We need to
make them available. Because its related.

Answer: this is an issue and we need help with the liason with IEEE.
Liaison: we will address it.

Question: skeptical about problem. Geographical routing vs optimal routing.=

Answer: an optimal IP routing is different from geographic
positioning. Optimal route may not be possible


Stop discussion: need to figure out what will happen next

How many people read the problem statement: only a few
How many saw the charter: a few

Why few, I = think because the group did not progress in leadership skills. We need lead= ership documents or someone who can lead the group to one vision. Then we a= re work together toward that vision. Hope that IESG did not discourage our = before=A0agreed vision.=A0


Is there work appropriate to the ietf: a few, some reluctance
Not appropriate for IETF: one person only

N= ot understood, please help, what is the document related?
=A0

Scope seems to still be too broad. Is it ready?

=
What is the scope please point to something?
=A0

Who is interested in working on this? Several people (20)
=
Add me so 21.=A0
=A0

There is a mailing list including discussing scope
http://i= etf.org/mailman/listinfo/its

Question: there is interest but are we ready to say go? We should not
drop it. Is the next step another BOF?

I re= commend the next step is to stick to one vision of use cases and possible s= olutions that have clear scope (the word scope was the reason why the group= did not make it to IESG mind as far as information announced).=A0
=A0

Interesting in a broad sense but the scope is too wide. Need to narrow
scope. Is there application level stuff needed. Who is capable of
handling the received data.

Yes, I want to = ask Alex to handle the scope issues, please.=A0
=A0

Ted: have heard there is interest, haven't heard there is a go, but
there honestly this is not a drop issue, next step is maybe another
bof.

Thanks.=A0=A0

Last word: thanks to BOF chairs. Couple of very interesting problems:
actions to move it forward:

I recommend a v= ision for solutions direction, so please one direction. Then each solution = to be scoped, then each scope documented in one document. Please note that = IESG should clarify do they want us to scope the problems=A0or scope the so= lutions,=A0I think they want all,=A0

IMHO, we should have few main=A0problems, and each prob= lem may have different issues to address. Each document has a solution.=A0<= /div>
=A0

Crisp problem statement, a little of solutioneering, iteration on
problems and solutions need to be gone through. More detailed problem
statement more specifity. Look for any existing work. And help limit
the scope of things needed to be done.

I do= n't see any decision made by the group, we need to make decisions to pr= ogress our action or scope every thing ;-)
--20cf3010e53544e71904f42403db-- From nobody Mon Mar 10 10:13: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 991EC1A0643 for ; Mon, 10 Mar 2014 10:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJAhHuqOOo6L for ; Mon, 10 Mar 2014 10:12:58 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 497A71A055D for ; Mon, 10 Mar 2014 10:12:58 -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 s2AHCprJ001377; Mon, 10 Mar 2014 18:12:51 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DAFA42067D0; Mon, 10 Mar 2014 18:14:02 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C5E4F2066C3; Mon, 10 Mar 2014 18:14:02 +0100 (CET) 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 s2AHClBD013084; Mon, 10 Mar 2014 18:12:51 +0100 Message-ID: <531DF28F.3080106@gmail.com> Date: Mon, 10 Mar 2014 18:12:47 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Michael Richardson References: <527AE393.3090502@gmail.com> <11979.1394309022@sandelman.ca> In-Reply-To: <11979.1394309022@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/SLUBni-kZle9hGZgpt0WQyWNm34 Cc: "its@ietf.org" Subject: Re: [geonet/its] [its] minutes of the 'geonet' BoF meeting - please correct where wrong 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, 10 Mar 2014 17:13:00 -0000 Le 08/03/2014 21:03, Michael Richardson a écrit : > > Alexandru Petrescu wrote: > > Please see below the minutes of the 'geonet' BoF. Please correct were > > necessary. > > ... > > > Question: IEEE 1609 does not make the documents available. We need to > > make them available. Because its related. > > > Answer: this is an issue and we need help with the liason with IEEE. > > Liaison: we will address it. > > did documents become available? Hi Michael, Thank you for the question. No, the P1609 documents have not become more available than before. In the past month the IETF liaison manager with the IEEE Standards Association has identified the right contacts and submitted and further clarified a request to make P1609 documents available, towards support in developping IPv6-over-802.11p technology in draft-petrescu-ipv6-over-80211p-01.txt. Several messages were exchanged in private, including technical discussion about technology of IP/p, and process at IETF and at IEEE. The last message I read is that an agreemend may be found between the two organization, although this may need involvement of IPR and legal specialists. A question was made whether a Memorandum of Understanding between IEEE and IETF exists such as to facilitate contact. That's where it stands right now. Is there any agreement, or MoU, between IEEE or IEEE/VTS and IETF? Alex From nobody Mon Mar 10 10:16:55 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 3974A1A055D for ; Mon, 10 Mar 2014 10:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSruTiWw9p_M for ; Mon, 10 Mar 2014 10:16:40 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id AFF101A0653 for ; Mon, 10 Mar 2014 10:16:39 -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 s2AHGXOB002646; Mon, 10 Mar 2014 18:16:33 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 24430206705; Mon, 10 Mar 2014 18:17:44 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 17A9420327E; Mon, 10 Mar 2014 18:17:44 +0100 (CET) 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 s2AHGWrV014420; Mon, 10 Mar 2014 18:16:32 +0100 Message-ID: <531DF370.2070903@gmail.com> Date: Mon, 10 Mar 2014 18:16:32 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Abdussalam Baryun References: <527AE393.3090502@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/epQhnYKC_yYTDT2c-5i1Cl5Bzfg Cc: "its@ietf.org" Subject: Re: [geonet/its] [its] minutes of the Vancouver 'geonet' BoF meeting 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, 10 Mar 2014 17:16:47 -0000 Hi Abdussalam, Thanks for the comments. The comments you provided are related to the Vancouver 'geonet' BoF. Should I still address them? If yes, just let me know. The London bar BoF meeting minutes have been drafted and circulated privately. I wait a little bit for last edits and I will post on the email list soon. Alex Le 09/03/2014 04:23, Abdussalam Baryun a écrit : > > Hi Alex > > Thanks for the update. The minutes is not showing names of who asked > what. Is It it one person asking and answering. It seems like the agenda > did not focus discussion on the ITS documents and its active docs. Why not? > > Comments below > > AB > > On Thursday, November 7, 2013, Alexandru Petrescu wrote: > > Hello ITSers, > > Thanks to the minute takers. > > Please see below the minutes of the 'geonet' BoF. Please correct > were necessary. > > Following these correcitons I must upload them on the Proceedings of > the IETF88 soon. > > Thanks, > > Alex > ------------------------------__------------------------------__----------- > > IETF Geonet BOF minutes > > Nov 5 2013 > > 1:00 to 2:00 PM pacific time > > Note taker: Mike Kallas > > Agenda shown > Note Well slide displayed to room. > Margaret could not make it > Agenda shown > Webex is up > > Alex: Introductions. > > Internet wide geo networking > > Explained other related work by other groups > > Disseminating IP packets to geographical areas. Or receiving IP > packets from a geographical area. > > Problem statement draft presented by Georgios Karagiannis > > Georgios: Challenges presented in the problem statement is not > addressed by IETF or any other bodies > > Lost protocol: Location to service mapping > > Two solution presented have actual implementations > > Suggestion: List all the related working groups > Answer: no working group working on the exact same problem > > Question: both use cases similar to ETSI scope. I don t see a wider > coverage than the ad hoc implementation. > > > Which use case? > What is AD hoc implementation? > > Why not use ETSI Answer: > short range only. Source has to be close to the area. This is internet > wide solution: provide that ability to any source on the internet to > send information to geographic areas. > > Question: Bob (Verizon) this is how things work right. What about when > things go wrong? What about malicious events. Like to see attack > review, failure nodes scenarios. Answer: Security and privacy are > very important. We have to focus on it > > > Disagree, we focus on solutions for each use case or each problem > statement. We then focus such solution with scenarios if things go wrong > of attacks only in security consideration section. > > > Next on the Agenda: implementation Interest: presentation. > > Last topic: IPv6 over 802.11p. Presentation > > End of presentation part. > > > Who presented and what did the presenter say. This is not minute > writing, I did not attend but did not benefit from this minute. Minutes > are written for others who did not attend so they understand what was > said exactly. > > > Interest, clarifications. > > Question: problem not well defined. Is it: enumerate IP addresses that > are currently in a geographical area to send to. > > Answer: its is one of the potential solutions. > > Answer: need to better define the problem statement. Need to learn > geographic proximity of certain devices and leave it at a high level > (not just IP) other options are possible. > > > Agree > > > Answer: looking at a relationship between IP addresses and locations > of Access Routers. > > > Agree, This is our solutions aim. > > > Question: requirements around trust model on the geographic database? > Are the set of networks all part of the same organization or people > who don't trust each other? Multiple network providers? Could > affect trust model > > Answer: both are relevant. Security is very important. Trust with > respect to positioning is different from security as defined in > IETF. Precision is also a factor. Trust of position: precision should > be part of the discussion. Main concern not who owns IP but where it > is > > Question: uniqueness vs non uniqueness and indirection in > addressing. For example who is moving and who is not. ILNP tries to do > indirection. Other issues are privacy: present information without > identifying person. You may not want symmetric behavior V2x different > mechanism from x2V. > > Answer: thank you. Agree on non symmetry. Need to take ILNP into > account in addition to others. DNS, LOST > > Question: Guarantees. Are you only sending to the area. Is it ok it > reaches outside the area? Are you expecting error messages if the > message does not reach? > > Answer: Reliability of delivery important > > Question: one of the use cases was querying? How do you identify what > nodes you want to query? > > Answer: example fire detectors, temperature, wind > > Question: translation between geo and IP very important. What about > translating from IP address to geo? May be nice to have the solution > for both. > > Answer: yes > > Question: IEEE 1609 does not make the documents available. We need to > make them available. Because its related. > > Answer: this is an issue and we need help with the liason with IEEE. > Liaison: we will address it. > > Question: skeptical about problem. Geographical routing vs optimal > routing. > > Answer: an optimal IP routing is different from geographic > positioning. Optimal route may not be possible > > > Stop discussion: need to figure out what will happen next > > How many people read the problem statement: only a few > How many saw the charter: a few > > > Why few, I think because the group did not progress in leadership > skills. We need leadership documents or someone who can lead the group > to one vision. Then we are work together toward that vision. Hope that > IESG did not discourage our before agreed vision. > > > Is there work appropriate to the ietf: a few, some reluctance > Not appropriate for IETF: one person only > > > Not understood, please help, what is the document related? > > > Scope seems to still be too broad. Is it ready? > > > What is the scope please point to something? > > > Who is interested in working on this? Several people (20) > > > Add me so 21. > > > There is a mailing list including discussing scope > http://ietf.org/mailman/__listinfo/its > > > Question: there is interest but are we ready to say go? We should not > drop it. Is the next step another BOF? > > > I recommend the next step is to stick to one vision of use cases and > possible solutions that have clear scope (the word scope was the reason > why the group did not make it to IESG mind as far as information > announced). > > > Interesting in a broad sense but the scope is too wide. Need to narrow > scope. Is there application level stuff needed. Who is capable of > handling the received data. > > > Yes, I want to ask Alex to handle the scope issues, please. > > > Ted: have heard there is interest, haven't heard there is a go, but > there honestly this is not a drop issue, next step is maybe another > bof. > > > Thanks. > > > Last word: thanks to BOF chairs. Couple of very interesting problems: > actions to move it forward: > > > I recommend a vision for solutions direction, so please one direction. > Then each solution to be scoped, then each scope documented in one > document. Please note that IESG should clarify do they want us to scope > the problems or scope the solutions, I think they want all, > > IMHO, we should have few main problems, and each problem may have > different issues to address. Each document has a solution. > > > Crisp problem statement, a little of solutioneering, iteration on > problems and solutions need to be gone through. More detailed problem > statement more specifity. Look for any existing work. And help limit > the scope of things needed to be done. > > > I don't see any decision made by the group, we need to make decisions to > progress our action or scope every thing ;-) From nobody Mon Mar 10 10:46:06 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 AC65E1A0652 for ; Mon, 10 Mar 2014 10:46:01 -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 OFUs1jN0TM7Y for ; Mon, 10 Mar 2014 10:45:57 -0700 (PDT) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D7A381A0642 for ; Mon, 10 Mar 2014 10:45:57 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id um1so7578456pbc.30 for ; Mon, 10 Mar 2014 10:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ovD/gA0QEdyIoUHYcYZpls71q12QWNRDw9S5xoZTLig=; b=VGJdZ0St0PS6fvnwgIm/PW7IUtXUtABxu4CSDeEQsQMsgVUYL054BdLcWj/q/lVXyP G4OoLPqc2QuvE4kO7hFkB/K6hBoUse7Sq88tg11RUUOyMxNg7m4obsfh9xq7iauRcpNd ksE2/JBD79Zz/1uPhNDJzuSbvwrN7BZHqPv8uhNJ/FhXnnpVOsYadIOPqLSdICJrv7k1 w6oAgoPQARy3fDay87H23gZd+uIGijaswxqa8EokXHZCKGhGCjrEyQTarkV5h1BFJHYy uxDzvqtki+UX3pCCj91nlmiDs1qSZrHi7m5hSKBFippvyYjpgiVY0/W5dIZE/GfygN7A S6Lg== X-Received: by 10.66.136.103 with SMTP id pz7mr42270555pab.140.1394473551367; Mon, 10 Mar 2014 10:45:51 -0700 (PDT) Received: from spandex.local (209-112-197-35-rb1.nwc.dsl.dynamic.acsalaska.net. [209.112.197.35]) by mx.google.com with ESMTPSA id vx10sm87510022pac.17.2014.03.10.10.45.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Mar 2014 10:45:50 -0700 (PDT) Message-ID: <531DFA4C.8060404@gmail.com> Date: Mon, 10 Mar 2014 09:45:48 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: its@ietf.org References: <527AE393.3090502@gmail.com> <531DF370.2070903@gmail.com> In-Reply-To: <531DF370.2070903@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/8UokNg2culhqnHmDJETHn-nJ8VA Subject: Re: [geonet/its] [its] minutes of the Vancouver 'geonet' BoF meeting 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, 10 Mar 2014 17:46:02 -0000 To be clear, this was not a BOF, and it should not be regarded as one. It was an informal get-together to try to get the proposed charter and problem statement better scoped. Not only were we not on the agenda, we were not given meeting space when we requested it. Might be better to post a few notes on points of agreement and on what needs to be done rather than to rathole on minutes for something that wasn't really even a meeting. Melinda From nobody Mon Mar 10 10:50:49 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 A38831A04B9 for ; Mon, 10 Mar 2014 10:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hceU6Uxdk9Dh for ; Mon, 10 Mar 2014 10:50:41 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3642D1A0535 for ; Mon, 10 Mar 2014 10:50:39 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id z6so7344288yhz.22 for ; Mon, 10 Mar 2014 10:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lmLEUgaOTgyBTdg+xaFowhV6AksrkNsx4hi/LAddWlo=; b=LYtuKgjoB7Mxub04+rA7C9oADfx5kbMxZ2/KG9Fz/fK/YqVpxafilE8VZWfihmUrk0 cMOJJm+rlIO474q2Uk0/5c/d8fQDuI9E+BEPEgkv48KsnWB9g49bJ615aTNoj/qfWlbB Oje6bf+C2yKFeHAz7JJADZAsrULdNDZ0COoLOEWF8mfz5Fv08NHb8MO06m9Ny6911soO 4xfqwnQwSZQHRj5KLoItl+3AORPEpCh4eULOuoBZL/gtTbYbBykcc5HuY47v5NoJ8cn3 ZvIuNHflt9AWC7QdL8gqSZDTKfAITChrHZybFALS119nxPK08NrbimaKAUgPsOhmUikq jwUg== MIME-Version: 1.0 X-Received: by 10.236.99.38 with SMTP id w26mr46971929yhf.18.1394473833708; Mon, 10 Mar 2014 10:50:33 -0700 (PDT) Received: by 10.170.202.7 with HTTP; Mon, 10 Mar 2014 10:50:33 -0700 (PDT) In-Reply-To: <531DF370.2070903@gmail.com> References: <527AE393.3090502@gmail.com> <531DF370.2070903@gmail.com> Date: Mon, 10 Mar 2014 18:50:33 +0100 Message-ID: From: Abdussalam Baryun To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=20cf3011e02781c15504f4443d64 Archived-At: http://mailarchive.ietf.org/arch/msg/its/pSAVZkfW42CDN6alxENi2Cng9FM Cc: "its@ietf.org" Subject: Re: [geonet/its] [its] minutes of the Vancouver 'geonet' BoF meeting 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, 10 Mar 2014 17:50:46 -0000 --20cf3011e02781c15504f4443d64 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex Ok, I thank you and know it is not easy to write minutes. However, the IETF 88 minutes was not clear and has no names, and difficult for me to understand. As long as it was posted I just commented that I did not understood but hope that the next 89 minutes is not the same like the Vancouver minutes (I really look forward to latest 89 meeting minutes, so for me it is no need to address 88 meeting, thanks). Regards AB On Monday, March 10, 2014, Alexandru Petrescu wrote: > Hi Abdussalam, > > Thanks for the comments. > > The comments you provided are related to the Vancouver 'geonet' BoF. > Should I still address them? If yes, just let me know. > > The London bar BoF meeting minutes have been drafted and circulated > privately. I wait a little bit for last edits and I will post on the ema= il > list soon. > > Alex > > Le 09/03/2014 04:23, Abdussalam Baryun a =E9crit : > >> >> Hi Alex >> >> Thanks for the update. The minutes is not showing names of who asked >> what. Is It it one person asking and answering. It seems like the agenda >> did not focus discussion on the ITS documents and its active docs. Why >> not? >> >> Comments below >> >> AB >> >> On Thursday, November 7, 2013, Alexandru Petrescu wrote: >> >> Hello ITSers, >> >> Thanks to the minute takers. >> >> Please see below the minutes of the 'geonet' BoF. Please correct >> were necessary. >> >> Following these correcitons I must upload them on the Proceedings of >> the IETF88 soon. >> >> Thanks, >> >> Alex >> ------------------------------__---------------------------- >> --__----------- >> >> IETF Geonet BOF minutes >> >> Nov 5 2013 >> >> 1:00 to 2:00 PM pacific time >> >> Note taker: Mike Kallas >> >> Agenda shown >> Note Well slide displayed to room. >> Margaret could not make it >> Agenda shown >> Webex is up >> >> Alex: Introductions. >> >> Internet wide geo networking >> >> Explained other related work by other groups >> >> Disseminating IP packets to geographical areas. Or receiving IP >> packets from a geographical area. >> >> Problem statement draft presented by Georgios Karagiannis >> >> Georgios: Challenges presented in the problem statement is not >> addressed by IETF or any other bodies >> >> Lost protocol: Location to service mapping >> >> Two solution presented have actual implementations >> >> Suggestion: List all the related working groups >> Answer: no working group working on the exact same problem >> >> Question: both use cases similar to ETSI scope. I don t see a wider >> coverage than the ad hoc implementation. >> >> >> Which use case? >> What is AD hoc implementation? >> >> Why not use ETSI Answer: >> short range only. Source has to be close to the area. This is intern= et >> wide solution: provide that ability to any source on the internet to >> send information to geographic areas. >> >> Question: Bob (Verizon) this is how things work right. What about wh= en >> things go wrong? What about malicious events. Like to see attack >> review, failure nodes scenarios. Answer: Security and privacy are >> very important. We have to focus on it >> >> >> Disagree, we focus on solutions for each use case or each problem >> statement. We then focus such solution with scenarios if things go wrong >> of attacks only in security consideration section. >> >> >> Next on the Agenda: implementation Interest: presentation. >> >> Last topic: IPv6 over 802.11p. Presentation >> >> End of presentation part. >> >> >> Who presented and what did the presenter say. This is not minute >> writing, I did not attend but did not benefit from this minute. Minutes >> are written for others who did not attend so they understand what was >> said exactly. >> >> >> Interest, clarifications. >> >> Question: problem not well defined. Is it: enumerate IP addresses th= at >> are currently in a geographical area to send to. >> >> Answer: its is one of the potential solutions. >> >> Answer: need to better define the problem statement. Need to learn >> geographic proximity of certain devices and leave it at a high level >> (not just IP) other options are possible. >> >> >> Agree >> >> >> Answer: looking at a relationship between IP addresses and locations >> of Access Routers. >> >> >> Agree, This is our solutions aim. >> >> >> Question: requirements around trust model on the geographic database= ? >> Are the set of networks all part of the same organization or people >> who don't trust each other? Multiple network providers? Could >> affect trust model >> >> Answer: both are relevant. Security is very important. Trust with >> respect to positioning is different from security as defined in >> IETF. Precision is also a factor. Trust of position: precision shoul= d >> be part of the discussion. Main concern not who owns IP but where it >> is >> >> Question: uniqueness vs non uniqueness and indirection in >> addressing. For example who is moving and who is not. ILNP tries to = do >> indirection. Other issues are privacy: present information without >> identifying person. You may not want symmetric behavior V2x differen= t >> mechanism from x2V. >> >> Answer: thank you. Agree on non symmetry. Need to take ILNP into >> account in addition to others. DNS, LOST >> >> Question: Guarantees. Are you only sending to the area. Is it ok it >> reaches outside the area? Are you expecting error messages if the >> message does not reach? >> >> Answer: Reliability of delivery important >> >> Question: one of the use cases was querying? How do you identify wha= t >> nodes you want to query? >> >> Answer: example fire detectors, temperature, wind >> >> Question: translation between geo and IP very important. What about >> translating from IP address to geo? May be nice to have the solution >> for both. >> >> Answer: yes >> >> Question: IEEE 1609 does not make the documents available. We need t= o >> make them available. Because its related. >> >> Answer: this is an issue and we need help with the liason with IEEE. >> Liaison: we will address it. >> >> Question: skeptical about problem. Geographical routing vs optimal >> routing. >> >> Answer: an optimal IP routing is different from geographic >> positioning. Optimal route may not be possible >> >> >> Stop discussion: need to figure out what will happen next >> >> How many people read the problem statement: only a few >> How many saw the charter: a few >> >> >> Why few, I think because the group did not progress in leadership >> skills. We need leadership documents or someone who can lead the group >> to one vision. Then we are work together toward that vision. Hope that >> IESG did not discourage our before agreed vision. >> >> >> Is there work appropriate to the ietf: a few, some reluctance >> Not appropriate for IETF: one person only >> >> >> Not understood, please help, what is the document related? >> >> >> Scope seems to still be too broad. Is it ready? >> >> >> What is the scope please point to something? >> >> >> Who is interested in working on this? Several people (20) >> >> >> Add me so 21. >> >> >> There is a mailing list including discussing scope >> http://ietf.org/mailman/__listinfo/its >> >> >> Question: there is interest but are we ready to say go? We should no= t >> drop it. Is the next step another BOF? >> >> >> I recommend the next step is to stick to one vision of use cases and >> possible solutions that have clear scope (the word scope was the reason >> why the group did not make it to IESG mind as far as information >> announced). >> >> >> Interesting in a broad sense but the scope is too wide. Need to narr= ow >> scope. Is there application level stuff needed. Who is capable of >> handling the received data. >> >> >> Yes, I want to ask Alex to handle the scope issues, please. >> >> >> Ted: have heard there is interest, haven't heard there is a go, but >> there honestly this is not a drop issue, next step is maybe another >> bof. >> >> >> Thanks. >> >> >> Last word: thanks to BOF chairs. Couple of very interesting problems= : >> actions to move it forward: >> >> >> I recommend a vision for solutions direction, so please one direction. >> Then each solution to be scoped, then each scope documented in one >> document. Please note that IESG should clarify do they want us to scope >> the problems or scope the solutions, I think they want all, >> >> IMHO, we should have few main problems, and each problem may have >> different issues to address. Each document has a solution. >> >> >> Crisp problem statement, a little of solutioneering, iteration on >> problems and solutions need to be gone through. More detailed proble= m >> statement more specifity. Look for any existing work. And help limit >> the scope of things needed to be done. >> >> >> I don't see any decision made by the group, we need to make decisions to >> progress our action or scope every thing ;-) >> > > > --20cf3011e02781c15504f4443d64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex

Ok, I thank you and know it is not easy to write= minutes. However,=A0the IETF 88=A0minutes was not clear and has no names, = and difficult for me=A0to understand. As long as it was posted I just comme= nted that I did not understood=A0but hope that the next 89=A0minutes is not= the same like the Vancouver minutes (I really look forward to latest 89 me= eting minutes,=A0so for me it is=A0no need to address 88 meeting, thanks).= =A0

Regards
AB

On Monday, March 10, 2014, = Alexandru Petrescu wrote:
Hi Abdussalam,=

Thanks for the comments.

The comments you provided are related to the Vancouver 'geonet' BoF= . Should I still address them? =A0If yes, just let me know.

The London bar BoF meeting minutes have been drafted and circulated private= ly. =A0I wait a little bit for last edits and I will post on the email list= soon.

Alex

Le 09/03/2014 04:23, Abdussalam Baryun a =E9crit :

Hi Alex

Thanks for the update. The minutes is not showing names of who asked
what. Is It it one person asking and answering. It seems like the agenda did not focus discussion on the ITS documents and its active docs. Why not?=

Comments below

AB

On Thursday, November 7, 2013, Alexandru Petrescu wrote:

=A0 =A0 Hello ITSers,

=A0 =A0 Thanks to the minute takers.

=A0 =A0 Please see below the minutes of the 'geonet' BoF. =A0Please= correct
=A0 =A0 were necessary.

=A0 =A0 Following these correcitons I must upload them on the Proceedings o= f
=A0 =A0 the IETF88 soon.

=A0 =A0 Thanks,

=A0 =A0 Alex
=A0 =A0 ------------------------------__----------------------------= --__-----------

=A0 =A0 IETF Geonet BOF minutes

=A0 =A0 Nov 5 2013

=A0 =A0 1:00 to 2:00 PM pacific time

=A0 =A0 Note taker: Mike Kallas

=A0 =A0 Agenda shown
=A0 =A0 Note Well slide displayed to room.
=A0 =A0 Margaret could not make it
=A0 =A0 Agenda shown
=A0 =A0 Webex is up

=A0 =A0 Alex: Introductions.

=A0 =A0 Internet wide geo networking

=A0 =A0 Explained other related work by other groups

=A0 =A0 Disseminating IP packets to geographical areas. Or receiving IP
=A0 =A0 packets from a geographical area.

=A0 =A0 Problem statement draft presented by Georgios Karagiannis

=A0 =A0 Georgios: Challenges presented in the problem statement is not
=A0 =A0 addressed by IETF or any other bodies

=A0 =A0 Lost protocol: Location to service mapping

=A0 =A0 Two solution presented have actual implementations

=A0 =A0 Suggestion: List all the related working groups
=A0 =A0 Answer: no working group working on the exact same problem

=A0 =A0 Question: both use cases similar to ETSI scope. I don t see a wider=
=A0 =A0 coverage than the ad hoc implementation.


Which use case?
What is AD hoc implementation?

=A0 =A0 Why not use ETSI Answer:
=A0 =A0 short range only. Source has to be close to the area. This is inter= net
=A0 =A0 wide solution: provide that ability to any source on the internet t= o
=A0 =A0 send information to geographic areas.

=A0 =A0 Question: Bob (Verizon) this is how things work right. What about w= hen
=A0 =A0 things go wrong? What about malicious events. Like to see attack =A0 =A0 review, failure nodes scenarios. =A0Answer: Security and privacy ar= e
=A0 =A0 very important. We have to focus on it


Disagree, we focus on solutions for each use case or each problem
statement. We then focus such solution with scenarios if things go wrong of attacks only in security consideration section.


=A0 =A0 Next on the Agenda: implementation Interest: presentation.

=A0 =A0 Last topic: IPv6 over 802.11p. Presentation

=A0 =A0 End of presentation part.


Who presented and what did the presenter say. This is not minute
writing, =A0I did not attend but did not benefit from this minute. Minutes<= br> are written for others who did not attend so they understand what was
said exactly.


=A0 =A0 Interest, clarifications.

=A0 =A0 Question: problem not well defined. Is it: enumerate IP addresses t= hat
=A0 =A0 are currently in a geographical area to send to.

=A0 =A0 Answer: its is one of the potential solutions.

=A0 =A0 Answer: need to better define the problem statement. Need to learn<= br> =A0 =A0 geographic proximity of certain devices and leave it at a high leve= l
=A0 =A0 (not just IP) other options are possible.


Agree


=A0 =A0 Answer: looking at a relationship between IP addresses and location= s
=A0 =A0 of Access Routers.


Agree, This is our solutions aim.


=A0 =A0 Question: requirements around trust model on the geographic databas= e?
=A0 =A0 Are the set of networks all part of the same organization or people=
=A0 =A0 who don't trust each other? Multiple network providers? Could =A0 =A0 affect trust model

=A0 =A0 Answer: both are relevant. Security is very important. Trust with =A0 =A0 respect to positioning is different from security as defined in
=A0 =A0 IETF. Precision is also a factor. Trust of position: precision shou= ld
=A0 =A0 be part of the discussion. Main concern not who owns IP but where i= t
=A0 =A0 is

=A0 =A0 Question: uniqueness vs non uniqueness and indirection in
=A0 =A0 addressing. For example who is moving and who is not. ILNP tries to= do
=A0 =A0 indirection. Other issues are privacy: present information without<= br> =A0 =A0 identifying person. You may not want symmetric behavior V2x differe= nt
=A0 =A0 mechanism from x2V.

=A0 =A0 Answer: thank you. Agree on non symmetry. Need to take ILNP into =A0 =A0 account in addition to others. DNS, LOST

=A0 =A0 Question: Guarantees. Are you only sending to the area. Is it ok it=
=A0 =A0 reaches outside the area? Are you expecting error messages if the =A0 =A0 message does not reach?

=A0 =A0 Answer: Reliability of delivery important

=A0 =A0 Question: one of the use cases was querying? How do you identify wh= at
=A0 =A0 nodes you want to query?

=A0 =A0 Answer: example fire detectors, temperature, wind

=A0 =A0 Question: translation between geo and IP very important. What about=
=A0 =A0 translating from IP address to geo? May be nice to have the solutio= n
=A0 =A0 for both.

=A0 =A0 Answer: yes

=A0 =A0 Question: IEEE 1609 does not make the documents available. We need = to
=A0 =A0 make them available. Because its related.

=A0 =A0 Answer: this is an issue and we need help with the liason with IEEE= .
=A0 =A0 Liaison: we will address it.

=A0 =A0 Question: skeptical about problem. Geographical routing vs optimal<= br> =A0 =A0 routing.

=A0 =A0 Answer: an optimal IP routing is different from geographic
=A0 =A0 positioning. Optimal route may not be possible


=A0 =A0 Stop discussion: need to figure out what will happen next

=A0 =A0 How many people read the problem statement: only a few
=A0 =A0 How many saw the charter: a few


Why few, I think because the group did not progress in leadership
skills. We need leadership documents or someone who can lead the group
to one vision. Then we are work together toward that vision. Hope that
IESG did not discourage our before agreed vision.


=A0 =A0 Is there work appropriate to the ietf: a few, some reluctance
=A0 =A0 Not appropriate for IETF: one person only


Not understood, please help, what is the document related?


=A0 =A0 Scope seems to still be too broad. Is it ready?


What is the scope please point to something?


=A0 =A0 Who is interested in working on this? Several people (20)


Add me so 21.


=A0 =A0 There is a mailing list including discussing scope
=A0 =A0 http://ietf.org/mailman/__listinfo/its
=A0 =A0 <http://ietf.org/mailman/listinfo/its>

=A0 =A0 Question: there is interest but are we ready to say go? We should n= ot
=A0 =A0 drop it. Is the next step another BOF?


I recommend the next step is to stick to one vision of use cases and
possible solutions that have clear scope (the word scope was the reason
why the group did not make it to IESG mind as far as information
announced).


=A0 =A0 Interesting in a broad sense but the scope is too wide. Need to nar= row
=A0 =A0 scope. Is there application level stuff needed. Who is capable of =A0 =A0 handling the received data.


Yes, I want to ask Alex to handle the scope issues, please.


=A0 =A0 Ted: have heard there is interest, haven't heard there is a go,= but
=A0 =A0 there honestly this is not a drop issue, next step is maybe another=
=A0 =A0 bof.


Thanks.


=A0 =A0 Last word: thanks to BOF chairs. Couple of very interesting problem= s:
=A0 =A0 actions to move it forward:


I recommend a vision for solutions direction, so please one direction.
Then each solution to be scoped, then each scope documented in one
document. Please note that IESG should clarify do they want us to scope
the problems or scope the solutions, I think they want all,

IMHO, we should have few main problems, and each problem may have
different issues to address. Each document has a solution.


=A0 =A0 Crisp problem statement, a little of solutioneering, iteration on =A0 =A0 problems and solutions need to be gone through. More detailed probl= em
=A0 =A0 statement more specifity. Look for any existing work. And help limi= t
=A0 =A0 the scope of things needed to be done.


I don't see any decision made by the group, we need to make decisions t= o
progress our action or scope every thing ;-)


--20cf3011e02781c15504f4443d64-- From nobody Mon Mar 10 10:57:00 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 56F371A04AB for ; Mon, 10 Mar 2014 10:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCEc78KeXxzd for ; Mon, 10 Mar 2014 10:56:55 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2927B1A0262 for ; Mon, 10 Mar 2014 10:56:55 -0700 (PDT) Received: by mail-yh0-f47.google.com with SMTP id 29so1783767yhl.34 for ; Mon, 10 Mar 2014 10:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yiEouQP5SiQcEcuNZcfHr/EDJ8mXlD+xDcmbJZ5/3+o=; b=iDYOwjKSdJkentDINrf+js8HhFQ+ClF8CcbM2+pvI8PNfyju753RzpakNwmX5HdXJp S8C0Hlzow+JFfohXIvuhv8K4P5tioQYXVcb8H2bvIVY7zHJ89S5JOQYcamGr35QUsHNr yBng7Szf+4fjiQS89EjHNiMcqqr/dd5cH4BRVeR3PO3qsv3PQKktqHKeFiL28r4uc4vX Fj3We5bsKfWkSbjxkbC3Z/xL7lpq+o/pOniNcQEGMbWa4yUJh13ifAiZKYTx9c8pFjIw OKZGjcfEHNhz0i8CGDhwSgrWAZS0GGyDs9jIm84gxSKPK9EBHY3WZw2O86dnODT6JibF OhIg== MIME-Version: 1.0 X-Received: by 10.236.93.208 with SMTP id l56mr4879367yhf.112.1394474209561; Mon, 10 Mar 2014 10:56:49 -0700 (PDT) Received: by 10.170.202.7 with HTTP; Mon, 10 Mar 2014 10:56:49 -0700 (PDT) In-Reply-To: <531DFA4C.8060404@gmail.com> References: <527AE393.3090502@gmail.com> <531DF370.2070903@gmail.com> <531DFA4C.8060404@gmail.com> Date: Mon, 10 Mar 2014 18:56:49 +0100 Message-ID: From: Abdussalam Baryun To: Melinda Shore Content-Type: multipart/alternative; boundary=20cf3010ead1e8cfab04f4445332 Archived-At: http://mailarchive.ietf.org/arch/msg/its/5AUe4ZZttPdaLU0l3rZjg14h7Nc Cc: "its@ietf.org" Subject: Re: [geonet/its] [its] minutes of the Vancouver 'geonet' BoF meeting 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, 10 Mar 2014 17:56:57 -0000 --20cf3010ead1e8cfab04f4445332 Content-Type: text/plain; charset=ISO-8859-1 Hi Melinda, If the gathering made some results, conclusions or agreements, please tell us. I agree that it is not important to have minutes ready, but it is important that we get together and make decisions/agreements, then announce them. I hope there was a good result because I am interested in this group, I look forward to reading discussion results not only discussion points. Best regards AB On Monday, March 10, 2014, Melinda Shore wrote: > To be clear, this was not a BOF, and it should not be regarded > as one. It was an informal get-together to try to get the > proposed charter and problem statement better scoped. Not only > were we not on the agenda, we were not given meeting space > when we requested it. > > Might be better to post a few notes on points of agreement > and on what needs to be done rather than to rathole on > minutes for something that wasn't really even a meeting. > > Melinda > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --20cf3010ead1e8cfab04f4445332 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Melinda,

If the gathering made some results,=A0conclu= sions or agreements, please tell us. I agree that it is not important to ha= ve minutes ready,=A0but it is important that we get together and make decis= ions/agreements, then announce them.=A0

I hope there was a good result because I am interested = in this group,=A0I look forward to reading=A0discussion=A0results not only= =A0discussion=A0points.=A0

Best regards
AB

<= /div>

On Monday, March 10, 2014, Melinda Shore wrote:
To be clear, this was not a BOF, and it should not be regarde= d
as one. =A0It was an informal get-together to try to get the
proposed charter and problem statement better scoped. =A0Not only
were we not on the agenda, we were not given meeting space
when we requested it.

Might be better to post a few notes on points of agreement
and on what needs to be done rather than to rathole on
minutes for something that wasn't really even a meeting.

Melinda

_______________________________________________
its mailing list
its@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/its
--20cf3010ead1e8cfab04f4445332-- From nobody Mon Mar 10 11:46:11 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 9B30D1A03FC for ; Mon, 10 Mar 2014 11:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 Rxdl4PUfgcBf for ; Mon, 10 Mar 2014 11:46:07 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1131A04B0 for ; Mon, 10 Mar 2014 11:46:07 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1686E1B80E5 for ; Mon, 10 Mar 2014 11:46:02 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 0E602190043; Mon, 10 Mar 2014 11:46:02 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Mar 2014 11:46:02 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Mon, 10 Mar 2014 14:46:00 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <3A043926-80A6-4259-8FCF-86D50B60B81F@nominum.com> References: <527AE393.3090502@gmail.com> <531DF370.2070903@gmail.com> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/its/eXJzjQ-Xp4cyp9Qhf-UgJFrlCEI Cc: Alexandru Petrescu , "its@ietf.org" Subject: Re: [geonet/its] [its] minutes of the Vancouver 'geonet' BoF meeting 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, 10 Mar 2014 18:46:08 -0000 On Mar 10, 2014, at 1:50 PM, Abdussalam Baryun = wrote: > Ok, I thank you and know it is not easy to write minutes. However, the = IETF 88 minutes was not clear and has no names, and difficult for me to = understand. As long as it was posted I just commented that I did not = understood but hope that the next 89 minutes is not the same like the = Vancouver minutes (I really look forward to latest 89 meeting minutes, = so for me it is no need to address 88 meeting, thanks).=20 To be clear, until a working group is chartered, this is just a = discussion among IETF participants, and no minutes are required. Once = a working group is chartered, meeting minutes are _required_, and = meetings have to be announced at least two weeks in advance on the = mailing list. So if someone took minutes, it would be great if they could post what = they have, but please don't get so formal about it that it becomes an = obstacle to forward progress. From nobody Mon Mar 10 12:13:55 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 960391A04F1 for ; Mon, 10 Mar 2014 12:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANNXlTHylzpz for ; Mon, 10 Mar 2014 12:13:49 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) by ietfa.amsl.com (Postfix) with ESMTP id 411B41A0675 for ; Mon, 10 Mar 2014 12:13:49 -0700 (PDT) Received: by mail-yk0-f178.google.com with SMTP id 79so20233814ykr.9 for ; Mon, 10 Mar 2014 12:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qR0b0Lv1cRMigdVKRtuys0N2WxZ2IbAkLib/KG6nbYw=; b=WzTF+a6rQv1hZ03SYl20kFqold6AC/Z1xuNHfgb/mP6YoQ6F43bwYAPy9Po/a6PTBt sOFMv/kOZMe269++Q/lAkyn/beTFjH++8VcErZP6F3XtftFLHbEYg20x5zBpV+ohXZe5 DevTZhxmHbpVHhBVUKdDKlWoTg4FNgTDjxWD0zo52UmfmXkJaXAU+cyhcSJENopc5Vb8 UtAJX51PJ62R01nVOOlbJZtzcXu71bH9atQB70/nP+L+RL21Q5haOS9OlK/OBv0eItem yYLBdHkL9QAGNbCucsZ2pyyR8ellOrbz/kM9FMLRhoH5EuqqT1TE5QD6zUu85Hk7fzK9 vNmw== MIME-Version: 1.0 X-Received: by 10.236.153.233 with SMTP id f69mr5935190yhk.107.1394478823663; Mon, 10 Mar 2014 12:13:43 -0700 (PDT) Received: by 10.170.202.7 with HTTP; Mon, 10 Mar 2014 12:13:43 -0700 (PDT) In-Reply-To: <3A043926-80A6-4259-8FCF-86D50B60B81F@nominum.com> References: <527AE393.3090502@gmail.com> <531DF370.2070903@gmail.com> <3A043926-80A6-4259-8FCF-86D50B60B81F@nominum.com> Date: Mon, 10 Mar 2014 20:13:43 +0100 Message-ID: From: Abdussalam Baryun To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf302d488eee6f3704f445660b Archived-At: http://mailarchive.ietf.org/arch/msg/its/KaDc62_YM62FDvz6rVXPWEJTADE Cc: Alexandru Petrescu , "its@ietf.org" Subject: Re: [geonet/its] [its] minutes of the Vancouver 'geonet' BoF meeting 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, 10 Mar 2014 19:13:51 -0000 --20cf302d488eee6f3704f445660b Content-Type: text/plain; charset=ISO-8859-1 Hi Ted, I agree, and I just replied to posts with my comments. but I think if we want progress, at least We need to know just results of meetings or gathering, or what the group chair advise what is missing, Is this ok, please advise, AB On Monday, March 10, 2014, Ted Lemon wrote: > On Mar 10, 2014, at 1:50 PM, Abdussalam Baryun > > wrote: > > Ok, I thank you and know it is not easy to write minutes. However, the > IETF 88 minutes was not clear and has no names, and difficult for me to > understand. As long as it was posted I just commented that I did not > understood but hope that the next 89 minutes is not the same like the > Vancouver minutes (I really look forward to latest 89 meeting minutes, so > for me it is no need to address 88 meeting, thanks). > > To be clear, until a working group is chartered, this is just a discussion > among IETF participants, and no minutes are required. Once a working > group is chartered, meeting minutes are _required_, and meetings have to be > announced at least two weeks in advance on the mailing list. > > So if someone took minutes, it would be great if they could post what they > have, but please don't get so formal about it that it becomes an obstacle > to forward progress. > > --20cf302d488eee6f3704f445660b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ted,

I agree, and I just replied to posts with my com= ments.=A0but I think if we want progress, at least We need=A0to know just= =A0results of meetings or gathering, or what the group chair advise what is= missing,=A0Is this ok, please advise,

AB

On Monday, March 10, 2014, Ted Lemon wrote:<= br>
On Mar 10, 2014, at 1:50 PM, Abdussalam B= aryun <abdussalambaryun@gmail.com> wrot= e:
> Ok, I thank you and know it is not easy to write minutes. However, the= IETF 88 minutes was not clear and has no names, and difficult for me to un= derstand. As long as it was posted I just commented that I did not understo= od but hope that the next 89 minutes is not the same like the Vancouver min= utes (I really look forward to latest 89 meeting minutes, so for me it is n= o need to address 88 meeting, thanks).

To be clear, until a working group is chartered, this is just a discussion = among IETF participants, and no minutes are required. =A0 Once a working gr= oup is chartered, meeting minutes are _required_, and meetings have to be a= nnounced at least two weeks in advance on the mailing list.

So if someone took minutes, it would be great if they could post what they = have, but please don't get so formal about it that it becomes an obstac= le to forward progress.

--20cf302d488eee6f3704f445660b-- From nobody Tue Mar 11 07:19:20 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 AE3991A072C for ; Tue, 11 Mar 2014 07:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.683 X-Spam-Level: X-Spam-Status: No, score=-2.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MANGLED_LOAN=2.3, 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 fCrR9z4CKeQy for ; Tue, 11 Mar 2014 07:19:16 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 45F241A0718 for ; Tue, 11 Mar 2014 07:19:16 -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 s2BEJ9a4023703 for ; Tue, 11 Mar 2014 15:19:09 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6D511206BB9 for ; Tue, 11 Mar 2014 15:20:22 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 64A00204537 for ; Tue, 11 Mar 2014 15:20:22 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s2BEJ6nX017423 for ; Tue, 11 Mar 2014 15:19:09 +0100 Message-ID: <531F1B5A.70107@gmail.com> Date: Tue, 11 Mar 2014 15:19:06 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.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/vI4DcyT9UnvULuxwf2TtoSx_6kA Subject: [geonet/its] minutes of the 'geonet' meeting in London IETF89 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, 11 Mar 2014 14:19:18 -0000 Hello, Please see below some minutes of the 'geonet' meeting in London. Alex ------------------------------------------------------------------- 'geonet' informal meeting Minutes and Action Points IETF89 in London Monday, 20h, in Victoria. ------------------------------------------------------------------- Participants: Melinda Shore, Eliot Lear, Dino Farinacci, Brian Rosen, Ray Bellis, Georgios Karagiannis, Dimitri Papadimitriou, Bastiaan Wissingh, Yong-Geun Hong, Robert Moskowitz, Alexandru Petrescu. Sidenote: shortly after the meeting Melinda Shore announced stepping back right after London. We need a co-Chair. The meeting went well, attended by about 12 people, including the Chair of the geopriv WG. We discussed how the Charter could be described in a clearer way, and how it could be better scoped. - In the first phase the Charter should be about single-hop scope. - which level in the stack targeted at the "edges" between locator spaces remains open. May be a way to get out of this rathole is to start with a functional spec. instead of a protocol spec. Along this line refining the technical artefact that will be produced by this group would certainly help. - add "we are not trying to reinvent layer 3 routing system". - add "the use of these protocols will involve a "intermediary" box." - add "This is not an automotive-only solution", although some of the work is applicable in vehicular communications, telematics. Drafts on use-cases have to be written and volunteers for writing them are about to be identified (Dino said he'd be interested). Text is needed about re-using where applicable results of the geopriv WG (PIDF-LO, an XML-based format). Its potential re-use remains to be documented in particular whether these formats could fit procedures - actually by moving deeper into them we would also have the mean to determine how applicable these formats are. Use cases: determine what characterizes a good use case in the present context before moving to their development. The use-cases not to be pursued: identifying regions of a city issuing particular traffic, and geolocation of instrumented ambulance. The vehicular use cases are important, but only as an application of a technology that is developped in a generic way. Eliot said there is a lot of support, and if we have users that support then we may be ok for the next steps and publish drafts before the next IETF meeting (problem statement and use-case drafts). Following this discussion I propose this plan of drafts. Individual personal drafts: - PS draft, fully describing the problem, and briefly describing the use-cases. (Georgios, all, including Geert Heijenk and Andreas Festag). - Use-case1 draft object localization (Dimitri) - Use-case5 draft reusing geopriv (Brian) - Use-case2 draft goods tracking (Dino) - Use-case3 draft geo dissemination (Georgios, Geert, Bastiaan) - Use-case4 draft vehicular (Alex, Georgios, Robert, Geert Heijenk, Andreas Festag). From nobody Tue Mar 11 09:05:03 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 0C7FE1A046B for ; Tue, 11 Mar 2014 09:05:00 -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 2fE0Dbau8Mva for ; Tue, 11 Mar 2014 09:04:58 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 597AF1A01AD for ; Tue, 11 Mar 2014 09:04:58 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id x10so8734073pdj.34 for ; Tue, 11 Mar 2014 09:04:52 -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=Bx3nsYkDiNKnsu/XLSOAAzrH2LEupjF5XDd+EWiqRPQ=; b=WOUAyMfwkHfO9Y4FrDtM3nKG4FQjQZgWhV7YQx/Ci1XUKQIh1mJs3EA4fBpCtyfvUE e/w2LErZG+OXL5z6Y/l8IVGMuup8t5lP8RKSKZC/MCkb6QOc/urLmzs41uJRQa7m8qX7 NCdeNYsH1lFDO+ONfpBqOJ5unVNqHbIbh0ATzTHMPAx3u8/JTbl6qoxbL7+6SDpBVEzY nWlj846k47eg1zixKREfFVkHJjN7GEoiTvkqq7g4rGrNsnQk2/H4d9fvKswx3wqDYhM8 Fv3kB545qeQha1q4P7jB0m3v4Yd0kLPJo4yp1PnjrcMhkKUpXQCw37GaO6jtJDmaAntF W41w== X-Received: by 10.66.12.67 with SMTP id w3mr49133272pab.29.1394553892674; Tue, 11 Mar 2014 09:04:52 -0700 (PDT) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id vf7sm75324724pbc.5.2014.03.11.09.04.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Mar 2014 09:04:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Dino Farinacci In-Reply-To: <531F1B5A.70107@gmail.com> Date: Tue, 11 Mar 2014 09:04:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <25E2FC42-6C9C-41F7-8433-E94B902EADBD@gmail.com> References: <531F1B5A.70107@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/its/J_ndB84_GoaEGrdGInkXfgmy_Yw Cc: "its@ietf.org" Subject: Re: [geonet/its] minutes of the 'geonet' meeting in London IETF89 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, 11 Mar 2014 16:05:00 -0000 > Drafts on use-cases have to be written and volunteers for writing them > are about to be identified (Dino said he'd be interested). Here is a description of the use-case I gave verbally at the ad-hoc get = together. It was labeled by Alex as "the Shell case". This was a = requirement from the oiler riggers in Texas. (1) The oil companies want to track employees in the field. The = conditions can be dangerous so they want to verify their safety. (2) They are each equipped with a mobile device. (3) The management knows their phone numbers but needs to send packets = to those phone numbers. We (cisco), suggested that that register E.164 = telephone numbers as EIDs in the LISP mapping database. When a lookup is = performed, what is returned is an RLOC-record which contains the IP = address of the mobile device. (4) Adding geonet specific mechnanisms to this use-case, say an oil = rigger explodes. They wan to send recovery instructions to all E.164 = addresses in the geo radius of the explosion. (5) So you store in the LISP mapping database the geo-coordinates of the = point of explosion with say a radius value of 1 mile. All EIDs that are = in the circle of geography are notified. That is each E.164 address (or = IP address) of the mobile device is registered with the circle EID. (6) Management detects explosion and sends packet to each IP address = that is in the mapping database record for the circule EID as the key to = the lookup. Dino From martin.florian@kit.edu Mon Mar 17 09:03:31 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 841C71A042F for ; Mon, 17 Mar 2014 09:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 VD8QF9gDMXqC for ; Mon, 17 Mar 2014 09:03:29 -0700 (PDT) Received: from mailout.scc.kit.edu (mailout.scc.kit.edu [129.13.185.202]) by ietfa.amsl.com (Postfix) with ESMTP id D66FA1A040E for ; Mon, 17 Mar 2014 09:03:28 -0700 (PDT) Received: from KIT-MSX-03.kit.edu (kit-msx-03.kit.edu [172.21.117.13]) by scc-mailout-02.scc.kit.edu with esmtps (Exim 4.72 #1) id 1WPa0U-0002H9-Uh; Mon, 17 Mar 2014 17:03:18 +0100 Received: from [141.3.71.87] (172.21.117.6) by smtp.kit.edu (172.21.117.13) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 17 Mar 2014 17:03:18 +0100 Message-ID: <53271CC5.80707@kit.edu> Date: Mon, 17 Mar 2014 17:03:17 +0100 From: Martin Florian User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "its@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/AJA6RacG3IVGeDuSsdscGTb9U4Q Subject: [geonet/its] Scenarios with multiple communication network providers 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, 17 Mar 2014 16:04:42 -0000 Hi, am I right to assume that discussions so far were centered only around use-cases where the communication network is controlled by one singular entity? Such scenarios don't map too well with the multi-AS structure of the Internet. Are the solutions developed by Geonet envisioned to run only within one organizational domain (AS)? I could imagine, for example, applications where vehicular safety warnings or advertisements need to be sent to all 3G/4G-enabled vehicles in a given area, independently of which network operator they are using. A straightforward solution is probably to broadcast such geographic messages to all operators covering the target area. However, a "geographic area -> network operator" mapping must be realized first as well as mechanisms for maintaining it. I couldn't attend the informal BoF meeting so please excuse me if this issue was already raised before. Kind Regards, Martin From nobody Mon Mar 17 09:24:21 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 AC9DC1A0426 for ; Mon, 17 Mar 2014 09:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4YSTUwXo7vF for ; Mon, 17 Mar 2014 09:24:17 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id B9A4C1A0436 for ; Mon, 17 Mar 2014 09:24:17 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2HGO7AZ007617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 17 Mar 2014 11:24:08 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2HGO3pS031275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Mar 2014 17:24:06 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.10]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 17 Mar 2014 17:23:37 +0100 From: "Papadimitriou, Dimitri (Dimitri)" To: Martin Florian , "its@ietf.org" Thread-Topic: [geonet/its] Scenarios with multiple communication network providers Thread-Index: AQHPQfqzZezX5BkaoU2uKjnZ4QSkPprldgHg Date: Mon, 17 Mar 2014 16:23:36 +0000 Message-ID: <84675BAA8C49154AB81E2587BE8BDF8308B5330B@FR711WXCHMBA07.zeu.alcatel-lucent.com> References: <53271CC5.80707@kit.edu> In-Reply-To: <53271CC5.80707@kit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/its/ggS0nOJ1OaOkeyp8hfKIQMIN2Ww Subject: Re: [geonet/its] Scenarios with multiple communication network providers 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, 17 Mar 2014 16:24:20 -0000 Hi, > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Martin Florian > Sent: Monday, March 17, 2014 17:03 > To: its@ietf.org > Subject: [geonet/its] Scenarios with multiple communication network > providers >=20 > Hi, >=20 > am I right to assume that discussions so far were centered only around > use-cases where the communication network is controlled by one singular > entity? Such scenarios don't map too well with the multi-AS structure of > the Internet. Are the solutions developed by Geonet envisioned to run > only within one organizational domain (AS)? The answer is negative.=20 The statement=20 "Mechanisms and IETF protocols are needed for authorized source nodes anywhere in the Internet to disseminate packets to other nodes in areas described by geographic parameters, while respecting the privacy concerns of sender and receiver." makes this clear I think since the Internet is by def. multi-AS. =20 Thanks, -dimitri. > I could imagine, for example, applications where vehicular safety > warnings or advertisements need to be sent to all 3G/4G-enabled vehicles > in a given area, independently of which network operator they are using. > A straightforward solution is probably to broadcast such geographic > messages to all operators covering the target area. However, a > "geographic area -> network operator" mapping must be realized first as > well as mechanisms for maintaining it. >=20 > I couldn't attend the informal BoF meeting so please excuse me if this > issue was already raised before. >=20 > Kind Regards, > Martin >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its