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
