Subject: [Geopriv] IETF 84 Minutes

From: Alissa Cooper <[email-masked]>
Date: Fri, 24 Aug 2012 17:39:31 -0400

Minutes - GEOPRIV - IETF 84

Summary

1. WGLCs for   
 -- draft-ietf-geopriv-local-civic
 -- draft-ietf-geopriv-relative-location
 -- draft-ietf-geopriv-res-gw-lis-discovery

At least one non-author committed to review each of the above documents. Chairs will send a deadline for comments to the list.

2. draft-bellis-geopriv-flow-identity

WG agreed to adopt this document, with fast track to WGLC. Robin Wilton and Martin Thompson agreed to review it. 

3. draft-jones-geopriv-sigpos-survey

Room expressed interest in this topic. Kipp will spur discussion on the list. Adam Roach and John Pickens agreed to review the document.

Raw notes from Matt Lepinski
--------------------------------------------

Note: James Polk sent a message to the list regarding an IRTF document
extending IPFIX to support geolocation, but this document  that has
zero privacy considerations!
    Please read the document and comment on the appropriate IRTF list

Note: Three Working Group Last Calls on the list, no responses other
than from the authors
 -- draft-ietf-geopriv-local-civic
 -- draft-ietf-geopriv-relative-location
 -- draft-ietf-geopriv-res-gw-lis-discovery

Marc Lisner: Commits to send nits on relative location to the list

Brian Rosen: NENA despretely needs Local Civic
         ... I think relative location is ready to progress

Kyp Jones: We make use of the civic address extensions and relative
locations, support them progressing
     ... commits to send nits on these documents

Roger Marshall: commits to send nits for Local Civic and LIS Discovery
to the list

*** Chairs: Will send out a reminder, with a deadline in a couple
weeks from this meeting. Intent to get them to the IESG very soon.

---------------------------------
Flow Identity by Ray Bellis
---------------------------------

-- Request for working group adoption of draft-bellis-geopriv-flow-identity-00
  ... fills a potential hole in identity extensions

-- Promises to review by: Robin Wilton ([email-masked]) and Martin Thompson

*** Consensus to adopt this document. Chairs will attempt to fast
track this document through the working group.
   ... it is short and straightforward, but important.

--------------------------
Indoor Signal Position Conveyance by Kyp Jones (of Skyhook)
---------------------------
Document: draft-jones-geopriv-sigpos-survey
Slides: http://www.ietf.org/proceedings/84/slides/slides-84-geopriv-0.pdf

-- Adam Roach: This is an interesting problem space. However, I don't
see anything in the spec about transport mechanism for this data. How
this is sent across the network will have a lot of affect
 Answer: I expect this will probably be transported by HTTPS, but I
welcome discussion of how to talk about transport in the document

-- Martin Thompson: I have read this. There seem to be two very
different usage models: (1) crowd-source, (2) contracted to do a
survey with specialized equipment
   ... These models seem to be quite different, especially when one
talks about licensing
   ... I think it may be possible to deal with licensing
declarations out of band, I am interested in hearing a clear argument
for why in-band declaration of licensing in the interchange is the
right way forward
   ... and you certainly make different use of data depending on
what model it comes from
   ... raises questions about crowd-sourcing in private spaces
 Answer: There seems to be some fuzziness in the industry with
regards to things like definitions of private spaces with regards to
wireless signals.

-- Martin Thompson: This is a minor structuring point, but I think the
location of the beacon is a property of the venue (at a point in time)
instead of a property of the survey. I see a survey as a collection of
measurements. We should talk about this more offline

-- Robin Wilton: I think this is interesting. I think there are some
issues to explore which may be applicable to other contexts (in
particular, from a privacy and data-rights point-of-view).
 1. User opt-in opt-out by default
 2. Transparency
 3. Use of the data
 Therefore, it may be valuable to document some of these
considerations in the document.

-- Alissa: Question about the other players in this space. We have a
lot of relevant expertise in this room, but we don't have all the
people who would benefit from this standardization.
 Answer: This is somewhat of a chicken-egg problem. It is easier to
get people interested in participating once if it has been accepted by
a working group. I appreciate any guidance on how best to solve this
chicken egg problem.

-- Many hands think this is an interesting problem that could benefit
from standardization and that the working group should spend some time
on.

***  Chairs encourage Kyp to keep working on this, and encourage
working group members to comment on the list.
***  Chairs request for concrete reviewers: Adam Roach (maybe?), John Pickens

---

From: Roger Marshall <[email-masked]>
Date: Fri, 31 Aug 2012 22:24:28 +0000

Per Alissa's thread, please find my "nits" comments to draft-ietf-geopriv-res-gw-lis-discovery-04:

Overall, I thought the document was well formed, and so I provided only a few suggested wording changes and requests for clarification, within the substitution marks as follows.

C1. Introduction, pp3.:

s/The configuration of a LIS address/The inclusion of a LIS IP address/1 ("configuration" redundant, "address" ambiguous)

C2. Intro, pp3., 

s/move between different access networks/move between different access networks served by different LIS'/1

C3. Intro, pp4., 

s/In most cases, these functions effectively prevent/Unfortunately, in most cases, these functions effectively prevent/1

C4. Intro, pp4, (last sentence seems to beg the question, "why?")

C5. Intro, pp5., 

s/The drawback with DHCP is/One drawback of the DHCP approach/1

C6. Intro, pp5, last sentence, (since devices could be built to this standard before it gets published...)

s/gateways built before the publication of this specification do not (and cannot) provide/ gateways built before the publication of this specification are not expected to, and likely are not able to provide/1

C7. Section 3., pp3., (assuming that geographical area is the type of are being referred to in the text)

s/Given a small enough area/Given a small enough geographical area/1

C8. Section 3., pp4.,

s/covers a larger area/covers a larger geographical area/1

C9. Section 3.1., pp4., (assuming that this is a bad thing)

s/Such an active involvement/Unfortunately, such an active involvement/1

C10. Section 4.1, pp2., 

s/A Device can use the ... (STUN) [RFC5389] to determine/ A Device can use the ... (STUN) [RFC5389] mechanism to determine/1

C11. Section 4.1., pp2., (clarify "host" wording, something like suggested below)

s/host/DNS host/1

C12. Section 4.2., pp2., (?assuming that we're talking about a DNS record here)

s/for a single record/for a single DNS record/1

C13. Section 4.2., pp5., (make more explicit)

s/SHOULD NOT be performed to limit the number of DNS queries performed by Devices.
   If no LIS is discovered by this method, no more than four U-NAPTR
   resolutions are invoked for each IP address.
/ SHOULD NOT be performed in order to limit the number of DNS queries performed by Devices.
   If no LIS is discovered by this method, it is recommended that no more than four U-NAPTR
   resolutions are invoked for each IP address.
/1

C14. Section 4.3., (Section Title reword)

s/When To Use This Method/When To Use The Reverse DNS Method/1

C15. Section 4.5., pp1., first sentence, 

s/Successful use of private addresses relies on a DNS server that is able to see the private address space; therefore, a means to determine a public IP address is necessary.
/Successful use of private addresses relies on a DNS server that is able to see the private address space; therefore, for external IP address discovery, a means to determine a public IP address is also necessary.
/1

C16., Section 4.6., pp1., (?clarify)

s/any DNS internal to that NAT SHOULD/any DNS server internal to that NAT SHOULD/1

C17., Section 4.6., pp2., (wording)

s/allowing for exceptions to be provided for at the lower point/allowing for exceptions provided at the lower point/1

C18., Section 6., pp3., (clarify - assumptive)

s/in an attempt to subvert the rest of the process/in an attempt to subvert the remaining discovery process/1

C19., Section 6., pp4., (wording)

s/Even if a STUN/Likewise, for the LIS discovery process, even if a STUN/1

C20., Section 6., pp5., (wording)

s/This attack is an effective means of denial of service, or/This attack could result in an effective means of denial of service, or/1

Regards,

-roger marshall.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alissa Cooper
Sent: Friday, August 24, 2012 2:40 PM
To: GEOPRIV WG
Subject: [Geopriv] IETF 84 Minutes

Summary

1. WGLCs for   

_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.