►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20220912
Description
KCSNA 2022 Weekly Planning for 20220912
A
All
right
welcome
to
the
Gateway
API
meeting
for
September
12
2022.
looks
like
we've
got
a
fairly
full
agenda.
Thank
you
for
organizing
everything
and
Shane.
It
looks
like
you're
changing
things
as
we
go
appreciate
that
as
well
yeah,
let's,
let's
kick
it
off!
Nick
I!
Think
you're.
First,
in
line
about
the
contributor
Summit
cfp.
B
B
If
we
have
two
sessions
or
one
session
like
one
for
Gamma
One
for
our
main
project
or
if
we
just
do
one
combined
in
I
kind
of
feel
like
it
might
be
better
to
do
combine
since
we're
probably
all
going
to
go
to
both
of
them
anyway,
but
yeah
so
I
just
wanted
to
just
wanted
to
mention
that
and
say
hey.
We
should
coordinate
on
that
and
get
a
submission
before
the
30th
of
September
when
it
closes.
A
A
The
collaborative
session
there's
like
two
two
different
things
are
basically
the
same
thing.
Basically,
we
have
the
option
to
have
an
hour-ish
of
time
to
work
together.
Talk
about
anything
we
want
about
Gateway
API
in
person
at
the
contributor
Summit
out
of
curiosity.
Maybe
if
people
can
temporarily
raise
their
hands
here,
how
many
people
think
they'll
be
able
to
make
it
to
contributor
Summit
this
year
in
Detroit.
A
Cool
okay,
it
looks
like
there
will
be
at
least
seven
of
us
great.
That
is
great
to
see
and
if
more
can
make
it,
that's
even
better
but
looks
like
we'll
have
a
good
group
there,
all
right
next
on
the
list.
Well,
actually
before
I
go
any
further
I
think
the
question
was:
if
we
want
one
or
two
and
I'm
fine
with
just
a
single
collaborative
session,
for
everyone
is
that
good,
great
okay,
cool
and
next
up
I
think
Candace
you're
up
next.
C
E
B
Well,
I
think
the
you
it's
the
next.
The
next
step
is
to
actually
to
decide
on
like
what
we
want
to
do
and
right
and
build
out
some
structs
and
some
sample
code
and
and
stuff
like
that
and
fill
out
the
the.
What
like,
the
how
basically
I
think
my
preferred
option
was:
was
the
some
sort
of
you
know:
back-end
service
kind
of
resource
that
has
a
bunch
of
or
service
back-end
resource
that
scribe?
B
B
Is
the
naming
the
identity
so
I
think
that
some
sort
of
back-end
service
resource
would
be
really
good?
It
needs
to
just
have
some
spots.
To
put,
it
needs
to
have
like
a
spot
to
put
a
reference
to
probably
a
service
as
as
a
back
end
as
a
collection
of
endpoints
and
the,
and
then
you
know
it's
supposed
to
put
the
other
config,
but
that's
pretty
much.
All
I
really
thought
so.
The
next
steps
are
for
somebody
to
do
that.
A
Yeah
I
agree
with
that
I.
You
know
we're
we're
very
much
so
far
have
been
focused
on
MVPs
for
things,
including
gaps
here
where
this
is
I,
get
with
goals
non-goals,
but
not
actually
the
implementation
details,
and
so,
as
you're
saying
the
The
Next
Step
would
be
to
actually
fill
out
implementation
details.
A
F
Yeah
I've
I've
got
a
use
case
for
this,
with
osm,
where
we
we
support.
Plugable
Ingress
and
the
osm
control
plane
creates
a
certificate
that
for
for
all
and
Envoy
parlance
Upstream,
but
I
get
for
all
cluster
traffic
that
the
Ingress
controller
brings
in,
and
so
this
is,
as
we
try
to
adopt,
Gateway
API,
something
for
TLS
would
be,
would
be
super
useful.
Even
if
that's
all
this
resource
does
so
I'm.
You
know
there's
comments
in
the
chat
about
experimental
being
good.
F
B
Yeah
so
I
agree
that
the
the
I
think
the
experimental
is
the
right
place,
for
it
is
literally
experimental
at
that
point,
but
like
I,
don't
whatever
we
do,
we
have
to
do
something
to
handle
the
case
of
your
gateway
is
implemented
using
proxy
and
you
need
to
have
the
TLs
details
to
connect
to
the
back-end
service
right,
like
the
end,
so
having
another
resource
that
does
that
and
then
that
resource
is
also
a
place
for
other
things
about
that
service
would
be
very
useful
right.
The
other.
G
B
Other
thing
that
the
other
two
things
that
I
thought
of
when
I
was
writing.
This
are
load
balancing
backend
for
endpoint
load,
balancing
algorithm
endpoints
as
opposed
to
load
balancing
back
in
for
routes.
We
have
a
spot
to
put
the
load
balancing
back
in
for
routes,
but
not
a
spot
to
put
the
load
balancing
the
load,
balancing
algorithm
for
choosing
amongst
endpoints.
Once
you
have
a
route
chosen.
B
B
Properties
that
will
fit
into
that
into
that
bucket,
and
so
that's
why
I'm,
okay
with
doing
it
just
with
TLS
to
start
with,
and
then
we
add
other
properties
as
we
go,
what
I'm
trying?
What
would
but,
in
my
mind,
what
we're
trying
to
do
here
is
to
create
a
space
in
the
API
for
that
information
to
live,
and
then
currently
there
is
nowhere.
We
create
a
resource,
we
put
it
in
there.
You
ideally
we're
like.
Oh,
this
is
really
good.
B
A
That
that
makes
sense
to
me,
I
I,
think
that's
a
reasonable
starting
point
just
to
to
recap:
I
think
what
we're
saying
is
we're,
okay
with
taking
this
Gap
as
it
sits
today
and
providing
you
know.
The
next
step
is
to
provide
a
proposal
for
implementation
details
of
a
new
resource
that
is
generic
enough,
a
name
that
can
support
more
than
TLs
re-encrypt,
but
that
all
the
initial
scope
of
it
will
be
will
be
TLS,
re-encrypt
or
config
configuration
for
a
service
and
I
think
Candace.
E
B
A
E
C
C
I
think
we'll
need
to
allow,
at
the
very
least,
Port
specific
policies
like,
for
example,
you
probably
don't
want
to
encrypt
Port
80,
but
you
probably
do
want
to
incorp
Port
443
right,
but
even
beyond
that,
we
may
even
need
Source,
aware
back-end
property
selection,
so,
for
example,
I
may
have
a
route
that
matches
on
the
grpc
service
and
I.
Don't
know
HTTP
Readiness
server
right
for
one
of
those
I
need
to
use.
Http
2
for
the
other
one
I
may
need
to
not
use
HTTP
too,
so
it
I.
A
Yeah
I
completely
agree,
I
think
Nick
very
intentionally
used
back
end
in
the
Gap
name
and
then
I
I
think
when
I
was
describing
it
I
use
service,
but
I
think
back.
End
is
very
intentionally
not
service
in
this.
In
this
context,
specifically
calling
out
port
and
then
Source
aware,
would
be
good,
I,
don't
know
if
that's
covered
in
the
Gap.
C
Oh
I
was
just
going
to
comment
that
it's
funny
that
kubernetes
kind
of
merged
service
together
with
different
ports
because
of
naming
reasons
like
in
terms
of
DNS,
but
they
are
technically
two
different
Services
if
you're
running,
HTTP
and
HBS.
Unfortunately,
we
just
have
to
carry
that
forward
in
our
whatever
we
design,
because
that's
kind
of
the
choice
yeah.
C
A
D
D
Let
people
know
that
the
intention
will
be
to
kind
of
do
that
more
and
start
getting
to
the
point
where
in
the
future
you
know
we
are
doing
kind
of
wholesale
planning
of
how
we
actually
lay
out
our
releases
and
hopefully,
by
proxy
doing
quicker,
smaller,
potentially
releases
we'll
see
but
yeah
just
you'll
probably
see
me
moving
a
bunch
of
stuff
and
it
then
perhaps
Nick
and
Rob
will
be
asynchronously
moving
them
back
we'll
find
out.
But
that's
that's
kind
of
the
the
idea
right
now.
A
So
there
is
that
other
Milestone
just
sitting
there
yeah
just
trying
to
make
more
sense
of
Milestones
going
forward,
and
if
you
see
things
that
you
feel
like
belong
in
060
or
051
ping,
any
maintainer
just
post
it
on
slack
and
we'll
we'll
notice,
but
we
want
to
make
Milestones
meaningful
and
help
help
them
prioritize.
Our
work.
D
Discussed
this
in
gamma,
twice
I
think
and
I
I
just
wanted
to
throw
it
out
to
this
Creator
I
think
I
was
asked
like
there
was
a
suggestion
from
the
group
to
kind
of
bring
it
back
to
this
group
and
kind
of
suggest.
You
know
when
you
have
something
that's
experimental.
You
have
something
that
is
maybe
in
the
middle
of
a
gap,
but
you
don't.
You
want
to
be
able
to
do
some
like
prototyping,
some
proof
of
concept
and
stuff
like
that.
What
would
we
say,
I
guess
what
are
the
opinions
on
what?
A
This
is
a
good
question
Maybe
and
to
understand
it
more.
Are
we
talking
about?
You
know
basically
adding
provisional
features.
You
know,
you
know
you
have
a
an
existing
mesh
implementation,
let's
say,
and
you
want
to
just
test
out
proof
of
concept.
A
new
potentially
new,
Gateway
API
feature
to
see.
If
it
even
makes
sense,
are
you
talking
about
a
built
from
scratch,
implementation
to
POC
some
feature.
D
Yeah
kind
of
the
second
one,
so
the
the
basic
idea
was
well
I,
guess,
historically
experimental
and
not
that
it's
been
around
that
long.
But
the
idea
with
experimental
right
now
would
appear
to
be
that,
even
though
it's
experimental
it
requires
kind
of
consensus
built
on
the
cap
and
everybody's
kind
of
behind
it.
Should
there
can
there
be
a
place
where
somebody
can
I
mean
other
than
creating
a
separate
repo,
which
is
the
obvious
backup
right.
D
D
Can
we
have
that
I
think
the
obvious
implication
is
to
make
it
very
easy
if
somebody
during
the
gamma
processes
is
wants
to
kind
of
like
kick
up
some
proof
of
concepts
for
like
setting
up,
for
instance,
I,
don't
know
just
having
like
a
mesh
POC
that
has
like
the
actual
mesh
API
type,
but
you
don't
want
to
commit
that
into
the
API
itself.
Even
if
it's
experimental
right
does
that
make
sense.
B
Like
it
feels
to
me,
like
the
only
reason
to
that,
we
would
need
to
have
like
a
blessed
shared
way
of
doing.
That
is
if
we
want
people
to
be
able
to
do
that
and
collaborate
on
it.
Otherwise,
like
a
fork
of
the
repo,
is
fine
right
because
and
if
you're,
if
you're
doing
a
book
to
be
like
this,
is
what
this
is,
what
I
think
we
should
do,
then
you
know
putting
people
like
to
a
branch
on
your
own
fork
or
something
like
that
is
fine.
B
You
know
like
in
fact
I
would
I
would
argue.
That
would
be
the
right
way
to
do.
It
is
to
create
a
web
PR
and
have
the
you
and
have
the
pr,
the
Whit
PR
sort
of
have
all
the
details
in
it.
And
then
you
say:
if
you
want
to
try
this
out,
you
pull
the
pr
and
you
pull
the
whip
branch,
and
you
know
and
compile
it
yourself.
B
The
like
I
guess,
I
think
that
most
of
the
stuff
that
we
have
done
to
this
point
has
has
sort
of
worked
like
that,
and
it
feels
like
having
anything
more
than
that
like.
We
really
need
to
be
really
careful
that
we're
not
running
running
that
we're
not
accidentally
blessing
things
as
the
way
when
when
then
not
yet,
and
that
that's.
Why
I
think
we
have
the
sort
of
the
rough
thing
that
you've
mentioned
there
about
experimental
requiring
some
consensus.
B
Experimental
is
currently
about
about
hey
this
that
we,
the
community,
has
agreed
on
this,
but
but
we
haven't,
got
it
conformance,
tested
and
implemented
enough,
yet
to
be
confident
that
it's
the
way
that
we
want
to
keep
the
API
it
is
the
equivalent
of
API
server
feature
flag.
You
know
you
can
flip
it
to
true.
C
D
C
D
F
Yeah
I
think
that,
with
with
gamma
one
of
the
things
that
we're
running
into
is,
you
know
we're
at
such
an
early
stage
and
we're
trying
to
continue
to
maintain
your
forward
momentum.
While
we
don't
really
know
what
the
exact
Adventure
book-
and
you
know,
there
are
different
kind
of
dependent
streams
of
potential
work,
we
want
to
investigate
we're
trying
to
figure
out
the
best
way
to
go
about
doing
that.
F
I
I,
honestly,
the
the
fork
idea.
The
process
sounds
perfectly
reasonable
to
me.
If
what
we
need
is,
if
you
believe
in
this
approach,
then
start
a
fork,
a
Gateway
API
get
some
code
in
there
and
maybe
play
with
your
implementation.
Maybe
demo
it
possibly
somebody
else
if
they
lock
that
approach
as
well,
they
can
demo
with
their
implementation
and
kind
of
just
see
how
that
works.
They
could
be
comments
in
the
pr.
This
request
doesn't
work.
We
could
pull
out
the
discussions.
F
F
D
B
C
D
B
Implementation
on
my
on
this
branch
in
my
book
and
that's
fair,
merging
things
into
merging
things
into
Maine
on
the
Main
and
Gateway
API
repo
does
carry
an
mature
of
this
is
part
of
the
spec,
because
that
main
on
the
repo
is
the
spec.
Regardless
of
whether
or
not
it's
you
know.
Technically,
we've
said
in
the
in
the
experiment
in
the
versioning
that
the
that
the
spec
is
like
released
on
a
in
a
release.
B
A
A
I
largely
consider
it
very
close
to
Alpha.
If
you
look
at
Upstream
kubernetes,
there
are
alpha
feature:
Gates
I,
consider
experimental
Fields
very
similar
to
that.
In
that
you
need
to
go
through
the
cap
process,
you
need
to
get
consensus
that
this
made
sense.
You
needed
to
have,
you
know,
go
through
the
full
review.
Go
through,
you
know,
I.
A
The
thing
I'm
worried
about
here
is:
if
we
make
experimental
too
experimental,
we're
going
to
lose
users,
and
we
really
need
experimental
people
to
be
testing
in
the
experimental
Channel
if
we
ever
want
something
to
graduate
from
experimental
to
standard
and
so
experimental
needs
to
be
at
least
somewhat
stable.
I
know
we
can
remove
things
we
can,
but
we
need
to
have
some
level
of
stability
there
that
somebody
can
say:
hey
I'm,
going
to
use
this
and
test
it
out
and
see
how
it
works.
A
F
D
F
Ahead,
I
was
just
gonna
say
if
I
go
back
to,
you
know,
think
about
continuous
deployment
and
continue
to
liberate.
You
know
main
is
what's
in
production,
and
so,
if
you
follow,
if
you
take
that
principle
towards
like
API
versioning,
like
we're
doing
with
Gateway
API
I
agree
with
what's
been
said
in
the
sense
that
main
carries
some
definitely
has
some
semantic
meaning
there.
D
Yeah,
but
what's
been
said,
I
think
is
good.
I
personally
feel
perfectly
satisfied
with
just
having
talked
about
it
and
it's
as
simple
as
it
might
have.
You
know
it's
it's
a
it's
a
simple
answer,
so
unless
anybody
really
wants
to
dig
into
that
further
I'm,
okay,
with
let's
consider
experimental,
not
actually
experimental,
in
maybe
the
linguistic
sense
and
move
on
and
then
the
last
one
I
had
I.
Actually
don't
think
I
have
an
action
item
for
this,
but
I
did
want
to
mention.
There
has
been
interest
in
the
gamma
meeting.
D
Sorry
I
think
I'm
just
going
to
continue
to
track
this,
but
there
are
people
that
are
saying
that
they
would
be
they
would
want
to
show
up
for
the
Gateway
meeting.
Were
it
were
there
an
earlier
one
I
think
I'm
gonna
talk
about
this
one
more
time
at
Gamma,
but
I
found
at
least
a
couple:
people
who
aren't
coming
to
any
of
the
meetings
who
are
European
time
zones,
Poland
and
so
forth.
D
That
would
like
to
come,
but
it's
prohibitive
and
then
the
gamma
meeting
has
at
least
a
couple
of
people
that
are
attending
that
one
and
would
most
likely
attend
to
this
one.
They
said
if
the
there
was
at
least
a
one
earlier,
less
prohibitive
time,
so
just
kind
of
a
heads
up
that
that's
still
a
thing
and
there
are
still
people
I,
think
that
we
might
gain
by
by
doing
that,
I'm
going
to
continue
to
follow
up
on
that
thread.
Unless
anybody
today
really
wants
to
push
for
a
specific
action
item.
A
D
A
No
great
points:
yeah
I
I
encourage
people
to
keep
on
following
up
with
meeting
times.
I
I
wish
everyone
was
in
the
same
time
zone
and
we
could
all
just
make
it
to
the
same
same
meeting
globally,
but
hopefully
we
can
find
sometimes
that
work
well
for
as
many
people
as
possible,
I
know,
anytime,
we
switch
to
a
different
time
zone.
We're
gonna
lose
some
people,
but
hopefully,
if
we
choose
to
do
that,
we
will
gain
more
but
yeah.
Obviously,
that's
really
just.
A
B
A
A
So
it's
not
completely
unprecedented,
but
I
think
this
was.
If
I
remember
this.
One
I
think
this
one
had
a
bit
more
yeah
a
bit
more
clear
use
of
it.
Anyways
yeah
does
any
anyone
feel
comfortable
volunteering
for
this
I
agree
that
we
need.
We
need
to
document
this
somewhere.
Does
anyone
want
to
just
kind
of
maybe
copy
a
reference
from
what
the
policy
is
in
Upstream.
B
B
Yeah
so
I'm
happy
to
oh,
it
looks
like
ages.
Other
people
commented
on
it,
but
I
haven't
had
a
chance
to
look
at
yet
so
I'm
probably
happy
to
to
leave
this
one
until
next
week.
If
we
want
there's
a
lot
to
talk
about,
if
people
want
me
to
sort
of
talk
about
the
the
general
strategy,
I've
gone
with
here
a
little
bit
here,
but
I
kind
of
want
to
be
careful
to
time
box
this
one,
because
this
one
could
drag
out
I
think
so.
B
Yeah
I
mean
so,
if
you
could
just
pull
up
the
the
top
of
the
file
I
think
I've
tried
to
summarize
it
pretty
well
in
the
the
thing,
but
so
basically
status
is
really
inconsistent
across
all
the
different
resources.
This
is
an
attempt
to
make
the
status
consistent.
I
specifically
did
some
stuff
that
I
knew
like
basically
after
I
started.
B
Looking
at
this
for
a
while,
I
was
like
we're
going
to
have
to
make
some
some
breaking
changes
to
some
changes
to
status
that
will
break
conformance
because
we
use
the
status
in
conformance,
so
I
was
like
well.
If
we're
going
to
break
conformance,
we
should
break
it
all
break
it
once
break
it
properly
and
fix
it
up,
so
that
you
know
so
that
we
only
have
to
do
this
once
so.
B
That's
why
you
know
some
of
the
proposals
here
are
pretty
big
changes,
because
I'm
like
well
I'm,
gonna,
design,
the
dream
and
then
we'll
figure
out.
If
we
can,
if
we
can
make
the
Dream
Work
rather
than
trying
to
design
what
you
know,
trying
to
take,
what
we
have
and
like
incrementally
change
it
I'm
going
to
be
like
this
is
the
this
is
my
wish
list
for
how
I
how
I
would
like
status
to
look.
B
B
For
Gary
class,
because
it's
the
top
of
the
train
go
API,
resources
are
a
tree,
and
so
you
know
that's
what
I
the
first
thing
I'm
proposing
is
that
we
take
all
of
the
resources
that
mean
this
is
accepted
for
processing.
Some
of
them
are
accepted.
Listeners
have,
you
know,
detached,
which
is
even
worse
because
of
the
opposite,
polarity
to
everything
else,
and
so
to
just
make
them
all
say
attached
and
that
way
when
we're
talking
about
when
things
have
been
accepted
for
processing,
we.
G
B
B
B
But
then
there
are
a
bunch
of
specific
error
conditions
like
memory
pressure,
disc
pressure
network
is
down
that
are
that,
if
some,
that
specific
thing
goes
wrong,
they
flip
to
true,
but
in
the
in
the
in
the
happy
case,
network
is
down
false
disk
pressure.
False
memory
pressure
false,
and
so
you
I
think
that
the
argument
was
made
to
me
a
couple
times
that
hey
you
know,
being
able
to
having
things
say.
B
Some
are
negative,
but
having
all
of
one
means
that
it's
much
easier
for
machine
consumption
of
the
conditions,
the
last
the
last
change,
that's
a
bit
big,
is
that
all
relevant
conditions
for
a
resource
must
be
added
at
the
first
time
it's
observed,
so
HTTP
routes
must
always
have
accepted
ready
if
we
have
it
and
resolved
refs,
regardless
of
their
state.
So
if
you
don't
know
if
the
result
refs
are
done
yet,
then
it's
unknown.
B
The
the
reason
there
is
that
it
means
that
it's
really
easy
to
accidentally
use
conditions
as
like.
It's
only
present
when
it's
one
of
the
states-
and
that
means
that
then
you
have
to
have
a
complicated
logic
about
when
you're
consuming
them.
You
have
to
have
complicated
logic
about.
If
it's
not
present,
then
what
does
it
mean?
You
know.
What
does
that
mean?
Does
that
mean
that
it's
good
or
bad
in
you
and
strictly
by
the
API
conventions?
B
B
B
B
You
know,
but
I
think
that
if
we
can
do
all
of
these
things,
it'll
really
set
us
up
well
for
having
a
very
clear
set
of
rules
for
status
as
we
make
more
resources
which
we
will
be
guaranteed
and
also
we
can
give
people
clear
status
guidance
for
when
they
create
their
own
resources
like
policy
and
reference
Grant.
So.
G
B
Now,
reference
Grant
has
no
status.
So
that
means
that
if
you
create
a
reference,
Grant
there's
no
way
to
know
if
it's
doing
anything
and
the
same
for
policy
resources,
you
know
there
needs
to
be
at
least
an
accepted
or
attached
condition
on
them
to
say
this
is
you
know
this?
This
resource
is
syntactically
and
semantically
valid
okay,
I've.
A
B
I
mean,
ideally,
we
get
it
in
060.
I
know,
that's
a
big
ask,
but
the
the
later
we
leave
these
breaking
changes,
the
more
painful
it's
going
to
be.
The
more
implementers
are
going
to
have
implemented.
What
already
exists
to
do,
the
conformance,
the
more
the
more
Implement
a
pain
we
are
going
to
cause
by
breaking
and
I.
Don't
think
it's
I.
A
B
B
When
we
update
the
conformance
tests
that
everyone
will
have
to
do
things
to
make
to
stay
conformed,
so
we
can,
we
can
add
the
new
conditions
in
as
like
recommended
things
that
aren't
tested
in
the
conformance,
but
like
that's
that's
also.
That
means
that
then
the
conformance
break.
We
just
push
the
conformance
break.
One
version
in
the
future,
like
you
know
it's
like:
when
do
you
write
the
performance?
Will
you've
got
to
do
it
sometime.
A
Yeah
that
makes
sense
to
me:
okay.
Well,
there's
a
lot
to
go
through
on
this
I
know:
we've
already
gotten
some
good
comments,
but
this
is
PR
1383
highly
recommend
you
take
some
time
to
review
it
in
the
next
few
days
because
we
are
trying
to
move
at
a
pretty
quick
timeline.
Here.
Looks
like
Keith.
You've
got
a
hand,
is.
F
A
But
our
releases
take
a
while
because
not
only
do
we
have
to
review
approve
releases,
we
have
to
get
Sig
Network
API
reviewers
to
approve
them
that
takes
a
period
of
time,
usually
there's
some
feedback
in
there
so
we'll
see.
But
realistically
we
need
to
have
everything
ready
no
later
than
a
month
from
now.
B
A
B
I
am
planning
on
spending
like
half
my
time
for
like
until
keep
going
on,
making
sure
this
happens,
but
yeah.
This
is
not
a
one-man
lift.
It's
like
you
know
you
gotta.
You
know
we
all
gotta
pitch
in
a
bit
here.
So
please,
you
know
I
just
wanted
to
say
hey.
We
all
need
to
focus
a
bit
on
like
trying
to
pick
up
some
things
and
get
them
done.
B
There's
a
bunch
of
there
is
a
bunch
of
small
good
first
issues,
style
issues
in
there
that
I,
like
just
we
just
need
documentation,
updates
there'll,
probably
be
some
more
after
today's
meeting.
Please
feel
free
if
you're
watching
this
recorded.
If
there
are
good
first
issues
left
in
the
Milestone.
Those
are
your
first
go-to.
Please
find
them
and
and
push
your
hand
out
to
do
them
because
yeah
we
desperately
need
to
get
this
release
out
and
there's
a
lot
of
work
to
do.
A
Yeah
completely
agree
thanks
for
calling
that
out,
maybe
at
the
start
of
the
next
meeting
we
can
spend
some
time
walking
through
the
milestone
and
making
sure
that
everyone
all
the
issues
are
assigned
and
if,
if
you
want
to
get
ahead
of
that
and
assign
yourself
to
them
to
an
issue
in
a
milestone,
that's
even
better
Danny
and
I
think
you've
got
a
couple
issues
here:
compatible
listeners
across
gateways.
Maybe
you
can
give
a
bit
of
or
yeah
you're
here.
G
Yeah
trying
to
decipher
the
spec
for
collapsing
compatible
listeners
across
gateways,
respect
those
Provide
support
for
that
and
I
try
to
capture
those
details
here
and
what
I,
what
I
interpret
from
that
is
is,
as
you
see
here,
is
that,
for
you
know,
each
listener
protocol
must
be
the
same,
so
HTTP,
for
example,
but
host
names
must
be
unique
and
the
spec
goes
on
to
provide
a
little
more
detail
there.
But
when
I
look
at
the
conformance
tests,
they
are
not
consistent
with
that.
G
A
That's
right:
yeah,
okay,
I,
see
the
confusion
here.
I
think
how
this
was
intended
to
read
in
the
spec
was
that
you
may
choose
to
merge
gateways
if
listeners
across
gateways
if
they
are
clearly
different
and
in
the
case
of
the
conformance
test
he
he
you
referenced
here.
I,
don't
think
these
could
be
merged
and
someone
correct
me
if
I'm
wrong,
but
I
think
what
you're
you're
saying
here
is.
These
are
basically
the
same
thing.
G
That's
why
the
issue
I
I
kind
of
call
out
either
we,
you
know
the
I
feel
like
the
the
spec
either
needs
to
be
updated
or
something
needs
to
be
done
with
the
conformance
test.
Because
right
we
see
that
the
spec
allows
the
collapsing
of
listeners
across
gateways,
but
this
particular
setup
for
conformance
tests
does
not
support
that
right
and
so
I
don't
know.
If
we
had
a
new
flag
that
points
to
a
different.
You
know
set
of
manifests
that
allow
the
collapsing,
because
this
doesn't
allow
that.
B
E
B
Like
if
you,
if
you
think
about
this,
like
the
so
I
think
the
things
are,
is
that
you
either
need
to
consider
a
loud
routes,
part
of
the
thing
that
makes
the
listeners
distinct
or
you
don't.
And
if
you
don't,
then
it
means
that,
like
the
the
part
where
you're,
generating
like
figuring
out
what
listeners
attached
to
the
to
the
Gateway
is
kind
of
separate
to
generating
the
con,
the
underlying
config,
so
I
cut
the
way
I
kind
of
anticipated.
B
G
I
mean
it's
just
I,
looked
at
this
right
and
we're
basically
saying
that
this
configuration
of
three
gateways
that
all
have
the
same
port
and
the
same
hostname
are
incompatible.
So
so
there's
no
way
for
you
know
the
envoy
Gateway
the
project
that
I'm
trying
to
get
conformant
here
to
run
these
these
conformance
tests,
because
these
three
gateways
from
a
multi-gateway
listener
collapsing
standpoint,
they're
they're
not
compatible,
so
Envoy
Gateway
is
not
going
to
be
able
to
collapse.
These
three
gateways-
Gateway,
listen,
I,
think.
A
G
But
if
the
spec
says
that
you
may
be
able
to
do
this,
but
there's
no
way
to
have
an
implementation,
run
Conformity
you're
right
it
just
it's
just
it's
a
it's
a
difficult
situation
for
implementers,
because
I
like
myself,
read
this
and
say:
okay
well
may
seems
like
we
can
do
this
and
for
for
Right
Reasons
right
is.
We
want
to
try
to
optimize
the
infrastructure
instead
of
creating
a
an
individual
Envoy
proxy
for
each
Gateway?
It's
like
okay!
G
Well,
if
we
have
distinct
listeners
right,
if
we
were
following
the
spec
here,
then
we
should
be
able
to
collapse
these
listeners
across
gateways.
But
by
doing
that,
there's
no
way
we
can
run
the
conformance
tests,
and
so
if
we
want
to
keep
the
spec,
as
is
we
can
find
having
some
type
of
flexibility
in
the
conformance
tests
that
maybe
you
supply
the
conformance
Tesla
flag.
That
says
you
know,
collapse,
Gateway
listeners
version
or
something
like
that
right,
some
kind
of
flag.
That
would
then
run.
C
Yes,
I
tried
to
press
the
record
button
instead
of
the
mic
button
which
didn't
work
very
well.
So
I
think
this
came
up
in
another
discussion.
I
had
with
someone
else
where,
like
apparently
the
prescribed
means
of
handling
a
conformance
test
that
tests
something
that's
optional
but
that
you
do
not
Implement
is
basically
just
you
don't
run
that
conformance
test,
which
is
I,
guess
it'll
work,
but
it's
kind
of
very
limited,
so
I
think
to
the
prior
point
is
like
we
do.
C
We're
saying
that
we
want
to
skip
the
conformance
test,
but
really
if
this
is
a
this
is
the
bread
and
butter
of
Gateway
and
your
implementation
can't
support
it.
Then
the
implementation
needs
to
be
fixed
and
you
should
not
try
to
collapse
these
well.
Sorry,
we
all
have
our
hands.
At
the
same
time,
I
would
like
to
understand
where
the
conformance
test
breaks
down,
because
the
result
of
collapsing
I
think
is
that
you
end
up
having
like
the
same
address
or
or
some
shared
resource,
where
these
two
things
are.
G
For
my
implementation,
it
breaks
at
creating
the
gateways
right,
so
it
breaks
the
controller,
so
everyone
can
call
our
view
that
I'm
getting
a
turn
back
from
or
feedback
somebody's
got
crazy
feedback,
but
anyways
I
mean
it
breaks
at
the
Gateway
creation
stage
right.
So
the
controller
is
reconciling
these
gateways
and
saying
wait.
A
second
all
three
of
these
are
are
invalid
because
they
conflict
with
each
other.
B
It
feels
to
me,
like
the
problem
here,
comes
down
to
the
fact
that
the
the
way
that
we
have
left
what
constitutes
a
conflicting
listener
to
like
you
know
so.
The
the
problem
here
is
that
the
the
the
as
you've
read
the
Specter
say
that
that
a
non-conflicting
listener
has
a
separate
can't
have
the
same
hostname
across
just
the
listeners,
just
the
listener
resources.
It
needs
to
be
distinct
across
protocol
and
hostname
I.
B
G
A
Yeah
I
think
this
is
a
great
conversation,
but
I
want
to
I
know
some
people
have
to
drop
here,
so
I
I
want
to
be
kind
of
that.
This
is
a
good
issue
to
follow
up
on
I
think
we
all
have
comments
and
there's
lots
of
discussion
to
to
follow
up
here.
So
13.85,
please
come
back
to
this
one,
and
maybe
if
we
can
take
any
follow-up
comments
and
put
it
on
this
issue,
I
think
it
will
be
helpful
for
anyone
coming
back
to
this
in
the
future.
Oh
yeah
I.