draft-ietf-speermint-architecture-01.txt   draft-ietf-speermint-architecture-02.txt 
Speermint Working Group R.Penno (Editor) Speermint Working Group R.Penno (Editor)
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expires: March 2007 September 18, 2006 Expires: April 2007 October 20, 2006
SPEERMINT Peering Architecture SPEERMINT Peering Architecture
draft-ietf-speermint-architecture-01 draft-ietf-speermint-architecture-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 2, line 11 skipping to change at page 2, line 11
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1] document are to be interpreted as described in [1]
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
2. Network Context................................................3 2. Network Context................................................3
3. Procedures.....................................................5 3. Procedures.....................................................5
4. Reference SPEERMINT Architecture...............................5 4. Reference SPEERMINT Architecture...............................5
5. Peer Function Examples.........................................7 5. Peer Function Examples.........................................6
5.1. The Location Function (LF) of an Initiating Provider......7 5.1. The Location Function (LF) of an Initiating Provider......7
5.1.1. Target address analysis..............................7 5.1.1. Target address analysis..............................7
5.1.2. User ENUM Lookup.....................................8 5.1.2. User ENUM Lookup.....................................7
5.1.3. Carrier ENUM lookup..................................8 5.1.3. Carrier ENUM lookup..................................8
5.1.4. Routing Table........................................8 5.1.4. Routing Table........................................8
5.1.5. SIP DNS Resolution...................................8 5.1.5. SIP DNS Resolution...................................8
5.1.6. SIP Redirect Server..................................9 5.1.6. SIP Redirect Server..................................9
5.2. The Location Function (LF) of a Receiving Provider........9 5.2. The Location Function (LF) of a Receiving Provider........9
5.2.1. Publish ENUM records.................................9 5.2.1. Publish ENUM records.................................9
5.2.2. Publish SIP DNS records..............................9 5.2.2. Publish SIP DNS records..............................9
5.3. Policy Function (PF)......................................9 5.2.3. TLS..................................................9
5.3.1. TLS.................................................11 5.2.4. IPSec................................................9
5.3.2. IPSec...............................................11 5.2.5. Subscribe Notify....................................10
5.3.3. Subscribe Notify....................................11 5.3. Signaling Function (SF)..................................10
5.4. Signaling Function (SF)..................................11 5.4. Media Function (MF)......................................10
5.5. Media Function (MF)......................................12 5.5. Policy Considerations....................................10
6. Call Control and Media Control Deployment Options.............12 6. Call Control and Media Control Deployment Options.............11
7. Security Considerations.......................................13 7. Address space considerations..................................12
8. IANA Considerations...........................................14 8. Security Considerations.......................................13
9. Acknowledgments...............................................14 9. IANA Considerations...........................................13
Author's Addresses...............................................15 10. Acknowledgments..............................................13
10. References...................................................15 Author's Addresses...............................................14
10.1. Normative References....................................15 11. References...................................................14
10.2. Informative References..................................16 11.1. Normative References....................................14
Intellectual Property Statement..................................17 11.2. Informative References..................................15
Disclaimer of Validity...........................................18 Intellectual Property Statement..................................16
Copyright Statement..............................................18 Disclaimer of Validity...........................................17
Acknowledgment...................................................18 Copyright Statement..............................................17
Acknowledgment...................................................17
1. Introduction 1. Introduction
The objective of this document is to define a reference peering The objective of this document is to define a reference peering
architecture in the context of Session PEERing for Multimedia architecture in the context of Session PEERing for Multimedia
INTerconnect (SPEERMINT). In this process, we define the peering INTerconnect (SPEERMINT). In this process, we define the peering
reference architecture (reference, for short), its functional reference architecture (reference, for short), its functional
components, and peering interface functions from the perspective of a components, and peering interface functions from the perspective of a
real-time communications (Voice and Multimedia) IP Service provider real-time communications (Voice and Multimedia) IP Service provider
network. network.
skipping to change at page 6, line 13 skipping to change at page 6, line 13
where I is the Initiating peer and R is the Receiving peer. where I is the Initiating peer and R is the Receiving peer.
+------+ +------+
| DNS, | | DNS, |
| Db, | | Db, |
| etc | | etc |
------- +------+ ------- ------- +------+ -------
/ \ | | / \ / \ | | / \
| LF---+ +---LF | | LF---+ +---LF |
| | | | | | | |
| PF----------PF |
| | | |
| SIP SF----------SF SIP | | SIP SF----------SF SIP |
| Service | | Service | | Service | | Service |
|Provider MF----------MF Provider| |Provider MF----------MF Provider|
| I | | R | | I | | R |
| | | | | | | |
| | | | | | | |
\ / \ / \ / \ /
------- ------- ------- -------
Figure 2: Reference SPEERMINT Architecture Figure 2: Reference SPEERMINT Architecture
The procedures presented in Chapter 3 are implemented by a set of The procedures presented in Chapter 3 are implemented by a set of
peering functions: peering functions:
o Location Function (LF): Purpose is to develop call routing data o Location Function (LF): Purpose is to develop call routing data
(CRD) by discovering the Signaling Function (SF), Policy Function (CRD) by discovering the Signaling Function (SF), , and end
(PF), and end user's reachable host (IP address and port). user's reachable host (IP address and port).
o Policy Function (PF): Purpose is to perform authentication and to
exchange policy parameters to be used by the SF. The data acquired
through the policy function can provide input to the LF, SF or MF
functions. Therefore the policy function can happen multiple times
(through multiple methods) during the procedures used to establish
a call.
o Signaling Function (SF): Purpose is to perform routing of SIP o Signaling Function (SF): Purpose is to perform routing of SIP
messages, to optionally perform termination and re-initiation of messages, to optionally perform termination and re-initiation of
call, to optionally implement security and policies on SIP call, to optionally implement security and policies on SIP
messages, and to assist in discovery/exchange of parameters to be messages, and to assist in discovery/exchange of parameters to be
used by the Media Function (MF). used by the Media Function (MF).
o Media Function (MF): Purpose is to perform media related function o Media Function (MF): Purpose is to perform media related function
such as media transcoding and media security implementation such as media transcoding and media security implementation
between two SIP providers. between two SIP providers.
skipping to change at page 7, line 16 skipping to change at page 7, line 8
This section describes the peering functions in more detail and This section describes the peering functions in more detail and
provides some examples on the role they would play in a SIP call in a provides some examples on the role they would play in a SIP call in a
Layer 5 peering scenario. Layer 5 peering scenario.
Some of the information in the chapter is taken from [14]. Some of the information in the chapter is taken from [14].
5.1. The Location Function (LF) of an Initiating Provider 5.1. The Location Function (LF) of an Initiating Provider
Purpose is to develop call routing data (CRD) [12] by discovering Purpose is to develop call routing data (CRD) [12] by discovering
the Signaling Function (SF), Policy Function (PF), and end user's the Signaling Function (SF), and end user's reachable host (IP
reachable host (IP address and host). The LF of an Initiating address and host). The LF of an Initiating provider analyzes target
provider analyzes target address and discovers the next hop address and discovers the next hop signaling function (SF) in a
signaling function (SF) in a peering relationship using DNS, SIP peering relationship using DNS, SIP Redirect Server, or a functional
Redirect Server, or a functional equivalent database. equivalent database.
5.1.1. Target address analysis 5.1.1. Target address analysis
When the initiating provider receives a request to communicate, the When the initiating provider receives a request to communicate, the
initiating provider analyzes the target state data to determine initiating provider analyzes the target state data to determine
whether the call needs to be terminated internal or external to its whether the call needs to be terminated internal or external to its
network. The analysis method is internal to the provider's policy; network. The analysis method is internal to the provider's policy;
thus, outside the scope of SPEERMINT. Note that the peer is free to thus, outside the scope of SPEERMINT. Note that the peer is free to
consult any manner of private data sources to make this consult any manner of private data sources to make this
determination. determination.
skipping to change at page 9, line 4 skipping to change at page 8, line 43
PSTN gateway termination by prior arrangement using a routing table. PSTN gateway termination by prior arrangement using a routing table.
If so, the initiating peer rewrites the Request-URI to address the If so, the initiating peer rewrites the Request-URI to address the
gateway resource in the target provider's domain and MAY forward the gateway resource in the target provider's domain and MAY forward the
request on to that provider using the procedures described in the request on to that provider using the procedures described in the
remainder of these steps. remainder of these steps.
5.1.5. SIP DNS Resolution 5.1.5. SIP DNS Resolution
Once a sip: or sips: in an external domain is selected as the target, Once a sip: or sips: in an external domain is selected as the target,
the initiating peer uses the procedures described in [4] Section 4. the initiating peer uses the procedures described in [4] Section 4.
To summarize the RFC 3263 procedure: unless these are explicitly To summarize the RFC 3263 procedure: unless these are explicitly
encoded in the target URI, a transport is chosen using NAPTR records, encoded in the target URI, a transport is chosen using NAPTR records,
a port is chosen using SRV records, and an address is chosen using A a port is chosen using SRV records, and an address is chosen using A
or AAAA records. Note that these are queries of records in the or AAAA records. Note that these are queries of records in the
global DNS. global DNS.
It is worth mentioning that the PF can override the default RFC 3263
procedure. That may be based on learned routes (via SUBSCRIBE), or
federation announcements.
5.1.6. SIP Redirect Server 5.1.6. SIP Redirect Server
A SIP Redirect Server may help in resolving current address of a A SIP Redirect Server may help in resolving current address of a
mobile target address. mobile target address.
5.2. The Location Function (LF) of a Receiving Provider 5.2. The Location Function (LF) of a Receiving Provider
5.2.1. Publish ENUM records 5.2.1. Publish ENUM records
The receiving peer SHOULD participate by publishing "E2U+sip" and The receiving peer SHOULD participate by publishing "E2U+sip" and
skipping to change at page 9, line 38 skipping to change at page 9, line 28
accept traffic from specific initiating peers, it MAY still reject accept traffic from specific initiating peers, it MAY still reject
requests on a case-by-case basis. requests on a case-by-case basis.
5.2.2. Publish SIP DNS records 5.2.2. Publish SIP DNS records
To receive peer requests, the receiving peer MUST insure that it To receive peer requests, the receiving peer MUST insure that it
publishes appropriate NAPTR, SRV, and address (A and/or AAAA) records publishes appropriate NAPTR, SRV, and address (A and/or AAAA) records
in the global DNS that resolve an appropriate transport, port, and in the global DNS that resolve an appropriate transport, port, and
address to a relevant SIP server. address to a relevant SIP server.
5.3. Policy Function (PF) 5.2.3. TLS
The purpose of policy function is to perform authentication and to
exchange peering policy capabilities to be used by the signaling
function. The policy function can happen multiple times (through
multiple methods) during the procedures used to establish a call and
the data acquired as a result can provide input to the LF, SF or MF
functions.
Policy data can come through DNS NAPTR resolution as shown in [18]
and/or a SIP peering event package [22].
The policy capabilities should be specified through well defined XML
schemas. These policies define the capabilities of each peer and its
devices used for peering. For example, the following capabilities
could be exchanged through the policy function:
o Adjacency (Next hop network attributes)
o If there are many adjacent proxies to use, the choice could be
based on:
. Location of the proxy
. Maximum number of calls per second (CPS)
. Maximum number of established calls
. Maximum allowed bandwidth (KBS)
o Path Discovery (Domains that are NOT adjacent)
o What are the paths to the destination domain that can:
. Guarantee quality
. Participate in Guarantee's for Trust
. Are these paths available?
o Adjacency and Path Congestion detection/avoidance
o Inflow Traffic Restriction (not call-by-call)
o For maintenance actions
o For congestion management
o How can a carrier prevent upstream networks from submitting
calls for certain destinations in overload
The authentication policy function can be implemented by TLS (as
described in (5.3.1), IPSec or any other method that meet the
security needs to a specific deployment.
Editor's Note: This section will be updated based on the progress on
the SPEERMINT policy document.
5.3.1. TLS
Once a transport, port, and address are found, the initiating peer Once a transport, port, and address are found, the initiating peer
will open or find a reusable TLS connection to the peer. The will open or find a reusable TLS connection to the peer. The
initiating provider should verify the server certificate which should initiating provider should verify the server certificate which should
be rooted in a well-known certificate authority. The initiating be rooted in a well-known certificate authority. The initiating
provider should be prepared to provide a TLS client certificate upon provider should be prepared to provide a TLS client certificate upon
request during the TLS handshake. The client certificate should request during the TLS handshake. The client certificate should
contain a DNS or URI choice type in the subject AltName which contain a DNS or URI choice type in the subject AltName which
corresponds to the domain asserted in the host production of the From corresponds to the domain asserted in the host production of the From
header URI. The certificate should be valid and rooted in a well- header URI. The certificate should be valid and rooted in a well-
known certificate authority. Note that the client certificate MAY known certificate authority. Note that the client certificate MAY
contain a list of entries in the subjectAltName, only one of which contain a list of entries in the subjectAltName, only one of which
has to match the domain in the From header URI. has to match the domain in the From header URI.
When the receiving peer receives a TLS client hello, it responds with When the receiving peer receives a TLS client hello, it responds with
its certificate. The receiving peer certificate SHOULD be valid and its certificate. The receiving peer certificate SHOULD be valid and
rooted in a well-known certificate authority. The receiving peer rooted in a well-known certificate authority. The receiving peer
should request and verify the client certificate during the TLS should request and verify the client certificate during the TLS
handshake. handshake.
5.3.2. IPSec 5.2.4. IPSec
Editor's Note: will be described later. Editor's Note: will be described later.
5.3.3. Subscribe Notify 5.2.5. Subscribe Notify
Policy function may also be optionally implemented by dynamic Policy function may also be optionally implemented by dynamic
subscribe, notify, and exchange of policy information and feature subscribe, notify, and exchange of policy information and feature
information among providers [22]. information among providers [22].
5.4. Signaling Function (SF) 5.3. Signaling Function (SF)
The purpose of signaling function is to perform routing of SIP The purpose of signaling function is to perform routing of SIP
messages, to optionally perform termination and re-initiation of a messages, to optionally perform termination and re-initiation of a
call, to optionally implement security and policies on SIP messages, call, to optionally implement security and policies on SIP messages,
and to assist in discovery/exchange of parameters to be used by the and to assist in discovery/exchange of parameters to be used by the
Media Function (MF). Media Function (MF).
The routing of SIP messages are performed by SIP proxies. The The routing of SIP messages are performed by SIP proxies. The
optional termination and re-initiation of calls are performed by optional termination and re-initiation of calls are performed by
B2BUA. B2BUA.
skipping to change at page 12, line 11 skipping to change at page 10, line 34
Admission Control, SIP Denial of Service protection, SIP Topology Admission Control, SIP Denial of Service protection, SIP Topology
Hiding, SIP header normalization, and SIP security, privacy and Hiding, SIP header normalization, and SIP security, privacy and
encryption. encryption.
The signaling function can also process SDP payloads for media The signaling function can also process SDP payloads for media
information such as media type, bandwidth, and type of codec; then, information such as media type, bandwidth, and type of codec; then,
communicate this information to the media function. Signaling communicate this information to the media function. Signaling
function may optionally communicate with network layer to pass Layer function may optionally communicate with network layer to pass Layer
3 related policies [10] 3 related policies [10]
5.5. Media Function (MF) 5.4. Media Function (MF)
Examples of the media function is to transform voice payload from one Examples of the media function is to transform voice payload from one
coding (e.g., G.711) to another (e.g., EvRC), media relaying, media coding (e.g., G.711) to another (e.g., EvRC), media relaying, media
security, privacy, and encryption. security, privacy, and encryption.
Editor's Note: This section will be further updated. Editor's Note: This section will be further updated.
5.5. Policy Considerations
In the context of the SPEERMINT working group when two Layer 5
devices (e.g., SIP Proxies) peer, there is a need to exchange peering
policy information. There are specifications in progress in the
SIPPING working group to define policy exchange between an UA and a
domain [23] and providing profile data to SIP user agents [24] These
considerations borrow from both.
Following the terminology introduced in [12], this package uses the
terms Peering Session-Independent and Session-Specific policies in
the following context.
o Peering Session-Independent policies include Diffserv Marking,
Policing, Session Admission Control, domain reachabilities,
amongst others. The time period between Peering Session-
Independent policy changes is much greater than the time it takes
to establish a call.
o Peering Session-Specific polices includes supported
connection/call rate, total number of connections/calls available,
current utilization, amongst others. Peering Session-specific
policies can change within the time it takes to establish a call.
These policies can be Peer dependent or independent, creating the
following peering policy tree definition:
Peer Independent
Session dependent
Session independent
Peer Dependent
Session dependent
Session independent
6. Call Control and Media Control Deployment Options 6. Call Control and Media Control Deployment Options
The peering functions can either be deployed along the following two The peering functions can either be deployed along the following two
dimensions depending upon how the signaling function and the media dimensions depending upon how the signaling function and the media
function along with IP functions are implemented: function along with IP functions are implemented:
Composed or Decomposed: Addresses the question whether the media Composed or Decomposed: Addresses the question whether the media
paths must flow through the same physical and geographic nodes as the paths must flow through the same physical and geographic nodes as the
call signaling, call signaling,
skipping to change at page 13, line 47 skipping to change at page 12, line 47
This model allows the implementation of M:N model where one SF is This model allows the implementation of M:N model where one SF is
associated with multiple peering MF and one peering MF is associated associated with multiple peering MF and one peering MF is associated
with multiple peering proxies. Generally, a vertical protocol with multiple peering proxies. Generally, a vertical protocol
associates the relationship between a SF and a MF. This architecture associates the relationship between a SF and a MF. This architecture
reduces the potential of single point failure. This architecture, reduces the potential of single point failure. This architecture,
allows separation of the policy decision point and the policy allows separation of the policy decision point and the policy
enforcement point. An example of disadvantages is the scaling enforcement point. An example of disadvantages is the scaling
complexity because of the M:N relationship and latency due to the complexity because of the M:N relationship and latency due to the
vertical control messages between entities. vertical control messages between entities.
7. Security Considerations 7. Address space considerations
Peering must occur in a common address space, which is defined by the
federation, which may be entirely on the public Internet, or some
private address space. The origination or termination networks may or
may not entirely be in that same address space. If they are not,
then a translation (NAT) may be needed before the signaling or media
is presented to the federation. The only requirement is that all
entities across the peering interface are reachable.
8. Security Considerations
In all cases, cryptographic-based security should be maintained as an In all cases, cryptographic-based security should be maintained as an
optional requirement between peering providers conditioned on the optional requirement between peering providers conditioned on the
presence or absence of underlying physical security of peer presence or absence of underlying physical security of peer
connections, e.g. within the same secure physical building. connections, e.g. within the same secure physical building.
In order to maintain a consistent approach, unique and specialized In order to maintain a consistent approach, unique and specialized
security requirements common for the majority of peering security requirements common for the majority of peering
relationships, should be standardized within the IETF. These relationships, should be standardized within the IETF. These
standardized methods may enable capabilities such as dynamic peering standardized methods may enable capabilities such as dynamic peering
relationships across publicly maintained interconnections. relationships across publicly maintained interconnections.
TODO: Address RFC-3552 BCP items. TODO: Address RFC-3552 BCP items.
8. IANA Considerations 9. IANA Considerations
There are no IANA considerations at this time. There are no IANA considerations at this time.
9. Acknowledgments 10. Acknowledgments
The working group thanks Sohel Khan for his initial architecture The working group thanks Sohel Khan for his initial architecture
draft that helped to initiate work on this draft. draft that helped to initiate work on this draft.
A significant portion of this draft is taken from [14] with A significant portion of this draft is taken from [14] with
permission from the author R. Mahy. The other important contributor permission from the author R. Mahy. The other important contributor
is Otmar Lendl. is Otmar Lendl.
Author's Addresses Author's Addresses
skipping to change at page 15, line 43 skipping to change at page 14, line 43
USA USA
Email: rpenno@juniper.net Email: rpenno@juniper.net
Adam Uzelac Adam Uzelac
Global Crossing Global Crossing
1120 Pittsford Victor Road 1120 Pittsford Victor Road
PITTSFORD, NY 14534 PITTSFORD, NY 14534
USA USA
Email: adam.uzelac@globalcrossing.com Email: adam.uzelac@globalcrossing.com
10. References 11. References
10.1. Normative References 11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Mealling, M. and R. Daniel, "The Naming Authority Pointer [2] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 2000. (NAPTR) DNS Resource Record", RFC 2915, September 2000.
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
skipping to change at page 16, line 40 skipping to change at page 15, line 40
[9] Peterson, J., "Telephone Number Mapping (ENUM) Service [9] Peterson, J., "Telephone Number Mapping (ENUM) Service
Registration for Presence Services", RFC 3953, January 2005. Registration for Presence Services", RFC 3953, January 2005.
[10] ETSI TS 102 333: " Telecommunications and Internet converged [10] ETSI TS 102 333: " Telecommunications and Internet converged
Services and Protocols for Advanced Networking (TISPAN); Gate Services and Protocols for Advanced Networking (TISPAN); Gate
control protocol". control protocol".
[11] Peterson, J., "enumservice registration for Session Initiation [11] Peterson, J., "enumservice registration for Session Initiation
Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004. Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.
10.2. Informative References 11.2. Informative References
[12] Meyer, D., "SPEERMINT Terminology", draft-ietf-speermint- [12] Meyer, D., "SPEERMINT Terminology", draft-ietf-speermint-
terminology-04 (work in progress), May 2006. terminology-04 (work in progress), May 2006.
[13] Mule, J-F., "SPEERMINT Requirements for SIP-based VoIP [13] Mule, J-F., "SPEERMINT Requirements for SIP-based VoIP
Interconnection", draft-ietf-speermint-requirements-00.txt, Interconnection", draft-ietf-speermint-requirements-00.txt,
June 2006. June 2006.
[14] Mahy, R., "A Minimalist Approach to Direct Peering", draft- [14] Mahy, R., "A Minimalist Approach to Direct Peering", draft-
mahy-speermint-direct-peering-00.txt, June 19, 2006. mahy-speermint-direct-peering-00.txt, June 19, 2006.
skipping to change at page 17, line 37 skipping to change at page 16, line 37
progress), March 2006. progress), March 2006.
[21] Livingood, J. and R. Shockey, "IANA Registration for an [21] Livingood, J. and R. Shockey, "IANA Registration for an
Enumservice Containing PSTN Signaling Information", draft-ietf- Enumservice Containing PSTN Signaling Information", draft-ietf-
enum-pstn-04 (work in progress), May 2006. enum-pstn-04 (work in progress), May 2006.
[22] Penno, R., Malas D., and Melampy, P., "A Session Initiation [22] Penno, R., Malas D., and Melampy, P., "A Session Initiation
Protocol (SIP) Event package for Peering", draft-penno-sipping- Protocol (SIP) Event package for Peering", draft-penno-sipping-
peering-package-00 (work in progress), September 2006. peering-package-00 (work in progress), September 2006.
[23] Hollander, D., Bray, T., and A. Layman, "Namespaces in XML",
W3C REC REC-xml-names-19990114, January 1999.
[24] Burger, E (Ed.), "A Mechanism for Content Indirection in
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 23 change blocks. 
112 lines changed or deleted 90 lines changed or added

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