►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20200404
Description
SIG Network Gateway API Bi-Weekly Meeting for 20200404
A
I
know
nick
has
the
first
couple
things
on
the
agenda
today,
but
before
we
get
into
those,
I
wanted
to
just
highlight,
if
you're
new
to
these
meetings,
if
you
haven't
been
here
before,
welcome
first
off
but
also
just
anyone
and
everyone
is
welcome
to
comment-
ask
questions.
Some
of
us
have
been
working
on
this
project
for
a
while
and
and
forget
certain
details
that
may
are
likely
not
obvious
or
it
could
be
confusing.
So
please
chime
in
if
you
have
any
questions
or
thoughts
or
whatever.
B
That's:
okay!
No!
No!
It's
cool!
It's
cool,
so
yeah!
This
one
nathan
raised
this
thanks
for
raising
it,
nothing
about
in
the
in
the
context
of
the
conformance
tests
right
now,
the
conformance
test
when
you're
implementing
them.
We
don't
have
a
way
to
signal
to
objects
that
to
to
sort
of
consumers
that
the
that
this
configuration
is
fully
propagated
and
everything
is
good
and
you
can
run
tester
here
and
it
should
all
work.
B
And
I
think
we're
pretty
much
in
agreement
on
this
pr,
but
I
think
if
you
scroll
down
to
the
bottom
rob
nathan
raised
the
good
point
that
we
need
to
talk
about.
We
need
to
talk
about
like
ready
versus
accepted
versus
programmed,
but
somehow
that,
like
how
do
we
signal
hey
from
the
controller?
Hey
I've
done
everything
I
can
do,
I'm
sending
this
off
to
my
data
plane
and
you
at
some
point.
It's
going
to
be
ready
and
then
how
do
we?
You
know?
How
do
we
say?
B
B
I
think
the
original
plan
was
that
we
would
have
accepted
and
then
ready
which
is
and
ready
would
cover.
You
know,
hey
everything
is
good.
I've
sent
the
config
off.
Everything
should
be
ready
real
soon
now,
but
you,
I
think
that
evan
from
evan
raised
the
good
point
that,
from
from
kennedy's
point
of
view
they've
had
to
for
contour,
I
know
for
sure
they've
had
to
do
a
lot
of
things,
building
probing
logic
to
check
to
see
if
when
the
config
is
fully
propagated.
B
So
I
guess
the
question
I'm
trying
to
ask
here
is
just
to
you
know,
have
a
chance,
a
space
for
people
for
us
to
talk
about
this.
To
say
what
do
we
think
we
should
do
I'm
kind
of
of
the
opinion
that
having
ready
mean
ready
real
soon
and
yes,
you're
gonna
have
to
do
some
retries
with
exponential
back
off.
That's
kubernetes,
and
you
should
be
doing
that
anyway
is
sort
of
my
feeling
about
where
we
should
go.
But
I
have
to
be
talked
off
this
ledge.
B
B
A
A
B
E
Yes,
that's
true,
like
true
ready
condition
in
the
sense
where
it
is
propagated
to
you
know
every
thread
or
something
like
that
at
that
level,
I
think
it's
difficult
like
you,
one
can't
assume
that
something
has
been
posted
to
the
data
plane.
That
means
it
is
available
on
all
threads
or
processes
or.
E
Whatever
you
have
right
and
and
people
or
rather
implementers,
may
confuse
readiness
as
okay,
I
have
propagated
to
my
data
plane.
Now,
generally,
most
implementations
try
to
avoid
the
latency
when
a
configuration
shows
up
in
a
data
plane
and
the
moment
it
is
you
it
is
being
used.
For
you
know
proxy
traffic
that
is
generally
minimized,
and
most
users
should
not
you
know,
figure
like
most
users
should
not
be
bothered
by
it.
Considering
kubernetes.
E
B
Yeah,
I
guess
one
of
the
things
that
I
that
I
saw
someone
mentioned
was
like.
Maybe
we
just
have
our
you
ready
means
that,
but
when
you
see
this
condition
that
within
some
number
of
seconds
that
you
can
be,
that
you
should
be
confident
that
the
data
plan
is
programmed
because
practically
I
think
you
can't
at
machine
scale,
machine
time
scales
as
harry
says
like
it's,
you
can't
you
can't
be
sure
of
this.
B
B
D
You
know,
and
in
some
cases
like
the
gateway
controller
might
be
running
on
somebody's
cloud
infrastructure.
You
know,
but
you
know
so
example
contours
controller
or
you
know,
consoles
or
or
any
you
know
somebody
else's
might
be
running
on.
You
know
azure
or
aws
or
gcp
and
and
as
part
of
it
you
know
being
integrated
and
stuff.
D
We
may
you
know
that
software
may
program
some
part
of
the
cloud
service
and
you
know
so
it's
out
of
the
controller's
hand
at
that
point,
what's
ready
yeah
somebody
said
but
or
via
a
dns
update,
delayed
propagation?
That's
that's
absolutely
true!
So
there's
I
think
I
think
the
best
we
can
realistically
do
is
just
say
ready.
Is
the
system
is
ready
as
much
as
we
are
in
able
to
to
control
that
state?
You
know
it's
a
good
faith.
Best
effort
ready
my
two
cents
about
it.
A
I
so
I
agree
with
everything
that's
been
said
up
to
this
point.
My
only
nitpick
here
would
be
the
terminology
used,
I'm
hesitant
to
use
the
word
ready
to
describe
something
that
isn't
truly
ready,
or
we
can't
know
for
sure
is
ready.
I
would
prefer
something
that
is
more
descriptive,
maybe
programmed.
Maybe
a
word
like
that
that
describes
we've
sent
this
off.
A
This
is
configured.
This
is,
I
don't
know
what
the
right
term
is,
but
I
don't
think
that
figured
things
all
right
yeah.
So
I
I
don't
know
what
that
term
is.
I
don't
think
ready
is
quite
the
right
thing,
because
I
think
someone
seeing
ready
is
going
to
interpret
that
how
ready
is
interpreted
elsewhere
in
kubernetes,
for
example,
or
elsewhere
in
other
systems,
and
that's
not
what
we
can
guarantee
here.
G
B
G
B
Yeah
yeah
yeah
bowie
raises
the
point
that
committed
has
a
very
specific
meaning
in
the
sort
of
underlying
databases
right,
so
yeah
configure,
I
feel
like
configured,
probably
is
a
better
word.
There
I
mean,
let's
not
buy,
show
too
hard
on
the
name,
but
like.
I
think
that
I
think
rob's
point
is
fair.
That
ready.
Does
you,
as
chen
said,
it
kind
of
implies
like
ready
to
pass
traffic
right
now
as
soon
as
you
see
it,
and
if
we
can't
guarantee
that,
then
then
we
shouldn't.
B
Then
we
should
yeah
like
yeah
like
like.
Is
it
like?
There's
there's
a
lot
of
bike.
We
can
do
about
the
name
here
and
I
think,
but
I
think
that
the
key
thing
is
that
it's
the
two
things
that
we're
getting
out
of
this
conversation.
Are
it
shouldn't
be
ready,
because
that
has
a
specific
meaning
that
we
can't
get
that
we
can't
allow
for,
and
you
know-
and
it
should
be
some
other
name.
That
means
something
similar
to
that
that
the
control
plane
has
finished
its
work.
E
E
B
That's
a
that's
a
very
good
point:
harry
yeah,
all
the
all
the
all
we
could.
All
the
control
I
can
know
about
is
the
control
plane
right
like
unless
it
actively
goes
and
probes
and
does
other
stuff
it
feels
to
me
like.
Maybe
we
should
have
some
description
somewhere
in
the
documentation
about
conditions
where
we
say
like
we
have
specifically
not
included
already
condition,
because
many
implementations,
because
ready
means
many
informations,
find
this
difficult.
If
your
implementation
wishes
to
do
a
ready
condition,
then
it
must
mean
you.
B
It
must
be
used
to
mean
that
the
data
plan
is
completely
programmed
and
consistent
and
ready
to
pass
traffic
as
soon
as
someone
sees
that
condition,
or
something
like
that.
Just
just
to
disambiguate
this
completely
to
make
sure
that,
because
the
the
condition
design
is
such
that
people
can
add
their
own
conditions
right
like,
and
so
you
don't
have
to
only
use
the
conditions
we
provide
you.
So
we
need
to
say
if
you
want
to
use
a
ready
condition,
that's
cool,
but
it
must
mean
exactly
this,
and
only
this.
A
B
Yeah,
I
think
the
exact
nuances
of
the
name
are
like
are
going
to
be
fun
to
argue
about,
but
at
the
end
of
the
day,
the
most
important
thing
is
that
we
have
a
name
that
we
have
a
behavior
for
that.
We
all
agree
on
that.
Everyone
does
that's
in
this
book.
That's
the
most
important
at
the
end
of
the
day,
whatever
the
ma,
the
name
will
end
up,
meaning
whatever
we
tell
it
whatever
we
say
it
means
because
we'll
define
the
specter.
So
that's
what
it
means.
C
B
E
B
B
B
Yeah
yeah
yeah,
like
I,
was
trying
to
be
relatively
exhaustive
here,
because
I'm
worried
that
I
think
that
I'm
very
worried
about
doing
the
status
for
this
is
very.
It
can
be
very
easy
to
make
it
so
there's
something
that
we
can't
represent
in
the
status
and
so
so
yeah
like
this.
This
is
just
the
simple
cases
now
in
these
in
all
of
the
diagrams.
B
Here,
I've
used
two
two
like
routes,
so
so
this
is
a
gateway
gateway
here,
parent
route,
child
route,
okay,
so
parent
route
is
obviously
the
one
in
the
middle
trial
route
is
the
least
note.
So
I've
used
two
at
any
level
to
represent
an
arbitrary
number.
You
know
we've
got
zero
one
and
some
arbitrary
number
greater
than
one.
Obviously
it
wouldn't
be
arbitrary
size,
but
you
know
the
important
part
here
is
you
once
you've
got
two?
Then
you've
got
three
and
five
and
ten
and
stuff
like
that?
B
Okay,
so
we've
got
the.
These
are
the
easy.
These
are
the
easy
cases
right
like
you
know
where
you've
got
one
child
route,
one
parent
round,
one
gateway.
You
know
our
current
status
represents
this
easily,
because
if
the
child
route
has
a
parent
ref
that
has
the
status
of
the
parent
route
and
the
parent
route
has
the
status
of
the
gateway
rounds.
You
know
like
the
status
kind
of
works
already
what
we
have
same
for
all
of
these
ones,
where
you've
got
sort
of
multiple
child
routes
rolling
up
to
a
thing.
It
kind
of
works.
B
It's
not
going
to
work
perfectly,
but
it'll
kind
of
work.
However,
when
we
get
down
to
more
complicated
ones
which
are
there,
because
we
allow
multiple
parent
refs
you,
it
starts
getting
a
little
hazy.
You
know
so.
We've
got
a
single
parent
route
that
references
that
attaches
to
multiple
gateways,
single
parent
route,
that
attaches
multiple
gateways
and
has
multiple
children
and
then
the
opposite,
where
you've
got
two
parent
routes
that
attach
to
the
one
gateway
and
one
child
route
attaches
to
multiple
parent
routes
and
then
roll
up
to
the
same.
B
So
we
need
to
be
able
to
make
sure
that
we
represent
all
of
these
statuses
in
whatever
standard,
whatever
we
end
up
with
doing
the
status.
That's
the
purpose
of
these
diagrams
to
be
like
to
make
you
have
a
little
bit
of
a
headache
to
be
like
look,
we've
got
a
problem
here
that
we
need
to
represent
correctly
in
status.
D
I
was
going
to
say
I
actually
added
a
note
about
this
at
one
point
in
the
in
the
gap,
because
you
could
have
an
issue
where,
depending
on
what
information
you're
exposing
in
the
status
it
could
provide,
you
know
if
the
name
spaces
are
different
organizational
units.
It
could
expose
information,
that's
confidential
to
one
group
and
shouldn't
be
visible
to
the
another.
So
it's
gonna
be
a
challenge.
I
think,
to
figure
out
exactly
what
the
right
balance
is.
B
Totally
totally
okay,
so
I
have
concentrated
for
now
on
thinking
about.
You
know
what
we
need
to
be
able
to
do
to
make
sure
that
that
we
can
represent
all
the
possible
errors
that
I
could
think
of.
So
let's
talk
specific
things,
so
this
is
the
this
is
the
example
that
I
had
in
the
hack
md
earlier,
so
we've
got
a
http
parent
route
that
parents
to
gateway
a
and
gateway
b.
B
This
should
be
over
here:
okay
gateway,
a
has
a
hostname
that
allows
start.example.com
gateway
b,
has
a
host
name
that
allows
subdomain.example.com.
Http
parent
has
no
hostname,
but
http
child
has
test
domain
okay.
So
that
means
that
http
child
is
not
valid
for
attaching
to
gateway
b,
but
it
is
valid
for
attaching
to
gateway
a
right
now.
B
There
is
no
way
to
represent
this,
because
the
status
only
has
one
hop
status
so
like
http,
child
can
only
represent
its
status
with
respect
to
http
parent
and
as
far
as
the
http
child
history,
parent
relationship
has
done,
is
set
up.
You
can't
you
can't
say
hey.
This
doesn't
work
because
it
does
work
to
attach
to
who
should
be
parent
it
only.
It
only
does
not
work
in
reference
to
the
sort
of
inclusion
from
gateway
b.
B
Yeah,
so
so
what
I'm
trying
to
do
so
yeah
a
rule,
zero
that
I'm
trying
to
go
with
here
is
that
if
I'm
the
owner
of
http
child,
I
should
be
able
to
deduce.
I
should
be
able
to
understand
the
status
of
my
resource
by
looking
at
only
my
resource.
I
shouldn't
have
to
go
and
chase
down
the
http
parent
or
the
gateway
to
find
out
my
status
because
I
might
not
have
access
to
them
right.
B
B
What
I
originally
proposed
is
that
we
would
have
like,
and
so
this
is
what
the
this
is,
what
I
thought
it
would
look
like
originally
that
the
the
parent
would
actually
have
the
would
actually
fail
attachment,
because
you
know
the
the
child
route
doesn't
work,
but
then
I
was
like
well,
that's
pretty
bad
because
now
they're,
what
do
you
put
on
the
child
route?
There's
no
way
to
say
on
the
child
route
that
that
how
that
would
work
now?
B
I
wanted
to
contrast
that
with
this
case,
where
we
only
have
a
single
gateway
and
we've
got
a
parent,
a
with
startup
example.com
and
parent
b,
with
subdemand.example.com
and
a
child
with
test
domain,
and
so
if
we
do
that,
then
the
status
looks
pretty
straight.
What
we
have
already
with
the
parent
refs
it
works.
We've
got.
F
B
B
Okay,
okay,
so
in
the
case
that,
in
the
case
that
we
are
doing
the
parent
this
this
one
on
this
one
here,
where
we've
got
http
routes,
parented
by
a
gateway
and
then
a
child
route
parenting
to
two
things.
What
we
have
today
actually
works,
we've
got
the
two
parents:
they
get
an
accepted
one
because
they
are
accepted
on
to
the
gateway,
because
the
gateway
has
no
requirements,
the
yeah
and
then
the
child
one
gets
accepted
by
parent,
a
and
not
accepted
by
parent
b.
B
You
know
this
is
this:
is
all
pretty
standard
stuff
the
same
as
if
it
was
on
two
gateways.
So
what
we
have
here?
It
just
works.
So
what
I
am
thinking.
So
what
I'm
thinking
is
that
the
the
thing
that
I
came
up
with
was
you
know
I
was
like.
I
had
originally
an
idea
about
having
like
a
another
like
a
children,
a
thing
called
children
which,
as
someone
raised,
was
very
confusing
because,
like
you,
insider
parents,
you've
got
a
children
like
how
does
that
work?
B
B
We
only
have
we
only
allow
two
levels,
so
we
only
have
parents
and
grandparents,
and
so
then
that
means
that
for
the
final
status
you
have
to
look
at
the
grandparent
stanza
because
it's
been
included
and
then
the
grandparents
sort
of
effectively
gives
you
the
full
include
path,
no
matter
which
way
you
end
up
going
and
then,
if
there's
an
error
somewhere
in
that
include
path,
then
the
grandparents,
the
grandparent
status,
tells
you
exactly
where
in
the
include
path.
The
problem
was.
F
F
F
You
could
have
a
unique
status
for
every
path
from
where
you
are
as
a
child
to
the
the
forest
routes
right,
because
all
the
gateways
form
trees
of
themselves
and
then,
in
terms
of
like
how
we
like
consolidate
it.
It's
is
it
a
case
of
like
what
do
we
think
the
most
common
layout
is,
and
then
we
kind
of
consolidate
in
that
way.
It's
it's
sort
of
like
do.
Columns
first
come
first
or
rows,
come
first,
exactly.
D
F
A
And
so
I
I
think
the
what
nick
already
highlighted,
while
the
previous
example
highlighted,
is
that
for
most
cases
we
really
only
need
parents
like
that,
that
is
parent
status
is
what
we
are
going
to
use
for
99.9
of
use
cases
that
includes
route
to
gateway,
and
that
includes
route
to
route.
In
most
simple
use
cases,
I
think
where
you,
where
you
need
this
kind
of
grandparents
status
stanza
whatever?
Is
that
really?
B
There,
maybe
is
a
problem,
but
I
would
rather
er
on
the
side
of
having
the
the
ux
be
possible
for
the
this
is
complicated
enough
without
like
yeah.
We
need
to.
We
need
to
make
sure
that
we
allow
for
people
to
do
the
things
that
they
can
do
in
the
api
that
they
have
a
way
to
know
that,
whether
or
not
it's
worked.
C
F
I
think,
like
my
only
one
of
the
things
that
I
hesitate
with
the
grandparents
is
that
imagine
writing
the
code
to
process
this
like
to
show
it
on
some
ui.
If
you
have
just
pads
like
someone,
can
just
write
handling
for
like
like
such
and
such
path
like
status,
and
then
they
can.
If
path
is
structured,
they
can
crack
the
path
inside
it
to
see
like
okay.
Well,
this
is
this
parent
or
this
parent.
F
B
B
You're
going
to
be
just
pausing
the
path
specific
right,
you're
going
to
be
passing
the
path
in
the
same
way
that
you're
going
to
be
parsing,
the
the
parents
thing,
and
then
also
that
means
that
then
you'll
have
to
have
a
path
for
every
time
when
you're,
when
you
only
really
care
about
one
hop
right,
like
you're,
gonna
have
to
have
the
full
path
regardless,
and
that's
what
I'm
saying
I
think.
Well,
that's!
Okay!
B
B
This
is
going
to
be
more
important
important
if,
if
you
start
talking
about
a
non-gateway
terminating
like
root
nodes,
you
know
like
a
mesh
object
or
something
like
that
which
people
haven't
been
talking
about
already.
I
don't
know
if
people
would
want
to
do
non-gateway
route
objects
with
this
full
inclusion
thing,
but
if
they
do
then
like
this
also
handles
that
case
yeah
and
that's
what
the
thing
I
like
about.
This
is
quite
it's
actually
pretty
generic.
B
It
does,
as,
as
you
say,
very
you're
100
right
that
it's
a
bit
of
a
hassle
to
traverse
this
status,
object
and
rebuild
the
the
graph
that
was
used
to
get
to
it,
but
it
does
have
all
the
information
you
need
to
do
it
and
it
it's
basically
reusing
the
same
patterns
at
the
grandparents
level.
Like
you
could
pretty
you
could
almost
you
can
copy
all
of
the
fields
at
the
grandparents
level
from
the
field
on
the
parent.
B
F
B
Is
what
I'm
proposing,
because
now
that
the
first,
the
first
level
is
the
parent
of
your
direct
of
any
direct
parents?
You
have
and
then
the
grandparents
goes
underneath
that
parent
that
tells
you
these
are
the
grandparents
of
that
direct
parent
right.
So
if
you've
got
you
know,
I
didn't
even
put
it
in
here,
because
you
know
if
you've
got
this
one,
but
you
have
two
gateways
on
each.
You
know
or
you're
one
gate,
two
gateways
on
one
and
one
gateway
on
another.
Then
this
structure
still
works.
You
will
have
two
two.
F
F
B
So
in
all
of
these
examples,
I've
assumed
that
all
of
these
gateways
are
the
same
day
by
class
being
reconciled
by
the
same
controller.
However,
that
that
does
not
have
to
be
the
case.
That
is
the
reason
why
we
have
the
controller
name
field
at
each
level,
because
the
you
know
the
controller
name
says
this
is
the
controller
name
of
the.
F
B
B
B
In
that
case,
the
status
here
will
have
two
parent
refs
one
will
be
the
parent
ref
that
leads
up
to
gateway
one,
and
it
has
a
controller
name
of
gateway,
one's
gateway
class.
One
will
be
the
parent
parent
ref
that
leads
up
to
gateway
2
and
has
a
controller
name
of
gateway,
2's
gateway
class
with
the
class.
F
B
F
F
Most
of
the
time
you
just
have
one
path,
but
sometimes
you
have
like
two
pads
and
then
one
thing
we
also
want
to
consider
is
like
that.
Can
you
control
the
number
of
pads,
but
like
then,
like
writing
the
code
to
process
this?
You
just
have
to
look
at
like
path
and
if
you
care
about
the
actual
path,
then
you
can
look
inside
it.
Otherwise,
it's
just
like
looking
at
like
path,
status,
path,
status,.
B
So
that's
why
that
was
what
yeah.
So
in
my
mind,
you,
you
start
with
the
parents
to
be
like.
Do
I
care
about
this
parent?
You,
like
you,
start
you
basically
start
at
the
child
objects
to
build.
You
know
to
if
you're
processing
this
whole
thing
you
look
at
the
you.
You're
gonna
have
to
traverse
the
graph
a
couple
times,
no
matter
what
happens
right
like
because
you're
gonna
have
to
build
the
graph
you're
gonna
you're
you
as
someone
parsing.
B
This
whole
structure
are
gonna,
have
to
start
with
gateway
classes,
find
gateways,
find
routes
attached
to
gateways,
find
routes
attached
to
routes
and
then
to
parse
the
status
you're
gonna
have
to
take
that
graph.
You've
had
to
build
anyway
and
sort
of
work
backwards
from
the
child,
one
to
find
out
which
ones
are
relevant
and
which
ones
are
good.
B
But
you
know
if
you're
building
like
some
sort
of
management
ui
to
handle
this
sort
of
thing,
you're
gonna
have
to
do
a
downward
pass
and
then
the
status
works
on
an
upward
pass
so
like
that
means
that,
because
you've
already
done
a
downward
pass
by
the
time
you
get
to
the
children,
you
should
have
details
about
the
parents,
and
this
just
help
then
tell
then
lets
you
check
the
the
details
about
the
parents.
You
already
have
from
troubles
in
the
graph
yeah.
A
F
B
B
F
So
it
requires
a
bit
more
coordination.
Doesn't
it
because
the
middle
parent
ref
status
would
have
to,
they
would
have
to
sense
each
other,
and
then
they
would
have
to
go
down
one
more
level
to
to
know
that
it
wasn't
fully
attached
and
then
like
go
back.
I'm
just
trying
to
think
of
like
how
you
would
contract.
B
B
F
A
And
specifically,
it's
only
that
controller,
it's
only
so
for
contour
controller.
Everything
is
great
because
the
gateways
it
cares
about
are
doing
great.
With
this
route.
Let's
say:
istio
one
route
is
not
happy,
so
that's
partially
attached
or
something
like
that
or
not
accepted.
I
don't
know
what
the
appropriate
thing
is,
but
yeah,
but
but
all
of
these
are
are
very-
are
very
much
namespaced
by
the
controller
name.
For
a
reason,
and-
and
this
I
think,
yeah.
F
Yeah,
I
just
it
feels
very.
It
feels
not
as
symmetric
as
we
could
do,
because
you
have
like
controller
comma
parent,
comma
gateway,
whereas
really
it's
is
parent,
comma
gateway,
because
gateway
already
implies
a
specific
controller
in
some
ways.
It's
like
the
controller
thing
is
almost
like
an
extra
level
of
grouping.
B
Is
that
it's
expected
that
if
you
pick,
if
you
look
at
the
status
for
parents,
and
you
see
multiple
references,
you're
expected
to
go
through
and
find
the
ones
that
match
your
controller
name
and
put
the
other
ones
back
like
you,
don't
you
patch
you
patch,
only
the
ones
that
have
your
controller
name
in
them.
You
don't
clear
anything
else
right.
It's.
F
I
see
and
we
we
accomplish
that,
because
we
label
in
the
kubernetes
api
that
that's
like.
Yes,
I
don't
know
what
I
remember
what
it's
called:
it's
like
independently
updatable
list
or
something
so
I
I
do
have
a
question
like.
Do
you
have
controller
name
under
grandparents
as
well
as
controller
name
at
the
top?
I
do
yeah.
It's
probably.
B
So
there
are,
I
left
the
fields
in
there
because
I
wanted
to
be
able
to
talk
about
this,
but
you're
right,
it's
probably
redundant,
because
because
it's
implied
by
that
one,
like
you
can't
have
a
controller
named,
be
different
at
those
different
levels.
It
has
to
be
the
same
all
the
way
down,
so
it
it's
actually
confusing
to
have
that
there
and
we
should
actually
take
it
out.
That's
much
better
but
but
like.
B
I
think
that
the
the
structure
of
having
parents
and
then
grandparents
that
feels
to
me
like
while
you
I
see
what
you're
saying
that
that
having
something
I
guess,
what
I'm
saying
is,
I
don't
see
how
you
would
have
like
any
structure
that
you
have
is
going
to
end
up.
Looking
a
little
bit
like
this.
The
thing
about
this
one
is:
the
structure
works
from
the
bottom
up
rather
than
working
from
the
top
down,
and
it
feels
like
what
you're
doing.
F
B
F
F
Parent
point
of
view
I'm
saying
on
here:
you
have
a
parent
ref
and
a
status
attached
to
that,
and
then,
additionally,
you
have
a
grandparent
ref
and
a
status
attached
to
that
like
is
there
such
like?
What
do
you
do
with
those
two
and
like
wouldn't
the
user,
just
care
about
for
my
given
path
like
did
it
work?
F
B
I
mean
so
the
the
point
being
here
that
if
you've
made
a
mistake,
so
the
intermediate
information
is
for,
I
attempted
so
remember
that
the
the
way
that
this
attachment
works
is
that
the
owner
of
the
child
route
says
I
want
to
attach
to
parent
route.
The
owner
of
the
parent
has
an
allowed
route
stanza
that
says
whether
or
not
that
child
route
will
be
allowed
to
attach.
F
D
B
F
F
D
You
do
need
to
know
that
you
know
whether
you
know
so.
You
need
to
know
whether
you've
been
able
to
attack
as
a
child
you've
attached
to
the
parent
or
not,
and
then
that
parent
has
it
attached
to
the
you
know
any
of
the
gateways
or
the
listeners
that
it's
supposed
to
attach
to
has
it
has
successfully
attached
to
those.
I.
F
B
Yeah
yeah,
so
that's
actually
comes
on
to
it.
I
think
another
thing
that
I
was
gonna
talk
about
that
yeah.
I
think
there's
a
couple
of
there's
a
couple
of
related
things
there,
but
so
I
just
just
before
we
move
on
to
that
thing
boy,
because
that's
a
slightly
separate
issue,
the
so
what
you're
kind
of
saying
is
you
feel
that
it's
just
it's
the
fact
that
we
have
two
steps
here
of
status
you
would
like
to
see.
F
Like
the
yeah,
I
just
maybe
it's
even
just
at
a
conceptual
level
like
at
the
end
of
the
day,
there's
like
this
hyper
matrix
or
whatever
like
where
it's
like.
The
paths
on
one
column
or
sorry,
fully
demoralized
like
thing
was
like
path,
comma
status
or
is
it
path,
comma,
a
list
of
status
where
it's
like
the
status
corresponds
to
the
path
and
then
right
is
like?
Is
that
meaningful
or
is
it
like
literally
like
each
node
in
the
graph
that
you
have
has
its
own
status
and
it's
like
common?
I
guess.
B
I
don't
know
like
a
function
of
the
of
the
individual
nodes,
and
I
think,
that's
important,
because
I
have
specifically
structured
these
examples
in
a
certain
way,
because
I
think
that
there's
another
thing
that
I
wanted
to
skip,
but
that
we
need
to
talk
about
now.
If
you
look
in
this
parent
route,
I
have
an
allowed
routes,
but
also
a
back
end
refs,
because
I
wanted
to
avoid
the
question
of
what
happens
if
you
have
allowed
routes
and
there
are
no
routes
attached.
What
is
the
status
of
the
of
this
route
then?
B
So
that
is
this
graph
I
put
down
here
you're
like
when
you
have
this
and
you
have
a
parent
that
has
no
config
of
its
own.
It
has
no
back-end
refs.
What's
the
status
of
that
parent,
is
it
attached
successfully
or
is
it
not
attached
successfully?
You
know,
and
is
the
fact
that
it
generates
no
config
an
error
or
not
an
error
in
my
mind.
So
I
this
is.
This
is
one
of
the
questions
I
want
to
ask
you
all
yeah
I
will.
B
F
D
Loaded,
I
guess
you'd
say
into
the
system
in
any
particular
order,
and
you
know
they
may
be
created
at
different
times.
You
know
days
weeks
months
apart
and
constantly
changing,
so
I
think
you
you
have
to
maintain
some
kind
of
some
kind
of
status
that
says
yeah
that
the
parent,
as
it
exists,
can
successfully
attached
to
me.
D
There's
nothing
preventing
it
as
it
is
right
now,
and
you
know
it's
not
doing
anything,
it's
not
contributing
anything
to
the
listener's
routing,
but
then
at
some
point
a
child
may
attach
to
it
to
that
parent
and
yes,
it
does
otherwise.
You
could
look
at
a
you'd,
be
looking
at
a
parent.
You
should
be
saying:
why
is
it
not
attaching
to
the
gateway?
Is
it
because
it's
there's
some
problem
or
is
it
because
it's
got
nothing
contributing
to
its
config?
You
have
to
start
figuring
out
what
what
your
issue
is.
B
A
B
B
You
know
you're
attached,
but
there's
nothing
but
you're
not
do
it,
but
it
doesn't
do
anything
right
like
so
that
you
could
people
have
a
way
to
know.
Yes,
you
attached,
okay,
but
hey
your
config,
isn't
doing
anything.
That's
really
important,
because
if
you
have
sorry
this
case
say
the
this
case
here
and
for
some
and
for
some
reason
this
child
could
not.
B
Let's
talk
about
a
bit
yeah
this
case
and
for
some
reason
this
child
cannot
attach
to
the
parent
route.
Then
the
parent
route
needs
to
be
needs
to
stay
attached
to
the
gateway
and
so
like.
I
think
that
the
rule
that
we
need
to
have
is
things
can
attach,
but
if
there's
no
config
present,
then
then
they'll
they'll
tell
you
in
the
in
their
attached
status.
B
B
D
B
The
other
reason
I
made
these
graphs
is
that
I
think
that
we
might
need
to
include
some
graphs.
Some
pictures
like
this
to
when
we
start
talking
about
the
status
in
the
gap
itself,
to
make
it
clear
what
we're
talking
about.
I
think
the
examples
are
not
nearly
as
clear
as
having
something
that
looks
like
this
yeah.
This
is
great
thanks.
A
A
I
think
nick
mentioned
it
earlier,
but
we
have
formally
requested
api
review
for
v0.5.0,
which
will
include
v1
beta,
1,
graduation,
hopefully
of
gateway,
class
gateway
and
http
route.
I
there
are
a
few
things
open
still
in
our
milestone.
Most
of
them
are
related
to
the
web
hook
and
documentation.
As
per
usual,
you
notice
that
we're
seeing
a
few
more
of
these
icons
indicating
that
we
have
prs
ready
for
a
chunk
of
the
issues
left
in
the
milestone.
A
But
if
you
see
things
that
are
left
open
here,
that
still
have
not
been,
you
know
have
not
had
someone
assigned
there's
a
few
of
them,
and
you
have
some
extra
cycles
by
all
means.
Take
some
time
to
to
work
on
these
and
assign
yourself
we
can.
We
can
appreciate
any
any
additional
contributions
to
get
us
through
through
to
v1
beta
1..
I
know
we're
all
looking
forward
to
that
release.
With
that,
I
really
wanted
to
highlight
pull
requests.
A
I
think
we
have
more
pull
requests
now
than
I've
ever
seen,
yeah
at
least
active
open
ready
for
review
in
this
project.
So
thank
you,
everyone
for
great
prs,
but
for
anyone
who
wants
to
review
there
is
more
material
available
for
you
than
has
ever
existed
so
enjoy
jeff.
I
want
to
highlight
your
pr
here.
That's
yeah
1085.!
F
A
One
more
that
I
wanted
to
highlight
is
by
ciao
down
here.
This
is
1082..
I
I
approve
this
one,
but
I
wanted
someone
else
to
take
one
more
look
at
it.
I
think
here
you've
already
comment
on
it
as
well,
but
this
is
just
the
docs
pr
for
port
and
parent
ref.
I
think
it's
pretty
straightforward.
I
think
this
one
may
be
one
of
the
closest
pr's
to
get
ready
to
go.
So
if
anyone
has
time
this
is
1082,
and
I
should
while
we're
here.
B
I
think
the
the
we've
got
a
few
performance
test,
ones
that
that
we
need
to
make
sure
we
that
we
get
in
the
you
know,
yeah.
I
think,
there's
some
discussion
on
the
cleanup
one,
but
I
think
this
supported
vegetable
consistency
and
performance
tests.
This
will
make
everyone's
life
actually
implementing
the
performances
much
easier.
I
haven't
reviewed
it
yet,
but
I
will
today
yeah.
I
think
that
absent
the
discussion
about
the
the
ready
condition
this
is.
This
is
probably
finally
going
personally.
B
A
Last
I
checked
this
was
right
on
track.
I'd
seen
a
few
comments
from
different
implementers
saying
that
this
made
their
their
test
runs
green
instead
of
somewhat
flaky,
which
is
great
news
all
the
way
around.
So
thanks
to
nathan
for
taking
this
one
on.
This
is
highly
related
to
that
conditions.
Conversation
you
had
earlier,
but
I
I
personally
agree.
This
is
awfully
close.
I
just
need
to
take
one
more
look
too
cool
the
other
conformance
test
this.
This
is
a
big
one
is
for
reference
policy.
A
A
I
mean,
I
think,
we're
almost
getting
to
the
point
where
we
need
feature
gate
like
things
to
describe
features.
Yes,
yes,
so
excited
for
whoever
wants
to
lead
that
discussion
proposal
whatever,
but
I
wholeheartedly
agree
we
need.
We
need
a
good
way
to
describe
what
a
gateway
class
is
capable
of
handling,
and
that
is
not
currently
in
the
api.
B
Point
just
going
back
to
the
milestone
list.
I
have
a
bunch
of
issues
assigned
to
me
that
there
I
have
like
yeah
a
week
or
so
until
I
go
on
annual
leave
and
then,
when
I
come
back,
I'm
gonna
be
home
for
like
two
days
and
then
turn
around
and
go
to
kucon.
So
I'm
not
going
to
have
a
lot
of
bandwidth
in
the
next
while
so
I
will
probably
concentrate
on
writing
up
what
I
think
we
should
do
in
those
issues
and
then
unassigning
myself.
B
So
there's
definitely
a
bunch
of
documentation
and
a
bunch
of
like
simple,
relatively
simple,
tooling
stuff
to
do
like
around
building
out,
manifests
and
and
a
bunch
of
other
stuff
that
kind
of
need
to
graduate
to
beta
but
are
not
like
heavy
coding
or
heavy
design
work.
So
I
will
try
and
write
those
up
and
hand
them
off
to
other
people
rather
than
trying
to
do
them
myself.
A
Great
thanks
for
the
heads
up,
I
think,
there's
one
more.
I
wanted
to
selfishly
highlight
one
of
my
prs
that
kind
of
got
lost.
This
is
the
versioning
and
web
hook
docs
from
a
couple
weeks
ago,
I
went
through
and
responded.
There
was
great
feedback
from
a
few
of
you
on
here.
I
finally
got
time
to
respond
to
all
of
it,
so
it
just
needs
one
more
round
of
review
and
hopefully
we
can
get
it
in
soon.
A
This
is
the
reason
I
care
about.
This
is
it's.
You
know
one,
it's
one
more
thing
for
the
milestone,
but
two
it
helps
explain
things
to
our
api
reviewers,
who
will
for
sure
have
questions
about
release
channels
about
our
versioning
approach,
all
that
fun
stuff.
So
getting
this
in
just
helps
with
that
so
yeah.
This
is
1066.