Re: [apps-discuss] Proposal for a Finance Area Mailing List

Walter <walter.stanish@gmail.com> Fri, 09 March 2012 03:44 UTC

Return-Path: <walter.stanish@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF46B21E801C for <apps-discuss@ietfa.amsl.com>; Thu, 8 Mar 2012 19:44:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.489
X-Spam-Level:
X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oax6FCovVeNJ for <apps-discuss@ietfa.amsl.com>; Thu, 8 Mar 2012 19:44:55 -0800 (PST)
Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5925D21E8010 for <apps-discuss@ietf.org>; Thu, 8 Mar 2012 19:44:55 -0800 (PST)
Received: by obbta4 with SMTP id ta4so1748563obb.31 for <apps-discuss@ietf.org>; Thu, 08 Mar 2012 19:44:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vSg9KYmv5OVPtP4IgT57VBMYA2FAf74Cnb1D4bwpYBg=; b=pSfg/Ad6DfxyxToHME6vM8E6aPVH5/r+UZiEwCZq7KMBepKF4lBAS1RSJPZcufeOD5 5s60G1FPH5YabGxfFoQnvlMfSIT7xREPQr4ztc8wSeK6PgB1GSBW3OgeDuxw0+y7l+N4 DCuiaKfYk0aSttbgMu4nB36pQBV6YdcF5euTMHkKGdW7fX10rXQMzVKcVHtz5sxM6Bmg phhp31st++HeVZ8mUpWGM3lnsirCGwwjgIv05HKTc3t3Zr79Qua/bYJ2/4usOhSW7SWu XMFoGcZ4PXHjYy6bolhtqMIEEWHeFOevX4oqC652ukpiK1GzDcdusTNCqaSGZwSTkhEs SkVQ==
MIME-Version: 1.0
Received: by 10.182.108.97 with SMTP id hj1mr282153obb.37.1331264694962; Thu, 08 Mar 2012 19:44:54 -0800 (PST)
Received: by 10.60.149.225 with HTTP; Thu, 8 Mar 2012 19:44:54 -0800 (PST)
In-Reply-To: <4F58D9F3.2000602@dcrocker.net>
References: <CACwuEiOPeym2Ro6WffhAg__nzkiKmBXu7woKV3kWLodX11b1Qg@mail.gmail.com> <CAC4RtVA_aQcSF6-vzuW6z0vHdgx8cWwpMFw_6twZL6ijukHJ8A@mail.gmail.com> <CACwuEiOP8ct661taViFJP6sNCEEfe7PyZrO2OBUg1tiB9d0vZQ@mail.gmail.com> <4F58D9F3.2000602@dcrocker.net>
Date: Fri, 09 Mar 2012 10:44:54 +0700
Message-ID: <CACwuEiNR3XVwrYov6uCy8QaTsdCEi=1B_rGn_Ef3jEj7izEnHQ@mail.gmail.com>
From: Walter <walter.stanish@gmail.com>
To: dcrocker@bbiw.net
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Mar 2012 03:44:56 -0000

> Stated differently, what problems are to be solved by this activity and who
> will work on them?  (Stating the former is meant to recruit statements of
> interest from the latter.)

Thanks for your comments Dave, particularly the historic references
your subsequent message which I will reply to shortly. I believe an
approximate answer to this specific question has already been supplied
- if there is any area in which you would like more detail please feel
free to ask:

============================================================
 Certain functionality required by modern financial systems is not
 presently available in open, legacy-free, adequately globalized
 protocols.

 This functionality includes:
  * Settlement and reversal / cancellation term negotiation
  * Exchange rate negotiation
  * Latency calculation / negotiation
  * Fee, tax and discount calculation / negotiation
  * Arbitrary currency / asset support
  * Multi-currency / asset transaction support
  * Quotation support
  * Multiple settlement path support
  * Optional support for in-band settlement (sometimes known as DVP)
  * High precision decimal value support
  * Arbitrary financial settlement topology support
  * Arbitrary communications topology support

 Given this situation, it makes sense to propose a legacy-free,
 adequately extensible protocol for internet-based financial exchange.
============================================================

>> Financial industry groups are not the right forum for this development
>> as they are top-heavy with a massive, indisputable interest in
>> maintaining the status quo.
>
> You know about IANA registries but appear not to know that statements like
> above are counterproductive in the IETF (and most other places.)

Please accept my apologies as I do not understand this comment.

In requesting the support of the IETF in setting up a mailing list for
the discussion and development of forward looking financial standards,
the question of whether the IETF is the "best" place to do this was
raised.

Thus presented with the notion that established financial industry
bodies (large, top-heavy, centralized organizations constrained
through bureaucracy, legal concerns and multi-jurisdictional
regulatory constraints as well as significant financial self-interest
in the status quo) might be a better venue to discuss alternatives to
the established systems used by the same, I motioned that was not the
case.

Would it be possible to clarify your perspective further? I believe I
am missing something.

To reiterate the points raised earlier, the IETF has been identified
as an excellent venue for such discussion and development for the
following reasons:

 1. Transparency and community examination of a proven standards
development process
 2. Access to IANA: an established, internationally credible third
party for registry management (very useful to build trust in alternate
financial systems)
 3. Access to supplementary services such as document distribution.

Regards,
Walter Stanish
Payward, Inc.