►
From YouTube: Gateway APIs Meeting (APAC Friendly Time) 20210830
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
this
is
the
gateway
api
meeting
for
august
30.
2021.
we've
got
a
lot
going
on,
but
I
think
we
actually
have
a
lighter
agenda
than
normal,
which
is
great.
The
big
news,
obviously,
is
that
rc1
was
released,
so
that's
our
first
release
candidate
for
v1
alpha
2
of
the
api.
A
A
So
for
anyone
working
on
implementations,
good
starting
point
and
big
thanks
to
nick
for
actually
making
this
release
great
to
have
yet
another
person
releasing
a
version
of
this
api
yeah.
The
next
thing
another
little
bit
of
news
not
really
much
worth
discussing
too
too
detailed,
but
we
had
a
lot
of
discussion
around
kind
and
resource
as
api
machinery
cigar
architecture,
everyone
else.
A
I
got
great
feedback
all
around
and
although
this
is
not
approved,
I
believe
the
concepts
discussed
in
this
changed
api
conventions
were
largely
acceptable
to
everyone
on
that
call.
So
I'm
ex
I'm
expecting
this
to
get
in
as
it
is.
Essentially,
this
adds
guidance
that
if
you
have
a
known
set
of
resources
that
you
are
going
to
target
and
there's
no
room
for
ambiguity
of
what
a
kind
should
map
to
then
it's
acceptable
to
use
kind
instead
of
resource
in
your
object
reference,
and
I
think
we
can
make
that
argument
for
gateway
api.
A
So
that's
that's
really
the
the
gist
of
where
this
came
from
there's
I
obviously
there's
some
more
recent
feedback.
I
need
to
tweak
some
things,
but
I
think
this
is
going
to
make
it
in.
Hopefully
the
concept
at
least
seems
to
be
supported,
so
that
all
translates
to
us
likely
not
needing
to
make
any
changes
in
gateway
api
for
this,
which
is
really
what
we
wanted.
So
I'm
happy
about
that
before
I
move
on.
Did
anyone
have
any
questions
about
this?
This
topic
discussion,
whatever.
B
A
A
Historically,
I
have
thought
of
implementations,
at
least
of
the
ingress
api
and
I've
thought
of
implementations
of
this
gateway
api
of
things
where,
although
an
individual,
although
the
api
is
a
core,
may
not
understand
everything
that
the
extension
refs
refer
out
to
every
implementation
of
the
api
should
have
a
core
set
of
known
resources
that
it
supports.
A
So
as
long
as
each
implementation
has
no
trouble
map
mapping
from
a
kind
to
a
resource,
I
think
we're
fine
and-
and
that
seems
like
a
pretty
reasonable
expectation,
that
any
implementation
of
this
api
is
going
to
be
able
to
map
from
a
kind
to
a
resource
of
the
kinds
it
supports.
Does
that
does
that.
B
Add
up
to
you,
so
I
think
that
makes
total
sense.
What
I
think
we
should
do
is
we
should
have
an
implementation
guideline.
Just.
B
D
A
good
idea,
I'm
sorry,
sorry
to
be
late,
because
I
think
yeah
we
need
to
just
have
a
guideline
of
like
don't
do
this
it
will.
It
will
screw
you
over.
A
A
A
Yeah
yeah,
exactly
so
I
mean,
I
think,
that's
the
the
best
outcome
here
is
to
continue
using
kind
for
better
usability,
familiarity,
etc.
But
if,
if
someone
has
a
strong
preference
to
to
use
resource,
we
can
consider
that
I
just
I
personally
prefer
using
something
that's
more
familiar
based
on.
You
know,
upstream
references
everywhere.
B
A
Agreed
great
yeah
I'll
leave
it
there,
then
sorry
bowie
go
ahead.
A
Missed
no,
so
I
I
think
we
can't
close
this
until
probably
two
things
happen,
one.
We
actually
need
the
api
convention
to
be
updated,
so
this
needs
to
merge,
and
second,
I
think,
as
I
think
harry
suggested,
it
would
be
good
to
document
our
expectation
that
implementations
understand
the
kind
of
resource
mapping
and
don't
have
ambiguity
among
the
resort,
the
kinds
they
support.
I.
E
A
E
A
D
E
D
A
Cool,
I
guess
harry
it
looks
like
this
is
yours.
Do
you
mind
updating
the
title
here.
B
A
Thanks,
I
okay
next
one,
I'm
just
curious.
I
know
there's
a
few
implementations
working
on
v1
alpha,
2
implementation.
A
I
am
curious
if,
if
anyone
has
a
a
rough
goal
or
timeline
for
when
they
think
they
might
have
a
v1
alpha,
2
implementation,
ready,
no
pressure
does
not
need
to
be
very
specific,
but
just
curious.
How
that
that
progress
is
going.
D
Contour,
where
we
got
a
release
scheduled
in
like
two
or
three
weeks,
I
don't
know
if
we'll
make
it
in
in
time,
because
it's
pretty
substantial
coding
changes
the
if
not
the
one
after
that
I'll
be
like
four
or
five
weeks
and
probably
sort
of
kind
of
end
of
october
yeah.
So
I
I
would
it
we
should
definitely
be
done
in
the
one
at
the
end
of
october.
Possibly
earlier
just
depends
on.
You
know
how.
C
G
I
was
thinking
I
was
thinking
about.
It
actually
rob
just
kind
of
curious
like
what
just
what
you're,
what
you're
hoping
to
gather
out
of
this
just
kind
of
making
sure
people
are
actually
doing
it
or
what's
up.
A
No
well
yeah,
so
I
I'm
obviously
curious
who's
planning
on
supporting
v1
alpha
2,
but
I
I'm
also
curious
just
as
far
as
our
timeline
like
thinking
about
upcoming
releases,
about
beta
about
other
updates
along
the
path
here,
just
trying
to
get
a
feel
for
or
even
if
we
want
to
you
know,
we've
talked
about
a
blog
post
at
some
point
about
v1
alpha
2..
It
would
be
nice
to
have
some
implementations
that
we
can
show
are
already.
You
know,
usable
with
an
api,
so
yeah,
I
don't
know.
G
Yeah
so
we're
active
on
this
right
now,
but
we're
in
the
early
stages.
The
general
hope
is
just
to
have
it
by
kubecon.
E
D
Yeah
agreed,
I
actually
think
we
probably
need
to
write
down.
I
don't
think
we've
actually
written
down
anywhere,
that,
like
portability,
is
an
explicit
goal
and
define
what
that
means.
So
we
probably
need
to
do
a
little
bit
of
work
there
to
to
do
that
as
part
of
the
beta
graduation
criteria.
In
my
mind,
beta.
A
Later
this,
this
is
actually
yeah.
I
agree
we
should
talk
about
this
and
I
actually
have
it
a
little
bit
further
down
on
the
agenda,
so
good
segue,
there
yeah.
I
completely
agree
anyone
else
jeff.
I
noticed
that
you
were
about
to
say
something
like
maybe
yeah,
we're,
probably
looking
at
mid-november,
okay
and
that's
console
or
yeah.
Okay,.
A
Cool
and
bowie,
I
don't
know
if
we
have
a
timeline,
we,
I
know,
we've
said
q4.
E
So
v1
alpha
2
will
likely
arrive
before
that
yeah,
I
I
sure
would
hope
so
what
I'm
saying
is
for
gke
that's
sort
of
we're
trying
to.
E
Right
as
soon
as
the
release
is
cut
yeah,
we
would
be
seeing
how
to
cut
over
to
it.
Yeah.
D
Cool
yeah,
I
feel,
like
the.
I
don't
think
that
the
that
the
implementation
availability
should
impact
cutting
rc's
or
cutting
the
final
version
of
the
spec,
the
rc
yeah.
It
would
get
started
on
the
spec.
I
think,
and
we
can
cut
the
final
version
without
being
ready
to
fully
announce
that
because
nobody's
got
it
implemented.
Yet
I
think.
A
Yeah
yeah,
so
I
I
agree
with
everything
there
and
it
looks
like
we're
going
to
have
a
decent
chunk
of
implementations
ready
by
kubecon.
That
seems
to
be
a
common
goal
here.
So
maybe
we
can
have
something
like
more
in
public
around
that
time.
Time
frame
cool
great
to
see,
progress
here
and.
D
B
We
don't
track
others,
but
I
think
something
that
might
be
useful
and
I
probably
don't
think
we
have
the
focus
on
the
call,
but
things
like
k,
native
sort
manager.
You
know
they
also
integrate
in
a
lot
of
this.
They
don't
directly.
I
don't
know
they
somehow
integrate
with
us
right,
they're,
not
direct
implementers.
A
Yeah
yeah
and
I
know
yeah
actually
on
that
note,
I
should
check
in
with
ingress
nginx
as
well,
because
I
know
they've
been
working
on
this
too,
so
be
interesting
to
see
what
their
timeline
is,
but
yeah
cool,
too
cool
to
see
progress
here,
cool
all
right.
So
the
next
thing,
which
I
think
is
kind
of
a
natural
follow-up
to
that
is
what
we
need
for
rc2.
A
So
obviously
we
released
rc1
last
week.
Thank
you,
everyone
great
to
get
that
one
out.
I
think
this
is
really
a
rough
summary
of
what
we
need
to
get
in
or
want
to
get
in
for
rc2,
but
anyone
feel
free
to
add
to
this.
I
think
some
of
these
are
more
or
less.
I
I
don't
know.
I
I
think
we'll
have
more
discussion
around
the
port
thing
than
anything
else.
The
rest
do
not
feel
too.
A
I
I
don't
know.
I
I
feel
like
these
are
all
pretty
straightforward
beyond
that.
So,
susan,
I
think
this
it
looks
like
you've
updated
this
I've
noticed
the
tests
are
all
passing
on
this
any
any
particular
status
update
here,
or
do
you
need
just
another
round
of
review
from
us.
F
Yeah,
I
think
I
mean
this
change
basically
is
combined.
I
mean
the
comments
from
the
the
previous
v10
here
and
some
you
know
common
sense
changes
under
the
validation
test
cases.
It's
pretty
straightforward,
the
kindly
review
and
let's
push
this
in.
A
Okay,
great,
thank
you.
Thanks
for
taking
this
on,
this
is
going
to
help
a
lot
with
780.
I
think
this
takes
out
a
chunk
of
the
comments
and
feedback
there.
So
thanks
for
getting
this
one
in
I'll
take
another
look
after
this
meeting
cool.
F
A
And
the
other
one
that's
in
flight
here
is
just
a
whole
bunch
of
a
little
small
api
changes
for
the
most
part,
mostly
around
document
go
docs.
Specifically,
there
are
a
couple
renames
in
here.
One
was
suggested
by
cal.
This
was
controller
to
controller
name.
I
think
that's
slightly
clearer.
It
does
match
what
we've
seen
in
upstream,
where
we
tend
to
we've
started
to
add
name
as
a
suffix
to
fields
like
this.
A
It
does
unfortunately
contra
conflict
with
ingress
class,
where
we
just
have
a
controller
field,
not
a
controller
name
field,
but
as
cal
says
you
know,
this
is
a
good
opportunity
to
make
something
better,
instead
of
being
stuck
with
what
we
had
before,
I
I
don't
have
a
strong
feeling
either
way,
but
I'm
fine
with
controller
name.
A
The
other
notable
change
here
is
admitted
condition
has
been
renamed
to
accepted
and
defaults
to
unknown
instead
of
false,
so
yeah,
that's
that's
what
we
have
going
on
there,
there's
obviously
a
lot
more
in
here
that
I
can't
you.
I
don't
think
we
have
enough
time
to
cover.
I
know
I
have
some
some
comments
in
here
that
a
lot
of
comments.
Thank
you
that
I
need
to
follow
up
on
so
yeah.
A
If,
if
anyone
has
extra
cycles
to
review,
I
will
be
working
on
this
later
today,
but
I
think
this
combined
with
susan's
pr
gets
us
probably
90
of
the
way
through
feedback
on
gateway,
api,
sig
network
review,
so
we're
getting
awfully
close
here.
A
I
know
tim
still
had
some
work
to
do
as
far
as
additional
types
to
review
and
andrew
it
sounds
like
he
doesn't
want
us
to
block
without
his
feedback,
but
if
we're
still
open
and
to
feedback
in
another
week
or
so
he'll
have
more
time
to
review
so
we'll
see
when
that
time
gets
here
yeah.
So
that's
an
update
on
v1,
alpha
2
feedback
again
feel
free
to
run
through
that
pr
and
make
sure
that
we
haven't
missed
anything,
but
I
think
we're
we're
getting
close
now.
The
big
one.
A
I
know
there's
been
some
discussion
around
that
and
we
had
some
discussion
last
week
around
this
concept.
Some
concerns
specific
to
all
ports
that
it
could
be
difficult
or
impossible
for
some
implementations
to
support.
A
C
Hey
rob
james.
Is
this
really
a
widely
designed
feature
because
I
read
the
thing
I
read
the
information
they'd
gathered
and
it
really
seemed
like
there
was
a
few
pretty
niche
sorts
of
applications
where
this
would
be
useful.
C
D
Controllers
feel,
like
that's
a
fair
point
james,
but
in
my
mind
the
one
that
I'm
worried
about
here
is
that
this
is
the
one
shot.
We
have
to
do
this
if
we
do
have
to
walk
this
back
and
change
something
later,
it's
going
to
be
really
hard.
D
If
something
comes
like
you
walk
back
in
which
the
cost,
the
cost
is
one
layer
of
indentation
in
yaml,
which
does
kind
of
suck
agreed,
but
the
the
cost
of
not
doing
it
is
that
later
on,
we
will
need
to
do
like
a
major
version
rep
to
change
this.
D
Like
I
feel
like
in
the
in
the
cost
trade-off
department,
the
the
risk
that
somebody
is
like
that
later
on,
people
might
be
like
yeah.
I
want
to
do
ip
forwarding
or
some
other
thing
that
required.
That's
like
I
don't
care
about
ports,
you
is,
is
non-zero
and
then,
if
we
don't
do
this
now,
then
if
we
do
want
to
handle
those
use
cases
later,
it
will
need
a
major
api
version
rev,
because
we
don't
want
to
do
this
now.
E
Yeah,
I
think
that's
basically
where
the
discussion
was
pushing
is
that
we
know
there's
these
use
cases
out
there
and
if
we
could
set
it
up
so
that
it's
not
very
awkward
later,
then
maybe
this
is
a
worth
a
trade
off.
A
Yeah,
I
think
it's
worth
clarifying
that
it's
not
necessarily
just
all
ports.
All
ports
is
a
proposal
that
we
know
is
very
real
and
and
something
we
can
link
to,
but
you
know
just
even
port
ranges
or
or
other
things
that
are
currently
impossible
in
upstream.
That
could
be
useful.
Potentially
here
I
recognize
that
anytime,
we
have
to
add
more
yaml
indentation
it
it's
not
a
great
user
experience.
A
So
probably
part
of
this
is
we
should
walk
through
exactly
what
conversion
logic
would
look
like
with
and
without
a
struct
like.
If
we
have
an
it
now
can
we
do.
We
have
a
path
forward.
That
is
not
terrible
for
conversion,
or
are
we
just
kind
of
stuck
with
it,
but
I
I
generally
I'm
certainly
interested
in
in
not
locking
ourselves
too
much
in
in
this
one
direction,
given
that
we're
already
seeing
the
limits
of
that
in
upstream-
and
it
would
be
a
shame
to
do
the
same
thing
all
over
again,
yeah.
C
I
I
honestly
don't
feel
super
strongly
if
you
say
if
we
have
like
if
we
turn
ports
into
a
struct,
and
you
have
port's
number
that
doesn't
feel
like
a
different
sort
of
problem
to
extend
that.
Then,
if
you
say
oh
well,
in
the
future,
we
have
a
ports
int
and
we
have
a
sibling
structure,
which
is
a
port
port
value
or
port
spec
struct
like
it,
doesn't
really
seem
substantially
different.
A
Yeah
and
that's
I,
I
think,
you're
probably
on
to
something
there
and
it's
it's
worth
digging
into
that
a
bit
more.
I
I'm
curious.
If
part
of
the
reason
it's
challenging
is
because
service
is
a
v1
api,
so
you
can't
even
really
you
really
can't
change
anything
with
that,
whereas
we
have
a
bit
more
flexibility
until
we
reach
ga.
A
A
I
don't
even
know
if
it
was
a
suggestion
as
much
as
a
question,
but
one
of
his
comments
in
the
sig
network
review
was
have
we
considered
making
port
optional,
which
feels
related
to
this
discussion.
A
A
Yeah,
I
I
think
we,
I
think
what
harry
said
in
chat,
is
true,
that
there
is
precedence
for
making
a
required
field
optional
and
not
considering
it
a
breaking
change.
You
need
a
new
like
you
need
a
new
version,
but
I
think
you
can
make
that
transition
all
right,
but
it
is
easier
if
you're,
starting,
if
you're
starting
from
an
optional
state
or
potentially
easier,
it
gets
a
little
weird
like
if
it's
optional
for
tcp
or
udp.
What
is
it
just
kind
of
implementation?
Auto
assigns
you
a
port
and
that's
fine.
B
I
mean
that's
optimizing
for
future
use
cases
that
we
don't
understand
today,
so
I
mean
I
had
to
err
on
the
side
of
you
know,
let's
optimize
for
today,
and
if
you
have
a
path
forward
in
future,
let's
just
point
it
because
you
can
make
that
change.
If
it
was
like
a
breaking
change,
then
doing
it
has
some
precedence,
but
otherwise
I
don't
see
a
precedence
for
doing
this
today.
E
B
Yeah
I
mean,
if
you
have
a
if
you
have
a
field
that
is
optional,
and
you
make
that
required
your
this.
You
might
have
like
a
you,
might
have
a
like
any
spec
that
you
define
or
any
you
know
any
you
could
break.
You
could
potentially
break
a
user
right,
but
let's
say
you
have
a
field
that
is
required
today
and
tomorrow
it's
optional.
A
A
So
as
as
I
understand
how
we
do
that
in
upstream,
like
how
we
transition
a
field
from
required
to
optional
is
we
have
to
do
it
over
two
or
three
different
release
cycles,
and
the
idea
is
that
you
have
to
document
it
well,
and
you
have
to
be
able
to
round
trip
between
the
two
versions
kind
of
thing,
and
so
you,
you
need
to
start
loosening
that
validation
before
you
truly
make
the
field
optional.
A
D
The
I
think
that
the
I
feel
like
to
me
you
that
making
a
required
field-
sorry
yeah,
making
it
quite
feel
optional,
does
feel
like
a
change
that
could
go
pretty
badly
wrong,
because
the
the
thing
that
the
thing
the
risk
that
you're
running
there
is
like
the
what
happens
if
it's
not
supplied
behavior
the
like
the
null
behavior
yeah,
I
think,
as
james
said
in
the
chat
like
you,
the
it
makes
sense
for
hp
and
hbs.
D
I
guess
because
it's
like,
if
you
don't
you
know,
or
in
the
case
that
it's
like
the
behavior,
is
that
if
you
don't
supply
a
port,
then
the
then
the
controller
will
assign
you
one
that
is
kind
of
nice.
That
kind
of
hits
to
what
one
of
the
other
things
that
tim
was
saying
is
like
you
know.
Why
should
I
need
to
configure
it
if
I
don't
care
but
like
the?
D
So
that's
true,
they
shouldn't
know,
that's
required,
so
that
helps
yeah
yeah
yeah.
So
I
don't
know
I
feel
like
the
it
feels
to
me,
like
the
options
are
like
we
move
to
a
struct,
because
then
you
can
do
this
stuff
inside
the
struct
a
little
bit
easier
than
you
can
if
it's
fields,
one
level
higher,
but
it's
not
again
james's
point
is
fair
that
it's
not
that
much
easier.
You
still
got
to
change
things
from
quite
optional
and
stuff
like
that
inside
the
struct.
D
So
the
the
sort
of
I
think
the
the
key
thing
is
like
the
the
cases
that
people
are
asking
for.
I've
definitely
asked
for
upstream
stuff
are
the
all
ports
one
and
the
you
know,
and
port
ranges
you
know
it
does
suck
to
have
to
make
like
20
different
port
entries
for
if
you've
got
20
different
port
20
reports
on
this
now
or,
if
you're
doing
some
like
tcp
protocol.
D
That
requires
you
to
expose
like
100
ports,
that's
going
to
make
your
yaml
extremely
unwieldy
and
having
a
way
to
do
that
would
be
like
having
a
spot
to
be
able.
To
put
that
later
would
be
nice.
D
And
I
think
yeah,
so
I
think
it
feels
to
me
like
you
know
those
are
the
two.
Those
are
the
two
use
cases
that
we
should
do
that.
We
should
consider
here
because,
like
I
know,
if
anyone
else
has
used
firewalls
but
having
firewall
like
you
know,
having
firewalls
that
can't
do
that
stuff
really
sucks.
A
The
the
more
I'm
thinking
about
this,
the
more
I
I
I
don't
know
I
mean
it
it
even
just
the
the
idea
of
an
optional
port
does
not
sound
as
bad.
When,
if
you
look
at
the
pr
and
my
initial
response
to
tim,
I
was
saying:
oh,
we
probably
shouldn't
do
that
essentially
and
and
now
I'm
I'm
beginning
to
be
won
over
by
that
being
not
a
bad
idea.
A
I
it
leaves
a
lot
more
room
for
flexibility
and
it's
something
that
in
a
lot
of
cases,
you
know
for
hp
hps.
A
We
can
generally
determine
the
protocol
that
the
port
that
someone
is
going
to
want
based
on
the
protocol
and
for
others,
we
could
auto
assign
worst
case,
which
does
not
seem
that
bad
either,
especially
now
that
we're
requiring
listener
name.
I
tend
to
agree
with
what
others
have
said
so
far.
I
don't
know.
E
A
That's
that
that's
it
I
mean
if,
if
the
whole
idea
is
that
we
want
to
support
all
ports
or
port
ranges
or
some
other
extension
mechanism,
we
need
a
way
to
make
port
the
single
hint
optional
at
some
point,
even
if
it
doesn't
start
that
way
so-
and
I
think
this
this
goes
to
what
james
said
it's
kind
of
like
it
doesn't
matter
as
much
whether
or
not
it's
in
a
struct,
it
seems
like
we
just
need
a
path
for
it
to
become
optional
and
to
become
extended.
D
I
think
your
point
is
fair.
Rob
that's
like
there's,
actually
not
that
many
downsides
to
having
to
be
optional
right
away.
C
A
I
think
that
is,
I
think,
that's
a
very
reasonable
assumption
to
make.
I
don't
know
how
prescriptive
we
need
to
be
about
what
controllers
choose
to
assign
as
ports
for
a
given
protocol.
I
think
we
should
be.
D
Is
that
we
must
be
100
prescriptive,
we
don't
want
to
leave
any
room
for
implementations
to
be
different,
so
it
should
be
it's
optional.
If
the
protocol
is
http
or
https
or
tls
and
end
the
port
is
not
supplied,
then
it
will
default
to
these
if
it
is
tcp
route
for
layer
four
protocols,
if
the
port
is
not
supplied,
the
implementation
must
auto,
assign
a
port
and
make
it
available
in
the
status
done.
A
Yeah,
that
seems
fair,
I'm
trying
to
think
of
some
edge
cases
here,
like
a
finite
set
of
ports
available.
Something
like
that,
but
really
that
that
seems
like
a
reasonable
set
of
default
events.
A
E
And
that
yeah,
in
that
case,
I
think
probably
we
should
go
with
the
simplest
thing,
which
is
that
the
defaulting
is
like
a
syntactic
thing,
almost
as
opposed.
D
To
trying
to
be
clever,
but
that
in
that,
in
that
specific
case,
though,
for
http
https
and
tls
there
are,
there
are
additional
routing,
discriminators
aside
from
port,
that
we
can
use.
So
in
those
cases,
it's
the
the
behavior
that
I
would
expect
as
a
consumer
of
the
api
is
that
if
you
specify
multiple
http
listeners,
whether
or
not
they
specify
ports,
if
they
all
end
up
on
the
same
port,
then
they
all
get
multiplexed
using
the
the
host
header
like
using
the
host
details.
D
E
A
Okay,
yeah,
I
think
that
makes
sense.
I
just
I'll
need
to
think
through
some
some
edge
cases,
a
bit
more
like,
I
think,
there's
some
in
cluster
proxies
that
at
least
in
some
cases
prefer
not
to
be
deployed
with
access
to
privileged
ports,
or
things
like
that.
You
know
like
I
feel
like
there's
some
weird
edge
cases
around
this.
E
E
A
E
A
D
That
harry
just
mentioned
in
chat
that
we
should
time
box
this.
I
do
think
that
there's
a
slightly
orthogonal
discussion
that
is
relevant
about
what
the
port
actually
is
like
it's
the
outside
port
right
destined
for
the
gateway
needs
to
consider
so
like
in
cluster
proxy,
should
really
be
saying
that
port
as
the
port,
that
the
stuff-
that's
not
in
the
cluster
is
the
port.
That's
the
the
port
is
the
the.
A
A
Yeah,
okay:
anyone
want
to
volunteer
to
create
an
issue
or
follow
up
with
this
one.
A
Yeah
awesome
thanks
all
right.
Next
one
is
removing
extension
ref
I've
covered
a
little.
I
I
referenced
that
as
a
an
item
down
here
as
well
harry
your
gap
is
already
merged.
I
just
had
one
question.
I
think
you've
already
responded
to
and
whatever,
but
I
I
wanted
to
bring
it
to
a
broader
audience
here
as
well
about
extension
ref
and
it
when
it
when
we
remove
it
from
routes.
A
What
that
looks
like,
but
in
this
context
all
I
all
I
want
to
say
is
this
is
something
that
is
in
scope
for
rc2.
In
my
mind,
any
anyone
dispute
that,
like
I
think
this
feels
like
it,
belongs:
okay,
next
one
and
and
we'll
come
back
to
that
momentarily.
A
Actually,
no,
let
me
move
on
to
that
one
quickly,
because
the
next
one's
gonna
be
a
discussion
too
so
harry.
I
think
you've
updated
this
pr
already
at
first.
What
you
had
here
is
you
left
matches
alone.
In
so
tcp
udp
and
tls
routes
all
had
a
matches
concept,
but
the
only
match
was
an
extension
wrap
and
we,
you
know,
we
determined
that
we
didn't
really
have
a
good
use
case
for
an
extension
ref
match.
A
But
that
meant
that
by
removing
this
we
don't
have
anything
to
match
on
for
tcp,
udp
or
tlss
hostname,
but
we
don't
have
a
match.
Instruct
anywhere
does
it
feel
appropriate
to
remove
the
entire
match.
This
is
to
clarify.
This
is
something
that
I
think
I
I'd
suggested,
but
I
didn't
want
to
be
the
only
one
suggesting
this
I
so
wanted
to
get
some
more
visibility
on
this.
Does
this
change
feel
appropriate
on
these
l4
route
types.
A
Is
it
just
empty
it?
It
is
the
the
option,
is
it's
either
empty?
We
just
have
a
matches
struct
that
has
nothing
in
it
or
we
don't
have
a
mattress
struct
at
all
and
then
the
only
thing
that's
in
tcp
route
is
a
list
of
back
and
reps,
which
is
what's
currently
proposed.
E
A
Yeah,
like
I
know,
there's
like
we
have
open
issues
already
for
destination
address
and
port
matching,
and
I
know
that's
not
like
we
want
to
get
in
so
I
know
this
is
probably
going
to
return,
but
in
its
absence
I
think
it's
less
confusing
to
just
not
have
it
than
to
have
an
empty
struct,
where
you
can't
specify
anything.
So
I
think
this
is
fine,
but
that's
a
big
agreement.
D
E
B
D
I
don't
know,
I
think
the
thing
I
like
about
this
is
that
it
makes
the
story
clear
for
sort
of
our
initial
launch
to
the
world
that
tcp
route
right
now,
it's
a
it's
a
one-to-one
thing.
Yeah,
you
get
a
list
report
on
the
listener,
goes
to
a
single
backend
service
industry
and
then
later
on,
we
can
make
that
more
complicated,
but
it
makes
the
the
story
simple
to
tell
to
start
with
yeah.
D
A
A
Cool
okay,
well,
yeah,
that
I'm
glad
that
we're
in
agreement
there,
if
anyone
has
any
any
last
concerns
I've
raised
them
soon
on
here.
Otherwise,
I
think
we
can
just
get
this
one
in,
and
that
will
be
one
last
thing
between
us
and
rc2.
A
All
right
so
covered
this
one,
the
next,
the
last
two
items
I
had
on
this
list.
One
was
custom
match
types
for
http
route.
I
feel
like
that
could
take
a
little
bit
of
discussion,
so
let
me
run
through
what's
currently
proposed,
as
v1
beta
1
graduation
criteria.
A
I
think
this
is
likely
le
sorry
that
yeah
beta
graduation
criteria.
I
think
this
is
likely
less
controversial.
I
just
wanted
to
raise
it
as
something-
and
this
is
something
like
this-
is
the
cap
that
we
needed
to
create.
It's
mostly
a
formality
for
becoming
part
of
the
kate's
io
api
group,
and
one
of
the
things
with
every
cap
is
you
need
this
concept
of
graduation
criteria
for
each
stage
and
obviously
one
of
our
goals
is
to
get
to
beta
and
since
that's
our
next
stage,
I
needed
some
graduation
criteria
here.
A
I
have
a
list
here
that
feels
pretty
non-controversial,
but
I
wanted
to
highlight
it
and
make
sure
that
people
were
aware
of
what
I'm
proposing
here
and
that
nothing
was
too.
You
know
that
I
didn't
miss
anything
or
that
I
didn't
have
anything
in
here.
That
was
too
over
the
top.
A
So
I
don't
think,
there's
much
to
say
here
other
than
just
this
exists.
If
you
have
suggestions
for
how
to
improve
or
change
it,
just
let
me
know
or
add
a
comment
here
all
right.
I'll
keep
on.
D
Yeah,
that's
what
it
was:
yeah
yeah
that
there's
some
contract
that
we've
all
agreed
on
that
about
what
portability
means
and
the
yeah
yeah
we've
agreed
on
what
portability
means
and
that
you
know
implementation
that
there
is
portability
between
implementations.
Yes,.
E
Something
probably
that's
like
we
could
just
add
that
to
that
initial
conformance
test,
so
it
seems
like
it's
yeah,
you
don't
mind.
D
That
probably
makes
sense
yeah,
but
I
think
I
feel
like
one
of
the
primary
values
like
one
of
the
biggest
like
user
end
user
value,
that
they're
going
to
get
out
of
this
api
is
portability
for
something
between
implementations,
probably
routes
between
gateways.
I
think
off
the
top
of
my
head,
but
but
portability
is
like
a
big
win
for
the
end
user.
D
So
I
think
we
need
to
enshrine
it
somewhere
as
by
the
goal
of
the
project,
and
you
know
how
to
make
sure
that
we
have
tests
to
check
that.
That's
the
case.
A
Yeah
that
makes
sense
cool
all
right.
I
think
I
think
that's
it
just
a
reminder.
This
kept
exists.
I
it's
such
a
formality.
I
don't
think
it's
really
blocking
anything,
so
it
doesn't
need
a
ton
of
attention,
but
if
anyone
has
some
extra
cycles
to
take
a
look,
I
think
it's
relatively
close
other
than
I
should
update
this
a
little
bit.
E
One
question
is
this:
does
this
go
into
the
case?
Sorry,
does
this
go
into
the
case?
Release
cycle
rob
like?
Are
we
specifically.
A
Targeting
it
or
something
or
is
it
just
kind
of
no
kind
of
it?
It's
kind
of
hanging
out
there?
One
thing
this
allows
us
to
do
a
little
bit
easier.
Is
it
allows
us
to
get
docs
in
because
we
we
now
are
owners
of
a
cap
and
docks
often
are
tied
to
caps.
A
A
You
know
enhancements
from
alpha
debate
at
a
ga,
but
I
think
that's
it
again
again
we're
kind
of
blazing
our
own
trail
here
and
it's
I
I
was
talking
with
john
from
cigarch
about
this
and
it
sounds
like
the
cap
isn't
completely
necessary,
but
it's
just
helpful
for
process
and
so
just
going
through
it
yeah.
Okay,
I
had
the
same
question.
B
A
All
right,
so,
the
last
one
that
I
want
to
discuss
today
is
this
thing
as
part
of
removing
extension,
ref
matching.
We
really
realize
that
you
know
this
extension.
Ref
matching
probably
doesn't
make
a
lot
of
sense
or
we
didn't
have
clear
use
cases
for
it,
but
there
are
you
know
we
got
some
feedback,
I
think
from
dan
and
the
sig
network
review
that-
and
I
I
think
elsewhere
as
well,
that
implementation
specific
matching
is
weird
as
we
have
it
right
now.
A
A
I
don't
know
another
kind
of
string
match
type
that
we
don't
support
in
our
core
api.
I
know
one
that
has
has
gotten
some
interest
is
like
a
template,
templatized
matching
as
an
idea.
These
are
things
that
could
technically
get
you
know
thrown
into
an
implementation
specific
match,
but
I'm
not
sure
that's
the
best
way
to
represent
those
or
extend
match
types.
A
So
this
this
proposal,
that
originated
from
slack
or
github
comment,
I
forget
exactly-
is
really
just
suggesting
that
we
keep
these
core
or
extended
match
types,
but
then
allow
for
free
form.
Qualified
name
match
types
that
are
vendor
specific.
A
B
B
We
are
asking
a
bit
too
much
from
the
user.
Remember
that
this
is
how
users
do
matching
of
traffic
to
forward
requests
right.
It's
him
and
it's
that
that's
the
core
use
case
right
and-
and
this
is
a
little
sensitive
area,
because
mistakes
are
easily
can
be
easily
made.
B
If
you,
you
know,
play
around
with
types
or
you
know
you
have
typos
and
in
my
experience
those
mistakes
are
far
easier
to
make
than
we
assume
and
the
consequences
of
those
mistakes
are
often
hard
to
foresee,
or
maybe
they're
larger,
usually
than
you
foresee.
So
you
know,
having
like
me
like
having
simpler
number
matching.
Criterias
are
usually
more
maintainable
even
for
complicated
use
cases
rather
than
you
know,
going
for
something
like
regex,
which
is
something
I
personally
always
advise
users
to
not
use,
although
there
are
some
use
cases
for
that.
B
So
you
know
something
like
parameterized
matches.
Yes,
that
is
there
is.
There
is
some
use
for
it
with.
I
think
filters
in
my
experience,
but
I
mean
using
matching,
for
that
is
it
can
be
very
tricky
so,
and
I
think
today
we
don't
have
very
concrete
use
cases
so,
rather
than
you
know
complicating
this
making
this
more
extensible.
B
E
I
think,
from
my
perspective,
we
should
figure
out
if
we
should
delete
implementation
specific,
so
implementation
specific
was
almost
a
solution
to
a
problem
we
created
for
ourselves
in
ingress,
and
we
just
had
no
way
out.
So
we
just
had
to
say
the
string
that
exists.
There
is
implementation
specific,
because
we
can't
really
speak
to
it
in
any
detail
and
there
had
to
be
a
it
had
to
be
a
default
value
that
the
these
kinds
of
fields
like
match
ended
up
taking
because
we
had
to
convert
from
something.
E
That
said
nothing
to
something
that
said
something
kind
of
yes,
you're
right
and
that
if
we
can't
stick
with
this
prefix
exact
regex,
I'm
fairly
certain,
we
can
also
just
find
examples
of
where
specific
implementations
want
to
support
even
more
clever
matches.
E
Like
which
one,
oh,
that
we
can
refer,
that
was
a
discussion
we
can
refer
to
that
conversation.
Yeah.
D
That
that's
documented
well,
I
think
I
hope
okay,
cool
yeah,
I
hadn't
I
hadn't
checked,
but
I
think
yeah.
Removing
implementation
specific
at
this
point
is
fine
and
then,
if
we
want
to
add
in
extra
things
later,
that's
additive,
not
not
subtractive,
so
there's
no
problem.
I
think
it's
better
to
remove
the
implementation
specific
now
and
say
there
are
three
material
messages
and
only
three
match
methods.
If
you
want
to
add
more,
that's
fine
come
and
talk
to
us.
A
Okay,
you
bet
that
definitely
is
simpler,
and
I
agree
with
with
bowie's
point
here
like
that
that
implementation
specific
is
an
unfortunate
holdover
from
ingress
where
we
were,
you
know
stuck
trying
to
provide
some
kind
of
backwards.
Compatibility
and
implementation
specific
was
basically
just
backwards
compatible
to
whatever
it
was
before.
A
This
is
probably
not
a
good
thing
to
carry
on
to
gateway
api,
so
I
I'm
happy
to
remove
it.
I
I
am
a
little
bit
sad
to
remove
it
without
a
replacement,
because
I
do
think
there
probably
are
some
extension
extension
mechanisms
lurking
here
and
if,
in
the
same
release,
we've
removed
implementation,
specific
matching
and
extension
ref,
we've
really
limited
how
you
can
extend
matching
for
a
route
or
anything
like
that.
So
I'm
I'm
a
bit
hesitant
on
that,
but
I
am.
D
Conversation
yeah
that
that's
what
I
was
going
to
say
like
I.
I
think
I
feel
like
the
best
thing
to
do.
Is
you
hey?
Do
we
really
need
do
we
really
need
this
extra
sensibility?
The
way
to
do
it
is
take
it
out
and
then
wait
and
see
if
anyone
asks
and
if
anyone
asks
then
we
put
it
back
in
but
like
then
then
we're
we're
starting
out
from
a
simple
place
and
then
not
need
to
make
breaking
changes,
because
we
tried
to
anticipate
stuff
that
we
that
we
didn't
anticipate
like
we
can
add.
C
C
E
That
is
an
available
type
that
that
feels
like
a
good
experience
with.
C
It
but
that's
kind
of
what
you
want
for
this
case
because,
like
if
you
you
want
to
be
able
to
have
enough,
feel
you
don't
know
what
fields
you
need,
because
you
don't
know
what
the
match
type
is,
and
you
don't
really
want
to
have
a
separate
cid,
because
then
you're
you're,
making
it
a
lot
harder
for
for
users.
D
It's
it's
like
it's
kind
of
acceptable
to
some
extent,
but
it
does
reinvent
the
annotations
problem
and
then
impact
the
portability
again.
The
reason
to
make
all
of
this
stuff
declared
as
fields
rather
than
having
as
json
bobs
or
mastering
string
or
something
like
that,
is
that
then,
there's
no
way
in
which
an
implementation
can
differ,
but,
like
this
stuff,
can
differ
between
implementations.
E
Issue
that
if
we
do
went
that
way,
we
would
need
to
solve
is
to
just
make
sure
that
you
are
able
to
find
your
own
ones,
that
the
reason
why
qualified
name
is
good
in
some
ways
is
because
it
comes
with
the
name
of
the
implementation
kind
of
stuck
as
the
key
like.
If
it's
just
arbitrary
json,
we
probably
have
to
put
something
around
it
as
well.
A
I
think
yeah
so
so
we're
over
time,
but
I
think
I
think
it's
worth
discussing
more.
I
think
the
thing
that
we
know
it
seems
like
we
have
pretty
clear
consensus
that
implementation
specific
as
it
exists
right
now
does
not
make
sense,
and
also
that
not
necessarily
now
but
potentially
at
a
later
point,
we're
open
to
replacing
that
with
some
other
implementation,
specific
extension
mechanism,
as
we
get
use
cases
for
it,
but
that's
that's
the
general
consensus
I'm
getting
right
now.
How
does
that
add
up
with
what
others
are
hearing.
A
A
Okay,
cool
yeah:
let's,
let's
work
with
that.
If
anyone
wants
to
volunteer
just
to
assign
themselves
to
this
issue,
otherwise
we
can
you
know
otherwise
I
can
take
it
on
a
bit
later,
but
happy
if
someone
else
wants
to
just
this
doesn't
need
a
gap
right.
A
D
A
Okay,
I'll
take
it
cool
awesome
thanks
all
right!
Well,
that's
all
we
have
for
today
thanks
everyone
for
the
great
discussion
and
we'll
talk
to
you
next
week.