file: /ram/wgchairs.sxi date: 6 november, 2004 slide 1 spencer dawkins tektronix...

File: /ram/wgchairs.sxi Date: 6 November, 2004 Slide 1

Spencer DawkinsTektronix

[email protected]

WG Chairs Training

Original slides from Margaret WassermanThingMagic

[email protected] is responsible for the dumb parts


My Checkered Career at IETF

Working Group co-chair for PILC (with Aaron Falk)● BoF in Dec 1998, concluded in Dec 2003

Produced 7 RFCsSurvived four co-chair sponsor organization changesSurvived regime changes (AD and IETF chair)Survived editor thrashing on major draftsSurvived RFC Auth-48 with 16 text resets/142 e-mail● 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


WG Chairs Training

WG Chair Role and ResponsibilitiesChartering and Re-charteringThe Working Group Document ProcessLife of a Draft After the WGConsensus and Problem SolvingMaking WGs Open and AccessibleResources and Administrivia


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?


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 issuesResponsible 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


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 chairAD can close the WG

Jeff Schiller, former Security Area Director:● “ADs have only the power to delay and destroy”


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


WG Chair or Secretary Tasks

Schedule meetings and plan agendasProduce minutes, return blue sheetsMaintain WG milestonesManage/moderate the WG mailing listKeep track of WG work item status and make it clear to the WG● Issue WG last calls● Submit documents to the IESG when

appropriate


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


WG Chairs Training

WG Chair Role and ResponsibilitiesChartering and Re-charteringThe Working Group ProcessLife of a Draft After the WGConsensus and Problem SolvingMaking WGs Open and AccessibleResources and Administrivia


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


WG Charter Contents

Administrative information● Chair and AD e-mail addresses● WG e-mail info

Purpose, direction and objectives of the WGDescription of WG work itemsSpecific WG milestones


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


WG Chairs Training



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…


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


Steps in the WG Process

Initial Submission

Author Refinement

WG Acceptance

Editor Selection

WG Refinement

WG Last Call



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



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



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



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



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



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



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!



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


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


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 oftenThe 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


WG Chairs Training

WG Chair Role and ResponsibilitiesThe Working Group ProcessLife of a Draft After the WGConsensus and Problem SolvingMaking WGs Open and AccessibleResources and Administrivia


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” stateAfter this point, WG Chairs can track document status in the I-D Tracker● https://datatracker.ietf.org/public/

pidtracker.cgi● This is the best tool for WG chairs in ten

years!


Steps in IESG Document Process

AD ReviewIETF Last Call IESG ReviewDocument sent to RFC Editor and IANA


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)


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”


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 commentsDocument passes when it has nine Yes or No-Objection positions and no DiscussesAll Discuss comments must be addressed before a document is publishedMost ADs are using Area Review Teams to process drafts


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 documentBe aware of reference dependencies● Draft will not be published with drafts as

references● Dependencies may be circular ( and even

indirect)


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 problemShare significant changes with the WG● We do not do this nearly well enough today


WG Chairs Training

WG Chair Role and ResponsibilitiesThe Working Group ProcessLife of a Draft After the WGConsensus and Problem SolvingMaking WGs Open and Accessible


Rough Consensus

"We reject kings, presidents and voting. We believe in rough consensus and running code."

-- Dave Clark


Consensus

Clearly dominant agreementDoes not have to be unanimousJudging 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


If Someone Appeals Your Decision

They need to do this in writingThey make clear, concise statement of problem● With separate backup documentation

They make it clear that this is an appeal They make specific suggestions for remedyThey do not try to jump the steps in the process● Wait for specific response for each step

Avoid personal attacks (in either direction!)


Appeal Process

Process &/or technical appeal to WG chairProcess &/or technical appeal to ADProcess &/or technical appeal to IESG● via email to IESG list

Process &/or technical appeal to IAB● via email to IAB list

Standards process appeal to ISOC BoT● via email to ISOC president● But ONLY for appeals of process violation


WG Chairs Training



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


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


WG Chairs Training



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)


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


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


WG Mailing Lists and Web Pages

<acronym>[email protected] 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.


Web Pages to Know About

WG Chairs web page● http://www.ietf.org/IESG/wgchairs.html

IESG web page● http://www.ietf.org/iesg.html

ID-Tracker● https://datatracker.ietf.org/public/

pidtracker.cgi

RFC Editors web page● http://www.rfc-editor.org/

A dozen important process mailing addresses● http://www.ietf.org/secretariat.html


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”


Questions?

file: /ram/wgchairs.sxi date: 6 november, 2004 slide 1 spencer dawkins tektronix...

Documents