►
From YouTube: Kubernetes WG IoT Edge 20230426
Description
April 26, 2023 meeting of the CNCF IoT Edge Working Group. Intro to OpenZiti. Also Edge Native Draft White Paper Supplemental Assets discussion
A
Hi
welcome
to
the
April
26th
meeting
of
the
cncf
iot
edge
working
group.
We've
got
a
few
items
on
the
agenda
today,
a
an
intro
to
open
ZD,
followed
by
a
discussion
of
the
edge
native
white
paper,
supplemental
assets
and
I
show
Brandy
Andy
Brandon
Andy
Frank
Herve,
whose
name
I
may
have
mispronounced
Joel
and
Philip
as
participants
or
people
who
nominated
that
to
the
agenda.
A
Also
I'll
just
take
a
minute.
To
recap:
some
of
the
interesting
things
that
I
observed
at
kubecon
since
I,
don't
think
I've
seen
any
of
the
people
in
this
meeting
there,
but
I
saw
some
cool
stuff
and
that
first
of
all,
the
kubernetes
on
the
edge
day
was
well
attended
and
had
some
great
talks.
A
I
think
that
you
could
go
to
the
sked
site
and
download
people's
decks
from
that
now
I
know
I
can,
but
maybe
it's
just
because
I
have
an
account
but
I
passed
past
operation
of
that
skid
site
left
those
things
open
to
the
public.
In
my
experience,
I'm
guessing
the
cncf
will
publish
recordings
of
those
in
a
month
or
two
based
on
how
they've
behaved
in
the
past.
A
What
did
I
see
there?
That's
cool
well,
a
couple
things
and
I've
got
pictures
of
these-
that
I
I
made
notes
in
the
agenda
notes,
but
I
have
to
scrape
the
pictures
out
of
my
camera,
but
the
harbor
or
image
registry
added
some
new
features
for
operating
their
image
registry
for
Edge,
even
in
an
air
gap
boat
or
with
very
intermittent
connectivity.
A
That
should
be
useful
to
many.
That
registry
holds
classic
OC
Docker
containers,
if
you
will,
but
it's
actually
oci
containers.
So
you
can
host
web
assemblies
as
well
and
it
also
hosts
Helm
charts.
A
Another
thing
that
I
thought
was
the
coolest
at
the
show:
it's
not
released
yet,
but
they
had
a
booth
and
it
was
a
pre-announcement.
A
division
of
Sony
called
medakura
announced
an
attempt
to
come
up
with
an
abstraction
layer
for
mlai
accelerators
on
edge
devices,
and
they
said
that
they
intend
to
open
source
this
work
in
a
June
time
frame
and
had
some
demos
going
on
in
a
booth
and
I've
got
a
picture
of
kind
of
their
elevator
pitch
of
what
they're
up
to.
A
But
it's
basically,
this
concept
that
you
know
you've
got
a
variety
of
these
Edge
accelerators
out
there
anything
from
the
older
Jetsons
to
you
know:
lower
costs,
lower
resource
devices
and,
if
you're
going
to
develop
software,
you
don't
really
want
to
have
to
deal
with
every
one
of
them
out
there.
A
So
they're
attempting
to
come
up
with
a
abstraction
layer
on
that
and,
interestingly
enough,
rather
than
it
being
an
API
they're
implementing
this
in
the
form
of
a
piece
of
a
web
assembly,
adapter
you'd
use
so
that
somebody
coming
up
with
this
could
potentially
have
it
consumed
by
people
on
any
CPU.
A
As
I
understand
it,
okay,
it's
in
the
it's
in
the
notes
now,
including
a
picture
picture.
D
F
Thanks
even
thanks
everyone's
time
today,
this
this
came
from
Victor
who's,
actually
on
the
call
with
us
we're
both
part
of
the
the
CNF
working
group
on
xero
trust,
and
he
mentioned
this
group,
which
then
got
me
on
a
rabbit
hole
of
going
into
white
paper
and
I.
F
I
saw
some
very
interesting
things
in
there
and
then
talking
within
the
the
slack
someone
said
hey
when
it's
coming
on
presenting
and
see
how
how
it
impacts
and
I
think
that'll
lead
into
the
white
paper
conversation
that
comes
next
quick
introduction
know
what
am
I
doing.
Why
was
I
interested,
etc,
etc?
So
I
work
on
a
open
source
project
called
open
ZT.
F
If
you
are
familiar
with
xero
trust,
you're,
probably
familiar
with
the
the
service
meshes
within
kubernetes,
which
are
highly
focused
on
server
to
server
East-West
kubernetes
based
workloads,
ZT
comes
from
the
opinion
that
we
should
be
able
to
apply
these
capabilities
to
absolutely
anything
so
whether
you're
connecting
users
to
sites
or
services
to
services
or
Edge
and
iot.
You
can
do
that
without
trust
in
any
networks
at
all.
You
do
not
need
vpns,
you
don't
need
public
DNS,
but
yet
you
can
connect
things
across
the
WAN
across
the
land
or
in
any
way
possible.
F
We
do
this
by
operating
effectively
an
overlay
Network
which
can
be
in
integrated
into
anything
that
either
operates
at
a
network
level,
a
host
level
or
even
at
an
application
Level
using
software
development
kits,
for
example,
we
are
working
with
Ajax
Foundry,
which
is
a
big
project
within
our
our
sister
organization
of
LF
Edge,
where
they're
embedding
our
go
SDK
into
all
of
our
packages,
so
that
the
the
application
can
run
in
a
OT,
Edge
or
iot
Edge,
and
not
trust
the
underlying
Network
for
that
East-West
connectivity
within
that
Network
or
north-south
connectivity
across
the
wide
area
network,
as
well
as
potentially
attaching
to
things
southbound
of
that
edge
environment
as
well,
and
so
when
I
came
across
the
white
paper
and
I
saw
it
talking
about
how
to
apply
zero
trust
principles
in
the
iot
edge.
F
I
thought.
That
is
definitely
something
I
want
to
be
contributing
to,
because
I'm
already
contributing
to
the
cncf
paper
on
xero
trust
as
applied
to
Cloud
native
architectures
and
I.
Believe
we
have
a
interesting,
unique
perspective
around
how
that
can
be
applied
to
the
edge
in
iot
and
effectively
anywhere.
A
F
Best
demonstrated
with
a
slide
I
think
so
ZT
can
be
broken
down
into
two
components:
The
Edge
and
the
fabric,
and
this
can
all
this
can
all
be
within
a
local
network
or
it
can
be
distributed
across
the
world.
In
fact,
I'm
working
on
a
use
case
at
the
moment
where
we're
looking
to
apply
this
to
low
F
orbit,
satellites
and
so
effectively,
you
have
a
component
of
the
edge
at
source
and
a
component
of
the
edge
at
destination,
either
at
the
network
level,
the
host
level
or
the
application
Level.
F
It
consumes
a
strong
identity
and
it
gets
told
by
the
control
plane
how
it
is
going
to
reach
from
Source
or
from
source
to
destination
or
destination
to
Source.
Those
edges
don't
need
to
have
any
concept
of
the
network
other
than
outbound
connectivity,
because
all
of
that
is
just
magically
handled
by
the
fabric.
The
fabric
is
what
allows
us
to
operate
over
any
underlay,
whether
it
is
Lan
or
Wan,
in
order
to
be
able
to
bridge
those
two
environments.
F
F
So
our
default
is,
you
should
not
trust
the
underlying
network.
You
should
not
trust
underlying
Network
identifiers
such
as
IP
and
DNS,
so
we
mandate,
starting
with
strong
identity.
Ziti
has
its
own
built-in
certificate.
Authority,
though
you
can
bring
your
own.
If
you
want
to
exist
on
the
overlay,
you
have
to
go
for
a
process
of
bootstrap
and
Trust.
A
I
think
it
does.
You
know
one
of
the
one
of
the
things
that
comes
up
persistently
in
this
Edge
group
is
even
that
bootstrapping
trust
with
Edge,
where
you
dispatch,
maybe
hundreds
of
thousands
of
these
out
at
remote
locations
with
no
trained
staff,
and
yes,
often
things
that
work
in
a
traditional
data
set
data
center
fall
apart.
There.
A
F
Agreed
and
our
opinion
here
is
the
lot
so
there's
actually
a
few
opinions.
F
Part
of
the
work
that
we're
doing
with
Ajax
Foundry
is
how
we
work
with
volt
to
take
that
identity
system,
but
to
ensure
that
Vault
isn't
exposed
to
the
network,
and
it's
only
talking
to
ziti
and
therefore
able
to
to
bootstrap
and
and
bring
on
Services
simultaneously
we're
doing
some
work
with
open
Horizon,
which
is
a
a
project
sponsored
by
IBM
Intel
and
a
few
other
organizations.
And
one
of
the
conversations
we're
having
was
well.
F
You
could
ship
devices
which
have
raw
Hardware
to
trust
either
in
an
additional
component,
a
USB
or
in
your.
You
know
your
flash
memory
or
something
like
that
with
Micron
authenta
along
those
lines,
and
you
could
have
it
so
that
your
your
connection
to
to
the
certificate
Authority
for
the
registration
could
be
over
the
zero
trust
overlay
so
that
the
certificate
Authority
doesn't
have
to
be
exposed
to
the
internet.
And
it
doesn't
have
to
know
where
all
these
ideas
come,
because
it's
only
coming
over
the
overlay
with
the
identity.
In
the
first
place.
F
The
data
plane
is
all
TCP
UDP,
so
the
these
connections
today
are
all
being
built
on
on
TCP,
but
you
can
obviously
send
other
protocols
on
top
of
it.
We
do
have
a
an
item
somewhere
in
the
future,
where
we'll
switch
it
to
UDP
but
fullback
to
TCP,
but
that's
so
we
could.
We
could
do
point
to
point
without
having
to
go
through
one
of
the
nodes,
but
right
now
yeah,
it's
TCP.
Basically,.
A
A
In
there
right
now,
but
so
the
whole
deck
would
be
useful
and
I
also
post
links
to
the
project
and
the
project
docs,
so
I
think
there
might
be
a
lot
more
there,
but
Philip.
This
was
great.
This
looks
really
interesting
and
useful.
A
And
the
way
that
works
well
stick
around
because
I
think
there'll
be
a
discussion
on
it,
but
it
is
democratized.
So
if
you
just
join
the
group,
go
for
it,
I
don't
know.
If
you're
also
listed
at
this
group
has
a
spreadsheet
work,
attempting
to
compile
of
edge
native
open
source
projects.
It
now
has
north
of
150
things
on
that
list.
You
might
already
be
there
because
people
have
been
adding
a
lot,
but
if
you're.
E
A
H
H
Wanted
to
introduce
this
next
topic
with
a
little
bit
of
context
and
some
background
on
how
we
got
to
where
we
are
so.
A
smaller
group
of
us
sort
of
a
subset
have
been
working
on
an
idea
of
how
to
expand
the
edge
native
application
principles
white
paper
that
we
published
last
year
so
that,
as
a
starting
point,
I
think
started
our
thinking
about
how
to
take
these
principles,
which
we've
now
defined
and
make
them
a
bit
more
actionable.
H
And
one
of
the
ways
to
do
that
is
to
think
about
how
to
apply
those
principles
through
development
and
the
behaviors
of
developers
who
are
creating
applications
specifically
for
the
edge
trying
to
capture
a
lot
of
that
wisdom,
but
then
think
about
structuring
it.
In
a
way.
That's
a
little
bit
more
predictable,
a
little
bit
more
kind
of
a
standardized.
H
You
know,
from
the
point
of
view
around
development,
best
practices
and
yeah
how
to
how
to
take
these
Concepts
and
and
move
them
to
the
next
Evolution,
where
we
feel
like
there'd,
be
more
practical
so,
rather
than
proposing
that
we
add
on
to
the
existing
paper.
I.
H
Think
our
our
thinking
right
now
is
more
about
treating
this
as
a
supplementary
piece
and
that
I
think
was
part
of
the
original
intent
of
the
white
paper
as
well
to
sort
of
serve
as
the
foundation
and
allow
for
supplementary
pieces
to
come
together
in
congruence
with
that
and
to
continue
to
build
on
the
core
principles
of
the
paper
and
be
useful
for
the
industry.
So
this
is
our
draft
effort
in
in
doing
that,
we
originally
were
calling
it
the
manifesto
and
we
realized.
That's
that's
not
a
good
name.
H
H
H
So
maybe
the
best
place
to
start
is
frankenhurst.
Just
could
briefly
introduce
yourselves
and
your
interest
in
this
topic,
and
then
Frank
is
has
a
draft
version
of
this
paper
that
we
could
go
through
with
the
group,
so
maybe
also
Frankie
could
share
a
link
in
the
chat
and
then
share
your
screen.
I
Then
I
can
absolutely
do
that
and
then
yeah
thanks
for
the
intro
and
yeah,
so
on
myself,
I'm
working
on
a
Cisco
Edge
native
project.
So
this
is
how
this
all
thing
came
together
and
a
while
ago,
I
was
at
the
one
Summit
that
was
used
to
be
called
like
the
open
networking,
Summit
and
whatever
Brandon
and
I
met,
and
we
quickly
discovered
that
well,
we
were
working
on
very
similar
things
and
that
it
might
be
useful
to
go
and
at
some
point
join
forces.
I
And
then
I
had
a
detailed
read
through
through
the
the
white
paper
as
it
sort
of
initially
like
or
the
principles
white
paper
and
through
discussions
with
Brendan
and
Annie,
we
felt
like
yeah.
Maybe
we
want
to
go
on
put
more
of
a
focus
from
say
a
developer
perspective
or
an
implemental
perspective
is
how
do
you
kind
of
make
this
thing
real?
I
And
now
we
started
to
go
and
draft
something
up,
based
on
the
experience
that
we've
seen
like
building
applications
for
the
edge
and
then
designing
them
so
that
they
indeed
follow
a
a
generic
pattern
that
makes
them
easy
to
go
and
operate
and
deploy.
So
this
is
like
how
it
came
to
to
place
like
a
really
probably
really
from
a
practical
perspective.
I
Getting
these
things
done
and
also
seeing
that
we
interface
quite
a
bit
with
with
independent
software
vendors,
so
smaller
companies
that
have
say
something
like
30,
40,
50
customers
for
no,
not
customers,
but
but
employees
and
most
of
the
applications
that
they've
done
they
started
in
the
cloud
they
need
to
go
and
put
something
at
the
edge
in
order
to
deal
with
bandwidth
constraints
with
policy
constraints,
security
constraints
and
reliability.
Constraints,
and
all
of
these
guys
are
pretty
much
facing
the
same
problem
as
they're
re-architecting
their
application.
I
So
we
felt
like
maybe
it's
useful,
to
write
these
things
down
so
and
then
starting
on,
publish
them,
and
we
found
like
when
I
talked
to
Brandon.
That
was
the
the
perfect
place
to
go
and
maybe
do
an
amendment
or
an
extension
or
whatever
you
want
to
call
call
it
a
complimentary
document
to
the
white
paper,
which
I
believe
is
a
great
great
Anchor
Point.
So
this
is
so.
I
This
overall
thing
came
to
place
and
I'm
gonna
go
on
I,
pass
it
on
to
RV
in
a
minute
and
I
have
a
little
bit
of
and
I
mentioned.
A
lot
of
things
that
are
on
networking.
I
have
a
little
bit
experience
in
the
open
source
domain.
Some
people
know
my
name:
I've
been
active
in
the
next
Foundation
networking
for
quite
a
while,
along
with
Brendan
on
a
load
of
networking,
related
projects
and
well
apparently,
I.
I
Think
Edge
is
also
inherently
dealing
with
a
lot
of
networking
topics,
which
is
why
and
love,
and
this
this
particular
corner
of
the
universe,
yeah.
Well,
let's
pretty
much
it
and
I
work
for
Cisco
and
I
live
in
Germany
and
in
Cologne
whenever
you
want
to
go
and
swing
by
and
have
this
this
beer
in
these
really
small
and
Tall
Glasses
go
and
give
me
a
shout.
H
At
one
time
in
Cologne,
Frank
happened
to
be
away
on
a
trip,
but
he
guided
me
to
some
pretty
cool
beer,
Halls
so
I.
Second,
that.
I
D
I
will
do
it
very
quickly,
I'm
working
closely
with
Frank
on
the
same
project,
I'm
based
in
Switzerland
and
yeah,
working
on
on
Frank
on
the
project
at
Cisco
and
I.
I
also
worked
with
him
on
the
on
the
document
so
nice
to
meet
you.
H
So
while
Frank
pulls
that
up
I
know
with
a
topic
this,
this
detailed,
we
sometimes
have
a
tendency
to
zero
in,
and
you
know,
we
can
spend
a
lot
of
time
around
one
particular
detail
and
talk
about
it
at
length.
But
what
might
be
best
Frank
is
if
you
could
maybe
spend
the
first
10
15
minutes,
trying
to
go
through
the
dock
as
a
whole
first
and
then
we
can
round
back
for
for
questions,
and
that
way
at
least
the
group
has
an
idea
of.
H
What's
all
there
before
we
dig
into
the
questions,
and
if
we
have
to
continue
this
discussion
into
a
future
call,
we
can
certainly
do
that.
We.
I
Can
absolutely
do
that?
What
we
can
also
go,
do
is
Andy
created,
another
framing
slide
and
Andy
I'm,
not
sure
whether
you
want
to
go
and
bring
it
up
and
add
a
little
bit
of
color.
From
your
end,
sorry,
like.
I
Okay
right
because
I
know
that
that
Andy
created
something
to
go
and
add
additional
context,
but
I
I'm
happy
to
go
and
share
it.
If
you
want
to
go
tag
along
I
hope
that
I
I
got
the
link
right
and
I
just
put
that
into
the
zoom
chat
and
then
Stephen.
Maybe
you
can
go
and
carry
it
over
because
I
don't
think
that
I
have
editing
rights
on
the
meeting
notes.
Talking.
I
See
whether
it
indeed
Works
click
on
it,
if
I
got
it
wrong
or
it
kind
of
screw
it
up
while
cutting
and
pasting
and
then
if
it
works
for
you,
then
hopefully
it
works
for
everybody
and
then
let
me
go
and
try
it
on
share
screen.
I
J
I
just
want
to
add
one
thing:
just
like
somebody
needs
to
go.
J
Yeah
I
just
want
to
add,
like
friends,
said
that
you
know
networking
is
quite
an
interesting
part
of
the
whole
thing
I
just
after
joining
the
the
communities,
the
cncf
kubernetes
community
for
the
past
several
months,
I
find
it
very
interesting
phenomena
is
anytime.
We
talk
about
networking.
J
The
assumption
is
the
is
the
is
the
it's
all
depending
a
fat
network
underneath.
So
it's
it's
not
considered.
So
that's
that's.
Why
I
think
it's
interesting
that
Larry
Peterson's
presentation,
because
the
network
underneath
is
also
being
in
a
way
no
longer
a
problem
of
the
just
the
network
provider,
it
can
be
controlled,
managed
programmed
so
I
guess
this
is
something
yeah
I
love
to
also
probably
be
part
of
the
discussion.
I
That's
another
important
aspect:
we've
not
really
covered
that
to
date,
but
it
would
be
another
important
aspect
to
go
on
swinging,
so
I
think
you're
bringing
in
another
good
aspect
yeah,
which
is
why
I
think
what
we
clearly
have
as
a
draft.
It's
an
early
draft
It's
relatively
rough
and
I'm,
sorry
for
that
roughness.
But
if
we
want
to
go
and
touch
on
that
and
jointly
polish
I'm
I'm
more
for
that,
let
me
go
and
see
now.
I'm
allowed
to
share
screen.
A
By
the
way,
Frank
on
the
edit
access
for
these
docs
there's
a
Google
group
behind
this
group,
and
if
you
join
that
Google
group
using
a
Google
ID
and
are
logged
on
to
that
same
ID
at
the
time
you
edit,
the
doc,
you
should
have
full
edit
permission
to
anything
we
make
and
if
you're
working
on
a
new
draft
I'd
suggest
that
you
grant
added
access
to
that.
I
I
think
you
can
take
the
name
of
the
group
I'm
Rusty
on
having
done
that.
But
you
just
add
the
group
and
give
them
permission.
A
I
I
can
open
it
up
to
the
world.
I
have
no
problems
with
that
even
right,
so
it's
like
there's
no
secrets
in
here
I
think
we're
writing
a
white
paper
in
order
to
reach
the
world
historically,.
A
G
J
I
very
much
I
also
share
the
the
Larry
Larry
has
a
book
actually
Edge,
Computing
and
and
basically
5G
and
and
and
Edge
Computing,
so
yeah
I
think
it
would
be
great
to
maybe
I
think
between
this.
This
Edge
paper
and
and
all
this
yeah
I
think
that
book
can
be
also
as
a
kind
of
reference.
One
thing
I
find
interesting
is
I,
know
webassembly,
it
can
run
monolith.
J
That's
probably
why
the
you
know
in
a
white
paper
mentioned
that
monolith
is
is,
is
a
kind
of
a
doesn't
has
to
be
microservices
basically
in
in
in
in
Edge,
however,
the
the
at
least
for
the
the
I'm
sorry
open
networking
Foundation
the
layer
is
where's,
Larry
is
CPO
and
they
actually
are
using
kubernetes
on
the
edge
for
the
for
the
underlay
Network.
J
K
I
Yeah
that'll
be
interesting
for
sure,
and
if
you
you
have
additional
pointers,
I'd
love
to
to
see
those
as
well
and
follow
up
on
those.
So
very
briefly
on
what
what
do
we
have
in
this
well,
sketch
I
would
almost
say
so
from
a
from
a
high
level
perspective,
we're
we're
trying
to
go
into
Skype.
I
What
Brendan
outlined
that?
How
do
you
go
and
basically
double
click
on
the
the
application
white
paper
or
application
principles,
white
paper
that
this
group
produced
and
translate
them
a
little
bit
more
into
practical
things
that
you
want
to
go
and
consider
as
a
developer
when
building
that
as
a
kind
of
a
Baseline
and
prerequisite?
I
And
that
dovetails
with
what
I
said
prior,
maybe
I,
jumped
to
the
second
diagram
first,
and
what
we've
seen
really
from
a
practical
perspective
is
that
we
are
helping
a
lot
of
the
isvs
on
board
their
application
and
they're
all
starting
from
something
that
is
logically
centralized.
I
So
they've
built
something
in
the
cloud
as
an
application
and
they're
facing
constraints
with
that
particular
application
that
they
build
in
the
cloud,
and
they
need
to
pull
a
portion
of
that
application.
To
the
edge-
and
they
then
do
this
and
need
to
go
and
have
something
like
for
transient
storage
caching,
data
at
the
edge
in
order
to
go
and
deal
with
well
air
gap,
mode
failures
in
the
landing
or
constraints
in
the
landing
like
not
enough
bandwidth
all
the
time.
I
They
need
to
go
and
figure
out
how
to
configure
the
the
individual
element
at
the
edge
in
runtime.
They
need
to
also
go
and
figure
out
that
they
are
building
something
that
indeed,
is
Cookie
Cutter
across
thousands
of
edges.
I
They
need
to
go
and
deal
with
data
ingest.
They
need
to
go
and
also
deal
with
the
fact
that
they
need
to
go
on
sometimes
display
the
data.
In
many
cases
you
have
these
Edge
boxes
obviously
connected
to
something
that
only
not
only
ingests
the
data
but
also
displays
the
data
on
the
screen,
but
yeah
some
of
the
data
will
be
reducted
there
change
transformed
and
then
uploaded.
I
So
you
always
have
this
duopoly
of
a
deployment
where
certain
functions
will
continue
to
reside
on
the
cloud
and
it
could
be
a
public,
a
private,
a
hybrid.
So
there
is
multiple
options
on
how
to
go
and
build
this
out
the
logically
centralized
entity.
I
However,
there
are
certain
functions
that
absolutely
have
to
live
at
the
edge
where
that
the
the
principle
of
operating
The
Edge,
like
an
extension
of
a
cloud,
doesn't
really
work
anymore
and
that's
I
think
what
I
see
as
the
the
real
domain
of
edge
native,
where
the
design
principles
nearly
need
to
go
on
change
and
well.
We
have
to
go
and
adhere
to
these.
I
These
constraints
that
you
otherwise
not
really
see,
because
here
in
the
cloud
and
so
I
think
that's
the
methodology
underneath,
so
that
there
is
a
a
logically
centralized
entity
that
has
multiple
layers
indeed
or
potential
tiers,
like
private
public,
hybrid
multi-cloud,
and
you
have
this
this
entity
that
is
living
or
that
is
spread
out
of
across
multiple
locations
or
multiple
ages.
I
That
needs
to
go
and
deal
with
a
different
design
Paradigm.
So
these
Edge
native
design
paradigms
would
be
then,
like
autonomous
entities,
self-contained
self-contained
operation
in
their
heterogeneous
location.
I
Aware
all
the
good
stuff
that
we
have
in
in
the
white
paper
and
if
we're
designing
these
things,
then
out-
and
there
is
more
content
here
and-
and
the
year
author,
this
mostly
around
like
how
this
logically
centralized
entity
could
go
in
BD,
indeed
be
tiered
or
up
to
the
level
where
things
then
trip
over
and
where
well
different
design
principles
would
go
and
start
and
apply
it
and
what
we
Disturbed
as
a
group.
So
far
from
a
design,
behaviors
and
there's
very
likely
more.
I
We
already
heard
one
and
Victor
I
think
that
was
you
right.
That
said
like
we
might
want
to
go
and
even
take
more
control
of
the
underlying
networking
infrastructure
in
certain
cases,
because
well
that's
context
and
awareness
of
the
environment
and,
to
some
extent
we
have
that
covered,
but
I'm
getting
into
that
in
a
minute.
But
from
a
design
Behavior
perspective,
there
is
some
main
classes
and
one
of
the
big
classes
that
we
have
is
how
do
we
deal
with
concurrency
and
scale?
I
If
we
go
with
the
old,
12
Factor
principles,
then
you
scale
by
the
process
model.
If
we
go
into
Edge
native,
then
we
also
not
only
scale
by
the
process
model
which
is
within
an
edge,
but
we
also
scale
by
the
number
of
edges.
So
we
scale
by
basically
location
and
that's
something
to
go
and
keep
in
mind,
because
when
we
scale
by
location,
we
start
to
go
and
not
treat
only
processes
as
cattle.
I
The
second
thing
is
around
like:
how
do
we
declare
dependencies
and
policies
and
as
again,
an
extensional
we
have
with
what
we
we
have
with
12
Factor,
that
we
declare
dependencies
and
isolate
policies
between
the
edge
and
the
cloud
and
that
we
are
defining
these
these
policies
in
a
way
that
the
edges
can
indeed
decide
autonomously
on
the
Fulfillment
of
these
policies,
so
that
they're
completely
self-contained?
I
Even
if
the
internet
like
disappears
or
the
connection
to
the
cloud
disappears
or
the
the
connection
to
the
central
entity
disappears
linked
to
the
the
principle
that
we
already
discussed
from
a
scale
perspective,
is
this
principle
of
disposability.
So
if
we
go
with
pure
Cloud
native,
we
just
separate
code
and
and
and
data,
but
here
and
then
that
makes
that
allows
us
to
go
and
heat
Trader
process
as
a
disposable
entity.
I
We
can
go
one
step
further
if
we're
now
scaling
not
only
by
the
process
model
but
also
by
The
Edge
location
model.
These
edges
become
disposable
entities
that
need
to
go
on,
adhere
to
the
same
principles
like
you
need
to
go
and
decouple
what
you
keep
as
local
state
and
what
you
have
as
persistent
state
in
the
cloud
so
that
we
can
go
and
make
individual
locations
Edge
locations
disposable.
I
The
next
point
is
and
that
that
probably
dovetails
quite
well
Victor
with
what
you
were
saying
and
it's
again
a
good
point
that
Andy
rice
and
the
discussions
early
on
is
capability
sensitivity,
because
as
soon
as
you're
at
the
edge
you're,
typically
interfacing
with
something
and
that's
what
I
said
in
the
opening
like
you,
either
need
to
ingest
something
or
you
need
to
displace
something
or
need
it
or
do
both.
But
you
also
need
to
be
possibly
aware
and
I
think
that
Victor.
That
was
your
point
about
what
is
underlying
there?
I
What
network
do
you
have?
What
are
the
specific
constraints,
and
these
constraints
could
all
be
around
like
we
even
mentioned
that
here,
Network
bandwidth,
compute
power,
sensors
cameras
displays
whatever,
but
that
knowledge
needs
to
be
typically
ingested
in
order
to
go
and
deal
with
the
application
environment.
I
Another
thing
is
around
storage
and
I
mentioned
that
already
right,
so
if,
as
soon
as
we
want
to
go
and
persist
data,
if
we
want
to
go
and
deal
with
failure
at
the
edge
in
a
way
that
we
are
treating
these
edges
almost
like
yeah
treating
these
edges
as
cattle
as
as
as
things
that
can
be
lost
at
any
point
in
time,
we
can't
really
persist
data
there,
but
we
need
to
go
and
make
sure
that
we
persist
the
data
in
a
space
in
the
centrally
local
or
in
this
logically
centralized
entity.
I
Many
cases
we're
calling
This,
Cloud
I
think
interchangeably
that
the
the
local
data
storage
is
only
of
temporary
nature
instead
of
of
permanent
nature,
and
we
need
to
build
it
in
a
way
that
we
do
this
properly,
and
that
includes
like
yeah.
Well,
if
you're
dealing
things
from
the
temporary
nature
and
you
need
to
be
resync
with
the
cloud,
what
do
you
do
if
you
lose
the
cloud
and
then
you
need
a
resync
once
once
you're
reconnecting,
it
might
cause
even
a
dose
attack
on
your
on
your
Cloud
entity.
I
So
all
of
these
things
need
to
be
taken
into
account.
Another
aspect
once
we're
building
things
out
is
metrics
and
logs
heavily
discussed
in
Academia,
and
then
many
pages
found
that
yeah.
Well.
If
you
export
all
the
logs
from
your
site,
then
you're
not
doing
anything
else,
because
you're
clogging
your
bandwidth,
your
Uplink,
so
the
overall
principle
is
to
go
and
focus
on
metrics
and
not
on
logs,
and
that
is
where
we
really
differ.
I
I
think
from
old
12
Factor,
because
12
Factor
was
still
like
logging,
Centric
I,
think
the
edge
and
Edge
native
is
really
something
that
is
a
matrix
Centric,
so
that
we're
exporting
information
instead
of
instead
of
like.
A
I
Information
raw
data,
so
trans
transform
data
is
always
better
to
be
Upstream,
because
that
has
higher
density
of
information
and
and
the
final
point
is
around
the
the
operational
principles
and
then
many
of
that
is
already.
I
In
the
in
the
principles,
white
paper
right
so
we're
assuming
a
non-expert
operator,
then
we
can
also
not
assume
a
load
of
say
capability
from
an
operations
perspective
at
the
edge.
We
need
to
go
and
deal
with
the
very
simple
Edge
operations
level
that
yeah
you
can
go
on.
Power
Cycle,
the
device
you
might
factory
reset
the
device,
but
that's
about
it.
I
We
can't
really
debug,
there's
no
way
to
go
on
Cube
cuddle
to
to
an
edge
device
to
go
and
fix
it,
but
we
have
to
go
and
look
for
procedures
that
are
automatically
like
self-recovering
and
a
lot
of
these
things
are
obviously
intertwined.
So
as
soon
as
the
device
designed
for
anything
can
fail
at
any
point
in
time,
you
can
also
go
and
come
to
easier
operational
principles,
so
I
think
yeah,
that's
pretty
much
what
we
have
like.
I
So
we
try
to
go
and
touch
on
a
couple
of
points
that
are
basically
takeaways
from
what
we've
seen
as
we
started
to
go
and
redesign
some
of
the
the
apps
that
were
very
Cloud
focused
initially
and
then,
where
certain
portions
of
these
apps
needed
to
be
taken
to
the
edge,
because
well
before
bandwidth
policy,
security
or
whatever
reasons
so
that
certain
things
had
to
go
and
live
at
the
edge
that
are
complementary
to
the
to
the
cloud.
And
then
one
thing
before
I
I
take
a
breath
here.
I
Joel
came
up
with
a
pretty
good
idea,
and-
and
it's
not
really
in
here,
but
what
Joel
said
and
then
I'm
working
on
something
along
those
lines.
This
is
what,
if
we
had
an
example
like
we
all
know
the
stock
shop
right
for
cloud
native.
Can
we
have
a
very
simple
thing
for
for
Edge
way
simpler
than
the
sock
shop?
I
Obviously,
but
a
very
simple
application
that
would
go
and
pretty
much
depict
or
put
in
the
application
example
complementary
to
to
these
rules
here
or
guidances
that
that
would
help
reflect
how
we
would
go
and
apply
these
things.
In
a
practical
example,
and
then
that's
something
that
I
started
looking
into
together
with
Joel
we're
not
yet
there
but
well,
we
hope
to
be
there
in
a
couple
of
weeks
and
yeah.
Well,
that's
that's
what
we
have
and
if.
I
I
Right
so
the
example
that
I
have
in
mind
Stephen
is
a
relatively
simple
one,
and
we've
seen
that
a
couple
of
times
already
and
a
lot
of
the
the
applications
that
have
to
do
with
something
video
at
the
edge
need.
A
very
simple
yeah.
I
would
call
that
a
bit
of
an
edge
video
recorder
where
you
ingest
video,
you
you,
you
sample
the
video
you
down
sample,
you
compress
you,
you
change
the
frame
rate,
you
change
the
resolution,
and
so
that
means
your
ingest
and
rtsp
stream.
I
You
might
write
it
to
local
disk
for
buffering
reasons,
and
then
you
change
it
a
little
bit
and
then
you
upload
it
to
Some
Cloud
device.
So
it's
maybe
a
tool.
Basically
a
I
think
what
I
have
right
now
is
a
two
container
application
that
could
go
and
serve
as
something
like
an
example
here
and.
I
A
as
a
simple
example,
because
I've
seen
this
as
a
as
a
pattern
for
for
many
many
applications
that
do
something
video
they
only
kind
of
reliable
video
ingest
with
like
different
frame
rates
and
and
different
resolution,
and
they
don't
want
to
go
and
do
that
in
the
cloud
for
bandwidth
and
reliability
reasons.
So
that's
that's
I.
Think
the
example
that
I
have
in
mind
that
I
want
to
go
on
20
up
there,
but
maybe
see
me
have
a
better
one.
Yeah.
A
That
just
like
soil,
moisture
sensors,
for
example,
that
are
just
scalar
numbers,
there's
so
many
different
definitions
of
edge
that
maybe
you'd
go
as
far
as
three
examples:
I
wouldn't
go
for
more,
but
the
simplest
one
that
I've
seen-
and
this
is
really
simple
and
I-
would
start
with
the
simple
one
and
build
up.
You
know
to
show
the
the
available
toolkit
but
kind
of
one
of
the
demos
I
saw
of
a
far
remote
Edge
was
an
agriculture
application
of
a
fish
farm.
A
Where
this
thing
is
in
such
a
rural
area
that
there
is
literally
no
internet
ever
you
know
there.
No
Wi-fi,
no
5G,
4G,
3G
of
any
kind
and
the
way
it
worked
is
they've
got
ponds
out
in
a
jungle
that
are
a
50-mile
motorcycle
right
away
and
there's
a
fish
feeder
that
broadcasts
feed
onto
this
Pond,
and
they
take
some
measurements
that
are
going
to
attempt
to
measure
water
quality
and
how
big
the
fish
are
for
harvesting.
A
Somebody
goes
there
once
a
week
on
a
motorcycle
through
a
dirt
path
and
when
they
get
there,
there
is
a
permanent
control
system
charged
operating
on
battery
and
solar,
and
it
bonds
to
the
motorcycle
rider's
cell
phone
and
they
exchange
updated
configuration
info
and
data
collection,
as
it
kind
of
a
once
a
week
batch
event.
And
then,
when
the
motorcycle
rider
rides
within
range
of
a
cell
tower,
then
it
goes
up
to
the
cloud,
but
that
was
kind
of
the.
A
It
was
a
cool
application
and
within
Edge
agriculture
is
actually
one
of
the
bigger
use
cases
and
if
you
can,
if
you
can
get
your
tool
kit
low
enough
to
support
that
thing,
I
think
that
the
same
techniques
will
work
when
you've
got
more
resource,
but
that
would
have
one
that
was
pretty
easy
to
understand.
What's
going
on
kind
of
the
ultimate
of
unreliable
communication,
you
know
like
once
a
week
and
it
never
actually
has
a
direct
connection
to
the
internet.
It
goes
from
these
devices
to
a
phone.
A
There
but
I
would
say
start
start
with
a
super
low
example
as
low
as
you
can
possibly
imagine
and
still
be
useful
and
then
maybe
go
up
to
a
mid-range
one,
and
if
your
story
can
cover
both
that's
good,
because
I
think
it's
sort
of
like
they
say.
Disruptive
Technologies
often
start
at
the
low
end
and
if
it
works
there
on
minimal
resources
generally
can
still
be
useful
when
you've
got
more.
But
you
go
the
opposite
direction
and
it
it
doesn't
work
out.
B
Yeah
Steve:
there
is
some
influence
in
this
paper
actually
from
that
that
area
of
AG
I
I
spent
time
just
prior
to
helping
Frank
and
the
team
out
with
this
paper,
with
Cornell
University
on
their
software-defined
farm
and
they're,
using
actually
UHF
channels
that
have
been
decommissioned
to
transmit
low
amounts
of
data
back
to
Hubs
right
so
they're
doing
this
for
cattle
they're
doing
this
wineries,
apple
orchards,
Etc
and
it's
part
of
a
bigger
Grant
given
by
actually
NASA
for
the
use
of
better.
B
You
know
improving
Equity
and
distribution
of
water
and
water
quality
for
the
purposes
of
farming
and
agriculture
around
the
world.
So
there
is
some
slight
influence
but
you're
right
in
saying
that
this
store
and
forward
is
not
as
maybe
as
elaborated
upon
as
it
could
be,
because
there
are
other
instances
not
only
of
that,
but
you
know
think
about
the
way
that
air
tags
work
with
your
iPhone
right.
That's
part
of
a
a
sideband
network.
B
That's
existing
on
all
these
on
all
these
devices
we
carry,
but
it
carries
common
information,
so
yeah
you're
right
there
could
be
more
there.
A.
A
I
Some
of
these
things
as
kind
of
real
world
examples.
What
I
also
had
in
mind
is
just
complementing
something
with
like
a
reference
to
code,
so
I
was
built
right,
so
that
here
is
a
home
chart.
Here's
a
couple
of
easy
containers,
and
this
is
how
they
deal
with
certain
situations.
I
But
tomorrow
you
had
your
hand
up
for
a
while,
so
I
don't
want
to
go.
Oh.
E
Yeah,
thank
you
so
Brandon
Frank.
Thank
you
very
much
for
the
talk.
I
think
that's!
This
is
really
interesting.
I!
Definitely,
you
know
check
this
out,
but
if
I
got
any
questions
or
something,
what
should
I
do
just
leave
the
comments
on
this
doc
or
something
else
you
want
me
to
do.
I
A
Think
the
last
time
we
started
out
with
a
Google
doc
with
both
comments
or
direct
ad
edits.
If
you
know
you
don't
necessarily
have
to,
if
you
have
valuable
content
to
add
I'd
say
just
go
put
it
in
there
rather
than
have
somebody
approve
it,
but
if
you
want
to,
you
know,
propose
an
alteration
to
something
that
you
already
found
there.
Maybe
the
comment
works
best,
but
it
was
pretty
open.
Brandon,
you
I,
think
were
more
vigorously
active
in
that
effort
than
I
was
so
maybe
you
can
add
a
little
color
here
too
yeah.
H
Yeah
I
would,
you
know,
just
treat
this
as
an
open,
Community
doc.
This
is
the
first
time
it's
been
presented
to
the
community,
so
this
is
kind
of
the
starting
point.
But
following
up
to
this
call,
we
will
put
a
link
to
it
in
the
meeting
notes
the
running
note
stock.
We
should
also
put
out
a
call
for
review
inside
of
the
the
the
Google
group
and
over
slack
that's
what
Kate
asked
me
to
do
last
time
and
that
you
know
informs
folks.
H
You
know
who
aren't
able
to
make
these
calls
that
there's
something
for
them
to
to
do
if
they're
so
interested
so
inclined
the
edits
come
in
the
comments
come
in
and
then
in
future
calls
we
go
through
those
and
we
can
consolidate,
we
can
accept,
we
can
reject,
and
then
we
get
to
a
point
where
we
feel
like
it's
everything's
there.
H
That
needs
to
be
there
in
terms
of
rough
content
and
then
what's
happens
at
the
end,
is
that
we
go
through
with
the
just
a
finer
tune
on
editing
and
presentation
and
flow,
and
then
we
get
it
ready
for
finalization,
but
we're
we're
still
a
couple
months
away
from
that.
I'd
say,
and
this
is
our
first
step
on
making
it
available
to
all.
J
What
I
find
is
joining
this
call.
Is
it's
a
really
broad
topic
at
first
I
was
thought
it
was
about
webassembly
and
be
honest,
and
then,
of
course,
this
is
about
so
many
things.
Maybe
it'll
be
better
to
really
classify
the
topics
into
area,
so
maybe
that
doesn't
even
have
to
be
in
this
meeting
can
be
like
offline
can.
For
that
week,
people
can
comment
on
the
slack
Channel
this
way.
For
that
week,
at
least
people
just
focus
on
what
area
this
way
can
get
more
specific,
productive
progress
made
on
the
topic.
I
A
A
Days
of
the
prior
white
paper,
we
we
let
the
documents
settle
just
by
group
text
edits,
but
at
some
point
we
get
to
the
point
where
it's
worth
just
putting
in
a
you,
can
put
an
agenda
item
in
the
meeting
series
for
this
group
and
just
take
over
a
meaning
for
kind
of
a
walk
through
where
some
host
would
scroll
through
the
document
that
if
we
have
unresolved
comments,
just
close
those
out
and
allow
for
group
comments,
we
don't
want
to
do
that.
A
Every
meeting,
because
not
all
of
our
audiences
interested
in
that
white
paper
I
think
there
are
probably
most
people
are
more
like
lurkers
who
want
to
see
the
final
result
rather
than
you
know.
It's
often
people
employed
by
vendors
who
have
an
interest
in
calling
it
part
of
their
job
to
go
work
on
this
and
the
others
just
would
wait
for
the
dust
to
settle
and
go
look
at
the
result.
But
yeah
you're
welcome
to
to
put
yourself
on
the
agenda
just
not
week
after
week,
but
you
know
intermittently
just
go
for
that.
H
Yeah,
it
tends
to
work
itself
out.
You
know
the
people
that
are
interested
and
want
to
contribute
to
and
that
activity
is
recorded
on
these
calls
and
in
the
doc
itself
and
once
all
that's
been
reviewed
and
processed,
we're
funneling
it
down
into
a
finished
product
for
now,
as
they
say,
but
yeah
we,
we
can
entertain
new
ideas
here
at
this
stage,
but
soon
we
want
to
start
limiting
what
gets
added
to
this.
So
it
has
a
definitive
start
and
stopping
point
and
then
once
this
is
finalized.
H
Of
course
the
group
is
more
than
welcome
to
think
about
what
other
areas
we
might
want
to
take.
A
I
don't
know
if
this
this
agenda
item
is
over.
We've
got
five
minutes
left.
We
can
keep
going
on
this
if
people
have
more
or
usually
when
we
run
out
of
material
or
even
start
with
no
material.
This
group
operates
just
total
free
form.
Birds
of
a
feather
people
can
throw
out
anything
interesting,
they've
come
across
and
we'll
discuss,
share
ideas
and
thoughts.
H
I
A
a
short
at
that
one
of
the
following
meetings
and
we
can
go,
and
at
least
say
well.
This
is
what
what
came
in
this
is
the
feedback
that
we
received
and
how
we
want
to
go
and
take
that
forward.
I
K
K
Yeah
Frank,
as
you
mentioned,
but
for
the
group
I,
have
a
building
what
Frank
had
mentioned
with
this.
K
Had
time
to
add
to
the
document,
but
I'll
be
doing
that,
you
know
in
the
coming
days
to
continue
to
move
that
forward.
I
just
wanted
to
state
that
for
the
group
here.
H
I
see
Kate's
joined
us
now
as
well:
hey
hey
Kate,.
H
H
No
worries
not
sure
how
much
of
that
you
heard,
but
we
were
able
to
to
get
through
the
the
idea
here.
As
a
first
step
with
this
group.
I
And
it's
a
bit
drinking
from
the
firehouse
right
I
understand
that
because
it's
all
like
a
written
text,
all
new,
so
maybe
you
just
kind
of
I-
did
settle
in
a
little
bit
and
then
we
can
go
and
take
another
round
of
discussion.
Maybe
in
the
next
meeting
or
so
and.
D
I
A
I
just
put
an
item
in
the
chat,
the
eclipse
Foundation,
conducts
what
I
found
to
be
a
very
useful
survey
of
Edge
Computing.
You
know
they
host
a
number
of
Edge
native
open
source
projects
and
they
have
typically
gotten
hundreds
well
into
the
hundreds
of
participants
on
this
and
often
have
interesting
results
on
technology
Trends
and
what
users
are
actually
interested
in
so
they're
doing
it
again.
A
I
put
this
link
here.
This
is
sort
of
a
kit
that
is
more
geared
towards
not
the
link
to
the
surveys
in
there,
but
this
is
geared
towards
people
who
have
organizations
and
want
to
circulate
it.
So
I'll
put
the
direct
link
to
the
poll
in
our
slack
channel
in
a
day
or
two
after
I
look
over
this,
but
just
got
it
this
morning,
but
I
think
that
this
kind
of
survey
is
valuable
to
the
community
so
and
I
encourage
people
to
go.
A
Take
a
look
at
this,
and
maybe
if,
if
you've
got
a
user
base
for
some
project,
you
run
or
you
know,
are
engaged
in
in
Edge.
Related
groups.
Go
take
a
look
at
that.
J
Is
there
any
other
organization,
like
reports
so
kind
of
a
similar
discussion
on
edge
computing.
A
You
know
most
of
the
analyst
groups
have
some
kind
of
edge
thing
anything
from
Gartner
to
Arc,
to
whatever
often
you
have
to
pay
for
those
you
know
they're
sort
of
commissioned
by
big
corporate
vendors,
and
this
one
is
by
an
open
source
group.
Historically
I
think
this
group
tried
to
do
a
survey
once,
but
I
don't
think
we
got
I
think
we
got.
A
Maybe
a
hundred
participants
in
the
eclipse
Foundation
seems
to
have
been
out
there
a
little
bit
longer
with
projects
and
gets
a
bit
more
traction
on
their
survey,
just
to
get
an
idea
of
it.
You
can
just
Google
search
for
last
year's
results
and
you
can
see
the
kind
of
things
that
are
in
there
and
I've
always
found
it
useful.
A
You
know,
even
if
you
give
a
talk
on
edge,
you
often
want
to
open
it
with
you
know,
kind
of
the
pitch
deck
kind
of
thing
of
you
know
what
the
potential
is
and
why
people
are
interested
in
this
topic
kind
of
thing,
and
rather
than
make
up
your
own
speculation,
it's
always
good
to
quote
an
actual
survey.
You
know
where
you
can
say.
According
this
recent
survey
of
800
users,
this
is
what's
going
on,
and
these
are
some
of
the
issues
people
are
facing.
A
That
kind
of
thing,
so,
just
having
out
things
out,
there
help
us
make
decisions
and
give
us
an
idea
of
what
to
focus
on
and
get.
J
J
The
biggest
question
even
I
think
even
for
the
largest
company
there's
a
question
of.
Should
we
do
Edge?
Does
the
white
paper
that's
already
published
and
said,
I
I
read
it
briefly,
I've
gone
very
good
content,
but
does
does
the
paper
itself
answer
the
question?
Why
should
we
company
do
Edge
computing.
L
No
I
don't
think
it
does
I.
Think
it's
more
of
the
audience,
though,
of
if
we're
talking
about
the
first
one.
Actually
I
came
in
late,
so
maybe
you're
asking
about
the
second
one,
but
the
first
one
was
focused
on
you
already
are
bought
into
the
fact
that
you
want
to
run
your
applications
on
the
edge.
Here
is
how
that's
an
interesting
point,
mother,
whether
we'd
want
a
paper
like
that
to
come
out
of
the
working
group.
A
A
A
Okay,
well
thanks
for
attending,
and
this
was
at
an
unusual
time
period.
So
I
think
we've
got
another
meeting
scheduled
in
just
one
week.
So
we'll
see
you
then
thanks
for
attending.