►
From YouTube: SIG Network Gateway API meeting for 20221212
Description
SIG Network Gateway API meeting for 20221212
A
Hello,
everybody,
Welcome,
To,
December,
12th,
Skateway
API
meeting,
keep
in
mind.
As
always,
this
is
governed
by
the
kubernetes
code
of
conduct,
which
boils
down
to
be
nice
to
one
another,
don't
be
rude
with
that
in
mind,
we're
going
to
go
ahead
and
get
started
on
our
agenda.
For
today
we
have
a
couple
of
follow-up
items
that
came
from
the
previous
meeting.
B
A
All
right,
so
one
of
the
follow-up
items
from
last
week
was
we
talked
about
moving
to
Priority
labels.
There
were
some
complaints
about
basically
understanding
like
how
things
land
and
how
we
want
them
to
land
across
releases
and
stuff.
Like
that,
does
anybody
have
any
thoughts
on
this?
Should
we
just
do
it.
C
A
D
B
A
All
right,
another
follow-up
from
last
week,
looks
like
we
had
an
update
here
since
I
posted
it
TLS
route
termination
discussion.
So
there
was
some
discussion
last
week
about
some
people
might
want
TLS
route
to
actually
do
termination.
We
were
kind
of
unclear
on
that.
We
decided
we
would
do
a
follow-up
Candace.
E
C
This
one
was
about:
is
there
any
reason
why,
when
you're
doing
TLS
random
routing
on
Sni,
you
would
want
to
terminate
the
TLs
connection
when
you're
only
routing
using
the
S9
we're
like
I,
don't
think
so
and
that's
why
so
yeah?
That's
what
that's?
Why
I
think
we
sort
of
moved,
but
we
didn't
get
to
it.
That
said
this,
this
definitely
has
kind
of
stalled.
C
I
haven't
had
a
lot
of
chance
to
give
it
to
a
little
bit
more
loving,
but
the
I
think
that
I
did
think
of
two
use
cases
that
aren't
in
there
that
I'll,
try
and
add
today,
but
yeah
but
and
I
think
the
point
of
that
was
just
to
sort
of
get
everybody
to
be
like
if
you're
using
TLS
to
get
API.
Can
you
put
like?
C
C
That's
like
we
haven't
recorded
I
want
to
use
a
client
certificate
on
The
Listener
and
a
couple
of
other
things
like
that
and
I
want
to
encrypt
Communications
between
the
Gateway
and
the
the
Gateway
in
the
back
end
without
the
without
encrypting
them
on
the
outside
of
the
listener.
So
yeah
I'll
update
that
today.
C
Not
they're
not
related
to
what
we
wanted
to
follow
up
today.
The
the
one
we
wanted
to
follow
up
today
is
so
TLS
route
is
designed
for
when
you're
you,
you
want
to
Route
traffic
only
based
on
the
Sni
in
the
in
the
TLs
connection,
not
based
on
anything
in
the
headers
or
anything
that
you
need.
Inspection
of
the
traffic
for,
and
so
the
question
is
in
the
case
of
TLS
route.
Is
there
any
utility
in
supporting
terminate
at
all,
because,
if
you're
terminating
TLS
and
only
routing
on
the
Sni,
then
it's
like?
C
A
C
You
explain
to
you
later
again
and
saying
right
now:
TLS
route
allows
termination,
but
I,
don't
think
that
makes
sense
and
lazy
consensus
is
that
yeah
laser
consensus
here
is
I
will
remove
references
to
TLS
for
outsporting
termination
from
across
the
API.
Unless
someone
can
explain
to
me
why
you
need
it.
E
D
E
F
C
If
you
want
to
bring
your
own
cert
and
and
run
the
TLs
inside
the
workload
so
that
you're
not
the
Gateway,
is
not
actually
like
unwrapping
the
TLs
and
you
and
doing
things
with
the
TLs,
then
that's
what
TLS
runs
for
is
for
when
you
pass
the
TLs
through
the
Gateway,
without
doing
anything
with
it.
That's
what
TLS
right
is
foreign.
C
C
It
kind
of
pokes
me
again
that
that
we
probably
need
to
do
a
little
bit
of
a
tidy
up
on
the
docks
around
like
I'm
doing
TLS
and
and
what
what
do
I
use.
But
that's
what
the
TLs
use
cases
stock
is
for.
So,
if
you're
using
TLS-
and
you
have
questions,
can
you
have
a
look
through
that
use
cases
doc
and
just
check
that
we
describe
everything
you
need
to
know
about
what
you
want
to
do
with
TLS.
C
A
Roger
that
all
right
moving
forward
so
rushi,
who
is
on
the
call,
joined
us
several
months
ago
and
started
looking
for
things
to
do
basically
was
interested
in
contributing
it
can
be
a
little
bit
challenging
to
contribute
when
you
don't
have
an
implementation
you're
actively
working
on
so
like
wanting
to
contribute,
but
not
necessarily
wanting
to
jump
into
any
specific
implementation
makes
it
hard
to
contribute
to
Gateway
API,
or
at
least
that
was
the
experience
we
had.
I
tried
to
find
him
some
stuff.
A
For
those
of
you
who
don't
know,
oblixt
is
a
project
that's
being
donated
to
kubernetes
for
Gateway
API,
for
the
purpose
of
being
a
reference
implementation
and
for
testing
only
and
rushi
recently
helped
to
implement
the
UDP
route
controller
for
it.
So
we
have
a
demo
today,
a
few
things
have
changed
and
we'll
kind
of
talk
about
some
of
those.
But
we
have
a
demo
today
of
doing
end-to-end
UDP
route
without
any
fanciness.
It's
all
working
now
true
go
ahead.
Take
it
away.
Rushi
I'll,
stop
sharing
his
screen.
D
Oh
yes,
yes,
very
fine,
okay,
I'll,
try
my
best
to
demo
it
in
like
very
good
way.
Shane
did
most
of
the
work.
I
did
some
sort
of
things.
So
if
something
goes
wrong
limit
machine,
okay,
four
questions
so
yeah.
Basically,
we
kind
of
did
like
this
was
to
get
UDP
implemented.
I
tried
to
implement
the
control
it
and
Shane
did
the
data
plane
part?
So
what
we
just
wanted
to
demo
it
like
you
know
how
it's
even
working
so
I
just
have
pull
off
some
of
terminals.
D
So
probably
what
I
will
do
first
is
get
started
with
maybe
getting
our
data
plane
and
control
plane
up
so
in
this
one,
please,
let
me
know
if
it's
not
visible.
I
was
just
telling
it
here,
so
I
will
go
ahead
and
deploy
probably
our
controller
and
a
data
plane
like
the
pods
for
database
and
controller.
This
is
a
data
plane,
control
manager.
Okay,
it's
running.
A
D
D
This
is
this
simple
server,
which
is
just
echoing
it,
probably
yeah
and
we'll
go
ahead
and
we'll
add
a
Gateway
route
of
Gateway.
First
we'll
install
the
crds
so
just
to
take
a
look.
It's
just
a
simple
Gateway
class
and
a
Gateway
I'm
telling
it
that
okay,
it's
blixty
and
we'll
also
go
ahead
and
add
UDP
route
for
it.
H
D
Okay,
it's
been
configured
I,
think
it
picked
up
we'll
just
check
once
if
we
have
okay,
yeah,
okay,
blixty
blxt,
so
and
probably
I
will
just
simply
do
a
netcat
just
to
see
okay,
so
UDP
router
is
working
and
it's
going
through
so
that
we
know
like
you
know
the
whole
thing
or
the
demo
which
we
are
trying
to
do
is
working
before
that
yeah
the
Gateway
is.
There
should
I
show
anything
specific
machine
before
like
we
doing,
maybe
not
cat
or
something
or
you
want
to
add
up.
A
A
D
A
F
H
D
A
It's
okay,
that
stuff
happens,
I'm
kind
of
curious
now.
Actually,
what
went
wrong
because
it
would
have
seemed
like
the
we'll
have
to
we'll
have
to
check
it
out.
I
think
it
has
something
to
do
with
cruft
leftover
from
a
previous
realm
that
isn't
being
cleaned
up
properly
so,
but
the
long
and
short
of
it
is
that
the
you
can
go
ahead
and
play
with
that
and
I'll
talk
for
a
second.
A
The
long
and
short
of
it
is
that
in
the
previous
demo,
we
were
using
go
see
as
and
ebpf
with,
celium
go
basically
and
this
time
we've
Rewritten
it
in
Rust
with
Aya
rust
and
the
Aya
framework
actually
have
full
support
for
TC,
where
ebpf
doesn't
or
sorry
celium
go
doesn't.
So
there
was
that
that
happened
for
a
couple
of
technical
reasons,
and
also
because
we
preferred
rust.
For
other
reasons,
too,
the
the
demo
before
used
XDP
this
one
uses
TC
if
you're
not
familiar
with
that
is.
A
These
are
different
kinds
of
ebpf
programs
to
XDP
is
like
really
really
low
level.
Tc
is
higher
level
but
and
gives
you
access
to
more
helper
functions
and
things
like
that
in
the
Linux
kernel
and
in
this
demo.
We
finally
are
at
the
point
where
we
have,
like
the
end,
to
end
working
without
having
to
go
in
and
do
things
like
manually,
manipulate
network
interfaces
and
stuff
like
that.
D
D
A
H
A
A
Jam
is
something
that
Andrew
stoicus
and
I
wanted
to
add
for
kind
of
partially
for
the
Blix
group,
but
in
general
just
to
be
able
to
do
like
pair
programming
kind
of
more
or
less
formal,
chats
and
stuff
like
that,
a
place
to
come
in
and
like
bring
a
topic,
that's
more
Technical
and
maybe
more
implemented.
Implement
implementation
detail
oriented,
so
we
can
sit
down
and
actually
look
at
things,
I
think
for
this
Friday
when
it
starts
so
it'll
be
Friday.
Every
Friday
at
I
think
it's
11
30
a.m.
A
It's
on
the
sick,
networking
meeting
it's
completely
optional!
It's
not
going
to
have
any
like
normal
or
like
normal
Gateway
API
agenda.
It's
just
going
to
be
related
to
Gateway
API,
for
like
bugs
and
just
whatever
else
that
we
run
into
and
we'll
try
it
for
a
while
and
see
people
like
that.
So,
if
you're
interested
it's
on
the
Sig
Network
calendar
and
it
is
free
form,
feel
free
to
bring
agenda
items
if
you'd
like.
B
Yeah,
we
I
think
we
finally
are
in
the
final
stretches,
there's
a
few
comments
left
that
we
haven't
addressed
at
this
point,
but
some
good
progress
in
the
past
week
and
I
know
I
have
a
PR
in
progress.
Well,
not
yet
PR,
but
a
branch
in
progress
that
should
clear
up
some
of
these.
You
know
talking
with
Shane
and
Nick
I
think
our
goal
is
to
have
you
know
the
last
few
comments
cleaned
up
and
taken
care
of
by
tomorrow.
B
So
if
we
stay
on
schedule,
that
means
rc2
should
go
out,
let's
say
Tuesday
or
Wednesday
Pacific
time.
At
that
point
again,
we're
going
to
rely
very
heavily
on
community
here
to
again
test
out
what
we're
calling
release
candidate
two
now
ensure
that
if
you
are
running
conformance
that
your
conformance
passes
or
has
a
path
to
conformance,
you
know
ensure
that
the
changelog
makes
sense
to
you.
There's
nothing
unexpected
in
there
and
with
that
I
think.
B
We
will
be
well
on
track
to
do
a
final
vo60
release
shortly
afterwards,
but
I
think
the
minimum
amount
of
time
we've
given
between
rc2
and
final
releases.
Two
days
I'd
say:
that's,
probably
going
to
be
similar.
This
time
it
may
be
a
bit
longer
since
we'll
be
running
up
against
a
weekend,
we'll
see,
but
that
that's
current
timeline
for
vo60.
D
A
G
B
A
B
B
A
H
C
Yeah
yeah
I
think,
let's,
let's
wait
to
hear
from
Wilson
again
I
think
that
the
yeah
I
think
Wilson's
looking
for
ways
to
help,
and
this
was
a
this
thing
like
a
relatively
obvious
thing,
I
didn't
even
think
about
when
I,
first
sort
of
like
yeah,
okay,
that
sounds
fine
I,
didn't
even
think
about
the
fact
that
Helm
was
sort
of
explicitly
like
hey.
We
can't
do
much
about
cids
because
of
because
you
can
only
have
one
in
a
cluster
right
like
yeah.
C
C
A
B
A
B
There's
a
couple
comments
on
the
on
Zoom
chat.
First,
it
looks
like
there's
a
question
of
if
this
is
a
proposal
to
remove
an
existing
option
or
just
add
a
new
one,
since
we
it.
This
is
a
proposal
to
add
a
new
one.
We
don't
have
any
Helm
support,
at
least
any
official
Helm
support.
Today,
then
Mike
is
suggesting
that
keeping
charts
as
Gateway
you
know
at
Gateway
implementations
seems
to
make
more
sense
than
you
know,
owning
them
as
the
Gateway
API
project
itself.
B
I
C
Yeah
the
problem,
the
problem
is
that
if
we
do
that,
then
and
two
implementations
are
referencing
different
versions
of
the
of
the
Gateway
API
chart,
then
things
will
break
in
spectacular
ways
and
so,
like
you
can't.
That
means
then,
like
I,
understand
what
you're
saying
but
doing
it
with
Helm
charts
and
having
a
Helm
chart
means
like
puts
versioning.
That
is
not
that's
not
handled
well
by
the
fact
that
cids
can
only
have
one
version.
B
B
B
Okay,
so
I
I
added
this
one
I
can't
remember
if
this
was
discussed
in
much
length
previously,
but
it
feels
like
one
a
good
thing
to
do
and
two
something
like
that:
may
break
everyone's
conformance
tests,
so
I
just
I
just
wanted
to
highlight
that
this
is
coming.
I
I
think
I
think
this
is
a
good
idea,
but
it
means
that
you
know
we.
B
B
My
own
opinion
is
probably
not
so
far
in
conformance
Gateway
classes
is
an
input,
not
something
we're
actually
testing.
It's
just
you
know
the
the
person
or
thing
that's
running
conformance
test
provides
a
Gateway
class
that
we
run
tests
against,
but
we
don't
actually
test
the
Gateway
class
resource
itself
and
I'm
not
sure
how
meaningful
observed
generation
would
be
on
Gateway
class.
B
B
C
I
think
that
it's
probably
better
to
just
you
know
it's
probably
better
to
just
require
that
we
do
it
because,
like
that
way,
if
we
need
to
add
it
in
the
future,
it's
not
a
big
change.
You
know,
if
we
add
any
extra
fields
to
the
Gateway
class
at
some
point
in
the
future,
then
we
will
need
observed
generation
there
and
just
getting
people
used
to
the
idea
of
if
you
update
the
status,
you
include
the
observed
generation.
C
Yeah
I
hear
what
you're
saying
I
hear
what
you're
saying
but
like
I,
think
that
I
don't
because
you
need
to
be
able
to
you
need
to
be
able
to
indicate
which
Gateway
class
you
are
reconciling
like.
You
know
that
that
is
the
reason
that
you
do
the
status
update
for
to
say
that
a
Gateway
class
is
accepted.
I
mean
it
could
be
that
you,
you
are
reconciling
more
than
one
right,
that's
up
to
you
right
like,
but
the
because
you
need
to
be
able
to
do
that.
B
C
That's
all
fun,
except
for
the
get
the
controller
name
update
right
like
so.
If
you
update
controller
name
that
changes
which
gateways
are
in
scope
right
like
because
if
you
change
the
controller
name
from
you,
know,
project
contour.io
to
slash
Contour
to
you,
know
gke
Gateway,
API
implementation,
then
that
means
that
all
of
those
gateways
under
there
now
belong
to
no,
it's
the
same
as
creating
another
Gateway
class.
That
does
that
right
like
and
the
the
old
implementation
needs
to
drop
support
for
it
and
the
new
one
needs
to
stop.
B
So
so
I
did
just
verify
that
controller
name
in
Gateway
class
is
something
that
we
have
intended.
Immutability
of
you
know
it
with
the
Web
book
validation.
So
we
have
web
of
validation
that
will
cover
that.
Obviously
Web
book
validation
is
not
perfect.
It
can
be
bypassed,
it
may
not
exist,
but
the
intent
is
that
field
is
supposed
to
be
immutable.
Obviously
people
can
change
it.
They
can
do
delete
recreate
whatever
I
I.
Don't
know.
C
It
I
guess
in
my
mind
the
reason,
the
reason
that
I'm
saying
it
the
way
I
am
is,
if
we
don't
allow,
if
we
don't
force.
If
we
don't
say
you
have
to
include
the
observed
generation
on
this,
then
there's.
No,
then
the
status
is
no
longer
reliable.
Right,
like
you
know,
like
the
like,
the
The
observed
generation
is
just
a
little
checksum.
That
says
that
you
know
everything
is
good.
C
The
version
that
you
touch
that
you're
seeing
is
the
version
that
that
was
last
updated
right,
like
the
the
other
reason
for
observed,
generation
is
okay,
so
you
have
I,
am
running
a
controller
implementation.
The
controller
implementation
picks
up
a
Gateway
class
and
observes
it
fine
and
marks
it
down,
is
all
good
and
then
but
but
we
do
support
parents
riff
right
and
so
the
and
then
I
shut
down
the
Gateway.
C
The
the
point
of
the
observed
generation
is
to
make
sure
that,
if
anything
changes
in
the
resource,
then
then
you
know
that
the
status
is
consistent
with
the
spec
of
the
resource
and
that
because
the
exaggeration
is
done
by
the
API
server,
you
can't
fudge
it
yeah
I.
Think
the
question
you're
saying
is:
is
it
useful
for
us
to
to
allow
any
changes
to
to
the
spec
of
Gateway
class
and
I'm
like
well
yeah?
That
is
an
interesting
question.
But
fact
is
it's
a
kubernetes
object
and
spec
changes
are
allowed.
So
we
should.
B
Yeah
yeah
and
I
I
think
I.
I
definitely
agree
that
observed
generation
should
be
set
where
I'm
struggling
is.
If
observed,
generation
needs
to
be
incremented
on
what
I
view
as
a
no
op
update.
So
in
my
case,
changing
description,
which
is
the
only
thing
we
can
test
right
now.
Changing
description
feels
like
a
no-wop
update
that,
like
it's,
it's
never
going
to
have
a
meaningful
difference
for
the
controller
and
so
requiring
that
a
controller
bump
observed
generation
in
that
case
feels
a
little
funny.
A
With
Nick
on
this
one,
but
it's
not
a
hill
I
want
to
die
on
so
I'm
kind
of,
like
I
think
we
could
spend
a
lot
of.
It
sounds
like
we
are
pretty
divided
on
this,
so
it
really
comes
down
to
who
wants
to
die
on
white
Hill
and
I'm,
not
gonna
die
on
the
hill.
So
if
you
really
want
to
take
it
out,
I'm,
okay,
with
taking
it
out
just
for
the
purposes
of
like
moving
forward,
but
it
seems
to
me
like
what
Nick
said
is
true.
A
G
C
That
is,
that
is
true
to
some
extent
but
but
like,
but
what
I'm
actually
saying
Makaya
is
that
no
in
in
the
case
that
the
generation
has
changed
like,
if
you
see
an
update
for
the
thing
in
the
generation
has
changed,
you
really
need
to
apply
the
status
again
to
say:
hey
yeah
like
as
of
this
generation.
This
status
still
applies
so
like,
even
if
the,
even
if
you
update
the
description,
which
is
a
no-op
in
terms
of
like
accepted,
you
know,
in
terms
of
changing
whether
or
not
accepted
has
taken
effect.
C
H
B
C
Generation
is
for
like,
if
you
so
it's
one
of
the
things
I
think
I
I've
always
felt
like
observed
generation
is
currently
an
optional
field,
indestruct
in
Upstream,
but
I've
got
the
impression
from
the
API
machine
folks
a
couple
of
times
that
the
only
reason
it
is
is
that
they
added
it
after
and
they
couldn't
make
it
default.
Otherwise
they
would
have
made
it.
So
you
might
it's
required,
like
the
only
reason
it's
optional
is
because
it
was
added
later
sorry
Makaya.
You
got
your
hand
up.
H
G
C
A
G
H
G
C
Not
so
it's
not
that
I
want
to
conflate
them.
It's
that
you're
we're
forced
to
conflate
them
right.
Like
the
the
you
know,
the
fact
the
updating
description
will
update
the
generation
right
like
that.
That
is
not
optional,
and
so
what
we're
saying
is
if
we
are,
if
we
are
requiring
that
it's
not
just
when
you
update
status,
you
have
to
update,
observe
generation
it's
if
the
generation
on
the
spec
on
the
object
updates,
you
must
update
status
to
ensure
that
the
observed
generation
matches
the
thing,
even
if
that
status
was
updated,
was
a
knob.
A
A
A
B
Yeah
I'd,
so
I
I
ran
through
and
went
through
the
most
recently
updated,
PRS
and
and
issues
this
was
one
of
them.
Michael
went
through
and
responded
to
most
all
of
the
feedback,
so
this
is
really
just
ready
for
another
round
of
review.
I
think
this
is
a
really
important
topic,
so
if
anyone
has
extra,
Cycles
I
think
we're
likely.
Many
of
us
are
familiar
with
the
process
of
going
from
Ingress
to
Gateway.
B
A
I'll
take
another
look
at
that:
I
thought
I
had
just
approved
it,
but
apparently
I
did
not
so
I
will
take
another
look
in
particular,
but
yeah
please
do
jump
in
this
is
going
to
be
a
sort
of
almost
like
a
landing
page
for
some
people
very
important
document,
so
as
many
extra
views
and
thumbs
up
as
we
can
get
or
requests
for
changes
cool.
So
maybe
there's
not
much
more
to
say
about
that.
Unless
anybody
has
something
pretty
straightforward.
A
D
D
This
revised,
so
I'm
just
gonna
go
ahead
and
apply
the
UDP
right
route
right
now
and
before
that,
maybe
even
we
could
see
okay.
This
is
not
going
right
now,
so
we'll
apply
the
UDP
router
just
created
it
picked
up
and
the
simple
like
Echo
test
just
to
revisit
again
the
IP
for
Gateway
is
the
same
one
and
press
yeah,
it's
1800,
so
we're
just
gonna.
Do
an
accountant
actually.
D
B
Yeah
I
know
so
one
one
of
the
things
I've
been
thinking
about
is
you
know
that
the
project
has
been
going
for
a
while
and
I
think
it
would
be
helpful
to
try
to
spend
some
time
in
the
next
few
weeks
to
start
thinking
about
where
we
want
to
be
a
year
from
now.
Basically,
as
a
project
things
we
want
to
achieve
the
things
that
are
most
important
to
us.
B
I
have
I,
have
lots
of
ideas,
but
I
don't
want
to
just
start
a
doc
on
my
own
I
wanted
to
see
what
others
are
thinking
about.
What's
top
of
Mind
what's
highest
priority
and
have
this
be
more
of
a
collaborative
effort?
So
there's
not
much.
You
know
that
we
have
to
discuss
today,
but
I
just
wanted
to
start
getting
this
in
people's
minds.
B
If
you
have
ideas,
if
you
have
things
I
really
want,
you
know,
X
feature
in
Gateway,
API
and
I
want
it
to
be
beta
by
the
end
of
the
year
or
whatever.
That
is
I'd
love
to
hear
about
that
or
you
know
whether
maybe
it's
just
I
really
want
this.
This
level
of
adoption
or
I
want
policy
attachment
to
succeed,
I,
don't
know,
there's
any
number
of
things,
I'm,
not
sure
the
best
way
to
to
kind
of
track
these
ideas,
as
you
know,
as
we're
just
kind
of
starting
out.
B
If
you
have
things
that
you'd
really
like
to
focus
on
or
like
to
see
the
community
focus
on,
maybe
just
mention
it
in
slack
to
get
started,
and
then
eventually
we
can.
We
can
start
working
on
a
dock
and-
and
you
know
include
that
on
the
website
at
some
point,
so
that
when
people
are
asking
what
are
what
our
vision
is,
what
we've
got
coming
up
next,
we
have
a
kind
of
centralized
place
to
point
them.
E
B
B
Oh
and
my
Kai
is
asking
a
good
question
chat.
You
know
it
can
be
big
new
ideas,
but
you
know
we
already
have
so
many
ideas
that
are
circulating
that
we
haven't
seen
you
know,
get
all
the
way
through.
I
am
personally
most
interested
in
just
getting
existing
ideas
through
but
I.
You
know,
I
I,
don't
know
you
know.
I
I
am
not
the
the
only
or
final
Arbiter
of
anything.
So
so
definitely
if,
if
there's
something
that
you
want
to
see
succeed,
you
know
bring
it
up.
A
G
C
Ahead
I
was
gonna
say,
maybe
maybe
this
is
a
thing
that
we
can
spend
a
bit
of
time
discussing.
You
know,
sort
of
open,
Office
sales
suggestion
next
week.
If
we
don't
have
any
other
questions,
I
think
Rob
was
saying
that
he
would.
He
was
biased
towards
not
to
finishing
out
things
not
focusing
on
being
new
ideas.