►
Description
Service APIs Bi-Weekly Meeting (APAC Friendly Time) for 20220110
A
All
right,
we're
recording
it
is
january.
10Th,
2020
2022
didn't
take
long
to
make
that
mistake
and
we've
got
lots
going
on
today.
So
let
me
start
off
with
the
the
v0.4.1
release.
A
There
is
one
pr
that
I'm
hoping
to
still
get
in
this
is
by
steve.
Well,
no,
actually
this
is
me
cherry
picking,
steve's
pr
into
0.4.
I
would
love
to
get
this
one
in
as
well.
I
don't
know
if
brian
is
on
this
cut.
Yeah
brian's,
not
here
brian,
had
a
good
question
about
this.
Why
I
was
even
trying
to
cherry
pick
this
one
back,
but
essentially
it's
it
is
tightening
validation,
which
is
something
we
consider
backwards
incompatible,
so
we're
trying
to
get
those
changes
out.
A
Well,
it's
well.
The
api
is
still
in
alpha.
It's
it's
really
more
of
a
technicality.
The
the
thing
that
we're
preventing
from
happening
has
no
meaning
you
know
redirecting
to
a
wild
card
domain.
Just
I
did.
I
don't
think
it's
implementable,
so
I
don't
think
this
is
a
big
thing.
I
just
would
rather
have
it
fixed
sooner
than
later.
So
thanks
to
steve
for
finding
this
one
and
yeah.
If
anyone
has
time
to
take
a
look
at
this
pr,
I'd
love
to
get
it
in
sooner
than
later,
yeah.
A
That's
all
for
this
one
cool
all
right.
The
next
one
is
anyone
interested
in
being
part
of
a
kubecon
maintainer
track
session.
This
year
we
have,
I
think,
a
decent
chance
of
getting
in
getting
a
session
in
as
a
maintainer
track
for
gateway
api
this
year.
Kubecon
this,
the
kubecon
eu
this
year
is
in
valencia
in
may,
I'm
not
sure
what
form
that
will
take
they're,
definitely
planning
on
a
hybrid
approach,
as
with
previous
kubecons
I,
but
we
would
have
35
minutes.
A
We
have
room
for
up
to
four
speakers,
but
it's
worth
noting
that
if
you
are
someone
who
would
already
be
on
another
maintainer
track
session,
you
can't
also
be
on
this
one.
You
can
only
be
on
one
maintainer
track
session
for
a
conference.
Apparently
it's
not
completely
guaranteed,
but
that's
that's
the
extent
of
this
one
so
yeah
I
if
anyone's
interested,
if
you
can,
I
guess,
raise
that
now
or
message
me
afterwards.
I'd
love
to
have
a
you
know,
a
good
set
of
people
to
help
present
gateway
api.
A
I
think
be
great
to
have
some
of
the
people
who
have
been
contributing
to
gateway
gateway.
Api
actually
be
there
to
talk
about
it.
So
again,
that's
may
16
to
20,
but
we
do
need
to
get
a
submission
in
ideally
soon.
I
think
we
have
until
february,
but
I'd
love
to
get
something
together
this
week,
if
possible.
A
Just
so,
we
have
an
idea
of
the
speakers
that
might
be
interested
and
whatever
else
so
yeah
if
anyone's
interested
just
just
ping
me
and
we
can
get
you
on
the
list-
cool
all
right
james,
I
think
you're
here
I
meant
to
add
more
than
just
this
james
has
started
a
good
conversation
around.
A
What
helpers
would
look
like?
I
think
we've
had
this,
this
broad
idea
that
it
would
be
helpful
to
have
some
basic
helper
library
included
in
gateway
api
itself,
which
is,
I
think,
a
very
good
idea,
someone
that
we've
talked
about
several
times
now,
but
james
is
taking
the
first
step
and
actually
trying
to
sketch
out
what
an
implementation
would
look
like.
James
has
this
pr
here,
I
think
he's
also
he
shared
a
couple
other
gists
with
me
as
well
of
different
variations
of
this
take,
and
maybe
james.
B
Yeah,
can
you
hear
me,
am
I
unmuted
correctly?
Okay,
good
good
good,
so
I'm
have
a
colleague
who's
working
on
a
gateway,
api
implementation.
So
my
perspective
is
coming
mainly
as
a
as
a
reviewer,
not
not
as
a
as
a
direct
author
of
some
of
this
stuff.
B
So
there's
some
parts
around
the
api
that
are
a
little
awkward
and
you
know
one
of
the
things
we've
done
is
we've
typed
a
lot
of
the
strings
so
that
we
can
attach
validation
to
it
by
the
time
you
get
that
out
into
into
real
code,
though
it
just
is
a
little
your
quality
of
life
as
a
go
language.
Author
suffers
a
little
because
you
have
to
cast
everywhere.
B
B
So
that
was
the
pr
that's
there.
That
adds
some
add
some
helper
types,
two
directly
into
the
go
api
types.
So
I
know
rob
felt
a
little
uncomfortable
about
you
know,
modifying
the
types
that
are
used
to
generate
the
cids.
B
So
there's
a
couple
of
other
approaches
we
could
take
so.
B
C
A
Okay,
yeah,
it's
supported
it's
just.
It
hasn't
been
done
in
the
the
thing
that
set
my
alarm
bells
off
is
just
it's
not
the
way
it's
done
in
upstream,
but
that
doesn't
necessarily
make
it
good
or
bad.
It's
just
unfamiliar
to
me.
It
is
definitely
easier
to
do
it
this
way
than
the
alternatives
that
I
that
james,
I
think
is
probably
about
to
talk
about.
B
Yeah,
but
I
mean
from
a
separation
of
concerns,
point
of
view.
I
think
it's
like
it's
it's.
It
would
be
nice
to
separate
the
concerns
of
declaring
an
api
from
the
concern
of
you
know,
using
declaring
an
api
for
the
kubernetes
compared
to
declaring
an
api
for
go.
So
they
are.
I
do
agree.
They
are
things
that
you
can
separate
and
it's
good
to
keep
those
boundaries
pretty
clear.
B
Let
me
just
post
a
link
to
the
other
gist
if
you
want
to
bring
that
up,
rob
so
here's
here's
another
approach,
which
is
a
separate
package,
called
a
reference
here,
and
the
idea
here
is
to
take
one
of
the
reference,
various
reference
types
and
just
be
able
to
deal
with
them
in
a
sort
of
generic
way.
So
this
is
just
type
switching
so
say
I
want
to
get.
You
know
at
some
point.
B
Your
controller
used
to
resolve
references
to
something-
and
you
say
and
lots
of
our
references
have
this
semantic
of.
If
the
namespace
is
unspecified,
then
you
use
the
namespace
of
the
object.
That's
the
ref,
the
referee
right.
So
we
can
write
namespace
of
in
this
in
this
kind
of
generic
way,
we're
giving
a
parent
object
and
some
reference
type
and
consolidating
that
so
that's
code
that
I've
seen
in
a
couple
of
places
and
people
end
up
doing
doing
similar
things.
B
Getting
the
name
of
getting
the
name
of
a
reference
is
also
something
everybody
needs
to
do,
and
it's
a
little
awkward
because
sometimes
it's
a
string.
Sometimes
it's
a
pointer
validation
in
all
cases.
I
think
validation
defaults,
the
pointer
to
something,
but
then,
as
a
code
reviewer,
it
feels
a
little
uncomfortable
to
always
depend
on
the
validation
having
been
run
so
should
you
require
a
code
to
check
for
a
millpointer
or
not?
Well,
it's
sort
of
this
non-local
decision
right
is
has
has
this
thing
been
validated?
B
B
B
B
When
we
just
have
to
do
like
little,
you
know
copy
pasting.
Little
wrapper
wrapper
types
for
all
the
references,
so
I
guess
the
question
is:
will
people
in
the
controller
community
find
these
sorts
of
helpers
useful?
I
think
there's
nothing
very.
You
know
there's
nothing
very
novel
here.
It's
just
about
improving
the
quality
of
life
for
for
the
community,
and
you
know
maybe
consolidating
some
code,
some
generic
code
in
in
the
gateway
api
repo,
so
that
we
don't
have
to
duplicate
it
across.
A
Yeah
thanks
thanks
for
bringing
this
up,
and
I
have
to
say
this-
this
has
resonated
with
me
because
I
like
earlier
today,
I
was
reviewing
some
code
where
we
were
doing
comparisons
that
awfully
similar
to
this.
That
could
benefit
from
a
shared
helper.
You
know
and-
and
I
think
anyone
who's
implementing
this
api
is
going
to
have
similar
frustrations
with
all
our
variety
of
types
that
we're
using
here.
A
So
I
I
think
that
there's
a
really
strong
value
in
having
something
like
this
in
the
gateway
api
project.
I
think
I
have
less
of
a
strong
opinion
as
far
as
which
approach
we
take
other
than
that
I
do
like
james
has
already
alluded
to.
I
do
like
something
that
is
separated
from
tight
definitions,
but
I
that
the
details
of
how
we
actually
implement
these
helpers
are
not
quite
as
clear
to
me,
but
just
I
I'm
glad
that
you're
pushing
this
forward,
because
I
think
it's
going
to
be
helpful
to
anyone
implementing
the
api.
C
B
Yeah,
that's
the
the
problem
is
that
for
these
kind
of
little
trivial
helpers,
if
you
end
up
having
to
return
errors
out
of
places
which
oh
I'm
just
getting
the
name
of
something
then
handling
the
propagate.
Just
propagating
the
error
ends
up
being
more
code
than
dealing
with
the
underlying
type
in
the
first
place.
So
it
really,
I
think
it
discourages
the
use.
D
B
I
think
that's
I'm
I'm
kind
of
as
kind
of
leaning
towards
the
second
approach,
where
you
wrap
a
interface
around
or
to
your
rapid
interface
around
all
your
reference
types.
I
think
that's
preserves
the
typing
better
and
seems
pretty
clean.
I
think
it'll
end
up
being
reasonably
useful.
A
E
Cool
all
right:
well,
hey
thanks!
Thanks
for
getting
this
started,
so
I
think
it
should
be.
We
should
be
able
to
care
like.
B
A
Yeah
there's
I
I
agree,
reference
policy
is
gonna,
be
a
good
one
to
make
a
bit
more
generic
and
and
add
some
helpers
around.
I
think
also
how
we
end
up
merging
route
logic
like
the
route
gateway
relationship,
I
think,
is
another
one
that
feels
prime
for
some
form
of
shared
helpers
around,
but
the
other
there's
a
lot
of
room
for
for
developing
shared
helper
code
in
here,
but
you
have
to
start
somewhere-
and
this
is
a
good
good
starting
point.
A
Cool
all
right.
Well,
thanks
for,
let
me
before
I
forget.
Let
me
add
this
to
the
agenda,
so
I
don't
lose
a
reference
to
it,
but
yeah
great
all
right.
So
the
next
few
things
are
just
pr
and
issue
triage.
I
don't
know,
is
shane
on
this
cupcake
shane
you're
here
great,
I
don't
think
ciao
is
here
all
right,
so
the
first
one
is
actually
ciao
pr
to
add
this
gap
for
port
matching
support
and
as
of
now
I'd
say,
it
seems
like
no
one
feels
very
strongly
about
this
one
way
or
another.
A
I
it's
one
that
that
I
support
getting
in,
but
I
I
wanted
to
get
leave
some
opportunity
for
others
to
add
feedback.
Add
comments,
add
any
kind
of
hesitation
you
might
have
around
this,
so
I
guess
maybe
I'll
open
it
up
now
does.
Does
anyone
feel
strongly
about
the
idea
of
basically
adding
port
to
parent
ref,
which
is,
I
think,
really
the
summary
of
this
gap?
I
think
james,
you
added
one
comment
below
here.
A
C
C
F
I
I
think
I
would
like
to
see
an
example
use
case
using
this
yeah,
if
kind
of
example,
where.
B
Similar
to
my
comment,
because
I
had
to
I
think
to
understand
the
use
case,
I
had
to
go
back
to
the
original
issue,
which
was
something
about
service
it
being
hard
for
service
mesh
to
make
use
of
the
section
name.
E
A
Yeah
that
that's
the
primary
motivator
for
this,
as
I
understand
it,
is
again
to
support
attaching
routes
to
specific
ports
and
in
a
mesh
use
case,
but
I
I
see
this
also
being
generically
useful
as
a
way
of
attaching
routes
to
a
port
on
a
gateway.
So
to
me
they
seem
similar.
A
It's
a
more
generic
parent
attachment
mechanism,
but
it
is
most
useful,
at
least
from
the
outside,
looking
in
for
the
mesh
use
case,
so
yeah,
so
some
examples
of
how
that
would
work
for
both,
I
think,
would
be
very
helpful
here.
That's
a
good
point.
F
G
This
is
so
in
this
case
we
are,
I
mean
we
have
already
walked
away
from
that
line,
but
changing
implementations
of
changing
I
mean
changing
gateways
will
require
further
more
careful
changes
in
the
routes
as
well
right
like
if
your
route
is
targeting
different
implementations
like
we
are
leaking
more
and
more
essentially
right
from
from
that
abstraction
down
to
routes.
A
So
I
think
what
you're
saying
is,
I
I
remember
like
a
key
goal
of
gateway.
Api
was
that
you
could
change
the
underlying
implementation
of
the
gateway,
and
no
one
at
a
real
level
would
need
to
care
basically
right
that
no
one,
no
app
developer
needs
to
worry
that
I
think
that's
still
possible,
like
so
maybe
explain
a
bit
more
how
this
would
pull
us
away.
I
mean.
G
G
Where
you
don't
like
you,
don't
go,
you
don't
have
to
go
and
change
the
the
code
inside
the
route.
Okay,
you
change
it
inside
the
gateway
section
of
the
listener
section
and
you're
good.
That's
like
one
area
where
I
mean
hiram's
law
right
like
an
api.
Something
is
possible,
it
will
be
used.
So
so
that's
that's
my
hesitation
here.
A
Okay,
I
I
get
that.
I
see
what
you're
saying
it's
one,
it's
more
things
to
support,
but
two
it's
the
idea
that
instead
of
users
using
this
kind
of
section
name,
abstraction
users
are
going
to
see
port
and
say
hey.
I
should
use
port
to
attach
to
my
gateway
and
because
that's
being
used
as
your
gateway
attachment
mechanism,
it
means
that
your
gateway
admin
is
going
to
have
a
difficult
time.
A
G
Yeah
this
this
field
so
smells
more
like
thoughts
or
numbers
and
names
inside
upstream,
and
I
think
that
causes
a
good
amount
of
confusion.
I
think
in
the
user.
So
I
think
this
this
is
like,
although
we
have
two
separate
fields,
but
we
are
going
essentially
towards
that.
So
that's
my
hesitation
and
a
minor
concern.
G
C
A
Yeah
yeah
I'll,
follow
up
with
them
and
I'll
add
some
of
these
comments,
just
as
a
follow-up
on
the
gap
itself,
any
other
comments
or
concerns
on
the
skip.
C
I
think
like
in
terms
of
coupling
that's
more
of
a
users
ended
up
using
port
because
you
can
always
say
hey.
If
you
don't
want
coupling,
you
can
use
section
name,
but,
more
importantly,
it's
wet
like
why,
in
what
situation?
Would
you
use
port
and
it's
required-
and
I
think
that's
not
probably
coming
through.
A
C
Like
we
would
just
recommend
everyone
use
section
name
so
because
it's
less
coupling.
B
B
A
A
Implementation
is
going
to
have
to
recognize
the
version
of
the
crd,
the
max
version
of
crds,
that
it
supports
and
then
log
some
kind
of
warning
when
it
detects
a
crd
that
that
is
newer
than
it
is
aware
of,
or
that
is
an
unrecognized
version
because
that's,
I
think,
that's
essentially
the
the
bounds
in
which
that
would
happen,
and-
and
in
that
case
I
think
you
need
to
log
errors-
warnings
whatever
whatever
it
might
be.
B
C
C
A
Yeah
you're
right,
so
I've
spent
a
lot
of
time.
Thinking
about
this.
This
problem
and
part
of
this
is
the
the
whole
bundle.
Versioning
that's
been
proposed
right,
so,
starting
with
0.5.0
our
next
minor,
hopefully
beta
api
release,
every
crd
is
going
to.
Actually,
I
think
it
yeah
it's
already
in
the
code.
Now
every
crd
is
going
to
include
two
annotations,
one
being
the
track
at
the
channel,
it's
on
so
stable
or
experimental
and
two
being
the
bundle
version
that
it
was
released
with.
So
I
think
right
now
we
have
0.5.0.
A
Dev
is
the
track
that
the
bundle
version
that
our
crds
on
master
have.
But
the
idea
is
that
any
consumer
of
the
api,
any
any
client
of
the
api,
is
going
to
look
at
that
bundle
version
and
say
I
recognize
this.
I
support
this
or
this
is
a
version.
I
don't
recognize
and
I
don't
know
anything
about,
and
therefore
I
should
vlog
some
kind
of
warning
that
I
don't
support
some
form
of
function.
A
G
A
And
so,
if,
if
you
consider
that
those
changes
would
only
ever
occur
along
the
boundary
of
a
version
bump
like
and
what
I'm,
what
I'm
meaning
is
not
like
a
v1
alpha,
2
version
bump,
I'm
meaning
a
bundle
version
bump,
then
I
think,
as
an
implementation
you
can
safely
say
I
I
support
the
concepts
of
the
apis
that
I
like.
These
are
the
the
versions
I
recognize
of
this
api,
and
if
I
see
something
like
outside
of
those
bounds,
I
will
do
x.
A
A
It
is
it's.
A
A
Yeah
there's
this
this
is:
I
had
a
gap
relatively
recently
that
was
about
how
we
would
handle
this
release
versioning,
and
I
hope
this
approach
is
sensible,
but
yeah
that
we're
trying
to
build
out
a
whole
new
system
of
doing
things.
So
hopefully,
hopefully,
this
approach
makes
sense
cool
any
any.
Last
comments
on
this
gap
or
versioning
in
general.
H
Hey,
hey
everybody,
not
so
much
on
the
versioning,
but
the
the
gap.
So
it
seems
to
me
I
think
so,
where
I
have
pause
is
some
of
the
confusion
this
might
bring
up,
and
this
is
partially
toward
to
harry's
point.
So
there's
section
name
which
the
way
name
is
listed
in
listeners
is
a
unique
key.
So
there
needs
to
be
one
of
them.
H
A
The
road
I
I
can't
remember,
who
suggested
it
might
have
been
james,
had
a
comment
that
was
awfully
similar
to
to
this
in
scope
of
is
port
sufficient
or
are
we
just
going
to
add
a
protocol
next
or
whatever
other
component
would
be
next
in
line
here
and
that
that's
very
possible.
I,
I
think,
you're
right
that
that
does
feel
like
that.
A
The
slippery
slope
we're
on
that
we
could
very
easily
keep
on
expanding
this
port,
I
think
is,
is
a
pretty
well
understood
concept
to
me
and
at
maz's
protocol,
I
suppose,
and
but
I
think
just
because
we
could
add
more
at
this
point.
I
don't
know
that
we
need
to.
I
think
that
port
has
a
fairly
clear
use
case
and
we
have
demand
request
whatever
for
it,
whereas
at
attaching
to
protocol,
for
instance,
or
to
I
don't
know
what
we
can
already
attach
to
host
name.
C
A
Most
mostly
yes,
but
http
route,
you
could
say
I
only
want
to
listen
on
like
http
versus
hps.
I
think
we
have
a
differentiation
on
the
listener
right.
So
yeah
you
yeah,
I
I
don't
know
I
should.
I
should
take
a
step
back
though
mikhail
it
is.
Is
that
something
that
you
specifically
have
a
use
case
for,
or
is
it
just
kind
of
an
abstract
idea.
I
Hello
everyone-
this
is
michelle,
michael,
so
I
just
wonder
if
this
new
field
reflects
the
personas
of
the
gateway
apis
and
like
for
non-non-service
mesh
use
case,
like
do
application
developers
who
publish
the
http
routes.
Do
they
really
need
to
know
like
the
this,
this
this
level
of
details
like
a
port
number
yeah,
or
it
should
be
like
the
concern
of
the
cluster
operators,
only
for
them
to
provision?
You
know
specific
listeners
of
listeners
for
specific
ports
and
then
share
that
information
with
the
application
developers.
A
Yeah
yeah,
that's
a
good
question.
I
we
we
have.
We
have
run
into
weird
edges
around
our
personas,
like
like
you're,
alluding
to
here.
It's
it's
hard
to
to
build
a
system
that
fits
everyone's
boundaries
perfectly,
but
you're
right
in
in
an
ideal
world.
You
have
those
those
really
strong
boundaries
and
your
your
gateway
happens.
A
G
H
Okay,
yeah.
That
would
definitely
be
helpful
right
like
so
you
guys
both
brought
up
that
there
are
other
ways
to
match.
Right.
Protocol
is
assumed
in
or
implied
in
certain
route
types
and
then
host
name.
Kid
can
match
directly
from
the
routes
right
because
they
they
have
a
set
of
their
own
host
names.
H
That's
the
other
little
pause
that
I
have
and
I
don't
have
a
great
alternative.
So
I'm
just
kind
of
bringing
things
up-
and
I
don't
have
a
use
case
outside
of
just
discussing
this,
but
then
yeah
this
there's
this
our
orthogonal
matching
of
section
name
and
then
port
name
and
then
spread
across
the
api
space.
H
There
is
hostname
and
then
implied
matching
with
protocol,
and
I
think
it's
I
think
it
like
bears
more
reflection
on
like
what
kind
of
system
the
users
or
or
what
kind
of
workflows
the
users
are
going
to
have
and
how
are
they
going
to
kind
of
reason
about
the
api?
So
I'm
glad
you're
bringing
up
the
discussion,
and
I'm
just
discussing-
I,
like
I
said,
I'm
still
trying
to
work
around
a
good
input
to
the
gap.
But
since
you
brought
it
up,
yeah.
B
To
kind
of
run
with
matthews,
I
think
matthew's
point
a
little
bit
so
the
context
here
is,
you
know
someone's
using
a
parent
ref
to
a
mesh
crd.
Well,
I
mean
a
mesh
can
have
arbitrary
fields
that
aren't
in
gateway
which
you
might
want
to
match.
So
maybe
you
have
multi
mesh
right,
so
you
have
like
six
different
meshes
or
meshes
have
particular
properties,
maybe
in
the
context
of
mesh
it
makes
sense
to
say
hey.
A
Yeah
you're
right
you're
right
and
it
does
depend
on
on
how
you
structure
that
parent
resource
you're
you're
entirely
right.
So
I
it's
going
to
it's
going
to
be
implementation,
specific
I
I
would
think,
but
the
there's
a
in
in
my
mind,
there's
a
difference.
You
know
if
you're,
you
know
your
your
example
is
a
good
one
of
I
I
have
two
different
meshes.
One
is
production,
one's
non-prod,
whatever
right
that
could
again,
depending
on
implementation,
be
represented
as
different
instances
of
a
mesh.
A
You
know
like
this
is
a
mesh
resource
that
represents
my
prod
mesh,
and
this
is
a
mesh
resource
that
represents
my
non-prod
or
dev,
whatever
mesh
and
and
that
works
that
that's
entirely
possible.
So
that's
a
parent
ref,
that
is,
you,
know,
referencing
a
different
resource
entirely.
A
Another
way
to
take
that
is
I'm
going
to
have
one
resource
that
includes
two
nested
items.
One
is
a
it's
not
a
listener,
but
it's
basically
a
parallel
concept
for
mesh.
I
haven't
seen
a
resource
like
this,
but
you
can
imagine
that
there's
a
mesh
and
within
that
definition
of
a
mesh
you
have
here's
my
prod
section
and
here's.
My
non-prod
section-
and
so
you
can
imagine
okay,
you
could
use
section
name
to
reference
that
those
both
of
those
seem
like
a
reasonable
approach
here.
A
What
but,
but
the
the
key
with
those
examples
is
you're
talking
about
something
that
is
relatively
finite
in
terms
of
the
the
quantity,
so
you
could
represent
it
with
additional
resources,
whereas
asking
someone
to
create
additional
resources
for
every
port.
You
know
60
value.
A
large
number
of
resources
for
each
port
may
be
a
bit
overkill
and
I
think
port
is
somewhat
unique
in
that
it
is
broadly
applicable
for
both
use
cases
like
it.
A
It's
clearly
something
that
is
desired
for
at
least
some
mesh
implementations,
but
I
think
it's
also
clearly
understood
and
has
some
valid
use
cases
for
gateway,
where
the
other
examples-
probably
don't,
so
that
that's
my
take
on
it.
But
I
don't
interested
in
other
discussion
here
too.
A
And
I
do
know
I
should
we
should
move
on
soon,
so
I
don't
want
to
keep
on
dragging
this
out,
but
this
has
been
awesome.
Conversation
thank
you
to
everyone.
Who's
contributed
to
it
I'll,
try
and
summarize
some
of
the
comments
here
in
one
broader
comment,
but
certainly
this
is
pr966.
A
If
you
have
comments
or
thoughts,
please
add
them
on
the
pr
as
well.
That'd
be
great
to
get
some
discussion
going
on
there
as
well
great
all
right.
Well,
thanks
everyone,
the
next
one
shane,
I
think,
you're
still
on
the
call.
This
one
is
l4
traffic
matching,
which
also
has
a
few
outstanding
conversation
items
here,
shane.
What
what
questions
do
you
think
need
to
be
answered
at
this
point?
I
know
there's
a
couple
outstanding
conversations
at
least.
J
Yeah,
it
ended
up.
It
was
an
implementation
for
the
gap,
but
I
think
we
ended
up
having
a
lot
of
comments
about
just
basically
say
basically
extending
the
original
get
pr
discussion.
So
things
are
changing
a
lot.
There's
a
couple
that
I
just
need
to
go
back
over.
I
just
need
to
catch
back
up
on
this
week
and
I
think
there
are
some
like
you
pinged
someone
and
they
haven't
chimed
in
yet
kind
of
just
waiting
on
consensus
for
a
couple
of
them
so
I'll
make
sure.
A
Okay,
that
yeah
no
thank
thank
you
for
driving
this.
I
know
this
turned
into
a
a
bit
of
a
large
discussion
here.
I
think
one
of
the
things
I
remember
is
being
better
now
than
beta
right.
Yes,
I
agreed
one
of
the
things
I
I
remember
as
being
kind
of
a
a
key
point.
Here
is
around
the
address
types
and
specifically
how
we
represent
them.
So
one
of
the
key
parts
of
this
pr
right
now
is
it
splits
out
address
type
into
two
types.
A
I
I
forget
the
specifics,
but
one
is
for
use
and
gateway,
and
one
is
for
use
in
l4
routes.
Essentially,
I
forget
what
you
just
called
and
the
reason
yeah
yeah.
J
A
J
No,
it's
just
split
because
the
we
didn't
want
host
name
in
the
yeah,
l4
validation.
A
Yeah-
and
so
I
I
guess
this
all
comes
back
to-
which
is
the
least
bad
way
to
do
this,
so
we
in
our
in
our
type
definitions,
but
what
we're
doing
right
now
is
we
have
this
awfully
fun
idea
of
you
know
putting
our
enums
on
the
tight
definitions
themselves,
and
so
that
means,
if
you
have
a
variation
in
the
values
allowed,
you
need
a
new
type
definition
instead
of
you
know
putting
your
enum
where
it's
used,
so
the
alternative
would
be
to
take
this
and
pull
it
up
to
where
it's
actually
used
in
the
gateway
and
on
the
route
and
say
on
the
gateway.
A
J
And
I
also,
I
also
did
try
the
inverse,
so
the
inverse
is,
instead
of
the
original
address
type
being
used,
basically
by
the
new
type
and
then
getting
hostname.
I
did
the
reverse,
where
the
new
one
becomes,
the
base
type
and
then
gateway
tries
to
just
add
the
hostname,
but
that
ends
up
in
some
weird
validation
generation.
G
Can
we
scroll
down
to
the
thread
that
I
think
james
started?
I
think
he
had
a
good
point
about.
I'm
not
sure
if
that
thread
was
going
in
the
right
direction,
yeah
this
one
where
we
should
write
matching,
I'm
speaking
for
james
here,
a
little
bit
so
james,
please
correct
me,
but
I
think
we
should
be
sort
of
matching
the
structure
of
the
route
you
know
similar
to
http
route,
rather
than
like
that's
a
simpler
api
where
we
have
homogeneous
routes
rather
than
you
know,
every
route
having
a
spec.
That
is
wildly
different.
B
Yeah
I
I
shane
a
bit
of
an
apology
on
this
one
because
I
clearly
didn't.
I
think
I
didn't
actually
review
the
original
gap
and
that's
something
that
it
would
have
been
better
to
raise
in.
J
Out,
I
think
I
get
where
you're
coming
from
like
kind
of
flattening
things
out,
but
I
think
that
where
we
left
off
in
that
conversation
was
at
least
in
the
original
gap,
we
had
talked
about
just
having
like
address
match
and
then
in
this
suggestion
it's
kind
of
splitting
out.
What
would
what
was
eventually.
J
Let
me
rephrase
myself
address
match
had
this
concept
of,
maybe
eventually
that
could
include
sitters,
and
this
kind
of
goes
a
different
way
and
says
that,
like
matching
on
network,
be
a
separate
thing
which
I'm
not
opposed
to
at
all.
It's
just
it's
kind
of
just
an
unresolved
threat
at
this
point
that
I
need
to
get
back
to.
B
Yeah,
I
think
the
idea
here
was
is
just
to
mirror
the
pattern
that
we've
established
in
http
route,
where
you
have
you
have
a
list
of
matches
and
each
match
has
a
list
of
field?
Has
some
number
of
fields
which
can
which
can
be
matched
against
so
source
address?
Is
one
field
destination
address?
Is
another
field
you
could
quite
easily.
Imagine
where
I
did
the
network
address
as
something
that
matches
against
cider,
and
then
you
can
put
all
the
you
put
all
those
matches
in
your
traffic
match.
B
Maybe
you
can
call
it
traffic
match
struct
or
address
match,
and
then
you
combine
them
with
an
or
at
the
top
level
in
your
in
your
slice,
which
is
what
http
rail
does.
G
J
Well,
the
center
part
was
already
kind
of
mentioned
as
a
we're
not
doing
this
for
this
gap,
so
that
is
kind
of
meant
to
be
for
later.
Anyway.
The
part
that
I
might
be
a
little
confused
on
is
you
asked
for
a
list
of
these
kind
of
topical
matching
structures
that
is
implemented.
I
immediately
saw
the
value
of
that
and
put
that
in,
but
are
we
still
trying
to
get
more
underneath
that,
because
the
or
was
that
list
right-
and
we
have
that
now.
B
Yeah
yeah,
so
if
you
have
the
or
at
the
and
so
I'm
just
scrolling
around
in
yeah
in
the
udp
route,
say
say
looking
in
tcp
route
rule
we
have
matches,
which
is
a
slice
of
address
route
matches,
so
the
address
route.
That
would
what
I
think
we
should
do
is
the
matches
would
be
a
slice
of
address
route
match
and
that
slice
gives
you
the
awesome
addicts,
which
means
any
one
of
these
matches
is
acceptable
and
then
in
address
route
match.
B
A
B
A
Think
what
might
make
sense
if
we're,
if
we're
talking
about
fundamental
changes
like
that,
maybe
we
should
take
a
step
back
and
try
to
modify
the
gap
first
and
then,
once
we
have
consensus
on
the
gap.
Come
back
here
because,
like
you
said,
there's
a
million
comments
and
it's
hard
to
follow
what
we're
suggesting
here.
A
I
I
see
I
see
the
merit
of
trying
to
match
more
closely
http
route
and
the
matching
semantics
there.
I
am
concerned
again
it's
it's
hard
to
predict
what
users
are
going
to
want,
but,
for
example,
they
may
want
to
have
us.
You
know
be
able
to
configure
a
situation
where
I
want
to
match
any
one
of
these
addresses
requests
from
any
one
of
these
addresses
to
any
one
of
those
addresses
which
I
don't
think
is
possible.
With
the
structure
you've
proposed
james,
like
the
the
single
address
to
single
address
kind
of
relationship.
A
E
B
A
I
think
it's
more
than
that,
if
you
pair
source
and
destination
together
as
a
one-to-one
match
that
that's
my
concern,
but
this
is
this-
is
going
down
into
more
detail
than
we
need
to
discuss
here.
I
think
it's
very
worth
that
you
know
following
up
with
the
get
pr
just
so
because
I
may
be
misunderstanding.
I
probably
am
misunderstanding:
what
you're
proposing
so
maybe
just
taking
a
step
back
and
make
making
some
proposed
suggestions
to
the
gap,
be
the
best
next
step.
I
don't
know.
A
G
A
Yeah
yeah,
okay,
hopefully
yeah.
Well,
I
I
wanna.
I
wanna,
actually
see
this
written
out
and
hopefully
it'll
make
more
sense
to
me.
Then
yeah,
okay,
so
the
last
one
is
conformance
test.
I
appreciate
all
the
feedback
we've
gotten
on
this
one.
This
is
a
huge
pr,
and
this
is
the
like.
I
think,
v3
of
this
pr.
Like
there's
there's
some
code-
that's
been
recycled
from
earlier
versions
of
this
pr.
A
I
I
really
do
think
this
is
close
to,
if
not
ready.
I
would
appreciate
some
additional
rounds
of
review
on
it.
Some
of
the
things
that
have
changed
more
recently,
I've
I've
added
a
new
flag
that
basically
allows
you
to
run
tests
without
cleaning
up
the
base
resources.
A
But
I
think
this
is
a
close
to
good
starting
point,
and
I
I'm
at
I'm
at
a
point
where
I've
seen
you
know.
Conformance
test
pr
stagnate
and
I
I
would
really
love
to
just
get
this
one
across
the
finish
line
whatever
that
takes
just
so,
we
can
have
some
baseline
for
conformance
tests
and
then
iterate
from
there.
G
I've
been
running
a
little
behind
on
reviews,
but
I'll
take
a
look.
It
seemed
like
the
I
think
at
this
point.
We
should
get
something
in
and,
like
you
know,
just
go
and
iterate
and
you
know
collect
feedback
like
we
have,
like
you
have
said
before.
Right
like
they
have
been
in
they've
gotten
stale
a
lot
of
times,
and
I
think
it's
a
lot
of
effort
to
create
even
like
one
version
so.
A
A
A
A
Cool
all
right,
well
welcome
back
happy
new
year,
everyone
and
we'll
see
you
online
and
hopefully
next
week
as
well,
have
a
great
one
thanks.
Everyone.