Network Working Group L. Daigle Internet-Draft Editor Expires: June 9, 2005 Internet Architecture Board IAB December 9, 2004 IAB Processes for management of IETF liaison relationships draft-iab-liaison-mgt-03 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 June 9, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document discusses the procedures used by the IAB to establish and maintain liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora. This document also discusses the appointment and responsibilities of IETF liaison managers and representatives, and the expectations of the IAB for organizations with whom liaison relationships are established. Daigle & Internet Architecture Board Expires June 9, 2005 [Page 1] Internet-Draft IAB Liaison Management December 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 June 9, 2005 [Page 2] Internet-Draft IAB Liaison Management December 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. When the liaison relationship is expected to encompass a complex or broad range of activities, more people may be designated to undertake some portions of the communications, coordinated by the liaison manager. 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 to the IETF's technical mandate. Individual participants of the IETF are appointed as liaison managers or representatives to other organizations by the IAB. 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 would like the same done with respect to their own work). Establishing a liaison Daigle & Internet Architecture Board Expires June 9, 2005 [Page 3] Internet-Draft IAB Liaison Management December 2004 relationship can provide the framework for ongoing communications to o prevent inadvertent duplication of effort, without obstructing either organization from pursuing its own mandate; o provide authoritative information of one organization's dependencies on the other's work. Daigle & Internet Architecture Board Expires June 9, 2005 [Page 4] Internet-Draft IAB Liaison Management December 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 applicable businesslike approach, 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. IETF liaison managers should also communicate and coordinate with other liaison managers where concerned technical activities overlap. 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 Daigle & Internet Architecture Board Expires June 9, 2005 [Page 5] Internet-Draft IAB Liaison Management December 2004 consult the IAB's designated liaison manager, and if that does not result in a satisfactory outcome, the IAB itself. 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. In some cases, this may also require communication and coordination with other liaison managers or representatives where concerned technical activities overlap. 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, a more formal communication is appropriate, either as an adjunct to the informal channel, or in its place. In the case of formal communications, 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 June 9, 2005 [Page 6] Internet-Draft IAB Liaison Management December 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. o Communicate and coordinate with other IETF liaison managers and representatives where concerned technical activities overlap. Daigle & Internet Architecture Board Expires June 9, 2005 [Page 7] Internet-Draft IAB Liaison Management December 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 using procedures defined in [6] or its successors. For a liaison statement generated on behalf of an IETF working group, the working group chair(s) must create a statement based on appropriate discussions within the working group to ensure working group consensus for the position(s) presented. The 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. In the case that the liaison statement is not sent by the Area Directors, their agreement must have been obtained in advance and is confirmed 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. In the case that the liaison statement is not sent by the IETF Chair then his or her agreement must be obtained in advance and is confirmed 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. In the case that the liaison statement is not sent by the IAB Chair, then his or her agreement must be obtained in advance and is confirmed by copying the IAB Chair on the message. In cases where prior agreement was not obtained as outlined above, and the designated authority (Area Directory, IETF Chair, or IAB Chair) in fact does not agree with the message, they will follow up as appropriate, including emitting a revised liaison statement if necessary. Clearly, this is a situation best avoided by assuring appropriate agreement in advance of sending the liaison message. Daigle & Internet Architecture Board Expires June 9, 2005 [Page 8] Internet-Draft IAB Liaison Management December 2004 5. Security Considerations The security of the Internet is not threatened by these procedures. Daigle & Internet Architecture Board Expires June 9, 2005 [Page 9] Internet-Draft IAB Liaison Management December 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, Scott Bradner, Scott Brim, Avri Doria, Allison Mankin, Thomas Narten, Russ Housley and Dan Romasanu. Members of the IAB at the time of approval of this document were: Bernard Aboba Harald Alvestrand (IETF chair) Rob Austein Leslie Daigle (IAB chair) Patrik Faltstrom Sally Floyd Jun-ichiro Itojun Hagino Mark Handley Bob Hinden Geoff Huston (IAB Executive Director) Eric Rescorla Pete Resnick Jonathan Rosenberg Daigle & Internet Architecture Board Expires June 9, 2005 [Page 10] Internet-Draft IAB Liaison Management December 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 June 9, 2005 [Page 11] Internet-Draft IAB Liaison Management December 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 June 9, 2005 [Page 12]