[Gen-art] AW: Gen-ART review of draft-ietf-geopriv-policy-12.txt

Hi Eric, 

thank you for your Gen-Art review of the geolocation policy document. 
A few minor comments below: 

> -----Ursprüngliche Nachricht-----
> Von: ext Eric Gray [mailto:eric.gray@ericsson.com] 
> Gesendet: Donnerstag, 20. September 2007 21:11
> An: Henning Schulzrinne; Tschofenig, Hannes (NSN - DE/Germany 
> - MiniMD); John B Morris; Jorge Cuellar; General Area Review Team
> Cc: Cullen Jennings (fluffy)
> Betreff: Gen-ART review of draft-ietf-geopriv-policy-12.txt
> 
>  
> I am the assigned Gen-ART reviewer for 
> draft-ietf-geopriv-policy-12.txt
> 
> For background on Gen-ART, please see the FAQ at
> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
> 
> Please resolve these comments along with any other comments you may 
> receive.
> 
> Document: draft-ietf-geopriv-policy-12.txt
> 
> Summary: This draft is essentially ready for publication.
> 
> Comments/Questions:
> ==================
> 
> The last sentence in the introduction (last sentence on page 5): where
> do the authors anticipate actions will be defined?  Same question also
> would apply to section 5.

The Common Policy framework does not require that every extension defines child elements for 
* actions
* conditions, and 
* transformations

When actions are not relevant for a particular problem space then they can be omitted. We believe it is the case for this document. 

When this document is used in the context and in combination with the presence authorization policies then the actions defined in the presence authorization policy document would be found in a specific rule. 

For the presence authorization policy document please look at: 
http://tools.ietf.org/wg/simple/draft-ietf-simple-presence-rules/

Does this answer your question? 

> ______________________________________________________________
> _________
> 
> In the next-to-last paragraph in section 4.1 (on page 10), there is an
> interesting (and interestingly confusing) discussion of a possibility
> of supporting co-planar (but not necessarily constant altitude) and/or
> nearly co-planar location polygons - which is then 
> (apparently) negated
> in the last sentence.  Is it the intention - behind saying 
> "two polygon
> forms are permitted" - to assert that all other polygon forms are "not
> permitted" (i.e. - disallowed/forbidden)?  If that is the case, this
> paragraph could probably be simplified.  I would suggest 
> something like:
> 
>    In order for the notion of a location that is defined as within a
>    specific polygon to make sense, points specified for the polygon 
>    MUST be coplanar.  To avoid implementation complexity, only two
>    polygon forms are permitted: polygons specified using EPSG 4326, 
>    and polygons specified using EPSG 4979 with a constant altitude 
>    value.

We took the current text from the following OGC document 

        Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application
        Schema for use by the Internet Engineering Task Force (IETF)",
        Candidate OpenGIS Implementation Specification 06-142, Version:
        0.0.9, December 2006.

that is also used for other GEOPRIV documents, such as http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-08.txt

We just wanted to make sure that there is no contradiction between this work and the rest of the GEOPRIV work. 

Still, your proposal sounds good to me. The difference between your text and the text from the OGC document is only that the current text indicates that an implementation may accept altitude values with a different height. 

Based on the current discussions I got the impression that we are going to delete the altitude issue and hence this problem might go away automatically.  

> 
> It is then possible to consider whether or not it makes sense 
> to retain:
> 
>    However, implementations SHOULD be prepared to accept small
> variations 
>    that might occur depending on whether the the polygon is 
> specified on
> 
>    a plane in space, or only relative to the ellipsoid.  
> 
Correct. 

> 
> NITs:
> ====
> 
> Towards the bottom of page 4, "evalation" should be
> "evaluation"...
Thanks. 

_______________________________________________
__________
> ______________
> 
> In section 12 (Security Considerations), there is what appears to be
> an extra closing paren at the end of the next-to-last sentence.

Correct. Thanks. 

Ciao
Hannes

> 

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art