On 10.08.2011 00:51, John C Klensin wrote: > Let me suggest a possible alternative which is workable independent of > whether we keep the WG going: > > -- If the sorts of suggestions that Barry, Alessandro, Mykyta, and maybe > others have made for revision have an traction beyond those who proposed > them, let's find an editor and record keeper (perhaps Barry if he is so > inclined; I think it is actually better if it isn't me) and revise and > update 5321bis-smtp-pre-evaluation.
Agreed. Considering the difficulties of having a 5321bis according to plan A, the best option for SMTP seems to be to publish a revised version of 5321bis-smtp-pre-evaluation. > If the plan is to shut the WG down (and I'm with the others in the meeting > consensus on that subject), let the designated editor put it out as an > individual draft. Perhaps, we could as well do it quickly enough to not delay the WG shutdown considerably. I concur with SM that we should avoid prolonged discussions, and a time constraint gives that. Do we need to recharter to put the revision as a WG draft? An individual draft for SMTP looks inadequate. > The editor and other interested parties agree that > 5321bis-smtp-pre-evaluation-bis is an appropriate place only for editorial > and other changes that would be appropriate for an upgrade from Draft-> > Full Standard or, at most, for recycling in grade at Draft. Any proposal > that contains even small elements of new features or changes to > requirements gets written up in a separate draft and the authors/ > proponents work with you (or whomever the sitting AD is) to figure out how > to get it processed. Similarly, those who want to see 5321 revised in > order to provide a comprehensive roadmap for SMTP (I interpret a few of > the suggestions as being along those lines) are free to generate a new > "roadmap" draft and see if they can get traction, but we don't use > 5321bis-smtp-pre-evaluation-bis as a vehicle for that purpose. Now, what kind of RFC will the revised pre-evaluation become? I'd guess a Proposed Standard that updates RFC 5321. Suggested textual changes contained therein may be clarifying and illuminating, but they will still be less "mature" than RFC 5321 itself. Hence, variations on the interpretation of SMTP, if there are any, could be conveyed through the same document, for the sake of simplicity and compactness. I've been looking for proposed changes not mentioned in the pre-evaluation doc, but cannot tell anything worth being mentioned, now that SM has added #24. Thus, I'm missing the "comprehensive roadmap for SMTP", as well as the "new discoveries that are so bad that they absolutely have to be incorporated". It has been repeatedly said that this list is the right place to raise any such issue, therefore they ought to be here. I'd suggest that the new doc includes an informative section where they are explicitly mentioned, if the relevant proponents post admissible text in the limited time frame that remains. Admittance to such section would require consensus that an issue is worth being /contemplated/ for 5321bis, which is different from being ready for Full Standard as the presently-numbered issues are. For clarity, let me add that I don't oppose to separate drafts for proposals that deserve one. The additional section I propose is meant to actually grant a chance to any half-baked issue that wouldn't be put forward otherwise, so as to take a correct position fix for SMTP. > At some point in the future, when the celestial omens align correctly, we > open 5321 and perform the relatively simple job of folding in editorial > changes that appear to have been agreed upon, then see if we have > consensus to publish with those changes. Oh well, judging by the relative simpleness thus surveyed, I'd reckon that point in the future must still be quite far :-) > That model would accomplish several things, including... > > -- It would get 5321bis out of the perceived critical > path for shutting down YAM. It would also get questions > about the future of the standards track out of that > critical path. > > -- It would reduce or eliminate the likelihood of having > substantive arguments about what 5321bis should say > (substantively) going on at the same time as we are > trying to agree on how to say it. Trying to do the two > at the same time is one of the reasons the document is a > mess today. > > -- Various ideas that have been proposed for inclusion > for 5321bis but that would be very controversial (at > least), and possibly inconsistent with advancing the > document, have a chance to be put forward separately and > to mature. This strategic accomplishment alone can justify plan B, IMHO. > -- It would permit making progress on the outline and > general content of 5321bis without any risk of > interfering with, or waiting on, EAI, DKIM, and perhaps > other efforts that at least vaguely interact with it and > that draw on many of the same resources. > > Is that helpful? > > john _______________________________________________ yam mailing list [email protected] https://www.ietf.org/mailman/listinfo/yam
