►
From YouTube: IETF106-SACM-20191119-1000
Description
SACM meeting session at IETF106
2019/11/19 1000
https://datatracker.ietf.org/meeting/106/proceedings/
D
E
F
C
F
F
F
F
F
This
is
the
agenda
that
we
have
for
today
we're
going
to
rejigger
it
slightly
to
allow
a
couple
folks
that
need
at
least
one
person
that
needs
to
leave
to
leave.
So
the
first
thing
we're
going
to
cover
real
briefly
is
the
status
of
the
coast.
Word
document
and
the
early
document
which
have
both
completed
working
group
last
call,
and
then
at
that
point
we
will
proceed
with
the
agenda
as
it
is
so
any
other
agenda
bashing.
G
F
I
F
J
Okay,
so
the
role
a
software
descriptor
document
has
gone
through
working
group
last
call
and
has
received
a
decent
amount
of
review
and
feedback.
That
feedback
has
been
integrated
into
the
most
recent
version
of
the
document.
It's
been
updated
and
I
believe
that
the
document
is
now
ready
to
move
forward
through
the
shepherding
process.
If
the
chairs
are
ready
for
that
as
well.
I.
F
K
Good
morning,
Dave
altameyer,
so
we
we've
completed.
It
feels
like
a
few
working
group
last
calls
on
on
coast
wit
at
this
point,
we've
gotten
a
ton
of
feedback
on
the
document
and
that's
all
been
addressed.
The
the
most
recent
feedback
we've
gotten
was
from
Kathleen
and
she
fixed
a
bunch
of
typographic
or
she
pointed
out
a
bunch
of
typographic
editorial
issues
that
were
fixed
in
the
latest
draft
that
was
posted.
K
She
did
raise
a
couple
of
issues
which
we've
there's
been
some
back-and-forth
on
the
on
the
list
about
I
wanted
to
raise
those
I'm
in
the
room,
just
just
for
awareness,
so
the
first
one
was.
She
was
suggesting
that
that
we
had
support
for
using
cosy
web
tokens
as
a
way
to
support
signing
in
the
coast.
Would
draft
I
suggested
that
it
was
pretty
late
in
in
the
hour?
As
far
as
you
know,
work
on
the
on
the
draft
that
we
were
looking
to
send
it
forward.
K
I
suggested
that
maybe,
if
there's
interest
in
pursuing
that
kind
of
solution
that
we
look
at,
maybe
writing
a
second
draft
to
describe
how
one
would
do
that
we
could
do
abyss.
As
well,
I
personally
like
to
see
you
know
more
implementers
raise
their,
you
know
their
opinions
as
far
as
what
kind
of
assigning
approach
that
we
would
like
to
see
in
the
draft,
so.
H
Hi
this
is
hang
from
the
Mike,
but
it
might
look
very
obvious
to
do
that.
I
I'm
using
CW
a
lot
for
a
lot
of
things
and
and
unfortunately
it
was
not
ready
at
the
Palmeri
started
the
reasons
why
haven't
done
that?
But
now
it's
a
small
lift
certificate
format.
It's
a
total
format,
so
they're
issuers
and
subjects
and
issue
a
date-
and
this
is
this-
is
redundant
semantics
to
coast
with
so
so.
I'm
I
have
no
way
of
breaking
semantic,
a
strict
division
of
semantics
when
we
include-
and
we
have
to
include
them.
H
Also
we
would
swamp
the
CWT
registry
with
roughly
80
to
100
new
items
and
I
think
that
trendy
in
there
right
now,
so
we
dominate
that
place.
Suddenly
I,
don't
I
know
it
could
be
done
and
if
there
is
a
good
use
case
for
it,
I'm
all
for
guiding
everybody
through
the
process,
because
I'm
I'm
not
sure
it's
in
the
solving
an
actual
problem.
K
Right
and
I
think
from
that
perspective,
there's
a
lot
to
talk
about
and
something
you
know
that
that
conversation
is
going
to
take.
You
know
a
number
of
months,
probably
to
conclude,
you
know
which
we'll
just
further
push
back
the
publication
of
coasted
and
but
I
think
I
think
what
I'm
proposing
as
a
way
forward.
Maybe
is
that
we,
you
know
we
published
coast
wit
as
is
and
and
that,
if
there's
interest
in
and
looking
at
a
CWT
based
signing
solution
that
we
have
that
as
a
separate
conversation.
J
J
K
Mean
given
given
that
they're,
given
that
there
are
integrity,
security
considerations,
you
know
relating
to
a
coast,
wid
and
I
I
think
the
the
responsible
thing
is
to
provide
at
least
a
signing
solution,
at
least
an
integrity
mechanism
as
part
of
the
draft
to
you
know
to
provide
for
that
integrity.
I
think.
If
we
were
to
pull
that
out,
we
would
be
providing
only
a
partial
solution.
K
J
This
is
Steven
as
Steven
yeah
I,
think
I
agree
with
Dave.
That
signing
is
pretty
important,
I
mean
if
we
look
at
some
of
the
interest
around
a
Swit
itself.
Signing
is
a
pretty
important
use
case
in
a
lot
of
places
and
it's
important
to
how
people
are
in
and
are
currently
using,
Swit,
yeah
and
I.
Think
if
you
want
to
fully
support
Swit
in
Khost,
wid,
then
signing
something.
That's
gonna
need
to
get
done
and.
H
Also,
we
need
signing,
because
otherwise
we
cannot
do
the
appraisal
policy,
reference
value,
known,
good
value,
stuff
from
the
servers,
and
the
draft
is
basically
done
and
we
have
to
do
a
reference
to
the
RFC,
and
that
is
very
important.
So
if
you
can't
sign
it
today
and
wait
for
the
next
iteration,
a
lot
of
people
will
be
kind
of
mad
yeah
right.
So.
L
I
feel
like
if
the
conversation
just
happened
so
managing
too
many
things
at
once.
As
chair
there
was
a
room
says
we
should
figure
out
how
to
do
signing.
Do
you
think
we
should
delay
for
adding
signing
to
the
draft,
because
that
part
wasn't
exactly
clear
to
me
and
then
humming,
something
like
a
full
Rios
cozy.
You.
H
M
J
Just
wanted
to
make
sure
that
Kathleen
had
a
couple
responses
and
I
want
to
make
sure
that
her
opinion
got
voiced
here
as
well.
She
agrees
that
signing
is
important,
but
that
multiple
methods
are
confusing.
Maybe
waiting
a
little
bit
makes
sense.
She's
worried
about
adoption,
not
just
getting
the
draft
out
the
door.
H
H
Also
and
I
do
I
think
that's
the
only
difference,
NEC
Tabuchi
res
it
registry
and
swamp
that
so
that,
basically,
that
is
the
only
addition
we
would
make
and
I'm
not
sure
if
you're
breaking
anything
before
or
after,
because
we
will
literally
use
the
same
signing
mechanism
where
there's
a
cozy
envelope,
both
of
them
use
them.
I.
Think
so.
Please
collect
me
if
I'm
wrong,
but
a
British.
H
L
Think
I
understand
the
you
know
the
room
I
want
to
take
it
to
the
list,
but
sounds
like
we
have
nominally
a
way
for
it.
I
just
want
to
have
a
finish
off
the
discussion
on
the
list
to
be
sure,
and
if,
if
the
case
is
that
there's
general
consensus
that
the
signing
that's
present
now
is
sufficient,
we'll
move
it
forward.
L
K
All
right,
then,
that
sounds
good
and
then
there's
there
was
one
other
issue
raised
by
Kathleen's
review
so
currently
for
identifying
hash
algorithms.
We
used
the
name
hash
algorithms
registry
in
Khost
wid.
She
was
suggesting,
maybe
that
we
align
that
with
the
cose
algorithms
registry,
which
uses
a
slightly
different
identifier
space
for
the
four
similar
algorithms
I.
Think.
The
challenge
that
we
have
is
one
of
algorithm
agility.
The
the
nice
thing
about
using
the
named
hash
algorithms
registry
is
it's
it's
just
hash,
algorithms.
K
If
we
were
to
point
to
the
Cosi
algorithms
registry,
we
would
need
some
way
of
pointing
only
of
selecting
out
of
that
registry.
Only
the
hash
algorithms,
because
those
are
the
only
algorithms
that
actually
makes
sense
to
be
used
and
in
in
this
context,
but
there
isn't
really
a
mechanism
to
do
that,
because
the
hash,
algorithms
and
the
cosy
registry
are
are
not
identified
in
any
different
way.
From
you
know:
signature,
algorithms
and
yeah
there's
a
good.
H
Reason
for
that,
because
Jim
shot
refused
to
do
simple,
hashing
and
cosy
for
years
and
and
only
a
few
months
ago,
he
kind
of
accepted
to
try
this,
so
there
is
now
a
hash
ID
in
cozy,
but
again
this.
We
started
this
work
like
years
ago
and
there
was
nothing
and
Jim
said.
No
we're
not
going
to
do
this
here.
This
is
something
that
could
be
visibility
to
include
another
valid
registry
for
hashing,
but
it
is
literally
not
necessary
because
the
AI,
an
unnamed
information
registry,
is
the
general
one.
H
So
if
we
use
algorithms
there-
and
you
want
to
assign
Jason,
for
example,
that
works
very
better,
then
we
are
going
to
use
the
cozy
specific
one
again.
But
this
is
something
we
can
discuss
the
next
iteration
of
this
document.
I
assume
it
is
not
a
blocker
today
and
because
the
other
document
is
not
done
also
is
actually
cool.
Yeah.
K
K
N
N
And
yeah,
and
back
on
the
CW,
T
I'm,
really
afraid
of
having
multiple
methods
and
then
just
something:
that's
only
used
for
coast
wit
and
not
used
elsewhere.
You're
gonna
have
random
developers
who
are
going
to
be
implementing
this
and
if
they're
using
something
that's
familiar,
you
know
CW
T,
which
is
yes
very
similar.
It
also
does
signing,
but
it
has
claims
as
well
and
is
in
a
registry,
then
I'm,
just
I
I
think
we'd
get
better
adoption
and
adoption
is
important.
F
F
H
H
N
N
You
know
there
might
be
other
things
that
you
want
to
attest
that
you
might
want
to
do
some
of
the
functionality
that's
being
baked
into
and
eat
where
you
have
the
nested
claims
and
just
following
that
same
structure.
So
if
you
have
dependent
libraries,
you
might
want
to
reference
them
within
your
larger
CWT.
You.
H
Side
I
think
there
already
is
basically
the
same.
We're
just
not
adding
the
CW
needs
egg
in
order
to
prohibit
people
to
sprinkle
in
CW
TV
claims
that
do
not
belong
into
the
thing,
because
if
you
are
CW
t
people
are
allowed
to
use
the
claim
there
and
that's
the
only
thing
we
wanted
to
prohibit
the
rest
is
actually
I.
Think
today
identical
you
can
even
using
a
CW
t,
positive
powers,
coach
read
at
home,
okay,.
N
Alright,
so
I
mean
I
read
the
document.
I
understands
cozy
I
was
the
ad
for
it,
so
you
know
I
I
get
how
all
of
this
works.
My
concern
is
developers
reading
this
and
you
know
someone
sing.
Oh
that's
just
a
CW
T,
so
I
just
use
this
package
and
and
just
get
it
done
as
opposed
to
how
its
described
now,
which
is
very
specific
and
into
the
weeds.
Oh.
H
K
K
Once
it's,
it's
published,
I'm,
trying
to
balance
the
interests
of
you
know
of
the
the
sort
of
initial
use
that
we
have
and
the
in
the
community
around
coasts
wid,
as
well
as
addressing
some
of
these
other
use
cases
and
I
like
to
find
the
path
forward
that
will
allow
us
to
you
know
to
to
to
Shepherd
the
draft
forward.
While
we
work
to
solves
you
know
some
of
these
larger
integration.
L
N
M
K
O
Toni
nedelin,
so
I
agree
with
Kathleen
I
mean
this
could
just
be
a
if
all
you're,
all
it's
all
it's
happening
is
the
claims
are
different,
they're,
not
in
the
same
namespace,
the
IANA
registry.
Then
it's
just
a
profile
on
top
of
on
top
of
CWT,
which
you're
allowed
to
do
so.
You
can
add
these.
You
know
you
can
do
the
extension
of
your
claims,
but
you're
actually
using
CWT
with
these
extension
claims
that
are
there.
Well,
we
don't
have
any
specific
claims
to
find
seven.
H
O
A
H
O
H
There
was
a
so
this
is
saying
finalizing
this.
There
was
a
good
reason
that
we've
created
a
own
SIBO
tech
registry
for
this,
because
we
wanted
to
have
there's
a
lot
of
claims
in
there
and
if
you
have
a
general
CWT
pasa,
you
create
a
lot
of
confusion
overhead
until
you
are
finally
understand
what
this
is,
because
they
are
not
safety
finding
safety
driving.
In
this
case,
you
have
to
parse
the
whole
thing,
and
now.
I
I
K
Okay,
so
so
we
have
an
action
to
do
that
and
I
just
wanted
to
finish
the
conversation
about
the
hash
identifier
registry.
So
my
emails,
the
Cosi
working
group
this
morning,
I'm
asking
for
advice
on
what
to
what
to
do
as
if,
if
it
will
be
possible
to
add
some
sort
of
label
to
the
cosy
algorithms
registry
that
would
allow
us
to.
You
know
just
point
to
the
you
know
to
the
hash
algorithms.
K
You
know
to
seek
their
advice
on
on
what
to
do
and
based
on
that,
then
we
can
have
a
conversation,
a
technical
conversation
about
whether
we
make
the
switch
or
whether
we
stick
with
the
the
named
hash
algorithm
registry
that
we
currently
use.
So
hopefully
that's
something
that
we
can
clear
up
on
the
list.
You
know
very
very
quickly
after
this
meeting,
but
those
are
basically
the
the
only
two
outstanding
issues
that
haven't
been
addressed.
H
Bit
on
the
on
the
frosting
pardon
that
is
kind
of
hard
so
bright.
This
is
why
I'm
here
again
Chanukah
at
my
could
we
have
some
deadlines
for
this
so
like
three
weeks
for
this
done
and
three
for
this
done
and
really
be
done
at
the
time
frame,
because
if
you
don't
get
this
out
this
year,
we
might
get
in
another
vicious
cycle.
Yeah
I.
K
K
F
N
H
H
F
H
F
F
K
F
F
H
H
So
so
the
thing
is
that
we
have
not
agreed
on
five
core
concepts
in
the
architecture
and
then
reviving
the
terminology.
Dolph
is
just
shining
words
around
without
any
real
target,
if
I
would
have
chimed
in
the
arc
in
in
the
architecture
document
again,
which
is
literally
at
no
time
for
sorry
and
rets,
covered
up
way
more
time
in
the
last
two
months
and
I
anticipated
so
I
couldn't
do
it.
So
yes,
I'm
partially
to
be
at
fault
here
and
I'm.
Sorry
to
the
group
that
there
is
no
open
document.
H
I
H
F
On
the
agenda-
and
they
have
some
slides,
so
we
will
be
talking
about
the
architecture
document,
no
right,
yeah.
Actually
you
see
EPA
PCP
is
that
do
undo
architecture
first
yeah
we're
gonna
put
Jes
first,
all
right,
so
we
will
revisit
terminology
and
architecture,
and
now
we're
going
to
Jess,
so
I
think
we're
going
to
do
the
slides
and
you're
going
to
get
in
the
remote,
cue
and
chat.
If
you
can.
F
G
F
F
L
L
Okay
did
something
here
anyway:
okay,
further
clarify
the
use
of
MAC
addresses
as
an
endpoint
identifier
added
support
for
the
coast
web
in
the
swam
extension
and
then
updated
the
diagram
posture
manager
and
make
the
endpoint
the
focal
point.
So
those
are
all
pretty
straightforward
changes.
Oh
wow,
there's
a
lot
Jess
I
curse.
You
right
now
emphasize
the
need
to
consider
privacy
regulations
when
collecting
and
storing
data.
These
are
all
pretty
self-explanatory.
Has
let
me
ask
the
quick
question
of
how
many
folks
have
read
the
update.
H
L
L
L
I
L
B
J
F
I
J
I
Yeah
I'll
make
a
context-free
statement.
I
have
not
read
whatever
was
the
discussion
we
had
if
I
read
and
I
apologize,
I'd
forgotten
I
mean
it
part
of
it
is.
It
seems
like
it's
a
profile,
so
we're
doing
all
sorts
of
normative
language
to
describe
behavior
on
other
kind
of
PSS
and
other
stuff
outside
and
so
kind
of
we're
doing.
Bcp
would
be
great
to
certainly
talk
about
the
basis
of
all
of
that
experience
it.
It
would
seem
weird
to
be
information.
B
F
L
Of
you
might
only
find
actually
the
conversation
as
I
recall
it,
since
you
just
said
that
was
there's
a
lot
of
shoulds
musts
and
others
in
an
informational
document.
That
seems
a
little
fishy
and
I
believe.
That's
why
we
chose
BCP
standards.
Would
we
thought
was
going
to
be
hard,
since
this
specifies
a
bunch
of
things
that
aren't
necessarily
under
our
normative
control.
I
F
Okay,
any
other
questions
on
draft
okay,
I
think
what
we
need
to
do,
then,
is
to
set
a
time
window
for
those
additional
reviews
that
we
requested
and
then
based
on
that
make
a
call
on
mailing
list
about
moving
it
forward.
I
mean
we
should
we're
going
to
move
it
forward
unless
something
I
can't
say
anything
coming
up.
That
would
cause
us
not
to
move
it
forward.
So,
what's
a
reasonable
time
frame
for
getting
those
reviews.
F
M
P
Okay,
so
architecture
updates,
I'll,
be
honest
with
you.
Bill
is
having
technical
difficulties
and
he
was
actually
supposed
to
be
the
person
presenting.
So
instead
he
did
see
me
so
good
morning,
all
right
cool,
so
we
pushed
an
update
on
the
29th.
As
the
slide
says,
I've
covered
a
bunch
of
issues
in
the
draft
that
were
up
in
github
I.
Don't
think
we
have
to
go
through
necessarily
all
of
those
can
we
go
to
the
next
slide
as
we.
P
Write
so
we
did
add
a
really
super
simple
architectural
overview
diagram
that
basically
starts
with
producer
to
integration
service
to
consumer
find
a
diagram.
All
the
subsequent
diagrams
are
now
referenced
as
role
based
diagrams
instead
of
component
diagrams
ago
that
we've
had
discussions
about
being
more
rural,
focused
rather
than
component
focused
to
try
to
clarify
that
all
of
these
things
can
be
composite
depending
on
how
a
vendor
might
implement
to
rather
might
package
them.
P
Cool
right
other
updates,
we
did,
we
organized
it,
so
I
think
you
might
want
to
take
a
look
at
it.
We
were
hoping
to
get
some
feedback
from
you,
but,
as
you
mentioned
earlier,
you
didn't
have
the
time,
so
we
just
went
ahead
and
took
a
stab
at
it
again.
We
have
updated
sections
for
collections
of
architecture
and
evaluations
of
architecture
and
bill,
actually
templated
sections
for
each
security
domain
workflow.
P
P
Yep,
what's
next
more
drastic
updates,
we
hope
right.
There
are
a
few
issues
remaining
in
github,
one
that
I
think
is
what
that
we'll
definitely
need
some
help
on
I.
Think
Kathleen
is
presently
attached
to
adding
a
section
or
subsection
somewhere
on
a
test
station
and
then
there's
a
few
other
things
that
we
need
to
figure
out
like
do
we
remove
the
XMPP
specific
information
and
start
putting
that
into
its
own
draft?
H
Is
the
reorganization
like
for
the
orchestrator,
the
role
and
the
interfaces
before
they
were
interfaces?
They're,
not
interfaces
anymore?
All
this
is
now
I.
Think
three
of
them
the
at
least
addressed
by
the
issue
tracker
at
least
they're
reviewable
now
and
then
two
more
open
ones.
I
sent
you
a
list
of
the
five
items.
I
don't
know
months
ago.
Probably
it's
somewhere
I
can
find
it
again.
H
So
we
have
to
just
cross-check
that
these
are
all
consistent
now,
because
if
I
change,
two
of
them
and
then
the
other
ones
change
and
we
change
everything,
it's
all
the
churn.
It's
like
like
module
run
and
so
I
would
like
to
have
them
stable
and
if
they're
stable,
we
can
move
on
to
the
next
phase
and
then
sync
it
with
the
other
text,
and
that
should
be
easy
because
you're
familiar
with
the
other
text,
so
we
can
do
it
in
concert.
That'd
be
even
faster.
P
I
I
P
H
I'm,
this
is
Hank
on
the
mic.
One
of
the
reasons
is
that
the
new
architectural
layout
has
this
conveyance
bus
in
the
center
of
it
and
which
is
the
biggest
difference
to
the
endpoint
posture
compliance
profile,
which
it
does
not
have
this
bus
in
the
middle
of
it
and
XMP
peak,
but
when
to
Maya
and
that
right,
basic
assumption
for
this
bus
could
also
be
diva's
or
it
could
be
a
iff
or
whatever
it's
multiple
solutions.
H
P
I
F
Mean
I
think
some
of
this
is
a
historical
artifact
of
the
problems
the
working
group
had
early
on,
so
they
tried
to
do
an
architecture
document.
Well,
we
tried
to
do
an
architecture
document.
We
got
all
tied
up
in
that
and
I
said
we
said:
let's
take
a
step
back
and
and
and
do
some
of
the
pieces
and
we
tabled
the
architecture
document
and
then
we
thought
well.
Maybe
we
can
come
back
and
do
an
architecture
document
that
pulls
it
all
together.
I
Yeah
I
mean
I'm
preparing
for
the
conversation
as
we
advance
this
document
forward.
There
is
certainly
some
reticence
in
other
parts
of
the
I
use
you
to
publish
kind
of
supporting
documents.
We
typically
say
supporting
documents,
helped
us
drive
kind
of
other
things
and
I'm,
just
I'm
struggling
kinda,
with
the
asymmetry
of
being
able
to
articulate
what
this
is
helping
us
drive
or
decide
or
document,
even
frankly,
because
there
really
is
new
dependencies
as
we
can
see
between
the
kind
of
the
the
other
standards
work
in
this
document,
we
can
of
course
take
this
offline.
Q
H
F
P
F
I
P
Agree
so
it
one
last
comment
on
that
and
in
the
slides
I
think
we
did
talk
about
potentially
taking
the
solution.
Ii
kind
of
parts
of
the
draft
that
are
in
there
I
think
they're
stuffed
back
in
appendix
at
this
point,
taking
those
out
and
submitting
that
there's
another
draft,
so
maybe
in
the
XMPP
grid-based
specific,
you
know
solution
to
this
architecture
that
could
be
viewed
as
work,
that's
being
driven
by
this
document
in
some
in
some
way
right.
L
I'm
gonna
actually
make
Rome
a
little
bit
happy
in
his
reference
to
the
documents
and
document
references,
but
not
in
something
you
can
search
and
say
yes
to
you,
okay,
so
information
model,
so
I
haven't
really
made
a
lot
of
progress
on
what
what's
in
the
information
model.
So
it's
really
hard
to
do
because
I
there's
not
enough
implementation
to
try
and
make
sense
of
how
to
make
a
minimal,
viable
set
of
information
elements
that
make
us
able
to
go
forward,
but
for
Hank
as
to
the
you
know,
ask
in
one
of
the
design
meetings.
L
It
is
actually
on
github.
So
there's
the
link
Hank
and
feel
free
to
send
issues.
Anyone
else
can
too,
but
I
know
Hank
loves
that
so
feel
free
to
send
those
there's
no
real
updates
in
it.
But
it's
there,
it's
really
minimal.
So
you
know
it'll,
take
you
all
the
15
minutes
to
read
all
right.
So
why
so
little
progress?
I
commented
on
this
a
little
bit
already
all
right
just
a
moment
ago.
Right
so
trying
to
understand
the
combination
of
the
architecture,
draft
and
implementation
for
sockem,
and
it's
not
concrete
enough.
L
So
I've
started
to
do
some
more
kind
of
implementation
experience
here
so
I'm
internally,
at
my
place,
we're
working
to
build
a
prototype
of
an
XMPP
grid,
implementation
for
sockem
I'm,
trying
to
use
that
to
drive
forward.
This
I've
had
some
off
list
conversations
with
Bill
and
Adam
as
to
capture
some
of
the
work
that
was
done
in
previous
hackathons
as
to
what
needs
to
be
done
in
extensions.
L
Those
extensions
to
you
know
kind
of
command
sets
etc
for
XMPP
grid
would
really
Drive
what
the
understanding
of
what
the
minimum
viable
information
model
needs
to
be
so
at
long-term
or
medium-term.
Some,
some
term
that
isn't
in
the
next
week
is
that
there
would
actually
be
interoperable
XMPP
grid
implementations
that
can
do
something
novel
with
regards
to
sockem,
so
I
did
put
like
the
sketch
of
a
draft,
so
Adam
bill.
L
I
know
that
we
exchanged
all
of
like
three
emails
but
and
I
know
that
this
would
include
some
of
the
information
that's
currently
in
the
appendix
of
architecture,
but
we
need
I
need
to
like
kind
of
the
next
set
of
details.
As
in
you
know,
what
are
the
actual
commands?
We'd
be
exchanging.
How
do
we
do
discovery
and
I'd
like
to
put
that
in
that
kind
of
draft?
L
So
there's
another
URL
for
a
draft
there
I
and
I'm
happy
to
collaborate
with
anyone
else
who
wants
to
start
to
kind
of
work
on
some
implementation,
because
I
think
I
need
that
to
inform
kind
of
the
next
set
of
stuff,
all
right,
so
I
kind
of
covered
this
somewhat.
But
this
is
kind
of
my
near-term.
What
do
I
want
to
actually
build
and
do
a
test
on
so
the
template
in
the
architecture
draft?
Is
there
and
so
Roman?
Your
kind
of
comments
about
you
know
things
don't
reference.
This
will
definitely
reference
as.
L
To
capture
kind
of
oval
evaluation
results,
one
of
the
things
that
we
do
at
my
place
is
a
lot
of
IP
fix
work.
So
the
thing
that
I've
been
trying
to
figure
out
how
to
add
is
how
do
I,
add
IP,
fix
observations
to
compare
against
oval
observations
already
in
there
and
frankly,
I,
don't
know
how
to
implement
it,
because
it's
not
documented
enough
to
implement,
and
so
these
are
the
kind
of
the
the
mini
goals.
L
I
want
to
be
able
to
put
those
two
sets
of
information
in
there
and
then
query
from
implementations,
either
direction
to
find
what
those
set
of
results
were
and
some
kind
of
mechanism
that
would
allow
us
to
do
comparisons
against
network
observations
against
hosts
evaluation
results.
So
and
and
as
we
talked
in
the
last
design
meeting
you
one
of
the
concerns
was
we're
very
desktop
focused.
So
if
I
can
get
those
two
things
working,
the
next
step
for
me
is
how
do
I
get
something
that
isn't
a
desktop
computer
involved.
L
So
all
of
this
would
let
me
drive
to
what
the
minimum
basic
information
elements
are
two
kind
of
enable
this
set
of
functionality
and
how
that
interoperates
between
the
architecture
and
an
actual
implementation,
and
that's
the
goal
so
I'd
like
to
in
combination
with
architecture.
I,
don't
know
if
that
would
be
a
standard
or
a
document.
We
throw
away
to
your
point
room
and
about
are
these?
Is
that
a
publishable
document?
It
is
a
nom
I,
don't
know
yet
I'm,
not
I'm,
not
far
enough
along
in
thinking
about.
L
H
I'm
struggling
with
joining
two
other,
the
information
model
I
think
does
not
have
to
be
standard
strike,
but
it
has
to
be
very
defined
information
information
elements
in
it
that
can
be
instantiated
in
solution,
so
yes,
XMPP
grid
and
the
terminology
draft
are
basically
circling
that
one
there
are.
Some
are
all
interconnected
and
therefore
I
think
that,
while
moving
on
with
the
centerpiece
of
the
architecture
and
getting
that
done,
we
basically
have
to
start
terminology
information
but
at
the
same
time
to
accommodate
that
again
and
I
think
that
goes
hand-in-hand
because
they
cannot
be
redundant.
H
You
are
about
the
extra
information
and
the
document
is
about
the
things
that
move.
The
information
and
the
architecture
tells
you
how
and
and
I
think
this
should
be
very
aligned,
and
maybe
we
collect
some
of
them.
I,
don't
ignore
to
that
in
the
end.
Actually,
and
people
think
less
documents
are
easier
to
ISG
as
a
gateway
function.
That
is
probably
true.
Unfortunately,
they
are
not
on
the
same
track.
Maybe
so
I
don't
know,
yeah
I
think
as.
L
So
that's
kind
of
a
push
that
I
want
to
make
and
I
want
to
align
those
interoperable
implementations
against
kind
of
information,
model,
architecture
etc
and
I
will
I
don't
want
to
predispose
the
answer
of
what
track
things
are
on
until
we
know
what
what
documents
shakeout,
what
way.
So
what
documents
really
need
to
be
a
standard
such
that
this
would
give
you
enough
information
to
have
workable
solutions
in
the
long
run.
J
L
So
I
I
will
say
that
Adam
bill
I
mean
you
guys
did
respond
and
tell
me
what
the
what
timeline
I
should
expect
your
responses,
and
you
guys
aren't.
You
know
out
of
the
bounds
of
whatever,
so
so.
The
to
the
extent
that
we
bring
it
back
to
some
design
meetings.
I
think
would
be
useful
for
everybody
and
bill
didn't
prepend.
This.
F
F
I
Yeah,
my
indelicate
question
about
milestones
is
actually
unrelated
to
the
dates
to
the
things
we
have
existing
documents
on,
but
we
have
milestones
to
do
things
that
I,
don't
even
see
individual
unadopted
things
for
in
the
queue
and
I
just
want
to
ask
the
question:
we're
still
holding
a
marker
to
do
that.
Work
or
do
I
just
not
understand
the
purpose
of
other
documents
that
we
do
have
in
the
queue
so
specifically
I'm.
Talking
about
yang
push.
F
F
D
L
I
think
that
there's
as
we
move
forward
implementation
yang
push
could
very
well
come
back.
I
did
have
a
hallway
conversation
with
with
Nancy
and
she'd,
be
willing
to
interoperate
Cisco's
XMPP
and
which
they
did
built
some
some
yang
capability,
I,
don't
know
if
that's
its
own
document
at
this
point,
but
as
far
as
a
marker
for
a
possible
thing,
I'm.
Okay,
with
that
and
Hank,
might
have
some
comments
on
yang
push
as
a
document,
but
I,
don't
believe,
and
unless
I
don't
know
if
jess
is
still
on
it.
I
F
When
you
came
on
board
in
July
is
that
when
you
came
on
board,
we
updated
the
milestones
that
we
had
drafts
for
and
the
others
I
just
left
alone,
because
I'm
not
aware
of
drafts
that
are
coming
in
so
they're
in
our
charter.
Those
are
the
original
published
milestones
from
the
Charter
and
you're
right.
We
don't
currently
have
any
drafts
for
that.
So.
H
So
so
does
the
think
yang
push
was
blocked
and
blocked
and
pushed
back
and
blocked
as
arbitrary
reasons
for
three
years.
That
is
a
reason
why
we
did
not
proceed
over
that
because
it
was
churned
so
hard,
the
people
and
he's
back
and
forth
that
the
primary
authors
actually
said.
Okay,
we
are
abandoning
this
and
giving
the
igf
so
fortunately,
at
the
last
turn
they
made
it.
So
that
is
a
good
thing
back
when
there
was
not
so
much
turn.
H
We've
provided
at
the
hackathon,
a
proof
of
concept
at
yank
wash
and
XMPP,
quite
literally,
with
running
code
already,
could
exists,
but
all
the
people
that
were
involved
in
that
were
demotivated
by
the
prospect
process
in
areas
and
are
gone
that
we
that's.
That
is
a
reason
why
this
process
has
stalled
right.
F
So
but
so
there
was
the
ancient
history
which
was
all
of
the
pushback
and
churn,
and
then
there
was
the
hackathon
/re
chartering
activity
and
at
that
point
we
were
like
is
this
something
we
still
want
to
do
or
not?
All
of
that
pushback
had
happened.
All
of
that
history
existed
and
then
at
that
point
in
time
we
said
yes,
we
do
want
to
do
this.
Yes,.
H
F
G
H
F
My
point
is
the
point
at
which
we
had
the
conversation
about
rewriting
about
reach
our
Turing.
We
had
the
conversation
about
the
history
mm-hmm
and
we
knew
what
the
history
was
at
that
point
in
time,
and
we
still
said
yes,
this
is
something
still
worth
doing.
So,
if
we
think
at
this
point
in
time
it's
still
worth
doing,
then
we
should
leave
it
here
and
we
should
update
the
date.
That
makes
more
sense.
We.
H
Can
also
change
the
scope
a
little
bit
because
I'm
focusing
on
concise
yang
to
the
Metro
right
now,
and
that's
basically
also
using
push,
but
it's
always
in
binary
and
I
have
no
support
on
that
route.
That
comes
yesterday
confirmed
that
is
rough
by
them.
You
want
to
do
that
and
therefore
I
think
there
is
a
slight
change
of
term
and
civilization,
but
this
concept
will
be
stay.
The
same.
I
J
F
I
I
Typically,
we
have
a
milestone
and
the
challenge
we
have
is
that
there
are
competing
individual
things
and
we
don't
know
kind
of
what
to
do
with
it,
and
there
is
just
the
even
the
absence
of
anything
as
the
starting
point,
and
we
said
we
wanted
to
do
it
a
long
time
ago.
So,
if
it's
still
the
thing
we
want
to
do,
and
we
just
need
to
figure
out
the
timeline
you
get
there,
I'm.
I
F
F
P
I
I
don't
know
I
see
value
in
if
I'm,
understanding
what
you
see,
P
over
transfer
mechanism
is
I.
Think
it's
no
PC
P
over
transfer
mechanism
and
I
mentioned
earlier
that
the
PCP
is
work.
The
sacrum
architecture
basically
views
as
a
collection,
some
architecture,
if
you
will
or
collection
architecture
that
and
and
I
think
that
e
PCP
over
transfer
really
intends
to
get
the
information
that
that
collection
architecture
is
grabbing
into
the
integration
service
for
further
downstream
use.
So
I
think
it's
still
valuable
at
some
point.
P
F
J
I
J
I
You
know
also
again
I'm
generally
I
would
be
concerned
that
we
don't
even
understand
what
the
milestone
is
and
then
kind
of
the
question
is
we
all
think
it's
a
good
idea,
but
is:
does
someone
want
to
work
on
it
and
we
can
think
it's
a
good
idea,
but
no
one's
working
on
it?
It's
not
clear.
We
should,
but
we
can
take
it
to
the
list
of
sorts
sort
that
out.
If
we
need
to
do
the
archaeology,
I.
F
C
F
F
J
J
J
F
P
That's
actually
right,
yeah
I,
think
I'm
still
on
right.
Sorry,
Steven,
yes,
I
think
at
some
point
we
were
actually
on
the
hook
to
to
write
that
that
draft-
and
you
know
we
were
overcome
by
events
essentially
which
I
know
it
might
be
a
cop-out
to
send
people,
but
it
does
happen
and
then
I
think
you
had
offered
to
kind
of
take
it
over,
but
then
obviously
you've
been
busy
with
all
the
other
things
as
well.
So
you
know
some
of
these
graphs
I
think
are
subject
to
you,
know
simple
capacity
constraints
at
this
point.
P
This
happens
to
be
one
of
them.
I
think
that
ECP
over
transfer
is
another
one,
because
it
at
some
point
in
the
future.
Once
the
architecture
is
baked
enough
and
we
have
more
time
creepiness
there
I
think
it
would
be
useful
to
have
that
draft,
and
that
would
be
something
that
I
think
CIS
would
consider
contributing
to.
J
F
I
So
yeah
that
works
for
me
rhyme,
didn't
you
I
just
wanted
to
explain.
So
you
know
the
question
was
asked
about:
what's
the
magic
of
milestones,
there's
no
magic,
two
milestones
generally
working
groups
have
a
fixed
scope
and
with
that
scope
we
understand
what
it
takes
to
be
done.
Where
groups
are
you've
been.
I
You
know,
for
an
indefinite
period
of
time,
and
so
I've
been
using
the
milestones
better
to
understand
what
it
takes
to
be
done
and
I
just
find
again
confusion
as
I
kind
of
said,
where
we
have
things
in
the
distant
past,
we're
not
sure
what
they
are
and
we
don't
have.
I
I
haven't
heard
a
plan.
I
mean.
F
We
tried
fairly
hard
and
when
we
wrote
when
we
did,
the
reach
are
during
to
put
like
I
said
milestones
that
people
were
committed
to
doing,
and
that
was
the
only
thing
that
we
put
on
there
and
not
the
aspirational
things
that
people
were
saying
we
should
do,
but
the
things
that
people
wanted
to
do
and
that's
why
yeah
some
of
the
documents
that
had
originally
started
in
this
were
taken
off
the
table.
So
at
least
at
a
point
two
years
ago,
people
said
they
wanted
to
do
these.
F
So
that
brings
us
to
the
end
of
the
milestone
review.
The
only
last
thing
was:
is
there
any
other
business
people
want
to
bring
up
okay
and
then
the
last
thing
I
had
was
a
plan
for
between
now
and
the
next
meeting
for
for
better
or
for
worse.
This
is
a
working
group
that
seems
to
drive
to
milestones,
drive
to
you,
like
dates,
meeting
dates,
and
things
like
that.
So.