RE: Gen-ART review of draft-ietf-geopriv-policy-12.txt

Hannes,

	Yes, I am satisfied with your answers.  For the record,
they were as much for curiosity as for anything else - given
that my summary indicated the draft is ready to publish...

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Tschofenig, Hannes (NSN - DE/Germany - MiniMD) 
> [mailto:[email protected]] 
> Sent: Monday, September 24, 2007 6:13 AM
> To: Eric Gray; Henning Schulzrinne; John B Morris; Jorge 
> Cuellar; General Area Review Team
> Cc: Cullen Jennings (fluffy); [email protected]
> Subject: AW: Gen-ART review of draft-ietf-geopriv-policy-12.txt
> Importance: High
> 
> 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:[email protected]] 
> > 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
> 
> > 
>