►
From YouTube: IETF101-SACM-20180322-0930
Description
SACM meeting session at IETF101
2018/03/22 0930
https://datatracker.ietf.org/meeting/101/proceedings/
A
A
B
D
C
E
C
C
So
I
just
wanted
the
draft
addressed
because
it
had
been
updated,
so
I
wanted
to
alright
I
wanted
the
draft
addressed.
C
Swimmer
is
in
the
RFC,
editor
queue
and
other
status.
We
will,
as
we
go
through
here
when
we
put
together
the
agenda,
basically
everything
that
was
current.
A
current
working
group
draft
we
put
on
the
agenda
in
a
in
a
sense
if
it
was
something
we
wanted
to
know
the
status
of
so
so
and
then
the
other
question.
The
other
thing
that
was
on
the
slides
and
I
think
what
I'm
gonna
do
is
Adam.
Remember
the
conversation
I
had
with
you
about
the
terminology
document
I
said.
C
H
Yeah
Adam,
what
fell
terminology
to
after
a
bunch
of
us
met
agreed
to
put
a
bunch
of
things
back,
which
I
did
and
I'm
waiting
for
feedback
haven't
gotten
that
yet,
but
will
soon
I
expect
and
then
we're
gonna
go
through
all
the
issues
that
are
in
there.
So
the
status
is
that
we're
actively
working
on
it,
we're
trying
to
meet
once
a
week
how
many
issues
are
proximately,
30
or
so.
If
I
remember
correctly,
I'd
have
to
look
at
github
me
and
I.
Don't
keep
that
at
yeah,
fine,
but
30
years
of
good
answer.
F
Well,
sorry,
it's
already
very
late.
For
me
this
is
Hank
terminology
wise.
There
are
30
documented
issues.
There
are
a
lot
of
more.
We
had
a
general
refactor
that
Adam
very
honestly
now
on
earth
or
humility
like
midgets,
he
rephrased
every
statement,
so
that
is
a
first
paragraph.
That
is
a
definition
and
as
decoupling
as
the
introduction
rejects
says,
the
rest
is
expositional
text.
F
So
I
don't
went
to
the
complete
document
and
refactored
that
so
that
Jared
and
I
now
can
pick
up
the
explain,
the
expositional
text
and
refactor
that
a
little
bit
some
of
the
disturb
a
rough
around
the
edges.
So
that
is
why
it
requires
a
lot
of
work.
But
Adam
did
the
very
first
big
pass
and
cleared
the
way
for
now
polish
of
exposition
of
text.
So.
I
A
C
C
All
right
so
the
the
second
will
actually
so
the
other
piece
of
working
group
status.
If
you
look
at
the
agenda
that
we
put
online
I
had
just
put
the
terminology
in
there
to
just
get
a
status
update
of
where
it
was,
but
I
didn't
have
a
presentation
of
it
just
so
we
could
sort
of
get
a
catch
up
on
where
it
was.
C
C
Meant
to
look
up
the
quote
and
I
can't
find
it
I,
don't
know
how
many
of
you
all
have
ever
seen:
movie
The
Princess
Bride,
but
the
thing
about
I-
something
something
something
but
I'll
probably
kill
you
in
the
morning.
So
so
and
when
Kathleen
asked
me
to
be
working
group
chair
she's,
like
we
shut
this
down
in
six
months
and
then
and
then
every
time
every
few
months
it
was
like.
C
A
M
A
M
M
G
M
M
So
for
our
deployment
process,
we
had
an
AWS
instance
fired
up
with
the
open
fire
XMPP
server
with
a
couple
of
plugins
on
there
one
plug-in
and
then
the
pub/sub
extension
also
running
the
HTTP
file.
Upload
was
basically
used
because
our
assessment
content
and
the
assessment
results
are
actually
really
large
XML
files.
So
they
kind
of
publishing
those
as
the
payload
to
an
XMPP
message
was
not
not
going
to
work
efficiently.
M
E
Then,
previous
previous,
the
first
one
yeah
here,
I
seen
you
have
different
kind
of
sauce
to
collect
the
yarn,
bush
and
IP
fix.
I'm
I
want
to
know
the
I
want
to
know
at
the
reason
why
you
included
so
many
kinds
of
resource
to
collect,
but
that
means
that
the
auto-detection
worker
will
map
to
the
current
second
work
in
the
future.
We
we
can,
we
click
in
the
Fri.
We
can
specify
the
the
motor
or
the
way
to
collect
all
this
kind
of
a
source.
M
You
know,
being
you
know,
kind
of
the
one
that
we
you
know
we're
using
here
was
the
data
stream
section
here,
but
these
are
also
just
other
examples
of
where
that
information
could
come
from
and
that
they
do
fit
into
the
model
of
sort
of
being
published
to
the
XMPP
server
and
having
that
information
then
be
kind
of
put
over
a
standard
interface
to
XMPP.
For
then
continued
on
usage
down
the
line.
E
M
N
Nancy
came
on
just
so
I
just
wanted
to
make
the
clarification
as
being
the
author
of
the
XMPP
or
a
document
right,
so
the
XMPP
great
document,
which
is
a
mile
and
then
we
can
show
the
applicability
in
second,
is
to
show
the
agility
of
the
XMPP
grid,
how
you
can
carry
different
information,
so
it's
up
to
sockem
to
figure
out
you
know
as
you're
showing
which
ones
it
doesn't
mean
that
sacrum
has
to
embrace
them
all.
That's
all
true.
A
So
cristinaw
CEO
of
Carnegie
Mellon.
So
during
the
hackathon
there
is
a
bunch
of
different
questions
about
kind
of
which
X
XMPP,
jep's
or
Zepps
I
have
no
idea
how
the
right
way
to
say
that
are.
Do
you
have
any
kind
of
comments
you
can
make
about
that
or
any
kind
of
output?
So
you
can
talk
about
sure.
O
M
It
it
is
the
the
architecture.
Diagram
is
flexible
enough
to
support
whether
or
not
an
agent
is
installed
on
there.
So
there
are
certain
cases
where
it
would
be
an
agent.
In
this
case,
the
assessment
was
being
done
here
was
being
done
locally
on
the
mission
on
the
machine
that
was
sort
of
running
that
so
in
the
sense
it
was
being
acting
as
an
agent,
but
that's
not
necessarily.
It
doesn't
necessarily
need
to
be
okay,.
F
This
is
thinking
to
elaborate
on
that
on
the
answer
of
the
question.
That
is,
why
answer
your
question
Frank?
That
is
why
there's
so
many
initial
acquisition
methods
from
the
original
data
source.
We
call
this
data
storage
because
they
are
the
information
elements,
effectively,
reside
and
then
at
some
point
they
go
through
the
collector
and
become
a
input
to
the
XMPP
code.
In
this
example
here,
so
this
is
called
the
data
origin.
F
So
the
data
origin
knows
a
lot
of
stuff
about
the
thing
it
assesses
I'm,
sorry
collected
and
and
therefore
you
have
this
indirection
and
this
interaction
spacing
addressing
your
question.
There
are
often
already
interfaces
and
you
don't
want
to
install
an
agent
because
it's
virtually
impossible
due
to
policies
and
an
ongoing
production
line,
design.
O
Thank
you.
The
reason
why
I
ask
is
internally
some
of
these
components
wear
on
basically
the
first,
if
not
and
there's
in
some
cases.
Second
generation
of
them
select
the
orchestrator
repository
and
so
forth.
We've
actually
built
some
of
them
and
were
actually
working
on
some
it
ii
and
in
some
cases,
so
we
have
some
feedback
on
on
that.
Okay,
thank
you.
M
A
M
So
in
preference
to
should
this
out
say
thanks
to
Dave,
who
represented
some
XMPP
for
us
and
was
kind
enough
to
offer
some
time
to
to
talk
to
us
and
and
kind
of
go
over
a
lot
of
these
different
extensions
to
to
see
what
could
and
and
may
fit
into
this
sort
of
architecture
as
well,
so
I'll
call
them
zips.
Sure
54,
ad
hoc
commands
allows
us
to
kind
of
allows
the
orchestrator
to
invoke
collection
on
any
entity
that
it
has
in
its
roster.
M
So
it's
kind
of
presents
based
as
well
that
capabilities
allows
for
discovery
and
caching
of
an
entity's
capabilities
or
service
discovery,
the
file
satori
and
sharing
in
again.
In
our
case,
we
had
sort
of
large
files
that
we
were
using
for
the
kind
of
data
sources
to
to
perform.
That
assessment
allows
to
find
and
retrieve
those
files
using
observe.
So
it's
kind
of
in
cohorts
with
the
with
the
pub
sub
pub
sub
collection
notes,
which
allows
sort
of
a
grouping
of
pub
sub
topics.
M
You
know
by
you
know,
capabilities
or
OS
other
logical
hierarchies,
and
things
like
that.
Pub
sub
chaining
allows
for
sort
of
like
Federation
of
different
pub
sub
nodes.
If
you
know
we
kind
of
had
a
scenario
going
for
a
policy
repository,
that's
a
you
know,
kind
of
in
a
remote
location
to
a
local
policy
repository
and
sort
of
forwarding
that
information
back
and
forth
through
the
Genii
pub
sub
since
allows
for
I
guess,
queuing
and
storage
of
published
information.
So
then,
once
a
new
entity
is
joined
onto
the
XMPP
grid,
they
would
get.
M
They
would
receive
all
of
the
notifications
that
were
published
since
a
previous
time
that
they
log
on
or
again
sort
of
presence,
based
form
discovery
and
publishing
talks
a
little
bit
about
templates
and
results.
So
it's
a
kind
of
a
way
to
have
maybe
a
policy
kind
of
logically
joined
to
the
results
that
were
discovered
when
assessing
those.
M
So
you
can
kind
of
just
kind
of
point
to
that
template
which
would
be
you
know,
say
a
data
stream
collection
or
something
like
that
that
defines
what
to
collect,
and
then
the
results
would
be
sort
of
linked
to
that
and
then
easy
user.
Onboarding
is
a
good
way
to
kind
of
send
an
invitation
to
an
entity
and
then
have
them
their
accounts
created
and
presents
established
with
the
orchestrator
in
order
to
kind
of
enable
the
rest
of
the
other
pieces
that
a
lot.
M
M
So
yeah
so
again,
the
the
transport
and
again
sort
of
the
the
pipes
of
this
semen
seemed
okay,
so
then
kind
of
what?
What
else
do
we
need
to
define
and
that's
sort
of
the
components
that
are
going
to
be
joined
to
the
XMPP
grid
and
their
capabilities
and
then
really
the
interface
to
the
posture
collection
and
an
assessment
of
those
different
items
and
the
the
information
items
and,
and
so
how
do
we
describe
those
interfaces?
And
how
do
we
describe
the
implementation
I.
C
Q
T
A
U
B
W
V
So
we
requested
it
would
be
published
at
what
underwent
ad
review
and
we
published
a
draft
o2
based
on
that
feedback.
I.
V
Went
through
a
is
G
last
call
and
oh,
my
god,
the
emails
so
many
emails
we
address
all
that
was.
V
Its
opposite,
it
was
a.
It
was
a
lot
more
review.
Then
again,
let's
put
it
that
way.
Oh
so
Charles
Schmitt
heroically
went
through
misty
online,
it's
not
online!
So
don't
tell
him.
I
said
that
heroically
went
through
and
address
all
of
these
changes.
The
biggest
changes
I
think
we're
in
clarifying
the
use
of
the
your
eyes
that
was
kind
of
a
big
one
breasts
were
mostly
minor,
oh
and
addressing
how
we
fit
into
the
sack
of
architecture
which
was
complicated
because
of
our
architecture
difficulties
here,
but
we
did
our
bestest
on
it.
V
It
seemed
to
go
pretty.
Well,
you
get
next
us,
so
the
iesg
did
in
fact
approve
it
as
a
proposed
standard,
and
it's
an
it's
an
eye
on
our
review
right
now.
We're
waiting
for
some
experts
to
review
some
of
the
new
registrations,
and
how
long
does
that
take.
K
V
T
V
A
V
A
V
V
V
So
we
did
make
a
first
pass
at
up
leveling
the
draft
and
and
talking
more
about
the
benefits
of
collecting
data
directly
from
an
endpoint.
We
okay,
they
architectured
documents
to
be
more
general,
so
that
we
could
allow
for
other
forms
of
endpoint
collections
such
as
yang
and
then
we're
going
to
sort
of
try
to
break
down
later
in
the
document
different
implementations
right
now.
We
have
a
lot
of
good
information
about
Nia,
swimmer
and
absolutely
nothing
except
a
placeholder
about
yang
that
bad
stuff.
V
That
last
bullet
is.
It
would
be
thanks,
Chris.
So
these
are
the
changes
we
made
to
the
diagram
before
it
was
very
near
century
2
and
we
essentially
took
the
Nia
diagram
and
added
a
repository.
That
was
essentially
the
only
update
we
made
after
the
session
on
the
virtual
interim
meeting.
We
first
apparently
reverse
the
order
of
things,
so,
instead,
the
important
being
over
there
it's
over
here
now
we
combined
a
couple
of
components
in
the
Nia
architecture,
the
posture,
client
and
and
the
communication.
Clients
are
two
different
architectural
components.
V
O
So
we
have
looked
at
something
similar
like
the
after,
like
we
have
something
like
that,
but
the
direction
that
we're
moving
towards
is
the
orchestrator
is
new.
What
we're
planning
to
move
towards
is
have
the
orchestrator
communicate
directly
to
the
repository.
So
if
the
repository
wants
to
pull
data
about
the
information
it
goes
through
the
orchestrator,
even
if
it
needs
the
the
raw
data
to
munch
something
together,
it
pulls
it.
But
the
other
thing-
that's
not
in
the
diagram
which
is
takes
a
bit
to
consider
is
asset
inventories.
V
So,
in
our
point
of
view,
your
asset
inventory
should
not
be
considered
separate
from
your
security
components.
Asset
information
is
a
critical
component
to
security,
even
though,
even
though
in
most
organizations
they
are
considered
different
from
a
business
model
perspective.
So
a
lot
of
our
work,
have
you
read
the
Swimmer
draft
I'm.
O
O
I
will
say
one
thing
about
that
comment
with
regards
to
it:
it's
not
just
necessarily,
we
don't
necessarily
have
access
or
the
knowledge
to
that
information
and
we
need
to
collaborate.
So,
for
example,
we
have
a
concept
of
like
findings
or
issues
right
that
one
of
them
is
a
coverage
issue,
so
for
our
security
tool
find
something
that
isn't
an
inventory
or
there's
a
data
quality.
O
Something
that's
not
on
the
end
point
that
should
be
in
there
like
a
security
control.
That
is
also
a
finding,
so
I
do
agree,
but
in
a
lot
of
situations
that
data
isn't
in
there
and
we
depend
on
our
security
tools
for
certain
things,
but
actually
the
wider
repositories
have
more
valuable
information
like
DNS
and
elsewhere.
That's
just
reference
data.
The
idea
that
the
repository
hooks
into
reference
data
to
make
sure
that
all
the
information
matches
and
that's
also
important
for
their
quality.
So.
V
Theoretically,
I
think,
according
to
this
diagram,
we'd
say
that
your
external
security
tools
are
evaluators
right
there
they're
receiving
data
and
making
decisions
based
on
maybe
what
they're,
observing
or
what
they
can
access
from
the
repository
and
that
they
need
to
be
able
to
input
data
into
the
repository
as
they
see
differences
as
well.
Okay,.
M
D
O
V
This
work
rather
at
because,
while
it's
important,
where
we're
meant
to
be
in
this
document,
focusing
on
the
collections
specifically
and
getting
getting
that
information
to
other
tools,
that
would
require
it
so
again,
I
I
think
that
would
be
a
specific
instance
of
an
evaluator.
But
maybe
what
we
could
do
on
list
is
make
a
list
of
what
there's
other
tools,
services,
things
that
would
would
require
the
information
how
we
should
capture
them
better.
Yes,.
O
O
To
the
left
is
the
threats
right,
so
you
have
a
finding,
but
it's
specific
to
an
attack
vector,
like
you
know,
client,
side
or
remote
code
or
some
remote
exploitation
and
so
forth,
so
that
tagging
it
to
a
particular
finding
is
one
thing
and
then,
from
the
far
end
of
the
spectrum,
is
also
the
the
remedy
and
being
able
to
tag
it
with
a
specific
issue
to
fix
it.
Yep.
V
Absolutely
q
I
concur
so
yeah.
If
there's
more
commentary
like
that,
we
can
think
about.
I
do
want
to
sort
of
capture
in
a
very
generic
way
that
things
need
this
information,
and
things
should
be
authorized
at
the
administrators,
no
preference
to
access
this
information.
So
maybe
we
can
talk
about
how
to
make
that
more
explicit.
V
If
you
have
forgotten
where
I
left
off
here,
oh
so
we
combine
the
posture,
server
and
communications
client
into
one
architectural
element.
I
guess
we
added
the
concept
of
an
Orchestrator
that
could
communicate
with
the
posture
manager
but
I'm
hearing
feedback
that
needs
to
communicate
with
the
repository
as
well,
and
we
captured
explicitly
the
idea
of
an
evaluator
that
is
also
accessing
this
data
and
can
make
use
of
it
to
do
good
things
on
the
network.
Oh.
V
Apparently
I'm
talking
about
in
advance
on
my
slide,
so
this
is
some
more
information
about
behavior
ater
Danny
made
these
slides
but
I
for
one
yeah,
so
yeah
a
bit
more
information
about
the
orchestrator.
We
kept
it
genetics
and
they're
they're
ours
XMPP
grid,
but
there
are
also
many
other
Orchestrator
components
that
don't
before
that.
We
want
to
capture
the
idea
that
all
of
them
could
should
be
able
to
access
this
information
and
do
good
things.
V
We
have
a
whole
very
blank
section
about
net
mod
yang
that
the
group
wanted
us
to
to
incorporate
that
into
this
work.
I
think
that's
a
fabulous
idea.
I
also
think
Danny
and
I
are
not
necessarily
the
right
ones
to
do.
It
I
think
there
are
a
lot
of
people
in
this
group
that
know
a
great
deal
more
about
net
Maude
yang,
all
that
good
stuff
than
we
do
and
so
I'm
asking
for
help.
If
the
group
feels
that's
important,
he's
not
meeting
my
eyes
he's
looking
at
the
screen.
Instead,.
V
D
V
You
I
appreciate
that
well,
that'll
make
it
easier,
I
I.
Thank
you
for
that.
I
think
it's
very
important
we
captured
here,
but
we
just
screw
it
up
so
I
would
like
your
feedback.
I
think
we
had
email
before
about
the
diagram.
If
we
need
to
make
changes
to
that,
to
make
it
more
lickable
to
yang,
we
should
do
that
all
right.
V
So
next
steps
is
to
incorporate
workgroup
feedback
right
now
we
have
a
lot
from
Chris
and
we
will
adjust.
Those
I
would
like
to
to
get
more.
If
the
group
feels
this
work
is
still
valuable.
If
you
want
us
one
criticism
that
I
saw
in
in
Chris's.
Comments
too,
is
that
we
mentioned
TCG.
I
FIM
see
and
I
Fi
and
beep.
It's
the
way
the
collectors
communicate
to
the
communications
components,
I'm,
not
sure
the
group
has
the
will
to
go
through
and
Reece
tan
derp
dies
them
here.
V
I
would
like
some
discussion
on
list
about
whether
we
want
to
take
that
approach
or
whether
I
mean
just
in
the
way
we
cited
the
ISOs
wid
standard
and
the
swimmer
document.
Maybe
we
can
just
cite
those
as
possible
means
of
communication
between
those
two
components
here,
but
I'd
like
to
bring
that
to
the
list
and
have
some
more
talk
about
it.
V
V
Yeah
we're
stable
than
I
think
I've
written
here,
so
so
yeah
okay,
but
we
can
is
that
decision.
Is
that
a
list
that.
X
X
X
So
since
the
last
IETF,
we've
actually
made
three
three
revisions,
one
one
yesterday
and
two
over
the
last
few
weeks.
So
the
the
first
revision
that
we
made
was
to
to
make
some
changes
to
the
CD
CD
DL,
to
make
a
choice
to
allow
a
choice
to
be
made
between
a
payload
or
evidence
element
now.
The
purpose
of
this
is
you're,
typically
gonna
have
one
or
the
other,
and
and
so
so
so
I'm
we
try
to
sync
up
them
the
model.
X
X
X
So
in
the
oh
four
revision,
we
did
some
more
work
relating
to
the
firmware
extension
and
that
required
some
additional
index.
Every
renumber
we
added
a
section
which
is
section
1.1
discussing
the
operational
use
cases
around
house
with
tags
and
coast
with
tags
are
used,
I'm
in
the
context
of
a
saw
of
the
near
the
general
software
lifecycle.
X
This
section
provides
more
informative
information
that
describing
really
the
context
in
which
a
curse
would
would
be
used,
and
we
felt
that
that
was
missing
in
the
document
to
really
help
the
reader
understand
why
it
matters
we
added
sections
2.1
through
2.7,
describing
the
coast
wood
model
in
detail.
So
we
folded
the
item,
descriptions
I'm
into
a
more
explicit
section
that
breaks
down
each
aspect
of
a
coast
with
and
and
and
describes
it
in
in
greater
detail.
X
We
also
created
a
number
of
vienna
registries
for
for
things
like
entity
role
and
version
scheme,
values
which
allows
us
to
use
index
values
instead
of
strings
that
resulted
in
about,
and
some
of
my
testing
of
you
know,
generating
coast
wits
that
resulted
in
about
a
50%
reduction
in
the
size
of
a
Coast
whit.
You
know
simply
replacing
some
of
the
human
straight
strings
with
with
index
values,
so
that
work
is
all
all
done,
and
then
this
week
we
made
an
o-5
revision,
and
this
was
largely
based
on
comments
from
Chris
inácio.
X
So
thank
you
very
much
for
providing
those
so
based
on
Chris's
comments.
We
did
quite
a
bit
of
clarification
in
the
draft
really
to
to
make
it
clear
conceptually
when
we
were
talking
about
either
a
sweet
tag,
which
is
an
xml-based
representation
or
a
coast,
would
tag
which
is
you
know
the
subject
of
the
draft.
X
Another
one
of
Chris's
questions
was
a
construct
that
we
use
frequently
inside
the
draft,
where
we
allow
either
a
choice
between
a
single
value
or
an
array
of
two
or
more
values.
It
wasn't
clear,
I'm
in
the
draft
why
we
were
doing
that.
It
turns
out
that
you
know
the
reason
we
were
doing.
That
is
because
in
c4
we
can
use
I
think
about
four
bytes,
less
data
for
a
single
value
versus
an
array
so
allowing
for
that
choice
in
the
cvbl
definition
allows
data
to
you
know
to
take
advantage
of
that
kind
of
optimization.
X
X
We
had
failed
to
document
the
various
extension
points
that
you
see:
DDL
sockets,
to
allow
the
payload
and
evidence
portions
of
the
model
to
be
extended.
That
extension
point
is
being
used
for
the
firmware
extension
that
is
also
in
in
the
appendix
and
I'll,
be
talking
about
that
in
in
a
few
minutes.
E
Saved
a
friend,
Shahar
question,
and
in
this
document
you
use
Zeebo
as
my
own
messaging
format
and
I.
Don't
follow
all
the
processing
in
second,
but
I
want
to
know
if
there
is
a
tradition
that
if
we
need
to
other
secong
data,
in
addition
to
this
cause,
I
do
something
if
we
decided
who
use
both
all
of
the
youth,
feeble
or
or
it's
just
the
yo-yos
cases.
You
see
bow
so.
X
X
E
F
O
X
So
the
challenge
that
we
have
is
it's
really
up
to
the
software
provider
to
make
a
choice
as
to
what
what
type
of
tag
makes
the
most
sense
for
the
environments
that
their
that
their
software
would
be
deployed
to.
So
it's
largely
going
to
be
decided
based
on
you
know
what
what
software
products
you're
using
within
the
organization
and
and
what
choices
the
providers
of
those
software
products
is
there
yeah.
O
No
I'm
just
trying
to
avoid
complexity
and
just
keep
it
as
simple
as
possible,
so
that
I
can
make
it
easier
and
avoiding
quality
issues.
An
example
I
have
that
I
wanted
to
check
that
Swit
can
do
is
to
clearly
define
that
if
I'm
a
perceive
EE
to
assuage
that
I
can
say
it's
particularly
these
versions,
this
specific
version
and
the
subversion
so
that
I
don't
tell
anything
below
this
version
is
vulnerable
and
I
crave,
false
positives
as
well.
Yeah.
X
X
X
They
both
use
different
security
containers,
the
XML
version
uses
XML
D
sake,
the
Siebel
representation
uses
cozy
signatures,
obviously
won't
be
portable
on
between
between
the
two,
but
the
data
is
portable
between
the
two,
which
means
that
common
code
can
be
written
to
work
with
both
with
both
formats
and
I,
actually
have
some
proof
of
concept
code
that
I've
been
working
with.
It
basically
takes
advantage
of
the
common
information
model
to
to
have
an
internal
representation
within
an
application.
That's
basically
shared
across
that's
okay,.
O
Thank
you
for
pointing
that
out,
because
that
is
one
of
the
pain
points
that
we
have
is
the
level
of
complexity
and
sometimes
lack
of
documentation
that
were
unable
to
adopt
this
information
because
of
a
steep
learning
curve
within
others.
So
it's
not
necessarily,
even
if
the
standard
can
provide
the
use
cases,
sometimes
the
steep
learning
curve
and
the
documentation
actually
retracts
from
adoption.
Yeah.
Thank
you
and.
X
X
I
think
that
we
have
to
make
that
will
determine
whether
we
address
these
issues
in
the
draft
or
whether
we
kind
of
kicked
the
can
down
the
road
and
work
on
another
draft
to
actually
address
those
issues
and-
and
so
the
the
first
of
these
issues
is
in
the
appendix
I
think
it's
Appendix
B.
We
have
defined
a
firmware
extension.
X
This
is
an
extension
that
we're
actually
talking
about
in
the
in
the
suit
working
group.
A
little
bit
suit
right
now
is
is
kind
of
working
out.
What
the
information
model
is
going
to
be
for
what
they're
calling
a
manifest
format,
which
actually
aligns
pretty
well
with
something
like
a
sweet
tag
or
a
coast
with
tag
Supes
largely
focused
on
sea,
bore
format
for
for
a
manifest,
and
so
we're
we're
talking
with
that
working
group
about
using
Coast
wit,
maybe
as
as
a
solution
or
for
a
manifest.
X
X
We
would
like
to
suggest
to
the
working
group
that
maybe
we
move
the
firmware
extension
to
another
draft
which
would
allow
Coast
wood
to
be
published,
and
then
you
know
that
draft
can
continue
to
be
worked
on
using
the
existing
extension
points
and
and
and
Coast
would
at
a
pace,
that's
more
suitable
for
ephra
suits.
Are
there
any
concerns
with
us?
Taking
this
action.
X
W
X
C
Let
me
thank
good
Oh
to
me
at
six
of
one
half
a
dozen
of
the
other
I
think
it
would
be
easily
adopted,
but
do
you
have
a
name
for
that?
Can
you
just
do
an
individual
draft?
You
know.
X
C
F
You
have
any
opinion,
yeah,
no,
actually
I,
don't
know
where
to
put
that
draft.
Until
we
had
have
some
me
to
the
bones
I'm
talking
about
me,
I
will
be
a
co-author
of
this
suit
information
model
so
to
make
sure
it
we're
in
cooperate
or
are
the
interoperability
course,
but
at
least
on
the
fundamental
level.
C
X
Thank
you
next
slide,
okay,
so
the
other
issue
that
we
have
is
is
within
both
a
sweet
tag
and
a
coast
would
tag.
There's
this
linking
mechanic
that
is
modeled
after
the
HTML
link
element,
and
the
idea
is
that
you
can
establish
relationship
arcs
between
the
tag
and
something
else.
Something
else
could
be
an
informational
resource,
that's
available
out
on
the
Internet.
X
One
is
by
identifying
the
tag
ID
of
the
tag
that's
being
referenced,
so
that
allows
sort
of
a
one-to-one
link
between
a
coast,
web
and
another
coast
with
or
a
swig
swig
tag
and
a
curse
with,
basically,
because
we
have
a
common
information
model
between
the
two,
the
linking
can
be
basically,
irrespective
of
and
have
what's
being
linked
to,
and
this
is
used
to
do
things
like
this
say
this
request.
This
software
requires
this
other
software,
or
is
this
match
I'm
patches
this?
X
This
other
piece
of
software,
those
are
distinct
relationships
that
can
be
expressed
as
these
as
these
links.
So
the
first
way
is
by
referencing
the
tag
ID
of
the
tag,
but
in
many
cases
it's
really
inefficient
to
be
able
to
enumerate
yeah.
Potentially,
you
know
dozens,
maybe
even
hundreds
of
unique
tag,
identities,
because
every
time
you
release
a
new
version
of
the
software,
it
gets
a
new
sweet
tag
or
a
new
co
sweet
pack,
and-
and
so
there
can
be
a
large
number
of
pegs
that
you
might
want
to
reference.
X
So
the
solution
to
this
that's
used
in
the
and
the
XML
version
that
was
to
find
an
ISO
is
to
use
on
an
a
URL
encoded
version
of
an
XPath
expression
as
a
way
to
provide
that
reference,
and
what
that
next,
PATH
expression
allows
you
to
do
is
to
select
out
useful
data
elements
within
within
the
sweet
tag.
Is
that
it?
That's
your
own
I'm
gonna
speed
up?
No,
no
aren't
you
already
here.
Mostly
I
wanted
to
actually
talk
about
the
examples
on
the.
P
X
X
The
second
example
is
one
where
there's
there's
some
kind
of
persistent
ID
which
can
be
used
for
grouping
a
collection
of
software,
so
you
could
say,
like
my
one
dotto
release
of
this
software,
has
this
persistent
ID,
and
that
applies
to
all
of
the
releases
of
one
dot
IO.
So
if
you
do
what
da
da
1
da
da
da
0:01
you
know
and
so
forth,
they
can
all
be
referenced
using
sort
of
a
group
identifier
for
that
software.
X
So
that's
how
these
paths
are
used
next,
like
this,
the
problem
is,
is
we
don't
have
a
suitable
path
expression
language
for
that
will
work
with
JSON
and
Seaborg?
This
is
actually
something
that
I
think
that's
a
broader
problem.
You
know
within
within
the
IETF
right
now,
there's
a
lot
of
small
attempts
at
being
able
to
define.
You
know
profiles
of
things
like
XPath.
X
So
by
doing
this
separately,
we
believe
that'll
allow
us
to
move
coast
wood
forward.
We
can
basically
say
that
you
know
a
specific
path.
Expression
is
not
yet
defiant
in
Coast
wit,
but
will
be
defined
later,
and
we
believe
that
doing
this
would
actually
benefit
a
few
of
the
other.
You
know
sea,
bore
and
and
JSON
related
efforts.
X
O
I
also
said
on
the
board
of
a
wasp,
so
if
there's
actually
some
gaps
that
you
need
help
with
with
regards
to
sort
of
missing
libraries
or
code
for
that
I
can
reach
out
to
the
community
and
see
if
someone
wants
to
help
the
second
one
is-
and
this
is
on
a
higher
layer
rather
than
just
the
direct
mapping,
but
on
an
unrelated
know,
we
were
looking
at
it
from
s
Kappa.
Have
you
considered
BDD
frameworks
that
behavior
durable
development
frameworks
like
gherkin,
that
has
a
domain-specific
language?
There's
almost
English
readings
like
given
this.
O
So
there's
a
few
organizations
like
Capital
One
and
ourselves
are
looking
into
that,
so
that
we
can
make
sort
of
the
requirements
or
the
English
language
stuff
when
the
test
scenario
almost
identical,
but
it
might
be
able
to
work
on
the
inventory
level.
Given
this
OS,
given
this
version
between
x
and
y,
this
yeah
yeah.
Y
X
Y
Okay,
I
see
the
two
drafts
I'm
thinking
about
the
first
one
I
think
before
we
decide
to
do
that
here.
I
think
we
would
benefit
from
surveying
a
lot
of
what's
potentially
out
there
and
seeing
whether
we
can
get
another
worker
to
help
us.
It
feels
like
a
lot
of
good
general-purpose
machinery,
not
in
scope
of
what
we're
doing
here.
We'd
love
it,
but
that's.
X
Something
that
we
need
a
solution
here.
We
need
something
that's
roughly
equivalent
to
what
the
valley
tech
standard
supports
with
XPath
so
and
we've
been
looking
around
and
we
haven't
found
actually
a
really
good
solution.
So,
if
anyone
has
any
ideas
on
what
existing
work,
we
could
leverage
to
do
this.
That
would
appreciate
it.
Thank.
F
You
well,
this
is
Hank
and
them
this
is
a
little
bit.
Bearing
now
embarrass
me
now
to
say,
after
you
said,
we
haven't
found
good
work
and,
of
course
there
is
the
yangtze
war
draft
that
is
has
including
a
XPath
filter,
expression
for
C,
bore
and,
and
somebody
that
was,
we
checked
that
that's
what
that's
not
a
complete
set
of
the
things
we
need.
So
that
is
why
it's
unsuitable
so
to
speak.
It
is,
although
I
point
to
as
a
reference.
You
can
start
working
often
have
a
some
lesson
back
off,
I
guess
so.
X
F
Z
B
C
I
think
what
I
kind
of
actually
I
don't
really
want
to
have
a
discussion
about
where
it
needs
to
be
do
where
it
needs
to
be
done.
I
think
I
would
start
the
work
and
then
figure
I
would
start
the
the
other
draft
and
then
see
where
it
needs
to
go.
But
I
would
I
do
like
the
idea
of
separating
things
out
and
getting
this
piece
moving
for
that.
U
X
X
Okay,
so
so,
given
that
we've
kind
of
like
shed
some
of
the
the
to-do
items
on
on
that
are
the
major
outstanding
items,
I'm
cursed
with
there
are
a
few
smaller
things
that
we
would
still
like
to
do
with
the
draft,
and
we
believe
these
things
could
be
done
yet
really
quickly.
So
there's
two
other
values
within
Coast
would
that
have
enumerations
of
text
values.
There
are
Lincoln
ownership
and
Linc
use,
so
we
would
like
to
turn
those
into
index
values
so
that
you
know
that
they'll
be
sufficiently
concise
as
well.
X
That's
about
an
hour's
worth
of
work
to
do
that.
There's
a
couple
of
INR
registrations
that
we
would
like
to
do
for
for
curse
with
so
you'd
like
to
register
a
media-type
for
application.
Curse
with
plus
si
bore.
So
this
would
be.
X
You
know
defining
the
the
coast
would
fragments
to
use
with
that
that
media
type
and
we'd
also
like
to
register
a
curse
with
content
type
for
Co
F,
which
would
just
make
it
easier
to
transport
you
curse,
wits
and
various
protocols,
and
then
there's
a
few
small
editorial
changes
that
we
would
like
to
make
to
the
draft
just
to
improve
its
readability.
So
we'd
like
to
add
figure
names
to
the
tables
and
fix
a
few
minor
on
formatting
issues,
just
to
get
it
ready
for
it
for
publication.
Are
there
any
concerns
with
us?
X
C
I
think
it
does
so
when
you,
when
you
do
an
update,
if
you
could
just
remind
us
that
we
want
to
do
a
working
group,
last
call
request
it
from
us.
Will.
P
A
P
C
Y
G
A
AA
AA
J
AA
More
heat,
that's
what
we
need
good.
The
feature,
great,
not
a
good
feature,
but
it's
a
feature.
It's
a
feature,
not
a
bug.
Okay,
so
I'm
here
to
do
two
things.
First,
I'm
gonna
provide
a
brief
cross
working
group
overview
of
some
work,
that's
happening
in
mile,
that's
the
Rolly
draft
and
then
I'm
going
to
once
a
draft
anymore,
get
depent,
spoilers
and
I'm
also
going
to
go
over
a
draft.
That's
here
in
sacrament
provides
an
extension
for
rolling,
so
next
slide.
AA
Please
text
is
very
small,
but
this
is
a
very
brief
overview
of
the
status
of
the
Roli
ecosystem
drafts.
A
new
c-cert
draft
extension
was
just
posted
two
mile.
A
to
new
versions
of
the
software
descriptor
were
just
posted
here
in
sockem,
which
I'm
going
to
go
over
a
new
personal
draft
going
over
discovery
using
dns
SD
was
posted
as
a
personal
draft
and
there's
a
couple
things
that
we're
thinking
about
doing
in
the
future.
AA
There's
a
concept
of
doing,
searching
or
querying,
and
then
a
JSON
version
of
roli,
which
both
taki
and
Brett
have
expressed
interest
in
working
on,
as
well
as
a
couple
other
people.
So
something
to
look
out
for
in
the
future.
Okay,
next
slide,
the
Roli
core
document
has
been
published
as
RFC
832,
so
that
has
officially
gone
through
everything
and
is
now
published.
AA
So
if
you
are
interested
in
reading
about
Roli,
which
I
see
a
couple
unfamiliar
faces
in
the
crowd,
roley's
the
resource
oriented
lightweight
information
exchange,
it's
a
Meishan
sharing
standard
based
on
the
atom,
syndication
format.
So
if
that
sounds
remotely
interesting
to
you,
go
check
out,
RFC
a
three-to-two
and
thanks
to
anyone
who,
in
this
group
provided
feedback,
which
is
several
of
you.
So
thank
you.
The
draft
and
it's
good
work
next
slide.
AA
I
posted
a
new
version
of
Rolly
software,
descriptor
back
before
the
deadline,
and
then
I
posted
a
new
version
like
two
hours
ago.
So
I'm
gonna
talk
about
both
of
those.
The
first
version
was
a
series
of
minor
grammar
updates,
updates
two
references,
some
fixes
throughout
the
document,
the
typical
stuff.
The
update
that
I
just
posted
a
few
hours
ago
is
more
interesting
and
is
what
I
want
to
talk
to
the
group
about
next
slide?
Please,
okay!
AA
So
the
software
descriptor
extension
defines
how
you
would
use
swift
acts
and
Coast
would
tags
in
a
rolly
repository.
We
have
a
media
type
field
in
content
that
lists
the
media
type
of
whatever
we're
linking
to.
There
is
no
defined
media
type
for
Swit
tags,
nor
is
there
one
for
coasts
wit.
Yet,
although
dave
was
just
mentioning,
registering
a
coast
would
thing
so
one
of
the
solutions
to
this
problem
for
us
is
to
register
the
Swit
tag
media
type
in
this
document.
AA
AA
Xml,
yes,
all
the
way
around
I
think
that's
fixed
on
the
next
slide.
Yes,
it
should
be
Swit,
and
so
this
is
something
I
made
up.
We'd
have
to
come
up
with
the
actual
format
for
it
and
figure
out
what
we
would
register
it
as,
but
if
there's
anyone
in
the
room
who
understands
or
who's
aware
of
the
full
registration
process
for
Media
types
and
understands,
if
we
can
do
it
in
this
document,
just
as
an
additional
activity,
that
would
be
useful
information
for
us.
Thank.
F
AA
F
What
are
you
actually
registering
here,
the
xst
that
is
available
or
what
was
what
is
making
a
switch
2015's
for
2015?
That
is,
that
is,
as
we
highlighted
in
the
registration,
apparently,
because
if
you
are
referring
to
the
schema
that
is
available,
two
of
them
and
the
extra
2015
is
broken
and
not
usable.
So
and
probably
the
2015
current
and
maybe
also
again
talk
to
ISO
and
let
them
fix
that
before
you
register,
and
you
know
what
you're
registering.
So
that's
a
little
bit
of
that
daily
responsibility.
X
X
AA
T
AA
AA
V
AA
That's
another
thing
that
we
could
do
as
well
right,
we
can
say,
register
the
media
type
for
swig
and
then
use
the
parameter
for
the
actual
official
version
and
then
just
in
requirement
text
or
just
in
the
text
say:
hey
here's,
a
profile
of
Swit
that
we
would
like
to
point
out
which
the
the
most
recent
drafts
has
a
sentence
in
there.
That
says,
if
you
want
to
learn
more,
go
check
out
mr.
80/60,
we
don't
have
any
requirements
around
it,
yet
something
we
could
do.
AC
So
David
Lindley
I
just
want
to
point
out
media
types.
You
used
in
two
different
places,
though
they're
used
as
a
they
use
in
responses
to
tell
the
consumer
what
they're
about
to
receive,
for
which
they
can
be
truly
thankful,
but
also
they're
used
in
requests
to
to
indicate
what
can
be
supported
now.
I
have
a
feeling
that
parameters
aren't
always
supported
in
all
cases
correct,
particularly
in
the
requests
correct
and
so,
given
that
the
parameters
detailing
the
precise
schema
and
I'm,
assuming
that
the
scheme
isn't
very
cross
compatible
2009.
AA
AA
X
Dave
well,
tomorrow,
I
just
wanted
to
+1
the
previous
comment
that
yeah
in
content
negotiation.
Support
for
parameters
can
be
kind
of
Hankey
and
I
do
agree
that
the
swig
models
are
from
the
2009
and
the
2015
versions
are
actually
very
different.
They
they
have
different
namespaces
they're,
effectively
different
models.
So
if
we
were
to
develop
a
media
type,
you
know
that
would
represent
the
model
being
used.
We
would
probably
want
to
media
types
for
the
two
different,
the
two
different
tags
yeah.
We
could
do.
AA
AB
So
Bret
Jordan,
I,
guess
I'm,
just
not
aware
of
the
content
negotiation
issues
that
people
have
seen,
cuz
I
haven't
seen
them.
You,
like
you,
just
put
it
in
your
except
header
and
you
put
the
parameter
in
and
then
when
you
get
content
coming
back,
you
could
just
specify
the
content
type
as
you
know,
and
the
parameters
there.
If
we
need
to
do
something
in
Rowley
or
some
of
these
other
things,
I
mean
you
just
call
it
out
and
say
that
these
are
what
you're
gonna
get.
AB
AA
X
Is
Dave
again,
two
two
breasts
point:
what
you
explained
is
how
it
works
like
how
you
would
the
the
standards
to
to
express
that
I.
Think
with
the
cautionary
note
that
we
were
giving
about
about
the
the
weirdnesses
implementations.
Don't
always
work,
you
know
completely
based
on
the
specifications,
and
there
are
some
implementations
that
can
be
a
little
bit
weird
on
content
negotiation.
F
AA
F
AA
C
AA
AA
The
this
is
I
think
the
last
issue
so
finish
it
quickly.
Hopefully,
the
document
now
has
a
number
of
requirements
in
order
to
enforce
interoperability
around
the
information
elements
that
we
expose
through
properties
as
well
as
a
couple
other
places
we
weren't
doing
this
before.
We
realize
that
it's
important
to
do
this
so
that
if
I
say
that
I'm
in
compliance
with
this
extension,
it
actually
means
something
rather
than
I.
AA
C
AA
Okay,
I
think
next
slide,
maybe
that's
it
all
right
cool.
So
thank
you
very
much.
U
C
H
Can
you
guys
hear
me
yep
all
right,
good
Adam
on
toast
Center
for
Internet
security,
talking
about
second
architecture
kind
of
like
a
second
one,
to
go
through,
possibly
I
sewed?
The
draft
makes
a
couple
of
assertions
that
this
first
one
is
basically
that
we
intend
to
enable
a
cooperative
ecosystem
of
tools,
probably
from
different
vendors,
different
sources.
Basically,
so
we
can't
always
rely
on
interoperability.
H
That's
proprietary
anyway,
next
assertion-
and
this
may
be
a
mistake,
but
I
think
that
there's
two
basic
perspectives
in
this
group
that
there's
an
architecture,
that's
more
XMPP
focused
and
an
architecture.
That's
more
I!
Guess:
ECP
focused
if
you
will
I,
don't
know.
If
that's
true
or
not
that's
an
assertion
the
draft
makes
and
the
rest
of
the
draft
is
basically
based
on
those
assertions.
So
basically
it
presents
what
if.
H
H
E
W
N
If
it's,
where
you
say,
word
odds,
I,
guess
I'm
trying
to
understand
from
a
draft
perspective,
I,
don't
see
them
being
at
odds.
Is
it
more
that
we
need
to
bring
a
better
understanding,
because
for
my
standpoint,
roldy
brings
in
one
potential
transport
mechanism.
Xmpp
grid
is
another
the
original
architecture
draft
which
I
haven't
updated
forever,
because
was
that
yeah
laughs?
Okay?
N
D
N
H
H
N
V
Fitzgerald,
okay
and
I
say
so:
yeah
I,
don't
think
Brett
ODS,
either
I
think
I.
Think
ECP
an
XMPP
grid
are
trying
to
solve
two
different
ends
of
our
problem.
I
think
my
concern-
and
this
is
maybe
a
meta
concern
not
about
the
sled,
but
about
the
the
architecture
document
you
presented.
No,
not
yours,
although
maybe
actually,
no,
not
take
back
your
sir
excellent.
No,
no!
It's
not
it's
not
that
thing.
V
Don't
worry,
don't
get
angry
in
advance
of
the
comment,
so
I
think
XMPP
grid
was
moved
to
mile
because
it
very
well
addressed
the
use
cases
mile
was
addressing
and
I
think
it.
It
is
absolutely
a
tool
that
can
be
used
to
address
some
of
the
use
cases
sockem
is
been
addressing.
V
I
would
like
to
see
an
architecture,
though,
that
captures
sockem
solutions,
solutions
we
have
created
here
and
we
do
have
one
and
then
maybe
also
goes
on
to
describe
how
we
how
we
can
interact
with
work
from
other
work
groups
as
well
right,
so
you
can
use
XMPP
grid
as
as
you
described
in
the
orchestration,
it's
not
a
sacrum
solution.
That's
a
mile
solution
that
we
can
interoperate
with
right
and
I.
V
M
G
C
AB
Always
been
known
to
be
a
short
at
the
mic,
so
I
vertically.
So
there
was
an
interesting
talk
at
the
lightning
round
at
this
IETF
that
I
thought
was
very
interesting
and
maybe
applicable,
something
that
we
want
might
want
to
look
at
and
that
was
Matthew
from
matrix
org.
So
that
might
be
also
another
piece
of
technology
that
we
may
want
to
look
at
so
I
find
that
to
be
very
interesting
for
some
of
the
other
projects,
I
work
on
and
they're
SDOs,
and
it
may
actually
be
something
that
is
interesting
here.
AB
H
So
hopefully
you
guys
can
see
that
enough.
If
you
can
bring
it
up
on
your
machines
or
whatever,
but
oh
and
notice
that
there's
a
plus
on
that,
so
it's
XMPP
grid
plus
because
XMPP
grid
doesn't
really
satisfy
it
and
everything
we
would
need,
which
is
what
Bill
talked
about
earlier
during
the
hackathon
presentation.
So
there's
a
bunch
of
other
extensions
that
we
might
need
to
bring
into
it.
So
it's
not
just
that.
You
know
we
want
to
rely
on
an
XMPP
grid
kind
of
thing
as
this
potential
solution.
H
It
says
there's
more
to
it
than
that.
So
essentially,
we've
got
a
bunch
of
collectors
down
along
the
bottom,
and
each
of
those
collectors
could
just
have
a
connector
that
talks
XMPP,
plus
those
extensions
right
as
specified
whatever
those
end
up
being
to
talk
to
all
the
different
components.
You
know
we
talk
a
lot
about
sacrum
components
and
sacrum
functions
and
interfaces
capabilities.
I
think,
is
what
we
prefer
instead
of
functions
anyway,
go
to
the
next
side.
H
Here's
the
EC
piece
I
wanted
to
do
a
CCP
to
show,
because
it's
kind
of
put
down
into
a
collection
mechanism,
because
that's
really
where
it's
targeted
right.
It
is
on
how
to
collect
things
off
of
endpoints
and
in
a
very
specific
way.
So
this
is
the
diagram
that
I
think
just
put
up
earlier.
This
is
what's
in
the
latest,
ECP
draft
I.
Think
so.
There's
the
new
bits
of
Orchestrator
evaluator
repository
stuff
go
to
next
slides.
H
We
could
connect
XMPP
grid
plus
right
from
what
I'm
calling
the
posture
manager,
which
is
the
three
repository
the
collector
manager
and
the
validator
to
an
Orchestrator
to
an
evaluator.
We
could
use
the
grid
for
that
pub
set
over
that
or
whatever
else
we
need
to
do
next
slide.
We
could
go
as
far
as
saying
hey,
let's
not
use
the
TNC
transport
at
all.
Why
not
have
agent
running
on
an
endpoint
talk,
XMPP
right?
H
Okay,
next
I
think
what
we'd
like
to
do
next
and
when
I
say
we
use
I,
so
bill
and
I
have
been
doing
the
hackathon
like
this
time.
I
think
last
time
with
over
two,
we
invite
others
to
help
help.
Us
is
we'd
like
to
see
how
we
can
get
like.
Basically,
look
at
the
policy
source
and
configuration
policies,
specifically
so
narrowing
down
the
set
of
components
that
we
want
to
care
about.
H
A
Y
H
The
yeah,
some
of
the
extensions
you
know,
use
your
onboarding
collection
nodes
for
pub/sub
things
like
that
and
and
capabilities
for
sure
something
that
we
want
to
do
for
capability
negotiation
or
at
least
awareness.
Next,
it's
a
list
of
potential
components
we
can
start
talking
about
during
the
hackathon
review.
Bill
talked
a
little
bit
about.
You
know
trying
to
define
semantics
around
some
of
these
things
right
now
and
really
what
that
means
is.
What
do
we
mean
when
we
say
software
inventory
or
vulnerability,
State
or
software
inventory
collector?
H
What
do
we
really
mean
when
we
say
those
things,
and
then
we
can
start
looking
at
what
we're
close
they
cooperate
in
and
what
interfaces
need
to
look
like
and
so
on.
So
anyway,
that's
kind
of
the
idea
behind
the
hackathons
that
we've
been
doing
is:
let's
pick
one
thing:
let's
look
at
it.
Let's
learn
from
that
and
move
onto
the
next
thing.
It's
so
going
forward
again.
We
welcome
contributions.
The
the
real
intent
of
this
draft
isn't
necessarily
to
move
forward.
H
H
If
we
do
you
go
the
XMPP
grid
route,
we
could
do
some
of
that
plus
work
a
mile.
We
could
do
a
separate
thing
here
or
do
something
else
entirely.
You
know
it
just
depends.
I
think
and
Bill
may
be
able
to
comment
on
this
a
little
bit,
but
I
think
that
we
found
it
easy
to
use
the
existing
supported
libraries
that
are
out
there
to
try
to
just
do
experimentation.
AC
Hello,
it's
dichroism
again
this
time
with
my
XMPP
standards.
Foundation
hat
on
I
was
just
going
to
say
that
if,
if
you
guys
do
want
to
work
on
so
I
can
related
or
mile
or
for
that
matter,
a
mile
relating
I'll
repeat
this
later
and
if
you
do,
if
you
want
to
do
that
within
the
ITF,
that's
fine,
and
if
you
want
to
do
that
within
the
XMPP
standards
foundation,
which
is
effect,
will
be
the
same
as
the
ITF
but
with
more
beer.
Then
you
are
also
fine
to
do
that.
AD
C
N
O
AE
A
AE
O
O
So
that's
one
thing
to
keep
in
mind
and
keeping
an
eye
out
and
then
from
our
side
because
we're
working
on
it
organically.
There
are
two
things:
I
have
feedback
on,
which
is
mistakes
will
happen?
I
think,
will
you
know?
Technology
grows
organically
will
discover
certain
things
so
we're
keeping.
The
API
is
the
connectivity
between
the
orchestrator
and
the
systems,
the
orchestrator
and
the
repository
versions.
O
So
we
know
that
the
data
model
will
change
over
time
and
we're
telling
people
to
basically
sunset
the
old
version
and
so
on,
so
that
the
adoption
just
sort
of
moves
organically.
We
know
that
we'll
make
mistakes
going
forward.
So
I
don't
know
if
that
has
taken
into
account.
The
final
thing
I
have
is
again
to
minimize
dependencies.
We
go,
you
know
you
know
Jenkins
or
any
of
the
build
pipelines
into
the
orchestrator.
O
The
orchestrator
hits
the
scanning
tools
and
so
on,
but
also
notifies
the
repository
that
repository
pulls
from
the
orchestrator,
which
means
that
for
any
of
the
posture
managers,
you
only
have
to
create
one
connectivity.
You
don't
need
to
create
another
connection
for
that,
and
this
is
mainly
for
an
implementation
perspective
because
of
where
it
is
right
now.
So.
Thank
you.
Thanks.
X
X
At
least
that's
what
I
heard,
and
that
was
actually
one
of
our
early
design
principles
in
this
group
was:
if
every
device
in
the
enterprise
has
the
ability
to
communicate
and
ask
something
of
the
endpoint,
it's
really
easy
to
actually
over
live
at
the
endpoint,
and
if
we
have
some
device,
that's
responsible
for
collecting
aggregating
all
of
the
requests
at
the
endpoint
and
then
doing
it
in
an
efficient
way
that
doesn't
overload
the
endpoint.
That's
a
desirable
aspect
of
our
architecture.
X
The
a
few
things
concerned.
It's
concerned
me
when
looking
at
some
of
these
pictures,
which
basically
shows
you
know
and
a
generic-
you
know
communications
mechanism
with
the
endpoint,
because
that
can
very
quickly
result
in
the
worst
case
scenario,
which
is
you
know,
hundreds
of
different
devices
asking
for
more
or
less
the
same.
You
know
kinds
of
information.
You
know
directly
from
the
endpoint.
You
know
which
can
overload
the
endpoint.
You
know,
how
do
we
address
that
as
part
of
this
architecture?
Oh
yeah.
D
O
You
know
quite
a
lot
of
endpoints.
We
have
the
you
know
if
we
configure
something,
especially
with
critical
infrastructure,
it
has
a
catastrophic
impact.
So
literally
so
from
that
side,
we've
made
quite
a
lot
of
work
on
the
orchestrator
for
calculations
of
the
asset
groups,
on
the
scheduling
of
those
cans,
and
that's
one
of
the
reasons
why
we
use
an
Orchestrator.
We
never
want
to
log
into
a
security
tool
like
a
posture
manager
and
do
everything
we
just
tell
the
orchestrator.
The
orchestrator
knows
the
blackout
periods.
O
It
understands
the
asset
groups,
the
polls,
reference
data
from
inventories
to
understand
their
sensitivity
and
makes
the
judgment
as
to
whether
that's
a
good
idea
or
not
and
then
scales
out
sort
of
the
the
checks.
The
posture
manager
in
general
can
do
that.
You
can
just
log
into
the
pilot
past
your
manager
and
just
scan
everything
under
the
Sun.
It's
not
necessarily
a
good
idea
and
we're
putting
sort
of
a
lot
of
that
logic
into
the
orchestrator
and
just
telling
the
dummy
manager
just
do
what
I
say.
O
H
O
I
would
slightly
disagree
in
the
sense
that
everyone,
you
don't
want
your
systems
to
go
down.
It
doesn't
matter
if
you're,
a
small
company
or
a
big
company.
It
might
not
necessarily
be
catastrophic
for
the
rest
of
society,
but
it
might
be
catastrophic
for
you
and
it
would
be
unfair
to
us
to
to
basically
make
that
distinguish.
You
distinguish
that
it's
important
to
be
considerate.
However,
the
deployment
is
and
just
to
make
sure
that
that's
taken
into
account.
That's
all
thanks.
Yeah.
AC
AC
No,
it's
too
hot
to
wear
a
hat.
That's
why
I'm
put
it
on,
but
just
on
they
there
you
go
just
on
the
on
the
subject
of
cashing
and
avoiding
the
traffic
going
all
the
way
to
the
end
point
you
know
this
is
something
that
that
in
the
xmpp
world
we
we've
dealt
with
a
lot
before
so
just
because
the
end
points
are
connected
or
addressable
throughout
some
VP
does
not
mean
that
you
have
to
go
back
to
the
amp
no
time.
There's
an
example
of
this.
AC
H
That's
an
excellent
point
actually
is
that
it?
What
we
really
get
down
to
is
that
the
first
assertion
of
the
draft
was
that
we
want
a
cooperative
ecosystem
of
tools
right
and
then
later
in
this
presentation,
we're
claiming
that
we
need
to
start
defining
semantics
of
things
and
components
right.
So
maybe
we
just
don't
allow
certain
components
to
talk
all
the
way
down
to
wherever
the
actual
collection
is
happening
and
we're
still
using
something
as
a
message
transfer
right.
So
that's
just
because
that's
a
good
point!
AA
C
I
that's
really
good
question
because
just
giving
the
time
I'm
curious,
as
opposed
to
the
the
details
of
this
document,
I,
was
wondering
if
we
could
talk
a
little
bit
more
about
whether
we
want
to
move
forward
with
this.
As
from
the
perspective
of
we
had
a
couple
versions
of
an
architecture
we
parked
it
and
then
we
thought
it
might
be
a
good
idea
to
try
and
revisit
it
again.
I
sort
of
like
to
answer
the
question
about,
as
opposed
to
whether
the
details
of
this
document
are
correct
or
not
whether
does
that.
C
But
if
we
think
so,
the
question
is
I
think
we've
we've
we've
gone
for
a
while
without
an
architecture
document
and
people
have
come
back
and
said
you
know,
an
architecture
document
would
really
help
us
move
forward,
and
so
I'd
really
like
to
frame
this
conversation
today
about
how
we
move
forward
with
an
architecture
document
and
not
necessarily
the
nitty-gritty
details
of
this
architecture
document
that
make
sense
so
now
go
ahead.
Just.
AC
One
more
point
which
I'm
not
sure
I'm
allowed
to
make
now
one
thing
that
I've
seen
as
a
from
an
application
protocol
designers
perspective
over
and
over
again
in
a
series
of
industries
from
mobile
to
IOT
and
security
as
well.
There
is
a
tendency
for
for
a
roomful
of
security
experts,
because
there
is
lots
that
is
unique
about
security.
There
is
a
tendency
to
assume
that
everything
is
unique
about
security
and
it
turns
out
that
most
of
the
application
protocol
level
problems
are
the
same
across
everywhere.
So
yeah.
O
V
So
you
asked
how
to
move
forward
on
this.
I
I
want
to
propose
two
alternatives:
one
that
that
concept
gets
worked
into
ECP
and
the
other
is
that
we
we
create
a
an
additional
document
that
describes
how
succomb
interfaces
with
other
work
groups
like
in
mile
and
how
we
can
interrelate
with
their
efforts
there
that
could
also
capture
Roli.
That's
a.
F
Hi,
this
is
Hank
again
we
were
participating
in
the
last
two
hackathons
and
creating
workflows
of
data
originating
from
a
net.
Heaven
I'm
target
end
point
of
those
Network
equipment
up
to
the
point
where
we
come
to
a
very
ater
that
just
says,
I
got
this
because
we
have
no
comparative
guides
to
compare
to
at
the
moment.
I
had
had
back
then
so
we
created
repositories
like
a
target
and
repository
and
an
imperative
guidance
repository,
and
we
use
this
an
XMPP
grid
to
a
faciliate
data,
collector
orchestrate
data
collection.
F
So
this
is
not,
according
to
the
current
architecture,
that
first
of
all,
according
to
the
architecture
before
that,
and
not
so
that's
the
mathematical
ahead,
a
complete
workflow
and
it
was
okay.
I
think
we
used
yang
Bush
as
the
source.
We
could
show
the
the
coupling
of
all
of
all
the
data
representations
and
the
complete
workflow
and
now
I'm
and
now
I'm
at
a
point
where
I
don't
know
why?
F
What
do
I
do
it
again,
because
this
is
something
that's
entirely
again,
I
think
sometimes
and
I
don't
know
how
to
proceed
because
we
lose
the
general
concepts
of
well.
We
have
a
capability
to
provide
some
information
to
do
and
the
capability
to
consume
information
order
to
bright
something
to
you,
restore
something
or
we
relate
and
as
soon
as
possible.
F
All
those
general
concepts
are
not
gone
from
the
architecture
and
they're
very
specific
things
we
have
somehow
now
in
there
and
now
I,
don't
know
how
to
build
anything
anymore,
because
I
can
only
build
the
very
specific
things
that
are
in
the
architecture,
and
that
is
confusing
to
me.
Si
as
if
as
an
individual
wants
to
build
more
flexible
workflows,
and
that
is
the
problem
I
have
at
the
moment.
So
with
the
current
architecture.
M
F
F
F
M
F
O
M
F
C
H
C
H
C
P
O
O
That
is
currently
a
challenge,
because
we
want
to
have
everything
talk
uniform
with
a
single
sheet
of
music
and
right
now
there
are
components
all
around
that
can
do
some
of
these
things,
but
they
don't
talk
to
each
other
with
the
right
way
and
we
would
like
to
be
able
to
do
that
going
forward
and
from
an
architecture.
That's
what
I
would
like
to
see
and
the
details
and
the
technical
architecture
the
plumbing
can
come
in
as
and
when
organically
as
well.
Thank
you,
okay,.
C
C
F
X
C
C
C
Y
L
Optimistic
Kepley
Moriarity,
one
thing
that
has
worked
well
with
other
groups,
is
to
do
an
architecture
document
at
the
end
of
the
work
to
show
how
all
the
pieces
tied
together
and
that's
actually
received
quite
well
through
all
the
final
stages
of
review
at
leasts
and
in
recent
yeah.
I
know
that
in
the
past
iesg
right.
C
C
V
And
I
think
there's
to
amplify
that
this
is
Jessica,
Furman
and
say
I
think
we
also
have
a
track
record
in
this
group
of
saying.
Well,
we
want
to
do
X,
Y,
&,
Z
and
then
no
one
ever
actually
brings
the
brick.
So
we
spend
our
time
down
a
rat
hole
for
the
high
level
document
for
work,
but
never
gets
brought
here.
So
I
wonder
if
we
should
tackle
the
problem
and
bring
the
work
you
think
needs
to
happen.
C
I
think
part
of
what
I
was
trying
to
do
is
to
get
to
the
difference
between
parking,
a
document
that
we're
ignoring
versus
a
document
that
that
is
a
living
document.
That's
that's
helping
us
guide
our
work,
but
we're
not
spinning
endlessly
on
it.
Does
that
make
sense,
I
mean
I,
really
think
the
the
hackathon
and
some
of
the
smaller
pieces
that
have
been
or
some
of
the
documents
had
been
coming
forward
in
the
last
six
months
to
a
year
have
been
I
think
we're
turning
the
corner,
we're
making
some
progress.
F
I'm
reporting
on
the
document
was
a
result
of
the
hack.
Can
anyone
hear
me
with
the
speakers?
I
can
hear
me.
I
have
no
monitor
okay,
so
I'm
talking
about
the
document
that
was
the
output
of
the
hackathon,
not
in
Singapore,
but
before
that
everything
was
Prague
and
there
we
for,
for
the
first
time
coupled
the
statement
message
in
excess
de
schema
and
output
of
young
push
s
in
excess,
the
XML
represented
data
format
and
to
come
back
to
that
single
sheet
of
music
paper
I
see
we
did
that.
We
tried
that
this
is.
F
This
is
basically
the
draft
that
is
the
coupling
of
yang
push
with
the
second
statement
structure.
The
second
statement
structure
is
supposedly
to
be
the
music,
that
is
the
representation
talk
between
or
exchange
between,
every
second
component.
It
is
a
containing
meta
that
it
knows
about
the
components,
and
it
is
most
certainly
possible
to
combine
every
second
component
in
a
single
endpoint
to
have
a
box.
That
is
all
of
it.
F
It
might
be
unfeasible
in
some
variations
Mario's
having
the
orchestrator
in
all
the
repositories
in
the
collectors
at
the
same
box,
but
it
most
certainly
was
architecture
of
ice
possible
again,
whether
its
current
one.
Maybe
it
doesn't
look
like
it,
but
it
certainly
was
the
plan
for
a
long
time.
So
have
these
components
like
architectural
components,
you
can
base
the
aggregate
in
a
single
endpoint.
That
then
assesses
other
targeting
points,
and
so
why
didn't
we
update
the
XMPP
grid
yang
push
draft
is
because
my
confusion
about
the
architecture
and
until
I
know.
F
F
We
have
a
second
component
as
the
originated
of
data
to
the
second
domain,
and
then
this
with
data
there
between
repositories,
evaluators
and
other
components
and
I'm
fine
with
that,
and
then
we
can
introduce
that
a
single
sheet
music,
basically
again,
which
is
the
second
statement
which
is
currently
also
defined
in
the
I,
think
also
expired.
Information
model
correct
the
information
models,
expire.
W
F
So
everything
we
require
is
basically
there.
You
just
have
to
use
it
and
implement
stuff
based
on
it.
So
we
have
the
generic
container.
That
is
conveying
data
between
all
components
and
we
have
a
very
valuable
source
that
yang
now,
because
pretty
much
every
Idol
server
and
electrical
component
can
have
a
representation
of
Yang
and
some
points.
I
guess
from
that
comes
to
call
me
whatever,
and
so,
if
we
are
pursuing
that
role,
that's
good
I
understand
the
sentiment
that
a
large
interest
group
once
a
agent
on
the
endpoint.
F
If
it's
a
user
device
and
that's
okay,
we
have
the
ECP
model,
and
that
is
perfectly
defined
in
that
problem
and
even
for
some
servers
if
the
policy
defines,
but
that
is
outside
the
scope
of
UN
push.
So
we
have
this
multiple
collect
methods
and
as
soon
as
we
agree
on
how
to
proceed
with
combining
the
zoo,
again,
I
think
we
can
update
a
draft,
but
before
that
it
doesn't
really
feel
feasible
to
me
to
put
work
into
that.
But
I
think
we
are
close.
F
T
T
You
used
it
to
identify
the
threats
and
well
the
rapidity
of
the
device
and
then
to
enforce
security,
huddling
measurements.
Okay,
this
is
the
overall
structure
of
the
entire
security
baseline
in
generator.
It
is
defined
divided
into
three
layers
as
a
application
layer,
the
network
layer
and
as
the
infrastructure
layer.
But
in
this
specific
draft
we
only
focus
on
the
data
plane,
skier
functions
in
network
layer
that
protects
as
a
data
plan
traffic
against.
He
was
dropping
that
that
tapping
the
forging
and
the
flooding
attacks.
T
T
T
They
are
layout
to
protection,
ARP
protection,
the
you
RPF
and
DHCP
spoofing,
the
CPU
protection
and
the
tcp/ip
attack
the
defense
in
the
layer
to
protection
function
at
a
section,
for
example,
in
we
select
the
configuration
parameters
of
McNamee
control
and
be--you'd
emesis
expression,
and
for
the
erp
protection
of
section,
for
example,
we
we
selected
a
configuration
parameters
of
the
erp
and
his
booking
and
the
arp,
and
he
flooding
her
functions
and
the
you
are
PF
you
RPF
section.
I
think
he
is
mo
most
to
change
the
section.
T
In
this
raft
we
found
the
the
UF
aur
PF
p,
RPF
parameters,
always
only
the
ways:
the
Q,
the
Q
as
the
Q
s
policies
and
the
Q
s
policies.
Policies
has
already
defined
that
you
know
another
draft,
so
we
just
reference
the
the
draft
and
all
augmented
and
another
another
most
change.
The
sectioning
is
a
CPU
protection
and
F
is
a
very,
very
big
in
aversion
over
this
draft.
Actually,
it
has
two
sections
called
data
plan.
T
T
This
is
another
draft
we
proposed
in
the
last
meeting
and
actually
all
the
sections
have
have
already
been
proposed
thing,
as
added
in
has
a
data
model.
So
if
we
we
don't
have
anything
else
to
do,
we
will
drop
this
work
next
this
in
the
next
step,
we
will
continue
to
simplify
the
current
as
QD
baseline,
and
we
will
also
consider
about
how
we
can
create
as
a
given
string
and
maybe
filtering
the
next.
We
when
interesting
her
how
our
can
be
combined
with
a
second,
even
even
information.
Well,
this
is
that
says.
AA
E
Me
either
response
to
you.
We
we
are
sure
that
we
search
other
yonder,
the
motor
in
young
category
and
country
are
the
data
mode
or
security
mode
or
the
security
modeling
data
plane
are
all
the
new
things
they
are
soon,
there's
no
the
same
similar
things
in
other
document.
Yes,
we
can
show
and
we
also
bring
another
another
document
to
talk
about
the
infra.
You
know
the
infrastructure,
layer,
security,
security
attributes
and
security
models.
I
think
that's
also
new.
We
also
talk
I've
done
this
such
work
so
yeah.
AA
There's
nothing
that
I
that
I
was
aware
of
yeah.
So
if
this
is
on
new
yang
modules,
from
from
my
perspective,
if
you're
providing
value
to
the
to
the
yang
module
ecosystem
by
defining
something
new,
then
that's
that's,
probably
beneficial
I'm
less
sold
on
linking
all
of
this
in
tightly
to
the
rest
of
the
sacrum
work.
I'm,
not
sure.
If
doing
alignment
with
something
like
the
information
model
is
going
to
be
beneficial
in
the
long
run,
I
think
you
guys
are
doing
something
beneficial
and
it's
okay
to
just
do
that
and.
W
AA
G
A
E
Yes,
we're
good
question
yeah,
actually,
yeah,
wait,
wait,
I,
think
this.
This
work
has
has
benefited
for
all
the
big
vendors
device
vendors
because
take
heart
away
as
I
example
that
a
country
in
for
our
devices,
we
sell
a
lot
of
network
devices
to
most
several
big
operators
in
the
network,
and
we
always
face
the
requirement
that
our
customer
need
us
to
provide
some
automatic
way
to
to
to
track
their
security.
We
recorded
as
the
static
a
security
posture
to
in
to
to
to
to
provider
this
kind
of
thing,
this
kind
of
service
to
them.
E
C
F
C
T
The
opportunity
of
law
actually
is
a
similar
with
the
priest
one.
We
want
to
defy
a
minimal
set
of
network
device,
infrastructure,
layer,
security,
attributes
that
can
be
collected
by
the
second
collector
and
further
consumed
by
the
second
evaluator
to
benchmark
the
device
q,
repo
postures
next
one.
We
have
already
showed
this
this
figure
in
the
previous
presentation,
but
the
difference
is
in
this
specific
drafter.
We
only
way
owning.
T
T
Here
are
the
four
sub
modules
contending
the
data
model
and
the
integrator
a
measurement,
awkward,
cryptography
security,
the
key
management
and
the
certificated
management
lines.
Great
T
measurement
is
to
protect
the
upper
layer
of
software
applications
as
a
kernel,
the
the
early
stage,
executable
code
from
replacement
and
the
champion
in
the
up,
put
stripping
and
updating
of
phases
and
the
key
points
over
this.
T
Talk
of
cryptography,
the
hash
functions,
the
met/met
message,
authentication
code,
it's
a
kata
variation
function
and
also
the
random
number
generator
in
the
in
the
key
management
server
modules.
We
collects
as
a
configuration
in
status
parameters
of
the
key
to
check
if
the
key
is
create
enough
in
its
entire
life
cycle,
from
generation
to
destroy
and
in
the
lab
last
sub
module.
We
collected
a
certain
information
and
the
configuration
data
for
the
devices
who
request
to
update
to
vary
the
certificate
and
also
where
we
include
the
Cir
updates
configuration
data
in
that
sub
module.
Okay.
T
Next,
the
next
step
we
we
want
to
or
needed
to
complete
is
a
this
infrastructure
layered
in
a
model,
and
we
needed
think
about
how
that
you've
defined
that
a
model
can
be
consumed
by
the
existing
protocols,
and
maybe
we
need
how
seen
a
thing
about
how
the
selected
attributes
you
know.
Data
model
can
be
evaluated.
Okay,
that's
all
any
comments.
O
E
Z
AE
AF
AF
C
K
A
Z
A
AF
First,
a
brief
recap:
this
documentaries
are
part
of
the
security
baseline
work
as
previously
introduced,
and
we
try
to
provide
a
minimal
set
of
configuration
and
the
stators
requirements
for
the
network
network
devices
and
a
young
duty
model
is
provided
and
an
appendix
is
added.
In
this
version
we
will
illustrate
all
the
existing
network
models
and
some
other
reuse
the
paths.
So
next,
please,
in
last
nighti
of
meeting
we
were
asked
about
the
difference
with
Idris
I
at
USF
work,
and
there
are
two
main
points.
AF
First,
I
try
self-focus
focuses
on
the
flow
base,
the
NSF's
and
well
this
document.
We
work
on
the
we
work,
our
network
infrastructure
devices,
including
network
security
devices
and
and
as
well
as
the
routing
and
forwarding
devices
and
the
second
I
join
self
focus
on
the
iTunes
as
policies
rules,
provisioning
and
the
network
security
status.
Monitoring
in
this
documentary,
we
work
on
the
configuration
security
of
account
management
system
management
and
the
log
and
the
file
system,
and
also
check
the
security
status
of
all
this
system
management
work.
AF
We
try
to
provide
the
network
operations
security
next
plane.
This
page
is
an
overview
of
the
whole
structure
in
this
document.
There
are
four
paths,
as
we
presented
at
last
meeting.
We
have
made
several
updates.
Let's
have
a
look
next,
please
so
for
account
management
security,
the
configuration
security
subtree
was
added
to
provide
security
controls,
an
account
names
and
the
password
configuration.
AF
AF
So
next,
please,
and
therefore
the
second
part
is
a
system
management.
Security
of
the
authorization
rules
was
a
commentator
for
the
net-net
account
security,
subtree
and
also
a
new
subtree
was
a
leader
to
capture
the
current
status
of
the
available
system
house
and
the
Chris
panting
values
can
be
used
to
compared
with
communication
matrix
for
the
system.
Posture
posture,
security
assessment.
AF
Next,
please,
and
the
last
two
parts
are
the
log
security
and
the
file
security
for
log
security,
sub
module.
It
is
defined
at
you
how
to
configure
the
log
rules
and
the
security
protections
and
to
check
whether
the
some
events
are
recorded
and
well
whether
the
security
controls
are
activated.
The
log
record
subtree
is
used
to
describe
what
events
will
be
recorded
and
another
another
subtree
alert
notifications
to
configuration,
configure
the
threshold
that
during
alerts,
abnormal
activities
and
the
third
patch
is
a
log
overflow
action.
This
this.
AF
This
is
about
what
action
will
be
taken
to
do
with
the
log
overflow,
and
the
last
patch
is
what
we
have
defined
in
the
last
version,
so
for
the
5,000
security
remaining
care
about
security
of
the
localized
or
the
files
and
there's
a
remote
transfer.
So
there's
all
the
updates.
Next,
please
also.
We
are
soliciting
comments
and
we
have
considered
about
our
next
steps.
First,
we
all
continue
refining
the
data
model
and
we
will
try
to
adaptor
to
attempt
to
the
data
model
to
support
the
combination
with
the
yam
pushing
mechanism
and
the
third.
AF
A
C
C
So
anyway,
I
think
we've
had
a
productive
meeting.
I
think
the
best
thing
to
do
the
one
question
I
do
have
is
we
have
historically
done
virtual
interims
to
help
us
keep
them
the
work
moving
forward.
Do
we
think
a
virtual
interim
would
be
productive
between
now
and
wherever
we
are
next
Montreal
um-hum?
If
you'd,
like
a
virtual
interim.
C
Okay,
so
we
will
work
on
scheduling
the
virtual
interim.
One
of
the
things
that
Chris
and
I
haven't
had
a
chance
to
do
is
to
go
back
and
look
at
our
current
list
of
milestones
and
update
those,
and
so
we
will
be.
We
will
be
doing
that
between
now
and
the
next
virtual
interim
I'd
like
to
get
some
realistic
dates
on
these
milestones.
Go
ahead.
X
H
V
C
AB
Bret
Jordan
scheduling
things
during
RSA
for
those
of
us
that
you
know
work
for
vendors,
it's
near
impossible
are
it's
literally.
We
are
scheduled
23
hours
a
day
during
RSA,
so
trying
to
do
anything
else
would
be
just
a
nightmare.
So
please
for
the
love
of
all
things
holy.
Let's,
let's
not
you
know,
and
an
RSA
this
year
being
pushed
back
a
month
or
a
month
and
a
half
whatever
is
just
throwing
everything
off.
C
AB
A
M
L
Kind
of
a
little
hint
like
bring
up
the
work
say
that
you
know,
there's
yang
modules,
make
sure
they
cover
what
you
want.
There's
this
there's
that,
like
different
aspects
that
are
of
interest
to
whomever
you're
talking
to
to
see
if
they'd
be
interested
to
review,
work,
expand
its
implements,
be
a
customer
of
it.
Whatever
the
case
may
be
just
kind
of
just
putting
that
thought
out
there.
So
this
can
this
grow.
I
I
think
this
work
could
have
a
lot
of
value,
but
we
just
have
to
see
it
expands
more
and
get
more
interest.
AB
Brett
Jordan
yeah,
so
I
would
follow
on
with
what
Kathleen
said
as
I
see
in
a
lot
of
SD
O's
and
a
lot
of
working
groups
and
technical
committees,
we
are
approaching
what
I
would
call
a
PR
problem
and
we
need
to
figure
out
ways
that
we
can
talk
about
it
and
we
can
help
people
understand
and
going
into
a
group
or
people
at
RSA
and
talking
about
yang
models.
They're,
not
gonna,
understand
what
the
dumb
foam
foam
we're
talking
about.
AB
O
Hi
Sherif
Mansour,
but
this
time
as
a
board
member
of
the
OS
bound
ation,
we
would
love
to
help.
So
in
june
we
have
a
one
week,
long
hackathon,
outside
of
london,
in
a
retreat,
and
we
just
it's
it's
a
non-conference.
Basically,
it's
just
like
a
week-long
hackathon
and
then
we
present
the
output.
We
have
AB
SEC
EU
again
in
London
in
the
beginning
of
July,
which
we
present
the
outcomes
of
that
and
we
present
it
and
it's
open,
livestreams
and
accessible
to
everyone.
So
that's
also
a
way
of
promoting
a
lot
of
the
work.
O
C
That's
very
good,
so
I
think
with
that
we
reach
we've
reached
the
top
of
the
hour
and
managed
to
go
late,
yay.
No,
no,
not
not
you
I
mean
so
so.
Promotion
at
RSA,
great
in
a
virtual
interim
after
RSA,
great
Chris
and
I'll,
take
a
look
at
milestones
and
annual
sends
them
updating
to
the
list.
Thank
you
all
very
much
I
think
we've
had
a
productive
session
today
and
enjoy
the
rest
of
your
week.
What's
left
of
it.