idnits 2.17.1 draft-crocker-id-adoption-09.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 date (February 7, 2014) is 3728 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-resnick-on-consensus-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Farrel 3 Internet-Draft Juniper Networks 4 Intended status: Informational D. Crocker, Ed. 5 Expires: August 11, 2014 Brandenburg InternetWorking 6 February 7, 2014 8 Handling of Internet Drafts by IETF Working Groups 9 draft-crocker-id-adoption-09 11 Abstract 13 The productive output of an IETF working group is documents, as 14 mandated by the working group's charter. When a working group is 15 ready to develop a particular document, the most common mechanism is 16 for it to "adopt" an existing document as a starting point. The 17 document that a working group adopts and then develops further is 18 based on initial input at varying levels of maturity. An initial 19 working group draft might be a document already in wide use, or it 20 might be a blank sheet, wholly created by the working group, or it 21 might represent any level of maturity in between. This document 22 discusses how a working group typically handles the formal documents 23 that it targets for publication. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 11, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. What is a Working Group Draft? . . . . . . . . . . . . . 3 61 1.2. Working Group Authority and Consensus . . . . . . . . . . 3 62 1.3. Questions Considered in This Document . . . . . . . . . . 5 63 2. Adoption Sequence . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1. Common Steps . . . . . . . . . . . . . . . . . . . . . . 5 65 2.2. Criteria for Adoption . . . . . . . . . . . . . . . . . . 6 66 3. Authors/Editors . . . . . . . . . . . . . . . . . . . . . . . 7 67 4. Document History and Stability . . . . . . . . . . . . . . . 8 68 5. Some Issues for Consideration . . . . . . . . . . . . . . . . 10 69 5.1. Individual I-Ds Under WG Care . . . . . . . . . . . . . . 10 70 5.2. WG Drafts Can become Individual Drafts . . . . . . . . . 11 71 5.3. Competing Drafts . . . . . . . . . . . . . . . . . . . . 11 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 74 8. Informative References . . . . . . . . . . . . . . . . . . . 13 75 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 14 76 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 The productive output of an IETF working group is documents, as 82 mandated by the working group's charter. Working groups develop 83 these documents based on initial input of varying levels of maturity. 84 An initial working group draft might be a document already in wide 85 use, or it might be a blank sheet, wholly created by the working 86 group, or it might represent any level of maturity in between. This 87 document discusses how a working group typically handles the formal 88 documents that it targets for publication. The discussion applies 89 only to the IETF and does not cover IRTF groups, where practices vary 90 widely. 92 Within the general constraints of formal IETF process and the 93 specific constraints of a working group's charter, there can be 94 considerable freedom in the adoption and development of drafts. As 95 with most IETF activities, the ultimate arbiter of such choices is 96 working group agreement, within the constraints of its charter. As 97 with most working group management, this agreement might be explicit 98 or implicit, depending upon the efficiencies that the group deems 99 appropriate. 101 NOTE: This draft is intentionally non-normative. It is meant as a 102 guide to common practice, rather than as a formal definition of 103 what is permissible. 105 1.1. What is a Working Group Draft? 107 Working Group drafts are documents that are subject to IETF Working 108 Group revision control, with advancement for publication as an RFC 109 requiring rough consensus in the working group and then in the 110 broader IETF. Creation or adoption of a draft by a working group -- 111 as well as substantive changes to the document -- need to represent 112 working group rough consensus. 114 Documents under development in the IETF community are distributed as 115 Internet Drafts (I-D) [RFC2026], [ID-Info]. Working groups use this 116 mechanism for producing their official output, per Section 7.2 of 117 [RFC2418] and Section 6.3 of [Tao]. The common convention for 118 identifying an I-D formally under the ownership of a working group is 119 by the inclusion of "ietf" in the second field of the I-D filename 120 and the working group name in the third field, per Section 7 of 121 [ID-Guidelines]. That is: 123 draft-ietf--... 125 In contrast, individual submissions are drafts being created and 126 pursued outside of a working group, although a working group might 127 choose to adopt the draft later, as discussed below. Anyone is free 128 to create an individual submission at any time. Such documents are 129 typically distinguished through the use of the author/editor's last 130 name, in the style of: 132 draft--... 134 (Also see Section 5.1 for an elaboration on this naming.) 136 Responsibility for direct revision of a working group I-D is assigned 137 to its editors and authors. See Section 3 for discussion about their 138 selection and role. 140 1.2. Working Group Authority and Consensus 142 A premise of the IETF is that, within a working group, it is the 143 working group itself that has final authority over the content of its 144 documents, within the constraints of the working group's charter. No 145 individual has special authority for the content. The chairs assign 146 document authors/editors and can formulate design teams, but the 147 content of working group documents is always, ultimately, subject to 148 working group approval. Approval is described in terms of the IETF's 149 "rough consensus" construct, which is the prime example of the IETF's 150 preference for pragmatics over niceties. Unanimous agreement is 151 always desirable, but more approximate (rough) agreement will 152 suffice, as long as it is clear and strong. 154 Other than for selection of document authors/editors, as discussed in 155 Section 3, working group decision-making about document management is 156 subject to normal IETF rough consensus rules. Useful descriptions of 157 this process for a working group are in Section 3.3 of [RFC2418] and 158 Section 4.2 of [Tao]. Discussion of the nature of rough consensus 159 can be found in [Consensus]. 161 In terms of the IETF's formal rough consensus processes, the working 162 group explicitly develops, modifies, reviews, and approves document 163 content, according to overt rough consensus. For difficult topics 164 and/or difficult working group dynamics, this laborious process 165 really is essential. Its diligence validates progress at each step 166 along the way. However working groups often handle simpler matters 167 more simply, such as allowing a Chair to assert the likely agreement 168 and then merely call for objections. Ultimately, the mode of working 169 group decision making is determined by the comfort and engagement of 170 the working group with the way the decisions are being made. 172 At times, a document author/editor can appear to have considerable 173 authority over content, but this is (merely) for efficiency. That 174 is, the chairs can permit authors and editors to proceed with an 175 implied (default) working group agreement, as long as the working 176 group is comfortable with that mode. Of course the benefit in the 177 mode is efficiency, but its risk is failure to retain or verify 178 actual consensus among the working group participants. When a 179 working group is operating in the mode of active, direct author/ 180 editor content development, an easy validation method is simply to 181 have chairs query the working group when a new document version 182 appears, asking for comments and concerns. 184 In general when it is not completely obvious what the opinion of the 185 working group is, working group chairs can poll the working group to 186 find out. As with any other consensus question, the form in which it 187 is asked can make a difference. In particular, a general 'yes/no' 188 question often is not as helpful as asking supporters and detractors 189 of a draft -- or of the decision under consideration -- to provide 190 their reasons, not merely their preferences. In effect, this treats 191 the matter of consensus as an on-going discussion. Ideally the 192 discussion can produce changes in the document or in participant 193 views, or both. 195 1.3. Questions Considered in This Document 197 The purpose of this document is to discuss the criteria and sequence 198 typically followed when adopting and developing a formal IETF working 199 group document. Therefore, this document considers the following 200 questions that are particularly relevant to working group chairs who 201 are charged with running the process: 203 * How do working group chairs decide which drafts to adopt and 204 when? 206 * Is it necessary to poll the working group explicitly, and what 207 does a working group poll look like? 209 * How do working group chairs make the decision? 211 * What are the process steps the working group will choose to 212 use, for an I-D to become a WG I-D? 214 * Are there any special cases? 216 * Can a document be created as a WG I-D from scratch? 218 * How can competing drafts be handled? 220 * Can an Individual I-D be under the care of a WG? 222 * Can a WG I-D become an Individual I-D? 224 2. Adoption Sequence 226 2.1. Common Steps 228 When there is interest in adopting a document as a new working group 229 document, the chairs often: 231 1. Remind current draft owners that they are transferring change 232 control for the document to the IETF. (This is a particularly 233 significant point for a document covered by proprietary 234 interests, which typically entails a negotiation between the 235 current owners and the IETF, including a formal agreement.) 237 2. Check for known IPR that needs to be disclosed, using some 238 technique like those described in [RFC6702] 240 3. Obtain working group rough consensus. 242 4. Choose document editors. 244 5. Chairs instruct authors to post WG I-D. 246 6. Chairs approve posting.[Approval] 248 7. Chairs ensure that the non-working group version of the draft 249 is marked as being replaced by this working group version. 251 8. Everyone enjoys the ensuing working group discussion... 253 2.2. Criteria for Adoption 255 No formal specification for working group 'adoption' of a draft 256 exists; the current document is meant to provide a description of 257 common activities for this, but again note that it is not normative. 259 There are some basic considerations when deciding to adopt a draft: 261 * Is there a charter milestone that explicitly calls for such a 262 document? 264 * Is the topic of the I-D within scope for the working group? 266 * Is the purpose of the draft sufficiently clear? 268 * Does the document provide an acceptable platform for continued 269 effort by the working group? 271 * What are the process or technical objections to adoption of the 272 draft? 274 * Is the draft likely to be completed in a timely manner? 276 * Does the intended status of the document seem reasonable to the 277 working group? 279 * If not already in scope, is a simple modification to the 280 charter feasible and warranted? 282 * Does the draft carry known intellectual property rights issues? 283 * Is there strong working group support for working on the draft? 285 Adoption has some basic pragmatics: 287 Rough consensus: Working group agreement to adopt is not 288 required to be unanimous. [RFC2418] 290 Initial, not final: The writing quality is not required to be 291 ready-for-publication, although writing quality can be a 292 problem and does need explicit attention; although not 293 mandatory, it is good practice to check whether a new working 294 group draft passes [IDNITS]. 296 Adoption, not approval: The document is not required to already 297 contain a complete and/or sufficient solution, although of 298 course this can be helpful. Equally, adoption by a working 299 group does not guarantee publication of the document as an RFC. 301 Group, not chairs: Concerning the draft, the position of the 302 working group chairs has no special authority, except to assess 303 working group consensus. 305 REMINDER: Once a working group adopts a draft, the document is 306 owned by the working group and can be changed however the working 307 group decides, within the bounds of IETF process and the working 308 group charter. Absent explicit agreement, adopting a document 309 does not automatically mean that the working group has agreed to 310 all of its content. So a working group (or its charter) might 311 explicitly dictate the basis for retaining, removing or modifying 312 some or all of a draft's content, technical details, or the like. 313 However in the absence of such constraints, it is worth having the 314 adoption process include a sub-process of gathering working group 315 concerns about the existing draft and flagging them explicitly. 317 3. Authors/Editors 319 Document authors/editors are chosen by the working group chairs. 320 Authors are described in Section 6.3 of [RFC2418]. Authors and 321 editors are described in [RFC-Auth-Ed]. 323 NOTE: In this document, the terms 'author' and 'editor' are meant 324 interchangeably. Within the IETF the distinction between an 325 'editor' and an 'editor' is, at best, subjective. A simplistic 326 rule of thumb is that editors tend to do the mechanics of 327 incorporating working group detail, whereas authors tend to create 328 the detail, subject to working group approval. That is, one role 329 is more active with the content and the other is more passive. It 330 is a responsibility of the working group chairs to ensure that 331 document authors make modifications in accord with working group 332 rough consensus. Authors/editors are solely chosen by the chairs 333 -- although the views of the working group should be considered -- 334 and are subject to replacement for a variety of reasons, as the 335 chairs see fit. 337 For existing documents that are being adopted by a working group, 338 there is a special challenge in the selection of document editors: 339 The document has already had editors. So the question is whether the 340 same people are appropriate for continuing the task? Sometimes the 341 answer is yes, but this is not automatic. The process within an IETF 342 working group can be quite different from the process that created 343 previous versions. This well might make it appropriate to select one 344 or more new editors, either as additions to the editor team or as 345 primary pen-holders (effectively re-classifying the previous team as 346 co-authors). 348 If the original editors are to continue in their role, the chairs 349 might want to ensure that the editors understand IETF working group 350 process; it is likely to be quite different from the process that 351 developed earlier versions of the document. If additional or new 352 editors are assigned, the transition can be discussed, including its 353 reasons; this is best done as soon as possible. 355 4. Document History and Stability 357 Working group charters sometimes specify an initial set of existing 358 documents to use as a basis of the working group's activities. That 359 'basis' can vary considerably, from simple input to working group 360 discussion, all the way to an advanced draft adopted by the working 361 group and subject only to minimal changes. The role of a document 362 should be explicitly stated in the charter. 364 Within the scope of its charter, a working group is free to create 365 new documents. It is not required that all drafts start as the 366 effort of an individual. Of course the criteria for brand new 367 documents are likely to be the same as for those imported into the 368 working group with the additional and obvious requirement that the 369 working group chairs will need to appoint authors/editors before any 370 work can progress. Note that from time to time a working group will 371 form a design team to produce the first version of a working group 372 draft. Design teams are discussed in Section 6.5 of [RFC2418]. 374 Work that is brought to the IETF has different levels of completeness 375 and maturity, and different timings for having achieved those levels. 377 When the IETF charters a group and includes existing material, the 378 charter can cast the role of that material in very different ways: 380 * It can treat it as no more than a set of ideas, to be used or 381 ignored; 383 * It can treat it as a basic design, with all of the actual 384 details still fluid; 386 * It can treat it as a rough draft, subject to extensive 387 revision; 389 * It can treat it as a solid specification that merely needs 390 review, refinement and maybe enhancement; 392 * It can treat it as a deployed technology that is best served by 393 trying to protect its installed base, but with some tolerance 394 for changes that affect interoperability; 396 * It can treat it as a deployed technology for which protecting 397 the installed base is essential, including retention of core 398 interoperability. 400 These suggest a wide range of possible constraints on working group 401 effort. Technology is brought to the IETF at different points of 402 maturity along its lifecycle and the nature of the technology can 403 have widely varying utility in developing an Internet standard. 405 When technology is brand new, with at most some prototypes done as 406 proofs of concept, then significant changes to the specification will 407 not necessarily add much to the development and deployment costs. 408 However when the technology is already part of a mature and extensive 409 operational deployment, incompatible changes are likely to be 410 problematic for that market, which can hinder adoption of the 411 changes. For example, immediately after the development investment 412 is made -- and especially when there has been considerable initial 413 deployment -- but still room for quite a bit more -- the installed 414 and potential base might not take kindly to disruptive standards work 415 that undermines their recent investment. 417 Conversely, even a deployed technology with a solid base might be 418 inappropriate to deploy at Internet scale, and while a document 419 specifying such a technology might serve as a good starting point on 420 which to base a new specification, undermining of the deployed base 421 might be completely appropriate. 423 In reflecting upon the basis for adopting an existing draft and the 424 way it will be used by the working group, it is important to consider 425 the document's place in its lifecycle, the needs of any installed 426 base, and the applicability of the draft's technology, when deciding 427 on the constraints to impose on document development. It will all 428 depend on the constraints of the charter and the analysis of the 429 working group. 431 5. Some Issues for Consideration 433 5.1. Individual I-Ds Under WG Care 435 Sometimes, a working group facilitates a draft, but does not own it 436 or formally adopt it. These are "individual" drafts [Individual]. 438 As noted in Section 1.1 and reinforced in [ID-Guidelines], the 439 convention for identifying an I-D formally under the ownership of a 440 working group is by following the naming convention: 442 draft-ietf--... 444 By contrast, documents that are still under the control of their 445 authors are known as "individual" I-Ds. When these documents are 446 intended for consideration by a specific working group, the 447 convention is that the document uses the naming convention as follows 448 where the second element is the last name of one of the principal 449 authors. 451 draft--... 453 Having the working group name following the personal name allows 454 tools to associate these drafts with the working group, even though 455 the filename identifies them as the work of individuals. 457 The working group can choose to apply any of its normal, internal 458 working group process management mechanisms to an Individual I-D. 459 However matters of ownership, working group final approval, and the 460 like are all subject to negotiation amongst the document authors, 461 working group and area directors. 463 This is a rare situation and working group chairs can be assured that 464 the Area Directors will want to understand why the document could not 465 be adopted and owned by the working group. 467 5.2. WG Drafts Can become Individual Drafts 469 A working group is not obligated to retain documents it has adopted. 470 Sometimes working group efforts conclude that a draft is no longer 471 appropriate for working group effort. If a working group drops a 472 draft then anyone is permitted to pursue it as an Individual or 473 Independent Submission, subject to the document's existing copyright 474 constraints. 476 5.3. Competing Drafts 478 Engineering for interesting topics often produces competing, 479 interesting proposals. The reasons can be technical aesthetics, 480 engineering tradeoffs, architectural differences, company economics 481 and the like. Although it is far more comfortable to entertain only 482 one proposal, a working group is free to pursue more than one. Often 483 this is necessary until a clear preference develops. Sometimes, 484 multiple versions are formally published, absent consensus among the 485 alternatives. 487 It is appealing to ask authors of competing proposals to find a way 488 to merge their work. Where it makes sense to do this, it can produce 489 a single, strong specification. The detailed discussions to merge 490 are often better held in a design team than amidst the dynamics of an 491 open working group mailing list. The working group has ultimate 492 authority over any decisions, but it is not required that it be 493 involved in all the discussions. 495 On the other hand, some differences cannot be resolved and attempting 496 a merge can produce a weaker result. An example of this problem of 497 conflicting design goals is discussed in [Heli-Sub], noting: 499 "Helicopters are great, and so are submarines. The problem is 500 that if you try to build one vehicle to perform two fundamentally 501 different jobs, you're going to get a vehicle that does neither 502 job well." 504 Various management efforts can facilitate the handling of competing 505 proposals. Some examples include: 507 * Develop a requirements document that is independent of specific 508 proposals; this can highlight features that are deemed 509 essential, from those that are of secondary importance, and 510 facilitate a discussion about features without reference to 511 specific proposals. 513 * Develop a comparison table of the proposals; this can aid 514 understanding of their differences. 516 * Discuss the relative importance and effects of having one 517 proposal, versus multiple; this can focus people's efforts at 518 compromise and encourage a willingness to choose a single 519 proposal. 521 The problem of competing drafts can be particularly painful when it 522 arises in either of two circumstances: 524 * If a second proposal appears as a new draft, just as the chairs 525 were ready to poll the working group on adoption of the draft 526 containing the first proposal, then the authors of the first 527 proposal could feel affronted. It does not follow that the 528 second draft was written to be difficult or derail the first: 529 it might even include better ideas. So it is best not to 530 disregard it. However, automatically asking the authors to 531 merge their work will not necessarily produce a more solid 532 solution and will not guarantee faster progress. This 533 situation will be a judgement call in each case, and it might 534 help to ask the working group for their opinion: shall the 535 working group adopt one document as a starting point and fold 536 in the ideas from the second under the control of consensus, or 537 shall the working group wait until the authors of both 538 documents have reached agreement? 540 * If the working group has already adopted an I-D on a specific 541 topic, the posting of a new individual I-D on the same topic 542 could be seen as an attack on the working group processes or 543 decisions. However, posting an I-D is often a good way to put 544 new ideas into concrete form, for public consideration and 545 discussion. The working group chairs will want to encourage 546 the working group to consider the new proposal. Shall it be 547 adopted and entirely replace the current working group draft? 548 Shall the new ideas be incorporated into the work of the 549 working group through the normal editorial process? Shall the 550 working group adopt a second competing solution? Or shall the 551 new draft be rejected and not adopted by the working group? 553 6. Security Considerations 555 Beyond the credibility of the IETF, this document raises no security 556 concerns. 558 7. Acknowledgements 560 This draft was developed from an IETF tutorial given by A. Farrel. 561 L. Anderson contributed useful comments. 563 8. Informative References 565 [Approval] 566 IETF, "IETF Internet-Draft Initial Version Approval 567 Tracker", IETF https://datatracker.ietf.org/cgi-bin/wg/ 568 wg_init_rev_approval.cgi, . 570 [Consensus] 571 Resnick, P., "On Consensus and Humming in the IETF", I-D 572 draft-resnick-on-consensus-06, November 2013. 574 [Farrel-Chairs] 575 Farrel, A., "What is a Working Group ID (and when to adopt 576 one)", Web 577 http://wiki.tools.ietf.org/group/edu/wiki/IETF78#, July 578 2010. 580 [Heli-Sub] 581 Rose, M., "On Helicopters and Submarines", ACM Queue - 582 Instant Messaging Vol 1, Issue 8, Page 10, ACM 583 http://dl.acm.org/ft_gateway.cfm?id=966726, . 585 [ID-Guidelines] 586 Housley, R., Ed., "Guidelines to Authors of Internet- 587 Drafts", IETF 588 http://www.ietf.org/ietf-ftp/1id-guidelines.txt, December 589 2010. 591 [ID-Info] Wijnen, B., Ed., "Checklist for Internet-Drafts (IDs) 592 submitted for RFC publication", IETF https://www.ietf.org/ 593 id-info/checklist.html, May 2009. 595 [IDNITS] IETF, "IDNITS Tool", IETF https://www.ietf.org/tools/ 596 idnits/, 2013. 598 [Individual] 599 IESG, , "Guidance on Area Director Sponsoring of 600 Documents", IETF http://www.ietf.org/iesg/statement/ 601 ad-sponsoring-docs.html, March 2007. 603 [RFC-Auth-Ed] 604 "RFC Editorial Guidelines and Procedures -- Author 605 Overload", WEB 606 http://www.rfc-editor.org/policy.html#policy.authlist, 607 2014. 609 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 610 3", BCP 9, RFC 2026, October 1996. 612 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 613 Procedures", BCP 25, RFC 2418, September 1998. 615 [RFC6702] Polk, T. and P. Saint-Andre, "Promoting Compliance with 616 Intellectual Property Rights (IPR) Disclosure Rules", RFC 617 6702, August 2012. 619 [Tao] Hoffman, P., Ed., "The Tao of IETF - A Novice's Guide to 620 the Internet Engineering Task Force", IETF 621 http://www.ietf.org/tao.html, 2012. 623 Appendix A. IANA Considerations 625 There are no requests for IANA. 627 The RFC Editor should remove this section. 629 Appendix B. Acknowledgements 631 This document was based on a presentation made at an IETF Working 632 Group Chairs lunch. [Farrel-Chairs]) 634 Authors' Addresses 636 Adrian Farrel 637 Juniper Networks 639 Email: adrian@olddog.co.uk 641 Dave Crocker (editor) 642 Brandenburg InternetWorking 643 675 Spruce Drive 644 Sunnyvale, CA 94086 645 USA 647 Phone: +1.408.246.8253 648 Email: dcrocker@bbiw.net