►
From YouTube: IETF108-STIR-20200731-1410
Description
STIR meeting session at IETF108
2020/07/31 1410
https://datatracker.ietf.org/meeting/108/proceedings/
A
A
A
A
B
C
A
A
D
D
D
D
Isg
review
convert
stuff,
but
I
mean
in
terms
of
ob,
obviously
like
ob
is
in
the
rc
editor
queue,
and
probably
several
of
you
this
week
have
heard
that
there
exists
such
a
thing
as
a
cluster
p38,
which
is
a
group
of
luckily
40
documents.
The
rfc
editor
is
currently
in
the
process
of
jointly
getting
released
and
as
a
consequence
of
that,
ob
is
just
kind
of
sitting
there,
but
it's
pretty
much
done
at
this
point.
D
D
For
those
of
you
that
don't
remember
the
long
and
sordid
history
of
diversion,
ov
and
interaction.
We've
come
to
a
few
phases
with
the
word
where
we
looked
at
doing
it
either
as
a
separate
passport
that
would
be
added
to
a
separate
identity
header.
It
would
appear
in
addition
to
an
original
identity
header
when
you're
going
to
do
the
diversion
or
versions
where
it
was
actually
nested
and
the
nesting
of
you
know.
The
original
passport
within
the
divergent
passport
is
something
we
did
with
a
separate
pipe
that
is
called
div.
D
D
For
virtually,
you
know
any
application
that
would
happen
to
want
to
do
nesting
passports,
not
merely
for
diversion
itself,
and
so
I
added
a
bit
of
text
just
about
like
kind
of
what
authentication
and
verification
services
do
in
general
to
work
on
div
when
they
receive
it
and
that's
the
main
switch.
But
please
do
read
it
if
you
care,
because
it
is
a
little
different.
There
are
even
normative
statements
and
you
see,
there's
a
parenthetical
question
to
the
chairs.
Here.
Is
this
something
that
we
want
to
actually
like
bring
back
to
the
working.
D
D
Given
the
choices
of
we
either,
you
know
have
some
formal
process
to
review
for
a
couple
weeks
before
we
give
you
know
thumbs
up.
Obviously
we
have
plenty
of
time
to
wait
given
where
they
are
stated
or
q
is
at
the
moment
you
know,
or
do
you
want
to
you
know
just
kind
of
tell
people
they
can
read
if
they
feel
like
it.
A
D
I
mean
it's,
it's
a
couple,
paragraphs
of
new
text
and
it
basically
is
like
high
level.
You
know,
authentication
services
when
they're
looking
at
this
in
general,
should
like
it's
pretty
much
the
procedures
you
previously
described
but,
like
you
know,
here's
some
high
level
guidance.
So
it's
it's
not
super
prescriptive.
A
D
D
Okay,
what's
prevent
some
naive,
you
know
intimidating
service
provider
or
ue
from
kind
of
lively,
trusting
that
this
is
a
complicated
question.
I
mean
the
position
that
I
articulated
on
the
list.
Was
that
really,
I
believe
it
is
incumbent
upon
relying
parties
to
trust
everyone
who
signs
passports
and
that
really
we
in
the
itf
here
aren't
typically
in
the
business
of
telling
you
know
people
who
they
should
trust
or
why,
but
that
you
know
this
has
to
be
a
factor
in
the
evaluation
of
div
and
jack.
Rightly
points
out.
D
I
mean
that
that's
potentially
complicated
right.
You
know
the
degree
to
which
the
star
shaken
implementation,
in
particular
within
the
closed
network
of
the
ipni,
is
predicated
on.
You
know
a
pretty
closed
system
of
trust
of
enrollment
and
you
know:
there's
significant
accountability
for
the
actors
to
generate
div
in
that
kind
of
environment.
I'm
not
super
worried
about
attacks
like
this,
especially
because
non-carrier
entities
are
not
exactly
getting
access
to
passports
in
the
shaken
idea
in
my
environment,
and
you
know
that,
as
a
consequence
of
that,
you
know
the.
D
I
think
the
risks
are
relatively
minimal.
Nonetheless,
I
mean
we
could
add
some.
You
know
clarificatory
tax
to
the
document.
That
speaks
to
just
kind
of
what
you
need
for
trust
in
general.
I
think
we
say
this
in
the
baseline
specs.
A
lot
already-
and
so
I
mean
you
know
I
kind
of
take
it
as
granted
from
the
security
considerations
of
824
and
age
225,
but
I
mean
I
wanted
to
open
this
one
up
to
the
floor
and
jack
feel
free.
D
I
mean
in
the
shaking
environment.
We
certainly
anticipate
that
right
that
it's
not
it
really.
It's
only
the
service
for
others
who
have
even
accessed
this
information
right,
and
you
know
what
what
you're
probably
going
to
see
at
ue
is
no
more
than
a
verstab.
You
know
there's
a
consequence
of
that.
I
mean
the
practical
implications
of
this,
for
the
immediate
implementations
of
stir
shaken,
I
think,
are
small.
That
much
said
I
mean
I
said
for
some
time.
D
Right
and
just
expand
that
a
bit
for
those
that
aren't
following
this
discussion
I
mean
the
the
good
news
is
any
of
these
impersonation
attacks
or
an
intermediary
is
attempting
to
you
know
spoof
that
the
original
origin
called
number
right
is
the
actual
caller.
You
know
provided
that
the
original
passport
uses
mkey
and
that
dtlsrtp
is
actually
used
for
the
media.
I
mean,
of
course
none
of
these
attacks
would
work
right
and
I
guess
yeah
in
the
in
my
head.
I
imagine
that
worst
or
ever
to
get
down
to
that
ue
level.
D
We
would
have
something
sit
brand.
Yes
right
that
we
would
be
doing
between
user
agents
and
as
a
consequence
of
that,
you
would
get
that
protection
from
that,
and
so
I
think
that
we
we
have
that
covered
now
again.
Details
ss3p
implementation
for
sip
overall
has
not
been
as
widespread
as
we
hoped,
to
put
it
mildly.
But
you
know,
I
think,
any
environment
where
things
did
get
down
to
that
ue
level,
where
there
were
widespread
implementations
that
did
that
yeah.
I
can't
imagine
that
they
wouldn't
have
that
available
to
them.
D
G
I
I
don't
know
if
this
is
I'm
just
curious:
how,
if
calls
get
down
to
the
ue
level,
do
you
how
much
diversion
is
going
to
be
going
on
there?
Are
you
going
to
depend
on
a
phone
to
be
on
all
the
time
to
forward
a
call,
or
is
that
always
going
to
be
a
network
feature?
You
know
I
mean
I'm
not
trying
to
use
that
as
any
excuse,
but
just
curious
what
you
think
there.
E
D
If
somebody's
intentionally
being
malicious
and
yeah,
if
you
get
a
passport
and
they
decide
to
reoriginate-
I
wouldn't
want
to
discount
a
use
case-
would
want
to
make
it,
I
guess
impossible
for
uae
to
implement
like
a
call
forwarding
app
on
it.
I
mean
it's
kind
of
not
a
great
app,
but
at
the
same
time
we
need
a
story
for
this.
I
think
the
story
is
empty.
H
Can
you
hear
me
now
yeah
man,
okay,
so
it
wouldn't
hurt
to
point
out
that
that
the
m
key
is
useful
in
this
circumstance,
because
it
may
not
be
obvious
to
somebody
reading
the
document
that
that
is
the
protection
for
this
particular
circumstance.
So
you
could
just
mention
it
just
point
back
to
the
original
discussion.
H
D
Slide
so
yeah
we
have
the
certificate
delegation
document
as
well,
which
concluded
working
group
last
call.
I
can't
say
there
was
a
ton
of
eyeballs
on
it,
but
russell's
eyes
I
think,
were
actually
intensely
gazing
at
it
for
a
bit
there,
and
although
it
took
me
a
little
bit
to
get
around
to
it,
those
pictures
I
believe
should
be
in.
I
don't
know
russ.
If
you
had
a
chance
to
look
at
them,
I
may
have
missed
it
on
the
list
if
you
did,
but.
D
I
assume
that,
if
it
is,
I
mean
and
again
I
took
the
text
out
of
the
jabber
log
from
the
last
in
a
room
and
patched
it
in
and
tried
to
address.
I
think
all
the
other
things
that
you
proposed.
I
think
there
are.
I
don't
recall
anything
that
I
didn't
put
in,
but
definitely
take
a
look
but
pending
that.
I
think
I
think
this
is
probably
good
to
advance.
A
D
A
A
A
B
A
B
J
A
G
Yep,
can
you
hear
me?
Yes,
we
hear
you
great
okay,
so
this
is
update
for
resource
priority
header
between
the
last
meeting
in
this
meeting
we
met
offline
with
brian
and
others
to
discuss.
You
know
aligning
some
of
the
the
things
that
he
had
in
his
document
and
I
think
the
result
of
that.
I
guess
you
can
go
next
slide.
G
Yeah,
so
this
is
some
of
the
background.
I
guess
I
could
go
through
that
if,
if
people
aren't
aware
of
it,
our
ph
is
related
to
resource
priority
header
and
specifically,
for
this
document.
We're
talking
about
emergency
services
calls
which
are
both
emergency
service
call
origination,
somebody
dials
9-1-1
or
the
appropriate
emergency
services
number
in
their
geography
and
then
also
the
callbacks.
That
can
happen
from
9-1-1
back
to
the
person
next
page.
G
Yeah
so
we
discussed
adding
sip
priority,
not
resource
priority,
but
priority
which
is
used
for
callbacks,
with
a
value
of
psap
callback
and
brian.
You
can
correct
me
if
I'm
misstating
anything,
but
hopefully
I
think
I
got
it
so
so.
The
simple
answer
we
had
was
just
to
add
a
new
claim
to
the
rph
passport,
which
is
sph
and
decided
to
assign
a
value,
a
psab
callback
to
make
it
straightforward,
and
the
purpose
of
that
would
be.
G
G
G
H
We
use
the
resource
priority
header
for
actual
priority
within
networks.
Typically,
you
don't
get
much
priority
for
emergency
calls,
but
networks
that
can
give
you
some
priority
have
a
marking.
They
know
what
emergency
calls
are.
There's
a
universal
marking
for
that,
but
specifically
specifying
an
rph
value
is
useful
and
using
the
esnet
namespace,
which
is
what
the
original
work
did,
but
being
able
to
also
bring
in
the
sip
priority
header
so
that
we
can
protect.
H
G
A
G
I
think,
as
far
as
I'm
aware,
it
has
most
of
the
substantive
things
that
should
be
in
there.
It's
also
been
reviewed
in
the
ipn
and
I
by
by,
and
I
think,
by
3gbp
folks
as
well.
So
I
think,
there's
been
you
know
in
terms
of
substance,
there's
been
enough
review
to
hopefully
move
forward
unless
there's
any
last-minute
things
that
can
anybody
can
identify
but
yeah.
I
think
we're
pretty
much
ready
to
go.
A
A
G
G
Yep,
so
for
rcd,
I
didn't
do
any
updates
to
the
rcd
draft.
I
didn't
receive
any
comments
specific
to
that.
I
think
we
again
in
terms
of
substance
we're
pretty
good
with
where
we
are
in
the
actual
draft,
but
we
do
reference
and
you
know-
we've
talked
about
it
in
the
last
few
meetings-
a
update
to
call
info.
G
G
G
G
G
D
E
D
Think
it's
pretty
important
that
we
identify
fields
that
we
want
every
receiving
party
to
be
able
to
understand
and
kind
of
draw
that
as
the
line
between
you
know
the
musk.
The
should
and
the
maze
for
support
of
this,
and
so
I
I
think
it
you
know,
I
think,
that's
probably
pretty
easy
to
come
up
with
things
that
we
want
to
make
sure
that
if
they're
sent,
then
receivers
are
gonna,
be
able
to
handle
them
and
figure
out
some
way
to
render
them
to
users.
G
Yeah
I
mean
in
the
initial
discussions.
People
are
talking
mostly
about
logo
well,
name,
obviously,
and
then
logo
and
reason
are
as
ones
that
seem
to
be
the
top
priorities.
But
you
know
I
can
see
adding
others
as
time
goes
on
and
depending
how
people
feel
about
receiving
that
type
of
information,
along
with
their
call.
G
D
D
That's
in
call
info,
which
I
think
is
the
right
actual
delineation
that
that's
the
way
I
like
store
to
work
where
you
know
we're
really
just
you
know,
figuring
out
how
to
sign
over
fields
that
are
part
of
the
base.
Sip
semantics,
given
that
there
isn't
actually
that
much
of
a
dependency
like
if
people
are
gonna
complain
about
this
field,
it
shouldn't
be
mandatory
or
whatever,
and
the
zip
code
draft.
D
G
H
Yeah
speaking
of
sip
core
chair,
our
workload
is
not
particularly
high,
so
it's
it's
a
fairly
good
time
to
try
and
put
work
in
and
we
can.
We
can
get
moving
on
it
pretty
quickly.
I
I
do
just
recommend
what
you
said.
I
think
what
you've
done
here
is
much
better
than
what
you
started
out
with
the
the
deciding.
H
How
we
want
to
want
to
do
this
kind
of
of
a
transfer
of
information
is,
is
a
sip
thing,
not
a
stir
thing,
and-
and
I
want
this,
I
would
like
the
sip
experts
to
weigh
in
on
this
on
on
that
part
and
then
signing
it
so
that
it
it
gets
to
the
other
so
that
you
know
that
it
hasn't
been
messed
with
in
transit.
Great,
that's,
that's
the
star
part.
So
I'm
I'm
particularly
appreciative
of
how
you
re
jiggered
this.
It
looks
much
better
than
the
original.
G
H
A
A
D
D
A
D
A
K
Guys
hear
me
yep
all
right,
excellent,
all
right,
so
I
jonathan
rosenberg,
five
nine.
I
I
admit
I've
not
been
doing
a
lot
on
the
list.
Discussion
with
rich
call
data
draft,
but
I
mostly
wanted
I
did
give
it
a
skim.
One
of
my
concerns.
Slash
comments
is
making
sure
it
works
well
for
enterprise
use
cases.
K
One
of
the
things
that's
not
at
all
clear
to
me
from
the
document
is
how
you
deal
with
the
k,
the
fact
that
some
of
the
information
will
be
provided
by
the
like
the
originating
enterprise,
which
you
know
may
or
may
not
be
signed
reason
for
call,
obviously
being
a
big
one.
You
know,
if
you
think,
of
an
enterprise
contact
center.
K
That's
going
to
be,
you
know,
highly
dynamic
based
on
the
you
know,
campaigns
and
other
and
other
properties
of
the
enterprise
call
center
and
not
known
by
the
the
authenticating
carrier.
So
how
does
that
work?
Because
that's
you
know
that
that's
call
reason,
for
example,
which
is
pretty
critical
for
connect
centers,
it's
in
the
signature.
So
how
does
the
carrier
trust
it?
Do
they
receive
it
from
the
enterprise
that
bit
of
it?
I
just
again
I
thought
maybe
I'm
missing
the
document
I
apologize
if
I
did,
but
does
it
cover
this
case.
G
K
G
Yeah,
I
guess
part
of
the
issue,
is
you
know,
making
sure
that
if
you
put
this
identity,
header,
rcd
identity,
header
in
your
sip,
invite
to
make
sure
that
it
gets
to
the
other
side
and
all
the
policies
that
are
involved
in
making
sure
that
nobody
drops
it
or
or
or
anything?
If
that's
your
intention.
D
That's
intended
to
create
this
delineation,
where,
like
a
vetting
agency
that
either
is
a
carrier
works
on
behalf
of
a
carrier,
for
example,
could
be
responsible
for
making
sure
okay.
This
number
is,
actually
you
know,
bronze
pizza,
and
this
is
the
bronx
pizza
logo,
and
everything
here
is
good
but,
like
the
call
reason,
part
is
intentionally
left
out
of
that
scope
of
protection
so
that
that
could
be
set
dynamically
by
enterprises.
So
there
are
mechanisms
in
there
that
are
intended
to
try
to
accommodate
that
that
kind
of
difference
in
the
scope.
D
K
Okay,
all
right
I'll
I'll.
I
just
want
to
make
sure
that
the
draft
clearly
articulates
that
there
is
a
you
know,
a
an
intended
applicability
to
the
case,
where
some
amount
of
effectively
unverified
information
by
the
authentication
information
is
received
by
the
authentication
service
from
the
enterprise
call
center,
which
is
not
signed
and
is
desired
to
be
passed
on.
A
subset
of
that
is
signed.
The
rest
is
passed
on
like
just
this
use.
Cases
is
clearly
described
and
supported
by
the
doctor.
K
D
A
C
D
All
right,
so
this
is
one
actually
that
I
had
for
last
time,
but
because
we
were
just
we
had
so
much
to
do
last
time.
I
don't
think
we
actually
got
around
to
talking
about
it,
then,
but
this
is
a
new
document,
and
this
is
a
follow-on
to
the
ob
specification.
The
informational
spec
that,
as
I
mentioned
earlier,
has
now
is
now
residing
in
the
arts,
editor
q.
Now
that
is
just
an
informational
document.
D
There
is
already
work
about
it
in
other
places
as
well
and
I'll
talk
a
little
bit
about
that
going
forward,
but
the
basic
idea
is
to
adopt
a
more
constrained
environment
than
the
original
informational
out-of-band
framework
stipulated
in
particular.
What
could
you
do
differently
from
a
security
perspective,
if
you
assume
that
it
is,
in
fact,
the
term
leading
service
provider
who
is
operating,
the
cps
there's
a
ton
of
tax,
that's
in
the
out-of-band
rfc
that
is
about.
D
As
I
said,
you
know,
this
will
use
roughly
the
ob
rest
interface
that
was
originally
described
in
the
out-of-band
framework,
with
the
assumption
that
it
will
be
the
terminating
service
provider
who
runs
the
cps.
This
will
obviate
the
need
for
encryption
of
the
passports.
The
you
know
kind
of
hard
edge
on
this.
I
guess
is
the
gatewaying
problem.
There
are
cases
where,
because
a
lot,
a
lot
of
these
cases
are
either
sip
to
pstn
or
pstn
to
sip
cases
where
there
just
is
some
smart,
smart
capacity.
D
D
When
you
have
that,
then
you
know
you
can
figure
out
how
to
discover
it,
send
the
passport
to
it,
and
you
know
the
gateways
that
you
enroll
to
handle
the
intermediary
stage.
If,
for
example,
traditional
indian
star
shaken
is
where
the
call
originates,
you
know
those
gateways
could
be
responsible
for
storing
the
cps.
If
you
don't
want
to
place
the
burden
on
like
every
participant
in
shaken
to
have
their
own
authentication
services
go
off
and
store
this
at
the
terminating
cps.
D
One
thing
that
this
does
require,
which
is
a
new
concept,
and
this
is
probably
where
the
bulk
of
the
actual
protocol
design
work
would
need
to
be
done,
for
this
is
in
this
concept
of
a
cps
advertisement
of
having
some
kind
of
a
document
exactly
where
the
document
lives
probably
depends
on
the
trust
models
of
the
store
network.
That
is
utilizing
this
I
imagine,
cps
advertisements
could
literally,
you
know,
reside
at
a
centralized
directory
service.
They
could
be
embedded
into
certificates
themselves.
D
Even
you
can
imagine
a
cert
kind
of
telling
you
for
all
calls
that
are
supposed
to
go
to
this
particular
network
to
the
holder
of
the
cert,
here's,
the
cps,
or
at
least
here's
a
bootstrapping
url
that'll
help.
You
learn
what
the
cps
is
for
that
network.
Something,
though
that
is
tied
into
whatever
the
trust
anchor
is,
I
think,
that's
the
crucial
component
of
the
cps
advertisement,
and
it
would
be
a
very
simple
json
document
that
would
just
be
showing
mappings
between
tnoth
lists
and
potential
cps
urls.
D
G
Question,
can
you
hear
me
yes
yeah,
so
you
know
I
wasn't
gonna,
not
say
anything.
Of
course.
I
guess
you
know.
I've
said
this
in
other
forms,
but-
and
you
know,
the
concept
of
the
cps
being
in
the
terminating
service
provider
is
a
little
bit
new
or
maybe
that's
I
don't
know
if
you've
been
thinking
that
for
a
while
or
what,
but
at
least
newer
to
me.
G
The
problem
I
see
with
that
is
you
know
if
I'm
going
to
set
up
a
bunch
of
connections
to
cps's
distributed
throughout
various
service
provider
environments-
and
you
know
like
for
a
service
provider
like
comcast.
You
know
where
we
have
national
footprint
and
geographic
concerns
about
sending
things
to.
G
What
I
fear
is
like,
why
send
an
http
request
when
I
can
just
send
a
sip
invite
over
ip
to
a
bunch
of
advertised?
You
know
interconnection
points
and
call
it
a
day
like
I'm.
Not
I'm
wondering
you
know.
Are
we
solving
the
problem
twice
if
we're
sending
invites
and
we're-
and
I
realize
they're
going
through
tdm
links,
but
you
know
like
if
we
have
to
create
this
overlay
network?
D
D
So
I
mean
this
is
much
more
looking
at
a
high
level
at
what
the
security
differences
are.
If
you
assume
that
again,
the
the
cps
is
not
something
that
is
a
third
party
that
you're
trying
to
conceal
data
from,
but
instead
you
know
an
entity
that
is
tightly
coupled
with
either
the
origination,
the
termination
of
the
call
and
what
the
consequences
of
that
are
for
what
the
security
requirements
are
incumbent
upon
like
the
the
protocol
to
deliver,
and
since
they
seem
much
easier
and
more
favorable.
G
D
Well,
so
I
think
we
think
from
that
perspective,
when
we
look
at
north
america,
but
you
know,
as
I
know
you
and
I
have
discussed
before
you
know
other
places
where
solutions
like
this
are
under
consideration
or,
for
example,
in
the
gsma
in
the
vines
working
group
there,
which
is
part
of
their
fraud
and
security
group.
That
is
looking
at
how
to
implement
this
in
international
mobile
and
like
they.
They
have
a
lot
of
the
same
kinds
of
problems
and
their
their
problems.
D
Are
you
know
the
intermediary
networks
in
various
environments
are
not
trusted
and
they
need
to
have
a
back
channel.
They
can
go
around
them
in
those
environments,
and
so
what
I'm
writing
about
this?
I
am
thinking
about
not
just
shaken
not
just
pure
stir,
but
like
what
some
of
these
other
potential
use
cases
are
for
it
and
what
we
would
need
to
be
able
to
implement
a
system
like
this
there
right
and
that's
why
I'm
kind
of
loving
a
bit
rather
than
getting
into
yes,
if
you
just
did
gateways.
G
Well,
international
is
a
whole
another
thing,
and-
and
I
agree
if
you
know
I
I
mean
you
could
make
the
same
argument-
I
guess
for
countries
that
may
not
adopt
stir
as
a
as
something
and
you
know
you
have
to
have
a
gateway
to
figure
out
trust
boundaries
and
things
like
that
as
well,
but
yeah.
I
just
wanted
to
bring
up
that
perspective.
Thank
you.
H
D
D
The
cps
is
kind
of
coupled
to
the
terminating
side,
and
we
talk
about
this
a
bit
in
the
text
of
whether
the
cps
could
be
literally
composed,
with
the
the
vs
to
a
degree
that
you
know,
there's
no
need
for
an
interface
between
the
obvs
and
the
cps,
and
then
there
are
models
where
the
cps
pushes
passports
it
receives
down
to
an
obvs,
because
it
knows
that
they
are
targeted
to
a
particular.
You
know
terminating
service
provider,
which
is
not
something
you
know
in
the
original
out-of-band
framework.
D
D
D
I
think
I've
already
talked
to
most
of
this.
I
mean
it
really
isn't
very
different
in
terms
of
the
verification
process.
What
you
need
to
do
from
the
baseline
ob
framework.
It
is
worth
pointing
out.
You
know
this
is
a
high-level
architecture
still
in
some
respects.
So
when
we
say
that
each
term
of
dating
service
provider
runs
a
cps
that
doesn't
necessarily
mean
they
operate
it.
Of
course
it
could
be
hosted.
It
doesn't
necessarily
mean
that
a
cps
couldn't
have
kind
of
multiple
tenants
that
it
is
fronting,
for.
D
I
understand,
there's
already
an
implementation
out
there
of
this
in
the
field
that
works.
That
way,
and
so
you
know
we
kind
of
gloss
over
some
of
that,
but
it
doesn't
change
the
fact
that
again
getting
the
security
requirements
of
this
particular
use
case
nailed
down
fleshing
out
the
rest
interface
a
bit
and
getting
cps
advertisements.
D
So
yeah
I
mean
my
base
question
to
all
of
you
is:
should
we
do
this?
Like
I
said
there
there's
a
parallel
effort
in
addis.
There
is
some
parallel
consideration
as
well
in
the
gsma
around
the
space,
though
that
that
is
relatively
early
and
I
think
it's
unclear
which
of
several
potential
high-level
solution
directions
they
will
take.
But
at
the
same
time
I
I
feel
like
it's
worth
documenting
again,
that
the
three
things
that
I
previously
described,
you
know
what
the
differences
are
in
the
threat
model
in
this
environment.
D
You
know
how
you
would
do
these
cps
advertisements
well
or
poorly,
because
I
believe
there
are
ways
to
do
them
poorly
and
I'm
concerned
that
there
will
be
implementations
out
there.
If
we
don't
have
something
like
this.
That
might
not
take
a
good
approach
to
cps
advertisement
and,
of
course,
the
rest
interface
itself
is,
you
know
really
just
a
sketch
in
the
original
draft
and
we
could
do
better.
D
A
Yeah,
let's,
let's
go
ahead
and
see
if
we
can
get
some
use
out
of
this
virtual
home
tool.
If
you
are
interested
in
contributing
to
this
draft
in
a
working
group.
Setting
is
the
question
so
I'm
going
to
hit
the
start
button.
If
you
think
this
should
be
something
working
group
should
take
on
and
you
will
participate.
A
A
D
That
we
sure
I
mean
you
know,
I
think
this
needs
to
be
done.
I
think
that
there
are
groups
that
are
already
starting
to
chart
this
outside
the
idf,
and
it
would
be
really
good
if
we
gave
some
guidance
to
them,
because,
generally
speaking,
when
we
don't,
we
are
often
unhappy
with
what
happens
as
a
result,
but.
A
G
D
C
E
D
Out
of
band
function
that
lets
them
get
call
detail
records,
basically
from
directly
from
origination
to
the
termination
side
and
like
there
are
only
so
many
ways
to
skin
that
cat.
They
were
talking
about
stir
shaking
before
I
got
there,
so
I
started
listening
in
the
next
thing.
You
know
they're,
like
hey.
Do
you
want
to
edit
this
thing?
So
I'm
like
okay.
D
Well,
I
think
you
know
we
at
the
itf
we're
not
the
protocol
police
we
put
out
what
we
think
are.
You
know
valuable.
You
know
vetted
secure
solutions
for
this
and
I
think
we
have
a
pretty
good
track
record
of
if
we're
willing
to
go
on
record
and
say
this
is
a
an
okay
way
of
doing
this.
People
listen
to
us.
A
H
Don't
worry
about
it,
you
don't
need
to
see
me.
This
is
going
to
be
quick.
Let
me
just
keep
going
so
this
is
I'm
I'm
basically
going
to
repeat
what
I
said
a
little
bit
a
while
ago,
so
emergency
calls
are
important,
validating
that
this
is
a
good
emergency
call
is
really
important.
The
the
thing
that
happens
with
spoofing
other
than
tdos
and
ddos
is
swatting,
where
you
call
up
9-1-1
with
a
spoof
telephone
number
and
say:
oh,
my
neighbor's
house
is
being
attacked.
Send
the
swat
team.
H
H
We
don't
currently
have
any
specification
for
how
you
use
the
resource
priority
head
header
for
emergency
calls
and
that
basically
reflects
old
experience
where,
where
the
the
psdn
does
not
give
any
kind
of
priority
to
emergency
calls,
newer
networks
have
the
capability
to
give
some
priority
to
to
to
emergency
calls
and
so
moving
forward
with
it.
A
way
to
at
least
ask
for
it
is,
is
a
reasonable
thing.
Next
slide.
H
H
H
H
We
needed
to
to
to
know
that
this
was
a
callback
and
the
marking
that
was
selected
in
rfc
7090
was
the
sip
priority
header,
which
is
not
the
resource
priority
header
and
there's
a
value
called
psap
callback
for
that
that
header
that
marks
this
as
a
as
a
callback
and
of
course
we
really
would
like
to
protect
that
against
modification.
We
don't
really
really
don't
want
to
make
be
able
to
spoof
that
that
that
setting
it
does
not
set
a
7090
doesn't
define
the
use
of
rph.
H
As
I
said
before,
we
we
really
didn't
have
any
notion
of
prior
of
resource
priority
in
in
the
past,
but
we're
now
we're
we're
thinking
that
at
least
some
networks
might
be
able
to
provide
it
so
we're.
What
we
would
like
to
do
is
to
set
the
rp
h
to
es
0
and
then
again
we
would
need
to
protect
both
rph
and
sip
priority
against
modification.
A
H
A
A
D
Hey
can
I
can
I
get
in
yeah
yeah,
I
was
just
gonna
give
a
little
pointer.
This
was
not
something
that
I
felt
we
needed
to
discuss
this
time,
but
I
did
revise
my
old
connected
identity
draft
actually-
and
this
is
something
that
I
am
going
to
start
putting
some
more
energy
into
as
things
like
ob,
intervert
and
so
on,
are
getting
off
of
our
plate
and
delegation,
and
this
connected
identity
draft
is
basically
looking
at
an
update
to
4916,
which
was
the
original
kind
of
connected
identity
for
4474.
D
That
looks
at
how
you
could
get
requests.
How
you
basically
get
started
work
in
the
reverse
direction,
how
to
get
a
request
in
the
backwards
direction,
probably
an
update
or
something
to
carry
a
passport,
so
you
could
see
who
it
is
you
ended
up
connecting
to.
This
is
a
valuable
property
for
a
number
of
the
things
that
we're
trying
to
do
with
stir,
including,
for
example,
sip
brandy,
and
so
that's
work.
D
D
I
hope
to
flesh
that
out
a
little
bit
more
than
it
is
now,
but
that's
something
that
I
know
I'll
be
bringing
next
time
and
there
was
one
other
thing
I
wanted
to
raise
as
well.
That
has
come
up
a
couple
times
now,
which
is
whether
there's
much
of
an
appetite
in
this
group
to
start
looking
at
messaging-
and
you
know.
Basically,
there
are
a
number
of
systems
out
there
today
that
still
use
telephone
numbers
as
the
source
of
textual
messages
or
mixed
textual
and
graphical
messages.
D
And
you
know,
although
there
have
been
some
custom
systems
that
have
been
developed
to
attest
for
those,
I
kind
of
feel
like
we
will
have
failed
in
our
responsibilities
in
stir.
If
we
don't
at
least
explain
how
stir
credentials
could
be
used
by
those
systems
if
those
systems
wanted
to
use
them,
and
so
chris-
and
I
actually
were
talking
about
this-
just
kicking
around
the
idea
that
we
could
create
some
kind
of
a
framework
document
that
isn't
specific
to
any
messaging
system.
D
That
just
says
like,
oh,
if
you're
going
to
use
like
messaging
lister,
here's
some
ways
that,
for
example,
passport,
could
relate
to
that.
Here's.
How
in
particular
stirf
would
then
to
relate
to
that,
and
I
was
curious
if
anyone
thought
that
was
an
interesting
or
non-interesting
thing
for
us
to
be
doing.
B
L
D
G
Okay,
chris
yeah
yeah-
this
is
chris.
I
I
was
actually
just
purely
going
to
ask
what
is
the
state
of
that
document
and
I
think
yeah
answered
my
other
question
that
it
wasn't
specifically
stir-related
but
certainly
seen
the
value
you
know
to
amplify
john's
message
that
you
know
you
know
it's
sort
of
like
the
calling
name
thing
we
we
we
left
that
off
and
we
knew
we
needed
to
do
that.
So
I
I
see
messaging
as
similar
thing
here.
D
D
D
Why
is
it
in
c238
because
of
the
dependency
on
the
ice
stuff
that
which
it
shocks
me
that,
like
trickle
ice
or
something
depends
on
anyway
but
I'll?
Do
it
I'll?
Do
it,
but
yeah
I
mean
so.
We've
always
needed
this
for
sip
randy
to
actually
work
this.
This
is
the
point
like
in
order
to
get
secure
credentials
in
the
backwards
direction
via
sip
brandy.
We
need
a
4916
update.
It's
not
a
big
update
from
a
protocol
perspective,
but
yeah.
D
Right
so
I'm
seeing
I'm
seeing
a
lot
of
plus
ones
for
for
messaging
people
seem
to
think
that's
a
pretty
cool
idea,
and
you
know
again,
I
think,
there's
a
way
to
scope
it.
I
think
the
trick
is
to
scope
it
in
such
a
way
that
anything
that
wants
to
use
it
like,
if
mls
like,
wanted
to
use,
stir
credentials
for
some
reason
like
what
would
that
look
like
like?
That's
me,
the
only
thing
that
that
I'd
be
willing
to
sketch
like
beyond.
D
Just
you
know,
message
or
something,
but
you
know
I
think
we
want
to
create
something.
That's
broad
enough,
that
it
gives
general
guidance
for
applications
that
use
messaging
that
might
want
to
use
star
credentials,
which
we
presume
are
going
to
become
very
common,
very
soon,
sometime
after
june
of
2021
and
so
like
yeah.
I
think
I
think
we
need
to
do
it.