Subject: [yam] Use of errata mechanisms for 5321 (and probably other things)

From: John C Klensin <[email-masked]>
Date: Tue, 08 Sep 2009 12:53:50 -0400

Hi.

Some participants in this WG have apparently decided that
submitting errata on 5321, even when the subjects have already
been discussed in the WG, is an appropriate way to get things
done.  In fact, all that sort of action accomplishes is to cause
more work for authors (and hence, less prompt responses to
discussion on this list and less prompt postings of I-Ds of
5321bis) and the RFC Editor.

In order to save time, unless Alexey has a preference to the
contrary, for any matter in which there is the slightest doubt,
I'm going to reject the errata and refer the issue to this
mailing list.  For clarity, I have more than "the slightest
doubt" about any issue less obvious than "typographic error" or
"comma out of place" including requests to move material from
one section to another.

While this is, more or less, the last chance to fix errors, it
is also an "opportunity" to create new problems by making
changes that appear relatively small and harmless but that may
have significant side effects.

If possible, let's focus discussion on this list rather than
trying to use the errata process to make suggestions or log
complaints.

I suspect that similar comments apply to other documents if
errata are in use, but I'll leave it to their editors --or the
co-chairs or AD-- to speak for them.

   john

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 09 Sep 2009 11:53:09 +0200

> 5321bis) and the RFC Editor.

I apologize for having caused unnecessary work. I thought an erratum 
could just stay there like a Post-it, somewhat more orderly than a 
parenthesized item inside a message about a different topic.

> "comma out of place" including requests to move material from

My purpose is to promote any change in RFC 5321 that would result in 
better consistency or readability of the the final standard document. 
I hope this intent is common to all participants, and that your 
attitude to reject meaningful changes is limited to the errata --not 
the whole revision process. Actually, my impulse to resort to some 
different means came after feeling a certain resilience in the mailing 
list, so that I thought I was better off not bothering it more than 
duly, for the time being.

> have significant side effects.

SMTP went through a major restructuring as its usage and abuse grew to 
unprecedented levels. Although mail reliability is currently in 
jeopardy, the protocol has the potential to allow effective anti-spam 
solutions. However, some passages are difficult to read and may seem 
inconsistent, which might be ascribed as a reason why existing 
anti-spam solutions are not widely deployed. In particular, passages 
that result from the effort to restructure the protocol while keeping 
compatibility as much as possible, tend to appear obscure to readers 
who were not familiar with RFC 821.

I think quality and comprehensibility of the specification can be 
amended without creating new problems. However, that may require an 
appropriate amount of time. To wit, if a passage is so difficult to 
understand that it requires a lengthy discussion, it may be better to 
unfold its correct meaning within this WG and then publish a clearer 
standard, than let equivalent discussions happen various times among 
users of an obscure standard. Is this a correct interpretation of the 
YAM charter description?

---

From: SM <[email-masked]>
Date: Thu, 10 Sep 2009 08:12:34 -0700

Hi Alessandro,
At 02:53 09-09-2009, Alessandro Vesely wrote:
>  errata --not the whole revision process. Actually, my impulse to 
> resort to some different means came after feeling a certain 
> resilience in the mailing list, so that I thought I was better off 
> not bothering it more than duly, for the time being.

Sending Post-it notes to John Klensin may not be the most effective 
way to reach the desired outcome.  :-)

>understand that it requires a lengthy discussion, it may
>  be better to unfold its correct meaning within this WG and then 
> publish a clearer standard, than let equivalent discussions happen 
> various times among users of an obscure standard. Is this a correct 
> interpretation of the YAM charter description?

I'm not interpreting the charter.  There is a lengthy discussion on 
another mailing list because of one word.  And it is not because the 
passage is difficult to understand.  The point missing in the above 
is that the person has to convince the other people that the quality 
and comprehensibility is better and that the amendment is not going 
to create new problems.

Ned provided some good advice.  A tiny bit of common sense is required.

Regards,
-sm