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

From: Walter <[email-masked]>
Date: Thu, 1 Mar 2012 22:31:19 +0700

Hi there.

This message is posted at the request of the Application Area Managers
as the culmination of email interaction dating back to December 15,
2011.

We seek the establishment of a mailing list for the discussion of
financial area protocols.

Recently Payward Inc. authored two drafts:
https://datatracker.ietf.org/doc/draft-iiban/
https://datatracker.ietf.org/doc/draft-imic/

The drafts propose means for financial endpoint identification and
financial market identification. They are of wide potential interest
for alternate financial networking, however they are missing a
critical and complex reason to deploy them widely, which is an
inter-institutional protocol for transaction quotation, negotiation,
reporting and state management.

A possible solution in this area will be presented in an upcoming
draft, essentially seeking to provide a mechanism to replace
established protocols (ISO20022, FIX) with an open, non-legacy
alternative with adequate flexibility to support emerging digital
financial networks.  To illustrate, the problem statement for the as
yet unpublished draft is as follows.

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

In addition to our own work above, most of you are probably aware of
some of the various other efforts going on in the financial world.
These efforts include mobile finance, digital currencies and
settlement systems, private currency markets, new transaction
protocols, scalable non fiat-currency based community-centric
transaction systems, and other projects.  A few examples:
 - Bitcoin: http://bitcoin.org/
 - CES: http://ces.org.za/
 - Ripple: http://ripple-project.org/
 - W3C Web Payments: http://www.w3.org/community/webpayments/

At this stage some discussions have already occurred in public forums
with reference to the drafts that Payward Inc. has published and the
potential for a greater community involvement in exploring potential
solutions:
 http://bit.ly/v6n2tk (The Bitcoin Trader)
 http://bit.ly/xpMxQ3 (Bitcoin Development list)
 http://bit.ly/zpVHms (Ripple Users)

Unfortunately, due to the project-oriented nature of each of these
forums it is difficult to focus on issues that exceed individual
project scope either affect or have the potential to affect the wider
internet community. Therefore Iwebelieve that it would be useful to
try to draw representatives of the various projects together to
discuss such issues via a mailing list hosted at the IETF, with the
goal to discuss and develop solutions to problems in established and
emerging financial networks.  The IETF specifically can provide:

 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 functional, supplementary services such as document distribution.

We therefore request the establishment of a financial area mailing list.

Feedback and statements of interest are hereby requested.

Regards,
Walter Stanish
Payward Inc.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 7 Mar 2012 18:19:03 -0500

Apps-Discuss folks: It's been about a week since Walter posted this,
and no one's commented.  Perhaps that means that no one's  interested,
but I'd like to stir the pot a bit and see whether anyone has anything
to say.  Nudge-nudge, stir-stir.

Walter, what we're looking for here is some public discussion that
results in at least some reasonable level of understanding about what
would be discussed on the mailing list you propose, who might be
interested in participating and, importantly, what IETF work might
come out of it.  I'll note that standardization doesn't only happen in
the IETF; there other standards organizations with different foci, and
industry consortia often form to develop special-purpose standards for
limited industry subgroups.  What you want here might not be a bunch
of Internet gearheads who worry about SMTP, HTTP, SIP, MPLS, and BGP,
but, rather, some techies involved in the finance industry who can
better develop something that really meets the need you have.

That's not an answer one way or the other, but a call for conversation
and analysis, and some seeds to start the discussion.

Barry, AppsAWG chair and incoming App AD

On Thu, Mar 1, 2012 at 10:31 AM, Walter <[email-masked]> wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Walter <[email-masked]>
Date: Thu, 8 Mar 2012 07:47:26 +0700

> to say.  Nudge-nudge, stir-stir.

For the record I have received a private response from a member of the
Energy WG.

> would be discussed on the mailing list you propose,

Is it really necessary to have people already participating in this
mailing list express interest in order to justify a new list on a
specific subject? Whilst I can understand the tradition, this does
seem like a bit of a paradox to me: surely interested parties are to
be drawn to such a mailing list from related corners of the wider
internet community?

> who might be
> interested in participating

Addressed in the original email, I believe.

> and, importantly, what IETF work might come out of it.

Being new to IETF processes in general, I can shed no light on this.
Certainly the establishment of some IANA registries.

>  I'll note that standardization doesn't only happen in

I am well aware of the protocol authoring focus.

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.

Scope-wise: Whilst we are looking at higher level protocols (hence
'application area'), we can't simply take the de-facto choice and
build on HTTP or TCP because they don't meet the multipoint
requirements of many financial messaging systems.  (In addition, the
transaction-orientation of HTTP is too limiting for many such
communities who presently use exotic mixes of custom out of band
stream replay solutions to resolve intermittent loss on their high
bandwidth, sequence-numbered financial information streams)  There are
a wide range of message queue systems that are in commercial use or
open source development that may serve to elegantly resolve transport
layer requirements, though mandating an exotic transport layer would
be self-defeating. Therefore, the current view is toward transport
neutrality.

Regards,
Walter Stanish
Payward, Inc.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 8 Mar 2012 07:45:03 -0800

> be drawn to such a mailing list from related corners of the wider

So, there may be some missing history here.  Some time ago, the IETF
had a working group called TRADE (archives visible here:
http://lists.elistx.com/archives/ietf-trade/) that produced IOTP (RFC
2801, 2802, 2803, along with some updates, including errata published
in RFC 3504).    Though it had sufficient activity to produce some
documents, it did not seem to get a lot of use with version 1 and
version 2 languished because working group was so low (a handful of
folks in the room low).   It eventually got shut down because there
were simply too few people engaged to call consensus on the results.

For areas that are new to the IETF or for which previous engagement
did not produce a lot of results, it does make sense to me to ask for
a demonstration that there is a community of interest in the work.
Donald Eastlake, who chaired TRADE, may have more insight.

regards,

Ted Hardie

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Mar 2012 08:01:18 -0800

Similarly, there was sufficient interest in the early EDI work, which had a similar audience to what is proposed here, but then that too fell into a situation of too few participants to be able to determine a meaningful consensus.

--Paul Hoffman

---

From: Dave Crocker <[email-masked]>
Date: Thu, 08 Mar 2012 08:10:27 -0800

Walter,

> Certainly the establishment of some IANA registries.

While it's reasonable not to know what details will or should be produced, it's 
a bit challenging to come to a forum asking for its community to participate in 
an activity, without having a pretty solid sense of what that activity will do.

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

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

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Thu, 08 Mar 2012 08:15:01 -0800

> Similarly, there was sufficient interest in the early EDI work, which had a similar audience to what is proposed here, but then that too fell into a situation of too few participants to be able to…

The early EDI work produced a working group and a successor working group, 
participation and specifications:

RFC6362, Multiple Attachments for Electronic Data Interchange - Internet 
Integration (EDIINT) K. Meadors, Ed.  August 2011  ASCII  INFORMATIONAL

RFC6359, Datatracker Extensions to Include IANA and RFC Editor Processing 
Information S. Ginoza, M. Cotton, A. Morris  September 2011  ASCII  INFORMATIONAL

RFC6017, Electronic Data Interchange - Internet Integration (EDIINT) Features 
Header Field

RFC5402, Compressed Data within an Internet Electronic Data Interchange (EDI) 
Message T. Harding, E

RFC1865, EDI Meets the Internet Frequently Asked Questions about Electronic Data 
Interchange (EDI) on the Internet W. Houser, J. Griffin, C. Hage  January 1996 
ASCII  INFORMATIONAL

RFC1767, MIME Encapsulation of EDI Objects D. Crocker

---

From: Walter <[email-masked]>
Date: Fri, 9 Mar 2012 10:44:54 +0700

> 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:

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

---

From: "John Levine" <[email-masked]>
Date: 9 Mar 2012 04:31:35 -0000

>  * Arbitrary communications topology support

Sounds cool.  Anyone likely to implement it?  The IETF has a well known
preference for running code.

R's,
John

---

From: Walter <[email-masked]>
Date: Fri, 9 Mar 2012 12:19:04 +0700

> Sounds cool.

Thank you for your positive comment.

>  Anyone likely to implement it?  The IETF has a well known

(One might wonder if such conflicts with the 'come with a problem
rather than a solution' philosophy of the BOFs / mailing list
proposals @ http://tools.ietf.org/html/rfc5434#page-2 ?  Then again,
one might try to focus on avoiding bureaucratic discussion
entirely...)

Forward looking statements are always hard to juggle, but at present
it does seem that whatever we wind up deciding upon will be
implemented by Payward Inc.  At least one party with worldwide
presence has also expressed a significant and immediate interest -
even at this very early stage - in rapid implementation.  Whether we
move forward independently or on a shared implementation is not yet
known. Resulting code may be shared in whole or in part with the wider
community as open source, depending upon commercial concerns which are
not my domain and I cannot therefore comment on.

Secondly, I would note that the complexity that the above feature list
suggests should not be taken as a requirement for basic
implementation; even integrating exhaustive specifications for all
possible considerations of these features in to a document would
render it a book. The philosophy to do one thing and do it well
demands a minimalist approach; as per established protocols extensions
for precise cases (under various legal jurisdictions, when accessing
certain financial markets or networks, etc.) would presumably be
described separately. Individual implementations would be free to
leave out support for most or all extensions, advertise the subset
that they support when handshaking, then interact appropriately.
Easier said than done, but I believe an achievable goal.

In closing, perhaps you could assist with teething issues faced by
mere newcomers such as myself by flexing your apparent dummy series
authorship credentials on a humorous RFC for April; "The IETF for
Dummies"?

Regards,
Walter Stanish
Payward, Inc.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 9 Mar 2012 05:22:15 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Walter
> Sent: Thursday, March 08, 2012 9:19 PM
> To: John Levine
> Cc: [email-masked]
> Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List
> 
> In closing, perhaps you could assist with teething issues faced by mere
> newcomers such as myself by flexing your apparent dummy series

John may have different advice, but I typically refer people to RFC4677 (http://tools.ietf.org/html/rfc4677, "The Tao of IETF").

Have fun!

-MSK (not an actual dummy, but I play one at plenaries)

---

From: Walter <[email-masked]>
Date: Fri, 9 Mar 2012 14:23:36 +0700

> A separate but related question is whether "financial-protocol" folk need
> different underlying  protocols, for transport/transfer of this particular
> type of data and notifications, than what is extant (and implemented &
> shipping) today (e.g., HTTP, TLS/SSL, SCTP, XMPP, etc.).
>
> If not, then perhaps they might concentrate on the stuff at their
> "financial" layer and concoct "bindings" to the existing underlying stuff
> (eg, as we did in SAML & Liberty (to HTTP)) as appropriate, and they then
> could perhps more easily work on their "financial" layer whereever (eg, W3C,
> OASIS, SomeNew.org, etc).

I agree wholeheartedly with the suggestion of transport neutrality,
which I believe I raised earlier on this thread (possibly indirectly
through allusion to arbitrary topology support).  Each of the
transports mentioned above offers different properties in terms of at
least security, topology, wire-level efficiency and latency and for
this reason alone it would appear to be unwise to mandate one or more
possible transports for all deployment environments (whose
requirements will vary).

However, I am not certain that I can agree with the apparent(?) notion
presented that perhaps it then follows that the IETF is not an
appropriate venue for this development.

The rest of this email will address each of the previous efforts
raised by Dave and Jeff (thanks for taking the time to point these
out!) and summarize briefly why from my perspective they appear to
differ significantly from the proposed scope.

> RFC6017, Electronic Data Interchange - Internet Integration (EDIINT)
> Features Header Field
>
> RFC5402, Compressed Data within an Internet Electronic Data Interchange
> (EDI) Message T. Harding, E
>
> RFC1865, EDI Meets the Internet Frequently Asked Questions about Electronic
> Data Interchange (EDI) on the Internet W. Houser, J. Griffin, C. Hage
>  January 1996 ASCII  INFORMATIONAL
>

Scope is EDI.

Without passing judgement on any one of the various EDI standards that
are apparently floating about these days, my own perspective is that
at its core EDI tends to differ significantly in scope from the
proposed scope of financial transactions, largely because EDI's focus
appears to be on "big corporate" and government business level
metadata and processes (invoicing, purchase orders, etc...) that do
not necessarily apply to all or even most financial transactions on
the internet today, such as those involving individual consumers.

As a result of this key difference, EDI systems tend to prevent or
constrict the expression of possible financial settlement level
concerns, and have little motivation to accomodate or consider
alternative systems that may be based upon either non-currency value
exchange or non ISO4217 currency exchange such as Ripple, CES, LETS,
Bitcoin, etc. In short, from an EDI perspective, it would seem that
(in *most* cases?) the settlement of financial transactions is
essentially an external process.

In addition, documents like http://tools.ietf.org/html/rfc5402 delve
in to concerns such as security (authentication, integrity and
encryption) that an alternative protocol designed now (from a
message-oriented perspective) might well be able to delegate in whole
or in part to the transport layer.

The proposed scope could be seen to support EDI in that it could
potentially provide higher reliability, lower cost, transparently
redundant (supporting business continuity / disaster recovery goals),
or otherwise more attractive settlement functionality to complement
existing EDI systems.  In addition, EDI information could potentially
be bundled within financial transaction related messages in order to
provide both information relevant to settlements and higher level
metadata where appropriate.

> In addition to the previously mentioned EDI and IOTP work, there was also
> this back in the late 1990s..
>
> CyberCash Credit Card Protocol Version 0.8
> http://tools.ietf.org/html/rfc1898

Scope is basically credit cards. It is also interesting to note that,
apparently at the time of writing, their centralized registry of
message types exceeded 100 (getting rather messy... maybe the approach
was not high level enough to be portable to an internet sized
community, re: most of these were probably necessitated by legacy
system integrations and there was no mechanism for abstracting them
away at the higher conceptual level of a 'financial transaction'...).

> ECML v1: Field Names for E-Commerce
> http://tools.ietf.org/html/rfc2706.txt
>
> ECML v1.1: Field Specifications for E-Commerce
> http://tools.ietf.org/html/rfc3106.txt

Scope is HTML (user interface) oriented; a totally different problem
domain. Also limits scope further to credit cards.

> ..and then fwiw, it's not clear what happened to these expired I-Ds..
>
> http://tools.ietf.org/html/draft-eastlake-internet-payment-01
> http://tools.ietf.org/html/draft-eastlake-universal-payment-02
> http://tools.ietf.org/html/draft-hallam-micropayment-00

'draft-eastlake-internet-payment-01' is one of the most relevant
historic efforts under review to the proposed scope. It specifies a
character string syntax to (1) indicate prices and acceptable methods
of payment, (2) tender payment, and (3) issue a receipt acknowledging
payment or notification if payment fails.  It could be considered an
early attempt at the same problem space. Some issues: ISO4217 limited.
Includes settlement path specification with boolean 'or' logic (no
other). Encourages payment information to be sent over insecure
transports. Vague (re: partial payment, what is a 'payment system',
estimates, ceilings, receipt delivery mechanisms, etc.). HTML
integration concept predates the tendency towards pixel-perfection in
the modern 'browser as a platform'-world and would be harder to
propose today. Receipt implementation appears to have skipped
consideration of non-realtime settlement (ie: ACH, SWIFT, etc.).

'draft-eastlake-universal-payment-02' attempts to provide header-based
negotiation of common 'payment systems' between clients and servers
(merchants) to facilitate simple payments, mostly in the language of
online shopping from a browser. This is potentially interesting but
has issues: Confuses actual financial connectivity and payment systems
(which often act as gateways to others), strong B2C + centralized
settlement system (legacy) focus, examples appear to request that
consumers might provide personally identifiable information prior to
purchase, lack of metadata.

'draft-hallam-micropayment-00' is one of the most relevant historic
efforts under review to the proposed scope.  It is an unfinished
proposal for a payments system based upon a
customer-(single)broker-vendor model, primarily concerned with
micropayments. It is relatively holistic and well considered, but
appears to fail to delineate clearly between aspects of financial
instruments (eg: currencies) and those of financial settlement
networks (eg: party authentication, message non-repudiation) in its
incomplete risk model. Its forward looking proposal to formally
describe multiple settlement paths with different temporal, risk, or
other characteristics is very much similar to the approach that we
have had under consideration and have been developing at Payward Inc.
since late 2011.  However, the proposal also descends in to specific
cryptographic algorithms instead of maintaining a pluggable
architecture which is apparently often considered 'bad practice' in
higher level protocol design today. It is also rather centralized and
insecure: "requires perfect trust between servers acting as brokers.
Compromise of one server compromises all others."

Considering all of the above proposals, at one end we have EDI focused
on business level metadata surrounding actual financial transactions,
and at the other we have draft-eastlake-internet-payment-01 that
attempts to strip out all metadata and simply negotiate prices and
paths for external execution of settlements through a finite
vocabulary of intermediary 'payment systems', conveniently ignoring
the potentially complex realities of said systems.

In summary - whilst interesting at points - none of the historic
financial related proposals target the same problem domain. Most
importantly, none can adequately describe the breadth of financial
transactions occurring over the internet today.

>From my perspective, what is sorely needed is instead an adequately
descriptive (yet extensible/flexible) protocol based not upon a
specific integration point within the existing standards
infrastructure (examples in the historic documents above included HTTP
headers, SMTP, etc.) but rather a transport neutral message-oriented
protocol that is concise and minimalist enough to be deployed readily
yet robust enough to be deployed for any conventional (interbank
payments, credit card payments), specialist (high frequency trading,
non-currency value exchange such as the Energy Working Group member's
idea regarding possible use for energy costs and trading, 'exotic'
(ie. non US / credit card centric)) or emerging (mobile, digital
currencies such as bitcoin, ripple) use case.

There has clearly been thought in this direction previously but
nothing adequately broadly based and flexible with the potential to
tie things together without excluding significant, interesting,
valuable and emerging parts of the community.  Perhaps it is now the
right time to solve this problem?

Regards,
Walter Stanish
Payward, Inc.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 09 Mar 2012 05:14:34 -0800

>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Walter
...
> John may have different advice, but I typically refer people to RFC4677 (http://tools.ietf.org/html/rfc4677, "The Tao of IETF").

That's a good introduction for an individual wishing to participate in the IETF. 
  Anyone new to the IETF should read it.

I think the challenge here is also giving guidance about starting an IETF 
activity. The closest document for that, I think, is:

    Considerations for Having a Successful Birds-of-a-Feather (BOF) Session
    http://tools.ietf.org/html/rfc5434

A pre-wg isn't a BOF, of course, but it's got quite a bit in common.

d/
-- 

   Dave Crocker

---

From: "John Levine" <[email-masked]>
Date: 9 Mar 2012 14:17:47 -0000

>one might try to focus on avoiding bureaucratic discussion

I'll take that as "no".

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 09 Mar 2012 09:23:38 -0500

On Friday, March 09, 2012 04:31:35 AM John Levine wrote:
...
> preference for running code.

Although DNS provisioning systems seem to be a notable exception to this rule.

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Fri, 9 Mar 2012 09:46:55 -0500

But here's what worries me (and, again, remember that I'm pushing back
to probe for answers, not as a way of saying "no"):

You're saying that you want to define a new application-layer protocol
(I have no idea what "legacy-free" means) that handles the use cases
you list.  That seems like a very fine thing to want to do.

It strikes me, though, that the denizens of the IETF know little to
nothing about the needs of those applications and use cases, and that
you're likely to encounter some or all of the following problems:

- There will be many nuances, corner cases, and unrecognized
underlying needs that will not be considered in the protocol design
because you'll have a lot of protocol designers but not enough
subject-matter experts.

- You (plural, not you personally) will get very frustrated by people
with experience developing things like LDAP and CoAP and SIP (and,
worse, MPLS and BGP) poking and prodding and telling you that you have
to do this and you can't do that.  Some of it will be valuable input
that you ought to get, but lots of it will be relevant marginally or
not at all.

- Because people don't know much about your field and your use cases,
you will get a lot of people telling you what the working group
charter has to look like, but then very, very few people participating
in the working group, to the point where it will be hard to make real
progress.

The IETF works best when it looks at core Internet protocols and
application protocols with broad applicability (such as SIP, HTTP, and
CoAP) and those that apply to Internet-related functions (LDAP, SMTP,
ALTO).

Looking at the other side, if the IETF can do this, what you'll get is
a bunch of people who know protocol design and can help you get it
right, and who know how to secure Internet transactions.  You
definitely need that.

Barry

---

From: Walter <[email-masked]>
Date: Fri, 9 Mar 2012 22:31:31 +0700

> to probe for answers, not as a way of saying "no"):

OK. Thank you for your constructive response.

> you list.  That seems like a very fine thing to want to do.

Great, and a fair enough point on semantics.

> nothing about the needs of those applications and use cases,

The proposal is made more in the spirit of establishing a mailing list
to invite community participation from people with parts of said
knowledge (as opposed to grabbing some people on an IETF list like
this one and somehow cajoling them in to being motivated to study
financial industry protocols and trends.)

The impression right now is that the formal establishment of any IETF
working group, BOF or such at some future point is an option but not a
requirement.  Therefore, right now we're just asking for a mailing
list to gather people and ideas in one place.

> and that

This is a risk with any system, ie. not limited to the field of
protocol design. There are proven ways to avoid such problems:
 (a) seek input from many parties
 (b) avoid non-critical assumptions within the design ("do one thing
and do it well")
 (c) provide a means of extensibility that might in future be used to
resolve nuances, corner cases and unrecognized underlying needs

The current proposal for a mailing list is in fact made in support of
method (a).

> that you ought to get, but lots of it will be relevant marginally or

The assumption has been that subject matter experts and finance
oriented programmers recruited from communities like Bitcoin and
Ripple are expected to be larger features within the mailing list than
veteran protocol authors who may be largely or wholly unfamiliar with
the specific area in question and whose input will be valued at a
later stage.

> in the working group, to the point where it will be hard to make real

This all sounds very much like: "Mailing list - low overhead. Working
Group - high overhead."  The present proposal is for the former, and
for reasons similar to this.

> right, and who know how to secure Internet transactions.  You

Perhaps the formalistic side of the IETF's grizzled core expertise
might be more valuable when applied to, for example:
 (1) the design of bindings between a message oriented application
layer financial transaction protocol that comes out of the mailing
list in question (either formalized through a later formed BOF or WG,
or not) and various available transports (as per JeffH's suggestion).
 (2) the design of optional security related extensions for the same

Both of these areas strike me as best approached at some later stage,
for example after discussions have occurred on the proposed list.

Regards,
Walter Stanish
Payward, Inc.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 09 Mar 2012 07:58:28 -0800

On 3/9/2012 6:17 AM, John Levine wrote:
>>> �Anyone likely to implement it? �The IETF has a well known

expecting code to exist even before pre-standards work has been discussed seems 
a tad excessive.

on the other hand, having a clear problem statement and clear statement of 
desired output -- or in the alternative, questions intended to produce those 
clear statements -- is more typical for pre-standards discussion lists.

absent those, there is no substantive anchor for the discussions.

d/

-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 09 Mar 2012 15:59:51 +0000

> for example after discussions have occurred on the proposed list.

IMO "optional security extensions later" for this would be a bad,
and in the IETF, unlikely, plan if it came to developing a protocol
like this.

I've no opinion on whether this ought be done, here or anywhere,
but if done here, I do have an opinion on when security needs to
be tackled.

S

---

From: Walter <[email-masked]>
Date: Sat, 10 Mar 2012 06:46:23 +0700

> but if done here, I do have an opinion on when security needs to

Fair concern.  Let me explain the source of the comment.

During research thus far it has been discovered that certain financial
transaction systems are stupendously latency sensitive to the point
where mandatory security processing is unacceptable.  Thankfully, said
systems may operate between known parties (even parties internal to
one organization) via trusted transport and physical layers.

This is not to say that more typical internet style approaches to
protocol security would be ignored; far from it, they would be the
norm rather than the exception. Simply in an effort to avoid
additional assumptions within the design (see strategy (b), previous
email), it is considered desirable to maintain the protocol's ability
to switch off, or optionally delegate authentication and integrity
services to lower network layers.

Regards,
Walter Stanish
Payward, Inc.