►
From YouTube: SIG Network Service APIs Office Hours 20200805
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
For
those
of
you
that
have
been
keeping
track
not
that
long
ago,
I
said,
maybe
not
particularly
wisely
that
it'd
be
really
cool
to
get
a
v1
alpha,
1
release
out
in
august,
we
got
at
least
one
thing
moved
from
in
progress
to
completed
in
the
past
week
and
progress
on
a
couple
other
things
at
least
I
probably
at
least
three
of
these
areas
have
seen
progress
since
last
week.
I
know
harry
you've
been
working
on
tls
config
yeah.
How
are
things
going
there?
Can
you
do
you
need
any
help?
C
B
B
I
have,
I
have
cobbled
together
something,
but
I've
still
still
to
polish
it.
So
I
have
some
time
tomorrow
and
friday.
So
by
the
end
of
this,
I
plan
to
have
at
least
couple
of
pr's
to
cover
like
70
percent
of
that
proposal,
and
then
there
are
a
couple
of
controversial
parts
that
you
know
will
follow
up
later
on.
B
D
A
Completely
agree
there
I
think
bowie
about
service
level
config,
I
think
he'll,
be,
I
think,
he'll
be
on
this
meeting
in
a
bit.
So
maybe
I'll
follow
up
later
on
with
that,
I,
as
far
as
I
know,
that's
still
making
progress.
I'm
just
I
haven't
haven't
gotten
an
update
recently
conflict
handling
semantics.
I
apologize
because
I
just
keep
on
taking
up
whatever
time
is
left
at
meeting
in
meetings
with
whatever
questions
I
have
around
conflict
handling,
so
progress
is
going
there.
A
I,
I
think
you
know,
for
a
lot
of
the
conflict,
handling
I'm
starting
to
get
into
into
the
weeds
and
things
that
we
may
not
need
an
answer
to
right
away,
but
I
think
I
may
have
enough
or
close
to
enough
where
I
can
get
some
of
the
high
level
stuff
in
place
and
actually
documented
and
and
better
better
defined
in
the
api,
and
this
is
this
has
also
led
to
some
larger
discussions
that
are
related,
but
but
different.
A
You
know
as
an
example
gateway
class
in
its
place
in
this
yeah
so
anyway,
but
that
that
is
progressing
if
anyone
wants
to
help.
If
anyone
has
questions
around
conflict
handling
or
things
that
they
would
like
to
add
or
have
covered,
I
am
very,
very
open
to
collaborating
with
people
or
just
getting
feedback
whatever
it
is,
and
the
last
one
I
I
I
think
we'd
asked
damian
to
try
and
take
on
some
some
work
on
status
and
conditions,
because
is
that
still
reasonable
for
you
damian.
F
I
guess
I'm
caught
I'm
kind
of
in
the
middle
okay,
I'm
starting
to
spend
some
time
looking
into
the
implementation
of
service
apis,
and
I
would
like
to
be
able
to
focus
in
on
that
along
with
kind
of
my
normal
day-to-day
responsibilities.
F
So,
if
it's
possible,
someone
else
can
pick
this
up,
I
that
would
be
great.
If
not,
then
then
it's
something
I'll
take
on
cool.
D
I
can
sync
with
that
danny
I
can
sit
with
daddy
and
do
it
I'd
like
to
get
an
idea
of
what
daniel
I
I'll
talk
to
daniel
offline
about
it.
Okay,.
A
A
A
A
Okay,
yeah
we'll
definitely
keep
on
thinking
about
this.
If
there
are
things
we
don't
have
on
our
list
on
on
our
roadmap
that
we
need
to
get
in
before
v1
alpha
1.
it'd
be
great
to
know,
but
at
this
point
maybe
I'm
a
little
too
optimistic,
but
it
does
all
of
these
things
at
least
feel
like
they're
they're
doable
in
sometime
in
august,
we'll
see
cool
all
right.
So,
let's
move
on
to
some
pr
issues.
A
Actually,
this
is
100
pr
triage
today,
no
new
issues
that
I
noticed
at
least
feel
free
to
correct
me.
If
I'm
wrong
james.
I
I
added
one
comment
just
earlier
well
probably
early
morning
for
you,
based
on
your
time
zone
but
early
afternoon,
for
me
a
few
hours
ago,
one
of
the
things.
I
noticed
it's
great,
that
you
took
this
one
on
you,
you
added
some
better
validation
hooks
here,
I'm
not
seeing
this.
This
should
translate
to
crd
yaml
right.
Oh.
D
Yeah,
the
thing
is
that
it
moved
so
it
moves
when
you,
if
you
move
the
the
validation
from
the
field
up
to
a
type
okay.
The
crd
gen
lowers
that
back
to
the
field
when
it
generates
the.
C
D
Api
spec,
so
it
ends
up
being
a
no-op
okay.
What
happens
you
can
see
the
difference?
If
you
have
the
validation
in
two
in
two
places
like
on
the
type
and
on
the
field,
then
it
will
generate,
it
will
generate
open
api.
Spec
that
looks
like
it
means
apply
both
of
these
kinds
of
validations,
and
it
will
be
because.
D
D
Perfect
it'll
be
so
I
mean
it'd
be
kind
of
nicer
if
they,
if
I
pulled
my
finger
out
and
got
the
api
and.
A
Yeah
reasonable
enough,
at
least
it's
at
least
it
is
well
defined
and
and
close
close
together
like
this,
this
would
be
a
lot
harder
to
maintain.
If,
like
you
were
saying,
this
validation
annotation
was
on
the
type,
and
this
had
to
be
here.
You
know
like
if
these
were
two
different
places.
I
think
that
would
get
a
lot
more
painful
to
maintain,
but
the
way
you've
done
it
here,
I
think,
is
great.
D
One
so
there's
one
weird
thing
with
it
which
people
want
to
know
in
the
forward
two.
So
there's
two
other
things
that
I
smuggled
in
this
change.
The
header
match
type
in
the
hp
route
is
no
longer
a
pointer
because
it's
not
so
yeah
right
at
the
bottom
of
your
screen,
scroll
down,
yep
there.
It
is
so
because
we
have
a
default.
D
Even
if
you
omit
the
field,
the
api
server
defaults.
It.
A
Yeah
this,
you
know,
I
think
the
the
guidance
is
if
there
is
no
no
significant
difference
between
empty
string
and
nil,
then
you
don't
need
to
use
a
pointer
type
and
in
this
case
empty
string
is
not
really
particularly
meaningful
here
so
yeah
I
this
this
seems
like
a
reasonable
change
as
well.
D
D
Yeah,
that
was
that's
the
corner
case
that
I
was
thinking
about,
but
I
convinced
myself
that
the
extension
ref
applies
to
how
you
forward,
not
necessarily
that
you
have
to
forward
all
right.
Yes,
that's
right!
Oh
wait.
A
D
Oh
okay,
I
said
oh,
I
just
rebased,
so
he
must
have
merged
it.
Yeah.
B
So
question
regarding
header:
match
type:
does
it
so
this
is
going
to
be
a
little
confusing.
If
somebody
is
not
using
a
header
match,
we
have
a
default
of
exact,
so
somebody
would
have
like
a
path,
a
path
type
match
and
somebody
would
have
a
header
match
type,
but
they
won't
have
a
headers
to
match
on.
E
I
think
that's
why
we
had
the
pointed
it
at
the
first
place.
A
So
what
I
mean
the
pointer
I
mean
it
feels
like
we
probably
just
don't
want
a
default
value
here
at
all,
does
does
that
make
sense.
D
A
C
A
Yeah,
I
think
that's
going
to
make
more
sense.
We
may
want
to
clarify
you
know
this
line
here
default
exact.
Maybe
it
should
be.
If
unspecified
default
is
the
city
I
don't
know
or
or
maybe
we
do
need
to
require
it
to
be
specified
if,
if
you're
using
headers,
you
also
need
to
specify
a
match
type,
I'm
not
sure.
A
A
I
would
lean
away
from
an
I
would.
I
would
lean
away
from
a
default
here,
because
what
harry
said
makes
all
the
sense
in
the
world,
and
you
know
we
don't
want
to
have
a
header
match
type.
If
we
don't
have
any
headers
specified,
that's
confusing.
A
A
F
D
A
I
I
would
rather,
if,
if
we
want
our
default
to
be
none,
then
you
could
spell
that
out.
So
it's
clear
that
default
is
none,
so
there's
no
header
matching
going
on
or
I
I
don't
know.
D
So
I
think
that
line
of
reasoning
takes
you
to
adding
a
struct
to
collect
the
path
match
and
the
type
and
the
path.
D
B
A
Yeah,
unfortunately,
not
I,
I
do
think
that
potentially
the
better
way
to
solve
this
is,
with
those
embedded
straw,
those
extra
structs
that
extra
level
of
nesting
but
but
agree
that
this
is
not
the
pr
to
solve
that.
At
least
I
I
don't
think
so
like
this.
This
vr
is
pretty
reasonably
scoped
towards
fixing
validation
rules,
so
I
would
either
move
away
from
changes
here
or
just
keep
changes
minimal
and
file
a
follow-up
issue
where
we
can
explore
different
ways
to
to
handle
this
default
value.
A
I
think
I
think
what
we
need
is
a
follow-up
issue
or
pr
that
really
we
should
not
be
setting
a
default
for
header
match
type.
F
So,
for
the
time
being,
leave
header
match
type
as
a
pointer
and
then,
as
you
mentioned,
rob
create
a
pr
or
an
issue
and
then
link
to
that
issue
in
this
pr
for
tracking
purposes,
as
it
merges.
A
That
that
would
be
my
thought,
because
this
this
has
been
a
helpful
discussion,
and
I
agree
that
a
default
value
here
does
not
make
sense
and
at
least
under
the
constraints
we
have
of
you
know,
you
want
a
default
value
if
headers
is
set,
but
we
can't.
We
can't
do
that
right
without
further
nesting
and
that's
out
of
the
scope
of
this
pr.
A
All
right,
I
will
I'll
make
a
note
to
come
back
to
this
too
and
and
add
a
comment
as
a
follow-up,
but
yeah.
Thank
you
for
taking
this
on.
There
are
a
lot
of
great
improvements
around
validation.
Here,
it's
good
to
see,
taking
advantage
of
what
what
crd
validation
we
can.
A
B
A
A
Oh
sure,
I
probably
have
them
up
here,
which
one
is
it
or.
A
A
Yeah
wrong
so
yeah
hp
route
filter.
I
know
I
commented
on
this
one.
B
A
Yeah,
okay,
so
I
just
wanted
to
to
come
back
to
this
one
and
remember
what
are
trying
to
remind
ourselves
what
the
consensus
was
on
this
I
I
I
seem
to
remember
that
not
in
general
people
didn't
mind
this,
but
there
were
some
thoughts
that
we
could
wait
to
add
this
until
later,
until
it
was
actually
until
someone
requested
it.
A
Yeah
yeah
and
I
I
think
the
follow-up
around
that
made
it
okay
to
make
to
be
an
and
sorry
to
be
an
or
because
basically,
a
match
is
a
set
of
paths.
A
F
It
does,
but
I
just
pulled
out
this
pr
to
to
dig
into
it
a
little
bit
I'll.
Do
it
here
at
the
end
of
this
call.
So
it's
not
okay,.
A
All
right
well
yeah,
I
just
I
think
it's
fine
for
me,
but
yeah.
I
appreciate
any
additional
feedback
and
I'll
try
and
follow
up
with
anyone
who
might
have
issues,
but
this
is
just
a
reminder
if
you
have
any
issues
with
this
approach.
Please
comment
on
this
pr
because
right
now
the
only
comments
are
positive
ones
and
I
think
we've
had
discussions
on
calls
that
have
indicated
some
confusion
around
here.
A
A
Okay,
yes,
but
I
know
here
you've
got
to
go
soon
and
this
is
a
much
larger
pr
yeah.
We.
A
I
guess
it
is
yeah,
so
you
added
a
route
filter.
I
had
a
couple
questions
on
this
one:
yes,
okay,
so
what
is
a
union
discriminator?
I've
never
seen
that
before
as
an
annotation.
So.
B
C
A
Cool.
Okay,
that's
awesome!
I
will
I'll
do
some
more
reading
on
this.
Thanks
for
the
link
yeah,
the
the
other
one
I
wanted
to
to
cover.
I
know
you've
got
to
to
run
soon,
but
this
this
config,
it
seems
like
this-
was
somewhere
between
core
and
ext
and
custom
like
this
was
a
middle
ground.
Is
that
correct.
B
A
Okay,
okay
yeah.
I
I
agree.
We
should
cover
this
tomorrow
in
more
detail,
make
sure
it's
on
the
agenda.
F
And
I
see
a
message
from
james
in
the
chat
and
I
think
he
brought
this
up
when
mikayla
last
brought
up
the
union
types
that,
even
though
you
have
the
discriminator
tag
there.
F
B
Least,
q
builder
doesn't
do
anything
right,
but
I
think
there
are
cuba.
What
do
you
call
this
open
api
conventions
or
extensions
that
can
be
used?
You
you'll
have
to
handwrite
those,
but
I'm
not
too
sure
about
that
either.
F
E
A
A
All
right,
perfect,
so
I'll
I'll
make
sure
it
looks
like
harry
just
dropped,
we're
about
to
I'll
make
sure
we
revisit
route
filter
later.
There's
lots
to
dig
through
here
and
if
anyone
has
time
it
would
be
a
great
issue
to
have
read
through
for
pr
to
have
read
through
first
because
they're.
A
Well,
you
can
see
the
diff
it's
it's
a
relatively
large
one,
admittedly
plenty
of
code,
gen
2
but
yeah,
and
the
the
last
one
that
I
wanted
to
cover
kind
of
going
out
of
order
here
is
reordering,
make
targets.
F
The
issue-
I
didn't
open
up
an
issue,
but
you
see
in
the
in
the
commit
message
where
I
was
just
making
a
small
change
to
api
and
pr
250
and
tried
to
run.
You
know
make
all
and
that's
basically
what
I
got
as
soon
as
I
swapped
the
order
of,
and
I
think
I
don't
think
it's
necessarily
generating
the
controller.
I
think
it's
the
running.
F
D
I
probably
just
ran
it
again
and
saw
it.
I
think
this
is
I
I
gave
this
approval.
I
think
this
is
fine.
I
I
saw
the
comment
from
bowie
about
wanting
proper
dependencies
in
may.
G
Oh
yeah,
the
thing
is:
if
you
reorder
it,
it
doesn't
fix
it
necessarily
if
you're
doing
make
dash
j,
because
I
don't
think
make
actually
is
supposed
to
understand
the
ordering.
F
And
bowie:
that's
because
make
all
doesn't
necessarily
run
those
targets
in
the
order
specified
in
the
makeover.
G
I
don't
think
that's
the
case
with
make
dash
j,
because
otherwise
you
wouldn't
be
able
to
do
parallel,
makes.
G
G
F
All
right
yeah,
I
mean
if
we,
if,
after
this
merges
this
happens
again,
then
I'll
kind
of
follow
the
proper
procedures
and
create
an
issue
and
and
then
hopefully
also
have
time
to
figure
out
what
the
real
issue
is.
A
Cool
all
right.
Well,
thanks
thanks
for
fixing
this,
I
think
that's
it
for
pr
and
issue
triage.
Were
there
any
more
pr's
or
issues
that
we
haven't
covered,
that
we
should.
A
Well,
I'm
thinking
about
it
I'll
make
sure
that
we
have
harry's
work
on
route
filter
at
the
top
of
the
list
for
tomorrow,
okay
cool,
so
the
next
one
is
an
issue
I
meant
to.
A
I
meant
to
file,
but
I
haven't
gotten
around
to
it
yet,
but
there
is,
it
came
up
recently
that
default
doesn't
really
make
sense
in
route
spec.
At
least
it
doesn't
make
sense
to
me
the
you
know,
if
you
think
of
gateways
referencing
multiple
routes,
then
it
and
and
and
kind
of
essentially
what
would
happen
is
those
routes.
Those
route
rules
are
going
to
get
merged.
A
It's
very
very
unclear
and
vague.
What
on
earth
a
bunch
of
defaults
like
how?
How
do
you
merge
defaults
in
that?
In
that
way,
I
it
doesn't
really
seem
to
make
sense.
At
least
to
me
it
seems
like
you
could
effectively
recreate
a
default
behavior
just
with
a
route
that
matches
everything
a
route
rule
that
matches
everything
just
slash.
D
H
A
And
ingress
potentially
makes
a
little
bit
more
sense
here,
maybe,
but
because
we
have
this
separation
between
gateway
and
route,
I
feels
even
more
potentially
troublesome.
I
don't
know
I'm
sorry.
What
were
you
going
to
say?
I.
A
That's
that's
a
great
question.
Yeah
I'd
have
to
go
back
through
and
and
and
look
through.
Our
notes
for
that.
A
A
So
even
there
it
it
is
rather
repetitive.
Yeah
yeah.
B
F
Several
http
route
hosts
that
have
different
paths
that
are
pointed
to
different
backend
services,
but
would
they
want
some
kind
of
default
so
that
none
of
those
match
it
goes
to
some
special
error
page
or
something
like
that.
A
Yeah
and
that's
generally
been
the
idea
here
and-
and
I
definitely
get
the
idea
of
having
this
kind
of
default
where
none
of
your
route,
none
of
your
route
rules
match,
and
you
want
yeah,
404
or
similar
kind
of
behavior,
but
that
that
is
equally
easy
to
accomplish
with
a
route
rule
that
matches
everything
yeah
it.
A
A
So
yeah
we,
my
thought,
is
especially
in
this
world,
where
we're
doing
so
much
merging
it
and
we're
trying
to
avoid
conflicts
where
possible.
A
F
C
A
Great
so
yeah,
I
think
I
think
that'll
be
a
nice
little
bit
of
cleanup
and
speaking
of
cleanup,
I
went
ahead.
We
talked
about
this
last
week.
A
I
just
ran
the
idea
by,
I
think
both
office
hours
and
the
main
meeting
of
this
kind
of
pre-alpha
api
review
and
okay
harry
just
added
a
comment.
Yes,
I
I'm
not
sure
exactly
how
to
do
this
and
I'm
glad
that
harry
has
added
his
feedback
here.
A
I
am
very,
very
open
to
other
approaches
here.
I'm
not
I'm
not
too
invested
in
this
some
background
on
this.
This.
This
was
inspired
by
two
things.
This
was
inspired
by
some.
A
I
think
I
think
it
was
james
had
mentioned
a
while
back
that
it
would
be
really
good
for
us
to
just
walk
through
the
entire
api
top
to
bottom
and
add
comments
feedback
whatever,
as
we
as
we
got
to
something
that
didn't
make
sense,
and-
and
second
I
talked
with
tim
a
bit
about
you-
know
how
we
could
get
better
feedback
from
him
on
this
on
this
api,
especially
before
we
try
to
do
an
alpha
release
and
he'd.
A
Also,
you
know
requested
a
way
to
provide
feedback
over
the
entire
api
in
one
shot,
which
is
hard
to
do.
A
You
know
like,
like
harry
harry,
mentions
here
one
option
of
b2
to
link
to
the
github
files
to
keep
them
in
sync
as
an
example,
that
would
be
easier
to
keep
in
sync
absolutely,
but
I
think
it's
harder
to
provide
feedback
in
the
you
know
at
a
per
line
level
of
the
you
know
what,
as
I
quickly
realized
as
I
was
copying
this
over
some
of
our
types
are
quite
verbose
already.
A
If
you
really
want
to
comment
on,
say
a
specific
field
or
a
specific
default,
or
I
I
don't
know
how
whatever
it
might
be.
So
that
was
my
motivation
for
this
doc,
but
I
fully
recognize
that
this
is
going
to
get
annoying
to
maintain
I'm
I'm
volunteering
to
maintain
that,
but
I
do
recognize
it
will.
It
will
get
annoying
and
I
am
wholeheartedly
open
to
other
ideas
here.
I
really
just
the
end
goal
here
is
to
make
it
very
easy
for
both
ourselves
and
anyone.
A
Does
anyone
have
any
thoughts,
other
approaches
etc
around
this.
A
That
that's
the
thought
process.
I
I'm
interested
in
trying
this
out.
At
least
you
know.
Maybe
we
can
try
it
out
internally,
I've
already.
You
know
the
nice
thing
about
the
nice
and
annoying
thing
about
google
docs.
Is
it
gives
you
all
these
cool
underlines?
A
Yeah,
okay,
there's
a
few,
a
few
things
that
it
caught
that
we
should
fix
these
are
these
are
all
pretty
tiny
things,
but
it
I
think
it
will
be
helpful
to
have
something
like
this,
so
we
can
all
take
a
second
look
at
what
where
we've
got
into,
because
it's
it's
very,
very
easy
to
at
least
for
me,
to
get
caught
up
in
these
incremental
changes
and
not
take
the
time
to
look
back
over
the
whole
thing
and
make
sure
that
you
know
all
these
incremental
changes
that
made
sense
individually
have
actually
resulted
in
something
that
makes
sense
as
a
whole,
which
are
you,
okay,.
D
A
Yes,
yes,
I
that's
so
that
was
going
to
be
my
next.
My
next
question
well
set
of
questions.
Okay,
not
vmware
specifically,
but
do
we
want
to
get
anything
else
in
here
before
we
start
circulating
this?
I
don't
know.
I
think
I
think
what
we
have
is
a
pretty
reasonable
base
to
start
getting
feedback.
A
I
can't
think
of
anything
that
I'm
uncomfortable
sharing
right
now,
I'm
looking
at
the
prs
that
are
coming
in
that
haven't
made
it
yet,
and
I
don't
think
you
know
I
don't
think
they're
absolutely
critical
to
having
for
for
our
first
round
of
review,
circulation,
etc.
A
A
A
Being
developed,
that's
a
great
question.
It
does
not.
I
should
add
that
at
the
top
here
as
a
maybe
the
easiest
way
would
be
to
link
to
the
v1
alpha
1
checklist,
because
that's
currently
showing
the
things
that
are
in
progress
that
are
not
currently
part
of
this
spec
and
it
will
automatically
be
updated,
as
things
are
resolved
and
added
here
does
that
seem
like
it
would
be
sufficient.
F
I
think
so,
maybe
just
you
know
in
in
bold
lettering
or
something
just
telling
people
hey,
you
know,
take
a
look,
so
you
understand
that
there
are
still
some
outstanding
items.
Otherwise,
if
people
don't
know
that
they're
going
to
go
through
here
and
they're,
probably
going
to
mention
stuff
around
status
conditions
and
yeah.
A
Yeah
you're
right:
okay,
that's
great
feedback.
I
will
do
that
and
then
we
do
have
a
sig
network
meeting
tomorrow
afternoon,
community
meeting,
so
I
will
probably
if
it's
all
right
with
everyone
I'll
try
and
circulate
this
among
that
community
as
well
just
to
try
and
get
some
feedback
from
from
those
them
as
well.
I
think
that
would
be
really
valuable
at
this
point.
A
I
think
the
more
feedback
we
can
get
within
reason
will
be
helpful,
though,
though
I
do
recognize
that
too
much
that
this
could
also
turn
into
a
very
distracting
exercise,
but
we'll
deal
with
that
when
we
get
there.
F
A
A
I
I'd
appreciate
before
we
circulate
this
too
much,
I
mean
even
just
over
the
next
less
than
24
hours,
whatever
it
is,
but
just
if
you
have
some
time
to
run
through
this
and
and
see
if
there
are
things
that
are
just
you
know
beyond
beyond
typos,
but
just
things
that
don't
really
make
sense
or
gaps
in
the
api.
A
Okay,
all
right
well
that
that
is
about
it
other
than
conflict
resolution,
but
I
always
add
conflict
resolution
at
the
end
of
meetings
just
to
try
and
fit
in
a
few
more
things,
but
before
we
get
there
are
there
other
topics
that
we
should
discuss
as
part
of
this
meeting
today,.
A
Great
well
I'll
always
take
some
time
for
conflict
resolution,
so
I
I
think
some
of
the
some
of
the
higher
level
things
that
I've
I've
been
hearing
as
part
of
feedback
here
is.
A
We
do
want
to
be
specific,
but
there
are
some
cases
where
we
can't
it's
too
early
to
solve
everything.
It's
too
early
to
be
too
prescriptive
about
everything,
because
we
can't
predict
how
everything
is
actually
going
to
be
used,
but
I
do
think
these
guiding
principles
are
broadly
supported
at
this
point,
so
at
least
you
know
actually
standardizing
on
these
and
putting
them
into
our
checking
them
into
code
somewhere,
I
think,
would
be
helpful.
A
There
are
some
other
issues
here
that
I
think
might
might
be
worth
a
little
bit
of
discussion,
one
that
I
I
had
raised.
I
for
I
forget
who
actually
raised
this
one,
but
I
think
it's
it's
a
broadly
supported
idea
that
if
you
know
if
tls
is
available,
implementations
are
likely
going
to
prefer
it.
So
if
you're
listening
on
both
both
protocols
as
an
example,
I
don't
know
that
we
have
a
way
to
communicate
that
a
specific
protocol
is
preferred
over
another
protocol.
A
Okay,
trying
to
think
of
anything
that
we
haven't
already
covered,
I
think
in
various
meetings
now
I've
gotten
good
feedback
on
all
the
all
the
various
conflicts
that
I
have
raised
or
suggested
at
this
point,
one
that
I
have
not
thought
of
enough
is
if
multiple
gateways
choose
to
request
like
if
multiple
gateways
request
the
same
address,
I
think
this
one
is
going
to
go
right
back
to
the
idea
of
oldest
resource
wins,
unfortunately,
that
again
can
cause
it
an
issue.
A
H
G
A
I
think
you
know
I'm
in
I'm
interested
more
in
the
use
case
of
gateway
merging,
I
think
I'll
be
obviously
ingress
merging
or
something
like
that
made
a
lot
of
sense,
gateway
merging
seems
less
clear
to
me,
because
gateways
can
already
target
multiple
routes.
A
When
you
would
choose
to
merge
or
want
to
merge
gateways,
but
I
do
know
this
has
come
up,
but
I
think
it
would
be
helpful
to
understand
the
use
cases
behind
it.
So
I
don't
know,
does
any
can
anyone
think
of
when
that
might
be
useful.
D
Yet
that
could
be
depending
on
your
infrastructure,
I
suppose,
or
or
depending
on
what
your
gateway,
the
listeners
that
you
have
in
your
gateways,
maybe
like.
I
can
imagine
if
two
gateways
specified
the
same
address,
but
then
they
had
listeners
listening
on
disjoint
sets
of
ports,
then
that
could
be
implemented
in
a
single
network.
A
So,
in
that
case,
we
still
need
to
at
least
think
about
implementations
that
might
merge
gateways
and
or
might
support,
merging
gateways
and
specifically
how,
because
that
seems
like
it
could
open
up
a
whole
slew
of
potential
conflicts
right.
You
have
duplicate
listener,
ports,
protocols,
etc.
A
It
seems
potentially
useful,
but
it
also
it
also
feels
scary
to
handle
from
a
you
know
the
number
of
conflicts
that
it
could
introduce.
D
Maybe
so
I
guess
one
way,
one
if
you
do,
if
you
don't
request
a
gateway,
some
infrastructure
is
going
to
sorry.
If
you
don't
request
an
address,
some
infrastructure
is
going
to
be
able
to.
You
know,
assign.
A
D
Address
from
a
pool
and
and
you'll
be
golden
the
in
cluster
ingresses
at
least
contour
has
you
know
a
fixed
set
of
a
fixed
data,
plane
footprint
and
it
has
some
address
already
and
so
it'll
probably
try
to
merge
multiple
gateways.
D
A
I
think
that's
a
good
point.
One
of
one
of
the
you
know
when
we
talked
about
listener
conflicts,
one
of
the
solutions
that
was
oh,
we
can.
We
can
handle
this
with
validation
right.
You
do
a
validating
web
hook.
You
ensure
uniqueness
within
the
gateway
of
all
the
listeners.
Well
as
much
as
you
can,
whereas
across
gateway's
a
look
you
don't
have
as
much
safety
with
validation,
but
I
think
a
lot
of
these
same
principles
will
apply
here.
C
A
All
right,
well,
I
know
we're
we're
already
over
time.
Thank
you
to
everyone
for
the
great
feedback
today,
I'm
excited
you
know
it
feels
like
we're
we're
within
reach
here
not
too
far
away
from
a
release.
Hopefully,
so
thank
you
to
everyone
for
your
contributions
and
we'll
talk
to
you
all
soon.