►
From YouTube: Gateway API GAMMA Meeting for 20230124
Description
Gateway API GAMMA Meeting for 20230124
A
I
think
hello,
everybody
Welcome
to
the
January
24th
occurrence
of
the
Gateway
API
gamma
meeting.
As
a
reminder,
this
meeting
is
governed
by
the
kubernetes
code
of
conduct.
So
everybody
please
be
nice.
A
As
a
reminder,
this
meeting
is
governed
by
an
open
Agenda.
Anybody
can
come
and
add
a
topic
and
we
will
discuss
it.
So
I've
placed
a
link
to
the
agenda
here
in
the
chat.
So
if
you've
got
a
a
topic,
you'd
like
to
discuss-
that's
not
already,
there
then
please
feel
free
to
add.
I
would
love
to
hear
from
you
while
you're
there
on
the
agenda.
A
Please
go
ahead
and
put
your
name
in
that
top
section
for
attendees
we'd,
like
to
know
that
you
were
found
us
interesting
enough
to
to
spend
your
afternoon
evening
here
with
us.
So
dispatchers
have
a
record
of
that.
So
do
that
if
you
will
I'm
going
to
go
ahead
and
share
my
screen
here
and
we
will
get
this
agenda
kicked
off.
We've
got
a
couple
of
topics
here
and
I'm
excited
for
the
always
riveting
discussions
that
we
have.
A
So,
as
is
our
custom,
we
are.
We
start
with
a
recap.
So
last
week
we
discussed
this
PR
about
expanding,
get
1420,
1492
I,
believe
the
the
gamma
gap
for
HTTP
route
to
support,
clients
or
consumer
routing
config
I'll
go
ahead
and
open
that
here
in
GitHub,
just
take
a
look
we're
in
pretty
good
shape
here,
it
looks
like
I've
got
a
couple
of
approvals
here.
A
B
B
C
I
was
intending
to
do
it,
and
I
am
hopefully
going
to
click
that
button
later
this
evening,.
A
Okay,
awesome
so
we're
good
we're
gonna
get
spot
with
that.
We
looked
at
some
of
the
open
issues
and
the
mouse
town
for
General
HTTP
support
got
three
close.
Seven
open
I've
got
another
a
couple
of
these
on
the
agenda
for
today
we're
looking
for
owners
to
try
to
get
some
of
these
knocked
out.
A
The
focuses
here
seem
to
be
on
routing
and
conformance.
We've
got
a
couple
of
PRS
here
for
two
of
these
and
then
don't
know
if
Nick
oh
Nick
is
here,
we
should
chat
about
an
update
to
the
policy
attachment
here.
I,
don't
I,
don't
know
if
policy
attachment
is
blocking
for
this
first
070.
I,
don't
think
it
should
be.
C
A
Yes,
okay,
so
I
don't
have
permission
to
change
this
Milestone,
but
the
sounds
of
the
action
items
to
drop
policy
attachments
for
right
now
and
then
we're
thinking
that
John's
PR
wants
to
be
route
per
service
limitation,
because
John's
here
address
that
or
is
it
okay?
Okay,
so
I'll
go
ahead
and
I
am
here.
B
And
that's
just
not
070,
we
don't
really
care
what
Milestone
just
not
070.
C
C
C
A
F
A
A
Interesting
well
we'll
it's
it's
noted.
So,
okay,
we've
got
these
three
off
PRS.
A
This
is
actually
the
so
this
is
actually
I'll
save
this
for
after
the
recap,
I
got
a
little
bit
into
the
weeds,
so
we
talked
about
that
again.
Our
focus
is
on
routing
and
conformance.
We
had
a
little
bit
of
discussion
on
istio's
ambient
model
and
architecture,
architecture,
applicability
and
then
some
interesting
discussion
that
I'm
that
I'm
I've
been
go
processing.
A
The
background
thread
for
a
little
while
now
about
operator
like
a
contributes
controller
logic
and
seeing
if
there
is
a
way
to
create
a
common
library
or
pattern
for
for
doing
diffing
and
more
performant
updates,
as
opposed
to
frequent
reconciliation
of
the
state
of
the
world,
so
lots
of
fun
stuff
that
we
chatted
about
last
week
again
at
a
topic
for
I've
got
the
Milestone
pruning
there
so
we'll
tackle
there.
So
yeah
lots
of
interesting
things.
We
chatted
out.
Anybody
have
any
questions
or
comments
on
the
recap.
Yeah.
A
All
right,
awesome,
Rob
you've
got
the
first
formal
agenda
item
of
the
of
the
meeting
yeah.
B
Thank
you,
so
one
of
the
things
that
I
mentioned
just
briefly
in
the
meeting
yesterday
was
we're
trying
to
figure
out
what
we
want
to
include
in
the
next
couple
sets
of
Gateway
API
releases.
B
You
know
one
of
the
high
level
things
we've
been
talking
about
a
lot
at
the
end
of
last
year
is
we
want
to
have
more
frequent
releases
that
are
smaller,
so
I
don't
want
it
to
feel,
as
you
know,
daunting,
if
we,
if
something
like
misses
070,
because
hopefully
either
080
or
1.0
will
be
around
the
corner
after
that,
we
we
have
a
list
of
things
that
are
mostly
Ingress
focused
that
we
want
to.
B
You
know,
think
about
and
move
forward
with
from
that
other
meeting,
but
I
don't
know
I'm
just
trying
to
figure
out
what
do
we
want
to
try
and
you
know
commit
to
what's?
What's
the
first
release,
you
know
artifacts
for
gamma,
really,
the
the
releasable
artifacts
more
of
an
open
question,
yeah
yeah,
Shane
Shane's
question
is,
is
probably
very
relevant,
assuming
somebody
puts
in
a
contribute
Summit,
no,
not
a
maintain
a
track
talk
or
there's,
maybe
Coupe
contacts
already.
Who
knows?
B
Whatever
it
is,
what
are
we
talking
about
in
Amsterdam?
That
also
seems
very
relevant
to
what
we
want
to
get
in
this
next
release.
E
I
think
the
the
key
thing
here
is
like
what
do
we
want
to
show
from
gamma
yeah
I
think
the
larger?
What
do
we
want
to
show
in
the
Gateway
API
question
is
one
for
another
time.
B
I
mean
I'm,
not
even
you
know,
I'm,
not
the
mesh
expert,
but
I'll
start
trying
to
answer
my
my
own
question
by
saying
you
know
a
natural
follow-up
to
what
Nick
said.
It
sure
would
be
neat
if
we
could
demo
a
couple
different
mesh
implementations
implementing
a
baseline
spec.
You
know
that
that
seems
may
be
achievable,
but
I'll
defer
to
somebody
more
familiar.
F
I
have
a
cfp
in
with
I
forgot,
his
name
all
of
a
sudden,
but
you
recommended
him
to
me,
which
would
basically
do
just
this.
D
So
it's
kind
of
a
hacky
implementation
because
I
feel
like
in
when
we
did
it
for
Ingress
right
off
the
bat.
We
had
three
four
five
implementations
and
you
learned
a
lot
from
having
different
implementations.
We
we
get
users
to
try
it
out,
give
us
feedback.
We
find
out
assumptions
we
made
that
aren't
true
across
implementations.
It's
really
the
putting
what
we
talked
about
into
to
test.
So
without
that
we're
kind
of
in
limbo,.
D
C
Yeah,
it's
definitely
something
that
will
not
be
ready
in
console
by
that
point.
It
is
something
we
definitely
still
want
to
do,
but
we
have
a
bit
more
architectural
work.
That
kind
of
underpins
some
of
this-
that
we
need
to
get
to
first.
So.
G
Can
I
so
first
of
all,
John
the
good
news
is
we
have
two
implementation,
just
in
istio
itself,
so
we
have
the
classic
sidecar
and
it
has
the
ambient
based
implementation.
G
So
we
can
start
to
do
implementation
already
and
learn
from
it,
but
seriously
speaking
I
don't
know
about
the
other
implementations,
but
most
of
the
Implement
Gateway
and
waypoints
are
really
gateways,
so
maybe
a
bachelor
implementation
where
some
elements
of
the
mesh
are
implemented
via
you
know
in
in
gateways
effectively
that
may
be
desirable
and
compatible
with
the
weight,
is
to
ambient
and
and
and
probably
benefit
everyone,
because
I,
don't
think
the
low
level
Z
tunnel
or
or
tunnel
whatever
we
are
doing
at
the
data
plane
to
ensure
security
is
at
important
and
the
implementation
on
the
Waypoint
is
actually
pretty
close
to
the
Gateway
to
implementation.
E
Resilient
point
of
view
we
won't,
we
won't
have
anything
of
our
gamma
stuff
available
for
a
while
I'm
still
busy
sort
of
spinning
up
the
service
mesh
team
internally.
So
yeah
it's
gonna
be
a
while
to
get
everybody
on.
D
Yeah
I
mean
it
seems
like
then,
we
have
kind
of
two
paths
forward
as
Linker
D
comes
and
chimes
in
and
says
that
they're
going
to
save
our
predicament
or
we
Blaze
forward
with
one
implementation
as
well-
that's
causing
some
maybe
1.5
and
hope
that
we
can
make
progress
with
that
I
mean
we
certainly
can't
do
things
like
we
can
get
conformance
tests.
We
can
get
user
feedback,
it's
just
very.
D
It's
a
bit
risky
that
we
end
up
making
these
duoism
sick,
so
I
wouldn't
feel
very
comfortable
with
promoting
it
too
far
with
one
well
I
think
it's
actually
a
hard
requirement
listed
somewhere
or
if
not,
it
should
be
of
some
number
of
implementations
to
promote,
but
maybe
maybe
that's
fine
for
experimental.
For
now.
A
So
I
think
there's
a
bit
of
a
chicken
egg
problem
here,
a
bit
where
I
mean.
Thankfully,
we've
got
people
from
a
lot
of
implementations
like
here
in
this
meeting,
who
who've
been
here
for
a
while
and
know
about
Gamma
and
are
looking
to
try
to
implement
it.
But
on
the
other
hand,
one
of
the
things
that
helps
people
here
make
justifications
to
the
people
who
you
know
do
the
road
mapping
and
stuff
like
that
is
hey.
A
Customers
are
asking
for
this
and
customers
it's
hard
for
customers
to
ask
for
a
feature:
that's
not
released
yet
and
so
there's
a
certain
I
think,
there's
a
certain
level
of
certain
level
of
of
feedback
that
we'll
get
for
as
far
as
implementations
go
and
getting
customers
to
ask
for
this
once
it's
released
and
once
there's
Buzz
about
it.
A
Oh
interesting,
so
kubernetes
customers
using
Gateway
API
for
AWS
VPC
lattice.
That
is
very
interestingly.
When
do
you
have
any
more
details
you
can?
You
can
share
with
us
about
about
timelines.
There.
H
I
think,
right
now
we
are
in
the
private
preview,
so
with
a
little
limited
customers
and
you
have
to
talk
to
the
account
manager
to
get
access.
So
that's
why
the
country
we
have
a
POC,
the
Gateway
API
controller,
but
that's
also
in
private
repo,
so
hopefully
by
the
ga
I
think
in
the
springtime
and
I
don't
know
exact
date.
D
A
Cool,
that's
super
exciting,
for
for
what
it's
worth
from
in
my
POV
from
my
POV
I
think
that
pushing
forward
with
the
with
only
one
implementation
for
experimentalists-
probably
fine,
again
it's
difficult
to
get
consensus
among
communities
with
without
something
being
definitely
be
part
of
a
release,
so
I
would
be
finally
pushing
forward,
even
if
with
just
istio's
implementation,
I
I
do
know
that
console
not
console.
A
Linker
d
has
some
some
feedback
and
some
limitations
about
the
current
HTTP
route
service,
binding
model
that
Flynn
said
he'd
be
ready
to
to
share
in
the
next
couple
of
weeks,
but
in
the
meantime,
I
mean
I
think
that
our
our
strategies
thus
far
has
been
kind
of
to
push
forward
to
get
things
in
people's
hands.
A
You
know,
Linker
D
is
is,
is
one
Community?
This
is
one
Community,
another
Community
osm
to
other
community
right.
So
as
as
this
perklet,
sport
will
be
able
to
go
back
and
make
the
breaking
changes
that
we
need
to.
If
that,
if
necessary,
so
I'm
not
too
worried
about
moving
forward
with
what
we've
got
now
for
070.
A
B
F
Might
also
help
the
intention
is.
We
already
have
an
API
for
like
hcp
in
the
same
way
that
we're
talking
about
HTTP
route
and
for
Amsterdam.
The
hope
if
that
cfp
goes
through
would
be,
to
just
add
a
compiler
that
compiles
HTTP
route
to
that,
so
that
we
can
show
HTTP
route
being
used
for
that,
even
if
it's
semi-derived,
but
it
should
be.
You
know
just
a
good
idea
of
like
here's,
what
we're
heading
for
with
gamma
sorry
I,
don't
feel
great
today.
So
if
I
sound
terrible,
it's
because
I
feel
terrible.
E
Yeah
I
think
that
it's
likely
that
whatever
we
do
end
up
doing
facility
and
will
be
something
along
those
lines
that
it'll
be
like
a
cross-compilation
thing,
where
you
take
the
the
service
and
HTTP
route
and
end
up
turning
it
into
whatever
we
yet
the
last
seven
rounded
policies
we
already
have
for
some
things
anyway,.
C
For
console,
except
that
we're
also
in
the
process
of
updating
some
of
our
internal
constructs
to
more
closely
map
to
http
route.
E
Well,
I
mean
you,
and
the
good
part
is
that
every
if
everyone
is
using
that
sort
of
approach,
then
you,
if
we
do
decide
that
we
need
to
change
directions.
E
It's
not
a
massive
lift
right,
like
you
know,
like
we're,
changing
our
translators
to
translate
different
things
into
the
same
end
result
you
know,
so
that's
that
sounds
good
to
me
that
you
know
that
that
is
indicative
to
me
that
proceeding
with
only
one
sort
of
functional
implementation
right
now
is
probably
fine,
especially
for
how
experimental
this
is,
because
you
know
everyone
else
is
going
to
be
doing
something
similar
to
what
the
current
Implement
to
what
SEO
is
doing.
G
Yeah
but
Nick
you're
saying
same
thing
at
this
year,
but
as
I
mentioned,
there
are
two
issues.
Are
you
saying
that
you
are
following
the
age
one
ambient
model
or
are
you
following
the
old
sidecar
model.
D
G
E
That's
what
I
meant
yeah
is
the
fact
that
you
know,
and
probably
the
rest
of
us
who
would
who
are
a
bit
further
behind
that.
That
is
what
we
will
be
doing,
because
almost
everyone
who
has
a
service
manager
has
some
way
of
doing
this
sort
of
thing,
because
that's
like
you
there's
a
reason
why
we
did
it.
First,
it's
the
key
thing,
and
so
like
we're
going
to
be
translating
the
the
common
definitions
into
the
specific
thing
that
we
have
available
wherever
we
can.
E
G
A
All
right
Rob
does
that
kind
of
give
you
I'm
starting
to
forget
your
original
question,
but
does
that
kind
of
give
you
some
idea
of
where
folks
are
with
those
seven.
B
Yeah
I
mean
it
so
it
seems
like
if
our
end
goal
is.
We
need
to
be
able
to
demo
something
that
we
call
gamma,
and
you
know,
ideally
with
more
than
one
implementation,
add
kubecon.
If
that's,
if
that's
what
we're
working
towards,
we
need
to
include
something
and
a
Gateway
API
released
before
then
that
defines
what
that
is.
I
seems
like
070
is
that
Target
we've
got
a
number
of
kepts
merging
gaps
merging
soon.
B
A
That's
kind
of
how
I've
been
proceeding,
like
that's,
been
my
assumption.
A
I
think
that
anything
beyond
this
would
be
too
much
investment
at
this
point
in
a
particular
implementation
particular
model,
which
is
one
reason
why
I
I
was
completely
on
board
with
removing
policy
attachment
it
just
it
feels
too
soon
so-
and
this
is
not
that
much
you've
got
PR's
Associated
for
three
out
of
the
six
or
balance
I
think
just
numbers
just
not
updated.
Yeah
there
you
go
I
can
count
I
promise
yeah.
We
have
PR's
for
three
out
of
the
six
of
these
of
these
issues.
A
I,
probably
so,
let's
chat
about
conformance
a
bit
if
I
recall,
correctly
conformance,
is
only
required
for
the
beta
graduation.
Is
that
correct.
E
So
conformance
tests,
yes
in
terms
of
I,
think
this
is
talking
more
widely
about
widely
about
the
fact
that
you
know
what
conformance
level
are
the
gamma
gaps
right,
like
you
know,
and
so
like
the
technically
these
are
going
to
be.
The
gamma
stuff
is
going
to
be
implementation
specific
when
we
first
write
it
down
right
like
because
it's
experimental
it's,
you
know,
we
don't
have
any
performance
tests
which
doesn't
meet
any
of
the
criteria
we
have
for
extended.
So
therefore
you
know
like,
therefore
we
should
you
know.
E
We
should
be
clear
that
this
stuff
is
implementation,
specific
behavior.
Now
we
are
working
towards
defining
a
standard
but
they're.
Currently
you
know
it's
like
a
very
rough
standard.
It
does
a
draft
standard
like
you
know
like
that's.
Maybe
that's
maybe
that's
the
word,
because
that's
the
word
that
RFC
has
used.
This
is
a
draft.
You
know
this
is
a
a
draft
of
the
gamma
standard,
not
not
a
final
camera
standard
or
something
rather
than
using
experimental
or
something
else
that
has
other
meanings.
We
use
the
word
draft.
A
I,
like
that,
I
think
that
disambiguates
a
good
bit
of
some
of
the
confusion
that
might
pop
up
when
it
comes
to
all
the
how
weird
this
all
is
so
that
that's
fine
I
want
to
put
I'm
gonna,
go
and
put
something
about
draft
of
the
standard
in
there
and
open
a
new
tab.
Just
so,
I
can
remember
that
I'll
go
back
and
update
that
this
issue
when
it
comes
to
supporting
testing
mesh
implementations,
I
feel
like
this
could
be
pushed
out
of
scope
for
r070.
E
I
mean
I
think
so,
if
we
want
to
have,
if
we
want
to
start
talking
about
how
we
would
do
it,
that's
cool,
but
like
I,
don't
think
it's
100,
it's
not.
It
shouldn't
be
a
requirement
for
us.
I,
don't
know
it
should
be.
So
we
are
going
to
talk
about
this
and
we
are
going
to
have
a
standard
way
of
testing
this.
We
will
have
performance
but
like
having
a
conformance
suite
that
you
can
run
right
now
is
a
nice
to
have,
but
not
required.
B
Sorry
one
thing
that
I
hate
to
throw
a
wrench
in
all
of
this
you,
the
last
meeting
yesterday
there
was
a
doc
that
I
shared
a
proposal
that
we
simplify
and
and
bring
us
down
to
two
API
versions.
B
The
idea
of
alpha
or
preview
and
a
ga
API
version
that
kind
of
condenses
things,
and
it
raises
the
bar
for
both,
including
Alpha
and
I.
I,
can't
remember
the
specific
details
of
that
proposal
and
you
know
we
can
adjust
as
we
see
needed,
but
I
think
the
current
state
of
that
proposal
would
be
to
include
at
least
some
conformance
tests
as
a
prereq
for
even
including
something
like
an
API.
That's
this.
Every
part
of
that
proposal
is
open
to
discussion,
but
just
if
that's
something
we
want
to
push,
we
should.
A
That's
a
great
Point,
actually
fast,
I
missed
that
part.
I
missed
that
part
of
The
Proposal.
C
B
B
At
the
same
time,
if
you
write
conformance
tests
and
there's
already
multiple
implementations,
that's
also
very
hard,
because
in
some
cases
you
have
to
pick
a
winner
between
two
implementations
that
chose
different
ways
to
interpret
the
spec
yeah
so
hard
to
get
the
timing
right
on
this,
but
I
think
John.
You've
had
your
hand
for
a
while.
So.
D
Yeah
a
couple
of
thoughts,
one
like
I
think,
regardless
of
whether
it's
required
or
not
for
XYZ,
like
conformance
testing,
is
in
my
mind
one
of
the
very
most
important
priorities,
because
we
can
write
specs
all
we
all.
We
want
I'm
sure
that
all
of
us
are
going
to
miss
parts
of
it
and
do
funky
things,
because
smash
is
just
so
complicated,
especially
because
none
of
us
are
building
from
the
ground
up.
So
we're
all
trying
to
translate
and
there's
a
lot
of
complexity
on
the
inner
layers.
D
So
I
don't
know.
I
feel
like
to
some
extent.
Rob
like
the
gamma
is
unique
in
that.
For
any
other
feature,
it's
just
one
more
incremental
feature
on
top
of
Ingress
kind
of,
and
so
it's
fairly
easy
to
add
a
conformance
test
for
mesh,
it's
harder
because
we
don't
have
any
of
the
infrastructure
for
mesh
tests.
So
it's
kind
of
unique
and
I'm,
not
necessarily
saying
we
should
or
shouldn't
do
one
way
or
the
other.
D
But
if
we
decided
that
we
didn't
want
to
I
think
it's
reasonable
to
have
an
exception
for
gamma,
given
the
differences,
so
I
I,
don't
know
to
me
personally:
I
don't
want
to
slow
things
down
too
much,
but
I
also
do
think
conformance
tests
are
super
super
important.
So
maybe
we
decide
fine,
we'll
shift
something
without
it,
but
I
don't
want
to
de-prioritize.
It
certainly.
A
Lots
and
lots
of
hands
I
believe
it
was
cost
in
the
nick
than
Mike.
G
Okay
quickly,
so
gamma
CRS
mostly
are
HTTP
route,
so
I,
don't
think,
that's
a
problem
to
add
tests
or
whatever
to
to
them,
but
mesh.
Really
it's
more
about
behaviors
about
how
DNS
resolves
and
how
do
you
refer
to
things
and
and
how
you
know,
and
for
that.
C
G
We
can
break
the
problem
into
parts
and
first
have
agreements
about
how
DNS
were
resolve.
That's
the
most
recent
discussion
indicate
we
had,
or
you
know,
similar
behaviors,
because
mesh
is
really
more
about.
You
know,
do
exposed
Elementary
how
what
is
a
common
ground?
What's?
How
should
you
know
two
workloads
in
different
clusters
talk
with
each
other,
this
kind
of
stuff,
more
like
interruptions
and
API
CR
conformance
tests.
That's
my
opinion.
E
Okay,
so
I
guess
yeah
what
I
should
be
clear
that
what
I
am
saying
is
I
think
that
the
deliverable
we
should
focus
on
for
the
Gateway
API
070
release
is
a
document
that
outlines
what
gamma's
intense,
like
basically
a
summary
of
the
two
gaps,
or
something
like
that
that
we've
got
that
outlines
what
gamma's
intents
are,
what
is
included
in
the
current
draft,
spec
and
I.
Think
you
know
like
I
said
draft
is
a
carefully
chosen
word
and
so
such
that
to
make
it
clear
that
this
is.
This
is
a.
E
We
are
announcing
a
draft
spec
that
is
implementable
and
that
you
they're
then
for
the
next
release,
like
you
know
like,
because
we're
not
talking
a
long
release
time
frame
here
that
we
look.
That's
when
we
look
at
saying.
Okay,
now
we've
got
a
draft
spec
there's
enough
there
for
people
to
implement.
Therefore,
now
we
expect
people
to
implement
it,
and
then
we
start.
We
start
the
work
to
define
a
conformance
test.
Suite
I
think
the
point
that
Mike
made
about
having
performance
profiles,
slash
Suites,
I,
100
agree.
E
There
needs
to
be
a
separate
suite
for
con,
for
you
know
for
mesh
conformance
testing.
It
needs
to
be
completely
independent.
People
use
a
lot
of
the
same
bits,
but
it
would,
but
it
needs
to
be
a
thing
that
you
can
run
into
separately
to
the
to
the
sort
of
the
Ingress
main
gateway,
API
things,
but
I
think.
The
the
thing
we
need
to
focus
on
for
today
is
that
the
deliverable
for
070
is
a
document
that
outlines
the
draft
gamma
spec.
E
C
I
I
started
talking
about
clicking
the
lower
end
button
on
you,
yeah
I
I,
like
that
that
sounds
good
to
me.
The
intent
of
this
issue
was
not
necessarily
to
block
on
having
all
of
that
Machinery
available,
but
really
just
come
up
with
a
strategy
for
defining
how
gamma
conformance
fits
into
Alpha
Beta
if
it
goes
away
or
not
GA
and
experimental
versus
standard
channels,
and
just
defining
that
and
I
think
that
that
could
literally
be
a
paragraph
in
the
document
that
you're
talking
about.
A
Yeah
agreed
so
I
think
I'm
I,
think
I'm.
Next,
the
I
I
agree
with
everything
that
Nick
just
said.
A
I
think
that
the
thing
that
would
worry
me
about
making
conformance
tests
a
requirement
for
for
gamma,
specifically
kind
of
harkening
back
to
what
John
said
is
that
I
think
it
I'm
worried
about
marrying
us
to
a
particular
implementation
so
early,
because
right
now,
if
we
had
to
Pivot
to
one
of
the
Alternatives
considered
that
we
talked
about
way
back
when
it's
a
defining
the
service,
we
could
do
that
pretty
easily,
because
oh
new
draft
spec
right
there's
nothing
really
attaching
us
to
the
service
parent
ref
approach
when
it
comes
to
code,
but
when
it's
like,
oh,
we
have
to
change
conformance
test
for
this.
A
Even
if
it's
you
know
just
understanding
how
how
human
beings
work
once
you've
invested
some
some
work
into
doing
into
codifying
it,
and
you
write
a
conformance
test
and
having
people
conform
it
with
it.
It
feels
a
bit
more
official
than
the
support
that
we're
intending
for
right
now,
I
think
so
I'm.
A
For
that
reason,
I'm
in
favor
of
not
including
tests
right
now
but
I
to
just
to
kind
of
go
back
to
Rob
your
general
proposal,
I'm
I'm
generally
found
raising
the
bar
like
once
we
do
get
a
solid
Direction
with
gamma.
Once
we
do,
you
know,
get
the
direction
solidified
and
have
implementation
feedback
and
whatever,
then
you
know,
any
new
gamma
feature
should
have
conformance
tests
from
the
beginning.
I
think
that's
a
good
habit
like
to
get
the
project
into
I.
A
B
I
think
that's
fair.
Let
me
just
throw
out
one
Middle
Ground,
maybe
would
it
be
possible
to
say
we
should
have
a
framework,
a
design,
a
something
that
at
least
shows
we
are
making
progress
towards
conformance
I
I
will
feel
but
feel
better
if
we
don't
just
completely
ignore
conformance
that
that
we
we
clearly
have
some
momentum
towards
conformance
tests
because,
like
everyone
is
I,
think
in
agreement
that
it
is
an
important
thing
I
can
I
can
agree.
Okay,
it's
a
big
big
project.
We
may
change
rapidly.
B
C
Yeah,
there's
a
there's,
a
doc
that
was
shared
in
Stig
multi-cluster
earlier
today.
That
I
think
it's
very
similar
to
what
we
might
want
to
deliver
in
terms
of
just
a
intended
approach.
To
conformance
a
description
of
here
are
the
expected
behaviors
that
we
want
to
cover
under
a
performance
suite,
and
basically
it's
just
it's
an
intent
of
what
this
will
look
like,
even
though
we
don't
have
the
code
to
go
along
with
it.
Yeah
I
think
something
like
that
feels
like
a
reasonable
middle
around
I'm,
not
going
to
drop
that
in
the
notes.
A
Yeah
and
I
can
I
think
that's
a
great
idea.
Mike
can
I
I
can
provide
us
a
quick
update
on
where
I've
been
on
1340,
with
with
the
mesh
conformance
test
framework.
So
far,
so
we'd
I
think
this
is
actually
in
the
issue
itself.
We'd
agree
to
kind
of
use,
yeah
istio's,
Echo,
client,
server
and
package
it
into
for
Gateway
API
and
use
that
framework
for
mesh
performance
tests.
A
A
A
Yeah
so
I'm
doing
a
line
of
refactoring
and
and
trying
to
to
balance
it.
That's
one
reason
why
I'm
trying
I
want
it
to
kind
of
figure
out
what
the
just
clarify
that
that
tests
are
required
for
for
beta
only
but
I
can
I
can
try
to
thump
that
priority
a
little
bit.
A
On
my
end
time,
management,
wise
and
at
least,
let
me
push
what
I
have
it's
really
just
a
bunch
of
renaming
and
figuring
out
the
right
go
packet
structure
to
get
everything
to
compile
it's
easy
to
include
too
much,
then
they
go
from
like
trying
to
strip
it
down,
but
I
there
is
progress
being
made
on
it.
It's
it's
just
a
lot
of
refactoring
work.
A
Nick,
sorry,
you
still
have
your
hand
up
go
ahead.
Yes,.
E
Sorry,
no
I
actually
put
it
down,
put
it
back
up
again,
so
yeah
I
have
just
been
thinking
about
this.
While
we
all
talked
I
think
that
the
right
place
for
the
for
the
draft
spec
that
I'm
talking
about
is
Gap
1426,
which
is
John,
has
the
pr
open
to
add
some
additional
stuff
to
that.
I.
Just
I
hit
the
approve
button
on
that.
E
While
meeting
was
happening,
it
looks
like
it,
it
GitHub
says:
there's
a
conflict
there,
so
John
you
might
need
a
rebase
or
something
there,
but,
but
once
that's
in
once.
That's
in
then
I
think,
if
there's
another
PR
to
to
yeah
down
the
bottom
of
this
plant.
This
branch
has
conflicts.
If
there's
another
PR
to
add.
E
Like
a
section
that
says,
you
know
conformance
testing.
That
basically
says
you
know,
makes
the
points
there
will
be
a
separate
yo.
There
will
be
a
separate
conformance
test
Suite.
This
conformance
test
Suite
will
be
built
using
the
test,
client
and
above
just
just
a
bunch
of
points
like
that.
That
says
this
is
what
the
conformance
tests
are
going
to
look
like.
Then
we
can
kind
of
say:
okay,
look.
We've
got
a
plan,
we're
not
doing
this
harcock
there's.
No,
there
is
a
plan
to
do
that.
E
We
don't
have
to
do
it
yet
we
just
need
to
have
a
plan
for
doing
it,
and
that's
that's
really
what
the
point
of
a
draft
spec
like
this
is
to
say
you
know
here
is
a
draft
spec.
We
have
a
plan
for
taking
it
further,
but
here's
the
draft
specs
so
that
we
can
we're
publishing
this
so
that
we
can
be
clear
that
it
is
a
real
thing
and
that
way
you
know
that
way.
E
We
so
we
Mark
the
the
our
the
the
Gap
as
a
like
implementable,
but
like
draft,
we
don't
have
a
way
to
sort
of
communicate
that
in
the
status
I,
don't
think
we
put
it
as
implementable,
but
we
mark
it.
You
know
it's,
it's
you
it
is,
it
is
a
drop.
It
is
a
proposal
like
is
an
implementable
proposal
that
we
that
we
expect
people
to
try
out
and
see
yeah.
That,
in
my
mind,
that
me
we've
already
done
most
of
the
work
to
sort
of
write
down
the
behavior
that
we
want.
E
That
is
effectively
the
spec
right
now
so
adding
on
to
that
students
like
the
least
amount
of
work,
and
then
we
have
the
good
part
for
that
is
that
if
we
you,
if
we
as
the
broader
Gateway
API
Community,
do
decide
that
we
want
API
reviewers
to
review
something
we
can
say
by
the
way,
while
you're
doing
an
API
review.
Can
you
have
a
look
over
this
Gap?
E
That's
the
that's
the
key,
but
I
think
the
only
to
be
honest,
I
think
the
only
real
thing
to
do
there
is
to
make
sure
that
the
language
reflects
what
I
just
talked
about
and
to
add
the
sectional
conformance.
So
there's
actually
not
a
lot
to
do.
A
A
Don't
disagree
with
the
plan.
I
think
yeah,
some
of
the
language
run,
1426
has
to
change.
I'm
I
also
feel
like
1426
is
already
pretty
long.
Yes,.
A
Fair
enough
fair
enough
I'll
take
that.
But
there
is
one
other,
and
this
is
the
topic
that
I
have
on
the
agenda,
so
I'm
going
to
introduce
it
and
then
let
other
people
add
other
things
before
I
go
down
this
rabbit
hole.
But
there
is
one
other
thing
I'd
like
to
see
in
1426
before
we
like,
move
it
to
draft
spec
status
or
like
RFC
status,
which
is
this
top
issue.
But
before
that,
any
other
comments
on
Nick's
idea.
E
A
A
So
I
think
this
conformance
success
plan
whoops
will
just
be
oh
and
there
you
go
this
1426
and
we're
just
gonna.
Do
that
awesome
thanks
for
I
think
that's
Mike,
yeah
thanks
Mike
for
writing,
notes
as
always
cool,
so
I'm
gonna
pivot
into
this
next
topic,
because
I
think
this
probably
should
belong.
You
know
7-0
because
it's
probably
an
area
of
a
lot
of
potential
confusion
for
folks,
including
the
spec
we
started
talk
talking
about.
This
is
like
right
around
kubecon
season.
A
So
it's
no
surprise
to
me
that
kind
of
what
happened
to
it.
But
we
started
talking
about
just
disambiguating
how
gateways
like
Ingress
the
Ingress
side
of
Gateway
API
should
interact
with
gamma
routing
configuration.
There
is
a
draft
of
the
proposal
that
was
started
and
again
the
the
kubecon
happened
and
I
completely
forgot.
A
This
existed,
I
think
Mike
and
John
collaborated
on
this
or
maybe
Mike
you
just
did
it,
but
I
think
this
is
pretty
important
to
get
through
in
our
initial
Gap,
because
it's
really
codifying
the
ways
that
the
existing
thing
and
the
new
thing
should
interact.
A
E
So,
do
you
want
to
go
first,
Mike.
C
Sure
two
sentences-
this
could
probably
become
a
paragraph
of
the
existing
Gap,
rather.
C
This
could
possibly
become
a
paragraph
from
the
existing
Gap
rather
than
its
own
entire
thing
and
is
already
touched
on
by
John's,
pending
PR,
in
terms
of
how
it
defines
the
relation
of
consumer
routes
to
producer
routes.
It
similarly
defines
the
relationship
of
Gateway
routes
to
produce
her
routes.
Basically
following
the
tldr
from
this
but
yeah,
we
we
should
resolve
it
and
get
things
wrapped
up
here.
E
So
yeah
I
agree
looking
further
down
the
document:
the
idea
of
moving
host
names
inside
HTTP
route,
so
that
is
breaking
API
change.
That
would
mean
that
HTTP
route
would
need
to
move
to
V2
Alpha
One
and
go
back
to
Alpha.
That
is
a
polite
way
of
saying.
Tell
him
he's
dreaming
to
use
in
australianism
so
like
I
I,
don't
while
that
might
be.
That
is
a
nice
way
to
solve
this
problem.
I
do
not
think
it
is
practical.
E
You
know
like
it's
not
practical,
to
do
in
sort
of
any
reasonable
amount
of
time
without
because
it
is
a
breaking
API
change
massively
pricking
point
away,
so
yeah
I,
don't
I.
Don't
think
that
that
that
proposal
is
is
workable,
like
yeah
it
just
it's
to
be
a
change
to
the
API
at
this
point
in
the
existing
api's
life
cycle.
E
Could
we
could
we
end
up
with
a
you
know,
a
mesh
shroud
or
something
like
that?
That
added
that
in
totally
but
like
the
existing
HTTP
here
out,
is
not
changeable
easily
at
this
point,
without
significant
impact
should
we
should
we
make
it
so
that
we
call
out
the
you
know,
the
interaction
like
as
John
has
done
anything
yeah.
Absolutely,
that's
that's
a
complete
no-brainer.
It
needs
to
be.
It
needs
to
be
very
clear.
What
happens
if
you
have
a
HTTP
route
targeting
a
service?
E
That
is
also
a
back
end
for
another
HTTP
route
right
like
that.
That
behavior
needs
to
be
clarified
as
part
of
the
spec
and
it's
100
fine
for
the
existing
answer,
which
is
nothing
happens
right
like
that's
fine
like
you
know,
but
it.
C
Very
hell
of
a
drug
I'll
reread
this
more
closely,
but
right
now,
I
think
in
gamma
we
recommend
or
or
say
that
you
must
not
infer
anything
from
the
host
news
field
HTTP
route,
basically
with
the
intent
of
like
it's
not
useful,
it's
possible
that
we
don't
have
to
remove
it
from
that,
but
potentially
consider
adding
it
to
parent
reference
and
defining
the
interaction
between
the
two.
Might
it's
it's
a
path
to
explore.
That
I
think
would
not
require
the
breaking
API
change.
I
can
take
another
look
at
this.
That's.
E
A
Yeah
and
just
to
to
sell
the
technical
details
of
this
I
think
that
most
of
the
the
need
for
this
is
to
for
to
enable
things
like
using
one
HTTP
route
for
multiple,
like
for
multiple
host
names
and
and
for
Gateway,
and
for
mesh
and
I
mean
the
other
option
is
to
just
create
separate
HTTP
routes
and,
while,
yes,
that
there,
that
is
non-zero
burden
on
the
user.
I
want
to
acknowledge
that.
It
also
allows
us
to
not
make
a
break
and
change
to
a
spec
and
make
things
very
explicit.
A
B
I
think
one
of
the
things
I
I
want
to
agree
with
what
you're,
saying
and
I
think
one
of
the
things
that
we
have
been
thinking,
but
not
saying
very
clearly,
is
Gateway.
Api
is
probably
best
used
with
more
smaller
resources
than
a
lot
of
large
resources
and
that
that
kind
of
goes
along
with
what
you're
saying
I.
You
know,
although
you
could
make
a
very
large
HTTP
route,
I
think
in
general,
we'd
recommend
against
that.
That's
probably
something
we
should
document.
That's
just
something
like
that.
B
I
think
at
least
I
have
been
thinking
and
I.
Think
that's
come
up
in
conversations
before
as
well,
so
I
I
would
just
kind
of
use
that
same
train
of
thought
to
say.
Maybe
we
should
avoid
these
really
complex
scenarios
where
you
can
do
all
the
things
in
a
single
HP
route,
not
saying
there
can't
be
some
overlap,
but
when
it
starts
to
get
really
complex
like
this,
we
should
probably
just
say
it
shouldn't
work.
E
I
think
the
the
thing
I
was
going
to
say
is
the
thing
that
you're
trying
to
model
here
with
the
the
parent
refs
having
host
names.
You
can
actually
model
today
without
making
a
change,
because
the
post
names
is
a
list
and
there
is
an
implied
hostname
in
a
service.
So,
like
you,
you
don't
actually
need
to
make
a
change
to
be
able
to
model
the
thing
that
you're
talking
about.
E
If
you
included
all
three
of
those
names
in
the
hostname
thing,
the
hostname
matching
semantics
say
at
least
one
has
to
match,
not
all
after
match
so
like
it
could
work.
That
said,
I
agree
with
Rob
the
the
yeah
like
we
definitely.
The
API
is
built
in
such
a
way
that
we
have
expected
that
people
will
generally
use
more
smaller
objects
rather
than
larger
ones.
That's
one
of
the
reasons
for
the
many
limits
on
the
lists.
E
Aside
from
the
fact
that
there
are
you
know
having
limits
on,
this
is
just
good
design
practice
that
we
have
actually
had
a
request
already
to
increase
the
limits
on
some
of
the
lists,
because
someone
was
Auto,
generating
HTTP
routes
for
Ingress
from
a
Swagger
definition.
So
I
actually
have
an
outstanding
to
do
item
to
write
some
documentation.
That
says,
if
you
are
going
to
order
generate
routes
from
Swagger,
then
we
recommend
you
do
it
this
way.
Basically,
each
endpoint
should
be
a
separation.
E
To
appear
out
is
the
is
the
tldr
there,
but
there's
a
few
other
cases
like
that
that
I
expect
will
be
common,
so
yeah
yeah.
That
was
the
main
point
I
wanted
to
make,
but
yeah
I
just
also
realized
that
you
know
what
you're
trying
to
model
there
does
not
require
any
changes
to
the
spec.
Currently,
whether
or
not
we
should
prohibit
that.
Well,
that's
a
different
discussion.
G
Yeah
just
quickly
I
erased
this
before
as
an
application
developer,
creating
a
Helm
chart.
The
last
thing
I
need
to
do
I
want
to
do,
is,
to
put
you
know,
custom
host
names
and
customizations
for
for
HTTP
browser
that
are
typically
boundless
application
with
you
know,
whatever
host
names
and
mesh
names
are
going
to
be
used,
so
I
think
it's
a
bad
practice
in
general
to
have
any
hostname
in
HTTP
routers
and
should
be
avoided
as
the
best
practice
by
everyone
which
the
hostname
should
be
defined.
G
In
you
know,
the
Gateway
and
DNS
entries,
or
whatever
else
is,
is
outside
of
the
application
developer
power
to
control
it
so
I
think
it's
a
good
problem.
G
H
I
have
a
puzzle
about
this
hostname.
It's
mainly
these
certificates
as
a
service
owner
I
want
to
Define
my
own
certificate.
I,
don't
know
I
want,
like
just
you
know
my
certificate
managed
by
sdo
AWS.
You
know,
I
do
have
my
own
search
system
and
I
want
to
specify
a
search
along
with
the
a
name,
a
hostname,
and
if
we
remove
the
it's
a
puzzle
to
me,
if
we
remove
the
host
name,
how
do
I?
How
do
I
associate
you
know
as
a
service
owner?
H
How
do
I
associate
my
search
to
express
this?
Is
the
host
name?
I
want
to
use
and
I
have
a
search
signs
using
this
host
name
and
if
we
remove
the
hostname,
how
do
we
do
that.
E
So
that
in
the
Ingress
use
case,
that
is
what
the
hostname
field
is
for.
You
know
that's
that
sort
of
thing
is
what
the
why
there
is
a
hostname
in
the
HTTP
route.
E
It's
constant
said
in
chat
the
the
there's
no
place
to
hook
a
cert
onto
a
HTTP
route,
because
we
wanted
the
the
TLs
stuff
needs
to
be
hooked
to
a
listener
on
the
Gateway
for
Ingress
and
so
the
the
intent
there
is
that
the
certs
live
at
the
Gateway
and
you
have
a
listener
that
has
that
attached
and
probably
and
have
the
hostname
on
the
Gateway
that
matches
the
server
and
that's
where
you
do
the
hostname
and
the
search
matching
is
on
the
listener
level
at
the
Gateway
level,
and
then
you
know
and
then
that
that's
what
whether,
whether
or
not
you're
terminating
whether
yeah,
if
you're
terminating
right,
but
if
you're,
not
if
you're
doing
the
thing
that
you're
talking
about
where
you
have
a
client.
E
You
know
a
client
like
a
serving
cert
inside
the
Pod
that
you're
talking
about.
That's.
Actually
the
thing
that
we're
talking
about.
You
know
option
thing
with
the
you
know
you
can
roughly
call
it
re-encrypt,
although
that's
not
100
correct.
You
know
like
where
the
Gateway
acts
as
a
tier.
The
Gateway
is
data
part
a
data
plane
acts
as
a
TLS
client
and
does
and
like
talks
TLS
to
to
the
backend
service.
E
That
is
a
little
bit
we're
talking
about
what
we're
talking
about
here,
because
yeah,
because
the
in
in
all
of
those
cases,
the
the
host
name
is
only
an
indicator
for
the
data
plane
about
where
the
traffic
should
be
routed.
It
doesn't.
The
data
plane
is
not
expected
to
like
unwrap
the
cert
and
have
a
look
at
the
cert
and
check
that
the
sands
on
the
certain
match,
those
name
so.
H
Imagine
you
know
what,
if
my
data
plan
is
doing
that
you
know
I
got
to
imagine:
I
have
a
nbm
fleet,
you
know
teaching
the
MB
another
example
and
I
do
I'm
now
using
the
sdo
certificate.
Authority
I
want
the
customer,
they
want
to
bring
their
own
search.
You
know
what,
if
that's
the
case,
it's
the
the
proxy
Fleet,
it's
it's
intercepting.
You
know
using
the
customer
own
search
and
which
contain
the
name
of
the
HTTP
routes,
and
how
do
I
do
that
I?
Think
that's
my
confusion.
H
I
hadn't
wrap
my
head
around
it.
Yeah
do.
D
You
want
to
go
first,
yeah,
I,
I,
think
to
be
honest,
without
seeing
the
doc
on
what
you
guys
are
doing
in
bpc,
lattice
I
think
it's
hard
to
answer
that
question,
because
I
think
what
you
guys
are
doing
is
different
than
what
anyone
else
who's
doing
like
for
the
mesh
case.
We
had
already
established
previously
that
mesh,
TLS
or
ipsec
or
wired
or
whatever
mesh
is
used
for
identity,
is
outside
of
scope.
All
right,
that's
a
mesh
specific
concern
and
it
doesn't
need
to
be
represented
in
the
API.
D
H
E
E
I
just
jump
in
there
you
mentioned
TLS
use
cases.
That
is
what
I.
That
is
what
that
TLS
use
case
is
Doc
is
for.
Let
me
just
put
a
link
to
it
in
the
chat,
and
then
you
can
keep
talking
sorry.
A
Yeah
I
mean
that
that's
I
was
going
towards
at
TLS
use
case.nic
what
you're
describingly
one
feels
at
least
like
making
picking
the
dots
in
my
head.
Assuming
on
your
implementation,
it
sounds
like
that
particular
use
case
is
one
of
the
downsides
of
our
current
API
with
body
http.service,
because
it
creates
it
makes
service
HTTP
route,
one
to
one
where,
typically
it
it
hasn't
been
in
the
Ingress
use
case,
the
the
service.
A
How
about
how
do
I
describe
it?
The
words
are
escaping
me.
Basically,
with
with
meshy
things
or
with
encryption
things,
there
is
a
a
layer
that
is
missing
in
kubernetes
and
that's
what
the
backend
properties
get
the
TLs
use
cases
all
that
is
seeking
to
try
to
describe
and
for
mesh
it's
it's
kind
of
transparent
right,
because
we've
you've
got
side
of
our
proxies
that
are
handling
not
necessarily
sidecars,
but
you've
got
things
proxies
network
devices
that
are
doing
that
work,
Distributing
those
certificates
and
doing
that
stuff.
A
For
you
in
the
background
and
comparing
it
doesn't
have
to
think
about
it.
It
was
kind
of
by
Design,
but
without
something
orchestrating
that
transparently,
it's
really
difficult
to
represent.
What
you're
describing
in
kubernetes,
because
it's
just
not
historically
hasn't
been
one
of
the
priority
use
cases,
at
least
from
my
perspective,
correct
question
that
we
are
right.
G
G
I
think
I
think
we
need
to
maybe
the
best
time
to
start
discussing,
DNS
and
naming
because
certificates
I
mean
in
general.
It's
not
your
business
to
control
what
most
of
the
time
users
don't
want
to
mess
with
DNS
or
don't
understand,
TLS
and
all
those
things.
Normally.
G
You
expect
a
name
in
the
DNS
that
you
resolve
as
a
client
to
be
resolved,
to
something
you
put
in
an
Sni
header
to
be
automatically
mapped
to
a
certificate
which
is
validated
to
have
a
son
with
that
particular
name,
so,
usually
the
opportunities
to
have
any
opportunity
to
customize.
This
is
basically
confusing
leading
security
problems
and
complexity
and
for
people
who
typically
don't
understand
what
they're
doing.
G
In
particular,
we
do
this
by
putting
the
service
account
and
namespace
most
people
on
the
internet
doing
by
using
DNS
sense,
which,
again,
if
we
have
a
stable
scheme,
we
agree
on
about
how
to
name
things
and
it
can
be
implemented
in
DNS
and
then
arbitrary
clients
will
work
unmodified,
but
in
general
the
least
amount
we
we
put
in
the
API
and
the
more
we
we
leave
us
using
the
standards,
the
better
it
is
for
everyone,
if
I
make
any
sense,
because
anything
PLS
related
doesn't
make
sense.
Usually.
A
A
donut
screw
there
I'm
going
to
go
and
cap
the
discussion
for
with
respect
to
everybody's
time,
but
it
was,
you
know,
useful
and
riveting
as
always.
Hopefully
we
can
continue
to
push
this
forward
and
talk
about
this
a
bit
more
next
week.
Again,
if
you,
if
this
conversation
triggers
something
for
you
that
you
want
to
discuss,
please
put
it
on
our
agenda
for
next
week
and
I'll
see
all
of
you
later
take
care
thanks,
see.