idnits 2.17.1 draft-narten-successful-bof-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 553. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (February 7, 2006) is 6645 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) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Thomas Narten 3 IBM 4 February 7, 2006 6 Considerations for Having a Successful BOF 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 20 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/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft expires in six months. 35 Abstract 37 This document discusses tactics and strategy for hosting a successful 38 IETF Birds-of-a-Feather (BOF) Session, especially one oriented at the 39 formation of an IETF Working Group. It is based on the experiences of 40 having participated in numerous BOFs, both successful and 41 unsuccessful. 43 Contents 45 Status of this Memo.......................................... 1 47 1. Introduction............................................. 2 48 2. Ideal Steps.............................................. 3 50 3. The BOF Itself........................................... 7 52 4. Pitfalls................................................. 8 54 5. Miscellaneous............................................ 10 55 5.1. Chairing............................................ 10 56 5.2. On The Need For A BOF............................... 11 58 6. Security Considerations.................................. 11 60 7. IANA Considerations...................................... 11 62 8. Acknowledgments.......................................... 11 64 9. Normative References..................................... 12 66 10. Informative References.................................. 12 68 11. Author's Address...................................... 12 70 1. Introduction 72 This document provides suggestions on how to host a successful BOF at 73 an IETF meeting. It is hoped that by documenting the methodologies 74 that have proven successful, as well as listing some pitfalls, BOF 75 organizers will improve their chances of hosting a BOF with a 76 positive outcome. 78 There are many reasons for hosting a BOF. Some BOFs are intended to 79 be a one-shot presentation on a particular issue, in order to provide 80 information to the IETF Community. Such BOFs are not intended to 81 result in the formation of a Working Group (WG). In many cases, 82 however, the intent is to form a WG. In those cases, the goal of the 83 BOF is to demonstrate that the community has agreement that: 85 - there is a problem that needs solving, and the IETF is the right 86 group to attempt solving it. 88 - there is a critical mass of participants willing to work on the 89 problem (e.g., write drafts, review drafts, etc.) 91 - the scope of the problem is well defined and understood, that is, 92 people generally understand what the WG will work on (and what 93 not) and what its actual deliverables will be 95 - there is agreement that the specific deliverables (i.e., proposed 96 documents) are the right set 98 - it is believed that the WG has a reasonable probability of having 99 success (i.e., in completing the deliverables in its charter in a 100 timely fashion) 102 2. Ideal Steps 104 The following steps present a sort of "ideal" sequence for hosting a 105 BOF where the goal is formation of a working group. The important 106 observation to make here is that most of these involve planning for 107 and engaging in significant public discussion, with sufficient time 108 for iteration and broad participation, so that much of the work of 109 the BOF can be done on a public mailing list in advance of -- rather 110 than during --- the BOF itself. 112 It is also important to recognize the timing constraints. As 113 described in detail below, the deadline for scheduling BOFs is 114 approximately one month prior to the IETF meeting. Working backwards 115 from that date, taking into consideration the time required to write 116 drafts, have public discussion, allow the ADs to evaluate the 117 proposed BOF, etc., the right time to start preparing for a BOF is 118 the meeting prior to the one in which the BOF is desired. By 119 implication, starting the work aimed at leading to a BOF only 2 120 months prior to an IETF meeting is in most cases too late, and will 121 likely result in the BOF being delayed until the following IETF 122 meeting. 124 1) A small group of individuals gets together privately, discusses a 125 possible problem statement, and identifies the work to be done. 126 The group acts as a sort of "design team" to formulate a problem 127 statement, identify possible work items, and propose an agenda for 128 a BOF. 130 Possible substeps: 132 a) Consider whether the work might already fall within scope for 133 an existing Working Group, in which case a BOF might not even 134 be necessary. Individual Working Group charters can be found at 135 http://www.ietf.org/html.charters/wg-dir.html and indicate what 136 a group is scoped to work on. 138 b) Select an area or areas where the work most naturally fits in 139 by identifying WGs that most closely relate to the proposed 140 work. Note that it is not uncommon to find that a work item 141 could easily fit into two (or more) different areas and that no 142 one area is the obvious home. 144 c) Consult with specific WGs to see whether there is interest or 145 whether the work is in scope. This can be done by posting 146 messages directly to WG mailing lists, contacting the WG 147 chairs, or contacting individuals known to participate in a 148 particular WG (e.g., from their postings or from documents they 149 have authored). 151 d) Consult with an area-specific mailing list about possible 152 interest. (Most areas have their own area-specific mailing 153 lists. Follow the links under each area at 154 http://www.ietf.org/html.charters/wg-dir.html to find details.) 156 e) Produce one or more Internet Drafts, describing the problem 157 and/or related work. It cannot be emphasized enough that for 158 the BOF, drafts relating to understanding the problem space are 159 much more valuable than drafts proposing specific solutions. 161 Timeline: This step can easily take 1-2 months; hence, begin 3-4 162 months before an IETF meeting. 164 2) The group may (or may not) approach an Area Director (or other 165 recognized or experienced leader) to informally float the BOF and 166 get feedback on the proposed work, scope of the charter, specific 167 steps that need to be taken before submitting a formal BOF 168 request, etc. By "leader", we mean persons with significant IETF 169 experience who can provide helpful advice; individuals who have 170 successfully hosted BOFs before, current or former WG chairs, IESG 171 or IAB members, would be good candidates. 173 The dividing line between step 1) and 2) is not exact. At some 174 point, one will need to approach one or more Area Directors (ADs) 175 with a specific proposal that can be commented on. Step 1) helps 176 shape an idea into something concrete enough that an AD can 177 understand the purpose and provide concrete feedback. On the other 178 hand, one shouldn't spend too much time on step 1) if the answer 179 at step 2) would turn out to be "oh, we had a BOF on that once 180 before, have you reviewed the archives?". Thus, there may be some 181 iteration involving going back and forth between steps 1) and 2). 182 Also, a quick conversation with an AD might lead them to suggest 183 some specific individuals or WGs you should consult with. 185 It may turn out that it is unclear which area proposed work best 186 fits in. In such cases, when approaching multiple ADs, it is best 187 to approach the ADs approximately simultaneously, state that you 188 are unsure of which area the work fits in, and ask for advice 189 (e.g., by stating "I'm not sure which area this work best fits 190 under, but it looks like it might be Internet or Security or 191 both"). When contacting multiple ADs, it is strongly advised that 192 you inform them of which other ADs you are conversing with. In 193 particular, it is usually counterproductive and not advisable to 194 go "AD shopping", where if one AD gives you an answer you don't 195 like, you go to another, without telling him/her what the first AD 196 said, in the hopes of getting a different answer. 198 To summarize, steps 1) and 2) involve a lot of "socializing an 199 idea," that is, having discussions with a number of different 200 people to try and get agreement on the problem and the need for 201 and appropriateness of having a BOF. How much such discussion is 202 needed is very subjective, but it is critical in terms of getting 203 agreement that a BOF is appropriate. One way to tell if you are 204 close to getting it right: if when talking to someone about your 205 idea for the first time, they quickly agree that a BOF seems in 206 order and don't have any major concerns. 208 Timeline: Steps 1-2) can easily take 1-2 months; hence, begin 3-4 209 months before an IETF meeting. 211 3) Create a public mailing list and post a "call for participation" 212 for the proposed BOF agenda on various mailing lists (e.g., the 213 ietf list). The call for participation advertises that a 214 "community of interest" is being formed to gauge whether there is 215 sufficient interest to host a BOF. The goal is to draw in other 216 interested potential participants, to allow them to help shape the 217 BOF (e.g., by giving them time to write a draft, ask for agenda 218 time, help scope the work of the proposed work, argue that a BOF 219 is (or is not) needed, etc.) 221 Timeline: This step can easily take 1 month or longer; it also 222 needs to be started well before the Internet-Drafts cutoff (to 223 allow participants to submit drafts); hence begin 2-3 months 224 before the IETF meeting. 226 4) Have real mailing list discussion. It is not enough for a handful 227 of people to assert that they want a BOF; there needs to be 228 broader community interest. A public mailing list allows ADs (and 229 others) to gauge how much interest there really is on a topic 230 area, as well as gauge how well the problem statement has been 231 scoped, etc. At this phase of the BOF preparation, the emphasis 232 should be on getting agreement on the problem statement; 233 discussions about specific solutions tends to be distracting and 234 unhelpful. 236 Timeline: this step can easily take 1 month or longer; hence begin 237 2 months before the IETF meeting. 239 5) Submit a formal request to have a BOF. Instructions for submitting 240 a formal request can be found at 241 http://www.ietf.org/instructions/MTG-SLOTS.html and 242 http://www.ietf.org/ietf/1bof-procedures.txt. Note that as part 243 of making a formal request, the organizers must identify the Area 244 (the area Area Directors will be required to approve the BOF), 245 include a proposed BOF agenda, estimate the attendance, list 246 conflicts with other sessions that should be avoided, etc. 248 If the previous steps have been followed, the Area Directors (ADs) 249 should be in a good position to gauge whether there is sufficient 250 interest to justify approval of a BOF. 252 Note: it almost goes without saying that without one or more 253 Internet Drafts at this point, it is generally pointless to ask an 254 AD to approve a BOF. 256 Timeline: The Secretariat publishes an "important meeting dates" 257 calendar along with meeting information. There is a firm deadline 258 (about 1 month prior to the meeting) for submitting a formal BOF 259 scheduling request. Note: that at the time of the deadline, an AD 260 will need to have sufficient information about the BOF to approve 261 or reject the request, so all of the previous steps will need to 262 have completed. 264 6) During the 2-4 weeks before an IETF (assuming a BOF has been 265 approved and scheduled), the focus (on the mailing list) should be 266 on identifying areas of agreement and areas of disagreement. Since 267 disagreements or "lack of consensus" tends to be the main reason 268 for not forming a WG, focusing on those specific areas where "lack 269 of consensus" exists is critically important. In general, only 270 after those disagreements have been resolved will a WG be formed, 271 thus, the main goal should be to find consensus and work through 272 the areas of disagreement. Alternatively, a specific case should 273 be made about why the charter as it is written is the best one, in 274 spite of the stated opposition. 276 7) Prior to the BOF, it is critical to produce a proposed charter and 277 iterate on it on the mailing list to attempt to get a consensus 278 charter. Ultimately, the most important question to ask during a 279 BOF is: "should a WG with the following charter be formed?". It 280 goes without saying that a charter with shortcomings (no matter 281 how seemingly trivial to fix) will not achieve consensus if folk 282 still have issues with the specific wording. 284 8) Decide what questions will be asked during the BOF itself. Since 285 the exact wording of the questions is critical (and hard to do on 286 the fly), it is strongly recommended that those questions be 287 floated on the mailing list and with the ADs prior to the BOF, so 288 people understand what they will be asked to give approval to, and 289 to allow the questions to be modified (prior to the BOF) to remove 290 ambiguities, etc. Likewise, discussing those questions in advance 291 may lead to refinement of the charter so that the questions can be 292 affirmatively answered 294 9) At the meeting, but before the BOF takes place, plan a meeting 295 with all of the presenters to have them meet each other, review 296 the agenda and make sure everyone understands what is expected of 297 them (e.g., what time constraints they will be under when 298 presenting). Use this time to also work through any disagreements 299 that still remain. Do the same "in the hallway" with other 300 interested parties! 302 10) Consult the tutorial schedule and consider attending relevant 303 tutorial sessions ("Working Group Chair Training", "Working Group 304 Leadership Training", etc.). This is especially the case if you 305 are considering being the chair of a potential WG. Since the role 306 of the WG chair and BOF chair have a number of parallels, a number 307 of the topics covered in the tutorial apply to hosting a BOF and 308 developing a charter. 310 3. The BOF Itself 312 For the BOF itself, it is critically important to focus on the bottom 313 line: 315 What is it that one is attempting to achieve during the BOF? 317 A good BOF organizer keeps a firm focus on the purpose of the BOF and 318 crafts an agenda in support of that goal. Just as important, 319 presentations that do not directly support the goal should be 320 excluded, as they often become distractions, sow confusion, and 321 otherwise take focus away from the purpose of the BOF. If the goal 322 is to form a WG, everything should lead to an (obvious) answer to the 323 following question: 325 Does the room agree that the IETF should form a WG with the 326 following (specific) charter? 328 One of the best ways to ensure a "yes" answer to the above, is by 329 performing adequate preparation before the BOF to ensure that the 330 community as a whole already agrees that the answer is "yes". How 331 does one do that? One good way seems to be: 333 1) Have a public discussion with sufficient time to allow iteration 334 and discussion. (hence, start a minimum of 3 months prior to the 335 IETF meeting). 337 2) Work with the community to iterate on the charter, and be sure to 338 address the significant concerns that are being raised. (One can 339 address the concerns in advance -- and get advance agreement, or 340 one can have those concerns be raised (again) during the BOF -- in 341 which case it is likely that the proposed charter will not be good 342 enough to get agreement on during the actual BOF). 344 3) During the BOF, keep the agenda tightly focused on supporting the 345 need for the WG and otherwise making the case that the group has 346 identified a clearly-scoped charter, and has agreement on what the 347 set of deliverables should be. 349 4. Pitfalls 351 Over the years, a number of pitfalls have been (repeatedly) observed: 353 1) Waiting too long before getting started. It is very difficult to 354 prepare for a BOF on short notice. Moreover, ADs are placed in a 355 no-win situation when asked to approve a BOF for which the 356 community has not had a chance to participate. Steps 1-4 in 357 Section 2 above are designed to show the ADs that there is 358 community support for a particular effort. Short-circuiting those 359 steps force an AD to make a judgment call with (usually) too 360 little information. Moreover, because the community has not been 361 involved, it is much more likely that significant (and valid) 362 objections will be raised. Often, those objections could have been 363 dealt with in advance -- had there been sufficient time to work 364 through them in advance. 366 2) Too much discussion/focus on solutions, rather than showing that 367 support exists for the problem statement itself, and that the 368 problem is well-understood and scoped. The purpose of the BOF is 369 almost never to show that there are already proposed solutions, 370 but to demonstrate that there is a real problem that needs 371 solving, a solution would be beneficial to the community, it is 372 believed that a solution is achievable and that there is a 373 critical mass of community support to actually put in the real 374 work of developing a solution. 376 3) Asking the wrong question during the BOF. Often, BOF organizers 377 feel like there is a need to ask the question "shall we form a 378 WG?". But, unless the question is clear, properly scoped, etc., 379 asking such a question serves no purpose. Even worse, such 380 questions can demonstrate that there is no consensus (yet) for the 381 work and thus no WG should be formed. The right questions to ask 382 are generally along the lines of: 384 1) Is there support to form a WG with the following charter? (that 385 is, the charter itself is ready, as shown by community 386 support.) 388 2) Does the community think that that the problem statement is 389 clear, well-scoped, solvable, and useful to solve? 391 3) Can I see a show of hands for folk willing to review documents? 392 (or comment on the mailing list?) 394 4) Who would be willing to serve as an editor for the following 395 document(s)? (BOF chairs should take note of individuals who 396 raise their hands, but it is also a useful gauge to see there 397 is a critical mass of editors to work on all the documents that 398 are to be produced.) 400 5) Does the community think that given the charter revisions 401 discussed during the BOF (subject to review and finalization on 402 the mailing list), a WG should be formed? 404 6) How many people feel that a WG should not be formed? (If the 405 number of no responses is significant, it would help to ask 406 those saying no why they are opposed.) 408 7) Before asking a particular question, it is sometimes very 409 appropriate to ask: Do people feel like they have sufficient 410 information to answer the following question or is it premature 411 to ask the following question? 413 Examples of unreasonable questions to ask: 415 1) Asking folk to approve or review a charter that is put on 416 screen but has not been posted to the mailing list sufficiently 417 in advance. (You cannot ask folk to approve something they have 418 not seen.) 420 4) Poorly advertised in advance, thus, the BOF itself does not 421 include the "right" participants. This can happen for a number of 422 reasons, including: 424 - BOF is given a "cute" but unintuitive name (or acronym), 425 causing people to not realize that it would be of interest to 426 them 428 - failing to advertise the BOF in advance to the community of 429 people that might be interested. At a minimum, the existence of 430 a proposed BOF should be advertised on the IETF list as well as 431 specific WG lists that are somewhat related. 433 5) Providing agenda time for the "wrong" presentations. There is an 434 (unfortunate) tendency to given anyone who requests agenda time 435 an opportunity to speak. This is often a mistake. Presentations 436 should be limited to those that address the purpose of the BOF. 437 More important, presentations should not distract from the BOFs 438 purpose, or open up ratholes that are a distraction to the more 439 basic purpose of the BOF. Examples of problematic presentations: 441 - presentations on specific solutions, when the purpose of the 442 BOF is to get agreement on the problem statement and the need 443 for a WG. Solutions at this point are too-often "half-baked" 444 and allow discussion to rathole on aspects of the solutions, 445 when instead the focus should be on getting agreement on 446 whether to form a WG. 448 6) Poor time management, leading to insufficient time for discussion 449 of the key issues (this is often closely related to 5). When 450 presentations run over their alloted time, the end result is 451 either squeezing someone else's presentation, or having 452 insufficient discussion time. Neither is acceptable nor helpful. 453 BOF chairs need to give presenters just enough time to make key 454 points -- and no more. It may well be helpful to go over a 455 presenter's slides in advance, to ensure they are on-topic and 456 that they will fit within the time slot. 458 5. Miscellaneous 460 5.1. Chairing 462 BOF organizers often assume that they will be chairing a BOF (and the 463 eventual WG). Neither assumption is always true. ADs need to ensure 464 that a BOF runs smoothly and is productive. For some topics, it is a 465 given that the BOF will be contentious. In such cases, ADs may want 466 to have a more experienced person chairing or co-chairing the BOF. 467 Also, those interested in organizing the BOF often are the most 468 interested in driving a particular technology (and may have strongly 469 held views about what direction an effort should take). Working 470 groups are often more effective when passionately-involved parties 471 are allowed to focus on the technical work, rather than on the 472 management work. Thus do not be surprised (or offended!) if the AD 473 want to pick one or more co-chairs for either the BOF or a followon 474 WG. 476 5.2. On The Need For A BOF 478 This document highlights the need for allowing for and actively 479 engaging in a broad public discussion on the merits of forming a WG. 480 It might surprise some, but there is no actual process requirement to 481 have a BOF prior to forming a WG. The actual process requirement is 482 simply that the IESG (together with the AD(s) sponsoring the work) 483 approve a formal charter as described in [RFC2418]. In practice, BOFs 484 are used to engage the broader community on proposed work and to help 485 produce an acceptable charter. 487 There are two observations that can be made here. First, BOFs are 488 often held not because they are (strictly speaking) required, but 489 because it is assumed they are needed or because ADs feel that a BOF 490 would be beneficial in terms of getting additional public 491 participation. Hence, those interested in forming a WG should give 492 serious consideration to using the steps outlined above not just for 493 the purposes of leading to a BOF, but to convince the IESG and 494 broader community that a BOF is not even needed, as there is already 495 demonstrated strong consensus that a WG shold be formed. Second, the 496 IESG should not forget that BOFs are simply a tool, and may not even 497 be the best tool in every situation. 499 6. Security Considerations 501 This document has no known security implications. 503 7. IANA Considerations 505 This document makes no requests to IANA. 507 8. Acknowledgments 509 This document has benefited from specific feedback from Brian 510 Carpenter, Spencer Dawkins, John Klensin, Mark Townsley and Bert 511 Wijnen. 513 9. Normative References 515 10. Informative References 517 [RFC2418] "IETF Working Group Guidelines and Procedures," S. Bradner, 518 September 1998. 520 11. Author's Address 522 Thomas Narten 523 IBM Corporation 524 3039 Cornwallis Ave. 525 PO Box 12195 - BRQA/502 526 Research Triangle Park, NC 27709-2195 528 Phone: 919-254-7798 529 EMail: narten@us.ibm.com 531 Intellectual Property Statement 533 The IETF takes no position regarding the validity or scope of any 534 Intellectual Property Rights or other rights that might be claimed to 535 pertain to the implementation or use of the technology described in 536 this document or the extent to which any license under such rights 537 might or might not be available; nor does it represent that it has 538 made any independent effort to identify any such rights. Information 539 on the procedures with respect to rights in RFC documents can be 540 found in BCP 78 and BCP 79. 542 Copies of IPR disclosures made to the IETF Secretariat and any 543 assurances of licenses to be made available, or the result of an 544 attempt made to obtain a general license or permission for the use of 545 such proprietary rights by implementers or users of this 546 specification can be obtained from the IETF on-line IPR repository at 547 http://www.ietf.org/ipr. 549 The IETF invites any interested party to bring to its attention any 550 copyrights, patents or patent applications, or other proprietary 551 rights that may cover technology that may be required to implement 552 this standard. Please address the information to the IETF at ietf- 553 ipr@ietf.org. 555 Disclaimer of Validity 557 This document and the information contained herein are provided on an 558 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 559 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 560 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 561 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 562 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 563 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 565 Copyright Statement 567 Copyright (C) The Internet Society (2006). 569 This document is subject to the rights, licenses and restrictions 570 contained in BCP 78, and except as set forth therein, the authors 571 retain all their rights. 573 This document and the information contained herein are provided on an 574 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 575 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 576 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 577 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 578 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 579 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.