Secure Asset Transfer Protocol
charter-ietf-satp-01

# Internet AD comments for charter-ietf-satp-00-03
CC @ekline

## Nits

### Paragraph 2

* "The resulting protocol that will be agnostic with respect to
   the type of asset being transferred although."

  This doesn't scan well to me.  Was the intention something more like:

  "The resulting protocol SHALL be agnostic with respect to the type of
   asset being transferred."

“SATP will reuse existing IETF standards for various aspects of the protocol
modes, including but not limited to secure channel establishment (TLS), payload
formats (e.g., JSON, CBOR, ProtoBuf, etc.)”

Did I blink, and protobufs are now an IETF standard? Can someone please point me to the RFC? 

(Also, what Zahed said.)

I am also skeptical about this working group. However, I think we should try it out and hopefully this will bring more new attendees and broaden the operating scope of topics in IETF.

Overall, I'm in the same boat as Zahed: "I am also skeptical about this working group. However, I think we should try it out and hopefully this will bring more new attendees and broaden the operating scope of topics in IETF."

One nit/annoyance on the charter:

A key requirement for transferring assets is ensuring that the digital asset is
valid in one network only at any given time. This means that SATP must ensure
that the properties of atomicity, consistency, isolation, and durability (ACID)
of the underlying networks are satisfied in an asset transfer. Commitments and
rollbacks must be supported in the case of an asset mid-transfer failure.

Rob:
I'm still not keen on the first sentence - broadly because I don't think it is possible to build a distributed system that conforms to this constraint.  E.g., when the transaction fails at one of the gateways at commit time, then until recovery has occurred then you will either end up in state where either (i) the asset exists in both networks at the same time, or (ii) the asset is present in neither network.  I presume that you can design a transaction protocol such that in the worst case (i) or (ii) always happens, but I don't believe that you can provide an absolute guarantee, that at *any given time*, neither of these two things can ever happen.

Regards,
Rob