[geonet/its] main conclusions of the Geonet meeting of Wednesday evening

[<[e-mail]>]

Hi all,

Before answering the question of Dimitri, seee below email,  I would like to mention the following. Bastiaan and I will send the minutes of the meeting asap, but the main conclusions of the meeting were the following:

====================
5 people were present! Dimitri is at IETF but he did not come! 
Dino, Bastiaan, Ray Bellis, Victor Moreno (CISCO) and Georgios Karagiannis
The main conclusions are the following.

There are two options on moving forward with the Geonet activity:


Option 1:: bring the proposal to IRTF in the form of a research group (RG) 
===============================================

Option 2: Try to create an IETF BOF/WG, by first modifying the following:
=============================================

1) The scope is too large:
Proposal remove the use case on package delivery (Dino agreed)
Narrow further the scope

2) show in detail how Geonet can be applied to one or more use cases, using message sequence diagrams, etc.

3) dissemination of packets within a geographical area should be layer 2 technology agnostic

4) show how geographical areas, including overlapping areas, can be possible mapped to IP addresses 
Ray Bellis mentioned that this is a very hard problem to solve and therefore it might be required to bring Geonet to IRTF and not IETF.

==================================

Please provide your opinion regarding which of the options we should choose in order to move forward!

Best regards,
Georgios
 


________________________________________
Van: Papadimitriou, Dimitri (Dimitri) [[e-mail]]
Verzonden: vrijdag 25 juli 2014 19:56
Aan: Karagiannis, G. (EWI); [e-mail]
CC: [e-mail]; [e-mail]; [e-mail]
Onderwerp: RE: Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk

Hi All,

I couldn't participate to the side-meeting on Wednesday evening but would like to share from the feedback received my suggestion in order to move forward based of my understanding of the current situation:

- We know a couple of technical challenges/key issues have to be further investigated (see point iii) here below)

- There are different alternatives we have to explore before moving to an IETF protocol chartered group

- Several initiatives have been already explored/specified in addressing contiguous problems and we have to figure out which one could fit our needs, which one require extension or enhancement, etc.

To this end, moving towards a proposed RG seems to be the more suited approach.

Any other opinion ? Thoughts ?

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