Maybe we could have a conference call and hash this out. Anyone is welcome.
I’m ok with removing resolver support for now to simplify this and tackle resolvers in another document. But if there’s a good solution we’re all happy with, we can fix it now. Tom > On Jul 4, 2019, at 3:54 PM, Ted Lemon <mel...@fugue.com> wrote: > >> On Jul 4, 2019, at 3:32 PM, Tom Pusateri <pusat...@bangj.com> wrote: >> I was trying to give the client enough information to determine WHY it >> failed. If we determine this isn’t important, we can just let the client try >> to figure it out but it will be more work for the client. > > The client is a computer program, not a person, so there is no chance that it > will be able to figure out what went wrong! :) > > Seriously, though, what’s the strategy the client should follow in this case? > I think we generally say “try again in an hour” but I’m not sure if we said > that explicitly here or just in the DSO document. > >> It’s likely that resolvers aren’t going to support this before authoritative >> servers are and clients will quickly learn their resolver isn’t capable and >> go directly to the authoritative for some period of time. > > I think that how resolver support for this will work is an open question > right now, which will probably have to be addressed in a follow-on document. > At present, the implementation I’ve done doesn’t even attempt the local > resolver, because I couldn’t figure out how to implement that. I’m assuming > that in most cases there’s no particular benefit to using the local resolver, > because the auth server will also be local. > > _______________________________________________ > dnssd mailing list > dn...@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
