►
From YouTube: SLSA Biweekly (February 16, 2023)
Description
Meeting notes: https://docs.google.com/document/d/1cx3fOBfic6A0xc2on25ITK4vQHUdxgBmJoSS1LPqDJo/edit
A
A
C
A
A
All
right,
so
it's
almost
five
after
the
hour,
so
welcome
everybody,
the
pacing,
the
community,
the
notes
meeting
in
the
chat-
if
you
could
sign
in
if
you
haven't
already
and
a
reminder
that
we'll
follow
the
links,
Foundation
code
of
conduct,
we
could
start
by
welcoming
new
members.
Although
I
don't
think
we
have
any
new
members
that
I
see
unless
I'm
not
saying
in
the
participant
list,
we
could,
let's
get
into
the
special
interest
group
updates.
A
The
we
didn't
talk
about
at
the
specification
meeting
on
Monday,
but
I
think
we're
probably
pretty
close
to
doing
like
maybe
cutting
out
a
release
candidate
early
next
week,
maybe
Tuesday,
there's
a
U.S
holiday
on
Monday
I.
Think
the
the
fine.
The
major
final
concept
is
the
verification
piece
which
we've
spent
a
couple
weeks
on
kind
of
going
back
and
forth
and
I
I
feel
fairly
confident.
Now
that
we
have
a
decent
idea
of
how
to
handle
it.
A
A
Again,
we
didn't
go
through
all
this
in
the
specification
meeting
on
Monday
but
I.
Anyone
feel
free
to
disagree,
but
I
think
that's
where
we're
at
Mike
asked
about
having
like
a
another
form
of
a
distributable
as
like
a
PDF
or
something
like
that.
Yeah
I
think
that's,
that's
fine,
I
I
think
it
would
also
be
good.
A
F
Oh
yeah,
yeah
yeah,
no,
no
yeah
I
don't
want
to
derail
anything
from
given
how
close
we
are.
I
I
think
the
the
only
other
thing,
I
kind
of
noticed,
just
based
on
some
of
the
the
blockers
for
the
1.0
draft,
was
like
it
became
a
little
hard
to
sort
of
figure
out
like
which
of
these
is
just
like
hey.
This
is
actually
an
issue
with
how
we
are
showing
the
website
versus
here
is
an
actual
aspect.
F
A
H
Yep
yep
so
well.
First,
a
lot
of
good
stuff
has
been
coming
out
of
the
positioning
meetings
with
respect
to
the
upcoming
open,
Summit
and
a
lot
of
our
submissions
for
cfps
ETC.
So
we
got
a
lot
of
that
good
work
done
and,
and
mainly
we
have
a
panel
discussion
that
we
put
up
to
talk
about
salsa,
s2c2f
and
Fresca
combined.
It's
it's
the
ketchup,
mustard
and
relish.
H
That
was
the
death.
We
we
all
love
that
that
title
for
it
anyway,
but
but
we
worked
on
that
also
at
the
working
group
level.
As
far
as
positioning
is
concerned,
we
are
all
talking
about
an
agreeance
of
up
leveling
positioning
from
a
working
group
standpoint
to
include
salsa,
s2c2a
and
Fresca
to
talk
about.
You
know
how
all
three
of
them
are
positioned
across
the
entire
supply
chain.
H
C
H
H
Around
that
time
period,
I'm
I'm
I'm
not
terribly
sure
we're
still
waiting
on
a
cfp
for
open
ssf
day
too,
which
may
be
a
good
opportunity
to
talk
about
some
of
these
things
as
well,
so
that
should
be
coming
around
around
the
same
time
period,
And,
I,
believe
Mike,
just
just
just
put
up
on
put
up
a
link
there
with
some
timeline
type
stuff.
Okay,.
F
F
It
might
be
nice
to
have
sort
of
maintainer
tracks
for
things
that
are
sponsored
by
the
opennessf,
so
that
you
know,
because
there's
there's
certain
folks
who
want
to
obviously
give
talks
about
various
things,
but
they're
also
maintainers
of
projects
and
they're
like
oh,
which
do
I
do
do
I.
Do
it
as
a
maintainer
of
this
project
and
then
I
only
get
that
one
talk
or
do
I.
Do
it
for
this
other
topic
that
I
want
to
do,
because
you
know
I
want
to
do
this.
Other
topic,
David.
D
D
We
were
just
the
the
tech
we
wanted
to
make
sure
the
tech
reviewed
and
had
a
chance
to
comment
and
make
improvements
or
whatever
and
then
okay
there's
a
link
there,
and
then
you
know
the
the
intent
is
to
go
review,
a
bunch
of
proposals
and
pick
pick.
What
we
think
are
the
top
ones
and
be
very,
very
sad
about
all
the
ones
we
can't
take,
because
there's
only
so
much
time.
D
Let's
see
here
the
Linux
security
sum,
which
is
also
happening
that
week,
their
cfp
doesn't
end
until
March
1.,
so
we're
not
the
only
ones
who
have
a
who
have
a
cfp
not
completed
already
supply
chain
security.
Con
has
already
that's
already
passed
their
deadline,
but
but
we
want
to
be
the
only
ones
to
not
be
done
yet.
B
D
Okay,
we
have
been
talking
with
the
the
organizers
and
they
agree
that
they're
going
to
do
their
absolute
best
to
deconflict
them
you'll
notice.
They
didn't
promise
to
deconflict
them,
but
they
have
acknowledged
that
that's
going
to
be
an
issue
and
they
will
do
their
best.
The
way
supply
chain
security.
Con
works
is
really
it's
a
track
within
the
larger
conference.
So
you
know,
if
you
missed,
you
wouldn't
miss
the
whole
thing.
You
would
just
miss
the
talks
that
happen
to
overlap.
If
that's
what
they
end
up
doing,
but.
B
D
Yeah
yeah
how's
this.
We
are
aware
of
the
challenge.
That
does
not
mean
we
have
perfect
solution.
I
mean
the
the
this
is
the
fundamental
challenge:
I'm
trying
to
do
Lop
onto
an
existing
event.
We
had
talked
about
having
completely
separate
events,
but
that
was
hard
even
before.
Suddenly
people
started
having
travel
budget,
slashes
and
so
on,
so
I
I
think.
Given
the
circumstances,
this
is
probably
the
best
we
can
do
at
this
moment
in
time,
and
it
just
continues
to
be
untenable.
Then
we
can
do
something
else.
B
I
D
I
A
So
that
way
we
could
like
use
tags
and
kind
of
assemble
things
without
just
using
a
very
specific
version
of
Jekyll
and
like
copying
and
pasting
directories
for
versioning
and
as
part
of
that,
I
think
like
trishank
mentioned,
like
maybe
there's
a
plug-in
to
generate
a
PDF
or
something
like
that
or
like
a
zip
file
with
HTML
yeah.
That
sounds
good.
J
J
B
Cool
I
know
so
in
in
the
update
framework
spec
we
use
bike
shed,
which
is
a
markdown
preprocessor,
to
generate
specs
that
look
like
what
WG
and
w3c
specs,
but
I,
don't
know.
We
we
used
only
minimal
minimal
features
from
bike
shed,
so
I
don't
know
if
it
would
be
possible
to
use
that
with
the
way
the
sales
respect
is
is
managed
today,
but
what
we
definitely
need
to
avoid
is
like
any
more
duplication,
content
well,.
J
F
It's
also
like
the
various
generators
to
see
if
they
can
be
ready
to
sort
of
implement
draft
one
of
the
spec
ASAP
and
then
also
reaching
out
to
some
of
the
other
folks
for
some
of
the
other
projects
that
are
looking
at
Salsa
like
or
that
already
implements
salsa
like
tecton
and
hecton
chains
that
have
like
a
longer
release,
Cadence
on
what
that
might
look
like
on.
You
know
just
at
least
making
them
aware.
F
So
that's
one
of
the
big
things
and
we
kind
of
kind
of
want
to
keep
doing
that.
One
of
the
other
things
that
kind
of
got
brought
up
by
a
few
folks
in
in
there
was
also
the
desire
to
if
possible
and-
and
we
know
that
this
is
probably
a
big
ask
for
a
lot
of
folks-
is
if
the
community
can
sort
of
come
together
around
at
least
some
basic
nouns
and
verbs
for
an
API
for
Distributing
and
discovering
and
consuming
salsa.
F
You
know
or
following
a
similar
specification
for
ruby,
gems
and
and
npm,
and
so
on.
Then
folks,
who
are
building
the
tools
to
consume,
to
pull
down
salsa
attestations
would
not
need
to
kind
of
have
hey.
We
need
to
create
features
for
every
single
individual
thing,
they'd
be
able
to
just
say:
oh
yeah,
like
all
of
these
folks,
follow
this
API
spec
and-
and
we
can
just
kind
of
do
that
and
so
I
had
a
couple
of
conversations
with
a
few
folks,
I
believe
there's
also
something
with
the
I
think
it's
what's.
F
It
called
securing
software
repositories
working
group
where
I
had
one
conversation
with
them
on
their
APAC
meeting
and
I'll,
be
having
another
conversation
with
them
in
their
emea
meeting,
just
to
kind
of
like
highlight
that
sort
of
sort
of
problem.
Once
again,
it's
not
intended
to
be
like
the
cure-all
for
everything.
F
Obviously
different
folks
are
going
to
implement
things
different
ways,
but
even
if
we
can
get
some
consensus
from
some
of
the
big
package,
maintainer
package
ecosystem
maintainers,
that
would
be
really
nice
so
that
we
don't
have
to
you
know
like
the
salsa
verifier
would
not
have
to
implement.
You
know
30
different
API
implementation
or
sorry
Implement.
You
know
what
I
mean
anyway,
sorry
Dustin.
H
K
I
am
very
happy
to
share
that
with
anyone
that
wants
to
be
included
once
draft
is
up
and
yeah
I
will
also
take
that
by
the
work
group.
So
I
agree
like
I.
Don't
think
we'll
want
this
to
be
super
prescriptive
for
each
individual
ecosystem
they
might
want
to
like
tweak
it
or
adopt
it
to
suit
their
needs,
but
I
think
yeah,
a
high
level
General
like
this
is
how
you
do
it.
This
is
the
relationship
of
provenance
to
artifacts.
That
kind
of
thing
would
be
good,
so
yeah
experiment.
I
F
Only
thing
I
was
just
gonna
actually
remembered
is
so
I
know
that
the
npm
folks
actually
have
a
bunch
of
stuff
already
done
for
some
of
the
things
they
were
using
and
not
to
say
that
we
should
just
adopt.
You
know,
let's
say
what
they're
what
they're
doing
already,
but
but
I
think
they
seem
to
be
potentially
able
to
sort
of,
say,
hey
like
contribute.
F
What
they've
done
from
an
API
standpoint,
and
once
again
this
is
also
probably
even
goes
beyond
salsa,
but
mostly
obviously
focused
around
salsa,
but
like
s-bombs
and
similar
sorts
of
metadata
as
well,
but
just
wanted
to
kind
of
say
that
some
of
the
folks
from
npm
are
are
working
on
they're,
one
of
the
first
adopters
of
like
trying
to
do
this.
This
also
so
they've
been
doing
a
lot
of
work
in
that.
G
G
F
Oh
yeah,
no
I
was
just
going
to
say
just
to
add
on
to
some
of
the
stuff.
The
idea
from
what
Brendan
was
was
bringing
up
was
that
the
build
profile
and
spdx
you
can
refer
to
a
salsa
predicate.
So
it's
like
you
know.
Instead
of
you,
there
is
a
build
profile
like
if
you
don't
use
salsa,
you
could
still
Define
a
build
profile,
but
you
can
say:
hey
instead
of
defining
a
build
profile
in
spdx
format.
I
can
cite.
F
I
can
essentially
refer
to
a
salsa
provenance
document
and
say
that
is
my
build
profile.
I'm
using
that
as
my
build
profile,
and
then
some
folks
have
been
asking
for
the
other
way
around
right,
which
I
think
Melba
brought
up
is
like
hey.
When
we
have
all
these
materials,
could
you
do
something
like?
F
And
then
obviously
there's
you
know
and
I?
Don't
want
to
get
into
it,
but
there's
obviously,
then
the
a
little
bit
of
the
technical
challenge
of
making
sure
that
you
don't
have
circular
references
in
the
tools
that
you
know
that
keep
following,
but
but
that's
kind
of
a
separate
thing.
Yeah
tree
shock.
L
Yeah
thanks
thanks
for
raising
this
discussion,
Melba
I
mean
you.
You
turned
my
joke
into
a
very
productive
question,
so
yeah
this
is
actually
a
great
question.
Even
to
me,
it's
not
clear
how
salsa
and
S
bombs
would
relate
to
each
other.
I
think
you
might
find
sort
of
a
new
working
group
called
verifiable
as
bombs
on
the
cncs
lack
part
of
the
problem
that
they're
trying
to
solve.
L
There
is
to
to
figure
out
how
to
relate
s-bombs,
that
you
have
right
now
within
dodo,
attestations
that
we're
producing
with
salsa
so
I
think,
maybe
hopefully,
if
we're
lucky.
Some
of
these
questions
might
be
answered
there,
so
I'm
throwing
it
out
there
in
case
you're
interested.
Let
me
also
paste
the
link
here.
G
Yeah
thanks
so
yeah.
We
also
had
representation
from
in
tote
in
Toto
I
think
was
Sebastian.
That
was
on
the
call
right
and
we
we
basically
are
just
trying
to
use.
What's
there
right,
we
know
the
executive
order
for
folks
in
the
U.S
they're
going
to
be
required
to
provide
s-bombs,
and
we
know
that
we
have
separated
build
from
source
and
salsa,
and
so,
when
it
comes
to
provenance
in
terms
of
source,
the
s-bomb
is
going
to
be
key.
So
do
we
use
that
artifact
instead
of
trying
to
recreate
the
wheel?
G
Can
we
reference
that
artifact?
We
might
need
other
data,
but
at
the
very
least,
let's
use
what
people
are
already
trying
to
do
so
that
way
it
reduces
their
overhead
and
Cyclone.
Dx
is
very
willing
to
partner
with
us
and
then
I
know.
Brandon
said
that
you
know
he's
all
for
it
right,
and
so
we
just
need
to
make
sure
that
we
continue
those
conversations
instead
of
trying
to
overlap
without
communication,
because
I
think
that's
what's
happening
right
now.
G
G
G
If
it
was
a
spec
group
or
if
it
was
a
supply
chain
integrity,
so
we
were
trying
to
figure
out
what
did
we
want
to
do
in
2023?
And
obviously
it's
also
1.0
spec
right
we're
trying
to
aim
for
we're
trying
to
aim
for
it.
This
quarter
right,
I'm,
just
using
quarters
because
it's
easier
than
trying
to
figure
out
March
or
whatever,
and
then
this
Providence
specification
I
think
we're
trying
to
aim
for
first
quarter
as
well
based
off
of
the
the
draft
that
I've
seen.
G
G
What
about
the
source
discussion
right?
We've
tabled
that
for
some
time
do
we
think
we
will
have
a
source
discussion
and
specification
at
least
a
draft
by
the
end
of
the
year
right.
What
about
the
tooling
right?
How
do
you
verify
that
something
is
salsa?
How
do
you
provide
guidance
on
producing
something
that
is
also
compliant
and
then
there's
some
other
things
so
I'd
be
very
interested
in
feedback
from
the
community?
G
A
Yeah
I,
it's
a
topic
about
the
s-bomb
too,
but
regarding
the
road
map
I
think
that's
great.
We
had
the
one
like
the
road
map
from
the
middle
of
last
year.
Maybe
it
would
be
good.
You
know
thanks
Joshua,
for
the
link
I
think
it
would
be
good
to
have
a
similar
update
in
the
proposals
repo
it
might
what
we
did
with
that.
A
One
was
start
with
Google
doc,
because
it's
just
much
easier
to
collaboratively
edit
into
Google
doc,
and
then
you
know,
convert
it
to
to
markdown
for
posterity
and
for
ease
of
reading.
So
I
think
this
is
I
think
this
is
great.
Thank
you
for
starting
this
I.
Don't
have
any
comments
on
I
mean
what
you
said
sounds
good
I,
don't
have
any
content-wise
suggestions.
A
G
E
C
G
I
I
C
C
M
I
G
M
G
Then
what's
the
point,
but
given
the
discussion
we
had
about
domains
right,
do
we
even
want
to
go
there
or
do
we
try
to
point
to
something
else?
That's
already
doing
that
and
leverage
that,
but
I
do
think
it's
a
good
idea
to
have
something
defined
in
terms
of
vulnerability
scanning
and
making
sure
you
are
producing
secure
software,
but
I
I,
don't
know
if
we
want
to
take
that
on
in
2023.
I
A
A
A
useful
signal
that
way
other
people
who
are
thinking
about
that
too
can
say
it.
If
people
want
to
raise
the
priority,
then
say:
oh
no,
we
need
it
now.
We
really
need
to
use
it
that
we
could
talk
about
raising
the
priority
Etc
I
I
did
do
other
folks
have
a
comment
on
the
road
map.
I,
don't
want
to
keep
jumping
topics,
yeah.
B
Mine
was
I
I,
it
kind
of
Builds
on
what
you
were
just
saying
is
Omak
I
I'd
love
for
us
to
have
like
a
relatively
small
set
of
things
that
we
are
committing
to
within
a
certain
time
frame
and
then
a
longer
list
of
things
we
care
about
and
want
to
like
start
building
towards,
but
like
1.0,
was
a
a
big
lift
and
we've
missed
all
of
our
self-imposed
deadlines.
So
I
want
to
try
and
avoid
setting
a
bunch,
more
deadlines
that
we're
going
to
miss.
F
Yeah
and
I
think
the
same
thing
also
goes
for,
like
we
I
don't
want
to
inflate
the
two
conversations,
but
there's
also
like
the
scoping
conversation
just
generally
of
like
Hey.
How
are
there
certain
things
that
we
just
don't
want
on
the
roadmap
that,
because
we
just
don't
want
to
dive
into
that
scope
or
also
if
it
is
something
we
might
want
to
dive
into?
F
Does
it
make
more
sense
to
say?
Hey
we
want
to
you
know,
provide
guidance
to
refer
people
to
other
things,
but
not
ourselves.
Take
on
that
work,
so
I'm,
just
a
you
know,
there's
a
lot
of
different
open
ssf
groups,
cncf
groups
Etc
that
have
stuff
around
like
scanning
and
some
of
those
other
things,
and
instead
of
us
kind
of
coming
up
with
our
own
set
of
rules,
maybe
just
sort
of
saying
hey
for
when
it
comes
to
scanning.
F
B
I
think
that
comes
back
a
bit
to
what
Mark
was
saying
where
we
can
kind
of
draft
something
start
to
generate
consensus
among
the
group
and
then
it's
only
officially
the
plan
of
record
when
it
hits
the
salsa
proposals
repository
as
a
markdown
document,
and
then
you
know
we
can.
We
can
do
some
of
this
connecting
to
other
efforts
during
that
initial,
like
drafting
review,
iteration
phase.
A
You
know
referring
to
other
projects,
I
I
think
like
hopefully
with
the
1.0
release.
What
I'm
hoping
for
is
that
we,
this
notion
of
separate
tracks,
allows
us
to
work
on
stuff
in
parallel,
and
if
we
did
a
good
job
for
1.0,
we
can
make
the
tracks
relatively
independent,
and
so,
if
there's
a
group
of
folks
with
an
openness
for
otherwise
who
are
working
on,
say
vulnerability
stuff,
we
could
have
it
folded.
You
know,
have
a
vulnerability
track.
A
I
H
Yeah,
so
a
couple
of
items:
David
has
a
Davis
asked
a
couple
of
questions
and
a
few
other
Sig
meetings
regarding
making
sure-
and
this
is
only
speaking
to
the
build
track
and
then
the
source
track
and
we're
going
to
be
discussing
the
source
track
and
then
we're
also
going
to
comment
on
the
vulnerability
track
as
well.
There
is
a
lot
of
stuff
that
we're
doing
right.
H
We
had
we
talked
about
s-bombs,
but
then
we
also
have
vdr
documents
and
Vex
documents
right
and
you
know
vdr
and
Vex
documents
they
they
do.
They
run
along
the
same
line,
but
do
a
couple
of
different
things
and
we're
talking
about
the
vulnerability
track.
I
I
mean
I
I.
We
talk
about
vulnerabilities
in
the
supply
chain
and
in
general,
are
we
talking
about
vulnerabilities
based
on
what
gets
produced
from
the
build,
but
you
have
two
documents
there
that
can
help
with
that
already.
H
D
D
I'm
expecting
things
to
documents
to
have
some
differences.
You
Know
cover
different
areas,
because
otherwise,
why
I
have
to
it's?
It's
the
conflicts
that
that
concerned
me
so
I,
don't
know
of
any
conflicts
on
offhand.
I
just
want
there
to
be
several
people
to
put
eyes
on
it
to
make
sure
in
particular
that
salsa
and
s2c
do
have
either
don't
have
conflicts,
or
if
they
do
that,
we
we
understand
why
they
are
my
suspicion.
Is
that
there's
a
conflict?
G
B
Yeah
not
really
directly
related
to
what
Jay
and
David
were
talking
about,
but
I
was
just
wondering
if
we
might
want
to
try
and
as
an
early
roadmap
item
post,
1.0,
try
and
capture
some
guidelines
for
how
to
define
a
track
like
the
principles
are
a
really
good
start
for
what
we're
trying
to
achieve
with
salsa.
But
if
we
want
this
to
be
easily
paralyzable
and
for
others
to
be
able
to
present
potential
tracks
for
inclusion,
almost
as
like
complete
draft
documents
than
having
having
some
guidelines
around.
I
I
G
One
thing
in
terms
of
the
conflict
and
making
sure
we're
in
sync
I
think
I
didn't
get
an
official
response
from
Mike.
Yet
so
I'll
wait
for
that
response.
But
if
we
do
become
upper
level
positioning
group,
so
it's
not
just
salsa
it's
supply
chain,
Integrity
as
a
whole,
then
we
can
make
sure
that
that's
discussed
there
right,
making
sure
that
we
don't
have
too
much
conflict,
making
sure
that
domains
are
properly
defined
and
that
we
can
map
to
each
other,
etc,
etc.
B
A
The
the
big
thing
was
this
idea
that,
right
now
in
the
salsa
Providence
there's
this
resolved
dependencies
field
and
the
idea,
if
I
understood
correctly,
was
effectively
to
either
replace
in
some
form,
replace
that,
with
in
reference
to
an
s-bomb,
either
like
inline
parts
of
the
s-bomb
or
use
the
same
schema
or
you
refer
to
the
s-bomb
or
you
have
multiple
attestations
or
something
I
think
in
general,
something
to
reduce
duplication
between
the
Providence
and
aspan,
because
it's
the
list
of
dependencies.
That
is
the
overlap.
A
A
F
My
vote
is
to
not
do
it
or
1.0
right
now,
unless
it's
just
something
that
is
super
simple
to
sort
out
just
because
I
think
My
worry
is
if
the
spdx
and
Cyclone
DX
folks
start.
You
know,
just
as
an
example
come
in
with
with
suggestions
or
whatever
it's
going
to
push
back
a
lot
of
the
other
stuff
for
a
really
long
time.
F
G
I
would
I
would
agree
with
that
right,
I,
don't
think
we
want
to
and
I
think
we
mentioned
this
during
that
call.
We
don't
want
to
be
bound
by
their
timelines
right,
but
we
do
want
to
keep
the
communication
lines
open,
but
I
also
think
we
need
to
have
a
story
to
tell
when
people
start
asking
right,
because
people
will
start
asking
and
they
have
already
started
asking
in
IBM.
G
A
Yeah
one
one
thing:
I
agree
on
the
timelines:
I
guess
what
I
was
thinking.
The
only
thing
that
would
be
actually
practical
would
be
to
look
at
if
we
take
existing
examples
of
provenance
in
a
1.0
format
and
use
an
existing
format
like
spdx
2.3
I
think
is
the
latest
version
or
Cyclone
DX
whatever?
Is
it
I?
A
Don't
remember
the
current
number,
whatever
the
current
latest
table
and
just
try
literally
taking
the
same
data
we
have
now
and
just
putting
it
in
that
other
format
and
see
what
it
looks
like
I
have
some
concerns
around
complexity.
There
of,
like
you,
used
to
be
able.
You
know
if
you
were
in
a
use
case
where,
like
the
one
salsa
predicate
solved
your
whole
use
case
now
you
have
to
understand
these
two
different
things
and
that
kind
of
sucks,
but
at
least
kind
of
looking
at
that.
F
Yeah
one
other
thing
or
two
other
things
to
add,
is
yeah
I,
think
some
of
it
is
Gonna
Come
Out
organically,
from
some
of
the
tools
as
well.
Some
of
the
tools
already
like.
Once
again,
we
have
two
s-bomb
formats
right
and
they
have
differing
use
cases
depending
on
who
you
talk
to
and
and
exactly
what
the
scope
of
them
is
and
I
also
want
us
to
to
to
not
maybe
not
get
too
hung
up
on
hey.
F
Why
can't
we
just
use
this
other
thing
for
for
that
as
well,
because
I
think
that
you
know
when
the
use
cases
are
really
overlapping,
I,
I,
agree
and
I
think
that
there
are
definitely
some
places
where,
where
we
want
to
be
cognizant
of
that,
but
I
think
throughout
you
know
throughout
history
right,
you
have
folks
being
like.
Why
can't
we
just
use
this
the
the
data
that
the
output
of
this
SCA
scan?
Why
can't
I
just
use
this
like
Json?
F
That's
the
output
of
this
other
thing,
just
as
my
s-bomb
or
whatever,
and
so
I
do
think.
Yeah
sorry
I,
don't
know
hate
against
the
sled,
but
I
think
that
there
are
a
lot
of
differing
formats
and
differing
tools
and
a
lot
of
folks.
You
know
because
once
again,
there's
there's
also
formats
that
I
believe,
like
medical
devices
have
been
using
for
a
really
long
time
and
you
know
hey.
Why
are
we
not
using
that?
J
So
if
I
may,
interject
I
mean
I
I
agree
with
you,
but
I
think
you
know
back
to
what
Melba
was
saying.
What's
important
is
to
be
able
to
answer
the
questions
that
are
likely
to
pop
up
right,
so
I
think
if
we
can
just
agree
Among
Us
that
yeah
this
is
an
area
we
recognize
the
overlap
and
we
are
investigating
ways
to
you
know
possibly
link
the
two
rather
than
duplicate
the
information.
I.
Think
that's
a
reasonable
answer
and
position
to
have,
and
that
you
know
in
the
immediate
needs.
A
J
Yeah
I
think
you
know,
realistically
speaking,
if
we
want
to
get
one
zero
done,
you
can
just
keep
adding
new
features
that
are
not
even
you
know,
really
figured
out
yet
so,
just
from
practical
point
of
view,
I
think
you
know
this
is
I,
mean
I,
think
it
would
be
great
to
do
the
exercise.
You
were
talking
about
to
try
to
investigate
what
it
might
look
like
and
you
know
so
that
maybe
at
least
we
don't
close
the
door
or
we
maybe
with
an
idea
on
how
we
would
accommodate
this.
G
G
D
Yeah
so
I'm
totally
sympathetic
to
arno's
comment
that
if
you
want
to
get
a
one
out
done
ever
eventually
have
to
say
please
stop
I
I,
think
the
one
the
the
one
thing
that
I'm
I'm
thinking
through
in
my
apologies,
I,
don't
have
a
solution
here.
Just
is
just
trying
to
make
sure
that
we
don't
cut
off
a
door,
in
other
words,
I.
Don't
it's
perfectly
reasonable
to
say
you
know
we
can't
solve
everything.
D
B
A
Yeah
and
I
think
the
with
the
1.0
format,
I
I
could
actually
with
the
V1
format,
I
I
think
it
could
be
a
non-breaking
change
that,
like
you,
know,
right
now,
you
could
list
result
dependencies
inline.
We
could
probably
have
an
optional
field
that
you
know
as
a
reference,
and
it
doesn't
really
it
would
be
equivalent.
You
know,
if
you
don't
parse
it,
then
it's
equivalent
to
just
not
having
it
there.
Anyway,
it's
not
a
required
field.
A
It
also
seems
possible
that
we
have.
You
could
either
stick
the
s-bomb
in
the
subject
or
stick
it
in.
We
now
have
a
byproducts
field
and
current
draft
right
now,
there's
no
convention
for
how
you
reference
that
and
how,
like
you,
would
know
that
this
thing
is
an
s-bomb
versus
something
else,
but
maybe
that
could
be
an
addition
as
well.
D
Yeah,
if
I
can
quickly
respond
back
I,
you
know
the
reality
is
we're
working
on
an
s-bomb
1.0,
but
I'm
wondering
if
maybe
this
is
just
a
revisit
of
including
a
version
ID
somewhere.
You
know
under
the
theory
that
there
will
be
a
2.0
eventually
with
potential
changes
that
might
be
very
good
for
recipients
to
know.
Are
we
talking?
Yes?
Are
we
talking
salsa,
100
or
2-0
and
and
I
think?
That's
actually
all
you
need,
because
if
you
can
identify?
Oh
this
is
the
newer
version.
Then
you
can
tell
the
well.