idnits 2.17.1 draft-ietf-ieprep-ets-telephony-07.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: ---------------------------------------------------------------------------- == 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 6 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 abstract seems to contain references ([2]), 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 119: '... telephony MUST be able to carry l...' RFC 2119 keyword, line 121: '... to carry labels MUST be extensible to...' RFC 2119 keyword, line 126: '...signaling labels SHOULD have a mapping...' RFC 2119 keyword, line 137: '...lephony capabilities MUST NOT preclude...' RFC 2119 keyword, line 146: '...lace to recognize ETS type labels MUST...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [5], but that reference does not seem to mention RFC 2119 either. -- 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? '2' on line 225 looks like a reference -- Missing reference section? '5' on line 44 looks like a reference -- Missing reference section? '4' on line 66 looks like a reference -- Missing reference section? '3' on line 85 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 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 November 28, 2003 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 [2]. 37 Solutions to these requirements are not presented in this document. 39 Conventions Used In This Document 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in [5]. 45 1. Introduction 47 Effective telecommunications capabilities can be imperative to 48 facilitate immediate recovery operations for serious disaster events, 50 ^L 51 such as, hurricanes, floods, earthquakes, and terrorist attacks. 52 Disasters can happen any time, any place, unexpectedly. Quick 53 response for recovery operations requires immediate access to any 54 public telecommunications capabilities at hand. These capabilities 55 include: conventional telephone, cellular phones, and Internet 56 access via online terminals, IP telephones, and wireless Personal 57 Digital Assistants (PDAs). The commercial telecommunications 58 infrastructure is rapidly evolving to Internet-based technology. 59 Therefore, the Internet community needs to consider how it can best 60 support emergency management and recovery operations. 62 1.1 Problem 64 Standards have been developed by other standards bodies concerning 65 emergency communications. As discussed in [2], some of these 66 standards, such as T1.631 [4], define specific indicators or labels 67 for emergency communications in Signaling System 7 (SS7) networks. 68 Certain requirements must be defined in order to achieve peering 69 across hybrid networks (networks that communicate between IP and 70 other types of networks such as that realized by the Public Switched 71 Telephone Network) in order to achieve an interworking of services. 73 2. Scope 75 [2] has defined a set of general system requirements to support 76 Emergency Telecommunications Service (ETS). This document defines an 77 additional set of system requirements to achieve support for ETS 78 within the specific context of IP telephony (note that this document 79 views IP telephony within the context of an end-to-end application 80 layer service). Solutions to requirements are not defined. The 81 document does not specify protocol enhancements or specifications. 83 Note that [3], Requirements for Resource Priority Mechanisms for the 84 Session Initiation Protocol (SIP), is an RFC that shares some overlap 85 with this document. However, [3] only applies to SIP and is not 86 meant to be applied to a more general perspective of IP telephony as 87 it relates to ETS. 89 2.1 Out of Scope 91 An item that is not in scope of this document is mandating acceptance 92 and support of the requirements presented in this document. The IETF 93 does not mandate requirements or capabilities to independent networks 94 that comprise the Internet. As an example, Internet Service 95 Providers (ISP) may choose not to operate any telephony-related 96 gateways or services. The IETF cannot and does not mandate that an 97 ISP deploy either telephony-related gateways or telephony-related 98 services. There is an expectation that business contracts, for 100 ^L 101 example Service Level Agreements (SLA), will be used to satisfy those 102 following requirements that apply to service providers. Absence of 103 an SLA implies best effort service is provided. 105 It is assumed that some ISPs will choose to offer ETS services and 106 that other carriers will choose not to offer ETS services. These 107 requirements do not apply to ISPs that have chosen not to offer ETS 108 services. 110 3. IP Telephony Requirements 112 The requirements in this section relate only to Telephony Signaling 113 as used in Internet-based telephony services. They are an extension 114 to the general requirements specified in [2]. The following 115 requirements explicitly do not relate to IP-layer mechanisms, such as 116 Differentiated Services or Integrated Services. 118 1) Telephony signaling applications used with Internet-based 119 telephony MUST be able to carry labels. 121 2) The ability to carry labels MUST be extensible to support 122 various types and numbers of labels. A single binary value will 123 not be sufficient given the various labeling standards in existence 124 today. 126 3) Telephony signaling labels SHOULD have a mapping with the 127 various emergency related labels/markings used in other telephony 128 based networks, such as the Public Switched Telephone Network 129 (PSTN). This ensures that a telephone call placed over a hybrid 130 infrastructure (traditional PSTN over some portion(s) of the path, 131 Internet telephony over some other portion(s) of the path) can 132 carry the labels end-to-end with appropriate translation at 133 PSTN/Internet boundaries. Absence of a mapping means that the 134 signaling reverts to a default service (presumably one attributed 135 to the general public). 137 4) Application layer IP telephony capabilities MUST NOT preclude 138 the ability to do application layer accounting. 140 Accounting is a useful feature in support of billing and tracking 141 down abuse of service. If specific solutions or protocols in 142 support of ETS require accounting, then this will be articulated 143 in future document(s). 145 5) Application layer mechanisms in gateways and stateful proxies 146 that are specifically in place to recognize ETS type labels MUST 147 be able to support "best available" service (this will probably be 148 realized as better than best effort). These labels MAY exist in 150 ^L 151 the application layer headers of data (i.e., bearer) traffic or 152 signaling traffic used for call completion. 154 The support for best available service SHOULD focus on 155 probability of forwarding packets. Probability MAY reach 100% 156 depending on the local policy associated with the label. Local 157 policy MUST also be used to determine if better than best effort 158 is to be applied to a specific label (or related set of labels). 159 Additional comments on this topic are presented below in item 2 160 of section 4. 162 The above paragraphs MUST be taken in their entirety. The ability 163 to support best available service does not mean that the 164 application layer mechanism is expected to be activated. Further, 165 we do not define the means by which best available service is 166 realized. Application layer mechanisms that do not recognize 167 ETS type labels are not subject to this requirement. 169 4. Issues 171 This section presents issues that arise in considering solutions for 172 the telephony requirements that have been defined for ETS. This 173 section does not specify solutions nor is it to be confused with 174 requirements. Subsequent documents that articulate a more specific 175 set of requirements for a particular service may make a statement 176 about the following issues. 178 1) Alternate paths 180 Experience with The Government Emergency Telecommunications 181 Service (GETS) over the PSTN has shown the utility of 182 alternate paths to a destination to help facilitate 183 emergency-related communications. From the perspective of the 184 Internet, this utility may be difficult to achieve and have a 185 more limited benefit. Unlike the PSTN, which creates a fixed 186 path during call setup phase, the Internet uses dynamic routing 187 for IP packets. This dynamic routing capability automatically 188 causes IP packets to travel the best current path. The Internet 189 network infrastructure does not have the concept of a "call" or 190 the concept of "call setup", though IP telephony applications 191 might have application layer awareness of calls or the call 192 setup concept. 194 2) Application of Best Available Service 196 In item 5 of section 3 above, we discuss the requirement of 197 supporting best available service. We note that in this 199 ^L 200 document, the scope of that support is constrained to the 201 application layer and flows that traverse that layer. This 202 may involve direct support for the flow containing the ETS 203 type label, or may involve indirect support (e.g., ETS labels 204 in signaling messages that causes an effect on corresponding 205 data or bearer flows). 207 It is critical to understand that how the support for best 208 available service can be realized is outside the scope of this 209 document. In addition, the perceived effectiveness of a given 210 approach or implementation also outside the scope of this 211 document. 213 5. Security 215 Only authorized users or operators SHOULD be able to create non- 216 ordinary Labels (i.e., labels that may alter the default best effort 217 service. Labels SHOULD be associated with mechanisms to provide 218 strong end-to-end integrity during their transmission through the 219 telephony systems. Finally, in cases where labels are expected to be 220 acted upon by operators, these operators SHOULD have the capability 221 of authenticating the label on a received message or transmission in 222 order to prevent theft of service and reduce risk of denial of 223 service (e.g. by unauthorized users consuming any limited resources). 225 Security is also discussed in the general requirements of [2], which 226 applies to section 3 above. 228 Normative References 230 There are no Normative References because this is an Informational 231 document. 233 Informative References 235 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 236 9, RFC 2026, October 1996. 238 2 Carlberg, K., Atkinson, R., "General System Requirements for 239 Emergency Telecommunications Service", Internet Draft, 240 Work In Progress, September, 2002 242 3 Schulzrinne, H., "Requirements for Resource Priority Mechanisms 243 for the Session Initiation Protocol (SIP)", RFC 3487, February, 244 2003. 246 ^L 248 4 ANSI, "Signaling System No. 7(SS7): High Probability of 249 Completion (HPC) Network Capability", ANSI T1.631, 1993. 251 5 Bradner, S., "Key words for use in RFCs to Indicate Requirement 252 Levels", RFC 2119, March 1997. 254 Author's Addresses 256 Ken Carlberg Ran Atkinson 257 University College London Extreme Networks 258 Department of Computer Science 3585 Monroe Street 259 Gower Street Santa Clara, CA 260 London, WC1E 6BT 95051 USA 261 United Kingdom 262 k.carlberg@cs.ucl.ac.uk rja@extremenetworks.com 264 Full Copyright Statement 266 Copyright (C) The Internet Society (2003). All Rights Reserved. 267 This document and translations of it may be copied and furnished to 268 others, and derivative works that comment on or otherwise explain it 269 or assist in its implementation may be prepared, copied, published 270 and distributed, in whole or in part, without restriction of any 271 kind, provided that the above copyright notice and this paragraph are 272 included on all such copies and derivative works. However, this 273 document itself may not be modified in any way, such as by removing 274 the copyright notice or references to the Internet Society or other 275 Internet organizations, except as needed for the purpose of 276 developing Internet standards in which case the procedures for 277 copyrights defined in the Internet Standards process must be 278 followed, or as required to translate it into languages other than 279 English. 281 The limited permissions granted above are perpetual and will not be 282 revoked by the Internet Society or its successors or assigns. 284 This document and the information contained herein is provided as an 285 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 286 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 287 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 288 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR 289 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE.