►
From YouTube: IETF-SATP-20230613-1400
Description
SATP meeting session at IETF
2023/06/13 1400
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
But
we've,
given
it
till
nearly
five
past,
so
I'll
kick
off.
We
have
two
items
on
the
agenda
today.
It's
much
more
of
a
workshop
type
session
today,
which
is
what
I
think
we're
all
trying
to
get
towards
So.
Today,
we're
going
to
be
looking
at
the
draft
that
Thomas
has
requested,
as
we
have
a
quick
review
of
and
then
we'll
move
into
the
error
message
workshop
ahead
of
our
next
ietf
formal
meeting,
so
Thomas
I'll
give
you
the
floor.
B
A
B
A
A
B
Okay,
thank
you
yeah
12th
of
June,
which
is
yeah
yesterday.
So
the
first
thing
that
Rafael
and
I
and
and
with
the
help
of
Martin
remotely
did,
was
go
through
to
make
sure
that
particularly
section
six,
seven
and
onwards
that
the
flows
were
cons,
we're
using
the
same
consistent
words.
You
know.
So
if
we
say
claims
you
know
claims
you
know
not
assertions
so
yeah.
So
thank
you
Claire.
B
So
if
you
look
at
that,
the
new
edition
is
probably
7.1,
so
so
pre
in
the
previous
version,
which
is
very
messy
each
one
of
those
flows.
Request
response
would
carry
like
the
complete
will.
We
were
very
verbose.
You
know
the
the
publicy
of
the
originator
public
beneficiary,
and
it
just
got
too
long,
so
we
said
well,
why
don't
we
make
this?
You
know
instead
of
you
know,
put
this
together
in
this.
B
You
know
transfer
initiation
claims,
which
is
the
set
of
claims
that
G1
and
G2
have
agreed
upon
in
stage
zero,
and
so-
and
this
is
just
a
all
of
a
sudden-
we
can-
we
can
fix
this-
add
this
remove
this,
but
then
it
makes
the
text
more
readable
bearable
as
we
go
down,
because
we
don't
have
to
repeat
the
whole
thing.
We
just
say
you
know
transfer
initiation
claim.
So
when
we
say
a
hash
of
the
claim
you
know
is
the
is,
is
these?
Are
the
these?
B
Are
the
claims,
the
items
that
G1
and
G2
has
agreed
upon,
and
so
each
of
each
of
the
subsequent
flows
now
becomes
shorter
because
we
don't
have
to
put
all
this
stuff.
It's
literally,
you
know
six
seven,
you
know
components
so
that
that's
kind
of
the
sort
of
first
just
clean
up
effort,
there's
nothing
new.
It's
just
cleaning
up
making
this
more
readable
and
also
I
think
from
a
semantics
perspective.
It
makes
sense
because
well,
there's
no
point
proceeding
to
any
of
the
other
flows.
A
A
Sorry,
so
the
just
to
give
everyone
a
bit
of
a
background.
This
is
the
new
draft
that
you're
asking
for
us
to
adopt
and
you're
talking
through
the
changes.
So
these
changes
do
they
replace
the
terminology,
glossary
that
we've
been
working
on
or
if
they
now
Incorporated
this
into
the
text.
As
we
sort
of
said
last
week,
we
might
last
time
we
might
want
to
do
just
to
kind
of
frame
the
changes
a
bit
yeah.
B
B
Is
bearable
because
it's
it
is
pretty
what
it
page
it
is.
It's
like
umbrees,
like
oh,
like
wow,
this
is
grown,
and
so
now
I
should
I
should
caveat
that
the
digital
asset
ID
and
asset
profile
ID
we
have
not
put
into
as
yet
into
the
into
the
terminology
document
glossary
document
and
also
we
used
to
say
originator.
You
know
entity
ID,
you
know
and
I've
added.
B
The
word
verified,
because
part
of
the
whole
legal
framework
is
there
is
that
it's
the
job
of
G1
or
the
owner
of
G1
to
verify
the
identity
of
the
originator
and
same
with
G2
and
the
beneficiary
right,
so
I've
added
the
word
verified
underscore.
What's
the
point
of
sending
you
know,
information
about
a
person
if
you've
not
verified
that
it's
a
true
person
right,
that's
part
of
the
whole.
You
know
whole
setup.
C
B
B
B
A
B
B
Well,
they
will
have
to
agree
on
a
format
and
we
we,
as
ITF,
typically
and
correctly
correct
me-
was-
is
early
over
there
in
California
land.
We
need
to
say
at
least
a
one
default
format.
We
have
to
choose
at
least
one,
but
it's
not
exclusively
one.
If
somebody
wants
to
re-implement
the
whole
thing
with
XML,
that's
great.
D
Well
so
two
things
one
I'm
actually
in
Washington
DC
for
the
icam
conference.
I
am
only
here
for
a
short
period
of
time
because
you
know
other
stuff
to
do,
but
the
the
general
recommendation
is.
If
you
can
separate
the
format
that
you're
delivering
something
in
you
know
from
the
transport
that
is
a
better
architectural
decision.
It
lets
you
actually
negotiate.
What
what
you
should
absolutely
must
do
is
declare
one
as
the
mandatory
to
implement
right
in
order
to
get
interoperability
between
two
different
things.
D
B
B
A
A
A
A
D
B
B
B
C
C
D
B
B
B
Yeah,
so
actually,
while
we're
waiting
another
topic-
that's
not
on
today's
thing
agenda
is
a
session
resumption.
So
Raphael
is
Rafael,
hey
Rafael,
so
we've
been
whiteboarding,
you
know
back
at
MIT
and
and
the
idea
is
that,
could
we
devise
just
a
pair
of
messages
that
says
basically
I
wanna
I
wanna
resume,
and
the
answer
is
yes:
yes,
no
and
and
leave
the
whole.
B
B
B
Yep,
okay,
great
so,
okay,
so
that's
the
topic
next
slide,
please
Claire!
So
so
this
is
just
the
discussion
of
the
proposed
model,
so
so
I
I've
I've
stolen
this
out
of
the
the
TLs
one
point:
two
Drive
RFC,
or
is
it
what
it's
actually
1.2?
It's
and
it's
also
remains
three
at
1.3.
So
this
is,
if
you
guys,
are
really
interested.
You
can
dig
the
section
six
or
section
five
of
of
the
TL
aspect,
and
so
the
idea
is
that
you
want
to
distinguish
between.
B
You
know,
alerts
and
you
know
well,
there's
the
alert
and
then
there's
the
a
bit
of
information
and
a
severity
level
and
I
think
that's
kind
of
the
model,
and
so
we're
thinking
that
for
sat
B.
We
need
to
like
look
at
like
two
possible
classes
or
severity
of
of
messages.
So
the
first
one
is:
is
normal,
orderly
closure,
so
terminate
notification,
meaning,
okay,
you
know
transfer
finish
our
very
last.
B
You
know
very
last
stage
message.
You
could
say
afterwards
you
know
terminate
you
know
connection.
So
that's
orderly!
There's
no
error!
There's!
No!
It's
not
messy!
The
second
one
is
the
messy
one.
The
second
one
is
something
happened,
I'm
terminating
and
so
the
word,
a
board
of
closure.
Again
that's
listed
from
the
TLs
RFC
and
so
the
following
question
then
the
following
as
well:
okay,
depending
on
the
severity
we
might
be
able
to
recover
it
because
we
don't
want
to
if
you're
already
like
in
you
know
the
very
last.
B
B
B
D
C
D
A
D
B
D
B
D
I
was
trying
to
figure
out
how
we
were
going
to
clearly
describe
this,
and
so
I
would
use
consistent,
formatting
or
you
know,
Styles
throughout.
So
you
may
want
to
reframe
it
into
a
the
same
style
that
the
rest
of
the
writing
is
and
not
use
the
TLs.
You
know
C
like
structure
unless,
unless
you're
using
that
everywhere
else
is
my
point.
B
D
Yeah
and
I
think
you
know,
there's
a
lot
of
good
rfcs
that
have
examples
as
the
documents
going
along,
for
you
know
the
different
sections
so
that
you'll
have
a
a
section
header.
You
know
that
talks
about
this
is
what
we're
talking
about
and
then
here's
an
example.
Here's
a
message
flow
example
where.
B
Imap,
okay
I'll
check
that
out
now.
That's
that's!
This
is
exactly
the
kind
of
input
that
we're
needing
where's
like
how
do.
How
do
we
express
some
of
these
sort
of
constructs
but
yeah?
So
I'll
take
a
look
at
the
IMAP
and
you're
right.
I
mean
the
idea
would
be
eventually
we
started
doing
this
and
never
finished,
because
we
we
needed
to
fix
the
error
messages.
B
Actually
the
protocol
itself.
You
know
semantically,
but
basically
this
the
the
ideal
scenario
would
be
that
every
message
has
an
example
Json
at
the
at
the
bottom
of
it.
This
says,
example
right!
So
if
it's
we're
sending,
you
know
a
lock
claim
from
G1
to
G2
here's
an
example,
but
you're
right.
That's
that's
the
kind
of
it's
kind
of
good.
A
B
Next,
next
one
yeah,
so
this
is
just
a
quick
note,
so
we're
trying
to
focus
right
now,
semantics,
meaning
that
given
a
pair
of
messages,
whatever
Block
in
a
receipt,
what
are
the
obvious
ones?
You
know?
Claims
are
badly
formed,
blah
blah
blah
and
what
are
the
edge
cases
and
Dennis
is
not
on.
Dennis
is
very
good
at
picking
the
edge
cases
because
he's
got.
You
know
the
deployment
experience
and
then
the
the
the
difficult
one.
B
What
scenarios
will
need
human
intervention
so,
for
example,
at
the
last
episode
of
mailing
list,
but
then
the
last
call
I
think
that
Dennis
was
saying
you
know
at
the
very
last.
You
know
commit
message:
if
the
commitment
message
doesn't
ever
reach
G2,
then
it
might
so.
Asset
has
been
deleted,
it's
been
created
but
not
assigned,
it
might
need
human
intervention
to
go
in
and
actually
assign
it
manually
to
Bob
right.
B
So
that's
kind
of
you
know
an
example
of
it's
not
worth
rolling
rolling
back
because
it
just
needs
an
I.T
guy
to
say
you
know
allocate
allocate
to
Bob
but
we'll
we'll
we'll.
This
is
an
ask
for
you
guys
these
three
bullets.
You
know
to
help
us
figure
out,
you
know
the
obvious
ones,
the
educations
and
the
the
really
sort
of
bad
ones
that
need
you
know:
human
intervention.
B
So
so
please
open.
If
you
want
message
flow
diagram
version,
18,
it's
up
there
on
the
GitHub,
otherwise
I've
snippeted
the
cut,
cut
and
pasted
the
the
different
parts.
So
this
is
now
and
we
begin
in
stage
what
is
this
stage
one?
No,
this
is
stage
two
2.1,
so
we're
leaving
stage
one
to
later,
because
it's
a
it's
a
simple
request
response,
but
it's
all
the
the
transfer
claims
that
we
have
to
figure
out
for
stage
one.
B
So
this
is
now
stage
two,
so
this
is
transfer
commence
and
then
there's
an
acknowledgment
coming
back,
and
so
this
is
the
three
sets
groups
of
errors
that
that
we
think
could
happen
so
badly
formed
a
message
you
know,
G1,
intentionally
or
otherwise.
Replace
one
of
the
claims
in
the
transfer
claim
part
that
had
previously
agreed.
So
G1
is
trying
to
cheat
right.
So
it's
okay,
that's
I!
Don't
know
what
to
call
it.
It's
a
badly
formed
message,
incorrect
parameters.
So
the
claims
are
okay,
but
something
else
is
is
wrong.
B
B
D
So
question
on
that
I
guess
a
couple
of
questions:
I
think
so.
Does
the
document
to
date
and
I
apologize,
I
haven't
read
the
latest
one
and
the
last
one
I
read
was
a
while
ago
too,
you
require
all
of
the
transaction
messages
to
occur
over
a
single
TLS
session.
Well,
unless
resumption
happens
right,
so
you.
B
Are
fine
very
good
ways?
This
is
yeah
I,
don't
know
people,
you
know
we
have
not
really
discussed
ever
whether
or
not
it's
we're
requiring
a
single
TLS
session
or
could
G1
and
G
to
effectively
have
a
big
pipe,
a
big
tunnel,
a
permanent
amount
of
permanent,
a
long-term
TLS
session
and
you're
running
in
a
multiple
transaction
transfers
across
the
same
TLS.
In
which
case
you
know,
error
2.3
is
a
is
a
true
possibility.
F
Yeah
sorry,
just
on
on
these
acts,
you
know
when
I,
when
I
was
talking
about
the
end
points
on
the
email
on
the
mailing
list
thread
I
was
considering
like.
Maybe
we
don't
need
some
of
these
acts
or
we
need
more
acts,
but
I
know
Raphael
addressed
all
my
all
my
concerns,
but
maybe
me
and
raffle
can
catch
up
after
this
meeting
just
because
I'm
still
I
still
really
strongly
feel
that
we
should
try
to
stalinize.
F
B
B
F
A
yes
exactly
yeah
yeah,
it
could
be
a
response
with
the
body
as
well.
It
could
be
a
200,
okay,
plus
plus
any
anything
that
is
required
in
the
ack
data
structure,
for
example
yeah.
But
we
could
use
the
same
representation
method
right
in
in
the
diagram,
that's
kind
of
what
I'm
advocating
for,
because
in
some
places
we
have.
For
example,
here
we
have
transfer
commands
and
the
neck,
but
in
other
places
we
don't
have
the
ACT
so
yeah.
B
Yeah,
so
that
that's
all
of
that
is
a
part
of
the
three-phase
commit
definition
like
if
you
want
to
say
we
want
to
do
three-phase
commit.
We
actually
have
to
send
this
message.
You
know
back
and
forth
and
and
the
other
you
know
the
others
cases
well,
we've
kind
of
put
it
aside,
but
it's
a
possibility
that
people
will.
Someone
may
not
want
to
use
http.
D
If
I
can
rephrase
Alex's
statement
in
a
way
anything
the
way,
I
put
it
into
the
notes,
you
have
a
sequence
of
you
know,
commands
or
messages
and
in
some
ways,
because
there,
that
sequence
is
a
defined
order.
An
act
can
be
implicit
by
following
along
in
the
sequence
where
the
opposite
side
sends
the
next
message
and
because
they
sent
the
next
message,
it
means
that
he
had
to
have
acknowledged
the
previous
one
unless
there's
a
digital
signal
or
something
something
that
is
required
for
you
know
to
act.
B
F
B
B
Okay,
if
there's
no
more
question
you'll
see
this
you'll
get
bored
pretty
quickly,
because
it's
a
yeah
keep
on
next
slide.
Please
Claire
you'll
see
the
same
types
across
so
this
is
this
gets
more
complicated.
So
so
a
lot
both
lock
assertion
and
receipt
are
signed
messages,
and
this
this
is
because
G1
and
G2
are
now
on
the
hook
right
legally.
B
On
the
hook,
the
signing
is
they're,
saying
things
to
be
true,
and
so,
for
example,
some
of
the
errors
could
be
badly
for
message
so
either
the
claim
is
wrong
or
you
know
the
the
something
is
wrong
in
the
lock
assertion
claim
data
structure-
or
you
know,
maybe
maybe
something
else,
bad
signature,
so
the
signature
part
did
not
work
out.
A
G2
could
not
validate
the
lock
assertion
message:
wrong:
transaction
ID.
We
saw
that
before
mismatch
hash
value.
So
this
is
where
there's
this
there's
this.
B
You
know
idea
that
his
message
should
carry
the
hash
of
the
previous
message
so
for
this
one
I
think
it
was
a
2.4
supposed
to
carry
the
hash
of
2.3.
Now
it
could
be
that
G1
is
trying
to
cheat,
and
so
it's
putting
in
the
wrong
hash
value
and
purpose
or
there's
just
bad
logic.
Implementation
expired,
signing
key
certificate.
So
if,
if
G
one
is
signing,
you
know
using
public
key
cryptography
and
there's
the
next
509
insert
G2
tries
to
fetch
that
you
know
using.
B
So
it
could
be
that
the
lock
assertion
claim
is
going
to
be
set
to
be
valid,
to
be
like,
say,
60,
60,
Seconds,
okay
and
then
G2
took
longer
than
that
took
five
minutes,
and
so
message
2.6
is,
is,
you
know,
delayed
very
much,
and
so
it
could
be
that
you
know
by
that
stage.
The
claim
has,
you
know,
gone
stale.
Basically,.
E
B
Yes,
yes,
so
so
this
is
thank
you
Dave.
So
so
do
you
notice
all
the
arrows
going
outwards
into
the
network
network?
One
network
through
is
not
included
because,
technically
speaking,
it's
not
part
of
the
protocol,
but
yes,
we
would
love
to
have.
We
should
add
the
reason
you
know
so
it
could
be
that
you
know,
but.
E
D
A
B
Yeah
so
so
David.
Thank
you
very
much.
Yes,
those
are
those
are
the
hard
ones.
How
how
do
I
say
this
politely?
These
are.
These
are
the
easy
obvious
ones,
but
so
you
know
you
know,
for
example,
this
step
2.4
took
too
long.
Okay,
G2
is
waiting
and
waiting
and
waiting-
and
that's
you
know
and
finally
gives
up
because
Gateway
One
is
unable
to
actually
do
the
the
lock
right.
B
B
B
Okay,
moving
on
Claire
sorry,
this
is
again
commit
prepare
and
commit
prepare
act,
so
these
are
pairs
badly
for
a
message.
Mismatch
hash
value,
I
mean
I,
may
not
be
saying
it
the
right
way,
but
basically
the
hash
of
the
you've
got
the
wrong
hash.
It
should
be
the
hash
of
the
previous
message
and,
and
it's
not
Computing,
so
you
might
have
done
something
wrong
and
some
incorrect
parameter.
Okay.
So
this
this
needs
more
discussion
and
elucidation.
B
You
know
any
one
of
those
commit
prepare
parameters
could
be
you
know
an
error
or
mistaken.
A
message
out
of
sequence
so
commit
the
commit.
Prepare
was
sent
before
the
the
last
message,
so
we
put
it
in
there
not
not
really
being
sure
if
this
is
even
possible.
3.1.4,
given
the
fact
that
there's
a
the
three
three
phase
commit
has
a
very
tight
set
of
messages
that
need
to
go
in
sequence,.
B
Yep
commit
commit,
ready
and
commit
prepare,
so
so
interesting,
I
think
in
the
email,
Racha
and
I
sort
of
discussed
this,
that
the
original
commit
prepare
and
commit
act.
The
commit
preparer
actually
has
to
to
I
I've
been
calling
them
children,
the
ACT
prepared
going
backward.
We
just
saw
and
then
there's
a
commit
ready.
B
So
so,
in
fact,
there's
this
silence
between
3.2
3.4,
where
in
fact,
G2
is
trying
to
create
the
asset
in
message:
3.3,
A
and
B,
and-
and
you
know,
if
you
guys
open
the
full
message-
Pro
you'll
see
this
and
then
3.4
I'm
ready
right.
So
it's
pretty
much
the
same
set
of
possible
errors
and
I
invite
you
guys
to
get
print
this
out
on
a
big
sheet.
You
know
put
it
on
your
wall
and
and
stare
at
it.
B
B
And
in
next
one
clear,
please
I
think
I
think
we
might
be
at
the
oh
yeah.
This
I
think
this
is
the
last
slide,
so,
okay,
so
Next
Step,
so
I
want
to
figure
out
the
set
of
errors
that
may
happen
in
stage
one.
This
is
all
the
transfer
initiation
claims.
This
is
I,
think
section
7.12
and
three
and
some
of
this
by
the
way,
the
actual
actions
you
know
in
the
real
world
is
outside
our
scope
or
we
all
the
G1
and
G2
can
do
is
report.
B
B
That
is,
is
you
know,
crucial
for
deployment
and
then,
finally,
we
will
we
plan
to
be
putting
on
some
adding
on
some
more
text
for
human
intervention
cases
and
session
resumption
and
I
think
the
plan
is
we
want
to
have
a
discussion
correct
me,
Raphael
at
the
at
the
San
Francisco
ietf
on
session
resumption?
What
should
it
we
have
a
sketch
on
a
whiteboard,
but
we
kind
of
need
to
think
some
more
about
it.
A
B
Yeah,
so
so
there
are
very
narrow,
very
what's
the
word.
I
think
I
wish
Dennis
was
here
there.
There
are
cases
where,
where
in
fact
it's
it's
not
a
deadlock,
but
but
this
is,
as
I
said,
the
the
commit
with
3.6
was
set
out
and
but
then
never
got
to
G2
that,
oh,
oh,
basically,
the
something
stuck
on
G2
and
the
IT
admin
guide
needs
to
go
in
and
say:
release
transfer,
like
actual
manual
override,
authorized
release
to
Bob
right
versus
okay.
B
This
thing
is
sitting
here
because
G2
crash
G2
has
come
back,
it
doesn't
know
what
to
do,
and
so
it's
sitting
there
just
waiting
for
the
asset
to
be
allocated
to
Bob.
So
that's
an
example,
but
but
Rama
the
goal
is
like.
We
need
to
understand
this
very
tight
rare
occurrence
scenario
so
that
if
it
does
happen,
it's
in
the
specs
that
somebody
reads
this
thing
in
10
years
and
believe
me
having
been
very
close
to
the
Kerberos
rfcs.
B
C
B
Yeah
yeah
yeah,
we
we
don't
mean
somebody
I,
take
logging
in
and
saying
hey,
I'm,
just
gonna
roll
back.
You
know
this
stuff
because
I
don't
like
it
it's
more.
This
thing
is
sitting
it's
unresolved.
It's
sitting
it's
it's,
not
it's
not
like
like
deadly,
so
so,
for
example,
G
network
one
has
already
extinct,
G1
network
has
already
extinguished
the
asset.
The
asset
is
is
actually
now
is
in
the
possession
of
G2,
but
G2
has
was
not
able
to
give
it
to
Bob.
B
B
A
good
implementation
should
be
able
to
clear
this
very
quickly
right.
So
there's
all
these
pending
yeah,
but
there
are
bad
implementations.
You
need
an
I.T
guy
to
log
in
and
say:
okay
is
this
three
pending
thing?
Is
it's
supposed
to
go
to
Bob?
You
know
Doug,
and
you
know
Rama
and
so
say
you
know,
approve,
approve
proof,
then
having
having
text
there
just
to
to
convey
that
we
are
aware
of
these.
Very
it
happens
in
databases
as
well,
so
the
having
text
there
kind
of
helps
us.
A
Is
that
something
that
we
want
to
put
on
the
agenda
for
our
next
meeting
the
iitf117
or
do
people
have
anything
else
that
they
would
like
to
have
on
that
agenda
we'll
be
putting
the
chairs
will
be
putting
a
call
out
at
the
end
of
the
session
today
or
early
tomorrow,
depending
when
I
get
around
to
it?
There's
a
call
for
gender
items,
but
is,
is
that
something
that
we
want
to
pick
up
as
part
of
that
working
session?.