►
From YouTube: Envoy Community Meeting 2020-01-09
Description
Envoy Community Meeting 2020-01-09
B
C
Cool
well
welcome
everybody
to
the
UDP,
a
working
group
meeting,
we've
kind
of
had
a
hiatus
recently,
so
there
hasn't
been
a
ton
of
activity
in
UDP,
a
land
of
the
last
quarter,
essentially
so
that
kind
of
grow.
My
goals
of
the
meeting
if
I
was
justice
or
bring
that
up
to
date
with
what
the
roadmap
looks
like
what
our
plans
are
for,
q1
and
and
beyond
in
2020,
so
I've
made
a
good
way.
C
C
So
we
had,
you
know
on
v2,
FCS,
api's
v3,
which
is
what
most
of
the
workers
in
api's
that
I've
been
focused
on,
has
been
around
it's
basically
going
to
land
and
intercept
the
Envoy
one
or
13
release,
which
will
be
next
week,
we're
just
kind
of
turn
right
now
in
the
onboard
code
base,
it's
largely
a
mechanical
change,
but
it
also
puts
in
place
what's
called
the
stable
API
versioning
policy,
where
we
revenue
major
version
of
the
API
here
in
envoy
and
gives
us
the
opportunity
to
maintain
trading
support
for
two
versions
for
basically
for
two
years,
and
that
gives
us
the
ability
to
make
major
changes.
C
C
So
yes,
I
talked
a
little
bit
about
the
versioning
goals.
One
interesting
thing
to
point
out
is
it's
just
the
sheer
scale
of
what
we're
doing
with
api's
here,
I'm,
not
sure
what
their
API
so
other
proxies
looks
like
like
a
page,
a
proxy
or
nginx.
But
you
know
if
we
look
at
their
just
the
sheer
line
kind
of
the
protons
which
are
you
know,
it's
a
specification
for
the
API
for
Envoy.
It's
really
really
large,
largely
because
of
the
extensions.
C
Each
extension
has
United
configuration
API,
but
we're
talking
about
15,000
lines
of
proto's
and
it's
actually
more
like
10,000
code
references
in
Envoy,
so
there's
a
API
is
a
huge
artifacts
and
actually
involving
them,
as
requires
in
v3,
to
build
a
lot
of
tooling
to
support
that
and
I
anticipate
UDP,
a
as
it
grows
will
need
tell
this
tooling
at
first,
though,
where
we're
taking
the
is
happy
they're,
also
smaller
and
then
grow
that
outputs.
So,
let's
the
is
not
fun.
C
Okay,
so
we're
kind
of
roughly
at
this
point
where
we're
talking
about
the
idea.
It
is
that
you
know
all
the
worries
before,
or
at
least
at
the
end
of
the
year
at
320,
and
this
way
you
hoped
a
lot
of
UDP
a
stuff
will
intercept
and
we'll
be
able
to
move
some
of
the
things
that
exist
today,
no
boy
after
UDP
and
consume
that
as
a
first-class
product,
patience
for
API.
So
let's
talk
about
what
we
actually
wanna
get
done
in
2020.
C
Was
that
oh
yeah
we've
started
a
popular
unity
of
the
tree
and,
and
we
sum
of
the
protons
that
we
use
in
the
hombre
api's
with
you,
there's
nothing
here
that
should
be
particularly
controversial
or
require
massive
review.
There's
a
bunch
of
annotations.
We
use
to
express
versioning
concerns
or
the
fact
that
some
fields
might
be
redacted
or
this
kind
of
thing.
These
are
all
very
structural
things.
Anything
may
actually
make
a
difference.
What
the
API
looks
like
we
introduce
new
type,
which
is
called
type
struct.
C
It
looks
a
lot
like
any,
but
emoji
allows
us
use,
JC
representations
for
extension,
objects
in
the
API,
but
also
convey
bit
type
information,
so
it's
essentially
type
jason
and
that's
actually
very
useful
in
on
Voyager,
we've
actually
phased
out,
the
use
of
plain
jason
cell
types
and
v3,
and
I
think
we
would
probably
be
using
type
struts
in
various
places
and
UDP
able
everyone's
some
kind
of
structured
expansion
again.
This
is
very
much
the
case
of
how
you
make
the
vs
or
what
the
API
looks
like
there
are.
C
A
few
of
these
things
are
social,
and
we
also
move
that
in
some
point
this
are
collidable
stuff
now
I'm,
not
sure
where
we
always
there,
but
that
was
something
that's
probably
not
even
necessary
in
the
proxy
to
support
other
than
as
a
consumer
about
it.
It's
got
its
own
design,
doc,
not
not
so
important,
but
anyway,
you
basically
produce
a
side
to
land
here
and
on
board
depends
on
them
in
certain
ways.
All
these
products
have
no
Envoy
specifics
in
their
best
generally
useful
are
base
types
and
things
like
that.
C
So
this
point
I'm
not
so
interested
into
speaking
to
basically
it
was
just
that
we've
started
to
think
about.
One
of
the
things
that
we
need
us
to
think
about
is
how
do
we
arm
write
an
API
specification
which
can
generate
dark
and
where
the
docs
might
be
slightly
different
projects?
And
oh,
no,
if
we
have
a
good
solution
to
that
yet
or
maybe
folks
on
this
call
could
speak
to
it.
C
They
would
see
that
they're
looking
like,
but
you
know
it
probably
looks
something
like
we've
got
a
base
set
of
Doc's
with
a
certain
format.
For
example,
Sphinx
rst,
or
something
like
that
or
that
or
some
sort
of
doctrine
or
there,
which
could
be
target
to
any
four
that
you
choose
and
so
how
needs
to
merge
some
amount
of
status,
like
you
know,
does
this?
C
Does
my
proxy
support
this
or
do
I
have
any
proxy
specific
comments
on
this
API
with
the
base
documentation
and
that
might
maybe
we
would
have
anchor
points
and
your
deborah's
by
a
manifest,
which
you
know,
maps
each
of
these
anchor
points
to
your
destruction.
Information
for
your
proxy
and
users
provide
this
manifest
file
that
the
docs
build,
or
something
like
that,
and
that's
the
way
that
I
think.
D
C
Oh
okay,
thanks
a
lot.
Yeah
I
mean
I'm,
not
you
here
there
is
an
existing.
You
know,
tools
or
languages
that
people
prefer
here
and
not.
You
know
what
what
works
well
in
practice.
I
think
the
the
yeah,
the
general
structure
of
using
hangers
I,
think
is
probably
where
we
would
head
towards,
but
I
I
rather
avoid.
You
know
not
invented
here
and
cooking
something
up
from
scratch,
which
is
where
we'll
probably
go
otherwise.
Yeah
cool.
D
Okay,
so
yeah
I
mean
we
have
we
have
we
have
a
developer
generating
or
a
community
member
generating
like
HTML
Doc's
out
of
basic
documentation.
So
that's
like
the
worst
possible
example
of
trying
to
enrich
documentation
so
like
if
we
can
and
if
we
were
able
to
accomplish
that
I
think
we
can
sort
of
hopefully
find
a
more
maintainable
and
of
the
shelf
solution
to
enrich
an
existing
documents.
Virtually.
C
Yeah,
that
makes
sense,
I
mean
so
for
reference
envoy
uses
Sphinx,
which
is
you
know,
some
sort
of
python-based
documentation
system
which,
like
projects,
use
and
it's
pretty
nice.
It's
like
I
heard
of
it's
the
best
one
out
there,
but
it's
certainly
got
some
nice
features
like,
for
example,
you
create
internal
links
and
references
and
doesn't
link
of
consistency,
checking
which
is
like
really
good
for,
like
scalable
documentation,
I.
D
C
You,
okay,
so
UDA
next
steps.
So
there's
a
lot
of
I
think
that's
pretty
clean
that
we
need
actually
starts
doing
some
things
in
the
repository,
which
will
be
useful
and
I.
Think
the
the
pretty
the
least
controversial
thing
to
start
would
be
the
Transfer
Protocol,
which
itself
is
very
controversial,
but
it's
at
least
opinionated
about.
You
know
proxy
specifics.
The
council
protocols
more
about
delivering
objects
over
the
wired
version
of
objects
and
being
able
to
deal
with
dependencies
and
being
able
to
deal
with.
C
You
know:
acknowledgments
inheres,
this
kind
of
stuff
and
though
this
is
largely
going
to
be
incremental
from
FCS.
We
already
have.
You
know
the
UDP
ATP
specification,
which
is,
it's
so
implied
by
think
the
foundations
are
clear
enough
that
we
could
start
to
build
something
within
the
repository
and
then
actually
involve
that
specification
as
an
X
as
a
national
code
artifact.
C
We
will
potentially
just
start
by
writing
this
as
a
bunch
of
Python
scripts,
and
then
that
would
become
the
reference
implementation
and
from
there
we
could
build
compliance
tests
so
since
you're
using
these
and
have
something
which
anyone
want
to
claim
the
EP,
a
compatibility
with
could
implement,
and
we
could
then
think
about
how
that
would
look
in
terms
of
game
on
voice,
for
example,
to
speak
this
and
speak
to
the
rest
of
the
titular.
The
reference
implementation
and
there's
probably
already
some
choices
there
like
for
example.
C
What
would
your
specification
or
your
reference
model
that
would
be
Python,
should
really
go?
Should
it
be
written
in
roster,
yeah,
there's
all
kinds
of
questions
that
are
which
it
would
be
good
to
produce
here
from
folks
on,
because
all
things
being
equal,
I,
probably
just
write
this
in
Python,
because
I
know
pikin
extremely
well
and
it's
high
level
it
lets.
You
write
a
lot
of
Express
a
lot
of
things
without
actually
writing
a
lot
of
boilerplate
and
so
on.
So
yeah
and
he's
also
met.
D
C
Kirsten
asks
well
chat
more
politely.
To
keep
us
honest.
That's
an
interesting
idea.
What
what
cause
inaudible
cystic
voice
are.
C
Not
sure,
but
the
main
issue
here
is
I
would
like
to
just
keep
it.
You
know
we
were
one
canonical
reference
here
which
looks
to
me
taking
as
a
specification.
So
that's
right
twice
like
once
in
Python
wants
to
go
that
seems
kind
of
like
each
other
I
feel
we
definitely
do
want
go
implementations,
but
the
difference
between
I
got
a
product.
Implementation
I
think
that
what
you
won't
actually
use
as
your
management
server
and
something
that's
just
sad
to
say,
hey.
This
is
how
they
look
like
are
actually
very
interesting.
E
C
He's
done
a
lot
of
very
careful
there,
picking
something
thinking,
but
also
just
a
big
careful
analysis
and
auditing
also
looks
and
where
the
gaps
might
be.
What
are
you?
Their
goal
of
this
exercise
is
to
avoid
this
occurring
with
UDP
a
and
the
new
transport
protocol
we
put
together
do
the
same
vectors
writing
a
Python
reference
would
be
that
thing
that
would
take
us
that
place
for
some
tests,
or
is
there
something
else
that
you're
about
to
say
all
right.
E
I
think
the
compliance
tests
are
probably
will
be
more
important
than
the
reference
specification,
although
obviously
you
need
you
know
something
to
you
know,
make
sure
the
tests
are
doing
what
they're
supposed
to
do,
but
yeah
I
mean
I.
The
reason
I
think
the
compliance
tests
are
really
important.
Is
I'm
I'm,
not
so
worried
that
like?
If
we
only
do
the
initial
implementation
in
one
language,
we
won't
be
able
to
do
it
in
other
languages.
I
mean
I.
Think,
particularly
if
we
choose
Python
like
we
know
envoy
is
gonna,
be
doing
this
in
C++.
E
We
know
that
er
PC
is
gonna,
be
doing
it
in
at
least
C++
Java
and
go
so
I
mean
if
there
are
problems
that
somehow
don't
let
other
languages
implement
the
spec,
which
is
hard
for
me
to
imagine
I.
You
know
I'm,
pretty
sure,
we'll
be
able
to
identify
those
fairly
quickly,
I'm
I'm,
more
worried
about
just
making
sure
that
the
spec
is
rigorous
enough,
that
we
don't
have
subtle
differences
in
behaviors
between
implementations
and
I.
Think
the
compliance
tests
are
gonna,
be
a
lot
more
helpful
with
that
than
the
the
reference
must
be.
C
Yeah,
my
wife
in
there.
Yes,
hopefully
we
should
not
get.
First
of
all,
you
know
she
is
looking
at
these
tests
as
they
come
others
badge,
and
that
feels
better.
We
get
we
get
it
up
with
circle
box.
In
my
place,
initial
thoughts
are
pretty
to
artists
what
a
reasonable
time
frames
to
get
at
least
the
basics
of
potato
protocol
up.
There's
a
lot
of
facts
and
get
conversion
from
Greenman
I
mean
we
can
lead
back.
You
know
towards
the
end
of
q1
and
say
you
know:
are
we
in
a
place?
C
I
would
call
this
the
EPA
transport
protocol
or
not,
and
most
of
the
fun.
Hopefully
most
of
the
discussion
going
forwards
can
be
done
being
done
in
a
Google
Doc
and
we've
done
as
PR
reviews,
and
we
can.
You
know
if
we
can
solid
sterling
with
at
least
controller
speed,
Jim
the
UDP,
a
Chinese
protocol,
spec
kepler's
and
write
test
written
and
then
you
know,
propose
a
concrete
code
reviews
through
income
of
you,
an
extension
like
that.
We
need
this
Federation.
C
We
need
this
form
and
support
and
we
can
end
go
work
through
those
discussions
in
a
very
focused
way.
So
that's
the
golden
last
time,
I'm
sort
of
unless
there's
more
bandwidth
and
more
folks
who
are
able
to
contribute
towards
UDP
a
in
q1,
and
maybe
there
are
no
be
interesting
hearing
from
folks
on
this
I
feel
will
mostly
be
focused
on
transport
protocol,
then
and
then
2
2,
&
3
would
be
about
data
models
using
all
the
infrastructure.
C
C
E
C
D
C
We
definitely
really
valued
the
insights
from
other
folks,
because
we
don't
necessarily
have
the
visibility
into
how
other
proxies
work.
Okay,
yeah.
We
have
the
old
sequencing.
This
way
makes
sense
because,
through
t2
built
on
the
base
infrastructure
for
just
doing
tests-
and
you
know-
example,
clients
and
servers
and
transport
protocol
is
kind
of
needed
before
we
can
really,
you
know,
do
a
Walter
which
is
like.
C
Why
are
realistic,
so
that's
kind
of
why
I
like
to
float
I'm
so
critical,
I
also
feel
like
transfer
protocol
is
going
to
be
controversial
because
for
sure
proper
discussion
about
do,
we
need
a
basis,
is
very
complicated
to
implement.
Yeah
yeah
and
we've
already
had
some
of
those
discussions,
but
that's
I
think
those
things
can
stand
alone
and
they're
there.
There's
things
we
can
get
into
within
the
timeframe
of
q1.
F
On
this
topic,
I
I
mentioned
before,
but
one
way
to
avoid
some
of
the
controversy
is
to
maybe
start
with
a
subset
of
existing
exists
protocol,
which
has
most
of
the
elements
we
need
anyway.
I
mean
it's
a
genetic
bi-directional
message,
passing
protocol
with
a
knee
and
piped
and
everything
else
and
then
iterate
on
it
and
make
changes
as
necessary.
I
mean
if
there
is
strong
justification,
but
we
can
just
put
strapped
the
process
and
have
some
initial
versions
that
is
existing
XDS
all
the
data
model
and
then
fix
whatever
is
necessary.
C
Really
their
constant
I
mean
it'll,
look
kind
of
accusation.
Acs
remember
guarantee
it's.
Why
compatible,
but
I
think
that's
where
what
I
was
thinking
all
this,
we
would
start
with
like
simple
enough
that
it
looks
very
much
like
they
just
get
CSI,
because
a
few
slight
differences
that
were
they
have.
You
know
it
was
a
reserved
reason
that
you
might
wonder
why
a
compatibility
with
existing
it
I.
F
I,
don't
care
about
work,
opportunity,
I
care
about
of
waiting
the
bike
shedding
and-
and
you
know,
making
arbitrary
changes
just
because
we
can
I
mean
if
we
start
with
the
existing
protocol,
as
sees
I,
don't
care.
If
we
change
some
protocol
number,
we
are
Tory
whatever,
but
at
least
we
have
a
basis.
That
is
story.
Then
we
know
we
understand
and
has
multiple
amendment.
E
Ation
and
I
think
I
think
what
I
mean.
I
think
the
the
UDP
UDP
ATP
draft
that
that
harvey
put
the
other
is,
is
actually
a
really
good
place.
To
start
I
mean
it
is
very
similar
to
access,
but
it
I
mean
I.
I
really
cannot
tell
you
the
number
of
surprising
and
and
difficult
to
deal
with
edge
cases
that
we
run
into
in
G
RPC
trying
to
implement
that.
Yes,
there
are
things
that
just
semantically
do
not
make
sense
in
the
current
protocol,
as
is
so
I.
Do
think
that
we
shouldn't
do
anything
dramatically.
E
Different
I
think
customer
I
think
you're
right
about
that,
but
I
don't
think
just
starting
from
the
current
protocol,
as
is
a
good
thing.
I
think
we
really
need
a.
We
need
to
start
sort
of
fresh,
which
is
what
the
ATP
TB
draft
does
with
the
same
concepts,
but
with
a
clean
thing
with
well
established
semantics
that
doesn't
have
any
of
the
backward
compatibility
problems
that
that
you
know
tie
us
to
these
ridiculous
behaviors
that
are
grandfathered
indexed.
F
I,
don't
disagree
with
you
on
that
many
are
rough
hitches
and
to
be
wonderful
to
identify
them
and
fix
them.
But
there
is
no
warranty
that
if
you
start
fresh
to
Dory,
Pizza
mistakes
I
mean
or
you
don't
end
up
with
something.
That's
us
because
you
know
usually
the
rating
is,
you
know
you
fix
what
is
broken
energy
buddies
instead,
I
know
it.
C
Just
makes
me
so
far
away
to
my
maybe
this
is
like
from
a
historical
perspective,
so
you
know
FCS
within
a
rosy
rose.
You
know
we
had
an
idea
that
it
might
be
more
canary
fingers
than
envoy,
but
in
reality
it
was
built
in
the
old.
More
code
base
really
existed
were
the
envoy
tests.
The
only
reference
client
was
envoy
and
its
internal
implementation
and
then
led
to
a
number
of
the
things
as
creep
in
when
you
do
that.
C
We
had
all
the
experiences
not
having
it
done
right,
the
first
time
and
so
we're
we're
gonna,
ideally
just
build
on
that
in
GDP
ATP,
like
we
may
really
rethink
what
aliases
look
like
a
UDP,
a
cheapy
to
make
sure
that
then
it's
comfortable,
then
it's
very
clear.
Why
then,
if
they're
there
and
what
well
our
purpose
they
sell,
but
maybe
in
the
first
draft
that
at
first
PR
I'll
and
let's
say
there
will
be
their
aliases-
will
strip
the
aliases
out.
F
An
alternative
would
be
to
start
with
an
existing
property.
You
know
for
messaging
like
like
the
not
streaming
or
some
other
protocols
that
exist
and
modify
to
our
fits.
But
again,
if
you
think
that
it
will,
we
can
avoid
the
bike
shedding
and
and
will
not
repeat
mistakes
by
trying
to
be
genetic
and
have
second
symptom.
A
second
system
syndrome
maybe
see
how
it
evolves.
You
know
in
you
know
the
last
next
month
or
so,
and
if
it
ends
up
to
something
stable
and
we
don't
go
down
the
rabbit
hole,
yeah.
C
Infinite
period
mind
is
very,
very:
can
order
a
hundred
without
many
artists,
in-house
management
service
written
for
xes,
and
so
we
don't
want
to
go
too
far
away
from
the
existing
model,
like
I.
Don't
want
to
move
on
to
some
generate
America
like
a
messaging
bus
architecture
or
something
or
Mesa
streaming
system,
which
has
nothing
to
do
with.
You
know
they're
there
sometimes
for
clinical
yesterday,
but
that's
a
big
rewrite
for
a
lot
of
folks.
I
feel,
and
it's
also
just
yeah.
C
A
big
conceptual
step,
the
same
time
things
we
should
have
plain
weird
that
we've
done
the
in
actually
s
the
wrong
way,
which
we
done
better
and
other
messaging
systems.
We
definitely
should
build
for
her
take
into
account,
like
other
folks,
do
error
handling
better
or
you
know,
versioning
better
and
we've
missed
something
that
we
should
just
build
that
into
the
protocol.