Scribe: Orie Steele
Chair review has uncovered a few critical issues to address.
Thomas: agree we need to specify the enumerations. Where would an IANA
table go?
Wes: We would create it in the document, describe the initial contents,
guidance to experts and registration policy.
Wes: We need to review all fields to ensure that the are fully
specified.
Alexandru: There are 2 implementations, do we need a table for
implementations?
Wes: what exact field needs things in an IANA table
Alexandru: We may need to add more locks in the future.
Peter: I'm happy to shepherd the documents.
... I contributed enough to become an author, so I can not shepherd (the
use case doc).
Wes: Chairs will discuss we have options to shepherding.
Orie: make sure you have multiple implementations that want to implement
each new charter item / feature. Need strong support for multiple
parties for it to be added. What is needed for an IETF protocol vs
within a single software boundry
Bing: We wanted to address a scenario related to data sharing, beyond
asset transfer... Can we discuss data sharing? How do we attach metadata
to transfers?
Thomas: We need to define asset IDs, and network identification... A
transfer context data structure... breaking apart stage 0.
Rama: We mention datasharing in architecture... there are drafts that
describe some parts of this in stage 0.
Claire: Data is an asset type, seperate from metadata.
Denis: Registry, also called API 3 in the past... Requirements for the
network.
Hyojin: I would like to consider the imp guide in scope for the
chartering discussion.
Claire: Should requirements be for the network or the gateway? Do we
need a document for the threat model?
Mike: I would like to see an implementation guide... and deployment
guide for assert transfer.
Wes: We don't have ops or BCP yet, so we can consider guidance within
the group.
Rama: Where are the requirements, for the gateway or the network?
Wes: The gateway seems to be responsible for requirements.
Peter: Regarding asset ID, is this negotiating an id or specifying a
structure?
Thomas: There is currently no standard for identifying assets... This is
being discussed in drafts.
Peter: There are structures out there... stage 0 is important (to
interop really different asset systems (non-blockchain to blockchain)
but wants to interop)
Denis: Regarding network vs gateway... We assume networks do not know
about gateways... We might be interested to understand requirements on
the networ, and not just the gateway.
Wes: Chair will discuss and expand these topics, and then help
prioritize them on list.
What information is needed in order to start a transfer in the first
place?
Pre transfer context setup, and interaction with gateway and network...
the blue part is stage 0 or setup phase.
Peter: ContextID... is relevan to data as an asset... it describes the
rules for how data should be used. We should avoid stepping on use
cases.
Thomas: When things move, do their IDs change. The addresses change, but
do the asset IDs change?.. The requirement to have a single unique
instance constrain the asset ID problem.
Wes: Doesn't this constrain networks that could be in scope? Doesn't
this limit which networks could be in scope? Are there security issues
with the network that could violate these requirements.
Thomas: We need to consider the bigger picture.
Wes: hashing algorithms are not permanent.
Denis: traditional systems have other forms of storing information, such
as in databases etc that may have their own locally unique storage. The
asset in some places may reside inside a smart contract, eg. AssetIDs
really need to be a global ID that can be tracked no matter where it is
and within what network.
Thomas: Gateway needs a way to describe the current state of assets in
networks, including if they are disabled.
Denis: gave a detailed discussion of how an initial stage-0 flow might
occur, along with an example JSON encoding of a transfer context
structure. Also included a list of things that was achieved by the
execution of stage-0 -- what did each side know at the end of the negoti
Peter: What about the IP network? Can the context include the IP network
information? or is this agnostic to IP network?
Denis: We call the IP network endpoints in the Context structure.
Wes: SATP is mostly about asset networks... We might consider a
terminology document as well.
Thomas: The next section is about asset "disablement"
Rama: [describes views and data sharing]
Wes: Is the structure of why views are needed described in the document?
Rama: Why views are needed is related to ledger state.
Hyojin: Good to see SATP in use since it seemed for a while no one cared
about how to transfer assests. This is important for cross-border
payments. Need multiple open source implementations in order to
facilitate delpoyment. Started draft-song-satp-implementation-guide.
Wants to develop a simple library as well. Would like feedback as well.
Rama: There are multiple implementations for Cacti. Are you going to
talk about implementations or just how to setup and maintain gateways?
Hyojin: I'm considering guidelines about how to integrate both as an
administrator.