Re: IETF Policy on dogfood consumption or avoidance - SMTP version

[Eliot Lear <[e-mail]>]

> On 19 Dec 2019, at 05:42, John C Klensin <[e-mail]> wrote:
> 
> 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