►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20220926
Description
SIG Network Gateway API Bi-Weekly Meeting for 20220926
A
All
right
welcome
to
the
Gateway
API
meeting
for
September
26th
got
a
few
things
on
the
agenda
to
get
through
a
quick
reminder.
This
is
a
kubernetes
community
meeting.
All
the
same
things
apply,
including
the
kubernetes
code
of
contact
in
general,
just
be
nice
to
each
other
and
feel
free
to
ask
a
question
at
any
point.
There
are
no
stupid
questions.
This
agenda
doc
should
be
editable
by
anyone.
A
So
if
you
have
something,
you
want
to
discuss,
feel
free
to
add
it
to
the
agenda
or
add
a
comment
whatever
it
is
with
that,
let's
get
started,
I
added
a
few
notable
things
that
merged
recently.
That
would
have
been
easy
to
miss.
A
First
up
the
makes
amazing
Gap
that
refactor,
so
much
about
conditions
has
emerged
after
many
comments:
lots
of
review
by
many
people,
so
thank
you,
Nick
for
pushing
through
on
that
one
pumped
to
see
this
one
get
in
and
now
we
just
need
to
implement
it,
but
I
think
we're
in
a
pretty
good
place
now
so
yeah
thanks
Nick
and
thanks
to
everyone
that
reviewed
it
next
up,
not
even
worth
opening,
but
reference
policy
has
formally
been
removed.
A
A
If
you
remember
a
week
or
two
ago,
I
made
a
PR
that
changed
our
crds
for
060
to
be
in
a
state
that
V1
Alpha
2
was
effectively
not
useful
or
not
usable,
in
the
sense
that
it
was
not
served
after
talking
through
that,
after
looking
at
the
harsh
transition
that
would
provide
I,
backed
out
one
step
and
have
proposed
this,
which
has
merged
of
a
marking
as
deprecated
marking,
V1
Alpha
2
is
deprecated.
So
anyone
trying
to
use
it
gets
a
warning,
but
they
can
still
use
it.
A
I
still
highly
highly
encourage
implementations
to
go
ahead
and
move
to
V1
beta
1
for
reads
and
writes,
but
this
gives
you
just
a
little
bit
more
time,
just
as
a
bit
of
a
reference
point
on
on
gke
I.
Think
I've
mentioned
this
before
we
have
a
policy
of
not
installing
Alpha
apis.
So
if
you're
using
the
Gateway
API
as
managed
by
gke,
it
won't
include
the
alpha
API
versions.
A
So
just
another
reason,
as
as
you
go
to
move
towards
U1
beta
1
as
soon
as
you
can,
but
this
does
give
just
a
little
bit
more
breathing
room
for
any
implications
out
there.
A
Cool
yeah,
with
that
the
051
release
looks
like
we've,
got
one
approval
on
this,
hoping
to
get
one
or
two
more
before
we
go
ahead
with
cutting
051,
but
this
changelog
ends
up
being
relatively
small
there's
one
tiny
bit
in
API
aspect
clarification
a
couple
web
hook,
cleanups
and
a
couple
conformance
cleanups,
but
I
think
this
will
be
a
good
release
to
get
out
and
hopefully
make
the
way
easier
for
060
next
time
any
comments
or
concerns
on
this
release.
A
Thanks,
okay,
we
are
flying
through
this.
The
last
one
on
this
Milestone
phase
was
to
actually
look
at
the
060
Milestone.
We
are
getting
closer,
but
the
time
is
ticking
down
and
as
we're
all
aware,
we're
probably
what
a
couple
weeks
before
we
really
need
to
have.
The
vast
majority
of
these
things
in
I
spent
some
time
going
through
and
pinging
people
just
to
see
that
you
know
most
of
these
have
someone
assigned
at
this
point,
but
if
there
aren't
people
assigned,
you
know,
please
volunteer
yourself.
A
If
you're
able
to
there
are
maybe
I'll
just
highlight
a
few
that
are
not
assigned
right
now,
don't
have
anyone
working
on
them.
One!
The
published
Web
book,
Docker
image
to
the
kubernetes
production
registry.
I.
Think
there
are
steps.
Yes,
Nick
is
linked
in
how
this
would
work.
This
really
just
requires
someone
to
go
through
a
few
steps
to
actually
make
it
happen.
B
It's
a
it's
a
really
good,
getting
started
one
as
well,
because
again
you
started
in
Cube
in
general
because
it's
going
to
require
making
PRS
to
a
few
Cube
repos.
So
if
you
haven't
done
that
before
it's
a
good
chance
to
have
a
crack
at
that,
that
said,
it
probably
isn't
a
blocker
for
060
yeah.
So
we
can
look
at
taking
it
out
same
for
the
admission,
workbook
I
think.
A
Yeah
I
agree
with
that
perspective
on
both
the
the
web
hook.
One
was
really
just
hey.
Can
we
be
automatically
scanning
these
for
our
vulnerabilities
I
reached
out
to
some
people
on
our
gke
security
team
to
see
what
kind
of
stuff
is
available
in
open
source,
all
open
source
kubernetes
already
for
this
we
seem
to
have
infrastructure
for
most
things,
but
I
I
don't
have
an
answer
yet,
but
if
anyone
else
is
familiar
with
what
we're
doing
in
Upstream
for
open
source
volume
tracking,
that
would
be
helpful
here.
B
A
I
think
I
think
that's
clear
enough
that
we
well,
you
know
let
GA
could
be
as
soon
as
070,
so
I
want
to
make
sure
we
don't
forget
about
it
in
in
that
time.
Hopefully,
I
did
that
right.
Okay,
cool
yeah.
B
A
All
right,
and
then
that
leaves
us
with
one
left
and
I
would
say.
This
is
the
same
thing.
I
will
stubbornly
leave
this
in
in
case.
Someone
has
time
to
to
take
this
on,
but
I
I
will
be
the
first
to
say.
If
it
doesn't
happen,
it
doesn't
happen
and
we
can
pull
it
there.
There's
just
some
weirdness
in
our
shell
script
around
verifying
examples
that
I
would
love
a
better
solution
for
this.
This
is
not
something
that
needs
to
block,
but
it
would
be
nice
to
fix
yeah.
B
Candice
pointed
out,
there's
no
issue
for
back-end
properties;
no,
there's
not
the
there
is
a
get
number
for
it.
That
was
a
one
two,
eight
two
I
think,
but
it's
not
in
it's,
not
a
blocker
for
the
release,
so
we
haven't
put
it
in
the
release.
If
we
can
get
it
in
before,
then
that
would
be
great,
but.
A
That's
that's.
Come
back
to
that
I
think
Candace.
You
added
that
at
the
end
of
the
the
agenda.
Let's
when
we
talk
through
it,
let's
see,
if
there's
any
kind
of
MVP
that
we
can
fit
in
and
then
we
can
try
and
add
that
and
add
some
kind
of
issue
to
track
that
back
to
the
Milestone
but
yeah.
Thank
you
for
calling
that
up.
A
Okay,
I
think
everything
else
is
covered
here.
I
think
at
least
four
of
the
remaining
open
issues
are
related
to
status.
So
once
that
Gap
gets
in
will
be
good,
I,
don't
know
if
there's
a
better
way
to
represent
that
in
here.
I
thought
about
you
know
only
leaving
the
gap
in
and
then
removing
the
other
ones
from
the
Milestone.
But
I
don't
know
if
that
really
helps
or.
B
A
A
All
right
I
will
leave
it
at
that
thanks
everyone
Okay,
so
the
last
one
is
well
the
last
one
that
I
added
to
the
agenda.
I
definitely
have
lots
to
talk
about
with
Candace's
proposal.
Next
I
came
up
with
a
weekend
project
type
thing
that
I
think
everyone
has
said.
A
We
should
do,
but
no
one
had
the
time
to
do,
but
there's
a
very
basic
CLI
tool
that
basically
reads:
Ingress
resources
from
a
cluster
and
converts
them
to
HP
routes
and
Gateway,
and
it
is
ugly,
but
it
works
at
least
for
me
on
my
cluster.
So
you
know
that
that's
a
thing
I
once
I
got
it
working
I
was
trying
to
figure
out
where
exactly
it
live,
it
should
live
and
what
a
scope
should
really
be.
So
I'll
talk
about
the
scope.
A
First,
I
think
the
idea
should
be
that
it
should
read
Ingress
resources
from
yamlara
cluster
and
have
the
same
out
options
for
output,
so
you
can
either
write
to
yaml.
Which
is
far
safer
or
if
you
really
trust
the
tool,
you
could
have
it
right
right
back
to
your
cluster,
but
I
don't
know,
but
I'd
recommend
that
for
many
people
with
that
said,
I
I
think
we
really
would
need
to
limit
this
to
just
a
subset
of
specific
implementation.
Annotations.
A
But
not
you
know,
there's
so
so
many
ways
we
could
expand
this,
so
it
was
very
difficult
to
to
maintain.
But
if
we
just
start
with
just
the
Ingress
spec
and
maybe
some
annotations,
that
would
go
a
long
ways
I
think,
but
all
this
is
to
say,
I
need
a
place
to
open
source.
This
properly
and
I.
Think
the
best
place
is
a
kubernetes
six
repo.
B
It
sounds
pretty
reasonable
to
me.
I
think
Sanjay
from
Contour
had
talked
about
doing
the
same
thing,
so
yeah
I
think
it's
definitely
come
up
before
it'll
be
really
good
to
have
a
sort
of
standard
place
to
go,
especially
for
the
Ingress
one
I
think
it
would
also
be
really
nice
if
there
was
some
way
if
there
was
some
way
that
we
could
like
make
it
that
people
could
Fork
it
to
have
their
own
to
write
their
own.
Like
cider
Gateway
thing
you
know
like
I
know
from
Contour.
B
We
always
wanted
to
write
our
HTTP
proxy
to
Gateway
API,
yeah,
converter
and
yeah,
like
it'd,
be
really
nice.
If
there
was
some
relatively
easy
way
to
help
people
do
that
either
building
a
tool
or
letting
you
Fork
it
and
and
add
your
own
and
add
your
own
one
or
something
yeah,
but
yeah
I.
Think
it's
a
great
idea.
A
Yeah,
okay
yeah,
so
this
is
this
is
just
a
baseline
I
think,
there's
a
lot
of
room
to
expand
and
make
it
better
and
I
think
everybody
has
has
said
at
various
points
that
they
want
to
build
this
so
I'll,
just
I
wanted
to
have
some
base
basic
thing
that
works.
C
We
should
throw
together,
like
I,
think
this
is
worth
creating
an
issue
and
then
just
throwing
together
the
requirements
of
like
hey.
We,
we
generally
think,
for
example,
one
of
the
things
that
that
seems
clear
to
me
is
like
it
should
be
importable
as
a
library,
so
people
can
extend
it
like
versus
just
like
a
standalone
controller.
That
can
only
do
one
thing
like
things
like
that.
A
D
Yeah
the
two
issues
when
I
put
it
in
comments
that
it
may
need
to
be
a
controller
because
people
creating
less
resources
dynamically,
but
I,
think
the
biggest
problem
is
with
all
the
annotations
that
people
are
using
Ingress
I
think
we
need
to
prioritize
creating
policy
attachments
for
all
those
annotations
or
import
the
annotations
as
kind
of
Poor
Man's
policies
going
forward.
D
I,
don't
know
what
I
was
looking,
for
example,
at
persistent
station
audition
in
nginx
and
few
others
to
figure
out
how
to
do
an
issue
and
I,
don't
know
what
what
is
a
plan
I
mean
if
you,
if
you
are
doing
this
kind
of
conversion,
what
will
happen
with
them.
A
Yeah,
so
I
I
don't
want
to
set
expectations
too
high.
This
is
this
is
a
weekend
project.
This
is
really
just
Ingress
back
to
Gateway.
Current
State
I
would
like
to
open
source
it
because
I
think
it's
broadly
useful,
but
it
is
not.
You
know
a
perfect
project
in
its
current
state.
What
I
would
say
is
that,
even
if
you're
going
from
Ingress
spec
to
Gateway
spec
without
any
annotations,
there's
still
some
things
that
get
lost
in
translation,
it's
it.
It
is
not
a
perfect
translation.
A
You
know
like
if
it's
a
controller
per
se,
it's
going
to
be
risky
that
there's
and
then
I
I
tried.
You
know.
I
I
took
some
nginx,
Ingress,
annotations
and
and
others
and
translate
those,
but
it's
a
subset,
a
small
subset
of
nginx
Ingress
annotations
that
can
even
be
translated
over
to
the
spec
as
it
exists
today.
A
So
it's
also,
you
know
it's
a
good
reminder
that
there's
still
plenty
more
work
that
we
can
do
now
that
our
goal
is
to
support
every
Ingress
annotation
out
there,
but
there's
still
more.
We
can
do
yeah.
D
I
don't
know
I
mean
it's
a
very
good
start,
and
it's
great
that
you
start
coming
I'm,
just
saying
that
it
will
be
very
useful
while
you
are
doing
or
people
who
are
doing
this
to
take
make
a
catalog
of
annotations
that
they
find
and
try
to
translate
and
prioritize
those
for
adoption
as
policy
attachments
and
kind
of
feedback
into
the
into
the
apis
that
we
have
here.
B
We
should
be
like
finding
a
way
to
put
it
in
the
apis
first,
if
possible
or
or
you
build
a
policy
attachment
first
to
show
how
Like
A,
Change
Would
work
or
something
like
that,
but,
like
I,
think
yeah,
like
I,
don't
I'd
really
like
us
to
sort
of
I.
Think
the
Leaning
too
heavily
in
a
policy
attachment
is
a
good
way
to
end
up
with
a
very
balkanized
like
landscape.
Here
that
where
you
know
everybody
supports
their
own
sets
of
policy
things
and-
and
you
can't
move
between
things.
B
So
we
should
try
really
hard
to
make
sure
that
we
put
things
into
the
the
specs
of
the
resources
as
far
as
possible
and
only
use
policy
attachment
when
it
when
we
really
need
to
and
again
we
kind
of
built
that
with
the
idea
that
it's
for
setting
the
things
that
you
want
to
say
like
for
all
the
things
in
this
Gateway,
it
must
be
at
least
it
must
be
TLS
1.3
or
something
like
that
right
like
or
it
must
have
this.
B
You
know
that
sort
of
thing,
but
that's
that's
what
a
policy
attachment
thing
is
really
intended
for.
I
know
that
it's
on
my
list
to
do
to
sort
of
write
up
to
put
a
little
bit
more
of
that
context
into
the
policy
attachment
docs,
because
there's
not
a
lot
of
examples.
Sort
of
in
the
world
yet,
but
yeah
I
just
wanted
to
remind
everybody
that,
like
it's
much
better
to
have
that
stuff
be
present
in
the
spec
rather
than
in
a
separate
meta.
D
Disconnect
here
or
some
confusion,
either
I'm
confused
or
well
probably
I'm
confused,
so
they're,
two
things
that
are
when
I
talk
about
policy
attachment
I'm,
not
talking
about
vendor
attachment
or
custom.
You
know
tender,
specific
attachment
and
I'm
talking
about
official
apis
that
can
be
defined
by
by
the
working
group,
because
we
cannot
put
everything
in
HTTP
route
and
right
now
we
have
Gateway
and
HTTP
route.
D
So
there
is
back-end
policy,
which
is
a
perfect
place
to
put
some
stuff,
but
there
will
be
need
for
some
other
resources
where
you
put
the
annotations
that
currently
are
used
in
Ingress
that's,
and
they
definitely
need
to
completely
agree
with
me.
So
you
need
to
be
defined
by
the
working
group
as
proper
crds
with
all
the
review
and
everything
else,
but
they
are
different
between
difference
between
vendor
specific
age,
vendor
Define
its
own
and
something
that.
B
Yeah
yeah
sure
and
like
I,
think
the
the
one
of
the
reasons
that
is
the
Robin
I
suggested
building
policy
tension.
The
way
we
did
is
so
that
it's
possible
for
vendors
to
like
make
their
own
policy
resource
and
be
like
I
think
we
should
do
it
like
this,
and
this
is
how
it
will
work,
but
then,
with
the
intent
being
that
yeah
we
end
up
where
it's
possible,
we
end
up
with
common
ones.
There
are
some
things
where
it's
not
possible
again.
The
canonical
example
is
timeouts.
B
You
can't
have
a
project
like
a
Gateway
API
timeout
policy,
because
every
data
plane
does
timeouts
differently.
So
you
need
to
have
like
an
Envoy
timeout
policy
and
an
nginx
timeout
policy,
or
something
like
that
right
like,
but
you
can't
have
one
that
sits
in
this
project
that
generically
defines
timeout
policy,
so
yeah
I
think
so
that
it's
not
so
much.
It's
not
only
vendor
specific.
It's
also
like
data
plan
specific
but
yeah.
So
that's
that's
the
point
that
I
was
trying
to
make.
There
is
just
yeah
like
I'd.
B
Really,
yes,
yeah
I,
agree
that
you
know
like
vendor
specific
policy.
Stuff
is
is
a
good
way
to
end
up
in
the
same
place
as
annotations,
and
that's
why
I'm
like
yeah,
let's
be
careful,
let's
be
very
measured
about
what
we
make
into
like
official
policy.
Things
is
what
all
I'm
trying
to
say.
We
should
try,
where
possible,
to
not
use
policy.
We
should
use
spec
Fields
wherever
it
makes
sense.
That's
all
I
was
trying
to
say.
A
I
would
I,
you
know
just
another
go-to
part
down
this
rabbit
hole,
but
I'd
agree
with
what
you're
saying
Nick.
Just
you
know,
we
we
spent
time
going
into
timeouts
I
think
was
a
good
example
or
retries
and
and
these
kinds
of
things
and
the
variation
between
even
just
Envoy
and
nginx
and
what
was
supported,
there's
very
little
overlap
very
similar,
but
it's
hard
to
build
a
stack
around
things
that
have
just
different
Behavior.
A
But
if
you
look
at
the
current
implementations
of
this
API,
a
huge
portion
are
based
on
Envoy
and
another
chunk
are
based
on
nginx,
and
so
even
if
we
can
agree
that,
here's
how
you
do
it
for
Envoy
and
here's
how
you
do
it
for
nginx.
As
an
example,
that's
going
to
be
a
huge
win
compared
to
one
per
every
implementation.
D
So
I'll
give
you
I
was
looking
even
more
about
things
that
are
common
between
nginx
and
persistent
station.
For
example.
How
do
we
declare
that
the
particular
service
is
using
sticky
sessions
or
persistent
sessions?
That's
kind
of
the
whole
debate
right
now
in
istio,
community
and
obviously
nginx
has
an
annotation.
There
is
AJ
proxies
I
mean.
Is
that
four
or
five
annotations,
that
kind
of
do
the
same
thing,
but
adding
yet
another
one
for
istio,
so
that's
probably
a
place
where
common,
it's
just
an
example.
C
Yeah
I
think
there's
two
things.
One
is
Rob
thanks
for
this
project,
I
think
this
has
been
on
everyone's
mind
and
it's
like
it's
great
and
we're
getting
started.
C
It
did
bring
up
this
interesting
rabbit
hole
about
how
do
we
support
all
the
stuff
that
Ingress
has
reminded
of
us
of
I
recommend
making
that
itself
its
own
topic
versus
having
it
nested
under
Rob's
projects
just
from
a
gender
perspective,
because
I
think
we
could
go
talk
about
that
for
quite
a
while
I
wanted
to
make
sure
we
get
to
the
next
one.
B
Yeah
I
agree:
yeah
I
think
I
agree
that
we
should
Park
this
one
and
yeah
talk
about
it.
Another
time
but
yeah
as
I
said.
I
think
that
there's
definitely
more
to
talk
about
here.
So
yeah,
let's
roll
on
to
the
next
topic,
Rob.
B
B
A
Yeah
I
I
mean
I,
think
that
would
be
awesome.
We
just
need
someone
to
volunteer.
Hopefully
this
kind
of
tool
will
make
that
a
little
bit
easier.
My
Shane
and
I
are
giving
a
coupe
con
talk
in
a
month
approximately
on
that
very
topic.
So
maybe
we
can
translate
some
of
our
content
there
into
a
guide
as
well.
This
tool
was
inspired
by
that
talk
happening
so
yeah.
A
A
Yeah
good
question
all
right:
Candace
I
think
you're
up
next
on
the
back
end
properties
proposal
I
know:
you've
been
working
towards
something
like
for
the
Skip
and
you
shared
a
doc
last
week.
I
want
to
say,
and
maybe
we
can
go
through
it
today
and
just
talk
through
the
different
options.
You're
thinking
of.
E
Yes,
definitely
so
my
first
option,
which
you
guys
reviewed
was
was
not
quite
what
you
what
we
had
in
mind,
but
that,
but
now
Nick
has
made
another
review
and
I
think
things
are,
will
change
again.
B
I
think
it
would
be
really
useful
to
talk
through
what
you've
got
here,
because
I
think
the
process
that
you've
gone
through
here
is
actually
really
common
for
people
for
when
you
want
to
add
something
to
an
API
like
thing,
and
so
it's
I
think
it's
worth
sort
of
walking
through
the
things
that
you
looked
at
and
like
you
know
why
those
are
like
were
those
are
not
ideal
and
then
the
and
because
it's
a
really
easy
thing
like
it's
the
same
thing
that
I
did
the
first
time,
I
tried
it
and
add
something
to
an
API
like
this
and
so
like,
because
it's
so
common
to
sort
of
walk
through
this
process.
B
I
think
it'd
be
good
to
walk
through
it
with
everybody
and
then
and
sort
of,
and
then
I
can
sort
of
give
my
reasons
why
I'm
like
I
think
we
could
do
this
better
and
that
way,
you
know
we
don't
have
everybody
having
to
sort
of
go,
do
three
rounds
of
going
backwards
and
voids
which
I'm
really
sorry
for
by
the
way.
B
Yes,
so
walk
us
through
like
what
you
like
what
what
your
thoughts
were
and
like
why
you
sort
of
did
things
this
way
and
yeah
I.
Think
that
then,
then
we
can
talk
about
like
you
know
what
what
are
my
reasons
for
saying,
I
think
we
should
do
this
differently,
yeah.
E
Okay,
so
in
the
first
iteration
of
this
that
I
came
up
with
I
thought,
I
was
interpreting
the
the
Gap
to
the
letter,
but
I
wasn't
really
so
my
my
idea
was
that
I
would
was
to
make
it
as
generic
as
possible.
E
So
it
starts
with
you
know,
just
this
map
of
capabilities
where
the
name
of
the
capability
is
mapped
to
a
backend
object
capability,
which
is
just
a
group
kind
name
value
which
is
a
a
a
pattern
that
I
had
seen
pretty
often
in
in
Gateway
API,
and
we
don't
use
it
pretty
pretty
very
often,
but
Gateway
API
is
using
it
and
and
I
can
understand
the
reason
why,
because
you
want
to
you
know
this
has
to
be.
E
This-
has
to
appeal
to
a
lot
of
people
who've
already
implemented
and
are
using
Gateway
API.
So
it
turns
out
that
that
was
you
know.
So
if
you
go
on
a
bit
further,
it
may
be
easier
to
understand
what
the
heck
I'm
thinking
of,
if
you
actually
look
at
the
examples,
so
here's
a
back-end
capabilities
list
that
just
has
TLS
re-encrypt
on
it
and
there's
this
TLS
re-encrypt
is.
E
Is
the
map
entry
string
and-
and
this
is
a
list
of
the
backend
capability-
the
backend
capability
object,
drafts
I,
think
I
called
it
or
something
so.
There's
version,
client,
server,
client
search,
private
key
CA,
certs
back
insert
and
then
I
thought.
E
If
anybody
had
any
fields
that
were
not
listed
in
here
already
that
they
needed
to
use
as
a
part
of
their
implementation,
then
they
could
just
add
another
name
name
value
pair
to
extend
that
with
you
know,
with
a
particular
field
that
they
need-
that's
not
represented
in
this
list,
so
it
turns
out
that's
a
little
bit
too
too.
Generic
and
I
think
rob
you
mentioned
that
it
probably
would
be
better
and
then
I
think
I
interpreted
that
wrong
as
well.
E
E
B
Yeah
thanks
for
thanks
for
running
us
through
it
kind
of
so
I,
think
the
this.
This
comes
down
to
the
stuff
that
people
have
learned
from
like
core
kubernetes
resources
and
stuff
like
that
over
time,
and
so
the
the
first
pattern
that
you've
got
there,
the
sort
of
the
map
of
string
destruct
is
really
attractive.
For
all
the
reasons
you
talk
about
right
like
that.
That
is
really
easy
to
add
to
add
new
values,
and
it's
really
easy
to
extend
the
biggest
problem
with.
B
That
is
that
it's
really
easy
to
extend
and
and
so
like,
for
a
thing
where
we're
trying
to
make
it
so
that
we
want
people
to
like
we
want
it
standardized
and
we
want
people
to
be
doing
the
same.
Things
like
having
it
be
too
easy
to
extend
is
actually
not
good
in
the
same
way
that,
because
that's
when
you
end
up
with
like
annotations
everywhere
and
and
or
or
things
like
that,
right
and
so
it
you
know,
I
completely
agree
that
that
that
is
the
easiest
way
to
make
something.
B
That's
we
actually
want
there
to
be
a
little
bit
of
friction
to
extend
like
you
know
in
that
you
need
to
come
together
with
other
people
and
agree
on
what
the
common
behavior
is
before
you
can
extend
it,
and
so
that's
why
something
a
bit
more
like
what
we're
talking
about
in
the
second
one
is
slightly
more
attractive
because,
because
it
sort
of
makes
you
come
and
talk
to
everybody
and
you
and
people
can't
implementations,
can't
go
and
go
and
like
do
their
own
thing
and
then
end
up
making
that
sort
of
their
standard
and
then
end
up
with
everyone
not
able
to
interoperate,
because
everyone's
done
it
in
slightly
different
ways.
B
It
kind
of
sucks
having
to
go
and
like
talk
for
like
three
months
about
like
what
exactly
is
TLS
recrypt
or
something
like
that
right.
You
know
it
kind
of
sucks,
but
but
what
that
means
is
that
you
end
up
with
something
that
is
like
the
you
know,
the
implementable
common
denominator,
I,
don't
want
to
say
lowest
common
denominator
because
it's
often
like
quite
a
bit
higher
than
you
would
expect.
But
but
it's
like
the
thing
that
everybody
can
implement:
John.
B
I
can
show
you
yeah
so
and
so,
like
the
yeah,
so
I
think
that
that's
sort
of
the
the
reason
in
my
mind
for
the
first
one
I
think
in
the
second
one,
the
the
thing
that
I
was
thinking
when
I
originally
wrote
the
gift
was
about
having
it
be
like
a
reference
to
a
meta
resource
that
sort
of
wraps
service.
B
That
then
holds
these
things
so
and
that's
what
tightly
binds
the
service
to
the
the
the
the
back-end
stuff
to
the
service,
and
also
it
gives
you
the
property
that
you
don't
need
to
Define
it
on
every
HTTP
route,
where
I
think
that
the
you
know.
So,
if
you're
defining
a
service
in
multiple
HTTP
routes,
then
then
putting
it
as
like.
A
meta
resource
means
that
you
don't
need
to
do
it
lots
of
times.
Every
time
you
reference
it.
You
know
HTTP
route.
B
You
do
as
part
of
the
HTTP
route
definitions,
because
that's
really
what
it
is
I,
don't
you
know
I
think
John's
probably
got
some
stuff
to
say
about
like
how
that
might
play
into
the
gamma
efforts,
but
but,
like
the
I,
think
that
that
I
think
that's
the
big
question
between
like
the
option,
two
that
you've
proposed
here
and
like
the
punitive
option.
Three
that
I
was
talking
about,
which
is
like
having
a
meta
resource,
is
the
reason
you
would
do
that
over.
B
What
you've
got
here
is
to
have
the
to
sort
of
have
it
so
that
you,
you
can
own
a
service
and
some
sort
of
service
wrapper
object,
and
then
anybody,
you
included,
who
refers
to
that
service,
could
sort
of
refer
to
the
service
wrapper
object
and
know
that
all
of
the
settings
will
be
picked
up
and
if
you
change
the
settings
more
importantly,
you
change
them
everywhere,
where
they're
used.
So
if
you've
got
like
10
HTTP
routes,
you
can
change
it
once
and
it's
all
done
and
you.
B
How
often
will
people
be
using
10
HTTP
routes
to
one
service?
I,
don't
know
right.
So
maybe
it's
not
worth
us
doing
that
so
I
probably
talked
enough
John.
Do
you
want
to
pick
up.
F
Yeah,
just
like
kind
of
a
high
level
note
and
I
sorry
I
didn't
read
the
whole
dark.
I
don't
seem
to
have
access
to
it.
So
this
may
not
be
super
in-depth
comment,
but
well
I.
Think
we
see
a
lot.
Is
that
a
lot
of
times
the
back
end
properties
are
defined
by
the
service
producers,
not
the
service
consumers.
F
I,
don't
have
much
more
to
say
about
that.
I!
Don't
have
a
concrete
suggestion
on
how
that
that
should
look,
but
I
think
that's
a
use
case.
That's
at
least
worth
exploring
or
talking
about.
E
Sorry,
everybody
I:
we
have
it
set
up
at
work
if
I
use
a
Google
doc.
I
can
only
share
it
one
by
one,
with
with
certain
email
addresses.
I
can't
share
the
link
and
have
it
be.
E
You
know
like
there's
no
way
for
me
to
group
share
it
I
I
guess
I
could
have
made
it
in
my
own.
I
didn't
realize
this
when
I
started,
I've
never
shared
outside
of
our
company,
so
well,
not
widely
outside
of
our
company,
so
yeah
I
can
add
it.
I
can
add
anybody
who
wants
access
to
it.
But
after
we
talk
about
it
here,
I
am
going
to
put
this
into
put
the
resulting
agreement
into
into
a
PR,
and
then
we
can
talk
about
it
more
there.
E
The
reason
I
had
it
in
a
Google's
dot.
Google
doc
was
I.
I'm
I've
never
done
one
before
for
this
group,
so
I
just
wanted
to
have
a
little
chit
chat
back
and
forth
before
I
actually
embarrassed
myself
with
a
pull
request.
B
I
should
be
clear.
You
have
absolutely
not
embarrassed
yourself
with
this
right
like
this
is
really
good
work
and
and
again
sort
of
me
me
being
picky
about
it.
I'm
sorry
is
not
a
reflection
on
like
the
work
that
you've
done.
B
It's
just
like,
there's
stuff
that
you
don't
know
you
don't
know
until
you
start
trying
to
do
this
and
don't
use
map
of
string
to
struct
is
one
of
the
sort
of
the
the
guideline
for
API
guidelines
that
is
really
easy
to
miss
and
yeah,
and
everyone
does
to
start
with
be
included,
so
yeah
don't
feel
bad.
E
So
John
and
Keith,
if
anybody
else
who
wants
access
now,
I
can
try
to
set
it
up,
but
I
expect
that
we'll
go
through
this
pretty
quickly
and
if
you
can't
see
it
on
here,
I'll
definitely
set
it
up.
If
you
want.
B
Yes,
one
thing
that
we
could
try
next
time,
though,
is
one
of
us
who
has
unrestricted
accounts.
We
could
create
you
the
doc
and
then
you
can
give
you
edit
access
and
then
yeah.
Then
we
can
share
it
to
just
the
whole
Kudos
div
or
something
like
that.
Yeah.
B
A
E
A
E
E
Okay,
so
option
two
took
it
a
little
bit
further
and
I
I
changed
it
to
just
be
a
back
and
back
end
refs
back
as
a
part
of
the
back
end,
ref
struct,
which
only
has
as
its
other
object
back
end,
object
reference
and
and
weight.
E
So
and
then
that
is
defined.
The
spec
itself
is
defined
as
a
listing
of
the
actual
items
that
we
might
want
to
add
in
there
re-encrypt
websocket
protocol
and
I
guess
we
would
just
keep
adding
more
as
as
we
go
on
as
we
as
we
want
to
add
more
different
backend
capabilities.
So
that
would
you
know
that
would
mean
that
you
know
people
couldn't
extend
it
on
their
own.
Yes,
we
would
all
have
to
agree
before
this
got
extended.
E
There
would
be
some
guard
rail
in
place
before
anything
changed
in
here,
and
you
know
just
a
listing.
E
You
know
just
a
translation
into
what
we
would
what
we
would
see
in
a
struct
as
opposed
to
a
map
stirring
of
map
string
to
structs
listing
yeah
and.
A
B
I
think
that
that's
what
as
I
said,
I
think
that's.
Where
sort
of
one
of
the
definitional
things
we
sort
of
need
to
agree
on
comes
down.
Is
that
you
know?
Is
this
part?
Is
this
the
responsibility
of
the
person
who
owns
the
HTTP
route
or
owns
the
the
service
or,
and
is
that
always
going
to
be
the
same
person?
And
so
that's
the
thing
that
we
need
to
sort
of
say:
yep,
okay,
yeah!
B
We
can
be
pretty
confident
that
the
person
who
owns
the
HTTP
right
is
the
person
who
owns
the
service,
and
so
it
doesn't
matter
but
and
they're,
probably
only
going
to
be
one
or
a
small
number
of
HTTP
routes
like
with
a
service
as
a
back
end.
In
that
case,
it's
fine
to
have
a
bit
of
history
about
because
it'd
probably
make
because
it
means
you're
not
adding
a
whole
a
whole
nother
resource
to
just
to
hold
this
information.
B
That
is
a
little
bit
analogous
to
what
John
John
was
saying
about,
like
producers
and
consumers
like
if
you,
if
you
think
that
people
are
going
to
be
making
HTTP
routes
to
sort
of
consume
other
people's
Services,
it
doesn't
feel
like.
That
would
be
the
case
to
me.
It
feels
like
the
person
who
owns
the
HTTP
right
is
probably
going
to
be
the
service
owner.
Most
of
the
time
is
just
my
sort
of
initial
think
about
it,
and.
A
Yeah
and
then
also
I,
think
all
your
points
are
are
spot
on,
but
I'd
add
one
other
consideration
here,
and
that
is
does
the
underlying
thing?
That's
provisioning
that
back
end
have
a
way
of
configuring,
say
timeouts
differently,
depending
on
the
route.
The
request
is
coming
from,
for
example,
some
systems
you
may
have.
You
may
only
be
able
to
have
one
timeout
configuration,
sir
whatever
for
that
back-end
Service,
as
opposed
to
other
systems
where
you're
basically
creating
a
separate
copy
for
each
one.
A
So
at
least
in
some
systems
it
seems
possible
that
you
may
only
be
able
to
configure
this
kind
of
config
once
per
service
and
so
having
it.
You
know
in
every
HP
route
anytime
a
backend
ref
is
specified,
especially
if
you
have
you
know,
five
routes
could
become
complicated
if
those
vary
in
some
way.
B
Yeah
I
think
John,
you
put
a
thing
in
the
chat
saying
need
both.
Is
there
any
way
you
could
yeah.
F
Sorry
I
I'm
trying
to
do
too
many
things
at
once.
Yeah
I
was
saying
it's
like
Rob
you're
you're
right,
that
is
complicated,
I,
don't
know
if
it's
necessarily
A
blocker,
because
you
could
in
theory
make
multiple
back
ends
with
just
the
settings
different
and
maybe
it's
you
know,
implementation
specific
like
when
we
looked
at
policy
attachment.
We
were
like
here's
all
the
places
you
can
attach
to
it
and
I
think
we
talked
about
this
exact
problem
and
we're
like
yeah,
it's
fine.
F
This
implementation
can
attached
to
all
of
them
this
one
just
these
ones
like
no
problem,
so
it's
possible
that
something
like
that's
needed
here.
What
I
meant
by
my
obscure
comment
was
that
I
think
in
some
cases,
like
I
mentioned,
it's
useful
to
have
producer
oriented
config,
but
it's
absolutely
on
the
route
level.
F
I
think
is
useful
as
well
like,
for
example,
the
back
end
May,
the
backend
may
say:
I,
don't
know,
use
use
TLS
or
something,
but
whether
or
not
we
actually
want
to
add
TLS
is
dependent
on
where
we've
come
from
right.
Maybe
it's
already
is
TLS
encryption.
We're
just
passing
it
through,
for
example,
I
mean
that
one,
maybe
we
could
say
we're
smart
enough
to
figure
it
out,
but
I'm
sure
there's
other
cases
that
are
like
that
right.
F
So
not
all
these
settings,
like
the
back
end,
usually
has
a
lot
of
say
in
it,
but
maybe
they're,
not
the
the.
Only
the
only
way
that's
used.
B
Yeah,
that's
a
really
good
point.
I
think
there's
definitely
some
confusion
here,
because
we
use
the
example
of
TLS
in
in
the
policy
documentation.
B
So,
to
my
mind,
the
one
of
the
advantages
of
doing
the
the
putting
this
in
the
backend
ref
one
is
a
being
able
to
be
able
to
have
a
place
where
you
say:
okay,
if
you're
making
a
policy
to
set
like
the
TLs
version,
your
policy
is
like
messing
with
this
field.
Right,
like
it's
overriding
the
value
of
this
field
or
you
know,
defaulting
the
value
of
this
field
right.
B
So
you
can
say
at
the
Gateway
level
we're
going
to
default
the
value
of
TLS
to
version
1.3,
but
you
can
override
it
inside
your
HTTP
route
by
setting
the
field
by
setting
the
field
in
the
back
end,
ref
spec
struct
to
in
the
TLs
part
of
that
to
1.2
right,
like
you,
can
override
it
at
that
individually
at
that
level.
But
if
you
don't
say
anything,
then
you're
going
to
get
TLS
would
be
1.3
right,
like
that's.
B
That's
how
I
sort
of
in
envisioned
the
the
policy
working
and
the
the
thing
that
you
can
do.
Then
is
that
the
person
who
owns
the
Gateway
can
attach
a
policy
to
the
Gateway
to
say
it's
tlsv
1.3
and
you
can't
override
it.
That's
what
the
override
idea
behind
policy
is,
you
can
say
no,
you
can't
step
this
down
to
1.2,
sorry,
end
story,
you
know
because
sometimes
that's
what
you
want.
You
want
to
be
able
to
say
I'm,
sorry.
B
If
your
app
doesn't
do
1.3,
then
your
app
is
not
running
in
this
custom.
Something
right
like
you
need.
We
need
to
make
sure
we
handle
that
sort
of
thing
and
that's
what
policy
attachment
is
for,
but
the
thing
that
I
like
about
putting
the
HTTP
route
is
actually
that
you
know
that
it's
a
very
clear,
Association
right,
there's
a
very
clear
relationship.
B
If
you're
overriding
this
at
the
Gateway
level,
that's
saying
we're
overriding
this
HTTP
route
level,
setting
back
in
ref
level
setting
up
here
because
of
someone
who
controls
it
up
here
is
doing
it
right.
That's
what
the
thing
I
think
I
think
yeah
and
the,
and
that
that's
so
in
some
ways
like
having
it
in
the
HTTP
route
is
good.
You
know
in
that
it's
a
very
clear
relationship.
B
I
think
Austin,
said
in
the
chat
that
HTTP
route
is
not
a
good
place
for
setting
connection
settings
and,
like
yeah
I,
agree,
it's
kind
of
like
in
my
mind,
it's
owned
by
the
it's
like
a
service
setting
right
like
it
should
really.
Ideally
that
setting
should
be
on
the
service
resource,
but
we
all
know
we
can't
change
the
service
resource
because
it
would
take
a
year
or
more
and
be
very
contentious,
because
adding
more
things
to
service
is
very
hard
so,
like
that
was
my.
B
My
thought
was:
hey,
we'll
have
a
wrapper
resource,
the
rap
service
and
then,
and
then
that
will
that
will
make
that
part
easier,
constant.
D
Well,
sorry,
for
repeating
myself,
but
that's
what
policy
attachment
is
for
and
I,
don't
think
we
need
to
change
service
for
come
out
for
this
purpose.
It's
sufficient
to
define
a
resource
that
act
of
the
policy
attached
to
the
service.
I,
don't
know
if
we
already
Define
Service
as
an
attachment
point
or
not,
but
I
think
we
do
and
that
policy
would
be
the
you
know:
TLS
attachment
policy
or
whatever
it
will
be
a
standard
resource
defined
just
like
here
and
that
will
Define.
You
know.
D
Properties
of
the
service
is
without
having
to
change
service
I,
don't
think
I
think
it
will
be
much
cleaner
than
putting
it
out,
because
your
routes
are
kind
of
confusion,
I
mean
you
have
two
routes
pointing
the
same
backhand
or
or
it
gets
crazy,
even
for
a
user
to
understand
how
it
affects,
because
it's
not
you
know
natural,
basically.
A
B
A
Thank
you.
Sorry,
just
a
couple
things
here:
I
I
personally
agree
that
I
would
prefer
for
this
not
to
be
in
route.
I
I
would
prefer
another
home
for
it.
I
am
I
I'm,
not
sure
I
see
so
policy
attachment,
at
least
as
it's
defined
today
comes
with
overrides
and
defaults,
and
the
ability
to
attach
at
multiple
levels
and
I'm
not
completely
clear.
A
That's
useful
for
the
capabilities
we're
talking
about
right
now,
the
I,
the
idea
of
TLS
Rec
configuration
the
protocols
that
a
back-end
supports
those
kinds
of
things
don't
feel
like
there's
something
you
wanted
to
Define
at
a
higher
level
and
then
override
further
down
the
stack
right.
They
seem
pretty
specific
to
a
service
or
a
back
end
of
some
sort.
A
So
my
own
bias
here
would
be
to
have
a
resource
that
is
really
just
a
decorator
on
top
of
a
service
and
just
extends
service,
and
it
exists
for
that
purpose
and
nothing
else
open
to
other
perspectives
here,
but
that
that's
my
bias
right
now.
D
I
completely
agree,
I
mean
I,
say
but
again
when
I
say
policy
attachment
I,
don't
necessarily
mean
the
policy
resource
with
overrides
and
whatever
we
can
define
a
another
crd
that
has
a
reference
just
like
policy
or
back
or
HTTP
route
to
the
service
or
decorator,
wrap
or
whatever
I
think
it
was
proposed
in
in
gamma
as
well.
It
doesn't
have
to
be
exactly
you
know,
with
overwrite
and
but
the
same
concept
that
you
attach
to
the
service.
Instead
of
having
to
wait
for
service
to
a
new
fields.
B
Yeah
so
I
think
that's
that's
what
I
was
talking
about
when
I
talk
about
a
meta
resource
or
or
like
a
bonding
style
resource,
the
I
think
for
me
and
I
think
it
sounds
like
maybe
Rob
is
on
the
same
page
here.
B
I
would
like
to
reserve
the
the
use
of
the
face
policy
attachment
to
sort
of
be
that
behavior,
where
you
have
something
that
makes
sense
with
the
hierarchy
of
Gateway
API
resources
and
has
the
defaults
and
the
and
the
overrides
the
so
like
you
know,
I
think
that
a
way
to
say
this
is
a
policy
attachment
is
a
meta
resource
in
that
it
binds
to
another
resource
and
influences
the
function.
But
not
all
medical
resources
are
policy
attachments
right.
B
We
spend
a
lot
of
time
sort
of
trying
to
get
the
language
right
on
defaults
and
overrides
there,
and
so
like
I,
think
that
in
this
sort
of
thing,
because
there
are
before
so
reference,
Grant
is
also
another
great
example
of
a
meta
resource
where
it's
a
resource
that
binds
in
some
way
to
another
resource
and
modifies
Its,
Behavior
and
so
I
think
that
we're
going
to
need
to
use
those
meta
resource
style
things
a
lot
but
like
I,
think
yeah
like
it
and
so
I
and
I
think
that
again,
this
is
a
thing
where
maybe
the
policy
attachment
docs
don't
make
clear
enough
that
it's
about
that
sort
of
the
defaults
and
overrides
behavior
policy
attachment-
and
you
know
this
is
a
thing
that
I've
been
meaning
to
clean
up
for
a
while,
but
I
think
now.
B
I
have
a
slightly
better
idea
of
what
I
need
to
say
in
there
that
policy
attachments
are
meta
resources
matter
recently,
yeah
meta
resource
binder
to
other
objects
and
make
them
and
change
their
behavior.
A
policy
attachment
is
a
meta
resource,
but
not
all
matters
resources
are
policy
attachments,
yeah
is
that
does
that?
Does
that
make
sense,
Colston
cool,
okay,.
B
I
think
that
you're
right
that
there
are
definite
sort
of
downsides
of
doing
that,
but
yeah
and
Mikhail
asks.
Is
it
a
one-to-one
relationship
between
a
meta
resource
and
the
resources
changing
for
all
of
the
ones
that
we
have
made
so
far?
Yes,
does
it
have
to
be?
Probably
not?
B
It
doesn't
get
real
foggy
if
you
start
having
it
be
any
more
than
a
one-to-one
relationship.
Absolutely
like
the
idea
here
is:
if
you're
going
to
have
these
meta
resources,
you've
got
to
be
really
clear
about
which
things
apply
to
what
and
how
you
know
that
your
thing
is
working.
B
C
Yes,
what
what
Nick
just
said
really
really
spoke
to
me
and
wanted
to
call
that
out?
I
I
think
we're
getting
to
the
point,
especially
with
some
of
the
work
that
game
is
going
to
start
doing
as
well
as
this
backing
property
stuff.
It
feels
like
it
might
be
helpful
to
kind
of
have
something
resemble
in
the
decision
tree
around.
C
What
we
feel
is
is
policy
attachment
versus
some
of
these
other
more
meta
resource
based
kinds
of
things,
and
you
know
I
think
to
be
to
be
fair,
like
Nick
mentioned
a
pretty
big
guiding
principle
like
if
you
need
to
take
advantage
of
the
hierarchy
piece
of
policy
attachment,
that's
a
good
sign
of
policy
attachment
if
the
if
it's
data
plane,
specific
I,
have
to
get
some
policy
attachment.
C
What
else,
and
and
what
does
that
mean?
Concretely
as
we
talk
about
developing
the
API,
it
feels
like
the
current
like
web
page.
Around
policy
attachment
could
be
augmented
a
bit
and
maybe
it's
more
of
a
meta
resource
type,
and
here
are
the
different
meta
resources
that
we
have.
Here's
when
you
reach
for
a
decorator
pattern,
object
like
a
back-end
properties.
C
C
You
know,
beginning
level
of
of
qualifications
and
and
kind
of
use
cases
for
each
one.
E
A
Cool
yeah,
thank
you.
So
you
know
looking
at
time
we're
close
to
the
end
of
this
meeting,
so
I
want
to
start
wrapping
things
up,
and
one
of
the
things
that
is
top
of
Mind,
probably
for
all
of
us,
is
that
we
have
a
release
coming
up.
We
would
love
to
get
this
or
some
portion
of
this
into
that
release,
which
leaves
us
with
a
very
tight
timeline.
A
You
know
this
requires
a
gap
that
requires
the
get
being
implemented
and
documented,
and
we're
really
looking
at
a
couple
weeks,
maybe
a
little
bit
more
to
get
all
that
done.
My
personal
advice
would
be
that
maybe
there's
some
subset
of
this,
that
we
could
Implement
just
just
to
get
the
resource
started.
Maybe
there
are
capability
or
two
in
here
that
we
feel
like
we
can
Define
clearly
are
going
to
be
non-controversial
and
widely
useful
and
we
can
focus
on
those
and
and
get
that
in
I.
A
Think
if
this
is
a
separate
resource
or
wherever
this
lives,
every
intent
would
be
to
continue
working
on
it
and
expanding
it
with
new
capabilities.
But
if
we
can
get
that
kind
of
foundation
of
this
is
where
the
config
lives.
This
is
what
it
looks
like
and
here's
a
couple
starting
capabilities
that
seems
like
we
might
be
able
to
squeeze
that
into
this
specific
release,
but
it
will
be
tight.
A
I,
don't
know
like
you
may
have
seen
our
thoughts
yeah.
B
B
I
would
say:
let's
stick
with
a
very
similar
Behavior
to
to
to
reference
Grant,
okay
and
have
like
the
the
service.
The
service
sort
of
service
back
end
meta
resource
like
be
a
separate
resource.
B
That
has
a
spec
thing
that
points
it
to
a
service
and
and
it
and
it
can
have
a
GVK
and
a
name,
but
no
name
space,
because
it
has
to
be
in
the
same
Resource
as
the
thing
that
it's
modifying
and
then
you
have
like
the
the
capabilities
thing
as
a
union
as
a
union
style
structure
where
you've
got
like
like
you've
got
in
the
option:
two
where
you've
got
like
TLS
backend
a
websocket,
and
we
just
add
more
things
to
that
struct
as
we
as
we
come
up
with
additional
capabilities
that
need
documenting.
B
If
we
have
I
think
something
like
that
is
pretty
easily
definable
in
a
very
short
amount
of
time
is
going
to
work
very
similarly
to
what
we
have
a
reference.
Grant
I,
don't
think
we
need
to
block
working
on
this
with
us
figuring
out,
like
some
more
bits,
a
better
language,
around
meta
resources
and
policy
attachment
all
that
sort
of
stuff.
I
feel
like
something
like
that
feels
pretty
good
to
me,
and
I
would
certainly
be
really
good
with
seeing
something
like
that
move
very
quickly.
B
Now
is
probably
the
time
for
anyone
who
has
big
objections
to
that
to
speak
up,
though,
because
otherwise
Candice
is
going
to
go
off
and
get
cracking
on
this
and
I
would
really
like
not
to
ruin
Candace's
day
yet
again
by
asking
her
to
change
directions
after
we
have
said,
go
and
do
something.
Please.
A
I
I
would
just
Echo
those
thoughts
and
also
say
you
know
Candace
if
you
need
help
at
any
point,
please
reach
out
I
think
between
the
different
maintainers.
Here
we
offer
basically
24
7,
someone's
awake.
Probably
so
we
got
that
covered,
but
also
I,
encourage
everyone
who's
interested
in
this
to
prioritize
reviewing
this
as
the
PR's
come
in,
our
timeline
is
going
to
be
pretty
quick.
A
B
A
Thank
you.
Thank
you.
Everyone
thank
you.
Candace
for
taking
this
one
on
I'm
excited
to
see
where
it
goes,
and
yeah
have
a
great
week.