> On 15 Oct 2015, at 18:00, 神明達哉 <jin...@wide.ad.jp> wrote: > > I see your point. But whether the updated notification from the > server works relies on whether the client includes an OPT RR in > subsequent queries, ambiguity on the latter can easily lead to > interoperability problem. So I thought this should be at least > clearly documented and RFC2119 keywords are helpful exactly in such a > situation.
That’s reasonable and so I do think extra text helps here. > > ...I incorrectly thought the client needs to keep including the > edns-tcp-keepalive option. I'm not sure if we can reasonably assume > clients generally include an EDNS OPT RR even if they have no other > particular reason to do so than the issue we're discussing here. > If we can assume that, the text can be loosened. But we probably cannot > rely on the current implementation behavior on this topic, so I think > it's safer to at least mention it explicitly in some way. > I certainly agree that the EDNS0 spec is full of subtleties :-) >> >> If a client includes the edns-tcp-keepalive option in the first query, it >> SHOULD include an EDNS0 OPT RR periodically >> in any further messages it sends during the TCP session. >> This will increase the chance of the client being notified should the server >> modify the timeout associated with a session. > > I'm fine with this. Also, if the use of 'SHOULD' really triggers > controversy on whether to be more specific about "periodically", I'm > fine with avoiding an RFC2119 keyword, too. Fair enough - I’ll add the above text to the document and the wording can be downgraded if necessary! Thanks for all the feedback. Sara. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
