GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:bcp:bcp67

[Note that this file is a concatenation of more than one RFC.]

Internet Engineering Task Force (IETF) J. Peterson Request for Comments: 5727 NeuStar, Inc. BCP: 67 C. Jennings Obsoletes: 3427 Cisco Systems Updates: 3265, 3969 R. Sparks Category: Best Current Practice Tekelec ISSN: 2070-1721 March 2010

      Change Process for the Session Initiation Protocol (SIP)
       and the Real-time Applications and Infrastructure Area

Abstract

 This memo documents a process intended to organize the future
 development of the Session Initiation Protocol (SIP) and related work
 in the Real-time Applications and Infrastructure (RAI) Area.  As the
 environments in which SIP is deployed grow more numerous and diverse,
 modifying or extending SIP in certain ways may threaten the
 interoperability and security of the protocol; however, the IETF
 process must also cater to the realities of existing deployments and
 serve the needs of the implementers working with SIP.  This document
 therefore defines the functions of two long-lived working groups in
 the RAI Area that are, respectively, responsible for the maintenance
 of the core SIP specifications and the development of new efforts to
 extend and apply work in this space.  This document obsoletes RFC
 3427.

Status of This Memo

 This memo documents an Internet Best Current Practice.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 BCPs is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc5727.

Peterson, et al. Best Current Practice [Page 1] RFC 5727 SIP Change March 2010

Copyright Notice

 Copyright (c) 2010 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.
 This document may contain material from IETF Documents or IETF
 Contributions published or made publicly available before November
 10, 2008.  The person(s) controlling the copyright in some of this
 material may not have granted the IETF Trust the right to allow
 modifications of such material outside the IETF Standards Process.
 Without obtaining an adequate license from the person(s) controlling
 the copyright in such materials, this document may not be modified
 outside the IETF Standards Process, and derivative works of it may
 not be created outside the IETF Standards Process, except to format
 it for publication as an RFC or to translate it into languages other
 than English.

Table of Contents

 1.  History and Development  . . . . . . . . . . . . . . . . . . .  3
   1.1.  The IETF SIPCORE Working Group . . . . . . . . . . . . . .  3
   1.2.  The IETF DISPATCH Working Group  . . . . . . . . . . . . .  4
 2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
 3.  Introducing New Work to RAI  . . . . . . . . . . . . . . . . .  6
 4.  Extensibility and Architecture . . . . . . . . . . . . . . . .  7
   4.1.  SIP Event Packages . . . . . . . . . . . . . . . . . . . .  9
 5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
 6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
 7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.1.  Clarification of RFC 3969  . . . . . . . . . . . . . . . . 12
 8.  Overview of Changes to RFC 3427  . . . . . . . . . . . . . . . 12
 9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
   10.2. Informative References . . . . . . . . . . . . . . . . . . 13

Peterson, et al. Best Current Practice [Page 2] RFC 5727 SIP Change March 2010

1. History and Development

 The Session Initiation Protocol (SIP) [RFC3261] has grown well beyond
 its origins in Internet-based multimedia sessions and now enjoys
 widespread popularity in Voice-over-IP or IP telephony applications,
 both inside IETF and within other standards groups.  One result of
 this popularity has been a continual flood of proposals for SIP
 modifications and extensions.  The challenge for IETF management of
 SIP has been to preserve baseline interoperability across its many
 implementations
 In order to defend SIP against changes that might reduce
 interoperability, the working group chairs and Area Directors
 responsible for its management authored the SIP change process
 [RFC3427].  That document defined the role of the SIP and SIPPING
 Working Groups (WGs) in shepherding ongoing work on the SIP standard.
 It also defined ways that external working groups or bodies can
 define extensions intended for limited usage, especially through the
 "P-" header field mechanism.
 Over time, however, the management structure of RFC 3427 has
 demonstrated some limitations.  The first and most significant of
 these concerns "P-" header fields.  While "P-" header fields require
 expert review and IESG shepherding, in practice IETF oversight of
 these header fields is quite limited, and the value added by the IETF
 supervising their development remains unclear.  More importantly, the
 presence of a "P-" in front of a header field name does nothing to
 prevent a popular header field from seeing deployment outside of the
 original "limited usage" it envisioned; a prominent example of this
 today is the P-Asserted-Identity (PAID) header field, described in
 RFC3325 [RFC3325].
 Consequently, this document obsoletes RFC 3427 and describes a new
 structure for the management of deliverables in the Real-time
 Applications and Infrastructure Area.

1.1. The IETF SIPCORE Working Group

 Historically, the IETF SIP Working Group (sip) was chartered to be
 the "owner" of the SIP protocol [RFC3261] for the duration of the
 working group.  All changes or extensions to SIP were first required
 to exist as SIP Working Group documents.  The SIP Working Group was
 charged with being the guardian of the SIP protocol for the Internet,
 and therefore was mandated only to extend or change the SIP protocol
 when there were compelling reasons to do so.

Peterson, et al. Best Current Practice [Page 3] RFC 5727 SIP Change March 2010

 The SIPCORE Working Group replaces the function of the SIP Working
 Group in the original [RFC3427] account.  Documents that must be
 handled by the SIPCORE Working Group include all documents that
 update or obsolete RFCs 3261 through 3265 or their successors.  All
 SIP extensions considered in SIPCORE must be Standards Track.  They
 may be based upon requirements developed externally in other IETF
 working groups.
 Typical IETF working groups do not live forever; however, SIPCORE's
 charter is open-ended in order to allow it to remain the place where
 core SIP development will continue.  In the event that the SIPCORE
 Working Group has closed and no suitable replacement or follow-on
 working group is active (and this specification also has not been
 superseded), then when modifications to the core SIP protocol are
 proposed, the RAI Area Directors will use the non-working-group
 Standards Track document process (described in Section 6.1.2 of RFC
 2026 [RFC2026]) using the SIPCORE mailing list and Designated Experts
 from the SIP community for review.
 It is appropriate for any IETF working group to develop SIP event
 packages [RFC3265], but the working group must have charter approval
 to do so.  The IETF will also require [RFC5226] IETF Review for the
 registration of event packages developed outside the scope of an IETF
 working group.  Instructions for event package registrations are
 provided in Section 4.1.

1.2. The IETF DISPATCH Working Group

 Historically, the IETF Session Initiation Protocol Proposal
 Investigation (sipping) Working Group was chartered to be a filter in
 front of the SIP Working Group.  This working group investigated
 requirements for applications of SIP, some of which led to requests
 for extensions to SIP.  These requirements may come from the
 community at large or from individuals who are reporting the
 requirements as determined by another standards body.
 The DISPATCH Working Group replaces the function of the SIPPING WG,
 although with several important changes to its functionality -- the
 most notable being that its scope expands beyond just SIP to the
 entire work of the RAI Area.  Like SIPPING, DISPATCH considers new
 proposals for work in the RAI Area, but rather than taking on
 specification deliverables as charter items itself, DISPATCH
 identifies the proper venue for work.  If no such venue yet exists in
 the RAI Area, DISPATCH will develop charters and consensus for a BoF,
 working group, or exploratory group [RFC5111] as appropriate.  Unlike
 the previous change structure, a DISPATCH review of any proposed
 change to core SIP is not required before it progresses to SIPCORE;

Peterson, et al. Best Current Practice [Page 4] RFC 5727 SIP Change March 2010

 however, any new proposed work that does not clearly fall within the
 charter of an existing RAI Area effort should be examined by
 DISPATCH.
 In reaction to a proposal, the DISPATCH Working Group may determine
 that:
 1.  these requirements justify a change to the core SIP
     specifications (RFCs 3261 through 3265) and thus any resulting
     work must transpire in SIPCORE;
 2.  these requirements do not change the SIP core specifications but
     require a new effort in the RAI Area (be that a working group, a
     BoF, or what have you);
 3.  these requirements fall within the scope of existing chartered
     work in the RAI Area; or
 4.  the proposal should not be acted upon at this time.
 Because the SIP protocol gets so much attention, some application
 designers may want to use it just because it is there, such as for
 controlling household appliances.  DISPATCH should act as a filter,
 accepting only proposals that play to the strengths of SIP, not those
 that confuse its applicability or ultimately reduce its usefulness as
 a means for immediate personal communications on the Internet.
 In practice, it is expected that the DISPATCH WG behaves as a RAI
 "Open Area" working group, similar to those employed in other areas
 of the IETF.  While it does not have the traditional deliverables of
 a working group, DISPATCH may, at the discretion of its chairs and
 Area Directors, adopt milestones in accordance with standard working
 group milestone-adoption procedures, such as the production of
 charter text for a BoF or working group, a "-00" problem statement
 document that explicates a proposed work effort, or a document
 explaining why a particular direction for standards development was
 not pursued.

2. Terminology

 In this document, the key words "MAY", "MUST", "MUST NOT", "SHOULD",
 and "SHOULD NOT", are to be interpreted as described in [RFC2119].
 This document additionally uses [RFC5226] language to describe IANA
 registrations.

Peterson, et al. Best Current Practice [Page 5] RFC 5727 SIP Change March 2010

3. Introducing New Work to RAI

 As with any new work in the IETF, proposals are best formulated in
 individual Internet-Drafts.  New ideas arising within the chartered
 scope of a RAI Area working group naturally should be treated as
 candidates for adoption as a working group item there.  Experience
 has demonstrated that authoring a problem statement or set of initial
 requirements prior to (or at least separately from) submitting a
 protocol mechanism speeds the consensus-making process significantly.
 A problem statement should explain what problem needs to be solved,
 why existing mechanisms are insufficient, and, for proposals to
 modify SIP, why SIP is the appropriate solution for this problem.  A
 problem statement must also detail any security issues that may
 result from meeting these requirements.  When proposed new work does
 not fall within the bounds of existing RAI Area working group
 charters, the DISPATCH Working Group assists the authors of
 proposals, the RAI Area Directors and the RAI community to decide the
 best way to approach the problem.  Authors of proposals may submit
 their problem statements to the DISPATCH Working Group for community
 consideration and review.
 The DISPATCH Working Group chairs, in conjunction with the RAI Area
 Directors, will determine if the particular problems raised in the
 requirements problem statement are indeed outside the charter of
 existing efforts and, if so, if they warrant a DISPATCH milestone for
 the definition of a new effort; this DISPATCH deliverable may take
 the form of a problem statement Internet-Draft, charter, or similar
 milestone that provides enough information to make a decision, but
 must not include protocol development.  The DISPATCH Working Group
 should consider whether the requirements can be merged with other
 requirements from other applications, and refine the problem
 statement accordingly.
 Once a new effort has been defined in DISPATCH and there is working
 group consensus that it should go forward, if the new effort will
 take the form of a working group or BoF, then the ADs will present
 the proposed new effort charter to the IESG and IAB, in accordance
 with the usual chartering process.  If the new effort involves the
 rechartering of an existing working group, then similarly the
 existing working group rechartering functions will be performed by
 the appropriate WG chairs and ADs.  If the IESG (with IAB advice)
 approves of the new charter or BoF, the DISPATCH Working Group has
 completed its deliverable and the new effort becomes autonomous.
 Anyone proposing requirements for new work is welcome to jointly
 develop, in a separate Internet-Draft, a mechanism that would meet
 the requirements.  No working group is required to adopt the proposed
 solution from this additional Internet-Draft.

Peterson, et al. Best Current Practice [Page 6] RFC 5727 SIP Change March 2010

 Work overseen by the SIPCORE Working Group is required to protect the
 architectural integrity of SIP and must not add features that do not
 have general use beyond the specific case.  Also, SIPCORE must not
 add features just to make a particular function more efficient at the
 expense of simplicity or robustness.
 The DISPATCH process is not the sole place that requirements for new
 work are considered in the RAI Area.  For example, some working
 groups generate requirements for SIP solutions and/or extensions.
 At the time this document was written, groups with such chartered
 deliverables include SIP for Instant Messaging and Presence
 Leveraging Extensions (simple), Basic Level of Interoperability for
 SIP Services (bliss) and Session Peering for Multimedia Interconnect
 (speermint).  The work of these and similar groups is not affected by
 the DISPATCH process.
 Of course, the RAI Area Directors may accept charter revisions from
 existing working groups that add new milestones or scope to their
 charters at their discretion, in the standard IETF manner, without
 any actions on the part of the DISPATCH Working Group.  DISPATCH
 exists to assist new work in finding a home expeditiously in those
 cases where it does not naturally fall into an existing bucket.

4. Extensibility and Architecture

 In an idealized protocol model, extensible design would be self-
 contained, and it would be inherent that new extensions and new
 header fields would naturally have an architectural coherence with
 the original protocol.
 However, this idealized vision has not been attained in the world of
 Standards Track protocols.  While interoperability implications can
 be addressed by capabilities negotiation rules, the effects of adding
 features that overlap, or that deal with a point solution and are not
 general, are much harder to control with rules.  Therefore, the RAI
 Area calls for architectural guardianship and application of Occam's
 Razor by the SIPCORE and DISPATCH Working Groups.
 In keeping with the IETF tradition of "running code and rough
 consensus", it is valid to allow for the development of SIP
 extensions that are either not ready for Standards Track, but might
 be understood for that role after some running code or are private or
 proprietary in nature because a characteristic motivating them is
 usage that is known not to fit the Internet architecture for SIP.  In
 the past, header fields associated with those extensions were called
 "P-" header fields for "preliminary", "private", or "proprietary".

Peterson, et al. Best Current Practice [Page 7] RFC 5727 SIP Change March 2010

 However, the "P-" header field process has not served the purpose for
 which it was designed -- namely, to restrict to closed environments
 the usage of mechanisms the IETF would not (yet) endorse for general
 usage.  In fact, some "P-" header fields have enjoyed widespread
 implementation; because of the "P-" prefix, however, there seems to
 be no plausible migration path to designate these as general-usage
 header fields without trying to force implausible changes on large
 installed bases.
 Accordingly, this specification deprecates the previous [RFC3427]
 guidance on the creation of "P-" header fields.  Existing "P-" header
 fields are to be handled by user agents and proxy servers as the "P-"
 header field specifications describe; the deprecation of the change
 process mechanism entails no change in protocol behavior.  New
 proposals to document SIP header fields of an experimental or private
 nature, however, shall not use the "P-" prefix (unless existing
 deployments or standards use the prefix already, in which case they
 may be admitted as grandfathered cases at the discretion of the
 Designated Expert).
 Instead, the registration of SIP header fields in Informational RFCs,
 or in documents outside the IETF, is now permitted under the
 Designated Expert (per [RFC5226]) criteria.  The future use of any
 header field name prefix ("P-" or "X-" or what have you) to designate
 SIP header fields of limited applicability is discouraged.  Experts
 are advised to review documents for overlap with existing chartered
 work in the RAI Area, and are furthermore instructed to ensure the
 following two criteria are met:
 1.  The proposed header field MUST be of a purely informational
     nature and MUST NOT significantly change the behavior of SIP
     entities that support it.  Header fields that merely provide
     additional information pertinent to a request or a response are
     acceptable; these header fields are thus expected to have few, if
     any, implications for interoperability and backwards
     compatibility.  Similarly, header fields that provide data
     consumed by applications at the ends of SIP's rendezvous
     function, rather than changing the behavior of the rendezvous
     function, are likely to be providing information in this sense.
     If the header fields redefine or contradict normative behavior
     defined in Standards Track SIP specifications, that is what is
     meant by significantly different behavior.  Ultimately, the
     significance of differences in behavior is a judgment call that
     must be made by the expert reviewer.
 2.  The proposed header field MUST NOT undermine SIP security in any
     sense.  The Internet-Draft proposing the new header field MUST
     address security issues in detail, as if it were a Standards

Peterson, et al. Best Current Practice [Page 8] RFC 5727 SIP Change March 2010

     Track document.  Note that, if the intended application scenario
     makes certain assumptions regarding security, the security
     considerations only need to meet the intended application
     scenario rather than the general Internet case.  In any case,
     security issues need to be discussed for arbitrary usage
     scenarios (including the general Internet case).
 Note that the deprecation of the "P-" header field process does not
 alter processes for the registration of SIP methods, URI parameters,
 response codes, or option tags.

4.1. SIP Event Packages

 SIP events [RFC3265] defines two different types of event packages:
 normal event packages and event template-packages.  Event template-
 packages can only be created and registered by the publication of a
 Standards Track RFC (from an IETF Working Group).  Note that the
 guidance in [RFC3265] states that the IANA registration policy for
 normal event packages is "First Come First Serve"; this document
 replaces that policy with the following:
 Individuals may wish to publish SIP Event packages that they believe
 fall outside the scope of any chartered work currently in RAI.
 Individual proposals for registration of a SIP event package MUST
 first be published as Internet-Drafts for review by the DISPATCH
 Working Group, or the working group, mailing list, or expert
 designated by the RAI Area Directors if the DISPATCH Working Group
 has closed.  Proposals should include a strong motivational section,
 a thorough description of the proposed syntax and semantics, event
 package considerations, security considerations, and examples of
 usage.  Authors should submit their proposals as individual Internet-
 Drafts and post an announcement to the working group mailing list to
 begin discussion.  The DISPATCH Working Group will determine if a
 proposed package is
 a)  an appropriate usage of SIP that should be spun into a new
     effort,
 b)  applicable to SIP but not sufficiently interesting, general, or
     in-scope to adopt as a working group effort,
 c)  contrary to similar work chartered in an existing effort, or
 d)  recommended to be adopted as or merged with chartered work
     elsewhere in RAI.

Peterson, et al. Best Current Practice [Page 9] RFC 5727 SIP Change March 2010

 "RFC Required" in conjunction with "Designated Expert" (both as
 defined in RFC 5226) is the procedure for registration of event
 packages developed outside the scope of an IETF working group,
 according to the following guidelines:
 1.  A Designated Expert (as defined in RFC 5226) must review the
     proposal for applicability to SIP and conformance with these
     guidelines.  The Designated Expert will send email to the IESG on
     this determination.  The expert reviewer can cite one or more of
     the guidelines that have not been followed in his/her opinion.
 2.  The proposed extension MUST NOT define an event template-package.
 3.  The function of the proposed package MUST NOT overlap with
     current or planned chartered packages.
 4.  The event package MUST NOT redefine or contradict the normative
     behavior of SIP events [RFC3265], SIP [RFC3261], or related
     Standards Track extensions.  (See Section 4.)
 5.  The proposed package MUST NOT undermine SIP security in any
     sense.  The Internet-Draft proposing the new package MUST address
     security issues in detail as if it were a Standards Track
     document.  Security issues need to be discussed for arbitrary
     usage scenarios (including the general Internet case).
 6.  The proposed package MUST be clearly documented in an
     (Individual) Informational RFC and registered with IANA.  The
     package MUST document all the package considerations required in
     Section 4 of SIP events [RFC3265].
 7.  If determined by the Designated Expert or the chairs or ADs of
     the DISPATCH WG, an applicability statement in the Informational
     RFC MUST clearly document the useful scope of the proposal, and
     explain its limitations and why it is not suitable for the
     general use of SIP in the Internet.

5. Summary

 1.  Documents that update or obsolete RFCs 3261 through 3265 must
     advance through the SIPCORE WG.
 2.  Standard SIP extensions that do not update RFCs 3261 through
     3265, including event packages, may advance through chartered
     activity in any RAI Area WG or (with the agreement of the RAI
     ADs) any IETF working group that constitutes an appropriate
     venue.

Peterson, et al. Best Current Practice [Page 10] RFC 5727 SIP Change March 2010

 3.  Documents that specify Informational header fields pass through
     an Expert Review system.

6. Security Considerations

 Complex, indeterminate, and hard-to-define protocol behavior,
 depending on the interaction of many optional extensions, is a fine
 breeding ground for security flaws.
 All Internet-Drafts that present new requirements for SIP must
 include a discussion of the security requirements and implications
 inherent in the proposal.  All RFCs that modify or extend SIP must
 show that they have adequate security, must consider the security
 implications of feature interactions, and most of all must not worsen
 SIP's existing security considerations.

7. IANA Considerations

 RFC 3261 directs the Internet Assigned Numbers Authority (IANA) to
 establish a registry for SIP method names, a registry for SIP option
 tags, and a registry for SIP response codes, and to amend the
 practices used for the existing registry for SIP header fields.
 Reiterating the guidance of RFC 3261, method names, option tags, and
 SIP response codes require a Standards Action for inclusion in the
 IANA registry.  Authors of specifications should also be aware that
 the SIP parameter registry is further elaborated in [RFC3968].
 Previously in RFC 3427, all new SIP header field registrations
 required a Standards Action (per RFC 5226) with the exception of "P-"
 header fields; now, Informational registration of non-"P-" header
 fields is permitted if approved by a Designated Expert, as described
 in Section 4.
 Each RFC shall include an IANA Considerations section that directs
 IANA to create appropriate registrations.  Registration shall be done
 at the time the IESG announces its approval of the draft containing
 the registration requests.
 Standard header fields and messages MUST NOT begin with the leading
 characters "P-".  Existing "P-" header field registrations are
 considered grandfathered, but new registrations of Informational
 header fields should not begin with the leading characters "P-"
 (unless the "P-" would preserve compatibility with a pre-existing,
 unregistered usage of the header field, at the discretion the
 Designated Expert).  Short forms of header fields MUST only be
 assigned to Standards Track header fields.

Peterson, et al. Best Current Practice [Page 11] RFC 5727 SIP Change March 2010

 Similarly, [RFC3265] directs the IANA to establish a registry for SIP
 event packages and SIP event template-packages.  For event template-
 packages, registrations must follow the [RFC5226] processes for
 Standards Action within an IETF working group.  For normal event
 packages, as stated previously, registrations minimally require
 [RFC5226] "RFC Required" with "Designated Expert".  In either case,
 the IESG announcement of RFC approval authorizes IANA to make the
 registration.

7.1. Clarification of RFC 3969

 [RFC3969] stipulates that the (original) [RFC2434] rule of
 "Specification Required" applies to registrations of new SIP URI
 parameters; however, Section 3 of that same document mandates that a
 Standards Action is required to register new parameters with the
 IANA.  This contradiction arose from a misunderstanding of the nature
 of the [RFC2434] categories; the intention was for the IANA
 Considerations to mandate that Standards Action is required.

8. Overview of Changes to RFC 3427

 This section provides a high-level overview of the changes between
 this document and RFC 3427.  It is not a substitute for the document
 as a whole -- the details are necessarily not represented.
 This document:
 1.  Changes the description of the SIP and SIPPING WG functions to
     the SIPCORE and DISPATCH WG functions using the context of the
     RAI Area.
 2.  Deprecates the process for "P-" header field registration, and
     changes the requirements for registration of SIP header fields of
     a purely informational nature.
 3.  Updates IANA registry requirements, reflecting the publication of
     RFC 5226, clarifying the policies in RFC 3969, and clarifying
     that the original RFC 3237 updated the policies in RFC 3265.

9. Acknowledgments

 The credit for the notion that SIP required careful management
 belongs to the original authors: Allison Mankin, Scott Bradner, Rohan
 Mahy, Dean Willis, Joerg Ott, and Brian Rosen.  The current editors
 have provided only an update to reflect lessons learned from running
 the code and from the changing situation of the IETF and the IANA
 registration procedures.  Gonzalo Camarillo was instrumental to the
 development of the concept of SIPCORE and DISPATCH.  Useful comments

Peterson, et al. Best Current Practice [Page 12] RFC 5727 SIP Change March 2010

 were provided by Jonathan Rosenberg, Mary Barnes, Dan York, John
 Elwell, Alan Johnston, Spencer Dawkins, Alfred Hoenes, Russ Housley,
 and Dean Willis.  The thorough review from Stephen Hanna of the
 Security Directorate proved enormously valuable.  The authors also
 appreciated IESG feedback from Alexey Melnikov, Adrian Farrel, Dan
 Romascanu, and Magnus Westerlund.
 The original authors thanked their IESG and IAB colleagues
 (especially Randy Bush, Harald Alvestrand, John Klensin, Leslie
 Daigle, Patrik Faltstrom, and Ned Freed) for valuable discussions of
 extensibility issues in a wide range of protocols, including those
 that our area brings forward and others.  Thanks to the many members
 of the SIP community engaged in interesting dialogue about this
 document as well, including and especially Jonathan Rosenberg,
 Henning Schulzrinne, and William Marshall.

10. References

10.1. Normative References

 [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
            3", BCP 9, RFC 2026, October 1996.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
            A., Peterson, J., Sparks, R., Handley, M., and E.
            Schooler, "SIP: Session Initiation Protocol", RFC 3261,
            June 2002.
 [RFC3265]  Roach, A., "Session Initiation Protocol (SIP)-Specific
            Event Notification", RFC 3265, June 2002.
 [RFC3969]  Camarillo, G., "The Internet Assigned Number Authority
            (IANA) Uniform Resource Identifier (URI) Parameter
            Registry for the Session Initiation Protocol (SIP)",
            BCP 99, RFC 3969, December 2004.
 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            May 2008.

10.2. Informative References

 [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 2434,
            October 1998.

Peterson, et al. Best Current Practice [Page 13] RFC 5727 SIP Change March 2010

 [RFC3325]  Jennings, C., Peterson, J., and M. Watson, "Private
            Extensions to the Session Initiation Protocol (SIP) for
            Asserted Identity within Trusted Networks", RFC 3325,
            November 2002.
 [RFC3427]  Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.,
            and B. Rosen, "Change Process for the Session Initiation
            Protocol (SIP)", BCP 67, RFC 3427, December 2002.
 [RFC3968]  Camarillo, G., "The Internet Assigned Number Authority
            (IANA) Header Field Parameter Registry for the Session
            Initiation Protocol (SIP)", BCP 98, RFC 3968,
            December 2004.
 [RFC5111]  Aboba, B. and L. Dondeti, "Experiment in Exploratory Group
            Formation within the Internet Engineering Task Force
            (IETF)", RFC 5111, January 2008.

Authors' Addresses

 Jon Peterson
 NeuStar, Inc.
 EMail: jon.peterson@neustar.biz
 Cullen Jennings
 Cisco Systems
 EMail: fluffy@cisco.com
 Robert Sparks
 Tekelec
 EMail: rjsparks@nostrum.com

Peterson, et al. Best Current Practice [Page 14]

Internet Engineering Task Force (IETF) B. Campbell, Ed. Request for Comments: 7957 Oracle BCP: 67 A. Cooper Updates: 5727 Cisco Category: Best Current Practice B. Leiba ISSN: 2070-1721 Huawei Technologies

                                                           August 2016
      DISPATCH-Style Working Groups and the SIP Change Process

Abstract

 RFC 5727 defined several processes for the former Real-time
 Applications and Infrastructure (RAI) area.  These processes include
 the evolution of the Session Initiation Protocol (SIP) and related
 protocols, as well as the operation of the DISPATCH and SIPCORE
 working groups.  This document updates RFC 5727 to allow flexibility
 for the area and working group structure, while preserving the SIP
 change processes.  It also generalizes the DISPATCH working group
 processes so that they can be easily adopted by other working groups.

Status of This Memo

 This memo documents an Internet Best Current Practice.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 BCPs is available in Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7957.

Campbell, et al. Best Current Practice [Page 1] RFC 7957 Update to SIP Change Process August 2016

Copyright Notice

 Copyright (c) 2016 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
 2.  DISPATCH-Style Working Groups . . . . . . . . . . . . . . . .   3
 3.  Decoupling the SIP Change Process from the RAI Area . . . . .   4
 4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
 5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
   5.2.  Informative References  . . . . . . . . . . . . . . . . .   5
 Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   5
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1. Introduction

 [RFC5727] described processes for evolving and maintaining the
 Session Initiation Protocol (SIP) [RFC3261] and related technologies
 in the former Real-time Application and Infrastructure (RAI) area.
 These processes are collectively known as the "SIP Change Process".
 While areas do not normally have "charters" per se, RFC 5727
 effectively served as a charter for RAI.  The language in RFC 5727
 was tightly bound to the RAI area and to the DISPATCH and SIPCORE
 working groups.
 In 2015, The RAI area merged with the Applications (APP) area to form
 the Applications and Real-Time (ART) area.  This document updates RFC
 5727 to remove its dependency on RAI and its working group structure.
 The updates in this document do not depend on the names of the new
 area, or any specific working group.  Rather, the authors seek to
 future-proof the SIP Change Process against future reorganizations.
 RFC 5727 specified that the DISPATCH working group assesses potential
 new work for the area, and determines where such work should occur.
 DISPATCH does not itself take on such new work.  The SIPCORE working

Campbell, et al. Best Current Practice [Page 2] RFC 7957 Update to SIP Change Process August 2016

 group is responsible for maintenance of SIP.  Other historically RAI
 area working groups develop extensions to SIP that do not change the
 core protocol, new applications of SIP, and other technologies for
 interactive communication among humans.  This document further
 generalizes the processes of the DISPATCH working group so that they
 can be applied to other areas, or to clusters of technologies within
 an area.
 This document does not change any other aspect of RFC 5727.  While
 areas and working groups may change over time, the rules and
 procedures for changing SIP and other historically RAI protocols
 remain the same, until such time that they are updated by future
 documents.

2. DISPATCH-Style Working Groups

 The DISPATCH working group has proven successful at managing new work
 for the RAI and ART areas.  Areas may choose to adopt DISPATCH-like
 procedures, either for an entire area, or for technology clusters in
 an area or across areas.  A "DISPATCH-Style" working group operates
 according to procedures similar to those used for DISPATCH.
 This document is not intended to recommend DISPATCH-style groups for
 any specific IETF area other than ART.  Different areas have
 different needs, and those needs may change over time.  It is up to
 the community and respective Area Directors to determine if a
 DISPATCH-style group is appropriate for any given situation.
 The "DISPATCH-style" includes the following essential elements:
 o  The working group evaluates proposals for new work for an area, or
    for a well-defined technology cluster.  It acts as a filter for
    the area or cluster to determine whether a proposal is a
    reasonable use of, or addition to, associated technologies.  This
    determination may depend upon established criteria (for example,
    the SIP Change Process), the experience and expertise of the
    participants, or a combination of the two.
 o  The DISPATCH-style working group determines an appropriate venue
    for the work.  The venue could be an existing working group.  If
    no appropriate group exists, it may develop a charter for a BoF or
    a new working group.  The group might also recommend that a
    proposal progress as an AD-sponsored individual draft, or even
    that a proposal should not be acted upon at the time.

Campbell, et al. Best Current Practice [Page 3] RFC 7957 Update to SIP Change Process August 2016

 o  The DISPATCH-style working group does not complete the proposed
    work.  It may, however, adopt milestones needed to properly
    dispatch the work.  For example, it may produce charter text for a
    BoF or a new working group, an initial problem statement, or
    documentation about why certain work was not pursued.
 Nothing in this list prevents existing working groups from directly
 adopting new work that reasonably fits their charters, nor does it
 prevent new-work proposals from going directly to BoF meetings when
 appropriate.  For borderline cases, the decision whether new work
 should start in a DISPATCH-style group or elsewhere is made by the
 responsible Area Directors and chairs.  Likewise, in cases where an
 area has multiple DISPATCH-style groups for different purposes or
 technology clusters, deciding which group will handle a particular
 proposal is up to the responsible Area Directors and relevant chairs.
 The charter of a DISPATCH-style group should make that fact clear,
 either by referencing this document, or by directly describing
 similar procedures.

3. Decoupling the SIP Change Process from the RAI Area

 This document clarifies that the SIP Change Process is not bound to
 any particular area or working group structure.  All references to
 the RAI area in RFC 5727 should be interpreted as "the cluster of SIP
 and closely related application and infrastructure technologies, as
 well as other technologies designed primarily for interactive
 communication, historically among humans".
 While the DISPATCH and SIPCORE working groups are expected to
 continue in their current capacities, nothing in the SIP Change
 Process prevents their responsibilities from being assigned to other
 working groups in the future.
 All other aspects of the SIP Change Process are to continue as
 described in RFC 5727.

4. Security Considerations

 This document discusses the roles and responsibilities of areas and
 working groups.  It does not create new security considerations in
 the conventional sense.
 However, organizational structures come with their own security
 considerations.  A DISPATCH-style working group has the potential to
 concentrate the control of work for an area or cluster in the hands
 of a much smaller set of people than those in the whole area or
 cluster.  This could effectively create bottlenecks or roadblocks for

Campbell, et al. Best Current Practice [Page 4] RFC 7957 Update to SIP Change Process August 2016

 new work in an area or cluster.  Likewise, such a concentration could
 reduce the quality of decisions about new work.  Care must be taken
 to avoid this risk.  The best mitigation is active participation in
 the group by as many people in the area or cluster as possible.

5. References

5.1. Normative References

 [RFC5727]  Peterson, J., Jennings, C., and R. Sparks, "Change Process
            for the Session Initiation Protocol (SIP) and the Real-
            time Applications and Infrastructure Area", BCP 67,
            RFC 5727, DOI 10.17487/RFC5727, March 2010,
            <http://www.rfc-editor.org/info/rfc5727>.

5.2. Informative References

 [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
            A., Peterson, J., Sparks, R., Handley, M., and E.
            Schooler, "SIP: Session Initiation Protocol", RFC 3261,
            DOI 10.17487/RFC3261, June 2002,
            <http://www.rfc-editor.org/info/rfc3261>.
 [RFC3427]  Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.,
            and B. Rosen, "Change Process for the Session Initiation
            Protocol (SIP)", RFC 3427, DOI 10.17487/RFC3427, December
            2002, <http://www.rfc-editor.org/info/rfc3427>.

Acknowledgements

 The authors would like to thank all the previous authors of the SIP
 Change Process for their contributions.  Jon Peterson, Cullen
 Jennings, and Robert Sparks authored RFC 5727.  That RFC obsoleted
 [RFC3427], which was in turn written by Allison Mankin, Scott
 Bradner, Rohan Mahy, Dean Willis, Brian Rosen, and Joerg Ott.
 The authors additionally thank the present and past chairs of
 DISPATCH and SIPCORE, as well as all the participants in the former
 RAI area since its inception.

Campbell, et al. Best Current Practice [Page 5] RFC 7957 Update to SIP Change Process August 2016

Authors' Addresses

 Ben Campbell (editor)
 Oracle
 Email: ben@nostrum.com
 Alissa Cooper
 Cisco
 Email: alcoop@cisco.com
 Barry Leiba
 Huawei Technologies
 Phone: +1 646 827 0648
 Email: barryleiba@computer.org
 URI:   http://internetmessagingtechnology.org/

Campbell, et al. Best Current Practice [Page 6]

/data/webs/external/dokuwiki/data/pages/rfc/bcp/bcp67.txt · Last modified: 2016/08/24 20:10 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki