| | | | | | | | |
|
|
|
You're here: Home |
At 06:32 PM 23/05/2007, Robert Kisteleki wrote:
Geoff Huston wrote:Resource Transfers A "Resource Transfer" is the operation of transferring the right-of-use of a resource from one party to another. In looking at how to support this operation, we appear to be looking at two major steps: 1. the return of a resource from the disposing resource holder to the resource's Issuer 2. the allocation of the resource to the new (acquiring) resource holder The implication is that a transfer is an action taken by a resource Issuer, and is the outcome of a combination of a resource revocation from an existing 'customer' resource holder, and a subsequent resource allocation action by the issuer to the acquiring 'customer', from the perspective of the common Issuer.What happens if the seller and/or buyer are not in direct business relation with the Issuer? In this case Issuer does not know the parties, their business keys, etc.
If you had read just a little further into the document you quoted above you'd have read:
"Can a resource be transferred across Issuers? Not as such. A transfer across Issuers essentially implies that the actual transfer is occurring at the first common point in the distribution hierarchy, and the other actions are resource disposals down the disposer's issuance hierarchy and allocations down the acquirers hierarchy. The actual transfer is undertaken at the point of the first common issuer in the resource allocation hierarchy and the related actions are those of resource return and resource allocation. This is outside the scope of this consideration. "
i.e. the approach described in the document you quote from only deals in the case where there are just three parties, a buyer, and seller and an issuer, and no more.
E.g. suppose that in out region ISP1->LIR1->RIPE->LIR2->ISP2 is the theoretical path of the transfer.
in which case the document you quoted from has nothing to say!What you appear to be considering below is a more complex matter where the transaction involves more intermediaries.
Without obsessing about details for the moment I've been thinking a little about what is going on here.
The certification model we are working attempts to create a certificate hierarchy that precisely models the resource allocation hierarchy.
When you think about what happens to transfers the real question is "what is the real world situation that the certificates are attempting to model?" In an environment of transfers what is the relevance of preservation of the original resource allocation chain? If the original allocation hierarchy is no longer relevant then what is the alternate structure here? How could or should such a structure be modelled in a certificate issuance hierarchy?
In this case we don't really know anything about the ISPs. The ISPs might agree on each ad every detail, but we will have to be involved.Or does this approach only deal with the LIR1->RIR->LIR2 part?An alternative (much less thought-about) approach could involve slightly different steps: 1. the initial transfer is localized to the (seller,buyer,seller's direct parent) context, i.e. the buyer becomes the sibling of the seller. transfers in such a context are practically atomic. 2. having done the local transfer, the buyer "moves/ascends" the resource up the hierarchy by asking the issuer one level up in the hierarchy as many times as needed 3. the buyer "moves/descends" the resource down the hierarchy with similar steps as in 2.The advantages of this approach would be:1. it only involves 3 (at step 1) or 2 (at steps 2-3) parties which is much easier to handle than locking god-knows-how-many parties into a single transaction.2. it can be reversed at any point3. in step 1 it's the buyer's and seller's common interest to succeed, whereas in steps 2-3 it's the buyer's interest to move the resource on. Thus, at every single step, the interested parties are directly involved. I don't see that clearly enough in the proposed approach (it actively involves non-interested parties). 4. Does not need complex supporting operations (half-keys, transaction timings, rollbacks, etc.)Some disadvantages: 1. i'm not sure it would work in practice :-)2. introduces the concept of "member for a minute", requiring the buyer to approach several businesses along the chain. OTOH, this could be done in advance too.Would this make sense as an alternative? Cheers, Robert
