General Area Open Meeting (genarea)
Monday, August 2 at 1530-1730
Chair: Harald Alvestrand <email@example.com>
1530 Introduction, agenda bashing, selection of scribe (Harald)
No agenda bashing occurred...
1535 Review/status report (Harald)
- Overview: What's happened since Seoul?
IETF mission statement ? approved as BCP on Saturday, hope this doesnít come as a surprise to anyone about what the IETF is doing...
Passed as BCP, "almost" used for draft-hardie-alt-consensus
Not sure what changes to the IETF standards process need to be approved by ISOC BoT
Are people covered by IETF liability insurance when we experiment? Weíll investigate. ISOC doesnít have a standards VP anymore ? we need to forward a suggested motion for their approval, after all the lawyers look at it
- Mailing list management
Passed as BCP, not used yet (this is not a bad thing)
No longer require complete IESG approval to suspend mailing list privileges for any amount of time
Passed as Experimental ? interesting to see if it will be used
Allows standards-track documents to refer to info documents, etc.
Was hung up on definition of "normative"
Approved as BCP
What extension mechanisms are appropriate for protocols (Diameter, BGP, LDAP...)
Still being discussed in IESG
- RFC Editor document expediting
Has reduced the backlog of RFC-Ed documents and IESG heartburn significantly
Approved as BCP, in use (in draft form) since April
Makes RFC Editor responsible for fixing documents that donít conflict, but the IESG doesnít like
- IESG Red Team/Blue Team experiment
(no draft) ? half the IESG are reviewing info/experimental documents via AD or WG
Team assignments appear in ID-Tracker
- ICAR and NEWTRK in separate working groups
ICAR ready to experiment
NEWTRK discussing short-term suggestions (moving to historic, etc.)
- likely action item to turn informal advice into july14 experiment write-ups
- no "small changes" currently in queue
1550 Report from the EDU team (Margaret Wasserman)
- team working for about 18 months, chartered after Vienna IETF 57
- does several classes, both open (on agenda) and closed (for working group chairs)
- Newcomers training, editorís training, WG chairs training, security tutorials
- Continuing "smiley face" experiment
- charter updated/renewed in July 2004
- have added local-language sessions, as appropriate
- Plans for coming year ? make presentations more accessible via the web, improve pointers to training
- New sessions ?
"bringing new work to the IETF", including what not to bring
"IETF Protocol Engineering Fundamentals", beyond security (congestion control, internationalization, MTU issues in tunneling ? what else is often wrong in IDs?) ? start with class and work down, or start with documents and work up? Or meet in the middle...
- work with ISCO Standards Publications and Resources committee for a periodic joint publication on major activities of the IETF
- Training on process changes in the IETF (ICAR, NEWTRK, etc.)
- and we are looking for people whoíd like to work with the Edu team, especially people with publication experience
Q&A (a lot of these were very general questions)
- How many people attend these classes? From 25 to 80 at this IETF, depending on the class (over 200 people at the Korean session in Seoul)
- Tool questions from XML2RFC? Thereís an excellent mailing list ? should this be a tutorial, or included in a tutorial
- Training on decision-making process, especially in WG chairs training? Bad process has bad consequences ? is it time for this? In Wednesday lunch sessions?
- Mailing list management? How does this fit into the appeals process? Can be appealed like any other WG chair decision, through a well-defined escalation process
1620 Report from the PROTO team (PROTO team) ? Aaron Falk
- Was Process and Tools, but now thereís a tools team, too
- small team, of six members ? details at www.mip4.org/proto
- have been running shepherding pilots (WG chair document write-ups, WG chair handling AD evaluations, WG chair handling IESG DISCUSS comments)
- have published a shepherding manual (insert draft name here)
- have gotten feedback from 13 documents
- check www.mip4.org/2004/survey, but feedback was positive (need more experience for statistical analysis
- Aaron also presented comments from pilot participants
- lessons learned ? pilot will be expanded (more ADs, more WG chairs), single pilot will combine all previous pilots for greater continuity
- WG chairs like transparency
- Need to watch for situations where author is also shepherd
- Pilots require management ? work is involved in getting participants to participate
- AD attentiveness is key for pilot success
- Next steps ? consolidate and extend pilots (8 ADs are willing to participate already)
- Not sure what metrics we should be using
- Feedback to firstname.lastname@example.org
Did any of the guinea pigs think the pilots were adding too much work? Definite small increase, but well worth it.
Process of moving beyond a trial? Should be BCPs, but the team isnít chartered to create them. But the pilots donít violate existing BCPs ? IESG internal process, doesnít even need to be a BCP.
Is this under July14? Can it be documented as a BCP by next IETF? Maybe premature at this point. The participants to date have been hand-picked while we worked out the mechanics. Should we try it on a larger scale? We may not know whether this is generally applicable for a while.
This does change the expectations for working group chairs ? itís an empowerment, not an extra burden.
WG chairs do (should be doing?) a lot of shepherding already ? isnít this additional work pretty minor? Are there any real risks? Well, WG chair may not know ADs with DISCUSS comments, may have different vocabularies with an impedance mismatch that slows things downs. Need to focus on making sure we donít drop balls, not on playing middleman in a conversation.
ADs didnít appreciate how opaque the end-of-process process is, even to hand-picked WG chairs!
Most maddening part of WG chair and document editor role is the inconsistency of it all. We couldnít even switch to RFC 3667/3668 without chaos, and we donít process enough documents to get good at it! We need consistency, and we can do more work with consistency than with inconsistency.
Canít have 200 working group chairs running on verbal lore ? the guidelines matter, and thatís why the pilots arenít moving faster.
Who DOESNíT want to participate? No one raised their hands...
1640 TOOLS team - concept discussion (Henrik Levkowetz)
Charter at ietf.levkowetz.com/team/tools/
Providing feedback from IETF and guidance during development of software tools for IETF processes.
Will consider an ID submission tool first, looking for input on additional needs (issue tracking, etc.). Tools will be developed by the secretariatís developers, and we need to bring them in touch with the IETF community (today, they arenít).
Guidance may be done by specifications, storyboarding, prototyping, or other methods.
The team will report to the IETF community periodically.
Where do people who use the tools provide inputs? Whatís the feedback process? Will use a mailing list for this ? should we do something else? Issue tracker for tools we develop?
What does ID submission tool look like? Secretariat requirements come from secretariat members, IETF community requirements come from us. Would be good to get inputs from IPR community, they went over some of this ground already.
What about ICAR review process support?
What about PROTO team work support? Need writeable access to ID-tracker for shepherds.
Tool for resolving WG meeting time conflicts? ("classroom scheduling")
Tools for mailing list management? "Strongly seconded."
Tools for tools?
GGF thought they needed tools a while back ? not a single WG chair in GGF is using them. Be careful about believing someone has the solution.
Henryk has some pretty nice tools for tracking WG draft diffs, nit-scanning, ties to ID-tracker.
1700 Team concept - is this a formalizable mechanism? (Harald)
Weíre doing a lot with teams, with no formal definition of what a team is, how itís formed, etc.
Writing down rules is a mistake ? too many types of teams.
Would be nice to at least FIND teams on the IETF website, for instance. Some formal description could be good.
"Teams have no formal legitimacy."
May need to rev the IESG charter to allow this, if we go forward with formalizing the definition. Probably a single sentence is sufficient.
IESG is using teams to do stuff they are responsible for ? as long as there is feedback loop available.
Weíre not just formalizing teams; weíre making them visible to the community. This could be easier.
We can either allow people to gather together and do useful things or have authorization for formalization ? not both at the same time.
Teams use substantial IETF resources ? can any team start serving lunch to the community? IETF chair can do this, IESG not needed and not authorized to do this stuff anyway. July14 is sufficient.
Used to be a lot of Internet Engineering Task Forces ? we grew out of one of them. Need some formality ? at least time limits.
Listing is nice, web pages are good. If the IESG already has a responsibility, just doing it via teams is OK. If itís a new responsibility, a working group is appropriate.
Do nothing? Document that teams exist? Create a procedure? Room consensus is "document that teams exist".
1715 Any Other Business, Summary of next items (Harald)
- Obscured domain names on mailing list archives arenít obscured when we download entire archives ? havenít done anything about FTP archives, and we probably need two archives, one providing a complete record of the discussion for the IETF ? this makes it harder to join a discussion late. Weíll leave the archives as they are.
1730 Meeting ends