I think this draft is a good candidate for adoption. I'd like to echo Ted's comment that the draft should explicitly state the sort of context this is meant to be used in. Calling out TCP sessions as an example would be a good start. I found myself wondering how the server is meant to initiate SS messages to the client in a UDP context where the client is behind a NAT, for example. I'm also wondering if wouldn't be possible to implement this in a more backward-compatible way. I anticipate a lot of people who don't even intend to capture SS messages having to update their code anyway, because the messages won't be automatically discarded and will confuse parsers that attempt to analyze them. On the other hand, I am wiling to discuss the merits of advancing the expectation that the message format could change with the opcode.
On 6 July 2016 at 15:24, Ray Bellis <[email protected]> wrote: > I've just submitted this draft, which resulted from discussions in > Buenos Aires related to issues with using EDNS for persistent signalling > (c.f. RFC 7828), and also from an overlap with draft-ietf-dnssd-push and > its (mis-)use of the edns-tcp-keepalive option. > > The intention here is to split out session-related stateful options from > the dnssd-push draft into a more generic specification. > > Please note that the question of whether to use an alternate message > format for this OpCode (as it is currently specified) or whether to > shoe-horn the options into an RR lookalike (per EDNS) is still a matter > of some debate between the authors. With no consensus amongst us I felt > if important that the WG be able to weigh in on that debate. > > Ray > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-bellis-dnsop-session-signal-00.txt > > A new version of I-D, draft-bellis-dnsop-session-signal-00.txt > has been successfully submitted by Ray Bellis and posted to the > IETF repository. > > Name: draft-bellis-dnsop-session-signal > Revision: 00 > Title: DNS Session Signaling > Document date: 2016-07-06 > Group: Individual Submission > Pages: 10 > URL: > > https://www.ietf.org/internet-drafts/draft-bellis-dnsop-session-signal-00.txt > Status: > https://datatracker.ietf.org/doc/draft-bellis-dnsop-session-signal/ > Htmlized: > https://tools.ietf.org/html/draft-bellis-dnsop-session-signal-00 > > > 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 > handle feature negotiation and to manage session timeouts and > termination. > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
