►
From YouTube: Technical Oversight Committee 2021/07/26
Description
Istio's Technical Oversight Committee for July 26th, 2021.
Topics:
- Environments Working Group Roadmap for 1.12
- Extending Istio's support window
- Promoting External Control Plane to Beta
B
111
so
based
on
the
timelines,
the
asynchronous
first
week
and
second
risk
testing
is
done.
However,
there
are
still
four
test
cases
left,
so
there
are
two
possibilities:
either
we
can
wait
to
automate
or
test
them,
given
that
the
testing
week
is
done.
So
my
question
is:
what
should
we
do
at
this
point?
Given
the
automation
is
not
completed
and
there
are
p
zeros.
B
E
E
E
B
C
G
H
B
F
I
don't
agree
with
that.
We
need
to
test
them.
We
don't
need
to
automatically
test
them
like.
It
doesn't
make
sense
to
block
the
release
of
you,
because
we
haven't
automated
some
tests
about
kiali.
We
can
say
we
can
block
it
until
someone
goes
and
manually
does
it,
but
we
don't
need
to
automate
it.
We
should
automatically.
Of
course
it
is
high
priority,
but
it's
not
blocking.
F
I
G
C
I
C
H
I
H
No,
no,
I
don't
think
it's
a
page
doesn't
make
it
very
clear
that
I
mean
looking
at
the
page.
I
don't
see
anywhere
that
you
know
this
is
an
alpha
api.
It's
not
going
to
be
supported,
I
mean
it's.
It's
very
looks
like
like
a
supportive
feature
to
me.
I
don't
know,
maybe
I'm
reading
it
wrong
and
it's
somewhere
soon.
K
C
L
A
H
I
A
A
H
J
B
B
L
B
Yeah,
so
just
a
reminder
that
the
third
august
is
the
code
freeze.
So
if
anything
is
to
emerge,
please
do
so
on
the
release
update.
So
that's
where
john
wendell
was
talking
about.
We
still
have
release
blocker,
10,
p,
zeros
and
15
p1.
So
john,
if
you're
still
on
oh
yeah,
you
may
have
to
switch
back
again.
E
No,
we
we
talked
this
morning
about
those
issues
and
we
are
going
to
trust
them.
Okay,
there
are,
there
are
some.
I
mean
there
are
some
stuff
that
I
don't
really
understand.
So
we
had
the
branch
cut
probably
two
weeks
ago
and
we
are
still
some.
We
are
still
seeing
features
being
cherry
picked
to
111,
so
we
should
communicate
better.
That
okay
feature
is
over
unless
you
have,
you
know
an
exception
or
it's
a
critical
feature.
E
E
So
we
are
just
trying
to
stabilize
the
release,
because
if
we
are
keeping
adding
features,
then
we
are
going
to
open
the
door
for
more
bugs
right,
but
yeah,
that's
it.
That
said,
there
is
a
release
blocker,
that
john
created
that's
going
through
that's
supposed
to
to
go
through
the
envoy
change
log
and
see
if
there
is
anything
that
could
break
us
so
ryan.
The
other
release
manager
asked
the
slack
channel
for
help
on
this
one,
because
again
we
are
not
experts.
E
A
M
Yeah,
so
I
had
proposed
this
to
a
toc
asked.
I
think
this
was
like
a
few
months
back.
It
hasn't
been
approved
by
the
testing
release
group,
but
this
is
something
that
we
should
prioritize
into
release.
This
was
around
like
feature
freezing
and
like
what
are
the
expectations
we
can
revisit
this
at
a
later
time,
but
I
just
want
to
put
it
on
the
radar
that
this
has
been
a
concern
before
you
know.
M
B
M
A
A
N
N
Yeah,
so
pretty
much
this
for
112
we're
looking
pretty
heavily
at
promoting
existing
features.
You
know
closer
to
stable
if
not
too
stable
I'll,
just
go
one
by
one
through
these
promotions
kind
of
discussing
what's
needed.
So
first
for
revision,
tags
or
stable
revision
labels.
There's
we
didn't
officially
introduce
the
feature
at
the
beginning.
N
N
So
then
multi-cluster
the
targeting
stable
for
this
release.
I
know
steven
has
a
dock
out
on
that
and
he's
doing
a
lot
of
work
on
making.
You
know
like
a
command
to
be
able
to
view
what
clusters
are
part
of
your
mesh,
and
you
know
some
holes
in
how
to
upgrade
a
multi-cluster
mesh
are
being
addressed.
N
So
that's
what's
going
on
there,
user
gateway
management
separation,
so
this
is.
This
is
john's,
john's
work
and
it's
been
getting
better
and
better
documentation
and
I
think,
just
steadily
moving
forward
in
stability
mcs,
so
kubernetes
multi-cluster
services
nathan
introduced,
I
think
a
few
months
ago
and
it
merged
into
experimental-
and
I
think,
we're
just
bringing
that
to
alpha
on
by
default,
not
necessarily
sure
what
else
is
required
for
mcs.
N
L
L
I
H
M
I
I
K
K
H
H
A
We're
already
in
this
state
right-
it's
it's
not
like.
This
is
a
new
thing.
Given
that
operators
beta
and
api
alpha
yeah,
I
think
it's
it's
probably
okay.
It's
not
great.
I
think
we
need
to
you
know,
have
environments,
put
more
effort
here
on
getting
us
out
of
this
mess
of
mesh
config
and
right,
like
we
need
to
get
to
a
point
where
we
are
happy
with
our
apis.
So
I
think,
as
long
as
that's
on
the
map
continuing
to
move
forward
on
getting
us
out
of
the
mess,
that's
good.
H
L
C
A
A
Is
it
going
to
change?
Is
everything
going
to
break?
Do
you
fix
security
bugs
in
it?
So
I
think
we
need
to.
We
need
to
be
clearer
about
like
yes,
the
actual
code
base
is
is
good
in
production
usable.
It's
just
we're
going
to
change
the
api,
so
yeah,
let's
enough
on
that,
but
yeah,
please,
please
help
us
get
out
of
this
mess.
K
Yeah,
so
so
so
I
just
want
to
say
one
last
thing
in
fact,
most
of
the
things
on
this
list,
if
I
look
at
the
documentation
they
have
somewhere
or
another
mentioned
mesh
conflict
like
external
studio
is
another
example:
you
look
at
the
documentation,
it
has
mesh
config
in
it.
So
I
really
don't
know
how
can
these
get
promoted?
K
F
Issue
is
not
just
that
it's
labeled
alpha
for
the
easter
operator.
It's
the
api
itself
is
no
longer
a
good
api.
It
was
you
know,
designed
before
easter
od,
and
so
it's
it's
more
than
just
the
the
stability
label,
whereas
mesh
config
like
it's,
not
perfect,
but
there's.
No,
you
know
fundamental
issues
with
it
like
it's.
We
just
stick
a
bunch
of
configs
in
there.
It's
fine,
but
the
easter
operator
api
is
fairly
flawed
and
confusing
right
now
so
like
regardless
of
the
label.
A
H
K
This
this
churn
on
users
and
coil
is
not
all
good
like
we
keep
swapping
and
changing
things
from
underneath
them
every
few
releases
and
if
operator
inquest
operator
was
the
way
of
doing
things
two
releases
ago,
and
now
it
looks
like
it's
no
longer
that
thing
we
are
never
planning
to
promote
it
so
that
signals
to
the
user.
They
shouldn't
be
using
it
right.
A
H
So
having
having
a
chart
that
installs
operator
and
operators
default
studio,
these
are
reasonable.
I
don't
see
a
problem
with
that
as
long
as
we
don't
have
the
api.
Basically,
that's
I
mean
it's
just
an
empty
and
sending
mesh
config
as
a
configmap,
which
you
support,
and
you
can
edit
the
configuration
time.
K
F
H
Okay,
if
I
can
put
one
more
thing
for
hand
v3
up,
we
discussed
what
kind
of
api
surface
we
have,
which
is
basically
values.tml
in
case
of
helm
operator.
We
also
need
to
consider
how
we
harmonize,
because
we
want
the
if
we
help
support
a
set
of
options
it
as
values
the
camera
for
them.
The
installation
of
operators
should
have
for
the
identical
api
or
as
close
as
possible,
because
there
is
another
api,
implicit
in
helm
entity.
N
N
H
P
I
I
I
did
also
have
an
agenda
item
on
here
to
propose
actually
doing
this
external
sd
promotion
to
beta
in
in
111.
I
think
functionally
it's
pretty
much
there.
It's
a
little
light
on
testing,
but,
but
you
know
1.12
is
is
the
alternative,
but
if,
if
possible,
I'm
thinking
it's
close
to
ready
for
1.11
actually,
but
maybe
these
api
issues
we're
talking
about
are
showstoppers
but
functionally.
I
think
it's
pretty
good.
P
I
got
a
lot
of
help
in
the
last
couple
of
months
from
from
john
and
stephen,
and
I
think
we've
got
stuff
looking
pretty
good
in
terms
of
the
implementation
and
there
are
tests-
that's
just
probably,
but
you
know
I
was
thinking
for
beta,
it's
ready,
but
anyway
we
can
talk
about
that.
At
that
time,
I
can
show
you
specifically
what
I
had
in
mind
on
that.
P
A
A
N
H
N
N
yeah
and
then
there's
default
revision.
So
this
is
something
that's
been
discussed
a
lot
the
last
few
months,
so
basically
it
solves
the
or
offers
a
solution
to
the
problem
of
validation
with
multiple
revisions,
there's
a
lot
of
like
tricky
cases
with
it,
where
you
don't
necessarily
want
every
revision
to
perform
validation
on
every
resource.
So
you
need
some
kind
of
a
mechanism
to
decide
which
revision
ends
up
validating
so
there's
a
design
out
for
that
there's
an
implementation,
that's
pretty
pretty
close
to
being
merged.
N
I'm
going
to
present
that
to
ux
as
well,
and
hopefully
we
can
get
that
documented
and
with
all
the
kinks
ironed
out
by
112.
and
then
moving
on.
We
also
have
eventing.
So
this
is
also,
I
don't
understand
everything
about
this
item,
but
my
understanding
is:
it's
basically
making
sdod,
publish,
knack
and
ag
events.
H
Yeah,
I
know
we
discussed
in
the
park.
We
have
the
design
discussed
right
now,
it's
difficult
to
integrate
and
to
get
debug
information
from
study
because
logs
and
logs,
but
people
have
difficulty
reading
logs,
and
we
want
to
have
a
structured
way
to
to
report
events
out
of
history
and
starting
with
knox,
because
that's
probably
the
most
important
thing
that
happens
in
study.
I
H
That
can
be
used
for
this,
but
it's
more
for
tooling
that
that
integrate
with
studies.
So,
for
example,
you
can
specify
that
all
knocks
or
all
important
events
from
yesterday
are
published
to
a
pub
sub
system,
and
then
there
you
have
some
tools
that
is
posting
them
to
slack
or
to
you
know,
google
chat
or
some
other
system,
because
once
you
publish
to
a
pub
sub
system,
there
are
integration
points
where
you
can.
H
We
could
have
a
tool,
for
example,
that
it's,
for
example.
What
one
thing
I
have
in
mind
is
to
you
know,
to
use,
for
example,
pop
something
in
the
case
of
google
or
some
other
system
and
then
have
a
debug
tool.
That
is
just
watching
the
events
and
you
know,
subscribing
to
the
topic
and
and
it's
displaying
any
arc
or
other
events
that
is
happening.
N
K
If
I
think
you
had
some
rfp
or
rfc
for
it,
yes,
so
I
would
recommend,
if
you
can
add
some
user
issues,
conversations
whatever,
where
people
are
specifically
asking
for
things
like
this,
because
I
haven't
come
across
it.
I
know
it
is
a
useful
thing
to
have,
but
in
terms
of
privatization,
that
would
help
right.
Are
people
actually
waiting
for
it?
They
really
want
it
or
some
of
the
other
things
much
higher
in
the
priority
list.
H
So
this
whole
start.
This
whole
thing
started
with
with
external
study
where
it
is
difficult
to
get
information
about
connected
implement.ps.
Basically,
it's
yokatrops
because
you
don't
have
a
direct
connection
to
sdod
and
also
when
you
have
a
distributed
system
where
you
have
multi
clusters
and
multiple
studies
running
in
different
clusters.
Ps
doesn't
actually
work
very
well
today,
because
you
cannot
really
connect
to
all
cluster
holistic
ids,
and
there
is
no
other
way
that
I
know
to
implement
this
today.
Exactly
that's
kind
of
the
only
implementation.
If
someone
has
a
different
implementation.
M
K
L
R
H
That
is
reporting
the
events
to
xds
using
xds
as
a
transport,
and
it's
that
it's
a
pretty
trivial
implementation.
I
mean
our
point
of
view
is
just
using
some
http
post
on
some
configuration
using
cncf
eventing.
That
was
the
initial
proposal,
so
it's
not
a
lot
of
coding
easter
side.
It's
just
just
you
know
integration
with
some
external
system,
and
then
we
can
let
everything
else
to
community
and
to
other
systems
too
to
deal
with
it.
R
A
So
I
have
one
quick
comment
on
the
mesh
config
cleanup
and
other
just
generally
other
cleanups
of
that
type.
Let's
try
to
figure
out
what
our
migration
story
will
be
as
part
of
the
work,
so
not
just
to
find
the
new
apis,
but
figure
out
how
we're
going
to
migrate
all
the
users
from
the
current
ones.
And
ideally
the
answer
is
not
like
make
them
do
a
ton
of
work
right.
We
should
think
about
how
we
can
help
them,
and
can
we
automate
some
of
this
and
things
like
that.
H
A
G
G
It's
something
that
we
have
been
talking
about
for
a
while,
but
have
been
hesitant
to
do,
because
the
rate
of
change
is
so
high
and
testing
was
difficult,
but
sam
did
a
great
job
testing
these
these.
What
were
previously
called
skip
version
upgrades
for
us
and
we've
sort
of
stabilized
to
the
point
where
it's
viable
for
our
users.
G
So
that's
great.
These
upgrades
have
been
the
number
one
most
requested,
upgrade
related
feature
in
our
upgrade
survey
in
both
one
nine
and
110..
So
it's
great
that
we're
meeting
our
users
where
they're
at
and
helping
them
to
upgrade
less
frequently
the
downside
is
istio
1,
8
and
istio
110
were
never
actually
under
support
simultaneously.
G
So
this
proposal,
you
know,
proposes
that
we
extend
our
support
window
for
each
of
our
releases
by
three
months.
The
net
gain
for
our
users
is
that
they
only
need
to
upgrade
their
istio
installation
twice
a
year
and
for
every
sorry,
this
I'm
talking
particularly
about
minor
version,
upgrades
I'm
not
talking
about
patch
upgrades.
Those
are
a
different
beast,
so
they
only
need
to
do
minor
version
upgrades
twice
a
year
and
they
have
a
three
month
window
to
perform.
G
G
F
K
F
F
Like
you've
mentioned,
we
need
to
staff
the
pswg,
but
are
we
only
fixing
security
fixes
like
if
there's
a
critical
bug
in
envoy?
Are
we
going
to
go
fix
envoy
if
it's
not
security,
related
that
type
of
thing?
So
I
I'm
having
a
hard
time,
like
kind
of
reconciling
how
users
are
going
to
understand
that
and
what
we're
expected
to
do,
because
it's
kind
of
vague
right
now,
but
I
think
it's
a
very
critical
point.
G
Yeah,
that's
a
great
point
in
talking
with
you
and
others
in
the
pswg.
It
sounds
like
already.
We
exercise
discretion
in
what
gets
back
ported,
where
the
further
we
have
to
backport
a
fix
the
more
work.
It
is
because
the
more
the
code
has
aged
since
the
fix
was
created,
and
so
already
for
each
fix,
we're
sort
of
making
ad-hoc
decisions
of
how
severe
is
the
bug
that
we're
patching?
How
important
is
it
to
get
this
fixed
back
to
the
version?
My
proposal
is
only
that
we
would
continue
that
level
of
discretion.
F
It
does,
but
in
some
ways
it
makes
it
worse
because
now
we're
telling
them
hey
and
we'll
probably
publish
publicize
this
a
lot
we'll
you
know
put
a
blog
post
but
hey,
don't
worry,
go
to
three
versions
back,
but
actually
we're
not
going
to
backboard
any
bug
fixes
because
it's
too
hard
right.
It's
kind
of
a
bad
impression
from
the
user.
H
All
right,
I
think
I
was
next
so
I
I
love
the
idea
of
having
long-term
releases,
I'm
absolutely
worried,
but
not
necessarily
all
releases
to
be
long-term
releases.
That's
my
concept,
because
that
is
basically
unrealistic.
It's
basically
just
increasing
the
amount
of
work
and,
and
so
back
backwarding
a
bug.
What
releases
it's!
H
I
don't
think
it's
we
we
can.
We
can
deal
with
such
much
stress
if
we
do
every
other
release.
Things
may
be
a
bit
better
because,
let's
say
110
is
a
long-term
release.
112
is
a
long-term
release
and
so
forth,
because
at
least
we
we
have
a
bit
more
determination,
the
other
one.
It's
you
know
it's
kind
of
yeah
people
who
want
new
features.
G
So
costan
that,
actually
you
know
you
and
I
co-authored
the
first
version
of
this
dock
and
it
was
for
every
other
release
to
have
an
extended
support
window.
The
feedback
that
I've
heard
from
various
members
of
the
toc
and
the
community
is
that
that
would
create
too
much
confusion
on
the
part
of
our
customer
and
that
if
we
tried
to
extend
it
beyond
nine
months,
like
I
think
the
initial
proposal
was
for
12
months
on
every
other
release.
H
That's
common
to
water,
so
we,
the
window,
is
as
much
as
we
can
support
our
release.
We
don't
compare
this
and
everything
else.
The
question
is:
do
we
want
each
release
to
be
a
long-term
release,
or
do
you
want
some
releases
to
belong
so
basically
you're
proposing
load
time
releases?
You
are
proposing
extending
the
the
life
of
the
release,
exactly
the
difference.
G
I
Okay,
so
a
quick
comment,
just
wondering
you
know
since
kubernetes
already
moved
to
every
four
months
since
we're
talking
about
overheads
of
releasing
and
qualify
and
also
supporting
them
from
product
security
stance.
I
was
wondering
starts.
Have
you
considered
alternative
proposal?
If
we
do
release
every
four
months.
G
Yeah
eric
did
a
great
job,
exploring
the
possibility
of
releasing
every
four
months
again.
That's
in
the
alternatives
considered
section
and
wrote
a
big
table
on
it.
The
long
and
short
of
it
is
that
kubernetes
now
has
a
trimester
release.
Schedule,
while
envoy
has
a
quarterly
release.
Schedule
envoy
is
a
far
more
important
dependency
to
the
istio
project
in
terms
of
the
need
to
stay
in
the
support
window
and
so
actually
sven.
G
G
D
G
K
I
think
I
was
yeah,
so
there
are
a
few
things
that
I
want
to
mention
because
we
have
been
discussing
it
in
product
security
working
group,
so
mitch
your
concern
and
what
and
the
others
in
the
pswg
they
raised
about
back
booting
and
the
you
know.
The
extra
effort
it
takes
is
valid
on
our
another
branch,
but
for
the
last
few
cves
we
have
been
doing
the
work
anyways
most
of
the
vendors
have
customers
who
are
on
these
older
branches
and
we
end
up
patching
them
right.
K
No
one
moves
as
quickly
as
the
stewardesses,
that's
the
reality,
so
in
fact
we
have
been
even
patching
up
to
like
one
six
or
something
even
for
the
latest
ones.
So,
oh
go
ahead!
Oh
no!
I
was
just
saying
that,
even
though
this
concern
is
valid,
we
are
doing
the
work
so
might
as
well
get
the
benefit
of
it.
Second
point
before
I
give
it
back
to
you:
is
our
process
of
when
a
bug
gets
fixed,
even
in
our
supported
n
minus
one
release
is
really
weird
right
now
right,
it's
basically.
K
G
Yeah,
my
intent
is
not
to
touch
that
standard
or
that
process
at
all.
Maybe
it
needs
to
be
touched
and
modified,
it's
possible
that
we
should
reconsider
it,
but
my
intent
is
not
to
address
that
in
this
proposal.
John,
I
know
you've
had
some
thoughts
on
what
the
vendors
do
with
cve's
currently
did
you
want
to
share
that.
F
Yeah
I
mean
it's:
it's
we
do
like.
The
vendors
do
patch
most
of
cves.
There
are
some
differences
because
it's
not
always
required
like
if
there's
a
cv
in
estro,
we
just
have
to
fix
it.
We
can't
say
that
hey
no
one's
using
this,
probably
whereas
with
us,
you
know
vendors,
have
more
restrictive
deployment
setups.
Typically,
so
we
can
say
something
like.
Oh,
that
was
multi-cluster.
F
G
John,
what
we
learned
in
october,
though,
is
that
our
users
don't
actually
recognize
when
they're
on
unsupported
versions
of
istio
or
vulnerable
versions
of
istio.
Today,
what
we've
learned
is
that
our
users
are
running
unsupported
versions
of
istio,
but
expecting
that
they
have
no
cves
and
that
they
can
be
supported
with
new
patch
releases
when
needed.
G
I
I
couldn't
answer
the.
Why
question
there?
I
think
that
we
had
communicated
pretty
clearly
what
our
support
policy
is,
but
the
bottom
line
is
our
users
feel
like
they
should
be
supported
by
the
community
and
or
not
so
this
would
simply
mean
those
users
who
are
on
the
on
the
one.
Nine
release
in
next
quarter,
who
feel
like
they
should
be
supported
would
actually
be
supported.
There
will
still
be
users
running
one
eight
next
year,
who
expect
support,
and
this
proposal
doesn't
help
them.
Does
that
make
sense.
A
So
I
I'm
looking
at
the
chat
the
chat
going
on,
but
I'm
actually
kind
of
in
favor
of
proposing
the
alternative
of
just
do
this
for
even
numbered
releases.
So,
rather
than
do
this
forever
release,
just
do
it
for
even
number
of
releases
as
a
way
to
reduce
costs,
and
potentially
you
know
we
could
to
to
john
and
costume's
point.
We
could
do
more
on
those
releases
right.
A
We
can
put
more
things
backwards
to
those
and
say
we
could
possibly
even
say
our
direct
upgrade
is
only
for
even
to
even
right
like
we
could.
We
could
make
this
a
policy
where
we
say:
okay,
the
even
releases
are,
you
know,
just
like
linux.
Even
releases
are
the
ones
you
you
want.
If
you
want
to
do
a
long
term
thing
odds
are
for
new
stuff.
Sorry,
I
don't
know
if
other
people
are
interested
in
that
one,
but
I'd
like
to
see
that
one
explored
so.
I
I
A
And
I
think
the
other
thing
you
would
see
what
costume
just
said:
you'll
see
someone
like
they're
on
and
even
and
then
you
know,
111
that
comes
out
or
113
and
it
has
some
feature
they
really
want.
They'll
go
to
that.
But
then
they'll
have
to
do.
You
know,
do
another
quick
upgrade
to
114
and
then
they
can
go
back
to
staying
on
on.
K
So
so
much
if
I
remember
this
discussion
long
back,
maybe
earlier
early
next
year
last
year,
I
think
the
key
was
we
didn't
support,
skip
version
upgrades
and
that's
why
we
punted
on
all
this
discussion,
whether
we
need
to
do
lts
on
even
odd
or
we
need
to
just
extend
the
window.
Now
that
we
have
confirmed
support
for
skip
upgrades,
I
I
think
what
swen
is
saying
makes
sense.
I
mean
if
it
reduces
our
burden
and
gives
the
same
value
to
the
customers.
G
A
C
G
K
D
G
A
D
K
L
F
G
I
don't
think
that
would
be
the
case
if
you
look
at
the
110
window.
110
ends
support
at
the
same
time,
111
in
support,
oh
yeah,
that
that's
what
I'm
saying.
I
don't
think
it
will
happen
here.
I
guess
technically,
it's
not
exactly
the
same,
because
111's
end
of
support
is
based
on
the
112
release
date
and
110's.
End
of
support
is
based
on
the
111
release
date,
but
as
long
as
we
stay
on
a
fairly
even
quarterly
cadence,
it
should
be
approximately
at
the
same
time,.
K
G
D
A
A
C
That
saving
I've
got
to
think
about
it,
but
does
that
only
apply
when
what
am
I
trying
to
say?
Does
it
actually
reduce
the
load
during
a
cve
release,
because
the
challenge
with
the
product
security
workbook
is
we've
got
to
release
all
of
these
supported
releases
at
the
same
time,
but
yeah
I'll
go
I'll,
go
back
and
think
about
it.
G
Okay,
so
I'll
circle
back
with
the
product
security
working
group
get
their
feedback
on
the
idea
of
an
lts
tick,
tock
sort
of
program.
The
toc
agenda
is
very
full
for
the
next
three
or
four
weeks
with
road
maps.
Would
it
be
all
right
for
me
to
schedule
a
follow-up
meeting
that
is
separate
from
the
normal
toc
for
us
to
kind
of
close
the
book
on
this.