►
From YouTube: IETF101-DISPATCH-20180319-0930
Description
DISPATCH meeting session at IETF101
2018/03/19 0930
https://datatracker.ietf.org/meeting/101/proceedings/
A
B
Given
how
packed
it
is,
we
should
start
yeah
all
right.
Let's
get
started,
our
third
illustrious
co-chair
will
return
momentarily.
This
is
the
dispatch
working
group
which
will
be
followed
immediately
by
the
art
area
general
meeting
in
the
same
room.
If
that
is
not
your
final
destination,
please
off
board.
Now.
B
The
blue
sheets
are
circulating.
Where
are
they
now
hold
them
up?
Something
Martin
has
one
behind
Martin
I,
don't
know
where
the
other
one
went.
Thank
you
in
the
corner.
Please
make
sure
you
sign
those.
We
have
a
minute
taker,
that's
John!
We
don't
have
a
jobber
scrub.
Yet
can
we
get
a
volunteer
for
a
jabber
scribe,
preferably
someone
who's
nourish
to
a
mic?
B
As
Barry
likes
to
say,
please
note
the
note
well
well.
This
is
these:
are
your
rights
and
obligations
for
intellectual
property
related
to
intellectual
property,
for
participating
in
the
arms?
Excuse
me,
the
ietf
as
I
like
to
say
you
have
the
right
to
remain
silent.
Anything
you
can
say
can
be
used
by
the
ietf.
Please
consult
with
your
attorneys.
If
you
need
to
before
it
pating,
there
has
been
one
agenda
bash
on
the
dispatch
agenda.
B
The
opportunistic
encryption
related.
The
email
will
be
moved
to
the
art
area
agenda
so
still
in
this
timeslot,
just
a
little
bit
later
on
down
for
organizational
reasons
proposed
deadlines
for
IETF
102.
Those
of
you
familiar
with
dispatch
know
that
we
operate
on
sort
of
a
schedule
for
getting
work
in
before
the
next
meetings.
These
are
the
proposed
deadlines.
We
will
confirm
that
we
are.
They
are
exactly
what
we
want
them
to
be
and
then
posts
to
the
mailing
list
when
they're
official
it
generally,
if
you're
not
familiar
with
how
we
work.
B
If
you
make
the
deadlines,
you'll
go
to
the
front
of
the
list
for
assigning
agenda
time.
If
you
miss
those
deadlines,
you're
relegated
to
a
OB
and
probably
won't
get
agenda
time,
especially
given
how
packed
we
are
this
time,
and
please
name
your
drafts
according
to
our
usual
IETF
naming
procedures,
so
that
we
see
them
in
our
summaries.
D
D
So
that's
one
of
the
reasons
why
I
think
a
formal
definition
of
how
complex
Jason
should
be
produced
is
necessary.
Often
we
say
examples
or
what
we
really
need.
Examples
are
necessary,
but
they're
not
sufficient.
We
have
two
good
case
studies,
art,
F
and
J
card.
I
got
started
in
all
this
because
of
our
tap
trying
to
get
the
different,
our
tap
implementations
to
be
conformant
with
each
other,
and
it
sounded
easier
than
it
actually
is.
D
So
we
had
a
bunch
of
test
Suites
originally
for
our
tap,
but
none
of
them
actually
dealt
with
the
structure
of
the
JSON
because
it
was
very
difficult
to
do
because
there's
no
formal
definition.
So
that's
where
this
all
started
from,
but
I've
also
been
lately
dealing
with
a
lot
of
J
card
issues
and
the
J
card
specification,
just
like
our
tap,
has
a
lot
of
examples
in
there.
One
of
the
problems.
D
D
D
They
can
more,
naturally
describe
what's
going
on,
but
we
also
want
to
be
able
to
aid
software
developers
when
they're
creating
implementations,
because
that,
at
the
end
of
the
day
is
the
thing
we're
trying
to
get
done.
We're
trying
to
make
sure
that
protocols
interoperate
with
each
other
and
as
I
said
we
want
test
Suites
to
be
able
to
it's
to
be
more
easily
written,
so
you
can
test
these
things
out
and
then
the
other
thing
is-
and
this
is
kind
of
something
that
I
feel
like
the
relaxed
and
G
context.
D
So
compact
syntax
has
it's
kind
of
legible
to
the
casual
reader.
So
one
of
the
things
we're
looking
at
is:
how
do
you
take
someone
who
knows
what
JSON
is
maybe
hasn't
actually
seen?
Jcr
but
they've
been
around
the
block
a
couple
of
times
they've
seen
other
DDL
is
you
know
their
schema
languages
and
they
can
probably
look
at
and
go
yeah
I
kind
of
get
what's
going
on
there.
So
next
slide.
D
So
here's
the
history
of
this
we've
been
working
on
this
for
a
couple
of
years
started
out
with
a
Jason
like
syntax.
It
was
not
just
incompatible
to
define
different
rules,
then
you
know
taking
some
hints
from
people.
We
said
some
people
said
hey.
We
want
a
more
verbose
syntax
that
actually
has
words
in
there.
We
tried
that.
D
D
D
We
have
a
piece
of
software
that
I've
been
working
on
and
plus
two
other
in
the
works
implementations
just
to
make
sure
that
we
understand
the
issues
that
would
be
we're
dealing
with
I
mentioned
that
you
know
I
got
into
this
because
of
our
DEP
trying
to
make
sure
there's
our
DEP
conformance.
One
of
the
other
things
I
wanted
to
do
is
make
sure
this
actually
worked
for
our
app
because
that's
where
it
started
from,
and
so
the
nick
info,
our
DEP
client,
actually
has
JCR
validation
built
into
it
now.
D
So
that's
one
of
the
things
I'm
working
on
with
other
RF
off
of
implementation,
authors
trying
to
help
them
become
more
conformant
with
that
next
slide,
please!
So
here's
an
example,
this
is
an
example
of
taking
cider
notation,
are
trying
to
decompose
it.
It's
just
a
an
example
here,
but
it'll
say:
you've
won
an
array
and
you
wanted
to
break
it
down
into
each
cider
notation
into
a
prefix
and
a
length.
D
D
Of
course,
if
you
wanted
to
get
a
little
more
thorough
about
what
you're
trying
to
specify
you
say,
you
know,
v4
v6
are
actually
different
when
it
comes
to
lengths.
So
hey,
let's
break
this
down
into
two
different
types:
one
for
v4,
one
for
v6,
where,
when
you
have
a
v4
address,
the
length
is
32
or
is
128
for
v6,
and
so
that's
what
the
second
example
is
and
you
can
get
even
more
or
detailed
if
you
want
to
excellent
oops.
D
So,
like
I
said,
we've
done
a
lot
of
work
on
this.
There
has
been
discussion
on
adjacent
working
mailing
lists,
but
the
jacent
working
group,
jason
working
group
itself,
is
now
closed.
We
have
at
least
two
github
projects
on
this,
and
there
have
been
a
lot
of
discussions
in
the
trackers,
the
issue
trackers
there
and
then
I've
also
had
I've
dealt
with
a
lot
of
private
email
about
this
as
well.
So,
where
we
currently
stand,
the
o.9
Draft
is
is
I
think
in
really
good
shape.
D
You
can
do
it
now,
but
you
there's
some
things
you
have
to
pay
attention
to.
So
we
think
there's
a
better
way
of
doing
that,
and
so
what
we
won't
go
now
is
we
think,
it's
time
to
actually
try
to
get
this
moving
along
more
formally
in
the
IETF
and
so
we're
looking
for
ad
sponsorship
via
dispatch,
so
I
think
that's,
oh.
G
D
H
D
E
D
H
Yeah,
so
the
other
thing
that
sort
of
makes
me
a
little
less
enthusiastic
about
this
is
this
is
just
one
of
many.
You
didn't
address
that
point
in
your
presentation.
Can
you
speak
a
little
bit
about
the
multitude
of
other
ways
of
specifying
jason
schemas
I
mean
we
already
have
one
of
them
in
an
RFC,
it's
called
yang,
not
exactly
not
exactly
the
sort
of
thing
that
I
think
is,
as
general
purposes
what
you're
describing,
but
there's
there's
also
JSON
schema.
There's
there's
a
bunch
of
other
things
that
that
exist
out
there.
What?
Why
will?
D
D
My
philosophy
is:
do
what
you
want
to
do,
but
I
prefer
something.
That's
a
little
more
specific
to
the
problem,
we're
trying
to
solve,
having
to
go
when
you're,
when
you're
dealing
we're
trying
to
try
to
get
people
who
are
writing
implementations
to
have
to
learn
something
else
that
maybe
not
be
germane
to
what
they're
working
on
you
just
in
order
to
get
software
interoperability
going
that
that's
just
another
barrier
to
problems
with
interoperability,
so
something
a
little
more
targeted
to
JSON
is
what's
best.
Yes,.
H
The
question
there
is
well
okay,
so
I
have
a
need
to
consume
Jason
schemas.
For
other
reasons.
Now,
I've
got
a
deal
with
this
other
thing
because
of
the
specification
that
I'm
dealing
with
uses
this
and
there's
there's
a
problem
in
that.
If
we
add
to
the
pile,
we
now
have
more
things
that
people
have
to
manage
in
parallel.
The
the
reason
that
we
have
xml,
schemas
and
relax
ng
is
that
xml
schemas
were
redacted.
J
D
I
mean
it's
always
gonna
do
subjective
right,
so
I
I
am
NOT
a
big
fan
of
that's
not
schema
myself.
I'd
rather
do
relax
and
gif
had
to
do
XML
and
they're
a
good
good
number
of
reasons
for
that.
But
there
are
people
who
are
very
comfortable
with
it
at
the
end
of
the
day,
I
think,
a
tool
that
helps
you
get
the
work
done
is
what
you
want.
There
are
always
going
to
people
who,
like
certain
syntaxes,
they
want.
You
know
curly
braces
here
or
something
else.
D
As
long
as
you
have
a
tool
that
helps
people
I,
think
that's
what's
important
again.
As
far
as
abstraction
layers
go,
I
tend
to
think
those
tent.
Those
get
more
in
the
way
of
people
who
are
very
who
are
concentrating
on
that
problem
and
I've
dealt
a
lot
with
people,
especially
like
I,
said
to
use
cases.
I
have
our
Jake
art
and
art
app
and
I've
dealt
with
people
who
have
to
go.
Read
these
things
and
they're
they're
not
interested
in
going
trying
to
figure
out
especially
Jake
art
cake
art
is
quite
complex.
H
That's
one
thing:
I'd
like
to
see
discuss
a
little
bit
more
perhaps
in
the
draft
is,
is
the
the
conceptual
framework
that
you're
using
for
this
now
you
talked
about
a
little
bit
here
is
the
intent?
Is
that
people
producing
a
document
work
directly
with
the
JSON
you're,
not
talking
about
a
language
that
would
allow
you
to
describe
mapping
of
the
JSON
into
other
things?
No,
that's
that's!
Yes,.
H
D
H
H
H
You
don't
have
to
say
that
you
just
have
to
say:
yes,
is
your
intense
are
with
respect
to
defining
another
thing?
Okay,
so
it
so
mark
that
is
out
of
scope.
Clearly,
is
that
what
you're
saying
okay?
This
is
intended
for
X
and
it's
intended
for
X
for
the
following
reasons.
That
said,
something
else
then
you're
in
look
in
the
wrong
place.
That's
that's.
D
So
we've
had
some
proposals
on
how
to
do
that
ways.
The
JCR
can
be
extended
and
we
we've
talked
about
that.
To
be
honest,
that
gets
into
a
whole
nother
set
of
problems
so
kind
of
want
to
solve
this
problem
first
and
then
we
can
go
on
to
how
you
deal
with
more
of
the
semantic
layer.
Type
things
of
a
data
model,
so
I
agree
that
that's
a
problem
that
may
be
a
problem
too
large
to
swallow
I
mean.
K
If
just
to
make
sure
I
understand,
how
are
you
ambitious
envision,
this
being
used
in
specifications
is
that
you
would
have
a
description
of
all
the
properties
of
an
object
which
you
need
anyway,
so
that
people
know
what
they're
for
and
then
that
kind
of
information
again,
but
just
on
the
syntax
level
in
this
form
of
this
is
the
exact
syntax.
If
you
want
to
validate
against
something
better
than
prose
right.
D
Yes,
exactly
we
have
so
I
have
a
draft.
You
know
some
of
the
art
app
work.
There's
a
draft
I
should
have
put
the
the
link
in
here.
It's
our
tap
JCR
or
something
which
I
actually
took
the
our
tap
prose,
which
are
quite
lengthy
and
there's
a
lot
of
very
long
examples
in
those
in
that
RFC
and
I
say
well
here.
You
know
these
are
very
difficult
to
read,
actually
because
they're
so
long,
because
that
to
be
inclusive,
a
lot
of
stuff,
here's
the
JCR
for
it.
D
L
Ii-I've
got
a
system
that
allows
me
to
go
on
my
own
sn1
schema
language.
Well,
when
I
was
doing
XML
schema,
I
wrote
my
own
schema
language
and
generated
the
XML
schema
from
it,
because
XML
schema
was
so
awful.
So
I
with
my
JSON
schema
I've
produced
about
eight
protocols
so
far
and
I've
never
once
found
the
need
to
limit
the
range
of
an
integer
I
think
that
we
can
get
rid
of
90%
of
your
spec.
What
I
did
see
the
other
day.
I
was
reviewing
I
forget
what
struct
it
was.
L
It
was
the
Tia
using
TLS
in
it
applications
and
they
have
a
JSON
schema
where
all
they
do.
Is
they
basically
take
adjacent
message
and
give
all
the
possible
values
of
that
message
in
JSON
as
an
example,
and
that
actually
provides
a
pretty
good,
concrete
definition
of
what
the
schema
it?
What
time
do
you
have
and
what
can
go
in
there
I'll
see
if
I
can
find
the
link
and
put
it
in,
but
I.
L
Don't
think
that
we
need
this
complexity,
because,
unless
you're
doing
a
syntax,
where
are
you
actually
going
to
pack
bytes
together
to
get
them
to
move
them
on
the
wire
and
Jason?
Isn't
that,
then,
if
Jason
only
has
a
concept
of
an
integer
when
I'm
writing
code,
I
only
say
whether
it
is
int
long
or
byte,
I
never
tell
the
compiler
that
oh,
this
is
a
number
between
0
and
45.
L
D
Protocol
scheme,
so
I
would
disagree.
I
have
run
into
cases
where
you
didn't
need
to
specify
that
in
the
protocol
specification
itself,
the
other
thing
is
and
one
of
the
things
we
do
a
lot
with
JCR.
Is
we
override
rules
locally
for
test
Suites?
So
you
say:
can
you
actually
take
the
JCR
override
one
portion
of
the
rule
set
and
say
for
this
specific
use
case?
This
number
needs
to
be
and
the
JCR
allows
you
to
do
that.
So
that's
a
very
good
example
of
why
you
would
want
to
do
that.
I.
F
So
I
ask
rola
I,
guess:
I
had
a
little
more
sympathy
for
false
position
before
I
read
a
too
many
I
models
and
they
seem
to
be
full
of
constraints.
Things
can
contain
so
so
I
fear
we
do
you
need
out
expressivity.
You
know
the
file
on
Martin's
point.
You
know
this
is
like
n
puff,
1
n
plus
1
of
these
things,
so
we're
in
serious
danger
of
xkcd
9:27,
and
you
know
so
the
test
for
whether
we're
doing
X
he
night
went
see.
F
M
M
D
Yeah,
so
the
the
validator
I
wrote
actually
have
some
tooling
in
there
to
help
with
our
co-authors,
but
you
can
actually
it.
You
can
put
things
in
the
ruleset
itself.
So
this
this
section
goes
here
into
this
file.
No
way
you
can
actually
put
it
into
an
IETF
document
rather
easily
some
sort
of
prefix.
So
it's
easy
to
extract
it
from
the
RFC.
F
D
F
Yeah
I
guess
I,
guess
right
this
past
years,
I
would
start
by
show
of
hands
of
who
in
this
room
thinks
it
would
use.
This
I
was
trying
to
freeform.
Before
we
went
to
that
I
mean
that's
a
pretty
good
question
right
and
then,
if
the
answer
that
is
like
zero,
then
we
need
to
stop.
But
if
the
answer
that
it's
like
actually
positive.
O
So
I'm
interested
in
splitting
that
just
a
hair
farther
to
try
and
figure
out
whether
there's
people
who
want
some
sort
of
JSON
schema
language
other
than
than
yang
and
people
who
want
this
one.
A
little
bit
I
think
that
that's
important,
so
it
can
people
who
would
use
a
JSON
schema
language
other
than
yang
in
some
protocol
work
going
on
at
IETF.
Can
they
or
know
of
or
know
of
work?
That
would
can
they
just
go
to
the
mic
and
tell
us
which
work
would
possibly
use
this.
D
Are
DEP
stuff
we
are
looking
at
putting
routing
information
to
our
tab
and
that's
going
to
get
hairy
pretty
fast
if
I
have
to
do
it
in
prose.
So
that's
that's
one
of
the
cases
where
every
time
I
want
to
write
an
extension
to
this
I've
got
to
do
something
and
it's
becoming
very
difficult.
Ok,
Richard.
P
Q
E
D
D
It
does
it
doesn't
a
different
way.
It's.
It
is
essentially
there
so
the
way
what
they're
doing
is
they're
saying
well,
our
GDL
is
going
to
be
jason
itself,
so
it's,
in
my
opinion,
much
more
tedious
to
read.
I've
actually
been
through
some
of
it
and
in
fact
that's
where
I
started.
Now,
it's
just
like
I
can't
deal
with
this.
D
Q
Q
Q
D
Q
D
H
O
B
That
is
basically
equivalent
to
the
links,
header
or
coop,
and
they
have
they're
using
kuddle,
which
is
obviously
designed
for
sea
bore
but
they're
using
it
to
define
JSON
and
I,
understand,
there's
some
design,
some
desire
to
use
it
and
that
you
can
use
cuddle
for
that
kind
of
thing
as
well,
so
yeah
so
they're
there.
As
far
as
I
understand
they're,
basically
three
competing
things
here,
because
there's
the
schema
work,
there's
this
and
then
those
cuddle.
But
so
yes,
there's
definitely
pressure
for
a
schema
language.
K
Neil
Jenkins,
so
I'll
try
to
be
quick.
Yes,
so
forge
a
map
which
is
protocol
that
has
Jason
descriptions
in
it.
I
have
had
to
look
at
various
schema
options
before
I.
Haven't
this
one,
but
I've
never
actually
found
them
to
be
that
helpful.
In
terms
of
our
specification
in
terms
of
increasing
clarity,
most
of
the
difficulties
with
the
specification
was
in
is
making
sure
we
can
understand
what
the
properties
are.
D
E
D
Like
our
dog
or
Java
dog,
or
something
like
that
again
I
mean
it's.
That's
interesting
and
it'd
probably
be
that
type
of
thing
as
long
as
it
can
get
too
far
away,
it
wouldn't
be
hard
to
do.
I.
Just
don't
think
it's
central
to
the
problem
at
the
moment.
So
but
I
I
agree
that
that's
a
good.
That's
a
good
next
step.
A
R
Nottingham
I
have
not
read
the
draft.
I
have
use
cases,
I
think
there
are
lots
of
times
when
we
need
to
be
able
to
specify
Jason
precisely,
and
we
really
need
a
better
way
to
do
that.
It's
not
as
bad
as
XML
was,
but
you
know
you
can
specify
Jason
in
prose
and
I've
done
it
a
fair
amount,
but
having
a
normal
language
to
do
that.
It
would
be
really
useful,
on
the
other
hand,
anything
that
people
can
feed
into
a
tool.
R
People
will
feed
into
a
tool
and
that's
when
things
get
really
dangerous,
which
you
know
we
kind
of
hopefully
learn
from
from
XML
and
WI
star
and
all
that
kind
of
fun
in
terms
of
extensibility,
in
terms
of
the
unintended
consequences
of
mapping,
data
structures
into
other
languages
and
so
forth,
and
so
on.
So
that's
that's
why
I
think
I'm
twitchy
about
this
sort
of
thing
is
as
there's
we've
talked
about
this
before,
and
people
have
been
twitchy
about
schema
languages
for
Jason.
Maybe
you
know
we're
talking
about
this
pressure
to
do
this.
R
D
S
D
Other
hand
I've
been
down
the
other
side
where
we
in
the
JSON
stuff,
where
we
don't
have
it
and
people.
Just
the
pros
said
it's
an
array
of
strings
and
they
had
an
array
with
a
string
that
was
comma
separated
values.
I'm
like
what
okay
Oh
IIIi
got
with
a
I
understand
how
they
got
there,
but
it
wasn't
what
we
want.
A
N
O
A
A
A
A
T
A
D
O
F
B
F
Discuss
yeah
I
mean
if
we
already
have
chart
of
work
in
this
area
that
we
think
applies
to
JSON
specifications
like
publishing.
This
is
an
ad
sponsor
thing
now,
having
two
things
developed
by
a
group
which
I
think
we
can
all
agree
is
not
like
central.
The
use
of
JSON
in
art
is
like
an
extraordinarily
confusing
situation.
F
T
F
Yeah
I
have
no
position
on
the
realm
of
technical
merits
of
any
of
these
specifications.
I'm
trying
to
avoid
the
ITF
publishing
in
a
bunch
of
confusing
ways
about
specification,
there's
conflict
for
doing
essentially
the
same
task.
Some
were
3d
sponsorships
on
the
third
working
group
like
that.
Just
seems
like
it
like,
like,
like
a
really
terrible
like
situation
where,
like
no
we'll
understand
what
I'm
supposed
to
use
and
like,
surely
we
can
do
better
than
that.
L
There
is
a
good
argument
for
saying
produce
a
schema
language
that
isn't
tied
to
any
one
encoding
which
mine
kind
of
is
I
mean
you
know
you,
you
don't
need
to
tie
the
schema
to
one
particular
serialization.
That
said,
the
prom
with
using
curdle
is
the
you
know.
The
original
sin
of
C
bore,
which
was
they
decided
to
create
a
new
data
model
and
not
use
the
JSON
data
model,
which
some
of
us
told
them
they
should
do
and
that
if
they
didn't,
we
would
never
use
their
stuff.
T
A
A
B
A
R
R
R
So
I
asked
for
a
little
time
to
talk
about
RFC
57
85.
This
57
85
is
the
RFC
that
defines
well-known
your
eyes.
Has
anybody
read
the
best
document
accomplished?
Hence
no
smattering.
Okay!
Next
slide,
please
all
right!
Thank
you!
So
yeah
50
75
was
one
on
your
eyes
and
when
we
put
that
together
it
was,
it
was
fairly
straightforward.
R
The
the
use
cases
we
were
thinking
about
was
we
have
people
doing
things
like
robots.txt
or
the
w3c
p3p
policy
for
the
site
or
do-not-track
was
coming
along
even
way
back
then,
and
you
know
people
kept
on
having
to
do
these
things.
We
call
site
wide
minute
in
our
next
slide,
which
are
things
about
the
website
itself,
and
indeed
57.
85
says
that
more
or
less
says
is
to
facilitate
discovery,
information
on
a
site
and
it's
for
site
wide
policy
information.
So
it's
when
the
site
needs
to
speak
about
itself.
R
We
didn't
want
people
stomping
all
over
other
people's
websites
by
standardizing
your
iPad's
in
in
the
root
or
somewhere
else
like
w3c
did
w3c
slash,
p3p
XML.
We
wanted
one
place
to
do
that
next
slide,
and
so,
and-
and
that's
based
on
you
know,
what's
accepted,
is
is
how
we
think
about
your
eyes,
the
architecture
the
world
wide
web
Volume,
one
which
was
published
by
the
w3c
technical
architecture
group
sort
of
like
the
w3c
siab.
It
says
that
the
Europe
has
are
under
the
control
of
their
authority.
R
In
other
words,
the
administrator
of
the
origin
dictates
the
the
structure
of
the
path,
and,
and
so
we
need
to
respect
that
standard
shouldn't
encroach
into
that
space.
If
you
want
to
understand
more
about
why
BCP
190
talks
about
that,
and-
and
so
this
was
the
mentality
we
went
into
well-known,
your
eyes
was
with-
was
that
they
were
a
very
limited
carve
out
for
this
purpose,
for
four
standards
to
to
define
metadata
for
an
origin
so
that
the
origin
could
talk
about
itself
next
slide.
R
In
the
meantime,
lots
of
other
things
have
happened
next,
oh
you
did
yeah
Monday
morning.
So
we've
had
lots
of
IETF
protocol
starting
to
use
HTTP
as
a
substrate
and
we're
currently
in
the
HTTP
working
group
working
on
BCP
56
bits,
which
is
how
to
use
HTTP,
is
the
substrate
successfully
ITF
protocols,
a
common
requirement
of
protocols
using
HTTP
is,
shall
I
bootstrap.
What
you
are
I
should
I
use
to
start
talking.
This
protocol
with
with
HTTP
and
unfortunately
well-known
your
eyes,
seem
like
they're
the
answer
to
that
problem.
You
know
it's
it's.
R
R
If
you
use
one
on
URI
like
this
again
BCP
56,
this
talks
about
why
this
is
not
a
great
use
of
HTTP,
and
indeed
there
are
many
very
few
use
cases
where
you
actually
need
to
start
with
a
host
name
rather
than
a
folio
or
I.
In
other
words,
when
we've
been
talking
about
this
with
working
groups,
the
one
you
use
well-known
your
eyes-
we've
discovered
many
times
now
that
you
just
start
with
URI,
instead
of
starting
with
a
host
name
next.
R
So
the
proposal
in
this
Biss
is
to
clarify
the
appropriate
use
section
this.
This
is
a
clarification.
I
talked
to
a
lot
of
people.
I,
don't
think
there
are
any
new
normative
requirements
in
this
Biss.
It's
just
explaining.
What's
written
there
in
relative
shorthand
a
little
more
clearly
folks
who
know
my
writing
know
that
I
like
to
write
really
briefly
and
I
was
this
one
was
probably
a
little
bit
too
brief
talking
to
the
ADEs.
R
We
think
this
is
really
necessary,
because
we've
had
a
few
run-ins
with
working
groups
that
have
tried
to
use
well-known
your
eyes
and
we've
had
to
walk
them
through
what
I
just
walked
you
through
and
say.
No,
this
is
an
appropriate
use,
police
reconsider
and
that's
awkward
for
them,
and
it's
not
pleasant
for
anyone.
So
we
want
to
give
people
good
advice
about
how
to
proceed
using
this
and-
and
so
my
question
here-
I
think
this
is
the
last
slide
is:
is
57
85
is
ad
sponsored?
R
L
L
R
L
U
U
At
the
the
dough
session
this
week,
I
wouldn't
say
that
within
our
working
group
that
we
really
have
a
clear
consensus
on
on
how
to
handle
what
we
are
calling
a
discovery
issue
in
our
terminology,
so
getting
from
the
getting
from
the
DNS
model,
where
DNS
servers
are
identified,
usually
by
an
IP
address,
sometimes
by
a
domain
name,
to
adapt
that
to
an
HTTP
model
where
services
have
the
URI,
so
I
think
we
don't
have
consensus
there.
I
think.
R
And
thank
you
you
remind
me
there
there's
language
in
the
current
draft,
which
says,
basically,
you
know
don't
do
this
for
those
purposes.
However,
there
is
an
escape
hatch
where,
if
you
have
an
IETF
working
group,
an
Internet
standard
wants
to
do
that
and
they
don't
have
any
other
viable
way
to
bootstrap
their
protocol
with
consultation
with
the
ISG.
You
can
go
ahead
and
have
registration.
It's
it's
really
to
still
allow
that
when
it's
there
there's
no
other
option,
we
recognize.
Sometimes
you
know
that's
necessary,
but
not
allowing
it
to
become.
R
S
Ten-Thirty
I
want
a
couple
comment
on
two
things,
one
of
which
is
mildly
related.
Phil
was
making
it
one,
which
is
I,
think
actually
a
dispatch
question.
One
is:
we've
had
historically
several
attempts
to
manage
registrations
and
use
that
as
a
gatekeeping
function
to
how
people
use
to
the
specification
that
had
been
built
in
in
the
ITF.
This
was
particularly
what
we
did
over
URI
schemes
for
a
very
long
time
where
there
was
a
whole
registration
process
that
was
somewhat
onerous
and
heavyweight,
and
our
discovery
was
over
time.
S
The
most
important
thing
we
can
do
for
interoperability
is
to
avoid
collision
and
therefore
our
aim
switched
entirely
in
the
later
versions
of
this
registration
process
to
focus
on
avoiding
collision
rather
than
maintaining
a
lean
and
mean
schema
lean
and
mean
scheme
registry
right,
I
point
this
out
for
the
possible
parallels
which
might
be
drawn.
The
other
point
I
wanted
to
make
here
is
57
to
85
was
written
before
PCP
190,
but
PCP
190
did
not
exactly
incorporate
it
and
and
sorry
it
did
well.
S
It
mentions
it,
but
the
purpose
of
the
curve
out
and
the
and
the
sort
of
the
implications
of
it
I
think
are
left
in
fifty
seven.
Eighty
five
I
think
as
a
as
an
item
of
coherence
that,
when
you
consider
updating
it,
what
you
actually
might
want
to
consider
is
instead
of
updating
this
consolidating
it
into
a
BC
point.
190
bits
rather
than
an
RC
50
785.
This
by
itself,
well,
is
I.
Think
the
point
phil
is
making
is
actually
true.
There
is
a
disagreement
on
the
usage
of
you
arise
here.
S
That's
not
about
dot
well-known
as
a
mechanism,
but
about
the
usage
of
fewer
odds
and
tackling
that
more
directly
may
result
in
something
that's
eventually
more
productive.
Although
I
grant
you
that
the
conversation
will
be
much
harder
in
the
short
term,
I've
pointed
out,
because
that
that
would
actually
change,
I
think
what
Dispatch
did
with
this,
because
it
would
actually
suggest
a
scope
change.
That
I
think
would
require
a
working
group
where
an
update
to
this
particular
section
might
not
so.
R
I'm
really
a
sympathetic
to
what
you
were
speaking
about
about
opening
registries
up.
We've
done
that
in
most
of
the
web
related
registries,
the
you
know,
headers
link
relations
so
forth
and
so
on
and
try
to
keep
them
as
open
as
possible.
There
are
exceptions
to
that.
The
the
biggest
one
that
comes
to
mind
is
methods
and
status
codes.
Cetis
codes
is,
is
a
constraint
space.
So
that's
an
obvious
one
methods.
S
I
S
An
old
method
and
a
new
media
type,
for
example
the
less
you're
going
to
get
interoperability
among
the
the
servers
which
are
placed
in
front
of
a
particular
set
of
resources
and
applications.
So
I
think
in
in
that
case,
what
you're
talking
about
there
is
a
different
kind
of
constraint,
and
that
is
the
constraint
in
the
protocol.
Mechanics
for
the
generic
server
right
and
I.
S
Think
that
the
the
question
you
have
in
front
of
you
here
is
actually
whether
what
you're
dealing
with
here
is
a
way
of
determining
what
protocol
mechanics
apply,
that
that's
the
port
argument
that
that's
being
made
or
whether
we're
dealing
with
is
in
fact
a
bootstrapping
method.
That
starts
with
a
well-known
URI
and
retains
the
core
protocol
mechanics
of
HTTP.
Okay,
there
there's
a
real
architectural
difference
between
those
two
uses,
and
that's
why
I
think
PCP
190.
This
is
the
right
place
to
examine
them.
I.
R
S
R
Perhaps
I
think
so.
My
assumption
here
after
after
talking
to
folks
was
that
we
just
needed
to
clarify
whatever
the
RFC
number
is
that
just
disappear
in
this
room?
57
85,
you
know
if
we
want
to
decide
something
else,
I
think
we
really
need
to
have
a
good
look
at
it
as
a
whole,
which
to
me
says
it's
a
working
group
and
it
really
does
need
to
be
coordinated
with
the
w3c
at
the
very
least,
because,
frankly,
this
is
their
space
more
than
it
is
our
space.
This
is
how
the
web
works
so.
R
O
Chair
here,
I
have
some
comments,
is
Renault's
an
angel
contributor.
This
is
the
weirdest
draft.
I've
ever
dealt
with.
I
flew
like
the
blue,
caterpillar
and
Alice
in
Wonderland.
I've
received
multiple
comments
of
people
who
feel
bullied
on
it
and
are
not
willing
to
come
to
the
microphone
or
send
comments.
The
list
for
the
record
in
this
case
I,
wouldn't
say
this.
O
One
technical
argument
that
was
open-
it's
not
quite
a
technical
argument,
but
one
comment
that
came
out
of
that
discussion
back
and
forth.
That
I
will
raise
here
as
a
comment
for
the
group
to
consider
was
in
trying
to
understand
the
requirements
that
we
have
in
this
space
and
the
use
cases
that
are
upsetting
people
and
they're
causing
problem.
Could
we
look
back
at
all
of
the
requests
for
these
namespaces
that
we've
rejected
and
see
if
there's
something
common
in
them,
that
we
might
be
able
to
come
up
with
a
schema
to
address
about?
R
The
commonality
I
mean
it's
like
Roli
doe,
a
couple
of
others,
and
the
common
thread
does
seem
to
be
well
we're
using
HTTP.
We
need
to
start
with
a
URI,
oh
look,
here's
well-known
your
eyes
and,
and
then
you
know,
the
ADEs
I
usually
involve
the
ADEs.
When
this
comes
up,
because
it's
a
working
group
and
I
don't
want
to
just
do
it
as
the
expert
and
we
talk
through
it
and
we
come
to
a
place
where
we
realize
you
know
you
don't
need
to
start
with
a
hostname.
You
can
start
with
URI
right.
O
We
need
changes
here
and
as
proposed
that
inside
the
dot
well-known,
perhaps
we
should
make
a
discovery
space
where,
as
a
place
where
I'm
gonna
poorly
described
this
I'm
relaying
somebody
else's
words,
but
that
we
could
that
a
website
could
configure
into
that
place.
The
information
to
tell
you
where
the
URL
was
that
you
went
and
used
for
the
API.
You
want
it,
not
the
API
in
that
space.
There's.
R
V
V
No
one
knows
what
a
URI
is
and
when
weird
so
I'm
thinking
about
this
from
the
perspective
of
the
usage
profiles
for
DNS
over
TLS,
if
you're
establishing
a
trust
anchor
right.
This
is
like
your
boots,
dropping
from
something
that
somebody
understands
you
need
to
give
them
something
to
hang
on
to
that.
They
can
understand,
and
at
the
moment,
I
would
also
argue
that
nobody
knows
what
a
DNS
name
is
either,
but
they
think
they
know
it
at
the
NS
name
is
better
than
they
know.
V
What
are
your
Heights
and
so
the
reason
that
we're
having
this
struggle
is
because
when
people
want
to
surface
something
to
a
user,
that
a
user
can
grab
on
to
you
what
they
what
they
settle
on
is
a
DNS
name,
and
if
you
tell
them
no,
no,
you
have
to
settle
on
a
URI,
then
the
user
interface.
For
that
doesn't
work
or
nothing
shows
you
our
eyes
anymore.
Our
browsers,
don't
even
put
the
schema
in
the
schema
bar
in
some
cases,
right
I
mean
the
some
some
browsers,
don't
even
show
the
URI
at
all.
V
They
just
show
the
title
where
the
URL
used
to
be
unless
you
go
up
and
you
manually
fiddle
with
it,
so
none
of
that
is
exposed
to
the
user,
and
so
what
we're
talking
about
is
an
anchor
that's
needed
because
it
needs
to
be
exposed
to
the
user.
A
URI
is
not
a
great
match
because
we've
lost
that
battle,
so
I'm
just
trying
to
bring
it
an
explanation
to
why
people
are
trying
to
do
the
thing
that
you
don't
want
them
to
do
sure
that
makes
a.
I
Rondon,
wada
I
was
introduced
to
dot
well-known
with
Calvin
car
dev
and
your
discovery
mechanism
is,
you
have
an
email
address
and
a
password,
and
you
need
to
find
the
right
server
that
okay
took
a
while
to
understand
how
that
work,
because
documentation
was
with
difficult
to
track
through
I'm.
Now,
in
the
same
situation
with
Gemma,
where
we
have
an
email
address
and
from
an
email
address,
we
have
a
right-hand
side,
which
is
a
DNS
name
and
from
that
we
do
a
serve,
will
come
assuming
that
stacks
support
which
helps
them.
I
Don't
it's
dinner,
so
virtually
people
try
to
solve
that.
That's
a
lot
of
places.
You
can't
even
do
a
server
code
lookup,
but
from
that
you
get
a
host
name,
a
report.
You
don't
get
the
or
I.
If
we
define
yet
another
way
of
doing
that,
lookup,
that's
different
from
how
Cal
Devon
Carter
work,
then
someone
who's
implementing
protocols
is
going
to
have
yet
another
thing.
They
need
to
understand
to
even
get
to
the
point
of
doing
a
discovery
lookup.
I
L
Oh
all
I
want
to
be
able
to
do
is
that
given
a
web
service,
for
example,
calm
and
the
web
service
has
prefix
foo
I
want
to
be
able
to
connect
to
that
web
service
by
DNS
discovery
with
no
additional
information,
given
that
the
host
may
be
running
more
than
webs
one
web
service
on
the
other
end
now
right
now,
there
is
no
record
that
allows
me
to
do
that.
I
think
that
that
is
an
entirely
rational
requirement.
L
The
way
that
I
sold
it
and
will
continue
to
solve
it
in
my
protocols
is
that
if
I
have
fool,
as
my
SRV
prefix
I
got
to
go
to
dot
well-known
dot
foo.
That
means
that
you
don't
need
a
plethora
of
registries,
because
you
only
actually
need
one
registry
per
protocol
for
per
web
service.
You
know
the
SRV
prefix
can
be
the
same
as
the
well-known
prefix
I
think
that
that
is
an
entirely
reasonably
well
argued
architecture.
L
Now,
as
to
the
boolean
question,
I
really
think
that
mark
you
should
step
down
as
the
expert,
because
when
I
came
with
this
proposal,
I
was
really
nice.
The
aggression
that
you
may
been
hearing
earlier,
it
was
frightened
because
of
the
bullying
I
felt
from
you.
You
first
of
all
told
me
that
this
is
an
absolutely
crazy
thing
to
do
that.
You
mustn't
do
it
this
way,
and
it
is
not
just
I,
also
picking
picking
who
the.
O
W
W
E
Row
I
feeling
I
just
want
to
for
the
record
note
that
not
only
was
Mark
rational
in
that
conversation,
but
the
only
doesn't
the
only
disagreement
was
whether
all
of
these
ports
should
exist
in
the
top
of
the
dot
well-known
space
or
if
there
should
be
some
intervening
label,
for
example,
PL
H.
So
it
me
dot,
well-known
/ph,
slash
whatever
you
want
to
do.
That's,
okay,
it's
reserving
all
infinite
names
of
every
port
in
the
dog.
Well,
my
own
space.
B
Like
to
hear
that
for
change,
okay,
it
sounds
to
me
a
lot
like
we
have
work
to
do
here.
I
can
take
hums
if
we
think
that
that's
necessary,
but
I
think
we
can
save
some
time
by
saying
this
sounds
also
like
something
that
needs
a
mini
working
group
charter
like
we're
heading
in
that
direction,
and
it's
that
serious
and
it
needs
that
level
of
input.
So
do
you
want
to
take
a
home
on
that,
or
do
you
just
want
to
roll
with
that
idea
and
say?
R
B
I
R
B
O
N
S
Ted
Hardy
a
clarifying
point
earlier
I
made
a
proposal
that
said
that,
if
there
needed
to
be
a
clarification
here,
the
clarification
was
actually
on
the
BCP
190
Biss
side,
rather
than
on
this
side
and
I
believe
that
there
may
be
an
appetite
to
consider
both
and
again
agree
with
Mark
that
you
know
there
are
other
non
IETF
folks
in
both
the
WZ
and
what
working
group.
That
would
be
very,
very
interested
to
know.
E
O
We
have
some
problems
that
have
accumulated
over
a
long
periods
of
time
that
are
quite
difficult
to
solve,
with
some
of
the
choices
we've
made,
and
we
have
some
sets
of
requirements
that
been
floating
around
for
a
fair
amount
of
time
that
we,
we
don't
really
know
how
to
reasonably
meet
in
some
of
our
existing
protocols
and
I'm,
proposing
that
it
would
be
a
good
idea
to
step
back
and
take
a
blank
sheet
of
paper.
Look
at.
O
How
would
we
do
this
if
we
could
do
it
any
way
we
wanted
given
what's
changed
in
the
network?
What
would
we
do
differently?
How
would
we
try
and
do
something
now,
once
a
blank
sheet
of
paper,
I
mean
that
from
an
abstract,
how
we
think
about
it?
What
we
look
at
point
of
view,
anything
is
up
for
change.
Nothing
sacred
I
would
hope,
of
course,
that
as
we
did
that
that
eventually
we
would
figure
out
ways
to
go
well,
oh
those
parts.
O
O
We
could
do
quite
differently
and
some
of
the
problems
that
that
that
might
solve
I'm
going
to
talk
about
a
couple
of
those
today,
but
what
I
really
want
to
motivate
is
getting
some
people,
perhaps
some
new
people
that
had
different
networking
technologies
as
well
to
to
come
in
and
think
about
what
we
would
need
to
do
differently
to
bring
this
all
together.
So
one
of
the
questions
you
know,
you
know
things
that
we
can
do
and
can't
do
that
have
come
up
right.
What
are
what
are
the
goals
were
the
requirements.
O
This
does
not
just
change
it
to
make
it
architecture
pure
or
something
like
that.
I,
don't
care
much
about
architectural
purity,
as
people
know,
the
the
you
know
some
of
the
problems
that
we've
had
and
all
hit
these
that
a
bunch
different
levels
with
with
things
like
some
of
these
things.
We
can
just
simplify
a
lot
and
make
much
faster
and
easier
to
implement
some
of
them.
We
can
make
more
flexible,
so
they
work
better.
Some
of
them.
We
can
do
other
things.
We've
never
really
been
able
to
deal
with
ways
where
we
had
cascaded.
O
Media.
Very
well
talk
about
that.
A
couple
slides.
We
have
not
had
ways
where
we
could
deal
with
firewalls
that
had
asymmetric
media
properties
so
that
we
could
perhaps
send
UDP
out
through
a
firewall,
but
we
couldn't
get
UDP
in
through
that
firewall,
so
we
needed
to
use
TCP
for
incoming
data
or
incoming
media,
but
UDP
out
or
that
type
of
thing.
Okay,
our
Indian
encryption
story.
O
We
we
have
a
so
in
in
most
of
our
deployments,
stated
in
the
detail.
Ss
RTP
or
the
s
des
mechanisms
are
used
as
a
sort
of
hop
too
hot
in
the
sense
between
an
endpoint
and
a
mixing
bridge,
or
something
in
the
cloud
like
that,
a
relay
of
some
sort
or
an
SBC
and
then
on
to
the
the
far
end
endpoint,
but
the
Indian
media
perks,
trying
to
address
that
at
some
level.
But
how
do
we
do
that
by
end
default?
How
would
we
do
that
cleaner
and
better
in
in
a
very
generic
environment?
O
There
are
some
big
problems
that
we've
never
solved
an
SDP
things
like
that
have
become
more
and
more
relevant
as
we
move
away
from
Hardware
codecs
to
software
codecs,
where
you
might
have
a
device
that
it
could
do
two
big
screens
or
four
slightly
medium
screens
or
16
other
ones
or
an
infinite
number
of
other
possibilities.
We
have
no
way
to
represent
that
SDP,
and
you
know
SDP
is
a
very
difficult
thing
to
upgrade.
It
has
no
option
in
it
to
say
this
is
a
mandatory
to
understand
attribute
like
Jonathan.
O
O
So
we
use
stun
for
about
three
different
things.
We
use
it
to
find
the
IP
address
the
outside
of
the
nap.
We
use
it
to
do
connectivity
checks
in
ice
and
we
use
it
to
do
ongoing
consent
of
media
sessions
in
WebRTC,
and
none
of
these
properties
are
what
it
was
originally
designed
for
much
of
what's
in
it
to
actually
do
it's
things
like
changing,
IP
addresses
and
changing
ports
of
where
the
answers
and
responses
come
from.
None
of
that's
used
anymore,
the
bulk
of
it.
O
So
don't
you
can
imagine
like
for
the
first
use
of
this.
You
could
define
a
new
protocol.
That
was,
you
know,
stun
to
over
quick
that,
basically,
you
connect
the
server
it
sends
you
back
the
IP
address
and
that's
it.
There
is
no
requests
there
and
the
response
is
just
you
know.
The
address
and
port
that
you
came
from
I
mean
that's
really
much
easier
to
understand
and
implement
and
use
than
many
other
things,
and
the
problem
is
it's
not
just
it's
not
like
really
a
stun
service
that
hard
to
write.
O
O
Another
thing
that
I
think
is
very
interesting
for
us
to
look
at
changing,
and
this
goes
at
some
level
to
changing.
Rtp
is
what
would
it
take
to
reorganize,
not
the
semantic
information
we
put
in
RTP,
but
more
the
syntax
of
how
we
arrange
it
and
where
we
put
it
in
RTP
to
allow
us
to
really
work
well
with
these
ICN
networks.
O
These
ICN
networks
allow
a
client
to
express
interest
up
to
some
sort
of
up
towards
an
SFU,
but
it
might
be
intercepted
along
the
way
by
an
IC,
an
aware,
router
of
some
sort
at
various
different
levels
that
can
aggregate
that
and
make
it
so
that
the
SFU
only
need
to
send
one
copy
of
the
media
across
the
land
link,
and
then
this
branch
office
ICN
aware
router
distributed
it
to
multiple
clients.
So
it's
a
similar
thing
that
goodwill
multicast
did,
but
it
might
be
much
more
deployable
in
that
you
don't
need.
O
You
know
your
network,
the
telcos
network,
the
data
centers
network,
the
AWS
network,
to
support
multicast
in
a
way
that
works
together.
So
this
is
one
of
the
areas
to
where
I
think
that
if
we
started
with
a
blank
sheet
of
paper
and
figured
out
what
we
really
wanted
here,
we
might
suddenly
notice
that
Oh.
Actually,
if
we
were
willing
to
put
a
very
specific
header
in
the
RTP
header
extension,
we
could
put
this
into
our
teepee
with
no
g8
and
no
changes
to
the
existing
RTP
I.
O
O
Similarly,
with
rearranging
things,
I
mean
more
and
more
we're
getting
to
devices
that
can
do
quite
fast
processing
on
packets
off
off
cards.
You
know
into
something-
and
sometimes
it's
it's
distributed
very
much
on
the
machine
in
the
same
way
that
we're
seeing
a
lot
of
computation,
moving
from
general-purpose
CPUs
onto
GPUs
and
and
back
and
forth,
between
those
two
we're
also
seeing
computation
starting
to
move
on
to
processors
on
the
actual
NIC
cards.
O
We
also
have
the
it's.
You
know
type
of
environment
where,
even
if
it
is
still
happening
on
a
main
sort
of
general
purpose,
CPU
there's
very
efficient
ways
to
do
it
using
a
lot
of
these
vector
processing
techniques,
but
we've
probably
arranged
our
our
packets
I
mean
RTP
was
designed
in
a
way
was
never
thinking
about
this
type
of
stuff
is
probably
not
ideal
for
it.
So
we
should
explore
what
we
need
to
take
to
use
these.
Maybe
the
answer
be
nothing.
O
You
can
actually
do
it
on
the
given
stuff,
but
when
we
look
at
the
type
of
throughputs
that
we're
getting
on
these
systems
doing
other
things,
this
FD
io
is
a
software
based
router
purely
software
running
on
general-purpose
computer,
and
it's
it's
getting
a
terabit
per
second,
ok,
that's
like
a
million
HD
video
streams
and
I.
You
know
you
guys.
O
Can
all
you
know
what
your
your
s,
F
use
and
MC
use
do
on
the
number
of
concurrent
video
streams
it
supports,
but
you
know
I'm,
imagining
you're
several
zeros
off
a
million,
so
I
think
that
this
is
the
type
of
thing
we
could
ask
like.
Why
can't
we
have
not
a
2x
improvement
in
performance,
but
you
know
800
X,
improvement
in
performance.
Why
are
they're
so
much
better
than
our,
so
that
again
would
go
to
to
rethinking
about
this
next
slide.
O
There's
other
things
where
we
may
have
had
constraints
that
are
no
longer
really
key
anymore,
so
turns
a
good
example
of
this
turn
for
a
variety
of
reasons.
We
made
very
restrictive
how
you
have
to
install
permissions
in
a
certain
way
so
that
you
can
get
before
you
can
receive
traffic
from
other
people.
You
have
to
say
the
address
you're
expecting
the
traffic
from
basically,
and
this
was
to
preserve.
O
You
know
it
took
to
reduce
concerns
and
certain
enterprise
firewalls,
so
they
had
able
and
it
that
type
of
thing
there
are
now
so
many
different
ways
that
you
can
make
inbound
relays
and
run
servers
inside
a
firewall
and
get
data
outside
a
firewall.
I
think
this.
This
is
really
no
longer
an
a
design
attribute
we
needed
to
have
so.
If
we
remove
that
design
attribute
or
limit
it
or
reduce
what
type
of
things
it
works
for,
you
know
slack
just
loosen
it
up.
O
A
little
bit
we
can
reduce
the
amount
of
call
set-up
time
it
takes
to
bring
up
the
call.
We
can
work
in
a
few
more
cases
and
we
can
make
it
bunch
of
our
stuff
easier
and
we
could
define
a
turn
again.
If
we
decide
turn
over
quick,
we
could
probably
make
it
so
that
a
turn
implementation
was
as
simple
as
like
you
connect
to
it.
It
tells
you
the
public
address,
you
should
get
used
for
it
and
anytime.
O
So
the
other
thing
I
want
to
talk
about,
and
this
really
speaks
to
replacing
STP
STP
was
very
much.
I
was
gonna
say
it
was
designed.
Who
knows
when
it
was
hatched?
I,
don't
know,
but
it's
you
know
STP
and
in
the
way
we
talk
about
it.
Itf
is
a
you
know.
Alice
is
talking
to
Bob
and
it's
going
through.
Some
proxies
and
there's
two
state
machines,
two
controllers
on
either
end
that
are
trying
to
synchronize
what
they're
doing
to
their
media
stacks
in
this
offer
answer
form.
O
Okay,
and
this
is
an
awful
model
for
what
we
actually
deploy
in
the
real
world.
Nearly
every
deployment,
whether
you're
talking
about
large
cloud
conferencing
services
or
whether
you're
talking
about
enterprise
PBX,
is
whether
you're
talking
about
large
networks
have
lots
of
SPC's
in
them.
There's
generally
a
controller
for
the
call.
That's
trying
to
do
these
poke
through
this
bizarre
process
of
pretending
it's
doing
off
or
answer
with
all
the
endpoints
so
that
it
can
get
these
three
clients
a
B
and
C.
O
So
they
can
all
talk
to
each
other
through
the
SFU
okay
and
it
has
to
offer
answer
to
them
and
there's
like
there's
a
state
machine
in
a
a
state
machine
and
B
and
C,
and
then
a
controller
has
a
state
machine
for
a
B
and
C,
and
it's
trying
to
magically
causes
all
those
states
to
align
in
in
a
way,
that's
happy.
So
a
better
way
to
do.
O
So
you
know
this
is
this
is
an
area
where
I
think
we
could
have
a
design
that
fit
much
better
with
what
we're
actually
deploying
and
made
a
lot
of
our
existing
problems
go
away
also,
at
the
same
time,
I
think
we
could
go
through
SDP
and
I
recently
took
the
normative
dependencies
of
the
web
RTC
document,
so
I
took
the
w3c
web
or
CDA
document
and
all
of
its
normative
dependencies
and
then
recursively
down
its
Norman
dependencies.
But
I
stayed
just
in
the
stuff
that
was
media
or
SDP
I
I
carved
out.
O
You
know
crypto
security
protocols
like
TCP,
etc.
Okay,
and
this
is
basically
the
mass
of
stuff.
You
need
to
understand
to
understand
the
media
stack
in
WebRTC
and
it's
a
it's
4,800
pages.
Okay,
and
you
just
wonder:
do
we
really
need
all
of
that?
Is
there
a
lot
of
stuff
that
we
could
just
leave
behind
that
that
we
could
simplify
and
have
in
a
more
generic
way?
As
we
understand,
you
know
how
the
codec
Asics
change,
how
software
video
codecs
have
changed.
O
E
O
I,
don't
wanna
show
that
slide,
do
not
look
in
the
agenda
and
go
find
that
slide.
So
I
think
with
that
I'm
just
going
to
stop
right
there
I
am
interested
in
in
doing
is.
This
is
a
yeah
sure
yeah.
You
know
I'm
interested
in
finding
if
there's
people
who
are
interested
in
working
on
this
various
on
various
parts
of
this
project
are
various
things
and
trying
to
figure
out
a
way
that
we
would
evolve.
X
I
read
the
document
and
you
started
your
your
presentation
by
saying:
you're
not
interested
in
the
architecture,
but
basically
you're
talking
about
architecture,
because
the
IDF
we
try
to
do
building
blocks
like
this
in
other
work,
in
other
word,
groups
like
media
control
or
whatever
to
decompose
and
do
whatever,
and
there
was
never
a
good
view
of
everything
and
I
think
it's.
Maybe
if
you
want
to
do
it
and
I
was
reading
a
document
and
there's
things
like
hop
by
hop
encryption.
But
what
about
the
hops
really?
So
it's
not
kill.
X
You
have
to
have
some
architecture
as
part
of
the
definition
before
you
can
start
with
solution.
The
other
point
I
want
to
make
is
that
it
may
be
also
a
good
opportunity,
because
today
for
transporting
media,
there
are
two
metal
metal
metal
to
do
that
once
over
RTP
and
run
over
HTTP
for
the
streaming
in
live
streaming.
X
Basically,
the
last
one
and
I
think
it
may
be
a
good
time
to
see
if
we
can
do
some
convergence
on
the
in
that
space,
because
today
it's
it's
problem,
two
service
provider
to
provide
IPTV
and
other
services
that
they
have
to
have
two
different
mechanism
to
distribute
the
media
itself
and
I'm
willing
to
work
on.
That.
Of
course,
agree.
B
M
Obviously,
the
network
has
changed
significantly
since
we
designed
RTP
an
SDP
and
all
the
rest
of
us,
but
the
network
we
have
today
isn't
the
network
we
had.
In
the
mid
nineteen
nineties,
we
have
added
a
bunch
of
things
to
try
and
correct
some
of
correct,
follow
up
and
address
some
of
those
changes.
Some
things
we
cannot
change.
Obviously,
any
critical
that
is
25
years
old
has
a
bunch
of
crafts
in
it.
It
was
no
surprise
that
you
know
revisiting.
Some
of
these
decisions
may
make
sense.
M
M
People
have
you
know
some
extent.
We
succeeded
to
some
extent.
We
failed
people
deployed
applications
using
some
of
those
other
use
cases
and
based
on
some
of
those
other
use
cases,
and
some
of
them
are
very
widely
deployed
and
very
widely
used.
Today,
if
we're
going
to
redesign
the
stack,
we
should
think
about
whether
we
want
to
solve
this
specific
problem
or
whether
it
is
worth
trying
to
address
the
broader
problem,
and
we
should
understand
the
scope.
We
are
addressing
a.
M
Lot
of
the
things
I
think
you're
discussing
our
quick
issues
rather
than
media
issues.
You
know
the
piss
piss
stuff
is
something
that
should
give
us
quick
rather
than
for
media
over
quickly
and
I.
Think
also,
you
are
proposing
unique
solutions
to
things
which
I
suspect
the
web
folks
have
addressed,
and
we
should
perhaps
consider
lining
bets
with
the
web
architecture
for
some
of
these
issues.
A.
B
N
N
We
I
do
believe
that
we
cannot
do
this
by
making
an
overall
plan
to
rip
out
everything
and
replace
it.
So
I
disagree
with
your
approach.
I
haven't
this
gameis
with
a
few
of
your
particular
suggestions
for
technology
is
to,
but
that's
the
main
thing
is
I
disagree
with
your
approach,
because
I
think
we
need
to
think
in
terms
again
of
components
that
can
be
slotted
into
appropriate
places
and
interfaces
that
let
us
stop
binding
things
together
in
in
inappropriate
ways
so
that
when
people
say
our.
N
O
N
Suspect
that
their
overall
approach
will,
if
followed,
if
anyone
follows,
lead
to
something
that
we
can
deploy
in
seven
years
from
now,
I
suspect
that
a
componentized
approach
will
lead
to
a
number
of
systems
with
different
different
properties.
Some
of
us
who
are
slight
improvements
somewhere,
which
are
large
improvements
that
will
be
deployed
over
the
course
of
those
seven
years.
N
T
This
Joe
Hildebrand
has
Jever
relay.
This
came
in
sort
of
within
the
latency
window
of
your
having
cut
the
lines,
so
this
is
from
John
cleansin.
He
says
having
just
on
a
slightly
similar
analysis
for
the
DNS
RFC,
eight
three
to
four.
At
what
point
do
you
expect
to
think
about
what
it
would
take
to
get
any
improvements
you
suggest
deployed?
Some
of
these
changes
employ
rather
significant
transitions.
O
Where
would
you
like
to
go
from
here,
John
I,
to
fully
understand
what
you're,
saying
and
I
always
think
about
paths
to
deployment?
This
is
certainly
not
far
enough
along
to
to
possibly
know
an
answer
to
that.
Yet
and
and
I
mean
Harold
suggested
more
or
less
the
same
thing
with
this
that
whatever
is
done
on
this
will
be
totally
and
completely
unplayable.
So,
where.
O
Would
like
so
so
my
preference
would
be
to
figure
out.
A
list
is
fine
with
me.
I've
dispatched,
but
I'd
like
to
know
a
place
where
people
who
want
to
discuss
this
should
continue
discussing
it.
That
I
think
is
the
only
thing
and
I
don't
care.
If
you
don't
want
to
discuss
it.
I
still
want
to
know
where
I
can
continue
discussing.
You
can't
stop
me.
A
P
B
B
Yeah
thanks
my
slide
up
there.
It's
here,
I
just
wanted
to
highlight
for
everyone
that
we're
getting
close,
so
cluster
238
if
people
aren't
familiar
with,
is
this
giant
wad
of
almost
50
documents
that
have
tangled
web
of
interdependencies
that
have
been
hanging
around
in
the
RFC
editor
queue
waiting
for
everything
to
get
back.
You
know
finished
up
and
into
the
queue
behind
it,
so
they
can
publish
this
entire
thing,
most
of
which
is
WebRTC,
but
there's
also
other
media
related
things
in
there.
B
I
wanted
to
highlight
for
everyone
that
were
really
close
to
the
end
of
this.
In
case
people
are
like
waiting
for
these
documents
to
pop
out.
We
actually
have
only
11
things
at
the
moment
that
are
still
like,
not
in
the
RFC
editor
queue
of
them
only
for
the
four
at
the
bottom
here
are
actually
still
in
working
groups.
The
rest
have
already
entered
like
the
either
IETF
last
call
or
IES
G
processing.
So
this
should
be
popping
out
sometime
really
soon
in
case
you're,
paying
attention
just
one
make
sure
that
everyone
was
aware
of.
B
E
Y
Everybody
I'm
Bernie,
who
Nisan
I'm
about
to
tell
you
in
five
minutes
what
about
Apple,
mystique
encryption,
email
messaging?
What
oh
she
takes
like
half
an
hour
to
an
hour
to
explain
so
I
give
my
best
next
slide.
So
the
whole
motivation
comes
from
that
the
communication
is
always
like.
Listen
in
to
my
people.
You
don't
want
to
have
our
conversations
known.
Y
So
that's
why
we
aim
to
make
all
the
communication
email
chat
private
by
default.
So,
as
you
know,
we
have
already
good
tools
for
privacy,
I,
Cappy,
GPO,
PGP
and
others,
but
our
users
can't
use
them.
They
are
just
unable
to
use
them
like
I
talk
about
all
three
users
like
your
grandma
or
it
just
can't
use
them.
If
you
don't
need
to
fix
this
usability
challenge
by
automation,
you
need
not
just
good
privacy.
We
need
easy
privacy
next
slide,
please.
So
you
already
build
up
some
architecture.
An
architecture
consists
of
several
building
blocks.
Y
You
will
see
the
next
slide,
then
the
main
thing
is
direct
xre,
yeah
yeah,
so
we'll
use
existing
standards
and
RFC's
whenever
they
are
possible
and
it
can
be
applied
to
the
case.
But
there
are
still
some
pieces
missing
and
we
intend
to
document
these
missing
pieces
in
our
seas
now
next
book.
So
it
is
like
the
whole
picture
of
the
missing
pieces.
So
the
green
stuff
on
the
left
upper
corner
is
already
out.
It's
a
whole
description
of
the
system
and
how
it
works.
Y
Then
it
goes
further
to
email
like
a
new
message
formats
and
how
this
process
is
working
like
automatically
generation
of
key
is
adding
the
keys
and
so
on,
intend
to
add
also
like
a
mapping
to
s
mine
the
same
to
XMPP,
and
for
that
we
need
kind
of
an
easy
way
to
establish.
Trust
like
comparing
fingerprints
is
not
so
easy,
so
we
have
a
draft
that
is
like
mapping
the
fingerprints
into
trust
words
we'll
hear
more
about
this
tomorrow.
Y
At
the
same
time,
in
a
second
dispatch,
and
then
we
have
also
like
a
trust
rating
system
like
the
user
can
easily
figure
out
where
these
communications
encrypted,
whether
it's
clear
that
the
other
guy
is
the
one
I
want
to
talk
to,
and
you
have
a
mapping
into
user
interface,
symbols
and
colors
of
distrust,
State
City,
so
user
can
easily
understand
its
kind
of
semaphore
semantics
and
the
whole
bunch.
The
blue
area
is
synchronization
of
keys
between
devices,
so
the
users
have
keys
on
one
device
and
received
email
on
the
other
device
and
County
cryptic.
Y
So
we
need
to
share
these
keys
among
devices
and
when
you
need
to
do
it
securely
and
from
there
we
can
also
develop
some
calendar
and
contact
things
we
see,
which
is
not
in
focus
at
moment.
So
this
is
in
really
short
how
the
whole
architecture
works.
Next,
like
this,
so
the
IDF,
we
could
get
some
help
like
in
my
message:
formats
in
public
fee,
synchronization,
based
protocols,
mapping
your
eye
schemes
and,
for
example,
creating
IANA
registries
to
support,
trusted,
establishment
and
more
things
next
slide.
Y
For
those
of
you
who
want
to
know
how
this
works,
we
make
a
small
demonstration
in
Rome
Waterloo
on
Wednesday
10:30,
so
we
can
also
ask
there
are
some
more
questions
and
discuss
the
things
and
so
on
next
slide?
Okay,
that
was
it
okay,
so
that
was
basically
two
proposed
or
cool
to
tell
you
what's
going
on
and
if
there
are
any
questions,
please.
B
Okay,
so
this
will
be,
this
is
being
largely
presented
in
more
detail
at
sec
dispatch
and
will
be
handled
properly
through
there.
We
included
it
in
art
area,
because
email
is
our
area
and
we
should
be
aware
of
the
work
that's
going
on,
so
if
more
questions
are
probably
come
up,
insect
dispatch
than
here
we're
actually
out
of
time.
Well,
thank
you,
modern
for
the
extra
five
minutes
and
we
are
adjourned,
we'll
see
you
in
Montreal.