On 20/07/2015 10:49, Petr Spacek wrote:
> 3.3.2. Sending Responses > Current text seems to allow servers to send tcp-keepalive option even if the > client did not explicitly request it. Is it intended? If it is the case it > would be nice to say it explicitly. Right now I do not if it is just omission > or a intentional violation of 6891 section 7. As I understand it, EDNS allows return of any option so long as the client sent an OPT RR, irrespective of which options where in the client request [but see below] > 3.4. TCP Session Management > typo: "RCF6891 states" ... > > Since servers must be faithful to this specification even on a > persistent TCP connection it means that (following the initial > exchange of timeouts) a server may not be presented with the > opportunity to signal a change in the idle timeout associated with a > connection if the client does not send any further requests > containing EDNS0 OPT RRs. > > This reference to RFC 6891 section 7 seems to contradict server behavior > mentioned earlier in section 3.3.2 of this draft. > > Personally I think that this is a deficiency in EDNS0 spec (or my > understanding of it :-). Is there a reason to assume that client could > possibly lost ability to understand particular EDNS option/feature during > lifetime of one TCP connection? This is a matter of some debate - see the earlier DNSOP thread I started on June 3rd with subject "Clarification on EDNS 6891" kind regards, Ray _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
