►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20220725
Description
SIG Network Gateway API Bi-Weekly Meeting for 20220725
B
A
A
A
A
B
E
F
F
F
However,
that
might
be
a
problem.
If
you
don't
know
what
the
current
running
state
is,
or
or
at
least
potentially,
depending
on
how
you
want
how
you
want
to
look
at
it.
So
I
encourage
everybody
that
that
is
involved
in
implementations
to
carefully
evaluate
how
it
describes
things
and
and
see
if
you
think
you
can
work
with
that
or
if
it
would
be
a
challenge
for
you
the
way
it's
described
here.
F
So
if
you
ignore
that
fact-
and
just
look
at
what
the
behavior
is,
I
should
say
it's
a
way
of
describing
behavior
not
not
a
way
of
implementing
it
implementing
it.
Maybe
that's
a
better
way.
To
put
it
so,
keep
that
in
mind
that
it's
it's
not
dictating
exactly
how
you
implement
the
logic.
It's
simply
a
way
of
expressing
what
the
logic
is.
B
B
B
E
I
think
this
is
this
is
like
lots
of
other
extended
features.
Bowie
and
it's
you
don't
have
to
do
it,
but
if
you
do
do
it,
it
must
behave
in
this.
Certain
way
must
is
the
word
not
should
you're
like
yeah,
like
the
the
whole
feature
is
optional
but
like
if
you
implement
the
feature,
it
must
behave
in
a
certain
way
and
we'll
conformance
test
that
to
make
sure
that.
F
F
E
E
The
problem
is
that
this
system
is
eventually
consistent,
so
you
can't
always
be
sure
that
you
know
the
before
state
and
the
after
state
before
and
after
are
a
bit
fuzzy
and
so
the
I
think,
the
the
point
that
the
ephemeral
thing
has
in
there
there's
two
things
that
I
just
need
to
talk
about
quickly.
The
question
the
boy
asked
about
the
ephemeral
route,
the
ephemeral
route
thing
is
like
it's
like
a
way
to
think
about,
what's
happening
here
like
what
you're
doing
by
yeah
exactly
constant.
E
What
what
you're
doing
by
doing
this
is
that
you're
kind
of
taking
all
of
the
all
of
the
routes
that
that
could
possibly
end
up
together
and
you're
trying
to
build
like
a
like
a
singular
route
object
that
puts
them
all
together
right
like
so.
It's
kind
of
like
the
ephemera
route
is
a
thing
that
you
don't.
E
Gonna
have
to
do
something
like
this
before
and
using
that
ephemeral
route
to
sort
of
talk
about
the
the
state
in
which
everything
is
sort
of
attached
in,
and
you
have
like.
One
big
object,
rather
than
a
series
of
smaller
objects,
is
like
a
way
to
describe.
What's
probably
going
to
need
to
happen
in
your
network.
B
B
F
E
G
G
You
know
impossible
to
compute
for
foreign,
so
I
think
one
of
the
things
that
that
I
I
asked
when
I
reviewed
this
document,
I
think
about
your
comments-
is
to
to
to
have
a
simplified,
basically
version,
basically
where,
where
you
maybe
restrict
to
only
host
name
and
path,
prefixes
or
or
have
some
restrictions,
so
at
least
regex
is
in
it.
Don't
don't
come
into
picture
because
with
regex
in
both
routes,
it
would
be
absolutely
impossible
for
anyone
to
to
understand
anything,
and
the
second
comment,
I
think,
which
is
very
important,
is
semantically.
G
This
should
be
equivalent
with
having
two
gateways,
so
we
have,
one
gateway
is
implemented
with
the
first
route
and
the
back
end
would
be
another
gateway
that
implements
the
second
route.
If
we
can
guarantee
that
the
semantic
is
identical
with
having
two
gateways,
I
think
we
are
fine
and
most
of
these
things
go
most
of
the
complexity
goes
away.
I.
G
E
E
If
you
think
of
the
way
I've
always
talked
about
this
is,
if
you
think
of
this
domain,
url
space
as
a
space
right
like
as
a
configuration
space,
a
multi-dimensional
configuration
space,
you
can,
you
can
slice
up
that
configuration
space
and
hand
responsibility
for
it
to
some
people.
That's
what
we're
trying
to
do
here
and
so.
E
But
then,
if
you
do
anything
inside
that
that
breaks
that
goes
against
anything
that
you've
been
given
by
the
person
who
owns
the
parent,
then
then
your
thing
will
just
not
work
right
like
and
that's,
and
I
think
that's,
I
think,
part
the
the
thing
that
I
think
the
thing
that
you're
trying
to
say
custom.
Forgive
me
if
I'm
putting
words
in
your
mouth
is.
This
is
really
complicated
because
there
are
so
many
features
on
a
route,
and
I
think
that
what
we
need
to
do
here
is
I.
E
I
think
that
what
we're
going
to
find
is
that
we
need
to
be
really
aggressive
and
just
say
if
you
make
a
mistake,
think
your
thing
will
just
not
work
like
it
will
just
get
chucked
out
right
like
because
that's
the
only
way
that
you
can
ensure
the
consistency
like
across
your
controller
restarts
and
there's
a
whole
bunch
of
other
api
machinery.
Shenanigans
that
you
just
cannot
do
it's
not
possible
to
have.
There
is
too
much
complexity
to
manage
to
have
this
set
up.
You
know
this.
E
This
complicated
a
feature
also
make
not
like
make
it
so
that
if
you
break
something
things,
don't
blow
up
right
like
it's
just
there's
too
many.
That
adds
too
many
dimensions
to
this
problem,
and
so
I
think
we
need
to
be
clear
with
people.
If
you
are
doing
this,
it
is
an
advanced
thing.
If
you
break
something
sorry,
your
shoes
gonna
break
right
like
that's,
you
that's
the
best
that
we
can
do
right
that
you
want.
D
G
My
point
is
is
really
that
it
should
not
be
that
complex
and-
and
in
reality
I
mean
the
ephemeral
stuff
doesn't
solve
the
complexity.
It's
just
you
know,
kind
of
if
you
are
lucky
and
you're
doing
the
config
change
at
runtime
instead
of
in
a
cicd
system
that
is
pushing
and
and
the
order
is
not
deterministic,
maybe
you're,
lucky
and
you're
not
break
stuff.
But
really
the
problem
is
a
complexity
of
combining
two
routes
together
and
the
best
way
to
solve
it.
G
Is
you
know
to
to
express
it
in
a
way
that
is
easy
to
understand
and
having
two
gateways
change?
It's
how
people
implement
this
feature
today,
because
it's
not
a
new
problem.
A
lot
of
people
have
one
front
end
that
is
doing
a
set
of
routes
and
then
a
second
gateway
per
name
space
of
their
teams
and
is
doing
a
secondary
set
of
routes.
F
That's
not
the
the
focus
or
the
intent
behind
this,
though,
as
nick
was
saying,
the
intent
behind
this
is
to
allow
administrative
delegation
within
the
gateway
and
so
how
how
enterprises
deploy
do
this
today
is
simply
they
have
whoever's
the
you
know
that
the
admin
for
the
gateways
has
to
write.
You
know
more
complex
routing
configuration
and
make
sure
that
it's
right
for
each
application's
requirements
and
when
an
app
makes
it
makes
needs
a
change.
F
Then
they
have
to
go
to
the
gateway,
administrator
and
request
that
change
and
so
on
so
forth.
So
that's
what
we're
trying
to
avoid
here.
We're
also
trying
to
make
the.
Let
me
finish
real,
quick
one.
Other
aspect
of
it
is
the
other
thing
is
we're
trying
to
make
it
so
that
routes
are
more
composable,
so
they
are.
You
can
have
this.
F
B
A
There
is
our
machinery
that
we
recently
added
for,
like
experimental,
channel
and
stuff
like
that,
provide
enough
window
to
say
just
push
this
through
into
a
state
that
we
can
all
agree
is
like
okay
to
merge,
but
not
okay,
to
release
like
do.
We
have
the
machinery
in
place
where
we
can
work
on
this
more
iteratively,
so
it
doesn't
have
to
be
this
big
giant,
vr
anymore
and
start
chipping
away.
A
B
But
it's
it's
hard
to
like
keep
the
comments
on
there.
So
I
think,
since
this
has
been
discussed
a
lot,
but
we
did
kind
of
like
completely
contact
shift
as
a
group
to
just
get
5.0
out.
I
would
say
that
it's
probably
worth
this
week,
you
know
especially
we're
mentioning
on
monday.
It's
just
like
hey
everyone.
Please
look
at
this
pr
and
then
probably
next
week
we
can
kind
of
see
like
hey
everyone's,
had
a
chance
to
kind
of
refresh
their
brain
like.
B
F
F
So
I
just
wanted
to
call
this
out
right
here
which,
because
I
think
it's
important
bowie
what
you
brought
up
about
the
ephemeral
routes,
and
so
I
just
wanted
to
stay
in
here
because
it
it
really
goes
to
to
address
your
question.
So
it's
the
ephemeral
routes
are
are
used
to
describe
behavior,
not
necessarily
to
dictate
implementation.
D
C
This
approach
makes
sense
to
me
I
wanted
to.
While
you
have
this
up,
I
wanted
to
just
there
was.
There
was
one
area
where
it
describes
just
the
specific
changes
that
would
need
to
happen
to
the
api
yeah,
I'm
wondering
if
we
could
just
refresh
at
least
my
memory
and
anyone
else's
memory
of
what
we're
actually
proposing
here,
because
I
think
that's
good.
F
F
Another
thing
that
we're
requiring
is
that
the
parent
route
would
have
to
be
the
same
type
specifically,
so
you
couldn't
have
a
child
route,
that's
an
hp
route
with
a
parent,
that's
a
tcp
route
and
that's
one
of
the
places
where
the
concept
of
treating
it
like
a
like
two
gateways
breaks
down,
because
if
you
want
to
do
this
in
one
gateway,
you
may
not
be
able
to
do
that.
The
the
way
your
your
data
layer
is
implemented.
F
E
F
And
then
the
the
which
I
meant
something
I
mentioned
a
little
bit
earlier-
is
a
child
could
have
multiple
parents
just
like
a
parent
can
have
multiple
child,
so
this
is
a
way
to
where
you
need
a
partial
configuration
in
multiple
different
gateways.
This
allows
you
to
define
that
config
once
and
then
reuse
it
by
reference
in
multiple
gateways.
E
Yeah,
exactly,
I
think,
there's
been
a
bit
of
there's
been
a
bit
of
discussion
in
the
chat
as
well.
While
jeff
was
explaining
that-
and
I
think
the
there's
a
couple
of
things
that
came
up
in
the
chat
that
I
think
we
need
to
be
super
clear
on.
Firstly,
there
is
nothing
in
the
spec
today
that
prohibits
you
from
having
a
gateway
resource
that
requires
another
gateway
resource
to
work.
E
In
fact,
that's
kind
of
how
we
intended
and
expected
layer,
7,
ingressy
controller
style
gateway,
implementations
to
work
that
they
would
depend
eventually
on
a
layer,
4
gateway
that
approximates
the
functionality
of
services,
type
load,
balancer
right.
So
there's
no,
there's
no
reason.
You
can't
like
layer
things
to
some
extent
now
and
require
a
gateway
sort
of
a
gateway
implementation
needs
something
else
that
could
be
a
gateway
to
work,
that's
100
expected
and
the
way
that
we
expected
this
thing
to
work.
E
I
think
that
I
understand
what
you're
saying
costume,
that
having
multiple
gateways
be
a
semantic
model,
I
think,
is
a
really
bad
idea,
because
it
breaks
the
idea
that
a
gateway
is
a
thing
that
sits
at
the
end.
A
gateway
is
a
construct
that
sits
at
the
edge
of
a
cluster
like
that's
the
that
is
the.
That
is
the
thing
that
we
have
spun
this
whole
api
design
around
is
a
gateway
is
a
thing
that
translates
between
stuff.
That
knows
about
the
classwork
internals
to
stuff.
E
The
gateway
is
a
routing
point
that
lets
you
know
about,
and
so
in
terms
of
the
layer,
4
layer,
7
thing
you're,
using
a
gateway
to
take
layer,
4
stuff
that
doesn't
know
about
the
cluster
and
get
it
into
the
cluster
and
then
you're
using
that
as
a
way
to
expose
something
that
speaks
layer
7.
That
then,
has
its
own
way
of
describing
things
so
you're
composing
layers
in
osi
model,
not
routing
hops.
E
I
think
that
a
gateway
is
not
a
routing
hop
right,
like
you
know,
and
that's
and
the
the
administrative
thing
that
we're
talking
about.
Like
using
gateways
as
listeners
like
using
gateways
like
as
sort
of
parents
and
children
would
imply
implies
that
that
they
are
routing
homes
right
like
whether
or
not
that's
actually
the
case,
that's
the
very
clear
implication
for
the
api
and
unless
that's
the
way
it's
implemented,
then
I
think
that
using
that
to
handle
this
thing,
I
understand
what
you're
saying
what
we
are
proposing
is
very
complex.
E
I
think
that
there's
possibly
an
argument
that
you
could
make
that
that
the
child
http
route
could
be
a
separate,
a
separate
resource
that
has
a
cut
down
set
of
things.
Maybe,
but
like
that,
I
I
would
prefer
to
see
us
do
like
to
try
it
out
and
see
what
happens
and
then,
like
you
know,
and
see
how
hard
the
the
sort
of
conflict
management
is
before
we
before
we
go
down
that
path,
because,
as
I
said,
there
is
prior
art
here,
both
console
contour.
E
I
think
other
people
have
similar
sort
of
admin
delegation,
ideas
that
that
have
kind
of
worked
right
like
even
though
it
is
complex
they're
like
that's
what
that's
what
I'm
trying
to
say.
I
think
that
we're
better
off
trying
something
like
this,
and
I
think
that
the
proposal
we've
got
here
is
actually
like
quite
well
thought
out.
We've
spent
a
lot
of
time
thinking
about
exactly
how
this
stuff
works
and
yeah.
E
I
need
to
take
another
pass
over
the
status
stuff,
because
I
know
that
mike
and
I
have
sort
of
back
and
forth
on
status
for
the
base
http
route.
A
lot-
and
you
know,
there's
some
changes
that
we
have
made
there
that
I
think
are
very
relevant
to
this,
especially
stuff
about,
like
you
know,
when
things
will
be,
will
become
unattached
and
when
they
won't.
That
are
really
really
important
here,
like
we've
changed
the
rules
a
little
bit
about
that
a
http
route
with
a
back
end.
E
Ref
that
is
valid
but
has
zero
endpoints
will
not
will
still
be
attached,
and
so
that's
really
relevant
here,
because
it's
much
more
likely
that
you
have
a
child
patient
appear
out
in
and
there
are
flow
on
effects.
If
a
parent
http
route
has
a
valid
allowed
routes,
reference
to
a
child
that
has
zero
endpoints,
then
that
is
a
different
behavior
to
use
up,
and
so
this
this
absolutely
is
expected
to
be.
We
are
going
to
describe
this
behavior,
so
cost
and
you're
asking
the
chat
like.
Can
this
be
implanted
in
a
vendor-specific
extension?
E
E
Yeah,
it's
experimental
in
that
we
may
change
it
right
like
if
you
implement
it
and
we
all
find
it
goes
pear
shaped
and
it
doesn't
work
the
way
we
think
it
does
then
we'll
change
it.
Right
like
this
is
not
final,
and
so
that's
the
that's
why
we
have
all
of
those
versioning
things
so
that
we
can
experiment
with
this
and
try
it
out
in
a
way
that
if
it
does
work
out,
we
haven't
all
ended
up
doing
our
own
implementations
and
that's.
B
D
C
D
C
C
We
need
feedback,
we
need
to
test
this
out
and
I
think
one
of
the
risks
we
have
if
we
had
kind
of
every
implementation
or
different
implementations
trying
their
own
unique
way
to
do
this
is
we
have
more
difficulty
bringing
this
back
to
convergence
later
so
agreeing
on
this
is
what
we're
going
to
start
with.
This
is
how
we're
going
to
test.
Initially,
I
think,
is
a
good
starting
point.
G
Rob
how
is
this
going
to
proceed?
I
mean
one
vendor
is
going
to
implement
it,
and
users
will
try
that
vendor
and
see
how
it
works
and
provide
feedback,
because
I
don't
see
how
multiple
vendors
can
accidentally
come
to
the
same
implementation,
giving
the
complexity
of
combining
routes.
So
is
it
one
of
the
vendors?
Will
you
know
just
I
will
implement
it
get
feedback
and
then
there's,
for
example,
how
we
plan
to
do
it.
F
As
nick
and
I
have
both
mentioned-
I
mean
that
this
basic
concept
is
already
implemented
in
at
least
two
different
products
console
and
contour,
and
so
we
do.
We
do
have
that
that
experience
that
that's
feeding
into
this
and
the
customer
feedback
we've
gotten
from
doing
those.
You
know
for
each
of
those
implementations,
the
feedback
we've
gotten
as
the
people
involved
in
those.
E
So
the
next
steps
here
are:
we
need
to
make
something
in
the
spec,
so
that
then
we
can
have
so
that
the
implementations
may
develop
something
against
what
we
have
right
like
that's.
The
only
way
that
we're
going
to
get
some
user
feedback
is
to
put
some
put
a
spec
together,
even
if
it's
experimental
and
draft
we
say:
okay,
here's
what
we
need.
Here's
the
way
this
feature
works
for
now,
experimental
blah,
blah
blah
blah.
We
say
this
is
the
way
you
implement
it.
E
What
we
found
in
the
past
is
that
it's
when
the
rubber
meets
the
road
of
actually
implementing
things,
you'll
find
a
lot
of
edge
cases.
You
never
thought
of
because,
like
then
you're
actually
writing
the
code
to
be
like.
How
do
I
do
this
and
then
people
will
be
like?
Oh
when
you
do
this
and
this
and
this
then
then
this
then
this
bit
doesn't
make
sense
right
and
that's
like,
but
you
can't
do
that
without
having
some
spec
right
like
this
spec
is
never
going
to
be
perfect.
It's
never.
E
Implementations
getting
like
people
have
tried
this
out
feedback,
even
if
it
is
the
implementers
will
both
will
be
useful
so,
like.
I
think,
I
think
that
yes,
the
the
there
definitely
should
be
concerns
about
about
how
the
implementations
work
and
how
how
that
implementation
actually
works,
but
once
some
people
have
implemented
it,
then
they
can
say
hey
these
things
were
hard.
These
things
were
easy.
This
is
what
we
did.
You
know
like
yes,
and
some
of
the
some
of
the
implementations
are
definitely
important.
E
Based,
yes,
so
contrary
is
envoy
based
contra
is
an
onboard
based
thing.
We
have
already
done
this
okay,
so
the
the
the
data
path
is
actually
relatively
irrelevant.
Right
like
it
is
all
the
hard
part
is
all
about
like
taking
the
config
and
washing
it
together.
Right,
like
exactly
as
you
said,
there's
a
lot
of
complexity
there,
but
you
can
actually
like
manage
that
complexity
by
having
a
very
clear,
very
specific,
set
of
rules
about
what
happens
when
you
have
a
conflict
right.
E
So
you
know
and
then,
as
long
as
you
don't
do
a
conflict
everything's
fine
and
as
long
as
you
know
what
happens
when
you
have
a
conflict
like
then,
then
you
can
be
and
that's
why
that's
that
stuff
about,
like
you
know,
does
do
you
sort
of
try
and
like
keep
the
current
config
or
or
just
blow.
Everything
up
is
really
important
because
that's
the
conflict
resolution
rules
and
the
conflict
resolution
rules
are
the
way
to
make
something.
This
complex
actually
work
the
yeah.
So
I
think
that's
the
that's
the
key.
D
Well,
I
I
my
comments.
I
guess
were
more
procedural
that
I'm
concerned
about
the
sort
of
let's
throw
it
in
there
and
then
decide
what
we
want
to
do
with
it.
Like
you
know
the
classic
salesman
shoe
and
the
door
right.
You
know,
I
I'm
you
know,
there's
a
point
at
which
things
get
momentum
just
by
virtue
of
being
in
the
spec,
and
it
feels
like
we're
allowing
that
decision
to
happen
too
lightly.
F
Okay,
I
think
the
thing
to
take
into
account
here
is
that
this
is
something
this
is
not
something
new.
This
is
something
that
a
number
of
us
have
been
discussing
doing
for
probably
close
to
a
year.
I'm
thinking
it's
been
around
a
while
yeah.
So
so
there
are
a
number
of
us
that
that
want
to
see
this
implemented
and.
E
E
That
nobody's
done
before
right,
like
contour,
has
been
doing
this
for
three
years
right
like
we
have
had
lots
and
lots
of
problems,
we
have
solved
them
right
like
that's.
Why
I'm
talking
a
lot
about
this
is.
This
feature
is
not
coming
out
of
nowhere.
It
came
from
specific
requirements
that
we
got
at
contour.
From
from
our
point
of
view,
we
had
specific
requirements
for
people
who
had
big
clusters
to
not
have
ingress
objects
stopped
all
over
each
other,
and
so
we
built
stuff.
E
E
That
you're
worried
about
like
are
we
pushing
this
in
but,
like
I
can
say,
with
great
confidence,
there's
absolutely
people
who
want
this
thing,
and
we've
done
something
like
this
before
like
this
is
not
just
coming
out
of
nowhere
right
like
and
that's
why
we
want
to
push
it
because
for
us
to
be
able,
like
I'm
worried
that
I
have
too
many
biases
here
around
exactly
how
this
works,
and
I
need
some
other
people
to
do
something
like
it.
But
we
can't
do
something
like
it
without
defining
what
something
like
it
means.
D
Okay,
I,
like
I
say
I
I
do
have
a
cons.
So,
for
example,
is:
is
this
visible
somewhere
other
than
in
raw
markdown?
You
know,
I
see
people
showing
screenshots,
I
mean.
How
would
I
have
learned
of
this,
as
somebody
coming
in
only
a
few
months
ago?
Is
this
some
I
mean
again,
I'm
relatively
new
I've
been
here
a
few
months.
Should
I
just
go
through
all
of
the
pr's
in
the
pr
queue
and
read
them
all,
and
you
know
or
or
is
there
some
pipeline
that
I
can
look
at
so.
E
E
This
is
a
pr
for
a
design
for
how
to
implement
the
gap
that
says,
do
route
delegation
right
like
so
there,
so
the
gap
is
like
do
we
want
to
do
route
delegation
and,
if
so,
how-
and
so
this
pr,
then,
is
like
jeff's
design
for
how
he
thinks
we
should
do
about
delegation.
So
the
things
to
look
out
for
when
you're
reviewing,
if
you're
going
through
the
repo,
are
to
look
for
issues
tagged
as
gaps
and
then
to
see
if
there
is
a
design
pr
yet
for
them.
E
That's
that's
how
we
do
like
that's
how
we
discuss
big
changes.
We
will
always
discuss
big
changes
like
this
in
this
meeting.
That's
what
this
meeting
is
for.
If
you
see
something
you
don't
know
about
or
that
that
we
will
not
merge
something
this
big
without
having
discussed
it
substantially
like
this
in
meeting
in
the
meetings
here,
so
that's
that's
why
these
meetings
are
key.
I
agree
that
probably
there's
more,
we
could
do
to
promote
stuff,
but,
like
you
know,
like
the
yeah
I
mean,
and
possibly
we
can
have
more
discussion
in
stack.
E
A
So
given
all
that
energy,
I
think
focusing
it
at
the
pr
the
comments
this
week,
so
that
we
can
get
it
moving
along,
would
be
really
good.
So
everybody
who
had
something
to
say
here,
I
would
highly
encourage
you
get
on
the
pr
say
it,
but
try
to
keep
in
mind
that
we
are
trying
to
do
this
as
an
experimental
thing,
which
means
we
can
pull
out
any
time,
we're
not
going
to
try
to
release
it
and
so
try
to
keep
a
to
see.
A
If
you
can
push
your
bias
a
little
bit
more
towards
helping
them
get
it
in,
so
that
we
can
work
on
it
iteratively
and
then
for
the
people
who
there's
at
least
two
people.
It
seemed
that
particularly
had
this
like.
I
don't
want
to
see
this
merged
in.
It
would
be
critical
for
you
to
get
on
that
pr
and
put
the
exact
reasons
why
you
say
I
want
to
block
this
on
there
so
that
we
can
start
having
those
conversations
specifically.
B
A
A
C
A
I
am
aware
of,
and
I
think
it's
relevant
to
this
one.
Oh
you
did
okay,
you
updated
this.
I
still
have
to
read
this
one,
I'm
involved
in
this
one
too,
because
there
is
some
potential
problems
with
some
of
the
the
the
not
allowing
upgrades
from
http1
to
hb2
with
nginx.
So
I'll
follow
up
with
you
in
the
pr
on
that
one,
but
that
was
one
of
the
lingering
things
that
I
was
worried
about.
H
A
H
E
H
H
Yeah
exactly
it's
about
the
the
conflict
resolution
and
the
creation
time
stamp,
so
I
I
laid
out
a
series
of
events
here
that
seem
problematic
to
me
and
you
can
disagree
with
me
if
you
don't
think
that
yeah,
that's
the
one,
you
can
disagree
with
me.
If
you
don't
think
that
this
series
of
events
is
possible
and
then
I
I
ask,
is
it
possible
to
check
the
conditions
to
see
if
accepted
true
is
already
in
there?
This
series
of
events
seems
like
a
bad
situation
to
me.
E
Yeah
I
100
agree.
There
are
a
lot
of
weird
edge
cases
because
potential
consistency
and
yeah,
like
I
think,
mandating
that
you
know
stuff,
like
yeah,
hey
or
at
least
saying.
Should
you
should
check,
accept
a
true?
You
should
check
for
an
accepted,
true
condition
and
assume
that
it's
there
already,
you
know
like
yeah.
The
problem
is
the
problem
is
about
like
what
happens
when
the
controller
is
starting
up
and
you're
like
it's.
H
E
True
right,
so
you
can't
like
that
means
that,
then
you
can't
you
can't
treat
each
individual
route
coming
in
as
a
thing
that
you
check
right,
because
you
can't
each
each
update
to
a
kubernetes
object.
Yeah,
I
think
in
general,
it's
reasonable,
but
like
we
just
have
to
be
very
careful
about
what
happens.
E
What
happens
when
you
start
out
the
controller,
and
you
have
a
randomly
ordered
sequence
of
resources
that
you
want
to
be
able
to
treat
one
at
a
time
right,
like
you
in
this
case,
like
you've,
got
to
sort
of
make
sure
your
cases
are
drained,
and
what
does
it
even
mean
for
your
case
to
be
drained
right
like
this?
Is
probably
we
don't
need
to
go
into
it
anymore?
E
Now,
I
don't
think,
but
I
think
that
that's
where
that's,
where
a
lot
of
this
conflict
resolution
stuff
is
kind
of
sucky,
is
that
you,
like
you,
have
to
allow
for
that
case
of
yeah,
like
of
like
how
like
what
happens
when,
when
the
controller
is
starting
up
from
scratch
and
is
the
is
the
question
that
you
need
to
ask
yourself?
So
I
think.
F
C
I'll
just
echo
what
others
have
said
that
I
I
think
it
makes
sense
to
check
for
accept
and
true.
I
think
we
have
some
other
discussions
in
flight
about
that
and
I
can't
think
of
the
reference
right
now,
but
there's
there's
been
some
suggestion
of.
Can
we
check
accepted,
true
and
and
use
that
more
broadly,
so
we
don't
break
quite
as
frequently
I
I
would
I
would.
C
I
would
suggest
two
things
here:
one
we
could
mirror
conflict
resolution
guidance
elsewhere
in
the
api
as
closely
as
possible
just
to
get
this
in
and
then
next
say
hey,
you
know.
If
we
say
we
should
check
accepted
true
that
probably
doesn't
just
apply
to
grpc
route.
It
applies
to
http
route.
If
there's
a
if
there's
a
new
http
route
that
conflicts,
but
we
already
accepted
one.
C
H
That
seems
totally
reasonable
to
me.
The
reason
why
I
didn't
do
initially
in
this
case
is
because
the
the
conflict
here
is
somewhat
different
than
I
think
what
you're
referring
to
in
this
case
we're
talking
about
inter-protocol
conflicts,
right,
http
and
grpc,
but
yeah,
I'm
fine
with
that
I'll
go
ahead
and
mirror
what
we
have
for
http
route,
http
route
conflicts
right
now,
and
then
we
can
maybe
deal
with
this
issue
later.
E
E
Yeah,
it
probably
makes
sense
for
one
of
us
to
generate
an
issue.
I
can
do
it
yeah.
I
suspect
we've
covered
some
of
this
stuff
in
other
issues
already
so
the
yo.
It
may
be
an
issue
that
we
end
up
closing
the
duplicate,
but
I'd
rather
open
an
issue
and
then
find
that
we
have
a
big
issue
that
better
describes
it
and
not
have
yeah
issues
are
free
like
rather
have
too
many
than
not
enough.
E
A
E
C
E
So
this
discussion
is
about
is
about
how
we
handle
how
we
handle
putting
information
about
the
back
end
service
into
the
api
right.
So
the
things
that
we're
talking
about
here
are,
if
you're
doing
re-encryption
to
the
back-end
service
from
the
gateway
to
the
service.
Where
do
you
put
those
details?
If
you
want
to
know
that
the
service
supports
you
know,
maybe
you
were
routing
with
http
route
and
if
the
service
does
jrpc,
where
do
you
put
that
information?
E
Maybe
you
it's
a
http
route
and
the
service
supports
web
sockets.
Where
do
you
put
that
and
so
basically
there's
a
whole
set
of
things
about
like
effectively
metadata
ish
about
the
service,
about
protocol
information
or
about
something
that
you
need
to
know
about
the
service
that
we
need
to
store
somewhere?
And
so
the
you
know
like
the
original.
The
original
thing
that
we
had
said
was:
oh
we'll
just
use
that
protocol
for
that
android
panel
right
that
that's
not
sufficient.
You
know,
like
it's
pretty
clear,
that
that's
not
sufficient.
E
E
My
current
proposal
is
that
we
have
a
it's
currently
called
service
metadata
resource,
but
but,
like
I
think
that
name
is,
we
can
buy
shared
a
lot
on
that
name.
But
the
idea
here
is
that
this
is
a
wrapper
thing
for
a
service
like
a
wrap
up
resource
for
a
service.
Essentially,
that
basically
says
you:
this
kubernetes
service
is
a
back
end
and
it
now
has
here's
some
extra
information
around
around
stuff
that
we
can't
fit
into
the
server
spec
right
now.
E
The
reason
for
doing
it.
That
way,
is
that
the
service
already
has
like
far
too
much
magic
built
into
it
and
you
and
we
want
to
be
really
careful
about
what
we
add
to
it,
but
also
the
it's
really
hard
to
add
things
to
kubernetes
v1
resources.
Right
like
it
takes
a
long
time.
You've
got
to
do
like
a
9
to
12
month
cycle
to
actually
get
features
to
get
fields
in
there.
You
know,
like
it's,
really
difficult
to
do
that,
and
so,
if.
E
H
So,
who,
who
so,
is
this
a
resource
about
the
service
owner,
offering
more
information
or
is
it
about
like
telling
gateway
that
go
use?
This
information-
and
this
is
where
you
route
to
right,
like
who
controls
that
piece
of
information
one
and
who
influences
the
routing
behavior?
Is
it
like
service
owner
tells
gateway?
Hey
only
talk
to
me
on
this
port
using
this
protocol
using
the
ca
cert
and
what
not
like.
E
E
E
B
G
Yeah,
I
completely
agree,
I
mean
naming,
may
maybe
discuss
it
with
still
better
than
destination
rules
that
we
use.
My
my
only
concern
is:
is
service.
Meta
is
restricted
kind
of
to
service,
but
we
have
stateful
sets.
We
have
photoport
communication,
which
is
also
a
factor.
We
have
other
forms
of
of
things
that
are
known
as
the
service
that
may
need
to
be
supported,
especially
in
gamma
in
in
summation.
E
C
Yeah,
no,
I
think
this
is
probably
where
we're
going
to
end
up.
I
mean
I
I
haven't
spent
as
much
time
on
it
as
others
on
this
call.
But
what
what
strikes
me
as
someone
who
maybe
hasn't
been
as
involved
in
the
conversation,
is
that
this
started
clearly
as
a
discussion
of
really
the
limitations
of
app
protocol
right.
C
E
C
E
E
H
It's
all
like:
where
do
you
put
health
checking?
Where
do
you
put
load
balancing?
Where
do
you
put?
I
don't
know
tls
level
details
where
do
you
put?
I
mean
traffic
traffic
splitting.
We
have
some
some
solutions,
but
not
all
of
them
right
all
of
those
issues
right.
We
have
never
solved
it
like
we,
we
solved
some
of
them
with.
D
E
D
E
Makaya
you,
you
mentioned
the
comment
that
that
yeah
hey.
Why
don't
we
use
policy
attachment
for
this?
I
think
that
the
the
in
this
case,
I
I
kind
of
I
always
intended
policy
attachment
to
be
for
more
clearly
defined
things
not
to
be.
We
need
to
be
really
careful
that
we
don't
end
up
using
policy
attachment
as
a
get
out
of
java
free
card
for
like
doing
proper
api
design,
and
I
think.
E
And
whatever
we
do
for
mesh
working,
so
that's
why
I've
sort
of
I've
let
this
expose
this
discussion
expand.
Is
that
it's
really
important
we're
about
to
start
talking
officially
about
what
happens
with
about
what
happens
in
gamma,
and
this
is
key
for
that
sort
of
thing,
and
so
it
is
a
yeah.
It
costs
100
right.
It
is
an
effective
policy
attachment,
but
I
think
we
want
to
be.
H
E
E
D
B
D
E
So
the
I
mean
the
thing.
The
thing
that
I
would
want
us
to
work
through
is
about,
like
a
large
part
of
the
reason
why
we
did
policy
attachment
is
the
the
defaults
and
overrides
things
in
that
right,
like
and
so
like.
Do
you
want
to
be
able
to
provide
a
like
a
service
metadata
policy
at
the
gateway
level
that
affects
all
services
affected
by
routes
on
this,
and
do
you.
E
To
have
that
be
like
a
default
or
override
that's
what
the
policy
attachment
thing
is
for
is
to
have
things
where
you
can
specify
some.
You
can
attach
a
thing
to
a
gateway
class
and
say
you
know,
I'm
going
to
override
the
client
timeout
everything
in
this
gateway
timer
in
this
gateway
class.
You
know,
and
so
that's
I
think,
that
defaults
in
the
override
the
important
part
of
policy.
The
fact
that
we're
having
a
thing
that
attaches
to
another
thing
is
not
the
important
part.
If
you
you
see.
A
A
So
I
I
think
I
think
I
would
like
to
see
us
start
a
gap,
but
I
think
that,
given
what
we
saw
with
the
other
gap
that
we
looked
at
today,
it
occurs
to
me
that
you
know
in
caps.
You
have
the
idea
of,
like
you,
know,
provisional
right
and
all
the
different
statuses
we
haven't
used
those
statuses
very
well.
We've
tried
to
do
one
big
stretch
for
every
gap.
A
It
would
be
completely
reasonable,
in
my
mind,
to
just
state
the
problem
and
the
motive
like
motivation,
summary
and
goals
in
a
first
iteration
of
this,
just
to
get
everybody
behind
the
like
what
and
why,
but
not
the
how,
because
the
how
could
get
just
as
big
as
that
other
gap
and
could
be
problematic,
we'd
never
be
able
to
do
it.
Iteratively
we'd
end
up
with
a
big
long
gear,
long
gap
that
would
be
open
like
so
maybe
we
could
just
start
with
that.
E
E
D
E
A
A
D
D
E
D
Okay,
so
my
my
the
link
that
I
posted
was
just
a
comment
on
the
same
pr,
and
it
is,
you
know
we're
specifically
looking
for
you
know
what
is
the
way
that
we're
going
to
provide
re-encrypt
and
what
is
the?
What
is
the
way,
basically
that
what
is
the
solution
that
different
implementers
are
using
to
provide
re-encrypt?
E
Yeah,
I
absolutely
want
to
solve
we.
I
absolutely
think
we
need
to
solve
that
and
we
need
to
have
a
good
solution
for
it
and
so
like.
I
think
it
is
key
that
we
have
a
solution
for
re-encrypt,
but
I
I'd
like
it.
Where
do
we
put
that
information?
Because
the
is
the
question
and
that's
that's
what
this
gap
will
be?
The
answer.
A
Yeah,
I
would
say,
since
we're
trying
to
do
this
gap
a
little
bit
more
iteratively,
because
it
could
get
very
big,
I
would
just
say
in
the
first
iteration
of
the
gap
just
make
it
one
of
the
motivations
like
this
can
just
we
can
capture
this
as
one
of
the
motivations
so
that
we
follow
up
on
it
in
upcoming
iterations
and
then
obviously
I
I
take
it.
This
is
the
cut.
This
is
the
comment
right
canvas.
H
And
part
of
that
story
could
be
solved
using
policy
attachment,
that's
something
that
we
discussed
when
we,
our
third
policy
attachment,
is
like
okay,
if
you
want
to
validate
upstream
certificate
against
a
common
ca,
and
you
don't
want
to
have
like
how
many
steps
you
want
to
verify
against
and
what's
the
tls
version
you
know
cyber
suits
and
whatnot.
They
are
a
pretty
good
candidate
for
policy
attachment
and
there
are
no
core
or
extended
policy
attachments.
E
E
I
know
for
contour
like
we
are
absolutely
doing
it
and
you
know
in
http,
foxy
there's
ways
to
specify
all
the
things
that
you
would
want
to
specify,
but
that's
because
we
already
designed
the
thing
in
http
proxy
to
do
the
thing
that
we're
talking
about
designing
here
for
gateway
api
so
like
that
yeah
and
I
think
that's
the
yeah,
the
sort
of
thing
like
I
don't
like.
I
know
it
sucks
that
we
don't
have
a
good
answer
for
it
for
you
yet
but
like
if
there's
one.
F
E
C
D
C
Yes-
and
that
seems
like
it
could
be-
it
could
use
its
own
discussion
because
otherwise
I
think
it
may
get
buried
in
this
one,
so
maybe
starting
a
new
q,
a
basically
question
and
answer.
What
are
other
implementations
doing?
I've
seen
some
success
asking
in
slack,
but
you
might
have
a
little
bit
more
asking
and
to
get
a
discussion
or
both.
A
D
A
All
right,
so
we
got
a
couple
of
potential
action
items
we
can.
I
didn't
know
if
any
everybody
agreed,
but
I
put
in
here
that
we
could
include
that
specific
comment
as
a
motivation
in
the
in
the
gap
just
so
that
we're
tracking
it,
even
if
it
ends
up
in
alternatives
considered
or
something
but
thus
concludes
this
for
now,
and
we
will
follow
up
with
you
in
these
upcoming
discussions
and
gaps.