Internet DRAFT - draft-alexan-datamod
draft-alexan-datamod
Network Working Group M. Alexander
Internet-Draft WU-Wien
Intended status: Standards Track March 22, 2007
Expires: September 23, 2007
NE/Facilities/Lines/Protocols/Services Modeling
draft-alexan-datamod-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that 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 becomes
aware will be disclosed, in accordance with Section 6 of 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.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 23, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Alexander Expires September 23, 2007 [Page 1]
Internet-Draft Data Modeling March 2007
Abstract
This draft presents a framework document for modeling network
elements (NE), facilities, lines, protocols and services for
substantially easing development and operation of element manager
systems (EMS), network management systems (NMS) and operations
support systems (OSS). The framework is independent of the access
method used, including SNMP, CLI, Netconf, Corba, CMIP, XML-RPC,
etc.) It covers configuration, alarms, current-historical
performance, accounting management and security. The frameworks
builds on and reuses the existing base of MIBs. The documents
presents a light-weight, structured and very simplified framework and
method to data modeling for defining and maintaining meta models,
device etc. models, and device etc. descriptors.
Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 9
5. Independence from Access Methods . . . . . . . . . . . . . . . 10
6. Core Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Secondary Scope . . . . . . . . . . . . . . . . . . . . . . . 13
8. Items NOT in Scope . . . . . . . . . . . . . . . . . . . . . . 14
9. Dependencies-Requirements on Others . . . . . . . . . . . . . 15
10. Process-Cycle Time . . . . . . . . . . . . . . . . . . . . . . 16
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17
12. Security Considerations . . . . . . . . . . . . . . . . . . . 18
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
14. Normative References . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Alexander Expires September 23, 2007 [Page 2]
Internet-Draft Data Modeling March 2007
1. Requirements Notation
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 [RFC2119].
Alexander Expires September 23, 2007 [Page 3]
Internet-Draft Data Modeling March 2007
2. Problem Statement
Network Management (NM) standards have traditionally been focused on
protocols, such as pertaining to configuration management and
discovery. Yet, all areas of Network Management, ranging from
Element Management (EM) to Network Management Systems (NMS) and
Service Management Systems have in common that they critically rely
on underlying data structures describing devices and services being
managed. Network elements (NE) frequently spawn ten thousands of
managed objects, such as for a multiservice switch.
In a common fallacy, programmatic access methods towards an NE such
as operations on attributes via SNMP, CLI or XML-Netconf etc. are
frequently taken as equating to 'network management'. Yet, in order
for a Craft Terminal/EMS/NMS/Service Management System to provide
sensible services to either a GUI operator or a mechanized interface,
the device data of an NE has to be in a structured model. Managed
objects alone - but in rare cases - do not allow to provision a
subscriber, retrieve an alarm, examine a performance metric etc.
From e.g. an NMS viewpoint, they tend to be 'flat' data structures
which need to be put into a defined structure the NMS can understand
so to perform any logical flow of actions on them. That is, a "flat"
device attribute list does not enable an operator or mechanized
interface to manage an NE. Unfortunately, there is little
commonality in data models, respectively managed objects exposed by
NEs to their northbound interfaces. Even worse, the plethora of NMS/
Service Managers each have their own models, leading to the present-
day situation in which a large set of management systems with
different models map to a large set of NEs with - differing models,
both of which ever changing.
The following comparison highlights the problem from an
implementation-effort perspective: It takes an experienced NM person
about a year to understand a medium-complexity carrier device's data
model in its entirety. This familiarity is necessary to build EMSs/
NMSs/Service Management Systems with human-operable GUIs, or machine-
to-machine interfaces for high-level operations (enable a service/
disable a service etc.). To adapt a given NMS's model for only one
NM constituent, such as configuration management, the effort to
initially map and then maintain the NE's to the NMS's data model is
vast. For example, only to cover configuration management of a
single service of a multi-service switch man-years of effort may be
necessary to match the two models.
Yet in contrast, the effort to effect an attribute value change with
SNMP, CLI or XML- Netconf etc. even with little prior knowledge of a
device's functionality, model and behavior is comparatively
minuscule. Setting a given NE attribute via a prompted CLI may take
Alexander Expires September 23, 2007 [Page 4]
Internet-Draft Data Modeling March 2007
an NM-person with only rudimentary knowledge of a given device
minutes; SNMP, depending on the design of the MIB takes longer,
similarly for XML or CORBA etc. Comparing the discrepancy in the
distribution of efforts again: the implementation of one leg of NM
tends to be measured in man-years, the second leg of device access
may range from man-hours to man-weeks. Logically, one might suppose
that standards development would match this distribution.
Traditionally, standardization of access-methods (protocols),
discovery, etc. have received most attention, while the more
heterogeneous data models and data modeling per saw comparatively
less. As there are real possibilities to standardize underlying and
universal commonalities in EMS/NMS/Service Management Systems on the
one side and managed attributes of NEs, protocols, transmission
facilities, lines and services on the other, the two distributions
should be closer aligned. Despite the complexity, it is possible to
identify and define frameworks and meta models of each constituent
and their relation to each other, that would substantially ease the
management of present and future devices, networks and services.
The problem was recognized early, but it took time until technologies
such as markup languages, with their key property of being human
readable, reached the mainstream and ubiquity: "Although some
positive sentiment was expressed for defining a kind of "super SMI"
metalanguage to aid in the definition of a general API, it was not
clear whether the current crop of supporting protocols had sufficient
semantic commonality to be used in this way. The matter remains open
for investigation." [Vince Cerf, RFC 1109]
Alexander Expires September 23, 2007 [Page 5]
Internet-Draft Data Modeling March 2007
3. Use Cases
The framework addresses the following use cases:
o Design and Implementation of EMSs
o Design and Implementation of NMSs
o Design and Implementation of OSSs
o Design and Implementation of Northbound and Southbound Interfaces
EMSs and NMSs are composed of the following main components: access
to NEs, data model and database (a special case being '"MIB-less"
managers with limited modeling and no database), NE-logic to augment
NE methods or define new ones using entities from the NE's exposed
management functionality, application logic, presentation logic,
besides security and system functions at al.
Over the mission-life of an EMS/NMS/OSS/SMS, the component that
consumes a majority of design and development resources is the data
models and their implementation. This applies to single - NE/Service
managers as well as multi NE-type or service managers where the
efforts to initially define and stay current with the respective NE/
service versions increases non-linearly. In some cases point-of-
diminishing returns in multi-NE EMSs, at large due to NE model
differences. They result in more and more device- specific
adaptations and shortcuts to the EMS's own meta model or in the
manager's application logic leading to eventually highly complex and
time-consuming coverage of additional devices and releases.
EMS/NMS are the more usable the more depth the NEs models have. In a
polar extreme, an EMS with a GUI that only offers a human operator a
flat representation of an NE data structure, requires a fair amount
of device/device model/device behavior knowledge on part of this
human operator. If, however, the device model is detailed, an EMS
can e.g. give the human operator a detailed view of the node, being
able to drill down from e.g. a shelf view down to management
information of given protocol running on a given port.
Covering a new NE with e.g. 2000 managed objects based on an
"average" MIB model in an existing EMS with pre-existing related
coverage takes -- depending on the granularity scope -- on the lower-
end several manyears. People doing the device integration have to
build a well-structured, multi-level model of the device in the EMS
so for the EMS to be easy to use for a human operator.
If the device MIB does not adequately convey the NE behavior, the
Alexander Expires September 23, 2007 [Page 6]
Internet-Draft Data Modeling March 2007
facility hierarchy and interrelation of objects and their attributes,
the effort can be substantially higher. The modeler(s) adding
support for a particular device to an EMS may have to (re) model the
equipment's hierarchy and discover its behavior through (lengthy)
series of experiments.
If, in contrast, if there is data model than conveys managed objects
in a normative way and there is a normative namespace/meta model,
then the task becomes substantially easier. If, in addition, the
device model specifies rules and equipment behavior in at least a
semi-normative way, then high-depth support for the particular device
becomes attainable in a fraction of the time than having to go from
plain MIBs.
Similarly, if the task were to build a prompted CLI for the device,
the main effort would be create a definition file that specifies the
CLI hierarchy levels and which operations would be permissible at a
given level -- a formidable task for a large MIB. In contrast, if
there is a namespace/meta model in conjunction with a device data
model that is based on a device class model, then the prompted CLI
(but of the application logic) could to a large extend be derived or
generated from the models.
The same goes for building NMSs, which allow for drilling down into
lines and devices. Yet, NMSs in addition require alarm templates.
Creating alarm templates involves in depth knowledge of the
equipment's behavior, if it has not been properly abstracted.
Creating alarm templates for root-cause analysis involving multiple
devices without pre-existing models is highly time and resource
intensive, possibly involving multiple testing cycles. The proposed
approach for simplifying alarm modeling is: an alarm meta model as
part of the namespace/meta model and an alarm template class model as
part of the device/service/protocol class model.
Not a use case per se is the necessity to uniquely locate equipment,
facilities, lines and their termination points in a network. If a
large number of network elements are involved, then they should be
put into inventory using a schema which incorporates at least a
unique serial, a unique product ID bound to the vendor partnumber,
vendor partnumber, the container equipment (for e.g. cards), the
organization's location classification (such as country/city/
location/room), a unique serial and dating. There needs to be a meta
model for inventory codes and schemata for the individual types of
inventory. The binding between the equipment type categories and the
unique serial could be done based on a normative registry, similar to
the binding between domains and IP address in DNS.
Implementing EMSs/NMSs/CLIs and OSS interfaces are different use
Alexander Expires September 23, 2007 [Page 7]
Internet-Draft Data Modeling March 2007
cases from the creation of device models. Provided a namespace/and
class-type meta models for the device exist, individual vendors can
model their own devices or charter 3rd parties to do so, thereby
allowing a wide range of NMS/OSS software to recognize and manage
their devices. They could be cataloged and put into a repository,
and be bound against the various (vendor dependent) unique serials
from the last paragraph.
Alexander Expires September 23, 2007 [Page 8]
Internet-Draft Data Modeling March 2007
4. Backward Compatibility
MIBs are the most common data structure for internal device data
representation. MIBs are also the most common non-proprietary EMS/
NMS/OSS data representations. The investment in them is vast, hence
it should be preserved. Therefore, backward compatibility with MIBs
SHALL be preserved. Existing MIBs need to be covertable ("import")
into the new set of DM models. This can be done in two ways: (a) the
could be converted into an applicable regular namespace, or (b) into
a free form variant not having the property of a direct line to a
common root. Reverse imports of DM Models into MIBs is not feasible.
MIB conversion does not have to use a generative approach. While it
may be possible to write converters that do not take manual
intervention, in order to produce (b), or a converter that takes
conversion directives embedded or references in the MIB source, this
approach will not yield well-structured models for (a). In order to
convert existing MIBs into the new namespaces and models derived from
the new meta models, partially automated/facilitated/tools supported
manual conversion will be necessary.
Alexander Expires September 23, 2007 [Page 9]
Internet-Draft Data Modeling March 2007
5. Independence from Access Methods
Data Models need to be independent of access methods; Talking to a
device via SNMP, a CLI, Netconf, CORBA, XML-RPC, Batch Config
Transfer, etc. is relatively insignificant in time/resources relative
to designing-implementing-maintaining data models. For example, a
clean data model of a 5000 managed objects device can be talked to in
ANY of the above access methods provides the device has an agent that
exposes the objects.
The ratio of efforts between adapting an EMS/NMS/OSS to talk to a
particular device access method protocol agent to refining an
"average" MIB data model approaches 0 the more complex a devices is.
Alexander Expires September 23, 2007 [Page 10]
Internet-Draft Data Modeling March 2007
6. Core Scope
The core initial focus includes a set of meta models, an initial
network type focus, and service focus. Prior to that, a set of
initial namespaces such as for the ones below is necessary:
o Base equipment hierarchy (rack::power::supplies::shelf::slot::
port::facility::protocols ::services
o Base network types: IP, SDH SONET, ATM, Ethernet
The proposed initial network type focus is: IP-Routing, Ethernet,
SDH/SONET and ATM. The proposed initial services to model are:
barebones SIP, Ethernet VLANs, DiffServ (as a service in the models).
Prerequisite to model network types or services are a set of meta
models shown in Figure 1 below:
The respective layers are explained in the following.
+-----------+------------------------------------------------------+
| Layer VII | Device/Line/Service/Protocol Instance |
+-----------+------------------------------------------------------+
| Layer VI | Device/Line/Service/Protocol Model |
+-----------+------------------------------------------------------+
| Layer V | Device/Line/Service/Protocol Type Meta Model |
| | Derived from class model |
| | Captures behavior, rules |
+-----------+------------------------------------------------------+
| Layer IV | Device/Line/Service/Protocol Class Meta Model |
| | Alarm template class model |
+-----------+------------------------------------------------------+
| Layer III | Namespaces/Meta Model |
| | Derived from existing CLI (option?),from scratch |
| | Constructs etc. |
| | Alarm template meta model |
+-----------+------------------------------------------------------+
| Layer II | Object Model |
| | Prototype methods-operations, data types |
+-----------+------------------------------------------------------+
| Layer I | Access Method |
| | SNMP, CLI, Netconf, CMIP, CORBA, XML-RPC, SOAP .. |
+-----------+-----------------------------------------------------+
Figure 1
Layer I (Access Method) is the protocol used to talk to the NE. As
emphasized before, in the existing status-quo given different data
Alexander Expires September 23, 2007 [Page 11]
Internet-Draft Data Modeling March 2007
models on the device and on the manager, the effort to code the NE
communication with a given protocol is relatively low compared to
refining the respective manager models to match that of the device.
I.e. is the access methods offers sufficient operations to act on a
given managed object, the choice of protocol may be a matter of other
criteria.
Layer II (Object Model) defines the base primitives including
operations that can effect managed objects. A superset of data types
should also be defined in this layer.
Layer III (Namespaces/Meta Model) is (a) concerned with the naming
hierarchies (namespaces) for devices/lines/services and protocols.
For example, part of the base equipment hierarchy from before (rack::
power::supplies::shelf::slot::port::facility) would form a namespace.
The meta model is (b) the prototype model for the higher layer
device/line/service/protocol {Class Meta Model, Type Meta Model,
Model and Instance}. That is, it integrates the object model and the
namespaces and provides a framework model for the higher layers and
defines constructs, language they can utilize. In addition, a meta
model for alarm templates needs to be defined at this layer.
Layer IV (Device/Line/Service/Protocol Class Meta Model) defines meta
models for classes of e.g. devices. An example for classes of
devices are Routers, Ethernet switches, or ATM switches. In the same
layer, alarm template class models (deriving from the alarm template
model on Layer III) need to be defined in order to support root-cause
alarming with a high degree of accuracy.
Layer V (Device/Line/Service/Protocol Class Type Model) extends the
Layer IV Class Meta Model. It defines types of device-line/service/
protocols further. For example, the class routers might branch into
routing switches, pure IP routers, multi-protocol routers, access
routers, edge routers, core routers, etc. Furthermore, the layer
suits defintions of rules and attributes describing the equipment
type's behavior.
Layer VI (Device/Line/Service/Protocol Model) extends the type meta
model with information that is particular to a specific device/line/
service/protocol. For devices, this might be a specific product or
product range in case of an equipment vendor. For services, it might
be a service as deployed by a specific operator.
Layer VII (Device/Line/Service/Protocol Instance) is the actual
instance of the e.g. device model which could be a data model for a
particular vendor's device at a given release level.
Alexander Expires September 23, 2007 [Page 12]
Internet-Draft Data Modeling March 2007
7. Secondary Scope
The secondary scope follows in sequence after the initial scope,
largely because of dependencies. It includes:
o Unique equipment/line locators
o Alarm template registries
o Protection, failover modeling (1+1, 1:n, 1:1, etc.)
o Device/service/protocol models to be defined in the respective
areas/WGs
Unique equipment/line locators have been discussed before as a use
case. As indicated, a schema which incorporates at least a unique
serial, a unique product ID bound to the vendor partnumber, vendor
partnumber, the container equipment, the organization's location
classification (such as country/city/location/room), a unique serial
and dating is necessary. This needs to be in conjunction with a meta
model for inventory codes and schemata for the individual types of
inventory. The binding between the equipment type categories and the
unique serial could be kept in a public database similar to a
registry.
Along the same lines, (a) registry(ies) could be formed for alarm
templates. The secondary scope also includes protection, failover
modeling (1+1, 1:n, 1:1, etc.), which involves a revision of all
metamodels. At the 2nd stage in the effort, it could also be trialed
that individual areas/ working groups define their device/service/
protocol models independently, based on the underlying meta models.
Alexander Expires September 23, 2007 [Page 13]
Internet-Draft Data Modeling March 2007
8. Items NOT in Scope
The data model SHALL NOT include support for Business Support Systems
(BSS) and workflow in general. It is SHALL NOT attempt to cover all
aspects of enterprise and carrier network operations.
Alexander Expires September 23, 2007 [Page 14]
Internet-Draft Data Modeling March 2007
9. Dependencies-Requirements on Others
There are no hard requirements on other efforts. One item, for which
there exists a workaround, would be good to have at the earliest
point though is a Netconf RPC call in-line with the DM object model
(layer II): Netconf 1.0 presently allows for free-form RPC calls.
The DM effort and anybody involved in EMS/NMS/OSS modeling would in
general greatly benefit if devices were to expose more high-level
functions/methods. For example, instead of having to set a large
number of attributes in order to provision a customer on a given
port, a method provision_customer() exposed by the NE, described in
the data model and called by the EMS/NMS/OSS would greatly reduce
complexity. Having a formalized method call which is congruent with
the object model might induce more vendors to expose simplified
methods in their devices.
Elegant integration of management information into protocol
specifications natural gets much easier for protocol designers if
Protocol Class Meta Model is available. Once this is the case,
individual working groups outside the OPS area should be able to
define their own protocol models. Hence, there is a depency from
them on the availability of the meta models.
Alexander Expires September 23, 2007 [Page 15]
Internet-Draft Data Modeling March 2007
10. Process-Cycle Time
The complexity for DM is significantly higher than for many protocols
(e.g. not TCP though). A high initial rate of changes in the
specifications is expected until steady-state is reached. Still,
even in steady-state a comparatively large number of changes per
revision is expected to be occuring in the regular update cycle.
Branches of the models outside the main modeling effort will need to
be allowed. Here, the process might become to fold normative schema
extensions into main as much as possible, allowing of private
branches and allowing specialization without folding.
The target time for the first iteration of the initial scope is one
year. The projected cycle times are:
o Device/Line/Service/Protocol Instances: on discretion of
equipment/nm vendors
o Device/Line/Service/Protocol Model: initial: 6 months, steady-
state 6 months, synced with protocols
o All meta models: initial: 6 months, steady-state 8-9 months
o Object model and data types: initial: 6 months, steady-state 3-4
years or longer
Alexander Expires September 23, 2007 [Page 16]
Internet-Draft Data Modeling March 2007
11. Open Issues
Three issues are not addressed in the present draft: Rules language,
metamodel language and the issue of state model inclusion and
language.
While good data modeling uses overspecification (which facilitates
device modeling), the immediate benefit from the inclusion of a state
model and a state model specification language is lower than for the
core namespaces and metamodels. Once at least the primary scope has
completed, the addition of state model information would aid the EMS/
NMS/OSS modeler in further codifying the equipment's behavior,
facilitating tasks such as deciding on the sequence when to issue
operations and with timing issues in general.
Similarly, rules could be specified in a separate rules language,
which could be added at a later point. The issue is different,
however, for a metamodel language. Having a full language for it
would greatly increase expressivity. Introducing a metamodel
language at a different time than from the onset is not a good option
though.
Alexander Expires September 23, 2007 [Page 17]
Internet-Draft Data Modeling March 2007
12. Security Considerations
The framework goes beyond assuming both the management stations and
the NEs being in secure networks. The Meta models SHALL include both
authentication and multi-level authorization which to be defined in
separate drafts. The frameworks covers both, manging of NEs
providing security functionality, and the authentication and
authorization of the NEs per se.
Alexander Expires September 23, 2007 [Page 18]
Internet-Draft Data Modeling March 2007
13. Acknowledgements
The author would like to acknowledge inputs in the form of drafts,
comments, discussions etc. from the following people: David Appel,
Ray Atarashi, Jan Bergkvis, Andy Bierman, Ron Bonica, Sharon
Chisholm, David Harrington, Robert Natale, Hideki Okita, Amy
Pendleton, Dan Romascanu, Juergen Schoewaelder, Henning Schulzrinne,
Thomas Stolz, Iijima Tomoyuki and Margot Wasserman.
Alexander Expires September 23, 2007 [Page 19]
Internet-Draft Data Modeling March 2007
14. Normative References
[RFC1109] Cerf, V., "Report of the second Ad Hoc Network Management
Review Group", RFC 1109, August 1989.
[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification
of management information for TCP/IP-based internets",
STD 16, RFC 1155, May 1990.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol (SNMP)", STD 15,
RFC 1157, May 1990.
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB definitions",
STD 16, RFC 1212, March 1991.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
Alexander Expires September 23, 2007 [Page 20]
Internet-Draft Data Modeling March 2007
Author's Address
Michael Alexander
Wirtschaftsuniversitaet Wien
Augasse 2-6
Vienna 1090
Austria
Phone: +43.1.31336.4467
Email: malexand@wu-wien.ac.at
Alexander Expires September 23, 2007 [Page 21]
Internet-Draft Data Modeling March 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Alexander Expires September 23, 2007 [Page 22]
