►
From YouTube: Ambient Mesh WG Meeting 2023 01 11
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
A
C
D
Yeah,
so
one
of
the
things
that
I
noticed
last
week
in
one
of
the
PRS-
and
it
was
mentioned
in
the
pr-
is
the
experimental
ambient
Branch
isn't
necessarily
being
kept
up
to
date
with
the
changes
in
the
other
branches.
D
So,
for
example,
there's
an
ischio
proxy
post
submit
job
within
its
Master
Branch
to
update
the
master
branch
of
istio
istio,
but
today
we
don't
have
one
to
update
experimental
ambient
and
the
pr
last
week
was
basically
you
know.
We
haven't
been
updating
Envoy
in
the
experiment,
ambient
Branch
should
we
be
basically
well.
The
pr
was
to
do
it
and
I
know.
D
There
was
also
another
PR
I
did
last
week
to
update
the
common
files
within
the
experimental
ambient
Branch
as
well,
and
so
this
is
just
a
quick
discussion
item.
Should
we
have
particular
jobs
to
do
that
to
keep
the
branch
up
to
date?
I
know,
I
have
PR's
out
there,
which
haven't
been
looked
at
for
the
proxy
and
the
common
files
updates,
but
potentially
there's
other
ones
as
well.
You
know
that
we
do
API
package
client
go
things
like
that.
D
E
Yeah,
my
only
thought
was
that
it
I
mean
it
may
be
useful,
but
we're
still
diverging
from
istio
Master
as
well,
and
that
is
probably
not
something
we'd
automate
and
at
this
point
we're
going
to
merge
we're
going
to
kill
the
experimental
branch
of
merging
into
master
in
the
coming
months.
So
maybe
it's
not
worthwhile
to
invest
effort
into
this.
D
Yeah-
and
you
know
to
me,
you
know
my
only
my
only
thought
with
the
common
files-
one
at
least
yeah,
you
know
so
so
Envoy,
you
know,
I
I,
don't
know,
I,
don't
know
how
how
much
you
guys
are
using
that
want
the
changes.
D
So
do
you
want
them
all
the
time
but
I
know
like
with
common
files,
there's
a
common
files
update
which
contains
the
build
image
that's
being
used,
for
example,
when
you're
running
the
the
various
make
commands
or
whatever
we
do,
update
I
believe
the
build
file,
that's
used
by
the
pipeline
for
the
experimental
Branch,
but
we
don't
actually
update
the
one
that
would
be
used
locally
if
you
were
doing
it,
local,
so
I
that
that
so
to
me
at
least
it
made
sense
to
do
common
files
and
I
started
up
proxy
as
a
as
something
to
do.
D
We
could
not
but
I
leave
it
up
to
the
I,
leave
it
up
to
the
community.
At
this
point,
I
I
created
some
PRS
that
are
out
there.
I
think
John.
You
and
I
are
probably
the
two
that
just
need
to
get
together
and
talk
about
this.
E
Yeah
I'm
fine
with
it.
If,
if
someone
wants
to
do
the
work,
I,
don't
think
it's
the
most
pressing
thing:
if
we
do
common
files,
we
may
want
to
make
it
like
not
on
every
commit.
If
we
can
do
that,
just
to
avoid
noise,
I.
E
Big
of
a
deal
it's
just
the
whole
automation
ends
up
with
a
lot
of
PRS
in
the
master
branch
and
it's
probably
a
bit
excessive
on
experimental,
so
I'm
fine
with
it
I'm
perfectly
fine
without
it.
Hopefully
it
doesn't
matter
in
a
month
or
so
and
we'll
be
all
on
the
master,
Branch
anyways,
okay,.
D
And
that's
fine,
you
know
we
can.
We
can
leave
it.
That's
I
just
want
to
mention
that
all
right,
so
I
won't
worry
about
those
necessarily
and
then,
if
you
don't
mind,
facila
has
her
mentorship
thing.
D
I
know
she
can't
make
the
call
and
she
asked
me
to
do
it.
So
if
I
could
slide
it
quick
up
the
agenda.
A
F
Which
I
think
already.
D
Yeah
I
was
gonna,
say
it
was
mentioned
in
the
previous
meeting.
The
30
seconds
feel
is:
there's
some
mentorship
opportunities.
If
there's
something
that
we
want
some
menis
to
help
with,
and
you
missed
the
last
call,
and
you
want
to
talk
about
it,
you
can
either
ask
Taylor
or
myself
and
I'll
leave
it
at
that.
E
F
F
A
result
of
these
topics-
John
explained
me
everything
I
just
wanted
to
ask.
If
pilot
further
Gateway
cluster
conflict
will
be
used
in
context
of
Waypoint
purposes,
but
I
didn't
solve
that
document.
So
this
question
wouldn't
make
sense.
I
will
read
the
documents.
Maybe
I
will
come
back
if
this
will
be
necessary.
I
crossed
out.
Please
thanks.
E
Cool
yeah,
the
short
answer
is
the
exact
semantics
of
it.
No,
the
same
effect
of
action
scaling.
Yes,
so,
okay!
Thank
you
very
much.
The
next
one
me
and
Lynn
have
been
working
on
kind
of
a
doc
on
putting
together
what
exactly
all
the
various
apis
mean
and
how
they
work
in
ambient
and
what
differences
there
are
for
for
sidecars
and
whatnot
right
now.
The
docs
fairly
work
in
progress
me
and
Landon
both
went
off
on
our
own
and
then
merged
them
and
they're,
not
fully
merged
and
whatnot.
E
The
one
I
wanted
to
talk
today
about
is
authorization
policy,
because
I
think
it's
one
kind
of
blocking
some
ongoing
work
and
it's
kind
of
a
Bellwether
for
what
we
do
for
other
apis
in
my
mind,
so
the
Crux
of
the
debate
seems
to
be-
or
at
least
these
are
two
positions.
I've
heard
is
that
we
cut
either
stick
with
the
current
API,
where
authorization
policies
select
individual
workloads
with
the
label
selector,
or
we
can
move
it
to
attach
at
some
other
layer.
E
What
that
is
is
not
exactly
clear.
It
could
be
at
the
Waypoint,
so
that
would
probably
be
either
a
label
selector
matching
the
Waypoint
labels
or
possibly
without
a
direct
reference,
and
you
point
to
like
the
Gateway,
which
is
potentially
something
we
could
do
for
Ingress
as
well.
Another
option
could
be
maybe
it
attaches
to
service
accounts,
which
that
ends
up
being
largely
the
same
thing
as
attaching
to
a
waypoint,
it's
just
a
different
user
experience
and
how
we
get
there.
E
So
the
the
concerns
about
doing
workload,
selector
I,
believe,
are
largely
around
the
implementation
complexity
that
we
now
have
different
rbac
policies
based
on
some
Upstream,
that
we've
selected
during
load
balancing,
which
is
not
something
that's
typical
in
load
balancers.
It
makes
it
pretty
awkward
to
implement
an
Envoy.
E
Obviously,
the
benefits
of
the
other
approach
is
that
it's
very
flexible.
You
can
have
all
sorts
of
obscure
policies
where
one
pod
in
the
service
has
a
policy
the
other
one.
Doesn't
it
could
give
you
weird
Behavior,
like
your
load,
balancing
between
a
rejection
and
a
200,
but
if
the
user
specifies
that,
maybe
that's
what
they
want.
E
E
I
have
three
there's
effectively
two
options,
but
one
has
Nuance
like
we
can
bind
to
a
waypoint
via
label
selector
via
service
count
or
via
direct
reference,
but
how
which
of
those
is
kind
of,
not
that
important
they'll.
They
would
all
be
implemented
essentially,
the
same
way,
that's
just
kind
of
the
syntax
that
the
users
does
or
bind
to
the
workload.
E
The
service
is
like
similar
to
it's
the
way
it's
a
bit
different,
but
it's
yes.
G
E
I
F
I
G
E
A
G
G
G
G
99
of
the
time
people
are
doing,
selecting
everything
in
the
namespace,
selecting
everything
in
a
deployment
right,
which
is
the
same
as
selecting
everything
in
a
service
account
almost
then
it
would
be
a
less
disruptive
change
for
users
or
we
would
make
refined
decisions
about
how
to
represent
this
in
the
evening.
E
F
G
Well,
right
like
we
can
we
have
a
budget
for
disruption
right.
We
could
do
the
thing
where
we
tell
people
look.
This
Edge
case
is
not
supported
and
you
know
go
and
put
something
in
the
status
field
of
their
resource
until
they
still
validate.
To
tell
them
look
sorry,
you
need
to
go
and
make
some
adjustments
most
of
the
time
your
stuff
still
works.
So
we
didn't
give
you
an
upgrade
headache.
H
Better
okay,
so
my
my
point
was
trying
to
make.
Is
that
it
really
not?
It
is
not
an
option,
the
first
one,
because
it's
contradicts
the
design.
Okay,
it
contradicts
the
design
of
all
proxy
servers
in
the
world.
There
is
no
proxy
server.
That
applies
authorization
at
the
end
after
the
load
balancing.
So
it's
it's
a
design
that
it's
working
well
for
sidecars
I
mean
applying
policy
selection.
H
H
It
will
not
be
adopted
by
by
gamma.
It
will
not
be
about
gateways
it's.
It
will
not
be
adopted
by
any
infrastructure,
because
nobody
insane
in
the
world
is
doing
this.
I
mean
do
authorization
after
you
select
the
final
endpoint
and
have
different
results
based
on
what
the
load
balancers
have
happens.
To
tell
you
it's
simply
not
feasible,
with
with
the
design
of
of
gateways.
H
It's
it's
cycling,
so
it's
a
design
that
works.
If
you,
if
you
apply
it
locally
and
it's
a
design
that
works
for
IP
and
for
for
Network
policy,
because
again
the
Metropolis
is
a
sidecar
effectively.
It's
it's
apps
like
a
sidecar.
It's
not
a
waypoint
where
it's
it's
and
it's
not
integrated
load
balancing.
It's
a
completely
different
program.
I.
G
G
H
C
G
Have
an
implementation
principle
for
what
they
do
for
egress
policy
behind
load,
balanced,
IP,
okay
and
then
their
answer
might
be.
We
do
the
terrible
thing
right
like,
depending
on
which
endpoint
the
VIP
selects
right,
you'll
get
intermittent
failure,
or
they
may
say:
no,
we
just
don't
select
any
of
the
endpoints.
That
would
fail,
so
you
only
can
go
to
endpoints.
That
would
work
right,
I,
guess
those
are
the
two
choices
they
could
make
with
the
current
API
I.
Don't
think
I've
seen
an
answer
to
in
the
specification.
I
don't
know
anyone.
G
B
H
A
I
totally
agree
and
I
think
you
know
conceptually
or
when
I
first
think
about
this
problem.
I
I'm
thinking,
natively,
intuitive
I,
combine
to
my
Waypoint
because
I
have
a
waypoint,
but
if
you
think
about
now,
I
need
to
maybe
create
my
layer,
7
and
layer
for
policy,
and
maybe
I
have
them
in
a
single
policy.
Now
do
I
want
to
use
different
selector
for
my
layer,
four
was
layer,
seven,
probably
not
so
I
think
that's
the
advantage
of
binding
to
workload.
It's
just
it's
more
intuitive
to
the
user,
but.
A
A
F
G
G
G
J
Sure
so
it's
the
core
question
here.
When
it
comes
to
workload
selector,
are
we
trying
to
figure
out
if
workload
selectors
effectively
a
proxy,
that's
overload
a
term?
Is
it
effectively
a
a
substitute
of
intent?
Force
like
a
service
account
selector,
is
that
kind
of
the
core
question
here.
G
J
I
know
I
can't
help
but
Wonder
if,
if
kubernetes
had
optimized
something
like
service
account,
selector
and
I
was
around
with
issue
long
enough
to
know
this.
But
if
service
account
selector
were
a
thing,
would
workload
selector
have
even
been
as
broad
as
it
is
Maybe,
but
an
anecdotally
from
the
customers,
I've
I've
talked
to
labels
are
effectively
used
as
a
to
elevate
service
account
to
a
queryable
level
and
outside
of
that
I
started
that
problem.
It
feels
like.
That's.
J
A
C
C
I
have
a
question
in
this
model.
If
we
want
to
express
the
semantic
of
let's
say:
if
you
want
to
access
billing
service,
you
must
have
a
short
token
with
identity
bar.
So
in
this
model,
the
building
service
is
represented
by
a
service
account,
and
is
that
or
I
totally
misunderstand:
it.
A
C
G
Okay,
right
and
so
cool
and
John,
like
very
concretely
the
problem
we
had
one
of
the
large
implementation
problems
we
have
is
it's.
The
policy
applies
to
the
selected
endpoint
right.
We
have
to
resolve
the
set
of
labels
for
the
target
endpoint
right
in
the
pipeline
somewhere
to
be
able
to
implement
the
policy.
G
And
so
this
makes
it
difficult
to
use
on
the
way
out
of
the
box
to
solve
this
problem
right.
We
have
to
effectively
do
an
internal
loopback.
We
have
to
run
for
the
pipeline.
Select
the
endpoint
extract,
its
labels
go
through
another
pipeline
just
so
we
can
implement
the
op
Z
policy
and
kind
of
do
an
original
destination
shenanigans.
I
G
E
One
thing
I
want
to
add
too
is
I
I
tried
to
scope
this
to
Aussie,
because
I
think
it's
clearer
and
it's
important,
but
this
actually
applies
to
almost
all
of
our
apis
right
like
does
it
make
sense
to
apply
a
wasm
policy
per
workload,
or
do
we
also
move
that
up
to
whatever
level
we
apply
to
this
right
Telemetry
same
thing
as
we
start
going
to
those
I,
don't
actually
know
where
other
things
doing
Wazoo
apply
it
I
could
see
an
argument
for
applying
mozamana
per
pod
basis
like
a
canary
rollout,
adding
my
Watson
policy.
E
G
G
B
Yeah
I
just
want
to
make
one
point
that
yeah
I
was
a
I,
am
considering
adding
the
oxidation
bind
points
to
a
waypoint
I
think
this
makes
sense,
especially
for
the
L7
policies,
but
for
L4
policies
on
sitano
binding
to
the
workload
but
into
the
label.
Selector.
Still,
it's
a
good
model.
E
Is
it
confusing
when
I
I
don't
know
if
I
think,
if
we
were
remove
this
from
Waypoint,
we
should
also
remove
it
from
Z
tunnel,
because
then
it
becomes
confusing
that
I
apply
an
L4
policy,
that's
a
workload
selector.
It
works
fine
on
Z
tunnel
and
then
I
add
a
waypoint
and
suddenly
I
can't
use
that
right.
Yeah.
A
I,
wouldn't
want
consistency
yeah.
That
was
my
major
concern
too,
because
a
lot
of
our
policy
when
we
give
the
example
it
starts
with
layer,
4
and
then
by
the
way,
I'm
adding
a
post
message
right,
so
it
becomes
layer
for
plus
layer,
7
and
now
you're
asking
me:
hey
I
need
to
change
my
labels
just
because
I'm
now,
a
layer,
7
policy
now
I.
A
E
B
Yeah
I
think
for
customer
for
customer
to
Define
policies.
They
shouldn't
care.
If
this
is
L4
only
or
this
is
L7,
so
you
can
say,
bind
the
12
Waypoint
or
buy
into
workloads.
A
B
Yeah
then,
in
that
case
they
are
actually
not
defining
the
right
policy
right.
They
they
say
this
policy
applied
to
Waypoint.
However,
all
the
properties
are
oh
wait.
Waypoints
can
only
can
also
enforce
The
L4
policies
right
only.
G
Okay,
so
we
have
this
somewhat
fundamental
question
right,
like
regardless
of
the
policy
type.
G
H
Probably
so,
let's
focus
on
L7
and
waypoints
I
mean
we
don't
have
necessity
to
have
exactly
the
same
answer
to
both
questions.
We
can
keep
L4
because
it's
about
digital
one
way
and
the
other,
but
for
waypoints
in
particular,
I
think
it's
important
to
get
take
into
account.
Other
infrastructures
that
may
Implement
waypoints
I
mean
there
is
a
side
Channel
discussion
about
what
AWS
is
doing.
Google
is
doing
pretty
much
the
same
thing,
all
vendors.
H
You
know
the
existing
infrastructure
in
Google
and
internal
infrastructure
is
kind
of
the
same
way.
I,
don't
think
we
have
a
way
to
apply
policies
before
so
it
will
be
highly
desirable
to
have
solutions
that
is,
can
be
implemented
not
only
to
avoid,
but
with
any
other
infrastructure
that
that
exist
today,
which
is
today.
B
F
E
Say
we
can
find
through
both
yeah,
so
we
can't,
we
don't
want
to
say,
bind
to
both
because
it's
problematic
to
implement
binder
workload.
So
if
we
go
down
that
option,
if
we
even
support
it
for
edge
cases,
it's
a
load
of
work
for
us
to
do
so.
We
may
decide
that
it's
worth
it
to
keep
our
existing
API,
but
if
it's
not
I
mean
we
could
do
both.
But
then
it's
just
a
ton
of
work
right.
The
main
discussion
here
is
not
doing
that
work.
E
G
H
Before
we,
we
we,
when
you're
here
I,
would
slightly
disagree
long
term
if
a
waypoint
is
shared
across
multiple
service
accounts
seems
to
be
slightly
different.
So
let's
be
clear
that
bind
to
service
account
or.
G
H
E
E
B
G
H
D
H
Think
I
think
we're
confused
a
bit.
The
the
use
case,
as
I
mentioned,
is
Easter
deal
and
any
applications
using
help.
So
if
you
have
an
application
like
this,
you'll
be
using
a
service
account
because
of
help
requirements,
V1
and
V2
of
the
application
will
have
to
have
two
different
service
accounts
just
like
we
do,
because
otherwise
they
conflict
and
you
cannot
install
it
so.
G
G
H
G
G
I,
don't
think
it
violates
that
the
basic
principle
of
the
grouping
mechanism
for
the
policy
matches
the
granularity
of
the
Waypoint
in
terms
of
its
selectivity
for
the
workloads
right.
If
this
Waypoint
is
for
these
two
service
accounts,
then
the
policy
is
selecting
two
service
accounts
right.
They
have
the
same
granularity.
G
E
Yeah
I
was
just
going
back
to
something
that
you
said
earlier
about
like
the
granularity
matching
and
that
we
could
say
deploy
a
waypoint
just
for
a
single
workload,
I'm
worried
that
may
become
problematic
because
then,
for
example,.
G
E
I
know
I
get
it,
but
yeah
like
a
single
service,
then
has
multiple
waypoints
and
like
what
does
it
mean
when
we
call
the
service
like
which
Waypoint
do
we
select?
We
have
a
solution
for
that,
but
it's
kind
of
bad.
H
H
H
G
You
don't
necessarily
want
to
get
distracted
by
my
own
straw.
Man
like
at
any
level
of
selection,
is
going
to
create
some
compositional
difficulty.
We
have
to
choose
ones
that
make
sense
or
are
implementable
or
useful.
G
So
let's
talk
about
the
hard
for
a
second
right.
What
we're
really
talking
about
is
the
difficulty
of
the
envoy
pipeline,
so
we
talked
about
service.
We
also
have
direct
to
pod
traffic,
which
a
waypoint
has
to
be
able
to
deal
with.
G
Logically,
what
would
happen
if
we
wanted
to
implement
what
exists
today?
Is
you
tried
to
talk
to
a
pod?
The
Waypoint
listens
on
the
part
IP
and
port
If
the
product
when
it
receives
traffic
on
a
given
pod
IP
in
Port,
it
decorates
the
request
with
the
labels
of
the
Pod,
and
then
the
policy
is
executed
based
on
labels.
Right
logically,
is
that
roughly
what's
happening
today
or
we're
doing.
E
Some
fun
yeah
I
mean
it's
not
There's,
No
Label
selection.
We
just
push
down
the
set
of
policies
that
apply
to
each
workload
and
we
have
a
whole
listener
chain
for
each
workload.
H
But
it
could
attach
to
to
effectively
to
the
route
or
to
deploy
them
into
a
service.
Account.
I
mean
if
we
consider
Bank
to
Waypoint
to
the
approxy,
for
buying
to
service
account
or
canonical
service
accounts,
and
it's
kind
of
the
same
thing,
because
we
attach
the
policy
to
the
service
account
important.
E
G
I
E
I
E
G
H
F
G
G
H
C
G
H
C
G
H
G
B
H
A
So
can
we
ask
a
user
so
basically
we
are
keep
if
we
go
down
to
optional
one
we're
keeping
the
same
API
as
authorization
policy,
but
the
semantics
of
changes
on
the
selector
right.
So
it
actually
selected
the
Waypoint
with
the
actual
workload.
So
could
we
ask
a
user
to
kind
of
using.
I
A
I
mean
they're.
Existing
authorization
policy
could
potentially
continue
to
work
without
any
change
right,
because
the
label
selector
would
just
select
a
waypoint
now
with.
G
A
A
B
Actually
I
have
one
question:
I
I,
don't
know
if
it's
discussed
earlier,
how
is
customer
always
manually,
deploying
Waypoint
or
is
Waypoint
always
visible
to
customer
or
is
it
is
it
going
to
be
automatically
deployed
if
we're
saying
okay,
so
one
service
control,
one
workload,
Waypoint
is
automatically
deploying
behind
the
scene.
No.
E
So
they
have
to
Signal
the
intent
just
like
injection
they
have
to
label,
they
have
to
create
a
Gateway
which
will
deploy
it,
but.
H
G
A
E
F
H
Again,
my
question
is
that
eventually
we
don't
want
to
have
the
Waypoint
as
a
workload,
but
ideally
for
a
lot
of
users.
The
Waypoint
will
be
a
shared
infrastructure
multi-tenant.
You
know
sure.
K
G
G
H
B
H
G
A
I
do
have
a
question
on
one
I.
Think
Louis
you
just
mentioned,
bind
to
Waypoint
doesn't
mean
there's
actually
a
waypoint
pod,
because
I'm
trying
to
think
how
option
one
works
with
layer,
4
policies.
E
I
yeah
I've
been
thinking
the
same
thing
I
like
binding
Waypoint,
because
then
we
can
do
the
same
for
Ingress
and
say
you
bind
to
gateways
that
could
be
your
Waypoint
or
that
could
be
your
Ingress
Gateway.
But
then
it
is
problematically.
If
you
don't
have
a
waypoint,
we
could
also
do
bind
a
service
account
which
would
be
fine
for
Waypoint
or
no
Waypoint
yeah.
A
G
Yes,
it's
yeah,
it's
probably
misleading,
to
say
point
to
Waypoint
right.
What
we
really
mean
is
we're
binding
to
the
same
granularity
of
thing
that
the
Waypoint
itself
is
bound
to
right.
Either
service
account
namespace
or
something
else.
F
A
C
E
H
E
E
G
E
G
G
We
again
have
to
ask
users
and
go
look
at
existing
all
Z
policies
like
if
there
are
no
all
Z
policies
out
there
today
that
are
L4.
Only
that's
an
easy
choice
to
make
right.
G
If
all
L4
policies
out
there
are
just
based
on
service
account,
it's
a
slightly
more
complicated
choice
to
make,
but
at
least
it's
like,
we
could
deal
with
it
mechanically
I
convert
them
into
Network
policies
right.
So
that's
the
that's
what
sorry
damn
headphones
again,
we
need
to
know
what
user,
what
the
policies
look
like
all
right.
G
K
No
I
mean
it's
also
not
really
possible,
because
you
lose
all
four,
you
don't
get.
You
don't
get
The
L4.
What's
the
word?
Sorry
like
you
can't
do
any
PLS
anything
based
on
like
TLS,
so
yeah
or
our
back.
It's
like
it's
I,
don't
see
it
being
possible,
but
it
would
be
very
nice
because
you'd
have
a
much
cleaner
separation
of
concerns.
G
With
network
policy,
we
can
simulate
the
properties
of
mtls
by
having
synthetic
labels
be
interpreted
in
the
rule.
Yes,
John
I
think
you
only
talked
about
that.
There's
a
way
to
model
it
within
the
existing.
K
Api
for
service
accounts,
they
say
you
know:
I
O,
kubernetes
service
account
blah
blah
blah.
I
E
You
really
like
about
that
option
is
that
if
we
think
about
the
other
apis,
they
only
applied
a
waypoint,
and
so
attaching
to
a
Gateway
is
I.
Think
the
best
experience
it's
only
the
Z
tunnel
thing
that
becomes
problematic,
but
that
doesn't
matter
for
the
other
ones.
So
we
could
say
like
wasm
Telemetry
they
apply
to
Gateway,
applying
to
service
account,
so
I
kind
of
love,
one
yeah.
F
C
K
G
G
E
G
G
E
G
H
G
Yeah,
absolutely
so,
if
anybody
has
the
ability
to
go
and
talk
to
one
of
their
large
customers,
what
we
should
do
is
we
should
write
down
the
list
of
key
questions
and
then,
if
people
can
go
and
talk
to
some
people
and
get
answers
to
those
key
questions
and
it's
quite
difficult.
H
G
A
E
E
I
will
at
least
put
together
a
proposal
of
what
it
would
look
like
if
we
do
what
we
talked
about.
Maybe
we
maybe
won't
move
forward
with
implementing
it,
but
so
we
can
at
least
see
it
on
paper
instead
of
for
number
one
yeah
with
the
whole,
not
just
authorization
but
Network
policy.
Everything
binds
to
Gateway
obviously
is
only
for
Waypoint.