►
From YouTube: SIG Network Service APIs Office Hours 20200826
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
welcome
to
office
hours
for
service
apis.
It
is
august
26th.
We
are
just
running
through
all
these
different
things.
At
this
point
I
wanted
to.
I
think
some
of
these
things
may
make
sense
as
a
follow-up
tomorrow
as
part
of
the
regular
meeting
as
well,
but
because
we're
here
I
wanted
to
really
spend
as
much
time
as
possible
digging
through
v1
alpha
1
release
checklist.
I
think
we're
really
close.
A
I
wanted
to
check
in
with
everyone
on
what
they
think
is
required
to
get
this.
What
everyone
thinks
is
required
to
get
this
into
a
v1
alpha.
One
final
state,
I
think
harry
this
sni
matching
and
mode
pr
is
required
for
tls
config.
Do
you
think
tls
route
is.
B
A
Okay,
yeah,
I
haven't
had
a
great
chance
to
is
what
what
is
unique.
Well,
I
guess
we'll
we'll
get
to
that
in
npr
and
issue
triage.
I
don't
want
to
to
hold
that
up
too
much
other
than
these
two
prs.
Do
you
think,
there's
anything
else
needed
on
the
tls
front
yeah,
so
there's
tls.
B
And
route
yeah-
and
so
I
started
with
that,
but
then
ran
into
another
issue,
so
I
opened
the
vr
for
dls
route,
tls
and
route.
I
can
push
that
later
this
week.
B
That's
a
little
controversial
at
this
point,
but
I
think
that
that
would
be
something
we
need
to
decide
like
our
stand
on
it.
A
Okay,
so,
and-
and
just
so
I
understand,
the
difference
between
a
tlson
gateway
is
for
termination
or
pass-through
tls.
If
we
associate
it
with
a
backend
is
fairly
clear
for
the
upstream
connection,
a
tls
on
route
remind
me,
the
purpose
there
yeah.
So,
though,.
B
In
some
cases,
the
service
owners
who
control
the
x
route
resources,
they
want
to
configure
the
dls
and
we
want
to
let
them
configure
the
certificate
in
in
the
route.
So.
A
A
A
Yeah,
okay
got
it
that
that
makes
sense,
so
it
is
an
extension
of
tls
config
on
gateway
and
would
override
any
settings
that
existed
at
the
gateway
listener
level
for
tls
config.
C
So
harry,
I
think
I
made
a
comment
about
something
about
this
in
the
pr
and
I
think
that's
kind
of
the
explanation
that
we
need
to
give
people,
because
when
we
have
multiple
ways
of
doing
what
seem
to
be
similar
things,
then
I
think
we
need.
We
just
need
to
feel
like.
We
need
to
kind
of
give
people
some
some
sort
of
guidance
about
how
they
should
think
about.
C
Case
there
was
a
comment
about
that
would
be
easy
to
link
to
it.
I
say
you
can
match
on
the
sni
server
name
at
the
listener
and
use
a
tcp
route.
So
so
how
do
you?
How
do
users
know
how
should
users
think
about
when
they
should
use
a
tcp
route
when
they
should
use
a
tls
router?
C
B
So
we
did,
and
so
but
I
have
added
a
pr
for
tls
route
specifically
so
so
tls
route
and
tcp
are
two
separate
things.
D
C
D
C
That
the
ambiguity
here
is,
you
have
sni
dependencies
of
the
listener
and
you
have
sni
dependencies
for
the
tls
route.
So
what
are
they
kind
of
giving
some
kind
of
guidance
around
the
use
cases
for
these
different
things?
I
think
it.
D
C
D
Go
ahead,
we
were
actually
saying
exactly
the
same
words
at
the
listener
and
then
at
sni
route,
probably
or
tls
route.
C
C
It's
unfortunate.
I
don't
think,
but
I
think
block
comments
at
the
top
of
this
tls
route
types
file
will
actually
make
it
through
into
the
api
rendered
api
docs.
B
A
Point,
I
think
I
think
mark
had
been
working
on
some
kind
of
demo
or
documentation
that
was
more
user-friendly
for
these
apis,
but
yeah.
We
we
definitely
need
some
something
as
part
of
an
alpha
release,
yeah
great
okay
and
maybe
well,
since
we've
already
opened
the
can
of
worms
of
tls
route
harry.
Is
there
anything
more
you
wanted
to
cover
on
this
pr.
B
No,
I
think
so
we
decided
to
like
we
had
a
pr,
I
think,
but
jeremy
to
add
tls
and
tcp
out
and
that
seemed
kind
of
weird.
So
we
decided
we'll
go
for
sni
route
and
decided
to
call
it
tls
route,
because
all
the
other
routes
are
based
on
protocol
and
not
a
field
field
name.
So
that's
why
this
is
tls
route
and
it
it
only
has
sni
routing
support
is
core.
B
B
Yeah,
I
think
that's
like
one
of
the
reasons
to
have
tls
route
where,
on
the
listener
level,
you
specify
okay,
this
port
is
going
to
do
tls
termination
and
right
and
then
and
then
do
things
like
alp
and
routing
would
be
inside
the
dls
route
instead
of
at
the
listener
level
right
and
that's,
and
then
in
in
some
cases.
It
would
also
mean
that
you,
you
could
also
use
tls
at
the
listener
level,
to
filter
the
snis.
So
maybe
the
gateway
owners
decide
which
snis
they
really
want
to
filter
out
and
that
could
be.
B
You
know
like
sort
of
sub
domains
on
a
specific
list
of
domains
or
if
the
gateway
owner
trusts
the
service
owners,
then
it
would
be
like
match
domain.
Any
alpn
is
not
part
of
the
matching
right
now
in
this
spec
but
yeah.
I
do
agree
that
it
would
be
a
lpn,
but
then
we
cannot
have
http
based
technology,
so
things
like
http
2
upgrade,
which
can
be
done
by
stony,
lp
and
probably
don't
belong
here.
B
B
A
Cool
okay!
Well,
thank
you
for
filing
this
pr.
I
will
I'll
take
a
look
afterwards.
It
does
look
pretty
straightforward,
great
okay,
so
that
is
that
is
tls.
Config
harry
does
this.
This
is
the
only
thing
left
that
isn't
currently
a
pr
just
adding
tls
config
to
route.
A
A
I
think
I
think
you
we're
ready
to
move
on
with
it.
It's
not
necessarily
that
it's
final
just
that
it's
it's
ready
for
more
iteration
in
follow-up
pr's.
At
this
day,.
B
D
A
That
that
makes
sense
and
the
the
main
thing
that
this
adds
is
it
pluralizes
filter
and
it
does.
It
adds
header
matching,
no
header
modification
at
this.
B
D
No,
I
think,
let's,
let's
get
it
reviewed,
I
will
take
a
look.
I
think
the
there's
still
some
questions
about,
should
we
name
it
action
or
filter,
but
that
could
be
a
sub
a
follow-on.
I
don't.
D
B
Okay,
great
in
part
of
the
boy
we
need
one
more
thing
to
get
in,
which
is
traffic
mirroring
that
was
sort
of
part
of
the
proposal,
and
we
initially
we
before
decided
that
you
know
mirroring
would
be
a
filter.
So
I
did
open
a
pr
for
that
yesterday.
I
think
okay.
D
Is
it
dependent?
Can
you
anyways
ping
me
on
slack
with
the
specific
dependency,
if
you,
if
it
is
it
going
to
have
conflicts
when
it
emerges.
A
A
Okay,
so
the
next
one,
this
previously
said
service
level
config,
I
just
reworked
it
a
bit.
I
wanted
to
bring
up
back-end
policy.
I've
been
thinking
about
it
a
lot
over
the
past
week.
I
initially
had
this
proposal
that
we
discussed
briefly
in
the
past
couple
meetings
about
how
we
could
do
service
level
configuration,
and
I
think
there
is
a
real
need
for
service
level
config.
A
A
I
think
other
things
that
make
sense
there
pretty
clearly
would
be
say:
health
checking
what
I
am
increasingly
less
less
sure
about
would
be
the
timeout
policy,
and
especially
the
retry
policy.
Retry
policy
feels
like
it
really
could
belong
on
route.
A
A
I
think
this,
I
think,
service
level.
Config
is
a
very
valuable
and
important
concept
that
we
need
to
have
nv1
alpha
1.
In
some
capacity
we
want
to
model
a
way
to
provide
configuration
per
back
end
that
isn't
just
on
a
route.
I
think
that's
an
important
concept,
but
I
at
this
point
am
not
as
sure
about
both
timeouts
and
retries,
so
I'm
actually
thinking
about
pulling
both
of
them
from
this
pr
to
be
addressed
at
a
later
point
and
or
potentially
be
considered
on
route.
A
B
A
Yeah,
okay,
that's
that's
a
great
question,
so
timeout
policy
is,
I
can
see
either
place
that
I
know
lots
of
implementations
have
timeout
policy
in
either
place.
The
retry
policy
is
especially
interesting
in
that
different
routes
may
want
to
specify
different
retry
policies
for
the
same
back
end.
A
At
least
that
was
that
was
my
theory
on
this.
One
and
retry
policy
also
feels
like
something
to
me
that
there
is
is
pretty
vague
there.
There
are,
you
know
I've.
I've
done
a
survey
of
a
lot
of
different
implementations,
h,
a
proxy
nginx
envoy,
etc.
A
As
far
as
what
you
can
configure
for
retries
and
there's
a
lot
of
variation
here
so
part
of
my
hesitancy
to
adding
it
here
is
not
necessarily
that
it
doesn't
belong
here
forever.
It's
just
it's!
It's,
maybe
not
core.
It's
maybe
well!
No,
I
shouldn't
say,
maybe
not
core.
It's
maybe
not
important
enough
to
get
into
v1
alpha.
One.
A
So
part
of
my
my
motivation
here
is:
I
am
trying
to
push
forward
for
a
v1
alpha
one
launch,
and
I
want
to
make
sure
that
we're
not
including
you
know,
like
a
retry
policy
as
as
an
example,
something
that
is
extended
and
not
supported
everywhere
and
may
be
hard
to
standardize
on.
So
I
don't
want
to
really.
You
know,
push
out
our
our
release
date
on
something
that
may
not
be
as
as
obvious
to
support.
E
Yeah,
I
don't
know,
I
think
that
makes
sense.
So
is
the
thought
there
then
is.
We
don't
include
timeouts
and
retry
policies,
and
so
we
can
move
forward
with
the
release
and
then
we
figure
out
where
the
best
home
is
for
this
functionality.
A
Yeah
that
that
was
my
idea-
I
mean
it's,
it's
not
that
I
don't
want
these
to
be
part
of
the
api,
I'm
just
not
as
sold
that
they
need
to
be
part
of
the
first
release
of
this
api.
You
know,
I
think
at
least
the
way
I
see
this
api.
A
A
E
Yeah,
I
agree
with
your
perspective
and
I
I'm
in
favor
of
leaving
the
timeout
and
retry
policy
out
of
the
release
so
that
we,
the
release,
does
not
get
stalled
and-
and
I
think
it's
important
for
us
to
to
cut
this
release-
it's
easier
to
add
this
later
on,
even
if
it
ends
up
being
part
of
a
back-end
policy,
it's
easier
to
add
it
later
on
than
to
to
take
it
out.
So
that's
that's
my
main
reason
for
agreeing
with
your
perspective.
A
Yeah,
I
appreciate
that
and
that's
exactly
what
I
was
thinking
as
as
we're
getting
awfully
close.
You
know
I'd
really
hope
to
get
this
this
out
in
august.
I
don't
think
we're
gonna
do
that,
but
I
think
we
are
awfully
close
and
I
just
I
you
know
we
already
have
an
api.
A
That's
incredibly,
you
know
it's
implementable
or
very
close
to
implementable,
and
I
I
want
that
to
be
able
to
be
used
and
implemented,
and
you
know
we'll
learn
a
lot
from
those
first
implementations
as
far
as
what
we
want
to
iterate
and
where
we
need
to
expand
yeah.
E
Yeah,
I
agree,
I
don't
think
we
could
figure
out
all
the
details
until
we
actually
start
proceeding
with
implementations
and
yeah
iterating
on
on
the
api,
specs
yeah.
A
I
I
did
briefly
consider
and
this
this
goes
against
everything
I
just
said.
So
I
will
probably
not
do
this,
but
one
thing,
if
it
is
not
too
controversial,
is
I
looked
again
in
that
survey
of
all
the
all
the
different
implementations
I
was
looking
at.
A
A
basic
health
check
is
very
commonly
supported,
just
the
idea
of
a
http
or
or
something
like
that,
and
that
does
feel
like
something
that
belongs
at
a
back
end
level
instead
of
on
a
route
level
like
that
feels
like
it
very
clearly
belongs
here,
whereas
timeouts
and
retries
aren't
quite
as
clear
to
me.
A
I
don't
know
if
I'm
going
to
go
too
much
further
down
that,
but
it
does
feel
like
if
we
want
to
have
a
back
end
policy,
and
we
want
to
make
it
clear
that
is,
it
is
for
more
than
just
tls,
that's
a
relatively
straightforward
thing
to
add
at
a
as
a
very
basic
component,
but
I
I
know
it's
it's
a
slippery
slope
there
so
yeah,
but
I
I
think,
if
I
think,
if
we're
all
okay
with
it,
I'd
like
to
start
with
a
really
really
basic
back-end
policy
design
and
just
more
of
a
concept
of
here,
is
how
we'll
attach
policy
config
to
back
ends
and
try
not
to
dig
too
far
down
that
that
path
of
all
the
advanced
configuration
we
could
do
there.
B
A
Cool
the
next
one
that
I
wanted
to
cover
was
conflict
handling.
I
think
yeah
reasonably
close
here.
I
know
yeah.
E
Go
ahead,
let
me
interrupt
you,
but
before
we
jump
on
to
the
next
topic,
one
other
question
on
the
well,
maybe
I'm
looking
at
the
wrong
pr.
I
think
I
am
for
the
back
end
policy.
A
Yes,
I
should
do
that.
I
should
do
that
better
in
this
dock.
So
in
this
pr
I
had
a
dock
which
I
haven't
linked
to
here,
I
like
probably
in
an
agenda
somewhere
that
may
define
it
slightly
better,
but
the
the
idea
of
a
back
end.
Well,
really,
it
is
primarily
going
to
be
service,
but
it
a
back
end
represents
maybe
yeah
okay.
A
But
let
me
let
me
work
on
the
actual
vocabulary
there,
but
a
really
simple
explanation
of
my
understanding
of
a
back
end
is
anything
that
can
be
forwarded
to
from
a
route.
A
E
D
E
I
just
want
to
make
sure
that
right,
because
people
could
just
come
up
with
their
own
definitions
of
back
ends,
so
I
just
want
to
make
sure
that
we
make
it
very
clear
what
we
call
a
back
end,
yeah,
okay,.
A
Cool
for
yeah
for
conflict
handling,
I
think
we're
in
a
reasonably
good
place
here.
I
have
a
lot
of
things
that
I
have
considered
resolved
or
accepted.
At
this
point,
I
need
to
follow
up.
It
looks
like
harry
may,
have
added
some
feedback
since
I've
been
in
here,
so
I
I
will
follow
up
with
this
one.
A
I
think
the
way
to
resolve
a
lot
of
these
is
going
to
be
through
comments
on
the
types
themselves
to
indicate
how
they
should
be
interpreted
and
then
a
higher
level
bit
of
documentation
that
documents
these
kinds
of
guiding
principles
for
conflict
resolution
somewhere
in
on
the
actual
website
in
the
docs,
wherever
it
happens
to
be.
I
think
that
is.
A
All
that's
left
for
conflict
resolution,
but
anyone
correct
me
if
I'm
wrong
here.
If
there's
some
kind
of
potential
conflict
I
have
not
addressed
yet
or
that
we
don't
have
an
acceptable
release
resolution
for
definitely
let
me
know,
but
I
will
try
and
make
these
resolutions
a
little
bit
more
visible
by
getting
them
into
a
pr,
so
we
can
get
some
more
feedback
there
as
well,
and
on
that
note
I
do
have
this
one
pr.
We've
had
a
lot
of
discussion
on
this.
A
I
think
okay,
yeah
I'll,
follow
up
with
harry.
I
need
to
I've
lost
track
of
this.
This
thread
yeah,
okay,
so
that's
conflict
handling.
The
very
last
one
is
james,
is
taking
care
of
status
and
conditions,
and
I
know
you've
already
added
some
awesome
stuff
to
the
agenda.
A
So
thank
you
james
and
it's
this
doc
around
condition,
vocabulary
vocabulary
which
we'll
get
to
shortly
and
then
I
think,
yeah.
We
just
well
yeah
I'll,
we'll
cover
that
as
part
of
the
agenda,
but
I
know
I've
taken
half
our
time
to
go
through
this.
This
road
map-
I
do
think
we're
close.
A
I
know
this
is
not
going
to
be
an
august
release,
but
I
I
am
quite
optimistic
still
that
it's
going
to
be
soon
yeah.
So
with
that
said,
yeah,
let's,
let's
get
into
the
actual
agenda
for
today,
which
is
a
few
things
long
first
off,
I
I
and
harry
had
a
bit
of
a
bit
of
a
discussion
about
this
pr,
which
would
be
which
would
require
action
and
the
my
question
was
well
what
you
know.
A
What
is
the
difference,
this,
along
with
harry's
pr,
that
would
add,
mirroring
as
a
filter
got
me
wondering
well
how?
How
do
we
distinguish
between
what
is
an
action
and
what
is
a
filter,
and
are
we
always
going
to
have
an
action?
You
know
these
kinds
of
things,
so
I
think
we
had
a
really
helpful
discussion
on
this,
though
we
ended
up
with
slightly
different
understandings
at
the
at
the
end
of
this
discussion.
A
I
think
so
yeah
I,
I
guess
I'll
cover
my
understanding
and
harry
correct
me,
yeah
whatever
so.
A
Basically,
my
understanding
was
that
every
route
should
require
an
action
like
this
pr
would
implement
and
that
action
could
be
forward
to
maybe
at
some
point
it
would
include
re
redirects
like
just
url
redirects
and
of
course
it
already
includes
an
extension
ref,
but
that
is
the
one
action
that
will
happen
as
part
of
the
route
and
it's
required
as
part
of
that
match.
A
A
In
my
mind,
all
route
should
have
a
single
action
and
a
filter
can
be
applied
before
or
after
an
action
can
can
take
place
and
filters
can
perform
actions
on
a
request
or
response.
You
can
have
zero
to
infinite
filters.
A
I
don't
know
what
kind
of
upper
limit
we'd
have
there
and
filters
could
include
things
like
request,
auth
modifying
headers,
mirroring
traffic.
I
don't
know
any
kind
of
custom
extension
at
that
point.
This
was
my
understanding
of
kind
of
the
the
differentiation
between
actions
and
filters
where
action
is
kind
of
this
primary
thing.
The
primary
purpose
of
that
route
and
filters
are
modifiers
or
verifiers
or
authorizers
or
whatever.
A
On
top
of
that,
I
don't
know,
I
I
think
I
think
harry
you
may
have
had
a
slightly
different
take.
So
maybe
you
should
you
should
give
your
understanding.
A
C
I
was
going
to
say,
I
think
you
captured
it
pretty.
Well,
it's
just
that
in
the
real
world.
You
know,
I
think
I
think
you've
captured
it
about
as
well
as
it
can
be
captured.
So
I
mean
there's
a
basically.
You
have
a
pipeline
of
processing
stages
and
filters
steps
along
the
pipeline
and
actions,
kind
of
terminate
that
and
then
there's
a
whole
bunch
of
special
cases
like
authorization,
which
is
a
stage
which
is
kind
of
a
filter
and
an
action
in
that
definition.
D
Yeah
that
I
think
that's
why,
though,
there's
an
alternate
proposal
to
just-
and
this
is
mostly
around
naming
it's
just
calling
everything
action
and
then
the
final
action
to
be
like
terminal
action
or
something
mostly.
I
see
this
as
a
can.
We
explain
it
to
the
users
such
that
they
don't
get
very
confused,
like
any
solution
is
okay,
as
long
as
it
meets
that
requirement
in
some
sense.
A
A
You
know
like
if,
if
you
say,
okay,
every
route
must
have
at
least
one
action,
and
it
must
be
one
of
well
actually.
No,
because
an
action
can
include
an
extension
ref,
which
we
have
no
idea,
if
that's
actually
terminating.
Actually,
you
would
hope
it
would
be.
D
You
could
do
it
like,
you
could
say,
there's
a
specific
action,
that's
outside
the
list
and
then
there's
a
list
of
extras
like
you
could
conceivably
do
it
and
then
it
it's
up
to
the
the
validation,
like
some
basic
validation
that
you
could
just
look
at
that
one
element.
A
A
single
action
type,
let's,
let's
say
they
were
all
called
actions
and
a
primary
or
terminating
action
that
was
defined
separately
from
all
the
rest
of
the
actions.
I
guess
one
thing
about
filters
is
we
explicitly
say
that
we
are
not
the
the
order
of
filters,
as
they're
defined,
does
not
necessarily
have
any
meaning
in
this
api,
whereas
an
action
is
kind
of
separate
from
that,
and
it
is
meant
to
be
the
terminating
action.
A
D
Yeah,
like
you,
could
have
a
singular
action
field,
and
then
I
don't
know
what
you
would
call
it
extra
actions.
We
could
we're
clever.
We
can
come
up
with
something
as
a
list,
not
clear
if
that's
like
the
most
more
understandable
one.
Interesting
thing
is
that
it
is
this.
You
end
up
with
a
schema,
that's
very
similar
to
the
plural
pluralization
of
a
field
schema
for
better
for
worse.
F
He
keeps
saying
an
action
is
in
a
sense,
a
terminating
item,
but
you
also
say
that
actions
can
be
applied
before
or
after
an
action,
and
I
have
a
few
questions
around
that.
But
first
thing
is
it's
kind
of
confusing
to
say
an
action
may
be
terminating
if
a
filter
may
take
place
after
or
am
I
misinterpreting
something.
A
G
H
A
A
It's
right,
but
harry's
current
pr
actually
makes
mirror
a
filter.
Okay,.
F
Another
question
I
had
was
is
whether
the
action
is
performed
on
sorry
is
whether
a
filter
is
performed
on
request
or
response
a
property
of
the
filter.
That
is,
do
you
say
these
are
filters
for
pre-action,
and
these
are
folders
for
post
action,
or
do
you
just
have
filters
which,
if
it
makes
sense,
can
be
done
beforehand
or
if
it
makes
sense,
can
be
done
after
hand?
Right
are
the
two
types
of
filters,
or
is
it
all
about
how
you
order
them
with
respect
to
the
action.
A
Yeah,
that's
that's
a
great
question.
I
I
think
it
would
be
very
difficult.
You
know,
especially
in
that
modify
header
example,
to
understand
when
that
header
modification
should
occur.
A
F
Or
it
almost
feels
like
there
should
be
two
lists
at
least
two
one
for
pre-filter
pre-action
filter,
maybe
a
list
or
just
a
singleton
for
the
action
and
then
another
list
for
the
post
action
filters.
A
C
Occurred
could
work
I'm
a
bit
hesitant
to
make
a
to
kind
of
make
a
more
sophisticated
model
yeah,
because
it's
harder
to
match
that
to
any
particular
implementation.
C
A
How
do
you,
how
do
you
define
on
filters
which
filters
happen
before
which
which
filters
modify
a
request
and
which
filters
modify
a
response?
You
know
which,
which
filters
need
to
be
performed
after
the
forwarding
has
occurred.
C
A
So,
okay,
I,
if
if
you
do
that,
then
and
and
just
to
clarify
forward
two,
is
still
separate.
It's
outside
of
filters
forward.
Two
is
its
own
thing
right
in
that
approach,.
C
A
You
can
imagine
that
there
would
be
some
filters
that
some
sequence
of
filters,
where
you
wouldn't
want
to
forward
at
all.
So
let's
say
you
have
a
filter
that
is
a
url
redirect
as
an
example.
If
that
becomes
a
filter,
do
you
then
make
the
forwarding
optional,
but
then
also
filters
are
optional,
and
so
then
everything
is
optional.
C
C
A
I
mean
this.
This
starts
to
feel
dangerously
close
to
the
idea
that
everything
is
just
an
action
or
filter
or
whatever
you
want
to
call
it,
and
forwarding
is
just
one
of
those
things
that
happens
to
be
in
there.
It's
all
just
one
big
list
and,
let's
just
hope,
you've
got
at
least
one
thing
in
that
list.
C
A
Okay,
I
mean
the
one.
The
one
thing
I'll
say
is
I
I
I
don't
mind
that
I
it
does
somewhat
simplify
things
in
the
sense
that
you
have
forward
and
you
have
filters
for
everything
else
and
extension.
Ref
has
all
you
know
feels
weird
in
action
when
you
have
filters
which
are
basically
extensions
and
can
do
what
you
know
like
it
feels
like
duplication,
redirects
could
potentially
go
on
a
filter,
but
you
sure
yeah
yeah,
I
mean
the.
A
Maybe
james,
if
you
don't
mind,
adding
that
that
comment
or
suggestion
to
this
pr
273,
that
that
would
be
very
helpful
to
to
do
to
have
some
follow-up
discussion
here.
A
Sounds
good
all
right!
Well,
thanks
for
that,
we
have
one
more
thing
here
and
this
is
from
james.
I
wanted
to
make
sure
we
had
some
time
to
cover
it
and
actually
before
we
we
could
get
into
this
james.
Would
you
rather
talk
about
this
in
tomorrow's
meeting
or
is
now
fine?
I
I
don't
know
what
you
had
in
mind
here.
A
Yeah,
I
think
I
think
you
know
we
only
have
10
minutes
left
anyway,
so
we
might
as
well
and
get
get
what
we
can
out
of
this
and
get
some
initial
feedback
if
that
works.
For
you.
C
Sure
so,
basically,
what
I've
tried
to
do
here
is
look
at
the
condition.
Look
at
the
existing
errors
that
we
have
and
try
and
kind
of
organize
them
a
bit
into
something
that
I
feel
reflects
the
categories
of
things
that
can
go
wrong.
I
haven't
taken
a
strong
stand
on
the
polarity
of
the
conditions.
C
There's
no
resolution
on
polarity
upstream
that
we're
still
kind
of
in
this
holding
pattern
where
the
official
guidance
says
negative
polarity,
but
large
parts
of
the
community
are
going
off
and
doing
positive
polarity.
So
it
seems
to
be
all
about
like
hey,
do
what
makes
sense
for
you.
I
I
do
like
I
know.
Mica
mica
has
a
apr
which
uses
a
positive
polarity
condition
for
for
the
route
types
and
that
pr
makes
a
lot
of
semantic
sense
to
me.
C
So
there's
one
argument
we
could
make
is
that
we
should
do
positive
polarity
to
be
consistent
across
the
api,
but
anyway,
for
here
I've
given
both
names
and
I've
tried
I've.
I've
thought
tried
to
be
careful
about
how
to
choose
names
so
that
they
can
make
sense
in
both
positive
and
negative
polarities.
C
So
the
one.
The
other
thing
that
I
haven't
changed
is
the
grouping
of
listener
conditions
by
port-
that's,
I
feel,
is
still
a
bit
wonky
because
of
primarily
because
of
the
addition
of
of
udp
so
prior
to
udp.
When
we
only
had
tcp
and
upwards
protocols,
then
you
know
your
collapse
here:
you're
either
collapsing
stacked
protocols
down
onto
a
single
port
or
you're,
not
and
so
everything's
on.
C
C
So
for
gateway.
There's
really
only
a
couple
of
it's
really
only
a
couple
of
conditions
at
the
moment
so
there's
pending,
which
is
the
state
sometime,
which
is
the
state
between
creating
the
resource
and
allocating
or
finding
some
kind
of
underlying
infrastructure
to
instantiate.
That
resource
on.
C
It
could
be
like
and
so
so
base.
So
that's
what
we've
talked
about
before
the
concept
of
scheduling
of
scheduling
the
gateway.
So
you
have
this
period
of
time
where
the
gateway
is
not
scared.
It's
not
scheduled
so
it's
pending,
then
you're,
basically
ready
so
you're,
either
ready
once
you've
actually
found
some
underlying
resources
to
put
your
gateway
on,
then
you
can
be
ready
or
not
right,
so
you
can
be
ready
if
everything's
cool,
but
you
can
be
not
ready.
C
A
Yeah
sorry,
one
question
here:
you
have
this
not
reconciled
condition
or
a
reason
here
is
there?
Is
there
room
for
some
kind
of
intermediate
state
where
a
you
know?
Basically,
a
controller
is
working
on
it
but
has
not
reconciled
it
yet,
and
I
I
recognize
this
is
not
going
to
take
a
lot
of
time
for
a
lot
of
implementations,
but
I
can
see
for
some
like
cloud
as
an
example
where
you're
spinning
up
a
load
balancer,
it
could
take
a
minute
between
when
a
controller
recognizes.
A
This
is
something
they
should
care
about
and
between
when
they've
actually
reconciled.
I
I
don't
know
if,
if
there's
value
there.
C
Yeah
there
could
be
a
it
could
be
like
a
non.
I
guess
some
of
these.
Some
of
these
reasons
are,
I
guess,
terminal
reasons
like
no
resources
is
like
you
know,
we're
done,
but
you
can
imagine
there's
non-terminal
reasons
like
you're
waiting,
you're
waiting
on
administration,
you're,
waiting
on
some
kind
of
approval
process
or
you're
waiting
for
some.
You
know
cloud
resources
to
to
become
available
so
that
I
think
definitely
there's
probably
there's
other
additional
reasons
that
implementations
could
put
in
there.
C
A
A
provisioning
reason-
or
I
don't
know
just
making
things
up
but
yeah
yeah,
sorry
to
sidetrack,
either.
C
Yeah,
I
think
one
of
the
feedback,
some
feedback-
I
had
I'm
not
sure
if
it's
here
or
whether
I
got
it
out
of
band-
is-
are
these
the
only
things
that
we're
allowed
to
put
in,
and
I
think
the
answer
is
no.
I
think
that
I
think
that
there's
benefits
to
having
a
common
vocabulary
as
much
as
possible,
because
that
I
think
that
helps
the
ecosystem
generally,
but
I
don't
think
that
this
captures.
C
I
don't
think
that
this
vocabulary
here
is
is
exhaustive
and
I
definitely
think
implementations
are
allowed
to
add
their
own
at
their
own,
publish
their
own
status
kinds
and
reasons
if
it
makes
sense
for
them.
C
Yeah
makes
sense
the
listener
conditions,
there's
more,
basically,
there's
more
bad
things
that
could
happen
to
listeners,
but
the
the
higher
level
the
high
level
states
which
were
which
we're
representing
here
are
conflicts,
so
listeners
can
be
conflicted
which
is
like.
Oh,
you
tried
to
do.
You
specified
two
listeners
and
you
can't
have
them
both
for
some
kind
of
reason.
C
Listeners
can
be
detached.
This
is
like
you
had
a
listener
and
I
think
it's
fine,
but
I
can't
do
it.
So
it's
the
notion
that
you
have
that
you
had
this
thing.
You
had
this
request
that
can't
actually
be
attached
to
a
gateway,
so
the
notion
of
like
listeners
and
gateways
are
kind
of
connected
in
some
way
that
that
state
is
fairly
similar
to
disconnected
refs.
There's
a
fair
bit
of
conceptual
overlap.
C
I
think
between
the
the
detached
state
and
the
disconnected
refs
state,
so
you're
in
the
positive
polarity
you've
gone
through
this
process
and
you've
resolved
all
the
references
and
you
and
you
know,
they're
good.
The
negative
polarity
you've
gone
through
the
process
of
resolving
them
and
you've
and
you've
found
an
error
and
you've
got
oh
some.
Some
references
are
disconnected
on
this
thing,
so
that's
kind
of
bad
or
it's
partially
bad
we're
not
quite
depending
on
the
implementation.
It
could
be
not
so
bad
dropped
routes
is
specific
to
routes.
C
So
there's
cases
where
the
listener
specifies
the
routes,
the
route
selector,
but
you
can
detect
in
the
controller
that
not
everything
that
that
route
selector
selects
is
going
to
be
good,
so
you're
saying
well,
we
used
some
of
them,
but
we
didn't
use
some
others.
C
So
I
think
this
is
something
that
you
that
could
feed
into
the.
E
C
C
Have
all
the
ones
that
you
wanted
and
the
final
state
is
ready,
which
is
everything's
cool,
so
you're
ready.
If
you
did
all
the
previous
kind
of
processing
stages,
you
resolved
your
conflicts,
you
attached
everything
you
you
connected,
you
resolved
your
references
and
you
didn't
drop
any
routes
and
you
programmed
the
whole
thing
into
the
listeners.
Then
then
you're
ready
and
it's
good
and
you're
good
to
go.
A
This
is
awesome,
thank
you
so
much
for
getting
us
all
together
and
especially
for
me
as
someone
who
is
trying
to
figure
out
conflict
resolution,
this
will
help
a
ton
on
that
front
as
well.
So
thank
you
for
the
contributions
on
that
front
as
well.
I
think
I
think
there's
going
to
be
some
overlap
in
conditions
I
suggested,
and
what
you
already
have
here
proposed
here.
So
this
is
yeah.
A
Awesome,
I
will,
I
will
make
a
note
to
to
read
through
this
again
and
and
leave
any
feedback
I
can
think
of
between
now
and
tomorrow's
meeting.
C
Oh
thanks,
so
I
think
there's
probably
a
lot
of
implementation
specific
stuff
we
can.
We
can
add
here
or
like
as
people
think
of
new
cases.
We
can
add
more
reasons
or
even
even
conditions.
I've
generally
tried
to
create
the
condition
types
so
that
they're
orthogonal.
So
I
believe
that
I,
that
one
of
the
goals
for
conditions
is
that
a
controller
would
always
set
a
controller,
would
always
publish
a
status
for
all
the
possible
all
the
possible
conditions,
so
in
listener
conditions.
For
example,
by
default,
you
get
one
two
three
four.
C
Yeah,
so
if
you're
not
conflicted,
say
if
you
are
conflicted,
you
would
say
I
am
conflicted
and
then
the
conflict
and
my
conflicted
state
is
true,
but
if
you're
not
conflicted,
you
would
still
you
would.
You
would
say
my
conflicted
state
is
false,
got
it
okay,
so
you
would
always
be
able
to
so
you
would
say.
I
think
the
idea
there
is
that
you
try
and
avoid
the
potential
ambiguity
of
what
does
it
mean
if
the
controller
didn't
tell
me
about
their
condition,
do
I
assume
it's
unknown,
or
do
I
assume
it's
good
or
bad.
A
That
makes
sense:
okay,
well
yeah.
I
know
I
know
we're
at
time,
but
this
is.
This
is
really
great.
I
will
yeah.
I
will
read
through
this
more.
Thank
you
so
much
for
the
overview
and
we'll
talk
to
everyone
tomorrow,
cool
thanks,
rob.