►
From YouTube: SLSA Biweekly (November 17, 2022)
Description
Meeting notes: https://docs.google.com/document/d/1cx3fOBfic6A0xc2on25ITK4vQHUdxgBmJoSS1LPqDJo/edit
B
A
B
This
is
this:
is
wonderful
man
yeah,
you
you
what
what
I've
been
able
to
to
see
over
the
last
eight
months
or
so,
and
then
just
the
of
that
Evolution
such
a
short
period
of
time
and,
of
course,
the
whole
year
that
has
been
the
openness
and
stuff
I.
Think
it's
absolutely
wonderful
man,
I
I'm
I'm,
so
I
I
feel
privileged
and
I
feel
I
feel
honored
every
time
I
get
on.
One
of
these
calls
because
there's
so
much
of
us
in
the
rooms
together
working
on
this
stuff.
It's
amazing.
F
C
Yeah
I
guess
we
could
get
started
just
as
a
reminder
if
anybody
who's
joining
now
feel
free
to
add
your
attendance
to
the
meeting
notes,
as
well
as
any
agenda
items
and
we
can
get
started
as
a
reminder.
This
meeting
is
being
recorded,
it'll
be
uploaded
to
YouTube
shortly
after,
and
your
participation
in
this
meeting
is
an
agreement
to
abide
by
the
open,
ssf
code
of
conduct
and
first
things
first
was
I'm,
not
sure,
but
is
there
anybody
new
on
the
call
who
wants
to
introduce
themselves.
E
Say
hi
myself,
David
zinzian,
with
VMware
I
I
am
in
a
field
role.
These
days,
I
spent
30
years
doing
security
and
many
of
those
as
an
auditor
as
a
various
Financial
spheres
and
I've
been
following
salsa
for
a
while
now
I'm
super
excited
to
have
time
to
just
for
now,
listen
and
see
how
it's
going,
but
eventually
contribute
as
I'm
able
cool
glad.
C
H
Sure
so
progress
continues
on
the
1.0
spec
work.
We've
discussed
various
topics
within
the
meetings
and
we're
making
progress
on
the
writing,
like
the
drafting
of
the
text,
but
I.
Don't
think,
there's
anything
big
enough
to
Warrant
discussion
at
this
group.
If
you
have
questions
I'm,
always
happy
to
answer
them,
there's
also
an
early
draft
of
a
1.0
provenance
format
that
hopefully
addresses
various
feedback
or
various
issues
that
we've
had
in
the
current
version.
H
H
H
Oh
in
terms
of
timeline,
because
this
come
up-
obviously
it's
taking
much
longer
than
expected,
as
most
software
projects
do,
the
plan
is
to
once
we
get
into
a
good
enough
state
that
is
like
readable
by
the
community
at
large.
We'll
have
a
review
period
of
I
would
say
at
least
a
month
where
community
members
can
look
at
it
make
sure
you
know
kind
of
test.
It
make
sure
it's
really
meeting
the
needs.
C
C
For
now,
one
of
the
things
was
some
of
the
additional
sort
of
collaboration
between
different
other
working
groups
like
The
Cloud
native
controls,
working
group
like
to
start
doing,
mapping
of
controls
between
Cloud
native
and
salsa
and
salsa
and
other
sorts
of
specs,
but
I
believe
that's
been
sort
of
just
put
on
hold
until
it's
also
1.0
is
final.
You
know
is
finalized
as
well
as
there's
a
bunch
of
work,
that's
being
done
from
the
oscal
side.
C
C
A
lot
of
folks
are
prepping
for
sort
of
talks
on
that
and
and
whatnot,
but
one
of
the
other
big
focuses
that
we
have
is
trying
to
also
build
like
make
sure
two
things.
One
is
make
sure
that
tools
are
going
to
be
like
a
lot
of
the
common
tools
that
we
have
are
going
to
be
ready
for
salsa
1.0,
so
we're
just
sort
of
following
the
spec
and
and
making
sure
that
you
know
once
the
the
the
spec
is
sort
of
finalized.
C
C
We
should
be
sort
of
building
a
salsa
validator
like
even
just
like
a
super
simple
like
hey,
because
this
is
actually
a
common
problem
in
the
s-bomb
space
is
a
lot
of
the
tools
that
are
generating
s-bombs
that
are
claiming
to
be
Cyclone,
DX
or
spdx
are
actually
like.
You
know
it
mostly
matches
the
spec
and
that's
making
consumption
of
some
of
those
s-bombs
really
difficult,
because
it's
hard
to
rely
on
so
I
think
it'd
be
worthwhile
to
you
know,
really
have
something
that
you
know
can
really
enforce.
C
Enforce
it,
and
so
that
you
know
you
can
run
against
all
the
you
know,
salsa
stuff,
that
gets
generated
by
something
and
and
essentially
verify
that,
yes,
it's
a
correct
URI
for
the
Builder,
not
just
a
string
or
whatever,
because
that
sort
of
stuff
is
going
to
cause
a
lot
of
issues
for
the
tools
that
consume
it.
So
I
think
that's
one
thing
that
we're
looking
at
as
well
as
potentially
something
like
a
library
or
a
set
of
libraries
that
can
then
support
that
shishank.
A
Yeah
I
think
I
think
that
would
be
very
helpful,
but
unless
I
missed
something,
the
spec
says
that
you
may
use
the
the
in
dodo
provenance
format,
not
necessarily
so
that
might
complicate
things
a
little
bit
but
yeah.
It's
certainly
better
than
nothing.
Most
people
are
probably
going
to
follow.
Follow
the
format.
C
Yeah
yeah,
that's
true.
Sorry,
I
I
should
say
that
it's
it's
more
for
the
specification
for
the
yeah,
the
in
Toto
attestation,
format
and
yeah.
I.
Think
that's
that
that's
the
important
piece,
because
most
of
most
of
the
built-in
tools
are
all
supporting
that
as
the
format
but
yeah
good
point,
and
then
one
of
the
other
focuses
is
still
on
identifying
gaps
in
the
sort
of
just
salsa
ecosystem.
C
Like
aggregation
tools,
we
know
that
you
know
there's
some
stuff
like
like
guac
and
a
few
other
things
that
are
starting
to
come
out
there,
but
we're
still
sort
of
like
looking
at
what
else
there
is,
for
you
know
not
just
the
generation
of
salsa,
which
there's
a
lot
of
tools
that
are
coming
out
of
that,
but
also
tools
that
can
consume
salsa
Beyond,
just
like
some
simple,
like
policy
validation
of.
What's
in
the
salsa
document,
foreign.
I
C
Yeah
I,
agree
and
I
know
Mark.
This
is
something
that's
been
brought
up
multiple
times
in
the
specification
meeting
as
well.
Where
does
it
make
sense
to
say?
Maybe
something
along
the
lines
of
it's
also
one:
it's
not
required
to
use
the
spec,
but
maybe
salsa
2
or
salsa
three.
It
is
100
required,
or
do
we
still
want
to
say?
No,
no.
We
want
to
make
sure
that
it's
flexible.
H
I
So
so
I
think
it
is
okay,
I
think
they
are
setting
themselves
for
trouble,
I
mean
I'm
the
old
standards
guy,
so
I
apologize
here,
but
you
know
my
experience
is
standards
are
needed
because
there
are
plenty
of
companies
that
try
to
just
get
a
modality
approach
to
a
problem,
but
with
merge
in
that
positions.
If
nothing
else,
you
know
you
may
decide
to
set
up
on.
I
You
know
yourself
on
one
particular
approach,
but
eventually
you
you
acquired,
or
you
acquire
another
company
that
made
a
different
choice,
and
now
you
have
an
interprety
problem
anyway,
so
I
I'm
not
disagreeing
with
what
you're
saying,
Mark
I
think
it's,
it's
totally
reasonable
to
say
there
are
different
ways
to
implement
it,
and
we
should
allow
for
that.
I
do
think
that
if
we
provide
the
tools
during
the
specific
way
with
that
mandating
that
you
use
those
tools,
it
will
be
an
extra
incentive
for
people
to
use
those
rather
than
something
else
and
and
I.
I
A
Oh
I
agree:
yeah
I
just
wanted
to
add
the
point
that,
from
my
experience,
what
I've
seen
is
that
there's
often
confusion
between
the
sort
of
metadata
you
require
say,
uri's
and
stuff
like
that
and
the
formats
that
you
that
you
transport
this
metadata
in
so
I,
don't
think
I,
think
I.
Think
salsa
has
been
very
good
and
being
careful
about
saying,
I
think
that's
largely
an
intention.
I
think
everyone
wants
to
share
the
same
metadata
right
but
I
think
I.
Think
people
are
going
to
probably
transport
it
in
different
ways.
A
C
Yeah
so
two
things
one
is
I
I
agree
with
Arno
on
on
a
lot
of
that
as
well,
which
is
just
a
lot
of
I
I.
Think
by
and
large
everybody
is
using
in
Toto
anyway,
at
least
what
we've
seen
in
the
public
space
I
agree
that,
like
we
don't
necessarily
you
know,
I
I
agree
that
maybe
even
just
saying
hey,
it's
not
required,
but
all
the
tools
are
going
to
be
supporting
mostly
this
one,
unless
something
else
comes
along
might
be
a
good
way
to
just
sort
of
settle.
That.
C
I
also
agree
with
what
you
said:
trishank,
which
is
a
lot
of
folks,
are
going
to
want
to
distribute
it
in
different
ways,
especially
when
it
comes
to
stuff
like
the
envelope
that
might
be
signing
it
and
yayada
and
I.
Think
that
there's
there's
a
lot
of
interesting
stuff
there
and
I
know
one
of
the
things
that's
been
I.
Don't
necessarily
think
it's
it's
something
we
have
to
talk
about
here,
but
something
that
maybe
should
be
talked
about
in
either.
C
Maybe
the
supply
chain,
Integrity
working
group,
or
something
like
that
is
there's-
been
a
lot
of
discussion
about
an
ontology
around
some
of
this
stuff.
Right,
like
a
lot
of
folks,
are
coming
in
and
saying
hey
with
stuff
like
how
eventually
S2
c2f
and
similar
sorts
of
things
are
coming
in
and
like
how
everything
is
kind
of
going
to
be
named
and
whatever
there's
some
folks
are
are
asking.
H
Yeah
I
I
guess
I
recommend
against
I'm
kind
of
on
Arno
side
in
terms
of
interoperability,
where
different
organizations
are
transmitting
the
data.
I
think
supporting
multiple
formats
is
really
confusing,
like
spdx
supports
like
six
different
serialization
or
formats,
or
something-
and
it's
super
confusing
like
I
know,
there's
good
reasons
that
they
do
that,
but
it
does
have
a
complexity,
cost
and
I
think
if
we
can
recommend
like
some
interoperable
format,
that's
like
I,
don't
care
so
much,
whether
it's
Json
or
something
else,
but
like
that.
H
B
Yeah
I
thought
that
that's
what
we
were
we're
looking
into
Oscar
I
thought
that
that
was
doubt
that
I'm
telling
you
oh,
it's
called
something
else.
I
I
thought
that
that
was
what
we
were
attempting
to
to
rectify
right,
Json,
XML
everything
they
can
all
go
into
all
Scout
and
oh
Scott's
supposed
to
be
able
to
take
all
of
those
formats
and
then
and
then
kick
out
something
that's
universally
acceptable
or
universally
can
be
universally
read
or
used
across
across
the
Spectrum.
B
Now
that
was
my
my
my
general
understanding
of
old
scholar
and
Oscar's
role
in
taking
a
lot
and
and
taking
in
a
lot
of
this
information
and
then
being
able
to
utilize
it
across
different
compliance
requirements
and
security,
Frameworks,
providing
reporting
and
and
everything
else.
So
that
was
my
general
thought
and
understanding
and
I
hope
that
that's
the
case,
because
if
that
is
the
case,
then
we're
we're
heading
in
the
right
direction.
C
As
far
as
the
actual
I
think
there
still
needs
to
be
a
like
some
sort
of
translation
layer
where
somebody
would
say:
okay,
well,
I'm,
going
to
consume
salsa
data
and
convert
it
into
oscow
format,
because
oscow
format
itself
is
not
really
conducive
to,
and
it's
not
really
intended
for
some
of
those
things.
So
it
is
and
I
think
when
it
comes
to
a
lot
of
these
things.
This
is
where
I
think
also
a
lot
of
the
tooling
is
going
to
come
into
play
of
like
translating
aggregating
some
of
this
information.
C
You
know,
and
some
of
that,
but
yeah
I
think
like
like
I
I,
because
I
think
this
is
also
one
of
the
challenges
is:
how
do
you,
let's
say,
take
information
from
salsa,
pull
it
out
and
say
hey.
This
is
proof
that
meets
these
oscow
requirements
or
whatever
I
think
is
going
to
be
an
interesting
challenge.
I
think
it
kind
of
goes
back
to
the
thing,
though.
C
If
if
we
have
12
different
formats,
then
the
the
tool
is
going
to
have
to
support
every
tool
is
gonna
have
to
support
those
12
different
formats,
as
opposed
to
having
one
standardized
format
at
least
internally
right-
and
you
know,
if
folks
say
Hey,
you
have
some
internal
format
great.
If
you
want
to
use
this
tool,
you
got
to
translate
it
into
the
other
format.
B
I
think
we
have
the
power
of
the
in
this
group
and
then
in
the
other
group,
so
at
least
those
that
are
meeting
underneath
the
openness
and
stuff
Banner
right
in
terms
of
all
the
all
the
different
Frameworks
and
specs
and
everything
else
that's
coming
out
of
what
we
do
across
the
board.
I
think
we
have
the
power
to
unify
under
under
a
specific
format,
to
kind
of
prevent
a
lot
of
that
and
create
and
create
those
bridges
and
in
parallels
to
make
things
that
are
that
are
interoperable.
B
F
J
Right,
oh
yeah,
I
wanted
to
mention
on
tooling
and
verification,
I
think
it.
If,
if
you
have
multiple
ecosystems
and
then
you
have
multiple
Builders
I,
don't
think
we
can
expect
every
ecosystem
like
npm,
pipe
pipe
pip
and
everything
to
basically
be
aware
of
the
how
to
verify
provenance
from
different
builders,
because
at
the
end
of
the
day,
it's
not
just
in
total.
It's
also
how
you
do
key
rotation,
whether
you
use
dsse
or
not.
J
That
would
be
very
useful
because
what
we've
seen
with
the
salsa
verifier
is
that
just
doing
GCB
there
were
a
lot
of
corner
cases.
Sometimes
they
didn't
actually
follow
the
specs.
You
know
to
the
letter-
and
this
is
going
to
happen,
especially
when
people
try
to
push
products.
Sometimes
it's
not.
You
know.
C
A
Now
those
those
are
very
good
questions
that
Laurent
and
and
Michael
erased.
I
know
it's
just
thinking
out
loud
here:
I
think
it
can
become
very
quickly
a
maintenance
nightmare
right,
because
the
way
I
don't
know
gcp,
does
it
and
then
there's
Java
I
might
do
it
differently,
npm
I.
Do
it
differently?
A
Python
might
do
it
differently,
at
least
for
now,
until
everyone
until
the
dust
settled
and
everyone
agrees
and
what's
what
I
think,
but
maybe
the
least
we
can
do,
is
sort
of
provide
like
a
plugable
interface
and
say:
look
we'll
take
care
of
the
basics
like
checking
the
metadata
inside
the
provenance
themselves.
Give
us
what
looks
like
a
prominence.
We
can
verify
that
stuff
for
you
and
then
we
can
plug
in,
like
modular
things
for
how
to
verify
signatures.
And
then
someone
writes
like
a
dizzy,
concrete
class
or
whatnot
right.
Does
this
make
sense.
C
Yeah,
yes,
I
I,
think
that
that
that
100
makes
sense
and
kind
of
how
I
would
think
that
this
would
hopefully
sort
of
work
right,
because
I
think
there's
like
a
couple
of
things.
One
is
the
signature,
slash
envelope,
format
and
Then,
followed
by
like
the
internal
payload
and
verifying
the
payload,
and
for
what
it's
worth.
This
is
something
that
we've
had
to
implement
ourselves
in
guac,
where
we
would
much
rather
say
you
know,
just
you
know,
give
us
arbitrary
documents.
Oh,
this
is
a
dizzy.
C
Okay,
cool
unpack,
the
you
know,
unpack
the
payload
and
figure
out
what
payload
it
is
and
then
pass
it
like
and
and
as
opposed
to
us,
having
to
now
go
in
and
re-implement
ourselves
like.
What
does
an
internal
document
look
like?
Oh,
we
want
to
just
use
the
in
total
library
and
and
in
fact,
okay
great.
It's
an
intodo
document
great
now.
What
type
of
in
total
document
is
it?
Oh,
it's
a
salsa
document
pool
use
the
salsa.
C
You
know
call
out
to
the
salsa
thing,
but
we'd
you
know
we
don't
want
to
have
to
do
the
implementation
ourselves
to
say.
Okay,
look
for
these
fields
in
this
in
Toto
doc.
You
know
in
this
predicate
in
an
internal
document
and
if
it
matches
all
these
fields,
then
you
know
you
have
a
100
valid
salsa.
We
would
much
rather
say
cool
now,
pass
this
to
the
salsa.
J
Yeah
I
think
it'd
be
great
to
have
library
apis,
but
realistically
I
don't
think
this
is
going
to
work
at
least
not
at
the
beginning.
I
mean
I
see
what
happened
to
six
store.
It's
it's
already
taking
like
one
year
to
develop
a
six
store
in
each
ecosystem
and
I.
Think
it's
also
a
verification.
You
multiply
this
by
the
number
of
Builders
and
the
number
of
versions
of
each
Builder
and
then
it
just
explodes.
J
J
H
Sure
the
I
agree
with
trishank's
comment
in
the
chat,
I
think
right
now.
A
lot
of
the
complexity
is
because
the
trust
model,
including
but
not
limited
to
the
public
key
infrastructure,
is
not
standardized
and
so
there's
you
know
each
system
does
its
own
thing
and
so
any
sort
of
code
that
has
to
support
multiple
sources
has
to
have
like
all
these
special
cases.
H
H
We
will
want
to
develop
that
and
have
some
standard
mechanism
for
how
you
transmit
attestations.
What
the
roots
of
trust
are,
how
you
verify,
and
so
and
everyone
just
adopts
this
standard
interface,
and
so
that
way
it
simplifies
verification,
but,
and
it
would
be
great
to
work
on
it.
It
might
be
a
little
early
right
now
we
we
might
need
to
get
the
first
couple,
things
might
be
messy
and
then
once
we
see
what
kind
of
patterns
emerge,
then
that
might
make
sense
to
standardize
Michael.
C
Yeah
yeah
no
I
definitely
agree
with
you
on
that
and,
in
fact
actually
I
was
gonna
say
my
least
initial
thoughts
on
the
verifier
would
would
focus
a
little
bit
less
on
the
signature
piece
and
the
identity
piece
and
more
on
just
the
the
simpler
piece
of
assuming
somebody
is
giving.
You
know
an
86
salsa
predicate.
C
C
Another
thing,
I
think
that's
being
brought
up
in
the
in
Toto.
Space
is
a
concept
which
might
I
don't
know
if
it's
something
that
salsa
wants
to
get
involved
in
at
all.
But
it's
the
idea
of
like
a
predicate
dictionary,
which
is
this
idea
of
like
salsa,
would
be
a
predicate,
and
then
you
might
have
something
like
a
salsa
predicate,
like
people
would
potentially
have
mappings
into
internal
data
models
or
Twitter
ontology,
or
something
like
that,
which
would
then
help
with
some
of
the
the
mapping
back
and
forth
between
other
standards.
C
I
think
that's
a
significantly
longer
longer
tail
item,
but
something
that
I
know
some
folks
have
begun
to
kind
of
talk
about
like
so
that
somebody
can
say
great
I
have
all
this
salsa
data
and
something
like
oscow
great
here
is
a
mapping
of
salsa
Providence
data
into
a
combination
of
oscow
and
some
other
standard,
and
that's
still
somebody
else's
thing.
But
you
know
it
follows
a
common
mapping
pattern,
so
it
can
do
that.
K
Iron
and
just
one
thing
you
just
mentioned
as
well
around
you
know
keeping
it
really
simple
for
first
implementation
of
well
does
this.
Does
this
thing
that
was
produced
by
a
builder
or
tool
like?
Is
it
actually
the
format
and
is
it?
Is
it
what
we
expect
it
to
be?
Because
if
it's
broken,
then
a
computer
can't
even
process
it
right.
So
this
is
actually
going
to
help
the
tooling
and
Builder
platforms
and
such
with
development
and
essentially
QA
testing
right
at
the
lowest
level.
C
C
Something
like
that.
I
think
would
be
one,
but
there
is.
There
are
some
folks
who
are
starting
to
ask
like.
Could
we
use
stuff
like
what
we're
seeing
in
the
semantic
web
and
similar?
Can
we
use
that
or
similar
ideas
to
develop?
What
Santiago
from
in
Toto
is
calling
up
and
I?
Think
some
other
folks
are
calling
a
a?
What
do
they
call
it?
A
predicate
dictionary
where
the
idea
is
we
could
have
a
bunch
of
predicates
and
either
have
a
bunch
of
ways
to
map
those
predicates
to
other
systems.
C
So
you
could
say:
okay
great
to
map
from
salsa
to
Tool
X's
internal
data
model.
It
looks
like
this
and
so
that
you
know
tools
would
not
necessarily
need
to
recompile
every
single
time.
There's
a
new
predicate
they
could
just
take
that
predicate
and
just
be
able
to.
You
know
know
that
this
is
a
mapping
to
an
internal
data
model
and
then
also,
maybe
even
longer
term,
have
something
that's
more
akin
to
and
I
know.
This
is
a
big
ask,
so
I'm
not
saying
that
this
is
like
you
know
anywhere.
C
You
know
this
is
years
off,
but
something
like
salsa
to
ontology
ontology
to
a
data
model
so
that
you
could
just
have
here
is
the
supply
chain,
security,
ontology,
and
anybody
who
supports
that
mapping
salsa,
would
say:
okay,
well
hash
maps
to
check
some
in
the
ontology
or
something
like
that
cool.
And
then
you
have
a
two-way
mapping
and
it
simplifies
certain
things.
I
know
it
brings
up
a
lot
of
other
problems,
but
that's
one
of
the
things
that's
being
discussed.
C
A
C
I
think
it's
it's
similar,
but
not
the
same.
The
idea
behind
the
typing
one
is
more
of
just
like.
Could
you
have
sub
groupings
inside
of
an
object
so,
for
example,
with
salsa
right?
You
might
have
something
like
where
you
want
to
define
a
way
in
salsa
to
say
what
I'm
expecting
here
is
a
URI
right
in
this
build
type
I'm
expecting
a
URI,
and
how
do
you
sort
of
tell
the
end
user
in
a
Json
schema
like
that?
C
Actually,
this
type
should
be,
or
in
the
Json
schema
and
the
Q
schema
and
a
protobuf
or
whatever
that
this
should
be
considered
a
URI
without
needing
to
actually
write
a
bunch
of
code
that
you
know
for
every
single.
You
know
language.
It's
something
that
some
way
of
like
looking
at
a
schema
and
being
able
to
kind
of
figure
that
out
would
be
useful,
so
that,
like
folks,
can
know
that,
like
as
an
example,
you
might
be
able
to
say
this
is
a
subject
type.
C
A
C
This
any
further
but
yeah,
that's
just
some
stuff
that
some
folks
or
at
least,
are
interested
in
it
from
an
outcome
perspective
of
like
it
would
be
great
if
we
could
leverage
this
stuff
or
use.
Something
like
this
to
do
some
of
this
stuff,
so
that
folks
kind
of
get
that
better
interop
and
are
also
able
to
kind
of
say
great
I
can
just
if,
let's
say,
for
example,
a
lot
of
these
tools
that
come
in.
C
If
you
have
something
like
a
predicate
dictionary
and
as
long
as
it
follows
the
the
normal
predicate
dictionary
rules,
if
in
total,
if
if
salsa
generates,
when
salsa
2.0
comes
out,
if
a
tool,
if
the
total
predicate
dictionary
version
does
hasn't
increased,
then
great,
you
could
still
ingest
now
salsa
2.0,
you
might
not
have
as
deep
of
an
understanding.
You
might
be
missing
a
few
things
here
and
there,
but
you
can
still
get
value
out
of
it.
I
think
and
parse
it
anyway.
C
Yeah
as
somebody
who's
new
to
the
semantic
web
stuff
I
have
somebody
who's
really
really
new
to
it.
I've
been
reading
up
on
it
and
there's
so
much
stuff
that
I
do
not
understand,
just
mostly
just
from
I,
know
a
lot
of
it's
like
not
standard
sort
of
Json
formats.
It's
like
weird,
you
know
like
there's
a
lot
of,
but
it's
interesting
stuff,
just
to
be
clear.
It's
just
taking
a
while
to
rock
it.
Anybody
else
have
any
other
agenda
items
anything
else.
C
If
you
look
at
the
thing
here,
I
believe
so
our
next
meeting
is
December
15th
and
the
reason
is
to
we
don't
want
to
conflict
with
the
Christmas
holiday
that
a
lot
of
folks
on
this
call
celebrate
so
that'll
that'll,
be
on
the
15th
cool
and
if
there's
nothing
else
have
a
good
rest
of
your
day
and
some
of
you
all
see
Tamara
tooling.
So
you
all
see
later.