Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-5966bis-04

[Brian E Carpenter <[e-mail]>]

Hi Sara,

On 03/12/2015 02:52, Sara Dickinson wrote:
> 
>> On 29 Nov 2015, at 21:16, Brian E Carpenter <[e-mail]> wrote:
>>
>> Comment: I read all the text and have no technical issues.
> 
> Hi Brian, 
> 
> Many thanks for the review. After a discussion amongst the authors and Tim, responses below.
> 
> 
>> --------
>>
>> Major Issues:
>> -------------
>>
>> This draft replaces RFC 5966, which formally updates RFC 1035 and 1123. Therefore,
>> logically this draft must also formally update RFC 1035 and 1123.
>>
>> Specifically:
>>
>> "Section 6.1.3.2 of [RFC1123] states:
>>
>>      DNS resolvers and recursive servers MUST support UDP, and SHOULD
>>      support TCP, for sending (non-zone-transfer) queries."
>>
>> Please make an explicit statement that this SHOULD is changed to MUST.
> 
> The bis reproduces 2 statements verbatim from RFC5966 with regard to this. In paragraph 4 of the Introduction: 
> 
> “This document therefore updates the core DNS protocol specifications
>    such that support for TCP is henceforth a REQUIRED part of a full DNS
>    protocol implementation."
> 
> and in the first sentence of Section 5
> 
> “All general-purpose DNS implementations MUST support both UDP and TCP transport.”
> 
> In light of this do you still think we need another statement to this effect?

Well, this may seem picky, but since you quote the text, I think that
a clear statement that you are changing it is useful. IMHO, YMMV, of course.

Adding the "Updates: 1035, 1123" is necessary, though.

Thanks for the rest, your proposals are fine.

Rgds
   Brian

> 
>>
>> Minor Issues:
>> -------------
>>
>> 1) The last sentence of the Introduction says
>> "It should be noted that failure to support TCP (or the
>> blocking of DNS over TCP at the network layer) may result in
>> resolution failure and/or application-level timeouts."
>>
>> Isn't "may" understating the risk these days? I would have thought that
>> "will probably result in ... failure" was justified.
> 
> Again, the wording here was lifted exactly from RFC5966, but the suggested change seems an improvement. I have updated the working copy with the new text. 
> 
>>
>> 2) If you want people to update existing code, the section "Changes to RFC 5966"
>> should be kept when "Appendix B. Changes between revisions" is deleted. Also,
>> please check which of the more recent changes need to be noted as changes compared
>> to RFC 5966.
> 
> This is an excellent point. In the working copy I have moved the “Changes to RFC5966” section to a separate Appendix and updated the wording:
> 
> "Appendix C.  Changes to RFC5966
> 
>    [Note to RFC Editor: please leave this section in the final
>    document.]
> 
>    This document obsoletes [RFC5966] and differs from it in several
>    respects.  An overview of the most substantial changes/updates that
>    implementors should take note of is given below:
> 
>    1.   A Terminology section (Section 3) is added defining several new
>          concepts.
> 
>    2.   Paragraph 3 of Section 5 puts TCP on a more equal footing with
>          UDP than RFC5966.  For example it states:
> 
>          1.  TCP MAY be used before sending any UDP queries.
> 
>          2.  TCP ought to be considered a valid alternative transport to
>               UDP, not purely a fallback option.
> 
>    3.   Section 6.2.1 adds a new recommendation that TCP connection-
>          reuse SHOULD be supported.
> 
>    4.   Section 6.2.1.1 adds a new recommendation that DNS clients
>          SHOULD pipeline their queries and DNS servers SHOULD process
>          pipelined queries concurrently.
> 
>    5.   Section 6.2.2 adds new recommendations on the number and usage
>          of TCP connections for client/server interactions.
> 
>    6.   Section 6.2.3 adds a new recommendation that DNS clients SHOULD
>          close idle sessions unless using a signalling mechanism.
> 
>    7.   Section 7 clarifies that servers are RECOMMENDED to prepare TCP
>          responses in parallel and send answers out-of-order.  It also
>          clarifies how TCP queries and responses should be matched by
>          clients.
> 
>    8.   Section 8 adds a new recommendation about how DNS clients and
>          servers should handle the 2 byte message length field for TCP
>          messages.
> 
>    9.   Section 9 adds a non-normative discussion of the use of TCP Fast
>          Open.
> 
>    10.  The Section 11 adds new advice regarding DoS mitigation
>           techniques.”
> 
> 
> Regards
> 
> Sara. 
>