►
From YouTube: Ambient Mesh WG Meeting 2023 07 05
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
Okay,
everyone
welcome
to
the
Wednesday
July
fixed
occurrence
of
ambient
weekly
contributors
meeting,
and
the
first
topic
is
from
Keith.
A
All
right
there
we
go
okay,
peace,
so
the
first,
the
only
topic
is
from
you.
C
Yeah,
so
sorry,
I
lost
track
of
time,
I'm
doing
something
else
yeah.
So
as
an
action
item
from
the
last
meeting,
I
went
through
the
ambient
API
stock
and
pulled
out
some
topics
for
conversation.
C
The
first
one
well,
I'll
start
the
second
one
first,
because
we
talked
about
last
week,
so
we
looked
I
mentioned
last
week.
The
destination
will
Improvement
stock
and
talked
about
what
we
needed
to
or
ask
questions
about
what
we
needed
to
get
the
closure
for
the
ambient
beta,
and
we
realized
that
the
destination
rule
Improvement
stock
is
too
General,
so
I
went
through
and
pulled
out
specific
any
date.
Specific
questions
from
the
doc
and
I
put
them
in
the
ambient
apis
documents.
C
So
I'll
go
to
the
section.
Yeah
I
should
link
directly
to
it.
So
as
far
as
the
open
questions
for
Destination
rule,
there
are
three
top
level
questions.
One
should
ambient
support
non-service
to
find
subsets.
C
In
other
words,
should
ambient
match
support
destination
rule
Define,
subsets
second
question
should
Z
tunnel
Implement
any
of
the
destination
rule
functionality
period
specifically
around
like
L4
connection
settings,
for
example,
and
then
third
question
which
destination
we'll
feel
to
be
supported
in
and
generally
versus,
beta
and
I
kind
of
put
my
gut
feeling
for
on
all
the
fields
there
in
the
in
the
bullet
points
so
yeah.
Does
anybody
have
questions
for
on
any
of
you
or
sorry?
C
Does
anybody
have
any
thoughts
or
comments
on
any
of
these
questions,
because
I
think
that
I
don't
think
these
are
all
the
things
kind
of
standing
in
the
way
of
destination
data.
D
C
C
You've
got
L4
I,
believe
there's
like
a
wire
detection
for
connections
dropped
and
things
like
that.
Do
we
want
to
require
users
to
deploy
a
waypoint
for
those?
If
you
want
to
implement
some
of
that
in
G
tunnel
am
I
completely
off
Facebook.
How
that's
implemented
just
wanted
to
get
clarity
on
those
and
that's
kind
of
the
purpose
of
question
two.
D
Yeah
thanks
well
connection
pooling
at
L4
is
not
really
doing
much
as
far
as
I
understand
it
and
similar
outlier
detection
until
4
is
also
not
doing
much
I
mean
you,
don't
have
a
application.
Level
errors,
so
I
mean
most
of
those
are
not
the
same
in
principle.
So,
even
even
if
you
have
the
same
field,
the
values
will
be
much
more
restricted.
C
D
E
F
B
F
F
Okay,
yeah
I
got
confused
the
reason
I
asked
this
clarification.
Question
is
when,
when
we
write
the
ambient
announcement
block,
we
put
out
the
functions,
the
two
slides
of
the
layer
between
layer,
4
and
layer,
seven
right
and
we
had
in
the
layer
four
one
I
think
we
have
some
routine
functionality
in
there.
Yes,.
E
C
Yeah,
that's
helpful
so
that
that
completely
clears
up
the
second
piece.
So
then,
that
narrows
down
the
third
question
and
the
first
question
so
will
which
designation
rule
feel
to
be
supported
and
I
can
be
more
specific
here
say
in
the
Waypoint
generally
versus
in
beta
and
then
should
for
the
first
question:
should
the
Waypoint
support
non-server
to
find
substance.
F
Make
the
subsets
the
existing
destination
rule
is
already
supported
in
Waypoint.
In
my
understanding.
C
I
wasn't
aware
of
that,
the
the
original
doc
that
the
destination
improvements
act
said
it
acted
as
if
it
was
an
open
question.
Maybe
if
it
already
Works
in
that.
F
C
F
And
also
the
new
AP,
the
Gateway
API
and
it
has
usage
on
destination
rule
to
do
either
Canary
based
routing
or
40
injection.
C
C
Sounds
like
the
answer.
This
is
yes
already
implemented,
supported.
Okay,
that's
good
to
know
because
the
now
they're
not
going
to
thinking
otherwise
and
then,
as
far
as
these
other.
Is
that
only
the
third
question.
It
starts
these
other
fields,
load
balancer,
attention
pool
level
settings
you
don't
have
to
get
all
of
these
figured
out
on
this
car
necessarily,
but
I
think
it
would
be
good
to
kind
of
get
a
a
sense
of
what
leads
Implement
for
waypoints
Now
versus
later.
C
Okay,
well,
not
the
the
doc
is
out
there.
This
is
the
amp
API
stock.
It's
linked
in
the
am8
working
group
meeting
notes.
So
take
a
look.
Let
me
know
if
you
have
opinions,
if
there's
no
strong
opinions,
then
I'll
just
kind
of
move
forward
with
what
I've
got
here,
come
from
a
lazy,
consistent
perspective.
C
Right
thanks.
That's
it
for
this
bullet
point.
There
is
one
more
one,
more
open
question
that
I
Linked
In
the
agenda,
also
in
the
API
stock
and
it's
around
the
authorization
policy
protocol
proposed
protocol
field.
C
So
under
the
operation
policy
heading
yeah,
it
was
proposed
to
add
a
new
protocol
field,
the
unspecified
spear
TCP-
and
this
would
be-
and
in
addition
to
the
Target
ref,
the
target
ref
field
that
we'd
be
adding
as
a
Gateway,
API
kind
of
compliant
policy
attachment,
John
and
I.
Both
were
unsure,
but
I
don't
have
Mrs
fully
agreed
upon,
and
if
this
is
greenlit
to
be
implemented,
does
anybody
have
more
recollection
of
what
we
just
agreed
upon
here.
D
C
I
believe
it
would
be
to
I
I
cut
down,
I
got
joined
up
I
believe
it
was
to
be
used
into
a
heuristic
for
the
control
plane
to
know
whether
or
not
a
particular
authorization
policy
is
intended
for
L4
versus
L7,
so
the
user
can
more
clearly
Express
their
intent.
I
don't
know
if
there
may
be
other
reasons
behind
that,
but
that's
what
I
remember.
D
D
D
I'm,
fine,
not
moving
it.
It's
just
I'm
questioning
whether
sniffing
is
a
good
thing
to
have
when
Waypoint
in
general,
because
we
pointed
http
so
having
TCP
there
and
it
creates
all
sorts
of
weak
conditions
where
things
don't.
E
D
Not
going
to
do
in
Sea
tunnel,
well,
there
is
stuff
you
can
do
with
TCP
that
you
can
do
in
history.
The
question
is:
is
that
the
good
stuff
to
do
in
waypoints
and
I
mean
if
you
deploy
a
waypoint,
you
have
assuming
this
GP
like
it
will
be?
It's
just
creates
a
weird
condition
that
now
you
don't
have
to
specify
just
play
point.
You
have
to
specify
protocol
everywhere.
F
So
can
I
ask
a
dumb
question
if
we
do
sandwich
wood
Waypoint
just
handle
HTTP,
because
honestly
I
say
if
I
think,
from
a
user's
perspective,
I
would
hate
to
specify
the
protocol
I
think
it's
not
intuitive
and
it's
easily
forgotten,
especially
when
they
transform
their
istio
experience
from
layer
4
to
layer
seven.
Now
they
have
to
change.
Remember
to
change
the
protocol.
E
That's
also
applied
to
sidecar
by
the
way
and
Francis,
by
the
way,
you're
showing
some
weird
page
that
you're
probably
not
attending
the
show
yeah.
But.
F
Wait
the
in
psychi
do
I
have
to
specify
the
protocol.
Maybe
I
missed.
E
It,
no
you
don't,
but
at
least
right
where
you
say,
I
want
to
deny
all
traffic,
that's
post
requests
and
all
of
a
sudden,
all
TCP
traffic
is
blocked
right.
We
talked
about
this
quite
a
bit
a
few
months
ago.
F
D
D
E
F
E
Almost
every
API
in
istio
has
L4
functionality
that
we
don't
want
to
put
in
Z10.
So
there's
TCP
wrap
this
destination
rule,
there's
so
Envoy
filter,
which
exposes
all
sorts
of
envoy
stuff
that
we
I
don't
even
know
about
that
that
users
use
at.
E
Much
Limited
in
Z10
all
right,
we
don't
have
all
the
filtering.
We
don't
have
the
per
workload
overrides
all
that
sort
of
thing.
There's
all
these
aspects
that
we
specifically
don't
want
to
make
the
tunnel
client
aware
and
be
adding
these
things
like
for
this
client
we
route
this
way
and
for
this
other
one
we
wrap
this
way.
D
So
I
I
know
there's
a
whole
genetic
word.
I
mean
there's
no
awesome
in
PCP,
there's
very
few
filters
in
Envoy
for
TCP
I.
Don't
think
it's
that
many
I
haven't
actually
seen
any
used.
Success.
Toxic,
for
example,
which
is
not
even
TCP
Telemetry,
is
identical
in
Z
tunnel
and
and
void.
I
mean
you,
you
made
it
unethical,
so
there's
no
extra
additional
stuff.
D
D
If
anyone,
if
we
should
start
from
the
use
case
and
then
work
backwards,
not
just
assume
that
history
did
it,
so
we
need
to
do
it.
That's
sort
of
my
my
goal
here
and
I
want
to
understand
if
any
TCP
level
policy
in
Waypoint
has
to
have
a
good
action
now,
otherwise,
it's
just
very
expensive
to
deploy
a
whole
proxy
to
the
TCP
stock.
C
I
think
I've
been
like
I,
had
a
really
good
question
in
the
in
the
chat
here,
easy
time
to
fundamentally
a
L4
proxy
or
a
TCP
proxy,
because
I
think
that
that's
gonna
that
should
impact
how
we
well,
if
we
add,
enum
what
those
values
are
going
to
be.
B
Yeah
I
I
think
my
main
objection
is
just
tying
mapping
stuff
to
Z
tunnel
based
on
protocol
versus
layer
like
I,
don't
that
seems
like
something
that
we
shouldn't
actually
care
about
at
the
z-tunnel
layer
and
if
we
need
to
Z10
shouldn't
care
about
protocols,
ideally
other
than
the
protocols
at
the
layer.
It's
designed
to
focus
on
so
yeah
I.
Don't
really
want
to
get
into
a
situation
where
saying
well.
This
is
tcps.
It
needs
to
the
Z
tunnel.
E
B
E
B
D
B
B
Yeah
yeah,
yeah
I
think
that's
fine,
like
it's
just
more
I
want
to
say
like
if
we
say
that
this
policy
applies
to
layer,
three
or
layer,
four,
and
therefore
it
goes
to
Z
tunnel
I'd
rather
say
that
than
say
this
is
TCP,
so
our
convention
is
that
TCP
traffic
is
rules
apply
to
Zito
like
that's,
not
a
useful
API
surface.
That's
construct
is
kind
of
what
I'm
saying
or
at
least
I
think
that's
a
messy
one
that
we
maybe
shouldn't
replicate
here.
Unless
we
have
a
real
good
reason
to
do
it.
C
So
do
we
have
an
idea
about
where
we're
leaning
with
respect
to,
should
we
add
a
protocol
to
obligation
policy
I
think
it
sounds
like
yes,
we
want
to
and
that
this
is
even
outside
of
AMD.
This
is
something
that's
that's
desirable,
but
sounds
like
most
of
the
discussion
at
this
point
is
what
already
enum's
going
to.
B
Be
well
if
it's
not,
if
the
enums
are
not
protocols,
then
it
wouldn't
be
a
protocol
field.
It
would
be
something
else,
maybe
later
or
something
or
I,
don't
know
something
like
that,
but
essentially
that's
kind
of
what
I'm
saying
is
I
would
like
it
to
not
if
I
would
like
to
avoid
using
that
to
determine
whether
something
should
go
to
I
would
like
to
avoid
protocol,
as
in
the
strict
sense
of
the
term
being
used
to
determine
whether
something
goes
through
zetel
or
not.
B
C
Yeah
plus
one
for
me
there,
but
it's
naming
aside,
is
that
generally
the
consensus
here.
Yes,
you
need
to
add
this
field.
Yes,
you
want
to
add
this
field
in
addition
to
Target
rep
and
the,
and
we
need
to
change
the
name
from
protocol
and
and
make
the
enum
it
makes
and
make
the
enum
based
on
the
enforcement
point
or
layer
that
we
want.
The
policy
to
occur
is
that
the
takeaway
I
should
be
I'm
getting
here.
B
F
I
guess
I
would
also
suggest
to
look
at
our
existing
authorization
policy
and
some
of
the
semantics
there
just
to
be
a
little
bit
consistent
and
not
too
surprising.
C
Yeah
plus
one
I
I,
don't
think
that
this
changes
any
of
the
semantics
I
do
think
we
want
to
oh
I
do
think
we
want
to
avoid
the
scenario
that
John
mentioned
earlier.
Wear:
oh,
you
want
to
only
accept
but
request
and
now
I'll
teach
you
trap
and
if
tonight,
because
the
you
know
the
layer
is
different,
but
outside
of
that
I
I
do
how
about
this?
C
I
think
that
this
is
worth
maybe
a
design
duck
on
its
own,
since
when
it
is
a
couple
of
API
changes
and
two,
it
done
a
sensitive
part
of
our
API
surface.
So
how
about
I
I?
Take
the
the
exam,
the
credit
design
doc
for
this
change.
I
already
have
an
umbrella
if
you
out
for
the
Target
ref
change
too
population
policy,
but
I
think
that
I
think
that
the
I
won't
say
protocol,
but
the
layer
con
to
add
any
layer.
C
Context
to
our
Edition
policy
is
worth
a
separate
Standalone
conversation
just
to
make
sure
that
we're
keeping
semantics
and
the
upgrade
path
clear,
so
I'll
I'll
take
that
action
item.
F
Yeah,
that
sounds
great.
Thank
you.
So
much
kiss
yeah
one
thing,
I
guess
I
I
will
do
a
encourage
us
to
Think
Through
is
that
we
already
have
this
Target
ref.
We
also
have
a
workload
selector
right
in
the
authorization
policy,
so
these
are
specific
to
waypoints.
To
my
understanding.
So
is
there
anything
we
can
Leverage
The
Factor
user
might
already
have
The
Ref
or
the
workload
selector
to
to
kind
of
elaborate.
So
they
don't
have
to
specify
this
and
then
only
maybe
in
certain
scenario
that
they
need
a
Clarity.
C
So
I
think
there
are
two
parts
of
that
conversation
right
when
it
comes
to
workload
selector.
My
understanding
is
that
we
want
to
don't
not
support
them,
ambient
the
and
then
digging
deeper
into
some
of
these
new
Fields
Target
ref
and
the
the
layer
field
for
Target
ref.
We
that
would
be
an
ambient
specific
deployment.
Topology
specific
field,
if
you're
using
sidecars
it
would
be
ignored,
is
what
I'm
understanding
and
then
the
SRS
layer
field.
C
F
C
I
mean
based
on
John's
scenario
earlier
it
sounded.
It
would
at
least
be
useful
for
for
sad
cards
sounds
like
there
are
some
existing
gaps
or
some
existing
I'll
say
an
inspection
Behavior
inside
car
mode
with
protocol.
C
So
I
guess
that
got
the
question
right.
Do
we
want
to
back
quote
unquote
back
torque
this
to
sidecars
or
pushed
forward
with,
or
just
kind
of
only
make
this
an
ambient
only
type
thing.
E
It
is
I
mean
I
feel
like
we're
talking
about
this
abstract
thing
when
it's
so
kind
of
rich
in
here,
and
maybe
it
would
help
to
review
the
doc
offline
and
discuss.
F
C
The
authorization
policy
just
had
this
extra
protocol
piece
that
we're
wanting
that
we
know
we
want
to
apply
for
an
ambient
but
like,
for
example,
I
think,
maybe
request
authentication
also
on
the
workload
selector.
That
would
be
replaced
with
the
target
rep
as
well
for
ambient.
C
C
Okay,
cool
and
I'll
also
I'll
take
another
action
item
to
create
GitHub
issues
for
all
of
the
resources
that
need
Target,
reps
as
well
does
I
guess
another
follow-up
question:
do
we
need?
Is
this
doc
this
API
stop
considering
like
approved
or
blessed
by
Toc
or,
if
there's
some
other
API
review
necessary
from
from
Toc
in
order
to
like
add
a
field
to
select
request,
Authentication.
F
F
It
will
be
good
to
kind
of
socialize
with
a
few
other
TLC
members
not
being
here,
because
they
will
be
reviewed.
The
API
doc
I
assume
this
woodlands
in
the
API
repository
right.
F
C
Off
the
top
of
my
head
anything
any
resource
that
is
applicable
to
Indian,
so
like
excluding
sidecar,
for
example,
for
any
resource
applicable
to
Ambience
that
uses
workload
selector
for
policy
should
also
have,
or
should
instead
be
programmed
via
a
Target
ref
instead
of
workload.
Selector
and
I
do
I
mean
this
anything
API
stock
says
the
pretty
much
the
same
thing
when
it
lists
several
request.
Authentication
is
one
that
would
have
no
other
changes.
C
C
Okay,
I'll
try
to
get
something
might
be.
You
know
a
one-pager,
but
just
describing
just
extracting
a
lot
of
the
context
for
from
the
stock
from
the
TOC
meeting
next
week.
F
That's
great,
thank
you.
So
much
kiss
and
I
saw
on
the
chat.
Jackie
was
asking
about
the
drive
ambient
to
Beta.
Did
you
say,
kids
there's
going
to
be
a
subgroup
set
up
for
that.
C
Yes,
so
in
last
meeting
we
kind
of
discussed
some
slipping
priorities
and
Francis
had
the
idea
to
create
some
stakeholder
holders
to
iterate
on
the
data
scope.
C
But
it's
John,
you
myself
and
then
Nathan
mittler
volunteered
on
or
maybe
Atrix
to
kind
of
get
together
a
a
core
still
gradient
beta,
because
because
the
concern
was
that
we
that
there
are
some
must-haves
from
a
priority
perspective
like
we're
not
going
to
have
a
beta
quality,
Ambience
ready
without
the
things
being
done,
and
they
didn't
have
any
owners
on
them.
C
So
we
thought
it
would
be
helpful
to
have
a
defined
scope
for
what
that
minimum
viable
product
is
and
then
use
that
to
kind
of
could
filter
our
priority
or
order
of
operations.
When
it
comes
to
executing.
C
C
Yeah
but
yeah
the
other
thing
I
forgotten
into
that.
There
was
a
timeline
associated
with
that
in
your
to
have
a
proposed
scope,
ready
by
like
721
and
organize
a
one-off
Toc
meeting
to
kind
of
get
sign
off
of
that
scope.
C
That
was
it
on
my
end,
I
think
Francis
now
accept
away,
but
I
think
yeah
I
had
the
only
topic,
so
I
think
we
are
pretty
much
done.