Hi, Here's my comments to version 1 of this draft.
3.1 Message Format I'm a little hesitant about going to the 4-octet header. Are we certain that most existing DNS servers will respond with NOTIMP rather than FORMERR upon receipt of a ses-sig message? Some servers may not even respond to packets smaller than 12 octets (DNS header size). I would prefer using the full DNS header, even if it wastes 8 octets. I do like the simplification of only allowing one TLV per message. 3.2 Message Handling I'm still uncertain about ses-sig messages being "sequencing points" (see my comments to version 00 of this draft). In addition, where do server initiated messages, such as DNS Push Notification updates, fit into this? 4.2.1 Start Session I like using the Start Session TLV as a no-op/I'm still here message. 4.2.2 Terminate Session The current DNS Push Notification draft specifies different Reconnect Delays in different cases. Maybe there should be suggestions for multiple delay values, depending on the kinds of reasons for termination (server shutdown, server restart, different kinds of client errors). Out maybe just mentioning that as a valid option. 4.2.3. Idle Timeout I'm not sure of the usefulness of querying for the timeout value, the client should already have received it if one applies. However, I see no harm in that feature. 5. IANA Considerations Nits: Should it be "IANA is directed.."? Regards, Jan Komissar On 7/21/16, 12:48 PM, "DNSOP on behalf of internet-dra...@ietf.org" <dnsop-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Domain Name System Operations of the >IETF. > > Title : DNS Session Signaling > Authors : Ray Bellis > Stuart Cheshire > John Dickinson > Sara Dickinson > Allison Mankin > Tom Pusateri > Filename : draft-bellis-dnsop-session-signal-01.txt > Pages : 11 > Date : 2016-07-21 > >Abstract: > The Extension Mechanisms for DNS (EDNS(0)) [RFC6891] is explicitly > defined to only have "per-message" semantics. This document defines > a new Session Signaling OpCode used to carry persistent "per-session" > type-length-values (TLVs), and defines an initial set of TLVs used to > manage session timeouts and termination. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
