►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20221003
Description
SIG Network Gateway API Bi-Weekly Meeting for 20221003
A
All
right,
everyone
welcome
to
Gateway
API
meeting
for
October
3..
We've
got
a
few
things
on
the
agenda
and,
as
always,
feel
free
to
add
more,
as
you
see
fit,
welcome
to
kubernetes
community
meeting
that
all
of
them
are
fairly
similar
in
the
sense
that
anyone
should
have
access
to
this
agenda
feel
free
to
add
things,
and
everything
is
subject
to
the
same
kubernetes
code
of
conduct,
which
is
in
general,
just
be
nice.
So
with
that
I
think
I'll
hand
it
off
to
Mike,
because
you've
got
the
first
thing
on
the
agenda.
B
All
right
so
yeah
this
is
I
can
share
my
screen
if
that
helps
her
but
yeah.
So
once
it's
kind
of
like
recapped
over
the
past
couple
weeks
in
the
Gateway
API
for
service
mesh
meetings,
which
are
happening
during
alternating
time
slots
on
Tuesdays.
Following
this
meeting,
we've
been
kind
of
workshopping
numerous
ideas
for
how
to
use
the
HTTP
route
resource
to
manage
mesh
traffic
rules,
specifically
focusing
on
the
producer
use
case.
B
So
as
a
service
owner
I
want
to
configure
Canary
deployments
or
other
ways
of
splitting
traffic
intended
for
a
named
service
and
we've
gone
through
a
series
of
proposals
there
and
we
kind
of
we
came
up
with
finally
a
gap
which
I
have
opened
today.
A
couple
hours
ago,
we've
got
1426
for
HTTP
root,
mesh
binding
and
try
to
share
this
foreign.
B
B
B
The
scope
to
future
proposals
so
like
that
includes
egress
use
cases
like
the
direction
of
authentication
or
authorization
of
services,
policy
attachments
or
outside
cluster
resources,
such
as
VMS,
because
the
high
level
goals
is
to
be
able
to
support
configuration
of
these
routes
by
a
service
owner
are
having
some
mechanism
to
allow
cluster
operators
to
allow
which
services
or
how
routes
are
applied
to
the
mesh
and
being
able
to
have
it
clearly
defined
on
a
route
where,
where
and
how
traffic
is
being
redirected
and
included,
support
for
transparent
proxy
use
cases.
B
So
being
able
to
deploy
these
resources
without
substantial
reconfiguration
by
application-
Developers,
oh
all
right!
So
with
that
kind
of
like
the
proposed
approach
that
we
ended
up
on
is
relatively
simple.
It
does
not
require
adding
any
new
apis.
It
does
not
require
any
breaking
changes
to
the
existing
API
and
it's
really
just
a
clarification
of
defining
expected
behavior
when
a
resource
when
HTTP
resource
is
configured
in
this
way.
B
So
what
we're
proposing
to
do
is
manage
the
application
of
the
traffic
riding
rules
to
Services
by
instead
of
defining
a
Gateway
as
a
paragraph
targeting
a
service
as
a
paragraph
of
an
HP
group.
B
Through
this,
we
can
then
use
the
back
end
rust
field
to
just
as
we
would
for
binding
to
a
gateway
to
be
able
to
split
traffic
between
different
Services
different
versions
of
the
service.
This
could
be
useful
for
carry
deployments
or
redirecting
traffic
when
breaking
up
a
monolith
or
something
like
that,
and
there
are
verbose
details
on
kind
of
the
nuances
of
how
this
should
be
implemented,
of
what
services
are
allowed
to
be
referenced
in
this
way
or
are
not
allowed
to
work
in
this
way.
B
Specifically,
like
node
or
and
load
balancer
that
we're
not
they're
not
specifically
excluded
elsewhere,
that
I
could
see
in
the
Gateway
API
spec,
but
it
just
being
clear
that
that
is
not
a
preferred
way
of
expliciting
services
publicly.
The
Gateway
API
north
south
API
should
be
preferred
for
that
case,
and
similarly,
with
external
name,
there's
an
open
issue
describing
how
it
could
potentially
be
used
in
Gateway
guy,
but
for
now
it's
left
as
it
should
not
because
of
potential
security
concerns
with
it.
B
Oh
they're,
there's
all
coverage
of
services
without
selectors
stateful
sets
potential
option,
as
well
as
multiculture
support
service
and
work,
and
some
of
the
nuances
of
how
the
host
names
feel
and
graph
depth
and
providing
circular
references
should
be
handled.
I'll
pause
there
for
a
moment.
Rob
your
own
question,
yeah.
A
I,
just
so
just
to
go
back
up
a
bit
to
the
allowed
service
types
that
one
stuck
out
to
me
a
little
bit.
You
know
I,
think
of
services.
You
know
node
port
and
load
balancer,
basically,
a
superset
of
cluster
IP
in
terms
of
service
type.
Is
there
a
reason
we'd
intentionally
exclude
like
if
we,
if
we
allow
the
subset,
which
is
cluster
IP?
A
B
So
the
intent-
and
this
is
one
of
the
few
areas
where
we
did
not
have
substantial
priorities
we
a
lot
of
this-
has
been
worked
out
through
substantial
amount
of
power
discussion.
This
spot
was
trying
to
kind
of
clarify
some
behavior
that
is
not
explicit,
currently
or
well-defined
within
the
existing
Gateway
API
spec.
B
B
If
there's
viable
use
cases
for
this,
where
it
would
be
expect
where
it
could
recently
be
expected
to
like
not
cause
conflicts
with
this
or
north-south
Gateway
API
Behavior
I'm,
open
to
suggestions
but
kind
of
the
spirit
of
a
lot
of
the
constraints
in
this
Gap
is
to
really
restrict
the
proposed
implementable
functionality
to
a
narrow
subset
with
the
intent
that
some
of
these
constraints
could
be
relaxed
later.
If
there's
use
cases
to
justify
them,.
A
Yeah,
that
makes
sense,
I,
guess
kind
of
a
follow-up
question
here
like
and
this
I'll
say
that
I
am
not
a
mesh
expert
here.
A
But
my
my
rough
idea
here
is
that
of
this
idea
is:
is
that
you
would
have
a
say,
a
load,
balancer
type
service
or
no
Port
type
service
that
you've
used
to
expose
your
application
externally,
let's
say,
but
that
same
application
you
want
to
for
East-West
traffic,
apply
some
kind
of
policy
or
some
kind
of
traffic
splitting
too,
and
so
I
thought
the
the
purpose
of
this
API
would
be.
A
B
So
that
is
explicitly
it
so,
the
basically
the
interoperability
or
interaction
between
north
south
and
East-West
configuration
is
listed
as
a
non-goal,
because
there's
a
few
different
ways.
We
could
approach
it
and
I
think
interested
that
we're
going
to
try
to
explore
that
in
a
future.
Gap
there's
a
future
for
ways
that
that
could
happen.
One
is
by
supporting
multiple
parent,
refs
I.
B
Suppose
the
other
service
types
is
another
way,
even
though
that's
not
something
that
We've
really
talked
about
and
watch
this
option
and
then
there's
also
like
implicit
references
or
like
implicit
application
of
mesh
rules
to
the
north
south
Roots,
which
is
a
thing
that
is
possible
in
possible
notation,
currently,
but
maybe
difficult
to
implement
across
vendors
or
in
a
standardized
way.
C
Yeah
I
think
to
follow
on
what
Rob
says.
Is
it
more
accurate
to
say
that
this
proposal
says
nothing
about
if
you
have
node
port
and
load
balancer?
What
that
means
for
the
mesh
versus
you
can't
because
I
think
by
restricting
it
it
feels
a
little
funny
just
because
of
the
current
semantics
of
how
Services
work.
That's.
B
Valid
I
I'm,
totally
fine
modifying
the
language
there.
That's
all
costs
and
suggestions
in
chat
should
not,
instead
of
must
not
or
being
explicit
about,
does
not
have
any
implications
for
this
functionality.
Awesome.
D
Yeah
I
I
think
one
of
the
problems
we
are
seeing
and
we
discussed
the
length
is
that
service
is
multiplexed
and
it
means
a
lot
of
things,
and
this
is
a
way
to
kind
of
Select,
seven
specific
semantics
of
service
and
it's
a
front-end
for
in
cluster
Services,
which
is
and
focus
on
those
first
and
then
leave
you
know.
Egress
use
cases
and
Ingress
use
cases
to
separate
discussion.
Meaningless
is
already
covered
by
Gateway
and
it's
better
to
Not
Duplicate
it
because
it
will
create
confusion
for
users
and
for
egress.
D
C
B
Talk
about
this
a
little
bit,
this
was
another
last
minute
Edition
when
I
was
going
through,
trying
to
enumerate
every
possible
kind
of
service
in
response
to
some
feedback
that
Nick
had
about
being
more
explicit
about
this
I
am
very
open
to
our
recommended
language
or
exclusion
of
this.
Specifically
it
it's
it
seemed
like
it
could
be.
Valid
is
the
only
reason
it's
included,
but.
D
State
four
sets
and
and
headless
services
are
particularly
tricky
to
implement
from
mesh
perspective
and
also
kind
of
fit
in
the
category
where
we
want
a
separate
discussion,
because
it's
persistent
session,
it's
you
know
how
do
you
deal
with
multi-clusters?
There
are
a
lot
of
issues
with
both
of
them
and
they
deserve
their
own
discussion.
I
think.
B
A
B
So
this
is
most
of
just
acknowledging
that
service
import
could
be
referenced
in
a
very
similar
way
to
surface
and
looking
out
to
a
specific
use
case
in
which
one
might
want
to
do
that
it.
It
is
a
may.
It
is
not
a
sure
it
is
not
expected
as
part
of
performance
or
anything
like
that.
B
And
yeah,
just
there
are
there's
an
extensive
list
of
Alternatives
that
we
consider
to
discussed
just
briefly,
one
of
the
primary
ones
we
consider
was
introducing
a
new
resource
to
represent
the
front-end
role
of
a
service
and,
among
other
drawbacks
kind
of
the
there's.
Some
substantial
interest
in
the
problem
to
be
solved
is
fundamentally
an
issue
with
the
Upstream
service
resource
itself
and
the
approach
that
we're
proposing
of
directly
referencing
the
services.
Paragraph
does
not
foreclose
solving
that
Upstream,
eventually
and
kind
of
the
entire.
B
What
would
be
to
minimize
like
excess,
abstraction
or
API
churn
in
doing
so,
and
one
of
the
other
options
which
is
still
relevant
not
necessarily
on
its
own,
but
possibly
in
combination
with
the
way
that
we're
posting
is
adding
a
mesh
resources
paragraph.
B
So
those
two
in
particular
are
like
the
worth
reading
through,
just
to
think
about
how
how
that
functionality
may
have
a
bearing
on
future
design
positions
and
kind
of
like
how
we
ended
up
in
the
spot
that
we're
at
now
Richard
question.
E
E,
oh
there
we
go
yeah,
so
I
have
a
question
from
the
perspective
of
a
proculus
service
match
about
the
hostname
section
here
and
sorry.
If
this
section
has
already
been
discussed,
so
it
seems
that
The
Proposal
here
is
very
DNS
oriented
right
like
we
use
the
the
Kube
DNS
name
from
the
service,
so
I
don't
know
if
there
are
any
other
practical
service
meshes
out
there.
My
comments
are
going
to
be
from
perspective
of
grpc
profitable
service
mesh.
E
The
way
that
name
resolution
works
is
instead
of
depending
on
the
host
header
and
routing,
based
on
that.
Instead,
when
you
direct
your
request
at
some
Target
string,
we'll
use
that
Target
string
directly
without
performing
a
DNS
query
and
instead
we
use
that
to
query
the
control
plane
and
get
the
configuration
directly.
E
So
the
thing
that
I
can't
fully
figure
out
how
it
would
work
is
like
the
search
path
right
so
like,
ideally,
if
you're
in
the
same
namespace,
you
should
be
able
to
direct
a
a
request
to
pod
Foo
as
like
Foo
right
and
not
like
food.internal
blah
blah
blah
blah
I,
don't
see
how
you
can
get
around
that
for
proxy
list.
What
you'd
end
up
with
is
like
a
degraded
ux4
proxy
list.
E
B
So,
let's,
let's
depend
on
DNS
and
I
think
support
a
model
by
which
it
is
possible
to
not
require
reconfiguration
of
DNS
I
I
think
this
is
the
not
being
super
familiar
with
practice
and
stuff,
so
I'm,
hoping
that
John
or
customer
will
offer
some
just
like
explanations.
But
I
would
expect
that
if
it
is
possible,
if
you're
specifying
Upstream
by
any
other
means,
then
as
long
as
the
control
plane
is
aware
of
this
configuration,
it
should
be
able
to
route
that
request
properly.
F
Yeah
I
would
say:
I
mean
the.
The
idea
is
really
that
we're
just
referring
to
a
service
as
an
in
the
normal
proxy
mesh
case.
We
identify
that
by
IP
address,
which
happens
to
rely
on
DNS
for
proxy
list.
You
could
just
identify
it
by
the
name
right.
If
they
say
you
know,
send
a
request
to
who
and
they
have
a
route
for
the
Food
Service.
Then
you
can
look
that
up
that
doesn't
have
to
actually
do
DNS
or
actually
rely
on
IP
addresses.
F
You
like
you,
as
the
mesh
implementer
are
responsible
for
defining
what
it
means
to
attach
to
a
service.
Now,
if
you
are
a
normal
proxy
mesh,
then
you
should
do
that
based
on
IP,
address,
I,
think
we're
saying
but
I
think
it's
reasonable,
like
that's
just
an
implementation
detail.
Really
the
behavior
is
the
same
right.
They
they
meant
to.
They
called
this
service
and
they
get
that
behavior.
E
F
E
Okay,
as
long
as
the
ID
is
not
that,
like
you
know,
proxylist
users
would
have
to
have
a
very
long
Market
string
with
lots
of.
D
So
a
slightly
different
take
on
this
is
what
I
think
that
says
is
that
arbitrary
host
names
are
not
supported.
It
doesn't
mean
that
food
is
not
supported,
but
food,
not
name
space
or
food
as
we
see,
but
if
you
want
to
put
the
name
google.com
or
example.com
that
will
fit
into
the
egress
use
cases
and
and
it's
a
different
problems
and
what
we
are
solving
for
you
know.
Virtual
for
HTTP
will
still
use
a
host
header.
D
Authority
I
mean
the
host
name
will
still
be
used
in
a
lot
of
places,
I
mean
for
verification
for
other
things,
but
it
means
that
we
cannot
Define
arbitrary
host
names
through
this
mechanism,
because
that's
the
secret
of
this.
A
I
just
had
a
kind
of
a
broader
question
on
this
Gap,
and
that
is,
it
seems,
like
a
deferred
goal
or
a
non-goal
of
this
is
really
to
Define
how
this
interacts
with
well
anything
else.
Basically
right.
So
you
know
it
seems
like
this
is
really
designed
in
the
bubble
of
let's
take
these
apis
as
they
exist
and
make
them
work
for
our
use
case,
which
makes
sense,
but
it
seems
like
we
may.
A
If,
if
we're
not
careful,
we
may
end
up
on
a
path
where
these
apis
are
used
in
two
different
bubbles
in
two
different
worlds
and
those
never
interact
and
and
I
think
that's
not
the
end
goal.
I
just
I
I
am
concerned
that
if
we
go
too
far
down
this
path,
without
defining
how
East,
West
and
north
south
interact
or
how
multiple
meshes
interact,
that
just
the
gravity
of
that
approach
of
this
is
the
way
we
do
mesh
could
be
hard
to
overcome.
When
we
try
to
merge
these
back
together.
B
D
D
So
so,
and
there
was
a
discussion
brother
in
get
a
working
group
about
composition
or
or
I,
don't
remember
how
it
was
called,
but
to
Nest
or
chain
routes
and
I
think
that
will
need
to
be
Revisited
in
context
of
this
of
this
game,
I
mean
what
what
does
it
mean
to
if
you
have
a
HTTP
router
for
service
and
and
then
a
Gateway
Point
into
that
service?
That's
a
composition,
and
it
should
be
a
particular
case
or
should
be
included
in
in
whatever
compositions
a
Gateway
will
use
yeah.
B
B
Sorry
yeah
so
yeah.
Thank
you
for
real,
like
this
definitely
intersects,
with
some
of
the
concerns
that
were
raised
in
the
route,
inclusion
and
delegation,
Gap
and
so
I'm,
currently
working
on
a
small
Gap
as
a
follow-up
to
this,
to
really
focus
on
that
north-south
and
East-West
use
case
in
terms
of
what
is
the
integration
point
between
them,
because
there
are
at
least
like
three
different
ways
that
it
could
be
implemented.
B
G
Go
back,
yeah,
yeah,
I,
just
had
a
a
general
note
here.
You
know
as
far
as
gamma
and
kind
of
the
way
they've
gone
about
trying
to
trying
to
do
things
is:
we've
tried
to
limit
scope
and
focus
on
okay.
What
are
some
of
the
more
natural
semantics
that
arise
from
trying
to
you
know
represent
mesh
semantic
within
Gateway,
API
and
I.
Think
this
this
Gap
is
very
representative
of
that
and
I'm
thankful
to
Mike
and
others
who
have
contributed
and
gotten
it.
G
To
this
point,
a
lot
of
good
work
being
done
here
from
some
of
what
I'm,
hearing,
Rob
and
and
Bowie
mention
here,
I
think
that
something
to
keep
in
mind
that
I'm
keeping
in
mind
moving
forward.
Is
you
know
how
do
we
address
those
intersection
points
between
mesh
semantics
and
north-house
semantics,
because
you
know
in
in
this
skip
we've
kind
of
tried
to
defer
those
conversations.
I,
don't
know
that
we're
always
gonna
be
able
to
do
that,
but
we
had
a
comment.
G
I
think
I
think
was
Billy
I
thought
we
should
try
to
Upstream
as
much
stuff
as
possible.
You
know
what's
the
process
for
that.
You
know
that's
something
we
should
be
figuring
out.
There
was
at
one
point,
there's
some
hesitation
to
a
particular
approach,
because
they
would
require
changes
to
the
Upstream
HTTP
route
resource,
and
that
was
one
of
the
attractive
things
about
this
approach
for
HTTP
routers,
that
it
wouldn't
require
any
Upstream
changes.
You
know
how
open
is
the
Gateway
API
project
to
changes
to
those
crds?
G
G
You
know
that
that
does
require
a
certain
level
of
scrutiny.
Understandably,
when
you're
making
changes
to
already
implemented
resources
that
I
believe
are
already
in
beta,
so
I
don't
really
have
Solutions
here,
but
I
think
these
are
questions
we
should
be
thinking
about.
As
we
start,
you
know
really
talking
about
things
like
HTTP
route,
that
I
really
shared.
G
We
I
think
we
got
to
figure
out
ways
to
be
able
to
to
work
and
to
iterate
and
to
experiment,
but
also
you
know
recognize
that
these
apis
are
already
in
use
by
a
lot
of
people.
So
I'll
get
off
my
soapbox
and
let
anybody
respond
if
they
want
to.
A
Yeah,
those
are
good
thoughts,
I
think
I.
You
know,
I
I
speak
for
myself,
anyways
that
I'm
certainly
open
to
Gateway
API
changes
for
gamma
I
mean
this
is
a
pretty
huge
use
case
and
we
want
to
make
it.
You
know
see
it
succeed,
the
the
places
that
I
start
to
get
uncomfortable
our
potential
fields
that
add
confusion
to
the
API
like
at
as
an
example.
If
we
had
a
list
of
service
refs
in
all
routes
that
I
don't
I,
don't
even
know
if
that
was
ever
a
proposal.
A
But
let's
just
pretend
we
did
that's
something
that
you
could
say
made
sense
for
north
south
and
east
west
and
be
confusing.
Is
this
just
for
mesh?
Is
this
just
for
East
West?
You
know
so
I.
If
we
do
make
changes,
I
would
strongly
strongly
prefer
that
they
not
confuse
the
north-south
use
case
that
that's
kind
of
you
know
my
my
take
on
it.
We
do
have
an
experimental
channel
that
we're
all
familiar
with.
A
So,
even
though
this
resource
has
made
it
to
Beta,
we
do
have
a
mechanism
of
getting
experimental
fields
in
it.
So
I,
you
know,
I
I,
don't
want
everything
in
in
gamma
to
feel
like
it's
unnecessarily
restricted
by.
We
can't
possibly
make
Upstream
changes
so
we'll
just
work
with
what
we
have
yeah
and
then
kind
of
I.
Guess
after
that
follow-up.
Just
a
a
kind
of
the
next
question
for
me
is
this
is
a
massive
Gap.
Thank
you
for
writing.
It.
A
B
So
that
is
one
of
my
hopes
in
really
trying
to
constrain
this
to
kind
of
core
functionality
and
pushing
off
a
lot
of
the
edge
cases.
Is
that
the
basic,
like
very
basic
traffic,
supporting
functionality
of
a
service
mesh
should
be
implementable
with
this
step
alone?
That
is
my
goal
for
it,
and
and
I
I
would
love
if
to
have
support
and
if
it
does
advance
to
be
improved
that
that's
kind
of
the
intent
of
this.
B
A
lot
of
of
the
like
other
stuff
that
we've
talked
about
is
kind
of
Behavior,
or
changes
to
augment
that
functionality
so
being
able
to
integrate
mesh
services
with
Gateway
API,
north
south
routes
being
able
to
do
something
like
control,
egress
functionality
or
redirection
from
arbitrary
domain
names,
to
in-cluster,
Services
being
able
to
specify
consumer
oriented
routing
overrides
that
would
be
narrowly
scoped
to
only
like
a
particular
service
or
a
particular
namespace,
and
not
broadly
applicable
to
any
service
dialing
that
so
that
kind
of
functionality
and
stuff
that
we
think
could
be
like.
B
Maybe
it
ends
up
in
an
extended
performance
or
something
like
that
or
is
just
ways
to
add
on
to
kind
of
like
the
core
use
case.
But
the
hope
is
really
that
this
Gap
lets
measures
start
in
my
detail.
It's
kind
of
the
hope.
A
Awesome,
okay
and
I
think
this
is
my
last
question:
how
it's,
if
I
understand
the
potential
overlap
right
now,
it's
that
the
same
route
cannot
be
used
for
multiple
meshes
or
multiple
gate
like
Gateway
and
mesh
at
the
same
time.
But
you
could
use
the
same
service
and
attach
you
know,
like
one
route,
could
be
used
for
north
south
to
forward
that
to
that
as
a
back-end
ref
and
the
other
route
could
Define
how
mesh
interacts
with
that
same
service?
Is
that
accurate
I.
B
I
believe
that
is
accurate,
where
it
that
is
defined
here,
somewhere,
yeah,
okay,
I
I,
think
it's
in
the
like.
Limiting
grass
deaths
rules
is
where
that
should
be
defined
so
like
the
intent
of
those
restrictions
is
to
still
allow
an
issue
for
your
best
traffic
rules
to
additionally
specify
so
I
I.
Guess
that
that
part's
underspecified
currently
but
like
there's
an
extensibility
point
there,
which
is
one
of
the
options
for
how
mesh
Services
mesh
HTTP
Roots,
could
share
functionality
across
north,
south
and
east-western
plantations.
B
B
A
A
Great
great
Gap
excited
to
see
all
the
detail
there
already
I
just
wanted
to
give
a
quick
update
on
reference,
Grant
I
think
many
of
you
may
have
been
following
this
discussion,
but
just
so
you
know
that
reference
Grant
has
some
interest
from
other
other
cigs,
most
notably
Sig
storage
is
proposing
use
of
this
in
one
of
their
caps
for
I.
A
Think
it's
cross,
namespace
volume
snapshots,
hopefully
I
got
the
the
name
correct
there,
but
you
can
read
all
about
the
cap
and
that
link,
and
so
there's
been
some
some
question
about
where,
where
this
should
live
long
term
I
think
reference.
Grant
is
a
concept
that
a
lot
of
has
drawn
a
lot
of
interest,
and
it
is
not
really
a
networking
concept
like
it
works
for
Gateway
API,
but
obviously
I
think
there's
broad
interest
in
pulling
this
somewhere
more
neutral.
A
Last
week,
I
brought
this
back
to
Cigar,
which
was
basically
a
year
since
we
discussed
it
lasted
some
really
good
questions
which
I
kind
of
outlined
here
and
are
going
to
require
some
more
follow-ups,
but
just
to
highlight
you
know
one
of
the
questions.
Our
references
assume
to
be
read
only
you
know.
We
have
two
very
specific
use
cases
we're
using
a
reference
grant
for
today
and
they
are
read
only,
but
there
is
kind
of
an
open
question
of
what
else
a
reference
Grant
could
be
used
for.
I
got
a
good
question
about.
A
Do
we
have
anything
that
formally
says
what
to
do
when
a
reference
Grant
is
well
defined.
I.
Think
we've
had
this
discussion,
but
I
couldn't
find
anything
in
writing.
So
I
think
we
both
need
a
conformance
test
for
this
and
documentation.
I
have
a
PR
which
I'll
get
to
which
gets
half
of
the
way
there,
but
we
still
need
some
conformance
test
coverage.
A
A
A
I
think
we're
close,
but
the
problem
is
that
there's
not
a
consistent
place
that
the
reference
comes
from
I
in
within
Gateway
API.
We
have
you
know
in
one
case
a
list
of
back
end,
refs
and
another
another
case.
A
list
of
certificate,
refs
and
they're.
Both
kind
of
nested
in
objects
it'll
be
hard
to
fully
automate
the
implementation
of
that
and
then
kind
of
the
the
last
thing
I
really
wanted
to
highlight
here
is
I.
A
Think
Jordan
had
this
idea,
you
know:
is
there
a
way
when
someone's
creating
a
reference
Grant
to
validate
that
they
actually
have
access
to
the
resource
that
they
are
providing
access
to?
Obviously,
we
are
looking
at
reference
Grant
as
a
highly
privileged
resource,
but
it
is
still
interesting
to
have
some
kind
of
Automation
in
front
of
that.
A
That
said,
that
double
checks,
when
that
Grant
is
created,
that
the
user
has
access
to
expose
that
resource
so
anyways,
just
some
good
good
follow-ups
here,
I'll
try
and
create
an
issue
to
track
conformance
test
coverage,
and
if
anyone
has
time
I
filed
this
PR
that
documents
a
variety
of
things
that
we
were,
we
were
missing
before
so
hopefully
this
helps
fill
in
some
gaps
and
gets
us
a
little
bit
closer
to
Beta
Readiness
for
reference
Grant,
but
just
wanted
to
highlight
the
otherwise
excellent
feedback
we
got
from
cigar
and
I.
A
Think
there's
still
some
interest
here
and
bringing
this
to
a
central
home,
but
we
we
have
no
idea
how
to
do
that
and
where
we're
we,
as
as
many
of
us,
are
familiar
kind
of
treading
completely
new
ground
and
in
everything
we
do
so.
I'm
gonna
try
and
bring
this
up
at
cigarch
this
week.
Anyone
is
welcome
as
always,
but
how
on
Earth
do
we?
If
we
move
this
to,
you
know
being
owned
by
Cigar
as
an
example
or
another
Sig,
and
it
has
a
more
neutral
home.
How
does
that
work?
A
My
proposal
is
that
we
continue
to
grab
towards
graduating
this
resource
to
Beta
in
Gateway,
API
I
think
any
of
these
other
tracks
are
going
to
take
quite
a
while
to
get
anywhere
so
I'd,
rather
just
continue
in
the
path
that
we
have
and
if
we
happen
to
get
widespread
consensus
from
segoth
and
cigarch
and
anyone
else
that
this
should
move.
We
can
deal
with
that
when
we
deal
with
that
any
any
thoughts
preferences
on
reference,
Grant.
D
I
put
a
comment:
I
think
it
may
be
worth
discussing
with
the
whoever
owns
a
hardback
resource.
If
this
wouldn't
be
better,
you
know
treated
us
because
our
back
is
already
a
high
privileged.
You
know,
security
related
permission
and-
and
there
is
some
duplication
here.
A
Yeah
so
that
that's
cigarth
so
misunderstood
I.
A
Sorry
yeah
yeah
in
in
kubernetes,
the
special
interest
group
owns
our
back
and
a
variety
of
other
things,
but
they
they
seem
most
relevant
to
this,
a
very
clear
distinction
between
reference
Grant
and
our
back
is
that
reference.
Grant
is
meant
to
be
runtime
validation
in
the
sense
that,
if
it's
revoked,
we
expect
that
access
to
be
revoked,
whereas
our
back
is
more.
You
know
as
long
as
it
as
you
are
allowed
to
create
it.
A
You
were
allowed
to
create
it
and
it
exists
forever
that
you
know
I
think
the
revoking
is
is
very
important
for
the
networking
use
case
where
we
want
someone
to
be
able
to
revoke
access
to
a
cross,
namespace
back
end
or
secret
or
whatever
it
is.
But
that
is
a
different
pattern
than
our
back
and
requires
a
different
means
of
enforcement.
D
D
A
Yeah,
definitely
and
and
you're
right
it
is.
It
is
entirely
possible
to
revoke
our
back,
but
you
know
it
any
anything
the
user
did
while
they
had
that
access
exists
forever
and
networking
is
a
little
bit
different
in
that
we
can
at
least
prevent
future
requests
being
allowed
all
through
that
path,
so
yeah
interested
in
more
discussion.
Anyone
is
always
welcome
to
to
join
these
meetings.
Say
art
I
forget
when
cigarch
is,
but
it's
mid-week
anyways.
A
If
anyone's
interested,
just
ping
me
after
and
we
can
go
from
there
yeah.
That's
that's
all
for
a
reference
Grant
next
one
is
kubecon.
Kubecon
is
coming
up.
We
have
I
think
by
my
account
six
talks
that
are
going
to
be
referencing,
Gateway
API,
which
I
think
means
we're.
Gonna
have
a
lot
more
people
looking
at
our
docs
and
our
docs
have
a
variety
of
gaps
or
you
know
missing
pieces
that
could
be
cleaned
up
so
I'd
encourage.
You
were
what
three
weeks
away
from
kubecon.
Now
it's
coming
up
really
quickly.
A
So
if
anyone
has
a
few
spare
Cycles,
if
you
can
even
just
spend
some
time
reading
through
docs
and
if
you
find
something
confusing
just
file
an
issue,
that's
that's
kind
of
Step
One
file,
an
issue
and
say
how
on
Earth,
you
know
that
this
part
is
confusing,
and
this
is
why,
especially
if
you're
a
new
contributor
and
less
familiar
with
the
API,
if
you
find
something
confusing
just
let
us
know
because
I'm
sure
you're,
not
the
only
one
that
finds
some
part
of
our
documentation
confusing
and
if
you
find
something
you
feel
like
you
can
also
fix.
A
H
Yes,
so
I
just
created
this
PR,
although
I
have
been
talking
to
Rob
and
Nick
a
bit
about
this
through
through
chat,
and
this
is
the
implementation
of
of
the
get
1282
back-end
properties
that
Nick
started
some
time
ago
and
that
we
were
I'm
hoping
to
fill
in
the
implementation
part
of
it
as
time
went
on
so
I
noticed
that
you
can,
you
can
actually
I
don't
know,
did
I
do
something
wrong.
H
You
can
bring
this
up
in
in
the
the
more
viewable
format,
if
you
click
on
checks
and
then.
A
H
A
A
Yeah,
do
you
mind
making
like
maximizing
or
whatever.
H
So
the
the
tldr
and
and
the
rest
of
this,
except
for
what
I'll
I'll
show
you
a
bit
later,
is
was
written
by
Nick,
Nick
Young
and
mostly
what
we're
trying
to
do
with
describing
the
back
end
properties
is
well.
H
The
initial
goal
was
to
be
able
to
enable
back-end,
TLS
or
reincrep
re-encrypt,
but
the
Gap
as
a
whole
is
basically
sort
of
summarized
as
describing
back-end
properties,
the
properties
that
you
need
to
use
post
Gateway
between
your
gateway
and
your
service
or
your
Target
in
the
end,
and
that
would
be
where
re-encrypt
would
would
come
in
play.
H
So
everything
that's
here
already
I
think
I
need
to
go
through
it
now
he's
already
written
it,
and
if
you
haven't
had
a
chance
to
read
through
this
I'm
going
to
leave
that
for
later,
unless
people
think
I
should.
H
Some
time
on
that,
okay-
and
this
is
a
proposal
for
the
API,
so
there'll-
be
a
new
object,
called
back-end
capabilities,
and
it
is
the
intention
is
for
this
to
be
a
a
decorator
on
top
of
service
and
it
does
point
to
the
service
and
then
the
reason
for
doing
it.
H
This
way
was
because
we
really
wanted
to
you
know
in
in
the
best
of
all
worlds,
we'd
like
to
be
able
to
change
the
kubernetes
service,
but
we
we
rather
not
at
this
point,
wait
for
something
like
that
to
happen,
so
this
is
going
to
be
sort
of
a
wrapper
to
that
service
on
its
own.
H
Let's
see
so,
back-end
capabilities
is
just
the
back
end
name
type
and
a
spec
and
Status
the
back
end
type
itself.
Is
you
know
whether
it's
a
service
or
a
service
import,
which
was
something
that
Rob
reminded
me,
is
coming
up
in
the
future?
H
Everything
is
pretty
straightforward.
I
think
this,
this
kind
of
format
looks
familiar
to
most
people.
H
The
target
reference
is
a
group
kind
version
name
and,
and
the
only
two
kinds
there
are
are
the
service
and
the
service
import.
As
I
mentioned
version
is
there
so
that
you
know
it's
easy
for
us
to
to
update
based
on
versions.
H
And
and
to
really,
you
know,
be
expressive
about
which
version
of
that
Target
reference
were
interested
in
I
did
not
put
namespace
in
here,
and
that
may
come
up
in
the
in
the
discussion,
because
I
think
we
are
considering
that
the
namespace
should
be
the
same
as
as
the
backend
capability
should
not
be
able
to
go
across
different
namespaces
in
this
implementation.
H
So
the
spec
itself
is
I,
think
you
call
this
optional,
unionized
struct
or
something
like
that.
I
forgot
what
it's
called,
but
every
every
type
that's
in
here
is,
is
what
we
hope
to
represent
as
a
back-end
capability
in
the
future.
H
H
H
And
then
there's
the
backend
capability
status,
and
that
will
be
this
I
didn't
really
flesh
this
out
too
much
at
this
point,
but
it'll
be
a
an
array
of
conditions
similar
to
this
status
and
all
of
the
Gateway
API
statuses.
H
H
Using
the
API
that
I
described
to
look
something
like
this
and
I
did
put
the
wrong
name
here.
I'll
have
to
update
that
the
name.
There
should
be
this
name
private
service,
but
the
re-encrypt
information
is
here.
H
And
and
then
there's
just
a
note
about
implementers
of
tls3
encrypt
would
have
to
check
for
these
back-end
capabilities
that
share
the
same
back
end
name
and
backend
type
as
the
targeted
service
service
to
discover
the
capabilities
fact
that
they'd
need
to
actually
perform
the
re-encrypt
as
as
it
moves
as
it
is
delivered
to
the
service.
H
Probably
the
the
file
system-
that's
mounted
for
this
capability
or
yeah
I,
don't
I,
don't
I,
don't.
This
is
just
an
example.
This
could
be
changed
for
sure.
D
I
have
a
question
exactly
on
this
subject:
I
mean
that
that
was
a
problem
we
have
with.
With
this
the
feature.
Let's
say
you
have
a
service
in
your
namespace
a,
and
you
defines
these
background
capabilities.
D
Any
color
in
any
namespace
is
somehow
required
to
encrypt
two
in
order
to
to
connect
to
that
particular
workload,
but
they
will
not
have
access
to
the
secret,
because
each
of
them
would
have
a
different
secret,
of
course,
because
it,
you
know
different
file
system
different,
so
how?
How
does
it
work
and
how
does
the
key
distribution
Works?
How
would
the
client
get
the
keys
that
is
allowed
normal
in
history?
We
use,
you
know,
workload,
identity
which
triggers
different
from
each
client,
and
we
don't
have
those
those
heels.
D
But
if
you
allow
anyway,
I'll.
H
Ask
your
answer
this:
this
could
be.
This
could
be
a
reference
to
a
secret
as
well
there
it's.
It
is
just
a
string.
Yeah
I
just
defined
it
as
a
string,
so
it
could
be
a
reference
to
a
secret.
If
you
want.
A
C
Others
this
does
bring
up
an
interesting
question,
which
is
that
usually
it's
like
what?
C
What
is
the
certificate
here
identifying
like?
Let's
say
it's
an
identity?
Wouldn't
it
be
this
the
client
of
not
the
service
itself,
but
the
service
is
the
end
point
it.
This
like
question,
make
sense
like
if
I
am.
Let's
say
this
is
like
a
website
that
client
cert
is
not
the
property
of
the
website
that
I'm
going
to,
but
the
property
of
me
who's
accessing
if
it's
a
clients
or
so
we
just
need
to
make
sure
that
foreign
on
the
right
end
of
the
communication
that
we're
describing.
D
So
maybe
I
spoke
when
I
when
I
asked
a
question
out
here,
even
if
you
use
secrets
and
secret
life
and
everything
else,
the
problem
is
that
all
clients,
in
all
the
namespaces,
from
whatever
they
are
calling,
would
need
to
have
access
to
this
object.
D
So
either
you
require
that
each
client
has
exactly
the
same
secret
name,
the
same
name
in
each
name
space,
or
this
is
a
way
to
for
each
clients
to
access
a
single
secret
which
kind
of
defeats
the
purpose
of
I
mean
because
if
too
many
people
have
to
seek,
it
is
no
longer
Secret.
D
So
normally
it's
spiffy,
Identity
or
or
so
so
some
identities
that
each
client
has
that
would
be
used
as
client
certificate.
So
if
you
require
client
certificates,
you
need
client
to
have
a
private
key
and
certificate
which
again
in
history,
it's
a
spiffy.
You
know
workload,
identity
and,
in
many
other
cases,
I'm
inspiring
many
solutions
or
something
that
is
provisioned
by
client
to
other
means.
But
it
cannot
be
something
that
is
fixed
and
and
decided
by
the
provider
how
you
are
going
to
store
as
a
client
as
a
private
key
and
what
certificate
you
have.
C
I
guess
like,
even
if
you
don't
use
workload,
identity,
I'm,
curious
Candice
for
your
use
cases,
whether
or
not
this
works
for
all
your
use
cases,
because
what
this
is
saying
is
that
anyone
who
accesses
your
service
ends
up
using
that
client
certificate,
which
seems
to
be
talking
about
like
the
end
of
the
community,
like
the
destination
versus
the
source,
which
is
seems
to
be
a
more
natural
fit.
H
Right
so
I'm
getting
that
we
need
to
actually
Define
what
each
of
these
things
is
and-
and
maybe
even
add,
some
more
Fields
here
I
was
worried
when
I
first
started
this,
that
we
were
either
going
to
need
to
make
it
so
specific
that
some
implementations
wouldn't
be
able
to
use
this
and
I
kind
of
wanted
to
make
it.
You
know
less
specific
than
that,
but
I
I
went
this
way,
enlisting
out
some
specific
fields,
but
I
didn't
Define
them,
hoping
that
that
this
would
cover
all
the
optional
Fields.
H
Testing
kind
of
implementation,
yeah.
C
So,
like
one
thing,
one
thing
that
would
be
good
is
in
the:
if
you
go
in
the
goals
is
to
map
out
some
topologies.
For
example,
I
can
see
something
where
you
might
have
two
gateways
that
access
the
same
service
and
each
Gateway
wants
to
use
its
own.
Let's
say
its
own
identity,
but
what
that
really
translates
to
after
talking
about
certificates
is
that
they
actually
use
their
own
unique
certificates
like
Gateway
a
will
have
a
certificate.
C
C
A
I
think
a
unique
client,
her
Gateway
and
that
specific
use
case
yeah
yeah
I-
do
want
to
do
a
time
check
here,
I
we
we
are
already
over
time.
Thank
you
so
much
for
presenting
this
Candace
and
getting
this
Gap
together.
There
is
a
PR.
Anyone
can
follow
up
with
that
discussion
on
the
pr
or
in
slack
wherever
is
easiest,
and
hopefully
we
can
keep
this
moving,
but
thanks
again
Candace
for
getting
it
started.
A
A
Thanks
so
much
and
with
that
have
a
great
week
and
we'll
talk
to
you
next
week,.