►
From YouTube: IETF114-DISPATCH-20220725-1400
Description
DISPATCH meeting session at IETF114
2022/07/25 1400
https://datatracker.ietf.org/meeting/114/proceedings/
A
A
Okay,
I
think
that
the
right
time
we
should
get
started
so
welcome
everyone
to
itf
week.
You've
got
me
kirsten
playing
one
of
the
co-chairs
for
dispatch
joining
virtually
and
we've
got
murray
sitting
at
the
front
as
a
physical
presence.
If
you
have
any
issues
on
site
at
all,
and
you
might
notice,
we've
got
a
change
of
co-chair
so
just
to
say
thanks
to
patrick
mcmanus,
for
his
great
stewardship
and
chairship
of
dispatch
over
the
years,
and
really
grateful
for
all
the
contributions
he's
made
and
replacing
him.
B
A
You
there
we
go
all
right
so
bear
with
us,
because
it's
always
the
first
session
and
dispatch,
so
we
always
have
a
bit
of
fun
working
out
how
the
technology
is
working
and
how
the
sessions
are
going
to
work,
and
so
we'll
just
run
through
a
couple
of
admin
points
before
we
get
started.
So
I'm
really
sorry
not
to
be
joining
you
in
person.
But
while
I'm
here
virtually,
let
me
just
remind
you
of
the
note.
Well,
this
is
probably
the
first
time
you've
seen
it
this
week.
A
So
it's
a
reminder
of
the
ietf
policies
that
govern
your
participation
and
please
make
sure
that
you've
read
all
of
these.
You
would
have
said
at
registration
that
you
would
do
so
in
particular,
take
note
of
all
the
kind
of
patent
policies
and
general
code
of
conduct
and
anti-harassment
procedures,
as
well
as
the
way
the
ietf
works.
A
If
you
have
any
issues,
contact
the
ombudsman
team
and
just
to
say
that
these
are
places
for
professional
collaboration
and
networking,
there
are
some
extensive
documentations
that
talk
about
the
way
that
you
should
be
behaving
at
these
meetings
and
if
you
have
any
concerns
at
all.
Once
again,
please
talk
to
the
ombudsman
team.
It's
important
that
we
create
a
good
environment,
so
everyone
can
bring
their
best
work
and
bring
their
best
selves
to
these
kind
of
technical
discussions
that
we're
having.
A
So
please
reach
out
to
the
ombudsman
team
or
anyone
around
you
that
you
trust,
if
you
experience
any
difficulties
or
offensive
behavior,
so
hybrid
meeting
participation
and
I
think
we're
all
still
getting
used
to
it.
Perhaps
you're
well
seasoned
by
now,
but
if
not
please
bear
with
just
while
we
run
through
this,
because
it
is
the
first
session
of
the
week.
So
a
lot
of
stuff
might
seem
new
or
has
changed
since
last
time.
A
So
to
the
folks
in
the
room
and
please
make
sure
that
you've
signed
into
the
session
using
the
meet
echo
light
client.
There's
a
nice
circle
there
to
show
you
exactly
the
button
to
join.
It's
really
important
to
join
that,
because
that
creates
the
blue
sheets,
but
also
it's
how
I'm
going
to
call
the
queue.
A
So
if
you
stand
in
the
room
at
the
mic,
but
you
have
not
joined
the
queue
on
the
meet
echo
light
client,
then
I
will
not
be
calling
you
in
to
the
queue
so
do
make
sure
that
you
have
joined
the
mike
mq
on
meet
echo.
We're
asking
you
to
keep
your
audio
and
video
off
if
you're
a
fully
remote
participant
or
if
you're,
on
the
on-site
version
as
well,
and
please
use
a
headset.
A
C
D
A
A
It
should
be
resolved
soon,
so
anyway,
try
and
bear
in
mind
for
the
other
meeting
sessions
that
you
have.
This
is
the
way
we
would
like
you
to
join
the
queue
thanks
colin
for
bringing
it
into
the
meeting.
I
do
love
having
the
first
meeting
of
the
of
the
week.
It's
very
enjoyable
okay,
so
just
so
you
all
know
this
session
is
being
recorded.
It's
very
important
that
you
know
that
this
goes
on
youtube
afterwards.
So
just
make
sure
anything,
you
say,
you're
happy
for
it
to
be
recorded
and
published.
A
That
way,
you
can
find
all
the
agenda
for
the
whole
week
at
that
link.
There's
also
meat,
echo
and
other
information.
If
you
have
any
technical
issues,
please
do
see
the
reporting
issues
page
and
all
the
meeting
and
notes
and
slides
and
everything
you
might
need
will
be
on
the
dispatch
page.
There's
also
jabber
and
tulip
that
you
can
give
a
go
as
well
for
this
this
session.
A
No
worries:
that's
okay,
we're
gonna
have
these
kind
of
teething
issues.
That's
why
again,
it's
the
joy
of
being
the
first
session
of
the
week
so
into
the
dispatch
hybrid
meeting,
giving
myself
a
healthy
four
minutes
just
to
run
through
the
agenda
and
take
any
agenda
bash
comments.
So
you
can
see
that
we've
got
a
bit
of
flex
time
today
and
but
we
have
five
presentations
flashing
between
either
20
minutes
or
10
minutes
for
various
items.
I
Hello,
jonathan
rosenberg,
five,
nine,
it's
not
on
the
agenda
and
I
don't
think
we'll
have
time,
but
I
submitted
a
draft
called
spin.
There's
been
a
lot
of
discussion
on
the
list
if
we
don't
get
to
it
here
I
do
want
to
let
people
know,
there's
a
mimi
buff.
Today,
that's
one
of
the
side
meetings,
so
we'll
try
and
do
some
discussion
there,
and
I
do
ask
if
there's
any
time
at
the
end
left
over
anyone
interested
like
to
discuss
this
topic.
A
Great,
thank
you,
jonathan.
Okay,
any
other
comments
before
we
dive
right
in
first
on
the
presentation,
slides,
it's
binary
application
record,
encoding
from
jury,
and
we
have
got
in
the
notes
and
the
links
to
the
slides
links
to
existing
messages
and
discussions.
Otherwise,
we'll
just
invite
him
to
come
up
and
present.
H
G
H
Hello,
everyone,
my
name,
is
siri
lasak
and
I
will
present
binary
application
record
encoding
or
shortcut
please
next,
so
the
first.
What
is
bare
it's
a
message
encoding.
This
is
binary.
It
scores
data
into
the
binary
that
are
then
used
to
store
these
data
on
or
transmit
these
data.
The
original
author
is
through
the
valve.
H
H
H
Next,
please
so
the
use
cases
for
bare
where
well
in
the
internet
of
services
or
internet
of
things
or
these
applications,
the
communications.
The
communication
is
really
important,
so
you
need
some
protocol
to
communicate
these
these
messages.
There
are
plenty
of
these
communications,
encodings
and
so
on.
H
The
bare,
as
we
saw
in
the
goals,
has
concise
messages,
simply
simplicity
of
implementation
and
is
used
to
communicate
between
these
web
services
or
communicate
between
the
the
internet
of
things
devices,
or
to
store
some
some
tokens
into
the
into
file
systems
and
and
so
on.
So
this
is
some
use
cases
of
of
the
bare
encoding.
H
Yes
well
so
this
was
in
short,
introduction
what
is
bare
and
how
it
can
be
used,
and
now
I
would
like
to
present
some
some
feedback
in
the
dispatch
mailing
list.
Up
to
today,
I
haven't
read
the
the
feedback
that
was
sent
today,
so
I'm
sorry
about
that,
and
the
first
was
the
comparison
into
cb
or
r
o
r,
concise,
binary
object
representation.
H
H
H
H
H
H
And
the
next
measurement
was
the
the
same,
but
zipped
or
compressed
form.
If
we
can
see
the
results
in
the
bottom
of
the
slide,
when
we
use
the
the
length
of
the
complete
messages
is
comparable
to
the
to
the
row
raw
data
when
we
use
cbor,
there
is
some
overhead
which
comes
with
cbor,
because
cbr
messages
contains
the
schema
of
the
messages
and
when
we
use
json,
there
is
even
a
greater
overhead,
the
same
apply
for
the
for
the
compressed
versions.
A
J
This
is
paul
hoffman,
co-author
of
seabor.
I
think
your
previous
slide
in
this
slide
have
a
pretty
significant
error.
A
seaboard
doesn't
have
a
built-in
schema.
You
can
build
one
in
if
you
want
that
would
be
complete
waste
of
overhead.
Here
I
looking
at
your
example
here.
I
cannot
imagine
how
it
would
be
twice
as
big
unless
you
tagged
every
item
saying
this
is
the
name.
This
is
this,
which
is
pretty
much
not
what
anyone
does
in
seaboard.
So
again,
seaboard
was
not
written
to
be
shortest.
J
H
Yeah
great,
thank
you
very
much.
I
am
really
sorry
about
that.
I
will
redo
the
experiment
and
update
the
threat,
email
thread.
To
be
honest,
I
used
the
the
cbo
r2
python
package
to
this
and
just
let
the
default
settings
so
so
there
may
be
some
some
problem
with
that
that
I
haven't
find
out.
I
will
I
will
make
note
and
dig
deeper
into
this
problem
and
try
to
try
to
do
the
measurement
again.
If
it's
okay.
H
H
These
were
mentioned
mentioned
in
the
in
the
feedback,
so
the
first
and
most
important
thing
is
that
none
of
the
above
is
standardized,
and
I
think
that
it
makes
sense
to
have
some
standard
just
because
these
these
frameworks
or
protocols
are
widely
used.
So
so
having
a
standard
that
is
well
defined,
makes
sense.
In
my
opinion,
I
would
like
to
repeat
what
bara
has
well
concise
messages
without
schema,
which
means
the
messages
are
concise.
H
It
has
the
octet
aligned
messages
with
the
little
indian
representation
when
possible.
The
encoding
is
ejective
and
the
butter
is
designed
with
the
simplicity
in
mind
what
I've
already
said.
So
next
slide.
Please
please
yeah.
This
is
the
comparison
of
the
of
the
types
used
and
available
in
encoding.
H
H
H
H
H
H
Other
thing
is
that,
of
course,
other
protocols
have
more
types
or
different
types
or
another
types
like
table
types
or
something
like
that,
but
but
it
tries
to
keep
keeping
being
simple
and
all
the
other
types
can
be
built
up
on
the
basic
types
of
of
the
barracks.
So
this
is
the
reason
why
some
some
types
are
omitted.
H
Yes
and
the
last
one.
There
is
clear
distinction
between
primitive
and
aggregate
types,
which
was
sometimes
in
bahrain,
which
was
sometimes
also
difficult
in
the
other
other
protocols.
So
next
please
yeah.
This
was
a
question
about
the
future
extension
points,
but
it
specifies
or
for
for
message
for
future
message
consideration,
but
I
suggest
to
use
unions
where.
H
H
H
A
Thank
you.
Thank
you
so
much
for
your
presentation
and
so
I'd
invite
people
to
join
the
queue
either
in
a
person
in
the
room
or
using
the
client.
If
you're
able
to
just
to
summarize,
we've
had
some
messages
on
the
list
so
far,
suggesting
sibor
and
others
suggesting
that
siebel
is
not
a
competitor,
and
I
think
richard
barnes
posted
just
this
morning
saying
sees
that
as
kind
of
a
tls
plus
10.
So
a
small
focus
working
group
with
his
suggestion
so
just
to
remind
participants,
keep
your
answers
focused
on
the
dispatch
question.
A
K
K
Level
like
the
way
structure
and
code
actually
could
exactly
contact
us.
We
had
extended
tests
a
little
bit
sympathetic,
the
idea
that
there's
need
for
attention,
so
it
seems
like
they're.
It's
not
implausible
to
me
that
you
know
it
would
be
useful
to
have
a
spec
that
was
that
just
encapsulated
the
syntax,
as
opposed
to
you
know
if
I
was
continuing
referencing
section
four
of
rfc
446
and
to
extend
it
a
little
bit
to
cover
you
know
what
kind
of
what
people
expect
from
a
modern
encoding
system.
K
I
agree:
there's
there's
a
bunch
of
other
binary
encoding
systems,
but
we've
had
a
bunch
of
success
with
tls,
syntax
and
and
lightly
extend
light
extensions
and
tls
syntax
in
the
atf.
So
all
right,
my
inclination
here,
probably
to
do
a
small
focus
working
group
if
we're
going
to
do
anything
in
kind
of
a
small
focus
room
starting
to
us,
adding
the
10
that
we
need
here.
A
L
I
think
richard
was
saying
he
supported
a
small
working
group
to
standardize
the
tls
syntax.
Not
this.
That's
not
actually
my
position,
so
I'm
just
trying
to
mirror
it.
So
I'm
not
particularly
interested
in
technical
details,
I'm
much
more
concerned
about
the
deployment
situation.
There
are
a
giant
pile
of
existing
things
like
this,
as
you
indicated
earlier,
and
the
fact
that
none
of
them
are
standards.
L
H
H
Definitely
we
also
had
the
feedback
in
the
mailing
list
of
some
some
researcher
that
that
tried
to
find
out
the
the
something
different
than
json
for
receiving
data
from
the
sensors
because
of
the
measurements-
and
this
was
particular
case
where
yv
allowed
in
the
in
the
standard,
the
full
compliance
with
I
triple
e
754
floating
numbers,
for
example.
So.
H
If
you
or
if,
if
you
need
some
some
giant
company
like
google,
to
backup
this
specification,
I
can't
offer
I
can
offer
nothing.
I
don't
have
such
a
company,
but
still,
I
think
there
is
a
need
for
standardization,
of
something
similar
to
bare.
That
would
be
a
simple,
simply
implemented,
which
would
be
a
safe,
concise
and
practically
with
the
same
same
properties.
A
Okay,
thank
you
just
to
say,
we
only
have
a
couple
of
minutes
left
in
this
item.
So
if
remaining
participants
can
make
their
comments
short-
and
I
completely
agree
that
implementation
is
an
implementation,
regardless
of
the
size
of
you
know,
it
doesn't
have
to
be
anti-competitive
in
that
kind
of
way
of
having
a
certain
size
of
implementer.
But
I
think
the
point
might
be
more
about
multiple
vendors,
as
is
being
discussed
in
jabber.
Okay,
so
next
in
the
queue
is
cullen
who's
physically
in
the
queue
I
think.
C
I
think
it
would
be
useful
to
standardize
something
along
these
lines
at
itf,
because
we
just
constantly
keep
repeating
this
and
building
it
individually
in
each
protocol.
You
know
we
have
a
tls
and
then
a
slightly
different
variant
in
mls
and
then
and
then
you
know
several
of
the
drafts.
I'm
writing
have
a
different
sort
of
variant,
so
I
think
it
would
help
us
write
drafts
to
have
a
tool
that
we
could
pull
out
of
the
box
and
use
if
we
wanted.
Obviously,
we
do
sometimes
use
c
boards.
C
Sometimes
you
use
this
sometimes
other
things,
so
I
don't
see
any
harm
and
I
think
it
would
be
useful
to
pick.
Maybe
it's
exactly
this
one.
Maybe
it's
something.
Maybe
it's
the
tls
one,
I
don't
really
care,
but
to
form
something
that
we
can
refer
to
and
is
standardized
and
is
roughly
along
about
the
level
of
weight
and
complexity
that
you're
proposing
here.
It
basically
has
exactly
the
sort
of
characteristics
of
what
you're
proposing
I
mean.
If
there
was
no
other
proposals,
I'd
be
fine
with
bear,
it
looks
it
meets
my
needs
exactly.
C
I
wish
it
had
a
sink
like
a
half
floating
point
thing
like
a
16-bit
floating
point
too,
but
I'm
sure
we
could
add
that.
So
I
think
it
would
be
worth
doing
something
like
this.
I
don't
know
if
there's
a
small
working
groups
the
right
way
or
whether
we
should
you
know,
have
a
bake
off
between
several
of
the
proposals
that
could
be
used
and
see
what
people
want
to
want
to
go
forward
with,
but
I'd
be
in
favor
of
having
something
thanks.
M
This
is
barry
lieber
first
I'll,
say
I
agree
with
what
ecker
said
the
overhead
in
the
ietf
to
just
to
standardize.
One
of
these
things
is
high
and
we
really
need
to
see
that
that
we
need
it,
that
it
it's
going
to
be
adopted
and
that
there's
a
pressing
need
for
it
before
we
get
into
that.
So
I
have
comments
from
two
different
roles.
I
am
one
of
the
co-seabor
co-chairs
now
I
have
not
spoken
with
my
co-chair,
but
I
would
support
discussing
this
in
seaboard.
M
A
N
An
irtf
group
or
an
art
area
charter
and
study
effort
or
design
team
to
bring
the
various
advocates
of
these
various
formats
together
and
see
if
they
can
agree
upon
something.
A
single
standard
for
these,
for
this
class
of
things
would
probably
move
us
forward,
starting
that
discussion
in
seaboard
would
be
fine,
but
but
moving
off
in
all
different
directions
with
more
and
more
of
these
is,
is
a
challenge
for
operability
and
not
helpful
for
the
internet.
Thanks.
A
O
Davidskenazi,
google,
so
plus
one
to
the
folks.
That
said
this
before
the
reason
that
we
have
like
17
different
non-standards
in
this
space
is
that
every
company
builds
their
own
to
fit
their
specific
needs
and
those
are
slightly
different
from
one
another
and
that's
why
google
has
protobuf,
for
example,
and
what
google
hasn't
like
moved
to
standardize
it
here,
because
we
want
to
keep
change,
control
and
modify
it
if
we
feel
like
it.
O
So
if
source
wants
its
own
format,
that's
totally
fine,
it
can
use
it,
but
unless
there
is
a
specific
need
from
other
vendors,
I
don't
see
any
reason
to
progress
this
in
the
ietf.
So
the
other
vendors
don't
need
to
be
the
size
of
google,
obviously,
but
there
needs
to
be
market
interest
from
outside
of
one
specific
vendor.
So
my
personal
thought
on
the
dispatch
question
is:
do
not
progress
this
unless
there
is
interest
from
multiple
folks
interested
in
implementing.
E
A
P
Cool
there
we
go
next
slide,
please,
let's,
let's
get
through
this
fairly
quickly.
I
think
describing
these
situations
fairly
easy.
Basically,
you
want
to
send
a
file
from
party
a
to
party
b,
but
neither
of
them
are
guaranteed
to
be
online
all
the
time,
so
you
have
to
store
it
somewhere
in
between,
ideally
that
third
party,
that
you're
storing
the
file
with
or
random
large
blob
of
data
doesn't
need
to
see
the
content
of
it.
P
P
Sorry,
this
text
a
little
bit
small
but
ideally
party
a
creates
and
encrypts
the
blob
up
uploads
the
encrypted
data
somewhere
tells
party
b
via
the
the
most
easy
to
read
and
easy
to
to
use
way.
Here's
how
you
decrypt
this
when
you've
downloaded
it
and
then
party
b
downloads
it
so
this
this
slide
is
lots
of
noise,
which
you
can
read
later
next
slide.
P
P
So
that's
why
I
thought
this
makes
sense
to
come
to
the
ietf.
The
reason
I
came
to
it
in
the
first
place
is:
I
want
to
implement
large
file
attachments
with
email,
which
means
putting
a
uri
somewhere
in
a
mime
part
saying
download
from
here.
What
we
have
at
the
moment
is
that
the
uri
has
put
as
a
link
in
the
html
version
of
the
body
with
little
or
no
annotation
to
say
this
is
an
attachment
at
all,
but
you
can
click
on
it.
You
can
download
it
in
whatever
email
receiving
program
you
have.
P
The
issue
here,
of
course,
is
that
nothing
does
that
yet
and
unless
it's
a
standard,
nothing
will
do
it
and
so
we'll
wind
up
having
to
wrap
every
single
uri
in
every
single
little
format.
In
the
same
way,
I
think
the
next
might
be
the
last
slide,
which
is
an
example
of
usage.
The
next
slide,
please.
P
So,
oh
yeah,
so
possibilities
for
design.
I
have
no
ideas.
This
is
not
my
area
of
expertise.
I'd
love,
someone
else
to
take
on
this
work
and
I
will
help
you
if
I
can
but
yeah
on
the
last
slide.
I
have
an
example
of
yet
another
place
where
this
would
be
useful.
That's
not
the
use
case
that
I
had
so
go
to
the
last
slide.
P
I
would
love
to
be
able
to
replace
this
with
something
that
says,
link
to
a
photo
and
the
server
where
the
photos
stored
can't
see
it
and
that
to
back
port
this
into
every
single
format,
with
separate
encryption
keys
very,
very
difficult.
But
if
you
could
just
say
a
uri
gets
downloaded
and
either
has
it.
It's
just
plain
text
from
the
server
and
downloaded
plain
text
over
https
sure.
A
Q
Thanks
everyone
thanks
ron
for
the
work
I
actually
got
in
the
queue
to
ask
a
scope
question.
So
it's
a
little
bit
late,
but
back
on
slide
four,
it
looks
like
you
had
a
party,
a
a
party
b
and
a
server,
but
it
wasn't
clear
what
happened.
If
you
also
had
a
party
c
d,
e,
f
g
h,
I
j
and
k,
were
you
expecting
each
of
them
to
be
able
to
using
the
same
decryption
key
for
it?
Q
P
P
N
F
Q
Q
This
is
the
place
where
you
retrieve
it
and
a
different
uri
like
a
data
uri
that
contains
the
decryption
key
that
you
want
to
send,
so
that
you
actually
then
can
use
multiple
different
paths
to
give
the
data
uri
without
necessarily
always
including
it
in
the
uri,
which
is,
is
used
along
the
path
that
that
part
ec
has.
But
I
I
think.
Q
P
Q
Love
carrying
them
both,
but
the
the
upshot
to
this
is
I
I
really
feel
like
what
you're
describing
here
doesn't
have
very
strong
confidentiality
characteristics
in
the
multi-party
case.
So
I
think
you
you'd
really
want
to
write
a
draft
for
the
security
considerations
where
you're
describing
what
it
is
you're
expecting
the
the
characteristics
of
the
confidentiality
or
or
other
characteristics
you're
getting
out
of
encrypting.
This
data
would
be
because
I.
G
P
P
P
A
F
R
It
will
be
pretty
straightforward
to
extend
message
external
external
body
to
do
this,
but
you
know
basically
you'd
add
some
more
stuff
to
the
external
body
with
the
keys
and
the
stuff,
and
we
already
have
the
syntax
to
have
a
url
elsewhere
in
the
message
that
refers
to
the
external
body.
If
you
want
people
they
will
link
to
it,
so
I
bought
it.
R
P
I
I
really
don't
want
to
do
it
at
that
level,
because
then
we've
got
yet
another
baroque
custom
format.
That's
only
in
one
place
for
handling
this
and
every
other
place
that
you
do.
Uris
needs
to
the
same
thing.
So
I
would
love
to
say
that
whether
it's
unencrypted
data
at
the
other
end
or
encrypted
data
at
the
other
end,
you
can
ask
your
system
library
to
please
fetch
this
data
make
the
transformations
required.
Give
me
the
plain
text.
R
I
still
think
it's
a
problem
worth
solving.
I
do,
but
I
I
do
think
now
we
we
want
to,
but
you
know,
but
basically
ted
and
I
are
both
saying
like
we
heard
fairly
different
things
that
ted
has
issues
of
who
who
can
decode
it?
I
have
issues
of
is
this?
Is
this
a
mime
type
or
is
this
a
uri?
So
I
think
I
mean
it
definitely
is
if
there
were
an
appropriate
working
group.
P
A
L
L
Yeah
sure
what
happened
I
this
gentleman
we're
solving
I'm
not
as
concerned
as
ted
is
about
the
security
properties
I
mean
like
they
are
what
they
are,
but
that's
if
we
just
set
the
thing,
as
you
say,
if
you're
just
something
in
the
body
be
the
same
so
so
it
doesn't
really
bend
me
out
of
shape
that
much
in
terms
of
location,
I
see
mark
donnie
himself
behind
me.
It
seems,
like
probably
this
seems
pretty
small,
so
I
would
tend
to
think
http.
L
I
know
it's
not
quite
a
great
fit
for
http,
but
we've
already
kind
of
like
done
a
bunch
of
some
more
crap
with,
like
you
know,
encrypted
bodies
and
stuff.
So
it
seems
like
it
kind
of
sort
of
belongs.
I
suppose
I
suppose
there's
an
http.
It
may
have
to
be
a
new
working
group
which
is
like
kind
of
heavyweight,
but
mark
may
have
a
different
opinion.
Yeah.
S
L
T
Oh
good,
I'm
here,
oh
good
yeah,
I
I
mark
nottingham.
I
kind
of
feel
like
this
is
an
area
that
that
is
prone
to
over
engineering.
If
we're
not
careful
the
the
most,
you
know,
if
you
don't
want,
if
you
want
to
communicate
a
key
with
the
uri,
but
you
don't
want
to
send
it
on
the
request.
The
most
obvious
way
to
do
those
fragment
identifiers,
as
you
saw
and
in
in
you
with
the
uri,
is
the
fragment
identifiers
defined
by
the
format,
so
define
a
format
with
a
fragment
identifier.
T
As
I
said
in
in
chat,
I
think
the
important
part
here
to
satisfy
a
lot
of
concern
is
to
describe
the
security
properties
of
that
thing
in
in
the
draft
and
we'll
see
where,
where
we,
where
we
get
from
there,
that
that
to
me
seems
like
the
most
straightforward
way
possible,
I
feel
like.
If
we
we
throw
this
to
other
venues
or
other
approaches,
we
might
come
up
with
an
over
complicated
solution.
G
A
Super
thank
you
very
much
brown
for
presenting
your
work.
I
think
there
I
was
hearing
that
a
bit
more
details
needed
to
understand
the
scope
of
the
problem,
but
the
problem
is
certainly
worth
addressing
and
a
couple
of
potential
avenues
going
forward
depending
on
the
detail
that
comes
from
that
draft
or
a
bit
more
scoping.
A
T
Do
you
have
a
question
or,
or
is
the
video
frozen?
I
think
the
video
is
frozen,
never
mind.
I
just
have
this
haunting
image
of
ecker
standing
at
the
queue
waiting
to
speak.
It's
a
little
disconcerting
okay,
so
this
is
gonna,
be
very
short.
I
think
this
is
about
a
draft
that
I
wrote
I
think
now
a
couple
months
ago,
privacy
considerations
for
web
feed
readers
next
slide,
please,
so
people
have
have
kind
of
assumed
that
that
web
feed-
you
know
web
feed,
so
rss
adam.
T
That
sort
of
thing
are
dead,
that
they're
not
really
interesting
anymore.
In
my
experience
and
from
talking
to
people,
that's
not
necessarily
true
next
slide
on
the
consumption
side,
there's
a
pretty
vibrant
ecosystem
of
different
feed
readers
and
different
consumers
that
have
built
some
sort
of
feed
reading
capacity
into
them.
T
There's
your
standard
kind
of
desktop
feed
readers.
There's
online
feed
readers.
There
are
products
that
aren't
feed
centric
that
also
use
them
in
really
interesting
ways,
for
example
the
kind
of
top
middle
shell.
Looking
logo
there
is
devin
think
which
is
a
kind
of
a
very
interesting
academic
tool
for
aggregating
information
that
uses
feeds
extensively.
T
If
you
choose
to
use
it
that
I
happen
to
use
quite
a
bit
next
slide
on
the
producer
side,
I
think
most
people
are
aware
that
there
are
a
lot
of
feeds
out
there
still
there's
still
a
lot
of
sites
that
produce
them.
You
know
by
default
either
because
the
underlying
tools
generate
them
or
because
they
have
some
constituency
for
that
to
get
some
sort
of
metric
on
that,
and-
and
just
because
I
was
interested,
I
wrote
a
little
tool
to
scrape
the
people.
T
You
follow
on
twitter
to
see
how
many
of
their
profile
urls
had
feeds,
and
it
turns
out
that
for
most
people
that
I
checked
about
a
third
of
the
profile
feeds
of
the
people,
they
followed
actually
had
sorry
profile,
urls
had
feeds,
which
was
really
really
interesting
to
me
that
that
you
know
there's
this
latent
kind
of
you
know:
ecosystem
of
feeds
out
there.
That
is
just
waiting
to
be
used.
T
If
people
bother
to
use
it
next
slide
and-
and
that
to
me
is-
is
kind
of
a
bit
of
a
theme
I
think
for
for
how
I
think
about
this.
You
know
the
feeds
web
feeds
are
our
latent
platform
on
the
internet,
they're
they're
out
there,
people
don't
think
about
them
a
lot,
but
they're
still
used
every
day
and
they're
still
available
and
next
slide.
T
You
know
when
I
say
platform
I
mean
things
like
you
know
what
people
call
the
web
platform,
so
this
this
you
know
ecosystem
that
you
can
build
on
top
of
the
the
obvious.
You
know
big
one
out
there
being
the
web.
Of
course
next
slide,
but,
unlike
the
web
feeds,
aren't
really
advertising
driven.
They
have
a
lot
of
really
unique
properties
as
compared
to
the
web.
The
information
you
get
in
feeds
has
a
different
tenor,
because
it's
not
able
to
be.
T
You
know,
advertising
driven,
usually
next
slide,
and
so
that
makes
me
think
what
can
be
done
to
improve
and
protect
that
platform.
How
can
we
bolster
it
so
that
it's
more
useful
to
the
people
who
want
to
use
it?
It
hasn't
gotten
a
lot
of
love
from
the
itf
for
for
several
years
now,
but
but
what
can
we
do
to
change
that?
I
guess
next
slide,
and
so
that's
what
led
me
and
that's
kind
of
the
thinking
behind
this
draft.
T
It's
a
draft
talking
about
what
are
the
privacy
considerations
for
this
platform.
You
know
when
you're
you're
making
requests
when
you're
handling
content.
How
should
a
a
a
feed
reader?
What
in
in
http
terms,
would
be
a
user
agent?
How
should
it
behave
regarding
user
privacy
next
slide,
and
I
think
that
that's
all
I
have
at
this
point.
This
is
very,
very
early
stage.
T
I
probably
could
have
taken
this
equally
easily
just
to
the
apps
area,
because
sorry,
art
area,
because
I
just
want
to
kind
of
give
people
a
heads
up
that
I'm
thinking
about
this
and
starting
to
talk
to
people
about
it,
I'd
love
to
hear
any
feedback.
People
have
from
a
dispatch
standpoint.
I
think
it's
too
early
to
dispatch
anything
like
this
to
another
place,
but
I
would
love
to
talk
about
maybe
getting
a
mailing
list
or
something
like
that.
T
A
J
Paul
hoffman
surprised
that
I'm
not
seeing
more
sport.
I
definitely
support
this
when
we
did
adam
hub.
You
know
in
the
paleolithic
era
there
was
a
lot
of
interest.
A
lot
of
stuff
happened,
it
became
invisible,
but,
as
mark
said,
is
still
there
adding
privacy
even
talking
about
privacy
would
be
a
good
thing,
because
this
is
definitely
part
of
the
ecosystem.
Still
it's
not
like
we
we're
trying
to
do
an
art.
J
I
assume
mark
is
not
trying
to
make
this
more
important
and
you
know
web
3.5
or
whatever,
but
just
you
know
something
to
say
we
you
know
we
started
something
we
should.
We
should
keep
working
on
it
in
a
privacy
level,
so
definitely
interested.
I
think
a
mailing
list
would
be
a
reasonable
start
and
if,
if
it
needs
to
be
a
working
group,
I
think
it
can
be.
J
A
Thank
you
very
much
presenting
mark
yep,
so
I
think
the
outcome
there
again
disagree
in
java.
If
this
is
wrong,
but
it
sounds
like
we
would
create
a
mailing
list
for
further
discussion
and
a
couple
of
plus
ones
they're
starting
a
list
and
seeing
how
much
energy
there
is
and
hoping
it
will
get
people
thinking
about
rss,
more
so
super
move
on
to
our
next
presenter.
V
Hello,
welcome.
Can
everybody
hear
me
okay,
closer
closer,
all
right,
that's
why
I
did
it
all
right
thanks
everybody
good,
even
closer.
How
about
that?
This
is
why
we
tested.
Is
that
good,
a
little
better
right,
good
awesome,
hey
thanks
everybody
for
having
me
today
online.
I
got
bradley
peabody
with
me
other
co-author
of
this
today
we're
going
to
talk
about
new
uuid
formats,
really
it's
new
uid
versions.
Next,.
J
V
Please
so
one
of
the
a
couple
of
the
problems
with
rfc
4122
is
that
the
main
timestamp
based
uuid
suffer
poorly
from
database
index
locality
problems,
the
uuid
version,
one
that
we
call.
It
has
a
very
uncommon
epoch
choice,
the
gregorian
epoch,
which
goes
to
a
timestamp
length
of
100
nanoseconds,
which
is
pretty
odd
right
and
then
to
further
compound
that
problem.
They
split
the
epoch
up
into
a
weird,
a
weird
way:
sorry
get
my
hands
out
there
and
it
just
causes
all
kinds
of
weird
issues.
V
So
we've
taken
an
examination
of
that
and
figured
out
a
different
way
to
do
it,
and
we
actually
found
a
lot
of
people
internet
who
are
untangling
that
epoch
and
just
slapping
a
version
4
on
it.
So
we're
going
to
try
and
standardize
that
as
version
6.,
so
the
people
who
are
doing
this
and
want
the
benefit
of
it
have
a
place
to
do
that
in
a
standard
track.
V
Around
uuid
generation
versus
uuid
storage,
in
terms
of
things
like
databases
and
overall,
just
a
lot
of
clarifications
around
little
things
like
big
indian
versus
little
indian
stuff,
that
the
errada's
have
an
opened
on
4122
and
we've
kind
of
tried
to
address.
As
many
of
these
as
we
could
in
this
update
to
4122
under
some
of
our
new
versions
and
I'll
go
through
those
real,
quick,
real
fast.
Next.
W
V
Okay,
so
uui
version.
Six,
like
I
said,
is
it's
the
time
based
input,
it's
the
same
as
uuid
version,
one
we're
just
not
swizzling
around
the
bits,
we're
taking
the
timestamp
as
it
is,
that
hundred
nanosecond,
gregorian
epoch
and
we're
laying
it
down,
and
then
the
rest
of
the
uid
layout
is
exactly
the
same,
and
this
is
something
that
many
many
many
places
have
been
doing
and
they
either
put
like
a
version
zero
on
it,
which
is
weird
or
they
throw
it
as
a
version
six.
V
So
it
looks
like
it's
a
random
address,
but
that's
all
we're
doing
with
the
version
six,
so
we're
just
labeling
what
other
people
are
doing
out
there
right
now
and
giving
them
a
place
to
do
it
officially.
We
also
make
the
subtle
hint
to
try
and
not
use
mac
addresses,
but
we're
not
going
to
outright
say
you
can't
use
mac
addresses
because
if
we
want
to,
you
know,
have
a
one-to-one
conversion
and
people
want
to
swap
from
version
one
to
version
six.
V
They
can
do
that
under
this
pretty
easily
next
slide,
please
so
version
seven
has
really
been
the
focus
right
of
this.
We've
looked
at
this
and
we've
said:
what
can
we
do
better
if
we
were
going
to
make
a
time-based
uuid
right
now
and
the
obvious
thing
is
to
use
a
better
epoch,
which
is
the
well-known
unix
epoch,
and
then
it
comes
into
questions
like
how
long
do
we
make
this?
V
What
precision
level
do
we
make
this
and
there's
been
a
lot
of
back
and
forth,
and
we
ended
up
laying
down
a
48-bit
unix
epoch
with
a
millisecond
time
stamp
and
the
rest
of
the
uuid
layout
is
random.
It's
entropy
and
you
can
move
the
slider
left
and
right,
and
if
we
move
a
little
bit
more
time
stamp,
we
get
one
side
of
the
field,
who's
really
angry.
If
we
move
it
to
the
other
way
and
give
it,
you
know
less
time
stamp,
the
entropy
folks,
you
know
both
sides
are
very
heated.
V
We
laid
on
and
landed
on,
millisecond
time
stamp
so
that
it's
the
most
ubiquitous
to
implement.
There's
lots
of
libraries
that
can
do
this.
The
timestamp
is
very
well
known.
It
caters
99
of
the
use
cases
next
slide
for
those
other
one
percent
of
the
use
cases.
Those
folks
that
want
to
use
a
custom
epoch,
they
want
to
start
something
right
now
and
start
counting
up
time.
V
They
want
to
use
nanosecond
level,
they
can
use
uuiv
version
8,
which
is
every
bit
of
this,
except
for
the
version
of
the
variant
are
for
you
to
use
in
anything.
You
want
this
future
proofs.
Our
spec
allows
very
custom
uuids
to
have
a
space
experimental
uuids
to
have
a
space
versus
slapping
a
version
4
on
it.
They
can
do
that
under
version
8..
If
you
want
to
take
version,
7
fork
it
and
do
whatever
you
want
with
it.
You
can
do
it
within
the
space
of
a
uuid
version.
8.
V
Lastly,
this
is
kind
of
an
oddball
uuid,
but
we're
just
writing
down
and
saying
that
the
maximum
value
for
uuid
is
being
defined
in
the
spec,
which
is
all
bit
set
to
a
one.
4122
sets
the
nil
uuid
as
all
bits
set
to
zero.
We're
just
writing
down
the
opposite
of
that,
so
that
library
generators
can
actually
write
this
down
and
reserve
it.
So
you
don't
use
it
in
some
weird
way.
This
is
for
some
needle
and
haystack
operations.
V
Next,
all
right,
so
we've
done
a
lot
of
prototyping.
We've
done
a
lot
of
data.
Modeling
we've
been
working
on
this,
for
I
mean
brad's
been
working
on
for
about
three
years.
I've
been
working
on
for
about
two
years.
We
have
taken
everything,
we've
done
with
library,
implementers
prototypes
and
and
put
this
into
kind
of
a
swan
song
to
the
implementers
out.
V
There
we've
solved
a
lot
of
problems
and
whether
it
be
you
using
version
7
or
making
your
own
under
version
8,
we
have
a
really
nice
list
of
what
you
should
do
or
should
not
do.
Some
of
these
are
like
time
stamp
granularity,
reliability,
source
precision
and
accuracy,
fuzzing
altering
smearing,
padding
or
truncating
right
your
uuids.
Let's
say
you
can
only
generate
32-bit,
unix
timestamp.
How
do
you
make
that
work
in
the
48-bit
space
monaticity
encounters
for
when
things
need
to
be
laid
down
in
a
database
in
an
exact
order?
How
do
you
do
that?
V
What's
the
placement
that
makes
sorting
really
nicely?
How
do
you
generate
those
or
seed
those
from
the
beginning?
How
do
you
increment
those?
Is
it
a
random
increment
or
is
it
a
linear,
increment
and
other
topics
like
distributed
uuid
generation
across
multi
nodes
that
may
not
talk
collision,
resistance
mechanisms,
local
and
global
uniqueness,
csr
unguessability
through
csp
rng,
sorting,
considerations,
opacity
and
introspection
database
considerations?
We
talked
about
really
briefly
about
how's
the
best.
What's
the
best
way
to
store
these
in
a
database
and
then,
finally,
of
course,
security
considerations.
V
We've
gone
at
great
lengths
to
really
put
the
last
half
of
this
document
as
a
this
is
what
you
should
do,
and
this
is
the
best
way
to
do
it
based
on
all
of
our
research
and
then
last
slide.
I
just
want
to
talk
real
quick
about.
Do.
We
have
a
need?
Yes,
there's
a
lot
of
energy
from
our
community
on
the
next
generation
of
uuids,
a
lot
of
people
like
uuid
version
seven,
and
you
can
see
that
yes
column
in
the
middle.
V
Almost
everybody
is
implementing
that
I
have
a
lot
of
uuid
version,
eights
out
there,
that
I
have
to
find
that
are
folks
who
really
liked
what
we
had,
maybe
in
a
previous
draft,
and
we
tweaked
something-
and
they
said
I'll.
Just
I'll
keep
that
I'll
put
it
as
an
eight
and
then
they
just
throw
an
eight
on
it
and
gives
them
the
space
to
do
that.
There's
more
implementations,
but
those
are
on
version
two
or
version
one
of
our
draft,
so
they're
slowly
being
updated.
But
you
can
see
there's
a
lot
of
different
languages.
V
A
O
Thank
you,
davidskenazi.
Google,
thanks
for
this
presentation
like
that,
was
exactly
what
I
like
what
we
were
kind
of
looking
to
hear,
and
so
thank
you
clearly,
there's
interest
in
this
and
clearly
you've
done
a
lot
of
homework.
I
would
like
to
see
this
published.
It
sounds
useful
as
far
as
dispatching
it.
O
V
A
C
It's
it's
one
of
those
things
with
a
lot
of
subtle
complexities,
that
sort
of
break
things
like
who
would
have
thought
of
the
database,
and
you
know
I
mean
there's
all
these
issues,
so
I
think,
having
a
long-term
sort
of
place
where,
if
any
of
these
updates
come,
we
get
the
knowledge
in
one
place.
That
sort
of
knows
the
history
of
why
things
are
the
way
the
way
they
are
and
what
went
right
and
what
went
wrong
is
probably
pretty
good
and
there's
a
lot
of
errata
on
those
drafts
too.
C
X
Thanks
alyssa
cooper,
so
I
was
just
looking
at
the
history
of
4122,
which
also
looks
like
it
was
80s
sponsored,
but
I
wasn't
here
at
the
time,
so
I
don't
know
ted
or
very
people
who
remember
if
that
was
a
good
choice,
but
agree
with
colin
that
it
might
be
that
that
wasn't
a
great
choice
and
that's
why,
like
we
have
a
pile
of
erada
and
other
other
things.
So
it's
worth
like
learning
from
that
experience
and
having
that
inform
what
we
do
next.
A
L
Yeah,
so
this
does
seem
like
a
reasonably
compelling
argument
that
something
needs
to
be
done
just
looking
at
the
body
of
work.
Here,
I
think,
would
be
an
appropriate
day
to
sponsor
it.
Like
does
much
work
behind.
It
should
be
working
grouping
if
it's
a
very
fast
working
group,
because
that's
like
how
things
get
handled.
A
Okay,
then
murray's
noted
that
rfc
four
one,
two
two
is
a
d
sponsored
by
ted.
So
it
seems
like
the
mood
of
the
room
is
either
that
the
work
should
go
forward
and
it
should
go
forward
in
the
least
friction
full
way
possible,
so
either
a
small
tightly
sketched
working
group
or
an
ad
sponsorship
murray
as
the
80
in
the
room.
Any
comments
on
your
view
or
something
for
us
to
pick
offline
and
discuss.
D
A
Yes,
thank
you.
I
can
see
a
couple
of
comments
in
java
as
well,
where
my
group
sounds
good
or
working
group
is
the
path
and
there
maybe
there's
some
discussion
to
be
had
about
whether
it
should
just
be
for
this
draft
or
if
it
could
be
a
more
general
long-term
care
for
uuids
and
but
that
would
be
worked
out
in
the
charter.
I
suppose
so
I
think
there's
no
more
comments,
no
more
people
in
the
queue
so
we'll
just
say.
Thank
you
very
much
kaiser.
A
I
think
we
have
our
dispatch
outcome
and
thanks
very
much
for
taking
the
time
to
present
to
us
here,
and
so
we
move
on
to
our
last
agenda
items
today.
The
discarding
priority
of
rpp
video
packets,
there's
been
quite
a
bit
of
discussion
on
the
list
about
this,
so
we'll
just
stop
sharing
the
slides.
If
that's
the
issue
thing
and
I
can
share
the
new
slides.
Y
Y
In
this
presentation,
I
mainly
want
you
to
want
to
show
you
that
you
know
the
importance
of
the
packet
payload
would
decide
the
discarding
priority
of
the
packets
when
network
congestion
happens.
So
then
I
also
want
to
discuss
how
to
achieve
this
prioritize
discarding
when
network
congestion
happens
through
the
dsp
field
and
mapping
next
slide.
Please.
Y
Y
And
by
reading
those
drafts,
I
I
found
out
that
they
are
actually
priority
indicator
of
the
packets
in
those
rtp
headers
or
say
they
called
an
ar
headers.
So
I
will
briefly
talk
about
those
in
the
next
following
slides.
Next
slide,
please
so
for
for
h.264,
the
coded
video
data
is
organized
into
the
in
our
units
and
then
the
rtp
packet
for
h.264
video
inherits
the
same
and
air
unit
header.
So
it
has
two
bits
here
called
an
ri
field.
Y
U
Y
Y
Y
Additionally,
it
has
three
bytes
in
the
entire
unit
header,
which
includes
the
pr
id
which
is
called
priority
id,
which
has
six
bits
and
also
did
qid
and
tid,
because
svc
actually
supports
the
different
levels
of
scalability
next
slide,
please
and
for
h.265,
because
it
has
improved
sport
of
temporal
scalability
over
h.264
includes
this
tid,
which
is
three
bits,
so
it
indicates
the
temporal
layer
of
that
packet
belongs
to
so.
The
lower
temporal
layer
means
more
importance,
because
it's
the
base
layer,
it
will
be
used
to
predict
other
layers.
Y
Y
It
has
the
layer,
id
and
tid
similar
as
h.265,
however
yeah
additionally
similar
to
h.265.
Of
course,
the
tid
indicates
the
relative
importance
and
then
has
addition.
This
layer
id,
which
is
six
bits
it
is
further,
indicates
how
important
the
layer
id
is.
Sorry
further
indicates
how
important
this
packet
is:
go
go
to
the
next
slide.
U
Mozinati,
cisco,
mozinati,
cisco,
there's
a
draft
in
abt
core,
that's
close
to
rfc
called
video
frame
marking.
That
goes
over
a
lot
of
these
points
and
what
it
basically
does
is
it
normalizes
across
all
of
the
codecs,
not
just
the
itu
codex,
but
also
alternative
codecs
like
vp8p98v1,
and
it
normalizes
them
into
a
common
format
for
describing
the
the
dependencies
and
the
the
priority
of
of
the
temporal
and
spatial
layers.
And
so
really
all
that's
missing
is
in
your
draft.
You
can
instead
of
referencing
every
single
codec.
U
You
could
reference
an
rtp
header
extension
that
carries
that
same
information.
The
difference
is
that
you're
jumping
all
the
way
to
mapping
that
directly
to
a
dscp
priority,
and
that's
a
that's
a
step
that
we've
had
a
lot
of
argument
about
before
about
how
to
how
to
do
that.
Mapping
and
so
I'd
suggest
you
separate
those
two
things.
One
is
identifying
the
the
layers
and
the
varieties
of
the
layers
very
specifically
and
there's
already
rtb
header
extension
to
to
surface
that
codec
agnostically
and
then
mapping
that
to
a
network.
Y
Y
Y
Y
Y
Y
Y
So
what
I
was
thinking-
maybe
you
know,
instead
of
just
mapped
to
a
single
f
class,
we
can
map
to
multiple
af
class,
as
I
mentioned
in
the
previous
two
slides
go
to
next
slide.
Please
and,
and
another
thing
is
about
you
know
you
have
to
h.266
and
h.265
svc-
you
have
the
pr
id,
which
is
six
bits
which
provides
more
granular
priority
information
about
lab
packets
and
also
you
have
h266
the
layer.
Id
also
is
six
bits
which
again
providing
more
discarding
priority
information.
Y
Y
Oh
yes,
yes,
okay,
all
right!
So
obviously
this
is
maybe
relevant
to
avt
core.
However
abt
core
is
specified,
is
you
know,
a
major
scope
is
to
specify
and
maintain
payload
formats
for
use
with
trtp
may
not
consider
how
you
know
how
to
actually
use
those
values
in
the
network
layer
and,
I
think,
the
most
relevant,
maybe
the
transport
air
area
and
working
group
yeah.
Let's
all
for
my
presentation,
I
will
take
questions.
A
W
Hi
this
is
pete
yeah.
It
seems
pretty
straightforward
that
the
people
who
can
evaluate
most
of
this
are
an
avt
core,
so
I
would
suggest
taking
the
document
there
as
the
dispatch
for
this,
and
someone
mentioned
in
the
chat
room
that
perhaps
tsvwg
could
take
on
the
dcsp
bits,
and
I
think
that
would
be
fine.
But
avt
core
has
the
expertise
to
evaluate
this,
so
you
might
as
well
take
it
there
in
the
first
place.
S
If
it's
not
iptv,
I
wonder
because
there's
as
I
wrote
in
the
latest
email
there's
multi-stream
aspect
of
this,
which
makes
doing
this
across
all
the
media
streams
blindly
is
unoptimized
in
many
ways
and
lose
you
more
calls
than
doing
it
in
the
media
where
an
application
aware
way.
So
I
think
there's
a
question
saying:
what
are
you
really
trying
to
accomplish
here?
What
are
you?
What
do
you
actually
need
so?
But
I
think
abd
core
is
a
reasonable
place
to
discuss
in
this,
but
it
comes
to
rp
and
the
usage
and
architectural
question
here.
S
Y
So
I
mainly
want
to
you
know
to
use
those
bits
in
the
network
layer
when
our
congestion
happens
just
to
randomly
instead
of
randomly
discarding
packets.
It
may
you
know
now
if
the
routers
is
able
to
know
which
packet
is
more
important
for
decoding
end,
to
improve
the
user's
end
of
quality
or
quality
of
experience.
Maybe
it's
better
to
yeah.
S
U
So
if
you
really
want
to
look
at
the
delivery
to
be
optimized
and
what
should
be
dropped,
you
should
also
look
at
things
like
you
know,
wi-fi
upstream
priorities
and
even
in
mobile
networks,
you
know
look
at
the
more
complicated
ways
that
rands
can
can
also
prioritize
things.
So
I
don't
think
dscp
is
really
going
to
give
a
lot
of
benefits
to,
especially
since
it's
usually
not
carried
through
interoperably
across
a
large
segment
of
the
network.
Y
Yeah
yeah,
thank
you
for
commenting.
I
agree
like
dscp
may,
have
remarking
issues,
so
it
won't
carry
all
the
weight
from
end
to
end
yeah.
I
will
probably
need
to
consider
if
there
is
other
fields
in
the
ip
protocol
which
can
carry
this
kind
of
information
that
could
be
leveraged
by
network
nodes.
Thank
you.
A
A
E
Yeah
hi
mia
could
have
been.
I
agree,
so
the
for
the
dispatch
option
going
to
avt
core
or
to
tcp
wwg
would
be
fine
if
you
go
there.
I
want
to
add
to
magnus
comment
that
I
think
it's
not
only
about
the
use
case.
It's
only
about
showing
data
that
this
is
actually
improvement,
because
usually
the
the
video
streaming
is
adaptive.
So,
like
you
shouldn't
have
long
periods
of
congestion.
It's
like
a
few
packet
loss.
G
Y
E
AA
AA
Other
transport
streams
may
benefit
from
that
and,
additionally,
the
notion
that
udp
is
not
sensitive
to
reordering
may
be
true
for
some
protocols
running
on
udp,
but
I
find
it
difficult
to
generalize,
for
example,
quick,
maybe
more
sensitive
to
to
reordering
and
the
router
may
not
know
the
difference
between
quick
and
rtb.
Thank
you.
Yes,.
AB
Thomas
eckhart
future
way
so
to
miriam's
comment
of
whether
this
is
you
know
important
or
not.
There
have
been
you
know.
Good
good
results
from
the
past
shown
that
it
obviously
is
valuable,
because
the
impact
of
losing
even
a
single
packet
of
a
reference
frame
like
an
iframe
in
a
video
stream,
may
cause
a
complete
interruption
blackout
of
a
video
stream
for
a
whole
group
of
pictures,
which,
for
example,
in
something
like
dish.
AB
Networks
has
been
up
to
five
seconds,
whereas
a
similar
loss
of
a
packet
for
a
non-reference
frame
like
a
pre-frame
just
causes
a
blip
that
any
good
setup
box
can
hide
from
you.
So
there
is
a
totally
different
degree
of
impact
of
even
very
short
packet
losses,
and
you
know,
even
with
ecn,
we've
seen
that
we
can't
completely
avoid
any
loss.
So
I
think
you
know
managing
that.
Loss
in
this
manner
is
a
highly
valuable
thing
to
do,
especially
the
more
you're
getting
into
real-time
and
non-delay.
A
Thank
you
very
much
and
just
to
say
that
I'm
hearing
that
it
sounds
like
a
lot
of
support
from
this
abg
core
and
tsb
working
group
once
the
use
case
and
performance
gains
have
been
clarified.
If
you
disagree
with
that
summary,
please
come
up
to
the
mic
and
express
that.
If
you
agree
then
also
please
come
up
to
the
mic
or
put
it
on
jabba
and
express
that
view.
Next
in
the
queue
is
jonathan
lennox.
Z
Yes,
jonathan
lennox
yeah
to
the
dispatch
point
as
an
apt
court
chair.
I
say
this
is.
I
think
this
would
be
entirely
in
scope
of
abt
car.
I
mean
again
with
the
dsvwg
doing
the
diffserv
parts.
To
the
use
case
point.
I
think
it
depends
the
assumption.
The
network
assumptions
you
get
for
like
set-top
box
streaming
versus
interactive
video
conferencing
are
quite
different,
and
I
think
that
if
you're
looking
at
a
set-top
box
streaming
type
use
case,
I
think
this
might
be
more.
Z
A
So
that's
the
end
of
the
part
of
the
meeting
at
the
moment,
so
just
to
run
through
a
summary
of
the
dispatch
outcomes
which
we
will
also
email
to
the
list
and
make
sure
the
minutes
fully
reflect
this
and
the
bar
a
dispatch
outcome.
There's
a
possible
working
group
or
discussion
forum
on
this
topic
because
it
repeatedly
comes
up,
but
not
necessarily
this
exact
proposal.
There
is
a
consensus
that
it
needs
to
be
more
widely
applicable
and
implemented
more
widely
than
only
one
party.
A
Therefore,
that
outcome
is
to
find
more
supporters
and
return
with
this
proposal,
possibly
others
for
working
group
scoping
on
bronze
item
transparently,
decrypting
uris.
The
outcome
was
that
the
work
is
worth
doing.
There
are
more
specifics
that
need
detailing,
so
it
can
be
properly
assessed
and
sent
to
the
right
place
since
we
were
hearing
differences
between
s,
mime
or
http
kind
of
similarities.
So
come
back
with
a
draft
work
to
progress
on
the
web
feeder
reader
dispatch
outcome
very
simple,
create
a
non-working
group
mailing
list
on
this
topic
for
the
uuid
dispatch
outcome.
A
There's
some
weak
support
for
a
working
group
performing
a
tightly
focused
or
a
longer
term
caretaker
for
uuids
and
maintenance
of
the
drafts,
and
so
that
will
go
to
the
dispatch
mailing
list
to
find
volunteers,
to
form
a
charter
and
flesh
out
which
of
those
two
options.
It
would
be
and
then
finally
discarding
priority
of
rtp
video
packets,
the
dispatch
outcome
was
the
use
case
needs
clarifying
gains
and
performance
need
clearly
demonstrating
and
then
once
those
aspects
have
been
updated
to
take
it
to
abt
core
and
tsp
working
group
which,
for
the
dscp
specific
aspects.
A
So
that's
a
rundown
of
our
dispatch
session.
Today,
thanks
to
everyone
who
presented,
it's
always
really
nice
to
see
new
work
coming
to
the
ietf,
really
grateful
for
you
bringing
your
time
and
effort
to
us
and
at
this
point,
we'll
shift
into
the
art
area
portion
of
the
meeting
so
I'll
just
share
the
slides
and
then
hand
over
to
mary.
D
D
I
was
hoping
to
have
a
photo
of
a
newborn
to
all
share
with
you,
but
that
has
probably
not
happened
yet
a
quick
update
on
some
meetings
of
interest
coming
of
interest
to
this
area.
We
have,
you
can
see
the
list
here,
the
ones.
The
couple
that
I
want
to
point
out.
Tigris
is
a
brand
new
working
group.
Meeting
this
week,
mock
isn't
going
to
attempt
to
create
a
bar.
D
D
So
some
just
some
comments
from
us
next
slide.
Please
errata
people
in
this
room
may
or
may
not
know
about
errata.
It
is
a
service,
a
record
keeping
service
provided
by
the
rfc
editor
about
documents
that
have
already
been
published,
but
they
need
to
have
some
kind
of
correction
made
to
them
or
on
the
record
so
that
people
know
there
are
corrections
that
have
been
recorded,
that
you
might
need
to
know
if
you're
implementing
this
specification,
they
can
be
also
folded
in
later
on.
D
D
We
will
reject
those
next,
please,
these
have
historically
the
atom
once
processed
is
either
rejected
because
it's
wrong
or
improperly
used,
it's
verified,
meaning
we've
confirmed
that
this
is
true.
This
should
be
properly
recorded
and
possibly
processed
later.
The
third
state
is
hfdu,
which
sean
turner
says
hold
for
the
death
of
the
universe,
but
it's
hold
for
document
update,
wait
for
the
next
version
before
you
actually
do
any
something
with
it.
These
are
often
left
neglected
and
not
actually
processed.
D
What
you
see
here
is
the
number
of
unprocessed
in
each
of
the
three
areas
for
art
and
its
previous
versions
are
apps
and
rye.
So
we
have
a
large
body
of
work
that
hasn't
been
looked
at
yet
this
is
just
historically
something
that
we
haven't
paid
much
attention
to,
but
they
do
need
to
get
processed
sooner
or
later.
So
some
of
these
art
ones
are
for
current
working
groups,
and
so
you
can
actually
go
and
see.
D
If
there's
something
here,
you
could
help
us
process
as
working
group
chairs
or
document
authors
and
see,
you
may
have
been
notified
that
there's
one
filed
against
one
of
your
documents
I'll
be
starting
to
process
these
slowly
myself
as
much
as
I
can.
We
can't
rely
on
the
current
working
groups
to
worry
about
errata
from
working
groups
that
are
gone
or
documents
that
were
sponsored
by
ads
and
had
no
working
groups,
but
anybody
who
has
in
a
working
group
where
you
could
help
us
start
processing
some
of
these
on
your
own.
D
D
We
need
more
volunteers
to
do
the
work.
That
is,
that
is
the
work
of
the
area.
It's
not
always
working
group
chairs,
although
that's
the
common
thing
that
we're
asking
for.
But
you
know
if
you
want
to
be
involved
in
reviewing
requests
from
ayanna
registries
of
media
types,
is
the
big
favorite
one
ned
fried
is
no
longer
with
us.
He
was
the
champion
of
that
one
for
many
many
years,
there's
we're
down
to
two
people.
One
of
them
is
me
and
I'm
not
supposed
to
be
doing
them.
D
While
I'm
an
area
director,
so
it
would
be
great
to
have
additional
help
if
you're
interested
in
shepherding
documents
he
doesn't
have
to
working
group
chairs
are
not
the
only
people
allowed
to
shepherd
documents.
If
you
want
to
try
to
get
you
introduced
to
the
process.
That
way
talk
to
your
working
group,
chair
about
being
willing
to
shepherd
something
working
group
secretary
is
a
role
that
doesn't
always
appear
but
help
the
chairs,
by
recording
consensus
of
of
your
meetings,
keeping
track
of
issues
in
the
trackers.
D
That
sort
of
thing
please
volunteer
for
that
area,
review
teams
we
have
art,
art,
the
art
area,
review
team
could
use
more
people
and,
of
course,
working
group
chairs.
If
you're
interested
in
learning
more
about
the
mechanics
of
how
the
work
gets
done
here,
you
want
to
be
more
involved
in
it.
Talk
to
your
working
group
chairs,
talk
to
me,
talk
to
any
experienced
ietf
or,
and
we
can.
D
D
I
looked
to
see
if
I
could
see
credit
one
person
with
having
done
way
more
than
everybody
else,
but
it
is
a
pretty
fairly
even
distribution.
Everybody's
done,
maybe
three
to
four
this
year.
Thank
you
to
those
people
who
provide
that
service.
It
is
very
helpful
to
us
at
during
document
reviews
to
have
an
extra
perspective
and
if
you're
interested
in
participating
in
this
barry
is
here
and
he's
the
current
coordinator
of
art,
art,
and
he
would
love
to
talk
to
you
and.
G
AA
M
M
Art
thing.
What
I
try
to
do
is
do
a
little.
I
look
at
the
documents
quickly
first
and
assign
only
ones
that
that
look
like
they
would
benefit,
particularly
from
an
art
area
review,
so
unlike
security
directorate,
for
instance,
that
tries
to
review
every
document
going
through.
There
are
a
lot
of
documents
that,
in
in
internet
area,
routing
area
in
with
yang
models
and
stuff
like
that
that
I
decide
we
don't
really
need
an
art
review
of.
M
D
And
last
slide,
I
think,
is
just
to
catch
up
on.
We
have
folded.
The
internet.
Excuse
me
the
internationalization
directorate
into
the
art
area
that
was
announced
about
10
days
ago.
I
think
the
current
reviews,
the
i18
ender,
used
to
conduct
internationalization
framework
reviews
for
documents
that
need
them,
eai,
unicode
and
so
forth.
The
current
chair
of
the
18
i18n
directorate
needs
to
move
on
to
other
duties,
so
we
have
folded
them
in
that
has
happened
just
in
case
anyone
missed
the
announcement.
D
There
is
a
breakfast
for
the
art
art
team,
which
now
includes
both
organizations
wednesday
morning,
it's
in
the
agenda.
If
you
haven't
seen
that
we'll
try
to
get
some
remote
participation,
because
I
think
actually
almost
none
of
the
internationalization
people
could
make
it
this
time,
but
we'll
at
least
set
up
a
laptop
in
the
corner
or
something
like
that,
so
that
they
can
say
hello
and
participate
in
any
conversation,
any
questions
for
for
your
solo
ad.
This
time
I
could
do
an
open
mic
before
the
plenary.
A
G
I
The
problem
we're
facing
is
that
you
know
ietf
has
been
working
for
decades
on
interoperability
for
voice
and
video
communication
between
different
providers.
This
has
been
pretty
successful
in
some
areas
but
has
totally
failed
when
it
comes
to
app
to
app
interoperability,
meaning
like
can
you
make
a
video
call
between,
say,
skype
and
facetime?
You
cannot.
Can
you
send
messaging
from
wire
to
signal?
No
right?
No
can't
do
that.
What's
app
to
webex
call,
no!
No!
I
That's
poking
at
different
things
that
need
to
happen
to
provide
a
modern
solution
for
voice,
video
and
messaging
interoperability
between,
say,
you
know,
facetime
and
a
skype
or
whatever.
So
that's
the
topic
of
the
spin
draft.
There
seems
to
be
quite
a
bit
of
interest
on
the
list.
We're
obviously
not
going
to
discuss
that
here
in
dispatch,
but
there
is
a
buff
called
mimi,
it's
a
side
meeting,
which
is
you
know,
a
buff
with
a
lesser
room.
I
don't
know,
but
it's
a
side
meeting
today.
What
time
was
it
ron?
I
4
4
p.m,
today,
in
which
room
sorry,
philadelphia,
south
so
downstairs
mezzanine
level.
So
if
you're
interested
in
this
topic,
we'll
have
this
buff
rowan
set
it
up,
we're
going
to
try
and
largely
frame
up
a
buff
for
next
ietf
or
engage
interest,
and
I'm
particularly
interested
the
hard
part
of
this
is
getting
the
big
players
to
adopt
it.
So
if
anyone's
here
from
google's
or
apples
or
primarily
the
ones
that
need
to
be
interested
in
this
thing
to
make
it
successful.
I'm
super
interested
to
talk
to
you.
Please
come
to
that
buff!
I
I
I
A
Thank
you
very
much
for
sharing
that
and
yeah.
That
was
just
what
I
was
going
to
ask
if
there's
remote
participation,
webex
details
have
been
sent
earlier
today
on
those
lists
and
in
those
places.
So
thank
you
very
much
for
bringing
that
and
we'll
give
you
now
11
minutes
back
of
your
of
your
time,
thanks
so
much
for
coming
to
dispatch,
as
always,
thanks
for
your
energy
and
opinions
in
the
room
on
the
mailing
list
and
from
virtual
participants
as
well.
So
thanks,
everyone
have
a
nice
evening
night
day
morning,
wherever
you
are.