►
From YouTube: Gateway APIs Meeting (APAC Friendly Time) 20210726
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
we
are
recording.
This
is
the
gateway
api
meeting
for
july
26..
A
I
hope
I
got
that
date
right
and
we've
got
a
lot
going
on
thanks
to
everyone
for
the
activity
on
github
and
elsewhere,
just
getting
feedback
in
on
a
lot
of
different
issues
and
prs
that
we
currently
have
in
flight.
One
of
the
things
I
wanted
to
highlight.
I
presented
this
at
the
sig
network
community
meeting
last
week
on
thursday
there's
nothing
in
here.
That
would
be
new
to
anyone.
Who's
been
well.
A
I
think
almost
nothing
that's
in
here
that
would
be
new
to
anyone
who's
attending
these
meetings,
but
the
the
one
thing
that
I
wanted
to
highlight
is
we
are
so
far
and
that
we
may
miss
this,
but
still
trying
to
target
a
mid-august.
V1
alpha
2
release.
No
sorry
not
release
ready
for
review,
so
this
is
a
little
bit
different.
A
So
our
new
timeline
and
dates
are
targeting
that
that
time,
so
not
when
we're
actually
releasing
an
api,
but
when
we're
handing
it
over
to
another
set
of
reviewers
to
actually
take
a
look
and
walk
through
this,
and
I
reached
out
to
some
sig
network
reviewers,
who
are
listed
as
api
reviewers
in
the
community
for
sig
network
and
andrew
dan,
cal
and
tim
have
all
agreed
to
block
off
some
time
to
review
our
apis.
A
So
I'm
really
excited
to
have
all
of
them
able
to
help
us
review
this
api,
and
I
think
that's
a
great
mix.
That's
and,
of
course
this
is
not
meant
to
be
an
exclusive
list
of
reviewers
or
anything
I
just
wanted
to
reach
out
to
these
people
in
particular
make
sure
we
had
their
their
time
and
availability
to
review.
A
So
with
that,
I
you
know,
I'm
really
excited
about
getting
this
additional
set
of
eyes
on
our
api,
but
first
we
actually
need
to
have
an
api
that
we
feel
is
ready
for
that
extra
round
of
review.
There's
also
a
cap
associated
with
this.
I
don't
know
how
quickly
that
needs
to
move.
This
isn't
really
tied
to
any
release
cycle.
This
is
mostly
just
to
formalize
that
this
was
happening.
A
It's
kind
of
a
unique
process
where
I
I
talked
with
john
from
cigars
just
to
make
sure
that
this
is
the
correct
process,
and
this
is
what
was
recommended
so
yeah.
This
is
this
is
where
I've
been
going
so
far.
If
anyone
wants
to
change
timeline,
goals,
reviewers,
etc,
add
additional
reviewers.
That
would
be
great,
but
this
is
what
I've
been
thinking
of
so
far.
A
The
other
bits
I'd
not.
We
have
lots
of
other
content
to
get
through
in
this
meeting.
So
don't
want
to
spend
too
much
time
here,
but
if
you're
looking
for
a
summary
of
things,
we've
changed
in
v1
alpha
2
so
far.
This
is
that
so
it's
just
a
really
high
level
summary
of
things
that
we've
changed
and
some
that
are
still
in
progress
like
I
have
links
out
to
gaps,
for
example,
route
gateway
attachment,
but
anyways,
that's
that's
all
I
want
to
cover
here.
A
We've
got
lots
more
to
get
through
any
questions
on
this
process.
A
Yeah
so
I
would
say,
generally
positive
feedback.
I
don't
think
I
think
most
of
the
questions
were
about
how
release
cycle
would
work
if
we're
going
to
eventually
try
and
tie
ourselves
to
kubernetes
releases,
if
we'll,
eventually
try
and
get
some
kind
of
you
know
consistent
release
schedule
out,
instead
of
just
when
we're
ready,
it's
ready
kind
of
thing
and
and
and
other
things
like
that.
A
I
don't
have
great
answers
for
yet,
and
I
don't
know
if
anyone
has
recommendations
but
yeah,
I
don't
think
there
was
much
feedback
for
the
api
itself
yet,
but
I'm
I'm
hopeful
that,
as
these
reviewers
start
taking
a
look
we'll
get
more
so
yeah.
A
All
right,
let's
keep
on
going
there,
and
on
that
note
you
probably
saw
that
that
pr
get
in
earlier
today
last
week,
whatever
welcome
nick,
so
glad
to
have
you
officially
as
a
maintainer,
I
think
we
all
just
kind
of
assumed
you
were
already
officially
a
maintainer
but
glad
to
make
that
that
formality.
True,
really
excited
to
have
you
on
board
and
yeah
thanks
thanks
for
all
your
contributions
already.
A
Awesome
well,
the
so
there's
been
so
much
discussion
on
github
elsewhere
on
different
pr's,
especially
today
that
I
probably
lost
some
of
them.
So
if
anyone
wants
to
make
sure
a
pr
or
issue
is
discussed
here,
I
was
thinking
of
leaving
at
least
15
minutes
at
the
end
for
pr
and
issue
triage.
But
if
that's
not
enough
time,
I
can
try
and
time
box
these
gaps
to
smaller
chunks.
Does
anyone
want
to
reserve
more
time
for
specific
pr's
or
issues
we've
been
discussing.
A
Cool
all
right
I'll
keep
on
running
with
that.
Then,
let's
aim
to
have
this
specific
conversation
done
in
17
or
so
minutes,
so
that
would
be
27
after
the
hour
for
me,
so
this
is
get
724
and
it
has
had
fairly
minimal
discussion.
I
probably
didn't
give
the
strongest
introduction
possible
for
this,
and
I
also
recognized
that
this
may
have
come
out
of
left
field.
A
What
v
one
alpha
two
represents
to
me
is
something
we
can
always
add
to,
but
something
that
will
be
very
difficult
to
remove
from
not
impossible,
but
it's
always
easier
to
add
than
remove,
and
so
we
have
a
lot
of
possibilities
right
now
in
route
gateway,
binding.
Some
some
of
the
defaults
are
maybe
a
little
bit
too
permissive
or
open
and
not
as
secure
as
we'd
like,
and
the
variety
of
different
ways
you
can
connect,
gateways
and
routes.
A
Those
variety
of
factors,
I
think,
are
part
of
what
led
me
to
this
proposal
recommendation,
but
I
am
very
open
to
other
approaches
and
feedback
here
with
that
said,
I
want
to
open
up
discussion
if
anyone's
had
time
to
to
read
this
over.
Take
a
look
any
any
high
level
thoughts
on
on,
what's
being
proposed.
A
B
I
haven't
had
much
a
chance
to
have
a
look
at
the
we
actually
off
the
back
of
the
community
cbe.
We
actually
had
a
contour
cv
last
week,
which
was
took
all
of
my
time.
A
That
makes
sense
yeah.
I
know
I
know
it's
a
it's
a
busy
time
for
many
I'll,
just
I'll
just
run
through
just
the
the
very
high
level
ideas
here
and
that's
just
that
the
the
idea
is
instead
of
having
multiple
way,
we're
basically
narrowing
down
the
connection
possibilities
from
several
to
one,
and
that
means
that
route
directly
references,
the
gateway
or
gateways
it
wants
to
attach
to,
and
it
removes
specifically
the
selector
from
gateway
to
route.
A
That's
that's
it!
So
you
can
imagine
that
if
you
remove
the
route
selector
from
gateways
and
just
condense
the
route
to
gateway
option
into
from
list,
you
end
up
with
what
I'm
proposing
here.
I
think
this
is
essentially
the
the
simplest
we
can
make
this,
while
still
preserving
the
core
functionality
and
still
allowing
us
to
expand
back
out
into
this
mode
if
we
ever
need
to
or
want
to
I'm
just
I'm
not
convinced
that
we
need
the
level
of
complexity
we
currently
have
in
the
api.
A
But
that's
that's
the
high
level
approach
here.
I
recognize
it
could
take
some
time
to
to
think
through
this,
but
off
the
top
of
anyone's
head
or
any
any
hesitation.
C
A
Yeah
yeah
that
that's
exactly
it
it
is,
it
was
one
of
the
goals.
Unfortunately,
I
think
this
is
feedback.
We
got
internally
for
gke's
implementation
of
gateway
api,
so
I
don't
know
that
we
have
any
oss
feedback
saying
this,
but
that's
something
that
we
we
have
got
on
ourselves.
A
I
don't
know
if
anyone
else
any
other
active
implementation
out.
There
has
gotten
any
kind
of
similar
feedback,
but
the
the
feedback
we've
gotten
both
from
initial
usage
and
also
from
the
first
round
of
uxr
that
mark
has
done,
has
been
that
users
prefer
being
very
explicit
about
which
gateways
they
want
their
route
to
be
attached
to.
C
A
Yeah
it's
one
of
those
things
where
you
know.
I
personally.
I
really
like
that.
The
idea
of
that
kind
of
seamless
gateway
replacement
as
a
gateway
admin
you
can
just
spin
up
a
new
gateway
and
but
but
then
when,
when
we
tried
to
sell
that
to
to
users
and
uxr,
it
was
well
okay,
but
it
wasn't.
It
wasn't
a
very
exciting
capability,
at
least
to
to
the
people
we've
talked
to
so
far.
Instead,
they
would
rather
have
that
very
direct
and
clear
reference.
B
Yeah,
I
guess
the
like
it
does
seem
like
probably
as
an
app
owner.
You
probably
can't
see
any
pluses,
but
only
minuses
for
someone
being
able
to
change
out
your
the
running
infrastructure
that
underlies
the
connections
to
you
without
you
knowing
about
it.
So
I
can
kind
of
see
where
they're
coming
from.
I
think
that
it's
something
that
probably
your
your
sort
of
cluster
operator,
slash
gateway
owner,
is
going
to
be
more
interested
in,
but
I
think
you've
got
I
I
do
remember
now.
B
B
I'm
sorry,
I
mean
yeah
like
if
you
if
we
did
try,
decide
to
expand
that
and
and
change
that
to
a
selector
on
the
route
for
gateways
like
a
label
selector
or
something
like
that,
then
then
you
could
still
pretty
easily
replicate
this
right.
Like
you
could
say,
you
know,
hey
make
sure
that
your
gateway
that
your
route
is
allowed
to
bind
to
these
gateways
like
the
gateway
by
selector.
Then
you
could
do
that
or
you
could
just
say:
hey
add
this
gateway
into
your
route.
B
Please
and
then
you'll
have
two
ways
in
and
then,
when
we
confirm
that
the
new
way
is
good,
then
we
can
then
you're
gonna
remove
the
option
exactly
exactly
and
migration
probabilities,
it's
just
that
they
will
require
a
little
bit
more
and
there
will
be
a
little
bit
less
magic.
But
I
kind
of
feel
like
operationally
people
like
a
lot
of
the
time.
Less
magic
is
actually
good,
like
you,
don't
want
the
your
operational
procedures
to
be
too
magic
because
you
want
you
want
people
in
the
loop
at
each
step
to
be
like.
A
Yeah
exactly
and
that's
that's
what
I
want
to
highlight
here
is
that
I
I
don't
think
of
this
as
a
a
really
new
set
of
functionalities,
so
much
as
it's
removing
existing
functionality,
which
which
seems
maybe
even
scarier,
but
what
it
does
is
it
really
simplifies
what
is
capable?
What
is
what
is
possible
right
now
and
it
leaves
the
door
open
if,
if
we
need
to,
we
can
go
back
to
this
more
complicated
way.
A
If
that's
something
that
we
d,
we
we
determine
is
really
valuable
to
a
set
of
users,
it's
very
possible
to
go
back
to
this
more
complicated
way.
What
we
can't
do
is,
let's
say
we,
we
launch
v1
alpha
2,
as
it
is
right
now
with
all
these
complex
ways
of
connecting
the
two
things
we,
we
can't
pull
things
out
later,
or
it
would
be
very
difficult.
A
D
Yeah,
let
me
go
ahead.
Rob
have
you
considered
mesh
use
cases
here,
because
this
could
probably
could
this
could
possibly
be
more
challenging
for
the
mesh
implementations.
A
It
could
be
a
custom
gateway
resource.
Who
knows,
I
I
don't
know
of
any
use
case
for
that,
but
let's
who
knows-
or
it
could
be
some
kind
of
resource
that
represents
a
mesh
again.
These
are
these
are
fairly
undefined
right
now,
but
that's
how
I
imagined
this
connecting
to
mesh
does.
Does
that
make
sense
for
for
your
use
case.
D
Yeah,
oh
that's
interesting.
Okay,
so
then
routes
would
let's
say
you
have
a
virtual
resource
routes,
bind
to
that
and
then
your
listeners
forward
to
that
virtual
resource.
A
Yeah
that
that's
that's
one
way
of
of
describing
it
and
and
there's
there's
not
as
much
consistency
in
in
terms
of
mesh
and
and
how
meshes
are
represented,
but
so
I
don't
know
that.
There's
you
know
that
the
same
argument
that
we
can
have
a
a
standardized
representation
of
a
mesh
but
yeah
that
that's
that's
how
I
had
to
imagine
it.
So
if
we
go
down
to
this
attached
to
you,
you
basically
just
have
this
group
kind
name
and-
and
you
can
attach
to
an
arbitrary
kind
of
parent.
A
That's
that's
all
that
may
or
may
not
make
sense,
but
I
I
think
it
gives
a
little
bit
more
flexibility
than
the
current
relationship,
which
has
this
type
it
has.
It
has
a
clear
requirement
that
the
parent
of
a
route
has
to
be
a
gateway
which
I
think
we're
moving
further
and
further
away
from
so
as
part
of
v1
alpha
2.
I
think
we
need
to
disconnect
from
that
at
a
minimum,
and
we
need
to
say
that
a
route
can
be
parented
by
something
that
is
in
the
gateway.
E
Hey
rob
so
I
did
a
quick
scan
of
this
and
I
think
the
semantics
of
this
are
not
super
clear
to
me.
So
if
a
route
does
an
attach
to
say
if
you
have
a
gateway
and
the
gateway
doesn't
specify
any
selectors
in
its
it's
listeners,
it
has
a
listener,
but
the
listeners
don't
have
any
selectors.
And
then
you
have
a
route
which
doesn't
attach
to
to
the
gateway.
B
Okay,
so
my
understanding
rob,
if
I
can
so
just
to
see
if
I
check
if
I've
read
this
right,
is
that
I
think
that
currently
it's
that
if
it's
in
the
same
name
space
it
works.
If
it's
across
name
spaces,
you
need,
you
need
the
the
binding.
Is
that
right
rob
or
is
it.
A
A
So
if
the
gateway
trust
routes
from
the
same
name,
space
and
the
route
attaches
to
it,
you're
great,
where
you
get
that
kind
of
room
for
confusion,
is
if
a
route
attaches
to
a
gateway
in
another
namespace
and
that
gateway
has
not
allowed
connections
from
routes
in
that
namespace.
That's
that's.
I
think,
where
you're,
where
we
enter,
that,
that's
that
space
for
potential
confusion.
A
What
I
like
about
this
approach
is
that
it's
very
clear
that
intent
was
broken,
but
so
right
now
we
have
these
kind
of
broad
selectors
right,
so
a
gateway
selects
all
routes.
Labeled
foo
in
you
know
these
three
name
spaces
and
some
app
owner
in
another
namespace
creates
another
route,
labeled
foo
and
they're,
not
selected
by
that
gateway,
and
they
may
not.
You
know
it's
not
clear.
Were
they
trying
to
attach
to
that
gateway
or
not?
F
E
A
I
would
almost
say
that
and-
and
I
think
I
should
actually
call
that
out
more
for
sure,
but
I
I've
seen
numerous
examples
of
users
already
using
the
api
this
way,
so
you
can
use
the
api
this
way
in
the
sense
that
your
route
selector
selects
everything
default
and
your
and
you
just
use
the
from
list
for
the
route
gateways
thing
in
route
so
like
this
functionality
is,
is
very
possible
right
now
and
already
used.
A
So
it's
more
a
question
of
how,
but
but
right
I
should.
I
should
absolutely
clarify
that
I
don't
go.
E
A
A
That
was
absolutely
the
intent,
and
then
we
saw
how
people
were
using
it,
and
it
was
not
that
I
mean
I'm
sure
in
some
cases
it
was,
but
in
some
cases
this
this
was
like
a
core
use
case
of
I
want
to
list
the
gateways
that
I
want
to
attach
to,
and
this
is
a
way
to
do
it.
You
know,
if
you
say,
gateway,
selects
everything,
then
your
your
routes
are
the
ones
that
control
what
they
attach
to.
E
E
Have
that-
and
I
guess
with
that
new
perspective-
I
know
nicole
nick
will
add
some
color
here
to
me,
but
I
remember
from
con
from
contour
days
there
were
lots
of
people
every
now
and
then
people
would
want
to
get
away
from
the
restrictions
of
http
proxy
inclusion
and
so
the
way
contour
works
is
you
have
a
top
level
which
then
specifies
what
the
next
like?
What
the
next
level
is.
So
they
wanted
to
break
that
top-down
coupling,
and
I
think
this
would
let
this
would
generally.
E
Let
them
do
that,
but
I
guess
the
cost
is
the
other
people
who
who
want
to
who
want
the
opposite
direction.
B
Yeah,
so
I
think
I
think
that
yeah,
the
thing
that
we've
got
that
we've
had
on
contour
is
that
people
contour,
is
a
very
strict.
The
the
sort
of
the
top
level
http
proxy
specifies
the
exact
http
proxies
to
include,
and
then
each
one
of
those
does
the
same.
So
it's
a
top
down
only
hierarchy
and
what
people
wanted
to
be
able
to
do
is
they
wanted
to
be
able
to
say?
E
Yeah-
and
I
think
this
also
addresses
the-
I
think-
the
need
that
the
estio
folks,
john
howard,
had
where
they
want
to
attach
their
existing
virtual
host
resource
type
as
well
as
the
you
know
that
gateway
resource
http
route
resource
types
they
want
to
be
able
to.
So
they
want
to
be
able
to
attach
multiple
resource
types
to
the
same
listener,
and
you
could
do
that
with
this
change.
E
B
Yeah,
so
I
think
I
think
the
thing
that
I
like
about
this
one,
sorry
rob.
I
know
you
want
to
talk
and
I'll
keep
talking
over.
You
is
the
thing
I
like
about
this
one
is
that
one
of
the
things
that
rob
has
done
here
is
he's
actually
kind
of
folded.
The
same
idea.
We
have
with
reference
policy
into
the
gateway
struct
so
like
that
the
gateway
does
the
same
thing
that
the
reference
policy
does
for
other
objects.
B
It's
the
thing
that
says
you
know
only
only
attachments
from
this
set
of
namespaces
and
this
kind
of
thing
come
are
valid
and
you
I
think
that
the
exact
way
we
should
define
that
is
pretty
important.
I
haven't.
I
can't
remember,
rob
exactly
how
you've
defined
that,
but
I
think
that
you
know
as
long
as
we
specify
as
long
as
the
exact
behavior
is
very
specific.
B
It's
fine,
like
you
know,
one
of
the
things
that
I
was
wondering
about
was
whether
people
might
want
sort
of
more
open
defaults
like
you,
if
you
don't
specify
a
kind,
it's
all
kinds
that
sort
of
thing,
but
I
think
that
one
of
the
things
that
the
cross,
the
stuff
we've
found
in
doing
in
looking
across
namespace
references,
is
that
a
lot
of
this
stuff,
like
you're,
better
off
like
in
terms
of
security
for
your
overall
cluster,
especially
in
a
multi-tenant
context,
you're
better
off
trading
off
wordiness
in
the
the
actual
object
for
clarity
and
explicit
config,
rather
than
having
implicit
things
in
there.
A
No,
that
that's
that's
great
summary
and
yeah.
I
agree,
and
I
know
I
know
I
said
I
was
gonna
time
box
this,
so
I
I
think
this
has
been
really
good
discussion.
It
I'll
try
I'll
make
sure
to
update
this
gap
soon
with
that
with
that
feedback
in
mind,
one
thing
that
I'm
realizing
I
haven't
explained
well
in
this.
In
this
gap,
I
I
don't
think
I
have
is
kind
of
my
fundamental
frustration
with
label
selection
in
that
it
it's
really
it's
not
a
security
mechanism,
and
it
it's.
A
You
know
when
you're
talking
about
crossing
namespace
boundaries,
it's
again
the
route
the
app
owner
had
all
the
control
in
the
world.
Anyways
the
app
owner
saw
that
you
know,
routes
of
label
foo
were
selected,
they
just
labeled
their
route,
foo
and
they're.
Now
attached
to
that
gateway
like
the
idea
that
selection
was
happening
from
gateway
to
route,
although
that's
what
we
documented,
it
still
required
the
route
owner
to
label
their
app
in
a
specific
way.
So
so
again,
the
route
owner
was
the
one
with
control.
A
So
the
selection
mechanism,
in
my
mind,
was
something
that
added
more
confusion
and
no
no
security
at
all.
So
I
would
rather
remove
it
and
and
describe
what's
actually
happening
very
explicit,
so
yeah,
that's.
That
was
my
thought
here.
B
Yeah
100
agree,
I
think
harry
put
a
thing
in
the
chat
saying
something
like
selectors
are
useless
for
security.
I
agree.
I
think
that
selectors
give
the
illusion
like
make
you
feel
like.
Maybe
there
might
be
some
security,
but
because,
because
of
the
issues
around
the
labor
label
ownership
being
the
same
as
object
ownership,
it's
not
it's
not
a
good
idea
to
base
any
securities
on
locals
yeah
exactly.
A
Cool
all
right
well,
this
is
this-
has
been
really
good
feedback.
I'll
make
a
note
to
update
this
and
I'll
ping.
Everyone
when
I,
when
I
have
an
update
out
but
yeah
thanks
the
next
step
I
wanted
to
cover
here
real
quick.
This
is
this
is
one
that
I
want
to
be
clear
is
what
I
would
say:
optional
nice
to
have,
but
not
required
for
v1
alpha
2..
I,
my
motivation
for
this
is,
is
purely
just
had
some
internal
feature
requests
for
this.
It
seemed
somewhat
straightforward.
A
I
I
recognize
that
we
may
not
get
it
in
but
wanted
to
spend
just
a
bit
of
time
discussing
it
today,
and
then
we
can
move
to
triage
and
looks
like
around
12
minutes.
This
is
really
not
trying
to
be
a
complete,
get
a
complete
enhancement.
It's
not
trying
to
cover
the
entirety
of
redirects
and
rewrites,
but
it
is
trying
to
expand
them
just
slightly.
A
So
what
you
can?
What
you
may
see
already
is
that
harry
already
added
host
redirect
host
and
protocol
and
port
redirects
correct
me
if
I'm
wrong
here.
I
think
those
are
the
the
main
concepts
that
are
already
checked
in
yeah
and
what
I'm
proposing
here
is
expanding,
that
to
include
path
redirects
and
then
we
have
no
support
at
all
for
rewrites,
so
adding
some
concept
of
rewrites
and-
and
these
concepts
seem
similar
enough-
that
they
could
be
merged
into
a
single
cap.
I
get,
but.
D
A
Free
to
correct
me,
I'm
happy
to
split
this
out
whatever
the
the
main
idea
here
is
yeah,
again
path,
redirects
and
the
most
simple
form
of
path
rewrites
that
could
be
portable
and
do
it
all
in
a
way
that
we
can
build
on
this
and
add
more
advanced
rewrite
and
redirect
capabilities
looks
like
I
got
an
extra
redirect
in
there
cool
so
just
like
redirects
with
that
said,
I'm
proposing,
starting
with
just
plain
path:
redirects
path,
prefix
and
redirects,
and
rewrites
and
host
rewrites.
A
I
spent
some
time
running
through
a
few
apis
here.
Looking
at
envoy,
gcp,
aj
proxy
nginx
feel
free
to
add
other
implementations
out
there
just
to
see
what
was
possible
and
my
understanding
my
translation
of
looking
at
these.
What
I
saw
was
most
portable
was
the
idea
of
a
prefix
rewrite
or
redirect,
and
so
that's
that's
what
I
proposed
to
start
with,
and
I
wanted
to
propose
it
in
such
a
way
that
it
was
hopefully
portable
and
easy
to
extend
in
the
future.
A
But
with
that
I
see
a
hand
nick
go
ahead.
B
So
I,
like
the
look
of
it,
I'm
just
having
a
quick
look
through
now.
The
thing
that
I
think
is
important
to
keep
in
mind
is
that
there
is
a
very
strong
interaction
with
if
we
do
include
a
route
inclusion.
B
What
happens
when
you
stack
a
re
prefix
rewrite
on
an
included
route
is
the
so
if
you
have
a
route
that
has
a
prefix
rewrite,
and
then
you
have
another
route
that
has
a
prefix
rewrite,
that's
included
into
the
other
route
like
how
do
the?
How
do
the
features
interact
for
http
proxy?
We
we
had
a
very
specific
defined
way
of
doing
this,
and
that
was
the
the
include
the
including
route
sort
of
wrapped
you
sort
of.
When
you
included
a
route,
you
got
the
prefix
on
any.
B
If
you,
if
you're,
rewriting
or
adding
a
prefix
to
the
route,
you
got
those,
but
that's
not
the
only
way
to
do
it.
But
the
key
thing
here
is
from
that.
I'm
trying
to
point
out
is
that
there's
a
very
strong
interaction
between
messing
with
the
route
and
route
inclusion.
C
Rob
I
have
to
look
at
this.
There
is
a
interesting
implementation
difference.
I
don't
know
if
people
remember
apache,
but
the
rewrite
actually
rewrote
the
request
and
re-injected
it
versus
just
rewriting
it
when
you
send
it
upstream
that
I
thought
was
the
significant
difficulty,
but
I
don't
know
if
no
one's
implementing
this
for
apache
so
and
I
forget
how
engine
x
behaves.
A
Yeah
there's
a
variety
of
there's.
Definitely
nuance
here
I
and
and
good
feedback
from
nick
as
well
about
route
inclusion.
I
had
not.
I
had
not
thought
about
the
the
overlap
there,
but
definitely
significant,
and
I
I
would
imagine
any
kind
of
rewrite
on
two
levels
is
going
to
be
very
complicated
to
do.
Well,
I
yeah
I'll
have
to
think
about
that
a
little
bit
harry.
I
see
your
hand.
Let
me
let
me
get
to
you
too,
while
we're.
D
So
so
I
think
bowie
sort.
D
A
Yeah
they
they
are
different
filters.
I
am
proposing
so
yeah
to
clarify
I
I
do
have
the
concept
split
up
in
the
gap
itself,
so
redirect
all
I'm
suggesting
is
adding
actually
this
to
the
request
redirect
filter,
but
then,
because
the
structure
of
the
request,
rewrite
and
redirect
filter
are
so
similar,
I
included
them
in
the
same
gap
and
and
the
support
and
the
means
of
how
you
know
like
looking
at
envoy
anyway.
There's
there's
some
overlap
in
in
how
they're
actually
configured,
at
least
in
other
technologies,.
A
There's
a
path
redirect
that
that's
what
I'm
suggesting
adding
but
separate
from
that,
I'm
suggesting
a
request:
rewrite
filter.
Now
it
yeah
that
that
those-
so
I
I
maybe
I
should
not
have
combined
these
these
concepts
together,
but
the
the
structure
of
the
filters
will
be
very
similar.
That's
all
I'm
trying
to
communicate.
C
Right,
I
see
yeah
because
they
like
do
completely
different
things
right.
One
of
them
sends
a
response
back
the
other
one,
just
yeah.
A
So
right,
basically
yeah
yeah,
you're
you're,
correct
so
yeah.
What
what
so
looking
at
the
the
ones
that
I
so
okay.
So
as
an
example
where
it
got
into
a
little
bit
of
confusion,
is
that
if
you
look
at
envoy,
for
example,
they
have
a
configuration
like
prefix
rewrite
that
is
valid
for
either
redirects
or
forwarding
same
with
regex
and
variety.
So,
like
there's
just
a
little
bit
of
overlap.
A
Most
other
providers
have
separated
these
out
and
like-
and
this
is
still
like-
you
can
rewrite
in
the
context
of
a
redirect-
is
how
envoy
allows
configuration
and
any
people
most
people
are
better
at
envoy
than
myself
so
feel
free
to
correct
me
on
this,
but
that's
my
understanding
of
the
reference
doc,
but
you're
right
these.
These
are
separate
concepts.
I
just
seemed
similar
enough
in
terms
of
how
they'd
be
configured,
but
I'm
I'm
happy
to
split
this
out.
B
Yeah,
I
was
about
to
say
the
same
thing:
the
if
you
have
the
yeah
like
then
then
the
order
of
the
filters
really
matters,
because
if
you
rewrite
and
then
redirect,
then
you're
gonna
end
up
with
a
different
result.
If
you
redirecting
is
a
terminating
option,
there's
a
terminating
filter
right,
like
you,
can't
have
another
rewrite
afterwards.
A
Yeah,
I
I
have
considered
and
this
this
is
again
the
lowest
common
denominator
thing,
but
I
have
proposed
that
these
filters
would
be
unique.
Would
you
could
not
use
a
re
redirect
and
rewrite
filter
on
the
same
path
on
this
on
the
same
route?
Rule
sorry
that
may
be
too
limited?
I
don't
know
I
just
there
were
some
providers
and
I'll
have
to
look
back
through
the
the
list
here,
but
I
think
some
did
not
support
both
at
the
same
time.
B
I
feel
like
we
could
probably
lift
something
like
again.
This
is
this
is
an
onboard
thing.
I
don't
know
how
other
proxies
do
it,
but
in
a
few
of
them
always
ways
in
which
you
can
specify
a
list
of
filters.
Some
filters
are
marked
as
terminating
filters
and
some
filters
are
not
terminating
filters,
and
so
a
terminating
filter
is
the
last
filter
in
the
list
and
if
you
put
anything
after
turning
filter,
it
doesn't
do
anything
in.
B
C
B
Yeah
yeah
so
yeah,
so
that
I
I
I
think
that
that's
that's
just
good
language
to
use,
because
it's
then
you
know
like
it
means.
B
I
think
that
we've
already
talked
a
little
bit
about
the
ordering
of
filters
that
you
know
it's
a
list.
It's
implicitly
ordered
you
know,
that's
important,
and
then
you
know
making
the
having
a
way
to
say
this.
This
is
a
terminating
filter
would
be
seems
to
me
to
be
makes
sense.
A
Okay,
well,
I
know
we're
what
about
jeff
actually.
H
The
only
thing
I
was
gonna
say
is:
I
actually
agree
that
you're
putting
both
of
these
into
the
same
gap-
they
are
so
close,
and
you
know
they
think
the
format
should
be
you
know,
keeping
them
in
the
same
gap,
keep
trying
to
be
consistent
in
the
format
between
them
and
they're
such
closely
related.
It
doesn't
make
sense
to
separate
them
out
so.
C
A
I'll
keep
this
together.
It
sounds
like
there's,
there's
still
a
number
of
questions
to
be
answered
on
this
one,
so
I'll
try
and
come
back
through
here
with
a
bit
more
detail
as
far
as
how
these
interact,
I
I
I
would
come
back
to
the
at
what
I
said
at
the
start
too,
that
this
is.
This
is
a
nice
to
have
feature
for
v1
alpha
2,
but
is
it's.
D
C
D
A
Exclusive
to
each
other
yeah,
this
may
not
be
used
at
the
same
time.
So
that's
what
I'm
going
with
right
now.
I
recognize
that
that
is
not
required
for
all
implementations.
There
are
some
that
can
support
both
rewrites
and
redirects
at
the
same
time,
that
would,
you
know
imply
that
they
understood
ordering
and
that
rewrite
should
occur
before
redirect,
etc.
A
So
maybe
this
is
a
limitation
we
can
remove
or
but
but
then
that
removes
some
level
of
portability.
D
A
Yeah
or
if
you
or
if
you
change
the
host
header
at
the
same
time
as
a
as
you,
have
a
rewrite
host
which
yeah
there
are,
there
are
some
weird
interactions
possible
between
those
two.
D
D
A
That's
fair,
okay!
Well,
yeah!
This
is
really
good
feedback
on
this
one.
I
will
try
to
update
this
pr
as
well,
but
I
you
know
as
much
as
I'd
love
to
have
it
in
it
is
purely
additive.
It
is
something
we
can
add
after
v1
alpha
2,
and
it
will
be
fine,
so
I'll
keep
this
one
updated.
But
if
you
are
in
between
looking
at
this
pr
and
another
pr,
I'd
recommend
a
pr
that
has
a
breaking
change.
A
Like
the
previous
gap,
we
looked
at
so
cool
with
that
I
promised
to
leave
some
time
for
issue
and
pr
triage.
There's
been
a
lot
of
discussion
on
a
variety
of
issues
and
prs.
I
let
me
let
me
just
highlight
a
couple
prs
before
I
get
into
issues.
I
think
there's
more
larger
issue,
larger
discussions
on
issues.
A
It
is
to
implement
method
matching
this
actually
originally
came
from
a
kubernetes
upstream
feature,
request,
redirected
them
here
saying
this
is
probably
a
better
way
to
add
this
feature.
We
had
a
tracking
issue
on
this
and
it
has
turned
into
an
actual
pr,
which
is
great,
there's
been
some
good
discussion
and
review
on
it.
I
think
we're
getting
fairly
close
here,
but
I
just
wanted
to
give
this
opportunity
if
anyone
has
a
strong
feeling
about
this
one.
This
is
a
great
one
to
talk
about
now
or
add
comments
on
the
pr.
A
This
is
one
that
is
not
going.
I
don't
think
it's
large
enough
to
deserve
a
gap,
but
I
just
want
to
make
sure
we
have
some
time
to
discuss
it
here,
because
it
is
rather
significant
and
that's
adding
fields
to
the
api
or
a
field
to
the
api.
D
A
Yeah
yeah,
that's
that's
a
good
one,
and,
and-
and
there
are
you
know,
this
is
really
just
a
convenience
method.
If
we
already
have
header
matching
and
well
again
depends
on
the
implementation,
but
for
implementations
that
support
those
pseudo
headers
like
the
colon
method
yeah.
That
would
be
their
way
to
do
custom
method
matching
unless
I'm,
unless
I'm
missing
anything.
A
H
F
Well,
it's
a
real
thing
in
http
2.,
it's
not
really
a
real
thing
in
http
1,
I
think,
but
like
you
could
implement
it.
Of
course,
yeah
like
there's
no
literal.
F
Header
in
http1,
but
if
someone
put
that
as
a
header
match,
then
you
know
you
could
say.
Oh
this
is
method
and
I'm
going
to
convert
that
to
a
method
match,
because
my
implementation,
you
know,
doesn't
have
a
method,
pseudo
header
or
something
like
you
can
still
implement
it.
Even
if
you
don't
have
your
proxy
doesn't
read
these.
F
C
A
Yeah,
I
wasn't
so
on
that
note
harry
that
that's
that's
a
good
question.
I
was
originally
thinking
this
should
be
extended
support,
but
then
I
looked
at
header
matching
and
I
rec.
I
realized
that
we
consider
header
matching
core
support.
A
So
if
we
consider
header-
and
I
know
it's
not
a
complete
overlap
like
not
everyone's
going
to
support
pseudo
headers
like
this-
so
I
don't
know-
I
don't
know
what
the
appropriate
support
level
is
on
this.
D
A
A
A
few
other
things
I
want
to
highlight
in
terms
of
prs
here
I
have
a
few
implementation
prs
of
existing
gaps.
One
of
them
is
removing
back-end
policy.
Then
you
know
the
rest
of
the
policy
attachment
gap.
If
anyone
has
extra
cycles,
there
are
gaps
and
notably
the
reference
policy
gap
that
has
merged,
and
it's
really
just
you
know
all
the
spec
is
out
there
and
it
just
needs
to
be
translated
into
an
actual
pr.
A
So
those
may
not
be
too
bad
to
implement
if
you're
looking
for
a
way
to
contribute.
I,
if
anyone
wants
to
volunteer,
I
would
love
it,
but
but
no
worries
on
that
one.
So
just
just
ping
me
or
assign
yourself
probably
best
would
be
to
assign
yourself
to
a
gap
issue.
If
you
want
to
actually
implement
it.
A
Yeah,
while
I'm
at
well
I'm
looking
through
the
prs,
are
there
any
other
ones
that
we
should
highlight
here.
A
Oh
yes,
you're
right!
Thank
you
all
right!
So
let
let's
remember
what
the
a
one
line
change
a
significant
one,
so
yeah
that
suggesting
that
a
tls
route
was
a
valid
route
when
tls
mode
is
and
there's
a
variety
of
conversation.
I
have
not
followed
this
as
closely
as
I
should
have
john
and
harry
and
james.
Anyone
want
to
summarize
this
discussion.
F
F
So
some
concerns
with
this
is
that
it's
kind
of
changing
the
semantics
where
before-
and
I
will
say
this-
is
my
my
concerns
that
I'm
summarizing-
we
kind
of
had
three
protocols
involved.
One
was
the
downstream
protocol
which
is
clearly
defined
by
the
listener
protocol,
and
then
we
have
the
upstream
protocol,
which
is
clearly
defined
by
apple
protocol.
I
think
those
are
not
controversial,
but
what
we
have
today
kind
of
is
this
route
type,
which
is
defining
the
protocol.
F
F
But
if
we
look
at
something
like
http,
then
it
gets
a
bit
confusing.
So
if
you
scroll
down
like
two
lines,
because
I
forget
what
I
what
I
said
here-
yeah
so
like-
if
we
wanted
to
do
something
like
terminate
https
traffic
and
then
match
on
some
http
property
and
the
s-
and
I
then
we're
in
like
this
weird
state,
where
we're
trying
to
do
tls
matching
and
http
matching
together
and
so
do
we
use
a
tls
route.
But
then
we
can't
do
http.
F
It
gets
very
confusing
and
it
seems
like
if
we
just
do
this
change
without
also
addressing
http,
and
we
somehow
have
more
functionality
for
tcp
than
http,
which
seems
a
bit
backwards
since
http
is
normally
the
the
core
use
case.
So
overall,
I
find
it
somewhat
confusing
to
do
this,
especially
when
you
consider
http.
D
Like
like
with
http
route,
we
could
be
terminating
http,
we
terminate
http
at
the
proxy
or
the
implementation
and
and
then
we
use
http
route.
In
that
case,
the
listener
protocol
and
the
route
type
is
same,
and
in
this
case
that's
the
same
thing
here,
we're
terminating
tls
at
the
gateway
and
then
we're
doing
some
matching
based
on
tls
metadata,
so
so
in.
In
that
regard,
it's
the
same
thing.
D
The
only
way
if,
if
you
do
not
like
this
was
intended
like
when
initially
dls
route
was
created,
this
was
supported.
So
this
was.
This
is
really
a
fix
for
that.
But
let's
say
if
we
do
not
add
this
feature
in
and
the
only
way
a
user
can
do,
tls
termination
and
then
do
routing
based
on
sni
would
be
via
gateway
listeners.
E
E
Was
my
impression
as
well
like
I
thought
my
understanding
was
like
this
has
always
been
how
it
works
and
that
so
I
kind
of
agree
with
john
in
that
there's
a
little
bit
of
smearing
in
terms
of
you
know,
is
the
route
the
the
next
top
protocol,
or
is
it
just
the
matching
and
yeah?
It's
it?
Arguably
it's
a
little
bit
of
both,
but
I
think
it's
always
been
that
the
back
end
protocol
and
the
service
app
protocol
tells
you
whether
to
do
tls
to
the
next
hop.
C
F
F
And
it
obviously
meets
some
real
demands.
I
just
don't
feel
like
right
now,
there's
a
cohesive
story
with
http
and
there's
certainly
ways
that
it
could
be
addressed,
but
I
feel
like
we
should
address
them
before
we
do
this
personally.
B
So
what
you're
saying
john?
That
that
we
need
to
be
clear
in
the
case
of
like
using
a
http
route
that
whether
or
not
sni
can
be
used
as
a
discriminator.
F
F
Well,
maybe
I
don't
know
if
that's
been
solidified
yet,
but
I
think
I
think
that's.
B
That's
the
issue
here
is
that
we
haven't
we
have
so
I
mean
I
certainly
anticipated
that
that's
a
thing
you
could
do.
That's
how
contour
works
that
you
know.
If
you
specify
a
hostname
for
a
http
route,
then
that
is
also
expected
to
be
used
for
the
s
as
the
s
I
and
it
won't
match
unless
they
do
match.
But
we
do
have
an
issue
checking
in
harry
thanks,
but
yeah
so
yeah
to
ensure
that
smi
does
not
equal
host
name
harry,
like
is
that.
F
E
Yeah
though,
some
of
this
stuff,
like
some
of
this
stuff,
I
think
there's
things
you
could
match
on
but,
like
I'd,
be
hesitant
to
kind
of
expose
everything
I
mean.
Clearly,
we
could
match
on.
You
know,
sort
of
arbitrary
tls
properties,
but
is
there
really
a
use
case
for
like
sending
different
tls
versions
to
different
services,
or
in
that
case,
is
what
you
want
more
to
be
able
to
specify
constraints?
You
say:
well,
I
only
want
to
talk
to
you
on
tls,
1.2
or
2s.
B
1.3
yeah,
I
think
so
harry.
Can
you
just
clarify
with
the
that
issue
so
to
ensure
that
snide
does
not
equal
hostname
for
hd
appearance?
Is
that
right
or
yeah.
D
So
we
have,
we
have
discussed
that
I
think
nick
you
have
been
able
to
lead
that
conversation.
H
D
We
we
want
to
make
sure
that
users
cannot
like
you
know.
You
cannot
use
one
sni
and
then
to
establish
a
pls
session,
and
then
you
know,
use
another
host
name.
You
know
that's.
B
So
yeah,
so
I
think
john,
I
guess
the
thing
that
we
haven't
done
there
is
is
yeah,
so
I
think
it's
probably
the
conflicting
one
yeah.
So
if
you
don't
have
if
the
sni
does
not
match
the
host
header
for
a
http
route,
then
you're
doing
like
domain
fronting
and
if
you
do
anything
like
authentication
or
authorization
or
something
like
that
at
the
like
at
the
gateway
level,
then
you
can
use
the
domain
fronting
to
swing
around
those
things.
B
So
it's
a
security
problem,
so
I
think
in
general
we
should,
unless
people
really
know
what
they're
opting
into
most
of
the
time
you
don't
want
to
do,
domain
fronting
and
you
shouldn't.
We
shouldn't
allow
that,
unless
without
people
having
to
jump
through
significant
hoops
to
say
to
indicate
that
they
understand
the
security
risks.
F
Yeah,
I
mean
there's
other
cases
too,
where
it's
not
just
like
having
it
completely
different
domain.
But
you
have
say
s
and
I
match
on
anything
you
do
the
matching
and
the
routing
or
you
have
like
star.example.com,
but
your
routes,
food.example.com
yep.
I.
B
Don't
know,
yes,
I
think
I
think
it's
absolutely
worth
us
and
being
very
specific
about
for
a
http
route
match
like
for
for
a
listener
that
specifies
http
or
https
or
tls,
and
you
know
that
has
hpv
routes
behind
it
like
what
are
the
hostname
fields
do
and
and
what?
What?
What
are
you
allowed
to
do
and
how
do
wildcard
host
names
play
into
that,
because
that
is
you
know.
That
is
something
that
is
relevant.
Yeah.
C
C
B
Of
obscure,
that's
why
I
wanted
to
make
it
that
you
know
s9
and
hostname
have
to
match.
In
some
way
I
mean
we
could
use
the
same
label
matrix.
I
mean
like
wild
card
matching
semantics,
be
used
for
like
hostname
gateway
and
hostname
on
route
with
you
know
you
can
have
a
single
wildcard
label
as
the
first
label
and
some
other
stuff
like
that.
B
So
I
think
that,
like
one
of
us
just
needs
to
sit
down
and
write
down
what
those
rules
are
and
say:
okay,
this
is
the
rules
for
these
rules
apply
for
if
you're
doing,
tls
and
use
and
using
sni
for
routing,
then
then
it
has
to
match
in
this
way
yeah.
I
think
that
I
feel
like
there's.
Definitely
an
implicit
assumption
right
now
that
that,
if
you're
doing
it,
you
are
using
the
snr,
if
you're
terminating
https
for
a
http
route,
then
you
are
using
the
s9.
You
are
checking
the
si.
B
B
C
B
C
B
Yeah,
so
so
yeah
john,
I
guess
the
question
I
have
for
you
is,
is
if
we
clarified
those
rules
in
the
http
route,
sort
of
guidance
somewhere.
Do
you
feel
like
that?
Would
that
would
remove
some
of
the
fuzziness
around
the
sni
stuff?
For,
for
the
other
case,.
F
Yeah,
so
I
guess
if
we
only
have
sni
matching,
then
this
starts
to
make
more
sense,
because
then,
yes,
http,
is
just
a
skateboard,
because
you're
already
doing
the
s9
match,
implicitly
with
hostname,
so
that
that
makes
more
sense
there.
If
we
add
other
stuff,
which
I
agree,
seems
kind
of
obscure,
and
we
can
get
every
feature
request
in
the
world
in
easter.
Pretty
much
and
I've
never
heard
anyone
asked
to
match
on
the
tls
version
or
cipher
suites
or
anything
like
that.
So
I
don't
think
envoy
supports
it.
F
So
this
seems
like
there's
no
demand
from
anyone,
really
that
I've
heard
at
least
so.
It
seems
plausible
that
we'll
just
have
s,
and
I
one
thing
we
may
want
to
consider-
and
this
is
not
fleshed
out
idea,
but
we
have,
in
other
discussions,
talked
about
adding
hostname
to
tcp
route.
F
D
B
I
think
that
comes
back
to
the
thing
that
I
put
in
the
in
the
channel,
though,
that
like
in
my
mind,
it's
kind
of
expected
that,
if
you're
doing
like
tcp
route
kind
of
implies
like
a
poor,
deport
like
you,
40
like
you're,
not
inspecting
the
traffic
you're,
just
taking
what's
in
the
port,
just
go
straight
to
the
to
the
back
end
to
the
back
end
service,
and
your
only
discriminator
is
like
port
and
other
like
layer,
3,
slash,
layer,
4
stuff,
but
then
tls
route
allows
you
to
use
tls
stuff
as
a
disc
as
a
routing
discriminator.
F
E
F
Your
tcp
route,
sure
yeah,
if
you
in
that
diagram,
I
had
with
the
three
protocols
I
think
I
may
have
been
misunderstood,
but
the
way
I
saw
it
was
kind
of
that.
The
middle
protocol
is
what
is
the
route,
and
that
is
the
protocol
after
a
tls
termination,
if
any
so
like
in
the
tls
case
in
that
would
be
a
tcp
route
because
it
would
be
terminated
to
tls,
and
then
I
guess,
if
we
added
hostname
there,
then
the
hostname
would
control
sni.
E
C
Yeah,
like
it's
not
like
it's
not
like
standard
protocol
processing
where
you
just
kind
of
toss,
the
previous
one,
because
inside
that
green
box,
actually
it
has.
It
knows
more
than
just
like.
Let's
say
you
were
running
some
tls
termination
thing
and
then
it
handed
it
off
to
you
like
there's.
Actually,
some
coupling
between
the
two.
H
E
Yeah-
and
I
guess
one
question
I
have
which
we're
way
over
time,
but
if
we
add
hostname,
if
we
had
hostname
to
tcp
route,
do
we
even
need
tls
route
at
all
because,
like.
D
B
You,
maybe
maybe
it's
http,
maybe
it's
not
maybe
you're
40,
maybe
you're
terminating,
but
the
thing
that
is
the
the
thing
that
you
are
allowing
the
input,
the
controller
that
implements
the
gateway
to
have
to
multiplex
multiple
tls
routes
into
a
single
port.
At
the
end
of
the
day
for
a
tcp
route,
it
implies
that
you
can't
multiplex
tcp
routes
onto
a
port,
there's
no
way
in
which
you
can
tc.
B
Like
you
can
multiplex
tcp
or
outside
report,
or
possibly
aside
from
source
ip
from,
like
you
know,
other
things
in
the
tuple,
but
you
can't
do
it
on
destination
information,
because
there's
not
enough
metadata
available
to
a
tcp
or
udp
route
connection
and
I
think,
adding
the
hostname
and
then
into
tcp
route
and
udp
right
as
james
says
it.
It
obviates
the
need
for
tls
right,
like
there's
no
discriminator.
B
You
know,
and
and
in
my
mind
that's
what
that's
why
I
posted
that
thing
in
the
channel
was
like
in
my
mind.
Those
are
the
differences
between
the
different
things
is
what
is
used
as
the
routing
discriminator.
B
If
you
are
sharing,
if
you
are
sharing
having
multiple
routes
specified
in
the
thing,
yes
and
we
are
super
overtime,
but
I
think
this
one
is
definitely
worth
talking
more
about,
because
it's
pretty
fundamental
to
the
to
what
the
what
each
object
is
for,
and
that's
one
of
the
things
that
we
really
need
to
be
more
specific
about
is
what
is
each
one
of
these
objects
for
what
is
the
intended
usage
of
this
object
and
that
that
should
be
like
top
of
the
top
of
the
dock?
A
Yeah-
and
this
is
this
is
a
really
good
discussion.
I
I
do
want
to
time
box
this
because
we
are
way
over
time,
but
I
I
think
conversation
in
chat
too
about
from
bowie
about
you,
know
tcp
and
udp
route
and
hostnames,
and
where
that
discussion
is
because
we've
had
that
discussion.
Thank
you.
A
Everyone
who's
been
involved
there,
but
we
haven't
had
that
discussion
in
the
context
of
what
we're
what
you've
been
saying,
what
everyone's
been
saying
now
of
the
the
overlap
between
tls
route
and
tcp
route,
if
host
names
were
to
filter
down
there,
and
this
is
exactly
the
kind
of
conversation
we
should
be
prioritizing
with
v1
alpha
2
around
the
corner,
because
we
don't
want
to
ship
something
like
the
v1
alpha
2.
If
we
don't
want
it
to
exist
beyond
v1
alpha
2..
A
So
if
there's
any
thought
that
we
should,
you
know,
include
tls
functionality
in
tcp
route
and
drop
tls
route.
We
should
explore
that
fully
now
so
yeah
I
I
I
don't
have
a
strong
opinion
on
this
and
I
think
great
points
have
been
raised,
but
I
think
we
should
continue
this
discussion
either
on
this
issue
or
on
the
originating
issue
for
this
discussion,
which
was
actually
a
pr.
So
maybe
we
should
continue
this
discussion
on
727,
since
this
feels
a
bit
closer.
C
A
A
Okay,
well,
thank
you
so
much
for
staying
longer.
Today.
This
is
great
discussion.
I
encourage
everyone
to
continue
and
follow
up
on
this.
Let's
aim
for
continuing
discussion
on
727
and
we
can
go
from
there,
but
thanks
everyone.