Network Working Group Scott Bradner Internet-Draft Harvard University Intended status: BCP Editor Obsoletes: 4052, 4053, 4691 January 22, 2015 Updates: TBD Expires: July 22, 2015 IETF Liaisoning draft-bradner-ietf-liaisoning-01.txt Abstract This document details the processes by which the IETF interacts with peer organizations. In some cases this involves establishing long lasting formal liaison relationships and in other cases the processes are less formal and of shorter duration. The document is designed to be useful in both cases to both IETF participants and to the participants in the other organizations. The document also includes information and pointers to information about the IETF and its operation that may be of use to participants in such peer organizations. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December xx, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Bradner [Page 1] Internet-Draft IETF Liaisoning January 2015 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents TBD 1. Introduction Standards development organizations (SDOs), including the IETF, often find it useful to engage in direct, and often formal, communication with each other to convey information relevant to a standards development effort in a SDO or to coordinate related standards development efforts. For example, as a SDO working in the Internet area, the IETF finds it increasingly necessary to communicate and coordinate their activities involving Internet-related technologies with other SDOs working in the same area. This is useful in order to avoid accidental overlap in work efforts and to manage interactions between their groups. In cases where the mutual effort to communicate and coordinate activities is formalized, these relationships are generically referred to as "liaison relationships". In addition, the IETF interacts with Internet-related organizations that are not directly involved in standards development, such as Internet Corporation for Assigned Names and Numbers (ICANN), the regional Internet registries (RIRs), and the Internet Governance Forum (IGF). These interactions sometimes require that the IETF provide formal communications on a topic but do not require the ongoing coordination that a liaison relationship implies. This document addresses both situations. 2. IETF Background This section provides a very quick overview of the IETF for the benefit of people in other organizations who may not be familiar with the IETF. Some of this information is from the Tao of the IETF [Tao], where a fuller picture of the IETF and how it works can be found. 2.1. IETF Scope The IETF is concerned with all protocols, procedures, and conventions that are used in or by the Internet, whether or not they are part of the TCP/IP protocol suite. [RFC2026] 2.2. IETF History The Internet Engineering Task Force (IETF) was formed in 1986 as an Bradner [Page 2] Internet-Draft IETF Liaisoning January 2015 expansion of US government sponsored activities aimed at the development of Internet related technology. Although the IETF received US Government support until 1997, the IETF became a self- directed activity before 1990. Since then, support for the IETF has come from meeting fees and, since the late 1990s, from the Internet Society. The IETF holds face-to-face meetings three times a year but most of the work of the IETF takes place on mailing lists and occasional working group interim or virtual meetings. Attendance at the face- to-face meetings grew from 21 at the first meeting to over 28 hundred at the height of the Internet boom in 2001. Meeting attendance has been between 1,000 and 1,500 for most of the last decade. 2.3. Internet Society The IETF has no separate legal existence, it has been operating as an organized activity of the Internet Society since 1996. The mission of the Internet Society (www.internetsociety.org/) is "to promote the open development, evolution, and use of the Internet for the benefit of all people throughout the world". The Internet Society sees support for the IETF as a part of fulfilling its mission. 2.4. IETF Participants The IETF does not have any members or membership agreements. Individuals participate in the activities of the IETF on their own behalf and are judged by the quality of their ideas not on what company they might work for. Participation can be in person at face- to-face meetings, by remote participation at such meetings, via email discussion lists or by publishing IETF documents. 2.5. IETF Structure The work of the IETF is done in working groups. The scope and goals of each working group is defined in a charter. Working groups have one or more chairs, who are responsible for the proper functioning of the working group and for judging consensus on topics discussed within the working group. IETF working groups are grouped together into Areas for managerial efficiency. IETF Areas generally have two Area Directors (ADs) each who are responsible for the proper functioning of the Area, for the creation and termination of working groups within the area and for serving on the Internet Engineering Steering Group (IESG). The IESG is the standards approval body of the IETF and is responsible for approving the creation of working groups and for the technical management of IETF activities and for the Internet standards process. The IESG gets advice on the creation of working Bradner [Page 3] Internet-Draft IETF Liaisoning January 2015 groups from the Internet Architecture Board (IAB). In addition to providing advice to the IESG on creation of working groups, the IAB is responsible for all IETF relationships with other groups (the subject of this memo) and for providing general architectural guidance to the IETF and its working groups. 2.6. Internet Research Task Force The Internet Research Task Force (IRTF) includes research groups that work on topics that are not yet ready for standardization. As with IETF working groups, the main work of IRTF research groups is done over mailing lists, but IETF research groups occasionally meet during an IETF face-to-face meeting. 2.7. The IETF Trust The IETF Trust (trustee.ietf.org/) is a legal entity set up in 2005 to hold whatever intellectual property rights the IETF accumulates during its work. 2.8. IETF Documents IETF documents and mailing lists are publically available, other than a few internal mailing lists and parts of some contracts. 2.8.1. Internet-Drafts IETF Internet-Drafts are IETF working documents. Most Internet- Drafts are submitted by individuals and represent the opinions of the people listed on the face of the Internet-Draft. The publishing process for Internet-Drafts is automated. As long as the document is formatted correctly and includes the proper boilerplate it will get published. The mere publication of an Internet-Draft should not be taken as an indication that anyone participating in the IETF, other than the authors, have knowledge of or support the document. Some other Internet-Drafts are working group documents and are assumed to represent the consensus of the working group, at least to some level. The Internet-Draft's filename can be used to determine its status. Internet-Drafts whose filename starts with draft-ietf- are working group documents. Internet-Drafts whose filename begin with draft- iab- or draft-iesg- are IAB or IESG working Documents. Other Internet-Drafts are the work of their authors. Internet-Draft filenames include a version number at the end. 2.8.2. RFCs RFCs are the archival publications of the IETF. Once published, the contents of an RFC is not changed. There are many types of RFCs. Some RFCs are standards track, some informational, some historic and some are jokes. The type and current status of a RFC can be found in the RFC index. Bradner [Page 4] Internet-Draft IETF Liaisoning January 2015 2.9. IETF Standards Process As mentioned above, most of the work of the IETF is done in working groups. The normal development process for a RFC, standards track or informational, involves one or more people developing an Internet- Draft. The Internet-Draft can be offered to a working group as long as the topic is covered by the working group's charter. Internet- Drafts can also be created at the direction of a working group. The working group will then discuss the Internet-Draft and, in response to the discussions, the authors will create a succession of versions if the Internet-Draft until the working group is satisfied with it. The working group then sends a request to publish the Internet-Draft as a RFC to their AD. The AD does a careful technical and editorial review of the document. If the AD is satisfied he or she then forwards the publication request to the IESG. The IESG issues an IETF-wide "last-call" asking that anyone interested to review the Internet-Draft and send their comments, if any, to the IESG. Then each of the IESG members has the opportunity to review the document. If the ADs, as a body, support the publication a request is sent to the RFC Editor to publish the document as a RFC. The document can be sent back to the working group at any time in the review process if it is not deemed reedy for publication. There is a similar process involving a longer last-call period that can be used to publish a RFC without the requirement of a working group. In addition there is an independent submissions process that can be used to publish non standards-track RFCs. 2.10. IETF Process Documents. The IETF standards process is documented in BCP (Best Current Practice) 9 (currently RFC 2026 [RFC2026] and updates). The IETF copyright rules are documented in BCP 78 (currently RFC 5378 [RFC5378]) and the IETF patent-related rules are documented in BCP 79 (currently RFC 3979 [RFC3979]). 3. Liaison Relationships 3.1 General In general, formal liaison relationships are justified for the IETF when there are areas of technical development of mutual interest in the IETF and in another SDO. For the most part, SDOs would rather leverage existing work done by peer organizations than recreate it themselves (and would like the same done with respect to their own work). Establishing a liaison relationship can provide the framework for ongoing communications to prevent inadvertent duplication of effort, without obstructing either organization from pursuing its own mandate and to provide authoritative information concerning the Bradner [Page 5] Internet-Draft IETF Liaisoning January 2015 status of work within a SDO or concerning one organization's dependencies on work being done in a different SDO. 3.2. Establishing a Liaison Relationship with the IETF Within the IETF, the Internet Architecture Board (IAB) has been chartered to establish and manage liaison relationships. Consistent with its charter [IABCharter], the IAB acts as the representative of the interests of the IETF and of the Internet Society in technical liaison relationships with other organizations concerned with standards as well as technical and organizational issues relevant to the worldwide Internet. Liaison relationships are kept as informal as possible and must be of demonstrable value to the IETF's technical mandate. A liaison relationship is set up when it is mutually agreeable and needed for some specific purpose, in the view of the peer organization, the IAB, and the IETF participants conducting the work. In setting up the relationship, the IAB expects that the setup process will include a mutual exchange of views and discussion of the best approach for undertaking new standardization work items. Any IETF work items will be undertaken in the usual IETF procedures, defined in [BCP 9]. Other SDOs often have organizational structure and procedures that are different than the IETF. Cooperation in the face of often quite different structures and procedures often requires some flexibility on the part of both organizations. The IAB expects that each organization will use the relationship carefully, allowing time for the processes it requests to occur in the peer organization, and will not make unreasonable demands. 3.2.1. Requesting a Liaison Relationship Contact the IAB if you believe that the IETF should establish a Liaison Relationship with another organization. Include in your request the reasons you believe that such a relationship would be beneficial to the IETF and to the other organization. There is no set form or process for this; the IETF participants and/or the peer organization representatives approach the IAB, generally by contacting the IAB Chair or by sending email to the IAB mailing list (iab@ietf.org). 3.2.2. Appointment of a Liaison Manager Once the liaison relationship is established, the IAB appoints a Liaison Manager to act as the IETF-side point of contact. (See section 7.1.) For this role, the IAB will be looking for people who have both a good technical understanding of the work being carried out and effective personal relationships within the IETF and the peer organization. Bradner [Page 6] Internet-Draft IETF Liaisoning January 2015 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. When the liaison is working effectively, it should facilitate the IETF and the peer organization working synergistically and reduce the chance of unrealistic expectations about the work of the two organizations and the chance of overlapping or conflicting standards being created. 3.2.3. Terminating a Liaison Relationship Liaison Relationships are terminated when they no longer provide useful functions in the collective opinion of the IAB and representatives of the peer organization. 3.3. Listing Existing Relationships The IAB maintains a list of existing liaison relationships and the Liaison Managers responsible for each one on the IAB web site at http://www.ietf.org/liaison/managers.html. 4. Liaison Statements Standards Development Organizations (SDOs) frequently use liaison statements to communicate with each other. Liaison statements (or liaisons for short) are simply documents that have been prepared by one organization for consumption by another and that carry the authority of having been formally approved by the sending organization. That is, a liaison reflects the formal and official views of the sending organization and will have gone through an internal approval process in the sending organization. (See section 7.8 for the requirements for the IETF's approval process.) Liaisons can cover almost any topic, but typically ask questions about specific technology being worked on by the target of a liaison, bring attention to work the sending organization is working on that may be of interest to the target organization or to ask for help in extending technology developed by the target organization that is being considered for use by sending organization. A liaison is a business letter sent by one standards organization to another. These organizations may be at any level (WG, Area, etc.) Generally, the sender and addressee are peer organizations. A liaison may have any purpose, but generally the purpose is to solicit information, make a comment or request an action. The IETF often sends liaisons to other SDOs, either in response to a received liaison, or to initiate a dialog. In most cases, communication is very specific to technology under discussion and thus originates from a specific (or small number of) IETF Working Groups. Bradner [Page 7] Internet-Draft IETF Liaisoning January 2015 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, references to documents or documents themselves and time schedules of which one party believes that the other party should be aware. Frequently the liaison will include specific questions that the sending organization would like answered. Frequently liaisons include documents as attachments for information or for comment. It should be noted that all liaison statements sen and received by the IETF are publically posted (https://datatracker.ietf.org/liaison/),along with any attachments the statement may include. See Appendix A for information about the format of liaisons. 5. New-Work email list The IETF maintains a mailing list for the distribution of proposed new work items among standards development organizations. (new- work@ietf.org) On the IETF side, many such items can be identified in proposed Birds-of-a-Feather (BOF) sessions, as well as in the draft charters for proposed working groups. The intent of the list is to enable SDOs to monitor the new work items for possible overlap or interest to their organization. This mailing list receives a few messages per month. Each group with which the IETF has a liaison relationship should ensure that at least one person is subscribed to the new work list and has been tasked with the responsibility to distribute relevant information from the list within the organization and to post information on new or proposed work that might be of interest to other SDOs. 6. - Liaison Relationship to IETF This section provides information to the IETF on how to deal with liaisons from groups that have an existing liaison relationship with the IETF and information for groups that desire or have a liaison relationship to IETF. It is designed to provide information on how the IETF deals with such relationships and the messages that are exchanged within such a relationship, with the people from such groups when they are participating in IETF activities and with messages addressed to the IETF or its working groups received from such groups. 6.1 How liaisons are treated in the IETF One topic that deserves special consideration is how the IETF handles liaisons (both people serving as a liaison and liaison messages) from Bradner [Page 8] Internet-Draft IETF Liaisoning January 2015 other organizations. The IETF has a long tradition of considering itself a meritocracy, where everyone participates as an individual and a person's position or affiliation does not automatically bestow special weight to his or her views. From that perspective, giving a liaison statement special weight, just because it is a liaison from another organization, is potentially problematical. Indeed, IETF processes on liaison handling specify that liaisons must be treated exactly the same as submissions (e.g. an Internet-Draft) from anyone else. From that perspective, in theory, liaison statements do not require special consideration by the IETF. In practice, however, they of course should and do. While a liaison may not by itself carry any special weight, it is in the IETF's own best interest to handle liaisons with special care, giving liaisons proper and careful consideration, and above all being respectful in all interactions with other organizations and the handling of liaisons. 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. 6.2 Referencing IETF documents For example, when a peer organization needs to reference material that is under development in the IETF: the final reference in the peer organization's documents needs the permanent identifier (RFC number) that will be assigned to an 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, when justified and when the IETF document is sufficiently mature that the RFC publication is imminent, 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 Manager 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 lists of their dependencies between their documents and IETF documents on a regular 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) or working group. 6.3. Using the Liaison Tool to send liaisons to the IETF See Appendix B for information about the IETF Liaison Tool used to send liaisons to the IETF. Bradner [Page 9] Internet-Draft IETF Liaisoning January 2015 6.4. IETF processing incoming liaison statements In practice, when handling liaison statements, the following considerations apply: o Listen carefully to what is being asked, take extra steps to understand what is being asked (and why), and be aware that if the IETF doesn't respond helpfully and constructively, the other SDO may not get the relevant input it needs from the IETF and inadvertently take steps that are not in the IETF's own best interest. How the IETF responds can make the difference between a positive collaboration and a situation where poorly informed decisions are made that require active follow up actions later by the IETF to repair the damage. o A liaison represents an official/consensus view of the sending organization (or a particular portion of the organization, such as a working group). Ignoring it or otherwise not responding constructively could be interpreted as a snub, making it harder to work together on any future issue. o The sending organization may not understand the IETF culture well (and vice versa). Poorly chosen words or language can easily be misinterpreted as much more negative or condescending than is helpful. Often there is a longer story behind a liaison statement, and it is advisable to understand the bigger story in order to have a full context in which to respond to a liaison statement. o Giving liaisons special consideration does not mean that the contents of a liaison carry more weight than input from other IETFers, but it does mean the IETF needs to exercise extra due diligence in evaluating and responding to input and carefully considering how a response will be received and what the possible next steps would be. o Responses to liaisons should timely. Reasonable efforts should be made to meet the deadlines conveyed in the liaison taking into account IETF process, the requirement for consensus and the need for careful consideration. Also see section 7.9. 6.5. 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 within 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. Bradner [Page 10] Internet-Draft IETF Liaisoning January 2015 Opinions expressed by a liaison manger of other SDOs, other than reports on work within the liaised organization, are given equal weight with opinions expressed by other working group participants. 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 or 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. 6.6. Informing the IETF of proposed & new work in other SDOs The new-work mailing can also be used to inform the IETF, and the other SDOs subscribed to the list, about proposed and new work in other SDOs. Each group with which the IETF has a liaison relationship is requested to send information relating to new work started or under consideration within that group to the new-work list as soon as the distribution of such information is possible within their process. 7. Liaison Relationship from IETF This section is for the information to IETF participants and to provide an understanding of IETF processes fro people in other organizations. It is designed to provide information on the IETF procedures for dealing with such relationships including how people from the IETF should act when participating in the activities of a group with which the IETF has a Liaison Relationship as a IETF liaison and how liaison messages should be developed, approved and transmitted. 7.1. IETF Liaison Manager When the IAB establishes a liaison relationship with peer organization it designates a person from the IETF to manage that liaison relationship; the person is generally called the "IETF Liaison Manager" to the peer 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, Bradner [Page 11] Internet-Draft IETF Liaisoning January 2015 the peer organization will similarly designate their own liaison manager to the IETF. 7.2. IETF Liaison Representative A Liaison Manager is, specifically, a representative of the IETF for the purpose 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 as Liaison Representatives to different parts of the other organization. Or, it might be appropriate to name a Liaison Representative to attend a particular meeting. 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. The Liaison Manager and Liaison 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. There may be cases where a single individual could serve both as an IETF Liaison Manager or Liaison Representatives to another organization and as that organization's liaison to the IETF. In any such case, the individual must take care to be responsive and true to both organizations. 7.3. Authority, Responsibilities and Duties of an IETF Liaison Manager Most work on topics of mutual interest will be carried out in the usual way within the IETF and the peer organizations. Specifically, by participants in each organization directly participating in the work of the other organization. Therefore, most communications will be informal in nature (for example, Working Group (WG) or mailing list discussions). Liaison Managers generally deal with the cases where more than normal participation is required. An important function of the Liaison Manager is to ensure that communication is maintained, productive, and timely. He or she may use any applicable businesslike approach, from private to public communications, and bring in other parties as needed. If a communication from a peer organization is addressed to an inappropriate party, such as being sent to the WG but not copying the Area Director (AD) or being sent to the wrong WG, the Liaison Manager will help redirect or otherwise augment the communication. Bradner [Page 12] Internet-Draft IETF Liaisoning January 2015 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 consult the IAB's designated Liaison Manager, and if that does not result in a satisfactory outcome, the IAB itself. 7.4. IETF Liaison Manager Communications In communications directed to peer organization, the mandate for IETF Liaison Managers is strictly limited to reporting factual information or reporting IETF consensus to the other organization and to conveying liaison statements from the IETF. The Liaison Manager must not on their own initiative send liaison statements to another organization on behalf of IETF, any of its areas, or any of its working groups. Liaison statements are only sent with the agreement of the IETF chair, the IAB chair, IETF Area Directors, or IETF working group chairs. As part of this, the liaison must clearly differentiate his or her own independent positions from those that represent IETF consensus. The above is not meant to inhibit Liaison Managers from facilitating discussions between people in both organizations to resolve any issues that might arise 7.5. Using the Liaison Tool to send liaisons to other organizations See Appendix B for information on the IETF Liaison Tool used to send liaisons to other organizations. 7.6. Compensation for IETF Liaison Managers and representatives Those representing the IETF, including IETF Liaison Managers and representatives, must inform the IAB if they are offered any remuneration related to the liaison role. In general, apart from reasonable personal travel expenses, Liaison Managers and Representatives are expected to turn down such offers. The IAB will consider requests for exceptions on a case-by-case basis. 7.7. IETF Liaison Manager Responsibilities Examples of tasks performed by the liaison manager are provided below. Depending on the nature of the liaised organization, the tasks may vary in frequency and relative importance. o Attend relevant meetings and participate in conference calls or mailing list discussions within the other organization. Note developments of interest for onward communication to the IETF. When required, communicate IETF consensus to the other organization. o Communicate information relevant to the liaison relationship to the Bradner [Page 13] Internet-Draft IETF Liaisoning January 2015 relevant parts of the IETF; this may involve email messages or discussions with IETFers involved in the other organization and other interested parties within the IETF, e.g., working group chairs and ADs. o Understand the concerns of both the IETF and the other 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 the development of engineering solutions within the appropriate organization. o It is the responsibility of the liaison manager to ensure that the peer 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. o Oversee the proper handling of liaison statements addressed to the IETF. This includes ensuring that liaison statements are delivered to the appropriate destinations within the IETF, as well as shepherding the timely creation of responses by the IETF. o Work with the other organization to ensure that the IETF's liaison statements are clear and are appropriately directed and responded to in a timely fashion. o Communicate and coordinate with other IETF Liaison Managers where the activities or interests of two or more liaised organizations overlap. o Assist with the preparation and delivery of IETF liaison statements based on IETF consensus. o Prepare reports giving updates on developments in the other organization as requested by the IAB or other interested parties in the IETF. o From time to time, Liaison Managers 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 work and issues. o In the cases where an IETF liaison message references an Internet- Draft or RFC, Liaison Managers should remind the target organization of the IETF IPR disclosure website so that the target Bradner [Page 14] Internet-Draft IETF Liaisoning January 2015 organization can determine if IPR disclosures have been filed concerning the documents. 7.8. Consensus Requirements Liaison statements and other messages sent to a peer organization must 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 or 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 it 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. 7.9. Incoming Liaison Statements When the IETF receives a liaison statement or other communication from an organization with which it has a liaison relationship that includes a request for a response to the communication, the IETF is committed to providing a timely response. This means that the IETF will work to respond within the time requested or in the best timely manner possible and provide information as accurately as possible. This commitment does not mean that the IETF will uncritically accept the content in the incoming liaison statement. To the extent that the liaison contains requirements on IETF technology or protocols, they will be taken into consideration based on their technical merit. 7.9.1. Ambiguous Incoming Liaison Statements Sometimes the IETF, an IETF area, or an IETF working group receives liaison statements from a liaised organization that are sent to the 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, including consulting with the IESG, which takes responsibility for some otherwise homeless liaisons. 7.10. Informing others of new or revised IETF work Bradner [Page 15] Internet-Draft IETF Liaisoning January 2015 The IETF forwards all draft charters for all new or substantially revised working groups to the IETF new-work mailing list. Announcements are also made to the list about all BOF session and the completion of all chartering and re-chartering activity. Organizational representatives may provide comments on proposed IETF working group charters and BOF descriptions by responding to the IESG mailing list at iesg@ietf.org clearly indicating their organization's position and the nature of their concern. Plain-text email is preferred on the IESG mailing list. 7.11. Speaking for IETF (in messages & in person) The IETF operates 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 he or she understands the IETF consensus on the topic. 7.12. What Hat to Wear When Acting as a Liaison *******we need a discussion here - when should someone have "IETF" or "ISOC" "on their badge" when communication to a peer organization or attending a meeting vs having a company or national delegation badge***** 8. Intellectual property rights The IETF's copyright-related rules for are detailed in BCP 78. The IETF's patent-related rules are detailed in BCP 79. All people submitting material to the IETF should be aware of these rules. Any organization with which the IETF enters a liaison relationship should take care to ensure that they have informed the IETF of any of their intellectual property rights (IPR) rules that could impact any messages the IETF sends or submissions the IETF makes. 8.1 Copyright The IETF rules on copyright in submitted documents are documented in BCP 78. By submitting an Internet-Draft for publication the authors of the Internet-Draft are agreeing to those rules. This requirement also applies to Internet-Drafts publishes as part of a liaison relationship. Please see BCP 78 for the detailed rules but the following is a brief summary. The IETF copyright-related rules are quite simple. The IETF Trust obtains the non-exclusive perpetual right to publish Internet-Drafts and RFCs from the authors of those documents. Unless a specific notice is included in the submission, the IETF Trust also obtains the right to publish the Internet-Draft as a RFC and the right to produce derivative works based on the material in the submission. The IETF Trust has licensed the content of all such submissions to IETF Bradner [Page 16] Internet-Draft IETF Liaisoning January 2015 participants to produce derivative works within the IETF processes. The IETF Trust, in theory, can license others to produce derivative works outside the IETF standards process (e.g., in books, educational materials, other standards groups, etc.) but this is a rare occurrence, and only done in consultation with the IETF community. Authors of comments sent to an IETF mailing list are consenting to the IETF publishing those comments and to the IETF using such comments in its standards process. Authors of liaison statements are consenting to the IETF publishing the statements. Document authors retain all other rights. Document authors are free to do anything else they wish to with their material. 8.2 Patent and patent applications The IETF rules relating to non-copyright intellectual property rights (within the IETF processes are documented in BCP 79. By submitting an Internet-Draft for publication the authors of the Internet-Draft are agreeing to those rules. Please see BCP 79 for the detailed rules but the following is a brief summary. The work of the IETF and its working groups frequently involves making choices about which technology to use in a particular situation. Understanding all aspects of a technology, including any intellectual property rights related impacts on the use of a technology, is an important part of deciding what technologies to support. Thus, it is important for the IETF and its working groups to be informed of any intellectual property rights claimed in regards to technologies under consideration. Thus, participants in the IETF process are required to disclose any of their own IPR they personally know about in any contribution to the IETF. In this context, a participant is someone who makes a contribution to the IETF (this includes submitting an Internet-Draft, sending email to an IETF mailing list, and speaking during a discussion in an IETF working group) or otherwise doing something designed to effect the discussion about a technology. Also, in this context, "their own IPR" means any patent or patent application that they, their employer or their sponsor could potentially assert against the technology under discussion. 9. Limitation of Liability The IETF makes no representations with respect to and does not warrant the accuracy of any information or any document. Without limiting the foregoing, each party of liaison relationship a agrees Bradner [Page 17] Internet-Draft IETF Liaisoning January 2015 to accept the terms of and reproduce any warranty disclaimers or limitations of liability that are included in any reproduction of published material made available to it under this cooperation framework. 10. IANA Considerations This document makes no requests of the IANA. [this section to be removed before publication] 11. Security Considerations This type of process document does not have any direct effect on the security of the Internet. 12. References 12.1. Normative references 12.2. Informative References RFCs consulted RFC 3113 - 3GPP-IETF Standardization Collaboration. RFC 3131 - 3GPP2-IETF Standardization Collaboration RFC 3975 - OMA-IETF Standardization Collaboration RFC 4052 - IAB Processes for Management of IETF Liaison Relationships RFC 4053 - Procedures for Handling Liaison Statements to and from the IET RFC 4691 - Guidelines for Acting as an IETF Liaison to Another Organization RFC 4965 - CableLabs - IETF Standardization Collaboration RFC 6756 - Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines RFC 7241- The IEEE 802/IETF Relationship Other documents [Tao] The Tao of the IETF, https://www.ietf.org/tao.html 13. Author's addresses Scott Bradner Harvard University 8 Story St. Cambridge MA 02138 USA email: sob@harvard.edu Bradner [Page 18] Internet-Draft IETF Liaisoning January 2015 phone: +1 617 495 3864 Appendix A - Format of a liaison A. Contents of a Liaison Statement Liaison statements may be very formal or informal, depending on the rules of the body generating them. Any liaison statement, however, will always contain certain information, much as an business letter does. This information will include the following: A.1. Envelope Information The following fields detail properties of the liaison statement. A.1.1. From: The statement will indicate from what body it originates; for example, it may be from, an IETF WG or Area, an ITU-T Study Group, Working Party, or Question, etc. In this document, this body is the "sender". A.1.2. To: The statement will indicate to which body it is. In this document, his body is the "addressee". A.1.3. Title: The statement will contain a short (usually single line) statement of its context and content. A.1.4. Response Contact: The sender will indicate the electronic mail address to which any response should be sent. A.1.5. Technical Contact: The sender will indicate one or more electronic mail addresses (persons or lists) that may be contacted for clarification of the liaison statement. A.1.6. Purpose: A liaison statement generally has one of four purposes and will clearly state its purpose using one of the following labels: For Information: The liaison statement is to inform the addressee of something, and expects no response. For Comment: The liaison statement requests commentary from the addressee, usually within a stated time frame. For Action: The liaison statement requests that the addressee do something on the sender's behalf, usually within a stated time frame. Bradner [Page 19] Internet-Draft IETF Liaisoning January 2015 In Response: The liaison statement includes a response to a liaison statement from the peer organization on one or more of its documents and expects no further response. A.1.7. Deadline: Liaison statements that request comment or action will indicate when he comment or action is required. If the addressee cannot accomplish the request within the stated period, courtesy calls for a response offering a more doable deadline or an alternative course of action. A.2. Liaison Content The following fields are the substance of the liaison statement. IETF participants use a wide variety of systems, thus document formats that are not universally readable are problematic. As a result, documents enclosed with the body or attachments should be in PDF, W3C HTML (without proprietary extensions), or ASCII text format. If they were originally in a proprietary format such as Microsoft Word, the file may be sent, but should be accompanied by a generally readable file. A.2.1. Body: As with any business letter, the liaison statement contains appropriate content explaining the issues or questions at hand. A.2.2. Attachments: Attachments, if enclosed, may be in the form of documents sent with he liaison statement or may be URLs to similar documents including Internet-Drafts. Appendix B - The IETF Liaison Tool B. Tools for Handling Liaison Statements Some tools have been developed for the IETF. Development is expected to continue. This section describes the basic tool and its intended use. B.1. Liaison Statements from Other SDOs, Consortia, and Fora to IETF The process of handling a liaison statement is more weighty than handling a business letter because it is important to a relationship with another SDO established by the IAB. To manage liaison statements, the IETF will offer three electronically accessible facilities: a form for submission of liaison statements, a mechanism organizing their contents and making them accessible, and a tracking system. Initially, the tracking system will be a manual procedure used by the liaison manager; in the future, this should be automated. B.1.1. Liaison Statement Submission The IETF Secretariat will provide an electronic method for submission Bradner [Page 20] Internet-Draft IETF Liaisoning January 2015 of liaison statements. The liaison statement submission mechanism is a form that requests the information listed in Section 2.2.1 from the user. Submission of that information results in the following actions: o creation of a display mechanism containing the envelope data in Section 2.2.1.1 and URLs pointing to the items from Section 2.2.1.2, an indication whether the liaison statement has been replied to, and if so, on what date, o the addition of a URL to the "outstanding liaison statements" summary mechanism, o when an automated tracking system has been implemented, a tickler/ status entry in the tracking system, assigned to the relevant chair or AD, o an email to the assignee copying * the liaison statement's technical contacts * The supervisor of the assignee (if it is to a WG, the relevant ADs; if to an AD, the IETF Chair), * The liaison manager for the sending SDO, * an alias associated with the assignee (WG/BOF or other open mailing list, Area Directorate, IESG, IAB, etc.) This email should contain the URL to the liaison statement mechanism, text indicating that the liaison statement has arrived, requests appropriate consideration, and if a deadline is specified, a reply by the deadline. The assignee has the capability of interacting with the liaison manager and the tracking system (once implemented), including replying, changing dates, reassignment, closing the liaison statement process, etc. The liaison manager or tracking system's "tickle" function periodically reminds the assignee by email that the liaison statement has not yet been closed. This tickle email copies all of the above except the associated mailing alias. B.1.2. Mechanism for Displaying Liaison Statements Bradner [Page 21] Internet-Draft IETF Liaisoning January 2015 The IETF site contains a section for current liaison statement activity. This consists of: o A submission mechanism, o A status/management mechanism for each active or recently closed liaison statement, and zero or more associated files. The status/management mechanism contains a simple frame, showing the title of the liaison statement, the URL for its mechanism, and the organizations it is from and to. The display for liaison statement itself contains: o the liaison statement envelope information (Section 2.2.1), o direct content (Section 2.2.1), o URLs for the various associated files o current status of the liaison statement: to whom it is assigned, its due date, and its status, o pointer to the liaison manager and tracking system entry for the liaison statement. o reply-generation mechanism (see Section 3.2.2.4) --- to do need to also cover use of email to liaisons@ietf.org as a backstop when the tool can't be how someone outside the IETF gets write access to the tool (noting that this is often a secretariat function at the other SDO, not necessarily a liaison manager function) how someone inside the IETF gets write access to the tool Bradner [Page 22]