Subject: [Gen-art] Gen-ART review of draft-ietf-enum-validation-epp-06.txt

From: Suresh Krishnan <[email-masked]>
Date: Tue, 18 Sep 2007 16:59:06 -0400

I am the assigned Gen-ART reviewer for
draft-ietf-enum-validation-epp-06.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 Last Call comments
you may receive.

Summary: This draft ready for publication.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Eric Gray" <[email-masked]>
Date: Thu, 20 Sep 2007 14:11:14 -0500

I am the assigned Gen-ART reviewer for draft-ietf-geopriv-policy-12.txt

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

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.

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.  

NITs:
====

Towards the bottom of page 4, "evalation" should be
"evaluation"..._________________________________________________________
______________

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

---

From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" <[email-masked]>
Date: Mon, 24 Sep 2007 12:12:33 +0200

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-masked]] 
> 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
> 
>  
> draft-ietf-geopriv-policy-12.txt
> 

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? 

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.  

>    a plane in space, or only relative to the ellipsoid.  
Correct. 

> "evaluation"...
Thanks. 

__________

Correct. Thanks. 

Ciao
Hannes

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 24 Sep 2007 08:52:44 -0500

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-masked]] 
> 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-masked]
> Subject: AW: Gen-ART review of draft-ietf-geopriv-policy-12.txt
> Importance: High
> 
> Hi Eric, 
> 
> 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. 
> 
> 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.  
> 
> >

---

From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" <[email-masked]>
Date: Mon, 24 Sep 2007 16:16:04 +0200

> that my summary indicated the draft is ready to publish...

Thanks, Eric. 

Good to hear that. 

Ciao
Hannes