►
From YouTube: IETF93-XRBLOCK-20150721-1740
Description
XRBLOCK meeting session at IETF93
2015/07/21 1740
A
Papas
everywhere,
but
where
you
empty
entities
is
such
a
huge
entity
with,
like
so
many
different
subsidiaries,
so
just
because
he
sends
it
is
something
you
know
like
this.
The
thick
side
is
like
mobile
side.
They
all
operate
different
happen.
I
can
read
this
man
Kiki
data
that
does
like
system
integration
good
and
there
is
like
cement,
ed
soft
that
sells
the
second
software
resellers.
B
A
Start
all
right,
I
think
we'll
be
done
before
the
second
spoon.
Okay!
Well,
we'll
try
to
yeah
alright.
So
this
is
x.
El
bloque
working
group
I'm
familiar
face,
I'm
assuming
everybody
CF
with
extra
block,
no
well
statement
that
runs
off
I,
etfs
I'm
sure.
If
it
is
read
that
no
well
statement,
if
you
haven't,
please
read
it
blue
sheets
and
I-
think
we
have
at
least
one
note
taker,
Ronnie
and
I.
A
A
Ecos
least
I'm
going
to
be
here
for
the
Barons
presentation,
slides,
we're
gonna,
move
Rachel's
before
veterans
and
hope
that
at
least
it
would
be
here
before
were
in
status,
slides,
so
agenda
bashing.
Anyone
wants
to
watch
the
agenda,
no,
all
right.
Okay,
we
didn't
meet
like
at
the
last
idea,
but
we
have
published
one
IFC
and
we
have
two
walking
drops
I
know
and
nothing
else
in
the
queue.
So
if
you
finish
these
two,
then
we
had
an
yeah.
Well,
just
go
to
sleep,
go
to
see
all
right,
so
Rachel.
A
A
E
Alright,
okay,
okay,
this
this
topic:
it's
about
rtcp,
XL,
Brock
for
lost
calcium
on
the
metrics
problem
on
video
applications.
Next,
please,
let's
have
a
recap
of
this
document,
and
this
document
I
was
adopt
as
a
working
corporate
look
working
group
chat.
It's
just
before
the
last
ITF
meeting
I
believe
it's
it's
in
January
yeah
yeah.
E
E
B
E
Yeah,
okay.
Next,
this
is
the
overview
of
the
report
block
yeah.
We
can
see
here
we
basically
now
we
have
six
magic
tricks.
The
first
one
is
impaired
duration,
which
is
a
total
time,
landed
a
video
impaired
by
transmission
loss
before
applying
any
loss,
consumable
methods,
and
it
it
is.
The
experts
expect
in
units
of
our
dividend
stems
and
we'll
also
have
a
consideration,
which
is
a
total
time.
Lance
of
concealed
damaged
video
pictures
on
which
loss,
concealment,
method
corresponding
to
B
is
applied
here.
E
E
E
Fractions
matrix,
M
ipf,
which
is
a
mean
impaired
frame
of
proportion,
indicates
the
mean
proportion
of
each
video
frame
impaired
by
loss
before
applying
any
last
consumer
method
and
AMC
FP
means
me
conceal.
The
frame
proportion
indicates
a
min
fraction
of
each
video
frame
to
which
plus
concealment
was
applied,
and
also
we
have
ffs
see,
which
is
shot
name
a
fraction
of
reims
subject
to
consume
and
indicates
a
proportion
of
two
frames.
Two
which
lost
concealment
was
applied.
E
E
E
D
G
F
G
Don't
say:
I
I
just
looks
at
the
diff,
so
I
haven't
read
it
very
carefully
that
the
changes
looked
fine,
it
seemed
I,
think
I
think
it
lost
over
ranges
indicator
in
the
field,
which
should
possibly
be
added
back
for
a
number
right.
Yeah.
It's
been
basically
fine
for
a
while,
so
yeah
it
just
needs
careful
proofreading.
Then
it's
probably
ready
to
go.
F
F
F
F
F
B
So
this
draft
has
just
one
open
issue
that
came
up
while
I
was
editing
it
in
March
when
I
realized
that
so
the
draft
make
some
recommendations
and
then
makes
a
list
of
ident.
Then
this
is
a
bunch
of
identifies
and
these
bunch
of
identifiers
it
inherits
from
the
existing
RFC's
or
drafts
that
are
already
approved.
So
so,
with
the
section
six,
there
are
two
recommendations.
B
B
We
had
this
discussion
on
the
mailing
list
back
in
March
there's
some
opinions
expressed
that
6.7
should
be
preferred
over
6.8,
and
my
only
thing
was
that,
since
the
data
in
6.8
cannot
be
derived
from
six
point
seven,
so
maybe
we
could
live
with
both,
because
these
things
are
just
recommendations
and
it's
up
to
the
community
or
the
implementers
to
choose
either
of
six
point,
seven
or
six
point.
Eight
and
I
think
both
are
rich
enough.
B
B
B
F
B
I
think
that
was
running
in
there
were
a
couple
of
others
who
looked
at
it
and
said
which
ones
they
prefer,
but
there
were
only
four
emails
in
that
thing.
So,
on
the
other
hand,
since
it's
a
recommendation,
then
we
not
saying
must
do
this.
I
I
don't
feel
strongly
if
we
should
run
the
side
of
caution
or
I
think
we
can
have
both
ism
they're,
not
terribly
long
list
of
if
people
find
it
useful,
they'll
implement
them
know.
B
B
So
I'll
keep
it
as
it
is,
then
the
next
slide.
So
while
I
was
doing
this,
I
found
a
bunch
of
things
because
when
I
was
trying
to
derive
these
metrics,
I
found
that
so
I
made
an
errata
just
today,
because
I
noticed
that
the
number
of
bus
were
like
supposed
to
be
16
base,
but
on
the
packet
from
it's
12
and
so
I,
I
reported
this
I,
don't
know
what's
the
next
step,
but
since
it's
reported
I
guess
people
will
do
what's
needed
to
what
I
was
needed
right.
H
B
B
G
F
B
F
B
B
Just
respond
to
that
email
asking
right
way:
yeah.
Okay,
no
next
slide,
so
this
was
triggered
so
before
that
I
had
the
RFC
7003,
which
had
this
thing
that
there
was
no
bust
count.
So
that's
how
I
started
looking
for
burst
count
and
I
found
that
the
Assumption
RFC
7003
makes
is
that
discards
and
losses
will
be
reported
together.
So
the
burst
count
are
only
in
one
place
and
both
reports
don't
have
a
separate
westconn.
B
So
Sam
I
presume
the
assumption
at
that
point,
when
the
RFC
7003
was
written,
that
the
they
assume
that
the
discards
and
the
losses
were
correlated.
So
they
could
report
report
them
as
one
report
or
as
to
reports
simultaneously,
but
I
believe
this
is
not
true
anymore,
because
you
can
have
discards
and
you
can
have
uncorrelated
losses
somewhere
else.
B
So
so
you
would
need
them
to
be
separate,
and
if
you
need
them
to
be
separate,
then
I
cannot
use
the
metric
because
me
it's
not
as
not
got
this
first
count
for
discards
so,
and
that
was
needed
for
this
6.7
in
in
the
in
the
draft
that
I'm
proposing.
So
so,
I'm,
not
sure.
If
this
is
in
a
rat
or
if
it's
a
new
draft,
because
I
believe
there
was
no
technical
mistake
made
in
seven
seven
thousand
three,
so
I
think
this
is
just
an
assumption
that
was
made
and
the
optimization
was
applied.
A
A
H
This
is
Ben
again
and
I'm
going
on
a
limb
here,
because
I
really
like
alyssa
to
alyssa
somewhat.
He
needs
to
make
an
authoritative
statement
here,
but
in
general
and
arata
is
for
fixing
mistakes
so
where
the
document
doesn't
reflect
what
the
consensus
was
at
the
time,
whether
its
editorial
or
technical
or
whatever,
it's
not
for
changing
our
minds
later
right,
so
I
would
personally
argue
and
again
sometimes
we
don't
follow
the
rules,
because
we
want
to
do
what's
quickest
and
easiest,
and
so
that's
doesn't
mean
you
can't
do
in
a
router
for
this.
B
And
when
I
went
back
and
read
the
rules
of
the
Iraq
I
was
not
sure
if,
because
we
don't
want
to
so
there
is
a
code
point
assigned
to
this,
and
this
metric
is
valid
for
the
assumptions
that
they
made
so
I
I
think
you
can
have
a
different
report
which
says
that,
which
is
that,
if
you
have
uncorrelated
discards,
then
you
use
this
one
and
older
one
is
for
correlated
discards
with
less
yeah,
so
go
to
the
next
slide.
I
think
please.
B
So
so
the
old
one
was
already
given
21
there's
already
any
rot
on
that
one,
because
I
think
the
draft
says
20
and
I
think
the
is
already
in
a
right
other.
It
should
be
21.
So
but
it's
missing
a
bunch
of
information
and
my
new
proposal,
if
you
want
to
do
this
correctly,
would
be
to
like
after
some
of
these
asians,
then
we
can
you
be
light.