Summary and Action Items from IESG Retreat, May 5/6, 2006. ========================================================== The IESG met for two days, kindly hosted at Harvard University by Scott Bradner. All Area Directors were present (Russ Housley for the first day only), as well as Leslie Daigle (IAB Chair), Dave Meyer (IAB Liaison), Ray Pelletier (IETF Administrative Director), Barbara Fuller (IETF Secretariat), Marshall Eubanks and Spencer Dawkins (scribes). This summary was drafted by Brian Carpenter based on extensive notes by the scribes. 1. First impressions from the new ADs ------------------------------------- With seven new ADs this year, we collected their observations and suggestions. The email load is heavy and it's hard to avoid overlooking things. Telechats with 30 drafts are also very stressful. However, with the annual run rate of almost 400 drafts approved, and about 22 telechats per year, we are going to see 18 new drafts per telechat on average, plus any that return for re-evaluation. Some new ADs have inherited a significant backlog. Brian urged them to communicate with the affected WGs, at least to say that they are working through the backlog. The boundary between "No Objection" and "Yes" ballots could be clearer. If there are also "Discuss" ballots and only one "Yes", the shepherd is unsure of the weight of the "No Objections" in the balance. However, the IESG objective is to reach consensus, which means *discussing* the "Discuss" until a resolution is found. Small but important points can be resolved very quickly, before or during the telechat. But in case of strong disagreement between an AD and a WG, careful discussion between the parties is essential. There is concern about the resulting lack of determinism in approval times. That's why the IESG agreed on some target times in January, and now we have to make them stick. But because of the consensus goal, it's equally important to be transparent to the community while a "Discuss" is being resolved. Further, it is not clear for somebody looking at a WG Charter when a piece of work is estimated to be delivered to the community, while many other SDOs make estimated publication dates available. The IESG should consider putting estimated publication or IESG approval dates in charters, while warning that these dates may be affected by DISCUSSes and other unanticipated events. There is concern that the amount of time needed for WG facilitation and document handling makes it hard to perform enough steering. We need to ensure that cycles invested in process discussions give good value for money. We need to occasionally review the mapping of WGs to areas (as was done prior to creating RAI). The new ADs are concerned that we should do better in managing allegations of mailing list disruption and appeals (see later agenda item). There's surprisingly little guidance to ADs about managing BOFs. There is concern about the appropriate scope of security concerns (see later agenda item). Actions: 1: Decide whether an RT tracker queue for the ADs would be useful. (ADs) 2: Investigate possibility of a WG Chair address book. (IAD/secretariat) 3: Investigate link to IAB address book. (IAD/secretariat) 4: ADs to communicate with WGs/authors about backlog. (ADs) 2. Observations from returning ADs ---------------------------------- The comment about lacking time to steer was echoed. But if the IESG appears to be slow to process documents, we can't be surprised if WGs are slow to produce them. Some feel that the IESG tends to focus inwards rather than looking outward at the actual network and the actual problems. Can we work better with the IAB to mitigate this? Should we be more relaxed about publishing documents that may need revision soon anyway? Designing for perfection is doomed. We could still do better on "Discuss" management. The telechat document load is very daunting at first, but does get easier with experience. And then it is possible and rewarding to look outward and make things happen. It was noted that the IAB has the same problem working on "A" as the IESG has with "S", due to an unending stream of interrupts. The IAD underlined that he can only help with improved administration if the IESG develops requirements. 3. Consensus building (Sam Hartman) --------------------- This discussion was concerned with how the IESG can best reach decisions on contentious questions. It's preferable to reach team consensus, even though the IETF in general works by rough consensus. The IESG is used to achieving this on technical matters, where normally the dissent concerns a few ADs who can work together. We need to know how to do this when the matter is of general concern and all ADs need to be of one mind. Aspects include - we can't avoid a voice discussion if email discussion shows dissent; - we really want to avoid having to override dissent; failures of consensus can lead to ill-will; - on the other hand, not all contentious question may really deserve the time that consensus may require; - we need a neutral summary if the issue is complex, or even alternative summaries if a neutral summary can't be agreed; - we may want to choose a (rotating) facilitator who is agreeable to the dissenting parties; - it's better to have a range of options than a binary choice. As a general comment, it was felt that technical matters raised on appeal should carry no more weight than those raised during IETF Last Call; otherwise there is a fairness issue. (However, last call comments very widely in how important it is to resolve them; appeals are viewed by the appellant as the most serious of last call comments.) 4. Mailing list disruption (Sam Hartman) -------------------------- PR-actions under RFC 3683 have proved a very contentious method of handling alleged mailing list disruption. The IESG agreed that we should look at the bigger picture and at the management objective: ensuring that IETF mailing lists are effective fora for collective discussions and decision-taking. The objective is not to punish or discredit participants, but to manage and prevent disruption of normal business, as part of the IESG's day to day management role. The IESG (and list managers) need a range of management tools to respond to disruptions. The input to the AD concerned should not be a request for specific action, but rather a report of a disruption and a request for management assistance. Action: 5: Write this up for the community (Sam) 5. IAB/IESG interaction for BOFs (Mark Townsley, with input from Ted and Bernard) -------------------------------- We agreed that earlier notification of likely BOFs to the IAB is desirable, as well as discussion between the IAB and IESG *before* the scheduling deadline. For some time, the Internet Area has been asking for BOF input earlier than the official deadline, and this has been helpful. The IESG agreed to generalize this, which means getting BOF requests to ADs at leasttwo weeks before the scheduling cutoff. What the IESG would like to get from the IAB about each BOF proposal is: - general technical assessment - warning of any likely liaison issues - architectural comment - research issues Actions: 6: Schedule joint telechat (Leslie/Brian) [Done, for June 1st] 7: Send message asking for BOF requests by May 22 (Brian) [Done] 8: Advertise the BOF wiki this time (Mark) 9: Use Friday breakfast for early heads up on *next* IETF's BOFs. 10: Update Secretariat meeting timeline for IETF 67 (Barbara) 6. AD Assistants (Lisa Dusseault) ---------------- We have a draft job list developed at the January 2006 retreat. However, discussion showed no consensus that off-loading these jobs to non-engineering staff would really be better than investing the same resources in better tools or asking the secretariat for increased assistance. The conclusion was to give the job list after refinement to Ray as a functional requirement rather than as a hiring request. The raw job list was: - Consistent publication request management (submission, ID-nits checking, etc.) - Support for milestone tracking - Sending out "agenda for xxx-directorate reviews" - Ensure WG chairs do short session summaries of their meetings at IETF - Ensure WGs have proper agendas online, with a reading list and clickable pointers to documents - Ensure proper minutes and slides get submitted for meeting proceedings - Maintaining area-related scheduling (deconflicting IETF week meeting scheduling, conference calls, etc.) - Support for interim and area meetings - Clerical I-D tracker tool support and for WG Chairs/Secretaries: - Meeting scheduling and coordination - Document tracking - Milestone tracking support Action: 11: Refine this list (Lisa) 12: Work the list into Secretariat and tools plans (Ray) 7. Standards process issues (Brian Carpenter) --------------------------- The IESG discussed how to make progress in the newtrk work, which has been stalled for some time. The conclusion was that the first step was to get a sense from the whole community what aspect should be tackled in priority, and Brian was advised to open a debate on the IETF discussion list with a view to a plenary discussion in Montreal. It was also commented that a strong incentive to adopt any changed process would be to have convenient tools available for the authors and WG chairs expected to use it. There seems to be significant interest in the community in working on mailing list management issues (see above discussion of managing disruption) and Brian expects a mini-BOF on this in Montreal. The ipr WG is continuing to debate the derivative works issue, which is the only major IPR issue still needing clarification. There are also people in the community ready to work on updating WG procedures (RFC 2418) and minor updates to Nomcom procedures (RFC 3777). The IESG suggested that the output documents of the PESCI team could conveniently be published for the record as independent submissions to the RFC Editor. 8. WG document quality and review issues. (Lisa Dusseault) ----------------------------------------- The concern behind this discussion was that documents sometimes emerge from the WG process with a variety of serious problems, and then get hung up in IESG discussion. It was asserted, perhaps exagerratedly, that 10% of all documents take up 90% of the IESG's time. The question was: what can be done to limit these problems, so as to reduce the cost of producing documents of acceptable quality? The goal is to significantly improve the quality of documents before they leave the WG for IESG review. In an ideal world, no WG document would ever attract an IESG "Discuss." What can be done in the real world to get closer to this goal? The IESG had a long discussion on this topic, split over several sessions. An initial sub-topic was a review of the "red team/blue team" experiment that the IESG tried some time ago, in which documents were selectively reviewed by subsets of the IESG. It turned out that this was not a significant time-saver for the IESG and of course did nothing to improve the quality of incoming documents. The IESG reconfirmed that its job is apply final quality control (see for example comments later on the need for due diligence in security review). Some level of quality loss in return for speed is OK. But what is very bad is when serious problems in architecture, design or even usefulness are found during IESG review. This argues for early review for such issues, in order to "blow a loud whistle" before enormous effort goes into the document. (This is not of course a new argument.) On the other hand, early review must not lead to frustration because an early review says "X" and a later IESG review says "Not X". There is a need for consistency in the criteria used, and certainly many of the DISCUSS criteria are irrelevant for early review. On the other hand we might want to be tougher on some things in early review (e.g. architectural blunders). As a practical matter, Bill showed a plot indicating that most editorial activity in the life of a large, complex draft occurs early in its life. This suggests that "big issue" review at that time can be most effective. Also it was noted that at IESG review time, small documents are likely to get more thorough review than big ones - a big document's best chance of thorough review is early in its life. The IESG then discussed how early review should be managed. It is fairly clearly a WG responsibility even if review is wider than the WG members. There's a question whether we have a set of area review teams, or a general review team. (Always in addition to specialist teams such as MIB doctors.) Brian observed that his proposal for a general review team sent to the WG Chairs list in February met some degree of consensus: http://www1.ietf.org/mail-archive/web/wgchairs/current/msg04173.html This makes it clear that early reviews have no special status in the process - they are just input to the WG. However, they can act as the "loud whistle" for the AD who can then steer the WG if necessary. The ideal moment for early review may be somewhere after the WG adopts a draft and before WG Last Call, but those are the only identifiable triggers today. In principle, the WG Chairs should know when early review is appropriate. [Note added later - draft-ietf-proto-wgchair-tracker-ext addresses this directly.] The IESG believes (based on Gen-ART experience) that volunteer early reviewers can be found, but that a dispatcher will be needed. Action: 13: Follow up on the February proposal in the light of this discussion (Lisa). 9. The Need for Better Security Considerations Guidance (Dan Romascanu) ------------------------------------------------------- Dan observes that some 35% of DISCUSS comments are related to security. It's clear that authors and WGs need more guidance earlier in the process. The real meaning of BCP 61 (RFC 3365) is unclear to many, and BCP 72 (RFC 3552) can't be doing its job. Also, there sometimes seem to be discrepancies between advice given by security advisors and later review comments by security ADs. One observation is that the IESG feels obliged to perform due diligence on security. Even though RFCs carry a disclaimer of warranty, we don't want to publish RFCs with security weaknesses. Hence the frequent requirement for mandatory-to-implement security which vendors may find onerous. Ideas for improvement: - update RFC 3552, perhaps as a web page; - define requirements for a security review, to help both authors and reviewers; - revise EDU security materials to clarify when/where strong security matters, how to design security into protocols; Action: 14: Dan to repeat his talk for SAAG. 10. Congestion control and path changes (Magnus Westerlund) --------------------------------------- Transport protocols and especially congestion control mechanisms were designed assuming the same path throughout a session. Path changes due to routing changes or mobility can result in congestion control state getting out of step with the real path state. For example this can force TCP into slow start for no good reason. Should we do something to allow the network and routing layer to signal changes to transport protocols or even to application layer? Or is this a problem that doesn't really need solving, because transport and real-time applications are sufficiently adaptive already? Opinions vary, and this is not a new topic. Ted pleads that we don't push such complexity to applications, which mainly don't want to care, apart from adaptive codecs. Brian points out that some applications might at least benefit from a good/lousy bit and that we are not forbidden from defining APIs in the IETF (although we usually choose not to). Lars asks what additional information from the network abstraction gives the upper layer most value. Partial solutions have been proposed in the past. There is a risk of partial solutions being touted as global solutions. We first need to winnow the solution space, and answer key questions (does the network layer ID change, are we discussing transport layer adaptation only or also application layer, etc.?). The conclusion was that this topic may be ripe for a preliminary BOF but is nowhere near ready for IETF or IAB work - IRTF follow-up may be appropriate. Action: 15: Have the INT and TSV ADs try to create a dialog with the community about the general topic. 11. Network management complexities. (Dan Romascanu) ------------------------------------ The current management framework has a number of limitations: - device-centric (and very much focused on routers) - vertical (operator-management app to device) oriented - very much based on one 'push' model protocol in what concerns configuration management operations while: - 'horizontal' control protocols proliferate at all layers from sub-IP OAM to transport and application end-to-end signaling - vertical provisioning functions are developped trying to perform "autoconfiguration" by reversing the SNMP client-server direction (or pull vs. push) The majority of these protocols are developped in the IETF, but in isolated islands or layers. A few in other SDOs that are taking over or re-using the IETF work. All re-invent again and again the same concepts, metrics, discovery procedures, etc. and face similar security threats that they solve in an inconsistent manner. Can we reduce the mess by trying to define a new management framework that is not stuck on a single vertical model and tries to bring together the different paradigms into a more versatile architecture, with identified components, a common discovery and security model? Is this achievable? Would it help? Other SDOs have done related but different work, for example the two different information models developed in DMTF and TMF. Also, independent efforts such as WBEM/CIM have taken place while the IETF has been focussed on SMI/SNMP. But SMI/SNMP's scope is limited to device-centric usage. It was felt that it's time for a change of approach in the IETF, from a reflexive "write a MIB" to a proactive "design for manageability." One of the key design aspects of management is the data model, and the choice of data model can be crucial. For example, decide whether a MIB, an LDAP structure, or a non-IETF solution is the best way to model a particular protocol. The protocol to use for management will follow from this rather than being SNMP by definition. Action: 16: Write a draft for the community, organize informal discussion (Dan) 12. Housekeeping issues. ------------------------ - IAB liaison Four people expressed interest. To be settled in the next telechat. - getting some more narrative scribes on board. Action: 17: Brian to draft and send solicitation [Done] - IESG mailman list management. Action: 18: find a volunteer (Bill, Brian) - new-work list management Action: 19: See if existing list manager will continue (Dan) [Done - he won't] - draft-iesg-vendor-extensions This draft needs to be revived as a general draft on protocol extensions done outside the IETF. It seems to concern the IAB as well as the IESG and certainly concerns the WG chairs. Action: 20: trigger IAB discussion (Brian) - draft-iesg-discuss-criteria It was noted that this is aimed explicitly at standards track and BCP documents. We are less crisp about what justifies a DISCUSS for informational and experimental documents, although some feel that the criteria should be broadly similar but less strict. The criteria for RFC Editor submissions are clear enough in RFC 3932 (and very limited). Action: 21: one more update (Jon) - conference bridges for ADs These would be expensive if provided commercially by IASA for all ADs. At least one free service has been identified which has been used with success. There was no decision to provide bridges for everybody, but any AD with serious problems should contact Ray. - reviewing actions from the January retreat Actions: 22: Write and maintain the IESG wiki (All) [Is now set up as an IESG project, with a list of outstanding items in the wiki itself] 23: Dashboard prototype by Dallas (Tools team) [Now Montreal] 24: Tracker gripes to be sent to the wishlist. (All) [Ongoing] - reviewing the IESG project list The IESG reviewed the projects at http://unreason.com/jfp/iesg-projects.html and updates were agreed. Jon Peterson observed that without "next action" dates in place, he can't help people track their projects.