►
From YouTube: Gateway API GAMMA Bi-Weekly Meeting for 20220815
Description
Gateway API GAMMA Bi-Weekly Meeting for 20220815
A
A
And
yeah
I'm
sharing
the
open
agenda,
which
should
be
in
the
media,
invite
and
accessible
to
everybody
here.
So,
as
always,
it's
an
open
agenda.
So
for
something
you
want
to
discuss,
please
feel
free
to
add
the
agenda.
It
should
be
documents
and
it's
editable
by
everyone
all
right
so
and
feel
free
to
add
yourself
under
attendees,
so
we
can
keep
track
of
who
showed
up
all
right
starting
off
keith.
You
had
two
announcements
about
upcoming
sharing
progress.
B
B
C
B
B
I
mean
there's
a
lot
more
discussion
needed,
especially
around
egress
gateway
that
came
up
in
the
gateway
api
meeting
yesterday.
There's
there's
a
lot
of
complexity
as
far
as
the
semantics
around
that,
and
so
we're
deferring
that
for
future
conversation
and
we've
also
got
a
set
of
use
cases
as
well
in
the
and
the
gap
to
help
guide,
to
help
folks
see
the
problem
space,
and
I
put
a
note
there
like
we're
not
necessarily
committing
to
every
single
one
of
those
use
cases
in
this.
B
In
the
sprint,
it's
more
of
an
exercise
in
helping
folks
to
empathize,
with
the
with
the
eventual
end
user,
end
users
and
personas
that
are
going
to
be
using
using
this.
So
take
a
look
at
that
feel
free
to
add
comments
and
review
the
pr
I
think
by
around,
if
there
aren't
any
outstanding
issues
by
around
thursday
or
so
I'll,
be
looking
to
other
gateway.
Api
maintainers
slash
leads
to
get
this
merged
in.
A
Cool
thanks
sounds
good
yeah.
This
looks
like
a
great
place
to
start,
and
definitely
I
think
everybody
involved,
like
maybe
read
through
some
of
the
use
cases,
think
about
how
those
might
apply
to
your
specific
mesh
implementation
and,
if
there's
anything,
obvious
missing,
there
feel
free
to
try
to
add
it
so
that
we
can
kind
of
align
on
common
scope.
D
How
many
people
will
be
at
kubecon
in
a
seems
like
you
know,
a
lot
of
us
are
going
to
be
there
so
yeah.
We
should
probably
get
together
and
do
something.
I
don't
know
if
it
needs
to
be
something
formal
or
if
we
just
want
to
try
to
toss
something
on
the
calendar
to
get
together
and
have
a
drink
or
two
but
yeah
that
seems
like
it
seems
like
there
will
be
enough
of
us
there
that
it
might
be
worthwhile.
B
C
Yeah,
so
I've
been
talking
with
bob
killen
and
jason
from
I
don't
know
I
guess
kubernetes
community,
but
they
they
have
been
trying
to
find
some
community
spaces.
The
easiest
day
for
them
to
find
community
spaces
is
on
tuesday
of
the
conference,
which
falls
between
the
contributor
summit,
which
most,
if
not
all,
of
us,
are
welcome
to
if
you're,
if
you're
a
kubernetes
or
recruiter
and
a
sig
org
member
you're
more
than
welcome
at
the
contributor
summit.
C
I
think
many
of
us
will
be
there
and
if
you're
not,
we
can
help
you
get
to
that
membership.
So
that's
on
monday
and
then
tuesday
is
an
open
day
for
many
of
us.
I
know
it.
It
unfortunately
overlaps
with
service
mesh
con,
which
will
be
for
many
of
the
people
on
this
call
something
like
that
they're
attending,
but
it
is
a
day
that
we
can
get
space
somewhere
in
the
venue
specific
for
gateway,
api.
D
C
I
think
that's
probably
the
winning
option
right
now,
so
they
don't
have
specific
times
for
us
yet.
But
what
they've
said
so
far
is
early
next
week
we
should
have
a
better
idea,
so
I'll
try
and
send
an
update
out
as
far
as
what
our
options
are
and
yeah.
Hopefully
we
can
all
get
together.
It'd
be
great
to
meet
many
of
you
for
the
first
time
in
person.
A
A
D
B
B
D
B
All
right
so
no
problem
all
right,
so
this
is
the
rendered
version
of
the
gap
and
just
as
as
an
overview
as
an
overview
for
what
we're
trying
to
kind
of
accomplish
gateway.
Api
represents
the
next
generation
of
traffic,
routing
apis
and
kubernetes,
and
while
most
of
the
current
apis
focus
on
the
ingress
use
case,
we
want
to
try
to
support
turbo
implementations
with
the
spec.
B
The
community
would
benefit
from
that,
and
so
this
gap
is
kind
of
a
genesis
for
developing
common
patterns
using
gateway
api
for
east
fest
traffic
within
their
mesh
implementation,
and
I
feel
like
it's
important
to
call
out
here
that
this
gap
does
it
purposefully,
doesn't
promise
new
resources.
It
doesn't
promise
new
implementations
or
anything
like
that.
We
are
simply
looking
for
patterns
and
if
new
resources
are
necessary,
then
we'll
add
new
resources.
B
There
are
kind
of
six
top
level
goals
that
I
think
are,
and
please
stop
me
with
questions
or
if
I'm
rambling,
but
there
it
seems
that
there
are
six
kind
of
top-level
goals
that
kind
of
have
come
out
of
our
early
discussions.
We
want
to
augment
the
gateway
api
with
the
necessary
keyword
necessary
there,
models,
resources
and
modifications
so
that
the
extra
primitives
are
usable
by
the
search,
implementations,
the
x
route
being
http
route,
tcp
route,
tls
route,
etc.
B
You
want
to
make
sure
that
gateway
api,
ingress
implementations
can
coexist
and
interoperate
with
mesh
implementations.
There's
no
interoperability
there's
a
breaking
change
there.
Then
you
know.
Why
are
we
doing
any
of
this?
So
I
felt
like
that
was
important.
As
top
level
goal.
We
want
to
remain
agnostic
at
the
topology
of
mesh
implementations
data
planes.
We
don't
want
to.
You,
know
pitch
and
hold
anybody
into.
You
know
this
only
works
for
side
cars,
those
only
work
for
non-side
cars;
it
should
be
topology
agnostic.
B
We
want
to
enable
mesh
implementations
to
have
vendor-specific
extensions
for
their
own
policies,
etc,
that
are
in
line
with
the
existing
extensibility
offered
by
gateway
api.
That's
a
fancy
way
of
saying
that
policy
attachments.
Should
you
know
implementation
should
be
able
to
use
policy
attachment
to
add
their
own
policies.
We
shouldn't
they
shouldn't
be
locked
into
any
such
resources
that
are
provided
by
gateway,
api,
gamma,
etc.
B
You
want
to
cooperate
with
the
greater
gateway
api
community
on
shared
patterns
and
policies
that
are
applicable
for
both
use
cases,
authorization
policy
right.
If
there's
authorization
policy
resource,
it's
likely
that
users
would
want
to
use
that
same
resource
or
pattern
for
both
the
ingress
and
the
service
mesh
use
case,
and
so
we
possibly
want
to
strive
to
to
make
to
cooperate
so
that
that
can
be
a
reality.
E
B
E
That's
good
enough.
I
mean
we
need
to
agree.
I
mean
I,
I
it's
very
hard
to
make
progress
and
design
something
when
you
don't
know
what
that
something
is,
and
I
know
we
each
have
a
different
idea
about
what
the
mesh
is.
I
mean
the
security
part
of
the
remesh.
I
don't
know
we
don't
agree.
It's
communication,
okay,
if
that's
the
minimum
that
we
agree
on,
let's
state
it
so
so
we
we
we
have
a
base.
I
hope.
E
A
D
A
D
B
So
we
what
so
it
sounds
like
traffic
routing
is
definite
like
within
the
scope.
It's
part
of
the
scope
of
mesh
as
we're
considering
mesh.
The
in
automatic
encryption
is
yeah,
I'm
kind
of
with
cost
in
here.
I
don't
know
if
I,
if
I
make
say
that
it's
a
it's
a
non-goal,
but
I
feel
like
it's.
It's
explicitly
an
implementation
detail
that
may
vary
yeah.
D
D
B
B
I'm
fine
with
that,
but
I'm
also
very
conscious
of
we
don't
want
to
exclude
meshes
that
may
that
meant
either
may
not
be
there
yet
or
they
be
on
something
else
for
that
implementation
and
that
we
don't
put
too
much
into
the
definition
of
mesh,
because
some,
like,
I
think,
of
something
like
chaos
mesh,
I'm
I'm
not
extremely
familiar
with
it,
but
the
goal
seems
a
bit
different
for
that
mesh.
Should
they
be
able
to
use,
get
the
api,
I
would
helps.
B
I
would
hope
so
so,
just
I
I'm
in
favor
I'll
make
those
changes.
If
someone
wouldn't
mind
adding
a
pr
comment,
just
to
make
sure
I
can
recall
what
we're
wanting
to
do
here,
a
pr
comment
or
a
a
note
in
the
agenda
doc
just
want
to
be
cautious.
Moving
forward
about
overloading
the
definition
of
mesh
too
too
much.
A
D
I
really
would
like
to
catch
a
capture
at
some
point
in
here
that
you
know
it
should
be
possible
for
somebody
who
is
a
cluster
provider
to
automatically
spin
up
a
mesh
for
somebody
using
the
cluster.
I
think
it's
important
to
also
clarify
that
it
still
needs
to
be
possible
for
somebody
who's
just
using
the
cluster
to
do
it
all
without
the
help
of
a
cluster
provider.
And
again
I
don't
know
where
a
good
place
to
put
that
is.
A
A
D
B
Yeah,
where
is
this
fear
of
influence
for
this
person?
What
kind
of
resources
yeah
that
makes
sense
yeah?
So
I
I
I
wonder
so
my
my
initial
thought
process
when
I,
when
I
hear
you
know
that
I
a
cluster
user,
can
install
a
mesh
without
a
cluster
operator,
maybe
I'm
just
assuming
too
much,
but
I
feel
like
that's
more.
B
B
B
D
It
may
just
be
a
matter
of
clarifying
you
know
clarifying
the
role
some
more.
It
may
also
be
a
compliance
point
where
it
would
be
really
nice
to
be
able
to
have
a
gamma
mesh
be
compliant
with
gamma,
without
requiring
it
to
fulfill
everything
for
or
compliant
in
some
fashion,
without
requiring
that
it
fully
implement
all
the
cluster
provider
infrastructure
stuff,
that's
something
that
we
ran
into
there's
some
friction
with
gateway
api
as
well,
but
that
yeah
that's
kind
of
why
it's
on
my
mind.
D
So
when
I
got
started
with
kubernetes,
it
was
in
a
company
that
consisted
of
four
people,
and
there
was
nobody
that
I
could
you
know
it
was
not
an
option
to
be
able
to
sit
down
and
go.
Oh
I'll
talk
to
the
company's
cluster
administrator
about
this
it.
It
was
just
me
or
you
know,
one
of
the
other
guys
who
was
busy
working
with
other
stuff.
D
It
would
be
a
beautiful
world
to
be
able
to
just
you
know:
fire
up
k3d
with
the
dash
dash
mesh
equals
whatever
option,
but
even
in
that
world
it's
going
to
be
important
as
an
app
developer
or
somebody
wearing
a
multiple
hats,
particularly
in
a
smaller
organization,
to
be
able
to
say
things
like
well,
okay,
this
mesh
isn't
quite
supported
by
gamma
yet,
but
I
want
to
play
with
it
or
you
know.
I
need
an
easy
way
to
go
and
try
the
alpha
version
of
the
mesh.
That
is
supported.
F
Yeah,
I
was
going
to
say
it
seems
like
we
may
be
scope
grouping
quite
a
bit.
You
know,
there's
that's
just
a
gigantic
field.
That's
why
we
all
have
jobs.
We
can't
solve
everything
and
kind
of
creates
some
new
standardized
way
to
solve
everything.
I
really
think
that
we
should
focus
on
the
core
stuff
and
things
like
deployment.
Maybe
we
tackle
that,
but
that's
also
the
hardest
thing.
That's
something
that
even
for
ingress
has
not
been
tackled
like.
How
do
you
actually
deploy?
F
Yeah,
I
think
the
deferred
goal
list
should
probably
be
like
a
page
long.
The
goals
should
probably
be
like
two
two
or
three
points.
Just
that
we
keep
ourselves
focused.
It's
really
easy
to
say.
Like
yeah,
I
mean
you
look
at
you
know
mesh
docs,
like
there's,
you
know
100
pages
of
stuff,
there's
tons
of
stuff.
We
can
do
and
we
should
do
it
at
some
point.
Maybe,
but
if
we
try
and
do
all
that
it'll
be
really
hard.
D
E
One
one
thing
that
should
be
a
goal,
probably
in
this
on
this
topic,
is
that
admin
should
be
able
to.
You
know
override
prevent
users
from
messing
up
and
and
this
kind
of
stuff.
So
while
you
know
each
individual
creating
its
own
mesh
and
deploying
it's
a
mesh,
maybe
a
deferred
goal
having
a
strong
control
probably
is
included
in
the
namespace
isolation,
or
I
don't
know
if
we
have
it
explicit
or
we
want
to
have
it
explicit.
E
B
Okay,
I
was
going
to
say
the
same
thing
like
I
think.
I'd
probably
prefer
for
that
to
live
like
within,
like
implicitly
with
boundary
and
the
controls
kurini
provides
around
our
back,
like
the
those
have
kind
of
served
the
community
well
for
for
years.
At
this
point-
and
our
permissions
is
a
is
a
non-trivial
problem,
and
so
I
let
I
like
to
let
kubernetes
solve
that
for
us
wherever
possible,
so
that's
kind
of
where
I
feel
and
why
I've
got
that
explicit
goal
of
namespace
boundaries.
B
A
B
Okay,
so
like
heterogeneous
heterogeneous
deployment
models
in
general,
yep,
not
just
multi-cluster,
so,
okay
so
close
to
my
birth
being
separate,
but
okay,
yeah
I'll
I'll,
add
those
to
the
to
the
to
the
gap
and
those
are
really
good.
I
appreciate
everybody's
feedback.
There,
john
you
mentioned
scope
creep.
Was
there
anything
in
the
existing
goals
that
you
felt
was
was
scope
creeper?
You
were
talking
about
the
current
the
competition
at
that
time,.
F
I
think
the
current
one
seemed
good,
but
I
have
also
lost
the
pages,
so
okay
yeah,
I
would
just
say,
like
I
think,
that's
good,
although
I
would
say
that
we
shouldn't
necessarily
try
and
tackle
everything
in
parallel,
like
the
top
stuff
is
probably
more
important
than
the
bottom
stuff.
Well,
the
well,
I
guess
it's
kind
of
unordered,
but
you
know
we
don't
need
to
solve
every
goal
at
the
same
time,
even
if
they're
not
deferred
goals
right,
they
could
be
this
month
and.
C
F
E
Maybe
maybe
some
mention
of
iterative,
development
or
releases,
so
basically,
no,
let's
agree
on
how
to
bind
routes
to
services
or
whatever
it's
called,
and
you
know
kind
of
do
small
steps.
So
we
don't
block
on
having
all
the
first
goals,
but
once
we
reach
a
goal,
we
can
have
implementations,
try
it
out
ship
it
whatever.
A
Sure
so
this
is
only
where
I
don't
think
that
we
necessarily
need
to
like
all
work
on
the
same
goal.
At
the
same
time,
I'd
love.
If
rob,
you
have
a
little
bit
to
share
about
kind
of
like
what
you've
seen
work
well
in
gateway
api
for
north
south,
but
like
one
of
the
things
that
has
seemed
to
help
there
is
having
like
one
or
two
people
like
take
the
lead,
as
like
owners
of
a
thing
and
try
to
like
work
on
driving
consensus
and
driving
like
initial,
like
gap.
A
C
Yeah
I
I
completely
agree
with
that.
I
would
be
careful
to
split
things
out
as
small
as
possible
within
reason.
We
certainly
still
have
things
to
learn
with
us
during
gateway
api,
but
that's
one
thing
that
has
helped
is:
if
you
can
get
people
who
are
really
wanting
to
drive
a
specific
area,
it
may
seem
small,
but
nothing
is
really
that
small.
When
you're,
trying
to
build
consensus
across
a
group
like
this
so
yeah.
E
So
that
sorry,
that
is
an
important
question.
Are
we
shipping
an
api
without
implementations
or
are
we
you
know
basically
agreeing
on
something,
have
wait
for
a
couple
of
vendors
to
implement
it
and
and
then
we
ship
it
when
it
has
an
implementation?
What
few
implementations
I
don't
know
what
what's
the
flow
we
want
for
for
kubernetes?
It
had
at
least
two
implementations
when
it's
shipped
I'll
be
very
predestined.
To
have
you
know,
kind
of
apis
or
definitions
of
protocols.
B
Yeah,
so
I'm
also
interested
in
hearing
from
gateway
maintainers
and
how
that
experience
was
in
the
early
days
when
you're
trying
to
develop
a
specification.
I
know
for
smi
when
we
were
doing
doing
stuff.
You
know
we
had
not.
We
didn't
really
have
implementations
and
that
and
that
may
have
been
a
you
know,
one
of
the
areas
of
improvement
for
that
process.
F
F
We
could
merge
it
as
experimental
and
then
have
implementations
pick
it
up
and
then
you
know
all
is
good.
We
move
on
it's
hard
to
have
you
know
kind
of
a
chicken
and
egg
problem,
so
at
least
from
our
side
on
istio
we
have
an
experiment,
have
meshed
with
gateway.
It's
not
what
will
be
the
end
result,
so
I
think
we
can
at
least
iterate
quickly.
I
don't
know
if
others
are
in
the
position.
F
C
I
think
that's
a
good
point.
We
didn't
have
experimental
back
in
the
day
I
mean
everything
was
experimental,
we're
in
a
slightly
different
place
now,
so
we
need
to
recognize
that
I
I
would
highlight
a
couple
things.
One.
As
john
mentioned,
we
can
release
to
experimental
there's
the
understanding
that
something
like
an
experimental
can
include
breaking
changes
at
any
point
with
that
said,
it
seems
like
it.
It
could
be
helpful
when
evaluating
a
gap
when
evaluating
a
host
of
proposals.
C
If
someone
had
a
work
in
progress,
unreleased
implementation
of
it,
that
said,
hey
yeah
this
this
actually
is
feasible.
This
is
something
that
can
work,
definitely
not
something
that
should
you
know,
take
a
lot
of
time,
but
just
if
more
than
one
implementation
can
say.
Yes,
this
would
work
for
us.
I
think
that
that
helps
a
lot,
but
we
have
the
experimental
channel
for
a
reason.
E
E
Usually
the
purpose
of
you
know
of
this
group
is
to
agree
between
at
least
two
vendors
or
three
vendors,
or
so
to
create
agreements
across
vendors.
If
you,
as
john
said,
you
know,
we
can
move
probably
very
fast
and
implement
whatever,
but
and
create
experiments
reflecting
our
apis
and
I'm
sure
other
vendors
can
do
the
same
thing.
The
goal
is
to
you
know,
create
this
agreement
and
have
at
least
two
different
vendors
agree
on
something
instead
of
each
vendor
pushing
their
own
api
into
into
experimental
and
then
trying
to
push
them.
E
C
C
We
we
can
adjust
those
requirements,
but
I
think
that's
really
what
you're
talking
about
costed
of?
We
need
more
than
one
implementation
to
have
implemented
something
before
we
get
it
to
beta,
and
I
think
most
of
the
resources
we're
talking
about
modifying
here
are
beta
resources,
so
something
would
start
an
experimental
and
then
to
get
to
standard.
It
needs
to
meet
all
the
beta
graduation
criteria.
B
D
D
E
But
but
but
it's
something
that
it
should
be
raised.
Actually
you
know
I
know
each
vendor
has
its
own
implementation
in
progress.
It
would
be
also
hard
to
coordinate
in
when
we
promote,
I
mean
to
have
someone
have
all
everyone
have
at
least
some
basic
implementation,
so
we
don't
kind
of
compete
too
much
in
you
know,
speed
to
market
all
those
things.
That's
a
you
know,
internal
agreement
or
something.
B
Okay,
so
if
there's
nothing
else,
they
want
to
briefly
just
go
over
these
non
goals.
Hopefully
nothing
contra
too
controversial
here,
but
obviously
I
think
one
of
the
nongoals
of
this
effort
is
to
represent
every
service
mesh
feature
within
gateway
api.
Like
john
mentions,
if
you
look
at
mesh
documentation,
they
are
pages
long
and
you
know
uploading
the
gateway
api
is
definitely
not
one
of
the
things
that
we
want
to
to
result.
Out
of
this.
B
I
also
one
of
the
other
non
goals.
Is
you
don't
want
to
duplicate
concerns
for
the
sake
of
mesh
specific
resources?
So,
if
exists
something
within
game
api,
that
does
we
want
the
x
route.
Family
resources
are
a
good
example.
Those
exist.
We
don't
want
to
duplicate
that
just
to
create
mesh
copies
of
everything
and
then
thirdly,
kind
of
the
it's
if
it's
the
converse
or
the
inverse,
but
the
kind
of
antithesis
of
that
is.
B
We
don't
want
to
overload
existing
gateway
api
mechanism
mechanisms
when
a
new
mechanism
is
more
appropriate,
and
so
those
kind
of
I
feel
book
in
the
extremes
of
where
to
go
about
doing
this,
and
hopefully
the
end
result
of
that
is.
We
are
asking
ourselves
these
questions.
Does
it
make
sense
to
to
split
these
resources
either
for
user
experience,
user
understanding
or
technical
difference
and
then
also
doesn't
mean
use
the
source
here
so
that
we
don't
create,
so
we
don't
create
bloat
in
the
spec
relatively
short.
B
All
right,
thankfully,
that
was
was
short
as
far
as
open
questions.
These
are
kind
of
like
deferred
goals,
but
I
didn't
necessarily
like
the
idea
of
having
them
as
as
goals
that
should
be
indented
a
bit.
But
there's
only
really
one
question
here:
around
should
creating
a
set
of
policy
attachments
for
like
what
we
might
consider
table
sex
functionality
for
a
mesh
like
authorization
policy
should
should
that
be
a
goal,
and
I'm
not
sure
about
that.
B
Yet
I
think
yes,
it
would
be
nice
for
there
to
be.
You
know
one
resource
that
makes
sense
across
multiple
implementations
but
kind
of
a
lot.
If
we
have
that
if
we
say
yes
to
that
question
that
we
should,
we
have
to
have
a
conversation
about
what's
the
process
and
what's
the
logic
for
which
features
should
have
kind
of
a
community
supported
implementation
and
which
ones
are
left
up
to
the
vendor.
I
don't
feel
personally,
I
don't
think
we're
in
the
place
to
have
a
conversation
yet,
but
I
could
be
wrong.
B
D
A
So
this
is
called
a
little
bit
in
the
main
gateway
api
discussions
before
and
I
believe
I
think
it's
documented,
but
it
was
basically
proposed
to
like
start
with
implementation,
specific
policy
attachments
using
a
like
vendor,
prefix
key
and
basically
a
pattern
of
like
if
they're.
If
we
end
up
finding
enough
similarity,
there
then
move
to
standardize
rather
than
trying
to
standardize
at
the
outset,.
B
B
That,
okay,
so
I'll,
want
to
take
away.
My
takeaway
then,
for
that,
for
the
sake
of
this,
is
I'm
going
to
move
that
as
to
the
non-goal
section,
hopefully
with
the
link
to
where
that
workflow
of
implementation
first
and
then
standardize
link
to
that
in
the
and
that
non-go
section
and
if
it's
not,
if
there's
no
link
to
explicitly
like
spell
that
out,
so
that
it's
set
up
that
it's
clear.
B
B
Okay,
well,
that's
basically
the
gap
there's
like
I
said
some,
some
use
cases
here
and
a
glossary
of
terms.
Oh
and
I
remember
the
other
action
item.
We
wanted
to
clarify
the
service
mesh
scope
as
far
as
traffic
routing
and
that's
not
in
the
engine
box
or
a
pr
comment.
I
will
either
or
somebody
could
add
it.
I
really
appreciate
it
to
make
sure
I
can
address
that.
But
yeah
that's
the
gap.
D
D
E
I
mean
I
create
some,
it
should
be
good,
but
it
will
differ,
but
that
raises
the
operation
that
you
you
mentioned.
Do
you
want
to
put
in
the
different
sections?
Something
about
you
know
what
kind
of
metrics
or
whatever
we
can
agree
on
so
to
have
consistent
operations.
So
someone
who's,
creating
a
mesh
kind
of
doesn't
have
to
learn
to
operate
a
different
one
or
I
don't
know
it's.
D
B
B
We'll
see
if
that
continues,
yeah
metrics
was
mentioned,
and
that's
an
interesting
problem
space.
One
thing
that
justin
just
mentioned
that
one
thing
smi
didn't
have
when
we
started
trying
to
to
do.
This
was
open
telemetry
and
I
think
open
telemetry
starts
to
make
some
start
to
make.
That
picture
a
little
bit
clearer
about
what
a
possible
standard
for
implementation.
B
Metrics
looks
like
when
comparing
like
what
costume
is
describing
on
the
operational
side
of
metrics
for
mesh
migration
or
mesh
upgrades
or
uninstallation
so
yeah,
just
for
just
a
fun
call
out.
If
anybody,
if
that
happens,
to
be
of
interest
to
anybody,
I
would
love
for
seminary
to
to
spend
some
time
in
that
area
and
come
teach
me
about
what
a
possible
metrics
standard
might
look
like.
A
All
right:
well,
I
think
that
about
wraps
it
up.
It
doesn't
look
like
we
have
anything
else
on
the
agenda
today.
So
just
wanted
to
thank
everybody
for
coming.
Good
conversation
got
another
chance
to
walk
through
some
of
the
step,
and
hopefully
it
sounds
like
we're
pretty
close
to
aligning
on
some
of
the
goals
here
and
hopefully
we
can
move
to
get
this
merged
shortly.