Network Working Group J. Peterson
Internet-Draft NeuStar, Inc.
Intended status: Standards Track C. Jennings
Expires: August 30, 2009 Cisco Systems
February 26, 2009
Change Process for the Session Initiation Protocol (SIP)
draft-peterson-rai-rfc3427bis-01
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 August 30, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Peterson & Jennings Expires August 30, 2009 [Page 1]
Internet-Draft SIP change February 2009
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 & Jennings Expires August 30, 2009 [Page 2]
Internet-Draft SIP change February 2009
Abstract
This memo documents a process intended to organize the future
development of the Session Initiation Protocol (SIP). 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 SIP. 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. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. Clarification of RFC3969 . . . . . . . . . . . . . . . . . 15
7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Changes from RFC3427bis-00 . . . . . . . . . . . . . . . . 16
7.2. Changes from RFC3427 . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Peterson & Jennings Expires August 30, 2009 [Page 3]
Internet-Draft SIP change February 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 & Jennings Expires August 30, 2009 [Page 4]
Internet-Draft SIP change February 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 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 mechanism.
Over time, however, the management structure of RFC3427 has
demonstrated some limitations. The first and most significant of
these lies in the "P-" headers. While "P-" headers require expert
review and IESG shepherding, in practice IETF oversight of these
headers 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 name does nothing to prevent a popular
header from seeing deployment outside of the original "limited usage"
it envisioned; a prominent example of this today is the P-Asserted-
Identity (PAID) header, described in RFC3325 [RFC3325].
Consequently, this document obsoletes RFC3427 and describes a new
structure for the management of IETF deliverables.
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
life of the working group exists. All changes or extensions to SIP
must first 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 therefore 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
handled by the SIPCORE working group include all updates or obsoletes
of RFC3261 through RFC3265. All SIP extensions considered in SIPCORE
Peterson & Jennings Expires August 30, 2009 [Page 5]
Internet-Draft SIP change February 2009
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 the 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. The IETF will remain the home of
extensions of SIP and the rest of this document. The rate of growth
of extensions of any protocol in the IETF is hoped to be low.
It is appropriate for any 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. 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.
In reaction to a proposal, the DISPATCH Working Group may determine:
that these requirements justify a change to the core SIP
Peterson & Jennings Expires August 30, 2009 [Page 6]
Internet-Draft SIP change February 2009
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 adopt
milestones 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 & Jennings Expires August 30, 2009 [Page 7]
Internet-Draft SIP change February 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 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 Internet-Draft must include a detailed
set of requirements (distinct from solutions) that SIP would need to
meet to solve the particular problem. The Internet-Draft must also
describe in detail any security issues that arise from meeting those
requirements. After the Internet-Draft is published, the authors
should send a note to the DISPATCH Working Group mailing list to
start discussion on the Internet-Draft.
The DISPATCH working group chairs, in conjunction with the RAI Area
Directors, will determine if the particular problems raised in the
requirements Internet-Draft is indeed outside the charter of existing
efforts, and if so, if it warrants a DISPATCH milestone for the
definition of a new effort. The DISPATCH working group should
consider whether the requirements can be merged with other
requirements from other applications, and refine the ID accordingly.
Once a new effort has been defined in DISPATCH and there is 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
process for chartering efforts. 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.
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.
With respect to standardization, this process means that SIP
extensions come only from the IETF, the body that created SIP. The
IETF will not publish a SIP extension RFC outside of the processes
described here. The DISPATCH working group may also evaluate and
Peterson & Jennings Expires August 30, 2009 [Page 8]
Internet-Draft SIP change February 2009
approve proposals for extensions if the requirements are judged to be
appropriate to SIP, but are not sufficiently general for standards
track activity.
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 a case by case basis, support a process in which
the requirements analysis is implicit and the SIP working group
requests the addition of a charter item for an extension without a
full DISPATCH process as described. This will be the exception.
Peterson & Jennings Expires August 30, 2009 [Page 9]
Internet-Draft SIP change February 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
headers 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, 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, headers associated with those extensions were called "P-"
headers, for "preliminary", "private", or "proprietary".
However, the "P-" header 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-" headers have enjoyed widespread
implementation; because of the "P-" prefix, however, there seems to
be no plausible migration path to designate these as general-usage
headers without trying to force implausible changes on large bases of
installments.
Accordingly, this specification deprecates the previous RFC3427
guidance on the creation of "P-" headers. Existing "P-" headers are
to be handled by user agents and proxy servers as the "P-" header
specifications describe; the deprecation of the change process
mechanism entails no change in protocol behavior. New proposals to
document SIP headers of an experimental or private nature, however,
shall not use the "P-" prefix.
Instead, the registration of SIP headers in Informational IETF
specifications, or in documents outside the IETF, is now permitted
under the Designated Expert (per RFC5226) criteria. The use of any
header field name prefix ("P-" or "X-" or what have you) to designate
headers of limited applicability is discouraged. Experts are advised
to review documents for overlap with existing chartered work in RAI,
and are furthermore instructed to ensure the following two criteria
Peterson & Jennings Expires August 30, 2009 [Page 10]
Internet-Draft SIP change February 2009
are met:
1. The proposed header MUST be of a purely informational nature, and
MUST NOT significantly change the behavior of SIP entities which
support it. Headers which merely provide additional information
pertinent to a request or a response are acceptable; these
headers are thus expected to have few if any implications for
interoperability and backwards compatibility. Similarly, headers
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 headers 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 MUST NOT undermine SIP security in any sense.
The Internet Draft proposing the new header 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 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 [6] 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). Normal event packages can be
created and registered by the publication of any Working Group RFC
(Informational, Standards Track, Experimental), provided that the RFC
is a chartered working group item. 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
Peterson & Jennings Expires August 30, 2009 [Page 11]
Internet-Draft SIP change February 2009
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. The author should submit his or her proposal as an individual
Internet- Draft, and post an announcement to the working group
mailing list to begin discussion. The DISPATCH Working Group will
determine if the 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) should be adopted as or merged with chartered work.
"RFC Required" (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 [6], SIP [3], 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 [6].
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
Peterson & Jennings Expires August 30, 2009 [Page 12]
Internet-Draft SIP change February 2009
general use of SIP in the Internet.
Peterson & Jennings Expires August 30, 2009 [Page 13]
Internet-Draft SIP change February 2009
5. Security Considerations
Complexity and indeterminate or hard to define protocol behavior,
depending on which of many extensions operate, 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 and do not worsen SIP's
existing security considerations.
Peterson & Jennings Expires August 30, 2009 [Page 14]
Internet-Draft SIP change February 2009
6. IANA Considerations
RFC 3261 [3] 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 headers.
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 registrations required a
Standards Action (per RFC5226) with the exception of "P-" headers;
now, Informational registration of non-"P-" headers 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 headers and messages MUST NOT begin with the leading
characters "P-". Existing "P-" header registrations are considered
grandfathered, but new registrations of Informational headers need
not begin with the leading characters "P-". Short forms of headers
MUST only be assigned to standards track headers.
Similarly, RFC 3265 [6] 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. For ordinary event packages, as stated
previously registrations require RFC5226 IETF Review. In either
case, the IESG announcement of approval authorizes IANA to make the
registration.
6.1. Clarification of RFC3969
RFC3969 [4] 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.
Peterson & Jennings Expires August 30, 2009 [Page 15]
Internet-Draft SIP change February 2009
7. Changelog
7.1. Changes from RFC3427bis-00
Changed description of the SIP and SIPPING WG functions to the
SIPCORE and DISPATCH WG functions.
Deprecated the process for "P-" header registration.
Updated the document to reflect the publication of RFC5226.
Numerous informative changes motivating some of the above.
7.2. Changes from RFC3427
References to the Transport Areas have been changed to point to
the RAI ADs.
Rewrote IANA registry requirements in terms of RFC2434bis.
Updated list of working groups at the end of Section 3.
Clarified that the original RFC3427 altered the IANA registration
policy of RFC3265.
Clarified the IANA registration policy in 3969.
Peterson & Jennings Expires August 30, 2009 [Page 16]
Internet-Draft SIP change February 2009
8. 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, Robert Sparks, and
Dean Willis.
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 & Jennings Expires August 30, 2009 [Page 17]
Internet-Draft SIP change February 2009
9. 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.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Peterson & Jennings Expires August 30, 2009 [Page 18]
Internet-Draft SIP change February 2009
Authors' Addresses
Jon Peterson
NeuStar, Inc.
Email: jon.peterson@neustar.biz
Cullen Jennings
Cisco Systems
Email: fluffy@cisco.com
Peterson & Jennings Expires August 30, 2009 [Page 19]