idnits 2.17.1 draft-bradner-ietf-liaisoning-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 12 characters in excess of 72. -- The draft header indicates that this document obsoletes RFC4052, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC4053, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC4691, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 22, 2015) is 3382 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2026' is mentioned on line 224, but not defined == Missing Reference: 'RFC5378' is mentioned on line 226, but not defined == Missing Reference: 'RFC3979' is mentioned on line 227, but not defined ** Obsolete undefined reference: RFC 3979 (Obsoleted by RFC 8179) == Missing Reference: 'IABCharter' is mentioned on line 247, but not defined == Missing Reference: 'BCP 9' is mentioned on line 263, but not defined Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Scott Bradner 3 Internet-Draft Harvard University 4 Intended status: BCP Editor 5 Obsoletes: 4052, 4053, 4691 January 22, 2015 6 Updates: TBD 7 Expires: July 22, 2015 9 IETF Liaisoning 10 draft-bradner-ietf-liaisoning-01.txt 12 Abstract This document details the processes by which the IETF interacts 13 with peer organizations. In some cases this involves establishing 14 long lasting formal liaison relationships and in other cases the 15 processes are less formal and of shorter duration. The document is 16 designed to be useful in both cases to both IETF participants and to 17 the participants in the other organizations. The document also 18 includes information and pointers to information about the IETF and 19 its operation that may be of use to participants in such peer 20 organizations. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December xx, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 55 TBD 57 1. Introduction 58 Standards development organizations (SDOs), including the IETF, often 59 find it useful to engage in direct, and often formal, communication 60 with each other to convey information relevant to a standards 61 development effort in a SDO or to coordinate related standards 62 development efforts. 64 For example, as a SDO working in the Internet area, the IETF finds it 65 increasingly necessary to communicate and coordinate their activities 66 involving Internet-related technologies with other SDOs working in 67 the same area. This is useful in order to avoid accidental overlap 68 in work efforts and to manage interactions between their groups. In 69 cases where the mutual effort to communicate and coordinate 70 activities is formalized, these relationships are generically 71 referred to as "liaison relationships". 73 In addition, the IETF interacts with Internet-related organizations 74 that are not directly involved in standards development, such as 75 Internet Corporation for Assigned Names and Numbers (ICANN), the 76 regional Internet registries (RIRs), and the Internet Governance 77 Forum (IGF). These interactions sometimes require that the IETF 78 provide formal communications on a topic but do not require the 79 ongoing coordination that a liaison relationship implies. 81 This document addresses both situations. 83 2. IETF Background 84 This section provides a very quick overview of the IETF for the 85 benefit of people in other organizations who may not be familiar with 86 the IETF. Some of this information is from the Tao of the IETF [Tao], 87 where a fuller picture of the IETF and how it works can be found. 89 2.1. IETF Scope 90 The IETF is concerned with all protocols, procedures, and conventions 91 that are used in or by the Internet, whether or not they are part of 92 the TCP/IP protocol suite. [RFC2026] 94 2.2. IETF History 95 The Internet Engineering Task Force (IETF) was formed in 1986 as an 96 expansion of US government sponsored activities aimed at the 97 development of Internet related technology. Although the IETF 98 received US Government support until 1997, the IETF became a self- 99 directed activity before 1990. Since then, support for the IETF has 100 come from meeting fees and, since the late 1990s, from the Internet 101 Society. 103 The IETF holds face-to-face meetings three times a year but most of 104 the work of the IETF takes place on mailing lists and occasional 105 working group interim or virtual meetings. Attendance at the face- 106 to-face meetings grew from 21 at the first meeting to over 28 hundred 107 at the height of the Internet boom in 2001. Meeting attendance has 108 been between 1,000 and 1,500 for most of the last decade. 110 2.3. Internet Society 111 The IETF has no separate legal existence, it has been operating as an 112 organized activity of the Internet Society since 1996. 114 The mission of the Internet Society (www.internetsociety.org/) is "to 115 promote the open development, evolution, and use of the Internet for 116 the benefit of all people throughout the world". The Internet Society 117 sees support for the IETF as a part of fulfilling its mission. 119 2.4. IETF Participants 120 The IETF does not have any members or membership agreements. 121 Individuals participate in the activities of the IETF on their own 122 behalf and are judged by the quality of their ideas not on what 123 company they might work for. Participation can be in person at face- 124 to-face meetings, by remote participation at such meetings, via email 125 discussion lists or by publishing IETF documents. 127 2.5. IETF Structure 128 The work of the IETF is done in working groups. The scope and goals 129 of each working group is defined in a charter. Working groups have 130 one or more chairs, who are responsible for the proper functioning of 131 the working group and for judging consensus on topics discussed 132 within the working group. 134 IETF working groups are grouped together into Areas for managerial 135 efficiency. IETF Areas generally have two Area Directors (ADs) each 136 who are responsible for the proper functioning of the Area, for the 137 creation and termination of working groups within the area and for 138 serving on the Internet Engineering Steering Group (IESG). 140 The IESG is the standards approval body of the IETF and is 141 responsible for approving the creation of working groups and for the 142 technical management of IETF activities and for the Internet 143 standards process. The IESG gets advice on the creation of working 144 groups from the Internet Architecture Board (IAB). 146 In addition to providing advice to the IESG on creation of working 147 groups, the IAB is responsible for all IETF relationships with other 148 groups (the subject of this memo) and for providing general 149 architectural guidance to the IETF and its working groups. 151 2.6. Internet Research Task Force 152 The Internet Research Task Force (IRTF) includes research groups that 153 work on topics that are not yet ready for standardization. As with 154 IETF working groups, the main work of IRTF research groups is done 155 over mailing lists, but IETF research groups occasionally meet during 156 an IETF face-to-face meeting. 158 2.7. The IETF Trust 159 The IETF Trust (trustee.ietf.org/) is a legal entity set up in 2005 160 to hold whatever intellectual property rights the IETF accumulates 161 during its work. 163 2.8. IETF Documents 164 IETF documents and mailing lists are publically available, other than 165 a few internal mailing lists and parts of some contracts. 167 2.8.1. Internet-Drafts 168 IETF Internet-Drafts are IETF working documents. Most Internet- 169 Drafts are submitted by individuals and represent the opinions of the 170 people listed on the face of the Internet-Draft. The publishing 171 process for Internet-Drafts is automated. As long as the document is 172 formatted correctly and includes the proper boilerplate it will get 173 published. The mere publication of an Internet-Draft should not be 174 taken as an indication that anyone participating in the IETF, other 175 than the authors, have knowledge of or support the document. Some 176 other Internet-Drafts are working group documents and are assumed to 177 represent the consensus of the working group, at least to some level. 179 The Internet-Draft's filename can be used to determine its status. 180 Internet-Drafts whose filename starts with draft-ietf- are working 181 group documents. Internet-Drafts whose filename begin with draft- 182 iab- or draft-iesg- are IAB or IESG working Documents. Other 183 Internet-Drafts are the work of their authors. Internet-Draft 184 filenames include a version number at the end. 186 2.8.2. RFCs 187 RFCs are the archival publications of the IETF. Once published, the 188 contents of an RFC is not changed. There are many types of RFCs. 189 Some RFCs are standards track, some informational, some historic and 190 some are jokes. The type and current status of a RFC can be found in 191 the RFC index. 193 2.9. IETF Standards Process 194 As mentioned above, most of the work of the IETF is done in working 195 groups. The normal development process for a RFC, standards track or 196 informational, involves one or more people developing an Internet- 197 Draft. The Internet-Draft can be offered to a working group as long 198 as the topic is covered by the working group's charter. Internet- 199 Drafts can also be created at the direction of a working group. The 200 working group will then discuss the Internet-Draft and, in response 201 to the discussions, the authors will create a succession of versions 202 if the Internet-Draft until the working group is satisfied with it. 203 The working group then sends a request to publish the Internet-Draft 204 as a RFC to their AD. The AD does a careful technical and editorial 205 review of the document. If the AD is satisfied he or she then 206 forwards the publication request to the IESG. The IESG issues an 207 IETF-wide "last-call" asking that anyone interested to review the 208 Internet-Draft and send their comments, if any, to the IESG. Then 209 each of the IESG members has the opportunity to review the document. 210 If the ADs, as a body, support the publication a request is sent to 211 the RFC Editor to publish the document as a RFC. The document can be 212 sent back to the working group at any time in the review process if 213 it is not deemed reedy for publication. 215 There is a similar process involving a longer last-call period that 216 can be used to publish a RFC without the requirement of a working 217 group. 219 In addition there is an independent submissions process that can be 220 used to publish non standards-track RFCs. 222 2.10. IETF Process Documents. 223 The IETF standards process is documented in BCP (Best Current 224 Practice) 9 (currently RFC 2026 [RFC2026] and updates). The IETF 225 copyright rules are documented in BCP 78 (currently RFC 5378 226 [RFC5378]) and the IETF patent-related rules are documented in BCP 79 227 (currently RFC 3979 [RFC3979]). 229 3. Liaison Relationships 231 3.1 General 232 In general, formal liaison relationships are justified for the IETF 233 when there are areas of technical development of mutual interest in 234 the IETF and in another SDO. For the most part, SDOs would rather 235 leverage existing work done by peer organizations than recreate it 236 themselves (and would like the same done with respect to their own 237 work). Establishing a liaison relationship can provide the framework 238 for ongoing communications to prevent inadvertent duplication of 239 effort, without obstructing either organization from pursuing its own 240 mandate and to provide authoritative information concerning the 241 status of work within a SDO or concerning one organization's 242 dependencies on work being done in a different SDO. 244 3.2. Establishing a Liaison Relationship with the IETF 245 Within the IETF, the Internet Architecture Board (IAB) has been 246 chartered to establish and manage liaison relationships. Consistent 247 with its charter [IABCharter], the IAB acts as the representative of 248 the interests of the IETF and of the Internet Society in technical 249 liaison relationships with other organizations concerned with 250 standards as well as technical and organizational issues relevant to 251 the worldwide Internet. Liaison relationships are kept as informal 252 as possible and must be of demonstrable value to the IETF's technical 253 mandate. 255 A liaison relationship is set up when it is mutually agreeable and 256 needed for some specific purpose, in the view of the peer 257 organization, the IAB, and the IETF participants conducting the work. 259 In setting up the relationship, the IAB expects that the setup 260 process will include a mutual exchange of views and discussion of the 261 best approach for undertaking new standardization work items. Any 262 IETF work items will be undertaken in the usual IETF procedures, 263 defined in [BCP 9]. Other SDOs often have organizational structure 264 and procedures that are different than the IETF. Cooperation in the 265 face of often quite different structures and procedures often 266 requires some flexibility on the part of both organizations. The IAB 267 expects that each organization will use the relationship carefully, 268 allowing time for the processes it requests to occur in the peer 269 organization, and will not make unreasonable demands. 271 3.2.1. Requesting a Liaison Relationship 272 Contact the IAB if you believe that the IETF should establish a 273 Liaison Relationship with another organization. Include in your 274 request the reasons you believe that such a relationship would be 275 beneficial to the IETF and to the other organization. 277 There is no set form or process for this; the IETF participants 278 and/or the peer organization representatives approach the IAB, 279 generally by contacting the IAB Chair or by sending email to the IAB 280 mailing list (iab@ietf.org). 282 3.2.2. Appointment of a Liaison Manager 283 Once the liaison relationship is established, the IAB appoints a 284 Liaison Manager to act as the IETF-side point of contact. (See 285 section 7.1.) For this role, the IAB will be looking for people who 286 have both a good technical understanding of the work being carried 287 out and effective personal relationships within the IETF and the peer 288 organization. 290 Ongoing face-to-face interactions between the IETF liaisons and 291 members of the peer organization are seen as critical to the 292 effective functioning of the role. These interactions should allow 293 the liaisons to keep the IETF abreast, and preferably ahead, of 294 matters of mutual interest or potential conflict. When the liaison 295 is working effectively, it should facilitate the IETF and the peer 296 organization working synergistically and reduce the chance of 297 unrealistic expectations about the work of the two organizations and 298 the chance of overlapping or conflicting standards being created. 300 3.2.3. Terminating a Liaison Relationship 301 Liaison Relationships are terminated when they no longer provide 302 useful functions in the collective opinion of the IAB and 303 representatives of the peer organization. 305 3.3. Listing Existing Relationships 306 The IAB maintains a list of existing liaison relationships and the 307 Liaison Managers responsible for each one on the IAB web site at 308 http://www.ietf.org/liaison/managers.html. 310 4. Liaison Statements 311 Standards Development Organizations (SDOs) frequently use liaison 312 statements to communicate with each other. Liaison statements (or 313 liaisons for short) are simply documents that have been prepared by 314 one organization for consumption by another and that carry the 315 authority of having been formally approved by the sending 316 organization. That is, a liaison reflects the formal and official 317 views of the sending organization and will have gone through an 318 internal approval process in the sending organization. (See section 319 7.8 for the requirements for the IETF's approval process.) Liaisons 320 can cover almost any topic, but typically ask questions about 321 specific technology being worked on by the target of a liaison, bring 322 attention to work the sending organization is working on that may be 323 of interest to the target organization or to ask for help in 324 extending technology developed by the target organization that is 325 being considered for use by sending organization. 327 A liaison is a business letter sent by one standards organization to 328 another. These organizations may be at any level (WG, Area, etc.) 329 Generally, the sender and addressee are peer organizations. A 330 liaison may have any purpose, but generally the purpose is to solicit 331 information, make a comment or request an action. 333 The IETF often sends liaisons to other SDOs, either in response to a 334 received liaison, or to initiate a dialog. In most cases, 335 communication is very specific to technology under discussion and 336 thus originates from a specific (or small number of) IETF Working 337 Groups. 339 Aside from the personal contacts between liaisons and the peer 340 organization, extensive communication may occur between the IETF and 341 the peer organizations through written materials. Much of this 342 communication is through liaison statements that typically contain 343 plans, new developments, references to documents or documents 344 themselves and time schedules of which one party believes that the 345 other party should be aware. Frequently the liaison will include 346 specific questions that the sending organization would like answered. 348 Frequently liaisons include documents as attachments for information 349 or for comment. It should be noted that all liaison statements sen 350 and received by the IETF are publically posted 351 (https://datatracker.ietf.org/liaison/),along with any attachments 352 the statement may include. 354 See Appendix A for information about the format of liaisons. 356 5. New-Work email list 357 The IETF maintains a mailing list for the distribution of proposed 358 new work items among standards development organizations. (new- 359 work@ietf.org) On the IETF side, many such items can be identified in 360 proposed Birds-of-a-Feather (BOF) sessions, as well as in the draft 361 charters for proposed working groups. The intent of the list is to 362 enable SDOs to monitor the new work items for possible overlap or 363 interest to their organization. This mailing list receives a few 364 messages per month. 366 Each group with which the IETF has a liaison relationship should 367 ensure that at least one person is subscribed to the new work list 368 and has been tasked with the responsibility to distribute relevant 369 information from the list within the organization and to post 370 information on new or proposed work that might be of interest to 371 other SDOs. 373 6. - Liaison Relationship to IETF 374 This section provides information to the IETF on how to deal with 375 liaisons from groups that have an existing liaison relationship with 376 the IETF and information for groups that desire or have a liaison 377 relationship to IETF. It is designed to provide information on how 378 the IETF deals with such relationships and the messages that are 379 exchanged within such a relationship, with the people from such 380 groups when they are participating in IETF activities and with 381 messages addressed to the IETF or its working groups received from 382 such groups. 384 6.1 How liaisons are treated in the IETF 385 One topic that deserves special consideration is how the IETF handles 386 liaisons (both people serving as a liaison and liaison messages) from 387 other organizations. The IETF has a long tradition of considering 388 itself a meritocracy, where everyone participates as an individual 389 and a person's position or affiliation does not automatically bestow 390 special weight to his or her views. From that perspective, giving a 391 liaison statement special weight, just because it is a liaison from 392 another organization, is potentially problematical. Indeed, IETF 393 processes on liaison handling specify that liaisons must be treated 394 exactly the same as submissions (e.g. an Internet-Draft) from anyone 395 else. From that perspective, in theory, liaison statements do not 396 require special consideration by the IETF. In practice, however, 397 they of course should and do. While a liaison may not by itself carry 398 any special weight, it is in the IETF's own best interest to handle 399 liaisons with special care, giving liaisons proper and careful 400 consideration, and above all being respectful in all interactions 401 with other organizations and the handling of liaisons. 403 The Liaison Manager should be aware of these written communications 404 and assist both parties to see that appropriate action is taken in 405 relation to liaison statements passing in both directions. 407 6.2 Referencing IETF documents 408 For example, when a peer organization needs to reference material 409 that is under development in the IETF: the final reference in the 410 peer organization's documents needs the permanent identifier (RFC 411 number) that will be assigned to an Internet-Draft when it is 412 approved and published. To meet the publication schedule of the peer 413 organization, a liaison statement is often sent to the IETF 414 requesting that an RFC number be assigned within the required 415 timeframe. In response, the IETF can, when justified and when the 416 IETF document is sufficiently mature that the RFC publication is 417 imminent, provide the RFC number or explain why it is not possible to 418 provide this within the timeframe requested. 420 An alternative situation that involves more specific action by the 421 Liaison Manager also involves requests for this kind of expedited 422 action on RFCs. For example, 3GPP/3GPP2 and the Open Mobile 423 Alliance(OMA) provide the IETF with an updated lists of their 424 dependencies between their documents and IETF documents on a regular 425 basis, indicating what documents are needed and the required 426 timeframe. In this case, the liaison manager tracks the dependency 427 list and, when necessary, conveys the request for expedited 428 assignment to the appropriate IETF Area Director (AD) or working 429 group. 431 6.3. Using the Liaison Tool to send liaisons to the IETF 432 See Appendix B for information about the IETF Liaison Tool used to 433 send liaisons to the IETF. 435 6.4. IETF processing incoming liaison statements 436 In practice, when handling liaison statements, the following 437 considerations apply: 439 o Listen carefully to what is being asked, take extra steps to 440 understand what is being asked (and why), and be aware that if the 441 IETF doesn't respond helpfully and constructively, the other SDO 442 may not get the relevant input it needs from the IETF and 443 inadvertently take steps that are not in the IETF's own best 444 interest. How the IETF responds can make the difference between a 445 positive collaboration and a situation where poorly informed 446 decisions are made that require active follow up actions later by 447 the IETF to repair the damage. 449 o A liaison represents an official/consensus view of the sending 450 organization (or a particular portion of the organization, such as 451 a working group). Ignoring it or otherwise not responding 452 constructively could be interpreted as a snub, making it harder to 453 work together on any future issue. 455 o The sending organization may not understand the IETF culture well 456 (and vice versa). Poorly chosen words or language can easily be 457 misinterpreted as much more negative or condescending than is 458 helpful. Often there is a longer story behind a liaison 459 statement, and it is advisable to understand the bigger story in 460 order to have a full context in which to respond to a liaison 461 statement. 463 o Giving liaisons special consideration does not mean that the 464 contents of a liaison carry more weight than input from other 465 IETFers, but it does mean the IETF needs to exercise extra due 466 diligence in evaluating and responding to input and carefully 467 considering how a response will be received and what the possible 468 next steps would be. 470 o Responses to liaisons should timely. Reasonable efforts should be 471 made to meet the deadlines conveyed in the liaison taking into 472 account IETF process, the requirement for consensus and the need 473 for careful consideration. Also see section 7.9. 475 6.5. Liaison Managers Representing Peer Organizations 476 Liaised organizations may appoint a person to act as a liaison 477 manager for "their side" of the relationship. This is the person 478 that will speak authoritatively, within the IETF, on the activities 479 within the other organization. The other organization needs to make 480 this person known to the IETF. This person might request a slot on a 481 working group agenda to discuss developments and plans of the liaised 482 organization. 484 Opinions expressed by a liaison manger of other SDOs, other than 485 reports on work within the liaised organization, are given equal 486 weight with opinions expressed by other working group participants. 488 The mandates of liaison managers from other organizations are 489 recognized by the IETF to the extent needed to understand the 490 information received from the liaison manager. In all other respects 491 he or she participates in IETF activities under the same conditions 492 and rules as any other IETF participant. It is important that the 493 IETF Liaison Manager understands the extent to which the peer liaison 494 manager is mandated or delegated to speak on behalf of the peer 495 organization, and to inform the relevant part of the IETF if the peer 496 liaison manager appears to be stepping outside the role or stance 497 given to him or her by the peer organization. 499 IETF Liaison Managers should work to include the liaison manager from 500 the liaised organization within their contact network, and to 501 understand the positions being communicated by the peer liaison 502 manager. 504 6.6. Informing the IETF of proposed & new work in other SDOs 505 The new-work mailing can also be used to inform the IETF, and the 506 other SDOs subscribed to the list, about proposed and new work in 507 other SDOs. 509 Each group with which the IETF has a liaison relationship is 510 requested to send information relating to new work started or under 511 consideration within that group to the new-work list as soon as the 512 distribution of such information is possible within their process. 514 7. Liaison Relationship from IETF 515 This section is for the information to IETF participants and to 516 provide an understanding of IETF processes fro people in other 517 organizations. It is designed to provide information on the IETF 518 procedures for dealing with such relationships including how people 519 from the IETF should act when participating in the activities of a 520 group with which the IETF has a Liaison Relationship as a IETF 521 liaison and how liaison messages should be developed, approved and 522 transmitted. 524 7.1. IETF Liaison Manager 525 When the IAB establishes a liaison relationship with peer 526 organization it designates a person from the IETF to manage that 527 liaison relationship; the person is generally called the "IETF 528 Liaison Manager" to the peer organization. When the liaison 529 relationship is expected to encompass a complex or broad range of 530 activities, more people may be designated to undertake some portions 531 of the communications, coordinated by the liaison manager. Often, 532 the peer organization will similarly designate their own liaison 533 manager to the IETF. 535 7.2. IETF Liaison Representative 536 A Liaison Manager is, specifically, a representative of the IETF for 537 the purpose of managing the liaison relationship. There may be 538 occasion to identify other representatives for the same relationship. 539 For example, if the area of mutual work is extensive, it might be 540 appropriate to name several people as Liaison Representatives to 541 different parts of the other organization. Or, it might be 542 appropriate to name a Liaison Representative to attend a particular 543 meeting. 545 Liaison Representatives are selected by the IAB and work in 546 conjunction (and close communication) with the Liaison Manager. In 547 some cases, this may also require communication and coordination with 548 other Liaison Managers or representatives where concerned technical 549 activities overlap. The specific responsibilities of the Liaison 550 Representative will be identified at the time of appointment. 552 The Liaison Manager and Liaison Representatives provide information 553 to the IETF community in order to enable the IETF to make decisions 554 based on the best possible information regarding the work in the peer 555 organization. 557 There may be cases where a single individual could serve both as an 558 IETF Liaison Manager or Liaison Representatives to another 559 organization and as that organization's liaison to the IETF. In any 560 such case, the individual must take care to be responsive and true to 561 both organizations. 563 7.3. Authority, Responsibilities and Duties of an IETF Liaison Manager 564 Most work on topics of mutual interest will be carried out in the 565 usual way within the IETF and the peer organizations. Specifically, 566 by participants in each organization directly participating in the 567 work of the other organization. Therefore, most communications will 568 be informal in nature (for example, Working Group (WG) or mailing 569 list discussions). Liaison Managers generally deal with the cases 570 where more than normal participation is required. 572 An important function of the Liaison Manager is to ensure that 573 communication is maintained, productive, and timely. He or she may 574 use any applicable businesslike approach, from private to public 575 communications, and bring in other parties as needed. If a 576 communication from a peer organization is addressed to an 577 inappropriate party, such as being sent to the WG but not copying the 578 Area Director (AD) or being sent to the wrong WG, the Liaison Manager 579 will help redirect or otherwise augment the communication. 581 IETF Liaison Managers should also communicate and coordinate with 582 other Liaison Managers where concerned technical activities overlap. 584 Since the IAB is ultimately responsible for liaison relationships, 585 anyone who has a problem with a relationship (whether an IETF 586 participant or a person from the peer organization) should first 587 consult the IAB's designated Liaison Manager, and if that does not 588 result in a satisfactory outcome, the IAB itself. 590 7.4. IETF Liaison Manager Communications 591 In communications directed to peer organization, the mandate for IETF 592 Liaison Managers is strictly limited to reporting factual information 593 or reporting IETF consensus to the other organization and to 594 conveying liaison statements from the IETF. The Liaison Manager must 595 not on their own initiative send liaison statements to another 596 organization on behalf of IETF, any of its areas, or any of its 597 working groups. Liaison statements are only sent with the agreement 598 of the IETF chair, the IAB chair, IETF Area Directors, or IETF 599 working group chairs. As part of this, the liaison must clearly 600 differentiate his or her own independent positions from those that 601 represent IETF consensus. The above is not meant to inhibit Liaison 602 Managers from facilitating discussions between people in both 603 organizations to resolve any issues that might arise 605 7.5. Using the Liaison Tool to send liaisons to other organizations 606 See Appendix B for information on the IETF Liaison Tool used to send 607 liaisons to other organizations. 609 7.6. Compensation for IETF Liaison Managers and representatives 610 Those representing the IETF, including IETF Liaison Managers and 611 representatives, must inform the IAB if they are offered any 612 remuneration related to the liaison role. In general, apart from 613 reasonable personal travel expenses, Liaison Managers and 614 Representatives are expected to turn down such offers. The IAB will 615 consider requests for exceptions on a case-by-case basis. 617 7.7. IETF Liaison Manager Responsibilities 618 Examples of tasks performed by the liaison manager are provided 619 below. Depending on the nature of the liaised organization, the 620 tasks may vary in frequency and relative importance. 622 o Attend relevant meetings and participate in conference calls or 623 mailing list discussions within the other organization. Note 624 developments of interest for onward communication to the IETF. 625 When required, communicate IETF consensus to the other 626 organization. 628 o Communicate information relevant to the liaison relationship to the 629 relevant parts of the IETF; this may involve email messages or 630 discussions with IETFers involved in the other organization and 631 other interested parties within the IETF, e.g., working group 632 chairs and ADs. 634 o Understand the concerns of both the IETF and the other 635 organization, while ensuring that interests of the IETF are 636 maintained. Where there appear to be problems to solve or 637 conflicts between approaches, work with both parties to encourage 638 the development of engineering solutions within the appropriate 639 organization. 641 o It is the responsibility of the liaison manager to ensure that the 642 peer organization communicates its requirements to the IETF in a 643 timely fashion and that the IETF consensus is clearly understood. 644 This is particularly important in situations where the IETF and 645 the liaised organization differ substantially in their positions. 646 In this situation, the liaison manager needs to facilitate prompt 647 communication so that the IETF and the liaised organization can 648 stay in close communication and avoid misunderstandings. 650 o Oversee the proper handling of liaison statements addressed to the 651 IETF. This includes ensuring that liaison statements are 652 delivered to the appropriate destinations within the IETF, as well 653 as shepherding the timely creation of responses by the IETF. 655 o Work with the other organization to ensure that the IETF's liaison 656 statements are clear and are appropriately directed and responded 657 to in a timely fashion. 659 o Communicate and coordinate with other IETF Liaison Managers where 660 the activities or interests of two or more liaised organizations 661 overlap. 663 o Assist with the preparation and delivery of IETF liaison statements 664 based on IETF consensus. 666 o Prepare reports giving updates on developments in the other 667 organization as requested by the IAB or other interested parties 668 in the IETF. 670 o From time to time, Liaison Managers will have to report to the IETF 671 on the status of the liaison relationship. For this purpose, they 672 will need to keep track of outstanding work and issues. 674 o In the cases where an IETF liaison message references an Internet- 675 Draft or RFC, Liaison Managers should remind the target 676 organization of the IETF IPR disclosure website so that the target 677 organization can determine if IPR disclosures have been filed 678 concerning the documents. 680 7.8. Consensus Requirements 681 Liaison statements and other messages sent to a peer organization 682 must be based on rough consensus within the IETF or one of its 683 working groups or areas. Though the Liaison Manager is not 684 responsible for determining consensus, it is important that the 685 Liaison Manager participate in the process and makes his or her 686 expertise and knowledge available. 688 How consensus is arrived at may vary according to the circumstances. 689 Some issues are new, and in these cases an open discussion on a 690 mailing list should be undertaken. For some issues, consensus has 691 already been arrived at or the liaison statement is a mere statement 692 of facts (e.g., to inform the liaised organization that an IETF Last 693 Call had started on a document it had previously expressed interest 694 in) and in these cases the liaison statement can be written and sent 695 (such as by a working group chair), possibly involving the Liaison 696 Manager. 698 7.9. Incoming Liaison Statements 699 When the IETF receives a liaison statement or other communication 700 from an organization with which it has a liaison relationship that 701 includes a request for a response to the communication, the IETF is 702 committed to providing a timely response. This means that the IETF 703 will work to respond within the time requested or in the best timely 704 manner possible and provide information as accurately as possible. 706 This commitment does not mean that the IETF will uncritically accept 707 the content in the incoming liaison statement. To the extent that 708 the liaison contains requirements on IETF technology or protocols, 709 they will be taken into consideration based on their technical merit. 711 7.9.1. Ambiguous Incoming Liaison Statements 712 Sometimes the IETF, an IETF area, or an IETF working group receives 713 liaison statements from a liaised organization that are sent to the 714 wrong destination. At other times, the liaison statement is sent to 715 working groups that are not chartered to do the work that the liaison 716 statement addresses. In some cases, it might be the situation that 717 no working group is chartered to do the work. 719 In such cases, the liaison manager should assist in finding the 720 appropriate recipient within the IETF that might respond to the 721 incoming liaison statement, including consulting with the IESG, which 722 takes responsibility for some otherwise homeless liaisons. 724 7.10. Informing others of new or revised IETF work 725 The IETF forwards all draft charters for all new or substantially 726 revised working groups to the IETF new-work mailing list. 727 Announcements are also made to the list about all BOF session and the 728 completion of all chartering and re-chartering activity. 730 Organizational representatives may provide comments on proposed IETF 731 working group charters and BOF descriptions by responding to the IESG 732 mailing list at iesg@ietf.org clearly indicating their organization's 733 position and the nature of their concern. Plain-text email is 734 preferred on the IESG mailing list. 736 7.11. Speaking for IETF (in messages & in person) 737 The IETF operates based on rough consensus, which means that the 738 right to speak for the IETF cannot be delegated. The Liaison Manager 739 speaks on behalf of the IETF on the subject matter of the liaison, 740 but only after making sure that he or she understands the IETF 741 consensus on the topic. 743 7.12. What Hat to Wear When Acting as a Liaison 744 *******we need a discussion here - when should someone have "IETF" or 745 "ISOC" "on their badge" when communication to a peer organization or 746 attending a meeting vs having a company or national delegation 747 badge***** 749 8. Intellectual property rights 750 The IETF's copyright-related rules for are detailed in BCP 78. The 751 IETF's patent-related rules are detailed in BCP 79. All people 752 submitting material to the IETF should be aware of these rules. Any 753 organization with which the IETF enters a liaison relationship should 754 take care to ensure that they have informed the IETF of any of their 755 intellectual property rights (IPR) rules that could impact any 756 messages the IETF sends or submissions the IETF makes. 758 8.1 Copyright 759 The IETF rules on copyright in submitted documents are documented in 760 BCP 78. By submitting an Internet-Draft for publication the authors 761 of the Internet-Draft are agreeing to those rules. This requirement 762 also applies to Internet-Drafts publishes as part of a liaison 763 relationship. Please see BCP 78 for the detailed rules but the 764 following is a brief summary. 766 The IETF copyright-related rules are quite simple. The IETF Trust 767 obtains the non-exclusive perpetual right to publish Internet-Drafts 768 and RFCs from the authors of those documents. Unless a specific 769 notice is included in the submission, the IETF Trust also obtains the 770 right to publish the Internet-Draft as a RFC and the right to produce 771 derivative works based on the material in the submission. The IETF 772 Trust has licensed the content of all such submissions to IETF 773 participants to produce derivative works within the IETF processes. 774 The IETF Trust, in theory, can license others to produce derivative 775 works outside the IETF standards process (e.g., in books, educational 776 materials, other standards groups, etc.) but this is a rare 777 occurrence, and only done in consultation with the IETF community. 779 Authors of comments sent to an IETF mailing list are consenting to 780 the IETF publishing those comments and to the IETF using such 781 comments in its standards process. Authors of liaison statements are 782 consenting to the IETF publishing the statements. 784 Document authors retain all other rights. Document authors are free 785 to do anything else they wish to with their material. 787 8.2 Patent and patent applications 788 The IETF rules relating to non-copyright intellectual property rights 789 (within the IETF processes are documented in BCP 79. By submitting 790 an Internet-Draft for publication the authors of the Internet-Draft 791 are agreeing to those rules. Please see BCP 79 for the detailed 792 rules but the following is a brief summary. 794 The work of the IETF and its working groups frequently involves 795 making choices about which technology to use in a particular 796 situation. Understanding all aspects of a technology, including any 797 intellectual property rights related impacts on the use of a 798 technology, is an important part of deciding what technologies to 799 support. Thus, it is important for the IETF and its working groups 800 to be informed of any intellectual property rights claimed in regards 801 to technologies under consideration. Thus, participants in the IETF 802 process are required to disclose any of their own IPR they personally 803 know about in any contribution to the IETF. 805 In this context, a participant is someone who makes a contribution to 806 the IETF (this includes submitting an Internet-Draft, sending email 807 to an IETF mailing list, and speaking during a discussion in an IETF 808 working group) or otherwise doing something designed to effect the 809 discussion about a technology. 811 Also, in this context, "their own IPR" means any patent or patent 812 application that they, their employer or their sponsor could 813 potentially assert against the technology under discussion. 815 9. Limitation of Liability 816 The IETF makes no representations with respect to and does not 817 warrant the accuracy of any information or any document. Without 818 limiting the foregoing, each party of liaison relationship a agrees 819 to accept the terms of and reproduce any warranty disclaimers or 820 limitations of liability that are included in any reproduction of 821 published material made available to it under this cooperation 822 framework. 824 10. IANA Considerations 825 This document makes no requests of the IANA. [this section to be 826 removed before publication] 828 11. Security Considerations This type of process document does not have 829 any direct effect on the security of the Internet. 831 12. References 833 12.1. Normative references 835 12.2. Informative References 836 RFCs consulted 838 RFC 3113 - 3GPP-IETF Standardization Collaboration. 839 RFC 3131 - 3GPP2-IETF Standardization Collaboration 840 RFC 3975 - OMA-IETF Standardization Collaboration 841 RFC 4052 - IAB Processes for Management of IETF Liaison Relationships 842 RFC 4053 - Procedures for Handling Liaison Statements to and from the 843 IET 844 RFC 4691 - Guidelines for Acting as an IETF Liaison to Another 845 Organization 846 RFC 4965 - CableLabs - IETF Standardization Collaboration 847 RFC 6756 - Internet Engineering Task Force and International 848 Telecommunication Union - Telecommunication Standardization Sector 849 Collaboration Guidelines 850 RFC 7241- The IEEE 802/IETF Relationship 852 Other documents 853 [Tao] The Tao of the IETF, https://www.ietf.org/tao.html 855 13. Author's addresses 857 Scott Bradner 858 Harvard University 859 8 Story St. 860 Cambridge MA 02138 861 USA 863 email: sob@harvard.edu 864 phone: +1 617 495 3864 866 Appendix A - Format of a liaison 868 A. Contents of a Liaison Statement 869 Liaison statements may be very formal or informal, depending on the 870 rules of the body generating them. Any liaison statement, however, 871 will always contain certain information, much as an business letter 872 does. This information will include the following: 874 A.1. Envelope Information 875 The following fields detail properties of the liaison statement. 877 A.1.1. From: 878 The statement will indicate from what body it originates; for 879 example, it may be from, an IETF WG or Area, an ITU-T Study Group, 880 Working Party, or Question, etc. In this document, this body is the 881 "sender". 883 A.1.2. To: 884 The statement will indicate to which body it is. In this document, 885 his body is the "addressee". 887 A.1.3. Title: 888 The statement will contain a short (usually single line) statement of 889 its context and content. 891 A.1.4. Response Contact: 892 The sender will indicate the electronic mail address to which any 893 response should be sent. 895 A.1.5. Technical Contact: 896 The sender will indicate one or more electronic mail addresses 897 (persons or lists) that may be contacted for clarification of the 898 liaison statement. 900 A.1.6. Purpose: 901 A liaison statement generally has one of four purposes and will 902 clearly state its purpose using one of the following labels: 904 For Information: The liaison statement is to inform the addressee of 905 something, and expects no response. 907 For Comment: The liaison statement requests commentary from the 908 addressee, usually within a stated time frame. 910 For Action: The liaison statement requests that the addressee do 911 something on the sender's behalf, usually within a stated time frame. 913 In Response: The liaison statement includes a response to a liaison 914 statement from the peer organization on one or more of its documents 915 and expects no further response. 917 A.1.7. Deadline: 918 Liaison statements that request comment or action will indicate when 919 he comment or action is required. If the addressee cannot accomplish 920 the request within the stated period, courtesy calls for a response 921 offering a more doable deadline or an alternative course of action. 923 A.2. Liaison Content 924 The following fields are the substance of the liaison statement. 925 IETF participants use a wide variety of systems, thus document 926 formats that are not universally readable are problematic. As a 927 result, documents enclosed with the body or attachments should be in 928 PDF, W3C HTML (without proprietary extensions), or ASCII text format. 929 If they were originally in a proprietary format such as Microsoft 930 Word, the file may be sent, but should be accompanied by a generally 931 readable file. 933 A.2.1. Body: 934 As with any business letter, the liaison statement contains 935 appropriate content explaining the issues or questions at hand. 937 A.2.2. Attachments: 938 Attachments, if enclosed, may be in the form of documents sent with 939 he liaison statement or may be URLs to similar documents including 940 Internet-Drafts. 942 Appendix B - The IETF Liaison Tool 944 B. Tools for Handling Liaison Statements 945 Some tools have been developed for the IETF. Development is expected 946 to continue. This section describes the basic tool and its intended 947 use. 949 B.1. Liaison Statements from Other SDOs, Consortia, and Fora to IETF 950 The process of handling a liaison statement is more weighty than 951 handling a business letter because it is important to a relationship 952 with another SDO established by the IAB. To manage liaison 953 statements, the IETF will offer three electronically accessible 954 facilities: a form for submission of liaison statements, a mechanism 955 organizing their contents and making them accessible, and a tracking 956 system. Initially, the tracking system will be a manual procedure 957 used by the liaison manager; in the future, this should be automated. 959 B.1.1. Liaison Statement Submission 960 The IETF Secretariat will provide an electronic method for submission 961 of liaison statements. 963 The liaison statement submission mechanism is a form that requests 964 the information listed in Section 2.2.1 from the user. 966 Submission of that information results in the following actions: 968 o creation of a display mechanism containing the envelope data in 969 Section 2.2.1.1 and URLs pointing to the items from Section 970 2.2.1.2, an indication whether the liaison statement has been 971 replied to, and if so, on what date, 973 o the addition of a URL to the "outstanding liaison statements" 974 summary mechanism, 976 o when an automated tracking system has been implemented, a tickler/ 977 status entry in the tracking system, assigned to the relevant 978 chair or AD, 980 o an email to the assignee copying 982 * the liaison statement's technical contacts 984 * The supervisor of the assignee (if it is to a WG, the relevant 985 ADs; if to an AD, the IETF Chair), 987 * The liaison manager for the sending SDO, 989 * an alias associated with the assignee (WG/BOF or other open 990 mailing list, Area Directorate, IESG, IAB, etc.) 992 This email should contain the URL to the liaison statement mechanism, 993 text indicating that the liaison statement has arrived, requests 994 appropriate consideration, and if a deadline is specified, a reply by 995 the deadline. 997 The assignee has the capability of interacting with the liaison 998 manager and the tracking system (once implemented), including 999 replying, changing dates, reassignment, closing the liaison statement 1000 process, etc. 1002 The liaison manager or tracking system's "tickle" function 1003 periodically reminds the assignee by email that the liaison statement 1004 has not yet been closed. This tickle email copies all of the above 1005 except the associated mailing alias. 1007 B.1.2. Mechanism for Displaying Liaison Statements 1008 The IETF site contains a section for current liaison statement 1009 activity. This consists of: 1010 o A submission mechanism, 1012 o A status/management mechanism for each active or recently closed 1013 liaison statement, and zero or more associated files. 1015 The status/management mechanism contains a simple frame, showing the 1016 title of the liaison statement, the URL for its mechanism, and the 1017 organizations it is from and to. 1019 The display for liaison statement itself contains: 1021 o the liaison statement envelope information (Section 2.2.1), 1023 o direct content (Section 2.2.1), 1025 o URLs for the various associated files 1027 o current status of the liaison statement: to whom it is assigned, 1028 its due date, and its status, 1030 o pointer to the liaison manager and tracking system entry for the 1031 liaison statement. 1033 o reply-generation mechanism (see Section 3.2.2.4) 1035 --- to do 1036 need to also cover 1037 use of email to liaisons@ietf.org as a backstop when the tool can't 1038 be 1039 how someone outside the IETF gets write access to the tool 1040 (noting that this is often a secretariat function at the other SDO, 1041 not necessarily a liaison manager function) 1042 how someone inside the IETF gets write access to the tool