--- 1/draft-ietf-ecrit-mapping-arch-02.txt 2007-09-30 06:12:07.000000000 +0200 +++ 2/draft-ietf-ecrit-mapping-arch-03.txt 2007-09-30 06:12:07.000000000 +0200 @@ -1,18 +1,18 @@ ECRIT H. Schulzrinne Internet-Draft Columbia U. -Intended status: Informational July 8, 2007 -Expires: January 9, 2008 +Intended status: Informational September 29, 2007 +Expires: April 1, 2008 Location-to-URL Mapping Architecture and Framework - draft-ietf-ecrit-mapping-arch-02 + draft-ietf-ecrit-mapping-arch-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware 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 Task Force (IETF), its areas, and its working groups. Note that @@ -23,60 +23,61 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on January 9, 2008. + This Internet-Draft will expire on April 1, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes an architecture for a global, scalable, resilient and administratively distributed system for mapping geographic location information to URLs, using the Location-to- Service (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. Table of Contents - 1. The Mapping Problem . . . . . . . . . . . . . . . . . . . . . 3 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview of Architecture . . . . . . . . . . . . . . . . . . . 5 - 4.1. Minimal System Architecture . . . . . . . . . . . . . . . 6 - 5. Seeker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 6. Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 7. Trees: Maintaining Authoritative Knowledge . . . . . . . . . . 7 - 7.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 7 - 7.2. Answering Queries . . . . . . . . . . . . . . . . . . . . 10 - 7.3. Overlapping Coverage Regions . . . . . . . . . . . . . . . 10 - 7.4. Scaling and Reliability . . . . . . . . . . . . . . . . . 11 - 8. Forest Guides . . . . . . . . . . . . . . . . . . . . . . . . 11 - 9. Configuring Service Numbers . . . . . . . . . . . . . . . . . 12 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 - 13.2. Informative References . . . . . . . . . . . . . . . . . . 15 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 - Intellectual Property and Copyright Statements . . . . . . . . . . 17 + 4.1. The Principal Components . . . . . . . . . . . . . . . . . 5 + 4.2. Minimal System Architecture . . . . . . . . . . . . . . . 7 + 5. Seeker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 6. Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 7. Trees: Maintaining Authoritative Knowledge . . . . . . . . . . 8 + 7.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 8 + 7.2. Answering Queries . . . . . . . . . . . . . . . . . . . . 11 + 7.3. Overlapping Coverage Regions . . . . . . . . . . . . . . . 11 + 7.4. Scaling and Reliability . . . . . . . . . . . . . . . . . 12 + 8. Forest Guides . . . . . . . . . . . . . . . . . . . . . . . . 12 + 9. Configuring Service Numbers . . . . . . . . . . . . . . . . . 13 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 + 13.2. Informative References . . . . . . . . . . . . . . . . . . 16 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 + Intellectual Property and Copyright Statements . . . . . . . . . . 18 -1. The Mapping Problem +1. Introduction It is often desirable to allow users to access a service that provides a common function, but is actually offered by a variety of local service providers. In many of these cases, the service provider chosen depends on the location of the person wishing to access that service. Among the best-known public services of this kind is emergency calling, where emergency calls are routed to the most appropriate public safety answering point (PSAP), based on the caller's physical location. Other services, from food delivery to directory services and roadside assistance, also follow this general @@ -110,72 +111,90 @@ determine the local service numbers. As discussed in Section 9, the architecture described here can also address that problem. The architecture described here uses the Location-to-Service Translation (LoST) [2] protocol, although much of the discussion would also apply for other mapping protocols satisfying the mapping requirements [8]. 2. Terminology - In this document, the key words "MUST", "MUSTNOT", "REQUIRED", - "SHALL", "SHALLNOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and - "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations. 3. Definitions In addition to the terms defined in [8], this document uses the following terms to describe LoST clients and servers: authoritative mapping server (AMS): An authoritative mapping server (AMS) is a LoST server that can provide the authoritative answer to a particular set of queries, e.g., covering a set of PIDF-LO civic labels or a particular region described by a geometric shape. In some (rare) cases of territorial disputes, two resolvers may be authoritative for the same region. An AMS may - redirect or forward a query to other AMS within the tree. + redirect or forward a query to another AMS within the tree. child: A child is an AMS that is authoritative for a subregion of another AMS. A child can in turn be parent for another AMS. (tree node) cluster: A node cluster is a group of LoST servers that all share the same mapping information and return the same results for queries. Clusters provide redundancy and share query load. Clusters are fully-meshed, i.e., they all exchange updates with each other. + coverage region: The coverage region of an AMS is the geographic + region within which the AMS is able to authoritatively answer + mapping queries. Coverage regions are generally, but not + necessarily, contigous and may be represented as either a subset + of a civic address or a geometric object. forest guide (FG): A forest guide (FG) has knowledge of the coverage region of trees for a particular top-level service. mapping: A mapping is a short-hand for 'mapping from a location object to one or more URLs describing either another mapping server or the desired service URLs'. parent: A mapping server that covers the region of all of its children. A mapping server without a parent is a root AMS. resolver: A resolver is contacted by a seeker, consults a forest mapping server and then resolves the query using an appropriate tree. Resolvers may cache query results. seeker: A seeker is a LoST client requesting a mapping. A seeker does not provide mapping services to others, but may cache results for its own use. - region map: A data object describing a contiguous area covered by an - AMS, either as a subset of a civic address or a geometric object. + tree: A tree consists of a self-contained hierarchy of authoritative - mapping servers. Each tree exports its coverage region to the - forest mapping servers. + mapping servers for a particular service. Each tree exports its + coverage region to the forest mapping servers. 4. Overview of Architecture - In short, end users of the LoST-based [2] mapping mechanism, called - seekers, contact resolvers that cache query results and know one or - more "forest guides". Forest guides know the coverage region of - trees and direct queries to the node at the top of the appropriate - tree. Trees consist of authoritative mapping servers and maintain - the authoritative mapping information. Figure 1 shows the - interaction of the components. +4.1. The Principal Components + + The mapping architecture distinguishes four logical roles: seekers, + resolvers, authoritative mapping servers and forest guides. End + users of the LoST-based [2] mapping mechanism, called seekers, + contact resolvers that cache query results and know one or more + forest guides. Forest guides know the coverage region of trees and + direct queries to the node at the top of the appropriate tree. Trees + consist of authoritative mapping servers and maintain the + authoritative mapping information. Seekers, resolvers, authoritative + mapping servers and forest guides all communicate using LoST; indeed, + it is likely that in many cases, the same software can operate as a + resolver, AMS and FG. In addition to the basic LoST query protocol + [2], a synchronization protocol [11] may be used to exchange + information between forest guides or to push coverage information + from a tree node to its parent. + + Seekers may be part of VoIP or other end systems, or SIP proxies or + similar call routing functions. + + Figure 1 shows the interaction of the components. /-\ /-\ +-----+ +-----+ | S +******* R ********* FG *-----------------+ FG | \-/ \-/ | |* | | +--+--+ * +--+--+ | * | | * | | * | | * | /-\ +--+--+ * +--+--+ @@ -199,29 +218,30 @@ Figure 1 The mapping function for the world is divided among trees. The collection of trees may not cover the whole world and trees are added and removed as the organization of mapping data changes. We call the collection of trees a forest. There is no limit on the number of trees within the forest, but the author guesses that the number of trees will likely be somewhere between a few hundred and a few thousand. The lower estimate would apply if each country operates - one tree. We assume that tree coverage information changes - relatively slowly, on the order of less than one change per year per - tree, although the system imposes no specific threshold. Tree - coverage would change, for example, if a country is split or merged - or if two trees for different regions become part of a larger tree. - (On the other hand, information within a tree is likely to change - much more frequently.) + one tree, the higher if different governmental or private + organizations within a country operate independent trees. We assume + that tree coverage information changes relatively slowly, on the + order of less than one change per year per tree, although the system + imposes no specific threshold. Tree coverage would change, for + example, if a country is split or merged or if two trees for + different regions become part of a larger tree. (On the other hand, + information within a tree is likely to change much more frequently.) -4.1. Minimal System Architecture +4.2. Minimal System Architecture It is possible to build a functioning system consisting only of seekers and resolvers if these resolvers have other means of obtaining mapping data. For example, a company acting as a mapping service provider could collect mapping records manually and make them available to their customers through the resolver. While feasible as a starting point, such an architecture is unlikely to scale globally. Among other problems, it becomes very hard for providers of authoritative data to ensure that all such providers have up-to-date information. If new trees are set up, they would somehow make @@ -231,21 +251,22 @@ Below, we describe the operation of each component in more detail. 5. Seeker Clients desiring location-to-service mappings are known as seekers. Seekers are consumers of mapping data and originate LoST queries as LoST protocol clients. Seekers do not answer LoST queries. They contact either forest guides or resolvers to find the appropriate tree that can authoritatively answer their questions. Seekers can be - end systems or call routing entities such as SIP proxy servers. + end systems such as SIP user agents or call routing entities such as + SIP proxy servers. Seekers may need to obtain mapping information in several steps, i.e., they may obtain pointers to intermediate servers that lead them closer to the final mapping. Seekers MAY cache query results for later use, but otherwise have no obligations to other entities in the system. Seekers need to be able to identify appropriate resolvers. The mechanism for providing seekers with that information is likely to differ depending on who operates the resolvers. For example, if the @@ -282,46 +303,46 @@ A seeker can contact a forest guide (see below) directly, but may not be able to easily locate such a guide. In addition, seekers in the same geographic area may already have asked the same question. Thus, it makes sense to introduce another entity, known as a resolver in the architecture, that knows how to contact one or more forest guides and caches earlier queries to accelerate the response to mapping queries and to improve the resiliency of the system. Each resolver can decide autonomously which FGs to use, with possibly different choices for each top-level service. - ISPs or VSPs would include the address of a suitable resolver in - their configuration information, e.g., in SIP configuration for a VSP - or DHCP [5] for an ISP. Resolvers are manually configured with the - name of one or more forest guides. + ISPs or VSPs may include the address of a suitable resolver in their + configuration information, e.g., in SIP configuration for a VSP or + DHCP [5] for an ISP. Resolvers are manually configured with the name + of one or more forest guides. 7. Trees: Maintaining Authoritative Knowledge 7.1. Basic Operation The architecture assumes that authoritative knowledge about the mapping data is distributed among many independent administrative - entities, but clients (seekers) needing the information may - potentially need to find out mapping about any spot on earth. - - (Extensions to extra-terrestrial applications are left for future - exploration.) Information is organized hierarchically, in a tree, - with tree nodes representing larger geographic areas pointing to - several child nodes each representing a smaller area. Each tree node - can be a cluster of LoST servers that all contain the same - information and back up each other. + entities, but clients (seekers) may potentially need to find out + mapping information for any spot on earth. (Extensions to extra- + terrestrial applications are left for future exploration.) + Information is organized hierarchically, in a tree, with tree nodes + representing larger geographic areas pointing to several child nodes + each representing a smaller area. Each tree node can be a cluster of + LoST servers that all contain the same information and back up each + other. - Each tree can map a location described by civic and geographic - coordinates for one type of service (such as 'sos.police', 'sos.fire' - or 'counseling'), although nothing prevents re-using the same tree - for multiple different services. The collection of all trees for one - service is known as a forest. + Each tree can map a location described by either civic or geographic + coordinates, but not both, for one type of service (such as + 'sos.police', 'sos.fire' or 'counseling'), although nothing prevents + re-using the same servers for multiple different services or both + types of coordinates. The collection of all trees for one service is + known as a forest. Each tree root announces its coverage region to one or more forest guides. Each tree node cluster knows the coverage region of its children and sends queries to the appropriate server "down" the tree. Each such tree node knows authoritatively about the service mappings for a particular region, typically, but not necessarily, contiguous. The region can be described by a polygon in geospatial coordinates or a set of civic address descriptors (e.g., "country = DE, A1 = @@ -350,25 +371,25 @@ providers, which in turn might further route signaling requests to more servers covering smaller regions. Leaf nodes, i.e., nodes without children, only maintain mappings, while tree nodes above the leaf nodes only maintain coverage regions. An example for emergency services of a leaf node entry is shown below, indicating how queries for three towns are directed to different PSAPs. Queries for Englewood are directed to another LoST server instead. - country A1 A2 A3 resource + country A1 A2 A3 resource or LoST server US NJ Bergen Leonia sip:psap@leonianj.gov US NJ Bergen Fort Lee sip:emergency@fortleenj.org US NJ Bergen Teaneck sip:police@teanecknjgov.org - US NJ Bergen Englewood lost:englewoodnj.gov + US NJ Bergen Englewood englewoodnj.gov .... Coverage regions are described by sets of polygons enclosing contiguous geographic areas or by descriptors enumerating groups of civic locations. For the former, the LoST server performs a point- in-polygon operation to find the polygon that contains the query point. (More complicated geometric matching algorithms may be added in the future.) For example, a state-level tree node for New Jersey in the United @@ -376,36 +397,36 @@ that any query matching a location in Bergen County, for example, would be redirected or forwarded to the node located at bergen.nj.example.org. There is no requirement that all child nodes cover the same level within the civic hierarchy. As an example, in the table below, the city of Newark has decided to be listed directly within the state node, rather than through the county. Longest-match rules allow partial coverage, so that for queries for all other towns within Essex county would be directed to the county node for further resolution. - C A1 A2 A3 resource - US NJ Atlantic * lost:atlantic.nj.example.org/sos - US NJ Bergen * lost:bergen.nj.example.org/sos - US NJ Monmouth * lost:monmouth.nj.example.org/sos - US NJ Essex * lost:essex.nj.example.org/sos - US NJ Essex Newark lost:newark.example.com/sos + C A1 A2 A3 LoST server name + US NJ Atlantic * atlantic.nj.example.org/sos + US NJ Bergen * bergen.nj.example.org/sos + US NJ Monmouth * monmouth.nj.example.org/sos + US NJ Essex * essex.nj.example.org/sos + US NJ Essex Newark newark.example.com/sos .... Thus, there is no substantial difference between coverage region and mapping data. The only difference is that coverage regions return - LoST URLs, while mapping entries contain service URLs. Mapping - entries may be specific down to the house or floor level or may only - contain street-level information. For example, in the United States, - civic mapping data for emergency services is generally limited to - address ranges ("MSAG data"), so initial mapping databases may only - contain street-level information. + names of LoST servers, while mapping entries contain service URLs. + Mapping entries may be specific down to the house or floor level or + may only contain street-level information. For example, in the + United States, civic mapping data for emergency services is generally + limited to address ranges ("MSAG data"), so initial mapping databases + may only contain street-level information. To automate the maintenance of trees, the LoST synchronization mechanism [11] allows nodes to query other nodes for mapping data and coverage regions. In the example above, the state-run node would query the county nodes and use the records returned to distribute incoming LoST queries to the county nodes. Conversely, nodes could also contact their parent nodes to tell them about their coverage region. There is some benefit of child nodes contacting their parents, as this allows changes in coverage region to propagate quickly up the tree. @@ -470,51 +490,51 @@ protocol mechanism, but a standardized incremental update mechanism makes it easier to spread those nodes across multiple independently- administered locations. The techniques developed for meshed SLP [3] are applicable here. 8. Forest Guides Unfortunately, just having trees covering various regions of the world is not sufficient as a client of the mapping protocol would not generally be able to keep track of all the trees in the forest. To - facilitate orientation among the trees, we introduce a "forest guide" - (FG). It is a server that keeps track of the coverage regions of the - trees. For scalability and reliability, there will need to be a - large number of forest guides, all providing the same information. A - seeker can contact a suitable forest guide and will then be directed - to the right tree or, rarely, set of trees. Forest guides do not - provide mapping information themselves, but rather redirect to + facilitate orientation among the trees, we introduce a forest guide + (FG) which keeps track of the coverage regions of all the trees for + one service. For scalability and reliability, there will need to be + a large number of forest guides, all providing the same information. + A seeker can contact a suitable forest guide and will then be + directed to the right tree or, rarely, set of trees. Forest guides + do not provide mapping information themselves, but rather redirect to mapping servers. In some configurations, not all forest guides may provide the same information, due to policy reasons. - Introducing forest guides avoids creating a global root, with the - attendant management and control issues. Trees can also restrict - their cooperation to parts of the information. For example, if - country C does not recognize country T, C can propagate tree regions - for all but T. - - For authenticity, the records SHOULD be digitally signed. They are - used by resolvers and possibly seekers to find the appropriate tree - for a particular area. All forest guides should have consistent - information, i.e., a collection of all the coverage regions of all - the trees. A tree node at the top of a tree can contact any forest - guide and inject new coverage region information into the system. - One would expect that each tree announces its coverage to more than - one forest guide. Each forest guide peers with one or more other - guides and distributes new coverage region announcements to all other - guides. + Forest guides fulfill a similar role to root servers in DNS. They + distribute information, signed for authenticity, offered by trees. + However, introducing forest guides avoids creating a global root, + with the attendant management and control issues. Forest guides can + also restrict their cooperation to parts of the information. For + example, if country C does not recognize country T, C can propagate + tree regions for all but T. - Forest guides fulfill a similar role to root servers in DNS. - However, their number is likely to be larger, possibly counted in - hundreds. They distribute information, signed for authenticity, - offered by trees. + For authenticity, the coverage regions SHOULD be digitally signed by + the authorities responsible for the region, as discussed in more + detail in Section 10. They are used by resolvers and possibly + seekers to find the appropriate tree for a particular area. All + forest guides should have consistent information, i.e., a collection + of all the coverage regions of all the trees. A tree node at the top + of a tree can contact any forest guide and inject new coverage region + information into the system. One would expect that each tree + announces its coverage to more than one forest guide. Each forest + guide peers with one or more other guides and distributes new + coverage region announcements to other guides. Due to policy and + maybe political reasons, not all forest guides may share the same + coverage region data. Forest guides can, in principle, be operated by anybody, including voice service providers, Internet access providers, dedicated services providers and enterprises. As in routing, peering with other forest guides implies a certain amount of trust in the peer. Thus, peering is likely to require some negotiation between the administering parties concerned, rather than automatic configuration. The mechanism itself does not imply a particular policy as to who gets to advertise a particular coverage @@ -559,43 +579,43 @@ sets of service numbers, namely those used in the user's home country and in the country the user is currently visiting. The user is most likely to remember the former, but a companion borrowing a device in an emergency, say, may only know the local emergency numbers. Determining home and local service numbers is a configuration problem, but unfortunately, existing configuration mechanisms are ill-suited for this purpose. For example, a DHCP server might be able to provide the local service numbers, but not the home numbers. When virtual private networks (VPNs) are used, even DHCP may provide - numbers of uncertain origin, as a user may contact to the home - network or some local branch office of the corporate network. - Similarly, SIP configuration [4] would be able to provide the numbers - valid at the location of the SIP service provider, but even a SIP - service provider with national footprint may serve customers that are - visiting any number of other countries. + numbers of uncertain origin, as a user may contact the home network + or some local branch office of the corporate network. Similarly, SIP + configuration [4] would be able to provide the numbers valid at the + location of the SIP service provider, but even a SIP service provider + with national footprint may serve customers that are visiting any + number of other countries. Also, while initially there are likely to be only a few service numbers, e.g., for emergency services, the LoST architecture can be used to support other services, as noted. Configuring every local DHCP or SIP configuration server with that information is likely to be error-prone and tedious. For these reasons, the LoST-based mapping architecture supports providing service numbers to end systems based on caller location. The mapping operation is almost exactly the same as for determining - the service URL. The mapping can be obtained either along with - determining the service URL or separately. The major difference + the service URL. The mapping can be obtained either along with the + service URL or through a separate request. The major difference between the two requests is that service numbers often have much larger regions of validity than the service URL itself. Also, the service number is likely to be valid longer than the service URL. Finally, an end system may want to look up the service number for its - home location, not just the current (visited) location. + home location, not just its current (visited) location. 10. Security Considerations Security considerations for emergency services mapping are discussed in [9], while [10] discusses issues related to the service URN, one of the inputs into the mapping protocol. LoST-related security considerations are naturally discussed in the LoST [2] specification. The architecture addresses the following security issues, usually through the underlying transport security associations: @@ -610,93 +630,96 @@ digitally signed, e.g., using XML digital signatures. Note, however, that simple origin assertion may not provide the end system with enough useful information as it has no good way of knowing that a particular signer is authorized to represent a particular geographic area. It might be necessary that certain well-known Certificate Authorities (CAs) vet sources of mapping information and provide special certificates for that purpose. In many cases, a seeker will have to trust its local resolver to vet information for trustworthiness; in turn, the resolver may rely on trusted forest guides to steer it to the correct information. - Region corruption: To avoid that a third party or an untrustworthy - member of a server population introduces a region map that it is - not authorized for, any node introducing a new region map MUST - sign the object by encapsulating the data into a CMS wrapper. A - recipient MUST verify, through a local policy mechanism, that the - signing entity is indeed authorized to speak for that region. - Determining who can speak for a particular region is inherently - difficult unless there is a small set of authorizing entities that - participants in the mapping architecture can trust. Receiving - systems should be particularly suspicious if an existing region - map is replaced with a new one with a new mapping address. In - many cases, trust will be mediated: A seeker will have a trust - relationship with a resolver. The resolver, in turn, will contact - a trusted forest guide. + Coverage region corruption: To avoid that a third party or an + untrustworthy member of a server population introduces claims a + coverage region that it is not authorized for, any node + introducing a new region map MUST sign the object by encapsulating + the data into a CMS wrapper. A recipient MUST verify, through a + local policy mechanism, that the signing entity is indeed + authorized to speak for that region. Determining who can speak + for a particular region is inherently difficult unless there is a + small set of authorizing entities that participants in the mapping + architecture can trust. Receiving systems should be particularly + suspicious if an existing coverage region is replaced with a new + one with a new mapping address. In many cases, trust will be + mediated: A seeker will have a trust relationship with a resolver. + The resolver, in turn, will contact a trusted forest guide. Additional threats that need to be addressed by operational measures include denial-of-service attacks [7]. 11. IANA Considerations Since this document describes an architecture, not a protocol, it does not ask IANA to register any protocol constants. 12. Acknowledgments - Richard Barnes, Jong Yul Kim, Otmar Lendl, Andrew Newton, Murugaraj - Shanmugam, Richard Stastny, and Hannes Tschofenig provided helpful - comments. + Richard Barnes, Jong Yul Kim, Otmar Lendl, Matt Lepinski, Andrew + Newton, Schida Schubert, Murugaraj Shanmugam, Richard Stastny, and + Hannes Tschofenig provided helpful comments. 13. References 13.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Hardie, T., "LoST: A Location-to-Service Translation Protocol", - draft-ietf-ecrit-lost-05 (work in progress), March 2007. + draft-ietf-ecrit-lost-06 (work in progress), August 2007. 13.2. Informative References [3] Zhao, W., Schulzrinne, H., and E. Guttman, "Mesh-enhanced Service Location Protocol (mSLP)", RFC 3528, April 2003. [4] Petrie, D. and S. Channabasappa, "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-12 (work in progress), June 2007. [5] Schulzrinne, H., "A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) - Discovery Procedure", draft-ietf-ecrit-dhc-lost-discovery-01 - (work in progress), March 2007. + Discovery Procedure", draft-ietf-ecrit-dhc-lost-discovery-02 + (work in progress), July 2007. - [6] Rosen, B., "Framework for Emergency Calling in Internet - Multimedia", draft-ietf-ecrit-framework-01 (work in progress), - March 2007. + [6] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework + for Emergency Calling using Internet Multimedia", + draft-ietf-ecrit-framework-03 (work in progress), + September 2007. [7] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", - draft-ietf-ecrit-phonebcp-01 (work in progress), March 2007. + draft-ietf-ecrit-phonebcp-02 (work in progress), + September 2007. [8] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", draft-ietf-ecrit-requirements-13 (work in progress), March 2007. [9] Taylor, T., "Security Threats and Requirements for Emergency - Call Marking and Mapping", draft-ietf-ecrit-security-threats-04 - (work in progress), April 2007. + Call Marking and Mapping", draft-ietf-ecrit-security-threats-05 + (work in progress), August 2007. - [10] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", - draft-ietf-ecrit-service-urn-06 (work in progress), March 2007. + [10] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency + and Other Well-Known Services", draft-ietf-ecrit-service-urn-07 + (work in progress), August 2007. [11] Schulzrinne, H., "Synchronizing Location-to-Service Translation (LoST) Servers", draft-schulzrinne-ecrit-lost-sync-00 (work in progress), November 2006. Author's Address Henning Schulzrinne Columbia University Department of Computer Science