Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk

["Papadimitriou, Dimitri (Dimitri)" <[e-mail]>]

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