I support publication of this document. I do have some "last call" feedback to share:
Section 2, paragraph 4 states that "A resolver that implements QNAME minimisation changes the QNAME and QTYPE in queries directed to an authoritative nameserver that is not known to be responsible for the original QNAME". This is true, except when the QNAME and/or QTYPE are already in the preferred form. For instance, if the resolver prefers to send QTYPE=A, and the client has requested QTYPE=A, then no change is needed. For similar reasons, the change does not necessarily "hide" the QTYPE, but rather prevents an observer from distinguishing queries of one type from another. Suggested changes: "changes the QNAME and QTYPE" -> "obscures the QNAME and QTYPE" "to hide the original QTYPE" -> "to obscure the original QTYPE" Section 2.3, last paragraph: I believe the intent of this paragraph is to show how many labels to add during each iteration, but it would benefit from further precision. These questions stand out: "The number of QNAME minimization iterations is the difference between this closest nameserver and the incoming QNAME". This should read "… the delegation point for this closest nameserver", correct? But this isn’t the number of iterations in any case, it’s the number of labels that are still not exposed. It’s only the number of iterations if it's less than or equal to MAX_MINIMIZE_COUNT. "The number of labels that are not exposed yet now need to be divided over the iterations that are left (MAX_MINIMISE_COUNT – MINIMISE_ONE_LAB). The remainder of the division should be added to the last iteration". True, but this overlooks all the iterations in between. Based on the example, I’m assuming the idea is to allocate the labels that are left proportionally to the remaining iterations, rounding down. The text should also state whether the algorithm is mandatory or optional. 2119 key words would be helpful. Minor edits: Section 1.1, paragraph 1: "publicaiton" -> "publication" Section 2.3, last paragraph: "handles" -> "handled" Scott _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
