►
From YouTube: IETF111-RUM-20210729-2330
Description
RUM meeting session at IETF111
2021/07/29 2330
https://datatracker.ietf.org/meeting/111/proceedings/
A
B
Well,
they
were
up
until
a
minute
ago.
I'm
not
looking
right
now,
but.
B
D
B
A
C
D
B
B
B
B
Anybody
have
any
any
bashing
they
want
to
do
to
the.
B
Difficulty,
okay!
Well,
we
didn't
have
any
bashing
to
do
so.
We
haven't
even
run
out
of
our
our
bashing
time.
So
I
guess
we
didn't
lose.
Anything
jonathan
has
agreed
to
take
notes
and
eugene
is
going
to
do.
Do
the
job
prescribing
it
from
past
experience.
There's
probably
nothing
to
do
in
jab.
Prescribing
here
just
keep
an
eye
out.
If
somebody
has
something
they
want
you
to
bring
forward,
do
it
otherwise
you're.
D
F
D
Okay,
so
I
submitted
an
05
draft
before
the
cutoff
and
I'm
going
to
go
over
what
I've
done.
You
may
have
noticed
that
I
submitted
an
06
draft
this
morning
by
the
itf
rules.
We
have
to
consider
the
one
that
was
available
to
you
before
the
meeting
started
before
the
cutoff,
but
what
I'm
talking
about
has
been
done
in
the
06
draft,
but
here's
here's
where
we
are
so
all
outstanding
issues
that
I
know
of
have
been
dealt
with,
with
some
exceptions
that
I'm
going
to
cover
on
a
later
slide.
D
Paul
k
did
submit
some
comments
against
the
o5.
I
have
made
all
of
his
suggested
wording
changes.
I
have
fixed
the
registration
text
as
he
suggested
I
I
did
mess
with
the
title.
That
was
the
title
of
four
five.
D
Two
two
was
the
dial
around
section
and
I
fixed
that
I
fixed
two-stage
dial
around
to
specify
that
you
use
the
front
door
number
uri,
which
fixes
his
issue
with
that
and-
and
I
did
rework
the
text
on
telephone
number
so
that
it's
clear
that
you,
you
use
the
syntax
with
no
no
decorations.
It's
just
the
telephone
number.
It's
plus
country
code
and
then
the
actual
number,
with
nothing
else.
D
I
did
fix
the
aor
thing
a
little
differently
than
what
this
says.
If
you
look
at
the
text,
I
actually
allowed
sipped
uris
in
the
in
that
come
from
the
configuration,
which
is
what
his
comment
was
and
then
I
did
split
the
configuration
service
into
two
pieces,
one
of
which
is
unauthenticated
and
gets
you
the
sign
up
and
front
door
information
and
the
other
gets
you
the
per
device
or
per
user
configuration.
D
So
again,
all
of
that
was
paul's
comments.
I
believe
I've
covered
all
the
issues.
There
are
a
couple
things
to
talk
about
in
those,
but
I
I
I
think
everything
is
done
in
one
way
or
another.
D
So
let
me
go
to
this.
There
are
a
couple
of
issues
that
I
that
require
make
sure
that
we're
all
okay
with
it
single
stage
dial
around.
He
raised
the
issue
about
because
the
example
had
a
route
header
in
it
and
it
was
confusing
and
we
went
through
it
back
and
forth
and
I
talked
offline
about
it
and
what
the
I
just
got
rid
of
the
route
header.
D
It
goes
back
to
the
original
notion
that
you,
you
you
say:
sip
colon
telephone
number,
at
whatever
the
dollar
on
peradore
domain
is
and
then,
if,
if
you-
and
that
tells
you
who
the
dalaran
provider
is
you
send
it
to
your
default
provider
because
all
calls
to
go
to
default.
Finder
always
there's
no
question
about
that,
and
it
just
tells
him
what
to
do
so.
D
B
I'm
fine
on
this,
the
best
I
I
mean
it
followed.
I
mean
doing
it
this
way.
If
the
provider
follows
normal,
sip
message,
processing,
behavior
it'll
cause
them
to
do
the
right
thing.
You
know
they're
going
to
receive
the
message
they're
going
to
look
at
the
request,
uri
and
say:
well,
it's
not
for
me.
I
guess
I'm
supposed
to
proxy.
It.
D
Yeah
and
that's
what
they'll
do
exactly?
Okay,
if
there's
no
other
comments,
that's
what
o6
does
so
that's
done
moving
on,
so
these
are
the
things
that
I
didn't
do
that
have
been
requested.
D
D
D
We
could
add
text
which
is
not
an
o6
that
provides
a
little
bit
of
of
help
in
implementation,
making
it
a
little
bit
easier
to
implement.
I
did
put
in
the
suggestion
that
if
you
do
ipv6
for
media
or
ip56
for
signaling,
you
have
to
do
it
for
media.
That
definitely
makes
the
implementation
simpler.
D
So
it's
either
one
one
or
the
other
everything,
but
I
don't
think
that
it
is
reasonable
to
build
an
ipv4
only
implementation,
it's
just
it's
v6
is
all
there
is
in
many
networks
now
and
and
that's
going
to
get
increasingly
true
as
we
we
see
people
deploying
six,
only
networks.
G
Read
the
rfc
draft
regarding
ipv4
ipv6.
If
I'm
reading
it
correctly,
the
way
that
it's
speaking
to
me
is
it's
saying
that
the
roux
must
support
both.
G
B
If
anything
that
I
think
that's
backwards,
I
mean,
I
think
it's
reasonable
to
assume
that
the
providers
can
get
an
ipv4
address,
so
they
that
they
shouldn't
have
any
technical
problems
supporting
both
the
the
rue
may
be
on
a
device
that
doesn't
have
a
b4
address.
D
Yeah,
that's
that's
the
thing
that
we're
most
worried
about,
I'm
looking
for
the
the
text
here.
D
D
B
Version
the
one
exception
to
that
that
I
might
bring
up
is,
if
you
use
ice,
to
negotiate
the
media.
B
Then
I
think
you're
still
free
to
offer
candidates
of
both
flavors
yeah
if
the
yeah,
if
the
signaling
was
v6
and
and
you
offer
both
v6
and
b4,
if
the
other
side
doesn't
do,
you
know
can't
do
v4
well,
they'll
just
ignore
those
candidates
and
things
will
be
okay
but
you'd,
but
I
think
it
in
the
case
of
ice.
You
at
least
better
offer
candidates.
D
Yeah
well,
so
I'm
I'm
willing
to
put
that
text
in
that's
right
now
the
v6
text
says
the
same
version
of
ipv
of
ip
must
be
used
for
both
signaling
and
media
of
a
call
so
that
that
doesn't
require
that
doesn't
support
ice,
allowing
it
to
be
different.
I'm
I'm
certainly
willing
to
add
that
I
I
don't
care
that
much
about
it.
I
I'm
I'm
okay.
D
B
C
B
C
G
C
B
B
D
D
Okay,
I
did
leave
contact
sync,
as
is
I
I
just
it's
just
a
simple,
straightforward
implementation:
I'm
willing
to
deal
with
the
x
card
j
card
thing,
but
I
really
think
we
ought
to
do
j
card.
It's
really
a
simple
conversion
if
you've
got
one
to
convert
to
the
other,
since
it's
exactly
the
same
data
format
and
just
a
representation
issue,
but
I'm
willing
I'd
be
willing
to
to
go
back
and
you
know,
do
do
an
x
card.
D
I've
had
some
discussions
with
the
folks
who
would
you
know
there
was
this
worry
about
the
fcc?
And
I
I
I
I
have
a
considered
opinion
that
that's
not
an
issue
that
that,
if,
if
the
spec
comes
out
saying
jason,
that
the
fcc
will
allow
that
that
would
have
to
get
done-
and
you
know
you
can
never
guarantee
anything
when
it
comes
to
regulation.
So
I
wouldn't
say
that
it's
a
done
deal,
but
I
I
have
it
on
good
authority
that
wouldn't
be
a
problem.
A
A
I
mean
it's
not
quite
a
simple
change
because
it
has
to
be
implemented
on
a
lot
of
different
platforms
and
systems
and
we
already
have
everything
working
as
x
card.
So
it's
like.
Is
it
really
worth
all
the
work,
the
development
effort
to
effectively
get
the
same
thing
right,
like
you
said
it's
the
same
information
same
data.
D
D
D
All
right
I'm
moving
on,
so
there
was
a
complaint
about
the
webrtc
compatibility,
and
I
wanted
to
remind
you
that
what
we're
supporting
is
not
webrtc
but
the
medius,
the
media
requirements
of
webrtc,
so
that
it
would
be
possible
to
take
a
webrtc
browser
client
and
connect
it
up
to
a
a
provider
that
supported
the
the
roo
interface
using
some
server.
D
That
would
have
to
be
built
to
do
the
job
that
would
generate
signaling
one
way
and
and
webrtc
the
other
way,
but
wouldn't
require
that
you
mesh
mush
with
the
media
that
that's
the
idea
is,
that
is
that
the
signaling
is
completely
different,
but
the
media
is
the
same
and
it
has
the
same
sdp
and
the
same
the
same
specs
for
media.
So
that's
all
that.
D
D
What
I
mean
is
is
that
any
webrtc
implementation
that
meets
the
minimum
requirements
of
the
rfcs,
the
browser
can
generate
a
set
of
media
streams
that
the
box
that
would
go
between
a
webrtc
client
and
a
rue
supporting
vrs
provider
would
only
have
to
mess
with
signaling
and
would
not
have
to
re-decode
and
re-encode
the
video.
D
That's
the
only
thing
it
it.
It
succeeds
at
doing,
and
there
is
one
specific
case
where
it
actually
does
have
to
decode
and
re-encode.
The
video,
which
is
rtt,
which
for
webrtc,
is
done
over
the
webrtc
data
channel
and
and
our
spec
still
says
4103,
so
you
actually
would
have
to
re-encode
the
the
the
the
rtt,
but
you
wouldn't
have
to
do
that
for
the
audio
in
the
video,
and
it
also
gives
you
a
set
of
capabilities
in
the
sdp
that
you
have
to
support.
D
So
it's
it's
saying
some
things
about
what
can
be
in
the
m
and
c
lines
that
may
be
a
little
more
than
what
is
currently
supported,
but
it's
not
a
major
difference.
It's
there.
There
are
some
improvement.
Improvements
is
the
wrong
word,
but
they
there
are
some
capabilities
that
webrtc
introduce
that
aren't
necessarily
in
the
current
implementations.
A
D
Well,
you
have
to
you,
you
have
to
you
again.
You
have
to
support
someone
else,
doing
a
conversion
between
webrtc
and
the
rue
interface,
where
that
conversion
doesn't
include
re-re-mucking
around
with
the
the
media
other
than
rtt.
You
aren't
responsible
for
dealing
with
webrtc
signaling,
you
weren't
responsible
for
that
server.
That
has
to
do
the
munching
of
the
of
the
signaling.
You
aren't
responsible
for
dealing
with
the
rtt
issue
you
are
on.
The
only
thing
this
is
doing
is
adding
additional
media
media
requirements.
A
Yeah,
so
webrtc
doesn't
even
do
signaling
right,
it's
ultramarine
camera
on
here,
but
it
does
do.
It
does
have
a
lot
of
enhanced
media
capabilities
and
webrtc
is
all
about
media,
specifically
yeah.
There
are
big
things
specific
requirements
it
has
like.
You
must
use
gtls
for
media
right,
yes,
which
is
a
great
thing.
D
A
But
we
all
agree
that
encryption
well,
like
you
know,
within
the
realms
of
affecting
video
quality
on
other
devices,
is
a
good
thing,
but
there
are
specific
things.
It
does
look
like
mac
and
sync,
and
that
that
are
there
are
things
that
you
do
have
to
support.
If
you
want
to
send
video
from
an
interpreter
video
phone,
that's
not
doing
webrtc
to
a
webrtc
client,
it's
not
as
simply
as
something
simple
as
sending
the
media.
A
D
D
It's
not
has
nothing
to
do
with
signaling;
it
is
only
to
do
with
what
can
be
in
the
sdp
and
corresponding
correspondingly.
What
can
be
in
the
media
stream?
That's
it.
There
is
no
more
than
that,
but
that's
that
is
doing
things
that
is
beyond
what
a
typical
vrs
device
currently
does.
Let
me
give
you
an
example:
it
requires
support
for
multiple
video
streams.
D
Right
now,
that's
typically
the
server
that's
making
that
decision
and
if
you
don't
offer
that
that
isn't
gonna
isn't
gonna
change
anything
and
you
typically
don't
have
multiple
cameras,
so
that
doesn't
usually
go
the
other
way,
but
that's
a
typical
thing
that
you
might
have
to
that
that
that
is.
That
is
a
difference.
It
probably
is
a
difference
that
matters
to
you,
but
it
is
a
difference
it.
There
are
probably
others
that
do,
but
I
I
I
the
one
thing.
D
Parameters,
that's
correct.
There
are
codec
parameter
differences.
The
I
there
was
there
was
a
a
a
a
strong
suggestion
when
we
created
this
work
group
that
this
capability
be
be
provided.
D
D
Group
done
was
that
we
tried
to
maintain
compatibility
with
webrtc
being
the
current
best
itf
recommendations
on
video
devices,
and
I'm,
I
think
that
the
argument
of
well
it's
extra
work
on
the
providers
we
don't
need
it
is-
is
not
going
to
be
enough
to
get
us
over
if
we
found
a
if
we
found
an
issue
that
made
compatibility
either
made
implementation
or
me
meeting
our
goals
impossible
or
you
know
way
too
hard,
then
we
could
go
along
and
say
well,
look,
you
know,
there's
this
problem,
that
we
have
completely
different
goals
and-
and
we
need
different
mechanisms
to
to
solve
those
goals,
and
we
can't
maintain
the
compatibility
in
this
area.
D
We,
it
isn't
a
hard
requirement
in
the
charter,
but
it
is.
It
is
something
that
we're
we're
obligated
to
attempt
to
maintain
and,
and
so
I'm
trying
to
do
that
and
that's
part
of
my
my
I'm
carrying
the
torch
of
what's
in
the
charter.
B
A
A
A
Who
don't
know
anything
about
being
a
provider
or
the
brs
provider
profile
that
we've
all
agreed
to?
You
know
to
adhere
to
to
ensure
great
compatibility,
which
has
been
very
successful
and
so
very
nice.
Somebody
should
have
referenced
that
and
looked
at
the
existing
interface
between
providers,
which
I
you
know
which
could
be
used
by
the
roo
to
go
to
the
extreme.
D
Well,
I
you
know,
I
I'm
I'm
wearing
two
hats
and
I'm
you
know.
I've
got
my
editor
hat
and
my
my
chair
hat
and
my
editor
hat.
I
want
you,
know
the
chairs
to
figure
out
how
to
solve
this,
because
the
charter
says
do
this
and
the
providers
are
saying
don't
do
that
with
my
chair
hat,
changing
hats,
I'm
gonna
I'll,
repeat,
paul's
issue.
D
D
If
you
want
to
do
something,
that's
older
than
that,
they
usually
say.
Well,
look
we've
done
this
before,
and
we
we
for
various
reasons,
and
I
can
tell
you
why
you
know
they
think
that
old
stuff
is
is
not
appropriate
anymore.
They
think
that
we
should
support
their
current
best
practice,
and-
and
it's
it
there
are.
It
is
always
difficult
when
you
go
to
any
any
new
organization
to
work
on
some
specification.
D
There's
a
piece
of
of
of
institutional
memory
and
and
process
and
and
expertise
that
you
have
to
deal
with,
which
doesn't
always
meet
what
your
ideal
situation
and
you
know
wherever
you
go,
that's
an
issue,
and
here
that
was
one
of
the
things
we
had
to
get
through,
that
we
they
wanted
us
to
take
current
best
practice
and
into
account,
and
if
we're
in
it
and
if
it
wasn't,
if
we
couldn't
do
it,
we
have
to
have
a
reason
for
not
doing
it.
D
And
if
we
do
then
then
then
we
can,
you
know
it.
Isn't
it
isn't
a
hard
requirement
in
the
charter.
The
charter
doesn't
say
you
must
it
says,
should
and
and
and
and
so
if
we
can
come
up
with
well,
this
is
the
problem
and
it
have
to
be
some
kind
of
a
technical
problem,
not
a
we
don't
want
to
do
it
kind
of
problem.
C
Sure
now
recall
the
goal
was
that
actually
not
so
much
to
put
requirements
on
providers,
but
rather
to
say
we
should
design
this
enter
the
interface
such
that
it's
possible
to
implement
a
rule
in
a
webrtc
environment,
and
I
think
that's
you
know
that
what
that
means
is
not
that
you
know
a
rule
can
do
anything
the
webrtc
can
do,
but
rather
that
the
person
writing
implementing
the
rule
can
you
know
has
to
you
know,
configure
webrtc
to
do
only
the
things
that
interface
supports,
and
so
I
think
this
is,
and
I
think,
as
sounds
like
of
your
description,
this
was
achieved,
and
I
don't
think
this
is
saying
anything
that
other
people
have
to
go
out
of
their
way
to
support
crazy
things
that
webrtc
can
do,
but
rather
that
you
know
you
know
as
long
as
it's
possible
to
do
what
brian
said
that
you
know
without
a
media
without
a
transcoding
gateway.
C
It
would,
you
know,
write
an
imp
right,
a
write,
something
where
most
of
what
the
ru
is
doing
is
written.
It
can
run
inside
a
browser,
and
then
you
know
gateway
in
your
cloud
to
something
else.
I
think
that's
achieved
and
I
don't
think
this
is
a
requirement
on
other
providers
anyway,.
D
I
mean
there
are
there.
There
are
things
that
are
in
addition,
that
that
that
that
would
have
to
be
supported
that
are
beyond
what
the
current
provider
interface
specifies
that,
but
I
don't
think
they're
very
significant.
I
mean
the
biggest
ones
I
mean.
Well,
I
don't
know
if
it's
the
biggest
but
but
opus.
Is
there
that's
one
thing,
but
there
are
a
couple
of
details.
D
If
you
go
through
and
look
at
the
specs
on
what
you
can
specify
in
the
sdp
offer,
which
is
all
we
worry
about
right,
what
comes
in
the
offer
is
the
part
that,
if
it's
beyond
what
you're
used
to
accepting,
because
if
there's
anything
that
came
back
in
the
answer,
you
can
just
not
use
it
and
no
one
would
care
be
all
fine.
B
The
thing
I
would
you
know
that
that
probably
that
may
bear
scrutiny
is
you
know
interoperability
like
in
an
end-to-end
case.
You
know
with
with
legacy
devices,
you
know
legacy
brews.
D
A
D
D
D
A
B
A
D
I
I
I
agree.
I
agree
it
is
not
what's
in
the
candidates,
it's
the
actual
mechanism,
it's
if
it
could
appear
in
it
as
a
candidate,
then
the
mechanism
that
supports
that
has
to
be
has
to
be
able
to
be
dealt
with
right.
So
I
I'm
I'm.
I
I
agree
with
you.
It
is.
It
is
not
just
you
know
what
could
be
in
an
offer.
It's
the
mechanisms
that
would
support
that.
That
are
the
hard
part.
B
D
Yeah-
and
I
I
mean
I
could
absolutely
see
statements
that
says
you
know
if
the
rue
is
attempting
to
connect
to
a
device
which
is
you
know,
a
red
legacy
device,
then
it's
then
the
answer
can
all
you
know
would
have.
You
know,
restrictions
that
that
would
limit
what
what
could
be
done,
and
I
I
think,
there's
that
that's
fine.
D
I
I
would
hope
that
if
it
was
the
other
way,
you
know
root-a-roo,
where
was
webrtc
on
both
ends
that
that
you
wouldn't
see
much
restriction
that
was
imposed
by
the
middle,
but
I
I
I
mean
if,
if
if,
if
we're,
if
we
need
to
add
text
that
says
when
can
be,
you
know
conversing
with
a
device
that
doesn't
have
this
capability?
You
know
the
whatever
it
is
that
were
the
specific
and
again
it'd
have
to
be
something
where
you
couldn't
have
the
right
thing
come
back
in
the
answer.
D
Given
the
given
the
the
the
the
offer,
then
I
think
it
would
then
then
I
think
we
we
we
would
have
an
issue
we
we
would.
I
then
we
could
write
texts
that
dealt
with
that
specific.
That's
what
I
meant
to
say.
A
Yeah,
I
think
we
could
certainly
help
do
that.
It's
it
definitely
opens
a
can
of
worms.
So
there's
just
from
experience
and
trying
to
support
some
of
those
webrtc
platforms.
It's
not
it's
not
simple
and
easy,
and
it's
it's
something
you
have
to
do
on
a
lot
of
platforms
right.
We
have
apps
on
ios,
android
windows,
mac,
linux
touches.
D
A
A
D
A
A
B
I
mean
I
mean
I
don't
I
don't
know
what
what
ios
does
but
they're
ipv6
only
the
the
I
presume
that
all
that
b6
v4
stuff
is
in
cases
where
they're
compelled
to
somehow
be
able
to
talk
to
a
v4
device
if
yeah,
if
with
an
implementation
of
this
ru
spec,
they
wouldn't
have
that
constraint,
and
so
I
presume
I
would
hope
that
they
can
use
ipv6
directly
without
special
accommodations
for
conversion
to
v4.
A
Well,
there
are
some
specific
things
you
have
to
support.
Just
for
example,
it
uses
dns
64..
What
dns
64
does
is.
It
says:
okay,
go
to
give
me
the
ip
address
for
and
it
gets
an
ipv4
address,
and
it's
like,
oh
okay.
I
can't
use
this.
I
need
to
convert
this
to
an
ipv6
address
and
so
it
tries
you
know
they
do
a
pretty
good
job
of
trying
to
make
it
transparent
to
the
app.
A
But
when
you
get
into
stp
type
stuff-
and
I
want
to
tell
the
other
client
what
my
local
ip
address
is-
there
are
some
there's
things
you
have
to
handle
to
understand.
Oh
okay,
that's
actually
an
ipv4
address.
I
need
to
convert
it
back,
so
nas
64,
dns
64..
D
I
think
that
what
you're
talking
about
is
does
not
apply
for
the
reasons
that
paul
suggests,
if
you
hav,
if,
if
the
only
addresses
you
return
well,
if
you
would
return
quad
a
records
for
every
resource,
you
can
also
return
a
records
for
resources.
But
if
you
return
quad
a
records
for
resources,
then
you
never
do
nat
64..
You
never
need
a
a.
You
need
a
need
to
recognize
that
it's
an
ipv4
address.
It's
always
an
ipv6
address.
A
It
looks
it
looks
like
an
ipv6
address,
but
it's
really
an
ipv4
address,
hiding
in
an
ipv6
address
and
there's
a
very
specific
rfc
about
how
to
recognize
that
and
convert
it
back
and
forth
and
so
like
with
ice
specifically
right.
It's
really
mainly
an
issue
with
ice.
The
benefit
ice
provides.
Is
that
if
you
and
I
are
on
the
same
local
network,
we
can
send
video
directly,
but
we
both
have
to
recognize
that.
A
Well,
imagine
two
ios
device
yeah,
that's!
I
think
we
need
to
dig
into
that
a
little
bit.
Okay,
but.
B
D
Yeah,
yes,
so
the
mwi
thing
is
still
there
paul
suggests
it
only
needs
to
be
required
if
the
provider
offers
voicemail.
I
remember
if
I
actually
put
that
in
I
may
have
put
that
into
six.
Is.
B
D
B
I
mean
I
I
mean
the
fcc
makes
it
makes
it
optional
right.
D
Go
ahead,
the
only
thing
it
requires
is
is
is
the
protocol,
the
mechanism
that
lets
the
device
know
that
mail
is
waiting.
That's
it
just
that.
B
D
D
B
B
A
D
D
B
A
A
The
you
know,
shift
shift
call
for
video
mail
experience.
D
You
know
I'm
all
right
with
saying
you
have
to
be
able
to
support
an
https
browser
interface.
For
that
that's
fine,
but
that's
still
the
you
still
have
the
problem
of
notification.
B
D
Built
that
when
you
push
the
button
that
says,
go
get
mail.
If
those
goes
and
follows
that
uri
and
then
you
can
go
and
build
it,
you
can
build
that
interface.
Any
way
you
want.
I
don't
care
what
the
ui
is.
I
don't
care
if
it's
sip
or
http
that
that
doesn't
matter
what
I
care
about
is
that
that
the
device
knows
that
there's
mail
so
that
it
gives
you
that
option.
A
D
D
That
was
my
list,
so
all
I've
got
is
you
know.
You've
got
a
lot
of
comments
great,
but
we've
got
to
get
them
in
and
make
decisions
because
we're
done,
I
think
we're
done
we
so
that
that's
where,
where
I
think
we
are
I'm
willing
to
do
as
many
reps
as
it
takes,
I'm
willing
to
you
know
like
we
agreed
on
a
couple
of
things
today:
the
change
back
to
x
card.
D
I
will
put
that
in
there'll
be
a
seven
soon
and
any
any
anything
else
we
come
up
with
that.
We
agree
to
I'm.
You
know
I
will
expeditiously
get
them
into
the
into
the
draft,
but
we're
at
the
end.
Now
I
want
to
start
running
through
the
approval
process.
Yeah.
B
D
A
I
mean
we
still
have
issues
and
concerns
that
haven't
been
addressed.
I
don't
know
how
that
changes
anything
so
we're
gonna,
get
you
more
details
on
some
of
these
yeah.
So
the
last
call
I
don't
know
the
protocol
there
right.
So
something
like
you
have
to
get
all
your
issues
in
by
this
date
or
for
it's,
like
speaking
now
or
forever
hold
yours
well,.
D
B
Yeah,
the
the
ietf
last
call
is
the
is
primarily
there
to
allow
people
that
that
don't
participate
in
the
work
group.
A
chance
to
raise
you
know,
say
something
yeah.
Usually
you
don't
want
them
doing
that
unless
they've
got
some
real
expertise
that
and
can
raise
an
issue.
That's
that's
grave,
so
I
mean
the
working
group.
Last
call
is,
you
know,
says
yeah.
B
And
there's
no
deadline
for
finishing
working
group
last
call
so,
but
it
you
know,
usually
when
we
do
that,
we
think
we're
close.
You
know,
and
there
may
be
some
things
to
finish
up,
but
it's
like
not
like
we're
gonna
massively
revise
the
document,
some
more
yeah,
so
we
don't
really
want
to
do
it.
If
we
think
there's
going
to
be
massive
revisions
to
the
document
as
a
result
of
it.
A
A
D
Well,
we're
again,
everybody
gets
to
to
put
their
comments
in
at
at
last
call
working
group
last
call
and
we
we
hope
that
you,
other
people
will
participate
and
again
its
specifics
are
the
things
that
we
really
need.
I
mean
what
what
do
we
want
to
change
is
the?
What
is
the
actual
problem?
D
We
have
processes
for
breaking
disagreements
where
you
know,
one
set
of
people
thinks
one
thing
and
another
set
of
people.
You
think
something
else
we
will.
I
got
my
chair
hat
now.
We
will
use
those
processes
to
deal
with
a
circumstance
in
which
some
people
think
one
thing
and
other
people
think
another
thing.
That's
the
that
is
the
the
rough
consensus
rules
in
the
itf.
D
We
we
would
like
to
get
what
we
like
to
do
to
to
do
those
run
those
processes
with
very
specific
things,
not
gener
generalities.
Like
I
don't
like
this,
it's
too
much
work.
D
D
So,
the
the
more
specific
you
can
get
the
more
likely
well
the
easier
it
will
be
to
run
those
processes
to
to
to
deal
with
the
the
some
people
think
one
way
some
people
think
another
way.
If,
if,
if
you
get
you
get
it,
if
you,
if
you
raise
an
issue
and
everybody
says
oh
yeah,
that's
a
real
issue,
and
and
and
and
you
know-
or
at
least
most
people
or
almost
everybody
thinks
it's
a.
It
really
is
an
issue
and
we
really
got
to
deal.
B
D
Then
we
just
deal
with
it,
I
saw
alex
for
a
second,
were
you
going
to
say
something
alex.
E
Thank
you,
brian
and
paul,
but
yeah
I
mean
when
it
comes
to
the
expertise
level.
It
definitely
is
a
lot
we
can
dig
into,
but
we
agreed
as
providers.
Actually
this
morning
we
had
a
brief
meeting
about
it
and
we
said
we
would
agree
on
on
on
the
subjects
that
are
that
were
on
the
slide
of
not
done
so.
E
I
think
if
we
dig
into
them
a
little
more
and
maybe
come
to
a
consensus,
I
know
we
agreed
on
the
x
card
now
you
know
and-
and
we
can
maybe
put
something
better
together.
B
A
E
I
just
wanted
to
ask:
I
have
tried
to
join
the
group
before
and
I
just
haven't
been
able
to
get
the
invitation.
D
B
D
Thank
you
for
helping
out.
I
appreciate
your
your
comments,
both
all
of
you.
Thank
you
very
much
good
to
see
you
see
you
later
bye.