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

Good to hear that. 

Ciao
Hannes

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