marka> Or we could stop debating whether we should maintain it and marka> assume that if we give people tools that will allow it to be marka> automatically maintained they will eventually deploy them.
For providers with millions or tens of millions of end customers, any system that just lets any customer scribble in DNS is unlikely to be employed for security or stability reasons. marka> Document what a node should do to register itself in the reverse marka> tree and to cleanup when its address changes. Write some code to marka> do it. And of course all CPE vendors put out quality products with these advances in code and never put out cheap crap. And consumers always upgrade their CPEs based on this improved code immmediately. Heh. The reality is that this will take decades and in the meantime, consumers will have problems doing what they want and they will complain to their service provider, who won't have a good solution. This document tries to lay out the challenges and tradeoffs of not having PTRs or not having "clean" PTRs. We should be sure it makes those tradeoffs clear, along with the problems service providers will see if they do or don't pick one of the solution sets. If there are issues or tradeoffs not in the document, suggest a text change. The "just do it right and folks will roll it out" argument doesn't solve the problem in any useful timeframe and doesn't let folks who do have to support millions of customers make informed operational decisions. And automating at the scale we'll see with real IPv6 deployment is going to be very hard. Add in that embedded devices are some of the least likely to be current, clean or remotely upgradeable as we learn of mistakes and you'll wind up with more boxes doing it wrong than right. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
