►
From YouTube: SIG Network Gateway API meeting for 20230801
Description
SIG Network Gateway API meeting for 20230801
B
Hopefully,
you
can
see
the
meeting
notes
which
I
don't
have
in
my
usual
dark
mode.
For
some
reason
there
I
don't
know
why
that
happened.
There
we
go.
That's
better.
Okay,
so
today
is
the
first
of
hopefully
a
I.
Think
today
is
the
first
of
we
are
going
to
do
the
first
Tuesday
of
every
month
as
an
e-friendly
time,
which
is
this
is
8
A.M,
Pacific
time
which,
for
a
lot
of
Europe,
ends
up
being
in
the
early
afternoon.
B
We
really
more
so
than
most
meetings.
It
would
be
nice
for
you
to
put
your
name
on
the
agenda.
The
attendees,
because
it
just
kind
of
helps,
give
more
Credence
to
having
this
alternative
time
zone.
When
we
can
see
a
big
turnout
and
we
do
have
a
pretty
big
turnout.
We
have
16
people
here,
which
is
especially
interesting.
B
Considering
we're
our
calendar
stuff
is
broken
and
we
couldn't
actually
send
out
the
invites
so
I'm
really
glad
to
see
so
many
people
here,
given
that
the
invite
wasn't
working
correctly,
which
we
will
get
fixed
soon,
yeah
so
for
anybody
who's
new
here,
please
do
feel
free
to
kind
of
raise
your
hand.
Use
the
zoom
raise
your
hand
function.
B
We
are
an
open
Agenda.
So
if
you
have
anything
you
want
to
bring
to
the
agenda,
please
feel
free
to
put
it
here
above
the
triage,
which
will
be
what
we'll
do
at
the
end.
If
we
have
time,
if
we
don't
make
it
to
your
agenda
item
today
for
some
reason,
which
I
think
will
be
okay,
given
what
we
have
so
far,
we
will
try
to
fold
that
over
into
the
next
meeting,
and
if
you
can't
make
the
later
meetings,
then
maybe
we'll
fold
it
into
next
month's
meeting
for
you.
A
D
Yeah
so
I
feel,
like
I've,
been
talking
about
this
release
for
ages
now,
I
I
think
we
actually
are
getting
close,
but
the
big
milestone
that
happened
last
week
is
we
finally
got
enough
time
with
all
the
Sig
Network
reviewers,
which
are
basically
Tim,
Cal
and
Mike
Zappa
as
well,
and
got
to
basically
present
what
we
were
hoping
to
change
in
080
and
I'm.
Realizing
we
had
some
slides
I
can
share
those
I'll,
add
them
to
the
agenda
after
and
some
meeting
notes
as
well.
D
The
reason
we
do
this
is
we're
trying
to
you
know
basically
speed
up
the
review
process
as
quickly
as
we
can.
The
the
whole
organization
structure
of
Sig,
Network
kubernetes
as
a
whole,
is
when
you're
a
sub
project
to
get
a
release
to
you
know,
get
approval
whatever
you
need
to
come
back
and
and
talk
to
Sig
chairs,
API,
reviewers,
Etc
and
run
by
whatever
ideas
you've
had
happen.
You
know
you've,
you
want
to
release
so
yeah.
Thank
you.
D
Thank
you
for
whoever's,
adding
a
link
to
those
slides,
perfect
and
so
yeah.
We
we
did
that
presentation
and
it
gives
us
kind
of.
We
basically
take
an
hour
and
we
try
to
have
those
initial
discussions
about
the
new
enhancements.
A
lot
of
it
was
gamma
this
time
that
we're
trying
to
get
through,
and
usually
it's
a
formality.
D
This
time
we
got
more
feedback
and
more
pushback
on
on
both
both
the
major
themes
that
we
were
presenting.
One
of
them
was
gamma,
and
one
of
them
was
readability,
gamma,
the
the
pushback
was
and
and
I
was
definitely
not
the
the
only
person
there,
so
anyone
Shane
Flynn,
whoever
else
was
on
that
call
feel
free
to
to
fill
in
gaps.
Gamma.
D
We're
we're
taking
that
that
thing
that
kubernetes
Sig
Network
shares
kind
of
regret
and
we're
just
like
you
know,
just
embracing
it
and
going
all
in
and
so
that
that
makes
them
uncomfortable
I
guess
you
could
say
they
they
would
broadly
consider
it
not
not
not
pretty.
What
was
what
was
the
word
that
was
used.
I,
think
stinky
was
a
word
that
was
used.
You
know.
A
D
D
D
D
So
the
idea
is
that,
for
those
that
aren't
familiar
with
routability,
we
introduced
three
address
three
types
of
routability
public,
private
and
cluster,
and
the
idea
is
that
you
would
say:
I
want
a
public
Gateway
and
you
get
a
Gateway
that
was
exposed
to
the
internet
or
you'd
want
a
cluster
Gateway,
and
that's
one
that
just
gives
you
a
cluster
IP.
Roughly.
D
D
Or
what
does
it
mean
to
be
private
in
that
context?
What
if
you
know
instead
there's
more
Nuance
of
I'm
accessible
on
these
two
networks
or
on
this
network
or
whatever?
But
this
is
you
know,
I
guess,
I
guess
this
is
the
value
of
bringing
this
back
to
Sig
Network
leads
is,
is
that
they
there
are
more
Sig
Network
sub
projects
than
just
Gateway
API
and
multi-network
is
one
of
them
that
you
know
we
have
not
interacted
with
that
much,
and
this
is
one
area
where
we
would
intersect
and
potentially
not
well.
D
I
do
think
that
cluster
IP
and
multi-network
actually
largely
make
sense
together,
like
I,
want
a
cluster
IP
from
Network.
Foo
is
a
fairly
sensible
thing
to
do,
but,
as
seems
to
be
the
trend
for
this
specific
Gap,
we're
really
struggling
to
Define
terminology
for
Network
Concepts
that
are
kind
of
outside
of
the
kubernetes
bubble
like
inside
kubernetes.
We
understand
and
have
defined
what
cluster
IP
means
outside
kubernet
like
outside
kubernetes.
The
terms
are
a
little
Messier
shall
we
say
public
and
private
aren't
as
well
defined
as
I
would
like
and
yeah.
A
E
Their
roadmap
shows
they're
going
to
address
service,
multi-service
multi-network
Services
next
year,
so
I'm
like
okay,
so
I
wonder
if,
like
the
the
workaround
is
like,
instead
of
defining
these,
what
I
would
call
more
user-friendly
constants.
Essentially,
maybe
the
ask
then
was
like
we
do
references
to
network
resources,
kind
of
how
we
do
like
parent
refs,
but
and
that
they
can
handle
like
hey,
instead
of
being
the
route
of
daily
use
line
and
Gateway
to
a
bunch
of
Networks.
C
I
think
the
fundamental
issue
we
were
running
across
was
that
it
seemed
that
nobody
had
great
answers
for
how
to
reference
those
semantics
in
a
way
that
made
sense
when
we
took
multi-network
into
account,
there
wasn't
any
pushback
of
sorry.
Let
me
phrase
that
more
gracefully
the
feedback
we
got
was
very
much
hey,
go
talk
to
the
multi-network
guys
and
then
let's
come
back
and
figure
out
what
to
do
as
opposed
to
no
no,
never
do
this,
but
this
was
last
Thursday
I
think
it
was.
A
E
I
created
a
slack
thread
just
not
about
this
topic,
but
just
like
what
the
roadmap
is
there.
It
feels
like
they're
so
far
away
from
being
able
to
offer
opinions
here,
so
I
think
it's
like,
and
that
just
makes
this
API
gonna
be
like.
If
you
make
it
open
enough
to
be
able
to
reference
some
arbitrary
resource
that
might
or
might
not
exist
in
the
future,
then
we
can
have
the
submit
then
meet
allow
ourselves
to
if,
like
public,
could
be
defined
by
an
arbitrary
list
of
networks.
B
B
You
I
I
still
think
that
we
should
probably
go
ahead
and
start
that
conversation
with
mache
and
Zappa
and
Zappa
also
goes
to
those
meetings.
Frequently
more
than
me,
actually
I
haven't
been
able
to
go
to
the
last
couple
and
just
get
that
ball
rolling
because
they
may
have
some
other
ideas
too.
They
may
understand
that
that
trying
to
tie
us
together
might
actually
have
problems
for
both
of
us
even
and
we
can.
B
We
can
come
to
a
discussion
that
can
lead
to
like
okay,
go
back
to
Cal
and
and
Tim
and
be
like
well.
We
can't
really
combine
these
efforts
for
this
purpose,
and
here
are
our
timing.
Problems
I
think
we
can
I
think
we
can
I.
Think
it's
not
a
you
said
Salvage
and
I.
Don't
think
we're
in
that
shape
at
all
with
this,
we're
in.
D
B
D
Yeah
and
I
I,
my
my
own
thoughts
here
is-
are
that
yes,
multi-network
will
take
a
while
to
Define,
but
I
think
what
we
need
from
that
group
that
that
working
group
specifically
is
some
kind
of
agreement
or
sign
off
that
wherever
we,
you
know
that
we
have
a
plan
that
will
work
with
their
eventual
plans.
You
know
like
we
don't
need
to
wait
for
them
to
have
fully
defined
everything.
D
We
just
need
to
have
some
kind
of
agreement
that
the
direction
we're
going
can
be
compatible
with
the
direction
they
want
to
go
or
any
number
of
directions.
They
may
go.
I
think
that
that's
my
perspective,
but
I
agree
the
timing.
You
know
there
there
earlier
in
in
design
development
than
we
are
at
this
point,
and
and
we
don't
want
to
wait
for
them
to
complete
their
development
before
we
can
just
move
on
with
this
Gap.
A
E
D
So
I
should
also
add
I,
think
you
know
we're
still
on
this
General
topic
that
I
feel
bad,
that
we
missed
this
and
by
we
I
mean
people
that
reviewed
the
gap
before
we
took
it
to
you
know,
presented
it
to
Sig
Network
as
a
whole.
I
really
want
to
avoid
this
kind
of
Disconnect,
surprise
whatever
in
the
future.
It's
really
an
awful
feeling
to
have
seeing
so
much
awesome
work
go
into
this
just
to
you
know,
squeeze
it
into
080
and
then
at
the
last
minute
you
know
I.
D
It
ends
up
getting
bumped
from
the
release.
So
one
sorry
that
that
happened
and
two
I
want
to
do
everything
we
can
to
avoid
that
from
happening
in
the
future.
That's
a
shared
opinion
with
with
others
that
the
people
that
we're
reviewing
as
well
from
Sig
Network
side,
so
you
know
I,
think
I
think
there's
a
lot
of
appetite
for
having
more
involvement
in
discussions
with
Tim
Cal
Zappa
Etc
earlier
on
one
of
the
easiest
ways
to
do.
That
is
just
to
take
these
gaps.
D
Once
we
have
some
kind
of
consensus
or
rough
consensus
within
Gateway
API,
just
bring
it
up
to
Sig
Network
meetings.
They
meet
every
two
weeks
that
set
of
people
are
there.
We
can
do
a
rough
high
level
review
of
hey.
Are
you
seeing
something
that
here
that
we've
missed
that
affects
other
sub-projects?
That
affects
other
cigs?
You
know
whatever
it
might
be,
definitely
want
to
avoid
this
kind
of
pain
in
the
future.
D
For
reference,
we
did
have
one
other
gap
that
had
to
get
pulled
back
at
the
last
minute
in
in
the
past,
but
you
know,
unfortunately,
we
just
we
just
missed
the
the
multi-network
aspect
here
so
yeah.
Sorry,
sorry
that
we
missed
that
and
we
will
work
on
getting
a
better
process
involved.
So
there
are
less
ugly
surprises
like
this
at
the
last
minute.
Hopefully,
none
yeah,
that's
I,
think
that's
the
updates
for
the
080.
Well,
that's
just
080
review
the
080
timeline
we'll
get
back
to
that,
the
Oedo
timeline.
D
D
B
D
C
D
D
It
was
already
there.
No
it's
fine,
but
yes,
I
agree!
That's
another
yeah!
That's
another
thing.
We
were
so
close
on
on
getting
that
and
I
thought
we
were
on
track
for
080,
but
I
mean
I
guess.
Fortunately,
we
caught
that
before
it
got
too
far,
but
yeah
timeout
formatting
is
way
more
complicated
than
I
ever
dreamed
possible.
D
D
D
An
API
review,
slack
thread
that
has
more
discussion.
It
I
there's
good
luck,
trying
to
follow
the
discussion
here
and
then
in
API
reviews
as
well.
I
think
if
you
go
all
the
way
to
the
very
bottom,
I
tried
to
summarize
what
I
think
the
consensus
is
here
that
we're
aiming
for
some
subset
this.
This
is
something
like
that
has
largely
been
the
case
for
a
while
that
we're
aiming
for
a
subset
of
what
is
possible
via
cell
and
go
duration
formats.
C
I
think
it
does
not
I
I
I've
spent
a
little
while
looking
into
this
and
I
have
become
convinced
that
when
kubernetes
says
the
API
server
takes
an
OPI,
open,
API
spec
and
does
validation
I've
become
convinced
that
what
they
actually
mean
is
we
take
this
thing.
That's
a
open,
API,
spec,
plus
some
additional
type
definitions
and
use
it
for
validation.
C
You
know
I
great
fine
interpretation,
but
it
does
raise
some
interesting
questions
of
whether
we
should
simply
say:
let's
just
use
the
syntax
that
kubernetes
already
accepts
for
this
rather
than
defining
yet
another
one.
The
big
I
hesitate
to
say
limitation,
the
big
source
of
some
controversy.
There
seems
to
be
that
kubernetes,
open,
ibi-ish
validation
will
accept
units
of
days
and
weeks
which
don't
really
make
sense
for
time
timeouts,
although
they
do
make
sense
for
durations
like
certificate
expiration
times.
C
D
D
D
I
think
the
argument
is
that,
for
whatever
strange
reason
cell
has
some
the
format
defined
by
cell
while
kubernetes
open
at
API
validation,
whatever
that,
whatever
that
thing
is,
is,
is
different
and
and
has
some
very
strange
variations
from
go
duration
formats
and
I.
Think
there's
a
very
strong
preference.
I
know:
I
have
a
strong
preference
to
have
the
ability
to
parse
this
both
with
go
duration
and
I
know
other
other
languages
also
support.
D
C
C
I
was
about
to
say
the
major
distinction.
There
is
the
lack
of
floating
point
for
open
API,
but
no
the
other
one
is
that
time.
Dot
parse
duration
has
days,
but
not
weeks,
if
I
remember
correctly
and
stir
format.paration
has
days
and
weeks,
but
broadly
enough,
stir
format
is
a
go
library
that
is
already
linked
into
the
kubernetes
API
server.
So
there's
not
really
an
issue
with
parsing
this
from
golang
yeah.
It's
it
is
a
weird
thing
to
me.
B
D
B
C
I
think
the
next
five
minutes
well
I
think.
Clearly
what
needs
to
happen
is
that
Rob
and
I
should
go
and
arm
wrestle
for
a
while
or
something
like
that,
somewhat
less
facetiously
I
think
that
it
would
be
great
if
anybody
else
has
opinions
on
this
one
to
chime
in
on
the
issue
and
or
in
slack.
If
we
want
to
do
it,
there,
I
would
personally
be
kind
of
sad
if
we
can't
get
timeouts
into
0.8
because
of
a
formatting
issue,
and
for
that
reason,
I
would
personally
rather
have
this
in
0.8.
C
B
B
D
Yeah
so
I
I'm
definitely
a
fan
of
more
restricted
format.
I
I
know.
Basically,
everything
is
lined
up,
I
think
if
we
are
trying
to
introduce
scope
before
we
merge
anything,
we
should
have
a
a
very
real
discussion
with
API
reviewer
Signet
API
reviewers,
to
see
if
they
have
issues
with
this
timeouts
is
yet
another
thing
that
has
proven
very
controversial
and
we
have
spent
a
absurd
amount
of
time
going
back
and
forth
on
timeout,
formatting
and
I'm
concerned.
D
D
D
D
We
have
a
very
hard
deadline
of
getting
1.0
out
the
door
in
October
which,
as
open
source
kubernetes,
it
goes
that's
basically
tomorrow
I
mean
not
quite,
but
it
is
things
move
slowly
and
so
we
CA
we
don't
have
much
time
to
fit.
Anything
else
in
is,
is
really
the
goal.
The
idea
here,
so
every
every
ounce
of
effort
is
on
releasing
1.0.
This
0.8
release
is
really
just
preparing
things.
D
That's
been
something
like
we've
been
saying
is
a
big
part
of
the
1.0
release
policy.
Attachment
is
a
big
concern
for
us.
What
we've
seen
is
that
people
continue
to
build
on
top
of
the
policy
attachment
model
that
exists,
and
that's
I,
think
good,
but
we
really
need
to
improve
the
ux,
because
the
ux
as
Flynn
and
others
have
pointed
out,
has
some
very
real
issues
and
that
one's
a
risk
I
would
say
to
the
to
the
health
of
the
API
ecosystem
as
a
whole.
D
If
we're
not
able
to
improve
that
ux
we're
going
to
have
everyone
building
on
top
of
it
and
just
creating
a
poor
experience
across
the
board,
whatever
implementation
you're
using
so
things
that
improve
that
are
absolutely
critical,
and
then
there
are
there's
a
final
class
that
I
think
is
harder
to
Define.
But
there
are
some
features
that
we've
made
a
an
argument
are
critical
enough
that
there's
a
substantial
set
of
users
that
will
not
use
the
API.
If
this
feature
is
not
present,
I
think
timeouts
is
probably
one
of
them,
but
it's.
D
Yeah
I
mean
it's,
it's
actually
pretty
similar
I
mean
that's
that's
a
little
bit
different
than
than
the
routability
Gap,
but
I
think
a
similar
concept
of
I
want
xlb
or
clusterite
yeah,
we'll
see
what
we
can
do,
but
I
think
that's
the
rough
order
of
priorities
that
we
want
to
focus
on,
so
other
gaps
can
move
forward,
but
they
are
not
like.
We
can
talk
about
them,
they'll
be
in
provisional
State
Etc,
but
unfortunately
we
just
don't
have
enough
time
to
include
really
anything
else.
D
In
the
scope
of
this
release
that
doesn't
meet
one
of
those
criteria,
I
would
say
yeah
and
then,
because
you
know
the
timeline
is
very
limited
and
because
we
had
those
kind
of
surprises
in
our
last
review,
our
goal
is
to
provide
regular
updates.
Maybe
every
Sig
Network
meeting
to
just
describe
hey
here
are
the
things
we're
working
on
here's
the
latest
proposal
for
x
and
just
provide
those
opportunities
to
give
feedback
earlier.
So
there
are
less
surprises.
All
around
yeah
I've
been
talking
a
lot,
but
that's
that's.
D
A
Yeah,
so
by
the
way,
not
sure
if
that's
gonna
be
in
scope
for
one
one.
That,
though,
but
yeah
that's
the
gap
for
supported
features
in
the
Gateway
class.
I
I
watched
the
API
review
and
I
see
this
is
in
scope.
So
if,
since
Day
Battery
view,
nothing
has
changed
so
like
you'd
confirm
but
I,
imagine
it's
still
in
scope.
I
incorporate
all
the
feedback
from
the
people.
So
thanks
for
that
so
and
it's
been
waiting
for
a
while.
D
B
A
Yeah
yeah
I'm
not
sure
what
we're
gonna
evolve
with
the
policy
attachments
concerns
that
you
mentioned
before,
but
like
after.
We
have
this
so
I'm
going
to
follow
it
in
similar
Gap
to
update
the
status
with
some
policy
or
related
crds
I'm,
not
sure
if
it's
in
scope
like
policy
attachment
for
but
yeah
like.
Maybe
it
will
be
one
of
the
features
we
need
to
build
at
a
critical
features
before
so
yeah
I'm
watching.
A
D
Yeah
now
that
that's
that's
a
good
question,
I
know
we
have
a
a
set
of
issues
defined.
You
know
the
problems
with
policy
attachment,
as
as
it
exists,
and
one
or
two
potential
Solutions,
including
what
goth
has
been
working
on
with
Gateway
cuddle
and
then
there's
been
some
discussion
about
status,
for
you
know
showing
that
policy
has
been
attached
to
a
resource,
but
I
think
we're
open
to
other
I.
Think
at
this
point,
small
things
yeah.
D
Okay,
yeah
I,
remember,
thank
you,
yeah
I
I
think
this
is
the
kind
of
thing
like
again.
We
have
very
limited
time.
So
we're
not
going
to
be
able
to
you
know,
do
a
big,
a
big
push
for
anything.
But
if
it's
it's,
if
it's
something
that's
small
and
well
contained
and
clearly
helps
the
policy
attachment.
Ux
I
think
that
that
is
the
kind
of
thing
that
we're
trying
to
prioritize
between
now
and
1.0,
yeah
and
yeah.
A
Yeah,
so
yeah
second
bullet
is
the
English
to
Gateway
first
release,
so
we
have
so.
We
want
to
ideally
release
singers
to
get
away
with
zero
0.8,
which
is
going
to
be
the
first
release.
There
is
a
big
refactor
cl2
to
basically
enable
more
providers
specific
logic
to
to
like
to
bring
in
more
provider
specific
logic
and
then
to
actually
make
the
Tool
more
usable,
because
we
are
not
only
converting
English,
as
there
are
many
many
custom
resources
to
be
converted
in
different
implementations.
A
So
yeah
encourage
everybody
like
you
know,
whoever
is
interested
to
review
part
of
it
or
all
of
it,
and
then
ideally,
I
want
to
work
with
a
few
implementations
to
implement.
So
we
I've
shared
with
Rob
about
it.
I
think
we
need
at
least
two
implementations
before
release
it,
so
so
yeah
we're
aiming
for
the
0.8.
A
However,
we
don't
have
a
lot
of
time,
so
we
might
get
later
release-
or
maybe
I,
don't
know
few
weeks
after
but
yeah
ideally
I
want
to
release
it
together
and
maybe
also
provide
like
a
nice
blog
post
to
bring
bring
more
users
to
kind
of
use
it
and
make
it
like
get.
The
initial
feedback
also
before
won
the
row
so
yeah.
So
it
will
help
users
to
actually
migrate
to
to
use
give
API.
D
Yeah
this
is
this
is
awesome.
Big
big
fan
of
everything
that's
been
happening
with
Ingress
Gateway
as
a
as
a
heads
up.
I.
Don't
think.
We've
mentioned
this
anywhere
yet,
but
lior
is
now
an
approver
on
Ingress
to
Gateway,
he's
been
doing
a
lot
of
work
and
has
brought
new
contributors
to
the
project
and
I'm
really
excited
about
getting
that
first
release
out
so
yeah.
D
Thanks
for
taking
ownership
and
Leadership
of
that
project
and
yeah
I
can't
wait
to
see
it's
actually
released
and
just
you
know,
Echo
Whatley
are
saying
we
want
this
to
be
useful
for
not
just
Ingress
API
to
Gateway
API,
but
also
additional
providers.
I
think
some
examples
had
been
like
Contour
has
some
custom
apis
similar
for
istio.
You
know
converting
those
to
Ingress
to
Gateway
API.
Sorry
I
could
be
very,
very
cool
in
this
project,
so
I'm
excited
to
see
kind
of
the
first
steps
of
that.
D
D
A
B
E
Not
a
quick
question,
one
thing,
I'd
kind
of
consider
relevant
was
the
back-end
protocol
selection
Gap
that
I
have
that
uses
The
kubernetes
annotation
the
discussion
Upstream
said
like
hey,
we
don't
care
about
Rob,
We're,
Not
Gonna
makes
no
sense
for
kubernetes
use
case,
but
there's
still
value
I.
Think
in
saying,
like
hey,
this
back
end
has
is
using
like
HTC
or
websocket
as
an
example.
Those
effectively
for
the
the
work
for
Gateway
Focus
here
would
just
be
essentially
I
need
to
update
the
Gap.
E
D
C
E
E
C
E
For
example,
a
lot
of
the
raw
stuff
was
to
indicate
don't
do
any
smart
probing
automatic
probing
and
they're
like
hey,
that's
really
sort
of
out
of
bounds
for
kubernetes
and
really
implementation
specific.
So
then,
really
this
Gap
would
just
be
like
dropping
the
raw
and
then
including
websocket
and
thus
I.
Guess
it's
already
there
and
probably
dropping
that
like
the
raw
table
and
and
stuff
like
that,
just.
D
E
A
A
E
D
E
E
D
So
at
this
point,
if
I'm
understanding
correctly,
this
is
really
just
saying
that
thing
that
theme
is
already
defined
in
Upstream
kubernetes
is
something
that
you
know
is
is
supported
and
relevant
for
Gateway
API
and
then
maybe
the
most
notable
part
of
this
Gap
is
defining,
which
of
those
Protocols
are
supported
by
which
of
the
route
types
and
Service
Port
protocols.
Is
that
the
the
idea.
E
Yeah
and
given
that,
for
example,
let's
say
like
raw
raw
is
gone
now
from
Upstream,
but
if
that
makes
sense
for
gamma
to
be
able
to
configure,
don't
do
any
protocol
sniffing,
then
we
might
need
to
Define
additional
constants
to
this
Gap
that
are
not
kubernetes
constants,
but
just
like
a
Gateway
constants
yeah
that
could
be
like
an
addendum
in
the
future.
I'm
just
trying
to
figure
out
like
hey,
should
I
rewrite
rework
this
get,
because
if
it's
gonna,
if
you're,
okay.
A
I
think
that's
in
so
I
think
that's
important
to
acknowledge
like
what
do
we
expect
from
implementations
tourists
to
like
look
at,
and
you
know,
program
yeah,
like
so
I-
think
it's
definitely
a
good
it's
a
good
to
have
so
we
don't
like.
We
don't
have
implementations.
You
know
different
implementations,
doing
different
things,
yeah
I'm,
not
sure
about
the
get.
The
specific
constants
I
need
to
look
at.
Why
kubernetes
raw
was
rejected
and
then
to
see
whether
some
like
whether
something
is
also
applies
for
this.
B
E
D
D
Cool
yeah,
I,
I
kind
of
would
Echo
what
what
liar
says.
I
I
think
this
is
this.
This
makes
sense.
I
I
need
to
look
into
the
specifics
as
well,
but
the
idea
of
saying
hey
this
kubernetes
thing
that
is
already
defined
is
something
that
we
care
about
and
just
really
defining
the
interaction
between
our
API
and
this
field.
Make
sense
to
me
is
an
important
thing
to
to
cover.