Network Working Group L. Daigle
Internet-Draft Editor
Expires: December 30, 2004 Internet Architecture Board
IAB
July 1, 2004
IAB Processes for management of liaison relationships
draft-iab-liaison-mgt-02
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 30, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document discusses the procedures the IAB uses to select
organizations to form and maintain liaison relationships with. It
further discusses the expectations that the IAB has of such
organizations and of the people assigned to manage those
relationships.
Daigle & Internet Architecture Board Expires December 30, 2004 [Page 1]
Internet-Draft IAB Liaison Management July 2004
Table of Contents
1. Liaison Relationships and Personnel . . . . . . . . . . . . . 3
2. Aspects of Liaisons and Liaison Management . . . . . . . . . . 5
2.1 Liaison Relationships . . . . . . . . . . . . . . . . . . 5
2.2 Liaison Manager . . . . . . . . . . . . . . . . . . . . . 5
2.3 Liaison Representatives . . . . . . . . . . . . . . . . . 6
2.4 Liaison Communications . . . . . . . . . . . . . . . . . . 6
3. Summary of IETF Liaison Manager Responsibilities . . . . . . . 7
4. Approval and Transmission of Liaison Statements . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 11
7.2 Informative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
Daigle & Internet Architecture Board Expires December 30, 2004 [Page 2]
Internet-Draft IAB Liaison Management July 2004
1. Liaison Relationships and Personnel
The IETF, as an organization, has the need to engage in direct
communication or joint endeavors with various other formal
organizations. For example, the IETF is one of several Standards
Development Organizations, or SDOs, and all SDOs including the IETF
find it increasingly necessary to communicate and coordinate their
activities involving Internet-related technologies. This is useful
in order to avoid overlap in work efforts and to manage interactions
between their groups. In cases where there is formalization of a
mutual effort to communicate and coordinate activities, these
relationships are generically referred to as "liaison relationships".
In such cases, a person from the IETF is designated to manage a given
liaison relationship; that person is generally called the "IETF
liaison manager" to the other organization. Often, the other
organization will similarly designate their own liaison manager to
the IETF.
This document is chiefly concerned with:
o the establishment and maintenance of liaison relationships, and
o the appointment and responsibilities of IETF liaison managers and
representatives.
The management of other organizations' liaison managers to the IETF,
whether or not in the context of a liaison relationship, is outside
the scope of this document.
The IETF has chartered the Internet Architecture Board to manage
liaison relationships. Consistent with its charter ([2]), the IAB
acts as representative of the interests of the IETF and the Internet
Society in technical liaison relationships with other organizations
concerned with standards and other technical and organizational
issues relevant to the world-wide Internet. Liaison relationships
are kept as informal as possible and must be of demonstrable value in
improving the quality of IETF specifications. Individual members of
the IETF are appointed as liaison managers or representatives to
other organizations by the IAB or IESG as appropriate.
In general, a liaison relationship is most valuable when there are
areas of technical development of mutual interest. For the most
part, SDO's would rather leverage existing work done by other
organizations than recreate it themselves (and they would like their
own standards work used rather than abused/recreated!). Establishing
a liaison relationship can provide the framework for ongoing
communications to
Daigle & Internet Architecture Board Expires December 30, 2004 [Page 3]
Internet-Draft IAB Liaison Management July 2004
o prevent inadvertent duplication of effort, without obstructing
either organization from pursuing its own mandate;
o provide authenticated information of one organization's
dependencies on the other's work.
Daigle & Internet Architecture Board Expires December 30, 2004 [Page 4]
Internet-Draft IAB Liaison Management July 2004
2. Aspects of Liaisons and Liaison Management
2.1 Liaison Relationships
A liaison relationship is set up when it is mutually agreeable and
needed for some specific purpose, in the view of the other
organization, the IAB, and the IETF participants conducting the work.
There is no set process or form for this; the IETF participants and
the peer organization approach the IAB, and after discussion come to
an agreement to form the relationship. In some cases, the intended
scope and guidelines for the collaboration are documented
specifically (e.g., see [3], [4], and [5]).
The IAB's expectation in setting up the relationship is that there
will be a mutual exchange of views and discussion of the best
approach to undertaking new standardization work items. Any work
items resulting for the IETF will be undertaken in the usual IETF
procedures, defined in [1]. The peer organization often has
different organizational structure and different procedures than the
IETF, which will require some flexibility on the part of both
organizations to accommodate. The IAB expects that each organization
will use the relationship carefully, allowing time for the processes
it requests to occur in the other organization and not making
unreasonable demands.
2.2 Liaison Manager
As described above, most work on mutually interesting topics will be
carried out in the usual way within the IETF and the peer
organization. Therefore, most communications will be informal in
nature (e.g., working group, mailing list discussions, etc).
An important function of the liaison manager is to ensure that
communication is maintained, is productive, and is timely. He or she
may use any businesslike approach to that necessary, from private
communications to public communications, and bringing in other
parties as needed. If a communication from a peer organization is
addressed to an inappropriate party, such as being sent to the
working group but not copying the AD or being sent to the wrong
working group, the liaison manager will help redirect or otherwise
augment the communication.
Since the IAB is ultimately responsible for liaison relationships,
anyone who has a problem with a relationship (whether an IETF
participant or a person from the peer organization) should first
consult the IAB's designated liaison manager, and if that does not
result in a satisfactory outcome, the IAB itself.
Daigle & Internet Architecture Board Expires December 30, 2004 [Page 5]
Internet-Draft IAB Liaison Management July 2004
2.3 Liaison Representatives
The liaison manager is, specifically, a representative of the IETF
for the purposes of managing the liaison relationship. There may be
occasion to identify other representatives for the same relationship.
For example, if the area of mutual work is extensive, it might be
appropriate to name several people to be liaison representatives to
different parts of the other organization. Or, it might be
appropriate to name a liaison representative to attend a particular
meeting.
These other liaison representatives are selected by the IAB and work
in conjunction (and close communication) with the liaison manager.
The specific responsibilities of the liaison representative will be
identified at the time of appointment.
2.4 Liaison Communications
Communications between organizations use a variety of formal and
informal channels. The stated preference of the IETF, which is
largely an informal organization, is to use informal channels, as
these have historically worked well to expedite matters. In some
cases, however, more formal communications are appropriate. In such
cases, the established procedures of many organizations use a form
known as a "liaison statement". Procedures for sending, managing,
and responding to liaison statements are discussed in [6].
Daigle & Internet Architecture Board Expires December 30, 2004 [Page 6]
Internet-Draft IAB Liaison Management July 2004
3. Summary of IETF Liaison Manager Responsibilities
While the requirements will certainly vary depending on the nature of
the peer organization and the type of joint work being undertaken,
the general expectations of a liaison manager appointed by the IAB
are as follows:
o Attend relevant meetings of the peer organization as needed and
report back to the appropriate IETF organization any material
updates.
o Carry any messages from the IETF to the peer organization, when
specifically instructed. Generally, these communications
"represent the IETF", and due care (and consensus) must be applied
in their construction.
o Prepare occasional updates -- e.g., to the IAB, an AD, a WG. The
target of these updates will generally be identified upon
appointment.
o Oversee delivery of liaison statements addressed to the IETF,
ensuring that they reach the appropriate destination within the
IETF, and work to ensure that whatever relevant response from the
IETF is created and sent in a timely fashion.
o Work with the other organization to ensure that the IETF's liaison
statements are appropriately directed and responded to in a timely
fashion.
Daigle & Internet Architecture Board Expires December 30, 2004 [Page 7]
Internet-Draft IAB Liaison Management July 2004
4. Approval and Transmission of Liaison Statements
It is important that appropriate leadership review be made of
proposed IETF liaison statements and that those who write such
statements who claim to be speaking on behalf of IETF are truly
representing IETF views.
All outgoing liaison statements will be copied to IETF Secretariat by
the liaison statement page.
For a liaison statement generated on behalf of an IETF working group,
the working group chair(s) must have generated, or must agree with
the sending of the liaison statement, and must advise the Area
Director(s) that the liaison statement has been sent by copying the
appropriate Area Directors on the message.
For a liaison statement generated on behalf of an IETF Area, the Area
Director(s) must have generated or must agree with the sending of the
liaison statement. If the liaison statement is not sent by the Area
Directors then their agreement is indicated by copying the Area
Directors on the message.
For a liaison statement generated on behalf of the IETF as a whole,
the IETF Chair must have generated or must agree with the sending of
the liaison statement. If the liaison statement is not sent by the
IETF Chair then his or her agreement is indicated by copying the IETF
Chair on the message.
For a liaison statement generated by the IAB, the IAB Chair must have
generated or must agree with the sending of the liaison statement.
If the liaison statement is not sent by the IAB Chair, then his or
her agreement is indicated by copying the IAB Chair on the message.
Daigle & Internet Architecture Board Expires December 30, 2004 [Page 8]
Internet-Draft IAB Liaison Management July 2004
5. Security Considerations
The security of the Internet is not threatened by these procedures.
Daigle & Internet Architecture Board Expires December 30, 2004 [Page 9]
Internet-Draft IAB Liaison Management July 2004
6. Acknowledgements
This document was developed as part of a conversation regarding the
management of [6], and the authors of that document contributed
significantly to it. Also, this version of the document has been
improved over its predecessor by several suggestions from Stephen J.
Trowbridge, Peter Saint-Andre, Michael Patton, Bert Wijnen, Fred
Baker and Scott Bradner.
Daigle & Internet Architecture Board Expires December 30, 2004 [Page 10]
Internet-Draft IAB Liaison Management July 2004
7. References
7.1 Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Internet Architecture Board and B. Carpenter, "Charter of the
Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000.
7.2 Informative References
[3] Rosenbrock, K., Sanmugam, R., Bradner, S. and J. Klensin,
"3GPP-IETF Standardization Collaboration", RFC 3113, June 2001.
[4] Bradner, S., Calhoun, P., Cuschieri, H., Dennett, S., Flynn, G.,
Lipford, M. and M. McPheters, "3GPP2-IETF Standardization
Collaboration", RFC 3131, June 2001.
[5] Fishman, G. and S. Bradner, "Internet Engineering Task Force and
International Telecommunication Union - Telecommunications
Standardization Sector Collaboration Guidelines", RFC 3356,
August 2002.
[6] Trowbridge, S., Bradner, S. and F. Baker, "Procedure for
Handling Liaison Statements Between Standards Bodies", June
2004.
Authors' Addresses
Leslie Daigle
Editor
Internet Architecture Board
IAB
EMail: iab@iab.org
Daigle & Internet Architecture Board Expires December 30, 2004 [Page 11]
Internet-Draft IAB Liaison Management July 2004
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 (2004). 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.
Daigle & Internet Architecture Board Expires December 30, 2004 [Page 12]
