►
From YouTube: IETF95-MODERN-20160407-1730
Description
MODERN meeting session at IETF95
2016/04/07 1730
A
C
Prince
barks
I
can't
I
have
another
meeting
schedule
that
will
be
stepping
out
to
deal
with
during
the
Middle
where
I
would
volunteer,
so
we
don't
need
a
blow-by-blow.
We've
got
a
recording
that
takes
care
of
that.
We
just
need
somebody
to
capture
the
the
major
action
items,
so
this
isn't
hard
if
you've
never
done
it
before
it's
a
great
way
to
you
know
make
sure
that
you
got
a
really
good
handle
on
what
the
conversation
is.
C
A
Thank
you
very
much
threat,
okay,
so
this
is,
as
I
said,
the
modern
working
group.
The
required
note.
Well,
please
do
note
it.
It
is
important,
you
see
it
every
every
meeting.
It
just
goes
over
your
head,
but
it
is
important
that
to
understand
the
IPR
rules
that
work,
we're
operating
under
here
so
you're
in
the
you're
in
this
meeting,
so
you're
agreeing
to
conform
to
to
the
moat.
A
Well,
the
agenda
do
some
agenda
bashing
here,
John
will
be
talking
about
modern
problems
and
and
we
will
be
trying
really
hard
to
move
beyond
the
modern
problem
strapped
and
on
to
other
working
group
items.
Tom
will
talk
about
NMP
that
he
talked
about
during
the
interim
meeting
a
little
bit
as
a
motivating
example.
Use
case,
of
course,
we'll
talk
about
the
about
drip
and
password
on
that
and
we'll
spend
some
time
talk
to
work
plan.
Next
steps.
I,
don't
expect
us
to
require
the
full
two
hours,
but
who.
F
G
Like
your
shell
tourney,
we
miss
you,
okay,
hi,
I'm,
John
I'm,
going
to
be
talking
about
our
problem
statement.
Next
slide
I
mean,
but
it's
really
not
just
like
a
problem
statement.
This
is
one
of
these
kind
of
grab
bags
of
there's
some
problem.
Things
expressed
in
it
there's
a
framework
that
tries
to
explain
the
ontology
that
we
see
behind
modern
what
the
actors
are.
G
What
the
data
elements
are
that
we
think
are
associated
with
that,
and
then
it
goes
through
and
enumerates
a
bunch
of
use
cases
related
to
the
three
major
protocols
that
we
and
we
aspire
to
develop
here.
Those
are
for
acquisition,
management
and
retrieval.
The
basic
notion
here,
of
course,
is
that
we
want
to
create
an
information
model
that
is
going
to
about
kind
of
what
information
you
need
to
have
about
telephone
numbers
on
the
internet
and
the
three
acquisition
management
and
retrieval
mechanisms
are
merely
going
to
be
operating
on
that
common
information
model.
G
This
has
kind
of
been
the
cell
of
this
that
takes
us
beyond
enum,
and
you
know
kind
of
the
early
thinking
we
had
orgies.
We
just
need
to
have
like
a
flat
file,
that's
going
to
map
telephone
numbers
like
sip
your
eyes
and
we'll
be
done,
and
it
seemed
like
a
really
great
idea
in
1999.
What
we
actually
discovered
is
we
really
need
an
entire
ecosystem.
That's
going
to
explain
how
these
how
these
numbers
are
created.
I
they
get
provisioned
how
they
get
managed.
G
Then
you
worry
about
how
they
get
retrieved
and
having
a
common
information
model
for
all.
That
seemed
essential.
That's
how
we
ended
up
here.
That
is
what
this
problem
statement
concerns
next
slide.
So
you
know
things
have
not
been
proceeding.
Super
expeditiously
or
smoothly
in
this
working
group.
There's
been
a
great
deal
of
controversy.
Let's
be
blunt
about
its
scope.
There's
been
I
think
a
great
deal
of
resistance
to
some
of
the
ideas
that
have
been
expressed
here.
I,
don't
want
to
sweep
that
under
the
rug.
G
So
what
do
we
do?
We
had
the
sinnerman
actually
was
quite
productive.
I
think
we
did
surface
some
of
the
issues
that
really
were
getting
people
caught
up,
especially
on
the
acquisition
protocol
and
the
way
that
we
had
cast
that
so
I
think.
The
good
news
is
that
we
made
some
tweaks
the
model,
and
hopefully
these
tweaks
will
alleviate
some
of
the
concerns
that
have
been
expressed
about
the
model
in
the
past.
G
We
hadn't
really
had
something
analogous
to
the
Registrar
of
the
domain
name
business
in
this,
and,
as
we
discuss
this
at
our
interim
call,
I
think
it
became
clear
that
that
would
be
a
very
useful
role
to
describe
within
this
architecture,
and
actually,
when
you
see
some
of
my
charts
and
this
I
go
see,
it
actually
fits
in
quite
well
clarifies
a
lot
of
things
for
me
about
how
the
allocation
model
works
and
about
how
thin
the
registry,
the
top
this
can
really
be.
We
also
changed
a
lot
of
the
end
user,
specific
text.
G
Okay,
there's
we
had
some
kind
of
forward-looking
left-wing.
Wouldn't
it
be
great?
If
consumers
could
you
know
own
their
own
telephone
numbers
and
stuff
and
henning
actually
very
wisely
pointed
out
to
us
that,
rather
than
dying
on
that
hill,
perhaps
what
we
should
do
it
instead
is
take
something
that
is
very
widely
and
practically
used
in
the
telephone
network
today,
which
is
free
phone
assignments
which
operate
in
precisely
this
register
registry.
G
Registrant
model
where
you
go
out
and
you
can
procure
effectively
a
registrar
if
you
are
a
resp,
org
right,
a
free
phone
number
and
then
shop
it
to
service
providers
at
various
competitive
rates
to
ascertain
who
is
going
to
propagate
it
that
that,
for
you
and
really
all
of
the
use
cases
we
can
show
for
this
are
now
practical,
real-world
use
cases.
That
is
one
of
the
major
revisions.
You'll
find
the
problem
statement
today
is
that
we've
been
that
we
also
decided
to
kind
of
let
drip
be
drip.
That
is
so.
G
We
have
a
mandate
within
this
working
group
as
well
to
explore
alternatives
to
centralize
monolithic
registries,
rather
than
really
the
tailing
that
we
kind
of
had
like
some
use
cases
for
it,
but
it
was
not.
It
was
not
deep
enough
to
be
useful
and
obviously
we
needed
more
context,
I
think
for
people
to
really
understand
what
those
distributive
registries
would
look
like.
So
what
we've
done
instead
is
just
we
have
definitions
and
things
like
that.
G
We
make
sure
people
understand
distributed
registries
or
something
in
our
scope
within
the
problem
statement,
but
we
have
left
that
to
other
specifications
to
fill
in
more
detail
and
yeah
and
I
went
through
all
the
use.
Cases
and
I
tried
to
fix
them
to
conform
to
this
stuff,
and
hopefully,
is
like
relatively
successful
I'm
not
here,
to
tell
you
the
document
is
doc
right,
I'm
not
here
to
say
this
is
ready
for
working-class
call.
G
G
So
this
is
very
similar
to
the
slide
that
I
showed
at
the
interim
that
enumerated
the
roles
of
the
various
actors
in
this
ontology
the
little
and
the
disin
green.
Therefore,
the
registrar
is
anyone
previously
and
it's
true
I.
There
was
something
I
think
I
was
like
conflating
as
I
was
thinking
about
this,
because
I
was
like
their
registries
for
distributing
numbers
and
their
CSPs
and
then
they're
like
delegates
and
III,
think
we
needed
to
get
to
a
point
where
we
could
say
the
registry
is
going
to
be
responsible
for
the
core
number
allocation
functions.
G
Is
this
TN
assigned
or
not
kind
of
stuff,
maybe
have
a
pointer
to
the
serving
CSP?
If
we
want
the
registry
be
slightly
thicker
than
that,
but
it's
really
this
concept
that
there
is
a
registrar's,
logical
role
that
has
relationships
with
csps
and
users.
Business
relationships
knows
who
they
are,
has
their
contact
info.
If
law
enforcement
people,
for
whatever
reason
happen,
need
to
happen
to
know
who
has
been
assigned
that
number,
that
is
where
that
would
reside
logically
within
the
registry.
Next
slide.
G
The
interesting
thing
about
picture
I
tell
about
this
now
and
there's
actually
a
picture
like
this
in
the
draft
I
busted
out
email
effects
for
the
first
time
in
few
years
and
put
together
some
ascii
art
to
go
into
the
draft
for
this.
I
think
when
you
lay
things
out
this
way,
you
see
that
the
CSP
and
registrar
functions
very
commonly
should
be
should
be
performed
by
the
same
administrative
entity,
and
if
you
look
at
the
way
most
of
the
telephone
network
works
today,
I
think
it
looks
in
a
model.
Quick,
quite
like
this.
G
G
They
give
blocks
of
inventory,
to
csps
we're
effectively
acting
as
registrars
there,
the
people
at
the
business
relationship
with
consumers,
the
customers
of
ATT,
the
customers
with
comcast
or
whoever.
Now,
in
some
cases,
you
may
have
an
enterprise
who
is
the
customer
who's,
getting
a
set
of
numbers
that
they
in
turn
delegate
down
to
end
users
and
and
so
in
the
most
complicated
models?
We
look
at
typically
they're.
There
is
something
that
looks
like
roughly
these.
G
These
four
levels
present
in
it
is
it
possible
for
users
to
get
numbers
by
going
directly
to
a
registrar,
sure,
there's
not.
The
enterprise
here
is
contingent
than
normal.
I
get
my
cell
phone
from
AT&T
case
is
one
in
which
that
third
box
there
goes
away
right,
but
I
think
in
this
otology
we
I
kind
of
get
better.
What
a
delegator
is,
what
a
registrar
is,
what
a
registry
is
registries,
yet
no
distribute
numbers
to
registrar's.
If
you
have
a
direct
relationship
with
a
registrar,
then
you
are
not
a
delegate
right.
G
If
you
have
a
direct
relationship
with
the
registrar,
and
you
are
then
giving
number
to
someone
else,
you
are
a
delegate
or,
and
those
people
the
users
in
this
instance,
are
your
delegates.
Definitionally
I
think
this
is
much
more
crisp.
This
makes
a
lot
more
sense
than
I
had
before
I.
Think
I
can
explain
most
of
the
use
cases
in
this
sense
people
seeing
this.
Does
this
seem
sane
or
people.
Looking
at
this
and
saying
I,
don't
get
this
better
better
than
what
I
had
before.
G
Okay
I
see
some
nodding,
I,
don't
see
anybody
getting
up
with
a
you
know
to
burn
me
an
effigy
next
one
yeah
and
just
just
a
particular
kind.
What
I
said
before
we
do
have
this
concept
in
the
data
types
that
there's
a
distinction
between
administrative
data
and
service
data?
There
are
a
couple
of
data
types
that
you
manage
with
this
and
I.
Imagine
when
we
break
this
down
so
there's
now
a
registrar
as
a
separate
entity.
We
gain
this
useful
distinction
that
we
can
say.
G
Okay,
it
may
be
one
administrative
energy
performs
both
of
these
functions,
but
there
are
two
discrete
functions
they
could
be
decoupled.
One
of
them
is
that
CSP
function
that
manages
the
service
data
knows
about
communication.
Endpoints
knows
about
protocols
is
what
gets
queried
in
real
time.
We
need
to
like
route
text
messages
or
calls
totally
get
that
and
they
are
providing.
A
communication
service
seems
like
a
crisp
definition.
G
Those
things
fall
all
where
they
should
there
and
then
you
kind
of
have
the
Registrar
to
mention
at
that
that
manages
the
administrative
data
knows
who
the
bill
knows.
Who
is
culpable
if
there
is
fraudulent
or
problematic
activity
going
on,
but
these
are
logical
rules
that
can
be
played
by
the
same
administrative
entity.
Having
made
this
division
now,
I
think
I
get
it.
It's
clear
to
me:
I.
G
I
think
the
ontology
is
about
right
next,
so
I
had
to
kind
of
go
through
the
use
cases
and
amend
them
for
this,
and
it
does
have
some
interesting
edges
on
it
to
do
so.
We
use
tab,
use
cases
the
talk
about,
like
a
user
acquiring
a
TN
from
the
registry
directly,
a
lot
of
people
were
barfing
on
that
use
case
and
I
get
that
now.
There
is
not
a
use
case
like
that
anymore.
G
There
are
use
cases
where
users
get
numbers
directly
from
a
registrar
and
a
registrar
is
often
a
CSP,
and
this
looks
an
awful
lot
like
the
way
that
this
just
works
out
in
the
world.
Today,
when
you
are
getting
a
new
cell
phone
number
activated
on
verizon's
network,
the
cases
where
a
user
requires
a
TN
directly
from
a
registrar
who
is
not
a
CSP,
those
look
again
much
more
like
this
free
phone
cases.
G
Where
you
go
out
and
get
this
800
number,
and
now
you
can
find
a
CSP
to
propagate
it
for
you,
but
those
have
been
decouple
so,
in
other
words,
all
these
abstractions
exist
in
the
telephone
over
today.
This
is
no
longer
in
that
sense,
even
for
plucking
right.
This
is
this
is
actually
descriptive,
rather
than
prescriptive,
of
the
administrative
functions
that
are
out
there
it,
but
by
characterizing
them
this
way,
I
think
we
can
enable
some
of
the
more
experimental
notions
that
motivated
us
to
go
down
this
path.
G
In
the
first
place,
simply
the
management
cases
have
to
have
that
same
distinction
of
used
to
CSP
CSP,
to
CSP
and
so
on,
because
they're
broken
down
into
the
service
data
cases
and
those
administrative
data
cases
when
you're
doing
service
data
updates,
usually
you
are
going
to
be
dealing
with
the
the
actor
doing
the
CSP
role
when
you're
doing
the
more
administrative
things.
Typically,
your
may
be
dealing
with
the
registrar
role,
maybe
the
same
administrative
entity,
but
from
the
flow
perspective
of
what
the
protocols
look
like.
G
We
can
break
that
down
and
decide
how,
in
the
information
model
the
the
messages,
then
we'll
will
be
sorted
for
that.
That
particular
you
skates
and
at
the
end
of
the
day,
of
course,
what
we
really
want
to
use
all
this
for
us
people,
like
you,
know,
route,
calls
and
have
useful
services
on
the
internet
and
figure
out
who
people
are
and
what
we're
doing
so
retrieval
interface
hasn't
really
changed
that
much
because
of
the
Registrar
thing
really.
G
The
distinction,
heat
registry
and
registrar
lives
much
more
up
in
the
acquisition
and
management
protocols,
but
I
think
we
have
a
much
better
notion
now
of
how
we
get
the
data
we
want
to
get
into
these
systems
to.
Let
us
do
retrieval
next
slide
and
I
mean
so.
I
went
through
all
the
use
cases,
and
basically
just
explained
things
like
how
the
acquisition
protocol
looks
for
each
of
them.
When
you
put
registrar
into
it,
it's
pretty
obvious.
You
know
if
you're
a
CSP
and
you
hold
inventory.
G
That
seems
to
be
something
we
commonly
do
in
the
telephone
network
today.
You
know
a
sprint
will
go
to
the
nampa
and
say
I
need
some
more
numbering
resources
and
look
at
them.
That
might
then
be
delegated
down
someone
else.
This
yeah
for
those
of
you
who
came
here
because
I
asked
you
in
stir
to
come
and
attend
this.
This
is
also
where
credentials
for
these
functions
might
be
distributed.
So
I
think
this
all
works
better
with
that
registrar
understanding.
G
I
wanted
to
talk
to
the
registrar
and
get
provision
with
again
credentials,
but
whatever
other
administrative
data
needs
to
be
assigned
to
do
that
and
with
a
service
data.
There
are
all
kinds
of
cases
like
this:
you
bought
the
new
phone
at
the
apple
store.
I
want
to
replace
an
existing
account
where
you
see
that
user,
going
up
to
the
Registrar
/
CSP,
changing
the
service
data
at
administrative
data
accordingly,
next
slide,
and
this
one
like
I,
said
we're
not
doing
it
it
just
it
doesn't
make
any
sense
in
this
model
anymore.
G
So
it's
out
next
line,
so
yeah
now
we're
talking
now
we're
talking
bit
about
what
do
we
do
so
I've
just
largely
articulated
what
the
changes
are
that
I
made
based
on
a
previous
interim
discussion.
It's
actually
some
pretty
pictures.
This
is
much
more
interesting.
What
I'm
talking
about
and
bridge
out
there
is
a
nice
I'm
not
going
to
present
the
cherry
work
today.
I
did
not
increment
the
Terry
work
since
last
time.
G
There
are
some
things
that
I
would
probably
tweak
about
the
way
that
structured
and
I'll
show
you
some
slides
about
that
in
a
minute.
You
know.
I
really
would
like
to
get
some
agreement
on
this
problem
statement
here
today,
because
honestly,
I
don't
want
to
do
any
work
on
the
Terry
model
unless
I
feel
like
there
is
a
working
group
year
that
is
gonna
like
do
something,
and
if
we
cannot
get
to
the
point
where
we
think
that
the
ontology
that
is
in
this
problem
statement
is
sufficient,
then
then,
why
should
I
bother?
G
Do
any
of
that
stuff
that
much
dad
I
think
I
think
it
does
all
work?
I?
Think
it's
a
great
time.
Forster
I
think
stir
needs
this
stuff
to
get
a
lot
of
the
credentialing
systems
that
we're
considering
for
that
to
actually
work
next
slide,
and
you
know
they're,
there
will
be
questions
right
like
this
is
an
example
of
something
when
I
do
Terry
that
when
we've
made
the
registry,
is
it
this
thin
we're
going
to
have
some
design
decisions
to
make
based
on
that
model?
G
Do
we
want
the
registry
to
contain
pointers
to
CSP
ESO,
the
user
kind
of
when
he's
doing
retrieval,
talks
the
registry
and
then
in
turn,
talks
to
the
CSP
based
on
a
pointer
they
receive
from
the
registry?
You
know
how
do
we
want
call
routing
to
work?
Those
things
are
there
are
things
that
we
could
do
a
couple
different
ways,
and
we
can
talk
about
that
today.
People
want
that's
not
the
main
thing.
I
want
to
talk
about
that.
Those
are
the
set
of
design
decisions
that
open
up
to
us
to
do
the
protocol
work.
G
This
working
group
is
supposed
to
do
if,
in
fact,
we
are
going
to
have
a
working
group
and
do
that
work
next
slide,
please
and
that's
just
a
Terry
picture
I
put
inside
this
is
what
I
want
to
have
this.
Is
this
helpful
you
like?
We
can
use
this
and
it'll
make
happy
things
happen
on
the
internet
and
it'll,
be
so
much
better.
G
So
we're
gonna
adopt.
This
is
right
right
now
or
I'm.
Gonna
drop
the
mic
and
I'm
done
I'm
serious,
like
I'm.
Just
I
am
NOT
going
to
bring
this.
This
working
group
Iraq
for
the
next
three
years.
Making
these
like
tiny,
increments
changes.
I
believe
that
this
that
what
we
have
today
is
a
sufficient
start
of
not
saying
it's
ready
for
glass
call
I
think
this
ontology
is
a
useful
ontology.
It
solves
actual
real-world
problems.
G
It
was
well
as
aligning
us
with
the
future
problems
that
the
FCC
workshop-
that
is,
we
all
now
inspired
this,
which
was
about
what
the
future
of
numbering
might
look
like.
I
think
we've
managed
to
create
a
framework.
Finally,
that
really
cast
that
future
in
a
way
that
is
rooted
in
our
administrative
systems
today
and
I
I
think
I
should
have
done.
I
should
have
thought
about
this.
That
way
from
the
start,
we're
really
everything
that
I
showed
in
this
should
have
been
traceable
back
to
something
that
we
do
today
at
the
start.
G
That's
on
me
like,
but
now
that's
what
we've
got
and
you
know
if
we're
not
going
to
do
this
I
suggest
we
all
go,
find
a
better
use
of
our
time.
So
I
mean
I'd
like
that's
the
chair.
It
was
reverse
all
please
discussion.
It
has
questions
or
wants
to
talk
about
the
fate
of
the
group
beyond
that
I
mean
I'd
like
to
ask
the
chairs
to
call
this.
This
question
cuz.
You
know
their
bars
open
down
there
right
and
if
we're
done,
I
we're
done.
A
Well
before
we
call
the
question
either
how
many
people
have
read
the
the
updated
draft
I
think
it's
a
very
good
draft,
very
good,
very
good,
update,
very
clear
and
is
a
good
foundation
for
the
architecture.
Work
item
that
we
have
on
our
on
our
working
group
list.
But
have
people
read
the
draft
got
one
or
two
three
or
small
number
I
mean
I
would
encourage
people
to
to
read
it.
It
is
a
bigger
change
and
I
thought
would
be
from
from
the
03
version,
but
but
all
good
that
said,
I
know
I'll.
A
F
You're
channeling
Peter
Koch
at
the
risk
of
looking
stupid
or
having
Dan
look
stupid
on
my
behalf.
In
the
late
stages
of
enum,
we
discussed
a
mapping,
an
e
164
number
and
a
service
to
a
provider
that
is
having
different
providers
cover
different
services.
Under
the
same
number,
the
draft
seems
to
speak
of
CSP,
as
in
a
singular
instance
per
number.
Do
you
see
any
sense
in
broadening
the
proposal
toward
that
late,
enum
way,.
G
Absolutely
Peter
I
mean
I
really
do
not
think
the
intention.
I
believe
there
is
a
specific
line
in
the
problem
statement
that
says
that
it
is
not
an
assumption
of
this
work
that
a
single
CSP
provides
all
the
services
associated
with
a
particular
telephone
number.
I
can
try
to
find
that
line.
I'm
pretty
sure
that
line
is
in
there
and.
A
A
J
J
G
There
is
actual
I'm,
not
sure,
there's
literally
like
something
that
says,
the
problem
statement
is
but
yes,
there's,
there's
a
block
of
introductory
text
in
the
document
that
articulates
really
what's
in
the
introduction
is
what
I
consider
to
be
the
problem
statement.
It
goes
through
and
talks
about
what
the
changes
are.
The
IP
transition
that
everyone
believes
is
going
on
and
kind
of
what
is
incumbent
upon
us
to
create
a
number
management
system
that
will
work
in
an
internet-based
ecosystem.
G
When
we
get
past
the
point
where
the
psg
n
is
the
primary
place,
the
telephone
calls
transpire.
That
is
a
summary
I
guess
of
what
the
problem
was
that
instigated
this
I
think
you'll
find
again
four
or
five
paragraphs
that
elucidate
that
in
the
introduction
to
the
document
it's
John
section,
one
is
called
problem
statement.
G
A
G
A
E
L
Hi
I'm
Tom
meharry,
I
put
together,
there's
there's
no
new
draft.
This
is
an
associated
with
new
draft.
It's
based
on
a
draft,
an
informational
draft
that
came
out
a
couple
of
months
ago.
You
want
to
go
to
slide
to
this
I
put
this
draft
together
because
it
was
we're
going
through
something
in
the
US
there's
this
concept
that
they
want
to
deploy
with
their
calling
nationwide
number
portability.
Our
geographic
numbers
are
tied
to
the
PSTN
to
where
the
telephone
number
has
a
geography
right.
L
If
you're
a
your
new
york
number,
you
are
connected
to
the
PSTN
in
New.
York
calls
that
go
to
and
from
you
that
go
through
the
PSTN
go
through
ultimately
connect
to
a
switch
in
New
York.
The
concept
is
they
want
to
do
away
with
that
and
have,
if
you're,
a
new
york
number
you
happen
to
live
in
los
angeles,
that
the
call
does
not
have
to
go
through
new
york
to
complete
to
you
that
it
can
go
to
elect
directly
to
Los
Angeles,
so
I
put
a
draft.
L
There
was
a
concept
that
we
came
up
with
in
the
u.s.
to
deploy
this,
which
used
a
brand-new
non
geographic
area
code
that
would
be
used
for
routing
numbers,
and
this
area
code
would
be
hosted
on
on
IP
switches.
It
would
be
all
IP
everything
neck
that
went
to
this
area
code
would
be
IP
in
essence,
what
this
does
is.
L
It
creates
a
IP
parallel
network
to
kind
of
the
existing
TDM
network,
and
if
people
want
to
carriers
want
to
move
their
infrastructure
over
to
the
IP,
they
can
do
that
if
they
want
to
leave
it
on
TDM,
they
can
do
that
as
well,
and
because
this
was
an
area
code,
all
switches,
even
TDM
switches,
can
route
by
area
code.
If
they
had
someone
routed
TDM
network,
they
originated
a
call
to
one
of
these
numbers.
L
They
at
least
have
enough
smarts
to
get
it
to
an
IP
network
like
a
partner
of
theirs.
Who
could
complete
the
call
on
the
IP
network?
So
it's
a
the
idea
has
a
you
know.
It
allows
the
calls
the
to
be
moved
on
the
IP
network
to
different
geographies
and
it
allows
the
TDM
networks
to
stay
and
do
what
they
do
today
and
and
not
have
to
participate
in
this
just
after
route
to
it.
L
So
anyhow,
because
this
was
a
brand-new
numbering
space,
it
was
a
Greenfield
numbering
space
having
been
working
on
modern
for
a
little
while
I
thought
it
was
a
really
good
use
case
that
starts
thinking
about.
How
would
you
do
something
like
this?
So
I
put
together
a
draft?
It's
just
informational
of
a
use
case.
That
said,
here's
kind
of
how
we'd
we
deploy
this
new
numbering
space
in
a
modern
context.
L
So
we
have
a
brand
new
area
code.
It's
used
for
routing
numbers,
so
carriers
acquire
numbers
to
use
for
routing
purposes,
and
we
also
have
we
can
use
these
numbers
to
assign
to
consumers
for
regular
voice
and
text
messages.
Today
we
basically
have
only
Geographic
numbers
for
those
purposes
in
the
u.s..
We
don't
have
non-geographic
numbers
for
those
purposes.
Consumers
just
don't
really
get
non-geographic
numbers.
Those
are
reserved
for
special
services
like
toll
free
and
government
services,
and
things
like
that.
L
L
As
I
mentioned
earlier,
the
routing
numbers
are
hosted
on
IP
switches,
and
this
presentation
goes
into
a
little
more
discussion
about
how
the
actors
in
this
ecosystem
would
would
work
with
each
other
a
little
more
than
the
drafted,
and
it
also
by
the
way,
assumes
similar
processes
that
we
have
today.
So
it's
not
as
forward-looking
as
we
like
to
think
of
in
modern
and
it's
a
little
more
kind
of
near
term.
So
it's
based
on
that
draft.
L
The
use
case-
and
it's
also
based
on
the
new
version
of
modern
problems,
so
you'll
see
lots
of
stuff
talking
about
registrar's
and
registries
next
slide,
please.
So
what
our
registry
is
registrar's
and
assignees.
We
use
the
term
assignees
by
the
way
in
the
draft,
and
that's
probably
something
we
should
start
thinking
about.
Maybe
we
should
change
the
term
for
registrant's,
just
be
more
consistent
with
the
domain
name
world
or
the
world
that
exists
out
there.
So
registries
are
authorized
by
a
numbering
authority
to
manage
the
numbering
space
again.
L
It
can
be
authoritative
or
distributed
by
the
way.
It
does
not
assume
that
communication
service
provider
is
not
act
as
a
registry.
A
lot
of
places
you
you
know
they
don't
allow
that,
but
because
we
have
this
concept
that
distributed
distributed
registries,
why
would
why
would
we
exclude
carriers
from
being
a
registry?
L
The
the
the
communication
service
providers
are
likely
to
be
registrar's,
as
John
mentioned
earlier,
and
assignees
are
the
ones
that
are
acquiring
the
the
routing
numbers
and
the
and
the
telephone
numbers
by
the
way.
One
thing
I
didn't
mention:
is
this
concept
these
IP
switches
that
hosts
the
routing
numbers
you
know
in
the
in
this
kind
of
environment
we
call
them
non-geographic
gateways
just
to
have
a
nice
4-letter
acronym,
and
so
so
these
non-geographic
gateway
providers
are
entities
that
would
be
looking
for
the
routing
numbers.
L
L
Assignees
can
have
relationships
with
many
registrar's
as
they
feel
like.
This
is
the
way
the
world
works
today.
Why
not?
She
go
to
the
next
slide,
please
so
you're
going
to
notice
by
the
way.
So
I
took
here
about
how
a
gateway
provider
acquiring
a
routing
number,
what
would
be
the
process
that
they
go
through,
I'm
going
to
start
analogizing
and
in
the
coming
slides
this
stuff
to
just
kind
of
general
modern
concepts.
L
I
know
this
is
kind
of
a
nationwide
numbering
number
portability
use
case,
but
in
reality
it
looks
works
just
the
same
for
telephone,
any
kind
of
telephone
numbers,
geographic,
telephone
numbers
and
so
forth.
So
on
the
on
the
left
side,
we
start
with
a
gateway
provider
looking
to
get
a
routing
number,
the
that
they
presumably
already
have
a
relationship
with
registrar.
They
have
a
credential
that
they
can
present
to
get
to
get
authorized
to
ask
for
it.
The
Registrar
who's
likely
a
communication
service
provider
by
the
way.
All
of
these
all
these
registry,
the
Registrar.
L
See
s
P
and
the
gateway
provider
could
all
be
the
same
same
entity.
So
the
Registrar
authorizes,
the
the
assignee,
the
the
gateway
provider
says:
okay,
you're
allowed
to
ask
form
they
could
also
I'm.
Sorry
they
authenticate
them.
They
could
also
authorize
them
to
say
yes,
you're
you're
eligible
to
get
one.
Maybe
there
could
be
policies
that
you
can
only
have
so
many,
so
that
may
be
something
that
the
the
Registrar
would
have
to
check,
but
so
they
review
it.
They
approve
it.
L
They
send
up
a
request
for
the
registry
by
the
way,
one
of
the
things
that
I.
You
know
that
we
need
to
think
about.
As
we
move
forward
in
this
is
is,
can
they
ask
for
a
specific
resource?
Can
they
say
I
want
this
number
today
in
the
US
anyhow,
when
you're
asking
for
a
geographic
number,
they
typically
just
get
the
next
one.
You
don't
necessarily
ask
for
specific
one,
although
certainly
a
lot
of
VoIP
providers.
They
allow
you
to
scroll
through
and
look
for.
We
do
exactly
that
with
toll-free.
Yes,.
M
L
L
L
Why
not
have
them
request
specific
numbers,
the
that
gets
that
gets
more
sticky
by
the
way
when
you
get
into
consumers
asking
for
it
users
asking
for
telephone
numbers,
so
you
have
to
start
thinking
about
speculation
and
squatting
and
all
that
so
the
the
registry
then
reviews
it
and
says
yeah.
This
person
is
able
to
get
it.
The
registrar
is
able
to
get
it.
L
They
again
may
need
to
authenticate
and
authorize
and
they
send
down
a
response
and
say:
yes,
you've
been
assigned
this
and
and
the
Registrar
CSP,
let's
the
gateway
provider
know
that
they
have
it
by
the
way
what
they
they
there's
administrative
data
that
goes
up.
There's
service
data:
where
is
the?
Where
is
the
address
for
this?
This
is
a
gateway
provider.
This
they're
going
to
need
to
understand
what
the
address
for
that
is,
so
the
registry
I
would
want
to
keep
that
data
they
also
and
by
the
way.
L
This
is
again
how
the
way
it
works
in
the
US.
They
notify
others
that
there's
been
a
change
in
state
right.
They
they
could
push
down
the
the
information
to
the
other
registrar's
that
are
connected
to
it,
and
then
those
registrar's
could
push
down
data
that
go
to
the
communication
service
providers
and
the
service
enablers
and
and
and
then
they
could
put
it
in
their
local
cache.
L
L
G
Peterson
yeah
no
I
would
suspect
that
those
would
be
management
operations
ultimately
and
the
question
of
kind
of
is
it
a
push?
Is
it
a
poll?
Those
are
actually
really
interesting
questions
in
terms
of
what
the
semantics
of
the
management
interface
needs
to
be.
If
we
imagine
they're
going
to
be
kind
of
subscription
style,
push
interfaces
or
associate
with
that,
that
will
let
the
registry
gap
data
down
to
the
registrar's.
That's
exactly
the
reason
to
have
a
document
like
this
wreck
is
this.
This
is
the
kind
of
thing
we
can
say.
G
Okay
for
this
use
case,
we
should
make
sure
that
we
specify
in
the
management
interface
that
it
should
be
able
to
do
this
right.
I,
retrieval
again,
I
think,
has
much
more
of
that.
The
pole,
semantics
and,
moreover,
I
think
it
has
much
more
of
the
semantics
of
individual
users
who
are
trying
to
either
get
get
administrative
or
service
data.
You
know,
as
a
consumer
of
that,
rather
than
provisioning
other
elements
of
the
architecture,
which
is
what
I
think
you're
doing
here
right.
I
I
I
L
M
L
Yes,
you
know
I'll
tell
you
why
I
kind
of
thought
about
this
push
concept.
You
know
we
are
thinking
about
operationalizing
this
sometime.
You
know
within
the
next
couple
of
years
right
this
nationwide
number
portability
thing
and
the
way
carriers
I'm,
probably
telling
people
hear
what
they
already
know.
The
way
carriers
do
IP
routing,
at
least
in
the
US.
L
Is
they
create
these
things
called
sip
trunk
groups
between
their
spcs
and
you
have
carrier
a
connects
to
carrier
be,
and
they
look
at
the
first
six
digits
of
the
telephone
number
and
say
you
know
when
their
routing
they
have
a
table.
That
says
these
six
digits
go
to
this
sip
trunk
group
and
they
send
it.
They've
we've
rebuilt
the
PSTN
the
way
it
looks
today.
So
something
like
this
routing
number
all
you
need
to
know.
L
The
only
routing
information
would
actually
need
to
know
is
the
number,
the
10-digit
number
and
the
service
provider,
the
gateway
provider
that
it
goes
to,
because
you
will
have
a
trunk
group
that
goes
to
that
gateway
provider
and
your
table
will
look
up
ten
digits
and
come
back
with
its
the
SIP
trunk
group
that
this
goes
to.
So
it's
pretty
simple
stuff.
L
Yeah
yeah.
Well
I
know
I
and
I
agree
with
you
by
the
way.
I.
Don't
think.
That's
the
I,
don't
think
that's
the
long-term
solution
again
the
end.
What
I
think
you
would
have,
though
you'd
have
that
I
think
there'd
be
other
routing
information
in
the
service
data
right
I
think
you'd
have
multiple
things
you
could
have
because
there
are.
L
There
are
companies
that
route
based
on
service
provider
IDs
just
like
a
four-digit
number,
that's
associated
with
a
service
provider
on
the
the
first
six
digits
of
the
phone
number
on
the
phone
number
itself,
and
maybe
there's
some
that
would
actually
want
to
honor.
You
are
I,
so
I
think
you
could
have
in
when
we
think
about
what
is
the
service
data?
You
know,
we'd
think
of
you
know
doesn't
seem
like
a
telephone
number
is
actually
service
data.
L
L
So
if
you
go
to
the
next
slide
and
I
won't
spend
much
time
on
this,
but
this
is
a
comparison
of
how
you
would
do
you
know.
I
use
the
the
nationwide
number
portability
use
case
again,
because
I
I
tend
to
think
about
these
new
things
called
a
non-geographic
routing
number,
but
this
could
work
this
exactly
the
same
way
for
any
kind
of
network
resource.
You
know
numbering
blocks
our
network
resources.
The
carrier
codes
as
I
mentioned
before
are
numbering
resources,
so
you
could
have
the
same
flow.
L
L
Have
in
the
future,
once
you
go
to
the
next
slide,
and
this
is
also
you'll
notice
here,
I
as
just
to
make
the
point
once
again,
it
works
for
the
non-geographic
resources
the
same
way.
It
works
for
the
geographic
resources
notice
everywhere.
I
have
ng,
I
put
it
in
put
it
in
brackets.
This
works
the
same
for
an
non-geographic
telephone
number
works
same
for
a
telephone
number,
just
regular,
Geographic
telephone
number,
so
these
are
really
kind
of
the
same
flows.
L
The
main
difference
here,
I've
highlighted
in
red
from
the
flows
we
just
went
through,
and
that
is
you
know
when
you
have
a
user.
So
this
is
this:
is
a
user
asking
for
a
telephone
number?
The
registrar
is
going
to
collect
contact
information,
kind
of
important
administrative
data
there
you
know
there's
two
models.
The
Registrar
could
hold
on
to
that
information.
L
This
is
kind
of
one
of
the
differences
that
I
think
we'd
see.
Here
you
go
to
the
next
slide,
so
next
steps
and
questions
you
know,
I
think
we
want
to
start
thinking
about
the
information
model.
I
really
covered
the
acquisition
transactions
here
in
the
in
the
problem
statement,
we
have
three
types
of
transactions,
acquisition,
management
and
retrieval.
You
know
what
do
we?
What
is
the
administrative
data?
What
is
the
service
data?
Actually,
the
discussions
we
were
just
having
I
think
we
need
to
start
getting
to
identify
the
options.
L
There's
the
thick
thin
registry
model,
where
the
the
Registrar
holds
on
to
the
contact
data.
There's
a
thick
registry
model
where
the
registry
holds
on
to
that
data
and
then,
let's
start
talking
about
the
retrieval
processes,
the
places
where
I
had
the
question
marks
in
seven
and
eight,
you
know
what
is
that?
Is
it
a
management
transaction?
Not
not
a
retrieval
transaction,
you
know
what
are
we
again
push
pull
or
entities
maintaining
local
caches?
L
You
start
getting
the
registry
having
to
deal
with
other
registries
to
to
to
secure
the
number
it's
telling
them
hey,
I'm.
Looking
for
a
number
here's
a
number
of
looking
for.
Is
anybody
have
it?
If
not
don't
don't
take
it
because
I'm
getting
it
for
somebody
and
then
once
that's
done,
then
they
can.
Then
they
can
assign
it
to
the
user
and
then
update
the
registry
and
the
other
registries
update
the
other
registrar,
I.
Think
you'd
likely
see
all
that
right
side
be
kind
of
collapsed
right.
L
L
A
L
L
Problem
yeah,
what
I
would
I
think
it
can
be
used
for
is,
as
we
start
thinking
about
what
is
the
information
model
right,
that
there
there's
something
called
a
telephone
number
there's
something
called
a
geographic
routing
number
there's
something
called
a
non-geographic
routing
number
right.
So
so
we
we
kind
of
understand
those
so
I
think
it's
just
informational
for
the
group.
Yeah.
G
A
And
that
was
kind
of
where
my
question
was
going
is
whether
maintaining
this
draft,
as
we
build
modern
infrastructure
to
as
a
test
case,
are
as
a
making
sure
that
we're
touching
all
the
necessary
components.
This
is
a
pretty
complete
problem
definition
for
a
specific
use
case,
but
it
has
with
all
the
pieces
we
need.
I
think
I
mean.
G
I
could
see
that
yeah
continuing
to
exist
in
becoming
kind
of
not
just
a
here
are
the
requirements,
but
here
is
how
that
is
solved
by
the
elements
and
Terry
and
then,
but
then
the
conclusion
of
that
process.
It
could
indeed
be
an
informational
drafter.
It
better
right,
saying:
look:
this
alters
problem.
E
Alyssa
Cooper
there's
some
discussion
in
the
IHG
about
whether
those
kinds
of
drafts
need
to
actually
become
published
as
RFC
s.
So
not.
This
is
not
a
question
you
need
to
think
about
today
too
much
but
obviously
useful
to
keep
it
around.
But
when
the
time
comes
it
may
be
the
case
that
you
say
this
is
great
glad
we
had
it,
but
there's
more
machinery
involved
in
getting
an
RFC
number.
That
might
not
add
any
utility.
So.
I
I
More
still,
no
review
actually
I
presented
these
before,
but
I
think
but
I
think
if
I
lonely
I'll
only
go
through
them
quickly
unless
there's
somebody
here
that
wants
me
to
go
through
them
in
more
detail,
but
just
from
a
high
level.
It's
a
HTTP
based
protocol
for
sharing
rigid
registries
between
distributed
data
stores,
pure
HTTP,
uses
gossip
protocol
and
incorporates
a
voting
mechanism.
G
I
Avoid
conflicting
data
updates
based
on
very
well-known
principles,
how
you
know
well
known
and
highly
implemented
things
in
most
of
the
databases
that
people
use
today.
Also
I
should
note
heading
during
the
interim
meeting.
I
think
pretty
much
gave
an
overview
that
very,
very
much
aligns
with
this
draft
as
well.
So
next
slide
just
the
picture
of
what
this
might
look
like
all
interconnected
via
HTTP
connections.
Next
slide.
I
I
I
Mentioned
this
last
time
there
was
some
discussion
on
this.
Well
last
time
being
in
Japan,
we
took
the
approach
so
far
that
the
the
scope
of
the
spec
was
only
for
the
protocol
for
exchanging
data
and
sort
of
took
the
approach
of
authentication
and
entitlement,
and
other
things
could
be
put
on
top
of
this.
I
You
know,
especially
since
it's
http-based
there's
a
lot
of
mechanisms
already
out
there
and
there
might
be
other
use
cases
like
security
requirements
for
different
scenarios.
If
I
want
to
have
a
distributed
registry.
Internal
to
my
network,
I
may
have
different
requirements
than
what
modern
is
looking
at.
So
we
sort
of
wanted
to
keep
that
perspective,
but
that's
up
for
discussion
next
page.
I
I
So,
like
I
said
whether
it's
included
in
this
draft
or
a
separate
draft
to
propose
some
sort
of
lots,
security
framework
also
number
their
identity.
Porting
security
would
be
another
aspect
to
think
about
as
well,
either
in
this
draft
or
a
separate
one
and
also
I
think
whether
it's
terry
or
or
whatever
the
data
model
may
impact
some
of
some
of
this
stuff.
But
hopefully
it's
a
pretty
independent
part.
It
should
it
may
impact
actually
the
security
model
and
the
the
other
thing
so.
G
I
G
I
A
Was
going
to
be
the
conversation
I
wanted
to
have?
Next
is
whether
I
mean
it's
clear
from
the
discussion
we
have,
discussions
were
having
that's
the
drip
or
something
like
trip
is
needed
and
would
would
add
a
lot
of
value
for
the
for
the
distributor
registry
problem
question
is
whether
this
group
has
the
right
people
in
it
to
do
protocol
specification
for
that
kind
of
a
problem
and
or
whether
it
would
make
more
sense
to
dispatch
that
work
separately
or
I.
A
A
M
Brian
Rosen,
gee
I
think
I
can
do
this,
but
maybe
there
isn't
enough
I
I,
I
kind
of
thought.
We
could
do
it
and
you
know
whether
we
should
adopt
it
now
or
wait
until
we're
a
little
bit
farther
along
is
kind
of
fun.
Doesn't
matter
to
me
much,
but
I
was
kind
of
hoping.
We
could
do
this
here
and
not
have
to
go
somewhere
else
to
do
it.
G
It's
not
like
we
haven't
looked
at
some
of
these
structures.
You
know
in
the
past.
You
actually
think
in
maybe
not
the
numbering
community,
but
the
community
that
has
designed
the
protocols
that
we
are
evolving
into.
This
has
been
a
subject.
I
think
I've,
actually
quite
detailed
study
already
here
in
the
ITF,
and
it
might
even
get
some
different
people
in
remember
who
have
that
expertise
if
they
understood
that
this
was
something
we're
going
to
take
a
serious
crack
out,
so
I
mean
I,
I.
Wouldn't
I'd
love
to
see
it
here.
A
E
G
E
A
F
New
York
I
don't
see
any
issue
with
doing
that
in
here,
I
mean
but
I
guess
I
would
just
say
to
John's
point.
There
are
lots
of
other
places
within
the
ITF
where
distributed,
databases
are
dealt
with,
I
mean
I.
Guess
you
know,
Chiho
dns
are
in
other
spaces
where
there's
large
place
like
I
guess.
The
question
is:
how
do
you
bring
alert
some
of
those
folks
that
this
is
going
on,
and
so
I
would
suggest
to
that?
G
G
Sure
John
provided
and
that
there's
there's
no
sudden
surprises
on
the
mailing
list.
In
that
regard,
I
wouldn't
mind
a
mean
I.
Remember
we
first
look
at
these
milestones.
You
know
I
kind
of
said
things
along
the
lines
of
doing
the
infirm.
Doing
the
information
model
work.
You
know
the
the
incremental
atta
you
know,
adapters,
40
and
resolution
or
whatever
that
follow
on
that
are
actually
quite
small
and
plain
simple
and
just
kind
of
looking
at
the
way
this
this
charter,
structured,
I'm,
sure
I.
G
I
recall
commenting
on
this
at
the
time
like
I
mean
did
it
would
not
be
unreasonable
for
that
to
be
literally
bundled
right,
I
mean
to
to
do
the
TN
resolution,
bundled
with
the
information
all
because
of
the
fact
that
they
are
so.
You
basically
need
to
have
solved
all
the
problems
about
how
to
do
TN
resolution
to
be
confident
that
we
could
submit
the
information
model
to
the
isg.
Now
looking
at
these
numbers
now,
I
kind
of
barfle
at
all,
but.
G
And
again,
because
we're
like
looking
at
drip
and
because
we're
looking
at
net
finish
my
number
portability
and
we
see
those
as
use
cases
that
potentially
impact
that
information
model
I,
think
that
milestone
is
too
aggressive,
but
so
that
the
silver
lining
I'd
say
on
that
is
that
it
will
collapse
in
with
I.
Think
the
things
that
follow
on
very
short
order.
Once
it's
complete.
G
A
No
I,
wouldn't
I,
didn't
want
to
suggest
that
I
was
just.
The
discussion
is
hopefully
to
start
getting
more
cycles
and
accelerate
the
process
on
the
other
documents,
since
we
lost
so
much
time
on
the
on
the
architecture.
Draft
for
the
problem,
statement
and
I
think
we
I
think
we're
able
to.
We
should
be
able
to
do
that
because,
hopefully,
we've
addressed
a
lot
of
the
concerns
about
the
problem
statement
and
and
and
we
can
get
to
a
focused
work
now,
I'm
hoping
but
yep.
G
Yeah
I,
don't
know
yes,
so
let
me
actually
answer
your
question.
Yes,
an
interim
would
be
helpful
for
us
to
talk
about
Terry
to
talk
about
where
we
are
with
all
this.
What
we
think
the
core
inputs
to
it
are
I'd
be
happy
to
do
some
work
in
advance
of
app
again,
provided
that
the
consensus
the
group
is,
that
we're
going
to
proceed.
Yes,.