Re: [members-discuss] Registry Services Ticket Response Time

Dear Felipe, while we wait for you to crop up a roadmap, I am still waiting for the statistics I asked from Marco weeks ago. Marco, I’d like to see real numbers and not just .. this Q we handled x% more tickets than last Q. Usually when statistics are presented this way, without backing numbers, they express a story you want us to see and not the whole picture. So, while Felipe works on the roadmap, please send us the statistics that you already have about number of tickets handled daily, number of FTEs working on those tickets daily and make sure we receive these numbers for at least since you stopped showing this information transparently (circa 2015). I hope you can provide these numbers swiftly and it won’t take weeks to provide them but rather days (you’ve been working on these stats/numbers since my initial e-mail requesting them, right?) Also, you avoid to respond to one very important question: how many working days in this year have you respected the agreed SLA and how many working days you failed to respect it. I am sure you already have this number and can provide it _today_. Elvis PS: I have yet to see a ticket handled within the SLA for months, still hope this will change swiftly and not months/quarters from now On Tue, Sep 7, 2021 at 08:11 Felipe Victolla Silveira <fvictolla@ripe.net> wrote:
Dear Gert, Elvis,
First, let me recognise that the ticketing system has been a sore point for a number of years and we have made little progress in addressing the issues that you and others have raised. We are not overly proud of our record here.
In the next few weeks, we plan to publish roadmaps with our plans for the next quarter[1]. We will make sure the ticketing system is covered here.
Given there are other areas which may need priority, I can't promise that you will be completely satisfied by what we propose in terms of the ticketing system. However, having public roadmaps should help to inform discussions about what we focus on and where trade-offs need to be made. Publishing more detail about our plans and tracking feedback or changes should also make it easier to hold us to account when we fail to deliver.
So, if you can bear with us a little longer, once this is ready we can continue the discussion on this list, using these roadmaps as a starting point.
Kind regards, Felipe
[1] Using our recent RPKI roadmap as a model:
https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-plann...
On 6 Sep 2021, at 18:07, Gert Doering <gert@space.net> wrote:
Hi,
On Mon, Aug 30, 2021 at 09:06:54PM -0700, Elvis Daniel Velea wrote:
PS: Note that I wanted to also send an e-mail about the RIPE NCC's ticketing system (zendesk) to the members-discuss mailing list and to the board members. I will wait for an answer to the e-mail I sent to HPH one week ago (which he promised he'll forward to the relevant team for a reply).
The ticket system from hell.
I'm looking forward to read the issues *you* have with it.
My complaints have been delivered to Felipe in person, years ago, and been summarily ignored. As far as I can see.
But that might be better suited in its own thread, and in ncc-services.
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/rsstaff%40ripe.net
-- This message was sent from a mobile device. Some typos may be possible.

Elvis, We have received your messages and registered your dissatisfaction. We will provide statistics when we can but the priority here is to address the issue with waiting times so our members can proceed with their own operations. Solving this issue is what we will focus on rather than having staff resources diverted to provide statistics. We work to serve all of our members and that is what our efforts here will be guided by. Wait times per member request are determined by a number of factors and where additional checks are required, the request will take longer. And while some requests take longer to process than others, our staff need to apply all necessary due diligence measures rather than rely on assertions from the member involved. This is how we maintain a robust registry of member resources. In your mails, you indicate excellent knowledge of what is involved in processing member requests. I can assure you that the nature of the work involved is of a completely different order to when you worked here. Our staff are working extremely hard to meet all the requirements involved in processing requests under these circumstances and I reject any implication otherwise. We will report further on this issue in due course, providing relevant data, once we have resolved the core problem. I reported on these figures at the NCC Services Working Group at the last RIPE Meeting[1] and I plan to do so again at RIPE 83. We will also look at ways to provide this information on our website providing all the necessary context. Regards, Felipe [1] https://ripe82.ripe.net/archives/video/584/ <https://ripe82.ripe.net/archives/video/584/>
On 14 Sep 2021, at 12:59, Elvis Daniel Velea <elvis@v4escrow.net> wrote:
Dear Felipe,
while we wait for you to crop up a roadmap, I am still waiting for the statistics I asked from Marco weeks ago.
Marco, I’d like to see real numbers and not just .. this Q we handled x% more tickets than last Q. Usually when statistics are presented this way, without backing numbers, they express a story you want us to see and not the whole picture.
So, while Felipe works on the roadmap, please send us the statistics that you already have about number of tickets handled daily, number of FTEs working on those tickets daily and make sure we receive these numbers for at least since you stopped showing this information transparently (circa 2015). I hope you can provide these numbers swiftly and it won’t take weeks to provide them but rather days (you’ve been working on these stats/numbers since my initial e-mail requesting them, right?)
Also, you avoid to respond to one very important question: how many working days in this year have you respected the agreed SLA and how many working days you failed to respect it. I am sure you already have this number and can provide it _today_.
Elvis
PS: I have yet to see a ticket handled within the SLA for months, still hope this will change swiftly and not months/quarters from now
On Tue, Sep 7, 2021 at 08:11 Felipe Victolla Silveira <fvictolla@ripe.net <mailto:fvictolla@ripe.net>> wrote: Dear Gert, Elvis,
First, let me recognise that the ticketing system has been a sore point for a number of years and we have made little progress in addressing the issues that you and others have raised. We are not overly proud of our record here.
In the next few weeks, we plan to publish roadmaps with our plans for the next quarter[1]. We will make sure the ticketing system is covered here.
Given there are other areas which may need priority, I can't promise that you will be completely satisfied by what we propose in terms of the ticketing system. However, having public roadmaps should help to inform discussions about what we focus on and where trade-offs need to be made. Publishing more detail about our plans and tracking feedback or changes should also make it easier to hold us to account when we fail to deliver.
So, if you can bear with us a little longer, once this is ready we can continue the discussion on this list, using these roadmaps as a starting point.
Kind regards, Felipe
[1] Using our recent RPKI roadmap as a model: https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-plann... <https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-planning-and-roadmap>
On 6 Sep 2021, at 18:07, Gert Doering <gert@space.net <mailto:gert@space.net>> wrote:
Hi,
On Mon, Aug 30, 2021 at 09:06:54PM -0700, Elvis Daniel Velea wrote:
PS: Note that I wanted to also send an e-mail about the RIPE NCC's ticketing system (zendesk) to the members-discuss mailing list and to the board members. I will wait for an answer to the e-mail I sent to HPH one week ago (which he promised he'll forward to the relevant team for a reply).
The ticket system from hell.
I'm looking forward to read the issues *you* have with it.
My complaints have been delivered to Felipe in person, years ago, and been summarily ignored. As far as I can see.
But that might be better suited in its own thread, and in ncc-services.
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
_______________________________________________ members-discuss mailing list members-discuss@ripe.net <mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss <https://lists.ripe.net/mailman/listinfo/members-discuss> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/rsstaff%40ripe.net <https://lists.ripe.net/mailman/options/members-discuss/rsstaff%40ripe.net>
-- This message was sent from a mobile device. Some typos may be possible.

Hi Felipe, On 9/17/21 3:01 AM, Felipe Victolla Silveira wrote:
Elvis,
We have received your messages and registered your dissatisfaction.
okay.
We will provide statistics when we can but the priority here is to
That's not acceptable. "When we can" is not a good answer, not when you have these numbers already. It's been three weeks already!
address the issue with waiting times so our members can proceed with their own operations. Solving this issue is what we will focus on rather than having staff resources diverted to provide statistics. We work to serve all of our members and that is what our efforts here will be guided by.
I am sure you already have all these numbers. How could you monitor the department's efficacy otherwise? You actually provided the numbers for the first 3 months of this year during the RIPE82 meeting. All I am asking is that you provide the same but for a longer period. All I've asked is a simple question. For the past few years, how many days in a month has RS failed to honor the SLA and how many days has it actually replied to all tickets within the SLA? Also, for comparison reasons, how many tickets were replied to, monthly, in the past few years? I found your slide 7 in the RIPE82 presentation and that shows you close 3k-6k tickets per month. Is that the right number? If you fail the SLA for up to 1000 tickets per month, why is this not raising a lot of alarm bells everywhere? I am only asking these questions because at 6k tickets per month (which is about the maximum I see from your partial statistics) it means that RS closes less than 300 tickets per day and if only an average of 75% of the department is working on tickets only an average of 10 tickets are closed per FTE per day. That's quite a low number. (I used this page ** to see how many FTEs are in RS, hope this is correct info, if the trainees are not included in the page, then the number are even worse) Also, you use the excuse for Q4 warning that you have hired a lot of new people, that was the same excuse for Q1, why will you have a really bad service in Q4 (as advertised by Marco's e-mail in early August) if you have already hired a bunch of people 6+ months ago. How much does training take? I know.. I asked for a lot of data, I understand that the whole team is working continuously to answer members' requests and I agree that they should focus on replying to LIRs instead of collecting statistics for me. However, instead of sending long e-mail replies, you may want to just reply to a couple of simple questions for which you already have the data. Your refusal to do that for weeks is unheard of. I have never before seen an NCC representative refuse to provide a number a member has asked for, especially a number that I know you have easily available and you are probably looking at weekly. Felipe, I'll keep e-mailing you, Marco, the Board and this list weekly until you DO provide the answer to the simple question "over the past few years, since you stopped showing this information transparently, how many working days per month/year have you failed to honor the SLA and what's the percentage of the failures (# of tickets) out of the total # of tickets?"
Wait times per member request are determined by a number of factors and where additional checks are required, the request will take longer. And while some requests take longer to process than others, our staff need to apply all necessary due diligence measures rather than rely on assertions from the member involved. This is how we maintain a robust registry of member resources.
Again, this is in line with your strategy change from 'we trust our members fully with the data they provide' to 'we suspect all our members are now committing fraud and we must protect their resources'. This change has been gradual but the level of the mistrust I see now is alarming. Maybe you should focus on passing the responsibility of keeping an SSO account secure to the LIRs and stop questioning the validity/legality of the information provided by the LIRs to the RIPE NCC. If someone provides illegal/falsified documentation you always have the option to revert the change you've made once a court has decided against your initial decision. You should not waste so much time of the RS department on manually verifying whether an ID is valid or whether a signature is similar to one you have on record. I applaud the attempts to automate some of these processes, finally something good happening regarding this. Although I am afraid that this change may add even more bureaucracy and push the blame for the failure of RS to the third party. Do these third parties have any SLA? Have you tested their services? How fast do they move? As for the sanctions, Marco has been using this excuse for a few years now, every time I called the NCC and asked for a manager because a ticket was not handled in time or correctly, this was one of the excuses. I don't understand why you can't have this check done faster, maybe when a company registers as a member or as an annual/monthly automated check. Why delay all transfer tickets for a process that could be done automatically? You already use DUNS data about all companies, you already do background checks.. why not do them automatically and only do manual work where the data is not easily accessible? I thought the NCC was not interested in politics and will support anyone that needs to connect to the internet. Is a monopoly in IP addresses and AS Numbers now going to censure individuals or companies from the internet? Laws come and go, sanctions are added and removed constantly, why are you joining this political game now?
In your mails, you indicate excellent knowledge of what is involved in processing member requests. I can assure you that the nature of the work involved is of a completely different order to when you worked here. Our staff are working extremely hard to meet all the requirements involved in processing requests under these circumstances and I reject any implication otherwise.
That was a reply I sent to another member that was complaining about your services. It was actually in your defense that I replied to them saying that the reason my ticket was resolved before theirs was because my ticket only needed an evaluation of a few documents (that I strive to make sure they are complete and correct) and approval. I am not sure what other 'implication' you have seen in my replies, please clarify. As replied to Marco separately, please send my apologies to the RS team, my former colleagues, my words were never meant to demoralize them. My words are a statement on the POOR job of the department’s current management and their constant failure to fix issues reported for years. This is not something coming out of the blue. I have been taking to RS management over the past 2-3 years reporting these issues constantly. Felipe - you say in the presentation here (*) that you have changed the way you calculate the % of the tickets responded withing one day and that is why you were only able to provide the data for 3 months of 2021. Please explain clearly what exactly has changed because, as far as I can see, the calculation of the failures to respect the SLA is the same today as it was 10 years ago. And if nothing has changed, why did you say it changed? Was it because 2020 was a disaster? Why not show the numbers of Q4 2020 when you clearly had those? Felipe, providing just the information that looks not so bad (even though the information provided was really bad as well) looks like a tactic to misrepresent the efficacy of the department you run. Please provide the numbers for 2020 to prove me wrong. Also, please stop the tactic of providing only the numbers you want to show. Provide complete information next time so we can really understand what's going on. I am not implying anything, I am accusing you of providing partial data that looks better. Just like the RIPE NCC refuses to show Israel (but shows Palestine) in the Menog stats ***, politics I've never understood. I actually hope a reply from the Board will come sometime soon, they have failed to supervise the RS management and penalize the failures to respect the SLA for more than a couple of years already :( Felipe, Marco.. had I had ONE ticket answered withing the SLA in the past Q (probably year), I might have been easier on you. But there hasn't been even one ticket replied to within SLA and that is unacceptable. * https://ripe82.ripe.net/archives/video/584/ ** https://www.ripe.net/about-us/staff/structure/the-registry/registry-services *** https://www.menog.org/presentations/menog-19/493-IPv4runout-Presentation-MEN... (slides 23,24) https://www.menog.org/presentations/menog-19/485-RIPE_NCC_Update_2019_MENOG.... (slides 5, 6, 7, 8, 10, 24) https://www.menog.org/meetings/previous/ (look at all the RIPE NCC presentations over the years) Kind regards, Elvis
Regards, Felipe
[1] https://ripe82.ripe.net/archives/video/584/ <https://ripe82.ripe.net/archives/video/584/>
On 14 Sep 2021, at 12:59, Elvis Daniel Velea <elvis@v4escrow.net <mailto:elvis@v4escrow.net>> wrote:
Dear Felipe,
while we wait for you to crop up a roadmap, I am still waiting for the statistics I asked from Marco weeks ago.
Marco, I’d like to see real numbers and not just .. this Q we handled x% more tickets than last Q. Usually when statistics are presented this way, without backing numbers, they express a story you want us to see and not the whole picture.
So, while Felipe works on the roadmap, please send us the statistics that you already have about number of tickets handled daily, number of FTEs working on those tickets daily and make sure we receive these numbers for at least since you stopped showing this information transparently (circa 2015). I hope you can provide these numbers swiftly and it won’t take weeks to provide them but rather days (you’ve been working on these stats/numbers since my initial e-mail requesting them, right?)
Also, you avoid to respond to one very important question: how many working days in this year have you respected the agreed SLA and how many working days you failed to respect it. I am sure you already have this number and can provide it _today_.
Elvis
PS: I have yet to see a ticket handled within the SLA for months, still hope this will change swiftly and not months/quarters from now
On Tue, Sep 7, 2021 at 08:11 Felipe Victolla Silveira <fvictolla@ripe.net <mailto:fvictolla@ripe.net>> wrote:
Dear Gert, Elvis,
First, let me recognise that the ticketing system has been a sore point for a number of years and we have made little progress in addressing the issues that you and others have raised. We are not overly proud of our record here.
In the next few weeks, we plan to publish roadmaps with our plans for the next quarter[1]. We will make sure the ticketing system is covered here.
Given there are other areas which may need priority, I can't promise that you will be completely satisfied by what we propose in terms of the ticketing system. However, having public roadmaps should help to inform discussions about what we focus on and where trade-offs need to be made. Publishing more detail about our plans and tracking feedback or changes should also make it easier to hold us to account when we fail to deliver.
So, if you can bear with us a little longer, once this is ready we can continue the discussion on this list, using these roadmaps as a starting point.
Kind regards, Felipe
[1] Using our recent RPKI roadmap as a model: https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-plann... <https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-planning-and-roadmap>
On 6 Sep 2021, at 18:07, Gert Doering <gert@space.net <mailto:gert@space.net>> wrote:
Hi,
On Mon, Aug 30, 2021 at 09:06:54PM -0700, Elvis Daniel Velea wrote:
PS: Note that I wanted to also send an e-mail about the RIPE NCC's ticketing system (zendesk) to the members-discuss mailing list and to the board members. I will wait for an answer to the e-mail I sent to HPH one week ago (which he promised he'll forward to the relevant team for a reply).
The ticket system from hell.
I'm looking forward to read the issues *you* have with it.
My complaints have been delivered to Felipe in person, years ago, and been summarily ignored. As far as I can see.
But that might be better suited in its own thread, and in ncc-services.
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 _______________________________________________ members-discuss mailing list members-discuss@ripe.net <mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss <https://lists.ripe.net/mailman/listinfo/members-discuss> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/rsstaff%40ripe.net <https://lists.ripe.net/mailman/options/members-discuss/rsstaff%40ripe.net>
-- This message was sent from a mobile device. Some typos may be possible.
-- Kind regards, Elvis Daniel Velea Chief Executive Officer V4Escrow LLC elvis@v4escrow.net +1-702-970-0921

Elvis,
On 20 Sep 2021, at 06:00, Elvis Daniel Velea <elvis@v4escrow.net> wrote:
Wait times per member request are determined by a number of factors and where additional checks are required, the request will take longer. And while some requests take longer to process than others, our staff need to apply all necessary due diligence measures rather than rely on assertions from the member involved. This is how we maintain a robust registry of member resources.
Again, this is in line with your strategy change from 'we trust our members fully with the data they provide' to 'we suspect all our members are now committing fraud and we must protect their resources'. This change has been gradual but the level of the mistrust I see now is alarming. Maybe you should focus on passing the responsibility of keeping an SSO account secure to the LIRs and stop questioning the validity/legality of the information provided by the LIRs to the RIPE NCC.
If someone provides illegal/falsified documentation you always have the option to revert the change you've made once a court has decided against your initial decision. You should not waste so much time of the RS department on manually verifying whether an ID is valid or whether a signature is similar to one you have on record.
I just wanted to pick up on this as I don’t agree at all. For a number of resons such as RPKI and increased value of resources, the importance of ensuring correct ownership and identification of the ultimate holder has gone up over time. As we have seen in other regions using courts to settle disputes afterwards can come at high cost and risk and will simply shift the workload of the NCC staff but more importantly might well be pointless if for example criminal activity has been enabled under a validated prefix until rectified by the courts. OF course the processes needs to be streamlined and automated as far as possible but let’s not pretend that loose or no validation of prefixes as in the old days is an option today. It isn’t. That will drive complexity and cost and we should discuss how to make that less impactful instead of how to abolish it. - kurtis -

Hi Kurtis, On 9/19/21 11:44 PM, Kurtis Lindqvist wrote:
Elvis,
On 20 Sep 2021, at 06:00, Elvis Daniel Velea <elvis@v4escrow.net> wrote:
Wait times per member request are determined by a number of factors and where additional checks are required, the request will take longer. And while some requests take longer to process than others, our staff need to apply all necessary due diligence measures rather than rely on assertions from the member involved. This is how we maintain a robust registry of member resources.
Again, this is in line with your strategy change from 'we trust our members fully with the data they provide' to 'we suspect all our members are now committing fraud and we must protect their resources'. This change has been gradual but the level of the mistrust I see now is alarming. Maybe you should focus on passing the responsibility of keeping an SSO account secure to the LIRs and stop questioning the validity/legality of the information provided by the LIRs to the RIPE NCC.
If someone provides illegal/falsified documentation you always have the option to revert the change you've made once a court has decided against your initial decision. You should not waste so much time of the RS department on manually verifying whether an ID is valid or whether a signature is similar to one you have on record.
I just wanted to pick up on this as I don’t agree at all. For a number of resons such as RPKI and increased value of resources, the importance of ensuring correct ownership and identification of the ultimate holder has gone up over time. As we have seen in other regions using courts to settle disputes afterwards can come at high cost and risk and will simply shift the workload of the NCC staff but more importantly might well be pointless if for example criminal activity has been enabled under a validated prefix until rectified by the courts.
OF course the processes needs to be streamlined and automated as far as possible but let’s not pretend that loose or no validation of prefixes as in the old days is an option today. It isn’t. That will drive complexity and cost and we should discuss how to make that less impactful instead of how to abolish it.
Maybe I over-simplified what I said and it came out wrong. I am not pro abolishing the fraud investigations, all I am wondering is whether the NCC's approach to do all these checks was a good idea. What I meant to say was that all members should understand that what they hold in their accounts are numbers that have a high value and therefore they should do everything they can to secure their accounts because there are fraudsters out there trying to hack into their accounts to steal their prized assets. It should not be the RIPE NCC wasting time to make sure that they have received the information from the right contact, that the account holder (SSO) of the company X transferring IPv4 addresses has not been hacked or that the requester may be a fraudster. It should not be the NCC's job to police, for example, a weak password of an SSO holder or to verify that the document they have received from a trusted contact is signed by the same person that has signed the SSO years ago. They can't as they do not have the skills to do that, all they can do is delay every request and waste time that should be more usefully used to process all the requests within the SLA. How can someone be sure that an ink signature is not fake always amazes me, there are highly skilled individuals that authenticate autographs that have done this for a life and can still make mistakes.. Why has the NCC gone this route with 30+ people, none with the right skills or training to do this? - I applaud the attempted changes in automation the NCC is trying to make by using iDenfy in the future.. I am not sure this was needed, though, but I am not there to see all the fraud attempts the NCC deals with. The owners of the LIR accounts should be responsible for their own passwords/authentication methods and who they give access to the resources to. They should also be responsible for the documentation provided by their company to the RIPE NCC and acknowledge that the NCC may refer cases to LEAs/justice when they have reasons to believe this information/documentation is fake. So, to summarize, I don't believe the NCC should have gone the route of doubting the documentation received every time a request is sent but should have instead trusted in the documentation provided by the LIRs. In cases where LIRs or end-users provide fake documentation, it is not the NCC that can really judge that but a court. The NCC does not have the skills for this and should not continue to go this route. Elvis -- Kind regards, Elvis Daniel Velea Chief Executive Officer V4Escrow LLC www.v4escrow.com elvis@v4escrow.net +1-702-970-0921

Hi Elvis!
On 21 Sep 2021, at 00:55, Elvis Daniel Velea <elvis@v4escrow.net> wrote:
What I meant to say was that all members should understand that what they hold in their accounts are numbers that have a high value and therefore they should do everything they can to secure their accounts because there are fraudsters out there trying to hack into their accounts to steal their prized assets.
It should not be the RIPE NCC wasting time to make sure that they have received the information from the right contact, that the account holder (SSO) of the company X transferring IPv4 addresses has not been hacked or that the requester may be a fraudster. It should not be the NCC's job to police, for example, a weak password of an SSO holder or to verify that the document they have received from a trusted contact is signed by the same person that has signed the SSO years ago. They can't as they do not have the skills to do that, all they can do is delay every request and waste time that should be more usefully used to process all the requests within the SLA.
How can someone be sure that an ink signature is not fake always amazes me, there are highly skilled individuals that authenticate autographs that have done this for a life and can still make mistakes.. Why has the NCC gone this route with 30+ people, none with the right skills or training to do this?
- I applaud the attempted changes in automation the NCC is trying to make by using iDenfy in the future.. I am not sure this was needed, though, but I am not there to see all the fraud attempts the NCC deals with.
The owners of the LIR accounts should be responsible for their own passwords/authentication methods and who they give access to the resources to. They should also be responsible for the documentation provided by their company to the RIPE NCC and acknowledge that the NCC may refer cases to LEAs/justice when they have reasons to believe this information/documentation is fake.
You are making the assumption that there are no undisputed resources at the moment, that there is a clear ownership for every single resource, that “password hacking” is the only way to claim or steal resources etc. Neither of these are true. There are plenty of disputed resources, many other ways to steal or claim resources. Disputes will arise as a result of company mergers, splits or defaults. Miscreants can claim ROAs for resources with loose controls or ownership structures. As a community we should all want the NCC to ensure we are protected from this as these all put us at risk. You seem to focus on the easy of the transfer market only but the that is not the NCCs goal, far from it. NCC has other, and in my view much more important objectives they need to fulfil to protect us all. To do this they need to uphold processes that might impact the speed of the transfer market, but I personally think that is a price worth paying for a robust system and community trust. That said, the checks should be streamlined and effective, but not compromise the integrity of the data. - kurtis -

Hi Kurtis, On Wed, Sep 22, 2021 at 01:48 Kurtis Lindqvist <kurtis@linx.net> wrote:
Hi Elvis!
On 21 Sep 2021, at 00:55, Elvis Daniel Velea <elvis@v4escrow.net> wrote:
What I meant to say was that all members should understand that what they hold in their accounts are numbers that have a high value and therefore they should do everything they can to secure their accounts because there are fraudsters out there trying to hack into their accounts to steal their prized assets.
[…]
How can someone be sure that an ink signature is not fake always amazes me, there are highly skilled individuals that authenticate autographs that have done this for a life and can still make mistakes.. Why has the NCC gone this route with 30+ people, none with the right skills or training to do this?
[…]
The owners of the LIR accounts should be responsible for their own passwords/authentication methods and who they give access to the resources to. They should also be responsible for the documentation provided by their company to the RIPE NCC and acknowledge that the NCC may refer cases to LEAs/justice when they have reasons to believe this information/documentation is fake.
You are making the assumption that there are no undisputed resources at the moment, that there is a clear ownership for every single resource, that “password hacking” is the only way to claim or steal resources etc. Neither of these are true.
No, I am not making this assumption. What I am saying is that the NCC is basing the security of those resources and the ‘holdership’ of a resource based on the SSO owner and the documents they receive from him/her. They evaluate these documents by comparing them visually, but they don’t really have any real training in identifying a fake signature, they can suspect it, maybe. The NCC RS dept. has never had people specialized in identifying fake documentation. It is very hard to identify abuse or faked documentation considering the large service region it covers. Deregistering resources or refusing services based on suspicion is just an invitation to the NCC being sued and losing more time in a court than evaluating requests. All the NCC is basing its decisions on is that by catching the bad guys those will not have the knowledge or willingness to take it to court. That is why it is very important that the NCC focuses it’s effort in ensuring the members have secure access to the LIR Portal and the tools available. Ever wondered why we have only heard of a handful of deregistrations in almost 30 years? Why the NCC has rarely gone (or been taken) to court? It’s because it is not their job to prove fraud and even when they do, the NCC should first report it to LEAs and let them investigate.
There are plenty of disputed resources, many other ways to steal or claim resources. Disputes will arise as a result of company mergers, splits or defaults.
Again, everything is reduced to an SSO holder which the NCC talks to. All other cases need to resolve by mediation or court decisions. I believe that because as IP Broker I’ve had customers with all kind of weird mergers or splits and have seen how complicated some of these are. In the end, what’s registered is hard to be changed or deregistered even with enough proof in hand. And when it comes to legacy blocks, the NCC rarely does anything, especially when the original resource holder does not know of the hijack or does not even exist any longer so they can’t report it. I know that for a fact as I’ve previously reported at least one hijack of a large block and they have not been able to investigate or revert any changes made by what I believed to be hijackers.
Miscreants can claim ROAs for resources with loose controls or ownership structures. As a community we should all want the NCC to ensure we are protected from this as these all put us at risk.
Only if they have access to the SSO which in turn has access to the LIR Portal account. I doubt the NCC have the training to really provide this ‘protection’. Some cases may be blatantly fraudulent (like when the NCC received a copy of an ID foe John Doe with Cher’s picture on) but even then, deregistering a resource should be done very carefully.
You seem to focus on the easy of the transfer market only but the that is not the NCCs goal, far from it. NCC has other, and in my view much more important objectives they need to fulfil to protect us all. To do this they need to uphold processes that might impact the speed of the transfer market, but I personally think that is a price worth paying for a robust system and community trust. That said, the checks should be streamlined and effective, but not compromise the integrity of the data.
I am not talking only about transfers here. ALL tickets are delayed, even those where people just want to open an LIR. You see that I’m an IPv4 Broker an guess that’s my only concern. That’s not correct and you are wrong here to make that assumption. The Registration Services department is failing to reply within the agreed SLA and some tickets take months to resolve (see Felipe’s presentation showing that there are over 100-150 tickets opened monthly that take more than 8 weeks or/and 10 replies to be resolved, at least 1/3rd of these are improvable so something is wrong with some of the processes or communication, see slide 7 *) Since the Customer Services Department has been merged with the Registration Services Department, it is now one big department, the only department communicating with the members. RS is the link between the NCC and the membership, they have a clear SLA which they fail to respect almost daily, for years now.. that is my concern. It’s even worse that in early August we received a message saying ‘we’ll do even worse before we improve’. I am not asking for any compromise or anything that would compromise the accuracy of the registry. I am asking for a review of the processes and of the reason the delay in processing request is getting worse because, it is my opinion, the RS management has recently made some poor decisions in creating/modifying processes for sanctions checks and anti-fraud checks that delay almost all the tickets processed by that department and miss the SLA daily. I have also been asking for a clear picture of the number of days the SLA has been violated, the NCC is still refusing to provide that number. * https://ripe82.ripe.net/archives/video/584/ -- Kind regards, Elvis Daniel Velea Chief Executive Officer V4Escrow LLC www.v4escrow.com elvis@v4escrow.net +1-702-970-0921
- kurtis -
-- This message was sent from a mobile device. Some typos may be possible.

On 22 Sep 2021, at 11:58, Elvis Daniel Velea <elvis@v4escrow.net> wrote:
No, I am not making this assumption. What I am saying is that the NCC is basing the security of those resources and the ‘holdership’ of a resource based on the SSO owner and the documents they receive from him/her. They evaluate these documents by comparing them visually, but they don’t really have any real training in identifying a fake signature, they can suspect it, maybe. The NCC RS dept. has never had people specialized in identifying fake documentation. It is very hard to identify abuse or faked documentation considering the large service region it covers. Deregistering resources or refusing services based on suspicion is just an invitation to the NCC being sued and losing more time in a court than evaluating requests. All the NCC is basing its decisions on is that by catching the bad guys those will not have the knowledge or willingness to take it to court. That is why it is very important that the NCC focuses it’s effort in ensuring the members have secure access to the LIR Portal and the tools available.
Ever wondered why we have only heard of a handful of deregistrations in almost 30 years? Why the NCC has rarely gone (or been taken) to court? It’s because it is not their job to prove fraud and even when they do, the NCC should first report it to LEAs and let them investigate.
I don’t have insight into what checks or processes the NCC follows, but in most internal audits and audits this is not just based on signature verification but on cross referencing documents and historical records so not sure to what extent just a signature is really at play.
You seem to focus on the easy of the transfer market only but the that is not the NCCs goal, far from it. NCC has other, and in my view much more important objectives they need to fulfil to protect us all. To do this they need to uphold processes that might impact the speed of the transfer market, but I personally think that is a price worth paying for a robust system and community trust. That said, the checks should be streamlined and effective, but not compromise the integrity of the data.
I am not talking only about transfers here. ALL tickets are delayed, even those where people just want to open an LIR. You see that I’m an IPv4 Broker an guess that’s my only concern. That’s not correct and you are wrong here to make that assumption. The Registration Services department is failing to reply within the agreed SLA and some tickets take months to resolve (see Felipe’s presentation showing that there are over 100-150 tickets opened monthly that take more than 8 weeks or/and 10 replies to be resolved, at least 1/3rd of these are improvable so something is wrong with some of the processes or communication, see slide 7 *)
I wasn’t referring to the time of ticket resolution, but to the process. I absolutely agree that the SLAs should be met. I wanted to separate the discussion of what process checks the NCC does and make sure this is as robust as possible and not eroded because of a wish of speedy ticket resolutions or a desire to meet the SLA.
I am not asking for any compromise or anything that would compromise the accuracy of the registry.
Good that we could clarify that! - kurtis -

Hi, On Wed, Sep 22, 2021 at 08:48:13AM +0000, Kurtis Lindqvist wrote:
You seem to focus on the easy of the transfer market only but the that is not the NCCs goal, far from it. NCC has other, and in my view much more important objectives they need to fulfil to protect us all. To do this they need to uphold processes that might impact the speed of the transfer market, but I personally think that is a price worth paying for a robust system and community trust. That said, the checks should be streamlined and effective, but not compromise the integrity of the data.
I totally agree with the requirement for a strong and correct registry. Nonetheless, RS response times for really simple things ("I want an IPv6 network, for an established LIR, no doubts on identity") have also not been exactly SLA compliant - "holding up all the easy requests because there are concurrent complicated ones" is not making happy customers. This comes down to management priorities... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

On 23 Sep 2021, at 08:32, Gert Doering <gert@space.net> wrote:
On Wed, Sep 22, 2021 at 08:48:13AM +0000, Kurtis Lindqvist wrote:
You seem to focus on the easy of the transfer market only but the that is not the NCCs goal, far from it. NCC has other, and in my view much more important objectives they need to fulfil to protect us all. To do this they need to uphold processes that might impact the speed of the transfer market, but I personally think that is a price worth paying for a robust system and community trust. That said, the checks should be streamlined and effective, but not compromise the integrity of the data.
I totally agree with the requirement for a strong and correct registry.
Nonetheless, RS response times for really simple things ("I want an IPv6 network, for an established LIR, no doubts on identity") have also not been exactly SLA compliant - "holding up all the easy requests because there are concurrent complicated ones" is not making happy customers.
This comes down to management priorities…
Obviously the SLA should be met, but I deliberately left that out of my comment as I wanted to focus on not eroding the stringent controls. - kurtis -

Hi, On Thu, Sep 23, 2021 at 07:35:25AM +0000, Kurtis Lindqvist wrote:
Obviously the SLA should be met, but I deliberately left that out of my comment as I wanted to focus on not eroding the stringent controls.
But that was sort of my point - if we have different classes of tickets - I want an IPv6 allocation for my pre-existing LIR - my atlas probe is being reported incorrectly in the LIR portal - I want to transfer this IPv4 /10 which has a less-than-clear history to a less-than-well-known LIR in a faraway region I can easily understand that some of them might take months to solve, but right now *all* of them take way too long to get anywhere. Plus, stupid ticket system ("reply to an already-closed ticket because 'no that atlas thing is *not* fixed' and you get a new ticket, a new ticket handler, and get to start from zero..."). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
participants (4)
-
Elvis Daniel Velea
-
Felipe Victolla Silveira
-
Gert Doering
-
Kurtis Lindqvist