►
From YouTube: IETF102-SACM-20180720-1150
Description
SACM meeting session at IETF102
2018/07/20 1150
https://datatracker.ietf.org/meeting/102/proceedings/
C
D
F
C
B
C
H
B
Okay,
welcome
to
the
last
session
of
the
last
day.
I
B
J
H
B
K
B
I'll
change
it
on
here:
okay,
I'm,
not
gonna
change
it
on
the
agenda
mean
I.
Think
we
can
all
remember
that,
possibly
maybe
I
don't
know
it's
Friday
I'm,
not
remembering
much
of
anything
any
other
agenda,
bashes
excellent,
so
status
of
the
working
group,
as
you
will
have
seen,
the
Schwimmer
document
got
published
and
it
is
RFC
84
12!
Congratulations
to
the
authors
and
everybody's
persistence.
H
Did
so
so
Schwimmer
is
on
the
standards
track
in
order
for
it
to
advance
on
the
standards
track.
There
have
to
be
two
independent
implementations
and
we
have
to
do
an
interrupt
test
and
I
was
hoping
that
authors
or
other
parties
might
have
some
comment
as
to
a
plan
for
that
I'm
willing
to
kind
of
support
that
Interop
test
wherever
so.
If
there
is
a
plan
for
an
interrupt
test
so
that
we
can
move
that
forward,
that's
fine!
Otherwise
it
will
just
stay.
It
won't
advance
on
the
standards
track
they
as
an
RFC,
so.
A
This
is
Charles.
We've
got
two
efforts
going
forward
on
drea
Stefan's
got
strongswan.
In
fact
it's
it's
been
published,
I
believe
or
is
in
the
process
of
being
published,
with
swimmer
compliance
in
there
and
there's
another
independent
effort
going
on
by
Carl
Heine's.
So
hopefully
we
we
might
be
able
to
do
that.
I,
don't
have
a
timeline
for
the
for
Carl
Heinz's
work
at
this
point.
I
am
an
email.
C
L
L
The
the
yang
model
expressions
have
been
really
good
at
detailing
the
the
stuff
that's
has
been
collected,
but
but
not
necessarily
describing
what
to
collect
sort
of
in
a
generic
way.
Instead
of
a
specific,
you
know,
I,
you
know
attribute
value,
you
want
to
kind
of
express
a
way
to
generically
say:
go
get
me
something
from
a
registry
location
or
something
like
that.
So
we
kind
of
created
a
very
simple
model
that
can
express
the
the
information
that
we
wanted
be
collected
from
an
endpoint
wrote
up
a
little
bit
of
code.
L
Again,
it's
a
very
small
amount
and
was
fairly
hard-coded
to
specific
things
that
we
had
put
together
and
started,
creating
a
bit
more
specific
yang
models
to
express
those
characteristics
from
from
a
we
started
with
a
Windows
box
so
and
of
taking
things
like
password
policies
and
user
rights
assignments.
Things
like
that
that
are
specific
to
Windows
and
and
created
some
some
basic
models
around
that
the
generic
sort
of
collection
model
was
used
to
kind
of
dry
drive
the
the
code
that
we
wrote
to
kind
of,
collect
and
and
and
express,
though,
that
windows
size.
L
L
L
You
know
in
in
in
other
working
groups
like
net
confident
how
they
have
that
accomplishes
those
those
tasks
for
collection
of
those
specific
endpoints
and
I
think,
instead
of
it
being
somewhat
specific,
being
more
sort
of
generic
in
nature
to
to
kind
of
define
that
and
our
github
repo
is
right.
There
French.
M
L
The
idea
was
kind
of
to
determine
the
applicability
to
do
it.
To
do
that,
you
know
we.
You
know
we
have
some
of
the
stuff,
that's
kind
of
define
you
with
oval
and
and
collection
methods
like
that
wanted
to
see
if
we
could
kind
of
port
that
over
in
a
sense
and
express
that
in
in
yang,
since
it's
seems
sort
of
pervasive
throughout,
though
so.
L
In
the
I'll
say
in
a
small
amount
of
progress
that
I
think
we
we
actually
made,
it
was
pretty
effective.
The
the
collection
mechanism
we
defined
is
a
very
small
model
and
it
would
be
up
to
implementations
to
be
able
to.
You
know
to
kind
of
interpret
that
so
there's
a
bit
of
complexity
there
to
you
know,
keep
the
model
really
generic.
It
makes
it
a
little
bit
more
on
the
implementation
to
to
do
stuff
and
I.
L
Think
that
you
know
it
it's
worth
exploring
something
similar
to
what
you
guys
did
with
the
network
device
models
yeah
yeah
to,
because
that's
that's
fairly
specific
information
and
it
kind
of
in
reading
some
of
those
drafts,
I
kind
of
it
kind
of
tweaked.
My
thinking
about
some
models
like
that
to
express
that
same
information
for
another
end
point
so
yep.
M
So
I'm
thinking,
maybe
next
time,
if
we
can
support
them
remotely
way.
Tester
we
have
some
some
cloud-based
test
environment,
sure
if
they're
connected
to
then
so
we
we
can
also
join
your
integrity,
testers,
okay,
yeah,
that's
yeah!
My
last
question
is
right:
now
all
your
information-
oh,
oh,
oh
over
to
you
are
doing-
is
collect
information.
So
in
yunkai
to
know,
though
they
are
all
the
reader.
Only
information,
yeah
right,
okay,
okay,
yeah!
Thank
you!
Yeah.
L
N
Hi,
this
is
Hank
under
my
jaw,
sorry
and
the
box,
and
this
is
a
short
update
about
the
work
we
do
on
the
terminology
document.
For
second,
we
started
branching
the
document
in
an
effort
to
reconciliate
some
changes
and
basically
enforced
a
better
pet
hunt
for
every
term
definition.
This
was
started
by
Adam.
Thank
you
very
much
for
that.
We
also
have
a
project
now
on
the
github
page.
That
basically
is
addressing
each
issue
appropriately
like
it's
on
the
leg.
It's
for
discussion,
it's
in
discussion
and
resolved.
This
is
actually
working
out
great.
N
Reconciliation
we
are
talking
about.
There
was
a
huge
cut,
basically
the
culling
of
terms,
and
then
we
had
to
argue
how
and
why
to
bring
some
of
them
back.
So
there
is
a
better
rationale,
know
why
some
of
these
terms
are
included
and
some
are
not
included.
I
will
not
go
through
I'll
hold.
If
that
would
be
a
little
bit
it's.
The
second
bility
is
about
how
we
structure
it
now.
So
we
start
with
what
most
people
want
a
very
concise,
spot-on
definition.
N
Sometimes
it's
a
reference,
but
the
term
is
so
vital
to
the
work
we
do
here
that
we
actually
highlight
it
again
as
a
reference
in
the
terminology
draft,
and
then
it
is
followed
by
expositional
checks
and
other
paragraphs
that
somehow
explain
like
declarative
guidance
halls
is
used
here.
Why
is
this
important
and
basically
gives
more
information
about
other
terms
and
their
relationship
yeah?
N
Unfortunately,
and
our
proposal
would
be
to
narrow
it
down.
The
first
idea
is
very
simple:
we
just
prefix
it
with
IT
an
IT
I
said
this
would
still
include
passive
cables
and
patch
fuse
and
such,
but
but
maybe
we
just
have
some
exponential
text
and
saying
it's
active
equipment
that
requires
energy
and
then
we're
done
with
that.
Maybe
even
some
I
don't
know
installation,
media
and-
and-
and
maybe
maybe
that's
good
enough,
because
we
were
I-
know
grinding
this
term,
for
it.
N
Just
now,
and
doesn't
really
make
any
sense,
so
I'm
asking
the
group
right
now
is
everybody
everyone
against
removing
s?
Finally,
an
including
asset
management.
Finally,
but
retaining
hardware
and
software,
the
management
of
hardware
and
software
components,
which
is
maybe
even
the
term
I
TS
set
if
you
really
read
fit,
but
I
would
also
remove
that.
Actually,
so
what
everybody
be
ok
with
removing
asset
as
a
term
entirely
from
the
documents
and
just
retain
how
four
components
and
software
components
thank
you.
So
we
will
start
it
off,
maybe
not
something
I.
O
N
N
That's
an
issue:
that's
a
good
question:
do
we
need
to
define
time
stems,
are
very
defined
by
49
49
and
no,
we
do
not
have
to
redefine
them.
That's
apparent,
but
again
we
reference
them
and
give
expositional
text,
because
time
stems
are
specific
importance
to
the
second
automation
process,
because
it
is
about
correlating
collection
provenance
like
if
you
collect
a
few
different
endpoint
attributes
at
the
same
time,
and
this
might
constitute
a
specific
threat
that
is
exploited
or
an
attack
that
is
happening.
So
some
is
some
some
characteristics
of
time.
N
Stamps
should
be
highlighted
and
the
intended
use
and
via
the
writer
I,
have
the
always
to
be
included
in
second
statements
should
be
elaborated
on,
but
this
will
be
very
concise
because
this
is
basically
an
architectural
feature
and
should
go
into
the
architectural
document.
Ultimately,
unless
do
we
have
an
active
one?
No
I,
don't
think
so
so
I'm
it
will
remain
here.
N
N
N
I'm
running
through
this
I
know:
okay,
we
have
a.
We
have
a
very
known
set
of
things.
We
want
to
manage
pretty
much
this,
our
own
or
company
own
or
entity
or
organization,
also
associated
endpoints
target
endpoints,
and
then
we
have
this
typically
bring-your-own-device
stuff
or
some
unknown
devices.
Rope
access
points
even
just
stop.
He
sees
that
are
unknown
and
the
second
procedures
will
be
able
to
discover
and
find
them,
but
they
will
not
know
how
to
label
them.
So
what
we
are
building
is
an
ohm
I.
Remember
the
wrong
slide
right:
okay,
sorry
I'm!
N
Not
talking
about
this
light,
actually
I'm,
sorry
about
every
finish
this,
and
so
we
have
the
endpoint
characterization
profile
and
they
record
sorry
the
endpoint
characterization
record,
and
if
you
encounter
something
like
a
mecha
dress,
there
is
no
management
database
or
an
authentication
attempt
of
a
user
that
is
reoccurring
and
in
somehow
can
use
a
service,
but
it's
not
over
documented.
So
somebody
edited
many
way.
Partly
this
will
be
recorded
and
a
great
decorated
in
something
that
is
associated
with
this
entity
that
we
can
see
over
and
over
again.
N
So
if
there
is
a
smartphone
that
is
using
the
guest
network
on
the
regular
basis,
we
will
at
some
point
can
profile
it,
and
every
of
this
profile
characters
will
be
aggregated
in
this
endpoint
characterization
record
again.
This
is
about
identifying
target
endpoints
that
are
not
under
your
own
control.
This
is
a
bit
out
of
scope
in
the
respect
to
the
tools
and
the
procedures
that
facilitate
we
will
define
the
information
that
is
vital
to
this
characterization
process.
N
P
O
There's
some
confusion,
at
least
in
the
github
chain,
on
attribute,
and
what
that
really
means,
and
in
the
github
chain.
There's
an
assertion.
I
think
that
you
made
at
some
point
that
an
attribute
is
equivalent
to
an
attribute
value
pair,
which,
to
me
says
that
attribute
has
value
value
is
an
attribute
we
are
does
is
is
not
intuitive
to
me
at
all,
attribute
has
value
value
like
that
sentence
in
the
third
bullet
right
there
right
after
the
the
:
that
attribute
has
value
value
would
actually
be
equivalent
to
attribute.
This
is
domain
range
object.
N
Here,
but
it's
it's
I
I,
don't
think
it's
it's
right,
so
once
upon
a
time
yeah,
which
means
I.
Think
two
years
ago,
we
agreed
upon
that
the
information
model
has
two
primary
structures
which
are
containers
and
leaves
the
leaves
call
attribute,
and
they
are
a
VPS
yes,
but
we
are
calling
the
attribute
was
the
consensus
of
the
group
and
the
containers.
We
would
call
subjects
again.
There
was
a
very
long
discussion
about
this.
Nobody
was
really
happy
with
the
compromised.
N
That's
because
it's
compromised,
okay
and
that's
what
we
decided
on
both
of
them
are
information
events.
One
of
them
are
composite
information
events
and
one
of
them
was
atomic
information
elements
and
that's
the
current
terminology.
We
can
change
it
again.
I,
don't
I,
have
no
strong
opinion
about
it.
I
wasn't
happy
with
it,
but
was
a
consensus.
I
Nancy
came
with
it,
so
yeah
we've
had
lots
of
debate.
We
just
need
to
like
stick
to
one
so
I
mean
I'm.
Okay.
But
to
reiterate
what
Hank
said
we
debated
all
of
this
at
length
and
if
I
recall
the
attribute
is
the
atomic
yeah.
We
were
referencing
it
as
an
attribute
value
pair
value
pair,
meaning
you
need
to
put
some
kind
of
label
so
that
you
know
so.
You
can
attach
a
semantic
meaning
to
the
value.
Q
R
Bright
Jordan,
I
didn't
voice
an
opinion
throughout
the
discussion
and
the
argument,
because
I
have
a
very
strong
opinion
that
maybe
not
be
too
popular
but
I.
R
Think
too
often
when
we
get
into
naming
and
we
get
into
these
structures
and
we
get
into
the
stuff
we
get
into
a
really
pedantic
kind
of
down
in
the
weeds,
and
we
get
so
far
down
in
the
weeds
that
we
forget
that
there's
oxygen
up
above
and
that
people
outside
of
the
twenty
thirty
people
that
are
designing.
This
actually
have
to
read
and
understand
this,
and
sometimes
I,
think
that
maybe
slightly
less
pedantic,
less
precise
terms
that
are
more
readily
understandable
by
the
masses
is
a
better
way
and
of
comment.
R
Just
because
I
know
how
far
down
the
weed
stuff
these
arguments
and
yeah
I,
just
as
a
general
rule,
I
think
when
we
a
bunch
of
us
technical
people
and
we
get
very
passionate
and
we're
very
super
concerned
about
the
absolute
precision
of
a
term
but
in
the
reality
is
in
the
four
billion
people
that
need
to
read
this
they're
not
going
to
understand.
So
we
should
like
bubble
it
up.
So
something
don't
believe
I
ever
full
of
custom.
N
P
Yeah
they've
camp
in
SA,
I,
guess
I'm
coming
to
this
late,
but
I
agree.
Certainly
we
want
to
make
it
understandable
and
intuitive
if
I'm
missing
the
controversy
on.
Why
attribute
is
not
intuitive
I
mean
if
you've
got
an
email.
An
email
has
a
subject
attribute
yes,
sender
attribute
a
timestamp
attribute
each
instance
of
an
email
message
will
have
a
particular
value,
but
I'm
not
I'm,
not
understanding
what
the
problem
with
having
a
name
and
a
value.
N
N
O
N
O
H
O
H
N
H
N
R
I'm,
just
introducing
you
sorry
Bret,
Jordan
yeah,
so
I
don't
have
any
issue
with
working
with
github
and
I.
Think
that's
a
great
way
to
do,
because
it
provides
some
sanity
to
the
madness
that
can
exist
through
email
discussion.
My
only
thing
is
I'm,
somewhat
OPD,
and
so
as
long
as
we
do
really
good
like
labeling
and
structure,
and
so
people
can
find
things
and
we
can
sort
in
order
and
organize
them
yeah.
Then
you
can
add
new
labels
and
even
add
colors
to
them.
Yeah
I
know
you
can
and
and
I
think.
R
N
O
O
All
right
cool
so
from
zero,
zero,
two
zero
one.
These
are
basically
the
changes
we
made
instead
of
saying
that
we
have
an
architecture
we're
trying
to
have
that
draft
focus
on
the
discovery
of
one
basically
centered
on
hackathons
that
we've
done
in
the
past.
We
did
add
text
about
sack
of
roles.
We
added
information
about
components,
capabilities
interfaces
and
workflows,
more
or
less
completed
in
appendix
mapping
to
our
use
case
document
RFC,
82,
48
and
added
an
appendix
of
example,
components,
and
this
is
a
pretty
short
deck.
O
We
just
have
a
bunch
of
questions
so
how
many
people
have
read
the
zero
one?
So
a
few
people?
Okay,
the
questions
that
we
have
at
this
point-
and
maybe
the
last
one-
is
most
relevant
from
the
group's
perspective,
but
I
mean
to
stay
in
whether
or
not
the
taxonomy
that
we
have
in
place,
and
there
is
like
about
right.
Is
it
on
the
right
path?
Are
the
workflows
that
we've
identified?
O
You
know
we
have
a
detailed,
the
workflows
yet,
but
we've
labeled
them
right,
we're
trying
to
start
to
define
what
those
workflows
would
be
or
those
about
right
are
the
mappings
in
Appendix
A
about
right
and
do
you
find
the
work
useful
because
we're
happy
to
continue
it?
But
if
it's
not
useful
to
anybody,
then
maybe
we
don't.
N
Hi,
this
is
ink
from
the
floor.
We
are
in
dire
need
of
an
architecture
because
lint
is
aggregating
in
the
terminology
which
should
go
there.
Also
regarding
roles,
I
I'm
a
little
bit
sad
to
see
only
very
specific
roles
for
components:
I,
the
the
beauty.
Sorry,
the
elegance
of
having
the
provider
and
consumer
roles
enabled
a
very
flexible
composition
of
second
components.
Now
every
component
has
to
have
a
specific
task
to
it
and
there's
no
guidance
how
to
create
your
own
second
components.
N
So
what
I
would
like
to
see
is
to
maybe
revive
that
control,
plane
concept
of
how
you
find
a
component
discovered
at
earlier
data,
so
this
and
having
the
consumer
and
provider
of
information
model
applied
both
to
the
control
plane
functions
and
the
data
plane
functions
that
other
machine.
That
is
the
second
automation
composite,
because
at
some
point
I,
don't
I.
Don't
think
that
we
should
force
people
to
write
a
standard
or
an
RC
to
it.
N
Just
another
role
right
and
the
the
earlier
model,
the
first
model
and
enable
basic
the
universal
composition
by
definition
of
functions
and
capabilities.
And
now
this
is
all
more
glue
together,
which
is
more
comprehensible
to
the
early
reader.
So
the
learning
curve
is
not
as
big
but
on
the
other
hand,
you're
really
restrained
you're
restricting
yourself
here
and
maybe
a
little
bit
unnecessary,
I
think
so
it
to.
O
There
was
a
the
first
bullet
in
that
section
says
that
providers
and
consumers
need
to
come
to
some
agreement,
semantically,
on
what
topics
are
available
and
I
think
it
follows
from
that:
not
only
what
topics
are
available
but
how
you
interact
with
those
talking
topics
like
what
you
expect
to
see
from
those
topics,
what
operations
you
can
perform
over
those
things
and
that
stuff
I
think
that
when
we
talk
about
capabilities
workflows,
you
know
like
tool,
capabilities
things
like
that.
We
would
want
to
define
here
and
I.
O
Think
that's
getting
more
to
what
you
were
just
talking
about
in
terms
of
roles.
So,
yes,
we
would
not
want
I,
don't
think
we
would
want
a
new
RFC
just
to
define
a
new
role.
Instead,
I
would
like
a
mechanism
where
somebody
can
define
a
new
role,
how
to
interface
with
that
role.
Where
that
goes
item,
not
sure
you
know,
I
Ana
table
over
at
XMPP
lay
on
whatever
that
might
be.
Okay,.
N
I
The
way
I
interpret
the
draft,
the
current
draft
that
is
live,
not
the
stale
one
is
basically
an
instantiation
of
the
abstract,
but
perhaps
not
as
complete
and
again
I.
Don't
want
to
rehash
all
of
the
arguments
that
from
the
past.
But
it's
the
notion
of
you've
got
collectors
and
evaluators
and
I
forget
the
other
to
me,
trolls,
which
I'm
not
seeing
explicitly
called
out
in
this
draft,
so
I
think
I,
guess
I
would
put
more
editions
or
bring
not
the
whole
parked
draft.
I
Okay,
then
draft
just
to
put
the
context
of
the
whole
intent
and
then
here's
the
exemplars
right.
O
S
O
Know
I'm
happy
to
I'm
happy
to
update
the
draft
right
and
and
see
what
we
can
do
about
merging
is
the
right
thing
whatever
that
is
right,
but
that
seems
to
imply
that
the
the
questions
you're
asking
seem
to
imply
that
a
draft
like
this
is
useful,
that
we
should
continue
this
work
at
some
level
and
possibly
start
even
elevating
it.
A
little
I,
don't
know
if
that's
very
term
but
whatever.
I
Yes,
so
so
at
some
point
we
had
talked
about.
How
do
you
begin
to
do
a
posture
assessment?
How
do
we
begin
to
do
the
posture
collection
right
right,
which
is
why
we
said?
Oh,
we
need
the
requirements.
Well,
the
requirements
got
us
from
the
use
cases
anyway
to
how
do
we
begin
to
talk
about
the
notion
and
please,
let's
not
rehash
the
terminology?
I
K
Hi,
this
is
Steven
bang
hard
at
the
mic.
I
like
it,
it's
readable,
I
feel
like
I
could
hand
it
to
somebody
who
doesn't
know
all
of
this
stuff
in
their
head,
wouldn't
explode,
which
is
probably
the
point
of
having
a
document
like
this.
So
I
like
it.
Obviously,
it's
a
zero
one,
there's
stuff
to
add
there
stuff
to
do.
I
think
this
is
valuable
work.
I
think
this
is
useful
work
and
I
think
we
can
actually
get
a
lot
of
value
out
of
this
as
its
well.
K
B
I
I
mean
I
I
guess
I
should
have
stated
I
do
think.
We
need
something
like
this
because
right
now
the
current
drafts
that
are
moving
forward.
They
talk
about
just
software
inventory
and,
and
it's
like
okay,
what
do
I
do
with
this
sockem
is
about
doing
the
posture,
evaluation,
configuration
and
and
okay
now
what
I
do
with
these
drafts,
so
I
do
think
we
need
something
like
this
yeah.
B
B
O
The
third
bullet
on
there
on
this
previous
slide
here
is
really
what
you're
getting
to
like.
What
are
the
other
capabilities
order?
The
other
workflows
the
interfaces
we
need
to
worry
about.
I
just
want
to
say:
okay,
we
need
to
think
about
these
things
now,
let's
start
coming
up
with
the
taxonomy
for
these
right
in
a
way
that
could
be
extended
easily,
so
we
don't
need
new
RFC's
to
do
all
that
exactly
they're
cool
I.
B
N
B
B
A
Charles
I'll
be
your
Danny
Haines
and
Jessica
Fitzgerald
Mackay.
For
today
they
are
the
ones
who
are
actually
moving
this
document
forward,
but
unfortunately
they
couldn't
be
here
so
I'm
gonna
be
presenting
on
this,
which
means
I
will
be
documenting
any
questions
you
have,
but
I
will
probably
not
be
answering
any
of
them.
A
A
Danny
and
Jessica
have
made
multiple
updates
to
that
and
the
new
version
was
published
on
the
second.
It's
got
a
lot
of
improvements,
updating
scope
as
as
indicated
there's
now
a
lot
more
information
on
net
mod
rule
rest,
cough
yahng,
yahng
data
model
going
into
the
document,
so
those
have
been
folded
in
took
out
a
bunch
of
the
stuff.
This
was
originally
a
trusted
computing
group
document.
A
We
took
a
lot
of
the
material
out
assumptions,
requirements
and
stuff
like
that
that
are
not
typically
part
of
IETF
documents,
but
are
part
of
the
TCG
documents
and
then
more
focused
on
interaction.
Capabilities
of
the
NIA
stack
focused
a
little
more
on
data
collection
rather
than
the
the
previous
folks
should
focus,
which
was
more
on
evaluation,
so
we
haven't
removed
that,
but
now
have
a
lot
more
on
on
the
collection
so
going
on
to
the
next
slide.
A
K
This
is
Steven,
bang,
Hart,
I,
don't
have
a
question
or
a
comment.
I
wanted
to
give
congratulations
to
Charles
on
getting
the
swimming
RFC
published.
That
is
a
great
document
to
get
published
I'm
out
of
this
working
group
and
thanks
everyone
for
their
hard
work
on
it.
I
know
it
was
a
lot
of
work
to
get
through
the
RFC
editor
that.
A
M
A
It's
it's
not
my.
My
understanding
is
that
we
are
not
creating
a
new
yang
model
for
ECP
as
much
as
we
are
ECP
sort
of
a
high
level
description
of
how
a
lot
of
these
components
work
together.
So
it's
it's
integrating
how
yang
could
be
part
of
the
data
collection
process
rather
than
defining
a
new
model.
Does
that
answer
your
question.
M
K
Hello
is
Steven
bang
hard
up
in
the
box,
I'm
channeling
Dave
today
or
you
can
do
it
go
ahead
and
yeah
just
jump
in
if
there's
anything
to
do.
Yeah
I
have
a
small
sheet
of
Dave
thoughts,
so
I'll
try
and
answer
questions
off
of
my
sheet
of
Dave
thoughts.
If
I
cannot
answer
it,
I
will
write
it
down
and
then
turn
them
into
Dave
thoughts
later
okay.
So
this
is
an
update
on
the
concise
software
identifiers
draft
the
coast
would
draft.
K
N
N
Legwork
there
is
no
conception
of
probably
hear
something
just
has
to
do
it,
but
I
did
the
film
extension
instead,
so
I,
but
I
hadn't.
At
the
time.
With
this
ICF
meeting
yeah,
we
have
an
ice,
teeny
tiny
discuss
about
how
to
do
a
kind
of
any
attribute
with
CD
DL.
This
is
not
recommended,
so
we
have
a
specific
structure
here,
but
we
also
are
doing
CDI
working
class
call
and
a
specific
control
that
in
that
might
resolve
this
issue.
So
the
added
extension
points
might
get
a
very
elegant
solution.
N
K
So
these
are
the
three
issues
that
Hank
had
alluded
to
that
need
to
get
done
still
if
anyone
was
in
suit.
This
came
up
at
suit.
The
firmware
extension
has
been
pulled
out.
Well
is
going
to
be
pulled
out
of
the
coast,
wid
draft
and
then
moved
into
its
own
separate
document,
and
then
maybe
slash
probably
done
in
suit
I,
don't
know
what
that
status
is
on
that,
but
I
don't
know
if
you
want
to
talk
on
that
firmware
piece
of
all
Hynek.
This.
N
N
Also,
the
description
of
firmware
is
done
in
suit
and
we
as
I
understand
as
the
cpe
concept
in
escape
is
going
to
be
going
away
and
switz
will
fill
that
vacuum
and
if
CPEs
and
the
vulnerability
assessment
via
them
has
now
done
with
cold
sweats
and
vulnerable
assessable
them,
we
need
firmware
and
crosswords.
It
is
a
necessity.
N
So
this
is
what
this
manifest
is
about
as
an
extension
to
a
co,
sweat
that
will
be
done
in
suit
because
it
is
the
exact
same
semantic
content
than
a
suit
manifest
and
at
first
the
office
of
the
data
valid
but
upset.
But
although
I
reiterated
that
I
would
do
this
a
lot
of
times,
I
think
but
offline
and
discussions,
never
the
plan
for
everybody
was
ok
but
again
when
I
explained.
K
Yeah
and
Dave
had
off
that's
a
really
good
work,
I'm
glad
that's
getting
done
to
do
this,
this
manifest
stuff
and
it
kind
of
connected
over
to
suit.
So
thank
you
for
doing
that.
Ok,
I'm,
Dave
again
last
two
tasks
to
do
are
take
care
of
the
Ayana
registrations
and
then
also
clean
up
all
the
CDL
related
documentation
to
include
things
like
the
example
CDL
throughout
the
document
needs
to
be
kind
of
double-checked
and
make
sure
that
it
aligns
with
the
updated
schema
that
was
changed
in
the
most
recent
version.
K
H
N
Okay,
okay,
so
Citadel
is
very
stable
at
this
point
of
time,
Alexei
is
encouraging
to
address
only
the
issues
we
had
discussed
at
the
civic
working
group
right
now,
and
this
sounds
very
promising.
I
think
we
will
be
finished
in
about
three
months.
The
latest-
and
maybe
this
even
includes
a
black
working
group-
that's
called
earlier.
So
this
is
a
pessimistic
projection.
N
K
T
K
K
Yeah,
okay,
so
this
is
Steven
bang
Hart
at
the
mic,
as
Steven
bang
Hart,
to
talk
about
the
Rolly
software
description,
so
a
new
update
was
posted.
This
is
the
oh
3
version
of
the
document
and
I
apologize.
It
was
a
late
posting
on
Monday
I
think
so
the
document
has
been
updated
to
be
significantly
more
readable,
to
have
some
more
clear
and
explicit
requirements
that
really
kind
of
focus
on
making
it
as
interoperable
as
possible.
K
The
previous
version,
while
useful,
didn't
fully
enforce
a
lot
of
the
things
that
would
make
separate
implementations
really
just
automatically
work
together.
So
I've
tightened
up.
Those
requirements
made
sure
that
completely
separate
implementations
understand
the
same
semantics
from
the
same
data
formats
and
the
same
attributes
and
categories
and
all
those
things
at
the
moment.
There's
actually
a
requirement
written
using
the
media
type
of
Swit.
It
does
not
have
a
media
type.
We
are
in
contact
with
ISO
about
getting
a
media
type
registered
for
Swit
I.
K
Don't
think
that
we
have
to
wait
for
that
right
now,
as
soon
as
ISO
gets
to
the
point,
where
they're
confident
on
what
the
Muny
type
is
going
to
be,
we
can
standardize
around
that
I
think
fairly
confidently,
but
so
we'll
keep
an
eye
on
that
and
make
sure
the
group
is
aware
of
that
media
type
status
if
it
falls
through.
Of
course,
we
can
just
standardize
anyway,
on
whatever
we
want.
K
U
K
Iso
is
the
standards
body
that's
in
charge
of
the
slid
standard,
okay
and
so
there
as
the
organization
are.
We
want
them
to
do
and
organize
sponsored
media-type
for
their
standard
through
I
Anna,
so
they
are
in
contact
with
Ayane
to
do
the
media
type
registration,
I.
Think,
there's
just
a
good
deal
of
bureaucracy
that
has.
V
M
Aha,
we
are
just
over
a
single
question:
first,
the
Rory
extension
for
swid.
Yes,
what
does
this
means
mean
because
I
assess
maintaining
a
goatee?
Is
a
transport
protocol
Sipapu
and
how
to
carry
information,
but
swid
is
some
format
or
some
attributes'.
Yes,
so
cute
quickly
clarify
what
is
extension
sure.
K
So,
as
you
said,
a
given
Rolly
entry
is
just
kind
of
a
wrapper
for
a
thing
right:
it's
just
posted
on
the
internet
somewhere
and
it
exists
and
it
sits
there
and
then
inside
of
that
entry
is
a
series
of
metadata.
So,
for
example,
the
content
that
I
have
is
of
you
know
this
category
and
is
of
this
size,
and
it
was
updated
at
this
time
and
then
there's
just
a
link
inside
of
that
entry.
That
points
to
the
swift
tag
so.
K
Is
a
yes,
so
you
can
still
transport
Swit
over
Olli
without
this,
this
is
an
extension
that
enforces
useful
interoperability
when
two
implementations
want
to
talk
swig
with
each
other,
okay,
yeah
I
think
using
Rolly.
Yes,
so
we're
we're
happy
in
the
sense
that
we
feel
like
we're
done.
However,
we
would
really
love
more
feedback.
The
author's
request
is
to
do
a
last
call
to
generate
feedback.
That
would
be
my
my
request.
The
chairs,
thoughts
on
that
I.
H
K
Bonus
rolling
today,
only
the
Rolly
checklist
draft
received
an
update
as
well.
This
is
the
0
1
update,
there's
a
new
author
on
the
draft,
which
is
me
I'm,
working
with
Adam
and
Bill
on
getting
the
draft
completed
as
quickly
as
possible.
The
one
update
included
mostly
formatting
and
style
changes
throughout,
so
it
matches
the
more
recent
look
and
feel
of
the
other
extensions.
K
And
then
the
document
has
been
kind
of
frame
worked
out
with
a
couple
spots
that
are
still
2
do's
and
the
authors
are
going
to
work
and
fill
those
in
as
we
go
so
we'll
probably
have
a
more
substantive
kind
of
content
driven
update
for
this.
You
know
either
at
the
next
ithc
effort
at
an
interim.
If
we
do
one
of
those,
so
that's
all
I
have
I
mean
license
on
any
of
you.
Q
N
O
Q
V
V
This
is
changes
we
have
made
things
last
idea
of
meeting
and
for
the
they
have
many
drafts.
First
say
the
the
configuration
attributes
for
via
si
broadcast
traffic
suppression
function,
editing
the
layer
two
protection,
then
we
we
change.
The
other
name
is
for
the
for
the
trade
agreement
and
yum
yum
mop
modules,
and
then
we
added
more
the
private
haps
type
Singh
young
modules
and
our
optimizer
Yamoto
have
passed
as
a
young
very
very
date.
Okay,.
V
This
is
and
of
the
overview
of
the
updates
for
the
infrastructure
layer.
Draft
first
say
we
rewrote
the
introduction
part
to
make
it
a
motivation
and
the
structure
of
the
draft
more
clear,
and
in
that
then
we
optimized
as
they
didn't
they
date.
A
model
by
the
raters
are
written
rate,
then
redundancy
party
and
the
give
up
to
collect
as
a
confidential
information
and
in
last
her
we
also
complete
the
young
modules
for
integrity
measurement
and
the
groupings
of
work,
cryptographic,
algorithms
and
in
the
data
model.
V
V
In
the
cryptographic,
algorithms,
we
using
groupings
instead
of
our
containers,
so
that
other
modules
can
reference
the
algorithms,
the
directory
and
also,
we
add
a
lot
of
more
algorithms
into
each
of
the
core
group
in
such
yet
as
a
way
as
a
TSA
and
the
ECDSA
in
the
signature
algorithm
group,
we
add
th
nacd
aging,
the
exchange
group,
and
we
also
added
the
same
back
in
the
map
message:
authentication
code
group
in
the
key
management
part
we
just
referenced
a
predefined
director
ism
groupings
rather
than
specifies
acronyms
configuration
details.
Again.
Here
are
an
example.
V
In
the
heat
generation
stage
we
use
just
use:
okay,
okay,
dear
aviation
function,
core
ping
and
instead
of
list
of
other
other
attributes
again.
Okay
in
the
future,
we
will
continue
to
optimize
our
data
model
and
we
needed
to
complete
all
all
all
the
secure
the
base
right
blocks
for
for
not
only
that
they
happen,
but
also
that
you've
raced
actually
okay
and
we,
as
we
are
seeking
more
comments
in
the
working
group,
and
we
hope.
V
O
Had
a
de
Montmorency
on
us,
so
it's,
which
is
the
three
drafts
right,
there's
three
drafts
in
total
that
do
the
networks
Efrain
when,
when
I
look
at
those
I,
think
immediately
of
the
work
that
CIS
does
not
just
for
network
devices
but
for
traditional
computing
devices.
You
know
windows
boxes
things
like
that.
The
thing
that's
missing
is
the
actual
recommended
value
right.
So
you
guys
have
like
this
tree
of
configuration
items,
attributes
right
that
we
care
about
from
a
security
perspective.
O
Now
in
CIS
we
we
tend
to
update
those
kind
of
frequently
or
relatively
frequently.
So
the
question
I
have
at
this
point
is
with
Network
Devices.
Will
this
baseline
change
frequently
if
it
does
change
frequently,
then,
is
there
a
different
way
to
go
about
doing
this,
where
we
won't
need
to
grab
an
RFC
every
time
the
base
line
needs
to
change
so
that
we
can
be
more
dynamic
in
the
marketplace?
O
M
Yeah,
you
know
harvest
a
good
point,
I
think,
comparing
to
the
some
PC
or
computers
or
network
devices,
security-related
configuration
stages
are
relatively
stable,
so
here
we
will
not
to
have
Connery
I
can
I
I
can
say
that
most
of
the
configuration
permits
and
the
studios
specified
in
our
document
is
very,
very
stable.
It's
exist
along
here.
It's
just
data.
There
are
no
no
vendors
to
propose
it
as
a
as
a
write
node
or
to
collector
to
validate
a
security
security
Stadium.
U
Been
Caidic
so
in
light
of
Adams
comment,
it
was
sort
of
interesting
to
see
that
both
the
finite
field
and
elliptic
curve,
DSA
and
ACTH
were
added
because
and
I
feel
like
the
general
direction
that
we
in
ITF
are
going
is
that
you
recommend
the
elliptic
curves
and
we
do
not
really
recommend
the
finite
field
for
new
developments
and
whatnot.
So
there
could
be
a
balance
in
there
to
strike
as
well.
You
might
get
some
questions
from
ITF
last
call,
or
is
you
review
if
they
stay
in.
O
O
If
we
can
yeah
cool
say
we
have
NCIS
has
it?
You
know,
speaking
on
behalf
of
CIOs.
At
this
point
we
have
a
variety
of
different
what
we
call
benchmarks
the
configuration
profiles
for
a
variety
of
different
network
devices.
We
could
probably
work
together
on
that
to
see
like
how
do
they
map
to
does
this
map
to
all
of
those
that
we
have,
and
you
know.
M
Yes,
that
that
is
also
our
wish,
because
I
think
actually
for
us
this.
These
security
postures
are
very
stable
in
our
company
and
it's
to
be
like
some,
our
internal
internal
security,
a
baseline
for
our
company
devices,
and
we
also
discussed
with
some
other
vendors
like
24
and
Cisco,
some
other
people,
and
they
also
express
a
certain
interest
that
they
say
that
this
is
variable
direction
but
yeah.
So
we
work
on
lower
contribution
and
can
get
a
more
comprehensive
and
more
how
to
say
more
quantity
model.
P
I
I
guess
I'm
trying
to
understand
because
you
do
have
different
drafts
and
they
all
speak
to
a
security
baseline.
So
there
is
the
data
plane.
There's
the
management
plane,
there's
the
security
posture
of
the
specific
device,
and
especially
as
you
talk
about
network
there's
many
different
capabilities
within
each
capability.
I
You
have
different
security
capabilities,
so
I
guess
I'm
trying
to
understand
the
goals
of
that
draft,
what
it
means
for
it
to
be
a
baseline
and
then
my
punchline
is
how
that
can
become
relevant
to
sockem,
because
right
now,
as
I
read
through
them,
I,
don't
think
they're,
really
part
of
sockem
I
really
do
think
they're
part
of
I
to
NSS.
So
sorry,
this
is
Nancy
yeah.
M
I
I
can
understand
your
concern
yeah,
but
from
my
understanding,
I
think
is
also
doesn't
suit.
Shouldn't
go
to
item
SF
as
long
as
every
is
about
Aneta
security
functions
policy
moder,
but
this
is
about
the
security
posture
motor.
So
that's
why
we
proposed
this
work
in
issue
order
here,
but
I
understand
your
concern.
They
its.
If
you
remember,
we
have
discussed
the
pending
work.
We
want
to
extend
our
second
work
to
cover
the
network
devices
so
yeah.
We.
O
So
the
you
know,
the
network
device
itself
has
a
configuration
that
then
results
in
I.
Guess
the
realization
of
a
network
security
function,
I,
don't
know,
but
so
I
see
what
you're
saying.
But
at
the
same
time
like
we,
we
treat
posture
assessment
of
a
network
device.
The
same
way,
we
would
treat
posture
assessment
of
a
data
center
endpoint.
S
O
Other
thing
I
was
going
to
mention
is
about
the
work
being
in
sacrum
or
not
okay.
So
yes,
I
see
this
being
important
when
we
get
down
into
the
weeds,
something
that
bill
and
I
were
talking
about
yesterday.
Was
this
more
abstract
collection
description
like
of
what
to
collect?
So
how
are
we
gonna
describe?
How
are
we
gonna
organize?
What
to
collect
is
a
little
different
than
specifically
describing
what
we're
gonna
collect,
if
that
makes
sense
right.
O
I
B
Was
just
done
sorry,
I
was
just
doing
a
quick
time
check.
We've
got
like
10
minutes
left,
so
it
sounds
like
that.
There
is
interest
in
this
work.
There's
still
some
uncertainty
about
the
scope
of
it
and
where
it
exactly
belongs,
and
can
you
all
I
guess
you
all
have
been
exchanging
emails
on
this,
so
you
can
work
it
I
think
from
from
a
chairs
perspective.
One
of
our
concerns
thus
far
is
it
has.
It
seemed
to
been.
B
M
Yeah
yeah
yeah,
you
are,
you
are
right.
That's
why
I
we
already
talked
of
several
vendors
and
the
actuary.
We
some
guys
hadn't
come
here.
Actually
we
have
okay.
I,
understand
your
point.
We
will
have
more
discussion
and
have
more
vendors
during
this
work
to
to
make
it
more
applicable
across
different
plans.
Oh
yeah,
okay,
it.
B
Doesn't
need
to
be,
obviously
they
don't
need
to
come
here,
but
you
know
if
you,
if
you
you've
posted
a
recent
update,
so
send
an
email
to
the
mailing
list
again
saying
that
you
know
you're,
soliciting
or
views
and
any
comments
that
you
can
get
from
some
of
those
people
and
there's
other
organizations,
and
that
would
be
helpful
as
well.
Okay,
okay,.
W
Okay,
I'm
sorry,
so
this
is
no
final
part
of
the
security
baseline
work,
meaning
about
meaning
about
is
a
match.
Play
security,
oh
and
I.
Think
we
can
skip
skip
the
introduction
patch
and
just
to
remind
as
I'd
say
we
categorized
as
a
management
plane,
security
of
the
network
devices
into
four
sub
modules,
the
administrator
management,
security
and
system
management,
security,
lock,
security,
no
file
security
and
the
what's
new
in
this
new
version.
Thanks
for
Hanks
comments
and
suggestions,
we
have
made
some
modifications
in
the
introduction
patch
and
also
the
descriptive
text.
W
The
sub-modules
and
a
few
remain
issues
will
be
addressed
in
the
next
version,
so
the
many
modifications
in
this
version
is
about
as
administrator
management,
a
security
patch
we
refine
the
young
tree
and
provided
as
a
Chris
bonding
date
model.
So
for
the
administrator
security
policy
patch,
our
manager
will
be
many
included.
The
security
baselines
about
the
account
security
policy
and
the
password
secure
policy
such
as
weather,
the
weather,
to
check
the
complexity
of
the
password
and
also
the
forbidden
rules,
whether
it
is
set
either
for
the
password
configuration
and
also
it's
a
common.
W
It's
a
best
practice
that
we
usually
europe
lock
the
account
with
the
login
is
field,
and
then
the
second
patch
is
about
the
login
security,
so
is
the
contains
different
security
controls
on
different
login
channels
such
as
telnet
and
ssh,
and
third
party
is
about
the
triple-a
securities,
many
about
which
his
scheme
is
choose
and
the
corresponding
servers.
So
last
patch
is
the
statistics
about
about
user
online
or
the
mini
Streeters
and
does
IP
block
list.
W
So
next
we
will
update
the
other
three
sub
modules
in
the
draft
and
provided
the
corresponding
your
mode,
your
model
to
make
it
more
readable,
and
then
we
also
will
come
for
collaborations
from
other
vendors
and
and
the
last
is
we
choose
a
better
use
this
data
model,
so
we
all
consider
how
to
adapt
it
to
the
young
potion
mechanism.
So,
let's
hop.
B
B
Well,
but
anyway
we
should
yeah.
We
should
take
a
look
at
it.
The
second
thing
is
so
way
forward.
We
we
kind
of
slacked
off
a
bit
this
last
time,
but
we
would
like
to
have
some
virtual
interims
going
forward.
We
have
targeted
to
two
potential
time
frames
for
these
and
I'm
scrambling
to
find
where
I
wrote
them
down.
Okay,
so
we
were
looking
at
the
week
of
August,
20th
or
27th
for
the
first
one.
B
B
B
B
N
K
B
Well,
yes,
so
so
let's
do
this,
everybody
that
thinks
we
need
one
virtual
tenor
and
the
one
thing
is
I
do
think
we
don't
make
any
progress
if
we
don't
do
something
in
between
so
everybody
hum
for
one
virtual
interim
home
for
two
virtual
interims
wow
that
was
pretty
darn
effective,
alright,
so
we'll
figure
out
dates
on
that
one
virtual
interim
in
September
sometime
and
at
that
meeting
we
will
go
through
the
milestones
and
see
if
we
can
update
some
of
these
dates.
So
folks
be
thinking
about
those
anything
else.