Roy Arends via dnsdir writes: > Why would you, as an implementor, guess? Because you've only said only "responses", and then also provided a document that largely talked about DNSSEC as examples. Clarifying that is not intended only for DNSSEC reporting would be great. If you really mean "all responses" then say it explicitly. I think that's overkill, but at least it is specified. Protocols should be clear, and just an unmodified "responses" leaves too much implicit without any real guidance. It's noteworthy that you are now suggesting it should be even inserted in responses where there client didn't even use EDNS. 6891 permits this, but as far as I can think of this is the first time we are suggesting that authority servers do that, so it really deserves some explicit attention. > > Also, for Section 5, is 0 an okay OPTION-LENGTH > > No. >> > or must it be minimum > > 1 with an AGENT-DOMAIN of \0? > > No. Right, and I get why ... but it should be explicit. You have a two octet field that could represent [0, 65535] but for this spec only [3, 241] are even theoretically usable. > > "The reporting resolver MUST NOT use DNS error reporting to report a > > failure in resolving the report query." This feels ambigous to me, > > because even as an old DNSSEC geek I would, in the vernacular, > > describe a failure to validate as a failure to resolve. Short example > > phrases of what sort of thing you don't want to see happen would be > > good. > > No. Okay, yeah, I wiffed on that one. I totally missed the point of the sentence and it is clearer to me now. Whoops. My bad. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
