> 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 > > > > > > > > _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
