►
From YouTube: IETF102-MILE-20180719-0930
Description
MILE meeting session at IETF102
2018/07/19 0930
https://datatracker.ietf.org/meeting/102/proceedings/
C
E
B
B
F
B
Ipr
and
then
for
the
agenda
today
we
pretty
much
have
the
working
group
items
that
we
want
to
get
update
it's
on
and
if
there's
anything
any
new
topics,
we've
we've
got
some
time.
We've
got
a
short
slot
and
all
the
author
said
they
only
needed
a
few
minutes
to
provide
the
update.
So
if
we're
lucky,
we
may
let
you
go
early
how's
that
so
anybody
have
objections
to
the
agenda
or
anything
to
add
to
it
going
once
going
twice,
but.
B
G
So
here's
a
volunteers,
thank
you
for
being
a
note
taker
and
describe,
creates
Roman
and
different
sentiment
very
much
for
the
help.
So
here
is
a
all
my
work
space.
As
you
know,
we
still
have
three
draft
working
first,
one
in
the
JSON.
Are
you
there?
The
second
way
that
see
such
Rory
Sun
one
is
XMPP
great.
All
of
them
would
be
addressed
here
today
and
I
would
like
to
discuss
a
bit
about
milestone.
G
B
B
The
question
is
getting
review
so
I'm,
trying
to
remember
at
the
last
session
I
know:
Adam
and
Bill.
You
guys
had
volunteered
to
review
the
draft.
We
can
reach
out
to
David
Cridland.
If
we
can
get
a
couple
of
other
volunteers,
the
question
would
be
when
we
can
get
feedback.
So,
given
that
you
guys
are
here,
is
it
reasonable
for
you
guys
to
update
the
draft,
provide
and
then
give
feedback
go
ahead?.
G
B
You
know
we'll
have
to
figure
out
based
on
when
we
get
the
comments
put
some
time
for
me
to
react
and
update
the
draft,
and
then
we
need
to
post
the
question
to
the
group
whether
the
group
believes
the
draft
is
ready
for
last
call
and
then
I
would
add.
You
know
one
more
working
group
session
to
push
it
through
the
isg.
Yes,
that
would
be
my
recommendation.
It's.
G
B
I
G
G
In
this
errata
the
XP
should
be
array
or
not.
What
discussed
you
can
read
it
later,
but
anyway,
basically,
all
they
wrote
about
confound
by
rama.
Already
ramos
origin
editors
RFC
switch
in
1970,
so
all
the
rota
is
valid,
so
I
hope
you
can
take
a
look
at
data
for
this.
The
first
one
is
about
the
data
type
of
XP.
G
G
G
It
used
to
be
indicator,
ID
reference
for
exit,
but
the
Amata
says
indicator
IDs
right,
one
for
Islam,
but
again
take
a
look
at
errata
data.
This
is
the
correct
one
and
we
also
other
two
editorial
I
write
it
again.
You
can
take
a
look
at
that
web
page
I.
Don't
think
we
have
any
objection
for
that,
but
just
to
share
the
situation.
B
So
one
question:
taki:
will
you
be
able
to
put
a
draft
two
documents,
the
errata,
or
do
we
need
to
have
somebody
else
document
it
thank.
E
K
F
Might
I
might
I
suggest
actually
teeing
off
what
you
said
actually
to
wait
a
little
bit
I
think.
Maybe
we
might
find
something
in
the
I/o
def
JSON
kind
of
work
as
we're
kind
of
advancing
that
I
don't
know,
maybe
we'll
find
something,
and
if
we
do,
then
we
can
roll
that
up
into
one
one
kind
of
update,
wait.
B
K
F
What
I
meant
more
to
say
is
that
we're
looking
really
really
hard
at
the
data
model
that
got
published
in
high
def
feet
you
ever
in
kind
of
this
erotic
as
part
of
the
JSON
kind
of
migration
and
I'm
wondering
as
we
get
more
and
more
eyes
kind
of
look
at
adding
it.
Looking
at
that
data
model,
we're
finding
kind
of
this
errata
through
the
process
of
constructing
the
json
draft,
so
you're
saying
there
may
be
more,
perhaps.
L
B
Then
we
prepare
any
slides,
because
the
updates
were
small,
so
I
can
either
put
the
RFC
death
up
or
I
can
just
speak
to
it.
So
in
in
the
last
session,
the
feedback
that
I
received
was
that
it
was
difficult
to
understand
what
was
mandatory
to
implement.
So
we
added
a
paragraph
in
the
main
XMPP
section
to
say:
if
you
want
to
be
compliant
with
XMPP
grid,
you
have
to
implement
the
mandatory
to
implement
descriptions
that
are
in
the
base.
Xmpp
drafts
and
I
reference.
B
The
third
question
that
came
up
was
the
draft
is
about
how
we
can
use
the
IO
death
as
a
topic
that
can
be
pub/sub.
If
you
will,
through
XMPP
and
and
again
I,
had
the
discussion
with
my
co-author
and
as
it
turns
out,
so
it
was
a
question
of
do
we
create
an
Diana
registry,
as
it
turns
out,
there's
already
a
registry
for
the
XMPP
topics
in
XMPP
org,
which
again
we
noted
so
in
the
draft.
B
H
Adam
artful
again
and
so
yeah
right
yeah,
so
the
two
things
that
were
changed
or
yeah.
You
know
pretty
good
I,
think
for
a
mile,
and
my
interest
is
obviously
more
on
the
second
side
or
our
interest.
Okay,
on
the
second
side,
so
that
I
have
specific
questions
about
the
first
bullet
bullet
in
Section
10
that
new
section
yeah
but
operational
concerns
which
really
speaks
to
before
you
set
this
up.
I
think
it
was
basically
something
like
providers
and
consumers
need
to
agree
on
common
nodes
right
or
whatever.
The
terminology
is
coming.
Yeah.
B
H
B
So
for
sockem
sockem
needs
to
agree
so
Hank
and
I
started
mapping
an
information
model
to
a
data
model,
so
so,
basically
in
Sakon.
What
we
did
here
in
Nile
was
a
mile.
We
already
had
the
topic,
which
is
IO
death,
so
we
need
to
do
the
same
thing
in
stack
them
and
so
again
we're
not
speaking
about
Sakon.
We
would
go
and
register
that
topic
in
XMPP
org
got.
N
B
I'm,
more
than
happy
to
help
with
that,
so
I
think
that's
it.
So
if
we
and
I'll
reach
out
to
Dave
Cridland
to
make
sure
that
we
can
provide
feedback
there,
and
so
then
taki
you
can
post
a
question
to
the
group
whether
the
group
believes
we're
ready
for
last
call
right.
That's
it
see
five
minutes
thanks.
G
G
So
ya
know:
I
can
thank
you.
So
in
the
previous
meeting
we
had
a
discussion
with.
We
should
keep
using
JSON
schema
or
not.
The
answer
was
no.
We
should
not
use
JSON
schema
because
JSON
schema
is
not
going
to
be
RFC
pretty
soon,
so
the
discussion
result
was.
We
should
try
to
use
G
GD
l,
GD,
G
L
is
expected
to
be
RFC
pretty
soon,
I
think
so
too.
So
the
change
in
these
three
months
is
to
use
CD.
Do.
K
K
My
advice
is
because
the
whole
area
is
a
bit
of
a
mess
and
there
are
like
two
or
three
competing
proposals.
They
cater
for
different
things,
pick
the
one
that
works
for
you
and
we
can
make
it
work
all
right.
So
my
point
is
you
know
if
you
think
CD
DL
is
better,
for
you
absolutely
go
and
do
it
don't
switch
just
for
the
sake
of
you
know,
switching
it
unless
you
believe
it's
going
to
help
you
alright.
G
Thank
you
very
much
so
I.
It
was
my
first
time
to
use
the
CD
DL
C
GDL,
what
much
easier
to
define
the
type
so
I
believe
CD
did
much
better.
So
next
recipes.
So
this
is
okay,
so
we
define
the
city
use
we
use
CD,
DL
and
JSON.
Schema
is
now
moved
to
the
appendix
we
don't
have
to
delete
it.
We
just
kept
it
in
the
appendix,
but
if
necessary
we
generated
so
basically
we
chose
c
DD,
l
and
my
plan
is.
We
do
not
have
to
wait
for
the
CD
dl
to
be
RFC.
G
O
G
O
K
G
M
P
G
It's
an
excellent
piece,
so
only
one
question
or
discussion
point
is
barukh
observable
list.
Maybe
I
should
discuss
it
romantic
victory,
but
let
me
just
write
it
here:
in
RFC,
7970,
a
bulk
observable
is
a
string,
but
if
I
write
it
like
this,
like
this,
it's
more
like
an
array,
so
whether
we
should
keep
it
as
a
text
or
array,
it's
a
choice.
I
wonder
we
can
use
array,
that's
easier.
If
there's
no
objection,
I.
G
B
J
Okay,
this
is
Steven
bang
hard,
I'm
gonna
be
talking
about
current
role,
a
document
status
here
and
mile
and
I'm,
probably
gonna
bleed
over
into
any
other
business
a
little
bit
as
well.
So
next
slide
in
case
you
were
not
aware.
The
Rolly
cord
draft
was
published.
That
was
before
the
last
IETF
I
think
that's
RFC
832,
so
that
all
went
very,
very
well
next
slide.
J
So
we're
still
working
on
the
Rolly
discovery
draft
that
we
presented
the
0/0
version
of
last
IETF.
We
have
a
working
prototype
test
implementation
internally,
testing
our
DNS
SD
work.
So
we're
going
to
take
the
lessons
that
we've
learned
from
that
and
actually
start
doing
the
specification
work
around
getting
that
down
onto
the
onto
paper
and
and
really
kind
of
deciding
on
things
like
resource
names,
service
names,
all
that
kind
of
stuff.
So
with
any
luck,
we'll
have
a
zero
one
version
before
the
next
IETF.
That
includes
some
more
technical
details.
Next
slide.
J
J
However,
there
have
been
many
new
audiences
that
have
become
interested
in
the
work
that
we're
doing
with
Roly
in
audiences,
at
different
organizations
at
different
stos
groups
that
are
not
familiar
with
a
lot
of
the
work
that
we're
doing
here,
and
they
have
expressed
that
they
have
a
desire
to
have
an
entry
point
into
this
Roly
work,
something
that
they
can
read
that
is
familiar
to
them
and
that
provides
value.
Add
to
the
work
that
they
do
with.
J
That
said,
I
think
the
best
way
to
address
that
use
case
is
to
split
the
Roly
c-cert
document
into
two
AC.
Sir
I
mean
a
document
that
just
addresses
the
I/o
diffuse
case,
and
we
can
really
focus
on
the
I/o
def
format
and
then
one
document
that
focuses
on
the
sticks,
format
from
the
Oasis
working
group.
The
text
for
each
of
those
is
largely
complete
at
this
point
they're,
both
in
the
c-cert
draft
already,
so
that
draft
already
has
a
stick
section
in
it.
J
J
J
So
it's
my
proposal
to
do
that.
Do
I
have
next
slide.
I
forget
if
I
have
it
next
slide?
Now
I
can
go
back
one,
no,
not
yet
so
I
would
pose
a
question
to
the
chairs
here
this
kind
of
pushes
into
any
other
business
and
I've
left
the
rest
of
my
slides,
because
these
are
also
new
things
that
we
would
like
to
do.
It
and
I
want
to
talk
about
that
after
we
have
a
brief,
recharter
discussion.
If
that
works
for
the
chairs,
yeah.
B
I
mean
the
current
Charter
really
speaks
to
just
the
IO
def
and
the
IO
de
transport,
so
I
do
think
we
would
have
to
change
the
Charter
okay
right
that
it's
no
longer
just
about
IO
def,
we're
now
including
another.
B
G
B
J
O
Bret
Jordan
I
would
support
this
if
it
pleased
the
chairs
to
allow
us
to
do
that
in
the
80s
to
allow
us
to
do
that.
I
think
that
I
can
speak
someone
authoritative
Leon
part
of
this
matter,
so
it
would
be
nice
if
there
was
an
entry
point
into
Rowley
for
a
sticks,
content
and
the
reason
for
that
is
Rowley
and
its
counterpart
in
the
sticks.
O
World
taxi
very
similar
and
I
would
hope
at
some
point
in
the
future
they
could
actually
converge
and
so
having
a
means
by
which
stakes
content
could
be
delivered
by
Roly
would
be
a
nice
thing,
especially
for
people
in
this.
You
know
organization,
or
this
group
or
people
that
follow
the
IETF
more
closely,
that
they're
looking
to
implement
really
but
they're.
Looking
to
do
more
of
the
threat.
Television
stuff
that
comes
out
of
say,
sticks,
it
would
be,
it
would
be
nice.
Oh
I
would
support
that.
Okay,.
B
B
O
O
I'm
not
suggesting
that
at
all
I
I
would
just
seeing's
how
I
do
work
on
those
in
full
disclosure,
and
so
I
am
an
editor
on
sticks
and
an
author
on
taxi,
so
I
I
do
know
those
intimately.
So
when
I
as
I
do
begin
to
work
on
Roly,
it
would
be
nice
if
there
was
entry
points
that
you
could
wrap,
sticks
content
into
okay.
So.
B
We
I,
so
all
of
that
needs
to
be
made
very
clear.
So
so
that's
one.
The
second
one
is
what
we
in
the
IETF
are
allowed
to
do
with
sticks.
Is
it
that
we
just
take
it
and
we're
just
putting
the
transport
around
it
with
the
discovery
mechanisms,
or
do
we
intend
and
are
we
allowed
to
make
modifications
and
extensions?
We.
J
M
J
O
F
F
Stephen,
can
you
help
clarify
for
me
what
exactly
we
would
recharter,
and
maybe
this
is
some
of
the
retarder
and
kind
of
finesse.
So
we
are
talking
about.
Reach
are
during
to
create
a
constellation
of
extension
drafts
to
Roley,
and
each
draft
covers
a
particular
type
of
threat,
Intel
data.
We
want
to
share
I.
J
J
This
is
just
some
swirly
extensions
right,
so
really
JSON,
for
example,
is
something
that
the
community
has
expressed
interest
in
and
that
were
a
Brett
and
I
are
co-authoring
and
still
working
on
and
we've
gotten
interest
from
that
I
think
the
last
two
IETF
and
I
I
think
there
could
probably
be
a
debate
if
Roly
JSON
is
part
of
the
current
Charter,
but
I
think
there
was
interest
in
it
right.
So
it's
it's
not
going
to
be.
J
Personally,
my
plan
for
drafts
to
do
here
right
is
these:
the
io
def
document
and
the
sticks
document
right
and
I
think
that
there's
interest
in
this
group
and
retiring
to
support
those
things
so
does
that
answer
your
question?
I'm
not
I'm,
not
I
I
mean
I.
Don't
think
that
the
recharter
should
include
well,
it's
up
to
the
group.
Okay.
B
F
B
Right
so
what
I
have
heard
so
far
and
as
the
chair,
the
reach
are
Turing
would
be
Rolly
as
the
transport
mechanism
for
different
incident
formats.
We
started
with
IO
def,
so
the
Charter
is
very
much
about
IO
def
today.
So
what
I've
heard
so
far
is
we're
going
to
update
the
Charter
to
include
Rolly
as
a
transport
and
discovering
mechanism
that
could
include
other
incident
formats
like
sticks
and
what
I
heard
from
others
is
they'd
like
to
be
able
to
consider
other
formats
beyond
sticks.
J
P
Altameyer
so
I,
chair
IP.
Second
me:
we
do
a
lot
of
extension
work
there
and
what
we've
done
and
that
Charter
is
explicitly
enumerate.
The
individual
work
item
that
were
that
we're
addressing
as
extensions
and
that's
been
really
helpful
to
kind
of
keep
the
effort
you
know
constrained
to
to
just
those
drafts
that
you
know
that
we're
working
on.
It
also
gives
us
a
way
to
sort
of
manage
the
work
on
a
on
a
cyclical.
You
know
basis,
as
we
start
to
wind
down
that
work.
B
B
M
B
Q
M
Q
Q
F
Roman
didn't
just
to
follow
up
my
series
of
questions
yeah
I'm
generally
supportive
of
carry
different
types
of
data
formats,
not
so
supportive
of
talking
about
more
transports
yeah.
Thank
you.
It
would
be
great
if
we
back
to
this
idea
of
kind
of
extension
mechanisms
that
if
we
made
the
extension
drafts,
we
create
as
slim
as
possible,
and
we
put
all
the
hooks
that
we
need
in
the
world.
We
draft
itself
the
core
drive
architecture
away,
yeah.
R
Yeah
I
think
you'll
find
that
that's
the
case.
Yes,
thank
ya.
I
think
this
can
only
build
on
what
Roman
said.
So
do
you
have
the
base
roli
stuff?
That
is
effectively
your
called
transport
I.
Think
then
you
have
formats
in
there.
Jason
will
be
a
new
format
or
whatever
encoding,
and
then
you
have
semantics
in
there.
You
wanna,
transport
and
I
am
mandating
that
every
semantics
has
to
support
every
encoding
or
can
they
choose,
and
so
because
if
I
serialization
I'm
a
and
then
I'm
doing
vulnerabilities
and
I'm
a
because
it's
not
so
Jason.
B
B
Good,
he
missed
the
comment
move
on
okay,
so
I
think
now
as
we're
contemplating
different
encoding
Zandro
lis,
the
group
should
contemplate
a
mandatory
to
implement
because
right
now,
if
you're
saying
multiple,
this
is
to
address
Hanks
comment.
If
we
now
come
in,
are
we
forcing
sticks
to
support
XML
and
JSON
and
see
Boris?
Oh
no,.
J
The
way
that
Rolie
works
is
that
it
just
provides
a
link
to
the
piece
of
content.
The
content
can
be
in
any
encoding
any
format.
The
the
encoding
and
format
of
rolling
has
no
implications
for
the
encoding
or
format
of
the
content
involved.
Additionally,
this
really
JSON
work
is
a
binding
and
it
is
a
way
of
representing
your
view
into
Roly
with
a
different
response
type
right.
So
it's
it's
inherently
in
extension,
right
off
the
bat
I,
don't
think
we're
gonna
have
any
problems
with
with
interacting
with
the
different
formats
here.
Hanks
question
was
good.
J
M
R
I
can
even
move
as
a
set
of
them.
Yes,
and
you
will
always
know
this
is
going
to
work
using
the
transfer
or
I'm,
not
yeah,
I'm
I'm,
using
the
word
term
transport.
Now,
because,
usually
and
but
with
respect
to
data
models,
I
mean
yes,
the
same
CVE
may
be
reference,
so
you
have
to
I'll
have
another
problem,
because
you
don't
know
which
format
to
expect
so
only
cause
requests
will
never
cease,
would
really
don't
ever
be
in
Jason.
You
still
don't
know
how
to
process
them.
So.
B
B
J
M
J
Will
confirm
it
that
we
can
talk
offline
about
it?
Okay,
great
so
I
guess
I
will
very
very
very
quickly
talk
about
the
things
that
the
future
work
for
Olli
right,
so
the
Roli
JSON
work.
Obviously
that
we've
been
talking
about.
We've
been
working
on
a
0-0
draft.
This
is
co-authored
between
Brett
and
I,
and
we
fully
intend
to
have
that
zero
zero
draft
published
and
ready
for
people
to
look
at
at
least
as
a
preliminary
version
for
Bangkok.
J
B
J
B
M
K
B
B
B
K
I
J
Okay,
so,
along
with
this
discussion,
we
just
had
I'll
move
forward
with
splitting
the
Caesar
extension
into
two
documents.
I'll
have
those
posted
both
absolutely
before
Bangkok
way
before
that,
so
we
should
probably
discuss
them
at
Bangkok
and
decide
if
a
last
call
is
appropriate
at
that
time.
So
you
know,
depending
on
what
the
group
decides
last
call
after
well.
B
J
P
B
My
formula
is:
give
the
people
give
the
people
give
the
working
group
one
face
to
face
so
that
we
can
discuss
after
that,
you
get
to
update
right.
So
that
gives
us
a
November
after
that
you
get
to
update,
and
then
we
posed
a
question
at
the
next
face
to
face
and
then
I
give
you
a
month
yeah,
which
is
why
I'm
putting
in
a
month
after
the
next
face
to
face
it.