idnits 2.17.1 draft-ietf-ieprep-domain-req-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 362. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 352. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 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 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 157: '... label mechanisms used for ETS MUST be...' RFC 2119 keyword, line 159: '... mechanism MUST avoid a single off/o...' RFC 2119 keyword, line 160: '...s of such a mechanism MUST assume that...' RFC 2119 keyword, line 163: '...sms used for ETS SHOULD be extensible ...' RFC 2119 keyword, line 171: '... Proxies MAY set ETS labels on behal...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (Nov 17, 2005) is 6727 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 4 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 G11 4 Nov 17, 2005 6 Emergency Telecommunications Services (ETS) Requirements 7 for a Single Administrative Domain 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). 37 Abstract 39 This document presents a list of requirements in support of Emergency 40 Telecommunications Service (ETS) within a single administrative 41 domain. This document is an extension of the General Requirements of 42 [rfc3689] and focuses on a more specific set of administrative 43 constraints and scope. Solutions to these requirements are not 44 presented in this document. 46 1. Introduction 48 The objective of this document is to define a set of requirements 49 that support ETS within a single domain. There have been a number of 50 discussions in the IEPREP mailing list, as well as working group 51 meetings, that have questioned the utility of a given mechanism to 52 support ETS. Many have advocated over-provisioning, while others 53 have favored specific schemas to provide a quantifiable measure of 54 service. One constant in these discussions is that the 55 administrative control of the resources plays a significant role in 56 the effectiveness of any proposed solution. Specifically, if one 57 administers a set of resources, a wide variety of approaches can be 58 deployed upon that set. However, once the approach crosses an 59 administrative boundary, its effectiveness comes into question, and 60 at a minimum requires cooperation and trust from other administrative 61 domains. To avoid this question, we constrain our scenario to the 62 resources within a single domain. 64 The following provides an explanation of some key terms used in this 65 document. 67 Resource: A resource can be a viewed from the general level as IP 68 nodes such as a router or host as well as the physical media 69 (e.g., fiber) used to connect them. A host can also be referred 70 to in more specific terms as a client, server, or proxy. 71 Resources can also be viewed more specifically in terms of the 72 elements within a node (e.g., CPU, buffer, memory). However, 73 this document shall focus its attention at the node level. 75 Domain: This term has been used in many ways. We constrain its 76 usage in this document to the perspective of the network layer, 77 and view it as being synonymous with an administrative domain. 78 A domain may span large geographic regions and may consist of 79 many types of physical subnetworks. 81 Administrative Domain: The collection of resources under the 82 control of a single administrative authority. This authority 83 establishes the design and operation of a set of resources 84 (i.e., the network). 86 Transit Domain: This is an administrative domain used to forward 87 traffic from one domain to another. An Internet Service Provider 88 (ISP) is an example of a transit domain. 90 Stub Domain: This is an administrative domain that is either the 91 source or the destination of a flow of IP packets. As a general 92 rule, it does not forward traffic that is destined for other 93 domains. The odd exception to this statement is the case of 94 Mobile IP and its use of "dog-leg" routing to visiting hosts 95 located in foreign networks. An enterprise network is an example 96 of a stub domain. 98 1.1 Previous Work 100 A list of General Requirements for support of ETS is presented in 101 [rfc3689]. The document articulates requirements when considering 102 the broad case of supporting ETS over the Internet. Since that 103 document is not constrained to specific applications, administrative 104 boundaries, or scenarios, the requirements contained within it tend 105 to be quite general in their description and scope. This follows the 106 philosophy behind its inception in that the General Requirements are 107 meant to be a baseline followed (if necessary) by more specific 108 requirements that pertain to a more narrow scope. 110 The requirements presented below in Section 3 are representative of 111 the more narrow scope of a single administrative domain. As in the 112 case of [rfc3689], the requirements articulated in this document 113 represent aspects to be taken into consideration when solutions are 114 being designed, specified, and deployed. Key words such as "MUST", 115 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 116 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 117 interpreted as described in [rfc2119]. 119 2. Scope 121 IETF standards that cover the resources within an administrative 122 domain are within the scope of this document. This includes 123 gateways, routers, servers, etc., that are located and administered 124 within the domain. This document also does not restrict itself to a 125 specific type of application such as Voice over IP. 127 QoS mechanisms are also within the scope of this document. These 128 mechanisms may reside at the application, transport, or IP network 129 layer. While QoS mechanisms may exist at the link/physical layer, 130 this document would only consider potential mappings of labels or 131 code points. 133 Finally, since this document focuses on a single administrative 134 domain, we do not make any further distinction between transit and 135 stub domains within this document. 137 2.1 Out of Scope: 139 Resources owned or operated by other administrative authorities are 140 outside the scope of this document. One example are SIP servers that 141 operate in other domains. Another example are access links 142 connecting the stub domain and its provider. Controlling only 1/2 of 143 a link (the egress traffic from the stub) is considered insufficient 144 for including inter-domain access links as a subject for this 145 document. 147 3. Requirements 149 It must be understood that all of the following requirements pertain 150 to mechanisms chosen by a domain's administrative authority to 151 specifically support ETS. If that authority chooses not to support 152 ETS or if these mechanisms exist within the domain exclusively for a 153 different purpose, then the associated requirement does not apply. 155 3.1 Label Mechanisms 157 Application or transport layer label mechanisms used for ETS MUST be 158 extensible such that they can support more than one label. These 159 mechanism MUST avoid a single off/on type of label (e.g., a single 160 bit). In addition, designers of such a mechanism MUST assume that 161 there may be more than one set of ETS users. 163 Network layer label mechanisms used for ETS SHOULD be extensible such 164 that they can support more than one label. We make this distinction 165 in requirements because there may be fewer bits (a smaller field) 166 available at the network layer than in the transport or application 167 layer. 169 3.2 Proxies 171 Proxies MAY set ETS labels on behalf of the source of a flow. This 172 may involve removing labels that have been set by upstream node(s). 174 If proxies take such action, then the security measures discussed in 175 [rfc3689] MUST be considered. More information about security in the 176 single domain context is found below in Section 5. 178 3.3 QoS mechanisms 180 [rfc3689] defines a label as an identifier, and the set of 181 characteristics associated with the label as policy. However, 182 Quality of Service (QoS) in the traditional sense of delay or 183 bandwidth is not automatically bound to a label. MPLS [rfc3031] is 184 an example of a labeling mechanism that can provide specific QoS or 185 simply traffic engineering of labeled flows. 187 In the context of ETS, QoS mechanisms, at either the network or 188 application layer, SHOULD be used when networks cannot be over- 189 provisioned to satisfy high bursts of traffic load. Examples can 190 involve bridging fiber networks to wireless subnetworks, or remote 191 subnetworks connected over expensive bandwidth constrained wide area 192 links. 194 Note well. Over-provisioning is a normal cost-effective practice 195 amongst network administrators/engineers. The amount of over- 196 provisioning can be a topic of debate. More in-depth discussion on 197 this topic is presented in the companion Framework document of 198 [frame]. 200 3.4 Users 202 Regarding existing IETF specified applications, augmentations in the 203 form of labeling mechanisms to support ETS MUST NOT adversely affect 204 its legacy usage by non-ETS users. With respect to future 205 applications, such labeling mechanisms SHOULD allow the application 206 to support a "normal" (non-emergency) condition. 208 3.5 Policy 210 Policy MUST be used to determine the percentage of resources of a 211 mechanism used to support the various (ETS and non-ETS) users. Under 212 certain conditions, this percentage MAY reach 100% for a specific set 213 of users. However, we recommend that this "all-or-nothing" approach 214 be considered with great care. 216 3.6 Discovery 218 There should be a means of forwarding ETS labeled flows to those 219 mechanisms within the domain used to support ETS. Discovery 220 mechanisms SHOULD be used to determine where ETS labeled flows 221 (either data or control) are to be forwarded. 223 3.8 MIB 225 Management Information Bases (MIBs) SHOULD be defined for mechanisms 226 specifically in place to support ETS. These MIBs MAY include objects 227 representing accounting, policy, authorization. 229 4. Issues 231 This section presents issues that arise in considering solutions for 232 the requirements that have been defined for Stub Domains that support 233 ETS. This section does not specify solutions nor is it to be 234 confused with requirements. Subsequent documents that articulate a 235 more specific set of requirements for a particular service may make a 236 statement about the following issues. 238 4.1 Alternative Services 240 The form of the service provided to ETS users and articulated in the 241 form of policies may be realized in one of several forms. Better 242 than best effort is probably the service that most ETS users would 243 expect when the communication system is stressed and overall quality 244 has degraded. However, the concept of best available service should 245 also be considered under such stressed conditions. Further, a 246 measure of degraded service may also be desirable to ensure a measure 247 of communication versus none. These services may be made available 248 at the network or application layer. 250 4.2 Redundancy 252 The issue of making networks fault tolerant is important and yet not 253 one that can be easily articulated in terms of requirements of 254 protocols. Redundancy in connectivity and nodes (be it routers or 255 servers) is probably the most common approach taken by network 256 administrators, and it can be assumed that administrative domains 257 apply this approach in various degrees to there own resources. 259 5. Security Considerations 261 This document recommends that readers review and follow the comments 262 and requirements about security presented in [rfc3689]. Having said 263 that, there tends to be many instances where intra-domain security is 264 held at a lower standard (i.e., less stringent) that inter-domain 265 security. For example, while administrators may allow telnet service 266 between resources within an administrative domain, they would only 267 allow SSH access from other domains. 269 The disparity in security policy can be problematic when domains 270 offer services other than best effort for ETS users. Therefore, any 271 support within a domain for ETS should be accompanied by a detailed 272 security policy for users and administrators. 274 Given the "SHOULD" statement in section 3.8 concerning MIBs, there 275 are a number of related security considerations that need to be 276 brought to attention to the reader. Specifically, 278 - Most current deployments of SNMP are of versions prior to 279 SNMPv3, even though there are well-known security 280 vulnerabilities in those versions of SNMP. 282 - SNMP versions prior to SNMPv3 cannot support cryptographic 283 security mechanisms. Hence, any use of SNMP prior to 284 version 3 to write or modify MIB objects do so in a 285 non-secure manner. As a result, it may be best to constrain 286 the use of these objects to read-only by MIB managers. 288 - Finally, any MIB defining writable objects should carefully 289 consider the security implications of an SNMP compromise on 290 the mechanism(s) being controlled by those writable MIB 291 objects. 293 6. Acknowledgements 295 Thanks to Ran Atkinson, James Polk, Scott Bradner, Jon Peterson, and 296 Ian Brown for comments on previous versions of this draft. 298 7. References 300 7.1 Normative Reference 302 [rfc3668] Bradner, S., "Intellectual Property Rights in IETF 303 technology", BCP 79, RFC 3668, February 2004 305 7.2 Informative References 307 [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", RFC 2119, March 1997. 310 [rfc3031] Rosen, E., et. al., "Multiprotocol Label Switching 311 Architecture", RFC3031, January 2001 313 [rfc3689] Carlberg, K., Atkinson, R., "General Requirements for 314 Emergency Telecommunications Service", RFC3689 315 Feb 2004 317 [frame] Carlberg, K., "A Framework for Supporting ETS in Stub 318 Domains", Internet Draft, Work in Progress, 319 draft-ieprep-domain-frame-02.txt, June 2003. 321 8. Author's Addresses 323 Ken Carlberg 324 G11 325 123a Versailles Circle 326 Baltimore, MD 327 USA 328 carlberg@g11.org.uk 330 Intellectual Property Statement 332 The IETF takes no position regarding the validity or scope of any 333 Intellectual Property Rights or other rights that might be claimed to 334 pertain to the implementation or use of the technology described in 335 this document or the extent to which any license under such rights 336 might or might not be available; nor does it represent that it has 337 made any independent effort to identify any such rights. Information 338 on the procedures with respect to rights in RFC documents can be 339 found in BCP 78 and BCP 79. 341 Copies of IPR disclosures made to the IETF Secretariat and any 342 assurances of licenses to be made available, or the result of an 343 attempt made to obtain a general license or permission for the use of 344 such proprietary rights by implementers or users of this 345 specification can be obtained from the IETF on-line IPR repository at 346 http://www.ietf.org/ipr. 348 The IETF invites any interested party to bring to its attention any 349 copyrights, patents or patent applications, or other proprietary 350 rights that may cover technology that may be required to implement 351 this standard. Please address the information to the IETF at ietf- 352 ipr@ietf.org. 354 Disclaimer of Validity 356 This document and the information contained herein are provided on an 357 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 358 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 359 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 360 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 361 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 362 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 364 Copyright Statement 366 Copyright (C) The Internet Society (2005). This document is subject 367 to the rights, licenses and restrictions contained in BCP 78, and 368 except as set forth therein, the authors retain all their rights. 370 Acknowledgment 372 Funding for the RFC Editor function is currently provided by the 373 Internet Society.