idnits 2.17.1 draft-iab-liaison-mgt-03.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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 367. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 383), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages 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 (December 9, 2004) is 7072 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: 7 errors (**), 0 flaws (~~), 3 warnings (==), 8 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: June 9, 2005 Internet Architecture Board 5 IAB 6 December 9, 2004 8 IAB Processes for management of IETF liaison relationships 9 draft-iab-liaison-mgt-03 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 9, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document discusses the procedures used by the IAB to establish 43 and maintain liaison relationships between the IETF and other 44 Standards Development Organizations (SDOs), consortia and industry 45 fora. This document also discusses the appointment and 46 responsibilities of IETF liaison managers and representatives, and 47 the expectations of the IAB for organizations with whom liaison 48 relationships are established. 50 Table of Contents 52 1. Liaison Relationships and Personnel . . . . . . . . . . . . . 3 53 2. Aspects of Liaisons and Liaison Management . . . . . . . . . . 5 54 2.1 Liaison Relationships . . . . . . . . . . . . . . . . . . 5 55 2.2 Liaison Manager . . . . . . . . . . . . . . . . . . . . . 5 56 2.3 Liaison Representatives . . . . . . . . . . . . . . . . . 6 57 2.4 Liaison Communications . . . . . . . . . . . . . . . . . . 6 58 3. Summary of IETF Liaison Manager Responsibilities . . . . . . . 7 59 4. Approval and Transmission of Liaison Statements . . . . . . . 8 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 64 7.2 Informative References . . . . . . . . . . . . . . . . . . . 11 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 66 Intellectual Property and Copyright Statements . . . . . . . . 12 68 1. Liaison Relationships and Personnel 70 The IETF, as an organization, has the need to engage in direct 71 communication or joint endeavors with various other formal 72 organizations. For example, the IETF is one of several Standards 73 Development Organizations, or SDOs, and all SDOs including the IETF 74 find it increasingly necessary to communicate and coordinate their 75 activities involving Internet-related technologies. This is useful 76 in order to avoid overlap in work efforts and to manage interactions 77 between their groups. In cases where there is formalization of a 78 mutual effort to communicate and coordinate activities, these 79 relationships are generically referred to as "liaison relationships". 81 In such cases, a person from the IETF is designated to manage a given 82 liaison relationship; that person is generally called the "IETF 83 liaison manager" to the other organization. When the liaison 84 relationship is expected to encompass a complex or broad range of 85 activities, more people may be designated to undertake some portions 86 of the communications, coordinated by the liaison manager. Often, 87 the other organization will similarly designate their own liaison 88 manager to the IETF. 90 This document is chiefly concerned with: 92 o the establishment and maintenance of liaison relationships, and 93 o the appointment and responsibilities of IETF liaison managers and 94 representatives. 96 The management of other organizations' liaison managers to the IETF, 97 whether or not in the context of a liaison relationship, is outside 98 the scope of this document. 100 The IETF has chartered the Internet Architecture Board to manage 101 liaison relationships. Consistent with its charter ([2]), the IAB 102 acts as representative of the interests of the IETF and the Internet 103 Society in technical liaison relationships with other organizations 104 concerned with standards and other technical and organizational 105 issues relevant to the world-wide Internet. Liaison relationships 106 are kept as informal as possible and must be of demonstrable value to 107 the IETF's technical mandate. Individual participants of the IETF 108 are appointed as liaison managers or representatives to other 109 organizations by the IAB. 111 In general, a liaison relationship is most valuable when there are 112 areas of technical development of mutual interest. For the most 113 part, SDO's would rather leverage existing work done by other 114 organizations than recreate it themselves (and would like the same 115 done with respect to their own work). Establishing a liaison 116 relationship can provide the framework for ongoing communications to 118 o prevent inadvertent duplication of effort, without obstructing 119 either organization from pursuing its own mandate; 120 o provide authoritative information of one organization's 121 dependencies on the other's work. 123 2. Aspects of Liaisons and Liaison Management 125 2.1 Liaison Relationships 127 A liaison relationship is set up when it is mutually agreeable and 128 needed for some specific purpose, in the view of the other 129 organization, the IAB, and the IETF participants conducting the work. 130 There is no set process or form for this; the IETF participants and 131 the peer organization approach the IAB, and after discussion come to 132 an agreement to form the relationship. In some cases, the intended 133 scope and guidelines for the collaboration are documented 134 specifically (e.g., see [3], [4], and [5]). 136 The IAB's expectation in setting up the relationship is that there 137 will be a mutual exchange of views and discussion of the best 138 approach to undertaking new standardization work items. Any work 139 items resulting for the IETF will be undertaken in the usual IETF 140 procedures, defined in [1]. The peer organization often has 141 different organizational structure and different procedures than the 142 IETF, which will require some flexibility on the part of both 143 organizations to accommodate. The IAB expects that each organization 144 will use the relationship carefully, allowing time for the processes 145 it requests to occur in the other organization and not making 146 unreasonable demands. 148 2.2 Liaison Manager 150 As described above, most work on mutually interesting topics will be 151 carried out in the usual way within the IETF and the peer 152 organization. Therefore, most communications will be informal in 153 nature (e.g., working group, mailing list discussions, etc). 155 An important function of the liaison manager is to ensure that 156 communication is maintained, is productive, and is timely. He or she 157 may use any applicable businesslike approach, from private 158 communications to public communications, and bringing in other 159 parties as needed. If a communication from a peer organization is 160 addressed to an inappropriate party, such as being sent to the 161 working group but not copying the AD or being sent to the wrong 162 working group, the liaison manager will help redirect or otherwise 163 augment the communication. 165 IETF liaison managers should also communicate and coordinate with 166 other liaison managers where concerned technical activities overlap. 168 Since the IAB is ultimately responsible for liaison relationships, 169 anyone who has a problem with a relationship (whether an IETF 170 participant or a person from the peer organization) should first 171 consult the IAB's designated liaison manager, and if that does not 172 result in a satisfactory outcome, the IAB itself. 174 2.3 Liaison Representatives 176 The liaison manager is, specifically, a representative of the IETF 177 for the purposes of managing the liaison relationship. There may be 178 occasion to identify other representatives for the same relationship. 179 For example, if the area of mutual work is extensive, it might be 180 appropriate to name several people to be liaison representatives to 181 different parts of the other organization. Or, it might be 182 appropriate to name a liaison representative to attend a particular 183 meeting. 185 These other liaison representatives are selected by the IAB and work 186 in conjunction (and close communication) with the liaison manager. 187 In some cases, this may also require communication and coordination 188 with other liaison managers or representatives where concerned 189 technical activities overlap. The specific responsibilities of the 190 liaison representative will be identified at the time of appointment. 192 2.4 Liaison Communications 194 Communications between organizations use a variety of formal and 195 informal channels. The stated preference of the IETF, which is 196 largely an informal organization, is to use informal channels, as 197 these have historically worked well to expedite matters. In some 198 cases, however, a more formal communication is appropriate, either as 199 an adjunct to the informal channel, or in its place. In the case of 200 formal communications, the established procedures of many 201 organizations use a form known as a "liaison statement". Procedures 202 for sending, managing, and responding to liaison statements are 203 discussed in [6]. 205 3. Summary of IETF Liaison Manager Responsibilities 207 While the requirements will certainly vary depending on the nature of 208 the peer organization and the type of joint work being undertaken, 209 the general expectations of a liaison manager appointed by the IAB 210 are as follows: 212 o Attend relevant meetings of the peer organization as needed and 213 report back to the appropriate IETF organization any material 214 updates. 215 o Carry any messages from the IETF to the peer organization, when 216 specifically instructed. Generally, these communications 217 "represent the IETF", and due care (and consensus) must be applied 218 in their construction. 219 o Prepare occasional updates -- e.g., to the IAB, an AD, a WG. The 220 target of these updates will generally be identified upon 221 appointment. 222 o Oversee delivery of liaison statements addressed to the IETF, 223 ensuring that they reach the appropriate destination within the 224 IETF, and work to ensure that whatever relevant response from the 225 IETF is created and sent in a timely fashion. 226 o Work with the other organization to ensure that the IETF's liaison 227 statements are appropriately directed and responded to in a timely 228 fashion. 229 o Communicate and coordinate with other IETF liaison managers and 230 representatives where concerned technical activities overlap. 232 4. Approval and Transmission of Liaison Statements 234 It is important that appropriate leadership review be made of 235 proposed IETF liaison statements and that those who write such 236 statements who claim to be speaking on behalf of IETF are truly 237 representing IETF views. 239 All outgoing liaison statements will be copied to IETF Secretariat 240 using procedures defined in [6] or its successors. 242 For a liaison statement generated on behalf of an IETF working group, 243 the working group chair(s) must create a statement based on 244 appropriate discussions within the working group to ensure working 245 group consensus for the position(s) presented. The chair(s) must 246 have generated, or must agree with the sending of the liaison 247 statement, and must advise the Area Director(s) that the liaison 248 statement has been sent by copying the appropriate Area Directors on 249 the message. 251 For a liaison statement generated on behalf of an IETF Area, the Area 252 Director(s) must have generated or must agree with the sending of the 253 liaison statement. In the case that the liaison statement is not 254 sent by the Area Directors, their agreement must have been obtained 255 in advance and is confirmed by copying the Area Directors on the 256 message. 258 For a liaison statement generated on behalf of the IETF as a whole, 259 the IETF Chair must have generated or must agree with the sending of 260 the liaison statement. In the case that the liaison statement is not 261 sent by the IETF Chair then his or her agreement must be obtained in 262 advance and is confirmed by copying the IETF Chair on the message. 264 For a liaison statement generated by the IAB, the IAB Chair must have 265 generated or must agree with the sending of the liaison statement. 266 In the case that the liaison statement is not sent by the IAB Chair, 267 then his or her agreement must be obtained in advance and is 268 confirmed by copying the IAB Chair on the message. 270 In cases where prior agreement was not obtained as outlined above, 271 and the designated authority (Area Directory, IETF Chair, or IAB 272 Chair) in fact does not agree with the message, they will follow up 273 as appropriate, including emitting a revised liaison statement if 274 necessary. Clearly, this is a situation best avoided by assuring 275 appropriate agreement in advance of sending the liaison message. 277 5. Security Considerations 279 The security of the Internet is not threatened by these procedures. 281 6. Acknowledgements 283 This document was developed as part of a conversation regarding the 284 management of [6], and the authors of that document contributed 285 significantly to it. Also, this version of the document has been 286 improved over its predecessor by several suggestions from Stephen J. 287 Trowbridge, Peter Saint-Andre, Michael Patton, Bert Wijnen, Fred 288 Baker, Scott Bradner, Scott Brim, Avri Doria, Allison Mankin, Thomas 289 Narten, Russ Housley and Dan Romasanu. 291 Members of the IAB at the time of approval of this document were: 293 Bernard Aboba 294 Harald Alvestrand (IETF chair) 295 Rob Austein 296 Leslie Daigle (IAB chair) 297 Patrik Faltstrom 298 Sally Floyd 299 Jun-ichiro Itojun Hagino 300 Mark Handley 301 Bob Hinden 302 Geoff Huston (IAB Executive Director) 303 Eric Rescorla 304 Pete Resnick 305 Jonathan Rosenberg 307 7. References 309 7.1 Normative References 311 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 312 9, RFC 2026, October 1996. 314 [2] Internet Architecture Board and B. Carpenter, "Charter of the 315 Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000. 317 7.2 Informative References 319 [3] Rosenbrock, K., Sanmugam, R., Bradner, S. and J. Klensin, 320 "3GPP-IETF Standardization Collaboration", RFC 3113, June 2001. 322 [4] Bradner, S., Calhoun, P., Cuschieri, H., Dennett, S., Flynn, G., 323 Lipford, M. and M. McPheters, "3GPP2-IETF Standardization 324 Collaboration", RFC 3131, June 2001. 326 [5] Fishman, G. and S. Bradner, "Internet Engineering Task Force and 327 International Telecommunication Union - Telecommunications 328 Standardization Sector Collaboration Guidelines", RFC 3356, 329 August 2002. 331 [6] Trowbridge, S., Bradner, S. and F. Baker, "Procedure for 332 Handling Liaison Statements Between Standards Bodies", June 333 2004. 335 Authors' Addresses 337 Leslie Daigle 338 Editor 340 Internet Architecture Board 341 IAB 343 EMail: iab@iab.org 345 Intellectual Property Statement 347 The IETF takes no position regarding the validity or scope of any 348 Intellectual Property Rights or other rights that might be claimed to 349 pertain to the implementation or use of the technology described in 350 this document or the extent to which any license under such rights 351 might or might not be available; nor does it represent that it has 352 made any independent effort to identify any such rights. Information 353 on the procedures with respect to rights in RFC documents can be 354 found in BCP 78 and BCP 79. 356 Copies of IPR disclosures made to the IETF Secretariat and any 357 assurances of licenses to be made available, or the result of an 358 attempt made to obtain a general license or permission for the use of 359 such proprietary rights by implementers or users of this 360 specification can be obtained from the IETF on-line IPR repository at 361 http://www.ietf.org/ipr. 363 The IETF invites any interested party to bring to its attention any 364 copyrights, patents or patent applications, or other proprietary 365 rights that may cover technology that may be required to implement 366 this standard. Please address the information to the IETF at 367 ietf-ipr@ietf.org. 369 Disclaimer of Validity 371 This document and the information contained herein are provided on an 372 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 373 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 374 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 375 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 376 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 377 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 379 Copyright Statement 381 Copyright (C) The Internet Society (2004). This document is subject 382 to the rights, licenses and restrictions contained in BCP 78, and 383 except as set forth therein, the authors retain all their rights. 385 Acknowledgment 387 Funding for the RFC Editor function is currently provided by the 388 Internet Society.