<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Eric, Becky,<div><br></div><div>Speaking only for myself but from the perspective of an active SSAC member, I can say that my understanding of SAC032 is very much in line with Becky’s. </div><div><br></div><div>As someone who’s tried to develop helpful advice, it is rewarding to see when SSAC advice is found useful by others and implemented by various parts of the Internet community. However, the advice itself does not have to be followed by anyone - the ‘power' of the advice comes only from the technical merit of the advice _not_ from any regulatory or authority perspective. </div><div><br></div><div>Although this might not have been clear in SAC032 (and some other SSAC publications), SSAC has tried to be more clear in recently - to quote from most of the Preface of most recent SSAC publications:</div><div><br></div><div><div style="margin: 0px; font-size: 12px; font-family: 'Times New Roman'; color: rgb(0, 0, 10);">The SSAC has no authority to regulate, enforce, or adjudicate. Those functions belong to others, and the advice offered here should be evaluated on its merits.</div></div><div><br></div><div>As one who was an original member, I firmly believe that SSAC advice has always been just that - advice that could be accepted, rejected or simply ignored. When people cite an SSAC publication as 'a source of authority’ for some action (past or future), that does not correctly represent SSAC advice. However, if some activity that does have authority for making relevant decisions chooses to follow SSAC advice, then the one with the authority is making the decision (but the authority is _never_ that of SSAC).</div><div><br></div><div>Russ Mundy</div><div><br></div><div><div><div>On Nov 9, 2015, at 1:19 PM, Burr, Becky <<a href="mailto:Becky.Burr@neustar.biz">Becky.Burr@neustar.biz</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><div style="font-family: Calibri, sans-serif;"><span style="font-size: 16px;">Eric,</span></div><div style="font-family: Calibri, sans-serif;"><span style="font-size: 16px;"><br></span></div><div style="font-family: Calibri, sans-serif;"><span style="font-size: 16px;">I have a different recollection of the Wildcard issue, and a different understanding of SSAC 032. </span></div><div style="font-family: Calibri, sans-serif;"><span style="font-size: 16px;"><br></span></div><div style="font-family: Calibri, sans-serif;"><span style="font-size: 16px;">My clear recollection was that the Board challenged the Verisign Wildcard proposal on stability and security grounds, prohibited its use – BY gTLD REGISTRY OPERATORS – on those grounds, and issued the New Registry Services review review process (found in registry agreements) in response. </span></div><div style="font-family: Calibri, sans-serif;"><span style="font-size: 16px;"><br></span></div><div><font face="Calibri,sans-serif"><span style="font-size: 16px;">SSAC 032 on Redirection does not appear to me to regulate anyone. In SSAC 032, the advisory committee “encourages the community to consider the broad implications of turning negative responses into revenue opportunities without consideration of the operational consequences and without consideration for the wishes of either registrants or clients of DNS data.” While conveying the reasoned views of DNS security experts, nothing about the report amounts to “regulation” by my read. It does not regulate down stream DNS server operators either directly (how could it?) or indirectly through registry operators. Nor am I aware that ICANN has attempted to use SSAC 032 for that purpose.</span></font></div><div style="font-family: Calibri, sans-serif;"><span style="font-size: 16px;"><br></span></div><div style="font-family: Calibri, sans-serif;"><span style="font-size: 16px;">So, as I read this, ICANN’s opposition to the Verisign Wildcard program on stability and security grounds falls squarely within ICANN’s Mission as stated in the current CCWG proposed text, and nothing about ICANN’s actions in this regard would appear to be in conflict with the proposed language precluding regulation of services that use the Internet’s unique<span class="Apple-converted-space"> </span><span style="font-family: Calibri; line-height: 17px;">identifiers to enable or facilitate their reachability over the Internet or the content such services provide.</span></span></div><div style="font-family: Calibri, sans-serif; font-size: 14px;"><span style="font-family: Calibri; font-size: 11pt; line-height: 16px;"><br></span></div><div style="font-family: Calibri, sans-serif; font-size: 14px;"><span style="font-family: Calibri; font-size: 11pt; line-height: 16px;">Becky</span></div><div style="font-family: Calibri, sans-serif; font-size: 14px;"><div><br></div><div style="margin: 12pt 0in 8pt; line-height: 16px; font-size: 11pt; font-family: Calibri;"><br class="webkit-block-placeholder"></div><p class="MsoNormal" style="margin: 12pt 0in 8pt; line-height: 16px; font-size: 11pt; font-family: Calibri;"><b><span style="font-size: 9pt; line-height: 13px;">J. Beckwith Burr</span></b><b><span style="font-size: 10pt; line-height: 14px; color: rgb(38, 38, 38);"> </span></b><b><span style="font-size: 9pt; line-height: 13px; color: rgb(51, 102, 255);"><br></span></b><b><span style="font-size: 9pt; line-height: 13px; color: rgb(0, 134, 86);">Neustar, Inc.</span></b><b><span style="font-size: 9pt; line-height: 13px; color: rgb(6, 134, 88);"> </span></b><span style="font-size: 9pt; line-height: 13px; color: rgb(125, 125, 125);">/</span><b><span style="font-size: 9pt; line-height: 13px; color: rgb(6, 134, 88);"> </span></b><span style="font-size: 9pt; line-height: 13px; color: rgb(125, 125, 125);">Deputy General Counsel & Chief Privacy Officer<br>1775 Pennsylvania Avenue NW, Washington D.C. 20006</span><span style="font-size: 9pt; line-height: 13px; color: gray;"><br></span><b><span style="font-size: 9pt; line-height: 13px; color: rgb(0, 134, 86);">Office:</span></b><b><span style="font-size: 9pt; line-height: 13px; color: rgb(125, 125, 125);"> </span></b><span style="font-size: 9pt; line-height: 13px; color: rgb(125, 125, 125);">+1.202.533.2932 <span class="Apple-converted-space"> </span></span><b><span style="font-size: 9pt; line-height: 13px; color: rgb(0, 134, 86);">Mobile:</span></b><b><span style="font-size: 9pt; line-height: 13px; color: rgb(125, 125, 125);"> </span></b><span style="font-size: 9pt; line-height: 13px; color: rgb(125, 125, 125);">+1.202.352.6367<span class="Apple-converted-space"> </span><strong><span style="font-family: Arial;">/</span></strong></span><span style="font-size: 9pt; line-height: 13px; color: rgb(6, 134, 88);"> </span><a href="http://www.neustar.biz/"><b><span style="font-size: 9pt; line-height: 13px; color: rgb(0, 134, 86);">neustar.biz</span></b></a><span style="font-size: 9pt; line-height: 13px; color: gray;"><o:p></o:p></span></p></div></div><div style="font-family: Calibri, sans-serif; font-size: 14px;"><br></div><span id="OLK_SRC_BODY_SECTION" style="font-family: Calibri, sans-serif; font-size: 14px;"><div style="font-family: Calibri; font-size: 11pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);"><span style="font-weight: bold;">From:<span class="Apple-converted-space"> </span></span>Eric Brunner-Williams <<a href="mailto:ebw@abenaki.wabanaki.net">ebw@abenaki.wabanaki.net</a>><br><span style="font-weight: bold;">Date:<span class="Apple-converted-space"> </span></span>Sunday, November 8, 2015 at 9:21 PM<br><span style="font-weight: bold;">To:<span class="Apple-converted-space"> </span></span>Accountability Community <<a href="mailto:accountability-cross-community@icann.org">accountability-cross-community@icann.org</a>><br><span style="font-weight: bold;">Subject:<span class="Apple-converted-space"> </span></span>[CCWG-ACCT] Fwd: Re: regulatory/mission issue WS2<br></div><div><br></div><div><div bgcolor="#FFFFFF" text="#000000">Colleagues,<br><br>Correspondence which inadvertently didn't go to the archived ccwg-acct list. My response to Malcolm, followed by Malcolm's query.<br><br>Eric Brunner-Williams<br>Eugene, Oregon<br><div class="moz-forward-container"><br><br>-------- Forwarded Message --------<table class="moz-email-headers-table" border="0" cellpadding="0" cellspacing="0"><tbody><tr><th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject:</th><td>Re: [CCWG-ACCT] regulatory/mission issue WS2</td></tr><tr><th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date:</th><td>Sun, 8 Nov 2015 10:43:36 -0800</td></tr><tr><th align="RIGHT" nowrap="nowrap" valign="BASELINE">From:</th><td>Eric Brunner-Williams<span class="Apple-converted-space"> </span><a class="moz-txt-link-rfc2396E" href="mailto:ebw@abenaki.wabanaki.net"><ebw@abenaki.wabanaki.net></a></td></tr><tr><th align="RIGHT" nowrap="nowrap" valign="BASELINE">To:</th><td>Malcolm Hutty<span class="Apple-converted-space"> </span><a class="moz-txt-link-rfc2396E" href="mailto:malcolm@linx.net"><malcolm@linx.net></a></td></tr><tr><th align="RIGHT" nowrap="nowrap" valign="BASELINE">CC:</th><td><a class="moz-txt-link-abbreviated" href="mailto:accountability-cross-community-bounces@icann.org">accountability-cross-community-bounces@icann.org</a></td></tr></tbody></table><br><br><pre>Malcolm,
That bell has already rung. SSAC 032 has been published. The Board took
note of SiteFinder. More generally, the Corporation acted to prevent
correct resolutions causing harm in the case of the Conficker.C variant.
Still more generally, "we" (the "community") routinely produce
informational RFCs and Best Current Practices documents addressing
resolver operators, as well as others.
The "means to ensure continuous correct resolution" is not limited to
"the authority to direct, in a compulsory sense, the operators".
I suggest that this detour into my opinion on the rights of ISPs doesn't
illuminate the "what's a service?" question Becky and others are
struggling with. My point was we could be specific about what we're not
regulating, which I suspect means "content", not ASN filtering, not
route filtering, and not filtering forward and backwards name-to-address
resolution.
Finally, the issue is not what our work product has been, and to what
effect, but what it will be, after some transition. As I observed in the
conclusion of the note from which you picked the quote below, the
possibility of future work on resolution is obsoleted by the sweeping
prohibition language, with the exception as others have mentioned,
through contracts.
Cheers,
Eric Brunner-Williams
Eugene, Oregon
On 11/6/15 4:30 PM, Malcolm Hutty wrote:
> On 2015-11-06 22:09, Eric Brunner-Williams wrote:
>>
>> First, could we narrow what it is we're not regulating, ISPs do a lot
>> of things, but one thing they can do is operate recursive resolvers,
>> so in particular, the "no authority to regulate" means no means to
>> ensure continuous correct resolution of domain names by ISPs.
>
> Eric,
>
> Are you of the opinion that ICANN does in fact have the authority to
> direct,
> in a compulsory sense, the operators of name resolvers such as ISPs in
> how to operate them?
>
> Malcolm.
</pre><br></div><br></div></div></span>_______________________________________________<br>Accountability-Cross-Community mailing list<br><a href="mailto:Accountability-Cross-Community@icann.org">Accountability-Cross-Community@icann.org</a><br><a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community">https://mm.icann.org/mailman/listinfo/accountability-cross-community</a></div></blockquote></div><br></div></body></html>