►
From YouTube: Gateway API Service APIs Office Hours 20201021
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
A
We've
had
a
couple
interesting
discussions
come
up
over
the
past
week
that
I
think
will
be
great
to
discuss
here
on
this
meeting,
but
before
we
get
there,
I
want
to
take
a
quick,
a
couple
minutes
to
go
through
our
v1
alpha
one
milestone.
We
keep
on
getting
ever
closer
to
being
complete
here,
trying
to
find
anything
that
is
new
here.
I
believe
this
is
relatively
an
order,
which
means
the
last
two
that
we
haven't
discussed.
Yet
are
these
two
gateway
listeners
default
for
hostname
match?
B
Have
if
you
scroll
down
into
the
cms
block,
we
have,
we
have
host
name
of
match
type
any
and
if
you
have
like
tcp
or
any
other
protocol,
which
does
not
have
the
concept
of
host
name,
then
that
confuses
users
now
james
pointed
out,
and
that's
right
that
the
documentation
says
that
you
know
the
match
type
of
any
means.
B
B
A
Yeah,
I
that
that's
that's
where
I
would
lean
as
well
the
the
whole
idea
that,
although
this
isn't
technically
wrong,
it
feels
unnecessary
for
a
gateway
that
is,
you
know,
using
tcp
protocol
you'd,
rather
not
see
that
in
your
spec
at
all,
and
based
on
that,
I
think
it
may
be
better
to
infer
this
behavior
from
the
absence
of
a
hostname
field
being
set
a
listener
than
to
actually
set
that
default.
D
D
This
case,
it
does
make
sense
that,
like
that,
the
conflict.
E
That's
okay.
I
was
just
going
to
say
I
I
don't
really
see
that
this
is
different
to
any
of
the
other
places
where
we
default
things.
I
think
the
nice
thing
about
being
able
to
make
defaults
is
that
the
configuration
is
explicit,
and
so
we
you
can
see
here.
Oh
when
I
made
a
protocol
tcp
when
I
made
a
tcp
protocol
thing
and
I
didn't
specify
the
host
name,
it's
going
to
match
any
host
statement,
so
it
whacks
you
over
the
head
with
what
the
default
actually
is.
So
you
can
see
it.
C
I
mean
would
another
option
be
since
since
hostname
is
irrelevant
for
layer,
4
load
balancing,
I
see
that
we
have
exact,
we've
got
domain
and
any
what?
If
we
added
an
additional
hostname
match,
type
of
none
that
would
be
used
for
tcp
route
or
any
layer
4
protocols
that
essentially
don't
do
any
hosting
matching.
C
D
A
So
what
I
was
going
to
say
here
is
to
me
hostname
feels
irrelevant
here
and
if
it's
so
I
I
agree
with
what
james
is
saying,
we're
using
defaults
all
over
the
place
and
those
defaults
make
it
clear
that
when
you
haven't
specified
anything,
this
is
what's
happening
and
I
like
the
use
of
defaults
wherever
that's
the
case,
but
in
this
case
you
know
like
l4
protocols
where
hostname
is
not
entirely
relevant.
A
If
we
could
default
for
specific
protocols
only
that
would
make
this
feel
a
lot
better,
but
because
we
have
to
default
for
all
or
nothing.
I
would
rather
only
set
this
field
or
only
default
this
field,
so
it
shows
up
in
the
manifest
no
times,
because
we
have
this
l4
weirdness,
where
it
just
to
me.
It
feels
unnecessary
and
potentially
confusing.
D
Because
for
http
you
want
it
to
be,
you
want
it
to
default
to
the
hostname
matching
and
you
want
it
to
be
present
and
you
want
it
to
tell
you
that
that
that
it's
matching
any
not
you,
don't
you
want
not
to
have
to
infer
that
from
the
fact
that
there
is
no
host
name
match
it's
right,
yes,
yeah!
That's
it.
E
D
The
fact
that
tcp
has
a
hostname
match
anywhere,
that's
not
really
relevant
or
or
if
we
change
it,
so
that
the
default
for
hostname
is
nothing
and
it's
not
present,
and
you
create
a
http
route,
and
you
don't
have
anything
saying
this
will
match
on
any
hostname
like
which
one
is
which
one
is
more
confusing.
I
guess
is
the
question
then,
because
those
are
the
two
options
right
like
either
we
have
a
default.
That
is
a
non-empty
default,
in
which
case
everything
will
show
up
or
we
don't
and
we
have
a
default.
D
A
That's
cool
but
I
to
me
I
would
interpret
a
match
type
of
none
as
potentially
like,
potentially
even
more
confusing.
You
know
one
way
to
interpret
match
type.
None
means
match
no
host
names
at
all,
which
you
know
seems
stupid,
but
you
could
interpret
it
that
way
to
me
match
type.
None
seems
very
similar
to
match
type
any,
at
least
in
terms
of
how
we
would
interpret
it.
B
I
see
okay
yeah,
I
mean
I
get
that
argument
too,
when
I'm
fine
leaving
this
the
way
it
is.
I
just
wanted
to
make
sure
that
we
are
doing
this
and
we
are
okay
with
this
api.
This
is
definitely
a
little
confusing
to
me,
but
it's
not
something
that
you
know,
I'm
like
no,
no.
We
have
to
absolutely
fix
this.
So.
D
Yeah,
I
guess
so
I
guess
my
so
how
about
I
will
go
there
now
and
I
will
put
a
thing
in
there
saying
you
know:
here's
my
here's.
My
feelings
on
we've
got
two
options.
We
can
either
leave
the
defaulting
in
place
and
have
confusion
on
the
tcp
case
or
we
can
set
it
so
that
the
default
is
empty,
which
will
be
much
easier
to
understand,
which
I
agree
is
easier
to
understand
in
the
tcp
case,
but
that
will
then
produce
some
slightly
magic
behavior
in
the
http
route
case.
D
C
Hey
rob:
can
you
do
a
refresh
on
this
and
then
scroll
down
to
an
example
that
I
added
just
to
so
if
we're
saying
that
the
like
the
hostname
matching
is
not
applicable
across
all
protocol
types
and
what?
If
what?
If
we
did
a
little
refactoring
and
we
say,
okay-
get
rid
of
host
the
hostname
matching
at
the
listener
level
and
kind
of
expand.
What
protocol
is
when
we
say?
Okay,
well,
the
protocol,
what
type
and
what
kind
of
host
name
matching-
and
you
know
what
we
can
do.
A
And
just
to
surface
bowie's
comments
from
chat,
and
I
think
he's
pointing
out
that
http
pointing
to
tcp
route
yeah.
B
C
C
Yeah
yeah
yeah
again
I
was
trying
to
do
this
quick,
but
yeah.
I
know
exactly
what
you're
saying,
so
let
me,
let
me
just
make
one
other
revision
to
it.
Then.
A
Yep,
so
just
to
kind
of
point
in
the
other
direction,
a
little
bit
when
we've
when
we've
run
into
you,
know
any
kind
of
controversy
over
defaulting
fields.
A
E
You're
not
actually
changing
the
default.
What
you're
doing
is
you're
making
using
is
you're
moving
the
default
from
being
explicit
in
the
yaml
to
being
implicit
in
the
ingress
controller.
A
Yeah
that's
correct,
but
so
to
me
this.
This
does
feel
somewhat
different,
though,
because
the
absence
of
specifying
to
me
the
way
I
interpret
this
api,
if
you
don't
specify
host
names,
it's
reasonable
to
assume
match
any
host
name,
and
if
you
do
specify
host
names,
it's
reasonable
to
assume
just
match
the
host
names.
I
specified
that
that
seems.
Like
a
you
know,
it
seems
like
a
way
to
further
filter
what
is
being
matched
here,
but
not
something
that
is,
you
know
if
it
doesn't
exist,
just
match.
Anything
seems
like
a
reasonable
interpretation.
D
D
I
understand
I
understand
the
point
of
making
james
about
the
fact
that
then
it's
it's
kind
of
down
to
the
controllers
about
what
they
do
but
like
like,
if
I
do
feel
like
adding
match
you're,
adding
a
match
condition
on
the
host
name,
right
like
if
you
specify
a
hostname
and
depending
on
the
from
what
I
remember
of
this
bit,
you
know
it
looks
like
you
can
do
exact
or
wild
card
or
something
like
that,
and
you
know,
then
the
field
is
just
about
telling
you
what
should
be
in
the
field
and
so
yeah
just
having
it.
E
E
I
I
guess
I
don't
have
a
super.
I
mean
this
isn't
the
end
of
the
world
if
you
take
it
out,
but
my
preference
is
for
defaults
to
be
explicit
when
we
can
make
them-
and
I
I
don't
think
I
don't
see
this
as
a
as
a
special
case.
A
Yeah
that
makes
sense.
I
I
need
to
think
about
this
more
myself
it.
I
appreciate
everyone
who's
already
added
comments
here.
I
have
missed
this
conversation
so
far,
so
I
will
follow
up
here
as
well,
and
maybe
we
can.
A
We
can
have
a
bit
more
conversation
on
this
issue
and
follow
up
tomorrow
and
hopefully
we'll
have
some
consensus,
but
I
I
agree
with
what
james
is
saying
as
well,
that
I,
I
think,
there's
you
know
a
reasonable
case
to
be
made
with
either
decision
here
and
I'm
not
going
to
be
terribly
upset.
If
it's,
you
know,
if
there
is
a
default
here
or
if
there
isn't,
but
right
now,
my
my
preference
leans
towards
not
setting
a
default.
A
Okay,
I'll
keep
on
running
then
again,
that's
issue
403.
If
anyone
wants
to
a
very
memorable
issue
number,
if
anyone
wants
to
continue
that
discussion,
okay,
so
the
other
one
is
just
a
follow-up
issue.
I
created
this.
We
removed
we've
had
lots
of
discussions
around
this.
A
We
removed
allowed
gateway
namespaces,
at
least
for
now
in
favor
of
other
options,
and
the
argument
was
that
for
now
we
should
provide
examples
of
how
you
use
policy
tools
like
gatekeeper
to
enforce
this
instead,
and
this
is
just
a
tracking
issue
to
actually
add
those
examples.
A
E
A
A
We
are
legitimately
getting
closer
with
that
said,
we've
got
plenty
more
to
discuss
here
and
I
want
to
make
sure
we
have
time
for
it.
Yes,
right
off.
Top
of
the
line
is
an
issue
that
generated
a
lot
of
discussion,
and
I
I
know
we've
gone
back
and
forth
on
this
and
we've
said
some
things
that
suggest
that
gateway's,
quick
gateway
merging
should
not
happen,
but
apparently
we
don't
quite
have
consensus
on
exactly
what
that
should
look
like.
So
I
guess
harry
you,
you
started
this
discussion.
Do
you
have
any
background
here.
B
Yeah
so
before
we
start,
I
mean
I
expected
this
to
be
a
little
controversial
or
rather
folks
not
to
have
consistent
consensus
on
it.
So
this
is
expected,
but
this
came
up.
You
know,
like
makaya,
pointed
out
during
a
conversation,
yeah
should
gateway
emerging,
be
allowed
or
not
right
and
and
and
we
in
the
conversation
said
yeah
it
should
not
be
allowed.
B
Then
I
went
back
thought
about
the
cases
where
you
know
ingress
resource
merging
was
being
done
and
then
I
think
who
was
that
I
think
it
was
neck
or
I
think
it's
naked
down
in
the
thread
below
who
points
out
here.
We
now
allow
to
set
dls
certificates
on
the
http
route
level
so
which
was
one
of
the
main
reasons
to
do
gateway
merging.
So
that's,
but
that
case
is
already
solved
now
so
yeah
I
mean.
D
So
I
think
it
was
kaia
actually
who
pointed
that
out
yeah.
But
I
think
that
I
made
the
converse
point
that
the
that,
if
we
do
that,
then
it
kind
of
messes
with
the
people
who
don't
want
to
allow
anybody
who
want
to
stop
explicitly
stop
people
from
being
able
to
add
any
cert.
They
want
to
the
thing
a
little
bit.
So
I
mean.
Maybe
we
do.
A
So
my
understanding
of
the
issue
here
is
that
there
are
potential
ramifications
here
for
conflict
resolution
and
they
just
conveniently
go
away
when
we're
not
doing
gateway
merging-
and
you
know
the
the
idea
is
well
hey
if
you
just
have
a
whole
bunch
of
listeners,
isn't
that
a
equivalent
to
several
gateways
with
those
listeners
you
know
split
across
them,
so
with
this
new
listener,
abstraction
that
we
have
relatively
new.
Does
that
solve
gateway
merging
to
clarify
I'm
not
arguing
in
favor
of
that?
H
H
D
H
F
H
Okay
yeah,
my
question
was:
do
we
have
a
sense
of
what
merging
means,
because
I
can
imagine
you
have
infrastructure
where,
due
to
various
things
like
a
set
of
multiple
gateways,
can't
be
created
because
it
violates
some
kind
of
shared
resource?
H
E
E
A
So
the
the
counter
argument
to
that,
I
think,
is
if
we
don't
know
what
merging
means
and
we
leave
it
open
to
gateway,
merging
we're
leaving
ourselves
up
to.
You,
know:
10
different
implementations,
implementing
gateway,
merging
10,
different
ways
and
losing
any
kind
of
sense
of
portability
for
that
part
of
this
api.
But
that's
the
point.
E
H
A
H
We
should
focus
on
like
if
you
had
to
reject
a
gateway,
because
it
has
an
underlying
shared
conflict,
then
like
how
what
the
behavior
would
be.
So
I
can
give
you
an
example
like,
for
example,
you
have
a
pool
of
ips
and
then
you
start
stuffing
the
gateways
into
this
pool
of
ips.
Eventually
you
run
out
because
it's
a
fixed
pool
so
like
you
may
have
to
merge
some
of
them,
but
but
the
way
you
merged
it
is
not
like.
There
could
be
many
ways
that
you
you
have
done,
that.
D
It
sounds
like
the
the
important
part
then
for
the
and
I'm
making
air
quotes.
When
I
say
conflict
resolution,
is
you
know
how
you
surface
the
conflict,
the
information
about
the
conflict.
You
know
like
we
in
the
in
any
of
the
cases
that
we've
talked
about
there.
The
important
part
is
how
do
you
like?
We
need
to
be
very
so
we
maybe
we
don't
have
to
be
prescriptive
about
what
merging
means
and
how
you
merge.
D
But
we
do
need
to
be
prescriptive
about
what
you
put
in
the
status
to
tell
the
end
user,
that
something
went
wrong
yeah
and
then
there
needs
to
be
specific
things
to
say.
You
know
specific
ways
that
you
say
there
was
a
con.
You
tried
to
merge
this
and
there
was
a
conflict
or
something
like
that,
but
that
that
there
are
very
clear
ways
in
need
for
the
api
to
say
you
know
this.
D
This
ingress
class
expects
to
merge
gateways
or
this
gateway
class
sorry
expects
to
merge
gateways
and
I
couldn't
merge
them
for
some
reason.
You
know
there
needs
to
be
a
very
clear
way
to
say
that
that
is
implementation
independent,
so
that
across
implementations
you
can
always
be.
You
can
always
be
sure
that
there
is
a
straightforward
way
to
know
that
that's
happened.
If
you
see
what
I'm
saying.
E
Yeah-
and
I
think
we've
tried
to
address
that
with
the
conditioned
vocabulary
so
by
making
sure
by
trying
to
have
standard
types
and
reasons.
So
after
the
check,
I'm
not
sure
we
have
a
reason
for
across
gateways.
We
definitely
do
have
reasons
that
cover
conflicts
within
gateways.
A
Yeah,
maybe
maybe
a
good
next
step
here
would
be
to
do
a
follow-up.
Pr
that
you
know
just
adds
conditions
for
what
you
know
for
you
know
for
conflicts,
merging
gateways,
because
I
I
agree,
I'm
pretty
sure
we
don't
have
that
specific
thing
covered
yet
in
our
gay
wave
in
our
condition
vocabulary,
but
that
may
be
the
best
thing
we
can
do
at
this
point
to
cover
merging.
B
D
Gateways
yeah
it
comes
down
then,
to
the
detailed
reason.
Probably
you
know
in
the
detailed
reason
you
need
a
way
to
say
there
was
a
conflict
between
the
listener
from
this
gateway
and
the
conflict
from
the
listener
from
this
gateway.
Just
so
that
you
can
there's
a
discoverable
way
for
a
person
who's.
Looking
at
this
to
figure
out,
which
is
the
one
to
do
it,
I
would
say
most
things
that
are
going
to
do
merging
are
probably
going
to
want
to.
D
G
A
Yeah,
I
I
agree
with
that
harry
since
you
started
this
conversation.
How
do
you
feel
about
where
we're
heading
right
now.
B
Yeah,
I
think
I'm
I'm
not
too
concerned
about
conflict
resolution.
I
think
that
can
be
resolved
as
we
are
already
talking
about.
That's
that's
not
the
big
problem.
I
think
to
me
a
couple
concerns
right.
The
first
concern
is:
will
this
change?
You
know,
make
users
abuse
gateway
resource
as
an
increased
resource,
and
you
know
what
I've
like
you
know.
People
are
merging,
10,
000
gateway
resources,
instead
of
you
know,
have
like
organizing
it
a
separate
way,
and
then
you
know
we.
I
still
don't
understand
the
use.
B
Cases
be
like
a
proper
use
case
behind
it.
Yet
so
that's
my
limitation
there
and
the
second
is,
I
think
we
always
talk
about
like
we
don't
have
to
be
descriptive
of
implementation
at
all,
and
I
sort
of
disagree
there,
because
when
we
talk
about
portability,
it's
not
just
about
you
know
portability
of
the
api
or
how
you
know
define
policies
right
like
here.
We
do
it's
also
about
the
end
result
right,
like
the
the
you,
the
end
user
should
be
able
to
move
across
implementation.
C
D
D
I
think
that's
a
fair
point
that
yeah,
like
I
mean
we've,
got
to
have
opinions
about
something
right
like
if,
if
I
was
brutally
summarizing
what
you
just
said
harry-
and
it
kind
of
does-
makes
it
yeah.
We
need
to
have
opinions
about
some
things
to
do
with
the
thing,
and
we
need
to
be
able
to
say
you
know
your
implementation
needs
to
be
bounded
in
some
ways.
I
don't.
I
think
that
it's
probably
fair,
that
we
need
to
talk
more
about
the
use
cases
that
would
be
here
again.
D
But
I
think
that
I
think
john's
john's
point
is
fair,
that
if
you've
got
a
lot
of
domains
and
you've
got
a
lot
of
you
and
they
all
need
tls
details
or
something
like
it,
you
it
does
you
you,
you've
got
to
put
them
somewhere
and
and
being
able
to
and
being
able
to
specify
stuff
about.
D
Those
domains
in
a
central
place
is
nice,
and
it
feels
like
a
lot
of
the
stuff
that
we
have
in
gateway
you're,
going
to
either
be
putting
using
the
gateway
or
you're
going
to
be
duplicating
a
lot
of
the
information.
That's
in
the
gateway,
because,
if
you
do
want
to
stop,
if
you
don't
want
to
not
say
hey,
accept
anything
which
you,
which
kind
of
having
just
using
the
http
or
out
thing,
is
then
you're
kind
of
stuck.
D
So
I
think
that
that
feels
to
me,
like
the
use
case,
that's
probably
going
to
be
the
most.
I.
B
Mean
I
mean
so,
let's
take
it,
let's
take
it
the
other
way.
When
I
read
john's
comment,
I'm
like
okay,
you
have
10
000
domains
and,
if
you're
behind,
like
a
single
gateway,
you
know
that's
too
big
of
a
blast
radius.
Maybe
you
we
should
recommend
that
if
you
have
that
kind
of
scale,
you
should
have
different
gateway
resources
which
map
to
different
load,
balancers,
right
or
whatever.
B
Maybe
you
want?
Maybe
you
should
don't
want
gate
to
be
merging
and
you
do
want
one
separate
point
of
entries
right.
So
maybe
that's
another
way
to
to
look
at
the
problem
right
like
rather,
we
solve
for
the
configuration
part,
but
when
it
translates
to
the
infrastructure,
it
rather
creates
a
new
problem.
H
Like
isn't
that
not
future
proof,
because
it,
it
seems
like
what,
if
there
was
a
way
that
after
you,
so
you
set
up
multiple
gateway
resources
and
so
basically,
on
the
api
side,
everything
as
you're
describing
would
be
the
same,
and
we
are
basically
saying
well
that
guarantees
you
a
certain
behavior
internally,
but
it
seems
a
bit
not
future
proof
like
what,
if
that
could
be
done,
but
it's
just
slightly
different
or
you
could
share
some
resources
but
other
resources.
That's
where
I
yeah
like
we
wouldn't.
H
E
E
D
The
point
that
I
was
trying
to
make
was
there
doesn't
seem
to
me
to
be
a
fundamental
difference
between
merging
gateways
that
have
listeners
in
them
and
merging
a
list
of
listeners.
That
only
applies
if
the
gateways
don't
have
addresses
specified
as
well.
You
know
like
and-
and
I
guess
the
the
the
thing
here
is
about
you
know
this
comes
back
to
a
little
bit.
What
jones
are
saying
where
it's
up
to
the
implementation
to
be
like.
Do
you
care
about
addresses
or
not?
D
So
we
will
probably
just
ignore
the
addresses
fields
and
say:
hey
you
know,
or
if
you
set
one
say
hey,
we
can't
do
this,
and
so
you,
it
kind
of
feels
like
and
so
for
contour
the
case
of
merging
gateways
is
effectively
just
making
it
making
there
be
a
nicer
way
to
be
able
to
have
to
split
a
big
list
of
listeners
up
into
a
small
into
a
set
of
smaller
lists.
D
You
know
and
that
that's
the
thing
that's
nice
for
contour
about
being
other
merge
gateways
you,
but
that
again,
is
a
prop
is
because
we
have
properties
about
addresses
where
we
don't
care.
We're
not
going
to
do
addresses.
D
So
I
don't
know
like
it
feels
to
me,
like
the
rules
about
merging
gateways,
come
down
to
the
rules
about
how
much
you
care
about
you
like.
Can
you
merge
listeners
like
I
mean,
there's
rules
for
merging
listeners
inside
a
gateway
and
are
there
rules
for
merging
addresses
inside
a
gateway?
If
there
are,
then,
then
there's
no
reason
why
you
shouldn't
merge,
because
there's
only
three
fields
in
the
top
level.
Maybe
that
doesn't
make
sense.
B
B
D
Yeah,
I
seem
to
recall
us
talking
about
that
before
and
saying
that
my
I
think
my
original
expectation
was
that
one
of
the
things
that
you
would
get
from
the
status
of
the
gateway
class
is
that
the
controller
that
implements
the
gateway
class
would
write
something
back
to
the
status
of
the
gateway
class.
Saying
hey,
I'm
taking
this
gateway
class
and
here's
the
capabilities
or
the
way
that
I'm
going
to
treat
the
gateways
in
them.
D
And
so
you
know
so
the
the
with
the
intent
being
that
you
say,
I'm
going
to
merge
listeners
across
gateways
and
not
care
about
addresses
in
the
case
of
control
or
something
like
that.
You
know
insert
and
have
some
reasonably
machine
readable
way
to
specify
that
information
on
the
gateway
class.
Just
so
that
you
can
have
so
that
your
personal
machine,
readable
ways
so
that
you
can,
as
a
person,
be
like.
D
Okay,
I
assign
this
gateway
class
to
contour,
say
and
then
contour
tells
me
what
how
it's
going
to
treat
the
gateways
and
then
that
way.
You
know
if
your
setup
is
going
to
work
or
not
something
like
that.
B
B
Okay,
if
we
want
to
allow
merging
it's,
you
know
it's
an
optional
thing
in
the
spec
that
implementations
can
do
and
then
we
at
least
have
some
guidance
around
okay.
You
can
merge
gateways,
and
you
know
this
is
the
behavior
that
users
would
expect
right
like
we're
right
now
trying
to
solve
for
a
hypothetical
case
and
to
incorporate
a
hypothetical
case
into
the
api,
and
that's
like
that
seems
problematic.
Right,
like
we
might
be
missing
things
out
in
the
api.
E
I
guess
I'm
still
struggling
to
understand
what
problem
we're
solving
by
being
prescriptive
here.
What
harm
would
come
I
mean
I
don't
know
why
we
wouldn't
just
see
what
implementations
do
and
then,
if
people
have
problems.
E
E
If
people,
if
implementations,
merge
in
a
way
that
sucks,
then
you
know
people,
those
implementations
will
suck
and
people
won't
use
them
right.
B
I
mean
that's
the
that's,
that's
the
thing
that
we
should
try
to
avoid
right
like
if
like,
if
we
give
away,
if
we
give
the
community,
you
know
a
prescriptive
way
of
getting.
This
is
what
a
gateway
resource
means,
and
this
is
how
initially
people
tear
out
resource
means.
You
know
we
we
would,
I
think,
as
api
authors,
we
should
try
to
avoid
situations
where
our
api
can
be
abused
in
ways
that
we
don't
expect
right
now,
but
you're
saying
I
think
the.
E
H
Yeah
harry
though
I
have
to
say
there
are
concrete
examples.
I
know
that
the
apac
well
at
this
time
does
work
for
you
guys,
but,
like
I
know
that
ali
cloud
a
couple
years
ago,
tried
had
a
proposal
basically
where
they
had
like
some
fixed
number
of
optics
number
load
bouncers
each
low
bouncer
could
only
take
a
certain
amount
of
capacity,
and
then
you
could
imagine
creating
a
pool
of
these
and
then
they
wanted
to
schedule
gateways
onto
that
and
you
could.
H
D
D
Didn't
you,
why
not
let
like
see
how
we
go
in
this
version
of
the
alpha
and
we
can.
We
can
turn
up
the
dial
to
become
more
prescriptive
if
it
is
a
problem,
is
that
you
I
mean,
I
think
it's
a
fair
question
to
ask,
but
but
also
like,
maybe
it's
better
to
get
some
real
world
examples
by
having
people
actually
make
implementations
and
see
what
it's
like.
B
Yeah
I
mean
this
sounds
like
repeating
the
problem
where
so,
let's
take
an
example
today
right
like
not
to
point
fingers
at
anyone,
but
you
know
the
way
cloud
providers
implement
ingress
resources,
they
spin
up,
in
most
cases
a
load
balancer
for
increased
resource
and
the
way
a
lot
of
proxies
do
it.
They
merge
increase
resource.
B
Now,
when
users
do
go
between
them,
it
does
create
a
point
of
friction
and,
like
the
users
do
get,
you
know
confused
and
for
for
variety
of
reasons,
do
we
do
we
want
to
solve
for
the
problem
or
is
it
like?
You
know.
We
expect
that
yeah
that
level
of
implementation
is
not
never
going
to
be.
You
know
a
part
of
this
api
and
that,
like
that
is
something
we
should
document,
and
you
know
users
should
expect
these
changes
could
happen.
I
E
Understand
why
that
was
a
problem
for
for
this
api?
Can
you
I'm
not
sure.
H
Yeah
sorry,
I
unmuted
my
the
non
phone
actually
we're
looking
at
allowing
both
behaviors
harry,
like
as
a
gateway
class
parameter,
so
some
people
might
be
okay
with
merging.
So
we
would
merge
stuff,
that's
possible
and
then
instantiate
one
cloud
load
balancer,
because
we've
actually
heard
demand
for
this
and
then
the
other
one
would
be
the
what
you
would
expect,
which
is
to
actually
do
one
per
gateway
and
in
that
way,
like
people
can
choose
this
behavior.
B
D
H
That's
worth
having
especially
like
now,
I'm
thinking,
for
example,
physical,
low
bouncer
vendors
like
f5,
like
forcing
a
particular
behavior
for
merging,
would
one
of
the
consequences
would
be
like
you
only
have
one
gateway
that
represents
that
f5,
but
probably
that's
not
what
they
want.
They
probably
want
more
flexibility,
you
might
have
one
gateway
per
address
or
something
like
we
should
definitely
write
down
these
examples.
H
H
You
know
in
a
concrete
implementation,
but
I
just
feel
like.
If
we
start
with
the
merging
topic,
then
it
it's
like
you
know
it's
like
here's,
how
a
car
engine
works
and
then
you're
like
building
up
to
like
how
to
drive
a
car.
E
H
But
harry
are
you
looking
for
implementers,
because
I
know
that
we've
mentioned
previously
like
we
should
have
a
set
of
dots,
that
kind
of
pitched
for
implementers
versus
users.
I'm
more
talking
about
the
user
dog.
B
Think
this
is
more
geared
towards
implementers
as
to
when
they
should
offer
like
it's
not
exactly
saying
that,
like
you
know,
as
nick
said,
like
you
know,
it's
not
having
an
explicit
list
of
okay.
This
is
the
only
way
you
should
do
gateway
merging,
but
sort
of
clarifying
like
okay.
There
are
good
cases
for
gateway
merging,
and
these
are
some
cases
where
you
could
implement
your
like,
implement
this
api
and
do
merchant
right
like
like
we
do
this
for
in
other
parts.
Right
like.
B
I
think
there
is
a
one
thing
that
we
are
already
almost
merging
is
tls
is
like
you
know:
when
should
you
use
tls
at
the
http
router
versus
versus
the
gateway
level
right
and
there's
a
reason
where
you
know
we
think
you
know
using
one
over
the
other
will
be
easier
and
have
a
better
user
experience.
So
similarly,
you
know
like
having
some
prescription.
A
It
seems
like
at
a
minimum
what
we
need
for
v1
alpha
1
is.
We
need
to
be
able
to
say
a
couple
things
one.
We
need
to
be
able
to
say
that
merging
is
something
that
controllers
can
do,
that
implementations
can
do,
but
also
we
need
to
clarify
that
this
is
not
maybe
well-defined
behavior
or
that
this
is
not
required
of
implementations.
A
That
implementations
do
not
need
to
support
this
kind
of
merging.
It's
kind
of
an
optional
way
that
implementations
can
choose
to
implement
this
api.
A
D
Yeah,
I
probably
tend
to
agree,
and
the
good
part
is
that
all
of
what
you
said
can
be
summarized
in
a
single
rsc
style
word:
may
you
know,
implementations
may
yeah
may
merge
gateways
that
behavior
is
currently
undefined
and
we
expect
sample
implementations
to
help
you
to
help
sort
of
define
what
it
looks
like
for
them.
In
order
to
make
this
make
this
whole
set
up
more
clear
or
something
like
that.
E
D
Of
course,
but
it's
important
it's
important
in
terms
of
defining
the
spec,
to
say
to
say
things
that
you
are
expecting
people
that
they
might
do
versus
things
that
they
should
100.
Not
do
right,
like
you
know,
there's
a
difference
between
you
know
must
and
should
and
may-
and
you
know,
must
not
right
like
you
and
so
that's
why
I'm
suggesting
the
rfc
language,
because
it's
pretty
it's
pretty
clearly
defined
and
clear
that
you,
if
we
put
the
merging
as
a
may,
then
that
is
a
thing
that
you
can
do.
D
If
you
want
you
that
you
don't
have
to
do
to
be
a
valid
controller.
But
if
you
do,
then
you
then
there
should
be
eventually
we
should
put
something
in
there
to
say.
If
you
do,
then
here's
some
of
the
things
that
users
might
expect
from
you.
You
know
like,
I
think
it's
reasonable
to
have
in
there
for
someone
who's
building
a
newer
thing
who
hasn't
been
involved
in
any
of
this
discussion.
D
To
have
something
to
say
what
does
gateway
merging
even
mean
like
you
know,
there
needs
to
be
something
that
that
clarifies
the
community
expectation
around
what
gateway
merging
is,
even
if
that
doesn't
define
an
implementation
like
define
exactly
what
the
implementation
must
do.
It's
at
least
valid
to
say
here's
what
someone
who
picks
this
up
and
has
used
other
service
apis
things
before
and
your
gateway
says
it
does
gateway
emerging.
That's
this
is
what
they'll
expect
it
to
do
from
a
user
point
of
view,
not
from
an
implementation
point
of
view
right,
like.
E
A
And-
and
I
think
to
to
add
to
that,
the
it's
important
for
us
as
we're
continuing
to
develop
the
api
to
understand
potential
ways
the
api
can
be
used
and
it's
important
to
say.
You
know
that
it's
a
fairly
significant
thing
to
say:
yes,
you
can
merge
gateways
or
no
you
can't
so
to
say.
Yes,
you
can
is
important
for
other
potential
api
decisions
in
the
future,
so
I
would
lean
towards
explicitly
saying
that
you
may
do
that
somewhere.
A
So
there's
no
more
confusion
around
that,
but
I
also
want
to
be
very
cognizant
of
our
time
and
we've
spent
a
lot
of
time
on
this.
I
think
we're
reaching
some
kind
of
consensus,
at
least
for
what
we
need
for
v1
alpha
one,
and
I
encourage
more
discussion
here,
but
because
we're
short
on
time,
I
just
want
to
cover
just
a
few
more
things
before
we
call
this
meeting
over.
A
So
there's
a
couple
more
issues
here
and
I'll
get
to
them
briefly,
but
I
wanted
to
at
least
mention
this.
There
is
a
doc
there
has
been
a
doc
for
a
while,
but
I
updated
it
yesterday
with
the
current
state
of
our
main
branch
at
that
point,
and
we've
gotten
some
great
feedback
since
then
from
I,
I'm
not
sure
how
to
pronounce
that
name
and
also
tim
has
also
added
some
feedback
closer
to
the
bottom.
A
I
know
tim's
first
reviews
had
primarily
focused
on
gateway
and
gateway
class
and
we're
starting
to
get
a
lot
more
feedback
from
him
around
routes.
I
would
love
to
spend
some
time
walking
through
some
of
this.
There
are
some
smaller
things
like
this,
but
there
are
also
some
larger
comments
in
here
as
well,
but
overall
feedback
seems
positive
from
what
I've
seen,
but
there
are
some
changes
that
we
could
make.
Some
of
them
are
pretty
easy.
A
So
if
anyone
wants
to
knock
out
a
quick
pr,
there's
a
number
of
typos
and
various
things
that
yeah
could
help
but
yeah,
I
don't
have
enough
time
to
cover.
There's
there's
a
lot
of
pages.
We
built
a
pretty
large
api
here,
but
there's
some
great
feedback
here
and
just
wanted
to
draw
your
attention
to
it,
and
if
you
have
anyone
in
your
organizations,
that
would
be
great
at
giving
api
reviews.
A
C
The
the
pieces
of
feedback
that
we're
going
to
address
in
b1
alpha
one
does
it
make
sense
to
maybe
create
an
issue
and
link
it
where
I'm
going
is
like
the
potential
for
multiple
people
to
be
working
on
the
same
thing
and
yes,
yeah.
Absolutely.
A
So
I
think
some
of
these
are
not
worth
a
a
separate
issue
like
a
lot
of
these
are
typos
or
you
know,
should
instead
of
me
kind
of
things
that
I
think
a
lot
can
be
knocked
out
in
one
go,
but
there
are
some
like
well.
A
I
know
there's
a
few
that
I
saw
tim
added
that
are
larger
discussion
pieces
that
hopefully
we
can
dedicate
some
meeting
time
to,
but
for
for
ones
that
feel
like
typos.
I
think
we
can
get
knock
those
all
out
in
a
single
pr,
but
I
agree
we
should
we
should
triage
the
larger
ones
and
create
some
issues
for
them.
C
So
for
those
on
the
call
yeah,
if
it's,
if
it's
not
issue
worthy
make,
you
know
just
make
a
note
somewhere
saying
you
know
that
I'm
working
on
it
and
yeah.
A
C
Maybe
in
the
meantime,
at
the
top
of
the
document
and
kind
of
red
lettering,
or
something
to
get
people's
attention
to
say
you
know,
please,
you
know
if
it's
a
major
change,
please
open
an
issue
and
link
it
yeah,
just
trying
to
think
through
some
ideas
to
prevent
overlap.
That's
a
great
idea,
I'll.
A
E
E
E
And
we
didn't
realize
that
it
would
affect
the
listener
status
too.
So
this
is
a.
This
is
a
big
problem.
This
is
a
problem
yeah.
A
Yeah,
so
maybe
yeah.
If
you
want
to
create
a
follow-up
issue
for
this
one,
this
definitely
needs
some
more
discussion.
I
agree
yeah
and
thanks
to
everyone,
who's
already
given
feedback
here.
I
know
we're
we're
already
past
time,
but
if
you
have
anyone
else
in
your
organization
or
that
you
know,
that
would
be
give
some
good
feedback
here.
Definitely
appreciate
it.
A
Cool,
I
guess
I,
if
it's
okay,
we'll
move
these
until
tomorrow,
these
next
two
issues
and,
of
course,
if
anyone
has
time,
recommend
taking
a
look,
there's
a
couple
things
that
we
could
unblock
and
get
moving
again.