Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-tcp-keepalive

[Sara Dickinson <[e-mail]>]

> On 15 Oct 2015, at 18:00, 神明達哉 <[e-mail]> 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.