idnits 2.17.1 draft-andersson-iab-liaison-guidelines-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 487. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 471. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 477. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119], [RFC4052]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (July 2005) is 6832 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) == Unused Reference: 'RFC3356' is defined on line 439, but no explicit reference was found in the text == Unused Reference: 'RFC4053' is defined on line 444, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3356 (Obsoleted by RFC 6756) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Andersson 3 Internet-Draft Acreo AB 4 Expires: January 2, 2006 July 2005 6 Guidelines for Acting as an IETF Liaison to Another Organization 7 draft-andersson-iab-liaison-guidelines-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 January 2, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 Whenever IETF decides to enter into a liaison relationhsip with 41 another organization, e.g. a Standards Development Organization, a 42 consortium, or an industrial forum, a liaison manger is appointed. 43 The procedures used by the IAB to establish and maintain liaison 44 relationships between the IETF and other organizations are described 45 in RFC 4052 [RFC4052]. This document give guidelines on 46 expectations, tasks, responsibilities and mandate of the liaisons 47 managers. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [RFC2119]. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. IETF liaisons . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Related documents . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Written information . . . . . . . . . . . . . . . . . . . 4 61 2.3. A person acting as liaison . . . . . . . . . . . . . . . . 5 62 2.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Liaison Guidelines . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. Expectations . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Responsibilities . . . . . . . . . . . . . . . . . . . . . 7 66 3.3. Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 3.4. Mandate . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3.4.1. Speaking for the IETF . . . . . . . . . . . . . . . . 9 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 Intellectual Property and Copyright Statements . . . . . . . . . . 15 78 1. Introduction 80 IETF has extensive communication with other organizations on issues 81 telating to the development of standards for the Internet. Part of 82 this is in written form, known as "liaison statements" sent between 83 the organizations. Part is done by appointing a person to be 84 responsible for the relationship with the other organization, a 85 liaison manager. We normally speak of such a person as "the liaison" 86 from the IETF to this other organization. 88 The organizations IETF establish liaison relationships with comes 89 from various categories, such as Standards Developing Organization 90 (SDO), e.g. the ITU-T or IEEE 802, consortium, and industrial forum. 91 Global Grid Forum is an example of the latter. Usually the IETF 92 liaisons are concerned with groups that develop standards and 93 technical specifications, and many types of groups do so. 95 Whenever IETF decides to enter into a liaison relationship a liaison 96 manager is appointed. The procedures used by the IAB to establish 97 and maintain liaison relationships between the IETF and other 98 organizations are described in RFC 4052 [RFC4052]. 100 The role of the liaison manager has become more and important to the 101 IETF. This document therefore, in addition to what is specified in 102 RFC 4052, gives some guidelines for liaison managers and liaison 103 representatives to another organization. 105 2. IETF liaisons 107 A goal for IETF is to develop standards for the Internet. These 108 standards are intended to make interoperable implementations for the 109 Internet possible. Developing Internet standards is an actvity that 110 makes communication with and agreements between IETF and other 111 organizations necessary. Other organizations may develop standards 112 for other types of networks, applications running over the Internet 113 and/or technologies that the Internet uses. 115 Sometimes the IETF and other organizations consider it mutually 116 beneficial to have certain rules governing such a relationship. The 117 organizations then enter into a "liaison relationship". On a high 118 level it can be said that both sides agree to undertake certain 119 responsibilities towards each other. The most basic liaison 120 responsibility is to communicate information as necessary and to 121 respond to requests for information from organizations participating 122 in the liasion relationship. 124 2.1. Related documents 126 The IETF liaison process is specified in an number of documents, RFC 127 4052 specifies how the IAB mamage the IETF liaison relationship, RFC 128 4053 [rfc4053] specifies how liaison statements should be treated. 129 RFC 3356 [rfc3356] describes the collaboration between the IETF and 130 ITU-T. 132 2.2. Written information 134 A large amount of information may be exchanged between the IETF and 135 the organizations it has a liaison relationships with. This 136 information is sent in a liaison statement and typically contains 137 plans, new developments and time schedules that one of the parties 138 believe that the other should be aware of. A typical example is that 139 one of the organizations that the IETF has a liasion relationship 140 with needs to reference IETF documents as part of its document 141 publication activity. The liaison statement the IETF receive would 142 then ask us to have an RFC number ready in time. The response IETF 143 sent could either include that RFC number or explain why it is not 144 possible to have it available within the time requested. 146 The requests for quick action on RFCs by other organizations than ITU 147 have not typically come as liaison statements - e.g. from 3GPP/PP2 148 and OMA, they've come as a monthly-updated list of the document 149 dependencies and dates-required. The liaison manager is expected to 150 follow this and interact and convey the requests via the AD's 151 requests for expedited publication citing the table (or email when 152 needed). 154 2.3. A person acting as liaison 156 Whenever the IETF enteres in to a liaison relationship with another 157 organization a liaison manager is appointed. In day to day talk we 158 refer to this person "the IETF liaison" to this other organization. 159 This document gives guidelines on expecations, tasks and 160 responsibilities for such a person. 162 All decisions on IETF liaison relationships, e.g. whether we should 163 have a liaison realtionship with a certain organization or not, is 164 the responsibility of the IAB. This is also true for appointing 165 liaison managers or liaison representatives. 167 In some cases, it may be necessary to have more than one person 168 working with the liaison realtionship with a given organization. For 169 example, it may be the case that the technical scope of the liaison 170 relationship is to varied, or that the time committement is more than 171 would be reasonable for a single person. 173 In such cases we might appoint a liaison representative, a person 174 appointed to manage one certain aspect of the liaison relationship 175 between IETF and the other organization. 177 2.4. Terminology 179 A terminology for managing the IETF relationship procedures are found 180 in RFC 4052, definitons given here is intended to be the delta valid 181 for this document only. 183 Liaison manager - 185 a person appointed to manage an IETF liaison relationship with 186 another organization. 188 Liaison representative - 190 a person appointed to manage a certain (sub-)aspect of an IETF 191 liaison relationship with another organization. Since it is only the 192 scale of the responsibilities, mandate and tesks that is different 193 the rest of this document only explicitly mentioning the liaison 194 managers. 196 3. Liaison Guidelines 198 Since the liaison relationship is by definition intended to be mutual 199 beneficial, the IETF liaison to another organization must act as a 200 bi-directional communication link between the IETF and the other 201 organization. While this is self evident it, is also evident that 202 since the liasion manager has been appointed by the IETF that there 203 are certain expectations from the IETF. 205 RFC 4052 lists some tasks and expectations on liaison managers, the 206 intention in this document is discuss this in some more detail and at 207 the same time focus more on how to execute the role as liaison 208 manager. 210 3.1. Expectations 212 There are certain expectations placed on liaison managers appointed 213 by the IETF. Examples of these expectations are listed below. 215 Comptence 217 A person appointed to act as a liaison manager on behalf of the IETF 218 is expected to have a thorough technical knowledge and understanding 219 of the key issues in the subject area. That is, the liaison manager 220 is expected to have a thorough understanding of the stakeholder 221 issues from both organizations. 223 An IETF liaison manager needs to have knowledge of the IETF's 224 consensus process in general and on the consesus work on the key 225 issues for the specific liaison relationship in particular. 227 The technical comptence of the liaision manager is important, but it 228 should be understood the essence of the liaison manager role is 229 giving attention to managing the rules agreed upon. While the 230 liaison manager is managing the liaison relationship, the liasion 231 mananger is not an independent IETF technologist with respect to the 232 topics that are the focus of the liaision relationship. Rather, the 233 liaison manager must represent documented IETF consensus in his or 234 her dealings with the liasied organization. 236 Perspective 238 Liaison relationships are designed for the mutual benefit of the 239 organisations participating in the liasion. As such, swift 240 information flow in both directions is a firm requirement. It is 241 nevertheless expected that an IETF liaison manager in everthing that 242 relates to the subject matter of the liaison relationship promotes 243 the interests of the IETF. A liaison managers needs to approach the 244 tasks of the liaison relationship wearing an IETF hat. It is NOT the 245 tasks of a liaison manager to promote the interests of the liaised 246 organization within the IETF. 248 Distance 250 When appointing an appropriate person to manage a liasion 251 relationship the IAB needs to take into account any conflicts of 252 interest that the individual being considered might have. IAB will 253 not appoint a person to liaison manger if there is strong conflict of 254 interests. Examples of such conflict of interest includes industry 255 or organization leadership positions in the liaised organizations. 257 Before a person is appointed to manage a liaison relationship he or 258 she will be asked to explicitly state any conflicts of interest. 260 Commitment and opportunity 262 A liaison needs to be committed to and have the opportunity to solve 263 the issues for which the liaison relationship has been created. This 264 also includes having time allocated to spend on the task. 266 Timeliness 268 One key factor when acting as a liaison is to make the IETF aware of 269 the new development in the subject area in a timely fashion. 271 3.2. Responsibilities 273 The key responsibility of the liaison manager is to make sure that 274 the information flow between the IETF and the liaised organization is 275 as effective as possible. 277 Information brought to the IETF will be used so that the IETF may 278 take decisions and actions based on the best possible information. 279 Information from the IETF is based on IETF consensus. The liaison 280 manager does not develop independent positions different from the 281 IETF consensus, though the liaison manager works with the other 282 organization on ways to ensure that the communication is clear; that 283 the other organization gets it requirements to the IETF, that the 284 IETF consensus is clear. If differences are strong between the IETF 285 and the other organization, the relevant IETF and other organization 286 leadership need to be in touch; the liaison manager needs to 287 facilitate this communication quickly. 289 From a more formal point of view the liaison managers are responsible 290 for a clear and correct communication of the IETF consensus position 291 to the liaised organization. This includes, when specifically 292 instructed, to carry any messages from the IETF to the peer 293 organization. Generally, these communications "represent the IETF", 294 and therefore due care and consensus must be applied in their 295 construction. 297 The liaison managers are responsible that any relevant information 298 originating from the liaised organization, or other information and 299 comes to the attention of the liaison manager, reaches the correct 300 destination, in a timely and correct fashion, within the IETF. 302 3.3. Tasks 304 The list below are examples of tasks that a liaison manager could be 305 required to perform. Depending on the nature of liaised organization 306 the task may vary in frequence and relative importance, 308 1. Attend relevant meetings, mailing lists and conference calls of 309 the liaised organization as needed and report back to the 310 appropriate part of the IETF on any developments that is of 311 interest for the IETF. 313 2. A liaison manager is encouraged to work through delegation, 314 sometimes this involves holding frequent update meetings with a 315 team of IETFers involved in the liaised organization and other 316 interested parties within the IETF, e.g. working group chairs and 317 ADs. A significant result of of holding such meetings is an 318 increased understanding, and eventually IETF support, for the 319 other organizations goals. 321 3. Prepare updates as this is requested by the IETF side. The 322 target of these updates (e.g., the IAB, an AD, a WG) will 323 generally be identified upon establishment of the liaison 324 relationship and/or the appointment of the liaison manager. 326 4. Oversee delivery of liaison statements addressed to the IETF, 327 ensuring that they reach the appropriate destination within the 328 IETF, and ensure that relevant responses from the IETF are 329 created and sent in a timely fashion. 331 5. Work with the liaised organization to ensure that the IETF's 332 liaison statements are appropriately directed and responded to in 333 a timely fashion. This could e.g. be accomplished by building an 334 informal contact network for exchanging relevant information. 336 6. Communicate and coordinate with other IETF liaison managers where 337 concerned technical activities of two or more organizations that 338 the IETF has a liaison relationship with overlap. 340 7. Based on the IETF consensus position be part of preparation of 341 IETF liaison statements. 343 8. Once the IETF has decided that a liaison statement should be sent 344 the liasion manager should be part of the preparation of the 345 liaison statement. The liaison manager should do this based on 346 the IETF consensus position and the information he or she has 347 about the liaised organisation. 349 9. Liaison mangers and liaison representaives shall report to the 350 IETF on status of the liaison relationship and keep track of 351 outstanding issues on behalf of the IETF. The frequency of the 352 reports and the recipients of the reports within the IETF will be 353 decide when the liaison relationship is set up and may be changed 354 at any time by an IAB decision. Status report and issue tracking 355 shall be done by means of the IETF liaison managment system." 357 3.4. Mandate 359 The mandate for IETF liaison managers is strictly limited, it 360 comprises only conveying IETF consensus to the liased organization. 361 In Section 3.3 and in Section 3.2 a number of tasks and 362 responsibilites is listed. There are at least two important aspects 363 of the tasks and responsibilities. Carried out carefully they will 364 supply the IETF with the information need to correctly interact with 365 other organizations. The other, equally important, aspect is that 366 the tasks and responsibilites will help the liaison manager 367 understand the IETF consensus and build a basis on which is possible 368 to execute the mandate. 370 The liaison manager MUST NOT on his or her own initiative send 371 liaison statements to a liaised organization on behalf of IETF, its 372 areas and working groups. Liaison statements are only sent following 373 the process specified in RFC 4052. Liaison statements are only sent 374 on the initiative of the IETF chair, the IAB chair, IETF Area 375 Directors or IETF working group chairs. 377 3.4.1. Speaking for the IETF 379 IETF does work on the rough consensus basis, which means that the 380 right to speak for the IETF is not in any way delegated. However, 381 the liaison manager has the task to speak for the IETF on the subject 382 matter of the liaison, but only after making sure that the IETF 383 consensus is understood. Some guidelines in understanding the IETF 384 consensus are given above, but the most important aspect is a close 385 and detailed coordination and consultation with the IETF side in the 386 liaison relationship. 388 4. Security Considerations 390 Because the interaction on protocols with other standards-making 391 organizations often concerns security aspects, though this document 392 does not specify any protocol or "bits on the wire", getting the 393 liaison manager role right does improve the development of secure 394 protocols for the Internet. 396 5. IANA considerations 398 There are no requests to the IANA herein. Note that the liaison 399 manager very often has to understand and bridge questions regarding 400 IETF namespace. 402 6. Acknowledgements 404 This document was developed as part of a conversation regarding the 405 requirements on IETF liaison managers and representatives. Several 406 IAB memebers have significantly contributed to the document. Also, 407 the document has been improved thanks to suggestions and review from 408 Allison Mankin, Dave Meyer and Leslie Daigle. 410 Members of the IAB at the time of approval of this document were: 412 Bernard Aboba 413 Loa Andersson 414 Brian Carpenter 415 Leslie Daigle 416 Patrik Falstrom 417 Bob Hinden 418 Kurtis Lindqvist 419 David Meyer 420 Pekka Nikander 421 Eric Rescorla 422 Pete Resnick 423 Jonathan Rosenberg 424 Lixia Zhang 426 7. References 428 7.1. Normative References 430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", BCP 14, RFC 2119, March 1997. 433 [RFC4052] Daigle, L. and Internet Architecture Board, "IAB Processes 434 for Management of IETF Liaison Relationships", BCP 102, 435 RFC 4052, April 2005. 437 7.2. Informative References 439 [RFC3356] Fishman, G. and S. Bradner, "Internet Engineering Task 440 Force and International Telecommunication Union - 441 Telecommunications Standardization Sector Collaboration 442 Guidelines", RFC 3356, August 2002. 444 [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for 445 Handling Liaison Statements to and from the IETF", 446 BCP 103, RFC 4053, April 2005. 448 Author's Address 450 Loa Andersson 451 Acreo AB 453 Email: loa@pi.se 455 Intellectual Property Statement 457 The IETF takes no position regarding the validity or scope of any 458 Intellectual Property Rights or other rights that might be claimed to 459 pertain to the implementation or use of the technology described in 460 this document or the extent to which any license under such rights 461 might or might not be available; nor does it represent that it has 462 made any independent effort to identify any such rights. Information 463 on the procedures with respect to rights in RFC documents can be 464 found in BCP 78 and BCP 79. 466 Copies of IPR disclosures made to the IETF Secretariat and any 467 assurances of licenses to be made available, or the result of an 468 attempt made to obtain a general license or permission for the use of 469 such proprietary rights by implementers or users of this 470 specification can be obtained from the IETF on-line IPR repository at 471 http://www.ietf.org/ipr. 473 The IETF invites any interested party to bring to its attention any 474 copyrights, patents or patent applications, or other proprietary 475 rights that may cover technology that may be required to implement 476 this standard. Please address the information to the IETF at 477 ietf-ipr@ietf.org. 479 Disclaimer of Validity 481 This document and the information contained herein are provided on an 482 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 483 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 484 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 485 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 486 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 487 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 489 Copyright Statement 491 Copyright (C) The Internet Society (2005). This document is subject 492 to the rights, licenses and restrictions contained in BCP 78, and 493 except as set forth therein, the authors retain all their rights. 495 Acknowledgment 497 Funding for the RFC Editor function is currently provided by the 498 Internet Society.