►
From YouTube: IETF97-SIPBRANDY-20161114-1100
Description
SIPBRANDY meeting session at IETF97
2016/11/14 1100
B
A
B
C
B
E
H
H
A
B
B
L
B
B
F
J
B
B
E
E
H
E
H
Get
started
they
the
only
hobby
GA,
so
we
had
to
change
laptop
actually
so
welcome
to
the
sea
brandy
working
group,
but
we
need
to
right
there
yeah
okay,
so
we
have
a
jabber
scribe
and
you
know
volunteer
to
take
notes.
So,
thank
you
very
much,
so
we
don't
need
that
if
somebody
can
be
in
the
Java
room
and
relay
comments
to
the
mic,
that'd
be
great
as
well.
H
H
Have
for
today,
the
status
of
the
working
group
also.
Is
that,
as
you
know,
we
have
to
draft
and
this
basically
nothing
that
has
happened
since,
since
last
time
we
met
in
Berlin
the
osr
RTP
draft.
We
know
going
to
have
a
presentation
because
Allen
coulda
me
here
and
he
couldn't
be
here
so
I
mean-
and
there
was
nothing
new
to
present
basically
and
I'm.
John
is
gonna,
be
giving
a
presentation
on
the
bcp.
Maybe
I
don't
know
Ben.
H
If
you
want
to
say
something
about
the
you
know,
status
of
the
other
draft,
like
you
know,
proposed
standard
versus
informational
or
you're.
Still
discussing
with
the
iesg
I
mean
what
I
want
to
know
is
that
if
the
working
group
gave
you
they
all
the
feedback
you
need,
or
you
need
further
input
that
that's
basically
what
I
would
like
to.
N
Know
I
think
I
have
the
input
I
need.
I
do
need
to
discuss
it
with
the
other
art
IDs,
but
we
did
come
back
and
find
yes,
here's
a
place
where
we're
actually
updating
a
current
proposed
standard.
Okay,
though
so
at
least
that
peace
would
need
to
be
standard
strike
to
move
forward,
don't
end
and
the
no.
I
need
to
have
further
discussions
with
the
other
IDs
on
whether
or
the
current
organization
that
is
okay,
perfect.
H
Excellent,
if
you
need
further
input
at
any
point,
just
let
us
know
and
then
regarding
the
always
thanks
regarding
the
energy
in
the
working
group.
As
you
have
noticed,
we
were
quite
concerned
with
that,
but
we
were
talking
to
john
and
it's
true
that
I
mean
the
stair
working
group
has
been
advancing
quite
a
bit
and
now
probably
know
we
will
get
more
energy
into
in
to
see
Brandi.
So
without
further
ado,
John
I'll
get
your
slice
up.
D
Yeah,
honestly
I
hope
we
don't
need
that
much
energy.
In
fact,
I
think
we
don't
in
the
sense
of
I,
think
there
is
a
limited
amount.
Let
me
still
need
to
do
here
and
we
will
be
able
to
do
it
to
get
this
relatively
fixed
place
next
lot.
So
for
those
of
you
who
are
walking
in
here
for
the
first
time
just
walked
in
off
the
street,
have
no
idea
what
this
working
group
is
about.
What
we're
doing
this
working
group
is
trying
to
define
media
confidentiality
with
Seth.
D
This
may
sound
like
something
that
would
have
been
kind
of
a
strange
omission
for
us
to
have
made
in
the
decades
that
we've
been
working
on
Sep,
in
fact
that
what
we're
trying
to
identify
are
given
the
kind
of
the
Swiss
Army
knife
of
security
services
that
are
available
in
sep.
How
do
you
combine
those
in
order
to
actually
be
able
to
get
privacy
and
confidentiality,
which
is
largely
motivated
by
purpose
by
concerns
about
pervasive
surveillance
and
so
we're
looking
at
what
techniques
will
cause?
Basically
the
most
VoIP
traffic
to
be
encrypted?
That
we
can?
D
We
also
want
to
create
a
document
that
might
help
to
influence
public
policy
that
people
who
look
at
the
iTap
and
see
a
bcp
bcp
is
something
we
can
represent
to
the
world
as
the
consensus
of
the
ITF.
That
is
a
relatively
unusual
property
and
the
products
of
the
group
and
yeah
I
mean
also
putting
these
things
together.
D
You
know
we
could
identify
gaps,
things
that
actually
need
to
be
fixed,
that
we
hadn't
thought
of
before
until
you
really
try
to
combine
everything
in
this
way,
you
don't
know
so
we
thought
we'd
do
the
exercise
and
create
something
that
hopefully
future
work
here
could
rely
on
in
order
to
define
the
best
way
to
do.
We
get
security
beset
next
level.
This
is,
has
guns
all
intimated,
divided
into
a
two-prong
strategy.
D
This
first
prong
is
a
comprehensive
security
draft
that
is
focused
on
how
we
use
techniques
built
around
kind
of
a
strong
identity
to
be
able
to
provide
that
confidentiality
service.
There
is
a
parallel
effort,
however,
that
is
not
represented
here
today,
which
is
the
opportunistic
security
draft
that
console,
oh
and
Ben
were
just
describing
we're
not
going
to
talk
about
that
much
here
at
all
next
slide,
so
we
we
didn't,
do
absolutely
nothing
since
last
time,
I
did
at
least
likely
iterate.
This
draft
I
think
it
was
already
twice
since
last
time
was
makes.
D
Them
and
then
I
actually
made
a
couple
of
changes
like
right
before
the
deadline,
not
that
that's
fair,
yeah
I
can
tell
suggested.
This
is
largely
because,
like
what
stir
has
been
and
stir
is
the
fundamental
underpinning
of
this
work
has
been
really
rapidly
changing
over
the
last
like
four
months
and
as
a
consequence,
I
mean
now
that
we've
got
this
kneel
down,
I
think
into
a
slightly
more
stable
place.
I
think
we're
in
a
position
to
then
apply
what
those
changes
have
been
to
the
SIP
Randy
work.
I.
D
Think
I've
done
a
lot
of
that
in
this
revision
actually,
and
my
hope
is
that
there
won't
be
a
lot
to
do
after
this.
That,
actually,
you
know,
most
of
what
we
need
to
do
is
probably
done
at
this
point.
More
significantly.
Beyond
that
realignment,
we
did
have
a
discussion
last
time
in
Berlin.
There
were
a
couple
points
in
that
discussion
that
came
out
of
it
that
are
noteworthy
one.
You
know
in
the
original
draft
we
had
a
pointer
to
perk
to
kind
of
that.
The
double
work
that's
going
on
there.
D
We
removed
that
since
last
time,
people
said
this
is
really
not
mature
enough
to
be
something
that
we
would
point
to
it
this
time.
So
right
now
we
kind
of
defer
to
any
of
these
kinds
of
video
conferencing
solutions
or
trying
to
figure
out
ways
that
multiple
parties
can
maintain
confidentiality,
while
still
using
a
central
bridge
that
is
now
punted
to
them.
That
is
not
going
to
be
in
the
scope
of
this
BCP.
We
also
removed
much
about
OS
RTP.
D
We
used
to
have
kind
of
statements
in
there,
like
you
must
do
what
we're
talking
about
here,
but
you
may
do
a
bunch
of
other
stuff,
that's
actually
discussed
in
like
Allen's
draft
and
based
on
our
conversation.
Last
time
we
don't
say
anything
about
that
really
anymore.
We
just
kind
of
took
all
that
out
and
like
you
can
like
rebalance
draft
to
figure
out
how
to
do
that.
D
We
tried
to
put
in
some
better
text
about
anonymity
and
its
der
interaction
as
well
and
a
bit
more
about
like
self-signed
certain
things
like
that
too.
But
though
these
are
I
think
the
substantial
changes
just
aligning
it
with
the
ongoing
work
and
stir
removing
the
things
we
agreed
to
in
Berlin
and
then
dispose
string
a
little
bit
of
the
certificate
management.
Stuff
I
do
have
a
couple
questions,
though,
for
the
room,
so
I
hope
you're
paying
attention.
There
are
things
I
think
we
can
profitably
discuss
them
a
little
time
we
have
today.
D
So
so,
please
do
follow
along
what
we
have.
One
thing,
I
think
that
is
emerged
largely
come
shaken.
Actually
is
this
concept
that
we're
profiling
stir
in
certain
ways,
for
particular
applications
and
I've
tried
to
retool
this
document
to
talk
about
the
work
of
sit
brandy
as
a
stirrer
profile,
we're
taking
stir
as
its
baseline
and
applying
it
to
this
problem
of
doing
media
security?
D
The
best
way
to
extend
stir
for
a
profile
like
this,
when
you
really
want
the
other
side
like
understand,
the
extension
is
to
use
this
passport
type
parameter
that
we
created
for
passport
passport
is
the
object
format
that
stir
uses
to
provide
its
integrity,
protection
over
elements
of
sick
requests
and,
as
a
consequence,
we've
now
defined.
One
of
those
for
this,
the
extensibility
model,
is
actually
something
that
Chris
person
I'd
like
mess
with
incessantly
over
the
last
six
months
or
so
now
that
that's
stable
enough.
D
I
think
I
can
articulate
what
the
right
way
is
to
do
it
for
this,
and
so
that
this
is
my
idea,
but
what
we
have
now
there's
an
M
sac
passport
type,
and
this
is
something
that
we
signaled
in
the
passport,
as
well
as
in
the
corresponding
sip
header
that
carries
the
signature
of
that
passport,
and
this
basically
allows
the
endpoints
to
negotiate
support
for
this
profile.
It
requires
the
verifier
well,
okay,
the
the
way
we
define
the
profile
requires.
The
verifier
must
feel
the
request.
D
If
there's
a
signature
violation,
this
is
not
a
property
that
is
intrinsic
to
passport.
In
fact,
you
know
all
of
sip,
identity
and
passport
is
pretty
forgiving
right
about
what
local
policy
can
be
like
if
you
get
an
identity,
header
and
the
signatures
broken.
If
it's
not
your
policy,
that
you
should
reject
the
request,
in
that
instance,
you
don't
have
to
well.
This
is
different
because
force
if
Brandi
you
actually
are
trying
to
create.
You
know
an
environment,
you
don't
necessarily
want
to
feel
back.
This
is
when
someone
is
originating
a
sip
request.
D
They
want
media
confidentiality.
They
want
the
request
to
fail.
If
it's
that
confidentiality
is
not
available,
that's
pretty
much.
How
we
define
the
profile
on
this
I'll
have
a
few
weasel
words
about
that
later
on
that
that
I'll
talk
about,
but
that
is
not
a
constraint-based
Leinster,
and
that
is
something
that
is
different
about
this
M
sac
profile
of
star.
Now
we
want
this
to
be
n
to
n.
D
That's
also
really
different
in
waster
works
stir
has
this
concept
of
an
authentication
service
and
verification
service,
those
could
be
instantiated
in
a
user
agent
or
an
intermediary,
or
actually
in
all
kinds
of
external
entities
and
weirder
store
architectures
that
we
have
at
least
a
dreamed
about
here.
You
know
we
want
it
to
be
end-to-end
I
think
we
can
make
sure
that
you
know
m/sec
gets
to
a
verifier
and
the
verifier
can
know
that
m/sec
was
used.
It's
a
much
tougher
question
to
really
prove
like.
D
Was
it
done
by
the
originating
you
a
or
not
I'll
have
some
things
to
say
about
that,
but
it's
it's
a
little
sketchy,
and
so
we'll
have
some
questions
for
group
about
this
as
well.
Next,
this
is
just
kind
of
a
recap
of
what
it
is
that
we
took
out
in
terms
of
the
previous
maze
and
so
on
for
things
like
zrt
PE
or
like
alternative
key
mechanisms,
we're
exploring
for
us
RTP
here.
What
we
really
say
now-
and
this
is
the
MTI
of
the
bcp-
is
used.
D
Eclss
circuit,
be
like
that's
what
we're
saying:
you're,
gonna
use
and
I
just
want
to
make
sure.
Since
we
talked
about
this
in
the
last
session,
it
was
a
little
bit
contentious
and
exactly
how
we
explored
that
language,
that,
for
the
purposes
of
this
profile
of
stir,
that's
still
how
people
want
to
do
it.
D
Where
we
just
say
what
you
were
all
were
having
in
the
bcp
is
a
must
for
detail:
SS,
r,
QP
and
crickets,
and
everything
else
I
see
no
one
rushing
to
a
microphone
to
violently
object
to
this
proposition
next
slide
right.
So
potential
management
is
where
we
begin
to
get
into
these
questions
about
what
it
really
means
for
the
authentication,
service
and
verification
service
to
be
implemented
in
the
end
points
for
sip
brandy.
What
that
you
know
most
practically
means
is
they
need
to
have
a
way
to
get
credentials
that
are
appropriate
for
this.
D
Anything,
that
is
an
authentication
service,
needs
to
have
a
credential
for
its
identity.
If
we
imagine,
this
is
going
to
be
a
truly
end
end
or
aims
to
be
an
end
and
media
security
mechanism.
Obviously
there
needs
to
be
a
way
to
get
then
cryptographic
material
down
at
these
endpoints
to
support
it.
It
needs
some
work
we
have.
We
could
do
something
like
tofu,
you
know
where
there's
some
kind
of
self
signed
certificate
on
first
use.
However,
that
is
unlikely,
let's
say
to
attest
something
that
could
be
differentiated
from
an
intermediary.
D
Basically
doing
the
same
thing,
and
that's
you
know
again:
it
man
in
the
middle
are
very
possible
in
environments
to
assume
that
as
well,
so
we
do
have
now.
This
draft
Peterson
Acme
telephone,
which
is
looking
at
Acme
as
a
potential
mechanism
for
acquiring
certificates
or
devices
that
newster
there
is
a
profile
for
that.
That
should
work
specifically
for
this
kind
of
end
user
device,
where
you
would
use
well
known
techniques
like
say:
SMS
validation.
There
are
sophisticated
adversaries,
obviously,
who
can
get
in
the
way
of
that
as
well?
D
But
this
would
at
least
be
a
way
that
we
have
a
plausible
story
potentially,
especially
in
a
smartphone
environment,
one
that
is
coupled
with
some
kind
of
operating
system
integration.
I
understand.
There
are
hooks,
for
example,
in
Android
that
allow
you
to
interrogate
the
operating
system.
So
you
might,
you
might
be
able
to
get
multiple
factors
that
really
tie
this
to
some
particular
endpoint
of
sim
cards.
D
That
much
said
you
know
we're
much
like
stir
itself
is
kind
of
punting
on
this,
like
we're
we're
talking
about
some
ways
that
you
could
do
it
if
we
have
some
very
clever
notions
of
how
we
could
do
this,
if
you
think
will
provide
stronger
attestation
that
this
is
in
fact
an
end
user
device,
we
can.
We
might
want
to
prescribe
those
right
now,
though,
it's
pretty
I'd
say
that
guidance
is
inspirational
rather
than
than
very
specific
about
what
credential
acquisition
looks
like
with
us.
However,
I
mean
I
think
again.
D
O
D
Know
who
the
signer
is
so
I
that
the
intent
here
is
provide
end-to-end,
media
security
and,
as
a
consequence,
you
know
that
the
assumption
is
that
there
is
some
sort
of
endpoint
right
and
that
the
credentials
require
design.
This
must
reside
on
such
an
endpoint.
Now.
This
is
unfortunately
because
of
sips
nature.
An
endpoint
is
an
abstraction
and
they're.
All
kinds
of
you
know
decomposed
endpoints,
and
things
like
that
that
make
this
extremely
problematic
or
you
know,
end-user
gateways
you
plug
a
black
phone
into
you
know.
D
Is
that
not
in
to
end
if
there's
like
a
Blackfoot,
so
I
mean.
Unfortunately
you
you
you,
you
quickly
hit
those
philosophical
limits
when
you
try
to
define
this
I'm,
just
trying
to
figure
out
what
the
best
kind
of
assurances
we
could
get
that
in
an
device
is
associated
with
this,
and
so
that's
why
I'm
thinking
things
like
this
multi
factor
off
that
might
be
associated
with
with
the
device
itself
to
really
strongly
couple
this
to
the
device.
So.
I
G
I,
just
a
sort
of
meta
level:
I,
don't
think
we
necessarily
have
to
prescribe
that
that
you
couldn't
do
that
other
ways,
but
I
think
that
we
do
need
some
way
that
we
say
you'll
have
they'll
work,
because
this
is
this.
Solution
is
sort
of
laughable.
Without
this
is
the
hard
part
of
it.
So
we're
going
to
put
together
a
solution
that
really
all
hangs
together.
We
don't
have
a
solution
unless
we
have
some
answers
to
this
problem
as
well.
I
think.
D
It's
a
different
part
like
TLS,
doesn't
have
to
meet
that
bar
right,
like
we
don't
ask
pls
to
solve
how
you
get
the
search
for
it
in
the
standard.
So
I
mean
it's.
It's
an
unusual
barf
the
item.
I
know
we
want
to
try
to
give
some
reasonable
guidance
for
this
right
and
in
may
be
there
I'm
really
poking
out
here.
Is
there
better
guidance
we
can
give
them?
You
ordinarily,
do
about
this.
Okay,
Chris.
L
Chris
one
I
guess
we
don't
mention
explicitly,
but
service
providers
obviously
have
to
follow
legal
types
of
requests
where
we
do
have
to
do
men
in
the
middle
yep.
So
that's
actually
one
case
where,
if
a
service
provider
was
ever
going
to
adopt
something
like
this
and
then
media
security,
which
can
be
a
good
thing,
we
sort
of
have
to
be
able
to
at
least
for
certain
calls,
do
some
legal
things
so
just
to
point.
D
Is
there
is
some
language
in
there
about
shipwreck
right,
which
is
an
example
anyway
of
a
mechanism
that
was
designed
for
that
purpose,
that
we
standardize
the
ITF?
There
were
you
kind
of
work?
Basically,
the
media
coming
out
at
the
end
point
to
two
devices,
one
of
which
has,
and
then
confidentiality
of
the
internet,
the
other
of
which
goes
to
recording
entity,
that's
required
by
Clea
or
whatever
so
I
mean
I.
Think
there
are
solutions
to
that
this.
This
particular
mechanism-
and
this
is
gonna-
be
true
to
anything
that
kind
of
follows.
D
The
purpose
mandate
is
looking
at
just
enabling
that
and
and
the
security
between
two
endpoints
and
so
yeah
it's
it
is
necessarily
going
to
be
antagonistic,
I
figured.
This
would
not
be
something
that
people
be
looking
at
service
writers
like
help.
This
happen
in
this
instance,
because
of
that
it
very
very
well.
L
I
understand
that
I
mean
it
could
be
just
in
domain
of
I,
want
n
dem,
sip
media
security,
and
that's
that's
it,
but
if
you're
talking
about
service
providers
there
and
I'm,
assuming
that
it
would
be
beneficial
if
there
was
some
way
in
the
future
that
this
could
happen.
But
you
know
the
problem
is
we
do
have
men
in
the
middle
apartments
there
some.
D
Do
but
I
really
on
the
side
of
his
noting
that
concern
they
get
another
purpose
threat
model
and
understands
that.
Certainly-
and
that's
that's
what
we're
coding
to
here,
basically
in
the
standard
exelon,
leaving
that
one
the
size
of
the
moment
unconnected
identity.
So
one
of
the
interesting
properties
of
stir
is
that
it
only
works
on
requests.
D
You
cannot
sign
responses
and
stir
there
a
number
of
historical
and
technical
reasons
for
that
back
in
the
day,
john
LOL
hack,
together
the
connected
identity
draft,
to
try
to
remedy
this
I've
kind
of
looked
it
over
a
bit
because,
basically,
we
need
the
same
thing
for
this.
Ultimately,
because
we
need
the
two
end
points
to
both
originate.
You
know,
signed
identity.
Header
is
basically
using
stir.
We
need
them
to
use
something
like
connected:
identity
connect,
identity,
among
other
things,
relaxes
the
requirement
that
you
maintain
certain
dialogue.
D
Tags
like
the
same
from
header
field
that
it
was
named
to
hetero
filled
this
in
the
original
request.
Things
like
that,
in
order
to
be
able
to
show,
especially
for
the
dialogue,
requests,
early
responses
and
things
like
that
that
what
the
actual
target
was
that
a
call
reached-
and
this
is
really
necessary
for
any
of
this
to
work,
because
you
need
to
sign
for
that
identity
if
that
identity
was
in
fact
not
in
Europe
industry
of
domain,
because
this
call
was
forged,
you,
you
literally,
wouldn't
be
able
to
sign
it
unless
you're
changing
those
identifiers.
D
I've
looked
at
49,
16,
I'm,
not
sure
I
see
much
that's
a
problem
and
since
I
mean
there's
a
lot
of
examples
there
that
use
4474,
there's
a
lot
of
4474
specific
language,
I'm,
not
sure,
there's
enough
that
it
warrants
like
an
update
but
I'm
interesting
opinion
of
some
so
I'd,
like
someone
other
than
me
like
who's
here
to
like
Rita
at
some
point
and
see,
if
that's
also
their
assessment.
I
just
didn't
see
a
lot
that
looked
like
it
needed
to
be
repaired.
I
D
H
D
Where
we
need
is
somebody
who
can
read
4916,
who
has
some
familiarity
with
what's
in
4474
bits
and
how
it
differs
from
4474
and
say:
okay,
given
the
deltas
between
4470
400m
four
bits,
is
there
anything
we
actually
need
to
change
about
the
campy
identity
mechanism?
Let's
not
focus
on
whether
it
you
know,
uses
the
term
identity
info
right
and
places.
So
there
are
things
that
were
deprecated
in
4474
best.
Let's
focus
on
whether
any
of
the
things
you
normatively
are
required
to
do
to
implement.
It
would
would
change
because
of
this
Adam.
G
D
M
D
That
you
know
I
wrote
a
draft
about
this
way
back
in
the
day
that
was
called
the
unanticipated
response
draft
that
I
refer
to
all
the
time
since
then
that
we
never
made
Narcy,
but
that
basically
asks
this
question
you
see
post
and
bought
here.
Wait
I
didn't
mean
to
call
this
person.
Why
am
I
connected?
Why
are
they
my
connected
identity,
like
you
kind
of
throw
sip,
invites
over
the
wall
and
they
get
routed,
and
you
don't
know
why
things
are
forwarded
or
what
happened
in
the
network.
D
Now
there
have
been
a
number
of
drafts
that
have
addressed
this
over
the
years
history
info
to
version
things
like
this,
and
they
have
various
levels
of
uptake
in
the
marketplace
because
of
the
cryptography
associated
with
this
in
particular,
though
I
think
a
cryptographic
solution
is
probably
warranted
for
this
and
I
took
a
stab
at
this,
because
people
keep
complaining
about
this
as
well
on
the
store
list.
There's
a
draft
now,
a
draft
Peterson
stir
divert
that
looks
at
a
special
passport
header
that
basically
does
a
cryptographically
signed
diversion
that
just
lets.
D
D
This
is
something
also
came
up
in
astor
list.
You
know,
should
you
do
people
want
some
kind
of
middle
ground?
Maybe
an
opportunistic
stir,
as
sex
I
have
a
previous
slide
on
opportunistic
stir
in
Berlin.
They
talked
about
something
different
than
this.
Do
we
need
a
way
that,
when
you're
trying
to
use
this
m/sec
mechanism,
you
still
want
the
call
to
set
up
if
the
other
side
does
not
support
media
security?
D
You'll
know
that
it's
not
encrypted,
don't
be
any
ambiguity
about
that,
but
you're
still
willing
to
let
the
call
be
set
up
if
it
turns
out
that
encryption
cannot
be
negotiated
and
that
this
is
no
I
mean
you
could
always
try
with
them
sack
and
then
you
know,
try
it
again
without
hit
right.
I
mean
it
invites
your
cheap,
but
if
we
wanted
to
do
that,
I
think
there
is
a
reading
on
stir
and
especially
if
it's
extensibility
mechanisms
that
kind
of
wood
already
allow
this.
D
If
we
wanted
it
in
that
the
authentication
service
right,
the
only
indication
it
really
gets
that
the
alternate
side
supports
em
sack
is
when
it
sees
this
request
in
the
backwards
direction
that
contains
the
answer
that
is
going
to
contain
the
em
sack
you
know,
passport
type
in
it,
and
if
the
authentication
service
is
feeling
forgiving
right,
it's
on
the
originating
side.
So
it's
in
this
instance
it's
supposed
to
be
coupled
with
the
end
user's
device,
the
end
user
would
control
the
authentication
service.
D
In
this
instance,
it
gets
feeling
for
giving
it
could
just
be
like.
Okay,
like
you
know,
you
don't
support
him
sack.
You
obviously
didn't
understand
the
identity
header
in
here,
there's
no
identity
at
or
whatsoever
on
the
response
or
whatever
fine.
Let's
just
like
set
up
a
call.
I
could
like
document
that
it's
I
don't
think
it
breaks
anything
in
stir
to
do
that.
But
I
was
curious
if
people
thought
that
was
even
worth
documenting
or.
M
D
We
want
to
take
a
strong
stand
and
say
actually,
when
you're
using
em
sack.
Don't
do
that
like
that,
that's
the
alternative
right
we
could
say
if
you
send
em
sack,
is
an
authentication
service
and
you
get
back
from
the
other
side,
something
with
no
idea.
You
had
to
wear
them
sec
in
it.
You
must
feel
like
right,
wait,
I,
don't
think
we
quite
say
that
yeah
we
could
right
now
it's
just
a
bit
ambiguous,
I,
think
that
is
Cullen.
Then
crisper
than
Jonathan,
hey.
J
G
Killing
James
I
mean
I
think
we
should
describe
something
like
this.
When
you
look
at
practical
deployments,
they
have
to
figure
out
how
to
solve
this
problem
and
they'll
all
do
it
differently.
We
like
won't,
like
the
answer
and
they'll
paint
us
into
corners
that
we
can't
get
out
later.
If
we
don't
end
up
describing
this,
so
I
would
prefer
to
describe
it
and
then
decide
whether
we
say
you
know
we
truly
hate
this,
but
no
you'll
do
it
anyway.
G
K
D
I'm
talking
about
what
the
baseline
stir
behavior
there
is
in
the
second
hole
subpolar.
We
could,
however,
override
that
right
we
could.
We
could
say
you
must
fail
this
for
this
specific
profile
again,
the
same
way
that
shaken
is
a
profile
of
stir.
This
is
a
profile
of
stir.
We
could
say
that
in
these
cases
we
wanted
to
ban
it
right
now,
it's
just
a
loophole
that
I,
don't
say
anything
but
either
way
and
I
observe
this
loophole
existed
because
people
like
dave
Franco
are
asking
a
master
list.
Is
their
way
to
do
this?
D
Opportunistic
lid
right
now
say
well,
you
could
so
I
mean
I.
Think
the
question
is:
do
we
even
if
we
say
nothing,
we're
still
allowing
it?
We
could
instead
of
saying
nothing,
explain
how
to
do
it
right
and
say
this
is
by
the
way
the
simple
exists
feel
free
to
exploit
it
alternately.
We
could
say
right,
you
can't
do
it
and
make
it
a
must
not
for
this
profile.
Would
you
prefer
any
of
this
three
options.
K
This
guy
I
mean
the
only
thing
what
what
I
want
to
do
is
assuming
I
mean
I'm.
The
verifier
and
I
only
support
stir
I
mean
a
stun,
easter
and
I
get
this
invite
with
this
m/sec
or
whatever
you
call
it
and
I
have
no
idea
of
it.
I
don't
know
what
it
is.
It's
just
something
to
me,
which
is
then
clip
on,
but
it's
still
ok
for
me
to
indicate
this
goal
as
being
verified.
D
My
Lou
we're
not
changing
that
paper,
I'll,
really
the
only
behavior
the
beaver
would
be
back
on
the
authentication
server
side
right.
The
the
changer
that,
if
we
were
to
make
a
change,
would
be
that
when
the
purifier
side
sends
back
the
response,
the
invite,
if
not
doesn't
use
em
sack,
we
could
say
because
the
original,
the
call
does
like
that
you
have
to
fail.
Yeah.
I
Gentleman
x,
yeah,
I
was
going
to
comment
that
I
think
that
they're
probably
should
be
some
warnings
that
even
if
you're
doing
opportunistic
you
know
you
call
this
guy
yesterday
needed
em.
Second,
you
called
him
today
and
he
doesn't
you
know,
that's
not
the
same
thing
as
I'm
calling
somebody
out
of
blue
and
they
don't
do
em
sexo
yeah.
D
I
So
I
mean
sort
of
like
inverse
tofu
or
something
yeah
so
on
the
other
related
thing,
but
you
know
what
you're
saying
here
is:
if
I
wondering,
if
you
want
anything
in
baseline
stir
for
basic
comprehension
mandatory,
you
know.
If
you
don't
understand
this
field
either
you
know
ignore
identity
entirely
or
even
reject
the
call.
So.
D
That
that
texas,
air,
it's
pretty
good
at
the
difference,
is
the
differences
this
to
Christers
point
we
don't
we
don't
prescribe
that
you
have
to
reject
the
call
right
when
you
prescribe,
if
you
don't
understand
the
ppt
type
in
that
entity
header,
you
can't
use
it
now.
It's
then
local
policy
up
to
you
what
that
means
right
if
there's
another
at
any
header,
you
do
understand.
In
addition
to
this,
one
obviously
can
use
that
I
hear
you
understand.
If
you
don't
require
identity,
all
you
can
still
process.
M
Yeah
Eric
school
yeah
I
think
that
it's
gonna
be
pretty
common
demonstration
where
you
admit
this
stuff
for
their
guys,
like
I've,
never
heard
of
this
crap,
so
I
I
don't
see
how
we
don't
I
I,
don't
know
how
much
is
talking
with
this
loophole
forces
less
if
we
allow
it
to
continue
to
exist.
Well,
that's
one
of
the
questions
I'm
asking
yes.
D
M
F
M
D
M
Look,
I
will
mention
that
I'm
I,
this
came
up
earlier
eyes,
just
for
ought
to
mention
it
I'm,
not
very
enthusiastic
at
the
tofu
mechanisms.
I
think
existing
evidence
with
systems
are
much
better
manners
than
this.
That
have
tofu
style
mechanism,
specifically
HP
KP.
Is
that
actually
it's
not
worked
out
very
well
and
people
are
extremely
reluctant
to
actually
commit
to
any
set
of
key
material
and,
and
it
causes
Buster's
gonna,
try
so
I
guess
this
is
a
situation
where
the
chance
that
I'm
gonna,
like
you
know
but
yeah.
M
How
many
times
is
like
the
people
have
to
restore
you,
start
their
phones
and
reinstall
our
phones
and
lose
their
keys
if
the
consequence
of
like
losing
your
key
is
like
everybody
that
is
it
like.
You
actually
talk
to
all
time,
can't
talk
to
you.
That
seems
like
a
not
very
attractive
outcome.
So
I
got
it.
D
Okay,
so
I
think
it
sounds
to
me
like
we'll,
probably
go
with
explicitly
documenting
that
at
least
noting
this
loophole
exists
and
what
it
would
look
like
in
practice
to
use
this
opportunistically
next
slide.
So
I
mean
that's
really
my
issue
list
for
this.
You
know
we
can
tighten
that
m/sec
tax.
That's
a
good
example
of
something
we
tighten
that's
an
example
of
a
failure
case.
Definitely
having
some
concrete
examples
in
the
draft
would
probably
help
as
well.
I
think
this
is
at
a
mature
enough
state
that
we
could
start
looking
at
those.
D
We
could
probably
borrow
them
pretty
pretty
much
from
the
existing
examples
we
build
for
passport
and
for
RC
4474
bits
at
some
point.
We
want
to
make
sure
we've
handled
WebRTC
alignment
on
this
Cullen
in
a
sense
of
like
you
know.
One
of
the
things
that
we
really
hope
for
out
of
this
mechanism
is
that
it
will
be
possible
to
have
ended
media
security
from
a
sip
endpoint
using
stir
to
a
WebRTC
endpoint
or
we.
D
We
have
to
add
that,
as
a
stretch
goal
in
this
particular
Kickstarter,
that
is
sip
brandy,
so
I
mean
I'm,
not
sure
that
we
need
to
do
anything
other
than
not
closed
doors.
That
will
prevent
us
for
doing
that
later.
At
this
point,
and
your
draft
about
this
is
appreciated
and
give
some
context
around
that
of
what
the
doors
are
we
shouldn't
close,
but
the
sense
of
getting
is
were
probably
cool,
yeah.
G
I
mean
just
a
status,
update,
I
think
right
now.
It's
it
we're
even
better
than
doors,
open,
I
think
would
actually
work
from
what
we
have
right
now.
I
mean
yeah.
There's
like
Martin
and
I
have
a
PR.
That's
in
on
web
RTC.
Stop
this.
You
know.
Change
is
happening
but
I
like
I
think
this
is
looking
like.
We
might
get
the
stretch
goal
Martin
you
you.
D
P
D
D
B
D
I'd
be
interested
to
hear
about
that
when
the
time
comes,
that
much
said,
I
mean
I.
Don't
think,
there's
like
a
ton
more
to
do
here
right,
miss
bcp
is
merely
you
know,
stitching
together
existing
work,
that's
been
done
elsewhere.
It
creates
this
new
profile
and
extension.
I
still
think
we're,
probably
pretty
good
shape
to
get
by
March,
especially
given
it
provided
stir,
does
not
change
15
more
times,
and
the
next
do
four
months
which,
at
this
point,
I
think
seemed,
seems
unlikely.
I
think
we
should
be
in
pretty
good
shape.