DRAFT general area meeting minutes - 3/22/06 chair Brian Carpenter scribes Scott Bradner and Elwyn Davies I - agenda bash Brian introduced the session & reviewed the agenda II - RFC 2434bis - Thomas Narten Thomas reviewed his proposed update of RFC 2434 "Guidelines for Writing an IANA Considerations Section in RFCs." We now have 7 years experience with the RFC. Thomas said that he has received some comments on version 4 of the ID and requested people provide him any additional comments. The proposed changes include a renaming of the IETF Consensus to IETF Review, clarifying the difference between IETF and RFC Editor documents, better examples of IANA Considerations sections, additional authority for the IESG to step in to the process, making it clear that expert review implies a designated expert, a note that appeals are to be handled via the normal RFC 2026 process, and additional information about designated experts. Pekka Savola - suggested that it might be useful to include review criteria that a designated expert should use - Thomas said that he had addressed this issue in his ID and asked people to review the current ID text Don Eastlake - asked if the ID referred to RFC 4020 on early IANA allocation - Thomas said that he felt that RFC 4020 was a reaction to problems in the routing area and might not apply widely but would review the document. John Loughney - reported on some issues with the old RFC that had come up in his working group for Thomas's information. He said that he would review the ID again and send Thomas any comments. Thomas said that he was considering adding a special section on SDOs III - PESCI wrapup - Scott Brim Scott reviewed the status of the PESCI effort since the last IETF meeting. He reported on the reactions to the ID that was published before the meeting. He said that PESCI had responded by publishing two IDs. The first one proposed a new process that used something like design teams to propose changes which would be reviewed using the current BCP process. He suggested that the place to start would be the IESG job - just what should the IESG be doing and how Kurt Zeilenga asked how the level of consensus about the output of a design team should be judged - Brian said that we could use the existing 4-week last call process Leslie Daigle asked how topics would be prioritized Peka Savola - agreed that prioritization of issues is important - maybe more than one design team should be used Harald Alvestrand- Suggested that we should accept the recommendation in the ID to start with the IESG Sam Hartman - Noted that the people who are going to be impacted by any change must be supportive of the effort. He noted that the BOF said that they did not want to require such buyin. Margaret Wasserman - Said that she felt that the work level of the IESG is an important issue. She suggested that a new team be formed rather than extending the PESCI group. Leslie Daigle - worried that the path beyond the first topic needed to be understandable to the IETF Adrian Farrel - Urged caution in the creation of the design team since membership etc can be sensitive Harald Alvestrand - said that the IETF community needs to judge the output of the design team based on deciding if the proposed change will make the work of the IETF better and that the support of the existing people "in power" should be secondary. IV - Process Issues in General - Brian Carpenter Brian discussed his personal review of existing IETF process documents. He asked for input on the question of if his review should be a RFC or kept as an ID. Paul Hoffman - suggested that it should be an RFC with a change list Margret Wasserman - said that she felt that all process documents should be BCPs and that there should be a clear separation of principles and procedures. Brian pointed to his ID reviewing RFC 2026 and asked for input. Brian said that he subtly disagreed with the PESCI recommendation to start with the IESG, he feels that we need to fix the things that impact what the IESG needs to do (e.g. RFC 2026 and 2418) first. He noted that a number of issues were already under control including the IPR effort and the RFC Editor contract. Brian floated the idea that the IETF needed a "executive committee" that had the responsibility for "corporate issues" - he also said that the he wondered if the role of AD for the General Area should be split off of the IETF Chair. Leslie Daigle - Emphasized that Brian's review was a personal one and should not be seen as something official and also noted that no one she knew had seen Brian's slides before this session. She said that there needed to be a real prod to get the community to review his review of RFC 2026. She also worried that Brian's suggestions were not fleshed out enough to support any real discussion on it. She also asked if Brian had offered anyone else time to rant in the meeting as Brian had provided for himself. Stewart Bryant - noted that the liaison process was a real issue that needed to be addressed Leslie Daigle noted that there were two recent RFCs and one ID that tried to address this issue. Margaret Wasserman expressed her opinion that anything like the executive committee would not be a good idea executive committee Kurt Zeilenga - also expressed concern about the idea of an executive committee Scott Bradner - noted that the IETF Chair was noted as the AD for the General Area in a number of BCP RFCs - i.e., he disagreed with Brian's opinion that such a change could be made unilaterally by the IESG. Brian said that he understood the feedback to be against the idea of an executive committee but it would be good to think about the chair roles. He said that he would be sure that it was clear in the minutes that this was his personal rant and not any kind of IETF Chair position V - Newtrk - where next - Scott Bradner Scott reviewed the history of newtrk including the reclassification of old standards to historic (in RFC Editor final process) and the unofficial interaction with the IESG about the ISD proposal. Harald Alvestrand objected to the text on the slide about the ISD review. Scott agreed the slide was wrong but said that he had accurately described what had happened. Margaret Wasserman said that the IESG had sent back a commentary (on the mailing list), then individual IESG members wrote to the list and Scott decided that the IESG had rejected the idea. Scott agreed with Margaret's description and said that he had come to the conclusion the same point that was made early in the session that the people impacted needed to sign off on the concept of the changes. He then went on to list the options for proceeding that included reviewing the standards track, doing additional work on the ISD idea, revise RFC 2026 to reflect what the IETF actually does or to close the working group. John Klensin - There is a choice on how to propose changes to standards track: a conceptual description (could then go on later and flesh out details - but be shot for no details) or a strawman proposal with details (then be nitpicked on details and conceptual material is lost). He said that the ISD proposal fell between two stools and both happened. He said that much of criticism came from IESG members and that he and Scott concluded that the ISD proposal could not move forward without agreements of IESG members. Margaret Wasserman said that it was important that people involved in the running process (maybe ex members) be involved in changing it (because of knowing about 2nd order effects). We need to figure out how to avoid members appearing to effectively veto progress when critiquing work in progress. Sam Hartman: Need enthusiastic participation of people involved in process (for example in the case of running code you have to engage prospective implementers): You get a change of attitude when you run an experiment to try this out rather than require an immediate and mandatory change to a new process. In particular you need to find a champion for your change within the IESG. Bob Braden: Said that he is in favor of continuing work on ISD system. He noted that the existing structure is 20 years old and isn't scaling with corpus of standards. People are finding complexity and lots of pieces and they can't find all the pieces. Newtrk tried hard but needed to take a longer deeper view on problem Scott Noted that other SDOs have been putting together lists of what makes an IETF 'standard'. John Loughney: Said that he had a problem in his working group. The general problem is that process up the standards track is taken as a principle. This has an effect that we don't change things in a draft standard because we want to get to full standard. This is a bad thing. VI - RFC Editor charter - Leslie Daigle Leslie, as the IAB Chair, provided an overview of the discussions to develop a RFC Editor charter and, later, a RFP for the function. She noted the effort to define what RFCs are that include the TechSpec BOFs. She provided a timeline for developing and reaching consensus on the charter of the RFC Editor which would be used in a RFI to be published in the May June timeframe. The RFI would be followed by a RFP and a vendor selection later this year. Leslie then reviewed the straw proposal for a RFC Editor Charter. She said that she expected that a RFC Editor Charter would go through the IETF process and be published as a BCP but that did not mean that the whole RFC Editor process, particularly including independent submissions, would be controlled by the IESG Pete Resnick - noted that there is a larger group interested in the RFC Editor than just the IETF - Leslie agreed Margaret Wasserman noted that we need to use an open process that lets the community wider than the IETF be involved even if we do not get input from all of the wider community. Elwyn Davies - noted that a number of details of the job of the RFC Editor needed to be worked out, for example the number of RFCs that we expected to produce per year. Paul Hoffman brought up the issue of RFC authors being worried about conflicting RFCs being published through the RFC Editor independent publication channel. VII - independent submissions track - Stewart Bryant Stewart reviewed the statistics of recent independent submissions to the RFC Editor and the process described in RFC 3932. Aaron Falk noted that the RFC Editor makes the final publication decision on independent submissions, it takes recommendations from the IESG but makes the final decision. Stewart then made a personal suggestion for a process for handling independent submissions. His proposal included a peer review board that would review the submission when one is first submitted. The review board would be answerable to the community. The peer review board then makes a recommendation on publication. The ID is then sent to the IESG if the board suggests publication. The IESG then reviews the ID and makes its own publication recommendation and provide a IESG note to be included in a published RFC. Bob Braden said that almost all of Stewart's proposal was currently in operation. He said that one difference was that the results of the review was private rather than public. Kurt Zeilenga - said he preferred that the process be independent of the IESG. Don Eastlake said feels the RFC Editor does a good job and he likes the current process. VIII - Long-Term Suspensions - Sam Hartman Sam reviewed his ID for long-term suspensions of the ability to post to IETF mailing list under the umbrella of RFC 3933. He said he is treating this as a way to make the experiment process under RFC 3933 easier. He said that he feels that using this type of process to perform experiments on changes to IETF process would make change easier. The particular experiment Sam wants to try involves suspending mailing list posting privileges for a period between the current 30-day and indefinite duration suspension options. He described the reactions to the last call on the ID. He said that one comment was that it was not clear that delegating this power to the IESG was a good idea and another was that the IESG already had the power. He said the power of the IESG in this area was unclear and that clarity would be good. Harald Alvestrand - said he was concerned that the Sam's current ID was too broad and that the real consistency for this type of thing was the IETF membership and not uniquely the IESG. Brian expressed the concern that there was not much discussion on the mailing list in response to the last call on Sam's ID. Margaret Wasserman said that she did not like the basic idea that the IESG should have all of the power to manage mailing lists Sam said that he agreed that additional constraints on IESG action were needed and asked Margaret what her opinion was about when the constraints should be added. Margaret Wasserman said that she was worried that there had not been enough public discussion on this topic for it to be adopted as an experiment. Thomas Narten suggested specifically solicit 5 to ten people to review the document and comment on it - he said that his arm was twistable Sam noted that we were having a very hard time changing process John Klensin said that his opinion for a long time that the community needed to give the IESG the ability to make changes and then punish them if they do the "wrong" thing. --