►
From YouTube: IETF97-MILE-20161118-1150
Description
MILE meeting session at IETF97
2016/11/18 1150
D
E
C
C
C
F
B
E
E
E
E
E
One,
quick
change
on
me:
asan
has
an
early
flight
to
take
so
for
the
presenters.
If
you
guys
are
okay,
I
would
like
to
put
him
after
the
mile
status
and
then
we'll
continue
on
the
same
order.
Is
that,
okay
with
everybody,
great
okay,
so
quick
status
for
the
working
group?
Next
slide?
Please
you,
you
are
doing
great
ok,
so
this
is
basically
the
representation
of
what
this
work
group
is
doing.
Hopefully
you
guys
all
know
this
I'm
trying
to
breeze
through
this
really
quick.
E
E
We
expect
the
progression
and
I
think
that's
on
the
next
slide
of
next
slide.
Please
of
what
we'd
like
to
do.
So
with
respect
to
the
schedule.
There
should
be
the
implementation
report
to
be
published
as
an
RFC
I
think
that
one
has
already
been
shepherded
by
taki.
Thank
you,
I'm
the
Shepherd
for
the
Rowley
draft.
So
if
we
can
get
the
updates
to
the
draft,
we
can
get
that
going
and
try
to
strive
to
get
that
done
by
the
December
timeframe,
so
hopefully
by
the
next
IETF,
which
is
98
on.
E
We
should
be
ready
to
do
on
a
last
call
for
the
guidance
draft.
I
think
we're
going
to
hear
updates
for
the
Rowley
draft,
there's
still
a
couple
of
issues
that
need
to
be
resolved,
so
Kathleen
we're
going
to
do
another
last
last.
Call
for
that
draft
just
to
make
sure
we'd
like
to
solicit
more
feedback,
give
steven
a
chance
to
update
the
draft.
So
that's
x,
98
same
thing
with
the
XMPP
grid,
so
I'll
provide
an
update
there
and
then
by
the
next
the
next
meeting.
E
B
E
So
we
should,
we
should
do
a
consensus
call
here
and
then
I'll
take
it
to
the
reflector.
So
I
guess
I
forgot
one
point
of
order:
I
want
to
thank
Steven
for
Jabbar,
scribing
and
Danny
for
doing
minute.
Taken
I
I
was
looking
at
you
Chris,
but
you
got
lucky.
You
weren't
that
the
breakfast
this
morning.
E
B
F
F
Will
show
the
updates
now
from
previous
drug?
Oh
sorry,
sorry
and
then
and
show
to
do
list
next,
please,
oh!
This
is
updates
and
played
from
the
previous
draft.
First,
we
we
modified
our
examples
in
appendix
to
follow
I.
Would
it
be
to
Skiba
currently
are
there's
four
examples
in
this
truck
and
a
one
Maria
and
related
in
Kita's
and
a
to
Marvel
delivery,
URLs,
a
3
&,
Lido's
traffic
and
finally,
a
for
the
spear
phishing
email
with
and
Maria
attachment.
F
D
G
F
E
F
E
E
H
D
G
C
G
E
G
You
a
bit
more
about
in
stages,
you
know
and
I
know
who
I'm
talking
about
schedule,
and
they
did
they
already
done
what
they
did
about
a
drought,
so
it's
possible.
We
would
like
to
make
sure
that
we
are
happy
to
initiate
working
group
last
call
before
the
next
meeting.
The
good
tips
could
share
as
audience
with
a
week.
Initiate
working
group
calls
before
the
next
meeting.
I
E
K
Yeah
I'm
steven
Banghart
with
NIST
and
Dave
altameyer
may
jump
in
a
few
times.
Help
me
out
with
a
few
things
as
well.
So
I
want
to
talk
to
you
guys
about
some
of
the
major
changes
that
we've
made
in
the
last
two
draft
updates
to
rolling
so
that
everyone's
up
to
date,
as
well
as
covered
like
the
major
review,
questions
and
issues
that
we
have
left
to
cover
until
we
do
the
working
group
last
last
call
and
get
this
thing
finished
up.
K
K
We
did
a
decent
amount
of
work
in
the
front
matter
of
the
document
in
the
background
and
motivation
section,
which
was
quite
lengthy,
and
we
boiled
it
down
with
the
same
kind
of
intent,
but
just
in
a
way
that's
a
little
bit
more
concise.
One
of
the
major
changes
we
made
was
we
combined
authentication
and
authorization
and
more
or
less
moved
all
the
normative
requirements
out
of
the
document,
and
we
are
intending
to
a
separate
document
that
will
contain
the
requirements
for
authentication
and
authorization.
K
The
TLS
requirements
that
were
originally
enrollee
were
iterated
and
expanded,
based
on
the
TLS
requirements
from
RFC
75
89,
they
had
a
TLS
requirements,
section
that
had
a
format
that
was
a
useful,
a
template
for
us.
The
forward
slash
resource
requirements
were
expanded
as
to
what
the
expected
responses
are
for
sending
requests
to
the
forward
slash
operator,
the
actual
response
codes
are
now
set
normatively.
K
The
link
relationships
were
basically
a
centralized
and
moved
into
a
more
sensical
kind
of
place,
all
in
one
place
and
everything
else
references
this
section
that
should
make
it
a
little
bit
more
clearer
and
make
a
little
bit
easier
for
reference.
We
want
the
document
to
be
referenceable
as
you're
working
on
its
be
able
to
just
pull
it
up.
Click
the
link
at
the
top
and
see
where
all
these
things
are
so
now
there's
one
table
for
all
that
the
rolly
format
element
is
defined,
which
is
a
new
element.
That's
an
extension
to
atom.
K
Syndication
and
rowley
format
holds
information
about
the
data
format
of
the
content,
the
actual
schema
and
definition
for
that
was
added
in
this
version.
The
search
requirements
just
like
authentication
authorization,
the
normative
search
requirements
were
removed.
That
is
intended
to
be
added
in
a
separate,
rowley
search
draft.
If
you
will
at
a
later
date,
as
that
was
deemed
out
of
scope
for
the
core
document,
the
extension
points,
rowley
format
being
one
of
them.
The
several
other
extension
points
like
category
and
Link
relations.
K
Those
extension
points
are
described
in
much
greater
detail
at
the
end
of
the
document.
There's
a
whole
section
that
describes
how
to
use
those
extension
points
and
what
they
actually
accomplish,
and
the
ionic
registration
section,
which
was
unfinished.
It
was
all
too
dude
an
in
the
03
version
was
completed
and
filled
out
and
all
those
registration
should
not
be
complete
for
establishing
all
the
ANA
tables
that
we
use
for
extensions
and
then
the
yeah,
as
I
mentioned
earlier,
that
the
actual
schema
was
added
for
Rowley
format.
So
this.
L
K
The
04
version,
which
was
a
lot
of
major,
normative
changes
not
too
long
after
a
four.
We
did
an
05
version
that
contained
a
few
more
changes
that
we
wanted
to
get
in.
Before
this
meeting,
we
expanded
the
terminology
section
at
the
beginning
of
the
document
in
order
to
define
all
of
our
Rowley
specific
terminology
in
one
place,
instead
of
defining
it
throughout
the
document.
The
atom
pub
category
document
is
a
document
that
allows
for
a
centralized
location
of
all
the
categories
that
a
rolly
server
provides
that
was
originally
not
required.
K
So
we
added
that
in
as
a
requirement
now,
there's
a
standardized
location,
a
client
can
come
and
get
the
category
document
and
instantly
know
what
the
given
rowley
server.
Actually,
what
information
types
and
categories
it
provides.
It's
a
normative
requirement
now
general
editing,
I'm,
trying
to
make
things
as
clear
and
concise
as
possible,
so
that
the
document
is
is
useful
to
implementers
as
possible
and
I
just
gets
right
to
the
meat
of
it.
K
The
format
parameter
type
the
was
in
04
for
the
iono
registration
that
is
not
being
registered
in
the
ana
section,
so
that
was
just
a
extraneous
text
that
was
removed
and
the
04
version
contained
like
a
35-page,
relax
and
g
schema
that
included
all
of
atom,
syndication
and
all
of
adam
pub,
and
that
was
unnecessary.
So
we
removed
the
full
schema
and
now
only
include
the
relevant
pieces
of
the
schema
that
have
actually
changed
throughout
the
document.
It
makes
a
lot
shorter,
easier
to
print
out.
K
You
have
to
print
out
the
whole
thing,
so
that
is
a
summary
of
the
major
changes
that
we
made
in
the
04
and
05
versions,
which
is
the
documents
current
version.
We
have
a
few
changes
pending
in
the
github
that
for
a
for
a
planned
06
version,
but
there
are
most
entirely
editing
clarity.
It
was
kind
of
small
edits.
Nothing
really
of
note,
so
with
that
there
are
a
few
things
left
that
we
need
to
do
to
get
this
done.
K
These
three
review
questions
that
we
have
up
here
are
less
of
an
outstanding
issue
and
more
of
things
that
need
to
get
reviewed
before
we
push
this
out.
Hopefully
these
will
be
answered
by
people
reviewing
the
document.
So
if
you
do
review,
keep
an
eye
out
for
these
things
are
normative
and
informative
references
need
to.
We
need
to
check
and
make
sure
that
the
reference
is
actually
in
the
place
that
they
belong,
whether
they're,
informative
or
normative
the
XML
snippets.
K
In
examples,
we
have
tried
very
hard
to
keep
those
up
to
date
with,
as
the
document
requirements
have
changed,
but
we
would
like
those
to
be
validated
against
the
rolly
schema.
Hopefully,
in
the
future
we
can
build
a
validator
or
just
use
some
kind
of
validation
to
actually
make
sure
that
our
examples
are
fully
valid.
It's
the
hope
there-
and
this
is
a
question-
that
we
hope
that
there
are
people
here
in
the
room
or
in
the
mailing
list
or
a
mile
in
general
that
can
help
us
with
the
security
side
of
things.
K
We
have
TLS
requirements
and
we
have
a
security
considerations
section.
We
need
some
people
who
are
knowledgeable
about
those
things
to
read
through
some
experts
in
TLS
or
just
in
the
HTTP
security
in
general,
and
give
us
feedback
on
those
security
sections,
and
let
us
know
if,
if
this
is
what
what
you
expect
so
with
that,
we
do
have
a
few
substantive
issues
that
we
need
to
talk
about
in
the
group.
So
this
is
the
first
issue,
and
this
is
one
that
came
to
light.
K
While
we
were
working
on
the
sea
cert
extension
document,
there
are
identifying
and
characterizing
properties
of
data
formats
that
don't
belong
in
our
current
extension
points.
So
we
have
linked
relations.
We
have
categories,
for
example,
in
IO
def
ID
is
a
really
important
property
that
could
be
useful
for
somebody
trying
to
get
information
off
of
a
rolly
server
to
say
get
me
this
iof
ID.
K
The
only
way
for
them
to
get
that
is
to
actually
download
the
content
and
then
search
it
if
there
was
some
way
of
arbitrarily
exposing
these
very
important
attributes
out
of
a
data
model
out
of
the
attacked
content
that
could
save
a
ton
of
time
for
people
trying
to
search.
So
there
are
a
couple
options
to
trying
to
solve
this
problem
and
we
have
some
examples
for
each
and
the
proposal
for
each.
So.
K
That
would
allow
the
exposure
of
these
important
elements
for
whoever
may
need
them
and
then
register
those
properties,
so
that
they're
tracked
and
understood
so
that,
for
example,
the
see
sort
extension
document
may
register
in
an
eye
on
a
table,
a
ID
and
maybe
date,
which
are
two
important
attributes
of
an
io
def
document
that
are
not
exposed
belen
any
other
way.
The
second
option
is
to
basically
require
any
time
that
you
want
to
do
that,
just
it
has
to
be
a
local
definition.
K
So
here
are
two
examples
of
option:
one
and
option
to
use
the
laser
pointer
things
pretty
cool,
so
option
one
here.
This
is
the
relevant
section,
there's
an
actual
rowley
property
element
with
a
scheme,
so
roll
ec
cert
I,
oh
def.
This
is
a
Stiga
scheme
that
would
be
established
by
the
extension
documents.
Oh
Rollie
Caesar
would
establish
this
scheme,
and
that
scheme
contains
a
number
of
names
and
in
that
document
that
defines
those
it
defines
the
actual
semantic
meaning
of
this
information.
And
then
the
actual
data
goes
in
the
content
of
the
tack.
K
K
This
is
the
option
to
these
are
locally
defined
name
spaces
which
are
shorter
and
element
name,
but
there
are
a
lot
of
compatibility
issues,
because
these
are
just
locally
defined,
so
there's
not
really
any
way
of
easily
communicating
that
to
a
public
distribution,
which
is
what
really
one
of
rollies
major
use
cases.
Is
this
public
distribution
use
case
and
if
everything's
locally
defined
doesn't
really
mean
anything
and
rowley
is
going
to
just
ignore
those
fields
in
most
of
the
cases
so.
K
E
J
J
B
Altameyer
as
a
contributor
and
I
think
the
difference
really
between
option
wanted
option.
Two
is
focused
around.
We
have
these
namespaces,
for
which
these
additional
properties
are
going
to
you
know
fit
within.
Do
we
do
we
want
to
have
a
controlled
process
for
adding
new
namespaces
enrollee
through
an
eye
on
a
registration
so
that
we
could
we
could
manage
the
the
namespace
of
namespaces,
essentially
or
or
do
we
want
to
allow
arbitrary
use
of
arbitrary
namespaces
by
you
know
by
implementation?
Why,
by
other.
K
K
It
wouldn't
it
wouldn't
preclude.
It
is
the
important
thing
here.
Basically,
Adam
allows
for
you
to
put
on
any
elements
that
you
could
possibly
want
any
of
the
time
and
it's
not
going
to
fail
validation.
If
you
send
that
to
somebody
who
doesn't
understand
what
that
is,
it
just
ignores
the
element
moves
on
so
you're
it
does.
It
does
not
preclude
a.
K
J
E
L
E
So,
to
me
option
one
gives
you
the
ability
to
dynamically,
create
a
new
property
and
defines
through
that
schema
the
semantic
intent
behind
that
property.
Yes,
so
beyond
the
ini
registration,
an
option
to
my
question
to
you
is:
it
seems
like,
as
you
register
these
you
know,
sorry
I.
Look
this
way
so
for
option
two.
When
new
properties
are
exposed,
not
only
does
it
go
through
the
iono
process,
but
there
has
to
be
an
understanding
of
what
that
namespace
and
schema
would
look
like
right
option.
B
K
M
M
So
if
you
do
not
really
require
versioning,
but
are
pretty
confident
that
you
are
stable
for
the
sake
of
simplicity,
option
two
is
actually
more
like
things
I've
done
now,
but
if
you're
a
lot
my
dilemma
traditionally,
one
I
have
this
rollout
of
excess
these
in
this
consistencies
inversions,
and
you
want
to
do
it
very
yeah.
Well,
traditionally,
in
strongly
defined,
I
rather
recommend
option.
One
depends
on
the
overall
strategy,
my
enrollee
in
combination
have
and
the
option
two
is
the
way
more
flexible
one
and
you
don't
have
to
better
all
the
scheme.
M
H
Rome
engineer
you
assert
my
misunderstanding:
is
there
a
third
option
which
is
option
one
and
two
the
same
time:
sip,
okay,
okay,
I
only
ask
because
I
feel
like
we
went
through
that
discussion
back
when
we
were
talking
at
least
about
IO
definite.
We
won
both
classes
of
them,
and
that
was
a
bit
of
discussion,
so
I'm
wondering
why
we
wouldn't
want
to
do
that
here.
So.
J
B
B
E
With
full
tons
option,
one
is
to
do
they
and
a
registry
through
the
creation,
as
you've
listed
there
option.
Two
is
what
you've
listed
there.
An
option
three
is
to
merge
the
two
to
allow
for
both
correct
I.
Think
that's
what
I
heard
okay,
so
this
is
gonna,
be
interesting.
Could
I
get
a
hum
for
option
one
go
ahead?
E
J
J
E
K
Right
perfect,
thank
you,
ok,
so
that
is
one
of
our
issues.
All
these
issues
are
on
github
by
the
way,
including
the
review,
questions
that
were
earlier.
So
if
you
want
to
come
comment
or
look
at
them,
they're
all
good
up
to
okay.
Here
we
go
so
issue
number
two.
So
we
have
talked
about
this
before
briefly,
but
we
want
to
get
some
final
discussion
in
on
it
as
we
approach
the
deadline
of
this
document
general,
so
data
model
enumeration
/
registration.
The
concept
here
is.
K
Right
now,
the
rolly
format
element
describes
the
data
model
of
the
content.
The
question
is:
should
that
be
registered
at
the
time
when
you
write
your
extension
document
that
talks
about
the
information
type,
so
there
are
some
pros
and
cons
of
doing
this
data
model,
registration
or
data
model
enumeration
it.
It
does
provide
a
registered
location
for
these.
K
It
would
be
like
a
namespace
for
IO
def
would
define
it
that
the
content
is
I
would
f,
you
put
it
in
really
format
it's
defined
in
the
table,
so
it
does
provide
this
kind
of
centralized
location
for
all
these
officially
supported
data
formats.
However,
it
requires
the
extension
document
writers
to
actually
just
pick
a
name
space
for
the
data
models,
which
might
not
mean
anything
to
anybody
else
right.
K
So,
even
if
you
register
a
given
name
space
for
a
data
model
and
you
publicly
distribute
that
atom
entry,
a
rolly
entry
out
to
the
world-
and
everybody
gets
this
Rollie
format
element-
and
it
says
oh
I'm,
a
I'll
def.
That
may
not
actually
mean
anything
to
the
client
who
receives
that,
so
it
it
is
basically
a
question
of.
Does
it
provide
value
to
require
the
extension
document
authors
to
to
register
those
data
formats
Dave
going
up
to
the
mic.
B
B
You
know
be
regenerated,
so
this
is
really
just
about
an
abundance
of
caution
to
not
make
it
too
difficult
for
you
know
for
creating
new
extensions.
What
this
effectively
allows
is
for
extensions
to
define
what
data
formats
are
allowed
but
doesn't
require
those
formats
to
be
registered
in
iono
registry.
So
you
don't
have
to
write
a
whole
bunch
of
ionic
considerations
in
order
to
create
an
extension.
H
K
B
N
B
So
this
is
all
about
the
the
format
extension
so
there's
the
format
element
contains
a
namespace
attribute
that
defines
the
namespace
of
the
referenced
content
by
the
rolly
entry.
It
can
also
contain
pointers
to
a
schema
location
where,
for
the
namespace,
a
media
type
for
the
schema
and
a
bunch
of
other
things
like
that
so
but
this
is
actually
about
is-
is
the
namespace
that's
used
in
that
Rolie
format?
Entry
does
that
have
to
be
registered
I'm
in
some
specialized
Diana
table.
You
know
for
for
the
rolly
format
element.
That's
what
the
question
is:
yeah.
J
J
K
Rolly
extensions
are
IETF
documents,
yes,
that
register
information
types,
because
information
type
is
one
of
the
category
extension
points.
Those
are
registered
in
iono
table
through
an
RFC
through
an
ietf
document,
so
the
information
types
which
are
really
what
almost
presumably
all
of
the
extension
documents
are
going
to
be.
The
idea
here
is
I
can
say
this
is
my
information
type
here
are
some
data
formats
that
are
reasonable
for
my
information
type,
that's
kind
of
the
planned
extension
format,
which
is
exactly
what
the
sea
sword
extension
does.
It
says
we
talk
about
incident
and
indicator.
K
J
L
J
J
B
I
Nacio,
sir
I
think
an
example
would
be
helpful,
but
I
actually
do
think
I
understand
what's
being
asked,
but
it's
not
clear
to
me
what
so
the
thing
we're
mired
in
the
technicalities
of
what
we're
doing,
but
I,
don't
necessarily
fully
appreciate
the
impacts.
So
I
get
it.
You
know
you
want
to
make
an
extension.
You
don't
have
to
do
an
eye
on
our
registry.
Okay
or
we
could
have
private
extensions
that
don't
have
I
Anna
registries.
I
I
B
B
M
E
M
E
M
M
M
Will
go
through
the
eye
on
a
registration
process
by
registering
the
information
types
you
just
want
to
avoid.
Have
specific
data
formats
tight
through
that
registration,
so
I
think
it
is
misleading
to
say
we
are
voting
on
not
registering
or
reducing
something,
because
you
are
already
registered
something
you
don't
want
to
go
into
more
detail
for
the
format
which
I
understand
yeah.
So.
L
I
E
B
E
So
my
suggestion
is
a
clarification
should
get
made.
An
example
should
be
provided
if
you
could
provide
it
to
the
mail
list
so
that
we
can
move
this
along
right
because
we'd
like
to
hit
the
December
deadline.
So
if
you
can
provide
an
example
of
what
that
means
and
try
to
provide
your
perspective
of
the
implications,
I
think
that
will
help
address
Chris's
points
right.
He
kinda
understands
it,
but
doesn't
quite
see
the
full
impact.
I
think
that
would
help
yeah.
K
K
E
K
We
can
do
that,
we
just
say
okay,
so
the
rest
last
couple
issues
are
a
little
bit
easier.
Actually,
rollies
current
status
is
informational.
There
are
many
many
informative
I
mean
normative
references
enrollee,
so
we
would
like
to
switch
it
to
a
standards
track
document.
So
our
proposal
is,
we
switch
it
to
a
standards
track
document.
Is
there
any
strong
opinion
opposing
that.
E
E
O
K
Okay
done
with
that
one
cool,
so
is
this!
The
these
two
issues
are
very
closely
related,
so
I'll
just
go
over
them
both
at
what
we
have
to
do
it
separately.
So
service
documents
are
really
really
important
to
the
operation
of
Rolly.
You
use
the
surface
document
to
discover
what
feeds
you
have
available
and
the
you
are
the
resource
at
locations
of
all
of
those
feeds.
K
So
if
you
can't
find
the
service
document,
you
can't
find
the
feeds
and
you're
out
of
luck
so
right
now
the
standardized
location
of
the
service
document
is
a
should
requirement.
Enrollee.
We
would
like
to
change
that
to
a
must
requirement
so
that
that
standardized
location
allows
any
kind
of
client
to
actually
discover
what's
on
the
server
reliably.
Without
this,
it
is
going
to
be
very
hard
for
a
client
to
discover
what
feeds
are
available.
Oh
I'll,.
K
P
K
E
K
Host
discovery,
but
as
soon
as
you
know,
a
host
you
can
find
a
rolly
server
there.
So
but
hoes
discovery
is
out
of
scope
for
this
document.
If
you
want,
if
there's
room
for
a
kind
of
hosts
discovery
type
thing,
then
that
would
be
in
a
separate
document.
I
think,
but
once
you
have
a
host
or
a
list
of
hosts,
you
can
check
them
all
for
Olli
servers.
If
this
is
a
must
requirement,
I.
I
E
K
Yeah
I
appreciate
the
feedback,
we're
looking
for
people
who
are
aware
of
these
type
of
things,
so
I'm
really
glad
you
brought
that
up
and
we'll
talk
about
it
on
list
and
get
as
much
feedback
as
we
can
on
it.
To
do
it
right
and
with
that
in
mind,
the
categories
document
is
the
exact
same
thing.
It's
another
top
level
document
that
just
lists
the
categories,
and
so
this
is
the
exact
same
question:
is
the
service
discovery
document,
and
so
will
we
will
discuss
this
at
the
same
time,
because
this
is
the
this?
K
Is
the
exact
same
issue
more
or
less
just
with
a
different
document?
So
no
reason
to
talk
about
this
now
and
if
we're
not
talking
about
this,
so
this
doesn't
matter,
but
if
you're
interested,
this
is
kind
of
what
a
categories
document
looks
like.
It
just
lists
all
the
categories
that
a
rolly
server
provides.
So
we're
not
going
to
talk
about
this
right
now,
because
this
is
going
to
go
to
list
along
with
the
service
document
stuff.
Okay,
those
are
the
issues
that
are
open.
K
K
Anybody
who
has
comments
or
edits
or
anything
that
you
you
care
about
in
this
document.
We
need
your
feedback.
We
need
your
review.
You
can
go
to
the
list.
You
can
go
to
the
github.
Doesn't
matter
just
get
your
get
your
reviews
in
a
few.
If
you
care
about
I
hope
you
do
would
hurt
me
if
you
don't
care
we're
building,
Roli
extensions.
We
have
a/c
cert
document
here
in
mile
I'm
about
to
talk
about
really
quick
in
just
a
second
and
there
is
a
software
descriptor
extension
in
sockem.
K
We
want
more
of
these
extensions,
there's
a
couple
more
being
built
by
people
here,
but
there's
always
room
for
more
extensions.
There's
all
these
information
types
that
we'd
really
love
to
see,
Rowley
extensions
for
and
if
you
are
interested
in
that
and
you
need
any
help
anything
at
all.
You
can
come
talk
to
the
authors,
we're
more
than
happy
to
help
you
put
together
an
extension.
You
can
also
follow
the
current
extensions
as
a
template
I'm
if
you
want
starting
point
there,
so
please
come
look
at
really
see.
K
Cert
extension
traffic
lips
I'm
going
to
go
over
very
quickly.
Cuz
I'm,
like
double
over
my
time
so
Rowley
see
Sir,
is
the
draft
that
adds
the
indicator
and
the
incident
information
types
to
Rowley.
This
is
text
and
requirements
that
used
to
be
in
the
original
I
think
it
was
the
0
2
or
0
1
version
of
Rowley
back
when
it
was
designed
as
an
io
def
carrier
and
since
I
Rowley
can
now
carry
many
different
things.
The
IO,
def
and
seizure
specific
text
was
pulled
out
and
is
now
the
role
ec
cert
extension.
K
So
it
registers
and
describes
the
indicator
and
incident
information
types
and
includes
all
the
normative
requirements
that
went
along
with
using
the
iof
format.
This
was
just
recently
uploaded
as
a
personal
draft
in
the
last
couple
of
weeks,
see
if
I
have
in
here.
Oh
these
are
issues
for
Caesar,
so
we
would
really
love
to
see
this
document
adopted
into
mile.
So
we
can
take
a
look
at
it
and
get
it
back.
K
K
If
there
are
other
properties
that
you
think
are
very,
very
important,
crucially
important
for
finding
iof
documents
that
need
to
be
exposed
as
properties.
Please
let
us
know
on
list
or
otherwise
we
need
development,
help
and
review
for
the
sea,
sir
document,
as
well
as
the
sockem
document
for
software
descriptors.
If
that
is
something
that
interests
you,
this
is
a
brand
new
document.
K
B
E
J
E
E
Right
but
you
still
have
a
set,
so
what
I
had
suggested
and
to
Alexei
right
was
to
do
an
expert
review,
but
I
think
that
should
come
after.
We
have
resolutions
for
the
current
issues
that
we
didn't
have
time
to
the
pole
here:
okay,
right
plus
the
ones
so
just
let
me
know-
and
through
the
mail
as
well
as
and
we'll
monitor,
but
you
need
to
make
sure
that
just
because
not
everybody
like
me
goes
through
github
and
looks
at
the
issues
just
put
them
back
out
on
the
mail
group.
K
E
All
right
good
morning,
Nancy,
Kim,
widget
I
think
I
only
have
one
slide,
so
I
had
three
or
four
different
commenters
provide
feedback
on
the
XMPP
grid.
So
many
thanks
for
that
on
a
lot
of
it
was
clarifications.
There
was
a
long
discussion
on
the
discovery
mechanism
and
we
debated
because
I
hits
assumed
that
the
base
XMPP
grid
does
talk
about
the
pods
up,
but
we
decided
and
agreed
I
think
through
the
mail
reflector
that
it
would
be
more
explicit
if
we
just
referenced
that
actual
extension
of
the
pub
sub
in
the
draft.
E
E
We
had
only
cited
the
XML
example
for
how
you
do
the
subscription
we've
added,
how
you
do
both
subscription
as
well
as
publication
and
then
added
a
few
more
sentences
and
I
can't
remember
that
in
to
the
sections
where,
in
the
overview,
I
think
we
said
for
the
extensibility
of
other
potential
pups
of
mechanisms,
because
XMPP
also
may
allow
for
others
just
like
Jeff
60
is
one
extension
for
pub
sub.
We
needed
to
allow
for
that
on.
E
So
we
added
text
to
address
that
set
of
comments,
so
that
was
basically
the
updates
that
was
done
in
two
version.
One
thank
you
Chris
for
providing
feedback
on
this
version.
So
I'd
like
to
better
understand-
and
we
don't
have
to
do
it
here
unless
you
want
to
do
it
with
the
open
mic
of
what
we
need
to
do,
to
make
things
more
clear
right.
So
with
that
any
questions,
so
next
slide,
please
so
the
question
as
the
author,
one
of
the
authors
is:
do
we
feel
we're
ready
for
this?
H
B
So
too,
so
probably
would
be
useful
to
to
get
more
review.
Can
I
can
I
get
some
show
of
hands
for
people
who
would
be
interested
in
in
reviewing
the
draft
Steven
thanks,
Adam
Thank,
You,
Hank,
okay.
So
we're
trying
to
have
we're
trying
to
move
fairly
quickly
on
this.
So
if
you
could
get
your
drafts
and
your
reviews
and
within
the
next
few
weeks,
that
would
be
that
would
be
appreciated.
E
E
E
G
L
G
So
next
please
three!
So
let
me
talk
about
the
summary
of
discussion
at
dinner
with
the
last
meeting.
I
think
people
are
generally
in
favor
of
defining
the
Jason
binding.
So
in
the
discussion
we
have
several
question:
dinner'll
be
the
difference
between
Jason
I
Otis,
an
iOS
version.
3
was
unclear.
That
was
a
message
I
received
from
the
camp
for
the
people.
For
instance,
I
have
received
two
question:
is
it
going
to
be
a
subset
or
extension?
I
didn't
think
I
can
answer
the
question
last
time.
G
I
also
got
the
question
like
this:
keep
in
mind
that
XML
or
JSON
contain
the
same
level
of
expressiveness.
So
currently,
I'm
trying
to
clarify
the
difference
between
Jason
resume
xml
version,
apostles
that
we
had
a
lot
of
discussion
in
Japan
item
JP
and
we
have
got
several
feedback
first.
One
is
jason
is
also
used
by
program.
It
does
not
need
all
field
of
I
you
back
when
we
want
to
use
all
feeds.
We
just
use
XML
the
second,
so
that
I
got
is
the
concept
of
ionic
version.
G
G
So
this
is
a
summary
of
the
difference
between
Jason
resume
and
I
only
present.
So
first
of
all,
this
and
prodigy
is
compatible
with
ionic
present
too.
So
what
I
mean
by
compatible
is
it
can
be
converted
into
I
got
a
project
to
automatically
without
any
problem,
and
also
there
is
dog
mandatory
field
for
Jason
I
Oh
death,
just
because
Jason
does
not
have
attribute
or
element.
G
It
was
easier
for
me
to
have
a
design
back
please
so
this
number
three
field
40
in
there
and
the
Jason
I
Otis-
cannot
express
the
type
of
data
that
could
not
be
expressed
in
ionic
present.
Do
in
this
way
I'm
incompatible
at
the
same
time,
I
think
we
need
to
make
station.
Some
difference
can
be
necessary
when
writing
take
a
drastic
reports
for
changes.
G
G
G
So
someone
with
Namor
chicks
so
hope
what
stick
to
portraits
in
some
places
the
data.
What
seems
to
event
date
on
this
when
the
data
is
supposed
to
be
in
array
when
I
right
at
Jason
I
did
not
want
to
look
the
JSON
schema,
so
it
should
be
more
clear
with
us.
The
data
is
the
array
for
Harper,
you
rotate
the
leg
flexes.
The
writer
of
the
document
can
easily
understood
whether
this
is
array
or
dot
this.
So
please
so
some
classes
that
exist.
The
only
photo
article
purpose
is
omitted,
for
instance,
flow
to
us.
G
This
is
very
understandable.
I
left
this
design,
but
when
I'm
right
Jason
Griffey
as
we
could
omid
it,
so,
for
instance,
we
had
a
application
had
a
film
class
that
is
also
the
same
trial
class,
so
I,
immediate
and
also
signature
class.
Lots
of
Justice
Scalia
as
well
indicate
a
class
as
well,
so
I'll
meet
the
prince
kind
of
the
semantics
of
classes.
G
G
Profile
this,
this
is
something
I
should
design
more
in
detail,
but
we
would
have
a
profile
in
order
to
limit
the
use
of
ionic
element.
Are
your
disposal
to
can
say
this
field
is
mandatory
or
not,
but
Jason
browser
does
not
say
this.
Gradual
is
monetary
or
not.
So,
by
allowing
profile
we
could
limit
the
use
of
the
element
want
profile.
We
are
building
it's
a
double
profile.
We
are
using
a
tablet,
decent
monitoring,
so
for
this
purpose
we
were
tentatively
building
a
great
profile
in
order
to
demonstrate
how
we
can
use
profile.
G
So
this
is
the
example.
I
think
I
have
shown
this
place
before
in
the
previous
meeting.
This
is
a
Jason,
so
when
I
would
like
to
write
our
alert
by
using
the
Jason
that
is
directly
converted
from
iOS
version
to
this
would
be
like
this.
As
you
can
see,
we
have
our
empty
glass
suggests
both,
but,
as
you
can
see,
we
have
IP
address
and
also
code
number
in
a
different
places.
G
G
This
equally
follow
the
proposal
of
this
adjacent
binding
draft.
The
data
can
be
changed
like
this.
It's
so
simple,
I,
just
converted
the
structure
following
the
rules
presented
in
this
presentation,
then
everton
look
so
smart
for
me.
So
I
hope
we
want
to
build
the
TSM
binding
draft
that
can
simplify
the
expression
or
the
data.
G
So
final
question
is
that
I
wanted
to
upload
new
version
to
data
tracker,
but
I
was
not
able
to
just
with
agent
applauding
as
we're
working
to
fill
draft
or
a
division
trapped.
We
had
a
call
about
the
main
list
and
no
decision
was
made,
but
still
we
have
had
several
support
and
obviously
what's
right.
So
if
it's
okay
I
got
to
upload
new
version
as
a
working
group
draft.
G
I
think
in
two
or
three
months
ago
we
had
a
kind
of
discussion
on
the
mailing
list
with
her
it
could
be
a
working
group
draft
or
not.
Then
the
result
was
something
we
had
several
persons
who
were
supportive
but
nobody's
what's
right.
So
I
wanted
to
know
what
time
I
actually
wasn't
expected
by
the
working
group.
So
I
do
yeah.