►
From YouTube: Envoy Community Meeting - 2019-06-07
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
So
welcome
everybody
to
the
first
inaugural
meeting
of
universal
data
playing
API
working
group,
I
think
hopefully
everyone's
here,
because
they've
read
the
Charter
that
was
put
together
a
few
expect
by
man,
myself
and
perhaps
maybe
even
read
the
blog
post
by
that
medium,
which
was
describing
roughly.
What's
you
know
they
are
the
goals
of
the
universe
of
data
playing
API
are
so
hopefully
we
don't
need
to
do
too
much
to
some
levels
and
expectations
there,
but
I
think
we're
great
is
if
we
can
just
go
around
and
then
just
like
introduce
ourselves.
A
A
Can
we
come
up
with
a
common
configuration
language
starting
with
the
existing
envoy
api's,
and
make
this
work
for
a
whole
variety
of
other
products
and
build
up
an
ecosystem
which
can
interoperate
together
and
provide
a
lot
of
value
as
a
result?
So
that's
me
maybe
we
could
go
across
left
to
right
in
the
grade
as
I
see
it's
in
that.
B
C
D
I
do
that
you
can
see
my
lips
moving.
You
can't
see
get
your
anything
right,
so
I'm,
vas
laughter,
check,
I'm
I'm
at
Microsoft
and
again,
I
guess
a
lot
of
the
same
reasons
that
Harvey
mentioned
already,
but
we
did
day
I
think
we
kind
of
tackled
this
the
control
plane
universal
API
pretty
recently.
That
was
a
joint
effort
which,
which
seemed
to
have
some
some
pre
interesting
uptake.
So
it's
interesting
to
see
how
this
will
play
out
for
the
data
plane
as
well.
J
L
AssadÃs
hi
I'm,
representing
ns1
today
we're
in
our
native
DNS
provider,
I
think
our
main
interest
here
is
kind
of
just
figuring
out
how
to
have
some
tighter
integrations
with
some
of
this
stuff
as
it
moves
forward.
We
have
a
lot
of
this,
like
data
generally
and
I,
think
you
know
kind
of
reading
to
that
blog
person.
All
that
seems
like
DNS
was
one
way
to
do
it
and
we're
seeing
if
there's.
A
N
Angelico
we
can,
we
can
say
that
is
in
Jellico,
director
of
engineering
at
AG,
proxy
and
I
work
with
really
and
with
API.
So
from
my
standpoint,
if
we
can
integrate
teacher
proxy
with
with
emerging
trends
and
help
help
improve
the
general
state
of
API
is
being
used
for
proxies,
that's
primarily
that's
my
primary
goal.
Also
Eric.
Oh.
O
E
E
D
Bryan
sillens
I'm
from
AWS
software
engineer
here.
My
main
focus
right
now
is
on
in
the
u.s.
at
mesh,
but
I'm
also
here
sort
of
representing
AWS
in
general,
because
there's
a
lot
of
interest
in
both
envoy
and
XDS
within
AWS
and
within
Amazon
as
a
whole.
My
real
hopes
right
now
are
one
to
learn
about.
What's
coming
about
how
you're
thinking
about
the
API
design,
hopefully
I
can
contribute
there
as
well,
but
also
to
perhaps
represent
the
needs
of
some
of
the
other
teams
within
AWS
or
Amazon.
P
A
A
So
the
next
thing
that
I
thought
it
would
be
a
good
use
point
to
mention.
Kick
things
off
is
like
in
terms
of
upcoming
activity
around
the
API
is
probably
the
biggest
changes,
we're
gonna
see
in
the
next
few
months,
and
so
the
opportunity
for
this
working
group
should
be
effective.
It
will
be.
Is
this
stable,
API
versioning
proposal
which
I
link
to
the
github
issue
there
and
proposed
plan
of
record
for
actually
making
that
manifests
in
the
Envoy
code
base?
Today
we
just
a
brief
history.
A
You
know
we
started
off
with
the
Envoy
view
on
api's,
which
were
provided
on
well
with
things
like
service
discovery
and
then
incrementally
additional
features
like
router
configuration,
lookup
and
things
like
listener
discovery,
and
we,
whether
about
two
years
ago,
in
our
project,
we
form
a
set
of
relevant
coherency.
Our
pc-based
api's,
which
also
addressed
variants,
which
were
the
core.
A
We
called
the
v2
XDS
API
they've,
essentially
become
the
standard
across
all
the
homeboy
ecosystem,
built
on
top
of
bi-directional
streaming,
G,
RPC
and
point
above
as
they're,
sort
of
called
defining
characteristics
and
there's
been
actually
huge.
Amounts
of
work
and
trim
in
these
API
is
over
time,
and
some
of
the
aspects
of
these
api's
are
truly
in
those
rings.
Some
of
them
are
very
specific
to
Envoy
and
rickles
point
now,
where
we're
actually
having
at
least
our
first,
you
know
real
additional
client.
A
There
are
many
FCS
servers
out
there,
but
there's
been
really
being
one
XTS
client
for
the
longest
time.
That
was
all
boy
and
that's
G,
RPC
lb
and
that's
putting
an
onboarding
these
protocols
and
we're
well
working
with
this
team.
We
actually
realize
that
you
know.
There's
a
number
of
things
that
we
need
to
do
to
make
these
API
its
usable
by
folks
beyond
oh
boy,
and
these
include
things
like,
for
example,
China
at
the
design
level.
A
We
had
our
own
sort
of
communal
understanding,
of
how
a
compatibility
was
supposed
to
work,
so
we're
trying
to
adjust
these
things
and
get
them
together
or
other
people
and
sort
of
try
and
improve
things.
It's
yes,
we
have
a
usual
design
document
describing
how
we're
planning
on
sort
of
stabilizing
the
Envoy
API
is
actually
moving
from
beyond.
A
There's
a
monolithic
notion
of
v2
to
a
family
of
API
is
essentially
which
would
be
versioned
independently
and
a
long
major
versions
and
where
we
will
be
working
on
essentially
a
v3
and
things
like
v2
and
v3
will
be
mutable
api's,
which
will
only
grow
in
non
breaking
waves,
and
this
is
essentially
what
we're
working
on
right
now.
It's
basically
a
combination
of
actual
API
design,
but
it's
also
a
lot
of
tooling
to
make
this
feasible
on
the
Envoy
side.
And
it's
also
things
like
features.
A
It
start
v3l
for
essentially
for
any
API,
which
we
want
to
start
reorganizing
and
we
want
to,
by
the
end
of
the
q3
finalized
v3
and
actually
cut
that
as
the
sort
of
the
next
version
for
whichever
API
needs
to
actually
be
bombs,
and
probably
a
lot
of
api's
will
be
bumping.
Cos
are
a
bit
of
technical
down
in
the
api's
because
we
didn't
want
to
break
folks
historically,
and
this
is
actually
really
great
opportunity.
Alongside
that,
there's
actually
started
to
that's
now
being
a
bifurcation
at
the
top
level.
A
The
API
is
in
the
package
namespace
from
Aomori
dots,
XYZ
to
onward
and
NYC,
and
also
Beauty
P,
a
dot
X
Y
Z,
and
we
are
hoping
that
we
can
try
and
you
just
use
package
namespaces
to
start
drawing
a
clear
distinction
between
parts
of
the
API
which
can
be.
You
know
to
truly
reusable
by
anyone
and
ones
which
are
very
own
voice
specific.
Now
this.
H
A
Won't
happen
just
over
the
course
of
v3
or
even
v4,
but
we
overtime
we're
into
this
direction.
Move
towards
this
package
organization
and
the
end
state
is
ideally
just
the
ombré.
Namespace
only
has
things
which
are
specific
to
envoy
and
potentially
there
would
be
other
proxy
trees
there.
For
example,
if
H
a
proxy
would
need
to
have
some
very
H,
a
proxy
specific
things
they
could
live
in
such
a
tree.
A
B
What
one
thing
that
we
should
talk
about
doesn't
have
to
be
now
is
you
know
we
had?
Obviously
we
used
to
have
all
the
api's
in
the
data
plane,
API
repo,
yes,
I,
do
wonder
if,
especially
for
the
UDP
a
portion
of
the
tree,
if
we
should
plan
on
actually
moving
that
back
out
into
a
into
a
separate
repo,
it
would
more
in
the
spirit
of
sharing.
B
So
it's
something
that
we
don't
have
to
decide
today,
but
I
think
that
we
should
talk
about
that
and
I
think,
given
that
the
rate
of
change
in
the
UDP,
a
API
should
be
slower,
we're
actually
gonna
have
to
figure
out
a
bunch
of
stuff
around
envoy
documentation,
because
all
of
the
Envoy
documentation
effectively
has
to
be
stripped
from
those
from
those
api's
and
and
put
somewhere
else.
So
it's
you
know
it's
probably
worth
just
just
putting
down
an
action,
thought
item
of
the
actual
storage
and
structure
of
which
github
repos.
J
K
J
B
I
mean
that's,
that's
actually
what
we
used
to
do,
but
you
know
it
had
made,
at
least
on
the
Envoy
side
of
things,
our
development
and
velocity
slower,
because
we
had
people
doing
PRS,
back-and-forth
I.
You
know
I
think
that
now
we
are
at
a
different
level
of
maturity,
so
I
think
I.
Think
now
is
the
time
that
we
probably
need
to
think
about
moving
back
yeah.
N
A
B
Yeah
and
I
think
that
many
projects
will
probably
me
that
so
and
that
might
be
something
where
again,
these
are
just
things
that
we
can
think
about.
But
I
could
imagine
that
you
know
the
existing
proto
dock
tool.
Maybe
it
would
have
some
way
of
taking
a
set
of
generic
proto's
and
then
projects
can
specify
additional
documentation
that
gets
effectively
merged
in
somehow.
Yes,
some
sort
of
thing
yeah.
A
B
A
Okay,
excellent
so
yeah,
so
I
links
to
the
part
of
record,
so
we
I've
also
sort
of
this,
never
saw
our
technical
things
in
there,
which
I
think
are
interesting
to
this
group
here,
and
that
is.
We
want
to
actually
like
real
soon
now
like
within
the
next
week,
start
to
lock
down
at
almost
API
is
a
bit
better.
A
You
know
different
parts
like
you,
so
many
uses
ahead
of
map
here,
use
the
same.
You
know
gary
attempt
as
ahead
of
map
there,
this
and
there's
another
group
that
I've
created
a
quote
on
the
proc
security
pawg,
which
hopefully
anyone
here
who
wants
to
submit
their
getup
ID
to
me,
can
be
a
part
of
and
we're
trying
to
ensure
this
is.
This
group
is
targeted
on
all
API
related
with
yours.
A
So
there's,
though,
they'll
be,
you
know,
manager
sign-off
from
API
Shepherds,
but
everyone
will
get
to
actually
see
all
of
these
reviews
and
have
an
opportunity
to
comment.
You
know.
Usually
we
don't
land.
We
review
merchants
instantly,
that's
usually
I
could
day
also
at
least
before,
and
if
you
get
certainly
done
with
them
reviews
envoy,
so
that's
probably
I.
Could
that
the
most
interesting
wrong,
which
is
about
to
happen
immediately
as
well
as
well
as
sort
of
III
alpha
being
cut.
A
So
that's
what
the
opportunity
you
were
for
anyone
who
has
acted,
who
wants
to
suggest
well?
Why
don't
we
make
this
change
the
API
to
make
it
more
Universal?
It
can
be
hugely
structural
change.
If
you
would
like,
we
can
actually
do
that.
I
mean
structures
in
the
bounds
of
the
stole
somewhat
resembling
next,
yes,.
H
A
When
we're
not
interested
in
completely
changing
the
discovery
service
over
and
I
have
the
way
the
X
discovery
service
pros,
work
overnight
or
completely
changing
like
the
notion
of
listeners
and
casters.
But
you
know
there's
sort
of
some
amount
of
flexibility
we
have
there.
For
example,
you
know
if
someone
were
to
point
out,
for
example,
this
is
a
routing
level
concept,
but
in
all
these
other
new
systems,
it's
a
service
level
concept
or
vice
versa.
We
could
potentially
think
a
bit
about
how
we
could
accommodate
these
as
we
move
towards
v3
and
I.
A
Version
of
has
before
we
actually
dive
dive
into
maybe
some
of
the
technical
topics
that
we
would
like
to
get
out
of
address
in
the
working
group
for
hands.
We
should
actually
just
actually
before
we
do
that.
Let's
just
quickly
chat
about
a
meeting,
cadence
and
so
on.
Does
our
monthly
work
for
most
folks?
Oh,
do
you
think
Polly
would
make
sense,
I.
B
J
A
Cool,
so
we
had
a
request
from
I
think
it's
Dave
Cheney
to
not
to
make
these
meetings
on
Friday
because
you
know
he's
in
Australia
in
Sydney
which
it's
not
a
good
time
in
Sydney
it's
a
Saturday
morning,
so
ideally
we'll
push
this
to
somewhere.
Maybe
week
is
doodle
okay
to
try
coordinator
a
comment
I'm
on
with
that,
okay
with
everyone,
I
mean
I.
It's
for
that.
B
What
what
what
is
a
time
that
generally
works
with
the
time
zones
that
that
we
have
like
I,
don't
even
know
what
time
zones
that
so
we
have
someone
in
Australia,
yeah,
China,
China,
Europe,
also,
potentially
or
okay,
I!
Guess
Lisa
is
probably
the
time
zone
expert.
What
what?
What
time
do
you
do?
Meetings
these
on?
Well,.
P
I
confess
my
time
zone,
so
it
will
be
like
around
midnight
in
okay,
that's
a
big
time!
I!
Don't
think
that
work
for
you
start
time
zone
so
probably
sometime
around
now,
it's
good
for
me,
but
I,
don't
think
it's
really
good
for
those
in
Asia.
If
they're
and
I
think
it's
like
4
or
5
a.m.
in
China
now
so.
B
P
A
A
B
B
A
N
A
A
F
So
you
know
I'm,
not
sure
you
know
just
procedurally,
you
know
how
much
detail
we
want
to
get
into
this
here,
but
I
just
wanted
to
sort
of
float
the
idea
I
can
always
you
know
if
it
seems
reasonable
to
people
put
together
a
PR
and
then
we
can.
You
know
we
iterate
it.
You
know
in
there,
but
basically
the
idea
is
right.
Now
the
it's
in
CD
s
I
believe
there's
the
the
CD
s
response
that
comes
back
basically
tells
the
client.
Okay.
F
Here
is
what
intra
closer
look
balancing
policy
I
want
you
to
use
and
right
now
it's
an
enum
and
we've
got
a
lot
of
sort
of
custom
load,
balancing
policies
that
we
want
to
use
in
different
cases,
and
so
an
enum
is
not
really
gonna
cut
it
because
we
can't
expect
you
know
adding
a
new
enum
value
for
every.
You
know
random
custom
case
that
we,
you
know,
may
want
to
use
in
a
particular
deployment,
so
in
particular
in
G
RPC
we
have
a
a
pluggable
LV
policy
API.
F
So
anyone
you
know
any
third
party
can
sort
of
write
their
own
and
plug
it
in.
So
what
what
I'm
proposing
is
that,
basically,
we,
you
know
replace
with
appropriate
backward
compatibility.
Obviously
the
enum
with
a
more
flexible
system
is
like
the
policy
name
is
essentially
feel.
Then
we
can
sort
of
attach
some.
You
know
arbitrary,
like
a
proto,
with
arbitrary
configuration
options
for
that
that
lb
policy
does.
It
seem
reasonable,
yeah.
B
That's
a
that's
a
huge,
huge
plus
one.
For
me,
we
actually
just
did
that
with
the
cluster
objects.
Also,
because
now
we
allow
cluster
extensibility,
so
it
would
be
great
to
actually
move
that
way
and
just
from
the
ombo
perspective,
we
want
to
allow
pluggable
load
balancers
also,
so
if
that
sounds
great,
sumos,
alright
yeah,
and
if
you
actually
just
look
at
the
changes
that
were
done
in
the
last
couple
of
months
to
add
this
capability
to
clusters,
I
think
you
can
mostly
replicate
what
was
down
there.
Ok
sounds.
A
F
Would
be
nice
to
have
it
sooner
it
would
it
would
help
a
lot
of
things
are
and,
and
also
I
mean,
since
this
is
presumably
gonna
be
done
as
an
addition.
It
shouldn't
break
backward
compatibility,
it'll
just
be
a
sprite.
You
know
the
old
field
will
have
to
continue
to
be
populated,
basically
for
older
clients.
J
Yeah
I
think
we
should
take
it
off
the
neck.
It
just
took
that
into
the
void.
Okay,
design
guidance
is
a.
This
kind
of
debate
has
been
happen
many
many
times,
so
the
our
rule
of
thumb
is
that
you
beautify
Nerina.
You
need
to
prepare
that
it
won't
change
more
than
once
a
year.
I
might
have
like
an
EDP
one
activity
to
create
speedy.
J
You
know
that
once
a
year
is
where
the
enum
can
handle
or
pretty
well
anything
more
than
that
you'll
start
with
a
string
and
that
like
I,
so
like
a
country
code
right
which
I'll
have
to
find
a
string,
then
let
us
back
to
explain
what
are
you
to
the
string
and
even
more
aggressive?
Then
you
go
to
the
open-air
CIT
model,
which
is
you
define
a
CR
key
using
a
spring
to
refine
to
arbitration
Rd
in
the
cluster
that
you
don't
have
a
spec
on
the
other
string
I'm
pretty.
J
B
Say
that
that
makes
sense
to
me
just
because
thinking
about
it
now,
I
can
think
of
many
cases
with
the
Envoy
api's,
where
the
use
of
enum
has
caused
issues.
So
I
would
be
fine
with
basically
just
saying
that
unless
we
all
agree
that
this
is
one
of
those
enums,
that's
just
never
gonna
change
that
we
just
block
them.
I.
A
J
A
Yeah
no
I
I
mean
we
based
on
versioning
proposal
roughly
on
what
was
at
the
in
those
best
practices,
but
it
seems
like
we
probably
should
become
familiar
with
all
of
them
and
try
and
collect
as
many
as
possible,
which
are
missing
from
that
dog
cool,
so
yeah.
So
I
think
that
ones
are
not
particularly
controversial
that
the
next
I'm
was
federating
XDS.
So
we
we've
been
to
Google
in
being
able
to
support
our
XTS
in
a
world
of
multiple
management
servers.
A
Each
responsible
for
some
set
of
there
are
resources
such
as
services
and
who
are
authoritative
for
them,
but
peering
together
and
being
able
to
share
configuration
and
distribute
it.
And
this
can
you
address
a
number
of
interesting
sort
of
use.
Cases
such
as
multi
cloud,
on-premise,
hybrid
and
so
on,
and
this
actually
is
going
to
require
a
lot
of
thinking
to
actually
make
work
with
X
Y
s.
A
If
that
is
indeed
the
level
which
we
want
to
federate
out,
but
it's
going
to,
for
example,
question
carefully
about
how
our
resources
are
naming
works
and
how
resources
are
composed
together
and
sort
of
what
our
XDS
discovery
and
protocols.
Look
like
I,
don't
think
that
this
is
certainly
nothing
means
you
to
brakes
on
that,
but
it's
probably
a
good
opportunity
to
raise
that
point
out
that
this
is
something
we're
thinking
about
and
then
hopefully
we
can
address
in
the
context
of
EPA
and
going
forward
it's.
A
C
So
I
guess
there's
kind
of
an
initial
question
for
people
which
is
the
the
you
know.
The
current
envoy,
API
is
and
the
proposal
here
right.
They
discuss
their
discussed
in
terms
of
configuring,
a
proxy
right,
the
the
Federation
use
case.
You
can
kind
of
think
of
it
as
either
having
two
endpoints
configuring,
one
proxy
or
you
can
think
of
one
control
thing
using
this
API
as
input
into
another
control
plan.
There's.
B
Actually,
there's
a
third
case
and
there's
a
proposal
in
the
Envoy
repo
currently
where
people
want
to
allow
envoy
to
consume
config
for
multiple
control
planes
and
then
on
the
envoy
side.
They
actually
want
to
merge
it.
So
like
I,
you
know,
III
think
that
that's
there
are
actually
a
bunch
of
interesting
reasons.
Why
I
think
people
would
want
to
do
that,
but
I
I
think
that
it's
worth
thinking
about
it
from
all
of
these
different
points.
C
So
the
fundamental
difference
between
the
two
use
cases
right
is
when
one
control
plane
is
using
the
information
from
another
control
plane.
What
you
would
expect
it
to
do
is
to
recompose
that
information
into
other
forms
like
filter
things
out,
augment
join
right
generally
performing
compositional
operations
on
that
data
in,
in
addition
to
other
sources
of
data
it
may
have
locally
or
any
different
sources
of
data,
so
one
that
would
do
would
be
to
put
pressure
on
the
API
to
provide
the
right
kinds
of
information
structure
to
allow
composition
to
occur
yep.
C
N
A
One
of
the
things
that
we've
actually
seen
in
the
onward
community
is
that
the
Envoy
API
so
recently
XDS
there's
two
aspects
of
XTS
there's
the
actual
resources
which
exist
today
like
cost
to
a
listener,
and
these
may
you
know,
are
very
much
data,
plane,
specific
objects
and
there's
also
the
transaction
yes,
cowfish
can
be
used
through,
which
can
be
used
to.
You
know,
move
wrong,
especially
one
part
of
important
a
to
point
b
and
allow
some
addressed
some
common
addressing
scheme,
and
this
is
actually
being
used.
A
B
I
mean
there
are,
there's,
probably
not
going
to
be
a
way
to
mandate
that
people
funnel
everything
through
a
single
control,
plane
and
III.
Think
that
you
know
for
the
people
that
are
speaking
about.
You
know
be
better
if
everything
funneled
through
a
single
control
plane
better.
To
put
that
logic,
there
I
actually
agree.
I.
Think
largely
that's
true,
but
I
will
give
you
a
concrete
example
from
lift,
so
lift
has
a
control
plane
for
envoy
or
if
we
do
most
of
our
control,
plane
management.
B
But
let's
say,
for
example,
that
we
want
to
build
a
separate
service
that
either
does
redline
testing
or
does
fault
injection,
or
something
like
that.
Fundamentally,
we
have
two
options.
We
can
build
api's
from
our
primary
control
plane
to
talk
to
another
service.
That
would
then
do
the
merging
there
and
that
might
be
the
right
decision
or
we
can
potentially
allow
the
data
plane
to
talk
to
multiple
control
planes
in
a
very
controlled
situation
and
then
do
the
merging
on
the
Envoy
there.
There
are
pros
and
cons
to
actually
both
both
situations
and
I.
A
B
H
B
A
Great
so
yeah
I
guess
going
forward
so
I'm
putting
a
please
resume.
You
know
your
github
ID.
If
you
have
already
analogy
to
the
UDP
AWG
team
and
you
should
start
seeing
a
stream
of
reviews
tagged
with
dots
which
were
potential.
The
API
changes
I
think
we're
gonna,
actually
in
CinemaScope
of
q2
will
be
taking
one
API
package
with
an
envoy
and
thinking
about
what
v3
alpha
would
look
like
for
that
and
which
bits
are
you
know,
Universal
and
which
bits
are
sort
of
a
very
own
voice
specific.
A
But
beyond
that
we
will
be
doing
most
of
the
work
in
q3
and
so
probably
after
we
next
meet
again
so
I
really
between
now
and
then
yeah,
please
yeah
follow
along
the
progress
that,
if
you're
interested
it
I
the
main.
This
is
a
great
place
to
raise
any
issues
you
have
and
I
think
this
book
is
also
good
place,
attract
future
agenda
items
with
us.
There
anything
else
for
you
to
discuss
today,
yeah.
B
Well,
just
I,
you
know
one
thing
for
folks
on
the
call
who
are
who
are
not
using
envoy
whether
it's
a
cloud
product
or
H,
a
proxy-
and
you
don't
have
to
answer
this
now,
but
I
think
that
the
the
sooner
that
we
can
get
a
concrete
case
of
someone
that
wants
to
use
these
api's.
You
know
that's
not
on
voice
that
already
includes
GRDC,
but
you
know
if
we
could
make
that
include
like
additional
products.
I
think
that
would
help
us
do
this.
Do
this
right.
B
B
D
Actually
going
to
ask
something
similar
along
those
lines,
what
what
would
you
say
for
this
working
group
is
our?
How
much
of
this
is
how
much
of
the
work
we're
doing
is
it
to
to
move
forward?
The
Envoy
api's
first
is
actually
trying
to
come
up
with
a
real
standard
for
the
industry
on
the
data
plain
API,
so
the
notion
of
a
universal
data
API
to
me
says
we're
kind
of
defining
the
common,
the
common
set
of
functionality
that
we
think
would
be
most
useful
to
other
proxies
and
load
balancers
to
standardize
around
and
the.
B
I
guess
I
will
briefly
give
my
thoughts
on
that
and
then
I'm
sure
people
have
different
thoughts,
which
is
I,
I.
Think
what's
interesting
about
this
is
that
we
have
to
at
least
from
the
on
by
project
side.
We
need
to
strike
a
balance
of
you
know.
We
want
to
continue
to
iterate
on
envoy
and
we
want
to
continue
to
move
things
forward.
So
this
is
not
entirely.
B
Let's
stop
everything
and,
let's
you
know,
do
some
some
effort
to
actually
standardize.
At
the
same
time,
we've
seen
interest
from
different
companies
and
different
proxies,
where
you
know.
We
think
that
there's
a
need
for
this
type
of
API,
between
control
planes
and
between
proxy
systems.
So
I
guess
my
view
is
that,
to
the
extent
that
we
have
interest
from
people
like
the
G,
RPC
folks
or
hopefully
others
that
they
want
to
consume,
the
API
is
I.
Think
I
think
we
want
to
be
pragmatic
and
actually
make
that
work.
So
it's
not
like.
B
A
I
mean
I
might
resent
this
vegetable
mat
said
I
mean
I.
Think
incrementally
evolved
the
api's
towards
the
point
where
it
needs
that
second
criteria,
that
have
being
just
the
general
standard,
which
is
not
almost
specific,
is
essentially
where
we
want
to
go.
I.
Think
like
nothing's
off
the
table,
there's
point
in
terms
of
like
that
long-term
direction,
and
we
can
definitely
you
know
if
someone
decides,
for
example.
Well,
this
you
know
this
formal
is
the
way
in
which
listener
obviously
makes
absolutely
no
sense
or
we
should
be
using.
A
You
know
there
are
some
things
which
are
off
the
table,
like
I,
think
we're
going
to
one
of
these
to
be
proto
based,
and
we
want
there
to
be
sort
of
good
junior
pieces
support,
so
I
think
there's
a
future
like
fundamental
sort
of
structural
elements
of
these
api's,
which
probably
are
going
to
be
completely
static.
But
within
that
I
think
we
know
we
have
a
lot
of
scope
to
like
completely
reshape
large
parts
of
it.
A
But
this
will
have
to
be
a
gradual
process
and
we
have
to
be
cognizant
of
the
fact
that
yeah
we
need
to
have
both
more
at
any
point
in
time,
real
parts
per
million,
and
we
also
have
real
customs
in
terms
of
management
service
today
for
those
api's
who
also
are
going
to
really
be
in
a
position
to
make.
You
know
radical
changes
overnight,
that
hey
Mike,
that
that's
my
two
cents
on.
D
The
pragmatic
side,
when
you
mentioned
that
we
would
probably
want
to
split
a
separate
repo
to
host
the
universal
data,
plane,
API
I,
think
I
think
that's
necessary.
I
think
you
kind
of
have
to
start
there,
but
we
can
even
we
can
even
potentially
take
it
further
like
when
Assad
someone
posted
general
kind
of
API
guidelines
to
follow,
so
if
this
would
end
up
being
a
common
set
of
universal
eight
guys.
Perhaps
another
thing
we
could
do
is
also
provide
a
common
set
of
guidelines
for
people
that
are
writing
extensions
onto
the
api's
yeah.
D
A
D
Not
it
so
I,
don't
know
if
it's
it's
non
ously
what
they
would
look
like,
I
think
it's
these
it's
there's
kind
of
a
common
set
of
functionality
that
maybe
pretty
much
you
know,
90
95
percent
of
proxies
have
to
provide
so
does
the
API
cover
that
does
it
cover
too
much
where
you
know
those
90
percent
of
proxies
look
getting
goes
well.
I
don't
have
most
that
functionality.
I
can't
implement
this
entire
thing
as
a
specification
or
is
it
yeah?
This
is
these.
D
Are
the
common
things
I
agree
with
all
these
I
provide
all
this
functionality,
I'm
gonna
use
a
common
I'm,
gonna,
use
kind
of
the
same,
the
same
idea
or
the
same
intense
to
produce
additional
functionality
that
I
want
to
do,
but
it's
gonna
be
in
the
same
vein.
So
if
we
say
XDS
is
kind
of
the
way
that
you
do,
data
play
an
API
that
to
me
makes
sense,
and
everyone
kind
of
follows
a
common
pattern.
D
Then
there's
a
question
of
what
are
the
actual
xdist
API,
specifically
that
we
would
expect
everyone
to
implement
if
they
want
to
be
I,
don't
know
I,
don't
want
to
say
compliant,
but
if
you
want
to
say
yeah
I
implement
the
universal
data
playing
API.
These
are
the
API
is
I
have
to
implement,
and
then
there's
also
kind
of
the
strategy
of
this
is
the
way
that
other
API
should
be
implemented
as
well.
So.
H
D
D
F
A
M
M
I
think
he's
rapidly
on
the
doorway
to
be
able
to
cover
the
current
involves
the
P
I,
just
because
around
it
works
impolite
hit.
We
need
to
cover
it.
It's
tough
to
have
a
Fenian
of
the
something
to
do,
but
we
need
to
the
reasonable
at
some
part
and
probably
decide
to
when
it
has
thought.
Even
if
we,
the
compatibility
at
Stanford,
maybe
we'll
bill
figures
at
certain
cuts,
it
would
be
a
significant
embody
fighter,
because
the
limited
use
only
much
certain
set
of
facts.
A
Okay,
yeah
I
think
like
the
Intel
India
week,
we
will
go
into
this
exercise
with
the
idea
that
we,
probably
we
hasn't
it-
worked
with
her
II.
Don't
have
something
that
works
for
everyone
away
very
open
to
the
possibility
of
changing
just
about
every
anything.
As
long
as
we
have
like
real,
concrete
sort
of
use,
cases
to
motivate-
and
that
would
be
some
I
mean
that's
just
the
omen
community.
The
way
we
work
we
prove
we
prefer
to
use
like
in
a
concrete,
tangible
thing.
A
N
N
N
B
N
For
sure,
we're,
not
fans
of
beautiful
work.
This
right
so
like
from
our
standpoint,
I
think
by
the
end
of
this
month
or
maybe
starts
with
July,
we'll
be
able
to
like,
have
a
clearer
idea
of
what
kind
of
products
or
what
kind
of
ways
we
might
be
using
the
data
playing
api's
in
and
then
that
would
allow
us
to
give
some
actual
concrete
feedback
and
and
suggestions
based
off
of
the
current
state
of
the
api's
super.