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

[Tom Pusateri <[e-mail]>]

> On Jul 4, 2019, at 2:13 PM, Ted Lemon <[e-mail]> wrote:
> 
> On Jul 4, 2019, at 12:52 PM, Tom Pusateri <[e-mail] <mailto:[e-mail]>> wrote:
>> 1. The client should only send SUBSCRIBE to set up the DSO session if it has gone through the discovery process and wants to talk to the authoritative directly. If it wants to try to subscribe to push notifications through a resolver, then it should use KEEPALIVE first to establish the DSO connection with the resolver.
> 
> This creates a new semantic connection between KEEPALIVE and SUBSCRIBE.  This means that DSO implementations now have to track more state.  I don’t think there’s a benefit to doing this.  Why do you think it’s necessary?
> 

Do I already have a session or not with my resolver is not a lot of extra state. Especially when it’s over TLS and you are likely to keep the session up for some time and then let it expire. This state is necessary regardless.

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.

>> 2. If the resolver supports SUBSCRIBE but the authoritative doesn’t, the resolver should not send DSONI back to the client because the client can’t tell the difference between the resolver not supporting SUBSCRIBE and the authoritative not supporting SUBSCRIBE. In this case, the resolver should return SERVFAIL. This should inform the client that the authoritative doesn’t support SUBSCRIBE. If there are multiple authoritative servers supporting _dns-push._tcp, the resolver may want to try all of them before returning SERVFAIL.
> 
> There’s no need to mention DSONI here.  Just say what the right behavior is.  If you mention DSONI here, someone might read this to suggest that in some case DSONI would make sense.
> 
> SERVFAIL just means that the server is unable to support the requested behavior. It doesn’t signal why. Unless there’s something the client would do differently, I don’t think it’s necessary for the client to know why the request failed.



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.

Tom