idnits 2.17.1
draft-winterbottom-geopriv-held-identity-extensions-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 15.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 474.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 485.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 492.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 498.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Too long document name: The document name (without revision number),
'draft-winterbottom-geopriv-held-identity-extensions', is 51 characters
long, but may be at most 50 characters
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
-- The document has examples using IPv4 documentation addresses according
to RFC6890, but does not use any IPv6 documentation addresses. Maybe
there should be IPv6 examples, too?
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
== Line 149 has weird spacing: '...dDevice xmlns...'
-- 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.)
-- The document date (October 24, 2007) is 6022 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-16) exists of
draft-ietf-geopriv-http-location-delivery-02
== Outdated reference: A later version (-10) exists of
draft-ietf-geopriv-l7-lcp-ps-05
** Downref: Normative reference to an Informational draft:
draft-ietf-geopriv-l7-lcp-ps (ref. 'I-D.ietf-geopriv-l7-lcp-ps')
== Outdated reference: A later version (-06) exists of
draft-thomson-geopriv-held-measurements-00
** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234)
** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)
Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Geopriv J. Winterbottom
3 Internet-Draft M. Thomson
4 Intended status: Standards Track Andrew Corporation
5 Expires: April 26, 2008 October 24, 2007
7 HELD Device identity Extensions
8 draft-winterbottom-geopriv-held-identity-extensions-03.txt
10 Status of this Memo
12 By submitting this Internet-Draft, each author represents that any
13 applicable patent or other IPR claims of which he or she is aware
14 have been or will be disclosed, and any of which he or she becomes
15 aware will be disclosed, in accordance with Section 6 of BCP 79.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as Internet-
20 Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on April 26, 2008.
35 Copyright Notice
37 Copyright (C) The IETF Trust (2007).
39 Abstract
41 This document defines a set of URIs for Device identities and a XML
42 containment schema. These can be used in conjunction with HELD to
43 provide Device identification beyond source IP Address. Examples and
44 usage in HELD message syntax are provided.
46 Table of Contents
48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
50 3. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
51 3.1. URI Definitions . . . . . . . . . . . . . . . . . . . . . 5
52 3.1.1. Ethernet MAC URI . . . . . . . . . . . . . . . . . . . 5
53 3.1.2. IP Address URIs . . . . . . . . . . . . . . . . . . . 5
54 3.2. Device Identity Schema . . . . . . . . . . . . . . . . . . 6
55 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
57 5.1. URN Sub-Namespace Registration for
58 urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 10
59 5.2. XML Schema Registration . . . . . . . . . . . . . . . . . 10
60 5.3. Identifier 'type' Attribute values . . . . . . . . . . . . 11
61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
63 7.1. Normative references . . . . . . . . . . . . . . . . . . . 13
64 7.2. Informative references . . . . . . . . . . . . . . . . . . 13
65 Appendix A. Alternatives . . . . . . . . . . . . . . . . . . . . 15
66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
67 Intellectual Property and Copyright Statements . . . . . . . . . . 17
69 1. Introduction
71 Protocols such as HELD [I-D.ietf-geopriv-http-location-delivery] need
72 to identify a device in order to perform some task. Basic HELD only
73 provides device identity through the IP address of the requesting
74 Target, while [I-D.ietf-geopriv-l7-lcp-ps] provides examples of where
75 this may be insufficent. This memo defines a set of URIs an a
76 containment schema that allow the specification of device identity
77 beyond source IP address and may be used with HELD and general
78 presence documents as described in [RFC4479].
80 2. Terminology
82 The key conventions and terminology used in this document are defined
83 as follows:
85 This document reuses the terms Device and Target, as defined in
86 [RFC3693].
88 This document uses the term Location Information Server, LIS as
89 described in [I-D.ietf-geopriv-l7-lcp-ps].
91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
93 document are to be interpreted as described in [RFC2119].
95 3. Details
97 The details of this memo consist of a simple schema extension for
98 HELD to support the inclusion of a device identity in the form of a
99 URI or typed-token, and a set of URI definitions that can be used for
100 device identities.
102 3.1. URI Definitions
104 The URIs defined in this section are designed to identify a device.
105 The URIs identify the Device, they do not identify measurements or
106 sighting data associated with a Device, such as the switch and port
107 information to which the Device is attached (which can be acquired
108 using DHCP relay information [RFC3046] or LLDP [LLDP]. Device
109 measurements and sighting data are described in
110 [I-D.thomson-geopriv-held-measurements]. The identity provided may
111 be transitory, such as an IP address that is leased from a DHCP
112 server pool, but it MUST uniquely identify a device within a network
113 at the time it is used.
115 The URIs in this section are defined using ABNF (augmented Backus-
116 Naur form) described in [RFC2234].
118 3.1.1. Ethernet MAC URI
120 This is the Ethernet hardware address of the device. The form of
121 this URI is used as example in [RFC4479] and this section provides
122 the ABNF for this URI type. An example of its use is provided in
123 Figure 5.
125 mac-uri = "mac:" 12*12HEXDIG
127 3.1.2. IP Address URIs
129 This section provides the ABNF for IP version 4 and IP version 6
130 URIs. One application of this URI scheme is described in
131 [I-D.ietf-geopriv-l7-lcp-ps], where an outbound SIP proxy needs to
132 make location requests to a LIS on-behalf-of a Device because, for
133 some reason, the necessary information was not provided by the
134 Device.
136 ip-uri = "ip:" ipv4 / ipv6
137 ipv4 = "IPv4+" IPv4-Address
138 IPv4-Address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
139 ipv6 = "IPv6+" hexpart [ ":" IPv4-Address ]
140 hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
141 hexseq = hex4 *( ":" hex4)
142 hex4 = 1*4HEXDIG
143 An example of a location request including a URI in this form to
144 identify the Target device is shown in Figure 3.
146
148 geodetic
149
150 ip:IPv4+192.0.2.5
151
152
154 Figure 3: HELD Location Request Using an IP Address
156 Note that the URI types are not case sensative and the iP:ipv4+
157 192.0.2.5 is still a valid URI.
159 3.2. Device Identity Schema
161 This section defines a schema that can be used to provide device
162 identities in a HELD location request.
164
165
172
174
175
176
177
179
180
181
183
185
186
187
188
190
191
192
194
196
197
198
200
202
203
205
207
209 Figure 4: Device identity schema
211 The schema provided in Figure 4 allows a URI and/or token to be
212 provided so a Device can identify itself by more than just its IP
213 address. The URI can also include an optional "type" attribute so
214 that URIs that might otherwise look the same can be distinguished
215 based on their usage.
217 For example sip:callee@example.com or sip:callee@example.com
220 When the element is used the "type" attribute is
221 mandatory as this tells the LIS or receiving entity how to interpret
222 the identifier. An IANA registry is established for the central
223 repository for recognized identifier types. The set of initial types
224 is provided in Section 5.3.
226 A HELD location request sent by a device using the schema shown in
227 Figure 4 to provide its identity as a mac URI would look similar to
228 Figure 5.
230
232 geodetic
233
234 mac:01ab34ef690c
235
236
238 Figure 5: HELD Location Request URI example
240 Similarly a device identifying itself using its DHCP client
241 identifier (DHCP option 61 in [RFC2132]) in a location request to a
242 LIS would send something similar to Figure 6.
244
246 geodetic
247
248 035552764
249
250
252 Figure 6: HELD Location Request Identifier example
254 4. Security Considerations
256 An Operator of a LIS that supports this schema extension needs to
257 ensure that location provided to nodes requesting location in this
258 manner are entitled to the location information being requested. In
259 some circumstances support of this schema extension will be
260 inappropriate and alternative measures will need to be employed.
262 5. IANA Considerations
264 This document registers an XML namespace and schema with IANA in
265 accordance with guidelines in [RFC3688]. It also creates a new
266 registry for device identity types, and stipulates how new types are
267 to be added.
269 5.1. URN Sub-Namespace Registration for
270 urn:ietf:params:xml:ns:geopriv:held:id
272 This section registers a new XML namespace,
273 "urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in
274 [RFC3688].
276 URI: urn:ietf:params:xml:ns:geopriv:held:id
278 Registrant Contact: IETF, GEOPRIV working group,
279 (geopriv@ietf.org), James Winterbottom
280 (james.winterbottom@andrew.com).
282 XML:
284 BEGIN
285
286
288
289
290 HELD Device Identity Extensions
291
292
293 Namespace for HELD Device Identity Extensions
294 urn:ietf:params:xml:ns:geopriv:held:id
295 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
296 with the RFC number for this specification.]]
297 See RFCXXXX.
298
299
300 END
302 5.2. XML Schema Registration
304 This section registers an XML schema as per the guidelines in
305 [RFC3688].
307 URI: urn:ietf:params:xml:schema:geopriv:held:id
309 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
310 James Winterbottom (james.winterbottom@andrew.com).
312 Schema: The XML for this schema can be found as the entirety of
313 Figure 4 of this document.
315 5.3. Identifier 'type' Attribute values
317 This document requests that the IANA create a new registry for
318 identifier 'type' attribute values. These are text strings that
319 clarify how the value identifies the Device. Referring to [RFC2434]
320 this registry operates under the "Expert Review" rule.
322 The following identifier types are registered as part of this memo:
324 o 'dhcpClientId' The DHCP client identifier as defined by DHCP
325 option 61 in [RFC2132]
327 o 'msisdn' The Mobile Station International Subscriber Dial Number.
328 This is an E.164 number made up of 6 to 15 digits
330 o 'imsi' The International Mobile Subscriber identifier. A unique
331 identifier for GSM or UMTS mobile terminal made up of 6 to 15
332 digits that identify the country code, the network code and
333 device.
335 o 'imei' The International Mobile Equipment identifier. This is an
336 electronic serial number for a mobile device and is consists of up
337 to 15 digits
339 o 'min' Mobile Identification Number. A unique equipment identifier
340 assigned to CDMA handsets.
342 o 'mdn' Mobile Dial Number. An E.164 number made up of 6 to 15
343 digits.
345 o 'hostname' The hostname or FQDN of the device.
347 6. Acknowledgements
349 The authors wish to thank the NENA VoIP location working group for
350 their assistance in the definition of the schema used in this
351 document. Special thanks go to Barbara Stark, Guy Caron, Nadine
352 Abbott, Jerome Grenier and Martin Dawson. Thanks also to Bob Sherry
353 for requesting that URI-types be supported which led to the typedURI
354 form.
356 7. References
358 7.1. Normative references
360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
361 Requirement Levels", BCP 14, RFC 2119, March 1997.
363 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
364 January 2004.
366 [I-D.ietf-geopriv-http-location-delivery]
367 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
368 "HTTP Enabled Location Delivery (HELD)",
369 draft-ietf-geopriv-http-location-delivery-02 (work in
370 progress), September 2007.
372 [I-D.ietf-geopriv-l7-lcp-ps]
373 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
374 Location Configuration Protocol; Problem Statement and
375 Requirements", draft-ietf-geopriv-l7-lcp-ps-05 (work in
376 progress), September 2007.
378 [I-D.thomson-geopriv-held-measurements]
379 Thomson, M. and J. Winterbottom, "Using Device-provided
380 Location Measurements in HELD",
381 draft-thomson-geopriv-held-measurements-00 (work in
382 progress), October 2007.
384 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
385 Specifications: ABNF", RFC 2234, November 1997.
387 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
388 IANA Considerations Section in RFCs", BCP 26, RFC 2434,
389 October 1998.
391 7.2. Informative references
393 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
394 J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
396 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
397 Extensions", RFC 2132, March 1997.
399 [LLDP] IEEE, "802.1AB, IEEE Standard for Local and Metropolitan
400 area networks, Station and Media Access Control
401 Connectivity Discovery", June 2005.
403 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
404 RFC 3046, January 2001.
406 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
407 RFC 3966, December 2004.
409 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
410 July 2006.
412 Appendix A. Alternatives
414 An alternative to providing the mobile identifiers as an
415 'type' they could be defined as URI types as shown below. This would
416 fit seeming well as other telephony device identifiers are already
417 specified using telephone URIs [RFC3966].
419 mobile-uri = "mob:" mobile-identifier
420 mobile-identifier = imsi / msisdn / imei / min / mdn
421 imsi = "imsi:" 6*15DIGIT
422 msisdn = "msisdn:" 6*15DIGIT
423 imei = "imei:" 1*15DIGIT
424 min = "min:" 1*15DIGIT
425 mdn = "mdn:" 6*15DIGIT
427 The URIs defined above allow an easy way for the Device to specify
428 this binding to a LIS by using a HELD location request. When the LIS
429 receives the location request in Figure 9 it is able to bind the
430 source IP address of the location request with the provided MSISDN.
432
434 geodetic
435
436 mob:msisdn:61448266004
437
438
440 Figure 9: HELD Location Request Using MSISDN
442 Authors' Addresses
444 James Winterbottom
445 Andrew Corporation
446 PO Box U40
447 University of Wollongong, NSW 2500
448 AU
450 Email: james.winterbottom@andrew.com
452 Martin Thomson
453 Andrew Corporation
454 PO Box U40
455 University of Wollongong, NSW 2500
456 AU
458 Email: martin.thomson@andrew.com
460 Full Copyright Statement
462 Copyright (C) The IETF Trust (2007).
464 This document is subject to the rights, licenses and restrictions
465 contained in BCP 78, and except as set forth therein, the authors
466 retain all their rights.
468 This document and the information contained herein are provided on an
469 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
470 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
471 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
472 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
473 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
474 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
476 Intellectual Property
478 The IETF takes no position regarding the validity or scope of any
479 Intellectual Property Rights or other rights that might be claimed to
480 pertain to the implementation or use of the technology described in
481 this document or the extent to which any license under such rights
482 might or might not be available; nor does it represent that it has
483 made any independent effort to identify any such rights. Information
484 on the procedures with respect to rights in RFC documents can be
485 found in BCP 78 and BCP 79.
487 Copies of IPR disclosures made to the IETF Secretariat and any
488 assurances of licenses to be made available, or the result of an
489 attempt made to obtain a general license or permission for the use of
490 such proprietary rights by implementers or users of this
491 specification can be obtained from the IETF on-line IPR repository at
492 http://www.ietf.org/ipr.
494 The IETF invites any interested party to bring to its attention any
495 copyrights, patents or patent applications, or other proprietary
496 rights that may cover technology that may be required to implement
497 this standard. Please address the information to the IETF at
498 ietf-ipr@ietf.org.
500 Acknowledgment
502 Funding for the RFC Editor function is provided by the IETF
503 Administrative Support Activity (IASA).