►
From YouTube: IETF94-AVTCORE-20151103-1300.webm
Description
AVTCORE meeting session at IETF94
2015/11/03 1300
B
C
C
C
C
Okay,
thank
you
both
so
document
status.
Rfc
is
published.
None.
However,
the
typologies
update
is
in
or
thurs
48,
it's
approved
by
all
authors
and
I'd,
so
we
are
waiting
for
our
FC
to
pop
up,
but
I
haven't
seen
it
yet,
but
it
should
be
any
day
soon.
The
star
said
if
it
gets
to
put
into
publication
so
nes
dsm,
I'm
sharing
that
it's
been
stuck
on
the
non
responsive
authors
there.
C
C
D
D
Still,
the
arias
OTP,
the
the
arias
RTP
I
will
I,
don't
know
what
what
is
the
process
here,
because
they
just
took
out
it's
a
previous
document
without
the
Estes
inside.
Otherwise
it's
the
same
document
and
it
was
at
the
isg
at
the
time.
So
the
question
I
mean
I.
Think
for
the
area
director
about
what
I
mean.
Should
we
do
again,
ITF
last
call
and
finish
that.
D
D
C
A
C
C
We
have
to
I'd
ever
working
of
documents
that
hasn't
it's
not
an
agenda,
and
otherwise
it's
not
specifically
this
kind
of
stare.
It's
the
multiplexing
scheme
up
this
press
f
to
pay
extensions
for
dtls.
There's
been
some
discussion
on
the
draft
and
and
I
yeah.
Let's
continue
working
on
resolving
those
issues
and
getting
updates
so
multiple
for
TP
and
what
you
want
to
save
our
own.
C
E
We
presented
an
update,
the
last
IDF
we're
working
through
the
updates,
and
we
now
have.
The
only
announcement
I
want
to
make
is
that
we
have
an
open
source
working
version
of
this
with
open
web
RTC,
and
hopefully,
I
was
hoping
to
do
a
demo
this
weekend,
I'm
still
hoping
that
I
could
show
some
people
listen
I,
think
next
time,
we'll
present
it
with
the
links
to
all
the
open
source
stuff
and-
and
we
can
progress
the
document.
So
I
guess.
E
Yeah
and
we
also
got
dtls
working
because
when
we
had
to
get
this
thing
working
with
open
web
RTC,
we
had
to
like
figure
out
how
that
mapping
de
goes.
So
we
got
that
working
and
I
think
we
would
put
that
either
in
this
craft.
Work
like
at
least
discuss
it
on
the
mailing
list
and
see
yeah
like
how
we
want
to
prove
yeah.
C
C
Yes,
oh
yeah,
we
have
two
expired
working
document
said
true,
so
the
multiplexing
guidelines
I'm
one
of
the
authors
we
met
yesterday
and
drew
out
the
plan
for
updating
raft
and
to
the
goal
here
is
to
no
later
than
bonus.
Iris
meeting
have
an
updated
draft
which
will
reduce
the
length
and
be
focusing
much
more
on
the
scope
of
m
dot,
useful
document
by
an
RTP
application
designer
for
considering
how
to
use
RTP
multiplexing.
So
when
you
have
multiple
streams
are
not
set
one
or
more
sessions.
Those
kind
of
question
so.
C
They
are
all
kind
of
past,
so
we
need
to
update
the
ones
which
aren't
done
or
very
close
to
finishing,
so
we
will
initiate
it.
Sheriff
initiate
you
round
up
asking
others
when
they
feel
think
they
really
complete
them,
etc
and
then
will
present
some
proposed.
You
milestone
dates
to
working
group
on
the
mailing
list,
so
so
authors,
if
you
already
now,
have
some
idea
on
when
would
be
a
suitable
milestone.
You
can
send
it
to
us
any
questions
on
the
stages
of
the
working
group.
F
So
the
the
the
two
main
areas
where
the
were
the
issues
with
this
draft
were
regarding
the
media
timeout
circuit
breaker
and
regarding
the
ginger,
the
congestion
circuit
breaker
and
these
weren't
fundamental
issues
with
the
mechanisms
they
all
sort
of
details
and
corner
cases
where
it
turned
out
that
the
simple
proposals
we
had
in
the
previous
version
of
the
draft
didn't
quite
work.
If
you
configured
a
tea
at
ccp
in
a
slightly
odd
set
of
not
so
much
an
odds-on
way,
but
but
in
a
sapper
hab
slightly
unusual
way
and
hit
some
corner
cases.
F
So
the
the
first
of
these
was
the
the
media
timeout
circuit
breaker.
Now
the
the
media
timeout
circuit
breaker
is
when
you're
sending
media
to
to
a
receiver
and
your
you're
wanting
to
check
that
the
media
is
actually
getting
there.
So
you're
sending
RTP
packets
and
you're
waiting
for
a
TCP
sender
reports
receive
a
report
packets
to
come
back
when
those
packets
come
back.
F
What's
the
media
timeout
interval,
so
what
was
in
the
previous
version
of
the
draft
was
that
you
should
wait
for
the
minimum
of
floor
of
three
plus
two
and
a
half
/
TD,
where
TD
is
the
TCB
reporting
interval
and
thirty
rtcp
reporting
intervals
before
giving
up
now
in
practice.
What
what
that
results
in
it
is
what's
shown
in
the
table
there,
where,
if
you're
a
reporting
interval
TD
is
five
seconds.
That
means
you
end
up.
Waiting
for
free
are
TCP
packets
to
come
back
before
giving
up.
F
F
If
the
reporting
interval
became
less
than
the
round-trip
time
lower
cases
way
where
you
would
start
getting
reports
back
before
your
data
had
time
to
get
to
the
receiver,
then
you
may
time
out
in
some
perhaps
unusual
cases,
but
you
may
time
out
if
your
reporting
interval
is
very
small
compared
to
their
own
tricks
I
before
the
data
actually
had
time
to
arrive,
and
this
didn't
strike
seem
very
common,
but
they
were
certainly
possible.
It's
something
we
should
address.
F
What's
in.
The
new
version
of
the
draft
is
that
the
reporting
interval-
sorry,
is
that
the
media
timeout
interval
is
now
you
take
the
maximum
of
the
rtcp
reporting
interval,
the
round-trip
time
and
the
media
framing
interval
a
that,
the
approximate
time
between
packets
you're
sending
you
take
the
maximum
of
those,
and
you
take
five
times
that,
and
you
divide
that
by
reporting
it
now.
What
that
gives
you
in
the
usual
case
where
the
rtcp
reporting
is
always
large
compared
to
inter
packet
time
and
the
round-trip
time.
F
F
So,
for
example,
if
you're
a
TCP
reporting
interval
is
half
a
second
and
you're
sending
media
packets
once
per
second,
rather
than
timing
out
after
five
a
TCP
reports
going
back
you
timeout
after
10
coming
back
because
each
you,
the
intervals
are
such
lead,
expect
every
second
report
to
have
to
show
show
packets
received.
So
we
scale
things
up
to
compensate.
F
F
F
F
You
estimate
the
rate
of
TCP
connection
would
achieve
over
the
same
path
based
on
the
rtcp
reports
that
are
coming
back,
and
if
you
compare
that
estimates
to
the
rate
at
which
are
sending
and
if
you're
sending
it
more
than
10
times
the
gcp
estimate,
you
either
cease
transmission.
Oh
you
reduce
your
rate
x
factor
attack,
so
the
issues
here
are,
then
what
should
be
the
minimum
rate
at
which
this
kicks
in
and
what
should
be
the
measurement
interval
over
which
you're
comparing
with
TCP?
F
So
what
was
in
the
previous
version
of
the
draft
was
that
the
minimum
rate
was
one
packet
per
round
trip
time
and
that
the
measurement
interval
was
that
expression
up
there,
which
is
the
same
as
the
one
used
for
the
media
type.
That's
the
problem
with
that
was
that
there
were
cases
where
the
rtcp
interval
was
more
than
the
round-trip
time,
where
the
minimum
rate
of
one
packet
per
round
trip
time
could
allow
quite
a
lot
of
data
to
be
sent
without
getting
any
feedback
and
for
small
round
trip
times.
F
F
What's
in
the
new
draft
is
that
the
minimum
rate
is
the
maximum
of
your
one
packet
/,
a
maximum
of
your
a
TCP
reporting
interval
and
your
round
trip
time,
whichever
one
is
is
biggest
so
in
the
in
the
case
where
the
I
tcp
/
interval
is
more
than
the
round-trip
time,
which
is
the
typical
one.
If
you're
sending
more
than
one
packet
/
report,
you
need
to
start
using
the
circuit,
breaker,
otherwise
a
limited
to
one
packet
per
round
trip
time,
which
is
the
minimum
rate.
Tcp
concern
that
UDP
guideline
straps
and
so
on.
F
You
know
the
round-trip
time
once
you've
got
an
rtcp
report
and
if
you
haven't
gotten
a
tcp
report,
while
we're
in
the
one
of
the
other
circuit
breakers
is
going
to
trigger.
So
it
doesn't
matter
at
that
point.
Yeah
and
yet
you'd
have
to
do
a
conservative
estimate,
but
you'd
be
in
the
stage
where
the
TCP
timeout
breaker
would
be
triggering
yeah.
Picking
a
conservative
estimate
would
be
fine
as
well
the
measurement
interval
we
have
what
what
looks
like
a
complicated
expression
is
actually
too
bad.
F
F
You
go
at
least
10
cops,
ten
round
trip
times
and
free
rtcp
reporting
intervals
at
which
you
can
adapt,
all
of
which
is
kept
the
expression
on
the
right
at
a
minimum
of
15
seconds.
So
you
have
at
least
15
at
a
maximum
of
15
seconds.
So
if
your
congestion
controller
isn't
doing
anything
sensible
over
a
period
of
10
frames
or
groups
of
frames,
10
round
trip
times
and
Free
rtcp
reporting
intervals
coming
back,
whichever
of
those
is
the
largest
and
you're
still
going
ten
times
faster
than
TCP,
would
then
you
should
cease
transmission.
F
So
that's
the
status,
the
draft
that
the
draft
has
changed
fairly
significantly
thur
the
new
proposals
are
reasonably
big
changes
on
the
others.
I
think
they
address
the
limitations
we
found
with
the
previous
version
of
the
algorithm.
I
also
think
the
draft
is
a--,
it's
better
specified
and
hopefully
easier
to
read
and
implement
than
the
previous
version
was.
F
F
My
understanding
is
that
he,
he
is
also
happy
with
them,
may
address
his
comments,
so
we're
what
we're
looking
to
do
is
go
for
a
long
working
group
last
call
to
give
people
time
to
play
with
these
and
see,
if
see
if
they
make
sense
it
implementations
and
to
do
some
more
simulations
and
so
on.
But
as
far
as
we
are
aware,
these
are
now
done.
G
F
It's
quite
a
lot
of
changes,
but
but
I
think
we
have
something
which
is
much
better
motivates
as
though
it
was
before
such
I
am
recently
confident
that
it
will
work.
Certainly
the
next
thing
I'm
planning
on
doing
is
putting
this
into
a
previous
set
of
simulations
and
rerunning
them
all
with
the
new
circuit.
Broken
saying
is
that
if
it
behaves
the
same,
I
just
didn't
have
time
to
do
that
before
the
meeting.
Ok,
if
you're.
G
F
That's
certainly
my
plan
and,
if
there's
anything
noticeably
weird
about
that,
but
obviously
I
will
come
back
and
say
here
what
we
found
problem
yeah.
If
people
are
able
to
implement
it
or
do
other
tests,
I
mean
that
would
clearly
be
a
good
thing
as
well.
The
main
point
yet
then
questions
I
think
at
this
point
is
of
how
quickly
do
you
want
to
move
forwards?
H
Michael
mala
cisco
systems
up
to
kiss
t'kul
question,
I'm
reading
the
document.
Now
I
obviously
haven't
read
it
really
thoroughly.
But
when
you
up
discuss
the
TCP
throughput
equation
is
the
P
and
stuff.
That's
in
that
equation
meant
to
be
the
same
exact
as
RFC
also
3448,
because
it
doesn't
seem
like
it
mandates
that
that
same
method
of
generating
p,
that
we
used
that.
H
H
So
my
question
joining
to
you
colonists
is,
if
you're
going
to
to
specify
an
equation
that
has
a
pee
in
there
that
you
order
that
there
should
be
some
text
in
there
to
say
how
you
calculate
P
and
if
you,
and
if
the
recommendation
is
actually
to
use
the
measured
p,
we've
got
documentation
that
that
isn't
the
best
one
to
use
I
just
bring
that
up.
I'm
pretty.
F
H
F
Necessarily,
we
have
to
use
it
because
this
has
to
work
with
unmodified
rtcp.
So
the
only
information
we
have
available
is
the
P
that
is
returned
in
rtcp.
The
draft
does
have
an
averaging
process
which
shows
how
you
calculate
P
for
the
congestion
circuit
breaker
in
it,
but
we
have
to
work
based
on
that
measurement
because
that's
all
it
is
available
and
the
goal
is
to
work
with
unmodified
rtcp
I.
F
A
H
Okay,
I'm,
just
I,
guess
I'm
worried
now
about
those
cases
where
that
equation,
because
of
the
way
that
you're
using
the
measured
data
would
result,
in
a
rate
that's
lower
than
the
one
that
you
are
to
be
running
at,
but
that's
I
haven't
read
the
draft
enough
and
I
am
commented.
Clearly,
I
have
not
commented
on
all
the
such
a
question
so.
F
That
there
is
an
averaging
process
in
which,
which
may
or
may
not
help
I,
don't
know
it
is
specified
in
detail
in
the
draft,
but
for
better
or
worse
we're
stuck
with
what's
reported
in
a
TCP
and
yet
I
agree.
If
we
could
change
the
metrics
that
were
coming
back,
we
could
do
something
better,
but
for
this
purpose,
as
we
can't
change,
okay.
H
F
That
this
is
certainly
not
you
know.
If
this
is
something
not
intended
to
be
the
only
circuit
breaker
ever
invented,
and
if
someone
yeah
it
comes
up
with
a
replacement
to
this
that
looks
at
RTC,
pxr
information,
for
example.
Then
I
think
that
would
be
a
good
thing
and
yeah.
You
could
probably
do
a
lot
better
than
this,
but
we.
H
C
F
Yes,
I
mean
if
a
future
version
of
RTC
web,
for
example,
wishes
to
say
we
have
mandated
extra
feedback
packets.
Therefore,
we
are
also
mandating
a
different
circuit,
breaker
and
I.
Think
that
would
be
a
reasonable
thing,
but
unless
you,
unless
you're
in
an
environment
where
extra
feedback
is
mandated,
you
can't
mandated
a
different
circuit,
breaker.
E
Why
don't
think,
but
just
commenting
on
the
fact
that
section
6
is
something
about
extended
reports.
It
does
say
that
there
may
be
some
and
we
should
use
them
if
they
I
think
it
says
some
text
about
it
says
if
ecn
summary
reports
exist
and
we
should
use
them,
but
I
don't
think
we
have
a
pointer
to
anything
that
has
the
the
specific
lost
metric.
That
Michael
was
alluding
to.
Therefore
we
cannot
actually
say
anything
about
earlier.
F
E
F
H
For
bringing
it
up,
I
haven't
used
your
method
of
calculating
the
P,
so
I
don't
know,
though
its
efficacy,
but
I
do
know
some
other
things
that
we've
tried
internally
at
times
will
generate
too
low
of
an
estimate
that
would
have
we
used
it.
Probably
kick
the
circuit
breaker
off,
but
I,
don't
know,
I
haven't
really
done
the
analysis,
but
I
do
know
that
the
other
ways
work
over
better
first
I
have.
H
H
It's
just
that
every
once
in
a
while,
you'll
get
a
bad
series
of
data,
and
it
will,
you
know,
wants
every
end
event
in
events
that
your
packet
rate
might
be
once
every
three
minutes
when
I
come
to
us
to
a
low
low
rate.
So
I
haven't
done
the
analysis
here,
so
I
feel
like
I'm,
yeah
I'm,
so
being
is
that
horse
on
what?
If.
F
It's
the
sort
of
thing
which
generates,
which
repeatedly
generates
values
which
are
out
by
a
factor
of
10
for
several
rtcp
reporting
intervals
in
a
row,
then
I
think
that's
something
that
we
need
to
be
concerned
about.
If
it
generates
things
which
are
you
know,
it's
only
one
in
a
hundred
or
it's
only
out
by
a
factor
of
two,
then
it
won't
make
slightest
bit
of
difference.
Yes,.
H
F
H
F
E
And
I
have
a
test
bed
that
we
could
spin
up
and
run
if
I
knew
like
what
the
corner
cases,
because
we've
been
looking
for
it
and
we've
not
found
anything
that
like
that
stands
out,
and
that
would
require-
and
some
of
the
fixes
that
we
have
here
are
because
of
that
right,
because
we
we
had
the
screen
sharing
and
those
options
where
you
had
really
low
frame
rates
and
we've
gone
back
and
fixed
it.
So
we
can
certainly
do
more
in
terms
of
if
we
would
find
these
honor
cases.
Yes,.
G
I'm
Jackson
yeah
I
was
going
to
say
like
yes,
it
was
that
was
our
findings
and
in
terms
of
like
the
p
value
calculation,
I
think
there.
I
think
google
chrome
condition
control.
They
use
a
TFR
sip-based
center
based
approach
right
now
and
they
use
this
p
value,
as
you
have
described
here.
So
it's
actually
a
live
system
using
it
and
I.
Nothing
like
it
would
have
been
a
huge
issue.
They
would
have
been
putting
in
a
life
system
so
and
I.
G
I
mean
you
don't
have
more
than
this
information,
so
I
don't
think
like
I
think
this
is
more
common
sense
like
you
use
what
you
need,
but
I
mean
this
will
come
pop
up.
If
somebody
comes
up
with
the
draft
or
some
better
idea
in
calculating
p
values
for
an
RTP
session,
you
can
obviously
use
that
nobody's
stopping
it,
but
here
in
depth,
I,
don't
think
that
you
need
to
do
anything
extra
and
that's
my
own
filling.
B
A
A
B
F
B
Yeah
but
I
mean
the
ND,
no
I,
guess
it's
the
you
know,
and
this
is
basically
what
you
end
up.
If
you
know
obviously
you're
talking
to
somebody
who
doesn't
support
your
other
contestants
oughta
grow
than
this
is
your
your
fallback
I
mean
hopefully
I
think
the
idea
is,
you
always
run
it,
and
mostly,
if
you
have
a
real
condition,
can
allow
them
at
your
diaper
trigger
yeah.
H
E
And
just
going
back
to
the
congestion
control
thing,
I
think
Karim
cat
even
says
that
all
congestion
control
should
work
within
the
envelope
of
a
circuit
breaker.
So
it
is
kind
of
I
think
if
people
evaluate
their
congestion
controls
to
work
like
the
browsers
or
whoever
is
like
making
their
congestion
control
that
they
seem
to
work
within
the
circuit
breaker,
then
you
kind
of
get
that
by
default.
So
yes,.
G
Dad
Ericsson
I
mean
yeah.
What
do
you
side
burn
is
right.
I
mean
that
the
requirement
says
like
arm
cat,
conscious
control
should
work
envelope.
So
even
if
people
has
not
been
implementing
a
circuit,
breaker
I
say
we
need
to
do
that
and
in
perhaps
in
the
in
the
evolution
of
Aaron
cat.
We
need
to
be,
and
now
more
be
more
strict
about,
like
I
having
a
mean
arm
cat.
They
should
actually
provide
results
like
that.
This
works.
G
This
doesn't
break
their
constant
control
rhythm,
but
looking
at
the
draft
at
that
time,
I
personally,
I
didn't
like
I,
should
actually
put
effort
to
really
to
implement
these
things
in
open,
/,
DC
and
stuff
that
we
do
like
to
see
if
things
works,
but
if
it
is
in
a
really
good
stead,
we
really
definitely
do
that,
but
depending
on
like
I
mean
now,
where
is
it
we're
talking
about
these
changes?
We
are
talking
about,
like
the
p-value
I'm,
still
not
sure,
like
I'll
invest
my
resource
to
really
implement
it
right
now,.
C
Okay,
so
next
steps
here,
my
inclination
would
be
to
actually
run
a
very
long
working
class
call
like
six
weeks
and
it's
because-
and
we
have
this
significant
long
list
of
documents
depends
on
this.
One
and
I
think
we
need
to
set
some
deadlines
for
actually
doing
these
reviews
in
checks,
etc.
So
and
I
think
that
would
probably
work
best
way
to
working
plus
call
so.
A
F
D
A
C
D
Click
we
at
the
thing
it
was
in
the
music
right
we
as
part
of
the
clerics,
maybe
text
Ravi
TX
was
offer.
We
decided
that
we
need
to
add
support
for
our
FC.
Fifty
to
eighty
five,
which
is
the
header
extensions,
are
together
extension
to
allow
support
for
mixing
single
bite
and
double
by
the
RTP
headers
in
the
same
RPP,
a
string.
D
So
so
so
this
is,
this
is
the
major
change.
There
were
some
comments
from
both
from
calling
and
from
Dave
zinger,
who
is
the
original
author
in
his
culture
of
this
draft
about
the
document
and
that's
why
the
text
that
was
changed
based
on
that
so
currently
does
it.
So
not
a
big
change
so,
basically,
after
we
think
what
we'd
like
to
do
is
to
adopt
it
eventually
the
one
whom
I
was
welcomed
them.
B
John,
clinics,
I,
don't
disagree
with
anything.
You
said:
I
sent
a
bunch
of
comments
like
five
minutes
for
the
meeting
start
and
I'm.
Sorry
for
not
sending
it
earlier.
I,
don't
know.
If
you
want
to
speak
to
those
now
or
yes,
please.
If
you
have
the
time,
okay,
I'm
actually
can
you
have
that
email
and
your?
Can
you
pull
it
up?
Your
laptop,
so
I
can
remember
what
I
said.
B
A
B
You
yeah,
so
one
of
the
points
was
we've
talked
about
this
in
the
past
is
something
grumpy
about
with
header
extensions.
There's
language
in
there,
which
you
know
I
somewhat
tendentious
ly
say
you
know,
header
extensions
must
be
useless,
which
is
to
say,
must
be
ignore
bowl
without
affecting
interoperability.
I
think
we
want
to
alter
that
to
say
you
know,
you
know,
you
know,
must
not
change
the
semantics
of
other
parts
of
the
RTP
packet,
but
you
know
it's
perfectly
fine
for
them
to
have
metadata,
that's
essential
for
interoperability.
B
D
B
B
F
B
B
Data
and
I
think
our
usual,
your
current
solution
of
put
it
in
Hetar
extensions
and
also
rtcp.
So
it
seems
to
work
fine
for
this,
and
you
know
that
means
that
if
your
header
exceptions
die,
you
get
a
little
bit
delayed
and
it
also
means
that
if
a
source
is
not
currently
sending
you
find
out
about
it
earlier,
so
that's
maybe
we
don't
need
to
worry.
Do
that,
but
it
just
you
know
it's
you
know.
D
So
that's
that
we
can
put
a
better
language
is
saying
that
it's
it's
good
to
have
them
go
through,
but
again
it
won't
prove
it
won't
solve
the
issue,
because
you
still
need
to
have
this
default
back
mechanism
of
having
maybe
multi-city
in
order
to
guarantee
the
day
to
have
more
chance
of
delivery
of
the
message.
Anyhow
and.
B
Then
the
other
two
points
which
I
brought
about
there
is
least
the
ones
that
are
currently
on
the
screen.
I
remember
whether
okay
yeah
Mia
is
that
Korean
JT
285,
the
two
bike
forum
is
op.
Only
the
one
bite
form
is
MTI,
it
sounds
like
we
eat
me
so
either
we
both
need
a
way
to
determine
definitively
other
side
supports
to
bite
form,
and
maybe
we
also
want
to
make
to
bite.
Em
TI
as
well
I
mean
give
it
all
the
things
we're
doing
like
with
SS
header
extensions,
which
would
need
it
in
some
cases.
B
B
D
B
A
little
but
the
point
being
that
I
mean
the
issue.
If
you
are
concerned
about,
is
you
know,
you
have
a
variable
length,
header
extension,
you
know
and
Sutton,
and
that's
why
we
have
these
changes.
Suddenly
you
know
it.
Suddenly,
its
value
is
longer
than
16
bytes.
So
you
need
to
switch
the
two
byte
form
with
a
low
ID.
There's
no
way
to
negotiate
know
whether
that's
gonna
be
received
at
or.
B
B
C
C
D
B
B
D
You've
said
you
can,
but
still
that
doesn't
solve
the
whole
issue,
because
I
mean
I
understand
what
you're
saying
if
you
negotiate
initially
the
support
for
this
specific
header
extension,
then
you
you
want
to
switch
from
one
by
two
two
bytes,
okay,
yeah.
So
anyhow,
you
cannot
just
switch
our
be
thoroughly.
You
only
can
switch
for
once
that
you
were
already
very
excited.
You
know,
and
you
just
want
to
know
that
the
two
x
is
generally
supported
by
the
other
side
and
to
have
some
exercise
if
the
IV
now
for
the
same
right.
D
A
C
B
C
Then,
in
that
case,
I
think
the
reasonable
thing
is
to
use
the
proposal,
which
is
in
the
enrollees
draft
auras
and
Ronan
David's.
It's
the
other
versus
draft
is
to
use
that
generic
singling
saying
oh
I
support
the
updated
spec
its
base
with
you
saying
sorry
can
do
both
one
and
two
bites:
okay,
yeah!
So.
B
B
C
Then
I
think
we
should
see
if
you
support
adopting
this
is
a
work
of
item
I,
so
any
more
questions
around
that
or
or
what
the
purpose
you
understand
why
we
updating
is
so
so.
Let's
about
this,
I
will
ask
about
two
supports
adoption
and
then,
if
there's
any
of
opposed,
so
do
you
support
adoption
of
this
graph
to
the
workroom
fight
them
now.