►
From YouTube: IETF-SCITT-20230814-1500
Description
SCITT meeting session at IETF
2023/08/14 1500
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
A
A
Ahead
of
time,
we,
as
you
all
have
seen
on
on
the
meeting,
is
we
had
to
cancel
last
week's
meeting
because
we
failed
what
I
failed
to
distribute
the
meeting
invite
with
the
agenda
in
with
enough
in
advance
notice,
and
so
we
had
to
cancel
that
meeting
and
then
give
it
another
try.
But
now
John
has
set
up
a
recurring
meeting
in
case.
You
have
seen
that
with
the
from
the
IDF
meeting
website
from
the
working
group
meeting
website
and
so
I
think
that
should
be
a
non-issue
in
the
future.
A
A
D
C
B
C
Okay
cool
so
sounds
like
that's
the
only
one,
so
mine
I
will
put
a
message
out
on
the
mailing
list
as
well
to
make
all
of
this
very
fair,
but
just
it's
already
time
to
start
thinking
about
118
in
Prague.
The
session
request
tool
is
open,
so
if
anyone
has
any
strong
requirements
or
opinions
on
the
session
for
118,
if
it
should
be
at
the
beginning
of
the
week
or
the
end
of
the
week
or
wants
to
express
Clash
avoidances,
we
if
we
collect
those
early
it'll
be
easier
to
accommodate.
E
E
E
C
G
A
C
G
E
Yeah
so
I
I
added
myself
as
a
reviewer
and
was
then
blocking
or
or
locking
on
on
orange
comment
or
your
question.
What's
the
payoff
for
having
a
yaml
version,
I
can
I
can
reflect
a
little
bit
of
the
sibo
working
group's
opinion
here,
I
hope
constantly
correctly.
If
I
was
wrong
later,
that
Yama
is
actually
a
good
alternative
or
optional
diagnostic
language
possible.
E
So
so
I'm
not
entirely
sure
if
you
want
to
send
it
over
the
wire
because
line
breaks
and
line
breaks
so
I
I
once
before,
sibo
I
once
did
a
base64
encountered
line
of
yaml
to
put
another
base64
encoded
message.
That
is
all
these
lines
of
yaml,
because
it's
line
break
oriented
and
it
was
it
was
a
nightmare
and
and
just
because
it
had
to
go
through
to
some
binary
in
the
end
and
so
yeah
I
think.
E
I'm
not
against
that
as
a
as
a
because
this
is
a
media
type,
a
comment
as
really
putting
that
on
the
Via
I
mean
I,
don't
know,
I,
think
it's
a
representation
problem,
not
a
transport
problem
or
a
encoding
problem.
But
that's
maybe
just
me,
but
I
know
that
the
again
sibo
working
group
is
is
is
basically
in
front
of,
but
never
really
came
to
using
yaml
as
a
diagnostic
representation
for
sibo,
for
example,.
A
E
F
F
That's
the
ideal
case.
In
my
experience.
Most
of
the
time
they
will
misparse
the
binaries
OR
at
some
point
be
making
some
kind
of
binary
parsing
mistakes,
and
at
that
point
they
may
fall
back
to
encoding
the
binaries
as
text
to
move
them
across
API
boundaries.
I
think
that
that
encoding
as
text
thing
is
maybe
not
always
a
great
thing
that
happens
in
apis,
but
at
the
same
time
a
lot
of
API
tooling.
Is
it's
not
really
ready
for
Seaboard
or
cozy?
F
It's
again,
like
you
know,
it's
gonna
make
payloads
more.
You
know
expensive.
It
makes
the
API
interface
potentially
more
complicated.
You
could
have
cases
where
maybe
you're
negotiating
for
Content
Types
on
the
API.
You
know
and
then
there's
different
API
considerations.
If
the
API
isn't
over
HTTP,
you
know
how
are
you
handling
your
different
content
types
Etc
with
all
that
being
said,
my
experience
working
with
cozy
structures
that
we
have
today
with
apis
is
that
I
just
prefer
to
wrap
them
in
yaml
or
Json
before
I.
Do
anything
with
them.
F
F
Maybe
that's
just
the
test
or
development
mode
thing
that
goes
away
when
you
get
to
the
production
case,
but
I
think
I
would
be
concerned
about
how
much
adoption
you
might
get.
If
you
stick
to
an
API,
that's
pure
seabour
and
cozy
it
just
it's
difficult
for
developers
to
work
in
that
space.
Sometimes
that's
it.
A
So
it's
I
I
have
to
check
if
it
would
essentially
be
a
way
to
define
this,
so
would
an
issue
a
potentially
use
like
a
Json
representation
of
the
of
the
sign
statement,
or
would
that
still
be
a
binary
person
representation
as
today
and
then
kind
of
behind
the
scenes
on
the
API?
It
would
be.
The
binary
version
would
be
translated
or
transcoded
into
into
sort
of
Json
Style.
B
You
know
binary
encodings,
but
eventually
you
have
to
be
able
to
follow
that
you
have
to
be
able
to
decode
it
and
and
put
it
into
a
format
where
you
can
say.
Okay,
this
is
what
we're
working
with
so
that
you
can.
You
can
check
it
all
the
way
through,
indeed,
you
know,
once
maybe
everything
is
locked
down
that
can
go
away,
but
likely
you
know
unless
we
see
a
real
need
for
it.
B
B
Today
we
don't
have
any
short
supply.
Well,
we
have.
Everything.
Is
limited
but
not
to
the
extent
that
it
used
to
be,
and
so
if
we
could
leave
it
in
Json
I,
don't
I'm,
not
a
fan
of
yaml,
so
I'll
just
be
honest
with
you,
it's
the
syntax
is
not
as
clear-cut,
so
I
I
would
promote
Json,
it's
obviously
the
absolute
leader
in
terms
of
interface.
B
You
know
syntax
and
why
not
just
leave
it
in
that?
It's
a
good
question
to
ask
why
go
to
seaboor?
Is
there
a
reason
and
if
there's
not
a
reason,
you
know
it,
you
could
leave
it
the
structure
or
whatever.
It
is
right
now
we're
re-encoding
into
a
Seaborn
and
and
then
encrypting
that
you
could
just
leave
that
in
this
as
a
Json
block
and
and
do
the
same
thing
with
it.
As
long
as
the
Json
was
had
limit.
F
B
Know
special,
and
indeed
there
are
some
fields
that
are
are
going
to
have
to
be.
If
you
put
that
into
an
encoding
that
is,
you
know,
human
readable.
Some
parts
are
not
going
to
be
right,
so
so
the
binary
you
know
say
signature
is
something
that's
still
very
opaque.
I,
don't
know
you
know
you
can't
read
it
so
that
it
can
be
encoded
in
something
that
is
still
transportable.
B
But
if
what
this
is
a
question,
is
there
I,
I
I,
just
think
that
yeah
I'm,
going
along
with
what
Ori
is
saying
in
that
that
the
apis
should
not
the
thing
that
are
obviously
going
to
be
used
by
human
beings,
which
is
the
apis
to
do
this
should
not
be,
should
maybe
there's
a
way
we
can
have
the
Json
Co
a
standardized
Json
for
everything.
That
is
what
we
mainly
Target
and
then,
if
necessary,
it's
turned
into
to
cozy
and
Seaboard.
B
C
E
Yeah,
so
one
reason
to
stick
with
one
thing,
at
least
for
the
authenticity,
and
the
three
part,
of
course,
is
the
homogenicity,
the
the
uniform
method
applied
for
a
signature
checking
so
for
authenticity
checking.
That
makes
a
lot
of
sense.
It's
that's
why
we
decouple
the
statements
media
types
from
the
surrounding
authenticity
representation,
which
at
the
moment
is
cozy
and
there's
good
reason
for
that.
E
Now
we
will
make
a
decision
for
some
time
into
the
future
here
and
and
going
with
Jason,
which
is
and
I
have
absolutely
feel
you
are
a
little
bit
of
web
platform
problem.
Yes,
the
support
might
not
be
great,
but
again
we
could
also
improve
on
the
tooling
for
the
web
platform
representation
to
debug
things
like,
for
example,
I
heard
from
Ray
I
think
not
so
great
Json,
nice
sibo,
dayak
literally,
is
Jason
with
a
few
things
that
Jason
never
ever
cannot
express.
E
So
it
has
to
be
tinkered
a
little
bit
to
make
it
representable
so
sibo
diagnostic
representation,
basically
is
Json
plus
plus
for
humans
to
read
it
the
C
board.
So
maybe
that's
already
good
enough.
Maybe
that
is
not
highlighted
enough.
Maybe
that
is
not
known.
Well,
that
is
a
co-wg
problem
and
it
should
be
fixed.
H
Oh
yeah,
I,
I,
think
I
agree
mostly
with
Hank
I'm
concerned
I
mean
just
having
seen
all
the
problems
for
decades
that
have
happened
in
the
world
of
canonicalization.
The
notion
of
having
kind
of
two
different
ways
to
represent
something
seems
fraud
with
with
problems.
I
mean
I
have
to
say:
I,
don't
haven't
looked
at
the
API,
so
I'm
not
really
sure.
A
Okay,
thanks
Nick
yeah
I'm,
so
I
I
can
obviously
understand
sort
of
the
the
desire
to
to
use
also
something
like
a
json-based
version,
giving
the
the
way
how
various
languages
support
json-based
structures
like
you
can
find.
As
a
developer,
you
can
find
hundreds
of
tutorials
for
different
languages
like
Google
or
whatever,
and
how
easy
it
is
to
to
pass
all
that
data
structure.
So
so
I
can
certainly
understand
what
I
would
like
to
avoid
is
having
two
different
encodings,
because
we
can't
decide
so
having
having
post
works.
A
A
F
You
know
the
the
response
from
the
API
can
just
be
the
same
as
the
spec
representation,
or
it
can
be
a
different
media
type
that
wraps
the
spec
representation.
It
can
do
that
and
stay
in
seaboor
or
it
can
do
that
and
cross
media
type
boundary.
So
you
have
a
seaboor
object.
That's
exposed
as
Json
in
as
a
Json
structure,
for
example.
So
the
the
kind
of
question
that
I
have
we
kind
of
come
back
to
what's
the
purpose
of
the
API.
F
On
the
other
hand,
there
it
could
be
an
API
that
you
know
you're
expected
to
implement
this
API
exactly
as
it
stated,
and
then
you
really
would
not
want
to
expose
anything
other
than
the
highest
performing
representations
possible,
and
so
I
would
say
if
the
skid
api's
purpose
is
to
actually
be
like
implemented
outside
of
a
testing
environment
and
in
production.
You
know,
high
volume,
critical
security,
critical
infrastructure,
environment,
then
I
would
say.
F
Yaml
and
adjacent
are
completely
off
the
table
and
you
have
to
do
everything
in
seabor
and
you've
got
to
get
your
Seaboard
perfect,
and
you
probably
want
to
register
media
types
and
go
into
some
extra
details
to
make
sure
that
that
production
grades,
git
API,
is
really
doing
a
great
job
for
a
pure
binary
format
because,
as
as
you
know,
apis
for
Pure
binary
formats
are
not
always
exposed
super
nicely.
So
there
will
be
like
a
lot
of
potential
work
you
might
want
to
do
to
make
that
really
comfortable.
F
On
the
other
hand,
if
the
purpose
of
the
API
is
really
just
to
help,
get
you
a
receipt,
and
you
really
want
it
to
be
very
readable
and
it's
okay
for
it
to
be
space
inefficient,
and
you
know
the
expectation
is
everyone's
going
to
go.
Implement
some
higher
performing,
you
know,
potentially
proprietary
or
different
API
after
they
kind
of
use
this
Scrappy
API
to
figure
out
how
to
implement
skit.
F
A
F
E
Yeah
I
have
to
amend
my
comments.
Obviously
yeah
I
was
talking
about
authenticity,
layer,
I,
think
what
I
heard
is
already
said:
yeah,
don't
don't
touch
that
it's
about
the
protocol,
so
API
here
means
protocol
message,
representation
and
you
can
do
whatever
you
want.
I
I
think
that
is
absolutely
fine
I'm,
not
entirely
confident
that
a
siboa
API
is
mandatory
to
implement.
E
But
it's
a
very
strongly
recommend
then
recommend
it
to
be
a
global
interoperable
in
the
end
and
and
therefore
it
might
make
sense
to
to
have
that
always
in
your
back
pocket
somehow
but
I
I
I
I
see
no
harm
in
in
using
HTTP
1.1
as
the
transport
protocol
implementing
something
in
Json
protocol
messages
that
then
include
a
base.
64
URL,
save
I,
don't
know
represented
Civil
War
to
to
send
that
around
and
to
get
that
get
that
one
validated
work
receipt
with
the
server
Library.
E
So
I'm,
sorry,
my
daughter
is
ringing,
but
this
is
my
my
reply
so
yeah
on
the
on
the
protocol
level,
which
I
think
we
have
to
somehow
check.
Maybe
here
in
this
group,
do
we
mean
the
API
protocol
and
and
on
that
level,
to
do
the
thing
that
moves
the
messages
around
you?
Can
you
can
definitely
use
Jason,
I
think
as
an
addition
to
the
to
the
original
origin?
A
You
you
were
asking
whatever
you're
talking
about
the
payloads
like,
for
example,
the
sign
statement
versus
the
protocol.
The
protocol
doesn't
that
doesn't
have
a
lot
of
Seaboard
to
begin
with
what
sibo
or
what
Json
or
what
whatever
like
a
restful
API,
doesn't
have
a
lot
of
like
it's,
not
like
soap,
where
you
encapsulate
lots
of
messages,
like
all
you,
maybe
when
like
if
the
existing
API
description,
like
it,
has
maybe
a
structure
for
a
response.
A
B
Okay,
so
like,
if
you
look
at
the
major
you
know
API
situation
today
like
like,
if
you
look
at
AWS
and
all
of
their
services,
they're
all
Json
interface
and
you
you
know
you
submit,
they
have
a
very
simple.
You
know
submission
mechanism
and
you
submit
some
sort
of
Json
chunk
and
you
get
one
back
and
it
may
be
pretty
extensive.
B
You
know-
and
so
you
know
that's
in
the
idea
that
something
needs
is
a
little
bit
more
capable
than
Json
I
would
say.
Just
whatever
that
capability
is
can
be,
can
be,
can
be
simplified
and
made
into
Json,
because
that's
that's
the
going
thing,
but
I
wanted
to
paint
a
little
similar
picture
to
what
they
did
with
QR
codes
in
Europe
for
the
covid.
B
B
B
Eventually,
you
get
back
to
this
human
readable
form
so
that
somebody
can
can
not
necessarily
human,
read
it,
but
you're
going
to
have
some
piece
of
software
that
somebody
has
to
write
and
they
have
to
take
these
fields
and
remember
what
the
hell
they
mean
and
you
know
do
something
with
it.
The
same
is
true
here:
where
we're
going
to
have
people
who
are
going
to
be.
B
You
know
looking
at
the
fields
eventually
in
their
software
after
they
get
through
all
the
API,
and
you
need
to
do
something
with
it
and
at
that
level
it
needs
to
be
unwrapped
from
all
of
whatever
encoding
is
required.
I'm,
not
saying
that
that
we
need
to
change
from.
You
know
even
think
about
changing
from
from
the
structure
of
of
cozy
and
Seaboard.
B
Now,
on
the
other
hand,
I
see
the
need
for,
if
we're
talking
to
Merkle
tree
and
what
goes
in
it
I'm
not
debating
anything
there.
That
should
be.
You
know
very
much
a
minimalistic
kind
of
thing,
because
the
thing
grows
without
bound,
and
so
you
don't
want
to
have
something.
That's
that's
in
there.
That's
very
big,
but
I
thought
I'd
paint
that
picture
to
say
that
that
the
the
the
definitely
the
API
needs
to
be
me,
I,
in
my
view,
I
would
fight,
for
you
know
Json
as
a
way
to
do
it.
B
E
Yeah,
just
a
quick
I'm,
absolutely
with
Ray
here
the
European
Union
digital
covert
certificate
is
a
cozy
C
bus
structure
that
is
base
45,
encoded
in
a
QR
code,
a
2d
code
and
and
that's
it
and
then
it
shows
even
text
labels
that
are
two
string
characters
because
they
are
small
enough
to
be
a
human
readable.
So
to
speak,
so
you
do
not
see
a
zero
and
the
one
there.
E
You
see
a
two
letters
that
make
sense
to
you
like
first
name
last
name,
f
and
Ln
and
such
and
so
to
make
sense
in
a
diagnostic
notation
and
and
then
they
have
that
representation
thing.
And
then,
when
you
put
a
show
to
some
scanner
and
scan
the
QR
code,
it
decodes
it
for
the
human
to
be
readable
and
that's
exactly
what's
happening
here
and
I.
Think
on
the
on
the
on
the
payload
side,
we
are
saved
on
Authority
I.
E
Think
we
established,
because
it's
fine
and
I
also
think
on
the
reference
API
we
can.
We
can
have
the
minimum
is
super
one
and
we
can
have
other
ones
and
and
show
how
they
would
be
implemented,
as
reference
I.
Think.
There's
no
harm
in
that
as
long
as
we
understand
that
the
that
the
yeah,
the
the
cost
structures
that
are
defined
by
architecture
and
cozy
IDs
are
all
uniform
foreign.
F
So
I
mean
just
for
the
sake
of
making
stronger
statements
that
are
potentially
more
triggering
I
would
say
there
should
be
a
mandatory
to
implement
seaboor
API,
and
if
you
implement
this
specification
for
the
skit
API,
you
should
expect
mandatory
support
for
seabor,
and
that
should
be
all
you
you
need.
You
shouldn't
need
anything
else.
F
If,
in
support
of
that
mission,
we
add
optional,
yaml
encodings
for
readability
and
Seaboard
diagnostic
Etc
I.
Think
that
is
nice
to
have
implementation,
detail
that
you
know,
if
someone's
excited
to
do
that,
work,
let
them
let
them
do
it,
but
it
should
be
completely
unnecessary
to
ever.
Ask
for
yaml
or
Jason
from
the
skip,
API
and
I.
F
Think
implementers
should
not
expect
any
interoperability
around
yaml
or
Jason
from
the
skip
API,
so
I'll
make
the
strong
statement,
and,
and
maybe
it
will
sort
of
help
us
move,
move
beyond
the
sort
of
place
that
we're
at
right.
Now,
like
again,
the
data
structures
returned
from
the
API
are
not
always
the
same.
Data
structures
that
protocol
other
documents,
Define
could
be
a
c
board
wrapper
around
a
list
of
you
know
receipts,
for
example.
F
So
if
you
know
that
our
content
type
is
always
mandatory,
see
more
by
default,
you
can
build
QR
code
systems
around
that
that
are
going
to
process
that
really
well
any
kind
of
Link
sharing,
you
know,
is
going
to
be
a
higher
degree
of
interoperability.
So
I
think
it's.
You
know.
My
argument
would
be
mandatory
support
for
seabor
on
all
of
the
endpoints
optional
support
for
yaml
and
a
debug
capacity,
and
no
support
for
Jason
whatsoever.
That's
it.
A
C
C
The
big
sweep
I
think
that
yogesh
made
mostly
to
correct
things
like
transparent
and
signed
and
stuff
consistently
that
that
wasn't
updated
in
the
code
so
we'll
get
that
updated
in
the
code
very
shortly.
So
it's
in
reasonably
good
shape,
I
would
say
as
far
as
117
goes
but
needs
updating
and
when
that's
ready
for
a
bit
of
a
maybe
a
show
and
tell
the
archivist
implementation
of
that
actually
does
rat
all
the
seaboar
structures
in
armored
Json
for
transmission
across
the
the
the
services
interface.
C
So
we
can
have
a
look
at
the
subtleties
of
of
what
that
means,
so
I'm,
certainly
not
advocating
for
Json
in
the
receipt
or
having
multiple
serialization
formats
as
as
Neil
rays.
That
would
be
a
disaster,
but
for
expressing
how
we
transmit
those
seaboar
structures
between
entities,
I
think
it's
very
useful
and
we've
got
a
new
implementation
of
that.
So
we
can
just
look
at
it
and
discuss
if
there's
anything
else
any
further
to
go.
There.
A
C
A
Okay,
so
that
that's
excellent,
because
I
think
it's
it's
definitely
a
useful
activity
to
have
that
reference
implementation,
so
that
anyone
sort
of
particularly
those
in
working
in
the
group
could
showcase
something
to
their
to
their
friends
and
peers
and
whoever
have
a
kind
of
running
code
type
of
example.
Of
course,
this
is
a
this
is
sort
of
like
a
a
playground
rather
than
a
full-fledged
production,
quality
implementation,
but
I
think
it
it's.
It
serves
the
purpose.
A
B
Guess
kind
of
represented
is
not
quite
the
same
Trend
that
I
wanted,
but
the
open
container
initiative,
which
has
a
little
bit
more
than
than
I,
wanted
in
the
in
the
packaging.
But
essentially
you
know
a
lot
of
that.
Information
is
in
there.
So
if
we
take
a
look
at
what
dick
dick
had
where
there
was
a,
there
was
sort
of
a
header
of
the
of
the
vendor
information
and
so
forth.
B
G
B
Skit
is
right.
Now
it's
very
minimalistic
in
terms
that
there
it's
just
like
a
hash
value
of
signed,
hash
value
of
something,
and
that
goes
into
a
miracle
tree
and
so
climbing
up
above
that,
my
current
thinking
was
to
Branch
off
of
what
Dick
had
done
in
a
very,
very
heavy
way
in
terms
of
adopting
kind
of
like
what
he
was
saying
and
and
yes,
including
a
lot
of
that
stuff
in
every
single
one.
A
B
Subject:
yeah
on
the
other
subject:
I
I
posted
a
link,
the
one
we
were
just
discussing
and
I
brought
up
the
Json
seabor
cozy
zlib
base
45
conversion
chain
that
they
use
for
the
EU
QR
code
for
covid
and
also
a
link
to
that
which
describes
you
know
actually
why
they
made
their
decisions
and
and
had
to
actually
come
up
with
the
space
45
encoding.
I
guess
to
do
it
and
you
know,
QR
codes
are
usually
used
for
URLs,
but
they
don't
have
to
be.
B
B
I
I
B
A
Good,
okay,
yes,
usually
takes
us
a
little
bit
longitude
discuss
items
understandably,
because
there
are
so
many
different
viewpoints.
So
we
didn't
manage
to
get
through
all
the
open
issues
or
to
get
to
any
of
missions,
but
at
least
the
ones
in
GitHub,
so
agenda
wise.
What
should
we
put
on
the
plate
for
next
Monday
I
I?
Think
some
discussion
on
the
feed
structure
would
be
appropriate.
J
E
Yeah
I
would
agree
with
that.
Sorry,
yeah
I
think
that
one
dedicated
session
that
looks
that
does
a
screen
share
and
and
we
can
go
through,
closing,
updating
or
actually
handling
issues.
Nprs
is
a
great
idea,
because
I
think
we
are
always
kind
of
skipping
that
and
therefore
we
have
to
consciously
deliberately
still
deserve
some
time
for
that.
I
Very
quickly,
just
I'd
like
to
see
if
we
could
focus
on
the
API
just
to
be
able
to
wrap
up
what
comes
back
after
putting
a
payload
into
a
registry
and
then
that
URL,
hopefully
it's
a
URL
and
that
can
be
distributed
for
others
to
pull
that
data
out
of
the
registry.
So
I'm
hoping
to
focus
on
the
API
a
little
bit
more
thanks.
Yeah.
A
Okay,
that's
perfect,
yeah!
We
didn't
go
too
far
today
on
the
API
topic,
but
yeah.
That
sounds
excellent,
so
we
have
already
like
kind
of
three
items
already
I.
Think
that's
good
enough
for
next
week
and
I
would
send
a
a
pointer
to
the
GitHub
issue
track
again
with
some
of
the
new
issues
that
I
that
I
added.
Maybe
someone
of
you
has
some
views
about
this
and
I
would
also
like
to
remind
you
that
you
promised
to
do
some
some
work
at
the
last
IDF
meeting
or
around
it
before
the
submission.
A
C
J
Right
I
want
to
raise
my
concerns
here.
We're
still
skirting
the
charter
very
closely
here.
The
API
we're
talking
about
for
the
The
Ledger
and
for
the
for
transparency
statements
is
a
submission
or
an
audit
capability.
If
you
want
query
and
storage,
we're
gonna
have
to
reopen
the
charter
right.
There
is
no
ad
hoc
query
capability,
Against
The
Ledger,
as
it
sits
today.
A
J
Dip
into
them
I
understand
the
feed.
I
have
John
and
I
have
talked
about
this
before,
but
you
know
talking
about
the
specifics
of
software
supply
chain
and
the
document
formats
and
so
forth,
which
are
being
controlled
by
sisa
and
nist,
and
a
bunch
of
others
is
getting
into
a
couple
of
gray
areas
where
we're
not
chartered
for
so
I
just
wanted
to
bring
that
out.
D
Hi
I,
just
kind
of
I
won't
take
too
long,
so
I
sent
a
link
in
the
skit
working
mailing
list
where,
like
CPU
government
organizations
in
uscisa
and
department,
National
cyber
director
of
Technology
and
other
organizations
are
asking
how
to
secure
open
source
software
they're
asking
for
a
feedback.
So
maybe
it's
good
time.
We
have
a
good
amount
of
time
to
prepare
something
and
suggest
something
and
kind
of
advertise
kit
in
a
way
that
suits
us
as
well
and
them
as
well.
So
just
one
thing
I
wanted
to
mention
that
here,
I.