Re: [Gen-art] [dnssd] Genart last call review of draft-ietf-dnssd-push-20

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 <mellon@fugue.com> wrote:
> 
>> On Jul 4, 2019, at 3:32 PM, Tom Pusateri <pusateri@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
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd