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

[<[e-mail]>]

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