Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area
draft-peterson-rai-rfc3427bis-04

Network Working Group                                        J. Peterson
Internet-Draft                                             NeuStar, Inc.
Obsoletes: 3427 (if approved)                                C. Jennings
Updates: 3265,3969                                         Cisco Systems
(if approved)                                                  R. Sparks
Intended status: BCP                                             Tekelec
Expires: April 26, 2010                                 October 23, 2009

 Change Process for the Session Initiation Protocol (SIP) and the Real-
               time Applications and Infrastructure Area
                    draft-peterson-rai-rfc3427bis-04

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  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.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 26, 2010.

Copyright Notice

Peterson, et al.         Expires April 26, 2010                 [Page 1]
Internet-Draft                 SIP change                   October 2009

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Peterson, et al.         Expires April 26, 2010                 [Page 2]
Internet-Draft                 SIP change                   October 2009

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 which are, respectively, responsible for the maintenance
   of the core SIP specifications and development of new efforts to
   extend and apply work in this space.  This document obsoletes
   RFC3427.

Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  History and Development  . . . . . . . . . . . . . . . . . . .  5
     2.1.  The IETF SIPCORE Working Group . . . . . . . . . . . . . .  5
     2.2.  The IETF DISPATCH Working Group  . . . . . . . . . . . . .  6
   3.  Introducing New Work to RAI  . . . . . . . . . . . . . . . . .  8
   4.  Extensibility and Architecture . . . . . . . . . . . . . . . . 10
     4.1.  SIP Event Packages . . . . . . . . . . . . . . . . . . . . 11
   5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
     7.1.  Clarification of RFC3969 . . . . . . . . . . . . . . . . . 16
   8.  Overview of changes to RFC3427 . . . . . . . . . . . . . . . . 18
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     10.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21

Peterson, et al.         Expires April 26, 2010                 [Page 3]
Internet-Draft                 SIP change                   October 2009

1.  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.         Expires April 26, 2010                 [Page 4]
Internet-Draft                 SIP change                   October 2009

2.  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].  SIP change defined the role of the SIP and SIPPING
   working groups in shepherding ongoing work on the SIP standard.  It
   also defined ways that external working groups or bodies could define
   extensions intended for limited usage, especially through the "P-"
   header field mechanism.

   Over time, however, the management structure of RFC3427 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 RFC3427 and describes a new
   structure for the management of deliverables in the Real-time
   Applications and Infrastructure Area.

2.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 are compelling reasons to do so.

   The SIPCORE working group replaces the function of the SIP working
   group in the original RFC3427 account.  Documents that must be

Peterson, et al.         Expires April 26, 2010                 [Page 5]
Internet-Draft                 SIP change                   October 2009

   handled by the SIPCORE working group include all documents which
   update or obsolete RFC3261 through RFC3265 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; SIPCORE's charter is
   however 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.

2.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;
   however, any new proposed work which does not clearly fall within the
   charter of an existing RAI Area effort should be examined by
   DISPATCH.

Peterson, et al.         Expires April 26, 2010                 [Page 6]
Internet-Draft                 SIP change                   October 2009

   In reaction to a proposal, the DISPATCH Working Group may determine:
   that these requirements justify a change to the core SIP
   specifications (RFC3261 through RFC3265) and thus any resulting work
   must transpire in SIPCORE, that the 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), that the requirements
   fall within the scope of existing chartered work in the RAI Area, or
   that 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 which 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.

Peterson, et al.         Expires April 26, 2010                 [Page 7]
Internet-Draft                 SIP change                   October 2009

3.  Introducing New Work to RAI

   When proposals arise for modifications or extensions to SIP outside
   the scope of existing chartered RAI Area work, they must be written
   up as a problem statement (preferably as an Internet-Draft)
   explaining the problem they are trying to solve, why SIP is the
   applicable protocol, and why the existing SIP protocol will not work.
   The problem statement must include a detailed set of requirements
   (distinct from solutions) that SIP would need to meet to solve the
   particular problem.  The problem statement must also describe in
   detail any security issues that arise from meeting those
   requirements.  After the problem statement is published, the authors
   should send a note to the DISPATCH Working Group mailing list to
   start discussion on the problem.

   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.

   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.

Peterson, et al.         Expires April 26, 2010                 [Page 8]
Internet-Draft                 SIP change                   October 2009

   Some working groups generate requirements for SIP solutions and/or
   extensions.  At the time this document was written, some 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 RAI ADs may, on an exceptional, case by case basis, support a
   process in which the requirements analysis is implicit and a RAI area
   working group handling extensions to SIP requests the addition of a
   charter item for an extension without a full DISPATCH process as
   described.

Peterson, et al.         Expires April 26, 2010                 [Page 9]
Internet-Draft                 SIP change                   October 2009

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".

   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 field name prefix ("P-" or "X-" or what have you) to

Peterson, et al.         Expires April 26, 2010                [Page 10]
Internet-Draft                 SIP change                   October 2009

   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 which support it.  Header fields which 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 which provide data
       consumed by applications at the ends of SIP's rendez-vous
       function, rather than changing the behavior of the rendez-vous
       function, are likely to be 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 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

Peterson, et al.         Expires April 26, 2010                [Page 11]
Internet-Draft                 SIP change                   October 2009

   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 which 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.

   "RFC Required" in conjunction with "Designated Expert" (both as
   defined in RFC5226) 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 RFC5226) 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 5 of SIP events [RFC3265].

Peterson, et al.         Expires April 26, 2010                [Page 12]
Internet-Draft                 SIP change                   October 2009

   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.

Peterson, et al.         Expires April 26, 2010                [Page 13]
Internet-Draft                 SIP change                   October 2009

5.  Summary

   1.  Documents that update or obsolete RFC 3261 through 3265 must
       advance through the SIPCORE WG.

   2.  Standard SIP extensions which do not update RFC 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.

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

Peterson, et al.         Expires April 26, 2010                [Page 14]
Internet-Draft                 SIP change                   October 2009

6.  Security Considerations

   Complex and 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.

Peterson, et al.         Expires April 26, 2010                [Page 15]
Internet-Draft                 SIP change                   October 2009

7.  IANA Considerations

   RFC 3261 [RFC3261] 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 RFC3261, 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
   [RFC3968].

   Previously in RFC3427, all new SIP header field registrations
   required a Standards Action (per RFC5226) 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 which 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 an 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.

   Similarly, RFC 3265 [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 RFC3969

   RFC3969 [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

Peterson, et al.         Expires April 26, 2010                [Page 16]
Internet-Draft                 SIP change                   October 2009

   of the RFC2434 categories; the intention was for the IANA
   Considerations to mandate that Standards Action is required.

Peterson, et al.         Expires April 26, 2010                [Page 17]
Internet-Draft                 SIP change                   October 2009

8.  Overview of changes to RFC3427

   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, clarifying that
       the original RFC 3237 updated the policies in RFC 3265.

Peterson, et al.         Expires April 26, 2010                [Page 18]
Internet-Draft                 SIP change                   October 2009

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, 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
   were provided by Jonathan Rosenberg, Mary Barnes, Dan York, John
   Elwell, Alan Johnston, Spencer Dawkins, Alfred Hines, Russ Housley
   and Dean Willis.  The thorough review from Stephen Hanna of the
   Security Directorate proved enormously valuable.  The authors also
   appreciaed 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.

Peterson, et al.         Expires April 26, 2010                [Page 19]
Internet-Draft                 SIP change                   October 2009

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

   [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.

Peterson, et al.         Expires April 26, 2010                [Page 20]
Internet-Draft                 SIP change                   October 2009

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.         Expires April 26, 2010                [Page 21]