idnits 2.17.1
draft-winterbottom-geopriv-held-identity-extensions-07.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 19.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 695.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 706.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 713.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 719.
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
-- 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 (November 3, 2008) is 5653 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)
== Unused Reference: 'RFC3986' is defined on line 578, but no explicit
reference was found in the text
== Unused Reference: 'I-D.ietf-ecrit-phonebcp' is defined on line 596, but
no explicit reference was found in the text
== Unused Reference: 'RFC3966' is defined on line 619, but no explicit
reference was found in the text
== Outdated reference: A later version (-16) exists of
draft-ietf-geopriv-http-location-delivery-10
== Outdated reference: A later version (-10) exists of
draft-ietf-geopriv-l7-lcp-ps-08
** Downref: Normative reference to an Informational draft:
draft-ietf-geopriv-l7-lcp-ps (ref. 'I-D.ietf-geopriv-l7-lcp-ps')
** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234)
== Outdated reference: A later version (-20) exists of
draft-ietf-ecrit-phonebcp-05
== Outdated reference: A later version (-06) exists of
draft-thomson-geopriv-held-measurements-03
-- Obsolete informational reference (is this intentional?): RFC 2434
(Obsoleted by RFC 5226)
-- Obsolete informational reference (is this intentional?): RFC 3825
(Obsoleted by RFC 6225)
Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 10 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: May 7, 2009 H. Tschofenig
6 Nokia Siemens Networks
7 R. Barnes
8 BBN Technologies
9 November 3, 2008
11 HELD Identity Extensions
12 draft-winterbottom-geopriv-held-identity-extensions-07
14 Status of this Memo
16 By submitting this Internet-Draft, each author represents that any
17 applicable patent or other IPR claims of which he or she is aware
18 have been or will be disclosed, and any of which he or she becomes
19 aware will be disclosed, in accordance with Section 6 of BCP 79.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF), its areas, and its working groups. Note that
23 other groups may also distribute working documents as Internet-
24 Drafts.
26 Internet-Drafts are draft documents valid for a maximum of six months
27 and may be updated, replaced, or obsoleted by other documents at any
28 time. It is inappropriate to use Internet-Drafts as reference
29 material or to cite them other than as "work in progress."
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/ietf/1id-abstracts.txt.
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html.
37 This Internet-Draft will expire on May 7, 2009.
39 Abstract
41 When a Location Information Server receives a request for location
42 information (using the locationRequest message), described in the
43 base HTTP Enabled Location Delivery (HELD) specification, it uses the
44 source IP address of arriving message as a pointer to the location
45 determination process. This is sufficient in environments where an
46 Target's location can be determined based on its IP address.
48 Two additional use cases are addresses by this document. In the
49 first, the source IP address in the request is not the only
50 identifier for the Target. In the second, an entity other than the
51 Target requests the Target's location.
53 This document extends the HELD protocol to allow the location request
54 message to carry additional identifiers assisting the location
55 determination process. It defines a set of URIs for Target
56 identifiers and an XML containment schema. This extension is used in
57 conjunction with HELD to provide Target identification, and set of
58 criteria of when to use this extensions are provided. Examples and
59 usage in HELD message syntax are also shown.
61 Table of Contents
63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
65 3. Identity Extension Details . . . . . . . . . . . . . . . . . . 6
66 3.1. URI Definitions . . . . . . . . . . . . . . . . . . . . . 6
67 3.1.1. MAC Address URI . . . . . . . . . . . . . . . . . . . 6
68 3.1.2. IP Address URIs . . . . . . . . . . . . . . . . . . . 6
69 3.2. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7
70 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10
71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
72 5.1. Location Configuration Protocol Requests . . . . . . . . . 12
73 5.2. Third Party Requests . . . . . . . . . . . . . . . . . . . 12
74 5.3. Distinguishing LCP Requests from Third Party Requests . . 13
75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
76 6.1. URN Sub-Namespace Registration for
77 urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 14
78 6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 14
79 6.3. Identifier 'type' Attribute values . . . . . . . . . . . . 15
80 6.4. URI Type Attribute Values . . . . . . . . . . . . . . . . 15
81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
83 8.1. Normative references . . . . . . . . . . . . . . . . . . . 18
84 8.2. Informative references . . . . . . . . . . . . . . . . . . 18
85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
86 Intellectual Property and Copyright Statements . . . . . . . . . . 21
88 1. Introduction
90 Protocols for requesting and providing location information require a
91 way for the requestor to specify the location that should be
92 returned. In a location configuration protocol (LCP), the location
93 being requested is the requestor's location. This fact can make the
94 problem of identifying the Target simpler for LCPs, since IP
95 datagrams that carry the request already carry an identifier for the
96 Target, namely the source IP address of an incoming request.
97 Existing LCPs, such as HELD [I-D.ietf-geopriv-http-location-delivery]
98 and DHCP ([RFC3825], [RFC4776]) rely on the source IP address, and
99 possibly lower-layer identifiers to identify a Target.
101 Aside from the datagrams that form a request, a location information
102 server (LIS) does not necessarily have access to information that
103 could further identify the Target of the request. In some
104 circumstances, as shown in [I-D.ietf-geopriv-l7-lcp-ps], additional
105 identification information can be included in a request to identify a
106 Target.
108 This document extends the HELD protocol to support the inclusion of
109 additional identifiers for the Target in HELD location requests. The
110 identifiers are defined as URIs that include a range of different
111 types of identification information. Finally, an XML schema is
112 defined that provides a structure for including these identifiers in
113 HELD requests.
115 An important characteristic of this addition to the HELD protocol is
116 that is also expands the potential scope of HELD beyond that of an
117 LCP. The scope of an LCP is limited to the interaction between a
118 Target and a LIS. That is, an LCP is limited to the Target
119 retrieving information about their own location. With this addition,
120 third party location recipients (LRs) are able to make requests that
121 include identifiers to retrieve location information about a
122 particular Target.
124 The usage of HELD for purposes beyond the Target-LIS interaction
125 obviously introduces a new set of privacy concerns. In an LCP, the
126 requester is implicitly authorized to access the request location
127 information, because it is their own location. In contrast, when a
128 third party LR requests a Target's location, the LR MUST be
129 explicitly authorized. Establishing appropriate authorization and
130 other related privacy concerns are discussed in Section 4.
132 2. Terminology
134 This document reuses the term Target, as defined in [RFC3693].
136 This document uses the term Location Information Server, LIS as
137 described in [I-D.ietf-geopriv-l7-lcp-ps].
139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
141 document are to be interpreted as described in [RFC2119].
143 3. Identity Extension Details
145 This section defines the details of the schema extension for HELD to
146 support the inclusion of a Target identity in the form of a URI or
147 typed-token. A set of URI definitions that can be used to specify
148 these identities is also provided.
150 3.1. URI Definitions
152 The URIs defined in this section are designed to identify a Target;
153 they do not identify measurements or sighting data associated with a
154 Target, such as the switch and port information to which the Target
155 is attached. This information may, for example, be acquired using
156 DHCP relay information [RFC3046] or LLDP [LLDP]. Device measurements
157 and sighting data are described in
158 [I-D.thomson-geopriv-held-measurements]. The identity provided may
159 be transitory, such as an IP address that is leased from a DHCP
160 server pool.
162 The URIs in the following sub-sections are defined using ABNF
163 (augmented Backus-Naur form) described in [RFC2234].
165 3.1.1. MAC Address URI
167 A MAC URI represents the media access control address of the Device,
168 as defined in the IEEE 802 series of specifications. The ABNF for
169 this URI type is defined as:
171 mac-uri = "mac:" 2*2HEXDIG 5*5macdig
172 macdig = "-" 2*2HEXDIG
174 MAC URIs can be used in the same manner as is suggested by the
175 undefined "mac:" URIs used in examples in RFC 4479 [RFC4479]. An
176 example of its use is provided in Figure 3.
178 3.1.2. IP Address URIs
180 This section provides the ABNF for IP version 4 and IP version 6
181 URIs. One application of this URI scheme is described in
182 [I-D.ietf-geopriv-l7-lcp-ps], where an outbound SIP proxy needs to
183 make location requests to a LIS on behalf of a Target because, for
184 some reason, the necessary information was not provided by the
185 Target.
187 ip-uri = "ip:" ipv4 / ipv6
188 ipv4 = "IPv4+" IPv4address ; from RFC 3986
189 ipv6 = "IPv6+" IPv6address ; from RFC 3986
190 The definitions for "IPv4address" and "IPv6address" are taken from
191 [RFC3986].
193 An example of a location request including a URI in this form to
194 identify the Target device is shown in Figure 1.
196
198 geodetic
199
200 ip:IPv4+192.0.2.5
201
202
204 Figure 1: HELD Location Request Using an IP Address
206 Note that the URI types are not case sensitive and the iP:ipv4+
207 192.0.2.5 is still a valid URI.
209 3.2. Schema
211 This section defines a schema that is used to provide Target
212 identifiers in a HELD location request.
214
215
222
224
225
226
227
229
230
231
233
235
236
237
238
240
241
242
244
246
247
248
250
252
253
255
257
259 Figure 2: Schema
261 The schema provided in Figure 2 allows a URI and/or token to be
262 provided so that a Target can identify itself by more than just its
263 IP address. The URI can also include an optional "type" attribute so
264 that URIs that might otherwise look the same can be distinguished
265 based on their usage.
267 For example sip:callee@example.com or sip:callee@example.com
270 An IANA registry is established for defining uri token types, and
271 this defined in Section 6.4.
273 When the element is used the "type" attribute is
274 mandatory as it tells the LIS or receiving entity how to interpret
275 the identifier. An IANA registry is established for the central
276 repository for recognized identifier types. The set of initial types
277 is provided in Section 6.3.
279 A HELD location request sent by a device using the schema shown in
280 Figure 2 to provide its identity as a MAC URI would look similar to
281 Figure 3.
283
285 geodetic
286
287 mac:01-ab-34-ef-69-0c
288
289
291 Figure 3: HELD Location Request URI example
293 Similarly a Target identifying itself using its DHCP client
294 identifier (DHCP option 61 in [RFC2132]) in a location request to a
295 LIS would send something similar to Figure 4.
297
299 geodetic
300
301 035552764
302
303
305 Figure 4: HELD Location Request Identifier example
307 4. Privacy Considerations
309 A location configuration protocol has a very simple privacy model.
310 Because the requester is also the Target, it can be assumed that
311 providing that requester with location information is allowed. Such
312 a policy makes the simple assumption that as the subject of the
313 location information, the Target is also permitted access to that
314 information. In effect, an LCP server (that is, the LIS) follows a
315 single rule policy that states that the Target is the only authorized
316 Location Recipient.
318 Note: HELD explicitly takes the position that the Target is a Device
319 and not a person. For the purpose of the discussion in this
320 section, the two are considered one and the same.
322 When the identity extensions defined above are used by the Target to
323 augment an LCP query, this default "LCP policy" remains the relevant
324 policy, and the security and privacy considerations of the base HELD
325 protocol [I-D.ietf-geopriv-http-location-delivery] apply. The only
326 augmentation required is that if the LCP policy is to be applied, the
327 LIS MUST authenticate that the requested identity is in fact that of
328 the requestor, and MUST deny access to location if this
329 authentication fails.
331 The LCP policy does not allow requests made by third parties. If a
332 LIS permits requests from third parties using identity extensions, it
333 assumes the rule of a Location Server (LS). HELD becomes a more
334 general location request protocol--a "using protocol" by the
335 definitions in [RFC3693]--and the privacy considerations for using
336 protocols apply. As a Location Server, the LIS MUST explicitly
337 authorize requests according to the policies that are provided by
338 Rule Makers, including the Target. This includes authentication of
339 requesters where required by the authorization policies.
341 An organization that provides a LIS that allows third party requests
342 SHOULD provide a means for a Rule Maker to specify authorization
343 policies before allowing third party requests for that Target's
344 location. Until an authorization policy is established, the LIS MUST
345 reject requests by third parties.
347 For a network operator, authorization might be a manual process, an
348 explicit part of the terms of service for the network, or an
349 automated system that accepts formal authorization policies (see
350 [RFC4745], [RFC4825]). This document does not mandate any particular
351 mechanism for establishing an authorization policy.
353 When the LIS is operated by the Target's access network, the
354 relationship between the Target and the LIS can be transient.
356 However, the process of establishing network access usually results
357 in a form of agreement between the Target and the network provider.
358 This process offers a natural vehicle for establishing location
359 privacy policies.
361 5. Security Considerations
363 The security considerations in
364 [I-D.ietf-geopriv-http-location-delivery] describe the use of TLS for
365 server authentication, confidentiality and protection from
366 modification. These protections apply to both LCP requests and the
367 requests made by third parties.
369 5.1. Location Configuration Protocol Requests
371 Requests made by a Device (or Target) in the context of a location
372 configuration protocol are covered by the same set of protections
373 offered by HELD. All the security considerations for HELD apply.
375 Identity information provided by the Device is private data that
376 might be sensitive. The Device provides this information in the
377 expectation that it assists the LIS in providing the Device a
378 service. The LIS MUST NOT use identity information for any other
379 purpose other than serving the request that includes that
380 information.
382 Falsification of identification information could be used by
383 malicious Devices to gain access to location information for others,
384 or to acquire false location information. For location
385 configuration, the LIS MUST ensure that claimed identity information
386 belongs to the requester before relying upon it. If this
387 verification cannot be performed, the LIS MUST treat the request as
388 if it were a third party request.
390 Note: This might seem to negate much of the advantage provided by
391 the inclusion of identity parameters for the LCP case. However,
392 checking that the identity information is correct is generally
393 more feasible than acquiring the information in the first place.
395 For example, a MAC address provided by a target device can be
396 verified by performing a DHCP lease-query ([RFC4388]). Identity
397 extensions such as tel: URIs and hostnames can be validated using
398 network services such as the DNS, ENUM, LDAP and SIP registrars.
400 5.2. Third Party Requests
402 Requests from third parties have the same requirements for server
403 authentication, confidentiality and protection from modification as
404 LCP requests. However, because the third party needs to be
405 authorized, the requester MUST be authenticated by the LIS. The LIS
406 MUST NOT provide location information to unauthorized requesters.
408 A LIS that allows requests from third parties MUST support TLS client
409 authentication.
411 More detail on the privacy implications of third party requests are
412 covered in Section 4.
414 5.3. Distinguishing LCP Requests from Third Party Requests
416 There is a risk that a LIS that supports both LCP requests as well as
417 requests from third parties could leak information. To successfully
418 exploit this leak, a third party could convince the server that its
419 request is an LCP request and that the identity information it
420 provides indeed belongs to it. This could mean that the third party
421 is exempted from the mandatory authorization process.
423 A LIS that only provides LCP access to Targets is subject to the same
424 attack. If a Target can provide false identification information
425 that is accepted by the LIS, it can effectively act as an authorized
426 third party.
428 This is limited by the ability of the LIS to detect falsified
429 identity information. Implementations need to take care to verify
430 identity information as described in Section 5.1.
432 For all requests, the LIS MUST ensure that the requester is
433 authorized to receive location information for the specified Target
434 before providing that information.
436 6. IANA Considerations
438 This document registers an XML namespace and schema with IANA in
439 accordance with guidelines in [RFC3688]. It also creates a new
440 registry for device identity types, and stipulates how new types are
441 to be added.
443 6.1. URN Sub-Namespace Registration for
444 urn:ietf:params:xml:ns:geopriv:held:id
446 This section registers a new XML namespace,
447 "urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in
448 [RFC3688].
450 URI: urn:ietf:params:xml:ns:geopriv:held:id
452 Registrant Contact: IETF, GEOPRIV working group,
453 (geopriv@ietf.org), James Winterbottom
454 (james.winterbottom@andrew.com).
456 XML:
458 BEGIN
459
460
462
463
464 HELD Device Identity Extensions
465
466
467 Namespace for HELD Device Identity Extensions
468 urn:ietf:params:xml:ns:geopriv:held:id
469 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
470 with the RFC number for this specification.]]
471 See RFCXXXX.
472
473
474 END
476 6.2. XML Schema Registration
478 This section registers an XML schema as per the guidelines in
479 [RFC3688].
481 URI: urn:ietf:params:xml:schema:geopriv:held:id
483 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
484 James Winterbottom (james.winterbottom@andrew.com).
486 Schema: The XML for this schema can be found as the entirety of
487 Figure 2 of this document.
489 6.3. Identifier 'type' Attribute values
491 This document requests that the IANA create a new registry for
492 identifier 'type' attribute values. These are text strings that
493 clarify how the value identifies the Device. Referring to [RFC2434]
494 this registry operates under the "Expert Review" rule.
496 The following identifier types are registered as part of this memo:
498 dhcpClientId: The DHCP client identifier as defined by DHCP option
499 61 in [RFC2132]
501 msisdn: The Mobile Station International Subscriber Dial Number.
502 This is an E.164 number made up of 6 to 15 digits
504 imsi: The International Mobile Subscriber identifier. A unique
505 identifier for GSM or UMTS mobile terminal made up of 6 to 15
506 digits that identify the country code, the network code and
507 device.
509 imei: The International Mobile Equipment identifier. This is an
510 electronic serial number for a mobile device and is consists of up
511 to 15 digits
513 min: Mobile Identification Number. A unique equipment identifier
514 assigned to CDMA handsets.
516 mdn: Mobile Dial Number. An E.164 number made up of 6 to 15 digits.
518 hostname: The hostname or FQDN of the device.
520 directoryNumber: The directory number of the device.
522 6.4. URI Type Attribute Values
524 This document requests that the IANA create a new registry for uri
525 'type' attribute values. These are text strings that clarify what a
526 URI actually identifies, and MUSt include the URI scheme to which the
527 type applies. Referring to [RFC2434] this registry operates under
528 the "Expert Review" rule.
530 The following identifier types are registered as part of this memo:
532 aor: The SIP address of record as defined [RFC3261]. Applies to
533 'sip:', 'sips:', 'pres:'
535 gruu: The Globally Routable User Agent URI (GRUU) as defined in
536 [I-D.ietf-sip-gruu]. Applies to 'sip:', 'sips:'
538 7. Acknowledgements
540 The authors wish to thank the NENA VoIP location working group for
541 their assistance in the definition of the schema used in this
542 document. Special thanks go to Barbara Stark, Guy Caron, Nadine
543 Abbott, Jerome Grenier and Martin Dawson. Thanks also to Bob Sherry
544 for requesting that URI-types be supported which led to the typedURI
545 form. Thanks to Adam Muhlbauer and Eddy Corbett for providing
546 further corrections.
548 8. References
550 8.1. Normative references
552 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
553 Requirement Levels", BCP 14, RFC 2119, March 1997.
555 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
556 January 2004.
558 [I-D.ietf-geopriv-http-location-delivery]
559 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
560 "HTTP Enabled Location Delivery (HELD)",
561 draft-ietf-geopriv-http-location-delivery-10 (work in
562 progress), October 2008.
564 [I-D.ietf-geopriv-l7-lcp-ps]
565 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
566 Location Configuration Protocol; Problem Statement and
567 Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in
568 progress), June 2008.
570 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
571 Specifications: ABNF", RFC 2234, November 1997.
573 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
574 A., Peterson, J., Sparks, R., Handley, M., and E.
575 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
576 June 2002.
578 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
579 Resource Identifier (URI): Generic Syntax", STD 66,
580 RFC 3986, January 2005.
582 [I-D.ietf-sip-gruu]
583 Rosenberg, J., "Obtaining and Using Globally Routable User
584 Agent (UA) URIs (GRUU) in the Session Initiation Protocol
585 (SIP)", draft-ietf-sip-gruu-15 (work in progress),
586 October 2007.
588 8.2. Informative references
590 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
591 J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
593 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
594 Extensions", RFC 2132, March 1997.
596 [I-D.ietf-ecrit-phonebcp]
597 Rosen, B. and J. Polk, "Best Current Practice for
598 Communications Services in support of Emergency Calling",
599 draft-ietf-ecrit-phonebcp-05 (work in progress),
600 July 2008.
602 [I-D.thomson-geopriv-held-measurements]
603 Thomson, M. and J. Winterbottom, "Using Device-provided
604 Location-Related Measurements in Location Configuration
605 Protocols", draft-thomson-geopriv-held-measurements-03
606 (work in progress), October 2008.
608 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
609 IANA Considerations Section in RFCs", BCP 26, RFC 2434,
610 October 1998.
612 [LLDP] IEEE, "802.1AB, IEEE Standard for Local and Metropolitan
613 area networks, Station and Media Access Control
614 Connectivity Discovery", June 2005.
616 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
617 RFC 3046, January 2001.
619 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
620 RFC 3966, December 2004.
622 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
623 July 2006.
625 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration
626 Protocol (DHCP) Leasequery", RFC 4388, February 2006.
628 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
629 Configuration Protocol Option for Coordinate-based
630 Location Configuration Information", RFC 3825, July 2004.
632 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
633 Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
635 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
636 Polk, J., and J. Rosenberg, "Common Policy: A Document
637 Format for Expressing Privacy Preferences", RFC 4745,
638 February 2007.
640 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
641 (DHCPv4 and DHCPv6) Option for Civic Addresses
642 Configuration Information", RFC 4776, November 2006.
644 Authors' Addresses
646 James Winterbottom
647 Andrew Corporation
648 PO Box U40
649 University of Wollongong, NSW 2500
650 AU
652 Email: james.winterbottom@andrew.com
654 Martin Thomson
655 Andrew Corporation
656 PO Box U40
657 University of Wollongong, NSW 2500
658 AU
660 Email: martin.thomson@andrew.com
662 Hannes Tschofenig
663 Nokia Siemens Networks
664 Linnoitustie 6
665 Espoo 02600
666 Finland
668 Phone: +358 (50) 4871445
669 Email: Hannes.Tschofenig@gmx.net
670 URI: http://www.tschofenig.priv.at
672 Richard Barnes
673 BBN Technologies
674 9861 Broken Land Pkwy, Suite 400
675 Columbia, MD 21046
676 USA
678 Phone: +1 410 290 6169
679 Email: rbarnes@bbn.com
681 Full Copyright Statement
683 Copyright (C) The IETF Trust (2008).
685 This document is subject to the rights, licenses and restrictions
686 contained in BCP 78, and except as set forth therein, the authors
687 retain all their rights.
689 This document and the information contained herein are provided on an
690 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
691 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
692 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
693 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
694 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
695 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
697 Intellectual Property
699 The IETF takes no position regarding the validity or scope of any
700 Intellectual Property Rights or other rights that might be claimed to
701 pertain to the implementation or use of the technology described in
702 this document or the extent to which any license under such rights
703 might or might not be available; nor does it represent that it has
704 made any independent effort to identify any such rights. Information
705 on the procedures with respect to rights in RFC documents can be
706 found in BCP 78 and BCP 79.
708 Copies of IPR disclosures made to the IETF Secretariat and any
709 assurances of licenses to be made available, or the result of an
710 attempt made to obtain a general license or permission for the use of
711 such proprietary rights by implementers or users of this
712 specification can be obtained from the IETF on-line IPR repository at
713 http://www.ietf.org/ipr.
715 The IETF invites any interested party to bring to its attention any
716 copyrights, patents or patent applications, or other proprietary
717 rights that may cover technology that may be required to implement
718 this standard. Please address the information to the IETF at
719 ietf-ipr@ietf.org.