On 3 Aug 2011, at 10:33, S Moonesamy wrote: > I'll summarize the discussion about shutting the YAM WG. There was a solid > consensus on the question of shutting down [1]. J.D. Falk and Dave Corcker > did not object to it [2] [3]. I read the messages from Alessandro Vesely as > an objection.
I've just skimmed this discussion. So far it does not seem to me really worthwhile worrying about whether YAM is shut down or not, since 5321BIS is nowhere near any kind of reviewable condition (and I *need* a reviewable document, one which I don't have to edit for, so someone would have to be behind it sufficiently to edit for me to bother). The pre-evaluation stuff is purely advisory and is basically just a load of errata. That's not enough of a reason to keep YAM alive, now. Whether documents separately updating 5321 or a single document implying future work on 5321 is used is irrelevant because we can't get good input without it. And anyway, I'm against the rush implied by finishing before the closure of YAM. I have a dim suspicion that's part of why there were some minor but notable problems with 5321 in the first place. (And I find it ironic that such a "Simple" protocol really isn't.) > The question on the table is whether there is an chance for the WG to pursue > work on 5321bis before it is shut down. Barry mentioned that it's a pity to > waste the work that was done and that he would really like to see the current > version of SMTP back at full Standard level [4]. He also volunteered to edit > 5321bis document, incorporating the changes from the pre-evaluation document. Well, splendid! But can we get on and shut down YAM first? :-) > Does the working group think that it is reasonable to give it a go? > > I haven't seen any objection to the changes mentioned in the pre-evaluation > document. John Klensin commented [5] on the description of the extension > model in 5321. That is the kind of change which Barry described as "new > discoveries that are so bad that they absolutely have to be incorporated". > > I am open to having the work done. That presumes that the working group is > agreeable to deferring the question of shutting down. If there is interest > in putting two months in this work, the working group could do the following: I don't like the time pressure and the implied limit on possible "Productivity" that could result. I want this document to be a full standard. I want this document thoroughly vetted. I want any major concerns addressed. I *do not* want this document tainted by lots of new and dangerous ideas unless the proposals come from people willing to put them into other documents. If YAM has no identifiable purpose until more work is done, let it die. We can't recharter. We need a discussion forum for any proposals. We know RFC 5321 is "Good enough" (TM) so we already have a strong reason to keep the work fairly focussed and minimal. The current pre-evaluation is a very good starting point. > (a) Each WG participant posts a list of proposed changes together with the > rationale for the change. The WG avoids any discussion of the proposed > changes at this stage. > > (b) I'll list each proposed change in the issue tracker. If there are two or > more changes that are similar, I'll track them as one if people agree. > > (c) Once the WG has a list of issues, it can estimate the time required to > get the work done and how to deal with the issues. > > The above work can be done under the current charter. Or we can just kill YAM and leave its mailing list open, and get back to you when we have a list of stuff that absolutely must go into 5321BIS, having discussed it thoroughly in the course of discovery, or with what we already have in the pre-evaluation doc. This has the added benefit of making the editorial work easier. If the problem is energy, there's no further discussion. The motivated people (and as I've said, something to look at is my real need) will happily bring the finished proposal to the table, as usual. Just my two-penneth. Cheers, Sabahattin _______________________________________________ yam mailing list [email protected] https://www.ietf.org/mailman/listinfo/yam
