►
From YouTube: SIG Network Gateway API meeting for 20230227
Description
SIG Network Gateway API meeting for 20230227
A
A
We
didn't
have
it
in
recent
months
had
an
attendees
list
for
the
meetings,
except
now
that
we're
starting
to
talk
about
doing
meetings
at
different
times.
It's
actually
helpful
to
kind
of
know
who's
attending
them.
So
if
you
would,
please
put
your
name
in
your
org
on
the
attendee
list,
we'd
appreciate
it
that
so
we
can
kind
of
see
who's
going
to
the
meetings.
A
If
you
have
anything
else
to
add
to
the
agenda,
it's
an
open
Agenda,
please
do
feel
free
to
add
something
to
the
doc
which
we
can
link
for
you.
If
you
don't
know
where
it
is,
can
everybody
see
the
doc
Okay
cool,
so
I
have
a
couple
of
just
minor
reminders
that
I
wanted
to
get
out
of
the
way
first
and
then
we'll
go
on
to
the
other
people's
agenda
items
first
thing:
March,
6th
and
I'm.
A
So
just
a
heads
up,
March
6th,
it's
on
the
kubernetes
six
Network
calendar,
so
you
should
already
see
it
there
if
you're
subscribe
to
that
next
reminder-
and
this
is
a
general
reminder
throughout
all
of
kubernetes
if
you
are
using
container
images
with
the
old
khs.gcr
dot.
Io
registry
this
registry
is
being
frozen,
is
being
deprecated
and
will
be
gone
soon.
A
It
is
mirrored
over
to
registry.k8.io.
Please
switch
any
usage
of
images
that
you
have
from
gcr.io
over
to
the
k8.io
registry.
Look
in
your
CI
and
everywhere,
like
these
things
can
be
like
you
know,
core
DNS.
You
know
that
you're
using
somewhere
randomly
stuff
like
that.
Please
switch
them
over
and
there's
the
blog
post.
You
can
read
more
details
about
that.
B
Ref
exist
on
Gateway
class,
which
is
which
is
great
but
they're.
We're
looking
for
some
clarification
on
about
some
language
there
and
Mike
there's
a
slack
thread.
We
were
discussing
this
Mike
linked
to
that
to
that
part
of
the
documentation
where,
essentially
it
says
that
program,
ref
changes
should
only
affect
Gateway
classes
that
are
or
sorry
should
affect.
Instances
of
gateways
that
that
binds
to
that
Gateway
class
after
batch
is
made.
So
essentially,
implementations
would
impact
to
snapshot
flag
for
the
better
term.
B
C
Yeah
I
think
that
was
a
great
overview
Keith
and
thanks
for
letting
us
voice
us
up,
you
know
kind
of
our
understanding
is
the
Gateway
class
is
really
a
template
of
what
the
customer
is
going
to
get
and
therefore
we
treat
that
as
almost
an
immutable
definition
and
then
the
Gateway
object
is
going
to
really
Define
what
gets
provisioned
as
we
look
at.
You
know
different
attributes
that
can
be
related
to
whatever
that
Gateway
is
that
ends
up
getting
provisioned.
D
Yeah
I
think
this
is
a
really
good
set
of
questions
that
I
I
spent
a
little
bit
of
time,
scrambling
around
to
try
and
find
where
we'd
specify,
because
I
know
we've
had
lots
of
discussions
and
it's
harder
than
it
seems.
It
should
be
to
find
a
a
good
recommendation
for
this.
The
closest
thing
that
I
could
find
that
I
linked
there
as
the
recommendation
in
the
Gateway
class
spec
above
the
Gateway
class
resource
name.
D
It
is
not
in
our
Gateway
class
documentation
that
I
can
find,
but
it
is
somewhere,
and
it
is
really
just
that
high
level
idea
of
Gateway
classes
should
be
used
as
templates
that
that's
a
recommendation,
not
a
requirement,
but
the
recommendation
comes
from
the
idea
that
we
want
to
limit
the
blast
radius
as
much
as
possible
right.
So
if
you
change
a
Gateway
class,
you
don't
want
it
to
affect
every
Gateway
that
was
provisioned
with
that
class.
It
could
be
very
problematic,
especially
if
you
introduce
some
kind
of
error
or
undesired
configuration.
D
This
does
not
I
I
guess
it
does
briefly
say
at
Gateway
class
or
Associated
parameters.
That
is
my
intention
as
well
or
my
recommendation
as
well.
We
should
try
to
bubble
that
up
to
more
visible
part
of
the
documentation,
but
I
I
think
absolutely
Gateway
class
should
be
you
know,
seen
as
a
template.
That
represents
the
starting
point
of
the
Gateway
created
at
that
point
in
time,
but
it
could
evolve
over
time.
A
A
I
know
that
this
is
kind
of
like
taken
from
Storage
class
I.
Don't
think
it's
necessarily
the
greatest
thing
for
users,
because
it
creates
a
state
that
can't
necessarily
be
known
without
going
through
like
object,
revisions
which
is
like
I,
don't
know
about
it,
I'm
just
to
throw
that
out
there
yeah.
F
I
think
this
was
sort
of
like
a
bowing
to
practical
considerations,
because
all
the
sort
of
like
end
user
interactions,
we've
had
discuss
based
sort
of
implicitly
understand
this
or
it
feels
safer
to
them.
So
I
do
know
that
you
know
from
a
declarative
standpoint.
It
violates
it,
but
from
expectation
and
oops
I
made
a
mistake
kind
of
standpoint.
If,
if
people
seem
to
prefer
sort
of
that,
behavior.
G
G
It
Zoom
had
decided
that
they
wanted
to
use
the
wrong
wrong
microphone.
As
always
sorry
see,
I
agree.
This
is
this.
Is
this
is
not
great
but
the
the
trader.
The
the
other
option
here
is
that
if
you
make
a
change
to
Gateway
class,
it
must
immediately
be
reconciled
out
to
everything
that
all
the
gateways
that
are
in
that
Gateway
class,
which
makes
like
changing
a
Gateway
class
like
absolutely
nightmarish
change.
G
G
D
D
If
you
have
major
changes
to
make,
it
probably
should
be
a
new
Gateway
class
I
think
changes
at
that
level
are
just
too
risky
to
justify
making
you
know
propagating
them
down
to
every
attached
Gateway
again,
if
you
have
no
gateways,
it's
no
big
deal.
You
can
make
as
big
changes
as
you
want,
but
maybe
that
is
the
kind
of
thing
that
we
want
to
expose
as
guidance
I,
again
kind
of
going
back
to
what
Bowie
said.
G
H
Oh
yeah,
actually
like
more
on
the
Skate
3
class
and
the
blast
radius.
I
mean
I.
To
understand
that
you
know
the
implication
is
like
you
know,
you
have
10
gateways
and
it
can
impact
and
it's
a
bigger
change,
but
like
what,
if
you
know
it's
scoped
to
like
you
know
like
we
had
like.
Oh
it's
the
platform
operator.
H
Similarly,
like
you
know
the
we
scope,
the
role
of
who
can
modify
this
so
assuming
that
the
person
making
this
change
is
consciously
aware
of
the
change
they're
making-
and
you
know
maybe
yeah,
because
you
know
the
impact
can
be
so
wide
like.
We
already
have
the
parameter
reference
in
the
Gateway
class
and
you
know
maybe
Define
a
crd
for
that
which
has
its
own
set
of
validations.
So
until
like
that,
one
is
not
like
in
a
valid
state.
G
I
I
was
just
gonna
say.
A
lot
of
this
is
really
really
similar
to
what
my
Gap
is
talking
about
for
in
cluster
deployments.
So
it
may
make
sense.
I
mean
we'll
go
over
that
in
a
minute,
but
it
may
make
sense
to
split
that
one
into
the
common
part.
That
is
just
configuring
gateways
and
then
also
then
a
cluster
one,
because
right
now
you
know
we're
solving
kind
of
the
same
problems.
A
Oh,
maybe
I'll
wait
until
we
talk
about
John's
thing.
My
main
thing
is
that
I
feel
like
this
recommendation.
While
we
feel
like
it
is
a
historical
recommendation
and
we
feel
comfortable
in
that
to
some
degree
is
ultimately
going
to
lead
to
people
doing
things
their
own
way
in
a
lot
of
different
ways.
G
One
of
the
reasons
is
there
is
that
if
you
do
this
for
an
in-cluster
one,
it's
it's
really
like.
If
you
do
this,
for,
if
we
did
this
for
Contour,
it
would
have
been
really
bad
like
because,
because
in
Contour
originally
in
Contour,
a
Gateway
class
equals
a
deployment.
So
changing
the
Gateway
class
means
that
you
de-provision
the
existing
proxies
and
then
reprovision
them,
and
so
that
means
that
there
is
an
outage
involved
in
changing
it
right
and
so
like
it.
G
Exactly
what's
happening,
I
understand
that
in
the
case
of
like
service
providers,
it
might
not
necessarily
be
the
case
that
there
is
an
outage.
That's
why
it's
a
recommendation
and
not
a
requirement
that
you
hey.
It's
like
hey,
be
careful
and
tend
to
use
this
as
a
template
is
probably
a
better
idea
because
changing
because
changing
these
things
might
mean
that
you're
reprovisioning,
an
entire
data
point.
D
It's
possible
from
cloud
provider
perspective
too
that
there
could
be
a
change
at
that
level
that
could
require
reprovisioning
infrastructure,
which
would
also
be
really
painful
and
I.
Think
that's
really
the
thing
that
we're
trying
to
avoid
is
any
kind
of
change
triggered
at
Gateway
class
level
that
results
in
everything
below
that
being
reprovisioned
and
downtime,
as
a
result
that
yeah
I
would
also
Echo
what
Nick
kind
of
alluded
to
there.
This
is
a
recommendation.
Not
a
requirement,
maybe
need
some
more
guidance
here.
G
D
G
We
have
more
guidance
here
about
why
it's
a
recommendation
and
not
a
requirement
yeah,
so
I
think
that
one
of
the
things
that
came
up
in
what
you
were
saying
Keith
is
about
addresses,
particularly
I.
Think
that
one
of
the
things
that
we
haven't
done
a
good
job
of
is
specifying
like
how
the
addresses
field
on
Gateway
is
intended
to
be
used.
G
G
It
can
may
claim
an
address
from
a
pool
of
addresses
the
the
idea
is
that
the
you
you
can
if
there's,
if
there's
a
way
for
you
to
tell
somebody
what
the
pool
of
addresses
is,
then
you
can
put
that
address
in
Spec
addresses
and
then
that
address
and
then
status
addresses
tells
you
if
that
was
successful
or
not,
and
so
the
idea.
The
idea
here
is.
G
If
you
have
a
pool
of
addresses
like
say,
if
there's
some
way,
that
you
can
configure
a
pool
of
addresses
or
one
thing
that
we
could
possibly
do,
there
is
add
some
space
on
Gateway
class
status
to
be
able
to
surface
to
Bubble
Up
sort
of
implementation.
Specific
information,
like
you
know,
maybe
it's
a
maybe
there
is
a
a
map
string
string
bit
in
the
status
where
you
can
put.
G
You
know,
implementation,
specific
information
without
a
need
to
be
too
structured,
and
then
you
can
tell
people
what
what
pool
of
IP
addresses
are
available
or
some
or
we
have
a
struct
or
something
like
that.
But
if
there's
some
way
that
you
can
expose
that
on
the
status
of
the
Gateway
class,
then
you
can
request
a
specific
IP
address
and
then
and
then
the
specific
IP
address
gets
claimed
and
then
you
you
and
then
the
thing,
but
the
the
the
the
intended
contract
of
addresses
in
Gateway
is
that
you
can.
G
You
may
request
it?
You,
as
a
user
may
request
a
specific
address
and
then
it
use
status.
Addresses
will
tell
you
if
it
if
it
succeeded
or
not,
and
if
you
don't
request
a
specific
address
that
means
Please
assign
me
some
address
and
I
don't
care
what
it
is
yeah
and
so
with
the
assumption
that,
once
that
address
is
assigned,
it
won't
be
reallocated
because
they
and
obviously
then
you've
got
DNS
updates
and
all
that
sort
of
stuff.
G
So
that
that
specific
part
of
what
you
were
saying,
that's
that's
how
it's
intended
to
work.
So
if
you
had
a
thing
in
params
ref
that
lets
you
specify
like
which
subnet
to
pick
addresses
from
or
something
like
that,
then
then
it
would
make
sense
for
there
to
be
something
that
lets.
You
check
that
that
is
all
okay
and
then
for
the
person
who
owns
the
gateway
to
be
able
to
say,
I
want
this
specific
address
and
it
to
stay
that
specific
address.
G
A
So,
just
just
to
make
sure
that
I'm
clear
in
the
case
of
like
Cloud
providers
and
stuff,
like
that,
the
main
concern
is,
if
you
have
a
configuration,
that's
referenced
by
parameters
ref.
The
main
concern
that
you
have
is
there
are
configurations
that
would
require
an
entire
reprovisioning
of
a
load
balancer.
What
have
you
right.
A
D
It's
there's
not
a
standard
way
to
do
that.
There
has
been
some
discussion
about
it,
but
it's
surprisingly
hard
to
Define
what
immutable
means
you
know.
Does
it
mean
going
from
nil
to
some
value?
Is
the
there
were
all
kinds
of
things?
I
talked
with
someone
an
API
Machinery
about
this,
because
we
wanted
it
somewhere
else
in
cable
API.
You
could
certainly
do
it
with
a
web
hook.
There's
not
a
way
to
do
it
with
crd
validation
and
obvious
a
web
hook
can
be
bypassed.
D
You
know
whatever
it's
it's
so
yeah
like
all
these
things,
their
their
guidelines,
they're
they're,
trying
to
avoid
pain,
I
it
it
is
ultimately
up
to
any
individual
implementation
and
I.
Think
in
this
case
we
just
need
to
do
a
better
job
at
describing
the
risks
and
benefits
associated,
but
certainly
I
think
a
high
level
guideline
would
be
if
there's
something
that
can
change,
that's
going
to
require
things
to
be
recreated
and
potentially
downtime.
Along
with
that,
you
probably
don't
want
to
propagate
that
down.
E
C
C
A
G
So
I
think
I
think
the
the
main
action
is
that
we
need
to
clarify
this
that
the
you
know.
Currently,
the
recommendation
is
that
you
treat
Gateway
class
plus
any
Associated
parameters
ref
as
as
a
template,
and
that
you
you,
that
is
the
current
recommendation.
To
be
honest,
I
can
probably
see
an
argument
that
what
we
are
saying
would
be
easier
to
explain.
If
we
just
made
the
Gateway
class
object
immutable,
you
create
it,
that's
it
after
that.
You
can't
edit,
you
want
to
make
a
new
one,
make
a
new
one.
G
G
Yeah
like
it
means
that
in
order
to
migrate
each
like,
if
you
have
10
000
gateways
and
get-
and
they
are
all
pointed
in
one
Gateway
class
now
you
have
10
000
modifications
to
gateways
that
you
need
to
make
to
make
move
them
to
a
new
Gateway
class.
Is
that
a
problem
I
mean
moving
a
Gateway
class
is
a
pretty
significant
operation.
It
feels
like
something
that
you
might
want
to
have
require
a
conscious
action,
but
I
don't
know.
G
I'd
probably
need
to
think
about
that
more,
but
I
think
the
action
item
is
definitely
which
would
clarify
what
we
currently
have
and
then
possibly
think
some
more
about.
It.
I
think
that
we
also
should
move
on
to
John
thing,
because
I
suspect
that
it
will
that
what
John
has
to
say
may
influence
this
discussion.
A
A
Okay,
we're
kind
of
getting
into
the
half
hour
here
and
we've
got
a
couple
things
left,
so
we
might
as
well
switch
over
but
I'll
take
on
unless
somebody
wants
to
jump
in
and
grab
this.
For
me,
the
act
of
like
trying
to
improve
the
recommendation
so
far,
and
we
will
continue
the
conversation
I
think,
generally
speaking
in
the
slack
thread,
but
also
probably
we
can
put
something
on
the
agenda
for
next
week.
I
Yeah,
if
you
wouldn't
mind
going
to
the
the
actual
content,
would
be
good.
So
basically,
I've
noticed
that
there's
been
a
lot
of
discussion
around
kind
of
how
we
do
a
lot
of
various
configurations
for
things
like
merging
gateways,
whether
it's
you
know
the
cluster,
local,
Gateway
or
external,
and
all
these
different
problems,
as
well
as
just
how
we
manage
and
operate
in
cluster
deployments
and
all
the
parameter
ref
stuff
that
we
just
talked
about
so
kind
of
my
goal-
was
to
make
one
Gap
that
kind
of
covers.
Here's.
I
How
in
cluster
Gateway
deployments
should
work
and
when
I
say
in
cluster
I
mean
something
that
is
actuated
by,
for
example,
a
service
and
deployment
in
the
cluster.
It
technically
doesn't
need
to
use
those,
but
commonly
does-
and
it's
you
know,
differs
from
kind
of
a
cloud
load
balancer
or
something
that's
doing
something
external
to
the
cluster.
I
So
that's
the
goal.
It's
it's
pretty
lofty
goal
and
that
large
part
of
this
Gap
in
its
current
form,
was
to
get
us
to
start
talking
about
these
things
and
kind
of
figuring
out
what
various
options
are.
So
I
did
fill
in
kind
of
ideas
for
a
bunch
of
things,
but
this
is
a
no
means
meant
to
be
like
here.
Is
the
the
doc
approve
it
or
I'm
gonna
like
fight
against
it
and
like
this
is
the
way
I
absolutely
think
it
must
be.
I
It's
really
meant
to
be
as
a
starting
point
for
for
discussion.
So
a
lot
of
these
things,
I,
don't
even
necessarily
I
strongly
feel
about
them.
I
just
wanted
to
get
at
least
something
down
in
all
the
sections,
so
that
we
had
a
a
starting
point,
at
least
so
that's
kind
of
the
idea
I
can
go
through
it
or
I.
Don't
know
how
much
time
I
want
to
allocate
to
this
and
preferences
and
kind
of
walk.
I
All
right,
then,
let's
see
I,
think
there's
a
few
kind
of
kind
of
points
here,
so
the
the
first
is
kind
of
defining
a
common
experience
for
in-cluster
deployments.
So
for
the
kind
of
cloud
load
Amounts
is
I,
think
it
is
a
I
mean
we
just
saw
in
the
last
discussion.
Maybe
this
is
not
quite
the
case,
but
there's
at
least
a
a
path
towards
a
a
consistent
experience
right.
I
You
just
create
like
a
Gateway
like
this
one
here
at
the
bottom,
and
eventually
some
address
gets
populated
in
the
status
and
you're
good
to
go.
If
you
don't
really
have
to
do
anything
else
for
in
cluster
deployments
is
quite
a
bit
different.
I
think
everyone
has
a
different
way
of
saying:
here's
how
you
associate
that
Gateway
with
a
deployment
right.
Some
folks
are
doing
kind
of
a
more
manual
approach
where
you
kind
of
go
provision
the
deployment
of
service,
and
then
you
link
them
up
to
the
Gateway.
I
Somehow
some
people
are
automating
it,
but
you
have
to
do
XYZ
config,
and
so
it's
not
really
like
the
you
know,
just
create
a
Gateway
and
check
this
at
the
status
to
see
how
to
access
it.
Experience
that
cloud
load
browsers
have
so
kind
of
part.
One
of
this
is
defining.
How
do
we
represent
those
right?
I
There's
kind
of,
in
my
mind,
there's
two
different
classes
of
these,
whereas
one
is
the
fully
automated
you
create
a
Gateway
and
the
implementation
acts
as
a
bit
of
a
controller
or
operator
or
whatever
you
want
to
call
it.
That
then
goes
and
spawns
a
deployment
service,
whatever
the
implementation
needs
and
the
other
is
kind
of
a
manual
one
where
the
user
does
that,
and
they
just
link
those
two
up
together.
So
here's
an
example
of
like
manual.
I
This
is
one
of
those
areas
where
I
definitely
feel
it's
pretty
weak.
So
folks
that
are
implementing
this
as
well.
Definitely
comments.
Welcome
the
next
topic.
I
tried
to
cover
was
about
merging
gateways.
That
is
again
a
pretty
weak
point,
but
it's
caused
a
lot
of
friction
and
then,
finally,
after
that
we
go
into
what
was
just
talked
about,
keep
which
is
kind
of
this
customization,
which
could
be
anything
from
like
the
type
of
service.
There
was
a
whole
Gap
about
that
of
cluster
local
Services.
I
Obviously,
but
different
users
will
want
all
the
different
fields
and
there's
a
thousand
fields
in
in
pod,
so
the
API
service
is
potentially
very,
very
large
and
potentially
all
those
may
want
to
be
configured
so
I
think
that
covers
kind
of
the
general
areas
that
we're
trying
to
go
into
I'm
happy
to
go
in
more
discussion.
I,
don't
want
to
take
up
all
the
time,
and
so,
if
there's
questions
now,
we
can
discuss
them
and
would
definitely
appreciate
folks
reviewing
the
actual
Gap.
A
G
Button
so
yeah
I
hadn't
had
a
chance
to
have
a
good
rate
of
this.
Yet
just
having
a
quick
read
now
I
like
a
lot
of
it,
I
think
in
particular
I
think
it's
clever
to
use
the
addresses
field
to
to
handle
some
of
these
things.
Although
a
specific
new
address,
type
I
think
would
be
better
rather
than
overloading
named
address.
G
This
one
is
for
service
type,
load,
balancer
and
and
then,
and
then
that
propagates
down
to
any
gateways
that
are
created
there,
so
yeah,
but
so
like
I,
will
try
to
do
a
proper
review
with
my
thoughts
on
there
as
well,
but
yeah
I.
Think
in
terms
of
like
very
brief
feedback.
That's
that's
money.
I!
Think
the
I
really
like
the
idea
of
having
some
way
to
handle
the
automated
manual
I
had
been
able
to
think
of
a
way
to
do
that.
D
Yeah
great
comments
and
I
would
just
add
this
is
this
is
great.
Thank
you.
John
I
added
some
comments.
Already
one
concern
or
just
I
guess
warning
is
that
this
Gap
is
very
Broad
and
it
covers
some
areas
that
have
historically
been
contentious,
so
it
may
be
easiest
if
we
can
cut
some
areas
out
for
separate
gaps
like
the
the
one
that
I
I
would
highlight
is
Gateway
merging
is
one
that
is
just
historically
very
complicated
to
reach
a
resolution
on.
D
D
Yeah,
this
is
one
that
we've
talked
about
in
previous
meetings
for
a
while
and
finally
got
a
rough
dock
together,
that's
ready
for
some
review,
I,
don't
think
anything's
going
to
be
particularly
surprising
in
here,
but
at
a
high
level.
What
we
want
to
communicate
is
we
have
lots
of
room
for
people
to
contribute.
We've
already
had
some
great
contributors.
Thank
you
for
everyone,
people
that
have
been
contributing
adding
so
many
new
conformance
tests
reviewing
some
aprs
gaps.
D
Etc
just
there's
there's
been
a
lot
of
great
participation
right
now,
I'd
say
a
lot
of
the
bottleneck
has
been
on
maintainers
waiting
to
for
us
to
review,
approve
whatever
and
we're
we're
hoping
to
get
more
people
involved.
That
can
also
help
with
that
load,
and
we
already
have
lots
of
people
that
have
been
doing
great
work
and
we
just
want
to
create
those
kind
of
formal
roles
and
Define
where
they
fit.
D
So
the
the
scope
of
this
stock
is
really
about
the
three
projects:
API,
of
course,
the
main
one,
but
also
Ingress
the
Gateway,
and
soon
to
be
blitzed
once
it
completes
the
migration
and
then
you
know
our
the
things
that
I'm
proposing
here
again
the
open
to
comments.
But
what
I'm
proposing
here
are
the
same
kind
of
roles,
the
same
kind
of
guidelines
that
Upstream
kubernetes
uses
the
member
reviewer
approver
and
then
finally,
the
sub-project
owners.
D
We
have
sub
projects
well,
basically
areas
within
our
project,
including
conformance
documentation
and
gaps,
that
we
have
lots
of
people
that
have
been
very
good
at
reviewing
these
areas.
I
think
it'd
be
really
helpful
to
formally
specify
reviewers
that
get
automatically
assigned
these
PRS
to
take
them
on.
Some
of
you
may
already
know
who
you
are.
If
you're
interested
in
this
please
reach
out.
D
Don't
think,
there's
anything
too
controversial
in
here,
but
certainly
we'll
leave
this
open
for
comments
for
a
while
and
then,
depending
on
what
kind
of
comments
we
get,
we
can
try
and
get
this
into
a
gap,
maybe
sometime
next
week,
but
certainly
before
then,
if,
if
you
are
thinking
about
you
know
trying
to
take
on
a
more
formal
role,
this
is
your
invitation.
There
are
lots
and
lots
of
opportunities
in
this
project,
yeah
and
maybe
I'll
hand
it
off.
A
K
Yeah
so
the
reason
I'm
bringing
this
up
is
after
bumping
to
version
061
and
running
all
the
port.
Redirect
tests
I
think
we
we,
as
in
onward
Gateway
as
well
as
Contour,
realize
that
some
tests
within
the
redirect
Suite
don't
pass,
and
these
are
the
tests
specifically
where
the
port
redirect
is
on
on
a
value,
is
unset.
K
K
K
K
So
that's
one
of
what
we
could
do.
The
third
is
I
haven't
seen
a
playground
with
hdbin.org
I
haven't
seen
them
sort
of
append
the
port
number
to
the
location
header
when
so
I
think
yeah
I
was
just
hoping
that
Everybody
sort
of
reviews
this
and
and
shares
more
feedback
on
what
the
default
semantics
should
be.
I
think
this
is
blocking
us
from
from
yeah
us
being
in
on
vacated
in
conformant,
so
yeah.
G
I
think
that,
in
my
mind
there
is
an
important
caveat
to
all
of
this
that
that
the
there
is
an
implied
Port
indicating
your
Port
unspecified
does
imply
a
port
when
the
based
on
a
protocol
so
for
HTTP,
Port
unspecified
implies
80
to
https.
Port
unspecified
applies,
443
and
so
I
think
I'm,
supportive
of
it
being
whatever's
on
The
Listener,
because
the
listener
address
is
supposed
to
be
whatever
The
Listener.
G
K
D
Yeah
and
I
just
wanted
to
I.
Think
I've
already
commented.
This
and
I
was
really
just
agreeing
with
John,
but
I
I
really
I
also
prefer
using
listener
Port,
as
the
reference
here
as
much
as
I
admit
that
that
is
not
certainly
not
what
anyone
would
imply
by
reading
this
spec
right
now.
The
spec
is
fairly
vague.
D
The
Listener
report
is
something
that
I
prefer
just
because
it
is
something
that
is
statically
configurable,
so
you
know
you
can
you
can
compute
that,
just
in
the
controller
code
itself,
you
don't
have
to
worry
about
underlying
implementation
details.
It
allows
us
to
be
consistent
across
implementations.
A
Other
question
my
sentiment
as
well:
I
I
think
that
you
do
this.
Rather
you
do
what
was
being
recommended
or
asked
for
a
couple
of
times
here
and
you
get
a
situation
that,
like
every
control
plane
is
responsible
for
it.
That
makes
it
very
easy
to
implement
once
you
push
it
down
to
where
it
might
be,
something
that
the
data
plane
has
to
kind
of
reason
with
you
might
get
different
behaviors,
but
it
would
be
better
to
compile
it
at
that
higher
level.
I.
A
E
D
E
E
With
a
redirect
status
code
as
well,
what?
Where
does
the
port
that
you
specify
on
the
location?
The
turn
location
header
come
from
right
like?
Is
it
The,
L4
Port
that
the
client
connected
to,
or
is
it
say,
the
request
was
made
with
hostname
with
host
header
Wikipedia.org
colon
8080
right
and
the
actual
listing
report
was
something
else
or
the
list
report
was
not
enough
to.
G
The
more
I
think
about
it,
the
more
I
feel
like
we're
over
complicating
this,
and
it
should
be
if
you
want
to
pour
if
you
you,
if
you're
redirect
you're
redirecting
here
right
like
this
isn't
so.
This
is
not
actually
about
the
port
that
you
connected
to.
This
is
about
where
you
are
redirecting
to
so.
E
What
kind
of
yeah
the
spec
kind
of
implies
the
support,
if
specified
when
it
comes
on
the
request
that
the
client
is
making
right,
but
we,
it
totally
makes
sense
that
if
the
if
the
redirects
it
like
with
me,
say
if
you
want
to
redirect,
then
we
want
to
change
the
port
the
location
header
has
in
it.
Then
you
should
specify
that.
E
G
G
Persona,
but
the
idea
here
is
that
the
The
Listener
on
the
Gateway
defines
the
thing
that
that
the
client
should
be
connected
to
right
like
so
the
listener
tells
you,
like.
The
point
of
the
listener
is
to
define
the
thing
that
it
should
be
connecting
to.
So
that's
so
so
here
yeah,
so
here
you're
redirecting
something.
So
if
you
this
is
obviously
so
there's
a
couple
rules.
First,
if
you
do
specify
a
port,
then
you
know
in
in
the
redirect.
G
Then
then
that
overrides
everything
we're
talking
about
right,
just
to
be
clear,
if
you
do
specify
a
port
in
the
redirect
and
it's
80
or
443
or
so,
whichever
way
the
port
ends
up,
decide
being
decided.
If
the
end,
if
the
final
Port
is
80
or
443,
then
you
should
not
specify
because
that
is
implied
by
you
know
the
protocol,
the.
G
Then
you
need
to
specify
a
port,
but
like
the
you
that,
where
we're
skipping
one
layout,
the
reason
we
don't
want
to
do
it
by
looking
at
what's
in
the
in
the
actual
Authority
is
because
that
that
then
places
a
dependency
on
the
fact
that
your
data
path
can
can
read
the
authority,
and
you
know,
and
and
take
actions
based
on
it,
I
mean
which
most
of
them
can
but
like.
Maybe
they
can't
and
where,
and
whereas
that
information
is
present
already
in
the
API
in
The
Listener
port.
G
G
E
F
G
E
G
G
K
A
A
G
D
I
so
I
added
this
one,
so
I
can
I'll
start
talking
about
it.
We'll
next
till
still
go
in
here,
but
Nick
has
an
old
PR.
That
I
took
way
too
long
to
meaningfully
review
sorry,
but
also
I
wanna
it
it.
It's
really
good
I
think
there's
a
lot
of
good
changes
here
and
since
policy
attachment
has
come
back
up
as
as
an
issue
that
is
overly
complicated,
I
think
Nick
had
some
ideas
here
that
could
provide
a
simpler.
D
G
Yeah,
so
this
change
I
would
summarize,
as
it
does
a
few
things.
Firstly,
it
coins
the
word
meta
resource
to
talk
about
a
meta
resource
that
augments
the
functionality
of
another
object
policies
are,
are
a
meta
resource
technically
reference
green
is
also
a
medical
resource,
but
it's
not
as
useful
like
a
use
case
here.
The
other
thing
that
it
does
is
previously.
G
In
Contour,
you
needed
four
definitions
of
the
of
every
single
timeout
that
you
wanted
to
configure
a
global
default
and
whether
or
not
that
you
know
an
override
value
that
would
override
any
other
settings
anywhere
else
and
then
a
per
route
default
and
a
per
out
override
like
yeah
it
just
it
was
really
complicated
and
it
meant
that
adding
any
time
and
adding
any
singular
timeout
was
was
a
lot
of
work.
So
that's
why
that's
one
of
the
reasons
why
the
you
know
there's
the
big
mechanisms
there
about
hierarchical
policy
attachment.
G
However
you
it
has
come
up
in
you
know,
mesh
and
other
cases
that
that's
pretty
complicated
and
a
lot
of
the
time.
You
don't
need
that
functionality.
So
the
thing
that
this
new
revision
adds
is
direct
policy
attachment
which
attaches
a
policy
specifically
to
a
single
object
or
a
kind
of
objects
I've
allowed
in
here,
and
that
that
then
is
that
then,
has
a
couple
of
extra
rules.
It
can't
cross
namespace
boundaries,
oh
no,
it
can.
G
It
is
allowed
to
cross
namespace
boundaries,
but
it
is,
it
has
significant,
it
sort
of
says:
don't
do
that
unless
you
have
a
really
good
reason
pretty
much.
The
only
good
reason
at
the
moment
is
you
know:
Hey
I
want
to
do
a
consumer
policy
in
a
service
mesh
use
case,
but
in
general
you
shouldn't
do
these
across
those
places.
I
think
is
the
wording.
I
can't
remember
the
exact
wording
I
put
in
there,
but
a
hierarchical
name,
a
hierarchical
one
will
not
be
allowed
to
cross-name
spaces.
G
Doing
that
in
status
is
really
hard
because
doing
it
in
status
implies
that
the
status
will
be
updated
anytime.
The
set
of
things
changes
which
can
get,
which
means
that
you
can
generate
a
lot
of
API
server
load
accidentally
with
fan
out
and
fan
in
kind
of
problems.
The
thing
that
I
have
tried
to
do
here
is
to
change
one
of
the
things
I
have
done.
Is
we
already
have
a
policy
Target
reference
struct
in
the
API,
that's
best
that
that
is
the
current
way
that
you
define
this
as
a
policy.
G
G
Think
I
misspelled
it
a
couple
of
times
in
this
specific
document
and
I've
been
typing
it
a
lot
I
think
that
there
are
definitely
better
names
that
we
could
do,
but
I'm
using
it
for
now,
because
it's
it's
clear
and
so
the
intent
here
is
that
a
policy
is
any
object
that
includes
this.
That
includes
a
top
level
Target
ref
field.
That
is
destruct.
That
is
a
policy
anything
that
does.
That
is
a
policy.
G
The
type
of
policy
is
set
by
the
type,
and
you
know
it's
expected
that
for
a
hierarchy
for
policy,
you
would
have
defaults
and
overrides
as
the
other
two
top
level.
Fields
I
still
have
a
clarified.
There's
a
couple
of
bits
in
there
that
I
that
I
only
realized
I
hadn't
clarified
this
morning.
But
that's
that's.
The
sort
of
idea
here
is
to
sort
of
try
and
dial
this
in,
so
that
it's
more.
G
G
This
is
why
one
of
the
reasons
why
I
had
started
doing
this,
but
it's
becoming
more
and
more
relevant,
because
lots
of
people
want
to
use
policy
and
I'm
worried
that
we're
going
to
get
wildly
varying
things,
because
we
haven't
been
specific
enough
about
that
language.
So,
please,
if
you
are
interested
in
using
policy,
please
review
this
thing.
Put
some
comments
on
it.
Give
me
give
me
suggestions
for
the
names
that
I
can
call
things
rather
than
hierarchical
policy.
You
know
you
know,
I
did
consider
direct
and
indirect,
but
it's
a
little
bit
misleading.