►
From YouTube: IETF-SATP-20230912-1400
Description
SATP interim meeting session
2023/09/12 1400
A
A
B
A
E
A
D
C
C
A
All
right,
why
don't
we
go
ahead
and
get
started
and
the
agenda
in
front
of
me
a
second
ago?
Essentially
you
know
these
are
the
interims
are
a
little
bit
more
laid
back
in
terms
of
let's
just
make
progress
and
get
things
done.
One
thing
that
Claire
and
I
were
discussing
that
we'd
like
to
hear
first
is
Thomas:
can
you
give
us
a
quick
update
in
five
minutes
or
less
about
the
design
team.
B
B
I
think
it
was
same
thing
on
a
Tuesday
and
I
I
thought
it
went
very
well
if,
if
anything,
we
ran
out
of
time
because
there
seems
to
be
multiple
problems,
but
if
there's
some
notes
up
on
the
sap
list,
but
the
core
sort
of
three
requirements
coming
out
of
that
discussion
that
that
wagya
proposed
are
the
following
that
that
a
network
identifier
needs
to
have
at
least
two
parts.
There's
the
self-generative
part.
That's
probably
not
the
right
word.
It's
it's!
B
The
hash
of
the
of
the
Genesis
block
to
make
sure
that,
even
in
the
case
that
a
DLT
has
Fork
that
you're
able
to
identify
the
correct
DLT
and
then
there's
the
the
I
call
it
the
Preamble,
which
is
the
front
bit,
which
is
the
assign
that
you
know
some
Authority
could
assign
it
Ayana
such
an
authorities
such
as
an
Ayana
or
some
kind
of
a
registry.
So
that's
the
first
requirement.
B
The
second
requirement
is
that
it
needs
to
be
what
was
the
phrase
self
self-proving
right
so
that
that
when,
when
a
node,
when
a
machine
evm
is
running
inside
a
particular
Network,
you
know
it.
It
can
run
happily
just
with
that
with
that.
Second,
second
bit
the
the
the
local
identifier-
and
it
can
just
forget
about
the
the
the
Preamble
the
the
issued
issued
bit
Claire,
you
have
your
hands
up,
you're
gonna
do.
Do
you
want
to
correct
me.
B
F
B
B
Apology,
that's
right,
and
so
so
this
brings
in.
So
let
me
say
on
the
second
one
here
for
a
moment:
Claire.
So
so
assuming
we
have
an
rtgs
monolithic
system
that
the
the
two
portions
remain.
True,
there's
a
sign
bit.
You
know
there
needs
to
be
you
know
and
then
and
then
the
the
what
we
call
the
16
bytes.
B
You
know
the
the
back
end
bit
could
in
fact
be
pre-selected
by
you
know,
say
the
bank,
so
the
bank
could
say:
okay,
you
know,
I
have
10
rtgs
systems
I'm,
you
know,
and
I've
got
one
common
Preamble
prefix
bit
that
I've
been
assigned
by
whatever
the
government
Ayanna,
whoever
I'm
gonna.
You
know
use
that
16
byte
namespace,
as
my
name
space,
to
allocate
identifier
for
each
of
these
endpoints
within
the
bank
right.
So
there's
no
dlps,
no
blockchains.
E
B
Not
extensively,
we
got
and
correct
me
for
folks
who
are
on
the
call.
We
got
to
realizing
that
there's
at
least
two
levels,
if
not
three
levels
of
identification
and
then
there's
the
question
here
on
of
metadata,
and
so
we
started
to
talk
about
dids.
It
doesn't
mean
we
have
to
use
the
IDS,
but
but
assuming
there
is
this
number
already
there,
whether
it's
fixed
length
or
it's
a
tlv.
It
could
be
put
into
a
did.
B
Data
structure
with
all
the
other
metadata
there
or
or
that
information
could
be
put
into
a
did
document
that's
off
chain
somewhere
and
the
did
is
just
a
resolver
mechanism
for
you
to
fetch
that
did
document.
So
so
we're
not
there
yet,
but
I
I
mean
I
feel
we
made
progress,
that
we
recognize
at
least
two
levels,
if
not
three
levels
of
identifiers-
and
you
know
needed.
A
B
B
B
You
know
on
the
main
blocks
right
and
that's
kind
of
inefficient,
but
but
there
is
this
question
of
how
do
you
show
legal?
You
know,
ownership
I
think
it's
probably
not
so
much
an
issue
if
it's
a
private
Network
or
an
Enterprise
Network,
but
but
that
that's
kind
of
the
third,
the
third
thing
and
I
don't
know
if
it's
even
in
scope
for
us,
but
any
technical
mechanism
that
would
help
that
could
help.
You
know
the
legal
side,
I
think
would
be
would
be
appreciated.
David.
G
Yeah,
like
question
related
to
that
is,
were
you
proposing
a
persistent
identification
or
a
transient?
In
other
words,
are
you
do
you
really
want
to
make
a
a
trial
operation
for
each
transaction
or
at
least
for
each
whatever
period
of
time
is
connected,
or
is
this
sort
of
a
one-time
transaction
to
prove
that
this
is
a
valid
node
and
then
that's
a
that
that
verification
is
persistent
for
the
remainder
of
so
Network
connect
or
not
I
mean
sometimes.
G
B
Right
so
so
the
the
problem
is
that
if
I
talk
to
a
node,
now
and
and
later
in
half
an
hour,
it
could
be
different.
Rpc,
endpoints,
right
you're,
not
talking
necessarily
to
the
same
node.
That's
the
first
problem
David
and
the
the
real
problem
is
that
we
want
to
include
this
identifier,
the
the
the
second
half
the
16
byte,
what
we
call
cross
chain
ID,
you
know
it
in
the
in
the
transaction.
B
It's
it's
it's
it's
it's
mentioned
as
part
of
the
the
DLT
transaction,
and
so
that
bit
has
to
be
persistent
right.
It's
the
same
network.
It
hasn't,
it
hasn't
changed.
It's
just
there's
two
different
nodes:
I'm
speaking
to
Via
RPC,
that's
claiming
to
be
part
of
that
Network
right
and
by
the
way,
I
don't
know
if
this
is
in
score.
I,
don't
think
this
is
in
this.
Rpc
problem
is
not
in
scope
for
us,
but
if,
if
you
have
this,
you
know
hash
of
Genesis
block
embedded
as
part
of
the
identifier.
G
B
C
C
There's
been
quite
a
few
conversations
that
and-
and
you
mentioned
yourself
earlier
Thomas-
that
certain
elements
are
out
of
scope
and
we
are
dipping
into
the
out
of
scope
elements
a
bit.
I
just
want
to
make
sure
that
we're
on
track
with
the
core
Charter
first
and
get
that
progressed,
because,
obviously
that
is
that
is
our
our
purpose.
Together.
B
B
Yeah
yeah
at
least
the
architecture
Dock
and
the
sapi
core
should
mention
these
things.
You
know
it.
You
know
requirement
for
Saturday
core,
that
the
endpoints
have
a
an
identifier,
a
network
identifier
and
and
and
that's
it
maybe
maybe
reference
something
else.
But
that's
that's
the
end
of
what
satbee
corkin
can
say,
I
think.
C
C
A
B
Yeah
yeah
sorry,
I
I
was
just
saying
section:
seven
in
San
Francisco.
We
had
this
quick
discussion
with
where
actually
you
corrected
me
that
there
was
this
idea
of
what
is
it
the
stage
zero
where
you
know
the
the
gateways
are
proposing
to
each
other
I'm
going
to
use
that
Cipher,
no
I
can't
use
that
I
want
to
use
this
Cipher
back
and
forth,
and
so
that
needs
to
be
fixed
also
and
I
I
need
to
ping.
You
privately
to
to
remind
me
your
suggestion.
B
B
F
F
Can
we
maybe
just
describe
the
properties
of
a
unique
identifier
without
explaining
how
they
get
created
like
it
has
to
be
unique,
Gateway
has
to
speak
a
negative
speaks
for
a
particular
system
or
network.
We
know
that
we
can
provide
that
particular
identifier
and
that's
going
to
be
persistent
across
until
the
happy
protocols,
complete
I.
Think
I,
don't
know
if
that
this
is
explicitly
stated
in
the
architecture
document,
all
this
RP
code,
so
I
just
wonder
if
we
should
just
take
the
properties
without
going
30
days.
B
F
G
B
A
We
can
shift
the
scope
around
a
little
bit
if,
if
there's
a
requirement
for
the
core
or
the
architecture
or
whatever
that
you
know,
we
realize
we
can't
go
forward
without
something,
then
that
means
it
has
to
be
a
part
of
it.
So
if
identification
or
more
specifically,
you
know
this
won't
work.
Unless
we
we
give
it
some
exact
specification,
then
we
can
include
that
as
a
requirement
for
for
getting
forward.
A
That
being
said,
I'm
not
sure
personally
that
this
qualifies
not
speaking
as
a
chair,
but
speaking
technically
right.
If
we
have
a
a
parameter
in
the
protocol,
that
is
generic
right,
it's
it's
some
sort
of
it's
most
likely
going
to
be
a
textual
type.
Blob
we've
talked
about
using
Gibbs,
we've
talked
about
using
something
else,
but
we
say
look.
This
is
this
is
basically
a
generic
string
placeholder
for
doing
identification,
but
two
parties
can
still
communicate.
You
know
because
they
already
know
who
they're
talking
to
in
the
first
place
right.
A
The
identifier
problem
seems
to
me
to
be.
You
know
more
of
the
discovery
case
of
of
the
future,
whereas
the
case
that
we
pitched
both
in
the
buff
as
well
is
in
the
initial
creation
of
the
working
group
was
look.
These
two
parties
know
who
they're
communicating
with
right
routers
on
the
internet.
Do
this
already.
In
fact,
you
know
I
run
a
lot
of
routers
and-
and
you
know
you
specifically
say
I-
need
to
talk
to
this
IP
address,
because
it's
this
ASN
for
this
network
that
you
know
exists
on
the
other
side.
A
You
know
who
it
is,
you're
talking
to
and
I
think
that's
where
said
p
promised
that
they
would
start
and
thus
is
probably
where
we
should
say
now.
We
do
have
to
specify
sort
of
what
what
that
placeholder
should
look
like
for
the
future
right
is,
is
it
a
string?
Is
it
a
binary,
blob
and
I
think
that
to
a
large
extent
is
you
know,
remains
to
be
seen.
A
My
my
belief
is:
is
that
if
we're
using
something
like
Jason
or
something
like
that
to
do
the
encoding,
then
it
should
probably
just
be
a
generic
string.
We
can
fill
in
later
and
explain
what
it's
for
this.
This
will
be
a
placeholder
where
this
identifier
will
go,
allowing
you
know
gateways
to
do
more
collaborative
agreement
upon
you
know
what
the
negotiation
is
actually
about,
or
something
like
that.
One
other
thing
to
note
is
as
a
reminder,
you
know,
there's
a
lot
of
people
that
are
newer
to
the
ietf
in
this
group.
A
The
way
documents
progress
is
that
we
get
to
a
we.
We
come
up
with
a
document
that
we
think
is
done
and
ready
to
be
published
right
so
that
and
then
what
multiple
people
have
said
is
a
peer
review
really
means
we
have
to
go
through
a
couple
of
steps.
First,
the
working
group
itself
has
to
say
this
is
done.
This
is
your
last
chance
to
make
any
comments
about
it
before
we
ask
for
it
to
be
published,
and
so
that
is
a
working
group.
A
E
A
Does
anybody
want
to
comment
and
I
guarantee
we're
going
to
get
comments,
and
so
that
also
it
will
be
like
three
to
four
weeks
long
and
things
like
that
so
and
then,
after
that,
it
goes
back
through
the
adsg
they
deliberate
on
it,
and
things
like
that.
So
at
any
point,
during
these
steps
we
can
sort
of
revert
back
and
say:
oh,
it
turns
out
there's
some
important
things.
A
E
A
ruthless
approach
to
scoping
is
is
very
good,
but
I
have
a
question
if
we
say
if,
if
we
publish
the
protocol
with
identity
as
a
generic,
any
string
will
do
and
then
later
on,
we
published
a
draft
with
us
that
performance
say
it's
a
did
or
urn
or
whatever.
Now
not
all
strings
are
URLs
and
certainly
to
to
do
the
security
check
or
to
be
compliant.
A
We
could
use
two
identifiers
right
where
one
is
here's
the
type
and
that
type
will
be
assigned
later,
so
the
type
could
just
be
an
an
integer
that
we
register
with
Ayanna
and
I
would
have
a
registration
system
saying
you
know
in
future.
Specifications
have
to
say
you
have
to
say
the
type
of
the
identifier
you're
going
to
use
as
a
second
piece
and
honestly
considering
the
number
of
ways
that
that
this
group
has
talked
about
creating
identifiers.
This
actually
seems
like
a
reasonable
approach
right.
A
B
A
Another
and
then
we
can
create
niana
registry
and
I
can
help
with
that
in
the
future.
If
you
know
how
we
do
that
in
a
document
saying
and
in
the
beginning
there
may
be,
you
know
no
types
assigned
in
the
initial
registry
or
more
likely,
we
would
actually
have
one
of
the
things
that
we
can
frequently
do
in
that
case
is
create
a
private
reserved
for
private
use
value
so
that
we
can
say
look
value,
typically
use
something
at
the
end
of
the
range.
B
A
E
A
And
we
don't
need
to
solve
it
today,
but
I
think
your
your
point
is
very
valid
that
we
need
to
make
sure
that
something
can
happen.
Future
specifications
are
allowed
to.
You
know
add
additions
to
this
one.
So
one
of
the
things
that
we
can
do
is
for
interoperability,
a
common
thing
that
the
aetf
does
is
they
mandate?
This
is
the
one
that
everybody
has
to
support.
A
The
other
ones
are
optional,
or
maybe
even
sometimes
a
couple
of
them,
but
it's
very
common
in
the
ATF
to
say
we
recognize,
there's
three
different
forms
of
identification
that
we're
proposing
number
one
is
the
one
that
everybody
has
to
do,
the
other.
You
know
two
are
optional
and
that's
done
all
the
time
for
things
like
that,
or
sometimes
even
for
security
protocols.
We
often
say
these
three
algorithms
are
mandatory
to
implement,
for
example,.
A
All
right,
so,
where
does
that
leave
us
for
the
day,
there's
still
a
half
an
hour
left?
Is
there
anybody
that
wants
any
of
the
authors
of
the
current
document,
specifically
that
want
to
bring
up
a
discussion
topic
about.
You
know
something
especially
on
that
remaining
checklist
for
things
to
get
done,
that
they
want
feedback
on.
A
F
Hello,
can
you
hear
me
yeah,
okay,
I,
don't
have
the
question
or
feedback
right
now,
but
I
just
want
to
note
that
Victor
zainan
who's
on
the
call
he
submitted
the
use
case,
which
he
also
mentioned
in
the
plus
IIT
meeting
whenever
he
was
present
I,
should
need
to
incorporate
that
in
the
main
draft
just
haven't
had
the
time
to
do
so.
I'll,
probably
get
some
time
next
week
and
after
that
we
can
connect
into
a
meeting.
B
F
A
D
D
The
goal
is
to
ask
if
DNS
nft
ownership
transfer
would
be
something
that
satp
is
interested
in
considering,
including
as
a
targeted
use
case,
the
reason
being
that
it
seems
there's
no
current
good
way
to
to
specify
it
and
the
closest
standard
is
the
Epp
also
by
ietf,
and
it's
a
very
natural
digital
assets,
as
if
we
see
that
ownership
of
DNS
so
I
pasted.
The
the
nft
ownership
transfer
dock
here
like
to
get
feedback.
A
Yeah,
thank
you
for
that
I
think.
Maybe
we
should
include
that
as
a
specific
topic.
Next
time
after
people
have
read
the
read
the
document
completely
so
that
we
can
consider
it,
I
will
say
that
for
transfer
of
assets
that
are
in
existing
protocols
like
the
DNS
that
already
have
solution
spaces
that
are
defined
within
the
registry
registrar,
you
know
model
and
things
like
that.
That
would
be
very
hard
to
get
past
right,
because
you're
you're
asking
for
an
alternate
mechanism
that
could
conflict.
A
If,
if
we're
talking
about
names
that
are
within
the
existing
DNS
framework,
if
you're
talking
about
nft
or
other
related
names
that
might
exist
under
the
future.alt
specification
or
things
like
that,
then
that's
out
of
scope
of
the
existing
specification.
So
we
could
run
into
Political
troubles
there,
but
we
can
work
through
that
I
would
say
for
now.
D
A
A
Anything
that
complements
the
existing
system
is
good,
I'd,
be
very
careful
in
in
when
that
use
case
is
written
up
to
very
clearly
articulate.
You
know
what
the
situation
looks
like
right.
You
have
this
part
of
the
DNS
tree
that
that
is
registered.
You
know
uses
traditional
DNS
resolvers,
because
otherwise
it's
not
the
DNS,
but
the
ownership
of
it
is
controlled
by
a
blockchain
based
registration
system
and
they
want
to
transfer
it
to
this
other
blockchain
based
registration
system
under
the
same
namespace.
That
is,
you,
know,
a
different
type
of
registrar.
A
C
B
Quick
note,
folks,
if
you
want
to
comment
on
architecture
document,
you
could
easily
open
in
issues
an
issue
thing
on
the
GitHub
repo.
Thank
you
again
who
set
this
up.
It
really
makes
a
big
difference
in
and-
and
you
can
now
look
at
diffs,
between
versions
of
of
drafts
and
Raphael
is
is
in
the
process
of
setting
up
the
same
thing
so
on
the
repo
you'll,
see
the
editors
working
copy
and
then
you'll
see
a
pointer
to
the
current
formal
ITF
version.
That's
up
on
the
data
tracker.
C
Because
everyone,
just
as
a
regular
reminder
for
everyone
to
step
today
with
the
documents,
is
that's
the
core
kind
of
focus
of
our
efforts
at
the
moment.
Obviously,
once
the
protocols
move
forward,
we
can
start
to
pull
in
some
of
the
outer
scope
or
expand
the
script.
Expand
I
can't
speak
today
extend
the
scope
for
future
work.