►
From YouTube: IETF95-SACM-20160408-1220
Description
SACM meeting session at IETF95
2016/04/08 1220
A
A
A
A
A
C
Okay,
hi,
hi,
I'm,
Hank
and
I
will
not
give
you
a
actual
report
today
what
things
that
have
been
done,
because
that's
happened
at
the
last
virtual
interim
today,
we
will
look
at
a
few
terminology
in
terms
that
are
in
the
queue
and
about
to
be
processed.
This
is
also
connected,
somehow,
of
course,
to
the
work
we
did
yesterday
on
the
information
model,
so
next
line
yeah.
This
is
just
to
reiterate:
what's
this
about
the
terminology
is
a
complementary
task
that
aligns
inconsistencies
across
drafts.
It's
it
was
this.
C
C
We
have
a
specific
at
some
specific
points
and
drafts
like
the
information
model
and
determine
ology
and
the
architecture
and
the
indication
that
the
information
model
is
about
data
in
motion
and
not
actually
about
data
and
rest,
and
that's
the
current
understanding.
I
think
this
is
going
to
be
an
issue
on
the
terminology,
because
I
don't
think
that
everybody
will
agree
and
from
the
top
of
my
head,
I
think
if
Jim
would
be
in
the
room,
you
would
object.
So
we
have
to
clarify
on
this.
C
It
is
most
certainly
about
data
emotion,
but
somehow
it's
also
about
that
unrest
and
we
have
to
define
those
terms,
put
them
in
the
architecture,
I
guess
as
a
plan
and
then
be
sure
about
whether
here
so
this
will
be
in
addition
to
the
ID.
This
will,
of
course,
shopping
for
that
doesn't
quite
go
ahead.
Right,
no
problem,
you've
actually
don't
forget
yeah.
Unfortunately,
we
have
a
question
on
data
model
again,
and
this
is
an
issue
we
have
to
resolve.
Please
do
not
throw
a
stone
at
me.
It's
a
very
simple
issue.
C
It
is
not
a
showstopper.
It
can
be
decided
why
we
go
on,
but
the
Inca.
The
idea
that
the
after
the
presentation
on
wednesday,
that
the
information
model,
for
example
for
could
somewhat
subsume
fields
of
the
Swit.
It's
not
a
definition,
and
there
there
are
two
representation
formats
for
splits
at
the
moment
which
are
XML
in
the
upcoming,
concise
representation,
see
bore
and
that
those
are
basically
the
same
data
on
order.
C
I,
don't
know
that
everybody
agrees
on
that,
so
I
will
just
put
a
basically
that
question
the
issue
tracker
is:
are
those
two
representations,
the
same
or
different
data
models
and
then
why
we
just
proceed
and
resolve
that
question
which
is
open?
I
think
we
can
solve
that,
and
the
underlying
notion
is,
I
think,
that's
just
a
different
serialization
or
a
different
data
model,
and
I'm
not
sure
about
this.
So
again
we
have
to
define
civilization
in
context
to
get
our
models
and
then
be
done
with
that.
That's
just
a
task.
C
D
E
D
I
think
we
brought
this
conversation
up
in
the
context
of
squid
tags
and
different
different
vine
days,
so
things
like
c4
and
XML
are
definitely
different.
You
know,
serialization
methods,
I,
think
the
challenge
with
purely
and
and
well
they're
different
serialization
methods
they
effectively
implement
the
same
data
model.
I
think
the
challenge
that
we
run
into
is
there
are
processing
requirements
around
XML
or
XML
signatures
or
see
Boris
signatures.
That
vary
slightly.
D
So
even
though
there's
the
serialization
Tsar
effectively
implementing
the
same
data
model,
there's
slightly
different
processing
requirements
that
need
to
be
invoked
in
order
to
properly
sinus
would
tag
and
validate
a
signature,
and
so
it's
important
that
the
distinction
that
we're
making
between
data
models
and
serialization
allows
for
some
flexibility
and
how
we
handle
some
of
those
operational
kinds
of
considerations.
Yeah
I.
C
D
C
Okay
next
slide,
please.
E
C
Clear
a
few
days
ago
that
it's
now,
but
it
will
be
clear
again
and
it
is
a
introducing
a
second
vocabulary,
which
is
a
new
term
that
will
be
added
to
the
information
model
and
we
will
not
use
every
imaginable
data
information
element
out
there.
We
will
concentrate
and
focus
on
the
things
you
want
to
ask
about,
for
example,
but
a
good
example
is,
of
course,
a
query.
C
If
you
have
a
query
in
a
second
domain
to
retrieve
some
more
complex
data,
you
have
to
at
least
have
a
hook
that
you
can
identify
a
specific
set
of
items
that
you
are
interested
in,
so
those
are
most
certainly
excusa,
most
certainly
based
on
fields
or
data
elements
that
are
defined
in
other
representations,
for
example
switch.
And
so
we
have
to
have
a
common
understanding
and
the
second
domain
how
to
retrieve
an
next
I
peace.
C
Unfortunately,
the
definition
of
a
second
domain
is
a
little
fuzzy
at
its
edges.
There
is
the
sort
of
the
open
question
of
if
an
internal
collector
is
exactly
actually
a
part
of
the
second
domain,
or
is
it
not
too
high
that
this
an
internal
comm
collector?
It
resides
on
the
target
and
point
it's
basically
software
the
owner
put
there,
and
that
is
able,
for
example,
to
self-report,
and
there
are
notions
that
this
should
be
not
a
part
of
a
second
domain,
the
notions
that
this
should
be
a
second
component.
So
maybe
it's
both.
C
It
has
to
be
defined
in
order
to
make
a
complete
definition
here.
I
think
so.
My
proposal
is
that
the
editor
office
of
the
existing
paths
might
maybe
agree
on
this
and
then
go
on
yeah.
That's
basically
the
same
next
slide,
please,
in
contrast
to
being
a
target
in
point,
there
is
no
a
kind
of
designation
that
you
can
associate
it
with
each
bit.
C
Basically,
every
endpoint
and
that's
the
excluded
endpoint
a
target
endpoints
that
you
specifically
do
not
one
to
assess
basically
so
they're,
not
a
target
and
points
every
mother,
what
excluded
endpoints
and
every
endpoint
a
pair
default
is
a
target
and
point,
but
the
second
components,
endpoints
that
contain
second
components-
are
an
exception
from
this
room,
but
then
again
could,
for
example,
may
be
made
accessible
by
explicitly
hiding
this
targeting
points.
That's
a
mechanism
we
haven't
talked
about
yet
a
lot.
C
So
there's
no
technical
understand
how
this
should
could
look
at
in
the
end,
but
maybe
it's
feasible
to
highlight
this
earlier
on.
So
there
can
be
some
solution
for
this.
In
the
end,
this
will
be
included
in
it.
Initially
the
existing
definition
of
the
extruded
and
pointed
and
an
issue
will
be
raised
on
the
github
next
slide.
Please
next
sorry.
C
Yeah,
I
added
a
definition
of
management
plane
to
the
terminology
which
is
new.
There
aren't
any
very
well
written
definition
out
there
that
I
could
find
if
you
have
a
comment
that
is,
if
you're
interested
in
what's
different
between
a
control,
plane,
dimensional
plane,
just
have
a
look
at
the
terminology.
C
Maybe
shake
your
head
right
to
the
list
this
long.
It
should
be
that
so
please
review
and
comment
especially
this
definition,
because
that
would
be
the
first
definition
of
mention
plane,
I
think,
is
happens
in
the
ITF.
Maybe
I'm
wrong,
maybe
I'm
just
bad
at
googling.
So
this
specific
item
I
would
recommend
everybody
in
the
room
and
on
the
listed
in
the
back
group
through
a
look
at
please
because
it's
beyond.
Second,
this
definition
I
guess
next
slide.
Please.
C
Yesterday
we
looked
at
the
introduction
of
the
information
modeling
for
the
list
of
tasks.
These
are
a
little
bit
outdated,
not
taking
into
account
our
current
development,
and
now
we
have
a
new
list
of
tasks
which
is
the
premier
minute,
and
then
he
will
elaborate
on
next
lot.
So
this
is
just
a
list
that
will
at
some
point
in
time
update
or
add
items
or
next
slide.
C
C
A
Questions
on
the
terminology,
work
can
I,
just
ask
you,
and
you
might
have
told
me
this
and
I
forgotten,
but
it
is
friday.
After
all,
what's
the
timeline
for
this
like
what
are
the
next
steps.
C
C
Think
it's
about
in
ninety
percent,
complete
defense.
It
actually
depends
on
how
fast
moving
the
other
drugs
out
there.
If
there
is
an
overhaul,
an
essential
one,
it
would
be
whatnot,
but
not
be
the
last
laugh,
but
the
last
next
graph
is
supposedly
really
stable.
We
could
we
could
make
a
call
on
it
may
be
my
personal.
That
would
be
the
and
in
two
iterations
will
be
the
last
laugh
because
the
next
iteration
might
just.
C
C
C
D
It
will
try
er,
so
so
as
we're
addressing
the
drafts
incrementally,
we
might
want
to
update
the
terminology
draft,
but
on
the
lines
of
this
conversation
it
would
be
probably
good
to
do.
A
working
group
last
call
on
the
draft
once
we
get
it
to
a
stable,
State
Park
it
until
we
need
to
update
it
again,
use
that
as
a
as
a
way
of
drawing
a
line
in
the
sand,
essentially
based
on
the
current
terminology,
yeah.
A
That's
actually
the
the
point
I
was
getting
to
us
at
what
point
do
it
do
we
agree
on
the
terms
that
are
in
their
name
and
then,
if
we
need
to
add
to
them,
that
would
be
great,
but
we
need
consensus
that
these
are
the
terms
we're
going
to
use
and
these
the
way
these
terms
are
defined.
Mm-Hmm
I
think.
C
F
Cool,
so
sorry
just
to
disappoint
and
probably
not
going
to
talk
about
the
tasks,
because
I
Hank
ended
up
talking
about
him,
so
I
kind
of
took
him
out
of
the
slides,
but
it's
all
right.
Yeah.
Now
we
got
mixed
up
there,
but
so
anyways
I
just
want
to
give
a
quick
update
on
what
we've
done.
Since
the
last
session,
I
can
go
to
the
next
slide,
basically
kind
of
broken
down
to
two
things.
F
We
had
a
breakout
session
on
Wednesday
after
the
sack
of
meeting
where
we
discussed
a
variety
of
different
information
model
topics
and
then
Hank,
Nancy
and
I
work
to
kind
of
start
merging
together
the
text
between
the
texts
they
provided
in
the
information
model
that
they
submitted
on
like
march
twenty
first
and
then
the
current
working
group
information
model.
So
we
go
to
the
next
slide
so
basically
for
the
breakout
session.
Most
of
this,
it's
all
on
the
list,
but
I
just
figured
I'd
highlight
the
the
main
points
that
were
kind
of
covered.
F
So
one
of
the
big
things
is
Hank
mentioned,
is
kind
of
just
resolving
whether
or
not
sockem
discusses
information
in
most
motion
verses
or
data
in
motion.
Verse
data
at
rest
kind
of
currently
thinking
that
the
sacrament
deals
with
the
data
in
motion
and
then
it's
up
to
implementers
to
decide
how
they
store
that
information
with
the
understanding
that
they,
you
know,
Sakon
components,
can
push
information
and
get
information
from
the
data
stores
in
some
standardized
way.
Thus
far
is
so
we
had
between
the
two
information
models.
F
We
had
a
couple
different
names
for
some
of
the
core
constructs.
There
is
attribute
and
atomic
information
element
and
kind
of
out
of
the
working
group
breakout
session.
We
decided
that
attribute
was
a
good
name
that
we
could
keep
and
then
we
also
had
object
in
a
composite
information
element
and
actually
out
of
the
breakout
session.
It
was
kind
of
decided
at
least
you
know,
as
a
proposal
to
the
working
group
that
may
be
subject
would
be
a
better
better
option
and
and
I
guess,
there's
a
slight
difference
in
how.
F
Defined
it's
basically
a
name
with
essentially
a
collection
of
attributes
or
other
subjects
associated
with
it,
and
that's
actually
that
new
definitions
in
the
revised
individual
draft
and
I'll
be
sent
out
to
the
list
for
kind
of
discussion
and
see
if
it
makes
sense
to
everyone
and
then
there's
also
some
discussion
around
sockem
content
elements
and
statements.
And
this
was
something
new
in
the
individual
draft
information
model
and
I.
E
F
So
basically,
the
approach
we
took
with
the
information
model
merger
was
because
it's
a
lot
easier
just
to
update
an
information
or
individual
draft.
We
basically
took
text
from
the
current
information
10
from
the
working
group
1
and
copied
it
over
into
the
individual
draft
and
kind
of
just
work
together
to
kind
of
combine
it
and
revise
it,
so
we're
both
happy
with
it
and
basically
what
we
did
then
is
kind
of
point
out.
You
know:
where
does
this
information
now
go
in
the
current
working
group
information
model?
F
And
basically
we
want
to
put
all
those
kind
of
decisions
out
to
the
group
to
look
at
and
make
a
decision
on.
So
next
slide,
so
basically
I
just
want
to
kind
of
highlight
the
the
key
areas
and
things
that
the
decisions
that
the
group
needs
to
make
and
once
the
updated
individual
drafts
up
on
on
the
working
group
page,
we
can
point
to
that.
F
In
you
know,
we
already
have
the
working
group
doctoring
up
there,
and
people
can
actually
look
at
the
text
that
you
can
see
what
they
think
and
you
know,
providing
feedback
that
they
want.
So
basically,
the
abstract
in
the
the
working
group
document
was
just,
as
you
know,
a
single
line
saying
you
know.
Here's
information
all
for
the
sack
of
marking
group
provides
a
little
bit
more
information
kind
of
talking
about
how
it
defines
the
information
needs
for,
for
sockem
kind
of
that
are
based
on
the
the
use
cases
that
sack
them
defined.
F
Now,
if
the
group's
okay
with
that,
but
that's
going
to
kind
of
be
pulled
in
there
and
then
obviously
or
I
guess
in
the
working
group
draft,
we
also
have
some
subsections
explaining
you
know
how
to
use
the
IP
fix
and
tax
with
respect
to
attributes
and
objects
will
keep
that
in
there.
Even
though
we're
going
to
change
some
of
the
text
kind
of
describing
what
what
the
different
structures
are
excellent.
F
So
then,
as
I
mentioned
before,
I
think
there's
some
more
discussion.
We
have
to
have
with
sockem
statements
and
content
elements,
so
I
think
really
before
we
consider
whether
or
not
we
merge
that
text
in
I
think
we
have
to
just
decide
whether
it's
needed
and
if
the
group
agrees
with
the
text,
so
that's
more
of
a.
We
have
to
just
kind
of
send
that
out
for
feedback
relationships
and
of
events,
those
are
sections
in
both
information
models
and
I
know
at
least
well
in
the
current
information
model.
F
F
It's
basically
just
a
list
of
different
information
elements,
and
we
need
to
consider
them
to
see
you
know
whether
or
not
we
want
to
pull
them
in
if
we
do
basically
just
have
to
convert
them
to
the
IP
fix
syntax
and
we
can
drop
them
in
section
5
of
the
the
current
information
model
and
excellent
and
then
so
yeah
with
that,
that's
pretty
much.
The
update,
basically
I,
see
kind
of
the
next
step
is
taking
these
different
actions
and
opposing
the
different
questions
to
the
to
the
list.
F
So
I
think
so.
F
Few
items
in
the
table,
those
are
rated
I,
think
have
a
decision.
We
made
whether
or
not
they
should
be
included.
So
as
soon
as
we
have
the
updated
draft,
where
people
can
the
updated
individual
draft,
where
people
can
look
at
the
revised
text,
I
think
we
can
just
send
out
emails
to
a
list
saying:
okay,
here's
the
new
text.
What
do
you
guys
think
if
everyone's
okay
with
it,
you
know
we
can
pull
it
up
and
so.
A
F
A
E
A
So,
potentially
the
week
of
May,
sixteenth
and
the
week
of
June
twentieth
is
what
we're
currently
looking
at.
Is
anybody
aware
of
major
conflicts
for
those
weeks
at
this
point
a
week
of
May,
sixteenth
or
the
week
of
June
twentieth
obviously,
will
reconfirm
this
on
the
list
and
we'll
set
up
doodle
polls
for
specific
in
those
times,
I
just
want
to
know
if
there's
a
like.
G
The
TCG
meeting
complex
on
the
20
jun
20
cg
meeting
complex
with
it
June
twentieth.
A
B
H
I
E
E
Meantime
we
have
a
call
on
the
the
swig
document
that
we're
going
to
put
out
the
call
for
adoption
on
that.
A
couple
of
other
I
guess:
administrative
things
for
that
that
I
guess
qualify
for
way
forward,
but
we're
going
to
reevaluate
the
list
of
conflicts
that
we
have
in
this
group
so
that
it's
easier
to
schedule.
Two
sessions
wider
apart
in
future
meetings,
so
be
on
the
lookout
for
that
I.
Guess
we'll,
probably
concentrate
on
chairs
and
you.
E
Authors,
critical
editors
and
the
other
thing
to
talk
about
is
how
we
use
github.
So
up
till
now,
we've
been
doing
one
github
repository
poor
draft
and
there
were
a
few
options
to
look
at
you
know:
should
we
move
to
having
11
github
repository
for
all
the
drafts,
one
ker
draft,
or
perhaps
one
repository
for
related
drafts,
and
a
present
thinking
at
this
point
is
that
we'll
use
one
github
repository
for
related
drafts
to
kind
of
help.
Excuse
me
prove
this
out:
we've
created
a
vulnerability
scenario
repository
that
will
hold.
E
It
actually
already
has
the
existing
vulnerability
repository
vulnerability
assessment
draft
in
it,
but
it
can
also
hold
additional
drops
related
to
that
scenario.
So,
for
example,
if
we
do
need
to
create
a
vulnerability
detection
data
format
that
could
go
in
that
same
repository,
if
you
know
we
will
put
this
out
on
the
list
as
well,
but
I
kind
of
wanted
to
get
a
sense
in
the
room
for
any
objection
to
having
one
repository
for
related
drafts.
I.
F
F
C
The
sink
sorry
I
have
a
question.
So
what
I
hear
from
this
is
the
period
by
might
be
end
up
with
two
repositories.
One
of
them
includes
the
I,
don't
know
stuff.
We
that
originates
from
the
second
group,
the
other
one,
that
with
solutions
that
are
then
adopted
its
second
solutions.
This
quick,
this
looks
like
it
isn't
a
little
bit
like
there's,
not
really
a
second
there,
just
a
little
bit
more
I,
don't
know
now,
I
just
thought,
maybe
I'd
understood
it
wrong.
I
can't
hear
you
you.
E
C
A
D
Was
just
gonna
say
this
is
Dave
Wallace
fire
we're
trying
to
we're
hoping
to
move
quickly
on
getting
to
a
working
group.
Last
call
on
the
vulnerability
assessment
scenario.
I
think
that'll
be
largely
driven
by
the
amount
of
discussion
and
feedback
that
we
that
we
get
on
on
the
draft.
But
if
we
can
get
a
good
amount
of
discussion,
I
think
we
would
like
to
have
a
working
group
last
call
before
Berlin.
If
we
can
get
there,
yeah.
E
I
agree:
I
submitted
a
pull
request
to
the
vulnerability
scenario
this
morning
or
technically
this
afternoon.
You
might
look
at
it
because
I
created
a
related
issue
as
well.
That
just
said
there
was
a
lot
of
stuff.
I
wanted
to
see
improved,
so
I
just
did
a
poll
request,
so
we
should
review
that
have
some
discussion
about
it
and
hopefully
it
clarified
made
it
a
little
shorter,
more
concise
and
thank
you
yeah,
and
that
was
as
contributor.
I
don't
know
if
I
have
to
say
that
or
not,
but.