On Apr 6, 2014, at 6:56 PM, Edward Lewis <[email protected]> wrote:
> > On Apr 6, 2014, at 20:52, Paul Hoffman <[email protected]> wrote: > >> That does not make the document "impossible to implement", it makes it >> unreliable when the child's nameserver is anycast. That's why the document >> says not to do that in Section 2.2.1 > > My comment wasn’t that the “document was impossible to implement” but that > with the advent of any cast one can never query all of the name servers (from > one location). > >> Again: isn't your concern covered by the four steps in Section 2.2.1? > > As far as the SOA and NS, that is a good approximation, but it doesn’t cover > the A and AAAA records that could be elsewhere. > > It is not that this stuff can’t work. It’s that ideas like this (adding to > the DNS protocol’s management toolset) are only ever approximations that run > the risk of adding complications when things don’t go well. The alternative > is another protocol for this, and I expect a blank stare in return to the > comment. So in the mean time, I just want to call out the rough edges of > these proposals. Calling out rough edges is fine; those should be admitted in the documents in question. My review of draft-ietf-dnsop-child-syncronization says that the rough edges are called out; if you have particular places in the document that you think should have bigger warnings, point them out. > The document does do a good job of handling as many as it can, but there’s > still the underlying limitations of one-way-only message passing. The only > way this will work (in the sense of scale and stability over time) is if the > parental agent gets notified reliably to check and the child’s (agent?) stays > on the ball until the action is completed. That is a good summary; maybe it should be added to the end of Section 1. --Paul Hoffman _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
