►
From YouTube: CNF WG Meeting 2021-08-23
Description
CNF WG Meeting 2021-08-23
A
A
D
C
C
All
right
standard
thing
that
keeps
coming
up
cube:
common,
o
nes
in
los
angeles,
I
don't
know
who's
going
and
who's
not,
but
we
do
have
our
deep
dive
session
on
the
working
group
itself.
If
anyone's
got
any
other
sessions,
they
think
are
going
to
be
relevant
to
members,
then
stick
them
in
here
so
that
we
all
know
what's
coming
up.
Otherwise
yep,
it's
it's
there
don't
forget
about
it.
We
also
have
the
mobile
world
congress
los
angeles,
coming
up
at
the
end
of
october.
C
B
B
E
C
All
right,
thanks
yeah,
I
think
you
have
to
remember
that
kubecon's
audience
is
very,
very
broad,
so
you
know
we're
always
at
a
disadvantage.
They're
talking
about
a
very
small
subset
of
users
compared
to
the
entirety
of.
What's
going
on,
imagine
you
could
have
said
the
same
with
openstack
and
openstack.
At
least
we
used
to
manage
to
get
talks
in
so.
A
C
C
Only
s
obviously
is
much
more
focused
on
specifically
the
users
that
we
care
about,
but
obviously
less
focused
on
specifically
the
software
that
we're
dealing
with.
So
it's
a
also
an
odd
combination,
but
that's
where
we
stand
yeah
I
mean
I
totally
agree,
and
I
don't
know
that
the
I
don't
know
who
does
the
reviewing
of
talks
for
kubecon
or
how
they
select
that
panel.
C
E
C
E
Go
ahead,
yeah,
so
I've
I've
been
a
part
of
these
particular
of
of
a
couple
of
these
things
for
kubecon
and
they
usually
will
pull
between
six
to
eight
people
through
the
industry
to
do
a
vote,
and
then
they'll
get
two
people
to
chair
it.
Who
then
do
the
the
final
selection,
but
generally
there
is
a
networking
track,
but
one
of
the
things
they
then
they
did
historically,
which
should
help
in
future
kubecons.
E
So
I
think
there
are
some
things
that
can
improve,
but
they
do
have
a.
They
do
have
a
process
for
for
feedback
on
some
of
this
stuff.
So
I
would
recommend
that
we
develop
a
little
bit
of
feedback
on
some
of
the
things
that
we're
struggling
with
and
respond
to
them
so
that
we
can
get
a
better
structure
in
the
future.
Where
we
can,
we
can
get
toxin
that
are
related
to
to
this
particular
industry.
E
Yeah,
so
I
dropped
a
link
in
the
chat
talking,
and
this
is
from
the
latest
kubecon
it's
talking
about
the
selection
process
and
kind
of
like
all
the
numbers
behind
it.
I
think
what
frederick
said
is
like
also
true
that
it's
yeah,
it's
good
yeah,
going
into
the
numbers.
The
acceptance
rate
is
low,
but
I
think
it'll
be
helpful
if
they
split
out
now
that,
like
service
mesh
and
networking
are
sold
out
because
they're
two
very
different
topics.
C
Right,
okay,
I'm
gonna
keep
that
for
later
later
examination,
but
let's
see
right
the
as
I
say,
the
o
nes
obviously
is
a
better
target
for
the
things
that
we're
talking
about
in
a
in
one
way.
So
again
I
don't
know
if
anyone
knows
speakers
at
the
only
s
or
specifically
relevant
talks,
but
again,
if
you
want
to
get
them
a
little
bit
of
free
advertising,
then
make
sure
you
tell
us
what's
going
on
and
we
will
keep
an
eye
out
for
that.
C
Then
we
can
go
and
heckle.
I
also
don't
know
how
many
of
you
are
actually
planning
on
attending
in
person
and
I
suspect
anyone's
plans
at
this
point
in
time
are
subject
to
change.
Speaking
personally,
I'm
likely
to
be
out
of
the
country
at
the
time
that
it
happens,
which
may
have
been
arguably
poor
planning
but
we'll
see
how
this
works
out.
My
plans
might
change
just
the
same
as
everything
else.
Okay,
since
nobody
wants
to
talk
about
anything
else.
C
I
stuck
in
a
note
there
about
least
privileges,
because
taylor-
and
I
have
been
riffing
on
this
for
a
few
weeks
at
this
point-
to
try
and
establish
the
whys
and
the
what
we've
got
the
review
already
out
there
for
the
best
practice,
but
the
best
practice
obviously
didn't
have
any
justification.
It
was
just
his
best
practice
and
we'd
like
to
have
use
cases
that
speak
to
best
practices.
C
C
Google
drive
right,
it's
got
all
of
our
notes
from
from
the
various
meetings
we've
had,
because
we've
been
talking
about
this
sort
of
offline
for
a
few
weeks
at
this
point,
but
we
tried
to
break
this
down
to
at
least
some
of
the
whys
and
the
wherefores.
I
I
think,
what's
clear
here
is
this?
Isn't
a
use
case
in
the
sense
of
this
is
a
specific
thing
that
a
telco
would
want
to
do
it's
more.
C
So
to
begin
with
least
privilege.
The
reason
I
would
suggest
that
it
was
it's
important
is
because,
if
you're
trying
to
work
with
a
platform
and
a
selection
of
applications,
then
you
break
isolation.
If
you
give
any
of
the
higher
privileges
that
are
going
on,
what
you
know,
we
would
call
a
privileged
container
is
obviously
a
privilege,
but
it's
only
one
form
of
privilege.
We've
talked
about
root
users
in
containers
as
well,
both
of
them.
C
Well,
specifically,
the
platform
privileges
tend
to
break
isolation
between
applications
and
application
platform,
and
if
you
do
that,
then
you
start
to
lose
the
sense
of
a
boundary
between
components
and
without
a
boundary
without
establishing
what
a
component
is
trying
to
deliver.
Then
you
run
into
the
difficulty
of
working
out
where
problems
arise
when
they
come
up.
C
C
If
I
call
the
platform
team,
how
do
they
establish
that
the
application
didn't
do
anything
untoward
that
led
to
that
breakage?
It's
least
privilege
basically
isolates
applications
from
each
other
and
from
the
platform
to
the
point
that
when
you
have
a
problem,
you
can
point
a
finger
at
a
team
and
say
this
was
your
component.
You
were
responsible
for
it.
You
are
the
one
who
will
be
able
to
fix
it
for
me
who
will
be
able
to
find
the
problem
as
soon
as
possible.
C
C
That's
been
compromised,
I
think
we've
established
previously.
That
least,
privilege
is
hard
for
us
to
implement.
There
are
a
lot
of
things
that
we
want
to
do
with
networking
that
tend
to
lead
to
asking
for
privilege,
particularly
capsis
admin
as
one
example,
but
other
things
are
set
up
in
such
a
way
that
having
root
privileges
over
the
containers
file
system
is,
you
know,
necessary
to
get
things
working.
C
It
doesn't
mean
to
say
that
those
things
can't
be
fixed
by
relatively
straightforward
means,
but
I
think
we
have
to
establish
to
begin
with
that.
They
do
need
fixing
that
simply
grabbing
the
root
user
and
having
right
right
access
over
the
whole
file
system
or
file
access
over
the
whole
file
system
is,
is
a
dangerous
thing
and
not
100
necessary
to
making
your
application
work.
C
C
C
The
performance
of
an
application
in
a
networking
world
is
tied
up
by
the
fact
that
you've
got
a
lot
of
packets
coming
in
on
a
regular
basis
that
you
have
to
get
rid
of
before
more
packets
come
in
because
you
know
the
world
doesn't
stop
and
traffic
doesn't
wait
for
you
to
process
it.
So
there
is
an
a
calculation
here
that
I've
done
in
front
of
people
many
times
before
now
within
my
company
and
two
customers
that
I
work
with,
but
I
thought
it
was
worth
writing
down
here.
C
It's
a
very
academic
thing
to
consider
in
the
sense
that
you
know.
Yes,
I
have
to
basically
do
numbers
and
make
calculations,
and
you
can
rework
these
calculations
for
yourself.
If
you
want
but
effectively,
we
are
not
serving
websites
where
a
user
will,
you
know,
accept
anything
that
turns
up
within
a
second.
C
C
In
summary,
I
would
say
that
it
isn't
so
much
that
you
can't
do
these
things
in
kubernetes.
It's
often
that
using
those
platform
grade,
privileges
is
necessary
because
there
isn't
a
finer
grained
way
of
getting
exactly
the
right
you
need
in
order
to
get
the
task
done.
You
know
I,
if
I
want
specific
fine-grained
scheduling
behavior.
I
have
no
way
of
asking
for
that
for
the
platform
from
the
platform
and
the
platform
offers
no
concrete
guarantees
that
it
will
happen
as
a
matter
of
course,
without
asking
for
additional
behavior.
A
C
Red
hat
yes,
true
enough,
I
I
am
judging
you
by
the
company
you
work,
for
you
can
always
leave
if
you
don't
like
standing
for
red
hat
on
the
call,
so
it
it's
often
the
case
that
what
we're
trying
to
do
here
isn't
necessarily
impossible.
It's
just
not
practical
in
the
current
world
that
we
live
in
it.
It
may
be
that
certain
areas
of
the
platform
need
enhancement
to
make
this.
C
If
not,
you
know
not
just
possible
but
beautiful,
elegant
from
an
application
design
perspective,
and
I
think,
that's
perfectly
acceptable
to
say
no
one's
saying
that
kubernetes
is
is
polished
and
perfect
is
never
going
to
change,
but
yeah
without
setting
down
some
ground.
Rules
like
as
sctp
is
an
example
that
all
platforms
would
load
that
module
and
include
it
or,
alternatively,
that
there
is
a
means
to
ask
for
the
level
of
functionality
that
you're
looking
for.
Then
you
get
into
difficulty,
writing
applications
that
consume
it
again.
C
I
can
talk
and
talk
and
talk
on
this.
It's
an
interesting
topic,
but
this
is
a
meeting
where
you're
supposed
to
do
the
talking
I'm
supposed
to
share
it.
So
I
don't
know
what
your
thoughts
are
on
this
or
whether
you
want
to
give
this
document
more
study,
either
now
or
later
on
and
see
what
you
think.
A
B
B
Other
principles
that
can
provide
that
right.
If
our
goal
is
isolation
and
say
we
do
need
to
use,
I
don't
know
the
root
user.
For
some
reason,
maybe
the
trick
is
not
to
think
of
it
in
terms
of
least
privilege,
but
in
in
ways
of
how
can
we
increase
isolation?
So
just
an
example
is
kata
containers
right,
that's
or
or
google's
g
visor
right
there
are
if
our
goal
is
isolation
and
we
can't
achieve
isolation
using
least
privilege.
Maybe
there
are
other
things
we
can
do
and
of
course,
protection
as
I
keep
pointing
out.
B
The
whole
field
of
security
is
far
far
more
than
this
principle
right.
So
there's
a
lot
of
ways
to
achieve
protection
and
all
the
things
that
that
are
mentioned
here.
You
know,
in
terms
of
I
I
guess
I'm
saying
these
two
topics,
isolation
and
protection
are
worthy
of
discussion
in
and
of
themselves,
without
connection
necessarily
to
this
principle.
C
A
Yeah
al,
what
we
want
to
end
up
with
at
some
point
is
here
is
a
practice
that
someone
can
implement
and
we
can
get
to
the
many
different
practices
that
you
can
have
out
of
us,
especially
if
you
said
we
want
to
follow
security
practices.
Well,
that's
going
to
be
a
wide
set,
so
we're
trying
to
narrow
it
down
so
that
we
can
end
up
with
some,
but
it
doesn't
mean
as
a
group.
We
must
focus
on
least
privilege
and
we
must
focus
on
non-root.
It's
just
the
first
of
many
things.
C
I
think
I
mean
taking
up
your
points
about
cater
containers
and
g-visor.
Then
the
question
would
be
in
both
cases
the
experimental
method
here,
which
is:
why
are
people
not
using
these
things
to
implement
cnfs,
which
I
don't
think
they
are?
I
mean
I
certainly
haven't
seen
it
if
they
are
the
right
thing
to
do.
Why
is
it
that
it's
not
occurred
to
anybody?
C
Could
you
implement
a
cnf
with
them,
so
you
you
could
take
that
forward
and
ask
yourself
from
an
experimental
basis,
what's
putting
people
off
from
a
practical
basis,
sort
of
tied
to
the
experimental
but
more
more
again,
academic
in
nature
is.
Could
you
implement
a
cnf
with
either
of
those
technologies?
Is
there
something
that
completely
forbids
you
or
prevents
you
from
from
writing
a
cnf
using
those
technologies,
and
certainly
it's
not
going
to
be
as
easy?
There
are
certain
hurdles
to
overcome
like
the
way
again
in
which
we
access
the
network.
C
B
A
Yeah
there
we
go
so
tell
this
section
has
a
whole
list
of
potential
practices
that
are
all
somewhat
related
to
this
area.
So
no
rooting
container
would
just
be
one
that
we
picked
right
now
running
a
container
with
the
privileged
flag
or
not
running.
It
would
be
another
practice,
but
there's
a
lot
of
different
ones.
Pods
should
not
mount
host
directories
as
volumes.
These
are
just
practices
and
we
have
them
if
we
don't
need
to
go
through
all
these
sections,
but
whoever
wants
to
read
it.
A
End
up
with
a
whole
set
of
practices
that
reference
whatever
this
is
called
like
ian
was
saying:
it's
not
exactly
like
a
user
story
right
now.
We
may
end
up
with
some
user
stories
in
it,
but
it's,
I
think,
what
we're
gonna
probably
have
more
than
that
is
a
write-up
around
the
the
general
principle
of
least
privilege,
and
then
we
can
have
a
whole
set
of
practices
that
come
out
of
that,
and
maybe
references
to
other
other
topics
around
isolation
and
protection
tell
we
could
have
those
just
referenced
to
other
documents.
C
Yeah,
I
I
mean
you
know
because
you've
seen
what
we've
been
presenting
over
the
course
of
the
weeks,
you'll
notice
that
we've
been
working
backwards,
pretty
much
from
the
beginning
right.
We
should
not
use
rooting.
Containers
therefore,
there's
a
reason
for
that,
and
we
should
figure
out
what
that
reason
is
and
so
on.
It's
kind
of
it's
a
strange
way
of
approaching
it,
but
the
problem
is
that
you,
you
kind
of,
I
would
say,
as
a
developer.
C
The
idea
of
using
the
least
quantity
of
privileges
is
is
ingrained
in
what
you
do
at
this
point
in
time.
You
know
you
should
sometimes
it's
a
little
difficult
to
articulate
the
reasons
why
you
feel
that's
a
good
thing,
so
you
know
because
it
covers
a
whole
bunch
of
stuff.
So
having
we
started
with
no
written
containers,
you
can
see
if
you
follow
the
timeline
up
from
this
meeting
that
we
had
a
couple
of
weeks
ago,
back
upwards,
then
you'll
find
well
it's
right.
C
Okay,
so
that's
one
point
of
least
privilege
what
other
least
privilege
practices
amount
to
again
least
privilege
here's
a
long
list.
Then
it's
like
okay.
Well
now
let
us
work
out
the
broad
statement
of
why
least,
privilege
is
sensible,
which
is
the
document
that
we,
or
or
at
least
the
skeleton
that
we
have
in
in
the
latest
round
that
we
were
discussing,
which
literally
was
half
an
hour
ago
at
this
point
to
to
get
to
why
these
least
privileged
rules
are
actually
being
helpful.
B
B
This
is
a
good
principle
for
working
on
kubernetes
and,
of
course,
much
of
this
document
too.
We
deal
into
well
the
specific
requirements
with
telco
with
networking,
etc.
There.
It's
a
tension
here
right
in
a
way
this.
This
part
shouldn't
be
worked
on
just
in
this
working
group.
These
kinds
of
this
idea
of
how
to
apply
the
principle
and
tips
for
doing
it
are
general
tips
for
kubernetes
right.
This
shouldn't
be
owned
by
our
working
group
to
an
extent,
but
then
the
telco
requirements
have
to
do
with
wealth.
Sometimes
we
do
need
privileges.
C
C
B
B
C
C
C
E
C
I
think
yes,
I'm
not
sure
it's
specific.
I
think
it's
more
a
general
question
of
how
we
could
benefit
from
their
learnings,
assuming
that
they've
gone
studied
this
rather
more
directly
because
it's
their
immediate
focus,
then
I'm
thinking
that
as
tal
says,
there's
probably
other
skills
out
there
and
more
to
the
point.
This
list
is
not
just
for
us
necessarily.
C
E
Recommend
is
you
put
together
a
short
talk,
maybe
five
to
ten
minutes
worth
put
it
on,
put
it
on
their
calendar.
The
way
you
put
it
on
their
calendar
is
by
opening
a
pull
request
against
the
against
the
security
technical
advisory
group
and
give
a
talk
and
then
ask
for
ask
for
help
and
see
see
what
they
say.
D
C
E
A
A
C
Yeah
yeah,
I
I
don't
want
to
limit
this
to
exclusively
runtime
checks.
I
think
if
we
can
get
static
analysis
as
well,
because
static
analysis
is
right,
if
you
spot
something
going
wrong
at
runtime,
it's
too
late,
because
whatever
you're
running
is
probably
not
going
to
deal
well
with
you
just
murdering
things
when
it
thinks
it's
about
to
get
started,
but
yeah.
E
So
they've
also
published
two
white
papers,
one
on
cloud
native
security
and
the
second
one
on
supply
chain
security,
and
there
is
a
security
controls
group
that,
let
me
see
if
I
can
find
the
the
spreadsheet
for
it,
but
in
short,
they
have
a
spreadsheet
that
they're
developing
it's
not
finalized.
Yet
that
goes
over.
E
The
variety
of
different
security
controls
they're
the
purpose
of
that
one
was
initially
so
they
can
give
to
groups
like
auditors
or
people
who
are
building
baselines
so
that
they
can
work
out
like
a
lot
of
a
lot
of
people
who
are
who
are
in
that
particular
chain
are
not
kubernetes
experts,
and
so
when
they
say
something
like
is
data
and
transit
encrypted?
It's
like.
Where
do
you
start
or
if
there's?
E
If,
if
there's
a
policy
saying
you
must
have
firewalls
and
then
you're
running
kubernetes
and
there's
no
firewall
on
the
edge
of
kubernetes,
then
why
is
kubernetes
sufficient?
What
controls
are
there?
That's
sufficient
that
could
help
replace
a
a
firewall
which
might
be
your
ingress
controllers
or
other
similar
types
of
things.
So
there's
so
there's
a
security
controls
group
that
is
relatively
new.
That
is
also
putting
things
together.
It'd
be
good
to
go
over
the
documentation.
E
C
Interest,
yeah
and-
and
I
think
you
have
to
be
careful
with
some
of
these
statements
because,
for
instance,
encryption
in
motion
as
an
example
is
widely
touted
as
an
answer
to
security
problems,
but
it
isn't
always
appropriate,
depending
on
what
you're
doing
if
what
your
main
job
is
is
to
move
traffic
as
fast
as
possible
with
the
least
amount
of
cpu
and
encryption
in
mo
and
the
traffic
is
moving
over
a
network
where
it's
mostly
not
encrypted
before
it
comes
to
you
then
encrypting
it.
You
know
between
your
components.
C
E
Absolutely
and
that's
that's
something
that
those
groups
are
very
aware
of,
but
it's
how
do
you
articulate
this
in
the
way
that
someone
who
is
not
in
that
particular
field,
and
we
actually
see
this
problem
in
the
zero
trust
space?
Quite
heavily?
It's
like
you,
have
one
camp
that
says.
Why
do
I
need
this?
We
have
sufficient
defenses
already
and
then
you
have
the
the
opposite
camp,
which
is
literally
wow.
I
can
put
dates.
C
Or
honestly
maintainability,
because
obviously
encrypting
everything
gets
you
less
and
less
insight
into
what's
happening
every
single
time
you
do
it,
but
yeah
there's
always
trade-offs
in
this.
Well,
actually,
that's
the
wrong
thing
to
say:
there
aren't
always
trade-offs
in
this,
the
ones
that
we
should
be
recommending
as
best
practices.
First,
the
ones
where
you're
actually
not
trading
anything.
E
Yeah
and
you
have
to
look
at
what's
called
the
residual
value
at
the
end
of
the
day,
which
is
what
is
the
thing
you're
defending?
What
is
the
cost
of
defending
it?
What's
the
value
when
you
put
those
two
of
them
together
and
like
what's
the
remaining
value
of
that
information
or
data
or
so
on,
and
so
it
very
much
people
think,
oh,
it's
just
a
technical
thing.
E
No,
it
very
much
ties
into
a
business
need
and
if
the
security
costs
that
are
you're
required
to
put
in
exceed
the
cost
of
doing
business,
then
in
some
scenarios
you
may
even
ask:
should
we
even
be
doing
this
in
the
first
place
so
or
you?
Maybe
you?
Maybe
you
go
back
and
try
to
work
out?
Why
is
this
thing
so
expensive
because
maybe
maybe
there's
a
better
way
to
do
it,
or
maybe
the
value
that
you
place
on
something
might
be
wrong,
so
I
mean
a
lot
of
different
places.
E
C
E
In
the
future-
and
maybe
this
is
something
we
could
do
through
here-
I
would
like
to
eventually
do
a
more
in-depth
talk
there
that
discusses
things
like
the
various
5g
protocols
and
the
security
deficiencies
that
exist
in
some
of
them
and
that
way
that
people
become
informed
and
they
can
then
become
part
of
that
perspective.
So,
for
example,
the
the
the
5g
user
tunneling
protocol
that
we
end
up
using
ends
up
the
whether
you're
logged
in
or
not
is
a
bit.
E
It
says
this
user
has
been
successfully
logged
in,
we
set
it
to
one,
and
then
they
gain
access
and
unencrypted.
So
so
the
protocols
themselves
need
to
have
something
else.
That's
that's
attached
to
them,
or
there
needs
to
be
some
out-of-band
thing
or
you
accept,
like
you
said,
you
could
always
accept
the
risk,
whether
that's
a
good
idea
or
not.
It's
probably
not
a
good
idea,
but
yeah.
E
In
short,
it
would
be
it'd,
be
good
to
raise
some
of
these
type
of
things
into
those
environments,
because
then
the
the
security
community
at
large
could
then
brainstorm
ideas
that
we
could
effectively
do
in
the
kubernetes
space.
That
would
move
kubernetes
from
being
just
a
hey.
We
can
run
this
at
higher
density
and
lower
cost,
presumably
lower
cost
to.
We
can
run
this
thing
with
all
those
benefits,
but
also
get
a
more
secure
stance
because
of
things
that
kubernetes
brings
to
the
table,
and
that
would
be
a
very
powerful
message
to
push
forward.
C
Okay,
so
I
think
we
could
probably
do
this
in
parallel
to
see
how
it
works
out.
We
can
get
this
right
up,
framed,
documented
committed
and
in
the
process
of
getting
it
frame
documented
committed.
We
could
be
writing
up
a
few
slides
for
the
10
minute
presentation
see
how
they
come
out
as
a
pair
rather
than
necessarily
saying
one,
then
the
other
would
that
work.
A
Yeah,
I
mean
definitely
write
it.
Like
would
do
a
presentation,
an
intro
like
what
are
we
doing?
What
are
where
are
we
trying
to
go
and
then
and
then
actually
give
an
example
of
here's,
one
that
we're
working
on
and
we've
published,
we'd
like
to
add
more
and
get
your
input
on
the
ones
that
we're
doing.
A
C
C
I
think
what
you're
asking
for
is
effectively
the
best
practices
that
this
suggests
yeah.
I
do
think
having
examples
is
a
good
thing
that
look
here
is
what
we
often
see
a
in
practice
here
b
is
what
you
could
be
doing,
and
here
is
how
to
get
to
b.
Yes,
absolutely,
but
that
does
sound
like
a
best
practice,
because
then
we're
making
a
recommendation
of
you
should
do
this,
but
yeah
I
mean
I
I
agree
with
you.
C
C
B
C
C
One
thing
I
think
that
came
up
in
passing
there,
something
frederick
mentioned
that
you
know
some
of
these
things
are
probably
worth
a
you
know,
could
benefit
from
a
technical
presentation
of,
however
long
we
always
kind
of
get
tied
up
with
the
idea
that
technical
presentations
have
to
go
into
kubecon
and
therefore
we
can't
get
into
kubecon.
So
we
never
get
to
make
our
technical
presentations.
C
Isn't
it
upsetting
in
a
world
of
being
online
and
working
from
home
all
the
time
and
being
wondering
whether
or
not
we're
ever
going
to
be
allowed
to
attend
conferences
again
anyway,
we
can
do
technical
presentations.
Whenever
we
want
right,
we
can
basically
have
someone
make
them
set
a
time
for
them
record
them.
I
I'm
sure
bill
and
his
team
will
happily
put
them
on
youtube
for
us
as
well.
There
is
always
that
option.
We
don't
have
to
wait
for
the
perfect
moment.