►
From YouTube: IETF-SATP-20230711-1400
Description
SATP meeting session at IETF
2023/07/11 1400
https://datatracker.ietf.org/meeting//proceedings/
A
D
Yeah
I
think
I
think
we
could
just
you
know:
Paul
just
discuss,
updates,
Maybe
and
maybe
talk
about
what
we
plan
to
do
at
San,
Francisco.
B
It's
pretty
quick.
We
can
get
our
agenda
so
at
the
moment
I'm
working
on
making
the
vocabulary
document
into
a
draft
on
the
way
we
discussed
in
one
of
the
previous
meetings.
B
So
it's
going
to
be
a
separate
item
rather
than
just
an
appendix
on
on
one
of
the
other
drafts
and
as
soon
as
soon
as
I'm
done
at
the
moment,
I'm
struggling
a
bit
with
the
XML
draft
drafting
process,
but
as
soon
as
I'm
done,
I
will
send
an
email
on
the
mailing
list
for
review
and
yeah
feel
free
to
add
any
any
contributions
to
it.
But
that's
that's
about
it.
So
I
expect
an
update
on
the
vocabulary
in
the
next
couple
days
to
the
mailing
list.
A
E
D
C
D
Thank
you,
I
I
received
it
I'm
going
to
work
on
it
today,
but
I
just
realized.
The
the
cutoff
date
for
uploads
of
drafts
was
yesterday
so
there's
a
kind
of
moratorium
until
I
guess
the
Monday
of
the
ITA,
but
but
I.
D
Okay,
so
so
that's
that's
fine,
so
Rama
I'll
try
to
upload
it
like
the
the
Monday
of
that
week,
so
that
but
I
don't
think
it's
significant
changes.
It's
more
like
you
know,
we've
added
text
on
the
iso
and
we
understand-
and
it's
interesting
folks
actually,
if
you
guys,
are
interested
the
bis
backup,
International
settlement
has
just
published
there,
I
think
annual
or
six
monthly
report
and
there's
a
particular
section
on
on
this.
D
You
know
related
to
this
problem
and
the
fact
that
the
current
messaging
scheme-
you
know
I
mean
even
they
recognize
that
the
current
ISO
you
know
messaging
is
not
enough
that
it,
you
can't
do
you
know
tokenization
with
just
messaging.
So
so
we
can.
You
know
if
people
are
interested.
Send
me
email,
I'll,
send
you
the
link
to
the
the
PDF
I'll,
send
you
the
PDF
all
together
and
you
can
have
fun
reading
it,
but
yeah
so
I
think
we're
on
the
right
track.
A
Yeah
I
I
have
to
push
an
update
to
see
the
use
cases
draft
as
well,
but
I
guess
I'll.
Do
it
by
on
the
Monday
of
the.
C
D
Okay,
great,
thank
you
Raphael.
Let
me
go
first
and
then,
when
we
get
to
the
section
on
session
resumption,
maybe
you
can
jump
in.
D
No
folks,
I'm
gonna,
try
and
share
my
screen,
which
is
the
version
19
of
the
message
flow,
which
is
on
the
GitHub
repo,
and
let
me
help
me
hang
on
how
do
I
actually
share
my
screen.
D
Actually,
you
know
what
maybe
it's
easier
if
everyone
just
goes
to
the
repo,
maybe
somebody
can
post
the
link
to
the
repo
and
and
look
at
the
diagram,
and
if
you
and
I'm
asking
a
lot
just
look
at
the
diagram,
if
you
really
want
to,
you
can
also
open,
sat
core,
which
is,
if
which
is
a
match
now
with
the
diagram
minus
some.
You
know
one
two
words
that
are
erroneous.
D
So
if
you
look
at
version
19
of
our
color
message
flow
diagram,
you
will
see
that
the
transfer
commence
message
and
the
acknowledgment
for
that
message
has
been
moved
up
to
stage
one.
So
that's
that's
sort
of
the
first
big
change,
and
so
the
reason
being
was
that,
as
Alex
pointed
out
correctly,
it
was
kind
of
awkward
to
look
at
this
transfer
comments
in
in
stage
two.
D
When
really
the
purpose
of
stage
two
was
to
do
the
Locking
and
to
deliver
the
assertion
for
the
Locking,
and
so
you
know,
logically
in
terms
of
functional
grouping.
Yes,
it
makes
sense
to
exclusively
Focus
stage
two
on
just
the
the
lock
and
the
lock
lock
assertion,
and
therefore
it
also
kind
of
makes
sense
that
all
all
the
preparation
and
and
all
the
the
agreement
to
proceed
between
G1
and
G2
really
need
to
happen
in
stage
one.
D
So
if
you
look
at
that
diagram
and
if
you
look
at
sad
core
version
02,
which
I
updated
two
days
ago,
you'll
see
now
now,
there's
a
transfer
proposal
claims
section
so
so
that
is
basically
putting
together
all
the
information
that
that
G1
and
G2
need
to
agree
upon
in
a
set
of
you
know,
proposal
claims
you
know
so
that
includes,
if
you
look
at
the
set
core
that
includes
things
like
Alice's
verified
added
in
the
Bob's
verified
identity.
Alice's
address
Bob's
address.
D
So
imagine
if
you
had
to
move
this,
you
know
a
regulated
asset.
This
is
the
kind
of
set
of
information
that
G1
and
G2
as
the
owners
and
operators
of
the
gateways
will
need
right.
So
so
that's
I
think
is
now
section
7.1
on
the
sap
core
draft
zero
two
and
the
diagram,
the
color
flow
shows
dotted
Circle.
So
so,
basically,
this
is
a
a
you
know:
multi
it
could.
It
could
be
a
monthly
around
negotiation.
D
So
G1
says:
hey
here's
the
set
of
claims
that
I
think
you
can
accept
and
G2
might
say.
Well,
hang
on.
A
second
you've
got
the
wrong
address
for
Bob
on
my
network.
So
that's
message
1.2
and
goes
back
again.
D
So
it's
a
loop
and
if
you
are
interested
in
deep
down
again
so
the
actual
messaging
start
in
section
seven
point
three:
you
know
what
let
me
open
up
actually
here
it
is
so
if
you
look
at
section
7.1,
that's
all
the
claims
pertaining
to
the
asset
and
I
added
a
new
section
point
two,
which
is
all
about
the
network
capability.
So
this
is
the
stuff
we
have
discussed
in
the
past,
such
as
well.
What
locking
mechanism
is
being
used
in
Network
one?
D
How
long
is
the
standard
you
know?
Average
luck,
duration
in
so
so
7.2
is
really
Network
specific
and
G1
and
G2
are
talking
about
their
own
Networks
and
so
the
set
The
Logical
separation
of
the
asset,
related
claims
and
the
network,
specific
information
or
network
capabilities
claims
is
seven
one
and
seven
two
two,
and
so
really
the
flows
start
in
7.3.
7.4
is
the
loop
and
7.5
and
7.6
is
just
a
way
to
G
G2
to
say,
accept
or
reject.
D
So
if
G2
says
okay
I,
like
the
claims
that
you've
just
sent
me
and
I
wish
to
proceed,
then
G2
has
to
has
to
explicitly.
You
know,
do
a
an
acceptance
message
right.
D
So
this
would
be
7.4
transfer
proposal,
receipt
message
so
so
G2
has
to
include
a
hash
of
the
set
of
claims
and
say:
yes,
I
accept
this,
and
this
has
to
be
explicit
now,
one
way
that
I've
introduced
in
seven
point
five
to
two
to
actually
do
the
loop
thing
and
feel
free
to
improve
on
7.5,
because
there
might
be
better
mechanisms
to
do
this.
If
G2
says,
okay,
you've
got
everything
correct,
90,
but
I
want
these
things
updated
or
modified.
D
Then
G2
will
send
a
conditional
reject
it's
conditional
and
here's
a
set
of
alternative
claims
that
I
am
proposing.
So
it's
a
counter
proposal
and
the
text
talks
about
a
counter
proposal
so
counter
proposal
and
then
back
again.
Here's
a
updated
repeat.
You
know,
transfer
proposal
message
so
this
this
Loop.
Now,
if,
if
G2
says
okay
I'm
good
to
go,
then
he's
going
to
say
explicitly
proposal
receipt
message
is
digitally
signed.
If
G2
decides
to
give
up,
okay,
I
I'm,
tired,
I
I
want
to
go
away,
you
know
and
you
go
away.
D
G1,
it's
gonna,
send
a
transfer
proposal,
reject
which
is
the
same
structure
except
the
proposal
field
is
blank,
there's
nothing
in
it.
So
it
signals
to
G1
that
that
G2
is
giving
up
and
and
terminate
session,
and
this
is
where
the
the
errors
messages
section
down
below
make
sense,
because
this
is
a
graceful
termination.
It's
not
a
protocol
error.
It's
G2,
saying
I
I
want
to
quit.
D
So
so
that's
kind
of
the
progress
that
we
made
and-
and
this
came
basically
from
a
side
discussion
that
a
group
of
us
made
a
couple
of
weeks
ago.
You
know
on
a
separate
Zoom
call
which
I
think
was
was
announced
and,
and
there
were
five
six
of
us-
and
you
know
we
talked
about
this-
and
this
is
this-
is
stage
one.
D
Any
any
questions
about
stage
one.
A
D
A
Good
but
one
more
thing
about
the
how
the
gateways
should
I
think
negotiate.
This
I
mean
if
a
Gateway
gets
a
counter
proposal.
They
are
not
saying
how
it
should
handle
the
counter
proposal
thing
and
whether
it
should
decide
by
itself
whether
to
accept
the
counter
proposal,
reject
it
or
should
go
back
to
the
network.
We
are
not
saying
that
that's
between.
D
Right,
it's
out
of
scope
for
us
and
in
fact
this
is
part
of
the
discussion
that
I
think
Dennis
wants
to
have
have
about
the
context.
This
is
the
application.
The
application
thing
right
that
that
really
the
the
application
is
already
already
knows,
which
asset
and
asset
type
and
so
on.
I
think
Dennis's
point
was
that
The
Proposal
needs
to
include
the
asset
profile
ID,
it's
just
the
ID
number
of
the
Json
document
that
defines
the
asset.
D
A
Bit
of
background
material,
that
I
mean
I
I
did
some
work
back
in
a
PhD
on
this
kind
of
negotiation,
and
it
was
based
on
the
two
sides
having
their
own
policy
databases,
and
when
you
get
a
counter
proposal,
you
match
it
against
your
policy,
see
if
it
is
an
accepted
and
or
whether
you
need
to
set
a
Content
proposal
and
also
there's
a
there's
work
done
in
the
grid
Computing
on
service
level
agreements.
So
this
is
kind
of
you
know
you.
Can
you
can
water
from
that.
D
Yeah
yeah,
so
so
Ramo.
Anyone
if
you
have
a
better
idea
of
how
to
do
how
to
express
this
Loop
proposal
except
reject
if
you
have
better
mechanisms,
feel
free.
You
know
to
suggest,
because
you
know
that
text
there
and
section
Point
7.3
proposal,
7.4
the
receipt
acceptance
and
the
7.5
yeah
that
that
that's
fluid
right
now.
You
know
we
can
change
that.
It's
just
a
way
of
saying.
Well,
if
somebody
asks
us
well,
how
do
you
do
this?
D
This
Loop
thing
right
which
which
I
think
to
be
honest,
I
I
did
not
look
at
how
ipsec
or
how
Ike
Ike
version
one.
Did
it
or
Ike
version
2?
Does
it,
but
it's
the
same
kind
of
model
that
in
in
act
there's
a
security
policy
database
at
both
ends
and
they
keep
on
looping
and
I.
Think
one
of
the
biggest
thing
is:
you
know,
for
example,
negotiating
the
algorithm
for
the
hash
right.
So
yeah
you
have
to
be
a
human.
D
We
we
today
conveniently
say:
oh
we'll
just
use
whatever
NIS
says
right,
but
it
could
be
that
specific
networks
have
a
different,
maybe
stronger
standard.
You
know
beyond
nist,
and
so
we
need
some
kind
of
a
way,
for
example,
to
identify
the
hash
algorithm
IDs,
which
is
already
standard
right,
so
that
we
have
to
communicate
that
yeah,
but
yeah
yeah
Rama.
If
you
have
any
alternative
ways
to
like
do
this,
Loop
yeah
happy
to
happy
for
you
like
to
to
you,
know,
recommend
it
sure.
D
Any
any
questions
about
that
particular
the
stage
stage.
One
changes.
D
Okay,
so
going
further
down
in
the
diagram
in
in
the
flow
diagram
version
19.,
so
at
our
thick
last
interim
meeting
and
also
subsequently
on
the
email
Alex
pointed
out
something
you
know
very,
very
observant,
very
good,
which
is
that
it
seems
that
the
in
the
old
previous
diagram
that
the
acknowledgment
prepare
message
was
redundant
like
why.
Why
is
it
there
right?
D
So
if
you
look
at
stage
three
now
who
have
a
commit
prepare
3.1
that
basically
signals
G1
to
G2,
you
know
you
know,
get
get
ready.
I've
agreed
on
the
lock
assertion
that
you
have
that
I've
indicated
I
I've
accepted
I'm,
accepting
it
and
I'm,
giving
you
a
signed
receipt,
and
so
now
GUI
says:
okay,
let's,
let's
begin
to
you
know,
prepare
to
to
commit-
and
this
is
the
the
classic
commit
prepare
message.
D
You
know
that
we've
stolen
from
the
database
world
now
the
ACT
prepare
for
those
who
don't
know
so.
The
original
two-phase
commit
three-phase
commit
in
the
database
was
a
was
a
one
coordinated
database
to
many
M
recipient
databases.
D
And
so,
if
you
had
like
three
databases
on
the
other
side,
then
then
the
coordinator,
which
is
in
our
case,
is
G1.
It
needed
to
receive
an
explicit
acknowledgment
from
all
three
and
that's
your
act
prepare,
but
since
we
only
have
one
recipient
Gateway,
so
it's
only
G2
G1
and
G2
it's
kind
of
redundant,
and
so
in
this
diagram
the
ACT
prepare
has
been
grayed
out
and
so
for
those
who've
seen
multiple
versions
of
this
diagram.
D
What
will
happen
is
that
it's
grayed
out
to
tell
you
that
when
we
update
this
diagram
next
time
to
version
20
that
is
going
to
be
completely
gone,
the
act,
the
great
the
great
ad
is
just
going
to
be
deleted
and,
as
you
you
know,
if
you
guys
are
Keen
enough,
you
could
see
all
the
previous
versions
going
back
to
you
know,
I
think
version.
Seven
was
the
sort
of
the
most
sort
of
it
had
feet.
D
D
You'll
see
ITF,
set
B
message,
flow
diagram,
asset
transfer,
unidirectional
one
sender,
one
receiver,
okay
and
the
message
we're
trying
to
say
to
people
that
okay,
we're
conscious
that
there's
only
one
sender,
Gateway
G1
and
one
receiver
G2,
and
if
people
have
you
know
in
the
future
ideas
about
you
know,
one-to-many
asset
transfers.
Great.
You
will
need
this
act
preparer.
You
know
you
bring
it
back
into
the
picture.
You
know
if
you
need
it,
but
for
now
that's
out
of
scope
for
sapi
we're
just
doing
unidirectional
one
to
one.
D
D
So
we
had
a
discussion
led
by
Dennis
about
the
fact
that,
even
in
today's
databases,
in
the
huge
you
know,
30
year
old
field,
well-studied
well-documented
mature
products
and
so
on,
there
might
be
very
edge
cases
where
there
it's
not
a
deadlock
is
deadlock
is
too
strong
a
word
that
that
the
protocol
gets
into
an
awkward
and
a
stuck
state
right.
Deadlock
is
too
strong,
and
so
the
message,
the
the
the
the
key
you
know
take
away
from
this
is
that
we
really
need
to
have
transport
reliability
for
3.5.
D
So
3.5
has
to
be
received
by
G2
right
and
so
in
the
case
that
that
G2
dies,
crashes
and
3.5
goes
unanswered.
What
will
happen
is
that
the
asset
has
been
extinguished
in
Network
one,
but
in
network
2
it's
been
self-assigned
to
G2,
so
G2
still
owns
it,
but
Bob
hasn't
received
it
right.
So
this
is
an
awkward.
It's
it's
it's
it's
an
awkward
said:
it's
gone,
it's
been,
it's
been
recreated,
it's!
Yes,
it
is
in
network
too,
but
it's
an
under
the
wrong
owner.
D
G2
is
the
owner
not
not
Bob,
and
so
it
may
need
manual
intervention
in
the
sense
that
Bob
knows
this
is
coming.
D
This
asset
is
coming
because
Bob's
application
is
waiting
for
it,
but
it's
still
stuck
at
G2
and,
let's
say
G2
crashes,
G2
needs
boot
up
and
say:
okay,
this
asset
is
is
self-assigned
to
me,
but
it's
really
needs
to
be
assigned
to
Bob,
and
so
then
G2
needs
to
assign
this
in
3.6
a
to
Bob.
D
So
so
the
AI
for
me
is
to
remove
the
word
deadlock
from
the
from
the
document
and
also
from
this
diagram,
because
it's
it's
the
wrong
word.
It's
just.
It's
called
a
heuristic
State
and
it's
kind
of
a
very
specialized
terminology
that
the
database
people
use.
A
A
So
then
G2
if
it
does
not
get
3.5
within
a
particular
timeout,
it
can
probably
just
give
up,
and
if,
if
G1
I
mean,
if
this
they
can't
follow
choose
to
follow
the
protocol.
So
if
G1
fails
to
submit,
send
a
3.5
in
a
way
that
it
knows
has
been
G2
and
the
timeout
is
passed,
it
knows
that
its
extinguished
should
be
reverted
and
G2
knows
that
it.
It
should
not
proceed.
So
that's
something
they
could
do.
But
of
course
it's.
There
are
many
different
kind
of
cases.
D
That's
right
so
so
the
point
of
this
is
to
communicate
to
the
reader
that
we
are
aware
of
this
very
edge
cases
right.
It's
almost,
you
know
a
contradiction
because
we've
said
from
the
beginning:
we
have
to
have
transport
liability,
so
you
know
3.5,
you
know,
G1
can
resend
3.5
multiple
times
right
until
G2
receives,
and
so
this
is,
you
know.
This
is
part
of
the
crash
recovery
that
you
know,
G2
or
G2.
D
Backup
needs
to
understand
that
it's
waking
up
from
a
crash
State,
and
so
so,
if,
if
we
number
one,
if
we
remove
the
case
of
message
loss
now,
messages
do
not
get
lost
today,
I
mean
none
of
my
Netflix
movies
ever
get
lost,
the
internet
is
so
reliable,
you
know
so,
assuming
you
know,
we
say
it's
got
reliability
that
really
it's
G2
crashing
that
that
is
the
issue,
although
of
course
you
could
have
a
Dos
attacks.
A
Dos
attacker
could
be
monitoring
this
and
say:
okay
at
the
right
point,
we're
gonna!
D
You
know,
you
know
flood.
You
know
G2
with
all
these
messages
to
make
it.
You
know
you
know
dysfunctional
basically
but
but
yeah.
So
this
is
this
is
also
part
of
the
session
resumption
that
we
need
to
handle,
and
in
and
Raphael
can
talk
about
that.
D
Maybe
after
this,
but
in
the
draft
a
court
the
course
had
version
two.
There
is
a
new
section
on
session
resumption
and
we've
we've
been
having
some
issues
with
the
the
diagram.
So
there
is
a
missing
diagram
in
in
the
text,
but
but
there
is
a
new
section
there.
D
If
you
look,
which
is
now
section
10
called
session
resumption,
so
Raphael
is
proposing
to
use
the
primary
backup
model
as
as
the
model,
it's
it's
the
easiest
one
that
is
two,
this
primary
backup
and
so
primary
backup
is
configured
to
understand
the
current
state
before
G2,
actually
crashes.
F
F
F
In
the
core
draft,
we
are
giving
considerations
on
how
to
do
the
recovery
itself,
so
the
recovery
itself,
it's
based
on
a
rather
simple
primary
backup
mechanism
that
Andrea
Augustine
I
studied
a
while
ago,
where
each
Gateway
on
the
setup
phase
defines
at
least
of
backup
gateways
so
in
the
form
of
public
keys
that
can
be
encoded
in
X
509
certificates.
F
If
the
next
time
I'll
expires,
then
the
counterparty
Gateway
initiates
a
robot
procedure.
So
we
introduced
the
rollback
procedure
when
the
crash
seems
permanent
or
when
it's
sensitive
to
issue
a
rollback.
Instead
of
waiting
even
more
for
the
crash
gateway
to
recover,
so
the
crash
Gateway,
we
we
can
assume
that
it
recovers
by
itself
called
the
self-healing,
but
we
focus
on
the
primary
backup
mechanism
because
it's
probably
more
reliable
and
we
can
also
add
parallelization,
making
it
more
efficient.
So
in
this.
C
F
Backup
mechanism,
the
crash
Gateway,
is
replaced
by
one
of
the
backup
gateways
that
were
accorded
in
the
beginning
with
the
counterparty
Gateway
such
Gateway.
One
of
them
identifies
itself
to
the
counterpartic
Gateway
that
didn't
crash
and
and
they
can
resume
the
process
from
there.
We
defined
a
few
messages
for
that
information
flow
to
to
be
exchanged,
which
is
the
recover
recover,
update
and
recover
success
messages.
F
So
when
a
Gateway
crash
title
recovers,
it
sends
a
recovery
message
to
the
counterparty
Gateway.
It
informs
the
counterparty
K2
of
its
most
recent
State,
the
specific
certificate
information
that
the
counterparty
needs
to
verify
the
identity
of
this
new
Gateway
because
note
that
the
recovered
Gateway
is
a
backup
Gateway.
It's
not
the
original
Gateway
so
session.
F
F
Let's
say
the
Align
state
after
the
crashes.
So
there
is
a
computation
step
which
computes
the
latest
state
after
the
crash
and
after
the
the
crashed
Gateway
now
the
recovery
Gateway
computes,
the
latest
State,
then
it
sends
the
recover
success
message
and-
and
both
gateways
at
this
point
are
agreeing
on
the
same
state
after
the
crash
so
that
they
can
resume
the
setup
process.
So
this
is
the
underlying
idea,
we'll
still
have
to
add
a
few
drafts.
F
We
had
some
formatting
issues,
hopefully
we'll
resolve
this
soon
and
and
adding
a
bit
more
details
about
these
these
techniques,
so
the
they're
quite
well
documented,
or
rather
documented
in
detail
in
an
academic
paper
that
Andrea
August
lab,
but
we
need
to
Port
some
of
those
details
to
this
document
and
also
the
crash
recovery
document.
D
So
so
Raphael
the
the
plan
is
for
you
to
be
presenting
in
San
Francisco
right,
you're
gonna,
you
know
he's
got
slides,
let's,
let's
just
say
so
so
so
we
have.
Probably
you
know
a
more
extensive
discussion
about
about
this.
D
Yes,
and
and
probably
it's
worth
explaining
to
folks
who
are
not
following
this
closely,
the
the
mechanism
to
actually
recover
and
so
on
currently
is
out
of
scope
right.
It's
the
the
thing
that
the
scope
is
the
the
the
arrows
in
between
the
the
two
columns,
but,
like
the
context,
ID
context,
setup
discussion,
we
need
the
core
to
be
informed
by
at
least
some.
You
know
within
some
crash
recovery
scheme
or
architecture
that
informs
sat
core
and
so
Raphael's
picked
one
which
is
the
easiest
one
which
is
primary
backup
right.
D
But
but
if
you
are
interested,
I
know
Raphael
and
and
Andre,
they
have
papers
academic
papers
that
talk
about
all
sorts
of
kinds
of
other
schemes,
Paradigm
schemes
to
do
recovery
for
gateways.
D
There
is,
there
is
a
section
in
so
when
we
talk
about
session
resumption
in
section
10
again
it's
it's
the
first
text.
You
have
that
you
know
so
the
idea
would
be
there's
a
G2.
Would
wake
up
or
G2
backup
due
to
Prime
will
back
will
wake
up
and
say:
hey
I
want
to
resume,
and
so
the
question
is
what
does
G2
backup
tell
G1
in
that
resume
message?
D
So
there's
at
least
we've
identified
like
three
possible
Flags,
which
is
in
in
capital,
letters
there
in
section
10,
which
is
recover,
recover
update,
and
then
the
response
will
recover
success
right.
So
so
we're
we're
Limited
in
the
current
scope
to
just
have
two
messages
that
can
also
loop
around
right.
There's
the
I
want
to
resume
resume
request
and
then
G1
and
say:
okay,
yes,
let's
resume
because
G1
can
say:
okay,
hey
you've
been
silent
for
60
seconds
I'm,
giving
up
right
that
that
will
also
be
the
default
behavior
of
G1
right.
D
This
is,
you
know
worst
case
scenario
G1,
but
is
there
a
way
for
us
to
inbuild?
Just
a
a
simple
message:
message:
sort
of
two
message
to
three
message:
addition
that
we
can
ideally
insert
anywhere
in
the
flow.
So
it
doesn't,
you
know
it
could
it
could
crash.
You
know,
for
example,
looking
it
could
it
could
crash
in
stage
you
know
stage
two
and
the
lock
assertion
message
was
sent
by
G1
G1
crashes.
D
Can
we
use
the
same
pair
of
session,
resume,
requests
and
request?
You
know
granted
you
know
anywhere
there.
That's
kind
of
the
goal:
I
don't
know
if
it's
achievable,
but
I
think
that
was
the
thing
that
that
I
think
Raphael
is
trying
to
communicate.
But
what
that
message
contains?
D
A
D
So
the
the
firmware
answer
is,
let's
finish,
the
first
three
drafts
that
we
have
before
we
add
more,
but
it
doesn't
mean
that
we
should
not
continue
working
and
I've
said
to
Raphael,
like
you
know,
if
I
understand
correctly
and
there's
there's
plenty
of
experience,
people
here,
you
know
from
the
ITF
that
they
should
continue
working
on
the
draft,
because
because
at
some
point
it
will
become
relevant
and
there
might
be
sufficient
reason
after
the
the
three
is
finished
to
actually
adopt.
D
You
know
the
cross
recovery,
for
example,
as
you
know,
a
proper,
a
formal
working
group
item
and
the
same
Rama
with
the
views
right,
which
is
why
I
was
asking
you
the
views.
Things
actually
absolutely
needed
right.
So
this
is
in
this
discussion
about
tokenized
deposits.
This
is
about
this
is
about
representing
your
bank
deposits,
which
is
what
the
bis
people
are
talking
about:
Bank
of
international
settlements
as
tokens
on
a
ledger.
D
That's
a
private
Network
right,
and
so,
if
I
want
to
sell
my
my
Ferrari
to
you,
not
that
I
own,
a
Ferrari,
I
I
need
some
proof
that
you
have
liquidity
right
and
for
those
who
are
following
the
whole,
you
know
FTX
thing
and
Terra.
Luna
liquidity
is
a
huge
topic.
I
mean
both
these.
You
know
particularly
Terra,
Luna,
Terra,
USD
and
Luna.
D
It
was
the
lack
of
proof
of
liquidity
that
just
brought
the
whole
thing
crashing
right.
So
so
what
is
so
proof
of
liquidity
would
need
to
be
something
like
what
you
have
in
the
views,
which
is
this
here's
my
proof.
What's
the
network
idea?
What's
the
block
ID?
What's
the
transaction
ID
right,
which
is
what
you
already
have
there
in
the
in
the
snippet
that
that
you
gave
us
on
the
mailing
list,
Rama.
D
D
D
D
Right
right,
so
so
so
it's
a
it's
a
burn,
so
David,
it's
a
burn
and
myth
model.
So
so,
formally
speaking
by
the
time
we
reach
message,
3.7.
D
Yeah
yeah,
so
so
in
the
burning
mint
model,
it's
not
like
transferring
bytes
as
in
you
know,
using
you
know
something
like
srtp
or
something
like
that
to
do
probable
transfer
transfer,
it's
it's
burning,
mint,
you
destroy
it
and
regenerate
it,
and
the
model
doesn't
necessarily
work
for
every
single
type
of
asset
on
the
planet
right.
So
if
somebody
could
argue
that
you
know
for
cbdc's,
it
doesn't
work,
but
but
Alex
did
you
want
to
speak
up.
B
Yes,
I
I
only
wanted
to
add
that
you
know,
according
to
the
satp
model,
the
asset
moves
at
the
point,
I
guess
when
it's
deleted
from
the
initial
network,
but
you
will
notice,
according
to
the
diagram
that
the
asset
is
present
in
both
gateways
at
some
point,
so
because
this
is
the
way
the
the
mint
and
burn
model
works.
First,
we
created
in
the
account
of
the
second
Gateway,
and
only
after
we
are
certain
that
this
asset
now
exists
on
the
second
Network
assigned
to
the
second
gateway.
Then
we
burn
it.
D
Any
other
questions
before
I
I
want
to
say
one
suggestion
for
the
people
going
to
the
San
Francisco
ITF.
So
right
now
we're
listed
sapi
to
be
meeting
on
the
Tuesday
morning
and
so
for
those
who
are
going
to
be
in
San
Francisco
I
was
thinking
that
maybe
we
could
get
together
for
lunch
and
we
certainly
want
to
invite
the
ladies
Thursday
morning,
Tuesday
Morning
a
Thursday
morning.
D
Whatever
morning
is
don't
go
away
for
the
lunch
you
know
hang
around
and
we
can
all
get
together
and
get
lunch
and
we
want
to
extend
an
invitation
to
Paul.
Of
course,
who's
been
tremendous,
helping
us
here
so
Paul.
If
you're
around
the
we
could,
we
could
shout
you
lunch
I,
don't
know
if
ads
are
allowed
to
drink
beer
at
lunchtime,
but
yeah
the
the
beer.
You
know
it's
also.
A
You're
right,
it's
not
usually,
but
it
was
Thursday
until
a
couple
of
weeks
ago,
so
you're
right,
Tuesday
driver.
D
A
Quick
mention
that
we
have
a
so
under
hyper
Legend.
We
have
the
cacti
project
right,
doing
interoperability,
so
hyper
nature,
organizers,
the
mentorship
program
every
year
which,
and
they
pay
people
and
people
can
apply
to
work
on
particular
features.
A
And
so
we
offered
a
project
to
implement
satp
within
cacti,
using
the
release
relay
company
three
days
being
like
Gateway
components,
so
just
want
to
let
everybody
know
that
we
have
an
active
implementation
going
on
and
I
asked
the
intern
to
be
on
the
scholarships
as
possible
he's
on
vacation
right
now.
But
you
know
as
any
any
feedback
that
we
get
when
it
comes
to
how
easy
it
is
Implement
satp,
if
there's
something
you've
missed
out,
then
I'll
communicate
that
in
the
or
on
the
meeting.
A
D
D
Oh
okay,
folks,
so
I
don't
know
how
to
actually
end
this
session.
Maybe
Paul!
You
need
to
actually
click
a
button
somewhere
to
to
end
this
session.
The
the
actual
meet
Echo
but
I
think
if
people
just
log
off
meet
Echo
will
probably
terminate
itself.