idnits 2.17.1 draft-lear-liaison-tool-rqts-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 18, 2013) is 4085 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5322' is defined on line 371, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft Cisco Systems GmbH 4 Intended status: Informational S. Dawkins, Ed. 5 Expires: August 22, 2013 Huawei 6 February 18, 2013 8 Requirements for the IETF Liaison Statement Tool 9 draft-lear-liaison-tool-rqts-00 11 Abstract 13 This memo specifies requirements for the liaison statement tool used 14 by IETF working group chairs, IESG members, and the IAB, as well as 15 representatives of organizations that liaise to these IETF entities. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on August 22, 2013. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Overall Processing of Liaison Statements . . . . . . . . . . . 5 54 2.1. Inbound Liaison Statements . . . . . . . . . . . . . . . . 5 55 2.2. Outbound Liaison Statements . . . . . . . . . . . . . . . 6 56 2.3. Description of Liaison Statement Elements . . . . . . . . 7 57 3. Specific Tooling Requirements . . . . . . . . . . . . . . . . 10 58 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 61 7. Normative References . . . . . . . . . . . . . . . . . . . . . 14 62 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 15 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 65 1. Introduction 67 The Internet Architecture Board (IAB) acts as representative of the 68 interests of the IETF and the Internet Society in technical liaison 69 relationships with other organizations concerned with standards and 70 other technical and organizational issues relevant to the world-wide 71 Internet, as part of its chartered responsibilities [RFC2850]. As 72 part of that responsibility, the IAB approves requests for IETF 73 liaison relationships with these organizations, and the IAB appoints 74 individual IETF participants as liaison managers using the process 75 described in [RFC4052]. 77 From time to time the IETF and IAB exchange liaison statements with 78 other organizations. These official statements must be preserved as 79 part of the historical record of the IETF, and often require that 80 responses to such statements must be tracked. It is the job of the 81 liaison manager to track those actions. A tool exists to help that 82 process, and to direct messages to the correct set of recipients. 83 This memo specifies a detailed set of requirements for the evolution 84 of that tool. 86 The IETF process for sending and receiving liaison statements is 87 defined in [RFC4053], which describes the basic flow of a liaison 88 statement. To briefly summarize, there are inbound and outbound 89 liaison statements. Inbound statements are issued by organizations 90 wishing to communicate with the IETF or to respond to liaison 91 statements sent to them by the IETF. Outbound statements are issued 92 by people within the IETF wishing to officially communicate with 93 another organization or wishing to respond to a liaison statement 94 received from another organization. Different groups of people are 95 authorized to issue such statements. When liaison statements are 96 issued, certain groups of people are meant to be informed of the 97 statement. 99 Upon receipt of an inbound liaison statement, certain response 100 actions may be desired by a particular date. Therefore, a liaison 101 statement management system has aspects of issue tracking, a role- 102 based statement distribution system, and a web service where people 103 can access liaison statements. The remainder of this document will 104 delve into the flow in detail, and describe data elements required to 105 process liaison statements. This memo expands on descriptions in 106 [RFC4053] for the purposes of further elaborating the data elements 107 of a liaison statement. 109 The IAB's guidance to liaison managers is available in [RFC4691]. 111 1.1. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT",ccccc "RECOMMENDED", "MAY", and "OPTIONAL" in 115 this document are to be interpreted as described in RFC 2119 116 [RFC2119]. 118 2. Overall Processing of Liaison Statements 120 ALL liaison statements that are received by the liaison tool, whether 121 inbound or outbound, MUST be posted to a web site for public 122 inspection. A liaison statement MUST be kept in perpetuity, as 123 mentioned in Section 2.4 of [RFC4053]. 125 Liaison statements may be for information, comment, action, or a 126 reply to an earlier statement. Liaison statements that are for 127 comment or action will have a response deadline associated with them. 129 EDITOR'S NOTE: Scott Bradner asked if we track response deadlines on 130 all liaison statements, or only on inbound liaison statements. 131 Thoughts? 133 The format of a liaison statement is described in Section 2.2.1 of 134 [RFC4053]. The following data elements are further elaborated for 135 purposes of understanding when they are used. 137 2.1. Inbound Liaison Statements 139 An inbound liaison statement comes from an external organization. It 140 is destined to either the IETF, the IAB, one or more Area Directors, 141 one or more IETF working groups, or exceptionally other groups, such 142 as the IESG or the IRTF. Upon receipt the liaison system MUST 143 transmit the liaison statement to the correct destination group, if 144 identified, to relevant responsible Area Directors for the working 145 groups, as applicable, and to the relevant liaison managers, based on 146 the source of the liaison statement. The liaison management system 147 MUST transmit inbound liaisons to those individuals and email lists 148 associated with the IETF and IAB, and working groups. It is not 149 required that inbound liaison statements be transmitted to every 150 destination listed in the "To" or "Cc" fields of a liaison statement. 152 Representatives from external organizations sending an inbound 153 liaison statement must be known in advance, and must request an IETF 154 tools system password from the IETF Tools Password web page [1]. 155 Each representative must be associated with an external organization, 156 and the IETF liaison manager for this external organization requests 157 that the external representative's e-mail address be associated with 158 the external organization. 160 If an inbound liaison statement is marked "for action" or "for 161 comment", then one individual SHALL be assigned as having 162 responsibility for ensuring that the liaison statement is addressed. 163 This assignment SHALL be made automatically by the tool using a list 164 of individuals maintained by the IETF Secretariat for this purpose. 165 If there is no individual listed for the named IETF destination of 166 the liaison statement, or if there are multiple IETF destinations 167 involved, the responsibility shall be assigned to the IETF's liaison 168 manager responsible for the liaison relationship with the 169 organization originating the liaison. 171 An open action awaiting response may be closed in one of two ways: 172 administratively by the action owner, or through the action of a 173 posting a response liaison statement. Periodically the liaison 174 management system SHALL remind individuals who are responsible for 175 tracking liaison statements for action when they have open actions. 176 Liaison managers for the organization MUST also receive such 177 reminders, even if they are not the assigned owner. There may be 178 more than one liaison manager for an organization. 180 2.2. Outbound Liaison Statements 182 Outbound liaison statements may only be sent by those specified in 183 Section 4 of [RFC4052]. Any tool MUST impose appropriate access 184 control for this purpose. Furthermore, when a liaison statement is 185 transmitted, the tool SHALL send appropriate copies in accordance 186 with Section 3.1.1 of [RFC4053], in addition to anyone else the 187 person sending the liaison statement deems appropriate. 189 2.3. Description of Liaison Statement Elements 191 +-------------+--------------+------------+-------------------------+ 192 | Field | Format | When | Purpose | 193 | | | required | | 194 +-------------+--------------+------------+-------------------------+ 195 | Liaison-Id | A short | Always | Identifies the liaison | 196 | | identifier | | statement that is to be | 197 | | uniquely | | tracked. Is prefixed | 198 | | identifying | | with "In" or "Out". | 199 | | this liaison | | | 200 | | statement | | | 201 | | | | | 202 | Pointer to | URL pointing | Always | Locates the liaison | 203 | the liaison | to the | | statement that is to be | 204 | statement | liaison | | tracked. Includes the | 205 | | statement in | | Liaison-ID as part of | 206 | | the IETF | | the URL. | 207 | | liaison | | | 208 | | statement | | | 209 | | repository. | | | 210 | | | | | 211 | Source or | UTF-8 | Always | See RFC 4053 Section | 212 | From: | | | 2.2.1. | 213 | | | | | 214 | To or | UTF-8 | Always | See RFC 4053 Section | 215 | Addresse | | | 2.2.1. | 216 | | | | | 217 | Response | One or more | Always | See RFC 4053 Section | 218 | Contact | name-addr | | 2.2.1. | 219 | | from | | | 220 | | RFC-5322 | | | 221 | | | | | 222 | Date | date from | Always | See RFC 4053 Section | 223 | | RFC-5322 | | 2.2.1. | 224 | | | | | 225 | Purpose | "For action" | Always | See RFC 4053 Section | 226 | | / "For | | 2.2.1. | 227 | | Information" | | | 228 | | / "In | | | 229 | | Response" / | | | 230 | | "For | | | 231 | | Comment" | | | 232 | | | | | 233 | Title | UTF-8 | Always | RFC 4053 Section 2.2.1. | 234 | | | | | 235 | Deadline | date from | When | RFC 4053 Section 2.2.1. | 236 | | RFC-5322 | Purpose is | | 237 | | | "For | | 238 | | | Action" or | | 239 | | | "For | | 240 | | | Comment" | | 241 | | | | | 242 | Liaison | From | Always | See RFC 4053 Section | 243 | Content | RFC-5322 | | 2.2.1. | 244 | | definition | | | 245 | | of "body" | | | 246 | | | | | 247 | Attachments | MIME | Optional | | 248 | | | | | 249 | Cc List | One or more | optional | A list of addresses to | 250 | | name-addr | | CC the liaison when it | 251 | | from | | is transmitted. | 252 | | RFC-5322 | | | 253 | | | | | 254 | Owner | name-addr | For | Someone who will manage | 255 | | from | inbound | the liaison statement. | 256 | | RFC-5322 | liaison | | 257 | | | statements | | 258 | | | when they | | 259 | | | are "For | | 260 | | | Action" or | | 261 | | | "For | | 262 | | | Comment". | | 263 | | | | | 264 | Response | URL pointing | When a | This is the outbound | 265 | liaison | to the | reply has | liaison statement that | 266 | statement | response in | been | is in response to the | 267 | | the IETF | generated | inbound liaison | 268 | | liaison | | statement. Note that | 269 | | statement | | more than one outbound | 270 | | repository. | | liaison statement may | 271 | | | | be associated with an | 272 | | | | inbound liaison | 273 | | | | statement. | 274 | | | | | 275 | Status | "awaiting | Always | Generated based on type | 276 | | response" / | | of liaison, date, | 277 | | "no response | | whether a response has | 278 | | required" / | | been generated, and | 279 | | "responded | | input from the owner as | 280 | | to" / "no | | to whether action will | 281 | | action will | | be taken | 282 | | be taken" / | | | 283 | | "overdue" | | | 284 +-------------+--------------+------------+-------------------------+ 286 Liaison Statement Elements 288 3. Specific Tooling Requirements 290 The IETF entities who may send a liaison statement to an external 291 organization have a hierarchy. The tool must allow entities higher 292 in the hierarchy to send liaison statements on behalf of an entity 293 lower in the hierarchy (for example, a routing Area Director might 294 send a liaison statement on behalf of a working group chair). These 295 liaison statements should include both the actual sender and the 296 person who will be responsible for further interaction with the 297 external organization. 299 Many peer standards organizations have a hierarchy to them. The tool 300 MUST support that hierarchy. It should be possible to direct a 301 liaison statement to specific subgroups. It should equally be 302 possible for a liaison manager to facilitate processing of inbound 303 statements for a specific subgroup within a standards organization. 305 Web tools should be able to input all information required for both 306 inbound and outbound liaison statements. As liaison statements can 307 sometimes be complex, information should be checkpointed. That is, 308 work should not be lost even if a session is lost. 310 For any field that takes more than one email address as an input, 311 separation of those addresses SHALL be either by commas or semi- 312 colons. 314 EDITOR'S NOTE: Scott Bradner asked - "how do we deal with a series of 315 interleaved inbound and outbound messages? - they send something to 316 us, we respond, they respond to the response, we respond to that 317 response etc - it would be good to keep this as a thread rather than 318 as a series of individual exchanges". I agree, but would appreciate 319 confirmation from others. 321 The tool should include a maintenance interface enabling the 322 secretariat to maintain the list of authorized external 323 organizations, the authorized representatives from those external 324 organizations, the IETF Liaison Managers for each external 325 organization, the list of IETF working groups, the area for each 326 working group, the e-mail list for each working group, etc. 328 4. Acknowledgments 330 The current tool can be accessed from the IETF web page [2]. These 331 requirements are based on experience with that tool, and the author 332 would like to acknowledge the efforts put into that tool by Henrik 333 Levkowitz, and others. 335 5. Security Considerations 337 Representatives from external organizations request an IETF Tools- 338 level password, and the IETF Liaison Manager responsible for each 339 organization requests that the representative's e-mail address be 340 associated with the appropriate external organization in the tool. 341 This requires the IETF Liasison Manager to be familiar with the 342 people in the external organization who will be sending liaison 343 statements, to prevent the possibility of impersonation attacks, and 344 requires the representatives to handle their passwords in a secure 345 way. 347 6. IANA Considerations 349 This document contains no requests for actions by IANA. 351 7. Normative References 353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 354 Requirement Levels", BCP 14, RFC 2119, March 1997. 356 [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of 357 the Internet Architecture Board (IAB)", BCP 39, RFC 2850, 358 May 2000. 360 [RFC4052] Daigle, L. and Internet Architecture Board, "IAB Processes 361 for Management of IETF Liaison Relationships", BCP 102, 362 RFC 4052, April 2005. 364 [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for 365 Handling Liaison Statements to and from the IETF", 366 BCP 103, RFC 4053, April 2005. 368 [RFC4691] Andersson, L., "Guidelines for Acting as an IETF Liaison 369 to Another Organization", RFC 4691, October 2006. 371 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 372 October 2008. 374 [1] 376 [2] 378 Appendix A. Changes 380 This section to be removed prior to publication. 382 o 00a Initial Draft from Eliot. 384 o 00b Revision by Spencer to include IANA Considerations, add text 385 for Security Considerations, and generally clean up IDNITs errors. 387 o 00c Revision by Spencer to address comments from Adrian Farrell 388 and Scott Bradner. 390 Authors' Addresses 392 Eliot Lear 393 Cisco Systems GmbH 394 Richtistrasse 7 395 Wallisellen, ZH CH-8304 396 Switzerland 398 Phone: +41 44 878 9200 399 Email: lear@cisco.com 401 Spencer Dawkins (editor) 402 Huawei Technologies 403 1547 Rivercrest Blvd. 404 Allen, TX 75002 405 USA 407 Email: spencer@wonderhamster.org