"Alissa Cooper" <ali...@cooperw.in> writes: > - Agree with Terry's DISCUSS.
Fixed, FYI (Terry agrees with the solution at least; see that thread). > > - Sec. 2: The last paragraph here isn't really about "goals" and seems > like it belongs more appropriately in Sec 3. Good point. Moving it to a new "NOTE" in section 3. > - Sec 6.1: I thought recently gathered data has been pointing to the > futility of popping up security warnings (e.g., > http://neurosecurity.byu.edu/media/Anderson_et_al._CHI_2015.pdf). Does it > really make sense to recommend warning users in a BCP? What are users > expected to do as a result? Is there any evidence about the proportion of > users who even know what DNSSEC is? I'll have to read your paper, thanks for the pointer. As to section 6.1, it seems like in a BCP we should say *something* about what to do. Thus, the current text says this: <section title="What To Do"> <t>If Host Validator detects that DNSSEC resolution is not possible it SHOULD log the event and/or SHOULD warn user. In the case there is no user no reporting can be performed thus the device MAY have a policy of action, like continue or fail. Until middle boxes allow DNSSEC protected information to traverse them consistently, software implementations may need to offer this choice to let users pick the security level they require.</t> </section> I supposed we could replace "warn" with something like "report an error to the user"? I think that's better so am making that change. -- Wes Hardaker Parsons _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
