Eliot,
I'm obviously not being clear enough about what I'm concerned
about and looking for, so I should stop commenting for a while.
Before I do and in line with your note...
(1) If an issue has already been discussed, at length and by
participants who are well-informed on the issues, on a
topic-specific IETF mailing list, making decisions based only on
a much more abbreviated discussion on the IETF list is probably
not a good idea. While we have historically not made a
distinction between non-WG lists that are created for
discussions by a person or two and non-WG lists that are the
result of WG efforts that resulted in standards and that were
explicitly left open for discussions as issues with those
standards arise, perhaps we should do so. In that regard, I
applaud Warren's and the IESG's decision to distinguish, by
name, between affinity group lists and lists on which it is
sensible to talk about IETF consensus.
Agree, although I think Warren’s efforts are a bit separate.
(2) I believe that my continued pushing back on making technical
decisions on the IETF list (or the Last Call list), other than
in response to well-formulated Last Calls when there has already
been extensive discussion on a specialized ex-WG list,
especially if there has been no effort at a careful and balanced
summary of that prior discussion, is a bad idea from a technical
standpoint. I believe that is true whether there is an issue in
which the Secretariat is involved or not. I think that position
is entirely consistent with the policy statements about the IETF
list, SAA efforts to push technical discussions onto more
specialized lists, etc. (including IAB decisions to push
strategic discussions of RFC Editor Function futures onto
rfc-interest as reflected in Ted's recent notes). Personally, I
don't like some of the implications of those policies and have
said so, but I'm trying to conform and think others should too.
I understand. However, sometimes the devil is in the detail. For the record, I disagree with the view that the LCs should take place on a separate list, but that is a separate discussion.
(3) I don't believe anyone is proposing micromanagement in this
area, just somewhat more awareness of what we are doing. Let me
borrow an idea from your note as a possible suggestion in that
area. Suppose we decide that operational decisions that diverge
from IETF standards should be associated with errata (or
announcements to ex-WG lists, or both) indicating that the
standard has gotten out of touch with reality and practice.
That would completely meet my needs, at least if discussion of
those errata on relevant mailing lists was not prohibited.
However, it does imply two other issues about which we should be
aware: (i) Most such errata are (IMO completely appropriately)
going to get marked "hold for document update" and then ignored
until a decision is made to revise the document for other
reasons. However, an AD, a document author, or an ordinary IETF
participant who happens to notice the erratum may bring the
erratum up as an issue on the relevant ex-WG mailing list,
perhaps even to stimulate a discussion of whether it is time to
revise the document or produce a new document updating it.
Should a discussion occur as a result and relatively clear
consensus emerge that the erratum is incorrect and the implied
requested change inappropriate, I would hope that there would be
a reasonable way to communicate that result to the Secretariat
and/or the IETF LLC ExecDir and would hope that the earlier
decision would be reviewed and revised as appropriate. (ii) I
do not believe that the job descriptions of either the
Secretariat or the IETF LLC ExecDir includes evaluating
conformance with IETF Standards or the skills and background
needed to do so.
If someone is running a mail service, the responsibility falls on them to manage it. How they manage it on aggregate is something that should occasionally be evaluated by the ExecDir. Whether IETF standards are followed is entirely secondary to whether the service is properly managed and providing appropriate utility to the community. Indeed, if the community wants to worry about whether these standards are being properly followed, it falls on us and not the secretariat to note when they are and when they are not, and take what standards actions we deem appropriate as a result (this also addresses your point 4).
As a customer of the service, you get to complain if there is a problem. You did so. Good. That leads to an escalation path when things go wrong. But let’s please separate the service not functioning as you think it should from whether the standards are being applied as you envisioned. That is the main thrust I am trying to convey.
In any event, at the time RFC 5321 was published, it represented
the rough consensus among those involved, affirmed in an IETF
Last Call that was somewhat more active and technically-specific
than I think has been the norm lately, that it was closely
aligned with existing practice. So no problem with Brian's
observation or anything else at that time. Prior to a
discussion that started only a month or two ago, there has been
no serious consideration of revising it in the subsequent eleven
plus years.
Fair enough. That is a standards decision for the community. It takes time and effort (I’ll note mostly your generous time and effort) to update these documents, and not all errata either individually or in aggregate rise to the need to do a document update. But that doesn’t mean the erratum isn’t something to correct.
(5) Your analysis of the reasons that a response to an IP
address literal in an EHLO command is interesting. It is a bit
inconsistent with the command-response model of RFC5321, but,
perhaps, if there were evidence that what is being done
represented very common practice, that would be irrelevant.
However, there is no such evidence and, perhaps more to the
point, it is not what Glen says the IETF servers are doing --
they are rejecting _all_ EHLO commands with IP address literals
as the argument but, for reasons I haven't asked him about,
deferring the responses until after a RCPT command is received.
Such deferred responses may be consistent with pipelining, but
pipelining was not requested in this case. Again, it seems to
me that this is a topic for the ietf-smtp list, not the main
IETF one for the reasons given above.
Yeah, we can take the specifics off the list. I gave a rational reason as to why someone might choose to reject later, not that this was the logic being used in this specific case.
(6) Finally, I think we need to be cautious about saying that it
is ok if conforming SMTP clients don't work with the IETF
servers because people can always find free email services that
work with those servers. In general, we know who the most
obvious of those free email services are. Several of them are
not strictly standards-conforming (although they may involved in
a sufficient fraction of Internet mail traffic that an extreme
interpretation of Brian's statement, one that I think Brian
would not have agreed to, is that _they_ are the standard, not
whatever the IETF specs have to say), they raise some of the
issues about concentration that the IAB has been trying to
address, and they raise some privacy concerns as well (even
though I personally believe that nothing said to the IETF that
might influence a standard should be treated as private or
allowed to be anonymous).
I would agree with you– and I share some of the IAB concerns on this point. However, my point was really this, and I’d like it not swept aside:
It is not a simple task to run an MTA these days for all the reasons I previously mentioned. The low bar here for communicating with this particular server was having a PTR record, and the standards community does not get to second guess the person who set that low bar. We only get to note that they did so and to decide whether it is a counter-example to what our voluntary standards specify.
If you can’t manage to get a PTR into the DNS, there are a great many options that include, but are not limited to using a free or pay-for mail service. You can still build your own, but you may have to use a data center that agrees to update the PTR record for you (this is what I have done). A mechanism even exists to accomplish this with EC2 at very nominal prices (~USD $10/month)
Eliot
|
