Diameter Maintanence and V. Fajardo, Ed.
Extensions (DIME) Toshiba America Research Inc.
Internet-Draft T. Asveren, Ed.
Intended status: Informational Ulticom Inc.
Expires: August 29, 2007 H. Tschofenig
Siemens Networks GmbH & Co KG
G. McGregor
Alcatel-Lucent
J. Loughney
Nokia Research Center
February 25, 2007
Diameter Applications Design Guidelines
draft-fajardo-dime-app-design-guide-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 August 29, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The Diameter Base protocol provides rules on how to extend Diameter
Fajardo, et al. Expires August 29, 2007 [Page 1]
Internet-Draft Diameter Applications Design Guidelines February 2007
and to create new Diameter applications. This is a companion
document to clarify these rules. This document does not intended to
add, remove or change these rules, rather it helps protocol designers
to extend Diameter.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Diameter Application Model . . . . . . . . . . . . . . . . . . 3
4. Rules on Diameter Extensibility . . . . . . . . . . . . . . . 4
4.1. How to Extend Diameter . . . . . . . . . . . . . . . . . . 4
4.2. When to Define New Applications . . . . . . . . . . . . . 5
5. Application Design Considerations . . . . . . . . . . . . . . 6
5.1. Extending Existing Applications . . . . . . . . . . . . . 7
5.2. Accounting Support . . . . . . . . . . . . . . . . . . . . 9
5.3. Generic Diameter Extensions . . . . . . . . . . . . . . . 9
5.4. Use of Application-Id in a Message . . . . . . . . . . . . 10
5.5. Updating an existing Applications . . . . . . . . . . . . 10
5.6. Use of optional AVPs . . . . . . . . . . . . . . . . . . . 11
5.7. Extending Existing Commands . . . . . . . . . . . . . . . 11
5.8. Documenting Command Contents . . . . . . . . . . . . . . . 11
5.9. Use of Application Layer Timers . . . . . . . . . . . . . 11
5.10. Support for Redundancy . . . . . . . . . . . . . . . . . . 11
5.11. AAA Considerations . . . . . . . . . . . . . . . . . . . . 12
5.12. Diameter User Sessions and Server Initiated Requests . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Fajardo, et al. Expires August 29, 2007 [Page 2]
Internet-Draft Diameter Applications Design Guidelines February 2007
1. Introduction
The Diameter Base protocol document defines guidelines on how one
would extend Diameter and create new Diameter applications (see
Section 1.2 of [1]). By themselves, these guidelines are not
necessarily comprehensive enough that one can easily derive good
design decisions from them. The effect of this can be seen in
various attempts to extend Diameter where protocol designers have no
clear answer on whether to even define a new application or not. At
worst, some existing Diameter applications that had purposely been
derived from another existing application resulted in some in-
appropriate design decision in which both applications are no longer
interoperable in certain conditions.
With this in mind, the intent of this document is to influence
ongoing and future Diameter application design by providing the
following content:
o Clarify existing Diameter extensibility rules present in the
Diameter Base Protocol.
o Clarify usage of certain Diameter functionality which are not
explicitly described in the Diameter Base specification.
o Discuss design choices when defining new applications.
o Present tradeoffs of design choices.
Please note that it is not always possible to offer a concise and
unique answer to certain design choices. There is, however, the
believe that at a minimum, this document can be used as a guide to
Diameter extensibility.
2. Terminology
This document reuses the terminology used in [1].
3. Diameter Application Model
As it is currently interpreted and practiced, the Diameter Base
protocol is a two-layer protocol. The lower layer is mainly
responsible for managing connections between neighboring peers and
for message routing. The upper layer is where the Diameter
applications reside. This model falls more inline with a Diameter
node having an application layer and a peer-to-peer delivery layer.
The Diameter Base protocol document completely defines the
Fajardo, et al. Expires August 29, 2007 [Page 3]
Internet-Draft Diameter Applications Design Guidelines February 2007
architecture and behavior of the peer-to-peer delivery layer and then
provides the framework for designing Diameter applications for the
application layer. This framework includes definitions of user
sessions and accounting support (see Section 8 and 9 of [1]) whose
usage is the focus of this document. The remainder of this document
also treats a Diameter node a single instance of a Diameter transport
layer and one or more Diameter applications that uses it.
4. Rules on Diameter Extensibility
4.1. How to Extend Diameter
The current rules for extending Diameter are specified in Section 1.2
of [1]. Diameter can be extended in the following ways:
o Create new AVPs or new AVP values
This implies that you can use this extensibility method in the
following scenario:
Add a new AVP to an existing application to either change its
current semantic
This generally requires that the new AVP is mandatory to be
understood and interpreted by the new semantics. This means
M-bit is set and most likely the new AVP is required to exists
in command ABNF of the modified application. This also implies
that a new application ID would need to be allocated.
Add a new AVP value to an to an existing AVP in an application to
change the applications current semantic
In this case, it is implied that the AVP has the same
properties as the first criteria above where the affected AVP
is mandatory and required to be understood (M-bit set).
Add a new AVP or a new AVP value to an existing AVP without
changing the application semantic
In this case, it is a less disruptive extension and it is
implied that the AVP is optional. This also implies that it
does not require its M-bit to be set. Thus, it will not
require the allocation of a new application ID.
The difficult engineering decision with these rules is when there
is an intersection between any of the criteria above, i.e., when
it's not clear how much influence the new AVP or new AVP values
Fajardo, et al. Expires August 29, 2007 [Page 4]
Internet-Draft Diameter Applications Design Guidelines February 2007
has in the semantics of the existing application to justify
whether a new application has to be defined. Some of the design
considerations regarding this are discussed in Section 5.1.
o Creation of a new application with new command code
The rules are well known in this case. There is no ambiguity
about the decision to create a new application, a new set of
command(s) and/or a new set of AVPs. Though some decisions maybe
clear, designers should also consider aspects of the application
itself. Some of these are described in Section 5. If accounting
is to be used, then models described in Section 5.2 should be
considered.
4.2. When to Define New Applications
It is worthwhile noting that the rules defined in Section 1.2 of [1]
had an assumption that there will be a small number of Diameter
applications that would exist and that these applications mainly
revolve around AAA functionality, i.e., as the next generation
RADIUS. Therefore, the general theme of Diameter extensibility is to
reuse AVPs, AVP values, commands and applications as much as
possible. Despite the current proliferation of Diameter applications
beyond AAA, the theme of reuse is still very relevant and it should
be applied. As a rule, the fundamental reason to create a new
application from an existing application is when there will be major
changes to the application in question. The general criteria for a
major change are, as taken from Section 1.2.3 [1]:
o The changes require that a new AVP will be added to the command
which have its "M" bit set. As described in Section 4.1, this
means that the new AVP has to be understood, interpreted and used
by the application to fall into this criteria. This also means
that AVP introduces a new behavior in the application that changes
it fundamentally. In some cases, however, it can be difficult to
come to a conclusion whether the new AVP should have its M-bit
set.
o The changes require an existing command now has a different number
of round trips to satisfy a request. This means the application
is now required to send multiple messages exchanges in sequence
using the same command. In general, it could also apply to
multiple message exchanges with the same command staggered across
the lifetime of the session. In all cases, this requires a
fundamental change in the behavior of the application.
Fajardo, et al. Expires August 29, 2007 [Page 5]
Internet-Draft Diameter Applications Design Guidelines February 2007
o Requiring the addition of a new command. Typically, the decision
that result in the definition a new command is clear and the
criteria in Section 4.1 can be applied with little ambiguity.
Application designers should also consult Section 5 so as not to
rely too much in defining new commands for every new
functionality.
Note that these rules are explicit taken as is and would result in
the allocation of new application IDs. The allocation of application
IDs specified in Section 1.2.3 of [1] says:
"In order to justify allocation of a new application identifier,
Diameter applications MUST define one Command Code, or add new
mandatory AVPs to the ABNF."
In some cases the above-mentioned rules are not entirely obvious to
apply. For example, an application has been updated and a newer
version of the application now supports some feature that falls into
one of the criteria above. Fundamentally, it is the same application
with some new features but it is now required to be allocated a new
application ID. It can be argued that this is an inappropriate or
inefficient allocation of application IDs since application
identifiers are being used for version control. A discussion about
versioning pitfalls are discussed in detail in Section 5.5.
Other pitfalls arise when there is a tendency by protocol designers
to keep adding optional AVPs to an existing command so they can
circumvent the M-bit criteria. This generally results in
interoperability problems since there will be many interpretations of
the application depending on which optional AVPs are present.
Examples of this problem are discussed in Section 5.6.
5. Application Design Considerations
There are multiple ways of extending Diameter and they fall into the
following categories:
Creation of a completely new Diameter application
More than likely, this means the new application has a use case
where there is no existing Diameter application that provides such
functionality, even partially. Hence, the allocation of command
code(s), AVP(s) and application ID is reasonable. The application
design should also consider the use of accounting, if required.
Fajardo, et al. Expires August 29, 2007 [Page 6]
Internet-Draft Diameter Applications Design Guidelines February 2007
Extending an existing Diameter Application
Typically, this would mean that a new Diameter application reuses
parts of the functionality of the existing application. It could
also mean that an existing application needs to be used in a
different scenario not envisioned by its original designers. In
either case, this has a very broad scope in terms of how much to
reuse or how much changes is introduced and how it will affect
existing functionality.
Diameter Accounting Support
Accounting is a special case Diameter application in the sense
that it is used by other Diameter applications. One problem that
has prevented easy usage of accounting was the lack of clarity in
the Diameter Base protocol. It is further complicated by the fact
that Diameter applications, which supported accounting, had
different interpretations on how to use it. Section 5.2 provides
some models for accounting support and pitfalls that current
Diameter applications have encountered when using accounting.
Generic Diameter Extensions
These generic extensions aim to be available to all applications
by either enhancing the Diameter Base protocol message delivery
layer or the application layer framework. Examples include the
generic support for auditing and redundancy, as described in [2],
and improved duplicate detection, as described in [3]. More
discussion on this topic can be found in Section 5.3.
5.1. Extending Existing Applications
There are several factors to be considered when extending existing
Diameter applications. Some of the major factors include:
Message Routability
It is essential to route the messages to an end point that is able
to process them. If the extension does not add new mandatory
functionality, end points that are able to handle messages for the
extended application can process them as well. New mandatory
functionality manifests itself as an addition of a new command, a
new AVP with M-bit set or change in the application processing.
Although the standard way of routing messages without the
Destination-Host AVP is to make use of the Application-Id and the
Destination-Realm AVP, for certain cases, the value and/or
absence/presence of some other AVP may be utilized as well.
Fajardo, et al. Expires August 29, 2007 [Page 7]
Internet-Draft Diameter Applications Design Guidelines February 2007
Network Maintainability
It is preferable to avoid/limit changes in the network topology
due to extension of an application.
Backward Compatibility
Extensions of an application must not require changes to existing
applications. This should be considered carefully when attempting
to updated an existing application to a newer version (see
Section 5.5).
Namespace Maintainability
Extensions should not require frequent updates to protocol
namespaces, e.g., application identifier name space, which may
lead to confusions and increase the probability for faulty
provisioning. Application designers should avoid justifying the
allocation of application IDs for every change that is made to an
existing application.
Usually it is not possible to extend an application in a way, where
all these factors are satisfactorily addressed. For example if an
extension introduces new mandatory functionality, allocating a new
application identifier would be attractive from message routability
perspective because it would not require non-standard routing
procedures to be introduced. On the other hand, if similar
extensions are expected in the future namespace maintainability may
suffer.
Typically, some of the unclear decisions comes when an existing
application can be reused for a new application by simply adding a
new value to an existing AVP to indicate the new purpose. Since the
change seems small enough, it is not clear that it justifies the
allocation of a new application ID. However, in this case, it is
more preferable to allocate a new application rather than manipulate
the meaning of an existing AVP since this normally leads to complex
application semantics and possible interoperability problems.
In general, following the rules in Section 4.2 should provide a basis
on deciding when to allocate new applications. When it is clear that
a new application is required, application designers should also take
care in defining too many new commands or new AVPs. Existing
commands and AVPs should be reused as much as possible.
Fajardo, et al. Expires August 29, 2007 [Page 8]
Internet-Draft Diameter Applications Design Guidelines February 2007
5.2. Accounting Support
Each application should specify whether it follows the so-called
"coupled" or the "split" accounting model. An indication makes it
easier to decide about the routing of accounting messages by placing
the appropriate Application-Id field in the message header and into
the Acct-Application-Id AVP. Furthermore, accounting servers need to
advertise application identifier for applications choosing split
accounting model in Acct-Application-Id AVP during capability
exchange procedure.
The coupled accounting model relies only on Application-Id in the
message header and Destination-Realm AVP value for routing messages
that do not contain the Destination-Host AVP or if the host specified
by the Destination-host AVP is not an adjacent node. Furthermore,
the coupled accounting model requires Diameter application servers to
process accounting messages in addition to the Diameter application
specific messages.
For the split accounting model accounting messages are routed to a
separate accounting server (by considering the usage of the Acct-
Application-Id AVP). This model is useful when a central accounting
server is used by multiple Diameter applications.
5.3. Generic Diameter Extensions
In general, generic Diameter extensions are either additional
optional AVPs that are used between peer or end points for signaling
non-application specific features. These features deal with
functionality that is either common among applications such as
auditing or used between peers for purposes like redundancy or
congestion control. Extensions can also take the form of new
commands or even new applications with semantics that affect other
applications.
When extensions use optional AVPs, a better design approach is to use
a grouped AVP which encompasses all the functionality of the
extension. The presence/absence of this grouped AVP may be used to
indicate support for this extension. The presence of this AVP in a
message should affect neither the behavior/semantics of the message
nor the application using it. The design of generic extensions
leading to a new application should follow the same rules described
in Section 4 with no particular exceptions.
In certain cases, however, the use of optional AVPs for generic
extensions may not be possible if the applications specification
lacks a catch all AVP rule ("* AVP" rule) in its message ABNF.
Though this maybe rare and more likely due to mistakes in the
Fajardo, et al. Expires August 29, 2007 [Page 9]
Internet-Draft Diameter Applications Design Guidelines February 2007
application specification itself, designers should still take care in
such cases.
5.4. Use of Application-Id in a Message
When designing new applications, note that the application ID carried
in all session level messages must be the application ID of the
application using those messages. This includes the session level
messages defined in base protocol, i.e., RAR/RAA, STR/STA, ASR/ASA
and possibly ACR/ACA in the coupled accounting model, see
Section 5.2. Existing specifications may not adhere to this rule for
historical or other reasons but the model described in Section 3
clearly defines this rule. It is important that this scheme is
followed to avoid possible routing problems for these session level
messages belonging to an application.
Also, as specified in [1], the application ID carried by any
application ID AVP present in the message must match the application
ID present in the header. With regards to Vendor-Specific-
Application-Id AVP, the Vendor-Id AVP in that group normally should
not be used as an additional discriminator. Given that the
application ID space is flat, the Vendor-Specific-Application-Id must
be treated like other application ID AVPs without regard to the
Vendor-Id AVP.
5.5. Updating an existing Applications
Use of a new application identifier should be the preferred way when
the extension introduces completely new and mandatory functionality,
e.g., defines a new command or introduces a new AVP with M-bit set.
If the extension merely extends an existing functionality, e.g.,
introducing a new enumeration value for an existing AVP to avoid
defining a new AVP is usually a better way. If that approach is
used, the extension document should specify what AVP values/presence/
absence should be used to route messages to end points that support
the extension.
An optional AVP can also be used in the same manner to indicate
version differences. If this approach is chosen, it is recommended
that the optional AVP is used specifically to indicate version
information only. It should not have any other purpose.
Enhancements with too many optional AVPs can become unmanageable.
In all cases, care should be taken as not to require changes to the
existing application as it is defined and implemented.
Fajardo, et al. Expires August 29, 2007 [Page 10]
Internet-Draft Diameter Applications Design Guidelines February 2007
5.6. Use of optional AVPs
The use of optional AVPs should be limited to optional application
functionalities or generic Diameter extensions. In general, optional
AVP(s) should not be used to circumvent the proper method of
extending an existing application, i.e., wherein the presence/absence
of the AVP(s) is used to indicate one application over another. As
seen with existing specifications, this leads to unnecessary
interoperability issues. Optional AVPs are meant to carry specific
application data and should not be used for version control when
updating applications (see Section 5.5). In general, the context of
using optional AVPs should be within the boundary of application
functionality only.
5.7. Extending Existing Commands
When adding new AVPs to an existing command, no new mandatory AVPs,
i.e., AVPs in {}, should be introduced to the command ABNF. This
includes also defining an optional AVP with minimum occurrence of 1,
i.e., AVPs in 1*[]. Similarly, when extending an existing command no
existing mandatory AVP should be deleted. This is seen as necessary
to preserve the original message semantics and to maintain integrity
of dictionaries.
5.8. Documenting Command Contents
Care should be taken when listing contents of the commands that are
used for different scenarios with possibly different content. Either
a different ABNF for each scenario or text clarifying the contents
concretely for each scenario should be provided.
5.9. Use of Application Layer Timers
It is common for applications to rely on timers to detect lack of a
response for a previously sent request. Although the Diameter Base
protocol defines a watchdog timer Tw, its use on application level is
discouraged for reasons such as Tw being a hop-to-hop timer, not
being able to control Tw provisioning in the whole message path, Tw
timer value being common for all applications and restrictions on the
provisioning limits for Tw. Applications should define application
layer timers to guard against non-receipt of responses.
5.10. Support for Redundancy
Session state information is the primary data necessary for backup/
recovering endpoints to continue processing for an previously
existing session. Carrying enough information in the messages to
reconstruct session state facilitates redundant implementations and
Fajardo, et al. Expires August 29, 2007 [Page 11]
Internet-Draft Diameter Applications Design Guidelines February 2007
is encouraged.
5.11. AAA Considerations
With the model stated in Section 3, it becomes more natural to
segregate one Diameter application from another. In this case, the
following considerations apply when adding new AAA functionality.
Distributed Application Servers
AAA services provided to a user generally require multiple
different services each in different Diameter applications. Each
of these services these needs to be associated with that user,
e.g., authentication, authorization, accounting, MIPv6
bootstrapping, Quality of Service, Packet Filtering, etc. With
the ability of the Diameter transport layer to route messages to
different destinations or application server on a per-application
basis, designers should take into account how such association can
be accomplished.
One example is that of the authentication being done is on a
separate server from authorization. As an implication information
about the previous authentication interaction has to be signaled
to be made available to the authorization server to prevent
security problems and assist during the authorization decision.
In general, a distributed architecture offers greater flexibility
but the tradeoff is additional complexity. It is difficult to
achieve a good balance between flexibility and complexity and at
the same time account for all the factors that affects or will
affect an application design. Therefore, designs will typically
require compromises to be built into it.
Scalability
It is given that there would be an increase in the total number of
messages generated by Diameter applications to provide the same
set of AAA services that Diameters' predecessor RADIUS generates.
In RADIUS, the addition an of AVPs in a RADIUS message is
sufficient to declare support for a new function. Since Diameter
traffic is greater compared to RADIUS for the same set of service,
care should be taken if scalability is going to be factor in the
deployment of a specific Diameter application.
The increased traffic generated by the Diameter applications is
not a fault of the Diameter design but to accommodate features,
such as reliability. From an application design standpoint, one
should at least consider the number of messages exchanges
Fajardo, et al. Expires August 29, 2007 [Page 12]
Internet-Draft Diameter Applications Design Guidelines February 2007
necessary when designing the application as well as load and
deployment scenarios.
5.12. Diameter User Sessions and Server Initiated Requests
This section briefly discusses which diameter sessions (see Section 8
[1]) to use when an application requires a server entity to transmit
request to a client entity. Note that a server or client entity is a
function of the application and not necessarily synonymous to a
Diameter client or server session. As defined in the Diameter Base
protocol document, only Diameter client sessions can send requests
towards a Diameter server session. To allow a server entity to send
requests towards a client entity, the server entity can create
Diameter client sessions and the client entity can create a
corresponding Diameter server sessions.
6. IANA Considerations
This document does not require actions by IANA.
7. Security Considerations
This document does provides guidelines and considerations for
extending Diameter and Diameter applications. It does not define nor
address security related protocols or schemes.
8. Acknowledgments
We greatly appreciate the insight provided by Diameter implementers
who have highlighted the issues and concerns being addressed by this
document.
9. References
9.1. Normative References
[1] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
9.2. Informative References
[2] Calhoun, P., "Diameter Resource Management Extensions",
draft-calhoun-diameter-res-mgmt-08.txt (work in progress),
March 2001.
Fajardo, et al. Expires August 29, 2007 [Page 13]
Internet-Draft Diameter Applications Design Guidelines February 2007
[3] Asveren, T., "Diameter Duplicate Detection Cons.",
draft-asveren-dime-dupcons-00 (work in progress), August 2006.
Authors' Addresses
Victor Fajardo (editor)
Toshiba America Research Inc.
One Telcordia Drive
Piscataway, NJ 08854
USA
Email: vfajardo@tari.toshiba.com
Tolga Asveren (editor)
Ulticom Inc.
1020 Briggs Road
Mount Laurel, NJ, 08054
USA
Email: asveren@ulticom.com
Hannes Tschofenig
Siemens Networks GmbH & Co KG
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Phone: +49 89 636 40390
Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Glenn McGregor
Alcatel-Lucent
USA
Email: glenn@aaa.lucent.com
John Loughney
Nokia Research Center
USA
Email: john.loughney@nokia.com
Fajardo, et al. Expires August 29, 2007 [Page 14]
Internet-Draft Diameter Applications Design Guidelines February 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).
Fajardo, et al. Expires August 29, 2007 [Page 15]