►
From YouTube: IETF111-STIR-20210729-1900
Description
STIR meeting session at IETF111
2021/07/29 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
B
B
C
D
D
D
D
Yeah,
so
just
generally,
if
folks
paid
attention
to
last
week,
there's
there
actually
is
a
lot
of
industry
discussion
going
on
about
rcd,
which
is
great
people
are
implementing
it,
and
so
I
think
we've
gotten
good
feedback
and
we've
incorporated
a
lot
of
that.
So
I
think
we're
fairly
confident
that
we're
in
a
good
state.
D
I
did
not
refresh
the
zip
core
document
yet,
but
I
I
don't
anticipate
any
other
changes
there.
Although
I'll
explicitly
ask
the
question
on
the
list
after
this,
unless
anybody
has
any
comments
today
about
that
document
as
well,
but
other
than
that,
I
think
we're.
I
believe
we're
ready
to
go
back
into
working
group
last
call
if
everybody.
D
B
A
D
D
A
F
A
G
C
C
Logical
extension
really
of
the
notion
that
if
we
have
certification
authorities
that
are
already
giving
search
providers
authority
over
telephone
number
ranges,
number-based
messaging
seems
like
it
might
be
able
to
benefit
from
that
in
some
dimensions,
and
you
know
messaging
is
always
you
know.
I've
been
working
on
messaging
for
20
years
in
various
capacities
like
I
I'm.
A
veteran
of
the
im
wars
back
in
the
day,
like
messaging,
has
always
been
very
fragmented
and
a
difficult
thing
to
get
your
hands
on
around.
C
And
really,
you
know
what
this
draft
outlines.
Broadly,
is
two
paths
firster
to
work
with
messaging.
The
first
really
just
uses
stp
negotiation
in
precisely
the
same
way
that
telephone
calls
do,
and
so
you
know
anything
that
is
rcs
like
which
uses
negotiated.
You
know
stp,
basically
to
set
up
sessions
or
rtt
like
them
is
potentially
in
scope
from
the
first
path
of
this,
and
you
know
there
are
there,
there's
been
a
lot
of
work
on
that,
a
lot
of
implementation
of
that.
So
I
think
that
it's.
C
Now.
I've
added
a
bit
of
tax
to
this
version.
That
basically
just
says,
protect
my
in
these
messages,
and
you
know
right
now:
it's
pretty
underspecified
or
I
guess
I
should
say
it's.
You
know
taking
the
a
blanket
approach.
It's
if
there's
a
my
multi-part
body
and
one
of
those
things
is
a
message
of
some
kind.
Don't
just
hit
the
message
mind
body
hit
the
entire
mind
multiply.
Just
just
do
it
dead
simple!
Is
that
I
would
be
curious
if
he
has
any
feedback
on
that
ben
you're
you're
up
already.
C
G
C
Yeah
I
mean
I'd,
be
happy
to
just
include
a
pointer
to
it
and
say
that
the
same
considerations
will
apply.
To
that
I
mean
it's
out
of
curiosity,
I
mean:
are
these
cpemish
systems
in
pat
in
path,
two
not
path
one,
because
I'm
aware
there's
a
lot
of
like
cpm
and
like
rcs
right
but
like
it
that
that's
not
yeah.
I
think
it.
G
B
G
C
Yeah
and
I'm
going
to
talk
about
multi-user
chat
in
a
minute.
Certainly
I
keep
hearing-
or
I
guess
I've
heard
in
the
last
week
or
two-
that
you
know
that
rcs
is
gathering
momentum
and
that
people
are
much
more
hopeful
about
its
prospects
than
they
were
the
last
time
we
all
got
together
and
discussed
this,
and
so
we
I
we
do
at
some
point
like
need
to
talk
to
the
gsma
about
this
right,
and
I
don't
know
if
that
means
a
formal
liaison.
C
I
mean
I
I
work
there
in
other
groups,
and
so
I
mean
I
I
think
I
know
the
right
people
that
ask
to
get
into
that
conversation
if
we
feel
like
it,
but
definitely
we
need
the
understanding
of
the
use
cases
that
are
relevant
to
this.
I
would
probably
be
content,
though,
really
just
to
reference.
The
considerations
and
the
existing
draft
that
ben
you
and
russ
did
and
say
that
the
same
considerations
will
apply
to
any
cpim
like
usage
in
path.
Two.
C
H
H
C
C
C
C
C
I
also
ruthlessly
excised
some
tbd's
and
even
wrote
like
a
little
bit
of
security
considerations,
so
obviously
we're
going
to
need
more
of
that
and
I
suspect
we
might
even
need
some
privacy
considerations
just
given
what
it
is.
That's
in
transit-
and
I
I
don't.
I
don't
think
that
there
is
some
huge
privacy
risk
that
is
added
by
merely
having
a
digest.
C
2.
I
think
things
just
work
like
because
you
know
for
any
system
where
you're
just
kind
of
multicasting
your
message
method
out
to
a
group
chat
list.
Every
message
gets
signed
as
is
appropriate,
and
so
I
don't,
I
don't
think,
there's
a
lot
that
we
need
to
mull
about
path
to.
But
this
is
another
one
I
wanted
to
throw
the
group
I
mean:
does
anybody
have
any
thoughts
about
this?
In
terms
of
you
know
the
difference
between
the
two
approaches,
ladies,
have
anything
for
path
to
that.
C
C
D
C
Yeah,
I
know
that
that's
a
very
good
point
and
for
path,
two
that
might
even
get
us
around
some
of
the
difficulties
here,
because,
of
course,
all
the
authentication
service
needs
to.
It
just
needs
to
see
the
desk
list
right
and
to
be
able
to
look
at
that
array
and
sign
for
it,
because
the
only
thing
it
needs
to
have
authority
for
is
the
identity
of
the
sender
of
each
individual
thing.
I
think
where,
where
it
gets,
hairier
is
when
again,
there's
there's
some
exploder
right.
C
C
Okay,
yeah,
I
mean
there
are
so
there
are
considerations
for
path
2
and
we
would
need
to
record
those-
and
I
hope
these
are.
This-
is
all
being
minuted.
So
we
can
make
sure
what
it
is
that
we
need
to
record,
but,
like
the
yeah,
this,
this
question
of
who
who
needs
to
do
the
signing?
Does
that
signing
thing?
D
Oh
sorry,
I'll
go
chris,
I
was
gonna
mention
before
it's
really
sort
of,
and
I
and
I
think
your
comment
about
connected
identity.
Maybe
answers
the
assumption
there,
but
are
you?
Are
we
assuming
that
the
sender
does
explicitly
know
all
the
destinations
of
their
messages
or
is
that
in
the
conferencing
part
of
it-
or
you
know
things
like
that,
so
we
need
to
probably
be
very
explicit
about
those
things.
C
I
mean
what
what
what
this
is
leading
me
to
is
that
for
path
2.
We
also
need
to
talk
about
centralized
versus
decentralized
conferencing,
so
in
a
decentralized
conferencing
model
right
I
mean
the
ue
or
effectively
something
adjacent
to
it
knows
the
group
chat
list
itself
and
for
those
kinds
of
cases
you
know
I.
I
think
this
should
work
fine
for
any
case
where
there
is,
though
some
exploder,
basically
more
centralization
to
it,
that
that
could
get
hairy
just
because
guests
will
fail
if
the
center
doesn't
know
them.
Roman.
F
The
other
consideration
is
all
the
matching
because,
for
instance,
if
you
again
with
explorer,
if
you
have
a
destination
id,
which
is
some
number,
which
is
a
group
and
then
it
goes
to
a
whole
bunch
of
numbers
which
are
actual
individual
subscribers,
the
sender
have
no
idea
what
the
subscribers
are
and
like,
but
the
subscriber
actually
might
know
that
this
is
the
destination
number
which
it
needs
to
accept
and
match.
So
that
might
be
another
yeah.
We.
C
F
The
other
consideration
is
there
a
whole
bunch
of
like
messaging
scenarios
where
identity
is
hidden
but
still
needs
to
be
like
it's.
It's
a
verified
sending
party,
but
the
actual
caller
is
somehow
needs
to
be
hidden
in
some
sort,
and
I
don't
know
if
we
just
assume
that
it's
verified
by
us,
because
I
can
with
ours
with
a
lot
of
those
scenarios.
The
messaging
is
end-to-end,
unlike
phone
calls
where
it
goes
to
a
carrier,
gets
verified
and
just
passed
with
some
sort
of
verified
header
in
a
lot
of
flickers.
F
C
Yeah
I
mean
again
and
a
lot
of
that
will
come
down
to
ue
versus
who
does
it
right
like.
If
it's
me,
we
can
probably
use
traditional
anonymization
techniques
to
protect
it
and
there's
plenty
of
stuff
in
8224
about
that
right,
but
like
if
we're
expecting
some
exploder
to
be
the
one,
that's
concealing
these
identities
like
then,
you
are
basically
just
in
a
centralized
conference
right
and
like
honestly,
you
should
be
using
like
sip
event
packages.
You
know
to
communicate
to
the
participants
in
the
conference
what's
going
on
or
something
like
that.
F
And
the
last
consideration
again
is
just
especially
for
the
path
to
is
like
how
much
additional
like
how
much
it
increases
the
message,
size
and
the
actual
complexity
of
processing
individual
messages,
because
again
for
path,
one.
It's
leveraged
across,
like
a
large
message
of
conversation
here,
it's
actually
per
message
can
be
significant,
like
additional
vote
on
the
messaging
system.
C
C
C
Well,
that's
why
I
was
talking
about
div
right,
I
mean
I
think
div
may
be
the
answer
to
at
least
some
of
the
exploder
things.
I
I
you
know
provided
that
the
thing
you're
sending
out
to
the
exploder
is
basically
a
pseudo
number,
and
I
I
I
gathered
like
rcs.
Basically
does
this
right,
where
there's
like
some
group
chat
id
that
you
register
or
whatever,
and
then
you
send
your
messages
to
that
and
it
sends
it
to
the
appropriate
message
service.
The
message
service
is
responsible
for
exploding
like
for
any
case.
C
C
Okay,
I
mean
it's,
you
know
on.
We
see
div
in
production
now
by
the
way
which
shocked
me
like
since
june
30th
in
u.s.
I
see
u.s
production
traffic
with
divs
in
it
which,
like
I
I
was
surprised
to
see
so
I
mean
it
may
be.
That
will
start
getting
some
some
uptake
at
this
point.
There
may
also
be
some
other
ways
to
do
that
that
wouldn't
require
using
div.
Like
I
said,
I
mean
a
lot
of.
It
really
comes
down
to
exactly
how
you
implement
this.
C
H
Well,
I
I
just
remind
you
that,
although
there
certainly
are
carrier
message,
exploder
services,
the
vast
vast
vast
majority
of
exploders-
are
just
customers
of
carriers.
You
send
the
message
to
a
telephone
number.
You
get
a
message
from
the
telephone
number
and
that's
all
there
is
so
you
know,
99.9
of
the
cases
are
going
to
be
covered
by
this.
I
think
so.
Yes,
there
might
be
some
cases
that
aren't,
but
most.
C
Are
yeah
I
mean
I
I'm
aware
you
know,
and
part
of
this
is
just
things
like
carriers
want
to
be
able
to
manage
maximum
group
sizes
and
things
like
that
and,
like
you
know
so
they're,
so
they
have.
This
has
to
go
through
some
kind
of
policy
service
for
it
to
interoperate
properly,
and
so
I'm
aware
of
what
the
use
cases
are
that
motivate
there
to
be
some
kind
of
an
exploder
in
this
but
yeah.
I
definitely
agree
with
you
that
this
this
is.
These
are
corner
cases.
C
Okay,
given
that
let
us
move
on
and
so
yeah
we've
got
a
couple
open
issues
to
resolve.
We
definitely
need
to
say
a
bit
more
about
conferencing
and
we've
had
some
review
in
this
document.
I
think
at
this
point
moore
is
probably
welcome.
I
don't
think
this
needs
to
be
a
terribly
complicated
or
elaborate
document,
so
I
mean
I,
I
think,
given
another
rev
or
two,
we
should
be
aiming
for
working
group
class
call
of
dust.
I
mean,
I
think,
fortunately,
most
of
what
we
want
to
say
about
it.
C
C
G
G
G
It
has
a
lot
of
gateways.
You
know
where
you've
got
email
to
message.
Sms
gateways
and
you've
also
got
things
like
the
short
codes,
at
least
in
the
us,
where
you
get
messages
from
some
business
that
is
coming
from
a
it's
a
number,
but
it's
not
a
globally
routable
number.
It's
basically
from
a
dialing
plan
yeah,
and
I
just
I'm
not
saying
that
that
we
just
had
have
to
go
fix
all
this.
C
Yeah,
I
mean,
I
think
I
think
it
works
for
sip
like
identifiers,
I
mean
you
know
our
obviously
rc
4474
was
not
telephone,
number
specific
and
really
8224
isn't
either.
You
know,
I
I
think
the
the
slippery
slope
that
I
fear
in
this
is
precisely
what
you
you
mentioned
there
like
email
gateways
and
things
like
that,
and
then
we
get
into
what's
the
interaction
with
like
deacon
or
whatever
right,
and
you
know
I.
C
C
Historically,
however,
I
would
say,
like
really
disturb,
like
the
authentication
service
concept
and
stir
predates,
as
far
as
I
know
like
most
of
that
work.
But
let's
that's
neither
here
nor
there.
You
know.
I
I
just
I'm
concerned
about
what
the
interplay
is,
especially
because
the
properties
of
those
email
systems
are
not
aimed
to
be
end
to
end
right
and
like
they're,
very
hot,
by
hop
and
store
and
40
and,
like
you
know,
they
have
a
lot
of
properties.
C
G
No
rebuttal
at
all,
I'm
just
trying
to
take
notes
now
the
the
and
strike
the
burn
from
the
stake
from
the
record.
I
I
didn't
actually
get
to
that
part,
I'm
trying
to
condense
stuff,
but
the
I
agree
with
you
and
the
collision
between
email
mechanisms
and
store
mechanisms.
I
think,
will
be
ugly.
I
do
agree,
I
like
story
better,
but
that's
why
we're
all
in
this
room,
not
somewhere
else.
G
C
C
Are
that
have
some
unusual
properties,
but,
like
I,
I
personally
wouldn't
be
that
worried
about
like
signing
for
a
short
code
as
an
identity
and
I'd
also
remark
that,
like
I
mean
I
think,
10
dlc
is
getting
a
lot
more
traction
these
days
than
it
has
in
the
past,
especially
for
some
of
these
enterprise
messaging
use
cases,
and
so
you
know
I
I
think
this
works
great
for
10
dlc.
It's
probably
fine
for
short
codes
and,
like
I
email,
seems
like
a
much
different
problem
to
me
than
dealing
with
codes.
D
D
The
other
one
is
maybe
related
to
a
potential
charter
discussion
that
we
have,
whether
or
not
we
want
to
bring
those
things
generally
into
scope
of
stir
or
not.
You
know
I'm
not
hard
set
against
it,
but
I
think
we
do
want
to
make
sure
we're
considering
those
things
in
terms
of
maybe
broader
history
progress,
so
just
something
to.
C
Think
about
I
mean
the
the
I
mean,
so
a
lot
of
what
she
can
really
accomplishes
right
is
the
ga,
the
pa,
the
system
for
figuring
out
like
who
should
be
allocated
credentials
and
why
and
for
email
style
identifiers.
We
know
the
answers
to
those
questions
already
right,
and
so
I
mean
it's
really
a
question
of
whether
the
endpoints
that
rely
on
shaken
who
would
be
willing
to
trust.
C
You
know
a
verizon
insert
right
for
like
apple.com
or
something-
and
I
think
you
know
I
I
could
imagine
that-
would
be
a
complicated
ga
discussion
which
obviously
we're
not
gonna
speculate
about
here
too
much,
but
certainly
I
don't
think
what
the
outcome
would
be
from
an
itf
perspective.
Of
that
discussion
is
oh,
we
need
a
whole
new
set
of
cas
that
are
gonna
give
identifiers
for,
like
you
know,
email
style.
D
C
C
C
If
you
want
to
be
able
to
get
an
assurance
of
which
party
was
reached,
then
you
need
to
have
some
way
that
a
request
can
be
sent
in
the
backwards
direction
that
can
actually
have
a
passport
in
it,
and
there
are
a
variety
of
attacks.
I'm
aware
of
that,
especially
exist
in
the
mobile
space
route.
Hijacking
short
stopping
attacks
along
those
lines
that
require
basically
both
parties
to
communication
or
the
service
providers
and
poll
parties
to
a
communication
to
be
able
to
mutually
share
identities.
C
So
basically,
this
is
making
something
that
would
look
like
a
mutual
stir,
and
this
is
significant
because
the
original
threat
model
of
stir
was
not
about
this
like
this
is
why
we're
gonna
have
a
charter
discussion.
At
the
end
of
this
presentation,
because,
like
the
original
threat
model
of
stir,
very
much
is
about
who's,
sending
invites,
and
you
know
whether
or
not
you
should
pick
up
the
phone.
That's
what
the
basic
robocall
case
is
and
taking
this
to
connected
identity.
C
Is
it's
different
right
and
like
we
need
to
acknowledge
that
that
changes
the
scope
of
these
things
fundamentally,
but
nonetheless,
the
mechanisms
required
the
certs
required
passports
required,
are
all
the
same
and
like
there's
really
no
reason
to
do
this.
If
we
think
it
could
close
some
fraud
loopholes,
I
just
want
to
make
it
so
like
buys
that
are
sent
to
tear
down
calls
right,
like
things
like
that,
like
can
be
signed
and
can
be
signed,
especially
in
more
complicated
cases
where,
like
call
forwarding,
has
happened.
C
C
C
C
Basically,
this
is
the
part
I
fleshed
out
a
bit,
and
the
fundamental
premise
here
is
that
you
send
an
invite
with
no
stp
that
has
an
identity
headers
when
it's
asserting
what
your
identity
is
and
then
have
like
100
require,
and
we
just
kind
of
accept
that
the
intended
semantics
of
that
is
a
request
for
pre-call
connected
identity
to
establish
a
medialis
dialogue.
You
do
the
cracks
and
everything
you
get
the
update
in
the
backwards
direction,
and
then
you
can
elevate
this
to
like
a
voice
session.
C
If
you
know
you
have
decided
that
the
called
party
is
legit,
and
I
think
you
know,
I
certainly
acknowledge,
as
the
second
last
bullet
says
here,
you
know
this.
This
is
not
a
small
lift
in
the
sense
of
you
know.
This
require
a
lot
of
changes
to
a
lot
of
implementations,
but
then
again
you
know
for
a
certain
class
of
businesses
and
institutions
and
financial
services
and
healthcare,
certain
government
agencies.
C
You
know,
I
think
there
there
is
a
demand
for
this,
or
at
least
there's
demand
to
address
this
problem
and,
like
the
I
think,
we
get
some
additional
traction
on
it
by
making
this
mechanism
available,
and
so
you
know
we'll
see
what
the
uptake
of
that
is,
but
you
know
I.
I
think
this
is
a
kind
of
cool
feature
to
do
that
builds
on
the
basic
building
blocks
of
connected
identity.
We
need
to
just
get
normal
scent
to
work
around
stir.
So
robert
sorry.
A
A
C
F
One
other
consideration
is
for
a
lot
of
those
calls
like
from
financial
medical
institutions.
You
actually
have
a
requirement
that
you
need
to
start
talking
to
the
person
within
some
period
of
time
after
the
call
is
placed
and
having
a
dialogue
in
the
opposite
direction
can
actually
run
like.
What
do
you
do
if
you
didn't
get
the
confirmation
back.
C
Yeah
for
emergency
services
that
wasn't
one
of
the
institutions,
the
government
institutions-
I
was
thinking
of
I'm
thinking
more
of
like
the
irs
right
irs
scams-
are
a
very
common
variant
of
this
right,
where
I
want
to
be
able,
when
I
see
a
number
to
get
like
a
vetted
irs
logo.
Yes,
this
is
the
rs
like.
C
That
will
give
me
confidence
about
it
now.
This,
of
course
assumes
that,
like
rcd
actually
is
properly
managed,
and
I
I
guess
I
I'm
already
past
that
in
my
head,
I
think
it
is
possible
to
properly
manage
it,
maybe
foolishly
optimistically
but
like
yeah.
That's
the
basic
idea
is
just
to
be
able
to
give
you
know
for
these
non-emergency
cases.
D
C
I
mean
the
the
good
news
is
like
you
know
these.
These
media
lists
free
call
dialogues.
I
mean
they
don't
like
alert
the
user
right.
It's
not
like
the
phone
rings,
like
a
media.
Pre-Call
dialogue
is
just
established
passively
between
the
the
ues
and
like
then,
when
the
hipaa
side,
the
hipaa
caller,
says
okay,
I
know
I'm
going
to
connect
to
brian
rosen.
F
J
H
So
I
I
think
that
you,
we
should
just
document
the
case
of
placing
an
anonymous
call
getting
the
connected
identity
back
and
then
replacing
that
you
know
reinvite.
With
with
the
with
the
forward
identity
and
and
the
media,
I
mean
that
that
that,
for
a
lot
of
the
cases
you
described,
that
would
work
perfectly
well.
The
bank
is
perfectly
willing
to
do
an
offerless
exchange
with
identity
for
an
anonymous
caller.
C
A
C
A
C
C
It
is
because
it's
it's
rat
hijacking
attacks
or
one
of
the
things
I'm
concerned
about
right.
These
attacks,
where,
like
mobile
networks,
like
somebody
uses
like
a
camel
based
attack
to
you,
know,
make
a
you
know
to
impersonate
a
number
right
and,
like
you
know,
yeah,
I
want
you
to
have
to
provide
a
credential
that
is
going
to
make
it
clearer
that,
like
this
is
not
the
proper
entity,
you
know
to
be
the
recipient
of
this
call,
and
you
can
only
learn
that
from
actually
routing
the
call
to
the
entity.
C
So
we
we
need
to
do
this
anyway.
I
think
you
know
belt
and
suspenders
redundantly
having
a
directory.
That
tells
you
what
you
should
expect
when
you
do.
That
makes
this
like
a
million
times
better,
but
I
I
think
you
know
I.
I
guess
I
view
that
as
kind
of
outside
the
scope
of
this
draft
is
defining
that
directory
or
service.
C
C
C
J
K
Is
that
we
had
a
brief
brief
discussion
also
in
the
chat
that
it
sounds
like
unless
you're
up,
you
know
an
institution
or
something
like
that,
you
probably
want
to
say
you
should
not
send
back
rich
call
data
for
or
for
precalculated
identity.
Otherwise
somebody
could
essentially
just
send
one
of
these
calls
to
you
know
every
number
you
know
to
do
just
do
a
dictionary
attack
on
every
phone
number
and
get
and
construct.
You
know
the
phone
phone
directory
of
who
every
number
in
the
phone
in
the
world
belongs
to.
C
Yeah,
so
I
think
the
rcd
case,
obviously
for
the
institutions
that
really
want
to
be
able
to
tell
consumers.
This
is
bank
of
america.
Right
is
more
applicable
to
that.
But
you
know
I
think,
there's
there's
probably
a
mix
of
some
of
that
discussion.
We
had
earlier
about
of
replies
being
upgraded
when
you
actually
turn
it
into
a
media
session.
C
C
Go
on
this
is
just
a
profit.
We've
already
talked
about
this
enough
conferencing
right,
so
I
did
add
a
little
text
saying:
should
they
think
about
conferencing,
largely
just
based
on
the
stuff
that
I
was
providing
already
for
the
messaging
draft,
and
since
I
was
already
planning
to
like
pump
some
of
that,
basically
to
the
connected
identity
draft
and,
like
you
know,
basically
my
easy
road
proposal,
my
proposal,
it
seems
like
the
least
work,
maybe
ill-advised
work,
but
it's
the
least
work
I
can
think
of.
C
We
could
do
and
get
something
out
that
might
be
useful
is
to
declare
centralized
conferencing
basically
out
of
scope.
In
other
words,
you
know
the
ways
you
learn
about
participants
in
a
centralized
conference
are,
you
know,
are
secured
separately.
They
could
be
a
safe
event
package.
That's
telling
you
really.
All
you
need
is
the
identity
for
each
participant.
C
K
No,
I
didn't,
I
didn't,
I
think
it's
fine.
I
just
wanted
to
also
say
I
think,
there's
there
is
benefit
from
getting
the
technical
identity
of
yes,
you
have
reached
the
conference
bridge,
not
something
else
so
yeah.
This
is
this
is
the
conference,
but
you
know
this
is
webex
or
bitsy
or
whoever
not
you
know
some
random
person.
Impersonating
them
is
is
valuable,
but
that's
just
as
easy.
C
C
K
H
You
letting
you
know
I
I
was
just
gonna
reinforce
exactly
that
that
that
I
I
would
like
to
get
the
rcd
from
you
know.
You
know
pick
a
company
cisco
that
when
I
called
cisco
I
you
know
I
was
on
a
cisco
conference
bridge
that
I
reached
the
cisco
conference
bridge
and
nobody
else,
because
if
I'm
having
a
conversa,
you
know
a
a
a
a
confidential
discussion.
H
H
C
Okay,
I'm
gonna,
I'm
gonna
try
to
get
away
with
it.
I'm
sure
the
security
ads
will
love
it.
Okay
next
slide
still
to
do
so.
You
know
49
17,
had
some
beautiful
examples
have
been
done
about
this
I'll
have
some
examples
generated
from
our
implementation
when
we
think
this
is
stable,
that
we
can
put
into
it.
You
know
there.
I
haven't
gone
through
like
a
normative
revision
change
log,
because
I'm
not
treating
this
as
abyss.
Yet
I
guess
that's
a
question.
C
Do
people
should
I
treat
this
as
abyss
or
do
we
think
this
is
different
enough?
In
other
words,
but
you
know,
4916
was
written
for
4474
and,
like
is
8224
different
enough
from
4474,
that
we
don't
really
want
to
treat
this
like
abyss,
but
it's
like
a
just
an
update
or
a
different
because
it
it's
not
like
we're.
You
know,
collaborating
some
protocol
field
or
something
like
that
right.
We're
not.
C
I
mean
that
that
there's
there's
a
mechanism
using
100
rail,
that's
articulated
in
4916
that
we're
borrowing
but
like
so
far
I've
been
thinking.
This
isn't
actually
abyss,
but
we
should
still
kind
of
explain.
You
know
that
we
we
don't
have
identity
info
headers
anymore,
and
things
like
that
that
you
know
are
different
from
what
the
text
was
in
4916.
Yes,
probably
it's.
A
Feels
to
me
it's
a
different
usage
in
that
you're,
not
actually
trying
to
change
what
4916
says
and
you're,
not
asking
implementers
of
4916
to
go
change
your
implementation,
unless
they're
trying
to
pick
up
a
new
application
so
yeah,
I
don't
even
think
you
know
cue
the
gen
dispatch
conversation.
I
don't
think
an
even
an
updates
header
here
is
is
going
to
be
the
right
thing
to
do.
Unless
we
need
to
go
back
and
change
something
that
4916
required,
I
don't
think
we
did.
I
don't
think
we're
going
to
so
so
it
just.
H
C
H
A
C
C
Yeah,
I
wouldn't
mind
obsoleting
4916..
I
believe
it
is
obsolete,
and
so
I
mean
you
know
that
that
could
just
be
done
in
general
principle
as
a
side
effect
of
what
we're
doing
here
we
could
just
put
in
oh
by
the
way.
4916
is
awful,
absolutely
without
necessarily
presuming
that
we're.
You
know
that
the
the
the
this
is
intended
to
be
a
successor
to
direct
successor
mechanism,
yeah
I'll
leave
that
to
the
murrays
of
the
world,
to
figure
out.
E
Murray,
what
do
you
think
I
I
heard
my
name
there
and
I
don't
think
I
have
a
preference.
I
I
guess
the
only
question
I
might
ask
is:
does
it
matter
if
this
becomes
obsoleted
without
something
to
replace
it,
or
can
that
be
done?
You
know,
there's
no
need
to
tie
those
things
together
up
to
you
guys,
yeah.
C
C
Yeah,
I
don't
know
well,
let's
kick
the
can
on
that
one.
This
isn't
even
a
working
group
item.
Yet
let's
take
the
can
on
that
one
and
based
on
the
discussion
here
today,
I
will
flesh
out
a
bit
more
of
the
pre-call
connecting
identity
approach
and
the
conferencing
stuff
from
this.
So
that's
still
on
the
to-do,
but
next
slide
yeah.
I
think
we
need
this.
C
I
kind
of
went
back
through
the
original
charter
and
removed
some
of
the
things
that
were
aspirational
that
we
have
now
done
that
were
just
part
of
the
descriptive
text
of
the
charter
to
make
it
clear
that
you
know
the
core
focus
of
the
group
is
the
development
and
the
maintenance
of
you
know
basically
ag
24
to
26,
and
but
I
said
that
we're
also
going
to
do
some
other
stuff
that
we
will
consider
extensions
to
solve
related
identity
problems
around
telephone
calls.
Another
telephone
number
based
communication.
C
Yes
to
your
earlier
point
ben
the
charter
is
full
of
things
that
say
that
right
that
this
is
about
telephone
number
based
communication.
If
we
want
to
ditch
that
that
that's
something
that
we
we
should
discuss
here
now
and
kind
of
hack
a
bit,
but
then
I
just
kind
of
included
a
laundry
list
of
the
things
that
we're
already
doing.
C
A
Run
over
so
I
think
that
to
be
fair
to
people,
we
should
have
folks
look
at
this
if
anybody's
got
really
nasty
heartburn
with
a
recharge
that
goes
in
this
direction,
go
ahead
and
come
to
the
mic
now,
just
so
that
we
know
it
exists
with
a
just
a
quick.
I
don't
think
this
is
a
good
idea
comment.
Otherwise,
we'll
work
with
murray
to
go
down
this
path
and
we'll
run
stuff
past
the
list
first,
and
we
just
really
have
to
apologize
to
chris
for
running
over
running
over.