--On Friday, September 02, 2011 16:43 +0100 Tony Finch
<dot(_at_)dotat(_dot_)at> wrote:
John C Klensin <john+smtp(_at_)jck(_dot_)com> wrote:
Mark Andrews <marka(_at_)isc(_dot_)org> wrote:
TURN is useful if the is not a direct incoming path. e.g.
Running multiple MTA's behind a firewall/nat that blocks
incoming connections. ETRN is useful if the is a direct
incoming path.
Mark, I said "it was deprecated". I didn't say that there
were not arguments for keeping it for special circumstances,
nor that there were not other tradeoffs. The WG considered
those issues, deprecated it, and introduced ETRN to deal with
the pieces of the problem that affected the public Internet.
There's also ODMR / ATRN - RFC 2645.
Sure. And maybe other things. If you think ATRN should be
mentioned along with ETRN in 5321bis (assuming that eventually
happens), I recommend generating an erratum that says so.
Similarly for any other IETF-approved technique for stimulating
a potential sender into action. Because 5321 has already gone
down the path of saying "this is a way to do this, I don't mind
adding more even though I think that whomever suggests such a
reference should be prepared to demonstrate that the method /
spec to be referenced is widely deployed and tested sufficiently
to justify an explicit pointer from a full standard.
On way to describe it is that any pointer to a technique from
5321bis should be treated as a recommendation for a tested,
established, and deployed protocol, not an advertisement for
something that folks think is a good idea.
For those interested in that distinction, see the recent
discussions of 4409bis on the YAM and IETF mailing lists. For
2645, I think the community would probably insist on the
equivalent of an implementation report whether there was an
effort to move it to DS or not.
john