[Geopriv] Draft GEOPRIV Minutes from IETF 73

Richard Barnes <rbarnes@bbn.com> Fri, 21 November 2008 20:48 UTC

Return-Path: <geopriv-bounces@ietf.org>
X-Original-To: geopriv-archive@megatron.ietf.org
Delivered-To: ietfarch-geopriv-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B1893A6840; Fri, 21 Nov 2008 12:48:36 -0800 (PST)
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 980023A68BF for <geopriv@core3.amsl.com>; Fri, 21 Nov 2008 12:48:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.201
X-Spam-Level:
X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[AWL=-1.302, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_82=0.6, MANGLED_EXTNSN=2.3]
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 JSz0btEdWqyJ for <geopriv@core3.amsl.com>; Fri, 21 Nov 2008 12:48:28 -0800 (PST)
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 058A13A6407 for <geopriv@ietf.org>; Fri, 21 Nov 2008 12:48:28 -0800 (PST)
Received: from [128.89.255.110] (helo=Richard-Barnes-Laptop.local) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <rbarnes@bbn.com>) id 1L3cvR-0001am-AN for geopriv@ietf.org; Fri, 21 Nov 2008 15:48:25 -0500
Message-ID: <49271E98.2060908@bbn.com>
Date: Fri, 21 Nov 2008 14:48:24 -0600
From: Richard Barnes <rbarnes@bbn.com>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: 'GEOPRIV' <geopriv@ietf.org>
Subject: [Geopriv] Draft GEOPRIV Minutes from IETF 73
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: <https://www.ietf.org/mailman/private/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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Sender: geopriv-bounces@ietf.org
Errors-To: geopriv-bounces@ietf.org

Draft minutes for the GEOPRIV meeting at IETF 73 are below.  Please send 
comments to the list no later than 25 November 2008.
--Richard


Minutes - GEOPRIV - IETF73

Summary (prepared by Richard Barnes):

1. Retransmission issues in SIP location conveyance
	draft-ietf-geopriv-sip-lo-retransmission-01
Jon Peterson led a discussion of open issues with this draft.  The group 
reached consensus on the two remaining issues in this draft: Syntax and 
B2BUAs.  First, there was agreement that the document is clear enough 
that the provided syntax is an example and not binding on the SIP WG. 
Second, there was consensus that (1) the WG should provide guidance for 
B2BUAs and (2) the spirit of the current guidance is correct.  Brian 
Rosen will submit revised text for the B2BUA section.

2. HTTP-Enabled Location Delivery (HELD)
	draft-ietf-geopriv-http-location-delivery-10
Mary Barnes gave an update on recent changes.  There was discussion of 
decoupling LIS discovery and HELD.  Mary will produce a new draft 
addressing AD comments before the end of the year.  Eric Rescorla will 
review the document again for security concerns.

3. LIS Discovery
	draft-ietf-geopriv-lis-discovery-04
Martin Thomson presented an update on this document, highlighting two 
open issues: URI schemes and discovery mechanisms.  The group reaffirmed 
its consensus on using HTTP/HTTPS URIs. Several participants who 
expressed a preference for a new scheme noted that they are ok moving 
forward with this decision.  Martin proposed removing everything but the 
DHCP-based discovery mechanism from the draft, based on comments from 
Peter Koch on the applicability of DNS for this problem.  Richard Barnes 
suggested that the DNS-based solution might be salvageable.  Discussion 
will continue on the list.

4. Civic Address Recommendations
	draft-ietf-geopriv-civic-address-recommendations-00
Alex Mayrhofer gave an update on this new WG document.  Several 
participants spoke in favor of this document.  Hannes Tschofenig noted 
that he is working with EENA to produce similar standards for European 
nations.  Brian Rosen and Richard Barnes proposed creating an IANA 
registry for jurisdiction-specific usages of the civic address XML 
structure.

5. Location Update Filtering
	draft-ietf-geopriv-loc-filters-03
Brian Rosen gave an update on this document.  Martin Thomson noted that 
the "location delta" format needs work.  Brian noted that a generic 
"element changed" filter would be useful, but he can't commit to 
creating it.  Brian will produce a new version, addressing Martin's 
comments and aligning with RFC 4661 updates.

6. 3693 Update
	draft-barnes-geopriv-lo-sec-03.txt
This agenda item was dropped in the interest of leaving time for later 
presentations.

7. Cross-area feedback on identifiers
	http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00192.html
	draft-winterbottom-geopriv-held-identity-extensions-07
This agenda item was moved to the end of the meeting during the agenda 
bash, and was dropped due to insufficient time, and because the relevant 
people from other areas were unavailable.

8. Third party access to location information
	draft-winterbottom-geopriv-held-identity-extensions-07
     draft-linsner-geopriv-obo-00
Jon Peterson led a discussion on the question of whether GEOPRIV should 
develop mechanisms to support requests for location in which neither the 
Location Recipient nor the Location Server is the Target.  There was 
strong consensus in the room that it is important to support request for 
location by third parties, keeping in mind that such transactions 
included a role for a Rule Maker.  Several participants presented 
motivating use cases, and no objections were raised.

Raw notes from Richard Barnes, Ben Campbell, John Elwell, and Roger 
Marshall follow:


------------------------------------------------------------
GEOPRIV at IETF73, Tuesday, 19 Nov 2008

===== Administrivia =====
-- Agenda bash:
	-- cross-area feedback moved to the end to minimize conflict with idnabis
	-- periodic-location if we have time at the end
-- Status update
	-- WGLC on lbyr after thanksgiving
	-- lbyr needs discussion between polk/martin
-- W3C update
-- Martin: SIMPLE continuous presence doc

===== Retransmission =====
-- Syntax issues
	** Use of header field allows prefs without location
	-- Polk: Maybe provide alternative examples and contrast (?)
	-- Hardie: We should make semantics clearer so that SIP can use to 
compare alternatives
	-- Rosen: We shouldn't hold this document up on this; we can't do 
syntax anyway
	-- HUM: Is the document clear that the syntax is an example?
		-- Several in favor
		-- None against
-- B2BUA issues
	-- Peterson: Tried to clarify implications of decisions by B2BUAs
	-- Rosen: Don't think the current draft does this; I'll send text
	-- Hardie: Trying to help people understand how to apply GEOPRIV principles
	-- Kaplan: Agrees that you should tell B2BUAs what to do; put in a MUST
	-- Sparks: Also need to handle the case where SIP calls transit the PSTN
	-- MBarnes: This text is important, but this discussion should be in SIP
	-- Hardie: This is still just advice from one WG to another
	-- Jennings(AD hat): Need to get these docs done
	-- Drage: SIP can't really deal with B2BUAs either
	-- Polk: S3.6 does have text for -conveyance.
	-- HUM: Does the WG believe that this document should contain a 
consensus opinion from this group on how B2BUAs should behave?
		-- Strong in favor
		-- Weak against
	-- HUM: Do you think the current document captures WG consensus on how 
B2BUAs should behave with respect to location retransmission?
		-- (postponed)
	-- HUM: Do you think that the spirit of the recommendation captures 
what we believe is right and that we're down to wordsmithing?
		-- Weak/med in favor
		-- None against
	-- ACTION: Brian Rosen to provide updated text
	-- ACTION: Hardie will produce a new version this week if Brian 
produces text this week

===== HELD =====
-- URIs
	-- Sparks: Proposal to use HTTP URIs with a "be careful" in the 
security considerations
	-- Thomson: What problem are you trying to solve by proposing this change?
		-- Trying to decouple discovery and HELD
	-- Hannes: Thought for a long time that we should decouple discovery 
and HELD
-- Changing validity interval recommendation "several minutes"=>30min
-- Removing reference to RFC 3704
-- ACTION: Re-review from Ekr
-- ACTION: New draft before the end of the year

===== LIS-discovery =====
-- URIs
	-- Pretty strong consensus to use HTTP/HTTPS, not a new scheme
-- Discovery mechanisms
	-- Rosen: DHCP OK.  Question: What is the use case for not DHCP, but 
yes DNS?
		-- MT: Part of the reason we're doing an L7LCP is that DHCP loc didn't 
work for a lot of people
			-- DSL networks (PPPoE config, etc)
		-- Rosen: But those guys don't have DHCP anyway!
			-- Nope, there are non-DHCP options
	-- Question: Is there push-back on the DHCP part of this draft?
		-- Sparks: No push-back; need to check with DHC; maybe add cert 
fingerprint?
	-- DNS-based discovery:
		-- Koch: arguments against from the DNS perspective
		-- Barnes: Should look at assumptions
		-- Martin: Inclined to remove this / separate document
		-- ACTION: Work this out on the list
		
===== Civic Addresses =====
-- Discussion
	-- Rosen: Really like this doc.  Really need to recruit other countries 
to do the same thing.  I'll do the US.
	-- Hannes: Working with EENA to do this for European countries.
	-- Rosen / RBarnes: Let's create a registry, allow multiple per 
country, tag civic addresses with which format
	-- Cullen(AD hat): Don't foresee any IESG problems with making a registry
	
===== loc-filters =====
-- Thomson: Another aspect that might need work is the "location-delta" 
format.

===== lo-sec =====
-- Bashed off the agenda

===== Third-party requests =====
-- Norreys: We would have trouble without authorization from the endpoint
	-- Peterson: User is still causing/enabling the LBS to make the request
	-- Norreys: With that caveat, this could be useful
	-- Peterson: Do you think this could be a plausible use case?
	-- Norreys: There are probably 3rd-party services that would want it, 
need authorization
-- Polk: Concerned that endpoint might not know when/how his location is 
being revealed
	-- Peterson: Absolutely want to have a rule maker, but it's easy to 
miss how that role fits in
-- Thomson: The mapping to 3693 seems pretty clear here; we need to 
tackle this problem
	-- Peterson: This is the concern that Morris raised, that we'll become 
irrelevant
-- Erik Burger: The chip in my dog is a Target with no UI.  Need to 
support positioning this too.
-- Matt: This will happen, we can only help add privacy stuff
-- Hardie: Is there some difference from 3693 that I'm not getting?
	-- Peterson: What's different is that it's LIS instead of LG
	-- Hardie: So there's an RM-PS interaction?  Need to create a rule 
referenced by the seeker
	-- Hardie: Need to include the identifier in security/privacy boundary
-- Linsner: identity-extensions removes requirements/motivation in 
recent draft
	-- Peterson: Do you object to what's being said here?
	-- Linsner: Object to getting rid of the Rule Maker
-- Hannes: We've been talking past each other; this diagram captures it 
nicely; doc should be clearer
	-- RM relationship might be done contractually as well.
-- Thomson: I'll add motivation to the document to respond to Marc's 
suggestion
	-- The way rules get to the LIS can be out-of-band
-- Gellens: This is kind of different, since there are different rules 
at the LIS and the LS
	-- Peterson: Sure, the reason we need weird ID considerations is that 
the LIS doesn't really get policy
-- Polk: Strongly believe that the LIS is the LG in the 3693 sense
-- Alissa: Seems like the motivation almost accomodates requests against 
the Target's wishes
	-- Peterson: There are cases like that (non-Target RMs)
-- Linsner: Problem with the current document is that when RM is brought 
into the doc it's not sincere
	-- Peterson: Undoubtedly, the document is imperfect, but if we can 
agree this is a good case, we can fix the doc
-- Thomson: Alissa's concerns can be alleviated if the Target acts as 
RM; remember that LIS is an LG and an LS
	-- Peterson: Sure, just different policies and provisioning mechanisms.
-- Hardie: In many cases, the target will not be the RM
** Conclusion: Strong agreement that this is an important use case to 
consider



------------------------------------------------------------
GEOPRIV - IETF73 - Tuesday 0900-1130


Welcome Richard as a co-chair


10m    Administrivia/Status

Agenda bash - Ted requests that we swap last two items due to schedule 
constraints.

Mary asks for feedback on a wimax related draft.

During update - missed dhcp-lbr status. James believes its basically 
done, but there are some comments that may have impact on draft.

Martin - draft in simple about how to put location in presence. Please 
participate. Martin will send pointer to document.


40m    Finalize any outstanding conversations on sip-lo-retransmission 
(Jon Peterson)
 
http://tools.ietf.org/html/draft-ietf-geopriv-sip-lo-retransmission-01.txt

2 major changes. Separate semantics from syntax. Offer possible syntax, 
but let SIP work out details.

Soften b2bua language--can't compel b2bua's, but we can show 
consequences of behavior.

Discussion:

First point:

Keith: is the parameter a header-field or URI parameter. Answer: We're 
not defining that, but example uses a parameter of geolocation header. 
Using a header allows some additional expression beyond a header parameter

James Polk: Geolocation header is not named in draft. Suggests adding 
"for instance" example showing it in a header vs a parameter. Response: 
We're still working out how concrete to be for this. There is a slight 
semantic difference between the two--open issue as to whether we want to 
couple geolocation routing to the geolocation header.

Ted: We can have the same semantics if we modify geolocation header to 
allow null location values.

Ted: SIP has sent this back to geopriv due to lack of geopriv agreement 
on semantics. If we can express the semantics, we are good to go. We 
should give example syntax that expresses the semantics. SIP can change 
that if they want. We need to get them something soon.

Brian: Don't hold up the document for this.

James: Draft is not clear that the syntax is exemplary, not 
prescriptive--do others agree?

*** Hum: Is the draft clear on this point?

Results: Several hums for, zero against.

Keith: Is there a requirement to be able to send location routing policy 
without location information? No, the requirement is that the rule maker 
must be able to associate policy with location. Separating the two is 
one way to accomplish that.

Discussion about SIP wanting this draft complete before moving forward. 
JFP is concerned about the layer of indirection.

James states he is satisfied with hum on syntax examples.

2nd point:

B2BUA language was too prescriptive. We can't force rules on B2BUAs, but 
we can show design tradeoffs. This was the intent of new text--did we 
succeed?

Brian: Doesn't think we succeeded. Given language does not tell when you 
should or shouldn't worry about it. But people who count won't pay 
attention to it--prefers to delete it. If we can't delete it, Brian will 
send text. JFP would love to delete it.

James: Confused by a discussion from Robert that the b2bua discussion is 
about gateways. JFP: It's about b2bua's, not specifically gateways.

Ted: You have to understand geopriv principles as a whole applies to 
this other system. We write this down to help us understand how actors 
in SIP networks can apply these principles. If b2bua implementers won't 
listen, it doesn't do harm, but there may be value keeping it to help us 
with this understanding. If we rip it out, we remove part of the 
explanation of the geopriv system.

Hadriel: Even if they won't listen, you should still tell them what to 
do. Wants stronger (normative?) language.  JFP: Does existing language 
persuade? Hadriel wants some MUSTs.

JFP: Important distinction--this is to instruct SIP, not final 
implementers. SIP can handle the normative stuff.

Real Robert Sparks: (refer back to gateway conversation). The idea of 
crossing a pair of PSTN gateways is helpful for illustrating b2bua 
issues. It may be possible for the gateways to carry location. If this 
is true, then any b2bua discussions must be able to handle that 
scenario, and it makes a good model for discussion.

Mary: This debate belongs in SIP. The b2bua guidance does not belong in 
this document.

Ted: Unless SIP decides to take on b2bua's, we should not expect SIP to 
offer more guidance for this than for any other header. If geopriv has 
opinions here, it should express them.

Cullen: (as AD) balance this with getting the document done quickly, and 
allowing SIP to get a document out quickly.

James: Believes 3.6 has text implications on location conveyance. He's 
Not sure if he understands how to account for the double-gateway model 
for b2bua's in location conveyance. JFP: Does that draft discuss b2buas? 
(no)

Keith: The only b2bua that SIP can talk about is a concrete pair of UAs 
in a single box--not the protocol between the UAs. (Room does not seem 
to agree)

JFP: Lets focus the discussion on whether geopriv support on whether the 
language in the document is a reasonable recommendation in general.

*** Hum: Does the wg believe that this document should contain a 
consensus opinion from this group on b2bua behavior.

results: Strong hum for yes, only a couple for no.

*** Hum: Do you think the spirit of the existing text is on the right 
track and we are down to wordsmithing?

results: yes

JFP: So now it's all down to Brian :-)

Robert -- what's the time pressure on this? Is someone desperately 
waiting on this?

Ted: Ted's bowels are desperately waiting on this!

Conclusion: Brian will offer text on list, Ted to incorporate.


05m    Update/discussion on http-location-delivery (Mary Barnes)
 
http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-10.txt


version 09 Several changes from LC review.
version 10 - addressed concerns about lack of URI schema registration 
and SOCKS recommmendations.

Primary open issue: URI schema for URI from LIS discovery. section 4 
references the LIS discovery doc, but does not scope the applicability 
of URI schema types. Need to add text to qualify the requirements for a 
URI that is returned from LIS discovery.

Robert: Possible way forward to avoid blocking on LIS discovery.--base 
doc just says use an HTTP URI. Security consideration says only use an 
HTTP URI from a trusted source--maybe with an attached lawyer. Point 
_informationally_ to LIS discovery as a way that might help you do this.

EKR: Current version not insane. Still confused about the relation 
between this URI and the HTTPS binding.

Martin Thompson: Doesn't know what problem RjS wants to solve. (To 
remove LIS discovery as a normative dependency.) Martin thinks we can 
get LIS discovery done. Suggest leave the dependency until we decide 
there is a problem with LIS discovery.

Conclusion: Defer issue discussion to list


Brief presentation of several issues, no discussion.

Issue: Specific range for frequency of location requests. Currently 
"several minutes" Propose change to >2 and <10 minutes

Martin: Several minutes is okay for now, we can specify later. Can make 
recommendations for by-ref but not for by-val. If by-ref, we can make a 
concrete recommendation. In US we keep state for 30 minutes for 
emergency calls. Recommend "at least 30 min".

*** Conclusion: Change to "at least 30 minutes." Be more explicit that 
this is the time after which a by-ref URI expires. Take details to list.

Issue: both get and post. Get rid of get.

*** conclusion: remove Get

Issue: Use of 3704 to avoid IP addr spoofing. Do we need this? Propose 
to remove bullet 2 in section 9.3.

*** Conclusion: remove bullet 2.

Next steps: Update doc, version 11 expected to be ready for publication. 
Need's a re-review from EKR.

Cullen: Tim said he was okay with the direction.


40m    lis-discovery (Martin Thomson)
         http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery-04.txt

Open Issue not on slides:

DNS issues, defer to end.

ISSUE: URI Scheme. Option to have a "held" scheme. Proposal to use 
HTTP/HTTPS URIs only. LCP URI must be a product of discovery. Discovery 
provides necessary context to determine the URI purpose. Text to this 
effect in the draft.

Hannes: We've gotten contradictory advice from apps area on this. Wants 
to express to apps area to please offer consistent advice.

Cullen (individual) - supports proposal. Either approach could 
work--moving forward is the important thing.

Ted: +1

Richard: His resistance to this approach is less strong than before. 
Given robert's suggested text about being careful about the URIs you 
use, this is okay.

Randall Gellens: Slide does not list any advantages for the HTTP/HTTPS 
approach. Advantage is that you don't have to mint a new URI scheme. 
(Randall: But URI minting is on special for rest of year :-)   )

Issue: General DNS use. If DHCP does not give you the information you 
need, there's some tricks to get to a domain name. If that doesn't work, 
there's a DNS NAPTR procedure to try to get to a domain name.

Brian: Why is there a need for more than one mechanism? Isn't DHCP enough?

Martin: A lot of people cannot pass this info through to end devices via 
DHCP. Example, DLS networks where box is configured via PPP or statically.

Martin: Before discussing DNS, are their concerns with DHCP parts?

Robert - DHCP is okay in general. Got some security advice to also 
include a finger print for LIS server in the DHCP data. Martin is not 
sure how that would be useful. Needs more discussion.

Martin: Comments on DNS have indicated what is in the draft won't work. 
Hannes proposed removing DNS parts. Unfortunately there would be 
networks where discovery would not be possible.

Option: REmove DNS from this draft--document that there would be 
situations where no discovery would be possible.

Hannes: Suggests re-looking at  a mechanism that we discarded 
previously. (e.g. IP anycast.)

Chair question: Is there a requirement in this doc for devices with 
static IP configuration to be able to discover the LIS.

Brian: Yes, but that would be via static configuration of the LIS.

Martin: Is anyone not comfortable progressing without the DNS parts.

Mary: Agrees. We need to avoid wiggle-words here. This is close enough 
for basic functionality.

Question: Were there comments that the DNS approach technically wouldn't 
work, or was it just impractical?

Peter (Koch?): DNSSEC would not due what the draft assumed. Also, idea 
of "being in a domain" is flawed. DNS publishes info about a domain, but 
not to a particular target audience. Reverse mapping is risky.

*** suggested Conclusion: Probably will remove DNS, but need to take to 
list and confirm with absent stakeholders.

Richard: Thinks there might be something salvageable in the DNS 
mechanisms. Will take to list.

Robert: We could always work on DNS mechanisms in the future.

EKR: Jabber room comment is concerned about partial solution.

*** Conlusion: Need to take to list.


05m    civic-address-recommendations (Alex Mayrhofer)
 
http://tools.ietf.org/html/draft-ietf-geopriv-civic-address-recommendations-00.txt

This is now a WG item. Just one recent review (Martin Thomson )

Intended as a "cook book" for mapping civic addresses into pidf-lo. 
Options for elements that can be mapped unambiguously. Guidelines for 
elements that don't directly map. Define which elements must be used, 
can be ommitted, or must not be used in a country.


Example mapping for Austria.

Questions: Is this useful? Can we recruit people to do mappings for 
other countries?

Brian: Great doc--need to incent people to provide other example 
mappings. ***Brian will create one for US, based on NENA specs.***

Issue: What do we do with country examples?

Hannes: Work with [missed] to do this for all European countries.

Hannes: Document lacks motivation on why this is important for emergency 
services case. That is the case with the most precise requirements. 
Document could be shorter. Hannes will post a couple of questions on the 
Austria example to list.

Martin: Doc is useful, how can we get it published? Author: It's hard to 
get anyone in an official capacity to "acknowledge" this and give 
feedback. Open question about whether the country examples are 
"normative" or "informative".

Robert: We anticipated WGLC on this shortly after publication. WGLC 
expected in December time frame.

Brian: Do we want 300 RFCs, one for each country? Maybe a registry? 
Suggests a registry that allows multiple entries per country to get 
around question about who is authoritative for a given country. 
(probably expert review required.)

Suggestion to create template for country considerations. Maybe use the 
austria example as a template.

Cullen (AD) - Cullen does not expect problems with creating a registry.


05m    status check on loc-filters (Brian Rosen)
         http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-03.txt

Presented status. Review comments (from Martin) listed in slides.

Issue: Generalized "change in value" filter mechanism. Brian thinks this 
is a good idea, but cannot commit to doing it. If someone else wants to 
do it, Brian will be happy to use it.

Martin: Location delta format needs generalization (marking _why_ you 
got a notification), and should be removed from this draft. Generalize 
to be generally useful for SIP/SIMPLE. Brian: Willing to use a 
generalized mechanism if it exists, but doesn't want to take it out of 
this doc until there is something to reference.

Martin: Will discuss this in issue.

Next steps: Rev with 4661 changes, comment changes.




05m    status check on lo-sec/3963 update (Richard Barnes)
         http://tools.ietf.org/html/draft-barnes-geopriv-lo-sec-03.txt
         (Note: this draft has not been updated since before Dublin)

*** bashed out of agenda due to schedule constraints. ***


20m    discuss cross-area feedback on identifiers (Ted Hardie)
 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00192.html
 
http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-extensions-07.txt

*** not discussed, out of time, principle not in room. ***


20m    3rd party access to location information (Jon Peterson)
                This will be the next steps in making progress on 
discussing if/how we facilitate 3rd party access to location information.

No draft. Slides presented. Trying to determine if geopriv should take 
this on.

Use cases:

-- Endpoint lacks capability to acquire or publish location to the service.

-- Access network policy prohibits giving location to endpoint, but will 
give it to third party services.


  Example architecture shows a network service that queries LIS on 
behalf of endpoint.

[Steve, from a phone company] - could not do this unless the endpoint 
can explicitly express consent to allow this.

James: This is fine for location of non-IP devices. Concern with ability 
of target not to know their location was revealed. What if location 
service is not a trusted agent? (JFP assumes it must be a trusted agent. 
Must be clear that there is a rule maker.)

Martin: We must deal with these cases or become irrelevant.

Eric Brunner-Williams: USE case: tracking chip in service animal, no UI.

Matt Levinsky: People will do this--we need to describe how to do this 
safely.

Ted: Is there a change here from 3693? Questions of how rule maker 
interacts with presence service. How does it create an identifier that 
can be referenced by seeker? What are the security/privacy implications?

Mark [Lisner?]: Held-07 removes all requirements and motivation for 3rd 
party.

Hannes: Some emergency services cases involve people planning to use 3rd 
party access, at least for transition periods. These are not just 
academic use cases.

Discussion generally in favor of working on this.

Randy: The presence server and the LIS may have different rule sets.

Alissa Cooper - There may be cases where the target does not want to 
manage their location privacy, through lack of knowledge, et.

Mark Lisner - If we really care about the rule maker, we need more 
guidance on how to push policy to xcap service, etc.

[out of time...]

Ted: Many cases, the target will _not_ be the rulemaker.




------------------------------------------------------------
GEOPRIV - IETF73 - Tuesday 0900-1130

10m	Administrivia/Status
Richard Barnes welcomed as new co-chair.
Mary Barnes asked people to read her draft ????, so that she can provide
feedback to WiMAX people.

Preference expressed for doing lbyr-requirements WGLC after Thanksgiving
rather than before.
Dhcp-lbyr was posted to list, basically done, some comments (impact to
be worked out, but more philosophical). Near end of life cycle, so pay
attention to it.

Richard reported on liaison with W3C, and liaison statement is being
prepared along with other chairs. Get in touch if you want more
information or wish to help.

Announcement of discussion in SIMPLE later in week on location in
presence.

40m	Finalize any outstanding conversations on sip-lo-retransmission
(Jon Peterson)
	
http://tools.ietf.org/html/draft-ietf-geopriv-sip-lo-retransmission-01.t
xt
Keith: asked for clarification on parameter - Jon thinks it is header
parameter, but we are only giving guidance to SIP as to possible
meanings - up to SIP. With header appearing without Geolocation header,
you can express something you can't express with parameter to
Geolocation header.

Ted: So can express policy even though don't have a location (a
downstream entity could add it).

James: Difference in writing style between James and Jon, and James
would have expressed it differently. Jon: don't want to give examples,
just principles.

James: I can express every piece of semantic needed as header
parameters.

Ted: I agree with statement as currently expressed, although an
alternative would be to allow an empty Geolocation header. So it is
important to have a syntax in here that we agree would work, and this
can be passed to SIP for them to see whether it is acceptable or whether
they need to find an alternative but equivalent syntax. Need to give a
clear message to SIP so that SIP can do its work, but not in terms of
syntax, just in terms of what we need to happen.

Brian: We have got all we need to get out of this, and should not hold
things up by prolonging this discussion.

James: Don't want to hold it up, but wants to leave meeting with clear
interpretation.

Hum to say if draft is clear enough as is. Quite a few for - didn't hear
any against.

Keith: Wants clarification that there is a requirement to be able to
send from user indication about policy. Jon: Not necessarily the user,
but could be the rule-maker.

Mary: Support Keith, needs to be well-cooked.

Chair: Point of draft is to capture semantics, and hum indicated we have
captured the semantics.

James: At this point I am satisfied.

Jon: Concerning point about B2BUAs, we can't compel B2BUAs to do
anything, but we can explain the design trade-offs.

Brian: Not satisfied that the text gives advice. In fact I think we
could get rid of it. Prepared to send text if we decide to keep it. Jon,
yes, please send text.

James: Confused about a suggestion that this is about gateways. Jon:
This is purely about B2BUAs.

Ted: Reason text is there is that you need to understand the GEOPRIV
principles as a whole. Rip it out if it isn't helpful, but I think it is
helpful and doesn't harm to keep it in. So before ripping it out we
should understand the consequences, i.e., that we think B2BUAs don't
need to understand GEOPRIV.

Hadriel: Agree with statement that you should tell them what to do, even
mandate it. Of course, they won't always do it, but then we can't be
responsible for operation of the service. Jon: Does what we have in
there persuade? Hadriel: Yes.

Jon: In any case, this is not the document that designers will design to
- that is for SIP to produce.

Robert: Explained where gateway came from, i.e., from point of view of
endpoint and e2e operation, which might cross a PSTN hop. So if there is
merit in having a recommendation on B2BUAs, it should also address that
case (B2B gateways).

Mary: Real text has to be done in SIP.

Ted: Need to stay in this document, even though SIP may or may not do
work on B2BUAs in future.

Cullen (as AD): Wants to balance Mary's concern against getting the
document done quickly. So do whatever we need to do to get this document
out quickly and across to SIP.

Jon: Agree that primary purpose of document is more the first rather
than the second bullet (B2BUAs).

James: Can work with Brian on existing 3.6, but not sure how can apply
it to the PSTN hop case.

Ted: You are ahead of where we are. Need a hum on the second point.

Chair: Wait for line.

Keith: You basically want a B2BUA to behave as a proxy. As soon as you
get to an intervening PSTN hop you are outside the scope of SIP.

James: Confused, because I am the person has to put text into conveyance
draft, particularly in case of a gateway. Comment on B2BUAs has been
taken out.

Jon: Can we determine whether room supports making this kind of
recommendation.

James: Want to know whether this group wants to recommend to SIP that in
conveyance it should address this scenario.

Chair. I will call the hum. Does WG believe that this document should
contain a consensus opinion from this WG on how B2BUAs should behave.
Conclusive in favour.
Second hum: Does current document capture WG consensus on how B2BUAS
should behave w.r.t. location retransmission. No response either way.
Ted: Should instead ask whether advice we are giving is the right
advice.
Keith: Wants to get rid of "note" from B2BUA text. Also pointed out that
SIP WG can implement in its protocol only about 30% of the
recommendation, and rest would need to be done elsewhere.
Chair: Is the spirit of the recommendation right, i.e., text basically
on right track
Hum if you believe we are on right track and just need to wordsmith.
Nobody hummed against.

Ted: If I receive the text this week you will get an updated draft this
week.

Chair: What is urgency for WGLC on this.

Ted: Very urgent.

Rosen: Conveyance is waiting on this, lets get both documents out and
then phonebcp.


05m	Update/discussion on http-location-delivery (Mary Barnes)
	
http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-10.
txt
Primary open issue on URI schema for URI from LIS discovery. Will add
text to qualify requirements.

Chair: Want a feeling from group whether essence of document (i.e. use
an HTTP URI) is correct. Explained boundary between this document and
LIS-discovery, so that this document can proceed withouth waiting for
LIS-discovery.

Mary: LIS-discovery has been a requirement all along, and thought we
could cover this.

EKR: Didn't catch question: Mary: Will get to that.

Martin: Don't know what problem you will solve by proposing this change.
Don't think this is a contentious part of draft and shouldn't hold it
up.

Hannes: Originally proposed to split discovery, so just ?????

Mary: Let's defer to list.

Additional comments on slides.

Martin: On point 3, nothing much we can do to specify a concrete number.
Given that it is for lbyr, can make a concrete recommendation. 30
minutes. Agreed 30 minutes would be added.

Randy: But slide says frequency, discussion was on lifetime.

Martin: The two are related.

Randy: Too frequent can involve overloading of resources.

Mary: Need more specific text.

Will be taken to list.

Bullet 2 in 9.3 will be removed.

Mary will update the document once mailing list discussion concludes.
Should be ready for progressing.


40m	lis-discovery (Martin Thomson)
	
http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery-04.txt
Open issue not on slides is with DNS methods. Cover this last.

Issue of whether to have HELD URI scheme or just have HTTP/HTTPS URIs.
If you get one of these HELD URIs, it would be through the discovery
process. Proposal is to stick to what is in draft (HTTP/HTTPS).

Hannes: Made one decision in ECRIT (having involved Apps Area), so
concerned about making a different decision in GEOPRIV.

Cullen (as individual). Support Martin's proposal. Any could work, and
had slight preference for a new scheme, in interest of progress let's
stick to what we have.

Ted: Let's just get on with it.

Richard: Arguments are captured accurately, but given the text the
present proposal is OK.

Randy: Concerned that we don't say why the chosen option is better.

Ted: It is simply that you don't have to invent a new URI scheme.

Martin: The DNS part will be contentious.

Chair: Who read it, and who studied it in detail - sufficient.

Biran: Good idea to have a DNS option, but what is the nature of the
domain that has a LIS and doesn't provide the DHCP option, so why do we
need other options.

Martin: No DHCP.

Brian: Will read it again.

Martin: Not hearing any concerns with DHCP aspects, so before we move
on, are there any?

Robert: No, although suggestion of containing fingerprint of server for
security purposes.

Martin: Don't see what this buys you. Discuss later.

Martin: Moving on to DNS, Hannes has proposed this be removed, but this
would leave networks where you can't discover the LIS. If remove from
this draft (and do elsewhere), would people be comfortable?

Hannes: I had proposed that we look at some other mechanism, so advance
this just with DHCP option, and then look at other options.

Chair: Meta question: Do we have a requirement for this document to
cover devices with static IP configured to discover LIS.

Brian: Yes, but can statically configure LIS.

Martin: Are we comfortable with taking this document without the DNS
component?

Mary: This would be a good thing.

Mark: IMO the DNS solution is more theoretical than practical.

Peter: Didn't understand what it wanted from DNSSEC - feared it wanted
something that DNSSEC won't give you. Also the concept of "being in a
domain" is somewhat flawed. DNS is not a service discovery mechanism,
but there are other things that do this. Reverse mapping risky. Too much
heuristic that you can't really rely on.

Martin: That is a pretty good summary of problems we have. Fine with
feedback. Suggestion of Hannes to cut the DNS stuff seems to be the way
to go.

Chair: This needs to be confirmed on list.

Richard: There may be something that can be salvaged, but will discuss
on list.

Chair: If we drop it, does this preclude picking up another option in
future?

Answer seems to be no.




05m	civic-address-recommendations (Alex Mayrhofer)
	
http://tools.ietf.org/html/draft-ietf-geopriv-civic-address-recommendati
ons-00.txt
Brian: Really likes the document, and need to recruit people from other
countries to add their input. Will help a lot of implementers. I will
create one from US from NENA's specs.

Alex: So what do we do if we end up with 100s of these?

Hannes: Will work with ENA for European countries. I have many detailed
comments, but lacks a clear articulation of why precise information is
needed for emergency services reasons. Perhaps document could be
shorter. Will post to list.

Martin: What do we need to do to get this document published? It is very
useful. Hannes suggestion good. What else of substance to do before
WGLC.

Alex: Would appreciate feedback on recommendations.

Chair: We anticipated that once we got charter item we would WGLC it, so
December/January timeframe.

Brian: To ADs: Do we want 300 RFCs for 300 countries? Perhaps a registry
is the way to go, with Expert Review required. Document would keep
Austria, but only as an example. Also ought to allow multiple entries
for countries where we don't get an authoritative input.

Richard: Registry is a good idea.

Roger Marshal. Document excellent. Not clear where "consideration" was
already in this document, or needs to be in the 300 country-specific
documents or registry entries.

Cullen as AD: Don't see a problem with registry.


05m	status check on loc-filters (Brian Rosen)
	
http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-03.txt
Martin: May need work on location delta format. Should reference another
draft.
Brian: Won't take it out until there is something to reference.


05m	status check on lo-sec/3963 update (Richard Barnes)
	
http://tools.ietf.org/html/draft-barnes-geopriv-lo-sec-03.txt
		(Note: this draft has not been updated since before
Dublin)
Removed from agenda.

20m	discuss cross-area feedback on identifiers (Ted Hardie)
	
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00192.html
	
http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-exte
nsions-07.txt

20m	3rd party access to location information (Jon Peterson)
                This will be the next steps in making progress on
discussing if/how we facilitate 3rd party access
                 to location information. Please be familiar with at
least the following inputs:
	
http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-exte
nsions-07.txt
	
http://tools.ietf.org/html/draft-linsner-geopriv-obo-00.txt
Wants a discussion whether these third party considerations are within
scope of the WG.
Steve Norreys: We as operator would have a problem doing this unless the
phone user has given his permission.
Jon: There has to be a way for the user to say go ahead and get that.
Steve: If this caveat is put in, this would be useful. Could even be
third party services, not part of operator's network, but permission is
all important.
James: Location seeker can ask PS where a device is, but ???? Didn't
follow the argument here????

Martin: Concerns with previous iterations of document distract from
things, but from the picture on the slide it is very clear, we do have
the discussion there (and people should say if we don't). Dealing with
this problem is relevant, and if we don't people will do this anyway.

????: Interested in UI-limited devices.

????: People are going to deploy things like in the picture, if we don't
tell them how to respect privacy they will do it wrong.

Ted: We have 2 aspects: how rule-maker interacts with PS, and that it
needs to be aware of identifier. Need an update of 3693 to include the
privacy indicator.

Richard: This is some discussion in draft update of the document.

Mark: held-identity-o7 removes all mention of 3rd party. Need to
identify motivation and requirement.

Jon: Do you object to what we have here?

Mark: I object to removing the rule-maker.

Hannes: This is something real and picture captures it well. Document
needs to be stronger on capturing notion of target and rule-maker.

Martin: Will take Mark's suggestion as feedback.

Jon: Anyone objects to addressing this use case? Nobody objected.

Martin: Rule mechanism can come from a number of places, e.g., contract,
subpoena, web page.

Randy: Other configurations possible, e.g., presence service need not be
LS.

James: ????

Alice: Expressed as if this is against the target's wishes, but could be
cases where the target wants this. Jon: Agreed.

Mark: ????

Jon: We can fix what is in the document.

Martin: Alice's concern can be fixed by saying target is the rule-maker.






------------------------------------------------------------
GEOPRIV - IETF73 – Tuesday, 11/18/2008, 0900-1130 (Central)

10m	Administrivia/Status

Robert: Announced Richard Barnes as co-chair to Geopriv

Ted: Request to switch order of last two items on agenda
(no chair decision)

Mary: wrote a draft on periodic location updates based on requirements 
from WiMAX Forum

(Robert: status on agenda items)

James: No mention of DHCP-LbyR

Robert: by mistake left off the agenda…

James: Still need to work out some details with Martin

Richard:  Status update on [see Richard]

Martin Thomson: request to get people to read a SIMPLE draft, which will 
send link to geopriv link.

---next

40m	Finalize any outstanding conversations on sip-lo-retransmission (Jon 
Peterson)
		http://tools.ietf.org/html/draft-ietf-geopriv-sip-lo-retransmission-01.txt

Jon Peterson:  (see slides) Differentiated (tried) syntax from semantics

Comments?

Brian: like to discuss B2BUA language

Keith Drage: is this recommending header or parameter?

Jon: changed to recommending neither – just explaining merits of each.

Ted: (paints an example)

James Polk: …believes that the geolocation header is named… maybe a 
difference in writing… I like to include examples…

Jon: We pulled back on how concrete we want this to be.

James: I believe that language that includes, “for instance…” is better. 
  Do you agree with that approach?

Jon: I don’t agree with that… the difference in the semantics is… [missed]

Ted: I agree that you could modify the semantics of the geolocation 
header to be a <null>, then insert later – and get where you are.

Ted: I believer it is important to have some example syntax here, 
because at that point it is testable.

Ted: Reality is that we need to do this for SIP to do its work – believe 
that we SIP can’t unless we include the syntax here.

Brian: I think we’ve got all we need to get out of this. Don’t want to 
hold the document up.

James: agree that I don’t want to hold it up, but want to leave this 
mtg. with a crystal clear understanding that this is what SIP needs.

Robert:  Would you like to take a hum now?

Robert: (takes a hum) do you think that the present draft is clear 
enough – that the syntax is exemplary, not prescriptive.

Some (low audible) Hums in favor, 0 hums against.

Keith: to clarify, this draft says that it is possible to send a message 
without location…

Jon:

Mary: I agree with Keith that this topic has to be well-baked before it 
moves over to SIP.

Jon:

Robert: Point of the draft is capture the semantic

***
Second bullet:
Jon: B2BUA language softened

Brian: will send text bcz I don’t think you’ve provided enough here

Brian: am ok with getting rid of it

Jon: would agree with getting rid of it

James: I thought I’d come up with a decent way to address <section 3.6>… 
recounting conversation with Robert – “… it is about gateways…”

James: Is this about gateways?

Jon: This is about B2BUA’s

Ted: (recounting …talking to Brian – you’re writing to someone who is 
not listening… <B2BUA’s>) trying to help others and ourselves to 
understand if geopriv principles to a B2BUA, then what would we see…

…since they’re not listening, if we rip it out, then be aware…

Hadriel Kaplan: Think you should have much stronger language directed to 
the B2BUAs – regardless of whether they listen.  Thou SHALL, you MUST… 
unless you know better.

Jon: what we try to do is “persuade”. Do you think what we have persuades?

Hadriel:

Jon: Again, what we’re trying to do is to tell a story…

Hadriel:

Robert: Want to explain where the gateway remark came from.  Original 
language in the draft came from acting as an endpoint in SIP

… scenario where from SIP into the PSTN – where it may be possible to 
carry location, but not policy – in cases like that, we need to specify

Mary: If want to pull this out and place into another draft, then ok, 
but don’t want to see it in this document.

Ted: Shouldn’t leave it out in expectation of something else to come. 
Leaving it out seem (to me) doesn’t seem to get to where we need to go.

Jon:

Cullen: (speaking w/AD hat on) another draft, not a quick work, so makes 
this critical for SIP, SIPPING, bcz of this, would rather see this done 
quickly – published soon.  Not saying what the answer should be but that 
we need to get this document done soon.

Jon: agree, and say that the B2BUA language may help – may not, but 
would say that… taking to areas more perilous…

Jon: So where are we here?

James: good with the Hum at the top

James: don’t know what text Brian will send it… don’t know what I’ll 
have to do in SIP conveyance

Ted: I think you’re further than where we currently are…

Ted: I think we need a hum

Ted: Suggest a Hum around text in section 3.6… Are we satisfied as a wg 
with this language Yes | No?

Robert: wait….

Jon: would like to take a hum whether this doc is the right place to 
discuss

<murmur – this is about SIP, right?>

Kieth:  Basically, you’re stating that you want a B2BUA to follow the 
rules for a Proxy…

Jon: no, not…

Kieth: black box -

Jon: white box…

<murmur, comments – crowd confused>

James: I’m confused… I think 3.6 has text implications, if B2BUA is an 
endpoint, or is a

Jon: are the five letters B2BUA in there now?

James: I think it is…

Jon: ill-advised…

Jon: I think we’ve gotten off-track…

Jon: does geopriv support making this kind of recommendation…?

James: Does this wg want to recommend to SIP, in conveyance

Jon: Let’s not think about telling SIP what to do…

<loud shouts>

Robert: I’m going to propose that we stop…

Robert: does the wg believe should contain consensus opinion from this 
group on how B2BUAs should behave

Hum loud in favor
Hum lesser against

Robert: Hum2)  do you think current document correctly addresses how 
location conveyance should be done.

(hum not taken)

James:

Ted: like to go ahead with your hum, but ask if this is the right advice?

Kieth: like to get rid of the “note”… you can agree here, but SIP can 
only implement only about 30% of that reqmnt.

Robert: what we’d like to get a read on…
Do you believe the spirit of this document, that the text is on the 
right tract, or that we haven’t captured it yet.

Hum – “are we on the right track, just need to wordsmith?”
Hums (medium level, yes)

Hum – “do you think we’re on the wrong track and need a separate doc?”
Hum – no hum heard.

Ted: if text can be received this week – I can turn this out this week.

Robert: how fast do we need to move?

Ted: (mentioned headache… need to get it done)

Brian: conveyance is first to me, so then we can get phonebcp, etc.

Jon: the power is yours, Mr. Rosen.

---next

Mary Barnes – HELD

09 changes

status

Primary open issue – URI schema for URI from LIS Discovery

Robert: suggestion to fix – just say “use an HTTP URI” here.  Security 
would say you only take a HTTP URI that you get (along with a lawyer)… 
and that this document says nothing about LIS Discovery.

Mary: LIS Discovery has been there as a requirement from day one.

EKR: HTTPS binding may have two different uses, GET and POST

Martin Thomson: listening to Robert’s suggestion, don’t know what 
problem your trying to solve…

Mary: essentially LIS Discovery…

Martin: only part that is controversial is DNS

Hannes: Suggested splitting out from early on…

Mary: let’s go on – HELD: Additional comments (slide)
1 - locationURI schema
2 - are both HTTPS and HTTP allowed?
3 – “several minutes” is not very specific

Martin: don’t think there is anything else we can say…

Mary: General, not specific to by-value

Martin: if a URI, then we can make this

Martin: in the States, (mobile), we keep state for at least 30 minutes.

Randall Gellens: not sure what is being discussed, since the slide says 
period, but we’re talking about how long a location request is good for.

Mary: or… the expiration of the locationURI

Martin: are related…, not orthogonal

Randy:

Mary: taking this to the list.

4. Get rid of the GET? Leave only the POST? Good with you EKR?

5. Use of 3704 for preventing IP Address Spoofing.

Cullen: not sure what this is…

Richard Barnes: we get this through return-routability, so would be ok 
with removing this (bullet 2 from section 9.3)

Hannes: agree with removal of this…

Way Forward – HELD (slide)

Request EKR to re-review

Mary: …Ted left the room – would like to ask…

Cullen: Ted mentioned as he was leaving room that he was ok with this.

---next

Martin Thomas

Martin: more has come up – so will add-lib

Martin: DNS not included on slides – will have to discuss with Hannes…

URI scheme (slide)

Option: a held:uri (slide)

You only have one of these URIs if you get it through a <   > server 
(perhaps with a lawyer attached, as Ted said…)

Martin: will suggest keeping only HTTP, HTTPS uris only

Hannes: <background with Applications guys> we agreed in Ecrit and it 
was fine, now in Geopriv and its not fine.

Martin: it’s been a confusing issue, suggest a reset based on proposed.

Cullen: I think I support your proposal, vague recounting some history

Ted: I agree with Cullen, that inventing a new URI was ok, but is fine 
to drop it here.

Richard:  I’m going to disagree some with Ted and Cullen, but if you are 
careful with URIs used, think it may be ok.

Martin: in dropping the GET, this will make it better,

Randall: you list an advantage for doing one… but don’t say why the 
other is not good. Just curious.

Ted: image the slide said (at bottom)… and you don’t have to go to the 
trouble of creating a new URI scheme.

Martin: brief talk of way forward for this draft.  Unfortunately, some 
stakeholders, not in the room –

Robert: Who read this draft in study mode? (editor’s count, ~8-10)

Robert: DHCP option – will require conversations with those DHCP folks…

Robert: Who in the room is ready to comment on these 3 options.

Brian: Why is there a need for more than one mechanism?

Martin: down the road is RFC 3875 – DHCP won’t work for some people. 
Namely, the DSL folks, gets configuration through PPP, or manual 
configuration.

Brian: If I’m not mistaken… all mechanisms imply that you started with 
something you get from DHCP…

<no – many from room>

(Brian: will read it again)

Martin:  doesn’t seem to be a lot of push-back on the DHCP mechanism for 
this draft.

Robert:

EKR: why don’t you think this will be useful?

Martin: not sure what it’s going to buy you.

Robert:

Martin: let’s move on to the DNS mechanism

Martin: some believe this won’t work, Hannes believes that this 
mechanism be removed.

Robert: …may have to try again…

Martin: may need to remove from this draft – stating that this draft 
will not address all cases.

Hannes: not only suggested removing, but also discussed IPAnycast

Robert: Does <missed the question>

Brian: document says static config is ok

Martin: Is anyone against this moving forward

Mary: close enough for

Marc Linsner: a question, though agree that DNS approach is more 
theoretic, was there list traffic

Peter _________: talked about DNSsec, talked about the gaps… DNS is used 
to publish information about a domain, not for a <   >.  Nervous about 
seeing DNS used as a generic discovery mechanism.  Other this was seeing 
Reverse DNS mapping – can have multiple returned – risky.

Too much heuristic that you can’t rely on – might not go to a reliable 
result.

Martin: I think that’s a pretty good summary of the problems we have 
with DNS discovery.

Richard: what’s the result of that Martin…

Martin: I think Hannes suggestion is to cut is good.  Need to check with 
the list (others) to see what the impacts might be.

Richard: There may be some salvageable pieces.  Useful to tease out what 
the assumption are.

Robert: just to be sure that we don’t get into a place where we don’t 
want to be – does this removal preclude some future method exclusion?

<from room> no.

EKR: Uncomfortable with…

Martin: Yes, he’s one that I wanted to check in with…

Robert:

Martin: We’ll knock this out on the list.

---next

Alex Mayrhofer (presenter)

Status (slide)

Motivation (slide)

Comments:

Brian: really like this document – need to recruit from other counties. 
  Going to help a lot of implementers – I will contribute one from the US

Alex: If, in an ideal case we get hundreds, where/how should we store them?

Hannes: will try to get EENA to create for each county in the EU.  Need 
one for each.  Document doesn’t say why – especially for emergency case.

Martin: want to know how we can get this doc published?

Brian: do we want 300 rfc’s? need a registry

Richard:

Roger: suggestion to extricate the Austrian example into a 
“consideration” document, which could serve as the basis of a document 
template – one that each of 300 could be built on.

Cullen: agree – don’t see a problem with creating a registry (don’t want 
300 milestones…)

---next

Brian Rosen (presenter)

Loc-filters draft

Comments based on review of Martin Thomson (slide)

Change filter – will wait for text from somebody

Martin: another area which could need work – location delta concept.

Martin: would like to see some things removed, such as the 
“notification” of which area you’ve moved into – would be useful as a 
general mechanism (in SIMPLE).

Brian: perfectly acceptable once there is some external document that 
contains the mechanism that this document can point to.

Martin: will continue to discuss – and will advertise to SIMPLE that 
this is a topic.

---next

Robert: do we have <…>?  Jon can we start on the 3rd party issues?

Jon Peterson (presenter) – Third-party Access to Location

Jon: want to get a sense of whether this is one of the things this wg 
wants to take on?

Jon: goes back to the origination of this wg – the scenario where an 
access network knows your location and you want a service to acquire it 
directly. (slide)

Jon: slide – how it might work (w/an identifier)

Steve Norrys: As a large, monolithic service company, we would be one 
that would *not* want this *unless* the user agreed to have it.

Jon: yes, qualify – relationship btwn black phone ane the presence 
server.  So, based on that… Steve, would this be something a company 
like yours would be interested in?

Steve: yes, only if expressed permission by the user.

James Polk: If you go way back (many moons) – if you remember, I used 
the example of a “lamp” who couldn’t communicate over IP but could be 
located.

Jon: don’t recall the analogy…

James: Concern in the old “on-behalf-of”, the rule-maker…

Jon: in the old document, it was less clear, this document here make it 
clear.

Martin: going back to old documents, where not clear, doesn’t help. 
This document does make it clear.  Dealing with problem is necessary, 
and by ignoring it – risk becoming irrelevant ourselves.

Martin: …I’m happy with that.

_________: chip in my dog’s ear doesn’t have a UI in it.  Therefore I 
think there is a use case where doing this for devices where UI in not 
present is worthwhile.

Matt Lepinsky:

Ted: Feelin a bit dim, but looked at 3693 – seems to be the same diagram 
in ascii.  Is there a difference?

Jon: main difference is that we have a LIS – rather than an LG.

Ted:

Richard:

Marc:  wanted to note that HELD iedentity extensions -07 removes all 
text as to why we’re doing 3rd party – need to identify motivation and 
requirements.

Jon: do you object to this picture Marc?

Marc: I object to remove the Rule Maker out of the picture

Jon: okay, we all object to that.

Hannes: Maybe this needs to be updated to take into account rule maker – 
and also acknowledge contracts in place today that equate manual rule 
maker agreements.

Martin: …you can already see this rule maker concept in “I accept” web 
signup pages.

Randall:  Have some fundamental disagreements with how entities are 
nameas in the diagram = reaching back to presence architecture may be 
more than one LS

Jon:

James:

Elizabeth ______: It seems almost like the discussion is “against the 
target’s wishes”, but for me, might this also be in reverse, “do it for 
the target – based on it’s wishes”.

Jon:

Marc:  When the rule maker has been brought into the document, doesn’t 
believe that it’s been sincere – for example…

Jon: <missed>, but I am thrilled that we all seem to agree that…

Martin: I think we can resolve this by saying the target = rule-maker. 
<missed>

Robert: We’re out of time.

Ted: qualified… taking discussion to the list

Robert: this has been a good conversation, believe that we have a 
document that Martin and Richard can take to the list to continue the 
discussion…

---End of meeting

---agenda (as posted)

10m	Administrivia/Status

05m	Update/discussion on http-location-delivery (Mary Barnes)
	 
http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-10.txt

40m	lis-discovery (Martin Thomson)
		http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery-04.txt

05m	civic-address-recommendations (Alex Mayrhofer)
	 
http://tools.ietf.org/html/draft-ietf-geopriv-civic-address-recommendations-00.txt

05m	status check on loc-filters (Brian Rosen)
		http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-03.txt

05m	status check on lo-sec/3963 update (Richard Barnes)
		http://tools.ietf.org/html/draft-barnes-geopriv-lo-sec-03.txt
		(Note: this draft has not been updated since before Dublin)

20m	discuss cross-area feedback on identifiers (Ted Hardie)
		http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00192.html
	 
http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-extensions-07.txt

20m	3rd party access to location information (Jon Peterson)
                This will be the next steps in making progress on 
discussing if/how we facilitate 3rd party access
                 to location information. Please be familiar with at 
least the following inputs:
		 
http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-extensions-07.txt
		  http://tools.ietf.org/html/draft-linsner-geopriv-obo-00.txt

Also, please be familiar with the following recently updated drafts to 
facilitate short conversations
during the Administrivia/Status section (and hallway discussions):
http://tools.ietf.org/html/draft-ietf-geopriv-lbyr-requirements-04.txt
http://tools.ietf.org/html/draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt



_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv