►
From YouTube: SIG Network Gateway API meeting for 20230213
Description
SIG Network Gateway API meeting for 20230213
A
B
C
D
Yeah
I
I
left
a
comment
at
the
bottom
here,
but
I
I'm
really
just
trying
to
figure
out
how
this
fits
into
the
broader
picture
here,
because
I
know
there's
kind
of
this
longer
term
bigger
picture
discussion
of
hey.
Could
we
have
like
a
a
Gateway
class
cluster,
IP
or
or
something
like
that?
That
was,
maybe
even
you
know,
implemented
by
data
planes
like
Coupe
proxy
in
the
future.
D
I,
don't
know
you
know
like
there's
there's
that
idea
of
Gateway
kind
of
taking
on
the
the
service,
routing
capabilities
that
currently
live
on
service,
and
then
there's
also
where
I
think
this
is
really
coming
from.
Is
the
idea
of
trying
to
map
there's
a
huge
number
of
implementations
today
that
by
default
will
take
a
Gateway
And
when
they
see
a
Gateway
they're
going
to
turn
around
and
create
a
service
type
load
balance,
usually
type
load
balancer
and
a
deployment
behind
it?
D
That
would
be
some
kind
of
Gateway
implementation,
and
this
feels
like
a
tiny
subset
of
that
right
like
it,
it
seems
like
we're
trying
to
find
a
generic
way
to
represent
I,
want
that
service
that
you're,
creating
to
be
cluster
IP
and
not
you
know
not
a
load.
Balancer
right
is,
is
that
am
I
understanding
this
correctly
before
I
go
too
much
further.
E
People
use
create
Canadian
Services,
which
kind
of
like
abstract
a
lot
of
the
underlying
details,
and
one
of
the
things
people
want
to
create
is
like
a
service
that
is
only
accessible
on
a
cluster,
so
it's
kind
of
like
a
private,
so
it's
not
by
default,
exposed
to
public
like
Ingress
and
so
that's
sort
of
the
problem.
So
the
question
is
like
hey:
how
can
you
do
this
right
now
with
giveaway
API,
but
in
a
portable
way?
I
would
say
it
doesn't
currently
exist.
E
D
Think
I
think
what
your
the
way
you
phrase
that
I
feel
like
it
is
almost
entirely
tied
to
a
service
of
type
cluster
IP
because,
like
you
know,
I
I'm
thinking
of
cloud
load,
balancers,
naturally,
and
our
internal
load
balancers
would
not
be
limited
to
a
single
cluster
necessarily
so
that.
But
maybe
there
are
other
thing,
other
potential
means
of
implementation
that
I'm
missing,
but.
A
Helpful
anecdote,
but
to
give
some
I
guess:
I
have
some
context.
A
very
early
version
of
Kong's
Ingress
controller
actually
did
this
with
Gateway
and
it
did
use
service
type,
but
it
specifically
added
sorry
service
type
load
balancer,
but
it
specifically
added
the
cluster
IP
for
administrative
traffic.
A
That
is,
we
would
have
the
control
planes
and
that
may
actually
be
multiple
talking
to
the
Gateway
using
the
cluster
IP,
but
all
other
traffic
would
be
through
the
load
balancer
for
the
actual,
like
application
traffic.
We
ultimately
threw
that
away
because
there
was
not
really
much
support
in
the
community
at
that
time.
It's
probably
like
a
year
or
more
ago
for
having
that
for
differentiating
traffic,
administrative
traffic
versus
application
traffic,
but
I
can
see
the
use
case.
A
E
Yeah
the
way
to
think
about
it
too
right
where
hey,
if
I'm
running
a
cluster
and
I'm
running
key
now
I
would
want
to
expose,
for
example,
my
front-end
services
to
the
public
internet.
But,
for
example,
my
micro
Services
would
be
private,
but
I
still
want
to
potentially
benefit
from
all
the
L7
features
to
do
like
Canary,
rollout
traffic
splitting
and
things
like
that.
G
Can
I
ask
a
simple
question
from
everybody
new
to
these,
of
course,
what
I'm
seeing
that
was
as
I'm
preparing
all
this
info,
so
it
depends
upon
what
kind
of
traffic
where
the
traffic
is
for
application
based
traffic
or
it's
admin
traffic.
So
if
we
have
in
that
case,
if
you
think
that
the
Gateway
is
a
load
balancer
for
the
traffic,
then
that
should
be.
G
That
means
one
particular
load
balancer
other
or
the
the
local
Gateway
you
are
talking
about.
It
should
be
for
a
particular
app
particular
app
or
app
or
or
delivery
different
local
Gateway
for
the
admin
kind
of
traffic.
So
we
have
to
have
one
kind
of
classification
classification
in
the
top
right
foreign.
E
Use
case
the
There's
no
distinction
between
like
traffic
directed
for
the
app
well
I,
guess,
that's
pretty
much
everything
that
the
load
balance
or
that
the
traffic
going
through
the
any
Gateway
would
be
directed
to
the
user
app.
So
I
would
probably
distinguish
this
as
if
I
refer
to
admin
traffic
as
I.
Don't
know.
If
this
generalizing,
like
observability
like
Prometheus
scraping,
then
you
wouldn't
use
the
Gateway
for
that.
G
E
I
I
apologize
but
I
don't
understand
the
question.
Like
my
use
cases,
there's
user
traffic
people
are
deploying
apps.
They
want
those
apps
not
to
be
exposed
to
the
internet,
but
within
the
cluster
you
might
want
to
do
ll7,
load,
balancing
meaning
using
features
like
topic
splitting
and
things
like
that.
E
G
A
G
C
G
Have
even
application
Level,
so
my
my
thinking
was:
are
we
trying
to
prove
them
together?
Okay,
we'll
be
doing
one
set
of
application
and
in
another
set
of
hospital
within
another
set
of
application?
In
that
case,
when
you
are
talking
about
load
balancing,
you
are,
you
have
to
know
what
kind
of
application
your
load
balancing
is,
but,
but
if
you
are
to
reduce
that
complexity
to
one
level,
that's
fine,
only
all
application
will
be
a
one
load.
Balance
then
also
is
fine.
A
Yeah
in
Dave's
case,
it's
simply
the
difference
between
whether
or
not
traffic
should
be
allowed
to
come
in
from
outside
the
cluster
or
not.
There
should
be
a
way
to
discern
that
to
to
configure
that
Within
Gateway
is
what
he's
requesting
it
seems
really
to
me.
I
Rob,
you've
been
pretty
quiet
to
me.
It
seems
pretty
like
a
solid
thing
to
do.
I
do
get
that
it
has
implications
potentially,
for
you
know
everyone
else
who
doesn't
want
to
do
that.
D
Yeah
I
know
it
to
be
clear:
I
I
get
the
purpose.
I
get
the
idea,
I
think
I
think
it
makes
sense
somewhere
I'm,
not
sure
where
that
somewhere
is
for,
for
example,
let's
you
know
you
can
easily
go
down
a
rabbit
hole
of
well
hey
if
you
want
a
generic
way
to
configure
same
cluster,
why
not
have
a
generic
way
to
configure
same
network?
D
You
know
the
traditional
ilb
use
case
as
well
right,
because
at
some
point
there
will
be
more
weight
more
than
one
way
to
represent
that
as
well,
and
then
you
very
quickly
start
to
say:
well,
hey
right
now,
that's
represented
in
Gateway
class.
Why
isn't
this
concept
represented
in
Gateway
class
because
it
really
feels
like
a
you
know,
like
class
of
a
Gateway
right
a
this
is
where
a
Gateway
is
exposing
traffic
so
that
that
may
Belong
One
one
level
higher
than
this
would
currently
put
it.
D
E
E
Because
there
are
needs
and
a
lot
of
user
requests
to
not
have
a
mesh,
which
is
essentially
why
keenano
went
through
the
whole
hey.
We
use
this
Shield
at
the
beginning
and
we
spend
a
lot
of
time
abstracting
in
a
way
to
give
people
optionality
to
not
use
a
mesh,
and
this
is
sort
of
like
the
requirement
needed
to
get
that
because,
like
candidly,
like
istio,
supports
assigning
gateways
to
the
Ingress
pod
and
then
they
have
like
you
can
set
a
Gateway.
This
Gateway,
referring
to
the
istio
resource,
one.
E
The
same
deployment
as
what
I
was
kind
of
hitting
at
and
like
that,
so
that's
like
a
way
to
get
around
the
full
mesh
thing
and
we
have
ways
to
do
this
with
key
native
sort
of
like
Envoy
Gateway,
precursor
called
Courier,
which
we
kind
of
hand,
roll
ourselves
and
also
like
in
Contour
as
well.
We
have
a
setup
encounter
to
accomplish
this
being
gay
native,
this
sort
of
visibility
in
terms
of
the
mechanics
that
you're
describing
Rob
like
I
I,
don't
necessarily
know
what
the
right
thing
is.
E
I,
don't
know
if
that
means
that
I'm
like
in
terms
of
Gateway
class,
it
would
just
sort
of
be
where
you
would
specify.
This
is
just
like
a
top
of
my
head,
like
IP
ranges
as
a
as
a
thing
like
more.
It's
like
a
more
of
a
templated
thing
and
then
gateways
like
the
the
stamp
of
the
template
like
this
instantiation
of
the
class.
E
A
I
meant
other
implementations,
oh
because
that's
going
to
be
one
of
the
things
that's
really
going
to
help
to
kind
of
push.
It
would
be
that
you
know
this
is
something
that
more
than
one
implementation
needs,
but
if
it
is
something
that
only
one
implementation
needs
or
knows
that
they
need
that's
another
way
to
put
it,
you
may
be
the
only
one
that
knows
that
you
need
it.
A
C
E
A
C
H
H
So
you
know
one,
you
know
one
service
inside
a
namespace
may
call
itself
via
our
product
via
our
Gateway,
and
you
know
we
do
it.
We
we
don't
restrict
the
the
access
to
it
by
saying
that
it's
only
internal
access
but
I
could
see
the
value
in
that
the
the
other
thing
you
guys
were
talking
about,
there's
some
mention
of
sort
of
restricting
the
IP
address
range
as
a
part
of
the
Gateway
class.
H
Like
again
one
of
the
use
cases
we
do
that's
really
key
to
us
is
we
have
we
connect
to
a
number
of
network
domains,
so
you
know
usually
there's
only
one
like
internally,
maybe
there's
you
know,
there's
a
pod,
Network
and
there's
a
node
Network.
Externally,
though,
there
can
be
a
radio
Access,
Network
and
operations,
Administration
and
maintenance,
Network
and
services
network,
a
DMZ
to
the
internet,
Network
and
they're
all
separate
and
sort
of
at
the
Gateway
class.
H
That's
where
I'm
expecting
you
would
configure
which
of
those
you
can
reach
and
how
and
I
think
that's
similar
here
where
you
could
configure.
You
know
that
you
just
are
listening
on
that
internal
Network
and
not
on
any
external
network,
and
that
would
be
the
equivalent
of
having
an-
and
you
know
this,
this
just.
B
I
I
One
service
of
type
load
balancer
that
could
accept
external
traffic
and
then
another
like
service
like
a
type
cluster
IP,
and
then
you
kind
of
bind.
You
have
like
a
listener
resources
which
defines
like
what
course
you're
listening
on
so
you
just
have
you
create
two
listener
resources
pointing
to
whatever
importance
that
the
services
are
going
to
be
exposed
on
and
then
that
that's
how
you
can
get
one
listener?
That's
is
accepting
external
traffic
and
another
one.
That's
only
really
for
internal
traffic.
A
For
popping
in
with
that,
so
there's
use
cases.
So
that's
established,
that's
something
that
maybe
we
should
kind
of
push
up
a
little
bit,
but
then
there's
Rob's,
open
question
and
Philip
talked
to
it
a
little
bit
about
whether
or
not
it
belongs
in
light
Gateway
class.
We
are
kind
of
we
have
kind
of
spent
a
lot
a
lot
of
time
on
this
all
and
we
do
have
a
reasonable
amount
of
agenda.
D
I
I
can
put
this
on
the
issue
itself,
but
I
think
I
I
have
two
questions
here:
I
I,
don't
doubt
and
I
think
we've
seen
clearly
that
there
are
very
clear
use
cases.
The
two
questions
that
I
am
very
interested
in
answering
is
where
this
belongs
specifically,
if
it
would
make
sense
on
Gateway
class
and
and
then
very
related
to
that.
To
that
do
we
want
to
differentiate
between
same
network
and
same
cluster
or
my
conscience.
There
are
going
to
be
implementations
that
can
support
one
or
the
other,
but
not
both.
D
There
are
going
to
be
implementations
where
internal
means
internal
to
the
cluster
and
other
implementations
where
internal
means
internal
to
the
network,
but
there's
probably
not
a
lot
of
overlap,
but
just
clearly
stating
what
we
actually
want
and
I'd
like
to
make
sure
we've
covered
both
of
those
with
this.
With
this
work.
A
D
A
D
A
C
A
A
D
John
and
so
I
sorry
I
missed
this
and
from
chat
but
I
wanna
I.
Think
John
asked
another
very
important
question:
I
is
this
bigger
than
just
cluster
IP
right,
like
I?
Think
John
is
talking
about
a
general
way
of
configuring
in
cluster.
Anything
like
how
you're
mapping
config
to
services,
because
I
think
maybe
90
of
active
implementations
today
were
some
very
large
proportion
are
taking
a
Gateway
and
mapping
it
to
a
service
resource,
and
although
this
is
just
one
piece
of
that
config,
that's
probably
another
good
open
question.
D
F
I
was
just
suggesting
that
every
implementation
today
that
is
in
cluster,
is
solving
the
same
problems,
but
they're
doing
them
in
different
ways
that
you
know
whether
it's
a
cluster
IP
service
or
load
balancer
service.
It's
just
a
small
subset
of
the
problem.
There's
plenty
of
other
fields,
really
every
field
in
service
or
deployment
or
whatever
fields
are
being
created
as
something
that's
potentially
in
scope.
We
don't
necessarily
need
to
solve
the
equal
1000
fields
of
API
spec.
F
E
A
A
A
D
D
Could
we
have
a
meeting
time
that
people
in
Europe
could
actually
make
it
to,
and
it
would
be
nice
if
we
could
actually
try
that
out
or
experiment
with
it
by
just
trying
to
understand
the
potential
impact
of
that
on
the
attendees
of
today's
call,
if
we
were
to
consider
rotating
similar
to
gamma
already
does
and
have
one
meeting
every
other
week,
that
was,
you
know
eight
or
nine
a.m.
Pacific
roundabouts.
D
A
D
D
D
Keith
did
a
great
job.
I
think
this
was
a
follow-up
from
a
gamma
meeting
of
actually
trying
to
describe
the
current
pain
points.
If
anyone
has
others,
please
add
them
to
this
list.
This
is
really
just
intended
to
be
a
discussion.
Point
of
anything
you
don't
love
about
policy
attachment
today
would
be
good
to
understand
and
quantify
with
that
said.
I
I
have
some
ideas,
go
ahead,
Shane
I'm,
sorry,.
D
No
I
have
some
ideas:
I
posted
them
below
in
here
and
I.
Think
they're,
largely
representative
of
things
that
we
have
already
been
talking
about
as
a
community
one
there's
this
idea
of
building
more
into
the
API
itself.
So
in
the
case
of
timeouts,
maybe
there
is
some
if,
if
we
allow
our
spec
to
be
just
a
little
bit
more
vague,
maybe
there's
some
space
in
there
for
some
kind
of
timeout
configuration,
I
I,
don't
know
it
they're.
D
A
It
absolutely
does
the
other
thing
I
was
going
to
add
real
quick
was
just
if
anybody
here
is
using
policy
attachments.
This
might
be
a
decent
thread
to
come
in
and
say
if,
particularly
if
you
have
pain
points
or
even
if
you
don't
come
in
and
kind
of,
add
hey,
we
are
using
policy
attachment
and
here's
how-
and
this
is
how
it's
painful-
that's
helpful,
I
think
to
this
conversation.
D
I'll
say
4G
for
gke
we've,
we've
implemented,
I
think
three
different
policies
today,
but
despite
them
using
the
current
model,
they
could
probably
be
represented
just
as
well
as
meta
resources,
because
they're
really
in
at
least
one
or
two
cases,
they're
really
tied
to
a
specific
resource
and
hierarchy,
doesn't
really
work
for
them.
So
that
seems
to
that
seems
to
go
well
with
Nick's
idea
of
meta
resources.
A
In
a
not
quite
like
that,
but
at
Kong
what
we've
done
is
danced
around
policy
attachment
by
almost
doing
it
multiple
times.
So
we
actually
had
some
existing
resources
that
attached
to
resources
to
basically
add
additional
configuration
from
the
Before
Time,
and
we
are
just
continuing
to
use
those
at
the
moment.
But
they
don't
they
they're,
not
in
the
vein
of
policy
attachment.
A
A
A
D
Not
record,
no,
it's
not
required
for
GK.
We've
tried
to
group
related
things
together,
so
you
would
have
get
on
in
one
example,
we
have
a
way
to
configure
custom
health
checks,
and
so
we
group
everything
related
to
health
checks
together
in
one
policy
and
others,
you
have
a
policy,
that's
related
to
you,
know
gcp
specific
settings
for
our
backend
yeah,
yeah
and
interesting.
That
Lewin
is
saying
that
you
can
attach
policy
to
either
Gateway
or
route,
but
I
guess
that's.
I
am
specifically
that's.
K
K
D
C
D
C
D
The
the
problem
with
any
kind
of
block
like
that
that
is
kind
of
you
know
open-ended,
is
that
you,
you
have
recreated
annotations
just
in
a
different
in
a
different
place
and
there's
not
really
good
way
to
validate
or
really
provide.
Much
of
anything
with
that
said,
it
may
be
preferable
to
policy
in
some
cases.
C
D
Notice
that,
for
example,
on
TLS,
we
have
an
options
field
which
it
feels
a
lot
like
that
it's
just
a
match,
string
string.
Maybe
there
are
some
places
where
we
could
I,
don't
I,
don't
want
to
completely
rule
it
out
I.
Just
we.
We
have
to
be
careful
that
I
I
really
want
to
wherever
we
can
push
for
proper
solutions
that
really
solve
it
the
right
way,
and
if
we
provide
too
many
easy
ways
to
kind
of
you
know
everyone
does
their
own
thing.
Then
we
have
ended
up
with
Ingress
V2.
A
B
D
So
I
was
talking
with
who
you're
this
this
morning.
Actually
he's
been
doing
a
lot
of
really
great
performance
tests
around
redirects
rewrites
and
the
next
one
on
his
list
is
request
mirroring
and
that
is
more
complicated
than
I,
initially
thought
about,
and
just
wanted
to
throw
it
out
as
anyone
have
ideas.
So
the
idea
with
request
mirroring,
is
obviously
that
you're
you're
sending
a
request
to
both
the
main
primary
back
end
and
sending
a
copy
of
that
request
to
a
mirrored
back
end.
What
do
we
do?
For
conformance?
A
F
D
D
A
A
Okay,
this
is
quick
Blix
our
project
for
a
reference
and
testing
implementation
layer
for
implementation
for
Gateway
API
has
had
its
first
pre-release.
It
has
a
very,
very
basic
level
of
UDP
route
support.
So
I
just
wanted
to
shout
that
out
here
and
let
people
know
the
next
steps
are
going
to
be.
Finally,
getting
this
license
thing
figured
out,
there's
still
some
kind
of
feed
Dragon
when
it
comes
to
the
GPL
V2
we're
starting
on
the
TCP.
A
A
But
just
not
you
know,
like
most
other
things
of
this
sort,
so
we
do
a
code
Jam
every
Friday
right
now
that
is
called
the
gateway,
API
code
or
yeah
Gateway
API
code
gym
we're
mostly
focusing
on
books
for
that
right
now,
it's
usually
about
six
people
show
up
and
we
just
do
like
look
at
code.
Sometimes
we
do
live
coding,
and
sometimes
we
just
talk
about
the
issues
in
the
project
and
stuff
like
that.
A
D
Cool,
that's
awesome
all
right,
yeah,
my
my
next
one
up
is
just
I've,
been
thinking
a
lot
about
070
and
specifically
the
idea
of
request,
rewrites
and
redirects
path,
redirects,
making
it
to
Beta
graduating
to
the
standard
Channel,
and
our
current
graduation
requirements
are
really
there's
two
forms
of
them.
There's
the
alpha
beta.
We
have
implemented
by
several
implementations
and
several
generally
means
more
than
two.
So
it
has.
C
E
D
A
Yeah,
okay,
Mikhail
asked
a
good
question
in
chat,
so
yeah,
even
if
two
implementations
support
a
feature
are
we
sure
any
users
actually
tried
it?
This
is
a
good
question
no
by
by
default.
We're
not
like
positive
of
that.
You
know.
Obviously,
if
you
just
implement
it
doesn't
mean
people
are
going
to
use
it
because
most
people
I
think,
will
stray
away
from
using
anything
in
production.
That
has
the
word
V1
Alpha
on
it,
you
know
or
whatever,
but
we
could.
We
could
ask
more
about
that.
A
A
There
are
four
implementations
I
found,
including
Kong's
Implement,
two
implementations
to
comics
of
technically
five
that
currently
implement
or
sorry
four
that
currently
Implement
UDP
route
like
you
can
use
it
and
one
which
is
nginx.
That
says
it
will
but
isn't
from
what
I
can
tell
quite
doing
that
yet,
which
is
great
by
the
way
for
The
L4
story.
We
have
that
many,
but
I
think
getting
UDP
route
over
the.
We
don't
want
it
to
be
an
alpha,
because
people
won't
will
be
worried
about
wasting
time
on
it.
A
Hump
under
these
terms
would
be
better
so,
and
it's
a
very
simple
API
right
now
so
I
mean
that's
the
that's.
The
the
best
thing
we
can
do
strategically
is
okay
yeah.
If
we
take
this
kind
of
approach,
we
just
have
to
be
extremely
is
judicious
the
right
word,
I.
Think
judicious
is
the
right
word
about
what
actually
ends
up
in
those
specs,
because
we're
gonna
commit
to
you
know
maintaining
it
longer
term
sooner
so,
yeah.
D
Yeah
completely
agree
and
there's
been
a
good
good
conversation
in
chat
as
well.
Brian's
comment
that
no
one
wants
to
play
crystal
ball
gazing
game
of
guessing
which
to
invest
in
yeah
I,
get
that
it's
a
a
tough
problem
and
and
I
others
are
saying.
Yeah
I
would
love
to
have
end
user
usage.
I
wish
we
could
find
a
reliable
way
to
gauge
that
I
know.
C
A
H
H
A
A
On
this
one,
no
yeah,
we
appreciate
the
the
input
on
that
I
guess.
I
guess
I
still
would
ask
the
question,
though,
like
so
as
somebody
who
feels
like
they're
more
on
the
user
side
of
things,
do
you
feel
like
Alpha
to
GA
having
two
conformant
implementations,
two
implementations
committed,
you
know:
do
you
think
this
is
a
good
change
from
your
perspective.
B
A
A
D
C
A
D
A
F
A
A
A
I
haven't
personally
had
the
Mo,
the
the
correct
motivating
feature
like
the
things
in
my
work
and
stuff
like
that
to
motivate
me
to
complete
it,
but
we
did
make
this
issue.
We
know
now
that
we
have
at
least
four
implementations
that
do
something
like
this
static
and
unmanaged
Gateway.
For
those
who
don't
know
is
the
idea
that
you
could
have
a
Gateway
implementation,
where
you
don't
provision
the
Gateway
or
you're,
not
responsible
for
the
life
cycle
of
the
actual
Gateway
resource
that
is
posted,
but
instead
that
life
cycle
is
managed
elsewhere.
A
In
some
cases,
that
may
be
by
helm
by
hand
by
a
human,
but
you
still
be
able
to
use
the
Gateway
Resource
as
kind
of
a
reflection
of
what's
going
on
with
that
existing
Gateway.
Multiple
implementations
do
this
today
and
there
is
some
prior
art
as
to
like
what
it
kind
of
means,
but
it's
never
been
fully
documented,
and
so
this
is
becoming
kind
of
a
sticking
point
for
gamma,
because
there
is
some
need
among
I
think
it
was
specifically
Linker.
A
B
D
A
Apparently,
with
Linker
D
and
I'm
probably
going
to
be
wrong
here,
but
I'll
try
apparently
with
link
a
d
I
I
know
with
Kuma.
There
is
a
there's,
a
Gateway
API
implementation
that
actually
supports
a
gateway
and
so
I
think
Linker
D
is
just
trying
to
do
something
similar
where
you
can
get
Ingress
requests
into
the
mesh
network
using
Gateway
API,
that's
my
guess,
and
so,
but
they
don't
have.
A
A
D
J
J
D
C
A
A
You
all
right
cool
all
right
and
we
are
right
at
time.
So
let's
go
ahead
and
close
it
up.
We
had
one
issue
left,
that's
the
first
time
we
got
to
triage,
we
got
through
everything
at
least
did
enough
to
bump
them.
Thank
you
very
much.
Everybody
for
your
time
feel
free
to.
If
you
had
anything
that
came
up
here
today,
make
sure
that
you
put
stuff
on
for
next
week's
agenda,
or
you
know,
catch
up
with
us
in
slack
until
next
time.