idnits 2.17.00 (12 Aug 2021) /tmp/idnits50116/draft-rosen-geopriv-requirements-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 6 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 22 looks like a reference -- Missing reference section? '2' on line 47 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 geopriv B. Rosen 2 Internet Draft Marconi 3 Document: draft-rosen-geopriv-requirements-00.txt Jose Costa-Requena 4 Category: Informational Nokia 5 Mari Korkea-Aho 6 Nokia 7 Mika Ylianttila 8 University of Oulu 9 Rohan Mahy 10 Cisco Systems 11 Kenji Takahashi 12 NTT 13 Stephen Farrell 14 Baltimore Technologies 16 Geolocation/Privacy Object Requirements 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026 [1]. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. Internet-Drafts are draft documents valid for a maximum of 27 six months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet- Drafts 29 as reference material or to cite them other than as "work in 30 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 1. Abstract 38 This document describes requirements to be placed on the 39 Geolocation/Privacy. This version is an unedited version of draft- 40 spatial-requirements-00, now expired. 42 2. Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 46 this document are to be interpreted as described in RFC-2119 [2]. 48 Geolocation/Privacy Object Requirements August 2001 50 3. Definition of Terms 52 Target: The entity whose location is known by the server and 53 desired by the client. The protocol does not specify 54 how the server learns the location of the target. 55 Server: Entity which supplies the location of the target to the 56 client. One end of the protocol. 57 Client: The entity which desired to learn the location of the 58 target. One end of the protocol. 59 Precision: Number of digits to which the measurement is accurate 60 Accuracy: The measurement is correct to within this maximum 61 expected error 62 Exactness: The precision of the reported value. 63 Velocity: Speed and direction 64 Orientation: Heading or bearing on or near the surface of the Earth, 65 with respect to True North 66 Obfuscate: To intentionally make the measurement less accurate by 67 adding randomness. 68 Geocentric: With respect to, or centered upon the center of gravity 69 of the Earth. 71 4. Location Representation 73 A location representation is an instantiation of the location of a 74 target. In geopriv, location representations shall be determined 75 through two levels of abstraction: schema and format. 77 ŸSchema÷ defines the logical scheme the location representations are 78 based on, such as WGS84. ŸFormat÷ defines how a given schema is 79 represented. A schema can be formatted in several ways. For 80 example, a location determined by WGS84 can be represented in a set 81 of longitude, latitude, and altitude or geo-centric Cartesian 82 coordination (X, Y, Z). 84 The object must: 85 a. Define one default location representation that must be supported 86 by all geopriv entities. 87 b. Specify an absolute location on the earth and use WGS84 geodetic 88 datum as reference system for the default scheme. 89 c. Specify the format of the default scheme in longitude, latitude, 90 altitude parameters. Altitude may be an optional parameter. 91 d. Support other location representations than the default, 92 including existing schemes and formats widely used in other 93 contexts. These location representations may be absolute or 94 descriptive. 95 e. Specify an IANA registration process for additional 96 representations. 98 Geolocation/Privacy Object Requirements August 2001 100 f. Permit at a minimum, the following values to be included in a 101 report, providing that the specified scheme and format have such 102 capability to specify: 104 1. Used location type (e.g absolute/descriptive location), 105 framework (e.g. WGS84, UTM, etc), and syntax/format (e.g. 106 long, lat., alt. in degrees). 107 2. Geocentric Position 108 3. Accuracy 109 4. Exactness 110 5. Time stamp (date, time, time zone) 111 6. Time-to-live 112 7. Direction 113 8. Velocity 114 9. Update frequency (??? do we want to include this?) 115 10. Orientation 117 g. Permit multiple scheme/format representations in a single report. 118 h. Client MUST be able to request certain elements of a format. 119 i. Server MUST be able to provide certain elements of a format based 120 on authorization policy (ex: give my speed, but not my position). 121 j. Server MUST be able to obfuscate a (numeric/coordinate) location 122 based on authorization policy. 123 k. Be extendable to support new location representations. 125 5. Message Coding 126 The object: 128 a. MUST support multiple formats. Each format must be registered 129 with IANA. 130 b. MUST support a very simple format for latitude, longitude, and 131 altitude. 132 c. MUST support a format for timestamp. 133 d. SHOULD have a provision to specify the accuracy of each 134 coordinate/measurement. 135 e. MUST support a mechanism to allow sending of multiple formats in 136 a single payload. 137 f. MUST gracefully handle receipt of formats clients do not 138 understand. 139 g. MUST be able to infer the IANA type and the beginning and end of 140 each format without parsing the entire message (as in TLV). 141 h. MUST support sending multiple instances of the same format within 142 the same packet. 143 i. MUST allow formats to contain raw binary, UTF-8, UTF-16, or UTF- 144 32 content. 145 j. Must support formats which contain human-readable text. Such 146 text SHOULD specify the appropriate language. 147 k. MUST be extensible/flexible enough to support a future 148 descriptive location format. 150 Geolocation/Privacy Object Requirements August 2001 152 l. Formats which tend to be large SHOULD support a simple 153 compression mechanism. 154 m. Both client and server MUST be able to send and receive formats 155 larger than a single packet. 157 6. Representation Negotiation 159 The protocol must: 160 a. Provide a mechanism for the server to inform the client which 161 representations it supports. Such a mechanism must be able to be 162 invoked prior to the first location report. 163 b. Provide a mechanism for the client to select which of said 164 representations it prefers. 165 c. Provide the capability to provide reports in any representation 166 d. Provide that following such selection, reports are provided by 167 the server in the format chosen by the client. 168 e. Provide a mechanisms for the client to specify the need for 169 periodic position updates. 170 f. Provide a mechanism for the client and server to agree upon 171 periodic position updates. 173 7. Server Discovery 175 a. There SHALL be a server discovery mechanism for a client to find 176 the appropriate server for a given target. 177 b. The discovery mechanism SHALL work across domains. It SHOULD use 178 widely deployed mechanisms such as DNS. It SHALL permit server 179 locations to be changed with TTLs ranging from minutes to months. 180 c. Targets SHALL be identified with an identifier. The target 181 identifier SHALL be unique within the domain of the server. 182 d. Servers SHALL be identified by an identifier. Server names SHALL 183 be globally unique. A URI of the form slop:haitao-tangs- 184 phone@airtouch.com would be an appropriate way to identify a 185 target, using the DNS to find the server. 186 e. Clients MUST be able to perform DNS A and SRV lookups, and may 187 support manual configuration and/or other methods to resolve the 188 IP address of a suitable slop server in an unqualified domain. 189 f. Translator services should be distinguishable from other servers 190 during discovery. 191 g. It is desirable that translator capabilities (supported formats) 192 can be determined during discovery. 194 8. Transport 196 a. The protocol SHALL support UDP transport with retry timers for 197 reliability. 198 b. The protocol SHOULD support TCP as an optional transport. 199 c. The protocol MAY support RTP and/or SCTP as optional transports 200 Geolocation/Privacy Object Requirements August 2001 202 d. The protocol SHALL provide a mechanism for the client to request 203 that location reports be delivered by the server using a client 204 specified QoS class or using the QoS class of the request. Such 205 a mechanism SHALL be optional to implement, and SHALL use IETF 206 DiffServ QoS classes. 208 9. Security 210 The object must: 211 a. Provide a mandatory-to-implement, optional-to-use authentication 212 mechanism from client to server and from server to client. The 213 mechanism should allow a choice in the algorithm(s) used. 214 b. Specify how such a mechanism shall be used in the presence of 215 firewalls and Network Address Translation (NAT) between client 216 and server. 217 c. Include mechanisms to allow subsequent location policy decisions 218 to be based on (possibly multiple) factors in addition to the 219 identity (or anonymity) or the client, e.g. authentication 220 mechanism, group membership(s), class-of-user, etc. 221 d. Provide a mandatory-to-implement, optional-to-use data integrity 222 and data origin authentication mechanism for all data. The 223 mechanism should allow a choice in the algorithm(s) used. 224 e. Provide a mandatory-to-implement, optional-to-use data 225 confidentiality mechanism. The mechanism should allow a choice in 226 the algorithm(s) used. 227 f. Not unnecessarily degrade a client's expectations of privacy. 228 g. Support anonymous use, as well as authenticated use. 230 Anonymous use MAY require the server(s) to be able to associate 231 location with the same (anonymous) client over time. 232 h. Where possible make use of existing, proven security mechanisms 233 (e.g. TLS, CMS, IPsec), in particular with respect to 234 cryptographic transforms. 235 i. Specify a mechanism for extending the security mechanism for 236 additional capability. 238 10. Policy 240 The protocol must: 241 a. Provide a mandatory-to-implement, optional-to-use ŸPolicy 242 Enforcement Point÷ mechanism. 243 b. Provide an optional ŸPolicy Decision Point÷ mechanism. 244 c. Specify how servers obtain policy from a policy storage facility 245 if the Policy Decision Point mechanism is implemented. 246 d. Specify a ŸPolicy Information Base÷. 247 e. Provide a mechanism to restrict the information in reports by: 248 1. Accuracy of location 249 2. Frequency of report generation 250 3. Representation format 251 Geolocation/Privacy Object Requirements August 2001 253 4. Identity/class of report-requestor 254 f. Specify the way that the PIB and class-of-user is used to 255 restrict location information reported by interpreting policy 256 selected by class of user. 258 11. References 260 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 261 9, RFC 2026, October 1996. 263 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 264 Levels", BCP 14, RFC 2119, March 1997 266 13. Author's Addresses 268 Brian Rosen 269 Marconi 270 1000 FORE Drive 271 Phone: +1 724 742 6826 272 Email: brian.rosen@marconi.com 274 Jose Costa-Requena 275 Nokia 276 Email: Jose.Costa-Requena@nokia.com 278 Mari Korkea-Aho 279 Nokia 280 Email: mari.korkea-aho@nokia.com 282 Mika Ylianttila 283 Centre for Wireless Communications 284 PL 4500, Tutkijantie 2 E, FIN-90014 285 University of Oulu, Finland 286 Email: over@ees2.oulu.fi 288 Rohan Mahy 289 Cisco Systems 290 170 W Tasman Dr, MS: SJCI/2/3 291 San Jose, CA 95134 292 +1 408 526 8570 293 rohan@cisco.com 295 Kenji Takahashi 296 Information Sharing Platform Laboratories 297 NTT 298 3-9-11 Midoricho 299 Musashino, Tokyo 180-8585 Japan 300 Geolocation/Privacy Object Requirements August 2001 302 Phone: +81 422 59 6668 303 e-mail: kt@nttlabs.com 305 Stephen Farrell 306 Baltimore Technologies 307 61 Fitzwilliam Lane 308 Dublin 2. Ireland 309 Phone: +353 1 647 7406 310 email: stephen.farrell@baltimore.ie 311 Geolocation/Privacy Object Requirements August 2001 313 Full Copyright Statement 315 "Copyright (C) The Internet Society (date). All Rights Reserved. 316 This document and translations of it may be copied and furnished to 317 others, and derivative works that comment on or otherwise explain it 318 or assist in its implmentation may be prepared, copied, published 319 and distributed, in whole or in part, without restriction of any 320 kind, provided that the above copyright notice and this paragraph 321 are included on all such copies and derivative works. However, this 322 document itself may not be modified in any way, such as by removing 323 the copyright notice or references to the Internet Society or other 324 Internet organizations, except as needed for the purpose of 325 developing Internet standards in which case the procedures for 326 copyrights defined in the Internet Standards process must be 327 followed, or as required to translate it into 328 Geolocation/Privacy Object Requirements August 2001