File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 1 Spencer Dawkins Tektronix WG Chairs Training Original slides from Margaret Wasserman ThingMagic Spencer is responsible for the dumb parts

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 2 My Checkered Career at IETF Working Group co-chair for PILC (with Aaron Falk) ● BoF in Dec 1998, concluded in Dec 2003 Produced 7 RFCs Survived four co-chair sponsor organization changes Survived regime changes (AD and IETF chair) Survived editor thrashing on major drafts Survived RFC Auth-48 with 16 text resets/142 ● This was with the RFC-Editor as co-chair! Since surrendering my blue dot, now serving on ● General Area Review Team (Gen-ART) ● EDU Team (“you are here”) ● General Area Directorate

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 3 WG Chairs Training WG Chair Role and Responsibilities Chartering and Re-chartering The Working Group Document Process Life of a Draft After the WG Consensus and Problem Solving Making WGs Open and Accessible Resources and Administrivia

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 4 So, You Want to be a WG Chair... You have to balance progress and fairness ● If you don’t make progress, fairness doesn’t matter ● If you aren’t fair, you won’t make progress ● Chairing a WG is not the time to insist on your own way! How willing are you to work through others? ● How successful are you when you work with competitors? ● How successful are you when you work with volunteers? How committed are you? ● It will almost always take longer than you think ● Sponsoring organization changes are commonplace ● ADs often prefer not to have authors as chairs What are you doing now?

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 5 WG Leadership Roles Chair(s) – manage process, judge consensus ● I’ll be assuming “two co-chairs” for a number of reasons WG Secretary – publishes agendas, takes minutes ● Most chairs don’t do administrivia well, but still try – why? ● Think very seriously about appointing a WG secretary! Document editor – reflect WG consensus in specification, track and resolve issues Responsible Area Director – oversee process, products ● Called a “shepherding AD”. Think about why.. ● S/he doesn’t have to agree, but s/he has to believe you ● Keep your shepherding AD up-to-date – that’s your job “Communication is a good thing” ● I learned this in my second marriage

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 6 AD & WG Chair Authority Chair can replace document editors ● Should have the backing of AD ● Editor replacement is painful but may be required ● AD can recommend document editor replacement ● AD can strongly recommend … AD can replace chair AD can close the WG Jeff Schiller, former Security Area Director: ● “ADs have only the power to delay and destroy”

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 7 WG Chair Responsibilities Negotiate charter and charter updates with ADs Keep the processes open, fair, and moving forward Select and manage the editors and the WG to produce high quality, relevant output ● Meets published document format/standards (ID-nits) ● High technical quality and relevance/usefulness Schedule and run meetings Keep milestones up-to-date (with AD approval) Judge WG consensus “Manage up” – Track WG documents during approvals

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 8 WG Chair or Secretary Tasks Schedule meetings and plan agendas Produce minutes, return blue sheets Maintain WG milestones Manage/moderate the WG mailing list Keep track of WG work item status and make it clear to the WG ● Issue WG last calls ● Submit documents to the IESG when appropriate

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 9 Editor Responsibilities Produce a document that reflects WG consensus and meets IETF editorial requirements ● I-D Nits and RFC Editor guidelines Raise issues for discussion and resolution at meetings or on the list ● If contention, WG chair judges consensus Track document issues and resolutions ● Some type of issue tracking software or tools are recommended, but not required A lot more information in “Editor’s Training” notes

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 10 WG Chairs Training WG Chair Role and Responsibilities Chartering and Re-chartering The Working Group Process Life of a Draft After the WG Consensus and Problem Solving Making WGs Open and Accessible Resources and Administrivia

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 11 WG Formation WGs may or may not start with a BOF ● Most WGs do start with BoFs ● BoFs have to pass “the giggle test” Before chartering, WGs should have: ● Well-understood problem ● Clearly-defined goals ● Community support (producers and consumers) ● Involvement of experts from all affected areas ● Base of interested consumers ● Active mailing list

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 12 WG Charter Contents Administrative information ● Chair and AD addresses ● WG info Purpose, direction and objectives of the WG Description of WG work items Specific WG milestones

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 13 WG Charter Approval Contract between the WG and the IETF ● Regarding scope of WG ● Identifying specific work to be delivered ● Initially negotiated by WG chair(s) and AD(s) ● Sent to the community for comment ● Approved by the IESG Re-charter as needed ● Minor changes (milestones, nits) approved by AD ● Substantive changes require IESG approval

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 14 WG Chairs Training WG Chair Role and Responsibilities Chartering and Re-chartering The Working Group Process Life of a Draft After the WG Consensus and Problem Solving Making WGs Open and Accessible Resources and Administrivia

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 15 Understanding the WG Process Why do we need to reach common understanding of our processes? ● The process will work more efficiently ● The process can work more consistently ­ Leads to more actual and perceived fairness ● Distinguish between process and technical discussion ● WG members can provide useful input to complex process decisions, and keep the chairs honest This used to be really controversial stuff…

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 16 Goals of the WG Process Follow the spirit of the IETF process ● Not just the letter of the process ● Openness, fairness and progress ● WG discusses all issues/changes to work items Produce technically sound and useful output ● Raising the bar for acceptance as a WG work item ● Raising the bar for sending drafts to the IESG ● Identify problems early – less pain, more progress

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 17 Steps in the WG Process Initial Submission Author Refinement WG Acceptance Editor Selection WG Refinement WG Last Call

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 18 Steps in the WG Process Initial Submission ● Original idea or issue is submitted to the WG ­ May be done via mailing list or at a meeting ­ Should become an Internet-Draft (or part of one) ● Chairs will reject submissions that don’t fit within the WG charter, in chair judgment ­ May refer submission to more appropriate groups or areas ● Chairs should reject submissions that aren't relevant or don't meet minimal quality requirements

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 19 Steps in the WG Process Author Refinement ● Idea is more fully documented or refined based on feedback ­ May be done by the person who originally submitted the idea/issue, or by others ­ May be done by individual, ad hoc group or more formal design team ● Change control lies with author(s) during this phase

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 20 Steps in the WG Process WG Acceptance ● For a document to become a WG work item, it must: ­ Fit within the WG charter (in the opinion of the chairs) ­ Have significant support from the working group, including: – People with expertise in all applicable areas who are willing to invest time to review the document, provide feedback, etc. – Probable (or current) implementors, if applicable

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 21 Steps in the WG Process WG Acceptance, part two ● To become a WG work item, a document must: ­ Be accepted as a work item by a rough consensus of the WG – Should reflect WG belief that the document is taking the correct approach and would be a good starting place for a WG product ­ Have corresponding goals/milestones in the charter – Approved by the Area Directors

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 22 Steps in the WG Process Editor Selection ● Editor(s) will be selected by the WG chairs ­ Usually one or more of the original authors – but not always ­ Must be willing to set aside personal technical agendas and change the document based solely on WG consensus ­ Must have the time and interest to drive the work to completion in a timely manner ● Make this decision explicitly, not by default! ­ Some people are concept people, some are detail people ­ Some people start strong, some people finish strong

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 23 Steps in the WG Process WG Refinement ● Document updated based on WG consensus ­ All technical issues and proposed changes MUST be openly discussed on the list and/or in meetings ­ All changes must be proposed to the mailing list – Complex changes should be proposed in separate IDs ­ The WG has change control during this phase – Changes are only made based on WG consensus – During this phase, silence will indicate consent

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 24 Steps in the WG Process WG Last Call ● Final check that the WG has rough consensus to advance the document to the IESG ­ WG consensus indicates that the WG believes that this document is both technically sound and useful, and ready to go to the IESG ● Process BCPs do not actually require WG Last Call ­ It is a good idea, however ­ A disturbingly large number of people wait to read drafts!

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 25 Steps in the WG Process WG Last Call ● The document must be reviewed and actively supported by a significant number of people, including experts in all applicable areas ● … or it should not be sent to the IESG ● “Why would we want to waste IESG time on a document that we can’t be bothered to review ourselves?” ● Silence does NOT indicate consent during this phase

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 26 Has anyone else read the draft? Standards-track documents reflect IETF views ● Not just a working group’s view ● “Will this work on an arbitrary IP network?” Avoid the group-think trap ● Ask “who else should be reading this draft?” ● Your ADs are good sources of potential reviewers Don’t wait until the last minute to share ● Stop the “last-minute surprise” madness Some “last minute surprise” examples

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 27 When “IP” is “Intellectual Property” IPR is a land mine waiting for your WG ● Read RFCs 3667/3668/3669 ● All three are critical, 3669 is painful experience Ask contributors about IPR early and often The IETF does not require royalty-free IPR ● But many WGs prefer royalty-free IPR If you can avoid encumbered IPR, great... ●... but you still have to deliver a solution! Keep your ADs informed when claims are filed

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 28 WG Chairs Training WG Chair Role and Responsibilities The Working Group Process Life of a Draft After the WG Consensus and Problem Solving Making WGs Open and Accessible Resources and Administrivia

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 29 IESG Hand-Off After WG Last Call issues are resolved, chair submits I-D to IESG ● Mail to responsible AD(s) and secretariat Document entered into tracker in “Publication Requested” state After this point, WG Chairs can track document status in the I-D Tracker ● ● This is the best tool for WG chairs in ten years!

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 30 Steps in IESG Document Process AD Review IETF Last Call IESG Review Document sent to RFC Editor and IANA

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 31 AD Review Responsible AD reviews the document to determine if it is ready for the next step ● IETF Last Call for standards-track ● IESG review for non-standards-track Comments may be returned at this phase ● Substantive issues should go to WG ● Editorial issues may go only to Editor(s) and Chair(s)

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 32 IETF Last Call Last Call for community review and comment ● Required for all standards-track documents ● Optional for all other documents ● At least two weeks for WG output ● At least four weeks for non-WG output All Last Call comments must be addressed ● “Addressed” may not mean “document changed”

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 33 IESG Review Document is placed on an IESG telechat agenda ● Telechats held every two weeks, agenda items submitted one week in advance Each IESG member provides a ballot position ● Yes or No Objection ● Discuss ● Abstain (or Recuse) Any position may be accompanied by non-blocking comments Document passes when it has nine Yes or No-Objection positions and no Discusses All Discuss comments must be addressed before a document is published Most ADs are using Area Review Teams to process drafts

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 34 RFC Editor and IANA After the IESG approves a document, it is sent to the RFC Editor At this point, IANA can do allocations related to the approved document Be aware of reference dependencies ● Draft will not be published with drafts as references ● Dependencies may be circular ( and even indirect)

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 35 The Last Stop Before RFC Has the document changed since WG last call? ● In AD Evaluation? ● In IESG Review? ● In RFC Editor Review? Small changes are not a problem Share significant changes with the WG ● We do not do this nearly well enough today

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 36 WG Chairs Training WG Chair Role and Responsibilities The Working Group Process Life of a Draft After the WG Consensus and Problem Solving Making WGs Open and Accessible

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 37 Rough Consensus "We reject kings, presidents and voting. We believe in rough consensus and running code." -- Dave Clark

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 38 Consensus Clearly dominant agreement Does not have to be unanimous Judging consensus can be hard w/o voting ● humm ● show of hands (sorta like voting but...) Even harder on a mailing list ● ask for "humm" & provide list of hummers at end? May discard parts to get consensus on rest

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 39 If Someone Appeals Your Decision They need to do this in writing They make clear, concise statement of problem ● With separate backup documentation They make it clear that this is an appeal They make specific suggestions for remedy They do not try to jump the steps in the process ● Wait for specific response for each step Avoid personal attacks (in either direction!)

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 40 Appeal Process Process &/or technical appeal to WG chair Process &/or technical appeal to AD Process &/or technical appeal to IESG ● via to IESG list Process &/or technical appeal to IAB ● via to IAB list Standards process appeal to ISOC BoT ● via to ISOC president ● But ONLY for appeals of process violation

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 41 WG Chairs Training WG Chair Role and Responsibilities Chartering and Re-chartering The Working Group Process Life of a Draft After the WG Consensus and Problem Solving Making WGs Open and Accessible Resources and Administrivia

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 42 Openness and Accessibility WG should be open to everyone who wants to participate ● In person or via mailing list only WGs don’t make final decisions in meetings ● Consensus must be confirmed on the mailing list Not all people participate the same way ● Be aware of cultural differences, language issues... Openness and fairness of the WG process is your responsibility as chair

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 43 Structured Discussion Slides Recommend use of slides for structured discussion and consensus calls Openness includes accessibility to non-native English speakers, hearing-impaired people, etc. Written consensus questions result in higher quality and more credible responses

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 44 WG Chairs Training WG Chair Role and Responsibilities Chartering and Re-chartering The Working Group Process Life of a Draft After the WG Consensus and Problem Solving Making WGs Open and Accessible Resources and Administrivia

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 45 Required Reading RFC 2026: Internet Standards Process ● Explains document processes, appeals process, etc. Significant Updates to Intellectual Property ● RFC 3667, RFC 3668, RFC 3669 RFC 2418: IETF WG Guidelines and Procedures ● Defines WG chair role, rules for conducting WG business, etc. Keep an eye out for process changes ● NEWTRK, ICAR, PROTO (still under way)

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 46 On the Naming of Internet-drafts Traditional file name conventions: ● WG: draft-ietf-acronym-whatever ● Individual: draft-author/group-whatever ­ Draft-author-acronym-whatever if submitted to a particular WG Use these conventions! ● They are not required, but they are assumed by most ● Yes, renaming WG drafts “breaks continuity”. Sorry! WG chair must approve all initial I-D submissions before draft-ietf-acronym filename assigned

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 47 Copyrights IDs must contain RFC 3668 boilerplate ● Absolute Requirement: Any ID for standards track documents MUST permit editing by the working group ● All submitted IDs must contain correct boilerplate ISOC holds non-exclusive copyright on RFCs

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 48 WG Mailing Lists and Web Pages MUST be on the mailing list ● ftp://ftp.ietf.org/ietf-mail-archive/acronym ● Additional archive, not the only archive WG web page can include link to additional web page ● Maintain WG work item status, etc.

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 49 Web Pages to Know About WG Chairs web page ● IESG web page ● ID-Tracker ● RFC Editors web page ● A dozen important process mailing addresses ●

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 50 Continuing Education For your working group ● Newcomer’s Orientation ● Editor’s Training ● Security Tutorial For you ● Editor’s Training ● Continuing Education for Serving WG Chairs Watch out for ● “Bringing new work into the IETF”

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 51 Questions?