text:
Internet Engineering Task Force (IETF) J. Peterson Request for Comments: 8396 NeuStar, Inc. Category: Informational T. McGarry ISSN: 2070-1721 July 2018 Managing, Ordering, Distributing, Exposing, and Registering Telephone Numbers (MODERN): Problem Statement, Use Cases, and Framework Abstract The functions of the Public Switched Telephone Network (PSTN) are rapidly migrating to the Internet. This is generating new requirements for many traditional elements of the PSTN, including Telephone Numbers (TNs). TNs no longer serve simply as telephone routing addresses: they are now identifiers that may be used by Internet-based services for a variety of purposes including session establishment, identity verification, and service enablement. This problem statement examines how the existing tools for allocating and managing telephone numbers do not align with the use cases of the Internet environment and proposes a framework for Internet-based services relying on TNs. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8396. Peterson & McGarry Informational [Page 1]
RFC 8396 MODERN Problems July 2018 Copyright Notice Copyright (c) 2018 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 (https://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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Actors . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Data Management Architectures . . . . . . . . . . . . . . 8 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Acquisition . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Acquiring TNs from Registrar . . . . . . . . . . . . 12 4.1.2. Acquiring TNs from CSPs . . . . . . . . . . . . . . . 13 4.2. Management . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.1. Management of Administrative Data . . . . . . . . . . 14 188.8.131.52. Managing Data at a Registrar . . . . . . . . . . 14 126.96.36.199. Managing Data at a CSP . . . . . . . . . . . . . 15 4.2.2. Management of Service Data . . . . . . . . . . . . . 15 220.127.116.11. CSP to Other CSPs . . . . . . . . . . . . . . . . 16 184.108.40.206. User to CSP . . . . . . . . . . . . . . . . . . . 16 4.2.3. Managing Change . . . . . . . . . . . . . . . . . . . 16 184.108.40.206. Changing the CSP for an Existing Service . . . . 16 188.8.131.52. Terminating a Service . . . . . . . . . . . . . . 17 4.3. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3.1. Retrieval of Public Data . . . . . . . . . . . . . . 18 4.3.2. Retrieval of Semi-restricted Administrative Data . . 18 4.3.3. Retrieval of Semi-restricted Service Data . . . . . . 19 4.3.4. Retrieval of Restricted Data . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Informative References . . . . . . . . . . . . . . . . . . . 21 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Peterson & McGarry Informational [Page 2]
RFC 8396 MODERN Problems July 2018 1. Problem Statement The challenges of utilizing Telephone Numbers (TNs) on the Internet have been known for some time. Internet telephony provided the first use case for routing telephone numbers on the Internet in a manner similar to how calls are routed in the Public Switched Telephone Network (PSTN). As the Internet had no service for discovering the endpoints associated with telephone numbers, ENUM [RFC6116] created a DNS-based mechanism for translating TNs into URIs, as used by protocols such as SIP [RFC3261]. The resulting database was designed to function in a manner similar to the systems that route calls in the PSTN. Originally, it was envisioned that ENUM would be deployed as a global hierarchical service; however, in practice, it has only been deployed piecemeal by various parties. Most notably, ENUM is used as an internal network function and is rarely used between service provider networks. The original ENUM concept of a single root, e164.arpa, proved to be politically and practically challenging, and less centralized models have thus flourished. Subsequently, the Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) framework [RFC6461] showed ways that service providers might provision information about TNs at an ENUM service or similar Internet-based directory. These technologies have also generally tried to preserve the features and architecture familiar to the PSTN numbering environment. Over time, Internet telephony has encompassed functions that differ substantially from traditional PSTN routing and management, especially as non-traditional providers have begun to utilize numbering resources. An increasing number of enterprises, over-the- top Voice over IP (VoIP) providers, text messaging services, and related non-carrier services have become heavy users of telephone numbers. An enterprise, for example, can deploy an IP Private Branch Exchange (PBX) that receives a block of telephone numbers from a carrier and then, in turn, distributes those numbers to new IP telephones when they associate with the PBX. Internet services offer users portals where they can allocate new telephone numbers on the fly, assign multiple "alias" telephone numbers to a single line service, implement various mobility or find-me-follow-me applications, and so on. Peer-to-peer telephone networks have encouraged experiments with distributed databases for telephone number routing and even allocation. This dynamic control over telephone numbers has few precedents in the traditional PSTN outside of number portability. Number portability allows the capability of a user to choose and change their service provider while retaining their TN; it has been implemented in many countries either for all telephony services or for subsets (e.g., mobile). However, TN administration processes rooted in PSTN Peterson & McGarry Informational [Page 3]
RFC 8396 MODERN Problems July 2018 technology and policies made number porting fraught with problems and delays. Originally, processes were built to associate a specific TN to a specific service provider and never change it. With number portability, the industry had to build new infrastructure and new administrative functions and processes to change the association of the TN from one service provider to another. Thanks to the increasing sophistication of consumer mobile devices as Internet endpoints as well as telephones, users now associate TNs with many Internet applications other than telephony. This has generated new interest in models similar to those in place for administering freephone (non-geographic, toll-free numbers) services in the United States, where a user purchases a number through a sort of number registrar and controls its administration (such as routing) on their own, typically using Internet services to directly make changes to the service associated with telephone numbers. Most TNs today are assigned to specific geographies, at both an international level and within national numbering plans. Numbering practices today are tightly coupled with the manner that service providers interconnect as well as with how TNs are routed and administered: the PSTN was carefully designed to delegate switching intelligence geographically. In interexchange carrier routing in North America, for example, calls to a particular TN are often handed off to the terminating service provider close to the geography where that TN is assigned. But the overwhelming success of mobile telephones has increasingly eroded the connection between numbers and regions. Furthermore, the topology of IP networks is not anchored to geography in the same way that the telephone network is. In an Internet environment, establishing a network architecture for routing TNs could depend little on geography, relying instead on network topologies or other architectural features. Adapting TNs to the Internet requires more security, richer datasets, and more complex query and response capabilities than previous efforts have provided. This document attempts to create a common understanding of the problem statement related to allocating, managing, and resolving TNs in an IP environment, which is the focus of the IETF Managing, Ordering, Distributing, Exposing, and Registering telephone Numbers (MODERN) Working Group. It outlines a framework and lists motivating use cases for creating IP-based mechanisms for TNs. It is important to acknowledge at the outset that there are various evolving international and national policies and processes related to TNs, and any solutions need to be flexible enough to account for variations in policy and requirements. Peterson & McGarry Informational [Page 4]
RFC 8396 MODERN Problems July 2018 2. Definitions This section provides definitions for actors, data types, and data management architectures as they are discussed in this document. Different numbering spaces may instantiate these roles and concepts differently: practices that apply to non-geographic freephone numbers, for example, may not apply to geographic numbers, and practices that exist under one Numbering Authority may not be permitted under another. The purpose of this framework is to identify the characteristics of protocol tools that will satisfy the diverse requirements for telephone number acquisition, management, and retrieval on the Internet. 2.1. Actors The following roles of actors are defined in this document. Numbering Authority: A regulatory body within a region that manages that region's TNs. The Numbering Authority decides national numbering policy for the nation, region, or other domain for which it has authority, including what TNs can be allocated, which are reserved, and which entities may obtain TNs. Registry: An entity that administers the allocation of TNs based on a Numbering Authority's policies. Numbering Authorities can act as the Registries themselves, or they can outsource the function to other entities. Traditional registries are single entities with sole authority and responsibility for specific numbering resources, though distributed registries (see Section 2.3) are also in the scope of this framework. Credential Authority: An entity that distributes credentials, such as certificates that attest the authority of assignees (defined below) and delegates. This document assumes that one or more Credential Authorities may be trusted by actors in any given regulatory environment; policies for establishing such trust anchors are outside the scope of this document. Registrar: An entity that distributes the telephone numbers administered by a Registry; typically, there are many Registrars that can distribute numbers from a single Registry, though Registrars may serve multiple Registries as well. A Registrar has business relationships with number assignees and collects administrative information from them. Communication Service Provider (CSP): A provider of communication service where those services can be identified by TNs. This includes both traditional telephone carriers or enterprises as Peterson & McGarry Informational [Page 5]
RFC 8396 MODERN Problems July 2018 well as service providers with no presence on the PSTN who use TNs. This framework does not assume that any single CSP provides all the communication service related to a particular TN. Service Enabler: An entity that works with CSPs to enable communication service to a User: perhaps a vendor, a service bureau, or a third-party integrator. User: An individual reachable through a communication service: usually a customer of a Communication Service Provider. Government Entity: An entity that, due to legal powers deriving from national policy, has privileged access to information about number administration under certain conditions. Note that an individual, organization, or other entity may act in one or more of the roles above; for example, a company may be a CSP and also a Registrar. Although Numbering Authorities are listed as actors, they are unlikely to actually participate in the protocol flows themselves; however, in some situations, a Numbering Authority and Registry may be the same administrative entity. All actors that are recipients of numbering resources, be they a CSP, Service Enabler, or User, can also be said to have a relationship to a Registry of either an assignee or delegate. Assignee: An actor that is assigned a TN directly by a Registrar; an assignee always has a direct relationship with a Registrar. Delegate: An actor that is delegated a TN from an assignee or another delegate who does not necessarily have a direct relationship with a Registrar. Delegates may delegate one or more of their TN assignment(s) to one or more subdelegates from further downstream. As an example, consider a case where a Numbering Authority also acts as a Registry, and it issues blocks of 10,000 TNs to CSPs that, in this case, also act as Registrars. CSP/Registrars would then be responsible for distributing numbering resources to Users and other CSPs. In this case, an enterprise deploying IP PBXs also acts as a CSP, and it acquires number blocks for its enterprise seats in chunks of 100 from a CSP acting as a Registrar with whom the enterprise has a business relationship. The enterprise is, in this case, the assignee, as it receives numbering resources directly from a Registrar. As it doles out individual numbers to its Users, the enterprise delegates its own numbering resources to those Users and their communication endpoints. The overall ecosystem might look as follows. Peterson & McGarry Informational [Page 6]
RFC 8396 MODERN Problems July 2018 +---------+ |Numbering| |Authority|Registry +----+----+ | V 10,000 TNs +---------+ | CSP |Registrar +----+----+ | V 100 TNs +---------+ | PBX |Assignee +---------+ | V 1 TN +---------+ | User |Delegate +---------+ Figure 1: Chain of Number Assignment 2.2. Data Types The following data types are defined in this document. Administrative Data: Assignment data related to the TN and the relevant actors; it includes TN status (assigned, unassigned, etc.), contact data for the assignee or delegate, and typically does not require real-time access as this data is not required for ordinary call or session establishment. Service Data: Data necessary to enable service for the TN; it includes addressing data and service features. Since this data is necessary to complete calls, it must be obtained in real time. Administrative and service data can fit into three access categories: Public: Anyone can access public data. Such data might include a list of which numbering resources (unallocated number ranges) are available for acquisition from the Registry. Semi-restricted: Only a subset of actors can access semi-restricted data. For example, CSPs may be able to access other CSP's service data in some closed environment. Peterson & McGarry Informational [Page 7]
RFC 8396 MODERN Problems July 2018 Restricted: Only a small subset of actors can access restricted data. For example, a Government Entity may be able access contact information for a User. While it might appear there are really only two categories, public and restricted (based on the requestor), the distinction between semi-restricted and restricted is helpful for the use cases below. 2.3. Data Management Architectures This framework generally assumes that administrative and service data is maintained by CSPs, Registrars, and Registries. The terms "registrar" and "registry" are familiar from DNS operations, and indeed the DNS provides an obvious inspiration for the relationships between those entities described here. Protocols for transferring names between registries and registrars have been standardized in the DNS space for some time (see [RFC3375]). Similarly, the division between service data acquired by resolving names with the DNS protocol versus administrative data about names acquired through WHOIS [RFC3912] is directly analogous to the distinction between service and administrative data described in Section 2.2. The major difference between the data management architecture of the DNS and this framework is that the distinction between the CSP and User, due to historical policies of the telephone network, will often not exactly correspond to the distinction between a name service and a registrant in the DNS world -- a User in the telephone network is today at least rarely in a direct relationship with a Registrar comparable to that of a DNS registrant. The role of a Registry described here is a "thin" one, where the Registry manages basic allocation information for the numbering space, such as information about whether or not the number is assigned, and if assigned, by which Registrar. It is the Registrar that, in turn, manages detailed administrative data about those assignments, such as contact or billing information for the assignee. In some models, CSPs and Registrars will be combined (the same administrative entity), and in others the Registry and Registrar may similarly be composed. Typically, service data resides largely at the CSP itself, though in some models a "thicker" Registry may itself contain a pointer to the servicing CSP for a number or number block. In addition to traditional centralized Registries, this framework also supports environments where the same data is being managed by multiple administrative entities and stored in many locations. A Peterson & McGarry Informational [Page 8]
RFC 8396 MODERN Problems July 2018 distributed registry system is discussed further in [DRIP]. To support those use cases, it is important to distinguish the following: Data Store: A data store is a service that stores and enables access to administrative and/or service data. Reference Address: A reference address is a URL that dereferences to the location of the data store. Distributed Data Stores: In a distributed data store, administrative or service data can be stored with multiple actors. For example, CSPs could provision their service data to multiple other CSPs. Distributed Registries: Multiple Registries can manage the same numbering resource. In these architectures, actors could interact with one or multiple Registries. The Registries would update each other when change occurs. The Registries have to ensure that data remains consistent, e.g., that the same TN is not assigned to two different actors. 3. Framework The framework outlined in this document requires three Internet-based mechanisms for managing and resolving TNs in an IP environment. These mechanisms will likely reuse existing protocols for sharing structured data; it is unlikely that new protocol development work will be required, though new information models specific to the data itself will be a major focus of framework development. Likely candidates for reuse here include work done in DRINKS [RFC6461] and Web Extensible Internet Registration Data Service (WEIRDS) [RFC7482], as well as the Telephone-Related Information (TeRI) framework [TERI-INFO]. These protocol mechanisms are scoped in a way that makes them likely to apply to a broad range of future policies for number administration. It is not the purpose of this framework to dictate number policy but instead to provide tools that will work with policies as they evolve going forward. These mechanisms, therefore, do not assume that number administration is centralized nor that number allocations are restricted to any category of service providers, though these tools must and will work in environments with those properties. Peterson & McGarry Informational [Page 9]
RFC 8396 MODERN Problems July 2018 The three mechanisms are: Acquisition: A protocol mechanism for acquiring TNs, including an enrollment process. Management: A protocol mechanism for associating data with TNs. Retrieval: A protocol mechanism for retrieving data about TNs. The acquisition mechanism will enable actors to acquire TNs for use with a communication service by requesting numbering resources from a service operated by a Registrar, CSP, or similar actor. TNs may be requested either on a number-by-number basis or as inventory blocks. Any actor who grants numbering resources will retain metadata about the assignment, including the responsible organization or individual to whom numbers have been assigned. The management mechanism will let actors provision data associated with TNs. For example, if a User has been assigned a TN, they may select a CSP to provide a particular service associated with the TN, or a CSP may assign a TN to a User upon service activation. In either case, a mechanism is needed to provision data associated with the TN at that CSP and to extend those data sets as CSPs (and even Users) require. The retrieval mechanism will enable actors to learn information about TNs. For real-time service data, this typically involves sending a request to a CSP; for other information, an actor may need to send a request to a Registry rather than a CSP. Different parties may be authorized to receive different information about TNs. As an example, a CSP might use the acquisition interface to acquire a chunk of numbers from a Registrar. Users might then provision administrative data associated with those numbers at the CSP through the management interface and query for service data relating to those numbers through the retrieval interface of the CSP. Peterson & McGarry Informational [Page 10]
RFC 8396 MODERN Problems July 2018 +--------+ |Registry| +---+----+ | V +---------+ |Registrar| +---------+ \ \\ Acquisition \\ \\+-------+ \ CSP | +---+---+ A A | | Management | | Retrieval | | | | +-------++ ++-------+ | User | | User | +--------+ +--------+ (Delegate) (Caller) Figure 2: Example of the Three Interfaces 4. Use Cases The high-level use cases in this section will provide an overview of the expected operation of the three interfaces in the MODERN problem space. 4.1. Acquisition There are various scenarios for how TNs can be acquired by the relevant actors, that is, a CSP, Service Enabler, and a User. There are three actors from which numbers can be acquired: a Registrar, a CSP, and a User (presumably one who is delegating to another party). It is assumed either that Registrars are the same entity as Registries or that Registrars have established business relationships with Registries that enable them to distribute the numbers that the Registries administer. In these use cases, a User may acquire TNs either from a CSP, a Registry, or an intermediate delegate. Peterson & McGarry Informational [Page 11]
RFC 8396 MODERN Problems July 2018 4.1.1. Acquiring TNs from Registrar The most traditional number acquisition use case is one where a CSP, such as a carrier, requests a block of numbers from a Registrar to hold as inventory or assign to customers. Through some out-of-band business process, a CSP develops a relationship with a Registrar. The Registrar maintains a profile of the CSP and assesses whether or not CSPs meet the policy restrictions for acquiring TNs. The CSP may then request TNs from within a specific pool of numbers in the authority of the Registry, such as region, mobile, wireline, or freephone. The Registrar must authenticate and authorize the CSP and then either grant or deny a request. When an assignment occurs, the Registry creates and stores administrative information related to the assignment, such as TN status and Registrar contact information, and removes the specific TN(s) from the pool of those that are available for assignment. As a part of the acquisition and assignment process, the Registry provides to the Registrar any tokens or other material needed by a Credential Authority to issue credentials (for example, Secure Telephone Identity Revisited (STIR) certificates [RFC8226]) used to attest the assignment for future transactions. Depending on the policies of the Numbering Authorities, Registrars may be required to log these operations. Before it is eligible to receive TN assignments, per the policy of a Numbering Authority, the CSP may need to have submitted (again, through some out-of-band process) additional qualifying information such as the current utilization rate or a demand forecast. There are two scenarios under which a CSP requests resources: either they are requesting inventory or they are requesting for a specific User or delegate. For the purpose of status information, TNs assigned to a User are always considered assigned, not inventory. The CSP will associate service information for that TN (e.g., a service address) and make it available to other CSPs to enable interconnection. The CSP may need to update the Registrar regarding this service activation; this is part of the "TN status" maintained by the Registrar. There are also use cases in which a User can acquire a TN directly from a Registrar. Today, a User wishing to acquire a freephone number may browse the existing inventory through one or more Registrars, comparing their prices and services. Each such Registrar either is a CSP or has a business relationship with one or more CSPs to provide services for that freephone number. In this case, the User must establish some business relationship directly with a Registrar, similar to how such functions are conducted today when Peterson & McGarry Informational [Page 12]
RFC 8396 MODERN Problems July 2018 Users purchase domain names. In this use case, after receiving a number assignment from the Registrar, a User will obtain communication service from a CSP and provide to the CSP the TN to be used for that service. The CSP will associate service information for that TN (e.g., the service address) and make it available to other CSPs to enable interconnection. The User will also need to inform the Registrar about this relationship. 4.1.2. Acquiring TNs from CSPs Today, a User typically acquires a TN from a CSP when signing up for a communication service or turning on a new device. In this use case, the User becomes the delegate of the CSP. A reseller or a service bureau might also acquire a block of numbers from a CSP to be issued to Users. Consider a case where a User creates or has a relationship with the CSP and subscribes to a communication service that includes the use of a TN. The CSP collects and stores administrative data about the User. The CSP then activates the User on their network and creates any necessary service data to enable connectivity with other CSPs. The CSP could also update public or privileged databases accessible by other actors. The CSP provides any tokens or other material needed by a Credential Authority to issue credentials to the User (for example, a STIR certificate [RFC8226]) to prove the assignment for future transactions. Such credentials could be delegated from the one provided by the Credential Authority to the CSP to continue the chain of assignment. CSPs may be required to log such transactions if required by the policy of the Numbering Authority. Virtually, the same flow would work for a reseller: it would form a business relationship with the CSP, at which point the CSP would collect and store administrative data about the reseller and give the reseller any material needed for the reseller to acquire credentials for the numbers. A User might then, in turn, acquire numbers from the reseller: in this case, the delegate redelegating the TNs would be performing functions done by the CSP (e.g., providing any credentials or collecting administrative data or creative service data). The CSP could assign a TN from its existing inventory or it could acquire a new TN from the Registrar as part of the assignment process. If it assigns it from its existing inventory, it would remove the specific TN from the pool of those available for assignment. It may also update the Registrar about the assignment so the Registrar has current assignment data. If a reseller or delegate Peterson & McGarry Informational [Page 13]
RFC 8396 MODERN Problems July 2018 CSP is acquiring the numbers, it may have the same obligations to provide utilization data to the Registry as the assignee, per Section 4.1.1. 4.2. Management The management protocol mechanism is needed to associate administrative and service data with TNs and may be used to refresh or rollover associated credentials. 4.2.1. Management of Administrative Data Administrative data is primarily related to the status of the TN, its administrative contacts, and the actors involved in providing service to the TN. Protocol interactions for administrative data will therefore predominantly occur between CSPs and Users to the Registrar or between Users and delegate CSPs to the CSP. Some administrative data may be private and would thus require special handling in a distributed data store model. Access to it does not require real-time performance; therefore, local caches are not necessary, and the data will include sensitive information such as User and contact data. Some of the data could lend itself to being publicly available, such as CSP and TN assignment status. In that case, it would be deemed public information for the purposes of the retrieval interface. 126.96.36.199. Managing Data at a Registrar After a CSP acquires a TN or block of TNs from the Registrar (per Section 4.1.1), it then provides administrative data to the Registrar as a step in the acquisition process. The Registrar will authenticate the CSP and determine if the CSP is authorized to provision the administrative data for the TNs in question. The Registry will update the status of the TN, i.e., that it is unavailable for assignment. The Registrar will also maintain administrative data provided by the CSP. Changes to this administrative data will not be frequent. Examples of changes would be terminating service (see Section 18.104.22.168), changing the name or address of a User or organization, or changing a CSP or delegate. Changes should be authenticated by a credential to prove administrative responsibility for the TN. Peterson & McGarry Informational [Page 14]
RFC 8396 MODERN Problems July 2018 In some cases, such as the freephone system in North America today, the User has a direct relationship with the Registrar. Naturally, these Users could provision administrative data associated with their TNs directly to the Registrar just as a freephone provider today maintains account and billing data. While delegates may not ordinarily have a direct relationship to a Registrar, some environments (as an optimization) might want to support a model where the delegate updates the Registrar directly on changes, as opposed to sending that data to the CSP or through the CSP to the Registrar. As stated already, the protocol should enable Users to acquire TNs directly from a Registrar, which may or may not also act as a CSP. In these cases, the updates would be similar to those described in Section 18.104.22.168. In a distributed Registry model, TN status (e.g., allocated, assigned, available, or unavailable) would need to be provided to other Registries in real time. Other administrative data could be sent to all Registries, or other Registries could get a reference address to the host Registry's data store. 188.8.131.52. Managing Data at a CSP After a User acquires a TN or block of TNs from a CSP, the User will provide administrative data to the CSP. The CSP commonly acts as a Registrar in this case by maintaining the administrative data and only notifying the Registry of the change in TN status. In this case, the Registry maintains a reference address (see Section 2.3) to the CSP/Registrar's administrative data store so relevant actors have the ability to access the data. Alternatively, a CSP could send the administrative data to an external Registrar to store. If there is a delegate between the CSP and User, they will have to ensure there is a mechanism for the delegate to update the CSP as change occurs. 4.2.2. Management of Service Data Service data is data required by an originating or intermediate CSP to enable communication service to a User; a SIP URI is an example of one service data element commonly used to route communication. CSPs typically create and manage service data, however, it is possible that delegates and Users could as well. For most use cases involving individual Users, it is anticipated that lower-level service information changes (such as an end-user device receiving a new IP address) would be communicated to CSPs via existing protocols. For example, the baseline SIP REGISTER [RFC3261] method, even for bulk operations [RFC6140], would likely be used rather than through any new interfaces defined by MODERN. Peterson & McGarry Informational [Page 15]
RFC 8396 MODERN Problems July 2018 18.104.22.168. CSP to Other CSPs After a User enrolls for service with a CSP, in the case where the CSP was assigned the TN by a Registrar, the CSP will then create a service address such as a SIP URI and associate it with the TN. The CSP needs to update this data to enable service interoperability. There are multiple ways that this update can occur, though most commonly service data is exposed through the retrieval interface (see Section 4.3). For certain deployment architectures, like a distributed data store model, CSPs may need to provision data directly to other CSPs. If the CSP is assigning a TN from its own inventory, it may not need to perform service data updates as change occurs because the existing service data associated with inventory may be sufficient once the TN is put in service. They would, however, likely update the Registry on the change in status. 184.108.40.206. User to CSP Users could also associate service data to their TNs at the CSP. An example would be a User acquiring a TN from the Registrar (as described in Section 4.1.1) and wanting to provide that TN to the CSP so the CSP can enable service. In this case, once the User provides the number to the CSP, the CSP would update the Registry or other actors as outlined in Section 188.8.131.52. 4.2.3. Managing Change This section will address some special management use cases that were not covered above. 18.104.22.168. Changing the CSP for an Existing Service Consider the case where a User who subscribes to a communication service (and who received their TN from that CSP) wishes to retain the same TN but move their service to a different CSP. In the simplest scenario, where there's an authoritative combined Registry/Registrar that maintains service data, the User could provide their credential to the new CSP and let the CSP initiate the change in service. The new CSP could then provide the new service data with the User's credential to the Registry/Registrar, which then makes the change. The old credential is revoked and a new one is provided. The new CSP or the Registrar would send a notification to the old CSP so they can disable service. The old CSP will undo any delegations to the User, including contacting the Credential Authority to revoke any cryptographic credentials (e.g., STIR Peterson & McGarry Informational [Page 16]
RFC 8396 MODERN Problems July 2018 certificates [RFC8226]) previously granted to the User. Any service data maintained by the CSP must be removed, and, similarly, the CSP must delete any such information it provisioned in the Registry. In a model similar to common practice in environments today, the User could alternatively provide their credential to the old CSP, and the old CSP would initiate the change in service. Or, a User could go directly to a Registrar to initiate a port. This framework should support all of these potential flows. Note that in cases with a distributed Registry that maintained service data, the Registry would also have to update the other Registries of the change. 126.96.36.199. Terminating a Service Consider a case where a User who subscribes to a communication service (and who received their TN from the CSP) wishes to terminate their service. At this time, the CSP will undo any delegations to the User, which may involve contacting the Credential Authority to revoke any cryptographic credentials (e.g., STIR certificates [RFC8226]) previously granted to the User. Any service data maintained by the CSP must be removed, and similarly, the CSP must delete any such information it provisioned in the Registrar. However, per the policy of the Numbering Authority, Registrars and CSPs may be required to preserve historical data that will be accessible to Government Entities or others through audits, even if it is no longer retrievable through service interfaces. The TN will change state from assigned to unassigned, and the CSP will update the Registry. Depending on policies, the TN could go back into the Registry, CSP, or delegate's pool of available TNs and would likely enter an aging process. In an alternative use case, a User who received their own TN assignment directly from a Registrar terminates their service with a CSP. At this time, the User might terminate their assignment from the Registrar and return the TN to the Registry for reassignment. Alternatively, they could retain the TN and elect to assign it to some other service at a later time. 4.3. Retrieval Retrieval of administrative or service data will be subject to access restrictions based on the category of the specific data: public, semi-restricted, or restricted. Both administrative and service data can have data elements that fall into each of these categories. It is expected that the majority of administrative data will fall into Peterson & McGarry Informational [Page 17]
RFC 8396 MODERN Problems July 2018 the semi-restricted category: access to this information may require some form of authorization, though service data crucial to reachability will need to be accessible. In some environments, it's possible that none of the service data necessary to initiate communication will be useful to an entity on the public Internet, or that all that service data will have dependencies on the origination point for calls. The retrieval protocol mechanism for semi-restricted and restricted data needs a way for the receiver of the request to identify the originator of the request and what is being requested. The receiver of the request will process that request based on this information. 4.3.1. Retrieval of Public Data Either administrative or service data may be made publicly available by the authority that generates and provisions it. Under most circumstances, a CSP wants its communication service to be publicly reachable through TNs, so the retrieval interface supports public interfaces that permit clients to query for service data about a TN. Some service data may, however, require that the client be authorized to receive it, per the use case in Section 4.3.3. Public data can simply be posted on websites or made available through a publicly available API. Public data hosted by a CSP may have a reference address at the Registry. 4.3.2. Retrieval of Semi-restricted Administrative Data Consider a case in which a CSP is having service problems completing calls to a specific TN, so it wants to contact the CSP serving that TN. The Registry authorizes the originating CSP to access this information. It initiates a query to the Registry, the Registry verifies the requestor and the requested data, and the Registry responds with the serving CSP and contact data. However, CSPs might not want to make those administrative contact points public data: they are willing to share them with other CSPs for troubleshooting purposes, but not to make them available to general communication. Alternatively, that information could be part of a distributed data store and not stored at a monolithic Registry. In that case, the CSP has the data in a local distributed data store, and it initiates the query to the local data store. The local data store responds with the CSP and contact data. No verification is necessary because it was done when the CSP was authorized to receive the data store. Peterson & McGarry Informational [Page 18]
RFC 8396 MODERN Problems July 2018 4.3.3. Retrieval of Semi-restricted Service Data Consider a case where a User on a CSP's network calls a TN. The CSP initiates a query for service data associated with the TN to complete the call and will receive special service data because the CSP operates in a closed environment where different CSPs receive different responses, and only participating CSPs can initiate communication. This service data would be flagged as semi- restricted. The query and response have real-time performance requirements in that environment. Semi-restricted service data also works in a distributed data store model where each CSP distributes its updated service data to all other CSPs. The originating CSP has the service data in its local data store and queries it. The local data store responds with the service data. The service data in the response can be a reference address to a data store maintained by the serving CSP or it can be the service address itself. In the case where the response gives a reference address, a subsequent query would go to the serving CSP, who would, in turn, authorize the requestor for the requested data and respond appropriately. In the case, where the original response contains the service address, the requestor would use that service address as the destination for the call. In some environments, aspects of the service data may reside at the Registry itself (for example, the assigned CSP for a TN); thus, the query may be sent to the Registry. The Registry verifies the requestor and the requested data and responds with the service data, such as a SIP URI containing the domain of the assigned CSP. 4.3.4. Retrieval of Restricted Data A Government Entity wishes to access information about a particular User who subscribes to a communication service. The entity that operates the Registry on behalf of the Numbering Authority in this case has some predefined relationship with the Government Entity. When the CSP acquired TNs from the Numbering Authority, it was a condition of that assignment that the CSP provide access for Government Entities to telephone numbering data when certain conditions apply. The required data may reside either in the CSP or in the Registrar. For a case where the CSP delegates a number to the User, the CSP might provision the Registrar (or itself, if the CSP is composed with a Registrar) with information relevant to the User. At such a time as the Government Entity needs information about that User, the Government Entity may contact the Registrar or CSP to acquire the necessary data. The interfaces necessary for this will be the same Peterson & McGarry Informational [Page 19]
RFC 8396 MODERN Problems July 2018 as those described in Section 4.3; the Government Entity will be authenticated and an authorization decision will be made by the Registrar or CSP under the policy dictates established by the Numbering Authority. 5. IANA Considerations This document has no IANA actions. 6. Privacy Considerations This framework defines two categories of information about telephone numbers: service data and administrative data. Service data describes how telephone numbers map to particular services and devices that provide real-time communication for users. As such, service data could potentially leak resource locations and even lower-layer network addresses associated with these services, and in rare cases, with end-user devices. Administrative data more broadly characterizes who the administrative entities are behind telephone numbers, which will often identify CSPs but some layers of the architecture could include Personally Identifiable Information (PII), even WHOIS-style information, about the end users behind identifiers. This could conceivably encompass the sorts of data that carriers and similar CSPs today keep about their customers for billing purposes, like real names and postal addresses. The exact nature of administrative data is not defined by this framework, and it is anticipated that the protocols that will perform this function will be extensible for different use cases, so at this point, it is difficult to characterize exactly how much PII might end up being housed by these services. As such, if an attacker were to compromise the registrar services that maintains administrative data in this architecture, and in some cases even service data, this could leak PII about end users. These interfaces, and the systems that host them, are a potentially attractive target for hackers and need to be hardened accordingly. Protocols that are selected to fulfill these functions must provide the security features described in Section 7. Finally, this framework recognizes that, in many jurisdictions, certain government agencies have a legal right to access service and administrative data maintained by CSPs. This access is typically aimed at identifying the users behind the communication identifier in order to enforce regulatory policy. Those legal entities already have the power to access the existing data held by CSPs in many jurisdictions, though, potentially, the administrative data associated with this framework could be richer information. Peterson & McGarry Informational [Page 20]
RFC 8396 MODERN Problems July 2018 7. Security Considerations The acquisition, management, and retrieval of administrative and service data associated with telephone numbers raises a number of security issues. Any mechanism that allows an individual or organization to acquire telephone numbers will require a means of mutual authentication, of integrity protection, and of confidentiality. A Registry as defined in this document will surely want to authenticate the source of an acquisition request as a first step in the authorization process to determine whether or not the resource will be granted. Integrity of both the request and response is essential to ensuring that tampering does not allow attackers to block acquisitions, or worse, to commandeer resources. Confidentiality is essential to preventing eavesdroppers from learning about allocations, including the personally identifying information associated with the administrative or technical contracts for allocations. A management interface for telephone numbers has similar requirements. Without proper authentication and authorization mechanisms in place, an attack could use the management interface to disrupt service data or administrative data, which could deny service to users, enable new impersonation attacks, prevent billing systems from operating properly, and cause similar system failures. Finally, a retrieval interface has its own needs for mutual authentication, integrity protection, and confidentiality. Any CSP sending a request to retrieve service data associated with a number will want to know that it is reaching the proper authority, that the response from that authority has not been tampered with in transit, and, in most cases, the CSP will not want to reveal to eavesdroppers the number it is requesting or the response that it has received. Similarly, any service answering such a query will want to have a means of authenticating the source of the query and of protecting the integrity and confidentiality of its responses. 8. Informative References [DRIP] Wendt, C. and H. Bellur, "Distributed Registry Protocol (DRiP)", Work in Progress, draft-wendt-modern-drip-02, July 2017. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>. Peterson & McGarry Informational [Page 21]
RFC 8396 MODERN Problems July 2018 [RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol Requirements", RFC 3375, DOI 10.17487/RFC3375, September 2002, <https://www.rfc-editor.org/info/rfc3375>. [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI 10.17487/RFC3912, September 2004, <https://www.rfc-editor.org/info/rfc3912>. [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 6116, DOI 10.17487/RFC6116, March 2011, <https://www.rfc-editor.org/info/rfc6116>. [RFC6140] Roach, A., "Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)", RFC 6140, DOI 10.17487/RFC6140, March 2011, <https://www.rfc-editor.org/info/rfc6140>. [RFC6461] Channabasappa, S., Ed., "Data for Reachability of Inter- /Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements", RFC 6461, DOI 10.17487/RFC6461, January 2012, <https://www.rfc-editor.org/info/rfc6461>. [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access Protocol (RDAP) Query Format", RFC 7482, DOI 10.17487/RFC7482, March 2015, <https://www.rfc-editor.org/info/rfc7482>. [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, February 2018, <https://www.rfc-editor.org/info/rfc8226>. [TERI-INFO] Peterson, J., "An Architecture and Information Model for Telephone-Related Information (TeRI)", Work in Progress, draft-peterson-modern-teri-04, March 2018. Acknowledgments We would like to thank Henning Schulzrinne and Adam Roach for their contributions to this problem statement and framework; we would also like to thank Pierce Gorman for detailed comments. Peterson & McGarry Informational [Page 22]
RFC 8396 MODERN Problems July 2018 Authors' Addresses Jon Peterson Neustar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 United States of America Email: firstname.lastname@example.com Tom McGarry Email: email@example.com Peterson & McGarry Informational [Page 23]


text:
TechRadar Verdict
Fast. Really fast, especially when given a bit of judicious tweaking, but way too pricey.
- +
Fastest card in the world (sorry)
- +
Great OC headroom
- -
- -
Mind-numbingly expensive
Why you can trust TechRadar
And here it is, the ATI Radeon HD 5970, the fastest graphics card in the world.
All hail its mighty rendering pathways and the gods of silicon for bringing us this technological wonder.
It's faster than any graphics card we've ever tested, it's bigger than any graphics card we've ever tested and it houses more technology than you could shake Stephen Hawking at. So why then are we feeling so utterly underwhelmed?
We had pricing issues with the original ATI Radeon HD 5870; its £320 price point making a mockery of AMD's previous successes with more svelte, cheaper cards than the monolithic strategy of its Nvidia rivals.
- Also read: 15 best graphics cards in the world today
In today's market such expensive cards are less viable purchases and more tech demos.
We're not just talking about the financial climate either, in this gaming world where most titles are developed for three year-old console technology you hardly need the sort of power such cards are touting, unless you've got a couple of 30-inch panels strapped together.
The same obviously rings true for a card that's sitting dangerously close to £600; it feels even less like a viable consumer card and more the sort of thing to ensure competition once Nvidia's DX11 Fermi cards hit our test benches in a month or so.
We're also slightly dubious as to how many of these cards you'll actually see in the wild. Reference and manufacturer boards have been made available to us, but we still find it difficult to track down any 5800-series cards in the country. Most retailers are out of stock - the supply just isn't there.
AMD assured us that the 5970 launch is coinciding with a ramping up of its 40nm production which should mean thousands of chips being produced every day.
Whether it will produce enough to cover demand for both 58xx series cards and the 5970 we'll have to wait and see.
But that's all by the by if the beast performs like the beast we're told it is.

subset: commoncrawl


text:
Alec Benjamin has been working on some new music, and recently released his latest single, "Different Kind Of Beautiful," and performed the track live for fans during his intimate iHeartRadio LIVE show.
In a first look at the performance, Benjamin sings a gorgeous rendition of the new song, accompanied only by a keyboardist as imagery of an ocean at night and the moon float on in the background.
Fans can set a reminder to can watch Alec's full iHeartRadio LIVE show on February 5th at 5pm PT/8pm ET in VR only in Meta Horizon Worlds. See him perform several fan favorites and talk about his new music and more during a special Q&A hosted by iHeartRadio's EJ.
"Different Kind Of Beautiful" follows the singer/songwriter's most recent album (Un)Commentary, which he released in 2022. The project included 13 tracks, including singles like "The Way You Felt," "Older," "Shadow of Mine," "Speakers" and "Devil Doesn't Bargain." Earlier this year, he joined John Mayer on his solo tour. In a statement, he said of the spring 2023 trek, "This tour was a dream come true .. you are as talented as you are kind .. I couldn't ask for a better friend & mentor."
Make sure to watch Alec's full iHeartRadio LIVE show on Monday, February 5th, 2024.


text:
November 15, 2012
By LAWT News Service
Los Angeles County Registrar-Recorder/County Clerk (RR/CC) Dean C. Logan announced the following updated semifinal results as of today, November 13, 2012.
The update includes 172,052 ballots processed since the last update. This count consists of only Vote by Mail ballots. For vote totals on specific contests, please visit lavote.net. This brings the updated estimate to approximately 521,710 to be counted.
Please remember that these results are subject to change throughout the canvass period. The next official update is scheduled for Friday, November 16, 2012 at 1 p.m. All results and updates will be posted online at lavote.net as they become available.
The mission of the Registrar-Recorder/County Clerk is to serve Los Angeles County by providing essential records management and election services in a fair, accessible and transparent manner. For more information, visit www.lavote.net.


text:
- Circus
- Dinky Dinkums
- Dinkum Dolls
- Cozy Dinkums
- Mushroom Luggy
- Original Luggy
- Strolley
- Wonder Wagon
- Dinkum Dolls
- Chari
- Piki
- Baskets
- Holdie
- Doll
- Playpa
- Dozy Dinkums
Shipping & Delivery
Orders placed before 10am PST will be processed same day. Orders placed on weekends or public holidays will be processed next business day. We will endeavour to process all orders within these times frames, however there may be delays during busy sale periods.
Once an order has been placed, please allow 3-5 business days for standard delivery. For Canada orders, please allow 5-7 days for delivery. Please note that these are estimated delivery times and depending on the postal network, this may vary slightly.
FedEx will arrange for the delivery of goods to the address provided as a preferred delivery address. Please make sure you provide a physical address as we do not ship to PO boxes.
Please note: If you have purchased any products on pre-order, please note that your entire order will be dispatched once all items are in stock.
If delivery is unsuccessful the customer will be responsible for any redelivery charges should they arise.
International orders - The company is not responsible for any import duties, taxes or delays that may occur during shipping.
Please note that we will be unable to cancel orders, change shipping methods or product during busy sale periods.
We ship all of our US domestic orders via FedEx. At this time USPS is the only entity that can deliver to a PO box or an APO, FPO or DPO address due to governmental security reasons.
So as not to delay your order, please ensure you provide a valid physical address at checkout.
Receive Free Standard Shipping storewide when you spend over $100 site wide. (For domestic orders within United States only. Excludes Alaska & Hawaii)
West Coast / West Central
Small Parcel: $7.95
Standard Parcel: $9.95
Large Parcel: $17.95
Oversize Parcel: $26.95
Rugs: $50
East Coast / East Central / Southern USA
Small Parcel: $9.95
Standard Parcel: $12.95
Large Parcel: $21.95
Oversize Parcel: $35
Rugs: $50
Standard Parcel: $45
Large Parcel: $85
Oversize Parcel: $300
Rugs: $250
Standard Parcel: $50
Large Parcel: $90
Oversize Parcel: $250
Rugs: $250
Small Parcel: $10.50
Standard Parcel: $35
Large Parcel: $85
Oversize Parcel: $150
Rugs: $220
We've carefully selected the shipping options for each product on our site to ensure you receive the fastest, safest, and most reliable delivery service possible. If you order an item that is marked as a large or oversize item, a delivery surcharge will apply. We deliver via FedEx (delivery in 3-5 days).
Please allow up to 5 business days for orders to be dispatched during busy sale or launch periods.
Our warehouse will be working overtime to ship out an increased volume of orders during sales periods so please keep this in mind, as we are unable to make any changes once your order has been finalized.
Once your order is dispatched you will receive shipping confirmation, plus tracking details for your order.
Great! We'll get that shipped out to you as soon as your item is in stock. Please note that if you have any items in your cart that are not on pre-order, your whole order will ship together once your pre-order item is in stock.
If you have any questions about this, simply reach out to our Customer Happiness team at email@example.com or catch them on the live chat, via our website.
Please note that we are be unable to cancel orders, change shipping methods or product after an order has been made.
Please note: Any delivery addresses received incomplete or that require changing on an order will delay the dispatch and delivery time.
As there is a small window between when you place your order and our warehouse team picking and packing it, we are often unable to change an address once the order has been placed. If you have entered the wrong address, please contact our customer happiness team immediately on email@example.com, ensuring your email subject title is "Urgent – Address Change" and they will do their best to try and catch it.
If you have received a tracking number already, we recommend giving your courier a call and asking them to redirect your order.
Olli Ella cannot be held accountable for failed deliveries resulting from an incorrect address entered at purchase. If your package is returned to sender, please contact us and we'll be happy to issue a store credit for the value paid, minus any shipping fees.
We ship to over 80 countries worldwide - view our Shipping Regions page for a full list of countries we ship to and select your shipping destination to see which site to order though.
Our warehouse is located in California, USA.
We work with FedEx for all our domestic and international orders
If you are ordering outside of the US please be aware of any fees your local customs office may charge before placing your order. As the payment and knowledge of taxes/duties that may apply to your purchase are your responsibility and Olli Ella cannot be held responsible for any charges.
If you choose not to pay duties on import and your parcel is returned to us. You will be issued with a credit note for the value of the products purchased only, less any shipping paid and an additional $10 will be deducted to cover return shipping costs.
View our Shipping Regions page for a full list of countries we ship to and select your shipping destination to see which site to order though.
Olli Ella is committed to delivering high quality products to our customers and we want you to be 100% happy with your online purchase.
We offer full refunds or store credit if the product does not meet quality standards or if you change your mind.
Returns must meet the below conditions:
- Is returned within 30 days of order delivery
- Has not been used or worn
- Is not soiled or damaged
- Has original packaging and tags
- Item was not purchased on sale
- If you have received a free item during a Gift/Buy One Get One Free promotion, this must also be returned, otherwise the value will be deducted from your refund
Due to hygiene reasons underWARES briefs are unable to be returned for a change of mind or incorrect size purchase.
If you opt for store credit for your return, we will waiver the return shipping fee.
If you prefer to return for a refund, for all change of mind returns, shipping is at the customer's expense.
To start your return, please click here and follow the prompts.
For Domestic Returns: Through the above link you will be able to generate a prepaid return postage label, which you will need to print and attach to your return package.
The postage fee will be calculated based on the item/s you are returning and will be deducted from your refund amount. If you opt for store credit this shipping fee will be waivered.
For International Returns, you will need to arrange your own shipping and send your return to:
ATT: Olli Ella Returns
C/O- Primary Freight Services
6545 Caballero Blvd
Buena Park, CA 90620
Please note returns sent to any other Olli Ella address will not be accepted and/or may incur a $20 redelivery fee
Please return your product in its original packaging and return within 30 days of receiving your order.
Packages received after this period will not be accepted.
Once we receive returned goods and they prove to be in original condition with packaging, we will process your store credit or refund directly to the original method of payment used for purchase.
If you need any further assistance with your return please contact our Customer Happiness Team at firstname.lastname@example.com
If your purchase is still within their returns window, please reach out to them directly and they will be more than happy to look after you.
We're so sorry to hear this!
For faulty or damaged items please click here and follow the prompts.
Once your image has been reviewed, we will get in touch with a resolution.
If you need further assistance with this please contact our Customer Happiness Team at email@example.com
We now offer free returns on WARES apparel (excludes underWARES briefs and bodysuits) for all domestic orders. You will receive a free shipping label inside your parcel. Easy!
For all change of mind returns on products outside of our WARES range, shipping is at the customers expense for refunds, or waivered when opting for store credit.
Please note shipping costs, sale items (sale apparel returns accepted) and gift certificates are non-refundable.
Recommended for you
Circus Tent Basket
Sold Out


text:
The sub-zero mornings can take their toll after a while, and there are few things that can quite reverse the effects of winter than a warm, open fireplace.
Subscribe now for unlimited access.
or signup to continue reading
If you don't happen to have one in your own home, or don't want to deal with the effort and mess that comes with running some of them, a number of venues around Canberra have done the hard work for you.
Cosy up and enjoy the gentle crackle of the fire plus a drink to warm your insides at one of these spots:
Pot Belly, Belconnen
This well-loved pub's main heat source is its namesake – the pot belly fire that has operated since the building was constructed in 1975. On a Friday and Saturday night, enjoy the fire with a side of live music. There are also pool tables close to the fire – just watch your seat doesn't get nabbed when you get up to take your shot.
Mercure Canberra, Braddon
If you're after old world charm, step into the doors at the Mercure Canberra, formerly Olims Hotel. Their original fireplace, built in 1927, now forms part of the bar and remains the focal point when you pass through reception. Classified by the National Trust of Australia, the building has been modernised over the years, while still keeping its original architecture and character. Order a drink and nestle into one of the oversized lounge chairs next to the log fire.
Old Canberra Inn, Lyneham
Also classified by the National Trust of Australia, the Old Canberra Inn houses two original fireplaces. The property has alternated between a homestead and a pub since 1860, and is now a favourite watering hole for locals and out-of-towners alike. The fires sit at either end of the main bar, most likely having originally been where the bedrooms sat. Pick your preferred fire spot, then relax with a drink – or stick around for a hearty lunch or dinner.
Monster at Hotel Hotel, New Acton
There's something already quite warming about this hotel foyer, despite its industrial furnishings, but the elongated "fire pit" takes pride of place. While it may only be gas, the two long rows of flame put out plenty of warmth, and there is ample bench and couch seating surrounding it to maximise your chance of getting a spot.
Walt and Burley, Kingston Foreshore
As one of the more recent additions to the Kingston Foreshore, at Walt and Burley you can almost sit by the fire and simultaneously enjoy lake views. While fire-side position is popular, there are three large couches surrounding the fireplace, meaning there's a slightly lower chance you'll be fighting for prime position.
Grazing at Gundaroo
If you're happy to take a short drive out of town, Grazing At Gundaroo offers not one, not two but six separate open fireplaces, that have all been in use for 150 years. If you just want to pop in for a quick drink, the cellar door houses one of them. Otherwise stay for lunch or dinner at the award-winning restaurant to enjoy the other five. Bookings are recommended, and while it can't be guaranteed, it never hurts to put in a request to dine right next to one of the fires.
What's your favourite establishment to enjoy a beverage by the fire? Let us know in the comments below.


text:
Two trains are swept into a canyon by an avalanche in Wellington, Washington, on March 1, 1910, killing 96 people. Due to the remote location of the disaster and the risk of further avalanches, efforts to rescue survivors and find the bodies of the dead were not completed until several days later.
The Great Northern Railroad's westbound Spokane Express left for Seattle, Washington, from Spokane on February 23. On February 26, a blizzard in Washington caused high snow drifts in the Cascade Mountains that blocked the rail lines. Despite many workers attempting to clear the tracks, the train was still stuck in Wellington, a small village in King County just past the Stevens Pass, nearly a week later. The area's telegraph lines had come down in the storm, and there was little passengers or train personnel could do but wait out the storm.
The Wellington train station was located near the base of Windy Mountain, but had no protective cover. On February 28, weather conditions changed, with temperatures dropping and thunderstorms battering the area. In Idaho, several miners died in an avalanche, and flooding imperiled residents of low-lying areas. At 4:20 a.m. the following morning, with approximately 50 passengers and 75 employees of Great Northern Railroad sleeping in the Spokane Express, an avalanche of snow crashed down Windy Mountain, prompted by a combination of rain, lighting and thunder.
Charles Andrews, a rail worker and resident of Wellington who witnessed the disaster, described the scene: White Death moving down the mountainside above the trains. Relentlessly it advanced, exploding, roaring, rumbling, grinding and snapping. The Spokane Express and a mail train were both thrown from the tracks down a nearby gorge 150 feet deep. The Wellington station was wiped away, though the town's hotel and store were untouched.
At the bottom of the gorge, the trains were covered by 40 to 70 feet of snow and debris. Because the telegraph lines were down, the people of Wellington were unable to call for immediate assistance. Despite the risk of further avalanches, many people pitched in to try to dig out survivors; it was not until the night of March 2 that assistance from outside Wellington was able to reach the site. By that time, 23 people had been pulled out alive, most with serious injuries. It took over a week to recover the bodies of all 96 victims of the avalanche, which then had to be moved by toboggan to the rail lines for further transport.
In the aftermath of this tragedy, the worst in Washington's history to that time, the town of Wellington was renamed Tye and new rail lines with protective tunnels were established; the old line is now a popular hiking trail. Lessons were also learned about the dangers of clear-cutting timber on mountains above towns and villages, a practice that was partially responsible for the avalanche.


text:
(SOLVED) A 14yo male returns to clinic for a well child exam.
Discipline: Nursing
Type of Paper: Essay (any type)
Academic Level: Undergrad. (yrs 1-2)
Paper Format: APA
Pages: 2
Words: 649
A 14yo male returns to clinic for a well child exam. His last visit was 12 months ago at 13 yo. He received TdaP, Meningoccal vaccine and HPV#1 at age 12, HPV #2 at age 13. Today he is due for HPV#3
A. True
B. False
Expert Solution Preview
Step 1/2
A. True
The Centers for Disease Control and Prevention (CDC) recommends that the HPV vaccine be given to girls and boys between ages 11 and 12. It can be given as early as age 9. It's ideal for girls and boys to receive the vaccine before they have sexual contact and are exposed to HPV. Research has shown that receiving the vaccine at a young age isn't linked to an earlier start of sexual activity.
Once someone is infected with HPV.......


text:
Some of the first usage data is in from Bay Area Bike Share. The data is rough, but the number of trips in the first 12 days is underwhelming compared to bike-share launches in New York or Washington, DC.
The Bay Area Quality Management District is still working on getting a real-time data platform set up, but it "will likely not be available in the short term," said agency spokesperson Ralph Borrmann.
Here are the data points they provided from August 28 (launch day) to September 8:
- 1790 = Total Registered Annual Members
- 2128 = Total Casual (1 and 3 day) Members
- 7691 = Total Trips Taken (system wide)
Divided by the 12 days in the data set, this works out to about 0.92 trips per bike per day. It doesn't quite stack up to NYC's Citi Bike, which hit 1.24 trips in the first two days, or DC's Capital Bikeshare, which had 1.05 trips in its first 10 days. Of course, it's still very early, and these usage numbers will change. On peak days, Citi Bike now hits seven trips per bike and on routine days averages between five and six trips per bike.
BABS' results aren't surprising, either, since bike-share proponents have warned that the small initial size of the system will limit its usefulness.
Even with the relatively low level of usage, there have still been anecdotal reports of stations reaching capacity, suggesting the system may have trouble maintaining balance. SF Weekly featured an interview with Mike Sonn last week (many of our readers may know him from the comments section), who uses BABS to commute from North Beach to Redwood City via Caltrain. Sonn said he's arrived at a full dock at the 4th and King Station, forcing him to find another dock with a free space and walk back.
Major rail hubs in New York and London have been the hardest places for bike-share managers to maintain balanced stations with both bikes and docks available. Borrmann told SF weekly they're "still learning the movement patterns for the bikes."