[address-policy-wg] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Address Block Transfers)

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/