Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation)
On Mon, Jan 22, 2018 at 04:45:43PM +0200, ox wrote:
Have I made myself sufficiently clear?
Not really.
Right. I will then re-iterate all of my arguments including the ones against v1. 1) The proposal states: "Improving the trust and safety of the IP address space is a priority for the RIPE community. It has therefore established the Assisted Registry Check (ARC) in order to help its members strengthen registry data by explaining the risks of outdated information and the benefits of ensuring their data is correct. ARC reviews are carried out for approximately 25%-30% of the membership every year and cover four subject areas: registry consistency, resource consistency, route/rDNS consistency and resource certification usage/consistency (RPKI). However, the ARC was not designed for the validation of the “abuse-c:” contact." While the ARC was not specifically designed to validate the correctness of abuse-c, it is *suitable* for the purpose. I disagree with the implication that the ARC can't be used to perform this validation. In my view, nothing makes abuse-c: any more special than admin-c: and tech-c:, so that it needs a separate ARC all of its own 2) The proposal states: "The objective of this proposal is not to devise a detailed validation procedure. The RIPE NCC is best placed to assess the technical challenges and the financial and human resources necessary to conduct validation tests in the most efficient manner." This actually makes the entire discussion around captchas and humans wasting their time with reading abuse-c emails redundant. Nothing of the kind of process you're dreaming about is actually part of the proposal, so I will forgo any further discussion on this unless a new implementation proposal comes along. What you have is a problem with the Impact Assessment and the way the NCC proposes to validate this contact. In fact, on this point alone, *I* should support the proposal and *you* should oppose it. (However, since I'm not sure the implementation process cannot just change without my consent, I still oppose it on this point, too) 3) Not explicitly stated in the proposal. The proposal and the IA assume that the abuse-c: is an email address (and the object, iirc explicitly asks for one). I don't think any new policy should be made that, even implicitly, ties RIPE NCC database information to legacy technologies. rgds, Sascha Luck
On Mon, Jan 22, 2018 at 04:20:41PM +0000, Sascha Luck [ml] wrote:
it. (However, since I'm not sure the implementation process cannot just change without my consent, I still oppose it on this point, too)
Actually, a question for the chairs on the PDP: Is the implentation plan a part of the proposal insofar as, should the policy be adopted, a new proposal is required to make changes to the process? TIA, Sascha Luck
On 22/01/2018 16:25, Sascha Luck [ml] wrote:
On Mon, Jan 22, 2018 at 04:20:41PM +0000, Sascha Luck [ml] wrote:
it. (However, since I'm not sure the implementation process cannot just change without my consent, I still oppose it on this point, too)
Actually, a question for the chairs on the PDP: Is the implentation plan a part of the proposal insofar as, should the policy be adopted, a new proposal is required to make changes to the process?
In short, yes. The impact analysis becomes part of the policy proposal and therefore is also a subset over what the community has to reach consensus. So any significant changes to the implementation would need to be communicated to the WG and also their approval would be needed. To be clear, the changes suggested in this conversation would absolutely be seen as significant changes! Brian Co-Chair, RIPE AA-WG
On Mon, 22 Jan 2018 16:20:41 +0000 "Sascha Luck [ml]" <aawg@c4inet.net> wrote: <snip v1 around here - as we are already past that>
"The objective of this proposal is not to devise a detailed validation procedure. The RIPE NCC is best placed to assess the technical challenges and the financial and human resources necessary to conduct validation tests in the most efficient manner."
This actually makes the entire discussion around captchas and humans wasting their time with reading abuse-c emails redundant. Nothing of the kind of process you're dreaming about is actually part of the proposal, so I will forgo any further discussion on this unless a new implementation proposal comes along. What you have is a problem with the Impact Assessment and the way the NCC proposes to validate this contact. In fact, on this point alone, *I* should support the proposal and *you* should oppose it. (However, since I'm not sure the implementation process cannot just change without my consent, I still oppose it on this point, too)
it is most definitely not "detailed validation procedure" to simply say: send an alphanumeric key to be entered on website after solving a capcha this entire issue makes abuse-c special, much more special than admin/tech etc. MANY auto respond, ignore, save money, avoid, etc their abuse-c - in fact there is also a lot of fake, non functional and dev/null abuse-c records. we would not be having this discussion or any need for all this if this was not an Internet abuse issue or an issue at all. yet, here we are. even if it is not specified/accepted in v2 RIPE NCC may well consider that it is the best "technical and financial" benefit to design the abuse-c validation in this manner - as it is ethical, mostly automated and does solve two extremely important issues unique to abuse-c
3) Not explicitly stated in the proposal. The proposal and the IA assume that the abuse-c: is an email address (and the object, iirc explicitly asks for one). I don't think any new policy should be made that, even implicitly, ties RIPE NCC database information to legacy technologies.
you make no sense? Please help me understand what you are saying? if you regard email as a legacy technology, which direct communication standard has overtaken it? afaik the death of email has been 'marketed' for the past 30 years. but it is FUD as there is simply no other general communication standard that replaces it (and there has never been) Kind Regards Andre
participants (3)
-
Brian Nisbet -
ox -
Sascha Luck [ml]