Re: [geonet/its] RG vs. WG (was: Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk)

[Alexandru Petrescu <[e-mail]>]

Le 25/07/2014 19:56, Papadimitriou, Dimitri (Dimitri) a écrit :
[...]
> To this end, moving towards a proposed RG seems to be the more suited
> approach.
>
> Any other opinion ? Thoughts ?

I would like to discuss further this aspect.

There are a number of big unknowns in geonetworking rendering it 
researchy.  How many geo-points relate to one IP address, and 
vice-versa?  IP forwarding is known through routers but not through 
geo-points: which translation could achieve that?  IP is universal, but 
geographical coordinates are part of various incompatible geography 
systems and projections. Etc.

On another hand, there are number of vehicular industry needs of sending 
app-layer IP packets to Routers situated in geographically-determined areas.

And, there are a number of standardized products sending non-IP messages 
containing geographical coordinates.  The main reason behind these being 
non-IP instead of IP is a fallacy.  That fallacy says that sending IP 
messages is not reliable, nor fast enough.

There are a number of advantages in sending IP messages, instead of 
non-IP messages, in a vehicular environment: interoperability, 
availability of open-source software, tapping in a much larger software 
developper base, cheap hardware.

I would like to discuss further along these lines.  What is more WG and 
what is more RG?  Thoughts?

Alex


>
> Cheers, -dimitri.
>
>
>
>> -----Original Message----- From: its [mailto:[e-mail]]
>> On Behalf Of [e-mail] Sent: Saturday, July 12, 2014
>> 7:17 AM To: [e-mail] Cc: [e-mail];
>> [e-mail]; [e-mail] Subject: [geonet/its]
>> Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF
>> registration desk
>>
>> Agenda GeoNet informal meeting ==========================
>>
>> Date and time: Wednesday 23 July at 20:30 Location: IETF
>> registration desk;
>>
>> I) Current version of charter, see attached document =============
>>
>>
>> II) Current status of documents ==============
>>
>> Currently the following drafts are produced:
>> http://www.ietf.org/id/draft-karagiannis-geonet-problem-statement-00.txt
>>
>>
http://www.ietf.org/id/draft-karagiannis-geonet-dissemination-geo-areas-
>> 00.txt
>> http://www.ietf.org/id/draft-wissingh-disseminate-to-rsu-00.txt
>>
>> The following two use cases Internet drafts are planned to be
>> written soon after the IETF 90 (Dino is the main author of these
>> two drafts; Dimitri will also participate; More volunteers?):
>>
>> => Precise tracking of package positions during a shipping
>> process: A good delivered by a shipping organization has a
>> provider-independent IP address. This good is tracked in that its
>> geographical position is known to end- users continuously
>> throughout the entire delivery process. The IP address of the good
>> is associated to the geographical coordinates of the router to
>> which it connects. Using IP addresses enables very finely grained
>> and precise tracking.
>>
>> => Tracking and communicating with people or objects located
>> within geographical areas, e.g., Oiler Rigger Oil companies want to
>> track employees in the field, where the conditions can be dangerous
>> so they want to verify their safety. Such a dangerous situation can
>> be the explosion (or the high risk of explosion) of an oiler
>> rigger. In this situation the Oil company needs to be able to
>> disseminate recovery instructions to all employees that are located
>> in the neighborhood of the explosion within a certain radius (e.g.,
>> 1 mile) from the explosion.
>>
>>
>> III) Possible blocking points on moving forward
>> ========================
>>
>> 1. The re-use of DNS is perceived as a blocking point; a possible
>> way out is to propose a system-specific resolution mechanism, with
>> a loose-coupling hook to DNS?
>>
>> 2. Forwarding/L3 packet processing based on GeoNet (rather than IP
>> addresses) is a blocking point; the best we could expect is a
>> overlay style mechanism à la multicast or Mobile IP, or LISP where
>> (one or more gateways) "gateway function" would be required?
>>
>> 3. Relationship to Geopriv WG may block because it suggests the
>> functions we propose in GeoNet are maybe more adequate at
>> application layer; maybe Geopriv may deliver an
>> encoding-independent document which would enable consistence in the
>> representation of geolocators and areas?
>>
>>
>> IV) What are the next steps on forming the GeoNET WG?
>> ==============================
>>
>>
>> Best regards, Georgios
>
>