Ray, On Fri, 12 Jun 2015 11:52:44 +0100 Ray Bellis <[email protected]> wrote:
> On 03/06/2015 17:22, Joe Abley wrote: > > On 3 Jun 2015, at 17:17, Shane Kerr wrote: > > > >> On Wed, 03 Jun 2015 13:57:39 +0100 > >> Ray Bellis <[email protected]> wrote: > >> > >>> Whilst discussing 5966-bis with my co-authors connection-close with the > >>> co-authors, we were reminded of this point I made in > >>> draft-bellis-dnsop-connection-close in relation to ยง7 of RFC 6891: > >>> > >>> " TODO: note - the constraint in RFC 6891 appears unnecessarily strict > >>> - it appears to mandate that the EDNS(0) support indication is on a > >>> per-request basis, but it would be reasonable on a connection- > >>> orientated transport to assume that ANY preceding request on that > >>> connection with an OPT RR is sufficient to indicate that the client > >>> supports EDNS(0)." > >>> > >>> Is this something that the WG believes needs to be fixed? > >> > >> The potential benefit is that a client could omit the OPT RR on > >> subsequent messages? Seems a relatively small benefit, and there are > >> costs. (Are there other benefits?) > > > > I agree. > > > > I think there's a baked-in expectation that OPT pseudo-RR is included in > > every DNS message, not on every connection (where the transport is > > connection-oriented). > > The use case we are considering is that absent an OPT RR in each > request, RFC 6891 doesn't permit the server to unilaterally send back an > OPT RR in a response (e.g. for connection signalling purposes) even it > one was previously seen on the same persistent connection. > > Furthermore if the specification of a particular OPT code requires that > it only be sent when received from the client then that must also apply > *per message*. > > We're not saying this is wrong, but in the context of a persistent > connection that could be quite an overhead and if necessary we should > explicitly document this with full awareness of the potential consequences. > > It seems that EDNS is not an entirely suitable mechanism for > *connection* related signalling and it's this issue that we're trying to > find a solution to. Okay, perhaps I misunderstood the original question. I was taking the question to be "in our current clarification work, should we consider omitting OPT RR from every message on a session". In that case, I think the answer is "no, this is not a clarification, but a protocol change". If the question is, "should we change the protocol so that EDNS over connection-oriented transports works differently", then I think the answer is, "hm... interesting. It probably won't provide a big win, but lets explore it." :) Cheers, -- Shane _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
