I tried to ignore this thread for a while, but became alarmed after reading some of the recent comments, so I went and read the document.
As far as I can tell, this document gives no clear justification for why it is a good idea. We have not been told of the practical operational problems that motivate it. It appears to solve a problem we have already solved, in a way that creates new security vulnerabilities. We have not been told why the existing solution to the problem is not adequate. If the authors have a real problem that they feel has not already been solved, the first step in the process ought to be to present that information to the working group, rather than to present a solution to the working group with no clear statement about the problem it solves, and in particular no data about the seriousness of the problem. For what it's worth, which isn't much since the chairs haven't issued a call for adoption, I don't think the working group should work on this. On Tue, Aug 15, 2017 at 9:41 AM, Vernon Schryver <v...@rhyolite.com> wrote: > ] From: Lanlan Pan <abby...@gmail.com> > > ] Give the choice to operators, time is the best witness, like IP surpassed > ] ATM. > > That is backwards. IP did not surpass ATM, because IP came long before > ATM. Instead, end-to-end ATM was the last gasp of the end-to-end > circuit switching point of view. End-to-end ATM was supposed to replace > IP, but instead the new virtual circuits of ATM came far too late and > did not solve the problems that packet switching had already solved. > > ATM has not yet died and is still common for some uses. For example, > ATM is used as x.25 was used under IP in the early days of IP; many > DSL installations use AMT VCs. > > A better and more relevant history is that of the SPF RR. The SPF RR > was supposed to replace the use of the TXT rtype for SPF. The SPF RR > was widely available in deployed DNS authoritative servers (via BIND). > I think it was in milter modules for sendmail and postfix. Nevertheless, > it died because it came late, was only a modest improvement, and required > operators to do something more than they were doing. > > > Vernon Schryver v...@rhyolite.com > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
