Subject: [Geopriv] REMINDER Re: WGLC: draft-ietf-geopriv-policy-17

From: Robert Sparks <[email-masked]>
Date: Fri, 11 Jul 2008 13:44:19 -0500

Please send a note to the list when you've looked at this.
"Good to go" comments are important to capture.

RjS

On Jun 30, 2008, at 3:32 PM, Robert Sparks wrote:

> All -
>
> This is a GEOPRIV Working group last call for comments on:
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-17.txt
>
> This document has undergone extensive revision since this group  
> requested its publication.
> This version should represent closure on the many discussions that  
> have taken place during its IETF and IESG review.
>
> Please give this document careful attention.
>
> Given that everyone is also preparing new drafts and getting ready  
> for Dublin's meeting, this WGLC will last 3 weeks.
> Please have your comments in by July 20.
>
> Thanks,
>
> RjS
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

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

---

From: Richard Barnes <[email-masked]>
Date: Fri, 11 Jul 2008 16:13:36 -0400

I believe this document is good to go.
--Richard

Robert Sparks wrote:
>> Given that everyone is also preparing new drafts and getting ready for 
>> Dublin's meeting, this WGLC will last 3 weeks.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 12 Jul 2008 22:22:32 +0300

Btw,

based on the recent discussion on the mailing list about the support of 
timezones. RFC 5025 has the ability to control the distribution of the 
time-offset:

3.3.2.11.  Provide Time-Offset

   This permission controls access to the <time-offset> element defined
   in [9].  The name of the element providing this permission is
   <provide-time-offset>, and it is a Boolean type.  If its value is
   TRUE, then the <time-offset> element in the person data element is
   reported to the watcher.  If FALSE, this presence attribute is
   removed if present.

There is, however, no such element in the Geolocation Policy document nor 
is there a condition element that would allow you to say something like "If I am at this timezone then ...."

Problem? 

Ciao
Hannes

---

From: Robert Sparks <[email-masked]>
Date: Mon, 21 Jul 2008 11:01:42 -0500

Note that we have hit the end of this WGLC period. There was  
frighteningly little response to the call.

Did people get to read this document and understand the changes that  
were made since we sent it up last? Please reply.

Based on offline communication, I believe Hannes has one last thing to  
double-check on. Unless there's controversy, I expect we will re- 
request publication soon.

I'd be a _lot_ more comfortable with that if there were some list  
evidence that this version of the document has received sufficient  
review.

RjS

---

From: [email-masked]
Date: Mon, 21 Jul 2008 17:15:25 -0400 (EDT)

Robert -

One minor nigly - the reference for GML as stated in the document:

 OpenGIS, "OpenGIS Geography Markup Language (GML)
         Implementation Specification, Version 3.00, OGC 02 023r4",
          http://www.opengeospatial.org/docs/02-023r4.pdf, January 2003.

Should be:

Open Geospatial Consortium, "OpenGIS Geography Markup Language (GML)
         Implementation Standard, Version 3.1.1, OGC 03 105r1",
          http://portal.opengeospatial.org/files/?artifact_id=4700,
January 2003.

This is the version that the PIDF-LO geodetic GML application schema
references.

I suspect the reference also needs to be corrected in a couple of other
IETF documents.

Regards

Carl Reed
OGC

---

From: "Kyle, Martin" <[email-masked]>
Date: Mon, 21 Jul 2008 21:31:42 -0700

Hi Robert:
 
Perhaps, I am jumping into the fray without all the necessary context. However, when I read over the document with its intended purposes; it sounded a lot like an extension to the OASIS XACML Policy Language (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml) called OGC GeoXACML (http://www.opengeospatial.org/standards/geoxacml) ... albeit privacy and authorization are different things; though, privacy may depend on an authorization mechanism.
 
>From draft-ietf-geopriv-policy-17.txt:
 
"This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control."
 
>From OGC GeoXACML standard:
 
"GeoXACML defines an extension to XACML for spatial data types and spatial authorization decision functions. Those data types and functions can be used to define additional spatial constraints for XACML based policies."
 
Clearly draft-ietf-geopriv-policy-17.txt appears to be built off of RFC 4745 while OGC GeoXACML is built off of OASIS XACML 2.0
 
The use cases that each address are identical in at least one case: "The rule set allows the entity that uses the rules defined in this document to restrict the retention and to enforce access restrictions on location data, including prohibiting any dissemination to particular individuals, during particular times or when the Target is located in a specific region."
 
The Geodetic Location Condition Profile seems quite anaemic from a geospatial perspective in that it only addresses one case (i.e. within - "Rule Makers use this profile by placing a GML [3] <Circle> element within the <location> element ") of the Egenhofer operators based on the 9-intersection model. The more robust set of operators are given URN references in the GeoXACML standard and thus allow other types of topological constraints to be encoded.
 
The various services (e.g. Location Server, Rule Maker) described in the draft-ietf-geopriv-policy-17.txt also seem to have corollaries in the OASIS XACML standard (e.g. Policy Decision Point, Policy Enforcement Point, Policy Administration Point, etc...).
 
As I do not know anything of merit in this domain, please consider my comments advisory only based on my background in geospatial web services. Indeed, you may have already considered the points that I raise.
 
Cheers,
 
Martin
 
H. Martin Kyle | Principal, GISP CASS
Sierra Systems

(T): 604-688-1371 (C): 778-384-5409 (F): 604-688-6482
1177 West Hastings Street, Suite 2500
Vancouver, BC V6E 2K3

Management Consulting | Project Implementation | Managed Services
website: www.SierraSystems.com <http://www.sierrasystems.com/> 

________________________________

From: [email-masked] on behalf of Robert Sparks
Sent: Mon 7/21/2008 9:01 AM
To: GEOPRIV
Subject: Re: [Geopriv] REMINDER Re: WGLC: draft-ietf-geopriv-policy-17

RjS

----Notice Regarding Confidentiality----
This email, including any and all attachments, (this "Email") is intended only for the party to whom it is addressed and may contain information that is confidential or privileged.  Sierra Systems Group Inc. and its affiliates accept no responsibility for any loss or damage suffered by any person resulting from any unauthorized use of or reliance upon this Email.  If you are not the intended recipient, you are hereby notified that any dissemination, copying or other use of this Email is prohibited.  Please notify us of the error in communication by return email and destroy all copies of this Email.  Thank you.
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 22 Jul 2008 10:10:53 +0300

Hi Martin, 

I know about GeoXACML and also about XACML. 

A long time ago I proposed to use XACML but that proposal was rejected
and the outcome of the work was Common Policy. I don't think that this
was a bad decision given that Common Policy is fairly simple. 

Regarding the relationship to GeoXACML: I am not surprised that they are
similar given that GeoXACML was written after initial versions of
Geolocation Policy were published. 

I have complained to the group that some features of Geolocation Policy
have caused a huge discussion during the IESG review while they did not
seem to be controversial in GeoXACML. 

For some reason the Geolocation Policy document is still not finished
and, as you can imagine, I am not all that happy about this. On the
other hand, deployment on location based services & authorization needs
to catch up with these things anyway. 

Since you have read the geolocation policy draft I have a question for
you. Do you think the document is readable and simple enough? Is there
anything we could simplify further? 

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Kyle, Martin
>Sent: 22 July, 2008 07:32
>To: Robert Sparks; GEOPRIV
>Perhaps, I am jumping into the fray without all the necessary 
>context. However, when I read over the document with its 
>intended purposes; it sounded a lot like an extension to the 
>OASIS XACML Policy Language 
>(http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xac
ml) called OGC GeoXACML
>(http://www.opengeospatial.org/standards/geoxacml) ... albeit 
>privacy and authorization are different things; though, 
>privacy may depend on an authorization mechanism.
> 
>"This document defines an authorization policy language for 
>controlling access to location information. It extends the 
>Common Policy authorization framework to provide 
>location-specific access control."
> 
>"GeoXACML defines an extension to XACML for spatial data types 
>and spatial authorization decision functions. Those data types 
>and functions can be used to define additional spatial 
>constraints for XACML based policies."
> 
>Clearly draft-ietf-geopriv-policy-17.txt appears to be built 
>off of RFC 4745 while OGC GeoXACML is built off of OASIS XACML 2.0
> 
>The use cases that each address are identical in at least one 
>case: "The rule set allows the entity that uses the rules 
>defined in this document to restrict the retention and to 
>enforce access restrictions on location data, including 
>prohibiting any dissemination to particular individuals, 
>during particular times or when the Target is located in a 
>specific region."
> 
>The Geodetic Location Condition Profile seems quite anaemic 
>from a geospatial perspective in that it only addresses one 
>case (i.e. within - "Rule Makers use this profile by placing a 
>GML [3] <Circle> element within the <location> element ") of 
>the Egenhofer operators based on the 9-intersection model. The 
>more robust set of operators are given URN references in the 
>GeoXACML standard and thus allow other types of topological 
>constraints to be encoded.
> 
>The various services (e.g. Location Server, Rule Maker) 
>described in the draft-ietf-geopriv-policy-17.txt also seem to 
>have corollaries in the OASIS XACML standard (e.g. Policy 
>Decision Point, Policy Enforcement Point, Policy 
>Administration Point, etc...).
> 
>As I do not know anything of merit in this domain, please 
>consider my comments advisory only based on my background in 
>geospatial web services. Indeed, you may have already 
>considered the points that I raise.
> 
>Cheers,
> 
>Martin
> 
>Did people get to read this document and understand the 
>changes that were made since we sent it up last? Please reply.
>
>Based on offline communication, I believe Hannes has one last 
>thing to double-check on. Unless there's controversy, I expect 
>we will re- request publication soon.
>
>I'd be a _lot_ more comfortable with that if there were some 
>list evidence that this version of the document has received 
>sufficient review.
>
>RjS
>
>
>----Notice Regarding Confidentiality---- This email, including 
>any and all attachments, (this "Email") is intended only for 
>the party to whom it is addressed and may contain information 
>that is confidential or privileged.  Sierra Systems Group Inc. 
>and its affiliates accept no responsibility for any loss or 
>damage suffered by any person resulting from any unauthorized 
>use of or reliance upon this Email.  If you are not the 
>intended recipient, you are hereby notified that any 
>dissemination, copying or other use of this Email is 
>prohibited.  Please notify us of the error in communication by 
>return email and destroy all copies of this Email.  Thank you.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 22 Jul 2008 11:16:08 -0500

Carl

RFC 4119 says that GML 3.0 is the mandatory to implement version, 
while the PIDF-LO profile document allows later releases of GML.

With that in mind - which reference, in your mind, is the more 
appropriate one to reference?

(I'd lean towards 3.0, because of the 4119 mandate, but could be wrong).

James

---

From: [email-masked]
Date: Tue, 22 Jul 2008 13:10:05 -0400 (EDT)

James -

Thanks for the question. The only issue I see is that 3.1.1 contains a
variety of schema corrections. 3.0 is currently not used by developers for
this reason. I am not sure of the implications to 4119 as I am not as
familiar with the IETF procedures as you and others are.

This also raises the question of what to do with 4119 and related
documents now that GML 3.2.1 is the official version - and also now an ISO
standard: ISO 19136.

Thoughts

Carl

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 22 Jul 2008 12:25:38 -0500

Carl

So, question back to you, do you believe there will come a time in 
the near future that GML 3.1.1 will "not be used by developers"?

If so, what's your prediction,

         - 1 year
         - 2 years
         - more than 3 years
         - more than 5 years
         - more than 7-10 years
?

I'm only looking for best guess, btw

In other words, is GML 3.1.1 a good, new, long lasting baseline to work from?

James

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 22 Jul 2008 20:50:53 +0300

From the standpoint of draft-ietf-geopriv-policy-17 it does not matter 
what we reference since we are essentially pointing to the PIDF-LO 
profile. I think we should reference GML informatively since PIDF-LO 
profile is already referenced normatively

---

From: [email-masked]
Date: Tue, 22 Jul 2008 13:56:16 -0400 (EDT)

James -

The GML geometry and feature elements used in PIDF-LO GML schema are
totally compatible between GML 3.1.1 and GML 3.2.1. The vast majority of
GML development is still in 3.1.1. I would say that 3.1.1 is a stable
platform for implementation and will be for some time.

Please note, however, that the OGC members are currently beginning the GML
4.0 revision process. There is currently an open call for change requests.
This call closes in September. That said, the actually completion of the
work on version 4.0 will not happen until late next year. And then we need
to coordinate with ISO. So, the full blown transition to 4.0 as an
International Standard (ISO) will not happen until 2010. So, I would say
we have a 2 year window before 3.1.1 is totally deprecated and no longer
used as the GML development platform

Of course, this does not mean 3.1.1 cannot be used. For example, the OMA
MLP API references GML 2.1.2 - and 2.1.2 is something like 5 years old. We
would like OMA to upgrade to 3.1.1 or 3.2 but they are happy with using
2.1.2 as MLP is a stable standard with many implementations.

Apologies for the slight wander . . . but the decision to move from 3.1.1
to a new version depends on requirements, current market conditions, and
so forth combined a consensus agreement to move.

Hope this helps.

Carl

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 22 Jul 2008 13:17:42 -0500

Carl

This is good background and I like the wandering when an absolute 
answer is not possible. You've given a good update to all of us, thanks!

James

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 22 Jul 2008 17:41:03 -0500

I think that I've already said this on-list, but I just checked and it wasn't on this thread so...

As one of those who had objections to the content in earlier versions, I've reviewed the changes and they address my concerns.  It is my opinion that this document is ready to publish.

Cheers,
Martin

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Robert Sparks
> Sent: Tuesday, 22 July 2008 2:02 AM
> To: GEOPRIV

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv