►
From YouTube: IETF94-XRBLOCK-20151105-1740.webm
Description
XRBLOCK meeting session at IETF94
2015/11/05 1740
B
B
B
We
have
in
submitted
to
the
ASG
yesterday
the
video
LC
internet-draft
and
by
the
way
Alyssa's
the
reason
05
discovered
overnight,
that
we
have
a
bug
and
Rachel
correct
if
it's
already
so
take
a
05,
please
hmmm!
No,
no!
It's
it's
the
same
Erica
mistakes
that
actually
show
up
in
one
of
the
otter
discussions
actually
has
been
copied
into
yeah
yeah.
A
D
B
A
B
A
C
Oh
this
is
this
is
brought
up
at
the
last
meeting
and
it
was
discussed.
We
found
out
the
data
that
had
posted
was
yes,
I'm
needin
it
added
to
my
Radha,
because
I
propose
to
fix,
and
the
problem
was
that
the
text
read
16
and
the
pits
were
12,
so
I
didn't
know
which
way
people
wanted
to
go,
and
so
I
posted
in
Nevada,
and
it
turned
out
that
people
wanted
to
stay
at
12
and
actually
change
the
text.
So
so,
basically,
they
radda
needs
to
be
updated.
However,
I
have
no
way
of
doing
that.
B
C
I
can
send,
I
think
there
was
discussion
on
the
list
which
said
that
the
proposal
was
wrong
and
and
that
the
text
below
should
be
upgraded
and
not
the
the
packet
format.
Well,
I
had
my
proposal
or
my
fix
when
I
saw
it
was
to
make
it
consistent
with
with
the
text,
make
the
packet
format
consistent
with
the
text.
Okay,.
E
So
why
don't
I
reject
this?
The
one
the
one
that's
in
there
and
you
file
a
new
one:
okay,
okay
and
then
I'm
sorry
that
I,
don't
remember
what
the
decision
was
last
time,
oh
and
then,
who
were
holding
all
of
these
for
document,
update,
yeah,
yeah,
okay,
yeah.
B
A
A
C
Another
side
three
so
slightly
is
a
recently
granted
rse
and
unfortunately
I'm
the
quarter
of
this
one
and
while
going
through
the
document
after
was
submitted,
I
noticed
that
we
had
a
block
length
said
24,
whereas
it
should
be
three
and
yeah
so
I
think
Cathy.
That
does
that
and
we
just
hold
it
up
for.
C
A
F
Mean
if
somebody
actually
sent
with
the
wrong
length,
things
would
go
completely
to
hell
right,
I
mean
it
would
not
parse
as
your
generic
XR
black
parser
would
not,
but
would
fall
off
the
end
for
the
next
block
and
bad
things
would
happen
so
right,
maybe
that's
actually
confirmed
I
mean
just
it
does
it
say
the
right
length
somewhere
else.
No.
A
F
A
A
A
A
A
That
would
be
the
quickest
uh-huh
I.
Don't
use
worth
it
because
you'll
probably
write
a
generic
exile
block
passer
and
the
rules
are
the
same
for
all
these
blocks,
and
this
is
just
a
typo
in
the
draft
and
I
think
if
you're
at
the
jarek
parts
are
following
the
guidelines,
you
will
spot
this
probably
immediately.
So
we
need
to
log
that
there's
a
bug
in
the
hair,
but
everything
we
need
to
rest
yeah.
C
D
Gonna
have
to
chip
in
on
this
will
Rick
China
coming
in
from
completely
different
group?
The
question
really
comes
down
to
is:
is
that
descriptive?
Is
that
example
block
you've
got
there?
Is
that
the
canonical
description
of
that
or
is
the
block
length
defined
canonically
elsewhere?
It's
defined
canonically
elsewhere,
in
which
case
I
would
say
that
was
a
typographic
editorial
issue,
not
a
technical
issue,
because
your
example
is
wrong,
but
the
fundamentals
are
defined
canonically
elsewhere,
yeah.
C
D
A
C
Yeah,
we
could
have
done
it
the
way
that
never
say
what
block
length
is
and
let
everyone
just
because
this
seems
to
be
like
an
error
that
happens
because
you
miscounted
and
yeah,
and
the
thing
is
that
the
value
zero
is
valid
and
that's
why
the
miscounting
happens
because
actually
counting
the
first.
Yes.
A
C
C
Do
we
need
to
make
abyss
draft
for
this
one,
okay,
yeah,
so,
based
on
the
last
IETF,
you
notice
that
the
the
RFC
7003
had
a
different
limitation,
that
the
block
could
only
be
sent
with
RFC,
69,
58
and
and
since
the
two
rfcs
came
out,
which
was
a
few
years
ago,
we
noticed
that
and
the
assumption
was
that
first
loss
and
burst
discards
happen
are
correlated
and
since
then
we
realized
that
they're
not
necessarily
correlated,
and
therefore
you
should
be
able
to
actually
express
this.
These
metrics
independently.
C
A
C
Some
additions
here
so
so
the
red
one
is
actually
copied
from
the
first
loss
draft
and
also
the
the
number
of
us,
except
in
in
the
first
loss.
The
number
of
purse
is
12
bits,
and
here
I
was
thinking
of
keeping
it
16
so
that
we
can
have
a
32-bit
boundary.
The
only
thing
is
that
it
do
people
care
enough
to
have
this
parser
and
have
bits
in
the
right
place
with
exactly
the
same
thing,
except
instead
of
loss.
B
C
A
C
Time
I
did
count
correctly
now
it
triggered
a
lot
of
reviews
for
me
yeah.
So
so,
if
you
add
this
card
count
and
I
think
that
argument
cannot
be
made
and
the
reason
to
add
this
card
count
is
that
there's
another
XR
block
which
has
this
card
account,
but
if
you
want
to
send
an
independently
independen
XR
block,
which
has
a
bunch
of
information
which
is
not
there
in
the
previous
one,
then
then
you're
already
aggregating
information
and
then
adding
a
bunch
of
information.
Instead
of
sending
two
or
3a
XR
blocks
them.
C
A
A
F
B
C
B
Okay,
so
we
leave
one
week
for
confirmation
on
the
working
group.
Please
you
submit
and
then
submit
as
a
draft
I
tfx
our
block
and
we
go
to
last
call.
Okay,
sorry
and
I'll
do
a
milestone.
Yes,
please
write
this
milestone
on
see
in
the
was
a
charter
here,
the
mass
of
the
chapter,
that's
for
the
chairs.
A
C
B
C
Fixing
all
these
other
references
that
we
needed
to
get
done,
I
think
the
RFC
750,
nine
and
and
this
new
one
that
I
just
put
forth.
But
meanwhile
there's
been
a
lot
of
discussion
at
the
the
web
RTC
working
group
at
in
w3c
about
how
they're
going
to
handle
a
new
identifier,
so
statistics,
because
there
might
be
a
different
stos
that
come
up
with
statistics
and
so
initially
for
last
few
years.
The
plan
was
to
do
an
eye
on
our
registry.
C
But
since
month
ago
there
was
a
decision
made
in
in
the
working
group
there
that
they
would
just
keep
the
document,
but
like
people
can
send
recommendations
for
new
metrics
and
if
they
feel
they're
useful,
they
would
they
would
incorporate
it
and
if
they
do
not,
there
should
be
sufficient
text
in
in
the
web.
Rtc
statistics
API
document
in
w3c
on
how
how
this,
how
identifiers
defined
in
other
stos
can
be
incorporated
so
right
now.
This
is
not
that
that
text
does
not
exist.
C
So
without
that
information
I
think
we
should
just
go
ahead
with
the
the
INR
registry
that
we
have
in
this
document.
That's
populated
in
this
document
so
that
all
future
ex
our
block,
things
that
want
to
like
contribute
to
the
web
RTC
statistics,
AP
I,
could
be
documented
in
one
place
in
then
we
could
send
a
pointer
to
that
registry
to
to
w3c
and
they
can
decide
what
would
be
the
next
step
for
them.
The
only
thing
I
can
think
of
in
that
sense
is
that
we
could
say
that
please
do
not.
C
There
have
been
many
proposals
to
this
and
I
think
that
is
one
of
the
possible
outcomes,
but
currently
there
is
a
w3c
document.
So
definitely,
while
that
document
exists,
contributions
can
be
made
to
that
document
directly
in
the
form
of
making
a
proposal
and
sending
it
there
and
and
it's
up
to
them
to
decide
if
they
want
to
incur
incorporate
the
identifiers
defined
in
another
standards
organization
into
into
that
document.
But
there
is
currently
not
enough,
like
process
documented
on
how
the
skin,
how
this
is
going
to
happen
in
in
practice.
C
The
w3
sir
yeah
yeah
w3c
document
has
at
least
that
it
seems
the
the
trend
is
that
they
would
snap
shot
it
at
some
point
and
say
this
is
web
RTC
statistics
for
version
1
and,
and
that
would
be
the
document
and
if
they're
their
new
metrics
that
are
needed,
then
there
would
be
version
1.1
or
version
2
or
version
next
version
or
and
then
the
document
would
come
back.
Okay,.
B
A
C
E
This
is
like
a
pretty
crummy
situation.
You
didn't
like
it's,
it's
really
suboptimal
to
have
these
defined
here
and
then
we
like
throw
them
over
the
wall
and
say
well,
whatever
you
decide
to
do
with
your
process
like
your
these,
like
please,
don't
squat
on
them
like
that,
that's
like
why
we
have
registries
I'm,
just
venting
about
the
decision
that
they
made
essentially
but
right.
C
B
A
E
The
XR
block-
well,
okay,
so
now
I'm
like
complete
speaking
out
of
turn,
because
not
really
my
job
to
do
this,
but
I
would
just
put
the
idea
out
there
if
the
X,
our
block
warden
group-
cares
about
this
enough
then,
and
it's
worried
about
it
getting
screwed
up.
Then
the
working
group
could
think
about
writing
a
liaison
statement
to
web
RTC.
C
B
A
A
C
I
the
feedback
was
just
last
week
and
we
had
this
discussion
and
the
like
the
case
that
I
made
for
for
actually
going
with
an
eye
on
our
registry
for
for
the
metrics
was
mainly
that
they're
like
for
the
constraints,
is
never
been
such
registry,
and
there
has
never
been
an
inclination
for
that.
However,
metrics
have
been
well
defined
across
the
board,
not
only
in
the
IETF
but
in
I
duty
and
several
other
places.
So
there
were.
C
D
Rick
Taylor
again,
I'm
I'm
I'm
here,
because
I'm
interested
in
metrics
coming
across
from
mobile
ad
hoc
environment
and
it's
not
really
RTC,
it's
just
metrics
in
general,
and
that's
got
to
be
a
registry
somewhere
and
if
there's
an
hour,
UTF
draft
which
defines
how
to
use
these
metrics,
then
a
corresponding
iono
registry
strikes.
Me
is
the
best
place
to
do
it.
D
So
surely
you
request
a
registry
in
the
bottom
of
your
draft
that
is
adopted
by
working
group
go
through
to
last
call
and
the
it
gets
picked
up
part
as
it
moves
through
the
iesg
and
through
the
IAB
and
so
yeah
that
that's
not
my
issue,
but
I
would
really
like
you
to
adopt
it
as
part
of
the
IETF
process,
because
that
means
I
can
start
to
use
some
of
these
metrics
downstream
from
other
areas.
Yeah
I,
eventually
routing
I,.
B
I
believe,
if
I
also
personally
like
this
past
better
and
probably
the
way
to
go,
is
actually
we
do
this
registry.
We
are
starting
from
as
a
set
taking
a
step
for
what
do
you
give
right
now
we
suggest
that
we
coordinate
and
whenever
you
update
the
you
update
as
a
weekly
page
or
whatever
process
you
are
using
in
order
to
work
at
the
new
matrix,
you
inform
the
working
group
or
we
need
to
provide
analysis.
Maybe
the
art
area
or
something
x
is
about
this
taking
place.
C
E
A
C
E
Yeah
so
I
think
to
your
earlier
question:
Dan
there's!
You
should
continue
to
progress.
This
draft
like
there's,
no
reason
not
to
do
everything
that
you
would
normally
do,
but
like
the
debbie
through
sees
our
friend
and
you
don't
want
to
like,
there
wasn't
a
reason
to
try
and
help
them
to
come
to
what
this
group
thinks
is
the
right
decision,
even
before
that
draft
becomes
an
RFC.
So
that's
why
I
think,
okay.
B
C
D
Rick
Taylor
again,
and
normally
when
setting
up
an
eye
on
a
registry,
you
have
to
specify
the
expert
review
process
and
other
considerations
is
granted
for
the
iono
and
there's
nothing
to
stop
you
putting
a
statement
in
there
to
say
this
is
being
paralleled
with
w3c.
They
need
to
be
kept
in
the
loop
and
follow
whatever
process
you
guys
in
the
w3c
think
works.
Well.
You
can
always
put
those
considerations
in
there.
B
B
C
An
I
don't
think
a
wiki
pages
is
codified
enough
to
actually
say
that
an
eye
on
our
registry
can
have
a
reference
to
wiki
page
I.
Don't
think
that
that's
sensible
because,
like
someone,
can
change
a
wiki
to
like
to
whatever
reason
as
and
you
have
a
metric,
it
could
be
redefined
every
day
of
the
week
right
and
like.
E
E
C
C
B
B
B
A
C
C
B
B
A
E
C
C
Like
yeah
but
I
here,
the
WTC
is
that
we
don't.