Secure Asset Transfer Protocol
charter-ietf-satp-01

[Ballot comment]
“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.)

[Ballot comment]
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

[Ballot comment]
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.

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

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
# 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

[Ballot comment]
# 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."

[Ballot comment]
# Internet AD comments for {doc-rev}
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."

[Ballot comment]
As already noted in Éric Vyncke’s ballot, this work seems misplaced in Security.  There are few or no security elements specified in the scope of this charter.  During the BoF, most security considerations were deemed out of scope.  The crux of the standardization appears to be an application protocol.  The ART area will likely have more expertise on this topic.  Their engagement will be essential for success.

** It would be helpful to explicit state that SATP is agnostic to the which digital asset network can carry, or if there are any prerequisites for the asset networks, what they might be in very broad strokes.

** Objective
There is currently an interoperability problem in many digital asset networks,
where assets in one network cannot be moved easily to another network

Is the key issue that there is a lack of standardize protocol?  It isn’t clear if the ease of movement across network is a technical, operational or policy problem.

** Objective
The
problem is more acute in the case of private asset networks, where external
entities have no visibility into the state of an asset in the private network.

Is this a problem the WG will be solving?  Is visibility defined as auditing the transfer of assets?

** Problem space and architecture
Each gateway represents one network or system ...

The text in the objective used “digital asset network” or “network”.  In this section, text is using "network or system”, please be consistent.

** Problem space and architecture
... and the SAT protocol performs a
voluntary transfer of a digital asset from the origin network to a destination
network in such a way that evidence of the transfer can be verified by a
third-party audit in the case of disputes.

-- is it “SAT protocol” or “SATP”?  The rest of the text uses SATP

-- It’s the gateway that performs the transfer using SATP.

** Problem space and architecture

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.

As I understood the discussion at the BoF, guaranteeing these ACID and rollback properties will require cooperation from the digital asset network.  The means to realize this cooperation is out of scope.  Please be clear on the dependency that SATP might have on the asset network.

[Ballot comment]
The text should be better formed (like noted by Lars).

More important in "among the above three protocol modes", I am unable to find the related three protocol modes in the text above.

Wouldn't this WG better fit the ART area ? (baring workload balancing)

Is a 'broker' gateway (acting as a proxy between gateways) in scope ?

-éric

[Ballot comment]
# GEN AD review of charter-ietf-satp-00-02

CC @larseggert

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Bad line-wrapping?

#### Paragraph 2
```
- network to a beneficiary in destination network. Problem space and architecture
-                                                -------------------------------
```

#### "A", paragraph 0
```
- rollbacks must be supported in the case of an asset mid-transfer failure. Scope
-                                                                          ------
```

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

[Ballot comment]
# Internet AD comments for charter-ietf-satp-00-02
CC @ekline

## Comments

### P2

* Is "recipient" an equally valid word in place of "beneficiary"?  If not,
  why not?

### P4

* "assumed to share a common understanding of the digital asset"

  Why is this important?  What is lost/what meaningfully changes if the
  gateways treat the transferred entities as opaque byte strings?

  Paragraph 6 says that the token validity must be unique to only one
  network at a time.  Is this a required function of the gateway, or is
  this a function that might be separable into another, closely associated,
  functional element (even though most implementations might not separate
  these functions)?

  (This question is clearly born out of my ignorance of the problem space.)

## Nits

### P2, P6

* The final sentence looks like the section title for the next section?

### P12

* Protobufs are not an IETF standard (not even ISE-published).  Seems fine
  to consider protobuf as a candidate, but the sentence as written seemed
  to imply a list of IETF technologies, specifically.