►
From YouTube: Ambient Mesh WG Meeting 2023 05 10
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).
B
B
All
right,
kids,
what
did
you
say
it
was
you
had
some
background
or
something.
B
B
All
right,
I
think
this
is
a
dog
which
I
think
this
time
I
did
put
in
the
Google
Drive.
So
hopefully
everybody
have
access
to.
What
is
your
Community
Drive
should
be
able
to
access
the
dog.
If
not
do
let
me
know
I'll
try
to
figure
out
what
I
did
wrong.
So,
basically,
we've
I
guess
the
Israel
1.18
is
coming
out
soon
right.
B
The
next,
which
we
have
ambient,
will
be
part
of
the
alpha
in
1.18,
and
this
document
is
intend
to
socialize
ideas
around
you
know
what
do
we
believe
is
driving
and
they
match
to
Beta.
So
this
is
certainly
going
to
be
a
very
Community
effort.
Well,
you
know,
I
would
love
feedback
from
each
and
every
one
of
you
to
see
if
the
list
makes
sense
as
a
starting
point
and
certainly
there's
a
lot
of
work
as
you
can
see.
B
So
definitely
the
you
know
welcome
owners,
people
willing
to
sign
up-
and
you
know,
move
forward
with
many
of
these
requirements.
So
at
a
high
level,
I'm
not
going
to
read
the
docs,
it's
kind
of
like
kind
of
a
break
into
different
categories
is
I.
Think
MD
API
is
probably
one
of
the
most
important
one
as
we
were
reaching
as
we
are
about
to
reach
beta.
We
do
want
the
API.
B
We
have
consensus
on
the
API
and
hopefully
not
going
to
change
much
at
all
after
beta.
So
that's
number
one.
Another
trend
is
also.
How
do
we
get
ambient
working
Beyond
single
kubernetes
clusters
as
part
of
the
offer
we've
been
focused
primarily
on
MBM
for
single
cluster,
so
there
are
some
desire
to
I've
heard
from
multiple
team
members
in
the
community.
How
do
we
get
ambient
for
multi-network
multi-cluster?
What
about
our
workloads
and
running
on
VMS?
B
So
these
are
different
ideas
we
had
that
could
be
potentially
very,
very
important
for
beta
and
the
other
thing
same.
That's
I
constantly
hear
people
talk
about
is
CRI
right,
I.
Think
then
you
open
the
issue
if
we
run
silly
machine
I
with
with
ambient
right
now.
You
know
zetano
just
crash.
If
I
heard
it
correctly,
if
I
read
it
correctly
colleague
call
you
know
how.
How
does
this
compatible
with
ambience?
So
there's
a
lot
of
things
we
need
to
think
out.
B
Do
we
work
through
the
network
policy,
or
do
we
just
completely
ignore
the
CI,
so
we
need
some
messages
around
some
of
these
major
clis
as
we
declare
beta
cluster
and
security,
hardening
I
think
this
one
is
primarily
from
Louis.
Actually
I,
don't
know
if
Louisa,
if
you
want
to
add
anything
for
this.
B
I
guess
I'll
move
forward,
but
it's
a
relative
self-explanatory
and
then
observability
I
believe
John.
You
opened
an
issue
about.
We
need
to
figure
out
what
we
do
with
service
related
costing
I
know
you
are
pushing
for
auto
supported
in
the
community
too.
So
this
is
another
area.
We
have
to
put
some
focus
on
to
think
out.
You
know
what
is
our
story
around
observability
for
beta
and
what
can
we
do
with
existing
ecosystem
projects
out
there
like
kayali?
What
about
our
group
on
that
dashboard?
B
What
about
our
existing
distribute,
tracing
integration
with
Jager
and
potentially
even
Zipkin,
and
then
testing,
of
course,
from
what
I
know
is
right?
Now
we
only
run
a
subset
of
casting
with
ambient.
It's
like
a
lot
of
testing
that
we
use
with
cycos.
We
are
not
currently
running
them
with
ambient,
so
it's
going
to
be
important
to
get
many
of
these
testing
whenever
they
are
applicable
to
get
them
running
with
ambience.
B
All
right
and
then
a
few
other
ones,
there's
certainly
ambient
cycle
will
need
to
interrupt
because
a
lot
of
our
users
are
using
psychology
days.
So
we
have
to
think
out
a
story
for
them.
We
have
to
think
out
what
is
the
right
path
of
the
migration
as
they
move
from
psychology
without
psychology
ambient?
What
are
the
documented
recommended
steps
and
also
installation?
B
Definitely
that's
another
thing.
You
know
it's
under
the
page,
in
fact,
in
the
previous
meeting
about
what
do
we
do
with
the
operator
controller
on
the
server
side
and
upgrade
because,
as
when
we
declare
beta,
we
have
to
think
through.
You
know,
form
data
to
the
next
version
of
data.
If
it's
beta
or
production
ready,
you
know,
users
will
need
to
be
able.
We
need
to
be
able
to
tell
them.
You
can
upgrade,
hopefully
with
very
minimum
downtime
and
we
definitely
need
help
with
documentation.
I've
heard
a
feedback.
B
If
you
go
to
istio
IO,
you
actually
don't
know
where
NBA
is,
unless
you
go
to
our
blog
page
or
you
know,
unless
you
go
to
print
inventory,
so
when
I'm
being
rich
paid,
I
think
it's
extremely
important
to
actually
have
ambient
as
part
of
the
landing
page,
so
that
people
know
ambient
is
also
part
of
istio
and
last,
not
least
the
some
of
the
performance
testing
that
we
need
to
do
for
ambient
as
we
declare
beta.
B
So
that
is
the
list
we
have
at
the
moment.
So
I
would
like
to
kind
of
open
up
for
any
questions.
F
Lynn,
would
it
make
sense
to
add
a
section
I
can
see
that
a
lot
of
this
is
about
work
that
we
need
to
do.
We
also
I
think
need
to
hear
back
from
our
users
as
well
in
terms
of
what
we've
done
already,
where
it
works,
where
it
doesn't
Etc.
Should
that
be
captured
here
as
well,
or
is
that
sort
of
a
different
type
of
work.
B
F
Yeah
I
I
just
was
asking
for
the
sake
of
the
doc.
If
we
should
be
tracking
that
there
as
one
of
the
gates
for
graduation
to
Beta
it's
in
process,
we
are
actively
soliciting
feedback.
I
I
expect
that
we
will
get
feedback
and
hopefully
it's
positive
and
we
can
just
go
to
Beta,
but
if
either
the
feedback
is
negative
or
if
we're
unable
to
collect
feedback,
then
we
probably
ought
to
pump
the
brakes
on
beta.
F
That's
going
to
go
out
we're
also
going
to
be
conducting
a
end
user
Summit
in
Late
July,
where
we're
specifically
asking
for
users
who
have
done
a
more
than
trivial
test
of
ambient
like
some,
maybe
a
development
or
staging
environment
to
come
and
give
feedback
in
something
like
a
two-hour
q,
a
session
but
I'm
working
on
the
details
and
could
use
all
the
help.
I
could
get.
Okay.
B
G
Okay,
I
put
a
comment
as
well
on
the
doc
I
think
it,
you
know,
have
huge
API
surfaces
and
huge
products,
hoping
to
bet
that,
once
it's
both
dangerous
and
and
very
likely
to
to
not
be
able
to
focus
on
on
all
the
things
that
will
take
forever.
G
A
much
more
practical
approach
is
to
break
it
down
and
to
to
split
it
into
independent
features.
For
example,
you
know
CLI
plus
Z
tunnel,
a
standalone
components
would
move
to
better
or
could
move
independently
and
again,
since
we
expect
cni
to
be
maybe
merged
with
upstream
cnis
or
combined
or
provided
by
a
provider.
Maybe
something
that
is
decoupled
from
from
history
itself.
G
We
can
have
the
new
authorization
AK,
for
example,
released
sooner
because
it
as
far
as
I
know.
It
applies
to
both
sidecars
and
to
and
to
Ambience.
So
it
will
be
much
better
to
not
have
one
big
ambient
blob,
but
to
have
a
list
of
distinct
features
that
can
can
move
at
different
speeds
and
obviously
work
on
Discovery
service
is
probably
one
of
the
first
things
that
we
we
should
enable
by
default.
It
needs
to
and
and
have
it
on,
because
it's
super
safe
and
the
most
useful
independent
of
of
the
rest.
B
Yeah
I
think
there's
no
disagreement
if
a
small
features
could
be
promoted
to
Beta
if
they
are
ready,
but
I
do
think
users
are
looking
at
us.
Is
ambient
mesh
beta
right?
That's
the
question!
The
user
would
ask
they're
not
going
to
ask
us
hey
by
the
way.
Did
you
have
the
workload
XDS
implemented
for
psycha?
Is
that
feature
beta?
You
know
they.
G
G
Will
be
better
when
all
the
components
are
better,
of
course,
but
we
can
have
them
test
work
or
Discovery
service,
for
example,
in
the
next
release,
because
we
just
need
to
enable
by
default
and
start
using
it
in
in
for
for
Telemetry,
or
we
can
have.
You
know
complete
testing
for
individual
features
separate
from
from
from
and
when
all
the
things
are
better,
obviously
as
a
whole
will
be
better,
but
at
least
people
can
get
give
feedback
on
individual
things
like
age,
Pawn
or
the
other
six
anyway,
I.
D
A
The
one
thing
I
want
to
want
to
clarify-
and
I
mentioned
this
a
couple
of
months
ago,
but
I
think
we
need
to
really
try
to
be
careful
about
how
we're
referring
about
and
in
with
respect
to
Future
status,
I
kind
of
loosely
agree
at
least
an
apartment
costume
here,
because
you
know
I
see
things
on
the
beta
list
like
workload,
you
know
VMS
and
multi-network,
and
things
like
that
and
I
think
that
Ambience,
you
know
we
decided
that
ambient
is
the
architecture
The
Architects
are
reaching
beta
is
a
distinct
conversation
from
that
that
architecture
being
having
feature
parity
with
what
it
just
inside
courses
and
if
the
plan,
if
the
goal
is
to
try
to
get
the
architecture
in
data
by
next
release,
I
think
that's,
probably
a
lot
more
feasible.
A
If
we
focus
on
the
core
thing
necessary
for
the
architecture
rather
than
you
know,
is
it
things
like
multi-network
and
in
VMS
that
can
come
into
beta
in
their
own
time?
Does
that
make
sense
where
people
think
about
that.
E
Yeah
I
mean
I,
think
that's
like
there's
a
core
use
case
right
and
then
there's
an
extended
set
of
use.
Cases
Lynn's
right
right
that
when
we
talk
to
an
end
user
and
tell
them
that
Ambience
ready
and
then
qualify
the
statement,
the
qualifications
have
to
be
things
that
make
sense
to
the
user
right
because
right
like
we
can
have
a
a
hidden
feature
right
for
the
workload
Discovery
API
to
improve
Telemetry
experience,
custom
and
scale
or
the
derivatives
of
it.
E
We
can't
really
talk
to
the
user
or
like
that's
not
a
product
in
the
the
sense
that
users
would
consume
it
so
like
we
can
have
a
more
narrow
definition
of
the
ambient
core
and
Define
it
as
working
for
beta.
Then
everything
in
istio
working,
but
we
still
have
to
think
about
how
to
express
that
in
terms
of
features,
not
infrastructure.
G
Completely
agree
with
you
and
and
I
think
you
hit
the
point
here.
How
is
it
expressed
to
users?
What
will
the
user
see
when
ambient
this
is
available?
They
will
see
the
network
is
secure.
They
will
see
some
metadata
service
apis
that
allows
them
to
get
access
to
the
credentials
which
is
probably
like
required
and
they'll
see
waypoints.
E
Well,
if
I'm,
a
customer
and
I
I'm,
multi-cluster
I'm
gonna
care,
yeah
ambient
works
with
multi-cluster
or
not.
If
that
multi-cluster
implies
multiple
networks,
I'm
going
to
care
right,
because
it's
going
to
limit
my
ability
to
test
it.
If
I
can't
can't
Target
those
things.
So
we
have
to
say
like
those
are,
because
those
are
features
right
which
which
of
those
features
are
in
scope
for
beta
and
which
are
out
which
have
reached
beta
level
equality
and
which
have
not
yeah
like
ambient
single
cluster
could
be
beta
ambient
for
multi-cluster
or
multi-network.
D
E
Sure
we
can
yeah,
but
you
know
that's
that's
not
going
to
affect
like
because
beta's
at
the
point
at
which
users
are
going
to
make
adoption
decisions
or
qualification
decisions
right,
so
we
have
to
speak
their
language.
At
that
point,.
F
However,
if
we
limit
the
cardinality
of
one
dimension
to
sidecar
and
ambient,
then
it
gets
to
be
something
that
a
user
could
consume
relatively
quickly.
You
could
scan
down
a
list
of
12
to
20
features
that
already
work
to
some
degree
in
sidecar
that
maybe
they're
using
and
evaluate
whether
ambient
is
a
good
choice
for
them.
G
What
maybe
I
was
not
very
clear
with
my
API
comment:
I
I
think
defining
the
API
surface
and
where
the
API
applies
is
probably
the
most
important
thing
for
users.
That
was
what
I
was
trying
to
say:
I
mean
hey,
we
have
this
set
of
apis
that
are
supported.
The
apis
are
better,
obviously,
and
as
we
said,
you
can
use
them
in
single
cluster.
G
That's
the
warranties
we
make,
and
then
we
can
tell
the
environment
where
this
thing
works
or
doesn't
work
I,
don't
think
we
need
to
I
mean
it
will
be
better
to
separate
this
this
this
this
thing
and
we
have
compatibility
test
switch
for
for
the
API,
maybe
for
the
gamma
and
K2
API,
which
are
which
we
are
using
cells
or
other
test
and
clear
definition
of
when
an
implementation
is,
is
beta
or
compatible
from
from
way
with,
at
least
by
perspective
and.
F
B
D
E
E
Something
we
want
to
say
in
terms
of
right
quotes
so
like
single
cluster
right
with
no
sidecars.
So
just
Ambience
is
the
only
thing
in
the
cluster.
Can
we
bring
that
to
Beta
single
cluster
with
sidecars
right
so
like
an
upgrade
scenario,
single
cluster
plus
VMS,
single
multi-cluster
and
then
multi-network,
and
then
there's
probably
a
priority
of
which
of
those
things
is
more
important
like
it
might
actually
be
more
important
to
do
multi-cluster
than
to
do
sidecars
and
ambient
cohabiting
the
debate
to
be
had
about
the
relative
value
of
any
one
of
those
two
things.
E
Like
because
at
least
for
an
upgrade
strategy,
we
could
say,
look
just
uninstall
sidecars
and
then
install
ambient
right,
and
we
don't
support
cohabiting.
That
would
be
painful
for
customers
who
had
big
existing
installations,
but
it
probably
wouldn't
prevent
them
from
doing
a
POC
if
they
were
standing
up.
A
new
cluster.
A
That's
also
the
benefit
of
shipping,
a
smaller
core,
because
the
big
issue
with
alien
being
alien,
anything
in
Alpha
is
that
you're
going
to
have
less
adoption.
So
the
sooner
we
get
anything
out
to
Beta,
even
if
it's
smaller
in
surface
area,
we're
going
to
be
getting
more
feedback
from
the
users
who
are
able
to
do
plcs,
because
this
this
core
piece
of
behavian
Architecture,
is
data.
G
And
maybe
this
score
would
be,
you
know
just
a
networking
layer,
because
that's
super
narrow
super
easy
to
qualify
and
much
easier
to
test,
like
you
know,
basically,
zitana
plus
cni,
providing
network
security.
E
G
And,
and
by
the
way,
shipping
mtls
as
a
feature
separated
them
first,
it
will
enable
people
to
have
security
across
the
entire
mesh.
I
mean
enable
by
default
and
all
the
other
nice
things.
You
know
right.
D
A
I
think
I
think,
ladies
doctor,
just
in
a
good
spot
of
seeing
what
there
is
that
we
could
push
the
beta.
What
remains
is
that
Matrix
of
here
are
the
permutations,
okay,
that
just
inside
Harley-Davidson
idiot
and
then
you
can
have
that
conversation
priorities
and
then
from
there
we're
able
to
do
what
we
get
throughout
the
get
it
in
Project
boards
and
start
executing
on
on
the
individual
things
that
we
prioritize.
D
B
I
think
that's
foul
in
the
meanwhile,
though,
I
don't
want
to
stop
people
who
are
interested
in
working
on
right,
different
things
right
in
the
community.
If
there
are
people,
because
we
know
this
is
like
the
end
goal,
we
want
to
have
mbms
to
be
beta,
and
these
are
the
different
things
we
want
to
be
able
to.
You
know
decloud
beta,
for
the
entire
ambient
of
at
least
most
of
the
future
of
ambient,
so
for
people
in
the
community
are
interested
in
working
on
those
items.
B
You
know
with
a
happy
happy
to
have
those
people
starting
to
help
out
and
working
on
those
in
parallel.
We
can
also
start
to
phase
this
out
right,
maybe,
like
you,
you
guys
were
mentioning
right.
Zetano
was
just
layer
for
function.
Just
for
single
cluster
is
the
first
phase
and
then
maybe
single
cluster
is
the
second
phase,
with
layer,
4
and
layer.
Seven,
you
know
we
can
have
a
phase
up
to.
E
A
It
feels
to
me
looking
at
looking
at
the
dock
like
if
it
were
to
try
to
get
a
sense
of
what
these,
what
those
P0
things
like
would
be
where
there
would
be
no
debated
without
those
things
the
apis
feel
like
the
big
one.
In
my
opinion,
personally,
there's
the
perk
state
of
things
and
from
what
I
understand
is
you
know,
we've
got
this
API
stock
has
a
lot
of
things
in
it.
Potentially
changes
to
destination
rule
and
things
of
that
nature.
A
Do
we
have
any
sort
of
media
acronyms
on
getting
some
clarity
on
those
things,
because
I
I?
My
concern
is
that
there'd
be
additional
work,
that's
blocked
by
not
having
some
of
those
base.
Things
left
out.
E
Yeah
I
mean
there's
definitely
worked
to
resolve.
Api
ambiguity,
questions,
yeah,
I,
don't
know
if
having.
E
Love
to
see
whether
you
know
if
there
are
some
stragglers
in
that
that
would
prevent
beta
versus
just
saying
guidance
to
the
users
about
what
apis
they
should
use
to
be
considered
in
beta
versus
Alpha
state
right.
That's
always
a
problem
with
apis
anyway
right
so,
but
it
obviously
deserves
some
time
and
effort
now
right,
there's
the
gamma
stop
and
there's
the
existing
apis
right.
There
are
things
in
the
existing
apis
that
make
no
sense
for
ambient
and
we're
going
to
tell
users
not
to
use
them.
The
API
doesn't
get
deleted.
E
E
G
E
I'm
sure
yeah,
but
you
stay
forever
like
like
what
like
peer
authentication
policy,
is
a
classic
example
of
an
API
that
has
different
meaning,
slash,
maybe
no
meaning
in
the
world
of
ambient
right.
So
we
have
to
take
a
hard
look.
The
API
is
not
going
away,
but
we'll
just
tell
people
not
to
use
it.
Is
that
a
reasonable
answer
for
beta
or
do
we
have
to
mess
with
the
install
as
well
exactly.
F
G
E
E
A
My
biggest
question
is
I,
expect
away
from
the
internet
for
a
little
bit
is
I,
don't
know
the
current
state
of
the
David
API
stock
and
how
up
to
date
it
is
so
as
long
as
I
can
search
and
find
a
good
understanding
of
current.
D
D
B
Yeah,
okay,
so
yeah
so
I,
John,
correct
me,
Byron
I.
Think
one
of
the
contention
points
was
authorization
policy
right
how
we
apply
authorization
policy,
particularly
from
layer,
four
move
to
layer,
seven
right:
how
do
we
keep
it
the
same
with
today's
authorization
policy
and
are
we
okay
with
select
a
waypoint,
or
do
we
use
reference
binding
to
bind
to
the
Waypoint
I?
Think
that's
one
of
the
contention
points.
B
The
other
contention
point
is:
do
we
need
pure
authentication
policy
for
ambient
I
believe
there
are
is
actually
an
outstanding
issue
for
that
there
are
people
saying
it's
still
useful.
They
are
focusing
it's
not
useful.
I,
don't
think
we
ever
made
a
consensus
as
a
community
record.
That
decision
is
there
anything
else.
John,
you
want
to
add
that's
a
contention
point
for
the
MBA
API.
E
E
B
Right,
okay,
so
this
is
the
MBA
API
document
which
you
guys
can
find
it
so
previous
meeting
minutes
just
search
ambient
API
I
believe
so
one
of
the
idea
in
this
document
is
the
way
to
bind
the
authorization
policy
to
a
waypoint
is
through
I
think
what
gamma
normally
is
is
through
apparent
ref,
where
you
specify
you
know,
you're
binding
to
a
particular
Waypoint
and
I
believe
this
should
map
to
the
name
of
the
Waypoint
as
you
deploy
your
waypoints.
B
B
So
yeah
I
can
describe
what
we
implemented.
So
basically,
what
we
implemented
in
Alpha
junkratic
membrane
is
the
authorization
policy
where
we
ask
you
to
select
to
do
a
label
selector
on
your
Waypoint.
So
instead
of
using
parent
wrap,
you
would
use
a
workload
selector
and
then
you
would
specify
the
label
to
select
the
Waypoint.
F
C
Yeah
that
was
implemented
in
as
well
intended
to
be
implemented
as
a
stop
gap
before
we
implemented
this.
The
main
reason
we
didn't
do
this
I
think
was
there
was
some
hesitation
like
I,
think
we
mostly
agreed
on
this
there's
just
some
hesitation,
because
doing
this
means
making
an
API
change
to
basically
every
single
H2O
API,
just
a
somewhat
scary
idea,
especially
for
ambient,
which
was
pre-alpha
at
the
time,
so
yeah.
B
And
particularly
for
user
using
cycle
today
right
that
means
they
have
to
rewrite
their
author,
also
for
layer,
seven
and
also
I,
think
John.
The
other
thing
that's
a
little
bit
different
is
because
also
we're
using
layout
for
authorization
policy.
You
would
use
the
selector
here
so
so.
Basically
that
means
we
will
inconsistency
between
layer,
4
and
layer,
7
authorization
policy.
B
So
that
could
be
another
thing:
that's
very
confusing
for
the
user,
because,
as
a
user,
they
could
start
with
a
simple
rule
like
this,
but
not
having
a
layer,
7
portion
and
when
they
move
to
layer,
seven,
they
kind
of
have
to
change
the
select
your
parents
ref,
which
I
think
it's
not
very
intuitive.
G
Two
two
points
or
three
points
here:
if
we
want
to
have
a
proper
support
for
gamma,
Gateway
and
Vendor
model,
I
think
we
need
to
do
this
for
these
two
anyway,
because
that's
how
you
properly
attach
policies
in
in
Gateway
and
Gamma.
So
I,
don't
think
this
is
specific
to
ambient
it's
something
we
need
to
do
for
everything
it's
Backward
Compatible,
so
users
don't
have
to
change
anything
at
all.
G
It's
just
new
fields
that
can
be
added
to
a
crd
in
a
Backward
Compatible
way,
so
I
I
think
we
should
move
ahead
with
this
across
the
board,
starting
with
regular
istio.
G
So
it
applies
to
to
Gators
and
Waypoint
is
the
Gateway
so
and-
and
let's
solve
this
problem
first,
but
I
am
very,
very
reluctant
to
have
attached
to
Gateway
as
a
whole,
because
the
Gateway
may
have
multiple
ports
may
have.
You
know
multiple
routes,
it's
what
we
had
before
with
you
know,
applying
the
route
at
the
top
level
and
then
then
doing
double
routing
is
not
ideal,
and
you
know
when
it
is
to
say:
employee
has
ability
to
attach
authorization
policies
to
routes,
so
we
can
do
better
than
than
what
we
had
before.
G
G
D
G
G
A
common
API
between
between
istio
and
and
them
yet.
A
Yeah
I
think
I,
don't
know
that
we
have
of
compatibility
issue
as
far
as
changing
every
issue.
Installation,
because,
like
this
Captain
said
you
know
it's
just
a
new
field
so
that
parent
rep
can
be
used.
For
you
know
anything
for
Ambience
and
people
can
continue
using
interesting
occupation
policies,
so
they
moved
to
India
the
other
thing.
The
thing
that
does
concern
me,
though,
is
The
L4
operation
policy
approach.
Where
I
do
agree,
it's
a
bit
confusing
to
have
to
translate
from
parent
Rec
to
workload.
Selector
is
there.
A
C
So
one
thing
to
clarify-
and
this
is
probably
just
a
pedantic
wording
thing-
is
it's
not
L4
policies
use
label
selector
its
policies
applied
at
z-tunnel
versus
policies
applied
at
the
Waypoint.
You
can
apply
L4
policies
at
the
Waypoint
and
by
L4
policies.
I
mean
policies
are
all
made.
Exalt
four
attributes
right
I
think
you
probably
meant
that,
but
just
in
case
anyone
else
was.
C
G
Don't
know
it's
part
of
the
API,
you
know
we
should.
We
should
make
sure
that
we
we
leave
room
for
section
name.
Definitely
we
need
it
soon,
but
Section
8
should
be
especially
in
a
way
to
attach
to
routes.
Because
again
you
have
a
host
with
ten
thousand
routes.
You
want
your
not
to
put
the
authorization
policy
on
a
route
you
don't.
We
shouldn't,
perpetuates
the
current
implementation,
details
of
double
routing.
C
G
C
G
C
E
Okay,
obviously,
the
semantics
of
attaching
to
right
so
custom
like
the
whole
double
matching
thing
right
is
an
issue,
but
so
I'd
rather
like.
Clearly,
we
need
to
attach
the
Waypoint
right.
I,
don't
think,
there's
any
disagreement
about
that.
You
can
do
service
specific
selection
by
putting
a
rule
in
two
right.
So
that's
sufficient
to
meet
the
requirement
and
is
the
case
today
anyway,
yep
right
so
we're
we
have
no
regression.
G
C
C
E
Just
it
seems,
logically,
more
complicated
right,
like
you
said
you
wanted
to
attach
the
Lister
right
custom.
The
next
thing
would
be
to
attach
to
like,
like
within
the
Gateway.
You
would
attach
to
a
listener,
but
that's
not
specific
enough
either
right,
because
Port
or
Port
name
wouldn't
really
work.
G
To
to
click
I
mean
I.
I
was
not
aware
that
we
are
moving
Waypoint
to
use,
I
mean
kind,
Athletics
a
Gateway,
so
it's
kind
Gateway
with
you
know,
Gateway
crd
and
did.
C
G
C
G
C
The
Gateway
API
says
you
can
attach
to
whatever
you
want
and
the
implementation
decides
what
that
means
right.
So
we
can
attach
the
Gateway,
which
means
apply
to
everything
on
the
Waypoint
we
could
attached
to
service,
which
means
to
request
matching
that
service
we
can
attach
to
Route,
which
means
potentially.
G
C
G
I
think
an
nginx
Gateway
and
use
it
as
a
waypoint
assuming
implements
H1.
What
could
be
the
requirement?
Besides,
you
know
having
authorization
policies
that
attaches
to
the
Gateway.
C
Now
you
can
make
a
controller
that
configures
and
you're
next
to
do
it,
but
I
would
never
expect
any
other
Gateway
To
Be
A
Drop
in
replacement.
They
can
be
programmed
to
do
it,
but
none
of
them
are
going
to
out
of
the
box.
It's
not
just
a
standard
inverse
Gateway
right.
It
has
specific
Waypoint
semantics.
E
G
E
G
B
F
G
E
But
trying
to
standard
like
because
then
we're
trying
to
balance
the
requirements
expressed
within
the
the
capabilities
of
sdo
authorization
policy
with
the
attachment
mechanism
right
and
there'll
be
a
different
set
of
decisions.
Maybe
who
are
trying
to
standardize
it
right
as
part
of
gamut
itself?.
G
E
G
E
We're
this
is
still
the
istio
API
okay,
based
on
istio's
choice
for
its
Gateway.
Now
not
the
gamma
choice
for
authorization
policy,
but
we
can
propose
it
and
try
to
say
look.
The
sdl1
is
a
good
base
basis
for
that,
but
I
don't
think
we're
trying
to
do
that
right
now.
G
To
take
a
step
back,
my
goal
finally,
is
is
to
to
not
have
the
restrictions
that
John
mentioned,
that
you
must
have
something
very
special
as
a
waypoint
other
vendors
like
Google
or
someone
else
could
have
another
implementation
of
gateways
that
can
be
used
as
a
internal
load.
Balancer
that
can,
you
know,
satisfy
all
the
requirements
that
the
Waypoint
would
have.
G
G
B
Okay
cool
sounds
like
we
are:
okay,
I
do
have
a
question.
I
want
you
to
have
us
think
through
Waypoint
upwards
right,
so
I
envisioned
when
I
need
to
have
two
versions
of
waypoints
for
enrolling
a
while
Canary
revision
based
upgrade
I
assume
down
the
road.
We
would
support
that
right.
So,
in
that
case
with
parent
ref
I,
don't
as
a
user
I
don't
want
to
change
my
authorization
policy
to
necessarily
point
out
to
I'm
I'm
enforce
this.
Only
on
Waypoint
Dash
revision,
one
I
mean
forces
on
Waypoint
Dash
revision.
B
B
B
G
B
D
B
Yeah,
so
it
will
controller,
can
spin
up
the
new
reversion
based
on
the
same
name,
but
just
based
on
the
version
differences
yeah
that
would
solve
that
concern.
E
C
But
today
that
means
it
applies
to
the
whole
namespace
I
think
I
mentioned
how
we
should
do
it
in
here,
but
I
forget
what
the
answer
was.
I
think
it
was
something
like
we
won't
allow
that
on
waypoints
because
unattended,
us
whether
it
applies
to
a
waypoint
or
the
Z
tunnel.
C
C
C
D
C
I'm,
barely
barely
any
response.
The
issue,
though,
is
that
we
are
part
of
this
is
we
want
to
clearly
know
whether
a
policy
is
intended
for
Z10
Waypoint,
because
we
treat
them
differently
but
The
L4
aspect,
so.
D
E
E
C
C
Let's
specifies
whether
it's
TCP
only
for
HTTP,
which
helps
classify
whether
it's
for
a
z-tunnel
or
Waypoint,
so
I
think.
Actually
the
idea
of
that
namespace-wide
ones
don't
apply.
The
Waypoint,
maybe
maybe
outdated,
but
I
have
to
go
right
through
this
again.
I
really
forget
what
we
we
had
settled
on
I
mean
we
didn't
settle
on
anything,
but
we
had
okay.
C
G
Yeah,
but
it's
able
to
change
into
being
you
know
if
you,
if
it
has
a
patient
if
to
a
gateway,
which
is
you
know,
the
https
and
so
I
I
I,
think
I.
Think
using
the
Gateway
API
is
the
right
solution
here,
because
it's
a
clear
signal
for
the
users
that
they're
in
a
different
world
they're
using
a
Gateway.
You.
C
E
G
Yeah,
that's
a
discussion
that
we
definitely
need
to
have
again,
maybe
about.
If
we
want
to
keep.
You
know,
adopt
Network
policy,
foreign.
E
E
G
E
G
Yeah
I
I,
don't
think
upgrade
automatic
upgrade,
is
realistic,
feasible
or
something
that
will
never
happen.
E
Yeah,
so
that's
that's!
The
real
question
here
is:
are
we
okay
telling
users
to
do
work
and
what
work
are
we
willing
to
tell
like?
Is
it
okay
to
ask
them
to
do
if
the
answer
is
look
foreign
if
you're
using
workload
selectors,
which
means
also,
if
you're
no
use
using
no
selector
at
all,
it's
Z
tunnel
only,
which
means
every
policy
is
treated
as
all
of
four,
and
only
if
you
do
a
waypoint
selector.
E
G
C
E
C
This
was
all
a
great
discussion.
I
am
having
a
hard
time
concretely
telling
what
user,
what
people
want,
not
user.
Sorry
what
people
in
this
call
want
or
don't
want.
If
we
can
comment
on
the
doc,
whether
we
like
what's
in
the
dock
or
what
we
want
changed
I
think
would
be
really
helpful
to
make
this
a
bit
more
concrete.
I
will
do
the
same
myself,
because
I
wrote
this
a
few
months
ago.
I
don't
know
if
I
grouped
anymore,
so
yeah.
C
C
E
All
right
so
that
ship
has
sailed,
because
we
could
try
and
spend
some
time
on
it
today
and
see
if
we
can
get
on
like
this
is
the
most
that's
the
most
impactful
thing
I
can
think
of
right
and
if
we
can
get
close
to
what
our
beta
answer
is,
and
although
that
is
probably
good
from
a
user
feedback
standpoint.
F
Beyond
upgrades
the
more
apis.
We
have
that
behave
differently
if
a
waypoint
exists
or
if
it
doesn't
the
more
pressure.
I
think
we
have
to
automatically
create
the
Waypoint
on
the
user's
behalf,
in
other
words,
enabled
in
order
to
enable
L7
auth,
you
have
to
create
an
L7
auth
policy,
and
then
you
have
to
go
create
this
completely
unrelated
API
object
that
has
no
connection
to
the
policy.
Well,.
E
G
And
you
use
the
same
thing
for
details
because
you
have
increased
gateways
and
Ingress
Gators.
Hopefully
you
will
start
using
the
Gateway
API
and
authorization
policy
will
apply
to
parent
traps.
So
we
have
consistent
experience
for
waypoints,
Ingress,
Gateway
and
eventually
egress
gateways.
So
I
don't
see
a
problem
with
using
proper
kubernetes
apis
as
they
are
defined.
E
F
G
What
you're
saying
yeah
I'm
not
comfortable
with
this,
because
parent
is
required
in
gamma
and
then
it
kind
of
prevents
I
mean
my
goal
is
to
have
full
compatibility
today
with
if
gamma
say
or
sorry.
If
you
give
to
APS
say
that
you
don't
have
a
required
apparent
ref
and
it
applies
to
everything
then
I'm,
okay,
but
that's
not
what
that's
absolutely
I.
Think.
G
But
also
do
we
don't
want
to
invent
another
thing
that
this
is
just
specific
and
from
everything
else,
and
when
people
start
using
other
implementations,
they
will
have
to
oh
istio.
Does
it
in
this
weird
way?
Does
the
requirement
ref
and
I.
E
G
I
I
kind
of
don't
think
that
the
upgrade
that
migration
are
kind
of
the
long-term
important
thing
I
mean
long
term
is
to
have
compatibility
and
consistency
with
other
implementation
with
kubernetes
and
clean
API.
That
is
agree
this
one
time
I
mean
it's.
It's.
E
G
But
but
we
standard
that
already
on
how
to
attach
policies
to
gateways:
that's
parent
ref.
So
if
we
use
a
Gateway
API
for
creating
the
Waypoint
I
think
it's
reasonable
to
expect
that
policies
will
attach
the
way
Gateway
defines
them
which
is
bar
and
ref
I'm.
Okay,
if
we,
if
we,
if
we
just
choose
to
hey
this,
if
we
don't
specify
parent
ref,
we
do
some
issue
specific
thing
and
whatever
happens
happens.
G
Once
the
user
make
sure
that
if
there
is
no
side
card,
you
know
it's
ejected,
because
we
also
have
the
case
where
you
may
have
migrate
from
sidecars,
and
how
do
you
know
which
it
is
it's
very,
very
complicated
to
do
a
migration
and
not
know
what
it's
applying
to
I
mean?
Maybe
it
was
easy
intended
to
apply
to
sidecar
and
someone
apply
Waypoint
accidentally
or
they're
migrating?
It's
I,
don't
know
it
seems
confusing
versus
something
very
clear-cut.
G
G
B
G
If
I
wanted
to
be
safe,
if,
if
I
in
a
lane,
space,
I
didn't
see
this,
this
parent,
ref
or
The
Interpreter,
says
the
user
approach
authorization
policy
for
sidecars
with
sidecar
in
mind.
They
don't
know
that
they're
using
ambient
because
someone
else
may
be
created
this.
D
E
E
D
E
E
B
Yeah
I
mean
the
more
I
think
about
it.
I
think
I,
like
the
parents,
wrath
more
and
then
John
I,
don't
know
if
you
remember
I,
think
kids.
You
actually
comment
out
on
one
of
the
issues
that
Nina
raised
actually
I'm
just
going
to
send
the
issues
here,
so
everybody
can
read
it
offline
too.
So,
basically,
we
need
a
way
to
differentiate
the
layer
for
authorization,
policy
and
layer.
B
C
I
think
how
it
works
right
now
is
that
if
you
have
a
waypoint
and
the
request
is
from
the
Waypoint,
we
just
don't
enforce
anything
on
Z
tunnel,
which
we
would
like
to
do.
The
second
layer
reinforcement
and
if
you
don't
have
a
waypoint,
we
apply
all
the
policies
which
may
be
L7
ones,
and
an
L7
policy
will
never
match,
and
so
you
will,
depending
on
what
you
write,
LL
versus
denied
you
potentially
will
just
make
it
so
all
traffic's
denied.
C
When
you
you
don't
want
that,
but
that's
part
of
why
the
doc
has
the
explicit
protocol
selection.
So
we
have
very
clear
delineation
of
TCP
policies
applied
to
Z
tunnel,
we'll
reject
any
time
you
put
HTTP,
so
you
can't
possibly
make
a
mistake
and
then
we
have
both
layers,
Waypoint
and
Z10,
and
we
can
apply
both
policies
in
the
one
request.
So
we
have
kind
of
Defense
in
depth
and
even
Network
policies
right,
so
those
kind
of
three
layers
of
authorization
policy.
Potentially
they
want
to
give
you
a
request.