►
From YouTube: Gateway APIs Meeting (APAC Friendly Time) 20210823
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's
august
23
and
we
are
well
on
our
way
to
v1
alpha
2..
I
I
wanted
to
before
we
get
too
far
into
this.
I
wanted
to
highlight
a
discussion
harry
and
I
had
in
the
main
slack
channel.
I
think,
a
few
hours
ago
harry
you
mentioned
that
extension
ref
for
route
matches
is
a
rather
confusing
thing
right
now
that
we
may
want
to
consider
removing.
Is
that
a
good
summary.
B
Yeah
yeah
and
the
reason
for
removing
is,
like
you
know,
it's
sort
of
odd.
The
way
it's
structured
right
now
violates
some
of
our
principles.
It's
it's
complicated
for
implementations
to
actually
use
it.
So
you
know
we
introduced
it,
but
I
don't
think
we
have
like
good
use
cases
of
how
we
envision
it
will
be
used,
and
another
reason
is,
I
think,
it's
just
clunky,
like
we
haven't,
seen
matching
criteria
separate
from
the
route
resource
anywhere
in
the
kubernetes
ecosystem.
C
B
A
Yeah
my
perspective
here
is
that
this
is
this
was
a
solution
in
search
of
a
problem,
and
you
know
we
we
still
have
not
found
the
problem
that
it
solves.
So
you
know
everything
we've
been
talking
about
for
v1,
alpha
2
is.
If
something
is
unclear,
confusing,
not
used,
we
should
probably
remove
it.
I
think
this
is
a
good
example
of
this
being
something
to
remove.
D
D
Right,
I
see.
E
I
think
also
it's
just
because
the
way
that
it
works
is
a
bit
confusing
and
unclear
like
you
having
that
having
the
an
extra
crd
for
matching
of
this
kind
is
weird
and
it
feels
like
yeah
just
I
had
a
like
very
quick
look
at
the
spectres
and
I
was
like
yeah.
I
don't
even
know
how
I'd
go
about
implementing
this,
so
it
feels
like
one
of
the
ones
where
it
feels
safer
to
take
it
out
for
now
and
then
because
then
it's
not
a
breaking
change
to
remove
it
again.
A
We
yeah
this.
This
is
one
that
has
kind
of
snuck
along
for
a
long
time
and
I'm
glad
that
harry
brought
it
up.
It
did
to
me
it
feels
like
it.
It
suffers
from
a
lot
of
the
same
problems
we've
been
trying
to
avoid,
like
you
know
that
the
race
conditions
involved
here
of
okay,
this
calls
out
to
a
to
a
different
crd.
What,
if
that
doesn't
exist?
What?
If,
what?
If
it
changes?
How
do
you
propagate
those
chain?
I
don't
know,
I
don't
know.
D
Right,
like
I
think,
it's
more,
that
this
might
be
hedging
too
much
yeah
so
have
no
one.
Are
people
satisfied
with
the
current
set
of
matches
that
are
proposed?
I
think
this
was
a
carve
out
just
because
we
knew
that
there
were
lots
of
implementation,
specific
matching
algorithms,
and
I
just
wanted
to
be
sure
that
we
didn't
end
up
accidentally,
locking
people
away
from
the
what
they
wanted
to
do
with
their
configurations.
A
One
one
of
my
concerns
here
is
that
this
leaves
us
with
essentially
nothing
for
l4,
routing
and
and
in
terms
of
matching,
which
may
be
an
accurate
state
of
where
we
are.
I,
I
don't
think
anyone
has
implemented
any
kind
of
custom
matching
based
on
this
or
anyone
I
don't
know
of
any
plans
to,
but
that
that
is
something
like
I.
A
I
would
support
removing
this
at
this
point.
Just
so
we
we
have
a
clearer
path
to
to
beta.
You
know
beyond
v1,
alpha
2
that
is
not
breaking.
B
Yeah
I
mean
just
just
take
http
route,
for
example.
Let's
say
you
have
header
paths
and
query
parameters,
some
matches
in
there,
and
let's
say
there
is
a
meta
data
field
that
is
not
possible
there
now
expecting
that
some
implementer
would
introduce
that
via
a
different
crd,
and
you
would
have
this
split
between
these
core
matching
criterias
and
then
this
crd
that
doesn't
feel
right.
B
D
A
A
Yeah
well,
let's,
let's
get
let's,
let's
revisit
that
when
we
get
to
rc1
and
we'll
figure
it
out,
but
I'm
not
sure.
C
E
I
think
for
that
sort
of
removal,
though
I
don't
think
it
should
block
the
rc,
because
the
important
parts
about
the
rc
are
all
of
the
route
changes
and
the
other
stuff
we've
already
done
yeah,
so
I
don't
think
we
can
have
an
rc2
if
we
need
to
so
I
don't
think
it
should
see
so
just
in
terms
of
that
but
yeah.
Let's
talk
about
the
milestone
and
that
sort
of
stuff.
First.
A
Yeah
I'd
agree
with
that
and
I
I
would
say
I'm
aware
of
anyone
who's
actually
using
extension,
ref
or
anything
right
now,
so
I
can't
imagine
removing
it
in
a
second
rc
breaking
anything,
but
who
knows
okay,
so
v1,
alpha
2,
milestone
something
I
wanted
to
cover.
This
is
incomplete.
I
meant
to
add
a
couple
more
things
into
this
milestone,
but
I
I
kind
of
wanted
to
just
run
through
this
and
make
sure
that
we're
not
missing
anything
too
much.
There's.
Obviously
the
api
review
process.
That's
going
on
right
now.
A
That's
I
think,
pr
five
780,
I
don't
know
it.
It's
got
tons
of
comments,
but
this
is
very
much
underway
right
now,
this
one
we
need
v,
one
alpha,
one
equivalent
examples
for
v,
one
alpha
two.
I
I
think
someone
had
volunteered
to
take
this
one
on,
but
I
forget
who
is
actually
doing
it.
C
I
think
this
task
is
going
on
so
in
previous
meetings.
We
are
talking
about
migrating
all
the
examples
on
the
we
are
for
one
to
under
to
be
world
for
two.
I
was
working
with
the
some
of
the
examples,
gamma
ferrous.
Well
exactly
the
thing
we
are
talking
about.
A
Okay,
great,
so
that
should
cover
a
lot
of
these.
Is
there
any
kind
of
umbrella
work
for
whatever
isn't
currently
included?
In
an
example,
is
anyone
included
in
a
in
documentation?
Is
anyone
working
on
those.
C
You're
right,
I
think
I
mean
all
those
examples.
Yama
files,
as
well
as
the
the
guys
under
the
site
I
rc
directory,
will
keep
updating
and
being
reviewed.
A
Okay,
okay,
so
it
seems
I
don't
know
if
I
can
assign
no,
I
can't.
I
guess
I
need
to
be
a
member,
but
we
know
we
know
who's
actually
working
on
this.
It's
it's
shane
and
is
it
jimin?
Is
that
the
correct
pronunciation
yeah.
A
Susan
yeah,
okay,
cool
yeah,
so
I
think
these
are
this,
isn't
a
good
place
then,
and
let
me
know
if
I
can
help
out
with
any
of
this.
A
Thank
you
for
all
the
help
in
getting
these
these
updated.
This,
I
guess,
is
really
the
same
thing.
Thank
you!
Oh
I
guess
I
can
assign
both
of
you
I'll
go
back
and
do
that
to
the
other
one
too,
the
s
I
binding
and
bypass
for
tls
listeners.
This
one
got
stuck
somewhere.
What
what's
this
james?
Are
you
on
this
call
or
what
what
is
or
who's
working
on
this?
This.
E
Is
basically
clarifying?
This
is
clarifying
what
we,
what
we're
doing
about
domain
fronting
and
yeah
if
the
s9
binding
needs
to
match
the
host
name,
I
think
that
it's
you
this
is
yeah.
Basically,
we
just
got
a
document
like
that.
It's
something
like
you!
If
you
got
a
tls
first
name
that
http
her
name
has
to
match
the
ti's
first
name
is
kind
of
where
it
goes
to
the
end
of
the
day.
We
need
to
write
that
down,
as
I
must
I
think
is
that
what
do
you
think
james.
H
Okay,
great
james
or
either
of
you,
and
what
do
we
do
when
they
don't
match,
because
the
browser
doesn't
follow
that
right?
It
actually
does
have
mismatch
when
it
yeah.
E
So
yeah
yeah
the
you
can
definitely
run
into
problems
with
connection
coalescing
and
421
responses
in.
If
you
don't
do
this
sorry
but
yeah,
the
so
yeah,
we
had
to
do
a
bunch
of
fixes
and
contour
to
handle
this
case.
E
So
that's
why
I'm,
I
think
we
make
it
so
that
it's
they
must
match
is
in
the
spec,
and
that
means
that
the
spec
doesn't
currently
support,
doing
domain
fronting,
which
I
think
is
probably
okay
and
then
that
the
spec
mandates
that
those
that
those
things
must
match
and
then
not
having
the
matches
there
are.
H
I'm
not
quite
sure,
because
we
can't
just
say
that
what
browsers
do
are
invalid
because
everyone
uses
browsers
right.
So
so
the
what.
E
It's
the
what
it
is
is
the
if
they
don't
match
and
you're
holding
open,
http
2
connection
the,
and
you
send
a
thing
that
doesn't
to
one
that
doesn't
match
the
the
implementation
should
respond
with
a
421
to
send
it
off
to
to
say
no
re
retry
this.
So
we
can
you.
E
H
I
think
that's
already
that's
already
part
of
the
spec
right,
but
what's
not
part
is
they
both
are
like
star.example.com
in
both
of
them,
and
then
they
s
food.example.com
and
the
hostname
sparrow.example.com
yep,
because
the
spec
already
has
like
the
handshake
between
the
http
route
hostname
and
the
listener
host
name.
Okay,.
E
So
I
will,
I
will
have
a
cable
ready
to
spec
and
I'll
see,
I
think,
yeah,
as
you
said,
because
we've
got
that
match,
there's
not
actually
a
breaking
change.
It's
a
it's
a
thing
that
says
that's
maybe
on
the
hp
route.
That's
like
you!
Please
make
sure
that
you
do
the
correct
behavior
by
the
rfc.
E
That
will
mean
that
people
who
use
safari
get
broken
if
you
use
safari
the
mobile
version.
Sorry,
all
the
other
versions
of
safari
safari
does
not
respect
forty
ones
properly.
Yeah
there's
a
weird
behavior
there,
but
yeah,
but
we
should
do
to
the
rfcs.
E
H
Yeah,
oh,
it
does,
although,
if
I
remember
the
spec
right,
it
is
a
bit
more
nuanced
with
actually
the
certificates
that
are
involved,
that
you
play
a
role.
It's
not
just
that's
an.
E
H
E
C
E
No,
so
I
think
that
the
thing
that
we
should
codify
is
that
you
should
generally
work
towards
the
rc
and
that
yeah
assign
me
rob
you
should
work
work
towards
rfc
and
that
you
send
you
if
the
if,
if
you've
got
the
the
two
wild
card
case,
then
use
this
rfc
for
guidance.
It's
probably
the
best
we
can
do.
E
F
E
A
Okay,
I
will.
I
will
look
forward
to
that
pr.
I
lost
track
of
that
part
way
through,
but
yeah
looking
forward
to
the
pr
and
we
can
continue
discussion
there.
I
will
try
and
explain
it.
You
know.
E
A
Great
thanks
the
last
one
v1
alpha
2
feedback.
This
is
a
great
umbrella
issue
that
john
had
taken
on.
I
know
we've
had
some
discussion
on
here,
but
it's
not
clear
who
is
actually
following
up
with
all
of
these
different
ones.
A
F
I'll
have
some
capacity,
just
not
okay,
not
right
away.
What
we're
trying
to
get
these
done
in
time
for
the
in
like
a
week,
basically
right.
A
Yeah,
I
think
that's
a
good
goal
yeah.
I
I
think
a
lot
of
this
stuff
is
I
I
john
you're
you're,
probably
most
familiar
with
this
issue.
Do
you
think
any
of
these
should
block
an
rc1.
H
No,
if
I
remember
it,
most
of
them
are
pretty
small
yeah
like
they
just
most
of
them
are
really
docks
for
the
most
part.
That's.
A
A
H
C
E
F
A
Yeah
this
this
feels
like
something
that,
although
it's
small
in
scope,
I
guess
it
is
going
to
be
challenging
to
change.
F
A
Sorry
this
this
is
something
like
that
dan
had
also
called
out
as
something
that
did
not
make
sense
to
him
during
the
api
review.
So
I
I
know
this
is.
This
is
an
issue
that
not
everyone
likes,
but
I
think
we'll
need
to
convince
api
machinery.
That
scope
does
not
make
sense.
If
we
do
want
to
change
this,
and
that
seems
like
it
could
be
a
a
challenging
conversation
to
have.
E
A
Cool
okay:
well,
I
will
it
sounds
like
shane
is
gonna
spend
some
time
on
these
ones,
and
I
should
I
have
some
time
to
work
on
these
and
anyone
else
just
pick
some
of
these
off
and
comment
when
you
start
working
on
them.
C
A
Okay
sounds
good
somehow
I
screwed
up
the
assignees,
but
I
will
try
and
fix
that
up
in
a
little
bit
but
yeah.
I
just
feel
free
to
ask
me
any
questions
and
I'll
try
and
help
out.
A
Great
thanks
all
right,
so
we
keep
on
coming
to
this
rc1
timing.
Actually,
you
know
it
could
be
helpful
to
go
through
this.
Out
of
curiosity.
Is
this
pr
taking
forever
to
load
for
everyone
else,
or
is
it
just?
I
know
harry
you've
been
having
issues
loading,
this
feedback
vr?
Is
it
an
issue
for
anyone
else?
A
It
definitely
takes
a
long
time
to
load
yeah,
but
it
does
I've.
I've
had
mixed
luck
with
this
one.
I
sometimes
it
gets
into
the
state
and
comments
never
loads,
sometimes,
but
whatever,
if
it.
If
it's
working
for
people,
there
are
still
a
lot
of
comments
that
are
not
resolved.
I
think
I've
got
maybe
half
of
them
covered
in
this
pr
now,
which
is
a
good
chunk,
but
there
are
still
more
to
go
through
here
and
I
I
certainly
didn't
want
to
monopolize
updating
yeah.
A
I
know
we
really
do
need
a
contact
at
github
to
help
this
out.
This
has
got
to
be
a
good
edge
case
for
them
to
test
things
on,
but
yeah.
I
I
certainly
don't
want
to
monopolize
responding
to
the
feedback
here.
I
know
there's
been
others
that
have
been
commenting
and
responding,
which
has
been
very
helpful,
but
if
others
want
to
take
on
chunks
of
this
pr
in
terms
yeah,
okay,
this
this
happens
too.
A
That
would
also
be
very,
very
welcome
before
I
before
I
go
any
further
about
this
upstream
pr
that
won't
this
base
pr
that
won't
load.
I
want
to
highlight
this
pr.
I
think
this
is
nearly
complete.
A
I've
responded
to,
I
think,
all
all
the
feedback
and
it
could
use
another
round
of
review
for
anyone
who's
looked
at
it.
This
is
a
pretty
broad
scope
and
then
it
just
tries
to
cover
a
lot
of
the
the
feedback
we've
received
in
that
other
pr,
obviously,
not
everything,
but
I
think
it
gets
us
to
a
much
closer
state.
A
There
are
a
couple
api
changes,
maybe
there's
more,
and
I
don't
think
I
think
this
is
it
one.
No
such
gateway
class
is
removed.
It
was
deprecated
in
v1
alpha
one
and
I
meant
to
remove
it
in
v1
alpha
two
but
missed
so
that's
gone
now,
and
then
I
forget
whose
feedback
this
was,
but
there's
a
routes
field
on
listener.
A
That
was
suggested
to
be
removed
to
allowed
routes,
which
seems
more
accurate.
So
I
renamed
that
as
part
of
this
change
as
well
based
on
feedback
in
780.,
I
think
those
are
the
major
ones
there's
a
lot
of
godot
cleanup
and
variety
of
things
like
that.
But
these
are
well
specifically
this
one
would
be
the
one
that
would
stick
out.
I
think
yeah.
So
that's
that's
the
the
progress
on
this.
If
anyone
has
time
to
follow
up
and
review
this
I'd
love
to
get
it
in
soon.
A
A
E
I
have
spoken
to
some
people
at
github
about
this
sort
of
thing
before,
because
they
say
that
the
kk
repo
is
extremely
challenging
for
this
sort
of
thing,
yeah,
so
yeah.
The
impression
that
I
got
was
the
more
that
you
can
resolve
comments
and
stuff
like
that,
the
better,
because
if
those
are
lazy,
fetched.
A
A
I
with
that
said.
I
really.
I
really
wanted
to
split
up
the
rest
of
the
changes.
There's
a
couple
huge
ones
in
there
that
I
haven't
touched
yet
one
is
one
that
I've
been
trying
to
stay
away
from
forever
and
I
actually
got
the
order
of
this
wrong.
A
But
tim
has
pointed
out,
unfortunately,
that
it
is
time
for
us
to
switch
from
kind
to
resource,
and
it
has
finally
made
it
into
api
conventions
and
as
much
as
I
have
tried
to
push
back
against
this,
it
seems
like
it
is
inevitable.
So
I
I
chatted
with
daniel
smith
today
too,
just
to
make
sure
that
you
know
we
already
had
a
v1
alpha,
one
that
started
with
kind,
and
I
thought
that
might
be
enough
to
allow
us
to
stay
there.
A
But
the
strong
preference
is
for
us
to
move
this
api
to
resource
it.
As
a
way,
so
all
our
object,
refs
that
currently
use
kind,
should
move
to
using
resource
to
match
the
latest
set
of
api
conventions,
not
my
favorite
change
in
the
world,
but
it
is
something
that
I
guess
is
required
for
us
to
meet.
The
official
api
spec
become
an
official
api.
So,
given
that.
D
A
It
is
an
annoying
change.
I
I
was
really
hoping
to
avoid
it.
There
are
some
small
apis
out
there,
but
I
I
think
that
for
a
number
of
users
we
are
going
to
be
the
first
api
they
encounter
that
he
uses
a
resource
as
a
I
mean
and
they're
not
backfilling.
This
like
this
is
going
to
be
that
that
is
my
understanding
from.
D
B
E
D
D
E
Just
said
that
openshift
has
been
doing
this
for
a
while.
Can
you
talk
a
little
bit
about
the
experience
there
like?
Is
it
that
big,
a
change
for
users
to
move
to
using
resource
from
kind.
J
Not
that
I'm
aware
of
I
haven't
heard
any
complaints.
E
J
I
Right,
it's
supposed
to
be,
but
I
think
I'd
have
to
check,
but
I
think
we
we
automatically
convert
in
some
cases
that's
kind
of
wrong.
E
E
A
A
D
A
A
Okay,
well,
let
me
so
it
seems
like
we
need
an
issue
for
sure
we
can
either
mention
some
sig
api
machinery,
people
on
that
issue
or
send
out
another
thread
to
api
machinery
about
this
as
well.
A
This,
this
is
really,
I
think,
secondary.
The
other
concern
for
api
machinery
is
the
scope
in
the
the
name,
space
reference
well
the
to
distinguish
between
namespace
and
cluster
scope,
references.
A
Yeah
and
and
mike
I
has
a
reference
for
the
pr
and
and
there's
also
a
pr
that
updates
api
conventions.
That
came
a
little
bit
later
that
clarified.
So
this
this
discussion
has
been
going
on
with
api
machinery
for
quite
a
while,
it
just
seems
like
it
hasn't
been
widely
used
or
implemented.
Yet
is
is
my
read
on
it,
but
I
could
be
wrong.
A
A
Oh
great,
okay,
thank
you
I'll,
thank
you
harry
and
based
on
that
or
there's
already
an
issue,
okay,
whatever.
A
If
we
can
add
our
strongest
concerns
about
this
switch
to
that
issue,
I
can
send
an
email
off
to
api
machinery
group
and
reference
that,
maybe
maybe
we
can
have
any
kind
of
concerns
we
have
sometime
today
on
that
on
that
issue,
and
then
we
can
try
and
get
some
feedback
from
api
machinery
and
just
keep
that
discussion
going.
A
What
I'm
hearing
here
is
that
this
is
something
that
none
of
us
are
excited
about
and
we'd
like
to
at
least
see
if
we
can
survive
without
it,
but
we
will
do
it
if
we
have
to
obviously
yeah
and
does
that.
Does
that
sound
good
to
everyone?
A
Cool,
okay,
the
other
another
big
change
that
the
potential
change
that
came
out
of
the
v1
alpha
2
review
that
I
wanted
to
highlight.
I
know:
there's
200
some
comments
on
that
pr
now,
so
it's
hard
to
keep
track
of
everything
on
there.
I
tim
had
suggested
moving
to
a
ports
struct
on
gateway
listener.
A
This
is
something
that
I
think
originally
came
from
feedback
from
cal
that
I
I
could
be
misunderstanding
this,
but
I
think
he
was
asking
about
all
ports
and
that's
kind
of
where
I
followed
up
from
there
and
that's
where
the
conversation
ended
up
going
on
that
thread,
I
and
all
ports
being
the
ability
to
support
all
ports-
or
maybe
even
poor
ranges
at
some
point
being
another
potential
here,
and
that
those
conversations
are
ongoing
in
kubernetes
upstream
and
one
of
the
things
that
tim
pointed
out
in
his
feedback
on
our
apis
who's
reviewing
gateway
is
that
we
don't
want
to
lock
ourselves
into
a
corner
by
having
a
single
port
int
that
we
do
right
now
and
instead
we
may
want
to
have
a
port
struct.
A
A
I
don't
exactly
know
how
that
that
would
look,
and
it
just
feels
like
a
more
significant
change
than
most
the
rest
that
are
coming
out
of
this
api
review,
but
I
thought
that
would
be
worth
some
discussion
here.
Does
anyone
have
strong
feelings
about
a
struct
for
port?
G
C
G
B
F
You
go
jay,
fine,
I'm
gonna
go.
So
I
think
that
if
we
can
come
up
with
a
good,
not
derived
example
of
port
ranges,
then
it
might
be
worth
it,
but
until
we
can
come
up
with
that
example,
which
I
I
think
that's
what
the
last
person
who
was
talking
was
basically
saying
but
like
produce
the
example
and
then
yeah.
Maybe
it's
worth
it.
C
F
G
E
K
E
D
Yeah,
I
think,
like
there
are
paths
that
we
know
it's
just
that
it's
very
awkward,
especially
looking
at
the
ipv6
ipv4
transition
and
what
had
to
be
done
on
network
policy.
D
G
So
I
have
no
objection
to
to
wrapping
it
in
a
struct
that
seems
generally
harmless.
I
think
all
ports
in
the
context
of
the
gateway
api
seems
to
me
to
be
pretty
different
to
all
ports.
In
the
context
of
you
know,
network
policy,
network
policy
is
all
about
matching
and
all
poor,
any
and
and
being
able
to
match
from
any
port
seems
really
useful.
Being
able.
G
All
ports
seems
like
you're
doing
some
sort
of
low-level
traffic
filtering,
which
is
sort
of
a
use
which
is
really
a
use
case
that
we
haven't
discussed
in
much
detail.
G
I
Well
right
now
we
really
have
two
fields
for
port,
because
you
have
to
keep
in
mind
port
includes
I
mean
you
can
have
tcp
port
80.
You
can
have
udp
port
80..
So
right
now,
it's
a
little
weird
that
you
have
two
fields
we
have
protocol
and
we
have
port
for
the
port
number.
I
Presumably
this
port
struct,
I
imagine
it
would
substitute
both
of
those.
And
so,
if
you
have,
you
know,
if
you
have
http
one
or
two,
you
have
tcp
port
80
and
then,
if
you
also
want
quick
you'd,
add
another
port
for
port
80
on
udp
right.
E
Say
that
I
think
that
the
thing
there
that
we're
doing
is
we're
again.
This
runs
into
the
problem
that
the
the
protocol
field
currently
conflates,
like
sort
of
multiple
level
things
and
like
it's,
the
the
protocol
field
is
like
is
more
like
a
listener
type
than
our
actual
protocol.
E
I
think
that
the
thing
we
sort
of
suggest
for
what
makai
is
talking
about
is
that
you
should
have
actually
have
like
a
separate
listener
for
each
thing
that
just
references
the
center
routes
like
they're
they're
for
quick,
you
have
a
listener,
that's
udp,
80
or
whatever,
or
443
or
whatever,
and
then
you
you
choose.
The
same
set
of
routes
pointed
to
the
same
service,
and
that
should
be
the
guidance
we
give
rather
than
having
one
listener.
That
has
like
three
protocols
on
it.
G
E
G
E
G
Port
is
we
don't
specify?
We
just
specify
here's
a
port
we
have
to
do
I
mean
the
gateway
specifies.
I
want
to
talk
http
some
version,
and
I
want
to
be
on
this
port
and
anything
else
is
up
to
the
implementation.
You
can
say
we
interpret
that
to
mean
all
versions
of
http
on
all
the
appropriate
ports
and
we're
going
to
do
the
right
thing.
I
E
Yeah,
I
think,
yeah,
I
think
harry's
right.
This
is
probably
a
discussion.
I
think
the
the
thing
I
wanted
to
put
in
here
was
that
the
that
one
of
the
things
that
people
thought
about
all
ports
for
was
for
using
a
gateway
for
for
an
even
lower
level
gateway
so
like
an
ip
route
gateway,
gre
tunnel
gateway.
Something
like
that
that
that
works
and
more
like
that.
E
E
And
so
the
yes,
that's
that's
what
I
think
people
think
is
like
well,
you
know
how
you
could
extend
this
to
ip
route
or
other
sorts
of
custom
route.
If
you
don't
have
to,
if
you
mandate
a
port,
then
it
means
that
you
can
only
ever
go
as
low
as
layer,
4.
E
F
E
F
E
Yeah,
so
I
think
the
thing
that
we
need
to
do
here
is
we
need
to
be
a
little
bit
more
clear.
E
Yes,
I
think
we
so
it
it
is
100
clear
that
this
is
not
clear
right,
like
that.
This
needs
to
be
clarified
and
that
this
behavior
yeah
this
behavior
that
http
as
a
protocol
type
implies
all
of
this
stuff
absolutely
needs
to
be
specifically
explicitly
documented.
E
You
know
so
that
there
is
no
magic
that
it's
all
written
down
very
clearly
as
to
exactly
what
happens.
I
think
that
the
more
we
have
magic
happen,
the
more
we
risk
people
doing
different
things
which
we
really
really
don't
want
to
do
so
the
you.
I
don't
think
that
what
james
is
talking
about
is
necessarily
that
bad
idea.
As
long
as
the
the
expected
behavior
is
documented,
you
know
like
if
http
means
any
version
of
http
on
this
port
and
implementations
can
do
what
they
want.
E
A
A
One
is
that
the
use
cases
for
all
ports,
or
just
a
port
struct
in
general,
what
how
we
might
expand
that
in
the
future
and
what
that
could
look
like
and
then
the
second
one
is
really
the
where
the
conversation
led
to
which
is
related,
but
slightly
different
of
what
does
htp
mean
as
a
listener
or
protocol
type
on
gateway,
because
if
we,
if,
if
our
spec
currently
states
that
it's
specific
for
http
1.1,
that
is
probably
more
specific
than
we
want,
it
seems
so.
A
A
Yes,
okay,
cool!
If
anyone
wants
to
add
follow-up
issues
for
that,
that's
great,
if
not
I'll,
plan
on
it
after
this
meeting,
but
if
you
do
just
link
them
in
this
agenda
at
some
point
the
last
one
in
this
view
on
alpha
2
feedback.
I
just
tried
to
highlight
some
over
overall
themes
here.
The
other
one
is
there's
a
lot
of
discussion
about
validation.
In
this
case,
I
should
be
more
clear
about
our
web
hook.
Validation
because
that's
in
the
apis
directory
that
ended
up
getting
included
in
our
api
review.
A
I
I
think
the
fixes
for
the
web
hook.
Validation
comments
are
pretty
straightforward,
so
if
any
and
it's
actually
real
go
code
instead
of
just
api
type,
I
mean
everything's
real
go
code,
I
guess,
but
this
is,
if
you
want
to
write
a
little
bit
of
code,
this
is
our
fix
code.
This
is
a
great
way
to
do
that.
So
does
anyone
want
to
volunteer
to
fix
the
respond
to
the
comments
on
on
these
tests
and
fix
them.
A
Awesome
thanks.
I
hope
I
get
your
I
get,
hubby
asian
name
right.
Yes,
yes,
okay,
so
yeah
I'll!
Just
do
that
great!
Thank
you
all
right.
So
we've
gone
through
a
lot
here.
Let's
talk
about
rc1,
there's
a
lot
in
here
that
we
can
still
do
as
we
work
towards
the
final
v1
alpha
2
release,
but
we
need
to
figure
out
how
much
of
it
we
need
to
do
before
our
first
get
our
first
release
candidate.
We
thanks
to
nick.
We
already
have
a
great
change
log
ready
to
go.
A
It's
a
pr!
That's
been
out
since
sometime
last
week
anyway.
Thank
you,
so
we're
really
close
to
being
able
to
just
cut
a
release
candidate.
A
The
question
I
have
is:
do
we
want
to
try
and
get
any
of
these
changes
in
before
that
release
candidate?
My
guess
is
that
at
a
minimum,
this
port
struct
and
this
kind
of
resource
change
are
changes
that
are
larger
in
scope
and
going
to
take
longer
than
we
want
to
wait
for
an
rc.
Does
that
seem
accurate?
A
A
Okay,
so,
given
that
the
only
question
I
think
that
leaves
us
with
is
if
we
want
to
try
and
sneak
this
pr
in
the
one
that
fixes-
I
don't
know,
maybe
40
or
so
of
the
comments
from
our
signet
api
feedback
to
me
it
it
feels
close
enough
and
it
would
make
me
feel
a
little
bit
better
about
getting
a
release
candidate
in,
but
it
is
not
something
that
has
to
be
a
blocker
in
my
mind.
So
I
wanted
to
you
know,
see
what
others
think
here.
E
I
agree
we
should
get
that
one
in
and
then
cut
that
I'll
see
you
after
that.
The
reason
I'm
in
favor
of
getting
the
rc
out
as
soon
as
possible
is
that
it
lets
implementers
get
started
on
their.
You
know,
v1
alpha
2
support
immediately
yeah.
E
I
want
to
be
able
to
get
contour
moving
on
the
v1
alpha
2
support,
because
we've
got
huge,
there's
huge
code
changes
and
I
think
the
more
that
we
can
give
people
time
to
do
that,
and
then
they
can
come
back
around
and
fix
further
things
in
rc2
later.
But
this
this
gives
people
a
go,
multiple
point
in
time
to
2.2
to
get
everything
working
with
that,
and
then
we
can
add
more
things.
On
top
of
it.
A
Yeah,
no,
I
I
agree
with
all
that
with
everything
that
you
just
said
there
and
I
really
like
the
end
goal
here
of
being
able
to
as
we
release
v1
alpha
2,
be
able
to
point
to
at
least
some
experimental
implementations
or
something
of
the
api
that
you
know
have
already
been
working
on:
release
candidate,
one
release
candidate,
two
or
whatever
I'd
hate,
to
make
a
big
splash
with
v1
alpha
2
and
have
no
way
to
try
it
out.
A
You
know
this
is
something
that
came
up
at
the
last
meeting,
so
I
I
agree
with
with
everything
there
so
rc1
will
design.
E
All
right,
sorry,
I
try
and
keep
an
eye
on
who's
on
meeting
to
make
sure
that,
because
it's
easy
to
speak
over
each
other,
sorry.
C
Oh
yeah,
but
yeah,
that's
fine!
Actually
I
do
have
one
question
I
mean:
do
you
have
an
issue
tracking
the
webhook
validation.
A
I
know
so
let
me
I
I
can.
I
can
help
point
this
out,
but
it's
so.
This
is
all
in
that
massive
pr
that
it
will
probably
take
several
attempts
to
load.
But
when
you
actually
see
all
these
comments,
one
of
the
files
changed
to
specific.
Well
whenever
it
loads.
A
There
are
probably
15
comments
on
the
validation
in
here
specifically,
so
we
have
some
webhook
validation
files.
Just
I
think
validation.go
something
like
that
in
here,
where
we
have
some
some
code
that
could
be
cleaned
up
and
that's
all.
C
A
C
A
But
I
I
can
try,
I
I
think
I've
got
a
handle
on
most
of
the
comments,
so
I
can
try
and
make
them
an
easier
to
grab
format
and
at
a
minimum.
I
have
this
pr
loaded
on
another
browser
somewhere
that
I
can
share
so
yeah.
A
Yeah,
let's
okay,
so
good
good
to
bring
that
back
up
bowie.
I
think
you're
back
here
now,
so
I
I
think
we
generally
reach
consensus
among
whoever
was
on
the
call
at
the
time
that
we
were
fine
with
moving
with
removing
extension
ref
but
boy
I
wanted
to
make
sure
do
you
have
any
any
concerns
about
removing
this.
I
think.
D
A
Okay,
that
makes
sense,
and
if,
if
we
can
just
get
an
issue
today
or
tomorrow,
just
so,
we
can
add
it
to
not
another
gap
itself,
but
just
some,
so
we
can
add
it
to
the
milestone,
so
it
doesn't
get
lost
I'll.
Do
that
yep
and
then
okay,
great
all
right.
Well,
we
are
almost
out
of
time.
We
have
five
minutes
left.
We
have
confirmed
that
rc1
will
go
out
soon.
We
just
need
to
get
this
one
last
fix
and
well
set
of
fixes
in
and
we
we
have
plans.
A
I
think
assignees
people
have
volunteered
to
take
on
most
of
these
items,
which
is
great
in
the
last
few
minutes.
We've
got
a
little
bit
of
time
for
pr
and
issue
triage
here.
Is
there
anyone
anything
that
anyone
wanted
to
highlight
anything
that
we
need
to
take
a
another
look
at
here
that
I've
missed
covering
so
far.
B
A
Well,
we
still
have
this
this
big
opportunity
to
make
a
breaking
change,
which
we
hope
not
to
do
for
future
releases.
So
yeah
completely
agree
with
that.
Let
me
run
through
the
pr's.
Real
quick
here
looks
like
everything
has
been.
Is
it
does
anyone
have
a
pr
that
just
needs
one
last
round
of
review,
that's
kind
of
gotten
stale.
A
I'll
take
silence
it's
great,
I'm
going
to
I'm
going
to
keep
on
reviewing
these
pr's
as
we
go.
We
have
so
so
little
time
left.
I
don't
think
it's
worth
trying
to
get
into
any
one
of
these
pr's.