On Jul 4, 2019, at 12:52 PM, Tom Pusateri <[email protected]> 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? > 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.
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
