►
From YouTube: Ambient Mesh WG meeting 2023 08 16
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
everybody
Welcome
to
the
Wednesday
August
16th,
it's
still
MBM
leafland
contributors
meeting,
so
first
up
on
the
agenda
is
a
short
one
in
our
ambient
beta
dog.
We,
let's
see,
if
I'm
in
the
right
place
here,
cni
compatibility.
Okay,
that
was
the
wrong
place,
see
another
compatibility.
A
We
need
someone
to
read
the
work
stream
for
compatibility
was
at
least
one
major,
cni,
I
think
teeth.
You
comment
here.
We
may
need
a
new
owner
and
then
a
few
folks
were
pinged.
But
I
didn't
have
I,
didn't
see
any
confirmations
here.
So
can
we
get
someone
to
leak?
This.
B
A
All
right,
then,
that's
that
so
next
up
is
Keith
and
Steven
on
hairpin.
D
Yeah
I'll
take
that
so
you
know
not
to
kind
of
rehash
the
mega
thread
from
ambient
Dev
last
week.
But
a
lot
of
a
lot
of
that
conversation
ended
up.
Circling
around
capture
and
thankfully
we've
split
we've
been
able
to
split
that
out
and
been
like.
It's
got
a
agenda
item
here
to
talk
about
the
capturing
mechanisms,
but
I
I
do
want
to
make
sure
we
don't
lose
sight
of
the
overall
hair
pinning
questions.
D
Steven's
got
a
PR
out
to
basically
block
all
I
think
block
all
inbound
plain
text
for
Z
tunnel
until
we
have
a
decision
because
we
don't
want
to
right.
What
we
have
right
now
is
just
is
even
worse
than
I
think
anything
that
we
could
any
of
the
potential
ideas
in
the
table.
D
So
I
think
you
know
some
John
costing
somebody
correct
me
if
I'm
wrong,
but
I
think
where
we
ended
the
discussion
and
the
thread
was
that
hairpinning,
essentially
that
the
question
comes
down
to
do
we
want
to?
D
Is
it
okay
to
potentially
brick
Network
policy
versus
plain
Tech,
being
able
to
do
plain
text,
L7
policy,
I'm
kind
of
firmly
on
the
plain
textile
7
policy
side?
D
So
we
need
to
hear
a
pen
in
order
to
do
that,
wanted
to
see
if
others,
where
the
community
stands
on
this,
so
that
we
can
get
some
decisions
made
and
tracked
in
architecture
documents.
So
we
can
continue
to
iterate
on
this.
D
Okay,
yeah,
so
what
I'm
for?
Is
users
being
able
to
write
something
policy
for
a
for
workload
that
has
a
waypoint
and
have
that
policy
be
applied
to
plain
text?
Traffic.
E
Plain
text:
HTTP
I
completely
agree
with
you,
but
the
question
is:
do
we
want
to
to
to
apply,
try
to
apply
L7,
plus
HTTP,
L7
policy
to
postgres
nuts
and
all
the
TCP
traffic,
which
is
play
index?
That's
the
main
debate
really
in
this
in
this
proposal,
because
obviously
my
example
is
postgres
nuts
and
you
have
a
waypoint
to
name
space
in
the
Waypoint.
Do
we
want
to
send
all
the
traffic
to
Waypoint
and
back
to
apply
L7
HTTP
policies
for
the
nuts
and
possible
strategy?
D
E
So
that's
entirely
possible
I
mean
some
people
may
use
a
service
account,
for
you
know,
have
only
PCP
services
and
only
HTTP
services.
But
question
is
what
happens
if
they
have
a
namespace
waypoint,
which
is
obviously
cheaper
and
easier
to
maintain
and
what
will
document
and
having
all
examples,
and
they
happen
to
have
postgres
knots
and
other
things.
B
E
C
E
B
D
Yeah
on
the
doc's
point,
you
know
Austin,
just
I
think
you
know
if
you
feel
like
you're
you're,
not
you're,
pointing
not
being
communicate.
Why
we're
not
hearing
you
I,
mean
I.
Think
anybody
here
be
happy
to
review
a
PR
with
the
kind
of
document
with
the
kind
of
docs
that
you
feel
that
we
need
to
close
the
gap.
I
I
personally
be
happy
to
take
a
look
at
something
like
that.
Okay
sounds
good
awesome.
Thank
you.
F
Keith
I'm,
looking
at
the
thread
in
ambient
Dev,
and
it
looks
like
it's
got,
642
comments
in
it,
I'm
not
going
to
be
able
to
get
through
it
during
this
meeting
for
context,
are
we
talking
about
whether
we
should
hairpin
ever
like
in
general,
whether
that
ought
to
be
a
functionality
of
ambient?
Or
are
we
talking
about
this
specific
scenario?
Routing
plain
text,
traffic
via
the
Waypoint.
D
The
the
the
general
question
was:
should
we
hairpin
ever
that
was
up
for
debate
at
one
point
really.
G
So
that's
kind
of
that's
kind
of
from
my
perspective,
like
we
already
support
hairpinning
for
mesh
traffic,
whether
it's
from
a
Gateway
or
whatever,
that's
fine.
That
works.
That's
not
really
a
question.
The
question
is:
if
we
don't
know
the
source,
we
have
to
add
a
special
flow
for
that.
Do
we
want
to
that's
where
it
gets
tricky.
G
E
No
I
meant
there
is
only
the
case
of
cream
takes.
There
is
no
other
case
there
is
traffic
will
go
to
foreign.
D
D
D
Somewhat
I
started
an
architecture
directory
in
the
SEO
istio
repo,
and
it
explains
the
flow
kind
of
at
a
high
level
in
the
in
the
context
of
peer
authentication.
That's
the
that's
the
context
of
what
the
what
the
doc
is
written
in
costume.
To
answer
your
question:
yes,
if
the,
if
the
client
supports
H
bone
I
mean
even
if
the
client
supports
H
bone,
somebody
correct
me
if
I'm
wrong.
It
still
goes
to
Z
tunnel
first,
because
that's
what
the
IP
table's
redirection.
Yes,.
D
So
everything
everything
go
through
G
tunnel.
The
question
is,
you
know,
for
plain
text:
should
It
Go
Button
within
Waypoint,
but
plaintiff
permission,
yeah
plain
text
and
permissive
peer
authentication
context
should
It
Go?
No,
the
server
is
z
tunnel
because
there
is
no.
If
it's
unauthenticated,
there
is
no
client
G
tunnel.
G
Correct
yeah,
it
just
gets
redirected
wholesale.
We
capture
everything
we
funnel
it
through
the
Z
tunnel.
The
Z
tunnel
can
handle
things
where
the
source
is
unknown,
but
if
there's
a
waypoint
configured,
it's
going
to
try
to
send
everything
to
the
Waypoint
for
policy
enforcement
and
if
we
don't
know
the
source
that
creates
problems
for
that
hairpin.
If
we
do
know
the
source,
it's
an
easy
air
pin.
We
already
support
that.
It's
just
yeah,
if
it's
permissive
and
we're
getting
stuff
that
we
don't
know
the
origin
of
it
gets
a
little
trickier.
D
G
We
could
just
do
something.
You
know
simplistic
where
we
say
look.
I
will
take
everything,
including
plain
text
through
Z
tunnel.
But
as
soon
as
you
configure
a
waypoint,
we
start
rejecting
plain
text
because
we
can't
enforce
the
identity,
which
is
a
little
rough
and
doesn't
give
you
the
layer,
7
enforcement
for
unknown
source,
plain
text.
But
it's
simple
to
do
sort
of
I.
Don't
know
it
doesn't
require
The
Hairpin.
D
G
I
I
also
feel
like
again
this.
Maybe
this
is
rehashing,
but
we
could
do
a
step
thing
here
right,
like
I,
think
there's
a
PR,
you
said:
there's
a
PR
already
out
that
denies
everything
for
plain
text
like
we
could
do
something
where
we
for
now
do
that
or
do
something
similar
where
we
deny
only
if
there's
a
waypoint
configured
and
then
punt
on,
like
the
more
advanced
solution.
If
we
want
to,
if
we,
if
we
want
to
say
that
layer,
seven
for
unknown
source
traffic,
we
have
to
do
it
now.
G
We
want
to
support
it
right
now,
then
it
gets
trickier.
But
if
we
want
to
say
like
let's
pick
something
safe
for
now
and
then
punt
on
how
we
do
that
until
later,
because
that
may
be
something
that
not
everybody
cares
about.
In
all
cases,
I
don't
know
that's
something
to
discuss,
but
it
is
just
yeah.
It's
the
layers,
heaven
for
unknown
source
traffic,
permissive.
E
I
I
think
I'm
completely
confused
now.
So,
if
you
have
a
put
that
is
annotated
to
not
use
ambient,
it
will
not
go
directly.
A
E
G
E
Okay,
let's,
let's
say
I'm
I'm
slow
today,
so
you
have.
The
source
is
not
easy
to
understand.
It's
not
ambient
understanding,
it's
a
social
ambient.
Will
it
ever
go
there?
Will
it
ever
go
directly
to
the
Z
tunnel
or
to
the
destination
as
Eternal,
or
it
will
always
be
related
to
the
Waypoint?
They
do
not
have
a
problem.
G
E
E
G
A
G
B
G
Don't
agree
right,
but
we
have
to
add
a
special
flow
to
support
that
is
testing.
Yes,
okay,
if
we
want
to
do
that,
that's
fine,
we,
but
we
are
only
adding
that
special
flow
in
order
to
support
layer,
7
policy
for
permissive,
unknown
source
traffic.
It's
a
it's
adding
an
ALT
flow
for
a
corner
case
is
the
thing
and
that's
fine.
If
we
want
to
do
it,
but
it
is
non-trivial.
B
Okay,
so
if
you
get
an
h-grown
request
that
should
have
gone
through
waycoin
and
it
wasn't-
we
deny
it-
we
could
allow
it
if
we
wanted
to,
but
because
anyone
that
can
do
h-man
should
also
be
smart
enough
to
know
to
go
through
the
Waypoint.
So
well,.
G
G
G
B
A
B
It
because
currently,
all
the
beta
things
that
aren't
in
the
beta
are
about
additional
features,
and
this
is
not
an
additional
feature.
It's
a
behavioral
change
and
the
point
of
shipping
a
beta
is
to
say
that
the
behavior
is
relatively
static,
so
it
doesn't
seem
like
it
makes
sense
to
ship
the
beta
and
then
I.
D
Yeah
I
think
we
need
to
like
have
a
have
an
active
stance
here.
If
we
have
concerns
about
about
security
of
the
approach,
whatever
I
mean,
that's
part
of
the
I,
don't
think
we
should
put
insecure
products,
but
you
know
we
we
can't
and
think
of
every
single
edge
case.
D
We've
got
a
couple
of
proposals
that
was
that
was
the
original
discussion
I
think
two
weeks
ago,
with
Steven's
DOC
for
like
five
different
options
for
how
to
handle
hairpinning
correctly,
it
seemed
like
we
were
sort
of
circling
around
the
TLs,
the
the
one-way,
vanilla,
TLS
approach,
and
that's
why
I
documented
in
the
pure
authentication
doc.
D
But
you
know
we
can
always
say
if
you
have,
if
you're
security
conscious
you
strict
and
that
solved
this
entire
problem,
I
feel
like
I'm,
more
I'm,
most
aligned
with
John,
where
I'd
prioritize
getting
you
know
for
a
Beta
release,
getting
the
features
that
you
know.
We
already
know
exist
out
there,
and
then
we
provide
knobs
for
people
with
different
who
are
who
are
willing
to
accept
different
trade-offs,
to
be
able
to
to
make
those
trailers
for
their
organization
and
pre-authentication
is
that
knob.
E
E
Okay
is
the
design,
changes
and
I'll,
read
it,
but
yeah:
okay,
I'll
review
it.
D
Okay,
do
we
feel
like
we
have
you
know
so
costumes
going
to
reach
on
stock
I
I
do
want
to
make
sure
we
continue
to
move
forward
on
this,
because
a
lot
of
our
implementation
needs
are
going
to
be
contingent
on
having
our
apis
somewhat
decided
on.
So
for
our
the
next
time.
Talk
about
this
I
think
it
would
be
better.
I
think
we'll
be
best
served
by
talking
about
the
specifics
of
Steven's
Regional
document,
with
the
different
options
for
how
to
Hairpin.
D
Today
it
sounds
like
we
agree.
We
want
to
Hairpin
now
we're
discussing
how
best
to
accomplish
that,
and
yes
costume
is
going
to
be
writing
a
doc
with
the
the
downsides
just
so
we
can
make
sure
users
are
educated
about
the
decisions
they're
making
and
commit
the
trade-offs
that
are
most
appropriate
for
them
cool
anything
else
on
this
topic
before
we
move
on.
D
All
right,
the
next
item
on
the
agenda
comes
from
me.
So,
as
part
of
implementing
you
know
Waypoint
what
is
the
name
of
the
the
dock?
It's
like
Waypoint
targeted
policy,
we're
at
Target
ref
to
our
policy
resources
in
the
process
of
implementing
that
my
team
and
I
discovered
that
to
to
do
policy
attachment
correctly
in
Gateway
API,
you
kind
of
need
status.
D
You
kind
of
need
to
report
that
hey
the
thing
that
you
put
in
Target
ref
is
valid
and
it
exists
and
that
we've
received
configuration
for
this
and
istio
istio
resources.
Don't
currently
have
status
today
there
there
is
a
possibility
of
doing
it
for
config
distribution,
but
it's
behind
a
feature
flag
and
I'm,
not
sure
it's
very
well
used
the
questions
I
have
are
one:
are
we
aligned
with
doing
with
adding
status
for
the
ticket
policy
attachment
and
then
two?
If
we
do
that?
D
What
is
the
best
flow
to
do?
In
order
to
take
care
of
that
I
know,
we
have
some
status
for
gateways.
We
use
Gateway
API
conditions,
but
want
to
see
if
we
have
any
concerns
about
how
to
encode
that
initial
API
is
and
stuff
like
that.
John
go
ahead.
B
A
B
B
D
B
I
I
think
I'm
convinced
that
it's
worth
it
eventually
I,
just
not
in
the
short
term.
Okay,
a.
D
Low
priority:
okay,
fair
enough
I,
have
rebuff
for
two
of
those
one.
The
reason
why
we
need
status
for
Target
red
from
that
workload
selector
is
that
workload
selectors
a
set
operation
or
they
just
need
to
be.
There
may
be
no
matching
subsets
at
any
given
time
and
you
can
easily
add
a
something
to
that
to
that
set
and
it
works.
D
Target
refs
identifies
a
specific
resource
that
may
or
may
not
exist,
and
you
expect
configuration
to
be
written
based
on
that
resource
and
so
for
that
reason,
I
feel
like
status
is
warranted
to
indicate
whether
or
not
the
particular
resource
that
you
that
you
target
the
status
is
valid
exists
Etc,
because
the
API
differences.
B
Yeah
I
mean
I
get
your
point
like
it's
slightly
more
compelling,
but
it's
also
like
if
you
select
zero
pods,
either
way
it
doesn't
matter
why
you
selected
zero
pods.
It
fills
the
label
selector
or
reference.
Your
thing's
still
broken
right.
D
In
from
a
user
experience
perspective,
the
result
is
the
same,
but
from
a
declarative,
API
perspective
I
feel
like
saying:
Hey
I
want
this
policy
to
apply
to
this
subset
of
things.
There's
there
there's
no
such
thing
as
an
incorrect
selector
unless
it
has
invalid
characters
or
whatever,
in
which
case
kubernetes
will
scream
at
you.
There
is
a
such
thing
as
an
invalid
Park,
The
Ref
either
you
you
know
we
can
deal
with
the
and
develop
group
with
a
not
adding
web
hook.
D
D
F
F
That
virtual
service
will
obviously
not
take
effect,
and
we
don't
provide
anything
today
by
default
in
the
API
that
gives
feedback
on
this.
We
did
design
analyzers
to
meet
that
use
case
with
the
intention
of
putting
the
result
of
analyzers
into
the
status
field,
so
that
eventually,
you
don't
have
to
proactively
run
a
command
line
utility
to
check
your
config
you'll,
just
see
in
kubernetes.
My
config
has
a
problem.
F
We
have
had
several
initiatives
to
try.
That's
an
alpha
level
feature
it's
slightly
different
from
config
distribution
status.
We've
had
some
efforts
to
move
it
to
Beta
that
have
fallen
through
mostly
just
due
to
lack
of
prioritization.
F
It
does
seem
to
me
that
ambient
presents
a
whole
new
slew
of
ways
to
misconfigure
your
mesh,
particularly
any
kind
of
L7
policy
on
a
service
that
does
not
have
a
waypoint.
We
need
a
way
to
proactively
notify
our
users
that
that
policy
is
not
going
to
be
taking
effect,
and
so
I
I
do
think
that
there's
a
bit
more
urgency
today
than
there
was.
But
this
is
not
a
new
class
of
problem.
It
has
always
existed
in
istio
and
we
do
have
designs
along
the
lines
of
how
to
resolve
that
class
of
problem.
D
Yes,
Patrick
on
the
right
window.
That
makes
sense:
okay,
John.
D
Gotcha,
so
an
analyzer
buys
us
a
like
an
interrupt
driven
type
of
flow
where
you
just
coming
into
your
cctl
analyze,
and
if,
in
the
future
we
want
to
write
status,
you
will
have
that
already
written.
B
Yeah
there's
already
a
flag
of
mine,
if
you
just
add
an
analyzer
and
then
you
turn
on
the
feature
flag
for
establish
writing.
It
will
write
the
analyzer
results
to
the
status
field
of
the
resource.
Gotcha.
D
Okay,
got
it
got
it
got
it.
Okay,
I
think
I.
Think
that's
fair,
that's
a
good
place
to
start.
Do
we
have
from
a
from
a
Gateway
API
perspective,
putting
that
hat
on
it?
You
probably
want
to
be
compliant
with
policy
attachments,
and
that's
getting
a
lot
more
attention
these
days
about
how
to
do
that
correctly
and
then
at
some
point
we'll
have
conformance
test
I'll
be
written
for
it,
maybe
possibly
if,
anyway,
the
goal
is
that
we
want
to
be
compliant.
Are
we
good
for
like?
D
B
Do
they
have
the
spec
for
how
a
policy
should
write
status?
I
didn't
think
there
was
one.
D
Not
yet
where
is
it?
There
is
a
line
in
terms
of
status?
It
should
be
reasonably
easy
for
a
user
to
understand
that
everything
is
working.
Basically,
as
long
as
the
targeted
object
exists
and
modifications
are
valid,
The
Meta
resource
is
valid,
and
this
should
be
straightforward
to
communicating
one
or
two
conditions.
You
know
at
the
time
of
writing.
This
is
not
completed,
so
there's
nothing
specific
there,
but
the
Gap
reads
as
if
status
is
expected.
C
B
Following
a
spec
that
doesn't
yet
exist
so
like
in
theory,
yes,
but
you
would
have
to
evaluate
I,
think
based
on
the
results,
and
maybe
we
want
to
sway
the
the
spec
itself
to
meet
a
reasonable
result.
D
I
mean
if
only
we
had
a
couple
of
mesh
leads
and
Gateway
API
to
influence
the
stack,
a
certain
way,
just
a
thought,
but
yeah
I
I'm
with
you
that
that
makes
sense.
So
foreign
atoms
here
no
do
not
need
status
for
ambient.
Today.
It's
not
a
beta
blocker
I
think
that
an
analyzer
is
probably
P1.
D
But
going
from
our
from
our
doc
on
driving
Vietnamese
data
that
sound
does
that
kind
of
work
for
everybody.
B
D
All
right,
I
will
capture
that
decision.
Thanks
all
for
the
discussion
and
I
think
it
would
be
actually
a
really
cool
to
see
a
either
existing
docs
or
a
new
doc
on
the
current
status
of
status
and
istio,
and
but
it's
as
we
tap
in
the
past
I
recall
a
couple
of
issues
with
the
fan:
art
problem
with
status
in
the
aster
repo,
but
I
don't
remember
offhand
where
they
are
so
something
like
that
would
be
really
cool
for
posterity.
If
somebody
wants
to
pick
the
work
up.
D
Okay,
moving
on
Ben
capture
versus
peer,
often
versus
API,
granularity,
yeah.
G
This
is
mostly
just
to
round
out
this
issue,
43700,
which
was
originally
raised
to
talk
about
whether
we
should
customize
or
let
support
people
allowing
people
to
customize
redirection
or
capture
based
on
like
Port
exclusions
or
whatever
else.
G
The
consensus
seems
to
be
especially
based
on
what
we've
talked
about
previously
with
the
hair
bending
stuff
and
the
unknown
source
like
we,
we
don't
want
to
support
capture
customization,
but
we
do
want
to
say,
assuming
we
capture
everything,
here's
what
you
can
do
based
on
whether
we
know
something
about
the
source,
Identity
or
not,
and
what
your
peer
authentication
is.
So
we're
not
customizing
capture,
but
we
will
support
customizing
what
we
do
it.
G
We
capture
based
on
what
kind
of
identity
assertions
we
could
make
about
the
source
and
the
test,
or
mostly
just
the
source,
I
guess
so
that's
fine
I,
think
that's
that's.
What
we
seem
to
be
arriving
at
is
that
we
don't
want
to
offer
capture
customization
and
we
do
want
to
off.
We
do
want
to
let
you
know,
offer
Source
identity,
Behavior
customizations.
G
If
we
do
that,
that
creates
two
things
we
need
to
deal
with.
One
is
if
we
still
support
peer
authentication,
sorry,
okay,
that
creates
two
problems.
If
we
support
that
and
we
support
permissive,
which
means
we
don't
know
the
source
identity
at
a
certain
point,
there
are
degraded
metrics
and
policy
guarantees
we
can
offer
for
that
kind
of
traffic.
So
we
need
to
figure
out
how
we
can
communicate
that
effectively
to
people.
G
You
know
if
we
don't
know
the
source
we
can.
You
know
there
are
certain
things
we
can't
attest.
There's
certain
metrics.
We
can't
guarantee.
There
are
certain
policies
we
may
not
be
able
to
enforce.
How
do
we
cleanly
communicate
that
two?
G
Have
we
thought
about?
Maybe
minimizing
the
multi-layered
footgun
of
permissive,
because
currently
right
now
you
can
say
peer
off,
allow
or
deny
plain
text
unknown
source
for
the
whole
pot,
and
you
can
also
do
allow
or
deny
Port
level
mtls
within
that.
So
you
can
do
a
thing
where
you
say:
allow
everything
but
enforce
mtls,
or
you
can
invert
that
it's
like
a
multi-layered
thing
where
you
have
two
levels
where
you
control
it.
That
feels
maybe
like
we
don't
need
to
do
both
in
ambient.
G
We
don't
have
to
do
both
because
we
don't
have
to
support
detail
or
that
we
don't
support
sidecar
back
compat.
What
it
might
would
it
make
sense
to
maybe
say,
look
for
ambient
peer
off.
You
have
to
configure
permissive
only
at
the
Port
level.
You
want
a
certain
port
to
not
be
strict,
then
you
allow
list
that
Port
explicitly
or
maybe
a
range
or
whatever,
but
we
don't
support
like
a
blanket
yep
open
the
whole
pot
up
for
permissive
right.
G
E
You
have
for
my
own
sanity
and
for
the
users
who
have
used
this
to
you
at
least,
let's
add
another
enough
value
to
indicate
whatever
you
want
and
not
call
it
permissive,
because
permissive
had
some
semantics,
I,
don't
know
if
they
are
documented
or
not,
but
it's
clearly
not
what
we
are
doing
here.
It
sounds
like
permissive,
but
it's
not
exactly
the
same
in
history,
we're
no
longer
using
permissions.
E
G
E
E
It
means
that
that
you
can,
you
know,
stick
this
clear.
What
it
means
only
accept
traffic
from,
but
permissive
means
what.
B
B
To
answer
quad's
question:
how
do
we
detect
app
m2s
versus
Eastview
mtls?
It's
based
on
the
special
alpn
we
use.
H
B
E
H
B
I,
don't
know
why,
like
the
definition
says,
permissive
can
be
either
plain
text
or
tunneled.
It
doesn't
say
anything
about
snift.
It
doesn't
say
like
I
agree
that
the
definitions
a
bit
confusing,
because
what
is
plain
text?
What
is
a
tunnel
like
it's
all
of
it
vague,
but
the
intent
is
very
clear.
Like
there's
two
types
of
traffic:
it's
either
East
Joe
transport
or
it's
not
and
permissive
means,
except
both
strict
means,
except
only
Easter,
secure
transport.
H
E
I
think
I'm
arguing
that
permissive
word
was
defined
in
an
RFC
and
had
specific
behaviors.
Now
we
are
saying
that
whatever
was
defined
in
issue
and
designing,
is
to
ask
permissive,
which
was
the
LPN
negotiation
whatever
whatever
now
we
want
to
take
over
the
world
and
just
Define
it
to
mean
something
else.
Why
not
introduce
a
new
word,
which
means
you
know
plain
text
aloud
or
whatever
you
want
to
call
it,
but
not
take
over
the
work.
That
meant
something
else
and
slightly
twist
it
to
mean
something
that
we
want
today.
E
Is
that
one
interpretation
where
words
change,
meaning
I
mean
Behavior
change,
meaning
the
other
one
is.
If
we
want
to
have
I
mean.
Is
that
what
permissive
meant
to
do
mtls
and
check
with
ILP
and
Eastern
whatever?
And
if
you
have
permissions,
it
means
that
that
Port
will
do
the
LPN
negotiations
or
someone.
G
That's
something
I
think
we
could
talk
about
and
I'll
take
a
note
to
consider
that
maybe
in
a
separate
issue,
but
I
would
like
to
talk
about
whether
we
keep
the
name
permissive
or
not.
Do
we
want
to
allow
an
ambient
that,
in
that
layering
of
blanket
open
the
whole
pod
and
also
Port
level
config
or
do
we
just
want
to
say
look,
do
you
want
to
blow
a
hole
in
your
mesh?
G
You
have
to
explicitly
do
it
Port
by
port
or
maybe
Port
range
like
we
don't
offer
an
all
on
all
off
for
the
Pod
anymore,
and
that
also
has
to
always
layer
with
the
port
level
stuff,
which
we
also
support
currently
appear
off.
Do
we
need
to
support
both
of
those
layers
of
foot
gun,
or
can
we
just
pick
one.
B
Yeah
I
I
think
we
should
support
what
we
support
today,
because
one
it
actually
makes
it
more
like
what
our
end
goal
is.
Is
the
more
strict
usage
the
better
right,
and
if
you
don't
have
the
multiple
layers,
then
the
only
thing
you
can
do
is
either
turn
it
all
on
or
opt
in
specific
ports.
There's
no
way
to
say
I
want
to
do
everything,
but
port
five
or
whatever
and
two
is
consistency
with
sidecar-
is
not
a
requirement,
but
it's
nice
to
have
a
tattoo
when
I,
don't
think
it
really
adds.
B
Much
like
you
actually
have
more
foot
guns
to
say
that
we
just
somehow
ignore
your
config
in
some
cases
than
just
accepting
it.
I
haven't
heard
people
confused
about
this
concept
of
having
the
blanket
and
the
purport
override
it's
a
fairly
common
pattern.
So
to
me,
there's
really
no
reason
to
change
this.
G
Do
you
see
people
using
both
frequently
or
like
I,
typically
see
people
just
slapping
the
permissive
and
not
doing
Port
level
granularity
and
like
if
we
pick
just
Port,
it
would
at
least
discourage
that
right.
If
you
want
to
open,
if
you
want
to
blow
a
hole
you
have
to
like
explicitly,
allow
us
the
ports,
we
don't
make
it
easy
for
you
to
just
sort
of
blanket.
Do
it.
Do
you
see
people
using
both
a
lot.
G
Yeah,
that's
that's
kind
of
my
point.
Right
I!
Think
it's
not
commonly
used
because
it's
easier
to
just
do
it
for
the
whole
pod,
but
we
kind
of
want
to
discourage
permissive
in
general,
so
doing
it
for
the
whole
pod
is
maybe
a
little
too
easy
and
we
just
do
the
port.
That's
kind
of
the
point
I'm
making
but
I
understand
what
you're
saying
it
is.
We
don't
have
to
support
what
sidecar
does,
but
it
is
going
to
be
easy
for
people
to
support
both
but
I
guess
now.
G
D
I'm
going
to
borrow
an
argument
from
from
like
Quantum
costing
earlier,
just
because
it's
permissive
on
a
port
does
not
mean
it's
not
encrypted
a
permissive.
You
could
not
want
HTM
TLS
on
the
port
and
you're
doing
your
own
https,
your
own
mcls,
your
application,
and
you
don't
want
istio
to,
and
you
don't
want
SEO
to
require
that
you're
doing
issue
mtls,
so
I
mean
I.
I,
see
value
for
both
so
you're
saying,
because
the
default
Behavior
with
no
pure
authentication
is
to
be
permissive.
D
G
G
All
right
well,
yeah
well
again
like
if
you
have,
if
you
want
to
exclude
a
port,
that's
fine!
If
you're
still
using
your
own
authentication,
that's
fine,
but
to
us
it
is
no
different
as
if
it
has
no.
We
can't
tell
we
can't
assert
anything
about
that.
Like
permissive
means
we
aren't
going
to
check
and
therefore
it
is
as
far
as
we're
concerned
unsecured
because
we
can't
provide
any
guarantees
on
our
end
as
istiocan.
G
So
I
see
what
you're,
saying
and
I
think
you
could
totally
do
that
with
the
port
level
exclusion,
you
just
exclude
it
and
then
you
don't.
We
won't
look,
but
you
know
we.
We
still
can't
make
any
guarantees
about
that.
So
it
doesn't
matter
it's
the
same
scenario,
kind
of
as
if
it
were
unsecured.
From
my
perspective,.
E
I,
don't
want
to
Rio
plus
the
first
thread,
but
I
would.
Rather,
if
we
have
a
port
setting
another
level
support
setting,
exclude
interception
completely,
because
in
that
case,
Network
policy
and
all
the
other
things
and
empty
native
application.
Level
TLS
and
all
these
things
can
take
effect,
I
mean
they
can
have
Source,
IP
and
I.
Think
we
agreed
eventually
as
a
feature
we
may
want
to
have
this
excluded,
maybe
not
or
I'll
write
a
token
experience.
E
So
I
should
always
not
use
ambient
if
the
FTC
reports
or
receive
Network
policies,
but
having
port
in
you
know
in
in
motorization
policy
to
mean
permissive,
meaning
plain
text
will
be
just
broken
in
network
policy,
but
will
still
be
broken
in
other
ways
and
then
have
another
Port
where
you
say
that
Port
Will
Will,
just
not
capture
and
you
can
apply
another
policy
to
be
very
confusing
for
users.
G
Yeah-
and
that's
that's
kind
of
want
to
raise
this,
though,
because
like
in
the
in
that
issue,
we
were
saying
that
we
do
not
want
to
allow
people
to
not
capture
things
right
and
that's
kind
of
what
we're
talking
about
for
the
hairpinning
again
right.
We
want
to
capture
everything,
and
then
we
figure
out
what
to
do
with
it
in
terms
of
policy
after
that.
So
that
means
capturing
is
not
something
we
want
to
encourage
people
to
opt
out
of
period.
G
D
Not
for
beta
I
think
that's
that's
where
I
am
on
this
I
think
something
like
inbound
exclusion
exclude
or
whatever
The
annotation
is
in
in
Statler
car
SEO
I
think
we
still
need
that,
but
I
don't
think
it's
something
for
us
to
focus
on
for
beta,
but
we
have
a
ton
of
other
things
to
get
to
get
through
before
next
release,
and
so,
at
least
for
me,
maybe
I
need
to
be
clear
when
I'm,
when
I'm
putting
my
opinions
out
there.
D
But
for
me,
if
I'm
saying
no,
we
don't
want
this
or
yes
we,
you
know.
Yes,
we
do
or
specifically
no.
We
don't
want
this
I'm
generally
talking
about
like
beta.
If
there's
enough
customers
coming
and
saying
we
need
this,
then
yeah
I'm
completely
on
board
with
with
evaluating
designs
for
that.
But
my
my
context
is
beta
at
this
point.
Okay,.
G
G
Okay,
so
back
to
the
so
the
solo
question
of
supporting
both
I,
don't
actually
think
we
need
both,
since
you
can
express,
you
can
always
fully
if
we
do
Port
level
is
fully
as
good
as
Global.
In
every
case,
it
just
means
that
you,
as
the
user,
have
to
be
more
explicit
about
your
impressiveness
I.
G
You
do
pure
authentication
strict
or
you
know
strictly
the
default,
and
then
you
would,
if
we
just
say
look
strict,
is
always
a
default
and
we
opt
out
as
report.
Then
they.
B
G
B
The
default,
then
you
probably
only
need
Port
level
or
right
okay,
because
we
don't
really
want
to
say
it
does
limit
what
you
can
do,
but
it's
okay,
we
don't
care
about,
but
with
permissive
as
a
default.
I
think
it's
useful.
We
need
both
a.
G
It's
we
found
some
bugs
in
it,
though,
which
is
kind
of
why
it
came
up
and
interesting.
We
were
trying
to
decide,
you
know
to
what
degree
we
want
to
support
it,
and
if
we
do
want
to
support
it,
should
we
fix
the
bug
so
yeah.
It
sounds
like
we're
going
to
fix
them.
Okay,
cool
thanks
guys.
That's.
D
D
Okay
with
that,
we
have
come
to
the
end
of
our
agenda.
Do
we
have
any
last
topics
that
folks
need
to
discuss
in
two
and
a
half
minutes?
If,
if
not,
we
can
actually
get
out
on
time
for
a
a
change.
That'll
be
nice.
C
I
had
a
very
brief
question:
there
was
some
talk
about
office
hours
being
started
for
mbn.
Has
that
happened.
D
Great
question,
so
the
office
hours
would
just
be
for
issue
in
general
and
they
have
not
started
yet
Cameron,
who
I
think
was
heading
that
up
from
steering
is
also
heading
up
the
the
election,
and
he
mentioned
to
me
that
he
will
look
to
kick
that
off
once
the
election
has
is
over,
but
I
I
think
we
should
expect
to
hear
something
about
that
soon.
G
I
can
bring
it
up
with
Cameron
too,
about
the
trying.
D
All
right,
in
that
case,
I,
think
we're
done
thanks
for
the
time
everybody
and
happy
hacking
talk
to
you
later.