►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20220214
Description
SIG Network Gateway API Bi-Weekly Meeting for 20220214
A
All
right,
it
is
february
14.,
happy
valentine's.
Everyone.
We've
got
a
few
things
to
get
through
today.
First
up
it
looks
like
we've
got
shane
on
the
list.
I
guess
I'll
hand
it
off
to
you.
Shane.
B
This
was
kind
of
just
like
a
question
that
I
wanted
to
put
down.
So
if
we
have
more
agenda
to
go
through,
I
can
wait
till
the
end,
but
otherwise.
A
B
Kind
of
why
I
was
thinking
it,
but
all
right-
it's
probably
pretty
quick
anyway,
so
we've
talked
recently
about
policy
and
how
policy
should
work
ultimately
to
like
deal
with
things
that
are
a
little
bit
implementation
specific.
The
most
recent
example
in
this
thing
was:
we
talked
about
use
a
policy
to
define
the
load,
balancing
behavior
of
back
end
refs
for
hcp
route
right.
B
How
far
do
we
for
have?
We
talked
about
like
using
policy
for
implementation,
specific
I'll,
say
general
configurations
for
gateways
like
are
we
have
other
people
been
or
it
was
it
intended
for
policy
to
be
something
where,
like
okay,
I
deploy
a
gateway
and
here's
my
policy
for
how
that
gateway
will
do
its
logs.
C
That
feels
like
a
pretty
good
use
case
for
me,
like
we're,
probably
not
going
to
want
to
put
it
feels
so,
for
me,
I've
always
considered
pro
policy
to
be
a
way.
To
put
you,
I
mean
we
spent
a
lot
of
time
on
the
sort
of
the
override
and
default
behavior,
and
it's
a
way
to
put
settings
that
you
can
override
or
default
that
you
want.
C
I
don't
think
it's
that
useful
to
have
like
a
standard
logging
stance
up,
but
you're,
making
a
you're
making
a
having
a
way
to
sort
of
say
it
feels
like
it
could
be
seems
like
it
might
be
useful
in
my
book
as
well
to
be
able
to
put
that
at
the
gateway
class
level.
Even
to
say,
any
gateways
under
this
gateway
class
should
log
to
this
log,
sync
or
whatever.
B
B
Ton
of
configuration
options,
theoretically
that
in
like
traditional
deployments
of
our
gateway,
it's
just
a
myriad
options
and
I'm
just
kind
of
I'm
wrestling
with
wanting
to
make
sure
I
make
good
choices
for
how
we
would
say:
okay,
post
a
gateway,
you
want
that
gateway
to
be
provisioned
by
the
controller.
Here's
all
the
different
configuration
options
you
want
for
it
and
right
now,
policy
looks
like
it.
A
A
You
can
look
up
the
docs
for
it,
but
we're
basically
recreating
the
the
configuration
that
was
available
there
in
policy
resources,
for
example,
we'll
have
a
lb
policy
as
a
generic
catch-all
for
a
variety
of
policy
and
then
some
other
more
targeted
ones.
So
you
know,
I
don't
think
we
have
one
specific
to
logging
yet,
but
they,
the
vlogging.
A
Yeah,
no,
I
mean
that's
a
great
example,
but
that
kind
of
thing
is
definitely
where
we've
taken
it.
D
One
one
other
way
I
think
policies
can
be
used
is
or
chunks
of
configuration
that
you
want
to
reference
repeatedly.
You
know,
so
you
can
change
it
one
place
and
have
it
affect
many
other
places
you
know
you
might
want
to
do.
D
No
login
is
an
example,
but
maybe
you
want
to
do
something
like
you
might
want
to
create
policies
for,
like
your
tlf
settings,
maybe
supported,
ciphers
and
and
minimum
version
you
don't
want
to
go
through
and
change
change,
every
westerner,
every
gateway
where,
when
you
need
to
make
like
a
corporate
change
for
again
a
common
one,
I've
run
into
is
ciphers.
Where
suddenly,
we've
found
a
weakness
in
a
specific
cypress
suite.
So
you
need
to
eliminate
that.
C
Yeah,
I
literally
have
an
item
on
my
on
my
post-it
note
thing
that
I,
where
I
keep
my
things,
that
I
need
to
remind
myself
about
to
write
an
example:
api
for
doing
tls,
minimum
version
using
policy,
which
I
think
would
be
you
know
we
could
even
have
the
that
would
be
one
that
I
was
kind
of
thinking
that
we
would
have
that
as
like
an
example
of
how
a
worked
example
of
this
is
how
you
would
write
a
policy.
B
B
C
A
I
I
just
want
to
say
thank
you
for
bringing
this
up
and
I
think
it's
worth
maybe
maybe
this
is
a
good
use
of
discussions
on
github,
but
I
am
very
curious
what
others
are
doing
or
planning
on
doing
for
policy.
I
agree
that
it
would
be
great
if
we
were
all
planning
on
doing
something
resembling
the
same
thing
following
the
same
patterns
and
you're
right
that
is
kind
of
vague
and
and
wide
open
right
now,
so
making
sure
that
we're
all
interpreting
things
the
same
way
would
be
great.
F
Yeah
concur
because
this
is
this
is
making
me
think
of
a
couple
things,
so
we
have
been
thinking
about
policy
very
similarly,
shane
is
that
it's
a
way
to
add
a
lot
of
implementation,
details
around
traffic
and
how
to
shape
traffic
or
how
to
shape
the
you
know
the
data
plane
so
to
speak,
but,
oh
sorry,
but
also
I'm
thinking
about
logging.
This
example,
you
know
so,
like
maybe
logging,
content
or
encodings
or
things
of
that
nature.
I've
been
thinking
belong
in
parameters.
Ref.
F
C
I
think
that's
a
really
good
question
that
we
don't
have
a
good
answer,
for,
like
the
I
mean
we
put
the
we
put
the
spots
in
there
for
us
to
use,
and
but
I
don't
think
we've
ever
had
this
just
this
literal
discussion
before
I
think
it
off
the
top
of
my
head.
It
feels
to
me
like
what
you
said
resonated
with
what
I
kind
of
expected
the
gateway
class
parameter
ref
to
be
that
feels
like
it's.
C
In
my
mind,
a
gateway
class
is
like
close
to
one
to
one,
not
always,
but
you
there's
you
a
gateway
class
and
a
controller
are
pretty
this
a
reasonably
close
binding
between
a
gateway
class
and
a
controller,
and
so
the
the
gateway
class
parameter.
Ref,
in
my
mind,
is
for
all
for
something
where
you
say:
everything
that
every
gateway
that
fits
into
this
bucket
is
going
to
have
these
overarching
settings
set.
C
Is
the
parameters
ref
like
all
the
control,
it's
configures,
the
controller
that
then
manages
the
gateways
for
you,
whereas
the
policy
is
about
configuring,
the
configuring
bits
on
the
gateways
or
the
routes
or
or
something
like
that.
That
feels
to
me
to
be
roughly
that's
pretty
poorly
explained.
I
think
that
feels
to
me
my
rough
idea
does
that
make
sense.
F
Yes,
yeah,
yes,
okay,
so
that
reflects
okay.
We
are
being
a
little
bit
squishy
here,
but
I
think
there's
room
for
being
squishy,
but
yeah
that's
reflects
that
of
how
I'm
thinking
about
it.
Okay,
yeah
this!
This
is
helpful.
Thank.
A
You
yeah,
and
I
I'd
add
that
for
gk
we
have
a
fairly
straightforward
mapping
here
you
know
for
for
us,
we
can
look
at
it
and
say
this
is
a
class
of
load
balancer,
essentially
because
we're
translating
these
gateways
to
load
balancers,
so
you
might
have
regional,
xlb
l7
whatever
right
that
that
is
a
well-known
class
of
load
balance.
In
our
case,
it
I
think
kind
of
what
nick
was
referring
to
also
makes
a
lot
of
sense
too.
A
A
I
think
these
are
the
kinds
of
things
that
you
set
once
and
forget:
they're
they're,
not
things
that
change
frequently,
so
you
know
for
for
again
our
our
implementation
of
gateway
class,
we're
looking
at
these
as
basically
templatized
concepts
that
apply
only
at
create.
So
this
is
what
it
meant
for
to
be
a
regional,
l7
xlb.
A
When
we
created
this
gateway,
we
don't
expect
them
to
change
very
much,
but
if
some
variation
did
change
that
would
be
in
the
next
gateway
created
with
that
class,
whereas
policy,
I
think
is,
is
very
much
going
to
be
more
broadly
used
and
something
that
you
would
expect
when
a
policy
changes.
It
affects
the
things
that
it's
referring
to
immediately.
A
F
Yeah,
so
maybe
a
note
there
because,
like
I
now
see,
I
now
see
like
an
intersecting
set
right
so
to
speak
in
like
nginx
parliaments
right.
I
I
see
parameters,
ref,
govern
your
worker
processes
and
then
I
see
policy
governing
whatever
is
in
your
stream
or
http
block
or
your
locations
regex's
and
matches
like
that.
But
then
logging
is
such
a
great
example,
because
I
see
that's
where
the
intersection
is
I
might
want.
F
I
might
want
my
access
logs
configured
parameter
ref,
because
that's
the
persona
who's
touching
access
logs,
but
then
there's
other
logging
formats
or
other
logs
or
trace
logs
that
I
might
want
to
apply
to
particular
routes
of
traffic
independently.
Okay,
I
think
there's
some
nuance
here,
but
this
is
this
is
helpful.
Thank
you.
C
Us
to
think
about
how
this
would
work,
for
I
mean
non-layer,
7
controllers
and,
like
I
mean
I
think,
rob
obviously
gke
load
balancer
is
a
good
example
of
a
non-last,
not
only
a
layer,
seven
controller,
but
yeah
I
mean
I
mainly
ride
a
l7
controller.
So
it's
easy
to
forget,
but
it
is
important
for
us
to
remember
this.
Api
is
about
left
four
as
well,
so
we've
got
to
think
about
those
sort
of
things
I
mean.
C
I
in
terms
of,
I
think
that
the
canonical
example
for
for
policy
is
still
timeouts
and
the
reason
that
that
is
the
canonical
example
is
everybody
has
timeouts.
C
Nobody
does
in
the
same
way
and
exactly
what
timeouts
you
have
and
all
that
sort
of
stuff
is
so
implementation
dependent
that
we
can't
build
a
generic
thing,
but
it's
really
common
that
you
would
want
to
have
you
you'd
want
to
be
able
to
say
the
default
client
timeout
for
whatever
value
of
client
timeout.
You
actually
mean
you
know
the
default
client
timeout
for
everything
under
this
gateway.
C
Is
you
know
five
seconds
or
something
like
that,
and
then
you
the
reason
and
then
we
have
this
mechanism
of
defaults
and
overrides
where
you
know,
if
you
put
a
default
at
the
gateway
level,
then
http
routes
can
override
it.
You
with
some
other
mechanism,
or
you
can
attach
another
policy
to
the
http
route
that
override
that.
So
I'm
using
the
words
wrong
it
can
the
def
can
they
can
specify
a
different
default
that
will
take
precedence
over
the
high
layer
default
because
defaults
operate
in
a
more
specific
beats.
C
The
timeout
setting
for
all
http
routes,
so
an
example
of
doing
that
would
be.
I
don't
want
people
to
be
able
to
set
an
infinite
client
timeout,
because
I
am
running
a
shared
layer,
7
proxy
and
having
infinite
client
timeouts
means
that
you
lick
resources,
and
so
you
don't
want
people
to
be
able
to
change
that,
and
so
that's
that's
what
the
default
on
override
is
for
is
that
sort
of
cascading,
but
is
it
controls
the
cascading
behavior
of
the
policy?
And
I
think
that's
the
other.
C
That's
the
other
thing.
That's
really
important
to
remember
about
policy
is
that
it
does
cascade.
D
D
So
that
you
know
people
that
want
certain
functionality
again,
I
think
you
know
we're
using
like
load
balancing
as
an
example.
You
know
we
have
a
standardized
policy
for
load
balancing,
you
know.
So
this
is
a
load
balancing
type
of
policy
and-
and
you
know,
standardized
parameters
similar
to
like
what
nick
you
mentioned
with
the
with
the
tls.
C
Yeah,
so
I
guess
the
other
thing
that
I'm
hoping
for
with
the
policy
mechanisms
is
that
over
time
we
may
find
we
should
be
able
to
drive
a
set
of
policy
objects
towards
some
sort
of
consensus
for
products
that
you
know
for
implementations
that
have
similar
behaviors.
C
So
I
would
kind
of
anticipate
that
say
time
out
to
use
timeouts
again
that
all
of
the
envoy,
based
all
of
the
things
that
use
envoy
as
their
data
plane,
should
probably
end
up
with
like
an
envoy,
timeout
policy,
or
something
like
that
that,
because,
because
the
the
data
plane
is,
one
is
the
thing
that
sets
the
time
like
how
the
timeouts
work
and
so
like.
In
my
mind,
this
is
a
great
example
of
how
we
could
we
all
do
our
own
thing,
but
we
try.
C
But
we
come
to
this
forum
and
we
try
and
we
sort
of
try
to
say
hey
how
about.
We
all
try
to
do
something
a
bit
similar,
so
that
so
that
you
so
that
we
can
get
back
to
what
I
feel
is
the
core
deliverable
of
this
project
and
that's
interoperability
and
ease
of
migration.
But
like
we
all
want
people
to
be
able
to
move
their
config
as
seamlessly
as
possible
as
far
as
possible
between
different
implementations.
F
Yeah,
I
think
there
might
be
room
for,
like
you
know,
bifurcation,
so
to
speak
of
of
policies
too
right.
Like
so
you're
saying
you
know,
let's
be
cognizant
of
l4
and
l7.
I
can
see
a
whole
set
of
a
slew
of
l4,
like
tcp
window
timeout
policies
for
for
the
l4
piece,
or
do
you
want
ip
tables
or
bpf
sort
of
work
at
the
l4
layer
versus
whatever
we're
going
to
do
at
l7?
A
This
is
a
yeah.
This
is
a
really
good
discussion.
Thank
you
again,
shane
for
bringing
this
up.
I
want
to
ask
for
a
volunteer
here.
Could
anyone
capture
this
in
an
issue?
To
I
mean,
I
think
the
end
goal
here
is
to
write
docs,
but
before
we
get
to
that
point,
can
we
capture
an
issue
of
just
what
we
discussed
here
and
what
our
docs
are
currently
missing
or
need
to
discuss.
C
Thanks
again,
shane
that's
good
question
man.
Yeah
you've
been.
C
A
Completely
agree
on
that:
okay,
so
next
week
I'm
gonna
be
off
it's
president's
day
in
the
u.s.
I
am
open
if
anyone
want
is
going
to
be
around
to
obviously
feel
free
to
have
a
meeting,
but
I
won't
be
here.
So
is
anyone
else
going
to
be
here
next
week
and
interested
in
meeting.
C
C
That's
what
I
I
was
about
to
say.
So
what
I'm
going
to
suggest
is
that
we
do
a
lazy
consensus.
Thing
of
you
know
speak
now.
If
you
don't
want
the
meeting
to
be
cancelled
and
if,
if
otherwise
then
I'll
take
one
hour
back
in
my
day,.
A
I
will
unless,
unless
we
hear
any
anything
else,
let's
plan
on
canceling
definitely
ping
in
slack
or
elsewhere,
if
you're
interested
in
meeting,
but
otherwise,
like
you,
said,
lazy
consensus,
we
can
all
have
an
hour
back
cool
all
right.
So
on
that
note,
I've
just
kind
of
by
default
been
leading
meetings
for
a
while.
A
I
don't
I'm
not
tied
to
that
by
any
stretch
of
the
imagination,
and
I
realized
that
I've
nev
it's
been
a
while,
since
I've
mentioned
hey,
anyone
else
can
lead
if
they
want
to
so
I'll,
throw
that
out
there
again.
If
anyone
is
interested
in
leading
meetings
and
sharing
the
load
whatever
just
leaving
one
every
now
and
then
I
would
love
some
diversity,
some
different
different
people,
leaving
so
by
all
means
volunteer
ping
me
or
on
slack
or
wherever.
C
Said
I
would
and
then
got
cold
feet
last
week.
I
C
Yeah,
I
I
definitely
am
interested
in
helping
as
well,
but
I
should
say
that
basically,
all
of
the
really
the
only
things
that
required
are
that
hey
you
get
you
end
up
with
the
hosting
key,
so
that
you
can
share
your
screen
and
then
b
be
the
one
who
runs
through
the
agenda.
That's
it
so
yeah!
It's
not
that
bad!
C
D
A
All
right,
well,
hey
awesome,
I'll
I'll
reach
out
to
you
after
to
to
figure
out
a
schedule
where
we
can
get
some
more
people
leading
here.
But
thanks
thanks
for
volunteering
and
if
you
haven't
but
you're
interested
just
ping
me
or
any
any
maintainer
and
we'll
we'll
get
you
on
the
schedule.
A
Cool
all
right,
so
there's
actually
a
bunch
of
pr
triage.
I
don't.
I
haven't
been
paying
as
much
attention
to
issues.
So
if
someone
is
aware
of
issues
that
we
should
discuss,
let's
do
that,
but
I
know
there's
some
big
pr's
that
are
just
sitting
right
now
and
I
want
to
make
sure
we
have
time
for
them.
I
I'm
not
even
going
to
cover
this
pr
because
I've
looked
at
it
and
I
just
ran
out
of
time
to
test
it
locally
before
I
merged
it,
but
it
seems
very
straightforward.
A
C
Yeah,
congratulations!
Yeah!
I'm
like
how
do
I
even
test
if
prayer,
I
was
gonna,
build
images
I'm
like
well,
I
don't
know
I'm
pretty
confident
that
I've
got
it
mostly
right.
It's
not
that
big,
a
change
to
what
we
do
already,
but
I
mean
the.
A
Yeah
I
yeah,
I
don't
know
what
sig
can
help
us.
Maybe
it's
test
infra,
I
don't
know,
but
whoever
can
help
us
with
this
yeah
I
mean
it.
This
looks
largely
reasonable
to
me.
I
had
a
few
little
knits
comments,
questions
whatever,
but
I
mean
without
really
knowing
how
we
can
test
this.
This
seems
like
a
reasonable
first
direction.
C
I
think
the
hardest
thing
the
hardest
thing
was
kind
of
figuring
out.
You
know
this
part,
that's
in
that
that
little
bulleted
list
there,
so
all
images
will
be
labeled
with
like
a
the
pro
version
string.
Images
built
for
like
a
branch,
assembly,
branch
or
tag
are
labeled
with
the
branch
tag
name.
So
when
we
do
a
release,
you
can
use
v041
as
your
admission
controller
tag,
label,
image,
container
image
label
and
then
images
built
with
a
rc
with
a
pre-release
marker.
C
They
are
not
labeled
yeah
so
and
then
the
the
one
that
does
any
symbol,
tags
that
don't
have
the
pre-release
marker
will
be.
It
will
be.
Pushed
to
later
latest
will
be
set
to
that
for
the
people
who
like
to
live
on
the
bleeding
edge
and
put
latest
in
their
manifests,
like
you
know,
and
fly
by
the
seat
of
their
pants.
C
A
Cool
yeah,
I
know
thank
you
for
taking
this
on.
I
know
this
is
something
that
we
will
all
I
mean
it's
really
a
beta.
You
know
something
that
we
require
for
beta.
So
I'm
glad
to
see
this
getting
some
traction
yeah
thanks.
C
There's
a
few
other
related
things
that
I
haven't
got
to
yet
I
wanted
to
do
this
one
first,
but
then
there's
like
updates
so
that
we
do
build
x
and
build
for
arm
and
stuff
like
that
as
well,
and
then
figure
out
how
we
push
to
pride
and
a
bunch
of
other
stuff
when
we're.
A
Awesome
all
right
so
next
I
see
richard
you're
on
this
call
and
I
noticed
you
had
pushed
an
update
or
set
of
updates
to
the
pr
any
any
high
level
summary
of.
What's.
J
Changed
sure,
so
one
big
semantic
change
is,
I
actually
defined
a
different
merge
semantic
for
when
an
http
route
and
a
grpc
route
have
the
same
hostname
where
they
share
a
hostname
space,
and
that
was
driven
by
bouncing
the
original
idea
off
of
some
more
people,
and
they
pointed
out
that
there
are
some
use
cases
where
you
may
want
http
route
to
win
out
or
you
may
want
grpc
route
to
win
out.
J
So
it
gets
a
little
bit
complicated
because
of
the
way
that
services
and
methods
are
mapped
down
to
http
2
uris.
But
I
think
you
can
read
through
there
and
it
makes
it
mostly
makes
sense.
It
does
end
up
using
regexes
in
some
places,
but
only
in
places,
mostly
in
places
where
you're
using
regular
expressions
in
the
grpc
route
api
other
than
that.
It's
mostly
just
filling
out
dock
strings.
Pretty
boilerplatey
expected
stuff.
J
I
know
it's
a
big
pr,
so
I
imagine
people
want
to
like
read
through
it
in
detail
before
commenting
on
it.
So
I'm
fine.
If
there
are
no
comments
today,.
A
Yeah
this
is
thank
you.
Thank
you
for
leading
this
and
for
getting
this
update
in.
I
had
not
really
thought
about
how
you
know:
http
route
merging
is
complicated
enough
and
layering
on
more
merging.
On
top
of
that
is
fun.
I
I
need
to
thank
you
for
laying
it
out
this
way.
I
mean
it
looks
logical,
but
I
need
to
spend
some
time
thinking
about
it.
A
bit.
J
More
so
there
is
one
detail
here
that
is
a
little
bit
rough
from
my
perspective,
which
is
like
so
looking
at
this
bulleted
list
here.
The
first
three,
I
think,
makes
sense,
but
there's
a
fourth
one.
That's
missing
before
the
catch-all
case,
which
is
what,
if
you
want
to
match
a
method
but
like
a
specific
method,
but
you
want
to
match
all
services.
So
the
encoding
in
grpc
is
slash
service,
slash
method.
Now
you
need
a
suffix
matcher
and
there's
no
suffix
matcher
with
an
http
route.
So
you
can't
translate
it
down.
J
The
only
way
you
can
do
it
is
with
regex's,
so
that
case
actually
falls
into
the
last
one.
The
problem
is
that
you
want
that's
an
exact
match
from
the
perspective
of
grpc
that
can
only
be
expressed
in
terms
of
a
regex
match
from
http
route
and
regex
match
is
what
is
it?
Custom
support
something
like
that
with
an
http.
J
So
it's
it's
difficult
right,
like
maybe
the
solution
there
is
to
introduce
a
suffix,
matcher
or
something,
but
that
might
have
a
bunch
of
other
unintended
consequences.
So
another
option
I've
thought
about
is
like.
Well,
maybe
you
say
specifying
a
method,
but
not
a
service
in
grpc
is
considered
like
custom
support,
or
something
like
that,
because
it
has
this
dependency
on
regex's.
A
Yeah,
I
thank
you.
Thank
you
for
calling
that
out.
I
don't
have
a
good
answer
or
thought
to
this
one.
Yet
one
thing:
while
we're
discussing
this
gap,
do
you
have
an
idea
of
approximate
timeline
or
you
know
is?
Is
there
a
goal
you
had
for
getting
this
in
and
implemented?
You
know
we're
we're
nearing
a
v1
beta
1
release.
Is
it
fine
if
this
were
to
slip
and
be
the
second
release?
It's
still
v1
beta
1,
but
you
know
later
on
in
the
process,
or
is
this
something
you
really
want
to
get
in?
J
Mean
I'd
like
to
get
it
in
as
soon
as
possible,
right
like
if
you
can
tell
me
how
unreasonable
each
of
these
milestones
it
would
be
to
get
it
into.
That
would
be
helpful.
A
Yeah
that
that's
a
good
question,
I
think
we'll
just
depend
on
review
bandwidth
here,
because
I
think
you
know
you've
definitely
spent
a
fair
amount
of
time
coming
up
with
a
reasonable
proposal.
So
we
just
need
to
spend
some
time
reviewing
it
and
I
I'm
not
sure
I'll
have
to
maybe
defer
to
others
in
the
community
as
far
as
timeline
and
what
we
think
is
reasonable
or
what
what
kind
of
capacity
we
have
here.
J
A
Weird
in
that
we,
it
will
still
be
v1
beta
1
of
the
api,
but
we'll
have
like
different
bundle
versions
that
it's
kind
of
like
if
you're
familiar
with
kubernetes
versioning,
there's
v1
beta
1
of
ingress
as
an
example,
and
then
we
make
additions
to
it
in
december
versions
of
kubernetes,
so
v1.20
added
something
to
ingress
api.
As
an
example,
I
could
be
wrong
on
the
exact
version,
but
that
that
idea,
so
I
I
think
what
is
likely
is
our
next
release
is
v0.5.0.
A
That
is
as
good,
I
guess.
As
you
know,
I
think
the
the
shortest
we've
done
in
between
releases
is
around
three
months,
and
the
longest
is
what
six
to
nine
months
somewhere
in
that
range.
C
A
C
B
C
Very
you
know
hey:
we
need
to
cut
our
list
to
get
this
thing
to
get
this
thing
in
so.
H
C
Complex
because
of
this
is
like
a
this:
is
a
upstream
api
group
cid
and
we're
the
first
ones
to
do
this,
so
we're
kind
of
figuring
as
we
go
so,
but
the
way
that
it'll
work
is
once
we
we
bring
in
the
the
so
gap
gets
approved.
C
You
know
we
bring
in
like
the
structs
that
you've,
you
know
something
like
the
structure
you've
got
in
the
gap
into
the
experimental
cid
set,
so
we
will
have
to
cut
a
release
to
do
that,
so
that
will
be
some
version
bump,
probably
o
five
o.
You
know
five
over
o
six
or
something
like
that,
but
that
you
know
so
there
will
be
a
version
bump
to
have
the
the
crd
included
in
the
cid
in
the
experimental
release
train
of
the
crds,
and
then
we
can
all.
C
And
then
that
means
that
implementers
are
free
to
pick
up
the
experimental
crds
at
that
release
and
then
the
grpc
route
cid
will
be
available
for
implementers
to
actually
try
out
and
implement.
Once
we've
had
some
people
actually
try
out
the
thing
and
like
implement
it
and
see
how
how
it
is
to
implement
for
them.
C
There
may
be
changes
that
we
would
need
to
do,
and
so
this,
the
grpc
route
resource,
will
stay
in
the
experimental
chain
until
we're
all
confident
that
the
way
we've
got
it
makes
sense
and
stuff,
and
then
once
that's
done,
it'll
move
into
the
stable
release
at
v1
beta1,
probably
because
adding
a
new
cid
is
a
backwards
like
is
a
it
doesn't
require
a
version
rev
of
the
actual
v1,
the
api
group
version.
It
does
require
a
bundle
version
and
moving
from
experimental
to
stable.
C
That's
it
okay,
so
it
sucks,
because
we've
got
three
dimensions
of
versioning.
You
know
we're
like
we're
way
out
and
we're
way
out
in
the
weeds
about
about
versioning,
so
yeah.
In
order
to
be
able
to
do
stuff,
it
just
makes
a
bunch
of
other
stuff
slightly
easier.
So
sorry,
it's
a
bit
complicated,
but
that's
that's.
J
So
my
my
side
is
just
you
know,
I
don't
want
to
rush
the
process,
but
also
I
don't
want
to
unnecessarily
doddle.
So
you
know
whatever
is
reasonable.
A
That
makes
complete
sense
thanks
for
working
with
us
and
thanks
for
keeping
this
up
to
date
and
keeping
it
moving
yeah.
Thank
you,
cool
awesome.
Let's
move
on
to
the
next
one.
Oh
did
not
mean
to
do
whoa,
that's
fun.
I
did
not
mean
to
do
that
either.
Hopefully,
everyone
can
see
my
screen
again.
A
The
the
shortcut
for
restoring
previously
closed
tab.
Apparently
pauses
screen,
sharing
anyways
lesson
learned
next
up
is
we
did
grpc
route
destination,
port
matching
chow
pushed
an
update.
Today,
I
think,
let's
see,
I
think
I
just
had
one
or
two
little
nitpicks
on
this,
but
it
looked
good
to
me,
but
there
haven't
been
as
many
people
commenting
or
reviewing
this
one.
This
is
just
this
is
an
implementation
for
an
already
approved
gap.
A
I
I
don't
think
chad
is
not
on
this
meeting
yeah.
So
the
the
thing
I
kind
of
wanted
to
call
out
just
more
broadly
is
right.
Now
we
don't
have
a
way
to
differentiate
between
stable
and
experimental
docs
yay.
So
I
suggested
just
experimental,
you
know
parentheses,
but
this
is
something
that
we
could
probably
improve.
A
So
you
know
when
I,
when
I
see
a
new
feature
like
this
one
of
the
first
things
I
look
at
is:
is
it
modifying
anything
in
the
stable
crd
because
it
shouldn't
be
and
it
is,
and
what
it's
modifying
is
it's
referring
to
you
know
in
in
this
case,
when
we
have
both
port
and
you
know,
and
section
name
specified,
what
does
it
do
and
port
is
unknown
in
this
space,
so
this
is
just
kind
of
a
machinery
thing,
a
limitation
of
our
experimental
implementation.
A
I
think
we
just,
I
think
it's
okay,
but
just
calling
it
out
if
anyone
has
a
better
idea
here
and
beyond
that,
I
guess
I'll
just
if
anyone
wants
to
wait
for
anything
else
to
get
at
it.
I
think
I
think
harry
had
a
couple
comments
I
think
they've
been
resolved,
but
if
anyone
else
has
an
opinion,
otherwise
I
think
we
can
get
this
one
in
pretty
quickly.
I
A
Thanks
that
was
destination,
port
matching.
Oh,
I
completely
missed
this.
Oh
no!
I
didn't
miss
this
one.
This
is
there's
one
legging
comment
that
I
think
the
author
missed
and
I
we
can
just
ping
them
because
I
think
I
think
they
they
already
made
one
fix,
and
then
it's
just
like
one
additional
fix
that
yeah.
A
Okay,
a
name
feel
to
it.
Okay,
before
before
I
go
down
that
rabbit
hole,
I
feel
like
we
spent
a
bit
too
much
time
on
that
one.
Let
me
at
least
get
into
a
conformance
test.
This
is
just
sitting
here
for
a
minute.
Oh,
this
is
on
me.
I
missed.
I
missed
one
bit
of
feedback.
A
If
anyone
else
has
anything,
let
me
know,
I
probably
need
to
rebase
now
it
just
kind
of
sat
for
a
minute,
but
I
would
like
to
get
this
in
we're
we're
at
the
point
where
we're
trying
to
run
these
conformance
tests
against
our
own
implementation
locally,
and
it
would
just
be
easier.
We
had
a
few
more
conformance
tests
to
run
with.
D
Yep
we're
looking
to
make
some
additional
contributions
to
the
performance
tests
too
here
in
the
next
week
or
two.
A
Yeah,
so
all
right
any
before
before
we
get
into
this
last
thing
of
named
hp
route,
are
there
other
things
we
should
be
discussing?
Are
there
issues
prs
anything
else.
A
Okay,
here
we
go
so
this
one.
We
we've
had
a
lot
of
variety
of
opinions
on
this
one,
apparently
not
cop,
not
captured
in
this
pr
itself.
D
So
rob
I
suggested
I
would
have.
Is
that
and
I
apologize
I
didn't:
have
there
once
again
didn't
get
the
route
inclusion
delegations
proposal
ready
for
today,
but
I
will
have
it
for
week
after
next,
and
I
think
we
should
just
prefer
discussion
on
this
one
to
that,
because
that's
there's
a
strong
interplay
between
them
and
I
think,
if
we
figure
out
how
we
want
to
do
route
inclusion
delegation,
that
you
know
how
we
actually
want
to
implement
it.
As
far
as
where
we
can
plug
in
a
route
inclusion.
A
C
I
guess
sorry
go
ahead,
I
guess
what
I
would.
What
I
would
say
is:
yeah
jeff.
Could
you
maybe
once
you
have
the
dock
ready
put
it
like
put
it
in
the
put
in
the
channel
and
that
way
we
can
all
like
pre-read
the
dock
and
stuff
and
become
prepared
to
the
meeting
yeah.
That's
exactly.
H
C
So
writing
a
dock,
for
it
is
really
hard
and
I'm
yeah.
I've
had
I've
had
that
sort
of
problem
too
you're
sitting
there
and
you're
like
I
know
what
you
got
to
get
this.
The
wording
needs
to
be
just
so
so
I
think
particularly
for
this
one.
The
important
part
is
that
we
have
some
options
to
discuss
rather
than
the
options
of
two
final.
D
Yeah,
that's
that's
what
one
of
the
things
I'm
going
to
do
is
I'm
going
to
show
a
couple
of
different
options
so
that
we
can
you
know,
debate
the
pros
and
cons
of
of
them
and-
and
you
know
maybe
just
we
decided-
we
want
to
go
one
direction.
Then
we
can
refine
it
from
there.
Yeah.
C
Yeah
definitely
yeah,
so
the
other
thing
that
I
just
remembered
I
needed
to
do
is
I
said
I
was
gonna
talk
to
api
machinery
about
it.
I
did
talk
to
them.
I
did
hear
I
did
hear
in
the
end,
and
so
the
answer
was
like
it
depends
on
what
your
users
want,
yeah,
and
so
I
think,
in
terms
of
I
think
that
it
it
really
does.
It
really
does
come
down
to
the
the
delegation
and
inclusion
discussion,
and
so
it's
really
good
to
sort
of,
I
think
we're
rob.
C
One
of
us
needs
to
comment
on
like
at
least
this
pr,
probably
just
to
say,
hey
we're
just
going
to
hold
off
on
this
until
we've
nailed
down
our
direction
about
the
route
inclusion
delegation
or
whatever
we're
going
to
call
it.
We
need
to
pick
a
name
as
well
and
you,
and
that
way
we
can
just
say,
okay.
C
What
what
that
does
do,
though,
is
that
puts
because,
depending
on
what
we
do
here,
I
think
it's
pretty
unlikely
at
this
point,
but
there
is
a
small
chance
that
we
might
need
to
rev
the
alpha
api
before
we
go
to
beta.
If,
if
things
turn
out
specific
ways
in
this,
so
we
this
is
a
blocker
for
for
beta
sort
it
so,
which
means
you
know.
All
of
these
things
are
blockers
for
beta
there's
plenty.
C
C
A
A
Honest
yeah,
so,
and,
and
hopefully
well
before
then,
but
yeah
with
that
said,
I
I
want
to
highlight
nick
what
you
were
saying
about
the
virgin
rep,
because
that
is
what
makes
me
nervous
about
this
discussion,
and
I
just
want
to
call
that
out
that
if
we
were
to
make
name
a
required
field,
which
is
one
of
the
options
being
discussed
here,
that
is
a
breaking
change
in
all
technicality.
It
requires
a
version
rift
if
you
want
all
three.
A
I
really
really
strongly
want
to
avoid
that,
but
we
just
I
that
that
is.
That
is
my
top
priority,
the
rest.
If,
if
we,
if
we
can
guarantee
that,
we
can
avoid
that,
then
everything
else
becomes
not
necessarily
a
blocker
for
beta.
But
if
we
think
there's
a
possibility,
that's
going
to
happen,
then
this
stays
in
the
category
of
could
block
beta.
A
A
I
think
we
may
have
reached
the
end
of
topics
then
I
can
volunteer,
like
you
mentioned
nick
one
of
us
should
I'll
volunteer
since
I'm
already
here
I'll
leave
this
tab
open
and
respond
and
just
add
a
note
for
what
we're
thinking
I
mentioned
jeff,
so
he's
looped
in
too
and
yeah.
I
think
that's
all
for
today
any
last
topics
or
give
everyone
back
15
minutes.