►
From YouTube: SIG Network Gateway API meeting for 20230508
Description
SIG Network Gateway API meeting for 20230508
A
All
right
welcome
to
the
Gateway
API
meeting
for
May,
8th
2023.
We've
got
pretty
good
agenda
today,
please,
as
always,
take
some
time
to
fill
your
name
in
the
attendees
list
and
just
a
quick
reminder.
This
is
a
kubernetes
meeting,
which
means
it
applied
with
a
cncf.
Code
of
conduct
applies
at
a
very
high
level.
That
just
means
to
be
nice
to
each
other.
A
It
also
means
that,
at
least
in
the
case
of
Gateway
API,
that
this
agenda
is
intended
to
be
open
to
anybody,
so
I
think,
especially
with
Shane
not
able
to
make
it
and
present.
Today
we
have
some
extra
time.
So
if
you
have
the
capability
or
something
you
want
to
discuss,
please
don't
hesitate,
especially
triage.
A
If
there's
some
PRS
that
we
haven't
been
getting
to
which
I
would
believe
because
our
PR
list
is
longer
than
I'd
like
to
admit-
please
don't
hesitate
to
add
the
add
it
to
the
triage
section
and
we'll
make
sure
we
go
through
it
today,
all
right
so
with
that
first
up,
our
next
meeting
time
already
covered,
but
for
anyone
who
just
joined
next
meeting
is
more
Europe
and
East
Coast
friendly
time
slot.
A
So
I
should
be
updated
on
the
Sig
Network
calendar,
if
you're,
not
in
the,
if
you're,
not
getting,
those
invites
I
suggest
subscribing
to
the
kubernetes
sign
Network
mailing
list,
and
then
you
should
automatically
get
invites
for
these
events
but
in
any
case
we're
looking
at
Tuesday,
Morning
Pacific
time
and
afternoon
evening
at
Europe
and
elsewhere.
A
Okay,
next
up
is
the
070
release.
This
is
absolutely
top
of
mind.
I
put
it
to
the
top
of
the
agenda
intentionally,
the
let's
see,
I
think
this
one
may
have
already
merged
since
I
added
the
agenda
yeah.
So
this
is
one
of
the
big
changes
between
rc1
and
rc2,
thanks
to
John
for
catching
and
finding
this
one,
we
had
not
considered
port
in
terms
of
validation,
so
that
meant
that
some
valid
things
were
getting
rejected
by
the
by
our
webbook
validation.
A
This
takes
that
into
account
so
huge
thanks
to
John
for
fixing
that
bug
and
then
the
other
thing
that
I
want
to
highlight
and
actually
in
garof
you've
got
one
just
below
maybe
I'll
just
highlight
this
one
is
garof
has
been
doing
some
great
work
on
redirect.
Sorry,
that's
the
wrong
one
and
it's
in
a
PR,
but
also
it.
It
started
with
this
proposal,
doc
from
garof
and
maybe
I
I
think
you're
on
this
call.
Are
you
able
to
just
give
a
high
level
explanation
here?
Oh.
B
A
And
actually
before
before,
that,
I
should
introduce
actually
sits
beside
me
he's
on
on
the
same
team
as
me
and
has
been
doing
some
really
great
work
recently
on
Gateway
OSS,
so
yeah
just
welcome
and
yeah
go
ahead.
C
Hey
everyone,
so
the
topic
of
discussion
of
this
problem
is
it's
quite
simple.
So,
given
you
are,
you
are
given
an
HTTP
route
and
you're
using
a
HTTP
request
redirect
filters.
C
C
C
So
can
you
scroll
down
Rob
yeah,
so
the
proposal
is
kind
of
considering
both
options.
One
and
two,
which
is
you,
can
simply
not
specify
any
port
at
all
in
the
outgoing
request
or
in
the
redirect
request,
or
if
you
do
intend
to
specify
the
port.
It
should
match
the
well-known
code
for
the
scheme
which
was
configured
inside
the
redirect
filter
the.
D
C
For
allowing
both
of
these
options
is
for
multiple
implementations
to
be
conformed,
because
I
believe,
like
some
implementations,
may
not
be
able
to
delete
the
port
if
it
was
specified
in
the
incoming
request.
That
is
why
it
would
be
beneficial
if
both
of
these
things
are
allowed
and
then
given
below
is
just
some
examples
of
how
what
things
are
considered
valid
and
what
we
consider
as
invalid
I
can
go
over
them.
But
if
anyone
has
any
questions
any
thoughts
regarding
this,
definitely
we
can
discuss
them
right
now.
C
Yes,
so
the
question
is
ADT
is
the
listener
Port
right,
not
the
host
header?
Yes,
that
is
correct.
8080
is
the
list
report.
A
I'm,
sorry,
maybe
we
can
jump
right
into
definitely
open
to
more
conversation
here,
I'm
missing
some
things
and
yeah.
E
I
definitely
would
recommend
that
people
go
and
read
and
think
carefully
about
this.
Thank
you
very
much
for
this.
This
truth
table
I
think
this
is
probably
the
most
important
part
of
this
talk
like
it
sort
of
lays
out
pretty
clearly
what
like
all
of
the
possible
options
and
what
the
valid
outcomes
will
be,
and
then,
once
you
understand
that,
then
reviewing
the
going
back
over
the
pr
is
pretty
straightforward.
D
A
And
then
I
think
I
don't
know
if
it's
linked
from
here
out,
but
there's
a
pull
request
somewhere.
Maybe
I'll
I'll
go
over
here.
That
actually
takes
this
the
step
further,
and
is
this
the
one.
D
A
This
is
the
one
okay
1880
I'll
link
this
in
the
agenda,
because
it's
kind
of
the
thing
everything
resolves
around
as
far
as
this
work.
A
So
essentially,
let
me
see
here
this
is
the
one,
so
this
is
actually
implementing
the
changes
as
they're
proposed.
It
updates
the
spec
and
it
does
conformance
tests.
So
the
spec
changes
are
here.
Gaurav
has
very
kindly
split
this
out
into
four
meaningful
commits,
so
if
you're
looking
to
review
just
the
spec
changes
or
if
you're
anyway,
so
it's
it's
well
laid
out
that
way,
I
encourage
everyone
to
to
take
a
chance
and
review
either
the
doc
or
this
PR.
A
But
since
it's
already
in
the
pr,
maybe
I
don't
know
whatever's
best
to
you,
I
I
think
we'll
just
be
keeping
track
of
both
of
those.
This
is
something
that
we're
trying
to
get
through
as
soon
as
possible.
I
mentioned
it
in
slack
as
well.
Unfortunately,
this
had
been
labeled
as
a
070
release
blocker
and
it
got
removed
from
the
Milestone
and
so
accidentally,
and
so
unfortunately,
well,
fortunately,
we
caught
it
before
we
released,
but
unfortunately
this
is
sitting
between
us
and
rc2.
A
So
really
appreciate
the
expedited
reviews
on
this
I
I
would
love
to
get
something
in
this
week.
So
I.
You
know
I
appreciate
that
you
know
the
code
is
here.
The
conformance
tests
are
here,
but
I
don't
want
to
rush
things
like
if
there's
something
that
is
really
you
know
incompatible
or
some
some
portion
of
this
does
not
make
sense
to
someone
we
can
slow
it
down
and
have
a
break
a
bigger
discussion.
A
Yeah.
Please,
please,
please
get
your
feedback
in
as
soon
as
possible
on
this
trying
to
move
as
quickly
as
possible,
because
we
all
want
to
get
070
out
the
door
yeah.
Any
any
thoughts
comments,
I've,
missed
chat.
If
anything's
there.
E
A
Cool
awesome,
yeah.
This
is
yeah
thanks
again
for
for
getting
this
out
there.
You
know
I
I,
know
I
you
you
signed
up
for.
If
you
know,
garof
has
signed
up
for
a
few
things,
and
this
at
first
seemed
like
oh.
This
will
just
be
an
easy
little
thing
and
you
got
you
know:
oh
release,
blocker
big,
you
know,
discussion,
design,
doc.
All
this
stuff
and.
F
A
Thanks
for
rolling
with
it
yeah
all
right,
let
me
let
me
keep
on
moving.
Then
again,
that's
rc2!
Those
are
the
big
things
I'm
aware
of.
If,
if
anyone
is
aware
of
anything
else,
don't
hesitate
to
to
reach
out,
but
as
far
as
I
know,
those
those
are
the
things
between
us
and
rc2
and
rc2
historically
has
been
the
the
thing
that
is
identical
to
our
final
release
and
I'm
sure
hoping
that'll
be
true.
This
time
too
yeah,
okay,
so
next
steps
I,
think
Arco
you're
on
this
call.
A
This
is
something
that
I
remember.
There
was
I,
think
Argo
pinged
on
this
and
I
said.
Oh,
we
should
discuss
this
at
the
next
meeting
and
I'm.
Remember
I'm,
forgetting
all
the
context
now
so
maybe
Arco.
If
you
can
help
fill
in
the
gaps.
Sure.
F
Thanks
so
I
did
see
a
contributor,
the
Community
member,
trying
to
change
the
the
conformance
level
for
certificate
reps
from
implementation
specific
to
Extended,
so
certificate
drafts.
This
is
just
on
the
listener.
F
You
can
specify
a
list
of
certificates
on
The,
Listener
and
so
supporting
a
list
is
implementation.
Specific
most
implementations
today
only
support
one
certificate
draft,
so
I
think
the
question
here
is
the
two
questions
here
is:
does
it
make
sense
for
the
Upstream
API,
Gateway
API
to
add
extended
support
for
this
field?
If
so,
watch
the
semantics
be
I.
Think
it's
for
the
the
latter
part
I
do
see
many
data
planes,
hre
proxy
nginx
Envoy.
They
do
sort
of
have
similar
semantics
for
when
multiple
searchs
are
provided.
F
A
Oh
yeah,
thank
you
a
bunch
for
for
that
background,
it
is
coming
back
to
me
now
I
think
I.
Think,
like
you're
saying,
we
know
that
multiple
certs
on
a
Gateway
listener
is,
is
a
broadly
supportable
concept
and
that's
that's,
and
so
by
that
criteria
it's
something
like
we
should
be
trying
to
get
to
Extended.
The
concern
is
just
how
specific,
should
you
know
our
spec
B
here?
How,
when
it
comes
to
multiple
search
seat,
is
specifically
when
you
have
overlapping
certs
that
that's
the
my
biggest
concern
is.
A
If
you
have
two
starts
that
have
some
some
form
of
overlap,
maybe
they
both
specify
the
same
Sni
or
there's
a
wild
card
involved
in
one,
not
sure,
and
it
sounds
like
Arco
you've
already
done
some
some
initial
digging
into
what
common
implementations,
support
and
there's
some
similarities.
A
You
know
the
simplest
possible
Next
Step
would
be
just
to
say.
Well,
you
have
to
attach
certificates
in
order
in
the
order
they
were
received.
You
know
to
configure
your
data
plane
in
that
same
order
and
then
everything
else
is
implementation
specific,
but
then
that
doesn't
really
I'm,
not
sure.
If
that
really
meets
the
bar
for
extended,
or
if
that
really
is
just
implementation
specific,
it
would
be
pretty
it'd,
be.
E
E
E
Don
Bulgaria
has
there
one
of
the
two
of
the
points
that
they
have
are:
firstly,
supporting
RSA
and
public
curve,
certs
on
the
same
listener,
which
I
think
is
a
pretty
fair
one
and
the
other
one
is
Sni
based
super
good
selection,
I
think
so
that's
probably
the
one
we're
always
most
likely.
That
is
a
lower
down
low
down.
There
is
two.
G
B
G
Use
Sni,
but
I
was
curious,
like
how
a
user
would
actually
go
about
using
that,
like
the
case
that
made
sense
to
me
was
just
saying,
like
hey
here's,
all
my
certificates,
I
have
I,
have
100
certs,
go
figure
it
out,
and
my
HTTP
routes
all
bind
to
host
names
and
everything
will
kind
of
work
its
way
up,
but
the
issue
there
is
like
it
almost
feels
like
you,
want
a
label
selector
or
something
over
Secrets,
not
necessarily
a
big
list
of
them,
so
I'm,
just
I'm
struggling
to
see
like
why
a
user
should
use
this
and
how
they
should
use
it,
and
how
that
compares
to
multiple
listeners,
not
to
mention
like
some
of
the
like
some
of
the
benefits
of
The
Listener
model
is
that
HTTP
routes,
don't
necessarily
just
have
permission
to
bind
to
whatever
host
names
they
want
in
any
namespaces.
G
So
there's
some
security
concerns
around
our
our
model.
It
would
be
nice
to
have
some
kind
of
example,
use
cases
I.
H
C
F
So
if
you
could
have
a
sub
domain
right
and
you
could
have
a
new
app
for
that,
and
so
if
something's
ephemeral,
you
could
add
the
search
for
that
add
their
route
for
it
Define
a
wild
card
hostname
at
The
Listener
level.
You
could
Define
a
more
specific
host
at
the
route
level
and
route
to
it.
E
You're
still
yeah,
if
you
want
to
have
individual
certs
for
each
hostname
and
have.
E
The
HTTP
routes
bind
to
the
same
listener
or
need
to
have
edit
permissions
on
the
gateway
to
be
able
to
edit
the
list.
The
listed
tier
list
certificate
riffs
inside
the
listener,
so
you're
still
going
to
have
to
edit
the
gateway
to
have
better
Gateway
permissions
to
be
able
to
change
the
list
of
TLS
certs,
at
which
point
you
may
as
well
be
adding
a
separate
listener
for
each
one.
E
The
I
mean
I.
Suppose
you
could
make
an
argument
about
being
concerned
about
the
size
of
statuses
and
things
like
that.
But
but,
like
I,
think,
that's
pretty.
That's
kicking
the
can
a
bit
far
down
the
road
like
you're
100
right
John
like
if
you
really
want
to
I
I
I
I,
suspect
that
most
of
the
current
the
ways
in
which
people
are
wanting
to
use
this
are
all
about
making
things
more
magic.
E
That
has
certainly
been
a
request
that
I've
seen
before,
where
people
want
to
be
able
to
say
you
know:
I
want
I,
want
people
to
be
able
to
Crypt
to
add
HTTP
route
still
Gateway
and
have
GLS
that's
generated
and
have
them
not
need
to
worry
about
materials.
So
it's,
but
also
to
have
the
the
the
the
HTTP
will
be
able
to
attach
to
a
Gateway
without
them
having
a
bigger,
specific,
listen
up
and
without
having,
but
I
also
want
to
have
distinct.
So
it's
not
a
wild
card
set.
E
G
E
So
I
think
to
answer
the
question:
that's
in
the
agenda.
It
feels
like
the
next
steps,
for
this
is
a
use
cases
doctor.
So
to
say
what
what
a
you
know:
multiple
stupid
risks
being
usable.
You
know,
I
think
no
one's
denying
our
code
that
the
that
are
being
able
to
specify
you
know
the
same
Sni
with
multiple
types
of
cert
or
multiple
Keys,
and
that's
what
they
tell
the
model.
Cyber
Suites
cybers
is
useful,
but
like
what
are
the
other
uses
that
we
would
like
to
hit?
E
You
know
with
Sni
matching
like
what
are
we
aiming
to
achieve
by
doing
that
and
that
that
way
we
can
all
have
this.
This
is
one
of
those
classic.
We
all
need
to
make
sure
we're
on
the
same
page,
one
of
discussions
I
think
where
we
need
to
make
sure
that
we're
talking
about
the
same
sort
of
use.
D
A
It
sounds
like
what
I'm
hearing
is
that
this
is
probably
I
think
we
initially
said
well,
we
might
not
need
to
get
for
it.
It
sounds
like
well,
we
probably
do
need
a
gap
or
something
like
resembling
a
gap.
Even
if
it's
a
small
one
for
this,
just
because
you
know
anytime,
you
you're
you're,
trying
to
discuss,
use
cases
and
go
through
the
you
know
this
process.
Gap
is
really
the
the
process
we
have.
E
Yeah
I
think,
and
the
other
reason
for
The
Gap.
There
is
to
be
able
to
record
the
you
know
the
use
cases
we've
thought
about
and
why
we've
designed
it
in
the
way
why
we've
made
the
decision
we
had
and
lots
of
stuff
and
recorded
all
for
austerity,
because
I
don't
know
about
anyone
else,
but
we
definitely
have
in
our
gaps.
Now
that
aren't
starting
to
have
trouble
remembering
why
we
made
decisions
and
yeah
why
things
are
the
way
they
are
and
that's
only
going
to
get
worse.
A
For
sure
cool,
do
we
have
anyone
who
can
follow
up
with
this
Arco?
Are
you
volunteering
to
to
push
this
forward?
A
F
A
All
right
so
we'll
I
could
follow
up
after
I'll
leave
this
one
open,
I
can
follow
up
and
just
summarize
our
conclusion
here
and
see
if
they
want
to
move
forward
cool
and
thanks
again
Arco
for
for
peeing
this
one
and
bringing
it
back.
I
know
we
have
a
few
too
many
PR's
that
are
just
kind
of
stuck
waiting
for
resolution.
So
I
appreciate
you
following
up
make
sure
making
sure
we
got
back
to
it
cool
all
right.
A
A
You,
maybe
do
you
have
some
more
context
you
can
share
here.
I
Yeah
so
so,
last
last
week
I
proposed
like
to
allow
static
mode
and
to
this
week
there's
another
proposal.
We
just
I
think
it.
Maybe
it's
it's
much
simpler
than
the
previous
one
one,
but
I
think
it
cannot.
Potentially,
you
know
Allah
allow
supporting
the
static
mode
in
test
with
a
single
Gateway
or
Gateway
class,
so
I
just
wanted
to
run
by
by
you
guys
and
and
see
if
you
know
in.
I
If
this
can
work-
and
you
know
so-
and
the
idea
of
of
the
of
this
proposal
is
to
basically
have
a
deforming,
the
test
have
a
pool
of
Gateway
of
Gateway
classes,
each
associated
with
the
data
plane
and
as
the
tests
run,
whenever
the
Gateway
is
created,
it
is
assigned
to
one
of
the
to
one
Gateway
class
from
that
pool
and
when
Gateway
is
removed,
that
Gator
classes
becomes
free
and
then
and
I
did
a
prototype
of
this
approach.
I
So
it
doesn't
require
any
changes
to
the
tests
or
manifests
it
just
requires
in
the
in
that
prototype
I
just
allowed
configuring
this
a
list
of
DSP
classes
that
are
available,
and
there
is
a
logic
in
a
common
test
code
code
that
allows
that
changes.
The
manifests
the
Gateway,
manifest
by
editing
the
Gateway
class
so
basically
allowed
to
I
think
the
most.
The
most
crucial
change
is
apply.goal.
Here,
it's
fun
Yeah.
I
So,
basically,
whenever
the
Gateway
resource
is
processed,
allocating
in
Gateway
class
for
it
and
then
whenever
the
test
finishes,
you
know
the
allocating
that
bitterness
and
for
the
for
the
more
for
the
for
the
current
mode,
where,
like
it,
doesn't
change
anything.
So
if,
if
you
have
only
one
Gateway
class,
you
know
the
tests
run
as
they
run
would
run
as
early
as
they
run
now.
But
if
you
have
multiple
Gateway
classes,
this
will
allow
us
to
assign
each
gateway
to
this
to
one
one
of
the
free
Gateway
classes.
I
A
Yeah,
this
is
really
interesting
if
I'm,
understanding
and
and
I
may
be
misremembering
what
you
were
saying
last
week,
but
it
sounds
like
every
Gateway
class
can
support
at
most
one
Gateway.
Is
that
correct
with.
A
Okay,
yeah.
That
is
not
interesting.
E
E
If
you
wanted
to
do
the
static,
Gateway
class,
the
static
thing
with
them,
then
you
you're
kind
of
start
you're
kind
of
out
of
luck
there,
because
because
there's
only
a
single
Gateway
class,
as
you
say,
it'll
end
up
with
effectively
being
a
dynamic
Gateway
I
appreciate
that
you
are
working
very
hard
to
try
and
to
try
and
thread
a
very,
very,
very
small
needle
yeah,
but
I
think
the
more
that
I
think
about
it.
E
The
more
that
I
think
that
that
the
that
we
may
be
better
off
to
move
everybody
towards
you
know
we
may
be
better
off
to
to
get
that
infrastructure
to
get
the
infrastructure
stuff
sorted
out
and
then
to
move
everybody
towards
being
able
to
specify
the
infrastructure
in
for
the
tests.
So
if
we
have
the
test
have
a
way
where
you
can
say
when,
like
when
you
create
gateways,
here's
what
should
be
in
the
infrastructure
stanza
and
because
then
you
can
say
the
infrastructure
standard
should
contain
its
own
parent
risk.
E
The
more
I
think
I
feel
like
that
should
hit
everybody's
use
case,
but
it's
just
not
going
to
be
achievable
without
without
more
work
on
the
infrastructure,
stanza
yeah,
it's
a
really
I,
think
it'll
be
much
better
in
the
longer
term,
but
it's
going
to
be
a
bit
hard
to
get
there.
I
E
A
Yeah
that
may
be
another
one.
If
anyone
feels
like
dropping
that
on
the
triage
list,
it
might
be
good
just
to
take
another
look
at
it.
I
am
pasting
it
in
right.
Now.
Awesome
yeah,
I,
I'm
interested
in
that
idea
and
how
it
would
work
the
I
don't
know
I
mean
obviously
the
the
ideal
I
would
love
to
to
get
to
is
a
world
where
every
implementation
could
support
multiple
gateways
likely
via
some
kind
of
operator
sitting.
A
You
know
above
it
that
that
feels
like
kind
of
the
end
goal
for
the
best
API
possible
API
experience.
I
recognize
that
may
not
be
practical
everywhere,
but
I
am
just
you
know.
I
I've
I've
been
thinking
as
I've
seen
some
very
creative
implementations
on
top
of
Gateway
API.
A
A
They
don't
I,
don't
want
to
go
too
far
down
that
rabbit
hole
but
I.
You
know
again
I
I
hate
to
see
everyone
doing
the
same
thing
different
ways
when
it
is,
it
seems
at
least
from
the
outside.
Looking
in
like
there's
a
lot
of
similarities,
yeah
I,
don't
know
I,
don't
know
again
in
in
mikhail's
case
with
with
yours,
I
are
you,
you
know
it?
Would
each
Gateway
be
specific
in
cluster
infrastructure?
Are
you
talking
to
say
you
know
out
of
cluster
hardware,
for,
for
example,
or
something
else
entirely.
I
A
Yeah
so
I
mean
yeah,
so
so
for
now
I,
you
know
I
think
some
implementations
out
there
have
have
their
own
custom
logic
to
kind
of
make
conformance
test
work
for
them.
I,
don't
know
that
I've
seen
anything
quite
like
this,
but
I
I
hate
to
see
you
be
blocked
indefinitely
on
this
I'd
love
to
get
something
that
makes
it
easy
for
you
to
run
conformance
tests.
I
think
we
just
have
to
to
walk
that.
You
know
find
that
balance
between
this
is
a
a
temporary
workaround.
A
Maybe
it's
just
unique
to
your
implementation
and
something
that
we're
committing
to
long
term.
Is
you
know
a
standard
because
I
think
at
least
from
my
perspective,
the
long-term
goal
would
just
be
that
anyone
who's
working
with
Gateway
API
doesn't
need
to
worry
about
deploying
a
new.
You
know
manually
deploying
a
new
Gateway
every
time
they
they
set.
One
up.
I
A
Yeah,
that's
true,
I,
don't
think
we
have
clearly
stated
that
anywhere
in
in
the
API
as
a
as
an
expectation,
that's
that's
kind
of
a
North
star
for
me,
but
not
not
clearly
stated
anywhere.
E
D
A
I
do
think
it's
it's
interesting
to
explore
different
ways
like
you
know,
using
the
the
infrastructure
stanza
which
should
merge,
while
the
Gap
at
least
should
merge
soon,
but
yeah.
Certainly
I
would
encourage,
wherever
possible,
to
to
work
on
some
kind
of
automation.
On
top
of
this,
that
that
does
enable
multiple
gateways
with
the
same
class
yeah.
E
A
And
and
definitely
if
you
feel
like
just
completely
stuck
and
you
can't
run
conformance
tests
without
this
yeah-
definitely
check
back
in
cool
all
right
next
up
I
think
we've
got
Candace
something
about
well,
maybe
Candace
are
you
on
the
call.
B
G
B
That,
okay,
all
right
so
so
this
is
this
is
the
gap
and
and
it
was
merged
without
implementation,
because
we
decided
that
we
would
do
the
implementation
after
everybody
agrees
on.
Why
and
why
we
want
to
do
this
and
then
the
next
step
would
be
how
we
want
to
do
this.
B
I
had
just
I
wanted
to
briefly
discuss
the
object
that
we
might
want
to
use
for
holding
this
information,
because
the
the
last
three
or
four
suggestions
that
came
from
Red
Hat
have
been
rejected,
so
I
just
kind
of
wanted
to
run
it
by
everybody
and
and
see
what
is
the
what's
the?
What's,
the
preferred
object
that
we
want
to
go
with
in
terms
of
the
implementation.
B
So
if
you
scroll
down
thanks
for
sharing
the
screen,
if
you
scroll
down
to
the
prior
art,
which
is
down
at
the
bottom,
we
did
talk
about.
You
know
how
how
have
influenced
the
implementations
done
this
so
far
and
different
implementations
and
her
sorry
for
anyone
who
who
doesn't
know
what
I'm
talking
about
we're
talking
about
TLS
from
the
gateway
to
the
back
end
yeah.
This
is,
this
is
the
picture
that
describes
it
from
the
gateway
to
the
back
end
and.
B
We
will
want
to
go
forward
before
we
start
talking
about
implementation,
about
what
kind
of
object
or
data
structure
do
we
want
to
associate
this
information
with
one
and
and
this
I
see,
question
is
talks
about
Gamma
and
even
in
the
implementation,
we're
not
going
to
be
addressing
gamma,
and
this
I
I
believe
as
agreed
upon.
E
Yeah
so
I
think
the
yeah,
so
I
think
it's
a
very
reasonable
question
for
you
to
ask
for
starters
the
for,
for
me,
I
I
would
like
you
know,
I,
think
that
something
like
that
looks
a
little
bit
like
the
istio
destination
will
be
great,
but
I
would
like
to
see
it
not
using
keying
our
first
name
on
the
string
level.
The
two
represent,
the
things
I
think
keying,
my
first
name
on
the
string
level.
E
If
there's
one
thing
that
Ingress
has
shown
us
is
that
king
or
first
name
on
the
string
level
for
handling
this
sort
of
configuration
is
brought
with
Danger
yeah,
and
so
that's
that's
sort
of
the
reason
why
I
would
probably
come
down
personally
on
the
side
of
having
some
sort
of
meta
resource
on
like
the
buying
Eco
service.
E
Yeah
so
so
I
mean
with
Ingress.
What
ended
up
happening
was
because
you
can
specify
any
first
name.
E
It
kind
of
ends
up
with
the
Ingress
Ingress
is
effectively
claiming
a
global
first
name,
using
a
namespace
scope,
resource
and
so
they're,
using
a
that's
a
unique
example
that
you
know
that's
in
the
first
one
for
the
the
destination
for
istio
I
can't
see
John
or
constant,
correct
me.
If
I
don't
know,
if
destination
rule
there's
no
space,
I
guess
it
probably
is,
but
it
references
it
has
the
full
spect
domain
name
for
the
services.
It's
talking
about
thanks
John
it
is,
it
is
namespace.
E
It
has
the
full
hostname
like
service
name.namespace.scc.cluster.local.
E
And
then
yeah
I'm,
not
saying
it
shouldn't,
be
namespaced
I'm
saying.
But
the
problem
is
that
when
you
have
a
string
name
yeah
like
when
you
have
a
string
hostname
the
you
then
have
to
specify
the
full
hostname
to
make
it
properly
pick
up
which
host
name
it
should
be
associated
with,
whereas
when
you're,
you
don't
actually
need
that
information
when
you're
connecting
from
a
gateway
to
the
back
end,
you
don't
need
to
know.
The
hostname
of
the
Gateway
is
connecting
on.
E
You've
got
that
from
the
host
from
the
hostname
headers
in
the
route
or
with
other
stuff
right.
So
you
just
need
the
TLs
stands:
the
traffic
policy
until
that
stands
a
bit
out
of
the
policy.
So
my
my
opinion
here
is
that
it's
better
to
connect
whatever
we
do
for
whatever
we
do
to
be
some
sort
of
meta
resource,
decorating,
a
service
which,
in
the
new
in
the
new
recently
merged
world
of
policy
attachment
counts
as
a
direct
attach
policy.
G
E
E
B
E
Yeah
I
was
about
to
say
what
is
it?
What
does
anyone
else?
Think
I
shouldn't
be
the
only
one
because
that's
gone
wrong
before.
A
Think
we've
tried
every
possible
variation
of
this.
E
We
did
about
I
think
the
previous
one
that
we
did.
We
left
it
a
bit
too
open
about
what
the
the
thing
would
be
covering
that
was.
That
was
the
back
end
policy,
and
so
we
sort
of
said
oh
yeah.
It
can
handle
all
sorts
of
stuff
and
people
were
like,
but
we're
but
handling
all
sorts
of
stuff
is
really
complicated,
which
is
fair,
so
yeah.
B
So
would
it
be
fair
to
try
to
resurrect
Becca
and
policy
but
reduce
the
scope.
A
That's
maybe
I
I
have
not
had
enough
time
to
think
about
this
with
any
API
design.
There's
there's
always
a
balance,
especially
in
kubernetes
between
too
many
tiny
resources
and
one
all-encompassing
resource.
Historically,
when
it
came
to
backend
anything
how
we
have
led
leaned
towards
one
resource
for
all
the
things
in
in
our
previous
attempts
and
that
hasn't
gone
as
well
as
any
of
us
would
have
liked.
A
I
I'm,
not
you
know
at
others
at
the
other
side
of
it,
I
don't
really
want
to
have
a
separate
resource
for
every
tiny
little
thing
like
if
you
think
of
other
config
that
could
potentially
be
attached
to
a
back
end,
and
you
say
well,
every
single
one
is
a
new
resource.
That's
pretty
awful
too
in
terms
of
ux
I
I.
Think
what
costs
and
said
in
chat
is
probably
a
where
I've
been
leaning
as
well
is
that
TLS
itself
is
pretty
complex
and
it's
sensitive
and
potentially
highly
privileged.
A
You
know
so
so
in
that
sense,
maybe
it
deserves
its
own
resource.
The
way
kubernetes
works
today
is
you
grant
rbac
based
on
a
resource,
and
so,
if
you're
saying
you
know,
I
want
to
configure
all
these
things
about
a
back
end.
Maybe
TLS
is
a
special
enough
thing
that
it
gets.
You
know
a
separate
resource
that
I
I.
This
is
this
is
me
talking.
You
know
off
the
top
of
my
head,
but
I
I'm,
increasingly
leaning
towards
a
a
more
targeted
resource
for
back
in
TLS
We've.
A
We've
tried
and
failed
with
the
other
approach.
Maybe
this
will
go
better.
Hopefully
it
will
and
yeah
I
know
we
absolutely
all
want
to
get
this
in
and
yeah.
A
Maybe
having
this
be
more
targeted
seems
to
give
us
better
chances
at
success
and
just
not
just
that
but
I
think
better
Access
Control
long
term.
B
So
service,
oh
sorry,
go
ahead.
G
D
E
Thought
so
Rob
that
crosses
over
into
territory
similar
to
what
we're
talking
about
with
the
reference
Grant.
So
ideally,
in
my
mind,
if
it
is
going
to
be
a
decoratory
resource
for
any
sort
of
object,
that
is
a
valid
back-end
ref.
Ideally
you
should
only
the
people
who
create
access
to
those
to
those
resources
should
be
able
to
create
and
use
this
resource.
However,
when
we're
talking
cids,
there's
no
way
to
do
that,
so
in
the
language
that
was
used
to
ask
that
question,
it
should
be.
E
The
producer
like
the
producer
of
the
service,
is
the
one
who
has
made
who's
setting
the
TLs
secret
connection,
because
this
is
explicitly
about
using
about
when
the
the
workload
that
the
service
is
pointing
to
is
running
its
own
TLS
is
handling
its
own
TLS.
This
is
not
about
you
know
when
there
is
some
other
layer
automatically
managing
TLS
on
behalf
of
the
workload.
E
This
is
when
the
workload
has
its
own
TLS,
that
it
is
managing
in
whatever
way
it
chooses,
but
it's
when
it
is
explicitly
not
when
there's
some
infrastructure
automatically
managing
TLS
on
look
that
is
owned
by
the
infrastructure,
not
by
the
application
developer.
So
maybe
application
developer
has
installed
their
own
cert
manager
in
their
own
namespace
and
is
doing
their
own
thing
with
that.
But
it's
explicitly
owned
by
the
same
person
by
the
application
developer,
not
by
the
you
know,
not
by
the
not
by
not
by
the
infrastructure
team
that
normally
owns
the
Gateway.
E
G
E
B
E
By
Mutual
by
Mutual
tailors
if
you're
saying
short
short
road
short
period
rotation,
things
used
to
validate
identities
between
Services
Mutual
TLS
is
not
a
goal
here.
If
you're
saying
being
able
to
do
client
certificate
validation
from
the
Gateway,
then
that
is
a
goal,
but
it
will
not
be
included
in
this
TLS
back
in
policy
because,
as
you
say,
that's
a
property
of
the
Gateway,
not
a
property
of
the
of
the
back
end
right.
Like
the
back
end,
you,
the
Gateway
May,
will
need
to
know
about
the
ca
it
should
be
using.
E
A
Yeah
yeah
well
said:
I
I
want
to
just
jump
back.
I
did
want
to
time
box
this,
but
Brian
left
something
interesting
in
chat
here.
That
I
think
we
kind
of
have
not
covered
in
this
discussion
at
least,
but
it
sounds
like
nginx
has
their
equivalent
configuration
to
this
in,
you
know,
they're
equivalent
to
a
route
and
that
that
definitely
would
be
an
option
here
and
thanks
thanks
Brian
for
for
linking
to
the
docs
it
I
don't
know
O'brien.
A
If
you
want
to
talk
a
little
bit
about
how
that's
how
that's
worked
for
you,
it
looks
like
this
is
just
an
on
off
Boolean.
H
Yeah,
it's
it's
relatively
simple:
it's
the
way
we
handle.
We
just
handle
it
in
the
Upstream,
so
you
get
the
you
get
the
certificate
associated
with
it
and
then
it's
whether
or
not
we're
basically
enforcing
whether
we're
testing
for
it
we
treat
mtls
is
a
separate
thing
because
there's
authentication
of
you
know
implied
with
with
mtls.
So
for
us,
that's
a
that's
a
policy.
This
is.
H
E
Is
that
one
of
the
reasons
that
the
previous
one
sort
of
got
it
was
hard
to
talk
about
was
because
we
didn't
have
the
right
language
to
to
sort
of
talk
about
that
yeah.
That's
exactly
what
custom
is
saying
in
chat
is
I
have
specifically
have
been
trying
to
avoid
the
use
of
the
Fallout
acronym
mtls,
because
it
means
too
many
things
to
too
many
people.
Yeah
and
I
prefer
to
use
the
more
accurate
in
this
case,
terminology
of
Gateway
client
certificate
checking.
J
Did
we
resolve
the
governance
issue
or
the
model
that
we
want
to
pursue
for
this,
like
if
the
person
who
provisioned
the
Gateway
has
a
conflict
with
the
person
who's
describing
the
service
like
the
Gateway,
wants
to
use
one
set
of
CAS
and
serve
it
like
so?
Are
we
making
some
base
assumptions
in
terms
of
like
they're
the
same
domain
for
this
proposal?
Is
that
still
something
that
we're
going
to
discuss.
E
E
You
know
so,
like
you
might
I
guess
to
me
when
I've
been
talking
thinking
about
this,
the
you
know
that
the
the
the
application
developer
the
service
owner
the
workload
owner,
holds
all
the
cards
here.
So
that's
why
putting
it
on
them
makes
the
most
sense
to
me.
Sorry,
I,
can't
it's
Hugo
I'll
talk
too
much.
B
Oh,
no,
that's!
Okay!
It
is
I.
It
I
think
what
you're
you're
talking
about
boy
is
a
non-goal
listed
here.
J
I
just
want
to
make
sure
that
we
understand
the
domain
of
like
control.
I
guess
like
is
this
meant
to
be
somehow
there
could
be
conflicting,
config
and
that's
resolved
or
that
we
state
that
that
is
not
possible.
J
E
But
right
now
you
cannot
configure
the
gateway
to
use
any
coats,
so
any
Cas
that
you
were
configuring
for
the
Gateway
are
for
listeners,
not
full
Gateway
as
client.
J
E
F
E
Tls
then
you
then
use
this
then
use
use
this
client
search
or
something
like
or
use
this
client
search
or
you
require
this
CA
or
something
like
that,
exactly
how
it
works
is
going
to
be
a
little
tricky.
I
think
John
has
a
good
point
in
the
comments.
Let's
say
like
you,
we
need
like
a
bit
of
a
table
that
summarizes
a
bunch
of
the
a
bunch
of
the
variables
here.
Yeah
I
think
that's
probably
the
way
to
go
about.
J
B
A
All
right,
well,
I,
do
want
to
time
box
this.
This
has
been
great
discussion.
Candace
I
think
you
have
lots
of
lots
of
next
steps
here.
Thank
you
so
much
for
for
taking
this
on
yeah,
it
seems
like
maybe
we
can
add.
Anyone
is
welcome
to
do
this,
but
this
prior
art
section
is
great,
already
probably
worth
adding.
Nginx
add
to
this.
A
Maybe
if
someone
from
the
nginx
team
actually
wants
to
contribute
to
this
Gap
I'm
sure
it
would
be
welcome,
just
describe
how
how
it
works
and
I
think
that
applies
to
any
Implement
implementation
out
there.
If
you
support
something
like
this,
please
go
ahead
and
add
it.
So
we
have
a
good
view
of
the
world
and
what's
out
there
and
then
at
the
same
time,
I
think
we've
got
some
clear
next
steps
and
you
know
we
do.
A
We
do
want
to
see
this
move
forward
pretty
quickly,
because
it
is
very
important
to
be
able
to
represent
this
in
the
API
so
really
appreciate,
Candace
pushing
through
and
yeah
we'll
see
where
we
go.
A
Great
okay,
next
up
with
just
a
couple
minutes
left
we've
got
1868.
This
is
the
per
Gateway
infrastructure.
Thank
you
for
adding
this
one
I
think
John
I,
think
everything
is
resolved
now
or
almost
resolved.
E
Yeah
I
think
I've,
given
the
my
approval
on
there.
I
think
you
just
need
to
lgtm
from
from
you
or
Shane,
probably
oh
okay,
yeah.
A
A
Okay,
the
in
cluster
gate.
Oh
yes,
yes,
this
one
is
this
one.
E
From
109
comments,
I
think
it's
close
ish,
it
depends
on.
It
depends
on
infrastructure,
though,
so
we
need
to
yeah
Emoji
instruction,
one
first
and
then
yeah
just
I
think
yeah.
It's
the
same.
It's
in
a
similar
boat
to
yeah,
not
another
one
which
I
have
not
linked,
which
is
the
network
scope,
slash,
reachability,
slash,
routability
I,
get.
D
G
Okay,
yeah,
aside
from
the
other
PR
emerging
I,
think
this
one
was
ready
to
go
just
pending
review.
So,
if
not,
let
me
know
what
you
you
want
me.
A
To
do
cool
I,
just
real
quickly
is
this.
Oh,
it
looks
like
this
has
already
been
removed.
The
that's
just.
G
A
Removed
that
okay,
okay,
cool
all
right,
I'll
I'll
make
sure
to
take
a
look
at
that
this
week
and
and
again
on
on
both
of
those
gaps.
This
is
one
of
the
last
chances
to
comment.
You
know
this
in
the
next
couple
of
days,
so
if
you
care
about
them,
I
recommend
reviewing
them
ASAP,
because
it
sounds
like
they're,
both
close
to
merging
yeah
with
that
yeah.
We'll
just
leave
it
at
that.
Thank
you.
A
Everyone
for
great
feedback
and
great
discussion
and
we'll
talk
to
everyone
at
a
different
time.
Next
week,
early
in
the
morning,
if
you
happen
to
be
on
the
west
coast,
yeah
thanks.
Everyone.