►
From YouTube: SIG Network Gateway API Meeting for 20220809
Description
SIG Network Gateway API Meeting for 20220809
A
I'm
going
to
share
my
screen,
get
started
just
a
reminder
to
everybody,
that's
here
and
very
welcome
to
anybody
to
put
anything
on
the
agenda
for
today.
So
if
you
need
help
getting
access
to
this
document,
just
ask
in
the
chat
somebody
will
send
you
a
link
but
you're
welcome
to
put
something
on
here
for
us
to
go
over.
B
So
I
wanted
to
see
if
you
know,
if
I
should
switch
my
maybe
switch
my
efforts
over
to
that
work
on
these
in
parallel
or
I
took
a
look
at
the
google
doc.
That's
that's
that
we
we
started
talking
about
last
last
time
we
met
it's
a
beginning
for
the
backend
properties,
api,
it's
just
the
the
why,
but
not
the
how
for
for
that
component,
so
nick's
not
here
today,
so
I
can't
really
ask
him
directly.
B
C
B
C
Place
this
is
an
interesting
thing.
I
would-
and
we
should
definitely
have
a
discussion
about
this
because
it
has
happened
many
times
before
is
that
is
the
termination
of
a
client,
tls
property
related
to
how
the
protocol
you
use
to
communicate
with
the
back
end
post-termination,
and
I
think
at
least
our
we've.
C
The
reason
I'm
bringing
this
up
is
because
we've
had
this
discussion
before
and
it
seemed
like
we've
settled
on
the
fact
that
they
are
somewhat
decoupled
from
each
other.
For
example,
you
can
have
one
completely
unique
set
of
tls
properties
for
how
you
want
clients
to
talk
to
you
and
then
you
could,
on
the
other
end
not
even
be
using
tls.
You
could,
you
know,
be
using
like
plain
text
http,
you
could
send
it
over
irc
protocol.
I
don't
know
like
it's
like
those
two
things
are
very
while
they
have
the
tls
in
them.
C
Usually
they
actually
are
not
necessarily
completely
tied
to
each
other
and
that
that
was
kind
of
where
it
as
from
a
sort
of
like
api
modeling
perspective,
we
sort
of
gone
down
the
line
of
thinking
that
you
should
describe
them
separately
because
they
sort
of
move
independently
of
each
other
versus
being
connected,
and
at
least,
if
you
look
at
the
implementation,
a
lot
of
the
implementations.
It's
like
you
have
one
thing:
that's
describing
how
you
want
to
terminate
clients
and
another
thing
entirely.
E
I
think
also
just
throw
in
there
that
you
know
you
may
because
of
match
criteria.
You
know
your
route,
may
you
know
you
have,
may
send
a
back-end
that
has
to
have
certain
connection
requirements,
whether
those
are
tls
or
protocol
or
something
else
and
under
a
different
mesh
condition.
You'd
send
it
to
a
different
backend
with
different
criteria.
B
C
Yeah
because
at
least
okay,
this
has
come
up
before.
So
that's
why
I'm
trying
to
give
some
context
for
the
group.
So,
as
jeff
was
saying
that
imagine
you
have
one
listener
that
let's
say
it
comes
in
on
http
for
whatever
reason
and
then
it
splits
traffic.
One
of
them
goes
to
like
a
set
of
back-ends
that
requires
https
to
communicate
with
them.
C
C
I
don't
think
this
setup
is
necessarily
that
unusual
because,
for
example,
you
could
be
determined,
let's
say:
you're
terming
an
entire
website
on
the
front-end
side,
so
you
enforce
some
internet-facing
set
of
tls
settings
which
may
be,
for
example,
if
you
support
legacy
clients,
it
may
have
some
downgraded
ssl,
but
on
the
back
end
you
might
have
different
pools
of
applications
that
are
being
aggregated
together.
Some
are
in
some
transition
where
they
support
a
one
set
of
tls
and
then
the
other
one
supports
another
tls.
A
A
B
D
I
think
one
of
the
things
that
mike
mentioned
in
chat
earlier
was
that
you
know
we've
been
merging
guests
earlier
in
the
process
where
you
know,
I
guess,
similar
to
back-end
properties.
Today
gap
has
been-
I
don't
know
if
we've
actually
merged
this
yet,
but
the
idea
of
merging
something
that
is
provisional
and
here
is
what
we
want
to
solve
with
this
gap
without
actually
having
a
solution.
A
A
But,
like
rob
said
I
you
know,
it
may
be
just
as
good
at
times
I
need
to
at
least
start
drafting
up
what
you
think
might
be
a
good
follow-up
to
the
otherwise.
Just
what
and
and
why
gap,
with
your
your
version
of
the,
how
I
would
let
nick
know
that
you're
kind
of
thinking
that
and
even
if
you
want
to
contribute,
I
think
it's
fair
to
ask
like
and
say
hey,
I
want
to
put
suggestions
on
the
pr
is
probably
the
easiest
way,
but
you
can
contribute
to
what's
there
too.
A
F
I
think
I
was
muted
in
my
headset,
but
I'm
interested
in
seeing
how
this
process
happens
from
a
local
organizational
process
perspective,
because
it
seems
like,
with
the
provisional
gap
being
a
thing
that
we're
starting
to
do
you've
got
the
possibility
of
multiple
different
avenues
of
implementation
in
the.
How
and
what
does
that
process
look
like
for
coming
to
consensus
on
which,
how
and
merging
that
upstream
into
a
gap?
Those
four
different
possible
approaches.
Separate
gaps:
are
they
sub
sub
gets
I'm.
A
Historically,
with
caps,
it
usually
ends
up
being
kind
of
the
first
one
to
get
in
there
gets
in
there
and
then
the
other
ones
can
potentially
displace
it
and
whichever
one
is
not
the
one
that
we
decide
on
end
up
in
alternatives
considered,
so
usually
all
of
them
end
up
on
the
gap
like
every
implementation
suggested.
It
just
comes
down
to
something
like
a
vote
on
which
one
actually
is
the
one
we
end
up
implementing.
A
So
I
don't
foresee
a
huge
problem
with
that
like
if
we
get
a
couple
pr's
with
a
couple
different
implementations,
it
will
definitely
take
more
time
but
we'll
end
up
documenting
both,
and
you
know
saying
which
one
we
ultimately
decide
on
and
that's
good.
You
know
the
posterity.
There
is
good,
it
keeps
it
keeps
us
clear
on.
You
know
why
we
made
the
decisions
that
we
made
and
so
forth.
A
A
Maybe
this
is
something
that
we
can,
I
would
say,
respond
to
nick's
comment
in
the
discussion,
and
maybe
that
can
be
kind
of
the
the
next
step
like
with
what
you
want
to
do,
and
we
can
talk
about
like
like
basically
you
respond
with
like
well.
My
intention
then,
is
to
do
this,
or
maybe
these
two
things
like
help
you
with
this
gap
and
maybe
and
review
it
and
maybe
start
on
this,
and
we
could
just
start
going
from
there.
Does
that
sound?
Okay.
B
B
A
D
Yeah,
I
just
wanted
to
add
a
couple
things
here:
one
it
sounds
like
candace.
You
already
have
a
good
understanding
of
all
the
previous
conversations
and
there
have
been
many.
So
thank
you
for
for
taking
the
time
to
look
through
our
mess,
but
two,
I
I
think,
maybe
that's
a
good
place
to
move
the
to
get
forward
of.
D
Maybe
just
put
everything
in
alternatives
considered
and
to
start
out,
like
here's
all,
there's
a
long
history
here,
just
getting
them
all
in
one
place
of
we
consider
these
things,
and
maybe
one
of
those
will
become
solution
proposed,
but
even
just
having
them
listed
out
in
one
central
place
of
the
things
we
considered
where
why
we,
you
know
hesitation,
we
might
have
had
with
that
approach
and
and
also
slightly
unrelated,
but
I
think
nick
is
out
this
entire
week.
So
he
may
not
be
that
responsive
on
github.
D
So
yeah,
so
I
think
you're
free
to
move
ahead
with
anything.
I
know
I
you
know
at
least
among
maintain
at
least
I
believe
nick's
approach
is
similar
to
shane's,
and
I
that
that
we
could
use
all
the
help
we
could
possibly
imagine
and
very
very
welcome
to
have
co-authors
co-owners
or
just
someone
take
something
over
so
yeah
by
all
means.
C
Yeah,
as
I
think,
as
long
as
your
thing
is
not
like
completely
does
not
work
with
what
the
philosophical
statement
that
nick
put,
I
I
think
you
should
just
you
know,
just
work
out
like
hash
out
the
concrete
details,
because
then
it
also
helps
like
let's
say
we
get
all
the
all
that
stuff
in
it's
like
immediately,
everything's
already
ready
for
the
next
discussion,
and
it
could
also
point
to
like
okay.
What
if
we
want
to
get
that
in
early
or
what
is
a
smaller
piece
that
could
go
in
beforehand,
like
just
it
helps
prioritize.
D
I
think
there's
actually
enough
discussion
of
both
of
these
topics.
I,
and
I'm
very
help.
If
you
want
to
reach
out
on
slack
or
somewhere,
I
have
some
context
as
well.
I
I
think,
whichever
seems
most
helpful
to
you.
I
know
there's
there's
plenty
of
historical
context
that
could
be
built
and
described
in
one
place
for
both
of
these
ideas.
So
you
know
for
for
the
backend
properties
idea.
We
once
had
a
back-end
policy
that
got
removed,
but
that
deserves
some
discussion
of
why
it
existed.
D
B
D
You're
right,
I
think
we
did
thank
you
yeah.
I
think
we
we
suggested
using
app
protocol
and
then
weren't
sure
about
how
that
would
work
and
yeah
good
call.
So,
yes,
having
central
central
list
of
all
these
things
that
are
related,
that
we've
done
in
the
past
and
regretted
or
pulled
out
or
not
implemented,
yet
be
very
helpful.
A
Okay,
I
think
that
that
sounds
very
wise
and
appreciate
the
willingness
to
contribute.
To
that
I
mean
it
sounded
like
you
were
willing
to
contribute
to
that.
I
want
to
put
words
in
your
mouth
canvas,
but
that
that
would
probably
be
a
great
place
to
start,
because
otherwise
we
keep
trying
to
figure
out
what
we
were
trying
to
do
before
and
it's
all
sprawled
everywhere.
D
D
E
No
there's
this
is
toby,
went
ahead
and
made
a
lot
the
a
lot
of
the
cleanup
of
the
little
formatting
and
grammar,
and
things
like
that,
and
he
submitted
pr
to
my
fork,
and
so
I
just
merged
that
in
and
brought
that
in
forward,
so
that
take
care
takes
care
of
all
that
stuff.
So
the
noise,
if
you
will
so
great.
D
Up
in
deep
deploy
preview
mode,
I
added
a
link
at
the
bottom,
maybe
because
it's
a
markdown
table
it's
near
impossible
to
read
any
other
way
yeah.
So
this
is
something
that
I
took
some
time
I
described
last
week
of
we
really
need
a
list
of
capabilities
in
hp
route
and
how
they
could
interact
with
delegation,
and
this
is
my
attempt
at
doing
that.
It
is
very
much
what
I
would
label
work
in
progress.
D
Many
of
these
labels
are
rather
arbitrary
in
terms
of
what
I
derive
as
importance
or
complexity,
but
it
is
a
starting
point
and
very
welcome
to
comment
on
these.
So
yeah,
it's
just
a
just
a
draft
pr,
I'm
not
exactly
sure
how
this
would
work,
I'm
assuming
we
would
incorporate
it
into
jeff's
pr
or
we
would
merge
this
after
jeff's
pr
merges.
C
D
C
Just
had
one
thought
in
terms
of
sort
of
it
feels
like
jeff
that
and
I'm
looking
at
the
group
that
we
are
all
directionally
thinking
that
some
form
of
delegation
should
get
in
and
is
it
the
case
that
there's
a
lot
of
like
specific
discussion?
Should
it
be
a
separate
resource?
Should
it
be
the
same
resource?
C
What
specific
fields
are
the
behavior
of
delegation
or
not
like?
Does
it
help
to
basically
put
that
out
there
in
the
proposal
itself,
just
say
explicitly
like
hey?
Many
of
these
things
are
still
yet
to
be
discussed
and
what
is
here
is
sort
of
like
a
concrete
sketch
that
people
can
anchor
their
discussion
on,
but
not
necessarily
the
final
form
and
that
helped
sort
of
make
people
comfortable
to
move
this
forward.
E
C
C
I
think
that
one
is
going
to
be
hard
to
resolve
and
get
just
the
general
directional
proposal
in
so
my
what
I
thought
was,
it
might
be
good
is
to
basically
say
explicitly
in
the
proposal
that
we
are
still
looking
at
like
some
aspects
of
this,
but
the
general
requirements.
If
we
could
like
highlight
them
like
it,
has
to
be
statically
computable,
you
know
like
those
like
those
we've
agreed
upon
and
then
we
can.
Then
we
can
get
it
in.
C
A
I've
done
this
so
actually
in
my
this
job,
I'm
currently
in
and
the
last
job,
we
actually
used
caps
locally
and
we
do
this
by
we've
done
this
exact
thing.
Just
by
saying:
okay,
we're
going
to
merge
it
but
provisional
with
a
to-do
list.
The
to-do
list
is
required
before
it
can
move
out
of
provisional
and
as
long
as
everybody
kind
of
agrees
on
the
to-do
list,
that's
worked
out
a
few
times.
D
Yeah,
I
think
that
seems
very
appropriate
for
this.
This
is
a
massive
gap
and
I
think,
there's
a
lot
of
very
good
content
in
it.
I
it
seems
like
there's
broad
directional
agreement
and
a
lot
a
lot
of
questions
about
the
specific
details
yeah.
I
I
like
the
idea
of
getting
getting
a
a
subset
of
this
in
soon
with
the
the
idea
of
these
are
the
things
are
still
unanswered.
A
So
what
I
would
have
suggested
and
what
I've
done
in
the
past
is
actually
you
take
the
open
comments
that
are
having
trouble
closing
turn
those
specifically
into
the
to
do
items
and
then
put
the
names
of
the
stakeholders
on
them
and
say
this
person
is,
has
to
be
involved
in
like
this
moving
forward.
But
there's
a
lot
of
effing
comments.
E
I
I
think,
maybe
I
think,
maybe
what
I'll
do
the
next
couple
days
here
is
I'll,
go
through
all
the
comments
and
try
to
bucketize
them.
If
you
will-
and
you
know
from
that
point
we
can
say:
okay,
you
know,
is
it
do
we
need
to
deal
with
this
bucket
as
a
as
a
whole?
You
know,
is
it
just
the
does
it
make?
E
You
know
a
top
line
single
issue,
or
is
it
really
a
collection
of
smaller
issues
that
individually
need
to
be
addressed,
and
then
we
can
say
you
know,
okay,
this
this
bucket,
that's
a
you
know
major
thing
like:
do
we
use
allowed
routes,
or
do
we
use
some
other
type
of
object?
You
know
that
we
that's
a
to
to
be
resolved
or
we
resolve
that
before
we
move
it
to
positional
and
then
the
buckets
of
lots
of
little
things.
E
A
C
D
D
I
I
went
into
it
thinking
that,
and
maybe
I've
missed
very
important
details
I
think
by
and
large
regex
anything
is
going
to
be
awful,
but
and
then
and
then
a
broader
theme
of
there
are
a
couple
things
that
really
only
make
sense
in
one
or
the
other
like
a
child
or
a
parent,
but
never
both
at
the
same
time
and
trying
to
communicate
that
or
validate.
That
is
going
to
be
tricky,
though
those
are
the
high
level
concerns.
D
D
I
think
it
technically
works,
but
it
it
it
could
result
in
resource
explosion
if
you
have
ores
on
top
of
each
other,
so
you
have
like,
let's
say
16
or
rules
in
a
match
like
and
then
each
child
route
has
a
bunch
of
ores
too.
Then
you
like
the
exponential
explosion
that
we're
talking
about
in
terms
of
configuration,
would
be
pretty
wild
if
you
took
that
at
face
value,
the
other
you
know
so
a
simple
example:
here
you
have
two
matches.
D
One
is
on
the
get
one
is
on
the
post
and
then
your
child
route
only
matches
get.
So
I
guess
you
interpret
that
as
only
matches
get
slash,
foo,
baz
and
not
slash
barbaz,
because
you
know
like
you,
can
see
how
that
could
translate.
But
it's
just
something
like
that.
I
hadn't
really
thought
of.
I
I
just
added
this
to
the
open
question
section
below
anyway,
I
opened
open
to
ideas
and
feedback
here.
I
think
there's
some
interesting
things.
This
opens
up
overall.
D
I
have
a
pr
that
does
that
it's
kind
of
pull
we
had
some
basic
docs
about
conformance
and
our
implementation
guideline
stocks,
which
felt
somewhat
out
of
place
and
hidden
and
if
you've
looked
at
our
implementation
guidelines
doc.
Recently,
it's
massive,
so
I
pulled
this
out
and
made
a
conformance
specific
page
that
covers
our
support
levels,
our
release
channels
and
our
conformance
tests.
D
I'm
not
sure
that
release
chan,
whatever
that
we
do.
We
don't
need
to
go
into
the
details
of
this
specific
pr
now,
but
I
just
wanted
to
highlight
this
is
a
thing
that
could
use
some
review
really
just
trying
to
have
some
kind
of
central
place
for
conformance,
and
I
think
that's
indicative
of
a
larger
term
effort.
I
think
v0.6.0.
D
One
of
our
big
themes
has
to
be
unimproved
focus
on
conformance.
We
have
a
fairly,
I
want
to
say,
stable,
but
a
well
thought
out
core
api
now
and
I
think
a
lot
of
our
investment
over
the
past
couple
months
has
been
in
conformance,
and
this
leads
into
the
next
thing
that
I
had
to
say
about
conformance
is
I
really
would
love
to
have
a
stretch
goal
of
v0.6.0.
D
Actually,
including
a
concept
of
a
conformance
report
that,
when
you
run
conformance
tests,
there's
some
kind
of
deliverable
that
says
this
is
the
result
of
my
conformance
test
with
these
parameters
and
these
results,
and
maybe
some
kind
of
opt-in,
dashboard
or
something
that
shows
conformant
implementations
with
links
to
those
reports.
These
are
things
that
we've
discussed
before,
but
I
I
think
I
just
want
to
make
sure
we
get
to
that
point.
D
D
A
I'll
be
interested
in
helping
out
with
that
I
have.
I
did
the
original
implementation
of
conformance
for
one
of
our
implementations
of
gateway
way
back
like
in
the
earlier
days
of
conformance,
but
one
of
the
other
engineers
on
my
team
right
now
is
finishing
up
getting
v050
conformance
done,
so
I
might
try
to
pull
him
in
too.
If
he's
interested
and
see
if
we
can
work
on
kind
of
just
dolling
it
up
a
bit
is
what
it
sounds
like,
but
also
you
know
getting
cool
things
like
little
buttons
stuff
like
that.
D
E
D
F
Cncf
tag
network
has
some
done:
some
really
cool
work,
around
smi
conformance
tests
and
automated
reporting
of
said
conformance
tests.
He
might
be
a
good
resource
to
reach
out
to
to
see
what
learnings
might
be
found
there.
So
I
put
a
link
in
the
chat
to
how
measure
tag
networks
again
see
how
nestory
does
their
conformance
tests
there's
a
ui
and
everything
so
that
might
be
worth
exploring
for
those
folks
who
are
interested
in
doing
conformance
stuff.
D
Yeah,
that's
awesome.
I
think
I
was
talking
with
john
sometime
last
week
about
how
conformance
plus
gamma
and
mesh
implementations
is
going
to
add
a
whole
different
perspective
on
conformance
here.
Whenever
we
get
to
it
so
yeah
that
I
mean
this
is
broadly
applicable,
but
especially
when
we
start
getting
to
mesh,
it's
going
to
be
very,
very
applicable,
so
yeah
I'll,
follow
up
with
that
too.
Thanks.
D
All
right
yeah,
I
just
wanted
to
add
this
last
thing
I
I
congrats
to
everyone
who
made
it
in.
I
think
we
have
six
different
presentations
that
are
going
to
be
related
to
gateway
api
at
kucon.
It's
great
excited
to
meet
some
of
you
for
the
first
time
in
person
there,
and
I
just
want
to
say
on
kubecon
front,
I'm
looking
into
organizing
some
kind
of
community
event.
D
A
Yeah
we
might,
unless
somebody
has
something
yeah
no
I'll
be
at
kubecon.
I
it's
in
my
backyard
I'll
be
driving
to
coupon,
so
I
would
very
much
like
to
try
to
get
together
and
do
something
you
know
like
as
a
as
a
group,
so
I
basically
live
here,
but
I
can't
think
of
anything
like
we
could
do
something
that
was
a
little
bit
less
sitting
down
and
talking
about
gateway
api.
A
If
we
wanted
to
just
do
something
fun,
we'd
probably
come
up
with
something
like
that
too,
like
maybe
talk
about
it
or
go,
do
something
fun
and
then
sit
around
and
talk
about
gateway.
Api
depends
on
if
everybody's
going
to
be
when
everybody's
going
to
be
there,
because,
like
were
you,
thinking
like
more
like
on
the
weekend
like
as
people
are
coming
in,
what
were
you
thinking.
D
So
I
I'm
really
biased
in
that.
The
way
kubecon
usually
works
for
me
is
tuesdays
are
an
empty
day.
I
because
I
go
to
contribute
summit
on
monday
and
the
main
conference
doesn't
start
until
wednesday,
but
I
know
a
chunk
of
gateway.
People
will
be
going
to
co-located
events,
which
would
be
on
tuesday,
so
I
know
that
doesn't
work
for
everyone,
so
it'll
be
hard
to
find
a
time
that
works
perfectly.
D
A
A
E
F
F
I
think
the
22nd
would
be
a
pretty
good
kind
of
status
check,
so
that
gives
both
meetings,
two
occurrences
and
we
are
that'd,
be
a
good
chance
for
us
to
kind
of
give
what
we're
what
we're
working
on
there's
pretty
good
work
going
on
it's.
It's
we've
had
some
really
good
discussions
for
the
last
couple
of
meetings,
so
I
would
love
to
update
the
greater
gateway
api
community
with
where
we
are.