►
From YouTube: SIG Network Gateway API meeting for 20230522
Description
SIG Network Gateway API meeting for 20230522
A
All
right
welcome
to
the
Gateway
API
meeting
today
is
May
22nd,
at
least
in
California,
happy
happy,
Monday,
everyone
and
yeah.
Just
we've
got
a
pretty
packed
agenda
today,
but
don't
hesitate
to
add
things.
We
might
have
a
little
a
little
bit
of
time
here.
So
this
agenda
dropped
it
in
chat,
don't
hesitate
to
add
things
throughout,
especially
triage.
If
you
have
things
that
PR's
issues
whatever
that
could
use
some
attention,
please
add
them
to
this
list.
A
I
would
just
want
to
make
sure
that
we're
not
losing
track
of
things
and
there's
been
a
lot
of
movement
over
the
past
week,
so
we
probably
have
missed
at
least
one
thing
so
yeah,
that's
all!
As
a
quick
reminder.
This
meeting
is
covered
by
the
kubernetes
code
of
conduct
in
general.
That
just
means
to
be
nice
to
each
other.
Please.
C
A
D
Simba,
it
is
time
we've
had
really
good.
We've
had
really
good
numbers
on
the
meetings
that
we've
done.
The
alternative
times
for
I
did
just
finish.
Sending
out
the
update
for
next
week's,
so
I
mean
this
was
just
to
make
sure
we
do
more
of
them.
I
would
like
to
think
at
this
point.
We
could
probably
commit
to
doing
a
regular
alternative
time.
D
A
Yeah
I
think
that's
a
reasonable
Direction.
It
is
unfortunate
because
when,
when
Nick
is
no
longer
in
Europe
at
that
time
will
be
really
hard
for
him
and
always
good
feedback
from
him.
So
yeah.
Maybe
we
can
start
with
like
what
you
said.
A
you
know
try
this
for
once
a
month
and
the
reason
that
we're
moving
it
next
week
is.
A
Keith
asked
a
really
good
question
on
this
doc.
That
I
wanted
to
highlight
at
least
the
goal
of
using
Tuesdays
was
was
we
were
trying
to
alternate
with
the
time
that
gamma
has
so
that
gamma
can
have
a
meeting
at
approximately
that
approximately
this
time
slot
and
then
in
roughly
the
same
time,
slot
Gateway
would
have
one
so
definitely
trying
not
to
conflict,
but
it
does
mean,
as
we
experienced
last
week.
A
It
does
mean
that
whenever
we
have
these
morning
meeting
well
morning
for
me
meetings
these
earlier
time
slots,
it
means
that
we
do
have
the
potential
of
having
both
a
Gateway
API
meeting
and
a
gamma
meeting
in
the
same
day,
which
maybe
isn't
great
either.
So
we
may.
We
may
want
to
fine-tune
that
a
bit
still
open
to
ideas,
yeah
and
I-
don't
know
if
anyone
else
on
the
gamma
side
wants
to
chime
in
here,
but
I
think
from
gamma
side.
A
F
A
So
yeah,
okay
I'll,
keep
on
moving
then
the
the
next
one
is
an
issue
that
I
raised
a
little
bit
ago
and
maybe
it'd
be
useful
to
have
a
bit
of
a
poll.
I've
asked
around
in
slack
too
and
I'm,
realizing
that
my
my
question
is
not
as
clear
as
I
would
like
it
to
be
so
maybe
I'll
drop
it
back
to
here
for
a
second
and
what
I'm
really
trying
to
ask
is:
should
a
request
to
Slash
Foo
yeah
like
this
match
a
well
okay.
A
G
H
I
H
D
J
A
Yeah
for
for
prefix
match
the
spec
is
actually
very
clear,
and
we
have
said
that
a
trailing
slash
is
ignored
for
exact
match.
Our
spec
is
just
you
know,
matches
the
URL
path,
exactly
which
I
guess,
if
you
take
that
very
literally
then
yeah,
the
the
trailing
slash
is
Meaningful,
and
that
seems
to
be
what
the
the
overwhelming
feedback
here
or
for
con
a
little
bit
more
context.
C
A
F
A
A
C
I
A
I
A
J
Will
motivation
something
yeah,
so
in
all
of
these
cases,
right
from
a
usability
perspective,
when
you
work
with
people
trying
to
leverage
this
Technologies,
they
tend
to
come
from
some
something
in
the
past.
That
they've
worked
with
pcre,
for
example,
is
a
great
example
of
something
that
people
are
very
familiar
with
and
when
they
attempt
to
use
this,
if
we
standardize
with
something
in
the
past,
that's
reasonable.
J
A
Yeah
I
think
that's
very
true
and
a
very
good
tip
for
any
of
our
documentation
to
try
to
reference
things
that
you
know
our
concepts
are
coming
from.
You
know
where
you
know
the
the
way
that
we're
doing
this
kind
of
matching
is
entirely
compatible
with
X
technology.
I
would
be
very
encouraging
and
appreciative
of
any
any
contributions
to
docs
anywhere
like
that,
because
I
think
that'd
be
very
helpful.
A
Yeah
anyway,
this
is
the
thing,
so
cable
API
controller
is
coming
along
on
on
various
fronts,
but
it's
cool
to
see
another
Community
implementation
and
Dan
does
all
kinds
of
of
cool
things.
So
I'm
excited
to
see
where
this
one
lands-
and
this
is
he
was
working
on.
What's
the
the
other
one
LinkedIn
slack
that
I'm
missing
out
on
right
now,
yeah
Cube,
VIP,
cable
API,
which
does
anyone
remember,
is
this?
Is
this
the
same
thing
like
I
Know
Dan
was
working
on
both
of
these
yeah.
I
A
D
Yep,
just
the
Prototype
merged,
or
rather
a
usable
prototype,
is
now
merged.
It's
under
an
experimental
go
build
tag,
so
don't
get
caught
up
on
that,
but
it's
an
alternative
test
Suite
that
you
could
try
out
I
believe
at
this
point
we've
had
two
implementations:
try
it
out
so
just
wanted
to
kind
of
raise
that
to
people
that
it's
there
for
checking
it
out
making
some
updates
take
a
look
at
the
gap
which
is
1709
and
the
next
step
is
kind
of
we're
heading
towards
marking
it
implementable.
D
A
Yeah
that
that
makes
sense
and
and
I'm
so
excited
to
see
this
move
forward.
I
think
since
many
implementations
are
represented
here,
I
want
to
highlight
one
of
the
takeaways
and
goals
of
of
this
performance
profile
work,
and
that
is
that
we
want
to
highlight
the
results
on
our
implementations
page,
so
we
want
to
really
make
it
clear
to
anyone
who's
trying
to
understand.
You
know
this
is
an
API.
A
So
that's
something
that
will
come
at
some
point
right
now:
the
implementations
paid
is
pretty
wide,
open
and
I
think
it
will
become
more
structured
and
there
will
be
definitely
some
incentive
to
to
run
these.
So
please,
the
earlier
the
better
in
terms
of
running
this
through
trying
to
understand
if
it
works
with
your
implementation,
if
it
doesn't
what
we
can
do
to
help
it,
you
know
be
a
better
fit,
but
this
is
definitely
something
that
we're
trying
to
fit
in
between
now
and
ga
yeah
I
don't
know.
D
Yep
and
we
only
have
a
the
go
test-
Suite
right
now-
nobody
picked
up
the
CLI
one,
so
I
think
Matia
finally
decided
to
go
ahead
and
get
that
started
so
that
we
can
help
people
that
way.
If
you
need
the
CLI
version,
just
please
reach
out
to
Matia
I'm
sure
he
would
be
happy
to
kind
of
he'd
be
happy
to
know
that
you
need
it
and
then
he
might
be.
We
could
break
it
down
into
things
that
we
could
work
on
together.
D
So
I
was
wondering
if
there
was
things
we
could
do
to
help
facilitate.
Basically,
you
know
basically
giving
people
more
to
work
with
to
get
started
as
a
way
to
kind
of
make
it
easier
to
land
and,
like
start
working
on
multi-cluster
implementations,
so
I
just
floated
the
I
worked
with
someone
from
Quadrant
named
Dan
and
or
Dave,
and
we
both
kind
of
brought
the
conversation
to
the
last
multi-cluster.
D
Sync
that
you
know
maybe
there's
room
to
kind
of
build
more
Machinery
in
multi-cluster
and
that
Machinery
being
kind
of
like
generic
Machinery
on
top
of
say,
multi-cluster
services
that
would
be
in
service
of
potentially
everyone
and
doing
that.
Upstream
might
give
people
kind
of
the
I'm
not
going
all
in
on
this
yet.
But
I
do
want
to
kind
of
make
make
moves
towards
this
kind
of
scenario
where
we
could
all
kind
of
get
Solutions
here
and
start
seeing
things
working
for
those
of
us
who
don't
have
implementations.
D
So
that's
kind
of
what
we
floated.
The
general
response
from
multicluster
Sig
about
like
doing
more
machinery
in
upstream
was
a
little
guarded,
but
I
think
the
main
takeaway
was.
It
seems
like
they
felt
if
more
people
were
willing
to
show
up
to
help
with
that
Machinery
they
would
be
open
to
it.
So
that's
kind
of
just
general
call
out
that
I
wanted
to
point
out.
There's
a
the
meeting
was
last
week.
D
G
G
So
you
know
it's
not.
It's
indicated
to
change
some
of
it,
but
I
do
think
part
of
the
reason
why
it
has
an
involved
in
the
way
that
I've
been
personally
like
looking
for
is,
is
because
you
know
there
is
the
start
of
cost.
You
anything
will
take
cluster.
You
have
to
create
a
controller
and
there's
some
not
lots
of
non-trivial
problems
in
creating
a
controller
and
everyone
in
each
implementation.
He
does
think
something
differently.
G
I
think
that
there's
a
lot
of
conversation
that
can
be
driven
through
like
a
reference
implementation
for
people
who
just
want
to
play
around
with
it
or
start
to
evaluate
it
as
an
API
I,
think
it'll
reveal
some
I
guess
chinks
in
the
armor
lack
of
a
better
term,
so
I
I
love
to
see
it
happen.
I'm
worried
that
the
that
that
they
need
it
for
something
like
this
Machinery
cluster
to
happen.
G
D
E
Foreign
yeah
I
think
bandwidth.
Discussions
aside,
I
think
one
of
the
biggest
things
that
Sig
multi-cluster
needs
in
terms
of
like
intersections
with
Gateway
API,
is
for
implementers
to
start
playing
with
it
and
I
know.
There's
a
few
folks
that
have
like
had
some
critiques
of
it,
where,
like
some
things,
feel
more
aligned
to
a
service,
Discovery
use
case,
which
is
what
it
was
designed
for
to
be
fair
and
it
doesn't
always
fit
white,
as
you
might
expect,
with
mesh
sorry
about
the
dog
yeah.
E
So
though
it
seems
like
the
core
resources
are
pretty
solid
and
it's
more
of
just
like
the
I
guess,
implementation
details
and
getting
more
folks
involved
and
whatever
we
can
do
to
help
facilitate
implementations.
I
know
that
this
work
that
started
a
conformance
test
I
think
that's
really
encouraging
and
can
go
a
long
way
towards
being
part
of
that
Machinery
but
yeah.
It
was
like.
E
D
I,
don't
really
have
any
specific
ideas
at
the
moment,
except
maybe
vaguely
we
talked
about
potentially
just
like,
starting
with
the
first
obvious
stepping
stone
which
is
like
solving
efficient
service.
Import
like
that
might
be
a
place
for
a
non-test,
related
Machinery.
But
again
it's
all
open
questions.
D
I'd
like
you
to
if
you're
interested
in
those
questions
and
interested
in
maybe
I
can't
go
all
in
on
an
MCS
implementation
today,
but
I
might
be
able
to
go
in
if,
like
you
know,
five
or
six
of
us
are
going
in
and
we
could
do
it
together
feel
free
to
PM
me
and
also
just
go
to
the
next
meeting.
We
can
put
something
on
the
agenda
and
kind
of
continue
the
conversation
a
little
bit.
They
say
they
seem
very
open
to
that
last
week.
E
E
G
G
This
would
be
action
you're,
paying
with
four
like
seeing
if
they,
if
they're
open
to
something
like
a
like
a
depth
process,
I,
don't
even
know
what
that
acronym
would
be
or
how
to
pronounce
it.
But
if
there
is
kind
of
a
more
that
more
quickly
iterating
process
for
folks
I
know,
I've
got
people
at
Microsoft
who
would
be
more
open
to
contributing
Upstream
and
sharing
products
with
community.
In
that
way,.
A
Yeah
I
think
that's
a
really
good
point.
I
I
feel
like
there
are
definitely
people
that
that
want
to
want
to
do
that.
So
maybe
it's
just
starting
the
conversation
our
meeting
time
next
week,
8
30
Pacific,
will
be
immediately
follow
I
think
it
will
be
immediately
followed
by
the
multi-cluster
meeting.
A
So
maybe
there's
some
some
room
there
for
a
little
bit
of
overlap.
Maybe
we
can
invite
some
multi-cluster
people
to
our
call.
Vice
versa,
there's
a
ton
of
overlap
in
the
things
we're
doing
and
you
know
I
know
it's
been
hard
to
I.
Think
my
understanding
from
the
multi-cluster
people
I've
talked
with
it's.
D
Can
you
hear
me
this
time?
Okay,
yeah
I
had
to
rejoin
I
can
see
my
things
working
now,
I
had
to
rejoin
because
I'm
happy
with
myself,
but
yeah
I.
Think
Keith.
If
it
wasn't
already
said
while
I
was
rejoining,
I
would
just
go
and
put
that
right
on
their
agenda
for
the
next
meeting
and
just
bring
it
up.
I
think
that
they'd
be
I
mean
obviously
they're
the
ones
that
need
to
hear
that
right.
D
A
A
Like
you
know,
one
low
hanging
fruit,
that's
already
been
brought
up
in
Sig
multi-cluster-
is
that
currently
the
spec
or
maybe
previously
respect
required
that
you
publish
endpoint
slices
in
every
cluster
and
kind
of
propagate
them
across
and
for
somebody
that's
just
trying
to
implement
this
via
mesh
or
in
cluster
implementation.
You
probably
already
have
this
information,
but
you
don't
want
to
go
through
the
effort
of
you
know,
keeping
all
the
endpoint
building
your
own
endpoint
slice
controller.
A
That's
I
think
a
good
example
of
things
that
we
can
remove
or
simplify
and
I
know
that
specific
one
is
already
in
progress,
but
I
imagine
there
are
others
that
we're
going
to
run
into
and
the
best
way
to
run
into
them
is
by
by
trying
in
or
just
even
looking
at
the
spec
and
trying
to
gauge.
How
would
I
implement
this
and
how
painful
it
would
it
be
and
trying
to
remove
those
so
John,
you
may
have
had
some
some
things
in
mind
and
I.
I
Sense
from
from
the
psyllium's
point
of
view,
yeah,
we
don't
because
we
already
have
a
cluster
mesh
thing
and
it
does
not
use
endpoints
losses.
Also,
it's
important
at
the
moment
yeah,
the
more
that
we
can
not
have
to
worry
about
the
endpoint
slices,
the
better
off
it
will
be
the
easier
it
will
be
for
us
to
do
to
support
multicluster
API.
E
I
I
So
it
should
be
a
reasonably
straightforward
change
to
make
that
the
you
know
that
you
also
see
a
service
import
like
or
or
you
don't
see
yourself
I'm,
not
sure,
exactly
that
again:
implementation,
blah
blah
blah,
but
like
the
mechanisms,
the
mechanisms
to
do
all
of
that
stuff
are
already
there
in
psyllium
and
so
like
just
making
it
so
that
the
spare
concilium
line
up
shouldn't
be
Dart
hard.
If
you
know,
if
the,
if
the
endpoints
don't
need
to
be
included,
that
would
be
a
big
deal.
A
C
If
we
want
to
handle
this
in
the
zero
seven
release,
what
people
think
about
the
relative
priority
of
method,
HTTP
method,
matching
versus
other
attributes
and
requests
existing
PR
to
change.
It
looks
like
it's
adding
method
matching
as
the
least
significant
attribute,
I,
don't
know,
that's
what
people
agree
with
or
not,
but
yep
we're
just
calling
it
out
in
case.
You
have
opinions
and
want
to
add
it
to
the
add
to
the
discussion.
I
A
You
know
it
probably
does
make
sense
somewhere
above
where
it
is
right
now,
but
it
just
it
just
doesn't
match
with
the
rest
of
these
in
in
sentence
structure,
so
it'll
be
require
some
wordsmithing
I
guess,
but
I
I
don't
have
a
strong
opinion
on
exactly
where
it
lives.
It
does
seem
like
a
few
people
are
suggesting
between
path
match
and
header.
Match
seems
okay
to
me.
C
Yeah
conceptually
right
is
it
does
it
make
sense
to
segmented
subset
of
requests
based
on
the
method
more
significantly
than
the
header,
a
header
I?
Yes,
I,
guess,
I,
don't
know
people
do
lots
of
things
so
yeah
I,
don't
know.
If
there's
any
particular
I
mean
that
seems
like
a
valid
use
case.
I
mean
it's
a
quite
a
significant.
It's
differentiating
feature
of
HTTP
request.
A
A
I
added
a
comment
on
the
the
issue
here,
just
agreeing
with
with
what
others
have
said
that
this
really
should
belong
in
O7
I
think
it
should
be
an
071
milestone
and
I'd
love
to
see
it
get
resolved
this
week,
because
we're
aiming
to
release
071
early
next
week,
so
I
think
we're
on
track
for
that.
Just
please,
as
you're
reviewing
things
prioritize
reviewing
this
specific
PR
as
it
evolves
over
time.
A
A
A
I
know
others
who've
been
involved
in
the
conversation
are
on
this
call,
so
we
can
discuss
a
little
bit
but
I'm
just
trying
to
get
an
idea
of
where
we
can
go
next.
I
think,
Flynn
and
and
I
think
Shane
helped
with
this
proposal
as
well.
Have
you
know
good
thoughts
here
about
the
the
complexity
of
of
the
model
that
we
have
right
now,
I'm
biased
in
that
I?
A
Think
a
lot
of
these
can
be
solved
by
making
the
existing
model
more
discoverable,
but
Nick
I
think
you,
you
have
your
own
thoughts.
I
know,
there's
been
lots
of
good
useful
discussion
on
this
PR
so
definitely
encourage
others
to
comment
here.
If
you
have
your
own
thoughts,
I
think
there's
been
some
really
good,
solid
discussion
throughout,
but
yeah
maybe
I'll
hand
it
off
to
Nick
before
I
go
too
far.
I
I
Think
I
saw
Europe
by
today
Rob
that
I
think
the
the
exact
hymns
sort
of
saying
it's,
not
the
clarity,
is
sort
of
based
on
a
based
on
a
sort
of
very
specific,
like
on
the
experience
of
Jane
in
the
in
his
example,
and
you,
like
yeah
I,
think
we're
basically
saying
the
same
thing.
It's
just
a
slightly
different
way
of
saying
it.
So
I've
got
a
bit
to
clarify
that,
but
yeah
I
think
I.
Think.
I
The
key
part
here,
in
my
mind,
is
clarifying
the
discoverability
and
and
adding
some
ways
to
to
sort
of
address
the
discoverability,
the
yeah,
the
discoverability
problem.
I,
am
sort
of
writing
up
a
bit
of
a
it's,
probably
going
to
end
up
being
a
mini
game
of
its
own.
In
that
comment,
I
think
just
sort
of
running
through,
like
here's,
the
things
I
think
we
could
do
and
he's
you
know,
here's
why
we
haven't
just
done
them.
I
You
know,
and
some
of
that
probably
will
end
up
getting
folded
back
into
the
Gap
as
Alternatives
considered,
or
something
like
that.
I
think,
but
I'll
put
it
in
here
for
now,
so
that
we
can
have
the
discussion
all
in
one
place
and
yeah
I
think
that
to
broadly
broadly
summarize,
I
think
is
for
the
discoverability
of
this.
There
are
three
things
that
a
a
user
of
a
route
needs
to
know.
Personally,
they
need
to
know
that
a
policy
is
affecting
their
route.
I
That's
what
a
lot
of
the
other
things
are
for
so
I'm,
just
in
the
process
of
kind
of
explaining
that,
in
a
way
that
doesn't
sort
of
have
me
rambling
for
30
seconds
and
it's
a
bit
more
comprehensible
but
yeah.
So
I'll
put
another
thing
on
there.
Soon.
I
definitely
encourage
other
people
to
not
have
a
rating
have
rated
discussion
and
say
what
you
think
this
is
getting
it's
sort
of
starting
to
get
down
into.
You
know,
let's
argue
about
API
Machinery
territory
and
so
which
always
gets
a
little
hairy.
I
So
yeah
look
that's
one
of
the
reasons
why
this
is
complicated
is
because
we're
sort
of
doing
we're
doing
stuff
that
hasn't
been
done
a
lot
in
kubernetes
before
this
sort
of
having
a
reasonably
complicated
system
of
of
objects.
That
also
has
other
objects,
sort
of
modifying
it
is
very
complicated.
It's
all
complex,
I
think
is
a
better
way
to
say
it.
Ideally,
it
can
be
complex
without
being
complicated.
I
A
A
I
think
you
know
that
yeah,
there
are
a
variety
of
things
here.
From
my
perspective,
I
I
wish
I
wish
there
were
a
better
way
than
what
we
have,
but
I
don't
know
that,
there's
a
better
way
to
accomplish
all
the
goals
that
we
have.
That's
again,
my
own
bias
perspective
on
the
world
with
that
said,
I
do
think
it's
really
important
and
this
kind
of
comes
back
to
what
you
were
talking
about.
A
Nick
of
we
need
to
make
it
easier
to
understand,
fundamentally
that
there
is
a
policy
that
is
affecting
your
thing,
that
that
is.
You
know
that
is
key
to
everything
here
and
it's,
it's
I,
think
led
to
a
lot
of
the
frustration
that
we've
seen,
including
including
this
you
know
the
the
parabelle
the
parable
from
Flynn
in
this
Gap
was
very
well
written
and
I.
Think
a
lot
of
the
frustration
in
that
story
was
that
the
the
author
of
the
route
did
not
understand
that
policy
had
been
affecting
their
route.
A
D
F
Yeah
sorry,
okay,
yeah
I'll,
go
I,
haven't
read
all
this
stuff,
so
maybe
this
is
more
complicated
and
I.
Just
don't
have
the
contacts,
but
as
I
was
listening
to
you
talk
about
it,
it
sounded
like
this
is
something
that's
just
go
on
the
route
status
like.
If
a
policy
is
being
applied
to
a
route,
it
should
be
on
the
status.
F
I
There
there
are
reasons
of
basic
it
comes
down
to
Fair.
Now
it's
very
possible
to
have
one
policy
affect
many
Logics,
and
so,
if
you're
updating
the
status
on
every
route,
because
a
policy
got
updated,
it's
a
really
good
way
to
produce
a
lot
of
extra
load
of
the
API
server
and
historically
doing
that
sort
of
one
object.
K
Yeah
I
mean
I
I,
always
think
initially,
I
was
thinking
about
what
he
said,
but
I
think
you
know
so.
Flynn
and
I
have
talked
about
this
like
a
little
bit
in
like
previous
discussions
and
in
my
mind,
like
one
of
the
biggest
things
that
I
think
would
actually
be,
or
what's
on
my
mind
when
I
think
about
policy
attachment
is
the
the
debug
story
so
like.
K
If
I'm,
you
know
debugging
around
whether
I'm
Jane
or
whatever
fun
it
calls
the
infrastructure
engineer
manager,
you
know,
one
of
the
things
I
want
is
super
useful
to
know
is
like
having
a
full
state
of
like
how
each
of
the
resources
are
sort
of
related
to
each
other
in
terms
so
like
not.
So
it's
not
just
with
the
policy
attachments,
but
it's
also
like
with
the
browse
and
like
gateways,
and
you
know
like
which
gateways
are
being
affected
by
okay
with
classes
and
I.
K
Think
there's
a
lot
of
that
could
also
just
be
solved
by
additional
tooling.
So,
for
example
like
having
like
I
think
this
was
brought
up
in
in
the
gap
or
in
one
of
the
discussions
about
having
like
some
sort
of
control,
Plug-In
or
actually
I
would
be
I
would
even
prefer
to
be
part
of
Patrol
itself,
so
sort
of
like
you
have
like
a
control
get
you
know,
dashes
graph
option
that
basically
allows
you
to
visualize,
like
all
of
the
you
know
situation.
K
K
That
and
you
can
also
sort
of
like
chain
it
Upstream
small,
to
succeed
like
okay,
it's
part
of
this
Gateway
and
then
the
Skateway
class.
You
just
like
managing
all
these
gateways
and
things
like
that.
But
and
the
content
gets
around
like
the
sort
of
status
part,
because
now
you
only
hit
an
APS
server
when
you're
calling
it
through
the
CLI
or
some
other
way,
and
not
every
time
you
update.
You
know
your
policy
attachments
for
sure,
presumably.
D
A
Yeah,
those
are
great
points.
I.
That's
that's,
definitely
been
directionally
areas
that
I've
been
interested
in
I.
Think
there's
more
in
the
discussion
kind
of
like
you
referenced
so
there
there
is
a
an
open
discussion
on
just
like.
How
can
we
make
this
better?
Please
submit
your
ideas,
there's
some
ideas,
plenty
of
ideas
already
out
there
that
have
some
comments
on
them,
but
I
definitely
want
to
get
more
more
movement
here
and
I
think
we
already
have
a
couple:
Front
Runners,
one
of
them
like
the
route
status.
A
If
we
can
solve
fan
out
and
the
other
like
Coupe
cuddle,
control,
Cube,
cuddle,
plug-in,
hopefully
more
integrated,
maybe
included
by
default
soon.
I
don't
know,
but
yeah
yeah.
Absolutely
we
I
think
we're
all
agreeing
on
the
the
fundamental
problems
and
we
all
want
to
make
the
situation
better.
I
think
that's
yeah
100.
I
I
think
there's
just
one
one
thing
that
I
wanted
to
quickly
just
said,
which
is
another
thing.
That's
going
to
be
in
my
response,
but
I
think
one
of
the
other
metrics
that
we
need
to
have
is
that
we
need
to
try
and
keep
the
I
call
it
the
troubleshooting
distance
for
for
a
route
as
close
to
one
as
possible.
The
troubleshooting
distance
is
like
how
far
you
have
to
go
to
figure
out.
I
A
J
Yeah
I
was
going
to
talk
about
the
operational
aspect
of
testing
as
well,
so
if
it
were
intended
for
operational
things,
metrics
blogs
other
debug
tasks
as
well
as
attaching
compliance
like
policies.
Let's
say
you
had
to
some
industry
standard
compliance
that
you
wanted
to
flow
to
switch
on.
Maybe
there's
some
way
to
extend
it
for
that.
A
B
A
Yeah
that
that's
really
interesting,
yeah
and
and
I,
and
also
your
your
point
there
about
again
kind
of
on
the
observability
front.
We've
we've
been
focused
a
lot
on
the
debugging
front
with
you
know
the
the
application
developer
or
somebody
who's
really
close
to
the
infrastructure,
but
what
you're
describing
is
kind
of
the
other
view
of
this
from
from
the
top
down?
Where
are
these
policies
getting
applied
and
are
they
really
being
effective
everywhere?
I
need
them
to
be
for
compliance,
and
that's
something
you
want
to
see
via
metrics
are
similar.
A
F
E
A
These
are
really
great
I.
Please
I
encourage
everyone
I
that
that
last
one
is
like
an
area
that
I
completely
had
neglected,
I,
don't
think
anyone's
brought
anything
up
about
the
org
admin
looking
down
and
trying
to
understand
where
their
policy
was
being
applied
and
I
think
that's
really
important.
So
please,
if
you've
got
time.
If
someone
can
capture
that
in
this
discussion
as
an
idea
suggestion
whatever
would
be
great
yeah.
A
B
A
A
B
B
Tls
back
in
TLS
discussion,
and
there
are
a
couple
there
are
a
couple
of
drawbacks
like,
but
does
this
freeze
it
in
place
now
the
idea
that
it's
I
mean
I
wanted
to
see
if
there's
any
implementers
who
are
using
policy
attachment
and
experiencing
issues
with
this
I
called
it
reverse
lookup,
but
you're,
calling
it
discoverability,
basically
so
you're
pointing
to
a
bunch
of
Services,
say
you
need
to
route
to
these
services.
But
how
do
you?
B
I
Do
it
I'll
just
do
a
check
to
see
if
I've
got
a
TLS
backend
policy
that
covers
it,
so
you'll
need
to
keep
like
and
you'll
need
to
watch
them
all
and
just
see
if
the
service
that
you've
got
is
relevant
like
you
have
to
watch
both
service
and
TLS
back
in
policy
and
watch
them
against
each
other
as
part
of
the
reconciliation
process
inside
the
controller
that
doesn't
solve
the
problem.
For
you
know,
I
own
a
service
and
I
want
to
see.
B
A
A
So
that's
that's
why
I've
been
trying
to
push
for
the
and
I'm,
not
the
only
one,
but
trying
to
push
to
improve
what
what
I'm
calling
discoverability,
but
really
just
understanding
that
policy
has
affected
you
and
and
how
it
has
and
and
to
fill
in
the
other
gap
here,
I'm,
the
one
who
added
this
and
I
was
actually
I
actually
intended
it
to
be
part
of
the
discussion
around
policy.
But
it's
a
very
natural
next
step.
A
I,
think
that
where
we
may
end
up
with
this
TLS
from
Gateway
to
backend
is
a
built-in
policy.
Maybe
what
we
know
for
sure
is
that
we
need
to
extend
service.
We
need
to
say
here's
how
you
validate
TLS
connections
from
Gateway
to
this
back
end,
which
is
probably
a
service
or
service
import,
and
we
don't
have
a
great
way
to
do
that
right.
Now
that
isn't
policy
attachment,
we
could
try
and
fit
it
into
back-end
rep,
but
that
means
every
single
route.
A
Every
kind
of
reference
to
that
you
need
to
configure
it
separately,
that's
kind
of
not
great,
so
it
feels
like
kind
of
as
a
natural
follow-up
to
policy.
This
discussion
around
TLS
from
Gateway
to
backend,
May
kind
of
just
force
our
hand
of
really
making
us
ensure
that
what
whatever
we
have
here
works
well,
so
that's
that's
kind
of
why
I
added
this,
where
I
did
but
I
yeah.