►
From YouTube: SIG Network Gateway API meeting for 20230403
Description
SIG Network Gateway API meeting for 20230403
A
We
are
still
doing
where
are
getting
still
getting
back
to
doing
attendees
on
the
meeting
doc,
because
this
is
helping
us
to
track
kind
of
who's
going
to
what
meetings
and
stuff
like
that.
So
if
you
would
please
take
a
second
to
Just
note
yourself
on
the
meeting
doc
as
having
attended
this
one.
We
appreciate
it.
A
A
We
have
not
stopped
and
asked
if
there's
anybody
new
in
the
audience
and
I
may
have
seen
a
couple
of
new
faces.
So
if
you
are
new
or
if
you're,
maybe
not
new,
but
you
just
want
to
introduce
yourself
and
kind
of
tell
us
a
little
bit
about
yourself
and
what's
going
on
with
your
story
with
Gateway
API
we'd
love
to
hear
it.
A
B
Hi
everybody:
this
is
Kenneth
Bingham
with
net
Foundry
and
we
have
the
open
source
project
open
ZD,
it's
a
zero
trust,
overlay
software
defined,
sdks
and
Gateway
stuff
and
just
trying
to
come
up
to
speed.
Don't
really
have
anything
to
add
at
this
point
just
trying
to
learn
and
see
how
you
guys
work
and
see
if
I
have
a
chance
to
add
value.
A
A
A
I
should
not
be
sharing
all
right
all
right,
so
we
have
I
mean
we,
it's
not
a
small
agenda,
but
if
you
have
anything
that
you
want
to
add
and
you're
kind
of
that
you're
thinking
about,
please
do
feel
free
to
add
it
above
triage.
If
you
still
want
to
add
something
we
might
be
able
to
get
to
that
I
think
we
probably
will
Rob
go
ahead.
We'll
talk
about
the
v070
released.
F
Yeah
anyone
anyone
can
talk
about
this,
but
I
just
added
to
the
agenda.
The
070
releases
top
of
mind
for
I
think
all
of
us,
it's
between
us
and
ga,
so
070
is
something
that
we're
hoping
to
do
a
freeze
for
a
feature
freeze
for
this
week.
I
think
Shane
announced
that
sometime
last
week
that
starting
on
Thursday,
we
will
be
doing
a
feature
freeze,
which
means
anything
getting
into
070
needs
to
get
in
before
then,
and
that
means
needs
to
merge
before
then
you'll
see
the
070
Milestone
is
massive.
F
This
is,
you
know,
really
not
not
realistic
at
this
point,
but
if
you
notice
there's
only
a
few
of
the
items
in
the
in
that
Milestone
that
are
labeled
release
blocker,
that
is
by
Design
anything
that
is
not
labeled
a
release
Blocker
in
that
milestone,
we'll
just
get
pushed
to
the
next
Milestone.
If
we
run
out
of
time,
so
that's
going
to
be
the
majority
of
things
that
are
still
open,
the
ones
that
we
have
remaining
one
is
I.
Think
Shane.
This
one
is
yours.
F
A
So
in
the
past,
we
we,
when
we
added
supported,
features
we
kind
of
got
into
a
mixed
mode,
where
we
weren't
being
really
consistent.
So
like
we
had
like,
for
instance,
reference
Grant
was
something
that
you
kind
of
had
to
opt
into,
but
Gateway
wasn't
wasn't
really
a
problem,
except
now
that
we
have
mesh
conformance
tests.
So
the
big
thing
driving
this
change
is,
if
you're
doing
mesh,
you
may
not
be
doing
Gateway.
Some
are
some
aren't,
but
now
it's
actually
an
optionable
thing.
A
A
It's
also
just
generally
more
consistent
because
we
weren't
being
super
consistent
once
we
added
supportive
features
and
then
it
can
help
to
lead
a
little
bit
into
the
conformance
profiles
which,
if
we
continue
the
direction
that
we're
going,
would
eventually
use
features
as
substrate
for
poor
for
profiles.
How
features
features
would
basically
be
composed
into
or
sorry
the
other
way
around
profiles
were
just
would
just
be
a
collection
of
features,
so
it'd
be
helpful
for
that
too,
so
it
doesn't
do
a
whole
lot.
A
A
F
Yeah
I
can
I
mean
this
is
I,
think
non-controversial
it's
we
already
have
request
header
modifier
in
the
API.
This
is
the
same
thing.
It
sat
for
long
enough.
It
meets
all
the
graduation
criteria.
It's
I
think
just
a
formality
to
get
it
across,
but
because
we're
graduating
a
feature
from
experimental.
The
standard
really
are
looking
for
as
many
LG
Tams
as
possible,
trying
to
show
broad
consensus
as
part
of
the
graduation
criteria
of
any
feature.
F
A
A
F
F
My
understanding
of
the
the
direction
here
is
that
that
is
not
an
explicit
goal,
so
maybe
we
can
modify
the
spec
to
just
say:
don't
add
it
if
it's
not
already
there,
which
I
think
would
match
envoy's
Behavior
if
I'm
understanding
correctly
like
if,
if
host
header,
does
not
specify
a
port
and
there's
a
redirect
to
80
or
443,
it's
not
going
to
explicitly
add
that
Port.
It
is
my
understanding
which
makes
sense
to
me
before
I
go
any
further.
Does
that
line
up
with
what
others
are
thinking
here.
G
So
I
think
there
are
two
different
issues
right
so
envoy
can
strip
the
board
using
some
other
functionality
right.
But
the
issue
here
is
that
the
client
that
is
sending
the
request
is
appending.
The
port
I
mean
implicitly
to
the
host
header,
so
I
guess
what
I'm?
What
I
was
suggesting
is
usually
when
you
are
sending
to
Port
80,
you
don't
append
the
port
to
the
host
header.
So
that's
something
that
could
be
done
in
the
client
in
the
in
the
conformance
client
itself.
F
G
H
I
But
we
still
need
to
specify
how
the
system
should
behave
when
it's
there
and
when
it's
not
there
right,
which
actually
has
both
cases.
So
we'd
probably
want
to
remove
the
implicit
Behavior
so
that
we
can
test
both
variants
and
then
we
can
decide
either
they
should
both
be
stripped
or
what
Rob
said,
and
you
just
don't
add
it
now.
I
try
to
implement
it
as
they're,
both
stripped
because
that's
what
the
test
tier
is
doing.
I
couldn't
find
a
way
to
do
an
Envoy
it.
I
H
H
G
H
G
I
think
you
could
do
something
else
in
in
the
in
the
I
think
in
HTM
or
outconfig.
I
can
look
at
what
that
is,
but
I
think
the
bigger
question
which,
with
John
raised
is
there
are
two
things.
One
is
what
is
being
sent
and
clarification
that,
even
if
you
send
you
explicitly
explicitly
add
a
port
to
the
host
header,
it
should
be
part
of
the
location,
header
for
Port,
80
or
not
or
any
other
I.
Think.
H
That's
so
yeah,
so
the
I
guess
the
so
yeah
in
terms
of
the
settings
I
agree
that
the
conformance
test
should
be
able
to
test
explicitly
adding
a
port
or
not
explicitly
adding
Port
yeah,
and
there
should
be
a
way
to
do
that
for
sure.
But
then
the
way
that
we
have
that
I
wrote
the
spec
there
is.
That
is
to
do
what
it
says
in
the
IFC
for
redirects,
which
is
if
the
scheme
is
HTTP
and
the
port
ends
up
to
be
80.
H
You
shouldn't
specify
this
port
practically,
it
doesn't
seem
like
that
is
really
achievable
the
and
so
the
so
like.
Probably
what
we
need
to
do
is
instead
just
say
it's
just
stripping
back
like
Rob,
says
and
say:
if
a
port
was
supplied
in
the
requests,
always
just
append
that
port
right
like
because
that's
what
the
client
is
expecting
and
that's
what
the
client
gets.
A
A
A
F
F
Right
so,
given
that
I
think
we,
you
know,
my
my
proposal
here
is
that
we
we
have
a
reasonable
should,
which
is
principle
of
least
surprise,
which
is
whatever
whatever
we
got
in
the
host
header.
We
we
try
and
keep
that
as
close
to
POS
as
close
to
what
it
originated
as
as
possible,
unless
there's
something
completely
different
there
and
then
second,
we
loosen
these
conformance
tests
to
be
more
welcoming
of
either
option.
F
J
Should
we
run
one
of
the
HTTP
compatibility
tests
because
I
think
there
are
some
compatibilities
for
HTTP
itself
and
say
that
if
we
support
https
and
http,
the
street
bus
and
I
don't
know
similar?
If
you
know,
we
are
saying
that
we
support
the
Java,
we
should
pass
the
serverless
compatibility
test
and
similar
things
that
exist
in
the
world.
A
Yeah,
if
I'm
understanding,
you're
correctly
I,
think
the
suggestion
is,
we
would
run
tests
to
see
if
what
we
have
is
conformant,
and
that
seems
fine,
but
if
we
find
out
that
it
is
we're
not
going
to
try
to
like
not
work
with
Envoy
right,
if
they're,
not
so
I,
don't
know,
yeah
I!
Think
that's
fine.
If
somebody
wants
to
run
that.
F
F
J
But
the
point
of
the
HTTP
performance
tests
are
to
verify
that
all
implementation
of
httpr,
conformant
and
again
so
browsers
and
clients
don't
have
unexpected
behave
anyway.
It's
not
a
big
deal,
but
it
will
be
good,
at
least
to
know
which,
which
implementations
are
passing
HTTP,
maybe
as
a
separate
performance.
This
is
conformal
to
get
to
API,
but
it's
not
confirmative
HTTP
specification,
so
clients
should
know
at
least
that
anyway,
not
a
big
deal.
Yeah.
A
And
if
you
want
to
actually
I
mean,
if
you
have
thoughts
on
this
and
stuff,
please
do
throw
them
on
1880
we'd
love
to
have
them.
It
sounds
like
we're,
probably
pretty
close
to
being
able
to
figure
something
out
here.
It
doesn't
sound
like
we're
in
a
really
sticky
position.
So
that's
good,
but
we
are
getting
kind
of
like
past
20
minutes
on
this
first
thing,
so
just
in
case
I.
A
F
A
Okay,
yeah:
we
are
in
a
time
crunch,
so
please
do
jump
on
1880
quickly.
After
this
meeting
at
least
post.
You
know:
hey,
I'm,
I
have
a
problem.
Let
us
know
all
right:
oh
I
didn't
mean
for
this
one
to
be
in
these
meeting
notes.
Yet
Rob
remind
me
if
we
made
a
specific
decision
on
the
next
earlier
time
we
did
didn't.
We.
F
A
H
F
E
A
C
E
A
C
E
F
F
If,
if
there's
a
broad
set
of
ports,
we
we
want
that
behavior
to
be
consistent,
but
I
know
that,
as
you
kind
of
mentioned,
there
are
some
implementations
that
just
cannot
support
the
full
range
of
ports
that
exist,
and
so
that's
kind
of
been
our
our
differentiator
between
core
and
extended
conformance.
So
I
would
say
this
is
a
concept
that
really
belongs
as
extended.
In
my
opinion,.
E
H
A
I'll
just
add
to
that
I'm
in
a
similar
boat,
with
kubecon,
unfortunately
being
the
center
of
my
world,
but
also
draft
PR's
I,
don't
usually
look
at
them
unless
pinged
I
assume
that.
But
if
you
catch
me
on
slack
and
if
you
have
some
questions
stuff
like
that,
I'd
be
happy
to
follow
up
with
you
on
this
one.
When
I
have
some
time.
Hopefully,
I'll
have
a
little
bit
before
kubecon.
To
give
you
some
feedback.
A
A
B
E
F
K
A
Yeah
at
Kong
we
have
one
implementation
which
does
not
support
it
because
it
uses
what
we've
been
calling
a
static
mode.
Rather
instead
of
provisioning,
the
Gateway,
it
actually
uses
a
static,
existing
Gateway.
So
there's
no
way
to
do
it
in
that
one,
but
we
have
one
that
does
support
Dynamic
listeners,
so
we're
kind
of
in
a
mixed
mode,
but
the
the
other
one
is
by
far
has
the
bigger
user
base.
So
we
wouldn't
be
able
to
move
that
in
any
kind
of
hurry.
A
Cool
he
said
yep
in
chat.
All
right
well
continue
to
follow
up
with
us
on
this
one
and
after
kubecon,
especially
when
we
get
a
little
bit
more
time
back.
Maybe
we
can
work
on.
You
know
what
it
is
that
helps
you
best.
What
what
kind
of
solution
you
need
all
right,
Candace,
the
Gap
issue
that
you
just
opened.
L
We
tried
to
collect
TLS
use
cases
from
you
know
we
prepared
to
cover
all
the
bases
with
those
cases,
and
this
is
a
a
new
gap
which
is
very
tightly
scoped
to
just
a
couple
of
those
use
cases,
and
these
use
cases
are
specifically
to
address
what
I've
listed
here.
Let
me
see
a
little
just
to
read
it
out.
Specifically,
to
address
the
single
use
case
as
a
client
implementation
of
Gateway
API
I
need
to
know
how
to
connect
to
a
back-end
pod
that
has
its
own
certificate.
L
L
L
L
K
Are
we
yeah,
I
think
one
of
the
slight
subtlety
to
personas
is
we
should
discuss
cross
namespace
referencing
and
what
that
means
like
the
service
is
in
one
name
space
in
the
oh.
Is
it
another
name
space,
but
I
think
it
might
be
useful
to
call
that
out,
because
I
think
that's
I
think
if
it's
like
within
the
same
name
space,
it's
like
okay,
I
get
it
like.
Probably
it's
under
the
same
domain,
but
the
cross
name
space
is
something
we
should
call
out.
Yeah
I.
H
Agree
that
we
should,
as
part
of
the
implementation
but
I,
think
for
for
this
initial
thing.
The
the
the
the
thing
that
has
been
hard
in
the
past
here
is
to
get
everybody
to
agree
on
the
thing
that
we
are
solving
for,
and
so
that's
the
point
of
this
PR
is
to
say:
okay,
we're
trying
to
solve
for
this
specific
use
case
and
not
for
mesh,
not
for
dynamic
things.
H
That's
why
the
non-goal
section
is
so
long,
because,
basically,
we
are
explicitly
going
through
and
putting
a
line
through
all
of
the
ways
in
which
you
know
sort
of
trying
to
sort
out.
This
has
been
complicated
in
the
past
by
you
know
by
people
having
the
sort
of
reasonable
questions
about
all
well.
But
what
about
this?
Or
what
about
this?
So
what
about
this?
It's
like!
We
want
to
be
like
explicitly.
H
H
This
is
a
good
case
for
like
a
direct
attached
policy
and
or
something
similar,
and
if,
if
we
did
something
like
that,
then
it
would
need
to
live
in
the
same
namespace
as
the
service
that
it's
modifying,
and
so
you
know
the
the
ID
and
that
again
that
gets
into
the
implementation
a
little
bit
but
depending
on
how
we
do
the
implementation.
More
than
likely
it's
going
to
be
a
more
than
likely
it's
going
to
be
a
little.
H
J
Yeah
I
mean
it
answers
the
question
of
how
you
can
Define
not
only
some
use
cases
that
where
it
would
make
sense
to
have
this
API
I'm,
not
entirely
sure
that
how
it
will
work
in
the
bigger
picture
when
we
consider
that
we'll
have
to
solve
this
for
egress,
we'll
have
to
solve
it
for
measure.
But
if
I
understand
it's
not
the
use
case
for
your
particular.
You
know
this
issue
in
particular,
but
it's
not.
H
You
know
what
we're
trying
to
do
here
is
to
hit
these
specific
one,
because
there
are
people
who
need
this
right
now,
and
so
this
at
least
we
have
a
data
point
for
saying
we
tried
this
and
it
worked
or
it
didn't
work,
it'll
go
in
an
experimental.
So,
like
you
know,
it'll
there
will
be
a
method
to
do
this
and
we
can
try
it
out
and
see
what
happens.
I
agree
that
we
need
to
solve
all
of
those
problems.
J
I
mean
yesterday
does
have
this
feature
for
credit
for
quite
a
while,
so
we
kind
of
know
how
it
works.
It's
not
a
lack
of
knowing
how
it
works.
I'm,
just
saying
that
if
we
want
where
to
pick
one
case
where
this
will
be
very
important,
very
useful,
it's
egress
use
cases
not
Services
is
a
in
the
cluster
yeah.
J
Has
this
feature
I
I
completely
agree
that
other
people
should
try
it
and
other
implementation
should
have
it,
and
eventually
we
should
have
a
common
API,
but
we
need
to
figure
out.
What
is
you
know?
The
best
way
to
have
you
know
multiple
implemented,
because
something
between
is
your
destination.
Rule
and
I.
Don't
know
what
other
vendors
have
where
you
can
find
Common
Grounds
that
can
be
implemented
all
of
them.
Can
you
hear.
K
A
Yes,
yes,
we
can
train
okay,
my
computer,
randomly
powered
off
I'm,
sorry
about
that.
I'm
gonna
have
to
check
my
kernel
logs
after
this
I.
Don't
know
what
the
anyway
I'm
co-host
now
in
case
that
happens
again.
If
it
does
Rob
Nick
just
take
over
I,
don't
know
but
I
think
at
this
point,
given
how
much
the
need
is.
A
We
want
to
make
a
beeline
for
at
least
getting
into
experimental
with
a
solution,
at
least
before
we
start
trying
too
hard
to
boil
the
ocean,
because
we
need
to
at
least
get
to
that
point
where
we
can
show
something
that
works,
and
then
we
can
kind
of
stop
and
readjust
a
little
bit.
But
if
we
get
stopped
up
in
the
early
stages
before
we
can
even
get
something
that
we
can
try
out.
H
The
custom
I
think
it's
really
important
for
us
to
make
clear
that
egress
is
explicitly
not
happening
until
later
this
year,
because
where
we
can't
do
it
man
before
before
GA,
we
can't
do
anything
to
do
with
the
us.
There
is
just
there's
not
enough
bandwidth,
maintainer
bandwidth,
to
be
able
to
handle
egress,
because
it
is
a
whole
cabin
can
of
worms.
No.
A
Yeah
I
think
the
point
just
being
that
we
are
eventually
going
to
try
to
do
what
you
said
like
we'd
like
to
have
something
that
everybody
can
Converge
on,
but
we
are
going
to
be
guarded
with
this
one
like
to
try
to
get
it
to
move
so
that
we
don't
end
up
in
the
same
position:
We've
Ended
up
multiple
times,
because
there
are
solutions
that,
for
instance,
can't
won't
even
Implement
Gateway
API
because
they
need
this.
This
is
a
requirement
I.
K
A
I
A
I
Yeah,
a
terrible
experience
but
I'm
a
bit
concerned
that
we're
saying
we
we
have
to
do
this
experimental
thing.
We
can't
to
do
other
experimental
things
because
we're
too
busy
for
GA
and
we
have
to
focus
on
GA
things
and
there's
a
lot
of
concern
that
this
is
not
the
appropriate
thing.
But
we
need
to
do
something
now,
because
people
are
blocked
on
adopting
Gateway
API,
but
they
shouldn't
be
adopting
Gateway
API
for
an
experimental
feature,
because
that
can
change
an
eight
point
and
like
when,
should
we
push
back
on
this?
I
K
A
K
B
I
Yeah
and
they
have
like
there's
a
variety
of
reasons
why
it
may
or
may
not
make
sense.
But
what
doesn't
make
sense
to
me
is
saying
we
want
to
push
forward
on
this
thing,
because
it's
blocking
users
from
adopting
it
and
therefore
we
are
okay
with
doing
something
except
optimal
and
we
should
push
back
at
some
later.
D
I
A
We
are
saying
we
are
trying
to
be
very
clear
about
Our
intention
to
help
it
move
more
healthfully
than
previous
iterations.
That's
the
main
goal.
If
you
ultimately
have
to
block
it,
we're
not
saying
no
don't
block
it,
we
will.
We
will
push
through
your
block,
we're
saying
think
about
the
the
progress
that
we're
trying
to
achieve,
which
is
at
this
point
just
saying
there
is
a
thing
that
we
would
like
to
do
something
about
and
see.
A
J
Yeah
I
mean
as
an
HD
developer,
since
we
had
this
API
for
five
years.
We
obviously
cannot
argue
that
is
not
useful
or
they
are
not
use
cases.
I
mean
it's
something
we
support
and
a
lot
of
our
users
are
using
this
API,
not
only
for
this
narrow
use
case
we
Define
but
far
more,
but
that
includes
the
use
cases
you
have
here.
My
my
concern
is
to
make
sure
that
again
we
learn
from
lessons
from
different
implementations
that
exist,
these
two
and
probably
others
that
do
the
same
thing.
J
F
F
There
is
a
finite
amount
of
room
beyond
that
for
for
gaps,
but
they
are
a
lower
priority
than
getting
to
ga
I
think
this
is
a
very
important
Gap,
so
in
any
Cycles
I
have
that
are
not
devoted
to
ga.
This
will
be
something
that
I'm
thinking
about.
I
would
also
say,
like
I
I
agree,
we
do
not
want
to
let
non-optimal
things
into
this
API.
The
API
already
has
a
lot
of
features.
F
F
We're
going
to
try
and
help,
but
it
is
still
a
complex
topic
and
even
with
the
very
narrow
scoping,
it's
not
going
to
be
something
that
just
you
know
is
in
the
API
tomorrow
kind
of
thing
this
is
this
is
going
to
take
time.
It
has
taken
time.
We
want
to
be
very
intentional
about
that,
but
at
the
same
time
this
is
a
pretty
significant
Gap
in
our
current
API
structure
and.
D
F
A
K
A
And
again
that
was
kind
of
the
hope
with
just
the
what
and
the
why.
As
a
provisional
thing,
we
were
kind
of
hoping
to
just
like
at
least
get
the
question
down,
so
that
we
could
just
lower
the
scope
of
those
discussions
a
little
bit
so
we'll
see
how
that
goes.
But
yeah
I
understand
that
there
will
probably
have
to
be
a
lot
of
discussion.
L
Just
just
just
to
cap
it
off
Shane,
just
the
we
will
definitely
not
be
talking
about
any
of
the
implementation
details
until
we
all
come
to
the
understanding
that
why
we're
doing
this
than
the
purpose
for
it
right.
So,
if
there's
anyone
who
already
thinks
that
this
is
not
worth
doing,
how
would
they
register
that?
Just
by
saying
this,
this
is
not
worth
doing
on
the
on
the
gap,
or
do
we
already
have.
A
B
K
A
Please
come
to
the
Gap
with
your
really
legit
comments.
Thank
you
thanks.
Yes,
thank
you
appreciate
all
the
effort
that
you're
putting
in
all
right
I
just
had
a
little
one
that
I
added
at
the
end
here,
but
we
only
have
five
minutes.
I
guess
this
is
more
I'll
reduce
it
from
what
I
originally
wanted
to
talk
about
down
to
a
little
bit
of
a
smaller
scope.
A
This
has
kind
of
come
up
before
multiple
times
over
the
course
of
a
couple
years:
Flynn
and
I.
If
you're
not
familiar
with
Flynn,
he's
more
active
in
the
gamma
side
of
things
and
works
on
Linker
d,
I
have
been
talking
about
a
potential
need
for
being
able
to
differentiate
routing
traffic
over
the
front
end
or
back
end
of
a
back
end
draft.
A
So
to
put
more
find
a
point
on
that
at
Kong,
our
Ingress
controller
currently
has
the
ability
to
say
use
service
or
just
directly
use
the
back
ends
the
endpoints
in
the
upstream
or
as
the
upstreams.
That's
a
Kong
lingo,
but
basically
as
the
upstreams
for
the
for
the
routing
and
let
the
Ingress
controller
deal
with
how
it
is
routed
versus
the
service
type
load.
Balancer.
A
There
is
a
similar,
so
we
do
that
today
with
Gateway
API
actually,
but
we
do
it
with
an
annotation
which
is
a
little
blah,
the
service
mesh
group
and
if
Morris
Mike
Morris
is
on
here.
That
would
be
great,
but
I
don't
know
if
he
is
now
I,
don't
think
he's
anybody
else
that
wants
to
pop
out
on
it.
Maybe
John
would
may
need
something
like
this
too,
particularly
when
attaching
English
controllers
to
it,
something
that
I've
been
discussing
with
fun.
A
I
That
was
more
like
what
is
the
interaction
between
master
and
Gateway,
which
I
think
is
a
different
question
than
should
we
send
to
the
front
end
or
back
end
like
there's
no
real
reason
to
send
to
the
service
front
end
other
than
for
working
around
an
issue
right.
So
my
I
think
so
my
general
impression
is
like
we're
tapping
this
at
kind
of
the
wrong
layer.
That
may
be
one
way
that
we
implement
it,
but
we
should
kind
of
start
with
the
user
behavior
that
we
want
unless
there's
none.
I
A
I
can
I
can
catch
up
with
that
one,
but
that's
good
feedback
I
mean
my
what
I
was
looking
for
was
kind
of
like
does
this
make
sense?
Anybody
else
is
something
that
you
might
want
to
do
it
maybe
be
just
service
mesh.
So
yeah
I'll
take
a
look
at
that
doc.
Then
I'll
catch
up
with
you
or
Flynn
or
Mike
Morris,
and
get
a
hold
of
that
and
take
a
look.
Okay.
I
B
A
A
A
Yeah
I
mean
that's
what
I
was
going
to
say
to
John
too,
but
I
also
know
that
it's
like
I,
can't
think
of
exactly
the
reason.
You
would
do
that
right
off
the
top
of
my
head.
It's
a
that
one's
a
little
bit
kind
of
like
okay.
What's
the
reason
that
you
do
that,
which
I
think
is
a
fair
question
with
alternate
implementations
of
service,
I
could
potentially
see
there
being
something
but
again
I.
Don't
have
anything
off
the
top
of
my
head.
I
A
G
A
A
I
A
We
are
at
time
I'm,
I
I
was
trying
to
pull
back
on
a
little
bit
because,
like
I
said,
I
didn't
want
to
get
too
deep
in
the
weeds,
but
what
I
will
do
is
follow
up
on
that
dock
then,
because
that
seems
like
the
next
logical
place
for
me
to
go,
see
that
there's
an
active
conversation
about
this
that
I
didn't
even
know
about.
So
thank
you.