►
From YouTube: Istio Networking (Data Plane) WG meeting - 2019-10-31
Description
Istio Networking (Data Plane) WG meeting - 2019-10-31
B
B
D
A
D
Sure
so
that
the
basic
discussion
is,
you
know
this
issue
is
trying
to
provide.
You
know
a
transport
security
mechanism
to
allow
people
to
basically
modernize
their
security,
best
practices
without
necessarily
being
too
disruptive
to
how
the
network
is
defined
today,
and
we've
tried
to
do
this
by
essentially
trying
to
wedge
in
TLS
into
the
network
on
all
the
existing
application.
D
And
so
this
was
document
was
an
attempt
to
explore
alternatives
to
see
if
we
could
do
something
that
provided
the
same
feature
set.
But
in
a
way
that
was
a
bit
more,
maybe
standardized
with
industry,
best
practice
and
more
supportable
with
a
non-void
and
there's
there's
a
few
examples.
I
put
in
the
doc
about
you
know
some
of
these
challenges
that
we
faced
you
know,
protocol
sniffing,
particularly
TLS
sniffing
is
complicated.
D
It
doesn't
necessarily
work
that
well
with
server
sends
first
protocol.
You
have
to
do
timeouts.
It
really
does
add
quite
a
bit
of
complexity
to
the
networking
stack
and
how
we
configure
envoy
and
then
there's
a
variety
of
other
things
with
the
solution
that
we
have
today
that
are
basically
in
the
same
category.
So
the
you
know
the
alternate.
The
the
kind
of
fundamental
alternative
proposal
is
to
kind
of
create
a
dedicated
transport.
You
know
networking
abstraction
kind
of
like
an
L
3,
L
4
direction
below
the
level
of
kind
of
cluster
etc.
D
In
envoy,
that
provides
a
transport
security
feature
and
we
can
still
use
em
TLS
for
that,
but
it's
a
transport
in
the
envoy
sense,
and
so
it
doesn't
collide
with
other
behaviors
of
envoy
and
in
particular
it
doesn't
share
application
ports.
So
we
don't
have
to
do
sniffing
or
things
like
that,
and
so
really
what
we
would
do
is
we
would
have
something
that
could
route
at
l4
based
on
the
existing
configuration,
but
we
already
sent
to
envoy
but
provide
em
TLS
and
it
would
just
be
entirely
opaque.
D
D
That
would
probably
simplify
oneboys
behavior
quite
a
bit,
and
you
know
where
we've
been
running
into
situations
where
we've
had
to
start
asking
envoy
to
do
things
with
protocols
that
are
non-standard,
and
you
know
we
can't
require
the
Envoy
bends
to
our
will
effectively
to
enable
these
kinds
of
features
like
I.
Don't
think
that's
practical
when
they
have
other
users
and
our
use
of
those
features
is
non-standard,
so
there's
that
kind
of
class
of
tension
and
then
there's
okay.
D
Well,
if
we
want
to
shift
to
something
where
there's
a
stronger
separation
between
the
kind
of
lower
level,
you
know
transport
level,
abstraction
and
the
application
level
abstraction,
then
what
would
we
like
it
to
look
like?
What
does
it
need
to
do
and
what
benefits
might
we
get
if
we
made
that
kind
of
transition?
D
You
know
one
of
these
physical
network
abstractions,
there's
a
good
chance
that
we'll
go
and
implement
a
better
one
later
or
a
more
performant
one
or
some
vendor
might
go
on
to
go
and
plug
in
their
proprietary
one
or
something
along
those
lines,
and
so
we
design
the
system
in
such
a
way
that
that
layering
enables
evolution
and
replacement
without
breaking
the
higher
levels
of
the
system.
Right,
so
there's
a
contract,
a
formal
contract
between
this
lower
layer-
and
you
know
the
higher
layers
of
the
system
and
a
good
example
of
this
might
be.
D
Well,
if
you
consider
that
reliable
enough
and
performant
enough
and
you
wouldn't
need
to
use
an
sto
implementation
or
an
envoy
based
implementation
of
Transport
Security,
because
you'd
be
happy
with
what
the
underlying
network
was
doing
and
because
you
could
read
identity
out
of
the
network,
you
could
still
implement
policy
right.
That's
the
other
big
thing
we
do
aside
from
kind
of
the
properties
of
encryption,
around
confidentiality,
integrity,
non
repudiation,
etc.
Is
we
reliably
propagate
identities
so
that
we
can
enforce
policy
on
application
level
traffic
right?
D
What
we
do
in
authorization
was
CVT
and
I
think
that's
the
kind
of
definition
of
the
contract
that
we
want
all
right.
We
want
an
abstraction
and
I
think
it
would
probably
be
good
for
envoy
to
have
a
kind
of
interface
abstraction,
which
codified
some
of
these
things
in
such
a
way
that
that
replacement
could
occur
because
it
will
help
us
evolve
the
product
over
time.
D
If
and
when
we
want
to
implement
a
better
transport
and
then
I
listed
out
a
bunch
of
kind
of
transport
implementation
options
that
are
based
on
pretty
well
understood
technologies
in
the
industry.
Today
you
know
so
basically
combining
having
a
dedicated
port
for
transport
and
then
just
using
a
tunneling
protocol-
and
you
know
we
could
use
MPLS
cross
the
proxy
protocol
because
we
need
to
carry
through
destination
port,
etc.
We
need
to
carry
through
the
l3
properties
and
there's
a
few
variation
most.
The
variations.
D
Listen
out
in
the
documents
are
all
using
a
dedicated
kind
of
tunnel
port
and
then
just
using
different
kind
of
encapsulation
protocols
over
it.
So
it
talked
about
the
H.
A
proxy
protocol
using
a
CP
connects
using
Sox
and
then
there's
a
couple
of
other
variants
which,
in
addition
to
you,
having
a
dedicated
port,
also
multiplex
all
the
streams
over
a
single
connection
right.
So
then
we're
talking
about
HTTP,
2
and
quic,
or
what
quic
is
a
little
different
and
then
also
I
talked
about
IPSec
kind
of
at
a
flannel
example
that
I
get.
D
You
know,
and
these
solutions
come
with
varying
costs
right
to
implement,
to
support
performance,
etc,
and
so
I
think
you
know,
assuming
we
can
come
to
some
agreement,
there's
kind
of
two
parallel
tracks
for
discussion.
One
is
you
know:
do
we
agree
that
we
might
want
to
make
a
change
in
how
we
do
Transport
Security
to
look
at
creating
a
stronger
separation
between
the
layers
and,
if
so,
how
do
we
want
to
define
that
contract
and
how?
D
What's
the
higher
levels
of
this
do
change
in
response
to
that,
because
there
would
probably
be
some
API
impacts
and
some
documentation,
impacts,
etc
and
then
a
second
track
which
is
okay,
which
transport
should
we
use
or,
and
that
doesn't
have
to
be
just
one
right.
That
probably
means
designing
so
that
there
can
be
one
now
and
then
others
in
the
future
and
how
would
they?
How
would
people
transition
across
those
boundaries
etc
operates?
D
So
those
are
the
kind
of
two,
the
two
major
themes
that
we
should
discuss.
It's
probably
worthwhile
discussing
the
first
one
right,
the.
What
are
the
are
the
advantages
or
disadvantages
of
moving
to
a
stricter
transport
layer,
separation,
worthwhile
and
then
a
second
discussion
about
well,
okay
and
which
one
makes
sense
to
people?
Yes,.
C
D
D
I'll
try
and
follow
like
he
had
some
more
kind
of
fundamental
questions,
and
you
know
so
one
reasonable
question
he
asked
and
because
all
of
this
plays
into
kind
of
security
posture
today
the
options
is
do
gives
you
our
basically
the
a
bin,
and
you
know,
and
the
options
are
given
to
both
admins
or
likely
madmen
and
to
you
know,
let's
say
a
namespace
or
a
service
owner
at
the
admin
level.
You
kind
of
get
the
option
is
like.
D
Do
you
care
at
all
about
security
right
and
if
you
don't
care,
you're,
not
gonna,
put
any
constraint
on
any
of
the
traffic
on
the
network
and
then
the
next
up
is
rights
and
that's
kind
of
like
the
plain
text
setting
for
authorization
authentication
policy.
Today,
then
the
next
setting
we
give.
You
is
permissive,
which
is
like
well
you're,
trying
to
get
to
a
secure
posture.
D
But
you
know
you're
not
there
yet.
So
you
can't
put
this
hard
constraint
on
traffic
flowing
over
the
network,
so
you're
gonna
allow
a
plain
text
and
secure
traffic,
but
you
want
to
enforce
policy
when
you
can
and
then
the
third
one
is
that
I
want
to
be
strict
right.
No
traffic
can
move
across
the
network
without
being
you
know,
confidential
or
having
integrity,
checks,
etc.
D
E
I
had
a
quick
comment
here.
Integrity
is
not
that
black
and
white,
then
even
simple
I
mean
yes,
we
say
strict,
but
it's
in
reality.
Strict
means
that
anyone
in
the
mesh
can
connect
to
your
work.
It
doesn't
really
mean
any
security
question,
because
you
can
only
get
security
if
you
actually
have
on
our
back
rule,
and
you
specify
only
work
on
the
ABC
can
connect
to
me.
Yeah.
E
D
11.8
rerun
brought
up
is,
if
you
look
at
most
appointments
they
there
is
some
traffic
flowing
between
workloads,
right
I'm
like
no
and
I'm
talking
about
deployments
that
aren't
using
is
the
area
where
their
traffic
is
already
secured
right.
They
may
be
doing
you
know
application
level
TLS
directly
I
did
not
even
be
doing
em
TLS
and
to
go
in
to
those
deployments
and
say,
look
as
far
as
we're
concerned
that
traffic
is
insecure
and
the
only
way
you
can
make
it
secure
is
to
enable
em
TLS
actually
causes
some
friction
for
adoption.
D
Then
that's
fine,
and
it's
only
for
the
protocols
where
we
don't
know
what
they're
doing
that
we
would
maybe
go
put
them
on
to
some
other
transport
mechanism
to
make
them
secure.
A
good
example
here
might
be
G
RPC.
You
right,
you
might
use
the
GRC
clients
talking
to
a
server
and
they
may
do
em
TLS
right
because
G
or
pcs
adding
support
for
this
or
there's
plenty
of
other
solutions
out
there
that
do
and
then
let's
say,
you'd
go
and
deploy
SEO,
but
you
only
deploy
it
on
the
server
side.
D
Now
the
client
might
have
to
change,
even
though
what
they
were
Anton
was
actually
secure
and
that's
probably
not
a
good
thing.
That's
not
a
good
choice
to
kind
of
forced
on
the
end-user,
so
we
might
actually
want
to
have
this
kind
of
mode.
Where
we
say
look,
your
security
posture
is
strict,
but
we
don't
require
that
everything
uses
secure
transport,
that's
implemented
by
SDO
or
is
bespoke
to
ISTE,
oh
right,
if
you're
using
M
TLS
at
the
application
level,
we
consider
that
to
be
strict
as
well.
A
D
So
it's
an
interesting
choice
right,
it's
for
all
the
things
you
don't
know
or
aren't
sure
you
probably
want
to
put
them
just
by
default
onto
some
generic
secure
transport,
but
for
things
that
are
already
secure
and
there
you
have
some
confidence
and
as
an
admin
that
the
applications
are
doing.
The
right
thing.
D
Do
you
want
to
also
do
that
and
because
one
issue
we
have
with
you
know:
if
you're
gonna
do
a
transport
level
abstraction
is,
there
will
be
situations
where
there
are
non
envoy,
clients
talking
to
envoys
right
and
then
we'll
have
to
submit.
They
may
not
support
that
transport
mechanism
and
so
you're
going
to
rely
them
on
the
ability
to
configure
some
alternate
means
of
terminating
secure
protocol.
What
was
already
a
secure
protocol
I.
E
Would
add
here
that
many
times
the
user
knows
better
what
their
applications
are
doing
and
I
was
trying
to
guess
it
and
put
everything
in
packets
based
on
so
maybe
just
giving
the
users
a
tool
to
control
what
ports
are
allowed,
what
ports
are
not
allowed
and
and
and
set
their
own
policy
if
they
choose
to,
because
if
they
care
about,
they
all
probably
write
the
policy
end
and
they
work
net
or
policy
or
other
things.
Yeah.
D
D
D
So
obviously
the
port
sharing
the
difference
would
be.
We
wouldn't
try
and
like
layer,
em
TLS
over
the
existing
application
port.
We
would
stop
doing
that.
Really.
What
the
application
owner
would
say
is
look
this
application
port
is
already
secure
right
for
whatever
definition
of
is
secure,
they're
comfortable
with
right,
and
that
could
be
what
you
know.
Is
it
using
MPLS?
Is
it
using
TLS
or
something
else
right
and.
D
D
Those
features
yeah
the
issue
with
if
we're
going
to
use
em
TLS
as
the
means
of
implementing
or
layering
in
a
secure
transport.
Porch
sharing
is
problematic
right
because
we
have
to
sniff
right
because
we
don't
know
what
they're
using
to
secure
it.
That
leads
to
timeout
service
and
first
issues,
and
it
also
ends
up
with
situations
where,
if
the
underlying
protocol
was
TLS
right
and
we're
not
currently
doing
TLS
over
TLS
or
except
well,
unless
they
declare
to
be
TCP,
you
could
end
up
in
situations
where
you
have
certificate
authority
collision.
E
D
A
real
estate
well
with
manage
CA
at
Google
right.
The
root
CA
is
the
Google
root
CA,
so
you'd
have
to
match
not
to
the
root
you'd
have
to
match
for
an
intermediate
root
and
you'd
have
to
say
that
that
you
can
only
use
the
intermediate
root
for
the
mesh
and
you
can't
use
any
certificates
issued
from
that
intermediate
root
for
the
application
level.
I
think.
D
D
A
One
comment:
I
hope
there
is
the
primary
goal
for
the
port,
showing
that
we
have
right
now
was
that
when
we
were
generally
designing
this,
it
was
I
think
number
one
requirement
to
use
the
same
parts
to
avoid.
You
know
new
firewall
rules
and
stuff
like
that,
whereas
we
are
now
explicitly
rejecting
this.
E
Was
it
a
strong
requirement?
Where
does
the
requirement
come
from,
and
and
is
it
really
something
that
is
was
a
good
requirement
or
bad
required?
We
have
experience
with
people
who
are
using
easier
to
say,
videos
that
are
policies
which
is
firewall
rules
and
it
is
a
proper
ways
they
want
to
use
it
because
that
actually
prevents
them
from
using
metaphors
as
intended
people's
we're,
not
the
police,
you
can
say
don't
allow
access
to
partake
with
is
queue.
You
never
know
what
port
80
is
going
to
be.
E
E
For
for
you,
so
you
need
to
use
East
your
policies
because
again
sense
or
we
need
to
enforce
the
policies
I
mean
we
need.
We
need
is
to
itself
in
for
the
same
policy
on
this
port,
but
that
that
doesn't
change
the
situation,
that
piece
unistream
for
some
security
policies,
one
way
or
another.
Before
remaining.
E
D
If
you
consider
the
use
cases
right,
if
you're
trying,
if
you
don't
care
about
getting
to
the
kind
of
SEO
world
or
the
strong
transport
security
model,
end-to-end
right,
where
you
just
leave
all
the
application
ports,
as
is
right
and
your
underlying
network
firewall
rule,
will
keep
working
but
the
reason
to
go
and
turn
on
these
two
security
policies.
Mostly,
so
you
can
enable
the
our
back
policy
right.
D
E
D
D
But
if
you're
going
to
make
that
transition
you're,
probably
all
you
are
making
the
transition
probably
to
using
our
back
now.
You
know
we
could
look
at
better
ways
of.
Like
you
know.
Maybe
MPLS
was
the
wrong
choice
because
it
collides
too
easily
with
TLS
right,
and
we
could
just
do
something
like
proxy
protocol
and
do
MPLS
over
proxy
protocol
right
and
then
the
detection
right
would
be
more
deterministic.
D
A
E
E
D
D
So
one
of
the
things
I'd
like
to
do
is
to
have
an
interface
abstraction.
So
we
could
go
work
with
networking
providers
who
are
willing
to
make
assertions
their
customers
about
the
security,
their
system
and
integrate
that
up
into
policy
in
telemetry
and
at
least
if
we
create
an
abstraction,
then
people
can
go
do
that
and
they
you
know,
then
we
can
go
and
talk
to
the
networking
providers
and
say
it
looks
guys.
D
You
know
we
have
this
option,
this
fairly
simplistic,
Transport
Security
option
or
go
talk
to
a
user
and
say:
look
we
have
this
Transport
Security
option.
It
uses
a
tunneling
protocol.
It
has
all
these
good
features,
but
if
you
don't
like
how
it
interacts
with
your
network
firewall
rules,
then
here's
your
options
right
go
run
a
lower
level
and
network
overlay.
That's
providing
you
VPN
like
features,
so
you
get
calm,
melody
and
integrity
and
identity
propagation
and
we'll
make
sure
that
there's
an
abstraction
over
that,
so
it
still
works
with
telemetry
and
policy.
D
E
Documents
there
may
be
an
intermediary,
a
situation
where,
if
you
have
permission
to
replay
experiments
it
with
this
mode
because
permissive
is
the
one
causing
most
problems
or
first
move
permissive
to
this
mode
and
maybe
leave
strict
because
with
strict,
you
know
that
everything
is
empty
LS.
You
know
that
I
mean
if
you,
if
you
declare
a
port
as
being
empty
LS,
we
can
just
treat
it
as
MPLS
yeah.
D
E
Means
supposed
to
be
plain
text
or
can
be
TLS,
it
can
never
be
in
gray
area,
it's
either
one
or
the
other,
and
you
choose
what
it
is.
It
can
be
M
TLS
because
we
make
it
empty
restore
this
application
is
making
MPLS,
but
you
don't
have
to
use
proxy
protocol.
If
you
it
is,
if
you
are
clearly
one
or
another.
A
E
E
There's
not
a
position
was
that's
a
default
mode,
which
is
you
have
your
Porter
as
you
want,
as
uniquely
you
implement
them,
and
you
have
this
extra
ways
that
is,
is
useful
for
for
for
East,
you
and
and
for
other
applications
that
use
the
proxy
protocol.
It's
not
even
in
specific,
if
you,
if
we
go
with
the
standard
of
all
like
connector
proxy,
any
load
balance
that
would
go
to
this
port
and
and.
K
D
E
L
A
D
E
Want
what
that
is
not
the
bigger
picture
is
here
that
is,
is
that
telemetry
also
when
is
metadata,
and
they
are
implementing
some
sort
of
hack
to
pass
TCP
metadata
in
some
sort
of
headers
at
the
beginning
of
the
protocol.
So
we
telemetry
is
also
very
important
and
we
also
can
use
as
identity
and
other
things
in
for
TCP
protocol
is
a
proxy
others.
There.
A
D
That's
that's
the
protocol
abstraction
interface
inside
envoy.
That's
different
yeah,
like
the
actual
protocol
choice
for
the
the
transport
right.
We
just
have
basic
requirements
on
it.
It
should
be
relatively.
The
goal
is
to
make
it
relatively
fungible
right
right.
We
should
be
able
to
transition
from
you
know:
TLS
plus
HTTP,
connect
to
you
know,
quick
and
the
application
wouldn't
even
notice
that
anything
happened
other
than
CPU
changed
right.
That
would
be
a
goal.
That's
a
very
specific
goal
and.
D
That's
getting
a
bit
more
into
the
which
one
kind
of
rabbit
hole
but
John.
Coming
back
to
your
point
that
and
that's
the
reason
why,
right
now,
I
was
a
bit
worried
about
having
basically
one
additional
port
for
every
application
port,
because
you
have
to
know
what
they
are.
If
you
cared
about
the
underlying
firewall
rules,
it
seems
easier
to
tell
people
just
whitelist
the
tunnel
pork
and
go
use
is
do
our
back
to
get
the
property
that
you
want.
D
D
All
right
so,
leaving
aside
the
coming
to
the
other
track
for
a
second,
we
could
talk
about
the
nuts
and
bolts
of
which
protocol
would
actually
make
sense
in
terms
of
implementation,
cost
practicality,
utility
cetera,
so
Causton
brought
up
yesterday.
The
point
that
the
proxy
protocol
doesn't
communicate
metadata
from
the
server
back
to
the
client.
A
D
A
E
D
E
E
D
C
C
The
thing
I
liked
about
the
Connect
approach
was
it
sounded
like
there
could
be
a
layer
on
top
that
that
decides
they
say,
there's
an
abstraction
layer
where
you
decide
whether
you
do
connect
over
HTTP
1.1
or
connect
over
HB
2,
and
then
we
could
have
basically
connect
over
H
to
a
1.1
with
offloads
competing
against
connect
over
HTTP
2
and
see
which
one
does
better.
But
it
sounds
like
there's
a
lot
of
code
involved
in
doing
that.
I
hope.
E
A
D
Maybe
I
mean
I
mean
there's
also,
you
know,
I
guess
the
other
part
of
that
kind
of
performance
assessment
would
be.
You
know,
HCP
to
with
DP
DK
or
FDI
o
or
some
non
kernel
based
iolair,
at
which
point
we
might.
It
might
be
more
practical
to
talk
about
quick
than
HCP
right.
Yes,
so
that
might
be
the
choice.
C
D
D
E
A
E
D
A
A
C
E
C
D
D
Case
of
HTTP
connect
right
is
to
transfer,
is
to
be
able
to
go
through
an
edge
firewall,
and
then
it's
very
common
to
do
TLS
once
you've
connected.
This
is
actually
the
other
way
around,
where
you're
doing
TLS
and
then
you're
connecting
with
in
gos
both
are
fine.
Both
are
perfectly
valid.
It's
just
one
is
more
stronger
together,
Connect.
E
D
D
The
agenda
notes
to
say
we
think
the
H
to
connect
extended,
connector
or
h2,
probably
already
works
out
of
the
box.
Yeah,
there's
no
specific
objection
to
HTTP
connect,
HC
p11
connect
yeah,
it's
just
isn't
there
and
we
might
introduce
it
as
far
as
the
kernel
offloads
work,
it
Darrell
yeah
and
we
might
introduce
it
anyway,
a
non-void
because
it's
widely
used
feature.
E
D
M
D
D
D
Design
does
that
sound
reasonable
to
you,
yeah,
so
I
think.
The
other
thing
we
want
to
do
is
to
in
that
the
transport
abstraction
in
envoy
mm-hmm
put
in
the
right
level
of
interface
abstractions.
So
we
can
do
the
things
that
we
talked
about
right,
where
we
can
read
peer
identity
out
of
the
transport
and
metadata.
E
C
D
N
N
N
N
E
N
C
Issues
in
the
poll
requests
this
morning
trying
to
get
the
context
and
I
gotta,
say:
I,
think
you
did
a
wonderful
job.
I!
Think
that
you
you
really.
It
was
a
big
effort
and
you
did
a
lot
to
get
it
to
where
it
is.
I
think
that
enabling
this
by
default
after
CUNY
testing
would
invalidate
the
testing
that's
done.
We
just
can't
do
that.
I
think
our
options
are
either
repeat
the
testing
and
delay
their
release,
or
let
this
go
in
1/5.
What
do
you
guys
think
so?.
N
Yeah
thanks,
like
I,
am
fine
with
that,
but
I
just
want
to
clarify
you
mean
let
this
go
to
1/5,
which
means
that
that
it
by
the
first
1/4,
1/5
or
stok,
that's
optional
for
one's
life.
I
would
say
they
say,
assuming
that
we
have
enough
casting
for
performance,
that
we
have
or
down
all
those
exercise.
Yeah.
C
So
I
think
it's
it's
it's
a
timely
question,
so
yeah
so
well,
I
think
we're
already
in
the
point
where
it's
it's
opt-in
off
by
default
for
1/4,
so
we
can
have
I'll,
try
it
and
get
feedback
from
that
for
1/5,
whether
we
default
it
on.
You
know
the
traditional
testing
work
you
can
do
and
that
could
say
we
want
it
on,
but
we
now
have
this
other
competing
effort
with
Kinect
over
each
I.
Don't.
D
Because
I
think
that's
Danny,
you
can
so
Auto
MCLs.
The
feature
is
I
want
to
be
in
this
state
where
I'm
migrating
is
quickly
as
possible.
Security,
posture
right
and
there's
specific
steps
that
I
take
to
do
that.
The
proposal
for
the
the
different
transport
is
still
part
of
an
auto
better
security
posture
migration
right,
it's
just
like
if
it
was
default.
If
auto
MCAS
was
default
on,
it
would
be
equivalent
to
the
base
state
of
the
secure
transport
I
think
so
they're
not
strictly
competing
they're.
D
E
N
D
So
I
think
that
the
only
decision
at
this
point
is
is
the
feature
on
my
default
or
not
the
features.
Obviously,
shipping
and
customers
can
opt
it
and
the
only
argument
about
not
having
at
the
on
by
default
was
it
hasn't
gone
through
community
testing
and
there's
no
community
testing
scheduled
between
now
and
the
release
date
right.
Josh.
G
D
C
N
D
D
O
N
C
Good
yeah
and
and
I
I
keep
harping
this,
but-
and
this
is
not,
this
is
something
that
this
is
probably
having
a
lot
of
different
features,
but
actually
having
tests
that
try
to
exploit
or
bypass
and
actually
hit
security.
Bugs
I
would
love
to
see
more
of
those
so
general.
So
we
can
see
more
on
that
yeah.