►
From YouTube: IETF-SCITT-20230313-1600
Description
SCITT meeting session at IETF
2023/03/13 1600
https://datatracker.ietf.org/meeting//proceedings/
B
B
Cool
could
I
ask
a
favor
just
in
the
first
couple
of
minutes,
while
people
are
coming
along,
hannes,
it
probably
will
be
along
later,
but
certainly
not
for
the
beginning
of
the
call
so
I'm
leading
and
taking
notes
today
and
someone
just
checked
the
Hedge
Dock
and
see
if
you
can
see
heading
meeting
minutes
for
2023.0313,
because
I
have
a
feeling.
It's
put
me
in
some
kind
of
private
note.
C
B
B
So
I
believe
the
free
after
so
I
guess
we
can.
We
can
start
to
get
going.
I
believe.
The
only
thing
that
we're
looking
at
is
the
continuing
large
update
to
the
architecture
document,
so
I
will
in
a
second
pass
over
to
Hank
and
Steve,
for
that
does
anyone
else
have
any
other
agenda
hacking
to
do
quickly
before
we
get
going.
A
A
So
there's
a
bunch
of
issues,
capturing
and
then
I
think
it
was
Friday.
I
tried
a
triage.
What
I
thought
we
needed
to
land
for
today
versus
what
we
would
do
later
so
I
did
a
bit
of
a
triaging
process
in
the
issues
and
either
was
set
to
116,
which
the
deadline,
one
of
the
deadlines
is
today
or
it
was
set
to
117
and
117
was
more
of
a
bucket
that
it
was
triaged.
So
if
nothing's
assigned
to
a
release
a
milestone,
then
it
hasn't
been
reviewed.
Yet
was
the
thought
process.
A
The
the
doctor
get
merged.
We
got
a
lot
of
the
updates
in
there
because
they
were
all
piecemeal.
There
is
a
little
bit
of
species
that
we
were
trying
to
clean
up
over
the
weekend
and
we
didn't
actually
note
down
some
of
the
decisions
we
made
in
the
open
issues,
so
that
added
a
little
more
confusion,
at
least
to
me,
because
I
was
trying
to.
A
D
Okay,
thank
you
Steve
hi.
This
is
Hank
yeah,
okay
architecture,
internet
draft
for
skit.
There
was
a
task
to
consolidate
the
terms,
claims
and
statement
and
assertion
and
how
to
deal
with
that.
There
was
a
outside
force,
an
outside
pool
of
inputs.
There
were
people
really
really
drenched
into
the
depths
of
how
this
should
look
like
like
the
hardcore
for
more
formal
people.
D
The
current
PR
that
was
merged
actually
I
think
represents
consensus
of
both
sides.
So
there
was
enough
a
lot
of
contentious
discussion.
I
think
I
want
to
highlight,
because
I'm
not
sure
if
every
stakeholders
here
that
there's
a
strong
for
the
strong
notion
on
separating
the
formal
term
of
signing
something
of
the
from
the
formal
term
of
using
cozy
to
signing
something,
because
when
you
sign
something,
that's
cozy,
you
separate
every
matter
that
are
into
two
buckets.
D
One
of
them
is
a
bucket
that
goes
into
the
signature
and
one
of
the
bucket
bucket
is
that
does
not
go
into
the
signature
and
there
was
I
think
I
think
formally
and
for
everybody
globally.
The
most
contentious
thing
for
for
some
people
from
the
ITF
coming
from
Jose
and
Jose.
This
is
all
of
this
like
obvious
right,
but
but
from
the
outside.
D
So
that's
my
summary
for
the
architecture
on
the
vast
overhaul
remaining
terminology
issues.
Are
there,
of
course,
there's
a
vastly
inconsistent
use
of
log
and
a
ledger
and
and
and
other
forms
of
phrasing,
the
the
the
the
repository
the
retention
system
and
and
I
want
to
highlight
and
spoil
here
first
that
I
think
that
somehow
Lost
in
Translation
between
the
two
meetings
after
meetings
was
that
we
are
basically
going
the
most
agnostic
term
that
the
append-only
ledger.
D
So
if
you
have
a
I,
don't
know
sqlite
file
in
your
tee
and
you
can
guarantee
that
that
is
handled
as
a
append.
Only
mechanism
you're
good.
The
thing
is
append
only
and
you're.
Never
removing
something
you're
only
add
in
something
you
want
to
remove
something
you're
amending
it
with
another
statement.
I
think
that's
the
current
understanding
here.
That
is
the
terminology
issue
not
resolved
in
the
current
VR.
There
is
still
a
little
bit
all
over
the
place
in
the
current
text
and
as
please
stay
tuned
that
we
fixed
up.
D
So
if
you
have
a
problem
with
the
append
only
structure,
in
this
case
log,
please
say
so
on
here
on
the
list
and
and
and
and
and
argue
why
this
is
bad,
but
I
think
that
that's
the
that's
a
common
denominator.
Everybody
agrees
on,
but
this
is
open
items
so
I
know
also
referring
to
things
solved
and
things
open,
I
think
that's
the
gist
of.
E
Yeah
I
mean
I,
think
thanks
to
Henke,
Consolidated
or
summarized
very
well,
so,
regarding
I
just
wanted
to
clarify
Hank,
you
saying
append
Only
log
right
because
way
back
in
October
before
the
idea
from
I
we
agreed,
we
agreed
that
we
will
remove
Ledger
and
because
it's
more
takes
it
towards
blockchain
and
very
implementation.
Specific
term
would
use
append
only
logs.
So
if
that
is
what
you
meant,
the
and
I'm
I'm
happy
with
it,
and
if
anybody.
F
D
So
before
the
objections
can
be
raised,
I
want
to
highlight.
Yes:
registry
has
the
drawback
of
iitf
connotation
because
of
we
don't
want
to
really
delve
into
a
yeah
and
a
territory
here
and
reuse,
the
term
registry
yeah
and
a
ledger.
Yes,
that
somehow
also
is
a
term
burned.
I
I
know
that
sometimes
ontologies
are
sold
via
the
using
the
term.
Json
ID
obvious
catering
is
a
termite
ontology,
while
you're
still
using
them.
So
we
are
not
trying
to
do
that
here.
I
think,
obfuscating
terms,
the
new
terms
is
bad.
D
I
think
they're
not
useful
here,
so
avoiding
it
for
now
and
then
elaborating
on
and
in
future
text
is
better
and
that's
yeah
Registries,
probably
out
they're,
just
probably
out,
which
basically
leaves
log
and
I
think
everybody
can
agree
on
that,
and
that
that's
my
my
point
of
view,
but
we
are
not
doing
anything
any
changes
right
now
of
this.
First
of
our
opinion,
please
speak
out.
A
So,
just
to,
and
so
regarding,
the
terminology,
I,
Ledger
or
log
I
think
either
is
fine,
I
opinions
either
way.
My
opinion
is,
let's
get
pick
one
and
move
forward,
so
append
Only
log
makes
sense.
The
question
I
have,
though,
is
skit
skit
transparency,
service
or
registry
I.
If
we're
talking
about
an
instance
of
this
thing,
is
it
a?
Is
it
a
transparency
service.
D
That's
another.
That's
a
point
item
three.
You
have,
of
course,
the
service
that
provides
apis
that
that's
very
intuitive,
an
API
and
I.
Think
that's
race.
Comments
has
an
as
a
customer
phase
inside
and
an
internal
facing
side
and
I.
Think
people
who
read
from
it
are
put
some
things
to
it:
yeah
it
might
be
different
and
I.
Think
Ray
made
a
good,
a
very
good
point
about
that.
So
that's
that's
future
work
also
flash
that
out.
D
D
What
I
want
to
say
today
it's
concept
that
really
really
resonates
with
everybody,
I
think
who
who
tries
to
understand
what
we're
doing
as
notarization
of
the
notary
that
doesn't
understand
the
content
that
just
you
know,
notarizes
all
the
parties
in
the
room
and
that
it
was
said
and
that
you
know
assertion,
and
so
so
I
think
that
has
to
go
in
there
and
has
to
be
a
part
of
transparency
service.
So
my
current
way
of
thought
from
my
individual
point
of
view,
is
Lord.
D
Yes,
because
that's
that's,
where
you
cryptographically
do
things
and
then
functionalize
wise
notarization,
who,
which
part
is
on
wall,
what
is
going
to
to
that
cryptographic
function.
These
are
two
parts
of
the
transparency
service,
but
I'm
I'm
a
little
bit
going
into
the
guessing
realm
here,
but
I
think
that
that
looks
pretty
feasible
to
me.
Yeah.
A
So
I
I
hear
you
and
I
I
agree
with
the
concepts
because
remember,
there's
the
there's
an
instance
of
this
thing.
If
somebody
refers
to
somebody
running
one,
what
do
we
want
to
call
it
and
so
I
I
struggle
with
the
term
transparency
service,
because
we've
got
ourselves
caught
up
in
some
things
are
opaque.
Some
things
are
transparent,
I'd,
be
perfectly
fine
to
call
it
a
transparency
service
for
now
just
so
that
Doc
is
consistent.
A
If
we
can
have
the
document
be
consistent
from
begin
to
end,
then
at
least
we
know
that
we
can
do
a
search
and
replace
for
a
single
term.
Should
we
choose
to
do
that,
but
right
now
we're
using
so
many
synonyms
that
it
does
get
confusing
so
I,
just
so
I
think
we've,
the
ones
we
I
know.
We've
solved
is
statement,
sign,
statement,
transparent
statement,
that's
good.
Yes,
the
other
one
is
log
over
Ledger,
which
is
the
thing
that
we're
writing
to
which
is
a
sub
component
of
the
overall
system.
A
D
A
C
B
B
G
B
B
There
are
always
abstractions
and
Shades
of
Gray
in
what
we're
doing
you
know
all
the
identities
strong
enough.
Well,
it
depends
how
how
hard
you
look
and
how
hard
people
are
trying
to
hack
you
but
yeah.
We
have
to
draw
the
line
somewhere.
So
I
think
that
the
consistency
is
super
duper
important,
Exquisite,
linguistic
correctness,
I
think
is
going
to
fail
us
because
the
English
language
isn't
very
good
at
the
kinds
of
abstractions
that
skit
is
dealing
with
so
yeah.
B
A
D
G
D
Other
shown,
for
example,
there's
a
receipt
ID,
it's
good,
and
we
realized
that
the
skits
received
ID
basically
represents
a
global
concept
of
how
to
phrase
Merkel
tree
proves,
and
maybe
the
ordered
paths
in
cozy.
So
that's
a
thing
we
will
issue
today
and
we
decided
not
to
the
editors
and
authors
of
the
architecture
decided
not
to
in
last
minute
change
the
reference
from
received
to
This
Global,
cozy
Merkel
tree
thing
that
has
not
even
accepted
by
cozy,
yet
right
so
so
we
are
parallel.
D
We
split
them
out
in
parallel,
so
in
this
iitf116
you
will
encounter
both
up-to-date
received
ID
for
providing
metadata
with
counter
signing
proves
that
something
has
to
be
added
to
a
ledger
next
to
a
cozy
IDE.
That
explains
how
to,
in
general
phrase,
if
you
use
some
kind
and
there's
a
register
there
of
hash
tree
and
cozy
how
to
use
that.
D
So
we
are
splitting
more
generic
items
off
screen
sketch
into
other
working
groups,
whether
it's
a
process
and
therefore,
at
the
moment
and
especially
in
116,
you
will
encounter
both
the
remaining
specific
document
and
sketch
and
also
Co
encounter.
The
more
generic
item
in
cozy.
I
want
to
really
highlight
that.
There's
no
discrepancy
here,
but
we
have
to
wait
for
a
response
from
cozy
and
we,
of
course,
won't
abandon
our
own
thing,
but
there
will
be
consolidation
between
116
someone
around
17
in
July,
and
then
we
will
find
out.
D
Where
goes
what
and
that's
an
interesting
discussion,
but
that's
that's
a
little
bit
off
topic,
maybe
too
too
specific
right
now,
but
but
yeah
there's
a
lot
of
sure
and
we
are
not
turning
into
the
architecture
today
we
were
discussing.
Should
the
architecture
document
already
refer
now
to
the
very
very
today
released
will
be
to
be
released.
Cozy
Mercury
specification
instead
of
receipt
and
I.
Think
the
overall
resonance
was
no
don't
confuse
people
with
that
spit
it
off
make
it
a
discussion.
D
Do
it
in
parallel,
see
what's
better
and
then
resolve
this
in
the
next
step?
So
so
that's
a
long
story
for
saying
no,
yes,
I'm
saying
yes,
actually,
there's
a
lot
of
things
going
on,
but
no
there's
nothing.
It's
changing
to
the
architecture
document,
although
there
are
some
generic
things
happening
at
cozy
working
group.
Look
at
that
and
that's
my
message.
Basically
thank
you.
H
I,
just
I
guess
I
wanted
to
a
couple
of
things.
First
of
all,
I
think
if
we're
discussing
a
document
and
some
of
those
changes,
I
think
they're
all
excellent,
but
I
unfortunately,
have
not
been
able
to
get
deep
into
the
document,
and
it
would
be
helpful
to
have
it
on
the
screen
or
at
with
some.
You
know,
link
or
something
to
the
the
changes
or
whatever
it
is
just
to
help
follow.
H
If
again,
if
I
heard
that
correctly
and
I
think
there
was
one
more
I
can't
remember
what
it
was.
Is
that
and
then
so
and
then
for
signatures
we
have
decided,
we
will
not
be
dependent
on
cozy,
but
we
will
put
a
magic
happens
here.
Box
in
the
architecture,
for
the
signature
process
is
that
is
that
a
correct
summary.
D
D
In
camera,
rough
sharing
anything
so
the
second
item
I
think,
depending
on
things
cozy,
we
are
in
skits
yeah,
taking
cozyen
and
molding
it
to
what
we
think
we
can
use
it
for
and
that's
a
receipt
and
then
cozy
and
parallel.
We
are
telling
them
while
we
are
doing
this
but
shouldn't
we
do
this
in
general,
like
like
in
a
global
thing,
and
we
are
paralyzing
that
so
there's
no
no
decision
there,
yet
there's
actually
two
tracks
that
we
want
to
see
which
is
going
to
work.
D
H
I
D
Coming
from
arbitrary
anywhere,
you
had
a
reliable
partner
for
years
and
they
are
now
coming
in
and
they
are
signing
something
that's
scrafu
and
you
have
never
heard
of
that
before
you
don't
know
what
scruffle
is.
You
have
literally
Googled
that
and
you'll
find
a
description
in
a
language
you
don't
know,
and
now
you're
like
okay,
how
do
I
check
authenticity?
That's
a
real
problem,
so
the
authenticity
check
about
the
same
thing
doing
over
the
world
all
over
again,
it's
a
thin
frosting.
It's
concise!
It's
security.
There
are
libraries
available
for
all
things.
D
That's
the
thing:
the
content,
whatever
it
is,
okay,
be
my
guest
but
I
think
no,
the
signature!
You
can't
diverge
too
much
that
that's
the
problem.
We
were
trying
to
accommodate
other
things
that
it
seems
as
a
payload
and
referring
to
them
and
like
okay,
this
is
initially
signed.
Unfortunately,
there
will
be
a
next
signature.
We
are
really
apologizing.
Please
call
this.
It's
very
specific
guidance.
How
to
do
this
possible,
but
I
think
on
a
global
scale.
You
can't
diverge
on
how
to
check
authenticity
all
the
time
because
then
again,
you're
inviting
all
the
problems.
D
H
Sense:
okay,
that
does
make
sense.
I
guess
my
I
wouldn't
say
that
you
know
Joe's
authentication
method
is
worth
having,
but
any
internationally
recognized
standard
or
well-accepted
practice
would
accelerate
the
adoption
of
skit
in
the
absence
of
our
own
signature
process.
So
just
just
my
two
cents,
I'm
I'm
gonna
yield
the
floor.
Thanks.
J
A
J
Is
a
lot
from
you
know,
go
through
and
and
do
Global
replace
or
anything
like
that,
I
happen
to
like
Ledger
better
for
the
core.
You
know
part
of
skit,
but
also
I.
Think
it
registry
is
a
better
word
for
the
whole
thing,
because
there's
going
to
be
I,
think
stuff.
That's
not
actually
in
that
ledger
that
it's
referring
to
and
so
forth,
and
that
it
seems
like
saying
something
like
skit
registry
would
be
good
for
the
whole
thing.
J
But
again,
these
are
my
opinions
right
now
and
I
think
we
can
maybe
yeah
I'm.
Just
thinking
it'd
be
better,
maybe
to
to
try
to
put
this
terminology
details
aside
and
I
love
the
discussion
that
we
were
just
having
about
how
cozy
fits
in
with
with
how
the
ledger
works,
and-
and
that's
where,
like.
If
I
was
here's,
what
I'm
trying
to
do
I'm
trying
to
take
a
ledger
off
the
shelf,
AWS
qldb
and
then
the
question
is
how
how
do
I?
How
would
I
work
with
that
with
cozy?
That's
that's
something.
J
G
D
Right,
I'm
just
barging
in
here,
because
I
said
the
trigger
word,
sorry
for
being
intrusive.
We
have
this
again
this
this
Global
cozy
how
to
represent
Market
trees.
It's
a
draft,
and
now
we
just
decided
to
move
qldb
not
into
the
first
zero
zero,
because
it's
a
branded
thing
and
to
reference
something
that's
an
algorithm.
That's
a
branded
thing
will
be
a
big
Opera
and
and
to
the
Gateway
functions
of
the
ietf
that
are
vetting
algorithms,
so
so
we're
going
with
the
the
least
contentious
thing
in
which
is
a
certificate
transference.
D
The
transparency
thing
right,
that's
our
first
residency
item,
but
but
there
are
other
I
want
to
say
named
algorithms
that
are
not
easily
referenced
today
to
for
for
vetting
of
the
crypto
Forum
research
Group,
which
is
the
I,
want
to
say,
semi
official
Gateway
function
for
algorithms
that
are
okay
for
the
IDF
and
we
have
to.
We
have
to
do
that
exercise
to
to
to
go
through
the
cfrg
here
to
to
get
something
like
2ldb
vetted,
but
yes
exactly.
That
is
why
we
are
splitting
off
the
Mercury
proofs
to
the
Cozy
group.
D
Saying
hey:
this
is
the
Place
who
register
something,
there's
just
one
cool
candidate,
because
that's
already
RC
and
all
these
other
candidates,
one
of
them
being
qldb
and
unfortunately
we
have
to
pass
them
through
crypto.
Forum
research
group
unfortunately
means
sorry
for
taking
this
time,
but
we
have
to
be
thorough
here
and
we
have
to
do
the
things
right.
So
the
apology
is
for
the
time
this
will
cost,
but
we
are
not
apologizing
for
foreigners
and
and
feasibility
so
because
that
is
the
goal
right.
D
J
B
Think
that
is
that
we've
got
two
different
two
different
Horizons
here
right,
because
the
the
important
thing
for
me
and
Tennis
is
now
here
so
welcome.
Hennis
I
think.
The
really
important
thing
for
us
is
that
the
deadline
for
submission,
if
we
want
it
to
be
sort
of
officially
considered
at
116,
is
today.
So
the
big
question
for
this
meeting
is:
is
there
anything
fatal
in
the
current
spec?
B
You
know
the
current
merges
that
that
we
really
think
we
don't
want
to
submit
and
then
yeah
we
get
to
we
get
to
keep
working.
It
does
occur
to
me
that
if
we're
going
super
abstract
with
changing
ledger
to
log,
that's
kind
of
the
opposite
decision,
so
we
need
to
look
at
you
know
in
the
next
phase
of
work.
B
We
need
to
to
look
at
how
far
we
take
that,
because,
obviously,
an
append
only
lock
doesn't
have
to
have
Merkle
trees
in
it
at
all.
So
there's
a
bit
of
inconsistency
in
my
mind
at
what
stage
of
maturity
the
document's
at
in
those
two
different
ways,
but
yeah.
Let's
just
make
sure
that
we're
we're
happy
with
the
today
submission
and
and
if
it's
okay.
B
C
What
we
landed
was
look
just
just
make
sure
that
you
have
an
a
mime
type
associated
with
the
payload
and
any
recognized
mind
type
could
be
processed.
So
if
it
was
a
pgp
signature
or
you
know,
signed
piece
of
you
know
artifact,
it
would
have
a
you
know:
pgp
signature,
mine
type,
so
I
I
think
we
could.
We
could
address
this
by
saying
with
skit.
We
recognize
mime
content
types
as
the
means
by
which
we
communicate
information
about
formats
and
signatures
and
and
payloads
thanks.
D
So
I
could
definitely
add
to
that
that
media
types
at
their
registry
are
absolutely
the
scope
of
our
seas
and
therefore
internet
drafts.
We
have
to
carefully
phrase
them
I
think
it's
it's
a
complimentary
thing
to
the
content,
of
course,
but
it's
very
useful
to
apis
and
their
proceedings
and
procedures.
So,
yes,
why
it's
not
a
high
priority
right
now
in
the
end,
I
absolutely
agree
with
dick.
Whatever
we
do
here
can
only
benefit
from
corresponding
media
types.
C
Yeah
and
I
was
just
raising
that
Hank
because
of
your
concern
or
someone's
concerns
that
cozy
was
mentioned
here
in
reality.
There's
no
there's,
no
reason
why
we
couldn't
support
cozy
or
pgp
or
S
mime
or
any
other.
You
know
proper
packaging.
You
know
format
as
part
of
this
deal
because
the
the
payload
is
okay.
So
it's
just
a
matter
of
getting
you
know
giving
the
receiver
the
information
they
need
to
process
that
payload.
D
If
we
diverge
there,
you
require
everything,
even
the
smallest
iot
device,
to
have
a
second
stack
that
doesn't
work
and
so
I
think
you're,
absolutely
correct.
Zig
on
the
payload
level,
we
could
even
have
further
documents
later
on
we'll
say
well,
this
payload
that
we
say
here
in
the
arc
just
says:
okay,
basically
composes
these
very
three
very
prominent
things,
and
we
can
elaborate
on
that.
That's
not
a
problem!
That's
becoming
that
we
can
even
make
them
a
non-opaic
statement.
D
I,
don't
want
to
say
transparent
statement,
because
that's
kind
of
violating
terminology
with
transparency
service
I'm,
avoiding
that
by
saying
non-opaque
at
the
moment,
but
but
yeah
I
think
there
are
a
lot
of
non-opaque
statements.
We
want
to
Define
here
and
sketch,
and
one
of
them
could
be
for
the
internal
signature
schemes.
Everyone
support
and
then
absolutely
addict
sorry
and
that's
awesome.
Yeah.
D
D
D
Unfortunately,
I
think
so
yes,
that
is
that
is,
that
is
a
global
problem
that
is
an
interoperable
problem
on
on
on
Fast,
immediate
resolution
of
authenticity,
yes,
but
again,
you're
as
soon
as
you
issued
your
own
statement
on
the
on
the
skill
level,
the
statement
itself
could
contain
whatever
you
need
as
further
authentication
authenticity.
It
is
not
mutually
exclusive,
but
I
think
on
a
global
level
for
easy,
fast
and
consistent
authenticity
ad
hoc,
you
cannot
go
into
a
tree
of
options.
That
is
the
problem.
Yeah.
B
B
G
So
I
I
wanted
to
agree
with
Hank
on
simplifying
the
client,
implementation
and
kind
of
using
standards
to
to
make
people's
lives
easier
and
I,
actually
wonder
if
I
I'm
not
quite
sure
what
you're
saying
about
the
append
only
definition
I.
It
would
seem,
in
my
mind
at
least
beneficial
that
there
was
a
single
way
to
architect
that
or
a
set
of
approved
ways
to
architect
that,
at
least
from
the
standpoint
of
making
the
auditor's
tasks
easier.
You
know
these.
These
claims
are
that
of
transparency.
G
Services
in
fact
transparent,
independently,
and
so
on
is
only
as
good
as
the
auditing
that's
done
on
that
I
I
guess.
It
could
just
be
the
case
that
if
somebody
comes
up
with
a
bizarre
scheme
that
they
claim
is
append
only
and
they
can't
find
an
auditor
for
it,
that
people
will
move
somewhere
else
but
I
to
what
extent
is
do
we
think
the
goal
should
be
to
have
only
a
certain
set
of
approved
data
structures
and
and
approaches
to
the
append
only
and
transparency
aspects.
D
I
think
that's
an
excellent
extension
I
think
you
have
to
go
through
some
vetting
here.
We
can't
just
say
this
is
the
way
I
I
would
like
I
would
love
to
say
this.
The
way,
but
I
think
that
that's
not
possible,
so
one
step
towards
what
you
are
highlighting
here
is
is
to
go
through
the
process
of
first
of
all,
accumulating
always
put
them
into
a
register
again
and
then
the
skit
the
skit
agree
on.
While
this
looks
like
the
best
way
forward.
D
G
Yeah
I
mean
I,
I,
guess
I,
it
also
I.
It
should
be
obvious,
I
guess,
but
just
to
curse
me
that
this
is
an
issue
for
the
verifier
of
receipts.
Also
and-
and
you
know
so-
I
appreciate
the
complications
of
of
how
to
do
all
that,
but
I
and
and
I
I
don't
want
to
take
time
away
from
what
we're
trying
to
get
done
today,
which
it
makes
sense,
but
I
I
do
think.
G
E
Then
we
should
not
restrict.
We
should
not
say
okay.
We
can't
support
that,
because
that
up
and
lonely
nature
is
not
Merkel
tree.
So
so
that's
why
append
only
is
the
characteristic
we
want
to
support,
how
you
implement
it
down
the
line
through
what
type
of
Merkel
tree
it
would
be
best
for
implemented
implementers
to
make
a
decision.
Call
on
that.
That's
my
take
on
that.
B
A
Yeah
just
to
yogishi's
point,
the
doc
does
refer
to
append
only
in
several
places,
and
there
was
a
more
detailed
section
that
referred
to
you
must
not
delete
or
it
must
not
delete.
So
I
think
the
append
only
and
the
couple
of
clarifications
of
a
definition
of
the
behavior
of
the
implementation
is
probably
much
more
critical
than
whether
it
says
log
or
Ledger
or
Foo.
Rather,
we
Define
the
behavior,
but
just
as
a
thought.
B
A
A
A
H
F
F
A
F
F
D
The
idea
what
Hannah's
is
trying
to
say
in
theory,
everything
we
do
from
Tuesday
on
is
reading
and
not
writing,
and
now
the
the
process
allows
you
to
push
something
in
two
weeks:
Mondays,
which
is
the
first
day
of
the
meeting
or
there'll,
be
Saturday.
I
am
not
entirely
sure
when
the
day
is,
but
but
the
expectation
is
that
you
don't
have
to
read
something
on
Monday
on
the
meeting,
but
because
you
already
read
it
in
the
two
weeks
now.
D
So
if
you
there's
a
possibility
formally
to
still
update
a
draft
in
the
meeting
week,
but
it
is
somehow
like
if
you
do
a
big
overhaul
and
not
only
editorials,
it's
also
perceived
as
well.
You
just
squeeze
that
in
I
couldn't
prepare
for
that
one
right,
and
so
so
it's
it's
a
little
bit
discouraged.
Is
that
impossible,
if
it's
a
vital
thing
that
that
it
provides
Clarity
and
resolves?
D
B
B
The
issue
that
we've
been
discussing
for
the
last
few
minutes,
because
there's
just
so
much
Nuance
to
it
in
particular,
we
clearly
have
to
have
more
than
one
signature
scheme,
because
otherwise
we
don't
have
crypto
agility
and
we
know
that's
a
bad
idea,
but
whether
it's
mime
type
references
or
cozy
references
or
tree
algorithm
types
in
the
Cozy
envelope,
I
think
we
we
don't
have
the
time
or
the
collection
to
actually
make
that
choice.
So
yeah.
H
I
agree
with
that
John
I
think
I
think
that
the
I
mean
I
guess
my
question
is:
do
we
have
obviously
there's
another
opportunity
to
revise
this
thing,
but
just
not
before
the
meeting
exactly
yeah
yeah?
So
it's
not
a
big
deal.
I,
don't
think
we
should
probably
go
with
what
we
have,
but
I
want
to
back
to
what
you
said
about
the
crypto.
That's
my
that
was
sort
of
my
point
earlier.
D
D
Know
I
know
it's
Japan
and
some
especially
European
folks
might
be
of
ours,
but
the
Japan
time
scale,
but
okay
I
think
but
Charlie
just
said,
is
really
putting
it
through
the
the
thumb
on
the
pain
Point.
One
of
the
most
severe
pain
points
and
I
think
we
have
to
have
discussion
time
in
your
karma
for
that
yeah.
B
F
No,
we
don't
need
to
vote
anything
but
I.
Think,
as
Steve
mentioned,
like
a
lot
of
the
feedback
that
we
had
over
the
last
I,
don't
know
how
many
weeks
well
months
has
been
incorporated
into
the
architecture
document.
Obviously
we
had
the
use
case
document
and
the
the
email
discussion
following
afterwards
for
the
call
for
adoption,
which
was
successful,
so
that
document
will
be
submitted
as
well
as
a
working
group
item.
So
we
have
two.
J
F
F
F
F
E
D
E
D
E
D
B
B
Laugh
when,
when,
when
you
remember
what
it
is,
so
it
seems
like
it
seems
like
we're
all
set,
so
harness
you'll
deal
with
the
actual
submission,
then
I'm
sure
many
of
these
comments
will
come
back
from
the
other
people
who
read
the
document
and
we'll
have
a
fun
time
in
a
couple
of
weeks.
Prioritizing
the
next
issues,
I
think
and
thank
you
very
much
to
the
the
guys
who've
done
so
much
work
over
the
last
couple
of
weeks.
C
Hey
guys
yeah
I
just
wanted
to
mention
earlier
today
on
the
mailing
list,
I
sent
out
a
suggestion
that
we
might
want
to
add
a
link
to
the
U.S
cyber
Street
National
cyber
security
strategy.
In
the
use
case
document
I
know
some
I
think
some
others
suggested
that
may
not
be
such
a
great
idea.
We
may
have
to
do
all
of
them,
but
at
least
like
to
you
know,
make
that
suggestion
and
see.
If
there's
any
support
for
it
here
to
see.
If
we
can
add
that
before
the
next
meeting.
H
C
So
how
is
one
of
the
one
of
the
items
in
there
that
I
think
is
really
going
to
be
directly
in
line
with
the
work
skit
does?
Is
this
concept
of
rebalancing
cyber
security
risk
where
you
know
software
suppliers
and
consumers?
Will
you
know,
take
action
to
to
do
a
better
job
at
mitigating
risks
amongst
themselves
to
try
and
share
the
responsibility
for
those
you
know
for
for
protecting
entities
from
cyber
risk,
so
I
definitely
see
it
being
aligned
with
the
items
we
have
in
the
use
case
document
thanks.
H
Just
okay,
because
that
is
not
a
perfect
match
for
skit
and
we
don't
want
to
kind
of
flavor.
The
you
know.
Skit
was
not
written
to
address
that
issue
and
the
skit
attestations
are
going
to
be
much
more
stringent
than
the
requirements
in
that.
In
that
document,
I
would
say
it
is
orthogonal
somewhat
to
skit,
but
maybe
is
a
use
case
for
down
the
road.
C
Thank
you,
Charlie
I
see
it
a
little
differently
when
I
look
at
what
what
our
name
is.
It's
supply
chain,
Integrity,
transparency
and
Trust,
and
the
concept
in
the
National
cyber
security
is
all
about
transparency
into
the
trustworthiness
of
software
supply
chain.
Artifacts,
so
I
I
see
it
I,
see
it
differently.
I
I
definitely
see
the
synergies
there
between
what
a
skit
registry
can
provide
in
terms
of
that
transparency
into
trustworthiness,
so
I
I
guess
I
see
a
little
difference.
H
H
Right
I
think
that
would
it
would
narrow
it
and
flavor
it
too
much
right
now,
maybe
later
on,
we
can
have
a
have
an
extended
use
case
where
we
can
address
that
that
you
know
that
the
cyber
security
strategy,
but
for
right
now,
I
think
it's
premature,
just
just
my
two
cents
and
anybody
else
is
welcome
to
jump
in.
Thank.
F
C
An
opportunity
for
credibility
here
you
know
linking
to
something
that
is
really
going
to
happen,
so
that
there's
some
benefit
to
that.
If
we
can
tie
our
wagon
to
something
that
is,
is
definitely
on
the
you
know
the
radar
to
be
implemented,
that
that
would
give
us
a
lot
of
credibility.
That's
just
my
opinion.
My
two
cents
thanks.
F
I
I
just
wanted
to
say
that,
while
adding
only
the
U.S
specific
strategy
is
no
good,
there
are
similar
legislations
all
over
the
world.
Maybe
you
should
have
a
separate
document
pointing
out
how
skit
fits
in
to
various
legislation,
but
pointing
out
a
single
legislation
in
a
worldwide
document,
wouldn't
be
a
good
thing.