summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7957.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7957.txt')
-rw-r--r--doc/rfc/rfc7957.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc7957.txt b/doc/rfc/rfc7957.txt
new file mode 100644
index 0000000..dae38bc
--- /dev/null
+++ b/doc/rfc/rfc7957.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+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]
+