►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20230313
Description
SIG Network Gateway API Bi-Weekly Meeting for 20230313
A
A
We
are
trying
to
do
the
attendees
list
for
these
meetings,
because
we're
trying
to
figure
out
alternate
times
and
stuff
like
that.
We
want
to
know
who's
attending
what
so,
if
you
would,
please
put
your
name
and
Company
down
on
the
document
under
attendees.
We
would
appreciate
that
all
right,
I
should
probably
share
my
screen
here.
A
Okay,
okay,
everybody
see
my
screen
just
fine.
Let
me
know
if
I
need
to
zoom
yep
all
right,
then,
let's
get
started
with
the
agenda.
We
do
have
a
little
bit
of
an
agenda
today,
but
anybody
here,
that's
new
I,
don't
see
anybody,
but
if
you
have
something
on
your
mind,
please
do
add
it
to
the
agenda.
If
we
can't
get
it
to
to
it
today,
we
can
always
try
and
do
it.
Next
week,
Candace
I
think
comment
from
Rob
from
January
23rd,
Ingress,
Focus,
config
filter.
B
I
can't
share
it
with
with
everybody
in
this
group,
but
I
did
share
it
with
the
maintainers
and
I
wanted
to
see.
If
you
guys
are
good
to
go
ahead
and
and
are
we
good
to
go
ahead
with
a
gap
for
this,
and
this
is
based
on
filters
which
I'm
not
a
hundred
percent
familiar
with,
but
I
just
used
the
the
API
and
cut
and
paste
a
few
things
from
get
1282
to
specify
this,
and
maybe
I
can
share
my
screen
or
one
of
you
or
Shane.
A
A
A
A
C
B
Mentioned
Ingress
TLS
on
the
Gateway
data
plane,
and
this
is
the
probably
the
the
most
explanatory
sentence.
What
we
want
to
do
with
this
is
to
satisfy
the
use
case
where
the
back
end
pod
has
its
own
certificate
and
the
Gateway
implementation
client
at
the
Gateway
implementations
client
needs
to
know
how
to
connect
to
the
back
end
pod,
and
these
last
two
bullets
are
from
the
previous
Gap
and
also
needs
to
be
tightly
bound
to
the
back
end
rather
than
the
route
and
the
service
owner
is.
B
A
A
The
service
owner
part
makes
sense
to
me,
but
in
this
stock,
have
we
like
kind
of
fleshed
out?
Why
is
that
down
in
the
introduction
somewhere?
The?
Why
like
what
this
is
used
for,
because
at
least
at
the
top,
like
in
the
tldr
and
stuff,
like
that,
the
Y
might
be
like
clear
to
some
of
us,
but
I'm
not
sure
it
would
be
clear
to
just
any
reader
that
came
in
here.
B
A
But
I
yeah
I,
think
all
I
was
going
to
say
is
just
like
the.
Why
you're
trying
to
do
something
like
as
soon
as
you
can
tell
somebody
why
you
want
to
do
something?
Do
it
I
mean?
Sometimes
you
have
to
get
really
involved
and
do
like
user
stories
and
stuff
like
that,
but
I
think
that's
the
the.
Why,
for
this
is
fairly
straightforward,
I.
D
B
So
this
is
just
something
that
keeps
going
around
and
around
and
I
feel
like.
This
is
a
I'm
trying
really
hard
to
whittle
it
down
here.
So
it
may
look
very,
very
basic
and
very
Bare,
Bones
and
I'm
willing
to
fill
in
if
needed,
but
just
having
the
references
back
to
these
may
may
fill
in
more
details,
so
anyways,
given
all
that
background
for
it.
B
What's
missing
in
in
in,
in
our
opinion,
in
my
team's
opinion
and
some
other
lots
of
those
other
17
issues
is
the
way
to
handle
TLS
from
the
gateway
to
the
back
end
pod,
and
that
should
sound
familiar
based
on
on
what
we've
talked
about
so
far.
So
here
again
is
the
use
case.
We're
satisfying
the
use
case
for
the
back
end.
Pod
has
its
own
certificate,
and
the
Gateway
client
needs
to
know
how
to
connect
to
the
backend
pod.
B
B
So-
and
this
is
just
straight
from
from
from
the
API
documentation-
filters
can
be
used
to
specify
additional
processing
steps
and
there
are
other
use
case.
There
are
other
other
types
already
implemented
that
help
with
request
response,
modification
and
authentication
strategies
rate
limiting
traffic
shaping,
and
that
is
basically
what
the
filter
is
there
for
it's
a
it's
under
the
the
rule
for
an
HTTP
route
and
and
closely
tied
to
the
back
end
and
under
the
back
end
graph.
If
I
have
that
right.
B
So
this
in
this
case,
we
already
have
a
bunch
of
HTTP
route
filters,
and
this
would
be
adding
a
new
one
called
TLS
filter
to
the
HTTP
route.
Filter
listing
just
defines
a
schema
and
for
for
information
that
helps
figure
out
the
TLs
connection,
but
it
helps
the
client
figure
out
the
TLs
connection
and
and
how
to
use
it
and
the
fields
that
I
am
supplying
for
the
TLs
filter
are
copied
from
the
old
Gap
that
was
closed,
the
old
Gap
being
too
generic,
but
too
specific
in
this
area.
B
B
You're
ready,
yeah,
okay,
so
within
the
HTTP
route
spec
we
have
the
rules
at
the
back
end,
ref
I,
think
I.
Think
I
have
this
right,
I
might
be,
I
might
be
doing
this
wrong.
Someone
will
correct
me
I
think,
and
under
the
back
end
ref.
We
have
tied
to
it
this
this
this
filter,
this
new
filter's
name
is
TLS
filter
and
it
has
the
the
fields
that
I
I
mentioned
above
in
this
section.
A
I
did
me
myself
all
right.
No
questions.
I
have
like
a
comment,
so
I
think
it's
good
that
we're
that
you're
pushing
for
this,
and
thank
you
for
sharing
the
doc
and
so
forth.
I
think
that
that
Y
is
going
to
be
really
important
to
tease
out
and
then
I
would
suggest,
even
though
it
might
seem
a
little
bit
more
cumbersome
because
I
could
see
there
being
some
some
contention
in
the
ju.
A
You
know
just
the
overall
idea
here:
I
would
suggest
putting
down
the
Gap
after
you
get
the
Y
teased
out
and
somewhere
between
the
tldr,
the
goals,
non-goals,
and
maybe
the
introduction
you
kind
of
have
that
pretty
clear
and
up
front,
leaving
out
all
the
implementation
details
and
just
putting
in
a
PR
to
get
that.
So
we
can
just
get
an
inventory
of
everybody.
Like
everybody
see
the
use
case
for
this.
A
Do
other
people
need
this,
that
kind
of
thing
and
get
that
figured
out
first
and
then
follow
it
up
with
the
how
which
is
like
the
spec
of
stuff.
That's
going
on
here,
because
it's
possible.
We
might
not
it's
possible,
even
in
the
process
of
talking
with
other
community
members,
about
the.
Why
and
like
wanting
to
do
this,
that
there
might
that
might
help
influence
the.
How
so
that's
just
my
that's
just
my
kind
of
advice
about
how
to
move
forward,
but
I
do
think
you
should
move
it
forward.
A
B
A
So
long
I'm
open
to
your
intuition
on
that,
if
you
really
feel
like
it
should
just
as
is
basically
go
I
think
you're
ready
to
like
take
it
to
actual
get.
But
if
you
think
that
you
know
you've
got
the
support
and
stuff
like
that,
then
ignore
me:
I.
Just
think
that
it
might
be
helpful
because
even
now,
I
just
feel
like
there's,
potentially
anyway
I'm
going
to
take
up
too
much
time.
But
that
was
just
my
my
thought:
go
ahead:
Howard
John
I
think
it
was
Bowie's
next
yeah.
E
F
E
F
Yeah
I
mean
that
was
that
was
my
thinking
originally,
and
that
was
why
we
we
said:
oh,
let's,
have
a
separate
resource
and
then
that
would
that
blew
up
into
a
big
thing,
so
this
is
trying.
This
is
Candace.
Trying
to
you
know
so
find
some
minimal
set
of
functionality
that
we
can
talk
about.
So
this
is
one
of
the.
This
is
one
of
the
things
I
think
I'm
going
to
swear
Shane's
point
about
talking
about
the
the
where
and
the
why
I
mean
the
the
essential
change
here.
F
That's
different
to
what
we
talked
about
before
is,
rather
than
decorating
like
the
service
resource
and
having
some
sort
of
wrapper
or
some
addition
onto
the
service
resource,
we're
adding
a
filter
into
the
the
route
resource.
So
it's
a
slightly
different
Focus.
It's
a
slightly
and
the
the
the
thing
that's
different
is
that
yeah
as
John
says
then
you'll
need
to
specify.
So
the
downside
of
doing
a
filter
is
that
you
have
to
specify
in
every
place.
F
You
refer
to
the
service,
so
I
think
that's
the
trade-off
of
doing
this,
so
I
think
the
that's.
That's
probably
the
the
I
think.
That's
probably
the
the
thing
that's
probably
worth
considering
doing
what
Shane
is
talking
about
and
sort
of
putting
in
the
goals
in
the
introduction
and
sort
of
saying
hey.
F
We
want
to
do
this
with
a
filter
because
we
tried
to
do
it
before
with
with
something
more
fancy
and
it
didn't
go
anywhere
and
we
want
to
get
this
moving
and
then
and
then
we
can
talk
about,
and
then
we
can
talk
on
that
PR
and
sort
of
decide
if
the
filter
is
the
right
approach
or
if
we
should
do
something.
That's
you
know
that,
as
John
says,
is
is
more
like
is
more
sort
of
per
service
rather
than
per
route.
D
D
You
know
that's
my
protocol
I'm
using
and
then
there
is
mtls.
Of
course
that's
like
a
big
one.
So
then
there
is
also
the
server
wants
to
control
the
ca
and
doesn't
want
to
just
trust
anything.
That's
coming
in.
It's
like
I,
think
I,
don't
know.
If
we
can
make
a
choice
there
and
say
only
a
few
of
those
paths
are
actually
supported,
but
that's
my
general
take
is
like
we
need
to
look
at
all
those
cases
and
see
there.
F
D
F
Yeah,
we
haven't
really
I,
think
Candace
is
definitely
sort
of
done,
a
pretty
good
job
of
making
it
clear
that.
Forgive
me
if
I'm
putting
words
in
your
mouth
here,
but
that
you're
definitely
very
interested
in
handling
this
most
simple
use
case.
First,
like
you
know,
you
haven't
said
explicitly,
but
my
gut
feeling
is
that
you
have
some
customers
who
are
like
I
would
like
to
be
able
to
do
this.
F
We
have
been
talking
about
this
for
over
a
year
and
you
know-
and
we
haven't
done
anything
because
we've
been
a
bit
Paralyzed
by
all,
but
we
need
to
address
all
of
the
use
cases,
and
so
you
I'm
kind
of
in
favor
of
us
doing
something
and
trying
it
out
putting
in
experimental
if
we
need
to
over
continuing
to
over,
like
to
just
sort
of
ensure
that
the
thing
that
we
can
do
can
handle
every
possible
use
case.
I.
D
A
Yeah,
there's
there's
going
to
be
a
lot
of
discussion
on
this
I
think
so
we're
getting
close
to
30
minutes,
so
it
should
probably
as
much
as
possible
take
that
async
if
the
dot
can't
be
I.
Put
a
comment
on
this
in
the
chat,
but
if
that
can
be
shared,
I
think
now
is
a
great
time
to
just
start
gapping
it.
So
we
can
start
doing
that.
Go
ahead.
Rob.
G
G
C
G
B
G
G
That
feels
like
it's
going
to
have
a
ton
of
comments.
It's
helpful
to
get
the
first
round
of
them
out
in
a
dock
and
then
have
round
two
in
a
PR,
because
if
you
start
to
have
a
PR
with
hundreds
of
comments,
it
just
becomes
a
pain
to
deal
with
same
with
the
doc.
But
this
just
kind
of
splits
it
up
a
little
bit.
A
Yeah
yeah
it's
kind
of
what
it's
kind
of
up
to
you,
but
that
was
kind
of
my
point
with,
like
maybe
making
just
just
part
of
it
into
the
Gap
at
first,
because
that
narrows
what
we
can
actually
talk
about
down
to
something
that's
a
little
bit
more
reasonable
for
a
PR
and
might
may
allow
us
to
just
get
that
solved.
The
one
thing
not
end
up
with
three
different
four
different
comment:
threads
get
that
merged,
so
that,
then
you
have
a
provisional
Gap,
it's
real!
A
It
exists
and
we
can
move
forward
with
it
with
other,
smaller
PRS.
But
that's
again,
my
preference.
So
it's
kind
of
up
to
you,
I'm
I'm,
going
to
reach
out
to
you
on
Community
slack
and
just
I'm
gonna
try
to
be
available
to
to
you
to
like
support
you
in
whatever
way.
I
can
to
help
push
this
forward,
because
I
know
that
you're
tired
of
this
being
stuck
so.
F
A
A
Okay,
all
right,
Rob
and
I
want
to
talk
about
upcoming
releases,
so
v062
is
going
to
be
another
small
patch
release,
just
mostly
focused
on
us,
releasing
more
often
and
not
taking
forever
to
do
releases.
So
the
exercise
of
that
causes,
learning
and
also
it's
just
it's
just
generally
a
good
exercise.
A
G
Yeah,
so
I
also
want
just
one
more
thing
on
062,
thank
you
to
Shane,
I,
think
you're,
the
one
who's
been
adding
Milestones
retroactively
to
bug,
fixes
or
other
things,
new
conformance
tests
that
we
believe
belong
in
the
062
Milestone
and
then
just
manually
cherry
picking
them
prior
to
release.
So
if
you
have
a
PR
or
something
like
that
is
in
the
vo62
Milestone
rest
assured
that
it's
going
to
be
in
that
release.
G
G
Yeah,
that's
all
so.
070
release
really
also
trying
to
get
that
out
soon.
The
age-old
thing
we
try
and
release
before
kubecon
in
this
case
and
in
this
case
I
think
the
major
changes
I'd
like
to
get
in
are
the
path
read.
Rex
and
rewrites
GAP
graduating
that
through
the
standard,
Channel,
there's
a
couple
other
bigger
things
in
here,
but
as
you
can
see
by
the
size
of
this
Mazda,
we're
gonna
have
to
pull
a
lot
of
things
out
of
this
milestone.
G
Given
our
relatively
limited
time,
I
don't
know
that
we're
going
to
be
able
to
do
the
triage.
Maybe
we
can
come
back
to
this
if
we
have
time
at
the
end,
but
this
this
Milestone
is
far
larger
than
we
can
possibly
fit
in
in
the
next
few
weeks.
So
we
do
want
to
get
070
out.
It's
just
need
to
be
very
targeted
about
what
we
want
to
include.
G
If
you
see
something
on
there
and
you're
assigned
to
it,
maybe
comment
if
you
think
you're
going
to
be
able
to
get
there
in
the
next
couple
of
weeks
and
if
not
we'll
just
pull
it
from
the
and
and
lack
of
comment,
we'll
just
lead
us
to
assume
it's
not
going
to
get
in
the
next
couple
of
weeks,
yeah
and
Shane
you've
got
this
is
a
good
transition
into
your
project
board
yeah.
How
about
it.
A
This
is
oh
sorry,
yeah
I
just
started
doing
that.
I
apologize,
but
I
should
tell
you
what
I
was
doing.
I
just
wanted
to
take
a
look
at
it
on
the
board,
so
yeah
we
have
all
of
these
things
in
progress,
seven
things
that
are
not
I'm,
not
sure
everything
is
we'll,
have
to
double
check
on
some
of
these
to
make
sure
they're
all
actually
in
progress,
but
definitely
seems
like
we'll
have
to
do
that.
A
G
F
The
timeouts
one
is
really
gated
behind
the
the
policy
attachment
update
and
because
but
I
think
that
there
are
two
candidate
timeouts
that
the
review
that
I
did
has
confirmed.
We
should
be
able
to
do
that
are
pretty
broadly
implementable,
so
I
think
that
we
can
add
a
timeouts
policy,
a
timeout
policy
with
two
like
broadly
implementable
timeouts,
that
will
mean
more
or
whatever
the
hell
we
Define
them
to
mean,
but
that
should
be
implemented
should
be
implementable
by
most
of
the
data
planes.
G
G
G
If
you
see
something
that
is
missing
from
either
of
these
releases,
don't
hesitate
to
chime
in
on
this
meeting
and
chat
in
slack
wherever
we
don't
want
to
leave
things
out
unnecessarily,
but
we
are,
as
Shane
mentioned,
trying
to
get
to
a
fast
release
Cadence,
so
it's
less
painful
to
misrelease.
If
you
do.
A
G
This
is
this
is
a
really
quick
one.
I,
don't
know
how
many
people
are
going
to
be
able
to
make
it
to
contrib
Summit
maybe
show
like
raised
hands
or
something
like
you
know,
reactions
whatever,
but
if
you're
going
to
be
able
to
make
it,
we
would
love
to
to
meet.
You
know
have
some
kind
of
Gateway
session
Gateway
related
session,
there's
a
cfp
for
contrib
Summit
that
is
open,
now
I
link
to
it.
Anyone
is
welcome
to
submit
something
there.
I've
been
thinking
about.
G
You
know
you
know
conformance
having
one.
You
know
trying
to
think
about
who's
going
to
be
there
and
what's
going
to
be
most
valuable
and
the
idea
of
trying
to
do
things
that
cross
Sig
boundaries
feels
really
potentially
helpful
so
trying
to
move
forward
on
conformance,
which
has
a
lot
of
overlap
with
cigarch
and
reference
Grant,
which
is
moving
to
Sega
but
open
to
any
other
ideas
out
there.
Just
trying
to
circulate
that
in
case
someone
wanted
to
collaborate
on
something
more
contribute.
G
G
G
All
right,
the
next
thing,
I
added
a
bunch
of
things
on
here,
but
let
the
last
thing
for
me
for
a
while
is
redirect
loop
protection.
There's
a
PR
that
kind
of
forced
the
issue
a
little
bit,
which
is
all
caused
by
an
issue.
I
created
actually,
but
there's
been
some
ambiguity
in
the
API
right
now
as
to
if
you
can
specify
a
redirect
filter
and
a
back-end
wrap
as
part
of
the
same
route
rule
and
what
happens
so
Travis
added
I.
Think
it's
Travis
added
an
issue
that
suggested
hey.
G
Could
we
add
a
concept
of
redirect
loot
protection?
So
if
there's
a
redirect
to
say
HPS
and
you're
already
at
you're
already
at
https,
then
just
you
know
go
through
the
rest
of
the
rule
and
forward
to
the
back
end
refs
associated
with
it.
So
basically
a
way
of
requiring
https
for
a
given
route
and
then
having
the
the
back
end
rafts
associated
with
it.
F
And
I
think
the
the
loot
protection
sounds
like
a
good
idea.
It
does
sound
like
it
might
be
hard
to
implement,
although
we
might
be
able
to
do
something
a
little
bit
like
the
some
of
the
changes,
I've
kind
of
suggested
in
a
couple
of
cases
for
the
redirect
things
where
it's
like,
where
we
have
specifications
about,
if
the
location,
the
generated
location
header
would
be
then
do
this.
F
You
know
so
like
right
now
the
the
thing
that
we
have
in
there
that
you,
like
the
issue,
that's
actually
a
bit
unclear
I,
had
I,
did
put
a
comment
on
the
issue
that
you
liked
about
that.
But
basically
the
idea
here
is
that
there's
there's
rules
in
there
that
are
intending
to
say
something
like
if
you're
using
HTTP
and
the
redirect
Port
comes
out
to
be
Port.
80,
then
don't
include
the
port.
F
A
A
So
if
there's
like
nobody,
that
does
I
think
we
can
right,
we
can
take
this
like.
If
we
have
this
validation
in
place
and
just
says
Nope,
we
can
eventually
remove
that
if
we
have
something
else
in
place,
that
would
protect
them,
so
we
can
grow
from
here.
If
we
don't
know
anybody,
who's
like
I
need
to
not
have.
This
is
a
problem
for
me.
Right
am
I
thinking
about
it
wrong.
F
A
A
We
needed
to
so
it's
not
like
we're
really
screwing
up
if,
for
some
reason,
this
break
like
we'll
take
time.
We
won't
just
do
this
I
think
without
making
sure
that
we
check
in
with
a
lot
of
people.
But
after
that
point
we're
not
messed
up
if
somebody
comes
along
later
and
it's
like
actually
because.
G
A
G
G
My
preference,
I
think
would
be
to
just
move
forward
with
this
PR
that
we,
at
least
in
terms
of
web
hook,
validation,
prevents
that
from
being
the
case
and
we'd
also
need
something
in
the
spec
that
says
these
two
things
are
not
intended
to
coexist
and
we
still
leave
some
room
open
though
it's
it's
unlikely.
We
leave
some
room
open
that
we
could
open
it
back
up
to
redirect
Loop
production,
but
that
I
don't
know
if
we
would
get
to
that
point.
G
I've
lost
some
comments
in
chat,
so
I'll
Focus
there,
but,
like
again,
my
preference
right
now
without
having
read
the
comments
would
be
to
just
lock
it
down,
so
that
it's
a
little
bit
more
clear
to
implementers
end
users.
What
the
intent
is
I
think
anything
like
redirect.
Loop
protection
is
going
to
be
complex
at
a
minimum
and
likely
not
universally
implementable.
A
Merge
it
got
it
all
right
done
right
here,
we're
doing
it.
No
just
kidding
okay
yeah!
So
please
do
it's!
It's
1788!
Please
do
jump
in
there
and
you
know
throw
out
your
comments
if
you
got
them
and
we
thank
you
for
that,
it
is
March's
draft,
so
actually
I
kind
of
missed,
so
I
don't
usually
read
the
ones
that
are
draft
unless
somebody
pings
me
all
right.
A
Okay,
so
we
talked
about
that.
I
have
a
little
update
on
bleaks.
We
are
getting
to
a
point
here
where,
as
a
part
of
the
conformance
profiles,
work
that
I'm
I'm
doing
with
some
members
of
the
community
did
I
did
I
like
the
wrong
issue:
somebody's
changing
something
anyway.
Yes,
you
did
I
fixed
it
cool.
Thank
you
appreciate
that.
So
we
are
getting
to
the
point
where
the
work
on
conformance
profiles
should
kind
of
converge
with
getting
UDP
route.
A
Conformance
tests
started
they're
not
going
to
be
like
it's
probably
not
going
to
be
the
like
laser,
lightning,
speed
or
anything,
but
fairly
soon,
I'm
expecting
in
the
next
couple
of
weeks
you
should
start
seeing
some
semblance
of
like
layer,
four
conformance
test,
starting
we'll
see
how
that
goes.
It
kind
of
depends
on
PR
reviews
and
stuff
like
that,
but
just
a
heads
up
and
there's
an
issue
on
the
Blick
side.
A
For
that
and
then
the
other
thing,
this
was
kind
of
like
just
a
an
interesting
thing
for
for
those
of
you
who
are
interested
in
ebpf.
You
might
know
that
it's
kind
of
hard
today
to
manage
your
ebpf
programs
loaded
in
the
kernel,
in
fact,
for
some
solutions
like
I,
think
in
celium's
case
and
correct
me
if
I'm
wrong,
Nick,
it's
kind
of
a
situation
where
they're,
like
don't
load
anything
else,
load.
What
we
give
you
kind
of
thing,
keep
it
keep
it.
The
sanity
is
or
sorry
the
sanitization
is
handled
that
way.
A
Bpfd
is
a
project
that's
coming
along
to
try
to
provide
like
a
manager
for
ebpf
programs
and
one
of
the
cool
things
that
it
has.
As
an
operator
with
like
an
EB
bdpf
program
resource
where
you
can
literally
just
put
your
ebpf
program,
byte
code
in
a
container
image,
put
it
on
that
resource
and
then
it'll
deploy
it
for
you
to
all
the
no
it's
kind
of
cool
we're
going
to
use
it
in
Blix
and
get
off
of
our
rust
based
loader.
A
A
F
Is
yeah
I
mean
I?
Think
it's
pretty
close
now
to
a
reasonably
final
version.
There
have
been
a
couple
comments,
so
yeah
AKO
has
mentioned
that
he'd
prefer
not
to
use
a
policy
attachment
for
like
TLS
and
I'm
like
okay,
that's
fine
but
like
I
need
to.
If
people
really
have
a
problem
with
policy
attachment,
we
need
to
know
right.
Like
you.
C
Yeah,
so
yeah
no
I
think
Nick
is
just
sharing,
so
Nick
I.
Think
policy
attachment
is
great
and
I
think
in
Envy
gate
we
will
actually
use
it.
We'll
use
direct
policy
attachment
I
think
for
Native
Fields,
like
what
Candace
was
talking
about
earlier
I
think
it
would
be
great
if
it's
if
it's
part
of
the
Native
API,
rather
than
extension,
API
like
policy
attachment
so.
F
Probably,
and
then,
if
we
were
going
to
do
TLS
with
with
with
a
policy,
then
TLS
would
also
be
included,
and
so
one
of
the
things
I
want
to
do
with
policy
attachment
is
to
make
this
whole
thing
a
little
bit
clearer
by
having
a
couple
of
examples
in,
in
the
actual,
in
the
sort
of
the
at
least
the
extended
API
and
so
yeah
I
think
that's
that's
the
you.
That's
that
I'm
kind
of
hoping
that
some
examples
will
make
it
a
bit
clearer.
F
F
F
Everyone's
going
to
get
really
good
about,
you
know
High
Rock,
cool
yeah,
so
that
that's
the
the
idea
here
is
that
that's
the
main
distinction
John's
had
some
great
comments
and
I've
really
dialed
in
on
exactly
what
the
difference
between
a
high
a
policy
and
a
hierarchical
policy
is
to
summarize
and
I.
Think
I've
got
this
down
to
a
very
short
summary.
That's
a
policy
is
anything
that
includes
the
target.
F
Ref
struct
and
a
a
hierarchical
policy
is
one
that
includes
the
target
refract
and
one
of
or
both
of
either
the
defaults
or
override
standards.
If
you
don't
have
defaults
or
overrides,
then
it
is,
by
definition,
a
direct
attached,
a
direct
attached
policy
that
will
only
affect
the
object
that
it
references
and
it
won't
sort
of
have
effects
outside
of
that.
E
Yeah
one
question:
I
have
so
say:
I
have
a
timeout
policy,
for
example,
and
I
say
this
is
a
direct
policy.
Well,
I
guess
two
questions:
one
can
a
given
crd
only
be
one
or
the
other
I
think
the
answer
is
yes
right.
Yes,
okay
and
the
second
question
is
so:
okay
I
have
time
on
policy.
It's
direct
policy
yeah.
What?
If.
F
Okay,
so
yeah.
This
feels
like
a
thing
that
I
need
to
explain
more,
so
hierarchical
policies
can
attach
to
anything
in
the
hierarchy
right.
So
a
hierarchical
policy
that
you
could
attach
so
timeout
policy
is
a
good
example
of
one
where
you
can
attach
it
to
say
a
Gateway
and
be
like
set
defaults
and
then
say
those
defaults
to
apply
to
all
HTTP
out
all
back
ends
under
all
HTTP
routes
under
the
Gateway.
E
F
The
hierarchy
is
still
present
and
you
can
attach
it
to
any
point
in
the
hierarchy
and
have
it
affect
everything
below
it
so
I.
Thank
you.
That's
a
good
question
that
I
need
to
explain
a
bit
more
yeah,
so
I'll
make
that
a
bit
clearer,
but
so
I
think
for
talking
about
policy.
The
rough
design
I
have
in
my
head
is
that
it
would
be
a
it
would
be
a
hierarchical
policy.
F
E
F
Yeah
I
think
I
think
I'm,
not
100
sure
I
think
I
need
to
think
about
it,
but
the
the
internity
is
that
director
policy
should
should
sort
of
affect
a
setting
that
you
only
want
to
change
for
sort
of
one
thing
you
know.
So
if
you
make
a
timeout
policy,
that's
direct
attached,
like
you,
should
probably
specify
in
the
policy
hey
this
type.
This
policy
is
intended
to
modify
service
yeah.
E
F
F
Yeah,
exactly
right,
yeah
and
so
I
think
the
but
yeah
I
think
for
direct
attached
policies.
In
my
mind,
are
things
like
you
know
things
like
if
we
were
to
do
the
TLs
properties
with
a
policy,
they
would
be
a
direct
attached
policy
to
a
service,
and
you
would
say:
okay,
you
know
for
this
service,
like
anytime
you're,
using
the
service,
the
the
you.
If
the
Telus
properties,
you
should
look
for
Taylor's
properties
and,
if
so,
use
the
ones
for
the
TLs,
the
TLs
property
policy
or
whatever.
F
C
F
Intention,
the
other
intently
policies-
maybe
actually
this
is
a
thing
that
I
should
put-
is
that
policy
should
be
tightly
focused
on
a
specific
kind
of
setting.
Don't
make
him
through,
don't
make
them
too
broad,
don't
make
them
too
generic.
They
need
to
be
very
tightly
focused
on
sort
of
a
limited
set
of
things
they're
hard
enough
to
understand,
without
having
a
really
big
set
of
things
that
you
need
to
that.
You
need
to
change.
E
E
E
Okay,
because
I
just
want
to
say-
and
maybe
we
follow
up
on
slack
or
something
like
we
like
this
generally
makes
sense
like
reading
this
I
think
that
you
seem
to
make
sense
as
an
implementation.
One
thing
that
we're
at
least
looking
into
is,
we
already
have
policies
right,
so
we
have
I
think
basically
10
policy
apis.
E
We
want
to
move
these
to
the
policy
attachment
shape
so
that
you
know
we
can
be
conformant
doing
it
in
the
direct
mode
is
very
nice
because
then
we
just
have
to
add
a
field
to
the
top
level
of
our
apis.
We
don't
have
to
move
everything
under
defaults
and
overrides,
but
we
already
have
a
hierarchy.
Actually,
so
it's
kind
of
funky.
F
F
Yeah
yeah
yeah.
We
can
talk
about
it
more
after
this
many
but
I.
Think
for
everyone
else,
like
I
said,
if
everyone
else
does
have
a
problem,
if
anyone
else
does
have
problems
with
policy
attachment
like
this
is
the
time
like.
Otherwise
this
is
gonna.
Like
you
know,
if
you
don't
say
anything
now,
then
then
you're
gonna
miss
out
so
speak
now
forever
hold
your
peace.
E
F
Yeah,
yes,
so
yeah
I
think
yeah
I
have
a
TLS
connection
policy
in
the
pr.
As
an
example,
I
might
change
that
to
be
not
TLS
connection
policy
and
do
something
else
as
well
as
to
avoid
thanks.
Michael,
that's
a
good
point.
Yeah
I
might
swap
that
out
for
something
else,
for
a
different
example,
try
and
find
something.
That's
that's
more
unambiguously
direct.
E
E
F
Yeah
so
I
mean
I'm,
hoping
that
the
like
you
know
that
people
will
sort
of
have
a
crack
at
this
and
be
like.
Oh
actually,
no
a
lot
of
the
time
you
do
need
hierarchy.
I
do
think
that
the
direct
one
is
probably
going
to
be
more
useful
for
very
small
hierarchy
or
non-existent
hierarchies
or
for
things
like
specific
mesh
use
cases
where
you
really
want
to
just
connect
to
a
specific
thing.