►
From YouTube: Service APIs Meeting (APAC Friendly Time) 20200423
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
B
B
Tls
configuration
to
be,
at
least
in
terms
of
the
schema,
because
I
think,
given
all
of
the
past
conversations
I
just
want
to
sort
of
lock
that
in
at
least
for
this
initial
draft
and
then
based
on
that,
we
can
see
who
who
would
want
to
sort
of
work
out
the
details
and
that
the
other
one
was
to
discuss
moving
traffic
split
into
HTTP
route
as
well.
So
those
are
the
two
things
that
we
heard
about
yesterday.
B
How
does
that
sound?
Does
anyone
have
well
to
start
off
with?
Does
anyone
have
any
burning
issues
that
they
would
like
discussed
as
well?
We
can
do
about
ten
minutes
of
just
going
over
the
PRS
and
the
issues
maybe
rub,
and
if
people
have
a
particular
thing
that
they
want
to
kind
of
raise,
that
would
be
good
Rob.
Do
you
mind,
sharing
the
agenda
doc
and
don't
you
okay?
Thank
you.
I.
C
A
I
should
highlight
that
a
number
of
PRS
have
been
merged
in
the
last
week,
so
that's
exciting
I
can
go
through.
We
have
less
PRS
right
now
that
are
actually
needing
review.
It
looks
like
something
that
maybe
the
verification
script
that
I
updated
in
test.
Impre
isn't
working
quite
right,
but
we
have
a
lot
of
verify
scripts
that
are
now
running
against
all
these
PRS
I.
A
E
It's
a
good
question:
that's
what
I'm
trying
to
understand
and
why
I
created
the
issue.
I
mean
if
we
go
to
http
route,
API
type,
let's
see
here
under
HTTP
route
match
see,
we've
got
a
path
type
and
a
path.
If
we
look
at
path,
type
core
supports,
exact
and
prefix
extended
supports
regular
expression
matching
so
and
then
we've
got
the
path
as
well,
and
now
we
have
the
header
type
and
header,
and
this,
let
me
give
me
a
second
role.
I
think.
F
B
B
B
B
D
A
B
A
Yeah
I
think
we've
covered
all
these
yesterday
now
so
I.
Don't
know
that
the
the
overwhelming
decision
here
was
that
it
makes
sense
for
Gateway
class
to
be
able
to
reference
parameters
inside
a
namespace
which
is
not
currently
the
case.
So
think
of
that
that
way
and
I
volunteer
to
take
that
one
off
I
think
the
rest
we've
already
covered
I,
don't
think
there's
any
new
poll
requests
per
se.
This
one
we've
had
lots
of
discussion
about.
G
So
I
was
reading
through
the
API
and
there
was
a
couple
of
error
conditions
which
were
noted
in
what
kind
of
implicit
in
the
way
that
listeners
work
so
I
added,
explicit
error,
condition
names
to
match
those.
So
hey
a
name
can
name
there's
syntactic
restrictions
on
what
you
can
name
a
listener,
which
implies
that
there's
a
invalid
name,
condition
and
listener
names
must
be
unique
within
a
gateway
which
implies
that
you
can
have
an
error
case,
which
is
a
name
conflict.
B
A
A
B
A
E
A
E
A
A
A
B
B
B
So
I
just
wanted
to
double-check.
That
is
the
case,
and
then
we
can
go
and
try
to,
and
then
this
it's
a
separate
discussion
about
how
to
handle
the
TLS
client
side
of
things
where,
if
you
had
a
proxy
that
terminated
and
then
you
had
to
originate
a
TLS
connection,
what
those
settings
were.
So
if
you
look
at
the
notes,
I
just
wanted
to
basically
come
back
to
that
for
now
again.
This
is
the
first
draft
we're
okay
with
putting
TLS
termination
settings
in
the
listener,
the
TLS
client
settings.
B
We
have
to
figure
out
where
that
lives
right
now,
there's
like
two
places.
Potentially
one
is.
We
say
that
will
be
something
on
service
and
then
sort
of
figure
out
how
to
do
it
on
service
or
somewhere
near
the
folder
to
towards
the
service,
or
maybe
some
parameter
there.
A
forward
to
reference
I
think
we
call
it
forward
to
reference
now.
We
do.
A
B
F
B
B
I
think
that
one
where
we
went
with
that
one
was
to
ask
the
question:
if
it
that
could
be
functionality,
that's
layered
on
top
of
this
API.
So
let's
say
that
they,
let's
say
like
you,
enable
let's
encrypt
on
your
gateway
and
it's
watching
a
gateway
and
all
the
routes
underneath
and
using.
Let's
encrypt
like
right
now.
Actually,
that's
how
please
correct
me
if
I'm
wrong,
because
I
haven't
used
this
directly,
that's
basically
how
the
cert
manager
works.
Is
that
watches
in
the
ingress?
B
It
watches
all
the
domain
names
associated
with
that
ingress
and
then
it
goes
and
fetches
it
does
like
the
magic
to
to
fetch
the
certs
and
and
attach
them
like.
You
could
think
of
similar
automation.
If
you
wanted
to
have
a
more
self-service
model,
but
it
would
be
like
someone
will
have
to
set
that
up
sort
of
on
the
side
and
not
necessarily
bake
it
into
like
re
the
this
API
layer.
A
Yeah,
the
thinking
at
the
time
was
as
if
I
remember,
the
discussion
just
to
build
on
that
is
that
well
we
imagined
that
most
application
developers
who
wanted
TLS
on
our
app
and
didn't
have
access
to
configure
a
gateway
directly
were
likely,
not
users
that
would
be
providing
or
generating
their
own
certs.
They
would
be
using
some
level
of
automation
to
do
that
already
and
if
a
controller
could
then
just
be
aware
of
this
API
and
connect
the
dots
for
them.
That
seems
like
the
ideal
use
case.
E
A
B
F
So
they
do
create
an
ingress
resource
to
complete
the
challenge.
So
you
should
he
be
challenged,
but
they
don't
don't.
They
did
any
existing
one
and
then
so
they
create
an
ingress
resource
or
the
proxy
source.
The
challenge
and
they
get
the
certificate
from
the
commit
provider,
create
a
new
so
to
create
an
existing
secret
or
I,
mean
replays
the
existing
secret
and
then
delete
the
ingress
resource
to
use
to
complete
the
challenge.
That's
the
flow
they
use
for
the
HTTP
challenge
and.
F
G
B
Right,
so
you
could
use
that
if
you,
if
you
had
an
empty
secret,
initially
the
application
developer
attached
it
issues
the
challenge,
that's
definitely
something
that
we
should
work
out,
especially
in
coordination
with
the
search
manager.
Folks,
just
to
see
like
what,
in
terms
of
the
API,
we
would
want
to
specifically
specify
how
it
behaves
to
make
that
flow
to
potentially
work.
B
A
I
feel
like
we
either
responded
to
an
issue
or
added
some
documentation
covering
this,
but
yeah
I
mean
I.
Don't
you
know
I
know
there
are
other
other
potential
implementations
of
TLS
automated
TLS
provisioning,
but
it
would
be.
It
would
be
very
helpful
to
at
least
understand
that
if
something
like
cert
manager
could
make
sense
of
our
API
or
there's
a
real
big
get
up.
Yeah.
B
B
H
A
B
Think
we
have
an
overarching
issue
because
it's
it's
like
end
of
them:
Danny
just
update
your
PRS,
so
it
pops
up
to
the
top.
The
I
think
the
thing
that,
if
we
can,
we
can
all
look
at
this
and
try
to
figure
out
what
what
we
can
support
in
the
core.
That
would
be
good
because
TLS
has
like
a
zillion
options
and
we
probably
want
to
have
some
smallish
stuff
to
begin
with.
B
G
D
B
That's
the
certificate
lists
of
references,
commands,
objects,
use,
container
identity
certificates,
bout,
the
listener
host
name
and
the
TLS
S&I
hello
message
is
used
for
certificate
matching.
Okay,
server
name
must
match
a
router
host
name
bout.
If
the
entry
empty
string,
yeah
just
defaults,
the
secrets
they
support,
resource
define
and
for
for
in
cannot
defend.
Okay,
so
you're
saying
that
the
server
name
must
match
me.
B
B
G
B
B
B
B
B
The
second
one
is
potentially
a
reference
to
a
managed
certificate,
and
the
third
piece
is
how
we
pick
bind,
which
one
because
I
know
there
was
discussion
like
you-
might
have
a
big
bundle,
but
you
only
pick
out
particular
sni
sort
of
sands.
I
guess
that
you
want
to
match,
and
then
the
fourth
one
is
for
the
pass
through
whether
or
not
this
one
is
Val
makes
sense.
Probably
it's
just
ignored,
so
those
are
like
the
four
things
I
think.
B
E
B
B
I'll
give
a
example
is
that
a
lot
of
the
cloud
providers
have
a
way
to
basically
generate
a
certificate
for
you,
but
you
can
only
attach
it
by
name
and
then
they
actually
keep
all
the
bits
so
like
it
never
leaves
the
trusted
cloud
so
forth.
So
you,
don't
you
can't
you
can't
leave
the
secret
or
you
can't
accidentally
misplaced,
the
secret
and
that's
that's
sort
of,
in
contrast
to
storing
it
inside
kubernetes,
which
I
know
some
people
aren't
super
keen
on
storing
it
inside
kubernetes
secrets,
for
various
reasons.
B
B
B
F
B
So
it
depends
on
the
controller
like
there
is
some
negotiation
that
the
controller
will
be
able
to
support
to
understand
that
it's
it's
not
the
other
kubernetes
secrets,
but
it's
not
that
we
forced
everyone
to
use
kubernetes
secrets,
because
in
some
cases,
for
example,
these
kind
of
like
in
the
cloud
or
in
the
device
kind
of
secrets
like
you,
can't
actually
get
the
thing
out.
So
you
can't
put
it
in
a
cup
a
nice
secret
anyways.
F
B
B
G
G
So
I
we
did
say
we
in
the
last
release
of
contour.
We
had
sni
binding
because
we
realized
we
didn't
have
it
and
we
also
added
TLS
client
auth,
and
if
you
have
TLS
client
off,
then
you
really
want
to
have
s
ni
binding
as
well.
You
can't
you
don't
really
want
to
have
you
really
want
to
make
that
client
off
guarantee.
B
G
B
It's
not
that
a
can't.
We
just
treat
that
as
basically
I
have
to
think
through
whether
or
not
it
feels
like.
We
should
just
add
it
as
a
validation.
Is
that
your
gateway
and
routes
and
certificates
set
form
a
the
Gateway
is
a
subset
of
the
no
wait.
The
Gateway
is
a
superset
of
those
route
hosts
so
that
it
can
terminate.
Is
that
sufficient.
G
B
Right
it,
it
doesn't
so
the
the
thing
that
you
can
I
sort
of
guarantee
from
the
config,
if
we
wanted
to
make
it
like
a
explicit
like
this
is
invalid,
is
to
say
that
if
you
terminate
a
set
of
certificates
with
some
set
of
names,
that
you
cannot
have
a
route
that
appears
that
is
outside
of
that
set.
So
therefore,
but
it
doesn't
preclude
someone
from
terminating
on
one
of
the
valid
names
and
then
adding
a
host
header
to
go
to
a
different
one.
F
The
same
thing
like
is
it
something
that
we
need
to
like,
probably
standardize,
but
it
shouldn't
be
reflected
in
in
the
API
itself,
like
if
it's
a
behavior
that
we
should
maybe
do
some
compartments
testing
on
and,
like
you
know,
like
the
proxy,
should
do
that.
But
it's
not
something
that's
defined
inside
the
API
like
we
can
have
dogs
around
it,
but
not
happening
and
yeah.
G
I
think
I'd
be
I'd,
be
happier
if
it
if
it
was
a
conformance
requirement
and
we
could,
and
that
mean
implementations
of
the
spec
behaved
in
a
predictable
way.
I
think
that
would
be
I
feel
pretty
comfortable
with
that.
I
think
my
my
concern
is
that
we
I
don't
want
to
kind
of
push
this
decision,
and
this
I
don't
want
to
push
this
off
on
to
end
users
to
have
to
understand
all
these
fine-grain
manipulations
in
order
to
get
the
thing.
That's
the
99,
the
same
case
yeah.
B
G
F
B
B
G
B
We
yeah
I
think
you
filed
an
issue
for
this.
It
might
be.
Maybe
we
dig
it
up.
It'd
be
great.
If
we,
if
people
who
know
the
implementations,
the
best
can
kind
of
point
foot
pointers
to
like
how
to
do
it
for
each
one
and
then
we
can
kind
of
see,
you
know
how,
whether
or
not
we
want
to
make
this
a
requirement.
G
G
B
B
H
We
don't
we
don't
make
sure
yet,
but
we
are
we
do
some
ham
I
mean
using
a
thing
like
you
choose
a
certificate,
but
if
you
I
mean
it's
dirty,
there's
no
certificate
of
matches.
We
were
using
a
t4
certificate,
so
you
can
specify
a
mutable
certificate.
Part
of
the
Ben,
sir,
and
the
way
we
all
choose
the
best
match.
Based
on
your
host
header
I,
see
oh
yeah.
G
B
Okay,
so
yeah,
please
comment
on
here
as
to
like
what
kind
of
behaviors
are
going
to
be
feasible
and
then
we
can
kind
of
see
where
it
stands.
I
would
love
to
have
it
and
be
more
secure.
I
just
need
to
make
sure
it's
we're
not
requiring
something
that
is
gonna
be
hard
to
get.
But
hopefully
you
know
in
a
few
months
maybe
they'll
change.