►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20220509
Description
SIG Network Gateway API Bi-Weekly Meeting for 20220509
A
All
right
it
is
may
9
and
we've
got
fairly
light
agenda
today.
This
is
the
gateway
api
meeting.
We've
got
an
open
agenda,
as
always,
I
saw
a
question
or
two
in
slack
that
could
probably
make
it
onto
this
agenda.
So
if
anyone
from
slack
is
wanting
to
raise
questions
or
comments,
please
just
add
add
those
items
to
the
agenda
here
and
we
can
make
sure
we
discuss
them.
A
As
always,
this
is
very
informal,
please
feel
free
to
ask
questions
there.
There
is
no
limit
to
who
can
talk
here.
We
appreciate
any
and
all
feedback
ideas
whatever.
If
something
doesn't
make
sense,
please
ask
with
that
yeah,
let's
get
started
first
off.
I
am
suggesting
that
we
should
cancel
the
next
two
meetings
for
kubecon.
I'm
going
to
be,
I
think
several
of
us
are
going
to
be
in
valencia
in
a
week
all
things
going
well,
at
least
so.
A
With
that
in
mind,
I
am
thinking
that,
at
least
for
me
I
will
be
jet-lagged
coming
back
from
kubecon
the
next
time.
I
don't
know
what
my
what
I'll
be
doing,
but
it
may
be
safe.
It's
just
to
cancel
both.
I
know
for
sure
that
I'd
love
to
meet
people
in
person
that
are
going
to
be
at
kubecon,
but
since
so
many
of
us
or
enough
of
us
will
be
there.
I
don't
know
that
there
would
be
enough
people
here
to
have
a
meeting.
A
Is
anyone
interested
in
meeting
either
of
those
next
sessions?
I'm
happy
to
let
someone
else
lead
a
meeting.
A
All
right
cool-
and
I
should
a
broader
note-
I
I
often
along
with
nick
will,
will
lead
these
meetings
and
discussions
and
whatever,
but
I
am
not
tied
to
that.
If
we're
we're
always
open
to
other
people
leading
these
meetings,
there's
not
much
to
it.
So
if
you're
interested
in
getting
involved
and
helping
out
that
way,
yeah
just
just
ping,
one
of
us
offline
and
well
we'll
get
you
set
up.
B
A
Cool
with
that
said,
let's
get
into
a
few
things
that
came
up
related
to
conformance
recently.
I
think
one
of
the
bigger
discussion
points
came
out
of
a
slack
conversation
last
week.
I
translated
that
into
a
pr.
I.
There
were
a
couple
points
in
our
api
where
we
had
recommended
returning
503
status
codes
and
no
parts
in
our
api
were
where
we
recommended
returning
404s.
A
What
made
this
confusing
is
we
had
conformance
tests
that
required
returning
404s.
I
had
an
assumption
that
oh
yeah
well,
of
course
it
makes
sense
to
return
a
404
here,
but
we
didn't
have
that
in
our
spec,
so
this
is
trying
to
force
that
issue
and
make
sure
that
our
spec
matches
our
conformance
tests.
Vice
versa,
there's
been
some
conversation
on
this
pr.
A
I
I
went
into
the
rfc
itself
to
try
and
like
yeah.
I
think
really
we're
trying
to
decide.
Does
a
503
make
sense
here.
Does
a
404
make
sense
what
what
really
makes
sense?
I
think
there's
really
two
key
things.
Scenarios
we're
discussing
here.
One
is
if
a
route
doesn't
attach
if
a
route
can't
attach
to
a
gateway.
A
Do
we
do
anything
for
that?
Do
we
change
the
status
code?
That's
returned.
Do
we
have
some
kind
of
indication
that
hey
something
was
trying
to
serve
here?
It
just
didn't
work
or
do
we
just
ignore
it
and
say
well,
it
didn't
attach
and
I'm
not
doing
anything
special
and
then.
The
second
thing
is,
if
you
reference
a
back
end,
ref
reference
a
back
end
that
either
doesn't
exist
or
you
don't
have
access
to
again.
A
Is
that
just
something
like
we
ignore
and
say:
hey
we
couldn't
find
anything
or
is
that
something
we
surface
as
a
50x
error
code
of
some
kind?
My
proposal,
as
you
can
see
from
this
pr,
is
that
we
we
use
a
404,
not
just
a
generic.
I
don't
know
about
that.
C
It
there
was
a
third
case
right,
which
is,
if
you
make
a
request
and
there's
no
applicable
rule.
C
A
The
base
case
yeah
good
point
that
that's
a
very
good
point,
so
I've
been
assuming
that
that
very
base
case
of,
if
you
don't
find
a
matching
route
rule
that
should
be
a
404.
A
That's
my
base
assumption
around
all
of
this
and
then,
if
you
take
that
to
the
next
step
of
if
a
route
failed
to
attach,
I
think
that
should
be
treated
the
same
way
as
just
not
finding
a
matching
route
rule
and
then,
similarly,
if
a
back
end,
ref
can't
be
found,
I
think
that
should
be
treated
the
same
way
too,
but
that's
each
one
is
a
little
bit
more
of
a
step
to
take.
I
think
so
open
to
a
discussion
on
that.
B
Yeah,
so
I
think
I
wanted
to
put
I
put
that
comment
in
there,
because
that's
what
I
remembered
us
talking
about
earlier
that
you
it
allows
like
end
users
like
web
clients,
people
who
control
the
actual
client
thing
to
be
able
to
tell
that
that
everything
you
know
what's
happening
and
whether
or
not
that
their
config
is
like
present
or
something
like
that,
but
it's
just
not
working,
but
the
the
more
I
think
about
it.
The
more.
I
think
the
rob
is
right
right.
B
You
don't
want
people
to
be
able
to
enumerate
like
what
possible
config
is
there
by
you
know
finding
where
the
503s
are
and
the
application
developer
should
be
reading
like
yo,
hey,
I
got
you.
This
path
was
working
and
now
is
not,
and
going
back
to
the
the
go
api
resources
to
find
out
what
the
status
is.
That's
kind
of
the
flow
that
we
want
people
to
have
is
hey.
I'm
expecting
this
to
be
surfed
by
my
gateway
api,
and
it's
not
what's
going
on
here.
B
I
better
go
and
look
at
my
google
api
resources
yeah
and
then
that
that
should
be
the
flow
that
we
want,
that
we
want
the
application
developer.
Who
owns
those
resources
to
have?
I
think
it's
helpful
to
come
back
to
the
personas.
B
There
there's
probably
an
implied
persona,
I
think
of
you,
the
end
user,
the
the
person
who's
actually
using
the
application
that
we
don't
specify
because
they
don't,
we
don't
have
any
way
to
interact
with
them,
but
you
know
I
was
kind
of
thinking
originally
that
the
503
was
useful,
because
those
people
could
then
complain
to
the
application
developer.
Why
they're
503s?
B
But
I
think
that
you
know
that's
probably
reading
too
much
into
it
now,
the
more
I
think
about
it,
so
yeah.
I
would
draw
my
objections.
I
think
I'm
fine
with
this
404s
so
but
yeah.
I
think
it
was
probably
good
to
have
discussed
this
too.
So
we
could
draw
out
this
and
have
a
record
of
why
we're
doing
404s
and
not
503s
yeah,
but
over
to
anyone
else
who
wants
to
talk
about
this.
D
I
think
the
one
place
that
503s
might
make
sense
is,
if
there's
no,
it
is
if
the
routes
attach
successfully
they're
bound
they're
accepted
as
valid,
but
there's
not
a
healthy
back
end
to
route
to
potentially
it's.
B
B
D
Yeah,
where
it's
actually
is
like
a
there's,
no
healthy
server
for
for
the
first
two
cases
yeah,
I
think
it's
like
the
default
case
of
having
404.
If
no
matches
down
seems
fine
in
the
case
of
if
a
route
is
not
able
to
bind
to
the
gateway,
if
it's
rejected.
For
some
reason,
no
configuration
should
happen
like
it
should
not
be
able
to
like
affect
or
configure
anything
specifically
different
default
case.
That
makes
a
lot
of
sense
to
me,
too.
B
Yeah,
I
think
the
the
it
can
be
difficult,
because
the
way
that
this
interacts
with
inclusion
and
delegation
can
be
tricky
as
well,
because
the
it
kind
of
my
experience
with
contra
has
been
that
it
can
be
difficult
to
tell
between
you
don't
get
any
config,
because
there's
no
yeah,
like
I
see
what
you're
saying
I
kind
of
tend
to
agree
a
little
bit,
but
it
can
be
in
practice.
B
It
can
be
difficult
to
tell
to
tell
if
it's,
because
there's
no
endpoints
or
because
the
you
know
the
service,
like
other
stuff,
has
happened.
I
think
that
that's
probably
a
good
case
to
call
out,
though,
rob.
A
A
Is
that,
and
so,
if
that's
the
case,
that
does
seem
different
than
a
404
to
me
that
that
does
seem
like
it's
503,
and
that
seems
like
something
we
should
clearly
document,
and
I
have
not
documented
it
here.
B
D
E
E
If
we
haven't
created
something
from
a
route,
we
will
just
serve
a
404
by
default
to
any
request
and
like
503s,
is
kind
of
our
default
right
now,
if
we
have
like
a
are
looking
for
endpoints
but
could
not
find
any,
which
I
think
makes
sense
because,
like
you
know,
if
you
have
a
503
like
because
of
a
misconfiguration
like
you
specified
a
back-end
ref
that
doesn't
exist
like
it's,
not
temporarily
unavailable
it's
unavailable
until
that
back
end,
ref
is
actually
created,
whereas
with
the
endpoint
case,
you
can
like
kind
of
reasonably
assume
that,
like
probably
a
deployment
is
like
coming
up
to
status
or
write
in
points
to
satisfy
that
service.
B
Yeah,
that's
a
good
point
about
the
transient
nature
of
the
era
versus
the
404.
That
might
that's
a
good
guideline.
I
think,
to
to
use
here
that
transient
errors
should
probably
be
a
server
error,
rather
that,
whereas
persisting
errors
that
require
human
intervention,
to
fix,
make
more
sense
to
be
a
400
series
or
404.
A
This
has
been
a
very
helpful
discussion.
Thank
you.
I
I
just
I
before
we
move
on
from
this
topic.
I
want
to
make
sure
I
understand
that
the
consensus
here
it
seems
like
we're
fine
with
the
404
for
the
use
cases
I
initially
introduced,
which
are
route
can't
be
attached
or
a
back
end.
Ref
refers
to
a
non-existent
or
invalid
service
or
some
other
thing
that
it
can't
be
resolved,
but
we
also
need
to
differentiate
from
that.
A
B
B
So
that
maybe
could
maybe
that's
another
thing
to
keep
in
mind
there
too.
B
Cool
yeah.
I
think
that
yeah
as
mike
says,
that's
a
general.
That's
a
general
guideline.
If
something
is
not
supported,
it's
basically
the
same
as
if
it's
never
it's
not
attached,
it
may
be
present,
but
you
know
it
should
not.
It
should
never
attach,
and
so
that
I
actually
talked
in
one
of
the
status
things
about
adding
a
general
condition
that
says
something
on
in
your
config
is
not
supported
so
that
you
can
look
for
that.
One.
A
Great
okay,
let
me
move
on
to
the
next
one
on
the
list,
which
is
a
conformance
test
added
by
karagina,
and
she
it
the
test,
matches
the
spec
perfectly
and
I
think
it's
valid
whatever.
I
just
wanted
to
raise
this
by,
because
when
I
looked
at
the
test,
it
threw
me
off
for
a
second,
and
that
is
that
the
test
specifies
and
requires
that
slash
two
should
pat
should
match,
but
the
trailing
slash
modifies
that
behavior.
A
That
is
something
we've
explicitly
for
prefix
match.
We've
explicitly
said
that
trailing
slash
makes
no
difference
in
terms
of
behavior
an
exact
match,
we're
saying.
Actually
it
does
make
a
difference.
The
trailing
slash
is
meaningful.
I
I
think
that
makes
sense.
I've
looked
through
a
variety
of
implementations.
This
seems
to
be
implementable,
at
least,
but
not
always
default
behavior.
So
I
call
it
out
with
nginx,
for
example.
This
is
something
that
does
not
happen
by
default,
so
you
have
to
do
some
extra
work
to
make
this
happen.
A
I
think
this
makes
sense.
I
just
want
to
make
sure
that
someone
else
you
know
that
we
all
see
this,
and
we
all
agree
that
this.
A
This
logic
of
the
trailing
slash
being
a
meaningful
part
of
an
exact
match
is
what
we
want
any
thoughts
on
this
one.
E
I
believe
this
was
also
the
case
for
ingress
v1
as
well,
so,
like
I
remember,
nginx
and
us
kong,
basically
having
the
same
sort
of
thing
where,
like
that
is
not
our
default
behavior
and
in
our
case
we
have
to
change
it
to
a
regex
that
explosively
terminates
after.
So
it's
in
that
respect,
probably
something
that
people
implementing
this
have
maybe
come
across
before,
if
they're
already
familiar
with
ingress
so
and
also,
if
that's
from
a
user
perspective,
changing
that
from
the
way
the
ingress-handed
exact
path
would
be
a
bit
odd.
A
C
A
Yeah
yeah,
the
next
one.
This
is
a.
I
don't
think
this
is
controversial.
I
I
was
trying
to
think
through
any
unintended
consequences.
This
change
could
have.
I
forget
who
made
this
initial
change,
but
we
added
some
tests
that
basically
ensured
that
for
conformance
tests
to
pass,
you
need
three
consecutive
successful
requests
to
a
given
endpoint
and
it
also
added
some
level
of
you
know
it
can
fail
this
many
times,
but
we
need
three
successful
requests
in
this
time
period
that
are
concurring
john's
solution.
A
Suggestion
here
is
to
take
that
one
step
further
and
say
if
your
previous
request
was
successful,
don't
wait
one
second
to
send
another
request.
Just
to
speed
up
conformance
test
runs
if
everything's
passing
this
makes
sense
to
me.
It
had
me
thinking.
Okay,
maybe
this
is
going
to
miss
some
edge
case
somewhere.
A
Use
case
there,
and
I
think,
if
it
misses
an
edge
case,
that
that's
a
failure
in
our
test,
not
a
failure
in
this
system,
but
just
just
because
it
is
a
significant
behavioral
change.
I
wanted
to
again
get
a
few
more
eyes
on
this
and
see
if
anyone
was
hesitant
about
getting
this
one
in.
C
I
added
the
eventual
consistency
stuff,
and
this
makes
sense
to
me
I'll,
go.
Take
a
look
at
the
pr.
B
B
I
see
that
there
was
a
question
from
you
mike
about
the
end
user
expectations.
Was
that
a
question
about
the
path
matching
yeah?
That.
D
Match
thing
so
like
not
the
difficulty
of
implementing
it
in
the
proxy
but
users
of
each
of
our
implementations,
what
they
might
expect,
and
that
was
kind
of
already
dressed
by
people,
probably
file
issues
about
it.
B
A
All
right,
I
wanted
to
spend
some
time
going
through
the
0.50
milestone.
This
is
something
that
was
previously
called
the
v1
beta
1
milestone,
which
this
release
will
still
include
beta
resources,
but
I
thought
it
was
clear
to
just
label
it
the
december
release
version,
so
I
renamed
this
milestone.
I
think
what
we
really
need
here
is
some
cleanup
of
the
things
that
are
still
in
here.
A
I
think
it
may
be
safer
now
to
move
individual
images.
Sorry,
individual
issues
into
the
milestone
and
move
this
parent
issue
out
great
okay.
Nick.
Can
you
follow
up
on
this?
One
awesome
cool.
I
think
this
is
the
same.
This
is
a
like
kind
of
a
umbrella
issue
and
I'm
not
sure
everything
in
we.
A
You
know
we've
accomplished
half
of
the
things
in
here
or
two-thirds
of
the
things
in
here
and
we
are
missing
one
of
the
things
I
think
what's
best,
I
think
that
the
thing
that's
remaining
is
this:
one
right
here
moves
significant
content,
generic
to
a
resource
into
the
resource
description
field.
Mike,
are
you
on
this
call.
A
Yeah,
I
I
think
this
that
specific
thing
is
not
critical
to
me
for
v1
alpha
for
v050
and
since
the
rest
of
the
things
have
been
accomplished
here,
I
think
I'm
good
to
pull
this
out
of
the
milestone.
B
A
All
right
and
let's
see,
moving
down
the
list.
I
need
to
document
this,
but
this
is
blocked
on
this.
I
really
wish
we
had.
Maybe
there
is
a
way
I'm
just
not
good
at
github,
but
maybe
there's
a
way
to
say
this
issue
blocks
this
issue,
but
whatever
this
is
all
blocked
by
this
refactor,
I
would
love
to
get
this
refactor
in
sooner
than
later.
I
realized
I
am.
A
I
need
to
respond
to
this
comment,
but
if,
if
anyone
else
has
time
to
take
a
look
at
this,
this
is
a
relatively
large
change.
That
kind
of
came
out
of
the
sig
network,
api
review
and
some
comments.
There,
we've
already
covered
that
in
I
think,
a
previous
meeting,
but
just
it.
This
is,
I
think,
probably
the
most
significant
change
that
is
currently
blocking
release,
and
I
would
just
I
would
love
to
get
this
one
in
this
week,
if
at
all
possible.
A
So
this
may
just
be
a
lazy
consensus.
One
of
we
we
do
have
one
lgtm
on
there.
So
I
will
try
to
make
the
the
one
change
here,
but
otherwise,
if
there's
no
comments
or
anything
I'll,
just
get
one
more
lgtm
and
call
it
good.
B
Okay,
yeah,
so
with
that
one
I
just
wanted
to
call
out
to
everyone
here
that
it
is
important.
I
think,
for
us
to
remember
that
qbuilder,
api,
server,
validation,
types,
the
upstream
conventions,
say
hey
changing.
That
validation
is
a
breaking
change,
because
an
enum
implies
that
it's
the
clut
it's
a
closed
set
and
they
sort
of
say
hey.
B
We
recommend,
if
you're
going
to
have
this
thing,
be
an
open
set
and
make
sure
you
call
it
out
where
you
have
the
income
validation
so
that
you're
in
the
documentation
for
that,
so
that
people
so
implementers
know
that
this
is
an
open
set
and
could
be
added
to
at
some
point
in
the
future.
So
you
need
to
make
sure
there's
a
default
case
right
like
even
if
that
full
case
is
hey
chief.
I
don't
know
what
to
do.
B
You
need
to
make
sure
that
you
don't
just
crash
or
something
okay,
so
I
think
that's
I'm
trying
to
be
I'm
trying
to
be
the
stickler
for
that
sort
of
stuff,
because
I
feel
like
there's
so
much
so
much
pain
written
into
that
api
conventions
document
that
we
really
just
want
to
try
and
avoid
as
much
as
possible.
A
Yeah
good
catch,
and
I
I
think
we
have
that
throughout
the
api
in
different
places,
but
we
need
to
we.
We
have
like
this
high
level
guidance
in
version
guideline
got
in
our
versioning
guidelines
that
say
hey.
We
can
change
this,
but
it
would
be
much
better
to
have
it
beside
every
field
where
it
can
change
just
so.
It's
crystal
clear
that
the
thing
you're
looking
at
can
change
in
the
future.
B
Yeah,
I
think
that
is
also
a
great
you
know.
First
time
you
want
to
interact
with
the
spec
kind
of
thing
is:
go
through
the
spec
look
for
all
instances
where
we
use
the
enum
and
directive
and
just
check
to
see
that
we
have
some
call
out
there
to
say
this
is
not
closed.
We
can
add
to
it
later
because
I
think
pretty
much
everywhere
we
have
used
it.
We
want
to
be
able
to
do
that.
B
A
Our
slides
right
now
are
very
guarded
of
we're
talking
about
we're,
releasing
the
beta
you
know
unclear
of
if
it
has
happened
quite
yet
or
if
it's,
but
I
I
expect
it
to
happen
this
month
and
sooner
the
better,
and
these
are
really,
I
think,
just
the
last
little
nitpicks
that
we're
working
through
right
now
so
yeah.
B
A
Yeah,
so
there's
there's
one
other
big
one
around
status,
and
I
this
has
gone
through
a
few
different
people
that
have
been
interested,
but
it's
it's
such
a
big
one
and
I'm
realizing
after
the
fact
like
shane
was
interested
in
a
portion
of
it,
but
I
think
that
the
full
scale
of
this
pr
this
issue
was
a
bit
more
than
you
had
time
for
so
maybe
what
we
need
on
this
one
too,
is
to
split
this
up
into
some
smaller
individual
issues
that
different
people
can
take
on.
A
I
I'm
not
sure
the
best
way
to
split
this
one
up
but
shane
remind
me
genuinely
yeah,
which
specific
part
were
you.
You
were
talking
about
an
accepted
condition.
E
Maybe
not
quite,
there
was
like
an
extra
thing
that
I
had
originally
tried
to
shove
into
one
one,
one
four
that
didn't
actually
go
there
and
I
wasn't
sure,
if,
like
the
change
proposed
here,
would
make
it
so
that
it
was
like
difficult
to
shove.
My
thing
in
there
was
like
a
accepted
false
reason
that
we
needed
it's
still
not
there,
but
like
accept
it
itself.
Is
there.
D
D
Was
just
kind
of
like
introducing
the
first
few
because
we
didn't
have
any
route
reasons
yet
so
what
was
the
specific
accepted?
False
reason?
We're
looking
for.
H
Related
to
like
namespace
namespace
and
port
restrictions
so
like
on
a
gateway
you
can
say,
I
only
allow
routes
to
connect
if
they're
from
this
namespace
or
these
ports
or
whatever
and
write
our
implementation
currently
like
we'll
block
that,
but
just
log
inside
of
the
controller,
and
we
were
looking
for
basically
better
ways
to
tell
the
the
end
user
nope
that
route
didn't
work,
but
here's
the
reason.
E
I
was
just
fetching
a
link,
so
that
was
the
thing
that
I
wanted
to
add
for
like
when
it
doesn't
match
like
the
allowed
routes
criteria
so
like
that
particular
doesn't
change.
I've
basically
been
held
up
on
like
trying
to
write
the
conformance
test
or
finding
time
to
do
that.
D
B
So
yeah,
I
would
recommend,
make
a
pr
for
that,
one
that
will
close
out
that
specific
action
item.
I
think,
with
these
reasons
and
types
and
stuff,
I
think
it's
more
important
that
we
get
the
reasons
and
types
into
the
spec.
Now
then
like
we
can,
we
can
do
follow-up
prs
for
the
performance
testing
for
it
yeah
yeah
good
point
yeah,
like
I
think
that
the
conformance
tests,
although
like
we
got
to
have
them
for
ga,
like
we
don't
need,
we
don't
need
any
more
conformance
coverage
than
we
have
already.
D
I
think
from
what
I
recall
some
conversations
with
heather,
nick
and
rob,
but
we
also
talked
about
this
is
potentially
like
easily
extensible
part
of
the
spec,
where,
like
it
still
doesn't
get
in
for
beta
that
we
can
always
add
more
reasons
later.
B
Yeah
it
doesn't,
this
is
not
a.
This
is,
does
not
require
adding
reasons
and
condition.
Types
does
not
require
api.
Ref
it'll
require
bundle,
rev
and
stuff
like
that,
but
not
an
api
ref
and
a
tour
through
the
experimental
channel,
but
not
non-aprf
yep.
A
Yep,
okay,
that
yeah!
Thank
you
for
going
through
that
this
so
travis,
are
you
going
to
create
a
pr
to
the
main
repo
with
this
yeah.
A
Would
be
awesome
and
then
I
can.
I
can
work
with
mike
to
try
and
understand
which
of
these
things
have
already
been
done,
which
of
them
have
not
been
done
yet,
and
maybe
we
can
split
this
out
into
you
know
a
few
smaller
issues
for
the
things
that
we
still
want
to
get
in,
and
some
of
these
I
think,
since
this
this
does.
I
think
we
do
have
consensus
on
this.
A
I
think
this
each
individual
thing
can
be
specced
out
clearly
enough
that
this
can
be
kind
of
a
good
first
issue
kind
of
thing
where
new
contributors
can
jump
in
if
you're
interested
so
again
keep
keep
an
eye
on
this.
I
added,
I
think
we
have
a
few
issues,
currently
tagged
good
first
issue,
so
if
you
have
time
and
you're
wanting
to
contribute
to
this
api,
we
do
have
some
issues
that
are
good
starting
points
now,
and
this
could
have
had
a
few
more.
D
Yeah
that
sounds
good
I'll
work
with
you
to
break
this
up
and
there's
at
least
probably
four
separate
individual
issues
that
can
come
out
of
here.
I
think
the
more
important
ones
are
the
ones
that
are
removing
or
changing
existing
reasons
before
we
go
to
beta
or
something
like
that,
the
ones
that
are
adding
more
verbose
or
informative
reasons.
I
think
those
can
easily
be
different
to
whatever
yeah.
A
And
I
think
I
think
that's
perfect
right
it'll
help
us
differentiate,
which
ones
belong
in
the
milestone
and
which
ones
are
nice
to
have,
but
not
required.
Yep
agreed
cool
sounds
good,
all
right
I'll,
follow
up
after
thanks
thanks
again
for
adding
that
issue
this
one
we
already
covered
the
refactor
domain,
prefix
strings
for
named
after
nick.
I
remember
you
added
this
to
the
milestone.
A
B
Did
yeah,
so
I
added
it
to
the
milestone,
because
this
is
there's
a
bit
of
a
change
of
type
for
the
strings
for
the
name
named
address
so
yeah
I
put
some.
I
put
some
deliberates
down
the
bottom,
because
mayhah
asked
if
she
could
take
this
one
it
I'm
not.
I
wanted
to
talk
about
whether
we
think
this
is
a
breaking
change.
So
right
now,
there's
a
named
address
type
that
in
like
when
we're
talking
about
addresses
that
covers.
B
Like
you,
what
similar
thing
to
what
the
load,
balancer
status
thing
in
ingress
and
service
does
for
named
address,
so
it
covers
like
something
that
is
not
specifically
an
ip
address
could
be
a
notepaddress,
but
could
be
a
hostname
or
some
other
thing.
I
wanted
to
make
sure
that
we
add
the
capability
in
here
to
have
a
domain
prefix
string,
so
we
could
have
like
project
contour.io
special
named
address
or
something
like
that
right,
like
some
other
condition,
type
that
has
a
domain
prefix
that
is
allowed
through
the
validation
hole.
B
That
means
that
then,
because
the
named
named
address
behavior
is
very
unclear
and
very
implementation.
Specific.
This
way
we
have
a
way
for
implementations
to
actually
say
you
I
want
this
is
an
address.
Then
you
know
this
is
my
address
and
you,
and
that
way
we
can
take.
B
We
can
do
the
normal
thing
that
we
want
to
be
able
to
do,
which
is
to
take
what
individual
implementations
do
get
some
consensus
around.
What
the
right
way
to
handle.
That
thing
is
and
then
make
that
into
a
a
an
official
sort
of
type
or
something
like
that,
and
so
that's
that's
the
yeah
so
where
the
this
is
a
currently,
this
value
is
a
string
and
it
has
a
validation
that
is
like
camel
case
only,
and
so
I
think
or
domain
name
only
or
something
like
that.
B
A
A
A
domain
domain
prefix
path
is
something
that
is
consistent
with
what
we've
done
elsewhere
in
the
api.
This
this
feels
like
something
that
is
nice
to
have
in
in
update
like
in
this
release.
I
don't
know
it
feels
like
something
that
we
could
cut
if
we
had
to.
B
So
the
only
the
only
reason
I
would
put
it
in
here
is
that
currently,
the
the
address
type
type
actually
has
an
enum
validation,
and
so,
if
we're
changing
the
enum
validation
to
to
non-enum
validation,
it's
kind
of
is
it
technically
is
a
valid,
is
a
validation,
change
or
tariff,
and
it
should
be
an
api,
an
api
bump.
I
think
in
this
case
it's
probably
okay,
because
we're
not
changing
the
underlying
type
and
the
previous
values
will
be
allowed
so
like
the
enum
values
will
be
allowed
constants.
B
Once
we
change
this,
you
know
and
then
we'll
supply
constants
to
actually
do
that.
So
I
think
yeah.
It
probably
is
okay
to
push
it
out
to
later
in
this
specific
case,
but
we
just
need
to
be
really
careful
about
things
where
we're
removing
an
enum
and
changing
it
to
a
pattern
or
something
like
that
in
the
future
and
think
about
it
very
carefully
before
we
count
it
as
not
not
a
breaking
change.
A
A
So
I
I
view,
even
though
the
implementation
details
it
here
are
going
to
be,
this
moves
from
enum
validation
to
regex
validation
or
something
like
that.
The
the
ux
for
the
user
is
the
same
thing
of
I
had
two
possible
values,
and
now
I
have
n
you
know
two
plus
and
possible
values.
A
B
Yeah,
so
I
think
if
someone
can
do
that
enum
change,
then
then
I'm
fine
we're
taking
this
out,
because
that
will
cover
the
fact
that
we
might
change
this
later.
The
yeah
I
do
since
most
of
the
implementers
are
on
this
call
yeah.
I
do
think
please
just
keep
that
in
mind
that
you
know
that
the
enums
are
not
exhaustive.
A
All
right,
I
think
that
exhausts
everything
that
we
have
left
in
the
0.50
milestone
good
to
see
our
percentage
going
up
here,
and
hopefully
we
can
get
the
last
few
of
these
knocked
out
pretty
quickly
again,
I
I
am
still
hoping
for
a
kubecon
release
for
o50,
but
even
if
we
don't
get
that
specific
date,
I
think
it's
going
to
be
awfully
soon.
E
Yeah
so
convenient
timing.
I
found
this
right
before
this
meeting
started,
so
looking
for,
like
our
implementation,
tls
route,
how
we
assign
certificates
and
like
the
tls
mode
certificates,
definitely
have
like
the
gap
that
says
like
no.
These
aren't
on
you
know
the
tls
route
itself,
like
they
were
in
ingress
they're
in
the
gateway.
E
Do
you
have
to
write
a
listener
separately
for
each
of
those
it
didn't
seem
like
this
would
come
up
before
in
chat.
So
I
just
kind
of
wanted
to
ask
about
it,
for
you
know
other
mentors,
or
if
people
had
thoughts
about
it
or
encountered
the
same
thing.
B
Yeah,
I
think
my
expectation
was
definitely
that
the,
because
the
reason
we
didn't
want
to
do
this
was
that
if
you
have
multiple
host
names
on
the
listener-
and
you
have
multiple
like
the
multiple
host
names
on
the
tls
route
and
you
have
multiple
certificates,
it's
very
difficult.
It
becomes
very
difficult
to
like
make
sure
that
everything
lines
up.
B
You
know
like
to
make
sure
that
they
all
match
for
the
only
some
of
the
match
or
something
like
that
like
and
so
having
a
place
where
there's
only
one
of
them
makes
that
easier.
I
do
acknowledge
that
it
means
that
you
have
to
create
separate
listeners
for
or
let's
say
for
listener,
stanzas
for
each
host
name.
B
I
think
at
the
end
of
the
day,
that's
actually
desirable,
because
then
you
can,
then
it
makes
it
much
easier
to
attach
the
tls
route
to
only
the
listener,
because
you
because
they
have
to
be
named-
and
you
can
attach
things
to
only
a
single
hostname.
B
B
Yeah,
so
the
the
way
that
the
host
name
matching
works
is
as
long
as
there's
a
match
between
a
hostname
on
the
gateway
and
a
hostname
on
the
route.
Then
then
you're
good,
that's
why
we
actually
talked
about
adding
the
host
names
that
are
actually
matched
into
the
status
of
the
route,
so
that
you
can
tell
which,
like
when
you
attach
to
a
listener
which
route
you
get
like,
which
host
name
you
match
to.
I
don't
know
if
that
actually
happened
yet,
but
we
did
definitely
talked
about
it.
E
Yeah,
like
I
also
I
also
considered
like
you,
know,
the
the
cheating
method
where
you
you
know,
you
just
want
to
aggregate
all
of
your
pass
through
routes
together
and
you
just
create
a
focus
name
that
won't
actually
be
used
and
just
put
it
on
all
of
them.
I
don't
know
if
that's
an
intended
effect
here,
but
it
seems
like
it
would
work.
Yeah.
B
Yeah
I
mean
as
long
as
you
pass
the
hostname
validation,
then
I'm
sure,
like
you,
I
think
the
we're
trying
we
have
to
walk
such
a
fine
line
here
to
to
hit
the
use
case
of
the
sort
of
cluster
admin
really
wants
to
keep
tight
control
of
the
of
what
hostnames
go
where
and
the
in
the
magic
use
case
of
you
know
hey.
B
I
can
just
do
everything
I
need
to
easy
quickly
and
easily
so
the
yeah,
so
this
was
the
best
that
I
could
come
up
with
that
also
dodged
the
bullet
that
we
had
to
contour
about
the
we
found
writing
the
tests
for
you,
what
happens
if
only
some
like
in
ingress,
the
behavior
is
not
specified
if
you
have
like
a
host
name
and
a
a
certificate,
they're
both
lists,
and
if
you
don't,
and
how
do
you
check
that
they
they
or
do
they
only
dimension?
Some
like
none
of
that
behavior
was
specified.
B
I
think
we
could
do
it
better
here,
because
we've
specified
what
the
behavior
should
be
for
the
hostname
matching,
but
I
think
that
having
multiple
host
names
in
a
single
listener,
although
it
will
be
convenient,
will
also
make
it
much
harder
to
test
some
of
these
things,
because
because
then
you've
got
a
three-dimensional
intersection.
You
know,
like
you've,
got
hostname
listener
route
listener,
plus
a
smiley
listener.
F
B
So,
and
I
think
that's
the
that
in
my
mind,
that's
the
main
reason
just
to
leave
it
at
a
single
one.
I
should
I
should
say
as
well
it
also.
B
I
think
we
still
don't
document
this
very
well,
but
it
also
is
intended
that
you,
if
you,
if
you,
allow
your
implementation
to
support
merging
gateways,
you
know
that
having
separate
listeners
in
separate
gateways
should
be
equivalent
to
having
those
same
listeners
in
a
single
gateway
object.
But
that's
what
gateway
merging
is
intended
to
be.
You
should
be
able
to
break
those
up
into
separate
gateways.
If
that's
what,
if
that's,
what
you
wanted
things
or
have
like
you
know,
a
bunch
of
listeners
in
one
gateway.
E
Yeah,
I
think
that
I
definitely,
I
think,
I'm
going
to
encounter
more
like
problems
to
solve
in
our
implementation
down
the
road,
but
now
I
at
least
know
that
it
is
intentional
what
the
reasons
why
are
so.
B
Yeah
cool
cool
yeah,
if
you
can
think
of
anywhere
where
we
should
write
that
down
so
that
other
people
don't
have
to
ask
the
same
question
then
please
feel
free
to
make
a
suggestion.
This
is
a
classic
case
of
stuff.
That's
in
my
head
or
rob's
head.
That's
that's
there
for
historical
reasons
where
it
just
hasn't
been
written
down.
Yeah.
A
A
Each
combination
of
port
protocol
and
host
hostname
is
intended
to
be
unique
within
the
gateway.
I
recognize
that
there
are
flaws
in
each
of
these.
Hopefully
this
is
the
most
straightforward
of
the
possible
options,
but
I
know
that
each
has
its
unfortunate
downsides,
interested
in
yes,
better
ways
to
document
and
also
if
there
are
tweaks
to
our
approach
or
documentation
that
could
help
but
yeah.
Thanks
for
raising
that,
I
kalisia,
I
think
yeah.
How
can
we
help.
G
Yeah,
so
I
was
in
the
meeting
last
week
and
we
were
talking
about
the
hsp
routes,
conditions
and
status,
and
you
all
asked
me
asked
someone
to
open
a
new
ticket
and
they
volunteered,
and
I
thought
and
the
reason
why
I'm
asking
is
because
I
thought
it
was.
The
ticket
was
supposed
to
be
for
just
to
extract
like
the
actual
readiness
portion
of
that
ticket.
But
now
I'm
not
so
certain
and
also
the
the
issue
number
one,
one
one
one
that
you
display
just
a
few
minutes
ago.
G
B
Correct
me,
if
I'm
wrong,
but
I
think
you
said
the
magic
word
ready
and
I
think
that
reminded
me.
I
think
the
the
key
was
that
we
wanted
to
extract
the
discussion
about
what
does
ready,
mean
yeah
and
so.
B
Triple
on
the
quad
one
issue,
but
we,
but
we
need
to
have
a
specific
issue
for
us
to
talk
about
you.
You
know:
do
we
have
a
ready
condition,
yeah,
exactly
yeah.
G
B
Yeah,
it's
like
cons.
The
issue
title
should
be
like
consider,
consider
adding
a
ready
condition
everywhere,
and
you
know,
and
the
the
discussion
is
then
about
you
know,
should
we
add
a
ready
condition
anywhere.
It
can
be
hard
for
implementations
to
that
and
what
does
a
ready
condition
mean
like?
It
means
that
this
is
guaranteed
to
be
finished,
the
the
eventual
consistency
has
eventuated
and
you
know
like
this
is
finished
and
that
that
that
is
the
implication
and
so
like.
B
If
you're,
if
you're
implementation
can't
do
that,
then
what
can
you
do
you
know
like?
Is
there
some
other
way
that
some
other
condition
that
we
can
say
that
we
talked
about
configured
or
programmed
or
something
like
that?
That's,
like
hey
I've
done
everything
I
can
do
now.
Now
I've
got
to
wait
now
you
gotta
just
probe
and
see
what
happens.
This
has
come
up
a
lot
because
you
know
a
k
native.
That
needs
to
be
comp
to
be
sure
that
everything
is
fully
configured
in
its
data
path
before
it
starts
sending
things.
B
But
k.
Natives,
like
sort
of
duty
cycle,
is
a
lot
shorter
than
the
sort
of
wall
clock
time
that
we
usually
care
about,
like
that,
usually
for
users,
you're,
making
a
change
once
you
don't
yeah
and
then
like
if
it
takes
10
seconds.
That
is
not
a
big
deal
right,
like
you
know,
you've
made
the
change.
B
You
wait
10
seconds,
it's
all
good,
it's
fine,
whereas
for
k,
because
there's
constantly
spinning
up
and
spinning
down-
and
you
know
scaling
to
zero
and
stuff
like
that,
those
few
seconds
can
be
crucial
and
so
like
it's
important
for
the
way,
the
canadian
forex
to
be
able
to
be
100
sure
that
that
everything
is
good,
and
so
I
think
that's
the
yeah.
I
mean.
Obviously
you
work
on
canadians.
B
You
know
what
I'm
talking
about,
but
that,
but
that's
the
that's
where
the
ready
requirement
from
that
evan
has
been
talking
about
on
a
few
issues
has
come
from
is
that
right
now
kdm
has
k-native
has
a
whole
bunch
of
custom.
Probing
logic
that
will
probe
through
the
data
path
to
100,
confirm
that
everything
is
good
and
that's
so
we
need
a
way
to
signal.
This
is
definitely
100
configured
and
that's
what
the
ready
contract
kind
of
implies.
G
Got
got
it
all
right,
thanks
nick,
and
so
there
is
that
issue
named
discrepancies
between
accepted
ready
in
the
past
condition
types
and
reasons
it
is
pretty
long.
So
I
just
want
to
make
sure
that
that
issue
when
it
comes
to
the
route
condition
type,
which
I
think
is
we
talking
about
specifically
just
the
http
routes
right.
A
I
so
I
think
this
could
apply
to
all
route
types.
I
so
good
yeah
this.
This
is
a
really
good
discussion
and
I,
I
think
what
so
earlier
in
the
meeting
mike
and
I
agreed
to
go
through
this
issue
and
split
up
things
into
different
follow-up
issues,
because
it
is
a
massive
issue.
A
I
think,
if
you
want
to
specifically
take
this
and
move
it
into
a
different
issue,
we
can
just
link
that
off
to
whatever
issue
you
create
and
then
the
other
ones
we
may
be
able
to
group
in
other
ways,
but
I
think
this,
the
idea.
B
Cool
nice
again
not
taking
notes
one
of
us
not
writing
that
down
immediately
strikes
again
so
yeah.
We
all
got
to
remember
that's
on
me
too.
A
A
Yes,
let's,
let's
come
back
to
that
nick
and
I-
and
I
think
others
on
this
call
will
be
at
kubecon
next
week
and
valencia.
If
you're
there
we'd
love
to
meet
you.
I
think
we'll
both
be
at
the
contributor
summit
on
monday
and
then
we're
giving
a
update
talk
on
thursday
five
something
I
can't
remember.
A
But
I
think
we're
the
last
talk
of
the
day
or
in
the
last
slot
of
the
day,
so
we'll
probably
just
meet
up
after
and
I
don't
know
that,
there's
anything
formal
advertis
you
know
organized
but
because
we're
the
last
session
of
the
day
it
means
we
can
continue
talking.
However,
long
wherever
whatever
makes
sense
so
yeah,
I
we
would
love
to
see
people
that
are
at
kubecon
and
if
not,
I
will
follow
up.
A
I
think,
for
anyone
that
missed
the
beginning
of
this
meeting,
we're
planning
on
canceling
the
next
two
gateway
api
meetings,
so
we'll
meet
back
in
three
weeks
from
now
on
soon,
and
hopefully,
we'll
see
some
of
you
in
person
in
valencia.
B
Indeed,
and
as
always,
if
you
have
questions
before
then
slack
channel's,
always
there,
you
know
we'll,
I
will
I'll
be
checking
that,
while
I'm
in
kubecon
intermittently
so
yeah,
if
you
need
to
ask
things
until
then
of
robbery,
then
bring
us
individually
or
put
it
in
the
channel.