Ballot for charter-ietf-satp
Yes
No Objection
Abstain
Note: This ballot was opened for revision 00-03 and is now closed.
Ballot question: "Do we approve of this charter?"
# 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.
I share Lars Eggert’s concerns. The scope of the charter provides no bounds on the use cases. The charter hints at “property ownership certificates, and regulated government-issued digital currencies” as possible markets. None of these are areas where the IETF currently has expertise. Both BoFs and subsequent conversations have not shown a strong demand signal or participation from operators of these classes of digital asset.
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
# GEN AD review of charter-ietf-satp-00-03 CC @larseggert I remain highly skeptical that the IETF has breadth of participants with the necessary expertise in this space. ## Comments ### Chairs Will there be a second chair? ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool