<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" 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 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Times New Roman \(Cuerpo en alfa";
panose-1:2 2 6 3 5 4 5 2 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
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.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EstiloCorreo18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=ES link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span lang=ES-TRAD style='font-size:12.0pt;mso-fareast-language:EN-US'>Hi Marilson,<o:p></o:p></span></p><p class=MsoNormal><span lang=ES-TRAD style='font-size:12.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><div><div><p class=MsoNormal style='margin-left:35.4pt'>El 27/3/19 1:34, "ARIN-PPML en nombre de Marilson Mapa" <<a href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a> en nombre de <a href="mailto:marilson.mapa@gmail.com">marilson.mapa@gmail.com</a>> escribió:<o:p></o:p></p></div></div><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><div><div><p class=MsoNormal style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:10.0pt;margin-left:35.4pt;line-height:115%'><span style='font-size:12.0pt;line-height:115%'>If the current policy, “3.6. Annual Validation of ARIN’s Public Whois Point of Contact Data” does not provide sufficient validation of the actual availability of the abuse mailbox, a standard abuse-c/abuse-mailbox as a pointer to the actual abuse POC, also won't solve the problem of the abuse victim.<o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:10.0pt;line-height:115%'><span lang=EN-US style='font-size:12.0pt;line-height:115%'>I think the validation should be more exhaustive, this is one of the aspects of my proposal.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:10.0pt;margin-left:35.4pt;line-height:115%'><span lang=EN-US style='font-size:12.0pt;line-height:115%'>If the goal is to reduce costs for resource-holders (LIRs and end-users) without worrying about the victims of abuse, go ahead but you will have to listen to criticism.<o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:10.0pt;line-height:115%'><span lang=EN-US style='font-size:12.0pt;line-height:115%'>The most important goal is to ensure that an abuse complain is really taken in consideration, and not automated or re-directed to a web form that is different for every ISP, which makes impossible, especially for small ISPs to develop an automated mechanism to fill-in hundreds (if not thousands) of different forms. Ideally, we should have an IETF standard to do that, and the policy should be so simple as “you must use this standard” to send/receive abuse cases, but we don’t have that. If the standard come later, we can then accommodate the policy proposal.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:10.0pt;margin-left:35.4pt;line-height:115%'><span lang=EN-US style='font-size:12.0pt;line-height:115%'>The reason is obvious and widely known and easy to prove. </span><span style='font-size:12.0pt;line-height:115%'>The AUPs, ToSs and ASPs, widely exposed on provider sites, are not obeyed. Most ISPs protect, hide, and make no demands on customers denounced with evidence.<o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:10.0pt;line-height:115%'><span style='font-size:12.0pt;line-height:115%'>Which is not right!<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:10.0pt;margin-left:35.4pt;line-height:115%'><span lang=EN-US style='font-size:12.0pt;line-height:115%'> I am talking about an exaggerated laissez faire, total lack of ethics and disrespect to the population of the planet. </span><span style='font-size:12.0pt;line-height:115%'>Imagine IoT in the hands of such people I can only glimpse a black future. </span><span lang=EN-US style='font-size:12.0pt;line-height:115%'>A future in which everyone loses because the internet will cease to be free.<o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:10.0pt;line-height:115%'><span lang=EN-US style='font-size:12.0pt;line-height:115%'>Se before we go into a massive fatal situation, let’s work on ensure that we are all respected.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:10.0pt;margin-left:35.4pt;line-height:115%'><span lang=EN-US style='font-size:12.0pt;line-height:115%'>What do you intend to include in this policy to force ISPs to have ethical behavior as described in their AUPs and ToSs?<o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:10.0pt;line-height:115%'><span lang=EN-US style='font-size:12.0pt;line-height:115%'>I just intend to make sure that abuse cases are actually processed, not ignored, which means that the abuse mail-box is functional and not an “always full mail-box”.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:10.0pt;margin-left:35.4pt;line-height:115%'><span style='font-size:12.0pt;line-height:115%'>Marilson<o:p></o:p></span></p></div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p><div><div><p class=MsoNormal style='margin-left:35.4pt'>Em ter, 26 de mar de 2019 às 16:53, ARIN <<a href="mailto:info@arin.net">info@arin.net</a>> escreveu:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal style='margin-left:35.4pt'>On 21 March 2019, the ARIN Advisory Council (AC) accepted <br>"ARIN-prop-264: Validation of Abuse-mailbox" as a Draft Policy.<br><br>The Draft Policy text is below and can be found at:<br><a href="https://www.arin.net/participate/policy/drafts/2019_5/" target="_blank">https://www.arin.net/participate/policy/drafts/2019_5/</a><br><br>You are encouraged to discuss all Draft Policies on PPML. The AC will <br>evaluate the discussion in order to assess the conformance of this draft <br>policy with ARIN's Principles of Internet number resource policy as <br>stated in the Policy Development Process (PDP). Specifically, these <br>principles are:<br><br>* Enabling Fair and Impartial Number Resource Administration<br>* Technically Sound<br>* Supported by the Community<br><br>The PDP can be found at:<br><a href="https://www.arin.net/participate/policy/pdp/" target="_blank">https://www.arin.net/participate/policy/pdp/</a><br><br>Draft Policies and Proposals under discussion can be found at:<br><a href="https://www.arin.net/participate/policy/drafts/" target="_blank">https://www.arin.net/participate/policy/drafts/</a><br><br>Regards,<br><br>Sean Hopkins<br>Policy Analyst<br>American Registry for Internet Numbers (ARIN)<br><br><br><br>Draft Policy ARIN-2019-5: Validation of Abuse-mailbox<br><br>Problem Statement:<br><br>The current policy, “3.6. Annual Validation of ARIN’s Public Whois Point <br>of Contact Data” does not provide sufficient validation of the actual <br>availability of the abuse mailbox.<br><br>As a result, some resource-holders (LIRs and end-users) might not keep <br>this contact information up to date, or might use a non-responsive <br>mailbox, which could be full or not actively monitored, or even <br>responding only to ARIN emails.<br><br>In practice, this contact becomes ineffective to report abuse and <br>generally gives rise to security issues and costs for the victims.<br><br>Furthermore, POCs are verified only every year and provides a too much <br>relaxed response time (60 days).<br><br>Finally, the proposal is aiming to have a standard abuse-c/abuse-mailbox <br>as a pointer to the actual abuse POC, in order to facilitate tools <br>across regions.<br><br>This proposal aims to solve those issues and ensure the existence of a <br>proper abuse-c POC and the process for its utilisation.<br><br>a. Arguments Supporting the Proposal<br><br>The Internet community is based on collaboration. However, in many cases <br>this is not enough and we need to be able to contact those <br>resource-holders (LIRs or end-users) that may be experiencing a problem <br>in their networks and are unaware of the situation.<br><br>This proposal solves this problem by means of a simple, periodic <br>verification, and establishes the basic rules for performing such <br>verification and thus avoids unnecessary costs to third parties that <br>need to contact the persons responsible for solving the abuses of a <br>specific network.<br><br>The proposal guarantees that the cost of processing the abuse falls on <br>the resource-holder causing the abuse (or its customers, from whom they <br>receive financial compensation for the service), instead of falling on <br>the victim, as would be the case if they had to resort to a legal claim <br>in an extreme case, thus avoiding costs (investigation and in the <br>worst-case lawyers, solicitors, etc.) and saving time for both parties.<br><br>Having an equivalent policy in different regions, has the advantage of <br>improving overall response to abuse cases, reduces the cost for handling <br>them, and facilitates the work for all the people involved in the <br>operation of Internet.<br><br>b. Arguments Opposing the Proposal<br><br>ARIN members have to verify and update (if required) their abuse-c <br>objects periodically.<br><br>Policy Statement:<br><br>Proposed<br><br>1.0 Abuse Contact Information<br><br>The “abuse-c:” will reference a role object holding abuse contact <br>information. The positioning of the “abuse-c:” attributes will make use <br>of the hierarchical nature of the resource data to minimize the workload <br>on resource holders. Internet number resources need to have an <br>“abuse-c:” attribute. The “abuse-c:” will be mandatory for all aut-nums. <br>Due the hierarchical nature of IP address objects, at least every direct <br>allocated inetnum and inet6num needs to have an “abuse-c:”. Inherited <br>objects might have their own “abuse-c:” attribute or they will be <br>covered by the higher-level objects. The role objects used for abuse <br>contact information will be required to contain a single <br>“abuse-mailbox:” attribute which is intended for receiving automatic and <br>manual reports about abusive behavior originating in the resource <br>holders’ networks. The “abuse-mailbox:” attribute must be available in <br>an unrestricted way via whois, APIs and future techniques. ARIN will <br>validate the “abuse-mailbox:” attribute at least every six months, as <br>per the procedure stated in this policy. Where the attribute is deemed <br>incorrect, it will follow up in compliance with relevant ARIN policies <br>and procedures. As per current practice, other “e-mail:” attributes can <br>be included for any other purposes.<br><br>2.0 About the “abuse-mailbox”<br><br>Emails sent to “abuse-mailbox” must require manual intervention by the <br>recipient at some point, and may not be filtered, because in certain <br>cases this might prevent receiving abuse reports, for example in a spam <br>case where the abuse report could include the spam message itself or <br>URLs or content usually classified as spam. The “abuse-mailbox” may <br>initially send an automatic reply, for example assigning a ticket <br>number, applying classification procedures, requesting further <br>information, etc. However, it should not require that the abuse reporter <br>fills a form, as this will imply that each entity that needs to report <br>abuse cases (a task that is typically automated), would be forced to <br>develop a specific interface for each resource-holder in the world that <br>mandates filling forms, which is neither feasible nor logical, as it <br>would place the cost of processing the abuse on those who submit the <br>claim and are therefore victims of the abuse, instead of being paid for <br>by those whose clients cause the abuse (and from whom they obtain <br>income). By way of information, it is worth noting that it is reasonable <br>to expect that the abuse reporting procedure sends, with the initial <br>abuse report, the logs, a copy of the spam message (attaching an example <br>of the spam email or its full headers), or equivalent evidence <br>(depending on the abuse type). Likewise, it is reasonable to expect that <br>the initial auto-reply email could specify that the claim will not be <br>processed unless such evidence has been submitted, thus allowing the <br>sender an opportunity to repeat the submission and include relevant <br>evidence. This allows automatic reporting, for example, via fail2ban, <br>SpamCop or others, keeping costs at a minimum for both parties involved.<br><br>3.0 Objectives of “abuse-mailbox” validation<br><br>The procedure, which will be developed by the ARIN, must meet the <br>following objectives: 1. A simple process that guarantees its <br>functionality and allows the helpdesks that deal with abuse reports to <br>verify that validation requests actually come from the ARIN and not from <br>third parties (which might involve security risks), avoiding, for <br>example, a single “direct” URL for validation. 2. Avoid exclusively <br>automated processing. 3. Confirm that the person performing the <br>validation understands the procedure and the policy, that they regularly <br>monitor the “abuse-mailbox”, that measures are taken, and that the abuse <br>report receives a response. 4. Validation period of no longer than 15 <br>days. 5. If validation fails, escalate to the LIR and set a new <br>validation period not to exceed 15 days. The “initial” and “escalation” <br>validation periods may be modified by the ARIN, if deemed appropriate, <br>informing the community about the motivation. For example, it could be <br>longer for the first validation, once this policy is implemented, and <br>shortened afterwards once the percentage of failures decreases, so the <br>quality of the contacts increases and consequently a decrease in the <br>average abuse response times could be expected. (By way of example, a <br>detailed procedure is included in this policy proposal under <br>“Comments/Example of the validation procedure”) 4.0 Validation of <br>“abuse-mailbox”<br><br>ARIN will validate compliance with the items above, both when the <br>“abuse-c:” and/or “abuse-mailbox:” attributes are created or updated, as <br>well as periodically, not less than once every six months, and whenever <br>ARIN sees fit. At the discretion of ARIN, in general or in specific <br>cases (for example, for confirmation in cases of escalation under 5.), <br>ARIN may use domains other than arin., and even modify the subject and <br>body of the message, in order to perform said validations more <br>effectively. Lack of compliance will initially lead to the blocking of <br>that account’s access to the invalid resources at ARIN Online, except <br>for the abuse-c/abuse-mailbox update and payments. The account blocking <br>will be released upon re-validation of the abuse-c/ abuse-mailbox, <br>triggered automatically by the update of the abuse-c/abuse-mailbox. <br>During the blocking of that account to the invalid resources, each time <br>is accessed, will show a warning message including this policy text, and <br>to continue it will be necessary to confirm by means of a check-box, <br>that the message has been read in full. ARIN will do a more exhaustive <br>follow-up, in accordance with the relevant ARIN policies, procedures or <br>contractual requirements. The frequency of the periodic validation could <br>be modified if ARIN deems this appropriate and informs the community of <br>its reasons. For example, a single validation could be done in the first <br>year, to facilitate adherence to the policy, and then the number of <br>annual validations could progressively increase, reaching even quarterly <br>ones, with the aim of improving the quality of the contacts.<br><br>5.0 Escalation to ARIN<br><br>To avoid fraudulent behavior (for example, an “abuse-mailbox” that only <br>replies to ARIN emails or to messages with a specific subject or <br>content), or failure to comply with the remaining aspects of this policy <br>(incorrect or lack of response to cases of abuse), a mailbox will be <br>available (for example, “<a href="mailto:escalation-abuse@arin.net" target="_blank">escalation-abuse@arin.net</a>”), to escalate such <br>situations. This would allow for a re-validation (according to section <br>4. above) and even intervention by ARIN and, where appropriate, the <br>application of the relevant policies, procedures or contractual <br>requirements.<br><br>Comments:<br><br>Timetable for implementation: Immediate<br><br>Anything Else<br><br>Situation in other regions:<br><br>A similar proposal has been accepted in APNIC (being implemented) and is <br>under discussion in the LACNIC and AFRINIC regions. It has also been <br>submitted to RIPE (still not published).<br><br>Example of the validation procedure.<br><br>1. ARIN initiates the validation automatically, sending TWO consecutive <br>emails to the “abuse-mailbox”.<br><br>2. These emails will be sent containing plain text only.<br><br>3. The first email will contain the URL where the validation is to be <br>performed (“<a href="http://validation.arin.net" target="_blank">validation.arin.net</a>”) and may contain information about the <br>procedure, a brief summary of this policy, etc.<br><br>4. The second email will contain a unique alphanumeric validation code.<br><br>5. The person in charge of the “abuse-mailbox” must go to the URL and <br>paste the code received in the second email in the form.<br><br>6. This URL must be designed in such a way that it prevents the use of <br>an automated process (for example, “captcha”). In addition, it must <br>contain a text that confirms that the person performing the validation <br>understands the procedure and the policy, that they regularly monitor <br>the “abuse-mailbox”, that measures are taken to solve reported cases of <br>abuse, and that the abuse report receives a response, with a “checkbox” <br>that must be accepted in order to proceed.<br><br>7. The alphanumeric code will only be valid for a maximum of 15 working <br>days.<br><br>8. If the code is not entered within that time, the system will mark the <br>“abuse-c” as “temporarily invalid” and will alert ARIN staff so that <br>they can initiate a personalized follow-up with the LIR.<br><br>9. If no reply is received confirming that the situation has been <br>corrected, after an additional period of three business days, the <br>“abuse-c” will be permanently marked as “invalid”.<br><br>10. Once the issue has been resolved, the validation process will be <br>repeated automatically (items 1 to 7 above). If satisfactory, the <br>“abuse-c” will be marked as “valid”; otherwise it will be considered in <br>breach of the policy.<br>_______________________________________________<br>ARIN-PPML<br>You are receiving this message because you are subscribed to<br>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>Unsubscribe or manage your mailing list subscription at:<br><a href="https://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<o:p></o:p></p></blockquote></div></div><p class=MsoNormal style='margin-left:35.4pt'>_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact info@arin.net if you experience any issues. <o:p></o:p></p></div><br>**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
http://www.theipv6company.com<br>
The IPv6 Company<br>
<br>
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.<br>
<br>
</body></html>