Re: [Geopriv] Draft GEOPRIV notes for IETF 76

["Hannes Tschofenig" <[e-mail]>]

+1 

(Please note that there is also an updated draft that addresses various
issues raised in the review that I quickly addressed.) 

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Richard Barnes
>Sent: 12 November, 2009 18:24
>To: James M. Polk
>Cc: [e-mail]
>Subject: Re: [Geopriv] Draft GEOPRIV notes for IETF 76
>
>James,
>
>Don't shoot the messenger, man!  I was just trying to 
>summarize what Hannes said.  The following may be more accurate:
>
>"Hannes Tschofenig noted that the major outstanding technical 
>issue with loc-filters is whether to add a "speed greater 
>than" condition."
>
>Please note that that sentence doesn't imply that he's not 
>going to address the rest of your comments, just that they're 
>more straightforward than that issue.
>
>--Richard
>
>
>
>
>
>On Nov 12, 2009, at 3:04 PM, James M. Polk wrote:
>
>> At 10:29 PM 11/11/2009, Richard Barnes 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.
>>
>> Richard/Alissa
>>
>> I sent a note to the list containing 47 numbered comments 
>with what I 
>> believe need to be addressed wrt to my review of loc-filters.
>> http://www.ietf.org/mail-archive/web/geopriv/current/msg08118.html
>>
>> The authors haven't replied to at least half of the comments I made.
>>
>> Are these being ignored by the chairs, or possible was this note not 
>> read?
>>
>> Or do you want issue tracker entries for all 47 before they will be 
>> considered?
>>
>> Or do I need to write individual messages to the list, with numbers, 
>> so that each can be addressed and closed individually?
>>
>> I'm kinda at a loss as to how this many comments look like they are 
>> about to be ignored -- especially since I didn't get into the "speed 
>> greater than" issue that is mentioned above (but maybe I'm not 
>> understanding the issue as stated; as I have issues regarding this 
>> section of the ID -- like acceleration anyone?).
>>
>> James
>>
>> BTW -- I agree with some of the author's responses (as some of these 
>> were just clarifications about what was meant). I am pleased some of 
>> my comments have resulted in modified text. However, I don't agree 
>> with all of the responses.  I'll be continuing with the list thread 
>> about these.
>>
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>
>
>_______________________________________________
>Geopriv mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/geopriv
>