►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20220321
Description
SIG Network Gateway API Bi-Weekly Meeting for 20220321
A
All
right,
this
is
the
gateway
api
meeting
for
march
21..
If
you
have
not
been
here
before
just
a
reminder
that
this
is
a
very
rough
agenda
that
we
go
through,
of
course,
and
anyone-
and
I
mean
anyone-
can
add
things
to
this
agenda-
there
are
things
that
we
should
talk
about.
Please
please
make
sure
that
you
fill
this
out.
You
can
do
it
at
any
point.
This
doc
should
be
something
that
anyone
can
edit.
A
This
is
a
very
informal
meeting.
There
are
no
stupid
questions
at
all.
So
please,
if
anything,
doesn't
sound
right
or
if
you
have
any
questions
about
what
we're
saying
please
by
all
means
with
that.
Let
me
go
ahead
and
jump
into
well
actually
mike.
I
think
he
started
on
a
topic.
Maybe
did
you
have
anything
you
wanted
to
add
here.
B
There's
one
more
thing
I
wanted
to
say:
okay
before
we
get
started
yeah
if
you
haven't
been
before,
if
you
haven't
come
to
the
meeting
before,
please
feel
free
to
drop
a
hello
in
the
chat
or
you
know
unmute
and
say
hi
like
rob
says,
this
is
a
pretty
informal
meeting,
it's
great
to
see
heaps
of
people
coming
but
yeah
and
I
think
both
both
rob
and
I
have
spent
a
long
time
working
on
this
and
can
talk
for
a
long
time
about
it
and
will,
unless
yeah.
B
Unless
we
have
reasons
not
to
so
yeah,
don't
feel
like
I've
said:
there's
no
stupid
questions
absolutely
not
and
please
un
unmute
or
raise
your
hand
if
you,
if
you
have
a
question
or
you
want
to
ask
anything
at
any
point
or
put
it
in
the
chat.
If
you
don't
feel
comfortable.
C
A
Makes
sense
I
completely
understand.
Thank
you.
Thank
you
for
signing
this
up.
I
took
me
to
the
last
minute
to
actually
add
today's
entry.
So
yeah
glad
glad
you
added
it
there
with
that
yeah.
Maybe
we
can
head
straight
into
the
v1
beta
1
milestone
these.
This
is
really
top
priority
for
me
anyway,
and
I
think
for
most
of
us
it's
just
trying
to
get
a
v1
beta,
1
out
the
door.
A
If
you
look
at
the
kinds
we're
seeing
here,
there's
almost
exclusively
documentation
left
and
some
web
hook
stuff,
but
there
are
a
couple
features
that
are
kind
of
on
the
edge
here,
and
I
wanted
to
talk
about
those
so
first
up,
there's
the
discussion
about
port
ranges
and
all
ports,
and
this
is
something
that
had
come
up
in
the
previous
api
review.
I
think
it
was
tim
may
have
raised
it.
I
don't
know
it
was
raised
by
a
few
different
people
of
how
could
we
support
all
ports?
A
How
could
we
support
port
ranges,
these
kinds
of
things
in
the
future,
and
the
idea
was
that
we
should
at
least
have
an
answer
for
how
it
could
work
when
we
get
back
to
the
next
round
of
api
review,
which
in
this
case
will
be
for
beta,
so
we've
had
good
discussion
throughout
here.
I
added
a
dock
that
we
reviewed
at
a
previous
meeting.
A
So
that
makes
me
think
that
this
specific
thing
does
not
need
to
block
a
beta
release,
but
I
wanted
to
just
kind
of
open
this
up
see
if
anyone
felt
more
strongly
that
we
should
hold
off
on
beta
or
that
we
should
or
that
this
should
not
block
anyone
have
thoughts
about
port
range
and
what
we
need
to
do
before.
Beta.
D
A
I
like
like
what
the
choices
were
sure,
so
I
mean
basically
I
I
have
a
proposal
here
that
that
shows
a
way
where
we
could
basically
mirror
verbatim
what
network
policy
did
as
a
backwards
compatible
approach.
That
would
solve
the
use
cases
that
have
been
presented
here,
but
that
this
approach,
one
we
don't
need
to
commit
to
it
and
two
does
not
need
to
block
beta.
So
that's
my
proposal.
A
I
haven't
really
provided
much
in
the
way
of
alternatives,
I'm
just
looking
for
confirmation
that
that
is
a
reasonable
step
forward
or
if
anyone
has
any
hesitancy.
This
would
be
a
great
time
to
raise
that.
E
Well,
this
is
john,
I
wrote
a
note
in
there
and
I
thought
about
this
over
from
the
last
meeting,
and
it
just
made
me
my
different
viewpoint
is:
give
me
api
titan
coupled
to
having
a
proxy.
This
is
where
the
port
listener
construct
really
comes
from.
If
I
have
a
proxy,
I've
got
to
have
a
port
listener,
I'm
going
to
have
a
listener
with
a
port
to
attach
to
it,
and
I
kind
of
put
a
use
case
in
you
know.
E
Over
the
weekend,
that's
trying
to
show
maybe
ask
the
question:
if
gateway
api
is
tightly
coupled
to
proxy,
then
okay,
if
it's
not
tightly
coupled
to
proxy,
it
can
be
more.
E
The
example
I
put
in
was
like
aws.
Has
this
thing
called
gateway
load
balancer?
That
basically
says:
hey
just
send
things
to
it
and
access
the
network
service,
and
then
it
does
things
and
sends
it
back
to
you
and
to
sort
of
view.
Our
vision
or
the
hope
I
had
was.
I
could
use
gateway
api
to
implement
that
generic
sense
for
kubernetes.
B
That
might
that
makes
it
your
use
case
made
sense
to
me
john,
and
I
think
it
is
fair
to
say
that
most
of
the
implementations
that
have
implemented
gateway
api
up
to
this
point
have
used
proxy.
B
But
when
we
were
talking
about
the
initial
constructs,
we
tried
to
make
it
that
in
general,
like
I
think,
most
of
us
were
thinking
about
mainly
kind
of
load,
balancer
kind
of
things
which
sometimes
props
you
sometimes
don't
right,
but
they
all
have
this
idea
of
this
narrow
listener
with
a
port,
and
so
that's,
I
think
the
load
balancer
idea
was
really
what
informed
a
lot
of
the
things
we
talked
about
about
gateway
api.
B
That
said,
I
think
that
your
points
are
super
fair
and
that
that
the
that
yeah,
it
should
be
it
should
be
pos.
The
gateway
idea
originally
is
intended
to
describe
a
thing
that,
like
the
the
boundary
at
which
your
network
traffic
goes
from
things
that
don't
know
about
the
cluster
to
things
that
do
know
about
the
cluster
networking,
and
so
like
the
use
case
that
you
have
like,
I
think,
that's
pretty
fair
it.
B
The
outside
bits
don't
care
about
the
fact
that
this
is
in
line
and
the
inside
bits
do
obviously-
and
I
you
know
I've
talked
I've
talked
before
about
having
like-
maybe
something
like
an
ip
route
to
describe
geo
return,
a
lot
of
gre
routes
describe
jre
tunnels
and
that
sort
of
thing
that
would
also
require
like
not
having
a
port.
I
do
think
that
the
the
the
thing
that
rob
has
in
there
is
about,
like
a
port
being
auto
assigned,
like
doesn't
necessarily
have
to
be
the
case.
B
You
know,
like
I
think
that
made
that
that
would
probably
end
up
being.
You
know,
I
think
there
were
some
other
questions
raised
in
one
of
the
other
issues
about
in
my
other
comments
there
about.
If
we
do,
if
we
do
have
ports
be
dynamically
assigned,
how
does
that
work?
I
feel
like
a
lot
of
design.
Work
needs
to
happen
there
for
us
to
be
able
to
be
like
okay,
if
you're
doing
stuff
that
needs
a
port
you
can,
you
may
assign
you
may
assign
a
port
and
if
so,
here's
how
it
works.
B
If
you're
doing
stuff
that
doesn't
need
a
port,
then
he's
then
he's
the
you
know,
he's
what
you
do.
I
I've
I've
also
noticed
feedback
a
couple
of
times
before
that
you
know
the
gateway
construct,
the
gateway
constructs.
We've
got
describe
like
a
lot
of
networking
concepts
really
well,
and
so
a
lot
of
people
want
to
take
them
and
use
them
to
describe
other
networking
concepts
like
we've
talked
before
about
replacing
the
gateway
object.
B
As
like
that,
I
think
the
key
object
that
you
spin
around
with
maybe
a
sort
of
putative
mesh
object
to
handle
some
of
the
service
mesh
use
cases
and
stuff
like
that
and
so
yeah
it
may
be,
maybe
the
the
gateway
we
have
now
like.
I
think
there's
a
few
things
that
we
could
do
here,
but
off
the
top
of
my
head.
I
feel
like
the
use
case
that
you've
supplied
is
sounds
pretty
reasonable,
although
it
seems
like
rob
and
bowie
both
had
things
to
say.
D
B
E
B
E
B
D
Your
super
duper
route
for
tcp
as
an
experiment
just
to
see,
and
you
can
still
use
the
same
mechanisms
for
association
putting
things
across
namespaces
like
attaching
policy
like
all
that
stuff
is
still
reusable
and
that
one
can
be
done
without
even
talking
to
upstream
just
to
see
like
oh
does
this
api
make
sense
in
that
situation,
but
the
key
would
be
that
does
the?
Is
there
any
impact
on
the
api
as
specified
from
gateway
standpoint,
to
make
it
possible
for
you
to
do
this?.
B
Yeah,
so
if
I
can
answer
what
I
think
it
is
john
and
you
can
correct
me,
it
sounds
to
me
like
what
you're
saying
is
that
if
there's
some
way
that
you
can
say
no
ports,
then
that's
really
what
you
need
to
you
know.
The
listener
can
have
no
ports,
then
that
would
be
what
you
need
and
I
think
in
robs
rob's
proposal.
B
A
B
And
the
one
thing,
the
one
thing
I
would
say
there
is
john,
you
said
like
you,
don't
need
a
listener.
I
think
that
in
this
case,
like
like,
listener
is
kind
of
not
a
good
word,
but
it
kind
of
means
that
this
is
the
point
that
you
attach.
The
routing
to
this
is
like
the
bucket
criteria,
and
so
like.
Maybe
the
point
that
costan
made
in
the
in
the
com
in
the
chat
is
fair
that
you
know.
Maybe
we
might
be
better
to
address
this.
B
That
use
case
with
a
with
a
like
a
custom
gateway
style
type
like,
but
like.
I
like.
I
think
that
rob's
point
that
you're,
like
hey
yeah
we've,
got
that
that
his
proposal
provides
a
way
to
represent
all
ports.
Maybe
you
could
we
could
use.
You
could
use
that
and
sort
of
try
it
out.
Yeah
yeah
you're
right
both
just
making
this
and
everything
yeah.
E
B
I
think
the
rob's
proposal
is
that
the
existing
port
field
be
made
optional
and
then
the
you
know
it
becomes.
If
you
specify
an
end
port,
then
it
becomes
the
start
that
the
existing
port
field
means
start
port.
So,
instead
of
having
maximum
minimum.
A
B
Just
have
port
and
import
with
the
endpoint
being
optional,
and
that
way
the
sort
of
the
existing
implementations
don't
need
to
change
a
lot.
They
just
need
to
handle
the
case.
The
port
is
not
defined,
but
like
then,
you
get
the
the
sort
of
all
ports
functionality
like
for
a
relatively
low
cost,
and
the
good
part
is
that,
as
rob
said,
the
reason
that
he
proposed
this
not
blocking
beta
is
that
making
a
required
port
optional
is
not
a
breaking
api
change.
E
A
No,
I
I
appreciate
it
too.
I
I
really
want
to
encourage
additional
use
cases
you're
right
that
so
far
the
maintainers
of
this
project
have
been
pretty
focused.
You
know
we
mostly
come
from
backgrounds
where
we're
implementing
and
or
maintaining
ingress
implementations
of
this
api.
We
want
to
be
very
aware
that
this
api
is
is,
and
can
be
broader
than
that,
but
we're
not,
as
you
know,
aware
of
these
other
potential
use
cases
so
seeing
them
is
very
helpful.
A
I'd
also
echo
bowie's
point
earlier
that
this
this
api
is
very
much
meant
to
be
pluggable
right,
so
we
we
have
these
kind
of
patterns,
these
components,
these
things
that
really
can
be
put
together
like
lego
pieces
or
whatever,
to
build
your
own
route
to
build
your
own
gateway.
If
that
be
the
case,
I
I
hope
that
everything
can
fit
into
the
pieces
we
already
have.
A
B
Thank
you
great,
I
think
cost
before
we
move
on.
I
think
costan
had
a
something
they
went
down.
C
I
can
see
there's
a
lot
of
times
when
users
might
need
either
multiple
ports.
You
know,
for
you
know
80
and
80
80,
but
just
as
examples
or
they
might
need
a
range.
C
You
know,
of
course,
as
as
just
talked
about
you
know,
you
could
use
the
being
optional
could
indicate
you
know,
auto,
assign
or
not
relevant
or
something,
but
it
seems
like
just
having
you
know
as
a
set
port
and
a
endpoint.
C
So
you
really
only
support
a
single
port
or
a
range
of
ports
is
a
little
limiting.
I've
certainly
got
a
fair
number
of
customers
that
need
to
expose
multiple
ports
for
an
application.
A
You
know
that's
a
very
real
use
case,
the
the
early
days
of
the
api
we
we
went
back
and
forth
between,
I
feel
like
10,
different
variations
of
gateway
right
and
the
thing
we
know
of
listeners
today
was
once
I
think,
really
just
a
list
of
ports
and
then
oh
well.
Maybe
we
can
so
it's
all
trying
to
find
that
the
right
abstraction
layer
listener
was
really
meant
to
be
a
initially
like
this
mapping
between
port
and
protocol,
and
so,
if
you
have
additional
ports,
you
want
to
listen
to.
A
You
create
a
new
listener,
and
here
are
the
routes
that
this
port
and
protocol
support.
I
think
that's
still
possible,
but
you're
right
that,
especially
if,
if
we
blur
these
lines
further-
and
we
say
actually
a
listener-
can
support
multiple
ports.
Now
and
now
it's
not
so
much
a
list
of
ports
and
protocols.
It's
within
that
list.
A
You
can
have
multiple
ports
per
item
which
changes
our
initial
assumptions,
some
for
sure
I
so
I
I
I
guess
that
doesn't
directly
answer
your
question
other
than
to
say
that
that
is
a
very
real
use
case
and
it
seems
possible
today
it
seems
possible
today,
but
just
adding
port
ranges
in
general
blurs
the
line
of
how
you
represent
more
than
one
port,
because
right
now
the
answer
is,
you
just
add
a
new
listener
and
now
we're
providing
two
answers.
B
It
does
feel
like
nothing.
We
have
discussed,
keeps
the
setup
block
at
blocking
beta
status,
though
sorry.
A
A
A
B
Okay,
yeah,
I
mean
that
would
mean
you
give
it
a
default
right,
because
if
it's
nil,
then
it's
by
definition
optional,
so
you
need
to
oh,
I
see.
Is
that
how
the
crd?
I
I
don't.
I
don't
know
if
you.
D
B
B
F
Okay,
so
rfcs
typically
have
some
semantics
of
what
happens
if
you
don't
specify
a
port
so
and
and
missing
port
for
http,
for
example,
means
80
or
440
with
https,
and
most
protocols
have
default
ports.
It's
better,
not
to
deviate
too
much
from
you
know,
internet
practices
and
and
also
zero
typically
on
unix
means
that
automatically
locate
the
port.
So
so
maybe
we
should
align
with
the
internet
and
rfcs
a
bit.
I
don't
know.
B
Yeah,
that's
a
good
point
that
yeah
like,
maybe
that
maybe
the
answer
there
is
when
we
do
it
to
say
yo.
If
port
is
nil,
then
the
port
is
defined
like
then
the
port
should
be
picked
by
the
implementation
based
on
the
based
on
the
protocol.
B
The
I
think
it
is
important
to
so.
One
of
the
discussions
that
we've
had
on
that
issue
is
about
dynamic
port
allocation
and
being
able
to
say
you
know,
but
we
need
to
think
really
careful
about
that,
because
if
we
do
something
like
what
kosta
says-
and
we
say
if
you
set
the
protocol
http
and
you
don't
specify
a
port,
then
the
port
is
80.
B
Then
that
means
that
some
implementations
will
expect
that
you
can
merge
multiple
listeners
that
have
port
protocol
http
and
no
port
specified
or
that
specify
http
protocol
and
port
80,
because
those
are
equivalent.
You
know
like
that
means
that
we
have
to
be
a
little
bit
more
clear
about
what
constitutes
murder
listeners
and
what
doesn't
that
which
is
which
I
think
is
fine.
We
should
be
very
clear
about
what
constitution
merging
listeners
and
what
doesn't.
But
yet
we
just
need
to
make
sure
we
we
make
that
set
of
rules
pretty
ironclad,
sorry
custom.
F
I
know
just
just
to
answer
a
bit
what
you
said:
yes
for
http,
for
example,
I
don't
think
we
have
too
many
cases
of
dynamic
port
for
rtp
we
definitely
have,
and-
and
so
so
maybe
protocol
dictates
what
the
semantic
of
what
is,
because
for,
if
webrtc,
for
example,
is
all
dynamic
ports
and
semantic
of
40
is
whatever
rpc
defines
for
http.
B
Yeah,
I
think
that's
pretty
fair
and
I
think
that
yeah
yeah,
I
also,
I
also
thought
of
the
same
thing
when
you
said
ftp
cost
and
I
was
like
people
still
use
ftp
but
anyway,
aside
from
that,
I
think
the
yeah
defining
it
based
on
the
protocol
is
like
feels
like
a
pretty
fair
way
to
do
it,
because
then
it's
like
okay,
then
we
have
to
have
you
know
I
mean
obviously
the
obvious
color
over.
There
is.
B
If
we
do
that,
then
we
have
to
have
like
you
know
the
conformance
test
and
stuff
to
say
this
is
how
the
behavior
works
for
specific
protocols,
because,
as
you
know,
we've
got
specific
protocols
are
available
as
values
in
the
listener.
Anything
outside
those
values
is
a
implementation,
specific
support,
so
it
won't
be.
It
will
never
be
covered
by
performance
tests
and
so
yeah.
I
think
that
that
would
be
the
way
that
we
would
make
that
work.
In
my
mind,
sorry.
C
I
was
just
I
was
thinking
that
you
know.
Maybe
the
way
to
leave
it
for
now
is
change
it
so
that
it's
optional
and
the
way
it's
done.
The
specified
behavior
is
implementation
specific,
but
the
more
as
I've
been
listening,
the
more
I
think
about
it.
I
think
that's
not
a
good
option,
because
I
I
definitely
would
not
want
to
see
a
say
that
unspecified
means
it
defaults
to
you,
know:
port
80
or
443
or
whatever.
C
It
is
because
I
think
we
do
want
to
allow
for
a
non-provided
value
to
represent
something
of
either.
You
know
an
auto
assigned
port
or
maybe
a
use
case
where
the
port
isn't
relevant.
You
know
like
nick,
like
you
mentioned,
you
know
like
pointing
to
a
gre
route
or
something
like
that
where
it's
not
really
relevant.
So
that's
my
thought.
A
Yeah,
I
I'd
agree
with
that
statement
too,
just
as
much
as
it's
tempting
to
go
to
optional
port
right
now.
I
think
that's
actually
a
dangerous
precedent
to
set
it
opens
it.
Basically
it
it
opens
the
door
to
all
kinds
of
undefined
usage
and
we're
not
saying
we
would
actually
define
what
that
means.
We
either
leave
it
implementation
specific
or
come
up
with
a
definition
that
meets
some
some
subset
of
use
cases.
A
I
I
think
what
we
need
to
be
very
clear
about
with
this
api
is
that
we
reserve
the
right
for
fields
that
are
currently
required
to
become
optional
in
the
future,
and
we
can
highlight
that
very
clearly
that
port
is
likely
going
to
become
optional
in
the
future
guard
against
that,
but
that
that
is
very
much.
I
think
that's
already
written
into
our.
A
You
know
api
versioning
guidelines
that
a
required
field
today
may
become
optional
in
the
future
and
and
that
allows
us
to
one
leave
the
field
required
because
there's
a
chance,
we
may
not
move
forward
with
any
of
this
or
there's
a
chance.
We'll
move
forward
with
a
subset
of
the
subset
is
just
port
range,
and
port
range
itself
does
not
require
a
nil
or
optional
port.
It
could
just
be
a
required
value
as
as
the
base.
A
B
That
is
explicitly
allowed
if
you
buy
the
upstream
api
change
guidelines.
Okay,
optional!
Is
that
okay,
because
so
it
comes
down
to
because
of
storage
versions
and
serialization
and
stuff
like
that,
like
you
can
round
trip
a
port
that
was
required,
can
round-trip
into
the
storage
version
where
it
was
required
and
then
come
back
out
to
one
where
it
was
optional
and
still
be
valid,
no
matter
what.
A
Yeah
right,
that
makes
sense,
even
though
it's
very
counterintuitive
yes,
and
it
is
very
strange
and
and
awkward
and
the
way
they
do
it
in
upstream
is
they
do
a
version,
get
a
feature
gate
and
it
it
rolls
out
over
like
two
kubernetes
versions,
we
don't
have
quite
the
same
level
of
flexibility,
but
it
is
very
much.
You
know
something
that
happens
upstream.
A
B
Yeah,
actually,
I
need
to
add
that
to
the
agenda,
give
me
a
second
yeah,
so
yeah
I
I
agree
with
rob.
I
think
that
right
that
for
beta,
I
think
this
is
a
complicated
enough
thing
that
we
need
to
sit
down
and
talk
about
it
properly.
I
would
definitely
encourage
you
know
costume
to
to
if
you
could
write
up
something
about
like
some
of
the
use
cases
you're.
Thinking
of
you
know
just
so
that
we
have
an
issue
with
the
with
the
use
cases
written
down.
That
way.
B
Yeah
agree
yeah.
I
think
that
would
be
really
good
and
anyone
else
who
has
like
layer,
4
use
cases
that
you
know.
I
think
that
we
need
to
have
like
an
issue
for
like
dynamic
allocation
of
ports,
one
for
like
ports
that
require
protocols
that
require
ranges.
B
You
know,
and
those
just
as
separate
like
use
case
issues,
so
that
then
we
can
all
agree
on
like
what
it
means
to
require
a
range
and
what
it
means
when
you're
doing
a
dynamic
one,
so
that
we
can
then
be
all
on
the
same
page.
Then,
when
we're
doing.
B
B
This
process
of
designing
a
surprising
amount
of
the
time
when
someone
says
dynamic
port
allocation.
They
mean
something
completely
different
to
what
someone
else
says
when
they
say
dynamic
port
allocation.
So
it's
good
to
make
sure
that
your
everybody
has
agreed
that
you're
on
the
same
page
by
someone
writing
down.
This
is
what
I
mean
when
I
say
dynamic
portal.
A
Yes,
on
that
note
in
in
my
last
comment
on
this
bug,
there
were
at
there
were
two
interpretations
of
dynamic
port
allocation
covered
by
two
separate
docs,
and
I
didn't
even
realize
they
were
different
until
I
was
at
john.
That
pointed
out
that
these
are
mark
pointed
out.
These
are
different
things
anyway,
so
I
I
I
completely
agree
need
to
be
careful
here.
I
think
I
we
we
have
a
lot
more
on
the
agenda,
so
I
do
want
to
get
to
it.
A
What
I
think
I'm
going
to
do
here,
I've
left
this
comment,
one
so
finish
that
up,
but
I
think
there's
one
more
thing
that
we
need
to
talk
about.
Okay,
sure,
so
I
left
this
comment
on
issue
818
I'll.
Let
this
sit
for
around
24
hours
and
if
you
have
any
other
hesitation
anything
you
want
to
bring
up
specifically
about
if
we
should
block
beta
on
this.
If
there's
something
in
here
that
we
want
to
change
before
beta,
add
a
comment
on
this.
A
B
Yeah,
so
it's
actually
two
more
things.
One
thing
that
bowie
made
a
point
before
about
the
status.
I
think
that,
no
matter
what
we
end
up
doing
with
port
being
not
required
in
the
thing
that,
if
an
implementation
assigns
a
port,
it
will
show
up
in
the
status.
That's
the
that's
the
if
there
is
a
port
relevant
to
the
listener
and
that
the
implementation
is
using,
it
should
be
in
the
status.
B
So
if
you
use
supply,
if
we
end
up
doing
port
optional
and
you
supply
http
and
your
implement
implementation
decides
that
that
means
port
80,
then
that
port
80
will
be
listed
in
the
status
for
that
for
that
listener
right,
so
that
that's
why
the
status
has
a
port
so
that,
if
you
are
consuming,
if
you
are
looking
at
how
these
things
should
be
working,
you
can
look
at
the
at
the
listener
status
and
you
can
say:
okay,
this
listener
has
this
port,
no
matter
what
is
in
the
spec,
because
I
think
that's
a
step.
B
One
thing
that
we
need
to
clarify.
The
other
thing
was
that
they
were
asking
like.
Is
there
another
way,
because,
because
a
http
route
can
have
multiple
parent
refs,
maybe
you
can,
just
if
you
want
to
have
a
hd
appear
out
call
cause.
You
know,
have
listened
on
multiple
ports,
then
you
can,
you
know,
have
the
http
right
refer
to
the
same
gateway
with
different
section
names
with
different
listener
names
to
to
make
it
work?
Yes,
and
I
think
that's
100
right
that
would
that
will
work.
B
B
B
I
think
there's
probably
some
room
for
us
to
tidy
that
up
a
bit,
but
that's
the
kind
of
in
my
mind.
The
current
expectation
just
wanted
to
make
sure
that
stuff
is
clear.
A
Great
clarifications,
cool
cool,
okay,
all
right,
let's
move
on
because
we
do
have
not
not
enough
time,
but
I
do
want
to
get
to
re-encrypt
because
nick
you
brought
this
up
and-
and
also
harry
had
mentioned
this
as
something
that
could
potentially
be
a
blocker
of
v1
beta1
and
I'm
just
again
trying
to
run
through
anything
unexpected
that
could
block
us
and
and
take
a
longer
time
than
just
documentation
or
something
in
this
case.
The
question
is
that
our
documentation?
I
believe
this
is
still
accurate.
A
Our
documentation
says
that
for
hp
route,
tls
can
be
terminated,
plus
re-encrypted,
and
the
confusion
here
is
that
we
don't
provide
any
mechanism
within
the
api
to
handle
that
re-encryption
from
gateway
to
back-end
and
so
at
a
minimum.
These
docs
are
confusing.
A
B
G
Was
looking
at
this
register
right
now
and
back
in
policies
where
we
had
put
in
a
tls
section,
which
was
the
tls
between
the
gateway
to
the
service,
hop
the
upstream
hub,
but
we
removed
that
resource
because
we
have
reference
policy
and
you
know
x,
x,
poly
series
you'll
have
x
resources.
D
I
guess
and
there's
also
a
protocol
which
does
let
you
get
this
information.
F
Yeah
one
once
one
thing
to
mention
is
that
for
array,
encryption
is
not
only
that
it's
very
encrypted,
but
it's
also
what
sound
to
expect,
on
the
other
end,
what
truth
certificate.
So
it's
a
bit
more
complicated
than
just
just
that.
B
Yeah
great,
so
there
needs
to
be
a
stanza
that
holds
the
tls
details
for
the
for
the
gateway.
However,
it's
implemented
to
be
a
client
that
connects
to
the
backend
service
and
that's
the
that's
the
key
part
that
we
need
to
have
like
an
upstream
upstream
tls.
Details
stands
out
that
specifies,
like
you
know,
here's
a
certificate
to
use.
Here's
the
ca
you
use.
Should
you
check
you
know?
Should
you
check
that
the
serving
statistics
should
you
check
the
name
on
the
service
dividend?
So
what
name
should
be
that
sort
of
stuff.
D
A
A
I
think
that's
that's
a
key
question
right
where,
where
does
this
live?
It
is,
I
think,
somewhere
in
this
thread
john
had
mentioned.
Well,
it's
not
in
you
know
the
api
itself,
but
it
there's
nothing
saying
you
can't
build
some
kind
of
extension,
some
kind
of
policy
to
do
it.
That
is
vendor
specific,
that
that
may
not
be
a
good
enough
answer
here.
A
I'm
not
sure
we
need
to
figure
out,
and
I
don't
I
don't
think
anyone
has
spent
the
time
to
figure
out
what
level
of
portability
is
available
for
this
kind
of
configuration
you
know
can.
Can
we
find?
Is
this
the
policy
resource
that
really
is
portable
enough
across
implementations
that
we
can
bring
it
into
the
api
itself?
This
does
feel
to
me
like
something
that
policy
and
policy
attachment
is
designed
for.
B
I
would
say
that,
even
if
we
were
going
to
add
something
to
the
api,
it
would
be
an
additive
would
need
to
be
an
additive
change
like
we
need
to
add
some
spot
to
put
the
details.
You
know
like,
like
I'm
thinking
about
what
we
did
for
contour,
we
literally
in
the
route
we
had.
I
think
in
the
cluster
definition
so
like
in
the
sort
of
the
the
end
point
or
the
back
end
definition.
We
had
we
added
a
spot
where
you
can
supply
tls
details
and
you
can
supply.
B
You
know
ca
some
names
and
other
stuff
like
that.
You,
as
you
say
that
can
absolutely
be
done
with
policy,
but
even
if
we
changed
our
mind
and
wanted
to
add
that
as
an
actual
upstreamable
like
an
actual
upstream
field,
that
would
be
100
added
an
additive
change
that
would
then
you
know
if
it
is
not.
You
know
an
optional,
an
optional
structure.
If
you
added
it,
you
should
enable
this
behavior
and
so
like.
B
If
we
were
going
to
add
it,
as
you
say,
rob
it
makes
sense
for
it
to
be
added
with
extended
support.
I
think
the
advantage
of
adding
it
with
extended
support
later
is
that
then
we
can
mandate
how
the
behavior
works.
You
know
like
the
expected
behavior
rather
than
if
we
limit
the
policy.
B
One
of
the
downsides
of
policy
is
that
for
this
relatively
common
thing
that
you
want
to
do,
then
that
means
that
every
implementation
may
end
up
making
their
own
thing,
and
so
I
think
that
the
the
reason
to
do
this
is
that
it's
pretty
common
to
want
to
like
terminate
and
then
re-encrypt,
and
that,
if
we're
going
to
do
that,
we
should
have
a
way
that
a
common
behavior
across
as
many
implementations
as
possible
and
that
the
way
to
do
that
is
with
a
field.
We
add
a
field
in
the
future.
B
B
Have
it
yet,
but
it's
planned
that
you
know
for
extended
fields.
We
will
have
conformance
tests
that
if
you
have
the
extended
fields
enabled
will
you
know
if
you
have?
If
you
indicate
that
you
support
the
extended
fields,
then
the
conformance
test
will
mandate
we'll
test
the
extended
fields
act
as
we
mandate
they
do.
D
Yeah,
that
makes
sense.
We
should
just
be
clear
that
if
it's
not
that,
because
it's
not
in
the
v1
beta
one,
that
we
are
sort
of
like
closing
the
door
on
the
existence
of
this,
it
just
sounds
like
this.
One
is
a
bit
more
complicated,
so
it
just
needs
more
time
to
understand.
B
G
B
B
Yeah
cool
yeah,
so
the
common,
the
common
extensions
thing
that
was
yours,
custom,
cool
yeah.
So
I
think
I
think
the
the
idea
for
common
extensions
is
for
if
they
are
prototyping
implements
implementation,
specific
things.
The
idea
is
that
implementations
can
bring
and
say
can
say,
hey.
I
think
everyone's
going
to
need
to
do
this.
You
should
you
can
and
should
bring
that
back
to
the
community
and
say
hey.
A
Great,
I
think
we
have
consensus
here.
I
want
to
make
sure
it
sounds
like
we
are
fine
with
leaving
this
out
or
not
blocking
the
initial
beta
release
for
this,
but
that
does
not
mean
this
will
not
eventually
make
it
to
the
beta
api.
A
Just
it
won't
be
in
the
first
release
of
v1
beta1,
and
there
is
significant
interest
in
finding
common
ground
among
implementations
that
can
support
this
and
implementing
that
either
as
an
extended
field
or
a
common
like
a
built-in
policy
resource,
but
also
with
extended
support,
good
okay,
I
will
I
will
run
with
that.
This
is
not
in
the
milestone,
yet
I
will
leave
it
out
of
the
milestone
and
I
will
add
one
more
comment.
This
is
968
I'll,
add
a
comment
just
to
clarify
the
summary
of
our
meeting
today,
cool
all
right.
A
So
let
me
actually
look
at
the
milestone.
My
other
questions
are
really
about
the
bugs.
The
issues
that
I
have
in
here
right
now
is
anyone
aware
of
anything
that
we
should
have
in
this
milestone
that
you
know
really
needs
to
get
done
before
we
release.
That
is
not
right.
Now.
B
I
would
say
the
one:
the
only
thing
that
I
can
think
of
that
we
don't
have
an
explicit
issue
for
is
that
if
people,
if
anyone
has
some
bandwidth,
I'm
probably
not
going
to
get
this
because
I've
got
to
do
all
the
workbook
stuff.
But
if
anyone
has
some
bandwidth
and
would
like
to
have
a
look
at
things,
if
you
could
go
over
like
some
of
the
behavior,
the
objects
that
we're
doing
and
try
and
see
if
we've
got
performance
tests
covering
it.
B
I
think
we've
got
reasonable
conformance
test
coverage
on
the
http
route
for
the
basic
functionality
that
we're
talking
about
and
and
gateway
as
well
implicitly,
because
because
of
the
usage
of
the
shapiro,
but
if
you
we
don't
have
any
coverage
of
like
you
collapsing,
we
don't
have
much
coverage
of
like
merging
listeners
or
you
know
other
things
like
that.
B
So
if
anyone
wants
to
add
any
of
that
stuff,
it's
not
a
blocker
for
beta,
but
the
more
conformance
we
have
before
we
go
beta,
the
better
so
yeah,
and
I
think
that,
having
like
close
to
100
conformance
coverage
is
a
requirement
for
ga.
B
In
my
mind,
maybe
not
all
the
way
at
100
but
close
to
you
know
for
all
of
the
core
stuff
for
sure
and
ideally
for
to
go
to
ga
we
should
have
a
mechanism
for
you
to
say
you
know
what
extended
fields
you
support
and
if
so,
you
know
how
you
test
them,
look
and
and
mandate
their
compliments.
Behavior,
like
I
talked
about,
there's
a
lot
of
work
to
do
to
get
there,
though
a
lot
of
work.
C
I
was
just
gonna
say
my
engineering
team
is
working
on
adding
some
conformance
tests
or
validation
tests
right
now
and
so
over
the
next
six
weeks.
Probably
we
should
be
able
to
contribute
a
fair
amount
that
you
know
we
we'd
like
to
not
be
the
only
person,
only
team
that
contributes
from
where
we're
at
right
now.
So
I
don't,
I
don't
want
to
be
promised.
I
don't
want
people
think
that
I
that
our
engineering
team
is
trying
to
do
all
of
it.
All
that's
left.
B
Yeah
one
of
the
things
that
I
that
I
do
want
to
do
actually
is
to
make
it
so
that
we
have.
I
would
I
would
like
to
have-
and
this
is
part
of
my
to-do
list
for
the
web
hook
is-
I
would
like
to
have
there
be
some
some
conformance
tests
of
the
web
hook.
I
think
rob.
Did
you
do
a
pr
for
that
already.
A
A
variation
of
that
so
not
it
does
not
cover
conformance
test,
but
we
do
have
e2e
testing
now,
where
our
examples
run
through
that
validation.
So
we
have.
We
have
some
coverage,
but
I'd
love,
more
yeah.
B
Yeah,
I
think
what
I
what
I
want
to
see
and
the
reason
I
want
to
have
conformance
tests
for
that,
in
addition
to
the
the
end
test
that
rob
is
talking
about
so
yes
I'll,
explain,
the
conformance
just
a
minute
is
so
for
conformance
tests.
B
B
That
will
that
will,
basically,
if
they
all
pass.
You
are
a
conformant
implementation.
There's
a
lot
of
complexity
there,
because
not
everybody
has
to
implement
all
of
the
api
in
like
at
least
two
dimensions
being
like
core
and
extended
stuff,
and
then
you
don't
have
to
support
all
of
the
objects
you
do
have
to
support
gateway,
class
and
gateway.
But
you
don't
have
to
support
yes
and
yes
gateway.
Api.
B
Slash
conformance
is
the
starting
point,
and
so
the
the
thing
that
I
want
to
have
it
be
is
that
we
run
the
webpool
conformance
so
that
to
validate
that,
your
implementation
is
installing
either
the
web
hook,
that
we
provide,
like
the
binary
web
hook,
that
we
provide
as
a
as
an
emission
web
book
or
you're,
providing
something
that
provides
the
same
level
of
functionality,
which
means
that
if
you
are
doing
something
clever-
and
you
want
to
add
some
additional
stuff
on
top
of
the
web
hook-
that
we,
the
upstream
project
provided,
that's
100,
fine,
the
conformance
test
will
pass
the
web.
B
Will
the
validation
will
be
like
yes
thumbs
up.
You
know
stuff
that
should
be
rejected
by
the
validating
web
is
rejected,
but
you're
free
to
do
that
in
any
way
you
see
fit
as
long
with
what
we're
doing
is
defining
the
testing
to
do
to
say
this
is
what
we
mean
by
a
validation,
and
that
means
that
in
my
mind,
we
want
to
have
extremely
close
to
100
on
the
performance,
the
conformance
testing
for
the
weapon,
because
the
reason
we
have
the
web
hook
is
that
the
validation,
the
kubota
validations.
B
You
have
are
very
important
in
some
cases
for
security
reasons,
but
you
can't
mandate
that
the
cube
build
of
the
open
api
validations
always
happen.
If
nothing
else,
you
can
cue
cuddle,
apply,
dash
dash
force
and
and
just
ignore
them.
If
you
want
and
so
like
having
a
valid
an
admission
web
book
evaluating
admission
web
pool
means
that
the
api
server
will
not
accept
those
things
and
you
can't
force
your
way
past
it
without
disabling,
and
so
that's
why
we
want.
I
want
to
have
the
conformance
tests
for
them,
so
yeah.
A
B
Hopefully,
I
explained
by
what
I
meant
by
conformance
tests
and
there's
so
much
work
to
do
there
if
anyone
else
is
interested
in
this
area
at
all,
it's
probably
been
my
baby
a
little
bit
at
the
moment,
but
you
know,
one
of
the
things
I
would
like
to
see
is
do
at
some
point
in
the
future
is
have
like
conformance
profiles
that
that
sort
of
define
like
right
now
a
lot
of
what
we,
the
first
round
of
beta
objects,
are
effectively
an
ingress
controller.
B
You
know
like
effectively
replicates
what
you
would
call
an
english
controller
currently
that
reconciles
the
ingress
object,
but
like
there's,
no
reason
why
you
have
to
do
that
use
case
so
like
if
you're
writing
a
layer,
4
load
balancer
only
that
doesn't
do
layer,
7
right
now,
the
performance
test
which
will
fail
for
you,
because
you're
not
doing
http
r.
So
there
needs
to
be
a
way
for
us
to
have
conformance
profiles
that
you
can
say
imr
you.
A
Great
great
points,
I
just
want
to
echo
that
last
one
just
the
idea
that
we
have
endless
amounts
of
work
that
can
be
done
if
you
have
any
extra
cycles
and
want
to
contribute
want
to
get
involved.
I
I
think
we
have
some
issues
tagged
that
way,
but
also
just
reach
out
in
slack
sig
network
gateway
api
channel.
I
think
that's
linked
on
our
website
too.
We
will
be
more
than
happy
to
provide
ideas
with
that
with
how
you
can
get
started
depending
on
your
interest
level.
Yeah.
A
Just
to
be
conscious
of
time
we
are
running
out,
I
do
want
to.
I
think
the
answer
to
anything
else
missing
is
no,
but
if
we
have
time
conformance
tests
would
be
great,
more
conformance
tests,
and
it
sounds
like
that's
in
in
in
work
progress.
So
great.
A
The
next
follow-up
question
is,
if
there's
any
hesitation
with
handing
over
the
current
api
as
it
exists
today,
basically
for
sig
network
api
review,
so
with
the
idea
that
we
want
to
ship
what
exists
in
v,
one
alpha
two
as
v,
one
beta
1
in
the
next
few
weeks,
and
we
want
sig
network
api
reviewers
to
review
the
api
as
it
exists
today.
A
Got
a
plus
one
from
bowie
in
chat
and
other
people
seem
in
greek
in
agreement.
I
do
you
know.
Definitely,
if
you
have
any
hesitation
again
drop
some
link
in
slack
or
on
github,
but
otherwise
within
the
next
24
hours
or
so
I'll
assume
consensus
and
we'll
move
on
from
there
and
I'll
reach
out
to
our
sig
network
api
reviewers.
I
think
that's
tim
cal
and
dan
right
now
and
I'll
hand
this
off
to
them.
It
is
near
upstream
code
freeze
time,
so
it's
going
to
be
busy
for
them.
A
B
So
yeah,
I
think,
candace
had
a
thing
in
there.
She
thought
we'd
already
done
that,
so
we
did
it
for
alpha
one.
We
did
it
for
like
releasing
an
actual
alpha
under
the
kubernetes
api,
but
because
we
are
using
the
kubernetes.io
api
group
every
time
we
do
an
api
rev.
We
have
to
do
another
round
of
api,
so
reasons
not
to
do
an
api
route
is.
A
Plus,
plus
we
we're
special,
we
get
to
do
two
rounds
of
api
review.
We
have
all
of
us
reviewing
our
own
api
and
then
we
get
to
send
it
off
to
another
level
for
a
second
set
of
api
reviews,
so
hopefully
that
makes
our
api
extra
special.
I
don't
know
with
that.
I
think
nick
you've
got
the
next
one.
This.
B
Is
a
very
quick
fyi
there's
a
I'm
helping
some
other
focal
vmware.
B
Work
on
this
kep
api
machine
recap
to
add
a
mechanism
to
cr
to
the
cid
object
itself.
The
actual
object
that
defines
crds
that
you
can
do
perl
field
level
feature
gates.
So
you
can.
You
can
have
the
feature
present
in
the
have
the
field
present
in
the
crd
definition
and
then
the
api
server
and
then
our
way
to
say
this
field
is
experimental
and
then
you
have
to
there
will
be
a
mechanism
for
operators
to
say.
Unless
I
opt
into
this
you
know,
then
the
field
will
do
nothing.
B
That
is
the
same
mechanism.
Basically,
the
idea
is
to
replicate
the
same
mechanism
that
upstream
objects
like
ingress
or
service,
or
something
like
that
have
for
with
feature
gates
to
the
api
server.
So
there's
a
way
for
you
to
try
it
out
without
any
for
the
code
to
be
present
without
it
impacting
production
users
until
we're
confident
that
their
production
users
are
good,
so
yeah.
Basically,
I
just
wanted
to
give
everyone
a
heads
up
that
this
cap
is
coming
when
it
is
delivered
it
will
be.
It
will
be
quite
useful.
A
Yeah,
thank
you.
I
took
a
look
at
this
and
it
I
it
just
made
me
sad
that
it
didn't
exist
when
we're
starting
this
api.
It
looks
awesome,
I'm
excited
to
see
it
actually
working,
but
yeah.
Thanks
for
the
heads
up
and
maybe
at
some
point
in
the
future,
we
can
transition
to
this.
I
I
don't
know.
B
But
this
would
effectively
replace
the
current
experimental,
stable
cid
damage
at
a
much
more
granular
and
flexible
level.
So
it's
just
going
to
be
a
straight
upgrade.
A
Yeah,
I
think
it's
going
to
be
a
a
positive
for
us.
You
know
for
now
I
think
the
experimental
stable
is
probably
sufficient,
but
as
we
get
more
and
more
feature
requests
we're
really
going
to
want
something
like
this,
which
is
per
feature.
So
hopefully
the
timing
works
out
for
that
yeah
next,
one
on
the
list,
I
think
jeff
or
mike
either
one
of
you
I
just
wanted
to
make
sure
we
hadn't
dropped.
The
ball
is,
do
you
need
anything
from
us
for
route
delegation
like?
A
Are
you
waiting
for
a
review
or
anything
that
that
we
could
help
with.
C
So
I'm
just
about
ready
to
actually
file
the
the
gap,
and
I
actually
have
a
couple
of
questions
about
that.
For
you
know,
maybe
you
rob
or
nick
if
you
could
stay
on
after
we're
kind
of
done
and
start
recording.
C
The
the
only
major
thing
outstanding
is
the
defining
how
route
status
works
and
yeah
in
which
set
up
steps
up
to
volunteer
to
do,
and
the
the
gap
will
incorporate
some
feedback
from
the
all
the
discussion
and
stuff.
So
I
think
we're
I
should
have
that
they
don't
get
it
up
today.
I
think
it's
not
tonight.
I
think
I'll
get
it
up
tomorrow
by
the
end
of
my
day,
tomorrow,
probably.
B
Yeah
I'll,
I
will
try
and
have
a
rough
cut
of
something
about
status
available
for
you
to
check
out
jeff
in
the
next
couple
days.
I'll
just
do
that
in
a
separate
fmd,
or
something
like
that.
So
then
you
can
just
straight
in
to
fold
it
straight
into
the
into
the
gap
once
we
open
it
feel
free
to
just
in
your
gap,
just
put
like
rap
status
pending
account.
B
A
I'll
I'll
remember
to
stay
on
after
this
just
yeah,
thanks
for
any
any
open
discussion.
The
thank
you
thank
you
again
for
for
the
work
on
that
and
and
to
anyone.
Anyone
on
this
call,
I
tend.
I
know
all
of
us
tend
to
forget
things
if
there
are
pr's
that
we
have
just
neglected,
it's
not
intentional.
A
So
please
just
hang
us
like
on
on
slack
wherever
it's,
not
that
we're
intentionally
trying
to
avoid
reviewing
something.
It's
just
that
it
got
dropped
off
of
the
list
in
you
know
the
queue
in
my
mind.
That's
it
has
a
a
short
list
and
can
only
hold
so
much
with
that.
One
last
thing
I
added
a
pr.
This
is
an
old
issue
that
came
out
of
the
last
api
review.
A
It
was
hey,
why
don't
we
like
th
this
host
name,
intersection
thing
between
http
and
tls
route
and
gateway
is
confusing.
Why
don't
we
draw
something
like
in
status?
So
it's
a
little
bit
more
obvious.
What
is
actually
being
used
here
that
just
kind
of
sat
neglected
and
then
it's?
You
know
what
I
think
it
got
mark
stale
sometime
over
the
weekend
and
nick
picked
it
up,
and
I
thought
oh,
this
will
be
an
easy
change.
It
ended
up
being
larger
than
expected.
A
Sorry,
so
I'm
I
am
not
tied
to
getting
this
in,
but
it
is
here.
I
think
it
is
a
net
positive.
I
will
not
be
offended
if
someone
wants
to
hold
off
on
this.
It
does
have.
It
does
have
the
one
lgtm
right
now.
I
want
to
wait
until
it
has
at
least
one
more
before
going
ahead
with
it,
but
if
anyone
is
at
all
hesitant,
I'm
fine
to
block
I'm
fine
to
just
leave
this
off
for
the
next
release,
so
any
strong
opinions.
A
This
is,
I
think,
the
most
recent
pr
1055.,
I
just
add
them
there,
but
otherwise
I
I'm
hoping
this
is
a
fairly
straightforward
change.
I
apologize
to
anyone
implementing
the
api
because
it
adds
yet
another
level
of
struck
nesting.
Just
you
know
the
inline
type
that
is
annoying
to
work
with,
but
otherwise
I
think
it's
fairly
straightforward.
A
So
I
think
that's
all
we
have
time
for
today,
we've
gone
over
yet
again.
Thank
you
to
everyone
for,
for
sticking
with
us.
Is
there
anything
I
missed
that
we
should
really
cover
in
this
meeting
before
we
call
it.