►
From YouTube: IETF109-SACM-20201116-0500
Description
SACM meeting session at IETF109
2020/11/16 0500
https://datatracker.ietf.org/meeting/109/proceedings/
A
Okay,
it
is
the
top
of
the
hour,
so
we
will
go
ahead
and
get
started.
I
believe
everything
is
so
the
recording
is
started.
Everybody
can
hear
me
and
you
can
see
the
slides
right
excellent.
A
So
this
is
the
sacrum
working
group.
Let
me
undo
the
chat
thing,
so
I
can
actually
excellent
great.
So
with
that
the.
A
If
you
have
any
questions
about
any
of
these
feel
free
to
ask
chris
or
myself
or
roman,
who
is
our
responsible
a.d
next
is
the
agenda
that
we
have
so
we're
at
the
welcome
notewell
and
administrivia
section
of
this.
The
first
thing
that
I
do
need
is
a
minute
taker.
Is
anybody
volunteering
to
take.
A
A
So
reliable
thank
you
bill
and
we
don't
particularly
need
a
jabber
scribe.
A
The
jabber
is
integrated
into
the
meat
echo
tool
that
we
are
all
using
and
I
don't
I
don't
know
if
there's
any
agenda
bashing.
A
B
In
the
terms
of
the
the
roley
configuration
checklist
stuff,
it
appears
that
my
name
got
drafted
on
there.
I
I
was
I
I
was
under
the
impression
that
steven
was
going
to
be
given
the
update
on
that.
So,
if
somebody
else
that
stephen
works
with
is
on-
and
they
know
a
little
bit
more
about
it
than
I
do,
I
can
give
a
three
second
update.
A
A
Yeah
either
either
one
of
them
all
right.
Thank
you.
So
the
next
thing
is
document
status.
I
went
ahead
and
put
the
epcp
on
here
because
we
had
a
virtual
interim
a
little
less
than
a
month
ago,
and
at
that
virtual
interim,
we
decided
to
stop
work
on
that
and
we
had
a
discussion
for
the
rationale
for
that.
But
the
chairs
were
supposed
to
send
a
follow-up
email
to
the
mailing
list
which
in
reviewing
the
minutes,
I
realized
that
we
had
not
done
so
earlier.
A
This
evening
I
sent
that
follow-up
email
to
the
mailing
list
and
I've
given
a
a
date
of
friday.
So
if
the
the
the
rationale,
if
folks
are
happy
with,
I
mean
basically
the
the
idea
was
that
jess
felt
that
the
document
was
no
longer
needed
in
the
community
that
the
work
on
the
document
had
already
informed
the
work
of
the
working
group
and
that
any
material
that
needed
to
be
incorporated
into
the
architecture
document
where
the
architecture
document
was
relying
on
the
epcp
could
be
moved
there
and
you
know
so.
A
The
other
reason
is
that
there's
there
appears
to
be
a
fair
amount
of
work.
That
would
need
to
be
done
and
we
don't
really
have
editors
for
it
at
this
point,
so
the
if
anybody
feels
that
that
document
does
need
to
be
progressed,
I'm
looking
for
both
opposition
to
us
parking
it
and
also
volunteers
for
helping
to
complete
it.
A
So
that's
why
that's
still
on
there,
if
you
were
at
the
virtual
interim
and
you're
wondering
why
the
next
document
is
the
coastwood
document.
I
know
that
there
has
been
a
lot
of
work
done
to
update
this
and
I'm
not
sure
who
would
like
to
speak
to
the
current
status
of
it.
I
put
hank's
name
on
here
because
he
was
the
one
that
discussed
it
before.
C
D
Hi,
hello,
hello,
everyone
yeah,
I
saw
there
was
actually
feedback
from
roman
my
night
yesterday,
so
this
is
my
very
early
morning
today
and
so
yeah.
We
have
created
a
update,
as
you
mentioned,
it
is
rather
substantial.
We
addressed
all
of
thomas's
comments.
I
think
there
is
this
structural
thing
to
disconnect
from
the
switch
interoperability
semantics.
D
I
think
we
have
done
that.
I
think
that
is
the
most
difficult
to
check
roman
seems
to
have
liked
it,
roman.
If
you
have
a
comment
on
that,
that
would
be
helpful.
I
think
the
only
really
open
issue
is
actually
a
rather
technical
one.
D
I
think
the
other
ones
are
just
more
leg
work
that
we
have
not
were
not
able
to
complete
until
this
meeting
here
and
this
technical
one
is
the
time
representation
of
xsd
date
and
if
the
seaboard
time
is
actually
a
appropriate
thing,
because
we
have
to
convert
that,
I
think
it
is.
We
might
not
need
the
time
fraction
here.
D
We
can
fall
back
to
an
an
inch
type
of
a
time
that
we
can
create
our
own
by
not
using
float
by,
but
the
native
primitive,
and
then
there
is
this.
This
question
that
we
actually
did
not
get
from
roman-
and
I
think
roman
is
here
today,
which
is
about
the
extensibility
features
of
sibor,
to
be
used
here,
and
that
caused
a
little
bit
of
a
confusion
in
the
attitus
group,
because
we
did
not
really
get
the
meaning,
I
think
so,
roman.
D
E
Hey:
hey
everyone,
so
so
top
line.
The
thing
you
first
mentioned
heck
about
the
fact
that
the
new
text
unwinds
coast
with
and
suid
yeah.
Thank
you
that
you
guys
the
team
did
a
great
job
unwinding
that
that
all
that
text
looks
good
to
the
point
about
extensibility.
E
D
Yeah,
I
think
you
did.
That
is
actually,
I
think,
the
the
issue
here,
because
we
we
don't
really
know
we
interpreted
it
that
way,
and
but
it
was
really
hard
for
us
to
understand
that
and
let
me
let
me
find
that
passage
it's
about.
E
I
thought
I
made
a
new
checklist
kind
of
yesterday.
I
I
I
took
a
subset
of
my
original
feedback.
I
don't
remember
anything
about
extensibility.
If
I
did
say
something
I
think
I
may
have
just
met.
Give
me
more
words.
D
D
E
D
Yeah
it's
by
the
it's
in
the
name.
Space
xsd
typically
has
this
interesting
feature.
Let's
call
it
to
draw
in
the
version
number
into
a
namespace.
Cdj
has
neither
I'm.
E
D
Okay,
yeah,
we
can
do
that,
so
it's
it's
supposed
to
be
handled
by
the
extensibility
feature,
so
everything
that
changes
over
time
can
be
expressed
with
additional
the
specifications
have
a
semantic
scope
and
therefore
it
is
defined
there.
We
abstract
from
this
full
symmetry
already
a
little
bit
here
now,
and
this
would
go
into
that
part
that
is
also
detaching
itself
from
that
there
is.
D
The
assumption
is
that
that,
having
a
a
a
more
complex
extensibility
feature
like
for
rims
or
for
other
contexts
like
like
the
evolvement
of
ice,
so
if
it's
reflected
here,
there
will
be
more
than
one
way
to
combine
all
this,
which
is
typically
the
thing
the
lane
you
want
to
go
and
down
the
small
constraint
space
and
the
in
the
cdl
space.
We
have
a
very
good
text,
so
I
I
like
we
can.
D
D
And
I
think
from
my
part
that
it
is
so
the
rest
is
actually
so,
for
example,
expressing
the
issuing
emails
again
for
for
registering
some
of
the
items,
some
artifacts
that
are
still
in
there.
I
think
that
is
all
still
some
leg
work.
We
think
we're
in
a
good
way
here,
so
so
stay
tuned.
I
assume
this
will
only
looking
back
on
our
speed.
A
G
H
F
A
Okay,
I
I
sorry
dave,
I
think
chris
and
I
are
both
clearing
the
queue
at
the
same
time,.
G
I
see
I
just
had
a
just
for
clarification.
I'm
sorry,
I
I
joined
late.
I
was
having
a
hard
time
getting
connected
at
first
first
meeting
of
my
week.
So
as
far
as
like
coast
with
versioning,
do
we
need
to
have
an
explicit
version,
so
one
of
the
things
that
we're
doing
in
coastwood
is
we.
We
have
a
registry
of
of
coast
with
tags,
and
so
the
idea
is
that,
as
the
syntax
of
a
coast,
wood
were
to
change.
G
We
we
would
simply
add
new
tags
to
that
registry
so
effectively
our
our
change
control.
You
know,
with
with
the
model
you
know
happens
through
through
that
tag
registry.
Do
we
do
we
need
an
explicit.
G
G
So
we
we
had
raised
the
question
a
while
back
about
explicit
versioning-
and
you
know
jim
shaw
at
the
time
had
actually
raised
the
concern
that
you
know
all
tags
are,
you
know
are
numbered
and
if
we
simply
add
new
data,
you
know
new
new
tags
to
the
to
the
model
that
would
be
handled
through
the
registry
and
we've
been
working
off
of
that
assumption.
You
know
since
since
then,
and-
and
so
I'm
wondering-
is
this
discussion
a
change
in
that
plan,
or
are
we
we're
keeping
with
that
approach
going
forward?
G
E
So,
philosophically
I
guess
I
envisioned
it.
If
we
ever
published,
let's
say
coast
with
one
one,
one
two
and
or
you
know
qo
would
we
have
kind
of
a
new
registry
of
of
the
tags
so
to
speak.
So
if
I
ever
wanted
to
provide
you
know
a
profile
of
some
kind
saying
I
expect
the
following
things
versus
kind
of,
not
because
that's
my
version
of
that's
my
version
of
god.
Of
course,
with.
I
would
not
have
some
easy
way
to
know
which
version
I
was
expecting
without
something
application
specific.
E
I
E
Of
the
things
that
I
caught
that
didn't
have
that,
and
so
I'm
not
per
se,
arguing
if
that's
what
the
one
guru
wants,
that
we
need
to
put
it
back
in
there.
I
was
just
saying
the
way
hank
was
already
already
noting
that
he
can
drop.
The
text
in
is
just
you
know
here,
is
why
it's
not
in
there,
and
you
know
it's
a
sentence
or
two
explaining
the
situation
that
it's
a
different
data
model.
G
G
Yeah
and
as
far
as
what
else
is
left
with
the
draft,
we
have
those
early
registration
or
the
early
review
requests
that
you
had
asked
for
that.
We
need
to
get
done
and
there's
also,
I
think,
one
small
issue
with
adding
some
text
about
size
comparisons.
You
know
for
swift
tags
and
coast
with
tags.
I
haven't
had
a
chance
to
get
my
implementation
up
and
running
to
do
those
comparisons,
so
that
should
be
a
pretty
quick,
quick
thing
to
do
as
well.
E
G
D
So,
thank
you,
roman
for
that.
Actually,
so
it
was
a
big
list
and
it
took
a
look
of
how
to
compile
it
and
again
it.
It
takes
us
some
time
to
address
it,
but
we
are
soldering
through
that
and
I
think
the
the
rest
is
now
there's
light
at
the
end
of
the
tunnel
here.
Thank
you
very
much.
A
I
I
know
we
discussed
this
a
little
bit
on
the
virtual
interim.
The
question
was
where
the
magnitude
of
the
change
is
going
to
be
enough,
that
we
wanted
to
do
another
working
group
last
call
on
this
document,
and
I
don't
know
roman,
if
you
have
an
opinion
on
that
or
the
authors
do
or
chris.
E
I
mean
from
my
perspective,
it
was
a
lot
of
nits.
The
list
was
long,
but
I
I
personally
didn't
feel
like
they
substantially
kind
of
changed.
What
what
came
to
me?
I
think
there
was
just
it
was
a
long
list.
A
F
So
I
guess
the
one
question
from
reviewing
the
document
is
is
about,
at
least
in
my
mind,
is
about
the
the
remote
attestation
seem
to
be
a
lot
more
developed
in
the
draft,
although
it's
still
just
pointers,
which
I
think
is
pointers
to
the
document
in
rats.
Can
anybody
comment
on
on
that?
You
know
because
I
feel
like
that
could
be
more
significant,
but
it's
actually
not
clear
to
me
if
it
is.
G
My
perspective
is
that
we
we
should
break
any
any
connection
to
you,
know
the
work,
that's
ongoing
and
and
and
rats,
and
simply
have
that
document
point
back
to
the
published
coast
with
spec.
You
know
when
when
it
works
its
way
through
the
isg,
because
it's
it's
a
use
case
for
using
coast
with
you
know
not
something
that
is
core
to
the
use
of
or
to
the
definition
of
ko
suite.
G
D
D
F
D
So
the
beginning
of
the
document
there's
three
use
cases
to
highlight
where
this
can
be
applied
and
at
first
there
was
a
so
you're
talking
about
the
assessment
case.
I
assume
that,
according
to
the
architecture
yeah
that
was
before
before
the
romans
comment
was
about
this
was
this:
this
document
started
when
there
was
no
rats,
and
so
it
was
pointing
to
tuda
before
so
a
a
specific,
the
only
one
protocol
aboard
attestation
at
the
time,
and
now
it
points
to
architecture.
D
So
it's
it's,
but
it's
also
talk
appointed
to
sam,
so
the
software
assessment
management
and
such
so
I'm
not
really
sure
how
this
is
different.
D
F
Be
my
lack
of
depth
of
reading
on
part
of
it,
so
maybe
that's
a
okay
actually.
G
It's
simply
just
an
informative
reference
to
the
rats
architecture.
If,
if
it's
problematic,
we
could
strike
it,
I
I
would,
I
would
say.
F
I
wasn't
saying
that
what
I
was
saying
is
I
didn't,
because
I
thought
there
were
some
more
statements
to
rim,
but
it's
okay.
So
if,
if
I
have
any
concerns
I'll
I'll
I'll
put
it
on
list
thanks.
D
Sure
but
I'm
pretty
sure
we
don't
have
included
any
forward
reference
so
to
speak,
to
ramsey.
E
A
Okay,
anything
else
on
cuss
with.
J
Yeah,
it's
more
like
six
to
four
to
six,
but
yes,
I
think
that's
true.
A
So
it
could,
it
could
be
like
yeah,
like
a
new
year's
surprise
how's,
that.
A
There
you
go
okay,
so
nothing
else
on
coast,
wood.
The
next
document
is
the
rolley
configuration
checklist
extension
and
dave
before
you
join.
The
call
I
had
put
bill
on
here
and
bill
said:
well,
maybe
you
or
stephen
wanted
to
talk
to
it,
and
then
you
weren't
here
so
I
left
bill
on
it
and
now
you're
here.
So
I
don't
know
which
one
of
the
two
of
you
wants
to
talk
about
the
rollie.
I
don't
see
stephen.
I
don't
believe.
G
B
Bill
yeah,
this
is
still
I
just
my
my
question
and
of
bringing
up
your
name
was.
If
steven
had
passed
any
information
on
to
you
if
he
was
joining
or
not
yeah,.
G
A
B
Yeah
sure
so
you
know
work
work
is
ongoing.
I
we,
the
three
of
us
me
stephen
and
gabe
alford,
the
the
main
authors
on
the
draft.
B
Are
we
meet
bi-weekly,
it's
sort
of
a
combination
of
the
the
two
of
the
the
two
of
them
really
kind
of
talking
more
about
implementations
of
of
rolly
that
are
going
on
on
either
side
as
well
as
the
draft,
and
I
know
that
we
were
waiting
for
the
official
adoption
of
the
draft
to
really
sort
of
continue
to
task
people
with
kind
of
completing
the
different
sections
of
the
draft.
B
It
shouldn't
be
all
a
huge
amount
of
effort
from
the
authoring
perspective,
but
again
it's
just
sort
of
us
getting
together
and
making
sure
that
we
can
kind
of
assign
people
to
to
work
on
stuff.
So
that's
that's
pretty
much
it.
The
the
updated
named
adopted
version
of
the
draft
still
hasn't
even
been
posted
on
there.
So
I'll,
just
kind
of
take
those
things
down
as
action
items
to
take
to
the
group.
A
A
Well,
the
draft
has
been
adopted
and
you
all
have
published
a
a
working
group
version
at
this
point
right.
B
It's
still
listed
in
the
documents
as
the
original
sort
of
eminem
named
document.
So
it's
not
even
it's
not
listed
as
draft
ietf.
Yet
so,
okay,
yeah,
I'm
sorry!
Well,
I
have
to
get
that
updated.
A
Yeah,
I
I'm
sorry
I
switched
it
with
it
is
kind
of
late.
I
switched
it
with
the
in
my
mind
with
one
that's
in
the
ntp
working
group
where
they
had
had
done
the
update.
So
that's
great
okay.
A
So
next
is
the
sac
architecture
we
do
have.
Let
me
get
these
switched
out.
A
So
bill
or
adam,
I
don't
know
which
one
of
you
is
going
to
talk.
B
My
huge
side,
yeah
yeah
so
I'll
just
say
it's
pretty
much
the
same
updates
that
we
represented
at
the
at
the
interim.
No
other
work
really
has
been
done
on
it
since
then,
again,
to
reiterate,
we
we've
addressed
most
of,
if
not
all
if
they
hadn't
been
changed
already
and
fixed.
The
iris
comments
from
the
previous
previous
reviews
a
lot
of
formatting
improvements
in
there
with
better
tables
and
descriptive
elements
and
stuff
section.
B
Four
got
a
lot
more
fleshed
out
with
a
number
of
the
different
component
interactions
and
section
five
got
a
lot
more
improvements
again
of
the
different.
You
know,
sort
of
topic,
naming
and
outlines
of
the
different
operations
and
kind
of
placeholders
for
the
different
information
elements
that
needed
to
be
put
in
there
for
each
operation.
B
So
all
of
those
still
need
to
be
kind
of
built
out
with
the
different
data
that
would
kind
of
be
passed
through
the
different
topics
and
endpoints
and
again
roman
did
a
kind
of
a
very
thorough
review
with
which
resulted
in
a
large
number
of
comments
that
we
have
not
gone
through
and
addressed.
B
B
A
A
Or
adam,
do
you
want
to
say
something
or
dave?
Did
you
want
to
ask
a
question.
A
So
bill:
do
you
have
a
sense?
Let
me
close
some
of
these
chat
boxes
that
are
opening
up
on
me.
B
We
definitely
that
there's
a
fair
amount
of
work
still
to
be
done
again.
Kind
of
addressing
all
of
roman's
comments
would
be
the
first
thing
and
then
a
lot
of
the
the
different
information
elements
that
would
go
in
in
each
operation.
In
section
five,
maybe
that's
part
of
the
comments
but
yeah
there's,
there's
there's
a
fair
amount
of
work
still
to
go.
A
Okay,
any
questions
or
comments
on
the
architecture
document.
F
Hey
bill,
I
mean
I
have
some
nits
in
the
current
document,
but
I'm
loath
to
kind
of
put
that
out
there
until
you've
kind
of
tackled-
maybe
some
of
roman
stuff,
but
I
don't
really
have
I
mean
roman's
got,
I
would
say
more
structural
type
comments
and
I
think
those
are
more
valuable.
I
have
one
structural
comment:
how
do
you
want
me
to
deal
with
them.
B
F
I'm
probably
going
to
hold
off
on
the
nits
and
just
talk
about
my
one
kind
of
structural
comment:
okay,.
A
A
Okay,
so
the
whichever
author
wants
to
speak
to
these
okay,
there
you
go.
C
Are
you
here?
Yes,
thank
you
so
much
karen
okay,
I
see
my
my
slides
in
this
screen.
K
H
I
will
it's
that
I'm
on
your
titles.
I
mean,
if
you
can't
see.
C
A
Okay,
well
we're
on
we're
on
your
first
slide.
Are
you
ready
to
move
to
your
second
slide,
yeah.
C
Okay,
thank
you.
This
document
suggested
a
light
weighted
vulnerability
record
because
in
the
work
of
continuously
secure
security
monitoring,
if
the
same
vulnerability
of
the
same
host
is
not
fixed
in
time,
multiple
records
will
be
generated
and
the
more
frequent
the
detection
holds.
The
more
vulnerability
records
will
be
generated.
C
Repeated
vulnerability
records
will
waste
the
storage
space
and
increase
the
cost
of
data
analysis.
So
this
documentary
proposes
this
light,
weighted
vulnerability,
recording
methods.
C
We
defined
several,
we
define
several
things
to
carry
the
information,
including
ip
address,
port
service
protocol,
vulnerability,
name,
vulnerability,
status,
vulnerability,
detected
time
and
update
time,
fixed
time
and
the
vulnerability.
C
The
vulnerability
detected
time
is
the
time
stamp
that
detects
the
vulnerability
first
time.
So
is
the
it
record
the
first
time
when
we
let
me
detect
it
that
this
is
a
variability.
A
Okay,
can
I
interrupt
for
just
a
moment
please,
okay,
the
the
meat
echo
support
people
are
suggesting.
Are
you
in
presentation
view
the
it's
the
first?
A
If
you
look
at
all
those
squares
across
the
top,
it's
the
first,
it's
the
first
one
on
the
left.
C
Is
nice
and
the.
A
So
over
on
the,
if
you
go-
and
maybe
I
should
just
continue,
if
you
go
to
the,
if
you
go
out,
you
see
where
it
says:
ietf,
109
and
sackum
and
then
goes
straight
across.
You
see
that
first
square
that
has
like
a
little
head
and
then
a
box.
C
Okay,
the
third
one,
the
third
page.
A
A
C
It
is
the
once
it
is
detected
that
the
vulnerability
has
been
fixed.
We
will
record
at
this
time
and
once
the
vulnerability
has
been
detected
and
fixed,
we
will
set
vulnerability
status
from
from
one
to
zero,
since
one
is
vulnerability
exists
and
the
zero
is
is
vulnerability,
fixed.
C
And
there
is
another
time
vulnerability
update
time.
C
It
represents
the
latest
update
time
when
detect
many
times.
The
last
the
latest
time
test
stamp
will
be
recorded
to
cover
the
order
record.
C
C
Fun
vulnerability
record
generated
every
day.
The
record
you
like
the
slides
in
the
left.
C
I
posted
a
picture
in
slide
in
slide
three
and
in
the.
C
C
C
C
For
for
each
vulnerability,
only
one
record
will
keep
and
is
much
more
easier
to
analyze
this
vulnerability
data.
Yes,
that's
that's
all
for
this.
A
Document,
okay,
does
anybody
have
any
questions.
I
I
Yeah,
I
know
I
I
mean:
is
there
any
existing
standard
about
the
non-lightweighted
vulnerability
record
because
you
want
to
have
some
changes
to
the
non-light
weighted?
So
I
I'm
curious.
Is
there
any
existing
standard
of
the
non-light
weighted.
C
You
release
the
song,
vulnerability,
scan
tools,
you
use
so
many
storage
or
so
many
data
to
record
some
sound
information
repeated.
So
I.
I
Document,
yes,
I
the
reason
I
asked
the
question
is
because
you
in
the
draft,
you
first
mentioned
the
non-lightweighted
record,
and
then
you
mentioned
how
to
improve
the
non-lightweighted
array
code.
So
if
there
is
no
existing
record
about
the
non-line
widget,
I
think
you
just
need
to
write
up
write
a
full
document
introduce
all
the
elements
in
the
records
you
mentioned
in
the
lightweight
vulnerability.
B
I
Also,
I
have
another
question
I
kind
of
feel
like
they.
This
is
an
intern
internal
implementation
issue.
Yes,
I
don't,
I
don't
think
it's
an
interoperability
issue,
so
I
don't
think
it
is
appropriate
to
standardize
this
work.
I
You
mean
I
mean
about
the
interaction
between
devices
between
network
devices.
B
G
This
is
dave,
holtzmeier
is
the
is
the
intent
for
developing
this
lightweight
vulnerability,
reporting
format
so
that
tools
that
generate
vulnerability
reports
would
be
able
to
share
that
information
with
tools
that
would
consume
those
vulnerability
reports,
and
if
that's
the,
if
that's
the
use
case,
then
you
know
there
could
be
value
in
standardizing
this.
G
G
On
but
but
then
I
think
if
that
is
true,
the
larger
question
is
the
second,
the
right
the
right
place
to
do
that
work.
G
Yes,
because
I'm
not
certain
that
this
is
something
that
we've
been
chartered
to
do.
Is
there
a
reason
why
you
submitted
this
draft
to
saccum?
Why
you
thought
sakham
was
the
right
place
to
do
this
work.
C
C
C
E
Hi
li
jang,
thanks
for
your
bringing
your
your
draft
to
the
working
group,
I
had
a
similar
question.
I
think,
to
what
was
asked
by
the
two
previous
speakers,
which
is
I
I
didn't
fully
understand
how
broad
of
a
set
of
information
elements
you
wanted
to
include.
Is
it
as
simple
as
you're
roughly
describing
in
this
example,
or
do
you
envision
a
much
richer
vocabulary
in
my
head
back
to
what
we
pan
was
talking
about
things
like
oval
and
iodef?
E
Sci
have
have
have
some
of
these
information
kind
of
elements.
So
I'm
trying
to
understand
how
how
what's
talked
about
here
overlaps
overlaps
kind
of
with
the
discussion
here,
if
you
have
a
sense
for
that.
C
Oh,
we
only
do
this
work
to
to
the
hosts
or
servers
that
are.
C
So
actually,
the
most
important
thing
of
this
document
is
not
about
vulnerability,
information
collection
or
some
other
internet
information
connection
is
a
is
a
way
to
record
vulnerability
and
then
to
improve
the
security
level
of
a
company's.
A
A
Okay,
so
I
I
think
at
this
stage
there
have
been
there's
been
some
good
questions
asked.
We
probably
ought
to
take
further
discussion
to
the
mailing
list.
I
think
I'm
hearing
that
there's
questions
about
whether
this
is
actually
within
the
sakham
scope
or
not.
A
A
A
So
the
the
slides
for
the
last
presentation
are
not
up
in
materials
but
I'll
get
them
loaded.
I
got
them
a
bit
late,
so
they're
not
listed
up
there.
So
the
next.
A
Thing
is
a
discussion
of
way
ahead.
What
we
think
our
next
steps
are,
the
we
we
have
coastwood,
which
we
think
is
going
to
be
four
to
six
weeks
to
resolve
all
of
the
ad
comments.
We
have
the
roley
configuration
checklist
which
is
meeting
bi-weekly
and
will
get
us
a
working
group
draft
published
sometime
soon.
A
You
know
for
better
for
worse,
we
seem
to
make
more
progress
and
meet
deadlines
when
we
have
meetings.
So
I'm
thinking
somewhere
from
the
middle
of
january
to
the
middle
of
february,
we
should
probably
have
a
virtual
interim,
maybe
middle
of
january
middle
of
february
is
too
close
to
march.
L
Hey
how
about
that
all
right
yeah!
I
think
that's
probably
a
good
idea
yeah.
We
just
need
to
get
it
scheduled
and
like
specifically
for
the
architecture
draft
and
bill.
Sorry,
if
I
am
overstepping
in
some
way,
you
know
I
know
I
provided
feedback.
I
know
roman
provided
feedback,
I'd
like
others,
to
provide
feedback
as
well.
If
we
can
and
then
then
I
think
we're
willing
to
keep
moving
forward
with
the
draft.
A
Right,
I
think
we
are
as
long
as
it's
making
progress.
I
think
the
the
conversation
we
had
had
prior
was
that
it
wasn't.
It
didn't,
look
like
it
was
getting
to
a
consensus,
but
it
seems
to
be
moving
in
the
right
direction
now.
E
Just
to
be
clear,
what
we're
effectively
saying
is
that
on
deck
we
have
the
we
have
the
coast
with
document.
That's
almost
wrapped
up
we're
going
to
continue
progressing
and
buttoning
up
the
really
config
checklist
and
the
architecture
document,
and
the
open
question
is:
is
there
anything
more
for
us
to
do
after
that?
Correct.
A
Okay,
so
we'll
chris
and
I'll
send
out
a
doodle
poll
for
some
time
middle
to
end
of
january.
A
A
Okay,
and
with
that
that
brings
us
to
the
last
agenda
item,
is
there
any
other
business
anybody
would
like
to
discuss?
Oh,
I
see
a
chat
message.
A
I
guess
our
our
note
to
self
is:
we
probably
should
have
requested
an
hour
instead
of
two
hours
with
that.
I
believe
we
are
done.
A
Thank
you
everybody
for
for
attending
and
please
comment
on
the
mailing
list,
because
that's
how
we
get
things
done.