idnits 2.17.1 draft-iab-liaison-mgt-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-iab-liaison-mgt-00', but the file name used is 'draft-iab-liaison-mgt-01' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 15, 2004) is 7375 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3356 (ref. '5') (Obsoleted by RFC 6756) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Daigle 3 Internet-Draft Editor 4 Expires: August 15, 2004 Internet Architecture Board 5 IAB 6 February 15, 2004 8 IAB Processes for management of liaison relationships 9 draft-iab-liaison-mgt-00 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 15, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document discusses the procedures the IAB uses to select 41 organizations to form and maintain liaison relationships with. It 42 further discusses the expectations that the IAB has of such 43 organizations and of the people assigned to manage those 44 relationships. 46 Table of Contents 48 1. Liaison Relationships and Personnel . . . . . . . . . . . . . 3 49 2. Aspects of Liaisons and Liaison Management . . . . . . . . . . 4 50 2.1 Liaison Relationships . . . . . . . . . . . . . . . . . . . . 4 51 2.2 Liaison Manager . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.3 Liaison Communications . . . . . . . . . . . . . . . . . . . . 5 53 3. Summary of IETF Liaison Manager Responsibilities . . . . . . . 6 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 55 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 56 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 59 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11 61 1. Liaison Relationships and Personnel 63 The IETF, as an organization, has the need to engage in direct 64 communication or joint endeavors with various other formal 65 organizations. For example, the IETF is one of several Standards 66 Development Organizations, or SDOs, and all SDOs including the IETF 67 find it increasingly necessary to communicate and coordinate their 68 activities involving Internet-related technologies. This is useful 69 in order to avoid overlap in work efforts and to manage interactions 70 between their groups. In cases where there is formalization of a 71 mutual effort to communicate and coordinate activities, these 72 relationships are generically referred to as "liaison relationships". 74 In such cases, a person from the IETF is designated to manage a given 75 liaison relationship; that person is generally called the "IETF 76 liaison" to the other organization. Often, the other organization 77 will similarly designate their own liaison to the IETF. 79 This document is chiefly concerned with: 81 o the establishment and maintenance of liaison relationships, and 83 o the appointment and responsibilities of IETF liaison managers. 85 The management of other organizations' liaisons to the IETF, whether 86 or not in the context of a liaison relationship, is outside the scope 87 of this document. 89 The IETF has chartered the Internet Architecture Board to manage 90 liaison relationships. In its charter [2], the IAB states that 92 The IAB acts as representative of the interests of the IETF and 93 the Internet Society in technical liaison relationships with other 94 organizations concerned with standards and other technical and 95 organizational issues relevant to the world-wide Internet. 96 Liaisons are kept as informal as possible and must be of 97 demonstrable value in improving the quality of IETF 98 specifications. Individual members of the IETF are appointed as 99 liaisons to other organizations by the IAB or IESG as appropriate. 101 2. Aspects of Liaisons and Liaison Management 103 2.1 Liaison Relationships 105 A liaison relationship is set up when it is mutually agreeable and 106 needed for some specific purpose, in the view of the other 107 organization, the IAB, and the IETF participants conducting the work. 108 There is no set process or form for this; the IETF participants and 109 the peer organization approach the IAB, and after discussion come to 110 an agreement to form the relationship. In some cases, the intended 111 scope and guidelines for the collaboration are documented 112 specifically (e.g., see [3], [4], and [5]). 114 The IAB's expectation in setting up the relationship is that there 115 will be a mutual exchange of views and discussion of the best 116 approach to undertaking new standardization work items. Any work 117 items resulting for the IETF will be undertaken in the usual IETF 118 procedures, defined in [1]. The peer organization often has 119 different organizational structure and different procedures than the 120 IETF, which will require some flexibility on the part of both 121 organizations to accommodate. The IAB expects that the peer 122 organization will use the relationship carefully, allowing time for 123 the processes it requests to occur and not making unreasonable 124 demands. 126 2.2 Liaison Manager 128 As described above, most work on mutually interesting topics will be 129 carried out in the usual way within the IETF and the peer 130 organization. Therefore, most communications will be informal in 131 nature (e.g., working group, mailing list discussions, etc). 133 An important function of the liaison manager is to ensure that 134 communication is maintained, is productive, and is timely. He or she 135 may use any businesslike approach to that necessary, from private 136 communications to public communications, and bringing in other 137 parties as needed. If a communication from a peer organization is 138 addressed to an inappropriate party, such as being sent to the 139 working group but not copying the AD or being sent to the wrong 140 working group, the liaison manager will help redirect or otherwise 141 augment the communication. 143 Since the IAB is ultimately responsible for liaison relationships, 144 anyone who has a problem with a relationship (whether an IETF 145 participant or a person from the peer organization) should first 146 consult the IAB's designated liaison manager, and if that does not 147 result in a satisfactory outcome, the IAB itself. 149 2.3 Liaison Communications 151 Communications between organizations use a variety of formal and 152 informal channels. The stated preference of the IETF, which is 153 largely an informal organization, is to use informal channels, as 154 these have historically worked well to expedite matters. In some 155 cases, however, more formal communications are appropriate. In such 156 cases, the established procedures of many organizations use a form 157 known as a "liaison statement". Procedures for sending, managing, 158 and responding to liaison statements are discussed in draft-baker- 159 liaison-statements. 161 3. Summary of IETF Liaison Manager Responsibilities 163 While the requirements will certainly vary depending on the nature of 164 the peer organization and the type of joint work being undertaken, 165 the general expectations of a liaison appointed by the IAB are as 166 follows: 168 Attend relevant meetings of the peer organization as needed and 169 report back to the appropriate IETF organization any material 170 updates. 172 Carry any messages from the IETF to the peer organization, when 173 specifically instructed. Generally, these communications 174 "represent the IETF", and due care (and consensus) must be applied 175 in their construction. 177 Prepare occasional updates -- e.g., to the IAB, an AD, a WG. The 178 target of these updates will generally be identified upon 179 appointment. 181 Oversee delivery of liaison statements addressed to the IETF, 182 ensuring that they reach the appropriate destination within the 183 IETF, and work to ensure that whatever relevant response from the 184 IETF is created and sent in a timely fashion. 186 Work with the other organization to ensure that the IETF's 187 liaisons are appropriately directed and responded to in a timely 188 fashion. 190 4. Security Considerations 192 The security of the Internet is not threatened by these procedures. 194 5. Acknowledgements 196 This document was developed as part of a conversation regarding the 197 management of draft-baker-liaison-statements, and the authors of that 198 document contributed significantly to it. Also, this version of the 199 document has been improved over its predecessor by several 200 suggestions from Michael Patton, Bert Wijnen, and Scott Bradner. 202 Normative References 204 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 205 9, RFC 2026, October 1996. 207 [2] Internet Architecture Board and B. Carpenter, "Charter of the 208 Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000. 210 Informative References 212 [3] Rosenbrock, K., Sanmugam, R., Bradner, S. and J. Klensin, "3GPP- 213 IETF Standardization Collaboration", RFC 3113, June 2001. 215 [4] Bradner, S., Calhoun, P., Cuschieri, H., Dennett, S., Flynn, G., 216 Lipford, M. and M. McPheters, "3GPP2-IETF Standardization 217 Collaboration", RFC 3131, June 2001. 219 [5] Fishman, G. and S. Bradner, "Internet Engineering Task Force and 220 International Telecommunication Union - Telecommunications 221 Standardization Sector Collaboration Guidelines", RFC 3356, 222 August 2002. 224 Authors' Addresses 226 Leslie Daigle 227 Editor 229 Internet Architecture Board 230 IAB 232 EMail: iab@iab.org 234 Full Copyright Statement 236 Copyright (C) The Internet Society (2004). All Rights Reserved. 238 This document and translations of it may be copied and furnished to 239 others, and derivative works that comment on or otherwise explain it 240 or assist in its implementation may be prepared, copied, published 241 and distributed, in whole or in part, without restriction of any 242 kind, provided that the above copyright notice and this paragraph are 243 included on all such copies and derivative works. However, this 244 document itself may not be modified in any way, such as by removing 245 the copyright notice or references to the Internet Society or other 246 Internet organizations, except as needed for the purpose of 247 developing Internet standards in which case the procedures for 248 copyrights defined in the Internet Standards process must be 249 followed, or as required to translate it into languages other than 250 English. 252 The limited permissions granted above are perpetual and will not be 253 revoked by the Internet Society or its successors or assigns. 255 This document and the information contained herein is provided on an 256 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 257 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 258 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 259 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 260 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 262 Acknowledgement 264 Funding for the RFC Editor function is currently provided by the 265 Internet Society.