►
From YouTube: CNCF TOC Meeting - 2018-04-17
Description
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
B
D
D
C
C
G
G
G
C
G
Thanks
very
much
Chris
good
morning
or
good
afternoon,
everybody
welcome
back
to
the
meeting.
I'm
sorry
I've
been
away
for
such
a
long
time.
Let's
just
jump
straight
into
the
agenda
and
we're
going
to
go
through
presentations
today
and
we're
going
to
discuss
the
Prometheus
graduation,
a
bit
of
working
group
staff
and,
of
course,
the
announcements.
The
TOC
results.
G
C
This
is
basically
I'm,
just
letting
people
know
we're
canceling
our
meeting
on
May,
first
just
a
lot
of
sort
of
the
conference
and
instead
we're
gonna
do
kind
of
booth
hours.
So
folks,
like
Alexis
and
I,
will
have
office
hours
at
the
CN
CF
booth
for
people
that
wanna
talk
to
TSP
members,
I,
don't
know
who
else
in
the
TSE
is
going
a
cube
concert.
It
would
be
nice
to
know
so.
I
could
add
you
to
the
office
hours
or
lists.
G
It
would
be
good
for
anyone
who's
a
TOC
contributor
to
to
meet
other
members
of
the
TOC,
so
I
think
you
know
we
should
continue
to
strive
to
bring
people
together.
I,
don't
know
what
you
and
Dan
feel
about
doing
something,
maybe
attaching
something
to
the
GB
get
together
up.
So
you
could
buy
everybody
a
glass
of
something
fizzy,
okay,
yeah
sounds.
G
Alright,
so
let's
go
on
to
the
election
results
now
Chris
correct
me
if
I'm
wrong,
but
this
is
these-
results
are
voted
on
by
the
other
members
of
the
TOC
yep
Vaughn
vetted
candidates
who
stepped
forward
and
are
the
two
seeds
that
are
elected
by
the
TOC
from
those
valid
candidates
correct
and
they
stand
for
one
year.
They
run
for
one
year
in
two
years:
correct
yep,.
C
And
I
got
to
do
a
quick
well
first,
we
can
make
the
announcement
that
Brian
grant
was
reelected
in
Quinten
bull.
It
was
elected
as
for
the
second
seats,
so
Solomon
is
no
longer
a
TOC
member
and
we
want
to
wish
him
the
best
and
thank
him
for
his
service.
Since
this
whole
thing
was
getting
started
so
there's
ten
total
candidates
I
ran.
So
thank
you
to
everyone.
There
I
got
to
do
a
quick,
crazy
kind
of
coin
toss
to
decide
who
gets
the
two-year
term
versus
one-year
term
seat
so
I'm
just
gonna
go
share.
C
G
Thank
you
thanks
Chris,
and
congratulations
to
Brian
and
Quintin.
I
want
to
say
a
few
things
here.
I
really
really
want
to
thank
Solomon
who
I
know
he's
into
every
single
meeting,
or
even
you
know
it's
kind
of
the
meetings,
but
I
do
believe
that
docker
lending
their
support
wholeheartedly
to
this
process
at
a
crucial
stage
and
very
important
for
the
evolution
of
the
CN
CF,
and
please
note
that
most
of
that
originated
from
Solomon.
G
He
was
the
person
who
bought
into
the
vision
of
having
this
community
and
docker
being
part
of
it
and
I
think
that's
very
important
to
recognize.
Thank
you
very
much.
Solomon.
Also,
congratulations
to
all
the
candidates.
We
have
a
really
stir
and
filled
with
some
very
close
voting.
Please
please
do
what
we
discussed
and
if
you
didn't
yeah,
you
know
what
you
want
it
banned
again.
Please
get
helping,
would
really
help
to
make
this,
whether
you
vote
or
not,.
G
But
one
thing
I
will
say
is
that
prometheus
is
ill
in
need
of
a
lot
of
help.
This
is
a
project
which
doesn't
get
all
the
limelight
like
kubernetes
does.
If
you
know
people
who
say
how
can
I
contribute
in
scale,
if
I'm
a
developer,
there's
plenty
of
work
to
do
in
prometheus,
you
don't
have
to
send
everybody
to
cuba
Nettie's.
There
are
other
projects
as
well,
so
I
voted
plus
one
for
this.
C
C
So
I
could
speak
quickly
on
this
one
Alexis.
So
we've
been
approached
by
a
couple
of
folks:
I
want
to
propose
new
working
groups
and
we
don't
really
have
a
formalized
process
where
someone
could
just
issue
a
PR
like
they
do
with
project
proposals.
So
this
is
just
basically
still
of
solidifying
kind
of
what
we
expect
folks
to
do
so.
G
So
my
big
concern
with
the
working
group
process
is
that,
while
well-meant
we
haven't,
you
know
we
don't
have
a
system
for
working
groups,
and
you
know
we've
reached
the
point
now
where
we've
explored
the
space
a
bit.
We've
kicked
the
tires.
We've
experimented,
we've
seen
a
few
successes,
a
few
non
successes,
and
now
we
need
to
get
serious
about
it.
G
So
if
anyone
would
like
to
help
me
and
Chris
to
figure
that
out
with
a
written
document,
I
would
really
appreciate
it.
So
please
send
Chris
an
email
volunteering
to
help.
This
is
a
toc
contributor
opportunity
or
if
you
have
a
vote
or
if
you've
recently
been
elected
or
re-elected,
this
could
be
a
great
chance
to
prove
that
everyone
made
the
right
decision,
but
please
do
help.
This
is
an
important
area.
Without
some
clarity,
working
groups
will
stutter.
They
can't
continue
forever,
based
on
energy
alone.
G
B
D
This
is
Dan
shall
we're
presenting
a
safe
working
group
proposal
later
in
this
meeting.
I.
Don't
think
that
you
know
I'm
necessarily
in
a
position
to
help
in
this
definition,
but
I
want
to
sort
of
raise
our
hand
as
we're
going
through
the
process
to
be
guinea,
pig
and
fodder.
For
you
know,
testing
this
process
and
working
through
that
so
you'll,
please
feel
free
to
lean
on
us.
You
know
in
that
process
and
you
know
we'll
we'll
help
document
along
the
way.
If
we
have
a
partner
in
the
TOC.
E
G
I
should
just
say
a
word
about
I
know
we
had
this
show
of
hands
vote
on
sandbox
versus
some
other
names.
There
was
an
even
split
between
sandbox
a
workshop
and
people
seem
to
be
settling
down
around
sandbox.
So
I
think.
That
kind
of
concludes
that
discussion.
There
wasn't
a
clear,
clear
vote
for
an
alternative,
I'm
afraid.
So,
unless
anybody
wants
to
throw
themselves
in
front
of
the
truck
right
now,
sandbox,
it's
gonna
be
so
we
have
the
two
proposals
for
the
new
gingy
newly
named
junior
ter
coming
in
I
am
the
sponsor
of
telepresence.
G
I
have
interviewed
several
customers
of
the
project,
end-users
and
I'm
quite
impressed.
It
does
fit
sandbox
well
in
the
sense
that
it's
not
completely
obvious
that
it
shouldn't
be
part
of
a
larger
project
or
going
really
what
direction
to
go
into,
but
I
feel
that
it
shows
the
right
kind
of
green
shoots
of
a
young
project
to
deserve
backing
a
sandbox
level.
I,
don't
know
who
is
gonna,
put,
stick
up
their
hand
for
open
messaging
Chris.
J
Right
so
so
sir
slide
12,
so
the
problem
that
we're
trying
to
solve
with
telepresence
is
just
improving
the
experience
of
the
active
on
kubernetes
and
today,
if
you're
setting
up
a
development
environment
for
kubernetes,
you
essentially
have
two
major
choices:
one
is
local
development
using
something
like
mini
cube
or
dr.
compose
or
now
docker
for
Mac
the
pros
are
you
don't
need
a
network
you're
isolated
from
other
developers,
so
any
changes
you
make.
You
have
your
own
little
sandbox
not
to
overload
the
term.
J
The
challenge
of
this
is
that
you
can't
run
resource-hungry
services
right
so
as
soon
as
your
application
goes
beyond
a
few
services
or
maybe
one
service,
if
you're
using
Java,
your
laptop
starts
to
get
really
hot
and
it
starts
to
melt
down,
and
so
the
alternative,
then,
is
cloud
development
where
you
run
kubernetes
and
cloud,
and
then
you
have
some
sort
of
deployment
system
like
scaffold
or
draft
or
CI
or
something
any
of
these
things.
The
pro
is
that
you
can
guarantee
that
your
production
environment
and
your
development
environment
are
exactly
the
same.
J
You
can
run
the
exact
same
version
of
kubernetes
in
the
exact
same
place.
The
challenge
is
that
it
requires
a
network.
You
can't
use
your
local
development
tools,
there's
a
higher
latency,
so
you
have
to
push
your
registry
and
do
all
these
things
and
developer
sort
of
an
impatient,
Bunch
and
so
on,
slide
13.
So
this
is
why
we
create
a
telepresence.
J
The
way
this
works
is
we
deploy
a
two-way
proxy
on
the
caribbean
indies
cluster
and
we
also
run
a
client
locally
on
your
laptop
to
connect
to
the
proxy
and
we
expose
things
like
config
map
secrets
access
to
other
services.
We
also
let
you
proxy
to
other
cloud
resources
like,
for
example,
amazon,
RDS
or
any
other
sort
of
cloud
database.
We
actually
telepresence
has
really
grown
organically,
so
we
actually
have
currently
three
different
methods
of
proxy,
which
we
are
trying
to
figure
out
when
we
recommend
one
versus
the
other.
J
We
have
a
VPN
type
approach
which
uses
s
shuttle,
which
is
a
VPN
of
r
SS
H.
We
started
with
this
method
called
inject
TCP,
which
injects
a
shared
library
by
hacking,
LD
preload
on
Linux
or
din,
live
on
Mac
into
sub
process.
The
benefit
inject
TCP
is
it
works
with
your
existing
VPN
and
then
we
also
use.
We
also
support
using
docker
run
directly,
which
lets
us
hijack
and
take
advantage
of
Dockers
networking
capabilities
instead
of
maintaining
a
VPN
of
our
own.
So
so
that's
generally
how
it
works
on
slide
15.
J
So
we
have
about
700
stars
and
growing.
Pretty
steadily
on
on
on
github,
we
have
a
bunch
of
users,
a
bit
nam
e's
actually-
and
I
see
ours
on
the
call
she's,
giving
a
talk
at
uconn
about
how
they
use
telepresence
with
cube
apps,
namely
company
on
new
york
city,
has
actually
integrated
telepresence
with
sto.
We've
got
a
couple
case,
studies
from
some
other
companies
that
use
sight
machine
uses
telepresence
because
they
run
a
lot
of
ml
and
the
mlpro.
J
Don't
work
well
running
locally
on
your
laptop,
but
they
also
want
to
use
PyCharm
the
IDE,
and
then
we
also
have
a
variety
of
non-public
enterprise
users
who
I'm
happy
to
talk
about
off
list
and,
like
I,
said,
the
common
use.
Cases
that
we
see
are
people
are
they
want
to
use
IDs
or
their
laptop,
isn't
powerful
enough
to
run
everything
in
mini
cubes.
So
a
lot
of
people
start
with
mini
cube,
and
then
they
run
out
of
memory
and
they
start
looking
for
something
else.
J
So,
lastly,
on
telepresence,
so
our
interest
in
CN
CF
is
we're
really
focused
on
the
app
developer,
trying
to
reduce
that
friction
and
building
multi
service
applications
on
kubernetes
and
sort
of
there's
been
a
bunch
of
threads.
We've
been
talking
about
with
the
scaffold
team,
but
we
really
would
like
to
try
to
grow
the
kubernetes
app
dev
community
in
general.
We
think
that's
sort
of
one
of
the
big
next
frontiers
in
conversation
around.
J
How
do
we
improve
and
there's
lots
of
stuff
going
on
with
the
application
CRD
and
the
app
dev
working
group
and
developer
tools
and
workflow?
We
just
think
from
our
own
experience
that
the
maturity
of
the
developer
experience
on
kubernetes
is
definitely
a
work
in
progress.
We
also
would
like
to
expand
the
telepresence
community,
so
the
core
maintainer
zall
work
at
data
wire.
Today
we
would
like
to
expand
to
other
maintainer
x'.
J
We
have
some
maintainer
x'
who
work
on
very
relatively
small
parts
of
system
like
we
have
someone
who
helps
with
OpenShift
support,
and
we
have
some
of
the
packages
telepresence
for
specific
Linux
distributions,
but
we'd
love
to
get
some
more
core,
maintainer
x'
and
also
more
users
who
can
help
each
other,
because
there
is
a
lot
of
sort
of
best
practices
and
configuration
and
we
don't
use
every
single
ide
under
the
Sun,
so
so
yeah.
So
that's!
That's
the
basics.
Happy
to
take
any
questions.
K
Yeah
ant
a
quick
question:
it
seems
that
so
you
do
need
a
network
connection
from
your
laptop
to
the
cloud.
In
order
to
use
this,
and
given
that
I
guess,
one
alternative
approach
would
be
to
run
the
ID
ease
on
the
cloud
used
like
a
virtual,
desktop
remote,
desktop
kind
of
tool
to
get
to
the
ID.
Did
you
consider
that
approach
as
an
alternative
I
would
see?
It
seems
a
lot
simpler,
but
I
can
see
some
downsides?
Did
you
think
about
that?
At
all?
Wait.
J
J
So
so
the
honest
answer
is
we
didn't
really
consider
running
your
IDE
in
the
cloud
since
then
we
sort
of
thought
about
it
and
it
seems
to
be
a
little
complicated
and
be,
and
also
with
some
of
the
things
I
should
have
actually
talked
a
little
bit
about
some
of
the
things
that
we
are
actually
working
on,
because
probably
the
biggest
piece
of
feedback
people
want
is
faster,
startup
and
better,
can
better
reliably
reliability
over
poor
network
connections,
so
we're
actually
working
on
things
like
Auto
reconnect
and
speeding
up
the
startup
process,
because
right
now,
starting
up
a
telepresence
process
takes
20
to
30
seconds
and
it
really
doesn't
need
to
so
we're
trying
to
get
it
down
to
two
or
three
seconds
and
I.
L
So
if
you
don't
mind
quitting
I
can
probably
add
on
to
that.
For
those
of
you
don't
know
me,
Matt
Farina
I
do
sig
apps
over
in
kubernetes
I
work
on
a
lot
of
the
app
tooling.
So
when
it
comes
to
IDs,
though
you
know,
Visual
Studio
code
is
the
most
popular
from
the
latest
surveys.
There's
vin,
verse,
Emacs
debates.
L
This
for
developers
is
a
really
personal
thing
and
I
think
the
popular
dev
tools
like
this
are
all
still
desktop,
based
the
cloud-based
ones
haven't
taken
off
as
much
as
the
traditional
desktop
ones
that
we
have
all
used
and
so
I
liked
that
telepresence
hooks
up
this
way,
because
it's
not
forcing
you
to
use
a
different
IDE.
It
kind
of
meets
you
where
you're
already
at.
J
A
J
J
Anyone
there's
a
question
about
volume:
ounces
of
containers
running
locally,
so
so
one
of
the
things
we
actually
support
is,
if
you're,
using
the
container
method.
If
we
actually
let
you
maybe
we
just
passed
through
incantations
docker
run,
and
so,
if
you
want
to
do
a
local
volume
out
into
your
container,
that's
one
way
you
can
actually
support
hot
reload
with
your
IDE,
so
you
can
save
to
your
local
filesystem
that
volume
is
mounted
into
the
container
and
that
actually
gets
proxy
to
proxy
into
your
kubernetes
cluster.
F
M
All
right:
well,
thanks
everyone
Oh.
What
what
do
you
kind
of
expect
the
project
to
end
up?
Looking
like
you
know
down
the
road
Wayne's
been
in
the
sandbox
for
a
while,
come
here
that
much
you
expect
it
to
end
up
being
a
standalone
tool
or
some
sort
of
library
that
gets
integrated
into
IDE.
So
what
kind
of
thing
would
you
expect
going
forward?
I
think.
J
This
to
be,
this
is
a
grand
experiment
rate,
and
this
is
one
reason
why
I
like
the
sandbox
concept,
because
we're
not
sure
if
it
make
it
will
ultimately
live
as
a
standalone.
J
We
think
it's
useful
functionality,
that's
important
that
people
will
use,
but
we
can
see
it
being
integrated
into
a
larger
projects
or
it
could
be
maintained
as
a
standalone
thing
and
more
functionality
will
be
added
over
time
and
that's
one
reason
why
we
would
be
very
happy
to
just
get
more
users
to
see
sort
of
what
the
trends
are,
because
right
now,
I
can
tell
you.
The
trends.
J
A
J
That's
the
only
supported
local
cluster,
but
that
would
be
and
there's
some
people
who
use
that
configuration,
but
that's
more
of
an
anomaly,
usually
your
Cooper
days
cluster
would
be
running
in
the
cloud
and
then
you
would
run
the
service
that
your
coding
has
a
local
process
on
your
laptop.
Not
if
that,
if
that
makes
sense
right,
so
you
can
run
it
locally
on
your
laptop
or
run
it
locally
on
your
laptop
inside
a
container.
G
D
Hi
everyone
I'm
Dan,
Shaw
I'm,
joined
today
by
JJ
and
Sarah
Allen.
We
are
the
co-conspirators
that
have
been
pulling
together.
This
working
group
proposal
that
centers
around
secure
access
to
to
build.
You
know
now
that
we
have
our
our
infrastructure
sort
of
elevated
into
the
cloud.
We
all
have
a
shared
visibility
from
operators
to
administrators,
to
developers
to
DevOps
to
that
cloud
infrastructure,
and
our
group
has
identified
that
you
know
it's
it's
there.
N
Bankston
thanks
Chris
and
Alex
for
Alex's
for
having
us
over
here
so
like
what
Dan
mentioned,
I'll
go
out
a
little
bit
of
what
safe
is
about
little
history,
and
why?
Yes,
part
of
it,
we
believe
secure
access
is
an
inter
in
concern
in
a
heterogeneous
system,
so
security
solved
within
a
system
doesn't
actually
lend
itself
to
providing
a
full
on
into
in
security.
We've
seen
this
several
times
and
several
systems,
and
we
all
believe
that
there
needs
this
needs
to
be
addressed
as
a
common
concern.
N
So
the
idea
is
to
understand
the
common
common
problems,
our
own
security
with
all
these
infrastructures
and
then
centralized
infrastructure
which,
to
some
extent,
is
already
happening
with
spiffy
and
hope
in
few
other
projects.
But
then
that
needs
to
get
centralized
in.
That's
the
that's
a
vision
and
the
idea
with
which
we
are
driving.
This
effort
towards
a
little
bit
of
history
is
disappeared
as
a
common
problem
way
back
when
Chris
Lee
when
I
was
brainstorming
with
Chrissy
last
summer.
N
So
obviously
we
weren't
ready
for
it
at
that
time,
and
many
of
us
organically
came
together
over
it
over
time
to
address
this.
As
a
as
a
problem
and
a
quick
quick
note
on
why
us
I'll
be
happy
to
address
any
of
the
pointed
questions
after
that,
but
I
just
wanted
to
give
you
like
a
brief
overview
of
what
what
what
we're
trying
to
accomplish
here.
Why?
Yes,
like
many
of
us,
will
come
to
come
here.
N
It
has
previously
built
security
infrastructure
at
scale
in
some
of
these
companies
like
people
from
people
from
Netflix,
Cloud,
Foundry,
Google
and
I-
think
torrents
here
as
well
OPA.
So
a
lot
of
a
lot
of
people
have
faced
customers
faced
real
problems,
and
a
lot
of
us
understand
that
this
is
a
common
cross-cutting
concern
across
heterogeneous
heterogeneous
infrastructure.
So
and
with
this
collective
knowledge,
we
hope
we'll
be
able
to
address
many
of
the
company
of
the
system.
Architecture.
That's
required.
N
That's
required
for
an
end-to-end,
secure
access
come
up
with
common
vocabulary
to
help
define
us
into
insecurities,
and
we
also
believe
like.
There
are
lots
of
gaps
and
libraries
and
protocols
that
needs
to
be
introduced
or
built
to
enable
a
full
on
into
insecure
infrastructure,
and
the
idea
is
like
the
sympathises
more
with
the
operators
and
developers
as
the
work
flow
happens,
so
security
becomes
built
in
process
along
the
way.
N
I'll
touch
briefly
upon
how
we
plan
on
go
about
doing
it
and
we'd
be
happy
to
take
any
comments
on
this
and
suggestions
to
improve
this
process.
We
had
a
draft
Charter
which
we
have
it
done
and
then
the
vision
statements
all
there
now
we
will
through
discovery
there
a
lot
of
people,
including
people
from
NASD,
presented
their
use
cases
and
their
understanding
of
what
secure
access
means
and
you've
gathered
a
lot
of
it
in
the
document.
I
I
I
Maybe
there
are
three:
we
don't
know
exactly
what
it
is,
but
after
we
have
these
use
cases,
we
will
at
least
attempt
to
make
a
draft
of
that,
and
we
think
that
by
breaking
up
into
these
three
phases,
that'll
kind
of
help
keep
us
focused
and
help
feel
like
there's
momentum,
because
we
expect
this
to
be
a
little
bit
of
a
process,
a
time-consuming
process,
but
but
with
artifacts
emerging
from
the
process.
You
know
every
couple
of
months.
I
We
think
that,
even
though
it
takes
a
long
time
that
it's
it
can
be
very
fruitful
in
the
interim.
So
the
second
phase
is
really
looking
at
standards,
because
there
are
a
lot
of
standards
in
this
space.
We'll
look
at
the
CN
CF
project,
see
which
standards
are
widely
adopted,
whether
there
aren't
clear
winners
that
are
working
for
the
community,
and
we
can
just
highlight
those
in
a
clearer
way,
whether
they're
it's
fractured,
whether
people
are
adopting
different
standards
and
thereby
not
interoperable
and
out
of
that
process.
I
The
next
step
is
to
really
catalog
the
projects.
What
is
what
are
people
using
in
terms
of
software
solution
which
CNCs
projects
are
related
and
fill
in
the
boxes,
so
that
we
end
up
with
really
sketching
out
what
this
ecosystem
is,
then
what
we
want
it
to
be,
and
we
anticipate
that
there
are
some
gaps.
There
are
some
that
each
of
us
are
is
motivated
to
come
to
this
working
group,
because
we
see
gaps.
I
We
don't
necessarily
agree
what
those
are
right
now,
but
by
we
get
to
by
the
time
we
get
to
phase
four,
we
think
we'll
have
having
that
shared
vocabulary
and
having
a
deeper
understanding
of
the
space
that's
written
down.
We
think
that
we
can
clarify
what
those
gaps
are
and
they
may
be
improvements
that
we
want
met.
I
In
a
way
that's
going
to
be
efficient
to
getting
to
us
to
this
end-to-end
security
that
crosses
clouds
and
crosses
on-prem
and
the
cloud
providers
which
we
all
see
as
a
critical
concern
for
anybody
who's
doing
substantial
cloud
native
apps.
So
this
all
culminates
in
a
recommendation
and
I'm
gonna
hand
this
off
to
Dan
who's,
going
to
review
our
proposal
great.
D
So
with
that,
with
the
context
that
you
know
this
group
that
that's
been
gathering
since
basically
Kubek
on
Austin
last
year
and
meeting
regularly,
you
know
this
past
quarter,
you
know
it's
it's.
You
know,
I
thought
that
that
interest
in
you
know
this.
This
cross-cutting
concern
of
safety
is
a
great
fit
for
the
CNC
F
a
couple
of
non
goals.
You
know
we're
not
here
to
choose
a
single
provider
or
single
security
technology,
and
obviously
we
aren't
a
standards
body
for
creating
standards.
D
But
we
are
a
you
know,
a
broad
group
of
your
concerns
across
the
cloud
ecosystem
and
yeah.
We
would
love
to
you,
know
bring
this
to
the
CTF
and
our
ass
are
specifically
yeah.
We'd
like
to
get
as
many
use
cases
in
we've
already
gone
through
a
few
had
some
some
great
presentations
from
the
folks
at
NIST,
Cloud,
Foundry
and
Google
and
we'd
love
the
opportunity
in
this
discovery,
phase
to
work
with
members
and
projects
and
integrate
that
into
this
broader
safety
story.
D
G
G
D
At
present
I,
you
know
I
believe
what
we
can
offer
to
that
group
is
to
listen
and
provide
feedback
in
terms
of
the
data
that
we
collected
so
far,
but
at
present
we
are
not
in
a
position
to
you,
know,
direct
or
add
towards
the
solution,
so
we
can
partner.
We
can,
you
know,
help
them
gain
perspective
on
you
know.
Some
of
the
other
concerns
other
peers
that
they
may
have
in.
I
This
a
little
bit,
not
I,
think
everything
Dan
says
is
right
and
we
want
to
set
expectations
that
we
are
nascent.
You
know
we've
got,
we've
got
a
group
of
people
that
are
coming
together
for
purpose
and
have
for
many
of
us
an
hour
a
week,
plus
the
async
activities
is
a
significant
time
commitment.
However,
we
think
that
by
being
a
CNC
F
working
group,
we
could
potentially
provide
a
structure
where
we
say
that
you
know
anybody
who
any
new
project
that
is
seems
related.
We
would
invite
them
to
just
sign
up
for
a
presentation.
I
So
then,
instead
of
us
going
and
finding
everyone,
we
would
just
have
this
steady
stream,
and
so
we
would.
We
would
offer
the
TOC
that,
after
that
presentation,
we'd
record
it.
We
would
write
our
summary
and
in
the
discovery
phase,
that's
pretty
much
all
we
would
do.
We
would
the
observations
of
the
people
of
the
working
group
later.
I
We
would
be
able
to
place
this
project
in
our
diagram
in
the
landscape,
and
we
would
ask
them
to
validate.
Is
this
feel
like
where
you
belong
right?
And
so
we
would?
You
know
it's.
It's
not
like
new
projects
are
adopted
every
week
or
something
so
there's
a
pace
that
I
think
would
be
reasonable
and
then
the
new
projects
are
fitting
themselves
into
the
landscape
and
then
we're
echoing
that
back
to
the
TOC.
Not
not.
I
N
Specifically
yeah
specifically
to
address
the
two
projects
that
Alexis
asked
about
in
CN
CF
I
am
part
of
spiffy
six-pack,
so
I'm
working
on
it
and
I
bring
in
the
perspective
that,
from
there
I've
been
fairly
involved
in
giving
comments
and
feedback
to
OPA
from
very
early
on
and
taurine
is
perhaps
part
of
this
working
group
already.
So
as
far
as
those
two
projects
are
concerned,
we're
good
to
go
and
for
the
new
once
we
would
like
to
have
a
similar
or
deeper
integration
with
the
newer
projects.
N
K
I
had
a
question
and/or
comment,
depending
on
which
way
you
look
at
it.
So
a
lot
of
this
workers
de-facto
happened
in
the
sigurth
special
interest
group
inside
Reuben
at
ease.
It's
not
you
know.
Its
mandate
is
not
the
same
as
this
working
group,
but
but
de
facto,
for
lack
of
a
better
place.
These
are
where
most
of
these
discussions
have
been
happening
so
question.
K
What
is
the
relationship
between
this
working
group
and
sigurth
in
kubernetes
or
stated
another
way,
I
think
that
it
would
be
very
beneficial
to
have
a
very
close
working
relationship
between
those
two
groups.
Otherwise
we're
going
to
end
up
with
you
know
two
buddies
doing
very
significantly:
overlapping
work,
potentially
diverging.
D
So
I'll
let
her
JJ
speak
to
sing
off.
You
know
specifically,
but
another
kubernetes
group,
sync,
sync
policy.
You
know:
we've
already
begun
sort
of
cross
pollinating
with
that
group.
So
yes,
all
the
work
that's
happening
in
kubernetes
is
you
know,
kind
of
you
know
leading
a
lot
of
the
direction
that
that's
happening,
but
you
know
there
are
all
the
other.
You
know
infrastructure
components
in
the
cloud
native
ecosystem
that
you
know
aren't
kubernetes
and
you
know,
while
some
of
us,
including
myself,
it
may
believe
that
the
kubernetes
is
the
eventual
future.
D
You
know
it
is,
you
know
an
implementation,
so
you
know
with
this
working
group.
We
really
want
to
be
that
the
clearinghouse
for
those
cross-cutting
safety
concerns
and
bring
those
together
bring
the
interest
of
cig
off,
bringing
the
interest
of
sig
policy
into
this
overarching
safety
concern,
and
you
know,
collaborate
with
with
those
groups
today.
Sir,
do
you
have
anything
to
add.
I
I
I
haven't
been
involved
in
those
working
groups,
but
I'm
like
we
will
do
both
less
and
more
right
because
it
certainly
initially
we're
not
gonna
get
into
the
details
of
specific
implementations,
and
now
that
ties
into
you
know
the
the
different
you
know
like
how
we'll
have
representatives
from
Kabul.
We
won't
dive
into
how
it
works
inside
of
Google,
we'll
have
representatives
of
kubernetes
and
and
vice
versa,
and
and
so
we're
already
excited
to
have
people
involved
in
both
groups
from
the
policy
side
and
I.
Don't
know
J
did
you?
N
No
I
think
I've
been
in
touch
with
Jordan
Lee
get
and
Jordan
Liggett
is
aware
of
this
and
I.
Don't
know
if
anybody
else
since
I
got
of
course,
Jo
Jo
betas
aware
of
this,
but
I
don't
know
if
anybody
else
that.
N
We've
also
noticed,
like
bunch
of
a
bunch
of
the
discussions
around
ABI
questions
are
back
versus
Lykes.
Other
things
happening
in
quite
a
number
of
places,
whether
it's
since
I
got
slash
the
policy,
slash,
spiffy,
slash
OPA,
which
are
all
the
same
discussion
happening
in
multiple
different
places,
but
then
it's
it's
something
that
we
can
actually,
we
feel
like.
I
So,
in
terms
of
the
scope
that
we've
we've
working
spent
a
lot
of
time,
wordsmithing
this
and
it's
not
quite
perfect,
but
what
we
found
is
that
there's
there's
a
big
there's
sort
of
it's
hard
to
put
bounds
around
this,
and
this
is
why
we
need
this
vocabulary.
We
for
a
while
we
were
talking
about
policy
but
I'll,
see,
is
very
expensive
space.
I
When
you
have
multiple
pieces
of
software
in
different
clouds
or
on-premise
and
cloud
that
have
different
definitions
of
how
they
secure
their
systems,
and
so
so
we
want
to
dig
in
so
that
this
is
clearly
defined.
Where
we're
not
saying
you
know,
we've
said
okay
well
like
if
I
deploy
a
piece
of
software,
and
it
has
a
vulnerability,
that's
out
of
scope
right,
but
that
I
was
allowed
to
deploy
that
software
and
that
it
was
configured
in
this
way.
I
N
Inch
in
short,
imagine
imagine
we
are
imagining
how
it
would
look
like
if
we
were
to
implement
triple-a,
authentication,
authorization
and
auditing
across
heterogeneous
systems
with
episodic
access
and
things
that
needs
to
get
addressed.
Part
of
that
right
and
it's
a
well-defined
protocol.
But
given
the
complexity
of
the
heterogeneous
system,
it's
not
a
veil
understood
and
a
well
structured
into
end
architecture,
and
that's
essentially
what
we
are
after.
M
G
D
And
I
think
there
there's
a
couple.
You
know
things
that
we
are
not
that
helped
clarify,
and
you
know
I
I
tried
to
get
us
to
distill
down
to
a
single
word
and
yeah.
We
went
through
security
right,
secure,
working
security,
working
group.
My
goodness,
that's
a
lot
of
you
know
a
lot
of
land
grab
and
same
thing
with
policy.
We
looked
at
that
as
like
wow
like
that,
there's
so
many
permutations
out
of
that.
D
So
you
know
safety
and
the
secure
access
you
know
gives
our
group
focus
and
we
have
spent
a
lot
of
time
and
trying
to
get
that
clear,
and
you
know
we.
We
know
that
that
it
is,
you
know
we
would
love.
You
know
that
the
turn
of
phrase
that
would
you
know,
get
everybody
aligned
and
understand
immediately
what
what
we're
talking
about.
G
G
Don't
want
CN
CF
to
become
an
organization
where
working
groups
instruct
individual
projects
and
of
what
to
do,
because
they
will
typically
be
exploring
things
very
close
to
what
users
want
if
something
like
this
became
drifted
away
from,
for
example,
what's
happening
in,
and
parts
of
Cuba
Nettie's
that
are
concerned
with
security.
That
would
probably
be
a
concern
because
it
would
be
unlikely
that
people
would
pay
attention
to
the
group
if
it
was
differing
from
what
was
happening
in
practice.
G
G
We
did
see
this
previously
with
this
storage
group,
where
there
were
at
least
at
the
beginning,
that
was
sort
of
parallel.
Parallel
efforts
around
what's
happening,
kubernetes
api
is
and
what's
happening
in
the
working
group,
so
the
sooner
those
two
things
are
brought
together:
the
better
for
everybody.
So
let's
take
this
offline
and
take
it
to
github
and
then
come
back
in
in
an
letÃs,
get
an
update
that
sound
good,
okay,
okay,
your
night
thank.
I
G
E
E
Pacific
time
except
I
mean
invite
on
the
CNC
F
calendar
for
that
timeframe
and
if
be
able
to
join
us,
please
do
and
we
are
going
to
be
looking
at
the
existing
reference
architecture
in
a
landscape
work
and
to
propose
next
level
down
in
detail
for
more
of
a
technical
reference
architecture
in
that
meeting
and
all
feedback
and
come
in
to
welcome.
So
please
choice.
If
you
can't
and
I'll
just
remind.
H
Folks
that
we
have
a
lot
of
users
now
at
landscape,
that
CFCF
dot,
IO
or
just
l,
dot,
CMC,
f10
IO,
and
that
is
based
on
off
of
this
reference
architecture.
So
for
folks
who
are
not
happy
with
the
categories
that
we
have
now
or
think
this
should
be
combined
or
split
up
or
such
it's
Ken's
work
here
that
will
lead
to
the
next
generation
of
the
landscape.