|
General Area Open Meeting (genarea)
Monday, August 2 at 1530-1730 ============================== Chair: Harald Alvestrand <harald@alvestrand.no> Agenda: 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... - July14 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 - Draft-hardie-alt-consensus Passed as Experimental ? interesting to see if it will be used - draft-ymbk-downref Allows standards-track documents to refer to info documents, etc. Was hung up on definition of "normative" Approved as BCP - draft-iesg-vendor-extensions 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) - www.edu.org - 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 proto-team@ietf.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 |