Matt, thank you for updating the draft based on last call comments. I have verified that you seem to have addressed all the comments that I noted. I like the new definitions you added they add clarity, thanks.
But I noticed some “strange language” I section 3.1 you say in paragraph 2: For this specification to apply, the entire DNS RRset that is returned MUST be “secure” … Well the word entire is redundant if you are talking about single DNS RRset, BUT I think there are missing words i.e. the sentence should be: For this specification to apply, the entire chain of DNS RRset(s) that is returned MUST be “secure” … If the second interpretation is right some minor word-smithing in paragraph 3 is also needed. Olafur as document Shepard > On Feb 16, 2015, at 4:48 PM, ⌘ Matt Miller <[email protected]> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 2/16/15 11:08 AM, Viktor Dukhovni wrote: >> On Mon, Feb 16, 2015 at 10:35:44AM -0700, ? Matt Miller wrote: >> >>> Thanks for the feedback! More inline ... >>> >>>> Section 3.4 (Impact on TLA Usage) second bullet: >>>> >>>> Revert change from -08 to -09. The -08 language: [...] >>> >>> The original language did not account for the lack of records, >>> but I can see how this is too permissive. Perhaps the following >>> is more acceptable (replacing the last two bullets in >>> dane-srv-09)? >>> >>> o If the TLSA response is "bogus" or "indeterminate" (or the >>> lookup fails for reasons other than no records), then the client >>> MUST NOT connect to the target server (the client can still use >>> other SRV targets). >>> >>> o If the TLSA response is "insecure" (or no TLSA records >>> exist), then the client SHALL proceed as if the target server had >>> no TLSA records. It MAY connect to the target server with or >>> without TLS, subject to the policies of the application protocol >>> or client implementation. >> >> Much better and basically correct, provided that it is clear that >> "indeterminate" is the 4035 (not 4033) definition, and the phrase >> "fails for reasons other than no records" is sufficiently clear to >> the document's audience. It is a somewhat informal phrase... >> >> In the SMTP draft ([1] below my signature) "no records" (be it >> NOERROR with ancount==0 or NXDOMAIN) is defined as a non-error (a >> successful empty result). Your taxonomy is different, but my >> guess is that the text is good enough. >> >> [ Is denial of existence of a success or a failure? How many >> angels can dance on the head of a pin? ... ] >> >> ---- Question to the WG at large: >> >> Anyone see any room for confusion about the meaning of the proposed >> text? ---- >> >>> The parenthetical is meant to account for the lack of SRV >>> records, but I can see how that might be too permissive. Is the >>> following more acceptable? >>> >>> If the SRV lookup fails because the RRset is "bogus" (or the >>> lookup fails for reasons other than no records), the client MUST >>> abort its attempt to connect to the desired service. If the >>> lookup result is "insecure" (or no SRV records exist), this >>> protocol does not apply and the client SHOULD fall back to its >>> non-DNSSEC, non-DANE (and possibly non-SRV) behavior. >> >> Thanks. Looks fine, provided the "fails for reasons other than no >> records" bit is clear enough to the world at large. >> > > I'll submit -10 presently. > > > Thanks again, > > - -- > - - m&m > > Matt Miller < [email protected] <mailto:[email protected]> > > Cisco Systems, Inc.
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
