►
From YouTube: Ambient Mesh WG Meeting 2023 02 22
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
All
right,
well,
John,
looks
like
you
have
the
first
few
items.
B
B
So
if
you're
using
the
Old
Branch,
don't
we're
not
going
to
accept
any
more
PRS
there?
No
more
changes
we'll
go
there.
The
code
is
like
99.9
the
same
between
the
two
at
this
point.
Unless
there's
been
more
peers
emerge.
Obviously,
so
it
shouldn't
be
too
hard
to
move
your
changes
over.
If
you
had
something
work
in
progress,
that's
that's
pretty
much
the
current
state
so
we're
going
to
Target
in
1.18,
which
is
what
the
next
year
we
saw
master
to
include
ambient
as
Alpha.
B
So
basically
that
gives
us
about
two
months
to
kind
of
you
know
improve
things
stabilize
things.
Why
not
before
we
go
Alpha,
the
intent
is
that
in
our
docs,
we're
going
to
make
it
very,
very,
very
clear
what
Alpha
means,
because
people
get
this
false
impression
that
Alpha
means
stable
and
istio.
B
We
mean
this
to
be
a
true
Alpha
like
we're
going
to
make
breaking
API
changes
after
1.18
I
believe.
So
that's
fine,
like
don't
worry
too
much
that
we're
going
to
be
stuck
with
whatever
decisions
we
make.
But
you
know
we
should
make
a
a
bit
more
of
an
effort
for
stability
than
than
experimental,
where
we,
you
know,
routinely
broken
things
and
whatnot.
B
Let's
see
what
else!
Oh
yeah,
so
four
for
that
as
well.
I
guess
this
kind
of
goes
into
the
next
one
as
well.
Some
of
the
things
I'd
like
to
see
done
in
maybe
the
next
two
or
three
weeks
before
1.18
is
to
get
a
dock
on
these
two
about
ambient
I
have
an
issue
I'll
link
it
on
there
once
I
find
it.
Oh
here
we
go
kind
of
what
I
think
like
the
general
outline
should
be.
B
It
would
be
great
if
we
can
get
people
to
pick
up
parts
of
that,
like
I,
think
it'll
be
multiple
pages,
so
we
can
kind
of
divide
and
conquer,
probably
and
then
I
think
it
would
be
great
to
get
like
a
1.18
output
build
which
we
can
do
at
any
time,
including
today.
If
we
wanted
just
so
I
mean
people
can
run
from
the
head
Branch.
B
But
people
like
to
use
official
gab
releases,
you
know
see
it
might
not
have
the
docs
so
I
think
that
will
be
good
to
get
early
feedback
before
we
even
launch
1.18
and
we
can
start
doing
some
marketing
noise
around
that
so
yeah,
that's
that's
kind
of
update
any
questions
or.
B
No
so
I
mean
technically
the
official
release
process.
Is
that
as
soon
as
right
now
we
could
start
doing
Alpha
releases
at
1.18,
so
I
mean
we
could
do
it
today.
But
you
know
this
until
we
have
docs.
It's
probably
maybe
should
probably
do
the
docs
first
but
I
think
once
we
have
the
docs,
which
I.
B
E
Oh
right,
sorry,
no
I'm,
just
using
the
wrong
word.
Are
we
we're
using
the
rust
Z
tunnel
in
in
this
Alpha
yeah,
so
that
will
also
be
an
alpha
release
effectively.
Yep
and
is
this?
Is
the
Z
tunnel
going
to
stay
in
its
own
repository?
Is
it
merging
into
istio
istio.
B
There's
no
there's
no
plans
yeah,
so
don
was
eternal
by
the
way
the
code's
fully
removed
and
everything.
So
it's
completely
dead.
So
there's
currently
no
plans
to
move
this
utensil
into
the
repo.
The
Easter
repo
is
part
of
this
I
saw
kawat
did
have
an
issue
kind
of
orthogonal
to
ambient
about
Envoy
that
the
proxy
itself
moving
into
the
repo.
If
we
do
that
and
solve
the
problems
there,
then
it
probably
also
makes
sense
to
do
Z
tunnel,
but
I
think
it's
not
something.
C
G
C
G
G
B
B
B
If
not,
and
anyone
wants
to
do
docs
contributions,
you
know
would
be
great
if
people
could
take
a
look
at
this
issue,
you
feel
free
to
assign
yourself
a
page
or
so
just
you
know,
two
weeks
or
whatever.
F
Yeah
I
have
yeah
I,
have
a
question.
Sorry,
everyone's
doing
snap.
On
the
update
on
status,
you
mentioned
about
Alpha
release
like
a
pre-alpha.
By
end
of
the
month,
I
mean
I
assume
there
could
have
been
multiple
pre-oper
because
I'm
just
a
sense
on
the
timeline
of
the
months,
which
is
like
a
few
days
from
where
we
are
where
we
are
now,
and
it
is
like
a
month
between
now
to
cubecon
one
plus
month,
I
assume
there
could
be
multiple
pre-alpha.
Then.
B
Yeah,
so
the
official
release
process
that
we
have,
which
we
don't
really
often
follow,
is
that
every
few
weeks,
starting
like
now,
we
start
shipping
Alpha,
zero,
Alpha,
One
Alpha,
two
alpha
three
and
then
once
we
cut
the
branch
they
become
beta,
0
beta,
1,
beta
2.
Whatever,
however,
we
want
to
release
and
then
once
we're
I
think
we're
ready
to
go.
We
release
release
candidate
zero
one
two
three
and
then
the
official
release.
B
So
the
short
answer
is
yes,
we
can
release
many.
We
often
don't
do
alpha
builds
just
because
I
don't
know
we
should
we
just
haven't
done
historically,
but
that
is
something
that's
definitely
officially.
The
process
actually.
F
A
We
do
have
118
release
manager
to
identified
it's
all
in
the
shade.
This
topic
I
have
now
brought
up
with
them
yet
because
this
is
I
heard
about
the
first
time
today.
G
A
So
John
I
think
we
can
take
a
saw
on
slack
and
discuss
it
with
the
release
managers.
B
To
make
sure
I
will
say,
part
of
the
alpha
release
is
actually
to
give
release
managers
a
chance
to
do
a
kind
of
run
of
the
process,
and
it
shouldn't
take
much
time.
We
don't
have
to
do
the
full
testing
on
output
releases.
So
it's
really
just
one
one
minus
PPR,
so
yeah,
but
we
will
make
sure
good
call.
E
I
have
a
question
about
how
this
will
work.
I
I've
heard
I've
seen
some
of
our
blog
posts
and
documents,
and
things
like
that.
Talk
about
effectively
hairpinning
traffic
from
the
Z
tunnel
to
the
Waypoint,
where
Z
tunnel
handles
decryption
and
then
Waypoint
just
does
the
lay
7
stuff
and
then
I've
heard
that
maybe
we're
changing
that
and
now
the
Waypoint
is
actually
more
active
in
the
h-bone
termination.
B
Yeah,
so
part
of
the
docs
plan
is
a
page
on
like
the
details
of
how
traffic
flows,
so
we
don't
have
it
yet,
but
I
do
have
it
in
my
head
at
least
describe
it
too,
if
you'd
like
or
we're
more
interested
in
just
making
sure
that
it
was
documented.
E
E
I
I
think
so
any
in
either
of
those
mods
Model
Z
tunnel
would
be
L4
only,
but
in
one
of
them
the
Waypoint
would
do
L4.
The
h-bone
termination
in
the
other
Z
tunnel
does
h-bone
termination,
and
that
has
implications
for
our
extensibility
with
waypoints
such
as
nginx
Etc.
B
So
I
think
the
plan,
unless
there's
some
confusion
about
the
sandwich
thing,
is
that
it's
always
been
that
both
do
H
bone
termination.
So
the
Waypoint
needs
to
terminate
it
so
that
it
can
read
the
inner
data
into
you,
know
all
the
L7
things
and
then
I
initiate
the
new
h-bone
connection
to
the
Z
tunnel,
who
also
terminates
it
to
pass
through.
B
C
Yeah
I
mean
we
should
support
both
language
and
and
terminating
depending
on
environment,
yeah.
B
To
clarify
on
sandwich
what
that
means
is
there
was
some
discussion
that
we
didn't
want
to
have.
H-Bone
code
have
to
live
in
Envoy
and
because
then
we
have
to
implement
in
two
places
and
so
that
we
would
have
the
Waypoint
basically
use
a
z
tunnel
so
that
it
doesn't
have
to
deal
with
like
a
normal
application.
Would
right
your
app
doesn't
do
each
bone.
It
just
uses
the
tunnel
on
the
Node,
so
it
would
actually
use
the
zetone
honest
node.
B
B
If
we
do
that,
so
that's
something
we
may
consider
long
term
as
an
optimization
or
change,
or
simplification
or
whatever,
and
something
that
may
be
useful
for
users
applications,
because
they
may
also
want
to
know
the
same
metadata.
But
it's
not
something.
That's
planned
in
the
short
term.
Sure.
G
C
So
that,
and
also
because
you
may
run
in
Hollywood
on
on
you
know,
outside
the
compare
outside
the
kubernetes
will
not
be
available.
But
again
all
modes
need
to
be
supported,
because
there
are
cases
where
there's
litana
functionality
may
be
pushed
to
the
networking
stock,
highly
optimize
it
without
any
involvement.
G
I
think
yeah
there's
a
there's,
a
separate
discussion
about
Envoy
and
weapon
and
trusted
Networks,
which
I
think
was
the
another
store,
so
I
I
don't
have
a
good
design
there.
So
I
think
the
protocol
between
Z
tunnel
and
Waypoint
depends
on
this
design
and
since
we
don't
have
a
design,
what
it
means
to
have
an
Envoy
on
Plain
text,
which
is
I,
don't
think
it's
the
right
time
to.
G
C
Sorry,
but
my
point
is
the
general
idea
of
ambient
was
that
you
know
the
encryption
should
be
part
of
the
to
the
ambient
basically,
and
we
want
to
keep
the
options
open
to
you
know,
maybe
that
design
that
I
proposed
with
a
different
design
to
move
the
encryption
functionality
down
to
to
Kernel
network
card
or
whatever
and
have
you
know
highly
optimized
version
of
ambient
where
possible.
C
So
what
I
want
to
make
sure
is
that
this
remains
possible
and,
of
course,
properties
which
is
another
thing
I'm
very
interested
in
so
so
we
should
never
assume
that
it's
it's
extensions
or
anything.
Nobody
should
make
assumptions
that
is
implemented
in
a
particular
way.
A
E
B
I
Just
just
kind
of
jumping
ahead,
though
it
like
the
the
terminology,
is
almost
relevant
to
this
discussion
as
well,
because
because
I
like
that
option,
three
looks
like
what
we're
talking
about
like
like
ambient
to
me,
should
be
the
definition
of
this
protocol
right
and
and
kind
of
a
clarifying
the
use
cases
and
and
the
whether
whether
it's
Envoy
in
as
a
waypoint
or
whether
it's
Z
tunnel.
As
a
you
know,
one
of
the
endpoints
is
kind
of
like
that's
an
implementation
detail.
I
I
B
B
What
ambient
means
and
we
can
expand
the
scope
to
what
Z10
lower
H
bone
or
waypoints
mean
if
we
need
to
but
I
think
the
biggest
confusion
so
far
I've
seen
is
what
is
ambient
mesh
I
put
a
10
minute
time
behalf,
because
I
think
we
can
talk
about
this
for
10
10
days.
Probably
if
we
need
more
time,
maybe
we
can
do
it
at
the
end
of
the
conversation.
I
don't
want
to
take
the
whole
meeting,
though
so
I'll
just
briefly
present.
What
I
thought
were
a
few
options.
B
There
could
be
other
ones
and
I,
don't
know
if
we're
gonna
come
to
consensus,
but
it
would
be
at
least
useful,
probably
to
get
people's
opinions,
and
then
we
can
try
and
distill
those
and
just
some
answer-
and
maybe
you
get
you
know
pitched
it
to
steering
committee
or
something
who
I
think
is
kind
of
in
charge
of
marketing
type
things
like
this
potentially
or
we'll
see.
I,
don't
know,
maybe
we'll
agree.
B
So
the
the
first
thing,
I
kind
of
thought,
was
okay,
like
ambient
is
the
fact
that
you
have
this
like
Waypoint
and
Z
tunnel,
new
architecture,
and
it's
not
sidecars
like
ambient
mesh
and
sidecar
mesh
operate
interoperate
together
they
can
communicate,
but
those
are
kind
of
two
separate
things
and
you
wouldn't
say,
like
I,
run
sidecar
list
in
my
or
sidecars
in
my
ambient
mesh,
because
the
ambient
is
the
lack
of
sidecars.
Basically,
the
other
one
would
be
like.
B
If
you
have
kind
of
Z
tunnel
or
any
of
this
new
ambientness,
then
it's
an
ambient
mesh.
So
even
if
you
have
sidecars
you're
still
an
ambient
mesh-
and
this
would
probably
be
something
that's
kind
of
temporary
like
long
term,
we
would
expect
everyone
to
have
this
probably
and
So.
Eventually,
this
just
becomes
istio
right.
It's
just
how
Easter
works.
You
have
sidecars,
you
have
Z
tunnels,
you
have
waypoints
they're
kind
of
all
there
together,
we
don't
really
have
a
name
for
the
new
stuff
and
the
sidecars
they're
just
kind
of
there.
B
Third
one
which
I
didn't
write.
So
let
me
refresh
my
memory.
Ambient
is
anything
using
H
phone
and
Gateway
slash
gamma,
these
sidecars
proxy
lists,
not
maybe
not
Z10
or
Easter
d,
okay,
yeah
I.
Think
that's
to
me.
That's
similar
to
to
option
two
I
mean
it's
a
bit
different
I!
Think
it's
more
refined,
but
it's
it's
still
somewhere
in
the
concept
that
the
ambient
is
kind
of
the
E
Studio
V2.
It's
not
this
segmented
section
of
your
cluster
that
isn't
using
sidecars
kind
of
if.
G
F
So
I
I
think
okay,
so
option
one
I
think
I
have
travels,
it's
it's
two
zetano
and
Waypoint
specific
and
that
we
also
have
this
ambient
profile,
which
is
the
future
of
the
HCL
and
I
suppose,
with
salsaika
and
cycat
right,
so
I
think
I'm
moaning
into
was
option.
Two.
The
only
trouble
I
have
with
option.
F
Two,
though,
is
any
mesh
with
Z
Tunnel
right
I
mean
I,
don't
have
to
use
C
tunnel
if
I'm
using
cycle
so
that
I
guess
that's
the
what
I
have
trouble
with
option
two
options.
Three,
though
I
think
it's
the
type
2
into
like
the
implementation
protocol,
which
we
used
for
Edge
phone
right.
What
if
one
day
we
decided
not
using
Edge
ball,
do
we
have
to
rename
this
thing
and
also
like
we
don't
necessarily
have
to
require
users
to
move
to
the
Gateway
API?
So
that's
the
other
concern
I
have
regarding
options.
Three.
I
I
C
C
But
if
I
hear
a
bit
means
everything
will
support
H1
plus
other
things.
I
should
say
it
doesn't
mean
that
everyone
must
use
okay,
it's
a
common
protocol
that
everyone
should
support
us,
a
fallback
and
that's
a
Common
Language,
and
they
may
use
additional
things
in
future
as
defined
by
different
implementation.
Handshake
negotiated
whatever
we
are
not
stuck
with
it
with
the
table.
Only.
E
So
I
think
that
these
three
options
come
down
to
well
and
maybe
there's
an
invisible
fourth
option
that
looks
like
is
being
discussed
by
others.
It
is
ambient
a
product
or
a
protocol
or
an
architecture.
E
If
it's
a
product,
that's
effectively
option
one
ambient
is
the
thing
that
istio
built
here.
You
can
have
it.
Anybody
who
builds
something
similar,
it's
not
istio-ambient,
but
it's
it
may
be
ambient
compatible
or
something
like
that.
If
it's,
if
it's
a
protocol,
we
any
ambient
is
anything
that
is
compatible.
That
speaks
the
same
protocol
with
the
same
apis.
E
Each
of
those
I
think
has
some
merits,
but
we
should
come
to
Clarity
on
them
and
I,
don't
know,
hopefully
looking
at
them.
That
way
helps
the
conversation.
I
So
so
architecture
is
part
of
it,
but
but
I
think
fundamentally,
if
we
want
other
vendors
to
be
able
to
cooperate
in
the
same
mesh,
it
comes
down
to
protocol
right.
I
So
we
we
have
to
have
the
protocol
as
the
fundamental
thing
that
that
ties
various
vendors
together,
so
yeah
architecture
is
great,
but
you
know
they
that
that's
just
the
deployment
model,
so
our
you
know
our
design
should
should
spell
out
the
the
protocol
and
then
Define
kind
of
spell
out
various
use
cases
or
various
deployment
models
where
you
know
and
and
how
the
protocol
Works
given
let's
say,
there's
a
waypoint
in
the
middle.
It's
direct
point
to
point:
it's
proxyless!
I
It's
you
know
all
those
things
should
be
spelled
out
in
the
architecture
based
on
the
protocol.
B
H
H
Sorry
go
ahead,
Keith,
okay,
thanks!
So
for
me,
I
can
kind
of
provide
a
bit
of
a
some
context
as
a
maintainer,
but
have
a
different
match
open
service
mesh.
You
know
when
the
ambient
announcement
came
out.
Was
it
last
September
I,
remember
the
the
two
things
that
stood
out
to
me
are
the
things
that
we're
talking
about
right
now:
the
architecture
as
far
as
node
level,
agent
for
encryption
and
the
protocol
biology
encryption
happened,
and
so
when
we
were
looking
as
far
as
conservative
we're
looking
at
okay.
H
What
are
the
options
for
something
sad
Pro
list,
because
of
course,
customers
were
asking
for
that
kind
of
functionality
and,
like
you
could
do
what
what
psyllium's
doing
what
Cilia
mesh
does
or
and
that
was
kind
of
all
that
existed.
You
could
do
something
like
ipsec.
You
know
wire
guard,
something
like
that.
H
That
was
state
of
the
art,
then
ambient
comes
through,
and
the
key
with
ambient
is
that
it
is
the
way
that
the
the
note
level
agent
that
we're
trying
to
stay
away
from
detail
here,
but
that
node
agent
is
doing
impersonation
and
retrieving
certificates
on
behalf
of
the
workloads
and
you
eliminate
the
Alp
and
hacks
that,
like
most
meshes,
have
to
do
in
order
to
identify
mesh
level
traffic
that
that
to
me
was
the
promise
of
the
ambient
model,
and
it's
why
I
started
becoming.
H
You
know
shrunk
these
meetings
discussing
because
the
Ambit
model
has
a
lot
of
potential
for
lots
of
other
vendors.
I
talked
to
you
know
a
guy
at
console.
They
see
that
some
of
that
same
the
same
views
in
that
case,
so
I
guess
what
I'm
trying
to
say
is
if
the
goal
of
ambient
a
bunch
of
discussions
happen
in
the
chat.
That's
really
good
about
this
name.
If
the
goal
of
ambient
is
to
be
something
that's
issue
specific,
then
this
is
kind
of
a
mooc
conversation.
H
But
you
know
you
know
I
remember
when
the
launch
happened
in
Jungle
shop
to
me
and
said:
would
love
for
other
vendors
using
H
film.
If
that
is
the
efforts
that
is,
is
being
discussed
here,
then
then
I
think
that's
some
combination
of
option
three
and
option.
Two
is
probably
the
most
at
the
scripture
where
you've
got
the
H
bone
protocol,
but
you
also
have
the
potential
for
I'm
not
super
tied
to
eat,
to
a
must
or
a
or.
G
H
Here,
but
the
possibility
of
that
that
encryption
happening
at
a
node
level,
agent
I,
think
that's
really
the
differentiator
between
the
existing.
You
know
pre
pre-ambi
announcements
and
what
ambient
please.
C
Yeah
I,
I,
completely
agree
and
I
think
at
least
to
me.
The
most
important
thing
in
ambient
is
interoperability
with
other
vendors
and
other
implementations,
the
ethio
classic
Eco
V1
is
you
can
only
talk
with
history,
one
you
are
on
mobile
and
you
are
completely
isolated.
You
cannot
talk
with
any
other
implementation
or
any
other
product.
C
Ambient
is
about
interrupt
means
that
your
compatible
to
GT
you
can
use
it
with
kubernetes.
You
are
compatible
with
other
implementation,
any
other
vendors
decide
to
support
similar
protocol
or
if
we
decide
to
also
add
additional
protocols,
then
we
we
can
we
can.
We
can
have
nginx
as
Waypoint.
We
can
have
Studio
mass
as
data
plane.
We
can
have
something
else,
as
you
know,
as
control
plane
and
and
all
of
this
will
work
together
and
and
interoperate
in
the
same
cluster
in
the
same
mesh.
So
I
would
put
interoperability
as
a
top.
C
I
Could
we
could
we
just
get
rid
of
the
name
ambient
all
together
and
effectively
say
H
bone
is
the
protocol,
and
this
is
going
to
be
istio.
V2
is
the
implementation
because,
because
that,
basically
rolls
into
combining
two
and
three,
as
other
folks
have
said,
I
think
Keith.
You
mentioned
it
where
you
know
you
know:
istio
is
just
a
vendor.
This
is
an
open
source
implementation
of
of
the
H1
protocol
that
supports
these
various
use
cases
or
deploying
models,
and
we
just
call
it
call
it
a
day.
I
At
that
point,
I'm,
not
sure
that
that
you
know
seeing
something
that
is,
is
ambient
really
I
I,
think
that
was
a
good
marketing
term
back
in
the
beginning
for
what
we
were
trying
to
achieve,
but
you
know
I
think
it's
just
it's
we're
kind
of
getting
into
that.
You
know
religious
kind
of
conversation
of
what
does
ambient
mean
to
you,
you
know,
and
it's
it's
becoming
kind
of
kind
of
confusing
to
everybody.
I
think.
D
So
I
think
that
makes
a
lot
of
sense.
I
mean
ambient
is
a
is
a
project
name
more
than
anything.
So
let's
I
mean
we
can
still
use
it
as
a
project
name
but
I
think
describing
the
topology
or
describing
the
architecture,
a
sidecar
lists
or
waypoints
here,
and
you
know
Z
tunnels
there
that
and
and
kind
of
keeping
it
I
wouldn't
use.
Istio
V2
personally,
but
I
mean
I.
Think
the
general
I
definitely
agree
with
generally
your
your
theme,
their
name.
I
D
But
I'm
not
sure,
that's
it
I
guess
that
I
mean
I.
Don't
really
have
a
problem
with
calling
it
is
cov2,
but
I'm
not
sure
that
I
agree
that
you
know
that
that'll
happen.
The
market
May
play
out
differently,
but
yeah
I
mean
I.
Don't
really
have
a
problem
with
cov2
if
it's
a
consensus
but
I
personally
wouldn't
have
used
it,
but
I
I,
like
the
rest
of
your
sentiment.
F
No
worries
so
I
I
think
you
know
we
certainly
generated
a
lot
of
Attraction
with
the
ambient
I.
Think
from
people
outside
of
the
issue
like
like
a
case
would
sing
right.
People
are
thinking
about
the
ambient,
it's
the
new,
no
proxy,
the
psychologist,
we're
introducing
without
sidecut
right,
and
we
can
still
promise
all
the
other
features
of
issue.
That's
how
people
think
about
ambient,
which
is
super
super
powerful,
so
I
don't
agree.
We
would
take
that
away
because
the
people
would
look
at
it.
F
Look
it's
your
project
doesn't
know
what
they
are
talking
about.
They
throw
this
ambient
now
they're
saying
you
know
ambient
is
nothing
so
I
I,
don't
agree.
We
should
take
that
away.
So
that's
number
one
number
two
I
think
everybody
understands
I
mean
is
the
future
of
istio,
whether
we
call
it
a
version.
Two
I'll
become.
You
know
the
mainstream
of
istio.
Is
it's
just
a
naming?
We
need
to
decide
but
I
think
people
agree.
That's
the
trend
and
direct
action.
J
But
the
truth
is
that
once
sidecars
move
to
H
bone,
then
technically
you
can
interrupt
with
sidecars
as
well.
So
the
protocol
has
nothing
to
do
with
ambient
right.
Ambient
is
a
deployment
model
inside
of
kubernetes,
so,
like
I,
think
that
we
should
maybe
try
and
figure
out
who
we're
aiming
towards
like
in
terms
of
because
I
agree,
it
is
sort
of
about
marketing,
but
I
think
that
the
protocol
is
not
actually
tied
directly
to
ambient
because
we
have
extended
it
to
sidecars.
J
I
But
I
I
don't
agree
or
disagree,
but
I
feel
like
we're
getting
back
into
the
you
know.
That's
what
ambient
means
to
you
and
I.
Don't
know
that
everybody
in
this
room
has
that
same
understanding
of
what
ambient
means
right
and
that
that's
fundamentally
the
problem.
It's
it's
an
extra
term
that
people
use
on
one
end
of
the
scale
or
the
other,
and
and
and
it's
it's
it's
we're
the
engineers
and
we
we
all
don't
agree
on
what
the
term
means
and
and
that's
a
problem.
I
B
Saying
we
should
do
this,
but
if
we
all
just
decided
okay,
it
doesn't
matter
what
everyone's
opinions
are.
This
is
the
definition
we
all
use
it.
Do
you
think
that's
efficient
or
do
people
care
enough
about
what
the
definition
is
that
it's
like?
Obviously,
we
need
to
take
into
account
people's
opinions,
but,
like
would
your
concerns
be
more
alleviated
if
we
just
mandated?
This
is
exactly
what
ambient
means
and
I'll
hit
you
on
the
head.
If
you
use
it
the
wrong
way
or
is
there
a.
I
I
I
What
is
what
is
this
versus
that
you
know
if
it's
not
immediately
obvious
right
like
it's
like
the
the
fact
that
we've
got
these
three
terms
is,
is
I,
I,
think,
fundamentally
the
problem
like
the
you
know,
there's
istio
and
so
the
product
I
guess,
if
you
want
to
call
it
that
and
and
then
the
protocol
and
then
what's
this
third
thing,
I,
don't
really
understand
the
third
thing
it
being
an
architecture,
it
just
seems
a
little
a
little
odd,
I
guess.
E
So
I
I
think
we
should
clarify
a
few
things.
We
discussed
it.
The
ambient
being
V2
of
the
istio
project
in
Toc
back
in
was
that
September
and
decided
that
that
was
not
a
direction
that
we
wanted
to
pursue,
particularly
because
sidecars
May
remain
around
indefinitely.
It's
not
clear
that
all
users
will
migrate
to
ambient
mode,
regardless
of
the
benefits
and
I'm,
not
sure
that
we
want
to
force
them
to
the
marketing
question
is
really
a
question
for
the
steering
committee
and
is
not
in
the
purview
of
of
this
meeting.
E
I
I
think
it's
valid.
What
costan
has
said.
We
need
a
word
for
how
to
be
interoperable
with
us.
I
don't
know
if
that
word
is
ambient.
Maybe
it's
a
different
word,
but
it
would
be
great
to
be
able
to
say
hey
if,
like
link
or
D
spun
up
this
thing.
It's
still
who
knows
what
architecture
who
knows
what
the
implementation
details
are,
but
it
can
run
alongside
istio
and
has
some
defined
interoperability
with
istio
when
it's
running
in
ambient
mode
or
maybe
when
it's
not.
E
We
need
a
word
to
describe
that
and
that
word
probably
once
we
come
up
with
it,
it
should
not
belong
to
us
we're
going
to
need
to
push
that
up
to
a
standards
body
that
can
say
here
is
this
word
meshes
can
comply
to
this
word
and
then
they
will
have
some
degree
of
cross
compatibility
with
one
another.
So
I
don't
know
that.
That's
the
word
ambient,
though.
I
If,
if
you
know
for
some
reason
steering
committee
comes
back,
comes
back
and
say
we
can't
lose
the
name
Ambien
then
maybe
h-bone
becomes
ambient
and
then
and
then
and
then
either
way,
we're
still
down
to
two
terms
and
I'm.
Happy.
E
The
other
thing
to
raise
is
there
was
a
great
comment:
I
want
to
call
out
from
Phil
in
the
thread
ambient
was
marketed
to
Consumers,
looking
to
remove
the
proliferation
of
sidecars
in
their
deployments.
Whatever
can
keep
the
theme
that
theme
of
understanding
will
keep
the
thought
consistent.
Ambient
is
very
much
something
we
we've
positioned
as
user
relevant.
C
Yeah
I
was
going
to
throw
almost
the
same
thing
about
you
know
there
is
the
simplification
part
of
HCL.
So
the
fact
that
you
can
you
don't
need
to
take
a
web
hook.
You
don't
need
right.
C
Credit,
simpler
is
whatever,
but
that's
that's
probably
good
for
marketing
point
of
view,
but
pragmatically
what
I
care
about
is
is
you
know
some
requirements
is
that
you
can
use
VM,
for
example,
and
on
the
end
of
it
you
have
cycle,
because
you
cannot
have
the
node
agent,
that
you
have
proxy
lists
and
implementations
that
Implement
natively
and
they
don't
need
either.
You
need
an
oversight
car
that
you
can
use
other
implementation,
except
the
Z
tunnel,
because
again
or
or
Envoy
for
for
the
waypoints
and
interoperability
I
mean.
C
E
So,
given
that
we
should
probably
put
together
a
document
for
both
the
ambient
term
as
well
and
I,
think
that
you
know
each
of
us
is
interested
potentially
in
eventually
offering
an
ambient
mesh
right
like
we're,
we're
all
trying
to
make
money
in
this
in
this.
This
is
not
charity
that
we're
doing
here.
In
these
meetings,
though,
it
is
open
source
so
defining
that
in
such
a
way
that
we
can
all
offer
an
ambient
mesh
of
some
variety
or
other
and
also
clearly
draw
a
line
around
what
isn't
an
ambient
mesh?
E
It's
not
the
same
thing,
but
it
is
somehow
compatible
and
has
some
sort
of
compatibility
guarantees.
My
guess
is
that
that
document
will
need
at
least
Toc
approval,
potentially
even
steering
because
it's
it
has
marketing
implications,
but
it
it
does
seem
like
that,
would
be
valuable
and
that
would
clarify
John
I
know
we're
going
to
start
working
on
docs
for
the
118
release
and
ambient
alpha
or
whatever.
E
We
want
to
call
that
it
would
be
good
to
have
that
Clarity
early
on
in
the
process,
so
that
our
docs
aren't
confusing
users
as
much
as
we
are
confused
today.
F
B
B
F
I
think
John,
you
summarized
the
discussion
really
well
from
what
I'm
hearing
from
different
people
on
the
car
sounds
like
people
are
okay
with
the
ambient
terminology
referring
to
running
without
sidecar
and
then
there's
additional
discussion.
We
need
to
have
about
interoperability,
for
whoever
willing
to
drive
that,
because
that
sounds
good
for
everybody.
F
B
Yeah
I
can
bring
this
up
steering
tomorrow
and
see
if
there's
opinions,
I,
don't
think
we're
going
to
get
as
Lively
discussion.
B
B
Yeah
we'll
get
some
feedback,
but
also
remember
steering
is
who
decided
Z10
on
it.
I
don't
know
who
likes
that
name,
but
no
just
kidding.
Okay,
that
was
a
joke.
I
was
in
that
meeting
too
so
I'm
to
blame.
Shall
we
move
on
any
last
comments
again
feel
free
to
add
to
the
doc?
Okay,
okay,
I
think
Mitch
you're
back
up.
E
Yeah,
so
we
talked
about
the
tag
API
proposal.
Last
week
we
recommended
that
we
talk
about
it
in
the
combined
working
group
meeting
to
get
input
on
sidecar
mode.
We
did
that
today
and
there
were
some
hesitations
around
security,
but
we
ended
that
conversation
with
John
and
custom
having
a
line
of
questioning
I,
don't
remember
who
was
asking
and
who
was
answering
but
I
asked
you
to
pause
it
because
I
thought
it'd
be
really
relevant
here
and
I
I
wonder
if
you
can
pick
that
back
up
now,
yeah.
C
I
think
General
was
asking
me:
how
would
we
we
do
it
in
ambient
without
without
dogs?
And
what
I
had
in
mind
is
pretty
clear:
I
mean
it's
updated,
independent
of
anything.
It's
you
know.
If
there's
not
a
problem
for
Waypoint,
we
want
to
remove
the
injection
and
I
think
that's
already
merged,
so
normally
there'll
be
no
web
hook
at
all
for
Waypoint,
and
we
want
Easter
D2
by
default.
Manage
the
the
the
Waypoint.
C
So
we
create
a
Gateway
is
the
current
ecod,
because
if
you
press
by
attack
that
doesn't
exist,
what's
going
to
happen,
it's
not
going
to
be
instantiated.
So
whatever
is
the
current
list,
your
D
is
going
to
activate
and
create
the
deployment
and
and
sidecar.
So
now
you
you
go
to
cicd,
you
go
to
whatever
and
you
push
a
new
version
of
his
qld
I.
Don't
know
what
will
happen.
I
mean
we'll
generate
you're
the
gradually
pick
up
and
start
managing
the
new
ones.
C
I,
don't
know
how
the
transition
will
happen,
but
presumably
the
code
will
drive
this
somehow
and
at
the
later
point
you
remove
the
old
version
of
his
theory.
That
was
at
the
normal
process.
So
then
we
don't
want
to
leave
some
waypoints
hanging
and
unmanaged
by
anyone.
So
somehow
the
implementation
of
uod
in
between
that
implementation
came
after
election
or
with
whatever
criteria
we
have
we'll
need
to
ensure
the
transition
somehow
automatically.
C
B
In
my
mind,
it's
the
same,
if
not
better
than
sidecars
like,
let's
say
you
initially
say:
okay,
the
it's.
The
revision
on
this
Gateway
is
V1
and
then
I
install
V2
right
and
to
move
it
I
would
go
re-label
the
namespace
or
the
the
Gateway
and
say
V2
and
in
sidecar
case
you
would
then
have
to
go
manually
redeploy
the
pod
in
Gateway
case
and
waypoints
Now.
Easter
D
will
do
that
for
you,
the
new
Easter
D.
The
V2
will
take
over
and
kind
of
re-update,
whatever
configs
needed
yeah,
but.
C
E
G
E
C
The
entire
division
was
based
on
the
idea
that
we
want
to
have
controlled,
rollout
and
and
to
follow
the
same
mechanism
that
users
use
for
certain
applications,
and
they
have
kind
of
is
a.
It
was
never
intended
to
be
an
API
and
exposed
to
Market
user
to
create
too
much
pain,
I
mean
the
whole
ethio
cuttle
said
talk
or
whatever
worth
more
kind
of.
You
know,
artifact
of
the
fact
we
didn't
have
time
to
do
something
better
and
the
completely
automate
the
migration
process
and
have
a
full
integration.
C
E
I
I,
like
the
idea
of
that
defaulting
that
you've
proposed
in
terms
of
a
full
CI
CD
solution
that
carries
out
the
migration
on
behalf
of
the
user.
I
think
that's
where
we
ought
to
be
encouraging
them
to
integrate
with
CI
CD
tools
and
making
sure
that
istio
integrates
with
that
tooling
well,
and
the
tag
API
is
exactly
oriented
around
that
today:
tags
suck
for
git,
Ops
and
generally
all
CI
CD
flows,
so
that
that's
why
an
API,
I
I,
do
think
a
crd
would
make
it
much
easier
for
those
users,
foreign.
B
C
Closing
API
to
the
user,
that
tells
user
that
first
of
all,
you
need
to
manage
it
and
and
to
set
attack,
and
then
it
gives
the
use
the
Impressions
that
they're
in
control
of
this
they
should
not
be
in
control.
The
the
tipdc
can
should
be
in
control
when
it
trolls
notice,
qod.
So.
B
C
D
C
I,
don't
think
it's
it's
something
that
but
I
don't
think
now
that
we
no
longer
have
injection,
we
no
longer
have
the
need
and
we
have
other
tools.
I
mean
eqd
has
ability
to
to
do
stuff.
Maybe
it's
implant
to
not
expose
it
to
user
in
any
form
and
keep
it
implementation
only,
and
you
would
have
proved
that
user
absolutely
needed.
C
E
F
C
No,
no,
no,
it
means
that
it's
still
revision
based,
but
revision
based
is
driven
by
study.
History
takes
care
of
of
moving
the
Waypoint
I
mean
taking
over
the
Waypoint.
F
C
F
It's
unless
it's
in
place,
if
it's
in
place,
I,
agree
I,
don't
need
to
know
I,
don't
want
you
now,
but
if
I'm
testing,
multiple
revision
I
need
to
tell
you
I'm
finishing
testing,
I'm,
confident
with
the
new
revision
right.
What's
how
am
I
going
to
tell
you
that
if
you
are
managing
this
automatically
for
me.
C
Yeah
I
think
with.
Currently
we
do
it
with
initiad,
at
least
with
with
the
master
election.
So
I
think
there
is
a
flag
with
your
desert
specifies
that
it's
I
don't
remember
how
it
was
implemented
and
because.
B
Yeah
but
I
think
what
we're
saying
now
is
that
all
of
your
waypoints
in
the
mesh
are
the
same
revision.
You
can't
say
that
in
the
canary
namespace,
I
use
the
canary
revision
and
can
kind
of
do
it
just
a
bit
before
I
roll
it
out
everywhere,
right,
yeah,
I
I
would
certainly
agree
that
most
users
should
need
to
modify
like
they
should
just
set
the
tag
to
default
or
stable
or
whatever
they
they
choose
to
name
it
and
not
have
to
think
about
it.
B
I'm
not
entirely
convinced
that
we
should
remove
the
ability
to
set
it
to
other
things,
so
they
can
kind
of
do
more.
Gradual
testing.
C
E
E
C
C
E
This
proposal
does
not
use
a
web
hook
for
ambient
mode.
As
for
the
traffic
shifting
between
two
versions
of
istio,
which
I
think
is
what
you
just
proposed,
that
would
be
great
for
which
control
plane
is
controlling
a
given
revision.
It
would
not
or
which,
let
me
be
more
specific,
which
control
plane
is
providing
XDS
to
a
particular
Waypoint.
It
would
not
help
us
with
which
controller
is
going
to
instantiate
that
Waypoint
and
what
version
of
the
Waypoint
are
we
going
to
instantiate,
because.
D
C
You
know
I
mean
in
the
Waypoint.
We
have
revision
history
of
revision
full
and
then,
if
your
D
has
is
watching
the
services
and
sees
that
the
service
called
ethiopu
with
that
is
selecting.
That
particular
is
the
audience
that
so
I
think
we
know
that
hey
I'm
in
charge
of
that
particular
Waypoint
I
can
take
it
over.
C
C
E
G
C
E
E
C
E
So
I
would
love
to
hear
Keith
and
John
weigh
in
on
that
I
I
didn't
think
that
we
should
be
creating
a
proliferation
of
Gateway
classes
or
allow
users
to
create
arbitrary
Gateway
classes
as
part
of
their
installation,
but
I'm
not
super
familiar
with
gamma
and
Gateway,
and
how
that's
all
going
so
I
would
love
other
input.
There.
H
So
the
user,
typically
does
not
I'll,
say
generally
does
not
create
Gateway
classes,
that
is,
the
Gateway
classes
are
provided
by
the
infrastructure
provider
cloud
provider.
The
controller
whichever
and
the
infrastructure
provider
basically
says
here
are
the
difference,
types
of
Gateway
academic
examples
of
load,
balancer
private.
What
was
public
right
custom
to
your
idea
about
having
the
get
a
class
representative
revisions?
H
One
thing
you
could
do
is
potentially,
when
you
install
into
sdod
that
scod
create
a
certain
revision,
that
is,
cod,
creates
a
Gateway
class
with
that
revision
and
then
the
waypoints
can
bind
to
whatever
provision
is
being
that
they
want
to
use
not
to
upgrades,
are
done,
and
then
it's
an
error
on
install.
If
you
try
to
create
a
a
Gateway
class
with
the
same
revision
that
already
exists,
so
I
think
that
would
actually
work.
John
I,
don't
know.
If
you
have
any
of
us
and
then
Lynn's
got
married.
E
And
my
concern
is
not
so
much
who
is
creating
the
Gateway
class
TRD
I
see
how
sdod
could
do
that
very
reasonably
and
already
is
going
to
do
that
at
install
time
effectively.
My
concern
is
more
around.
Should
we
allow
users
to
create
an
arbitrary
number
of
Gateway
classes
by
virtue
of
their
istio
installations.
C
E
C
F
Because
the
I
don't
see
us
putting
like
the
revision
information
in
the
Gateway
class
from
a
user
perspective
as
an
application
developer,
I
need
to
develop
I
need
to
deploy
my
Waypoint
proxy
right
and
to
in
order
for
me
to
deploy
my
Waypoint
proxy
I
need
to
develop
my
Gateway
resource,
which,
within
that
Gateway
resource
I,
need
to
refer
to
the
Gateway
class
and
I.
Don't
see
us
keep
changing
that
Gateway
class
because
the
fact
I'm
pointing
to
a
different
revision
right
so
early
on.
F
We
talk
about
the
default
revision,
which
is
the
most
common
scenario
in
it.
Still
right,
I.
Don't
expect
me
needing
to
change
my
Waypoint
Gateway
resource
moving
between
istio
versions
as
a
developer,
managing
you
know
owning
our
services
for
Instagram.
So
that's
why
I'm
against
putting
the
revision
in
the
Gateway
class.
F
But
look
attack
has
this
flexibility,
which
everybody
in
this
world
project
loves
to
to
help
with
the
default
default
right
everybody
loves
to
using
like
there
is
a
thing
called
default.
There
is
also
a
thing
you
can
use
like
a
attack
called
prod
attack
called
Canary
right.
So
a
lot
of
users
love
the
perspective
of
that.
But
Gateway
class
to
me
can
refer
to
like
specific
version
map
to
your
control
plane.
That's
providing
the
Gateway
class.
C
G
E
Think
I
can
explain
a
little
bit
here
and
get
everybody
on
the
same
page
while
I'm,
not
sure
I,
agree
with
Costa
and
I.
Think
I
can
help
people
understand
what
he's
saying
better.
We
wouldn't
be
replacing
revisions
into
Gateway
classes.
We
would
be
putting
Gateway
class
would
become
effectively
the
same
as
tag
so
a
Gateway
class
called
default
might
refer
to
a
revision
and
then
someday.
We
might
go
and
update
the
default
gateway
class
and
say
you
know
it
really
points
to
this
other
revision.
Now
and
now.
E
C
E
C
H
H
G
C
I'm
I'm,
probably
confused
here
more
than
everyone
else,
so
the
cluster
admin
infrastructure
and
mean
creates
tag
and
Gateway
classes
and
they
select
what
implementation
and
what
configs.
For
that
particular
infrastructure
pieces,
the
Waypoint
owner
can
choose
which
Gateway
class
to
use
that
apparent
of
those
Gateway
is
required
by
the
spec
and
would
also
specify
the
attack,
which
is
kind
of
doing
the
same
thing.
But
all
Gateway
class
and
tag
is
the
same
persona.
It's
an
infrastructure
providing
deciding
that
default
is
version.
1.15
and
and
Canada
is
version
116,
and
what
implementation
it
is.
E
So
I
I
think
the
thing
is
we
we
support
one
or
the
other
for
tags,
certainly
not
both.
So
if,
if
Gateway
class
is
effectively
tagged,
then
waypoints
don't
specify
any
revision,
we
don't
respect
that
label
in
them.
All
they
have
is
the
Gateway
class
selector.
However,
if
we
support
the
tag
API,
they
still
have
to
request
a
Gateway
class,
but
that
Gateway
class
will
be
static.
It
will
be
something
along
the
lines
of
istio
Waypoint
I.
We
we've
already
defined
what
it
is.
I,
don't
remember
what.
G
E
Is
the
Waypoint
Gateway
and
effectively
all
the
tags
are
a
subset
of
that?
It's
which,
which
type
which
one
of
the
istio
Waypoint
Gateway
types?
Would
you
like
to
select.
C
But
my
point
was:
Waypoint
is
not
necessarily
try
to
eat
your
D
or
if
to
itself
you
could
have
a
waypoint,
it's
perfectly
valid
to
deploy
engine
if
assuming
nginx
implementation,
protocol
and
Gamma
API,
which
they
do
I,
can
go
and
say.
Hey
I
want
to
use
nginx
from
Gateway
class,
because
internet
time
has
some
unique
features
that
I
need
and
it's
a
perfectly
valid
deployment
for
a
waypoint
I.
Don't
think
it's
required
to
be
tied
to
hit
your
D
or
each
implementation
or
anything
history.
E
So
I
I
think
what
you
mentioned
just
now
is
really
important
question
and
I
feel
a
little
bit
uncomfortable
about
it.
Given
some
of
the
design
changes
that
that
I
I
addressed
earlier
I
think
we
need
to
come
up
with
a
design
document
and
a
test
showing
my
nginx
Waypoint
Works
alongside
istio
ambient
I,
think
that's
a
super
important
use
case
that
we
need
to
preserve.
However,
the
the
value
of
a
design
dock
there
is
I'm,
not
clear.
Wouldn't
the
Gateway
class
of
an
nginx
Waypoint
be
nginx
yeah.
H
You
can't
expect
the
tagging
functionality
to
be
constant
between
two
different
implementations.
I.
Think!
That's
where
the
you
know
the
the
the
rub
is
the
the
tagging
from
Mitch's
design
in
the
current
way.
It's
is
an
issue
attacking
is
a
cluster
admin
Persona,
if
after
admins
says
here
are
the
tags
are
available,
Gateway
class
is
an
infra
provider.
Persona
which
aren't
the
same.
The
info
provider
would
be
either
your
cloud
provider
or
a
controller.
H
That's
that
is
installing
icod
like
on
during
that
operation,
but
the
tags
that
are
available
are
defined
by
the
cluster
operator.
The
person
with
admin
permission
to
Once
issue
is
installed.
I'm,
going
to
set
up
all
all
the
different
things
label
the
name
spaces
Etc.
There
was
a
mismatch
between
those
two
personas,
which
is
why
I'm
not
for
Gateway
class
having
a
package
functionality.
C
Yeah
I'm
not
sure,
I
see
the
distinction
that
wrongly
I
should
do
in
in
terms
of
persons.
I
mean
it
not
like
Google
cloud
is
providing
you
know,
gcp
providing
a
particular.
You
know
Gateway
class,
and
these
two
is
not
adding
additional
ones
you
can.
You
can
have
the
cluster
I
mean
deploy
additional
Gateway
classes,
just
like
we
do
in
history,
I
mean,
if
you're
installing
history
of
deploys
when
you
get
to
a
class
right.
H
The
key
is
the
flexibility
that
Mitch
was
mentioning
earlier,
so
like
for
the
things
that
are
cluster
admin
Scouts
in
organization.
A
I
can
have
a
Dev
staging
prod
set
of
tags
that
I
move
around.
As
my
cluster
moves
through
the
life
cycle,
new
AC
releases,
but
the
same
istio
Gateway
classes
would
be
the
same
organization
B
so
again
sing
Gateway
classes,
but
I
can
use
Alpha
Beta
stable
for
my
tags
and
nuclear
different
Cadence.
H
There's
a
distinction
between
the
different
Gateway
classes
that
are
available
in
the
different
tags
that
users
have
the
flexibility
to
set
basic
organizational
needs
costume.
E
C
My
use
case
what
I
have
in
mind
is
that
Waypoint
and
pretty
much
everything
in
ambient
should
be
interoperable
and
should
support
that.
That's
why
we
use
Gateway
and
Gamma
apis,
because
you
can
have
additional
implementations
and
you
know
infrastructure
can,
they
can
be
managed,
can
be
in
the
cloud
and
so
forth.
Anything
that
is
EQ
only
and
if
you're
specific,
which
is
not
ideal
of
programming.
E
B
Yeah
one
thing
I
would
say:
is
that
how
a
Gateway
class
or
implementation
specifies
the
version
is
totally
specific.
To
that
thing,
like
Easter
has
a
way
to
do
it.
Nginx
has
a
way
to
do
it.
Gke,
Cloud,
load,
bouncer,
doesn't
have
a
way
to
do
it
intentionally
because
you
don't
get
it
specify
the
version
right.
So
it's
it's
at
the
very
least
the
same
as
how
it
is
for
Ingress
gateways
that
the
API
is
consistent.
B
Yes,
but
there
is
vendor
specific
attributes
of
it
like
what
version
to
use
or
maybe
Easter
exposes
CPU
resources,
but
nginx
doesn't
because
I
have
reasons
we
could
standardize.
Those
like
I
think
there's
interest
in
in
more
standard
deployment,
customizations,
but
I,
don't
think
it's
it's
horrendous
to
have
a
user-specific
thing
when
you
use
the
East
View
Waypoint
that
doesn't
apply
if
you
use
the
nginx
breakpoint.
The
other
thing
I
would
notice
that
using
a
non,
these
two
Waypoint
is
completely
broken
today.
B
So
if
someone
is
interested
in
networking,
you
need
to
do
some
some
work
to
make
that
happen,
or
we
need
to
do
some
work
to
make
that
happen.
C
But
again
we
haven't
added
a
crd
for
a
long
time
because,
again
and
for
far
more
use
we're
seeing
the
important
things
and
I'm
completely
agreeing.
We
should
start
that
and
we'll
share
this,
but
I
don't
know
if
it
is
the
case
where
we
need
to
add
another.
Is
your
specific
ERD
for
this
particular
view
State,
when
when
we
didn't
do
it
for
a
lot
of
other
more
harmonious
disease,
but
we.
F
E
Okay,
I
see
a
lot
of
people
have
had
to
drop
or
other
minutes
over
that
we
should
probably
allow
them
to
participate
in
the
conversation,
I'll
follow
up
a
little
bit
more
offline.
Invite
comments
in
the
doc
appreciate
the
conversation.