►
From YouTube: Ambient Mesh WG Meeting 2023 05 24
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
Yeah
so
I
I'm,
pretty
close
to
having
like
a
first
cut
at
some
of
the
DNS
stuff
and
as
I'm
kind
of
like
building
it.
It
kind
of
feels
like
it's.
It
should
be
kind
of
like
its
own
crate
for
a
couple
reasons,
one
it's
kind
of
a
standalone
thing
and
could
be
reusable
outside
of
z-tunnel.
A
A
B
I,
don't
personally
see
any
value,
but
I
do
see
cost,
so
it
may
just
be
because
I'm,
not
a
rust
expert
but
I
I.
What's
what's
the
value
like
I,
don't
think
we
have
a
goal
of
the
channel
as
a
DNS
library
and
I'm,
not
convinced
that
it's
easier
to
make
it
optional
or
that
even
optional
compiling
is
a
goal.
A
C
A
Agree
with
that
goal,
though,
okay
well
I
mean
we
can.
We
can
have
that
discussion
again,
but
you
know
it's
I
I
feel,
like
you
know.
Having
multiple
crates
is
a
pretty
idiomatic
rust
pattern,
especially
when
they're
they
really
are
kind
of
independent
libraries,
I
I,
guess
I,
don't
see
a
lot
of
effort
in
doing
this
and
so
I'm
I
guess
I'm
surprised
at
the
pushback.
Can
you
can
you
maybe
expand.
B
Yeah,
if
you
want
to
make
one
crate,
but
then
it
needs
to
depend
on
some
common
field,
then
you
need
to
make
your
common
crate
and
then
you
probably
end
up
with
a
bunch
of
common
utilities.
So
you
have
your
tools
rate
and
suddenly
we
have
100
crates
when
they
could
just
be
Imports
and
like
there's
no
benefit
to
a
user
to
make
them
crates
right.
It
seems
like
just
more
work
for
us
and
more
complex
awesome,
yeah.
D
So
my
my
personal
interest
is,
you
know
in
in
making
sure
that
Z
tunnel
can
be
used
as
a
library,
so
you
can
have
a
proxy
less
something
where
you
know
you
just
link.
You
know
you
write
a
rust
application,
you
want
to,
you,
know,
reuse,
the
same
code,
the
same
age,
one
is
the
same
Discovery
service
and
you
just
use
the
rest
as
a
library
with
some
API,
and
that
would
also
allow
people
to
take.
You
know
links
zitana
with
the
DNS
server,
with
the
ca
or
whatever
they
want
to
link
it
to.
D
I'm
not
selling
the
one
entry
point
is
the
minimum
of
use.
If
you
need
something
multi,
a
bit
more
refined
API,
it's
probably
better,
but
not
too
big,
but
it
doesn't
have
to
be
I'm.
No,
absolutely
everything
needs
to
be
maintained
as
an
API,
but
we
should
have
the
discipline
I'm
not
concerned
about
how
many
crates.
But
you
know
what
is
a
stable
interface
as
minimal
as
necessary.
D
B
A
Yeah
I
was
kind
of
looking
at
it
from
the
you
know,
the
perspective
of
like
kind
of
like
layering
functionality,
you
know
like,
like
Z
tunnel,
might
be
layered
on
top
of
something
else
that
does
DNS
you
know.
Potentially
that
thing
could
leverage
our
DNS
Library,
but
you
know
like
like
neither
Z
tunnel,
would
need
necessarily
to
include
the
code
from
DNS
and
that
other
thing
may
not
need
to
include
the
code
from
Z
tunnel.
D
But
it's
about
the
same
thing:
I
mean
as
long
as
functionality
we
have
today
in
the
core
Z
tunnel,
it's
available
in
linkable
as
a
library,
then
you
can
go.
Naturally
you
can
put
whatever
you
want.
You
have
one
thousand
options
to
to
to
build
the
c-tunnel
based
server
that
include
anything
without
adding
complexity
or
anything.
D
A
Sure,
okay,
Ian.
E
Excuse
me:
could
we
meet
this
need
by
having
one
crate
that
has
different
features
so,
like
proxy
is
a
feature.
Dns
is
a
feature.
If
you
don't
accept
the
DNS
feature,
then
it's
we
wouldn't
be
compiled
into
your
binary.
Yeah.
A
Yeah
I
think
I
think
regardless
it
would
be
a
feature
basically
that
I
I
just
I
just
see
like
you
know
it's
it's
pretty
clean
and
rust
to
optionally
even
include
another
crepe
based
on
that
feature,
rather
than
you
know,
having
you
know,
kind
of
like
conditional
compilation
throughout
an
entire
section
of
the
code.
B
Ask
why
we
want
conditional
compilation.
We
have
10
000
features
in
Easter
today
and
one
one
build
it's
not
clear.
Why?
Suddenly
DNS
and
Z
tunnel
needs
its
own
build
and
how
someone
could
possibly
how
someone's
going
to
consume
that
anyways,
because
I
really
don't
want
to
ship
Z
tunnel
fips
the
tunnel
non-fips
Eternal
fips,
DNS,
eternal
fips,
yeah
yeah,.
A
Build
right,
yeah,
we
we
wouldn't
we
wouldn't
ship,
we
would
ship
one
thing
in
open
source
right,
but
you
know,
if,
for
for
folks
that
you
know
want
to
do.
Custom
builds
the
features
available.
I
mean
it's,
it's
it's
pretty
low
cost
to
us.
B
A
I
I
don't
actually
know
yet
so
I'll
have
to
see
like
what
the
binary
ends
up
being
yeah.
B
D
Optimizing
the
e120
makes
is
not
a
huge
deal
compared
with
sidecar
I.
Don't
think
we
are
anywhere
close.
The
big
question
is:
if
we
want
to
take
the
burden
of
maintaining
a
DNS
server
or
we
want
to
let
other
vendors
or
projects
to
reuse
the
tunnel
and
Link
with
the
other
servers,
if
they
choose
to
I
mean
the
question
is:
do
we
take
the
DNS
maintenance
or
and
get
in
the
business
of
being
a
DNS
server?
A
Well,
I
I
think
the
decision
from
a
few
weeks
back
was
that
you
know,
will
will
ship
with
our
thing
but
allow
it
to
be
stripped
out
and
in
favor
of
you
know,
reducing
the
size
of
the
binary
and
and
just
deferring
to
platform
for
DNS
right.
D
Everything's,
a
set
of
binary
I
think
it's
optimizing
for
the
wrong
thing
question
is:
do
we
believe
that
we
should
maintain
a
DNS
server
and
document
and
everything
else
or
not?
If
we
decide
that
it's
worth
being
a
DNS
server,
we
should
just
compile
it
in
and
be
part
of
the
normal
distribution,
and
you
know
by
the
bullet.
C
C
A
Oh
I'm,
sorry,
maybe
I
misunderstood
what
you're
asking
no
I,
don't
think
we're
going
to
slip
it
or
replace
anything
within
Z
tunnel.
So
it's
not
like
an
API
kind.
A
C
F
So
this
has
been
an
issue
that
we
dealt
with
Louis
a
little
bit
in
your
absence.
There
had
been
a
proposal
I
believe
it
was
from
solo
to
add,
like
webassembly
style
extensibility
into
the
tunnel.
G
F
Yeah,
the
response
at
the
time
was
like
rust,
is
really
composable
go
ahead
and
have
your
own
build
rather
than
you
know,
dragging
down
everyone's
open
source
build
by
adding
features
there
right.
I
think
that
using
multiple
crates
would
support
that
sort
of
a
model
that
we
want
solo
and
others
to
follow
where,
instead
of
adding
extensibility
into
istio,
they
consume
the
bits
that
they
need
and
modify
them
as
needed.
Nate
is
that
is.
Is
that
what
this
is
going
towards.
H
Solo
thing
was
a
little
different
in
that
it
was
I,
think
making
zetunnel
a
crate
that
could
be
composed
so
that
you
could
add,
like
extensions
to
the
network,
handling
pathway
as
opposed
to
the
DNS
stuff,
which
is
essentially
a
wholly
separate
bit
of
logic,
right
and
I.
Think
actually
it's
even
stronger
for
the
DNS
stuff.
The
case
is
stronger
to
just
say:
yeah.
It
should
be
a
separate
crate
and
doing
it
as
a
feature
flag,
like
that
seems
pretty
reasonable.
H
A
I
I
think
I
think
the
DNS
I
think
the
DNS
thing
is
is
a
pretty
good
example
of
a
standalone,
Library
I,
don't
know
if
we
have
a
lot
of
other
examples
of
that
today
in
Z
tunnel
we
don't
yeah,
but
but
I
mean
it
is.
It
is
pretty
idiomatic
and
in
Rust
to
make
separate
Standalone
libraries
crates.
You
know
it's
just
kind
of
pretty
common.
You
look
at
a
lot
of
projects
out
there
and
they're.
Just
you
know:
yeah
multi-create
projects.
H
A
Yeah
I
mean
John
to
your
to
your
kind
of
concern
about
great
proliferation,
I,
I
I.
Don't
know
we
need
to
worry
about
that
too
much
I
mean
I,
I.
Think
it's
gonna
come
up
on
a
you
know:
PR
by
PR
basis
somebody
tries
to
add
a
new
crate.
We
can
say:
does
it
really
make
sense
as
a
crate,
yada,
yada
yada?
You
know,
I
I,
I,
think.
B
A
B
Not
just
make
it
another
module
instead
of
a
crate,
though,
then
we
don't
have
to
make
so
many
different
crates
which,
by
the
way
each
crate
specifies
its
dependencies.
So
we're
gonna
have
like
10
crates.
Sorry,
okay,
now
10.
we'll
say
five
crates
depending
on
Tokyo
and
then
you
need
to
make
sure
that
doesn't
go
awry
and
every
time
you
import
one
Library.
You
need
to
go
modify
that
creates
dependencies
like
we.
We
have
dependencies
at
the
binary
level.
We
don't
really
care
about
them.
B
At
a
procreate
level,
you
can
have
clean
code
and
separate
isolation
with
modules.
That's
not
needed
in
crates
like
I.
Get
that
other
projects
do
it,
but
they
have
different
needs.
I.
Think
like
we're
talking
things
like
Servo
or
something
that's
like
a
million
lines
of
code.
It
makes
much
more
sense
to
have
small
crates
in
that
case
than
a
very
focused
small
binary,
like
we
have
all
of
Easter,
with
one
go
module,
for
example,.
C
I
Which
we
understand
yeah
by
the
way
yeah
by
the
way
Ben
was
mentioning
about
solo
submitted
API
to
extend
zitano
I
at
this
stage.
I,
don't
really
see
how
we
could
leverage
multiple
crates
to
help
us
at
this
moment.
B
A
Also,
possibly
I
don't
know,
but
that's
that's
I
mean
that
actually
brings
up.
Another
Point
like
rxds
protos,
could
be
made
into
a
crate.
I
mean
that
seems
pretty
reasonable.
F
F
B
C
B
Agree
with
that
as
well,
but
wait
the
hypothetical
future,
maybe
we'll
want
to
depend
on
it,
because
we
don't
know
what
you'll
want
to
depend
on
right.
We
may
be
divided
the
crates
up
in
the
wrong
way
like
we
can
still
Write
Clean
code,
that's
isolated
without
making
a
bunch
of
crates
by
using
modules
and
then
we're
not
locked
into
anything
like
we
can
always
refactor
things
later.
J
C
Right
so
I
guess
there's
two
there's
two
issues
right
with
with
any
like
componentization
right,
one
is
the
interfaces,
and
then
two
is
the
the
modularization
of
the
build
of
dependency.
Artifacts
I
am
no
rust
expert
on
on
either
of
those
things.
I
probably
have
a
bit
more
experience
with
the
inter
cases
than
the
modules
part.
C
If
you're
trying
to
do
this
right
now,
mate,
then
right,
obviously
there's
two
choices
right.
You
can
either
depend
on
all
of
Z
tunnel
right
and
an
interface
or
you
can
depend
on
a
piece
of
Z
tunnel
in
a
crate
and
an
interface
right
and
you're
going
to
deal
with
the
churn
and
either
is
it
substantially
better
one
way
or
the
other
right
now,
I
presume
the
interface
is
more
material
anyway,.
A
Yeah
I
mean
so
so
are
you
asking
like?
Is
it?
Is
it
a
burden
to
take
on
the
the
full
the
binary
size
of.
A
I,
don't
know
it
just
seems
kind
of
icky
to
do
such
a
thing
right,
because
it
is
really
a
a
separate
thing.
It
should
just
be.
You
know
a
handful
of
files.
It
really
is
a
standalone
entity.
It
was
that
case
in
in
in
istio
too
in
golang.
A
But
you
know
it's
I
I
feel
like
dividing
things
up
into
crates
is
more
idiomatic
sort
of
thing
to
do
in
Rust,
it's
just
it
just.
It
seems
to
to
make
sense
to
do
that.
I,
I,
just
I,
think
the
only
thing
John
that
you're
saying
that
might
resonate
is
is
the
fact
that
you
know
each
crate
kind
of
needs.
Its
own
listed
dependencies
I
mean
I
I.
Suppose
we
can
look
into
ways
of
simplifying
that,
so
that
that
we
know
that
dependencies
are
consistent
across
all
the
crates,
but
is.
B
I
think
I
would
actually
be
a
lot
less
concerned
if
the
crates
were
what
I
don't
know
if
this
is
a
real
term,
but
kind
of
leaf
crates
like
if
it's
just
it's
completely
Standalone
thing.
That
is
just
doing
some
logic
that
doesn't
depend
on
anything,
that's
fine,
but
if
we
get
in
the
situation
where
that
thing
is
kind
of
in
the
middle
of
the
dependency
tree
and
it
kind
of
Z
tunnel
depends
on
it.
B
C
A
A
And
I
think
the
XDS
part
could
be
ripped
out
of
it
and
and
put
into
you
know
the
the
Z
Channel
proper
code
for
now.
K
Yeah
so
I
think
for
me,
the
ugly
when
it
comes
to
extensibility
the
the
prospect
of
being
able
to
just
import
the
XCS
Library
or
the
DNS
libraries
is
pretty
pretty
attractive.
K
The
weird
thing
about
doing
that
for
Eternal
now
is
that
their
and
that's
where
the
discussion
was
a
few
months
ago.
Right
is
that,
where
are
the
integration
points
going
to
be,
and
are
those
going
to
be
sufficient
for
the
use
cases,
whereas
I
think
having.
K
Functionality
of
DNS
or
it's
your
compatible
XTS,
those
are
pieces
that
can
be
composed
in
a
knockoff
away
and
the
actual
kind
of
representation
that
we
know
today
is
eternal
doesn't
have
to
worry
about
exposing
all
these
100
different
integration
points
for
people
to
do.
Custom
stuff
that
just
leverage
the
library
that
the
library
was
to
have
you
know
reference
the
crate
and
the
crate
can
have
whatever
integration
point
to
make
sense
for
standalone.
C
Right,
I
just
think
so
the
I
think
it's
reasonable,
I
think
the
one
thing
people
take
independencies
have
to
realize
is
that
right,
these
this
work
and
meeting
the
requirements,
the
interfaces
will
be
done
to
serve
Z
Tunnel
right,
and
so,
if
those
interfaces
churn
right,
the
downstream
adopters
will
not
to
adapt
right.
Don't
don't
consider
them
to
be
hard
contractual,
stable,
apis
right,
yeah
right.
This
is
Library
dependency
without
a
contract.
E
A
So
John
and
anyone
who's
interested
I'm,
I'm,
happy
to
kind
of
you
know,
start
our
work
in
progress
PR
in
the
next
week
or
so,
and
we
can
just
you
know,
have
discussion
there.
If
that
works.
B
C
C
I
do
think
we
want
to
facilitate
this,
though
John
right,
like
in
general
right,
the
granularity
is
still
probably
subject
to
dpd
and
right.
The
downstream
dependency
takers
have
to
deal
with
churn,
but
I
see
no
reason
not
to
facilitate
people.
Recomposing
Z
tunnel,
like
things
out
of
zetorol's
component
parts,.
A
C
E
H
H
Well,
there's
two
parts
to
that,
but
one
is
basically
you
treat
Z
tunnel
as
a
rust
component
itself
and
then
there's
the
extension
stuff,
but
I
think
the
Russian
tunnel
as
a
component
is
what
you're
talking
about
essentially
like
make
it
a
importable
module.
Yeah.
A
Well,
I
was
just
I
was
actually
just
going
to
take,
basically,
all
the
all
the
code
and
everything
and
just
put
it
into
a
sub
directory.
E
A
Be
effectively
Z
tunnel,
C
tunnel
yep
and
then
have
a
have
a
workspace
at
the
the
Tamil
at
the
top
level
would
just
be
a
workspace
that
includes
it.
So
it
would
be
a
no
a
no-op
apart
from
just
restructuring.
Okay,.
H
F
All
right,
Chief
I,
think
your
agenda
item
up
or
is
up
next.
K
This
is
me
looking
to
try
to
push
on
some
of
the
stuff
in
latest
drive
and
get
to
betadop.
One
of
the
P0
items
is
authentication
and
figuring
out.
K
What
support
looks
like
for
that
ambient
looking
at
the
80
apis
doc,
there's
kind
of
two
password
one
to
keep
proff
in
and
kind
of
retrofit
semantics
on
top
of
it
to
make
sure
it
gets
into
the
ambient
the
other
one
is
to
rip
it
out
completely
new
operation
policy
kind
of
as
a
as
replacement
wanted
to
see
where
consensus
is
on
this,
because
I
couldn't
find
any
yeah.
We've
talked
to
a
couple
of
folks
individually
about
it.
K
I
think
my
preference
would
probably
be
for
alien
beta
to
just
continue
using
peer
authen
but
I
think
I'm
generally,
a
line
long
term
with
perhaps
with
making
obligation
policy
do
the
same
job,
but
regardless
yeah
just
want
to
see
if
there's
Direction
here
and
if
so
would
love
to
make
a
general
issue
and
start
going
through
what
implementation
looks
like.
D
I
mean
I'm,
probably
the
ones
that
object
the
most
on
this
and
argument
quite
a
bit.
My
personal
opinion
was
that
it's
not
our
business
to
deal
with
plain
text
in
ambient
Network
policy
exists.
It's
a
you
know
very
good
API
in
kubernetes.
It
can
be
used
to
restrict
and
fine-tune
exactly
what
you
want
to
to
be
allowed
as
plain
text
or
not
from
from
non-esteo
workloads.
D
So
it's
better
to
just
get
out
of
the
way
and
have
an
option
to
not
capture
plain
text
and
learn.
Network
policy
delete
it
and
we
are
focused
only
on
the
strict
TLS.
So
if
you
have
a
legacy,
you
know
VM
or
something
that
needs
to
talk
with
with
a
workload
and
needs
to
use
plain
text,
you
can
put
a
network
policy
and
allow
it
to
do
it.
Otherwise,
you
can
deny
all
traffic
to
supply
text.
K
I
hear
that
I
can
say
with
osm
we
kind
of
did
a
similar
thing
where
we
didn't
allow
plain
text
and
or
any
kind
of
protocol
detection
mechanism,
and
there
there
were
some
customers
were
kind
of
confused
and
it
took
and
it
adopt
me
a
bit
longer.
K
Just
because
you
know
oh
I
have
to
have
a
certificate
to
talk
to
this
thing.
It
makes
the
dependency
chain
a
lot
further
because
you
have
to
figure
out
who
talks
to
what
service
before
like
setting
on
your
config,
which
is
probably
the
most
secure
thing,
but
adoption
wise
it.
It
is
difficult.
K
K
D
B
I
I
think
I
mean
this
is
still
in
debate,
but
kind
of
the
current
thing
here
was
for
Z10
on
network
policy.
We
want
the
network
policy
to
apply
after
before
tunneling
or
after
detunling,
so
it'll
be
on
the
original
port,
not
on
the
H1
port,
which
is
not
how
sidecars
would
work
with
h-bone
and
not
compatible
with
higher.
B
D
So
you're,
seeing
that
if
Network
Police
is
implemented
in
zitana,
let
me
intercept
and
we
bypass
the
network
policy
with
interceptions
and
it's
not
possible
to
use
Network
policies.
That's
what
you're.
B
Saying
no
well,
we
will
use
the
same
either
Network
policy.
It
will
just
apply
on
the
traffic
like
we
can
decide
when
it
applies
right.
They
can
apply
before
we
put
it
in
HMO
tunnel
or
after
so
the
original
port
or
15008.
D
B
D
F
D
D
With
normal
Network
policy
and
layers,
I
mean
Network,
policy
applies
first
and,
and
you
talk
with,
then
it
will
work
perfectly
fine,
but
I
understand
the
complexity
that
join
the
script.
I
I
Now,
by
the
way
we've
been
using
it
for
a
long
time
and
to
me
I
think
pure
authentication
has
been
extremely
helpful
in
the
Cycle
World
to
help
people
troubleshooting
right
to
enable
strict
was
not
strict
when
their
application
have
a
complex,
complex
compatibility
issues
with
psycha.
It
has
been
extremely
useful
for
onboarding
applications
with
cycle,
so.
I
K
Was
gonna,
say:
I,
don't
know
that
your
authentication
doesn't
make
sense
in
ambient
I.
Think
peer
authentication
is
a
declarative
expression
of
user
intent
of
what
kind
of
encryption
should
use,
and
you
know
in
sidecar
case
it's
it's
doing
it's
doing
one
thing,
but
the
A
to
B
case
is
just
port
numbers
I.
Don't
think
that
we
should
Elevate
the
specific
H1
port
numbers
to
the
user.
That
goes
like
a
like
a
leaky
abstraction.
At
that
point,
it's
just
in
my
mind.
Port
numbers
are
implementation,
details
of
user
declared
intent.
D
Keep
in
mind
that
we
had
a
discussion
very
similar,
that
per
authentication
really
doesn't
do
anything
I
mean
it's.
It's
like
it's
like
using
service
entries
for
egress
control.
It's
it's
a
very
weak
security
boundary,
even
if
you
say
strict.
What
really
means
is
that
pretty
much
everyone
has
access,
because
everyone
is
a
mesh,
can
get
a
certificate
review
proper
way
to
do.
Security
is
to
put
an
authorization
policies
where
you
say
that
this
work
can
only
be
accessed
by
Alice
and
Bob,
and
then
you
are
controlling.
D
B
To
me,
though,
like
I
think
it's
about
a
very
valid
argument
and
I
would
probably
completely
agree
with
it.
If
this
was
a
new
API
being
proposed,
but
I
think
the
biggest
risk
is
that
a
user
adopts
ambient.
They
stick
peer,
authentication
strict,
they
think
all
their
traffic's
TLs,
but
it's
actually
not,
and
it
is
in
some
cases
for
sidecars
it
is,
but
not
for
a
z
tunnel.
B
That
would
be
my
concern
and
we
don't
have
a
good
way
to
expose
that
to
users
now
I
suppose
you
could
say
that
for
every
other
API
as
well,
like
request,
authentication
or
Envoy
filter
I,
don't
know
so
maybe
it's
a
bit
of
an
unfair
argument,
but
that
that
would
be
my
biggest
concern.
Is
it
just
the
confusion
that
migrating
users
may
they
have.
D
Exactly
what
you
said
I
mean
if
we
see
piano,
authentication,
strict.
We
deny
all
traffic
on
on
Plain
text,
but
we
don't
support
any
other
field
like.
G
D
B
J
D
For
migration,
I,
don't
mind,
I
mean
I'm.
Just
my
question:
is
it's
really
not
a
very
good
practice
too?
So
if
you,
if
you
want
to
limit
what
I
mean
the
network
policy,
had
the
benefits
that
you
can
fine
tune,
what
is
allowed
to
go
into
the
into
the
support
So,
if
you,
you
may
have
a
legacy
workload
and
you
can
fine
tune
that
particular
workload
is
allowed
to
do
plain
text
instead
of
binary
switch
everything
on
or
off,
but
that's
fine
I
mean
if
it's.
B
B
D
A
problem,
you
cannot
do
it
authorization
policy,
because
if
you
put
authorization
policies,
then
you
cannot
say
authorize
for
everyone,
except
for
this
particular
workload
where
I
allow
plain
text
so
basically
kind
of.
If
you
have
a
let's
say
you
have
Legacy
Gateway
like
like
in
Google,
you
have
the
downloads.
You
want
those
particular
by
cidr
or
by
something
to
to
be
allowed
in
and
be
kind
of
trusted,
implicitly
because
they're
in
different
cidr,
that's
a
use
case.
That
is
not
possible.
B
D
B
I
B
Pilots
telling
the
clients
then
they're
not
going
to
do
plain
text.
Oh
you're,
saying
that's
fine.
We
only
care
about
so.
B
D
If
everything
is
encrypted
anyway
automatically,
why
would
we
capture
it?
I
mean
with
let
Network
policy
deal
with
any
potential
plain
text
traffic
which
shouldn't
exist
in
the
first
place
in
an
ambient
Network,
so
exceptions
will
be
exceptions
controlled
by
Network
policy,
and
we
are
not
involved.
That's.
It
simplifies
a
lot
anyway,
it's
too
late
for
that,
probably
but
foreign.
C
Yeah
so
I
think
we're
if
we
say
we
want
Z
tunnel
to
capture
and
see
plain
text
traffic,
so
we
can
enforce
policy
on
it.
Then
we
need
all
right.
All
we're
doing
is
translating
peer
authentication
policy
into
authorization
policy
and
extending
the
capability
of
all
the
research
policy
to
say
plain
text
or
not
right.
B
B
C
Yeah
I
think
that's
pretty
good
enough
to
start
with
whether
we've
identified
peers
or
not.
At
some
point,
we
may
need
to
be
able
to
distinguish
on
the
mechanism,
but
probably
not
to
start
with.
K
And
again,
I
think
I'm
generally
I'm
fine
on
the
long
term
of
this
being
deprecating
or
moving
away
from
your
authentication,
because
we
can
express
it
in
openness
and
policy,
but
for
the
sake
of
the
ambient
to
Beta
and
urban
and
adoption
transition.
I
think
it
makes
sense
for
use
the
istio
to
HCL
users
to
have
their
stuff
still
work
in
a
fairly
expected
way.
C
D
If
there's
a
part
of
deprecation
I'm,
happy
I
mean
my
constellation
started
with
the
ideas
that
eventually
zitana
should
be
part
of
cni
layer
anyway,
somehow
and
anything
like
peer
authentication.
It's
in
putting
delaying
this
happened
from
happening,
because
it's
more
radii,
it's
more
surfaces
that
such
a
cni
layer
will
need
to
support.
D
I
C
Well,
as
long
as
we're
telling
them
what
to
do
right
and
the
the
thing
that
they
would
replace
it
with
is
just
an
existing
API,
that's
already
there
write
that
that
should
be
satisfactory.
Then
right,
it's
just
one.
That's
it's
a
one,
less
API
for
them
to
look
at.
J
Yeah
I
have
a
question
right,
so
if
the
direction
is
to
move
the
peer
authentication
into
authorization
policy,
how
do
we
convey
this
concept
of
this
must
be
encrypted
by
mtos,
because
authorization
policy
essentially
is
expressing
who
is
allowed
to
do
what
operation
on
what
resource?
But
not
it's?
Who
right
may
come
from
George
coming
from
certificate
and
they
may
come
from
plaintext.
It's
not
about
the
transportation
layer.
The
TRS
is
the
transportation
layer
security.
J
C
Well,
we
have
two
types
of
principles:
right,
there's,
request
principle
and
peer
principle.
The
only
way
we
distribute
pure
pencil
today
is
with
a
secure
overlay,
right,
I,
H,
bone
or
or
mtls
right.
So
if
we
have
a
requirement
that
there's
an
identified,
a
security
identified
peer
principle
right
that
gets
us
99
of
that.
The
second
part,
as
I
mentioned
earlier,
is
describing
the
mechanism.
It's
not
clear
if
we
need
to
do
that
yet,
but
we
could
say:
yeah
was
this
done
over
TLS
1.3
using
this
Cipher
right.
C
J
Okay,
so
essentially,
what
we
are
saying
is:
if
we
have
authorization
policy,
then
it
means
the
traffic
is
encrypted.
If
you
are
using
plain
tags,
essentially
you
are
not
doing,
you
are
not.
The
authorization
policy
is
bypassed
because
no.
C
J
D
C
D
C
B
It's
one
small
note:
it's
actually
not
checking
that
there's
any
identity,
it
does
check
the
trust
domain
and
the
other
thing
is
someone
mentioned
that
this
equivalent
it's
very
close
to
equivalent
but
I
think
with
pure
authentication,
will
actually
deny
it
in
the
TLs
handshake
with
authorization
policy
will
fully
accept
the
TL
of
sandshake
or
lack
thereof,
and
then
deny
it.
I
guess
it's.
Actually.
This
ends
up
being
the
same,
because
there's
no
TLS
handshake.
If
you're
doing
plain
text.
D
D
B
D
B
Yeah
yeah
actually
looking
at
it
through
authentication,
that's
specifically
say
mpls,
but
if
we
really
need
to,
we
could
probably
say
mtls
equivalent
answer
or
something
maybe
but
I
mean
that's
also
another
thing:
that's
in
favor
of
authorization
policy
right
it
doesn't
specify
the
transport.
It
just
says
that
identity,
oh
I,
just
say
peer
certificate.
So,
but
that's
you
know
we
could
genericize
the
wording
to
make
it
hit.
Other
use
cases.
G
C
I
B
I
B
F
I'm
just
thinking
you
know,
we've
already
had
one
user
discover
this
and
be
surprised
by
it.
We're
asking
all
of
our
users
to
kick
the
tires,
and
let
us
know
what
needs
Improvement.
F
It
might
be
a
good
idea
to
have
a
way
of
letting
them
know
where
we
know.
We
already
know
their
needs
improvements
so
that
we
don't
get
inundated
with
bug.
Reports
on
this
foreign.
K
D
G
D
Is
there
any
authorization
policy
that
does
not
imply
paintings,
I
mean
even
with
jot?
Goods
must
be
sent
over
I,
see
what
they're
saying
that
when
we
kind
of
violate
the
standard
and
yeah?
That's
a
good
point.
C
B
B
D
But
what
where
is
this
and
who
is
that
we're
talking
about
so
the
Waypoint
receives
H1,
which
is
clearly
you
know,
TLS
and
that's
it
because
sea
tunnel
is
the
one
that
receives
that
to
reinforce
the
pure
Authentication.
H
G
D
G
D
K
G
K
And
we
defer
this
the
soft
deportation
into
later,
because
it
seems
that
we
know
what
we
want
to
do
for
a
of
H,
specifically
we're.
Not
what
we're
not
sure
about
is
how
I
want
to
reconcile
that
with
sidecars.
So
does
it
make
sense
to
be
nervous
to
delay
the
soft
deportation
or
to.
C
Get
to
do
I
don't
know
if
we
need
to
delay
the
soft
like
soft
deprecation
doesn't
say
like
this
is
going
away
anytime
soon
right.
So
what
is
the
concern
that
people
will
just
start?
Writing
all
the
policies
to
deny
plain
text
traffic
and
have
psychers
Implement
that,
while
having
you
know,
peer-off
and
policy
be
permissive.
C
G
C
K
G
G
D
What
is
alsoever
is
to
have
a
production
system
where
a
huge
amount
of
traffic
is
is
rejected.
So
it's
not
common
to
I
mean
we
optimize
for
the
normal
90
of
the
traffic,
which
is
200
and
works.
It's
not.
You
know
a
significant
amount
of
traffic
in
a
production
cluster
that
will
go
be
rejected
immediately
and
we
optimize
for
it.
K
I
think
I
agree
with
that
lucky,
it
does
make
sense
to
say
hey
if
you're
dealing
with
dealing
with
performance
issues
have
your
head
organization
policy.
That
is
this
stricter
and
you
can
start
limiting
things.
K
C
C
I
C
C
C
K
C
K
Sounds
good
I'll
get
started,
creating
issued
in
Step
One
implementation,
but
I
gotta
go
I'll
talk
to
you
later,
okay,.