Thanks for the review. I can confirm that both nits need fixed. As far as your comments: 1. UNSUBSCRIBE and RECONFIRM are unidirectional because they are already acknowledged by the transport protocol and there is nothing the client can do in response to a DNS level Stateful Operations acknowledgement from the server. If an UNSUBSCRIBE fails, it’s because it’s not subscribed and the end result either way is that it’s not subscribed. A RECONFIRM may trigger additional queries from the server which may or may not result in PUSH notifications but the client has to deal with the situation the same until a PUSH notification is received. 2. As far as using the DNS header MESSAGE ID in an UNSUBSCRIBE, this is a consequence of not reusing outstanding message IDs over stateful operations. This means the server must keep the state of the message id and so associating it with the subscription is natural. Will also address TLS comments. Thanks, Tom > On May 17, 2019, at 3:47 AM, Liang Xia via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Liang Xia > Review result: Has Issues > > Nit: > 1. Section 6.1, s/This connection is made to TCP port 853, the default port for > DNS-over-TLS DNS over TLS [RFC7858]./This connection is made to TCP port 853, > the default port for DNS-over-TLS [RFC7858]. 2. Table 2, RECONFIRM should be > C-U TLV type. > > Comments: > 1. why are UNSUBSCRIBE and RECONFIRM the client unidirectional message? > 2. In UNSUBSCRIBE message, why do you choose to use SUBSCRIBE MESSAGE ID, not > NAME+TYPE+CLASS? 3. In the section of Security Considerations: > 1) you should also mention that TLS provides the anti-replay protection > service for DNS Push; 2) maybe you need to consider the client > authentication to achieve policy control and detect illegal client; 3) TLS > WG are specifying the SNI encryption mechanism, will it influence your TLS > name authentication? > > _______________________________________________ > dnssd mailing list > dnssd@xxxxxxxx > https://www.ietf.org/mailman/listinfo/dnssd
