< draft-campbell-art-rfc5727-update-00.txt   draft-campbell-art-rfc5727-update-01.txt >
Internet Engineering Task Force B. Campbell, Ed. Internet Engineering Task Force B. Campbell, Ed.
Internet-Draft Oracle Internet-Draft Oracle
Updates: 5727 (if approved) A. Cooper Updates: 5727 (if approved) A. Cooper
Intended status: Best Current Practice Cisco Intended status: Best Current Practice Cisco
Expires: November 26, 2015 B. Leiba Expires: November 30, 2015 B. Leiba
Huawei Huawei
May 25, 2015 May 29, 2015
Improving the Organizational Flexibility of the SIP Change Process. Improving the Organizational Flexibility of the SIP Change Process.
draft-campbell-art-rfc5727-update-00 draft-campbell-art-rfc5727-update-01
Abstract Abstract
RFC 5727 defines several processes for the Real-time Applications and RFC 5727 defines several processes for the Real-time Applications and
Infrastructure (RAI) area. These processes include the evolution of Infrastructure (RAI) area. These processes include the evolution of
the Session Initiation Protocol (SIP) and related protocols, as well the Session Initiation Protocol (SIP) and related protocols, as well
as the operation of the DISPATCH and SIPCORE working groups. This as the operation of the DISPATCH and SIPCORE working groups. This
document updates RFC 5727 to allow flexibility for the area and document updates RFC 5727 to allow flexibility for the area and
working group structure, while preserving the SIP change processes. 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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 26, 2015. This Internet-Draft will expire on November 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 35 skipping to change at page 3, line 37
the SIP Change Process), the experience and expertise of the the SIP Change Process), the experience and expertise of the
participants, or a combination of the two. participants, or a combination of the two.
o The dispatch-style working group determines an appropriate venue o The dispatch-style working group determines an appropriate venue
for the work. The venue could be an existing working group. If for the work. The venue could be an existing working group. If
no appropriate group exist, it may develop a charter for a BoF, a no appropriate group exist, it may develop a charter for a BoF, a
new working group, or an exploratory group [RFC5111]. The working new working group, or an exploratory group [RFC5111]. The working
group may also determine that a proposal should not be acted upon group may also determine that a proposal should not be acted upon
at the time. at the time.
o The working group does not complete the proposed work. It may, o The dispatch-style working group does not complete the proposed
however, adopt milestones needed to properly dispatch the work. work. It may, however, adopt milestones needed to properly
For example, it may produce charter text for a BoF or a new dispatch the work. For example, it may produce charter text for a
working group, an initial problem statement, or documentation BoF or a new working group, an initial problem statement, or
about why certain work was not pursued. documentation about why certain work was not pursued.
Nothing in this list prevents existing working groups from directly Nothing in this list prevents existing working groups from directly
adopting new work that reasonably fits their charters. For adopting new work that reasonably fits their charters. For
borderline cases, the decision whether new work should start in a borderline cases, the decision whether new work should start in a
dispatch-style group, or in an existing group is a judgement call dispatch-style group, or in an existing group is a judgement call
among the responsible Area Directors and chairs. Likewise, in cases among the responsible Area Directors and chairs. Likewise, in cases
where an area has multiple dispatch-style groups for different where an area has multiple dispatch-style groups for different
purposes or technology clusters, the decision about which group will purposes or technology clusters, the decision about which group will
handle a particular proposal is a judgement call. handle a particular proposal is a judgement call.
skipping to change at page 4, line 35 skipping to change at page 4, line 39
5. Security Considerations 5. Security Considerations
This document discusses the roles and responsibilities of areas and This document discusses the roles and responsibilities of areas and
working groups. It does not create new security considerations in working groups. It does not create new security considerations in
the conventional sense. the conventional sense.
However, organizational structures come with their own security However, organizational structures come with their own security
considerations. A dispatch-stye working group has the potential to considerations. A dispatch-stye working group has the potential to
concentrate the control of work for an area or cluster in the hands concentrate the control of work for an area or cluster in the hands
of a small number of people. This could have the effect of a "Denial of a much smaller set of people than those in the whole area or
of Service Attack" against the area or cluster. Likewise, such a cluster. This could have the effect of a "Denial of Service Attack"
concentration could reduce the quality of decisions about new work. against the area or cluster. Likewise, such a concentration could
Care must be taken to avoid this risk. While this responsibility reduce the quality of decisions about new work. Care must be taken
lies primarily with the relevant Area Directors, all participants to avoid this risk. The best mitigation is active participation in
must play a roll. the group by as many people in the area or cluster as possible.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank all the previous authors of the SIP The authors would like to thank all the previous authors of the SIP
Change Process for their contributions. Jon Peterson, Cullen Change Process for their contributions. Jon Peterson, Cullen
Jennings, and Robert Sparks authored RFC 5727. That RFC obsoleted Jennings, and Robert Sparks authored RFC 5727. That RFC obsoleted
[RFC3427], which was in turn written by Allison Mankin, Scott [RFC3427], which was in turn written by Allison Mankin, Scott
Bradner, Rohan Mahy, Dean Willis, Brian Rosen, and Joerg Ott. Bradner, Rohan Mahy, Dean Willis, Brian Rosen, and Joerg Ott.
The authors additionally thank the present and past chairs of The authors additionally thank the present and past chairs of
 End of changes. 7 change blocks. 
15 lines changed or deleted 17 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/