Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)
draft-ietf-dnsext-dnssec-algo-signal-10

This seems more like an Experimental document, but I will not stand in the way of the WG's view of its status.

After discussion, it sounds like we're in agreement that some clarification on why a client MUST NOT send DAU/DHU/N3U if it's not setting DO would be a good thing, and some review of the other requirements language (in particular I suggest removing the "MUST send DO if you send DAU/DHU/N3U") is in order. I will work with the AD and authors to get this in before final approval.

Section 5, paragraph 2: s/DNSSEC-OK (OK)/DNSSEC-OK (DO)

Why is there a need for separate DHU and N3U options?  It seems like if an implementation has a hash, then it has the has.  Are there real implementations for which these differ?

The combination algorithm for recursive resolvers seems backwards; it results in a list of algorithms such that at least one of the stub and recursive resolvers can validate.  It seems like you would want to know how many clients there are out there for which you MUST use a given algorithm.  Since either the stub or recursive resolver can fail the resolution on validation failure, you would thus want the intersection of the two lists, not the union.

- abstract: the draft does stuff, it doesn't "set out to" do
stuff, at least not anymore

- section 4: not sure if the write-up is a bit out of date,
but personally I prefer the text in -10 of the draft to using
"[RFC525-422]" as given in the write-up

- section 7 or earlier: it'd be nice to point at the IANA
registries if those had stable URLs. I can never remember if
they do or not;-)

- section 8: I think you maybe ought add another security
consideration something like: 'If a client continues to
support a "broken" algorithm that would allow an attacker to
prepare bogus but cryptographically valid DNS responses then
advertising that fact via this extension could make it easier
for the attacker to exploit such a vulnerability. The
solution for such clients is to remove support for such
"broken" algorithms as soon as possible.'

- The secdir review [1] mentioned a possible DoS. I don't see
the threat myself, but it'd be good if the authors responded
to that, just in case. (Sorry if you've done that already and
I missed it.)

   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03919.html

There seemed to be a lot of UOFU TLAs and FLAs, hopefully these are all RFC Ed SEs.