►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20220425
Description
SIG Network Gateway API Bi-Weekly Meeting for 20220425
A
All
right,
it
is
the
gateway
pi
meeting
for
april
25th.
We've
got
lots
going
on
this
week
and
I
think
I've
monopolized
the
agenda
today,
as
is
often
the
case,
but
especially
today.
So
if
anyone
as
always,
if
anyone
wants
to
add
things
to
the
agenda,
please
do
and
for
anyone
who
either
is
new
to
this
meeting
or
hasn't
been
here
for
a
while.
This
is
a
very
informal
meeting
feel
free
to
ask
questions
at
any
point.
A
Some
of
us
may
have
more
context
than
others.
We've
been
working
on
this
api
for
a
very
long
time
now
and
very
very
appreciative
of
questions
and
comments
and
feedback
and
also,
at
any
point,
feel
free
to
add
things
to
the
agenda
in
this
dock.
I
think
everyone
should
have
added
access
to
it.
So
with
that,
let
me
go
ahead
and
jump
into
the
first
thing
on
the
agenda,
which
is
a
big
pr
that
has
gone
back
and
forth.
A
I
don't
know
how
many
times
now,
but
I
finally
got
some
time
to
come
back
to
it
last
week
and
made
some
big
changes.
So
it's
probably
easiest
just
to
go
right
to
the
deploy
preview
and
look
at
everything
bowie.
One
of
his
comments
was
this
could
really
use
some
diagrams.
A
I
think
I
may
have
gone
overboard
with
diagrams
or
I
may
have
made
those
diagrams
too
complicated,
so
yeah
that
that's
a
thing
so
first
I
created
this
kind
of
flow
chart
that
describes
okay.
Everything
starts
in
v1
alpha.
Is
that
working?
Well,
yes
or
no,
if
it
is
continue
to
beta
and
if
not
it,
either
gets
removed,
or
we
try
again
with
the
new
alpha
api
version
and
similar
with
beta.
A
A
This
may
gloss
over
too
much
or
it
may
include
too
much
information.
I
don't
know,
but
I
just
wanted
to
highlight
these
are
some
diagrams
and
if
they
seem
wrong
or
if
they
seem
confusing,
this
would
be
a
good
time
to
mention
it
and
very
related
diagram
for
these
release
channels,
basically
trying
to
explain,
hey
experimental
channel
is
just
a
super
set
of
everything
inside
stable
channel.
A
So
one
of
the
things
I
mentioned
in
slack
last
week
is,
I
spent
a
lot
of
time,
as
I
was
reworking
this
trying
to
describe
how
the
combination
of
experimental
and
or
no
sorry
of
stable
channel
and
alpha
resources
made
sense
right.
So,
like
I've
got
a
tcp
route,
it's
in
the
stable
channel,
but
it's
only
alpha.
What
does
that
mean?
It
felt
very
confusing.
A
So
the
change
that
I'm
proposing
here
is
that
we
just
say
stable
channel
just
includes
resources
that
have
made
it
to
beta,
and
experimental
channel,
includes
everything
else
that
so
anything
that's
in
alpha
or
beta
resources,
plus
experimental
fields
on
those
resources.
A
That's
that's
it
right,
so
experimental
is
everything.
Stable
is
just
the
things
that
have
made
it
to
beta
or
ga.
That
seems
at
least
slightly
easier
to
describe
than
the
alternative
that
I
spent
far
too
long
trying
to
so
again.
Hopefully
that
makes
sense,
I'm
seeing
some
nod
so
hopefully
that's
the
right
track.
B
I
think
I
think
that
makes
a
lot
of
sense.
I
was
always
a
little
bit
uncomfortable
about
having
alpha
resources
in
the
stable
channel.
That
seemed
weird
to
me
too
see.
I
think
this
is
that's
a
very
elegant
solution.
It's
nice.
A
A
A
I
don't
know
what,
if
anyone
has
better
ways
to
describe
this
flow,
I'm
very,
very
open,
but
yeah,
hopefully
they're
better
than
nothing
or
maybe
there's
better
approaches
too.
B
You
know
one
plus
one,
I
think
yeah.
I
think
that
having
the
having
the
the
flowcharts
is
necessary,
I
think
your
flowcharts
are
always
like
yeah.
They
can
be
intimidating
when
you
first
go
there,
but
it
like
it's.
Actually
it
actually
does
make
it
easier,
because
we
do
have
a
very
complicated
complex,
I
think
is
a
better
way
to
say
it.
Yeah
versioning
story,
so
the
more
we
can
make
it
easy
for
people
to
understand
the
better.
A
Yeah
great
okay,
cool
I'll
run
with
that,
then
that
was
easy.
Okay,
this
is
another
one
that
turned
into
so
I,
basically
all
these
things
are
running
through
feedback
that
we've
gotten
so
far
on
the
api
review
and
specifically
tim's
comments,
and
one
of
his
comments
was
hey.
You
know,
instead
of
trying
to
do
that
type
value
thing
we
do
a
lot
of
you
know
type
prefix
match
value.
A
You
know
whatever
matches
that
type,
we
should
really
have
different
fields,
and
you
know
we
we're
not
going
to
go
ahead
and
retroactively
change
things
that
have
already
made
it
into
the
api
are
used,
but
in
the
case
of
this
example
of
path,
modifier
for
rewrites
and
redirects,
this
is
a
net
new
thing
in
o50
and
we
should
probably
use
that
idea.
So
this
refactors
a
lot
of
that
and
adds
a
union
discriminator.
A
I
they.
So
this
started
as
a
thread
on
kubernetes
api
reviews.
I
linked
it
in
the
agenda
somewhere,
but
it's
also
here,
I
didn't
even
know
this
was
a
mailing
list,
but
it
is,
and
it
got
good
discussion
from
a
bunch
of
different
people.
I
I'm
not
going
to
highlight
the
whole
thread,
but
there
was
a
bunch.
A
The
high
level
is
at
least
of
the
participants
on
this
thread.
Everyone
believed
strongly
that
we
should
move
away
from
generic
value
fields
and
to
per
type
fields.
So
in
this
case
the
rename
is,
you
know,
instead
of
a
single
value,
that
it
goes
from,
that
to
a
replace
full
path
field
and
a
replace
prefix
match
field.
For
those
of
you
who
are
familiar
with
our
filters
api.
This
is
basically
the
same
thing.
We're
doing
for
filters
just
in
one
more
place
that
that's
it.
A
The
thing
that
was
a
little
more
controversial
was
this
tight
field,
and
it's
especially
bad
because
we're
inside
filters
where
we
already
have
the
union
discriminator.
So
you
have
a
union
discriminator
here
and
you
have
one
here
and
if
you
look
at
this,
you
could
say
why
do
you
need
the
type
field?
You
can
just
clearly
see
this
and
this,
and
this
feels
kind
of
unnecessary.
A
I
my
motivation
for
adding
it
here
is
one
it's
consistent
with
what
we
already
have
in
filters
and
two
since
there's
still
some
ambiguity
of
whether
or
not
this
is
a
good
idea,
it's
much
easier
to
have
the
field
and
transition
it
to
optional
in
the
future.
If
we
say
well,
this
isn't
really
necessary,
then
to
retroactively
add
it
later.
We
just
can't
right
the
one
of
the
most
compelling
arguments.
A
I've
seen
for
union
discriminator
at
this
point
is
when
you
have
version
sku,
which
I
think
we're
going
to
have
a
lot
in
our
api.
Where
you
have.
You
know
four
different
implementations
of
this
api.
They
all
support
slightly
different
versions
of
gateway,
api
and
one
of
the
older
implementations
doesn't
recognize
this
new
type.
A
We
have
a
new
substitute
type
in
our
url
rewrite
or
new
filter
type
whatever.
So,
if
we
didn't
have
a
type
field,
what
that
would
look
like
to
them
is
just
an
empty
struct
right.
They
wouldn't
have
any
idea.
They
just
see,
there's
an
empty
struct.
What
am
I
supposed
to
do
with
this,
whereas
instead
they
can
see
hey?
This
is
a
type.
I
don't
recognize
and
they
can
just
say
I
don't
support
type
foo
for
path
or
for
whatever,
which
feels
like
a
better
ux
as
much
as
this
is
a
little
clunky.
A
B
I
think
what
you
said
makes
sense
to
me
yeah.
I
think
that
the
version
skew
thing
is
really
important.
It's
actually
the
reason
why
I
am
generally
a
minus
one
on
the
the
cube
builder
enum
validation,
because
that
does
not
play
well
with
with
a
version
sku
because
and
also
it
doesn't
allow
you
it
doesn't
allow
implementations
to
do
their
own
to
add
in
like
domain
prefix,
their
own
things.
You
know
me
enough
means
that
the
set
is
closed
over
additions
without
a
api
bump.
B
So
unless
you
yeah,
the
api
guidelines
say
like
hey,
enum
implies
that
this
is
all
the
possible
values.
If
you're
not
if
it's
not
going
to
be
all
the
possible
values,
you
need
to
kind
of
make
it
extremely
clear
that
your
thing
needs
to
handle
stuff.
That's
not
in
that
you.
There
needs
to
be
a
default
case,
that's
not
panic
and
so
yeah.
I
think
a
lot
of
these
things
like
where
we
have
a
type.
It
would
be
really
useful,
almost
always
where
we
have
a
type
field
like
this.
B
It
should
be.
We
provide
the
constants
for
the
ones
that
are
supported
in
the
api
that
have
some
level
of
support
in
the
api,
and
then
we
allow
domain
prefix,
prefix
string
so
that
we
can
add,
you
know,
project
contour,
dot,
io,
slash,
some
special
type
right,
like
or
or
so
yeah,
so
implementation
is
going
to
add
their
own
things.
B
If
need
be,
do
I
that
that
that's
kind
of
implying
that
you
know
hey,
we
want
to
be
able
to
have
implementations,
extend
these
things,
maybe
the
for
that
path,
path!
Rewrite
types!
We
don't
want
that,
but
I
yeah
that
that's
why
my
I'm
generally
minus
one
on
the
enums
so
yeah.
B
I
think
I
think
the
idea
of
the
union
discriminators
is
good
and
the
but
the,
but
we
just
need
to
be
really
careful,
as
you
say
that
that
we
handle
what
happens
when
your
controller
expects
a
different
version
of
that
of
the
go
api,
gracefully
as
gracefully
as
possible.
A
Yeah
that
that's
a
good
point
and
brings
up
a
whole
other
thing
of
how
we,
how
we
support
extended
types
where
those
values
would
live
if
they,
if
they
existed,
but
having
a
tight
field
having
a
union
discriminator
here,
does
leave
room
for
that,
which,
I
think
is
a
net
positive.
I.
B
One
thing
I'm
not
sure
about,
though
just
ask
now
is
so
this
union
discriminator
is
enforced
by
the
api,
so
it
is
it
led
by
the
api
server.
No.
A
B
A
A
So
one
of
one
of
the
other
comments
from
tim,
several
comments
from
tim
related
to
this
cap,
the
gap.
Sorry,
I
get
my
letters
right,
which
is
the
address
matching
that
I
was
a
champion
of,
and
I
really
wanted
to
see
this
work
and,
as
I've
tried
to
explain
it
to
tim
in
api
review,
I've
had
a
hard
time
making
it
make
sense.
A
I
so
there
are
a
few
things
that
so
basically
this
is
just
something
that
we
added
to
tcp
and
udp
route.
It
allows
matching
request
based
on
source
or
destination
ip
address.
The
question
around
source
ip
matching
is:
is
this
just
a
firewall
and
if
it's
not
a
firewall,
is
that
you
know?
Is
that
dangerous
to
have
source
ip
matching?
That
does
not
behave
like
a
firewall
when
some
might
expect
it
to
I've
chatted
a
bit
with
shane,
but
he's
been
out
of
office.
A
So
I
only
got
a
brief
discussion
with
him
about
this.
The
perspective
from
him-
and
I
hope
I
is
that
I
I
don't
think
he
was
tied
to
either
of
these,
but
especially
not
source,
address
matching,
I
think
source
address
matching
is
one
of
the
hardest
things
to
one
of
the
one
of
the
riskiest
things,
because
it
could
imply
more
than
it
is
and
two
that
the
use
case
may
not
be
entirely
clear.
A
A
So
my
I
I've
I've
been
going
back
and
forth
on
this
and
I
hope
someone
feels
more
strongly
than
I
do
on
this,
but
I
I
just
have
not
been
in
a
place
where
I
can
provide
a
strong
enough
argument
to
keep
it
in
to
this
rev
to
this
release
of
the
api,
and
so
my
thought
would
be
to
just
put
a
pause
on
this
say:
we'll
come
back
to
it
in
the
next
release,
but
it
it's
not
quite
clearly
understood
or
you
know
we
we
have.
A
We
have
big
enough
questions
that
can't
be
answered
right
now
and
we
don't
have
anyone.
That's
just
you
know
really
needs
this
tomorrow.
So
my
preference
right
now,
I
think,
is
to
remove
this
from
the
api
for
now
and
change
the
status
of
this
gap
to
implementable
or
provisional,
or
something
like
that.
I'm
not
sure
what
the
correct
status
is.
A
I
don't
know
that
that's
a
lot.
It
would
be
the
first
time
we
had
implemented
a
gap
and
then
said
well,
actually
we're
not
sure
about
it,
so
it
is
significant
in
that
sense,
I
think
that
is
why
we
have
this
kind
of
second
layer
of
review
of
you
know
it
made
sense
to
us
at
the
time,
but
you
know
now
that
we're
looking
at
it
again.
A
I'm
not
sure
this
is
just
being
added
as
an
experimental
field,
so
you
could
say:
well
it's
just
experimental.
We
can
remove
it
later,
but
I
do
want
our
experimental
bar
to
still
be
relatively
high.
You
know
I
I
want
experimental,
still
be
something
that
people
use
and
if
we
just
throw
everything
in
there-
and
you
know
50
of
things
that
make
it
to
experimental
get
removed,
not
many
people
will
actually
use
it
so
that
that's
a
lot
of
thoughts
about
this
gap.
A
I
can
try
and
formalize
those
thoughts
in
a
comment
somewhere.
I'm
not
sure
where,
because
this
is
api
review
but
yeah
any
other
thoughts.
Anyone
are
you
in
favor
of
keeping
or
removing
this.
B
I
thought
I
thought
we
did
discuss
a
little
bit
about
the
source
stuff
when
we
did
it
but
yeah.
I
don't
remember
enough
about
the
detail.
It's
like,
it
seems
likely
that
we
were
like
yeah,
okay,
seems
reasonable,
and
then
that
was
it.
So
it
does
make
sense
to
me
that
that
yeah,
we
should
sort
of
hold
this
a
little
bit
more.
It
is
weird
to
it
does
feel
weird
to
sort
of
back
out
something
that's
implemented
already.
B
You
know,
but
you
know
being
able
to
admit
your
wrong
is
pretty
good
and
so
yeah.
I
think
it
feels
to
me
like
the
right.
I
don't
I
don't
disagree
with
anything
you're
saying
it
feels
to
me
like
the
right
thing
to
do
here
is,
to
you
know,
log
a
blocking
issue
for
o50.
B
You
ping
shane
on
there,
so
that
when
so
because
I
mean
it's
his
change
like
we
need
to
talk
to
him
about
it
before
we
do
anything
and
then
you
and
then
put
all
the
stuff
you're
talking
you've
said
on
on
that
issue.
So
then
we
have
a
place
to
talk
about
this
and
we
have
some
notes
of
that
and
that
way
we
can
refer
to
the
we
can
say:
hey
yeah,
we're
going
to
decide
what
we
do
about
this
in
the
issue.
B
You
can
say
I
personally
in
favor
of
taking
it
out,
I
probably
tend
to
lean
yeah.
It
makes
more
sense
to
take
it
out
and
we
do
want
to
keep
that
quality
bar
higher
for
experimental.
I
mean
that
makes
sense,
but
yeah
we
need
to
do.
We
need
to
understand
where
this
is
at,
because
I
think
that
shane
wanted
this
implemented
because
he
needed
it
for
for
their
for
their
controller,
so
their
controller
probably
has
implemented
already.
C
C
You
know
I
might
argue,
for
it
not
being
a
core
but
an
extended
feature,
but
I
don't
think
since
we've
already
got
it
in,
I
don't
think
it
makes
sense
to
pull
it
out.
Certainly
not
the
source
address,
like
I
said
again,
destination
address,
I'm
less
clear
on
the
the
use
cases
for.
D
If
you're
doing
this
sort
of
filtering
the
gateway
and
by
time
it
gets
through
to
a
service
and
then
gets
to
the
the
pod,
the
source
address
is
gone
typically,
so
you're
you're
filtering
at
the
gateway
and
then
you're
seeing
something
at
the
pod.
It
may
mean
it's
different,
I'm
so
struggling
for
to
articulate
this
well,
because
the
thinking
through
my
head
is
like
rambling.
C
I
think
it-
I
would
argue
with
you
a
bit
in
this-
that
there's
multiple
ways
to
actually
indicate
the
source
ip
address,
so
there's
a
couple
of
different
protocols
out
there
that
will
piggyback
it
into
some
additional
information
and
there's
many
cases
going
through
things
like
firewalls
or
load
balancers
doesn't
change
the
source
address.
There's
a
technique
often
used
with
load
bouncers
called
direct
server
return
where
the
incoming
traffic
goes
to
the
through
the
load
balancer,
but
the
actual
response
goes
directly
from
the
services
out.
C
So
I
I
don't
think
that
I
just
wouldn't
agree
with
with
you.
I
think
there's
plenty
of
scenarios
where
the
source
address
is
still
valid.
If
you
will,
by
the
time
it
hits
the
gateway.
D
D
You
know,
breaks
firewalls
because
you
don't
get
certain,
you
don't
get
the
client,
client
and
server
path
so,
but
it
still
works
for
lots
of
use
cases.
Yeah
so
don't
disagree,
but
I
was
adding
more.
If
then
else
but
tight
logic,
which
is
that
was
worry
effect.
A
Yeah,
that's
a
good
point.
I
I
think
one
of
the
one
of
the
things
that
the
concerns
here
for
source
address
matching
specifically
was
the
behavior
is
not
clear.
Is
it?
Is
it
matching
or
is
it
like?
So
if
this
request
doesn't
match
this
set
of
ips
or
this
ip,
what
do
we
do?
Do
we
do
we
drop?
Do
we
drop
the
connection?
Do
we
just
let
something
else
match
it
further
down
the
line,
the
syntax?
There
is
different
and
has
significant
impact,
and
we
have
not
defined
it
here.
A
Well,
I
I
would
say-
and
I
think
you
know
the
the
other
side
of
it
is:
where
does
this
belong
right?
Is
this
really
a
and
that's
related
to
that?
Is
this
really
a
routing
construct
of
just?
This
is
a
way
you
match
requests,
or
is
this
fundamentally
a
firewall
concept
of?
I
only
want
to
allow
requests
from
these
trusted
ranges,
and,
if
so,
should
that
be
on
the
gateway
and
not
on
a
like.
A
You
know
how
do
intersections
work
here
is
that
you
know
if
you
have
two
routes
attached
to
the
same
gateway
and
both
specified
different
set
of
source.
Add
you
know,
I
think,
there's
more
nuance
here
that
hasn't
been
well
defined
and
I
don't
I
don't
feel
equipped
to
answer
those
questions
properly.
D
Would
I
write
some
traffic
to
one
tcp
right
and
other
traffic
to
identity
right
or
how?
What
would
I
write.
B
I
feel
like
the
it's
it's
like.
I
think
the
problem
that
it
feels
to
me,
like
the
problem
of
saying
rob,
is
just
that
it's
underspect
right
like
that
that
we
haven't
that
we
haven't
said,
like
you
know,
what
does
this
address
match
mean
for
the
different
route
types
you're
like?
What
is
this
address?
What
does
the
address
match
mean
for
tcp
route
types?
What
does
it
mean
for
you
to
appear
outside?
B
What
does
it
mean
by
http
route
types
you
like
that
and
and
we're
going
to
have
to
be
specific
about
that,
because
it
can
mean
slightly
different
things
right,
like
for
http
routes,
having
an
address
match
kind
of
means,
like
you
implies,
you
should
only
match.
You
should
only
you.
The
match
criteria
for
the
http
route
should
include
the
ip
addresses
like
the
source,
ip,
the
client
ip
in
this
case
for
http
for
tcp
route.
It
does
kind
of
more
imply
a
firewall
like
behavior,
where
it's
like.
B
Well,
if
you
don't
you,
does
that
mean
that
you
don't
that
if
traffic
doesn't
match
yeah
the
source
for
the
for
the
traffic
to
be
valid,
to
be
sent
off
to
the
tcp
target,
so
the
tcp
route,
john
to
kind
of
answer
your
question,
a
little
bit
in
my
mind,
is
like
it's
kind
of
like
a
way
of
describing
like
firewall
rules
like
to
to
some
extent
you
know,
but
it's
a
way
of
describing
it's.
It
hits
the
thing
where
load
balancers
often
overlap
with
firewalls.
You
know
like
that.
B
Yeah,
like
especially
therefore
load
balancers.
They
often
overlap
functionality
with
firewalls.
Well,
they
will
drop
traffic
that
doesn't
match.
If,
if
you
have
a
set
of
listener,
that
has
a
bunch
of
addresses
on
there,
it's
kind
of
expected
that
it
will
drop
traffic
that
doesn't
match
anything
there,
and
it
will
be
that
traffic
will
be
reset
in
the
same
way
that
a
firewall
would
you'll
be
just
like.
No,
it's
not
open
yeah.
B
That
feels
to
me,
like
the
expectation,
but
I
agree
that
that
it's
not
really
well
specked
out
enough
to
say
that
that
is
the
expectation
right
like
that's.
What
I
would
expect
I'm
using
this
functionality
in
a
layer,
folder
balancer,
but
is
that
what
everyone's
going
to
expect
and
we
haven't
specked
it
out
to
say
this-
is
what
you
must
do?
D
B
A
Right
and
and
if
it
is
about
firewall,
which
is
what
it
feels
like,
should
it
be
long
on
the
gateway?
It's
not
like
right
now.
What
we've
added
is
specific
to
tcp
and
udp
rap.
There
is
no
such
concept
for
http,
and
it
feels
like
this
is
something
that
is
really
it
almost
feels
like.
It
belongs
on
the
gateway
if
it
belongs
somewhere.
A
If
we're
talking
about
pure
firewall
behavior,
trying
to
implement
merging
logic
of
this
route,
says
this,
this
route
says
this
other
thing:
do
we
and
those
together
do
we
or
those
I
get,
probably
or
but
it
feels
messy,
and
maybe
not
all.
This
is
me
trying
to
say
this.
This
feels
like
we
did
not
expect
this
as
as
thoroughly
as
like
now
that
now
that
I'm
trying
to
answer
more
in-depth
questions
about
it,
I'm
realizing.
Oh,
I
really
don't
know.
B
A
B
Mikhail
raises
a
good
question
about
like
what
about
the
personas
who's
going
to
be
the
ones
owning
the.
If
they
are
fireball
rules
who
owns
the
firewall
rules?
Would
you
would
they
need
to
be
convicted
by
the
same
people
who
create
routes?
That
is
a
very
good
question
that
is
100
not
answered.
A
Assumed
that
firewall
rules
are
are
level
above
you
know
like
they're
they're
at
that
gateway
they're
at
that
infra
layer.
I
could
be
wrong
on
that,
but
that
that's
a
really
good
question.
C
There
there's
scenarios
where
I've
certainly
seen
where
example
for
a
specific
service.
C
If
it's
coming
from
a
one
of
the
corporate
you
know
official
addresses,
you
know,
you
know
my
company's
owned
addresses,
you
know,
I
send
it
one
place
and,
and
if
it's
not
you
know,
I
send
it
a
different
one
and
firewalls
don't
really
handle
that
kind
of
scenario.
C
That's
where
something
like
the
gateway
comes
in
to
to
make
those
forwarding
decisions
and
that
could
vary
by
you
know
by
listener
by
listener,
and
it
could
even
be
some
specific
endpoints
with
say
http
that
would
be
permitted
or
not,
but
that's
not
to
say
that
you
know
the
points
about
it
being
under
under
respect.
B
Yeah,
I
think
I
think
that's
the
problem
here.
It's
not
that
we
disagree
that
there's
usefulness
to
it.
It's
that
we
haven't
specced
out
the
usefulness
enough
to
make
it
like
implementable
without
future
problems,
and
that's
the
that's.
The
thing
that
I'm
worried
about
here
is
that
if
we
leave
this
in
there,
other
people
are
going
to
implement
it.
You
know
people
are
going
to
do
stuff
with
it
and
make
assumptions
and
then
we're
stuck
with
those
assumptions.
B
You
know
we're
in
our
we're
back
in
the
ingress
v1
beta,
1
problem,
where
you
know
it
depends
on
what
the
biggest
implementation
says
is
what
we
end
up
doing
or
the
you
know
the
one
that
gets
in
first
or
something
like
that,
and
I'd
rather
have
this
spec
be
a
spec
that
would
define
things
so
yeah
that
that
yeah
sorry
go
john.
D
No,
I
was
thinking
that
routing
is
inherently
you
give
it
a
single
address
with
a
mask,
and
you
know
to
say
this
is
the
route
you
want
to
have,
whereas
firewalls
is
what
rob
is
mentioning
is
ands
and
ours,
which
I'm
not
sure
we
want
to
implement
n's
and
hours
and
more
and
more
complex
things.
It's
a
slippery
slope.
It
says,
oh
here's
a
firewall
rule
and
somebody
said:
oh
now,
you.
C
B
Yeah
yeah,
I
think,
like
I,
I
feel
rob
like
to
be
honest
off
the
top
of
my
head
now.
After
this
conversation
I
feel
like
it
actually
feels
like
it
would
be
much
better
to
put
if
we
want
to
do
address
matching
you
put
it
on
the
gateway.
Like
you
said.
That
makes
far
more
sense
to
me,
because
then,
then,
the,
if
you
have
the
address
match
at
the
listener
level,
then
it
can
have
then
by
implication
it
has
different
semantics
based
on
the
route
type.
This
is
that's
attached
right.
B
That
means,
if
you
have
address,
address,
matching
on
the
listener.
Somehow,
then
that
means
that
it
implies.
If
you're
doing
a
http
route
you're
going
to
use
whatever
mechanism
you
can
to
recover
the
client
ip,
maybe
that's
exported,
for
maybe
you
know
h.a
proxy
proxy
protocol
or
some
other
thing
right
like
you
know,
but
the
the
point
there
is
that
the
the
intent
is
very
clear
that
you
this
listener.
B
It
requires
you
to
be
on
these
things
and
then,
if
you
don't,
if
you
have
another
listener,
that
doesn't
then
that
you
kind
of
do
in
a
firewall,
but
you've
got
a
catch-all
at
the
bottom.
If
you
don't,
then
there's
no
match,
and
so
it's
pretty
clear,
there's
no
match
right
like
and
you
don't
have
to
worry
about
merging
merging
behavior,
because
listeners
in
that
case
those
having
address
matches
means
the
listeners
can't
be
merged
and
that's
the
you
know,
and
and
then
you
and
your
list
can
also
is
in
one
place.
B
So
you
don't
have
to
worry
about
merging
multiple
lists
that
off
the
top
of
my
head.
That
makes
actually
a
lot
more
sense
and
it
immediately
makes
the
spec
much
clearer,
whereas
if
you
have
the
the
current
thing
has
the
problem
as
rob
says
that
if
you
have
like
10
tcp
routes
that
all
have
different
address
match
things
in
there
and
they're
all
supposed
to
go
on
to
one
listener,
how
do
you
coalesce
that
rule
set
as
john
says,
into
into
a
single
rule
set
that
makes
sense?
B
You
know
like
how?
How
does
how
does
that
interaction
work
you
and
most
of
the
time
the
thing
that
you're
going
to
be
programming
is
going
to
want.
B
You
know
some
it's
going
to
need
to
to
do
that
sort
of
the
address
matching
at
some
reasonably
sort
of
lower
level
than
that
yeah.
So
it's
it's.
It
seems
weird
and
it
seems
like
it
could
be
very
difficult
to
implement,
as
john
says
so
yeah.
I'm
definitely
a
plus
one
for
taking
this
out
for
now
and
looking
at
bringing
it
back
to
bring
it
bring
it
up
to
the
listener,
rather
rather
than
doing
this
but
yeah
we
need
to
talk
to.
A
Yeah,
no,
I
I
talked
with
him
briefly.
I
don't
think
they've
implemented
it
yet,
but
I'll
follow
up
when
he's
back
in
in
office.
A
To
be
sure,
I
agree
next
step
is
an
issue
discuss
this,
discuss
our
hesitation
with
the
current
state
and
see
what
what
kind
of
feedback
we
get
from
there
again
like
like
everyone
is
saying
this
is
a
good
concept,
but
maybe
not
in
the
right
place
yet,
and
you
know
that
that's
why
it
helps
to
have
these
extra
layers
of
review
and
why
it
helps
to
try-
and
you
know
I
spent
too
long
trying
to
explain
and
justify
this
and
I
couldn't
make
it
make
sense
to
myself
and
so
yeah
anyways
cool,
all
right.
A
So
this
is
I
I'll
take
that
action
item.
I
can
create
an
issue
out
of
this
and
well,
while
we're
here.
I
think
we,
we
talked
a
lot
about
source
address,
matching
destination
address
matching
the
use
case
that
I
was
thinking
of
and
most
familiar
with
was
really
for
egress
right
for
for
the
other
side
of
this,
which
I
think
is
a
fairly
unimplemented
un,
less
understood
concept
that
could
be
used
for
this
api
right
of
I
want
to
adjust.
A
A
A
I'll
take
that
as
just
me,
okay,
well
I'll
I'll,
follow
up
on
that.
That
conversation
then
cool
all
right
one,
that's
I
think
less
controversial.
Now,
thank
you
for
for
the
good
discussion
here.
This
is
one
request
to
add
one
more
cherry
pick
to
the
oda
for
release.
I
think
steve
had
mentioned
this.
A
A
A
What
I
would
like
to
do
out
of
this
vr
is
actually
cut
a
release.
I'd
like
to
cut
out
043
based
on
this
there's
a
few
I
think
entirely
web
hook
related
improvements
that
we
haven't
released.
Yet
it
seems
like
it
would
be
good.
It
also
would
finally
test
out
our
full
end
to
end
image
tagging
now
that
we've
seen
it
work
once
yeah.
A
A
A
I
keep
on.
I
keep
on
forgetting,
that's
not
merged
it's.
It
feels
like
forever
ago,
yeah.
Okay,
thank
you,
yeah.
Your
that
payout
will
merge
that
one
mike,
I
don't
think
mike
is
on
this
call.
I
think,
there's
just
one
tiny
bit
left
of
this
one,
and
maybe
the
the
bit
that's
left
doesn't
need
to
be
part
of
the
b1
beta
1..
We,
I
think
we
got
the
most
important
things
out
of
this
one.
A
Let
me
leave
that
one
open
pr
will
close
this
this
one.
I
I
I'm
going
to
save
documentation
until
my
actual
change
comes
in
because
everything
about
this
is
you
know
the
api
structure
is
changing
with
redirects
and
rewrites
yeah.
A
Okay,
this
didn't
actually
go
anywhere.
I
thought.
Okay,
so
mike
had
a
number
of
issues
that
really
define
this.
I
think
nick
while
you
were
out,
and
one
of
them
made
it
into
the
milestone.
A
Yes,
the
one
quadruple
1
11
11
issue
is
the
one
that
we
added
to
the
issue,
and
it
was
really
suggesting
that
hey
we've
got
these
kind
of
inconsistent
conditions
and
reasons
and
status
across
different
resources
and,
where
possible,
we
should
try
and
use
the
same
terminology.
A
I
think
this
was
really
well
defined.
Thank
you
to
mike
for
this
one.
I
think
we
just
need
someone
I
well.
I
can
chat
with
manhattan
to
see
if
she's
able
to
work
on
this
or,
if
not
or
go
ahead,
nick.
A
Okay,
so
this
one
probably
has
someone
to
work
on
which
would
be
great
the
we
got
a
yeah
something
to
fix
this
one
is
already
in
this
yeah.
This
is
a
really
tiny
pr.
If
anyone
has
a
chance
to
review
it,
it
just
re.
It
just
removes
some
confusing
lines
from
godox
I
need
to.
I
need
to
have
some
or
anyone
needs
to
have
a
pr
for
this
v1
alpha
one
deprecation.
A
I
should
have
done
this
a
lot.
We
should
have
done
this
a
while
ago,
but
I
think
it's
just.
This
will
be
deprecated
soon,
probably
with
the
v0500
release,
and
I
don't
know
that
there's
much
else
to
say
I
I
thought
about
just
adding
a
header
to
all
of
our
v1
alpha
one
docs
pages.
A
and
I
think
that's
all.
We
need
cool
okay.
A
A
We
are
making
progress
slowly,
but
surely
any
other
things
that
we
should
add
to
v1
beta1,
or
does
that
feel
like
a
complete
list,
actually
just
kidding
that
that
issue
I
need
to
create,
should
go
in
this
milestone.
Absolutely
that
should
that's,
probably
the
one.
A
Cool
okay,
and
with
that,
let's
move
over
to
issue
triage,
I
don't
think
we
have
a
whole
lot
of
activity
over
the
past
week.
This
one
is
going
to
be
fixed
by
my
pr,
that's
just
again,
because
we
hadn't
cherry
picked
back.
The
web
hook
search,
end
fix
and
this
one.
A
I
think
we
just
need
help
triaging
this,
I'm
not
sure,
and
I
think
there's
already
an
issue
that
covers
most
of
these
I
can
spend
it
looks
like
harry,
has
already
done
some
time
reading
through
this,
but
I
don't
know
if
anyone
has
some
time
it
can
help
triage
and
understand
what
the
request
is.
That
would
be
good
10.74.