SIPPING V. Gurbani, Ed.
Internet-Draft Bell Laboratories, Alcatel-Lucent
Intended status: Informational E. Burger, Ed.
Expires: August 12, 2010 Neustar, Inc.
T. Anjali
Illinois Institute of Technology
H. Abdelnur
O. Festor
INRIA
February 8, 2010
The Common Log Format (CLF) for the Session Initiation Protocol (SIP)
draft-ietf-sipclf-problem-statement-00
Abstract
Well-known web servers such as Apache and web proxies like Squid
support event logging using a common log format. The logs produced
using these de-facto standard formats are invaluable to system
administrators for trouble-shooting a server and tool writers to
craft tools that mine the log files and produce reports and trends.
Furthermore, these log files can also be used to train anomaly
detection systems and feed events into a security event management
system. The Session Initiation Protocol does not have a common log
format, and as a result, each server supports a distinct log format
that makes it unnecessarily complex to produce tools to do trend
analysis and security detection. We propose a common log file format
for SIP servers that can be used uniformly by proxies, registrars,
redirect servers as well as back-to-back user agents.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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.
Gurbani, et al. Expires August 12, 2010 [Page 1]
Internet-Draft SIP CLF February 2010
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 12, 2010.
Copyright Notice
Copyright (c) 2010 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 BSD License.
Gurbani, et al. Expires August 12, 2010 [Page 2]
Internet-Draft SIP CLF February 2010
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4
4. What SIP CLF is and what it is not . . . . . . . . . . . . . . 4
5. Alternative approaches to SIP CLF . . . . . . . . . . . . . . 5
5.1. SIP CLF and CDRs . . . . . . . . . . . . . . . . . . . . . 5
5.2. SIP CLF and Wireshark packet capture . . . . . . . . . . . 6
6. Motivation and use cases . . . . . . . . . . . . . . . . . . . 6
7. Challenges in establishing a SIP CLF . . . . . . . . . . . . . 8
8. SIP CLF fields . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. Operational guidance . . . . . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
13.1. Normative References . . . . . . . . . . . . . . . . . . . 12
13.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Gurbani, et al. Expires August 12, 2010 [Page 3]
Internet-Draft SIP CLF February 2010
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
RFC 3261 [2] defines additional terms used in this document that are
specific to the SIP domain such as "proxy"; "registrar"; "redirect
server"; "user agent server" or "UAS"; "user agent client" or "UAC";
"back-to-back user agent" or "B2BUA"; "dialog"; "transaction";
"server transaction".
This document uses the term "SIP Server" that is defined to include
the following SIP entities: user agent server, registrar, redirect
server, a SIP proxy in the role of user agent server, and a B2BUA in
the role of a user agent server.
2. Introduction
Servers executing on Internet hosts produce log records as part of
their normal operations. A log record is, in essence, a summary of
an application layer protocol data unit (PDU), that captures in
precise terms an event that was processed by the server. These log
records serve many purposes, including analysis and troubleshooting.
Well-known web servers such as Apache and Squid support event logging
using a Common Log Format (CLF), the common structure for logging
requests and responses serviced by the web server. It can be argued
that a good part of the success of Apache has been its CLF because it
allowed third parties to produce tools that analyzed the data and
generated traffic reports and trends. The Apache CLF has been so
successful that not only did it become the de-facto standard in
producing logging data for web servers, but also many commercial web
servers can be configured to produce logs in this format. An example
of Apache CLF is depicted next:
%h %l %u %t \"%r\" %s %b
remotehost rfc931 authuser [date] request status bytes
remotehost: Remote hostname (or IP number if DNS hostname is not
available, or if DNSLookup is Off.
rfc931: The remote logname of the user.
Gurbani, et al. Expires August 12, 2010 [Page 4]
Internet-Draft SIP CLF February 2010
authuser: The username by which the user has authenticated himself.
[date]: Date and time of the request.
request: The request line exactly as it came from the client.
status: The HTTP status code returned to the client.
bytes: The content-length of the document transferred.
3. Problem statement
The Session Initiation Protocol [2](SIP) is an Internet multimedia
session signaling protocol that is increasingly used for other
services besides session establishment. A typical delpoyment of SIP
in an enterprise will consist of SIP entities from multiple vendors.
Currently, if these entities are capable of producing a log file of
the transactions being handled by them, the log files are produced in
a proprietary format. The result of multiplicity of the log file
formats is the inability of the support staff to easily trace a call
from one entity to another, or even to craft common tools that will
perform trend analysis, debugging and troubleshooting problems
uniformly across the SIP entities of multiple vendors.
SIP does not currently have a CLF format and this document serves to
provide the rationale to establish a SIP CLF and identifies the
required minimal information that must appear in any SIP CLF record.
4. What SIP CLF is and what it is not
The SIP CLF is a standardized manner of producing a text file. This
format can be used by SIP clients, SIP Servers, proxies, and B2BUAs.
The SIP CLF is simply an easily digestible log of currently occurring
events and past transactions. It contains enough information to
allow humans and automata to derive relationships between discrete
transactions handled at a SIP entity. For example, a SIP
administrator should be able to issue a concise command to discover
relationships between transactions or to search a certain dialog or
transaction.
Note: The exact form of the "concise command" is left unspecified
until the working group agrees to one or more formats for encoding
the fields.
Gurbani, et al. Expires August 12, 2010 [Page 5]
Internet-Draft SIP CLF February 2010
The SIP CLF is amenable to quick parsing (i.e., well-delimited
fields) and it is platform and operating system neutral.
The SIP CLF is amenable to easy parsing and lends itself well to
creating other innovative tools.
The SIP CLF is not a billing tool. It is not expected that
enterprises will bill customers based on SIP CLF. The SIP CLF
records events at the signaling layer only and does not attempt to
correlate the veracity of these events with the media layer. Thus,
it cannot be used to trigger customer billing.
The SIP CLF is not a quality of service (QoS) measurement tool. If
QoS is defined as measuring the mean opinion score (MOS) of the
received media, then SIP CLF does not aid in this task since it does
not summarize events at the media layer.
5. Alternative approaches to SIP CLF
It is perhaps tempting to consider other approaches --- which though
not standardized, are in wide enough use in networks today --- to
determine whether or not a SIP CLF would benefit a SIP network
consisting of mutil-vendor products. The two existing approaches
that approximate what SIP CLF does are Call Detail Records (CDRs) and
Wireshark packet sniffing.
5.1. SIP CLF and CDRs
CDRs are used in operator networks widely and with the adoption of
SIP, standardization bodies such as 3GPP have subsequently defined
SIP-related CDRs as well. Today, CDRs are used to implement the
functionality approximated by SIP CLF, however, there are important
differences.
One, SIP CLF operates natively at the transaction layer and maintains
enough information in the information elements being logged that
dialog-related data can be subsequently derived from the transaction
logs. Thus, esoteric SIP fields and parameters like the To header,
including tags; the From header, including tags, the CSeq number,
etc. are logged in SIP CLF. By contrast, a CDR is used mostly for
charging and thus saves information to facilitate that very aspect.
A CDR will most certainly log the public user identification of a
party requesting a service (which may not correspond to the From
header) and the public user identification of the party called party
(which may not correspond to the To header.) Furthermore, the
sequence numbers maintained by the CDR may not correspond to the SIP
CSeq header. Thus it will be hard to piece together the state of a
Gurbani, et al. Expires August 12, 2010 [Page 6]
Internet-Draft SIP CLF February 2010
dialog through a sequence of CDR records.
Two, a CDR record will, in all probability, be generated at a SIP
entity performing some form of proxy-like functionality of a B2BUA
providing some service. By contrast, SIP CLF is light- weight enough
that it can be generated by a canonical SIP user agent server and
user agent client as well, including those that execute on resource
constrained devices (mobile phones).
Finally, SIP is also being deployed outside of operator- managed VoIP
networks. Universities, research laboratories, and small-to-medium
size companies are deploying SIP-based VoIP solutions on networks
owned and managed by them. Much of the latter constituencies will
not have an interest in generating CDRs, but they will like to have a
concise representation of the messages being handled by the SIP
entities in a common format.
5.2. SIP CLF and Wireshark packet capture
Wireshark is a popular raw packet capture tool. It contains filters
that can understand SIP at the protocol level and break down a
captured message into its individual header components. While
Wireshark is appropriate to capture and view discrete SIP messages,
it does not suffice to serve in the same capacity as SIP CLF for two
reasons.
First, while the Wireshark format saves bulk of the information
needed to create transaction and dialog state, the Wireshark format
is a binary format that does not lend itself very well to being
manipulated by text-based tools. Second and more importantly, if the
SIP messages are exchanged over a TLS-oriented transport, Wireshark
will be unable to decrypt them and render them as individual SIP
headers.
6. Motivation and use cases
As SIP becomes pervasive in multiple business domains and ubiquitous
in academic and research environments, it is beneficial to establish
a CLF for the following reasons:
Common reference for interpreting events: In a laboratory
environment or an enterprise service offering there will typically
be SIP servers from multiple vendors participating in routing
requests. Absent a CLF format, each server will produce output
records in a native format making it hard to establish commonality
for tools that operate on the log file.
Gurbani, et al. Expires August 12, 2010 [Page 7]
Internet-Draft SIP CLF February 2010
Writing common tools: A CLF format allows independent tool providers
to craft tools and applications that interpret the CLF data to
produce insightful trend analysis and detailed traffic reports.
The format should be such that it retains the ability to be read
by humans and processed using traditional Unix text processing
tools.
Session correlation across diverse processing elements: In
operational SIP networks, a request will typically be processed by
more than one SIP server. A SIP CLF will allow the network
operator to trace the progression of the request (or a set of
requests) as they traverse through the different servers to
establish a concise diagnostic trail of a SIP session.
Note that tracing the request through a set of servers is
considerably less challenging if all the servers belong to the
same administrative domain.
Message correlation across transactions: A SIP CLF can enable a
quick lookup of all messages that comprise a transaction (e.g.,
"Find all messages corresponding to server transaction X,
including all forked branches.")
Message correlation across dialogs: A SIP CLF can correlate
transactions that comprise a dialog (e.g., "Find all messages for
dialog created by Call-ID C, From tag F and To tag T.")
Trend analysis: A SIP CLF allows an administrator to collect data
and spot patterns or trends in the information (e.g., "What is the
domain where the most sessions are routed to between 9:00 AM and
12:00 PM?")
Train anomaly detection systems: A SIP CLF will allow for the
training of anomaly detection systems that once trained can
monitor the CLF file to trigger an alarm on the subsequent
deviations from accepted patterns in the data set. Currently,
anomaly detection systems monitor the network and parse raw
packets that comprise a SIP message -- a process that is
unsuitable for anomaly detection systems [3]. With all the
necessary event data at their disposal, network operations
managers and information technology operation managers are in a
much better position to correlate, aggregate, and prioritize log
data to maintain situational awareness.
Gurbani, et al. Expires August 12, 2010 [Page 8]
Internet-Draft SIP CLF February 2010
Testing: A SIP CLF allows for automatic testing of SIP equipment by
writing tools that can parse a SIP CLF file to ensure behavior of
a device under test.
Troubleshooting: A SIP CLF can enable cursory trouble shooting of a
SIP server (e.g., "How long did it take to generate a final
response for the INVITE associated with Call-ID X?")
Offline analysis: A SIP CLF allows for offline analysis of the data
gathered. Once a SIP CLF file has been generated, it can be
transported (subject to the security considerations in Section 9)
to a host with appropriate computing resources to perform
subsequent analysis.
Real-time monitoring: A SIP CLF allows administrators to visually
notice the events occurring at a SIP server in real-time providing
accurate situational awareness.
7. Challenges in establishing a SIP CLF
Establishing a CLF for SIP is a challenging task. The behavior of a
SIP entity is more complex when compared to the equivalent HTTP
entity.
Base protocol services such as parallel or serial forking elicit
multiple final responses. Ensuing delays between sending a request
and receiving a final response all add complexity when considering
what fields should comprise a CLF and in what manner. Furthermore,
unlike HTTP, SIP groups multiple discrete transactions into a dialog,
and these transactions may arrive at a varying inter-arrival rate at
a proxy. For example, the BYE transaction usually arrives much after
the corresponding INVITE transaction was received, serviced and
expunged from the transaction list. Nonetheless, it is advantageous
to relate these transactions such that automata or a human monitoring
the log file can construct a set consisting of related transactions.
ACK requests in SIP need careful consideration as well. In SIP, an
ACK is a special method that is associated with an INVITE only. It
does not require a response, and furthermore, if it is acknowledging
a non-2xx response, then the ACK is considered part of the original
INVITE transaction. If it is acknowledging a 2xx-class response,
then the ACK is a separate transaction consisting of a request only
(i.e., there is not a response for an ACK request.) CANCEL is
another method that is tied to an INVITE transaction, but unlike ACK,
the CANCEL request elicits a final response.
Gurbani, et al. Expires August 12, 2010 [Page 9]
Internet-Draft SIP CLF February 2010
While most requests elicit a response immediately, the INVITE request
in SIP can pend at a proxy as it forks branches downstream or at a
user agent server while it alerts the user. RFC 3261 [2] instructs
the server transaction to send a 1xx-class provisional response if a
final response is delayed for more than 200 ms. A SIP CLF log file
needs to include such provisional responses because they help train
automata associated with anomaly detection systems and provide some
positive feedback for a human observer monitoring the log file.
Finally, beyond supporting native SIP actors such as proxies,
registrars, redirect servers, and user agent servers (UAS), it is
beneficial to derive a CLF format that supports back-to-back user
agent (B2BUA) behavior, which may vary considerably depending on the
specific nature of the B2BUA.
8. SIP CLF fields
The inspiration for the SIP CLF is the Apache CLF. However, the
state machinery for a HTTP transaction is much simpler than that of
the SIP transaction (as evidenced in Section 7). The SIP CLF needs
to do considerably more.
Accordingly, the following SIP CLF fields are defined as mininal
information that must appear in any SIP CLF record:
date: Date and time of the request or response represented as the
number of seconds and milliseconds since the Unix epoch.
remotehost: The DNS name or IP address of the upstream client.
authuser: The user name by which the user has been authenticated.
If the user name is unknown or when a request is challenged, the
value in this field must be "-"
method: The upper-case name of the SIP method.
request-uri: The Request-URI, including any URI parameters.
from: The From URI, including the tag. Whilst one may question the
value of the From URI in light of RFC4744 [4], the From URI,
nonetheless, imparts some information. For one, the From tag is
important and, in the case of a REGISTER request, the From URI can
provide information on whether this was a third-party registration
or a first-party one.
Gurbani, et al. Expires August 12, 2010 [Page 10]
Internet-Draft SIP CLF February 2010
to: The To URI, including tag.
callid: The Call-ID.
status: The SIP response status code returned upstream.
contactlist: Contact URIs in the response, if any. A "-" field
value may be used if there aren't any Contact URIs.
server-txn: Server transaction identification code - the transaction
identifier associated with the server transaction.
Implementations can reuse the server transaction identifier (the
topmost branch-id of the incoming request, with or without the
magic cookie), or they could generate a unique identification
string for a server transaction (this identifier needs to be
locally unique to the server only.) This identifier is used to
correlate ACKs and CANCELs to an INVITE transaction; it is also
used to aid in forking as explained later in this section.
client-txn: Client transaction identification code - this field is
used to associate client transactions with a server transaction
for forking proxies or B2BUAs. Upon forking, implementations can
reuse the value they inserted into the topmost Via header's branch
parameter, or they can generate a unique identification string for
the client transaction. A more detailed explanation of why it is
needed is provided next.
SIP Proxies may fork, creating several client transactions that
correlate to a single server transaction. Responses arriving on
these client transactions, or new requests (CANCEL, ACK) sent on the
client transaction need log file entries that correlate with a server
transaction. Similarly, a B2BUA may create one or more client
transactions in response to an incoming request. These transactions
will require correlation as well.
To best demonstrate the correlation directives "server-txn" and
"client-txn", some examples are necessary. In order to do so, it
helps to use a canonical representation for the SIP CLF. The most
expedient way to do so is to use an ASCII representation for
illustration purposes only, but to be safe, the working group
should okay this since a specific SIP CLF format has not been
defined yet. To get a gist of how these correlation directives
help, please see Section 6 of a predecessor [5] to this draft.
Finally, the SIP CLF should be extensible such that future SIP
methods, headers and bodies can be represented as well.
Gurbani, et al. Expires August 12, 2010 [Page 11]
Internet-Draft SIP CLF February 2010
Note: Not sure what else to say here since the specific format
used to encode the CLF has some bearing on extensibility. A type-
length-value (TLV) format or a PCAP format has advantages over an
ASCII format. All three formats -- the ASCII, binary TLV format,
and the PCAP format -- are available in Gurbani et al. [5], Roach
[6], and Kaplan [7], respectively.
9. Security Considerations
A log file by its nature reveals the both the state of the entity
producing it and the nature of the information being logged. To the
extent that this state should not be publicly accessible and that the
information is to be considered private, appropriate file and
directory permissions attached to the log file should be used. In
the worst case, public access to the SIP log file provides the same
information that an adversary can gain using network sniffing tools
(assuming that the SIP traffic is in clear text.) If all SIP traffic
on a network segment is encrypted, then special attention must be
directed to the file and directory permissions associated with the
log file to preserve privacy such that only a privileged user can
access the contents of the log file.
Transporting SIP CLF files across the network pose special challenges
as well. While transporting SIP CLF files is out of scope in the
current working group charter, it seems worth drawing attention to
the fact that if the file is transported using unencrypted FTP or
email, intermediaries and adversaries may have access to the raw SIP
CLF records. Accordingly, if the SIP CLF file is to be moved from
the generating host, secure FTP or secure email must be used instead.
The SIP CLF represents the minimum fields that lend themselves to
trend analysis and serve as information that may be deemed useful.
Other formats can be defined that include more headers (and the body)
from Section 8. However, where to draw a judicial line regarding the
inclusion of non-mandatory headers can be challenging. Clearly, the
more information a SIP server logs, the longer time the logging
process will take, the more disk space the log entry will consume,
and the more potentially sensitive information could be breached.
Therefore, adequate tradeoffs should be taken in account when logging
more fields than the ones recommended in Section 8.
Implementers need to pay particular attention to buffer handling when
reading or writing log files. SIP CLF entries can be unbounded in
length. It would be reasonable for a full dump of a SIP message to
be thousands of octets long. This is of particular importance to CLF
log parsers, as a SIP CLF log writers may add one or more extension
fields to the message to be logged.
Gurbani, et al. Expires August 12, 2010 [Page 12]
Internet-Draft SIP CLF February 2010
10. Operational guidance
SIP CLF log files will take up substantive amount of disk space
depending on traffic volume at a processing entity and the amount of
information being logged. As such, any enterprise using SIP CLF
should establish operational procedures for file rollovers as
appropriate to the needs of the organization.
Listing such operational guidelines in this document is out of scope
for this work.
11. IANA Considerations
This document does not require any considerations from IANA.
12. Acknowledgments
Members of the sipping, dispatch, ipfix and syslog working groups
provided invaluable input to the formulation of the draft. These
include Benoit Claise, Spencer Dawkins, David Harrington, Christer
Holmberg, Hadriel Kaplan, Atsushi Kobayashi, Jiri Kuthan, Scott
Lawrence, Simon Perreault, Adam Roach, Dan Romascanu, Robert Sparks,
Brian Trammell, Dale Worley, Theo Zourzouvillys and others that we
have undoubtedly, but inadvertently, missed.
Adam Roach proposed and documented the binary TLV-format and Hadriel
Kaplan proposed and documented the PCAP-based format as alternative
SIP CLF representations.
13. References
13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] 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.
13.2. Informative References
[3] Rieck, K., Wahl, S., Laskov, P., Domschitz, P., and K-R.
Muller, "A Self-learning System for Detection of Anomalous SIP
Messages", Principles, Systems and Applications of IP
Gurbani, et al. Expires August 12, 2010 [Page 13]
Internet-Draft SIP CLF February 2010
Telecommunications Services and Security for Next Generation
Networks (IPTComm), LNCS 5310, pp. 90-106, 2008.
[4] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[5] Gurbani, V., Burger, E., Anjali, T., Abdelnur, H., and O.
Festor, "The Common Log File (CLF) format for the Session
Initiation Protocol (SIP)", draft-gurbani-sipping-clf-01 (work
in progress), March 2009.
[6] Roach, A., "Binary Syntax for SIP Common Log Format",
draft-roach-sipping-clf-syntax-01 (work in progress), May 2009.
[7] Kaplan, H., "PCAP-compatible Binary Syntax for SIP Common Log
File Format", draft-kaplan-sipping-clf-pcap-00 (work in
progress), June 2009.
[8] Debar, H., Curry, D., and B. Feinstein, "The Intrusion
Detection Message Exchange Format (IDMEF)", RFC 4765,
March 2007.
[9] Claise, B., "Specification of the IP Flow Information Export
(IPFIX) Protocol for the Exchange of IP Traffic Flow
Information", RFC 5101, January 2008.
[10] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
Authors' Addresses
Vijay K. Gurbani (editor)
Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane
Naperville, IL 60566
USA
Email: vkg@bell-labs.com
Eric W. Burger (editor)
Neustar, Inc.
USA
Email: eburger@standardstrack.com
URI: http://www.standardstrack.com
Gurbani, et al. Expires August 12, 2010 [Page 14]
Internet-Draft SIP CLF February 2010
Tricha Anjali
Illinois Institute of Technology
316 Siegel Hall
Chicago, IL 60616
USA
Email: tricha@ece.iit.edu
Humberto Abdelnur
INRIA
INRIA - Nancy Grant Est
Campus Scientifique
54506, Vandoeuvre-les-Nancy Cedex
France
Email: Humberto.Abdelnur@loria.fr
Olivier Festor
INRIA
INRIA - Nancy Grant Est
Campus Scientifique
54506, Vandoeuvre-les-Nancy Cedex
France
Email: Olivier.Festor@loria.fr
Gurbani, et al. Expires August 12, 2010 [Page 15]
