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

[Walter <[e-mail]>]

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

OK. Thank you for your constructive response.

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

Great, and a fair enough point on semantics.

> It strikes me, though, that the denizens of the IETF know little to
> 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
> 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.

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

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

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.

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

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.

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

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.