[geonet/its] uploaded geonet BoF minutes Vancouver IETF88

Alexandru Petrescu <alexandru.petrescu@gmail.com> Mon, 25 November 2013 09:38 UTC

Return-Path: <alexandru.petrescu@gmail.com>
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 C87411ACCE3 for <its@ietfa.amsl.com>; Mon, 25 Nov 2013 01:38:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.583
X-Spam-Level:
X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 NGor1ABwLaqG for <its@ietfa.amsl.com>; Mon, 25 Nov 2013 01:38:09 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id CF8A91ACCDF for <its@ietf.org>; Mon, 25 Nov 2013 01:38:08 -0800 (PST)
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 rAP9c8Wv031754 for <its@ietf.org>; Mon, 25 Nov 2013 10:38:08 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4A753205497 for <its@ietf.org>; Mon, 25 Nov 2013 10:38:39 +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 40996201536 for <its@ietf.org>; Mon, 25 Nov 2013 10:38:39 +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 rAP9c3p4009424 for <its@ietf.org>; Mon, 25 Nov 2013 10:38:08 +0100
Message-ID: <52931A7B.90604@gmail.com>
Date: Mon, 25 Nov 2013 10:38:03 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: "its@ietf.org" <its@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [geonet/its] uploaded geonet BoF minutes Vancouver IETF88
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GeoNet BoF discussion list." <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Nov 2013 09:38:12 -0000

Hi,

I have uploaded the minutes of the geonet BoF held in Vancouver.  The 
URL is:
http://www.ietf.org/proceedings/88/minutes/minutes-88-geonet

The text is also pasted below.

If you need any modification please suggest it by December 19th, 2013.

Yours,

Alex
----------------------------------------------------------------------

IETF 88 Vancouver, Canada
Minutes of the Geonet BoF
Nov. 5 2013
1:00 to 2:00 PM pacific time
Note taker: Mike Kallas

BoF Chairs :
Melinda Shore,
Alexandru Petrescu.

Meetecho log:
http://ietf88.conf.meetecho.com/index.php/Recorded_Sessions#GEONET

Jabber log:
http://www.ietf.org/jabber/logs/geonet/2013-11-05.html

------------------------------------------------------------------
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 solutions 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. 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, ex-Chrysler) 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.

Next on the Agenda: implementation Interest: presentation.

Last topic: IPv6 over 802.11p. Presentation

End of presentation part.

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.
Answer: looking at a relationship between IP addresses and locations
of Access Routers.

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.

Comment: trust model and the uncertainty of locations.

Question: have you looked at ILNP?
Answer: no, but will.

Comment: see the document referred to on jabber
(draft-hain-ipv6-pi-addr-10).

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, reliability.

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 for this work here. Because it is related.
Answer: this is an issue and we need help with the liason with IEEE.
Liaison: we will address it.

Comment: HIP MAP server.

Question: skeptical about problem. Geographical routing vs optimal routing.
Answer: an optimal IP routing path may be different from optimal
geographic 'routes'. Optimal geographical route may not be possible,
whereas the other can, and vice-versa.

Stop discussion: need to figure out what will happen next

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

Is there work appropriate to the ietf: a few, some reluctance
Not appropriate for IETF: one person only (the reason has to do with
explicit reference to DNS).

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

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

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?  next BoF - another BoF?

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.

Ted Lemon (Area Director in charge of this BoF): 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.

Last word by Eliot Lear (IAB member following this BoF): thanks to BOF
chairs. Couple of very interesting problems: actions to move it
forward:

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.