Skip to main content

Secure Asset Transfer (SAT) Use Cases
draft-ramakrishna-sat-use-cases-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Venkatraman Ramakrishna , Thomas Hardjono
Last updated 2022-08-22
Replaced by draft-ietf-satp-usecases
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ramakrishna-sat-use-cases-00
Internet Engineering Task Force                           V. Ramakrishna
Internet-Draft                                              IBM Research
Intended status: Informational                               T. Hardjono
Expires: March 22, 2023                                              MIT
                                                         August 22, 2022

                 Secure Asset Transfer (SAT) Use Cases
                   draft-ramakrishna-sat-use-cases-00

Abstract

   This document describes prominent scenarios where enterprise systems and
   networks maintaining digital assets require the ability to securely
   transfer assets or data to each other.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 22 March 2023.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

1.  Introduction

   Business networks, built on both centralized and decentralized models,
   have emerged to manage cross-organization assets and workflows. The scope
   of such workflows and the assets they govern, as well as the set of
   participating organizations within a network, have been quite limited,
   partly for security, privacy, and scalability reasons, and partly because
   organizations have been reticent to moving large portions of their pre
   existing workflows to such networks. We see this especially in the areas
   of trade, finance, supply chain logistics, and property management. Yet
   the workflows managed by these networks are naturally interlinked in the
   real world, and therefore cannot afford to remain isolated from each
   other technologically, which would diminish the value of their assets. At
   the same time, a network, once built, has institutional staying power,
   and it is therefore impractical to assume that they will expand or merge.
   Interoperability is therefore an imperative in this fragmented business
   network ecosystem. This comes in different flavors, namely the ability to
   move an asset from one network to another, interlinking workflows to
   share asset state with proof of authenticity from one network to another,
   and swapping assets in different networks as part of a business
   transaction, as listed in the SAT Architecture Specification [SATA]. The
   purpose of this document is to describe prominent examples of these modes
   that have been encountered by enterprises and business consortiums and
   identified as challenges to be overcome.  

2.  Terminology

   There following are some terminology used in the current document.
   We borrow terminology from NIST and ISO as much as possible,
   introducing new terms only when needed:

   o  Asset network (system): The network or system where a digital
      asset is utilized.
   
   o  Asset Transfer Protocol: The protocol used to transfer (move) a
      digital asset from one network to another using gateways.

   o  Origin network: The current network where the digital asset is
      located.

   o  Destination network: The network to which a digital asset is to be
      transferred.

   o  Data sharing: The process, using the Asset Transfer Protocol, by which
      one or more units of verifiably authentic data are communicated from
      an Origin network to a Destination network, either voluntarily or upon
      request.

   o  Asset Transfer: A fail-safe process of moving an asset from one
      network to another, with the destruction of the asset in the Origin
      network and its recreation in the Destination network occurring as a
      single atomic action.

   o  Asset Exchange: A fail-safe process of exchanging (or swapping) assets
      held by a pair of owners, each asset being maintained in a different
      network, with the two in-network transfers occurring as a single
      atomic action.

   Further terminology definitions can be found in [NIST] and [ISO].

3.  International Trade and Supply Chains

3.1.  Trade Finance and Logistics

   There are several real-world examples of consortium networks managing
   different aspects of international trade. Networks like We.Trade [WET],
   built on Hyperledger Fabric [HLF], and Marco Polo [MP], built on R3 Corda
   [R3C], manage trade finance workflows by connecting exporters, importers,
   and financial institutions (primarily banks). Other networks like
   TradeLens [TL], built on Hyperledger Fabric, manage trade shipping and
   documentation logistics, by connecting exporters and shipping carriers.
   As an example, consider a system of two networks as illustrated in Figure
   1: (a) a trade finance network managing letters of credit business
   lifecycles from application to fulfilment, and (b) a trade logistics
   network managing shipping consignment creation and dispatch documents
   like bills of lading.

      +------------+
      | Exporter's |  +----------+              +---------------------+
      |    Bank    |  | Exporter |              |       Exporter      |
      +------------+  +----------+              +---------------------+
            | |            |                       | |              |
       3    | |    5       |    4           1      | |      2       |   4
    Approve | | Request    | Upload       Book     | |   Create     | Accept
      L/C   | | Payment    |   B/L     Consignment | | Consignment  |  B/L
            | |            |                       | |              |
            V V            V                       V V              V
    +-------------------------------+     +-------------------------------+
    |     Trade Finance Network     |     |    Trade Logistics Network    |
    +-------------------------------+     +-------------------------------+
            |              |                           |     |
       2    |              |    1               5      |     |    3
    Propose |              | Request        Dispatch   |     | Upload
      L/C   |              |   L/C         Consignment |     |   B/L
            |              |                           |     |
      +------------+  +----------+                 +-------------+
      | Importer?s |  | Importer |                 |   Carrier   |
      |    Bank    |  +----------+                 +-------------+
      +------------+
                   (a)                                   (b)

                                 Figure 1

   An exporter who belongs to both systems must produce a valid bill of
   lading in the trade finance network to enforce a payment from the buyer
   to fulfill the terms of the letter of credit. But this bill, which serves
   as evidence of a shipping consignment?s dispatch via a carrier, lies in
   the other, i.e., trade logistics, network.  The two networks must
   therefore be interoperable in such a way that the logistics network can
   share a bill with the finance network along with independently verifiable
   proof of authenticity. Otherwise, the trade finance network?s workflow
   must trust that the exporter is acting in good faith and supplying
   genuine bills of lading, which adds insecurity. This interoperation,
   which involves sharing of network data, can be extrapolated to other
   scenarios involving the two networks. The trade logistics network can
   require an exporter to produce a valid letter of credit from the trade
   finance network before permitting a consignment record creation. Both
   these cross-network data sharing instances are illustrated in Figure 2.

               +----------+    1 Agree on      +----------+
               | Exporter |<------------------>| Importer |
               +----------+   Purchase Order   +----------+

      +------------+
      | Exporter's |  +----------+              +---------------------+
      |    Bank    |  | Exporter |              |       Exporter      |
      +------------+  +----------+              +---------------------+
            | |                                    | |              |
       4    | |   12                        5      | |      7       |   9
    Approve | | Request                   Book     | |   Create     | Accept
      L/C   | |   L/C                  Consignment | | Consignment  |  B/L
            | |                                    | |              |
            | |                                    | |              |
            | |            |--------------------|  | |              |
            | |            |    11 Share B/L    |  | |              |
            V V            V                    |  V V              V
    +-------------------------------+     +-------------------------------+
    |     Trade Finance Network     |     |    Trade Logistics Network    |
    +-------------------------------+     +-------------------------------+
            |              |    |               |      |     |
            |              |    |  6 Share L/C  |      |     |
            |              |    |_______________|      |     |
            |              |                           |     |
       3    |              |    2               10     |     |    8
    Propose |              | Request        Dispatch   |     | Upload
      L/C   |              |   L/C         Consignment |     |   B/L
            |              |                           |     |
      +------------+  +----------+                 +-------------+
      | Importer?s |  | Importer |                 |   Carrier   |
      |    Bank    |  +----------+                 +-------------+
      +------------+

                                 Figure 2

3.2.  Tracking Food Shipments

   The use case linking a trade finance network with a trade logistics
   network can be augmented by adding a food tracking network like the IBM
   Food Trust [IFT] to the mix. Such a network connects producers,
   suppliers, manufactures, and retailers, who participate in food supply
   chains. Purchase orders, like those negotiated between producers and
   retailers, and which are illustrated as negotiated between exporter and
   importers in Figure 2, are recorded in this network?s ledger. For quality
   control, its business workflow will track at periodic intervals the state
   (e.g., temperature and humidity) of containers carrying, for example,
   produce from farm to source port and from destination port to warehouse.
   The trade logistics network handles documentation and dispatch but does
   not track the location or condition of a consignment outside of a
   carrier?s purview. Clearly, these networks play complementary roles in a
   supply chain. The logistics network should be able to get the state and
   history of a container before dispatch from the food tracking network, as
   should the latter from the former after the carrier has delivered a
   consignment. End-to-end supply chain visibility and effectiveness relies
   on the interoperability of these two networks, or to be precise, their
   ability to share verifiably authentic data with each other. Further, such
   interoperation also enables the trade finance network to allow the
   creation of a letter of credit only after verifying the existence of a
   valid purchase order in the food tracking network. Figure 3 illustrates
   the links between these networks.

                      +-------------------------------+
                 |----|     Food Tracking Network     |----------|
                 |    +-------------------------------+          |
         Share   |                              |                |  Share
        Purchase |                              |  Share         | Shipment
         Order   |         |----------------|   | Shipment       |  State
                 |         |   Share B/L    |   |  State         |
                 V         V                |   |                V
    +-------------------------------+     +-------------------------------+
    |     Trade Finance Network     |     |    Trade Logistics Network    |
    +-------------------------------+     +-------------------------------+
                                |               |
                                |   Share L/C   |
                                |_______________|

                                 Figure 3

3.3.  Supply Chain Management

   To complete the picture, we can add a payments network to the mix, which
   maintains currency accounts for clients in different countries and
   enables cross-border payments, an example being the Stellar network
   [STN]. After goods have been dispatched, and optionally after
   verification of the delivery and proper condition of a shipment, payment
   is due from an importer to an exporter. The trade finance network can
   record a payment obligation on its ledger but it will rely on the
   payments network to process and confirm the actual transfer of funds. The
   former shares data about the obligation to the latter, which shares data
   about a successful (or otherwise) payment in return, as illustrated in
   Figure 4.

                      +-------------------------------+
                 |----|     Food Tracking Network     |----------|
                 |    +-------------------------------+          |
         Share   |                              |                |  Share
        Purchase |                              |  Share         | Shipment
         Order   |         |----------------|   | Shipment       |  State
                 |         |   Share B/L    |   |  State         |
                 V         V                |   |                V
    +-------------------------------+     +-------------------------------+
    |     Trade Finance Network     |     |    Trade Logistics Network    |
    +-------------------------------+     +-------------------------------+
                | |               |               |
        Share   | |   Share       |   Share L/C   |
       Payment  | |  Payment      |_______________|
     Obligation | | Fulfilment
                | |
                V |
      +----------------------+
      |   Payments Network   |
      +----------------------+

                                 Figure 4

   Addendum: we can add yet another network to the mix, one that manages
   regulatory compliance. (E.g., proof-of-concept systems have been built to
   bring banks and corporations on a single distributed ledger and smart
   contract platform to share KYC information in privacy-preserving ways
   [BKYC] [SKYC].) Now issuances of letters of credit in the trade finance
   system will be dependent on valid KYC records being maintained as assets
   in the regulatory compliance system.

4.  Financial Instruments and Currency Exchanges

4.1.  Currency Transfers

   Central Bank Digital Currencies, or CBDCs for short, have garnered
   significant interest in governmental circles recently as an efficient and
   transparent mechanism to enforce monetary policy and to enable
   transactions at scale as a substitute for legacy payment mechanisms. CBDC
   systems can come in different varieties, with a 2-tier model as
   illustrated in Figure 5 gaining recent popularity. In the higher tier lie
   wholesale CBDC networks, built on distributed ledger and smart contract
   platforms, bringing together central or reserve banks and various
   commercial banks. Commercial banks hold reserve currency deposits with
   the reserve bank, which has the special power to mint currency and issue
   CBDC and also enforce regulatory compliance. In the lower tier lie retail
   CBDC networks for commercial banks and their customers, built on similar
   technologies, enabling seamless, efficient, and transparent payments
   using CBDCs. A retail CBDC network may involve a single commercial bank
   or multiple commercial banks, depending on the market caps of those banks
   and their purposes for joining such a network.

                  +----------------------------------------+
                  |                                        |
                  |         Wholesale CBDC Network         |
                  |                                        |
                  |           +----------------+           |
                  |           |  Central Bank  |           |
                  |           +----------------+           |
                  |                                        |
                  |  +------------+  +------------+        |
                  |  | Commercial |  | Commercial |        |
                  |  |  Bank A's  |  |  Bank B's  | ...... |
                  |  |   Account  |  |   Account  |        |
                  |  +------------+  +------------+        |
                  |                                        |
                  +----------------------------------------+
                        |                      |
                        |                      |
                        |                      |
                        V                      V
   +----------------------------+  +----------------------------+
   |                            |  |                            |
   |    Retail CBDC Network     |  |    Retail CBDC Network     |
   |                            |  |                            |
   | +------------+ +---------+ |  | +------------+ +---------+ |
   | | Commercial | | Central | |  | | Commercial | | Central | |
   | |  Bank A's  | |  Bank   | |  | |  Bank B's  | |  Bank   | |
   | |   Account  | +---------+ |  | |   Account  | +---------+ |
   | +------------+             |  | +------------+             |
   |                            |  |                            | .......
   | +----------------+         |  | +------------+             |
   | | Client Account | ....... |  | | Commercial |             |
   | +----------------+         |  | |  Bank C?s  |             |
   |                            |  | |   Account  |             |
   +----------------------------+  | +------------+             |
                                   |                            |
                                   | +----------------+         |
                                   | | Client Account | ....... |
                                   | +----------------+         |
                                   |                            |
                                   +----------------------------+

                                 Figure 5

   Here we will encounter scenarios where a given commercial bank maintains
   digital currency accounts in a wholesale CBDC network as well as one or
   more retail CBDC networks. To inject liquidity into a retail CBDC
   network, this bank will need to transfer currency from its reserve
   account in the wholesale CBDC network. Or it may need to transfer
   currency from one retail CBDC network to another bank in another retail
   CBDC network. In the world of decentralized finance, or DeFi for short,
   currency cannot afford to remain siloed in any single CBDC network.
   Hence, these networks must be interoperable in order to facilitate secure
   transfers of currency among themselves, as illustrated in Figure 5.

4.2.  Delivery vs Payment of Securities

   In Decentralized Finance, or DeFi for short, investors and financial
   institutions will form networks to manage the creation and purchase of
   securities. As a simple example, we can consider a network consisting of
   the Treasury, which issues bonds, and commercial banks, which purchase
   and trade bonds. We can also consider a payments network of the kind we
   saw in Section 3.3 (or a retail CBDC network of the kind we saw in
   Section 4.1), which allows CBDC transfers between commercial bank
   accounts. In the securities network, banks may wish to transfer bonds to
   each other but only in exchange for compensation. But such compensation
   can be made only on a payments network where the two maintain currency
   accounts (e.g., in CBDC). Therefore, the securities and payment networks
   must be able to interoperate in such a way that two banks can carry out a
   delivery-vs-payment transaction spanning these two independent networks.
   Such a transaction must be atomic, i.e., either both bond and CBDC tokens
   get transferred in their respective networks or neither gets transferred.
   Figure 6 illustrates this exchange.

   +-----------------------------------------------------------------------+
   |                             Bond Network                              |
   |                                                                       |
   |     +----------+      Issue        +---------------------------+      |
   |     | Treasury |------------------>|    Commercial Bank A's    |      |
   |     +----------+       Bond        |         Portfolio         |      |
   |                                    +---------------------------+      |
   |                                                  |                    |
   |                                                  |  Transfer          |
   |                                                  |    Bond            |
   |                                                  V                    |
   |                                    +---------------------------+      |
   |                                    |    Commercial Bank B's    |      |
   |                                    |         Portfolio         |      |
   |                                    +---------------------------+      |
   +-----------------------------------------------------------------------+
                                       |
                                       |
                                       |
                                       V
   +-----------------------------------------------------------------------+
   |                 Payment Network / Retail CBDC Network                 |
   |                                                                       |
   |     +-----------+                  +---------------------------+      |
   |     |  Central  |                  |    Commercial Bank A's    |      |
   |     |    Bank   |                  |           Account         |      |
   |     +-----------+                  +---------------------------+      |
   |                                                  |                    |
   |                                                  |  Transfer          |
   |                                                  |  Currency          |
   |                                                  V                    |
   |                                    +---------------------------+      |
   |                                    |    Commercial Bank B's    |      |
   |                                    |          Account          |      |
   |                                    +---------------------------+      |
   +-----------------------------------------------------------------------+

                                 Figure 6

5.  Interoperation Protocol Considerations

   The use cases provided as examples serve to illustrate instances of
   general phenomena that the Secure Asset Transfer Protocol [SATP],
   with a limited number of variations, is designed to handle. The data
   sharing examples in Section 3 can be extrapolated to any kinds of data
   that need to be shared between networks running arbitrary workflows. The
   asset transfer example in Section 4.1 and the asset exchange example in
   Section 4.2 similarly can be extrapolated to any kinds of digital assets
   lying within any kind of network. Considerations for the interoperability
   protocol, or SATP< can therefore be limited to standard distributed
   systems issues like integrity, fault tolerance, and liveness, while
   completely disregarding the nature of the assets, networks, and
   workflows, which can all remain opaque to the protocol.

6.  References

6.1.  Normative References

   [BKYC]     Michael Curry, "Blockchain for KYC: Game-changing RegTech
              innovation.", September 21, 2018,
              <https://www.ibm.com/blogs/blockchain/2018/09/blockchain-for-
              kyc-game-changing-regtech-innovation/>.

   [HLF]      Elli Androulaki, Artem Barger, Vita Bortnikov, Christian
              Cachin, Konstantinos Christidis, Angelo De Caro, David
              Enyeart, Christopher Ferris, Gennady Laventman, Yacov
              Manevich, Srinivasan Muralidharan, Chet Murthy, Binh Nguyen,
              Manish Sethi, Gari Singh, Keith Smith, Alessandro Sorniotti,
              Chrysoula Stathakopoulou, Marko Vukolic, Sharon Weed Cocco,
              and Jason Yellick, "Hyperledger Fabric: A Distributed
              Operating System for Permissioned Blockchains", EuroSys 2018,
              <https://dl.acm.org/doi/pdf/10.1145/3190508.3190538>.

   [IFT]      IBM, "IBM Food Trust ? Blockchain for the world?s food
              supply", 2022,
              <https://www.ibm.com/blockchain/solutions/food-trust>.

   [ISO]      ISO, "Blockchain and distributed ledger technologies-
              Vocabulary (ISO:22739:2020)", July 2020,
              <https://www.iso.org>.

   [MP]       Marco Polo Network Operations (Ireland) Limited, "Marco Polo
              Network: Blockchain Enabled Supply Chain & Payment
              Solutions.", 2022,
              <https://marcopolonetwork.com/>.

   [NIST]     Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST
              Blockchain Technology Overview (NISTR-8202)", October
              2018, <https://doi.org/10.6028/NIST.IR.8202>.

   [R3C]      R3, "Corda: A Technical White Paper", August 2019,
              <https://www.r3.com/reports/corda-technical-whitepaper/>.

   [SATA]     Hardjono, T., Hargreaves, M., Smith, N., and V. Ramakrishna,
              "Secure Asset Transfer (SAT) Interoperability Architecture,
              IETF, draft-hardjono-sat-architecture-00.", June 2022,
              <https://datatracker.ietf.org/doc/draft-hardjono-sat-
              architecture/>.

   [SATP]     Kumar Bhaskaran, Peter Ilfrich, Dain Liffman, Christian
              Vecchiola, Praveen Jayachandran, Apurva Kumar, Fabian Lim,
              Karthik Nandakumar, Zhengquan Qin, Venkatraman Ramakrishna,
              Ernie GS Teo, and Chun Hui Suen, "Double-Blind Consent-Driven
              Data Sharing on Blockchain." First IEEE Workshop on Blockchain
              Technologies and Applications (BTA) 2018, Co-located with 2018
              IEEE International Conference on Cloud Engineering (IC2E),
              Orlando, FL, April 17, 2018.

   [SKYC]     Michael Curry, "Blockchain for KYC: Game-changing RegTech
              innovation.", September 21, 2018,
              <https://www.ibm.com/blogs/blockchain/2018/09/blockchain-for-
              kyc-game-changing-regtech-innovation/>.

   [STN]      Stellar Development Foundation, "Stellar ? Access your
              universe of opportunities", 2022,
              <https://www.stellar.org/>.

   [TL]       TradeLens, "TradeLens: Supply chain data and docs.", 2022,
              <https://www.tradelens.com/>.

   [WET]      IBM, "we.trade.", 2019,
              <https://www.ibm.com/case-studies/we-trade-blockchain>.

6.2.  Informative References

   [Abebe19]  Ermyas Abebe, Dushyant Behl, Chander Govindarajan, Yining
              Hu, Dileban Karunamoorthy, Petr Novotny, Vinayaka Pandit,
              Venkatraman Ramakrishna, Christian Vecchiola, "Enabling
              Enterprise Blockchain Interoperability with Trusted Data
              Transfer", Middleware 2019 - Industry Track, December 2019,
              <https://arxiv.org/abs/1911.01064>.

   [Abebe21]  Ermyas Abebe, Yining Hu, Allison Irvin, Dileban Karunamoorthy,
              Vinayaka Pandit, Venkatraman Ramakrishna, Jiangshan Yu,
              "Verifiable Observation of Permissioned Ledgers", ICBC 2021,
              May 2021, <https://arxiv.org/abs/2012.07339>.

   [ABCH20]   Ankenbrand, T., Bieri, D., Cortivo, R., Hoehener, J., and
              T. Hardjono, "Proposal for a Comprehensive Crypto Asset
              Taxonomy", May 2020, <https://arxiv.org/abs/2007.11877>.

   [BVGC20]   Belchior, R., Vasconcelos, A., Guerreiro, S., and M.
              Correia, "A Survey on Blockchain Interoperability: Past,
              Present, and Future Trends", May 2020,
              <https://arxiv.org/abs/2005.14282v2>.

   [Clar88]   Clark, D., "The Design Philosophy of the DARPA Internet
              Protocols, ACM Computer Communication Review, Proc SIGCOMM
              88, vol. 18, no. 4, pp. 106-114", August 1988.

   [Gray81]   Gray, J., "The Transaction Concept: Virtues and
              Limitations, in VLDB Proceedings of the 7th International
              Conference, Cannes, France, September 1981, pp. 144-154",
              September 1981.

   [Herl19]   Herlihy, M., "Blockchains from a Distributed Computing
              Perspective, Communications of the ACM, vol. 62, no. 2,
              pp. 78-85", February 2019,
              <https://doi.org/10.1145/3209623>.

   [HLP19]    Hardjono, T., Lipton, A., and A. Pentland, "Towards and
              Interoperability Architecture for Blockchain Autonomous
              Systems, IEEE Transactions on Engineering Management",
              June 2019, <https://doi:10.1109/TEM.2019.2920154>.

   [HS2019]   Hardjono, T. and N. Smith, "Decentralized Trusted
              Computing Base for Blockchain Infrastructure Security,
              Frontiers Journal, Special Issue on Blockchain Technology,
              Vol. 2, No. 24", December 2019,
              <https://doi.org/10.3389/fbloc.2019.00024>.

   [HTLC21]   "Hash Time Locked Contracts", Bitcoin Wiki
              <https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts>.

   [IDevID]   Richardson, M. and J. Yang, "A Taxonomy of operational
              security of manufacturer installed keys and anchors. IETF
              draft-richardson-t2trg-idevid-considerations-01", August
              2020, <https://tools.ietf.org/html/draft-richardson-t2trg-
              idevid-considerations-01>.

   [SRC84]    Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments
              in System Design, ACM Transactions on Computer Systems,
              vol. 2, no. 4, pp. 277-288", November 1984.

Authors' Addresses

   Venkatraman Ramakrishna
   IBM Research - India

   Email: vramakr2@in.ibm.com

   Thomas Hardjono
   MIT

   Email: hardjono@mit.edu

[2]