[dnsext] Updates to draft-ietf-dnsext-dnssec-algo-signal draft as a result of IESG review

[Ted Lemon <[e-mail]>]

During IESG review some subtle issues were raised with the DNSSEC algorithm signaling draft that resulted in an RFC editor note being added to the document.   I'm writing this note to apprise the working group of the changes that were made.   My expectation is that the working group will not see any of these changes as substantially changing the document in a way that would influence the outcome of the last call, but they are not merely editorial, so it seemed appropriate to give the working group a shot at them.

The complete editor's note is here: http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal/writeup/

The particular change to which I want to draw your attention relate to the question of what it means for a resolver to be a validating resolver.   The document as submitted by the working group allowed for the possibility that a validating resolver might not set the DO bit; this then led to an ambiguity in section 5 about the processing of the three new options.

The text as submitted by the working group said that the server doesn't process the options if the DO bit isn't set.   The question was raised: what if a validating resolver doesn't set the DO bit for a particular query?   Don't we still care, in principle, what algorithms it supports?

The clarifying change is the change to section 3.1.1: a validating stub resolver is now defined for the purposes of the document as one that sets the DO bit.   The actual piece of software running on the host may sometimes set the DO bit and sometimes not, but we only _treat_ it as a validating resolver if it does.

If this sounds like an interesting point to you, please check out the editor's note and see how it affects the draft.   If we don't hear any substantive objection by midweek, I will release the document for publication with the editor's note as is.  There are a number of editorial changes in the editor's note as well; the changes that pertain to this question are specifically those that address 3.1.1 and 3.2.1.