On 9 Oct 2015, at 15:21, Tim Wicinski wrote:
I've spent some time reviewing this document and I feel that all the
outstanding issues have been addressed, and the document is very well
put together. This is ready for the next step.
This starts a Working Group Last Call for draft-ietf-dnsop-5966bis
Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-5966bis/
Please review the draft and offer relevant comments. Also, if someone
feels the document is *not* ready for publication, please speak out
with your reasons.
This starts a two week Working Group Last Call process, and ends on
20:00 UTC 23 October 2015.
This document is clear, easy to read, fills a need, and I support its
publication as-is. I made a few notes as I read through, but it would be
entirely fine with me if they were all ignored.
Section 4 -- a reference to 6891 at the first mention of EDNS(0) seems
like it might be helpful. It's cited in the fourth paragraph, but not
the first paragraph.
Section 5, third bullet point: the final phrase seems a bit awkward (it
seems to suggest TCP being required between a stub resolver library and
its clients, which I don't think is intended. Suggest:
OLD:
o Stub resolver implementations (e.g., an operating system's DNS
resolution library) MUST support TCP since to do otherwise would
limit their interoperability with their own clients and with
upstream servers.
NEW:
o Stub resolver implementations (e.g., an operating system's DNS
resolution library) MUST support TCP since to do otherwise would
limit the interoperability between their own clients and
upstream servers.
Section 5, second to last paragraph: the word "resolver" here is used
without clarifying whether it means a recursive resolver, a stub
resolver, or both. Suggest:
OLD:
This requirement is hereby relaxed. A resolver MAY elect to send
either TCP or UDP queries depending on local operational reasons.
NEW:
This requirement is hereby relaxed. Stub resolvers and recursive
resolvers MAY elect to send either TCP or UDP queries depending on
local operational reasons.
Section 6.2.1.1: I found the third paragraph hard to parse, mainly I
think because of the phrase "that do not both". I understand the
intention, but I think it would be clearer if re-case slightly. Suggest:
OLD:
DNS clients will benefit from noting that DNS servers that do not
both process pipelined queries concurrently and send out-of-order
responses will likely not provide performance on a par with UDP.
NEW:
It is likely that DNS servers need to process pipelined
queries concurrently and also send out-of-order responses
concurrently over TCP in order to provide the level of performance
possible with UDP transport.
Section 6.2.2: the final clause in the last sentence ("multiple clients
behind NAT") seems to be missing an article, because NAT is not expanded
upon first use and my natural interpretation of the T is "translator"
not "translation". Clearly I'm insane, but perhaps I'm not the only one.
Suggest spelling it out.
OLD:
These limits SHOULD be much looser than the client
guidelines above, because the server does not know, for example, if
a
client IP address belongs to a single client or is multiple
resolvers
on a single machine, or multiple clients behind NAT.
NEW:
These limits SHOULD be much looser than the client
guidelines above, because the server does not know, for example, if
a
client IP address belongs to a single client or is multiple
resolvers
on a single machine, or multiple clients behind a device performing
Network Address Translation (NAT).
Section 7: matching responses to queries "by port number" seems a little
vague, and also very slightly odd given that every response received
over the same TCP session is going to have the same source and
destination port numbers. Matching by query ID with a (reasonable)
requirement that query IDs be guaranteed unique across a single TCP
session seems sufficient? No suggested replacement text, open question.
Section 8: is there benefit perhaps in including a matching SHOULD for
the desired server behaviour? The paragraph notes that servers may
respond in an unhelpful way if the message length and the message itself
don't arrive in the same segment, but doesn't specify in a normative way
what we think of that. Perhaps they SHOULD NOT do that?
Section 11: the text uses the phrase "reflector attacks", whereas I seem
to think the more common phrase is "reflection attacks". I realise that
5358 says "reflector" though.
Joe
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
