►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20220801
Description
SIG Network Gateway API Bi-Weekly Meeting for 20220801
A
All
right,
hey
everyone,
welcome
to
another
gateway,
bi
call.
I
know
we've
had
a
lot
of
these
recently.
So
thanks
to
everyone
for
showing
up
to
another
one,
I
I
think,
let's
start
off
with
that
jeff,
maybe
we
can
revisit
some
of
the
gap.
Discussion
here
for
route
delegation
sure
cool
yeah.
I
know
there's
been
a
lot
of
discussion
here.
I
don't
know,
do
you
do
you
have
a
summary
of,
or-
or
maybe
I
can
summarize-
I
don't
know-
yeah.
B
A
Yeah
sure
so
I
I
you
know
last
week
we
got
a
lot
of
feedback.
I
think
we
had
more
feedback
on
this
gap
than
any
other
gap
and
more
discussion
last
week
than
I
think
any
of
us
expected.
So
you
know
it
was
a
good
good
refresher
on
just
all
the
different
perspectives.
Here
I
took
some
time
over
the
past
week
to
reach
out
to
people
that,
had
you
know,
voice
concerns
or
hesitation
around
this
gap
to
try
and
understand
those
a
little
in
a
little
bit
more
detail.
A
I
added
a
comment
at
the
bottom
that
seemed
to
summarize
concerns
and
suggestions
and
whatever,
but
there's
a
lot
of
comments
on
here.
I'd
say
you
know,
of
the
100
plus
comments
on
the
skip
so
far,
there's
a
chunk
that
are
you
know.
Knits
like
this
is
a
good
example
of
a
of
a
knit
that
oh,
we
use
this
capitalization.
Instead
of
that
I'd
say
that's
a
good
chunk
of
them,
but
then
there
are
some
larger,
broader
themes
that
I
think
we
should
discuss
today.
A
If,
if
we
have
time,
I
and
I
may
miss
some
but
well,
let
me
let
me
jump
down
to
the
bottom
and
again,
if
I've
missed
something
important.
Please
please
let
me
know,
I
know
there's
a
lot
of
good
stuff
in
here,
but
I
tried
to
summarize
some
of
the
themes
here.
One
of
them
that
I
think
tony
toby
mentioned
here
is
is
kind
of
an
interesting
thing
that
that
others
may
have
mentioned
in
passing.
A
A
You
know,
I,
I
think
we
have
at
least
three
implementations
represented
on
this
call
that
have
implemented
delegation
in
some
form
and
it'd
be
interesting
to
hear
the
perspective
there.
But
my
understanding
so
far
is
that
it's
it's
generally
been
represented
as
the
same
resource.
Is
that
correct
not
saying
that
this
is
good
or
bad,
but
just
in
in
other
implementations,
so
far,.
B
C
A
And
is
it
also
the
same
kind
of
thing
where
you're
providing
a
subset
of
functionality?
When
you
have
delegation
involved.
D
D
You
know
or
the
or
contradictory
yeah
you
do
have
to
define
some
stuff
like
that,
but
I
mean
that
you're
gonna
have
to
do
that
anyway,
you
know
like
if
you
I,
if
you
allow
matching
on
path
conditions
for
for
like
inclusion
and
delegation,
then
you're
gonna
have
to
handle
like
what
happens.
If
the
path
conditions
are
contradictory.
D
Oh,
you
can
only
use
path
prefix,
because
using
a
regex
doesn't
work
because
you
know
how
do
you
validate
that
the
regexes
are
not
greedy
or
like
there's
a
bunch
of
other
stuff
like
that
right
like
that
stuff
is
going
to
be
the
same,
no
matter
what
I
think
like
it
probably
does
make
sense
a
bit
to
just
split
it
apart
than
a
market
yeah.
I
I
actually
think
that's
a
reasonably
compelling
argument,
but
yeah
I
don't.
B
Yeah,
I
think
one
of
the
things
we
talked
about
previously
as
a
as
a
challenge
and
which
kind
of
led
me
to
to
proposing
at
using
this.
The
the
same
object
type
was
the
the
challenge
of
keeping
things
in
sync.
So
you
know,
if
you
you
want
to
establish
some
initial
routing
parameters
at
that
parent
level
and
say
we,
we
made
some
type
of
additional
filter
option
available,
just
just
picking
something.
B
B
It's
a
big
opportunity
for
inconsistent
behavior
when
you
do
that,
so
I
I
looked
at
it
as
a
as
a
safer
approach
that
you
know
kind
of
have
one
one
set
of
logic:
that
does
your
validation
and
and
you
can't
that
way,
you
can't
the
verb
diverge
between
it.
A
Yeah,
I
think
that
makes
sense.
I
I
think
this
all
leads
and
that
actually
is
a
good
segue
into
one
of
the
themes
that
I
saw
throughout
the
comments,
and
that
is
a
lot
of
confusion
around
what
functionality
delegation
would
support
and-
and
specifically
so,
a
lot
of
the
comments
were
some
some
theme
of
is.
This
concept
is,
is
header
modification
header
matching
supported
on
both
levels?
A
What
happens
when
they
conflict
as
an
example
like
that
some
kind
of
comment
like
that-
and
I
think
that
is
kind
of
the
biggest
effort-
that's
remaining
with
route
delegation
here
and
something
that
we
need
to
answer
broadly
and
maybe
that
can
help
decide
if
this
should
be
the
same
resource
or
not
right.
If,
if
we
make
that
long
list
of
these
are
the
20
features
of
http
route,
I
don't
know
whatever
it
is,
and
these
are
the
five
features
that
delegation
supports.
A
D
Think
so,
travis
just
asked
a
question
in
the
chat
about
like.
Is
there
a
you
is
something
about
how
how
this
is?
How
do
you
preventations
handle
this?
I
think
the
thing
everyone
needs
to
to
keep
in
mind
here
is
that
this
is
actually.
This
actually
doesn't
have
very
much
to
do
with
the
implementation.
D
D
Stuff,
you
actually
need
to
worry
about,
like
that.
There
will
be
stuff,
you'll
need
to
do
in
the
implementation,
but
I
think
one
of
the
I
think
jeff
in
retrospect.
One
of
the
errors
we
actually
made
here
was,
I
think,
introducing
the
idea
of
the
ephemeral
round
has
been
very
confusing
for
people
like.
I
think
people
have
not
got
what
we
were
trying
to
say
there.
What
the.
D
Ground
is
intended
to
say
is
practically
when
you
are
taking
this
system
of
things
at
some
point,
you're
going
to
have
to
build
a
single
model
that
you
flush
down
to
your
config.
That's
all
the
ephemera
idea
is
right,
like
that.
You
have
to
take
all
of
these
things,
wash
them
against
each
other
and
end
up
with
a
single
config
that
you
push
to.
Whatever
is
actually
your
data
plan.
D
That's
it
right
like
that's
all
the
fm
router
is
trying
to
say
it's
not
trying
to
say
you
need
to
create
like
this
intermediate
kubernetes
resource
or
no.
No,
it's
just
trying
to
say
practically.
You've
got
to
build
this
thing
out.
By
being
like
here's
a
listener,
it's
got
a
round
attachment,
that's
got
a
round
attachment
or
you
collapse
effectively.
What
you're
doing
is
collapsing
the
config
down
into
the
listeners,
which
you
got
to
do
anyway,
when
you're
building
up
when
you're,
just
attaching
a
route
to
a
gateway
yeah.
Maybe
I
see
your.
B
You're
very
right
nick
I
mean
that's,
that's
exactly
what
the
concept
of
the
ephemeral
route
is.
It's
just
you
know
it's
just
taking
these
pieces
together
and
writing
them
out
as
one
single
route,
which
is
really
what
it
boils
down
to
so
to
to
me.
Strikes
me
fairly,
straightforward.
B
You
do
nothing.
So
no
decision
gets
me.
You
know
there's
no
decision
based
off
of
it,
so
I
most
things
feel
like
that
to
me.
D
A
D
D
D
D
A
D
A
subset,
then
you
say:
okay,
that
works
the
like,
and
I
don't
think.
D
That
difficult
to
write
down,
but
I
think
that,
as
I
said,
I
think
that
I
think
that
the
the
way
that
and
yeah
I
mean
I
read
this
whole
thing
before
and
it
made
perfect
sense
to
me
jeff.
So
I'm
not
like
throwing
stones
at
you
like
yeah.
I.
B
D
It
was
fine
before
but
like
reading.
Back
now,
after
having
people
comment
on
the
idea
of
the
ephemeral
route,
it
feels
like
we
may
have
strayed
too
much
towards
making
it
sound
like
the
ephemeral
right
was
like
an
implementation
requirement.
It's
like
it's
not
a
requirement.
It's
a
very
useful
way
to
think
about
it.
Right,
like
you
know
like
you.
What
what
would
happen
if
this
config
was
all
in
a
single
route
is
a
very
useful
question
to
ask
yourself
to
think
about
conflict
resolution,
but
it's.
B
F
Oh
thanks,
so
I
I
guess
where,
where
I
had
a
problem
with
ephemeral
route
is,
is
not
so
much
the
specifics
of
it,
but
just
that
it
needed
to
exist.
So
I
think
ephemeral
route
is
basically
you
know,
kind
of
trying
to
wallpaper
over
a
hole
in
the
wall
here,
which
is
that
what's
what
happened
here
is
that
we
basically
forked
http
route
and
said
okay.
F
And
so
and-
and
I
see
a
ephemeral
route-
is
an
attempt
to
kind
of
reconcile
those
two
things
to
say.
Well,
you
attach
the
parent,
you
attach
a
route
and
it's
a
parent,
but
it's
not
really
a
route
because
it's
a
parent
and
so
at
some
point
later.
This
other
thing
called
an
ephemeral
route
gets
created
and
it's
the
sum
of
a
parent
and
a
child.
But
then
it's
got
its
own
soul
in
a
sense,
and
so
so
that's
what?
F
Then
it
becomes
a
template
or
it
becomes
a
scope
or
it
becomes
a
range
or
something,
and
then
at
least
conceptually.
F
It
becomes
a
lot
easier
for
me
to
sort
of
think
about.
Okay,
when
this
happens,
I
you
know
when
you
create
an
http
route
template
you
don't
expect
to
get
route
behavior,
because
it's
a
different
thing.
Sorry,
but
then,
when
you
attach
what
we
called
a
child?
Okay,
now
I've
got
a
route.
So
I
get
routish
behavior.
B
So
I
think,
if
nick,
if
you
don't
mind
yeah,
you
got
that
so
I
think
the
the
the
challenge
there
is
that
the
at
least
from
you
know
based
off
of
the
conversations
we've
had
in
the
past
and
reflecting
what
I
know
from
my
customer
base.
Is
that
what
what
the
use
cases
that
we've
been
targeting
is
the
fact
where,
as
a
you
know,
maybe
a
cluster
administrator.
B
I
want
to
do
some
routing
decisions,
but
then
I
want
to
allow
a
subset
to
be
done
by
you
know
by
say
the
owners
of
the
name
space,
and
so
I'm
only
going
to
let
certain
traffic
even
get
to
them
by
finding
those
routing
rules
at
the
parent
and
they
can't
override
that
and
get
up
traffic.
They
shouldn't
get.
B
B
F
Okay,
so
yeah
that
that's
a
great
point,
because
so
maybe
I
don't
understand
the
intent
of
the
http
route,
because
my
my
naive
understanding
from
going
through
the
spec
once
or
twice
is
that
the
http
that
apparent
http
route
kind
of
has
no
reification,
there's
no
route
behavior
until
a
child
attaches
to
it.
And
so
at
that
point
it
sounds
like
what
you're
saying
is
that
you've
actually
got
two
routes.
So
you
have
the
picture
that
you're
trying
to
show,
which
is
at
the
point
that
a
child
attaches
now.
F
D
D
D
You're
gonna
have
to
create
something
that
looks
like
a
route
that
has
like
all
of
these
things
in
the
one
spot
and
then
that
at
that
point,
when
you're
doing
that
is,
when
you
do
the
checking
like
hey.
Does
this?
Does
this?
Does
this
extension?
That's
in
the
child
in
the
child,
one
makes
sense,
like
you
know,
is
there
a
contradictory
set
of
conditions
or
you
know?
F
D
This
in
order
to
be
able
to
apply
this
conflict
to
a
proxy
at
some
point.
So
but
the
thing
is
it's
not
that
the
h,
the
parent
http
route
does
nothing
right,
the
in
the
in
the
spec.
You
are
explicitly
allowed
in
it's
a
bit
confusing
because
you,
because,
because
of
the
words
that
we
have
to
use
right,
but
you're
explicitly
allowed
in.
C
D
In
the
in
that
parent
route,
as
you
see
here,
you're
allowed
to
match
on
things
and
have
those
go
somewhere.
What
we
saw
in
contour
was
a
lot
of
the
time
people
did
is.
You
would
use
this
for
like
a
big
for
your
main
company
website
right
so
you'll
have
your
default
routing
rule
in
your
parent
route,
for
the
main
company
website
will
be
like
a
will,
be
a
yeah
like
a
static.
D
Like
you
know,
it's
got
your
main
company
website,
it's
just
a
static
thing:
it
serves
a
lightning
fast
or
something,
and
then
you've
got
like
you've
got
here
like
slash,
store
and
slash.
Api
are
sort
of
carved
out
and
requests
to.
Those
are
then
forwarded
on
off
to
some
other
service,
and
so
like
that's
that's
the
pattern
that
we've
seen
people
actually
wanting
to
do
with
this
thing
is
that
you
want
to
take
a
single
url
space
and
sort
of
carve
it
up
and
give
bits
of
it
to
other
people.
D
But
in
order
to
be
able
to
do
that,
you
need
to
have
stuff
like
you
need
to
be
able
to
have
routing
happen
at
each
of
the
layers
and
that's
one
of
the
key
things
like
it's.
Not
we're
not
we're
not
doing
we're,
not
building
this
in
the
abstract
like
this
is
built
like,
but
jeff,
and
I
have
had
built
a
thing
like
this
before
that
we
have
been
addressing
extremely.
F
Right,
so,
to
take
your
example,
which
I
think
is
a
good
one-
you
have
a
sort
of
top
level
of
slash,
store,
yep,
right
and
that's
enforced
by
the
parent,
and
then
the
child
route
is
ultimately
slash,
store,
slash,
cart
and
that's
kind
of
another
problem
I
have
with
this
is
we're
creating
things
that
aren't
explicitly
created
by
users,
but
I
guess
the
thought
experiment
is:
what's
the
difference
between
stacking
the
two
things
on
top
of
one
another
and
just
requiring
that
the
child
can
only
implement
urls.
That
start
with
slash
store.
D
D
B
F
Well,
I
disagree
that
you
need
a
parent-child
relationship.
You
need
an
object
that
specifies
what
the
ranges
are
that
the
child
is
allowed
to
do
I
mean
we
have
other
examples
of
that
with
attachments,
and
you
you
know
so
you
could
just
say
if
if,
for
example,
the
parent
route
were
not
a
route,
but
it
were
a
constraint
object,
it
could
say,
reject
any
attempt
to
attach
if
the
url
doesn't
begin
with
slash
store.
A
Yeah-
and
I
I
think
that
is
along
the
lines
of
what
you
had
proposed-
of
a
of
a
different
object
that
acted
as
in
place
of
the
parent
route
here
right.
Something
like,
I
think
you
call
that
the
template,
but
but
some
some
resource,
and
I
think,
we've
just
been
calling
that
like
a
a
parent
concept,
but
whatever
that
resource
is,
it
sits
between
a
gateway
and
what
is
defined
here
as
a
child
route.
And
it
says
things
in
this:
namespace
can
only
attach
to
this
path,
or
this
prefix
path
is.
F
Right
so
I
mean,
I
think,
we're
sort
of
talking
about
two
approaches
to
the
same
thing
and
I
think
they're
roughly
comparable,
I
mean
one
is
basically
to
say
that
the
what
we're
calling
a
child
route
here
is
basically
just
a
route,
but
we
can
constrain
what
it's
allowed
to
look
like.
We
can
constrain
what
it's
allow.
You
know
what
urls
it's
allowed
to
do,
whether
it's
allowed
to
do
certain
things
or
not.
There
are,
basically,
you
could
imagine
a
sort
of
rbac
type
system
that
says.
Oh
you've
tried
to
do
something
that
you
know.
F
You've
tried
to
move
outside
of
a
url
scope
that
that
we
defined
for
you,
so
we're
not
going
to
let
you
attach
and
that
doesn't
require
a
parent-child
relationship.
It
just
requires
a
sort
of
rule
relationship.
You
know
rule-based
control
relationship
that
says
these
things
are
allowed
to
do
these,
and
these
other
things
are
allowed
to
do
something
else,
and
that
way
you
don't
get
the
sort
of
oh
well.
D
So
I
guess
so
it
seems
to
me
like
what
you're
proposing
is
that
you
have
some
resource
that
has
like
slash,
store,
slash,
api
and
any
other
constraints
that
you
want
to
put
out
and
says
for
this
for
this
domain
name,
these
things,
you
can
only
do
these
things
for
these
domain
names
and
if
you
want
to
hit
slash
store
like
you,
need
to
have
a
constraints
or
something.
But
how
do
you
associate
that
constraint
with
the
routes?
D
D
F
That
doesn't
violate
the
constraints
like
we
could
reference
the
route,
could
reference
a
set
of
constraints
or
it
could
not,
but
we
could
basically
say
the
gateway.
Has
this
set
of
constraints,
and
if
you
want
to
attach
a
route
to
this
gateway,
it
has
to
meet
all
of
the
constraints
that
were
specified
for
it.
A
I
think,
in
the
context
of
how
gateway
api
works
today,
but
just
the
the
resource
model
itself,
you
need
that
hierarchy
right
of
the
the
child
route.
The
route
at
the
very
bottom
of
this
tree
would
need
to
be
able
to
attach
to
something
that
that
delegation
thing
that
allows
that
to
happen,
and
then
that
delegation
thing
whatever
we
call
it
would
need
to
be
able
to
attach
to
the
gateway.
A
So
so
right
now
that's
called
a
parent
route
in
this
proposal,
but
I
think
we,
I
think,
what
you're
describing
is
still
something
that
fits
at
that
level
in
the
hierarchy
may
just
be
a
different
resource,
but
I
think.
A
F
D
I
think
that's
a
reasonable
objection,
but
I
think
that
the
the
reasons
that
we've
chosen
to
do
things
this
way
are
to
sort
of
meet
specific
problems
and
meet
specific
use
cases
right
and
that's
like
the
the.
So
there
was
the
user
sort
of
made
a
side
comment
before
about
how
you
don't
like
that,
the
the
you
know
there's
an
implied
prefix
when
you
import
a
route
into
like
when
the
child
attaches
to
the
parent.
That
is
literally,
that
is
the
solution
to
a
problem
that
we
had
within
contour
with
ingress
route.
D
So
in
ingress
right
was
our
earlier
attempt
at
doing
something
like
this,
where
you
could
delegate
things
and
what
happened
there
was
that
we
didn't
have
that
you
you,
you
could
have
any
prefix
you
liked
in
the
parent
routes
and
in
the
child
routes,
but
if
they
didn't
match
up,
then
it
didn't
work,
and
that
was
worse
because
it
meant
that
the
the
owner
of
the
eventual
thing
needed
to
know
all
of
the
possible
places
where
it
could
be
put.
D
One
of
the
advantages
of
doing
things
in
the
way
that
we're
doing
here
is
that
the
childhood
appearance
are
composable.
You
can
put
them
into
multiple,
you
can
put
them
into
multiple
parents
and
it'll
still
work.
You
know
like
the
as
long
as
I
mean
practically,
you
do
have
to
do
some
rewrite,
but
the
tools
are
there
for
you
to
do
the
rewrite
in
both
locations,
and
that's
the
I
guess
what
it
comes
down
to
is.
D
The
gamer
api
is
built
as
a
hierarchy
as
it
stands,
gateways
have
gateway,
classes,
gateway,
classes,
have
routes,
and
so
this
the
reason
that
this
made
sense
to
me
is
that
this
extends
the
hierarchy
by
one
level.
I
understand
what
you're
saying
that
it's
slightly
confusing
to
have
things
be
named
the
same
thing
that
have
different
behaviors
but
like
because
they
have
extremely
similar
behaviors
in
many
ways
you
know,
like
a
large
slab
of
the
behavior,
that
you
need
to
have
available
in
the
parent
route.
I.E.
D
The
routing
functionality
means
that,
if
you
make
this
a
template,
then
what
and
then
to
meet
the
rules.
The
requirements
where
you
want
to
be
able
to
have
like
a
default
routing
thing,
that's
owned
by
the
cluster
admin.
What
what
will
happen
then,
is
that
cluster
admin
will
need
to
own
like
a
template
and
then
a
route
right
like
you
know,
and
that
template
will
and
then
that
route
will
need
to
be
attached
to
the
template,
and
then
the
template
will
also
need
to
be
attached.
D
F
I
guess
I
mean
your
example,
I
think
is
good
in
the
sense
that
we
have
a
gateway
that
attaches
you
know,
and
then
there
are
a
variety
of
different
things
that
attach
to
the
gateway.
I
don't
think
there's
any
place
in
the
spec
where
a
thing
attaches
to
a
thing
of
its
own
kind,
except
for
this,
and
so
I
I
would
argue
that
the
template
approach
honors
the
current
design.
Far
more
than
saying
we
have
this
sort
of
kind
of
recursive
but
limited.
F
F
We
got
a
hierarchy,
but
it's
a
hierarchy
of
different
things
connecting
to
the
different
things
that
they're
allowed
to
connect
to
and
we're
inserting
this
sort
of
almost
circular
turtles,
all
the
way
down
thing,
but
except
that
we
have
a
rule
that
says
that
you
can't
have
turtles
all
the
way
down.
You
can
only
have
one
turtle
standing
on
another
turtle
and
then
you're
done
so
I'd
rather
have
an
explicit,
different
object
and
and
wedge
that
in
between
the
gateway
and
the
route
in
some
optional
cases,.
A
E
Yeah
I
had
some
thoughts
if
it's
still
relevant.
So
when
I
look
at
the
api
from
a
user
perspective,
I'm
thinking
I
have
a
route,
that's
logically
using
another
route
as
the
back
end,
I'm
thinking
logically,
this
route
is
forwarding
to
that
route,
and
I
realize
that's
not
the
way
it
really
works.
E
But
then
the
same
is
true:
if
you
have
a
route
with
a
service
as
a
back
and
it's
not
really
going
through
the
service
proxy
and
to
tony's
point
the
same
way,
you
can
have
a
route
that
you
configure.
This
is
a
parent
route
or
you're
thinking
of
it
as
a
parent
route
and
the
configuration
is
incomplete
until
you
have
the
child
route
attached
to
it.
The
same
is
true:
if
you
have
an
http
route
and
you
specify
a
service
and
say
the
service
doesn't
have
any
endpoints,
your
configuration
is
incomplete.
E
So
I
don't
think
there's
a
big
discrepancy
there,
but
I
mean
the
bottom
line.
Is
the
api
is
for
users
and
as
a
user?
Logically,
I'm
thinking
this
route.
My
my
example
route
is
sending
traffic.
You
know
if
it
matches
this
criterion.
That
goes
to
the
store
route,
or
if
it's
that
criterion,
it
goes
to
the
core
services
route,
which
then
has
a
service
backend.
E
So
that's
the
way
I
think,
about
route
delegation
and
having
a
route
with
a
route
as
a
back
end,
maybe
nick
or
rob
or
others
can
tell
me
why-
that
mental
model
is
wrong.
E
B
I
I
agree
with
that
statement.
I
I
think
I
think
some
way
I
kind
of
summarize.
Some
of
this
is
that
we
start
with
the
use
case.
What
is
it
that
we're
trying
to
address,
and
so
what
do
we
capabilities?
Do
we
need
at
each
by
each
entity
if
you
will
involved
in
that
use
case
right,
so
the
the
basics
is,
we've
got
a
we've
got
basically
a
cluster
administrators
or
a
global
administrator,
whatever
you
want
to
call
them
and
namespace
administrators
and
the
cluster.
B
I
mens
want
to
be
able
to
control
some
things
that
when
it
comes
to
routing
traffic
that
the
you
know
and
restrict
what
the
the
the
namespace
admins
can
do,
and
so,
if
you
look
at
it
that
way,
then
what
you
you,
the
cluster
admin,
may
want
to
do
the
exact
same
things
at
the
cluster
level
that
they
might
want
to
do.
B
If
you
didn't
have
child
routes,
so
I
may
want
to
insert
headers
I
may
want
to
do
marrying
and
such,
and
I
simply
don't
want
to
allow
the
namespace
admins
to
control
some
of
that.
B
So
that's
where
we
get
these
this
parent-child
relationship
and
it's
it
really
is
about
the
more
than
anything
it's
about
the
delegation
of
authority
and
who
controls
what
what
I've
seen
in
my
experience-
and
you
know-
nick's
talked
about
his-
what
I've
seen
is
having
it
the
config
model,
where
there
are
two
different
objects
like
a
template
at
the
parent
level,
and
you
keep
adding
functionality
to
that
parent-
and
you
know
it's
like
you
know
like
the
route
lets
me
do
this,
but
the
template
doesn't-
and
I
really
want
that.
B
So
you
add,
we
add
that
to
the
template
and
we
keep
doing
that
and
pretty
soon,
these
two
things
look
very,
very
similar
but
they're
not
quite
the
same,
and
so
they
each
have
just
a
little
bit
different
logic
and
the
validation
code.
It's
just
a
little
bit
different
and
it
gets
out
of
sync.
You
know,
there's
just
there's
it's
like
a
recipe
for
chaos
in
some
ways
and
for
a
user,
it's
very
it's
very
confusing
to
say:
okay,
if
I'm
defining
a
filter,
you
know
or
a
match
criteria.
C
B
B
E
C
It's
like
you'll
have
that
problem
anyways,
because
you
have
a
delegated
route,
necessarily
is
a
subset
of
the
functionality
of
the
whole
right.
The
question
is:
it's
almost
like
a
you
can
discuss
it,
sort
of
like
just
like
what
is
the
trade-off
here
in
terms
of
design.
Are
you
going
to
end
up
with
a
a
reason,
a
different
resource
that
essentially,
after
iterating
it
a
couple
times
and
adding
features,
reaches
feature
parity
with
the
parent?
C
C
It's
a
tough
call.
I
would
say
one
thing
that
it,
the
api,
is
fairly
neutral
in
terms
of
what
it
supports,
so
it
it's
hard
to
see
that
if
you
copied
the
resource
into
a
new
one
that
you
would
end
up
significantly
different
than
just
the
resource
we
already
have,
but
that's
just,
I
think
the
group's
current
take
on
it.
People
can
correct
me
if
I'm
misrepresenting.
A
Yeah
you
know
I.
I
think
this
is
a
good
transition
here
to
the
the
last
comments
on
here
or
themes
of
the
last
comments
and
as
I
was
kind
of
describing
earlier
in
the
meeting,
it
seems
like
a
big
theme
throughout
these
comments
is
questions
about
what
delegation
would
support?
What's
the
scope,
what
features?
A
How
does
it
work?
You
know
I
and
I
think,
having
some
kind
of
table
laid
out.
Maybe
it
starts
as
a
dock.
I
don't
know
where
it
belongs,
but
that's
it's
a
huge
effort
on
its
own
to
outline
every
single
feature
of
http
route
and
how
it
interacts
with
this
right,
but
that
I
feel
like
that's
what
we
need,
and
I
remember
you
know
the
feature-
requests
that
I
saw
in
oss
that
really
stuck
well.
A
I
shouldn't
say
it
started
this
discussion,
but
it
is
a
good
part
of
it
was
I
want
to
delegate
path,
slash
foo
to
foo
name
space
and
that's
what
the
the
feature
we
see
all
throughout
our
gap
or
whatever,
and
if
that's
really
all
it
is.
If
it's
really
just
path
prefix
to
hp
route,
then
the
full
hp
route
resource
is
potentially
overkill.
A
It
feels
very
important,
and
I
think
I
think
you've
already
covered
a
chunk
of
that
and
and
so
correct
me,
if
there's
already
some
in
here,
but
that
that
feels
like
just
the
theme
of
the
comments
that
that
seemed
most
significant
to
me
in
the
gap
as
it
exists
today
and
then
and
so
jeff.
I
know
you've
got
a
ton
going
on,
so
let
us
know
if
we
can
help
you
with
with
any
part
of
this.
A
I
know
that,
like
this
is
a
massive
gap
and
there
are
parts
that
we
could
potentially
you
know
break
out
if
it
helps
but
yeah.
Let
us
know
how
it
can
help.
B
Something
you'd
suggest
rob
to
me
in
our
direct
conversations
with
you
know.
Maybe
it's
some
of
the
status
stuff
we
extract
in
into
a
like
a
sub,
maybe
like
an
appendix
or
something
so
we
can
work
on
that
kind
of
independently
and
I
think
the
idea
of
having
a
table-
or
you
know
how
things
you
know,
what
support
at
the
parent
versus
a
child
and
how,
when
you,
when
you
merge
them,
you
know
what's
the
behavior
under
certain
situations.
B
B
So
I
I
need
to
go
through.
You
know
the
comments
myself.
I
need
to
respond
to
some
that
that
I
can
address
directly,
but
those
are
my
my
first
couple
of
suggestions
is
that
you
know
we
kind
of
treat
those
things
as
as
appendices
to
the
gap.
It
can
be
updated.
F
So
so
jeff
I
mean
one
one
concern
I
had.
While
I
was
reading
it
that
just
made
it
a
little
bit
difficult
was
having
to
wade
through
all
the
comments
about
fairly
trivial
things.
I
would
actually
volunteer
if
you
want.
I
can
go
through
the
comments
and
make
my
own
fork
of
your
spec
and
apply
what
I
would
consider
to
be
trivial
non-controversial.
F
I'm
making
air
quotes
here,
changes
I.e,
not
the
delegation
stuff,
but
I
mean
especially
in
terminology
markdown
formatting,
all
that
kind
of
I
mean
if
you
want.
I
would
do
that
and
and
push
another
revision,
and
at
least
that
way
we're
starting
with
a
clean
copy.
B
I
mean
you're
certainly
welcome
to
do
that.
I
I
think
you
know
a
lot
of
the
somewhat.
Sometimes
a
lot
of
the
details
were.
I
was
trying
to
think
of
different
scenarios
that
I
kind
of
see
I've
seen
it
that
I've
encountered
and
trying
to
address
you
know
what
would
be
that
case.
If
the
comments
aren't
helpful,
then
then
then
sure
we
can
make
we
can
extract
those.
If
that's
if
that
people
feel
that
would
make
it
easier.
I'm
not
sure
I
I
think.
A
I
think
he's
just
referring
to
you
know
the
various
formatting
and
typos
and
and
things
like
that,
there's
a
bunch
of
those
that
yeah.
F
F
It's
got
a
lot
of,
and
so
you
know
so
you
you,
for
example,
you
and
nick
raised
some
very
valid
use
cases
that
are
not
in
the
spec,
so
I'm
coming
in
and
saying
I'm
trying
to
evaluate
it,
based
on
the
use
cases
that
are
in
the
spec
and
then
we
start
discussing
them
and
it
turns
out
there
are
a
whole
bunch
of
other
use
cases
that
I
don't
know
about.
So
so
I
think
in
terms.
C
Of
like
github
workflow,
isn't
it
the
case
that
you
can
send
a
patch
to
jeff?
And
I
mean
I
I'm
hesitant
to
like
clone
a
pr
because
right
like
we
still
want
to
preserve
the
history.
So
my
advice
is
you
know
it's
good
right
like
you
can
have
a
patch
where
you
have
merged
all
the
markdown
changes
and
then
just
send
it
to
jeff
and
then
jeff
can
just
apply
it
on
his
tr
yeah.
That's
like
the
easiest
thing
to
do.
D
Status
with
you,
with
the
status
up.
B
Yeah-
and
I
you
know,
I'd
be
happy
to
do
that.
As
you
know,
with
based
off
of
the
revisions
you
make
to,
you
know
clean
up
all
the
the
noise
all
right.
B
A
Okay,
so
this
is
great,
I
think
we're
we're
splitting
this
out.
Well,
so
toby
thanks
for
volunteering,
for
that,
I
think
the
other
thing
split
out
the
status
bit
into
a
sub
gap,
maybe
nick
since
you've
already
been
doing
a
lot
of
this
status
stuff.
A
If
you
can
formalize
that
and
then
I
think
I
can
handle
the
last
one,
which
is
at
least
create
the
workflow
for
creating
the
feature
list,
some
ideas
for
what
may
or
may
not
be
in
scope
and
how
that
could
work
and
I'm
sure
that
will
have
lots
of
comments
on
its
own,
but
maybe
that
lives
in
a
different
pr,
so
that
that
seems
good.
We
have
lots
more
to
get
to
here,
so
I'm
gonna
keep
on
going
here.
Let's
move
right
into
nick's
new
gap,
which
is
back-end
properties.
D
Yeah
so
shane
had
a
great
suggestion
here
to
try
and
avoid
ending
up
as
deep,
ending
up
having
to
go
as
deep
as
sort
of
explaining
everything
to
everybody,
as
we
had
to
with
with
inclusion,
is
to
sort
of
ins
rather
than
move
straight
to
like
here's.
D
What
we're
gonna
do
and
here's
how
we're
gonna
do
it
that
we
move
that
we
try
out
saying
like,
let's
all
agree
on
what
we're
going
to
do
and
what
problems
we're
solving
and
why
we're
solving
those
problems,
put
the
gap
in
as
provisional
in
that
way
and
then
come
back
around
and
actually
have
like.
I
mean
I
have
plenty
of
ideas
of
how
I
would
do
it,
but
let's
agree
on
the
what
on
the
y
first.
D
So
then
we're
not
like,
then,
when
we're
doing
the,
how
we're
not
spending
time
like
talking
about
the
what
and
the
wire
right.
So
I
think
this
feels
like
a
thing
that
will
probably
be
good
sort
of
good
for
big
gaps
in
the
future
is
to
sort
of
be
like.
Let's
agree
on
the
what
and
the
why
of
what
we're
doing
and
then
we'll
come
back
to
the
how
and
so
yeah
sorry
jeff.
I.
B
D
I
think
that
there's
an
improvement
we
can
make
here
will
we
merge
a
simpler
gap
that
has
that's
a
provisional
gap
that
has
the
sort
of
the
the
what
and
the
why
just
the
what
and
the
why
right,
so
that
so
the
diff
that
you're
looking
at
then
is
not
like
here's
like
a
thousand
lines
of
stuff.
It's
like
here's.
What
we've
agreed
already
and
now
here's
how
we're
gonna
do
it
right,
and
so
I
think
it
was
great
so
shane
asked.
Can
we
avoid
google
docs?
D
What
we
have
found
in
the
past
is
that
you
know
how
we
were
just
saying
about
how
reviewing
a
thing
with
like
100
comments
on
it
in
github
kind
of
sucks.
Like
think
about
that,
if
we
had
500
to
700
comments
on
it,
which
is
what
you
will
often
get
in
the
very
early
phases
of
of
doing
a
gdoc,
is
that
there'll
be
a
lot
of
iteration
very
quickly
and
so
like
that's?
A
D
D
Like
and
you
can't
see
them
anymore
and
so
like
that's
the
key,
isn't
it
people
just
want
the
resolved
comments
to.
D
So
you
have
like
a
clean
thing
to
review,
as
toby
was
saying,
is
actually
really
really
useful
as
well,
and
so
I
think
that's
why
we've
turned
are
on
the
side
of
doing
a
g
dot
first,
because
it
lets
you
sort
of
keep
a
clean
set
up
in
that
in
that
initial
g
dock.
And
then,
when
you
pick
up
that
dude,
I
can
put
it
in
it's
like
okay.
Now
we
do
a
pass
on
what
we've
got
written
here
and
see
if
it
makes
sense
to
people
who
haven't
been
keeping
up
with.
F
D
Ew
yeah
so
yeah,
so
right
now
this
you
know
this.
Actually,
this
actual
issue,
if
you
could
just
scroll
down
a
bit,
there's
been
a
little
bit
of
conversation
on
here
already.
You
know
I've
put
the
thing
in
there.
I
think
that
john
made
a
good
point
that
and
mike.
D
I
think
that
one
of
the
things
we
want
to
do
here
is
be
very
clear
that
some
of
the
stuff
we're
doing
is
going
to
be
useful
in
the
mesh
gamma
use
cases,
and
but
I
think
that
keeping
the
the
mesh
encryption
separate
is
a
good
idea
like
that.
The
the
main
thing
that
we're
talking
about
here
is
how
you
get
from
the
gateway
to
the
back
end
right,
like
in
the
in
the
encryptions
the
encryption
hop
there.
D
I
think
that
even
referenced
in
that
91
issue,
that's
there
where
it
says
it
says
just
below
rob.
Evan
mentioned
this
issue
four
days
ago,
yeah,
so
that
one
is
that
this
issue
describes
client
certificate,
validation,.
D
Of
listeners,
I
put
a
thing
down
the
bottom
to
sort
of
clarify
that,
but
so
this
issue
describes
classic
validation
like
for
clients
who
live
out
in
the
internet
or
outside
the
cluster
or
external,
to
the
gateway
and
like
right
now
we
don't
have
a
spot
in
the
api
to
put
the
client
client
certificate
validation
details
for
if
you
want
to
have
client
certificates
there.
There's.
D
Just
like
how
you
drop
some
drops
of
config
in
because
most
people
who
do
that
want
to
use
the
client
search
for
authentication
and
probably
then,
details
from
the
client
so
for
authorization,
so
you've
got
to
make
sure
that
a
few
things
happen.
That's
what
some
of
the
discussion
in
that
one
is
for
from,
but
yeah.
I
just
wanted
to
make
clear
that
1.282
is
all
about
gateway
to
back
end
like
gateway
to
back-end.
That's
why
I
called
it
back-end
properties,
because
that's
what
it
is.
D
I
am
trying
to
avoid
the
use
of
the
terms
upstream
and
downstream,
because
envoy
flips,
those
around
to
what
a
lot
of
people
who
are
used
to
using
reverse
proxies
talk
about
up
streams
in
onboard
talk
are
back-ends,
not
clients,
and
so
I'm
being
very
specific
and
using
back
end
and
client,
because
those
are
more
clear
terms
and
aren't
subject
to
confusion
so
yeah,
so
yeah
rob
if
you
could
pull
up
the
the
gdoc
there's
been
a
bit
of
conversation
on
there
already.
I
would
encourage
people
to
have
a
look.
D
I
don't
think
this
one
is
like
that
tricky
to
get
the
the.
What
we're
trying
to
do
here-
and
I
have
I
did-
expand
that
one
that
shane
comment
there.
I
think
that
most
of
the
comments
are
kind
of
resolved.
I
think
john
has.
D
The
same
stuff
that
he
didn't
think
that
you
know
that
we
need
to
be
clear
about
what
the
information
is,
but
I
think
that
this
is
actually
feels
to
me
like
it
should
be
reasonably
close
to
something
reviewable
for
like
the
what
and
the
why
I
think,
the
prior
art
section
here
that
use
the
thing
that
the
the
issue
that
candice
logged
about
the
specific
case
of
tls
details
only
was
really
useful.
Thank
you
candice
for
that
the
but
yeah.
I
think
this
is.
D
This
is
slightly
more
general
than
that
discussion.
So
yeah.
Please
have
a
look
at
this.
You
I
think
I've
resolved.
A
D
Kind
of
would
like
people
to
read
it
before
I
go.
Changing
it
too
much
more
to
sort
of
make
sure
that
it's
it's
clear.
That's.
A
D
A
A
A
Great
all
right,
gotta
keep
moving
pretty
quickly
here,
translation
tools,
this
you
as
well
nick.
D
Yeah-
so
I
just
wanted
to
put
this
in
here
to
mention
on
the
record
that
I
have
discussed
a
couple
of
times.
I
don't
have
anything
tracking
this
that
at
some
point
we
should
look.
We
as
a
community
should
ensure
that
there
are
some
tools
to
help
people
get
from
one
thing
to
another
to
get
from
ingress
to
gateway.
You
know,
as
contour
contour
maintainer
I
would
want
like
http
proxy
to
gateway.
You
know.
D
I
would
imagine
that
a
lot
of
the
other
folks
who
have
their
own
crds
would
probably
want
something
to
help
translate
from
other
crds
to
gateway.
So
it
feels
like
something
that
might
be
useful
is
like
a
tool.
That's
that
has
a
little
bit
of
plug-in
style
framework
that
lets
you
suck
in
conflict
from
somewhere
and
then
and
then
spit
it
out,
as
gateway
would
be
generally
useful
for
the
community.
D
I
think
sanjay
from
the
contour
team
is
gonna,
get
started
on
something
for
this
for
contour,
so
that
we'll
have
something
to
sort
of
look
at,
but
then
I
just
wanted
to
raise
this,
that
it's
something
that's
on
my
radar
that
I
think
that
it'll
be
a
really
useful,
ux
thing
to
be
able
to
help
people
move
like.
D
Oh,
you
want
to
try
out
the
gateway
api.
Well,
here's
the
thing
that
will
take
your
ingress
and
put
it
in
there,
and
oh
thanks
yeah
thanks
keith
yeah.
That
is
my
controller.
Sdk
might
be
another
good
place
to
start,
but
I
think
you,
one
of
the
things
that
I
would
like
us
all
to
have
think
about
is
if
we
did
build
something
like
that,
where
should
it
live?
D
Should
it
leave
in
the
api
repo?
Should
it
be
like
a
specific
thing
that
starts
out
somewhere
else
and
comes
into
the
gateway
api
repo
when
it's
more
built?
Like
I
don't
know,
I
have
no
idea,
but
I
just
wanted
to
phrase
that
if
we
had
a
tool
like
this,
that
was
like
a
community
supported
one.
Would
it
make
sense
to
put
it
in
the
gateway,
api,
reaper
or
some
other
repo,
that
the
gateway,
pi
project
controls,
or
I
don't
know
like,
have
a
think
about
that
and
think
about
what
we
might
do
there.
A
Yeah,
that's
a
good
question,
I'm
not
sure
offhand.
I
know
that
I
I
thought
I'd
seen
someone
talking
about
doing
the
ingress
to
gateway
conversion
already,
but
I
don't
know
what
the
progress
of
that
is.
Yeah
that'd
be
very
valuable.
I
don't
have
a
strong
opinion
on
where
I
should
live.
I
just
want
it
to
exist.
C
I
think
if
it's
ingress
the
gateway,
that's
like
a
kubernetes
standard
resource
to
standard
resource
that
definitely
seems
like
it
fits
well.
I
think
like.
If
you
try
to
suck
in
lots
of
non-standard
projects,
you
do
run
into
the
cloud
provider
problem
in
standard
kubernetes,
which
is
like
eventually
just
gets
so
big
and
hard
to
that.
It
gets
difficult.
D
D
C
Yeah
I
mean
it
sounds
interesting,
and
if
someone
is
willing
to
whip
up
what
the
general
shape
of
it
is,
then
we
should
definitely
discuss
it.
A
Cool
I
next
on
the
agenda
I
wrote
out
just
this
is
mostly
for
my
own.
Oh
no,
not
next!
On
the
agenda.
I
missed
one.
This
is
not
publicly
visible,
yet
I
need
to
work
with
one
of
the
github
admins
in
kubernetes.org
to
make
it
so,
but
I
just
sketched
out
a
project
board
for
gap
tracking.
This
is
something
that
had
been
suggested
at
various
points.
A
I
very
much
a
work
in
progress,
but
I
thought
it
was
useful
to
see
the
things
that
have
merged
where
they
are
where
they
are
for
conformance,
for
example,
you
can
see
some
of
these
that
have
made
it
to
experimental,
don't
have
conformance,
there's
one
that
has
made
it
to
standard
that
doesn't
have
conformance
tests.
Yet
these
kinds
of
things.
A
This
is
very
much
something
that
evolves,
but
if
you
have
ideas
for
project
boards,
let
me
know
want
this
to
be
a
little
bit
more.
Well,
let
any
of
the
maintainers
know
just
want
this
to
be
a
little
bit
more
discoverable.
If
you're
trying
to
understand
where
the
project
is
headed
and
the
major
themes,
I
think.
B
A
A
Next,
the
060
rough
timeline
here
I
just
wanted
to
get
something
out
in
at
a
rough
level
of
if
we
want
to
have
a
release
out
by
kubecon,
let's
walk
backwards
and
think
about.
When
do
we
need
to
hit
these
dates
by
I,
and
from
my
perspective,
you
know
if,
if
we
consider
these
rough
dates
reasonable,
it
means
early
september.
We
need
to
have
our
gaps
merged
and
implemented
that
we
want
to
get
in
060
and,
if
they're,
not
in
by
september
12.
A
I
think
we
need
to
start
going
through
the
process
of
backing
them
out.
So
that's
you
know.
In
some
sense,
it
may
seem
like
a
long
ways
out,
but
it's
not
so
yeah.
There's
a
lot
to
do.
I
think,
at
a
minimum
we
should
be
able
to
get
reference
grant
and
grpc
route
in
a
release
before
kubecon,
hopefully
something
else,
but
we
are
just
about
out
of
time
for
today's
meeting,
so
I
don't
want
to
go
too
far
into
that.
A
Just
keep
these
dates
in
your
mind
when
you're
thinking
about
projects
and
things
you
might
want
to
get
into
the
next
gateway
release
and
finally,
with
not
any
minutes
to
spare,
I
want
to
just
highlight
grpc
route.
Pre-Submits
are
passing.
I
think
everyone
has
had
a
chance
to
look
at
this.
All
the
comments
are
resolved.
A
A
Cool
okay,
I
again
reach
out
in
the
next
24
hours
or
so
otherwise.
We'll
aim
on
just
getting
this.
In
with
that
said,
thanks
everyone
for
a
great
discussion
and
we'll
talk
to
you
actually
for
anyone
in
gamma
meeting
is
morning,
pacific
time
so
around
what
18
hours
from
now
16
hours
from
now
keith.
You
know
you
may
know,
but
anyways
it's
earlier
than
normal,
so
we'll
see
everyone
there
or
next
week
have
a
great
one.