Summary (prepared by Richard Barnes):
1. Chairs' Introduction
The chairs reviewed the status of several WG documents. Hannes
Tschofenig noted that there is only one outstanding issue with loc-
filters, namely whether to add a "speed greater than" condition.
Martin Thomson noted that lis-discovery is ready to go to the IESG
2. RFC 3825 Update
draft-ietf-geopriv-rfc3825bis
Bernard Aboba presented an update on this document. Several issues
have been closed, leaving three remaining after the next, upcoming
revision.
3. GEOPRIV Architecture
draft-ietf-geopriv-arch
Alissa Cooper presented an update on this document. The most recent
edition added some clarifications and simplifications. Ms. Cooper
proposed that the document be last-called.
4. HELD Identity Extensions
draft-ietf-geopriv-held-identity-extensions
Martin Thomson presented an update on this document. The primary open
issues are around how authentication and authorization are applied.
Cullen Jennings expressed concern that current text on authenticating
ownership of identifiers is not implementable. The authors agreed to
add more explanatory text, and where good authentication techniques
cannot be clearly described, to restrict usage to limited cases with
pre-configured authorization relationships.
5. Indoor Location
draft-stanley-geopriv-int-ext
draft-polk-geopriv-int-relative-in-tlv
draft-rosen-geopriv-pidf-interior
draft-thomson-geopriv-indoor-location
Dorothy Stanley presented an overview of the first three documents.
Martin Thomson and Brian Rosen expressed reservations about the syntax
that these drafts employ, in particular the overloading of the civic
address structure. Martin Thomson presented an overview of his
document. The two teams agreed to work together to come up with a
unified strategy.
6. Geocoding
draft-george-geopriv-address-translation
Robins George presented an overview of this document. Several
participants had read the draft and agreed that the general topic is
worth working on, but doubted whether HELD was the appropriate
protocol. At least one more revision will be necessary before the
draft can be considered for adoption.
7. Policy URIs
draft-barnes-geopriv-policy-uri
Richard Barnes presented an overview of this document. Hannes
Tschofenig and Martin Thomson observed that indirect-publish
mechanisms might be more suitable.
Raw notes from John Elwell and Stephen McCann follow:
------------------------------------------------------------
Status update:
On held-identity-extensions:
Remote: Are we going to do a generalised mechanism?
Martin: ????
Martin: lis-discovery - about ready.
draft-ietf-geopriv-rfc3825bis (Bernard Aboba)
Chair: Does issues list include discussion on list in last 24 hours
Bernard: Indicated which issues were still open.
Martin: Document in good shape apart from 3 issues listed on slide.
draft-ietf-geopriv-arch (Alissa Cooper)
In opinion of Alissa, about ready for last call.
About 6 people had read the document.
HELD Identity Extensions update and discussion of open issues
draft-ietf-geopriv-held-identity-extensions (Martin Thompson)
Issue#19: Martin also added that latest discussions lead to
restrictions in which something can be considered LCP. No discussion.
Issue#27: No discussion.
Open issue on solution scope: Martin's proposal is that the questions
raised on the list are valid questions but do not need to be addressed
in this document, so out of scope.
Richard: OK with first, but 2nd and 3rd should have something said to
address privacy concerns.
Cullen: On 2nd and 3rd, which document DOES address these?
Richard: Can't have a general solution for these, but at least can
give guidance.
Cullen: Need proper normative references to get past IESG.
Martin: We have such references, will make document a bit longer if we
put them in. But problem is, that for one network they may work fine,
but not for the next one.
Jon: Sense is correct (not wrong), but unsure that it is complete or
helpful (but that was a month ago). Doesn't understand how IMSI would
work, for example.
Martin: IMSI easier than MAC address from my perspective.
Cullen: Others won't understand it - write it down.
Jon: Different classes of problem, for IMSI, MAC address etc.
Jabber: Gave reference.
Martin: Don't see much value in an LCP request with identifier.
Cullen: We need to say how privacy will work, although there won't be
a single answer. From the present document I fail to see the answers.
Same issue will come up from people who haven't previously read the
document, as it progresses.
Martin: Disallow request if you don't have policy for dealing with
that request.
Cullen: Not implementable.
Richard: One case is MAC address look-up from IP address:
Cullen: This doesn't make sense.
Martin: That is correct, supplying MAC address as identifier is not
required.
Richard: So doesn't do any harm.
Cullen: So it might be misused for something else.
Martin: Explained one case.
Jon: If that is the only case, I understand.
Martin: Explained another case.
Brian: Can give you a use case for LCP - involves a gateway. Could
turn it into third party, but really it is first party.
Jon: This should be treated as third party.
Martin: No problem covering this in the document.
Jon: Need text that says that for third party case must be some pre-
association, and must express scope of what requests can be made.
Cullen: Write down how it should work in practice. We have been
complaining about W3C ignoring all privacy, so we should ourselves
address the issue.
Martin: When hosts can get their own location, this will gradually go
away.
Jon: This is a MUST use case, not just a MUST implement.
Jabber: ????
Alissa: Make it clear in document which of these are third party cases.
Jon: Fundamental distinction between these cases - different approach,
different security.
Martin: Want people to attach to network and get location information
they need, and often IP address is sufficient.
Jon: Don't' all become 3rd party, they are different.
Alissa: They need to be explained.
Martin: Will deal with non-LCP cases in more detail.
Chair: If we can solve by reference, that would be fine.
Open issue that we need examples:
No agreement on list on what principles, but perhaps moot in view of
previous discussion.
Open issue on alphabet soup:
Martin: Not a lot I can do about it, but we are in a lot better state
than some other documents.
Cullen: I agree with people complaining about this.
No other issues raised from floor.
Indoor location proposals
draft-stanley-geopriv-int-ext
draft-polk-geopriv-int-relative-in-tlv (Dorothy Stanley)
Proposal also make use of draft-rosen-geopriv-pidf-interior.
Jabber: Why just these shapes?
Dorothy: Others can be added - just not in this draft.
Roger Marshall: Good to have a discreet reference that is more precise
than "front door".
Dorothy: Looking to provide civic-only parameters.
Brian: Like the draft. Generally the approach is correct, but two
problems. "Front door" is a string that does not exist on the drawing.
Would like to see something like "Door" with value "Front". Add
another level or two of INT. Second issue is syntax for offset. Would
prefer a more structured syntax.
Dorothy: On first point, this was considered, but went this way to
provide additional flexibility for deployment. Otherwise we would need
to know all entity types (door, elevator, etc.) that one might want to
use, and this is very difficult.
Richard: Agree with Brian we should say what it is and what it is
called.
Dorothy: Yes, but issue of how to specify and what degree of
flexibility we want to give.
Marc: IEEE has adopted PIDF-LO and is using it in its protocols, so to
say stop now and go in a different direction puts us in a bad light.
Doesn't see problem with having a tag.
Martin: I have already outlined my concerns, and whilst the use cases
need to be solved, this is a bad way of doing it. A recipient could be
mislead by this. Need to get the data model right first - then fix the
other things.
Roger: ????
Dorothy: In response to Jabber question, not trying to add complexity,
just extending what already exists.
Martin: The bunch of elements being introduced masks the complexity
that is there. An entity not understanding the extension would get the
wrong location.
Dorothy: But would still have building address.
Martin: Each element added to a civic address should make the location
more specific. Adding these elements should make the location
specific, but they are intentionally making it less specific (e.g., a
circle) and shifting the location.
Hannes: No way of negotiating what you understand.
Dorothy: In the context of using this, would know the protocols being
used.
Hannes: Could use proprietary.
Concerning comparison with draft-thomson-geopriv-indoor-location
Martin: I don't think it is a good characterisation of my draft.
draft-thomson-geopriv-indoor-location (Martin Thompson)
Addresses same problem, but solution takes into account some things
Martin considers important.
Cullen: How to get from WGS84 is better attached as metadata to the
map, but otherwise like the way this is going.
Martin: Will need to discuss on list.
Dorothy's final slide:
Dorothy: Solutions have different characteristics, and different
applications have different needs. So recommendation is to progress
both.
Martin: Would be willing to work on a merged proposal, if we get the
data model right. Don't want to see two competing solutions.
Dorothy: Happy to discuss this off-line, but there are some important
considerations that need to be kept. Requirements don't appear to be
quite the same.
Martin: Let's discuss requirements and see which ones survive.
Jabber (James): Any location must have significance outside the local
environment.
Martin: Either need a way of specifying both an outside location and
an inside location, or need to know which the application needs.
Marc: There is running code on some of this IEEE stuff.
Richard: Should not have impact on XML - should be able to translate
to/from binary.
Brian: Would like to see one solution for this, if possible.
draft-george-geopriv-address-translation (Robins George)
4 people have read the draft.
Martin: Like the idea in general. Location requests in HELD is
probably not the right way. Either use a different request in HELD, or
better, another protocol. Perhaps need to work with James Polk. Also
there are discussions on putting something similar into LoST.
Roger: Good idea to have a standard for this. Seconds Martin's
comments on use of HELD - perhaps a light LoST usage.
Martin: Last discussion said don't geocode in LoST.
Brian: Martin has said most I want to say. Would not accept the draft
as is.
Chair: More discussion on list.
draft-barnes-geopriv-policy-uri (Richard Barnes)
Open question: Does the general approach make sense
Is the extension syntax correct (DHCP and HELD)?
Do we need also to provide general policy (outside of LbyR)
What is the right protocol for installing policy.
Hannes: There was a previous proposal that people found too
complicated. That was placed with something simpler in the HELD
context document. Advocates a different model. How would server
authenticate.
Richard: Not all the things the policy server can provide require
authentication.
Hannes: ????
Martin: Not too against it, but don't see it as deployable.
Jon: Needs to be some glue for some cases. Want to make sure all those
cases are covered.
Martin: Third bullet on open issues slide - thinks this is bad - sees
no need to do. To Jon's questions, need to work on it.
Other business:
Martin: People should perhaps get involved with indirect publish,
which seems to have relevance to these discussions, although it is
only a straw man.
Meeting closed.
------------------------------------------------------------
alissa and Richard Barnes chairing
see slides (geopriv agenda)
Draft status
------------
Brian Rosen's document is now in last call. There don't appear to be
any mailing list comments on this.
HELD on the RFC editors queue
-loc-filters: Resolving WGLC issues
Hannes: regarding the filter document, there was an issue about
reachng a certain speed (e.g. 100km/h). You can currently say that
the speed is above this limit. A custom filter is possibly required.
Richard; Please can we take this discussion to the list
Martin: I'm not sure why we want to use this.
A: Tempreture changes, why not add greater than, less than.
Martin: -lis-discovery, this has now finished last call and I've
updated it with comments. I think its ready for IESG evaluation
Cullen: Yes, I agree
w3C liaison
-----------
We sent some comments to w3C regarding their liaison.
It looks as though no further action is required.
RFC 3825bis - Bernard Aboba (remotely)
---------------------------
Added some next sections as shown in the slides.
Martin: Does these updates include the list discussion during the last
48 hrs?
Bernard: Not entirely
Martin: If we can close off the 3 issues as shown, then I think the
document is good. Issue 4 is a bit of a concern.
Bernard: Yes, ok. There are some more possible change to this.
-arch-01 - Alissa Cooper
------------------------
Changes since 01.
Alissa thinks the document is ready for WG last call (WGLC).
Richard: How many people have read this document. About 9
HELD identity - Martin Thomson
------------------------------
Changes since 01
two primary issues have been raised: Issue #19 and Issue #27
There are some outstanding issues.
Richard: OK, that's fine for the 1st point. For the 2nd and 3rd (about
the security issues) I'm not sure.
Cullen: But which document addresses the 2nd and 3rd points?
Richard: Well, they would be use cases and have not been written down.
We'll not have any universal solution to these issues. We can produce
a set of requirements.
Cullen: We need normative text so we can actually implement this.
Alissa: There have been some ideas on the list, but are not in the
draft.
Jon Peterson: The text is ok, but I don't think it's complete. The
IMSI cases are difficult.
Martin: I don't think IMSI makes sense for LCP.
Cullen: So perhaps we should split out IMSI.
Martin: But IMSI is easier than using a MAC address. I can put in
another paragraph about this.
Jon: There are different classes of identifier, and perhaps these need
to be dealt with seperately. You have different sets of security
challenages for these classes. The IMSI does scare me (regarding the
ease of attack), as opposed to MAC address.
James Winterbottom (remotely). Something is already defined in a TS
31.xxx document (3GPP).
Martin: I don't see any point in having a LCP request which contains
an indentifier.
Cullen: But this group is supposed to only create functionality where
security is included. The document is missing this level of detail.
Martin: So, if a 3rd request comes in, without a policy identifer,
then we should ignore.
Richard: Your trying to authenticate the identifier againsts an IP
address, which is the LCP case.
Martin: So we don't need any identifer.
Cullen: But this draft will not be used for that type of
functionality. You must be able to secure this system.
Jon: Re: Emergency Service case: This is the only case where I can see
this draft working.
Brian (remotely): I agree that this is abig problem. You have a class
5 switch and need location for an ES. The identifier is a phone call.
The gateway will query it's location using its own telephone number.
The network will then assert the location against that number. The LIS
should know the range of numbers and therefore allow location to be
determined for that gateway. Therefore this is case where no IP
address is used.
Jon: I think this is still a 3rd party situation. It only works based
on a security pre-association.
Martin: ok, so I can put this in the document.
Jon: So you add some text which describes the 3rd party case and the
assumptoipn that there is a pre-SA between the individual and the LIS.
Martin: So, that's your policy.
Jon: Without a pre-SA, then this mechanism will not work.
James (remotely): NAI is used in WiMAX. Typically there is no mapping
of IP address to identifiers in a enterprise.
Alissa: I think you need to describe the use cases for the 3rd party
scenarios.
Jon: I think there are almost all 3rd party cases, but there may be a
couple of 1st party cases, where the security threat model is
different. IMSI is a long term identifier.
Alissa: Sure, but they all need to be explained.
Martin: Ok, I'll address the cases where LCP make sense.
Cullen: perhaps we could pull in the references to other SDOs which
have addressed the IMSI case.
Alphabet Soup comment
Cullen: This draft is quite heavy on the acronyms.
Martin: I agree but I'm not sure what I can do about it.
-int-ext & -int-relative-in-tlv - Dorothy Stanley
-------------------------------
There is also a draft rosen-pidf-interior, which has been covered in
this pressentation.
This work is partially in response to a liaison from IEEE 802.11,
asking for support of WLAN relative locations.
James Winterbottom: Why is ellipse not in the list?
Dorothy: I'm sure that it can be added at a later point. It's not in
the first draft.
Cullen: The IP manager policy issue is quite unique.
Richard: What is the difference between the private and the registered
int syntax.
Dorothy: It's just the way they are registerred.
Roger Marshall: It appears to be a subjective reference. Perhaps you
should use a wall.
Dorothy: Yes, you could use a WG system, with a lat/long.
Brian Rosen: This is very useful. But I have two problems:
1) the reference itself. Front door is a string which does not exist
on the buliding drawing itself. I would like the reference point to be
the civic address itself, then specify a "door" on the drawing itself.
This adds another level of INT.
2) the syntax of the offset, is defined as INTs. Normally we would
expect to see a normal piece of XML. This document tries to fit into
the PIDF-LO syntax and to fit within a TLV.
I think this is a poor way to define a new data strucuture. I think we
should define a new element instead and have a new mapping to TLVs.
Brian: With that I think it would be a really great draft.
Dorothy: Regarding the enumeration of the door, we'd then have to
enumerate all entities within the building, e.g. door, elevator, water
cooler etc. I think our scheme gives more flexibility.
Richard: But there needs to be a split syntax, say whay the entity is,
then what it's name is.
Dorothy: The problem is that the civic address is not enough to
provide the referece point.
Marc Lisner (remote): IEEE has adopted some of the PIDF-LO work and so
we're trying to re-use that syntax. Regarding the explicit reference,
I think this is a minor point. When it's mapped to the binary code.
Martin: Civic address can identity a reference point for you. I think
this is bad way to add a new item. The use cases are good. The binary
format is not well designed. It allows mis-understanding. I think we
need to get the data format correct, before we consider the binary
format (RFC 4476).
Roger: One different point would be to think of a virtual rectangle,
and then to define anchor points at the corners. Then suite 400
centroid would make sense. The rectangle would then cover any civic
location.
James Winterbottom (remotely): Why not define a new location type, as
opposed to Civic.
Dorothy: We're not looking to add a lot of new functionaluty. We just
want to extend what's there already.
Martin: But you've already added new elements. The extra extensions
can move the reference point and cause confusion.
Dorothy: But the civic address is still ok.
Martin: Every element you add to a civic address, just refines the
location. Adding these element should refine the civic address, not
move it somewhere else.
Hannes: When we added speed and velocity, work in GML helped us. This
is a similar problem. We then decided to not use the GML, as they were
not backward compatible. Another approach is to go for a propriatery
solution.
Comparison table (between -stanley and -thomson)
Martin: I was asked not to present, but I do have a presentation of my
draft ready
Alissa: Let's allow Dorothy to go through the comparison table, then
you can present.
Indoor Location - Martin Thomson
--------------------------------
Cullen: The transformation from WGS84 to the map is better attached as
meta-data to the map itself, as opposed to the location offset itself.
Otherwise, I do like the direction that this is going.
Recommendations slide - Dorothy Stanley
---------------------------------------
The two solutions are different.
recommendation is to progress both solutions
Martin: I think the two solutions are not too different and I think
it's a matter of getting the XML model right first. Then the binary
part will come afterwards. I think two RFCs is a bad idea.
Dorothy: Sure, but the binary representation is very important. We
should be able to sort this out offline.
James Winterbottom (remotely): How does a device obtain this location
from a LIS, as it should be able to do that.
Martin: Basically this is asking whether the location offset is
spceific to the location. Well, yes it is. It would not be useful in
another context. Perhaps we have to define an inner and an outer
offset (perhaps for emergency service use).
Alissa: But if you receive more detailed information, which you don't
understand; I think you can ignore it.
Marc (remotely): You wouldn't send all the offset information to a LIS
server. There is product and running code based on the earlier work.
Richard: But I don't think that will change the XML to binary conversion
Brain (remotely): I think we need 1 solution on this. I don't think
the compact biary requirement is not a bit issue. I think we should be
able to compromise quite easily.
Geodetic Datum to Civic address - Robins George
-----------------------------------------------
Alissa: how many people have read the draft: about 5
Martin: I'm not sure that this is right place to put it. I like the
concept. Geo-coding is quite useful, but location requests in HELD is
not the best place. Perhaps a new request or even a new protocol
should be created. Let's look at what people are using out there.
Discovery of geo services would also be usful. It could also go into
LoST. LoST needs an extension to provide this reverse look up
mechanism. Therefore the draft needs some more thought.
Roger: I like this document and its a good idea. In an emeregency
context, PSAPs don't have a exchange protocol to communicate with each
other. Something based on LoST is perhaps the way to go.
Robins: But I thought the WG said, don't geo-code in LoST
Martin: Yes, so perhaps another protocol needs to be found.
Brian (remotely): Yes, I agree, but this should be a new protocol. it
may have some good uses within NENA.
Richard: Ok, so please can we have some more discussion on the list.
-policy-url - Richard Barnes
----------------------------
LbyR (location by reference)
Hannes: In the intiial HELD submissions, there was some text about
policy. But how do you apply the policy. You need to authenticate and
then use the LIS itself. Even today, it is not solved correctly.
Within the DHCP document, James Polk wrote another mechanism to do
this. The HELD approach is still rather heavyweight.
Richard: You might want to upload some geographic information, which
does not contain any identity information.
Hannes: But many location service servers need some understanding of
identity. Not everyone has certificates? In addition, these policies
are quite complicated. There are some overlaps with the HELD policy
document, but it's still not clear.
Martin: I don't think this is deployable. I don't see why is it
required. You establish a policy in one place and then you don't worry
about the local access provider. Perhaps we just need the ability to
invalidate the refernce.
Jon Peterson: If I get a location and then give it to someone else,
then this may be appropraite.
Martin: You say, here's my policy. What happens when the IP address is
re-allocated to someone else. This can be a real mess. Regarding
JOn's question, can we fallback to location based authentication, but
I'm not sure.
===
AoB
---
Martin: Can I also have comments on the list about -immediate-publish,
which may have some relevance here.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
