Re: [dnsext] WGLC ENDS0-bis

[Joe Abley <[e-mail]>]

On 2011-05-10, at 10:25, Olafur Gudmundsson wrote:

> Please send statements that you have reviewed this document and if it raised any issues. Remember we need 5 a minimum of 5 reviewers to say they reviewed the document.

Summary

Lots of nits below, some (to me, at least) somewhat substantial. I would like to see some edits before the document is sent up the tree, since I think there is some low-level ambiguity in the text and if the goal is clarification then these seem worthy of fixing.

I'm happy to work with the authors on specific text where there is consensus to edit if that seems helpful.

Abstract

"based on 10 years of deployment experience" seems like an empty phrase in the absence of citations of any study of EDNS0 penetration. I would delete it.

Section 1 ("Introduction")

"The maximum allowable size of a DNS Message is limited to 512 bytes". This is not true in general (it's true for DNS messages sent using UDP transport without EDNS0).

"uses which are commom [typo, sic] or desired to become common" is grammatically inelegant and unsupported. Desired by whom? Perhaps better to cite specific examples and avoid expressing unsubstantiated desire.

"RFC 1035 does not define any way for implementations to advertise their capabilities". Since the DNS protocol is variously implemented for different purposes (resolver, authority-only server, update client, etc) it might be better to re-cast this as "[RFC 1035] does not provide any mechanism for capabilities negotiation between DNS clients and servers".

"[RFC2671]" seems to be bare ASCII rather than a reference (this is more obvious in the HTML rendering of the document).

"This document Obsoletes Extended Labels". Obsoletes, or deprecates?

Section 2 ("Terminology")

Various terms are capitalised as if they are defined phrases, but do not appear in Section 2 ("Terminology"). Examples include "Message Format", "DNS Message", "DNS Message Header", "Traditional DNS Messages", "Extended Label Types", "Option Codes", "(Un)extended agents", "(Un)extended DNS". As noted elsewhere, "Middleware Boxes" could do with a definition.

Section 3 ("EDNS Support Requirement")

"practically mandatory in a modern world" is subjective and ambiguous. The section would benefit from the normative language being spelt out in its own paragraph, and the justification/preamble being re-cast to avoid subjective phrases and instead call out specific examples (e.g. from DNSSEC and ENUM) for which EDNS is necessary or useful.

Section 4.3 ("UDP Message Size")

"Today"? "many organizations"? "special tricks"?

Given that DNSSEC requires an EDNS0 pseudo-header in a request in order to react to DO=1, is it a suitable example to justify the existence of EDNS0 at all? An unextended DNS message can't be used for secure answers anyway. I'm not explaining myself very well, but it seems like there's some avoidable chicken/egg juxtaposition here.

Section 5 ("Extended Label Types")

"obsoleted" or "deprecated"? What is the required action of DNS Requestors and Responders who receive messages that contain extended label types?

The direction to the IANA seems out of place in this section (perhaps replace with an xref to Section 9).

Section 6.1 ("OPT Record Definition")

Several aspects of the OPT RR are defined in later sub-sections of section 6, so 6.1's title seems not entirely appropriate.

Section 6.5 ("Requestor's Payload Size")

The second paragraph has me scratching my head, since it implies that a requestor has knowledge about the cleanliness of the UDP/IP path to a server without describing how it acquires that knowledge. Some guidance about how requestors might probe each path in order to establish a sensible payload size seems appropriate.

I appreciate there is some more detailed guidance in 6.7; perhaps that could be extended and an xref placed in 6.5, or perhaps this section could become a subsection of 6.7.

Section 6.6 ("Responder's Payload Size")

There is algorithmic guidance given in this section to allow an implementor to choose a suitable payload size, but it seems vague (e.g. "meaningless QUERY"). More specific guidance seems like it would be helpful.

I appreciate there is some more detailed guidance in 6.7; perhaps that could be extended and an xref placed in 6.6, or perhaps this section could become a subsection of 6.7.

Section 6.7 ("Payload Size Selection")

See above.

Section 6.8 ("Middleware Boxes")

See above regarding definition of "Middleware Boxes". (Incidentally, "Middleware" as a noun seems better to me, once defined, than "Middleware Boxes".)

Is the prohibition on limiting UDP-transport DNS messages to 512 bytes by middleware necessary in the case where middleware performing deep packet inspection knowns unequivocally that it is dealing with an unextended DNS message?

"MUST understand the OPT record" -- do you mean to say that such devices must support EDNS0? There's a difference between understanding and processing.

Section 6.11 ("OPT Options Code Allocation Procedure")

Shouldn't this direction be moved to the IANA Considerations section, since it describes an attribute of a registry?

Section 9 ("IANA Considerations")

"EDNS Extended Label Type", "EDNS Option Codes", "EDNS Version Numbers", and "Domain System Response Code" are not the names of the registries created by RFC 2671, at least not as seen at <https://www.iana.org/protocols/> (unless I'm reading it wrong). Since this section contains direction for the IANA, it seems appropriate to make sure the registries referred to are unambiguously-named. Worth checking, anyway.

"IANA is advised to re-parent these sub-registries to this document",
  "We request that this registry be closed" --

I don't know that "closed" or "re-parent" are sufficiently unambiguous when it comes to describing an action on a registry. Does "closed" mean that the registry should no longer accept additions, or that it should be deleted such that nobody can find it any more? Does "re-parent" imply that the requirements for changes to the registry (e.g. "RFC Required", "IESG Approval") are inherited, and that the existing contents of the registry should be preserved?

No doubt any ambiguity would be cleaned up during IANA review of the document, but it doesn't hurt to get it right first time.

"This document assigns EDNS Extended RCODE 16 to 'BADVERS'" -- it seems like a good idea to specify precisely which registry the document is requesting be updated, here.

In general a quick review of RFC 5226 might help clean up this section.


Joe