►
From YouTube: Gateway API GAMMA Bi-Weekly Meeting for 20220726
Description
Gateway API GAMMA Bi-Weekly Meeting for 20220726
A
One
there
we
go
hello,
everybody
welcome
to
the
first
Gateway
API
gamma
meeting.
This
is
a
very
exciting
thing
to
be
able
to
spend
some
time
talking
about
talking
about
Gateway
API
for
service
mesh
use
cases-
and
you
know
I've
seen
lots
of
conversation
happen
out
in
the
community
about
this
topic,
and
so
through.
Some
conversations
with
the
API
leads.
A
A
There
we
go
all
right
appreciate
that,
so
we're
gonna
actually
hop
right
into
our
agenda.
I've
prepared
a
slide
deck
that
I'm
just
gonna
kind
of
go
through
real
informally
here
to
talk
at
a
high
level
about
what
gamma
is
what
we
can
interactively
talk
about
goals
and
things
like
that
and
then
I'll
turn
it
over
to
to
John
to
talk
about
the
exploration
document
and
we'll
hop
in
there.
A
A
The
leads
of
this
initiative
are
John
Howard
of
Google
myself
from
Microsoft
and
Mike
Morris
from
hashicorp
our
meeting
times
alternate
between
3
P.M
and
8,
AM,
PST,
so
now
and
then
8
A.M
Pacific
time.
So
next
time
we
meet
next
week,
it'll
be
at
8
A.M
Pacific
time,
and
the
reason
for
this
is
to
at
least
in
the
beginning
attempt
to
be
as
time
zone
inclusive
as
possible.
A
Lots
of
folks
that
you
know
are
in
the
mass
space
who've
expressed
interests
are
in
you
know
the
EU
and
others
in
the
more
asia-pacific
area.
So
I'm
gonna
try
this
for
a
while
and
kind
of
see
how
the
community
responds
and
if
you've
got
feedback.
Please
feel
free
to.
Let
folks
know
oh
and
I
forgot
to
mention
this.
We
will
be
using
the
you
know.
A
A
A
We
want
you
to
develop
a
model
for
describing
service
mesh
configuration
using
data
API,
and
we
want
to
do
so,
while
maintaining
and
possibly
modifying
conformance
with
the
Upstream
spec
may
I
say
maintaining,
because
we
want
to
make
sure
that
we
don't
fundamentally
break
or
change
any
of
the
underlying
assumptions
of
the
Gateway
API
spec.
But
that
may
mean,
because
we're
dealing
with
different
use
cases,
that
might
mean
we
have
to
change
slightly
some
of
the
ways
we
think
about
conformance
down
the
line.
A
Second
kind
of
top
level
goal.
Is
you
want
to
use,
set
model
to
plug
any
perceived
holes
and
get
free
spec
when
it
comes
to
mesh
use
cases?
That
again,
it
may
mean
slight
change
it
to
the
apis
creation
of
new
apis
things
like
that
and
then
kind
of
a
tertiary
concern.
Where
applicable.
We
want
to
develop
reference
apis
for
common
service,
mesh
utilities,
authorization
policy-
it
would
be
for
me
personally.
A
These
that's
really
kind
of
a
nice
to
have
I'd,
be
really
satisfied
with
with
getting
these
these
first
two,
but
you
know,
depending
on
the
community
and
the
need
and
such
the
United
States
and
apis,
especially
around
the
API
policy,
attachment
part
of
the
spec
any
questions
or
comments
about
any
of
this.
So
far,.
A
A
A
Last
when
I
wrote
this,
there
are
five
options:
I'm,
not
completely
sure,
if
that's
still
the
case
with
the
current
refactor
but
I'm
sure
John
talked
about
that
as
you
go
through
the
doc.
Some
things
to
keep
in
mind
when
evaluating
these
options
in
general
is
underlying
cohesiveness,
with
the
spec
various
edge
cases
like
Auto
cluster
services
like
VMS.
That's
a
primary
concern
for
a
lot
of
meshes
and
as
well
as
multicluster
services,
so
John
do
I,
see
a
hand.
Okay,
yeah.
C
I
took
it
away,
but
I'll
just
say
no
actually
one
thing
I
was
going
to
say
is
also
remember
that
we're
not
trying
to
solve
everything
right
now
is
a
big.
It's
a
big
area.
It's
meeting
number
one
we
can
get
to
stuff
in
the
future,
but
for
now
we're
really
trying
to
iron
out
some
of
the
kind
of
groundwork,
and
we
also
even
within
that
we
don't
necessarily
need
to
solve
anything
or
everything.
Rather,
you
know
we
can
have
areas
that
are
implementation
specific.
C
We
can
have
areas
that
are
left
to.
You
know
vendor
specific
apis.
You
know
we
want
to
reduce
that
as
we,
because
we
move
on
I
think.
But
you
know
we
have
to
make
some
progress
now
and
then
we
can
kind
of
start
buying
things
later.
I
just
do
I
want
to
avoid
we're
like
having
a
boil
the
whole
ocean
to
make
any
progress
here.
A
A
Think
scope
is
very
important.
As
John
said,
we
don't
want
to
pull
the
whole
ocean,
so
I
took
a
stab
at
kind
of
initial
set
of
of
scoping
constraints,
and
you
know
if
you,
if
your
use
case
is
presented
here,
that's
I
think
a
really
good
use
case
to
either
make
a
comment
on
the
doc
create
a
GitHub
issue
or
a
comment
on
when
issue
is
created
and
things
like
that.
So
starting
off,
we
want
to
support.
A
Sure
all
right,
so,
let's
start
scoping
wanna,
you
know
make
sure
we
know
what
kind
of
back
then
you're,
supporting
and
by
back-ends
I
mean
anything
that's
kind
of
Downstream
from
from
a
route,
so
cluster
IP,
Services
kind
of
big
ones.
The
the
you
know
the
the
base
case,
if
you
were
Hitler
Services
have
a
for
mesh
just
because
it
serves
a
service,
there's
a
typically
more
more
interaction
there,
and
so
we
want
to
consider.
You
know
for
a
first
task,
that's
something
we
want
to.
A
A
To
what
degree
do
you
want
to
support
TCP
routes,
TLS
routes,
UDP
routes
for
a
lot
of
implementations,
you're
going
to
be
limited
by
your
proxy,
and
so
you
know
figuring
out
to
what
degree
and
kind
of
in
what
order
of
importance
do
you
want
to
tackle
some
of
these
X
routes?
The
types
of
routes
that
exist
in
the
spec
additionally
often
Z-
that's
another,
pretty
big
mesh
use
case
so
service
authorization
policy
as
well
as
identity
via
authentication,
JWT
kinds
of
things.
A
To
what
degree
do
we
want
to
support
that
based
on
use
cases
and
then
a
big
one
that
I
think
has
the
potential
to
be
be
very
powerful
is
a
gateway
integration.
So
when
it
comes
to
multi-network
East-West
gateways,
just
a
very
common
thing
in
service
mesh,
World,
egress
gateways,
possibly
modeling
the
sidecar
as
a
Gateway,
and
how
does
that
within
the
Gateway
API?
How
does
that
communication
happen?
A
D
Yeah,
so
thanks
thanks,
Keith
I
think
that's
a
really
awesome.
Intro
well
done
the
I
think
the
the
thing
that
I
that
I
think
that
maybe
is
not
obvious
and
Rob.
Who
can
probably
back
me
up
here
that
for
the
actual
for
the
sort
of
the
Gateway
API
itself,
one
of
the
things
that
we
spend
a
lot
of
time
doing
in
the
very
early
parts
of
the
of
the
project
was
getting
everybody
to
agree
on
what
we're
actually
doing
right.
D
Like
you
know,
I
know
that
sounds
like
a
stupid
thing
to
spend
a
lot
of
time
on,
but
it's
actually
a
lot
harder
than
you
would
think,
because
a
lot
of
the
time
when
you
talk
about
this
stuff,
people
have
ideas
that
use
the
same
words
or
sound
like
they're
the
same
thing,
but
when
you
get
down
to
it,
there's
some
subtle
difference.
It
comes
out
really
important
and
you
don't
find
that
until
you
actually
start
building
things.
So
what
I
wanted
to
encourage?
D
Reading
all
the
comments
on
the
on
the
on
the
dock
and
and
sort
of
looking
at
this
initial
scope,
I
would
say
I
would
basically
what
I
wanted
to
say
was
to
put
a
strong
caution
in
to
say:
hey,
be
careful
not
to
dive
too
closely
into
the
implementation,
spend
some
time
to
get
the
like
for
everybody
to
make
sure
everyone's
on
the
same
page
about
like
what
are
the
concepts
that
you're
talking
about
here.
Don't
worry
too
much
about
like
what
exists
in
the
current
API.
It's
all
changeable
anyway,
right,
like
the
import.
E
Definitely
a
big
part
of
that
is
also
figuring
out,
like
we've,
had
discussions
between
a
few
mesh
implementations,
but
we
definitely
want
to
get
on
the
same
page
in
terms
of
like
constraints
or
assumptions
that
other
measures
may
have
things
like
transparent
proxy.
The
ways
in
which
upstreams
or
permissions
are
defined
or
not
so
that
kind
of
stuff
is
definitely
going
to
be
an
important
part,
so
kind
of
like
building
this
sharing
context,
to
figure
out
like
what's
the
set
of
common
goals
and
non-goals
to
pursue.
As
part
of
this.
D
Yeah,
absolutely
but
again
again,
even
I
I
think
even
before
you
generate
the
goals
and
non-goals
you've
got
to
be
sure.
You're
all
talking
about
the
same
thing
right,
like
that's
the
yeah
and
and
service
mesh
means
a
lot
of
things
to
a
lot
of
people.
Right
like,
and
you
know,
I
mean
I
spent
a
long
time
when,
when
we
first
started,
building
Contour
I
like
having
to
tell
people
just
because
we
use
Envoy
doesn't
mean
we're
a
service
mesh
right,
like
you
know
so
on.
D
Not
how
I
expected
that
to
work
right,
which
says,
which
is
a
signal
to
me
that,
like
as
someone
who's
like
knows
the
Gateway
stuff
and
is
passing,
has
a
passing
knowledge
of
service
mesh
stuff
like
yeah,
that
that
was
sort
of
a
bit
of
a
red
flag
for
me.
That
that,
like
there's
something
missing
in
in
this
in
the
discussion
somewhere.
A
A
How
do
we
think
about
traffic
flowing
through
a
mesh
now,
like
I,
said
I?
Think
some
of
that
started
to
appear
in
that
dock,
but
it
might
be
worth
spending
some
more
time
doing
that,
just
for
the
sake
of
finishing
this
and
I'll
turn
it
over
to
John
for
our
next
janana,
but
I'll
be
thinking
about
that
neck
in
the
back
of
my
head
for
a
bit,
how
can
I
help
so
with
something
new
like
this
I've
gotten,
several
requests
to
me
personally?
A
A
If
there's
more
context,
then
please
add
suggestions
and
things
there,
but
eventually
you
know
that
I
think
the
doc
remind
the
way
I
envisioned
it
is
that
the
doc's
going
to
be
the
kind
of
springboard
for
GitHub
issues
and
discussions
that
will
that
would
be
migrated
over
and
then
tell
your
friends
I
mentioned
at
the
beginning
of
the
call
that
we've
got
APAC
and
emea
friendly
time
zones.
We
love
for
as
many
people
as
possible
to
be
able
to
attend
to
be
a
part
of
this
all
right.
John.
C
Yeah
I
think
that
makes
sense.
It
may
help
to
just
go
directly
to
the
design
part
at
the
top.
I
had
a
bunch
of
info
about
my
interpretation
of
other
mesh's.
You
know
apis
and
things
how
things
work,
but
I'm,
not
an
expert
on
all
of
them,
so
I
can
probably
do
the
appendix
I
was
more
researched,
but
fundamentally
what
I
try
to
break
this
down
to
is
you
know
we.
C
To
solve,
but
initially
what
I
wanted
to
solve
was
two
things.
The
first
was
kind
of
how
we
solve
mesh
representation.
So
in
the
Gateway
in
Gross
world
we
have
Gateway
classes,
which
kind
of
say
this
is
some
implementation
that
exists
in
my
cluster
and
it's
accessible
and
then
a
Gateway
actually
goes
and
Provisions,
like
the
actual
instance
of
that,
we
need
some
sort
of
similar
thing
for
mesh
so
that
we
can
attach
things
and
say
this
applies
to
the
mesh
or
that
I
have
these.
C
You
know
these
matches
installed
on
my
cluster
potentially
anyhow.
All
this
you
know
is
really
up
in
the
air
and
if
we
scroll
down
the
other
concept,
is
what
I'm
calling
service
binding
so
for
Ingress
use
cases.
We
we
kind
of
Define
matching
through
a
combination
of
routes
and
listener
right,
so
routes
have
all
this
explicit
matching
config,
but
they
work
on
the
intersection
of
The
Listener,
which
includes
matching
things
like
port
and
hostname
for
HTTP
and
Sni
for
TLs.
But
what
we
can't
do
is
represent.
C
Some
like
I
want
to
match:
TCP
requests
to
the
Food
Service.
You
know
if
you're
an
Ingress
Gateway,
you
don't
you
can't
know.
The
request
is
to
the
food
service,
because
the
request
went
to
your
proxy
right.
You
don't
have
that
original
destination
intended
target
information
that
we
do
have
in
the
batch.
So
we
have
these
kind
of
different
constraints
and
requirements
on
on
mesh
routing,
and
this
is
really
the
most
common
case.
I
think
we
want
to
apply
traffic
rules
to
specific
services.
So
we
want
to
say
something
like.
C
G
Yeah
I
think
before
we
started
to
put
how
to
represent
meshes.
We
need
to
answer
the
question
about.
Is
it
a
mesh
or
there
are
multiple
meshes,
and
if
there
are
two
meshes,
does
it
mean
that
they
are
completely
separate,
or
does
it
mean
that
it's
just
to
implementation
talking
together?
That's
because
after
we
answer
this
question,
a
lot
of
stuff
will
flow
and
will
be
much
easier.
C
Yeah,
that's
a
that's
a
good,
that's
a
good
point.
So
one
thing
I've
been
trying
to
avoid
in
this
is
focusing
on
anything
other
than
a
routing.
So
you
know:
can
they
talk
to
each
other
would
probably
be
something
like
do
they
speak
with
the
same
certificate
or
even
use
mtls
or
some
other
mechanism
right
right
or
do
they
have?
You
know
firewalls
blocking
them.
C
G
Security
is
if
security
is
part
of
the
mesh,
then
two
ports
talking
with
each
other
is
critical,
and
that's
where
you
know
if
we
agree
that
there
is
a
single
mesh,
a
single
implementation
per
cluster,
some
things
become
simpler
and
others
become
more
complicated.
But
if
we,
if
we,
if
we
assume
that
there
are
multiple
measures,
then
we
need
to
take
into
account
this,
how
they
cross
communicate
with
each
other.
So
it
cannot
be.
You
know,
just
ignored
as
a
problem
that
one
is
using
a
certificate.
C
C
A
C
D
D
The
thing
around
which
the
whole
API
spins
but
I
think
that
it's
really
important
to
to
that.
We
don't
I
think
that
the
the
kubernetes
object
Service
is
heavily
overloaded
with
a
bunch
of
meanings
already
and
like.
We
need
to
be
really
careful
about
adding
layering
more
on
top,
so
I
think
yeah,
one
of
the
things
that
I
wasn't
sure.
C
Yeah
I
definitely
agree
so
when
I'm
saying
like
service
and
here
and
I
tried
to
be
consistent
with
I
should
probably
not
just
capitalization
but
like
coding,
code
font
or
something
about
service
versus
capital.
S
Service,
so
I
I
try
to
represent
this
as
more
generic
service,
so
the
kubernetes
service
is
a
service,
but
so
as
a
service
import
or
you
know
my
mesh
service
type
that
some
custom
type
or
you
know
GCS
bucket.
D
D
H
Yeah
hi
I
have
a
comment
about
the
mesh
class
who
is
responsible
for
creating
that
customer
resource.
I
assume
this
is
not
something
a
user
would
be
doing.
It's
probably
set
up
one
time
at
the
initial
creation
of
the
mesh,
maybe
installation-
and
is
this
like
a
one
kubernetes
one
per
kubernetes
cluster
or
are
we
envision?
This
could
be
multiple
namespaces.
Well,
if
user
choose
to
set
up
multiple
meshes
in
the
cluster
like
10,
zillion
or
SEO,
you
know
coexist
or
console
when
they
choose
to
implement
this.
C
A
D
D
I
think
that
the
thing
that
another
thing
that
I
was
trying
to
say
earlier
is
that
there's
a
there's,
a
definite
sort
of
if
you're
talking
about
binding
things
to
the
service
resource,
the
kubernetes
service
resource.
There's
a
conceptual
Shear
here
between
an
impedance
mismatch,
maybe
between
between
the
assumptions
we
make
in
the
the
mango
API.
And
what
we're
talking
about
here
but
like
in
the
main
game.
Api
a
service
is
a
place
that
you
route
stuff
to
it
is
the.
D
Routes
service,
like
it's
a
leaf
node
right
at
the
very
end,
I'm
making
it
be
like
not
a
leaf
node
in
a
graph.
That's
sort
of
a
thing
that's
pretty
similar,
like
is
a
big
sort
of
there's
a
there's,
a
big
conceptual
difference
between
that
and
that's
what
I
meant
by
getting
everybody
on
the
same
page,
conceptually
so
I
think
like
that's
why
in
general
I'm
in
favor
of
some
of
the
stuff,
you
talk
about
later
about
having
like
a
separate
thing
that
the
you
know,
the
the
like.
The
the.
D
What
we're
talking
about
with
nature
is
a
different
enough
use
case
to
what
we're
talking
about
with
the
Gateway
that,
like
the
the
constructs,
are
similar
but
not
the
same
and
so
like
for
things
that
are
similar,
but
not
the
same.
Having
them
have
the
same
name
or
use
the
same
resource
like
is
a
path
to
things
being
really
confusing.
D
D
A
B
E
I
think
I
agree
with
the
idea
of
not
binding
things
directly
to
services,
and
earlier
I
was
hearing
something
that
I
think
sounded
a
lot
to
me,
like
the
idea
that
some
of
the
meshes
are
using
the
service
as
the
thing
that
they
are
making
routing
decisions
based
on
which
feels
like
layer
skew
to
me.
So
I
wanted
to
see
if
I
really
understood
that
correctly
Howard
I
think
you
were
the
one
who
were
saying
that.
Did
you
mean
that
you
know
a
DNS
hostname?
Did
you
mean
a
name
of
a
service?
E
I
Yeah
I
mean
the
hopefully
people
can
hear
me.
I
mean
service
is
two
things
in
kubernetes,
not
just
one
right,
one,
it's
an
addressable
name
and
the
other
is
it's
a
bag
of
endpoints,
most
of
the
time
on
the
consumer
side,
when
people
think
about
policies
right,
like
I'm,
talking
to
named
thing
a
DNS
host
name,
which
is
what
service
mostly
Provisions
I'm
in
that
and
a
bit
right.
They
want
policies
that
apply
to
that
conversation
that
they
have
and
that's
the
like.
You
know,
there's
only
a
few
things.
I
I
I
In
the
topical
case,
so
that's
why
usually
right?
That's
roughly
what
we
mean
when
we
talk
about
attachment
right.
It's
attachment
policy
attachment
to
the
thing
being
talked
to
right
and
mostly
by
the
person
who
owns
the
thing
being
talked
to
right.
That's
certainly
the
most
common
case
and
and
so
therefore
in
kubernetes,
the
thing
that's
most
commonly
talked
to
is
service
right.
I
These
kubernetes
has
made
that
the
thing
that
people
talk
to
like
staple
sets
aside
and
some
other
stuff,
but
that's
the
most
common,
and
so
that's
the
mental
model
that
users
generally
have
is
I.
I
want
policy
on
inbound
into
the
thing
that
I
own
and
is
being
talked
to,
or
between
a
tuple
set
right
between
the
consumer
and
producer
group.
I
And
so
then
the
question
becomes
how
to
represent
that
in
an
API
form
without
introducing
too
much
abstraction
right.
So
we
don't
lose
immediacy
right
because
otherwise,
right
things
get
really
quite
confusing
right.
So
there's
this
right
and
Nick,
you
refer
to
the
Gateway
API
right,
where
the
state
service
is
the
leaf
of
the
the
reference
graph
right,
because
it's
both
a
bag
event
endpoints
and
also
because
it's
the
names
thing
that's
being
referenced
in
that
form
right.
So
this
naming
agreement
I,
don't
think,
there's
necessarily
any
well.
I
So
some
of
the
models
that
John
discussed
right
describe
policy
attachment
by
reference
to
service
right,
I,
think
John.
Is
that
a
fair
way
to
describe
it?
In
that
case,
the
service
is
still
the
leaf
of
the
graph
right,
but
the
consumer
may
be
anything
or
the
consumer
may
be
just
one
thing
right
and
the
most
common
case.
It's
anything
right,
because
the
policy
was
written
by
the
person
who
also
owned
the
service,
but
the
service
is
still
released
with
the
graph,
at
least
in
traffic
routing
cases.
I
I
D
D
D
D
A
super
smash
Telemetry,
you
know
like
security
and
stuff
like
that
flow
from
the
fact
that
the
service
has
an
identity
that
you
can
then
use
to
to
Anchor
those
things
so
yeah,
I,
I,
completely
agree,
I,
think
that
that's
and
that's
exactly
the
sort
of
conversation,
I
kind
of
wanted
to
hear
like
that
that
you
know
like
that.
What's
the
you
know,
the
service
has.
H
D
Identity
and
and
the
the
key
part
that
you
want
to
add
like
routing
and
and
sort
of
other
policy.
Information,
too,
is
the
identity
and
the
exact
resource
you
use
for
the
identity
is
probably
not
as
important
as
the
fact
that
you
wanna
like
take
actions
based
on
that
identity
and
so
I
think
the
the
I
guess.
F
D
Us
have
this
discussion
and
knows
that
at
least
in
some
of
what
people
are
talking
about
when
we,
when
we
say
service
and
we
say,
bind
into
a
service
I
think
what
you've
described
with
the
owner
of
the
service.
Wanting
to
wanting
to
do
things
like
that
sounds
a
lot
like
what
we
ended
up
building
with
reference
Grant.
D
E
A
F
Interpretation
of
current
Gateway
API
in
my
use
case.
So
in
my
use
case
you
know,
I
do
have
two
different
version.
You
know
of
a
kubernetes
service
version,
one
version
two
or
four
I
can
use
as
a
service
owner
full
service.
I
can
Define
HTTP
route
so
when
I
can
Define
the
path
which
can
point
to
my
back
end,
kubernetes
Services
I
think
it's
in
line
with
what
Nick
is
talking
about.
F
I
just
want
to
point
out
that
one
of
the
my
interpretation,
what
is
the
meaning
of
the
HTTP
route
and
my
backend
service
and
and
another
interpretation
of
my
interpretation
of
mesh?
What
I
mean
match
in
my
case
it
is
a
gateway,
and
then
you
can
call
Gateway
or
mesh
I
mean
is
mesh,
is
a
collection
of
these
HTTP
routes
as
a
kubernetes
cluster?
If
I
associate
to
a
mesh
or
I,
you
know,
I
say
I
want
to
use
this
mesh
means.
I
can
discover
you
know.
I
can
have
full
service
bar
service.
E
I
Oh
yes,
that's
kind
of
an
interesting
inherent
question
in
in
what
was
just
discussed
right,
there's
a
mesh
and
and
who
gets
to
use
it
if
I'm,
an
owner
of
a
service
right
and
I,
attach
policies
to
my
service
I
do
not
want
those
policies
bypassed
right.
So
whether
or
not
a
consumer
is
enrolled
in
the
mesh
is
somewhat
irrelevant
to
me
right,
I,
don't
want
you
to
be
able
to
get
access
to
my
service
without
abiding
by
those
policies
right
so
there's
this
kind
of
uniformity
requirement
in
in
the
mesh
right.
I
I
I
A
I
A
That
was
me,
I
was
just
gonna,
say,
I,
completely
agree
and
I
think
that
the
it's
hint
out
in
the
dark
and
I
think
we've
already
talked
about
a
bit,
but
it's
going
to
be
important,
I
think
to
just
the
mechanisms
that
are
available
to
uphold
that
policy.
So
in
that
particular
example
of
as
a
producer
of
a
service,
the
consumers
can't
simply
opt
out
of
that
one
mechanism
of
doing
that
is
via
something
like
mtls,
but
to
what
degree
should
that
be
represented
in
the
Gateway
API
yeah?
A
C
C
C
You
know
or
like
retries
or
can
airing
or
things
like
that
it
seems
like
a
useful
property,
but
one
that
may
not
necessarily
be
feasible
for
many
implementations
to
implement
and
so
I
wonder
you
know
for
all
these
things,
we'll
need
to
draw
a
line
on
what
is
recommended
versus
required
for
the
spec
and
I.
Do
worry
about
some
things
that
maybe
generally
better
from
a
user
perspective
but
may
kind
of
block
out
some
of
the
implementations
so
that
it
wasn't
really
anything
concrete
other
than
that.
I
I!
Think!
That's
not
quite
the
case,
I
think
it's
a
little
bit
different
right.
I
I
as
an
individual
within
a
a
large
Network,
don't
get
to
make
the
rule
choices
on
behalf
of
others,
so
I'm,
not
choosing
that
you
know
which
of
their
rules
I
get
opt
into,
I
may
get
to
choose
which
of
mine,
but
I
don't
get
to
choose
anybody
else's
and
that
will
have
an
effect
on
what
API
composition
look
like,
regardless,
whether
it's
a
hard
security
boundary
or
not,
which
is
I,
agree
a
more
tricky
thing.
G
G
I,
don't
think
it's
it's
so
tricky
I
mean
I.
Think
from
a
user
perspective,
you
have
an
rbox
security
or
you
have
a
routing,
because
your
application
requires
service
food
to
be
routed
to
Borrowed,
whatever
your
application
breaks,
if
someone
is
not
obeying
so
so
it's
it's.
It's
true
that
two
mesh
implementation
may
not
be
able
to
play
together
and
but
in
order
for
two
meshes
to
be
in
the
same
clusters,
they
need
to
to
to.
A
A
B
B
D
A
A
I
think
I'd
love
to
see
one
two,
two
of
them
you
know
as
with
steam,
I
love
for
it
to
be
one
and
it'd,
be
very,
very
easy,
but
realistically
I'd
love
to
to
try
to
see.
If
we
can't
find
the
you
know,
those
unworkable
solutions
for
one
reason
or
another,
get
consensus
around
that
and
start
to
kind
of
coalesce
around
one
or
two
options.
I
think
that'll
make
further
iteration
a
lot
more
Focus.
If
there's,
if
there's
less
options
to
choose,
Trump
go
ahead,
John.
C
C
You
know
what
they
may
look
like
in
terms
of
API
I.
Think
the
the
finer
points
of
the
API.
You
know
the
exact
names
of
fields
and
shape
et
cetera,
that
we
can
all
hammer
out
in
you
know
in
the
future.
But
what
would
be
really
useful
is
if
there's
things
in
here
that
you
know
you
as
a
mesh,
implementer
or
user,
are
looking
at
like
they're,
absolutely
crazy
and
would
never
work
in
your
case.
You
know
that
could
be
very
helpful.
Obviously,
people
writing.
C
C
You
know
we're
trying
to
make
this
work
for
all
the
implementations
that
are
out
there.
How
much
you
know
what
that
would
look
like
is
to
be
determined,
but
it's
at
least
useful
to
know.
If
we're
doing
things
that
aren't,
you
know
very
compatible
with
some
architectures
at
the
very
least
that
we're
explicitly
we're
aware
that
we're
doing
that
right.
B
We
don't
know
exactly
what's
going
to
belong
in
each
of
these,
we
know
what
this
thing
this
blob
is
going
to
represent
and
we'll
figure
out
the
configuration
inside
it
a
little
bit
later.
But
we
want
to
agree
on
these.
Are
the
fundamental
building
blocks
of
this
concept
and
I
feel,
like
that's,
probably
the
most
important
stage
and
I?
You
know
at
a
minimum
what
I
think
we'd
hope
to
have
in
Say
by
kubecon
or
something
like
that?
That
kind
of
understanding
but
yeah
I'll
pass
it
off
to
Lynn.
H
Yeah,
thank
you
Rob,
sorry,
so
you're
trying
to
get
all
volume
I
would
also
like
us
to
kind
of
settle
down
on
the
initial
scope.
Kids,
you
presented
the
initial
scope
and,
let's
discuss
I,
feel
like
there
hasn't
been
much
discussion
about
the
initial
scope
and
then
we
kind
of
jump
into
the
design
because
I
know
in
istio
a
lot
of
time.
We
were,
you
know,
jump
into
the
design
and
then
we
constant
question.
As
you
know,
what
is
the
scope?
What
are
the
scenarios
that
we
want
to
solve?
H
D
C
D
To
me,
like
there's
a
pretty
tight,
there's,
a
very
tight
feedback
loop
between
those
two
things
that
the
the
scope
requires:
the
the
initial
sort
of
building
blocks,
but
the
initial
building
blocks
require
the
scope
as
well
right,
so
you've
got
to
do
them
both
at
once.
I
100
agree
that
you
can't.
You
can't
have
useful
discussions
without
about
the
building
blocks,
without
having
a
very
clear
idea
of
the
scope.
H
Yeah
and
I'm
hoping
I'm
hoping
we
would
have
a
Saturday
on
the
scope
and
then
we
can
decide
the
building
blocks
so
sort
out.
The
implementation
is
the
kind
of
a
reflex
of
the
scope
right,
just
didn't
want
like
the
implementation
or
the
design
of
the
API,
actually
impact
our
scope.
If
you're
a
green
Nick,
yeah.
D
D
Or
something
like
that,
and
that's
what
I
mean
by
there's
a
really
tight
Loop
between
those
two
things.
So
it's
really
important
to
have
everybody
write
down
like
what
are
the
things
you
expect
out
of
a
service
mesh?
That's
a
rough
idea
of
what
your
scope
is,
and
then
you
use
those
things
to
generate
like
what
are
the
concepts
that
that
you
know
like
make
up
a
service
mesh
and
that
helps
you
sort
of
bucket
those
scope.
Items
features
slash
scope,
items
in
scope,
items
into
like
what
the
concepts
are,
but
this
is
a
like.
D
I
said
this:
is
this
sort
of
very
early
stage
thing
is
very
nebulous
and
very
tricky,
and
you
have
to
spend
a
lot
of
fun
doing
what
we're
doing
right
now
talking
in
a
meeting
about
it,
you
can't
do
it
it's
very
difficult
to
do
this
I
think
the
async
is
like
a
way
that
you
can
sort
of
generate
questions
to
then
discuss
in
a
meeting
is
what
I
and
that's
what
I
have
found
in
the
Gateway
API.
That's
how
we
that's
how
we
worked
best
I.
Think.
A
A
One
of
the
things,
at
least
in
my
mind,
is
as
a
goal
here
was
to
make
sure
that
the
exploration
duct
was
accessible
to
folks
to
be
able
to,
you
know,
get
their
minds
around.
Some
of
the
thought.
That's
already
happened,
but
we
also
and
have
these
conversations
and
talking
about
scope,
we've
kind
of
shaken
out
really
good,
solid,
first
principles,
which
we
need
to
around
service
identity.
A
What
we
think
about
the
Flies
to
make
sure
everybody's
talking
about
the
same
terms
so
I'll
actually
take
that
as
an
action
item
and
I'll
go
back
and
share
on
the
agenda
kind
of
where
that
discussion
lives,
not
I,
think
Google
Docs,
probably
the
right
place
to
start
possibly
a
separate
one,
because
this
expiration
Doc
is
already
32
pages
long,
but
I
will
be
sharing
with
the
community
as
I
work
on
it
and
hopefully
get
that
out
soon.
So
everybody
can
add
their
thoughts,
got
30
seconds.
A
I,
really
appreciate
everybody,
everybody
coming
out
and
and
in
this
meeting
as
a
reminder,
our
next
meeting
will
be
at
8
A.M,
Pacific
time
on
next
Tuesday
And.
For
those
of
you
who
won't
be
able
to
make
it.
These
should
be
uploaded
to
the
same
Gateway,
API,
YouTube
playlist
so
be
sure
to
check
those
out
Mike
or
John
any
last
second
thing
before
we
call
the
meeting.