►
From YouTube: SLSA Specifications Meeting (April 3, 2023)
Description
Meeting notes: https://docs.google.com/document/d/1kMP62o3KI0IqjPRSNtUqADodBqpEL_wlL1PEOsl6u20/edit#heading=h.yfiy9b23vayj
A
C
D
It's
quite
late
here:
I'm
walking
out
of
India
I
am
not
switching
on
the
video
today,
but
next
time,
I'll
try
to
switch
on.
My
video
I
generally
have
conflicted
calls
at
this
time.
Hence
I'm
unable
to
drive
this
call.
I
am
a
security
architect
in
IBM,
working
on
record.
The
working
at
the
control
lead
for
voluntary
management
for
IBM
Cloud,
currently
focusing
on
bringing
together
all
this
sanitization,
but
I
was
quite
interested
in
working
with
this
community
as
well
to
see
what
other
it
is
happening
here.
E
B
G
A
Said
last
week,
I
think
I
said:
I
tagged
things
that
I
thought
were
blockers
for
V1
I
didn't
notice.
If
anyone
else
had
it
anymore,
but
we
have
the
following
issues
which
I
could
share
the
screen,
so
I
guess
before
we
get
into
that,
I
think
what
we,
assuming
that
we
still
want
to
cut
through
the
candidate
today,
which
speak
up.
A
A
A
A
A
We
have
an
issue
who
sets
expectations
for
which
there's
an
open,
pull
request,
I'd
like
to
get
that
resolved
and
merged
today,
although
I
feel
like
that
one,
we
might
want
to
continue
iterating
on
at
least
in
my
mind.
It
wasn't
super
obvious
that,
like
it
just
completely
resolved
the
issue,
there's
a
question
about,
should
we
add
a
new
salsa
level.
A
This
thing
from
Builder
ID,
my
feeling
is
I,
didn't
respond
on
the
thread
yet
that
no,
it
is
not
a
blocker
for
1.0,
and
so,
instead
of
introducing
a
new
thing
last
minute,
we
should
just
stick
with
what
we
have
and
then
iterate
it
on
in
the
in
the
future
version
which,
if
you
disagree
with
it
I'll,
maybe
I'll
take
just
the
for
Simplicity.
If
you
disagree
with
what
I'm
saying
either
speak
up
now
or
comment
on
the
thread,
but
otherwise,
well
that's
what
we
could
do.
A
A
H
I,
don't
disagree.
I
think
it's
useful
to
agree
like
what
changes
are.
Okay
during
a
review
period,
which
is
one
of
the
things
you
added
to
the
agenda
like
I
completely
agree
with.
All
of
your
summary,
like
verifying
out
of
that
is
a
useful
change.
The
provenance
change
seems
fine
to
me.
The
expectation
change
I
think
seems
reasonable
to
kind
of
continue
to
iterate
on
after
the
RC
personally.
I
think.
H
F
F
F
I
A
A
A
So
the
proposal
in
the
pull
request
was
to
have
two
different
terms:
expectations
and
verification
policy.
The
whether
or
not
this
is
the
actual
particular
change.
I.
Think
arno's
point
is
that
if
we
change
around
these
Concepts
now
that's
more
of
just
an
editorial
change,
but
rather
like
changing
what
the
specification
means,
and
so
we
be
ideally.
A
J
I
mean
it
seems
consistent
with
other
open
issues.
They've
got
closed
where
we're
just
using
words
that
are
overloaded
and
going
through
and
picking
new
words,
so
that
it's
more
precise,
so
that's
it's
kind
of
in
line
with
I,
don't
think
like
I
guess
we
have
to
do
a
quick
check
to
see
if
it
changes
anything
but
I,
don't
think
if
we
stuck
with
those
two
and
figured
out
which
one
it
was
in
context
that
that's
going
to
change
anything
about
the
spec.
A
A
J
I
mean
my
thought
is
that
we
can't
say
what
you're
going
to
do
with
your
verification,
and
so
it's
better
that
we're
saying
this
is
conformant
to
the
specification
and
then
you
can
do
additional
actions
based
on
that.
If
you
want
to,
but
we
shouldn't
be
dictating
what
people
are
doing,
we
should
just
be
dictating.
Does
this
comply.
K
Oh
yeah,
yeah,
I,
so
I
think
that
right,
like
there's,
there's
things
that
we
can
state
is
possible,
like
you
can
verify
like.
If
the
expectation
here
is
you're
you're
this
level
of
salsa
and
blah
blah
on
your
conformant,
then
you
should
be
able
to
verify
these
things
and
there's
probably
best
practices
that
we
can
suggest.
K
F
So
you
know
I
I
a
couple
of
this.
So
first
of
all,
I
think
you
know
it's
a
spec
and
we're
totally
entitled
to
say
to
be
compliant.
This
is
the
things
you
need
to
do,
and
but
the
thing
is,
we
have
different
types
of
people
who
are
going
to
try
to
you
know
be
compliant
with
conformant
with
the
spec
we've
said.
F
We
can
enforce
meconomic
features
to
have
seat
belts,
but
at
the
end
of
the
day,
if
the
drivers,
don't
the
users,
don't
put
the
seat
belt
on
so
going
to
do
much
good,
and
there
are
things
that
are
more
passive
like
airbag.
They
will
work,
no
matter
what
the
user
does,
and
so
salsa
does
some
of
this.
If
you
know,
but
but
to
get
the
full
benefit,
we
rely,
we
depend
on
the
consumer
to
do
certain
things,
and
this
is
what
this
section
does.
A
I
guess
a
challenge
I
I
have
is
that
If
This
Were
a
requirement
for
calling
something
a
build
level,
then
I
would
get
it
it's
like.
That
is
a
requirement
of
level
three
but
I.
Think
where
we've
gone
the
past
couple
weeks
or
month
or
whatever
is
splitting
that
out.
So
the
build
level
is
satisfied
if
you
just
generate
provenance
and
then
the
verification
of
that
is
a
kind
of
a
separate
thing,
but
we
don't
have
like
a
name
for
that.
Maybe
yes,.
F
J
I
think
so
that's
the
thing
as
a
verification
page
itself,
I
want
to
be
less
specific,
but
if
we're
referencing
verification
on
the
level
requirements,
I
think
we
can
then
say.
You
must
do
something
to
your
point
for
certain
levels
or
certain
pieces
we
can
say,
and
you
must
do
verification
of
X
or
of
all
the
things,
and
that
would
make
perfect
sense
to
me
dictating
that
on
the
levels.
J
D
A
A
We
call
them
guidelines
or
recommendations
and
use
avoid
saying
anything.
Anything
is
required
or
must
let's
say
like
you
should
do
this,
and
these
are
recommendations
which
would
avoid
the
problem
of
like.
If
you
don't
do
it,
then
are
you
social
compliance
or
not,
because
it
wasn't
a
requirement
in
the
first
place
and
but
would
still
give
us
the
opportunity
in
a
future
version
to
like
turn
that
into
a
give
it
a
name
and
add
requirements,
any
feelings,
positive
or
negative
about
that.
F
Well,
yes,
I
mean
basically
you're
you're
shrinking
further
the
scope
of
the
spec.
So
of
course
it
it
kind
of
removes
some
of
the
the
the
roadblocks
we
have
by
saying.
Okay,
let's
put
that
those
things
aside
and
it's
not
unreasonable
one.
So,
but
then,
basically,
what
you're
saying
is.
We
are
specifically
making
salsa
one
zero
about
build
systems
and
to
for
build
implementers.
I
Thank
you
I
agree
that
we
don't
address
the
consumer
side
in
the
sense
that
if
you
want
to
have
some
sense
of
security
from
every
package,
we
need
to
address
locally.
As
a
user,
the
transit
business,
you
need
to
address
the
source
track,
so
I
think
we
are
still
in
a
different
side
for
the
old
identification
part,
because
we
need
the
other
tracks,
I
think
to
give
something
really
useful
for
the
end
user,
I'm
not
sure
I'm,
very
clear
about
what
I'm
saying,
but
that's
my
feeling.
I
So
that's
why
I
would
keep
guidelines
for
now
and
I
agree
with
Mark
on
that
and
see
once
we
have
the
other
tracks
and
how
to
to
see
end
user
consumer
how
to
give
a
sense
of
security
when
you
use
something
and
defined,
and
it
will,
these
things
will
appear
by
themselves
when
we
develop
Tools
around
all
this,
probably
and
so
I
think
we
need
to
be
patient
on
that.
One.
K
So
trying
to
think
through
like
what
what
because
I
I
agree,
I
just
think
that
also
like,
when
I
think
purely
about
the
the
salsa
provenance
aspect
of
it
I've
always
thought
of
it.
I've
always
considered
it
purely
about
Providence.
It's
making
no
assertions
about
you
know
like
did
it
come
from
the
right
place,
just
that
this
is
the
place.
I
got
it
from
right.
The
build
system
is
making
this
claim.
Hey
I
got
it
from
this
place.
K
K
We
were
always
looking
at
it,
not
necessarily
as
a
way
to
sort
of
prove
that
necessarily
anything
was
good.
It
was
just
enough
information
that
when
you
were
verifying
like
for
audit
purposes
or
anything,
you
could
always
go
back
and
say:
hey
something
went
wrong.
Well,
let's
look
at
the
salsa
provenance
and
see.
Did
it
pull
from
the
right
place
and,
and
so
on
and
I
think
those
are
the
sorts
of
pieces
of
information
that
that
we
were
looking
at
when
we
were,
we
were
verifying
against
salsa
V
0.1
like
it
wasn't
necessarily.
K
H
A
Talking
about
on
the
verifying
artifacts
page,
it
would
be
to
I
mean
keep
the
same
content,
possibly
with
the
outstanding
pull
requests,
but
just
avoid.
The
word
must
basically
every
case
of
must
would
change
into
should
so
monitor?
Should
expectations
should
be
sufficient
Etc,
as
Nicholas
said
I
think
you
know,
maybe
we
would
turn
that
into
a
future
track
or
something
like
that
with
more
specificity.
One
thing,
I'll
note
is
that
right
now
we,
the
text
currently
says
the
phrase.
A
It
defines
a
salsa
conformant
system,
but
we
never
actually
say
I
think
what
that
is.
I
think
that
kind
of
introduces,
A,
New,
Concept
unintentionally
or
like
there's
kind
of
maybe
a
implicitly
some
sort
of
notion,
but
I,
don't
know
if
we've
ever
really
discussed
or
agreed
explicitly
about
what
that
means.
H
H
Making
a
significant
kind
of
reduction
in
scope,
we're
just
acknowledging
the
existing
scope,
but
because
we've
talked
a
lot
about
how
you
know:
there's
a
chicken
and
egg
problem,
and
they
you
need
build
system
to
be
producing
the
problems
metadata
before
you
can
have
a
good
feel
for
how
to
integrate
that
into
different
ecosystems
and
things
and
we've
been
trying
to
provide
incremental
like
tooling
and
things
and
we
haven't
got
as
far
with
the
verification.
Well,
that's
not
fair.
F
So
I,
you
know
again:
I
don't
disagree
with
the
the
general
proposal
of
you
know
shrinking
down
the
scope
to
just
build
systems
and
making
salsa
mostly
about
you,
know,
build
system
implementers
and
defining
what
it
means
to
be
conformant
to
salsa.
For
that.
From
that
point
of
view,
but
back
to
what
and
in
line
with
what
you
just
showed
the
Mark,
you
know
what
does
it
mean
for
a
system
in
general
to
be
such
a
compliant?
F
I
mean
you
can
imagine
I'm
I'm,
you
know
I'm
selling,
some
kind
of
device,
it's
a
piece
of
hardware
and
it's
got
to
you
know,
have
some
software
on
it
and
I
could
claim
compliance
with
salsa.
If
I
said
no,
no,
you
know
I
checked
the
very
I
verify
the
problems
of
all
the
software
that
actually
put
on
my
device
and
I
mean
never
have
developed
anything
myself,
but
I'm
on
the
receiving
end
of
software
and
I
make
sure
I'm.
F
F
No,
no,
this
is
independent.
I
was
just
trying
to.
You
know
clarify
what
that
meant
earlier
by.
You
know
trying
to
Define
what
it
means
for
to
to
have
some
kind
of,
and
maybe
you're
right.
It
should
have
a
name,
a
different
kind
of
track.
They,
you
know
to
say
what
it
means
to
be
salsa,
compliant
from
a
consumer
side,
point
of
view,
but
so
I
again
I
didn't
mean
to
you
know
and
and
when
I
said
bust
earlier,
you
know,
I
didn't
mean
to
get
into
the
detail.
There
may.
F
A
A
A
K
Yeah
I
mean
I
I,
just
think
when
I
think
of,
like
verification
rate,
it
immediately
makes
me
think
of
what
are
the
attacks
I'm
trying
to
prevent
like
what
like
when
looking
at
this
sort
of
thing,
what
is
the?
What
is
the
the
goal
of
me
to
try
and
figure
out
like
hey
I,
want
to
use
this
also
compliant
artifact
and
I
want
to
verify
certain
elements
of
it
in
order
for
me
to
achieve
some
goal,
I'm
not
just
doing
it
for
for
my
own
health
or
whatever.
K
So
when
I
think
about
like
once
again
some
of
these
things
you
know
and
and
like
I,
think
it's
worthwhile,
just
you
know
and
I
don't
know
if
anybody
has
these
other
use.
Cases,
like
my
use
case
was
always
like
I
can
show
you
that
if
something
went
wrong,
it's
probably
not
the
build
system
right.
That
was
kind
of
one
of
the
key
things
that
I
was
taking
as
a
takeaway
from
salsa
was.
Let
me
look
at
source.
Let
me
look
at
dependencies
because
those
might
have
been
an
issue,
but
the
build
system.
K
If
I
look
at
it
and
it
seems
to
have
listed
all
the
right
things
and
it's
also
compliant
then
I'm
pretty
sure
it
performed
those
actions.
And
let
me
look
at
the
dependencies
or
the
source
as
the
the
place
of
the
problem
and
I
think.
Maybe
just
kind
of
like
thinking
through
some
of
those
things
might
help
out
with
understanding
what
what
we
should
be
verifying.
C
I
guess
I'll
jump
in
here,
I
I,
think
Mark
I've
been
I've
been
listening.
A
little
bit
and
I
mean
I
think
the
goal
you
know
when,
when
I
used
to
do
this
back
back
in
the
day,
I
I
just
think
about
I
just
want
to
know
I,
don't
even
want
to
like
I,
don't
even
want
to
take
any
action.
I
just
want
to
know
what's
out
there,
what
do
we
have?
C
How
are
we
being
protective
or
what
is
what
is
like
just
exposed
so
I
think
if
we
go
with
that
mindset
like
you
know,
I'll
call
it
a
soft
governance
of
just
letting
people
know
letting
people
be
aware
and
then
just
releasing.
You
know
iterative
iteratively,
releasing
we're
not
going
to
get
it
right
the
first
time.
So
let's
just
go
ahead
and
move
forward
and
and
it
will
adjust
as
we
go.
C
I
I
mean
I'm,
just
we're
just
trying
to
educate
everybody
out
in
the
world
that
hey
guys,
are
you
just
aware?
Are
you
aware,
from
a
soft
governance
perspective
and
hey
guys
if
you're
not
aware
hey,
you
should
maybe
try
these
tools
that
we
recommend.
Well,
the
you
know
the
guac,
the
macaroons,
the
in
total,
the
blah
blah
blah
right
and
then
hey,
maybe
hey.
Here's
an
example
of
what
we
would
do.
C
I,
don't
know
I,
just
I
I've
seen
this
I've
seen
this
work
in
the
past
and
just
making
suggestions,
but
I
think
we
should
just
just
do
it.
Let's
just
deploy
out
there,
we
have
nothing
to
lose,
but
but
people
giving
us
comments
and
telling
us
no,
that
you
guys
are
wrong
or
you
guys
yeah,
you
guys
are
great.
You
guys
did
it
did
a
great
job.
E
So
I
I
thoroughly
enjoy
showing
up
to
meetings
like
this.
With
that
naive
understanding
and
asking
questions
from
from
a
novice,
Viewpoint
I
I'm
I'm
curious
how
the
specification
defining
the
social
levels
doesn't
make
the
verification
implicit
like.
Why
does
there
need
to
be
like
this,
like,
contrary
or
other
half
of
the
side,
for
the
the
way
in
which
the
levels
are
defined?
That
there's
any
like
any
ability
to
have
an
interpretation
of
whether
or
not
something
is
verified.
A
A
A
How
confident
are
we
that
it
actually
came
from
the
source
and
someone
wasn't
lying
to
us,
but
we
also
want
to
cover
things
like.
Did
it
come
from
the
expected
Source
repo
or
like?
Did
you
build
from
an
unofficial
Fork?
Did
you
have
local
modifications
in
your
git
client
and
you
built
from
that
and
not
the
actual
thing
that
was
checked
in,
and
everyone
had
code
reviewed
and
that's
not
currently
covered
by
the
build
level?
A
It
was
suggested
last
week,
I,
think
of
or
maybe
in
a
previous
meeting
at
least.
Maybe
that
should
just
be
a
future
source
track
like
cover
a
b
and
c
in
this
diagram
as
a
source
track
and
then
I
think
that
would
actually
make
it
a
lot
cleaner
and
then
maybe
it
would
really
become
more
obvious
of
like
verifying
is
more
straightforward,
but
right
now,
I
think
we're
in
the
situation
where
we
have
the
build
level
plus
some
other
things
to
do.
K
A
G
It
goes
back
to
the
old
problem.
What
is
provenance
provenance
in
the
opinion
of
some
people
is
that
this
is
what
happened.
This
is
a
builder
that's
built
from
this
source
code.
It
doesn't
say
that
the
source
is
good,
that
the
program
is
benign.
It
just
says
that
it
was
built
from
this
source
code
and
with
the
buildsystem.com
that
can
address
certain
threats,
and
so
that
means
that
it's
half
of
the
it
solves
half
of
the
problem.
The
other
half
is
what
should
have
been
built
from,
and
that's
not
what
the
provenance
says.
G
Something
else
says
should
be
built
from
a
particular
source.
So
we
we
have
these
two
halves.
It
would
be
nice
if
Providence
could
say
this
program
is
good,
but
provenance
cannot
say
that
it
can
only
say
I
built
a
piece
of
software
from
a
particular
source,
with
particular
dependency
instances
so
or
looks
like
with
verification
and
and
build
problems
were
still
not
certain
about
the
boundaries
between
the
two.
A
A
A
A
This
one
will
be
a
pull
request:
that'll
have
to
get
merged
to
and
then
a
pull
request
to
actually
do
the
thing
is
there
enough
time
in
the
day,
are
we
okay
having
folks,
whoever
you
know
most
probably
U.S,
based
folks,
I'm
guessing
because
most
people
in
Europe
or
Asia
are
going
to
be
asleep
just
doing
that
today,
I
mean
normally.
We
want
pull
requests
like
longer
time
to
comment.
B
A
F
F
K
Yeah
so
there's
two
separate
things:
one
is
the
release
candidate,
two
which
yeah
I,
think
I,
don't
know
if
we
have
anything
specifically
set
up
for
that
I'm
sure
we
could
probably
draft
something
up:
real,
quick
based
on
release
candidate,
one
just
picking
like
replace
with
the
release
candidate,
two
and
then
further.
We
have
we're
still
kind
of
working
on
the
1.0
stuff.
I
believe
that
there's
some
they
some
of
the
folks
from
the
open
ssf
side,
still
have
some
of
the
V
0.1
info.
K
A
A
B
A
A
A
A
F
F
But
so
I
mean
yeah
specifically
about
this
point.
I
think
it's!
You
know
it's
pretty
clear.
It's
it's
not!
Maybe
it's
easier
to
do
final
by
primer,
it's
easier
to
say
what
it's
not
right,
if
it's
not
editorial,
if
the
change
impacts,
the
compliance
of
an
implementation
right
so
I
have
an
implementation,
I
I,
implemented
against
the
draft,
and
now
I
need
to
go
change.
My
code
because
yeah
we
have
updated
the
spec,
then
that's
not
the
tutorial
formally.
That's
what
it's
about
now,
of
course.
F
Unless
you
know
it's
just
commas
and
typos,
there's
always
the
risk
that
it's
not
just
the
tutorial,
but
at
least
we
should
be
aware
when
we
make
changes
and
think
about
you
know,
do
we
expect
this
to
change
so,
for
instance,
if
you
think
there
are
cases
where
it's
very
simple
like
if
you
look
at
the
provenance
format,
if
you
change
the
name
of
an
ad
properly.
Well,
that's
it!
You
know
this
is
not
going
to
be
just
the
tutorial.
If
you
change
the
description
of
that
property,
then
you
know.
F
K
K
You
know,
I
think
that
there's
a
lot
of
useful
information
about
how
generally
folks
handle
it
and
yeah
it's
like
yep.
That's
why
there's
so
many
you
know
you
see
like
or
like
this
documents
you
see
like
rev,
5,
rev6
and
a
lot
of
times.
It's
it's
not
necessarily
even
just
like
any
real
content
changes.
K
It's
like
a
clarification
because
hey
a
clarification,
two
people
are
going
in
opposite
directions
and
even
the
clarification
is
like
well,
you
you're
now
saying
that
the
way
I
was
doing
it
originally
was
completely
invalid,
which
is
is
not
the
you
know,
expectation
and
so
yeah.
We
just
got
to
be
careful
and
and
I
do
think
that
you
know
there's
a
lot
of
useful
history
out
there
that
we
can.
You
know
look
to
follow
to
make
sure
that
that
we're
doing
it
the
right
way.
F
Yeah
things
are
interesting
and
I
mean
you
know,
I
think
it's
easier
in
some
cases
like
I
was
saying
for
formats
and
if
you
can
have
like
tests,
you
know
once
if
we
are
tests,
it's
easier
to
find
out
here.
The
Prime
with
salsa
is
some
of
it
is
not.
You
know
hard
coded,
and
it's
not
like.
There's
still,
you
know,
I
think
has
been
said
before.
F
F
K
Yeah
I
mean
it
can
wait
till
till
next
time.
I
think
one
of
the
things-
and
this
is
kind
of
more
of
a
post
1.0
thing,
one
of
the
things
that
folks
have
been
bringing
up
about
conformance
and
some
of
the
other
things.
Is
it's
great
that
that
we're
looking
at?
Like
you
know,
you
should
have
a
you
know,
a
document
somewhere
in
yayada,
but
some
folks
are
saying
like
how
can
I
distribute
that
information
in
sort
of
also
a
programmatic
and
automated
way
so
stuff
like
could
you
know?
Is
there?
K
Is
it
in
the
cards
to
have
something
like
a
salsa
conformance
attestation
that
could
have
as
this
like
you
know,
here
is
the
the
conformance
document
location
or
something
like
that
and
here's
a
bunch
of
other
information
so
that
folks,
who
are
are
coming
through?
You
know,
they're,
like
oh.
This
thing
claims
that
it
was
built
with
this
salsa
Builder
I.
Don't
necessarily
need
to
check
right
this.
K
Second,
that
that
it
is
in
fact
it's
also
conformant
and
have
somebody
review
the
document
but
I
when
I
pull
this
in
I
want
to
pull
down
that
attestation.
Was
it
signed
by
somebody,
I
trust
or
whatever
was
did
some
other
third
party,
that
I
do
trust,
certify
it
or
whatever?
And
then,
when
I
go
back,
you
know,
I
can
go
in
and
out
of
band
read
through
the
human
readable
documentation
and
and
go
through
that
sort
of
thing.
I
think
that's
just
you
know,
yeah
anyway,
Josh
UA.
H
We
spoke
about
it
if
I'm,
remembering
correctly
in
the
context
of
the
the
conformance
program,
which
is
a
post
1.0
activity,
so
I
I
expect
you
will
come
back
up
then
so
yeah
I
think
there's
some
something
we
likely
will
end
up
doing
effectively
and
just
figuring
out
how
to
distribute
those
and
how
they
fit
into
the
verification
cycle.
And
everything
is
something
we'll
need
to
figure
out.
H
H
F
You
know
so
I
I
was
going
to
say
so
in
the
conference
I
mean
you
know.
For
now
the
people
who've
been
working,
the
conformance
program,
the
looking
at
the
CNC
F1
and
the
cncf
as
basically
a
website
and
there's
a
there's,
a
repository.
This
is
how
the
register
their
claims
of
compliance
and
so
I
think
this
shouldn't
be
hard
to.
You
know
that
would
be
the
place
to
have
that
if
we
want
to
have
a
repository
of
attestations
of
claim
of
compliance
but
yeah.
F
F
So
I
guess
it's
all
right.
We
are
out
of
time
anyway,
so
we'll
close
on
this,
and
we
can
discuss
this
further
next
time.
When
we
talk
about
the
conference
program
in
more
details
for
those
who
are
interested,
there
is
a
spread,
and
there
are
a
couple
of
people
who've
been
working
on
it.
There's
a
draft
being
worked
on.