►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20221121
Description
SIG Network Gateway API Bi-Weekly Meeting for 20221121
A
B
A
Added
something
to
the
agenda,
but
I
know
he's
not
here
today
and
I'm
actually
not
sure
what
he
means
by
a
pair
programming
or
tooling
meeting
so
I
don't
know
if
anyone
else
has
any
contacts.
Otherwise
we
may
just
move
on.
C
Yeah,
we
should
also
do
the
usual
Mrs
kubernetes
meeting
need
to
abide
by
the
code
conduct
please
you
know.
In
short,
please
be
nice
to
each
other
for
the
record.
C
Yeah
so
yeah
I
think
that
yeah
we
need
to
wait
for
Shane
to
come
back.
We
might
just
need
to
carry
that
one
forward
for
a
couple
of
weeks
and
talk
to
Shane
about
that
when
he
comes
back.
That
means
that
we
are
on
to
let's
talk,
video.
A
The
short
story
here,
if
you
want
just
a
high
level
summary,
is
that
the
version
of
the
API
we
have
right
now
is
near
identical
to
what
we
will
release
as
vo60.
That
is,
I
I
feel
pretty
confident
in
saying
that,
with
that
out
of
the
way,
we
still
have
some
formalities
to
work
through
and
a
a
whole
bunch
of
work
to
actually
get
the
release
out.
So
let's
talk
about
everything
involved
there
now,
first
up
I
have
a
changelog
PR.
A
This
is
very
much
work
in
progress,
but
it
helps
at
least
highlight
the
differences
that
I'm
aware
of
this
needs
to
be
cleaned
up,
grouped
and-
and
you
know,
made
something
that
is
easier
to
understand
and
and
for
for
anyone
that
might
not
have
been
as
involved
with
these
changes.
But
this
is
basically
just
the
results
of
running
one
of
our
scripts
to
generate
release,
notes
and
grouping
things
together.
A
If
there's
anything
that
you're
aware
of
that
is
not
included
in
this
changelog,
please
please
let
us
know,
but
this
at
this
point
is
primarily
just
existing
to
ensure
that
we
have
the
full
scope
of
things
covered
in
our
changelog.
It
will
be
cleaned
up
soon
enough.
A
The
other
thing
on
Friday
I,
we
started
the
Gateway
API
vo60
review
for
anyone
who's
not
really
familiar
with
our
process
and
and
how
things
work.
We
as
Gateway
API
maintainers,
try
to
get
the
API
to
a
point
that
we
believe
is
ready
to
for
release,
and
then
we
send
it
off
to
Sig
Network
API
reviewers,
in
this
case
it's
Tim
and
Cal,
who
are
going
through
the
API
and
running
through
everything
for
with
their
you
know,
API
reviewer
perspective
that
are
a
little
more
disconnected
to
try
and
see.
A
What
those
look
like
in
any
kind
of
high-level
feedback
and
then
just
ask
how
and
Tim
to
actually
run
through
the
pr
that
has
the
full
diff
and
go
into
an
in-depth
review
so
I,
just
for
the
sake
of
completeness
I
created
a
few
slides
just
that
this
is
just
what
we
went
through
on
Friday
there's,
nothing
particularly
notable
in
here,
but
just
if
it
may
be
an
interesting
way
to
see
what
is
actually
changing
in
this
release.
A
A
few
few
notes
in
here
but
anyway,
that
is
that's
what
we
presented
and
walk
through
and
then
have
some
meeting
notes
here
as
well
for
General
back
and
forth
discussion,
whatever
on
whoever
could
make
it
just
I,
don't
think,
there's
anything
actionable
in
here.
It's
just
maybe
helpful
to
understand
the
scope
of
the
meeting
in
just
any
top
level
feedback.
A
A
We
can
use
I
I'll
speak
for
myself
and
say
we
can
use
a
lot
of
help
actually
responding
to
these
comments.
So
especially,
if
you
see
some
of
these
that
that
just
seem
like
oh
I
could
fix
that.
You
know
there
are
some
of
these
that
are
fairly
straightforward.
You
know
it's!
It's
not
clearly
worded!
Well,
that's
great!
If,
if
you
can
take
it
make
a
PR
make
it
make
this
better.
Just
please
comment
and
say:
hey
I
can
work
on
this.
That
would
be
amazing.
C
A
lot
of
very
small
sort
of
knit
style
pickups
that
that
we
need
to
fix,
but
like
they're,
not
they're,
not
complicated
or
hard
fixes
that
require
a
lot
of
familiarity
with
everything.
That's
going
on
yeah.
A
D
A
Yeah
just
think
think
of
this
PR
as
a
whole
host
of
tiny
good.
First
issues.
You
can,
you
can
combine
them,
however,
you
want,
but
if
you
want
to
work
on
these,
please
like
add
a
comment
on
the
things
saying:
hey
I'm
gonna
take
this
and
we'll
leave
it
for
you.
C
C
But
if
you
want
to
do
it
like
it's
cool
but
like
we
are
on
a
bit
of
a
clock,
so
you
know,
if
you
want
to
do
it,
that's
fine,
but
put
your
name
down
soon
and
and
and
grab
it
otherwise,
probably
next
week
sometime
when
we've
had
less
when
we
don't
have
the
meetings
and
there's
less
going
on
unless
people
are
around,
I
will
get
cracking
on
PRS
to
fix
these.
If
no
one
else
has
done
it
already.
A
Yeah
yeah,
a
big
plus
one
I,
mean
I
I.
Think
with
all
these
things,
we
are
just
trying
to
do
everything
we
can
to
get
a
release
out.
We
we
are
so
close
at
this
point.
We
just
want
to
get
this
release
out.
I'd
agree
with
what
you're
saying
like
these.
None
of
these
are
huge
breaking
changes.
Any
you
know
these
are
just
bits
of
cleanup.
A
That
I
think
will
be
will
be
helpful
with
that
said,
there
are
a
few
things
that
require
a
bit
more
help
and
thought
one
of
the
things
that
we
at
least
need
to
document.
Certainly
in
the
release
notes,
but
probably
more
broadly,
is
what
we
plan
to
do
with
reference.
Grant
I
think
that
everyone's
okay
with
reference
Grant
going
to
Beta
but
want
want
to
plan
for
what
does
it
look
like
when
reference
Grant
goes
Upstream,
which
seems
like
the
most
likely
path
for
it
after
this?
A
So
once
it
becomes
a
core
kubernetes,
Upstream
API?
What
do
we
do
with
it
in
inside
of
Gateway,
API
I?
Think
at
a
high
level?
That's
going
to
be
that
we
keep
track
of
the
crd
as
long
as
our
version
support
window.
It
requires
right.
So
we
said
we
support
five
trailing
kubernetes
versions,
which
means
we're
going
to
hold
on
to
this
reference
Grant
TRD
for
a
while,
but
at
some
point
it's
going
to
drop
off.
C
The
big
Advantage
there
is
that,
when
it
goes
Upstream
that
the
implementers
who
are
in
this
meeting
won't
need
to
implement
the
behavior,
because
the
API
server
will
implement
the
behavior
like
the
yeah
is
it
is
that
the.
A
Idea,
I
wish
we
could
make
it
quite
that
generic
I
don't
know
that
we
can
even
do
that.
I
think
it
I
I
think,
unfortunately,
maybe
maybe
that
that
that's
the
dream
right
like
yeah
I,
was
talking
with
someone
at
kubecon
about
like.
Could
we
do
a
custom
authorizer
there's
a
maybe,
but
in
any
case
when
it
goes
Upstream,
it
will
be
something
that
eventually
leaves
Gateway
API
the
project
and
and
moves
on,
maybe
implemented
centrally
I
don't
know,
but
that
would
be
very
cool.
C
Yes,
I
mean
that's
the
dream
right
like
did.
We
make
it
to
the
reference
Grant
as
part
of
the
core
apis
and
that
you
don't
need
to
worry
about
in
the
same
way
as
our
back
is,
and
you
don't
need
to
worry
about
you
just
basically
say
if
the
reference
Grant
isn't
there,
then
the
API
server
is
like
no.
You
can't
make
that
reference
or
something
like
that,
but
it
is
complicated
to
equipment.
C
C
C
So
yeah,
that's
that's!
The
idea
is
that
it's
pretty
generic
spec
that
you
can,
it
has
a
it
has
a
it
has
like
a
you
put
it
in
the
same
name
space
as
the
thing
that
it's
granting
reference
access
to,
and
it
has
kind
and
a
a
client
selector
only
at
the
moment,
and
then
it
has
the
from
selector
has
a
kind
and
a
namespace
selector.
C
So
so,
basically
you
can
say
you
say:
I
want
to
allow
references
to
this
secret
from
gateways
in
the
secure
namespace
or
something
like
that.
But
yeah.
You
could
conceivably
also
use
it
for
I
want
to
allow
access
to
this
secret
from
you
know,
from
Ingress
objects
in
in
this
other
namespace,
or
something
like
that
too.
Conceivably,
it's
not.
That
is
not
part
of
the
current
spec,
but
like
that's
you
could
it's
designed
to
be
generic
like
that,
but
it's.
B
D
Was
sorry,
thank
you
sorry.
So
I
was
thinking
like
you
can
possibly
reference
like
crds
like
yes,.
C
But
so
the
idea
here
is
that
so,
when
you're
making
a
cross
namespace
reference,
unless
both
ends
of
the
cost
name
space
reference
agree,
then
you
then
it's
not
safe
like
so.
If
I
have
a
Gateway
in
one
namespace
and
it
wants
to
refer
to
a
secret
in
another
namespace,
unless
the
secret
is
sort
of
says,
I
allow
access
to
that
gateway.
C
Then
it's
not
a
safe
reference,
because
because
the
like,
the
person
who
owns
the
secret
needs
to
say
I'm,
okay
with
this,
and
so
this
is
like
a
a
formalized
contract
way
of
you
doing
that,
and
so
the
intent
is
that,
yes,
absolutely
you
can
use
it
for
like
granting
reference
access
to
a
crd
from
some
other
CID
totally
in
the
Gateway
API,
though,
we've
actually
not
done
that
for
some
things,
because
between
Gateway
and
HTTP
route
you
can
do
those
across
namespaces,
but
because
we
have
control
of
the
spec
yeah.
C
We've
actually
just
put
those
stuff
that
stuff
inside
the
spec.
So
for
our
Gateway
HTTP
route,
the
HTTP
route
says
I
want
to
attach
to
this
Gateway
and
the
Gateway
has
a
thing
called
allowed
routes
inside
it.
That
says,
I
will
only
accept
routes
that
look
like
this,
and
so
that's
the
same
two-way
handshake.
So
you
don't
need
a
reference
Grant
in
that
case,
and
so
reference
screen
is
kind
of
intended
to
be
used
for
where
you
don't
have
control
over
one
side
of
the
spec.
C
You
know
so
or
both
sides,
and
so,
if
you
have
control
over
one
side
of
the
over,
you
know,
both
sides
of
the
spec
I
would
recommend
doing
something
more
like
with
what
we've
done
with
HTTP
router
Gateway,
where
one
refers
to
the
other
and
the
other
one
makes
a
makes
a
lock,
basically
or
a
hole
that
that
sort
of
validates
what
ones
can
be
referred
to,
and
it's
completely
valid
to
have
that
be
like
anything.
It's
fine
but
like
the
default
should
be
more
secure
than
anything
is
fine.
C
You
know
you
should
you
should
have
to
make
take
some
positive
action
to
say:
I
will
allow
connections
from
anything
in
any
namespace
like
you.
Should
need
to
do
that
because
that's
a
big
deal
and
you
shouldn't
do
it
without
thinking
about
it?
Does
that
make
sense.
D
I
think
I
think
at
first
I
was
just
thinking
within
the
same
namespace
like
referencing,
a
resource
like
another
resource
like
that
right,
Custom,
Custom
resource
that
definition
within
the
same
namespace,
but
I
think
when
you're
talking
about
cross
namespace
I
haven't
thought
about
that.
So
are
you
saying
that
reference
grants
can
allow
across
namespace?
But
are
you
supposed
to
have
like
a
like
an
a
reference
Grant
on
the
other
side
of
the
namespace
that
says
it's?
Okay,.
C
Yeah,
yes,
so
like
so
you
within
the
same
namespace,
we
have
generally
assumed
that,
within
the
same
namespace
like
the
namespace
is
kind
of
the
smallest
unit
of
trust
you
have
in
kubernetes
right,
like
you,
can't
really
segment
things
inside
a
namespace
and
so
there's
no
point
having
a
reference
group
inside
a
namespace,
because
more
than
likely
the
person
who
controls
the
namespace
controls
everything
in
the
namespace.
So
there's.
D
C
Yeah
and
then
so,
but
between
namespaces,
there's
no
way
to
know
for
sure
which
owner
controls
each
namespace,
and
so
so
you
need
to
have
like
the
thing
that's
sent
that
it
originates.
The
cross,
namespace
request
needs
to
agree
with
the
thing
that
is
receiving
the
cross,
namespace
request
and
that
needs
to
sort
of
say
yes,
I'm.
Okay,
with
this
connection.
C
No,
so
the
the
intent
here.
So
if
you
look
at
this,
the
diagram
that
Rob's
got
off
on
the
screen,
the
HTTP
route
can
refer
to
a
back
end
right
in
another
namespace,
but
when
so
the
HTTP
router
doesn't
need
a
reference
Grant
to
do
that
because
it's
it's
it's,
the
the
reference
is
outbound
you're
right.
C
The
HD
period
is
saying:
I
want
to
use
this
back
end
and
it
happens
to
be
in
another
namespace
right,
so
they
should
be
around
as
kind
of
making
a
request
to
be
able
to
use
the
service
in
another
namespace.
Well,
the
reference
Grant
does
is
allow
the
owner
of
that
service.
To
say
that
request
is
okay.
Yes,
I
agree
to
this,
and
so
you
only
need
it
like
where
the,
where
the
reference
points
to
right.
So
that's
why
it's
called
reference
Grant.
Is
you
grant
access
to
that
thing?
C
Makes
sense
yeah
yeah,
that's
fine,
like
yeah,
like
I,
completely
get
it.
This
is
very
confusing
and
hard
to
understand.
Part
of
what
I
want
to
do
is
I
actually
had
I
had
a
talk
accepted
to
keep
playing
an
a
that
I,
unfortunately,
couldn't
do
because
I
wasn't
there,
but
which
was
like
explaining
reference
Grant.
Why
we
built
it
this
way
that
that
literally,
the
reason
I
could
tell
you
all
this
off.
C
The
top
of
my
head
is
that
I
still
wrote
The
Talk,
so
I
actually
have
a
talk
with
slides
and
stuff
that
I'm
hoping
to
give
it
keep
fun
of
you
about
this
about
literally
this,
but
probably
before.
In
the
absence
of
that,
it
probably
would
make
sense
for
us
to
do
a
Blog
about
it,
maybe
Rob
or
something
like
that.
That
summarizes
the
talk,
yeah
yeah,
so
to
clear
up
this
sort
of
thing,
because
it
is
very,
it
can
be
very
hard
to
understand
when
you
haven't
seen
it
before.
A
Yeah,
so
this
is
intended
to
be
a
generic
way
to
solve
it,
and
the
reason
we're
talking
about
upstreaming
it
and
moving
it
into
core
kubernetes
is
that
Sig
storage
also
has
a
very
similar
problem
and
they
also
want
to
use
reference
Grant,
and
it
doesn't
make
sense
for
them
to
use
a
resource
that
is
in
gateway.networking.katesio.
You.
C
Yeah
no
worries
feel
free
to
hit
me
up
with
more
questions
about
this
on
slack
or
something.
If
you
have
them,
if
you
think
of
them
later
well,
this
is
kind
of
like
probably
slightly
more
my
baby
than
robs
yeah
Rob's
done
a
lot
of
great
work
on
it,
but,
like
you
know,
I
think
that
yeah
like
this
is
probably
sliding
on
my
thing.
So
yeah
yeah
like
I'm,
always
happy
to
explain
this
to
people.
A
Yeah
yeah,
likewise
Nick
and
I
are
in
different
time
zones.
So
if,
if
Nick
is
offline,
I'm,
probably
online
or
vice
versa-
so
definitely
don't
hesitate
to
reach
out
to
either
one
but
agree
that
that
Nick
has
done
a
lot
of
awesome
work
with
reference
Grant.
C
I
should
probably
just
take
this
moment
to
publicly
say
that
a
lot
of
this
work
on
reference
Grant
is
actually
based
on
stuff
that
Joe
Peter
and
Dave
Chaney
did
in
Contour
with
the
Taylor
certificate
delegation.
I
need
to
give
credit
where
credit
is
due
and
I'm
standing
on
the
shoulders
of
giants
on
this
one.
D
A
Yeah
so
I'll
keep
on
running
through
here,
so
we
were
just
covering
the
reference
Grant
to
Upstream,
but
the
the
next
one
I
wanted
to
cover
was
a
bigger
question
about.
If
reference
Grant
really
means
spec
well,
it
kind
of
kind
of
it's
a
two-phase
question
of
doesn't
need
status
and
if
it
doesn't
need
status,
why
do
we
have
spec
so
for
any
anyone?
Who's
hasn't
looked
really
deeply
into
reference
Grant.
A
You
may
see
that
we
have
a
spec,
and
then
we
have
this
common
doubt
block
saying
status
would
go
here
if
we
did
it,
but
we're
not
sure
what
needs
it
and
the
the
broader
and
generally
in
kubernetes
apis
you,
you
follow
a
spec
and
Status
pattern
where
spec
is
the
desired
configuration
and
status
is
basically
away
from
the
underlying
implementation.
To
tell
you
what's
happened.
Reference
Grant
is
in
this
really
weird
gray
area
and
we're
not
sure
what
to
do
so.
A
You
can
make
the
argument
that
it's
really
similar
to
our
back
in
kubernetes,
where
it's
like
a
roll
resource
and
that
does
not
have
spec
or
status.
You
could
make
another
argument
that
it's
more
like
Network
policy,
in
which
case
it
didn't
start
with
spec
and
status,
but
we're
working
on
adding
status
because
it
was
deemed
valuable.
That's
a
bigger
question
and
that's
kind
of
one
of
the
things
that
came
out
of
API
review
that
I.
A
Just
if
you
have
thoughts,
I
recommend
adding
them
to
the
pr
I'm,
not
sure
I,
don't
I,
don't
think
this
is
a
blocker,
but
it
would
be
good
to
make
sure
we
have
a
very
clear
reason
and
rationale
for
why
we
have
what
we
have
in
the
API
today
before
we
go
to
Beta,
because
you
know
I
think
the
most
significant
part
of
v060
is
that
we're
trying
to
graduate
reference
Grant
to
Beta
and
then
finally,
we
have
a
ton
of
util
kind
of
pointer
functions
in
our
API
right
now,
Cal
asked
you
know:
could
we
just
use
generics
instead
of
recreating
the
same
code,
a
million
times
I?
A
D
A
Yes,
yeah
I
do
want
to
make
sure
I,
don't
know
how
many
implementers
are
on
the
call
right
now,
but
if
you're
working
on
an
implementation
of
this
API,
do
you
find
the
various
util
pointer
functions?
We
have
in
the
API
useful.
C
B
Yeah
I
think
we
found
it
found
them
useful
in
Contour.
I
think
we
might
have
Steve
might
have
from
might
have
contributed
a
few
of
those
helpers
just
because
it's
nice
to
have,
but
not
a
show
stopper,
but
we
just
figured.
We
were
rewriting
helper
functions
all
over
the
place,
so
we
figured
other
people
probably
could
use
them.
C
Is
that
Contours
on
go
118
already
right?
So
there's
no
one,
there's
no
issue!
If
we
moved
to
generics.
B
C
B
C
A
A
I
I,
don't
know,
I.
Think
in
this
case,
I,
don't
know
if
our
util
point
and
I
think
this
actually
lines
up
with
what
what
was
in
chat
as
well,
but
I.
Don't
think
that
anything
in
our
util
pointers
has
actually
been
released
yet
so
we
can
probably
just
so.
A
Yeah,
okay,
but
with
all
that
said,
I
I
want
to
move
on
to
the
060
Milestone
quickly,
but
before
I
get
there.
I
am
not
100
sure
that
we'll
get
a
release
candidate
out
this
week.
I
know
that
was
kind
of
a
goal
of
mine
that
I
stated
last
week
either
way.
I
feel
very
confident
if
you
are
using
this
API
and
implementing
this
API
I
would
I
would
consider
the
its
current
state
right
now
as
roughly
release
candidate
worthy.
A
A
A
Cool
all
right,
I'm,
just
gonna,
keep
on
moving
through
these,
then
the
060
Milestone
is
nearly
done.
Thank
you,
I
think
the
very
last
one
is
this
PR
and
I
think
we
have
everyone
on
the
call
that
is
worth
that
could
help
discuss
this
I
had
a
question
and
I
think
there
was
good
good
back
and
forth,
and
maybe
it's
easier
just
to
discuss
on
this
call,
since
this
really
is
the
last
thing
on
the
agenda
I'm
trying
to
I.
B
From
the
bullets
in
the
in
the
Gap
they
looked
like
they
mentioned.
When
you
have
incompatible
filters,
then
you
should
add
a
new.
Where
is
it
specifically
an
era.
C
C
C
Then
there's
no
config,
because
there's
no
other
rules,
and
so
it's
not
it's
completely
invalid,
so
that
one
you
can
just
not
accept
it,
but
for
if
there's
more
than
one
rule,
then
then
we're
in
this
the
space
where,
where
you
need
a
like
the
rule,
that's
in
there
that's
valid
should
go
into
the
into
the
data
plan.
So
you've
got
some
config
and
so
the
the
invalid
filters
one
rule
will
just
get
dropped.
C
So
we
need
some
way
to
signal
to
people
that
you're,
in
that
your
whole
rule
has
been
dropped
because
of
invalid
filters,
because
the
filters
are
incompatible
and
so
that
the
only
way
that
we
can
do
that
is
to
have
a
like
another
condition,
like
a
condition
that
does
that
and
I.
Don't
think
we
have
a
condition
that
covers
like
that.
We
don't
have
like
a
generic
a
rule.
A
rule
in
this
is
invalid
because,
because
of
some
reason.
A
So
I
think
what
you're
saying
is
that
you
want
a
new
condition
that
covers
a
partially
valid
state
for
a
route,
and
it
says
this
is
partially
valid
or
partially
invalid.
Whatever
we
want
to
say
and
then
at
the
same
time,
you
want
a
new
reason
and,
like
the
reason
would
be
into.
C
C
You
know
that
you
want
those
to
be
true
and
then
it's
okay
to
have
extra
conditions
that
are
negative
polarity
that
if
they
are
present
and
true,
then
there's
some
error
and
they
can
go
away
when
the
when
the
error
is
no
longer
present.
C
And
so
the
idea
here
is
that
you,
we
have
more
specific
error
conditions
that
that
are
only
present
when
there
are
specific
problems
and
so
yeah
like
I,
think
we
have
a
couple
of
those
we
have
result.
Drifts
is
not
a
good
example
here,
because
that's
actually
positive,
polarity,
I
think,
but
like
the
idea,
the
idea
is
that
there's
sort
of
more
specific
error
conditions
that
can
come
and
go,
and
this
one
is
feels
like
it's
a
big
enough
deal
that
it
warrants
like
a
definitive
like
extra
thing.
C
That's
not
just
a
message,
a
reason
and
a
message
unaccepted,
because
you
can't
do
it
that
way,
because
partial
probability
and
so
yeah
I'm
not
too
worried
about
having
a
few
extra
conditions
for
specific
problems
in
the
same
way
that
node
has
conditions
for
like
disk
pressure
memory
pressure.
C
You
know,
like
they're,
very
sort
of
specific
error,
things
that
you
see,
and
so
the
node
object
currently
has
like
a
node
ready
or
a
ready
condition,
and
then,
if
that's
false,
then
a
lot
of
the
then
a
lot
of
the
time
it'll
be
false,
because
one
of
the
other
error
conditions
is
true.
Like
you
know,
Doc
is
not
running.
A
I
yeah
I
think
so
I'm
I'm
a
little
concerned
that
we're
going
to
end
up
with
just
a
really
long
list
of
conditions.
The
another
concern
I'd
have
is
that
within
incompatible
filters.
A
A
E
D
C
A
C
Yeah
yeah
incompatible
filters
feel
like
you're
right
incompatible.
Filters
feels
at
the
level
of
something
that
could
be
a
reason.
Maybe,
as
you
said,
the
correct
approach
here
is
that
we
have
a
condition.
That's
like
you,
rule
invalid,
like
or
yeah
a
rule
air
up
or
something
like
that.
Yeah
and
we
say
you
know
incompatible
filters
and
then
the
message,
and
then
we
say
oh
for
this
condition.
The
message
needs
to
tell
you
which
rule
it
is
or
something
like
that.
A
C
B
Realistically,
we
could
probably
also
not
focus
on
this
for
zero
six,
because
this
is
specifically
around
the
incompatibility
between
URL
rewrite
and
redirect
like
that.
What
the
bullets
in
the
GIF
we're
talking
about,
but
I
mean
there
could
be
other
cases
for
implementations
where
other
filters
are
incompatible
or
in
some
sense
or,
like
you
said
in
the
comments
like
what
was
it
like
header
rewrite
and
redirect
this
might
even
make
sense.
B
C
Don't
know
if
you
put
if
you
put
two,
if
you
put
two
header
ads
or
something
like
that,
you
know:
that's
that's
invalid,
but
I,
don't
know.
I
can't
remember
what
things
we
have
to
describe
that
at
the
moment.
So
it
could
be
that
this
is
this.
Maybe
this
is
worth
us
being
a
little
taking
a
step
back
and
doing
something
a
little
bit
more
clear
in
the
longer
term
about
what
we
do
about
partially
valid
rules.
C
C
C
But
you
know,
but
there's
probably
there's
probably
a
bunch
of
other
cases
that
we
need
to
have
partially
valid
tests
for
and
then
this
would
be.
You
know
if
we
go
through
and
enumerate
the
ways
in
which
a
rule
can
be
invalid,
but
that
if
there
are
other
rules
that
it
doesn't
make
the
route
invalid,
then
that
that
would
be
a
good
thing
for
us
to
spend
a
little
bit
of
time
on
status
for,
but
that's
kind
of
additive
status.
C
If
you
know
what
I
mean
like
right
now,
it's
just
not
clearly
defined,
rather
than
so
I
mean
you
know
rather
than
it's.
This
is
just
something
we've
missed,
rather
than
something
that
we
need
to
fix.
If
you
sit
on
like
it's,
not
something
not
that
we
need
to
change
what
we
have
already
so
much
as
we
need
to
clarify
and
add
extra
Behavior.
So
it
probably
in
my
mind.
C
Yeah
so
Mikaya
says
that
incompatible
filters
feels
a
lot
like
the
listeners,
conflicted,
condition,
type
yeah
and
that's
exactly
what
it's
intended
to
be
like.
It's
like
something
is
wrong,
so
you
know
here's
some
more
information
you
about.
What's
wrong,
you
know,
like
the
you
know,
it
didn't
it's
still
attached,
but
there's
something
wrong,
and
so
you
need
to
know
about.
That
is
the
sort
of
the
use
case
we're
trying
to
go
for
here,
but
it
probably
does
like
in
order
to
stem
the
tide
of
the
problem
that
Rob
is
talking
about.
A
I'd
love
to
get
to
a
state
where
we
have
a
single
condition
that
can
be
used
on
all
route
types.
That
is,
you
know
partially
valid
or
partially,
and
you
know
whatever
that
partial
validity
condition
and
then
each
route
type
can
have
different
reasons
for
that:
yeah
yeah,
that
that
seems
like
a
good
goal,
but
I
I,
I,
think
I
agree
with
what
everyone's
saying
here.
This
is
a
nice
to
have,
but
not
a
firm
requirement
for
o60
I.
B
B
Yeah,
and
and
in
the
in
terms
of
conformance
and
conformant
environments
that
whole
discussion,
this
would
have
to
get
you'd
have
to
not
be
running
the
web
hook,
the
validating
workbook,
to
specifically
hit
the
case
where
we
write
and
redirect
Carlisle,
oh
yeah,
very
true.
So
this
is
kind
of
like
a
weird
Edge
case
anyway.
C
So
yeah
right!
Okay!
Yes,
yes!
So
this
also
comes
under
the
discussion
of
you
know.
How
do
we
handle
like
when
you're
not
running
the
web
hook,
and
what
do
you
do
and
and
stuff
like
that
so
yeah,
this
one
yeah,
definitely
is
good
to
push
back.
Then,
of
course,
there's
a
whole
thing
there
as
well.
A
I
think
that
means
we're
going
to
consider
our
Milestone
complete.
We
can
work
on
actually
finalizing
that
later
today,
but
it
sounds
like
we're
good
then,
with
this
I
appreciate
that,
for
here,
I
mean
it
actually
seeing
this
spelled
out
helped
clarify
where
our
gaps
are
and
I
think
we
can
just
build
on
this
too.
You
know
decide
what
that
new
partial
validity
condition
actually
looks
like,
but
it's
probably
not
too
far
off
from
this
cool.
E
Can
you
see
me
now
yep
yeah?
This
is
like
a
you'll.
See
me
around
here.
Presenting
key
native
use
cases
often
so
like
with
the
backing
capabilities
kind
of
getting
Revisited.
E
I
need
to
do
some
due
diligence
myself
to
see
what's
Landing
versus
what
we
need
for
key
native,
so
I'll
revisit
that.
But
this
is
the
other
use
case.
That's
pretty
important,
like
we
have
kind
of
like
a
cluster,
only
services
that
are
accessible
externally
in
the
cluster,
but
we
also
do
need
the
L7
load,
balancing
capabilities
there.
The
traffic
splitting
Etc
et
cetera
so
I'm
just
kind
of
curious
about
people's
thoughts
and
how
best
to
move
sort
of
this
forward
like
does
it
need
a?
E
Like
is
there
anyone
interested
in
sponsoring?
Do
you
need
me
to
sponsor?
Even
though
I
don't
know
anything
about
implementing
the
apis
like
I
could
do
a
bad
gift,
and
then
that
could
be
a
starting
point
like
I,
don't
know
just
curious,
I
guess
like
what
a
this
might
be
more
of
a
meta
questions
like,
as
things
are
discussions,
what
promotes
them
to
sort
of
the
next
stage
and
then
what
promotes
them
further.
C
It's
all
a
bit
woolly
at
the
moment.
To
be
honest,
we
don't
have
a
formal
process
around
this
stuff,
yet,
but
I
think
I
think
the
the
request
you've
got
is
actually
pretty
like
a
pretty
reasonable
ask
for
like
a
change
like
it's
pretty
tightly,
scoped
like
it's,
okay,
I.
We
want
to
be
able
to
do
this.
C
It
feels
to
me,
like
usually
the
the
process
for
a
gap.
Is
that
we
sort
of
start
talking
about
hey.
Maybe
this
needs
a
gap,
and
then
someone
who
is
sort
of
wanting
to
push
it
starts
usually
a
Google
doc
that
we
use
for,
like
a
that,
you
sort
of
fill
out
from
a
gap
template
and
start
like
filling
in
some
of
the
sessions,
and
we
talk
about
it
on
there.
C
So
we
can
do
this
async
and
we
talk
about
in
a
couple
of
meetings
and
then
eventually
that
gets
turned
into
like
the
actual
get
PR
I.
Think
in
terms
of
this
specific
one,
like
I
said
in
the
issue,
it
seems
relatively
reasonable
to
me
that
we
that
we
make
the
address
field
like
a
domain
prefix
string,
so
that
people
can
add
you
could
add
like
canadies.io
slash,
you
know
cluster
cluster
or
something
like
that
and
then
that
everyone
else
would
know.
C
Hey
I
just
ignore
this,
because
it's
domain
perfect
string
and
then
you
can
that
wouldn't
let
you
prototype
like
how
the
how
the
thing
would
work
and
then
and
then
we
can
and
then
once
you've
sort
of
got
away.
One
of
the
once
you've
got
a
way
to
sort
of
say
hey.
This
is
this
is
how
we've
done
it.
This
is
what
it
looks
like
you
know:
I
propose
we
we
do
something
like
this.
C
We
take
something
like
this
into
extended
performance,
the
that
cuts
a
whole
bunch
of
like
bike
shading
time
on.
But
what
about
this?
But
what
about
this
like?
If
you've
got
an
implementation
and
you're
like
we've,
made
an
implementation,
here's
how
it
works,
here's
what
happens
and
then
it's
a
much
more
concrete
discussion
than
if
you
know
you,
you
don't
want
to
end
up
getting
involved
down
in
your
Gap
about
like.
C
But
what
do
words
mean?
You
know
it
which,
which
has
happened
quite
to
us?
Quite
a
lot
like
you
know
like,
but
what
is
what
does
it
mean
for
a
for
a
gateway
to
be
cluster
local
right,
like
you,
you
and
what
you're
doing
by
that
is
saying
in
our
implementation.
It
means
this
and
here's
here's
how
the
implementation
works.
Let
can
we
take.
Can
we
take
what
we've
got
here
and
make
it
extended
and
then
and
then
we
can
have
more
something
more
concrete
to
discuss.
C
We
definitely
have
it
happened,
but
backing
capabilities
is
a
good
example
of
this,
where
you
know
where,
like
I-
and
you
know,
a
few
of
us
have
talked
about-
had
talked
about
this
and
then
when
Candace
went
to
implement
it
like
it
seemed
reasonable
to
me.
But
then
there
were
a
whole
bunch
of
other
people
who
it
crossed
over
into
their
streams
and
had
sort
of
unanticipated
side
effects,
and
so
like
doing
something,
that's
pretty
tight.
Let's
go
to.
C
You
seems
good
I'm,
not
100
sure
what
the
validation
is
on
that
field.
At
the
moment,
if
it
doesn't
allow
a
domain
prefix
string,
then
there
is
an
API
change
to
say:
hey.
If
you
allow
a
domain
prefix
string,
then
we
can
go
away
and
try,
try
this
out
and
see
how
it
goes,
and
that
is
a
much
smaller
change.
C
That
I
think
is
much
more,
is
deliverable
pretty
quickly
not
in
the
o60
time
frame,
but
in
the
070
time
frame
for
sure
that
sort
of
feels
like
an
easy
place
to
start.
That
would
then
help
build
a
git,
but
we
can
also
just
go
with
the
full
Gap
thing
and
the
full
court
press
for
the
Gap
and
talk
about
it
in
a
document
and
stuff
as
well.
If
that's
what
you
prefer
to
do
wrong.
A
Yeah
I'd
agree
with
the
direction
you're
heading
here
of
you
know
that
for
Gateway
addresses
they're
present
in
Spec
and
status
in
Spec.
You
could
just
specify
you
know:
I
want
an
address
of
this
type
without
actually
saying
the
value
you
want
just
I
want
any
Val
any
address
that
is
of
this
type,
and
if
that
type
were
some
kind
of
domain
prefix
cluster
IP
that
was
broadly
understood,
I,
I'm,
99
sure
our
validation
right
now
allows
one
of
the
two
allow
listed.
A
You
know,
values
that
aren't
domain
prefixed
or
a
domain
prefix
value,
so
I
I
think
this
should
be
possible
in
the
API
today.
If
it's
not
it's
intended
to
be,
but
I'm
99
sure
it
already
is.
Please
definitely
let
us
know
if
not
I
think
that
that's
probably
the
best
way
to
test
this
out
is
to
try
it
with
that
with
that
kind
of
API
and
see.
If
that
makes
sense
to
you,
I
was
about
to
go
down
a
rabbit,
hole
and
I.
A
E
Yeah
I
guess,
if
we
I
guess
for
some
backstory
I
work
at
BMI,
so
Sanjay
wasn't
here
and
I
didn't
actually
contribute
to
well
I,
actually
don't
contribute
to
Contour
I've
worked
on
a
like
I'm
an
end
user
right,
not
a
English
implementer
would
I
approach
it
the
same
way
or
do
you
like?
Do
you
see
what
I'm
saying
like
the
Gap
makes
sense
the
what
you're
suggesting
makes
sense
if
I
actually
Implement
the.
C
E
C
Yeah
I
think
in
the
case,
where
you're
an
end
user
wanting
to
request
a
feature
like
this,
then
I
think
that
yeah
like
we
need.
Basically
we
need.
We
need
some.
We
need
to
talk
about
what
we're
trying
to
do
and
which
Implement
like
what
implementations
we'll
actually
be
able
to
do,
and,
of
course,
the
the
other
thing
that
we'll
need
to
talk
about
when
you're
doing
that
sort
of
design
without
an
implementation
already,
then
you
need
to
do
like
you
need
to
figure
out.
What
are
we
trying
to
do?
C
You
know
like
what
happens
with
an
implementation,
can't
do
a
cluster
IP
Gateway
because
you're
not
you
know,
for
some
reason,
you
can't
create
a
service
with
a
cluster
IP
or
whatever
unlikely
but
possible,
and
so
you
need
to
have
the
status
Loop
closed
there
to
be
like
what
happens
when
you
get
a
type
that
you
can't
handle
I
mean
that
having
anything
other
than
those
two
types
kind
of
requires
us
to
close
that
status
Loop
anyway,
and
so
you
know,
I,
don't
think
it's
a
big
deal
to
do
that,
but
yeah
that,
basically,
that's
I,
think
that's
it's
a
really
good
point.
C
We
haven't
had
a
lot
of
sort
of
end
user
feature
requests
as
yet,
and
so
that's
why
we're
like
I,
don't
know
what
to
do
here
and
so
I
think
it's
a
really
good
point
that
we
need
to
get
better
at
that.
C
A
Yeah
I,
don't
know
what
you
were
trying
to
say,
but
we
lost
you
into
a
roboty,
something,
but
maybe
drop
and
chat
I'm,
not
sure
Let
me.
Let
me
just
take
this
quick
opportunity
here
to
go
down
a
little
bit
of
a
rabbit
hole
that
came
out
of
the
start
of
our
review
yesterday.
A
That
seems
very
very
similar
to
to
this
concept
and
it
was
actually
initially
what
I
thought
was
being
requested
in
in
my
mind,
for
a
long
time,
an
end
goal
of
Gateway
API
has
been
to
become
the
the
next
service
front
end.
So
that's
you
know.
Many
people
have
thought.
Okay,
Gateway
API
is
the
next
generation
of
Ingress.
A
It
can
be
the
next
generation
of
service
type
load
balancer,
but
what
about
service
type
cluster
IP?
Could
it
be
that
service
front
end
we've
been
having
all
these
discussions
in
gamma
about
how,
as
service
is
really
two
things
right.
It's
it's
a
front
end
and
it's
a
grouping
for
a
bunch
of
back-ends,
and
that
makes
our
gamma
ux
a
little
funny
and
that
you're
attaching
to
a
service
front
end
and
then
forwarding
to
a
bunch
of
back-ends.
A
But
also
service,
so
it's
like
it
feels
kind
of
funny
and
a
big
bit
of
feedback
is,
you
know,
can
can
we
separate
that
out
so
one
of
the
things
that
came
up
in
that
was
really
this
this
section
here.
A
Could
we
abstract
all
of
this
away
and
split
service
out
into
new
types,
so
you
had
a
type
that
allocated
cluster
IPS
and
DNS
names.
Maybe
that's
two
different
types,
I
don't
know
and
service
would
automatically
create
those
when
you
create
a
service
it
maps
to
those
things,
but
it
would
also
be
a
way
for
any
other
API
such
as
Gateway
API,
to
allocate
a
cluster
IP
or
DNS
name
for
a
gateway
and
and
have
it
be
respected
across
everything.
This.
C
A
This
is
like
a
high
level
idea
that
came
out
of
the
gamma
discussion
about
you
know
what?
What
exactly
are
we
doing
when
we're?
Attaching
you
know
parent
ref
above
as
service,
and
then
back
in
ref
below
is
also
service.
You
know
that
that
feels
confusing
is
it?
Is
this
a
path
that
we
could
use
to
do
Gateway
of
cluster
IP
Gateway
class
cluster
IPM?
That
is
truly
generic
and
supported.
A
You
know
directly
by
kubernetes,
without
any
additional
implementation,
don't
know,
but
just
I
thought
I
would
bring
that
up.
It's
it's
in
the
notes
here,
but
just
if
anyone
sees
that
and
says
yes,
this
is
definitely
what
I
want
I.
You
know
I'd
love
to
get
that
discussion
going
more
broadly.
These
are
kind
of
longer.
You
know
these.
Take
you
know
Cycles
to
get
through
these
These
are
enhancement
Cycles.
A
This
takes
time
to
get
through,
but
I
think
it's
a
really
interesting
vision
and
I'd
love
to
see
it
happen,
but
it
would,
you
know,
be
easier
to
make
happen
if
we
had
a
broad
set
of
people
that
actually
wanted
this
and
had
use
cases
for
it.
So
it
it
sounds
like
this
thing
would
solve
your
specific
request,
but
it's
definitely
a
much
longer
term
thing
than
I.
Think
you
you
want
to
sign
up
for.
A
Weird
roboty
noise:
for
me:
sorry
how
about
now?
Oh
perfect,
we
can
hear
you
switch.
E
My
mic
I
guess
you're,
saying
that
this
cluster
IP
would
be
on
a
Portage
site.
Then
let's
go
through
the
whole
Capital
yeah,
we'll.
B
C
Yeah
yeah
that
one
that
one
was
like
a
wall
because
that's
sort
of
like
that
feels
like
it's
analogous
to
like
the
endpoint
to
endpoint
slice
transition
in
terms
of
like
figuring
out
an
API
and
making
it
so
that
API
server.
Does
it
all
for
you
and
handles
the
mechanics?
And
you
know
all
that
sort
of
stuff
but
yeah.
It
would
be
really
nice
if
we
could
do
it
because,
then
you
end
up
with
something
like
endpoint
slides.
C
A
A
The
way
that
we
were
talking
about,
first
of,
like
you
just
put
an
address
type
that
you
want
in
in
Gateway
spec,
is
something
that
would
rely
on
an
individual
implementation
to
do
a
thing
right,
so
it
would
be
I
I
need
to
make
a
feature
request
to
Contour
or
whoever
it
is
right,
whereas
this
much
longer
path
is
something
like
that
would
work
in
any
kubernetes
cluster
is
the
vision
for
it
right,
it's
something
that
is
built
into
kubernetes.
A
So
then
that
is
just
a
portable
generic
way
to
do.
I
think.
C
Yeah
yeah
well
right,
I
mean
right
now
you
can
do
like
a
cluster
IP
service
and
have
multiple
ports
in
the
cluster
IP
service,
that
forward
TCP
traffic
or
UDP
traffic
right
like,
and
you
specify
that
inside
the
server
spec
I
mean
as
as
we've
done
in
the
rest
of
this
we're
kind
of
trying
to
break
apart
that
you
know
enormous
chunk
of
config.
That
is
the
service,
the
service,
spec
and
split
it
up
into
separate
things
and
so
they'd,
be
you
know
what
you're
talking
about
here
is.
C
You
would
have
a
Gateway
of
cluster
IP
with
a
cluster
IP
instead
of
with
an
externally
visible
IP,
and
that
you
could
then
attach
TCP
routes,
UDP
routes
or
HTTP
routes
or
https
routes
too,
and
have
it
be
like
have
it
work
kind
of
like
a
I
mean
doing
so
doing
it
that
way
and
doing
it
with
cluster
IP,
basically
gets
you
the
mesh
functionality
like
gamma
wants.
C
You
know
for
HTTP
route
and
and
and
TLS
route
and
stuff
like
that,
and
then
it
also
gives
you
sort
of
a
more
east-westy
kind
of
way
to
handle
to
handle.
You
know
UTC
and
UDP.
C
Yeah
yeah,
like
I,
think
it
definitely
I,
know
I
know
why
you're
asking
for
it
Dave,
because
you
know
Kennedy
have
had
this
very
specific
use
case
where
you
want
cluster
IP
and
you
want
to
be
able
to
help
in
things
and
stuff
like
that,
and
so
yeah
I
I
get
what
you're
asking
for
it,
but
kind
of
the
the
reason.
C
It's
one
of
those
classic
cases
of
a
small,
a
very
small
change
that
has
like
massive
Butterfly,
Effect
style,
or
implications
on
the
rest
of
the
API,
and
that
sucks
because,
like
the
ask
that
you're
asking
for
as
a
user
is
straightforward
and
relatively
easy,
but
because
it
has
a
big
implications
for
how
the
rest
of
the
API
works
like
I.
Can't
just
be
like
yeah
sure,
we'll
just
go:
do
that
which
sucks
foreign.
A
Good
discussion,
all
around
I
I,
think
there's
a
lot
more
to
go
on
both
directions
here.
If
there's
an
implementation
out
there
that
wants
to
try
out
this
kind
of
you
know,
just
look
at
spec
address.
Just
type
I
I
would
love
to
see
if
that
works
in
practice,
because
that's
going
to
be
a
much
faster
thing
to
support,
but
certainly
also
interested,
if,
if
there's
broader
interest
in
that
longer
term,
vision
for
kubernetes
cluster
IP
gateways,
I
I
would
love
to
make
that
work.
A
A
Okay,
that's
I
think
everything
on
the
agenda
any
any
last
bits.
A
Cool
all
right.
Well,
thank
you.
Everyone
for
good
discussion,
hope
everyone
has
a
good
Thanksgiving
for
those
that
celebrate,
and
we
will
talk
to
everyone
next
week
have
a
great
one.