<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Hi all,</div><div class=""><br class=""></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">It sounds like there were some fruitful discussions at ICANN 78. I'm sorry that I couldn't be a part of those discussions. I don't know if there's a record of the dinner conversation, but I have been trying to get up to speed by reviewing </span></font>the meeting from the NCAP meeting at ICANN 78. Just a few thoughts/questions that came to mind from the meeting.</div><div class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">1. Consensus was declared, but I don't completely understand what the consensus was. I think part of it was the idea that all of the listed/enumerated tools would be options for the TRT to employ. I still don't think option (4) application-layer interception should be among them (see item 3 below), and I still think that some of this should be a little more prescribed, so that the process is more standardized from one to another. But I suppose that I'm in the minority here, and if there's consensus, there's consensus.</div><div class=""><br class=""></div><div class="">2. A comment early on referred to the purpose of option (2) controlled interruption was notification, but option (3) "reject-all" was *not* notification. I completely disagree with this. But it might be because my understanding of "notification" is different than someone (everyone?) else's.</div><div class=""><br class=""></div><div class="">If notify means "cause an interruption to let users/systems/organizations know that there is a problem", then (3) is just as much notification as (2). I see it as users have more or less the same experience; the difference is that additionally transport-layer data is collected.</div><div class=""><br class=""></div><div class="">If notify means "point the user/system/organization to the cause of such a problem", then both (2) and (3) (and (4)) have elements of this. Obviously, the idea behind (2) is for the users/systems to search for the controlled interruption IP address (although the root cause analysis shows that the controlled interruption IP address (127.0.53.53) was found or understood relatively infrequently). However, the same can be done with (3), as I've written elsewhere, by doing similar lookups and/or reverse DNS tricks. The effectiveness of this latter one is untested.</div><div class=""><br class=""></div><div class="">If notify means "actually display readable information to the user/system/organization", only (4) plays this role. But see next item.</div><div class=""><br class=""></div><div class="">3. Option (4) was mentioned quite a bit as an option. But given what was reported in the NCAP workshop in early October (Wash DC) about privacy and the (un)likelihood of this actually being approved, why are we still even considering it as one of the tools?</div><div class=""><br class=""></div><div class="">4. What does "minimum coverage" mean in the slide?</div><div class=""><br class=""></div><div class="">Thanks everyone.</div><div class=""><br class=""></div><div class="">Casey</div></body></html>