Network Working Group L. Andersson (Ed)
Internet-Draft IAB
Expires: December 19, 2006 June 17, 2006
Guidelines for Acting as an IETF Liaison to Another Organization
draft-iab-liaison-guidelines-04.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 December 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Whenever the IETF decides to enter into a liaison relationship with
another organization, such as a Standards Development Organization
(SDO), a consortium, or an industrial forum, a liaison manager is
appointed. The procedures used by the IAB to establish and maintain
liaison relationships between the IETF and other organizations are
described in RFC 4052 [RFC4052]. This document expands on the role
of liaison managers and liaison representatives giving guidelines on
their mandate and the expectations, tasks and responsibilities placed
on them.
Andersson (Ed) Expires December 19, 2006 [Page 1]
Internet-Draft Liaison Guidelines June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IETF Liaison Relationships . . . . . . . . . . . . . . . . . . 3
2.1. Related Documents . . . . . . . . . . . . . . . . . . . . 4
2.2. Liaison Managers and Liaison Representatives . . . . . . . 4
2.3. Written Communications . . . . . . . . . . . . . . . . . . 5
2.4. Terminology and Conventions . . . . . . . . . . . . . . . 6
3. Guidelines for Liaison Managers and Representatives . . . . . 6
3.1. Mandate . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Speaking for the IETF . . . . . . . . . . . . . . . . 7
3.2. Expectations . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Responsibilities . . . . . . . . . . . . . . . . . . . . . 9
3.4. Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Relationship Management . . . . . . . . . . . . . . . . . 11
3.5.1. IETF Consensus Process on Liaison Statements . . . . . 11
3.5.2. Incoming Liaison Statements . . . . . . . . . . . . . 11
3.5.3. Ambiguous incoming Liaison Statements . . . . . . . . 11
3.5.4. Liaison Managers Representing Peer Organizations . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Andersson (Ed) Expires December 19, 2006 [Page 2]
Internet-Draft Liaison Guidelines June 2006
1. Introduction
In the course of developing Internet standards, the IETF needs to
communicate extensively with various other peer organizations,
including
o Standards Developing Organizations (SDOs) such as the
Telecommunication Standardization Sector of the International
telecommunications Union (ITU-T) or standardization working groups
of the Institute of Electrical and Electronics Engineers (e.g.,
IEEE 802)
o Consortia such as the World Wide Web Consortium (W3C)
o Industrial forums such as the Global Grid Forum (GGF)
These organizations are usually concerned with developing related
standards and technical specifications, so that from time to time
issues of coordination and mutual interest may arise. To facilitate
communications, the IETF, through the Internet Architecture Board
(IAB), establishes permanent liaison relationships with appropriate
parts of these organizations according to the processes described in
RFC 4052 [RFC4052].
Whenever the IETF decides to enter into a liaison relationship, a
liaison manager and possibly some liaison representatives are
appointed by the IAB to act as a channel between the IETF and the
peer organization, typically in tandem with counterparts appointed by
the peer organization.
Sections 2.2, 2.3 and 3 of RFC 4052 briefly set out the basic
functions of the tasks of liaison managers and representatives. Over
time the number and importance of liaisons have grown, and the
importance of the personal role of IETF liaison managers and
representatives in maintaining effective relationships with peer
organizations has grown concomitantly. This document supplements
[RFC4052] by providing guidelines for liaison managers and liaison
representatives in maintaining communications to peer organizations.
2. IETF Liaison Relationships
A major goal of the IETF is to develop standards for the Internet,
enabling the development of interoperable implementations. In order
to develop Internet standards, it is frequently necessary for the
IETF to communicate with other organizations which develop standards
for other types of networks, for Internet applications or for
technologies that the Internet uses.
Andersson (Ed) Expires December 19, 2006 [Page 3]
Internet-Draft Liaison Guidelines June 2006
In some cases the IETF and peer organizations consider it mutually
beneficial to have a permanent formal relationship with certain rules
governing the relationship. The organizations then enter into a
"liaison relationship". At a high level, both sides agree to
undertake certain responsibilities with respect to each other. The
most basic liaison responsibility is to communicate information as
necessary, and to respond to requests from peer organizations to
which liaisons are maintained.
Decisions on IETF liaison relationships are the responsibility of the
IAB. This includes whether the IETF should have a liaison
relationship with a particular organization or not.
2.1. Related Documents
The IETF liaison process is specified in several documents. RFC 4052
[RFC4052] specifies how the IAB manages the IETF liaison
relationship; RFC 4053 [RFC4053] specifies how liaison statements
should be treated. Organization-specific agreements and documents
may also be generated in some cases, e.g., RFC 3356 [RFC3356]
describes the collaboration between the IETF and ITU-T, RFC 3113
[RFC3113] describes the relationship with The 3rd Generation
Partnership Project (3GPP), and RFC 3131 [RFC3131] describes the one
with The Third Generation Partnership Project 2 (3GPP2).
2.2. Liaison Managers and Liaison Representatives
Whenever the IETF enters into a liaison relationship with another
organization, a liaison manager (often referred to as "the IETF
liaison") is appointed by the IAB. This document expands on the
mandate of and the expectations, tasks and responsibilities placed on
the liaison manager by Section 2.2 of RFC 4052.
In some cases, it may be necessary to have more than one person
handling the liaison relationship with a given organization. For
example, the time commitment required may be too substantial, or the
technical scope of the liaison relationship may be too broad to be
handled by a single individual.
In such cases the IAB may appoint one or more liaison representatives
to supplement the work of the liaison manager by managing different
aspects of the liaison relationship between the IETF and the other
organization.
The value of personal relationships between the IETF liaison manager
and represenatatives and members of the peer organization is central
to the roles. The IAB will be looking for people who have both a
good technical understanding of the work being carried out and
Andersson (Ed) Expires December 19, 2006 [Page 4]
Internet-Draft Liaison Guidelines June 2006
effective personal relationships within the peer organization.
Ongoing face-to-face interactions between the IETF liaisons and
members of the peer organization are seen as critical to the
effective functioning of the role. These interactions should allow
the liaisons to keep the IETF abreast, and preferably ahead, of
matters of mutual interest or potential conflict. Whe the liaison is
working effectively, it should facilitate the IETF and the peer
organization working synergistically and reduce the chance of
overlapping or conflicting standards being created.
2.3. Written Communications
Aside from the personal contacts between liaisons and the peer
organization, extensive communication may occur between the IETF and
the peer organizations through written materials. Much of this
communication is through liaison statements that typically contain
plans, new developments and time schedules of which one party
believes that the other party should be aware.
The liaison manager should be aware of these written communications
and assist both parties to see that appropriate action is taken in
relation to liaison statements passing in both directions.
For example, when a liaison organization, such as ITU-T, needs to
reference material which is under development in the IETF: the final
reference in the peer organization's document needs the permanent
identifier (RFC number) that will be assigned to the Internet Draft
when it is approved and published. To meet the publication schedule
of the peer organization a liaison statement is often sent to the
IETF requesting that an RFC number be assigned within the required
timeframe. In response, the IETF can provide the RFC number or
explain why it is not possible to provide this within the timeframe
requested.
An alternative situation that involves more specific action by the
liaison manage also involves requests for this kind of expedited
action on RFCs. For example, 3GPP/3GPP2 and the Open Mobile Alliance
(OMA) provide the IETF with an updated list of dependencies between
their documents and IETF documents on a monthly basis, indicating
what documents are needed and the required timeframe. In this case
the liaison manager tracks the dependency list and, when necessary,
conveys the request for expedited assignment to the appropriate IETF
Area Director (AD).
Andersson (Ed) Expires December 19, 2006 [Page 5]
Internet-Draft Liaison Guidelines June 2006
2.4. Terminology and Conventions
Terminology relating to IETF liaison procedures is found in
[RFC4052]. Terms defined below are valid for this document only.
Liaison manager
A person appointed to manage an IETF liaison relationship with
another organization.
Liaison representative
A person appointed to manage a certain (sub-)aspect of an IETF
liaison relationship with another organization. Since it is only the
scale of the responsibilities, mandate and tasks that is different,
the rest of this document only explicitly mentions liaison managers.
IETF consensus
RFC 2026 [RFC2026] and RFC 2418 [RFC2418] discuss the IETF consensus
process. In this document the term "IETF consensus" is used to
indicate either consensus of the IETF as an organization, an Area
within IETF or a working group. There the term "IETF consensus"
needs to be interpreted in the context in which it is used.
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].
3. Guidelines for Liaison Managers and Representatives
Since liaison relationships are intended to be mutually beneficial,
the IETF liaison to another organization must act as a bi-directional
communication link between the IETF and the other organization.
Since the liaison manager has been appointed by the IETF, the liaison
manager needs to be responsive to the needs and aims of the IETF.
RFC 4052 lists some of the tasks and expectations relating to liaison
managers and liaison representatives. This document expands on their
mandate, provides more detailed discussion and describes how the role
is executed.
3.1. Mandate
The mandate for IETF liaison managers is strictly limited to
conveying IETF consensus to the liaised organization. The liaison
manager MUST NOT on their own initiative, send liaison statements to
Andersson (Ed) Expires December 19, 2006 [Page 6]
Internet-Draft Liaison Guidelines June 2006
a liaised organization on behalf of IETF, or any of its areas and
working groups. Liaison statements are only sent following the
process specified in [RFC4052]. Liaison statements are only sent on
the initiative of the IETF chair, the IAB chair, IETF Area Directors
or IETF working group chairs.
In Section 3.3 and in Section 3.4, tasks and responsibilities are
listed which enable the IETF to obtain the information to correctly
interact with the liaised organizations and to develop and clearly
communicate IETF consensus.
3.1.1. Speaking for the IETF
The IETF functions based on rough consensus, which means that the
right to speak for the IETF cannot be delegated. The liaison manager
speaks on behalf of the IETF on the subject matter of the liaison,
but only after making sure that the IETF consensus is understood.
Some guidelines for understanding IETF consensus are provided above;
however, the most important requirement is close and detailed
coordination/consultation with the IETF community.
3.2. Expectations
There are certain expectations placed on liaison managers appointed
by the IETF. Examples of these expectations are listed below.
Competences Required
The key competence needed in the liaison manager or representative
role is effective management of the liason process according to
the rules which have been agreed upon. The liaison acts as a
representative of the IETF and not an independent voice with
respect to topics of discussion in the liaison relationship. The
liaison must therefore be careful to distinguish their own views
from documented IETF consensus in his or her dealings with the
peer organization.
To this end, the liaison manager or representative must be able to
communicate effectively with members of the peer organization,
especially in face-to-face situations. This is important both to
communicate the IETF's viewpoint and to gather information about
the issues in the peer organization which the IETF needs to
understand.
In support of the liaison process, a person appointed to act as a
liaison manager or representative on behalf of the IETF is
expected to have a good technical understanding of the key issues
in the subject area, as well as an understanding of the concerns
Andersson (Ed) Expires December 19, 2006 [Page 7]
Internet-Draft Liaison Guidelines June 2006
important to stakeholders in both organizations.
An IETF liaison needs to have knowledge of the IETF's consensus
process in general, as well as the consensus process(es) applying
to the key issues within the liaison relationship.
The liaison must also have a good understanding of the processes
used by the peer organisation involved.
Perspective
Liaison relationships are designed for the mutual benefit of the
organizations participating in the liaison. As such, swift
information flow in both directions is a firm requirement. The
role of an IETF liaison manager is to promote the interests of the
IETF with respect to all topics within the scope of the liaison
relationship. Since the liaison manager "wears an IETF hat", it
is NOT the task of a liaison manager to promote the interests of
the liaised organization within the IETF.
Distance
A liaison may not be able maintain the required perspective if he
or she is closely involved in the outcome of the work in the peer
organization. A conflict of interest might arise if the liaison
is involved in the management of the relevant part of the peer
organization, has a close technical involvement in the work that
is the subject of the liaison or has a close interest in the
outcome of the work in the peer organization through their
employment. When appointing an appropriate person to manage a
liaison relationship, the IAB needs to take into account any
conflicts of interest that the individual being considered might
have. Before a person is appointed to manage a liaison
relationship he or she will be asked to explicitly state any
conflicts of interest. The IAB will not appoint a person to a
liaison manager position if there is a strong conflict of
interest. For example, an individual with an industry or
organizational leadership position in an organization would
typically not be suitable for appointment as an IETF liaison to
that organization.
Commitment and opportunity
A liaison manager needs to be committed to addressing the issues
relevant to the liaison relationship. To handle the job properly,
it is necessary for the liaison be able to allocate sufficient
time to the task.
Andersson (Ed) Expires December 19, 2006 [Page 8]
Internet-Draft Liaison Guidelines June 2006
Timeliness
It is expected that a liaison manger will make the IETF aware of
new developments in the subject area in a timely fashion.
3.3. Responsibilities
The liaison manager and representatives provide information to the
IETF community in order to enable the IETF to make decisions based on
the best possible information regarding the work in the peer
organization. In turn, information communicated by the IETF liaison
to the liaised organization MUST be based on the relevant IETF
consensus. The liaison manager works with the liaised organization
to ensure that communication is clear. As part of this, the liaison
must clearly differentiate their own independent positions from those
which represent IETF consensus.
It is the responsibility of the liaison manager to ensure that the
liaised organization communicates its requirements to the IETF in a
timely fashion and that the IETF consensus is clearly understood.
This is particularly important in situations where the IETF and the
liaised organization differ substantially in their positions. In
this situation the liaison manager needs to facilitate prompt
communication so that the IETF and the liaised organization can stay
in close communication and avoid misunderstandings.
The liaison manager and representatives are responsible for clearly
and correctly communicating the IETF consensus position to the
liaised organization. This includes, when specifically instructed,
to carry any messages from the IETF to the peer organization.
Generally, these communications "represent the IETF", and therefore
due care and consensus must be applied in their construction.
The liaison manager and representatives are responsible for ensuring
that relevant information originating from the liaised organization,
or other information coming to the attention of the liaison, reaches
the correct destination within the IETF, in a timely and effective
way.
3.4. Tasks
Examples of tasks performed by the liaison manager are provided
below. Depending on the nature of liaised organization the task may
vary in frequency and relative importance.
1. Attend relevant meetings and participate in conference calls and
mailing lists within the liaised organization to gather
information relevant to the liaison relationship. Note
Andersson (Ed) Expires December 19, 2006 [Page 9]
Internet-Draft Liaison Guidelines June 2006
developments of interest for onward communication to the IETF.
Communicate the point of view of the IETF consensus to the peer
orgnaization.
2. Communicate information relevant to the liaison relationship to
the relevant part of the IETF either by written reports or
verbally; this may involve update meetings with a team of IETFers
involved in the liaised organization and other interested parties
within the IETF, e.g., working group chairs and ADs.
3. Understand the concerns of both the IETF and the peer
organization, while ensuring that interests of the IETF are
maintained; where there appear to be problems to solve or
conflicts between approaches, work with both parties to encourage
engineers from both orgnizations to collaborate on solving the
problem and facilitate the development of engineering solutions
in the appropriate organization.
4. Prepare reports giving updates on developments in the peer
organization as requested by the IAB or other interested parties
in the IETF. The target for these updates (e.g., the IAB, an AD,
a WG) will typically be identified upon establishment of the
liaison relationship and/or the appointment of the liaison
manager.
5. Oversee delivery of liaison statements addressed to the IETF.
This includes ensuring that liaison statements are delivered to
the appropriate destination within the IETF, as well as
shepherding the timely creation of responses by the IETF.
6. Work with the liaised organization to ensure that the IETF's
liaison statements are appropriately directed and responded to in
a timely fashion. To accomplish this, the liaison needs to build
a contact network.
7. Communicate and coordinate with other IETF liaison managers where
the activities of two or more liaised organizations overlap.
8. Assist with the preparation of IETF liaison statements based on
IETF consensus.
9. From time to time Liaison managers and liaison representatives
will have to report to the IETF on the status of the liaison
relationship. For this purpose they will need to keep track of
outstanding issues on behalf of the IETF. The frequency of the
reports and the recipients of the reports within the IETF will be
decided when the liaison relationship is set up and may be
changed at any time by an IAB decision. IAB or other parties
Andersson (Ed) Expires December 19, 2006 [Page 10]
Internet-Draft Liaison Guidelines June 2006
within the IETF may probe for liaison reports as needed or at
regular intervals.
3.5. Relationship Management
Liaison managers will be involved in activities for which they are
not directly responsible, but that might greatly benefit from their
expertise. Some of these activities are outlined below.
3.5.1. IETF Consensus Process on Liaison Statements
Liaison statements and other messages sent to a liaised organization
should be based on rough consensus within the IETF or one of its
working groups or areas. Though the liaison manager is not
responsible for determining consensus, it is important that the
liaison manager participate in the process and makes his/her
expertise and knowledge available.
How consensus is arrived at may vary according to the circumstances.
Some issues are new and in these cases an open discussion on a
mailing list should be undertaken. For some issues consensus has
already been arrived at or the liaison statement is a mere statement
of facts (e.g., to inform the liaised organization that an IETF Last
Call had started on a document they had previously expressed interest
in) and in these cases the liaison statement can be written and sent
(such as by a working group chair), possibly involving the liaison
manager.
3.5.2. Incoming Liaison Statements
When the IETF receives a liaison statement or other communication
from an organization with which it has an liaison relationship that
includes a request for a response to the communication, the IETF is
committed to providing a timely response. This means that IETF will
respond within the time requested, and provide information as
accurately as possible. This commitment has been one of the key
discussion points in the past, such as within the (g)mpls change
process [I-D.andersson-rtg-gmpls-change].
This commitment does not mean that the IETF will uncritically accept
the content in the incoming liaison statement. To the extent the
liaison contains requirements on IETF technology or protocols they
will be taken into consideration based on their technical merit.
3.5.3. Ambiguous incoming Liaison Statements
Sometimes the IETF, an IETF area or an IETF working group receives
liaison statements from a liaised organization that is sent to the
Andersson (Ed) Expires December 19, 2006 [Page 11]
Internet-Draft Liaison Guidelines June 2006
wrong destination. At other times the liaison statement is sent to
working groups that are not chartered to do the work that the liaison
statement addresses. In some cases it might be the situation that no
working group is chartered to do the work.
In such cases the liaison manager should assist in finding the
appropriate recipient within the IETF that might respond to the
incoming liaison statement. Sometimes this might require that the
intended response is made available for review on one of the IETF
mailing lists.
3.5.4. Liaison Managers Representing Peer Organizations
Liaised organizations may appoint a person to act as a liaison
manager for "their side" of the relationship. This is the person
that will speak authoritatively, within the IETF, on the activities
performed by the other organization. The other organization needs to
make this person known to the IETF. This person might request a slot
on a working group agenda to discuss developments and plans of the
liaised organization.
Opinions expressed by a liaison mangers of other SDOs, other than
reports on work within the liaised organisation, are given equal
weight with opinions expressed by other working group participants.
RFC 3356 [RFC3356] describes this in the context of the relationship
between the IETF and the ITU-T, however the same model is applicable
to all other organizations with which the IETF has a liaison
relationship.
The mandates of liaison managers from other organizations are
recognized by the IETF to the extent needed to understand the
information received from the liaison manager. In all other respects
he/she participates in IETF activities under the same conditions and
rules as any other IETF participant. It is important that the IETF
liaison manager understands the extent to which the peer liaison
manager is mandated or delegated to speak on behalf of the peer
organization, and to inform the relevant part of the IETF if the peer
liaison manager appears to be stepping outside the role or stance
given to him or her by the peer organization.
IETF liaison managers should work to include the liaison manager from
the liaised organization within their contact network, and to
understand the positions being communicated by the peer liaison
manager.
4. Security Considerations
Andersson (Ed) Expires December 19, 2006 [Page 12]
Internet-Draft Liaison Guidelines June 2006
This document does not specify any protocol or "bits on the wire".
However, since interaction with other standards-making organizations
often relates to security, the liaison manager can assist with
security related issues, resulting in improved security for Internet
protocols.
5. IANA considerations
There are no requests to the IANA herein. Note that the liaison
manager very often has to understand and convey questions regarding
IETF namespaces managed by IANA.
6. Acknowledgements
This document was developed as part of a conversation regarding the
requirements on IETF liaison managers and representatives. Several
IAB members have significantly contributed to the document. Also,
the document has been improved thanks to suggestions and review from
Allison Mankin, Dave Meyer and Leslie Daigle.
A special thanks to Bernard Aboba who based on his experience as a
liaison manager has made many useful comments on the subject matter.
Elwyn Davis and Bernard Aboba has both spent time on correcting
language and grammar.
Members of the IAB at the time of approval of this document were:
Bernard Aboba
Loa Andersson
Brian Carpenter
Leslie Daigle
Elwyn Davies
Kevin Fall
Olaf Kolkman
Kurtis Lindqvist
David Meyer
Dave Oran
Eric Rescorla
Dave Thaler
Lixia Zhang
7. References
Andersson (Ed) Expires December 19, 2006 [Page 13]
Internet-Draft Liaison Guidelines June 2006
7.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
[RFC4052] Daigle, L. and Internet Architecture Board, "IAB Processes
for Management of IETF Liaison Relationships", BCP 102,
RFC 4052, April 2005.
7.2. Informative References
[I-D.andersson-rtg-gmpls-change]
Andersson, L., "MPLS and GMPLS Change Process",
draft-andersson-rtg-gmpls-change-02 (work in progress),
December 2005.
[RFC3113] Rosenbrock, K., Sanmugam, R., Bradner, S., and J. Klensin,
"3GPP-IETF Standardization Collaboration", RFC 3113,
June 2001.
[RFC3131] Bradner, S., Calhoun, P., Cuschieri, H., Dennett, S.,
Flynn, G., Lipford, M., and M. McPheters, "3GPP2-IETF
Standardization Collaboration", RFC 3131, June 2001.
[RFC3356] Fishman, G. and S. Bradner, "Internet Engineering Task
Force and International Telecommunication Union -
Telecommunications Standardization Sector Collaboration
Guidelines", RFC 3356, August 2002.
[RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for
Handling Liaison Statements to and from the IETF",
BCP 103, RFC 4053, April 2005.
Andersson (Ed) Expires December 19, 2006 [Page 14]
Internet-Draft Liaison Guidelines June 2006
Author's Address
Loa Andersson
IAB
Email: loa@pi.se
Andersson (Ed) Expires December 19, 2006 [Page 15]
Internet-Draft Liaison Guidelines June 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Andersson (Ed) Expires December 19, 2006 [Page 16]
