►
From YouTube: CNCF TOC Meeting - 2018-11-20
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
A
A
B
B
A
Sure
you
know
we
just
held
our
conference
Kubik
on
China
for
the
first
time
last
week,
so
that
was
super
exciting.
Thank
you
for
Quintin,
for
taking
the
time
to
show
showing
up
and
representing
the
TOC
there.
We
posted
the
videos
online,
so
you
should
be
able
to
see
most
of
the
talks
there
on
YouTube
Seattle
is
coming
up
in
a
few
weeks.
Our
flagship
event
is
currently
sold
out.
So
thanks
everyone
for
signing
up,
it's
a
little
bit
difficult
to
predict
them.
A
A
A
We
are
currently
in
the
nomination
period,
which
ends
at
the
end
of
this
month.
Essentially,
every
CN
CF
member
has
the
ability
to
nominate
up
to
two
folks
during
this
process
and
then
there's
a
qualification
period
that
happens
where
the
governing
board
vet
these
candidates
and
then
a
formal
election
is
run
Condorcet
style,
and
then
we
have
a
new
TOC
on
January
29th,
seven
of
nine
slots.
Any
questions
here.
D
A
E
A
Well,
this
is
just
a
reminder
for
the
backlog.
You
know
always
a
good
idea
to
kind
of
take
a
look
at
that
and
offer
any
assistance
to
the
TOC
on
reviewing
proposals,
reviews
and
so
on
as
they
go
in
next
slide.
Is
the
core
I
think
focus
of
today's
meeting?
Is
the
kind
of
category
slash
refresh
of
working
groups,
so
Alexis
I'm
going
to
go?
Leave
it
to
you
to
bring
this
up
right.
B
Besides
that,
the
core
idea
is
to
identify
a
set
of
categories
such
as
observability
or
storage
or
security,
and
then
try
and
bootstrap
up
dedicated
efforts
driven
by
the
community
shepherded
by
the
TOC
and
other
volunteers
and
assisted
by
the
CN
CF
team,
folks,
like
Chris
and
Chris's
team
and
his
colleagues
in
order
to
make
us
get
more
work
done
and
add
more
value
to
users
and
make
projects
more
successful
and
more
attractive.
Make
C&C
have
more
attracted
to
those
projects.
So
to
that
end,
a
proposal
has
been
drafted
around
the
categories
and
working
groups.
B
If
you
click
on
the
link,
you'll
see
the
proposal,
if
you
can't
see
it
out,
because
it
might
not
be
I,
think
all
the
settings,
let
you
see
it
I
think
I've
set
it
up
to
be
editable
by
anybody.
So
please
don't
go
spanning
the
text
if
you,
unless
you
have
a
very
good
reason,
it's
not.
It's
had
a
quick
pass
from
the
voting
members
of
the
tea,
see
and
I
think
the
kind
of
basic
ideas
are
there
now
ready
for
folks
to
jump
in
and
start
to
contribute.
B
A
B
B
The
absolutely
key
idea
dear
here
is
Lee
is
asking
if
SIG's
client
working
groups,
we
originally
call
these
category
working
groups
but
felt
that
actually
they
had
a
very
special
purpose,
which
was
quite
similar
to
the
six
in
kubernetes.
So
it
was
suggested
to
use
the
word.
Zig
describe
the
working
group
associated
with
a
category,
so
they're
not
they're,
not
getting
rid
of
all
the
working
groups,
but
some
of
the
working
groups,
like
security
and
safe,
would
morph
into
it
sig
to
be
associated
with
that
category.
B
E
Alexa
said
I
just
want
to
make
it
clear
that
that
the
current
SIG's
were
actually
put
in
place
as
the
current
working
group
for
put
in
place
as
working
groups
as
short-term
yes,
groupings
to
produce,
essentially
white
papers
or
other
define
things
which,
which
is
quite
different
than
the
sig.
So
I,
don't
think
they
necessarily
turn
into
SIG's
or
certainly
not.
The
current
formation
of
the
working
group
doesn't
magically
become
a
sig.
F
B
F
G
This
is
Brian
I
think
this
looks
good.
My
only
comment,
such
as
it
is
to
it,
be
that
I
think
experts
in
any
given
field
often
have
the
the
bias
of
their
particular
experience
and
expertise.
I
I
may
change
that
wording
just
slightly
to
clarify
that
that
their
responsibility
is
not
to
their
particular
technology
or
their
company,
but
to
the
broader
special
interests
group,
because
I
I
wouldn't
want
us
to
be
excluding
people
to
be
running
SIG's
because
they
happen
to
develop
their
expertise
in
a
particular
technology.
I
see.
B
That's
a
good
point.
Thank
you
for
bringing
that
up.
I!
Think
that
you
know.
Essentially,
why
are
we
doing
this
I
mean
the
objectives
are
set
out
at
the
top
of
the
document,
but
it's
just
become
impossible
for
the
core
TOC
membership
to
properly
keep
on
top
of
everything
as
the
CNCs
as
grown,
and
whilst
we've
made
some
headway
with
tio,
some
contributors
and
the
community
was
still
I,
think
you
know
struggling
to
really
really
scale
and
get
organized.
B
So
this
is
an
attempt
to
do
that
and
it
represents
in
a
way
the
sort
of
biggest
change
in
how
we
work
for
some
time.
What
we
want
to
do
is
retain
the
ability
of
the
nine
ctoc
to
to
do
things
like
vote
in
projects
and
to
be
to
really
focus
on
making
sure
that
CN
CF
is
doing
a
great
job
for
the
community
and
users
and
nation,
but
also
to
invite
people
to
help
and
for
us,
I
think
we'd
be
talking
about
this.
B
The
most
important
thing
to
us
is
that
the
folks
who
are
putting
in
the
most
time
really
understands
what
this
again
is
trying
to
do.
What
its
mission
is
and
demonstrate
a
lot
of
integrity
in
terms
of
that
mission,
so
we're
worried
that
a
cig
or
any
kind
of
working
group
could
become
its
own
sort
of
political
structure.
We
think
that
we've
been
bad
outcome,
so
we've
tried
in
this
initial
structure,
to
come
up
with
a
way
to
balance,
sharing
and
retaining
full
control
in
the
TOC.
B
If
that
makes
sense,
which
means
that
we
are
actively
seeking
people
to
show
leadership
in
these
SIG's
who
we
think
you
know
it
would
be
people
who
we
welcomed
into
a
future
tio
sees
in
another
time
if
that
makes
sense,
so
you
don't
need
to
be
a
category
expert.
You
need
to
be
somebody
who
deeply
cares
about.
The
mission
deeply
cares
about
the
community
and
is
able
to
demonstrate
balance
and
integrity
in
that
process.
H
H
E
Yeah
there
was,
there
was
my
wording.
The
unbiased
and
I
knew
as
I
was.
Writing
that
it
was
gonna,
be
controversial
and
I
totally
agree
with
your
sentiment.
Brian
I
just
couldn't
think
of
a
short
way
of
describing
what
we
what
we
just
said
in
a
hundred
words,
but
I
think
we
can.
We
can
wordsmith
to
be
better.
B
H
This
is
Matt
Farina.
You
know
it
might
be
interesting
to
put
a
purpose
at
the
beginning
of
this,
not
just
getting
the
technical
introduction,
because
I
think
what
you're
trying
to
say
is
you
want
to
scale
the
contributions
to
the
CNC
out
around
the
expertise
because,
as
we
see
the
scene
CF
growing,
at
least
this
is
my
two
cents
on
it.
H
We
see
the
scene
self
growing
with
the
number
of
projects
and
things
going
on,
there's
there's
more
an
expertise
and
knowledge,
and
we
want
to
be
have
a
place
to
scale
that,
and
this
is
that
opportunity
to
do
it
and
it's
sort
of
reflective
of
how
kubernetes
has
been
able
to
successfully
do
it,
but
with
our
own
slant
on
it.
Is
that
sound
about
right.
G
Think
what
we
have
found
is
that
the
surface
area
is
now
so
broad
that
we
require
depth
in
so
many
different
domains
that
we
need
to
have
the
ability
to
delegate
that
depth.
At
least
what
I
say.
Is
that
I
think
that
there
are?
You
know
so
many
projects
that
that
come
up
for
you
know
incubation
or
other
kind
of
feedback
to
the
CNC
ftse
and
they
are
I'm
not
able
to
provide
feedback
for
them
because
they're
simply
not
in
my
there
they're
a
deep
technical
project.
G
That's
not
my
area
of
expertise,
I
don't
personally
use,
so
the
SIG's
I
think
allow
us
to
delegate
some
of
that
delegate
where
people
can
get
really
good
technical
feedback
and
guidance
from
people
that
have
been
effectively
delegated
by
the
TOC
and
then,
when
those
projects
are
deemed
kind
of
ready
or
appropriate
by
the
SIG's.
We
as
a
TOC
can
have
more
confidence
in
more
background
in
terms
of
what
the
extra
are.
I
Hey
Alexis,
this
is
a
pratik
water
from
Intuit.
Here,
hello,
hey
there,
hey
I
had
a
just
a
quick
rough
question
which
is:
would
would
there
be
a
disconnect
between
this
cig
and
an
appropriate
kubernetes
cig,
and
how
do
we
make
sure
that
we
don't
create
a
parallel
working
structure
or
parallel
ideas?.
B
Very
interesting
question,
so
let
me
try
and
answer
that
I'm
not
sure
if
I'll
get
it
right
and
I
think
kubernetes
sig
is
focused
on
extending
kubernetes
with
functionality
reflected
in
the
sake.
So,
for
example,
I,
don't
remember
what
the
names
are
of
the
pieces
of
kubernetes
with
monitoring,
but
I'm,
aware
that
there
are
recommendations
about
how
to
monitor
kubernetes
and
making
sure
that
it's
possible
to
do
that
in
this
CNC
air
we
might
have
an
observability
stick,
which
included
projects.
B
B
I
B
H
We
have
kubernetes
sig
apps
and
we
have
talked
about
things
that
are
various
specific
to
extending
kubernetes,
but
also
lots
of
related
tools
that
help
people,
because
sig
apses
wanted
to
encourage
that
app
developer,
an
app
operator
space,
but
over
here
I
see
we
have
a
category
for
something
like
app
definition
and
development,
and
so
since
there
is
that
broader
space
and
say,
gaps
is
definitely
touched
on
it
in
kubernetes,
there's
definitely
gonna
be
overlapping
effort
at
the
CN
CF
and
so
I
figure.
We
need
to
probably
resolve
that
and
it'll
just
be
a
case.
H
Maybe
were
the
kubernetes
thing
in
the
other.
Sig
need
to
talk
and
figure
it
out,
I
don't
know,
but
there
there
are
spaces
where
we
are
gonna.
Have
that,
because
kubernetes
sakes
have
gone
just
beyond
extending
kubernetes
to
try
to
enable
the
space
as
a
whole,
which
I
think
is
what
the
CN
CF
wants
to
do.
Yeah
that.
J
J
From
the
we
have
an
example
in
our
group,
that
is
actually
the
kubernetes
policy
working
group
as
they
were
looking
to
extend
beyond
you
know
what
they
were
doing.
They
decided
well
actually
the
first
they'd
they
they
drafted
a
proposal
to
go
to
CF,
and
then
they
looked
at
that
and
this
looks
awfully
like
safe.
Maybe
we
should
just
join
forces
with
that
working
group
and
yeah.
We
became
a
larger
body
because
of
that
incorporated
their
interests.
K
No
I
think
that
any
say
in
kubernetes
that's
working
on
anything
that
looks
like
a
pluggable
or
extendable
interface
is
going
to
almost
by
definition,
extend
outside
the
kubernetes
project.
Whether
it's
scheduler
si
si
o
si
si
and
I
like
take
your
peg,
so
I
think
I
I
don't
see
this
as
conflicted,
though
I
just
see
it
as
a
like
there's
already.
These
great
touch
points
for
the
kubernetes
things
to
work
and
in
hand
with
CNC
f6,
not
a
not
a
conflicted
thing.
E
I
also
gave
some
thought
to
that
and
I
think
it
applies
generally
to
to
the
terms
in
not
not
necessarily
to
the
individual
SIG's,
and
we
can
have
this
confusion.
You
know
one
simple
of
we
did
consider
calling
on
something
completely
different,
but
then
you
know
they
do
fulfill
a
very
similar
function
to
the
SIG's
and
community,
so
that
would
create
a
different
kind
of
confusion.
F
G
Yes,
I
think
it's
a
good
idea
to
just
make
clear
that
we
we
know
that
we
need
to
make
a
distinction
here
and
that
there
will
be
some
groups
involved.
I
also
think
there'll
be
some
SIG's
that
don't
overlap
at
all
or
there'll,
be
some
SIG's
that
when
they're
there
kubernetes
eggs
are
solely
focused
on
that
attribute,
as
as
it
pertains
to
kubernetes
I'm.
Obviously,
thinking
observability
in
particular,
where
the
observability
technologies
are
really
orthogonal
to
kubernetes
itself.
L
L
E
So
those
are
two,
you
know
quite
distinct
kinds
of
entities,
and-
and
these
things
we
were
talking
about-
are
long
lived,
so
they
live
forever,
basically
and
they're
responsible
for
all
of
the
projects
that
fall
within
that
area,
whether
it's
you
know,
observability
or
storage
or
networking
or
whatever
we
envisage
that
within
each
of
those
SIG's.
There
will
also
be
working
groups
that
are
spawned
to
solve
specific
problems
within
the
ambit
of
that
sig.
Also,
perhaps,
in
some
cases,
crossing
SIG's
does
that
make
sense.
Yeah.
L
Yeah
sure
does
I
mean
yeah,
I,
think
at
first
blush
or
particularly
makes
sense.
If
that's
the
way
in
which
kubernetes
things
have
been
run
and
are
understood
and
and
that
through
that
understanding,
the
use
of
the
term
state
CNC
F
sake
just
helps.
People
have
a
the
right
frame
of
reference
to
begin
with,
and
that
makes
that
reinforces
the
notion
that
you'd
use
city
of
the
term
as
opposed
to
committee.
You
or
you
know
you
know,
or
whatever
else
you'd
call
it
yeah.
G
C
B
B
B
Work
on
it
together
over
the
next
two
weeks
and
we'll
see
if
we
can
get
to
a
revised
version
in
time
for
the
next
EOC
call,
it's
not
a
promise,
but
it'll
evolve
along
the
lines
of
the
sandbox
document
which
took
a
few
goes
to
get
right
in
the
case
of
the
sandbox.
It
wasn't
until
quite
late
in
the
process
that
we
that
we
realized
some
quite
crucial
stuff
that
we
missed
out.
So
you
know
be.
Please
do
keep
making
an
effort
to
make
this
this
document
better.
A
So
I'm
happy
to
kind
of
go
over
this
fairly
quick
I
sent
them
out
to
the
mailing
list.
I
think
it's
been
a
few
a
few
weeks
ago,
but
happy
to
go
over
it
quickly,
and
then
we
have
some
graduation
reviews
that
kind
of
want
to
have
the
option
two
percent.
So
I'll
go
over
this
really
quickly.
So
we
survey
our
maintainer
community
twice
a
year,
and
so
we
did
this
recently
and
we've
kind
of
collated
the
resort
results
for
this
year.
A
A
But
this
kind
of
main
takeaways
that
at
least
I
had
from
this
was
ciencia
projects
are
mostly
asking
for
support
kind
of
in
three
major
areas.
The
first
one
is
around
kind
of
technical
documentation
website
help
other
one
is
around
just
marketing
help
us,
you
know,
write
a
blog
post
or
technical
article,
technical
blog
and
the
other
one
is
around
events:
hey
help
us
host
a
you,
know,
envoy,
con
orgy,
RPC
conference,
etc.
A
So
that's
kind
of
my
overall
takeaways
for
here
and
we've
properly
staffed
up
recently
on
the
technical
writer
side
of
the
house,
and
we
continue
to
serve
our
project
maintainers
with
events
like
envoy,
con
gr,
PC,
Cohn
and
so
on.
So
I
don't
want
to
dive
into
each
specific
question
that
kind
of
goes
on
the
next
few
slides
but
I
think
on
slide
20.
We
have
some
of
the
comments
you
know,
as
has
CNC
reset
for
projects,
you
understand,
help
response
time
and
so
on,
but
slide
20
kind
of
shows.
A
D
A
J
D
Worries
so
yeah
I
think
I'm
not
going
to
walk
through
the
exact
checklist
of
toç
graduation
criteria.
The
PR
is
linked
and
I.
Think
I
assume
many
people
have
seen
it
at
the
end.
Obviously,
if
there
are
specific
questions
about
checking
off
items
on
the
list,
we
can
discuss
that,
but
mainly
stay
somewhat
high
level.
I
assume
many
people
have
heard
of
container
D.
D
We
joined
the
CNC
F
at
the
Berlin
kook
on
just
last
spring,
the
goal
being
to
have
this
core
container
runtime
for
both
docker
beretti's.
To
have
this
sort
of
boring,
stable
infrastructure
run
time
under
under
which
both
could
could
then
innovate.
Our
key
tenants
have
really
been
again
thinking
about
this
being
boring.
Infrastructure
is
having
a
a
strong
focus
on
reliability.
Stability
of
that
core
runtime
again,
we're
built
on
top
of
OSI
eyes,
run
C.
D
So
again,
our
goal
is
not
to
add
a
bunch
of
functionality
around
app
but
to
simply
have
a
strong
guarantee
of
life
cycle
control.
Over
run,
seed
launched
containers
around
that
we've
built
a
really
nice
client
API.
That
means
from
golang
or
G
RPC
people.
People
can
build
other
interesting
things,
not
just
docker
and
kubernetes,
and
so
you
can
see
if
he
tweets
here
of
people
who
have
found
that
very
interesting
and
and
in
our
project
use
list
which
we'll
look
at
on
the
last
slide.
D
D
We've
also
added
strong
compatibility
guarantees,
backporting
fixes
so
having
long
term
releases
that
are
supported
in
a
very
stable
and
and
reliable
way,
and
then
performance
obviously,
is
another
key
tenant.
Next
slide,
our
community
I
believe
has
has
been
very
healthy
and
it
has
grown,
especially
even
this
year.
I
think
one
of
the
nice
things
about
the
graph
it's
a
little
bit
small,
but
obviously
you
can
go
to
the
CN
CF
data
and
I.
D
D
We
you
have
12
maintained,
errs
across
eight
organizations.
That's
listed
a
little
more
in
a
detailed
way
in
the
PR.
We
have
a
reviewer
category,
they're
allowed
to
lgt
em,
but
not
merge,
and
so
that
list
has
been
growing
and
again,
if
you're
interested
in
stars
and
Twitter
followers
and
all
that,
obviously
again
there
seems
to
be
a
healthy
interest
and
community.
That's
come
up
around
container
D
last
slide.
D
So
again,
you
know.
Obviously
the
goal
would
be
that
container
D
would
grow
in
usage,
and
so
today
we
have
two
public
clouds
who
are
offering
container
D
as
the
kubernetes
runtime,
so
IBM
cloud
and
Google,
so
GK
and
IBM
are
both
offering
recent
versions
of
kubernetes
with
container
D
as
the
runtime
Alibaba
Cloud.
We
several
of
us
just
met
with
some
of
the
teams
from
that
organization.
Last
week
in
Shanghai,
their
pouch
container
project
is
built
around
container
D.
D
You
can
see
other
uses
as
well,
but
again
we
see
a
significant
growth
and
interest
and
usage
of
container
D,
and
the
graduation
proposal
has
a
more
extensive
list
of
projects
that
are
using
container
D.
So
with
that
I'm
a
little
bit
under
five
minutes
and
so
I'll
stop
there
and
see
if
there
are
any
specific
questions
we
can
answer.
K
This
this
may
be
more
of
a
kubernetes
question
than
a
container
D
question,
but
do
you
have
a
view
as
to
lend
container
D
might
might
or
if
or
my
tour
will
become
default
runtime
for
kubernetes
I,
don't
believe
the
kubernetes
project
tests
it
as
a
feature
walking?
It's
not
a
release
blocking
compatibility,
it's
kind
of
less
than
after
the
fact.
K
D
M
N
K
Don't
believe
that
it
is
I
believe
it
is
tested
after,
in
other
words,
a
regression
would
not
cause
kubernetes
or
as
a
release
not
to
ship
it
would.
It
would
obviously
be
something
the
container
D
community
would
react
to,
and
I
I
mean
I'm
I'm,
actually
very
supportive
of
getting
container
D
to
that
state.
So
anyway,
yeah
yeah.
N
D
D
Obviously,
any
application
which
decides
it
needs
to
inspect
the
hosts.
You
know
either
through
you
know,
sharing
namespaces
with
the
hosts
or
trying
to
interact
with
underlying
runtime,
obviously
will
care,
but
but
an
application
which
purely
uses.
The
kubernetes
api
should
have
no
concern
or
or
effectively
no
problem
with
being
agnostic
to
the
underlying
runtime.
Okay,.
E
A
A
E
A
B
O
Yes,
yes,
Justin
Kappas,
so
yeah,
so
just
a
quick
reminder
for
those
of
you,
so
tough
is
the
way
in
which
software
gets
distributed,
largely
across
a
bunch
of
domains,
including
the
cloud
that's
resilient
against
server
and
key
compromises.
So
it's
a
framework
that
makes
it
so
that,
even
if
people
break
in
to
different
parts
of
your
infrastructure
different,
you
know,
you're
signing
your
repository
or
other
aspects
of
your
cloud
infrastructure.
It's
meant
to
resist
this
so
we're
something
of
the
the
plumbers
plumbing
so
I
know.
O
A
lot
of
you
know,
basically
what's
being
done
here
in
the
cloud
is,
is
basically
plumbing
for
the
services
of
the
future
and
we're
even
kind
of
you
know,
just
the
boring
underneath
part
under
that.
So
tough
has
multiple
roles.
It
has
a
bunch
of
issues
with
you
know
it
uses
to
provide
security,
a
bunch
of
things
like
threshold
signatures,
selective
delegation
supports
HSMs
and
TPMS,
and
so
on
and
there's
a
couple
of
things
that
tough
does.
That
makes
it
fairly
invisible
under
the
under
the
surface.
O
It's
intentionally
meant
to
be
very
easy
to
drop
into
existing
workflows,
and
so,
apart
from
maybe
needing
someone
to
sign
something
they
didn't,
they
didn't
sign
before.
You
know
which
it
can
be
as
easy
as
just
making
a
change
to
a
script
or
having
them
use.
A
Yubikey
tuff
is
meant
to
be
very
invisible.
There's
often
a
one-time
initial
set-up
cost
of
having
to
make
a
couple
changes
somewhere
in
the
way
you
sign
and
build
things,
but
it's
very
meant
to
be
very
transparent
and
easy
to
use,
and
it
has
a
very
strong
security
focus.
O
So
there's
minimal
design
with
this
or
sorry
there's
a
minimal
intentially,
minimal
design,
we're
not
trying
to
grow
and
add
and
have
every
possible
feature,
and
it's
meant
to
be
low
turn
for
those
who
go
and
implement
the
system.
So
the
history
of
this
is
back
in
2010
I
had
some
folks
from
the
Tor
project
that
that
came
to
visit
after
they'd
seen
some
work,
we've
done
on
security
for
Linux
package
managers
and
saw
there
were
a
bunch
of
issues
with
that.
O
We
pointed
out
there
that
also
applied
to
the
Tor
updater,
and
they
spent
a
little
bit
of
time,
did
a
bit
a
bit
design
and
went
away
and
huddled
and
then
created
a
design
that
we
found
some
issues
with.
So
we
built
on
that
and
and
made
a
different
version
of
it
that
that
was
tough
made
myself
in
an
undergraduate
was
working
with
me.
We
were
admitted
to
the
CAF
in
2017,
along
with
notary
notary,
which
was
created
by
docker,
is
the
most
widely
used.
O
Implementation
of
tough
inside
of
the
cloud
and
is,
is
one
of
the
most
popular
implementations
of
tough
over
all
tough
itself,
as
a
project
has
a
formal
process
for
changing
the
standard,
because
we
are
meant
to
be
very
low,
churn
and
have
a
very
simple
minimal
design.
So,
there's
a
process
called
a
tap
process,
and
this
is
perhaps
one
of
the
biggest
distinctions
between
tough
and
a
lot
of
the
other
CN
CF
projects
is
that
we
don't
directly
interact
with
a
lot
of
the
people
that
adopt
tough.
O
They
mostly
interact
with
whichever
implementation
of
toth
they
they've
gone
and
integrated
if
they
use
a
reference.
Implementation
as
some
implement
some
integrators
have,
then
we've
actually
communicated
with
them,
but
oftentimes
I
will
find
out
that
we
have
a
new,
tough
deployment
because
I'll
hear
something
from
the
notary
team
or
hear
something
from
another
team
in
a
different
domain.
That's
gone
and
done
this
and
I'll
talk
about
some
of
those
other
domains
in
I.
Think
the
next
slide
so
next
slide.
O
Alright,
so
tough
is
used
in
a
lot
of
cloud,
a
lot
of
the
large
cloud
companies
as
you
can
see
a
list
there
have
gone
and
used
this
if
you
go
and
click
on
the
adoptions
link,
that's
on
the
bottom
of
the
slide
and
you
click
on
any
of
the
company
logos
and
things
it'll.
Take
you
to
the
articles
and
discussion
about
how
they
use
it
and
what
they
do.
O
Don't
really
understand
why
that
is
it's
very
counter
to
the
way
that
most
the
open-source
community
is,
but
we
can't
talk
openly
about
which
of
like,
for
instance,
which
of
the
big
three
US
automakers
uses
is
using
obtain
in
their
new
models
or
which
you
know
large
Asian
automotive
manufacturer
manufacturers
are
doing
so.
But
I
can
say
you
know
from
the
things
that
are
public,
we're
part
of
automotive-grade
Linux
and
about
a
third
of
the
new
cars
sold
in
the
United
States
are
going
to
be
including
obtained
in
the
future.
O
We
also
have
used
outside
of
cloud
for
different
projects
that
are
not
cloud
projects
that
are
using
using
tougher
different
environments,
next
slide
yeah.
So
we
have
a
lot
of
different
committers
that
that
go
and
work
on
different
aspects.
The
most
interesting
aspect
here
is
really
this
specification,
so
these
are
just
different
implementations
here.
The
Python
reference
implementation
has
a
collection
of
folks,
as
do
the
does
notary,
there's
about
six
other
implementations
that
are
done
by
different
organizations.
Some
are
open-source.
Some
are
closed
source.
O
Some
are
things
that
we
can't
really
talk
publicly
about,
but
we
can
talk
about
and
point
to
quite
a
few
of
them.
If
there's
interest,
the
specification
itself
is
fairly
low.
Churn.
We
try
to
be
pretty
protective
about
adding
or
changing
things
in
the
spec,
so
that
our
implementations
can
be
low
turn,
as,
as
you
know,
is
I
deal
with
security
software
next
slide.
O
So
the
real
way
to
look
at
top
at
tough
is
really
to
look
at
the
taps
to
look
at
the
changes
to
the
specification
because
once
again
we're
a
little
atypical
and
that
were
mostly
sort
of
the
specification
rather
than
a
piece
of
software
that
it's
directly
used.
Although
people
do
use
our
Python
reference
implementation
in
in
production,
so
we
have
had
in
the
last
year
and
a
half
or
so
or
two
years
or
something
we've
had
a
bunch
of
accepted
taps.
We
have
several
under
consideration.
O
In
fact,
I
think
there's
been
some
additions
to
this
since
we've
had
this
conversation
and
have
had
a
lot
of
focus
both
from
cloud
native
projects
and
also
outside
projects
that
are
both.
You
know,
automotive
and
broad,
go
and
produce
things
here.
There
have
been
a
bunch
of
activity
on
this,
so
10
different
contributors
with
500,
something
commits
which
is
a
lot
for
something
like
standards
documents.
O
Some
of
these
have
been
things
like
as
simple
as
as
typo
fixes
or
other
things,
but
a
lot
of
them
have
been
just
you
know
more
substantial
clarifications,
you
you
can
see
this.
You
can
see
what
the
changes
of
specification,
notary
and
and
the
Python
reference
implementation
have
also
had
a
healthy
set
of
commits
and
contributors
participate
in
them
next
slide,
and
you
know
the
last
slide
I
have
here.
O
I
just
want
to
say:
we've
of
course
done
all
the
things
that
we're
supposed
to
do
as
part
of
this
who
adopted
CN,
CF
code
of
conduct,
and
you
can
read
for
more
information
about
our
governance
and
contributor
process
adopters
list.
One
last
thing
I'd
like
to
kind
of
leave
people
with
is,
is
that
we
have
both
the
passing
and
silver
and
we're
almost
all
the
way
to
the
gold
badge
for
CII
best
practices
and
I
just
want
to
encourage
everybody
on
the
call.
O
If
you
have
an
open
source
project,
CII
best
practices
is
a
is
a
really
helpful
process
to
go
through
and
I,
encourage
you
to
take
it
and
and
get
not
just
the
passing
badge.
If
you
can
on
your
on
your
projects,
but
to
really
take
it
further,
it's
it's
a
fantastic
project
and
one
that
we're
happy
to
be
working
with
and
happy
to
have
benefited
from.
A
H
O
O
There
are
two
taps
that
we
have
that
we
were
considering
whether
they
should
be
in
a
1.0
or
whether
they
should
be
in
the
next
iteration,
the
two
taps
that
are
pending,
but
we're
we're
basically
ready
to
bump
that
to
bump
that
number,
because
really
all
of
our
main
adopters
are
on
on
or
near
the
the
functionality
that
does
not
include
those
tabs.
So
yeah
we're
ready
to
bump.
To
that.
A
E
Instead,
a
very
brief
observation:
I
went
through
some
of
the
tough
the
proposal,
etc.
It's
it's
kind
of
blurry,
the
distinction
between
the
standards,
the
specification,
the
reference
implementation
and
notary
and
I
quite
often
found
myself
wondering
which
of
these
things.
Are
you
actually
talking
about
here
so
more
like
constructive
feedback
than
a
question.
O
N
N
A
A
All
right,
I
will
think
Justin
first
time,
I'll
shoot
another
email
to
the
TOC
list,
asking
for
more
feedback.
Generally,
our
approach
has
been
asking
the
original
TOC
sponsor
to
kind
of
support
this
request.
But
in
this
case
this
was
Solomon,
so
we'll
figure
out
if
we
get
a
current
TOC
member
to
Shepherd
this
along
to
do
the
formal
call
for
vote.
So
thank
you,
Justin
and
the
tough
and
notary
folks
on
the
call
for
presenting.
A
O
A
A
Cool
awesome
and
then
Ken
can
answer
the
question
on
the
tough
issues
since
he's
doing
some
work
with
it
at
MasterCard,
so
I'll
work
with
Ken
offline
to
get
him
pushing
that
forward.
So
well,
then,
that
thanks
everyone
for
their
time
and
we'll
see
you
in
a
couple
weeks.
First
week
of
December
all
right
take
care
Thanks.