►
Description
Service APIs Bi-Weekly Meeting (APAC Friendly Time) for 20211101
A
A
Both
shane
and
jeff
are
hoping
to
be
able
to
talk
about
the
upcoming
gaps,
one
for
route
matching
l4
route
matching
destination,
ip
port
and
anything
else
we
might
think
of,
and
similarly
route
inclusion
and
delegation,
hoping
we
can
get
to
those
in
a
couple
weeks.
So
I
just
kind
of
penciled
those
in
as
november
15.,
obviously
feel
free
to
change
them
as
the
date
gets
closer.
A
But
that's
that's
what
we
have
right
now
for
coming
up
topics.
We
also
have
lots
to
get
through
today
and
I'm
not
sure
yeah.
It
looks
like
young
men,
you
are
on
this
call.
You
had
added.
You
had
started
a
discussion
about
metadata
matching
for
gateway
api.
Maybe
you
can
provide
a
bit
of
background
and
what
you're
hoping
to
get
out
of
this.
B
It
contains
a
a
kind
of
like
a
json
object
containing
a
lot
of
claims
representing
the
validated
and
the
user,
and
we
often
want
to
like
route
that
request
to
different
backend,
based
on
the
like
a
different
claims.
In
that
token,
for
example,
if
you
have
some
like
a
developer,
they
have
a
high
private
each
job
token.
They
can
use
that
token
to
route
the
request
to
development
backend
and
for
the
normal
user
and
for
other
people
they
will
not
have
that
token,
and
then
they
will
be
routed
to
the
default
production
backend.
B
B
B
Actually,
the
dollar
character
showing
in
the
github
issue
is
probably
not
a
good
example,
because
that
is
that
is
actually
an
allowed
http
header,
but
we
can
use
some
other
prefix
like
the
x
character,
so
that
it
will
never
be
used
as
a
real
hd
behavior
and
then
the
remaining
part
is
just
reusing.
The
header
meter
that
is
already
there
to
match
against
the
validated
draw
the
claim,
and
we
can
use
a
reserved
key
to
specify
that
this.
This
item
is
matching
to
the
job
claim,
for
example,
the
request
on
all
stock
claims.
B
B
I
think
it
seems
like
most
people
probably
prefer
or
like
a
dedicated
field
other
than
reusing
the
header
field,
to
like
reduce
like
a
confusing
and
also
probably
give
us
like
more
flexibility
in
the
future.
If
we
have
more
like
a
different
kind
of
data,
better
metadata,
we
want
to
support
so
that's
kind
of
the
introduction
and
of
this
picture
request.
A
Yeah
thanks
thanks
for
raising
this
I'll
hand
it
off,
and
if
anyone
has
questions,
but
I
just
wanted
to
to
thank
you
for
adding
all
these
anytime.
I
see
an
issue
which
shows
already
shows
how
different
implementations
use
or
support
this
kind
of
feature.
It's
helpful,
because
these
are
obviously
implementations
where
we're
trying
to
support-
or
you
know
at
least
be
portable
with.
So
so
that's
really
helpful.
I
I
can
see
this.
You
know
based
on
your
your
introduction
to
this
and
read
through
this
and
the
discussion
below
it.
A
So
I
I'm
trying
not
to
go
too
far
against
what
I
just
said,
but
this
this
shows
that
we
currently
don't
have
a
matching
extension
mechanism.
I'm
not
I'm
not
sure,
that's
the
correct
approach
here,
but
it
does.
You
know
if
we
were
to
run
into
some
kind
of
route
matching
mechanism
that
was
more
extended
and
further,
you
know
less
broadly
supported.
A
Then
I
I
can
see
how
some
kind
of
extension
mechanism
here
could
be
really
useful
to
enable
this
kind
of
experimentation,
but
this
this
particular
thing
does
seem
to
be
fairly
broadly
supported,
so
anyways
that
that's
a
lot
of
nothing
but
I'll
hand
it
off.
If
anyone
has
additional
thoughts,
they
want
to
add
here.
C
Yeah,
I
wanted
to
say
thanks
for
addressing
that
concern.
I
had
about
a
map
string
map,
string,
string,
yeah,
I
think
yeah.
I
feel
pretty
strongly
about
that
one
that
we've
got
to
avoid
all
things
like
that,
but
you're
already
doing
that.
So
thanks
for
just
clarifying
that
gentlemen,
but
I
think
yeah,
I
definitely
support
having
something
it
does
make
sense
to
be
able
to
route
on
job
token
claims.
C
I
think
the
thing
that
I
would
worry
about
with
this
is
that
the
the
design
sketch
you've
got
there
makes
sense,
but
I
feel,
like
the
the
magic
name,
feels
like
a
bit
of
a
smells
a
little
bit.
You
know
it
feels
a
little
funky.
It
feels
like
having
something
that
would
more
more
cleanly
define
the
name
in
a
field
rather
than
in
like
a
magic
string
in
a
name
is
a
better
design
practice.
C
One
of
the
things
you
I've
been
pushing
for
the
sort
of
thing
about
conformance
a
lot
and
one
of
the
things
I've
been
trying
to
think
of
is
like.
How
would
we
test
this?
How
would
we
ensure
that
that
there's
a
specific
way
to
do
this
and
that
we
can
write
a
performance
test
against
it
and
how
would
we
bound
the
scope
so
that
so
that
you
don't
have
to
write
conformance
tests
for
like
all
possible
combinations
of
metadata?
C
So-
and
I
think
the
answer
to
that
in
my
mind-
is
something
like
having
something
where
you
can
say
you,
the
type
yo
the
match
that
it's
an
exact
match
and
it's
an
off
type
metadata
and
you
it's
or
it's
you.
We
specify
that
it's
a
job
metadata
and
then
then
you
supply
the
key
in
the
value
or
something
like
that.
So
then
we
can
say:
okay,
four
jot
tokens
that
we
we
do.
C
A
Yeah,
I
I
agree
with
everything
there
that
those
are
those
are
great
points
and,
and
young
man,
just
I
I
think
I
understood
this
quickly,
but
I
I
want
to
be
clear.
This
is
the
the
examples
you're
giving
are
four
jot
matching,
but
you
are
really
looking
for
something
broader
in
scope
than
jot
matching
you're
you're.
Looking
for
metadata
matching
as
a
whole
is
that
okay,
yes.
B
Yes,
a
little
bit
more
about
this
is
that
even
those
are
like
an
immediate,
immediate,
like
a
useful
request
like
we
have
seen,
is
for
this
chart
claim
matching,
but
I
imagine
it
will
be
needed
for
other
types
of
metadata.
That
is
large,
like
in
the
format
of
draw
token,
and
it
may
be
have
some
other
formats,
so
I'm
just
thinking
ideally
like
in
the
in
the
gateway
api
level.
B
So
we
completely
decoupled
this
from
other
things,
like
the
validation
of
that
like
information.
If,
if
that
is
evaluated,
and
also
we
decouple
this
from
those
like
it's
a
while
format,
that
is
being
tran,
that
has
been
sent
overlaid
network
and
in
the
gateway
label,
we
specifically
like
have
a
scope
of
like
a
api
for
matching
that
metadata
after
that
is
like
a
decoded
or
validated
or
whatever
operation.
That
is
necessarily
done
for
that
thing.
B
So
in
this
level,
if
we
can
somehow
express
that
metadata
in
a
kind
of
unified
or
general
data
structure,
for
example,
if
it
can
be
expressed
in
like
a
like
a
json
object,
the
real
like
the
matching
schematics,
we
will
need
in
most
cases.
I
guess
is
just
to
look
up
a
property
in
that
json
object
and
then
compare
it
with
a
value.
B
So,
like
imagine,
if
you
have
another
metadata
that
you
want
to
match
in
the
future,
let's
we
we
have.
We
want
to
match
against
the
pure
certificate
a
pure
certificate
because,
like
there
are
also
many
users,
they
are
using
client-side
certificate
for
validating
and
authenticating,
which
the
gateway
api
and
that's
pure
certificate.
Information
can
also
be
expressed
very
likely
like
in
like
a
json
object.
B
The
only
like
a
thing
you
need
to
make
a
specified
explicitly
in
the
gateway
api
is
probably
to
see
like
which
type
of
metadata
you
want
to
match
and,
as
those
remaining
part
will
be
reused,
I
think
that's
that.
Hopefully
I
think
that
will
be
like
a
useful
for
other
metadata
so
that
we
don't
need
to
like
introduce
another
field
like
each
time
for
real
data
or
for
new
metadata.
A
I
think,
nick
you
had
the
suggestion
earlier
when
you're
talking
something
along
the
lines
of
instead
of
say
an
exact
type
or
something
like
that,
where
you're
talking
about
an
exact
name
match
what,
instead,
what
you
might
have
is
this
is
a
kind
of
jwt
match
and
it's
you
know
a
jot
match.
This
is
a
clearly
understood
kind
of
match,
and
this
is
what
this
means
in
the
extended.
A
You
know
scope
of
the
api,
but
then
we
potentially
have
room
like
we've
done
elsewhere
and
gateway
api
of
vendor
prefixed
values.
There
too,
of
this,
is
a
proprietary
foo
match
for
this.
This
other
concept
that
is
not
as
broadly
understood
in
gateway
api.
So
we
have
these
core
concepts
and
we
have
a
you
know
a
consistent
way
to
match
jot
across.
You
know
every
implementation,
but
then
there
you
know
we
have
room
for
extension
here.
A
C
Yeah,
so
I
think
that
that
is
exactly
what
I
was
saying.
I
definitely
would
support
what
you're
talking
about
young
and
having
the
mechanism
be
present,
but
I
think
the
thing
that
we
that's
really
important
that
we
do
for
the
gateway
api
is
be
very
clear
about
what
what
things
are
like
supported
at
what
level,
and
so
the
and
so
like
something
like
jot
is
like
a
very
as
you
say,
it's
a
pretty
common
use
case.
Lots
of
people
want
that.
C
C
But
if
we
say
okay,
the
type
is
what
sets
the
how
well
it
should
be
supported,
so
that
and
and
that,
if
that
type
is
allowed
to
be
a
domain
prefix
string,
then
that
means
that
if
you
say
you
want
to
experiment
with
a
certificate,
you
know
certificate
key
value
matching.
Then
you
can
do
you
know
my
implementation,
dot,
io,
slash
certificate
or
something
like
that,
and
then
that
means
that
then
you
can
prototype
something
you
can
try
it
out.
C
You
can
have
your
users,
try
it
and
then,
if
it
works
really
well-
and
you
think
it's
a
common
enough
use
case,
then
you
can
bring
it
back
to
the
gateway
api
and
say:
okay,
here's
the
code
that
I've
done.
Here's
the
implementation.
I've
done
for
you
know
my
implementation
dot
io
certificate.
I
think
that
there's
broad
enough
use
of
it
that
we
can
bring
it
back
and
make
it
extended
support
in
the
gateway
api
part
of
that
process.
I
think
we
haven't
defined
this
process
yet,
but
in
my
mind,
part
of
that
process.
C
That
feels
like
the
flow
that
we're
aiming
for
with
building
out
new
features
in
one
implementation
and
bringing
it
being
able
to
bring
them
to
other
implementations.
Because
again,
I've
said
this
in
always,
but
I
want
to
try
and
say
it
every
meeting
so
that
we
all
you
know,
make
sure.
We
agree
that
one
of
the
primary
aims
of
the
gateway
api
project
is
to
make
sure
that
you
can
move
routes
safely
between
implementations,
as
long
as
both
implementations
support
the
same
set
of
features.
C
A
A
A
Yes
experimental,
yes,
I
I've
been
thinking
to
myself
about
the
the
experimental
gap
which
we'll
get
to
later
today
it
how
I
actually
implement
that
and
to
do
that,
I
really
would
really
need
an
experimental
field
to
test
it
with.
So
whoever
can
race
the
first
experimental
field.
This
seems
like
a
great
candidate,
whatever
it
is,
that'll
be
fun.
So,
okay,
I
think
I
think
we
have
at
least
enough
interest
to
work
towards
a
proposal
on
this
it.
A
It
seems
like
the
direction
that
that
nick
was
describing
here
lines
up
with
what
others
are
thinking
young
men
I
can
work.
I
can
chat
with
you
offline
about
how
we
can
get
a
proposal
out
there,
but
maybe
we'll
start
with
a
dock
that
kind
of
builds
from
this
issue
and
eventually
move
to
a
gap
cool
all
right,
well,
yeah.
Thank
you
thanks
for
bringing
this
great
awesome,
all
right,
I'll
move
on
to
the
next
one,
and
that
is
yeah
release
plan.
So
this
is
really
just
I
I
ye.
A
Last
week
I
was
looking
at
the
release
plan
and
timeline
proposal.
It's
not
a
plan
whatever
it
is,
and
I
was
trying
to
figure
out
how
do
I?
What
is
the
next
step
for
a
doc
like
this,
like
we've
been
struggling,
I've
been
struggling
at
least
with
you
know:
does
everything
become
a
gap?
Does
every
doc
we
ever
create
turn
into
a
gap
if
it's
something
that
we
agree
to,
or
are
there
some
things
that
go
from
doc
to
like
built-in
documentation?
A
A
A
E
F
C
Yeah,
I
was
gonna
say
it
feels
like
this
is
very
much
a
time
limited
announcement
of
some
sort
and
yeah
my
thought
was
well.
We
have
a
blog,
that's
a
time
limited
announcement
yeah,
maybe
that's,
maybe
that's
a
safer
place
as
any
to
be
like
okay,
we're
going
to
publish
a
blog
saying.
This
is
the
current
plan
out
of
the
date
that
this
blog
was
published.
C
You
know
for
the
for
the
most
up-to-date
version
of
this
plan.
Please
see
somewhere
else
or
you
know,
or
this
plan
may
change
or
something
like
that,
but
that
way
a
blog
post
has
the
advantage.
It
has
a
very
definite
publish
date
if
we
will
put
where
to
put
this
in
as
a
gap
or
something
like
that,
we'd
have
to
have
a
thing
at
the
top
to
say
this
was
the
plan
as
of
this
date.
You
know
if
you're
looking
at
this
after
this
date,
then
you
should
really
consider
you
know.
A
That's
a
good
one,
maybe
that
that's,
I
hadn't
actually
thought
of
a
blog
post,
but
that's
a
good
way
to
incorporate
it
into
the
website
with,
as
you're
saying,
a
very
clear
publish
date
which
is
important
for
this.
I
wonder
if
we
could
maybe
a
a
blog
post,
pointing
to
a
discussion,
something
like
something
like
that.
That's
easy
to
update
with
more
up-to-date
timeline
whatever,
as
we
go.
C
A
Okay,
I'll
work
on
that
great,
the
last
bit
I
have
here
is
just
in
no
particular
order
pr
and
issue
triage.
I
think
the
entirety
of
prs
we've
got
it
in
the
past
week
or
so
are
gep
related.
So
thanks
everyone,
the
first
one,
let
me
hand
it
over
to
nick.
I
think
this
is
almost
done.
There's
just
a
question
from
james
at
the
end,
I'm
unless
I'm
missing
any
other
discussion
points
on
this.
C
But
yeah-
I
think
james,
isn't
here
today
so,
but
I
think
james
was
sort
of
saying
why.
Why
should
we
do
profiles,
and
I
think
I
put
a
bit
of
a
response
there,
but
just
to
say
it
again
in
my
mind,
the
profiles
are
the
way
that
we're
gonna.
This
is
a
really
big
api.
That
is
almost
that
most
implementations
will
not
support.
All
of
and
in
my
mind,
profiles
are
a
way
to
to
subdivide
the
functionality
and
say
you
for
this
for
this
set
of
functionality.
C
If
you
support
some
of
this,
you
probably
you
almost
certainly
want
to
support
all
of
it,
and
so
we're
going
to
carve
that
off
and
say
this
is
a
profile,
and
you
know
if
you
support
this
profile,
then
you
then,
then
you
should
be
able
to
move
between
them
at
its
heart.
A
profile
for
conformance
is
literally
just
a
checklist
of
all
of
the
features
that
everything
needs
to
support,
and
you
know
on
top,
and
those
features
are
really
what
tests
need
to
pass
at
its
heart.
C
A
conformance
profile
is
syntactic
sugar
for
a
certain
set
of
conformance
tests
that
have
to
pass
for
your
implementation
and
but
there's
a
certain
set
of
ones
that
are
in
core
support.
That
are
let
everybody
who
does
a
certain
thing
is
going
to
have
to
pass,
and
I
think,
there's
some
value
in
having
a
very
simple
synthetic
sugar
for
for
that
that
matches
like
how
we
talk
about
these
things
anyway.
The
the
examples
I've
given
in
the
document
are
layer,
4
and
layer
7..
A
Yeah,
so
I
read
through
this,
I
was
starting
a
response
and
then
I
lost
track
of
time,
but
what
my
response
was
going
to
be,
as
I
I
see
what
james
is
saying
is
that
in
that
you
know
fundamentally,
we
we
want
to
support
we.
You
know
an
implementation
wants
to
say
I
support
these
particular
route
types
and
that
might
not
always
fit.
You
know
squarely
in
terms
of
one
single
conformance
profile
or
the
other
you
know
like
there
may
be.
I
support
tcp
route,
but
not
udp
right.
A
You
know
whatever
it
is
right,
whatever
it
is
so
or
I
don't
support
tls
route,
I
I
don't
know
what
what
it
feels
like.
We
we
need,
and
there
there
may
be
space
for
this
is
conformance.
Profiles-
are,
are
useful
kind
of
shortcut,
a
useful
way
of
describing
the
95
of
implementations
that
are
going
to
fit
into
this
bucket
of
hey.
I
am
a
l7
proxy
or
I
forget
what
we
call
that,
but
that
you
know
that
profile.
A
Whereas
there
will
we
need
to
have
some
room
for
the
five
percent
or
whatever
implementations
out
there,
that
don't
cleanly
fit
into
one
of
those
buckets.
They
either
do
a
little
bit
more,
a
little
bit
less
and
so
maybe
there's
maybe
there's
room
kind
of
as
an
extension
to
this
to
say,
if
you
don't
fall
into
a
conformance
profile,
here's
how
you
can
programmatically
describe.
A
C
Okay,
I
think
yeah,
it
makes
sense.
It
makes
sense
to
define
this
in
terms
of
like
the
per
object
is
like
the
intermediate
step
between
profile
and
like
field
level
support,
I
think,
at
its
heart.
All
of
this
comes
down
to
field
level,
tests
that
will
need
to
be
run,
and
then
you
can
bundle
those
up
into.
C
You
know
cid
level
tests
that
comprise
a
set
of
field
level
tests,
and
then
you
can
bundle
those
up
into
conformance
profiles
that
are
like
a
set
of
crds,
and
so
it
probably
makes
sense
to
update
this
document
to
make
that
clearer
to
make
clear
that
there's
a
sort
of
a
hierarchy
here
and
that
we
may
that
we
can
provide
syntactic
sugar
in
the
form
of
a
performance
profile,
and
all
that
is
a
set
is
saying.
The
layer,
7
conformance
profile
is
gateway,
gateway,
class
reference
policy,
http
right
here,
tls
route
yo.
C
But
if
you
want
to
support
those
object,
objects
plus
your
own
routes
or
you
only
want
to
support
http
router,
not
to
less
route,
although
but
sure
yeah.
If
you
wanted
to
do
that,
that's
fine!
You
can
do
the
conformance.
Just
by
specifying
that
that
you
support
just
those
objects-
and
if
you
want
to,
if
you
wanted
to
do
http,
tls
route
and
tcp
rep
and
not
udp
route,
then
then
you
can
do
that
just
by
specifying,
like
your
own
custom
performance
profile
in
this
mat
in
this
manner
so
yeah.
C
I
think
that
is
fair
feedback
that
I'll
take.
You
know
that
the
the
conformance
profiles
are
syntactic
sugar,
but
we
should
make
sure
that
the
the
levels
of
the
syntactic
specificity
that
you
want
are
available
to
you
as
an
implementer
that
comes
back
to
what
I
was.
What
I
ended
up,
I
kind
of
took
out
of
this
that
I
had
in
the
original
document
was
thinking
a
little
bit
more
about
how
we
will
programmatically
expose
that
information.
C
There
needs
to
be
a
way
for
we
need
to
be
able
to
have
a
test
suite
that
you
can
point
at
something
that
has
a
way
to
describe
to
the
test
suite
what
tests
should
be
run.
Ideally
in
my
and
so
my
initial
proposal,
for
that
is
that
it
should
be
status
on
the
gateway
class.
But
you,
I
don't
think,
that's
the
be
all
and
all
there
could
be
other
ways
to
do
this.
That
are
better,
but
I
think
that
it
is.
C
C
At
the
end,
I
think
we
want
to
end
up
with
the
same
sort
of
thing
as
you
do
with
the
official
case,
conformance
where
you
run.
There's
a
specific
sonoboy
set
of
set
of
command
line
flags
that
you
pass
to
it,
and
then
it
gives
you
a
a
test
output
file
that
you
then
pr
into
a
specific
repo.
That,
then,
is
reviewed
by
the
those
repo
owners
and
they
give
the
thumbs
up
and
merge
it
in,
and
then
that
says
that
thumbs
up
emerging
is
we
are
conformant
for
this
specific
kubernetes
version.
C
The
corollary
to
that
is
that
you,
the
conformance,
has
to
be
versioned.
It
has
to
be
versioned
by
the
bundle
version
probably,
but
it
has
to
be
versioned
by
some
version
of
that.
Basically,
you
can
only
be
conformed
to
a
specific
version
of
the
other
gateway.
You
can't
just
be.
You
know
conform
it
to
latest
or
something
like
that,
whatever
your
conformance
is.
It
has
to
have
the
caveat
that
it's
a
specific
version
and
the
tests
and
stuff.
A
Yeah,
I
think
I
I've
been
thinking
too
about
about
what
you're
describing
there
of
how
you
write
conformance
tests
against
any
of
this
right,
and
I
think
that
that's
a
good
point.
We
want
this
to
be
something
that
can
be
programmatically
understood
by
conformance
tests.
Like
you're
saying
you
know,
I
you
know
the
simplest
way
I
can
think
to
write.
A
conformance
test
is
to
say
this
is
a
test.
It
requires
an
implementation
that
supports
gateway,
http
route
and
gateway
class.
A
A
It's
almost
that
lower
level,
whereas
what
conformance
profiles
seem
most
useful
for
me,
this
may
be
me
missing
the
boat
on
this,
but
what
I,
when
I
think
of
a
conformance
profile,
it's
a
very
useful
way
to
describe
to
users
of
gateway
api
that,
if
you're
looking
for
an
l7
proxy
here
are
your
implementations.
If
you're
looking
for
an
l4
whatever
here
are
your
implementations,
so
you
can
kind
of
group
things
very
in
in
very
well
known
and
defined
buckets,
and
maybe
there's
an
other
category.
A
G
I
tend
to
tend
to
feel
a
little
bit
more
towards
james's
point
of
view.
I
think
doing
something
like
you
know,
saying
like
on
the
crds
and
saying
you
support
http
route
and
you
could
have
levels
of
support.
So
you
could
you
know
the
support
could
be
core
meaning
you
support,
you
know,
obviously
just
core
or
it
could
be
core
and
extended,
meaning
you
support
all
of
extension
or
maybe,
if
you,
if
you
only
support
like
some
of
it
extended,
it
could
be.
G
You
know
core
plus,
so
you
know
you
know
just
be
like
a
a
a
a
string
of
possible
values
right,
you
know,
so
you
know
or
a
string
of
keywords
right
core
extended
plus,
I
don't
know
sit
all
right,
but
it
would
make
it
fairly
easy
to
look
at
at
the
capabilities
you
need
and
fair.
You
know
at
a
high
level,
see
if
they're
there,
the
one
of
the
issues,
I
think
I
I
see
with
the
profiles
is
trying
to
agree
what
should
be
in
a
profile.
G
C
Yeah,
I
think
that's
100
fair.
I
think.
Maybe
I
didn't
do
a
good
job
of
making
it
clear
that,
in
my
mind,
the
conformance
profiles
are
only
ever
around
what
we
class
as
core
conformance.
So
a
conformance
profile
is
like
I
support
effectively.
Performance
profile
is
syntactic
sugar,
for
I
support
gateway,
gateway,
class
reference
policy
http
and
the
conformance
profile
may
only
mandate
that
you
support
the
core
support
for
supported
fields
for
each
of
those
types
and
then
extended
is.
C
C
You
probably
won't
support
all
of
the
all
of
the
extended
fields,
and
then
there
needs
to
be
a
very
detailed
way
for
you
to
lay
out
exactly
what
extended
fields
you
do
support,
and
I
don't-
and
I
guess,
as
I
said
I
don't-
I
never
intended
that
that
the
extended
fields
be
included
in
there
that,
in
my
mind,
the
conformance
profiles
are
literally
syntactic
sugar.
For
I
support
core
conformance
for
this
for
the
following
set
of
resources:
that's
it
that's
all
they
are
and
that
you
know
not
that
it
does
not
include
extended
support.
G
C
Yeah,
like
I
think
literally
all
the
conformance
profiles
are,
is
like,
so
I
probably
should
just
update
this
to
make
performance
profiles
less
of
things.
They
are
syntactic
sugar.
They
are
how
we're
probably
going
to
end
up
talking
about
these
things
anyway,
like
you,
contour
is
a
layer,
7
ingress
controller
right
like
it.
That's
it
does
so
it.
C
You
need
to
say
every
time
that
you
specify
what
your
thing
does
that
hi,
my
name
mike
I
have
contour
and
contour
supports
gateway,
gateway,
class,
http,
router
and
tlsr,
but
not
physical
and
udp
route.
Right.
I
think
it's
much
quicker
to
be
able
to
say
contour
is
the
layer
7
ingress
control,
though
a
layer,
7
gateway,
api
implementation?
C
That's
all
it's
just
a
it's
just
a
convenience
thing,
but
I
agree
that
what
I
should
be
doing
in
this
thing
is
specifying
this
in
terms
of
the
supported
resources
and
being
more
clear
about
the
you
know
core
and
extended
on
those
resources,
and
then
at
the
end,
saying
hey
performance
profiles
is
I'm
proposing
performance
profiles,
be
a
syntactic
sugar
way
of
gathering
up
a
common
set
of
these
things,
and
talking
about
them
do
we
need
performance
profiles?
No,
do
we
need
performance
on
a
per
object
basis?
Absolutely.
G
C
So
this
is
where
again
like
in
my
mind:
that's
where
the
machine
possible
version
of
the
conformance
information
is
the
most
key
thing
right,
but
the
machine
possible
version
of
the
performance
information.
Basically,
is
your
column
in
the
checkbox
matrix
that
in
people
always
do
when
they're
doing
a
comparison
between
different
implementations
right
like
it
allows
you
to
programmatically
specify
which,
which
ones
are
ticks
and
which
crosses
for
you
right
like
and
that's
yeah,
so
everyone's
going
to
have
like
the
core
ones
at
the
top
for
like
yo.
C
C
So
and
that's
why
I
was
talking
about
like
when,
if
you're
a
person
who
doesn't
know
anything
about
the
gateway
api
and
want
to
be
like,
I
want
to
be
able
to
do
tls
right,
like
I
wanted
to
be
able
to
do
some
tls
functionality
like
you,
you
then
need
to
go
off
and
learn
all
about
how
the
api
works
in
order
to
learn
the
question
that
you
need
to
ask
the
mechanical
parsing
thing
to
know
which
one
does
what
the
thing
you
want
is
right.
There's
no.
C
All
I'm
saying
is
that
the
conformance
profiling
is
literally
just
a
syntactic
tree
to
help
people
understand
which
implementation
that
they
should
even
consider
looking
at,
because
yeah,
but
it's
not
and
like
again
you're
right,
I
should
just
throw.
I
should
just
probably
not
talk
about
this
and
let
this
evolve,
and
then
we
will
end
up
talking
about
it
later.
You
know,
like
that's
that's
what
I
think
will
happen.
C
Is
that
we'll
end
up
putting
things
into
rough
buckets
and
we
will
end
up
talking
about
things
in
that
most
people
who
support
http
right
are
probably
going
to
support
pls
route
and
that's
what
the
performance
profiles
discussion
was
about.
It's
probably
not
worth
even
this
level
of
discussion,
so
it's
probably
worth
just
taking
it
out.
A
I
I
think
what
you're
saying
and
what
you're
both
saying
is
similar
in
it.
I
could
be
wrong
here,
but
I
what
I'm
hearing
is
that
conformance
profiles
are
entirely
a
concept
for
to
enable
to
simplify
users,
understanding
of
implementations
of
this
api
right
to
understand.
Oh,
these
are
the
kinds
of
things
that
are
built
with
this
api.
There
are
some
tools
out
there
that
do
l7
load
balancing.
There
are
different
tools
out
there
that
do
l4
load
balancing
and
that's
like
your
your
high
level
introduction.
A
These
are
the
kinds
of
things
that
are
possible.
This
is
not
meant
to
be
a
machine
parcel
concept.
If
I'm
understanding
correctly,
it's
meant
to
be
a
a
way
of
describing
similar
implementations
and
then
each
implementation
is
very
welcome
to
and
like.
We
should
have
that
kind
of
more
detailed
thing
of
we
support
these
specific
resources
and
these
specific
features
on
those
resources,
but
that's
like
kind
of
your
step
too
you're
you're,
I'm
digging
further
into
it.
A
Now
that
I
know
you're
in
this
category,
so
the
the
profiles
you're
describing
feel
more
like
ways
to
categorize
implementations
that
aren't
necessarily
used
as
useful
for
writing
conformance
tests
but
they're
very
useful
for
a
user
understanding,
implementations
of
the
api
and
where
they
fall.
Does
that
seem
accurate,
yes,
cool
and
does
that
seem
valuable
to
you?
Jeff?
Is
that.
G
Yeah,
I
think
that
to
me
it's
just
that
it's
again,
if
you
start
breaking
it
down
into
what
is
in
those
particular
performance
conformance
profile,
you
know
what
is
that
going
to
be
and
start
you
get
into
the
issue
of
well.
If
it's,
what?
If
it's
something
you
know,
there's
some
aspect
of
it.
I
don't
want
to
support,
but
you
know
I'm
90
there.
G
You
know,
then
I
quote
and
not
conform
it.
Even
though
I've
got
you
know
very
likely
have
everything
that
a
user
might
need.
So
I
just
think
doing
it
at
the
high
level
the
crds
is
gets.
You
gets
the
user
in
the
in
the
general
ballpark
and
then
it's
going
to
have
to
be.
You
know
going
down
into
the
details
depending
on
what
they're
going
to
need
to
do
it's
it's
kind
of
like
what
trying
to
think
what
is
it,
the
capabilities,
codes
and
cpus?
G
You
know
you
have
yeah,
mmx
or,
or
you
know
the
different
things
that
a
specific
you
know,
family
or
generation
of
a
processor
can
do.
You
know
extended
instructions,
that's
kind
of
where
you
have
to
look
at
the
specific
ones.
You
need
and
that's
what
I
think,
that
the
detailed
conformance
tests
come
in.
I'm
gonna
have
to
see.
If
you
know,
if
I
need
to
use
http
header
routing,
I
need
to
see
if
you
know
if
the
product
needs
it
does
support
that
specific
type
of
routing.
C
Yeah,
I
was
just
I
think,
even
in
the
the
sort
of
the
you
know,
which
I
agree
is
not
a
good
great
example,
but
like
even
in
the
case
of
like
cpu
capabilities
like
you
still
have
broad
families
like
amd
or
intel
right
like
or
you
know,
md64
versus
your
x86,
and
that
I
guess
in
my
mind,
conformance
profiles.
Are
that
broader
bucket
right,
like
it's
like
it's
not
talking
about
any?
C
It's,
not
really
it's
making
some
representation
that,
like
it's
just
hey,
this
is
focused
on
layer
seven
or
this
is
focused
on
layer
four
and
it
probably
if
you,
if
you
want
you,
so
that
it
means
that
the
people
who
are
doing
layer
four
stuff
can
be
like.
Look
if
you're
interested
in
doing
hdp
right,
don't
even
like
we're
not
for
you
like
we're,
not
don't
you
don't
bother
coming
and
looking
in
our
thing.
It's
not
for
us,
it's
not
for
you.
It's
a
very
much
a
high
level
classifier,
as
I
said
before.
C
I
would
be
like
absolutely
gobsmacked
if
we
don't
end
up
with,
like
a
whole
bunch
of
implementations,
that
support
gateway,
gateway,
class
reference
policy,
http
run
tls
route
and
not
tcp
rap
udp.
Rats.
Right,
like
you
know,
or
some
that,
will
you
they'll
support,
like
only
the
bearish
capabilities
of
tcp
around
up
right
or
something
like
that,
but
and
so
yeah.
That's
and
that's
what
I
meant
by
sort
of
conformance
profiles,
in
my
mind,
were
intended
to
be
composable
so
that
you
could
say.
Look
I
support
both.
C
You
know
and
or
I
support
some
custom
thing.
That's
not
a
performance
profile,
but
again,
I
think
that
I've
probably
lent
too
hard
on
that,
because
that
was
how
it
made
sense
in
my
brain,
but
it
does
make
sense,
as
you
say,
to
specify
for
the
spec
to
specify
this
in
terms
of
the
object
that
you
were
talking
about
and
then
performance
profiles
is
the
thing
that
arises
later.
If
we
need
it,
so
does
that
make
more
sense,
jeff
yeah,
I
guess.
G
I'm
almost
saying
and
I'll
drop
it
after
this.
This
is
just
my
view.
I
guess
I'm
thinking
more
of,
like
conformance
profile
almost
is,
but
you've
got
that
by
default.
If
by
saying
which
crds
you
support,
do
you
support
the
http
route?
Do
you
support
the
tcp
route
and
that
you
know
if
I
don't
support
http
route,
then
obviously
I'm
not.
G
C
G
A
A
Yeah,
okay,
well
yeah,
good
discussion.
I
think
we
can
keep
on
moving
from
this
one.
Let
me
move
on
to
this
versioning
one.
I
I
have
some
follow-up
on
this
to
do.
Thanks
for
the
feedback
on
this
one
nick,
I
I
think
you
had
good
suggestions
on
adding
examples
here,
but
I
just
I
just
want
to
throw
this
out
here.
I
think
I
only
made
this
pr
friday-ish,
maybe
thursday,
I
don't
know-
is
there
any?
A
Does
anyone
have
any
hesitation
about
this
one?
This
is
a
gap
that
started
as
a
dock
that
we
covered
at
least
last
week,
if
not
weeks
before,
but
this
is
really
talking
about
well,
there's
more
content
in
here,
but
I
think
the
most
novel
con
content
in
here
is
that
of
the
experimental
fields
and
how
we
plan
on
supporting
that.
A
A
A
Okay,
so
that's
a
gap
922
the
next
one
is
wait
going
way
back
in
time.
This
is
from
before
v1
alpha
2.
So
I
I
would
imagine
that
in
most
people's
mind
this
is
a
relatively
you
know.
You
have
to
go
back
and
pull
it
out
of
your
memory
here,
but
essentially
what
this
harry
already
added.
Some
basic
request
redirect
support
one
of
the
things
that
was
missing
from
that
was
path
redirect
support,
and
there
was
also
no
rewrite
support.
A
So
this
kind
of
bundles
path
redirect
and
redirect
and
rewrites
in
a
single
gap
it
they're
they're,
similar
but
different
concepts.
This
suggests
that
hey
we're
going
to
start
with
a
path
redirect
that
is
based
on
the
match
value.
This
is
something
that
I
believe,
you've
probably
seen
this
portability
section
down
here,
but
I
show
how
this
is
implementable
by
a
variety
of
implementations.
A
A
I
really
need
a
clear
example
here,
but
that
that
is
what
I'm
suggesting
for
path
redirect
here.
Any
has
anyone
looked
at
this
recently
or
does
anyone
have
feedback
after
having
seen
this,
maybe
for
the
first
time
in
a
while?
Does
this
line
up
with
what
you
were
thinking
a
path
redirect
might
look
like.
D
A
D
A
And
then
rewrites
are
are
very
similar
in
concept
to
what
we
already
have.
It's
just
a
new
kind
of
filter.
It's
a
request
redirect
it's
request,
rewrite
and
yeah.
I
I
don't
want
to
go.
We
we're
we're
almost
at
time
here,
so
I
don't
have
enough
time
to
run
through
every
detail
here.
But
just
if
you
have
time
to
take
a
look
at
this
gap,
I'd
be
appreciated.
I
am
hoping
to
get
this
back
in
to
our
next
release.