Thanks for the pointer. In order to meet IEEE's request, we may have to
move forward with something more ad-hoc, but in the long term, it will
probably make sense to align on a single standard for interior location.
--Richard
creed@opengeospatial.org wrote:
> Richard -
>
> Thanks for the excellent meeting notes.
>
> On item 7, perhaps related, there is a new collaboration about to begin
> titled "Open Floor Plan". Essentially, this collaboration is between
> multiple standards organizations and interested individuals that is
> focused on defining a lightweight interchange and encoding for floor
> plans. The driving use cases are emergency services and in building
> navigation. Currently, the standards organizations are the OGC,
> NIBS/buildingSMART, and OASIS. The "new" model would actually be a limited
> profile of an existing standard from the international building industry
> (I believe).
>
> Regards
>
> Carl
>
>
>
>
> > 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.
>>
>>
>> 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
>>
>
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
