IESG Retreat Notes -- April 28th/29th, Geneva Attendees: Brian Carpenter, Mark Townsley, Sam Hartman, Allison Mankin, Jonathan Peterson, Ted Hardie, Leslie Daigle, Bert Wijnen, David Kessens, Dave Meyer (IAB liaison), Alex Zinin, Bill Fenner, Scott Hollenbeck, Barbara Fuller (Secretariat), Margaret Wasserman, Russ Housley Apologies: IANA and RFC Editor liaisons Notes edited from raw notes by Margaret Wasserman ----------------------------------------- AGENDA: 1. Technical Topics 1.1 What's our "big picture" technical goal and how does that help to define what's in and out of scope? [This is not an NGN discussion but will illuminate some aspects of that discussion.] 1.2 Can we launch a more global security model? How can we ensure that there are no security gaps between what the IETF defines and what other upper or lower layer bodies define? SIP security, identity, consent framework BGP Security Using the AAA infrastructure for SNMP authentication Security Mechanisms WG proposal, EAP 1.3 TRILL status 1.4 SLRRP status 2. Management topics 1: how to manage the IESG workload ** 2.1 IASA/IAOC status report (Leslie/Brian) How to bring the IAD up to speed? What jobs are most urgent to delegate to the IAD? 2.2 Any value in the red/blue team approach or in draft-iesg-alvestrand-twolevel? - can we delegate more responsibility for document quality and cross-area review to the WG Chairs? - other ideas to reduce AD workloads? 2.3 IESG chairing, and generally, role conflict for the IETF Chair? 2.4 Telechat format, any reason to change? Can we become more efficient in resolving issues prior to the telechat? 3. Management topics 2: Meetings ** 3.1 Are the plenaries less useful than before? 3.2 WG meeting logistics (more effective f2f time usage, as Alex proposed) 3.3 Future meeting planning (status report) 4. Management topics 3: Operational ** 4.1 The ISD proposal from NEWTRK - also, do we need NEWTRK to take radical action about the standards track? - policy on independent submission RFCs (another topic floating around in NEWTRK) 4.2 Short term measures re RFC Editor backlog 2223bis 4.3 "Operational Procedures" documents (Brian's proposal) 4.4 BCP on how to write interoperability reports. 4.5 Requirements and framework documents 4.6 Criteria for DISCUSS 4.7 Criteria for Experimental 5. Overflow and other topics 5.1 BGP Security (deferred from earlier) 5.2 Security Area WG 5.3 ISOC Annual Report -------------------------------------- 1. Technical topics 1.1 BIG PICTURE: Discussion of scope of IETF work. Is scope defined as how high/low we are willing to go in the stack? Is it decided by the text in RFC 3935? Is it decided by the interest and expertise of the IETF community? We mainly do pieces/parts -- how do we decide which ones to do next? Pieces/parts can also be considered like items of clothing (they fit into places in the general architecture). How can we interact with other bodies/technologies more effectively (for example, could we have better considered web services for NETCONF)? How should we react to items that arrive here with thrust even if we don't like them at first sight (e.g. SOAP)? Would SOAP have been a better protocol if developed in the IETF? This may be something that both the IAB and IESG should discuss. Need to strike the right balance between point solutions and more general solutions. (Fenner's law) Conclusions: We still generally agree with the text in RFC 3935, particularly: In attempting to resolve the question of the IETF's scope, perhaps the fairest balance is struck by this formulation: "protocols and practices for which secure and scalable implementations are expected to have wide deployment and interoperation on the Internet, or to form part of the infrastructure of the Internet." We need to consider our resources when making decisions about whether to do work. We might need to consider taking on potentially disruptive technologies (especially ones with "thrust"), even if we don't agree with them, because we will then have some influence over how they are specified. What is the boundary between us and other standards bodies? We should consider the "API" or service model when we take on work, since that tends to define the trechnical interface to the work of other bodies. We want to encourage innovation. We should not discuss what we do as "pieces/parts", but as "elements of the Internet Architecture". These elements need to be well formed, long lasting and appropriately extensible. This can be a question we use to decide what we do: Is this an element of the Internet architecture? How people perceive us effects what they bring to us. We may need to do more to handle how we are perceived. We need to prepare for a joint IAB/IESG follow-up discussion in Paris: Allison and Dave Meyer will work with Brian and Leslie on this. 1.2 SECURITY MODEL: Security ADs and Jon have been discussing this for months. Concern that current IETF protocols do not encourage (and perhaps do not allow) an integrated authentication/security model for IETF protocols, let alone integration with security models for non-IETF protocols. Discussion of comprehensive identity model and how this applies to a generic security model. One topic of the Liberty Alliance SAML work. We need to understand/review SAML and make sure that it will be applicable to IETF protocols, such as SIP and GEOPRIV. How should the data flow between GEOPRIV and SIP? Both ways. Is work needed in the security area on a more general security model? The specific security topics listed in the agenda were all touched on in the discussion, except for BGP security which was deferred (see below). Conclusions: There is no fundamental objection to the idea of holding a BOF on the topic of approving new security mechanisms and better unification between existing frameworks. Obviously, a BOF description should be circulated. There also doesn't seem to be any objection to Sam doing technical work in this area about a security model for HTTP, etc. 1.3 TRILL: Inappropriate to discuss technical/scope aspects of TRILL in this setting, because we do not have proposed TRILL chair present. It was confirmed that the TRILL chair must be included in ongoing email discussions. Would it make sense to create this as an IETF group with an explicit liaison relationship with one (or more) IEEE groups? Or should this be a new beast: a joint IETF/IEEE effort? Discussion seems to indicate that, if this is chartered it should be done as an IETF group with a strong liaison relationship with the IEEE. How does this make the Internet better? We need to ask the list? Do we know the criteria that we are using to determine if this is in scope? ACTION ITEM: Margaret to send questions to the list. ACTION ITEM: We will all include Erik in future discussions. 1.4 SLRRP: Discussion of possible overlap with EPC Global. Scott has a call in the works shortly. How do we determine what the overlap is if we can't see the EPC Global documents? Other issue about scope -- do we want to specify management protocols for different types of end-node devices? Why SLRRP devices and not other sensor-type devices? As with TRILL, need to involve the protagonists in that discussion. Should we talk to EPC Global about whether or not a liaison relationship makes sense to advise them about work that they are doing with IETF protocols (ONS, SNMP MIBs)? At least, we need a conversation. 2. Managing IESG Workload 2.1 IAOC report Leslie and Brian reported on progress in setting up the IASA and in particular on hiring the IAD. Since this is largely a personnel issue, it isn't reported here. 2.2 AD WORKLOAD ADs have discretion to use directorates or advisors. We discussed whether there was a need to formalize this into a two-level delegation system, but concluded that there was no workload advantage in formally changing the primary role of the Area Directors. The red/blue team experiment (in which half of the IESG was relieved from reviewing each Working Group Informational/Experimental - by team) was briefly reviewed: it didn't seem to have substantive effect on workload or throughput, during the particular experiment. Discussion of review teams and possible division between "steering" and "review". Discussion of discuss criteria and why it is damaging for the IESG to fundamentally question a document's assumptions at the end of the process. (This is also later in the agenda, we got a bit out of order here.) The IESG doesn't want to second-guess WG consensus, but has a responsibility to deal with serious cross-area issues even if they are discovered late. This issue moved to a discussion of early review, due to concern that we are still hitting "late surprise" issues after WGs have completed work on a document. Would it be useful to document the criteria for early review, so that chairs can use it as a guide to soliciting early review? Should we revist Alex's proposal for area-based early review? And recycle the criteria developed in ICAR? Can we create some responsibility for solicting early review in the document editor or WG chair role? Concern that WG chair and editor may not have the knowledge/awareness needed to understand what type of early review is needed. Also, WG chairs may not want to do more than is required to serve the WG's narrow interests. Ted suggested that we could create a cultural shift towards early review by having new WG drafts announced to the whole IETF, so that this becomes an IETF event. Conclusions: It is not the IESG's job to question basic assumptions/decisions of the WG when we know that those assumptions/decisions have been discussed in the WG. We should not be second-guessing the WG. We can ask them to consider things if we don't know if they have considered them, though. General agreement that we should implement a mechanism to announce newly accepted WG documents and encourage review at that point. Kept as simple as possible. ACTION ITEM: Allison, Brian, Sam and Mark will write up the new WG draft announcement/review mechanism. They will coordinate with Bill and the EDU team about this. 2.3 IESG Chair DISCUSSION There can be times when combining the roles of IETF Chair, General AD and IESG Chair can lead to potential conflict of interest. When this happens, who should lead the IESG to form a consensus and who should communicate the IESG's decisions? Does this need a new position to be defined? Brian agrees that this is a valid concern, but thinks that this discussion is a little premature, given that the IETF chair role is changing due to the creation of the IAD role. We should revisit it when the IAD is up and running. [Comment added after the meeting - obviously I will recuse myself from the IESG Chair if there is a clear case of conflict of role - BC] Some discussion about the IANA coordination team. There seemed to be general agreement that it is okay for Thomas to continue participating in the IANA team, even though he is no longer on the IESG. No action items or specific conclusions, other than the idea that we should revisit this when we have more experience with the IAD. 2.4 TELECHAT FORMAT Discussion of how to make the discussion more effective. Conclusions: Barbara will check into how much work it would be for Amy to collect timing information for the next couple of telechats -- how much time are we really spending on each item? (Barbara) Change the way that we ask whether discussion is required for a given document -- just ask sheperding AD, not each person holding a discuss. Not all discusses need to be discussed on the phone. (Brian) Change the order of the telechat to put management items before WG news we can use. (Brian) Change the tracker to automatically send discuss comments to the IESG mailing list. (Bill) Work with the Secretariat to design and implement a summary page for each AD that lists his or her position for each document on the agenda of the next telechat. (Bill) 3. Meetings 3.1 PLENARIES Discussion of usefulness of plenaries. Can we remove/reduce operational statistics? We have an obligation to report them, as long as it's brief, and it is good for the community to have a direct connection with the operations No consensus to reduce to one plenary. Rough consensus that we should borrow the GGF terminology of "town meeting" for at least the IESG Q/A session. 3.2 Discussion of efficiency of WG meetings. Alex is working on an experiment for alternate meeting room configurations with Marcia. We will also try to have more roaming radio mics in Paris. Conclusions: We also need to reinforce well-known rules for running meetings with the WG chairs. ACTION ITEM: Margaret to distribute RSVP list for ongoing WG chairs training to IESG, so that we can know who does/doesn't attend. 3.3 FUTURE MEETING PLANS Concerns about network planning for Paris. Barbara or Brian should get Jim Martin, Lucy or someone with IETF networking experience to work with France Telecom on this. There is a tentative meeting planned for May/June. If none of the folks with IETF networking experience can go, Mark may go. ACTION ITEM: Barbara should let Brian know whether Jim can do this. We may have similar concerns in the fall WRT Vancouver. Area directors should ask folks from the Asia-Pacific region which countries are harder or easier for them to reach. The IESG will work with the Secretariat to determine (by retrospective analysis) how site selection affects attendance at future meetings. (Purpose: to improve the site-selection process) 4. Operational management topics 4.1. ISDs/NEWTRK Brian presented slides from the ISD authors (draft-ietf-newtrk-repurposing-isd-03.txt) A short summary is that the IESG recognizes the problem that is being tackled but has issues with the proposed solution. However, to be constructive, the IESG wants to discuss possible ways forward to achieve some or all of the desired results. Assuming newtrk meets in Paris, IESG members will make a best effort to be present. Conclusions: We agreed that we haven't reached a clear consensus on these issues that we can communicate to the WG chair or WG. Brian will draft a response after the meeting. ACTION ITEM: Brian to draft response based on notes. 4.2. SHORT TERM RFC EDITOR MEASURES There was concern that RFC publication is taking too long, for a variety of reasons. Some possible short term measures were discussed. One option would be to give the document shepherd (AD or WG chair) better visibility into where the document is in the editing process. They should be able to understand why it is taking so long. The paper handling of copy-editing seems inefficient and involves mark-up for compliance with a particular style manual. Does the IETF want to follow a style manual, or simply accept generally correct English? Does the copy editing have enough value to justify the costs (both $$ costs and time of ADs, chairs and authors)? Mistakes are introduced during copy editing and this may actually reduce the quality of the document if they are not caught. Should the IESG have the choice between "light" and "heavy" copy-editing when it approves a draft, i.e. if the style is considered acceptable as-is then instruct the RFC Editor to avoid all stylistic edits? Any changes in this area would need to be discussed with the community, via the IAB which is responsible under its charter. Brian noted as General AD that the revision of RFC 2223 is on hold. 4.3. OPERATIONAL PROCEDURES NOTES General agreement about updating/posting the operational procedures in a consistent way. It was noted that quite a few operational documents need updating. ACTION ITEM: Brian to make precise request to Secretariat. 4.4. BCP ON INTEROPERABILITY REPORTS There is some inconsistency about what level of interoperability testing is required for protocols. What does it mean to test that every feature has been implemented? There is a document that describes how to write MIB interoperability reports (RFC 2438). ACTION ITEM: Alex will edit the document and/or find someone to do it. 4.5. REQUIREMENTS AND FRAMEWORK DOCUMENTS Discussion of how/when these documents are useful. There is pushback on writing them, and they are often considered to be superfluous. But there are cases where they are useful. Should we avoid asking for them? Or do we need to ask for them in some cases? Sometimes the level of consensus around framework documents is unclear. They can be published as Info with no IETF last call, which may not always be appropriate. Some organizations focus a lot of effort on use case documents. Suggesting a requirements document has become an easy stall tactic. Not clear that we can reach any conclusions here. This discussion was just to raise our awareness of the fact that these are used in some situations where they are inapporpriate. We should be careful about when to use them, and we might consider use cases instead of requirements. 4.6. DISCUSS CRITERIA (currently an IESG internal note) Agreement in the IESG that we should publish this document to the community (as an informational document, not a BCP). Not clear if this should be an RFC or just an operational note -- start with an I-D. We need to make the status (informational only) clear in the top of the document. We also need to make it clear that we are interested in community feedback. ACTION ITEM: We should comment on the internal note over the next two weeks. Then Jon will do an update, and publish as draft-iesg-*. 4.7. EXPERIMENTAL RFCS: There is a stigma associated with Experimental status. May be interpreted as an indication that the technology is dangerous. This may be appropriate if we really don't think that people should implement the spec, except for experimental use. Sometimes used for documents that we just don't have energy to finish. Other documents (RMT docs) stay at experimental, even when they are in use because the WG is not sure that the documents are ready for standards track. The criteria for Experimental status in RFC 2026 need interpretation. An IESG internal note states that we use this for actual experiments (with criteria for evaluating results) and/or for cases where we may publish as standards track later if the protocol is successful. This seems to miss the case where we put documents in Experimental because they are contentious and/or because they are not suitable for publication on the standards track. ACTION ITEM: We should comment on the internal note over the next two weeks. Then Brian will do an update, and publish as draft-iesg-*. Side Note: We should put dates on our operational notes. 5. Overflow and other topics 5.1 NEW SECURITY WG ("New Hash" Group) New effort being proposed, with active NIST participation, to charter a new security WG. With the understanding that this will be an IETF effort (in accordance with usual IETF procedures), there was agreement that we should pursue this work within the IETF Security Area. A two phase approach was discussed to ensure that the necessary participants are engaged. The first phase would specify the way to truncate larger one-way hash function output so that it can be used as a replacement of a shorter one-way hash function output. The second phase will be pursued only if it is clear that the cryptographic community will participate. The second phase will specify one or more new one-way hash functions, following a model similar to the AES competition. Major effort, may take 3 years.. ACTION ITEM: Security ADs should send us a charter. 5.2 BGP SECURITY There are two proposals -- SBGP and SOBGP (??). One is from the security group and another is from the routing area. Should have a BOF to determine what approach (one, the other or a hybrid) is likely to gain traction with implementers. At this point, each group is accusing the others of stacking the requirements to support their solution. Work would be done outside of current IDR WG. Action in this area is important. We may want to talk to our PR department about how to make sure that governments and others are aware that we are making progress on this. If we want the U.S. Dept of Homeland Security or any government to help us with this, we need to make it clear what they can do. 5.3. ISOC ANNUAL REPORT Peter Godwin is about to go to press with the ISOC annual report. It will include a sidebar on IETF achievements in 2004. In general, Peter is available to assist with any public relations we wish to do. ACTION ITEM SUMMARY: Allison & Work with Brian and Leslie to prepare for joint Dave IAB/IESG follow-up discussion on the scope of IETF work for Paris. Margaret Send technical questions to the TRILL list. All Include Erik on further discussions of the TRILL charter. Allison, Brian, Write up the new WG draft announcement/review Sam & Mark mechanism and coordinate with Bill & EDU Team. Barbara Find out how much work it will be to extract timing information from the recordings of the next couple of telechats. Brian Send clear instructions to Secretariat on agenda order changes. Bill Work with the Secretariat to on summary page for each AD that lists his or her position for each document on the next agenda Bill Increase priority of the sending e-mail to IESG from tracker for discusses. Margaret Distribute RSVP list for WG chairs training to IESG. Barbara Find out if Jim Martin will be able to attend a meeting with France Telecom in May/June. All Work with the Secretariat to determine (by retrospective analysis) how site selection affects attendance at future meetings. Brian Draft IESG response regarding ISDs based on the notes from this meeting. Brian Make precise request to Secretariat about Operational Procedures page Alex Write a BCP on interoperability reports or find someone to do it. All Provide feedback on the DISCUSS Criteria. Jon Update DISCUSS criteria after two week comment period and publish as draft-iesg-*. Brian Update EXERIMENTAL criteria after two week comment period and publish as draft-iesg-*. Russ & Sam Send us a charter for the new security WG.