►
From YouTube: SIG Network Gateway API meeting for 20230919
Description
SIG Network Gateway API meeting for 20230919
A
This
meeting
is
being
recorded,
hello,
everyone
and
welcome
to
the
September
18th
edition
of
The
Gateway
API
sync.
As
always,
this
meeting
is
covered
under
the
kubernetes
code
of
conduct,
which
effectively
boils
down
to
be
nice
to
one
another.
So
please
do
be
nice
to
one
another
throughout
the
meeting.
If
you
need
to
interject
or
ask
questions,
please
use
the
raise
hand
feature
in
Zoom.
It's
very
helpful
for
us
to
coordinate
questions
and
comments
and
stuff
like
that
and
keep
things
flowing.
A
A
Don't
think
I
see
anybody
that
I
haven't
seen
before
so
I
think
we'll
go
right
into
the
agenda
unless
anybody
I'll
take
a
couple
seconds.
If
anybody
wants
to
introduce
themselves
or
talk
about
something
that
or
just
say,
hi
and
say:
hey
I'm,
working
on
Gateway,
API,
we'd
love
to
hear
from
you
we'll
give
a
couple
seconds
for
that
and
then
we'll
start
on
the
agenda.
A
C
Yeah
I
can
do
that,
so
we
released
081
last
week
and
this
was
to
fix
one
bug,
but
in
the
process
of
fixing
one
bug
we
created
another
bug
hurray,
but
accidentally
in
the
process
of
releasing.
Usually
we
would
tag
a
you
know:
a
v0.1
8.1
patch
release
on
the
release,
08
Branch.
Unfortunately,
we
mix
it
up
and
tagged
on
Main.
C
So
what
that
means
you
know
is
relatively
minor,
but
it
means
that
hbr
route
timeouts
actually
got
included
in
the
experimental
crd,
the
experimental
version
of
HP
route
I'm,
not
sure
what
the
best
thing
best
path
forward
here
is.
We
very
clearly
need
process
improvements
which
we
can
work
on,
but
also
it's
unclear
if
we
should
create
a082,
which
removes
timeouts,
which
were
accidentally
added
or
if
we
should,
just
you
know,
say
we're
weeks
away
from
a
1.0
release
that
will
include
timeouts
anyways.
C
So
maybe
it's
not
a
big
deal,
I'm,
not
sure,
but
feedback
is
very
welcome.
There's
you
know
comments
welcome
here
or
on
that
issue
also
that
links
to
a
slack
thread
that
has
some
more
conversation
as
well,
thanks
to
Steve
for
catching
this
one.
For
us,
sorry
that
we
we
missed
this
in
the
release
process,
but.
D
C
C
Yes,
it's
an
especially
fine
line
between
a
bug
and
a
feature.
This
time.
D
A
I'm
not
really
sure
if
we
should
remove
it
or
not
it
being
v0
and
then
backwards
compatible,
and
all
that
does
seem
like
some
git
hooks
as
much
as
everybody
hates
githubs
might
be
helpful
to
like
catch
these
sort
of
things
in
the
future.
Like
disallow
a
tag
on
Main
that
kind
of
thing.
E
C
Yeah
no
strong
opinion,
I,
yeah
and
I
I.
The
correct
thing
is
probably
082
that
that
rips
it
out
at
the
same
time
it's
coming
right
back
in
pretty
soon
so.
A
B
E
A
So
that's
what's
going
on
with
v082,
potentially
vp02,
let's
talk
about
1.0.
C
Yeah,
so
this
is
I
just
linked
the
release.
Blockers
I
tried
to
add
the
ones
that
I
thought
could
use
some
discussion
in
triage
at
the
end.
So
we
don't
need
to
spend
much
time
on
this
now.
Just
you
know
a
reminder.
1.0
is
top
of
mind
for
all
of
us.
C
We
are
really
working
to
to
make
sure
that
we
can
get
this
released
in
October,
which
means
you
know.
Realistically,
we
need
to
be
feature
complete
by
end
of
this
month.
This
list
does
look
longer
than
I
think
it
is
in
reality,
because
we
have
a
combination
of
PR's
and
issues
and
some
of
the
PRS
close
out
some
of
the
issues.
C
At
least
one
of
the
PRS
closes
out
multiple
issues,
so
I
think
we
are
getting
closer,
but
definitely
if
you're
looking
for
things
to
prioritize
as
far
as
review,
work,
etc.
These
are
the
things
so
yeah
and
and
if
there's
anything
that
we've
missed,
that
you
think
yeah,
we
really
shouldn't
release
1.0
without
X,
and
it's
not
on
that
list.
Please,
you
know
speak
up
sooner
than
later,.
A
I
do
that
yeah
and
then
this
one
we'll
do
this
one.
This
needs
to
be
done
kind
of
at
the
end,
but
all
of
them
are
pretty
much
accounted
for
at
this
point
and
I
think
we've
been
doing
kind
of
checking
in
as
maintainers
and
keeping
on
top
on
top
of
the
in
progress
to
make
sure
nothing
gets
out
of
band.
So
I
think
the
most
helpful
thing
that
we
can
get
from
people
right
now
is
very
prescriptive.
A
Pr
review
comments,
not
just
especially
during
these
next
few
weeks,
maybe
more
so
than
ever.
It's
always
good
to
do
this,
but
when
you
have
PR
review
comments,
we
do
want
them.
We
want
to
get
things
right,
make
sure
that
they
have
a
very
prescriptive.
This
is
the
action
to
take
to
resolve
my
comment,
rather
than
just
being
nebulous
and
kind
of
like
this
is
a
problem,
but
not
without
anything
to
do
about
it.
That'll
help
to
keep
things
moving
forward,
and
hopefully
we
can
get
that
RCA
RC
one
out
in
three
weeks.
E
Yeah
this
next
one
is
yeah.
This
next
one
is
a
sort
of
an
FYI,
I
kind
of
want
to
poke
people
to
start
thinking
about
this.
Now
it's
not
a
thing
until
much
later,
yeah
I
think
with
all
of
the
stuff
that
we've
been
doing
for
conformance
status
on
Gateway
class
I.
Do
think
that
it
would
be
very
handy
to
have
some
somewhere
to
be
able
to
put
equivalent
information
for
things
that
don't
use
Gateway
and
Gateway
class.
E
So
currently
that's
mesh,
so
I
think
that
it
would
be
really
talking
about
Gamma.
We
haven't
wanted
to
add
a
mesh
resource,
because
there
was
no
way
to
associate
the
mesh
resource
directly
with
the
service
and
he
should
be
around
binding,
but
I
think
that,
having
a
place
to
put
the
the
supported
features,
you
know
the
version
stuff
that
that
we've
been
talking
about,
adding
to
Gateway
class
status.
To
say,
like
hey,
does
this?
E
E
C
E
C
C
E
C
C
Cool
all
right,
I
I
agreed
I,
I,
I'm,
really
interested
in
a
mesh
Resource
as
well,
but
I'm.
Also
not
you
know.
I
I
think
I'd
defer
to
Flynn
Keith
John
Etc
there
as
well,
but
I
I,
think
we're
we're.
Adding
real
value
to
Gateway
class
and
I
would
like
to
see
some
kind
of
similar
concept
somewhere
on
the
mesh
side.
C
You
know
Shane
I
went
so
I
use,
dark
mode
on
GitHub
and
I.
Think
do
you
use
dark
mode
on
GitHub
as
well?
Yeah,
okay,
so
I,
don't
use
dark
mode
in
docs
and
I
dropped
it
in
docs,
because
I
thought
it
would
be
easier
to
see
in
docs.
But
unfortunately
it's
not
easy
to
see
here
either,
but
you
that
oh
Magic,
okay,
thank
you
yeah.
D
B
C
We've
been,
we've
been
looking
for
a
new
logo
for
for
a
bit,
but
I
will
be
the
first
to
say:
I
am
not
an
artist
by
any
stretch
of
the
imagination,
and
so
there
there
was
an
old
issue
asking
about
a
logo
for
Gateway
API,
which
kind
of
brought
back
to
life
and
I
actually
reached
out
to
Tim
Hawkin,
who
had
done
the
original
kubernetes
logo
and
I
just
asked
him
hey.
Do
you
have
any
tips
for
who
could
write?
C
You
know
come
up
with
a
Gateway
logo
for
us
and
he
had
this
idea.
He
will
not
be
offended
in
any
way
if
we
don't
go,
go
with
it,
but
this
is
basically
his
attempt
at
merging
the
kubernetes
logo
with
that
of
a
black
hole
and
seems
like
an
interesting
concept.
C
I
just
added
some
basic
text
to
it,
but
there's
there's
not
much
to
it.
The
the
actual
graphic
is
is
his
so
there's
an
issue.
That's
linked
in
that
thread.
Really
I
think
this
would
be
will
be
lazy.
Consensus
of
you
know
if
there's
if
anyone
wants
to
provide
Alternatives,
very
welcome
to
provide
alternatives.
C
If
not,
we
may
just
end
up
going
forward
with
this
I
just
kind
of
picked
end
of
September,
for
you
know
a
rough
date.
The
goal
is
to
have
a
logo
as
part
of
our
1.0
release.
C
This
is
currently
the
front
runner
because
it's
the
only
one
that
exists,
but
if
there
are
other
options
that
that's
great
too
and
Dave,
you
got
a
question
comment.
We're.
F
More
of
a
no
thing
I
saw
the
picture
in
the
in
the
notes
and
I'm
like.
Is
it
trying
to
be
a
black
hole
and
like
there's
no
way?
We
want
this
to
be
a
black
hole,
awesome
Wormhole,.
F
Technically
this
this
diagram
with
the
weights,
it's
gravity
right
and
then
black
logo
is
like
a
singular
point,
because
it's
heavy
I
would
recommend
a
compass
because
it
kind
of
ties
to
the
router
routing
bit
of
gateways,
but
you
can
draw
it
up.
Yeah.
It's
gonna
be
worse
than
this,
though
I
I,
don't.
A
D
A
E
D
E
So
yeah
an
Einstein
resin
Bridge
is
a
wormhole
that
connects
a
black
hole
to
a
to
the
postulated
white
hole
right.
A
E
D
E
A
C
The
table
Yeah
I,
think
the
the
biggest
blocker
here
is
as
much
as
we
can
come
up
with
ideas.
I
know,
I
personally
can't
translate
ideas
into
anything
that
looks
roughly
as
good
as
this,
but
if
anyone,
if
anyone
can
ideas,
are
you
know,
alternatives
are
very
welcome
here
if
we
do
have
more
than
one
I
anticipate
that
we'll
turn
this
into
a
vote
at
the
end
of
September.
If
this
Remains
the
only
option,
then
nothing
to
vote
on
right,
you
won't
be
about
yeah.
A
F
E
E
A
So,
anyway,
all
LOLs
aside
by
the
end
of
the
month,
if
we
have
no
other
contenders,
I,
think
we're
pretty
much
set
on
well,
we'll
pick
the
one
thing
that's
there
and
it
will
be
this
wormhole
depiction
and
if
anybody
has
anything
that
they
want
to
add,
even
if
you're
a
little
bit
of
you
could
even
post
something
that
was
kind
of
drafty,
I,
think
and
if
people
really
liked
it,
we
could
probably
find
somebody
who
who
could
like
you
know
level
it
up
for
us
or
something
if
you're,
not
if
you
don't
usually
do
graphic
art,
so
don't
be
afraid
to
put
something
out
there
that
you're
like
oh,
this
is
kind
of
blah.
A
A
A
C
Okay,
so
I
I
had
a
comment
here
and
I
thought
it
might
be
useful
just
to
discuss
it
in
a
larger
audience,
because
this
so
for
context,
Nick
added
a
this
PR
I
think
it's
very
simple,
straightforward.
In
the
sense,
it's
just
saying:
hey.
If
you've
got
more
than
one
parent
ref
pointing
to
the
same
resource,
they
both
need
to
specify
something.
That's
more
specific,
like
a
section
name,
a
port.
You
know
whatever
right
and
and
specifically
you
can
have
one
with
a
section
name
and
one
with
the
port.
C
They
either
all
need
to
have
section
name
or
all
need
to
have
port.
My
question
is:
what
happens
when
we
get
to
this
this
date,
which
is
now
called
parents
not
distinct?
C
E
I
agree:
it
should
be
I,
guess
I
had
kind
of
thought
that
we
should
not
not
accept
either
because
there's
no
our
usual
conflict
resolution
mechanisms,
don't
work
because
it's
by
definition
it
has
to
be
the
same
object.
So
there's
no
like
creation
time
difference.
There's
no!
Nothing
about
the
object
is
different.
F
C
Subsequent
ones,
I'm,
just
going
to
say,
are
not
distinct,
so
I'm
not
going
to
care
about
them.
The
the
thing
that
leads
me
to
that
preference
is
just
being
a
little
bit
kinder
to
users
in
the
sense
of
I
said
the
same
thing
twice
and,
and
the
new
thing
that
I
just
added
can
be
not
accepted,
but
I
don't
want
to
break
the
old
thing
that
was
already
there,
but.
E
I
think
that
there's
there's
I
agree
that
we
should
in
general
be
kind
to
users,
but
in
my
mind,
because
this
thing
is
in
the
same
object
pointing
to
the
same
other
object.
It's
like
look
I
feel
like
this
is
a
case
of
like
no.
No,
you
need
to
fix
your
stuff.
Like
you
know,
if.
E
C
I
guess
I
guess
that's
fair
I
mean
I
I.
Think
there's
two
different
sides
of
this
right:
the
there's
another
conversation
that
I'm
responsible
for
resolving
it.
It's
in
one
of
these
release
blockers
that
basically
describes
what
happens
when
a
resource
that
was
previously
accepted
goes
to
an
unaccepted
state
and
one
of
the
potential
outcomes
there
is
to
continue
to
run
in
the
last
known
good
state.
C
So
that
would
be
another
that
would
be
another
attack
on
the
same
thing
of
we
call
it
not
accepted,
but
if
you
happen
to
be
working
on
an
implementation
that
takes
a
an
awfully
long
time
to
transition
between
states,
you
may
not
want
to
yeah.
Thank
thank
you
for
pulling
this
one
up.
C
G
E
Yeah
well
yeah,
like
in
in
general
I'm
supportive
of
that
but
I
think
in
this
case,
because
both
of
those
references
are
literally
lines
away
from
each
other.
It's
like
it's,
not
there's
no
sort
of.
Oh,
you
could
accidentally
do
this.
It's
like
now.
You've
done
this
deliberately,
like
you
know
like
ideally
I,
would
reject.
I
would
want
to
reject
this
in
like
a
validation
report,
but
we
don't
want
to
do
that
anymore.
E
So
and
you
can't
write
a
cell
rule
that
will
implement
this
so,
like
that's,
why
I
think
removing
both
of
them
is
like
well
now,
you've
broken
things
and
you've
got
to
fix
it
straight
away
like
it's.
The
sort
of
the
tightest
time
frame
to
fix
this,
like
I
I,
understand
what
you're
saying
like
it's,
probably
not
a
big
deal
to
just
accept
the
first
one,
but
we
need
to
very
clearly
document
that
if
you
do
this,
only
the
first
one
in
the
list
will
be
accepted.
E
You
know,
but
again,
the
problem,
then,
is
what
happens
if
you've
got
a
list
of
10
parent
refs
and
two
of
them
conflicting
and
the
the
one
that's
going
to
win
is
the
one
that's
fourth
in
the
list,
because
there's
three
before
it
and
then
there's
there's
the
third
one
and
the
seventh
one
that
are
conflicting
like
how
do
you
know
which
two
are
conflicting
like.
A
G
There
are
two
cases
right:
you
go
from:
no
parents
to
do
conflicting
parent
traps.
The
second
case
is
one
valid
Parent,
Trap
and.
E
There's
no
there's
no
way
to
tell
by
looking
at
a
single
record,
if
which
of
those
is
happening.
You
can
tell
if
you've
got
the
Old
State
and
you
see
an
update
that
gives
you
the
new
state
but
like
when
we're
talking
about
validity
of
objects.
You
cannot
count
on
the
fact
whether
or
not
you
have
observed
a
previous
state.
You
only
have
the
current
state
of
the
objects
to
look
at
like
in
terms
of
defining
what
the
correct
state
is.
E
B
C
Yeah
I
think
you're
you're
raising
a
good
point
that
it
one
one
approach
here
could
be
for
us
to
in
the
spec
not
make
a
difference.
You
know
say
this
is
an
invalid
State
and
you
can
fall
back
to
the
previous
again.
The
discussion
of
what
you
do
when
you
hit
an
invalid
state
is
going
to
be
depend
on
the
implementation.
C
Some
implementations
may
choose
to
fall
back
to
previous
snow
and
good
state,
and
others
may
choose
to
just
immediately
change
and
drop
or
whatever
that
that
may
be.
Maybe
that's,
okay
here,
the
other
thing
I
wanted
to
to
cover
and
I
think
I.
Think
that
would
line
up
with
what
Arco
saying
too,
because
I
think
article.
C
E
That
is
not
distinct
enough.
So
that's
the
only
time
when
this
is
going
to
arise.
Is
you
have
the
same
route
object
having
two
parent
refs
that
both
point
to
the
same
Gateway
object,
and
you
don't
have
enough
information
in
them
to
be
able
to
choose
which
of
the
listeners.
It
should
be
bound
to
like,
even
if
you
like,
the
thing
is,
if
you
have,
if
you
have
parent
Rift.
So
if
you
go
back
to
that
example
that
you
showed
Rob
the
that's
the
your
third
tab
from
the
right
chain,
yeah.
E
E
Yes,
so
only
having
the
name
of
an
object
means
that
you
should
bind
to
all
listeners
in
that
object,
not
any
one
particular
listener,
but
then
the
one
underneath
it
says
you
should
only
bind
to
one
particular
listener
right,
there's
literally
a
conflict
in
the
two
things
that
you
have
asked
for
here.
One
of
them
says
please
bind
to
all
listeners
and
the
other
one
says
only
bind
to
a
single
listener
like
it's
actually
not
possible
to
realize
both
of
those
at
once.
E
E
A
C
I
mean
you
already
had
that
problem:
I
mean
you
and
you're
gonna,
see
it.
You're
gonna,
see
hey,
there's
an
error
in
I
mean
hopefully
you're
gonna
see,
there's
an
error
in
route
status,
I
I,
also
Nick
Nick.
You
said
something
earlier
that
I
am
starting
to
question.
I
am
you
you
mentioned
that
hey?
Maybe
we
could
solve
this
with
cell,
but
you're
not
sure
if
it's
possible,
but
I
am
I,
think
it
would
be
ugly
but
maybe
possible
to
solve
this
with
validation.
E
Yes,
100,
it
would
be
much
preferable.
It
was
much
much
more
preferable
to
do
this
validation.
Yes,
because
then
asgar
says
in
the
chat,
then
then
you
never
have.
This
problem
come
up
because
either
the
route
points
to
no
parent
refs
or
it
had
at
least
one
valid.
It
had
at
least
one
valid
paragraph
beforehand,
and
you
you
it
doesn't
matter
that
you
can't
get.
You
can't
fully
reconcile
this
object,
because
the
object
has
never
persisted
with
the
thing
I
mean
the
the
objections
that
I
have
to
sort
of
the
last
known.
E
Good
State
thing
is
in
general
that
when
you
do
that,
the
state
of
the
the
declarative
state
that
you
have
requested
is
never
reachable
like
you
can't,
but
there's
nothing
to
indicate
that
it's
never
reachable
right.
Like
the
object,
you
you
know,
you're,
you
have
requested
a
state
that
is
not
deliverable,
and
but
you
don't
like,
there's
nothing
on
the
object
to
say
this.
Isn't
this?
Is
you
the
what
your
request
is
never
going
to
be
reachable.
C
What
well
hold
on
I
mean,
isn't
isn't
that
true
of
many
things
you
know
like
I,
I,
request
gateway
address
that
can't
be
assigned
right,
I'm.
C
E
E
You
know,
and
by
the
way
you
you're
still
running
with
the
old
version
of
the
config
like
there
needs
to
be
some
way
or
an
object,
to
make
it
very
clear
that
the
old
version
of
the
company
is
still
in
use,
and
there
needs
to
be
a
condition
that
we
had
or
something
like
that
that
lets
people
know
that
this
implementation
leaves
your
old
company
running.
It
doesn't
just
take
all
the
config
away
when
there's
conflict.
A
D
A
E
C
A
E
Be
long
yeah,
but
so
yes
I,
think
so
to
answer
the
question
like
it's
not
the
end
of
the
world.
If
we
have,
if
we
pick
a
winner,
yeah
like
as
long
as
we're
very
clear
about
which
winner
gets
picked,
that
is
not
a
thing
that
can
be
implementation
specific,
like
that
is
a
theme
that
has
to
be
defined
in
the
spec
I
like.
So
if
we
want
to
pick
a
winner,
then
that's
fine,
but
we
have
to
be
have
very
clear
rules
about
how
the
winner
gets
picked.
E
E
Yes,
the
the
most
specific
one
we're
winning
would
be
better,
but
again,
then,
which
is
more
specific
picking
a
section
name
or
having
a
port.
E
A
Well,
we
still
have
a
few
triages.
E
C
I
think
we
should
look
in
the
cell,
I
I
think
that's
it.
I
started
talking.
E
Go
ahead,
I'll
put
some
of
my
thoughts
on
on
on
this
comment
later,
when
I
have
a
chance
to
like
write
them
down
and
I'm,
also
when
it's
not
like
nearly
one
o'clock
in
the
morning
so
yeah
when
I
can
baby
walker
here,
but
I
do
agree
that
if
we
could
solve
this
problem
with
cell,
it
may
actually
be
better.
E
D
D
C
I
added
this
one,
this
one
is
one
that
I
think
could
use
another.
Look.
If
China
you
actually
pinged
a
bunch
of
people
this
morning,
I'm
a
little
concerned
on
this
one
that
we
may
be
missing
some
tests.
What
what
it
that
does
is
it
adds
a
universal
check.
So
those
are
always
scary,
not
not
Universal,
but
almost
every
conformance
test
calls.
This
function
of
Gateway
must
be
accepted,
or
something
like
that,
and
it
also
expects
that
every
listener
has
a
resolve.
Ref
specified
the
true
as
well
in
status.
C
I
think
that's
reasonable,
I'm
just
a
little
concerned
that
some
we
have
some
tests
somewhere.
That
intentionally
has
a
listener.
That
is
to
an
invalid
something
right
and
just
want
to.
You
know
if,
if
conformance
reviewers,
approvers
whatever
it
could
take
another
look
at
this
one,
it
would
be,
it
would
make
me
feel
better.
This
is
something
that
you
know
as
part
of
this
1.0
push
we're
trying
to
make
sure
everything
in
core
and
extended
has
conformance
test
coverage.
E
Yeah
I
mean
I
think
it's
important
to
be
clear
that
it's
okay,
that
implementations
need
to
change
this
Behavior.
If
they're
not
like
that's
acceptable
the
prob,
the
thing
that
would
not
be
acceptable
is
you
know
if
we,
if
this
forces
it
to
always
be
true,
and
we
have
a
conformance
test
that
relies
on
resolved
recipe
and
false,
then
that
would
be
a
problem
because
then
the
conformance
test
is
not
going
to
work
properly.
It's
not
going
to
produce
the
result.
E
D
A
So
I
will
try
to
take
a
look
at
this
and
anybody
else
who
has
some
time.
That's
a
poll
2247.
A
This
needs
needs
a
couple
of
extra
eyes
because
it
may
have
some
implications
a
little
bit
further
than
we
would
have
expected.
A
C
C
This
is
much
smaller
in
scope
than
it
was
initially.
This
is
really
just
labels
and
annotations
that
you
can
specify
in
Gateway
infrastructure
and
those
will
be
get
passed
through
to
related
resources
that
are
provisioned
as
a
result
of
the
Gateway
that
could
be.
You
know
in
cluster
or
otherwise,
John
I
think
you
also
added
some
well
I
know
you
also
added
some
other
guidance
in
here
that
could
probably
use
some
some
reviews
from
people
who
are
actually
writing
in
cluster
implementations
I.
C
B
I
particularly
want
to
call
out,
but
I
agree
if
you're
an
implementation,
please
take
a
look
and,
if
not
I,
think
I
addressed
all
the
comments,
so
unless
Rob
just
said
something
otherwise,
I
assume
this
is
yeah.
E
No
I
think
this
is
this
is
super
close
I
just
I've
just
got
to
do
and
I'll
do
another
pass
tomorrow
in
my
time
and
like
yeah
I
think
it
looks
pretty
good
to
me
just
having
a
very
quick
look
right
now.
B
B
Out
a
lot
of
stuff,
so
I'll,
probably
once
that
merges
open
up
a
new
one,
adding
that
stuff
as
a
follow-up
one
that
then
we
can
be
controversial.
B
This
was
intended
to
be
yeah,
very
small
and
not
controversial.
So.
E
B
That's
one
I
expected
to
be
controversial,
so
it
was
no
problem
here.
Yeah
I
was
just
waiting
to
see
how
much
we
had
to
whittle
away,
but.
E
E
E
The
thing
that
I'm
really
pushing
for
on
this
is
that
I
think
it's
really
important
that
we
sort
of
record
that,
for
a
variety
of
reasons,
in
the
clear
taxation
DP
case,
you
need
to
treat
the
hostname
match
as
sort
of
a
separate
level
level
of
matching
to
the
other
one
cause
in
the
TLs
cases.
It
happens
that
way.
E
Anyway,
you
have
to
you,
have
to
match
the
Sni
first
and
then
do
host
header
matching,
and
if
your
Sni
does
not
match
your
host
header,
you
can
cause
weird
security
Shenanigans
to
happen,
because
you're
sort
of
violating
the
the
agreement
that
you
made
with
your
with
your
TLS
match
you
sort
of
the.
How
I
would
summarize
it.
C
Yeah
and
I
I
asked
a
comment,
a
question
on
there
too.
That
I
think
is
basically
along
the
same
lines,
but
I
I'm,
interested
I
think
the
implementations
right
now
that
are
doing
cascading
here
across
listeners,
I
tend
to
be
nginx
based
or
related,
and
so
I'm
trying
to
understand
how
that
works
with
https,
because
it
does
at
least
seem.
C
You
know
possible
that
you
could
do
that
with
clear
text
hpe,
but
I,
don't
like
it's
not
clear
to
me,
what's
happening
for
HPS
and
it's
confusing
to
have
different
Behavior,
I
think,
but
also
like
you're,
saying
not
safe,
to
have
cascading
with
HBS
I,
don't
know
so
if
anyone
is
worth
so
so
again
for
for
a
little
bit
more
context,
this
is
I.
Think
the
comment
right
up
that
that's
in
in
screen
right
here
is
is
helpful
in
the
sense
that
you,
some
implementations,
are
going
to
Cascade
that
match
I.
C
Think
many
Envoy
implementations
are
not
going
to,
but
there
there's
a
mix
here
if
you're.
If
you
haven't
seen
this
before,
please
do
take
a
look,
because
your
implementation
almost
certainly
has
made
a
choice
here,
and
it
was
not
clear
in
the
spec
what
we
expected
and
we
are
trying
to
make
a
choice
retroactively
and
well.
There
was
there
was
Unwritten
expectations
that.
E
Expected
I
mean
the
shortest
way
to
say
this:
is
we
kind
of
expected
things
to
work?
The
way
that
they
do
an
Envoy,
For,
Better
or
Worse
was
that
it
was
the
original
expectation
and
like
yeah
the
standard
way
that
you
do.
The
nginx
rules
doesn't
work
like
that,
and
so
that's
why
you
know
the
a
lot
of
the
recommendations
here
it
like
is
like
hey,
you
know,
I,
don't
it's
not
fair
at
this
point
to
be
like?
E
No,
you
have
to
make
it
work
like
I'll
go
when
that's
not
how
your
implementation
works,
like
that's,
not
cool
but
like
equally.
That
is
absolutely
what
we
intended.
It's
just
that
we
never
actually
wrote
down
the
language
in
a
clear
enough
way,
and
so
now
figuring
out
how
to
write
the
language
down
in
a
clear
enough
way
is
one
problem.
A
F
A
D
C
E
C
E
E
So
like
once,
you
like
host
header,
whether
it's
host
name
matching,
is
done
before
any
other
matching,
regardless
of
whether
it's
host
host
matching
based
on
the
S
I
order
and
then
checking
the
host
header
matches,
the
SMI
is
actually
a
thing
that
you
should
do,
but
it's
it's
actually
not
straightforward
to
do
that,
but
but
all
the
other
matching
the
path
matching,
the
the
other
any
other
header
matching,
is
done
separately,
sort
of
in
Envoy
by
default,
and
so,
like
the
you
know
again,
like
I,
am
sorry
that
we
didn't
know
like
we
didn't
think
about
our
own
sort
of
biases
here
and
sort
of.
E
We
assume
that
that's
how
everything
worked,
but
again,
I
think
that
assumption
is
also
based
on
the
fact
that
for
https
you
have
to
match
a
hostname
being
the
Sni
first
before
you
get
access
to
the
uninterested
tracking,
and
it
is
very
important
that
you
make
sure
that
the
host
header
matches
the
exact
the
exact
host
name
that
was
used
in
the
in
the
certificate
negotiations.
E
E
So
yeah,
what
I
would
like
is
I
would
like
people
other
people
to
read
what
I
have
put
here.
I
understand
it's
very
long.
I
would
have
liked
to
have
been
shorter,
but
I
was
trying
to
make
say
it
in
a
few
different
ways
and
I
I
need
some.
We
need
some
more
conversation
on
this
one.
Unfortunately
yeah
perfect,
yes,
you're
right
John.
There
is
two
levels
yeah
okay
for
for
this
one,
so
Mikhail
said:
do
we
need
conformance
test
too?
E
Will
this
one
because
it
will
be
a
should
for
for
Clear
texts?
E
E
Yeah
yeah
I
know
yes,
so
to
some
extent
yeah,
but
like
I
mean
we
we
do
need
to
take
that
into
account,
but
like
yeah.
Yes,
we
need
to
take
that
into
account,
but
it's
very
hard
to
write
for
that.
Yeah.
B
I
know
I
totally
get
it
I
yeah
I
brought
this
back
and
everything
I
just
want
to
make
sure
that
folks
are
around
about
it
from
us,
but.
E
Cool
yeah
yeah
it
burned
us
that
burned
us
on
contour
for
some
time,
yeah
certain
certain
browsers
and
operating
systems
would
just
not
work
with
Contours
tiller
support
for
a
while,
and
it
took
us
a
while
to
figure
out
that.
That's
that
specific
HTTP,
HTTP
2
connection,
coalescing
and
four
to
one
redirects
did
not
work
under
certain
combinations
of
os
and
browser.
A
A
E
But
in
this
case
it's
a
bit
complicated
to
write
conformance
tests
for
it
as
well
like
yeah,
yeah,
absolutely.
A
A
C
Not
too
open
too
much
of
a
can
of
worms
here,
but
there
may
be
a
case
to
be
made
for
something
like
a
characteristic.
It's
not
really
a
feature,
but
it's
a
way.
An
implementation
handles
a
thing.
So
one
of
the
things
I've
been
thinking
about
as
I've
been
working
through
potentially
allowing
two
different
ways
for
implementations
to
handle
invalid
or
partially
invalid
routes
is
that
one
characteristic
may
be
falling
back
to
last
known,
good,
State
and
another
one
may
be
dropping
everything.
E
D
E
Yes,
I
know
I
think
yeah
this
one.
This
one
needs
more
discussion
on
it
and
sadly,
and.
A
G
I
see
that
a
similar
API
got
merged
right
back
in
TLS
policy,
and
so
to
me
this
is
sort
of
a
subset
of
those
fields.
So
if
I
can
get
any
guidance
on
what
I
can
add
remove
edit
in
this
PR,
that
will
be
great.
E
C
My
my
own
personal
perspective
is
this
belongs
to
an
API,
but
it
is
not
a
good
idea
here
to
rush
any
review
that
requires
thought
around
TLS
and
I'm
really
hesitant,
although
it
makes
sense
like
this
makes
sense
to
me
on
the
surface.
There's
just
so
many
different
considerations
here
that
I
feel
like
I
might
miss
if
I'm
not
super
careful.
Just
as
a
reviewer
and
my
bandwidth
between
now
and
1.0
is
very,
very
tough.
Very
limited
I
definitely
want
this
in
the
API
I.
C
Even
if
you
even
there,
maybe
you
know
I
mean
if
you'll
be
there,
but
either
way.
Yeah
after
it
would
be
great,
too
sounds
good.
Yeah.
A
Yeah
Nick
and
yeah,
Nick
and
Rob
can
add
on
to
this,
but
at
least
from
my
perspective,
it
seems
like
most
people
should
realize
that
gep
stuff,
if
it
isn't
a
release,
blocker
may
vary
at
bare
minimum,
may
not
get
any
attention
until
rc1,
which
we
expect
to
be
within
the
next
two
to
three
weeks.
Hopefully
bare
minimum
yeah,
but.
A
A
So
thank
you
for
bearing
with
us
we're
almost
to
the
finish
line,
but
it's
actually
the
starting
line,
so
yeah
that'll
be
fun
but
yeah.
Okay,
we
got
through
all
the
triage
I.
A
Just
in
time
yep,
thank
you.
Everyone
for
your
time.
We'll
see
you
next
time,
keep
in
mind
that
we
do
have
the
time
changes
and
I
still
haven't
gotten
the
calendar,
updated,
I'm.
Sorry,
I'll
get
the
calendar
updated
shortly,
where
the
I
think
we
get
one
more
Monday
meeting,
and
then
we
have
a
Tuesday
meeting
at
the
beginning
of
the
month.
So
just
keep
that
in
mind.