►
From YouTube: IETF109-RUM-20201118-0730
Description
RUM meeting session at IETF109
2020/11/18 0730
https://datatracker.ietf.org/meeting/109/proceedings/
A
B
A
C
C
A
Yeah,
just
a
second
I
gotta
share
here.
C
A
A
I
think
most
everybody
here
has
been
been
to
a
meeting
an
ietf
meeting
before.
If
you
haven't
ever
read
the
note:
well,
you
better
read
it.
It
has
to
do
with
how
you
participate
in
all
kind
of
legal
crap.
A
That's
why
we're
at
this
ungodly
hour.
A
So
welcome
to
rum,
we
haven't
done
much
for
quite
a
while
a
little
bit
of
mail
discussion,
we're
hoping
to
get
things
going
and
hopefully
finished
before
too
long.
We've
only
got
one
thing
on
the
agenda
really
and
just
to
talk
about
the
open
issues
on
you
know:
draft
ietf
from
roof.
A
And
other
than
that,
we'll
you
know
that's
all
we
got
to
do
today.
If
anybody
else
has
something
else,
they
want
to
add
to
the
agenda
and
it's
a
good
time
to
speak
up
and
say
what
it
is.
B
A
C
I
know
I
can
push
the
slides
note
well.
C
I
I
didn't
hear
that,
but
that's
okay,
it's
a
itf
meeting
and
subject
to
the.
A
C
So
I'm
going
to
publish
the
screen.
Yes,.
C
E
Okay,
weird
invitation,
you've
shared
the
medico
documentation.
C
Yeah
this
this
should
be
well
all
right.
Let's
try
it!
It
should
be
here
all
right.
Let's
try
hang
on
one.
Second,
go
back
to
this:
stop
sharing,
publish
screen,
yes,
chrome,
tab.
C
There
share
how's
that
that's
better
okay,
wrong
button,
okay,
so
the
two
issues,
the
first
one
is
the
provider
controller
over
unauthorized
applications
and
the
other
is
the
configuration
file,
which
is
how
credentials
for
registration
are
kept,
especially
when
the
provider,
when
the
user
has
more
than
one
provider
that
he
sees.
He
has
two
telephone
numbers
from
two
different
providers
or
more
than
one
so
starting
with
the
first
one
providers
wanted
to
control
over
what
apps
get
access
to
their
infrastructure,
reasonable
requests
request
in
in
closed
systems.
C
The
example
is
the
easy
example
is
ios
the
way
they
do,
that
is
they
sign
code
and
the
system
that
loads
programs
only
allows
sign
code
to
load.
So
you
they
have
very
tight
control
over
what
apps
can
run
you.
You
can
only
run
apps
that
come
from
the
ios
store.
We
don't
have
a
closed
system.
You
could
have
one
on
ios
if
you
had
an
ios
app,
but
that
that's
roughly
it
other
than
that.
C
C
The
the
alternative
that
most
people
use
for
this
kind
of
thing
is
what
we've
been
calling
an
api
key
and
an
api
key
is
a
is
a
as
a
string.
C
C
You
can't
steal
a
key
from
another
program
and
it
it
it
can
be
provided
per
provider
right,
so
each
provider
could
have
their
own
key
and
the
app
could
put
the
right
key
in
typically,
you
send
this
as
a
header
or
a
json
object
in
an
https
transaction.
That's
typically
how
it's
used.
We
could
do
that
or
we
could
send
it
in
a
sip
header.
Maybe
a
call
info
header
in
the
register
operation.
C
So
both
of
those
are
possible
and
the
the
the
the
question
on
the
floor
is
is
this
is
an
acceptable
mechanism.
If
it
is,
I'm
happy
to
write
the
text
for
it,
and
we
can,
you
know,
can
make
sure
that
that
that
that
says
what
we
want
and
all
that
other
stuff,
but
I'm
I'm
very
happy
to
create
the
text
that
that
defines
how
an
api
key
is
used.
I
will
I
would
like
to
have
a
discussion
on.
C
Do
you
want
it
on
the
register
or
just
do
it
with
an
https
transaction
and
and
we
can,
we
can
work
out
how
all
the
details
work.
So
I'd
I'd
like
to
have
some
discussion
now
about
that,
and
you
know,
is
this:
what
what
what
providers
want
is
is
is
doing
it
in
https
enough
or
do
you
want
it
to
be
done
in
in
the
sip
register
happy
to
do
it
either
way,
whatever
whatever
works,
is
fine
and
and
are
there
any
other
questions
or
suggestions
or
or
whatever?
C
So
the
the
floor
is
open
for
people?
We
have
a
small
number
of
people
who
are
here
if
you
want
to
use
the
cue
by
all
means.
Do
that
that's
our
normal
process
is
put
yourself
in
the
queue
and
and
we'll
recognize
you
or
you
can
just
unmute
and
talk
and
it'll
be
all
right.
There's
a
small
number
of
us.
B
I
personally
feel
that
using
it
outside
of
sip
would
be
a
good
option
as
an
https
transaction.
B
You
know
when,
when
we
actually
do
the
register
and
those
types
of
things,
of
course
we're
in
sip,
but
if
it's
pre-sip
connection,
maybe
just
using
the
https
transaction,
would
be
a
good
option.
I'm
certainly
not
expert
in
the
security
of
of
things.
So
maybe
I
don't
understand
why
putting
it
in
the
sip
header
would
be
a
better
way
to
go.
I'm
not
sure.
C
It
just
avoids
having
to
do
that.
Https
transaction.
That's
that's!
Really!
The
only
thing
I
I
actually
like.
I
prefer
to
do
it
with
https
only
because
it
it's
kind
of
the
normal
way.
You
know
you're
kind
of
you're,
you're,
you're,
you're,
falling
down
a
hole,
that's
been
been
well
smoothed
out
and
and
and
so
if,
if
you
ask
me
what
I
think
we
want
to
do,
I
think,
let's
just
do
it
with
an
https
transaction
that
happens
before
the
register.
It's
an
authorization
step
that
you
have
to
do.
C
Your
register
will
be
rejected.
If
you
don't
do
it
and
and-
and
I
I
think,
that's
a
perfectly
reasonable
thing
to
do.
That
would
be
my
preference
I'd
rather
not
go
mess
with
sip,
but
I'm
happy
to
do
that.
If,
if,
if,
if
that's
what
what
we
want.
A
A
One
thing
I
was
wondering
about
about
this
is
has
to
do
with
the
the
mechanism
by
which
these
things
get
author,
you'll
get
certified
or
you
know,
verified
or
whatever
you
know.
C
I
think
that
that's
that
we
can
make
that
out
of
scope
for
our
spec
and
the
providers
can
decide
among
themselves
how
they
want
to
do
it.
We
can
make
the
mechanism
work
both
ways
and
and
you
you
can
have
the
same
key
for
all
providers.
You
can
have
independent
keys.
I
I
I
given
that
the
itef
is
international.
I
don't
want
to
bias
this
towards.
C
You
know
the
the
the
u.s
providers
and
let
them
decide
and
make
that
stick
for
everybody,
so
I
I,
unless
they
all
think
that
the
right
thing
to
do
is
once
somebody
tests
and
then
everybody
accepts
that
is
acceptable.
C
I
think
it's
simpler
than
that.
The
there's
already
the
remember
there
there's
already
the
configuration
file,
which
is
common,
which
is
the
list
of
available
providers
right.
So
if
you
have
the
list
of
available
providers,
then
you
can
have
a
list
of
keys
associated
with
each
provider
and
substitute
the
right
one
when
you,
when
you
go
in
so
it's
pretty
easy
to
make
it
work
per
provider.
A
C
No,
I
think
again.
I
think
that
the
way
the
spec
could
be
written
is
that
that
it
can
be
per
provider
or
it
can
be
one
and
and
and
it
basically,
if
it's
if
it,
if
you're
in
an
environment
where
there's
only
one,
then
there'll
only
be
one
and
if
you're
an
environment
where
there's
more
than
one
you
know,
there's
one
per
provider,
then
you'll
have
you'll,
have
to
have
a
configuration
of
one
one
per
provider,
but
I
think
that's
it
even
could
be
mixed
right.
C
C
In
fact,
it's
built
into
the
code
right
or
it
could
be
built
into
code
for
a
particular
region.
Anyways
can.
Can
we
hear
from
other
people?
What
they
prefer
to
see
is
what
do
you
think
this
ought
to
be
one
one
per
provider,
or
you
know
a
keeper
provider
or
or
do
you
think
that
it
actually
might
work
out
to
be
one
for
a
region.
B
G
F
So
jim
here
so
everybody
else
is
being
quiet
today,
having
listened
to
the
providers
for
for
a
number
of
years
on
this
topic,
it's
not
at
all
clear
to
me
that
provider,
a
is
going
to
be
satisfied
with
provider
b,
is
testing
that
this
is
not
impactful
to
their
service.
F
So
you
again
it's
a
regulatory
issue
right.
Do
we
have
a
an
individual
certifying
entity
that
does
the
testing
and
says
this
works
for
all
providers,
or
does
each
provider
have
to
do
that?
Brian?
Your
earlier
point,
I
think
that
that
could
be
locale
specific
right
just
because
the
us
decides
to
do
it.
One
particular
way
doesn't
mean
that
another
country
would
do
the
same
thing
so
suspect
in
the
us.
We
would
be
looking
at
a
per-provider
certification.
G
C
Yeah,
I
I
I
I
think
I
have
some
ideas.
I
want
to
noodle
them
in
my
head
and
I'll
write
some
text
down
to
make
it
possible
to
be.
You
know,
region
specific
where,
where
it
could
be
in
one
region,
it's
one
way
in
another
region.
It's
another
way
that
that's
fine
and
do
recall
that
if
we
realize
maybe
not
recall
but
realize
that
if
it's
implemented
per
provider
and
two
providers
decide,
oh
look
we'll
we'll
trust
each
other's
keys.
C
C
Any
other
comments
I
I
thought
I
heard
someone
else
try
and
get
in
when
jim
started.
Is
there
someone
else.
D
C
C
You
know
I
mean.
D
C
Right
right,
so
so
for
those
of
you
who
are
not
following
this
there's
the
notion
of
using
something
like
oauth,
which
is
a
single
sign-on
mechanism
right,
so
the
there's
there
would
be
some
sort
of
identity
provider
and
again
you
could
have
one
per
region
or
you
could
have
one
per
per
provider
and
and
and
then
well.
I
guess
it'd
have
to
be
one
per
region
in
order
for
that
to
work
right.
C
So
then
you
get
a
key
that
that
you
can
use
with
the
identity
provider
to
prove
to
another
provider
that
you're
good.
I'm
not
sure.
How
would
you
how.
F
C
D
Well,
I
mean
what
one
thing
is
identity
to
provide.
The
other
is
how
you
register
the
services,
but
I
guess
it
depends.
I
mean
sweden,
you
get
kind
of
public
funding,
you
get
authorized
to
use
a
service,
then
you
go
pick
a
service
on
the
market.
C
D
Right
so
I
mean
maybe
you
could
use
your
facebook
account
to
log
in,
but
the
providers
has
to
get
in.
I
don't
know
you
can
also
look
at
something
like
saml
or
eduroam,
where
you
have
a
account
in
one
university.
Can
log
into
all
universities
that
provide
services?
C
G
C
I
I
get
that,
but
I
I
I
I'm
still
not
exactly
clear
how
it
would
work
if
you
could
sort
of
maybe
send
an
email
to
the
list
describing
how
you
think
it
would
actually
work.
I'm
I'm
having
trouble,
I
mean
I
kind
of
understand
the
concept,
but
I'm
I'm
having
trouble
understanding
the
mechanics
and
maybe
I'm
being
biased
by
what
jim
said,
which
is
in
in
north
america.
It
would
be
hard
to
have
a
single
anything.
C
It's
likely
to
be.
You
know
the
per
provider
kind
of
world
and
providers,
don't
necessarily
trust
each
other
in
some
circumstances.
Anyways,
sometimes
they
do.
Sometimes
they
don't
regulations
require
that
they
trust
them
in
certain
circumstances
and
in
other
circumstances
they
they
do
voluntarily
and
others
they
don't.
So
I'm
not
sure
exactly
how
it
would
work.
I
kind
of
see
the
idea,
but
I
don't
see
the
it's
not
clear
to
me,
how
that
how
how
it
would
actually
work.
So
if
you
could
kind
of
send
an
email
describing
how
it
would
work.
D
C
C
G
C
D
Another
question
about
the
api
key
is
whether
or
not
it's
just
a
random
string
or
if
it's
actually
a
token
that
contains
some
data
like
we
use
in
open
id
connect
or
something
is
this
assigned
something
by
something
that
we
can
use
to
transport
some
sort
of
data?
Just
an
open
question
in
many.
E
C
So
yeah
I
mean
typically
an
api
key.
Doesn't,
although
they're
actually,
what
I'm
no.
C
C
Yeah
yeah
sure
sure,
yep,
yeah
yeah
sure
you
put
the
time
you
issued
the
key
and
all
kinds
of
other
great
stuff
in
it.
It's
just
the
string,
so
you
know
put
some
data
in
it,
digest
it
and
you're
done
yep,
okay,
anyone
else
with
with
thoughts
on
that
I
mean
it
seems
like
the
api
key
is
acceptable.
C
Ali
is
talking
about
a
possible
alternative,
so
we'll
let
them
see
if
you
can
write
down
how
it
would
work
and
look
at
it
as
an
alternative,
but
I
I'm
hearing
that
api
key
will
be.
Okay
is
that
is
that
true?
Is
there
anyone
who
who
doesn't
think
that
it
would
be
acceptable
to
use
an
api
key?
Is
the
solution
to
this
problem.
C
F
Jim
here
very
quickly,
ali
you
mentioned
perhaps
using
your
facebook
id
as
as
a
as
a
common
mechanism
for
this,
because
then
you
already
have
the
centralized
infrastructure,
but
the
facebook
id
is
attached
to
the
user,
not
to
the
device.
Something
to
keep
in
mind
as
you
as
you
write.
Something
up
here
is
that
it
really
does
need
to
be
tied
to
the
device.
F
So
I
just
wanted
to
point
that
out.
I
either
I'm
missing
something
or
or
that
doesn't.
Okay,
quite
work.
D
C
G
H
I
just
had
a
an
rfc
that
sprung
to
mind.
I
I
don't
know
the
oauth
is
the
way
we
would
want
to
go.
I
just
I
noticed,
there's
a
best
practice
roc8252
on
oauth
for
native
apps.
H
A
C
C
So,
even
if
we
decided
full
start
that
we're
gonna
do
the
api
key,
we
would
still
have
to
go
back
to
the
list
and
ask
people
their
thoughts
on
it,
so
that
that's
just
our
process,
but
I'm
what
I'm
hearing
at
the
moment
is
an
api
key
is
acceptable,
as
is
an
acceptable
answer
and
we
might
have
an
alternative
answer
using
something
like
oh
after
saml
ollie
is
going
to
go
and
write
up
how
he
thinks
that
might
work
and
we'll
consider
it
we'll
do
that
on
the
list.
C
I'll
start
writing
text
for
api
key
once
we
make
the
decision
on
the
list
on
if
ellie's
idea
has
merit
I'll
I'll,
you
know.
If
we
decide
that,
then
then
he
may
probably
I
will
cooperate
on
creating
some
text
for
that
idea
and
otherwise
they'll
be.
The
next
version
will
have
either
the
api
key
or
or
or
if
this
oauth
saml
id
works
out,
we'll
we'll
have
that.
So
that's
what
I'm
hearing
I'm
going
to
do
as
author
and
and
so
that
and
it's
good
from
my
point
of
view.
C
C
I
I
note
that
almost
every
voip
device
you
you
have
has
such
a
file
and
it
does
in
most
of
the
way,
are
in
clear
text,
which
is
not
a
good
idea,
but
it's
there.
It
has
a
local
storage
of
username
and
password
and
and
most
store
the
the
more
than
one
provider.
C
You
know
a
multi-line
phone
right,
so
you
can
have
all
the
configuration
information
for
each
of
your
lines
on
your
on
your
voip
phone
in
that
local
storage
and
that's
what
we're
replicating
that
that
you
know
what
a
voip
phone
does
you
you
can
configure
each
line
with.
You
know
where
the
proxy
server
is
and
what
your
username
and
password
is
and
what
your
telephone
number
is
and
all
the
other
good
things
that
are
provisionable
in
that
configuration
file.
Your
turn
servers.
C
C
So
we've
had
lots
of
ideas
that
have
been
tossed
around
on
the
list,
including
using
open
id
or
saml
as
a
way
of
authenticating
users
and
then
getting
configuration
out
of
that
or
we've
talked
about
having
a
local
login.
So
the
app
would
have
a
username
and
password
that
the
user
would
put
in.
C
That
would
unlock
the
configuration
file,
and
so
a
lot
of
these
ideas
have
been
thrown
around
and
I'm
hoping
that
we
can
have
a
good
discussion
now
on
what
we
want
to
do
and,
and
hopefully
we'll
come
up
with
at
least
a
tentative
answer
or
more
than
you
know,
one
at
least
one
answer
that
we
can
start
writing
text
on.
So
again,
the
floor
is
open
on
on
ideas
for
how
we
handle
this
configuration
file.
D
D
I
think
using
a
setup
where
we
have
some
sort
of
certificate
enrollment,
where
the
run
device
create
a
key.
Parry,
gets
a
certificate
somehow
and
then
use
that.
Then
we
can
bootstrap
configurations
by
having
encrypted
configurations
that
encrypted
with
the
public
key
of
the
device,
and
we
can
use
the
certificate
for
authentication
and
sip,
which
is
a
really
good
thing.
D
C
Well,
I
personally
am
with
you
ali.
A
lot
of
people
have
a
lot
of
code
that
uses
all
that
stuff
and
they're,
sometimes
reluctant
to
to
to
replace
it
with
something
more
modern.
But
if
it
were
up
to
me,
I
would
do
that.
C
C
You
know
with
with
real
certificates
instead
of
username
password.
Instead
of
you
know,
digest
and
and
he's
advocating
using
that.
D
How
you
get
that
certificate
is
an
interesting
prospect,
but
since
we
have
an
https
transaction
in
the
beginning,
we
can
do
a
lot
of
things.
Assuming
we
have
a
user
interface
that.
C
Well:
okay,
but
in
a
standards-based
environment,
let's
say
that
we
did
that
that
we
we
had
an
http
transaction,
so
we've
got
a
certificate.
We've
done
some
local
authentication
using
that
certificate
to
create
the
https
transaction.
We've
created
a
tls
session
using
that
certificate.
You
know
mutual
off
so
now
what?
Now?
What.
D
C
F
D
The
thing
is:
there's
a
lot
of
ways
to
set
up
server
certificates.
You
have
acme,
you
have
a
lot
of
protocols
for
doing
that
for
the
client
certificates.
We
have
an
old
c
party.
That
is
well,
it's
beautiful
con
considering
those
times,
but
it
doesn't
work
anymore.
D
You
need
to
have
first
an
agreement
on
a
device
id
right
and
is
that
the
same,
the
the
login
on
the
device
is
that
the
same
as
the
user
login?
It's
the
user
login.
We
want
here
right.
D
Using
to
protect
the
register-
and
there
are
a
lot
of
I
mean
you-
you
can
take
oauth
and
start
with
an
oauth
or
sample
login
that
ends
up
in
a
certificate.
I
did
that
15
years
ago
in
the
university
environment,
so
we
had
a
saml
login
where
you
say.
Oh
I'm
from
this
university,
and
I
got
my
certificate
after
that
and
used
the
client
certificate
to
get
the
provisioning
for
my
special
version
of
bria
software
and
then
use
the
client
search
to
bootstrap
the
tool.
C
D
We
need
them,
we
need
an
authentication
mechanism
and
maybe
we're
not
at
the
authorization
level,
and
we
need
an
authentication
mechanism
that
ends
up
in
a
client
search
and
the
client
cert.
We
want
to
be
using
in
the
zip
layer.
D
D
A
A
A
C
A
C
C
I
I
indeed
and
and
and
we
can
we
can-
if
we've
got
a
cert,
then
we
can
maintain
assert
and
do
the
startup
that
that
paul
is
talking
about
and
handle,
revocation
and
all
the
other
things
that
go
along
with
certs.
Then
the
cert
can
be
used
for
mutual
off
with
tls.
The
cert
can
be
used
for
mutual
off
with
sip.
I
mean
you
could
do
that.
C
Yeah
yeah
acme
is
here
to
save
you,
so
you
know
yeah
three
months.
D
D
D
E
D
Of
assert
is
over
night
over
an
open
id
token
yeah.
We
we
we
have
that
document,
but
it's
well
needs
to
be
discussed,
because
that
I
put
in
a
requirement
of
an
encrypted
token
and
there's
not
many
implementations
of
that
and
that's
why
I'm
hesitant
to.
D
C
Okay,
so
the
there's
there's
this
proposal
to
widen
this
whole
thing
out
and
use
search
for
everything.
That's
a
change
to
how
registration
would
work.
It's
a
change
to
how
I
mean
the
whole
sip
authentication
process
works.
Is
that
something
that
that
that
we
can
consider
is
that
is,
is
that?
Is
that
reasonable
to
think
about
putting
into
this
spec.
C
A
Well,
they're
thinking
about
it.
The
one
thing
about
like
using
the
client
cert
is
that
I
think
it
only
makes
it
as
far
as
the
the
the
the
front-end
proxy
for
the
for
the
server.
It
doesn't
necessarily
make
it
all
the
way
to
the
registrar.
C
A
C
Is
kind
of
what
jonathan
was
getting
to
and
and
and
not
only
is
saying
yeah,
but
we've
been
doing
this
for
years.
So
I
mean
I
I
I
I
it's
doable
but
as
jonathan
says,
there's
not
a
lot
of
rfc
coverage
for
it.
D
I
think
we
can
start
with
agreeing
that
the
the
traditional
username
password
digest
authentication
is
safe
is
something
we
don't
want,
and
now
we
have
two
alternatives.
We
have
the
token
based
sip
authentication,
which
is
very
new
and
lacks
implementations,
and
I
kind
of
agree
with
eugene
that
if
you
have
an
ingress
proxy,
you
have
to
transport
the
client
search
somewhere
else
in
http.
You
do
that
frequently
in
a
header,
you
take
the
client
search
from
the
first
level
and
you
transport
it
in
the
header.
D
C
D
C
C
All
right
we
we
can
do
that
heck.
We
can
use
our
little
raised
hand,
tool
how's
that
I
I
would
actually
like
to
see
some
doc
some
discussion
before
we
go
there.
This
is
ollie
is
asking
if
sort
of
a
fundamental
question
right.
The
traditional
way
you
handle
authentication
for
sip
is
basic
or
digest
right
and
use
a
username
or
password
and.
C
C
Sorry,
don't
lie.
Sorry,
sorry.
I
said
the
wrong
thing
digest
so
he's
saying:
don't
do
that
do
something
involving
certs
or
or
oauth
tokens.
So
that's
the
he
wants
to
make
that.
The
first
question
is
that
a
reasonable
thing
to
do,
as
he
says
in
2020
we're
writing
a
spec
in
2020.
Is
it
reasonable
to
say
no?
No,
no,
we're
not
going
to
use
digest
we're
going
to
use
something
based
on
certs
or
or
or
oauth
tokens.
F
The
the
providers
weigh
in
here
because
they're
the
ones
who
are.
F
So
when
you
phrase
it
the
way
you
just
phrased
it,
it
seems
like
the
the
change
you're
looking
for
would
require
some
significant
logic
changes
to
the
the
platforms
that
the
providers
already
have.
That
would
impact
their
existing
clients
that
are
not
required
to
be
compliant
or
or
a
parallel
development,
so
they
could
handle
both
what
they
do
today
and
what
we're
proposing
here
well.
F
What
you're
saying
and
where
this
is
indeed
the
right
direction
to
be
going.
A
E
C
D
Your
audio
brian,
I
mean
we,
we
tr.
We
are
trying
to
leave
md5
behind
by
implementing
sha,
256
and
512
authentication.
It's
still
not
a
good
solution
to
have
username
and
secrets
in
clear
text
and
configuration
files.
Clear
text
has
never
been
a
good
option
and
we
have
severe
security
problems
with
those
solutions
because
of
the
possibility
of
downgrade
attacks.
D
We
have
no
document
yet
on
how
to
migrate
from
md5
in
existing
installations
to
a
stronger
one,
and
if
you
still
have
to
do
a
migration,
it's
better
to
take
the
leap
into
2020
and
do
another
kind
of
authentication
and
there's
a
lot
of
things
happen.
In
this
token,
based
authentication
area,
there's
a
new
working
group
in
itf
that
kind
of
works
with.
D
I
think
it's
gnapp
that
works
on
the
successor
or
an
alternative
to
oauth
2.,
so
token-based
authentication,
I
think,
is
the
way
to
go
or
client
search.
If
we
want
to
look
at
something
existed,.
C
We
have
eight
minutes
left
in
this
meeting.
I
I
would
really
like
to
hear
from
providers
what
they
think
about
this.
C
We
can
take
it
to
the
list
we're
running
out
of
time
to
do
anything
else.
Anyways.
A
C
A
A
C
That's
traditionally
how
it's
done.
It
would
be
cool
if
it
wasn't
that
hard
and
right
when
you,
when.
A
C
A
At
that
point,
it's
just
it's
it's!
It's
just
encoding
whether
you
talk
about
that
as
one
file
or
multiple
files.
It's.
A
C
B
C
C
A
C
D
C
Yeah
I
mean
we
can
we
we
can
automate
that
more.
I
I
I
think,
the
once
there
there
there
is
something
of
of
you
know
once
a
day
one
once
once
once
a
month
once
a
day,
and
once
every
time
you
log
in.
C
C
Well,
what
we
can
figure
it
out,
I'm
I
I
is
the
the
only
question
that
remains,
depending
on
on
where
we
go
with
ollie's
idea
of
using
samls
or
tokens
or
or
certs,
is
what
you
do
with
credentials
and
and
how
those
are
unlocked
right.
You
know
how
is
it
securely
stored
so
that
you
don't
have
to
re-enter
per
provider
credentials
every
time
you
log
in
that
that
that's
the
part
that
I
want
to
make
sure
that
we
do
right.
Clear
text
won't
work
right.
That's
the
clear
text
problem
right.
C
A
A
C
C
C
D
Or
are
we
discussing
multiple
states?
At
the
same
time,
we
have
a
configuration
provisioning
state
where
we
set
up
a
device.
We
authorize
ourselves
to
use
an
account
and
all
that
and
that's
one
thing,
and
then
we
bootstrap
kind
of
a
running
state
where
we
have
to
answer
incoming
calls
and
that's
another
thing.
I
think
we
have
to
separate
these
in
order
to
clear
the
running
state
involves
sip
and
answering
calls,
and
we
have
java
persistent
authentication
for
that.
D
C
Okay,
we're
we're
over
time
now
so
we're
going
to
have
to
close
it
out
and
go
back
to
the
list.
I
I.
E
C
Yes,
I
I
very
much
appreciate
everybody's
participation
in
the
session.
It
was.
It
was
very
helpful.
Let's
see
how
far
we
can
get
on
the
list
on
these
issues.
If
we
need
an
interim
meeting
or
something
else
to
work
out
one
or
more
of
these
things
we
can.
We
can
schedule
that
which
could
be
scheduled
at
a
different
time
scale,
but
thank
you
all
very,
very
much
for
for
showing
up.