[Gen-art] AW: Gen-ART review of draft-ietf-geopriv-policy-12.txt
"Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" <hannes.tschofenig@nsn.com> Mon, 24 September 2007 14:16 UTC
Return-path: <gen-art-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZok4-0006UX-3o; Mon, 24 Sep 2007 10:16:56 -0400
Received: from gen-art by megatron.ietf.org with local (Exim 4.43) id 1IZok2-0006TG-8F for gen-art-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 10:16:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZok0-0006Q6-5X; Mon, 24 Sep 2007 10:16:52 -0400
Received: from demumfd001.nsn-inter.net ([217.115.75.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZojt-0000Qg-IP; Mon, 24 Sep 2007 10:16:52 -0400
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id l8OEGAYA032725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Sep 2007 16:16:10 +0200
Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id l8OEG5BL015452; Mon, 24 Sep 2007 16:16:05 +0200
Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 16:16:05 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 24 Sep 2007 16:16:04 +0200
Message-ID: <5FB585F183235B42A9E70095055136FB32D06A@DEMUEXC012.nsn-intra.net>
In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF01A0FB58@eusrcmw721.eamcs.ericsson.se>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Gen-ART review of draft-ietf-geopriv-policy-12.txt
Thread-Index: Acf6NwSJXtzoHQWJTfa5KTFy9wttCABeVOHQALeNslAACNW/IAAA3mSw
References: <46F03C1A.3020905@ericsson.com> <941D5DCD8C42014FAF70FB7424686DCF019E0D5F@eusrcmw721.eamcs.ericsson.se> <5FB585F183235B42A9E70095055136FB1E5516@DEMUEXC012.nsn-intra.net> <941D5DCD8C42014FAF70FB7424686DCF01A0FB58@eusrcmw721.eamcs.ericsson.se>
From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" <hannes.tschofenig@nsn.com>
To: ext Eric Gray <eric.gray@ericsson.com>, Henning Schulzrinne <schulzrinne@cs.columbia.edu>, John B Morris <jmorris@cdt.org>, Jorge Cuellar <Jorge.Cuellar@siemens.com>, General Area Review Team <gen-art@ietf.org>
X-OriginalArrivalTime: 24 Sep 2007 14:16:05.0506 (UTC) FILETIME=[71CBB620:01C7FEB5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, geopriv@ietf.org
Subject: [Gen-art] AW: Gen-ART review of draft-ietf-geopriv-policy-12.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org
> 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:hannes.tschofenig@nsn.com] > > 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); geopriv@ietf.org > > 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:eric.gray@ericsson.com] > > > 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 Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
- [Gen-art] Gen-ART review of draft-ietf-enum-valid… Suresh Krishnan
- [Gen-art] Gen-ART review of draft-ietf-geopriv-po… Eric Gray
- [Gen-art] AW: Gen-ART review of draft-ietf-geopri… Tschofenig, Hannes (NSN - DE/Germany - MiniMD)
- [Gen-art] RE: Gen-ART review of draft-ietf-geopri… Eric Gray
- [Gen-art] AW: Gen-ART review of draft-ietf-geopri… Tschofenig, Hannes (NSN - DE/Germany - MiniMD)