►
From YouTube: 2021-12-16-Node.js Technical Steering Committee meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
Yes
should
probably
mention
we
are
currently
having
some
issues
with
the
some
of
the
macs
in
the
ci,
so
there
was
a
scheduled
maintenance
window,
but
that's
currently
been
extended.
So
at
the
moment
we
are
just
waiting
to
hear
back
from
our
provider
as
to
when
those
will
be
back
up.
So
at
the
moment
we
are
down
a
few
macs
in
the
ci,
so
you
may
have
to
wait
for
any
cis
if
you're
running
things
from
pr's
and
things.
A
Yeah-
and
it
might
be
worth
mentioning
that
might
persist
till
tomorrow-
yeah,
we
don't
know
yet.
Okay,
maybe.
A
A
Okay,
I
don't
have
any
updates
from
the
board
or
the
cpc
this
week
as
things
you
know
over
the
next
couple
weeks,
a
number
of
the
cpc
meetings
have
been
canceled
and
there's
no
board
meetings
or
anything
planned,
so
pretty
quiet
on
that
front.
A
Okay,
so
the
next
things
we
might
as
well
move
on
to
the
issues
tag
for
the
agenda,
the
first
one
is
the
meta
move
emeritus
to
emeritus
automatically
after
18
months,
and
actually
I
see
that's
already
been
closed.
So
I
don't
think
that
there's
any
discussion
that
we
actually
need
on
that.
A
Okay,
the
next
one
is
managing
feature
requests.
This
is
number
four
one,
one
one
three,
and
actually
I
added
this
to
the
agenda.
You
know
I
think
it
was
maybe
maybe
about
a
month
ago.
Well,
maybe
not
maybe
just
well.
Actually,
I
think
it
was
about
a
month
ago.
Anyway,
we
were
looking
at
all
the
issues
across
the
in
the
nord
note
core
repo
just
to
seeing
what
we
could
triage
to
bring
down
number
something.
A
One
of
the
things
I
noticed
is
that,
like
20
of
our
issues
are
feature
requests-
and
you
know,
153
are
more
than
a
year
old,
96
more
than
2
years
old,
so
it
seems,
like
we've
got
a
lot
of
feature
requests
which
I
kind
of
doubt
anybody
is
looking
at
and
I'm
wondering
if
we
should
do
something
in
terms
of
like
making
sure
we
just
don't
let
those
hang
around
open
forever.
A
So
basically,
if
somebody
opens
a
feature
request,
you
can
like
thumbs
up
the
issue
and
issues
get
closed
if
they
don't
reach
a
certain
certain
threshold
after
some
amount
of
time
and
that
that
actually
sounded
reasonable
to
me
like
if
you
can
get
a
thousand
people
to
pee
to
to
thumbs
up
your
your
feature
request.
Maybe
that's
something
we
should.
You
know
prioritize
to
look
at
if
it's
one.
A
A
There
was
a
bit
of
discussion
in
the
issue,
but
not
too
much
so
I
wanted
to
put
it
on
on
the
agenda
to
try
and
get
some
discussion
see
if
we
you
know
if
I
could
get
some
feeling
from
the
tsc
members
as
to
like
what
might
be
a
a
direction
that
would
people
would
find
acceptable.
A
You
know
I
think
rich
had
made
some
suggestions.
One
of
them
was
like
to
say,
let's
close
them
after
you
know
some
period
of
time,
whether
it's
60
days,
90
days,
whatever,
with
a
ref
with
a
reference
to
the
rfc
process.
Basically
saying
you
know
sorry,
we've
closed
this
because
nobody's
gotten
involved.
There
hasn't
been
any
discussion
in
quite
a
long
time.
If
you
think
you,
you
know,
if
you
think
this
is
really
important,
you
know
you
could
open
up
the
discussion
through
the
rfc
process.
A
A
So,
yes,
I
didn't
think
about
that.
When
I
was
reading
the
comment
about
yeah,
maybe
we
would
have
to
actually
put
them
in
I
I
guess
I'm
coming
from
like
we
have
a
huge
number
of
these
and
I
don't
know
that
it
makes
sense
to
have
them
open,
but
it'd
be
interesting
to
hear
what
other
tse
members
think
in
terms
of
like
that's,
fine
and
better
to
just
leave
them
there
or
whether
we
should
try
and
prune
down
that
list.
C
A
A
Right
and
and
that's
it
in
fact,
like
we
started
auto
closing
or
we
use
stale
we're
using
stale
bot
in
the
node
api
repos
and
it's
actually
been
a
pretty
decent
reminder
like
oh,
we
forgot
to
actually
do
you
know.
We
haven't
actually
looked
at
this
for
a
certain
amount
of
time
and
it
does
actually
sometimes
make
even
like
the
maintainers
say,
wait
a
sec.
This
is
important.
We
better
do
something.
D
What
I
do
is
like,
could
we
close
it
with
a
comment
like
please
comment
or
reopen
if
this
is
still
right
issue
for
you
or
something
just
so
that
people,
you
know,
are
not
afraid
to
comment
or
reopen
something?
That's
been
closed
by
the
sailboat.
E
C
C
A
Okay,
so
yeah,
I
think
I
looked
at
it.
I
think
we
can
even
have
the
stale
bot
only
apply
to
certain
tags,
so
I
think
we
could
set
it
up
so
that
basically
just
for
feature
things
tag,
feature
request
would
say
after
this
amount
of
inactivity.
Yes,
we're
going
to
put
a
comment
and
then,
after
30
more
days
it
gets
closed
or
something
so
okay,
so
it.
A
If
nobody
is
like
violently
of
you
know
thinks
it's
a
bad
idea.
I
can
put
together
some
sort
of
proposal
and
document
that
that
says
like
here's,
how
we'll
manage
our
feature
requests
and
that
what
it
would
you
know
after
what
time
we
would
close
them
and
we
can
sort
of
close
on
the
details
as
part
of
landing
that
the
the
other
question
I'd
have
is
in
terms
of
voting.
Do
people
think
there's
any
value
in
saying,
like
you
know,
have
people
thumbs
up,
feature
requests
and
then
us
try
and
look
at
that
number.
Somehow.
A
Is
that
interesting
because
sorry,
I
I'm
just
wondering
like
it,
I'm
I'd
still
be
interested
to
know
which
ones
are
thumbed
up
a
lot
fetch
off
the
top
of
my
head
right,
websockets.
B
Okay,
those
kind
of
things
so
they've
been
open
for
who
knows
years
right,
don't
want
to
close
the
doors
exactly
yes,
probably
not,
but
I
mean
that's
so
yes
in
theory,
we
could
have
thresholds
for
voting,
but
we
are
probably
going
to
end
up
with
things
that.
B
A
E
Is
quite
probable
to
cause
issues,
but
at
the
same
time,
if
implemented
correctly,
each
would
likely
be
okay,
but
perhaps
we'll
need
some
more
discussion
about
how
exactly
to
implement
that
in
a
way
that
wouldn't
integrate
people
a
lot.
Perhaps
we
could
label
some
issues
at
the
start.
E
Something
that
the
there
is
a
label
that
will
tell
them
the
word
that
how
to
close
the
decisions
to
ignore
that
issue.
From
the
start
of
this
yeah,
there
is.
E
E
Can
get
involved
yeah.
A
E
Yes,
just
one
of
the
ideas
and
another
one
would
be
that
an
issue
that
was
close
to
stale
should
be
reopened
on
any
comment,
I
think
automatically,
because
if,
if
you
just
say
that
this
issue
after
post
in
30
days,
unless
someone
comments,
someone
might
miss
that
they
might
be
on
vacation
or
they
might
just
be
busy
with
other
things,
and
then
they
can
you'll
come
back
after
30
days
and
we'll
see
that
their
issue
was
closed
and
if
it
won't
get
you
open,
when
they
comment,
no
one
will
notice
it.
E
Why
not,
I
think
it
should
be
doable.
We
have
our
own
board,
I
think.
E
E
Like
you
just
do
it
without.
E
Discussing
and
planning
how
to
avoid
the
potential
issues
with
that.
It
is
something
that
likely
cause
disruption
and
you
will
have
net
negative
effect.
So
you
need
to
be
very
careful
with
that.
A
A
A
A
E
E
And
yes,
it's
an
ongoing
problem.
There
are
models
in
it.
The
system
that's
claimed
that
they
can
run
and
trust
code
using
just
vm,
and
they
actually
came
to
london
just
to
go
to
entire,
very
easy
to
escape
and
if
you
get
supported,
they
kind
of
fix.
It
also
breaking
another
thing,
something
else
in
the
process
and
they.
E
Except
for
cases
when
the
whole
javascript
interfaces
in
waiters,
but
that's
not
running
interesting.
B
I
posted
the
link
to
the
docs
in
the
in
the
meeting
minutes
where,
where
we
do
state
that
it's
not
not
to
be
used
as
a
security.
A
A
C
E
A
Okay,
so
I
think
I
think
without
more
context.
That's
maybe
the
discussion,
that's
the
useful
discussion
that
we
can
have
I'll
paste
into
the
issue.
The
link
answering
that
first
question
just
saying
you
know
we
already
did
that
and
then
chakra.
If
you
have
more
thoughts,
you
can
always
jump
into
the
issue
itself.
Does
that
make
sense.
E
A
The
next
issue
is
renamed
default
branch
from
master
domain.
I
I
don't
have
any
updates
on
that.
I
haven't
had
any
time
to
sort
of
look
at
whether
some
of
the
the
last
remaining
ones
have
had
any
progress.
I
don't
know
if
anybody
else
has
had
a
chance
to
look
recently.
A
The
next
one
is
migration
of
core
modules
to
primordials,
and
I
think,
as
discussed,
the
real
issue
we
should
talk
about
is
1-104,
which
is
related
to
the
vote
so
and
next
time
that's
the
one
that
will
show
on
the
agenda
now.
F
Yeah-
and
so
so
I
mean,
I
think,
the
I
think
the
one
you
want
to
look
at
at
this
point
is,
I
mean
I'm
gonna,
I'm
gonna
paste.
This
comment
into
the
chat,
which
is
where
we've
got.
I
think
we
have
an
agreement
that
we're
down
to
these
five
options
at
the
most
and
I've
been
suggesting
we
remove
c,
and
I
think
there
seems
to
be
there
seems
to
be
some.
D
I
mean
yeah,
I
I
guess
there
is
some
overlap
there
with
the
technical
priorities
thing.
F
C
is
overlap
but
the
technical
priorities,
yeah,
and
also
just
I
mean
I
just
don't
think
that
we,
you
know,
we've
as
as
a
as
a
as
a
governing
body
as
a
decision-making
body.
We
have
been
very
slow
to
deal
with
this
issue
and
and
a
lot
of
work
has
gone
into
it
by
by
us
by
by
by
a
small
part
portion
of
the
tsc.
F
You
know
garish
you
and
you
know
antoine
and
a
few
others,
but
yeah,
and
I
think
that
just
like
asking
for
more
feedback
from
the
community
is
really
just
a
way
to
like
defer
the
need
to
make
a
decision
at
some.
At
some
point
we
need
to
make
a
decision.
I
think
we're
past.
That
point.
I
think
we
need
to
just
do
it.
A
F
F
Okay,
all
right
and
then
and
then
I
was
also
arguing
for
the
removal
of
d,
which
is
do
not
so
actually
for
the
for
for
the
interest
of
and,
and
I
see,
colin
dropping,
b
and
c.
Okay,
so
we'll
go
back
to
me,
but
for
the
interest
of
people
who
are
streaming
or
people
watching,
the
recording
c
was
ask
the
community
for
me
for
more
feedback.
F
I've
been
advocating
for
dropping
d
as
well,
which
is
which
is
do
not
port
any
further
code
to
primordials,
but
do
not
remove
existing,
in
other
words,
just
leave
it
exactly
where
it
is
now
and
don't
don't
don't
increase
use
of
primordials
but
also
don't
remove
it,
and
I
kind
of
think
that
that's
like
the
worst
of
all,
that's
just
like
oh
well,
wherever
it
ended
up,
is
where
we're
gonna
leave
it.
F
D
F
F
Okay,
so
I
see
colin
colin
in
the
chat
is
advocating
for
removing
b,
which
is
fully
migrate,
module
loaders
and
policy
code
to
c
plus,
plus
and
undo
all
primordials,
no
ambi.
The
advantage
is
no
ambiguity
about
what
code
has
to
be
migrated
and
what
code
does
not,
and
I
I
think
that
there
are
people
who
who
who
might
advocate
for
that.
But
I
don't
know
if
they're
here
today.
D
A
But
I
think
we're
now
starting
to
get
into
like
how
we're
going
to
vote
on
these
yeah.
I
think
if
we
remove
c
there's
nothing
which
delays
the
vote
and
like
well,
I
agree
with
you
on
d
and
I
wouldn't
vote
for
it.
I
don't
think
it's
important
to
remove
it
from
the
vote
like
we're
down
to
a
small
enough.
F
F
So
the
only
the
only
open,
the
only
remaining
issue,
then
I
think,
is,
is
is
to
make
sure
everybody
has
enough
information
to
understand
e,
which
is
antoine's
suggestion
about
the
the
bind.
This
proposal,
which,
let's
see
antoine,
follow
up
with
a
question
that
I
asked
about
whether
it
would
mean
waiting
or
not-
and
he
said
no,
I'm
altering
the
code
using
a
syntax
not
get
supported
by
v8.
F
A
F
That's
that's
getting
into
the
details
and
that's
getting
into
stuff
that
you're,
probably
in
the
issue
tracker,
so
that
everybody
can
read
it
and
everybody's
on
the
same
page.
I
think,
but
I
think
that,
like
in
terms
of
in
terms
of
like
do
we
have
do,
we
have
a
small
enough
number
of
items
that
we
can
that
we
can
call
for
our
vote
and
continue
to
have
these
conversations
clarifying
questions
you
know
and
so
on
and
so
forth,
and
I
think
the
answer
is
yes.
F
C
So
I
don't
know
if
folks
I've
seen
I've
suggested.
Maybe
we
should
do
two
votes
because
clearly
promote
yours
or
a
big
like
has
a
big
impact
on
code
readability
and
I
think
reuben
as
a
for
example.
Reuben
has
a
would
like
to
see
that
go
away,
but
maybe
temper
proofness
is
not
something
like
if
we
could
have
both
temper-proof
nests
without
pro
modules.
It
wouldn't
would
like
that.
C
F
I
wonder
if
the
the,
if
you
know
whether
or
not
we
should
make
something
tamper-proof,
I
wonder
if
the
answer
to
that
is
dependent
upon
the
implementation.
Like
some
people
will
some
people
will
say
no
if
it
means
moving
everything
to
c
plus
plus
or
I
imagine
and
yeah
I
don't
know,
but
maybe
maybe
it'll
work.
I
don't
know
what
do
other
people
think,
but.
D
C
Yeah
and
like
I
said,
maybe
we
also
would
like
to
have
a
report
tempo
proof,
because
it's
not
a
performance
sensitive
part
of
node
at
all
and
it
gains
of
being
temporal
proof.
But
maybe
I'm,
but
it's
something
we
don't
want
to
include
in
the
vote.
D
I
think
like
option
e
is
when
that
exists.
We
can
discuss
this
again,
but
it
doesn't
exist
yet
so,
given
the
current
way
of
implementing
primordials,
I
think
that's
the
context.
We
have
to
keep
in
mind
here
like
if
there
comes
a
way
to
do
primordials
that
is
both
performance
wise
and
maintain
a
little
bit
device
good.
Then
I
mean
there's
not
much
to
discuss
just
let's
just
do
it,
but
we're
not
there
right
now
are
we.
D
A
F
F
So
treating
it
as
a
as
an
author,
it
now
proposal
and
you
know
like
we're,
making
a
decision
now.
We
can
always
make
another
decision
a
year
from
now
when
new
things
are
available
to
us.
But
what
are
we
doing
sure?
I
think
I
think
the
vote
is
on
what
are
we
doing
right
now
and,
and
I
I
I
would
be
surprised
if
we
chose
to
do
that,
but
I'm
not
you
know
if,
if
that's
what
everybody
else
wants
to
do,
I'm
okay,
but
I
think
it's
I
think
it's
fine
to
include
it.
F
I
think
it's
a
viable
option
and
I
might
be
surprised
I
just
yeah
I
just
wanted
to.
I
just
want
to
make
sure
we
ripped
out
c,
because
c
was
the
one
that
was
like
we're
not
was
basically
voting
to
not
actually
make
a
decision
and-
and
I
think
that
yeah
now-
I
guess,
but
the
thing
that
antoine
originally
brought
up
to
started
this
conversation
was:
do
we
want
to
have
two
votes,
one
on
whether
we
want
to
make
things
tamper,
proof
or
not,
I'm
inclined
to
say
no,
but.
C
What's
bugging
me
about
this
is
okay.
If
we
decide
that
module
policy
will
be
time
to
proof,
will
we
undo
what
has
been
done
in
http
or
not?
Will
we
keep
the
making
pro
modules
in
ripple?
It
gives
a
lot
of
grey
area.
C
A
C
Say
that
yeah
yeah
we.
C
C
F
Need
to
make
you
know,
decisions
about
about
multiple
sections
of
the
code,
but
I
do
think
that
I
do
think
that
making
a
decision
about
module
loading
and
policy
first
makes
a
lot
of
sense
because
those
are
obviou.
If
you
want
something
to
be
tamper-proof,
those
are
obvious
areas.
You
want
things
to
be
tamper-proof,
I
think,
like
you,
don't
want
policy
to
be
affected
by
tampering
with.
D
I
don't
know
this
feels
like
we're
going
back
to
square
one
a
little
bit,
I
think,
like
everybody
agrees,
that
module
loading
and
policy
code
makes
sense
to
make
tamper
proof
and
we
are
okay
to
give
up
some
maintainability
in
order
to
get
there.
I
think
we
have
consensus
on
that
topic,
mostly
at
least,
but
I
don't
think
you
know
making
other
things
tamper-proof.
F
So
I
think
I
would
like
to
I
think
what
I
would
like
to
do
is
call
for
a
vote
on
the
module
loading
and
policy
stuff
using
these
four
options
and
give
it
a
week
well
maybe
two
weeks
because
holidays
or
whatever,
but
don't
give
it
a
whole
lot
of
time.
Because
conversation
going
on
a
long
time
and
hopefully
people
have
a
decent
idea
of
where
they
stand
and
if
they
don't,
maybe
they
should
abstain.
F
Yeah
I
want
I
want
us
to
make
a
small
decision.
I
want
to
actually
say
we
made
a
decision
and
scoping
it
to
just
those
two
modules
makes
that
possible.
Let's
do
that,
let's
make
that
small
decision,
and
then
we
can
talk
about
slightly
larger
decisions
from
there
like
I
don't
I
don't
mind
talking
about
this
for,
like
the
next,
like
three
or
four
months,
if
we're
making
decisions
along
the
way
you
know,
I
just
don't
want
to
talk
about
it
for
another
three
or
four
months
and
still
not
make
a
decision.
A
A
F
I'm
probably
just
add
the
word
in
my
in
just
at
the
at
the
outset.
Regarding
module
loading
and
policy.
Do
you
want
to
a
you
know:
temple
profit,
yeah,
tamper,
proof
right,
yep,
that
one's
obvious
through
the
through
the
through
the
you
know
through
the
through
through
primordials
right
I
mean
b,
move
it
to
c
plus
plus
to
make
a
tamper
proof
d.
F
Don't
do
anything
to
it,
just
leave
it
as
it
is
now.
I
you
know
and
e
try
to
tamper
proof
it
with.
A
A
A
A
F
A
A
F
So
and
yeah
and
we
can.
D
F
Yeah
those
sounds
wait.
Those
are
three
number
four.
Fourth
one
is
use,
bind
this
syntax
to
make
it
tamper.
Proof
which
you
know
is
the
one
that
you
said
you
can't
imagine
anybody
doing
so.
You
know
I
can
and
then
and
then
five
would
be,
don't
bother,
making
a
tamper
proof
there
did
you
say
that
already
and.
F
C
D
Which
is
the
the
one
you
thought
is
not
a
decision
yeah.
I
don't
like
that
one,
but
but
I'm
happy
to
leave
it
in
there.
Okay
and
is
is
c
plus
plus.
Even
you
know.
I
think
in
theory
sounds
good,
but
practically
is
that
even
an
option
because.
F
I
mean,
I
think
I
I
I
mean
I
I
know
he's
he
signed
off
already,
but
I
mean
I,
I
suspect
that
you
know
you
know
I
mean
I
don't
know
what
is
I
don't
know
what
his
free
time
looks
like,
but
you
know
I
mean
you
know
the
idea
that,
like
bradley
might
implement
policy
and
you
know
it
seems
to
be
not
not
not
impossible.
To
imagine
let's
see
what
this
is,
that.
H
I
dropped
because
I'm
not
supposed
to
be
in
tdsc
meetings
and
I
had
the
wrong
account
on
my
zoom.
I
got
confused
all
right
german
though,
so
all
the
module,
loader
and
policy
stuff
used
to
be
written
in
c
plus
plus,
I
would
much
prefer
to
put
it
back
to
c,
plus
plus
there
were
less
problems
back
in
c
plus
there
are
many
more
bugs
in
javascript.
F
H
H
H
F
H
Correct
so
the
loaders
working
group
is
finally
ready.
I
think
we've
reached
feature
parity
where
we
can
move
loaders
off
thread
and
we
want
to
move
all
es
module,
loaders
off
thread,
which
would
mean
they
are
already
in
kind
of
like
a
protected
area
that
has
to
be
invoked
via
the
cli.
We
probably
don't
need
to
tamper
proof
it
at
that
point,
because
random
user
code
off
npm
most
likely
can't
tamper
with
it
so
you're,
probably
fine.
Then
you
only
need
to
guard
the
message
port
between
the
loaders
and
the
application
context.
H
Yep,
so
it's
separate
it's
it's
like
you
can
leave
the
code.
However,
you
could
port
it
back
to
javascript.
It
doesn't
matter
port
it
to
c
plus.
You
can
do
that
on
top
of
everything,
but
we
plan
on
doing
it,
at
least
for
the
es
module
loader
to
move
it
off
thread,
in
which
case
this
concern
goes
mostly
away
for
that
for
common.
Just
it's
not
practical
to
defend
it
right.
F
H
H
H
By
privileged,
I
mean
the
tamper
proof
area
or
whatever
we
want
to
call
it
and
the
application
context
the
thing
getting
random
modules
off
npm,
generally
loaders
policy
files.
We
can't
consider
untrusted
because
at
that
point,
they've
already
got
a
hold
of
things
too
powerful
to
really
for
us
to
be
concerned.
H
So
as
long
as
this
barrier
exists,
where
the
only
way
for
the
application,
npm
modules
to
communicate
with
the
privileged
loader
is
through
this
ipc
bridge,
probably
going
to
be
a
message
port.
That
means.
The
only
thing
you
have
to
defend
is
a
message:
port
against
tamper,
everything
else.
You
would
send
a
literal
object
or
string
through
it
and
it
would
be
handled
on
the
other
side.
H
F
So
here's
what
I'm
thinking
out
loud
about
this,
which
is
that,
like
okay,
if
we're
just
talking
about
esm
modules,
we're
not
we're
not
if
we're
not
concerned
about
c
common
js
and
es
modules-
are
gonna
just
be
taken
care
of
by
themselves,
whether
whatever
we
decide
to
do,
then
that
just
leaves
policy
which
is
also
like.
Like
you
know,
policy
is
basically
maintained
by
you
right,
I
mean
nobody
else
is
really
working
on
that.
H
Policy
integrates
against
the
module
loaders.
Yes,
I
think
there's
one
other
person
who's
done
commits
on
it.
Besides
me,
it
would
also
be
unaffected
in
es
modules.
Like
I
said,
this
is
only
going
to
protect
the
s
modules.
This
is
not
going
to
protect
common
js
modules.
I
don't
think
common.js
is
practically
defensible.
F
F
A
H
The
the
only
thing
you
would
probably
want
to
decide
before
going
over
there
is,
if
you
want
to
declare
commentaries
kind
of
indefensible.
H
A
F
Bradley,
do
you
want
to
add
a
comment,
or
would
you
prefer?
I
do
to
the
issue
just
explaining
what
you
just
basically
explained
to
us
that,
like
this
is
not
going
to
be
any
that
at
some
point
in
the
foreseeable
future,
modules
and
policy
will
be
nearly
or
completely
tamper
proof.
Because
of
this
reason.
H
H
A
A
A
A
Sounds
good
add
security
triaging
to
core
repo.
F
D
A
Okay,
the
move,
bnb
dev
and
that's
basically
been
moved.
I
think
we
can
close
the
issue,
so
I
just
commented
on
that.
So
I
think
there's
nothing
to
discuss
there
and
that
takes
us
to
the
end
of
the
issues
that
we
had.
I
know
we're
at
time,
but
rich
did
ask
that
we
stick
around
just
for
a
very
short
private
section,
so
I'll
put
it
I'll.