Yet Another Mail Working Group Minutes Meeting : IETF76, Wednesday 11 November 2009 Location: ANA Crowne Plaza Hotel, Hiroshima, Cattleya West, 09:00-10:30 Chairs : Tony Hansen Minutes : S. Moonesamy Version 1.0 AGENDA A. Meeting Administrivia Note well Agenda bashing B. Discuss how our process is working Alexey Melnikov Dave Crocker C. Next Steps Wither the working group? Template changes? D. Any Other Business Meeting Report A. Meeting Administrivia Tony Hansen chaired the the IETF76 YAM Working Group meeting in Hiroshima, Japan; the co-chair, Chris Newman, participated remotely. S. Moonesamy was the scribe. Barry Leiba was the Jabber scribe. The Chair brought the Note Well to the attention of the meeting participants and asked them to sign the blue sheets. B. Discuss how our process is working Alexey Melnikov, Applications Area Director, mentioned that some of the old Area Directors and the new Area Directors did not understand how the process was supposed to work. The question of whether current IESG members can bind future members was raised during IESG discussions. There was confusion about the process. The Applications Area Director reported that the IESG found the format of the pre-evaluation document suitable. He stated that it is better to list the changes not to be done so that the IESG can think about them in advance. He also mentioned that the IESG got distracted by discussions about security considerations. The discussions was not really productive as they turned to everything that could possibly go wrong. The IESG will be processing the pre-evaluation documents as Management items. The Applications Area Director proposed to take two moderately complex documents and do one using the two step process and do the other using the normal process and see whether we get variation in speed and try to analyze why. The Working Group would then know whether the process experiments works or not. Dave Crocker, author of draft-ietf-yam-rfc1652bis-pre-evaluation, viewed the tone of responses from the IESG as complaints instead of a collaborative effort to improve things. The Working Group could choose to challenge the process but that would be seen as a social statement about entering a state of war with the IESG. It was mentioned that the IESG, as a whole, did not agree to be constrained by the process used by the YAM Working Group. John Klensin asked whether the Area Directors that decided that they do not want to be constrained been identified by the NomCom was asked. Dave Crocker, who is a NomCom member, declined to answer the question. John Klensin questioned whether it was acceptable for individual IESG members to hold documents for long periods of time because of some hobby horse that they mounted very late in the process and without any justification from IETF Last-Call. He pointed out that changing the process requires a major revision of the charter. Barry Leiba pointed out that the chartering process already binds future IESGs. Pete Resnick discussed the IESG being seemed uniquely tied to the procedures and the rules and the tools that the IESG uses. It is odd for the IESG to complain that the Working Group is doing things differently when the purpose of the process experiment is to do things differently. There is a view within the IETF that moving anything to Full Standard is not a regular process and that the process ends when a document gets to Proposed Standard. C. Next Steps The Working Group viewed it as worthwhile to take a commitment given the maturity of the documents being progressed along the Standards Track. There was a comment that the choice is between either doing that work or revising the Standards Process. There was some comments from the room about EPP. John Klensin mentioned that the specifications are uncontroversial as nobody outside its community cares. The situation is different for email as everybody in the IETF who works with email has opinions and participants in the IETF including some Area Directors believe that there are experts because they are using email. He is in favor of an expedited fast track model instead of bringing the documents to Full Standards against an IESG that is not really interested in Full Standards except insofar that they get to second guess everything every time a document comes to them. The Applications Area Director mentioned that there were discussions during this year's IESG retreat about why moving documents to Full Standard is so difficult. He reassured the Working Group that there is a strong feeling within the IESG that it is important to help move documents to Full Standard. If the work on the SMTP document is done within six months, it would be easier as two-thirds of the original IESG have reviewed and voted on it for Draft Standard. John Klensin pointed out that several members of the existing IESG agreed to change their vote and not to raise objections on moving that document to Draft Standard on the condition that changes would be made when the document went to Full Standard. There is a need to consider the larger issues carefully. Dave Crocker reminded the Working Group not to be distracted from its goal and to go and do the actual work without the effort of a recharter. The Area Director mentioned that the IESG would not nit-pick about a recharter if the Working Group wants to use a one-step process. John Klensin disagreed and pointed out that such a decision could be appealled. He was pessimistic about the experiment but he agreed that it is worth trying. He noted that from a political standpoint, it is better to take the question of the behavior of the IESG when moving complex documents about which the community cares to Full Standard to the community and get it out of the YAM Working Group. Barry Leiba suggested taking the IESG on their word and continuing the experiment by working on the SMTP document. He volunteered to take on the document if John Klensin had any reason to pass the document off. Although he questions the value of the three-step standards track, he believes that it is important to take RFC 5321 and RFC 5322 to Full Standard is that RFC 821 and RFC 822 are at Full Standard. Speaking as an individual, Chris Newman commented that if the YAM Working Group re-charters, he would like the pre-review replaced with text providing equivalent functionality. He suggested a first draft for the recharter: When the WG attempts to move a document from draft to full standard it will only make minor technical corrections deemed necessary to better align with the installed base. In the event changes the WG believes have a substantive risk of breaking backwards compatibility are deemed to be blocking by the IESG, the WG will remove the document from processing and its charter. In the event all documents are removed from the WG charter, the WG will write a narrowly drawn update to RFC 2026 that eliminates the third level of standard; this update document is forbidden from making other changes in the standards process. Presently, he support continuing with the pre-review experiment. The Applications Area Director commented that the text is excellent and that he is tempted to recharter with it. The Chair called for a multi-voting to find the sense of the room with a four way hum and asked for comments before the hum on: 1. Do you want to disband? 2. Do you want to recharter to a one-step process before continuing? 3. Do you want to continue working but do as Alexey suggested in his original slides and do one step versus two step comparison of two different documents? 4. Do we continue with the current course on the next set of documents in the two step process? Dave Crocker mentioned that the Chair left out the question that some Working Group participants considered it as reasonable to continue a one-step process without rechartering. John Klensin suggested a slightly different refinement which is to go ahead and put the template for RFC 5321 into the hopper as it is the most complex and probably the most controversial document the Working Group has which responds directly to the IESG's request to do that. He called for the Working Group to be disbanded if the IESG responds to that template by saying yes this looks find but we reserve the right to make any changes we want or any demands we want during and after Last-Call. Pete Resnick agreed with John Klensin and suggested a variant which is to work on RFC 5322 as it is a big document but not as controversial. Pete Resnick suggested having a hum before getting into a discussion about the relative controversy of the documents. Dave Crocker suggested changing the humming process because the classic problem of making list of decisions is that it is not quite the right one. He proposed: 1. The first is disband or continue. 2. The second is keep the charter or revise the charter. 3. And the third is depending on the other one, is what to do if we keep the charter or what to do if we change the charter. The Chair pushed back on that. The Applications Area Director pointed out that there were so little people in the room and asked for a raise of hands. The Chair asked the following questions: 1. Who wants to disband? 2. Who wants to flat out switch to one-step process whether we do a recharter or skip the recharter? 3. Who wants to follow Alexey's original suggestion of doing a comparison step with two documents, one that does a one-step process and the following does a two-step process? 4. Who wants to continue with the two step process for the next couple of documents? The first and third questions did not get any votes. There was one vote for the second question and four votes for the fourth question. There was not enough time to discuss specific changes to templates that came up on the list. The next set of documents are SMTP, Mail Format and Submit. The Chair only has the pre-version of the template for RFC 5321. Randy would only be able to do Submit in about three weeks. Pete has not provided the template for RFC 5322 yet. John Klensin pointed out that the experiment with RFC 5321 is very important due to the nature of its controversies. The Chair asked for a raise of hands on doing: 1. RFC 5322 only 2. RFC 5321 only 3. Both RFC 5321 and RFC 5322 There was three votes for each of the questions. The Chair ruled that there was no consensus. D. Any Other Business This item was not discussed as there was not enough time. The Chair ended the meeting.