Good morning Alex,
Quoting from 2012-05's impact analysis:
«It is worth mentioning that the RIPE NCC is willing to publish details on resource transfers and a report has not been requested so far. Only one transfer has been recorded in the RIPE NCC service region recently, and this is why no details on resource transfers have been published so far.»
* Alex Le Heux
However, given this proposal and the discussion around it, we would prefer to wait until it reaches a conclusion before publishing.
Okay. This surprises me a bit, though. The impact analysis seems to me to state, essentially, «we are willing to publish the requested information without a clear policy mandate from the community». However, your response seems to suggest the exact opposite, i.e., «we are NOT willing to publish the requested information without a policy clear mandate from the community». I don't believe anyone is proposing to *forbid* you from publishing information on transfers, the way I see it, the question is simply whether or not the community needs to compel you (through policy) to publish it, or not. In my opinion, it would be much more preferable to not have to take the policy route, since the terser and concise the policy text is, the better it is. The community shouldn't need to micro-manage the NCC through policy - it would be better and more efficient if we could instead work directly with you to get what we want. But now I am not so sure on whether or not the added policy text is required after all. Do you see any outcome of this proposal's discussion that would cause you to not publish the requested information after all?
We already publish various files that reflect the state of the RIPE registry:
ftp://ftp.ripe.net/pub/stats/ripencc/ ftp://ftp.ripe.net/ripe/stats/membership/alloclist.txt ftp://ftp.ripe.net/ripe/dbase/split/
Comparing different versions of these files will show any transfers that were done under the transfer policy. It would however also show the results of the various types of mergers, acquisitions and divestments that also happen on a regular basis.
I am aware of these files, and have been digging through them already in search of the transfer in question. The problem with them, as you point out, is that it is difficult to tell a "pure" transfer apart from other types of business transactions. Looking back to mid-June, the most likely candidates I find are: 1) 109.109.144.0/20 (uk.layershift -> uk.gemsoft, 2012-06-19) 2) 91.145.32.0/19 (se.helsingenet -> se.hnet-ovan, 2012-08-29) 3) 82.164.192.0/18 (no.telenor -> no.eab, 2012-10-17) 4) 82.196.28.0/22 (fr.inetwork -> fr.edxnetwork, 2012-10-30) #4 can't be the one the Impact Analysis refers to as it is too recent, and all the others seems to be related in other ways (e.g., same ASN for the route objects). If I were to make a guess, I'd put my money on #3, as the recipient LIRs in #1 and #2 hold only the single transferred resource, making me suspect those transactions are due to the origin LIRs' organisations splitting in two. However, all the allocations mentioned above are listed with the original date of allocation in both alloclist.txt and delegated-ripencc-extended. I could not find a single transaction where the date changed to the present day (except those blocks that went through the "reserved" state, which I guess means returned to the NCC and re-allocated normally). So while I won't ask you to confirm whether or not any of the above transactions are indeed the transfer the Impact Analysis refers to, I was wondering if you could tell whether or not the date of the allocation will remain unchanged as a result of a transfer?
I hope this answers your questions for now.
Not really. I ended up with more questions than I had to begin with. ;-) Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/