Extensible Markup Language (XML) Formats for Representing Resource Lists
RFC 4826
| Document | Type | RFC - Proposed Standard (May 2007) Errata | |
|---|---|---|---|
| Author | Jonathan Rosenberg | ||
| Last updated | 2020-01-21 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Ted Hardie | |
| Send notices to | (None) |
RFC 4826
Routing Area Working Group Bin Liu
Internet-Draft ZTE Inc., ZTE Plaza
Intended status: Informational Yantao Sun
Expires: November 24, 2019 Jing Cheng
Yichen Zhang
Beijing Jiaotong University
Bhumip Khasnabish
ZTE TX Inc.
May 23, 2019
Generic Fault-avoidance Routing Protocol for Data Center Networks
draft-sl-rtgwg-far-dcn-12
Abstract
This draft proposes a generic routing method and protocol for a
regular data center network, named as fault-avoidance routing (FAR)
protocol. FAR protocol provides a generic routing method for all
types of regular topology network architectures that are proposed for
large-scale cloud-based data centers over the past few years. FAR
protocol is well designed to fully leverage the regularity in the
topology and compute its routing table in a simplistic manner. Fat-
tree is taken as an example architecture to illustrate how FAR
protocol can be applied in real operational scenarios.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 24, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bin Liu, et al. Expires November 24, 2019 [Page 1]
Internet-Draft FAR for DCN May 2019
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://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 Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Acronyms & Definitions . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3.1. The Impact of Large-scale Networks on Route Calculation . 5
3.2. Dilemma of conventional routing methods in a large-scale
network with giant number nodes of routers . . . . . . . 6
3.3. Network Addressing Issues . . . . . . . . . . . . . . . . 8
3.4. Big Routing Table Issues . . . . . . . . . . . . . . . . 8
3.5. Adaptivity Issues for Routing Algorithms . . . . . . . . 9
3.6. Virtual Machine Migration Issues . . . . . . . . . . . . 9
4. The FAR Framework . . . . . . . . . . . . . . . . . . . . . . 9
5. Data Format . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Data Tables . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 13
6. FAR Modules . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Neighbor and Link Detection Module(M1) . . . . . . . . . 17
6.2. Device Learning Module(M2) . . . . . . . . . . . . . . . 17
6.3. Invisible Neighbor and Link Failure Inferring Module(M3) 18
6.4. Link Failure Learning Module(M4) . . . . . . . . . . . . 18
6.5. BRT Building Module(M5) . . . . . . . . . . . . . . . . . 18
6.6. NRT Building Module(M6) . . . . . . . . . . . . . . . . . 19
6.7. Routing Table Lookup(M7) . . . . . . . . . . . . . . . . 19
7. How a FAR Router Works . . . . . . . . . . . . . . . . . . . 19
8. Compatible Architecture . . . . . . . . . . . . . . . . . . . 22
9. Application Example . . . . . . . . . . . . . . . . . . . . . 22
9.1. BRT Building Procedure . . . . . . . . . . . . . . . . . 24
9.2. NRT Building Procedure . . . . . . . . . . . . . . . . . 25
9.2.1. Single Link Failure . . . . . . . . . . . . . . . . . 25
9.2.2. A Group of Link Failures . . . . . . . . . . . . . . 26
9.2.3. Node Failures . . . . . . . . . . . . . . . . . . . . 27
9.3. Routing Procedure . . . . . . . . . . . . . . . . . . . . 27
9.4. FAR's Performance in Large-scale Networks . . . . . . . . 29
9.4.1. The number of control messages required by FAR . . . 29
9.4.2. The Calculating Time of Routing Tables . . . . . . . 29
9.4.3. The Size of Routing Tables . . . . . . . . . . . . . 30
Bin Liu, et al. Expires November 24, 2019 [Page 2]
Internet-Draft FAR for DCN May 2019
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 30
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
In recent years, with the rapid development of cloud computing
technologies, the widely deployed cloud services, such as Amazon EC2
and Google search, bring about huge challenges to data center
networking (DCN). Today's cloud-based data centers (DCs) require
large-scale networks with larger internal bandwidth and smaller
transfer delay. However, conventional networks cannot meet such
requirements due to limitations in their network architecture. In
order to satisfy the requirements of cloud computing services, many
new network architectures have been proposed for data centers, such
as Fat-tree, MatrixDCN, and BCube. These new architectures can
support non-blocking large-scale datacenter networks with more than
tens of thousands of physical servers.
All of these architectures have regular topologies, which are common
features. The regular topology refers to the network topology
structure with obvious regularity and symmetry, which is conducive to
automatic configuration of the network, such as the Fattree network.
In a regular topology, each network node such as a switch or router
can be addressed by its location and through a node's address, the
node's connections to its neighbors in a network can be determined,
and furthermore, the route to the node from other nodes in the
network can be determined. So nodes can compute route entries
without learning topology.
This draft proposes a generic routing method and protocol, fault-
avoidance routing (FAR) protocol, for DCNs. This method leverages
the regularity in the topologies of data center networks to simplify
routing learning and accelerate the query of routing tables. This
routing method has a better fault tolerance and can be applied to any
DCN with a regular topology.
FAR is not a routing protocol to replace generic routing protocols
such as OSPF and IS-IS. It cannot be used in general local networks
whose topological structures are arbitrary, and whose scales are also
not very large. OSPF works very well in such a network. But in a
large-scale network with regular topology, FAR has a better
performance. Compared with OSPF and IS-IS, FAR has shorter time of
network convergence and lower PDU overhead. Furthermore, FAR
requires less computing and storage resources, which let FAR routers
to run at a lower cost of production than the generic routers.
Bin Liu, et al. Expires November 24, 2019 [Page 3]
Internet-Draft FAR for DCN May 2019
In addition, for each type of network architecture, researchers
designed a routing algorithm according to the features of its
topology. Because these routing algorithms are different and lack
compatibility with each other, it is very difficult to develop a
routing protocol for network routers supporting multiple routing
algorithms. FAR has better adaptability than these specified routing
methods.
FAR consists of three components, i.e., link state learning unit,
routing table building unit and routing table querying unit. In the
link state learning unit, FAR exchanges link failures among routers
to establish a consistent knowledge of the entire network. In this
stage, the regularity in topology is exploited to infer failed links
and routers. In the routing table building unit, FAR builds up two
routing tables, i.e., a basic routing table (BRT) and a negative
routing table (NRT), for each router according to the network
topology and link states. In the last component, routers forward
incoming packets by looking up the two routing tables. The matched
entries in BRT minus the matched entries in NRT are the final route
entries to be used to forward an incoming packet.
The remainder of this draft is organized as follows. The problem to
be addressed by FAR is described in Section 3. The framework of FAR
routing protocol is described in Section 4. Section 5 and 6
introduce FAR's data format FAR and modules in detail. Section 7
describe how FAR works by finite state machine (FSM). In Section 8,
we discussed how FAR works with variable network architectures.
Section 9 takes Fat-tree network as an example to illuminate how FAR
works.
1.1. Acronyms & Definitions
DCN - Data Center Network
FAR - Fault-Avoidance Routing
BRT - Basic Routing Table
NRT - Negative Routing Table
NDT - Neighbor Devices Table
ADT - All Devices Table
LFT - Link Failure Table
DA - Device Announcement
Bin Liu, et al. Expires November 24, 2019 [Page 4]
Internet-Draft FAR for DCN May 2019
LFA - Link Failure Announcement
DLR - Device and Link Request
IP - Internet Protocol
UDP - User Datagram Protocol
VM - Virtual Machine
2. Conventions used in this document
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
[RFC2119]. In this document, these words will appear with that
interpretation only when in ALL CAPS. Lower case uses of these words
are not to be interpreted as carrying RFC-2119 significance.
3. Problem Statement
The problem to be addressed by FAR as proposed in this draft is
described in this section. The expansion of Cloud data center
networks has brought significant challenges to the existing routing
technologies. FAR mainly solves a series of routing problems faced
by large-scale data center networks.
3.1. The Impact of Large-scale Networks on Route Calculation
In a large-scale cloud data center network, there may be thousands of
routers. Running OSPF and other routing protocols in such network
will encounter these two challenges: a) Network convergence time
would be too long, which will cause a longer time to elapse for
creating and updating the routes. The response time to network
failures may be excessively long; b) a large number of routing
protocol packets need to be sent. The routing information consumes
too much network bandwidth and CPU resources, which easily leads to
packet loss and makes the problem (a) more prominent.
In order to solve these problems, a common practice is to partition a
large network into some small areas, where the route calculation runs
independently within different areas. However, nowadays the cloud
data centers typically require very large internal bandwidth. To
meet this requirement, a large number of parallel equivalent links
are deployed in a network, such as a Fat-tree network. Partitioning
such a network will affect the utilization of routing algorithm on
equivalent multi-path and reduce internal network bandwidth
requirements.
Bin Liu, et al. Expires November 24, 2019 [Page 5]
Internet-Draft FAR for DCN May 2019
In the FAR routing calculation process, a Basic Routing Table (BRT)
is built on local network topology leveraging the regularity of the
network topologies. In addition to BRT, FAR also builds a Negative
Routing Table (NRT). FAR gradually builds NRT in the process of
learning network link failure information, which does not require
learning a complete network fault information. FAR does not need to
wait for the completion of the network convergence in the process of
building these two tables. Therefore, it avoids the problem of
excessive network convergence overheads in the route calculation
process. In addition, FAR only needs to exchange a small amount of
link change information between routers, and hence consumes less
network bandwidth.
3.2. Dilemma of conventional routing methods in a large-scale network
with giant number nodes of routers
There are many real world scenario where tens of thousands of
nodes(or much more nodes) need to be deployed in a flat area, such as
infiniband routing and switching system, high-performance computer
network, and many IDC networks in China. The similar problems have
been existed long ago. People have solved the problems through
similar solutions, such as the traditional regular topology-based
RFC3619 protocol, the routing protocols of infiniband routing and
switching system, and high-performance computer network routing
protocol.
Infiniband defines a switch-based network to interconnect processing
nodes and the I/O nodes. Infiniband can support very large scale
networks, use the regularity in topology to simplify its routing
algorithm, which is just the same to what we do in FAR.
Why OSPF and other conventional routing methods do not work well in a
large-scale network with giant number nodes of routers?
As everyone knows, the OSPF protocol uses multiple databases, more
topological exchange information (as seen in the following example)
and complicated algorithm. It requires routers to consume more
memory and CPU processing capability. But the processing rate of CPU
on the protocol message per second is very limited. When the network
expands, CPU will quickly approach its processing limits, and at this
time OSPF can not continue to expand the scale of the management.
The SPF algorithm itself does not thoroughly solve these problems.
On the contrary, FAR does not have the convergence time delay and the
additional CPU overheads, which SPF requires. Because in the initial
stage, FAR already knows the regular information of the whole network
topology and does not need to periodically do SPF operation.
One of the examples of "more topological exchange information":
Bin Liu, et al. Expires November 24, 2019 [Page 6]
Internet-Draft FAR for DCN May 2019
In the OSPF protocol, LSA floods every 1800 seconds. Especially in
the larger network, the occupation of CPU and band bandwidth will
soon reach the router's performance bottleneck. In order to reduce
these adverse effects, OSPF introduced the concept of Area, which
still has not solved the problem thoroughly. By dividing the OSPF
Area into several areas, the routers in the same area do not need to
know the topological details outside their area. (In comparison with
FAR, after OSPF introducing the concept of Area, the equivalent paths
cannot be selected in the whole network scope)
OSPF can achieve the following results by Area : 1) Routers only need
to maintain the same link state databases as other routers within the
same Area, without the necessity of maintaining the same link state
database as all routers in the whole OSPF domain. 2) The reduction
of the link state databases means dealing with relatively fewer LSA,
which reduces the CPU consumption of routers; 3) The large number of
LSAs flood only within the same Area. But, its negative effect is
that the smaller number of routers which can be managed in each OSPF
area. On the contrary, because FAR does not have the above
disadvantages, FAR can also manage large-scale network even without
dividing Areas.
The aging time of OSPF is set in order to adapt to routing
transformation and protocol message exchange happened frequently in
the irregular topology. Its negative effect is: when the network
does not change, the LSA needs to be refreshed every 1800 seconds to
reset the aging time. In the regular topology, as the routings are
fixed, it does not need the complex protocol message exchange and
aging rules to reflect the routing changes, as long as LFA mechanism
in the FAR is enough.
Compared with the LSVR protocol, the LSVR protocol has no special
requirements for the network topology structure, however, the FAR
draft is applicable to the regular topology network architecture and
simplifies unnecessary processing. It is a solution proposed to
greatly improve the routing efficiency of the regular network
topology. The FAR solution is more efficient than the general
methods such as LSVR in regular topology.
Therefore, in FAR, we can omit many unnecessary processing and the
packet exchange. The benefits are fast convergence speed and much
larger network scale than other dynamic routing protocol. Now there
are some successful implementations of simplified routings in the
regular topology in the HPC environment. Conclusion: As FAR needs
few routing entries and the topology is regular, the database does
not need to be updated regularly. Without the need for aging, there
is no need for CPU and bandwidth overhead brought by LSA flood every
Bin Liu, et al. Expires November 24, 2019 [Page 7]
Internet-Draft FAR for DCN May 2019gt; and <anyAttribute> elements.
Extensions to this specification MUST specify where their elements
can be placed within the document.
As a result, a document that contains extensions will require
multiple schemas in order to determine its validity: a schema defined
in this document, along with those defined by extensions present in
the document. Because extensions occur by adding new elements and
attributes governed by new schemas, the schemas defined in this
document are fixed and would only be changed by a revision to this
specification. Such a revision, should it take place, would endeavor
to allow documents compliant to the previous schema to remain
compliant to the new one. As a result, the schemas defined here
don't provide explicit schema versions, as this is not expected to be
needed.
Rosenberg Standards Track [Page 23]
RFC 4826 XML Resource Lists May 2007
7. Security Considerations
The information contained in rls-services and resource-lists
documents are particularly sensitive. It represents the principle
set of people with whom a user would like to communicate. As a
result, clients SHOULD use TLS when contacting servers in order to
fetch this information. Note that this does not represent a change
in requirement strength from XCAP.
8. IANA Considerations
There are several IANA considerations associated with this
specification.
8.1. XCAP Application Unique IDs
This section registers two new XCAP Application Unique IDs (AUIDs)
according to the IANA procedures defined in [10].
8.1.1. resource-lists
Name of the AUID: resource-lists
Description: A resource lists application is any application that
needs access to a list of resources, identified by a URI, to which
operations, such as subscriptions, can be applied.
8.1.2. rls-services
Name of the AUID: rls-services
Description: A Resource List Server (RLS) services application is a
Session Initiation Protocol (SIP) application whereby a server
receives SIP SUBSCRIBE requests for resource, and generates
subscriptions towards a resource list.
Rosenberg Standards Track [Page 24]
RFC 4826 XML Resource Lists May 2007
8.2. MIME Type Registrations
This specification requests the registration of two new MIME types
according to the procedures of RFC 4288 [9] and guidelines in RFC
3023 [5].
8.2.1. application/resource-lists+xml
MIME media type name: application
MIME subtype name: resource-lists+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [5].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [5].
Security considerations: See Section 10 of RFC 3023 [5] and
Section 7 of RFC 4826.
Interoperability considerations: none
Published specification: RFC 4826
Applications that use this media type: This document type has been
used to support subscriptions to lists of users [14] for SIP-based
presence [11].
Additional Information:
Magic Number: none
File Extension: .rl
Macintosh file type code: "TEXT"
Personal and email address for further information:
Jonathan Rosenberg, jdrosen@jdrosen.net
Intended usage: COMMON
Author/Change controller: The IETF.
Rosenberg Standards Track [Page 25]
RFC 4826 XML Resource Lists May 2007
8.2.2. application/rls-services+xml
MIME media type name: application
MIME subtype name: rls-services+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [5].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [5].
Security considerations: See Section 10 of RFC 3023 [5] and
Section 7 of RFC 4826.
Interoperability considerations: none
Published specification: RFC 4826
Applications that use this media type: This document type has been
used to support subscriptions to lists of users [14] for SIP-based
presence [11].
Additional Information:
Magic Number: none
File Extension: .rs
Macintosh file type code: "TEXT"
Personal and email address for further information:
Jonathan Rosenberg, jdrosen@jdrosen.net
Intended usage: COMMON
Author/Change controller: The IETF.
Rosenberg Standards Track [Page 26]
RFC 4826 XML Resource Lists May 2007
8.3. URN Sub-Namespace Registrations
This section registers two new XML namespaces, as per the guidelines
in RFC 3688 [8].
8.3.1. urn:ietf:params:xml:ns:resource-lists
URI: The URI for this namespace is
urn:ietf:params:xml:ns:resource-lists.
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Resource Lists Namespace</title>
</head>
<body>
<h1>Namespace for Resource Lists</h1>
<h2>urn:ietf:params:xml:ns:resource-lists</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4826.txt">
RFC4826</a>.</p>
</body>
</html>
END
Rosenberg Standards Track [Page 27]
RFC 4826 XML Resource Lists May 2007
8.3.2. urn:ietf:params:xml:ns:rls-services
URI: The URI for this namespace is
urn:ietf:params:xml:ns:rls-services.
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Resource List Server (RLS) Services Namespace</title>
</head>
<body>
<h1>Namespace for Resource List Server (RLS) Services</h1>
<h2>urn:ietf:params:xml:ns:rls-services</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4826.txt">
RFC4826</a>.</p>
</body>
</html>
END
8.4. Schema Registrations
This section registers two XML schemas per the procedures in [8].
8.4.1. urn:ietf:params:xml:schema:resource-lists
URI: urn:ietf:params:xml:schema:resource-lists
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).
The XML for this schema can be found as the sole content of
Section 3.2.
Rosenberg Standards Track [Page 28]
RFC 4826 XML Resource Lists May 2007
8.4.2. urn:ietf:params:xml:schema:rls-services
URI: urn:ietf:params:xml:schema:rls-services
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).
The XML for this schema can be found as the sole content of
Section 4.2.
9. Acknowledgements
The authors would like to thank Hisham Khartabil, Jari Urpalainen,
and Spencer Dawkins for their comments and input. Thanks to Ted
Hardie for his encouragement and support of this work.
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Paoli, J., Maler, E., Bray, T., and C. Sperberg-McQueen,
"Extensible Markup Language (XML) 1.0 (Second Edition)", World
Wide Web Consortium FirstEdition REC-xml-20001006,
October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
[3] Moats, R., "URN Syntax", RFC 2141, May 1997.
[4] 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.
[5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
Rosenberg Standards Track [Page 29]
RFC 4826 XML Resource Lists May 2007
[9] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[10] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
10.2. Informative References
[11] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[12] Rosenberg, J., "Presence Authorization Rules", Work
in Progress, October 2006.
[13] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[14] Roach, A., Rosenberg, J., and B. Campbell, "A Session
Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, January 2005.
[15] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
August 2004.
Author's Address
Jonathan Rosenberg
Cisco
Edison, NJ
US
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Rosenberg Standards Track [Page 30]
RFC 4826 XML Resource Lists May 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rosenberg Standards Track [Page 31]