At Thu, 15 Oct 2015 16:32:40 +0100, Sara Dickinson <s...@sinodun.com> wrote:
> My hesitation here is that if it is a SHOULD, then I think the > document would need a bit more detail regarding what ‘regularly’ > means, rather than simply saying the precise behaviour is out of > scope. I like to think that when something is specified as a SHOULD > then it should be relatively easy to determine if an implementation > is compliant with that requirement, and without specifying more > detail here I don’t think that would be easy. Do you have any > thoughts on that? IIRC there were some discussions among the > authors about this prior to the -02 version and we deliberately left > this out because how to time these subsequent signals isn’t > obvious. However maybe this isn’t really necessary and the above > text is acceptable. 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. I personally do not think a SHOULD inevitably requires more specific text about the frequency, although I see some others may have a different opinion. That said, I just realized I misunderstood one related part... > A couple of details to consider: > > 1) If the client is regularly sending messages with an EDNS0 OPT RR, > then the server can respond to these by adding the > edns-tcp-keepalive option and there is no need for the client to > specifically send the edns-tcp-keepalive option in the query. ...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. > The best wording I can come up with to try to cover this is: > > 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. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
