<html><head></head><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_ym19_1_1507038712082_378554">Hi</div><div id="yui_3_16_0_ym19_1_1507038712082_378579"> </div><div dir="ltr" id="yui_3_16_0_ym19_1_1507038712082_378621">I think you misunderstood what I said about the original policy and the design of "abuse-c:". Before "abuse-c:" there were 4 ways of adding abuse contact details into the database. The data was spread all over the place and it was practically impossible to find it with any reliability. The original policy set out to solve that specific problem. The arguments over verifying email addresses were just as contentious then as they are now. We knew if we tried to do everything in one step we would get bogged down and nothing would change. By creating a narrow, but very specific policy we improved the situation. </div><div dir="ltr"> </div><div dir="ltr">Just because that policy didn't force people to enter valid information with a threat of deregistration is no reason for anyone to enter junk into the database. There has always been a condition of membership that people enter and maintain correct information in the RIPE Database. A policy for verifying email addresses was left for another day...that day seems to be now...</div><div dir="ltr"> </div><div dir="ltr">cheers</div><div dir="ltr" id="yui_3_16_0_ym19_1_1507038712082_379088">denis</div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1507038712082_378553"> </div><div class="yahoo_quoted" id="yui_3_16_0_ym19_1_1507038712082_378545" style="display: block;"> <div style="font-family: Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" id="yui_3_16_0_ym19_1_1507038712082_378544"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;" id="yui_3_16_0_ym19_1_1507038712082_378543"> <div dir="ltr" id="yui_3_16_0_ym19_1_1507038712082_378551"> <hr size="1"> From: ox <andre@ox.co.za> To: "anti-abuse-wg@ripe.net" <anti-abuse-wg@ripe.net> Sent: Thursday, 5 October 2017, 6:00 Subject: Re: [anti-abuse-wg] 2017-02 New Policy Proposal (Regular abuse-c Validation) </div> <div class="y_msg_container" id="yui_3_16_0_ym19_1_1507038712082_378542"> <div dir="ltr" id="yui_3_16_0_ym19_1_1507038712082_378547">On Wed, 4 Oct 2017 23:54:44 +0000 (UTC) denis walker <<a shape="rect" ymailto="mailto:ripedenis@yahoo.co.uk" href="mailto:ripedenis@yahoo.co.uk" id="yui_3_16_0_ym19_1_1507038712082_378549">ripedenis@yahoo.co.uk</a>> wrote: > I have read the proposal and all the comments. Many things have > already been said. I will try to say something new, mostly on the > technical issues. My first comment is as the co author of the > original "abuse-c:" policy. It was clearly said during the discussion > about that policy that it was ONLY intended to define a place to > store abuse contact information in the RIPE Database. It was also if one is to store information in a database, surely it has to be actual data and not just random characters? so, if you store an abuse-c email record, in your statement, it is okay to store: <a shape="rect" ymailto="mailto:mickey.mouse@example.com" href="mailto:mickey.mouse@example.com">mickey.mouse@example.com</a> and RIPE has to store a lot of junk? what would the purpose of that be? > said that further policies may be brought forward at a later time > about validating the email addresses and/or enforcing action on abuse > reports. So the lack of any validation does not undermine the > existing policy. This was by design. > poor design or what else? one sometimes has to wonder at the motives and sometimes these motives seem immoral, not ethical and very vague and suspicious. all hidden under the guise of "freedom" - but freedom with zero responsibility is evil. > This policy extension is about validating the email address in the > "abuse-mailbox:" attribute. These will only exist in ROLE objects > after the planned cleanup to be done soon. These ROLE objects are > referenced by "abuse-c:" attributes in ORGANISATION objects and soon > INET(6)NUM and AUT-NUM objects. They may also be unreferenced. There > will be a default "abuse-c:" for all resources administered by the > RIPE NCC. There will also be delegated "abuse-c:" attributes in a > variety of places managed by or on behalf of customers of LIRs. It is > not clear at all in this proposal which ones are going to be > validated. Just the mandatory ones for resource holders or all of > them? Validating all of them will be more challenging both > technically and procedurally. But not validating them all may leave > invalid data in the RPE Database. > the point of storing data is to store actual data and not actual rubbish. otherwise you may as well propose the allocation of resources to Minnie and Mickey Mouse. > How will they be marked as invalid? Will this show up on a database > query or in the information returned from the Abuse Finder or > RIPEstat? Or is it for RIPE NCC internal use only? Will they only be > marked as invalid because of a lack of response from the test email? > What if someone informs the RIPE NCC of an invalid address? > this will need to be discussed as having junk data is not only pointless but also meaningless. Why does RIPE exist if there is fake/junk/rubbish data? > The new policy text says "attempt to correct the issue". Saying > 'attempt' is a very weak statement. If the end result 'could be' > deregistration then I think the policy should say something stronger > like "the issue will be fixed". If that is the end goal then make it > clear. > +1 > There is some mention of 'complying with national laws'. Did you have > a particular nation in mind or do you mean all nation's laws or just > all those in the RIPE region? > all EU nation laws, maybe the word EU could just be added? or is the intent "international" as in planet wide? (-1 for that) > One of the supporting arguments is given as "Validating “abuse-c:” > information is essential to ensure the efficiency of the abuse > reporting system." It may be "helpful to the effectiveness" but it > has nothing to do with efficiency. > it does. as junk in means junk out. the whole point of validating abuse-c is to firstly ensure the accuracy of data, which will serve to ensure efficiency of abuse reporting. > During the discussion it was said that using an auto responder would > validate the email address in compliance with this policy. So anyone > who doesn't intend to handle any abuse reports just needs to set up > an auto responder, or even filter emails on "@ripe.net" or on some > keyword/phrase in what will probably be a standard text and respond > to that email. The data is valid and the RIPE NCC at least will get a > response. But it is meaningless. Of course it will highlight those > resource holders who are already serious about handling abuse but > mistyped an address or forgot to update it. But resource holders who > have no intention of responding to any abuse complaint can easily > avoid any hassle from the RIPE NCC with this validation process. > ianal, but: an auto response is an acknowledgement of receipt. so, if you receive notice of a 100TB DDOS and you do nothing, you may be legally "more" liable. etc etc. > Also during this discussion it was said "The point is: if there is an > auto-responder, there won't be an absolute and definitive invalidity > of the answer. But additional investigations would be conducted, of > course." Now I am not an expert on the inner workings of email > clients. So do all auto responders add something to the email header > to make it clear it is an auto response? Or can one be configured to > send back an email looking as if I wrote it? If so what is going to > trigger the 'additional investigations' for auto responses? > any response is a response. so, it is semantics... > I don't understand why possible deregistration is listed as an > argument 'against' the proposal. > fake data?<div class="yqt7803307256" id="yqtfd40756"> > The arguments listed as supporting the proposal, in my mind, read > like a marketing brochure. I don't think that style of writing in > this type of proposal is helpful...but that is just my opinion... > > Overall I neither support nor oppose the policy. I just wanted to > highlight some issues. > > cheers > denis > > From: Marco Schmidt <<a shape="rect" ymailto="mailto:mschmidt@ripe.net" href="mailto:mschmidt@ripe.net">mschmidt@ripe.net</a>> > To: <a shape="rect" ymailto="mailto:anti-abuse-wg@ripe.net" href="mailto:anti-abuse-wg@ripe.net">anti-abuse-wg@ripe.net</a> > Sent: Thursday, 7 September 2017, 13:59 > Subject: [anti-abuse-wg] 2017-02 New Policy Proposal (Regular > abuse-c Validation) > Dear colleagues, > > A new RIPE Policy proposal, 2017-02, "Regular abuse-c Validation", is > now available for discussion. > > The goal of this proposal is to give the RIPE NCC a mandate to > regularly validate "abuse-c:" information and to follow up in cases > where contact information is found to be invalid. > > You can find the full proposal at: > <a shape="rect" href="https://www.ripe.net/participate/policies/proposals/2017-02" target="_blank">https://www.ripe.net/participate/policies/proposals/2017-02</a> > > As per the RIPE Policy Development Process (PDP), the purpose of this > four-week Discussion Phase is to discuss the proposal and provide > feedback to the proposer. > > At the end of the Discussion Phase, the proposer, with the agreement > of the RIPE Working Group Chairs, decides how to proceed with the > proposal. > > We encourage you to review this proposal and send your comments to > <<a shape="rect" ymailto="mailto:anti-abuse-wg@ripe.net" href="mailto:anti-abuse-wg@ripe.net">anti-abuse-wg@ripe.net</a>> before 6 October 2017. > > Kind regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- <a shape="rect" href="https://www.ripe.net/participate/mail/forum" target="_blank">https://www.ripe.net/participate/mail/forum</a> > > > </div></div> </div> </div> </div> </div></div></body></html>