idnits 2.17.1 draft-iab-liaison-mgt-02.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 323. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 339), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** 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 == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 11) being 69 lines == 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 (July 1, 2004) is 7237 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 (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Daigle 2 Internet-Draft Editor 3 Expires: December 30, 2004 Internet Architecture Board 4 IAB 5 July 1, 2004 7 IAB Processes for management of liaison relationships 8 draft-iab-liaison-mgt-02 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 30, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document discusses the procedures the IAB uses to select 42 organizations to form and maintain liaison relationships with. It 43 further discusses the expectations that the IAB has of such 44 organizations and of the people assigned to manage those 45 relationships. 47 Table of Contents 49 1. Liaison Relationships and Personnel . . . . . . . . . . . . . 3 50 2. Aspects of Liaisons and Liaison Management . . . . . . . . . . 5 51 2.1 Liaison Relationships . . . . . . . . . . . . . . . . . . 5 52 2.2 Liaison Manager . . . . . . . . . . . . . . . . . . . . . 5 53 2.3 Liaison Representatives . . . . . . . . . . . . . . . . . 6 54 2.4 Liaison Communications . . . . . . . . . . . . . . . . . . 6 55 3. Summary of IETF Liaison Manager Responsibilities . . . . . . . 7 56 4. Approval and Transmission of Liaison Statements . . . . . . . 8 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 58 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 61 7.2 Informative References . . . . . . . . . . . . . . . . . . . 11 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 63 Intellectual Property and Copyright Statements . . . . . . . . 12 65 1. Liaison Relationships and Personnel 67 The IETF, as an organization, has the need to engage in direct 68 communication or joint endeavors with various other formal 69 organizations. For example, the IETF is one of several Standards 70 Development Organizations, or SDOs, and all SDOs including the IETF 71 find it increasingly necessary to communicate and coordinate their 72 activities involving Internet-related technologies. This is useful 73 in order to avoid overlap in work efforts and to manage interactions 74 between their groups. In cases where there is formalization of a 75 mutual effort to communicate and coordinate activities, these 76 relationships are generically referred to as "liaison relationships". 78 In such cases, a person from the IETF is designated to manage a given 79 liaison relationship; that person is generally called the "IETF 80 liaison manager" to the other organization. Often, the other 81 organization will similarly designate their own liaison manager to 82 the IETF. 84 This document is chiefly concerned with: 86 o the establishment and maintenance of liaison relationships, and 87 o the appointment and responsibilities of IETF liaison managers and 88 representatives. 90 The management of other organizations' liaison managers to the IETF, 91 whether or not in the context of a liaison relationship, is outside 92 the scope of this document. 94 The IETF has chartered the Internet Architecture Board to manage 95 liaison relationships. Consistent with its charter ([2]), the IAB 96 acts as representative of the interests of the IETF and the Internet 97 Society in technical liaison relationships with other organizations 98 concerned with standards and other technical and organizational 99 issues relevant to the world-wide Internet. Liaison relationships 100 are kept as informal as possible and must be of demonstrable value in 101 improving the quality of IETF specifications. Individual members of 102 the IETF are appointed as liaison managers or representatives to 103 other organizations by the IAB or IESG as appropriate. 105 In general, a liaison relationship is most valuable when there are 106 areas of technical development of mutual interest. For the most 107 part, SDO's would rather leverage existing work done by other 108 organizations than recreate it themselves (and they would like their 109 own standards work used rather than abused/recreated!). Establishing 110 a liaison relationship can provide the framework for ongoing 111 communications to 112 o prevent inadvertent duplication of effort, without obstructing 113 either organization from pursuing its own mandate; 114 o provide authenticated information of one organization's 115 dependencies on the other's work. 117 2. Aspects of Liaisons and Liaison Management 119 2.1 Liaison Relationships 121 A liaison relationship is set up when it is mutually agreeable and 122 needed for some specific purpose, in the view of the other 123 organization, the IAB, and the IETF participants conducting the work. 124 There is no set process or form for this; the IETF participants and 125 the peer organization approach the IAB, and after discussion come to 126 an agreement to form the relationship. In some cases, the intended 127 scope and guidelines for the collaboration are documented 128 specifically (e.g., see [3], [4], and [5]). 130 The IAB's expectation in setting up the relationship is that there 131 will be a mutual exchange of views and discussion of the best 132 approach to undertaking new standardization work items. Any work 133 items resulting for the IETF will be undertaken in the usual IETF 134 procedures, defined in [1]. The peer organization often has 135 different organizational structure and different procedures than the 136 IETF, which will require some flexibility on the part of both 137 organizations to accommodate. The IAB expects that each organization 138 will use the relationship carefully, allowing time for the processes 139 it requests to occur in the other organization and not making 140 unreasonable demands. 142 2.2 Liaison Manager 144 As described above, most work on mutually interesting topics will be 145 carried out in the usual way within the IETF and the peer 146 organization. Therefore, most communications will be informal in 147 nature (e.g., working group, mailing list discussions, etc). 149 An important function of the liaison manager is to ensure that 150 communication is maintained, is productive, and is timely. He or she 151 may use any businesslike approach to that necessary, from private 152 communications to public communications, and bringing in other 153 parties as needed. If a communication from a peer organization is 154 addressed to an inappropriate party, such as being sent to the 155 working group but not copying the AD or being sent to the wrong 156 working group, the liaison manager will help redirect or otherwise 157 augment the communication. 159 Since the IAB is ultimately responsible for liaison relationships, 160 anyone who has a problem with a relationship (whether an IETF 161 participant or a person from the peer organization) should first 162 consult the IAB's designated liaison manager, and if that does not 163 result in a satisfactory outcome, the IAB itself. 165 2.3 Liaison Representatives 167 The liaison manager is, specifically, a representative of the IETF 168 for the purposes of managing the liaison relationship. There may be 169 occasion to identify other representatives for the same relationship. 170 For example, if the area of mutual work is extensive, it might be 171 appropriate to name several people to be liaison representatives to 172 different parts of the other organization. Or, it might be 173 appropriate to name a liaison representative to attend a particular 174 meeting. 176 These other liaison representatives are selected by the IAB and work 177 in conjunction (and close communication) with the liaison manager. 178 The specific responsibilities of the liaison representative will be 179 identified at the time of appointment. 181 2.4 Liaison Communications 183 Communications between organizations use a variety of formal and 184 informal channels. The stated preference of the IETF, which is 185 largely an informal organization, is to use informal channels, as 186 these have historically worked well to expedite matters. In some 187 cases, however, more formal communications are appropriate. In such 188 cases, the established procedures of many organizations use a form 189 known as a "liaison statement". Procedures for sending, managing, 190 and responding to liaison statements are discussed in [6]. 192 3. Summary of IETF Liaison Manager Responsibilities 194 While the requirements will certainly vary depending on the nature of 195 the peer organization and the type of joint work being undertaken, 196 the general expectations of a liaison manager appointed by the IAB 197 are as follows: 199 o Attend relevant meetings of the peer organization as needed and 200 report back to the appropriate IETF organization any material 201 updates. 202 o Carry any messages from the IETF to the peer organization, when 203 specifically instructed. Generally, these communications 204 "represent the IETF", and due care (and consensus) must be applied 205 in their construction. 206 o Prepare occasional updates -- e.g., to the IAB, an AD, a WG. The 207 target of these updates will generally be identified upon 208 appointment. 209 o Oversee delivery of liaison statements addressed to the IETF, 210 ensuring that they reach the appropriate destination within the 211 IETF, and work to ensure that whatever relevant response from the 212 IETF is created and sent in a timely fashion. 213 o Work with the other organization to ensure that the IETF's liaison 214 statements are appropriately directed and responded to in a timely 215 fashion. 217 4. Approval and Transmission of Liaison Statements 219 It is important that appropriate leadership review be made of 220 proposed IETF liaison statements and that those who write such 221 statements who claim to be speaking on behalf of IETF are truly 222 representing IETF views. 224 All outgoing liaison statements will be copied to IETF Secretariat by 225 the liaison statement page. 227 For a liaison statement generated on behalf of an IETF working group, 228 the working group chair(s) must have generated, or must agree with 229 the sending of the liaison statement, and must advise the Area 230 Director(s) that the liaison statement has been sent by copying the 231 appropriate Area Directors on the message. 233 For a liaison statement generated on behalf of an IETF Area, the Area 234 Director(s) must have generated or must agree with the sending of the 235 liaison statement. If the liaison statement is not sent by the Area 236 Directors then their agreement is indicated by copying the Area 237 Directors on the message. 239 For a liaison statement generated on behalf of the IETF as a whole, 240 the IETF Chair must have generated or must agree with the sending of 241 the liaison statement. If the liaison statement is not sent by the 242 IETF Chair then his or her agreement is indicated by copying the IETF 243 Chair on the message. 245 For a liaison statement generated by the IAB, the IAB Chair must have 246 generated or must agree with the sending of the liaison statement. 247 If the liaison statement is not sent by the IAB Chair, then his or 248 her agreement is indicated by copying the IAB Chair on the message. 250 5. Security Considerations 252 The security of the Internet is not threatened by these procedures. 254 6. Acknowledgements 256 This document was developed as part of a conversation regarding the 257 management of [6], and the authors of that document contributed 258 significantly to it. Also, this version of the document has been 259 improved over its predecessor by several suggestions from Stephen J. 260 Trowbridge, Peter Saint-Andre, Michael Patton, Bert Wijnen, Fred 261 Baker and Scott Bradner. 263 7. References 265 7.1 Normative References 267 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 268 9, RFC 2026, October 1996. 270 [2] Internet Architecture Board and B. Carpenter, "Charter of the 271 Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000. 273 7.2 Informative References 275 [3] Rosenbrock, K., Sanmugam, R., Bradner, S. and J. Klensin, 276 "3GPP-IETF Standardization Collaboration", RFC 3113, June 2001. 278 [4] Bradner, S., Calhoun, P., Cuschieri, H., Dennett, S., Flynn, G., 279 Lipford, M. and M. McPheters, "3GPP2-IETF Standardization 280 Collaboration", RFC 3131, June 2001. 282 [5] Fishman, G. and S. Bradner, "Internet Engineering Task Force and 283 International Telecommunication Union - Telecommunications 284 Standardization Sector Collaboration Guidelines", RFC 3356, 285 August 2002. 287 [6] Trowbridge, S., Bradner, S. and F. Baker, "Procedure for 288 Handling Liaison Statements Between Standards Bodies", June 289 2004. 291 Authors' Addresses 293 Leslie Daigle 294 Editor 296 Internet Architecture Board 297 IAB 299 EMail: iab@iab.org 301 Intellectual Property Statement 303 The IETF takes no position regarding the validity or scope of any 304 Intellectual Property Rights or other rights that might be claimed to 305 pertain to the implementation or use of the technology described in 306 this document or the extent to which any license under such rights 307 might or might not be available; nor does it represent that it has 308 made any independent effort to identify any such rights. Information 309 on the procedures with respect to rights in RFC documents can be 310 found in BCP 78 and BCP 79. 312 Copies of IPR disclosures made to the IETF Secretariat and any 313 assurances of licenses to be made available, or the result of an 314 attempt made to obtain a general license or permission for the use of 315 such proprietary rights by implementers or users of this 316 specification can be obtained from the IETF on-line IPR repository at 317 http://www.ietf.org/ipr. 319 The IETF invites any interested party to bring to its attention any 320 copyrights, patents or patent applications, or other proprietary 321 rights that may cover technology that may be required to implement 322 this standard. Please address the information to the IETF at 323 ietf-ipr@ietf.org. 325 Disclaimer of Validity 327 This document and the information contained herein are provided on an 328 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 329 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 330 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 331 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 332 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 333 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 335 Copyright Statement 337 Copyright (C) The Internet Society (2004). This document is subject 338 to the rights, licenses and restrictions contained in BCP 78, and 339 except as set forth therein, the authors retain all their rights. 341 Acknowledgment 343 Funding for the RFC Editor function is currently provided by the 344 Internet Society.