draft-ietf-geopriv-radius-lo-20.txt   draft-ietf-geopriv-radius-lo-21.txt 
GEOPRIV H. Tschofenig, Ed. GEOPRIV H. Tschofenig, Ed.
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Standards Track F. Adrangi Intended status: Standards Track F. Adrangi
Expires: May 5, 2009 Intel Expires: August 13, 2009 Intel
M. Jones M. Jones
A. Lior A. Lior
Bridgewater Bridgewater
B. Aboba B. Aboba
Microsoft Corporation Microsoft Corporation
November 1, 2008 February 9, 2009
Carrying Location Objects in RADIUS and Diameter Carrying Location Objects in RADIUS and Diameter
draft-ietf-geopriv-radius-lo-20.txt draft-ietf-geopriv-radius-lo-21.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 5, 2009. This Internet-Draft will expire on August 13, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
This document describes procedures for conveying access network This document describes procedures for conveying access network
ownership and location information based on a civic and geospatial ownership and location information based on a civic and geospatial
location format in Remote Authentication Dial In User Service location format in Remote Authentication Dial In User Service
(RADIUS) and Diameter. (RADIUS) and Diameter.
The distribution of location information is a privacy sensitive task. The distribution of location information is a privacy sensitive task.
Dealing with mechanisms to preserve the user's privacy is important Dealing with mechanisms to preserve the user's privacy is important
and addressed in this document. and addressed in this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Delivery Methods for Location Information . . . . . . . . . . 6 3. Delivery Methods for Location Information . . . . . . . . . . 7
3.1. Location Delivery based on Out-of-Band Agreements . . . . 6 3.1. Location Delivery based on Out-of-Band Agreements . . . . 7
3.2. Location Delivery based on Initial Request . . . . . . . . 7 3.2. Location Delivery based on Initial Request . . . . . . . . 8
3.3. Location Delivery based on Mid-Session Request . . . . . . 8 3.3. Location Delivery based on Mid-Session Request . . . . . . 9
3.4. Location Delivery in Accounting Messages . . . . . . . . . 12 3.4. Location Delivery in Accounting Messages . . . . . . . . . 13
4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Operator-Name Attribute . . . . . . . . . . . . . . . . . 14 4.1. Operator-Name Attribute . . . . . . . . . . . . . . . . . 15
4.2. Location-Information Attribute . . . . . . . . . . . . . . 17 4.2. Location-Information Attribute . . . . . . . . . . . . . . 18
4.3. Location-Data Attribute . . . . . . . . . . . . . . . . . 19 4.3. Location-Data Attribute . . . . . . . . . . . . . . . . . 20
4.3.1. Civic Location Profile . . . . . . . . . . . . . . . . 20 4.3.1. Civic Location Profile . . . . . . . . . . . . . . . . 21
4.3.2. Geospatial Location Profile . . . . . . . . . . . . . 21 4.3.2. Geospatial Location Profile . . . . . . . . . . . . . 22
4.4. Basic-Location-Policy-Rules Attribute . . . . . . . . . . 21 4.4. Basic-Location-Policy-Rules Attribute . . . . . . . . . . 22
4.5. Extended-Location-Policy-Rules Attribute . . . . . . . . . 23 4.5. Extended-Location-Policy-Rules Attribute . . . . . . . . . 24
4.6. Location-Capable Attribute . . . . . . . . . . . . . . . . 25 4.6. Location-Capable Attribute . . . . . . . . . . . . . . . . 26
4.7. Requested-Location-Info Attribute . . . . . . . . . . . . 28 4.7. Requested-Location-Info Attribute . . . . . . . . . . . . 29
5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 34 5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 35
6. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 36 6. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 37
7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 7. Security Considerations . . . . . . . . . . . . . . . . . . . 39
7.1. Communication Security . . . . . . . . . . . . . . . . . . 38 7.1. Communication Security . . . . . . . . . . . . . . . . . . 39
7.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 39 7.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 40
7.2.1. RADIUS Client . . . . . . . . . . . . . . . . . . . . 40 7.2.1. RADIUS Client . . . . . . . . . . . . . . . . . . . . 41
7.2.2. RADIUS Server . . . . . . . . . . . . . . . . . . . . 40 7.2.2. RADIUS Server . . . . . . . . . . . . . . . . . . . . 41
7.2.3. RADIUS Proxy . . . . . . . . . . . . . . . . . . . . . 41 7.2.3. RADIUS Proxy . . . . . . . . . . . . . . . . . . . . . 42
7.3. Identity Information and Location Information . . . . . . 41 7.3. Identity Information and Location Information . . . . . . 42
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
8.1. New Registry: Operator Namespace Identifier . . . . . . . 43 8.1. New Registry: Operator Namespace Identifier . . . . . . . 44
8.2. New Registry: Location Profiles . . . . . . . . . . . . . 44 8.2. New Registry: Location Profiles . . . . . . . . . . . . . 45
8.3. New Registry: Location-Capable Attribute . . . . . . . . . 45 8.3. New Registry: Location-Capable Attribute . . . . . . . . . 46
8.4. New Registry: Entity Types . . . . . . . . . . . . . . . . 46 8.4. New Registry: Entity Types . . . . . . . . . . . . . . . . 47
8.5. New Registry: Privacy Flags . . . . . . . . . . . . . . . 46 8.5. New Registry: Privacy Flags . . . . . . . . . . . . . . . 47
8.6. New Registry: Requested-Location-Info Attribute . . . . . 46 8.6. New Registry: Requested-Location-Info Attribute . . . . . 47
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.1. Normative References . . . . . . . . . . . . . . . . . . . 49 10.1. Normative References . . . . . . . . . . . . . . . . . . . 50
10.2. Informative References . . . . . . . . . . . . . . . . . . 49 10.2. Informative References . . . . . . . . . . . . . . . . . . 50
Appendix A. Matching with Geopriv Requirements . . . . . . . . . 52 Appendix A. Matching with Geopriv Requirements . . . . . . . . . 53
A.1. Distribution of Location Information at the User's A.1. Distribution of Location Information at the User's
Home Network . . . . . . . . . . . . . . . . . . . . . . . 52 Home Network . . . . . . . . . . . . . . . . . . . . . . . 53
A.2. Distribution of Location Information at the Visited A.2. Distribution of Location Information at the Visited
Network . . . . . . . . . . . . . . . . . . . . . . . . . 53 Network . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.3. Requirements matching . . . . . . . . . . . . . . . . . . 54 A.3. Requirements matching . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61
Intellectual Property and Copyright Statements . . . . . . . . . . 61
1. Introduction 1. Introduction
This document defines attributes within RADIUS and Diameter that can This document defines attributes within RADIUS and Diameter that can
be used to convey location-related information within authentication be used to convey location-related information within authentication
and accounting exchanges. and accounting exchanges.
Location information may be useful in a number of scenarios. Location information may be useful in a number of scenarios.
Wireless networks (including wireless LAN) are being deployed in Wireless networks (including wireless LAN) are being deployed in
public places such as airports, hotels, shopping malls, and coffee public places such as airports, hotels, shopping malls, and coffee
skipping to change at page 7, line 34 skipping to change at page 8, line 34
| Authentication | | | Authentication | |
| Success | | | Success | |
|<----------------------| | |<----------------------| |
| | | | | |
Figure 1: Location Delivery based on out-of-band Agreements Figure 1: Location Delivery based on out-of-band Agreements
3.2. Location Delivery based on Initial Request 3.2. Location Delivery based on Initial Request
If the RADIUS client provides a Location-Capable Attribute in the If the RADIUS client provides a Location-Capable Attribute in the
Access-Request, then the RADIUS server MAY challenge the RADIUS Access-Request, then the RADIUS server MAY request the RADIUS client
client for location information if it requires that information for for location information if it requires that information for
authorization, and location information was not provided in Access- authorization, and location information was not provided in Access-
Request. This exchange is shown in Figure 2. The inclusion of the Request. This exchange is shown in Figure 2. The inclusion of the
Location-Capable Attribute in an Access-Request message indicates Location-Capable Attribute in an Access-Request message indicates
that the NAS supports this specification and is capable of providing that the NAS is capable of providing location data in response to an
location in response to an Access-Challenge. The subsequent Access- Access-Challenge. The subsequent Access-Challenge message sent from
Challenge message sent from the RADIUS server to the NAS provides a the RADIUS server to the NAS provides a hint regarding the type of
hint regarding the type of desired location information attributes. desired location information attributes. The NAS treats the Basic-
The NAS treates the Basic-Location-Policy-Rules and Extended- Location-Policy-Rules and Extended-Location-Policy-Rules Attributes
Location-Policy-Rules Attributes as opaque data (e.g., it echoes as opaque data (e.g., it echoes these rules provided by the server
these rules provided by the server within the Access-Challenge back within the Access-Challenge back in the Access-Request). In the
in the Access-Request). In the shown message flow the location shown message flow the location attributes are then provided in the
attributes are then provided in the subsequent Access-Request subsequent Access-Request message. When evaluating this Access-
message. When receiving this Access-Request message the Request message the authorization procedure at the RADIUS server
authorization procedure at the RADIUS server might be based on a might be based on a number of criteria, including the newly defined
number of criteria, including the newly defined attributes listed in attributes listed in Section 4.
Section 4.
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
| | | Network | | RADIUS | | | | Network | | RADIUS |
| User | | Access | | Server | | User | | Access | | Server |
| | | Server | | | | | | Server | | |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
| | | | | |
| Authentication phase | | | Authentication phase | |
| begin | | | begin | |
|---------------------->| | |---------------------->| |
skipping to change at page 8, line 49 skipping to change at page 9, line 49
| |<---------------------------------| | |<---------------------------------|
| Authentication | | | Authentication | |
| Success | | | Success | |
|<----------------------| | |<----------------------| |
| | | | | |
Figure 2: Location Delivery based on Initial Request Figure 2: Location Delivery based on Initial Request
3.3. Location Delivery based on Mid-Session Request 3.3. Location Delivery based on Mid-Session Request
The on demand mid-session location delivery method utilizes the The on-demand mid-session location delivery method utilizes the
Change of Authorization Request (CoA-Request) message, defined in Change of Authorization Request (CoA-Request) message and the CoA-
[RFC5176]. At any time during the session the Dynamic Authorization NAK, defined in [RFC5176]. At any time during the session the
Client MAY send a CoA-Request containing session identification Dynamic Authorization Client MAY send a CoA-Request containing
attributes to the NAS (i.e., Dynamic Authorization Server). session identification attributes to the NAS (i.e., Dynamic
Authorization Server).
In order to enable the on-demand mid-session location delivery In order to enable the on-demand mid-session location delivery
method, the RADIUS server MUST return an instance of the Requested- method, the RADIUS server MUST return an instance of the Requested-
Location-Info Attribute with the 'FUTURE_REQUESTS' flag set and Location-Info Attribute with the 'FUTURE_REQUESTS' flag set and
instances of the Basic-Location-Policy-Rules and Extended-Location- instances of the Basic-Location-Policy-Rules and Extended-Location-
Policy-Rules Attributes in the Access-Accept message for the session. Policy-Rules Attributes in the Access-Accept message for the session.
Upon receipt of a CoA-Request message containing a Service-Type Upon receipt of a CoA-Request message containing a Service-Type
Attribute with value "Authorize Only" for the same session, the NAS Attribute with value "Authorize Only" for the same session, the NAS
MUST include location information and echo the previously received MUST include location information and echo the previously received
Basic-Location-Policy-Rules and Extended-Location-Policy-Rules Basic-Location-Policy-Rules and Extended-Location-Policy-Rules
Attributes in the subsequent Access-Request message. Attributes in the subsequent Access-Request message.
Upon receiving the Access-Request message containing the Service-Type Upon receiving the Access-Request message containing the Service-Type
Attribute with a value of Authorize-Only from the NAS, the RADIUS Attribute with a value of Authorize-Only from the NAS, the RADIUS
server responds with either an Access-Accept or an Access-Reject server responds with either an Access-Accept or an Access-Reject
message. message.
[RFC5176] is necessary when location information is needed on demand The use of dynamic authorization [RFC5176] is necessary when location
and cannot be obtained from accounting information in a timely information is needed on-demand and cannot be obtained from
fashion. accounting information in a timely fashion.
Figure 3 shows the above-described approach graphically. Figure 3 shows the above-described approach graphically.
+---------------+ +---------------+ +------+ +---------------+ +---------------+ +------+
| Dynamic | | Dynamic | |RADIUS| | Dynamic | | Dynamic | |RADIUS|
| Authorization | | Authorization | |Server| | Authorization | | Authorization | |Server|
| Server/NAS | | Client | | | | Server/NAS | | Client | | |
+---------------+ +---------------+ +------+ +---------------+ +---------------+ +------+
| | | | | |
| Access-Request | | | Access-Request | |
skipping to change at page 11, line 5 skipping to change at page 12, line 6
Figure 3: Location Delivery based on CoA with Service-Type 'Authorize Figure 3: Location Delivery based on CoA with Service-Type 'Authorize
Only' Only'
When the Dynamic Authorization Client wants to change the values of When the Dynamic Authorization Client wants to change the values of
the requested location information, or set the values of the the requested location information, or set the values of the
requested location information for the first time, it may do so requested location information for the first time, it may do so
without triggering a reauthorization. Assuming that the NAS had without triggering a reauthorization. Assuming that the NAS had
previously sent an Access-Request containing a Location-Capable previously sent an Access-Request containing a Location-Capable
Attribute, the DAC can send a CoA-Request to the NAS without a Attribute, the DAC can send a CoA-Request to the NAS without a
Service-Type Attribute, but including the NAS Identifiers and Session Service-Type Attribute, but including the NAS Identifiers and Session
identifers as per [RFC5176] and the Requested-Location-Info, Basic- identifiers as per [RFC5176] and the Requested-Location-Info, Basic-
Location-Policy-Rules and Extended-Location-Policy-Rules Attributes. Location-Policy-Rules and Extended-Location-Policy-Rules Attributes.
The Requested-Location-Info, Basic-Location-Policy-Rules and The Requested-Location-Info, Basic-Location-Policy-Rules and
Extended-Location-Policy-Rules Attributes MUST NOT be used for Extended-Location-Policy-Rules Attributes MUST NOT be used for
session identification. session identification.
Figure 4 shows this approach graphically. Figure 4 shows this approach graphically.
+---------------+ +---------------+ +------+ +---------------+ +---------------+ +------+
| Dynamic | | Dynamic | |RADIUS| | Dynamic | | Dynamic | |RADIUS|
| Authorization | | Authorization | |Server| | Authorization | | Authorization | |Server|
skipping to change at page 21, line 16 skipping to change at page 22, line 16
option, and the 'what' element are not included) are not put into the option, and the 'what' element are not included) are not put into the
Location field of the above-described RADIUS Location-Data Attribute. Location field of the above-described RADIUS Location-Data Attribute.
4.3.2. Geospatial Location Profile 4.3.2. Geospatial Location Profile
This section defines the geospatial location information profile This section defines the geospatial location information profile
corresponding to the value (1) indicated in the Code field of the corresponding to the value (1) indicated in the Code field of the
Location-Information Attribute. Geospatial location information is Location-Information Attribute. Geospatial location information is
encoded as an opaque object whereby the format is reused from the encoded as an opaque object whereby the format is reused from the
Section 2 of RFC 3825 Location Configuration Information (LCI) format Section 2 of RFC 3825 Location Configuration Information (LCI) format
[RFC3825]. starting with starting with the third octet (i.e., the [RFC3825] starting with the third octet (i.e., the code for the DHCP
code for the DHCP option and the length field is not included). option and the length field is not included).
4.4. Basic-Location-Policy-Rules Attribute 4.4. Basic-Location-Policy-Rules Attribute
The Basic-Location-Policy-Rules Attribute MAY be sent in an Access- The Basic-Location-Policy-Rules Attribute MAY be sent in an Access-
Request, Access-Accept, an Access-Challenge, a Change-of- Request, Access-Accept, an Access-Challenge, a Change-of-
Authorization and in an Accounting-Request message. Authorization and in an Accounting-Request message.
Policy rules control the distribution of location information. The Policy rules control the distribution of location information. The
obligation with respect to understanding and processing of the Basic- obligation with respect to understanding and processing of the Basic-
Location-Policy-Rules Attribute for RADIUS clients is to utilize a Location-Policy-Rules Attribute for RADIUS clients is to utilize a
skipping to change at page 28, line 45 skipping to change at page 29, line 45
Accounting-Request message but does not require it for computing Accounting-Request message but does not require it for computing
an authorization decision then the Access-Accept message MUST an authorization decision then the Access-Accept message MUST
include a Required-Info Attribute. This is typically the case include a Required-Info Attribute. This is typically the case
when location information is used only for billing. The RADIUS when location information is used only for billing. The RADIUS
client SHOULD attach location information, if available, to the client SHOULD attach location information, if available, to the
Accounting-Request (unless authorization policies dictate Accounting-Request (unless authorization policies dictate
something different). something different).
If the RADIUS server does not send a Requested-Location-Info If the RADIUS server does not send a Requested-Location-Info
Attribute then the RADIUS client MUST NOT attach location information Attribute then the RADIUS client MUST NOT attach location information
to messages towards the RADIUS server, unless an out-of-band to messages towards the RADIUS server. The user's authorization
agreement is in place. The user's authorization policies, if policies, if available, MUST be consulted by the RADIUS server before
available, MUST be consulted by the RADIUS server before requesting requesting location information delivery from the RADIUS client.
location information delivery from the RADIUS client.
Figure 6 shows a simple protocol exchange where the RADIUS server Figure 6 shows a simple protocol exchange where the RADIUS server
indicates the desire to obtain location information, namely civic indicates the desire to obtain location information, namely civic
location information of the user, to grant access. Since the location information of the user, to grant access. Since the
Requested-Location-Info Attribute is attached to the Access-Challenge Requested-Location-Info Attribute is attached to the Access-Challenge
the RADIUS server indicates that location information is required for the RADIUS server indicates that location information is required for
computing an authorization decision. computing an authorization decision.
+---------+ +---------+ +---------+ +---------+
| RADIUS | | RADIUS | | RADIUS | | RADIUS |
skipping to change at page 35, line 4 skipping to change at page 36, line 4
Figure 7: Table of Attributes Figure 7: Table of Attributes
The Error-Cause Attribute is defined in [RFC5176]. The Error-Cause Attribute is defined in [RFC5176].
The Location-Information and the Location-Data Attribute MAY appear The Location-Information and the Location-Data Attribute MAY appear
more than once. For example, if the server asks for civic and more than once. For example, if the server asks for civic and
geospatial location information two Location-Information Attributes geospatial location information two Location-Information Attributes
need to be sent. need to be sent.
The attributes defined in this document are not used in any messages The attributes defined in this document are not used in any messages
other than the onces listed in Figure 7. other than the ones listed in Figure 7.
This document requests IANA to allocate a new value from the Error- This document requests IANA to allocate a new value from the Error-
Cause registry with the semantic of 'Location-Info-Required'. Cause registry with the semantic of 'Location-Info-Required'.
6. Diameter RADIUS Interoperability 6. Diameter RADIUS Interoperability
When used in Diameter, the attributes defined in this specification When used in Diameter, the attributes defined in this specification
can be used as Diameter AVPs from the Code space 1-255 (RADIUS can be used as Diameter AVPs from the Code space 1-255 (RADIUS
attribute compatibility space). No additional Diameter Code values attribute compatibility space). No additional Diameter Code values
are therefore allocated. The data types and flag rules for the are therefore allocated. The data types and flag rules for the
skipping to change at page 48, line 49 skipping to change at page 49, line 49
working group. Therefore, the authors thank Henning Schulzrinne, working group. Therefore, the authors thank Henning Schulzrinne,
James Polk, John Morris, Allison Mankin, Randall Gellens, Andrew James Polk, John Morris, Allison Mankin, Randall Gellens, Andrew
Newton, Ted Hardie, Jon Peterson for their time to discuss a number Newton, Ted Hardie, Jon Peterson for their time to discuss a number
of issues with us. We thank Stephen Hayes for aligning this work of issues with us. We thank Stephen Hayes for aligning this work
with 3GPP activities. with 3GPP activities.
The RADEXT working group chairs, David Nelson and Bernard Aboba, The RADEXT working group chairs, David Nelson and Bernard Aboba,
provided several draft reviews and we would like to thank them for provided several draft reviews and we would like to thank them for
the help and their patience. the help and their patience.
Finally, we would like to thank Dan Romascanu, Glen Zorn, Jari Arkko, Finally, we would like to thank Dan Romascanu, Glen Zorn, Russ
Tim Polk, and Lars Eggert for the IETF Last Call comments, Derek Housley, Jari Arkko, Tim Polk, and Lars Eggert for the IETF Last Call
Atkins for his security area directorate review and Yoshiko Chong for comments, Derek Atkins for his security area directorate review and
spotting a bug in the IANA consideration section. Yoshiko Chong for spotting a bug in the IANA consideration section.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
skipping to change at page 50, line 4 skipping to change at page 51, line 4
http://www.opengis.org/techno/implementation.htm", , http://www.opengis.org/techno/implementation.htm", ,
January 2003. January 2003.
[GSM] "TADIG Naming Conventions, Version 4.1", GSM Association [GSM] "TADIG Naming Conventions, Version 4.1", GSM Association
Official Document TD.13", , June 2006. Official Document TD.13", , June 2006.
[I-D.ietf-geopriv-policy] [I-D.ietf-geopriv-policy]
Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
and J. Polk, "Geolocation Policy: A Document Format for and J. Polk, "Geolocation Policy: A Document Format for
Expressing Privacy Preferences for Location Information", Expressing Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-17 (work in progress), draft-ietf-geopriv-policy-19 (work in progress),
June 2008. January 2009.
[I-D.josefsson-pppext-eap-tls-eap] [I-D.josefsson-pppext-eap-tls-eap]
Josefsson, S., Palekar, A., Simon, D., and G. Zorn, Josefsson, S., Palekar, A., Simon, D., and G. Zorn,
"Protected EAP Protocol (PEAP) Version 2", "Protected EAP Protocol (PEAP) Version 2",
draft-josefsson-pppext-eap-tls-eap-10 (work in progress), draft-josefsson-pppext-eap-tls-eap-10 (work in progress),
October 2004. October 2004.
[ISO] "Codes for the representation of names of countries and [ISO] "Codes for the representation of names of countries and
their subdivisions - Part 1: Country codes, ISO 3166-1", their subdivisions - Part 1: Country codes, ISO 3166-1",
, 1997. , 1997.
skipping to change at page 61, line 4 skipping to change at line 2395
Email: avi@bridgewatersystems.com Email: avi@bridgewatersystems.com
Bernard Aboba Bernard Aboba
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
US US
Email: bernarda@microsoft.com Email: bernarda@microsoft.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 19 change blocks. 
88 lines changed or deleted 96 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/