doc: Add RFC documents

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]
+