Re: [Geopriv] Draft GEOPRIV notes for IETF 76

On the discussion of HELD identity, I thought I heard a more definitive
consensus on LCP use.  What I thought I heard was no LCP use in this
version.  I understood Martin to agree to this as a "better part of valor"
kind of thing to get the draft moving.

What did we decide (as always, subject to list discussion)?  There was no
hum of course.

I am good with this.  I thought I had a use (Gateway from PSTN switch using
telephone number as identity), but the room response was "that's a 3rd party
use".  I am okay with that call.

Brian

On 11/11/09 11:29 PM, "Richard Barnes" <rbarnes@bbn.com> wrote:

> Minutes - GEOPRIV - IETF76
> 
> 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