►
From YouTube: Kubernetes WG IoT Edge 20230628
Description
June 29 2023 meeting discussed Edge Native Principals Paper Review,
Wasm on K8s: Wasm WG, Debuggability of the edge - if edges are designed to be stateless, can just press reset and pick up where you left off
If you want longer persistence on the edge, add another edge,
Open Ziti for zero trust edge
A
B
You
know
we
can
go
and
jump
to
the
white
Behavior.
Excuse
me,
for
my
voice
got
a
bit
of
a
cold.
We
can
jump
to
the
white
paper.
Real,
quick,
but
so
Andy
did
a
ton
of
updates.
So
it's
so
reflecting
your
comments
Victor,
but
we
I
don't
really
see
Andy
here,
which
might
be
useful
to
Adam
right
for
for
that
particular
discussion,
but
I
at
least
know
what
the
edits
are.
A
B
B
B
A
B
B
B
I
you
over
need
need
to
overcome
certain
constraints
at
the
edge
like
low
or
low
bandwidth,
limited
or
design
design
constraints
from
a
delay
perspective,
frequent
outages
of
the
Uplink
or
certain
policy
considerations
that
require
the
application
to
stay
at
a
particular
location,
and
all
of
these
could
obviously
apply
to
the
constrained
device
Edge.
They
can
go
and
apply
to
the
smart
device
Edge.
They
can
also
apply
to
the
access
Edge
or
Regional
Edge.
B
What
we
all
call
Edge
native
right,
that
we
need
to
go
and
apply
these
alternative
design
behaviors
in
that
case,
which
is
another
set,
or
an
additional
set
of
considerations,
so
that
it's
not
so
much
like
Edge
native
applies
to
this
particular
type
of
Edge,
and
it
doesn't
really
apply
to
that
particular
type
of
assets.
We're
basically
saying
well,
it
could
go
and
apply
to
all
types
of
edges,
depending
on
what
the
qualities
are
of
that
particular
type
of
edge.
B
So
it's
a
it's
an
orthogonal
set
of
considerations
that
need
to
kick
in
and
if
you
would
go
and
consider
that
thing
as
a
kind
of
a
topology
or
a
landscape,
that
could
well
be
that
in
certain
areas
it
could
be
a
smart
device
Edge
that
needs
to
go
and
consider
Edge
native
design
principles
or
in
other
locations.
It
could
even
be
an
access
Edge
that
needs
to
go
and
consider
Edge
native
design
principles,
just
depending
on
where
this
is
where
it's
located
like.
B
If
this
access
ad
just
say
located
on
a
vessel,
then
well,
then
Edge
native
design
principles
might
apply
if
the
access
Edge
is
like
high
bandwidth
connected
with
fiber
or
dual
homed
on
whatever
at
a
particular
location
in
the
country,
then
it
might
not
apply
right.
So
I
think
that's
what
we're
trying
to
go
and
say.
B
Well,
that's
what
Andy
I
think
put
into
some
very
nice
words
in
in
this
section
to
go
and
re
resolve
the
confusion
between
the
or
the
anticipated
confusion
around
the
the
different
types
of
edges
that
were
qualified
in
an
earlier
paper
by
elevage
and
the
application
design
behaviors
that
we're
talking
about
here
and
it's
still
in
the
in
the
process
of
being
evolved.
As
you
see
like
certain
areas
in
this
table
for
considerations
and
the
likes
are
still
being
filled
out.
B
D
B
E
I
think
it's
more
I
think
that
that
terminology
ad
is
definitely
not
very
clearly
defined,
so
I
also
depend
on
the
background
like,
for
example,
I'm
more
of
a
traditional.
You
know
really
the
classic
database
guys.
So
so.
For
me,
the
the
all-time
Edge
Computing
means,
and
then
now
we
have
public
Cloud.
Let's
say
public
cloud
is
the
center
right,
so
Edge
means
even
for
customer,
like
just
a
customs
to
public
Cloud
right
they
their
their
own
data
center.
E
That's
also
considered
Edge
right
so,
but
in
that
case
the
edge
has
almost
exactly
the
same
connectivity.
You
know
speed
and
all
that
and
it
doesn't
even
involve
you
know,
iot
and
all
that.
So
so,
if
it's
so,
if
the
white
paper
is
say,
it
says
this
iot
Edge,
that
will
probably
be
more
I.
Guess
specific
for
for
what
was
described
in
that
paper,
because
you
say
at
Native
yeah
that
edge
could
be
could
be
just
a
customer,
Data
Center
and
that's
too.
B
That's
what
we're
saying
and
you
can
you
there's
nothing
specific
that
you
would
need
to
go
and
consider?
But
if
that
particular
customer
data
center,
as
I
said,
like
is
a
customer
data
center
that
is
situated
on
a
vessel
and
that
whistle
is
crossing
the
Pacific
then
suddenly
like
there
might
not
be
connectivity
on
the
vessel
for
a
particular
point
in
time
and
then
it
might
well
be
that
edge
native
application
design
Behavior
needs
to
go
and
deploy,
because
you
need
a
new.
B
Have
the
application
deal
with
the
fact
that
it's
not
always
on
that?
It's
not
always
connected,
so
what
we're
trying
to
go
and
say
in
this
short
paragraph,
and
maybe
we
should
go
and
make
it
even
more
expand
it
even
further-
is
that
the
type
of
edge
doesn't
necessarily
mandate
how
you
design
applications.
It's
a
it's
an
orthogonal
consideration.
B
And
that
means
sometimes
it
can
be
a
large
Edge
or
it
can
be
very
small
Edge.
In
many
cases
the
small
Edge
is
more
constrained,
but
doesn't
necessarily
need
to
be
right.
It
could
be
a
small
Edge
that
has
fiber
to
the
small
Edge.
Really
good
connectivity
will
be
always
on
Dual
homed,
just
because
it's
situated
in
in
a
in
a
metropolitan
area
where
there's
really
no
limitations
to
the
whole
thing.
B
E
B
And
that's
what
we're
struggling
with
here-
I
I
I,
fully
understand
that
and
which
is
why
we
probably
need,
maybe
even
more
like
that's
where
we
started.
Building
this
table
and
as
I
said
like
not
all
the
considerations
have
been
filled
in
you
know,
that's
something
that
Andy
is
still
working
on,
but
that
is
really
to
help
well
make
sure
that
there
is
a
common
understanding
that
these
design
criterias
are
trying
to
overcome
certain
constraints.
B
And
if
these
constraints
are
not
there,
then
we
don't
need
to
worry,
and
these
design
constraints
can
be
there
if
you're
very
far
from
the
the
central
cloud,
and
you
can
be
very
close
to
the
central
Cloud,
but
that
doesn't
really
matter
because
you
can
still
face
these
constraints
and
and
the
design
behaviors
are
just
to
overcome
these.
These
constraints,
around
latency
requirements,
bandwidth
requirements,
availability
and
the
likes.
E
So
that's
also
sort
of
sometimes
not
even
constrained
by
networking
connectivity,
but
it's
some
other
different
kind
of
constraints,
so
yeah,
it's
so
it'll,
be
I
would
say
it
would
be
nice
to
have
a
uniform
definition
for
that.
But
right
now
the
definition
from
like
the
RF
Edge,
the
definition
from
the
tradition,
National
Edge
yeah.
All
that
is
a
little
different.
That's
the
hard
part
yeah.
B
And
we're
not
trying
to
go
and
Define
edges
again
here
right.
This
is
more
like,
as
I
said
like
what,
if
Cloud
native
application
design
principles,
don't
really
work
anymore
for
a
variety
of
reasons,
so
these
constraints
that
we
we've
just
been
discussing.
What
do
I
need
to
go
and
do
differently
from
an
application
design
perspective
so
that
it
can
go
and
deal
with
these
constraints.
I
think
that's
what
we're
trying
to
go
and
solve
in
that
white
people
yeah.
E
B
Whenever
you're
rotating
you
have
intermittent
connectivity,
whenever
the
data
center
faces
the
work,
the
the
the
Earth
then
you'll
have
connectivity
and
then,
if
you're,
on
the
dark
side
of
the
the
Mars
or
the
moon,
then
you
won't
have
connectivity
and
so
yeah.
Even
if
you
put
a
large
data
center,
there,
Edge
native,
would
very
likely
apply
so
I
think.
That's
that's!
A
This
reminds
me
of
a
discussion
that
we
had
when
we
were
making
the
edge
native
application
principles
when
we're
it's
impossible
to
start
any
Edge
initiative
without
debating
over
the
definition
of
Edge,
and
we
found
that
where
there
were
three
kind
of
categories
of
definitions,
one
was
location-based
Edge,
which
or
geography
based
Edge,
namely,
how
far
is
the
data
from
the
user?
The.
D
A
Was
network
based
Edge,
which
is
kind
of
sounding
like
we're
getting
here
with
how
connected
is
that
device
to
a
network
and
what
is
it
the
behavior
of
connectivity
and
the
last
was
resource
based
Edge,
so
how
Edge
is
it
means
how
many
resources
are
around
it
and
how
important
is
that
to
it
as
a
system?
So
is
it
the
last
server
near
all
these
iot
devices
or
does
its
environment
instead?
Look
like
a
data
center,
but
it's
actually
just
kind
of
disconnected
or
in
a
different
facility.
A
B
B
C
A
Yeah
I
think
this
gets
to
the
question
of
is
the
solution
and
it
seems
like
the
problem
here
is:
how
do
we
Define
what
these
application
behaviors
should
be
when
an
application
here
is
so
different,
so
varied,
because
Edge
is
very
varied
and
I'm
wondering
if
one
mentioned
that
Victor
said
was
scoping
the
definition
to
iot
or
would
another
option
be
to
kind
of
create
a
spectrum
of
issues
and
allow
every
design
Behavior
to
be
targeted
to
a
certain
issue?
So
you
don't
need
to.
You
only
need
to
have
data
persistence.
A
B
B
We
had
different
different
capabilities
that
you
need
to
go
on
different
design,
behaviors,
based
on
the
constraints
that
you're
facing,
so
that
you
can
check
them
off,
for
an
odd,
like
applies,
doesn't
apply.
If
you
don't
worry
about
storage
like
because
everything
is
anyway
stateless,
then
well,
it
doesn't
apply
at
all
right,
so
yeah,
maybe
I
think
that's
a
good
idea.
We
should
go
and
we
can
go
and
try.
E
D
E
Maybe
it's
because
of
a
database
guy
I'm
kind
of
a
when
it
comes
to
stylus
my
understanding
at
least
the
edge
I
do.
Is
you
leave
off
database
database?
That's
probably
why,
when
I
have
a
like
Edge
location,
even
if
it
means
that
data
center
on
a
machine
right
having
a
really
staple
backup,
recovery
mechanism
is
more
important
than
like
a
regular
Edge.
You
know
like
if
you
have
in
the
data
center,
you
have
backup
constantly
running
in
a
you
know.
Backups
can
be
restored
in
in
a
cloud
right.
E
B
I
hear
you
I
think
these
are
good
points.
Let's
see
whether
we
can
go
and
see
whether
we
can
go
and
decraft
the
table
with
the
different
considerations
and
how
they
apply,
because
then
then
this
is
also
less
of
a
a
one.
Size
fits
all,
which
is
very
clearly
not
working
for
the
edge
right.
So,
let's
that's
I
think
the
conclusion
that
everybody
was
very
likely
under
subscribed
to
right,
hey,
Andy,
thanks
for
joining,
so
we
we
just
jumped
into
the
discussion
on
well.
B
Where
does
they'll
do
these
design
principles
apply
and
that
we
try
to
go
and
articulate
that
or
what
we
try
to
go
and
articulate
in
the
update
and
I
was
just
speaking
for
you
is
that
the
the
original
taxonomy
around
like
different
edges,
that
are
mostly
tried
to
who
owns
the
the
thing
and
then
what
type
of
organization
is?
It
is
somewhat
orthogonal
to
the
design
behaviors
that
we're
trying
to
go
on
articulate
because
a
data
center
in
a
metropolitan
area
is
different
than
a
data
center
on
a
vessel.
B
B
So
and
then
maybe
we
can
go
and
come
up
with
something
where
we
have
the
different
design
constraints
around
like
data
around
resources
around
networking
and
I
think
those
were
the
main
pillars
and
maybe
overlap
with
policy,
and
we
have
that
in
table
and
then
have
the
design
behaviors
and
then
see
whether
we
can
go
and
do
a
mix
and
match
okay,
so
that
we
are
less
kind
of
prescriptive
about
like
there's
only
black
and
white
and
black
and
white.
Obviously
that
never
exists
right.
B
So
there's
all
kinds
of
things
at
the
edge
that
are
say
more
diverse,
because
your
Edge
is
different
than
my
Edge
and
what
is
central
for.
You
is
Edge
for
me
and
and
vice
versa.
So
maybe
that's
a
good
way
to
go
and
express
it
so
that
we're
trying
to
evolve
that
table
a
little
bit
further
and
then
I'm
trying
to
be
less
than
a
one
size
fits
all.
We
can
still
have
all
these
behaviors,
but
from
an
applicability
perspective.
We
we
are
a
little
bit
more
Diversified
and
I.
B
F
You
remember
so
you
remember
we
talked
last
week
and
we
were
I
was
saying,
let's
add
a
column,
to
the
tiering
for
considerations,
and
so
that's
what
I
was
thinking.
I
was
thinking
along
those
same
lines,
but
it
I
was
you're
coming
at
it
from
one
end,
I'm
coming
out
from
the
other
end,
it
was
the
considerations
as
they
align
for
each
of
the
different
sectors
that
or
sections
that
we
have
so
for
this
you
would
be
ephemeral.
This
would,
you
would
be
less
right,
et
cetera,
et
cetera
for
storage,
so
yeah.
F
That
was
the
same
sort
of
principle.
So
even
you
know
what's
pretty
cool
about
that
is.
We
could
actually
use
that
as
a
pivot,
so
the
considerations
can
be
used
both
for
understanding
what
type
of
data
center
you
have
or
what
type
of
edges
you
have,
and
it
could
also
be
used
as
a
way
to
connect
that
back
to
tiering
as
well.
F
B
D
Yes,
because
at
the
edge,
sometimes
there
are
some
applications
that
need
a
higher
slas,
so
maybe
having
a
two
node
configuration
in
case
of
node
failure.
But
then
the
problem
is
the
share
PV
between
the
two
nodes
right,
because
kubernetes
usually
calls
for
three
nodes.
That's
one
consideration
and
the
other
consideration
is
having
a
shared
storage
solution.
That
is,
that
fits
in
a
in
a
in
an
edge
right.
D
B
D
D
B
E
I
know
this
is
CS
yet,
but
maybe
the
the
solution
for
Edge,
just
because
it
is
so
extreme,
doesn't
have
to
be.
You
know
like
kubernetes.
Only
right,
we
already
know
he's
not
so
just
anything
that
works,
for
example
the
for
database.
Let's
say
if
we
have
a
a
remote
bank
right,
if
you're,
if
you
have
a
remote
location
on
the
moon
and
you
have
to
build
a
local
bank,
that
transaction
cannot
be
lost
right.
E
E
Yeah
I,
probably
I'd,
only
learn
about
a
web.
Stampy
I've
joined
this
team.
Actually,
no,
okay.
Do
you
talk
about
it?
So
so
this
is
my
understanding.
So
there
are
a
lot
of
right
now
to
work
being
done.
You
know
several
work
groups
so
that
the
the
web
assembly
can
be
run
directly
by
the
by
kubernetes
instead
of
you
know,
having
put
in
within
the
particular
container,
so
right,
right
now,
I
think
I.
E
A
It's
just
maybe
there's
work
to
remove
the
second
layer
of
isolation,
but
I
do
think.
There's
been
I'm,
not
I'm
curious.
What
other
level
of
orchestration
they
could
add,
given
that
it
has
the
same
level
currently
besides
they're
working
on
right
now
supporting
resource
limitations
with
webassembly
as
well.
So
right
now,
of
course,
with
containers,
you
can
say
only
use
this
much
memory,
CPU
et
cetera
and
they're,
working
on
adding
that
same
declarativeness
to
the
webassembly
experience
for
kubernetes.
E
Yeah
I,
don't
know
the
the
technical
details.
I
just
heard
overall,
what's
being
worked
on,
my
understanding,
I
mean
of
course,
once
they're
being
managed
by
kubernetes
it's
possible
to
make
it
part
of
a
the
whole.
You
know
microservices
Cloud
native
experience
right,
so
there
could
be
some
overlapping,
so
what's
what's
being
described
at
Native.
Could
change
actually.
A
C
Let's
say,
parameters
IP
addresses
credentials
this
and
that
maybe,
but
on
the
other
hand,
for
each
devices,
if
you
have
a
small
enough
Raspberry,
Pi
somewhere
and
it
gets
lost
in
the
in
the
field.
Is
that
something
that's
quite
interesting
when
it
comes
to
like
having
such
kind
of
self-discovery
modes
or
because,
as
far
as
I
understand,
there's
no
such
thing
that
exists
for
a
lot
of
these
kind
of
devices?
C
B
If
I
can't
reach
it
anymore,
I
just
have
somebody
go
there
and
hit
factory
reset
or
or
cycle
it,
and
then
you're
done
I.
Think
that's
one
of
the
things
that
you
want
to
go
and
design
towards,
especially
in
locations
where
it's
difficult
to
go
and
reach
these
locations
and
operate
them
and
and
even
send
like
it
personal
there.
E
State
listing
is
another
keyword
as
I'm
still
trying
to
get
a
grasp
of
just
being
in
the
community
for
not
too
long.
For
example,
kubernetes
is
also
designed
to
be
stainless
when
it's
first
design,
but
there
are
a
lot
of
effort
trying
to
put
database
running
on
kubernetes
as
a
really
serious
Enterprise
database
data
store
running
on
kubernetes.
So
this
is
no
longer
stainless,
so
yeah
I
guess
how
do
we
Define
stylus,
when
we
have
a
a
banking
application
running
on
an
edge.
B
You
know
what
do
you
run
on?
Kubernetes
is
your
problem
right,
so
at
the
end
of
the
day,
but
I
think,
but
the
main
design
principles
for
for
cloud
native
r
d,
like
you,
you
design
processes
to
be
stateless,
because
you
want
to
go
and
farm
out
your
state
into
a
into
a
persistent
store
like
a
database
and
be
able
to
retrieve
it
from
there
in
case
you
trip
over,
because
otherwise,
horizontal
scalability
is
just
not
there
and
yes.
Well.
F
B
F
Think
we
take
any
specific
stance,
and-
and
this
is
just
going
back
to
the
paper
that
we've
been
hacking
on
on
statefulness
versus
non-stateful,
necessarily
right,
but
the
idea
is
is
that
is
you
know
when
you're
talking
about
Banking
and
the
potential,
for
you
know
data
storage
or
compute
at
the
edge
right?
Let's
say
it's
a
branch
you
want
to
be.
F
You
know,
there's
also
all
kinds
of
considerations
that
you
have
to
be
careful
with
in
terms
of
compliance
right
for
the
and
the
regionality
and
transfer
of
data
that
so
I
I
put
a
little
more
references,
emphasis
on
compliance
and
sovereignty
and
rules
that
govern
the
transfer
of
data.
In
that
respect,
less
so
than
I
do
put
on
any
any
specific
architecture
that
we
might
impose.
As
a
result
of
you
know
the
work
that
we're
doing
I
don't
know.
Would
you
agree
with
that?
Frank
yeah.
B
And
then,
even
more
so
right,
so
we're
trying
to
go
and
recommend
what
might
be
useful
to
go
and
has
that
have
as
a
goal
yeah.
You
might
not
get
there.
But
if
you
design
towards
the
goal,
then
your
life
is
definitely
simpler
than
you
have
a
a
tight
linkage
between
your
code
and
State.
If
you
manage
the
state
as
part
of
your
code,
then
the
whole
thing
is
very
difficult
to
scale
and
very
difficult
to
maintain
in
many
locations.
E
Originally,
for
example,
database
on
kubernetes.
You
use
it
for
like
a
transient
database
for
caching
right
for
running,
like
what
is
called
anyway,
just
just
like
something
you
can
reload
from
somewhere
else.
That's
usually
the
when
you
run
database,
but
but
now
there's
a
push
to.
It's
also
really
how
to
say
a
requirement
right,
because
more
and
more
people
want
to
don't
want
to
run
just
pure
bare
metal
hardware
anymore
and
not
even
virtual
machine
wherever
possible.
E
So
but
on
the
other
hand,
the
database,
you
imagine
that
you
have
a
database
running,
kubernetes
and
and
and
the
key
is
also
encrypted
right.
The
encrypted
key
needs
to
be
stored
in
a
in
a
in
a
key
store
and
that
key
store
is
super
important
because
because,
if
you
lose
that
key
store,
everything
is
everything
else
is
gone
right
in
the
cloud
in
the
public
Cloud.
It's
not
a
problem,
because
that
is
managed
and
replicated
by
the
public,
Cloud
vendors.
E
But
now,
if
you're
on
the
edge,
where
every
let's
say,
there's
no
bare
metal,
there's
no
virtual
machines,
pure
kubernetes,
you
have
both
the
key
store
and
the
database
running
on
kubernetes.
So
the
the
critical
technicality
of
that
both
the
keystore
and
the
database
is
so
important
because
if
you
lose
it,
it's
not
backlab
anywhere
right
because
there's
no
easy,
remote
backup
solution
at
the
edge.
F
E
Know
true,
yeah
key
store
can
still
be
done,
but
let's
say,
if
you
have
a
very
intensive
application
on
the
edge,
have
a
database
local
database.
If
you,
if
some
part
of
it
at
least,
is
so
critical,
you
cannot
lose
it,
but
there's
no
because
of
network
connectivity
issue.
You
don't
have
a
constant
backup,
like
you
do,
on
a
public
cloud
or
even
on
premise,
then
having
a
really
a
solid
Hardware
that
you
know
triple
mirrored
right,
not
not
losing
data
become
even
more
important
than
on-premise.
F
F
Would
probably
point
that,
back
to
another
design,
consideration
right,
I
mean
if
the
if
the
data
is
that
important
I
wouldn't
leave
it
with
one
copy,
I
mean
I'm.
Sure
you've
already
thought
through
this
right,
so
I'm
not
telling
you
anything,
you
don't
know,
but
it's
we're
not
trying
to
overcome
those
types
of
hurdles
right.
Those
things
are
but
we're
trying
to
give
guidance
around
what
maybe
you
should
think
about
I
mean
if
you're
looking
to
impart
more
Victor
I,
really
like
you
know
what
you've
you've
done
in
terms
of
giving
us
feedback
and
input.
F
If
there's
more
there
that
can
be
expressed
in
terms
of
you
know,
hey
look.
You
might
want
to
make
sure
that
you
back
up
your
key
store,
hey
look!
You
might
want
to
make
sure
that
you
don't
have
a
single
copy
of
your
database
running
somewhere
and
maybe
have
some
duplication
or
some
replication
scheme.
I
think
that
would
be
really
helpful
feedback.
We
certainly
could
incorporate
something
like
that.
I
think
those
are
the
types
of
traps
that
we're
looking
to
incorporate
Frank
right.
F
F
I
think
Victor
I.
You
know
what
we
didn't
write
Baptist
about
a
key
store
right,
nothing
in
relation
to
that.
So
that
would
be
I
really
think.
That's
low-hanging
fruit
right
there
in
terms
of
database
considerations,
I'm,
so
sure
we
could
firm
up
what
we
have
there
to
to
cover
it
more
so
I
encourage
you
to
contribute
there.
E
It's
interesting
topic
so
just
like
Kate
I
think
Kate
bringing
up
a
good
I,
don't
know
where
Kate
you
got
that
that
classification
of
an
edge
based
on
network
resource
and
location
simply
a
good
starting
point.
I'm,
not
sure
you
got
that
you
did
you
come
up
with
that.
The
network
and
resource
location,
classification
and.
A
E
I
also
believe
Frank
already
had
a
great
idea.
Maybe
you
have
a
like
a
different
for
different
classification.
There
would
be
different
features
that
apply
like
you
know,
classes
for
this
type,
stateless
for
this
type
of
application-
maybe
maybe
not
for
that
type
and
coming
back
to
the
backup,
for
example,
if
I
have
a
database
on
the
on
the
ship,
even
if
I
want
to
back
up,
but
Network
could
be
down
during
the
storm
right,
for
example,
right.
E
B
That's
exactly
what
we
need
to
go
and
then
state
right,
so
that
if
you
really
want
longer
term
persistence
at
the
edge
and
you
Freight
that
one
Edge
might
go
down,
then
that's
exactly
where
Andy
was
hitting
hinting
I
mean
earlier
on
that
you
need
replication
of
State.
Maybe
you
actually
put
two
edges
onto
the
very
same
vessel
and
that
these
two
edges
can
go
and
back
edge
up
each
other
up
because
they
have
a
mutual
reachability.
Even
if
they,
the
cloud
disappear
right,
yeah,
well,
Annie.
Nobody
can
share.
That's
the
problem.
Oh.
F
That
would
be
considerations
that
would
define
further
what
we
mean
by
that
specific
row
right
and
so
for
in
the
case
of
what
I
have
written
out
there.
It's
just
on
the
tiering,
but
it
doesn't
have
to
be
specific
to
that.
We
could
talk
about
it.
Being
classifications
and
categories
like
Kate
has
so
I
think
that
that's
you
know
if
you're
willing
to
put
pen
to
paper
there,
you
could
use
your
help
in
figuring
that
out.
C
Yeah
and
I
think
address
Victor's
point
of
key
stores
on
such
kind
of
edges,
so
there
are
hardware
specs
out
there,
where
you
can
use
Concepts
like
TPMS,
where
you
store
the
core
essential
things
like
certificates
and
a
little
bit
more
than
that
chances
are.
There
are
much
more
higher
end
stuffs
that
you
can
now
do
with
TPM,
V2
I.
C
Think
if
I'm
not
wrong
so
yeah,
there
are
certain
so-called
security
guarantees
that
the
hardware
provides
on
the
edge
where
you
can
have
certificates
in
them,
or
maybe
some
form
of
access
credentials
which
are
extremely
valuable.
Even
though,
if
one
of
the
things
goes
down,
the
DPM
still
holds
that
critical
value
out
there
and
I
think
the
other
part
was
beyond
the
key
stores.
C
So
you
there
are
certain
Concepts
out
there,
like
spiffy
Inspire,
where
you
are
your
Edge
devices
proactively
work
to
prove
that
they
are
actually
the
devices
that
your
applications
are
bound
to,
for
example,
connect
as
opposed
to
just
blindfoldedly,
accepting
the
certificate,
because
in
very
rare
cases
there
are
chances
where
certificates
can
be
spoofed
too.
So
you
can
have
a
very
malicious
Edge
device
that
something
like
stuck
next,
though,
where
some
someone
can
plug
in
a
USB
device
and
things
can
go
Haywire
really
quickly.
C
So
in
order
to
do
see
these
kind
of
things,
I
think
the
concept
of
zero
trust
also
starts
to
trickle
in
these
days,
although
it's
a
bit
too
fresh
for
the
edge
native
landscape,
because
it
comes
with
a
lot
of
complexity
to
to
bind
it
but
yeah,
it
should
answer
a
lot
of
questions
in
the
future
when
it
comes
to
trust
on
edge
native
applications.
Yeah.
F
We're
doing
some
work
so
in
the
open
source
code
Stellar,
which
is
the
project
that
I
represent,
we're
doing
some
work
with
open
ZD,
which
allows
you
to
you
know
which
they
figured
out
a
way
to
have
a
TLS
based
library
that
you
can
just
incorporate
at
your
endpoints
right.
So
both
southbound
and
Northbound
traffic
can
be
encrypted
right
out
of
the
gate,
so
it
just
basically
by
turning
on
a
feature
switch
which
is
real
nice
right,
so
yeah
I,
agree.
I.
F
You
can
call
in
the
intermediary
body
or
entity
and
either
way
you
slice
it
you're
not
guaranteed
that
you're
a
going
to
be
on
the
same
service
provider.
So
it
could
be
a
hyperscaler,
it
could
be
AWS,
gcp,
Azure,
IBM,
Alibaba
or
it
could
be
something
more
Regional.
It
could
be
a
sovereign
Cloud.
It
could
be
just
a
you
know.
It
could
be
just
somebody
hosting
a
device
in
a
you
know,
out
on
some
railroad
tracks
in
the
middle
of
Canada.
F
B
B
We
made
the
case
for
kind
of
adding
two
additional
example:
scenarios
around
industrial,
iot
and
Telehealth,
but
he
just
made
the
Highlight
the
the
kind
of
the
headline
for
that.
What
we
don't
really
have
any
content
for
that
I'm.
Just
wondering
whether
it's
anybody,
that
is,
that
feels
like
adding
content
for
that,
because
well,
the
even
the
summary
I
I'm,
not
sure
whether
we
want
to
be
that
perspective,
prescriptive
about
like
latencies
and
bandwidth
and
whatever,
because
different
applications
might
behave
differently.
B
But
if
we
had
more
testimonials
or
initial
sample
scenarios,
that's
obviously
always
beneficial
because
it
means
like
people
can
connect
these
things
more
to
reality
and
more
grounded.
If
you
have
examples
there.
So,
if
somebody
feels
like
he
wants
to
go
and
throw
in
an
example
that
would
be
awesome.
A
A
That
make
sense
since
we're
at
the
top
of
the
hour,
just
a
reminder
to
add
your
name
to
the
agenda
for
today.
If
you
would
like
and
then
maybe,
if
anyone
does,
anyone
have
agenda
items
or
things,
they
would
like
to
see
in
future
meetings
certain
speakers
or
topics
that
you
would
like
folks
to
reach
out
to
just
as
a
last
call.
We
can
certainly
also
add
time
to
discuss
some
of
these
use
cases.
The
next
meeting
as
well,
if.
F
A
A
Worries
but
yeah.
So
if
there's
no
desires
or
agenda
items
for
next
to
me
meeting,
we
can
continue
the
white
paper
discussion,
birds
of
the
feather.
We
always
fill
the
time,
but
if
there
is
something
that
you
would
like
to
see
in
a
meeting
feel
free
to
throw
it
in
chat
and
we
can
reach
out
to
folks
from
different
areas
as
well.
Hey.
F
Kate
point
of
information
I,
don't
know
if
you've
already
covered
it,
but
one
of
the
things
and
I
don't
have
the
note
open
right
now
or
I
put
it
in
there
myself
is.
Do
we
have
any?
Is
there
anything
that
this
working
group
is
looking
to
promote
or
put
in
for
the
cfp?
I
think
it
just
closed
for
North,
America
or
and
for
Shanghai
for
kubecon
is
have
those
talks
already
been
entered?
Is
there
anything
coming
out
of
this
out
of
this
working
group.
A
Yeah
the
maintainer
track
sessions
for
the
cfps.
We
might
still
be
able
to
submit
something
for
I'll
check
in
on
that
I've
been
out
for
the
past
few
weeks,
so
I
missed
some
of
the
past
meetings,
so
I
wasn't
sure
if
we'd
already
covered
that
sounds
like
we
haven't,
but
yeah,
usually
the
maintain
your
track
sessions
are
open
for
a
little
while
after
so
I
can
check
in
on
that.
I
do
know
that
they've
changed
that
system
a
little
bit
to
the
point
where
we're
not
guaranteed
a
session
anymore.
A
B
A
A
Yeah
and
Mark,
if
you
have
something
that
you
want
to
present
next
session,
feel
free
to
throw
it
on
the
agenda
there
and
then
for
folks
who
aren't
familiar
in
order
to
be
an
editor
of
the
document.
You
just
have
to
add
the
Google
Group,
which
is
ADD
yourself
to
the
Google
Group,
which
is
open,
so
that
gives
you
the
right
study
all
right.
Well,
thank
you.
Everyone
for
going
over
and
see
you
in
a
couple
weeks,
yeah.