►
From YouTube: Istio Networking WG meeting 2019-06-06
Description
- Extension via Customization Proposal
- Better Default Networking
A
Hi
everybody
welcome
to
this
your
networking
community
meeting.
Today
we
have
four
items
on
the
agenda,
so
first
few
proposals
from
Louis
about
extension,
VR,
customization,
better
default
networking,
as
well
as
MPLS
on
by
default
and
also,
if
time
permits
we'll
discuss
a
bit
about
an
issue-
that's
been
going
on
for
more
than
a
month
and
is
related
to
service
entry
and
security.
A
C
D
D
Oh
so
this
proposal
just
takes
that
a
little
bit
further
and
extends
that
customization
to
Mauritania
envoy
ecosystem
right,
so
clusters,
listeners
filters
and
probably
filter
chains,
and
so
the
goal
of
this
mechanism
is
to
allow
people
to
both
add
new
resources
into
these
dream
emitted
by
XTS
and
also
to
customize
the
resources
that
are
emitted
by
pilot.
So
you
know,
if
there's
a
flag,
that
you
want,
that
on
a
cluster
in
some
build
of
envoy
that
is
not
yet
supported
in
the
sto.
Api
is
right.
D
D
D
So
the
general
proposal
is,
you
know.
Basically,
we
have
a
mechanism
for
patching
a
resource
which
is
defined
by
a
type,
is
an
operator
describing
a
patch
type
to
be
performed,
and
there
are
some
suggestions
in
here.
The
only
thing
I
need
to
go
through
an
update,
this
a
little
bit
there's
a
path
which
is
a
path
reference
into
the
type
to
be
mutated,
saying
where
the
mutation
should
occur
right.
D
So
the
dis
bachman
is
written.
You
know,
obviously
it
needs
quite
a
bit
of
updating,
but
the
raft
general
idea
right
is
to
be
able
to
have
an
api
that
we
can
consider
stable.
That's
of
course,
a
variety
of
structured
mutations
over
are
the
types
emitted
by
envoy
so
that
when
we
give
people
be
regular,
behavior
or
anybody
to
inject
customization,
and
obviously
this
needs
to
scale
right.
So
there
was
a
there's,
a
debate
about
how
generic
or
how
concrete
the
specification
of
these
mutations
should
be
defined
right.
D
We
could
use
you
know
a
scripting
language
or
a
pseudo
scripting
language
to
perform
the
mutations,
but
there's
a
debate
about
how
performance
that
would
be
a
lot
of
viable
scripting
engines.
We
could
use
to
embed
that
kind
of
customization.
You
know
if
you
look
in
kubernetes,
for
instance,
they
use
JSON
path
to
perform.
D
Then
we
need
to
understand
the
use
cases,
because
I
mean
need
to
know
what
to
put
into
those
specifications
until
that
need
to
be
filled
out
and
that
people
have
progestins
of
you
spaces.
Please
either
put
a
comment
in
this
section
and
I
will
reconcile
I'll,
make
sure
that
all
documents,
commissural
I,
have
to
go
back
through
and
scrapes
with
the
github
issues.
I
know,
there's
a
variety
of
stuff
documented.
There
I
think
we
know
had
a
few
of
those,
for
instance,
and
yet
this
last
piece
is
about
the.
How?
D
Because
some
of
the
things
that
we
emit
in
XDS,
we
emit
with
kind
of
mangled
names,
that
they
don't
the
names
that
are
used
in
these
two
resources,
don't
carry
through
in
a
stable
way
into
the
resources
that
are
admitted
to
XTS,
and
the
canonical
example
here
is
cluster
names
right.
Pluster
names
are
not
the
same
thing
as
service
entry
names
or
kuwaiti
service
names.
D
D
But
the
specification
is
not
done
yet.
There
are
still
pending
design
decisions.
I
just
want
to
make
sure
that
everybody
is
aware
of
this
and
understand
the
ramifications
of
it,
which
are
priests
example
right.
If
we're
going
to
commit
to
this
I
think
we
want
to
because
of
the
number
of
feature,
requests
that
we're
getting.
D
This
provides
a
lot
of
power,
a
lot
of
break
glass
power.
It
would
be
very
careful
with
it
and
it
has
to
be
able
to
perform
at
scale,
so
those
are
the
kind
of
fundamental
constraints
now
all
that
being
said,
the
one
other
thing
that
this
offers
as
an
opportunity
by
providing
more
capability
here
is
we're
also
making
it
easier
for
people
to
build
features
down
there
on
top
of
them
right
and
rely
on
this
feature
to
use
Pilate
as
the
means
to
distribute
those
features
in
reliable
ways.
D
You
know
I
had
a
conversation
with
Lehman
and
the
ISTE
of
security
team,
for
instance
about
you
know
as
a
hypothetical
could
they
use
this
feature
to
implement
sto
Arabic
activist
just
distribute
the
policies
which
are
actually
implemented
as
envoy
filters
and
actually
use
that
as
the
the
runtime
mechanism
for
pushing
that
feature
out,
as
opposed
to
having
proprietary
code
in
Pilate.
Do
that
right,
and
that
was
a
hypothetical
exercise,
but
I
want
to
make
sure
that
we
can
meet
the
needs
of
those
hypotheticals
right.
D
E
No,
this
one
comments
so
I
really
like
that
huge
support,
injecting
listener
filters
is
a
lack
of
the
a
company
to
do
that
right
now.
The
reason
why
helium
has
to
use
a
fork
of
pirate
right
now.
So,
if
you
add
that
capability,
we
don't
need
to
see
him
anymore,
so
that'sthat's
great,
there's
a
real
need
right
now:
okay,.
D
Yeah,
so
you
know,
obviously
we
need
to
a
bunch
of
validation
of
this,
but
you
know,
but
it's
hard
to
imagine
this
API
being
anything
other
than
alpha.
My
filter
is
already
out
so
we're
really
making
the
Envoy
filter
API
well,
capable
you
could
in
alpha
and
then
try
and
get
some
more
vendor
verification
and
use
gates,
verification,
so
Roman.
If
you
want
to
add
that
as
a
comment
into
the
appendix
about
use
cases
that
would
be
very
helpful.
I
can
go
follow
up
the
cilium
folks
about
that.
I
did.
F
So,
just
for
the
record
I'm!
Actually
that
you
know
actually
there
has
to
semantics
matches
that
we
were
discussing
about
for
cluster
land
routes.
In
addition
and
listeners
that
is
similar
to
the
there
is,
there
is
always
one
final
fallback,
which
is
a
red
X,
but
which
is
not
probably
going
to
be
used
at
all,
because
we
have
proper
semantic
matches
for
on
ports
or
on
pipe
and
contact
from
so
answer.
Yeah.
F
G
D
H
D
F
One
reason
month
event,
and
this
can
definitely
wait-
it's
not
immediately
yeah,
but
if
1.3
is
gonna
take
a
while,
then
yes-
and
we
might
have
to
push
some
limited
version
of
this,
because
there
were
a
series
of
requests
like
they
wanted
to
enable
some
things
next,
TP
connection
manager
for
the
x-forwarded-for
settings
and
or
the
idle
time
mode
settings
and
so
on
at
the
gateway
level.
And
what
who
I've
been
fending
them
off,
saying
that
wait
for
this
one.
F
So
if,
even
if
a
limited
version
of
this
Lantern,
those
people
would
actually
be
happy,
but
if
the
1.2
is
gonna
be
out,
103
is
gonna
be
out
in
July,
and
we
know
for
sure
that
is
gonna
happen.
Then
yeah,
then
this
we
can
have
the
whole
thing
land
in
July,
which
will
just
allow
people
to
add
less
noise
cluster
routes,
you
name
it
everything
it's
a
bootstrap
conf.
It
can
actually
be
added.
So
let.
D
Me
try
and
I
haven't
had
as
much
time
to
get
to
this
over
the
last
two
weeks
as
I
would
like,
but
I
will
try
and
push
this
the
getting
the
design
solidified
is
as
possible
and
sorry.
I
didn't
quite
catch.
The
name
of
who
was
doing
the
prototype.
I
was
interested
in
seeing
how
Jason
path
compares,
would
sell
and
I
can
have
the
cell
implementer
reach
out
and
we
could
kind
of
do
an
a/b
comparison
for
performance.
We
are
performance
sensitive
here.
I
C
D
D
Movies
is
already
now
resolved
in
the
1.2
build.
You
have
to
declare
the
container
port
right
to
allow
ingress
traffic
into
the
pod,
because
we
didn't
have
segmentation
in
the
filter
chain
in
Envoy
and
we
can
end
up
trampling
in
traffic
right,
and
so
that
was
a
a
security
workaround,
but
the
security
workaround
came
with
usability
cost,
so
you
Chen
and
Costin
and
Josh
have
been
driving
a
bunch
of
fixes
there.
D
So
now
we
have
to
filter
chains
right,
one
for
an
ingress
and
one
for
egress
I
mean
hard
partition,
the
traffic
between
those
two
flows,
and
so
we
don't
strictly
need
the
container
port
anymore,
and
so
there's
less
configuration
work
for
users
to
do
to
get
traffic
to
work.
So
that's
one.
The
other
thing
that
we
do
we
require
people
to
do
today
is
to
go
through
all
their
kubernetes
services
and
name
their
services,
name,
the
ports
and
their
services
with
the
protocols
of
the
service,
so
that
we
can
extract
telemetry
from
it.
D
It
could
be
if
it's
HTTP
or
protocol
that
we
understand
that's
a
lot
of
work
for
people
to
do
in
an
existing
cluster.
And
so
one
of
the
proposals
in
this
document
is
to
basically
enable
envoy
to
detect
a
small
set
of
well-known
protocols,
but
the
most
widely
used
one.
And
if
it
detects
the
protocol,
then
it
will
treat
it
as
that
protocol
and
we
would
extract
telemetry
and
enable
other
routing
and
other
features
without
requiring
you
to
go
through
and
declare
what
the
protocols
are.
But.
D
C
D
D
So
the
the
Tetrick
folks
I
think
Liz
Ann
was
saying
that
he
was
do
the
work
at
home
going
to
enable
this-
and
this
is
already
a
fairly
well
established
pattern,
an
envoy
right.
We
already
protocol
sniff
TLS
right
as
part
of
the
permissive
mode
handling,
so
this
is
just
doing
that
for
other
protocols,
so
we
can
do
more
stuff
out
of
the
box.
D
The
other
thing
that
the
proposal
does,
which
is
somewhat
leveraging
the
work
done
in
sidecar,
is
to
make
the
default
routing
through
sidecar,
effectively
be
the
Envoy
original
destination
mechanism
right.
So
if,
if
traffic
comes
into
Envoy,
what
will
sniff
the
protocol
will
do
what
we
normally
do
for
that
protocol,
particularly
on
the
telemetry
and
policy
side,
and
then,
if
we
don't
really
have
around
for
it,
we
will
send
it
to
original
destination
right,
which
is
something
that
we
did
as
they
kind
of
mesh
white
config
default.
D
But
we're
now
also
going
to
put
that
as
an
option
into
the
sidecar
API
all
right
and
what
we
really
want
to
do
is
kind
of
transition.
More
of
what
are
the
mesh
white
configuration
defaults
into
features
that
are
controllable
by
the
sidecar
API
and
the
other
networking
aid
guys
and
then
use
the
kind
of
a
default
sidecar
API
resource
in
the
route
config
namespace
as
the
default
behavior
right.
D
Yes,
so
the
general
goal
here
is
install
you'll
have
an
existing
cluster
with
existing
stuff.
You
install
this.
Do
right,
you
do
your
injection
and
then
without
doing
any
more
work.
Other
than
that
you
see
telemetry,
you
see
protocol
specific
telemetry
port
for
protocols.
We
understand
and
your
traffic
doesn't
break
right.
That's
the
kind
of
fundamental
usability
story.
We
want
to
have
the
very
least
in
Cabrini's
clusters.
D
I
D
The
one
reason
was
because
we
weren't
strongly
able
to
distinguish
between
inbound
and
outbound
traffic.
You
don't
worry
because
Manuel
the
listener
chains,
but
sending
to
original
destination
with
the
venous
security
risk
right,
because
traffic
would
come
in.
There
was
no
Rev
for
us.
He
would
fold
into
original
destination
and
go
back
out
mm-hmm
right.
So
now
you
have
impersonation,
that's
not
good!
Okay,.
A
D
A
C
D
D
J
D
K
C
K
K
The
traffic
to
convoy
level
right
now
we
pay
attention
to
the
pods
back
container
port.
Would
we
just
redirect
everything
all,
but
you
know
just
all
ports
to
Envoy
to
this
SP
to
be
able
to
clicked
so
that
you
just
to
leverage
the
traffic
detection
and
then
have
an
option
to?
If
you
add
container
ports,
then
we'll
clean,
we'll
just
have
that
finite
list.
D
K
K
L
C
F
F
The
ingress
ingress
in
the
potholes
I
mean
the
mesh
context
so
that
people
can
actually
assess
by
one
or
both
or
whichever
way
they
want
to,
but
the
becomes
a
single
point
of
control
and
from
wherever
you
control
might
want
figures
per
you
to
control
these
settings
rather
than
having
a
flag
for
each
and
every
side,
car
or
a
random
flag.
Inside
pilot.
This
right,
it's
easier
make
control.
You
also
wanna,
have
the
default
behavior
be
the
split.
D
F
F
D
Types
of
scenarios
with
the
test
right
I
mean
that's
what
I
am
thinking
right,
so
you
know
if,
if
there
was
one
thing
I
would
ask
people
to
test
with
it
would
be
to
test
that
feature
with
some
of
the
the
kind
of
more
esoteric
no
pods,
or
you
know
things
that
any
typical
communication
patterns
right.
You
know
server,
send
first
or
Kafka
or
what
we
seen
with
Cassandra
references.
D
D
Which
is
why,
when
we
tell
people
to
write
our
back
policies
right,
we
tell
them
to
mostly
write
the
policies
based
on
identity
principles
on
MPLS
touch
on
a
little
bit,
and
the
next
thing
you
know.
Ultimately,
you
know
people
can
misrepresent
their
protocols
right
in
their
current
config
right
to
bypass
that
as
well.
G
But,
and
in
the
first
case
it's
the
server,
you
know
the
actual
operator
needs
to
declare
the
port,
in
the
second
case,
the
client,
who
could
be
anyone.
It
could
be
someone,
you
know
just
calling
you
from
externally
and
do
some
sort
of
attack
where
they
don't
send
a
header
in
the
first
second
or
something
we
call
back
to
TCP
and
now
they've
now
kind
of
avoided,
all
the
HTTP
rules.
D
D
Yeah,
but
there
is
a
problem
with
being
able
to
allow
well,
no,
but
no
matter
what
happens
this.
The
server
side
is
gonna
receive
the
traffic
in
the
protocol
that
it
supports
right.
That's
what
Stryker
declares
right.
So
if
you
want
to
guarantee
that
the
traffic
coming
into
your
workload
is
HTTP
on
a
specific
port
mm-hmm.
G
D
To
find
the
list
or
port
in
the
sidecar
and
make
it
HCP
now,
there's
a
further
refinement
that
we
can
do
right,
which
is
you
know,
making
what
we
don't
have
today
and
it's
tricky
with
Bernays
is
when
I'm
creating
a
sidecar
for
a
workload.
But
if
you
declared
container
ports
for
a
workload
and
those
container
ports
declared
protocols,
then
we
could
criticize
car
automatically
for
that
that
enforced.
But
those
were
the
inbound
protocols
all
right.
So
there's
probably
a
proposal
that
we
should
write
up
to
do
that.
G
Yeah
the
thing
I
would
be
concerned
is
that,
right
now,
if
they
don't
declare
it
as
HTTP,
it's
going
to
always
be
TCP
and
they'll
realize
that
right
away
or
is
now
the
default
is
that
it
will
try
to
be
HTTP.
But
then,
when
some
attacker
sends
a
request
that
makes
it
fail.
The
protocol
sniffing
now
they're
in
TCP
mode
and
now
they've
just
avoided
everything
so
now
like
the
default
is
unsafe.
G
L
You're
talking
about
security
violation
due
to
communication,
won't
you
be
doing
our
back
like
Lewis
said,
and
if
you're
talking
about
client-side
traffic
behavior,
you
should
not
be
relying
on
your
client
side
being
following
all
your
restrictions.
Anyways
right
so
I'm
still
not
getting.
What
violation
is.
M
L
K
D
D
M
D
G
I
get
that
you
can
do
that.
The
thing
I'm
concerned
about
is
that,
right
now
you
have
to
do
it,
which
is
you
know,
it's
bad
UX
and
so
most
people
once
we
move
to
this
model.
They
no
longer
have
to
do
it,
they
probably
won't
do
it.
Most.
People
will
stick
to
their
defaults
and
now
everyone's
going
to
default
to
using
Auto,
which
leaves
them
at
risk
to
this
downgrade
attack.
G
O
O
D
G
A
G
D
Give
it
an
ingress
gateway.
You
declare
ports
yeah,
you
don't
do
anything
on
the
gate
base.
It's
only
for
the
site
cards.
Okay,
I
mean
you
could
declare
the
port
the
protocol
on
the
ingress
gateway
as
being,
although
if
you
want
right
right,
so
you
need
to
clear
it
in
the
Gateway
config
how
that
but
yeah.
I
Kyle
asked
a
question
on
contain
important
mm-hmm,
so
so
today,
if
I
have
house
check
my
container
port,
a
dedicated
port
and
if
my
other
traffic's
goes
to
maybe
a
different
port,
what
I
can
do
today
is
I,
can
specify
container
port
main
traffic
and
the
house
check
port
would
not
we
intercepted
by
it
still.
How
would
I
do
that
in
the
new
way
if
we
stick
on
your
owner
for
people
who
doesn't
want
sleeping
on
the
poor
number
so
that
they
can
still
declare
continued
ports,
you
only
captured
specific,
a
continuum
what
they
wanted.
I
D
I
D
Right
so
which
is
easier
for
users
right
to
capture
everything
and
allow
it
to
go
through
right,
which
is
you
know
if
we
capture
report
and
we
enable
permissive
mode
on
the
forum
TLS,
it
will
go
through
right
so
to
Randy's.
Health
checks
would
pass
through,
but
now
you'd
see
that
in
telemetry
or
to
tell
people
if
you
want
to
ports
to
not
be
captured
right
all
right.
So
it's
either
we
capture
everything
and
then
you
do
exclusion
or
we
capture
nothing
and
you
opt
in
which
is
a
more
usable
power.
Okay,.
I
I
D
D
I
I
I
D
P
L
Link
to
meet
your
requirement
looks
like
we
at
least
need
to
identify.
The
cases
we
know
will
break
one
of
them
being
if
you
have
empty
LS
turned
on
by
default
and
all
the
ports
get
captured
and
you
don't
want
some
ports
to
have
empty
LS
or
you
don't
want
some
ports
to
go
through
the
sidecar.
So
for
those
types
of
installation
we
need
to
say
this
is
the
config.
You
need
to
add
extra
configuration
where
these
are
the
ports.
You
have
opted
out
so.
I
D
So
what
I
guess
we
need
to
get
a
sense
of
how
many
people
have
strict
enabled
for
inbound
traffic
all
right.
So
the
primary
use
case
we
know
of
today
is
the
queue
blurred
health
check,
all
right,
being
unable
to
do
mutual
TLS,
and
so
we,
if
you
enable
strict
mode
on
that
port,
it
will
get
rejected.
That's
the
overriding
one
that
we
see
today,
but
metrics.
J
J
J
D
What
we
would
probably
recommend
to
people,
ideally
really.
What
we
would
like
to
be
able
to
do
is
for
the
cute
little
health
check
right.
We
want
to
be
able
to
special
case
something
because
it's
just
really
common
and
then
everything
else
would
go
in
to
capture
all
ports
with
permissive
em,
TLS
enabled
by
default
right
and
then
you
would
gradually
migrate
towards
trick
mode,
which
is
some
of
what
the
next
proposal
in
the
agenda
is
about
right.
But
cubelet
should
work
with
permissive
of
MPLS
right
because
it
will
fall
back
to
plain
text.
D
P
I
Was
just
going
to
say:
is
there
a
penalty
we're
paying
for
permission
materials?
Well,
we
know
it's
not
going
to
be
maturity
hours
because
the
way
I
look
at
the
permissive
configuration
envoy.
It's
like
a
double
configuration
if
I
have
3000
lines,
because
the
fact
that
I'm
doing
permissive
it's
become
6,000
lines
for
my
arm
weight
configuration.
J
A
M
I
C
D
D
A
D
F
Only
filter
change:
why
isn't
6,000
lines
then
I
think
the
listeners
alone
is
just
like
big
long
thing,
because,
especially
if
you
happen
to
have
empty
less
sniffing,
no,
it's
not
know
an
inbound
pod.
So
unless
you
happen
to
have
like
2030
inbound
codes,
you
should
only
have
this
filter
chain
sniffing
for
the
inbound
port
of
that
all
outside
odd
side,
car
or
service.
F
D
We
should,
but
it
doesn't
seem
like
you-
should
be-
that
material
anyway
yeah
semantics,
because
you
know
we
can
always
do.
That
was
those
kinds
of
optimizations
but
I
guess
you
should
make
a
note
in
the
agenda.
There's
a
question
about
why
things
have
so
much
config
overhead
in
that
situation.
Yeah.
L
I
D
Sir,
you
Chen
okay
yeah,
he
added
some
stuff
on
here,
but
yeah.
We
should
probably
get
some
documentation
out
into
it.
Maybe
write
up
an
email
to
discuss
and
ask
people
to
test
out
in
that
mode,
but
not
not
everything.
That's
in
this
document
right
is
in
1.2
right.
The
protocol
sniffing
is
not
anyone
not
I,
think
there's
still
some
work
to
do
on
the
IP
table
side
of
things
each
end
right,
we're
still
doing
some
more
testing.
F
Think
it's
not
the
client
that
has
several
protocols
like
my
sequel
and
so
on,
which
I
was
telling
listen.
We
need
a
primer
on
the
pipe
that
actually
like
receives
I
mean
if
it
doesn't
receive
any
data,
then
it
actually
like
times
out
and
alls
back
to
the
the
empty
last
question
or
the
non-empty
LS
question.
It
has
to
pick
one
or
the
other
right,
but
I
think
that's.
F
It
apparently
right
it
will
kick.
My
battle.
Protocols
are
breaking
with
the
snipping
because
of
the
like
client
first
right,
because
the
server
flows,
yeah
he's
also
of
most
things
and
but
sniffing
for
HTTP,
is
not
that
hard
because
leg
night.
Well,
you
always
in
a
time
or
anyway.
If
there's
nothing
that
comes
out
on
the
wire,
then
you
fall
back
and
then
just
feel
does
a
plain,
TCP
connection
right
right.
F
L
D
D
D
Different
but
there's
there's
a
lot
of
code.
That's
been
written
that
has
been
pretty
well
tested
to
do
this
over
a
very
long
period
of
time,
right,
okay,
pretty
buggy.
Could
the
I
was
knows
that
the
truth
is
you
won't
get
everything
right?
You're
gonna
make
a
decision
about
how
quickly
you
want
to
sniff
the
versus
how
perfect
you
want
to
sniff.
Yes,
you're
gonna
capture
a
lot
right.
We
just
look
like
that's
the
that's
where.
L
D
Now
pretend
first
protocols
like
my
sequel
right,
where
climb
connects
right
if
it's
empty
LS,
the
client
is
sending
packets
first,
so
we
already
know
what
we're
doing
right.
So,
there's
no
problem
sniffing
MTF
on
that
situation.
It's
when
the
protocol.
The
protocol
is
plain
texts
and
then
the
underlying
there's
seven
protocol,
whatever
it
is,
then
you'll
have
to
timeout
and
then
the
case
of
my
sequel,
the
timeout
will
fall
back
into
TCP,
which
is
what
we're
doing
anyway.
For
my
sequel,
those
are
the
protocols
we.
F
D
D
D
D
I
J
I
I
I
P
L
J
G
D
D
I
D
No,
so
what
we're
saying
is,
if
you're
already
using
a
1.1
Envoy
right,
the
container
port
restriction
will
be
lifted.
We
would
have
the
flag
we
could
detect
and
upgrade.
If
you
wanted
to
use
container
quarters,
opt
in
or
out
that
right,
mm-hmm
all
right.
We
have
to
be
able
to
tell
if
it's
an
upgrade.
D
I
D
D
I
D
D
D
L
D
I
I
C
I
K
D
P
I
I
A
D
A
A
Yeah,
so
people,
maybe
I,
should
look
at
these
two
issues
and
comment
directly
on
the
issue
and
we
can
cover
them
next
time.
Also
I
want
to
bring
the
Ernest
the
last
item
in
the
agenda,
which
is
related
to
service
entry
and
in
fact,
John
Howard
will
write
the
document
with
describing
the
context
and
the
proposal
how
we
can
fix
this
so
John.
Maybe
next
week
you
can
present
that
document,
but
people's.