idnits 2.17.00 (12 Aug 2021) /tmp/idnits49243/draft-rosen-spatial-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 374 lines 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 46 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Spatial B. Rosen 2 Internet Draft Marconi 3 Document: draft-rosen-spatial-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 Spatial Location Protocol 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 Spatial 39 Location Protocol (SloP). 41 2. Conventions used in this document 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 45 this document are to be interpreted as described in RFC-2119 [2]. 47 Spatial Location Protocol (SloP) Requirements July 2000 49 3. Definition of Terms 51 Target: The entity whose location is known by the server and 52 desired by the client. The protocol does not specify 53 how the server learns the location of the target. 54 Server: Entity which supplies the location of the target to the 55 client. One end of the protocol. 56 Client: The entity which desired to learn the location of the 57 target. One end of the protocol. 58 Precision: Number of digits to which the measurement is accurate 59 Accuracy: The measurement is correct to within this maximum 60 expected error 61 Exactness: The precision of the reported value. 62 Velocity: Speed and direction 63 Orientation: Heading or bearing on or near the surface of the Earth, 64 with respect to True North 65 Obfuscate: To intentionally make the measurement less accurate by 66 adding randomness. 67 Geocentric: With respect to, or centered upon the center of gravity 68 of the Earth. 70 4. Location Representation 72 A location representation is an instantiation of the location of a 73 target. In SLoP, location representations shall be determined 74 through two levels of abstraction: schema and format. 76 "Schema" defines the logical scheme the location representations are 77 based on, such as WGS84. "Format" defines how a given schema is 78 represented. A schema can be formatted in several ways. For 79 example, a location determined by WGS84 can be represented in a set 80 of longitude, latitude, and altitude or geo-centric Cartesian 81 coordination (X, Y, Z). 83 The protocol must: 84 a. Define one default location representation that must be supported 85 by all SLOP entities. 86 b. Specify an absolute location on the earth and use WGS84 geodetic 87 datum as reference system for the default scheme. 88 c. Specify the format of the default scheme in longitude, latitude, 89 altitude parameters. Altitude may be an optional parameter. 90 d. Support other location representations than the default, 91 including existing schemes and formats widely used in other 92 contexts. These location representations may be absolute or 93 descriptive. 94 e. Specify an IANA registration process for additional 95 representations. 97 Spatial Location Protocol (SloP) Requirements July 2000 99 f. Permit at a minimum, the following values to be included in a 100 report, providing that the specified scheme and format have such 101 capability to specify: 103 1. Used location type (e.g absolute/descriptive location), 104 framework (e.g. WGS84, UTM, etc), and syntax/format (e.g. 105 long, lat., alt. in degrees). 106 2. Geocentric Position 107 3. Accuracy 108 4. Exactness 109 5. Time stamp (date, time, time zone) 110 6. Time-to-live 111 7. Direction 112 8. Velocity 113 9. Update frequency (??? do we want to include this?) 114 10. Orientation 116 g. Permit multiple scheme/format representations in a single report. 117 h. Client MUST be able to request certain elements of a format. 118 i. Server MUST be able to provide certain elements of a format based 119 on authorization policy (ex: give my speed, but not my position). 120 j. Server MUST be able to obfuscate a (numeric/coordinate) location 121 based on authorization policy. 122 k. Be extendable to support new location representations. 124 5. Message Coding 125 The protocol: 127 a. MUST support multiple formats. Each format must be registered 128 with IANA. 129 b. MUST support a very simple format for latitude, longitude, and 130 altitude. 131 c. MUST support a format for timestamp. 132 d. SHOULD have a provision to specify the accuracy of each 133 coordinate/measurement. 134 e. MUST support a mechanism to allow sending of multiple formats in 135 a single payload. 136 f. MUST gracefully handle receipt of formats clients do not 137 understand. 138 g. MUST be able to infer the IANA type and the beginning and end of 139 each format without parsing the entire message (as in TLV). 140 h. MUST support sending multiple instances of the same format within 141 the same packet. 142 i. MUST allow formats to contain raw binary, UTF-8, UTF-16, or UTF- 143 32 content. 144 j. Must support formats which contain human-readable text. Such 145 text SHOULD specify the appropriate language. 146 k. MUST be extensible/flexible enough to support a future 147 descriptive location format. 149 Spatial Location Protocol (SloP) Requirements July 2000 151 l. Formats which tend to be large SHOULD support a simple 152 compression mechanism. 153 m. Both client and server MUST be able to send and receive formats 154 larger than a single packet. 156 6. Representation Negotiation 158 The protocol must: 159 a. Provide a mechanism for the server to inform the client which 160 representations it supports. Such a mechanism must be able to be 161 invoked prior to the first location report. 162 b. Provide a mechanism for the client to select which of said 163 representations it prefers. 164 c. Provide the capability to provide reports in any representation 165 d. Provide that following such selection, reports are provided by 166 the server in the format chosen by the client. 167 e. Provide a mechanisms for the client to specify the need for 168 periodic position updates. 169 f. Provide a mechanism for the client and server to agree upon 170 periodic position updates. 172 7. Server Discovery 174 a. There SHALL be a server discovery mechanism for a client to find 175 the appropriate server for a given target. 176 b. The discovery mechanism SHALL work across domains. It SHOULD use 177 widely deployed mechanisms such as DNS. It SHALL permit server 178 locations to be changed with TTLs ranging from minutes to months. 179 c. Targets SHALL be identified with an identifier. The target 180 identifier SHALL be unique within the domain of the server. 181 d. Servers SHALL be identified by an identifier. Server names SHALL 182 be globally unique. A URI of the form slop:haitao-tangs- 183 phone@airtouch.com would be an appropriate way to identify a 184 target, using the DNS to find the server. 185 e. Clients MUST be able to perform DNS A and SRV lookups, and may 186 support manual configuration and/or other methods to resolve the 187 IP address of a suitable slop server in an unqualified domain. 188 f. Translator services should be distinguishable from other servers 189 during discovery. 190 g. It is desirable that translator capabilities (supported formats) 191 can be determined during discovery. 193 8. Transport 195 a. The protocol SHALL support UDP transport with retry timers for 196 reliability. 197 b. The protocol SHOULD support TCP as an optional transport. 198 c. The protocol MAY support RTP and/or SCTP as optional transports 200 Spatial Location Protocol (SloP) Requirements July 2000 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 207 DiffServ QoS classes. 209 9. Security 211 The protocol must: 212 a. Provide a mandatory-to-implement, optional-to-use authentication 213 mechanism from client to server and from server to client. The 214 mechanism should allow a choice in the algorithm(s) used. 215 b. Specify how such a mechanism shall be used in the presence of 216 firewalls and Network Address Translation (NAT) between client 217 and server. 218 c. Include mechanisms to allow subsequent location policy decisions 219 to be based on (possibly multiple) factors in addition to the 220 identity (or anonymity) or the client, e.g. authentication 221 mechanism, group membership(s), class-of-user, etc. 222 d. Provide a mandatory-to-implement, optional-to-use data integrity 223 and data origin authentication mechanism for all data. The 224 mechanism should allow a choice in the algorithm(s) used. 225 e. Provide a mandatory-to-implement, optional-to-use data 226 confidentiality mechanism. The mechanism should allow a choice in 227 the algorithm(s) used. 228 f. Not unnecessarily degrade a client's expectations of privacy. 229 g. Support anonymous use, as well as authenticated use. 231 Anonymous use MAY require the server(s) to be able to associate 232 location with the same (anonymous) client over time. 233 h. Where possible make use of existing, proven security mechanisms 234 (e.g. TLS, CMS, IPsec), in particular with respect to 235 cryptographic transforms. 236 i. Specify a mechanism for extending the security mechanism for 237 additional capability. 239 10. Policy 241 The protocol must: 242 a. Provide a mandatory-to-implement, optional-to-use _Policy 243 Enforcement Point_ mechanism. 244 b. Provide an optional _Policy Decision Point_ mechanism. 245 c. Specify how servers obtain policy from a policy storage facility 246 if the Policy Decision Point mechanism is implemented. 247 d. Specify a _Policy Information Base_. 248 e. Provide a mechanism to restrict the information in reports by: 249 1. Accuracy of location 250 2. Frequency of report generation 251 3. Representation format 253 Spatial Location Protocol (SloP) Requirements July 2000 255 4. Identity/class of report-requestor 256 f. Specify the way that the PIB and class-of-user is used to 257 restrict location information reported by interpreting policy 258 selected by class of user. 260 11. References 262 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 263 9, RFC 2026, October 1996. 265 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 266 Levels", BCP 14, RFC 2119, March 1997 268 13. Author's Addresses 270 Brian Rosen 271 Marconi 272 1000 FORE Drive 273 Phone: +1 724 742 6826 274 Email: brian.rosen@marconi.com 276 Jose Costa-Requena 277 Nokia 278 Email: Jose.Costa-Requena@nokia.com 280 Mari Korkea-Aho 281 Nokia 282 Email: mari.korkea-aho@nokia.com 284 Mika Ylianttila 285 Centre for Wireless Communications 286 PL 4500, Tutkijantie 2 E, FIN-90014 287 University of Oulu, Finland 288 Email: over@ees2.oulu.fi 290 Rohan Mahy 291 Cisco Systems 292 170 W Tasman Dr, MS: SJCI/2/3 293 San Jose, CA 95134 294 +1 408 526 8570 295 rohan@cisco.com 297 Kenji Takahashi 298 Information Sharing Platform Laboratories 299 NTT 300 3-9-11 Midoricho 301 Musashino, Tokyo 180-8585 Japan 303 Spatial Location Protocol (SloP) Requirements July 2000 305 Phone: +81 422 59 6668 306 e-mail: kt@nttlabs.com 308 Stephen Farrell 309 Baltimore Technologies 310 61 Fitzwilliam Lane 311 Dublin 2. Ireland 312 Phone: +353 1 647 7406 313 email: stephen.farrell@baltimore.ie 315 14. Full Copyright Statement 317 "Copyright (C) The Internet Society (date). All Rights Reserved. 318 This document and translations of it may be copied and furnished to 319 others, and derivative works that comment on or otherwise explain it 320 or assist in its implmentation may be prepared, copied, published 321 and distributed, in whole or in part, without restriction of any 322 kind, provided that the above copyright notice and this paragraph 323 are included on all such copies and derivative works. However, this 324 document itself may not be modified in any way, such as by removing 325 the copyright notice or references to the Internet Society or other 326 Internet organizations, except as needed for the purpose of 327 developing Internet standards in which case the procedures for 328 copyrights defined in the Internet Standards process must be 329 followed, or as required to translate it into