idnits 2.17.1 draft-dolly-sipping-atis-ptsc-03.txt: -(165): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(180): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 416. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 400. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 406. ** 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 5) being 143 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 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. ** There are 16 instances of too long lines in the document, the longest one being 220 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. 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 (October 23, 2006) is 6394 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) == Unused Reference: 'I-D.ietf-sipping-config-framework' is defined on line 318, but no explicit reference was found in the text == Unused Reference: 'I-D.petrie-sipping-profile-datasets' is defined on line 324, but no explicit reference was found in the text == Unused Reference: 'I-D.sinnreich-sipdev-req' is defined on line 330, but no explicit reference was found in the text == Unused Reference: 'RFC0822' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 338, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 341, but no explicit reference was found in the text == Unused Reference: 'RFC3265' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'RFC3470' is defined on line 349, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-07 == Outdated reference: A later version (-05) exists of draft-petrie-sipping-profile-datasets-03 ** Downref: Normative reference to an Informational draft: draft-sinnreich-sipdev-req (ref. 'I-D.sinnreich-sipdev-req') ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) Summary: 10 errors (**), 0 flaws (~~), 15 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING M. Dolly 3 Internet-Draft AT&T Labs 4 Expires: March 24, 2007 B. Hall 5 SBC 6 J. Zebarth 7 Nortel 8 October 23, 2006 10 ATIS PTSC Work Program 11 draft-dolly-sipping-atis-ptsc-03.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 24, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 At the 67th San Diego IETF Meeting it is anticipated that the Real-time 45 Applications and Infrastructure Area will meet and its ongoing work program will be an item for discussion. 47 This Internet Draft has been prepared to share the relevant portions 48 of the PTSC current work program with the IETF. It is hoped that 49 awareness of the Packet Technologies Systems Committee (PTSC) work 50 program will allow for more informed discussion. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. PTSC Work Program . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. IP Interconnection, and Services & Capabilities . . . . . 3 57 2.2. IP Emergency Telecommunication Services . . . . . . . . . 5 58 2.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.3.1. Security at NNIs and UNIs . . . . . . . . . . . . . . 5 60 2.3.2. Security Mechanisms for Messaging Applications . . . . 6 61 2.3.3. End to End User Authentication and Signaling 62 Security . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.4. Lawfully Authorized Electronic Surveillance . . . . . . . 7 64 2.5. Program Items related to IP Network Testing . . . . . . . 7 65 3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 5. Changes from previous . . . . . . . . . . . . . . . . . . . . 8 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 71 Intellectual Property and Copyright Statements . . . . . . . . . . 11 73 1. Introduction 75 At the 67th San Diego IETF Meeting it is anticipated that the Real-time 76 Applications and Infrastructure Area will meet and its ongoing work program will be an item for discussion. This Internet Draft has been prepared 77 to share the relevant portions of the PTSC current work program with 78 the IETF. It is hoped that awareness of the Packet Technologies 79 Systems Committee (PTSC) work program will allow for more informed 80 discussions to occur. 82 The PTSC defines its work program in the context of Issues. The PTSC 83 operates on the principle that one deliverable is typically produced 84 under one identified Issue (or project if you wish). It is important 85 to understand that the PTSC is quite prepared to recommend adoption 86 of existing standards should they be available and appropriate. 88 The PTSC wishes to maintain a good working relationship with the IETF 89 and sees the IETF as a rich potential source of IP related protocols. 91 2. PTSC Work Program 93 The PTSC is an ATIS sponsored technical committee. The PTSC develops 94 and recommends standards and Technical Reports related to packet 95 based services, architectures, and signaling, in addition to working 96 with related subjects under consideration in other North American and 97 international standards bodies. The PTSC is a major source of 98 proposed United States Positions to the ITU. 100 While the full PTSC work program is publicly available and can be 101 found at: http://www.atis.org/0191/issues.asp, this document will 102 identify those items that are related to this topical area and that 103 are active. 105 2.1. IP Interconnection, and Services & Capabilities 107 The following issue statements cover the topics related to general 108 network interconnection: 110 Issue S0010 - Authorizes development of an update to the interworking 111 requirements defined in T1.679 (SIP-I), as new RFCs become 112 approved and as ITU-T Recommendations are modified. 114 Issue S0014 - Authorizes development of a Technical Report assessing 115 which industry groups are developing operator services-related 116 standards for next generation equipment and what, if any, common 117 functions and architectures are emerging in support of operator 118 services in the IP space. 120 Issue S0018 - Authorizes development of a Technical Report that 121 defines an implementable architecture in support of IP QoS & RACs 122 for USA networks. 124 Issue S0019 - Authorizes development of a Technical Report that 125 defines an implementable architecture in support of IP QoS & RACs 126 for USA networks. 128 Issue S0021 - Authorizes development of a Technical Report describing 129 operator services functions and a common nomenclature and in 130 support of operator services in the IP space. 132 Issue S0023 - Authorizes development of Technical Report that 133 specifies a set of requirements for communicating IP traffic 134 priority and QoS parameters between applications and the IP 135 transport. Specific aspects of such a work program are the 136 following: 137 Call/Session Flow Identification 138 Vertical Interface Requirements 140 Issue S0024 - Authorizes development of a Technical Report that 141 defines the Session/Border Control Functions (S/BCF), performed 142 within various different network types. The functions required 143 depend on the interface. The document will include illustrative 144 examples of physical realizations of the functions. The physical 145 distribution of the functions will depend on scale, operational 146 and application needs. 148 Issue S0025 - Authorizes development of a Standard that defines the 149 NNI numbering and routing capabilities and procedures to promote 150 IP-IP interconnection between carriers in support of multi-media 151 services. This includes the support of carrier based ENUM. 153 Issue S0026 - Authorizes development of a Technical Report, in the 154 form of a users guide, on how to use SIP History-Info, between 155 networks and within a single network domain. 157 Issue S0027 - Authorizes development of a standard for a signaling/ 158 control interface between an End User's SIP UA and an IP Service 159 Provider, with the focus on layer 4 and above, application 160 signaling and control. In addition to defining the interface in 161 support of the application services, the document will also 162 include procedures and call/signaling flows for device bootstrap, 163 discovery and data profile configuration. 165 Issue S0029 � Authoriaes development of an Interworking Standard to Support ANSI Extensions to NSS. 167 Issue S0030 - Authorizes development of a Technical Report that 168 documents signaling to support Call Admission Control and Traffic 169 Management capabilities and procedures to be used between two IP 170 service providers, or within a service provider's domain. 172 Issue S0031 - Authorizes development of a Technical Report that 173 recommends application of packet priority markings and call 174 processing in managed IP networks. 176 Issue S0040 Authorizes extension of the NNI VoIP IP-IP interconnection standard, intended to facilitate interconnection between carriers, to address multimedia services in NGN 178 2.2. IP Emergency Telecommunication Services 180 Issue S0038 Authorizes development of a standard, applicable to managed IP networks using an NGN architecture, to support �911� Service. 182 Issue S0039 Authorizes development of a standard that recommends application of packet priority markings and call processing in managed IP networks based on future additions to DiffServ Code Points, such as a second Expedited Forwarding queue (with associated drop precedence, if applicable). 184 Issue S0041 Authorizes development of a standard that defines protocol and procedures for supporting ETS in NGN/IMS architectures, with a focus on security and authentication on IP access 186 Issue S0043 Authorizes development of a Technical report that captures the Technical Requirements that define the network element requirements for ETS Phase 1 188 Issue 45 Authorizes development of a Technical report that specifies the service requirements for ETS in an NGN environment 190 Issue 48 Authorizes development of ANSI IMS Standards 192 2.3. Security 194 2.3.1. Security at NNIs and UNIs 196 As telecom networks migrate the Network-to Network Interface (NNI) 197 from circuit switched to IP, there is a need for network control 198 security related specifications/ and standards which define the NNI 199 and the User Network Interface (UNI). 201 The PTSC is in the process of developing a suite of 5 Security IP 202 network interconnection related standards that deal with this 203 security area. These standards complement the security work already 204 undertaken by the ATIS TMOC Committee 205 (http://www.atis.org/0130/index.asp) and the security work currently 206 underway in the ATIS PRQC Committee 207 (http://www.atis.org/0010/index.asp). 209 The security related standards being produced by the PTSC are as 210 described in the issue statements below follows(note that issue 211 statements describe the deliverables of the PTSC): 213 Issue S0003 - Authorizes development of a standard which provides a 214 roadmap view of a subtending suite of standards, technical 215 reports, and requirements documents which provide a consistent set 216 of baseline security recommendations for the control and signaling 217 plane. 219 Issue S0006 - Authorizes development of a standard that describes 220 security issues specific to a VoP or Multimedia network 222 Issue S0007 - Authorizes development of a standard that addresses 223 security issues specific to the UNI access. 225 Issue S0046 Authorizes develop a standard that provides recommendations and specifies requirements for NGN Security based on the ATIS NGN Architecture. 227 2.3.2. Security Mechanisms for Messaging Applications 229 The following issue statement covers the Security Mechanisms for 230 Messaging Applications: 232 Issue S0032 - Authorizes development of a Technical Report that 233 details the minimum security mechanisms that carriers should 234 invoke, based on business objectives and policies for VoIP 235 messaging applications. The security mechanisms will address 236 aspects related to SPIT and application layer DoS attacks in both 237 signaling and data planes. 239 2.3.3. End to End User Authentication and Signaling Security 241 The following issue statement covers the End to End User 242 Authentication and Signaling Security: 244 Issue S0033 - Authorizes development of a Technical Report to 245 address: 246 >End-to-end security transiting multiple domains 247 >A mechanism(s) for a user to validate end-to-end security in 248 the presence of a "man in the middle network". 250 Issued S0051 Authorizes development of a standard that specifies a harmonized IdM approach for the ATIS NGN architecture 252 2.4. Lawfully Authorized Electronic Surveillance 254 The following issue statements cover the topics related to Lawfully 255 Authorized Electronic Surveillance (LAES): 257 Issue S0001 - Authorizes development of preparation of version 2 of 258 American National Standard T1.678 Lawfully Authorized Electronic 259 Surveillance (LAES) for Voice over Packet Technologies in Wireline 260 Telecommunications Networks, which can serve as a safe harbor 261 document for LAES in support of Voice services over Packet-mode 262 technologies in a wireline environment. 264 Issue S0002 - Authorizes development of a new standard to specify 265 LAES support for Public IP Network Access Service (PIPNAS) 266 provider. 268 Issue S0022 - Authorizes development of a Technical Report to 269 describe the evolution of the LAES capabilities and solutions 270 specified in existing American National Standards to support NGN 272 Issue S0035 - Authorizes development of a Technical Report that 273 describes various network and service provider scenarios and the 274 applicability and use of CALEA safeharbor and other LAES standards 275 documents (e.g. ANS T1.678, T1.ipna) to elements of the service 276 providers involved. 278 Issue S0037 Authorizes development of a Technical Report that identifies detailed requirements and assesses their feasibility and the complexity of implementation, for reporting LAES events. 280 Issue S0047 Authorizes the development of a Supplement to ATIS-1000678-2006, Lawfully Authorized Electronic Surveillance (LAES) for Voice over Packet Technologies in Wireline Telecommunication Networks 282 Issue S0049 Authorizes the development of a Technical Report describing an appropriate buffering (short term storage) capability and corresponding file structure to support LAES. 284 2.5. Program Items related to IP Network Testing 286 S0008 - Authorizes development of a Technical Report that provides a 287 testing framework in order to ensure interoperability for IP-IP 288 interconnection between networks. 290 Issue S0050 Authorizes development of a Technical Report that provides a testing framework in order to help ensure interoperability for VoIP CPE-network interconnection. 292 3. Summary 294 This Internet Draft has been prepared to share the relevant portions 295 of the ATIS PTSC current work program, which may be related to this 296 topic and other topics, with the IETF. It is hoped that awareness of 297 the Packet Technologies Systems Committee work program will allow for 298 a more informed discussion during the 64th IETF Meeting. 300 The PTSC wishes to maintain a good working relationship with the IETF 301 and sees the IETF as a rich potential source of IP related protocols. 303 4. Security Considerations 305 This ID discusses among other things the security work program of the 306 PTSC. There are no security issues raised by this ID. 308 5. Changes from previous 310 Work items deleted: 311 Issue S0004, S0005, S0016 and S0020 313 Work items added: 314 Issue S0037, S0038, S0039, S0040, S0041, S0043, S0045, S0046, S0047, S0048, S0050 and S0051 316 6. References 318 [I-D.ietf-sipping-config-framework] 319 Petrie, D., "A Framework for Session Initiation Protocol 320 User Agent Profile Delivery", 321 draft-ietf-sipping-config-framework-07 (work in progress), 322 July 2005. 324 [I-D.petrie-sipping-profile-datasets] 325 Petrie, D., "A Schema and Guidelines for Defining Session 326 Initiation Protocol User Agent Profile Data Sets", 327 draft-petrie-sipping-profile-datasets-03 (work in 328 progress), October 2005. 330 [I-D.sinnreich-sipdev-req] 331 Sinnreich, H., "SIP Telephony Device Requirements and 332 Configuration", draft-sinnreich-sipdev-req-08 (work in 333 progress), October 2005. 335 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 336 text messages", STD 11, RFC 822, August 1982. 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 342 A., Peterson, J., Sparks, R., Handley, M., and E. 343 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 344 June 2002. 346 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 347 Event Notification", RFC 3265, June 2002. 349 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for 350 the Use of Extensible Markup Language (XML) within IETF 351 Protocols", BCP 70, RFC 3470, January 2003. 353 Appendix A. Acknowledgments 354 Authors' Addresses 356 Martin Dolly 357 AT&T Labs 358 200 Laurel Avenue 359 Middletowm, NJ 07748 360 USA 362 Phone: 363 Email: mdolly AT att DOT com 364 URI: 366 Bob Hall 367 SBC 368 Austin, TX 369 USA 371 Phone: 372 Email: 373 URI: 375 Joe Zebarth 376 Nortel 377 Ottawa, Ontario 378 Canada 380 Phone: 381 Email: 382 URI: 384 Intellectual Property Statement 386 The IETF takes no position regarding the validity or scope of any 387 Intellectual Property Rights or other rights that might be claimed to 388 pertain to the implementation or use of the technology described in 389 this document or the extent to which any license under such rights 390 might or might not be available; nor does it represent that it has 391 made any independent effort to identify any such rights. Information 392 on the procedures with respect to rights in RFC documents can be 393 found in BCP 78 and BCP 79. 395 Copies of IPR disclosures made to the IETF Secretariat and any 396 assurances of licenses to be made available, or the result of an 397 attempt made to obtain a general license or permission for the use of 398 such proprietary rights by implementers or users of this 399 specification can be obtained from the IETF on-line IPR repository at 400 http://www.ietf.org/ipr. 402 The IETF invites any interested party to bring to its attention any 403 copyrights, patents or patent applications, or other proprietary 404 rights that may cover technology that may be required to implement 405 this standard. Please address the information to the IETF at 406 ietf-ipr@ietf.org. 408 Disclaimer of Validity 410 This document and the information contained herein are provided on an 411 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 412 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 413 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 414 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 415 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 416 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 418 Copyright Statement 420 Copyright (C) The Internet Society (2006). This document is subject 421 to the rights, licenses and restrictions contained in BCP 78, and 422 except as set forth therein, the authors retain all their rights. 424 Acknowledgment 426 Funding for the RFC Editor function is currently provided by the 427 Internet Society.