idnits 2.17.1 draft-peterson-rai-rfc3427bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. -- The draft header indicates that this document updates RFC3969, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3265, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC3265, updated by this document, for RFC5378 checks: 2001-07-05) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 23, 2009) is 5261 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 3427 (Obsoleted by RFC 5727) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft NeuStar, Inc. 4 Obsoletes: 3427 (if approved) C. Jennings 5 Updates: 3265,3969 Cisco Systems 6 (if approved) R. Sparks 7 Intended status: BCP Tekelec 8 Expires: April 26, 2010 October 23, 2009 10 Change Process for the Session Initiation Protocol (SIP) and the Real- 11 time Applications and Infrastructure Area 12 draft-peterson-rai-rfc3427bis-04 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on April 26, 2010. 47 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This memo documents a process intended to organize the future 60 development of the Session Initiation Protocol (SIP) and related work 61 in the Real-Time Applications and Infrastructure (RAI) Area. As the 62 environments in which SIP is deployed grow more numerous and diverse, 63 modifying or extending SIP in certain ways may threaten the 64 interoperability and security of the protocol; however, the IETF 65 process must also cater to the realities of existing deployments and 66 serve the needs of the implementers working with SIP. This document 67 therefore defines the functions of two long-lived working groups in 68 the RAI Area which are, respectively, responsible for the maintenance 69 of the core SIP specifications and development of new efforts to 70 extend and apply work in this space. This document obsoletes 71 RFC3427. 73 Table of Contents 75 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. History and Development . . . . . . . . . . . . . . . . . . . 5 77 2.1. The IETF SIPCORE Working Group . . . . . . . . . . . . . . 5 78 2.2. The IETF DISPATCH Working Group . . . . . . . . . . . . . 6 79 3. Introducing New Work to RAI . . . . . . . . . . . . . . . . . 8 80 4. Extensibility and Architecture . . . . . . . . . . . . . . . . 10 81 4.1. SIP Event Packages . . . . . . . . . . . . . . . . . . . . 11 82 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 85 7.1. Clarification of RFC3969 . . . . . . . . . . . . . . . . . 16 86 8. Overview of changes to RFC3427 . . . . . . . . . . . . . . . . 18 87 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 90 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 93 1. Terminology 95 In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", 96 and "SHOULD NOT", are to be interpreted as described in [RFC2119]. 97 This document additionally uses [RFC5226] language to describe IANA 98 registrations. 100 2. History and Development 102 The Session Initiation Protocol (SIP) [RFC3261] has grown well beyond 103 its origins in Internet-based multimedia sessions, and now enjoys 104 widespread popularity in Voice over IP or IP telephony applications, 105 both inside IETF and within other standards groups. One result of 106 this popularity has been a continual flood of proposals for SIP 107 modifications and extensions. The challenge for IETF management of 108 SIP has been to preserve baseline interoperability across its many 109 implementations 111 In order to defend SIP against changes that might reduce 112 interoperability, the working group chairs and Area Directors 113 responsible for its management authored the SIP change process 114 [RFC3427]. SIP change defined the role of the SIP and SIPPING 115 working groups in shepherding ongoing work on the SIP standard. It 116 also defined ways that external working groups or bodies could define 117 extensions intended for limited usage, especially through the "P-" 118 header field mechanism. 120 Over time, however, the management structure of RFC3427 has 121 demonstrated some limitations. The first and most significant of 122 these concerns "P-" header fields. While "P-" header fields require 123 expert review and IESG shepherding, in practice IETF oversight of 124 these header fields is quite limited, and the value added by the IETF 125 supervising their development remains unclear. More importantly, the 126 presence of a "P-" in front of a header field name does nothing to 127 prevent a popular header field from seeing deployment outside of the 128 original "limited usage" it envisioned; a prominent example of this 129 today is the P-Asserted-Identity (PAID) header field, described in 130 RFC3325 [RFC3325]. 132 Consequently, this document obsoletes RFC3427 and describes a new 133 structure for the management of deliverables in the Real-time 134 Applications and Infrastructure Area. 136 2.1. The IETF SIPCORE Working Group 138 Historically, the IETF SIP Working Group (sip) was chartered to be 139 the "owner" of the SIP protocol [RFC3261] for the duration of the 140 working group. All changes or extensions to SIP were first required 141 to exist as SIP Working Group documents. The SIP working group was 142 charged with being the guardian of the SIP protocol for the Internet, 143 and therefore was mandated only to extend or change the SIP protocol 144 when there are compelling reasons to do so. 146 The SIPCORE working group replaces the function of the SIP working 147 group in the original RFC3427 account. Documents that must be 148 handled by the SIPCORE working group include all documents which 149 update or obsolete RFC3261 through RFC3265 or their successors. All 150 SIP extensions considered in SIPCORE must be standards track. They 151 may be based upon requirements developed externally in other IETF 152 working groups. 154 Typical IETF working groups do not live forever; SIPCORE's charter is 155 however open-ended in order to allow it to remain the place where 156 core SIP development will continue. In the event that the SIPCORE 157 working group has closed and no suitable replacement or follow-on 158 working group is active (and this specification also has not been 159 superseded), then when modifications to the core SIP protocol are 160 proposed the RAI Area Directors will use the non-working group 161 standards track document process (described in Section 6.1.2 of RFC 162 2026 [RFC2026]) using the SIPCORE mailing list and designated experts 163 from the SIP community for review. 165 It is appropriate for any IETF working group to develop SIP event 166 packages [RFC3265], but the working group must have charter approval 167 to do so. The IETF will also require RFC5226 IETF Review for the 168 registration of event packages developed outside the scope of an IETF 169 working group. Instructions for event package registrations are 170 provided in Section 4.1. 172 2.2. The IETF DISPATCH Working Group 174 Historically, the IETF Session Initiation Protocol Proposal 175 Investigation (sipping) Working Group was chartered to be a filter in 176 front of the SIP Working Group. This working group investigated 177 requirements for applications of SIP, some of which led to requests 178 for extensions to SIP. These requirements may come from the 179 community at large, or from individuals who are reporting the 180 requirements as determined by another standards body. 182 The DISPATCH working group replaces the function of the SIPPING WG, 183 although with several important changes to its functionality, the 184 most notable being that its scope expands beyond just SIP to the 185 entire work of the RAI Area. Like SIPPING, DISPATCH considers new 186 proposals for work in the RAI Area, but rather than taking on 187 specification deliverables as charter items itself, DISPATCH 188 identifies the proper venue for work. If no such venue yet exists in 189 the RAI Area, DISPATCH will develop charters and consensus for a BoF, 190 working group, or exploratory group [RFC5111] as appropriate. Unlike 191 the previous change structure, a DISPATCH review of any proposed 192 change to core SIP is not required before it progresses to SIPCORE; 193 however, any new proposed work which does not clearly fall within the 194 charter of an existing RAI Area effort should be examined by 195 DISPATCH. 197 In reaction to a proposal, the DISPATCH Working Group may determine: 198 that these requirements justify a change to the core SIP 199 specifications (RFC3261 through RFC3265) and thus any resulting work 200 must transpire in SIPCORE, that the requirements do not change the 201 SIP core specifications but require a new effort in the RAI area (be 202 that a working group, a BoF, or what have you), that the requirements 203 fall within the scope of existing chartered work in the RAI Area, or 204 that the proposal should not be acted upon at this time. Because the 205 SIP protocol gets so much attention, some application designers may 206 want to use it just because it is there, such as for controlling 207 household appliances. DISPATCH should act as a filter, accepting 208 only proposals which play to the strengths of SIP, not those that 209 confuse its applicability or ultimately reduce its usefulness as a 210 means for immediate personal communications on the Internet. 212 In practice, it is expected that the DISPATCH WG behaves as a RAI 213 "Open Area" working group, similar to those employed in other areas 214 of the IETF. While it does not have the traditional deliverables of 215 a working group, DISPATCH may at the discretion of its chairs and 216 Area Directors adopt milestones, in accordance with standard working 217 group milestone adoption procedures, such as the production of 218 charter text for a BoF or working group, a "-00" problem statement 219 document that explicates a proposed work effort, or a document 220 explaining why a particular direction for standards development was 221 not pursued. 223 3. Introducing New Work to RAI 225 When proposals arise for modifications or extensions to SIP outside 226 the scope of existing chartered RAI Area work, they must be written 227 up as a problem statement (preferably as an Internet-Draft) 228 explaining the problem they are trying to solve, why SIP is the 229 applicable protocol, and why the existing SIP protocol will not work. 230 The problem statement must include a detailed set of requirements 231 (distinct from solutions) that SIP would need to meet to solve the 232 particular problem. The problem statement must also describe in 233 detail any security issues that arise from meeting those 234 requirements. After the problem statement is published, the authors 235 should send a note to the DISPATCH Working Group mailing list to 236 start discussion on the problem. 238 The DISPATCH working group chairs, in conjunction with the RAI Area 239 Directors, will determine if the particular problems raised in the 240 requirements problem statement are indeed outside the charter of 241 existing efforts, and if so, if they warrant a DISPATCH milestone for 242 the definition of a new effort; this DISPATCH deliverable may take 243 the form of a problem statement Internet-Draft, charter or similar 244 milestone that provides enough information to make a decision, but 245 must not include protocol development. The DISPATCH working group 246 should consider whether the requirements can be merged with other 247 requirements from other applications, and refine the problem 248 statement accordingly. 250 Once a new effort has been defined in DISPATCH and there is working 251 group consensus that it should go forward, if the new effort will 252 take the form of a working group or BoF, then the ADs will present 253 the proposed new effort charter to the IESG and IAB, in accordance 254 with the usual chartering process. If the new effort involves the 255 rechartering of an existing working group, then similarly the 256 existing working group rechartering functions will be performed by 257 the appropriate WG chairs and ADs. If the IESG (with IAB advice) 258 approves of the new charter or BoF, the DISPATCH working group has 259 completed its deliverable and the new effort becomes autonomous. 261 Anyone proposing requirements for new work is welcome to jointly 262 develop, in a separate Internet-Draft, a mechanism that would meet 263 the requirements. No working group is required to adopt the proposed 264 solution from this additional Internet-Draft. 266 Work overseen by the SIPCORE Working Group is required to protect the 267 architectural integrity of SIP and must not add features that do not 268 have general use beyond the specific case. Also, SIPCORE must not 269 add features just to make a particular function more efficient at the 270 expense of simplicity or robustness. 272 Some working groups generate requirements for SIP solutions and/or 273 extensions. At the time this document was written, some groups with 274 such chartered deliverables include SIP for Instant Messaging and 275 Presence Leveraging Extensions (simple), Basic Level of 276 Interoperability for SIP Services (bliss) and Session Peering for 277 Multimedia Interconnect (speermint). 279 The RAI ADs may, on an exceptional, case by case basis, support a 280 process in which the requirements analysis is implicit and a RAI area 281 working group handling extensions to SIP requests the addition of a 282 charter item for an extension without a full DISPATCH process as 283 described. 285 4. Extensibility and Architecture 287 In an idealized protocol model, extensible design would be self- 288 contained, and it would be inherent that new extensions and new 289 header fields would naturally have an architectural coherence with 290 the original protocol. 292 However, this idealized vision has not been attained in the world of 293 standards track protocols. While interoperability implications can 294 be addressed by capabilities negotiation rules, the effects of adding 295 features that overlap, or that deal with a point solution and are not 296 general, are much harder to control with rules. Therefore, the RAI 297 Area calls for architectural guardianship and application of Occam's 298 Razor by the SIPCORE and DISPATCH Working Groups. 300 In keeping with the IETF tradition of "running code and rough 301 consensus", it is valid to allow for the development of SIP 302 extensions that are either not ready for standards track, but might 303 be understood for that role after some running code, or are private 304 or proprietary in nature, because a characteristic motivating them is 305 usage that is known not to fit the Internet architecture for SIP. In 306 the past, header fields associated with those extensions were called 307 "P-" header fields, for "preliminary", "private", or "proprietary". 309 However, the "P-" header field process has not served the purpose for 310 which it was designed - namely, to restrict to closed environments 311 the usage of mechanisms the IETF would not (yet) endorse for general 312 usage. In fact, some "P-" header fields have enjoyed widespread 313 implementation; because of the "P-" prefix, however, there seems to 314 be no plausible migration path to designate these as general-usage 315 header fields without trying to force implausible changes on large 316 installed bases. 318 Accordingly, this specification deprecates the previous RFC3427 319 guidance on the creation of "P-" header fields. Existing "P-" header 320 fields are to be handled by user agents and proxy servers as the "P-" 321 header field specifications describe; the deprecation of the change 322 process mechanism entails no change in protocol behavior. New 323 proposals to document SIP header fields of an experimental or private 324 nature, however, shall not use the 'P-" prefix (unless existing 325 deployments or standards use the prefix already, in which case they 326 may be admitted as grandfathered cases at the discretion of the 327 Designated Expert). 329 Instead, the registration of SIP header fields in Informational RFCs, 330 or in documents outside the IETF, is now permitted under the 331 Designated Expert (per RFC5226) criteria. The future use of any 332 header field field name prefix ("P-" or "X-" or what have you) to 333 designate SIP header fields of limited applicability is discouraged. 334 Experts are advised to review documents for overlap with existing 335 chartered work in the RAI Area, and are furthermore instructed to 336 ensure the following two criteria are met: 338 1. The proposed header field MUST be of a purely informational 339 nature, and MUST NOT significantly change the behavior of SIP 340 entities which support it. Header fields which merely provide 341 additional information pertinent to a request or a response are 342 acceptable; these header fields are thus expected to have few, if 343 any, implications for interoperability and backwards 344 compatibility. Similarly, header fields which provide data 345 consumed by applications at the ends of SIP's rendez-vous 346 function, rather than changing the behavior of the rendez-vous 347 function, are likely to be information in this sense. If the 348 header fields redefine or contradict normative behavior defined 349 in standards track SIP specifications, that is what is meant by 350 significantly different behavior. Ultimately, the significance 351 of differences in behavior is a judgment call that must be made 352 by the expert reviewer. 354 2. The proposed header field MUST NOT undermine SIP security in any 355 sense. The Internet Draft proposing the new header field MUST 356 address security issues in detail as if it were a Standards Track 357 document. Note that, if the intended application scenario makes 358 certain assumptions regarding security, the security 359 considerations only need to meet the intended application 360 scenario rather than the general Internet case. In any case, 361 security issues need to be discussed for arbitrary usage 362 scenarios (including the general Internet case). 364 Note that the deprecation of the "P-" header field process does not 365 alter processes for the registration of SIP methods, URI parameters, 366 response codes, or option tags. 368 4.1. SIP Event Packages 370 SIP events [RFC3265] defines two different types of event packages: 371 normal event packages, and event template-packages. Event template- 372 packages can only be created and registered by the publication of a 373 Standards Track RFC (from an IETF Working Group). Note that the 374 guidance in RFC3265 states that the IANA registration policy for 375 normal event packages is "First Come First Serve"; this document 376 replaces that policy with the following: 378 Individuals may wish to publish SIP Event packages that they believe 379 fall outside the scope of any chartered work currently in RAI. 380 Individual proposals for registration of a SIP event package MUST 381 first be published as Internet-drafts for review by the DISPATCH 382 Working Group, or the working group, mailing list, or expert 383 designated by the RAI Area Directors if the DISPATCH Working Group 384 has closed. Proposals should include a strong motivational section, 385 a thorough description of the proposed syntax and semantics, event 386 package considerations, security considerations, and examples of 387 usage. Authors should submit their proposals as individual Internet- 388 Drafts, and post an announcement to the working group mailing list to 389 begin discussion. The DISPATCH Working Group will determine if a 390 proposed package is a) an appropriate usage of SIP which should be 391 spun into a new effort, b) applicable to SIP but not sufficiently 392 interesting, general, or in-scope to adopt as a working group effort, 393 c) contrary to similar work chartered in an existing effort, or d) 394 recommended to be adopted as or merged with chartered work elsewhere 395 in RAI. 397 "RFC Required" in conjunction with "Designated Expert" (both as 398 defined in RFC5226) is the procedure for registration of event 399 packages developed outside the scope of an IETF working group, 400 according to the following guidelines: 402 1. A Designated Expert (as defined in RFC5226) must review the 403 proposal for applicability to SIP and conformance with these 404 guidelines. The Designated Expert will send email to the IESG on 405 this determination. The expert reviewer can cite one or more of 406 the guidelines that have not been followed in his/her opinion. 408 2. The proposed extension MUST NOT define an event template-package. 410 3. The function of the proposed package MUST NOT overlap with 411 current or planned chartered packages. 413 4. The event package MUST NOT redefine or contradict the normative 414 behavior of SIP events [RFC3265], SIP [RFC3261], or related 415 standards track extensions. (See Section 4) 417 5. The proposed package MUST NOT undermine SIP security in any 418 sense. The Internet Draft proposing the new package MUST address 419 security issues in detail as if it were a Standards Track 420 document. Security issues need to be discussed for arbitrary 421 usage scenarios (including the general Internet case). 423 6. The proposed package MUST be clearly documented in an 424 (Individual) Informational RFC, and registered with IANA. The 425 package MUST document all the package considerations required in 426 Section 5 of SIP events [RFC3265]. 428 7. If determined by the Designated Expert or the chairs or ADs of 429 the DISPATCH WG, an applicability statement in the Informational 430 RFC MUST clearly document the useful scope of the proposal, and 431 explain its limitations and why it is not suitable for the 432 general use of SIP in the Internet. 434 5. Summary 436 1. Documents that update or obsolete RFC 3261 through 3265 must 437 advance through the SIPCORE WG. 439 2. Standard SIP extensions which do not update RFC 3261 through 440 3265, including event packages, may advance through chartered 441 activity in any RAI Area WG, or with the agreement of the RAI ADs 442 any IETF working group that constitutes an appropriate venue. 444 3. Documents that specify Informational header fields pass through 445 an Expert Review system. 447 6. Security Considerations 449 Complex and indeterminate and hard-to-define protocol behavior, 450 depending on the interaction of many optional extensions, is a fine 451 breeding ground for security flaws. 453 All Internet-Drafts that present new requirements for SIP must 454 include a discussion of the security requirements and implications 455 inherent in the proposal. All RFCs that modify or extend SIP must 456 show that they have adequate security, must consider the security 457 implications of feature interactions, and most of all must not worsen 458 SIP's existing security considerations. 460 7. IANA Considerations 462 RFC 3261 [RFC3261] directs the Internet Assigned Numbers Authority 463 (IANA) to establish a registry for SIP method names, a registry for 464 SIP option tags, and a registry for SIP response codes, and to amend 465 the practices used for the existing registry for SIP header fields. 466 Reiterating the guidance of RFC3261, method names, option tags and 467 SIP response codes require a Standards Action for inclusion in the 468 IANA registry. Authors of specifications should also be aware that 469 the SIP parameter registry is further elaborated in RFC3968 470 [RFC3968]. 472 Previously in RFC3427, all new SIP header field registrations 473 required a Standards Action (per RFC5226) with the exception of "P-" 474 header fields; now, Informational registration of non-"P-" header 475 fields is permitted if approved by a Designated Expert, as described 476 in Section 4. 478 Each RFC shall include an IANA Considerations section which directs 479 IANA to create appropriate registrations. Registration shall be done 480 at the time the IESG announces its approval of the draft containing 481 the registration requests. 483 Standard header fields and messages MUST NOT begin with the leading 484 characters "P-". Existing "P-" header field registrations are 485 considered grandfathered, but new registrations of Informational 486 header fields should not begin with the leading characters "P-" 487 (unless the "P-" would preserve compatibility with an pre-existing 488 unregistered usage of the header field, at the discretion the 489 Designated Expert). Short forms of header fields MUST only be 490 assigned to standards track header fields. 492 Similarly, RFC 3265 [RFC3265] directs the IANA to establish a 493 registry for SIP event packages and SIP event template packages. For 494 event template packages, registrations must follow the RFC5226 495 processes for Standards Action within an IETF working group. For 496 normal event packages, as stated previously registrations minimally 497 require RFC5226 "RFC Required" with "Designated Expert". In either 498 case, the IESG announcement of RFC approval authorizes IANA to make 499 the registration. 501 7.1. Clarification of RFC3969 503 RFC3969 [RFC3969] stipulates that the (original) RFC2434 rule of 504 "Specification Required" applies to registrations of new SIP URI 505 parameters; however Section 3 of that same document mandates that a 506 standards action is required to register new parameters with the 507 IANA. This contradiction arose from a misunderstanding of the nature 508 of the RFC2434 categories; the intention was for the IANA 509 Considerations to mandate that Standards Action is required. 511 8. Overview of changes to RFC3427 513 This section provides a high-level overview of the changes between 514 this document and RFC 3427. It is not a substitute for the document 515 as a whole - the details are necessarily not represented. 517 This document: 519 1. Changes the description of the SIP and SIPPING WG functions to 520 the SIPCORE and DISPATCH WG functions using the context of the 521 RAI Area. 523 2. Deprecates the process for "P-" header field registration, and 524 changes the requirements for registration of SIP header fields of 525 a purely informational nature. 527 3. Updates IANA registry requirements, reflecting the publication of 528 RFC 5226, clarifying the policies in RFC 3969, clarifying that 529 the original RFC 3237 updated the policies in RFC 3265. 531 9. Acknowledgments 533 The credit for the notion that SIP required careful management 534 belongs to the original authors: Allison Mankin, Scott Bradner, Rohan 535 Mahy, Dean Willis, Joerg Ott, and Brian Rosen. The current editors 536 have provided only an update to reflect lessons learned from running 537 the code, the changing situation of the IETF and the IANA 538 registration procedures. Gonzalo Camarillo was instrumental to the 539 development of the concept of SIPCORE and DISPATCH. Useful comments 540 were provided by Jonathan Rosenberg, Mary Barnes, Dan York, John 541 Elwell, Alan Johnston, Spencer Dawkins, Alfred Hines, Russ Housley 542 and Dean Willis. The thorough review from Stephen Hanna of the 543 Security Directorate proved enormously valuable. The authors also 544 appreciaed IESG feedback from Alexey Melnikov, Adrian Farrel, Dan 545 Romascanu and Magnus Westerlund. 547 The original authors thanked their IESG and IAB colleagues 548 (especially Randy Bush, Harald Alvestrand, John Klensin, Leslie 549 Daigle, Patrik Faltstrom, and Ned Freed) for valuable discussions of 550 extensibility issues in a wide range of protocols, including those 551 that our area brings forward and others. Thanks to the many members 552 of the SIP community engaged in interesting dialogue about this 553 document as well; including and especially Jonathan Rosenberg, 554 Henning Schulzrinne and William Marshall. 556 10. References 558 10.1. Normative References 560 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 561 3", BCP 9, RFC 2026, October 1996. 563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, March 1997. 566 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 567 A., Peterson, J., Sparks, R., Handley, M., and E. 568 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 569 June 2002. 571 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 572 Event Notification", RFC 3265, June 2002. 574 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 575 (IANA) Uniform Resource Identifier (URI) Parameter 576 Registry for the Session Initiation Protocol (SIP)", 577 BCP 99, RFC 3969, December 2004. 579 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 580 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 581 May 2008. 583 10.2. Informative References 585 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 586 Extensions to the Session Initiation Protocol (SIP) for 587 Asserted Identity within Trusted Networks", RFC 3325, 588 November 2002. 590 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., 591 and B. Rosen, "Change Process for the Session Initiation 592 Protocol (SIP)", BCP 67, RFC 3427, December 2002. 594 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 595 (IANA) Header Field Parameter Registry for the Session 596 Initiation Protocol (SIP)", BCP 98, RFC 3968, 597 December 2004. 599 [RFC5111] Aboba, B. and L. Dondeti, "Experiment in Exploratory Group 600 Formation within the Internet Engineering Task Force 601 (IETF)", RFC 5111, January 2008. 603 Authors' Addresses 605 Jon Peterson 606 NeuStar, Inc. 608 Email: jon.peterson@neustar.biz 610 Cullen Jennings 611 Cisco Systems 613 Email: fluffy@cisco.com 615 Robert Sparks 616 Tekelec 618 Email: rjsparks@nostrum.com