►
From YouTube: Ambient Mesh WG Meeting 2023 03 29
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).
B
Okay,
great
so
today,
can
you
see
my
screen
now
not.
C
Yet
here
do
you
just
want
to
present
the
the
document.
B
B
And
this
is
the
background
to
save
some
time.
I
will
give
A
Brief
Review,
and
the
first
is
that
we
have
POC
for
the
versus
Eternal
that
switch
from
borrowing
SSL
to
open
SSL.
This
is
our
internal
POC.
We
have
some
requirements,
so
we
found
that
there's
no
significant
gap
between
the
two
open,
accessor
and
two
levers.
B
So
and-
and
we
see
there
is
already
a
issue
in
the
backlog
in
of
Russia
tunnel,
so
so
we're
proposing
this,
our
our
POC
to
the
community
for
your
review
and,
let's
see
what
were
going
on-
and
this
is
an
open
SSL
review,
I
I
I
think
I
have
I,
have
put
some
links
in
in
this
document.
You
can
see
the
data
that
algorithm
and
the
example
for
Open
Access
are.
B
The
one
thing
I
want
to
mention
is
that,
since
that
open
SSS
without
one
which
is
released,
this
month's
open
SSL
has
started
to
spot
the
ABS
ABX
instructions
which
will
help
the
performance,
increasement
and
there's.
One
comment
in
the
issue
is
that
open
accessor
currently
doesn't
support
the
quick
and
from
the
roadmap.
It
is
expected
to
have
its
first
implementation
in
the
upcoming
version,
which
is
supposed
to
suppose
the
six
weeks
later
and
open
SSL
3.0
is
a
fifth
component.
B
We
have
a
version
for
that,
and
this
diagram
is
currently
the
how
the
rest
is
eternal
use,
the
borrowing
SSL
and
you
can
see
the
volumes
and
the
libraries
are
all
focused
from
the
open,
SSL
libraries,
and
we
don't
see
there
is
so
many
difference
between
the
library
families
so
and
from
our
practice.
We
see
migrate
from
foreign.
A
Is
yeah
before
you
move
forward
I?
Think
John
Howard
has
a
question
here
so
John
please
go
ahead.
E
D
Want
to
get
some
clarity
Easter
today,
like
in
sidecar
mode,
we
don't
support
or
open
SSL.
Do
we
or
an
iron
mister.
B
Yeah
I,
don't
think
you
still
support
open,
SSO
right
right
now,
but
I
know
there
is
a
project
to
support
it
named
the
envoy,
open
SSL,
it's
ongoing.
D
B
B
Right
now
we
have
a
tos.ars
RS
and
a
boring
boring
model
as
its
sub
module
and
the
work
we
do
is
create
a
new
module
called
openss.rs
within
the
TLs
grid
and
add
the
necessary
open,
SSL
specific
code
code
within
the
open,
sensor.rs
module
and
to
support
the
TRS
functionality.
The
third
is
modified.
Existing
code
within
the
TLs
crate
to
detect
the
presence
of
the
open
SSL
and
the
use
instead
of
the
boring
SSR
module
will
appropriate
and
you
can
see
here
is
the
the
boring
SS
module.
B
B
So
here
in
the
trs.rs
here
we
can.
The
real
implementation
can
be
selected
by
using
the
configure
feature,
the
attribute
as
shown
below.
If
we
we
use
the
feature
boring,
we
will
select
the
borrowing,
module
and
use
the
borrowing
SSL
crates,
and
if
we
select
open
SSL,
we
will
build
the
open
sensor
module
and
using
the
open
apis
in
the
open
SSL.
B
So
this
is
the
quite
simple
and
the
the
two
here
here
is
the
feature
attribute.
We
can
we
choose
to
use
in
the
cargo
build
command.
If
we
choose
open
SSL,
we
will
build.
We
will
build
two
images,
one
for
boring,
SSO
and
the
other
one
for
the
open
SSL.
B
So
so
we
must
expose
the
same,
create
apis
to
the
user
code.
If
we
have
two
two
different
libraries
and
and
when
Nintendo
needs
to
reference
a
TRS
tag
or
invoke
a
TRS
method.
It
can
use
this
this
as
usual
and
use
the
TLs
script
and
something
something
was
exposed
by
by
these
two
independent
modules,
and
this
part
I
will
introduce
the
some
example
for
how
to
use
the
POS
create
apis
at
the
bottom
of
this.
This
section
I,
have
this
list:
I
have
a
list
for
all
the
user
code
in
reference.
B
B
The
error
is
referenced,
the
Tokyo
boring
handshake
error
and
with
our
modification
it
will
change
to
and
use
the
use,
create,
create
TLS,
handshake
Arrow,
and
this
is
the
handshake
error
defined
by
by
the
this
TLS
crate,
and
it
will
be
implemented
by
either
Point
RS
or
open,
open,
SS
or
is
so.
This
is
the
real
implementation
in
the
boring
RS.
It
will
reference
to
the
real
talk,
real
borrowing,
libraries,
the
Tokyo,
boring
handshake
error.
This
is
just
a
reference,
but
this
is
a
example
case.
B
So
in
the
open,
SS
libraries,
we
cannot
find
equally
handshake
error
type
directly
defined
in
the
open,
accessor
Library
families.
B
So
we
we
Define
our
own
handshake
error
for
it
to
to
implement
the
the
to
express
the
same
meaning
for
the
handseek
errors,
so
that
we
make
this
for
a
typical
example
for
the
type
reference-
and
here
is
the
invocation
example
basically
similar
to
the
reference
example-
and
you
can
see
the
current
code
in
outbound.rs,
Connect
TOS
is
referenced
as
the
Tokyo
Tokyo
boring
connect
and
in
the
new
code
it
will
goes
to
create
TRS
connect
here,
so
that
connect
will
be
implemented
either
by
Boring
is
or
the
open
rs.mod.is.
B
We
have
Implement
a
connect
in
our
open,
SSL
module.
This
is
the
implementation.
We
will
use
the
Tokyo
open
SSL,
so
basically,
we
we
our
work
is
to
implement
independent
implementation,
comparing
to
the
Align,
which
is
aligned
to
the
boring
SSM
module.
B
Here
is
a
change
list
I
mentioned
before,
where
the
the
user
code
in
the
outbound
or
proxy,
using
the
SSL
libraries
here
is
a
change
list
not
too
much,
and
this
section
I
will
go
to
the
building
and
the
deployment
I
wish
I
have
already
covered
in
in
previous
sections,
and
we
just
use
these
these
features
to
to
control
the
building.
B
If
we
build
want
to
build
our
open
ancestor
or
run
or
open
accessor,
we
will
add
the
features,
open,
SSL
and
and
and
disable
the
online
sensorflips,
which
is
a
default
feature
and
I
want
to
mention
what
I
want
to
mention
is
that
the
open
sensor
can
either
be
statically
linked
or
that
or
dynamically
linked
to
the
open
sensor.so
installed
on
the
host
container.
So
this
may
leave
us
choice.
B
We
can
upload
our
binary,
which
is
a
free
component
binary
into
the
the
tunnel
code
base
which,
like
the
what
kind
we
do
do
it
to
in
the
Border
SSL,
and
we
can.
We
can
also
choose
to
upload
the
the
component,
the
opensser.so
into
the
running
environment,
into
our
container
image
based
image.
C
That
is
so
I'm
just
a
little
concerned
with
all
the
conditional
logic
that
this
is
going
to
require
I.
Think
it's
going
to
add
a
lot
of
complexity
to
the
code.
The
way
it
is
especially
that
it's
kind
of
merged
into
the
same
crate
as
the
boring
provider,
I
I,
think
I
I
think
to
do
this
I
think
we
would
actually
want
to
separate
it
out
and
to
have
two
separate
crates
and
then
whatever
is
using.
C
It
would
just
pick
it
pick,
the
crate
that
they
want
to
use
and
then
and
then
we'll
have
to
Define
some
sort
of
like
you
know
trait
or
something.
If
you
specify
a
provider
because
we
don't,
we
don't
want
the
rest
of
the
code
to
even
know
or
care.
C
We
really
just
want
the
whoever
whoever's
bootstrapping
the
application
to
to
make
a
cognitive
choice
to
say:
I
want
to
compile
in
this
provider
and
use
that
explicitly
of
I.
Don't
know
who's
next
I
think
I.
Think.
D
Ben
Ben
was
next,
but
I
was
responding
to
you
specifically
so
I'll
cut
the
line,
if
you
don't
mind
so
I
I
agree
the
rest
of
the
code
shouldn't
care
about
what
the
back
end
is.
It
should
be
abstracted
Linker
de
does
this
with
boring,
SSL
and
Russ
TLS,
and
they
have
I
posted
a
link
on
the
meeting
notes
which
abstracts
US
I
think
it
does
add
some
complexity,
still
abstraction,
isn't
free,
but
I
think
it
can
be
done
better
than
we
are
are
proposing
here
along
those
lines.
C
Along
those
lines,
the
Quinn
Library,
also
kind
of
like
defines
their
own
kind
of
like
provider,
API
and
and
I've
actually
just
built
out
support
for
boring
SSL
with
the
Quinn
Library,
which
is
which
is
the
the
main
rust
quick
implementation.
B
C
Yeah,
for
the
most
part,
I
I
would
just
say
that
it
wouldn't
be
a
next
step.
It
like
this
code,
won't
land
in
this
state
that
that's
I
think
that's
my
main
point.
B
F
F
What's
the
objective,
it's
not
clear
if
we
want
to
support
parallel
implementations,
because
there
are
features
that
are
in
one
and
not
the
other
or
if
boring
and
the
rust
bindings
we're
using
are
just
kind
of
a
pain
in
the
ass
to
work
with
because
I
know
like
Nate,
you
up
you've
tried
to
Upstream
some
stuff
to
the
cloudflare
boring
bindings
and
like
they
haven't
merged
anything
since
last
year.
F
Right
and
it's
that
there
are
things
that
we
need
to
do
that
we
can't
do
and
we're
block
live
stream,
because
the
rust
bindings
for
boring
that
we're
using
are
not
very
good
and
or
I've
seen,
is
not
responsive.
To
me.
That's
like
the
bigger
problem.
I,
don't
really
care
what
we
pick
for
the
crypto
Library
as
long
as
it's
standardized
relatively,
has
good
bindings
and
or
responsive
upstream
and
supports
fips.
F
So,
like
I
guess,
the
question
is
like:
is
that
a
problem
with
the
fact
that
we
picked
something
the
bindings
we
have
are
not
very
good,
and
so
we
want
to
do
another
implementation
because
we're
stuck
on
those
bindings
or
is
it
actually?
We
need
to
support
multiple
conditions
or,
like
John,
was
saying,
maybe
just
rust
TLS
like
do.
We
need
the
abstraction
to
support
multiple
or
do
we
need
to
pick
a
better
library
with
better
bindings?
Like
that's
kind
of
my
question,
it's
not
clear
to
me
which
of
those
two
things
it
is
yeah.
C
Big
plus
one
to
that
I
would
like
this
document
to
kind
of
clearly
Express.
Why
and
and
follow
up
to
the
Rusty
LS
thing
I
I,
think
Rusty
LS
is
the
right
path
and
there's
there's
actually
some
noise
in
the
rusty
LS
community
of
actually
kind
of
like
abstracting
out
the
crypto
and
allowing
that
to
be
provided
by
the
platform
so
that
that's
actually
a
direction.
Rusty
LS
is
headed
anyway,
so
yeah
this
just
something
to
be
aware
of
yeah.
D
Big
plus
one
of
that
one
question
I
have
for
the
people
are
proposing
this:
do
you
need
the
open,
SSL
crypto,
or
do
you
need
the
entire
openssl
TLS
stack,
because
what
Nate
was
proposing
and
I'll
also
answer
one's
question,
which
is,
is
rustbip's
compliance,
there's
actually
two
aspects
of
these
TLS
libraries
there's
there's
the
crypto
layer,
which
is
the
part
that
fifth
certifies.
That's
like
all
like
the
lower
level
crypto.
D
That's
the
fips
part,
so
there's
boring
crypto
I,
assume,
there's
some
open,
SSL,
crypto
I,
don't
know
what
they
call
it
in
Rusty
LS.
They
have
this
thing
called
ring,
which
is
the
kind
of
their
implementation.
So
it's
actually
that
lower
level.
That
is
the
fit
certified
thing
now.
What
rest
TLS
is
looking
to
do
is
abstract
over
the
crypto,
so
they
would
support
boring
crypto,
for
example,
which
could
be
the
certified
more
in
crypto,
but
then
still
use
the
rust,
TLS
TLS
library.
D
B
D
B
My
requirement,
my
requirement,
is
using
the
open,
SSL,
so
I
I
I
agree
with
it
that
we
can
also
pick
the
the
rust
TLS
and
I
think
we
were
going
forward
to
support
multiple
libraries
like
like
the
rust
TOS.
This
is
our
plan.
Yeah.
H
H
A
Yeah,
so,
basically
from
Intel
side,
the
reason
we
want
to
propose
open
SSL
here
is
open
access.
Sl
has
a
good
integration
with
Hardware
accelerators,
like
the
what
coffee
mentioned,
the
evx
512
and
our,
for
example,
quick
assistance
technology.
All
these
Hardware
drivers
has
already
been
opened
as
a
library.
So
this
is
the
background
motivation
for
this
from
just
the
previous
discussion.
A
I
think
I
got
the
two
pounds
here
when
suggestion
is
whether
we
can
utilize
TRS
as
injection
layer
and
make
just
make
part
of
the
Open
Access
library
to
imp,
to
I
mean
to
do
the
crypto
functions
here.
This
is
the
suggestion
right,
and
maybe
we
can.
We
can
predomination
points
is
to
skip
current
step
and
go
forward
with
the
next
step
directly.
Foreign.
F
Yeah
I
think
that
is
right.
Ideal
World
is
Rusty,
LS
supports
plugable
back-ends,
which
open
SSL
is
one
and
we
just
use
rust
TLS.
That
would
be
the
ideal
world.
C
And
that'll
that'll,
probably
unfortunately
take
a
bit
for
that
to
lend
yeah
to
have
our
own
provider
kind
of
API
for
the
for
the
time
being,.
D
C
A
It
lacks
all
this
acceleration
capabilities,
but
Open
Access
has
had
this
capability
and
also
it
has
the
fixed
compliance
version
and
from
the
custom
game
engagement
from
our
site.
A
lot
of
customers
are
actually
on
demanding,
open,
SSL.
So.
D
A
Yeah
from
communities
perspective
internet,
it
might
not
too
urgent,
but
I
think
it
will
be
a
a
great
add-on
feature
for
the
end
users,
because
they
have
the
flexibility
to
choose.
The
underlying
crypto
libraries
here.
C
So
Iris
I
I,
think
I
think
before
we
push
on
this
any
further
I
think
it
would
be
great
if
your
team
would
kind
of
engage
with
Rusty
LS
and
see
the
state
of
their
their
push
towards
externalizing,
crypto
and,
and
all
that,
and
you
know,
see
see
if
we
can
kind
of
figure
out
what
that
roadmap
is
and
and
kind
of,
like
you
know,
kind
of
set
the
context
with
respect
to
this
document
and
and
maybe
revisit
after
we
have
more
information.
Does
that
sound,
reasonable.
A
So
yeah
one
question
here
is
current:
is
foreign.
C
Is
not
trips
compliant
and
they
really
financially
don't
seem
to
have
any
desire
to
do
it,
but
but
what
they
do
want
to
do
is
is
the
externalization
of
crypto,
so
they
could
externalize
crypto
to
something
that
is
subscribe.
A
Okay,
so
so
I
think
my
question
is
why
we
we
need
to
stick
our
last
Tails.
If
I
mean,
if
we
can
go
with
the
next
step
directly
I
mean
provide
abstraction
layer
in
the
velocity
tunnel,
and
the
game
will
use
the
flexibility.
It
should
be
turned
offices
and
the
bonus
SL,
and
this
also
suitable
approach
for
the
community.
So.
D
Yeah,
so
my
concern
is
that
Z
tunnel
has
been
ex
one
of
our
exclusive
design.
Goals
is
not
flexibility,
it's
actually
simplicity
and
those
are
in
Conflict
right
all
pretty
much
all
the
time,
and
we
have
very
intentionally
chosen
Simplicity
over
sensibility
and
flexibility
at
every
point
of
the
project.
So
there's
a
pretty
high
bar
to
add
more
flexibility
at
the
cost
of
complexity,
we've
actually
denied
other
PR's
doing
the
same
thing
that
were
kind
of
introducing
complexity
to
the
code
base.
D
That
does
not
help
default
users
right
like
this
change,
has
absolutely
no
impact
on
an
open
source
standard,
istio
user,
because
we
would
never
ship
a
build
with
the
open
SSL
feature
enabled
right.
It
adds
complexity
only
for
this
flexibility,
which
is
something
we
kind
of
push
back
against.
Now.
If
we
move
that
flexibility
externalize
it
into
rest
TLS,
then
it's
not
that
much
overhead
for
us
and
I
think
the
bar.
D
You
know
the
the
ability
to
accept
is
far
easier
right,
like
in
general,
it's
not
really
an
istio
or
zetan
with
a
Civic
concern
to
want
to
abstract
over
TLS
libraries
right.
That's
a
pretty
General
rest
Community
concern
and
it's
not
an
easy
problem.
I
think
it's
something
that
is
best
solved
by
other
projects
that
we
then
just
rely
on.
Instead
of
inheriting
all
that
complexity
ourselves
and
on
the
other
side,
I
believe
in
Envoy
as
well.
D
They
in
many
ways
push
the
complexity
out
as
well,
because
I
think
they
have
a
boring
SSL
shift
for
open
SSL.
So
as
far
as
I
know
and
I
could
be
very
wrong
here.
This
is
like
10
minutes
of
reading.
They
don't
actually
have
open,
SSL,
libraries
directly
and
Envoy
code.
The
envoy
openssl
Fork
thing
has
a
shim
that
translates
it
into
the
envoy
mode,
so
the
complexity
actually
doesn't
live
in
Envoy.
But
here
we're
talking
about
putting
all
the
SSL
complexity
directly
into
Z
tunnel.
H
So
it
could
be
a
similar
model.
After
with
SEO
I
mean
it's
something
worth
looking
into.
A
I
E
I
Tiny
comment
alternative
to
to
what
was
discussed.
Maybe
I
think
it
would
be
very
useful
if,
if
zidane
was
restructured
as
a
library
move
more
meaning
that
it
can
be
used
from
other
crates.
And
you
know
if
someone
wants
to
you
to
reuse
a
protocol
or
whatever,
and
then
any
vendor
can
have
a
different
means
that
may
link
different,
open,
SSL
or
whatever
I.
Don't
think
I
mean
there's
a
definition
on
the
encryption
or
can
be,
can
be
kind
of
contained.
A
Pause
at
the
application
layer
here
then,
in
one
side
we
can
reduce
the
complexity
complexity
for
the
Johnson
City
Tunnel.
For
the
other
way
we
can
allow
the
under
users
to
plug
in
their
own
crypto
libraries.
I
Yeah
no,
but
the
other
way
around
I
mean
yes,
okay,
the
abstraction
is
necessary,
so
we
need
to
be
able
to
plug
whatever,
but
if
not
necessarily
as
optional
or
you
know,
build
options
or
complexity
in
in
the
tunnel
itself,
but
actually
simplifying
the
tunnel
to
be
a
library
and
then
doing
whatever
you
want
in
in
so
have
the
abstraction.
But
if
you
want
to
plug
in
open
FSL,
you
just
have
your
own
main
edit.
Whatever
you
want
in
the
name.
A
Okay,
so
from
the
animal
part
I
see,
there
are
more
open,
SSR
report
here,
so
this
might
be
an
option
for
data
noise,
zero.
We
might
have
a
separate
report
to
do
the
open,
SSM
work.
This
might
be
a
direction,
then
the
other
part
is
the
last
TRS
part.
We
can
do
some
investigation
here
to
see
the
possibility,
but
it
seems
a
lot
of
gaps
here,
because
it's
not
supported
yet
in
in
advanced
the
tunnel,
then
the
other
direction
is
the
average
detection
layer
in
the
tunnel
itself.
A
So
we
will
consume
our
comments
here
and
maybe
revise
our
profile
and
get
data
reviewed
again.
C
Just
real
quick
I
posted
a
couple
links
that
are
relevant
to
the
rust
TLS
discussion
with
respect
to
supporting
other
crypto
providers.
So
if
you're
interested
take
a
look.
B
H
H
J
Yeah,
just
a
quick
question:
I
was
just
wondering
what
is
our
Cadence
for
these
Alpha
bills
for
ambient,
so
I
thought
that
we
made
like
a
1.18
Alpha,
but
we
only
made
one
and
then
the
sdo
1.18
is
going
to
be
soon
so
then
I
guess
there'll
be
a
beta,
but
is
there
a
plan
to
make
more
Alphas,
or
is
it
just
to
have
the
one
alpha
is.
J
D
In
yeah
so
good
question
the
typical
Cadence,
which
has
nothing
to
do
with
ambient
it's
just
how
we're
supposed
to
always
do
releases
is
roughly
every
two
to
three
weeks.
We
ship
in
Alpha,
we
historically
haven't
really
done
that
once
we
cut
the
branch
on
it's
supposed
to
transition
to
being
betas
we're
supposed
to
cut
the
brand
on
April
11th,
so
we
could
ship
beta.0
and
time
for
kubecon
and
kind
of
pin
that
as
the
cubecon
release
so
to
speak.
D
H
H
Problem
with
with
the
alpha
build
Andrew
is
last
time,
I
think
we
spent
like
three
or
four
builds
John
Craig
and
that
whole
process
took
a
week.
So
I
don't
know
if,
if
this
not
sufficient
changes,
I
don't
know
if
it's
worse
being
another
build
or
if
we
have
resources
to
test
all
those
fields.
E
Yeah
I
was
going
to
say,
I
think
there's
two
issues,
this
sort
of
one
is,
you
know
if
we
build
an
alpha,
we
we
should
test
it
before
we
publish
it,
which
is
where
we
ran
into
issues
last
time,
but
I
think
the
issue
Andrea
and
correct
me
if
I'm,
wrong,
Andrea
I,
think
that
the
issue
she's
talking
about
and
and
why
we
might
want
to
potentially
send
another
one
is
he's
doing
some
experimenting
with
ambient,
specifically
I,
think
on
IKS
and
we're
noting
differences
in
Behavior.
E
I
Yeah
I
agree
with
the
with
this
I
mean
if
there's
any
bugs,
that
was
fixed,
that
one
platform
will
needs,
then
absolutely
we
need
to
cut
it
because
we
want
to
have
as
many
users
as
possible
testing
it
out
so,
and
I
also
did
some
testing
with
with
installing,
with
Helm
and
and
the
other
option.
I
It
may
be
useful,
at
least
to
update
the
documentation
and
include
the
helm,
update,
help,
install
options
and,
and
how
to
you
know,
what's
the
proper
way
to
to
install
it
with
kalinko
and
so
forth,
to
make
it
a
bit
more
more
clear
in
the
blocks.
If
we
don't
do
release
the
other
point,
I
want
to
to
make
we
discussed
before
about
making
new
mistakes
and
not
repeating
the
old
ones.
I
It
may
be
worth
you
know,
considering
having
Z
tunnel
separate
from
istio
the
as
a
release,
scandals
in
general,
not
not
for
cubecon
but
but
moving
forward
because
they
are
supposed
to
be
decoupled
and
they're
supposed
to
be
usable
independently
of
each
other.
That
sets
my.
H
H
A
J
I
J
So
I
use
the
iptable,
Calico
and
and
but
with
the
ambient
EVPs.
J
Know
yeah
so
well,
but
it
needs
to
be
the
master.
There
was
a
fix
that
went
in
after
the
alpha,
but
and
then
I
had
some
problem
with
Master
like
a
few
days
ago,
but
now
Master
seems
okay,
so
I
was
like
if
we
could
just
get
one
master
or
one
more
cut,
then
that'd
be
more
official,
but
I
can
just
keep
the
tag
that
I
have
from
the
master
build.
That
was
working
with
you
to
just
continue
my
testing,
but
it
would
be
nice
to
have
the
alphabet.
J
I
H
J
H
I
Use
the
different
port
also
breaks
most
of
the
air
policies
anyway,
so
we
need
to
have
a
discussion
about
how
we
deal
with
network
policies.
What
do
you
open
the
discussion?
Because
it
depends
a
few
times,
but
I
don't
think
we
should
document
it
very
clear
that
no
network
policy
should
be
expected
to
work
with
when,
when
you
know
this
ambient
KC
news,
even
for
classic
istio.
I
If
it's
too
much,
would
it
make
sense
to
have
an
option
enable
or
cni
equal
Calico
in
the
install,
because
there
are
a
couple
of
options
that
need
to
go
together
and
I
was
also
thinking
towards
The
annotation
by
default
in
in
the
Z
tunnel.
I
Yeah,
the
Eternal
setup
instructions
involve
a
step
where
you
put
some
annotation
and
support
the
both
IPS.
If
you
want
to
rewrite
the
source
address,
and
it's
pretty
confusing
I
mean
it
took
me
a
while
and
some
help
from
John
to
actually
even
know
that
that
step
is
required.
But
we
can,
you
know,
put
it
in
in
the
helm
chart
directly,
so
it
doesn't
have
to
be
done
manually
by
the
user.
A
E
I
Was
quite
a
discovery,
I
was
thinking
to
put,
you
know,
basically
have
an
option,
there's
a
health
chart
and
put
move
the
Rhythm
in
the
notice
since
and.
I
A
G
All
right
sounds
like
we
have
a
plan
Andre.
Would
this
work
for
you
yeah
all
right,
I
think
we
can
move
to
the
next
topic
kiss.
If
you
are
here.
K
Yeah,
so
this
is
a
topic
still
kind
of
following
up
on
the
safe
mode
plans.
For
most
of
the
time,
I've
heard
we're
talking
about
Ambience
kind
of
been
grouped
together
as
a
feature.
No
ambient
itself
is
Alpha,
but
I
wanted
to
start
getting
people's
thoughts
and
getting
people
thinking
about
how
we
might
start
considering
Futures
within
ambient
and
breaking
that
down
and
having
more
isolated,
a
more
separate
feature
stages
per
things
in
the
ambient.
K
So,
for
example,
I'm
blocking
an
example
right
now,
but
as
as
new
features
in
ambient
come
out,
you
know
tags
or
certain
topologies,
like
a
like
a
sandwich
or
Z10
sidecar
Z
tunnel.
K
All
these
various
things
we
probably
are
going
to
want
to
have
some
delineated
support
within
like
the
ambient
category.
So
my
question
is:
you
know
for
long-term
ambient
supportability.
What
do
we
think
that
that
point
is
we're
going
to
stop
considering
ambient
as
a
whole
having
a
certain
feature,
status
and
start
kind
of
breaking
out
things
in
the
deployment
model
to
have
different
support.
D
I
would
think
that
once
any
portion
of
it
has
a
different
stability,
then
it
makes
sense.
I
mean
we
could
do
it
now,
but
it's
kind
of,
like
you
say,
here's
these
10
aspects
of
ambient
they're
all
Alpha.
It's
definitely
that
much
value
right,
but
once
we
you
know
say,
oh
ambient
base
is
out
or
is
beta,
but
XYZ
Alpha.
That's
that's
fine!.
D
K
Okay,
got
it
sorry,
go
ahead,
costume.
I
No
I
mean
we
discuss
this
in
a
few
weeks
ago.
I
think
we
need
to
just
differentiate
between
the
API
surface
and
actual
teachers
that
happened
to
work.
I
mean
topologies
other
single
kind
of
separate
from
API.
I
So
we
need
to
be
very
strict
and
very
clear
about
what
apis
can
be
used
and
what
the
apis
will
do
and
have
make
sure
we
have
testing,
and
especially
if
we
go
with
with
the
gamma
API
as
a
main
API
surface,
there
is
a
compatibility
test
in
implementation
of
gamma
will
have
the
same.
Api
will
work
the
same
way.
You
don't
care
how
it
works.
You
just
care
that
HTTP
routes
work
with
whatever
topologies
are
available
and
transform
user
perspective
and
from
vendors
perspective
you
have
different
choices.
I
You
can
support,
you,
know
multi-clustering
and
support
multinetic.
You
can
spot
whatever,
but
that
kind
of
an
expert-
and
you
know,
kind
of
Google
or
Microsoft
or
Amazon,
or
you
know,
kind
of
taking
care
of
things
for
their
platform
and
stabilizing
them,
testing
them
in
their
own
environment,
like
what
cni
provider
is
supported,
what
you
know,
maybe
cni
provider,
Calico
Works
in
some
vendor,
doesn't
work
in
another
okay.
K
Okay,
yeah-
that
makes
sense
to
me
well
as
far
as
kind
of
the
plans
for
for
safe
mode,
I
think
that
ambient
of
course
makes
sense
just
one
of
those
exceptions
where,
even
though
it
is
at
this
point,
it's
truly
Alpha.
But
it's
it's
something
that's
considered
to
be
the
future
for
for
istio.
So
we
want
to
encourage
users
to
to
use
it,
but
we'll
mix
space
kind
of
as
we're
drafting
up
the
the
process
here
for
more
granular
things
under
ambient
I.
K
Guess
a
follow-up
question
I
just
thought
about:
do
we
think
it
makes
sense
to
ever
Mark
all
of
anything
as
beta
or
gradually
gradually
graduate
things
to
Beta
within
the
ambient
category.
I
Just
quickly,
just
on
on
the
on
the
first
part
that
ambiente's
Alpha
well
safe
history,
Alpha
technically,
because
it's
just
brand
new,
it's
a
dock
right
now
so
I
think
it
I
kind
of
changed
my
mind
a
bit
about
so
maybe
we
can
have
safe
mode
alpha,
plus
ambient
Alpha
in
118
in
some
form
or
another
and
US
ambient
is
graduating
to
Beta.
I
We
also
graduate
safe
for
for
ambient
and
I
kind
of
I
changed
a
bit
more
in
my
mind
about
it
yourself,
I
see
it
as
control,
plane,
options
for
ambient
and
what
you
would
install
if
you
wanted
to
have
ambient
and
to
have
you
know
a
mix
of
ambient
and
sidecars,
but
with
same
semantics
and
same
defaults
and
and
kind
of
same
set
of
features
that
are
safe
and
because
again
filters,
for
example,
obviously
they're
not
supported
in
in
ambient.
I
K
Right,
that's
an
interesting
idea.
I
got
to
think
through
it
more
one.
One
thing,
though
you
mentioned
I,
don't
think
between
code
reads
and
everything
else:
I,
don't
think
we're
gonna
get
safe
mode
in
the
118,
so
probably
maybe
119
would
would
make
sense
for
that.
I
K
I
Get
a
dock
and
we
can
get
a
set
of
defaults
that
we
want-
and
we
can
have
at
least
of
if
you
want,
is
your
to
test
the
safer
mode
use
help
me
install
HDO
with
those
options
that
we
used
to
basically
I
mean
you
may
add
the
small
option
to
disable
to
change
the
defaults
to
to
have
kind
of
so
you
can
do
a
bit.
We
can
do
a
bit
to
get
give
people.
I
K
Sounds
good
Justin
go.
L
L
Ambient
is
available
as
a
data
plane
is
like
experimental
or
alpha
or
beta
whatever,
and
then
there's
the
feature
set
that
it
supports
within
that,
and
we
probably
should
be
teasing
those
apart
more
than
we've
spoken
about
in
the
past,
so
yeah
anyway,
I,
don't
think
I'm
saying
anything
new,
but
I
think
we
yeah,
but
I
think
we
should
I
think
that's
the
correct,
correct
password,
I
think
you're
you're,
highlighting
here
yeah
a
great
costume.
K
All
right,
yeah,
that's
that's
pretty
much
it
I
will.
My
goal
is
to
get
is
to
present
the
safe
mode
doc,
and
the
networking
group
meeting
had
to
fight
a
bunch
of
fires
this
past
week,
but
hopefully
we
can
I'll
have
some
custom
day
and
I'll
have
some
proposals
and
stuff
for
Ambience
within
that
and
talk
about
the
interactions
next
week.
But
thank
you
all.
K
C
All
righty
I
see
no
other
topics
on
the
agenda.
Does
anyone
have
anything
else
you'd
like
to
discuss.
A
One
thing
yeah,
but
I,
see
some
comments
added
to
our
proposal.
Yeah,
please
and
the
more
comments
here
and
then
we
can
analyze
it
because
some
of
my
team
members
are
in
different
time
zones.
So
we
need
to
consume
the
comments
here.
Thank
you.