►
From YouTube: SIG Network Gateway API meeting for 20230925
Description
SIG Network Gateway API meeting for 20230925
A
All
right
welcome
to
the
Gateway
API
meeting
for
September
25
wow
time
is
moving
quickly.
This
is
a
standard,
kubernetes
meeting,
a
community
meeting.
That
means
we
abide
by
the
kubernetes
code
of
conduct
at
a
high
level.
This
just
been
means
to
be
nice
to
each
other.
A
couple
notes
really
encourage
people
to
definitely
take
some
time
to
comment
on
anything.
A
A
I,
don't
see
any
oh,
maybe
if,
if
anyone
is
new
or
hasn't
had
a
chance
to
introduce
themselves
yet
give
just
a
minute
or
so
for
someone
to
introduce
themselves
if
they
want
to
no
pressure
at
all,
but
we
do
like
to
hear
what
brings
people
to
this
meeting
and
what
their
interest
in
Gateway
apis.
A
Okay,
so
I'll
just
keep
on
moving
here
at
the
first
thing.
Up
on
the
agenda
is
really
quick.
This
is
I,
think
the
third
time
we're
doing
this
now,
but
the
first
meeting
of
every
month
is
going
to
be
an
earlier
time
slot
to
better
accommodate
people,
east
of
the
West
Coast,
so
in
the
US,
so
that
includes
other
continents
such
as
Europe
and
in
Africa,
as
well
as
even
just
the
U.S
east
coast
and
others
better.
A
Okay,
next
up
is
a
discussion
point
that
I
think
gained
a
lot
of
steam
in
last
week's
meeting,
and
this
was
all
about
listener,
isolation
or
cascading
Behavior.
We
found
in
the
spec
that,
although
we
made
assumptions
about
how
we
thought
this
would
work
they,
those
assumptions
were
not
clearly
written
in
the
spec,
which
is
very
very
unfortunate,
and
not
only
were
they
not
clearly
written
in
the
spec.
They
were
not
clearly
described
in
conformance
tests
either.
A
So
there
were
a
lot
of
assumptions
that
were
made
here
that,
unfortunately,
not
everyone,
not
every
implementation,
matched
perfectly
so
the
implementations
of
Gateway
API
roughly
fall
into
two
categories
today,
and
that
is
that
listeners
are
isolated.
So
once
you
pick
a
listener,
you
only
get
forwarded
to
back
ends
attached
to
that.
You
know
attached
to
routes
attached
to
that
listener
or
cascading
Behavior,
which
means
that
if
there's
no
match
on
the
current
listener,
you
might
Cascade
to
a
different
listener.
A
The
cascading
behavior
is
particularly
problematic
when
it
comes
to
TLS,
among
other
things,
and
just
having
inconsistency
here
is
not
good
for
the
Gateway
API
ecosystem
as
a
whole,
because
one
of
our
big
value
propositions
is
consistency
across
the
ecosystem,
so
I
think
everyone
is
is
hopefully
I'm
not
misrepresenting
here,
but
I
think
many.
Maybe
most
people
want
to
see
the
community
move
towards
a
model
of
listener,
isolation
where
a
single
listener
is
selected
and
and
then
from
there
only
routes
attached
to
that
listener
are
chosen.
A
So
there's
a
fair
amount
of
discussion
here.
Nick
gave
a
great
introduction
to
this
Shane
added
some
comments.
Shane
Nick
and
myself
met
a
few
days
ago
to
discuss
this
in
more
detail,
and
we
have
a
proposal
here,
but
I
know
everyone
has
has
different
opinions,
so
I
just
want
to
again
show
The
Proposal
that
we
think
will
work
for
most.
Hopefully
everyone
here
and
that
is
to
add
a
new
Gateway
listener.
Isolation
extended
feature
along
with
conformance
tests
that
will
describe
the
ideal
state
that
we
want
everyone
to
work
towards.
A
We
think
that
some
new
features,
particularly
clients,
cert
validation,
which
Arco
has
proposed,
are
likely
going
to
require
support
for
listener
isolation
because
without
listener
isolation
you
could
effectively
bypass
client
search
validation,
which
is
just
not
a
good
thing.
Yeah
so
need
to
be
very,
very
careful
there,
but
the
other
thing
is
we
really
don't
want
to
leave
anyone
behind,
although
I
think
we
all
had
a
very
well
maintainers
had
had
a
clear
idea
of
how
how
we
wanted
this
to
to
work.
It
was
not
clearly
written
down.
A
It
was
not
there.
There
were
a
bunch
of
missteps
here,
so
that
is
why
this
is
not.
You
know
intended
to
be
a
a
breaking
change
where
everyone
has
to
move
before
we
won.
This
is
intended
to
be
a
directional
change,
where
we
want
to
encourage
people
to
move
as
quickly
as
reasonably
possible
to
this
approach
so
that
we
can
make
this
a
core
and
required
feature
in
the
future,
but
we
recognize
that
it
will
take
some
time
for
people
to
make
this
transition,
so
we
need.
A
We
need
a
way
to
represent
the
two
different
states
while
they
exist,
while
also
encouraging
people
to
move
as
quickly
as
possible.
To
this
any
any
comments
or
questions
on
this
approach
concerns
anything.
A
Yeah
I
recognize
this
could
affect
some
implementations
more
than
others.
So
please
take
some
time
think
about
this.
If
you're
already
in
Camp
listener
isolation,
this
should
be
a
no-op
for
you.
If
you
are
not
there
yet,
please,
you
know.
Take
some
time
comment.
Etc
I
would
be
great
to
hear
from
you.
B
I
think
it
is
important
to
to
call
out
that
yeah
this,
that
it's
really
important
to
emphasize
sorry
that
we
want
to
make.
We
want
to
make
sure
everyone
understands
that
we
will
be
moving
this
to
core
at
some
point
in
the
future
like
like
we
do.
We
don't
want
this
sort
of
distinction
between
unisolated
business
and
isolated
listeners
to
stick
around
forever.
B
All
right,
Michael
asks
in
the
chat.
Are:
is
it
possible
to
implement
listener
isolation
with
intersecting
list?
No
Hearst
name
fields?
Yes,
so
the
intent
here
is
what
we
intended
originally,
which
is
that
if
the
hostname
feels
intersect,
you
pick
one
based
on
the
existing
close
name,
sort
of
distinctiveness
rules
right
and
then
once
one
was
picked,
that's
that's
it.
You
can't
match
more
than
one.
So
the
the
most
common
case
here
is
that
you
have
a
precise
hostname
and
a
wild
wild
card
hostname
in
two
separate
listener.
B
Fields
and
the
rules
say,
and
the
intent
is
that
if
you
have
that
case,
the
precise
hostname
listing
matches
before
the
wildcard
listener-
and
you
can't
sort
of
where
this
has
come
up-
is
that
when
sometimes
people
have,
you
know
a
precise
match
with
you
know,
parfou
and
a
wild
card
match
with
path
bar
and
the.
B
If
you
go
to
the
precise
match,
part
bar,
you
should
get
a
404
with
listener
isolation,
because
you've
matched
the
precise
match,
and
then
there
is
no
powerful
bar
in
the
routes
attached
to
the
precise
match.
You
should
not
be
able
to
sort
of
back
out
to
The
Listener
and
pick
a
different
host
name
and
pick
a
different
set
of
routes
attached
to
the
the
star
listener.
B
This
is
also
complicated
further
by
the
fact
that
there's
another
layer
of
sort
of
hostname
definition
in
the
in
The
Listener
and
Route
hostname
distinction,
but
again
the
intent
here-
is
that
the
listener
and
Route
hostname
sort
of
interaction
is
really
about
routes
being
able
to
match,
with
particular
listeners
on
the
Gateway.
B
So
if
you
have
a
star
a
wild
card
listener
on
the
a
wild
card
hostname
on
The
Listener
and
a
precise
hostname
on
the
route,
then
the
route
will
attach
to
the
precise
to
the
precise
to
the
wild
card.
There's.
No.
If
you
have
a
precise
hostname
on
The
Listener
and
a
wildcard
host
number
on
the
route,
then
the
route
will
attach
to
the
precise
listener.
B
If
you
have
a
wild
card
host
number,
both
then
they'll
both
attach
you
who
have
different
precise
host
names
on
both,
then
the
route
will
not
attach
to
that
list
not,
and
so
the
the
thing
that's
important
here
is
what
happens
when
you've
got
different
host
names.
B
Sorry
distinct
values
for
host
names
on
The
Listener,
regardless
of
whether
or
not
they
intersect
in
terms
of
being
precise
or
wild
card
now
so
I
mean
have
another
read
of
the
I
tried
to
explain
this
as
well
as
I
could
in
the
initial
comment
in
the
initial
sort
of
opening
post
yeah.
B
So
but
yeah
have
a
look
through
that
and
if
anything
is
unclear,
please
ask
on
that,
but
I
think
yeah,
a
careful
read
there
should
should
explain
a
bit
more
and
thank
you
for
the
example
Michael.
Well
that
really
helped
me
to
sort
of
make
this
more
clear.
Candace.
B
C
Probably
I
don't
know
exactly
the
different
ways
that
that
connection
coalescing
connection
coalescing
happens,
but
it's
something
that
I
want
to
learn
more
about.
B
Yeah,
so
yes,
the
in
the
this
config
is
kind
of
intended
to
represent
how
traffic
is
routed
once
it
gets
to
the
Gateway.
B
If
the
Gateway
is
allowing
sort
of
coalescing
of
HTTP
connections
for
separate
hosts
under
a
single
listener,
there
is
actually
another
issue
open
about
making
Sni
and
hostname
making
sure
that
S9
has
no
match,
which
again
is
very
important
for
yeah
thanks
Rob
this
one,
which
is
very
important
for
when
you
start
adding
client
certificates.
B
But
again
it
is
John
pointed
out,
and
thanks
to
thanks
for
pointing
this
out,
John
that
you
know,
yeah,
we've
got
a
remember
about
41
status
code
connection,
coalescing
and
some
and
and
a
couple
of
other
things
so
it'll
make
writing
this
a
little
bit
more
complicated,
as
is
always
the
case
when
it
comes
to
TLS,
and
so
yes,
so
yes,
we
do
need
to
take
that
into
account.
B
But
I
don't
think
that
the
listener
matching
semantics
that
we're
talking
about
in
2416
will
have
too
much
of
an
impact.
This
is
the
thing
that
will
have
an
impact
on
connection
I,
hope.
C
A
Yeah
I
think
we
can
come
back
to
this
specific
issue
in
triage,
but
yeah
this.
These
two
are
very
very
closely
related
any
additional
comments
or
questions
on
this
one.
A
Well,
I.
Well,
thank
you
for
the
feedback.
Thank
you
to
there's
there's
been,
although
this
issue
is
fairly
isolated,
this
is
coming
out
of
a
larger
discussion
that
I
know
many
people
were
involved
in.
So
thank
you
both.
Thank
you.
Everyone
for
for
being
involved
in
this
and
helping
us
come
to
some
kind
of
conclusion
here,
but
again
would
be.
I
would
would
appreciate
any
additional
feedback
here
before
we
move
forward.
I
expect
that
this
doesn't
sound
like
we're.
A
Gonna
have
to
move
forward
with
this
week,
given
our
timeline
for
release
and
and
all
the
rest.
A
Michael
asks
again:
is
there
an
implementation
that
does
both
things
correctly
I
think
there
are
some
Envoy
based
implementations
that
handle
this
handle
listener,
isolation,
the
way
that
we
are
expecting
here,
I,
don't
want
to
name
names
and
be
wrong
here,
but
I
believe
istio
and
Envoy
Gateway
May
both
be
matching
the
behavior
described
here
as
listener
isolation,
but
someone
can
correct
me
if
I'm
wrong
there.
B
Yeah
I
haven't
had
a
chance
to
test
either,
but
but
my
understanding
is
there's
a
possibly
Contour.
Although
I
can't
remember
whether
we
did
something
similar
for
hdb
proxy,
but
I
can't
remember
if
that
has
been
ported
to
get
it
going
or
not.
A
And
we
do
have
some
awareness
that
this
is
at
least
possible
in
nginx,
but
I,
don't
believe
any
nginx
based
implementations
are
doing
this
right
now.
A
A
I'll,
keep
on
moving,
don't
hesitate
to
bring
up
any
additional
comments.
Concerns
as
we
go
here.
We
can
come
back
to
this
one
next
up,
v1.0
is
coming
awfully
quickly,
so
let
me
just
run
through
release
blockers
real
quick
you're,
starting
to
notice
that,
although
the
number
is
not
changing
it's
because
we
have
a
lot
of
these
showing
up
as
PRS
that
are
addressing
the
issues
and
I
I
feel
fairly
good
about
where
we
are
at
this
point,
yeah
and
I'm
not
seeing
a
lot.
A
I
think
I
think
what
we
had
I
identified
as
our
biggest
concern
is
that
issue
that
we
just
discussed
and
as
long
as
we're.
Okay,
with
the
approach
that
that
we
proposed
here,
we
should
be
able
to
fit
this
one
in.
D
A
Cool
and
we
are
targeting
so
for
those
of
you
who
have
been
around
Gateway
API
for
a
while,
we
go.
We
kick
off
API
review
before
we
do
any
release
any
kind
of
minor
or
major
release,
and
that
means
talking
to
Signet
tech
leads
and
API
reviewers.
A
This
time,
we're
planning
to
start
that
process
next
week,
we're
trying
to
get
everyone
lined
up
in
terms
of
availability,
but
right
now,
that's
looking
like
maybe
October,
4
or
so
mid
to
mid
to
end
late
next
week
is
when
we
hope
to
see
that
process
begin,
which
means
we're
really
trying
to
be
code
complete
before
then
at
least
as
far
as
any
API
changes
documentation
and
such
can
continue
to
take
some
time,
but
that
means
we've
got
a
lot
to
get
in
in
a
fairly
short
window
here.
A
Foreign
next
up
is
there's
some
more
logo
options.
Some
of
you
may
have
already
seen
this
already.
This
is
continuing
on
the
existing
issue
here,
but
Pierre
Louis
actually
trying
the
last
community
meeting.
It
came
up
with
a
sketch
that
I
thought
was
particularly
clever,
so
I,
actually
I,
reached
out
to
Lauren,
who
ended
up
coming
up
with
some
designs
based
on
Pierre
Louis
sketch
and
they
are
outlined
below
in
this
issue.
I
would
really
appreciate
some
feedback
here.
A
You
know
we
are
trying
to
have
options
that
we
can
vote
on
by
the
end
of
the
month,
but
we're
also
trying
to
not
overwhelm
everyone
with
10
different
options
to
vote
from,
or
something
like
that.
A
So
if
you
can
help
narrow
down
which
one
of
these,
or
which
couple
of
these
we
add
to
the
list
to
vote
from,
that
would
be
great,
but
right
now
we're
just
I'm
just
encouraging
some
Emoji
Style
voting
here
and
if
you
have
any
comments
or
other
ideas,
feel
free
to
add
them
as
comments,
and
also
really
really
appreciate.
If
you
have
any
other
ideas,
you
know.
Other
suggestions
are
welcome
here
too,
but
yeah
just
a
few
more
options
to
consider
for
Gateway,
API,
I.
A
I
didn't
add
this
in
the
comment,
but
the
the
high
level
idea
that
Pierre
Louis
had
here
was
to
show
that
Gateway
API
was
not
just
North
South
traffic,
but
also
East-West,
and
that's
why
you
get
you
know
I
think
maybe
it's
clearest
in
this
orientation,
but
in
either
one
you're
trying
to
show
that
traffic
is
both
going.
I
mean
I
guess
this
is
not
exactly
east
west,
but
the
idea
is
both
north
south
and
east
west
and
maybe
a
Gateway
in
the
middle,
depending
on
your
perspective,
yeah,
so
comments
feedback.
D
A
Yeah
is
I
added
this
again
to
handle
another
release:
blocker
there's
a
partially
invalid
condition,
I'm
proposing
to
add
to
routes-
and
this
is
something
we've
been
circling
around
for
an
awfully
long
time,
but
it
is
to
figure
out
what
to
do
when
you
have
a
single
or
a
you
know
a
set
of
Route
rules
that
are
invalid
within
a
route,
but
you
still
have
other
route
rules
that
are
valid,
so
some
kind
of
mixed
state
for
a
route
which
is
really
tricky
to
handle
in
Gateway
API
today,
I
am
proposed.
A
There's
been
an
issue
where
there
was
some
discussion
around
this
and
we
kind
of
again
went
around
a
few
different
ideas
here.
I've
proposed
an
option
here.
I
would
really
appreciate
feedback
on
this
because
again,
this
is
another
thing
we're
trying
to
get
it
in
in
the
next
week
or
so,
but
at
a
high
level
I'm
proposing
that
that
we
actually
allowed
two
different
kinds
of
behavior
here.
A
A
This
is
particularly
useful
for
implementations
that
cannot
handle
do
not
have
state
right,
so
you
don't
want
to
use
the
other
approach,
which
would
be
a
fallback
to
last
known,
good
State,
because
if
your
implementation,
for
any
reason
restarts,
gets
updated
Etc
you
lose
that
and
then
you
break
at
a
future
point
in
time
which
may
be
less
predictable
Etc.
A
A
But
this
is
a
little
unconventional
in
that
we're
providing
two
possible
ways
to
handle
a
invalid
state
and
not
just
that.
I
also,
don't
think
that
we
can
write
conformance
tests
for
this,
because
the
only
paths
I
can
think
of
to
get
to
an
invalid
state
are
fairly
implementation.
Specific,
you
know,
specifically
an
unsupported
value
or
unsupported
feature,
which
is
again.
D
A
To
be
very
implementation
specific
or
it
would
be
blocked
by
our
validation
or
some
subset
of
that,
so
this
is
really
intended,
primarily
just
to
be
a
set
of
guidelines
for
two
different
ways
you
can
handle
this
state
which,
although
it's
not
just
a
single
way,
I
think
it
is
preferable
to
have
some
guidelines
on
how
you
can
handle
this.
B
So
I
I
must
admit
to
feeling
a
little
bit
uncomfortable
about
the
sort
of
the
the
last
new
good
State
I've
talked
about
that
before,
but
this
is
about
as
good
a
way
to
handle
the
handle
both
possibilities,
as
I
can
think
of
so
I'm.
Fine
with
this.
A
Yeah,
in
my
opinion,
I
think
last
known.
Good
status
is
really
best
used
for
implementations
that
one
have
a
means
of
restoring
the
state
through
transitions,
State
transitions,
but
then
two
especially
useful
for
implementations,
where
it
may
take
a
protect,
protracted
period
of
time
to
restore
you
know,
to
transition
between
good
and
bad
config,
all
right.
So
if
you're
going
to
drop
a
rule
and
then
it
takes
a
couple
minutes
to
restore
that
rule,
that's
a
very
different
story
than
if
it's
going
to
take
two
seconds
to
restore
that
rule.
E
So
one
issue,
potentially
with
the
last
known
good
status,
you
might
have
an
an
audit
log
that
does
not
align
with
what
is
actually
happening
on
the
system
unless
we
have
some
directive
to
say
that
when
it
falls
back,
it
emits
an
equally
strong
or
true
audit
log
or
signature.
Oh.
B
Yeah,
that's
that's
the
idea
behind
having
these
these
conditions
is
so
that
these
conditions
are
effectively
the
audit
logo,
signature
yeah.
So,
like
part
of
again,
this
is
something
that
we
haven't
explicitly
said
in
enough
places,
but
part
of
the
contract.
That's
expected
for
for
gamer,
API
implementations
and
get
API
users
is
that
the
conditions
on
various
objects
are
important
and
you
must
monitor
them.
B
So
watch
for
changes.
Take
action
like
you
know,
and
look
for
changes
and
stuff
like
that.
I'm.
Actually,
writing
like
an
implementer's
guide
that
is
going
to
be
in
addition
to
the
spec
that
will
sort
of
make
some
of
these
things
a
little
bit
more
clear
with
the
intent
being
that
eventually,
we'll
have
a
more
solid
user's
guide.
That
tells
you
things
like
hey.
You
need
to
watch
the
conditions
for
the
various
objects.
A
Yeah
and
I
and
I
would
say
that
that
this
is
a
very
unique
is
so
far.
Every
implementation
is
doing
something
for
this,
but
there's
no
standardized
way
to
report
this,
so
every
implementation
is
doing
their
own
thing.
What
we're
trying
to
accomplish
here
is
is
somewhat
unique
in
that
we're
we're
trying
to
add
a
new
condition
and
require
you
know,
require
every
implementation
to
set
this
condition
so
that
hopefully
any
plug-in
any
dashboard.
A
Any
anything
that
consumes
Gateway
API
has
a
standardized
way
of
recognizing
there's
a
problem
here,
and
it
falls
into
this
category
of
problems
and
I
can
alert
based
on
that
right.
So
whatever
implementation
you're
using
this
provides
some
kind
of
portable
feedback
that
there
is
a
problem,
and
this
is
what
it
is
so
yeah.
This
is
trying
to
address
that
very
specific
State
and
I
and
I
agree
that
you
know
both
fall
back
and
dropping
it.
Neither
are
great
you
know.
A
I
I
would
I
would
say
that
dropping
immediately
is
is
pretty
hostile
in
its
own
state,
but
I
at
least
the
failure
happens
closest
to
when
the
configuration
happens
so
someone's
paying
attention.
That
knows
what
they
did
and
knows
what
triggered
it.
Hopefully
fallback
is,
you
know
a
little
bit
friendlier
to
to
customers
potentially
at
the
cost
of
it
may
not
be
obvious
for
them
that
something
broke.
So
you
need
to
be
very
good
at
bubbling
this
this
up
and
and
surfacing
that
to
your
users.
B
Michael
Austin
chat
is
this
the
first
time
we
prescribed
it.
A
message
has
to
start
with
the
prefix,
and
does
this
mean
that
messages
are
now
part
of
the
API
and
I
said
yes
and
yes,
it's
an
all.
I
do
but
again
nothing
about
this.
Particular
situation
is
ideal.
B
You
know,
I
would
much
prefer
that
messages
are
like
GO
error
messages
in
that
you
can't
make
any
statements
about
them,
but
in
this
case,
unless
we
change
the
condition
struct
to
have
like
some
other
field
that
like
and
which
I've
tried
before-
and
it
didn't
work
out-
you
know,
but
this
is
the
the
best
option
we
have.
A
Yeah
yeah,
so
I
I
would
say
this
is
not
ideal.
I,
don't
love
any
I.
Don't
love
this,
but
I
I
feel
like
it's
very
important
for
this
API
to
have
a
standard,
a
standardized
way
to
represent
these
partially
valid
States,
because
right
now
every
implementation
I'm
aware
of
is
handling
this
in
some
kind
of
inconsistent
way
and
we
need
we
need.
You
know
shared
tooling,
common,
tooling,
to
be
able
to
understand
and
alert
or
warn
based
on
this
date.
B
No,
you
always
I
was
just
gonna,
say
Travis
suggested
in
chat
as
well.
Could
we
add
a
this
makes
the
rule
fail?
This
makes
the
rule
a
valid
filter
and
then
use
that
as
a
way
to
test
this.
It
kind
of
makes
sense.
I
guess
it
might
be
a
good
way
to
do
that,
and
actually
having
that
sort
of
having
that
sort
of
filter
available
is
actually
not
that
bad.
An
idea.
A
A
Okay,
so
that
is
2429
feedback
very
welcome
and
appreciated
on
this.
One
would
also
be
helpful
to
know
I
I
think
many,
if
not
most,
implementations
fall
into
bucket
one
right
now,
but
it
would
be
interesting
to
hear
if
you
fall
into
neither
of
these
buckets
right
now
and
if
there's
some
other
category
that
that
we're
missing
here.
A
Cool
all
right
with
that
gaurav
has
a
very
cool
PR
to
add
Gateway
cuddle
to
the
Gateway
API,
repo,
no
pressure,
but
do
you
have
anything
you
can
download?
Are
you
on
this
call.
D
C
A
So
while
all
gov
is
starting
us
up,
this
has
been
something
that
you've
probably
seen
in
Pre
at
least
one
previous
meeting.
But
Gateway
cuddle
is
really
trying
to
fill
the
gaps
of
both
policy
attachment
and
the
limitations
of
cube
cuddle.
When
it
comes
to
interacting
with
crds
with
Upstream
kubernetes
apis,
you
can
Define
all
kinds
of
custom
Logic
for
Coupe
cuddle.
You
can't
with
crds
and
gaurav
has
done
some
awesome
work
here
to
fill
a
lot
of
gaps
and
I'm.
A
This
is
actually
the
first
time
I'll
see
this
demo,
so
I'm
excited
to
see
what
it
looks
like.
F
F
So,
as
we
know,
policies
can
be
attached
to
resources
like
Gateway
class
gate
base,
name
spaces,
and
if
it's
an
inherited
policy,
then
it
could
affect
all
the
sub
resources
within
that.
So
one
of
the
first
things
is
that
you
should,
when
you
list
all
policies,
you
will
be
able
to
see
whether
a
policy
is
inherited
or
if
it's
directly
attached
policy.
F
F
F
F
Effective
policy
basically
means.
If
there's
multiple
policies
of
similar
kind
attached
on
any
place
in
the
hierarchy,
then
we
should
be
able
to
kind
of
calculate
the
effective
or
figure
out
which
Fields
take
precedence
over
the
others.
For
example,
in
this
case,
timeout
policy
was
attached
to
both
the
Gateway
and
the
namespace,
so
that
that
is
why
you
can
see
that
some
fees
would
deny
from
the
parent
some
Fields
would
derive
from
the
child.
F
If
the
HTTP
route
is
attached
to
multiple
gateways,
then
you
will
be
able
to
see
effective
policies
for
each
particular
Gateway,
so
the
effective
policies
are
currently
by
which
Gateway
you're,
referring
to,
in
addition
to
http
routes,
we
have
support
for
some
more
resources
like
backends
right
now.
F
F
So
what
this
will
do
is
it
will
list
all
backends
which
are
of
this
particular
kind
right
now,
I'm,
assuming
that
a
Gateway
is
kind
of
packing,
and
in
this
case
it
will
show
you
it
will
treat
this
Resource
as
a
backend
and
again
calculate
the
effective
policy
for
it.
In
this
case,
it
wasn't
able
to
kind
of
figure.
F
So
since
no
HTTP
route
was
referencing,
this
particular
kind
of
backend-
you
don't
see
any
effective
policies,
there's
only
directly
attached
policies
to
this
particular
resource
and
yeah
I
think
that
that's
it
mostly
there's
been
changes
and
advancements
on
calculating
the
effective
policy
since
last
time.
Any
questions,
thoughts,
comments
are
welcomed.
B
Wow
that
looks
awesome
as
much
of
us
no
seriously
yeah
I
think
yeah.
It
just
looks
really
cool
yeah
that
that
effective
policies
looks
very
much
like
what
I
can
what
I
talked
about
on
the
on
things,
so
yeah
just
nice
work
great
work,
that's
great.
A
Yeah
I
I'm
really
excited
about
really
excited
about
this
I
I
can't
wait,
I
think
Gateway
cuddle
is
soon
going
to
be
the
default
way.
People
interact
with
Gateway
API,
which
I
think
is
just
going
to
make
the
experience
that
much
better,
even
even
without
policy.
You've
already
provided
some
great
improvements
and
then
adding
policy
on
top
I
think
it's
going
to
be
a
great
win
and
we
can
only
we
can
only
expand
from
here.
So
yeah,
thanks
for
thanks
for
driving
this
forward.
A
B
Guess
so
is
the
question
that
you
are
also
asking
here
like
should,
should
we
look
at
moving
this
into
the
repo.
F
So
yes,
right
now,
I
think
it
has
reached
that
stage
where
I
feel
confident
that
okay,
it
can
be
moved,
but
it's
totally
up
to
you,
the
reviewers.
Please
take
a
look
whenever
you
get
some
time
at
the
pr
and
see
if
there's
any
changes
that
you'd
like
and
definitely
I
need
to
add
some
more
tests.
I
have
added
some
tests,
but
yes,
definitely
that
area
can
that
area
needs
some
improvement
or
not.
It
can
always
need
Improvement,
yeah.
A
Yeah
I
think
the
the
idea
right
now
is
that
this
this
plug-in
Gateway
cuddle
is,
is
something
that
is
critical
for
Gateway
API
usage,
ux
Etc,
and
we
want
it
to
be
bundled
with
Gateway
API
release
with
that
said,
I
think
that
we
need
to
have
different.
You
know
different
sets
of
dependencies,
so
this
comes
in
with
a
different
go
dot,
mod
Etc,
so
we're
not
adding
dependencies
that
every
implementation
needs
to
fight
with
and
I
think.
We
would
also
class
this
as
experimental
Channel
I.
A
You
know
we
don't
really
have
channels
per
se
with
this
is
a
New
Concept,
but
we
want
to
be
clear
that
this
is
not
a
ga
product
in
the
first
release.
This
is
just
experimental.
It
will
continue
to
grow
and
evolve,
but
I
think
it
is
important
for
it
to
live
alongside
the
rest
of
Gateway
because
as
new
Gateway
features
come
in
I'd
love
to
see
them
added
immediately.
To
to
this
as
well
yeah
great
great
work,
I'm
I
can't
wait
to
see
this
one
come
through.
A
I
think
this
is
going
to
be
a
huge
win
for
for
everyone.
A
All
right,
hopefully,
I'm
gonna
share
the
right
thing
again
did
I
share
the
wrong.
What
did
I
share?
A
Yeah
sweet,
highly
secretive?
Maybe
this
one
looks
better
all
right:
okay,
cool
with
that
I
think
we're
just
about
done.
We're
at
triage
now,
so
first
up
I
wanted
to
make
sure
we
had
time
to
to
get
back
into
this
discussion
a
little
bit
more
Nick
I,
don't
know
if
you
have
more
to
say
on
this
one
or
if
we
just
just
follow
up
offline,
but
it's
it's
a
pretty
big
topic.
A
I
I
personally
am
of
the
mind
that
I
don't
know
that
we
can
add
this
restriction
to
to
Gateway
API
I
I
think
it's
gonna
be
really
complicated
at
a
minimum
and
there's
so
many
you
know
like
because
rfcs
don't
require
it.
It
yeah
I,
don't
know.
B
I
mean
it
could
be,
it
could
be
that
this
is
another
one
where
we
need
to
have
an
extended
feature
that
that
we
probably
would
suggest
that
most
people
have
on
but
yeah
as
as
John
said,
we
also
like
the
the
initial
rule.
I've
got,
there
definitely
needs
rewriting
to
handle
four
two
ones:
connection
coalescing
and
some
other,
and
some
other
stuff
like
that.
B
B
You
know,
if
you're,
if
your
rule
set,
is
rendered
as
a
set
of
Sni
matches
and
a
set
of
hostname
matches
you,
it
is
possible
like
and
there's
sort
of
no
link
between
them
and
there's
no
sort
of
you
you're.
Not
you
don't
subdivide
the
set
of
hostname
matches
based
on
the
Sni.
B
Then
then
you
can.
It
can
make
it
easier
to
do
sort
of
swinging
between
back
ends,
kinds
of
things
and
ignoring
the
front-end
part
I.
Think
once
you
once
you
once
we
are
sort
of
pushing
for
listen
isolation
more.
It
becomes
much
harder
because
then
your
rules
should
be
written
in
such
a
fashion
that
that
any
domain
fronting
you
do
will
only
be
to
other.
B
You
will
be
limited
because
of
the
way
the
list
and
isolation
works,
but
it
is
still.
It
is
still
important
for
us
to
talk
about
this
at
some
point.
I
think
so
it's
not
I,
don't
think
this
one's
a
ga
blocker,
especially
if
we,
if
we
once
we
do
the
listener
isolation.
What
we
do
need
to
think
about
it
and
talk
about
it
at
some
point.
A
Yeah
yeah
I
agree
with
everything
you
said:
I
think
that
this
is
not
GA
blocking
it's
a
it's
something
that
we
can
talk
about
in
more
detail
later
on
and
I
I'm
really
hopeful
that
listener
isolation
will
resolve
a
lot
of
the
major
concerns
here.
I'd
recognize.
You
know
this
is
not
everything
but
I
think
we
need
to
be
very,
very,
very
careful
about
anything
like
this
and
make
sure
we've
we've
got
it
through
properly,
because
you
know
getting
going
above
and
beyond.
What
is
restricted
elsewhere
can
be
challenging.
A
Yeah,
okay,
I!
Think!
That's
all
for
that.
One
then,
and
then
back
in
protocol
I
think
this
is
Dave's
right,
yeah,
yeah,.
A
D
Okay,
yeah
I
think
I
dressed
everything
I
think
Nick
for
you.
It's
I've
done
a
bit
of
changes
based
on
Rob's
feedback
to
simplify
I,
think
the
table
and
marked
a
bunch
of
stuff.
A
Well,
yeah
I
think
this
is
really
really
close.
I
have
no
issue
with
this
one.
You
know
what
this
one
getting
in
there's.
Also
this.
This
is
one
Gap
that
I
I
think
is
on
Pace
to
make
it
again
pending
feedback
from
Nick,
but
this
one
feels
really
close
and
it
it
basically
amounts
to
here
are
here's
app
protocol
and
here's
how
you
should
use
it
roughly?
Maybe
that's
a
an
oversimplification
of
the
Gap
but
I
think
it's
good
to
have
this
specified
I,
don't
think
we
actually
need
do.
A
In
like
back
end
reference,
maybe
yeah.
B
A
And
one
other
thing,
while
I'm
thinking
about
gaps
that
are
right
on
the
verge
of
getting
in
Sean,
has
one
for
in
cluster
gateways
that
has
been
approved.
There's
one
pending
comment
on
it,
but
I
think
once
that
comment
is
resolved,
they
can
merge
and
that
one
would
also
be
good
to
get
in.
A
Think
you
posted
that
in
the
header
for
the
next
meeting
Robert,
and
that
was
not
me
but
I
can
try
and
follow
where
it's
going,
yeah.
Okay,
that's
the
same
one,
all
right,
okay,
so
I
think
that's
all
that
I'm
aware
of
anyone
want
to
add
any
last
last
minute
things
to
the
agenda.
I
think
that's
the
one
we
just
discussed
right.
D
A
Well,
thank
you,
everyone
for
the
great
discussion.
Oh
there's,
one
more
triage
item.
Okay,
whoever
is
typing
that
feel
free
to
to
bring
it
up
or
I
can
follow
a
link
in
the
agenda.
A
I
I
choose
not
to
follow
perfect.
That
may
be
the
first
time
this.
This
meeting
got
Rick
Rolled
well
done,
but
anyways,
yes,
have
a
have
a
good
rest
of
your
week.
Thank
you.
Everyone
for
the
great
great
discussion
today
I,
remember
we're
basically
10
days
out
from
starting
the
review
process
for
1.0,
which
means
everything
really
needs
to
get
in
in
the
next
week.
A
So
if
it,
if
you're
not
getting
reviews-
and
you
want
reviews-
please
ping-
whoever
needs
to
be
reviewing
your
code
and
you
know
don't
hesitate
to
ping
me
personally
if,
if
I
can
help
get
people
reviewing
or
if
I
can
review
myself,
but
we
do
want
to
make
sure
that
we
can
get
what
we
had
prioritized
as
1.0
into
1.0
with
that
I
think
we're
we're
at
time.
So
thanks
everyone
for
the
discussion.