►
From YouTube: IETF112-STIR-20211112-1600
Description
STIR meeting session at IETF112
2021/11/12 1600
https://datatracker.ietf.org/meeting/112/proceedings/
A
B
And
it
is
so,
let's
get
started.
This
is
the
stir
session.
It's
friday
last
session.
We
seem
to
keep
getting
this
slot
so
whatever
here
we
go
the
note
well
by
this
point
in
the
week.
I
hope
you've
all
well
aware
of
it.
This
is
the
rights
of
responsibilities
for
participating,
so
please
make
sure
you're
aware
of
it
before
you
contribute.
B
A
Okay,
so
the
chairs
had
agreed
in.
Oh,
I
see
johnson
q
but
I'll
say
real
quick.
The
chairs
had
agreed
at
the
last
ietf
meeting
that
we
were
to
discuss
this
charter
update
that
we
had
some
proposed
text
from
john
and
we're
going
to
discuss
it
with
murray.
We
appear
to
have
dropped
the
ball
on
that,
so
I
had
an
email
exchange
with
murray
last
night
and
he
is
okay
with
the
wording
that's
presented.
D
F
A
C
F
C
There
we
go
okay,
I
got
it
perfect.
This
is
my
first
time
using
this
one,
so
so
my
apologies
for
that
so
yeah
as
you
can
see
from
the
markup
at
the
bottom
of
this.
This
is
kind
of
gotten
kicked
down.
The
can
a
couple
of
times.
We've
run
out
of
time,
every
time
which
it
was
why
I
assume,
even
though
this
is
not
a
working
group
item,
we're
actually
discussing
this
first
this
time.
C
Why
this
is
particularly
interesting.
There
are
a
couple
of
either
mid-dialogue
or
dialogue,
terminating
request
potential
vulnerabilities
to
sip
communications
overall,
and
you
know
I've
heard
about
some
of
these,
for
example
in
the
gsma
about
shortstopping,
where
there's
an
intermediary
network.
There's
kind
of
synthesizing
buys
to
one
side
and
not
to
the
other.
In
order
to
do
arbitrage,
there's
a
whole
bunch
of
like
weird,
you
know,
toll
avoidance
or
building
maximization
attacks.
People
are
concerned
about,
and
even
just
like
route
hijacking.
You
know
given
how.
C
Really
it's
often
a
matter
of
provisioning
I'd
say
rather
than
consulting
any
authoritative
database,
how
the
destinations
of
sift
calls
ultimately
terminate
on
the
internet
be
great
if
we
had
some
stronger
assurance
that
things
have
landed
in
the
place.
That
they're
supposed
to
do
problem,
of
course,
is
that
all
this
does
take
stir
quite
far
past
the
threat
model
of
rfc
7375,
which
is
primarily
focused
on
eliminating
nuisance,
calling
and
a
set
of
related
things
like
voicemail,
hacking
and
swapping,
and
so
on.
C
Anything
that
really
is
looking
at
this
more
bi-directionally
is
going
to
be
a
bit
more
complicated,
which
is
why
we
need
a
charter
update
to
pass
it.
So
I
said,
there's
no
new
version
right.
This
is
kind
of
been
back
bernard
since
we
started
having
this
rechartered
discussion
and
we
we
have
been
kind
of
punting
on
this.
The
last
couple
of
times
that
we've
gotten
together
the
last
iteration
mostly
focused
on
this
pre-call
case,
which
is
really
interesting
to
me.
C
The
medialis
dialogue
that
can
be
established
in
order
to
allow
the
connected
side
to
reveal
to
the
original
caller
who
they
are
and
to
be
able
to
prove
that
cryptographically
with
stir
that
much
said
there
are
plenty
to
do
here.
Like
the
you
know,
we
had
a
discussion.
I
think
it
was
at
the
interim
actually
or
maybe
it
was
a
111.
I
don't
remember
about
you
know
what
some
of
the
privacy
implications
of
this
are,
because
there
are
definitely
some
risks
about
data
collection.
C
If
you
can
just
kind
of
form
a
medialis
dialogue
with
some
endpoint,
you
could
well
imagine
somebody
trying
to
do
that
on
a
mass
scale,
just
to
ascertain
what's
supposed
to
be
on
the
other
side
of
a
given
telephone
number.
So
we're
pretty
concerned
about
that.
This
interaction
with
anonymity-
I
think,
is
another
thing
I
think
that's
probably
easier
to
resolve,
because
we
do
have
so
much
text
about
anonymous
communications
associated
with
stir
already,
but
there
will
be
some
privacy
considerations
that
are
specific
to
this
particular
use
case.
C
C
And
you
know
this
is
something
that
is
really
salient
to
a
set
of
high
risk
use
cases
like
health
care,
government,
emergency
services,
things
like
that,
where
it
might
be
handy
for
there
to
be
some
place.
That
implementations
could
look
to
know
that,
if
they're
not
getting
connected
identity
like
from
their
bank
they're
supposed
to-
and
in
the
absence
of
that,
especially
as
this
is
going
to
be
an
incremental
mechanism,
that's
being
built
on
top
of
the
existing
stir,
ster
shaken
infrastructure.
C
That
seems
like
a
really
valuable
property
to
have.
I
don't
know
if
we're
gonna
articulate
it
in
this
draft.
I
think
that
service
is
orthogonal.
You
know
in
in
terms
of
exactly
you
know,
certainly
all
this
all
this
works
and
can
be
specified
at
a
protocol
level
without
the
existence
of
that
service.
C
You
know
protocol
breakdowns
so
that
implementers
know
what
they're
supposed
to
do
and
there
may
be
especially
coming
out
of
sip
brandy
and
some
of
the
things
that
we
did
for
that
some
actual
normative
revisions
to
4916,
one
of
the
obvious
ones,
is
the
elimination
of
the
identity
info
header
which
which
the
4916
examples
assume.
So
there's
like
stuff
like
that.
That
is
on
the
roadmap
for
this,
and
so
yeah
still
plenty
to
do
now.
C
We
need
to
think
about
it
and
really
the
question
before
the
group
for
the
past
couple
meetings
has
been
adoption
pending.
Of
course,
the
recharter,
and
I
did
have
one
side
that
just
kind
of
shows
what
the
charter
text
would
be.
That
is
salient
to
this.
That
goes
beyond
what
stur's
original
scope
was,
and
this
is
really
opening
up.
You
know
mechanisms
that
identify
the
called
party.
C
How
that
that
the
called
party
reached
the
calling
party
and
then
similar
use
cases
related
to
fraud
and
security
that
fall
under
that
rubric,
and
so
we
really
yeah
just
take.
Take
a
look
at
the
charter
text
it'll
be
circulated
on
the
list
in
front
of
murray
and,
if
it
all
seems
good,
then
we
will
adopt
and
start
filling
in
the
many
gaps
that
we
know
we
have
in
this
one.
C
C
F
C
And
yeah
I
mean
I
I
will
say
you
know,
I'm
aware
that
this
is
going
to
be
a
lift
in
terms
of
where
stir
shaken
is
today.
This
is
like
stir
shaken
2.0
kind
of
stuff
right,
and
so,
but
I
mean
there
are
just
so
many
use
cases
as
star
shaking
has
now
been
rolled
out.
You
know,
mandates
are
passed
here
in
the
us
and
so
on.
G
G
My
only
hesitation
is
that
it's
quite
a
lot
like
it's
quite
a
big
change
and
it's
a
reasonable
amount
of
work
to
do
all
of
it
and
get
it
all
adopted
and
working
and
I'd
like
to
be
a
bit
more
confident
that
people
are
actually
going
to
find
use
of
it
like
because
it
would
be
quite
easy
to
standardize
something
like
this
and
just
no
one
ends
up
using
it,
but
also
it's
quite
cool,
so
maybe
they
will
just
use
it
but
yeah.
I
don't
really
know.
C
Yeah
I
mean,
like
I
said
I
do.
I
do
recognize,
it's
a
lift.
I
think
the
motivation
for
that
lift
is
going
to
come
from
these
silos
that
actually
require
it
right.
This
is
something
that,
if
emergency
services
requires
this,
if,
like
big
banks,
been
powerful
enterprises
that
have
a
lot
of
leverage
with
carriers
and
that's
what
carrier
vendors
require
it
government
agencies
require
it
so
that
we
can
stop
some
of
these
irs
scams
and
things
like
that.
I
mean
it
the
the
actual
drive
for
it
will
have
to
come
from
them.
A
I
want
to
promote
a
comment
that
robert
made
in
the
chat
into
the
audio,
which
is
we've
talked
about
this
before
we've
pretty
much
agreed
to
go.
Do
this
in
previous
conversations,
so
yeah
we're
kind
of
taking
a
check
on
that
now,
but
unless
one
someone
has
some
strong
opinion
that
we
should
change
our
path,
we've,
which
already
wanted
to
do
this,
we
were
just
waiting
for
the
charter.
E
E
E
So
I
think,
hopefully
we're
in
a
pretty
solid
path
forward
now,
and
I
think
you
know
it
was.
I
think
we
had
a
lot
of
great
discussion
and
good
collaboration
and
ended
up
in
a
good
place
on
this.
So
you
know,
let
me
know
if
there's
any
questions
or
comments
related
to
the
changes
I
made
but
and
if
I
incorporated
everybody's
thoughts
correctly,
but
otherwise,
hopefully
we're
we're
set
to
to
move
on.
H
G
G
E
I
think
there's
certainly
potential
danger
in
that,
although
I
don't
think
people
are
used
to
dealing
with
multiple
or
early
enough
that
people
aren't
used
to
well,
I
guess
that
doesn't
matter
whether
there's
multiple
or
not,
I
guess
you
know
personally.
I
question
how
much
risk
there
is
for
the
for
this
situation,
but
you
know
I
certainly
understand
and
support
the
ability
to
strip
it
at
the
authentication
service
that
sent
that
so
yeah.
G
E
I
I
mean
this
is
just
usually
when
we
want
to
do
something
like
this.
We
we
add
some
kind
of
options,
mechanism
that
lets
the
downstream
entity
know
the
upstream
entity
know
if
the
downstream
entity
can
do
deal
with
it
and
maybe
there's
something
we
could
do
here
and
then
you
wouldn't
send
it
unless
it
was,
unless
the
other
end
implemented
and
it
was
prepared
to
handle
the
security
stuff.
I
A
E
E
I
created
a
a
pretty
lengthy
checklist
of
items
to
make
sure
I
fixed
in
the
document,
and
hopefully
I
cover
them
all,
and
I
tried
to
enumerate
them
in
the
slides
here.
So
we
can
go
through,
there's,
probably
a
few
that
hopefully
are
straightforward.
A
few
that
may
have
some
more
discussion
points,
but
let's
go
for
it.
E
E
A
E
C
C
Do
we
really
wanna
like
have
these
mind,
bodies
be
inserted
by
intermediaries,
potentially
right,
and
you
know
that
that's
always
made
me
a
little
uncomfortable
about
that,
because
we
don't
the
use
cases,
we're
envisioning
for
a
lot
of
these
at
least
aren't
ones
where
it's,
the
actual
originator
of
the
invite
who's
gonna,
be
the
one
that's
generating
it,
but
we
could
also
argue
that
protocol
purity
shift
is
longs
and
sale.
There's
like
absolutely
no
reason
we
should
be
worried
about
that.
Like
I,
I
would
be
fine
with
it
being
cid.
C
You
know,
I
think,
then
the
question
becomes
like
what
the
integrity
protection
properties
of
that
are
right,
and
you
know
if
we're
concerned
about
that
potentially
being
altered
in
transit.
Some
somebody
putting
you
know,
advertisements
or
something
like
you
know,
into
jay
card,
as
the
message
goes
by
or
something
like
that.
If
we
can
like
those
things,
then
I
think
it's
it's
doable.
E
A
My
impression
is
that
operators
and
such
that
are
likely
to
actually
use
rcd
are
still
really
figuring
out
how
they
want
to
do
some
things
and
I
I
would
be
hesitant
to
take
cid
off
the
table
just
yet
maybe
they'll
use
it.
Maybe
they
won't,
but
it
would
be
inconvenient
for
them
to
come
back
later
and
say
hey.
You
know.
We
really
wanted
to
use
that.
I
guess
you
know
we
can
always
update
rvs.
E
E
C
Yeah
yeah,
I
I
mean
so
you're
pointing
at
the
data
url,
it's
an
interesting
one
too,
because
of
course
you
could
encode
the
entire
j
card
as
a
data
url
and
like
embed
it
in
like
the
in
the
call
info
header
itself
right,
which
is
ugly
and
appalling,
and
we
shouldn't
do
that.
I'm
I'm
afraid.
That's
the
kind
of
thing
people
will
do
if
we
don't
provide
like
some
way
for
this
to
work
a
bit
more
responsibly.
C
I
I
Info
in
emergencies,
a
lot
to
pass
information
between
pieces
that
get
added
to
an
emergency
call
as
it
gets
processed
through
the
system,
and
we
uniformly
allow
cid
as
well
as
https,
and
that's
it
I
mean
it's
https
or
cid.
You
get
exactly
the
same
data.
It's
just.
Is
it
come
in
line
or
is
it
com
it's
by
value
or
by
reference?
That's
exactly
how
we
describe
it.
E
E
I
E
E
E
E
You
know
things
about
reflecting
the
same
values
in
j
card
those
types
of
comments,
so
I
really
just
added
you
know
similar
to
namm,
that
apn
must
be
used,
so
there
must
be
a
like
if
you're
intending
for
an
alternative
number
to
be
displayed,
then
you
must
include
it
in
apn
and
not
rely
on
people
also.
You
know
going
into
the
jcl
and
that's
specific
to
you
know
for
supporting
textual
clients
and
things
that
may
not
want
to
go
into
the
j
card
or
support
j
card.
E
E
E
E
E
E
E
E
I
think
I
actually
shared
on
the
list
what
I
proposed
in
the
text
and
then
obviously
in
the
document
that
I
uploaded,
which
is
specifically,
I
added
the
last
paragraph
here,
so
this
was
sort
of
my
compromise
proposal.
I
got
some
support
for
that.
I
think
maybe
some
question
marks
any
comments
that
anybody
wants
to
mention
here.
G
G
A
I
agree
with
jack
here
we
had
some
email
discussion
after
your.
I
guess
I
think
it
was
after
the
last
revision
and
I
had
made
a
proposal
that
I
don't
remember
the
exact
words
but
along
the
lines
of
there's
really
two
separate
kinds
of
verification
here,
one
is
to
verify
that
your
passport
is
correct
and
that
verification
is
you
verify
the
signature.
You
verify
the
jwt
claims
constraint
and
a
passport
that
meets
those
requirements
is
verified.
A
A
So
I
think
I
had
better
words
around
this
in
the
email,
but
the
general
idea,
I
think,
is
to
actually
divide
this
up
into
two
steps
where
and
the
dependency
is
only
one
way
right,
so
verification
of
the
passport
itself
is
not.
It
is
not
dependent
in
any
way
on
the
integrity
being
correct.
All
it
does
is
verify
that
hey
this
rcdi
hash
value
is
the
value
they
put
in,
and
then
you
have
a
separate
step,
which
does
depend
on
having
a
verified
passport,
which
is
the
integrity
check
itself.
C
Yeah,
the
last
sentences
here
are
trying
to
say
roughly
that
then
in
the
sense
of
you
know,
because
it's
not
about
full
verification
versus
something
else
right
and
like
I,
I
I'm
a
little
hesitant.
You
know
to
figure
out
how
we
want
to
draw
the
line
on
this,
and
this
is
like
a
fundamental
ambiguity
and
start
shaking.
It's
been
around
forever
right
of
what
what
it
really
means
for
this
thing
to
be
verified
and
what
you're
supposed
to
do
with
that.
I
think
the
interesting
part
of
rcd
is
that
it.
C
You
know
it's
kind
of
more
actionable
than
some
of
the
previous
ways
that
we've
talked
about
verification
in
a
pre-rcd
environment
where,
like
you
know
it
used
to
be
it's
just
kind
of
like
okay.
If
the
call
is
verified,
then
it
goes
into
carrier
policy,
engines
or
people
translate
into
veristats
or
whatever
this
more
fundamental
question
of.
Are
these
links
in
it
going
to
be
rendered
to
users?
Are
they
safe
to
be
rendered
to
users
and
to
like
show
up
on
their
display
on
their
mobile
device?
C
When
they're
being
alerted,
I
mean
we
don't
want
to
be
prescriptive
about
that,
though,
for
the
same
reason,
we
don't
tend
to
be
prescriptive
about
what
you're
supposed
to
do.
When
you
decide
something
is
verified,
so
I
mean
I
think
this
in
some
ways
this
is
the
semantic
you
know
question
what
what
we
consider
to
be
verification
or
full
verification,
or
do
we
want
to
split
it
into
an
explicit
stage,
one
and
stage
two,
but
you
know,
I
think,
where
the
difference
is
material.
C
Is
that
question
of
are
we
recommending,
or
at
least
are
we
considering
these
rules
to
be
safe,
to
render
to
a
user?
A
policy
allows
that
and
like
that.
That
may
be
a
place
to
draw
that
distinction
that
I
I
at
least
understand
what
it's
supposed
to
mean,
because
I
mean
just
kind
of
saying:
well,
we've
got
a
couple
different
things
that
verification
could
mean
and
carriers
without
what
you
will
or
whatever
you
know.
I
I
I'm
not
sure,
is
appropriate
for
where
we're
going
with
rci.
E
E
Is
it
right
to
look
at
that?
You
know.
Are
you
looking
at
the
total
picture
there
of
verified,
or
you
know
you
know,
are
you
saying
only
well
the
telephone
number
passes.
So
so
it's
okay
that
that's
the
part
I
struggle
with.
I
think,
if
you're
sending
any
information
you
have
to
look
at
it
holistically,
but.
A
That's
that's
going
to
really
confuse
people
if
we're
not
careful
here
and
that's
why
I'm
trying
and
proposing
that
integrity
verification
has
is
not
part
of
passport
verification
at
all.
They
are
two
distinctly
separate
things.
What
passport
verification
does
is
verify
the
contents
of
the
passport
and
the
signature
etc.
A
E
E
Can
can
I
just
quick
comment?
My
fear
is
that
people
won't
take
the
integrity
stuff
seriously
and
you'll
have
a
mailbox
that
gives
the
shaken
at
a
station
a
based
on
the
phone
number
and
people
are
going
to
pass
risk
rich
call
data
and
they're
not
going
to
check
the
integrity
and
therefore
it's
going
to
be
a
huge
security
hole
because
people
are
going
to
pass
whatever
logos
they
want
and
it's
not
going
to
get
verified
on
the
other
side.
E
A
E
G
And
the-
and
I
feel
like
frequently
the
verification
service
is
not
the
thing
that
is
actually
rendering
the
things
at
the
urls,
which
means
the
like.
The
integrity
is
quite
separate
and,
like
the,
in
my
view,
the
thing
in
the
passport
like
the
text
of
the
urls
is
what
the
passport
is
verifying
and
like
the
contents
of
what
you're
of
what's
at
those
urls
is
so
vague
and
indistinct.
That,
like
the
only
thing
that
could
realistically
do,
that
is
the
thing
at
the
end,
and
so
it
should
be
more
explicit
like.
E
I
recognize
that,
but
the
verification
service
that,
like
you,
said,
that's
actually
rendering
retrieving
the
url
and
actually
going
to
render
it
in
a
trusted
space
because
it
did
the
entire
verification.
That's
the
thing
that
we're
talking
about,
and
maybe
that's
the
thing
I
can
clarify
in
the
text
so
that
that
I
don't
disagree
with.
E
C
Okay,
so
stir
messaging,
I'm
gonna
do
this
real
quick.
So
there
was
an
update
to
the
storm
messaging
draft
for
those
of
you
that
are
just
joining
us
on
this
one.
This
is
looking
at
providing
store
protection
for
a
set
of
use
cases
for
either
real
time
tech
session
negotiation,
which
encompasses
things
like
rcs
as
well
as
kind
of
sending
individual
messages.
C
Why
are
we
doing
this
because
message?
Spam
is
becoming
a
big
problem
and
really,
it
seems
to
make
little
sense
to
develop
like
a
separate
pki
for
messaging,
that
is
using
telephone
numbers
when
we've
already
built
this
stuff
out
for
stir.
But
this
is
just
to
be
clear.
It's
kind
of
speculative
work
in
the
sense
that,
although
there's
some
interest
in
exploring
this,
it's
not
like
you
know,
they're.
C
The
the
messaging
ecosystem
is
incredibly
diverse
and
filled
with
lots
of
legacy
craft
that
never
touches
sip
and
would
be
very
difficult
for
us
to
arrogate
to
ourselves.
But
we
still
think
especially
given
some
of
the
fcc's
recent
comments
about
this
problem,
that
we
should
have
a
story
for
it
for
how
it
will
work
with
stir,
as
I
suggested.
C
There's
kind
of
like
two
paths:
you
know
you
can
obviously
negotiate
with
sdp
any
kind
of
media
stream
security
that
you
would
like
using
mechanisms
that
look
a
lot
like
our
sip
brandy
stuff,
which
was
devised
for
voice,
but
basically
all
the
same
principles
would
apply
to
negotiating
an
msrp
session
or
something
like
that
and
then
there's
individual
message.
Security
brian
will
tell
us
that
this
is
useful
for
some
emergency
services
applications.
C
Our
proposal
is
basically
to
protect
these
messages
at
the
mime
level
to
have
a
message
digest
that
will
cover
them
and
that
will
become
part
of
a
new
message
eye
very
similar
to
rcdi
element
that
will
appear
in
passports
that
are
of
this
new
message:
powerpoint
type.
We
really
put
this
as
a
pretty
pat
answer,
we're
just
like
we're
gonna.
C
So
what
else
is
new?
In
this
version
we
added
some
security
and
privacy
considerations
a
lot
of
that
just
referencing.
The
numerous
other
places
that
we
have
discussed
this
we
added
a
little
bit
of
text
about
message
conferencing.
This
is
one
of
the
longer
polls
in
the
tent
when
you
look
at
something
like
msrp,
of
course,
we've
endlessly
studied,
centralized
and
decentralized
conferencing
applications
for
sip.
C
We
do
know
we'll
need
connected
identity
for
that,
and
my
current
proposal
is
basically
to
kick
most
of
the
work
that
would
need
to
be
done
to
make
that
into
the
connected
identity
draft
itself,
as
that
goes
forward
and
kind
of
leave
this
as
a
pretty
simple
draft
that
just
kind
of
provides
the
tools
that
implementers
go
kick
around
and
see
if
it
looks
like
it
might
be
useful.
I
did
add
some
text
on
cpam
ben.
A
I
don't
know
that
I
have
an
answer
to
that
question.
The
only
thing
I
comment
I
had
is
there
is
a
discussion
of
this
somewhat
in
the
what
85.
I
can't
remember
the
draft
that
russ
and
I
did
a
while
back
rfc8
wrestling.
I
did
a
while
back
yeah,
but
and
we
do
reference
that
in
in
the
span
right,
but
the
cpm
discussion
goes
further
than
what
is
mentioned
in
in
this.
A
J
Hey
john,
I
think
this
is
like
great
to
see
you
working
on
this.
Can
you
talk
a
little
bit?
What
do
you
think
the
relationship
with
mls
is,
you
know,
obviously
on
you
know
these?
These
are
all
in
the
same
space
and
which
might
be
nice
if
there
was
a
way
if
like.
If
you
know
there
wasn't
a
break
point
between,
like
you
know,
sms
or
sms
style,
stuff
and
and
others
investing
applications
yeah
I
mean,
I
think.
J
I
Ryan,
this
clearly
would
be
useful
to
us
in
emergencies
we
treat
msrp
is
what
we
actually
use
and
it's
treated
like
a
call
and
has
all
the
same
spam
and
swatting
issues
that
we
have
with
calls
and
if
we
lock
down,
if
we
lock
down
calls-
and
we
don't
lock
down
messages,
that's
just
a
vector
for
people
to
exploit.
So
we'd
really
like
to
have
this.
We
do
use
msrp
and
we
gateway
sms
to
msrp.
That's
been
done
for
quite
a
while
now,
so
msrp
would
work
for
us
as
long
as
we
can.
I
C
It
wouldn't
be
too
different.
Ben
also
raised
on
the
list,
the
question,
a
question
about
store
and
forward,
especially
for
the
message
side
of
this,
which
raises
a
lot
of
familiar
semantic
questions
about
what
means
to
be
for
a
message
be
delivered
in
intermediate
like
texting
system
like
this
as
opposed
to
red.
J
J
I
From
its
point
of
view,
it's
just
it's
a
unicast
line
going
out
that
has
stuff
done
to
it.
That's
probably
not
stable
for
a
very
long
time.
That
is
where
we
are
now,
because
nobody
implements
multi-party
msrp
in
any
particularly
great
way
right
now,
if
that
happened
so
that
you
know
we
started
doing
chat
with
msrp
in
in
deployed
systems,
then
then
our
opinion
would
change,
but
right
now
it's
not
a
big
deal
and
punting.
It
is
fine.
C
Yeah
I
mean
anything
uses
centralized
conferencing
that
can
actually
proxy
through
a
passport,
and
the
passport
will
still
validate
on
the
other
side
of
it.
I
think
we'll
be
fine.
It's
just
a
question
of
anything
that
has
to
munch
that
I'm
worried
about
and
like
whether
your
desk
needs
to
contain
your
total
targets
at
the
start
or
whether
you
know
those
are
the
things
there's
actually
some
considerations.
I
did
put
in
this
draft
about
that
point.
In
particular,
okay,.
E
Great
yeah
john
and
I
talked
about
this,
but
I
think
it's
probably
better.
I
think
it's
something
we
can
do
and
probably
can
do
sooner
rather
than
later,
but
I
think
just
from
the
industry
swallowing
things.
It
might
be
good
just
for
this
document
to
keep
it
simple
and
then
maybe
have
something
separate
that
considers
conferencing
scenarios
more
generally,
and
maybe
mls
is
another
case
to
consider
that
could
be
part
of
that
whole
framework.
Also.
C
We
are
out
of
time,
I
think,
we're
you
know
again.
If
we're
not
going
to
do
any
major
surgery
and
mls,
you
know
hopefully
wouldn't
be
major
surgery.
I
think
we're
pretty
close
to
working
good
last
call
here.
Why
don't
I
circle
around
with
richard,
which
I
was
seeing
you
in
in
the
text
there
in
the
chat
and
echo
a
bit
on
what
we
might
want
to
do
to
just
at
least
draw
a
line
for
this
is
this
would
be
the
basic
principles
you're
going
to
use
mls
with
this.
C
But
you
know
to
ben's
point
in
the
chat
and
what
I
said
earlier.
This
is
getting
some
attention
at
the
moment
like
the
fcc
is
turning
their
baleful
gaze
to
messaging,
because
the
problem
is
becoming
quite
quite
a
bit
worse
in
the
u.s
at
the
moment
and
again,
I
I
would
just
hate
to
see
somebody
try
to
completely
reinvent
the
wheel
around
this
for
a
telephone
number
based.