idnits 2.17.1 draft-carlberg-ets-telephony-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 107: '... telephony MUST be able to carry l...' RFC 2119 keyword, line 109: '... to carry labels MUST be extensible to...' RFC 2119 keyword, line 114: '...ignalling labels SHOULD have a mapping...' RFC 2119 keyword, line 125: '... to the PSTN MAY support applicati...' RFC 2119 keyword, line 126: '... These applications MUST NOT preclude...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 15 looks like a reference -- Missing reference section? '3' on line 59 looks like a reference -- Missing reference section? '2' on line 170 looks like a reference -- Missing reference section? '4' on line 60 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Ken Carlberg 3 INTERNET DRAFT UCL 4 December, 2002 Ran Atkinson 5 Extreme Networks 7 IP Telephony Requirements for 8 Emergency Telecommunication Service 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 [1]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 26 Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 For potential updates to the above required-text see: 30 http://www.ietf.org/ietf/1id-guidelines.txt 32 Abstract 34 This document presents a list of requirements in support of Emergency 35 Telecommunications Service (ETS) within the context of IP telephony. 36 It is an extension to the general requirements presented in [3]. 37 Solutions to these requirements are not presented in this document. 39 1. Introduction 41 Effective telecommunications capabilities can be imperative to 42 facilitate immediate recovery operations for serious disaster events, 43 such as, hurricanes, floods, earthquakes, and terrorist attacks. 44 Disasters can happen any time, any place, unexpectedly. Quick 45 response for recovery operations requires immediate access to any 46 public telecommunications capabilities at hand. These capabilities 47 include: conventional telephone, cellular phones, and Internet 48 access via online terminals, IP telephones, and wireless PDAs. The 50 ^L 51 commercial telecommunications infrastructure is rapidly evolving to 52 Internet-based technology. Therefore, the Internet community needs to 53 consider how it can best support emergency management and recovery 54 operations. 56 1.1 Problem 58 Standards have been developed by other standards bodies concerning 59 emergency communications. As discussed in [2] and [3], some of these 60 standards, such as T1.631 [4], define specific indicators or labels 61 for emergency communications in SS7 networks. Certain requirements 62 must be defined in order to achieve peering services across hybrid 63 networks (networks that communicate between IP and other types of 64 networks such as that realized by the Public Switched Telephone 65 Network). 67 2. Scope 69 [2] has defined a set of general system requirements to support 70 Emergency Telecommunications Service (ETS). This document defines an 71 additional set of system requirements to achieve support for ETS 72 within the specific context of IP telephony (note that this document 73 views IP telephony within the context of an end-to-end application 74 layer service). Solutions to requirements are not defined. The 75 document does not specify protocol enhancements or specifications. 77 2.1 Out of Scope 79 An item that is not in scope of this document is mandating acceptance 80 and support of the requirements presented in this document. The IETF 81 does not mandate requirements or capabilities to independent networks 82 that comprise the Internet. As an example, Internet Service 83 Providers (ISP) may choose not to operate any telephony-related 84 gateways or services. The IETF cannot and does not mandate that an 85 ISP deploy either telephony-related gateways or telephony-related 86 services. There is an expectation that business contracts, for 87 example Service Level Agreements (SLA), will be used to satisfy those 88 following requirements that apply to service providers. Absence of 89 an SLA implies best effort service is provided. 91 It is assumed that some ISPs will choose to offer ETS services and 92 that other carriers will choose not to offer ETS services. These 93 requirements do not apply to ISPs that have chosen not to offer ETS 94 services. 96 3. IP Telephony Requirements 98 The requirements in this section relate only to Telephony Signalling 100 ^L 101 as used in Internet-based telephony services. They are an extension 102 to the general requirements specified in [2]. The following 103 requirements explicitly do not relate to IP-layer mechanisms, such as 104 Differentiated Services or Integrated Services. 106 1) Telephony signalling applications used with Internet-based 107 telephony MUST be able to carry labels. 109 2) The ability to carry labels MUST be extensible to support 110 various types and numbers of labels. A single binary value will 111 not be sufficient given the various labeling standards in existance 112 today. 114 3) Telephony signalling labels SHOULD have a mapping with the 115 various emergency related labels/markings used in other telephony 116 based networks, such as the PSTN. This ensures that a telephone 117 call placed over a hybrid infrastructure (traditional PSTN over 118 some portion(s) of the path, Internet telephony over some other 119 portion(s) of the path) can carry the labels end-to-end with 120 appropriate translation at PSTN/Internet boundaries. Absence of 121 a mapping means that the signaling reverts to a default service 122 (presumably one attributed to the general public). 124 4) Hybrid infrastructures that include and support connectivity 125 to the PSTN MAY support application layer accounting within IP 126 telephony applications. These applications MUST NOT preclude 127 the ability to do accounting. 129 4. Issues 131 This section presents issues that arise in considering solutions for 132 the telephony requirements that have been defined for ETS. This 133 section does not specify solutions nor is it to be confused with 134 requirements. Subsequent documents that articulate a more specific 135 set of requirements for a particular service may make a statement 136 about the following issues. 138 1) Alternate paths 140 Experience with GETS over the PSTN has shown the utility of 141 alternate paths to a destination to help facilitate 142 emergency-related communications. From the perspective of the 143 Internet, this utility may be difficult to achieve and have a 144 more limited benefit. Unlike the PSTN, which creates a fixed 145 path during call setup phase, the Internet uses dynamic routing 146 for IP packets. This dynamic routing capability automatically 147 causes IP packets to travel the best current path. The Internet 149 ^L 150 infrastructure does not have the concept of a "call" or the 151 concept of "call setup", though IP telephony applications might 152 have application-layer awareness of calls or the call setup 153 concept. 155 Alternate path routing at the application layer may be useful 156 in choosing one of possibly several egress points to the PSTN 157 from the Internet. 159 5. Security 161 Only authorised users or operators SHOULD be able to create non- 162 ordinary labels. Labels SHOULD have mechanisms to provide strong 163 end-to-end integrity during their transmission through the telephony 164 systems. Finally, in cases where labels are expected to be acted 165 upon by operators, these operators SHOULD have the capability of 166 authenticating the label on a received message or transmission in 167 order to prevent theft of service and reduce risk of denial of 168 service (e.g. by unauthorised users consuming any limited resources). 170 Security is also discussed in the general requirements of [2], which 171 applies to section 3 above. 173 6. References 175 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 176 9, RFC 2026, October 1996. 178 2 Carlberg, K., Atkinson, R., "General System Requirements for 179 Emergency Telecommunications Service", Internet Draft, 180 Work In Progress, September, 2002 182 3 Folts, H., et. al., "User Requirements for Emergency 183 Telecommunications Service", Internet Draft, Work In 184 Progress, September 2002 186 4 ANSI, "Signaling System No. 7(SS7): High Probability of 187 Completion (HPC) Network Capability, ANSI T1.631, 1993. 189 ^L 191 7. Author's Addresses 193 Ken Carlberg Ran Atkinson 194 University College London Extreme Networks 195 Department of Computer Science 3585 Monroe Street 196 Gower Street Santa Clara, CA 197 London, WC1E 6BT 95051 USA 198 United Kingdom 199 k.carlberg@cs.ucl.ac.uk rja@extremenetworks.com 201 Full Copyright Statement 203 "Copyright (C) The Internet Society (date). All Rights Reserved. 204 This document and translations of it may be copied and furnished to 205 others, and derivative works that comment on or otherwise explain it 206 or assist in its implementation may be prepared, copied, published 207 and distributed, in whole or in part, without restriction of any 208 kind, provided that the above copyright notice and this paragraph are 209 included on all such copies and derivative works. However, this 210 document itself may not be modified in any way, such as by removing 211 the copyright notice or references to the Internet Society or other 212 Internet organizations, except as needed for the purpose of 213 developing Internet standards in which case the procedures for 214 copyrights defined in the Internet Standards process must be 215 followed, or as required to translate it into languages other than 216 English. 218 The limited permissions granted above are perpetual and will not be 219 revoked by the Internet Society or its successors or assigns. 221 This document and the information contained herein is provided as an 222 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 223 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 224 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 225 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR 226 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE.