Subject: [Geopriv] Draft GEOPRIV notes for IETF 76

From: Richard Barnes <[email-masked]>
Date: Thu, 12 Nov 2009 13:29:24 +0900

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.

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 12 Nov 2009 00:04:44 -0600

>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.

>_______________________________________________
>Geopriv mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/geopriv

---

From: Richard Barnes <[email-masked]>
Date: Thu, 12 Nov 2009 18:23:49 +0900

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:

> 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.
>> 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.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 12 Nov 2009 18:41:28 +0900

+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: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Richard Barnes
>Sent: 12 November, 2009 18:24
>To: James M. Polk
>Cc: [email-masked]
>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
>
>
>
>
>
>>> Martin Thomson presented an update on this document.  The primary 
>>> open issues are around how authentication and authorization are 
>>> applied.
>>> 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 
>>> draft-ietf-geopriv-arch (Alissa Cooper) In opinion of Alissa, about 
>>> ready for last call.
>>> raised on the list are valid questions but do not need to be 
>>> addressed in this document, so out of scope.
>>> 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: Fundamental distinction between these cases - different 
>>> approach, different security.
>>> draft-polk-geopriv-int-relative-in-tlv (Dorothy Stanley) Proposal 
>>> also make use of draft-rosen-geopriv-pidf-interior.
>>> Roger Marshall: Good to have a discreet reference that is more 
>>> precise than "front door".
>>> 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.
>>> 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.
>>> 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.
>>> that is there. An entity not understanding the extension would get 
>>> the wrong location.
>>> 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
>>> draft-thomson-geopriv-indoor-location (Martin Thompson) Addresses 
>>> same problem, but solution takes into account some things Martin 
>>> considers important.
>>> 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.
>>> 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.
>>>
>>> Jon: Needs to be some glue for some cases. Want to make sure all 
>>> those cases are covered.
>>> Richard: OK, that's fine for the 1st point. For the 2nd and 3rd 
>>> (about the security issues) I'm not sure.
>>> Jon: There are different classes of identifier, and perhaps these 
>>> need to be dealt with seperately. You have different sets 
>of security 
>>> Jon: Re: Emergency Service case: This is the only case where I can 
>>> see this draft working.
>>> 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.
>>> Richard: What is the difference between the private and the 
>>> registered int syntax.
>>> 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.
>>> 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.
>>>
>>> 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.
>>> 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.
>>> 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).
>>> 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.
>>>
>>> Martin: I was asked not to present, but I do have a presentation of 
>>> my draft ready
>>> 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.
>>> 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.
>>>
>>> context, PSAPs don't have a exchange protocol to communicate with 
>>> each other. Something based on LoST is perhaps the way to go.
>>> Brian (remotely): Yes, I agree, but this should be a new 
>protocol.   
>>> 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.
>>>
>>> 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 
>>> Martin: Can I also have comments on the list about -immediate- 
>>> publish, which may have some relevance here.
>>>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 12 Nov 2009 13:51:30 -0500

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

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 12 Nov 2009 13:58:37 -0600

>issues raised in the review that I quickly addressed.)

please note that I did say I was pleased that some of the comments 
were taken well by the authors, and even resulted in some clarifying 
or improved text be added to the ID.

I didn't bash what you said, I just wanted to make sure each of the 
comments were addressed in this final WGLC (before it gets thrown 
over the wall to the IESG).

James

BTW -- Keith's holding me accountable for each of the comments you 
(or anyone else that's) made on Location Conveyance using a 
spreadsheet, not just my confirmation that they are addressed.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 13 Nov 2009 11:04:58 +0900

Reworded and submitted.

On Nov 13, 2009, at 3:51 AM, Brian Rosen wrote:

>> open
>> syntax
>> we
>> need
>> to
>> be
>> the
>> location
>> or
>> those
>> need
>> see
>> LIS
>> registered
>> be
>> we
>> water
>> so
>> binary
>> were
>> my
>> as
>> LIS
>> conversion
>> each
>> worry
>> is

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 13 Nov 2009 10:57:55 +0800

In line

> kind of thing to get the draft moving.

[AJW] There are very clear examples where the LCP does work and is useful, we will highlight these in the draft. In WiMAX for example the IP address return routability is allowed, but there is no explicit way to interrogate the RADIUS server using IP address, there is for NAI. If you query using NAI you will get out of the RADIUS server the IP address assigned to that NAI, along with a bunch of other things including the WiMAX-session-id that is the identifier used in the ASN to identify the device. This is a real world case, and it can really only work as currently defined if the NAI is provided by the Target in a LCP case.

I don't see a away to turn this into a third-party request, and it is a legitimate usage for LCP that is verifiable. So I am absolutely NOT OKAY with restricting identity extensions to third-party only requests! I might be okay with restricting it only those identifiers that we can provide a verifiable usecase for. The question then comes about whether these use cases go into the body or whether they are normative appendices.

Cheers
James

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 13 Nov 2009 12:31:01 -0600

Richard

If nothing else, I'm firmly reminding whoever is the document 
shepherd that there are some outstanding issues remaining, and these 
need to be checked out - as they occurred within WGLC - before the 
doc gets thrown over the wall to the IESG.

Sometimes firmness (or bluntness) is needed to get attention.

For instance, the stance of the authors that this doc has no 
relationship to Location Conveyance will be troublesome for 
implementers, given that Conveyance has always said - even before 
Rohan wrote the first -00 of loc-filters - that for SIP to carry 
location as a value or a location URI, the Geolocation header value 
(which back then was the Location header value) must be present.

Now, according to Location Conveyance, implementers must include a 
Geolocation header value when carrying location as a PIDF-LO or a 
Location URI, even in a NOTIFY request.  Yet, according to 
loc-filters-08 and the authors, the Geolocation header value is not 
necessary at all.

So, imagine you are an implementer, if you're implementing 
loc-filters you are probably implementing Location Conveyance too. 
Now, are you really going to implement that in some cases there is a 
Geolocation header value, and this one case there is none - by 
implementation choice?

that will lead to Location Conveyance not being followed, or 
loc-filters having something added to it when implemented.

This is an inconsistency that might be troublesome to LRs, and appear 
in RFPs, as this is clearly not following the rules of Location 
Conveyance, which is defining SIP as a using protocol (a defined term 
that some believe doesn't apply anymore, yet is still in our 
documents, and is in one that's about to go to the IESG 
(lbyr-requirements) from this WG -- so this means it's still applicable).

James

At 03:23 AM 11/12/2009, Richard Barnes wrote:
>>>Martin: Can I also have comments on the list about -immediate- publish,

---

From: Brian Rosen <[email-masked]>
Date: Fri, 13 Nov 2009 14:12:53 -0500

James

We've responded to this, and yet you persist.

This is PRESENCE.  Nothing more, nothing less.

PRESENCE, predates Geolocation by a lot, but even if it didn't, presence
returns a PIDF in the body of a NOTIFY.  It doesn't need, nor want, a
Geolocation header even if the PIDF contains a PIDF-LO.  That is
fundamental.  It's simple.

Think about what you are saying.  If a plain old presence subscription
happens to have a PIDF-LO in it, you are arguing that there must be a
Geolocation header in the NOTIFY.  That makes no sense.

You subscribe to presence, and if the presence NOTIFY has location,
loc-filters can be used, like any other filter, to adjust the frequency of
notification.  It is NOT related to Geolocation.

It's not implementation choice.  If you are using the presence event
package, you don't use Geolocation (at least normally).  I shudder to
imagine what would happen if you tried.  I think you would need multipart
and two PIDFs, one for the Notify body and the other for the Geolocation
header cid.

Brian

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 13 Nov 2009 14:01:59 -0600

Brian

I know you responded, but how you responded didn't make sense to me.

To be clear, I'm not suggesting a Geolocation: be in the SUBSCRIBE, 
just in the NOTIFY, if it contains a PIDF-LO.

Saying Presence predates Conveyance therefore you're gonna stick to 
the old rules and procedures of Presence is explicitly saying you 
don't care about any changes that are being made since Presence was 
first defined -- which Conveyance does to all of SIP when Location is 
carried in any SIP request.

Heck, dude, Conveyance even insists when you subscribe to another 
entity, you use the Presence event package *with* a Geolocation: 
header value (when location is contained as a value or a reference).

Conveyance updates all of SIP where location is concerned, it's just 
not a formal update to 3261 or 3265.

I'm saying - also - that RFPs will be written saying whenever 
Location is transported in SIP, that vendor's products must support 
whatever RFC Conveyance becomes. Yet, you're arguing that in the case 
of Presence - which Conveyance talks about - don't use the rules or 
guidelines in Conveyance.

I'm thinking this may be the wrong list to have this discussion, 
since Conveyance belongs to the SIPCORE WG, and that's where 
subscriptions are primarily also owned.

James