3rd Community Review of 1475 EFil+ Allocator

[1475Notary]

First Review #57
Second Review #143

Allocator Compliance Report: https://compliance.allocator.tech/report/f03018491/1728695297/report.md

5PiBs DataCap awarded in 3rd round

example 1: 1475Notary/1475-Allocator#14 - 1.75PiB

After Q&A with the client and confirmation of their identity, we allocate datacap to the client. Before the second round of allocation, we reviewed the client's cid report and confirmed that the results were good, so we decided to allocate a new round. By the third round of allocations, we noticed that the retrieval success rate had reduced in their latest cid report. After discussing with the client we decided to allocate a new round to the client to observe their improvement. (We asked the client to add a note on their application. 1475Notary/1475-Allocator#14 (comment))

example 2: 1475Notary/1475-Allocator#12 - 1.5PiB

After Q&A with the client and confirmation of their identity, we allocate datacap to the client. Before the second round of allocation, we saw their improvement in the client's cid report, so we decided to allocate a new round. By the third round of allocations, we noticed that the retrieval success rate had reduced in their latest cid report. After discussing with the client we decided to allocate a new round to the client to observe their improvement. (We asked the client to add a note on their application. 1475Notary/1475-Allocator#12 (comment) The client has stopped working with sps who provided low retrieval success rate.)

example 3: 1475Notary/1475-Allocator#19 - 1.75PiB

After Q&A with the client and confirmation of their identity, we allocate datacap to the client.

Before the second round of allocation, we found that the retrieval success rate is low in cid report. Due to client just added some sps into their team, we decided to allocate new round to observe the next process. 1475Notary/1475-Allocator#19 (comment) Before the third round of allocations, we saw their improvement in the client's cid report, so we decided to allocate a new round. (We asked the client to add a note on their application. 1475Notary/1475-Allocator#19 (comment))

[filecoin-watchdog]

@1475Notary
Allocator Application
Compliance Report
1st Review
2nd Review

1st Review score: 2.5PiB granted
2nd Review score: 5PiB granted

3.75 PiB granted to existing clients:

Existing Client Name	DC
NOAA	2 PiB
ChildMind Institute	1.75 PiB

1.75 PiB granted to new clients:

New Client Name	DC
NationalCenter For Atmospheric Research	1.75 PiB

Example 1
1.75 PiB DC granted
—
This dataset was already stored several times(FIL-A-2,top value storage,filecoin-plus-large-datasets)

SPs list updated in the issue:
f03100008 Guangdong
f03100009 HongKong
f03030649 Hebei
f01660795 Guangdong
f01084413 Zhejiang

SPs list used for deals:
f03100008
f03100009
f03216485
f03030649
f01660795
f01084413
f03157879
f03161261
f03159626
f03224828
f03189917
f02825282

All 5 SPs updated in the issue consist of SPs list used for deals, yet 7 additional SPs were never mentioned (neither in the form nor updated later).
Retrieval looks rather good. 5 SPs has low retrieval rate.

The client declared 10 replicas, but there are 12 already.

Example 2
2 PiB DC granted
—
This dataset was stored many times. NOAA often appears as a dataset in applications, so you need to pay special attention to applications that use these datasets. Below is a link to search just for this dataset. There are 2 search results. https://github.com/search?q=repo%3Afilecoin-project%2Ffilecoin-plus-large-datasets+noaa-ofs-pds&type=issues
With allocator.tech, you can find applications open on 12 other allocators by typing in NOAA's name. Did the allocator ensure that sending more copies of the dataset would be valuable for the network?

The client declared 10 replicas, but there are 11 already.

Example 3
1.75 PiB DC granted
—
SPs list updated in the issue:
f03100008 Shenzhen
f01084413 Ningbo
f03214920 Hong Kong
f03161261 New York
f03192503 Hong Kong
f03189917 Dulles
f03156722 Hong Kong

SPs list used for deals:
f03100008
f03100009
f01084941
f03100002
f0114153
f01084413
f03214920
f03161261
f03192503
f03189917
f03156722

The client did not use any of the SPs listed in the form. The client's comment appeared in the thread with an update of the SP list, which included 7 SP IDs (all were used for deals). The list of SPs with which deals were made contains 11 addresses. The client did not update the additional 4 addresses used for deals. Did the allocator know about this change?

The second CID report showed a lot of irregularities, including low retrieval rate, but the allocator commented on it as "good job". Why such a conclusion after seeing a report with a retrieval rate of 8.9% on average, with SPs of unknown location and 2 out of 7 SPs that sealed over 25% of data?

Also, this dataset seems to be already stored many times on filecoin. Has the Allocator talked about this with the client?

---

In general, the allocator tries to keep an eye on its customers, performs KYC (however, this is a method outside of kyc.allocator.tech, gov team may ask additional questions here). The allocator should pay more attention to the application details and check if datasets are not stored on filecoin already. If this is the case, additional questions should be asked.

[1475Notary]

Hello @filecoin-watchdog

Example 1
We used to remind our clients to keep their sp updated.

The client has updated the new sp twice.
1475Notary/1475-Allocator#14 (comment)
1475Notary/1475-Allocator#14 (comment)
We support our clients in distributing data to a number of sps as they described in the application. We noticed that the reason clients store in more sps than the number in their application is that they replaced sps with low retrieval rates.
Next we will also push our clients to provide updated lists when necessary.

Example 2
Thanks for the helpful tips!
I had a look at this dataset and got the result https://github.com/search?q=repo%3Afilecoin-project%2Ffilecoin-plus-large-datasets+s3%3A%2F%2Ffcp-indi%2F&type= issues
Those past applicants that I saw didn't start storing this dataset. Nevertheless, we will follow up with improved selection of data stored by the applicants, and your method can be very helpful in doing so.
On the question of replicas, the client said that they had stopped working with sps who did not give a good retrieval success rate. 1475Notary/1475-Allocator#12 (comment)
But the sps that have worked with them in the past still show up in the report.

Example 3

The client has disclosed full of sps to me as follows.
1475Notary/1475-Allocator#19 (comment)
1475Notary/1475-Allocator#19 (comment)
The location of that sp I looked up via filfox, I don't know why the ip didn't show up in the report.

I saw the client's efforts to improve the retrieval success rate, which they were dealing with positively, and in short time, they increased the retrieval success rate. I hope the client continues to make progress like this.

report in 9.28

report in 10.4

In my view, it seems that most of the applicants who have been storing this dataset have not completed the whole process.
We will, however, step up our review of the various aspects in the follow-up work so as to do a better job.

[galen-mcandrew]

Good evidence presented overall, but calling special attention to the following areas for the next round of allocations:

• duplicate existing datasets across network
• updating SP distribution lists
• VPN usage
• number of replicas per client

Given the KYC diligence, retrieval rate increases, and other evidence, we are requesting an additional 5PiB of DataCap.

Perhaps this team can help propose some solutions for the community to have more transparency around this issue:

In my view, it seems that most of the applicants who have been storing this dataset have not completed the whole process.