--On Tuesday, August 09, 2011 15:49 -0500 Pete Resnick
<[email protected]> wrote:
>> Barry Leiba explained the status of
>> 5321bis-smtp-pre-evaluation. I gather that it is clear that
>> the document cannot be published as a RFC as it was
>> discussed by the IESG as a management item.
>
> It would have to be put on a telechat as a WG document. It
> could conceivably be published after that. But let's not get
> hung up on the process point. I don't think that document was
> written in a way that was intended to be published, and I
> doubt the IESG would be too thrilled with it in its current
> form.
>...
> First, I want to say that in the room in Quebec, there was a
> *STRONG* feeling that the amount of pain and energy needed to
> continue work on any item other than 4409bis, and 5321bis in
> particular, *FAR* outweighed the benefit of doing the work.
> Though Dave only +1'ed, he expressed rather strong feelings in
> the room on this topic.
Pete, Subramanian,
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. 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.
Use that I-D as a living document to consolidate and summarize
discussions and conclusions, to draw errata together, and, where
appropriate, to record suggestions about specific textual
changes to 5321. Discussions of which suggestions are
appropriate can use the SMTP list or a residual YAM one at your
preference.
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.
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.
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.
-- 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
