Hello, having been encouraged to do reviews with my newcomer's eyes, here are some comments:
On 4.7.2015 17:06, Tim Wicinski wrote: >> A further change is the removal of the usage of the option over UDP >> since the semantics of whether a UDP message can say anything about a >> subsequent TCP message are unclear. >From my perspective this is a reasonable step. >> The authors request working group discussion on this point. 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. 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? 4. Intermediary Considerations Sentence "Should a non-keepalive-aware intermediary sit between a client and server that both support keepalive a potential side effect will be an increased frequency of the proxy closing idle client connections." is kind of hard to read, but that is just matter of taste. -- Petr Spacek _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
