[Geopriv] Draft minutes: GEOPRIV at IETF69

Hi folks -

Here's a first pass at minutes for yesterday's meeting.
Please send in comments/corrections ASAP.

Thanks!

RjS
--------

MINUTES - GEOPRIV - IETF69
Wednesday July 25, 2007 - 0900-1130

Summary:

== pidf-lo-profile ==

* The group is not yet finished with pidf-lo-profile.
* It is intended to clarify 4119 and address omissions.
* We need to look at RFC4479 (the presence data model) and decide if  
this document needs to take it into account
* The document applies to the use of PIDF-LO in general, including,  
but not limited to, the case where applications need to specify one  
location with minimal ambiguity.

== HTTP Location Delivery ==
* Lisa Dusseault needs concrete use cases to help advise on the  
response time question which is still an open issue
* The room hummed strongly indicating they were happy with the path  
this document is on
== Location conveyance in SIP and its interaction with PIDF-LO ==
* The room confirmed the following two points by strong hum
     - The group wants a way to say to the network "If you need  
location to route this request, and you need this particular location  
object to do that, fail the request instead".
     - The group wants to leave providing the tool to the using  
protocols rather than change 4119.
* The room hummed in support of having the SIP location conveyance  
document remain silent on the length of subscriptions associated with  
a location by reference.
* When asked if geopriv should provide constraints about event  
packages used for location, the room expressed
     - dereferencing may be done with presence
     - dereferencing may be done with other event packages
     - geopriv's recommendations focus on using presence

== lbyr requirements ==
* The room hummed in favor of adopting draft-marshall-geopriv-lbyr- 
requirements-02 as a working group item

== lbyr dereferencing mechanism ==
* James and Hannes will merge their drafts and consider the using/ 
transport question looking into the feedback Ted's original strawman  
attracted. There were several comments indicating using was more  
likely to be the correct path.

== DHCP lbyr ==
* There is interest in this work (and the group still wants to  
address the problem), but the group is not ready to adopt this draft  
as the starting point for a mechanism at this time.
   - Lisa and Ted raise architectural concerns with the ability to  
carry arbitrary URIs

== Location Security Requirements ==
* There is concern that the scope of the system has changed since the  
last threat model was published and that it is time for a new analysis
   - Several participants expressed interest. They will work with  
Richard to revise the draft
     and continue to pursue the topic on list.

== Other points ==

* Attendees in the room expressed willingness to use conference calls  
or other more interactive tools to resolve some of the more  
contentions issues as they come up.

------ start of notes by Spencer Dawkins------
Notes by: Spencer Dawkins <spencer@mcsr-labs.org>

     * 15m status/administrivia

No agenda bashing happened.

Hannes - policy document was revised while in queue, went back to the  
WG and back into the queue, saw this is pending a review by Tim Polk,  
included IANA comments, small update, hasn't moved since February.  
RADIUS Geopriv also confused me - what does "expert review" mean? I  
thought I addressed all the IETF Last Call Comments.

Cullen - off the top of my head, wasn't policy in editor wait for a  
while? RADIUS draft had very negative comments from RADIUS chair,  
waiting for that to get resolved. Policy document is still waiting to  
look at most recent changes, RADIUS draft is waiting for RADIUS chair  
to confirm changes...

Hannes - two options - version in February reflected WGLC comments, I  
added IANA comments so IESG wouldn't see them again.

Robert - slow movement over last couple of months, is slow, won't  
stay that slow.

WG document that fell out of the queue - does group think this is  
important and needs to be pursued? (binary lci)

James - this document originated because of misunderstandings about  
RFC 3825, we made requested changes, chair left status in "waiting  
for new draft" and was unresponsive.

Robert scanned for who read draft/was aware of it - small number of  
people, about 7, only 3 expressing an opinion about keeping it active.

James - people are implementing, will chase their comments. Concern  
is that we are still talking about error - significant digits is fine.

James Polk - did lots of work on PIDF-LO profile, Robert is looking  
for feedback on what this document was supposed to be.

Hannes - not clear whether this draft covers data model or not.

James - PIDF-LO looked useful, but there are about 6-7 places where  
you can insert different kinds of location, didn't seem helpful or  
obvious about what is going on. This got pushed off into IGC draft.  
Basic rules are two years old, didn't change during that period.  
Concern with post-LC comments is that we can put in users, devices,  
etc, really sweet but don't know how to choose between multiple  
locations in various places in the object. Could describe general  
case plus profile, could separate functions in separate documents.  
Open to suggestions, but this is getting in the way of being useful.

Jon - some stuff in GML I totally didn't understand, we were just  
saying that there was other stuff we could also do. This doesn't  
replace anything in RFC 4119, isn't a 4119bis document.

Robert - not just applications that talk about one location, right?

Ted Hardie - two different questions - intended not to be 4119bis,  
it's omissions from 4119, is in no sense possible to read this and  
not 4119, may update but does not obsolete. Second question is "is  
there anything else editors need to do?" Does presence model require  
changes to this document, or a new document? Don't think we have had  
that conversation yet, and we haven't read this enough to decide today.

Rohan - any reason to recommend that people DON'T follow the  
recommendations in this document? Think "no" - argues for "UPDATES  
4119".

Robert - takeaway is that we aren't quite done yet with this  
document. Do we need to say anything in addition? Please read 4119  
and PIDF-LO document now, and check whether PIDF-LO is done.

     * 45m http-location-delivery - draft-ietf-geopriv-http-location- 
delivery-01

Mary Barnes presenting - 00 version taken from Winterbottom draft. 01  
draft added terms and tried to make them consistent with other  
documents.

(see Mary's presentation for details)

Hannes - terminology stuff has been haunting us for a while, document  
has redefinitions of other terms, this is a problem.

Mary agrees.

Suggestion to remove duplicate definitions.

Slide 7:

Hannes - try to differentiate between IAP and ISP in other documents.  
Why use new terms? Should be explicitly.

James - L2- LCP becomes our glossary of terms? Is this the right  
place to do it, or in separate terminology document?

Slide 8:

Brian Rosen - still don't think Response time is useful, but don't  
want to be an obstructionist.

Richard - has a lot of impacts on timers and relationships.

Mary thought these timers were independent.

Cullen - would wireless technologies end up with really inaccurate  
location for emergency calls with default Response Time of 0?

Robert - who understands this question? Who is paying attention?

Ted - compromise is workable, won't fall on my sword, but discussion  
on list has shown disagreements and these are showing up in other  
arguments as well. Need to come to agreement in order to avoid  
continued fights.

Lisa - as APP technical advisor to the group - this really isn't  
compatible with HTTP architecture, could make suggestions if you  
provided more information about the use cases I could be more helpful.

(We will follow up with Barbara) - Wireless network could return a  
quick value plus a reference for a more accurate value later.

James Polk - would there be a response delay in returning a URI?  Why  
is there a response time issue?

Rohan - some applications want to block on a socket and wait for  
accurate information, others don't want to wait. Return location type  
and response time = 0.

Mary - don't have total consensus yet.

Slide 9:

James - a lot of discussion happened on list since we made these  
slides. We're thinking "just request civic" in case there are  
differences between postal and jurisdictional civic addresses.

James - how do you know whether your response is postal or  
jurisdictional?

Slide 11:

Canada will use both jurisdictional and postal forms of civic.

Slide 12:

Hannes - refers to underlying question about what this reference  
refers to. Could ask for value AND reference. Clarify kind of  
location you want. Later document provides this information. If you  
always request both types, that could be useful.

Richard - need to clarify which dereferencing protocol is being used?

James - not necessarily restricted to one mechanism. Hope we can  
discuss this during dereferencing presentations.

Slide 13:

Robert - asked onlist whether people were happy with 00 as starting  
point, got no negative responsive. Still happy? Hums in the room  
indicate so.

Rohan - looking at schema of revised civic, would be nice to add  
attribute that distinguishes between jurisdictional or civic.

Brian - bad idea, can't know what to do based on one attribute.

James - what about civic locations that are neither postal nor  
jurisdictional. LIS document has been around for a while, without  
much discussion. Document needs to move.

Hannes - if someone thinks this is useful, they should just write a  
document and explain why.

Brian - from list - if there is a country that uses A fields in a  
different way than the post office uses them, we would need to know  
that, but don't think there are any countries that use A fields in a  
different way.

Miguel??? - currently trying to figure out where to put the number in  
PIDF-LO

Hannes - larger problem - DHCP discovery isn't controversial, but DNS  
discovery is. If we don't get proper input from other WGs, this will  
not be good.

     * 30m location conveyance in SIP and its interaction with PIDF- 
LO - draft-ietf-sip-location-conveyance-08

Robert - questions from SIP community as background....

James Polk presenting...

Robert checked (via humm) on whether he understood and correctly  
stated some background...

Expires=0?

Hannes - what does the reference actually point to? this is  
underspecified.

Robert - non-zero Expires need to be defined - what does reference mean?

Hannes - what is default type of location?

Jon - confused - SIP presence has been specified pretty exhaustively,  
not ambiguous.

Hannes - problem is that user isn't using this, often a proxy is.

Brian Rosen - conveying URI, if it's a presence URI, you get to do  
what you do with presence URIs.

Robert - Henning said the same thing (offline before the meeting)

James Polk - you can track me as long as you have a presence URI,  
right? That was a big deal (required polling).

Hannes - two ways to do this - we have seen use cases where access  
network adds the reference, haven't discussed how that works.

James Polk - document is silent on this issue, we're talking about  
what's in 09 draft.

James - don't think the document should say anything on this point.

Ted - don't think this document should say anything about this, it's  
the wrong document and probably the wrong working group.

Robert - after hum, this is not a geopriv-specific question and  
should be discussed for using protocols.

Ted - question I asked for was "does this document remain silent?"  
<pleasant rant followed>

Robert  - is "silent" saying that the document says "not our problem"?

Ted - levels of indirection are OK, I guess. Speaking for me  
personally, if you are silent you get the semantics of the type of  
URI you are using. If you want to say "not our problem", that's  
better than some alternatives.

Rohan - premature to decide where something goes when we haven't  
decided what that "something" is. Lots of opinions, need to get  
motivations out in the open to make this decision.

Robert - understand, still calling Ted's question for sense of the  
room. (Sense of the room is that "document shouldn't say anything")

Does the Using Protocol only send the target's location?

Rohan - is this in a SIP INVITE, or for any REQUEST?

James Polk - goes back to "can't lie".

Rohan - can set my city, etc. on my UAC.

James Polk - can we have more than one location object with more than  
one identity?

Rohan - but you can send any location you like, including "lies".

Jon - never been a big fan of expressing multiple locations in a SIP  
message.

Robert -  do we want to rule out telling what we know about other  
entities?

Jon - nothing is going to tell you what a URI actually represents.

Robert - value versus reference is a separate question?

James Polk - I have only one identity in each object, but I may have  
multiple objects.

Hannes - location refers to entity and may have multiple PIDF-LOs

Brian Rosen - generally in agreement, would like advice that sending  
multiple PIDF-LOs can be confusing.

James Polk - document says that.

Rohan - having problems with terminology, and problems are  
interfering with my ability to follow the discussion. Is location  
always about the request URI?

Robert - "when you send a request, you're saying where something is  
from?" Can we talk about location of "something else" - is that the  
question?

James Polk - people have been saying that PIDF-LO could only have  
request URI location, right?

ERROR topic -

Is granular error feedback a good idea?

James - what about geodetic problem? Interested in a use case.

James Polk - "didn't include city", UAC has some information about  
what the error actually was - need XML error body.

James - this information is going to be big enough that an XML body  
makes sense.

Robert (after hum) - will take this off the list

     * 20m dereferencing lbyr

Robert - will enforce the 20 minute limit.

Do we only pres?  with what event package?

Rohan - location is a first-class object, can be addressed directly.

-------------------------- (scribe break)

Hannes - don't need to say anything about this in the SIP conveyance  
document

Ted - multiple LLs in SIP (was previous discussion)

Ted - "may dereferencing be done with presence" - answer in room is  
probably "yes" -

Does anyone object? No one jumped up...

Ted - if there are multiple ways, is the current presence event  
package Rohan put forward one of the ways? Don't see any reason for  
this document to limit to pres.

Brian Rosen - discussion we've had multiple times - something beside  
SIP-pres - just don't get Rohan's proposal and don't want to hold up  
this document - not MUST, but CAN

Rohan - don't think "no other event package"  is relevant

Jon - working group should not provide mechanisms that are not  
conformant to the working group charter

     * lbyr requirements -  draft-marshall-geopriv-lbyr-requirements-02

Roger Marshall presenting...

Hannes has provided comments on 02, Roger agrees with all of those  
comments.

James - question about what we call this depends on whether reference  
is anything BUT a URI - no? suggest we call this a "location URI".

Brian - please look at requirements in conveyance draft for conflicts  
- don't think there are any but need to be sure.

James - requirements are requirements. If some LCPs can't do a  
requirement, note that and move on.

Richard Barnes (but I missed his comment)

James - about status of this document - held has dependencies on this  
document and others are coming down the road. I'd like to see  
document move into WG.

Robert - enough people have read the document to call the question  
(after show of hands) - any objections? none noted by hum/show of hands

     * held dereference BCP - draft-winterbottom-geopriv-held-deref- 
bcp-01 and draft-tschofenig-geopriv-http-using-protocol-00

James presenting

Brian Rosen - think this is a using protocol, and don't think that's  
a problem.

Hannes - philisophical argument - are we talking about security  
discussions in the document?

Brian Rosen - privacy discussion, don't think anything else has to  
happen

Hannes - we don't do location-based routing with this stuff.

James proposal is to merge these drafts.

Ted - think merger would be value, but when I put out a strawman  
proposal about this it went up in flames. Using protocol on top of  
HTTP caused serious heartburn - need HTTP as a using protocol. HTTP  
as transport punts too much important stuff to an unnamed using  
protocol. Keep as individual draft for one more round, consider  
whether we need to switch to HTTP as a using protocol.

     * 10m DHCP lbyr - draft-polk-geopriv-dhcp-lbyr-uri-option-01

James was brutally flamed 5 hours after submission - this was a humm  
in Prague?  don't understand.

Only issue was "must specify complete architecture before this can  
move forward"  - but 3825 and 4776 didn't do this, either.

James - discussion was on access network, this is an entirely  
different can of worms. "Need to have an architecture described"  
because I can't see the context.

Hannes - do you plan to include text about validity duration?  
Something that tells both sides how long to store it.

James Polk - in the message, or only in the specification?

Lisa - please provide restrictions about types of URIs, so many  
types, could be useless or even harmful?

Richard - could use same syntax to point someone to a HELD server.

James Polk - but that's not what I'm trying to do.

Marc Lisner - same mechanism has been used for other drafts, if we  
can figure out "unique", we can figure out "unique URIs". - why do we  
need a timer on this when we haven't had timers on previous  
mechanisms? This document should say the same thing as other  
documents - not a solution for mobile devices.

Cullen as individual - this is an instantaneous thing, other  
mechanisms have implicit "zero lifetime", this mechanism could have a  
non-zero lifetime.

James - if this is intended to be used in WiFi, need to say more  
about this.

Robert - people are interested, but not enough interest (after a hum)  
to adopt as WG draft. James Polk will rev as individual.

Ted - following Lisa' point - there are general URI mechanisms that  
aren't appropriate for every type of URI. As an architectural point,  
though, it might be useful to decide whether using a *single* option  
for every using protocol makes sense, rather than individual  
options.  Radius and HELD are pretty different, and a client  
requesting this might request one over the other or only be able to  
use one. Architectural questions should be decided first.

     * 30m location security requirements - draft-barnes-geopriv-lo- 
sec-00

Richard Barnes presenting.

Design team had concerns about security and how objects should be  
protected. We've been doing threats followed by countermeasures, this  
document just covers threats.

Integrity and Authenticity:

EKR - explicit assumption that this is a three-party system. Who  
doesn't trust who?

Hannes - we've had a number of cases come up where people are  
concerned about information being manipulated in an emergency  
situation. Are existing mechanisms sufficient?

EKR - hard to believe that 911 centers don't roll if they can't  
verify a signature.

Hannes - this is the first step in coming to that conclusion.

James - people haven't been exposed to the idea that if you can't  
trust location information, you can't even apply policy.

Jon - what do you see as relationship between this document and 3693?  
Didn't have list concept at all when we did the work previously.

EKR - would be nice to have text explaining why the usual situation  
(ignore what you don't trust) doesn't apply here.

Robert - what's the goal? Adding to 3694?

Richard - scope of working group has expanded since 3693, expansion  
of scope needs to be added.

Robert - out of time, hearing that there is interest in the document,  
but additional work is appropriate. Please work with Richard and fill  
that in.

James - problem is that it's not clear what the 3693 model extensions  
really are right now.

Hannes - useful because it captures a contentious issue, don't want  
to replay 1000 e-mails again.

Robert - in attempt to avoid threads of 1000 e-mails, would like to  
have more interactive forum between meetings? Teleconf? Text plus  
Audio? Please consider building your messages more carefully, not  
replying tit-for-tat.

James - more agenda time? Or an interim meeting?

------ end of notes by Spencer Dawkins------

------ start of notes by Marc Linsner ------
GeoPriv - IETF 69 - Notes

No agenda bashing

Hannes - question about the policy draft - why is it in and out of  
the queue.  Hannes included IANA comments, why hasn't this moved  
since Feb.?

Cullen - policy draft was in revised for a while, policy draft now  
waiting on ADs, radius has serious problem with radius wg.

James W. - revised civic-lo has been in this state since April, is  
that normal?

Cullen - policy draft status been since May, not Feb.

Hannes - I updated the IANA comments.....????????

Robert - Drafts have been moving slowly, but going to better going  
forward.

Spencer - Names please?

Robert - What's up with binary-lci draft?  It's expired....

John S. - this draft was originated due to confusion on 3825, chair  
asked for this draft, revisions were made, draft accepted as wg item,  
chair let the draft drop.

Robert - 7 people read it, 3 want it to move forward

James W. - people have done implementations and expressed there is  
still confusion....draft still talks about location error and we  
don't want location error in this draft.

Robert - pidf-lo profile - questions on the slides

Hannes - problems intrepreting 4119, this draft still causes confusion

James W. - pidf-lo profile provides better intrepretation of  
understanding the pidf.  Intent is to provide guidance as to how to a  
device will handle multiple locations within a pidf-lo.
long discussion about how to intrepret pidf-lo using the profiles set  
out intially, against the concept of service, device, person

Jon P. - Does this ask to stop doing what 4119 says?  I hope not.   
What this draft states is these are additional things that can be  
done with pidf-lo

Ted H. - this is intended to be a profile draft that supplements  
4119, it doesn't replace 4119. Is there anything else we need to do  
with the recent presence data model changes?

Rohan M. - this is not intended to obsolete 4119.  Is there anything  
we should recommend people to do that is outside this profile?

Ted H. - 4119 does not require the use of this profile

Robert - suggests that the wg is not done with this draft.....please  
read 4479 and pidf-lo draft....

James W.- I want this ready to go for the Vancouver meeting

Moving to the agenda presentations

Mary Barnes - presenting HELD 00 (see slides)
changes from Winterbottom draft

Hannes - terminolgy changes required to maintain same across several  
drafts.

Hannes - the terms Internet Access provider and Access Network  
provider needs defined to be the same across all drafts

James W. - Should this L7-LCP be the main terminology document for  
all other docs?  Or do we need a master terminology document.

Brian R. - I still don't think the responsetime parameter is useful,  
but I won't stand in the way of this going forward.

Richard B. - I see a problem with having these timers having a  
conflict with transport timers.

Ted H. - If the underlying protocol timers won't wait for the upper  
layers

Cullen - I want people to think about this, will the suggested  
default of zero be fast enough for an emerg. call in a wireless use  
case.

Robert - Who understands the question Cullen just asked?

Ted H. - The list discussion on the list has exposed serious  
disagreements and we need to resolve.

Lisa - A technical advisor, this proposal does have http  
ramifications, so I need the understand the use cases.

Barbara from the jabber - Wireless networks also return l by r

Barbara from the jabber - clarification to her comment, wireless  
network provide both quick and accurate.

James P. - Will there be a delay in returning a location uri?  Why?   
Why is there a response time issue?

Barbara from the jabber - clarified James question

Rohan M. - there are use cases where someone will ask for the most  
accurate, I don't want a uri

James P. - how do you request such?

Rohan M. - use the request type and response timers..........

Mary - location type discussion.....

James W. - there has been more recent discussion on list about  
removing the postal and jurisdictional types...my recommend is to  
eliminate the location types in the request

Richard B. - this location type problem extends way further than just  
HELD

Rohan - from the jabber room - Canada will use both jurisdictional  
and postal

Hannes - there is a larger question about how the reference  
works....there is a question about requesting a reference for civic  
or request civic when requesting the reference

James W. - are you happy that your use case can be addressed with the  
context mgmt style????

Richard B. - there will be a need to specify what type of uri is  
returned with the possible various de-ref protocols

James W. - HELD returns a uri 'set'

Richard B. - this need clear clarification

Robert took a hum whether people are happy with this draft at this  
time...

Rohan M. - I was looking the schema and we should add a tag  
distinguishing between jurisdicational and postal

Brian R. - This is a bad idea, a single lo can handle both

James W. - If you add this tag, it must be optional.

James W. - a different topic....the lis discovery document has been  
around a while, held is dependant on this doc and this needs to move.

Hannes - a comment, please don't add something to the revised civic,  
it's in a very late stage.

Brian R. - If there is a country that represents a jurisdictional and/ 
or postal using the existing tags different for each type, this needs  
to be known.

Ted H. - per the jabber - an optional tag would be useful

??? - from Austria - (ed note, didn't understand this comment)

Hannes - the lis discovery is a larger problem, dns discovery is  
bigger than this context, needs more discussion/review

Moving to James P. preso on sip-location-conveyance

Robert - the sip chairs launched questions into geopriv - 2 issues -  
do we want to reject a call that is routed based on the location  
object where retran. = no?  Do we want a using protocol header to  
express the ability to route the call?

Hannes - What does the uri point to?  what is the object?  (ed  
note....lost track of discussion)

Jon P. - the presence info is totally unambigous....this mechanism  
will not change the semantics.....

James P. - the target controls what is sent...

Hannes - NO, this

Jon P. - no, we must use the sematics of presence

Brian R. - if we convey a presence uri, you use the sematics assoc.  
with presence, nothing more, nothing less

Robert - Henning agrees with Brian

James P. - this is not the understanding of the wg over the last  
several years.

Hannes - take this example, there can be a presence uri where the  
rulemaker has control, but if the uri is inject by a proxy, how does  
this work?

James W. - There is enough extensibility with the uri mechanism to  
allow semantics..

Ted H. - I suggest this document remain silent on this point.

Robert asked for hum....consensus was that this document will remain  
silent on this document.

Hannes - We need a document to address this....

(ed note....lots of discussion...not captured .... sorry)

Robert asked for a hum - who thinks this doc should remain silent on  
this issue....rough consensus is to remain silent.

James asked about which lo can this protocol retransmit

Rohan - can I lie about my location?

Jon P. - (ed note...distractions, don't understand)

Jon P. - the rules are within the pidf-lo, no where else

Brian - I agree

Hannes - the doc should be silent

Jon P. - the semantics for the pidf-lo are in the pidf document and  
does not need to be in outside that doc.

Brian - I agree with Jon

Rohan - I am difficulting with the terminology.   Does sip only send  
location assoc. with the request uri?

James P. - some believe that sip can only forward the location of the  
uac in the request uri

James W. - how do you handle errors on the geo case?

James P. - I don't know

Hannes - We must figure out how to handle granular for geo

James W. - maybe we need an xml solution?  How about the LoST error

Robert - next topic has a time limit......only 20 minutes

James P. - what event package should this doc state ???

Rohan - location is a first class that we need to address  
appropriately....like other things, calendar, etc. location is a  
first class object

Rohan - I purpose an event package that we use for location  
only....it's a first class data, it needs an event package of it's own

Jon P. - my comments are pertained to the geopriv charter.  this wg  
decided years ago, due to the desired attributes, that pidf-lo is the  
wg mechanism, we don't want to repeat these semantics in a new event  
package

Ted - from the jabber room -

Hannes - I agree, this has no bearing on this document..

(ed note....left room...)

Roger Marshall presentation.

James W. - do we believe a LbyR will be anything but a URI...we  
should call it a locationURI

Brian R. - I would ask that you review the req. in conveyance for  
conflicts that they agree with this draft

James W. - reqs. are reqs. - I don't think there are reqs. targeted  
at a particular conveyance type

Richard B. - the req should be dereferencable by the client?  this  
shouldn't be part of this draft

(from the jabber) this draft should apply to all

James W. - HELD has dependencies on this draft, I want this to move  
forward...

Robert - who has read this document?

Robert - who believes this document as a wg item.....consensus is  
that this doc is now a wg doc.

James W. preso on a http dereference...

Brian R. - the entity that is de-ref is the watcher.....the location  
server must take into account all the privacy rules.... this is a  
using protocol

Hannes - I want to know what you have to write into the document to  
be declared a using protocol vs. a transport protocol

Ted - I believe a valuable to merge the 2 proposals....my conclusion  
to my earlier strawman is that there are many in the wg is that http  
must be a using protocol

James W. - location uri are much more complex than location bv  
value....this needs sematics

Hannes - I think this needs synced with the semantics in the other  
location uri drafts...

(ed note - discussion about dhcp being for the wireless use case)   
(notes missing)

Robert - can this document be used for a wg item.  consensus is to  
wait....

(from the jabber) g.caron hummed for pursuing this draft....

Richard Barnes preso.....

Eric R. - this seems reasonable....there is an explicit assumption  
this is a 3 party system.

Hannes - people believe that location data can be manipulated.....

Eric R. - I don't believe that a psap will treat a location the same  
whether the location is signed or not

Hannes - ?

James W. - People don't understand the enormity of the problem

Jon P. - we need a way to secure location information  - how does  
this compare with 3694???  - this document should update that 3693/4

Eric - there is an explicit assumption there is an adversarial  
relationship between the target and watcher

James P. - what is your goal with this draft???  are you adding to  
3693/4???

Robert - we are out of time....there is interest in the doc, get with  
Rich. revise and bring it back to the list

James W. - I have a concern that 3693 does not cover the use  
cases....the threat model has increased

Hannes - this document is useful...

Robert - as we are working forward, trying to avoid death by email, I  
would like to use conference call, text chats, etc. to help.

James W. - we need more agenda time
------ end of notes by Marc Linsner ------

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