Re: [yam] Referencing 1652bis and update to RFC 5321/5322

[John C Klensin <[e-mail]>]

--On Sunday, June 27, 2010 11:20 AM +0100 Alexey Melnikov
<[e-mail]> wrote:

> [Moving this discussion to YAM and changing the subject.]
> 
> SM wrote:
> 
>> At 16:17 26-06-10, John C Klensin wrote:
> 
>  [...]
> 
>>> For these and others, let's make sure we remember (the Nits
>>> checker will presumably do that for us, but not actually make
>>> changes until it is absolutely, 100%, clear that 1652bis
>>> will be published.  In particular note that, while it is in
>>> the RFC Editor queue, it is stuck in MISSREF waiting on
>>> 5321bis and 5322bis, for neither of which there is even an
>>> active I-D yet (I expect that will be cured for one or both
>>> before IETF 78, but one should not count on that until it
>>> happens).  Also note that if the IESG, in its wisdom,
>>> approves
>>> draft-housley-two-maturity-levels in the next month or two,
>>> the YAM WG enters the "overtaken by events" stage and
>>> 5321bis and 5322bis (and probably even the
>>> supposedly-approved 1652bis) become more effort than they
>>> are worth to finish.  Having the distinction of being the
>>> last full standards approved by the IETF under a set of
>>> rules that are being phased out does not seem to me to be
>>> likely to be treated by the responsible editors as worth the
>>> trouble.  That is, of course, just my opinion.
>> 
>> I don't know what will happen to the maturity levels.  The
>> MISSREF  could be cleared.
> 
> Yes, this particular MISREF can be cleared at any time by
> asking the RFC Editor to use published RFCs.
> 
> I have a more fundamental question for this WG: are people
> still going to be interested in updating various email specs
> if 3 muturity levels are replaced with 1 or 2?
> (I understand that that would mean rechartering, but that is a
> relatively minor point.)

Speaking for myself only, the changes called for by this group
and the preevaluation documents so far would probably be
time-consuming to get right (and get agreement that they are
right) and would undoubtedly improve the quality of the
documents, they are, in the grand scheme of things, largely
cosmetic.  Specifically, little or no evidence has been offered
that the present text is causing serious implementation or
interpretation problems.   Even if such evidence appeared around
a few points, the problems could be solved with short and
focused documents clarifying those particular points rather than
revising and reissuing the base specifications.

If the community (or the IESG because, based on experience with
the POISSON, NEWTRK, and IPR efforts, I do not expect clear
community consensus about anything) came to the conclusion that
the additional quality improvements that result from moving
documents through the review and approval process three times
were not worth the effort, I'd almost certainly respect that
conclusion.  In other words, without community recognition that
examining and revising documents twice after Proposed was worth
the trouble, I don't see any reason to believe that treating
these documents as a special exception would be a good
investment given other work that could be done with the same
resources.

I also note that several of the items on the preevaluation lists
(or in queue for those lists) were changes that the IESG
insisted upon as a condition for moving to the next level.  If
that level were eliminated, those demands would either become
moot (reducing the incentive for revisions) or would turn into
obviously unjustifiable and arbitrary demands to satisfy
personal preferences (_really_ reducing the incentive to slog
through editing and approval of revisions).

Again, just my opinion.

    john