►
From YouTube: Ambient Mesh WG Meeting 2023 03 01
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
Okay,
HTTP
3
support
whose
topic
is
this.
C
E
About
that
I
think
Steve
got
stuck
in
traffic,
so
you
might
be
here
for
the
laptop
of
the
meeting.
If
it
goes
that
long.
E
E
F
E
Okay,
so
remember
that
we're
talking
about-
or
at
least
my
proposal,
there's
other
things
we're
talking
about,
but
my
proposal
was
to
create
a
tag.
Api
that
looks
like
this.
It's
really
just
a
name
pointing
to
a
revision
which
is
exactly
what
a
tag
is
today.
This
just
formalizes
that,
as
a
crd
today,
it
exists
sort
of
implicitly.
E
E
What
the
pros
and
cons
would
be
conston
has
proposed
using
Gateway
class
in
lieu
of
tags
and
so
I
sort
of
compared
and
contrasted
that
as
well
as
I've
made
the
proposal
and
and
Lynn
had
a
suggestion
as
well.
That
was
like
a
crd
that
looks
just
like
the
one
I've
proposed,
but
is
not
for
sidecar
mode
and
therefore
probably
not
called
tag
anything
but
come
up
with
a
new
name
for
tags
in
ambient,
and
then
I
have
a
little
table
sort
of
summarizing.
E
The
four
kind
of
objectives
that
I'm
measuring
everything
against
that
you'll,
see
listed
in
each
of
these
pros
and
cons
is
I
would
like
it
to
be
compatible
with
how
the
tag
CLI
works
today,
so
that
users
can
take
advantage
of
their
existing
automation
if
they've
built
on
top
of
that
they're
not
having
to
learn
anything
new.
All
of
these
are
things
that
I
would
like
to
see.
I
don't
know
that
they
are
necessarily
requirements.
E
We
could
go
without
them,
I
so
that
that's
the
CLI,
particularly
the
istio
control
command
consistent
with
the
sidecar.
In
other
words,
you
would
use
the
one
API
or
command
to
upgrade
both
ambient
waypoints
and
istio
sidecars,
as
well
as
standard
istio,
Ingress
and
egress
gateways.
E
Having
I
I
think
really
having
two
mechanisms
for
doing
this,
so
that
you
have
like
a
sidecar
upgrade
step,
and
then
you
have
a
waypoint
upgrade
step
is
not
a
good
idea.
Personally
get
UPS
friendliness.
We
talked
a
lot
about
how
the
existing
process
for
tags,
the
istiocuddle
CLI,
is
not
get
Ops
friendly.
It's
very
difficult
to
look
at
a
git
repo
and
see
what
tags
are
present
in
it
and
to
reason
about
those,
because
we
don't
save
them
as
tags.
We
save
them.
E
As
this
thing
down
here,
a
giant
mutating
Web
book
configuration
so
hard
to
reason
about
changes.
Etc
I
have
been
meaning
to
whoops,
meaning
to
but
I
haven't
gotten
around
to
giving
an
example
of
like
a
pull
request
for
changing
tags
in
this
mode
that
we
have
today
versus
my
proposal.
I
hope
to
add
that
soon
and
then
the
the
last
is
one
of
the
objectives
and
I
feel
really
strongly
about
this
one.
E
We
should
not
have
mutating
web
hooks
present
in
ambient
mode
if
sidecar
mode
is
disabled,
that's
a
security
vulnerability,
so
those
are
the
the
area,
the
ways
that
I'm
sort
of
judging
these
different
options,
but
I
wanted
to
invite
you
all
to
consider
that
I
also
wanted
to
ask
you
know:
we've
been
talking
about
this
since
early
January.
Since
we
came
back
from
break,
we
are
supposed
to
go
to
Alpha
in
the
118
release,
whose
code
freeze
is
somewhere
less
than
four
weeks
away.
Is
that
right?
E
G
So
some
of
which
I
I
don't
think
anything
changes,
I,
don't
think
we're
addressing
the
comments
that
I
had
about
creating
a
full-blown
crd
I
mean
when
we,
when
we
we,
you
know,
try
to
stay
clear
of
creating
CR.
This
was
far
more
commonly
used
things
just
for
the
sake
of
a
feature
that
it's
blown
out
of
proportion,
because
you
are
trying
to
cover
the
entire
world
change.
How
tags
work
in
sidecar
for
ambient?
We
have
a
very
narrow
problem.
Really
I
mean
for
for
Z
tunnel
is
clearly
it's
just.
G
How
do
we
manage
the
waypoints
and
and
maybe
gateways
for
and
I,
don't
think
we
are
ready
to
commit
to
an
API
called
Tags?
That
is
confusing
and
impact
sidecars
and
all
the
other
stuff.
Just
to
do
a
very
simple
thing
that
that
you
know
we
could
put
a
config
map
like
mesh
config
and
and
be
done
with
it.
G
For
this
release
in
particular,
I
completely
agree,
I
mean
there
is
no
disagreement,
that
we
should
not
put
it
in
in
the
in
the
injection,
but
from
not
putting
an
injection
to
Let's,
create
a
new
crd
and-
and
you
know,
discuss
our
back
and
it
is
a
huge
distance.
So
do
you
find
something
in
the
middle
that
that
it's
possible.
G
G
I,
don't
know,
I
mean
it's
it's
something
that
is
specific
to
the
upgrade
process.
It's
not
something
that
it's
you
know
such
such
an
important
thing
to
to
to
worry
too
much
about
is
just
for
Waypoint
upgrades,
I,
don't
think
if
it
at
this
point,
we
need
to
worry
I
mean
with
all
the
alpha
things
where
we
put
an
alpha
config
map
to
be
blocked
on
it.
For,
for
too
much
foreign.
E
As
we
expose
this
to
users,
we
we
are
committed
to
supporting
it
as.
G
G
B
G
Very
very
good
point:
I
mean
sorry
I
miss
that
yes,
I
mean
first,
let's
verify
this
upgrade
Works
before
we
commit
to
the
API
and
let's
see
how,
because
we
don't
have
too
much
experience,
upgrading
waypoints
so
far,
I
mean
we
don't
know
how
you
know.
Maybe
history
will
do
it
automatically
if
there
is
no
need
for
API
Maybe,
there
is
no
need
for
user
to
control
it.
Maybe
it's
not
possible
that
was
kind
of
the
whole
thing.
I
mean
we
don't
even
know
what
the
user
experience
will
be
without
going
through
at.
E
So
this
document
does
not
address
I
think
what
they're
talking
about
is
whether
the
upgrade
can
be
hitless
or
not.
We
initially
decided
back
in
like
November
when
we
first
talked
about
this,
that
hit
list
upgrades
may
or
may
not
make
it
into
open
source
that
it
was
something
that
would
be
nice
to
have,
but
that
we
weren't
sure
exactly
how
it
would
work
with
z-tunnel
and
waypoints
Etc,
regardless
of
whether
the
upgrade
is
hitless
or
not.
We
still
have
to
support
customers
upgrading.
E
We
cannot
ship
a
product
that
is
not
possible
to
upgrade
so
we've
added
functionality
that
allows
waypoints
to
be
upgraded
today.
The
way
that
it
works
is
one
is
Tod
must
control
all
waypoints
in
the
cluster.
When
you
upgrade
that
sdod,
it
automatically
upgrades
all
the
waypoints,
no
tags,
no
revisions,
no
possibility
for
rolling
back
without
rolling
back
the
whole
control
plane.
This
proposal
would
allow
us
to
have
a
process
that
is
similar
to
the
process
we
follow
today
for
sidecars
I,
totally
agree
that
hit
list
is
important.
Someone
should
be
working
on
it.
E
That
someone
is
not
me.
That's
not
my
skill
set
I.
Don't
know
enough
about
Z
tunnels
to
or
h-bone
to
talk
about
how
to
drain
them
Etc,
but.
G
But
you
are
interfering
with
that
work
because
you
are
proposing
an
API
that
may
or
may
not
be
possible
to
implement
I
mean
if
The
Hit
List
upgrade
requires
your
edit
work
stays
update
without
user
control.
Without
then,
your
API
will
stay
in
the
way,
because
we
are
promising
that
this
stock
will
do
something
and
whatever
that
spec
is
saying,
and
that
may
interfere
with
other
upgrades
options.
Because
again
it's
not
something
that
this
API.
E
Will
absolutely
work
today
using
the
technology
that
we
have
today
upgrades
already
happen
today
when
you
operate
as
DOD.
This
just
gives
users
control
over
when
that
happens,
whether
or
not
that
upgrade
is
hitless
is
not
something
that
this
API
gets
us
to.
I
think
it
should
be
hit
list
I,
think
someone
should
be
working
on
that,
but
that's
not
what
this
API
is
about.
E
G
Not
twist
what
what
said
I
mean
what
I
think
what-
and
we
are
saying,
is
that,
right
now
the
upgrade
process
is
not
very
well
established.
We
never
did
an
upgrade
of
zitana
because
we
haven't
shipped
it
yet
and
it
is
parked
to
premature
to
to
to
Define
apis
for
something
that
we
never
did
for.
G
Istio
we'd
introduced
revision
and
tags
after
about
five
or
six
releases,
where
we
did
upgrades
without
them,
and
then
it
was
two
or
three
releases
where
we
discussed
it
got
feedback
figure
out
how
it
is,
and
we
end
up
with
an
ATS
that
is
not
perfect.
I
missed
you
a
couple
tags
and
putting
it
I
agree
with
you,
but
you
know:
history
didn't
explode
because
you
didn't
have
a
Target
API.
It
was
a
crd.
E
D
Have
a
hard
time
understanding
why
this
is
such
a
big
deal
to
a
user
experience,
I
mean
it's
an
implementation
detail
right.
They
use
the
Easter
Kettle
command
to
operate
anyways,
so
is
it
a
mine?
Is
it
an
improvement
potentially,
but
it's
not
like
a
groundbreaking
difference
right.
Most
users
won't
even
notice
that
the
change.
E
D
E
D
D
E
B
E
D
We're
committing
this
API
that
impacts
everyone,
so
I
have
my
big
fear
in
general,
and
we
have
this
issue
with
the
Gateway
API
is
in
order
to
support
some
experimental
Alpha
thing.
We
introduce
a
more
stable
API
and
then
that
experimental
thing
is
experimental
right.
So
it
changes
all
the
time
and
now
we're
stuck
with
this
more
stable
API,
because
the
you
see
what
I
mean
yeah.
E
I
understand
that
the
the
tag
and
revision
API
is
something
that
we've
already
promoted
to
Beta
in
the
existing
sidecar
mode.
So
this
is
not
experimental
or
new.
This
works
exactly
the
same
way
that
it
worked
before.
There's
some
implementation
detail
changes
in
terms
of
how
they're
persisted
to
the
cluster,
but
the
CLI
that
we
tell
users
to
make
use
of
which,
as
I
understand
it
is
beta
today
stays
functional.
We
see
improvements
for
git,
Ops
users,
you're.
E
If,
if
we
were
to
not
do
this
to
Simply
continue
the
status
quo
until
we're
ready
to
go
to
a
ambient
only
mode
that
could
potentially
work
for
our
users
I'm
just
curious,
why
an
API
that
we've
had
for
years,
that's
a
Beta
Support
that
has
one
field
in
it
is
controversial
for,
for
the
group.
G
D
G
A
lot
of
other
API
crd
is
that
we
already
demand
is
an
early
day
with
mixer
when
pretty
much
everything
had
the
crd
and
we
had
100,
CRPS
and
people
started
to
complain.
We
have
too
many
crds
to
understand,
but
major
I
think
we
are
making
some
assumptions
here.
I
mean
with
Gateway.
For
example,
we
had
the
install
that
was
bundled
issue.
G
Like
you
said
we
changed
it
many
times
we
had
an
install
that
was
based
on
a
Helm
chart
when
installed
based
on
injection,
and
now
we
are
finally
converging
on
yet
another
different
installer
history
of
this
completely
managing
and
the
user
doesn't
have
to
to
to
do
anything.
Basically,
so
revision
is
great,
it's
not.
It
was
not
a
bad
idea
at
the
time.
It
doesn't
mean
that
we
are
stuck
doing
revision
based
upgrade
forever
for
everything
gateways.
For
example,
I.
Don't
think
there
is
any
concept
of
revision
based
upgrading
Upstream,
kubernetes
Gateway
API.
G
Each
controller
is
free
to
do
its
best
to
up
to
it
and
to
make
it
happen,
however,
it
fits
without
any
user
intervention.
Same
thing
is
probably
true
for
tags,
because
the
next
Evolution
step
for
revision
based
upgrade,
is
fully
automated
upgrade
where
we
take
care
of
the
upgrade
without
user
having
to
to
deal
with
tags.
G
E
A
So
Mitch
I
guess
I
have
a
question
for
you.
Is
this
major
issue
for
you
for
psycha,
or
is
this
a
major
issue
for
you
for
Ambien,
because
with
ambient
what
I'm
seeing
is
we
don't
really
have
this
issue
because
we
are
going
to
support
psycho
like
the
ambient
profile
we
have
is
going
to
support
zaica
for
the
near
future,
right
probably
for
at
least
a
year,
and
even
probably
more
so.
The
issue
probably
resides
back
to
the
cycle
world.
Is
that
what
you
see
with
your
user
that
have
this
problem.
E
I
see
two
problems
and
one
of
them
I
think
you're
right
on
the
nose
for
as
soon
as
we
want
users
to
be
capable
of
running
ambient
without
sidecar
mode.
We
need
to
not
have
mutating
Web
book
configs
as
part
of
our
installation.
E
I
I
think
that
there
will
be
users
interested
in
making
use
of
ambient
in
net
new
clusters
as
soon
as
we
call
it
Alpha
who
are
not
interested
in
using
sidecars.
At
that
point,
the
mutating
web
Hook
is
simply
a
vulnerability
with
no
benefit
to
it.
So
when
that
happens,
we
do
need
some
sort
of
new
way
to
represent
tags.
The
other
benefit.
E
The
second
is
for
get
Ops
get
Ops
users
today
effectively
cannot
make
use
of
tags
because
we
do
not
have
an
API
and
because
you're
required
to
run
a
CLI
in
your
git
Ops
environment,
which
is
just
not
a
thing
so
for
both
sidecar
users
and
ambient
users.
We
need
an
API
for
tags,
whether
that's
a
config
map
based
API
or
a
crd.
We
need
something
that
you
can
clearly
see.
There's
a
tag
with
this
name.
It
pointed
to
this
provision.
Now
it's
been
updated
to
point
to
that
revision.
A
E
Using
config
maps
and
little
of
a
crd
is
completely
viable
from
a
technological
standpoint
that
will
work
well
for
git
Ops
users.
It
will
eliminate
mutating
web
hook
configs
for
ambient
only
mode.
That's
all
great,
however,
if
we
view
it
as
an
intermediate
step
to
later
introducing
an
API
we're
again
asking
our
users
to
change
their
integration
point
for
the
first
year.
You
can
modify
this
config
map
and
it
will
change
how
things
are
upgraded.
G
We
keep
telling
users
not
to
use
Alpha
CRTs
because
they
are
experimental.
We
keep
saying
that
it's
Alpha
means
we
can
modify
it,
but
you
are
saying
that
the
main
motivation
for
cutting
the
crd
is
that
it
cannot
be
changed
later
and
users
will
not
change
it.
I
mean
pick
one
of
them
either
it's
an
alpha
crd
that
will
change
and
eventually
become
a
beta.
Maybe
it's
a
different
form,
because
who
knows
the
alpha?
Or
it's
not
going
to
change
that?
We
have
a
completely
different
discussion.
I
mean
you.
E
We
have
the
ability
to
change
any
API
that
we
introduce
as
Alpha,
whether
it's
a
config
map
or
a
crd
or
a
Home
option.
We
have
the
ability
to
change
it.
I
would
be
opposed
to
introducing
any
option
that
we
expect
to
change
in
the
coming
12
months.
It's
one
thing
to
say:
if
we
got
it
wrong,
we
might
be
able
to
dial
it
in
later.
It's
another
thing
to
say
we're
shipping
it.
Today
we
know
it's
wrong
and
we'll
fix
it
later.
G
And
that's
how
we
ended
up
with
all
the
crappy
apis.
We
have
initio
because
we
said
that
hey
it's
Alpha.
We
don't
need
to
review
it
too
much.
We
don't
need
to
have
experience.
We
don't
have
to
have
feedback,
let's
put
it
Alpha,
because
we
may
change
it
later
and
then
the
argument
changed
immediately
after
say:
hey
we
have
Alpha,
we
don't
want
user
to
change.
Let's
we
have
to
keep
the
same
API
and
promote
it
to
Beta,
because
I
mean
I
I,
don't
know.
G
A
D
It's
I
I'm
just
not
sure
why
we
can't
just
stick
with
the
web
hook
in
the
short
term,
like
what
is
a
config
map,
short
term
I
I,
think
I
agree
with
Mitch's
concern.
I,
don't
want
to
go
from
webhook
to
config
to
tag
I'm,
not
sure
why
we
need
the
intermediate
State.
Can
we
just
stick
with
webhook
for
now
and
if
we
want
to
do
tag
later,
we'd
go
to
tag
I.
G
I
only
support
this
is
a
proposed
to
configure
map,
because
if
you
absolutely
cannot
use
webhook,
if
you
can
speak
with
web
Hooks
and
that's
the
best
option
because
less
less
problems
for
existing
users
and
it's
you
know
easier
trans
transition
and
when
we
are
ready
to
get
rid
of
sidecars,
then
we
can
do
whatever
is
necessary.
A
D
B
G
G
D
E
Can
you
clarify
the
Ops
to
manage
their
istio
installation
today?
Most
of
them
are
hand.
Upgrading
most
of
them
also
do
not
use
tags.
According
to
our
latest
upgrade
surveys
in
the
last
survey,
we
did
not
find
any
users
who
use
tags
and
revisions.
A
E
I
am
saying
that
it
is
a
very
high
friction
process.
I've
got
a
demo
of
how
to
do
it.
I've
I've
presented
it.
However,
like
the
chain,
if
you
just
change
one
tag,
the
pull
request
is
extremely
confusing.
It's
like
a
20
line,
change
in
a
very
highly
sensitive
object.
Within
kubernetes.
It
should
be
a
one-line
change.
G
Yes,
but
again
this
is
you
can
still
use
githubs
for
everything
else.
You
can
deploy
pause.
You
can
do
everything
except
upgrading
on
managing
history.
That's
the
only
thing
that
is
really
broken.
Yes,.
G
G
I
mean
you
know
you
need
to
do
some
tricks.
I
mean
you
know
how
how
to
you
know
managed
upgrade
works.
You
cannot
just
apply
some
config
and
leave
it
yeah.
If
it's
there
there's
some
some.
You
know
check
some
metrics
that
you
don't
crash
something
do
some
stepping.
That
is
not
something
that
is
fully
get
UPS
friendly.
Well,.
E
I
mean
that's
precisely
what
git
Ops
does.
Incidentally,
it
applies
config
and
then
it
checks
to
see
if
that
application
was
successful
and
resulted
in
the
desired
state.
But
if
it
didn't
it
will
roll
back
the
config
that
it
has
applied
so
I
think
we're
I
think
we
have
more
or
less
agreement
unless
someone
objects
for
the
alpha,
we
will
use
this.
D
A
E
D
I
think
that's
a
general
problem.
We
need
with
Ambien
right
we're
shipping
ambient
Alpha
as
a
means
to
get
feedback
which
is
I
almost
wonder
if
we
should
do
like
a
survey
just
like
we
do
with
upgrades
like
put
it
in
the
getting
started,
docs
to
say
hey
once
you
try,
this
out,
give
us
feedback
or
something
I,
don't
know
you're,
probably
better
than
than
outside,
of
that
Mitch.
So
I'm
kind
of
looking
to
you
to
answer
your
own
question.
E
Yeah
I
mean
obviously
we've
done
surveys
in
the
past.
We
get
about
10
ish
responses
for
each
upgrade
and
we
would.
We
would
certainly
want
to
add
and
expand
the
118
survey
to
cover
information
about
ambient
and
then
again
we're
at
119.
E
That
being
said,
We've
often
not
received
feedback
on
things
that
we
hope
to
receive
feedback
on,
for
instance,
the
the
117
or
116
upgrade
survey.
Nobody
used
tags
or
revisions
at
all,
so
we
didn't
get
any
feedback
on
how
that
worked.
Yeah.
D
A
F
We
of
any
big
customers
today
that
might
actually
you
know
are,
are
really
excited
about
ambient
want
to
try
it
out
that
kind
of
thing
give
people
that
maybe
are
experienced
with
istio
already
anybody
have
any
information
there.
E
What
we
need
to
do
is
Identify
some
I
don't
want
to
call
them
Flagship
users,
but
like
users
who
are
willing
to
try
it
out
and
come
and
share
publicly
with
the
community.
We've
done
that
before
at
Toc
meetings.
Like
being
you
know
now
that
I'm
at
aviatrix
I
don't
have
as
much
contact
with
istio
users
as
I
had
at
Google.
So
I'm
I'm,
not
in
a
great
position
to
invite
users.
There
I've
got
a
handful
just
that
I
know
from
the
community.
E
I
can
invite,
but
maybe
we
should
plan
like
either
the
April
or
May
Toc
meeting
to
invite
users
to
come
and
give
feedback
on
ambient.
A
E
I'll
put
together
kind
of
a
strategy
for
collecting
feedback
on
ambient
in
general.
I'll
try
to
include
this
upgrade
process
with
tags,
I've
already
taken.
Two-Thirds
of
the
meeting
and
I
know
that
Steven
had
some
stuff
to
discuss
regarding
H3.
So
unless
there's
other
burning
content
I'd
like
to
let
him
talk
just.
G
B
C
Issue,
or
are
you
good
I'm,
just.
C
So
this
dog
sort
of
mostly
just
kind
of
a
evaluation
of
different
libraries
for
H3
and
click.
The
pyoda
pointed
out
to
me
a
different
approach,
which
is
supporting
Beauty
like
the
whole
idea.
Is
that
quick
and
H3
would
let
us
do
unreliable
message
passing
and
support
UDP
proxy,
but
we
could
proxy
UDP
with
reliable
message
delivery
over
H2,
but
it
would
just
likely
be
pretty
slow,
but
we
would
still
get
GDP
support
I.
Imagine
that
quit,
but
also
still
have
benefits
for
TCP
proxy.
C
So
those
are
like
two
different
orders
that
we
could
do
this
in.
So
maybe
we
should
discuss
that
first.
I
actually
think
there
are
two
separate
efforts,
so
what
I
understand
was
pure
some
other
folks.
C
Out
H3,
if
we
have
people
that
can
go
to
parallel,
then
yeah
yeah,
it's
already
industry.
Here,
okay,
yeah
I,
have
seen
web
transport
custom.
C
G
So
yeah
it
is,
but
the
special
thing
is
that
it
has
some
some
specific
provisioning
for
the
datagram
over
H2,
which
basically
says
that
you
can
drop
datagrams
and
and
because
that's
really
different
between
udps
or
you
can
each
which
point.
If
you
you,
you
have
your
queues
full
or
whatever
you
just
drop
udps
and
you
get
the
behaviors.
That
UDP
has.
C
G
The
part
about
datagram
handling.
G
F
G
A
F
C
Talk
to
each
other,
but
this
loan
for
now
is
more
focused
on
hp3
and
more
specifically
picking
a
dependency
or
picking
dependencies
to
use
for
our
quick
transport
and
HTTP
3
lib,
the
landscape
and
rust
for
hp3
support.
It's
a
little
like
early
there's,
pretty
much,
nothing
that
supports
regular
connect.
C
That
supports
web
transport
or
sorry.
No,
it
was
the
Mozilla
one
that
supports
web
transport,
but
that
library
is
also
pretty
it
doesn't
have
a
lot
of
documentation
and
it
doesn't
let
us
use
boring
SSL.
The
only
thing
that
let
us
use,
boring
SSL
is
Quinn,
which
is
supported
with
Hyper
or
the
underlying
library
for
hyper,
but
pretty
much.
My
proposal
is
that
we
don't
use.
C
We
don't
wait
for
all
these
things
to
support
what
we
need,
because
we
contribute
upstream
and
we
still
go
within
the
like
Hyperion
hyper
ecosystem
and
use
their
H3
Library,
which
is
a
little
bit
lower
level
than
the
library
we're
currently
using
for
H2.
C
But
we
just
internally
unstrap
things
so
that
we
can
use
their
lower
level
library
and
get
H3
support
sooner,
provide
them
feedback
on
how
they
can
put
this
into
their
like
main
higher
level.
Library.
C
D
C
Much
is
Just
provides
a
pretty
high
level
Matrix
of
what
they
give
us
off
the
bat
and
what
like,
what
my
perceived
level
of
activity
and
maturity,
each
one
has
so.
F
Just
just
a
few
of
the
question
about
the
teach
Library,
there
are
actually
two
teach
loggers,
there's
Google's
quiche,
which
is
C
plus
plus,
which
I
suspect
would
be
it's.
It's
a
big.
F
Very
difficult
to
to
use
for
rust,
given
that
a
lot
of
us
are
still
kind
of
rust,
UVs,
the
the
other
quiche
is
in
Rust
from
cloudflare.
It
doesn't
seem
to
be
very
well
maintained
and
it
it's.
It
also
doesn't
seem
to
directly
support
async,
which
is
you
know,
basically,
the
the
whole
stack
that
we're
using
is
positioning.
F
Currently,
it
looks
like
hyper,
which
is
the
H2
implementation
that
we're
currently
using
is,
is
is
built
on
top
of
Queen,
for
each
is
building
until
is
their
their
H3.
Work
is
currently
building
a
type
of
coin,
so
we
we
ended
up
kind
of
going
the
same
route.
The
nice
thing
about
The,
Clinton
Library,
is
that
it
actually
has
a
pretty
clear
API
for
the
crypto,
so
we're
actually
already
actively
contributing
a
boring,
SSL
implementation
of
the
crypto,
so
that
can
that
gets
us
to
fips.
G
F
G
If,
for
some
reason,
we're
not
happy
with
the
library,
we
chose
we'll
just
revalue
it
later,
yeah
has
anyone
asked
about
the
employees.
You
know
we
already
take
independency
on
on
wish,
C
plus
plus
Google,
which
is
also
is
in
Chrome,
so
that
if
it
is
possible
to
use
that
it
may
simplify,
avoid
some
bugs,
because
who
knows
I
mean
at
least
we'll
have
the
same
implementation
and
then
parity
and
bugs
and
and
boy
Chrome,
and
what
you
probably
know
more.
B
Yeah,
so
good
Google's
quiche
is
not
fully
integrated
as
a
it's,
not
fully
Implement
of
a
connect.
So
this
implementation
is
also
not
fully
integrated
into
NY.
There
is
somebody
working
on
that,
but
it's
about
the
same
level
of
you
know.
Early
prototyping
I
would
say
there
is
a
design
dock
for
how
to
do
quiche
for
extend
the
connecting
Envoy
and
I
think
it
makes
sense
to
share
the
structure
of
the
configuration
to
program
the
library
but
I,
don't
think
we
can
share
code
unless
you
try
to
import
all
of
cache
into
zitano.
F
I
I
also
just
generally
kind
of
prefer
to
err
on
the
side
of
you
know
or
a
rust
solution
as
much
as
possible.
I
mean.
Obviously
it's
still
wrapping
boring
SSL
at
some
level
to
get
fips,
but
you
know
eventually,
rust
TLS
will
will
actually
have
some
some
way
of
achieving
fips
compliance
itself.
So
we
can
back
that
out,
but
yeah
I
I
just
think
the
debuggability
of
the
the
memory
safety,
all
the
all
the
stuff
that
Russ
gives
you.
B
So
right
for
me
what
what
I
care
is,
how
much
use
it
gets
and
right
now,
quiche
has
a
lot
more
use
for
UDP
and
quick.
So
if
we
choose
any
Library
I,
don't
really
care
which
language
or
Technologies
it
has
to
have
some
kind
of
use
shouldn't
be
the
one
who
I
have
to
you
know
iron
out
all
the
protocol,
which
cases
right
right,
but.
F
I
mean
that's:
to
that
point,
I
mean
hyper,
is
probably
the
standard
HTTP
library
for
rust,
and
that's
that's
going
to
build
various
resolution
on
Quint.
So
we're
still
in
connect.
B
B
G
F
Well
folks,
at
Google,
if
you
want
to
you,
know,
get
some
some
folks
in
the
Google
teach
team
to
help
us
out
with
rust
findings.
You
know
just
send
us
a
chat.
That'd
be
great,
but.
G
But
but
Nate
I,
don't
think
I
mean
that's.
Why
I
said
initially,
we
can
change
it
later.
So
if
it's
easier
to
integrate
with
with
Quinn,
let's
integrate
with
green,
get
some
feedback
figure
out
how
it
works
and
we
can
change
it
when
it's
ready,
I
mean
it's,
not
I,
don't
think
even
connect,
and
it's
it's
really
that
big
of
a
deal
let's
test
H3
do
some
benchmarks,
maybe
another
one.
D
Yeah
I
generally
agree.
I
just
want
to
express
I
I
think
that
you
guys
are
on
the
same
page
already,
but
we
should
just
make
sure
that
this
is
kind
of
siled
off
in
kind
of
its
own
file,
possibly
even
turned
off
by
default,
like
with
the
build
quag
or
just.
G
D
A
A
Answer:
yeah,
no,
no
sorry
I
think
I
I
was
going
to
say
your
point.
Actually
so
I'm
actually
a
little
bit
concerned
about
introduced
this.
It
has
to
be
off
by
default
before
user
feels
comfortable
and
also
I'm,
also
a
little
bit
worried
about
like
the
performance
impact.
A
Hopefully
it's
supposed
to
perform
better
right,
but
you
know,
and
also
would
this
cause
any
of
a
binary
impact
of
the
Z
tunnel
like
the
size,
the
resource
utilization,
I
think
there's
a
lot
of
things
to
look
at
before
we
can
even
enable
it,
so
it
has
to
be
default.
For
now-
and
here
you
know,
more
vendors
have
more
confidence
about
this
yeah.
F
G
Think
we're
going
too
far.
I
mean
it's,
it's
probably
okay
to
build
it
as
a
binary.
Just
not
enabling
by
default
does
use
it
by
default.
So.
F
So
I
think
long
and
short
of
it
is
there's
a
million
ways
to
enable
it
explicitly,
and
we
can
just
discuss
that
when
we
get
to
a
design.
B
So
related
to
this
and
I
think
quick
Downstream
for
connect
HTTP,
regular
HTTP
connect
is
already
considered
production
stable
in
Android.
So
we
can
do
it
today.
The
concern
there
is
that
it
bypasses
Network
policy
and
especially
if
you
change
from
TCP
to
UDP,
you
can
somehow
it
might
be
unexpected
that
suddenly
protocol
goes
through
with
it
goes
through
when
you
put
a
policy
of
firewall
policy,
so
we
should
work
out
how
that
works.
B
F
Could
you
can
you
expand
on
that
just
a
little
bit
just
just
well.
B
F
B
F
B
Seems
like
it's
a
discussion
in
itself,
yeah
great,
so
I'm
I
think
there
was
an
issue,
but
I
think
we
should
probably
have
an
answer
before
Alpha.
That
seems
like
a
yeah.
A
Yeah
can
I
ask
a
dumb
question.
I
saw
that
in
the
chat
about
our
voice
support
for
for
quick.
So
let's
say
one
day
we
did
enable
zetano
with
HTTP
3
I
assume.
That
means
like
the
English
Gateway
Waypoint
all
needs
to
have
the
quick
support
to
be
able
to
communicate.
B
F
Okay,
I
think
that's
all
we
had
on
this
topic.
Any
other
comments.
F
F
E
G
E
Very
well,
thank
you.
Everyone
for
your
input,
I
will
get
to
work
on
the
tag
thing
and
it
was
great
to
have
the
H3
conversation
and
see
you
next
week.