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