<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";
        mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {mso-style-priority:99;
        mso-style-link:"Plain Text Char";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Arial","sans-serif";
        color:black;
        mso-fareast-language:EN-US;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";
        mso-fareast-language:EN-US;}
span.PlainTextChar
        {mso-style-name:"Plain Text Char";
        mso-style-priority:99;
        mso-style-link:"Plain Text";
        font-family:Consolas;
        mso-fareast-language:EN-US;}
p.Textebrut, li.Textebrut, div.Textebrut
        {mso-style-name:"Texte brut";
        mso-style-link:"Texte brut Car";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";
        mso-fareast-language:EN-US;}
span.TextebrutCar
        {mso-style-name:"Texte brut Car";
        mso-style-priority:99;
        mso-style-link:"Texte brut";
        font-family:"Arial","sans-serif";
        color:black;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;
        mso-fareast-language:EN-US;}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";
        mso-fareast-language:EN-US;}
span.EmailStyle25
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi everyone, <span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Thanks for your questions and comments. In light of those, Hervé and I will prepare a slightly amended version of the proposal to specify some languages, in particular when it comes to the role of RIPE NCC’s impact analysis in providing
 more details about the concrete implementation of this policy change proposal. <o:p>
</o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Andre rightly asked what was the goal of the proposal. Ultimately, the goal of the proposal is to reduce the likelihood of getting no response when someone (anyone) need to urgently contact a LIR via the abuse-c contact. To achieve this
 goal we believe that RIPE NCC should be mandated to regularly validate the abuse-c contact point. We think that the main criteria to decide whether to move the proposal to the review phase or not, should be whether there is a majority of AAWG members who thinks
 that having a valid and functioning abuse-c contact points is a valid goal. <o:p>
</o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Most questions raised were about the actual implementation of the proposal. As explained by Marco/RIPE NCC, the practical details of how the validation procedure will be implemented should not be laid down in the policy change proposal
 at this stage but rather by the impact analysis that RIPE NCC will conduct. RIPE NCC is the best placed to propose a working procedure (whether it should be done in the framework of ARC, what will be the criteria to consider a contact point invalid, how to
 address auto-answer, how often the validation process should be carried out etc.) because they are the ones who can best assess the financial and human resources to conduct these checks in the most efficient manner.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Lastly, it seems that some members assume that this proposal is driven by law enforcement (LE) needs only. It is not. All network operators/LIRs have at some points been in the frustrating situation of not being able to find a valid contact
 point, this is why Hervé/Orange is co-authoring the proposal. There is not so many ways of ensuring that you get an answer: the community needs to agree that at least one contact point will be validated by RIPE NCC. In parallel, law enforcement is indeed working
 with NCC and some RIPE members to develop our knowledge and possibly a tool to visualize BGP routing tables. But improving the way LE can identify and investigate malicious IPs is not the goal of this policy change proposal.
<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">In conclusion, we think that so far, except for one or two members who explicitly opposed the goal of the proposal, a majority of members who expressed themselves on the AAWG mailing list during the discussion phase, agrees with the general
 objective of the proposal – that is to mandate RIPE NCC to regularly validate abuse-c contact in order to reduce the likelihood of not getting an answer when someone needs to urgently contact a LIR.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Therefore, in agreement with the AAWG chair, we would like to move this proposal to the review phase.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Thanks<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Greg and Hervé <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-language:EN-GB">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-language:EN-GB"> anti-abuse-wg
 [mailto:anti-abuse-wg-bounces@ripe.net] <b>On Behalf Of </b>herve.clement@orange.com<br>
<b>Sent:</b> 09 October 2017 15:01<br>
<b>To:</b> Nick Hilliard; Michele Neylon - Blacknight<br>
<b>Cc:</b> ox; Gert Doering; anti-abuse-wg@ripe.net<br>
<b>Subject:</b> Re: [anti-abuse-wg] 2017-02 New Policy Proposal (Regular abuse-c Validation)<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoPlainText"><span lang="FR" style="font-family:"Calibri","sans-serif"">Hello Nick,<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="FR" style="font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US" style="font-family:"Calibri","sans-serif"">We have already talked with the RIPE NCC about ARC.<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US" style="font-family:"Calibri","sans-serif"">If the ARC would include actual contact validation, a same LIR would be contacted less frequently for a global audit.<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US" style="font-family:"Calibri","sans-serif"">Dealing specifically with abuse-c validation, RIPE NCC Impact Analysis will answer the question of extra work evaluation.<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US" style="font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US" style="font-family:"Calibri","sans-serif"">Hervé<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="FR" style="mso-fareast-language:FR">-----Message d'origine-----<br>
De : anti-abuse-wg [<a href="mailto:anti-abuse-wg-bounces@ripe.net">mailto:anti-abuse-wg-bounces@ripe.net</a>] De la part de Nick Hilliard<br>
Envoyé : lundi 9 octobre 2017 13:01<br>
À : Michele Neylon - Blacknight<br>
Cc : ox; Gert Doering; <a href="mailto:anti-abuse-wg@ripe.net">anti-abuse-wg@ripe.net</a><br>
Objet : Re: [anti-abuse-wg] 2017-02 New Policy Proposal (Regular abuse-c Validation)</span><span lang="FR"><o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="FR"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="FR">Michele Neylon - Blacknight wrote:<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="FR">> The current situation is that abuse-c can be populated with rubbish.<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="FR">> The email addresses can be completely non-functioning.<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="FR">> That is the real and current issue.<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="FR"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="FR">the real issue is that this is a complex layer 9 problem inside each organisation, and although creating technological tickbox policies will provide a veneer of doing something, that veneer is very thin.<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="FR"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="FR">The RIPE NCC already has a mechanism for information consistency audits, namely the Assisted Registry Check.<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="FR"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="FR">Has anyone talked to the RIPE NCC about including abuse contacts in the ARC, and been given credible reasons as to why this wouldn't be a simpler, better and more effective way of dealing with issue of stale / inaccurate
 details?<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="FR"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="FR">Nick<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="FR"><o:p> </o:p></span></p>
<pre><span lang="FR">_________________________________________________________________________________________________________________________<o:p></o:p></span></pre>
<pre><span lang="FR"><o:p> </o:p></span></pre>
<pre><span lang="FR">Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc<o:p></o:p></span></pre>
<pre><span lang="FR">pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler<o:p></o:p></span></pre>
<pre><span lang="FR">a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,<o:p></o:p></span></pre>
<pre><span lang="FR">Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.<o:p></o:p></span></pre>
<pre><span lang="FR"><o:p> </o:p></span></pre>
<pre><span lang="FR">This message and its attachments may contain confidential or privileged information that may be protected by law;<o:p></o:p></span></pre>
<pre><span lang="FR">they should not be distributed, used or copied without authorisation.<o:p></o:p></span></pre>
<pre><span lang="FR">If you have received this email in error, please notify the sender and delete this message and its attachments.<o:p></o:p></span></pre>
<pre><span lang="FR">As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.<o:p></o:p></span></pre>
<pre><span lang="FR">Thank you.<o:p></o:p></span></pre>
</div>
*******************<br><br>DISCLAIMER : This message is sent in confidence and is only intended for the named recipient. If you receive this message by mistake, you may not use, copy, distribute or forward this message, or any part of its contents or rely upon the information contained in it.<br>Please notify the sender immediately by e-mail and delete the relevant e-mails from any computer. This message does not constitute a commitment by Europol unless otherwise indicated.<br><br>*******************</body>
</html>