►
From YouTube: IETF99-MILE-20170717-1550
Description
MILE meeting session at IETF99
2017/07/17 1550
https://datatracker.ietf.org/meeting/99/proceedings/
B
C
D
D
D
A
D
A
All
right
good
afternoon,
everyone
cool
and
he
even
got
that
working.
Alright,
sorry
about
the
delay.
We
can
go
ahead
and
get
started
so
for
those
of
you
just
so
you
know
this
is
the
mile
working
group
just
in
case,
because
we
had
two
people
that
were
in
the
wrong
room.
Okay,
next
slide:
this
is
the
new
note.
Well,
I'm,
not
gonna!
Read
it
to
you!
That's
our
standard
note
well!
A
Basically,
the
issue
revolves
around
being
able
to
decrypt
I
guess
at
a
proxy
level
right
in
the
TLS
1.3
and
issues
around
that,
and
so
there's
been
a
lot
of
discussions
around
the
architecture
which
could
effectively
affect
us
if
we're
trying
to
get
some
insight
for
the
incident
reporting.
So
if
we
have
time
we'll
open
up
the
mick
to
see
if
there
are
any
questions
or
issues
that
we
need
to
discuss
right
and
perfect
so
Kathleen,
maybe
you
could
start
with
providing
us
with
a
summary
and
then
we'll
open
up
to
make.
A
So
with
that,
let's
give
you
a
quick
status
of
where
we
are
so
we're
you
on.
Look
at
the
work
that
we've
been
chartered
to
do
with
respect
to
the
data
modeling,
the
data
representation.
We've
got
the
IO
death
drafts
which
have
been
published.
A
We've
been
talking
about
the
different
transports.
The
two
new
drafts
under
construction
in
working
group
last
call
have
been
rolling
and
XMPP
grid.
They
did
go
through
working
group
last
call
I.
Think
Roley
is
much
more
mature,
so
we
can
talk
and
and
ask
our
area
director
Kathleen
if
we
can
just
move
it
forward,
given
that
the
authors
have
provided
an
updated
draft,
was
it
this
morning?
A
Yes,
so
I
I'm,
not
even
gonna,
ask
for
whose
read
it
yet
and
then
mio
has
been
providing
some
updates
on
the
IO
death
right,
which
we'll
get
an
update
on
that
as
well.
So
I
think.
Given
our
milestone
dates,
we
are
pretty
much
on
track,
given
that
there
were
substantial
rewrite
of
the
XMPP
grid.
I
think
that's
fair
and
I
know
I'm
speaking
as
chair
that
we
should
go
through.
Another
last
call
for
the
XMPP
quit
draft
and
we
can
discuss
whether
we're
ready
for
the
Roley
as
well.
A
A
A
D
A
F
That's
okay,
okay,
I'm
Steven
Bankart
from
NIST
I'm
gonna,
give
a
presentation
about
the
current
status
of
the
two
Roley
drafts
that
are
here
in
the
mile
working
group.
The
first
one
I'll
be
talking
about
is
the
Rolly
quard
draft
that
specifies
the
actual
Rolly
transport
itself
and
I'll
be
talking
a
little
bit
about
the
Rolly
c-cert
extension.
That's
here
as
well,
so
we
went
through
working
group
last
call
and
got
a
quite
a
lot
of
good
feedback.
F
We
are
actually
very
very
happy
with
the
responses
that
we
got
and
we
feel
like
we
improved
the
document
a
lot
so
immediately
following
working
group
last
call
we
pushed
out
a
o7
version
that
included
the
vast
majority
of
those
changes
and
to
quickly
run
through
those
changes,
so
everyone
can
kind
of
keep
track
of
the
deltas
here.
The
first
thing
we
did
was
we
received
some
comments
that
the
front
matter
of
the
document
was
a
little
bit
weighty.
F
So
we
went
and
reworked
the
front
matter,
reworked
the
introduction
and
made
everything
a
bit
more
concise
made.
It
flow
a
little
bit
better.
Hopefully,
if
it's
your
first
time
reading
the
document,
it
goes
a
little
bit
smoother
now.
So
that's
one
of
the
things
that,
if
you're
reviewing
it
now
is
to
look
at,
is
the
new
frontmatter.
F
The
second
major
change
that
happened
after
working
group
last
call
is
that
we
switched
our
URL
templating
to
the
slash
dot,
well-known
Ayana
registration.
That's
a
IETF
standard
that
specifies
that
if
you're
laying
out
a
URL
pattern
for
well-known
URLs
that
you
should
register
it,
this
slash
dot,
well-known
registration,
so
for
a
service
document
retrieval,
it
is
now
inspect
out
that
that
will
happen
at
the
server
root,
slash
dot,
well
known,
slash,
service,
slash,
Rolly,
slash
service
document
and
that's
all
described
in
the
spec.
This
is
more
compliant
to
IETF
guidance.
F
Now,
along
with
that
ion
registration,
we
also
registered
a
few
more
things
in
the
Ayane
tables
that
we'd
already
established.
We
just
filled
in
a
couple
more
initial
values,
so
there
are
now
local
registrations
in
there
so
to
make
a
namespace
that
is
just
designated
100%
for
local
use
of
both
property
and
category.
F
We
also
registered
at
that
time
one
initial
property,
which
was
a
Content
author
name
I'll,
be
talking
a
bit
more
about
that
on
the
next
slide.
We
added
a
privacy
consideration
section.
This
was
again
in
line
with
recent
IETF
guidance
that
we
should
be
adding
privacy
considerations.
So
that's
all
new
text
in
that
section
talks
a
little
bit
about
how
just
how
information
stored
in
role
a
sent
over
Olli
can
cause
breaches
of
privacy
cross
referencing
information
to
resolve
identity.
Things
like
that.
F
So
there's
some
considerations
there
in
that
section,
and
then
there
was
a
big
stack
of
editorial
grammatical
sentence
structure,
changes
from
working
group
last
call
we
accepted
almost
all
of
those
and
hopefully
made
the
document
a
lot
better.
So
this
came.
This
update
was
pushed
out
about
two
months
ago
after
the
working
group
last
call
following
the
working
group
last
call.
We
actually
received
a
decent
amount
of
review
during
a
requirements,
review
process
of
roli
and
we
wanted
to
get
that
feedback
into
the
document
before
it
went
on
to
the
next
step
of
publication.
F
So
just
this
morning
we
got
that
update
in
and
we
produced
the
oh
eight
version
of
Rolly,
and
this
is
integrating
the
last
of
the
review
that
we
got.
That
was
after
the
working
group
last
call,
but
we
felt
was
important
enough
to
get
in
before
it
started
to
move
forward
so
as
a
quick
overview
I'm
not
going
to
go
into
intense
detail
of
these
changes,
because
none
of
these
changes
changed
normative
requirements,
which
is
notable.
These
are
all
editorial
changes.
We
clarified
a
couple
requirements,
but
there
is
no
requirement
explicit
requirement
changes
in.
F
Oh
eight.
We
rewrote
a
couple
of
the
sections,
namely
a
PP
collection
and
atom
feed,
to
make
those
not
only
flow
a
little
bit
better
but
to
also
explain
our
intent
a
little
bit
more
clear
léa,
so
that
reading
it
the
first
time
you
understand
a
little
bit
better
what
it
means
to
be
a
Roli
feed
and
what
it
means
to
be
a
Roli
collection.
So
hopefully
those
sections
are
a
little
bit
clearer.
Now,
there's
a
decent
amount
of
new
non
normative
text.
F
In
those
sections
there
was
a
kind
of
errant
extra
requirement
in
the
security
considerations
section
that
had
actually
already
been
covered
in
the
earlier
parts
of
the
document,
but
that
had
kind
of
made
its
way
down
into
security
considerations.
So
we
went
ahead
and
resolved
that
so
that
duplicate
requirement
was
not
there.
We
did
some
more
clarification
of
the
TLS
requirements.
Section
we've
been
iterating
on
that
pretty
much
every
update.
We
feel
like
it's
in
a
pretty
good
place.
F
Now,
we've
we've
clarified
and
really
kind
of
made
clear
our
intentions
for
the
TLS
requirements,
and
then
we
also
did
some
more
clarification
to
make
the
rid
requirements
more
clear
as
well.
There
was
no
actual
requirement
changes.
We
just
kind
of
did
some
semantic
wordsmithing
to
make
sure
that
everything
came
across
as
clearly
as
possible.
Then
more
notably,
we
registered
three
more
properties
so
that
the
property
table
when
Roley
publish
publishes
at
this
moment
the
property
table
will
have
four
initial
values
just
from
the
core.
F
Of
course
extensions
may
add
to
that,
but
it
now
for
now
we
have
four,
and
that
is
the
content
author
name
from
oh
seven.
That
is
a
property
that
allows
people
to
expose
either
the
name
of
the
author
or
the
name
of
the
organization
that
created
the
piece
of
content
you're
talking
about,
we
registered
property,
Content
ID,
which
is
a
way
to
expose
an
identifier
from
the
content
we
registered
publish
date
and
update
date,
updated
date
which
fairly
self-explanatory.
F
We
were
working
on
some
other
extensions
and
found
that
these
properties
are
useful
to
register
in
the
core
so
that
every
single
extension
doesn't
have
to
register
them
for
themselves,
and
this
will
help
interoperability
hopefully
and
allow
these
registrations
to
be
done
in
the
core
so
and
then.
Oh.
It
also
includes
a
smaller
batch
of
editorial
grammatical
and
word
smithing
changes
that
aren't
really
important
enough
to
mention.
F
So
at
this
point
we
would
like
to
ask
the
working
group
in
the
chairs
as
to
what
the
next
steps
are
for
this
Roley
core
document.
Obviously
there
has
been.
No
one
has
read
the
new
updates,
yet
it
just
went
out
a
couple
hours
ago.
So,
if
you
have
read
it,
I
should
buy
you
a
beer
or
something
that's
amazing.
F
A
A
A
G
Director
who's,
not
that
tall
so
yeah.
So
if
you
just
want
to
do
your
the
Royce
Shepherd
write-up
and
then
toss
it
over
to
me
into
iesg
review,
okay
I
will
do
my
review
and
then
you
can
address
those
comments
and
then
we'll
do
IETF
last
call
and
then
from
there.
It
goes
to
iesg
review,
pretty
simple.
So
things
are
we.
A
F
Forward
to
it
working
on
this
for
a
while
on
it
make
it
as
good
as
it
can
be.
If
anyone
is
interested
in
writing
extensions
for
this,
please
don't
hesitate
to.
Let
me
know
I've
helping
a
couple.
Other
people
put
together
extensions
as
well
for
other
information
types
or
any
other
registrations
in
the
Rolly
space.
So
please
don't
hesitate
to
shoot
me
an
email
or
stop
me
here
this
week
and
talk
to
me
about
it
or,
if
anyone's
doing
any
kind
of
implementation
work.
Anything
like
that
I'd
love
to
hear
about
it.
H
Brett
Jordan
so
I'd
like
to
give
you
know:
I,
don't
want
to
work
with
you
a
little
bit
offline,
not
here
waste
time,
but
I'd
like
to
eat
a
little
bit
more
information
on
the
direction
that
Roly
is
gonna,
go
long-term.
Okay,
I'm
as
chair
of
taxi
in
the
different
standards
body.
I
would
like
to
see
a
convergence
at
some
point
between.
A
H
A
G
I'm
happy
to
have
that
conversation
probably
doesn't
need
to
be.
We
can
even
have
a
small
group
to
help
with
that,
but
they
are
different
transport
protocols.
So
doing
convergence
might
be
very
difficult
and
might
result
in
interoperability.
Problems
would
be
my
concern.
This
taxi
involves
at
least
laughs
I
looked
at
it
and
it's
been
a
while
for
me.
So
I
could
be
wrong.
Multiple
transports
that
it
accepts
right,
Oh,
they've,
changed
it
yeah
taxi,
2.0,
I,
haven't.
A
G
E
G
I
I
You
know
given
entry,
and
so
if
we
were
able
to
spin
up
some
work
in
the
IETF
around
doing
that,
we
could
actually,
you
know,
create
a
JSON
representation
which
I
think
would
then
cause
it
to
better
align
with
what
is
currently
being
used
in
in
oasis,
so
I'd
be
interested
in
talking
with
the
iesg
about.
You
know
how
we
might
be
able
to
start
some
work
in
that
regard.
I
think
that's
work
that
we
would
be
interested
and
in
doing.
A
That
might
be
part
of
the
mile
charter.
I
mean
we
are
talking
about
the
data
representations,
which
is
part
of
our
Charter,
so
I
guess
what
I'm
hearing,
and
maybe
we
should
just
ask
here
and
we
could
take
it
back
to
the
male
group
if
there
is
enough
interest.
I
know
for
me,
I'd
like
to
hear
an
update
of
where
taxi
2.0
is
and
then
maybe
have
another
session.
F
A
F
Mind
me
jumping
in
really
quick
before
we
asked
the
room.
The
the
JSON
update
to
Adam
and
Adam
pub
is
something
that
we
actually
were
thinking
about
doing
before
we
ever
really
were
even
familiar
with
the
taxi
space.
We
think
that
the
the
JSON
update
would
be
useful
for
a
lot
of
reasons.
People
like
JSON
these
days
and
being
able
to
use
Adam
and
Adam
pub
in
JSON
would
be
useful
for
roli,
regardless
of
the
rest
of
this
of
this
space.
So
I
think
it's
it's
two
separate
interest.
Okay,.
G
H
A
As
the
mild
chair
I
think,
we
do
need
to
put
prioritization
right,
so
I
think
the
first
order
of
business
is
for
us
to
identify
which
to
me
begins
with
having
this
form
understand
so
getting
an
overview
brand
right
of
taxi
2.0.
So
the
suggestion
was,
we
don't
need
to
wait,
wait
until
the
next
face-to-face.
We
can
put
it
out
on
the
main
list.
We
can
set
up
a
doodle
poll
to
pick
a
time
and
so
Brad
I'm
gonna
look
to
youth
as
volunteering.
Somebody
to
help
provide
with
that
overview
and.
A
A
Okay,
I
would
say:
that's
pretty
strong.
Okay,
so
all
I'll
set
up
I'll
send
an
email
instead
of
a
doodle
poll
to
get
that
moving
and
then
from
there
we'll
decide
whether
we
do
another
interim
or
wait
for
the
face-to-face.
But
don't
let
me
stop
you
from
doing
internal
I
mean
sign
right,
progress
right.
F
A
A
We've
got
our
business,
which
is
we're
gonna
move
Roly
forward
right
so
now.
The
next
question
is
whether
you
want
to
bring
Roly
with
JSON
as
the
next
and
that's
something
that
we
need
to
bring
it
to
the
group
and
agree
as
to
whether
that's
another
working
item
we
need
to
put
in
two
mile
separate
from
that
is
the
taxi
work.
That's
the
way,
I'm
seeing
it.
H
Overlay
at
commented
I
would
like
to
see
Roly
over
JSON
simply
because
as
a
vendor
I,
if
I
take
off
my
open
source,
you
know
community
hat
and
put
on
my
vendor.
Hat
working
in
a
JSON
environment
is
a
lot
easier,
especially
in
the
whole
web
2.0
environment,
that
everyone's
going
to
and
cloud
to
cloud
communication
going
between
Amazon
and
Google
and
Rackspace
XML
is
painfully
difficult
to
implement
these
days
and
it's
not
in
the
development
stack
of
any
vendor
so
well.
I
would
say
anything.
H
F
F
A
F
Okay,
so
the
other
documents
here
are
relevant
to
Roly
in
mile
is
the
c-cert
extension.
There
has
not
been
a
major
update
in
a
while
my
time,
enrollees
been
working
on
finishing
the
core
document
to
get
that
out
and
stabilized,
so
I've
actually
identified
a
few
minor
edits
that
I've
been
compiling
together
into
a
OH,
but
it's
only
very
minor,
so
it's
it's
at
least
shaped
correctly.
At
the
moment.
It's
it's
fleshed
out.
Most
of
the
way,
there's
still
work
left
to
be
done,
I
mean
there's
been
no
review
on
it.
A
A
A
I'm
the
c-cert
Rolly
c-cert
draft,
oh
you've
read
it
okay,
I
mean
that's
fine,
no
I
appreciate
it.
Cuz
you're,
writing
notes,
so
Roman
has
already
read
it,
so
it
would
be
Chris
and
Frank
and
I'll.
Ask
I,
guess
I'll,
send
it
out
to
the
mail
to
for
even
review
and.
F
A
Chris
and
Frank
I'm,
just
you
think
by
this
week:
okay,
so
I'm
gonna
send
it
out
on
the
mail,
so
maybe
I'll
have
to
add
another
week
to
it.
And
then
we
can
I'll
post
a
question
through
the
mail
right.
F
If
the
group
is
interested,
if
the
chairs
are
interested,
we
used
Roley
in
the
hackathon.
If
anyone
would
like
to
hear
about
kind
of
implementation
report
or
a
hackathon
report
on
that,
would
anyone
have
any
interest
in
that?
Yes,
okay,
so
I
have
been
working
on
and
is
the
chair,
so
you,
okay
with
that.
A
F
Minutes
is
more
than
enough,
so
I've
been
working
on
an
implementation
of
Roley,
we
deployed
it
and
used
it
at
the
hackathon.
We
were
using
it
to
store
and
allow
discovery
of
and
then
deploy
in
this
case
it
was
software.
Descriptors
and
vulnerabilities
were
the
information
types
that
we
were
using
in
this
hackathon
demo.
F
There
were
only
a
few
implementation
issues:
the
standard
itself
held
up
and
operated.
We
were
able
to
successfully
send
HTTP
requests
to
the
roli
server
in
order
to
go
through
the
service
document
and
to
parse
through
that
to
find
a
relevant
collection
and
departs
through
that
to
find
relevant
vulnerabilities
and
actually
extract
the
content
out
and
use
it
further
down
the
workflow
chain.
So
by
by
all
measures,
the
roli
standard
itself
worked
really
really
well
at
the
hackathon.
F
It
completely
filled
in
the
square
that
we
needed
to
fill
in
and
we
were
really
happy
about
about
how
it
operated
there
at
the
hackathon.
So
if
anyone
has
any
questions
or
comments
about
how
it
went
during
the
hackathon
or
the
implementation
or
any
of
that
or
I
worked
with
Dave
at
the
hackathon,
so
I'm
sure
he
more
more
comments
about
that.
I
How
about
I
did
de
volta
Myra?
How
about
I
add
them
to
the
notes
for
you,
so
I
just
wanted
to
add
one
other
thing,
one
that
we
demonstrated
the
extensibility
of
Rowley,
because
we
also
used
it
to
serve
up
oval
content,
which
was
used
as
part
of
the
the
hackathon
so
yeah.
That
was
a
another
type
of
content
that
we,
you
know,
hadn't
really
been.
You
know
considering
using
using
Rowley
to
serve
and
yeah,
and
it
did
yeah.
F
A
Thank
you
yeah
this
morning,
I
couldn't
bring
the
pole
down.
Okay,
so
everybody
who
knows
me
by
now
I'm
antsy
can
watch
it.
So
I
did
post
a
version
3
of
the
XMPP
draft,
and
if
anybody
has
looked
at
it,
you
will
notice
that
it
was
a
major
rewrite.
It
has
now
gone
from
45
pages
to
20,
some,
not
pages
so
given
all
of
the
editorial
comments,
so
thanks
Adam
for
them,
as
well
as
Chris
and
Hank
long
list.
A
So
all
of
those
I
addressed
the
biggest
most
critical
feedback
was
its
readability,
that
it
was
just
too
hard
to
discern.
When
you
look
at
the
history
of
the
draft
in
both
the
second
group
and
the
mild
group
where
it
was
presented
there
weren't
that
many
people
familiar
with
XMPP,
and
so
there
was
a
lot
of
content
in
there
that
described
how
XMPP
worked.
All
of
that
text
is
now
gone.
Okay,
so
right
now
what
you'll
see
in
the
text
is
basically
saying
we
are
using
XMPP
to
either
query
or
publish/subscribe
to
obtain
information.
A
This
is
how
you
do
it
using
XMPP,
and
so
how
you
do
the
authentication
authorization
you
use
this
RFC,
so
I
left
the
general
architecture.
Diagram
I,
put
in
a
new
abstract
message,
flow
diagram
showing
the
RFC's
as
well
as
the
XMPP
extensions
that
you
would
use
to
carry
the
I/o
death
and,
in
fact,
XMPP
has
already
created
its
own
namespace
for
I/o
death.
A
It
is
a
major
rewrite:
the
security
considerations,
I
left
alone,
because
architectural
e.message
wise
all
that
content
hasn't
changed
so
from
a
privacy
and
security.
All
of
that
still
applies
so
next
slide,
please.
So,
basically,
it
was
section
2
that
has
been
completely
rewritten
and
the
appendices
are
now
gone.
Ok,
where
we
actually
were
trying
to
show
the
XML
messaging,
it's
all
of
those
exists
in
the
rfcs
and
the
XMPP
RFC's,
and
then
the
gems
okay
next
slide.
Please
ok
so
to
carry
io
death
and
XMPP.
A
These
are
the
basic
so
there's
the
base
XMPP
protocol.
That's
now
part
of
an
updated
RFC
which
includes
the
pub/sub,
but
I
left
the
publish
subscribed,
which
is
Jeff
0-60,
also
referenced
in
there.
Just
because
there's
better
examples
in
that
Jeff
right
up,
then
there
is
an
RC,
ok,
but
how
you
do
the
discovery
and
now
a
question
that
I'm
thinking
of
is:
we
could
actually
do
the
discovery
through
the
XMPP
discovery
mechanism.
They
call
it
disco.
We
could
potentially
use
Roly
as
well.
A
So
that's
basically
the
gist
of
the
changes
next
slide,
so
I
just
wanted
to
give
thanks
for
all
of
the
feedback.
I
wasn't
able
to
each
Peterson
Andre,
but
I
did
reach
out
to
David
Cridland,
just
to
make
sure
that
where
I
was
going
with,
the
draft
was
what
he
was
looking
for,
and
he
said
yes
you're
on
the
right
path.
Okay,
so
I
think
we
need
to
do
another
working
group
last
call
or
it
just
because
it
was
a
substantial
write-up
content
wise
to
me,
semantically.
A
So,
given
that
Stephen
gave
the
the
readout
for
the
hackathon,
I'll
also
put
a
plug
for
XMPP
grid,
so
we
also
did
a
hackathon
or
participated
in
the
hackathon
using
the
I
to
NSF
and
I.
Forget
which
group
Eric
Boyd.
So
those
groups
are
providing
information
of
the
network
devices
like
topology
like
session
state
information
and
configuration.
A
So
what
we
did
was
we
used
their
pub
I'll
call
it
pub
cons
right
interface,
so
Huawei
had
a
switch
in
their
cloud
in
China
and
we
at
Cisco
had
a
switch
in
the
u.s.
in
our
lab
and
they
were
providing
so
I
believe
the
Cisco
switch
we
were
providing
just
so
we
could
show
the
variety
of
information
that
could
be
shared.
So
Cisco
was
showing
here's
topology
information
that
the
switch
is
seeing.
A
Huawei
was
showing
here's
the
session
information
that
we're
seeing
they
were
publishing
it
in
the
yang
data
model,
publishing
it
to
the
XMPP
grid
and
the
XMPP
grid
was
saying:
here's
this
information
that's
available,
so
we
didn't
really
have.
We
were
just
gonna
put
a
stub
application.
That
was
a
consumer,
but
we
didn't
quite
have
time
to
do
that,
but
anyway,
so
that
was
the
first
true
interoperability
of
two
separate
data
repositories
across
the
world.
Sharing
information
through
XMPP
bring
an
instance
of
XMPP.
A
C
G
J
J
We
think
currently,
a
locking
roof
last
call
consensus
reached
and
we
we
modified
our
defying
reviews
from
Adamu
and
Roma
after
working
with
lustful,
sanctum
and
drama,
and
we
are
now
waiting
for
Shepherd
writer,
I
appreciate
Nancy,
taking
a
shepherd
and
yeah
plates
from
the
previous
draft.
We
modified
issues
before
in
accountants
review
comment.
The
comment
is
main
language
improvements
and
need
throughout
the
draft,
and
then
now
we
modified
issues
from
romance
and
witty
comments,
as
we
are
fixing
XMS,
lipid
and
exact
of
consistency
in
the
fact.
J
I
owe
the
value
and
then
add
the
description
of
xml:lang
attribute
and
also
add
that
difference
to
read
and
finally,
language
improvement
throughout
the
draft
and
solution.
Also
added
paragraph
about
language
support
in
midstream,
assets
and
I.
Think
to-do
list
is
only
full
waiting
for
Shepherd
right
up.
Is
that
quick?
A
I
think
so
on
I
apologize
for
being
late,
so
I
think
I
just
need
to
do
the
right
of
because
the
comments
so
Roman.
As
far
as
I
saw
you
comments,
they
were
fairly
a
neighing,
so
I
think
I'll
just
go
ahead
and
do
the
right
of
you
and
then
G
as
well,
and
we're
good
to
go.
Thank
you
for
all
your
hard
work.
Thank
you.
It's
good!
A
C
About
some
comment
on
diet
of
schema
I
was
also
enjoying
a
hackathon.
This
time,
I
was
building
a
converter
between
six
and
I
ODF
and
found
out
several
schema.
A
necessity
of
the
change
schema,
so
the
first
one
is
easy
one.
The
IANA
registry
has
a
schema,
but
a
schemer
was
somehow
edited
by
somebody
else,
so
we
had
unnecessary,
unnecessary
space
in
a
namespace,
so
I
would
like
to
change
it.
Maybe
you
could
ask
Rahman
to
change
the
schema.
What
should
I
do
that?
I
don't
know
Justin
deleting
fits.
The
name
is
vertical
relation.
G
I
think
that
so
yeah
so
there's
that,
but
the
most
important
thing
is
getting
the
Ayana
one
that
is
yeah
hold
on
automatically
fixed.
So
that's
something
I
think
I
can
easily
just
approve
I,
don't
think
that'll
be
a
big
come
up,
but
then
we
have
to
check
to
see
if
it's
in
the
draft
and
then
maybe
an
errata.
So
people
are
aware:
yep.
C
K
C
We
do
have
some
other
issue
to
review,
so
we
had
an
example
in
the
draft
right,
so
we
use
an
example
through
the
draft
from
from
the
RFC
7920
and
also
from
the
guidance
draft
and
I
checked
with
this.
This
can
be
workable
and
it
wasn't.
We
identified
three
issue
here:
the
first
one
if
iam
occur
of
the
URL
was
defined
in
the
threat
actor
class,
but
the
schema
does
not
allow
us
to
omit
the
URL
element,
so
we
have
to
stitch
by
the
minimum
number
of
the
occurrence.
C
Other
issue
since
number
5,
the
enum
value
of
the
type
attribute
in
bulk
observable
class,
do
not
have
sqdm,
but
in
the
example
you
we
are
using
fqdn,
so
we
should
change
draft
or
schema.
We
can
discuss
about
it.
Well,
at
this
moment
we
can
just
use
a
extension
type,
but
the
extension
type
station
value,
but
also
missing
from
the
schema.
So
we
have
to
angry
change
it.
So
these
are
the
two
big
issues
yeah.
It
is
clear.
Yes,
thank
you.
The
draft
was
really
huge,
so
it
was
not
so
easy
to
fix
everything.
A
C
C
C
So
finally,
comment:
yeah:
we
should
change
the
schema
and
RFC,
though
so
what
I
felt
is
maybe
game
JSON.
It's
useful
I
used
to
work
for
the
JSON
representation,
but
somehow
this
was
bent
somewhere,
but
if
somebody
is
interested,
I
want
to
keep
working
with
the
JSON
representation.
I
think.
Are
there
any
interest
of
this
work?
If,
yes,
I
can
work
on
that,
you
cannot
I
will
just
keep
it
so.
A
G
A
G
A
A
A
G
Some
of
us
should
also
do
some
outreach
to
make
sure
we
have
incident
responders
that
will
actually
use
it
engaged.
So
I
will
help
with
that.
Okay
and
there's
a
number
of
other
people
that
help
with
like
not
lack
nic
and
coordination
here.
So
like
Carlos
Martinez
I'll
try
to
help
make
these
connections
because
it'sit's
only
valuable
if
we're
gonna
have
people
using
it
right.
Yep.
G
Guess
to
with
this
work,
if
somebody's
willing
to
go
present
it
there
at
one
of
their
meetings,
I
can
help
arrange
that
as
well
so
it'd
be
a
trip
to
South,
America
I'm.
Sure
taki
would
love
that
with
this
light,
that
would
involve
for
him.
Okay,
that
was
our
kites,
imprisoned
in
Spanish,
but
I
know
no
English
is
fine.
I
I
have
presented
multiple
times
at
their
c-cert
group.
Oh
okay,
yep
destinations
are
usually
wonderful,
but
you
can
present
in
English
and
they
have
full
translation
to
English
when
there's
a
presenter
in
Spanish.
G
G
Yes,
yeah,
it's
very
well
done,
but
that
might
help
as
well
just
so
we
have
additional
real
customers
and
then
maybe
the
see
sir
group
that
was
located
here
from
the
last
time
we
met
in
Prague.
They
also
had
something
related
in
JSON
that
wasn't
quite
IO
def.
What
was
closed,
so
I
think
we
should
re,
engage
them
at
least
four
reviews.
G
Okay,
so
I
was
hoping
some
of
some
of
the
folks
would
be
able
to
attend
that
are
trying
to
get
their
use
cases
solved.
This
is
really
just
a
request:
hey
I,
don't
think
we
got
all
the
people
in
the
room.
I
was
hoping
would
show
up
so
that
we
can
have
a
discussion
to
help
them,
but
on
the
TLS
list,
elos
1.3,
maybe
I'm
in
front.
G
So
there's
a
proposal
that
enables
the
use
of
diffie-hellman
static
keys
is
their
short
term,
for
it
that's
going
to
be
presented
on
Wednesday,
and
the
mailing
list
has
just
completely
blown
up
hundreds
of
messages.
In
the
last
couple
of
days
discussing
the
use,
it
started
from
a
use
case,
discussion
of
what
this
actually
helps
with,
except
that.
G
G
His
incident
response
was
turned
there,
as
as
a
general
and
I've
tried
to
help
with
the
conversation
and
I
do
have
the
experience
to
know
what
this
is,
but
a
few
more
incident
responders
people
that
experience
may
help.
So,
basically,
if
you
own
the
server,
you
can
use
this
technique
to
monitor
traffic
with
the
key,
so
basically
decrypt
the
traffic
going
to
that
particular
server
that
you
own
anyway.
So
you
have
that
capability.
G
G
Because
it's
being
argued
that
people
don't
have
the
experience
now
it's
been
a
few
years
since
I've
been
hands-on,
but
I
do
understand
how
this
stuff
works.
I
know
a
bunch
of
you
do
too
so
I'd
say
read
up
on
on
the
diffie-hellman
proposal
and
at
least
the
initial
messages
in
the
use
case
thread,
and
they
are
supposed
to
come
out
with
an
updated
example
of
updated
set
of
use
cases.
G
I
G
Think
that's
necessary.
No,
we
don't
need
a
draft,
so
I
think
just
an
email
is
gonna,
be
just
fine
for
this
progress
and
the
proponents
are
already
working
on
that,
but
helpful
responses
to
tone
it
down
in
professional
ways.
I
think
the
messages
have
been
professional
enough
on
the
list,
but
making
sure
it
stays
that
way
and
that
they're
getting
sound
advice
from
people
who
have
the
hands-on
experience.
It's
kind
of
what
I'm.
Looking
for,
because
there's
a
you
know,
there's
some
presupposing
that
people
don't
have
experience
so
I
know
some
of
you
do.
H
Brett
Jordan
I
made
this
comment
earlier
today
in
in
the
TLS
meeting
for
the
record.
I
am
very
much
for
encryption
and
I.
Think
privacy
is
a
very
important
thing.
I
do
have
concerns
with
these
proposals
that
are
coming
out
of
the
TLS
working
group,
not
just
this
one,
but
also
the
encrypted
SNI
and
I
think
it
sets
up
for
a
very
dangerous
precedent,
as
organizations
historically
have
tried
to
protect
their
networks
through
middle
box
technology
to
be
able
to
find
malicious
content
or
data
going
out
or
whatever.
H
However,
you
want
to
look
at
it
with
some
of
these
technologies
that
are
coming
down
the
pipe
with
with
TLS
TLS
1.3
specifically,
is
we're
going
to
get
to
a
point
where
every
middle
box
is.
You
know
whether
it's
a
Cisco
a
sa
firewall
or
whether
it's
a
Palo,
Alto
firewall
or
who
knows
what
they're
going
to
have
to
do
full
TLS
proxy,
and
some
of
these
devices
are
not
very
good
at
it,
I'm
in
the
vendor
space,
and
so
if
I
was
a
threat
actor.
H
These
devices
are
now
going
to
become
the
prime
target
for
everything
that
I
do,
because
now
it's
like,
historically,
you
were
able
to
do.
You
know
some
basic
inspection
and
you
were
able
to
say:
oh
all,
the
Amazon
traffic,
all
the
stuff
you're
buying
with
credit
card
information,
but
we're
not
gonna
decrypt
that
or
all
the
banking
traffic
we're
not
going
to
decrypt
that
and
now
you're
going
to
get
the
situation
where
these
devices
are
gonna.
Take
a
huge
performance
hit
because
they're
gonna
have
to
do
full,
TLS
proxy
and
now
as
a
threat
actor.
G
So
encrypted
sni
is
anyone
familiar
with
that?
Just
because
that's
a
whole
big
SNA
is
used
by
devices
to
determine
it
basically
see
the
hostname
essentially
now
I
think
there's
some
mitigators
for
that
and
I
think
that
if
it
goes
forward
and
the
working
group
I'm
not
taking
any
position
by
the
way,
if
the
working
group
decides
that
encrypts
and
I
should
be
encrypted,
then
there
has
to
be
clear
notifications
to
server
operators
so
that
they
understand
whether
or
not
they
should
encrypt
SNI
for
their
particular
service.
G
And
you
know,
banks,
for
instance,
might
opt
to
not
encrypt
s
and
I
so
that
their
traffic
is
not
intercepted
by
proxies.
So
you
know
I
see
that
as
a
reality,
you
know
I'm
sure
some
people
pull
that
trigger
immediately
I'm
hoping
we
can
get
to
better
guidance,
so
Before
we
jump
to
that
and
that
we're
able
to
put
more
good
information
out
in
terms
of
you
know
real
use
cases.
Mitigating
factors
pros
cons
and
come
to
good
decisions
with
good
information.
I
think
I
think
there
are
ways
to
do
encryption
and
push.