Subject: Re: RFC 2119 violations and DRUMS mismanagement

From: Scott Bradner <[email-masked]>
Date: Tue, 4 Aug 1998 10:32:49 -0400 (EDT)

Just to ward off more mail asking if Dan is quoting me correctly, he is,
but let me put my comment into context.

When I wrote the original ID that became RFC 2119 it did not include the
text in section 6:

    6. Guidance in the use of these Imperatives

        Imperatives of the type defined in this memo must be used with care
        and sparingly.  In particular, they MUST only be used where it is
        actually required for interoperation or to limit behavior which has
        potential for causing harm (e.g., limiting retransmisssions)  For
        example, they must not be used to try to impose a particular method
        on implementors where the method is not required for
        interoperability

I received mail from a number of people suggesting that this was an ideal
place to comment on the tendency for some IETF specification writers to put
text into their specifications which restrict implementation choices
without a specific requirement to do so for interoperability or security
reasons.  I agreed to add the above text to warn against such over
specification.  But this text is not meant to restrict the author of an RFC
from specifying behavior which may not be strictly needed for
interoperation but which is useful in ensuring robust operation.  I think
that it is rational and consistent with the guideline in 2119 to add
"SHOULD" provisions when there is evidence that following those provisions
will aid in interoperability in even marginal cases.

A quick look at the ID in question shows a number of places where SHOULD is
used that seem to not be required for security or interoperability reasons
but I have not followed the DRUMS discussions and do not know if there are
unexplained reasons for some of the SHOULDs.

Scott

---

From: Dave Crocker <[email-masked]>
Date: Tue, 04 Aug 1998 09:30:02 -0700

>unexplained reasons for some of the SHOULDs.

Indeed, the real problem here is an unhappy working group member who does
not wish to accept the very strong consensus judgements of the group.  As
occasionally happens, the recourse chosen by such a participant is to
create a public stink.  

To the extent that such challenges are claiming failure to follow
procedure, it is worth noting that sending a complaint to the IETF list
does not, itself, conform to recommended procedures for resolving such
challenges against working group process.

As one who is not part of the DRUMS working group management, and as one
who has no financial interest in particular outcomes -- although I must
note some amusement at that particular effort to undermine the working
group chair's credibility, since all of us have financial interests in
these activities -- let me state clearly and strongly that the DRUMS
working group chair has been extremely diligent and constructive in his
management of the process.  In fact he has been quite good at maintaining
his, and the working group's, equilibrium in spite of extremely painful
disruptions from at least one participant who seems unable to post a note
without criticising other participant's competence, motives or genetic
history.

I would strongly urge that this thread be moved immediately off of the IETF
mailing list.  I am only including the list in my note so that there is
some record of a counter-point to Mr. Bernstein's unfortunate posting.

d/

_________________________________________________________________________
Dave CROCKER                            <mailto:[email-masked]>

Tel: +1 408 246 8253     BRANDENBURG CONSULTING      Tel: +60 19 329 9445
675 Spruce Drive         Fax:  +1 408 273 6464        P. O.  Box 296, UPM
Sunnyvale, CA 94086       www.brandenburg.com     Serdang, Selangor 43400
United States                                                    Malaysia

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 Aug 1998 02:29:42 -0000

Let's try an example.

The smtpupd draft, like RFC 1123, defines a simple type of mailing list,
and requires that all SMTP servers let their users build such lists.

To the extent that this requirement matches user demands, it is useless.
To the extent that it doesn't, it is imposing extra implementation costs
for no benefit.

Why should LISTSERV, for example, be required to support naive mailing
lists without bounce protection? And why should firewall implementors
waste time and code to provide a feature that their users don't want?

I shouldn't have to ask these questions. There is no interoperability
excuse for the requirement. It's a barrier for new implementors. It
violates RFC 2119. The editor should have immediately rejected it.

Dave Crocker writes:
> not wish to accept the very strong consensus judgements of the group.

This requirement is _not_ the DRUMS consensus. I recall objections from
Eric Thomas (LISTSERV), Jim Conklin (listproc), Philip Hazel (exim), and
of course myself (qmail).

The particular type of ad-hominem attack shown above, misrepresenting
the DRUMS consensus to avoid rational discussion, is standard practice
for a few people on the DRUMS mailing list.

> all of us have financial interests in these activities

I don't.

Frankly, I don't see why any MTA implementor, let alone an implementor
such as Newman with a financial interest in the results, should be
allowed to chair an MTA working group. How does the IESG expect to
protect itself from lawsuits?

---Dan

---

From: "Perry E. Metzger" <[email-masked]>
Date: Tue, 04 Aug 1998 23:02:58 -0400

> protect itself from lawsuits?

Given that none of the "problems" you are complaining about induce any 
financial hardship on anyone or have any financial impact, I believe
this is a moot point. Unless someone directly involved in the
standards process gets financially harmed, there is no basis for a
suit seeking financial damages. The difference between whether an MTA
is required to wait for a response to QUIT or not does not in any way
give a financial advantage to anyone.

Perry

---

From: Craig Partridge <[email-masked]>
Date: Tue, 04 Aug 1998 20:46:15 -0700

Given the flurry of notes, I took a little time this evening to read
draft-ietf-drums-smtpupd-07.txt and my conclusion is that it isn't
ready for prime time.

Like Dan, I object to the strong perpetuation of aliases -- a bad idea --
mailers should protect users from mailing list errors -- we've known this
since the early 1980s -- let's work on stomping out bad practice by
deprecating this.

The use of must and should seems somewhat unsteady -- and certainly not
up to RFC 2119 standards.  I counted over 30 uses of "must" instead of
"MUST" -- and in many of those cases, "MUST" was appropriate.

There's a common quote "the better is the enemy of the good" -- and
if this spec were the first attempt at SMTP I'd argue it was ready to
ship.  But this isn't the first attempt -- we have good specs and the
goal is to produce a better one.  This spec isn't much better although
it is getting close.

Craig

---

From: Robert Elz <[email-masked]>
Date: Wed, 05 Aug 1998 18:00:58 +1000

Date:        5 Aug 1998 02:29:42 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | > all of us have financial interests in these activities
  | I don't.

You do.   Not as directly as some others perhaps, but as an implementor
of a SMTP implementation that is used by more than just one or two others
you have some degree of reputation at stake.  Reputation can be converted
to cash - and thus you have a financial interest, whether or not you ever
decide to take advantage of that.

I would agree however that the "all" is perhaps too strong, I don't think
I can find any financial interest that applies to me (except just possibly
that my organisation probably spends $'s on e-mail implementations, and thus
could be affected).   I have a personal implemenation that I work on from
time to time, but I don't distribute it (or not widely) - it isn't of the
appropriate quality.

kre

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 5 Aug 1998 14:17:07 -0400

Let's try an example.

I'm not 100% sure which feature you're referring to, but if it's mailing
list aliases, it's a SHOULD, not a MUST (which follows RFC 2119), and
given that aliases are used for things other than just simple mailing
lists, I'd claim it's a good thing.

In any case, if you're not happy with the process, why don't you take it
up with the relevant Area Director, instead of complaining on the IETF
list?  That would be following approprpiate perscribe process, after
all.

							- Ted