--On Thursday, 21 June, 2007 15:53 +0100 Tony Finch
<dot@xxxxxxxx> wrote:
> On Thu, 21 Jun 2007, John C Klensin wrote:
>>
>> (2) Section 3.1 contains a MUST requirement for availability
>> of the message submission port (RFC 4409). While I am a firm
>> believer in RFC 4409 and look forward to the point at which
>> we can put out a document that deprecates the use of SMTP
>> (RFC 2821) for message submission by clients that do not
>> support full SMTP services (for many more reasons than spam
>> mitigation), we aren't there yet, and a MUST requirement
>> definitely does not represent current practice.
>
> It does represent *best* current practice, and I think it it
> reasonable to say that a site is not conformant to
> draft-hutzler-spamops if they don't support RFC 4409. I don't
> think this document is trying to say that all sites will have
> to adhere to all the MUSTard, just that they can't claim to be
> following best current practice if they don't.
>...
Tony (and Dave)...
Please reread my introductory note. I think all of the
recommendations are fine. My problems are with classifications
and language only, with "language" including a few things where
I think the document is a little more vague than it should be,
especially around Security Considerations. I'm also nervous
when you respond to a remark by giving your rather specific
interpretation of terms like "based on": not because I disagree,
but because the presumed audience for a document like this
presumably includes those who don't already know the answers and
the IETF's thinking.
I don't think repeating all of this helps: if the IESG concludes
that there is consensus to publish this, as is and as a BCP,
that is how it goes. I just disagree with doing that and felt a
need to express that opinion and explain it.
Without going through your comments point by point, which I
don't think is useful in this case, let me summarize my reaction
to all of them with "ok, that is fine, why doesn't the document
just say that". Again, my problems are about language and
specification style/ level/ completeness, not about the
recommendations.
But, as an illustration of my problem, let's compare the above
with the later text about Submission servers (MSAs) supporting
both Submit and SMTP. I suggest (and I hope my comments made
clear) that the *best* practice there is for the MSA operator to
require that all MUAs that intend to be its client support
Submit -- the port and the authentication -- and hence that port
25 traffic be prohibited entirely or, at least, supported with
the same level of authentication that particular MSA would
require for Submit if the MUA were using that port. But the
document wraps SHOULD language around that case. If the
difference is recognition of existing practice and the fact that
a few MUAs haven't caught up, that is fine, but it is somewhat
inconsistent, IMO, with your "*best* current..." reasoning above.
I've also got some problems with conformance language and a BCP
like this (one that effectively profiles existing protocols).
It feels to me that BCPs should be largely descriptive: "this is
the best current practice" and not "to conform to the norm set
by this document, you MUST do this, that, and the other thing".
I realize I am probably in the minority of the IETF about
considering that distinction useful.
Finally, I've got a problem with conformance scope that may be a
general issue where applied to a BCP. If the intent is that
someone either conforms to the statements of this document or
they are not conformant to this particular document (as your
note suggests), I have no problem. But, absent some very
specific language in the document _and_ clear instructions to
the RFC Editor that this is not permitted to share a BCP number
with anything, it seems clear to me that failure to fully
conform to this document (i.e., obey all of the SHOULDs and
MUSTs) will be construed a failure to use best practices for
Internet Mail generally, including in environments and for
purposes for which this document may not be applicable. It
doesn't contain a discussion of those cases, which is probably
fine, but encouraging overly-broad interpretations of expected
conformance scope, even by omission, seems like a bad idea to me.
Again, just my opinion.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf