Hi Sandra Sub-allocation is not the same as transfer. At least not in the current understanding of transfers. There is also a difference between resources and objects in the database. If a resource holder ´transfers´ part of an allocation to another organisation, then the original resource holder transfers full control, management and responsibility, irrevocably, for that part of his original allocation to the new organisation. All database objects will be modified to reflect the new resource holder for this transferred part. A sub-allocation is totally different. In this case the resource holder has a contractual agreement with another organisation to provide resources to this organisation with ´some´ control. The sub-allocated resource is still part of the original resource holders allocation and that resource holder is still responsible for the full resource, including the sub-allocated part. Depending on the contractual details, the new organisation may have rights to make assignments and handle routing for this sub-allocated part. The original resource holder can always take back control of the sub-allocation and delete all related database objects, regardless of who maintains them, using the reclaim functionality. The original resource holder cannot relinquish responsibility for the sub-allocation unless they decide to transfer it. With regard to ´authority over an object´ in the database, this depends on the object type and is partly about whose maintainers are referenced within the object and, for resource data, partly to which allocation it is (distantly) related to. cheersdenisco-chair DB-WG From: Sandra Murphy via db-wg <db-wg@ripe.net> To: Database WG <db-wg@ripe.net> Sent: Friday, 18 May 2018, 18:46 Subject: [db-wg] query related to Open Source wg talk on blockchain (A comment about the presentation that I’m asking here because I wasn’t quick enough in typing in the chat window - I was participating remotely.) There was a question at the mike at the very end of the presentation about blockchain, about the purpose for the work.  The answer was that the purpose was to protect origin authorization. That got me thinking about the blockchain model vs the RIPE model.  In times past, I’ve seen RIPE reminders to their members that they are responsible for their entire allocation, even if some of it is sub-allocated.  And I’ve seen training that carefully instructs the members how to use mnt-by, mat-lower, mat-routes, etc., to retain control over the sub-allocation portions of their address space, but give some control to the recipient.  And warnings that lack of care may result in losing authority, which would require correction by the database staff. I did find a FAQ for Sub-allocation that says some of this, so hopefully I am not totally off-base. Is that still the RIPE model, that authority over the sub-allocation is more shared than relinquished? If I understand blockchain properly, it presumes a model where control is given up entirely when an object is transferred.  No two entities can have authority over an object. Nothing says I’m right about that, either, of course. —Sandy