►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20230306
Description
SIG Network Gateway API Bi-Weekly Meeting for 20230306
A
All
right
welcome
to
the
Gateway
API
meeting
for
March
6
2023.
As
we've
mentioned,
this
is
the
first
experimental
time
slot
that
is
trying
to
be
more
east
coast
and
Europe
friendly.
Hopefully
it
looks
like
we're
already
getting
some
different
and
new
attendees,
so
really
great
to
see
that
and
we'll
see
if
we
continue
with
that.
This
is
a
just
like
any
other
kubernetes
contributor
meeting,
where
we
encourage
everyone
to
be
kind
to
each
other
really
adhere
to
the
kubernetes
code
of
conduct.
A
This
agenda,
which
I'm
presenting
is
intended
to
be
editable
by
anybody.
So
if
perchance,
you
see
this
and
you
want
to
add
something:
don't
hesitate
to
add
something
to
this
agenda
or
any
future
agenda
and
also
feel
free
to
add
comments
in
chat
or
speak
up
as
necessary.
I
really
want
everyone
to
feel
like
they
can
participate
with.
That
said,
let
me
go
ahead
and
get
into
the
first
couple
items
which
are
both
mine.
A
The
first
one
I
tried
to
write
out
a
doc
that
describes
how
I
think
Gateway
API
can
interact
with
multi-cluster
Services
I
actually
had
the
stock
sitting
around
for
a
while,
but
then
I
disappeared
on
vacation
for
a
bit
and
came
back
to
it
and
said
you
know.
I
should
probably
share
this
more
broadly
and
try
and
get
some
some
feedback
from
the
rest
of
the
community.
With
that
said,
I
think
this
is
a
natural
follow-up
to
some
discussions
that
Sanjeev
started
earlier.
A
Maybe
a
couple
weeks
ago,
at
a
meeting
where
he
was
trying
to
you,
know,
show
the
whole
scope
of
multi-cluster
and
Gateway
API
and
I
know
that
scope
may
end
up
being
larger
than
the
current
multi-cluster
service
API.
But
it
seems,
like
the
you
know.
Most
natural
simplest
starting
point
is
defining
how
Gateway
API
interacts
with
the
existing
multi-cluster
service
API.
A
So
in
in
this
case,
in
the
scope
of
this
document
I'm
trying
to
structure
the
document.
So
it
looks
and
feels
similar
to
again,
because
I
think
this
will
probably
eventually
make
it
into
a
gap
format,
but
the
main
goals
are
yeah
just
trying
to
ensure
that
we
have
a
clearly
defined
interaction
between
Gateway
and
multiplicity
services
and
maybe
the
most
important
non-goal
is
we
don't
want
to
make
any
significant
changes
to
either
API
as
a
part
of
this
Gap,
at
least
that
that
was
not
my
intention.
A
This
is
really
just
trying
to
say
given
the
two
apis
as
they
exist
to
get
today.
How
do
they
interact
with
that
said,
I
I'm
thinking?
Many
of
these
things
will
not
be
too
controversial,
but
happy
to
be
wrong
with
any
of
those
one
I
think
the
the
most
commonly
used
thing
would
be
forwarding
to
a
service
import.
So,
instead
of
forwarding
to
a
service
inside
a
cluster,
you
can
forward
to
a
service
import
and
that
is
interpreted
as
forwarding
to
all
endpoints
associated
with
that
service
across
all
clusters
and
I.
A
Think
the
fleet
is
the
appropriate
multi-cluster,
termite
I'm,
not
sure,
but
the
group
of
connected
clusters,
as
far
as
multi-cluster
services
are
considered
so
really
just
a
drop
in
replacement
for
service,
but
instead
of
forwarding
to
Buster
local
endpoints.
It
refers
to
all
all
endpoints
within
the
set
of
connected
clusters,
then
for
the
routing
to
specific
clusters,
similar
to
what
multi-cluster
service
would
recommend
or
similar
to
what
we're
doing
for
traffic
splitting
with
single
cluster
Services
I.
A
Think
the
the
way
to
do
that
would
just
be
to
have
different
service,
Imports
or
different
services.
So,
with
single
cluster
traffic,
splitting
we'd
have
different
Services.
The
same
idea
would
apply
here
for
multi-cluster
services,
so
you
can
imagine
store
West
Store
East
and
those
might
only
be
exporting
imports
from
clusters
in
a
western
region
and
an
Eastern
region
for
example.
A
Then
the
last
thing
I
wanted
to
cover
here
is
cross
namespace
references
with
reference.
Grant
I
think
this
is
a
great
use
for
reference
grants,
so
we
might
as
well
make
use
of
it.
So,
just
like,
we
enable
cross
namespace
references
to
services
with
reference,
Grant
I
think
the
same
would
apply
to
service
Imports
I.
Think!
That's!
That's!
Really!
A
The
the
high
level
idea
of
the
stock,
taking
anywhere
where
we
use
service
and
saying
the
same
Concepts,
apply
to
you
servicing
board
and
then
finally,
I
don't
see
any
of
the
mesh
I
think
he
is
on
here.
Maybe
yes,
but
this
is.
This
is
probably
worth
some
more
discussion
on
gamma
side.
This
is
the
area
that
I'm
least
confident
about,
but
I
feel.
Like
you
know,
you
should
be
able
to
differentiate
between
a
a
broad
Set.
A
You
know
like
plus
your
local
service
and
a
multi-cluster
service
via
service
import.
So
the
idea
being
that
attaching
to
a
service
import
is
a
different
thing
than
attaching
to
a
service.
A
I
know
many
meshes
don't
make
that
distinction
today.
So
this
is
probably
going
to
need
some
more
discussion
within
gamma,
but
just
that's
the
began
the
side
of
it.
I,
don't
know
Keith
if
you
had
anything
to
add
or
any
dish
or
anyone
else
from
mesh
side
on
this.
B
Yeah
I
can
save
that
from
an
API
perspective.
This
definitely
feels
right,
I
think
you're
you're
correct
though,
and
that
we'll
probably
need
to
you
take
a
look
at
some
of
the
particular
ways
that
this
will
play
with
different
Mission
implementations,
but,
like
I
said,
it
feels
like
the
right
direction
not
feel
comfortable
like
if
there
was
a
Delta
necessary.
It
feels
like
it
would
be
correct
to
to
have
Mission
plantations.
Make
that
change.
So
yeah
I
will
put
this
as
an
agenda
topic
for
the
game
meeting
tomorrow.
B
A
Thanks
and
then
the
the
rest
of
this
I
think
is
is
fairly
straightforward.
The
main
changes
here
are
service.
Import
would
be
recommend,
recognized
as
extended
conformance
and
then
service
import
would
also
be
included
in
gamma
gax
with
the
same
extended
performance
and
then
some
kind
of
clarification
that
Services
as
they're
specified
in
kubernetes
refer
to
endpoints
within
the
same
cluster
intended
to
be
referring
to
multi-cluster
services.
C
A
That's
a
whole
lot
any
thoughts
or
comments
on
this
before
I
move
on.
A
Cool
I'll
take
Shane's
thumbs
up,
but
anyone
please
feel
free
to
add
feedback
on
this.
If
not
I'll
just
probably
go
ahead
and
transition
this,
as
is
to
a
gap,
but
also
interested
in
what
the
feedback
from
gamma
meeting
is
tomorrow,
cool
all
right.
The
next
thing
for
me
is
the
contributor
ladder
lead
contributor
ladder.
He
has
a
doc
I
shared
last
week
and
I.
Think
there's
been
no
real
comments
on
this
other
than
Nick
is
plus
one
and
I.
Think
Shane
is
as
well
on
this
one.
A
C
D
A
Yeah
and
and
one
thing
well,
while
I'm
here
I
realized
that
many
of
the
people
on
this
meeting
were
not
on
the
meeting
we
discussed
this
last
week
because
of
time
zone
issues
or
whatever
else
so
I
want
to
highlight
really
quickly
that
we
are
defining
with
this
Doc
and
soon
be
Doc
update
a
a
formal
way
to
become
a
recognized
contributor
with
a
formal
role
within
the
Gateway
API
project.
A
We
have
tons
of
opportunities
here,
and
this
project
has
so
much
work
still
to
do,
and
we
appreciate
everyone
who's
been
helping
us
out.
So
if
you've
been
interested
in
getting
a
formal
role
and
contributing
more
within
Gateway
API,
we
would
love
to
have
you
this
doc
really
just
tries
to
formalize
what
that
looks
like,
but
don't
hesitate
to
reach
out
to
any
of
the
maintainers
Shane
myself
Nick
anyone
else
and
yeah
Dave
you've
got
a
good
point.
A
We
we
do
need
to
make
it
a
little
bit
more
clear
how
to
actually
become
a
reviewer
at
this
point.
I
think
we've
basically
just
said:
hey
just
reach
out
to
a
maintainer,
but
yeah
would
would
be
open
to
more
guidance
on
this
really
I
think
for
reviewer
and
approver.
A
Think
of
conformance
tests,
especially
we've
got
some
really
good
reviewers
on
there
so
and
and
also
gaps.
So
if
those
are
areas
that
you're
interested
in
or
documentation,
please
don't
hesitate
to
reach
out.
We
want
to
get
more
people
involved
and
and
ensure
that
we
have
a
really
healthy
Community
here.
C
C
Okay,
thank
you.
Yeah
I'd
raised
this
discussion
a
few
weeks
ago,
so
I
just
wanted
to
follow
up
and
make
sure
we
get
enough
eyes
on
it.
It's
just
proposing
adding
a
alpn
field
which
would
allow
for
routing,
based
on
the
alpn
extension
in
the
TLs
and
chick
for
the
TLs
route.
C
A
Interesting
I,
just
you
know,
for
John's
follow-up
question.
That
is,
is
s
and
I
a
fit
here.
C
D
Yeah
yeah
I
think
this
is
what
I
was
about
to
just
say:
I
would
say
respond
to
some
of
the
things
like
that
are
still
not
responded
to
like
I
think
it
may
just
be
John's
one
thing,
but
I
think
you're
ready
to
try
a
gap.
You
know
provisional
and
start
getting
a
little
bit
more
technical
about
what
you
want
to
do
and
see
how
the
response
is
to
that,
because.
E
D
Think
what
I
think
we're
yeah
I
think
where
we're
at
with
this
is
it's
mostly
like?
Okay,
it's
got,
gonna
be
an
extended
thing,
but
okay
and
yeah.
It's
just
a
matter
of
starting
to
make
the
the
motion.
A
Yeah
I
would
say:
I
I
would
emphasize
it
yeah
I
agree
with
Shane.
Here
I
would
emphasize
it's
important
to
go
in
kind
of
baby
steps
here.
You
know,
like
add
a
bit
more
detail,
start
again
with
that
I,
don't
you
know
if
you
know
sometimes
sometimes
it'd
be
tempting
to
go
away,
write
out
everything
and
then
come
back,
and
then
you
know
like.
If
you
can
just
do
smaller,
updates
smaller
incremental
changes,
then
we
can
get.
D
I
yeah
yeah
add
the
what
and
the
Why
without
any
how
for
the
first
iteration,
that's
something
we've
been
doing
a
lot
more
over
the
last
year
and
it
seems
to
have
fairly
good
results.
We've
at
least
had
some
it
just
it
just
makes
it
so
that
you
don't
have
to
do
everything
in
one
PR,
because
the
bigger
a
PR
is
the
inevitably
longer
it
will
take
to
get
it
to
merge.
So
when
we
say
what
and
why
there's
like
a
tldr
section,
A
summary
some
goals,
non-goals
fill
those
up.
D
D
And
if
you
need
any
help
whatsoever,
we're
on
kubernetes
slack
I'm
at
Shane,
Rob
Scott,
you
know
just
Pingus,
actually
just
ping
Rob
like
constantly
for
anything
that
you
need.
No,
no
yeah.
A
And
also,
whenever
Shane
and
I
say,
pingazier
you're
welcome
to
DM
us,
but
also
very
welcome
to
just
yeah
mention
Us
in
Sig
Network
Gateway
API
channel.
That
way
everyone
can
be
part
of
the
discussion
it
doesn't.
You
know.
None
of
this
has
really
intended
to
be
confidential.
Just
we're
saying
we're
open
to
chat.
However,.
D
C
D
Right,
I
figure,
since
we
have
a
little
bit
of
a
different
crowd
here,
we'll
do
an
introduction,
so
this
project
is
called
blixt,
which
is
a
Swedish
word,
meaning
lightning.
Originally,
it
was
an
experimental
layer,
4
load
balancer
using
ebpf
as
the
data
plan
at
Kong,
experimental,
meaning,
literally
just
kind
of
a
toy.
What
we're
doing
with
it
now
is
actually
it's
already
being
set
up
to
be
contributed
to
kubernetes
sigs
and
become
because
it's
its
control
plane
is
entirely
Gateway
API,
as
opposed
to
like
Ingress
or
anything
like
it's
entirely.
D
Gateway
API
based
control
plane.
It's
going
to
become
the
testing
and
reference
implementation
for
like
layer,
four
in
Gateway
API.
So
it's
going
to
become
a
Gateway
API
repository.
You
actually
probably
saw
that
on
the
contributor
dock,
so
that's
just
a
little
brief
introduction
to
what
it
is.
If
you
have
more
questions,
please
feel
free
to
reach
out
in
the
Gateway
API
kubernetes
slack
Channel
or
in
discussions
and
issues
on
the
repository
I
wanted
to
give
a
quick
update
on
where
things
are
with
it.
D
We
recently
had
our
first
pre-release,
which
has
UDP
route
support,
and
we
it's
not
completely
finished
or
anything
like
that,
and
we
are
currently
tracking
a
couple
of
different
major
tasks
for
our
next
release,
which
is
TCP
support,
which
is
almost
done
and
then
so
so
TCP
route
support,
ultimately
with
Gateway
API,
and
then
we
are
going
to
change
our.
This
may
be
Greek
to
some
people,
but
we
are
going
to
change
our
loader
for
our
ebpf
programs
from
Aya,
which
is
our
current
loader.
D
That's
just
a
rust
program
loader
to
bpfd,
which
is
an
open
source
loader
that
has
like
cool
tools
for
managing
BPF
programs,
including
it
can
kind
of
tell
you
if,
like
there's
other
BPF
programs
already
on
the
system
them
and
it'll,
like
give
you
the
option,
the
ability
to
kind
of
organize
in
what
order
you
want
the
BPF
programs
to
actually
run
cool
stuff
like
that.
But
the
main
thing
that
we
like
it
for
is
your
edpf
program,
is
also
a
crd.
D
So
those
two
things
are
the
next
kind
of
bigger
things
before
our
next
release
and
then
the
last
thing
is
we're
migrating
to
cncf,
and
that
has
been
taking
a
long
time.
So
we
recently
literally
just
in
the
last
couple
of
days,
decided
to
Short
Circuit
that
by
switching
our
license
from
GPL
V2
for
the
data
plane,
which
is
required
for
ebpf
for
those
who
aren't
aware
to
dual
licensed
gpl2
plus
bsd2
Clause.
D
This
is
the
current
allowed
kind
of
GPL
combo
license
that
celium
uses,
and
so
we
expect
that
now
that
we've
done
this,
we
should
be
able
to
kind
of
fast
track
into
get
it
into
kubernetes.
Finally,
so
that's
just
kind
of
a
really
fast
update
on
everything
going
on
with
that
project.
Hopefully
we
will
be
in
kubernetes
soon
and
hopefully,
you'll
start
seeing
it
showing
up
in
our
conformance
sooner
rather
than
later,
we're
tracking
for
it.
A
E
E
I
understood
what's
going
on
here,
so
blixt
is
a
gateway,
API
implementation
that
is
going
to
live
in
the
Gateway
API
repository.
D
D
A
Yeah
well
said,
and
I
should
you
know
Echo
everything
Shane
said
and
also
say
like
we,
you
know
when
we
were
talking
about
adding
this
to
kubernetes
sigs
project.
If
you
go
back
through
the
Sig
Network
mailing
list,
I
think
the
the
big
requirements
that
were
added
were
that
you
know
this.
This
should
never
ever
be
used
for
production.
A
It
needs
to
have
mechanisms
and
documentation
in
place
to
to
prevent
that
that
kind
of
usage
and
it
it
should
be
clear
that
this
is,
you
know,
meant
to
further
the
development
of
Gateway
API
not
meant
to
be
used
in
production
ever
for
any
reason.
I
know.
I
know
this
is
a
really
hard
thing
to
do,
because
you
know,
for
example,
kind
was
never
intended
to
be
used
in
production.
Yet
you
know
it
is
so
I
think
we've
tried
to
be
even
more
aggressive
on
that
stance
and
then
for
the
motivation.
A
I
really
want
to
highlight
what
Shane
said
with
The
L4
side
of
things.
It's
been
really
hard
to
find
something
that
can
help
Drive
L4
forward.
So
having
some
kind
of
implementation
that
we
can
kind
of
use
to
prove
out,
our
Concepts
is
is
really
helpful.
We've
had
a
lot
of
L7
implementations
that
have
been
really
good
at
helping
us
prove
out
L7
Concepts,
but
it's
been
harder
to
define
the
same
with
L4.
E
Just
recently
added
TCP
route,
UDP
routes,
your
PC
route
support,
so
I'm
still
trying
to
understand
like
right.
Gateway
API
has
a
dozen
different
implementations
and
like.
Why
is
this
particular
implementation,
the
one
that
is
used
to
well
conformist.
D
Yeah
for
conformance
tests,
we
specifically
wanted
to
avoid
what
we
thought
would
be.
What's
the
right
word
Rob,
we
wanted
to
stay
away
from
what
we
thought
would
be
controversial
technology
choices
so
like
Envoy
versus
nginx,
regardless
of
the
fact
that
Envoy
is
cncf
just
because
this
would
seem
to
play
favorites.
So
we
figured
that.
E
A
And
I
think
the
the
point
about
you
know
that
there
are
implementations.
Envoy
Gateway
has
been
amazing
at
getting
a
full
conformance
of
all
features
and
I
know.
We
really
appreciate
that
I
think
the
idea
with
bleaks
and
Shane
correct
me
if
I'm
wrong
was
the
idea
that
that
there
could
be
some
kind
of
experimental
playground
where
you
could
test
out
features
before
they,
even
you
know
became
is
that
you
know
this
is
this
is
not
something
like
we.
We
need
to
have
any
kind
of
backwards
compatibility
gear.
D
A
But
I
do
I,
do
want
to
be
very
clear
weed
that
this
project
has
no
intent
and
we
are
trying
to
do
everything
we
can
to
to
ensure
that
it
does
not
and
will
never
compete
with
any
of
the
official
implementations
that
that
people
are
working
so
hard
on
this.
This
is
not
correct.
D
It
won't
currently
and
if
it
ever
gets
to
a
point
where
it's
easier
to
use
anywhere
else,
but
in
the
really
limited
sense
that
it
is,
we
intend
to
put
something
like
a
kill
switch
on
it.
Where
it'll
be
like.
A
Yeah
good
good
comments
open
open
to
other
ideas
for
how
we
can
further
limit
this.
But.
A
E
E
D
Okay,
so
go
ahead
and
open
that
Gap.
If
you
would
please
conformance
profiles,
Gap
has
had
a
few
iterations
now,
like
I,
think
four
or
five
PR's.
This
is
going
along.
The
this
has
been
moving
along
quickly
using
the
whole,
like
very
small
iterations
kind
of
concept,
and
it's
been
doing
pretty
good.
It
is
in
provisional
state
for
those
of
you
who
aren't
familiar.
We
also
called
this
conformance
levels
at
one
point,
but
it's
called
conformance
profiles
here
to
not
confuse
it
with
support
levels.
D
I
would
definitely
anybody
who's.
Well,
probably
everybody
on
this
call,
but
like
most
people
who
are
using
the
conformance
test,
Suite
should
probably
check
this
out.
Give
it
a
look
over
I
think
plenty
of
people
on
this
call
already
have,
but
more
or
less.
This
describes
the
system
in
which
we
would
have
profiles
which
you
can
subscribe
to
and
say.
This
is
the
profile
that
I
want
to
test.
D
When
you
use
the
test
Suite,
it
runs
and
then
It
ultimately
produces,
and
you
can,
if
you
scroll
down
a
conformance
report,
there's
some
examples
of
yaml
of
that
and
those
performance
reports
can
be
submitted
back
to
Gateway
API
for
basically
for
certification
and
and
recognition
and
badges
markdown
badges
you
can
put
on
your
repos,
and
so
that
is
underway.
There's
been,
there
are
a
few
people
who
are
actively
contributing
to
it.
D
Leor
and
Arco
are
also
contributing
to
this
and
Sanjay
and
we're
just
kind
of
all
kind,
getting
it
to
the
point
where
I
think
we're
about
ready
to
call
it
maybe
experimental,
but
I
would,
as
it's
kind
of
sitting
here
right
now,
I
would
encourage
everybody
go
look
through
it.
We
really
would
love
to
have
your
collaboration
on
this
and
feel
free
to
make
changes
like
feel
free
to
make
a
small
PR
and
be
like
hey
I
think
this
is
a
better
idea
or
I
think
you
should
add
this.
D
That
kind
of
thing
is
very
wanted.
One
of
the
big
things
that
we
for
sure
know
we
need
is
we're
not
sure
how
the
display
layer
is
going
to
look
yet
so
once
you
report
your
conformance,
that's
all
you
know.
No.
This
could
all
change
like
everything
you're
looking
at
here.
It's
it's
provisional.
We
may
change
significantly,
but
we've
got
the
basic
idea
of
what
we
want
to
do.
D
So
we
know
that
we
want
to
submit
these.
We
don't
want
to
add
infrastructure
for
this,
so
we
just
want
to
submit
them
to
the
repository
for
now
and
then
later
we'll
see
how
that
goes.
D
But
when
you
do
that
we
know
we
want
to
provide
like
a
badge
that
says
you
know:
I'm
conformant
with
layer,
seven
conform
layer,
four
conformative
mesh,
but
we
don't
really
know
what
we
want
the
dis
we
want
to
have
some
kind
of
a
nice
display
layer
somewhere
and
the
current
idea
is
to
put
it
in
the
implementations
page
as
like
a
header
or
a
widget
under
your
implementation.
That
gives
like
a
nice
human,
readable
sum
like
not.
This
is
machine
readable.
This
is
meant
to
be
used
by
a
program.
D
Nice
human
readable,
like
display
of
like
what
your
conformance,
is,
what
features
you
support
that
kind
of
thing.
So
that's
we
want
something
like
that,
but
I
am
not
a
front-end
person
and
like
not
good
at
designing.
D
If
you
ask
me
to
make
a
website,
you
are
going
to
get
like
an
HTML
BSD
man
page
so
looking
for
some
kind
of
help
from
somebody
who
has
a
touch
a
knack
for
making
things
look
nice
to
come
in
and
say
how
the
display
level
is
going
to
work
in
particular,
but
definitely
want
encourage
people
to
just
put
in
PRS
in
general
and
just
read
this
over
because
it'll
affect
everyone.
A
Yeah
I
I'm,
looking
forward
to
this
I
I
trademarks
in
place
for
conformance
I,
don't
think
so,
but
I
know
we.
We
have
had
some
discussions
with
cigarch
and
some
of
the
people
that
have
been
involved
in
kubernetes
overall
conformance
with
this.
They
recommended
following
the
the
same
general
process
that
kubernetes
conformance
follows,
which
is
that
it's
it's
self-reported
reports
that
are
filed
centrally
in
those
reports
are
really
actually
just
test
logs
that
are
uploaded
and,
and
you
know,
instructions
for
how
they
ran
the
conformance
tests.
A
I
imagine
ours
will
actually
be
slightly
more
structured
in
the
sense
that
you
know
like
Shane
and
others
have
posed
here-
will
actually
have
a
better
overall
summary
than
just
test
logs
I'm.
A
Yeah
it
hit
us,
it
is
and
I
think
I
think
one
of
the
concepts
that
is
different
with
our
idea
of
conformance
from
Upstream
conformances
that
there
are
features
you
know,
there's
not
it's
not
just
a
you're,
conformant
or
you're,
not
there's.
There's
a
lot
of
Middle
Ground
here
of
I'm,
conforming
with
everything,
that's
core,
but
maybe
not
everything,
that's
extended,
and
so
our
tests
need
to
document
that
and
represent
that
well.
A
I'm
also
really
excited
about
being
able
to
report
conformant
status
on
the
implementations
page.
We
have
a
lot
of
implementations
and
that
list
is
only
growing.
Thank
you.
Everyone,
but
I
I,
really
am
looking
forward
to
you
know
for,
for
the
sake
of
someone
coming
to
Gateway
API
I'm
wanting
to
try
it
out,
you
know,
being
able
to
say.
Oh
hey
here
are
the
fully
conformed
versions.
Maybe
I'll
start
there
that
that
seems
like
a
really
good
way
to
differentiate
implementations,
yeah.
D
Implementing
this
and
or
who's
got
this
you
know,
feature
support
and
that
kind
of
thing
this
will
help,
probably
not
perfectly,
but
this
will
help
us
to
be
able
to
actually
just
literally
go
look
and
see
who's
implementing
what
or
who
supports
what
features
and
stuff
like
that,
which
will
be
great
from
a
maintainer
perspective
compared
to
what
we've
had
to
do
in
the
past.
So.
G
Mentioning
trademark
stuff
I
would
follow
up
with
someone
I
don't
know
who,
because
the
whole
point
of
conformance
in
kubernetes
is
to
say,
like
hey,
I
can
say:
I'm,
kubernetes,
conformant
and
then
I
advertise
kubernetes
on
my
implementation
website
and
I.
Think
the
trademark
is
there
in
places
to
prevent
people
from
saying
that
they
support
kubernetes
when
they
actually
don't
actually
I.
Think
like
doing
these
performances
then
allows
you
to
advertise.
Those
logos
and
yeah
sounds
good.
D
I'll
be
putting
out
a
so
I,
am
I
am
personally
talking
with
cigarch,
but
I
would
encourage
other
people
to
come
to
the
meetings
and
stuff
I'll
be
putting
out
a
message
on
the
cigarch
mailing
list
today.
Basically
kind
of
letting
them
know
where
we're
at
since
we're
in
provisional.
If
you
want
to
I,
would
definitely
we
have
a
to-do
list
at
the
top
you
scroll
at
the
top
and
basically
it's.
These
are
the
things
we
must
do
before.
D
G
Yeah,
just
just
think
of
the
use
case
of
someone
implements
says
the
Implement
Gateway
API,
but
they
don't
so
you
prevent
them.
There's
a
note.
D
It's
going
to
be
really
hard
to
try
to
catch
proprietary
implementations
like
falsifying
the
information,
and
so
that's
not
fair
to
everybody
else,
certainly
but
and
two
I
think
that
the
reputation
loss
for
getting
caught
doing
that
like,
if
you
do
that
and
then
eventually
get
caught,
your
reputation
lost
in
the
kubernetes
community
is
going
to
be
like,
like
I,
don't
think
it's
worth
it
but
again
I'm
willing
to
be
argued
with,
but
I
said
for
right
now.
D
H
So
on
the
varying
levels
of
conformance
compatibilities,
so
certain
projects
are
going
to
be
intentionally
very
specific,
like
have
specific
use
cases
so
like
a
Broadway
off,
my
gate
would
always
drive
or
full
performance.
But
you
know
if
someone
wants
to
go
and
Implement
a
production
version
of
Blitz.
You
know
Blix
Pro,
if
you
say
that's
just
specifically
for
L4
like
they
would
never
Implement
an
HTTP
route
so
but
they're
still
conformant
fully
conformant
in
this
narrow
areas
like
they
have
all
the
L4
performance
compatibility.
So
I'm
not
sure
how
you're
gonna
I
mean.
D
Is
a
profile
that
is
what
a
profile
is
considered.
Is
that
area
that
category
so
layer?
Four
is
its
own
category?
We
will
add
more
categories
later
I
am
certain.
We
also
have
extended
support
and
potentially,
eventually,
implementation,
specific
I,
don't
know
how
that's
gonna
work,
but
there's
a
note
about
it,
but
we're
not
trying
to
deal
with
it.
Just
a
second
that
you
can
optionally
have
like
features
supported
for
those
can
be
reported,
as
well
as
like
extra
features.
H
Yeah,
there's
also
like
some
weird
use
cases
like
so
like
there's
that
one
that
one
I
forget
what
the
name
of
it.
But
there
was
that
one
guy
who
presented
like
a
very
narrow
use
case
of
like
I,
think
a
few
meetings
ago,
where
they
only
implemented
like
one
or
two
resources,
like
a
very,
very
I,
forget
what
the
exact
thing
was
like
something
about.
D
G
D
Gateway
class
and
UDP
route,
specifically
yeah
they're.
That's
that's
a
good
point.
We'll
have
to
I
I
need
to
check
in
with
him
because
I
don't
know
if
they're,
if
he's
actually
planning
on
adding
TCP
route
support.
I
know
that
the
Project's
pretty
early
on,
but
there's
probably
room
for
adding
special
profiles
like
for
something
like
that.
A
That's
it's
related
to
some
of
the
thoughts
I've
had
too
I
think
we
may
as
much
as
profiles
are
yeah
a
very
helpful
concept
that
many
people
will
fit
in
I
I
think
it
may
be
beneficial
to
have
per
resource
instead
of
you
know,
groups
of
resources,
just
because,
like
another
example
is
someone
may
want
to
do
a
grpc,
only
Gateway
implementation.
D
Leaves
the
door
open
like
right
now?
We
just
know
that
these
are
going
to
be
the
more
common
ones
right
or
layer.
Seven
is
gonna,
be
the
most
common
one
and
there's
going
to
be
people
who
want
to
do
multiple
ones
like
istio
will
likely
do
layer,
four
layer,
7n
mesh,
but
they
really
just
refer
to
collections.
D
So
I
I,
hear
you
and
I
would
definitely
have
you
say
like
come
in
here
and
say
what
like
put
some
notes
down
in
here
with
us
and
say,
like
the
things
that
you
think
are
probably
going
to
be
things
we
need
to
address
sooner
rather
than
later,
but
the
door
is
definitely
open
for
us
to
have
these
profiles
change
names
and
to
add
more
that
one.
That's
like
I
only
do
grpc
route,
but
they're
just
meant
to
be
shorthand
for
what
is
currently
like
supported,
features
and
Skip
tests
and
stuff.
H
H
You
said
or
UDP,
for
example,
but
I
also
think
that,
having
like
a
per
resource
conformance
section
as
well,
the
kind
of
capture
like
the
full
edge
cases
could
would
also
be
beneficial
in
addition
to
profile.
So
profiles
is
like
a
high
level
overview,
but
then
you
can
kind
of
dig
in
and
say:
okay,
what
specific
resources
do
you
and
extensions
to
use
them?
Where.
D
D
I
would
love
to
have
you
all
like
put
in
PRS
to
add
the
things
and
the
changes
and
the
thoughts,
and
they
can
just
be
notes.
The
to-do
list
items
that
you
want
to
see
taken
care
of
for
because
I
want
everybody
to
be
included.
I
don't
want
anybody
to
feel
like
they're
getting
excluded
from
this
and
then
suddenly
they
have
to
adhere
to
it.
So
please
do
jump
in
and
make
a
PR.
A
Oud
great-
and
it's
really
excited
really
exciting-
to
see
this
all
coming
together.
I
mean
this
is
something
I
wanted
in
the
project
for
a
really
long
time.
It
sounds
like
there's
some
good
feedback
here
that
we
can
build
on,
but
I
mean
just
to
have.
This
will
be
huge.
So
thanks
to
Shane
and
everyone
working
on
this
I
know,
there's
been
a
few
different
people
helping
out
yeah
it's
great
but
I,
know.
We've
got
a
lot
left
on
the
agenda,
so
I'll
keep
on
moving
I.
Thank
you.
A
Antonio
I
remember
asking
Antonio
to
come
and
give
a
little
bit
of
an
update
about
the
service,
cider
and
IP
address
cap,
because
it's
entirely
relevant
or
Gateway
API,
so
I'm
going
to
skip
to
that,
because
we've
left
Antonio
waiting
for
longer
than
I
intended
to
thank
you
Antonio,
maybe
can
you
can
you
give
just
a
high
level
overview
of
of
what
you've
been
working
on
with
this
cap
and
maybe
for
bonus
points
how
it
might
be
relevant
to
Gateway
API.
I
A
I
Main
goal
of
the
cup
started
because
on
for
into
that,
each
kubernetes
service
has
a
cluster
ID,
okay
and
requested
AP
is
unique,
so
you
kind
of
have
two
services
with
two
cluster
City.
This
is
achieved.
The
the
implementation
is
in
the
API.
Server
is
a
bitmap
that
is
shared
and
a
snapshot
in
Italy
and
has
a
lot
of
performance,
implication
and
scalability
implications.
I
So
we
have
to
use
at
last
112
for
IP
disease,
for
example,
and
I
started
working
on
this
in
two
two
or
three
years
ago,
and
the
decision
to
be
able
to
have
a
assign
a
piece
in
a
multitasker
environments,
keeping
the
concurrency
and
all
this
problems
was
to
create
a
new
object
that
was
called
IP
address.
I
Do
you?
The
only
use
case
I
have
is,
is
for
services,
so
I
know
Rob
told
me,
people
is
excited,
but
I
I
really
wanted
to
know
the
use
cases,
because
you
know
how
kubernetes
is
once
we
Implement
something
in
this
start
graduating
and
then,
after
that,
changing
something
is
going
to
be
difficult.
So
right
now
the
only
use
case
is
this
is
to
create
a
service.
I
I
What
happens
in
something
wants
to
create
IP
addresses
here?
What
happens
if
I
don't
know?
We
need
more
controllers
and
all
these
things
and
I
couldn't
come
up
with
any
use
case
or
both
told
me.
People
is
excited
and
interested
about
this
API.
So
you
have
use
cases,
please
comment
or
reach
out
or
whatever
to
to
be
able
to
to
adapt
the
API
to
to
all
the
use
cases.
A
Yeah
no
thank
you.
Thank
you
for
good,
good
introduction
and
I
and
I.
Think
the
the
top
thing
that
I
I'm
interested
in
is
this
idea
that
you
have
an
IP
address
resource
and
that
IP
address
resource
has
a
parent
reference
that
references,
the
resource,
usually
services,
that
an
IP
address
would
be
attached
to.
A
We
just
haven't
really
specified
how
we'll
make
this
work,
but
I
I
know
that
this
feels
very,
very
relevant
to
to
our
longer
term
goals
with
Gateway
and
there's
some
gaps
right
now.
I
think
gaps.
E
A
I
E
I
They
have
now
is:
is
the
generation
okay,
because,
right
now,
when
you
you
create
service
to
assign
a
service
either
to
their
class
right,
and
the
idea
is
that
you
can
create
more
service
sizes
and
now
it's
when
I'm
blocking
right
now,
because
I
we
have
another
cap.
That
is
adding
no
side
and
we
cannot
overlap,
and
if
we
have,
we
had
this
problem
with
the
importance.
Thank
you
proxy.
I
A
A
A
Okay,
we'll
leave
it
there,
but
thank
you
thank
you.
So
much
Antonio
I
can
follow
up
offline
later
and
anyone
else,
please.
If
you
have
ideas
for
how
you
could
use
this,
you
know
or
or
what
might
be
missing,
I
really
want
to
make
sure
you
know
this.
This
is
a
really
good
opportunity
for
Gateway,
API,
I,
I,
think
and
and
I
want
to
make
sure
like
Antonio
said.
E
A
And
and
like
what
Keith
is
saying,
you
know
this.
This
feels
especially
relevant
to
mesh.
A
All
right,
the
the
next
thing
I
wanted
to
just
come
back
around
to
is
this
idea
of
configurable
retries
I
found
this
a
little
bit
ago.
Actually
it's
only
three
weeks,
but
I
just
wanted
to
bring
it
back
up
again
in
case
anyone
is
looking
for
a
project
to
take
on.
This
is
one
that
I
think
is
non-controversial
would
be
a
great
addition
to
the
API,
and
you
know
I
I,
think
there's
at
least
some
people
that
would
be
interested
in
having
it.
A
You
know
I
I'm
sure
somebody
will
eventually
get
to
it,
but
if
you're
looking
for
some
way
to
contribute,
that
is
actually
adding
a
feature
to
this
API.
This
one
is
available
and
and
wanted
so
I'm
just
throwing
that
out
there
for
someone
who
might
be
interested
in
going
through
the
full
enhancement
process
feel
free.
A
If
you
are
interested
to
to
add
a
comment,
but
just
another
reminder
that
this
one
exists
all
right
with
that
said,
policy
attachment
I
think
right
now
we
are
stuck
on
policy
attachment
naming
among
other
things,
we
we
could
use
some
some
additional
reviews
on
this
PR,
because
it
again
represents
a
significant
change
to
policy
attachment
and
thank
you
to
everyone.
A
Who's
left
comments,
but
I
think
one
of
the
things
that
keeps
on
being
a
blocker
is
the
word
hierarchical,
which
you
know
the
the
idea
is
there's
direct
policy
attachment,
which
is
this
new,
simple
form,
but
there's
also
the
hierarchical
concept
of
you
know,
being
able
to
specify
overrides
and
defaults
at
different
layers
of
the
stack
and,
as
you
can
imagine,
that
word
is
both
painful
to
say,
and
especially
the
spell
it's
very
easy
to
make
typos
when
trying
to
spell
that
word
so
I
think
I
was
the
one
who
originally
proposed
the
word
hierarchical,
but
it
it
a
different
term
would
be
very
welcome.
A
So
for
anyone
who,
who
is
better
at
naming
things,
definitely
add
any
ideas
on
this
Gap
and
yeah
I
know
I,
know,
there's
additional
feedback
here,
I,
don't
I,
don't
know
Shane.
Do
you
have
any
more
contacts?
I've
I've
been
out
for
a.
D
Few
days
it's
changed
a
lot
since
I
originally
approved
it.
I
was
hoping
that
this
would
go
through
more
of
a
an
iterative
process
where
we'd
make
smaller
PR's
I
probably
need
to
look
this
one
back
over
for
more
recent
changes.
A
This
this
one
is
is
tricky
because
it's
a
big
change,
but
it's
a
big
change
to
an
existing
Gap.
So
it's
hard
to
like
do
it
in
small,
like
small
little
chunks
or
it's
I,
don't
know
but
yeah.
This
is
a
massive
PR
and
there's
lots
too
lots
of
process
in
it.
But,
as
always
feedback
is,
is
welcome
this.
This
feels
like
something
that
could
change
a
lot
and
I
know.
E
A
Okay,
I'll
keep
on
moving
then
just
got
a
few
minutes
left
here.
Michael
Beaumont
added
this
one
I
think
this
one
was
uncontroversial,
but
I
wanted
to
actually
anytime
that
there's
a
test
that
is
against
conformance
I,
want
to
make
sure
that
this
works
with
a
few
implementations
and
doesn't
get
in
the
way
of
them.
So
usually
all
manually
run
conformance
myself,
but
also
it's
helpful
if,
if
others
with
implementations,
are
able
to
comment
and
say
yeah,
this
makes
sense
to
me.
From
my
perspective,
this
seems
like
a
very
reasonable
change.
A
Has
anyone
I
think
I
think
Arco?
You
mentioned
that
you
had
had
some
flaky
tests
as
well.
That
may
be
related
to
this,
so
yeah
I
would
be
interested
in,
in
others
running
these
tests,
confirming
that
this
change
is
reasonable.
I
think
it
seems
like
if
you
do
nothing
but
fixed
things.
A
Yeah,
okay,
so
just
yeah.
If
we
can
get
a
couple
more
comments
on
this
PR
itself
to
confirm,
then
I
think
this
makes
a
lot
of
sense.
A
F
E
I
F
I
kept
it
together
is
because
I
don't
end
up
with
one
of
those
situations
where
we
have
four
PR's
and
they're
all
inter
mingled,
so
I
think
keeping
it
together
now
and
then,
once
we
get
a
little
bit
of
consensus
splitting
out,
some
of
the
details
will
make
more
sense
because,
like
there's,
this
new
field
infrastructure
and
every
aspect
of
it
relies
on
that
new
field,
and
so
until
we
get
kind
of
some
agreement
on
that,
I
think
it's
easier
to
keep
them
together.
F
A
Well,
yeah,
it
looks
like
it's
changed
even
a
bit
since
the
last
time,
I
took
a
look
so
I'll
come
back
to
this
one
this
week,
trying
to
set
another
round
of
feedback.
F
F
Yeah
I
think
we'll
probably
have
one
on
merging
gateways
or
an
iteration
on
the
existing
one,
maybe
because
I
think
for
Mary
to
be
one
and
then
there's
customization
of
in-cluster
deployments
and
possibly
a
third
I
kind
of
forget.
Certainly
the
merging
part
I
think
will
be
split
out.
F
A
Yeah
and
I
I,
you
know
your
point
about
this.
This
kind
of
field,
or
this
kind
of
configuration
of
buying
not
just
to
in
cluster
planets
I,
mean
I,
think
that
that
would
certainly
be
good
if
we
could
make
it
generic
enough
that
it
could
apply
to
any
Gateway
implementation
and
it
sounds
like
that's
the
way
it's
headed,
so
yeah
I'll
follow
up
cool
all
right
next,
one
on
the
list
and
I
just
added.
D
A
Yes,
I
had
ones
that
look
interesting
to
me,
but
as
always,
if
something
like
means
is
attention,
don't
hesitate
to
add
it
through
the
agenda.
A
This
one
is
a
grpc
route
method
and
service
Fields
added,
tighter
validation
that
did
not
was
not
compatible
with
regular
Expressions.
So
this
takes
this
PR
takes
that
validation
that
applied
to
every
kind
of
match
type,
because
it
was
in
the
crd
and
moves
it
to
the
Web
book
instead,
where
it
can
be
specific
to
a
given
path
to
a
match
type,
this
seems
fun
to
me.
It
will
actually
result
in
loosening
our
validation
somewhat,
but
just
a
heads
up
that
this
is
a
somewhat
significant
change
to
grpc
Route.
A
H
A
A
big
one,
so
yeah,
I
I,
know
we
discussed
this
Nick
had
some
ideas
and
I.
Think
Arco
has
updated
based
on
Nick's
ideas
in
the
previous
meeting,
but
it
would
be
very
good
to
Circle
back
since
yeah
this.
This
Gap
has
changed.
This
PR
has
changed
significantly
in
the
past
week,
but.
A
D
D
Just
real
quick,
we
are
going,
we
don't
have
anything
scheduled
yet,
but
beyond
the
lookout
we
are
going
to
try
to
schedule.
Probably
another
one
of
these
at
some
point
where
it's
earlier
in
the
day.
Thank
you
all
for
coming
to
it,
but
like
just
keep
a
look
out
and
slack
and
stuff
like
that,
because
this
we're
probably
not
going
to
make
it
a
regular
thing
just
yet,
but
we
will
make
a
future
one
on
early
morning,
one
again
and
just
see
how
the
attendance
holds
up.
A
Cool
all
right
thanks,
everyone
see
you
tomorrow
or
next
week.