transfers doco

[Geoff Huston <gih@apnic.net>]

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.


Decomposing this further:

o Can a resource holder unilaterally "return" a resource to the resource
  issuer? Ths implication is that any allocations that were made by this
  holder are in effect invalidated at the point of resource return. (I'll
  assume that the answer is "yes" and a resource holder may return a
  resource to the issuer without any further consultation or permission
  required, although its not really relelvant to the consideration of
  resource transfers.)

  This implies that a resource holder can, at any stage, "return" a
  resource to the resource issuer.

o Can a resource holder specify the entity to whom the resource should be
  subsequently allocated? This would appear to be a matter that is up to
  the discretion of the Issuer. According to the Issuer's policies this may
  or may not be permitted.

  This implies that a resource transfer function is one that is logically
  operated by the Issuer, that reflects the transfer between clients of the
  Issuer's resources.

o 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.

What are the desireable properties of a transfer function?

o one that requires the permissions of the resource disposer, the resource
  acquirer and the common resource Issuer in order to commence.

o one that locks the resource disposer into the transaction with the
  resource acquirer to the exclusion of all other potential acquirers for
  the period of the transaction.
o one that places a time limit on the completion of the transfer
  transaction, at the expiration of which time if the transfer is not
  completed then the lock is removed and the incomplete transfer operation
  is annulled.

How could this be implemented?

One possible implementation is for the resource Issuer to operate a
transfer function, if resource transfers are permitted for resources issued
by this Issuer (according to the Issuer's policy):

o A transfer would require both entities to be 'known' to the issuer (i.e.
  have a certified business relationship with the issuer, and be capable of
  receiving certified resources from the Issuer).

o A resource transfer would commence by having the resource disposer
  deposit a signed intent to sell, and with the resource acquirer's signed
  intent to acquire a listed resource also desposited.

---------------
     Party A is willing to acquire resource x.y from Party B on or before
     the closing date: [date], subject to the completion of associated
     terms
     and conditions

     [signed Entity A]
     on this date: [date]



     Party B is willing to have resource x.y transferred to Partyy A, on or
     before the closing date: [date]  subject to the completion of
     associated
     terms and conditions

     [signed Entity B]
     on this date: [date]
---------------

o On receipt of both signed intents the Issuer would lock the resource
  against any simultaneous transactions and issue each parties a
  "transaction key half" and a validity period for the key (which becomes
  the validity period in which the transaction must be completed, the
  resource to which the transaction refers to and the names of the parties,
  signed by a verifiable Issuer's key. The Issuer is committing to
  undertake the resource transfer between the two parties on the condition
  that both halves of the "transaction key" are deposited back to the
  Issuer on or before the expiration of the transaction validity period.

o If both transaction keys are returned to the Issuer on or before the time
  when the validity period expires, then the transfer is undertaken by the
  Issuer by performing a database resource revocation from the original
  holder and a database resource allocation to the resource acquirer.

  (Presumably the two parties would engage in a transaction that saw the
  aquirer have a third party validate the transaction key halves and then
  taking control of the disposer's transaction key half in exchange for
  some form of consideration, and the acquirer subsequently returning both
  transaction keys to the resource Issuer to complete the transaction, but
  this is beyond the scope of the actual transfer operation)

TO BE DEFINED

Presumably the the transaction key is some form of signed object.

o What is the format of the transaction key?

o What information is in the transaction key halves? Presumably it
  identifies the intending disposer and intending aquirer (using identifies
  relative to the Issuer, presumably), the Issuer, the resource that is the
  subject of this transaction, the date the transaction key was created and
  the date by which the transaction keys must be deposited with the Issuer
  for the transaction to be completed.

o Can transaction key halves be independently validated, or must they be
  re-joined in order to be validated? I suspect that each half name the
  parties, the validation, the resource and is validatable as an issuer-
  signed document (in a 3779 sense of validation).

o What PKI is used for validation of the re-joined halves?

o Who determines the transaction validity period? (I suspect that its a
  Issuer max time, but a buyer and seller might agree in their requests to
  nominate the same minimum time.)

o Can the buyer or the seller cancel the trasnaction once its initiatied?
  (I suspect not, as the cancellation can in and of itself introduce
  further issues about the validity of the transaction.)

o Are there any other considerations related to the transaction key?
  Presumably the "transfer" is an allocation database transaction, and that
  the "transfer" is a consequence of an allocation registry action. The
  transfer is an allocation resource database shrink, which triggers an
  automated certificate issue and related revocation of the previous cert,
  BUT one that awaits the acquiring party to request a new cert (as the CA
  engine functionality currently does not permit auto issuance and instead
  is passive and awaits the new party to request the (larger) certificate.
  ANOTHER approach is to permit the command and control interface to also
  generate a new certificate issuance request based on the current most
  recently issued certificate and any outstanding requests in the key
  signing engine queues. It is not clear whether this auto-issuance should
  be just an attribute of a transfer, or an instance of a more general
  parameter that the CA Engine and does a regular "sweep" of certificates
  and automatically enqueues certificate issuance requests in the case that
  a) the allocation database reflects a larger resource set and b) there is
  a currently issued certificate.

o Transfer where there is no consideration of the current use of the
  address has to be seen as distinct from transfer of the functioning
  business entity with eployed resources, and routing, which is to be left
  undamaged by a change in responsibility for management/ownership higher
  in the tree.  the first kind, unencumbered transfer has no sequencing
  considerations in respect of the visible certificate hierarchy. The
  resources are expected to be redeployed in totally different ways. There
  are of course considerations of encumberance, which the buyer and seller
  and issuer need to resolve in the transfer, but the damage to the
  certificate hierarchy below this level of transfer is not material if
  sale proceeds.  The second kind is actually transfer of a business
  entity, or split of resources into a new business entity, or combining
  with an existing business entity. It has totally different behaviours,
  and depends on a process which can re-certify all existing resources
  underneath the current certificate hierarchy, with the least operational
  pain. This form of transfer should be more closely aligned with the
  Issuer's operational procedures in the corresponding resource allocation
  registry concerning potential splits and mergers of entrues in the
  allocation database that are in response to organizational splits and
  mergers

http://mirin.apnic.net/resourcecerts/wiki/index.php/Resource_Transfers";