Subject: [Geopriv] GEOPRIV minutes from IETF 76

From: Richard Barnes <[email-masked]>
Date: Fri, 13 Nov 2009 11:04:39 +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 the major outstanding technical issue with loc- 
filters is 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  
restrict usage to limited cases with pre-configured authorization  
relationships, except possibly for some cases the document can provide  
clear, implementable guidance.

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: "Winterbottom, James" <[email-masked]>
Date: Fri, 13 Nov 2009 10:58:28 +0800

[AJW] Absolutely NOT TRUE! I voiced a very strong protest to this in the jabber room. I agree to this ONLY for the identifiers that cannot have an explicitly verifiable link back to the Target IP address. I have provided one very good example of where this is the case. I will look at the others and see if there are similar scenarios. But please, the comment above about the author's agreeing is false and what is stated was not the outcome.

Cheers
James

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 13 Nov 2009 08:15:17 +0100

This is a working group document.

It does not have authors.

It has editors who work to WG concensus. What was the WG consensus?

regards

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Winterbottom, James
> Sent: Friday, November 13, 2009 2:58 AM
> To: Richard Barnes; [email-masked]
> Subject: Re: [Geopriv] GEOPRIV minutes from IETF 76
> 
> 
> 
> 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 restrict usage to limited cases with 
> pre-configured authorization relationships, except possibly 
> for some cases the document can provide clear, implementable guidance.
> 
> [AJW] Absolutely NOT TRUE! I voiced a very strong protest to 
> this in the jabber room. I agree to this ONLY for the 
> identifiers that cannot have an explicitly verifiable link 
> back to the Target IP address. I have provided one very good 
> example of where this is the case. I will look at the others 
> and see if there are similar scenarios. But please, the 
> comment above about the author's agreeing is false and what 
> is stated was not the outcome.
> 
> Cheers
> James
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 13 Nov 2009 15:23:28 +0800

No hum called, no consensus reached!

________________________________________
From: DRAGE, Keith (Keith) [[email-masked]]
Sent: Friday, November 13, 2009 1:15 AM
To: Winterbottom, James; Richard Barnes; [email-masked]
Subject: RE: [Geopriv] GEOPRIV minutes from IETF 76

regards

Keith

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 13 Nov 2009 16:09:50 +0800

There was general agreement that LCP cases could be included - providing that these were described in sufficient detail.  The concern was with the amount detail for LCP in the current draft.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of DRAGE, Keith (Keith)
> Sent: Friday, 13 November 2009 4:15 PM

---

From: Richard Barnes <[email-masked]>
Date: Fri, 13 Nov 2009 18:48:35 +0900

Martin,

Thank you for being sane.

That is all,
--Richard

On Nov 13, 2009, at 5:09 PM, Thomson, Martin wrote:

> There was general agreement that LCP cases could be included -  
> providing that these were described in sufficient detail.  The  
> concern was with the amount detail for LCP in the current draft.
>

---

From: Marc Linsner <[email-masked]>
Date: Fri, 13 Nov 2009 08:10:04 -0500

James,

I do hope you realize that stating 'no LCP' does not prevent a target from
discovering it's own location using identity-ext.  The characteristic of
'LCP' is that the communication protocol provides assurances to the LIS the
request is from the target.  Identity-ext cannot do this.  So, if the LIS
can go off and verify the request is in fact from the target using some
'out-of-band' mechanism, great, the LIS can then chose the proper policy.

So, from a policy POV, identity-ext (by itself) CANNOT be a LCP.

BTW, I'm still bothered by the assumption of 'LCP Policy'.  Such a policy is
still under control of the Rulemaker(s).  GeoPriv does not dictate 'LCP
Policy'.

-Marc-

On 11/12/09 9:58 PM, "Winterbottom, James" <[email-masked]>
wrote:

> [AJW] Absolutely NOT TRUE! I voiced a very strong protest to this in the
> jabber room. I agree to this ONLY for the identifiers that cannot have an
> explicitly verifiable link back to the Target IP address. I have provided one
> very good example of where this is the case. I will look at the others and see
> if there are similar scenarios. But please, the comment above about the
> author's agreeing is false and what is stated was not the outcome.
> 
> Cheers
> James
>