►
From YouTube: SIG Network Gateway API meeting for 20230612
Description
SIG Network Gateway API meeting for 20230612
A
All
right
welcome
to
the
Gateway
API
meeting
for
June
12
2023,
thanks
to
everyone
for
making
it
out.
We've
got
a
fairly
light
agenda
today
so,
as
always
feel
free
to
go
ahead
and
add
anything
you
can
think
of
to
this
agenda.
If
there's
something
that
we've
been
missing
out
on
or
that
we
really
should
be
talking
out
at
these
meetings,
please
don't
hesitate
to
add
it
to
the
agenda
if
somebody
could
be
so
kind
as
to
drop
a
link
to
the
agenda
and
in
chat
here
in
the
meeting
chat.
A
That
would
be
really
helpful
for
anyone
who
can't
see
it
and
before
I
go
any
further.
I'll
just
remind
everyone.
This
is
a
kubernetes
community
meeting,
which
means
we
are
governed
by
the
kubernetes
code
of
conduct
in
general.
That
just
means
be
nice
to
each
other.
I,
don't
think.
We've
ever
had
an
issue
with
that
here,
but
yeah.
Just
please.
Everyone
be
nice
and
just
as
a
way
to
make
sure
everyone
has
a
chance
to
speak.
A
If
you
can
use
the
raise
hand,
feature
that
helps
make
sure
that
we
get
to
everyone
who
who
does
want
to
say
something
yeah,
that's
all!
That's
all
for
the
intro
here,
let's
Jump
Right
In,
and
let's
talk
about
next
week's
meeting
for
many
in
the
U.S
at
next
week.
A
week
from
today
will
be
a
holiday
and
at
least
for
Shaymin
myself.
That
means
we're
going
to
be
out
of
office,
so
we
are
looking
at
a
different
time
for
our
meeting.
A
Usually
what
we
do
is
we
just
say:
well,
maybe
we'll
try
out
a
earlier
meeting
time
slot
on
Tuesday
this
week.
Gamma
is
already
in
that
earlier
meeting
time
slot.
So
what
we're
thinking
is
we
may
want
to
combine
meetings,
so
that
means
that
gamma
is
already
scheduled
to
meet
8
A.M
Pacific
on
Tuesday.
Their
meeting
agendas
have
had
room
to
spare
recently,
so
I
think
we
can
probably
fit
in
some
broader
Gateway
API
content.
At
the
same
time,
I
chatted
a
little
bit
with
other
maintainers
and
I
think
this
will
work.
A
So
unless
there
are
any
issues,
we're
going
to
plan
to
use
the
gamma
meeting
next
week,
so
8
A.M,
Pacific,
11
Eastern
I,
forget
what
it
is
and
centrally
yes
yeah.
You
can
find
your
own
time
zone
but
that
yeah
that's
what
we're
planning
to
meet
so
yeah
camera
meeting
invite
link.
Everything
else
will
be
the
same,
but
yeah
we'd
love
to
see
you.
There
it'll
be
a
broad
agenda
and
cover
everything,
gamma
and
Gateway
API
yeah,
and
then
one
more
just
point
of
announcement
here.
A
If,
if
you
are
interested,
please
go
ahead
and
submit
something,
and
if
you
want
help
with
reviewing
a
proposal,
I'm
very
happy
to
help
with
that
or
if
you're
looking
to
be
partnered
up
with
someone
that
may
want
to
speak
on
something
similar,
especially
if
it's
related
to
Gateway
API,
it
might
be
able
to
help
out
there
too
I
know
of
a
couple
people
that
are
looking
around
for
somebody
or
something
to
to
present
with
so
yeah.
A
That's
all
yeah,
okay,
so
that's
the
announcements
for
today
any
comments
on
those
before
I
keep
on
moving.
A
Cool
all
right,
the
very
next
thing,
Shane
I
know
you
had
to
dial
in
so
I.
Don't
know
how
much
you
can
see
here,
but
I
added
this
thing
from
that
you
had
in
the
next
stop
thing
about
kind
of
the
tweaks
you'd
made
to
the
Gap
process.
I,
don't
know
if
you're,
in
a
place
where
you
can
talk
about
those
or
be
better.
For
me,
too,.
A
I
will
go
ahead
and
say:
I
will
do
that:
okay,
yeah
for
Shane's
having
some
technical
difficulties
with
computer
at
this
moment,
so
yeah
we'll
see
I
think
he'll
be
able
to
be
partially
online
for
this
meeting.
But
there's
there's
two
series
of
changes
to
the
get
process
that
I
think
are
worth
highlighting
here.
A
The
first
one
here
is
that
we're
adding
a
you
know
if,
if
the
word
experimental
didn't
already
provide
connotations
of
instability,
now
we're
adding
an
additional
term
here.
That's
probationary,
which
is
really
trying
to
communicate
that
whatever
is
here,
is
subject
to
Future
removal
and
changes,
breaking
changes
Etc
and
really
that
the
goal
here
and
Shane
can
probably
correct
me
somehow
or
Nick
and
Nick
or
Flynn.
A
A
variety
of
people
were
involved
in
these
changes,
but
we've
seen
with
some
some
gaps-
and
this
was
largely
inspired
by
policy
attachment
that
the
natural
state
of
gaps
is
once
they
get
merged,
especially
once
they
get
to
experimental
or
and
are
somehow
usable.
A
They
kind
of
just
sit
and
there's
not
anything
that
forces
us
to
come
back
through
and
look
and
revisit
and
decide.
Should
we
improve
this?
Should
we
remove
it,
you
know
what
what
should
we
do
here?
So
the
the
idea
of
a
probationary
period
is,
as
a
gap
is
graduating
to
experimental.
So
experimental
in
this
terminology
means
that
this
is
a
something
that's
actually
going
to
get
released.
It's
going
to
be
in
a
our
experimental
set
of
crds.
A
So
that's
a
pretty
significant
thing,
but
it's
it's
really
almost
mirroring
some
things
that
happen
in
Upstream
after
Upstream
kubernetes
kind
of
dealt
with
this
Perma
beta
State,
where
they
they've
also
tried
to
say.
Okay,
if
you
are
not
able
to
move
this
forward
within
X
number
of
releases,
we
need
to
just
roll
it
back.
We
can't
we
can't
have
things
stuck
in
this
intermediate
experimental
state
for
too
long,
and
that's
really
what
we're
trying
to
do
here.
A
This
is
what
you're
seeing
in
this
diff
is
that
this
is
not
intended
to
apply
to
any
existing
gaps,
we're
not
trying
to
change
the
process
or
what
people
signed
up
for
for
the
things
that
already
exist,
but
we
are
trying
to
avoid
this
kind
of
thing
for
future
gaps
going
forward
so
yeah.
That's
that's
a
high
level
idea
of
the
changes
that
we're
getting
in
here.
A
I,
don't
know
if
anyone
else
wants
to
jump
in
with
clarifications
questions
whatever,
but
yeah
open,
more
discussion.
B
Yeah
I
think
that
the
policy
attachment
was
a
good
example
here.
Where
not
only
did
the
did,
we
sort
of
have
a
process
problem
that
we're
fixing
here,
but
we
also
I
think
we
accidentally
gave
policy
attachment
a
slightly
more
status
than
it
should
have
got
early
on.
You
know,
in
that
we
had
another
document
that
sort
of
laid
out
the
details
about
policy
attachment
that
wasn't
clearly
marked
as
experimental
so
I
mean.
B
That's
a
lesson
learned
that
yeah
and
as
part
of
I'm
doing
it
working
on
an
update
to
the
boss,
attachment
docs
and
I'll
be
actually
stripping.
That
page
back
to
basically
just
say,
go
and
read:
go
and
read
the
Gap.
B
You
know
this
page
is
now
mostly
stale
but
yeah.
So
the
idea
here
is
that
yeah
stop
that
sort
of
thing
from
happening
again
and
to
learn
from
what's
Happening
Upstream
about
Perma
beta
and
you
know
Rob
knows
all
about
Ingress.
You
know
be
on
V1
being
sort
of
stuck
around
for
way
too
long,
and
we
just
we
don't
want
to
have
that
happen
again.
Having
an
apple
once
is
bad
enough.
A
Yeah
well
said
so
yeah
we
link
to
this
in
the
agenda
as
well.
So
if
you
have
any
questions,
don't
hesitate
this.
This
came
through
as
a
PR
from
Shane
I.
Think
a
few
people
reviewed
it
but
yeah.
A
This
is
just
really
again
trying
to
prevent
that
kind
of
state
of
Perma
beta
Perma
experimental,
it's
a
mouthful,
but
whatever
that
is,
and
also
you
know
what
we're
trying
to
do
is
ensure
that
this
API
you
know
is,
is
something
that
is
broadly
useful
for
both
implementers
and
users,
so
there's
as
minimal
churn
and
as
much
stability
as
possible.
A
So
we
want
to
you
know
if
if
something
doesn't
work,
we
want
to
recognize
it
as
soon
as
possible
and
pull
it,
and
if
something
like
that,
you
know,
ideally
we
don't
pull
it.
Ideally
everything
gets
through,
but
we
don't
want
things
to
accidentally
just
get
stuck
through
that.
Maybe
shouldn't
have
yeah
all
right.
So
that's
one
phase
of
the
changes
that
we've
proposed
here.
The
second
one
that
I'll
highlight
real
quickly,
is
an
emphasis
on
the
Gap
discussion
process.
A
Again,
this
is
just
trying
to
go
forward,
but
this
is
mirroring
what
happened
in
Upstream
as
well,
where
Upstream,
if
you're,
trying
to
file
a
kubernetes
enhancement,
one
of
the
things
that
they
ask
for
before
you
file
anything
is
please
make
sure
you
please
link
to
a
place
where
you've
discussed
this
before
and
got
an
agreement
that
it
should
proceed
with
a
cap
in
that
case,
but
in
this
case
we're
just
saying
again,
but
we're
really
just
asking
for
hey
before
before
we
go
any
further
here
before
you
start
out
a
gap
process,
because
we
know
that's
a
lot
of
work.
A
Please,
let's
have
a
discussion
first,
so
the
recommendation
that
Shane
added
is
to
have
a
discussion
like
have
a
created,
GitHub
discussion
for
that,
but
also,
hopefully
we
can
discuss
these
things
in
a
meeting
as
well
and
get
broad
Community
consensus
that
this
is
I.
Think
we
want
to
move
forward
with
or
not.
A
But
again,
it's
really
just
trying
to
understand
clearly
that
everyone
in
the
community
has
limited
bandwidth
and
we
want
to
focus
on
the
things
that
you
know
have
have
the
highest
level
of
interest
and
the
most
importance
to
the
overall
success
success
of
the
project.
A
So
this
is
this
is
something
that
was
already
slightly
documented,
but
not
as
obvious
as
it
could
have
been.
So
just
this
PR
just
tries
to
make
that
especially
clear
yeah,
any
any
comments
or
questions
on
either
one
of
those.
B
Yeah
I
think
the
the
it
is
important
to
note
that
the
discussion
thing
is
a
recommendation.
You
know
not
a
hard
requirement
if
you
really
need
to
write
like
you
need
to
write
a
big
doc
to
explain
your
thing,
then.
Probably
that's
definitely
something
we
need
to
talk
about
in
a
meeting
anyway.
But
the
idea
here
is
to
use
discussions
because
they're
much
easier
to
find
when
you're
searching.
If
you
search
on
GitHub,
then
you
then
it'll
be
easier
to
find
then
so
then
Google
doc
in
someone's
private
Google
account
somewhere.
B
So
yeah,
that's
that's.
The
main
reason
to
push
people
towards
good
local
stuff
was
just
to
make
it
easier
to
search
so
that
if
we
have
something
come
up
in
the
future,
then
we
know
that
the
discussion
is
going
to
stick
around
and
it
will
be
accessible
as
long
as
GitHub
is
so
forever
in
Tech
terms,
yeah.
A
You
know
initially
as
well
so
yeah
cool
I
will
keep
on
moving
then,
but
don't
hesitate
to
interrupt
me
at
any
point
throughout
the
next
one.
Here
is
HP
route.
Timeouts
I
I
had
just
one
question,
but
I,
don't
think
Frank
or
yeah
I.
Don't
think
he's
on
this
call.
But
one
of
my
questions
here
is
right.
Now
this
this
Gap
is
proposing
that
both
timeouts
are
extended.
Only
I
think
that's
okay,
but
it
does
kind
of
go
back
to
the
I
think
that
we
were
trying
to
avoid
and
Nick
worked
so
hard
to.
A
You
know,
try
and
outline
here.
You
know
we
wanted.
You
know
a
portable
concept
of
a
timeout
somewhere,
but
we've
gotten
some
feedback,
I.
Think
from
someone
on
nginx
side
that
request
timeout
was
not
supported
so
so
to
clarify
this
Gap
proposes
two
kinds
of
timeouts:
one
is
a
timeout
that
basically
is
the
entirety
of
a
request
somewhat
simplifying
there
and
then
the
other
is
a
timeout
that
covers
a
request
from
Gateway
to
back
end
like
an
individual
request,
and
there
could
be
multiple
if
there
are
retries
involved.
A
It
seems
like
both
of
these
need
to
be
extended,
but
I
just
wanted
to
have
just
revisit
this
a
little
bit
and
see
if
anyone
could
think
of
you
know
A
variation
of
this.
That
really
is
broadly
implementable,
because
I
would
love
to
have
at
least
one
kind
of
timeout.
That
is
core.
B
I
don't
know
yeah
I
gotta
admit
this.
This
is
one
of
the
reasons
why
I
had
lift
that
that
get
that
get
in
the
state
that
it
was
was
that
I
hadn't
had
a
chance
to
sit
down
and
sort
of
wash
all
the
time
out,
it's
against
one
another
and
try
and
find
the
the
one
or
two
that
would
actually
be
implementable.
B
I
think
the
request
timeout
was
the
one
that
I
thought
was
most
likely
to
be
implementable,
but
I'm,
not
kind
of
not
surprised
that
yeah
that
it's
not
exactly
the
the
thing
that
I
learned
building
those
diagrams
that
are
at
the
top
of
that
Gap
is
that
for
something
that
seems
so
simple
timeouts
are
shockingly
shockingly
difficult
to
to
yeah
to
make
a
common
across
implementations.
C
Sorry
I
think
there
was
discussion
of
an
overall
timeout
in
there
plus
a
discussion
of
breaking
down
the
time
overall
time
out
into
pieces
and
portions.
Could
we
go
with
an
overall
timeout.
A
Yeah
and
that's
yeah
exactly
and
that's
what
we
thought
or
hoped
that
would
be
that
the
you
know
what
I
think
Ian
here
is
called
a
request:
timeout
we
were
hoping
well.
Surely
this
is
generic
enough
that
it
can
be
broadly
implemented,
but
it
sounds
like
that
is
not
a
concept
that
is
easy
to
represent
or
possible
to
represent
an
nginx
so
that
my
my
understanding
of
nginx
config
is
that
you
know
you
get
little
chunks
that
you
can
configure
as
timeout,
but
not
one
end-to-end
thing.
B
You
yeah
yeah,
so
yeah
so
this,
so
the
the
request
time
out
as
it's
defined
in
the
Gap
at
the
moment,
is
the
time
from
when
the
request
sort
of
starts
for
a
given
value
of,
starts
to
to
win
the
responses
returned
and
the
request
is
finished
like
the
response
from
the
back
end
is
returned,
so
it
actually
includes
the
the
other.
B
Timeout
is
the
back
end
timeout,
which
is
the
time
that
it
takes
for
the
request
to
be
sent
to
the
back
end
and
the
back
end
to
respond
and
like
so
the
request
timeout
currently
includes
the
back
end
timeout.
B
The
problem
one
I
had
considered
earlier
is
all
Candice
doing
something
about
sort
of
saying,
yeah,
building
umbrellas
or
something
like
that.
But
you
because
everyone
starts
and
stops
their
timeouts
in
a
different
place.
It's
quite
difficult,
it's
surprisingly
difficult
to
find
a
spot
that
that
everyone
is
going
to
be
able
to
cover
all
right,
yeah.
D
Are
we
talking
about
time
to
First
Bite
in
order
to
see
if
the
back
end
is
not
responding
at
all
or
are
we
talking
no.
B
No
so
these
are,
these
are
we're
talking
about
timeouts
from
mostly
mostly
timeouts
from
the
roughly
from
the
client's
point
of
view
right
like
so.
The
point
of
this
is
to
be
able
to
have
some
sort
of
time
out
from
the
client's
point
of
view,
but
the
problem
is
that
exactly
where
that
timeout
starts
and
finishes
is
different,
it
costs
pretty
much
every
implementation,
so
the
request
timeout
is
intended
to
be.
B
You
know
the
timeout
from
when
the
you
know,
roughly
when
the
request
sort
of
is
finished
arriving
at
the
proxy
to
when
the
response
is
finished
returning
and
has
been
sent
back
to
fire
like
roughly.
But
the
problem
is
that
everybody
starts
and
stops
these
things.
It's
slightly
different
big
Summits,
like
kind
of
first
bite.
Some
are
you
know
when
the
headers
are
completed.
B
Somehow,
when
the
you
know,
when
the
full
incoming
request
is
completed,
and
then
you
others
finish
the
timeout
at
different
times
as
well
like
when
you've
sent
the
entire
request
to
the
back
end,
when
the
back
end
is
fully
returned
to
response
from
the
back
end
of
return,
just
the
headers,
you
know,
like
yeah,
there's
lots
of
different
places,
ways
you
can
slice
this
cake,
and
you
know
everyone
seems
to
have
opinions
and
do
it
differently.
D
B
A
client,
yeah
yeah,
so
I
mean
all
of
those.
All
of
those
have.
You
know
good
reasons
to
exist,
but
like
yeah.
This
is
this
is
one
of
the
reasons
why
I
I
hadn't
done
this
either
is
because
I
was
like.
Oh,
this
is
really
hard
and
I
need
a
lot
of
interpreters
to
go
and
do
this
washing
thing.
So
I
really
appreciate
Frank.
Putting
all
the
effort
into
building
this
I
think
we've
run
up
against
the
thing
that
I
was
worried.
B
So
I
guess
the
the
question
for
everyone
to
think
about-
and
this
is
particularly
important
for
people
who
are
maintainers
of
an
implementation-
is
for
you
for
the
maintenance
of
the
implementation
to
sort
of
come
on
here
and
have
a
look
at
the
definitions
and
say
you
know,
for
example,
my
implementation
uses
Envoy
we're
good
here.
Right,
like
you
know,
because
I'm
working
do
can
do
a
request
or
my
implementation
uses
nginx.
We
can't
or
my
implementation,
you
know,
uses
our
own
proxy
and
it
has
a
slightly
different.
B
B
So
yeah,
that's
these
so
I.
Basically,
I
spent
a
bunch
of
time
like
going
through.
You
know
exactly
where
the
timeouts
are
defined
and
sort
of
making
those
little
spans
on
the
on
the
diagrams
to
say
when
the
various
timeouts
cover
onward
has
pretty,
you
know
extensive
timeouts.
There
are
a
lot
of
timeouts
possible
to
configure.
If
it
keeps
going
down
rob
you
can
see.
There's
the.
B
There's
you
know
if
you
keep
going
down,
there's
like
proxy
and
a
bunch
of
other
implementations
see
I,
think
that
it's
you
I
think
we
had
talked
a
bit
about
request,
timeout
being
the
most
likely
candidate,
but
it
really
feels
like
you.
This
is
one
where
the
API
looks.
Fine,
there's
no
problems
with
that,
the
API
itself.
It's
like
we
need
to
decide.
B
A
Yeah
I
think
I
think
you're
hitting
at
one
of
the
you
know
fundamental
challenges.
This
API
is
going
to
have
more
and
more
as
we
have
more
implementations
and
more
variety
here
that
it's
going
to
be
hard
to
add
new
things
that
work
for
everyone
and
and
I
think
that
absolutely
has
to
be
the
goal.
A
But
you
know
basically,
from
my
my
perspective,
our
past
guidance
or
philosophy
has
been
if
we
have
a
path
for
at
least
half
of
implementations,
ideally
also
representing
more
than
one
underlying
data
plane
to
implement
something
that
is
that
meets
the
bar
for
extended
so
because
there's
at
least
some
portability
there,
but
we
really
do
want
to
get
to
what
Nick's,
describing
here
of
of
something
that
is,
is
portable
across
everything
and
with
timeouts
we're
finding
that
to
be
especially
challenging
so
yeah
I
think
it's
been
really
helpful.
A
My
understanding
is
the
idea
of
a
request.
Timeout
is
portable
across
at
least
AJ
proxy
and
Envoy,
maybe
others
but
I
I
would
really
appreciate
that
you
know
I,
think
I'll
call
out
nginx
specifically,
but
any
other
implementations
right
now
that
are
seeing
this
Gap
and
say
you
know,
there's
nothing
in
here
that
I
can
support.
If
you
can
help
us
find
something
that
you
could
support
and
ideally
others
could
support
too.
A
That
would
really
help
it's
hard
to
make
sense
of
all
the
variations
here,
but
you
know
yeah
and.
B
Also,
if
I
made
a
mistake,
if
I've
made
a
mistake
with
these
diagrams,
please
correct
me
like
this.
Was
me
just
sifting
through
the
documentation
and
doing
my
best
to
get
this
right.
It's
pretty
likely
that
I've
made
some
mistakes.
I've
I
haven't
got
a
lot
of
experience
at
operating
some
of
these
things
so
I.
If
they're
always
that
aren't
I
made
it
obvious,
then
yeah
like
I,
probably
miss
them.
A
B
To
those
you
can
have
an
update
to
those
to
the
docs
as
well,
we
can
probably
just
take
a
separate
PR
that
would
you
know
that
would
update
the
diagrams
and
then
this
PR
can
be
rebased
on
top.
A
Yeah
yeah,
so
good
discussion
here,
we'll
talk
some
more
about
this
I
I
think
that
the
Gap
that
has
been
proposed
is
in
the
process
of
moving
forward.
I.
Think
current
trajectory
is
that
it
will
move
forward,
but
please
you
know
if,
if
you
would
like
to
stop
it,
if
you
would
like
to
include
something
else
that
is
maybe
more
portable,
please
catch
it
soon.
A
A
Okay,
that's
that's
timeouts
great
discussion
there.
Thank
you!
Everyone
yeah!
Please,
please
follow
up
on
the
pr
and
or
you
know,
add
suggestions
clarify
our
existing
charts,
whatever,
whatever
you
can
do
to
help
us
move
forward
there.
C
Yes,
yes,
it
is
so
I
have
been
working
on
a
document
to
fill
out
a
API
implementation
for
this
Gap
and
bounced
it
off
of
Rob
and
Nick,
and
so
the
idea
is
that
there
will
be
an
object
which
is
actually
a
direct
policy
attachment
applied
to
service
which
will
represent
the
the
client
search
settings
used
in
the
TLs
handshake
from
the
gateway
to
the
back
end,
and
we've
been
talking
about
this
for
a
while,
but
this
is
something
that
has
a
little
bit
of
background
already
in
some
of
our
existing
gaps,
at
least
as
an
example
and
the
question
that
Rob
had
about
this.
C
C
But
there's
also
the
possibility
that
this
would
be
a
Gateway
admin
role
and
not
just
a
and
not
an
app
developer
role
and
there's
pluses
and
minuses
for
both
so
for
app
developer.
It
would
relieve
that
it
would.
It
would
make
it
so
that
the
Gateway
admin
wouldn't
have
to
administer
those
certs
update,
update
the
search,
update,
expired
certs
and
have
to
do
that
kind
of
configuration
on
behalf
of
the
application
developer
and
it
would
just
be
the
application
developers
rule.
C
On
the
other
hand,
as
Rob
pointed
out,
if
it
was
a
Gateway
admin
role,
there's
a
better
separation
of
concerns
in
in
terms
of
the
Gateway
admin.
Having
us
say
over,
which
certs
are
are
acceptable
for
the
Gateway
to
work
with
the
back
end
am
I
explaining
that
correctly
Rob
yeah.
A
A
And
so
we
have
this
idea
of
personas
in
the
API
and
we
have
infrastructure
provider,
cluster
operator,
app
developer
and
the
question
here
that
Candace
and
I
bring
up
is
just
when
you're
thinking
about
you
know
basically
ACA
cert
configuration
to
to
validate
the
certificates
served
by
your
back
end,
so
the
Gateway
is
doing
this
validation.
A
What
is
the
correct
Persona?
Who?
Who
is
the
person
that
we
would
expect
to
be
configuring
that
when
I've
seen
this
in
other
apis,
I've
kind
of
seen
a
mix
where
it's
you
know
closer
to
something
like
resembling,
a
Gateway
and
and
others
where
it's
closer
to
something
like
resembling
a
service
like
it's,
you
know
either
attached
on
one
side
or
the
other
and
I'm
not
really
sure
what
the
correct
Persona
is
here
either,
but
I
thought.
Maybe
you
know
opening
this
up
for
more
discussion,
be
helpful.
A
So
thank
you,
Candace
for
for
raising
this
question.
I
don't
have
an
answer,
but
I
I
would
love
some
additional
input.
B
C
I
could
go
either
way
and
would
defer
to
you
guys,
I.
We
don't
have
an
implementation
that
we're
working
on
where
we
have
an
integration
that
we
work
with.
It's
just
a
this
is
a
feature
that
we
need,
and
you
know
we
would
be
relying
on
the
best
way
for
the
implementers
to
handle
this,
but
also
you
know,
bearing
in
mind
that
there's
you
know
a
certain
operational
aspects
that
we
we
want
to.
C
We
just
don't
want
to
make
it
difficult
for
people
to
use
it
or
mistake
prone
to
use
it
as
well.
B
Okay,
well,
I
think
I
left
plenty
of
time,
so
I'm
going
to
have
a
crack.
So
my
feeling
here
is
that
the
first
thing
that
we
need
to
hit
is
the
application
developer.
Uk
use
case
having
the
cluster
admin
Gateway
owner
use
case
is
nice,
but
it's
not
as
important
as
the
application.
B
Having
that
meeting,
making
sure
that
we
meet
the
application,
developers
need
to
the
I
mean
the
reason
that
we're
putting
this
you
they
were
putting
this
close
to
the
service
and
making
it
a
matter
of
resource
is
because,
like
it's
kind
of
the
service,
really
should
be
owned
by
the
application
developer,
or
at
least
someone
doing
the
same
job,
and
so
as
part
of
the
service,
ideally
like
I
mean
the
best
situation,
for
this
would
be
that
we
would
put
this
into
service
right.
Like
the
you
know,
we.
B
Can't
do
that
because
making
changes
in
core
objects
is
it
takes
a
very
long
time
but
like
the
best
possible
design,
for
this
would
be
that
service
grows
a
thing
that
says
to
connect
to
this.
To
connect
on
this
port.
You
need
to
do
TLS
and
you
need
to
do
you
need
to
use
these
tailor
setups
right.
Like
you
see,
you
need
to
have
a
search
for
this
CA
or
you
know
you
need
to
trust,
CCA
or
yeah
and
a
bunch
of
other
stuff
like
that.
B
B
This
service
is
doing
TLS
and
you
should
use
TLS
to
talk
to
it.
You
know,
and
that
should
be
generally
the
application
of
primarily
the
application
developer's
concerned.
I
100
agree
that
there
are
lots
of
really
interesting
ways.
You
can
extend
this
default,
it
all
that
sort
of
stuff
that
you
know
there
is
more
stuff
that
the
Gateway
admin,
or
you
know
other
people
will
care
about.
B
You
know
which
TLS
versions,
all
that
sort
of
stuff,
but
like
the
the
main
use
case
that
we
need
to
get
here,
is
that
that
initial
one
that
we've
tried
to
make
this
sort
of
telescope
on,
and
so
that's,
why
I'm
kind
of
in
favor
of
leading
towards
the
application
developer.
One
first,
because
we've
tied
these
companies
down.
A
I
I
think
that
makes
sense
and
I
think
that
is
closer
to
what
I've
seen
elsewhere
as
as
priority
here
but
I
just
to
to
I,
guess:
State
P.
The
other
side
of
this
I
think
where
we're
starting
with
this
configuration
is
that
it's
primarily
just
validating
these
certs
that
are
served
by
the
back
end.
Nothing
else,
like
I,
I,
agree
that
what
you
know
there
are
other
things
like
Cypher,
Suites
or
other
things
that
could
be
in
scope
eventually,
but
right
now,
I
think,
what's
in
scope
is
just
you
want
to
validate.
A
The
Gateway
should
validate
that
the
certs
that
are
served
by
the
back
end
are
in
this.
You
know,
are
valid
right
using
the
ca,
I
guess
right
and
so
having
the
the
application
developer,
both
responsible
for
the
certificate
it's
serving,
as
well
as
the
configuration
for
how
to
validate
what
it's
doing
feels
like.
Maybe
not
the
right
separation
of
concerns,
but
I
I,
don't
know
I.
A
But
yeah
I
don't
want
to
don't
want
to
waste
too
much
time
on
this.
Thank
you.
Thank
you
for
raising
this
I
am
very,
very
excited
to
see
this
in
get
form
and
maybe
I'll
and
also
would
encourage
anyone
who
has
an
opinion
on
what
Persona.
This
belongs
to
to
to
comment
on
I
guess,
yeah.
C
A
Will
probably
turn
into
an
update
to
the
existing
Gap
fairly
soon,
and
we
can
we
can
comment
a
bit
more
there.
You
know
I
think
I
think
what
Candice
has
been
working
on
right
now
is.
Is
you
kind
of
a
policy,
and
so
a
policy
really
could
be
owned
by
either
Persona
I
think
a
policy.
The
joys
of
a
policy
is
a
little
bit
more
flexibility,
flexible,
which
Persona
you
grant
access
to,
so
that
may
kind
of
resolve
this
anyways
yeah
just
yeah.
A
Thank
you
a
million
times
over
Candace
for
taking
this
one
on
I
know
it's.
It's
been
a
rather
complicated
one,
two
to
get
through
yeah.
C
B
A
Cool
all
right,
yeah.
Well,
thank
you
and
I
think
that
brings
us
to
triage
yeah,
okay,
so
first
up
very
related
to
that
is
what
Candace
is
talking
about.
Is
there's
a
lot
of
things
that
are
kind
of
circulating
here
I,
but
this
is
client
search,
validation
from
client
to
Gateway,
so
as
opposed
to
what
Candace
was
just
talking
about
of
gateway
to
back
end.
A
A
So
this
is
also
a
really
helpful
time
to
try
and
gauge
interest
level
and
see
who
who
would
be
in
you
know,
interested
in
implementing
or
contributing
to
this
right
now,
he's
really
just
to
find
a
single
goal
and
non-goal
at
this
point
I
think
the
the
scope
of
this
is
fairly
small,
but
he's
really
just
looking
for
some
initial
feedback
yeah.
Just
maybe
quickly
does
it.
Anyone
on
this
call
interested
in
implementing
this
is
this
something
like
that.
The
customers
or
others
have
been
asking
for.
C
A
Cool
yeah
I
just
wanted
to
make
sure
this
one
doesn't
get
missed,
but
I
I
completely
understand
the
low
on
bandwidth
state
next
up
2108.
This
is
something
that
Leora
is
starting
to
work
on
which
I'm
excited
about
we've
been
talking
about
this
for
ages,
but
the
idea
is
in
Gateway
class
status.
A
We
want
to
be
able
to
start
extending
this
in
a
couple:
different
directions,
one
we
want
to
enable
users
to
to
very
clearly
see
what
features
and
implementation
supports.
This
has
been
talked
about
for
a
year
or
more
now,
and
then
two
very
related
to
that
yeah.
This
is
a
more
complicated
thing
to
do.
Can
we
provide
some
kind
of
clear
errors
when
a
user
tries
to
use
a
feature
that
is
not
supported
by
the
Gateway
class?
A
A
This
is
intended
to
be
a
discussion,
because
yeah
I
wanted
to
get
some
feedback
and
interest
level
again.
The
first
part
of
this
is
really
just
requiring
that
implementations
publish
something
like
in
Gateway
class
status
that
describes
the
the
set
of
features
they
support.
A
This
would
map
very
closely
to
the
conformance
test
features
that
already
exist.
So
if
you're
running
conformance
tests
and
know
the
set
of
features
that
you
already
support
based
on
those
that's
what
would
be
published
in
Gateway
class
status
and
ideally
that
would
also
be
how
you
would
run
conformance
tests
just
based
on
what
your
setting
in
Gateway
class
status
instead
of
studying
a
bunch
of
flags
or
supported
features
depending
on
how
you're
using
this
yeah.
A
So
this
is
just
another
FYI
feedback
and
discussion
welcome
here,
but
this
is
something
that
Leora
is
starting
to
work
towards
and
I'm,
seeing
something
in
chat
here,
yeah
somebody
open
to
help
with
2080.
That's
that's
great,
definitely
recommend
reaching
out
to
ARCO
on
this.
One
Arco
is
easy
to
to
find
on
slack,
but
don't
hesitate
to
Ping
anywhere
or
or
let
me
help
make
a
connection
if
that's
helpful
as
well.
A
Yeah
I
know
you
know
a
common
theme
of
all
these
meetings
is
that
we
have
so
many
things
we
want
to
do
and
so
little
time
to
do
them
so
yeah.
If,
if
you
have
some
bandwidth
opening
up
that
would
be
amazing.
I
would
love
to.
A
Yeah,
great,
okay
and
so
yeah.
That's
that's
just
coming
up
for
Gateway
class
status.
I'm
excited
about
this
one
and
if
you
have
any
requests-
or
you
know,
suggestions
for
how
this
should
be
done,
please
go
ahead
and
leave
them
here.
Otherwise,
I
think
Leo's,
Just,
Gonna,
Keep,
On,
Moving.
B
Yeah
I'm
gonna,
I'm
gonna
drop
some
stuff
on
there,
I
think,
but
the
the
TLD
offer
everyone
on
this
call
is
I
think
we
should
use
a
similar
if
not
the
same
format
as
the
current
conformance
profiles,
reporting
schema
and
just
put
that
straight
into
the
into
the
gateway
class.
As
for
the
features
reporting
so
so
that
you
have,
you
know
the
conformance
profile.
Reporting
schema
is
available
in
the
Gateway
class
at
all
times.
Basically,
I
think
that's
the
simplest
that
yeah.
That.
A
Actually
is
you're
right,
you're
right
and
that's
actually
pretty
brilliant.
There
are
some
things
in
there
that
I
had
not
thought
about,
but
conformance
profile
report
already
includes
things
like
Gateway
API
version.
That's
supported,
which
I
can
imagine
being
really
helpful
to
you
know
automatically
flag.
Hey
this
implementation
you're
using
is
behind
the
apis
you're
using
yeah.
That's
that's
a
really
good
idea,
yeah.
So.
B
Yeah
I'll
put
a
comment
on
there
to
that
effect
tomorrow
morning,
but
the
other
thing
was
Lewis
has
said
there
he's
planning
on
opening
up
another
one
which
was
on
my
to-do
list
as
well,
which
is
about
adding
a
gap
to
to
have
the
Gateway
class
status,
also
record,
all
of
the
implementation
specific
or
other
extended
extra
crds
that
the
implementation
users
that
has
come
up
a
bit
in
policy
attachment
in
that
it
would
be
nice
to
have
somewhere
to
know
some
way
to
know
what
your
implementation
is
using
and
what
you
should
look
for,
and
yeah
I
think.
A
Yeah
yeah,
I,
I'm
excited
so
I
think,
there's
a
lot
of
good
improvements
to
Gateway
class
status,
coming
down
the
pipeline
real,
soon
and
more
of
a
discussion
for
gamma
meeting
but
in
for
mesh
side
of
things,
but
we're
going
to
need
to
figure
out
how
to
represent
all
these
same
Concepts
at
a
mesh
level
where
Gateway
classes
so
far
not
present,
but
yeah
coming
soon,
hopefully
well.
Some
kind
of
solution
for
that.
B
A
All
right,
so
next
up
is
2111,
yeah,
TLS
termination
mode
for
TLS
routes.
This
came
in
just
before
the
meeting
and
I
figured.
It
would
be
worth
just
getting
a
few
more
eyes
on
it.
A
So
far
we
have
said
that
TL
TLS
route
is
reserved
for
pass
through
only
and
haven't
really
had
a
clear
use
case
for
why
you
would
use
TLS
route
for
anything
besides
pass
through,
but
this
is
actually
a
seems
like
a
reasonable
idea
of
somebody
who
has
a
custom
protocol
that
runs
on
top
of
TCP,
and
so
they
basically
want
to
at
this
at
this
level,
terminate
and
then
do
TCP
routing
after
the
fact.
Well,
no,
not
TCP
rap
handle
TCP
traffic
on
TCP,
routing
I.
A
Don't
know,
I
haven't
read
this
that
thoroughly
yet,
but
just
thought
it
was
an
interesting
idea
and
the
first
time
I'd
seen
a
request
like
this.
So
I
like
most
things,
it
would
be
very
helpful
to
you
to
gather
interest
on
this
and
see
just
how
widely
people
want
this
kind
of
feature.
A
We
do
need
to
have
some
kind
of
triage
and
prioritization,
because
it
just
is
not
enough
capacity
to
do
everything
right
now,
but
if
this
is
something
you
want
or
have
customers
that
want,
please
don't
hesitate
to
comment
on
here
and
help
us
triage
at
as
best
we
can.
A
Cool
and
finally,
the
last
thing
on
the
agenda
that
I
have
anyways
I
just
wanted
to
revisit
this
multi-cluster
mesh
discussion
real
quickly,
I
thought
that
Brian
added
a
really
good
comment
here,
and
this
is
something
that
we've
been
struggling
with
as
an
API
of
trying
to
find
the
right
balance
between
you
know,
trying
to
just
represent
the
concepts
that
already
exist
versus
leaving
room
for
new
things
and
new
ways
of
doing
things.
A
I
thought
this
was
a
a
good
comment
and
just
a
concept
that
I
care
a
lot
about
multi-cluster
and
its
intersection
with
Gateway
and,
in
this
case
gamma
so
again,
just
another
another
heads
up
that
if
this
is
something
that
you
care
about,
if
you're
invested
in
multi-cluster
and
and
Gateway
or
Gamma
or
I,
think
you
might
be
I'd
encourage
you
to
revisit
this
discussion
and
and
chime
in
with
your
own
thoughts,
yeah.
A
Okay,
so
that's
all!
That's
all
I've
got
for
today,
any
last
things
before
before
we
call
it
the
meeting.
A
Cool
all
right,
well
we're
going
to
see
everyone
a
little
bit
later
next
week,
so
we're
going
to
meet
on
Tuesday
at
8,
A.M,
Pacific
I'll
cancel
our
meeting
note
and
just
our
meeting
time
and
send
a
note
out
that
we're
using
the
gamma
meeting
for
everything
and
with
that
thanks
everyone
for
making
it
and
hopefully
we'll
see.
Many
of
you
next
week
have
a
good
one.