►
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
All
right
we're
recording
it
is
august
27,
and
this
is
service
api's
meeting
we've
got
plenty
to
get
through
today.
I
did
not
outline
the
pr's
or
issues
that
we
should
cover,
but
there
are
plenty
if
we
have
time
for
them,
but
first,
as
per
always,
I
want
to
take
a
little
bit
of
time
to
revisit
the
v1
alpha
checklist.
A
I've
added
some
more
detail
here,
and
I
think
this
is
now
up
to
date.
But
definitely
let
me
know
if
I'm
missing
anything
I've.
One
edition
that
I've
added
here
in
the
past
day
is,
I
included
udp
route
in
the
scope
for
v1
alpha
1..
A
That's
because
you
know
it
wasn't
something
that
absolutely
needed
to
get
in,
but
I
think
all
the
comments
have
been
resolved.
It's
got
an
lgtm
from
me
now.
Anyone
else
is
welcome
to
take
a
look,
but
I
think
it's
pretty
close.
I
wanted
to
add
it
just
so
we
were
tracking
it.
A
I
also
noted
other
prs
that
are
nearly
done
and
have
at
least
one
lgtm
to
give
a
better
idea
of
our
progress
here.
So
in
this
case,
you
can
get
an
idea
that
we
have.
You
know,
although
we're
not
able
to
move
any
of
these
high-level
topics
to
done
quite
yet
for
a
lot
of
them.
I
think
for
all
of
them.
They
either
have
prs
that
are
ready
for
review
lgtm
or,
if
not,
that
a
document
that
is
ready
for
review.
So
I
think
we're
making
some
great
progress
here.
A
Yeah.
Thank
you
to
whoever's,
adding
that
we
do
still
need
review
on
tls
route.
So
yes,
and
hopefully
we
can
get
to
that
and
issue
triage
again.
If
you
see
anything
in
here
that
is
not
well.
If
you
don't
see
anything
in
here
like
if
there's
something
that
should
be
part
of
you,
one
alpha
one
that
isn't
definitely
let
us
know
we
can.
We
can
get
it
in
here
and
make
sure
it's
tracked,
but
I'm
feeling
reasonably
good
about
our
progress
here.
A
Obviously,
you
know
it's
august
27
at
this
point,
so
the
dream
of
an
august
v1
alpha
one
release,
probably
is
not
going
to
be
the
case,
but
I
feel
like
we
are
awfully
close
and-
and
I
really
really
would
love
to
get
this
get
this
out
in
the
next.
I
I
hate
to
give
a
specific
time,
but
a
couple
weeks
I
don't
know,
but
quite
soon
it
seems
like
we've
got
some
really
great
progress
here.
I'd
hate
to
I'd
hate
to
see
it
slow
down.
A
That's
I
think,
that's
all
I'm
going
to
say
here:
we've
got
lots
of
other
things
to
get
through
and
not
a
ton
of
time,
so
I'll
keep
on
moving.
Unless
anyone
has
anything
else,
they
want
to
say
as
far
as
v1
alpha
1
timing.
B
B
A
We
should
prob.
I
did.
I
have
not
looked
at
issues,
but
if
there
are
issues
that
we
feel
belong
in
the
v1
alpha
1
milestone,
we
should
probably
do
that
as
well.
A
Yeah,
thanks
for
bringing
that
up
here,
cool
all
right,
james
yeah
you're
here
I
know
you
you'd
already
presented
this
I've
gotten
a
chance
to
look
through
this.
A
D
Am
I
talking?
Yes,
we
can
hear
you,
oh
good.
Sorry,
I
just
wanted
to
be
sure.
So,
basically,
I
think
the
state
we're
in
at
the
moment
is
we
have
we
have
these
set
of
condition
types
and
I
think
we've
been
thinking
about
them
more
as
as
error
flags.
D
D
D
Rob
in
one
of
the
comments
pointed
out
that
we
also
have
gateway
classes
and
routes
which
I
totally
forgot
about
so
conditions,
I
think,
are
really
underlying
states
right.
So,
when
you're
thinking
about
our
conditions,
you
think
well,
okay,
what
are
the
underlying
states
that
are
going
to
be
general
across
different
implementations
and
different
controllers?
And
what
is
what
does
the
controller
really
have
to
do?
And
then
is
that
a
kind
of
a
useful
state
to
expose
in
sort
of
an
abstract
model?
D
So
when
we're
talking
about
gateways
the
way
I
thought
about
that
was
well,
we
have
a
gateway,
and
we,
this
gateway,
is
this
link
between.
Is
this
request
for
some
underlying
load
balancing
resources?
So
when
we
created
a
gateway,
but
we
don't
have
the
underlying
resources
for
it
to
instantiate
it,
then
it's
kind
of
in
this
pending
state,
so
we've
always
been.
I
know
one
of
the
words
one
of
the
terminologies
bowie
has
introduced
from
the
start.
Is
this
idea
of
scheduling
a
gateway?
D
So
we
have
this
notion
of
a
gateway?
That's
not
that's
pending
because
it
hasn't
been
scheduled.
Yet
then
we
have
ready
right,
because
ready
is
the
only.
D
D
I
think
there
was
a
question
yeah,
so
dipto
asked
whether
readiness
implies
a
health.
A
health
check
you
know
does
ready
to
imply
that
this
thing
is
passing
health
checks.
Maybe
there's
a
lot
of
wiggle
room,
for
I
think
quality
of
implementation
issues
here
so
gateway.
A
Yeah
sorry,
I
just
I
had
I
had
a
follow-up
question
here
now.
Maybe
this
is
a
broader
question,
but
are
these
conditions
that
would
always
be
present?
I
know
right
now
because
our
conditions
have
traditionally
just
been
error
states.
They
only
show
up
when
there's
an
issue,
and
I
think
what
you're
talking
about
is
maybe
conditions
that
are
always
present.
D
E
D
Everything
about
every
every
rule
about
conditions
is
violated
by
multiple
things
all
at
once,
but
if
you
look
at
pods,
then
like
the
pod
conditions
are
persistent,
so
you
because
the
underlying,
because
the
conditions
reflect
kind
of
underlying
an
underlying
state
model
which
isn't
strictly
a
state
machine,
but
it's
a
little
bit
more
abstract
than
a
state
machine.
I
think,
but
there
are
like
states.
D
So
it's
not
it's
it's
not
a
so
I
think
the
condition
is
used
in
a
way
where
it's
not
a
conditional
like
a
branch,
but
it's
a
condition
as
in
a
state
of
being
and
it's
a
state
of
being
not
necessarily
a
state
of
transition
which
would
which
we
usually
talk
about.
If
you
were
talking
about
a
state
machine,
so
you
know
on
a
pod,
you
have
this
persistent
condition
of
being
out
of
memory
or
not.
So
you
can
always
look
at
a
pod
and
go.
Are
you
at?
D
Is
the
out
of
memory,
condition
true
or
false
right?
And
that's
the
way.
I've
kind
of
that
and
that's
the
sort
of
vocab
thing
I've
approached
here.
So
we
can
say
you
know
it
makes
sense
for
us
to
have
a
condition
scheduled
or
a
negative
condition
pending
right.
So
we
can
say
that
this
thing
is
no
longer
pending
and-
and
it
makes
sense
to
have
that
as
a
permanent
thing.
A
Yeah-
and
I
think-
and
maybe
this
is
probably
just
me,
but
if,
if
a
condition
is
always
going
to
be
present,
I
think
I
slightly
prefer
the
positive
polarity
instead
of
the
negative
polarity,
just
in
the
sense
that
at
least
to
me
the
idea
of
a
condition
with
pending
an
estate.
False
is
less
obvious
to
me
than
a
condition
scheduled
and
a
you
know
true
scheduled
true
versus
ending
false.
A
D
D
Okay,
so
so
conflicted,
for
example
like
right.
So
if
you
look
in
the
listeners,
you
have
this
conflicted,
you
have
this
conflicted
condition,
and
you
say
well
this
poor,
so
you
would
say
well,
this
port
is
conflicted
right
and
when
conflict
is
true,
that's
bad,
so
it
has
negative
polarity
and
at
least
to
me
as
a
as
an
english
reader
conflicted.
E
False
I
mean
the
whole
conditions
thing
originally.
Was
that
like
it's
like?
Are
you
sick?
No,
and
then
you
could
write
a
generic
loop
that
didn't
know
about
all
the
potential
conditions
that
could
happen
and
if
you
have
no
conditions,
you're
healthy,
that's
basically
where
the
negative
thing
came
from.
E
I
don't
know
like
given
how
it's
kind
of
a
mess,
and
it's
not
consistent
that
that
you
can't
even
make
that
assumption
anymore.
But
if
we
wanted
to
go
negative
then
you
might
want
to
allow
for
such
a
thing.
It's
basically
that
the
whole
you
can,
since
it's
an
open
type,
an
open
enum
so
like
you,
can
handle
it
and
upgrade
without
having
to
know
about
a
set
of
all
conditions
period.
D
Yeah,
so
the
only
library
I'm
aware
of
that
tries
to
do
this
in
a
generic
sense
is
the
k-status
library
I
think,
every
other
project
that's
tried
to
tackle
the
general
concept
of
readiness
for
resources
has
just
gone
and
said:
here's
the
10
resources,
core
resources
I
know
about-
and
I
have
rules
for
those
case
status-
follows
the
api
consistency
guidelines
and
it
looks
it
ready,
especially
and
then
any
other
condition.
D
If
any
other
condition
is
true,
then
it's
it
considers
the
resource
to
be
in
some
sort
of
error
state.
D
So
part
of
the
reason
why,
pending
equal
way,
pending
is
kind
of
a
weird
one,
is
that
scheduled
kind
of,
I
think,
seems
nicer
to
to
english
speakers.
I
think
scheduled
is
more
recognizable
word,
and
I
think
that
I
haven't
found
a
pending
is
the
best
antonym
for
schedule
that
I
could
come
up
with,
but
I
think
people,
I
think,
you'd
feel
differently
about
it,
based
on
whether
you
choose
the
right
answer.
D
So
a
lot
of
the
problem
here
is
a
lot
of
the
problem
in
getting
the
right
vocabulary
here
is
is
just
choose,
is
just
being
able
to
choose
the
words
really
really
carefully
so
that
it
seems
like
that
makes
sense.
So
it's
less
of
a
programming.
Let's
have
a
programming
api
problem,
then
it
is
like
a
a
problem
of
aligning.
You
know
connotations
for
english
speakers.
D
But
the
reason
that
the
I've
tried
to
make
a
fairly
small
number
of
top-level
condition
types
on
the
basis
that
they
would
be
persistent
right.
So
if
you
have,
if
you
have
persistent
conditions
which
can
be
either,
which
would
change
to
be
true
or
false,
depending
on
the
underlying
depending
what's
going
on
underneath,
then
you
don't
want
to
have
you
know
50
conditions
permanently
there.
D
You
want
a
small
number,
so
you
want
a
small
number
of
kind
of
underlying
states,
and
then
you
want
to
qualify
them
with
with
some
kind
of
more
specific
reason
and
because
you
only
in
general,
what
you're
supposed
to
do
with
conditions
is
you're
supposed
to
use
a
list
map
so
that
it's
a
array,
but
each
condition
type
would
only
be
allowed
to
appear
in
the
array
once
which
means
that
if
you're,
if
you
have
a
so
listener
condition
detached,
you
can
only
have
that
in
there
once,
which
means
that
the
reasons
within
that
should
be
kind
of
orthogonal
right.
D
Yeah
but
I
it's
it's
kind
of
a
little
bit
iffy
with
listeners,
because
sometimes
you
want
to
say
the
same
thing
because
listen
that,
because
we
have
these
arrays
and
we
have
other,
we
have
fairly
complex
objects.
And
sometimes
you
want
to
say
the
same
thing,
but
for
two
different
parts
of
two
different
parts
of
the
resource.
E
D
Yeah,
it's
pretty
hard
to
programmatically
respond
to
conditions.
I
think
you
can.
You
can
look
at
that.
I
mean
you
can
look
at
the
ready
they
type
and
the
reason
and
that's
really
about
it.
E
D
Yeah,
if
we
have
kind
of
complex
state
that
we
want
to
expose,
then
we
should
have
other
top
level
status
fields,
but
I
don't
think
we
have
that
and
conditions
is
kind
of
okay
for
exposing
these
things
broken
or
this
thing's
not
not
working
yet
or
there's
some
sort
of
problem.
E
Yeah,
I
imagine
like
that
thing
is
basically
the
top
level
status
and
then
we
would
do
more
complicated
stuff
as
structures
in
status.
D
A
Yeah,
that
makes
sense-
I
you
may
you
may
have
already
covered
this,
but
you
know
at
least
for
for
this
conflict
status.
Specifically,
it
feels
like
it's
possible
for
all
of
these
to
be
the
reason
in
that
case,
would
it
just
be?
You
know
some
kind
of
order
of
operations
you
check
pro
first,
if
that's
in
conflict
you
don't
even
check
the
others
and
as
the
implementation,
you
just
say
that
that's
the
reason
and
if
you
fix
that
you
check
for
the
next
potential
conflict.
D
Yeah
we
end
up
with
the
same
sort
of
awkwardly
linear
behavior,
with
the
disconnected
refs
condition
where
you
can
have
you
know,
certificate
routes
or
some
other
of
the
forbidden
routes.
Right,
there's
like
three
different
reasons,
which
in
theory
in
principle
at
least
a
controller,
could
know
about
all
of
those
conditions.
F
A
D
Yeah
yeah,
presumably
I
mean
one
of
the
and
you
meant
you
said
the
word
in
force,
which
brings
me
to
also
that
I
think
in
general.
What
I
would
suggest
with
these
is
that
we
we
don't
enforce
validation
for
the
type
names
or
reasons
so
that
we
allow.
A
Own
yeah
that
makes
sense
and
yeah
it
yeah.
That
all
seems
reasonable.
Do
you
think
you
know?
I
think
we
don't
need
to
validate
this
necessarily,
but
maybe
we
would
want
to
have
some
kind
of
conformance
testing
to
ensure
that,
if
say,
there's
a
hostname
conflict
or
or
something
like
that
that
that
status
condition
is
applied
by
a
controller.
Is
that
too
far
for
conformance.
D
Yeah,
I
think,
if
there's
only
if
I
mean
for
conformance,
if
there's,
if
only
one
of
those
reasons
is
possibly
true,
then
I
think
the
implementation
should
reasonably
publish
that
particular
reason
in
maybe
the
probably
at
what
area,
where
it'd
be
a
little
bit
low,
to
have
conformance
requirements
as
if
you
make
multiple,
if
you,
if
you
create
a
configuration
where
more,
where
there's
a
protocol
conflict
and
a
hostname
conflict,
I
don't
know
if
we
should
really
require
implementations
to
do
things
in
a
particular
order.
Like
you
mentioned
before,
yeah.
A
A
I
would
imagine
that
listener
would
get
that
condition
of
hosting
conflict,
but
the
gateway
as
a
whole
would
still
remain
in
a
state
of
pending,
false
and
and
ready
true
right.
So
so
it
would
just
be
one
specific
error,
but
everything
else
is
working.
A
D
Yeah,
I
I
mean
personally,
I
think
that
I
think
that
I
think
that's
okay,
you
could
also
you
could
also
publish
yourself
as
ready
with
listeners,
not
ready
or
listeners.
Not
this
is
listeners
not
valid.
I
think
both,
I
think,
all
kind
of
three
of
those
options
would
be
acceptable.
D
E
Yeah,
I
think,
like
ready,
probably
means
that
go
look
at
the
more
specific
stuff.
So
if
like
there's
no
conditions
that
are
negative,
then
everything's.
Okay,
if
you
have
some
conditions
that
are
negative,
then
it
depends
on
the
scope
of
each
negative
thing
and
if
the
whole
thing
is
not
like
overall,
it's
negative,
then
you
shouldn't
have
any
expectations.
E
D
D
Yeah,
so
that's
we
have
ways
to
so.
We
have
ways
to
express
the
partial
states,
so
you
you
could
see.
So
you
could
have
one
way.
One
thing
you
could
do
is
you
could
say
that
the
gateway
is
ready
and
everything
in
the
gate
and
the
gateway
ready
condition
is
true,
but
then
in
the
listeners
you
could
say
well,
the
listeners
have
dropped
routes
and
you
wouldn't
really
have
to
make.
You
wouldn't
really
have
to
cause
that
to
be.
D
E
Yeah,
I
think
like
maybe
we
do
need
a
rule,
though,
that
if
the
gateway
overall
is
not
ready,
then
probably
all
the
underlying
conditions
either
are
irrelevant
or
should
be
deleted
or
something
I
don't
know
like
like.
Let's
say
some
of
them
are
okay,
conceivably,
they
could
be
stale
like
what
happens
in
that
situation.
E
D
D
B
D
That
bo
is
describing
where
you
don't
really
have
any
underlying
you,
don't
necessarily
have
any
underlying
listener.
There's
no
conditions,
maybe
in
the
case
where
some
of
your
listeners
are
good
and
some
are
some
are
bad.
Then
that
could
be
depending
on
your
list
depending
on
what
went
wrong
with
your
listeners,
then
that
could
be
okay
or
not
so
this
in
in
the
actual
text.
For
the
reasons
for
the
gateway,
readiness,
I've
sort
of
put
the
line
at
listener,
you
kind
of
want
to
know
listeners
is
the
listener
like
syntactically.
Okay,
you
know.
D
Is
there
some
sort
of
like
fundamental
syntax
problem
with
my
listeners
and
and
have
my
listeners
been
provisioned?
There's
two
things
to
make
it
ready,
but
those
things.
A
Well,
what's
what's
required,
what
what
do
you
think
are
the
next
steps
here?
Do
you
need
more
feedback
on
this
doc
or
do
you
think
we've
got
enough
feedback
here
and
you
want
to
move
this
to
a
pr.
D
I
think
the
primary
thing
is
we
need
to
kind
of,
as
a
group
probably
decide
whether
we're
going
to
do
the
positive
or
negative
polarity
some
of
the
some
of
the
names
I
like
better
in
positive,
some
of
them
names
I
like
better
in
negative,
but
clearly
I
think,
that's
the.
I
think
I
think
that's
the
big
one
right
are
we
going
to
be.
Is
it
going
to
be
positive
or
negative
polarity
names,
and
then
we
can
iterate
on
those
specifically.
C
James,
have
you
referenced
other
projects
that
have
standardized
enough
polarity,
or
is
it
common
for
projects
to
have
a
mixed
polarity.
D
It's
kind
of
all
over
the
place
a
bit
some
place.
Some
projects
which
have
standardized
have
standardized
on
positive
polarity,
so
k
native
and
I
believe,
controller
runtime
no
cannot.
B
C
All
right-
and
the
reason
I
ask
is
that
if
it
is
uncommon
that
projects
standardize
in
a
polarity,
maybe
it
does
make
sense
to
have
a
mixed
polarity
and
the
reason
I
say
that
is
status
conditions
you
know
are
meant
for
humans
to
read,
and
it
should
be
easy
for
someone
to
look
at
the
status
conditions
and
understand
what's
going
on,
and
if
that
means
that
we
should
have
mixed
polarity
to
achieve
that
goal,
then
maybe
that's
the
best
course
of
action.
D
I
have
a
lot
of
sympathy
for
the
idea
that
status
conditions
that
you
should
be
able
to
you
know
naturally
read
them,
although
that's
a
very
kind
of
native
english
speaker
centric
point
of
view
that
what
what
what
feels
natural
to
people
and
you're
right,
that
there
is
a
lot
of
there-
is
this
concept
that
that
status
is
for
humans,
but
I'm
not
sure
that
that's
a
kind
of
a
coherent
concept,
because
I
think
that
if
you
have
an
api
and
you're
saying
that
your
api
can
only
be
interpreted
by
like
a
human
at
the
desk,
is
that
like
it
doesn't
really
feel
like
an
api
right?
D
C
C
You
know,
because,
no
matter
how
difficult
it
is
to
understand
it's
like
okay
from
a
machine
standpoint,
it's
like
okay.
This
is
what
it's
supposed
to
mean,
let's
program
it,
but
from
a
human
standpoint,
if
you
know
probably
the
easiest
way
to
program
humans
is
just
to
make
it
as
easy
to
understand,
and
I
don't
know
maybe,
as
you
mentioned
it's
a
language
thing,
but
I
know
I
I
you
know.
I
spent
a
lot
of
my
time.
Troubleshooting
cluster
issues
and
status
conditions
are
a
big
part
of
what
I
use
for
troubleshooting
and.
C
Yeah,
so
you
know
from
the
human
side
of
programming
it
it
does
for
me
it
does
help
to
have
you
know
these
status
conditions,
human
readable,
easy
to
understand-
and
I
know
at
least
from
users
that
I've
worked
with
I've
kind
of
heard,
the
same
feedback
as
well.
D
The
one
thing
that
I
think
that
you've
nailed
there
is
that
the
terminology
that
we
use
kind
of
does
imply
a
like
a
native
polarity.
So
you
know,
I
think,
when
you,
when
you
look
at
some
of
these,
you
know
scheduled
it
feels
like
it
has
a
native
polarity
right,
there's
a
pretty
obvious
way.
You
would.
It
feels
like
you
would
think
about
that
in
an
obvious
way
as
a
positive
polarity
and
so
like.
D
You
know,
depending
on
your
type,
there
is
a
that
you,
you
can
think
as
soon
as
you
read
the
type
name
you'll
that
will
automatically
prime
you
to
think
about
a
particular
polarity,
either
positive
or
negative.
So
there
is
this.
I
think
there
is
this
thing
that
there
is
a
native
polarity
to
to
the
types
depending
on
the
names
we
choose.
E
I
think,
like
from
a
pragmatic
perspective,
adding
positive
polarities
requires
it
assume.
Like
let's
say
this
is
like
a
ga
api.
It
would
require
sort
of
version
incompatible
changes,
whereas
adding
negative
ones
seems
like
that's
not
true,
and
I
think
that
was
the
original
intent
of
the
conditions.
E
So
it
feels
like
it's
okay
to
have
positive
and
depending
on
where
the
community
goes.
That
may
end
up
being
the
guidance,
but
we
should
probably
limit
those
to
like
a
very
few
and
then
mostly
when
we
evolve
it.
We
would
be
looking
towards
adding
negative
ones
and
having
that
mixed
rule
like
how
cube
status
does.
A
It
yeah-
I
I
have
a
I
don't
know.
I
think
I
think
negative
makes
sense
if
we're
treating
these
as
error
conditions.
If
we're
treating
these
as
things
that
appear
when
there's
an
error
and
go
away
when
they're
fine,
I,
where
negative,
starts
to
get
confusing,
I
think,
to
read
and
understand,
as
a
user
is,
you
know
in
the
pending
example,
you
have
pending
equals
false
reason.
A
None,
I
don't
know
or
reason
healthy.
I
I
don't
know
right
it.
It
feels
confusing
to
me
to
to
re
if
your
healthy
state
involves
a
lot
of
double
negatives
kind
of
thing.
I
know
we're
all
always
going
to
have
at
least
one
positive
in
terms
of
ready,
because
well
that's
what
you
have
yeah
I
mean
I
I
agree
with
danian
in
the
concept
of
you
know,
the
conditions
can
get
difficult
to
read
very
easily.
A
In
my
experience,
the
conditions
that
are
difficult
to
understand
are
often
the
negative
ones,
but
that
could
just
be
me.
E
Yeah
like,
but
how
many
positive
ones
do
we
need?
Do
we
just
need
like
very
few
like
ready,
and
then
we
can
say
all
of
the
error
conditions
are
all
negative
and
kind
of
give
a
rule
like
that,
because
if
we
expect
extending
it
going
forward,
is
that
mostly
we're
just
going
to
add
negative
ones
and
actually,
for
the
most
part,
we've
satisfied
sort
of
the
rules
of
the
game.
A
Okay,
you
added
a
a
condition
to
gate
to
route
that
I
think
it
was
it
admitted
to
indicate
like
it
was
a
positive
condition.
I
remember
that,
do
you
remember.
A
A
A
Right
so
I
think
in
this
case
it
was
referring
to
gateways
that
had
accepted
this
route.
So
if
a
gateway
hadn't
accepted
this
route,
my
understanding
was
that
it
potentially
just
wouldn't
show
up
in
in
the
list.
But
maybe
I'm
misunderstanding
that.
D
Accepted
true,
it
sounds
good
and
I
feel
like
accepted
false,
sounds
pretty
good
to
me
as
well.
G
Yeah,
I
agree
and
going
back
to
the
nuanced
thing
when
you
say
accepted
or
accepted
false
to
me
that
feels
less
final
than
saying
rejected.
True
right,
you
might
have
two
routes
that
conflict,
one
is
admitted
false.
The
other
is
admitted
true.
You
delete
the
one
that
submitted
true
now,
the
the
one
that
previously
was
not
admitted
can
be
admitted,
whereas
it
seems
a
little
weird
if
it
were
rejected
to
say,
rejected
true
and
then,
when
the
conflict
goes
away,
you
say
rejected
false.
D
Yeah,
I
think
it
does,
and
I
think
there
is
again
we
get
back
to
this.
D
I
think
the
connotations
around
rejected
it's
like
a
slightly
stronger
than
the
connotations
around
admitted,
because,
especially
in
the
pre-decision
phase,
because
I
think,
if
you're,
if
you're,
if
there
hasn't
been
a
decision
made
about
your
route,
yet
then
admitted
false,
makes
sense
but
rejected
false,
isn't
quite
the
same
thing.
Ridiculous
are
much
more
positive,
like
I
made
it
as
this
much
more
positive,
definite
connotation
around
a
decision
having
being
already
made.
G
G
D
I
think
there's
consensus
on
that
schedule
now
ready
ready's
ready
what
about
the
consistent
conflicted
for
comfort,
conflict
court
controllers
for
listeners
which
have
inconsistent
or
that
can't
coexist
on
the
same
port.
D
Okay,
one
one
staff
are
consistent:
two
for
conflicted,
perfect,
okay.
So
this
is
a
there's.
This
notion
of
a
a
listener
being
connected
to
this
listener
being
connected
to
a
gateway,
and
maybe
you
can't
connect
it
because
you
don't
support
something
about
it.
D
C
D
So
there's
this
next
one,
which
is
okay,
we
tried
to
resolve.
We.
D
Selectors
and
we
did
some-
we
had
to
resolve
all
these
selectors,
but
we
failed
for
some
reason.
So
we
had
this
process
of
like
okay
taking
everything,
and
then
we
resolve
everything
that
it
depends
on.
G
G
I
think
the
way
I'm
looking
at
this
is
I'm
thinking.
What
condition
am
I
looking
for
I'm
looking
for,
I
want
to
see
that
it's
been
accepted
or
that
there's
a
problem.
So
I'm
looking
for
the
thing
that
says
this
is
bad
or
the
thing
that
says
it's
been
admitted
right
again.
It
goes
back
to
that
kind
of
transition
or
event,
I'm
looking
for
a
status
condition
that
represents
that
the
event
has
happened
or
that
the
status
has
changed.
E
Like
how
would
you,
let's
see
so
looking
at
this,
let's
say
you're
using
it
you're
looking
at
the
status,
you
note
the
time
that
status
was
updated
and
then,
if
you
had
a
negative,
you
could
just
scan
for
the
negative
ones
and
know
that
there's
a
problem,
whereas
with
the
positive
ones,
when
you
have
to
go
through
each
one
and
just
see,
did
this
one
have
it
like
is
the
set
of
all
right
like.
A
A
That
assumes
that
if
the
polarity
is
negative,
it
is
not
always
there.
I
think
the
the
biggest
issue
I
have
with
negative
polarity
is
if
the
condition
is
present
and
negative
and
false.
That
feels
very
confusing
to
me.
So
let's
say
here:
invalid
refs
is
in
my
conditions
list
and
the
the
status
is
false
feels
like
I
can
understand
it,
but
it
takes
more
processing
time
than
resolve
refs
true,
I
think
so.
We.
A
A
D
So
these
so
for
this,
so
this
document
is
written
from
the
perspective
of
we
should
always
publish
the
conditions
all
of
them.
So
that's.
Why
that's?
Why
there's
only
like
a
small
number
of
that's,
why
there's
only
a
small
number
of
condition
types
and
it's
why
the
condition
types
as
as
much
as
I
could
try
to
reflect
some
kind
of
underlying
processing
of
the
that
the
controllers
are
going
to
be
doing.
E
A
Okay,
sorry,
I
know
I
know
we
have.
We
have
gone
over
time.
I
think
there's
just
the
one
more
condition
that
we
need
to
vote
on
here.
D
Okay,
so
this
is
where
you've,
so
this
is
kind
of
the
inverse
of
micah's
notion
of
admitting
the
route
to
the
gateway.
So
it's
like
the
gateway
going
have
I
pulled
in.
Have
I
pulled
in
all
the
routes
that
you
referenced.
A
I
think,
unfortunately,
this
has
to
be
negative
as
much
as
I
just
argued
for
positive.
The
these
are
not
two
opposite
thing.
A
task
route
seems
to
indicate
I
attached
a
route
that
well
it
should
be
routes
attached,
isn't
it
sure
sure,
but
either
way
that
that
seems
to
indicate
that
that
at
least
one
route
is
valid,
whereas
drop
routes
indicates
that
at
least
one
route
has
been
dropped.
D
A
D
Attached,
I
think
I
think
that
progressing
kind
of
goes
with
the
notion
of
attaching
routes,
but
it
doesn't
fit
so
well
with
the
notion
of
having
dropped
routes.
So
so
maybe
that's
like
that
progress,
maybe
that's.
Maybe
this
is
not
one
condition.
Maybe
this
is
two
conditions,
I'm
not
sure.
A
F
A
Yeah,
okay!
Well,
thank
you
everyone.
I
know.
I
know
we
have
gone
over
a
bit,
but
this
has
been
very
helpful.
James.
D
Yeah,
it
sounds
like
this
well,
I
think
rob
pointed
out
that
we
also
have
routes
in
gateway
class,
so
I
should
try
and
think
about
those
a
little
bit
and
I
think
in
general
it
feels
like
we're
leaning
towards
positive
polarity
in
general.
D
I
mean
I
can
be,
I
feel,
like
you
know,
there's
so
little
in
this
area
that
you
know
native
polarity
is
probably
gonna,
be
just
fine
in
practice
and
everyone
will.
Everyone
will
just
live
with
it
and
it'll
be
cool.
A
Yeah,
I
I
mean
yeah,
my
my
thought
is:
we
should
lean
towards
one
polarity
and
follow
that
pattern
as
a
default
and,
if
there's
a
really
compelling
reason
to
use
the
other
polarity,
whether
that's
negative
or
positive,
we
can
just
so
it
reads
better
or
is
easy
to
understand,
but
I
like
the
idea
of
a
pattern
of
using
one
mostly
or
consistently
yeah,
okay,
well,
yeah.
A
We
we
have
a
lot
to
go
through
today.
Thank
you
so
much
for
your
work
on
that
james.
Thank
you
for
everyone
who
stayed
a
bit
longer
today.
There's
just
a
reminder:
there
are
lots
of
pr's
that
can
use
review.
So,
if
you
happen
to
have
a
few
extra
minutes,
definitely
take
a
look
and
I
think
that's
all.
I've
got
any
any
last
words
here.