Re: [Geopriv] Draft GEOPRIV minutes from IETF 75

"James M. Polk" <jmpolk@cisco.com> Wed, 29 July 2009 09:04 UTC

Return-Path: <jmpolk@cisco.com>
X-Original-To: geopriv@core3.amsl.com
Delivered-To: geopriv@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAF6E3A6EDE for <geopriv@core3.amsl.com>; Wed, 29 Jul 2009 02:04:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.522
X-Spam-Level:
X-Spam-Status: No, score=-7.522 tagged_above=-999 required=5 tests=[AWL=1.077, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8C2maqY8uPF for <geopriv@core3.amsl.com>; Wed, 29 Jul 2009 02:04:04 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B24033A699F for <geopriv@ietf.org>; Wed, 29 Jul 2009 02:03:57 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqIHAJutb0qrR7PE/2dsb2JhbACISLMIiCeQKgWCLAYNgVGBTQ
X-IronPort-AV: E=Sophos;i="4.43,288,1246838400"; d="scan'208";a="190653665"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2009 09:03:59 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n6T93xMV021610; Wed, 29 Jul 2009 02:03:59 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6T93x5M003313; Wed, 29 Jul 2009 09:03:59 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 02:03:58 -0700
Received: from jmpolk-wxp01.cisco.com ([10.89.15.133]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 02:03:58 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 29 Jul 2009 04:02:20 -0500
To: Richard Barnes <rbarnes@bbn.com>
From: "James M. Polk" <jmpolk@cisco.com>
In-Reply-To: <4A6EB80D.9010400@bbn.com>
References: <4A6EB80D.9010400@bbn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Message-ID: <XFE-SJC-211K8jcAI5D000054c5@xfe-sjc-211.amer.cisco.com>
X-OriginalArrivalTime: 29 Jul 2009 09:03:58.0233 (UTC) FILETIME=[81E42090:01CA102B]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11126; t=1248858239; x=1249722239; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20<jmpolk@cisco.com> |Subject:=20Re=3A=20[Geopriv]=20Draft=20GEOPRIV=20minutes=2 0from=20IETF=2075 |Sender:=20; bh=B8bfHI1vbtRGj2nxIJwAVgLTpNJuI8KFDlynol7jxCw=; b=A3/UZ4FWbGTEaOy4EUlgonL3u4UcxaNnbIWayvptwy32gP1uWyAJZbaLT4 epDoPxbms69wuxeW6xNw5hMuhZz0dkMwP0/FneWIJhvbXmoEK9NPZfIJtQtp VVYo9IOK9f;
Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
Cc: geopriv@ietf.org
Subject: Re: [Geopriv] Draft GEOPRIV minutes from IETF 75
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/geopriv>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jul 2009 09:04:05 -0000

you might want to say somewhere that hands were used instead of hums 
because the room acoustics prevented hums from accomplishing what 
they normally do. Someone reading this down the road might question 
this procedure mentioned below.

more in-line below

At 03:34 AM 7/28/2009, you wrote:
>Draft minutes for the GEOPRIV meeting at IETF 74 are below.  Please 
>send comments to the list no later than Friday, 7 Aug 2009.
>--Richard
>
>
>----------
>Minutes - GEOPRIV - IETF75
>
>Summary (prepared by Richard Barnes):
>
>1. Agenda Bash
>Brian Rosen requested 10 minutes at the end of the meeting to 
>discuss his drafts on extensions to the PIDF-LO civic address 
>elements.  James Polk volunteered 10 minutes of his time for 
>dhcp-lbyr-uri-option to extend discussion of geopriv-arch.
>
>2. Geolocation URI
>    draft-ietf-geopriv-geo-uri
>Alex Mayrhofer presented a brief update on the WG draft describing a 
>URI scheme for geolocation.  The current version adds a CRS 
>parameter, and the next will address comments from the URI-Review mailing list.
>
>3. Location Filters
>    draft-ietf-geopriv-loc-filters
>Brian Rosen presented a brief update on the WG draft describing a 
>filter language for location updates.  The current draft is a 
>significant update from prior versions, basing the filters on the 
>general RFC 4661 filter syntax.
>
>
>4. GEOPRIV Architecture
>    draft-ietf-geopriv-arch
>Alissa Cooper presented an update on the WG draft describing an 
>overall privacy architecture for GEOPRIV.  The developemnt of the 
>current version was focused on refining terminology, in particular 
>the meaning of the term "LIS"; discussion of that topic continued in 
>the meeting, with no clear resolution.
>
>5. Location URIs in DHCP
>    draft-ietf-geopriv-dhcp-lbyr-uri-option
>James Polk presented an update on the WG draft describing a 
>mechanism for carrying location URIs in DHCP.  Hannes Tschofenig 
>submitted an extensive review of the current version of the 
>document, and James is still working through these comments.  James 
>agreed to send a summary of the open issues in the draft to the 
>list.  Several participants said that the current prohibition 
>against the use of HTTP URIs should be modified to permit at least 
>some classes of HTTP URIs.

Regarding the last point here:

Firstly, I think it is only HTTPS URIs, and not HTTP URIs, but I 
could be wrong here (but I don't think I am).

Secondly, this has to come via the Application Area AD (Lisa) who 
told me to create this list of what's allowable, verses what's 
prohibited.  Her view is that she'll block the ID when going through 
the IESG, which is a hurdle the WG needs to consider. Now, at the 
same time, Ted volunteered to champion that effort of getting HTTPS allowed.



>6. Updates to DHCP Geodetic Location (RFC 3825bis)
>    draft-ietf-geopriv-rfc3825bis
>Bernard Aboba presented an update on the WG draft that makes a 
>series of udpates to address errors and unclear points in RFC 
>3825.  Individual changes are being tracked using the issue tracker 
>on tools.ietf.org, and most are awaiting text from their assigned authors.
>
>7. IEEE Liaison
>Dorothy Stanley, chair of IEEE 802.11 TGv, presented a liaison 
>statement from 802.11 to GEOPRIV requesting that GEOPRIV develop a 
>binary encoding for the GML shapes that are available in XML, mainly 
>for use in interior location scenarios.  Some participants addressed 
>doubts as to the utility of such a translation, but others supported 
>working on this topic.  Discussion will continue on how to respond 
>to this request.
>
>8. HELD Extensions
>    draft-winterbottom-geopriv-held-deref
>    draft-winterbottom-geopriv-held-identity-extensions
>    draft-thomson-geopriv-res-gw-lis-discovery
>    draft-thomson-geopriv-held-measurements
>Martin Thomson led a discussion on a series of proposed HELD 
>extensions.  He gave a brief description of each document, with some 
>group discussion after each description.  Privacy concerns continue 
>to be a significant concern for the HELD Identity extension, and 
>there is continuing debate over the need for special mechanisms for 
>residential gateways.  Shows of hands indicated varying degrees of 
>support for these drafts, but rough consensus to work on all 
>four.  Discussion on how to sequence these drafts will continue.
>
>9. PIDF-LO Civic Address Extensions
>    draft-rosen-geopriv-pidf-interior
>    draft-rosen-geopriv-prefix
>Brian Rosen introduced two drafts that extend the PIDF-LO civic 
>address structrure to include (1) "prefix" elements that match 
>current "suffix" elements, and (2) a generic element "INT" to 
>represent interior location elements.  The major issue with the INT 
>element right now is whether to register values for it: Some view 
>registration as necessary to avoid ambiguity, while others note that 
>the lack of standards for building models could cause a lot of noise 
>in the registry.  A show of hands indicated strong support for 
>working on the -prefix draft; discussion will continue on the 
>-pidf-interior draft.
>
>
>
>Raw notes from Marc Linsner follow:
>
>------------------------------------------------------------
>
>Geopriv Notes
>
>Agenda Bash: brian wants to discuss INT
>     James wants lbyr longer
>
>status update: charter updated; W3C GeoLocation last call deadline this
>Friday;
>
>Lightning Round:
>
>Alex - GeoURI - discussion around CRS - consensus seems to be that WGS84
>should be default, but don't preclude other CRS, solution in the current
>draft.  Is a URI parameter registry needed? What about privacy policies?
>
>Brian - loc-filters - 05 released this morning; now based on RFC4661;
>several changes - read the slides/text!  Issue: Normal Reference to -dynamic
>which is experimental
>
>Alissa - Geo-arch: not trying to dramatically change from existing Geopriv
>work or implementations. Describe what a 'LIS' means; James - the current
>definition of LIS seems to fit the HELD arch but no necessarily the DHCP
>architecture.  Brian - there is current usage of LIS includes dereference.
>Marc - the term LIS is still muddy. Jon - What's wrong with the current
>text? - Brian - like I just said, 'own location' does not cover
>dereferencing.  Ray - ???
>
>James Polk - lbyr uri - chose the auth. security model; rewrote the intro;
>addressed Ted's concern; Hannes is addressing things from the 00 draft 2+
>years ago.  Some of Hannes' comments were good.  Keith: this is a wg draft?
>You are not the arbitrator of the text, the wg is.  Hannes is commenting on
>the jabber...(read the jabber).  Jon: I'm lazy, I read the doc for the first
>time today.  I am curious why only SIP, SIPS, PRES uri?  Why not HTTP uris.
>James: Jon you agreed to this earlier.  Ted: you need structure around the
>URIs, hence this restriction.  We need to work on this.  Jon, we need HTTP
>uri support. Ted: if we had support for a HELD uri would that satisfy your
>concern.  Brian: I want to support HELD uris  James: this needs to be run by
>Lisa. Ted: I'll take the task to run this by Lisa.  Cullen: I agree Ted,
>we'll work this out.
>
>Bernard - rfc3825bis - started with 3825; we have an issue tracker; we will
>make changes based on list discussion and consensus.  Issue 9 & 10 closed;
>Issue 1 resolved; Issue 2 needs list discussion; Issue 5 has been sent to
>the list; Issue .... (read slides) Keith: does the assignee have more
>authority?  Bernard, all text will be discussed on the list.  Martin: I have
>proposals...I'm don't have motivation.  Richard: please copy/cut paste from
>your other draft.
>
>Dorothy Stanley - IEEE liaison - chair 802.11tgv and liaison to IETF -
>summarize the letter sent last week.  (read slides)  covered background of
>802.11 location work.  IEEE is requesting the IETF to extend the BINARY
>representation of the location objects to include shapes, etc.  Cullen -
>verify the dates....wg doc. Brian questioned the usefulness. Martin
>supported Brian.  Marc - IEEE is asking for xml to tlv mapping, not critque
>of their application.  Ted - decide to do the work, then have the
>application discussion Hannes - 3GPP has already done this work. Dorothy -
>we chose to come to IETF first.  Gabor - Nobody has this defined, not in
>3GPP
>
>Martin Thomson - HELD extensions - 4 drafts - deref, identity extensions,
>res-gw-lis-discovery, held measurements.  Derefernce - do people think this
>is useful/necessary?  Identity - (read slides) - Marc:   Brian: I don't see
>anything in the doc about a 3rd party using IP address to ask for someone's
>location. Cullen: I believe we agreed to not do the 'authorized third
>parties'.  (missed some)  Ted: I agree with Marc...you are changing the
>rules around LCP.  The draft needs to explain why/how we are changing the
>LCP rules before becoming a wg draft.  Martin: the doc talks about the need
>for authorization.  Jon: We need to solve this problem and need to
>prioritize this as the first problem.  Bernard: Maybe break off the third
>party issue and deal with it separately.  Lis Discovery: a large group of
>home gw devices don't support this. Cullen: it's too strong a statement,
>some devices do support.  (Ray Bellis): this overloads option 15 and use of
>it.   Cullen: if we have a solution that is supported on some of the
>existing, we need to use it.  Ray Bellis: this draft will work with no work
>in the home gateway.  Measurements: necessary for cooperative location
>determination.  Brian: I think this is the least interesting of the 4  Marc:
>please characterize measurements and identity extensions.  Ray Bellis: In
>the UK, we need identity and res-gw-discovery
>
>Richard: Any more comments on the prioritization??  Identity Extensions then
>HomeGw LIS Discovery
>
>Brian: Concerns over putting deref off for another year.
>
>Jabber room: all 4 are equally important
>
>HUMS:
>Those in support of the group working on Deref:  (no hums)
>Those no in support of the group working on Deref: (no hums)
>
>Should the wg work on a deref for HELD: (little hums)
>(never asked for the opposite)
>
>Should geopriv address the problems of Identity?  (17 hands raised)
>Against (1 hand raised)
>
>Gateway discovery problem, in favor (9 hands raised)
>Against? (1 hand raised)
>
>Measurements, (8 hands raised)
>Against? (3 against)
>
>Brian - Additions to PIDF - prefix draft - 2 additions to handle prefix in
>civic addressing.  Can we take this on as a wg item.  pidf-interior - we
>can't support a lot of interior spaces.  This works in more cases.  James -
>no registry leads to interoperability problems.  Ted - there is no standard
>for interior spaces.  Richard: Aren't these drafts at odds with each other?
>
>Hum:
>
>Should we do prefix??  (14-15 hands)
>Opposed?  (none)
>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv