►
From YouTube: IETF99-MODERN-20170721-1150
Description
MODERN meeting session at IETF99
2017/07/21 1150
https://datatracker.ietf.org/meeting/99/proceedings/
A
So
here's
the
note
well,
we've
seen
it
many
times
this
week
and
applies
just
as
much
for
the
end
of
the
week
as
it
does
for
the
beginning
of
the
week.
So
if
you're
not
familiar,
please
do
familiarize
yourself
with
it
quick
agenda
bashing.
We
we
moved
Chris
a
little
later
in
the
agenda,
but
they
didn't
change
the
the
name
of
the
draft,
so
Chris
will
be
talking
about
the
one
that
has
went
in
the
name:
move
the
John,
John,
Peterson
ones
up
I
apologize
for
the
failure
in
moving
things
around
any
any
agenda.
Bashing.
A
B
C
Feel,
like
is
your
last
session
I'm
talking
about
something
similar,
I
see
a
few
familiar
faces
from
that.
Actually
still
lingering
here.
Do
you
mean
to
be
your
parlour
as
to
say,
okay
break
up?
You
did
fair
enough,
so
we're
gonna
talk
about
the
thing
that
is
supposedly
articulating
what
it
is
you're
here
to
do
this
great
investigation
that
we
have
called
modern
next
slide
please.
C
So
we
developed
this
document
originally
as
a
problem
statement,
though
it
then
morphed
into
allistic
use
cases
and
morphed
a
bit
into
a
framework
as
well,
and
now
it's
as
basically
a
container
for
those
three
things.
It's
gotten
pretty
extensive
and
hopefully,
though,
those
three
things
are
at
least
relatively
aligned
because
we
stuff
them
all
into
the
same
container.
We
had
a
workgroup
last
call
in
this,
and
I
was
just
astounded
by
the
level
of
response
that
we
got
to
it
all
right.
Yeah.
Thank
you.
Thank
you.
C
C
We
probably
should
have
thought
of
doing
that
earlier.
Henny
had
asked
us
to
consolidate
the
use
cases
a
while
ago
and
I
kind
of
did.
A
I
did
some
of
that,
but
not
nearly
enough,
and
so
I
tried
to
do
a
bit
more
of
that.
To
get
that
to
be
a
bit
tighter.
This
time
next
slide
light
guy
I,
don't
know
we
could
I
I
would
welcome
more
review.
This
document
I
would
certainly
not
represent
this
as
a
document.
C
It
has
had
adequate
review
and
it
is
just
an
articulation
of
use
cases
and
the
framework
for
how
these
various
actors
interact
and
the
problem
statement.
This
is
not
something
that
by
publishing
it,
we
are
compelling
and
any
implementer
anywhere
to
do
anything
so
I
think
we
may
be
in
a
good
position
for
this
now
and
I
propose
if
no
one
else
feels
like
reviewing
it
that
we
try
to
send
it
on
the
same
thing.
Do
you
like
have
this
like
burning
urge
to
like
delve
deeper
into
the
modern
problem
framework
in
this
room?
A
D
C
Is
relatively
minor,
really
I
mean
we
added
that
credential
stuff,
but
that's
pretty
much
it
and
again
tried
them.
There
were
a
lot
of
use
cases
that
were
the
form
user
provisions
number
at
CSP
and
then,
like
delegate,
you
know
bridge
number
at
CSP
and
then
like
CSP
bridges
over
another
CSP,
which
I
have
tried
to
consult
because
they,
then
they
it's
just
like
rubber
stamp.
All
the
tax
can
solidly
those
into
provisioning
number
at
the
CSP
in
has
the
little
just
kind
of
differences
outlined
there.
A
C
As
I
sitting
up
here
for
like
one
slide
worth,
I
would
hold
my
stop,
but
not
now,
okay,
so
we
get
into
a
bit
of
meat
and
some
new
stuff
and
the
scan
came
out
of
conversation
unsurprisingly
by
the
the
dynamic
duo,
Chris
went
and
John
Peterson
once
again
submitting
work
to
modern
to
address
a
problem
that
has
some
currency
right
now
actually,
and
this.
This
really
is
an
attempt
to
address
the
perennial
and
sometimes
justifiable
accusation
that
this
has
kind
of
been
a
fishing
trip.
C
Right
I
mean
that
this
started
for
those
of
you
that
don't
recall
that
far
back
and
it
was
a
ways
back
at
this
point,
they
started
from
an
FCC
workshop
in
North
America,
where
we're
kind
of
speculating
on
what
kinds
of
tools
would
be
useful
to
have
in
future
numbering
administration.
So
what
kind
of
motivated
this
whole
exercise,
and
because
of
that,
you
know
we
have
been
facing
for
some
time
complaints
of
well.
What
are
you
really
doing?
C
That's
practically
gonna
change
anything
about
how
we
do
things
in
the
telephone
network
today,
and
this
is
an
example.
This
is
something
that
seems
to
be
going
on
now.
We
don't
seem
to
really
have
an
idea
of
how
we
should
do
it.
It
seems
like
the
kind
of
thing
we
should
be
able
to
do
with
the
stuff
we've
been
designing
here.
C
So,
let's
see
if
it
works
or
not,
was
the
thought
next
slide
so
first
before
we
get
into
that
particular
use
case,
this
is
all
based
on
this
thing
called
Terry,
it's
more
to
understand,
Kerry
before
I
really
get
into
this
I
talked
about
the
tools
we've
been
building
here
that
can
apply
to
this
use
case.
Terry
is
the
tool.
This
is
now
our
third
or
fourth
provision,
Terry.
Actually,
my
third
provision
and
what
Terry
really
represents
keep
it
stands
for
telephone
related
information.
C
T.Ri
is
an
attempt
to
create
an
information
model
that
designates
who
the
four
various
actors
are
involved
in
the
operations
of
acquiring,
managing
and
resolving
telephone
numbers
in
this
hypothetical
future
architecture
that
we
would
like
to
use
I
think,
since
the
framework
is
getting
getting
more
mature,
you
know
I
think
we
have
a
good
notion
now
kind
of
what
the
semantics
of
Terry
should
be,
and
this
is
purely
semantic
exercise.
We
have
a
separate
document
as
I
suggest
down
at
the
bottom.
C
C
First,
what
kind
of
information
we
want
to
have
inquiries
and
responses
for
Terry
before
we
got
too
deeply
into
the
syntax,
and
that
has
its
own
historical
roots
and
endless
debates
about
what
the
DNS
or
web
protocol
it'd
be
more
suitable
for
this
and
it
seemed
at
the
time.
The
best
thing
we
can
do
is
kind
of
put
that
off
the
table
and
say:
let's
just
talk
about
what
should
be
in
messages
and
we'll
worry
about
what
how
we're
gonna
carry
that
stuff
later
next
slide.
C
So,
like
I
said,
Terry
is
a
3-fold
thing.
There
are
three
basic
operations
that
it
defines:
there's
an
acquisition
operation.
This
is
rich
Aki's,
personal
favorite.
This
is
something
that
allows
if
you're
a
consumer.
Sorry
for
jockey
is
not
not
a
fan
of
this.
This
is
the
operation
that
allows
an
MD
to
request
a
new
telephone
number
from
some
kind
of
authority.
It
has
an
inventory
of
telephone
numbers.
Now
there
are.
C
There
are
many
ways
to
stage
that
that
could
mean
a
communication
service
provider
going
to
a
registrar
in
a
very
you
know,
kind
of
DNS,
like
model
name
like
model
where
you,
you
know
you
go
to
a
registrar
and
you
acquire
inventory
from
it
or
it
could
mean
a
consumer
going
to
a
carrier
or
it
could
mean
an
enterprise
having
individual
phones
connecting
up
to
it
that
go
to
the
enterprise
acquire
a
number
from.
You
know
the
central
call
computer
of
the
enterprise
I'm,
so
these
operations
are
intended
to
be
that
flexible.
C
In
other
words,
we
imagine
that
they're
gonna
be
applicable
to
a
wide
variety
of
different
use
cases.
They'll
have
fundamentally
the
same
semantics,
I'm
an
entity
I'm
going
to
some
authority
that
has
some
numbering
and
inventory
saying
gives
up
to
me.
We
have
a
management
operation,
which
is
the
question
of
how
you
actually
provision
information
about
a
number
and
the
fundamental
building
block
of
Terry
is
and
how
the
record
records
are
the
kinds
of
things
that
you
provision
and
retrieve.
C
They
contain
information
about
telephone
numbers
that
might
be
useful
to
you
in
placing
calls,
or
in
figuring
out
who
owns
what
and
then
there's
this
retrieval
operation,
the
fetch
operation.
Where
are
we
to
look
at
this?
Like?
Yes,
a
successor
to
enum,
which
sometimes
it
snaps
a
ssin
that
is
levy
that
it
eeen
is
really
scoped
to
that
retrieval
operation
component.
I
want
to
query
this
this
service
and
get
back
information
about
a
particular
number.
C
We
found
that
at
Clement
they
just
ended
up
having
different
information
models.
The
retrieval
protocol
did
from
the
management
protocol,
I
mean
it
was
more
flexible.
What
you
could
provision
in
other
words,
then
we
could
realistically
query
for
given
the
way
that
enum
worked,
and
so
the
core
conceit
of
Terry
is
that
you
have
this
common
information
model
based
on
the
record
and
that
we're
studying
the
ecosystem
of
the
record.
If
you
can
provision
it,
you
should
be
able
to
query
for
it's
a
common
information
model
next
line.
C
Similarly,
though,
the
basic
way
the
model
works,
clients
don't
tend
to
don't
need
to
trust
services,
typically
in
the
sense
of
it
doesn't
matter
from
whom
you
get
a
record.
What
matters
is
the
signature
on
the
record
that
was
created
that
was
put
on
the
authority
who
created
the
record,
in
other
words,
so
you
can
kind
of
think
about
it,
like
services
are
just
middlemen
in
this
ecosystem
and
that
records
come
into
being
through
the
acquisition
interface
numbers
are
kind
of
created
in
the
modern
ecosystem.
C
By
that
then
kind
of
authorities
can
provision
additional
records
against
and
they
sense
the
system.
Then
clients
retrieve
them
to
figure
out
a
communicate
with
people.
That's
the
basic
idea
of
all
this
next
slide.
So,
as
I
said,
there's
these
three
operations
each
has
a
request,
new
response
concept.
One
thing
is
actually
different.
This
is
the
first
place
I've
gotten
into
something
that
is
new
information.
I
presented
all
of
this
before
many
times.
C
We
keep
hacking
the
model
right
as
we
look
at
these
use
cases,
since
we
look
at
this
particular
use
case
this
time
of
dealing
with
valid
allocated
numbers
which
we'll
be
talking
about
shortly.
One
thing
that
kind
of
occurred
to
me
is
that
I've
had
this
previous
concept
that
the
requests
that
would
have
a
source
in
a
subject
right
the
source
is
the
client
that's
sending
the
request.
The
subject
is
what
the
request
is
about
and
I
had.
This
thing
was
called
like
attributes.
C
You
can
have
like
attributes
of
the
request
and
eventually
I
decided
I
didn't
like
having
attributes
or
requests,
but
instead
I
wanted
to
have
restrictions
for
requests,
in
other
words,
a
restriction
rather
than
attribute,
which
has
them
a
much
more
general
semantics.
Restriction
means
if
I'm
applying
this
through
the
request.
C
There
are
other
authorization
decisions
that
are
made
about
the
policy
of
this.
We
can
talk
about
about
authorization
policy
in
Terry
as
well,
but
that's
one
change
the
model
since
the
last
time
I
talked
about
is
now
requests,
don't
have
attributes
anymore.
They
just
have
restrictions,
they
always
are
being
made,
but
more
narrow
by
adding
these
qualifiers
to
them.
Responds
yes,
just
a
quick.
C
E
C
C
The
purpose
of
restrictions
is
to
give
the
client
way
to
reduce
the
set,
that's
like
they
receive
or
to
receive
nothing
if
there's
nothing
applicable,
which
might
be
exactly
right
thing
about
them
and
that's
what
response
codes
are
like
if
you
send
a
request
for
something
and
there
are
no
suitable
records
or
get
back
a
response
code
saying
I
got
nothing.
There
are
similar
things
about
unauthorized
access
to
records.
There,
of
course,
is
a
success
response,
but
yeah.
The
basic
idea
is
for
the
retrieval
ich
in
Amish
case
right.
C
When
you
send
a
a
request,
a
successful
response
will
contain
one
or
more
records.
That'll
be
useful
to
you
and
doing
what
it
is.
You
want
to
do
in
life
next
time,
so
this
is
kind
of
what
I've
got
in
mind
anyway
and
I.
Have
this
really
quick
and
dirty
like
JSON
mash-up
with
this,
but
the
notion
is
basically
that
any
given
request
will
have
a
source,
the
sources.
Usually
it
gives
it.
There
is
the
request
source.
There
can
be
like
a
query
intermediary.
C
F
B
C
So
yeah
this
is
exactly
I'm
talking
about
about.
How
are
these
kinds
of
restrictions
work?
Of
course
again
we
I
know
it
would
be
great
to
have
a
Jeffers
fab.
Can
anyone
here
please
subscribe
to
the
I?
Do
I
need
to
go
on
strike
until
there's
Jeffers
revving,
because
you
know
it's
been
a
long
week
and
frankly,
labor
disputes,
sir.
B
C
Yeah
I
mean
when
we
actually
imagine
how
these
semantics
would
be
mapped
onto
restful
api,
somehow,
probably
the
subject
wouldn't
not
being
mirrored
in
the
URL
or
whatever,
but
just
take
this
for
the
moment,
as
just
a
data
object,
that's
intended
to
convey
everything
there
would
be
in
a
request
next
slide
and
this
example
responds
you
talk
to
that
service.
That
service
says
oh
I
know
you
are
I,
am
no
reason
to
give
you
anything
so
yeah
we're
gonna
have
a
number
of
different
response
codes
like
this
identified
right
now.
C
C
So
I've
already
talked
a
lot
about
records.
It's
important
to
appreciate
before
we
get
into
this
use
case,
especially
that
we
imagine
this
concept.
That
was
service.
As
being
you
know,
a
repository
for
these
records
that
could
be
Network
remote
or
could
be
that
something
is
kind
of
local
that
you're
dipping
through
Terry
as
an
API
right.
C
We
want
to
have
a
way
to
distribute
these
records
out
radically
and
flood
and
propagate,
and
so
on,
so
that
for
some
kinds
of
networks
and
applications
of
this,
it
makes
a
lot
of
sense
to
have.
You
know
every
record
that
is
relevant
to
everything
being
every
Terry
service
that
is
co-located
with
everybody,
that's
actually
to
use
the
application.
There
are
certainly
use
cases
we're
considering
have
very
much
that
property.
C
Well,
potentially,
all
of
those
entities
could
eight
records
of
some
kind
and
the
question
again
of
whether
or
not
you
use
records
you
as
a
relying
party
if
the
retrieval
interface
or
kind
of
gets
these
records
from
a
Terry's
service.
It's
entirely
based
on
whether
you
not
you
trust
the
authority
that
created
it,
and
so
it
could
be
in,
like
carrier
environments,
carrier
trust.
The
records
other
carriers
may
have
is
not
so
interested
in
what
a
user
made,
for
example,
but
the
whole
Terry's
service
could
contain
a
mix
of
these
records
and
again
through
restrictions.
C
You
could
winner,
those
down
to
the
ones
you're
interested
in.
There
are
all
kinds
of
possibilities
like
this
that
arise
from
the
way
that
we've
decide
that
and
yeah.
We
obviously
because
of
the
way
that
the
modern
framework
is
designed.
We
have
to
accommodate
things
like
government
entities,
which
is
a
component
of
that.
The
notion
there
are
entities
they'll
have
privileged
access
to
Terry
services.
It's
the
fact
of
life
to
ignore
it
would
not
be
productive
for
getting
the
protocol
that
we
need
to
have
next
slide.
C
So
here's
a
I
should
put
this
slide
earlier.
Here's
in
table
data,
Terry
success
response
looks
like
and
what
a
record
actually
might
look
like
in
the
middle
of
this
and
again
these
are
mock-ups.
Let's
not,
you
know,
I'm
sure
the
syntax
is
broken
here
and
there
that's
not
dwell
on
that's
the
moment,
but
the
basic
idea
is
the
records
are
gonna
have
an
identifier.
C
This
lets
you
uniquely
identify
them
so
that,
if
say
you're
using
the
management
interface,
you
want
to
update
a
record
if
you're,
because
you
aren't
ready,
you
know
you
want
to
push
an
entire
copy
event.
You
need
to
use
that
identifier
right
to
make
sure
that
you
can
figure
out
which
record
you're,
trying
to
replace
the
example
of
an
authority
of
a
signature
that
lets.
You
know
who
was
actually
generated
this
record
and
in
this
instance
you
know
records
can
have
multiple
subjects
that
isn't
true
of
requests,
but
it
is
true
of
records.
C
In
other
words,
there
can
be
a
record
that
gives
the
same
basic
data
about
a
very
wide
range
of
numbers
actually,
and
we
have
this
concept
in
the
framework
of
a
distinction
between
administrative
data
and
service
data.
Frankly,
you
know
it's,
it's
still
a
little
vague.
What
we
mean
by
that
but
administrative
days,
a
perfect
example
of
something
where
you
might
have
a
record.
C
That
applies
to
a
ton
of
numbers,
because
what
it
really
tells
you
is
like
these
are
all
Comcast's
numbers
right
and
like
it's
just
something
like
piece
of
administrative
data
like
that
that
isn't
actually
used
in
the
resolution
of
a
call
or
figure
out
how
to
route
it
or
whatever
it's
it's
just
there.
So
you
can
do
like
you
know,
accounting
or
whatever
it
is
you
like
that.
C
So
does
this
stuff
so
far,
Terry
seemed
clear
to
people,
because
people
kind
of
get
where
we're
going
with
this
and
like
are
people
here,
who
think
that
we
should
be
doing
something
different,
cuz
I
ask
this
to
lock,
as
we
I'm
now
on
again
Mike,
my
third
revision
of
Terry,
and
it's
not
one
group
item.
Yet
it
should
be
at
some
point.
Probably
if
we're
gonna
get
serious
about
this
I
don't
know
if
it
needs
to
be
today,
but
if
there's
a
need,
for
course,
correction.
This
would
be
great
time
to
let
us
know.
B
E
C
Trip
yeah
I
mean
an
authority,
can
always
create
a
record
right
for
something
they
don't
have
authority
for,
but
the
the
purpose
of
tying
this
to
the
stir
like
credentials
is
presumably,
if
you're
making
a
record
for
a
telephone
number.
You
should
have
the
ocn
right
that
that
number
is
in,
and
if
you
don't,
that's,
actually
show
up
as
a
security
failure.
It
should
be
detectable
in
the
system
and
I.
C
It's
this
point,
I,
don't
quite
think
crud
I,
think
scrud,
but
I
do
think
of
it
as
a
life
cycle
matter.
If
there's
an
ecosystem
that
these
records
exist
in
that
there's.
This
concept
that
the
registry,
which
is
kind
of
the
route
of
numbering
authority
for
a
given
chunk
of
modern
and
modern,
doesn't
necessarily
assume
a
one-world
government
I'm
behind
this.
C
Just
that
there
are
apex
points
of
registries
that
are
the
places
that
registrar's
get
numbers
from
how
those
people
get
related
to
each
other
and
what
the
deal
is
with
that
is
business
relationships
and
stuff.
That
is
outside
the
scope,
at
least
what
we're
trying
to
accomplish
here.
We
seem
to
acknowledge
that
they
exist
now.
Paul
would
like
to
speak
to
that.
H
Hoffman,
so
that
was
sort
of
my
question
on
the
search
part.
So
how
do
I
know
where
to
search
if
I
I
mean
I
know
if
I
know
about
this
tree,
I
can
search
in
that
tree
tree
discovery
or
treat'
linkage.
Is
there
I
didn't
see
anything
in
here?
Is
there
a
plan
sort
of
for
later,
and
at
least
an
informal
like
picture
of
a
tree?
It
doesn't
have
to
be
formal
like
this?
H
C
On
trees
and
it
seems
to
call
forest
guides
that
let
you
find
the
trees
that
you're
looking
for,
and
it's
based
on
the
same
principle
that
you
kind
of
you
only
that
was
a
telephone
number.
How
do
you
figure
out?
What
writing
is
you
need
to
talk
to
yep,
so
it's
been
studied.
We
are
making
specific
recommendation
yet,
but
definitely
agreed
that
at
some
point
we
need
to
say
with
us.
H
H
C
C
First,
for
a
reasonable
value
of
no.1,
I
think
as
an
implementation
problem,
I'm
not
immensely
worried
about
being
able
to
get
implementations.
That
would
rely
on
something
like
this,
so
it
knows
if
you,
if
you
know
enough
to
even
be
using
the
retrieval
interface
of
this
know,
then
I
suspect
that
I
can
for
North
America.
At
least
I
can
take
care
of
that.
Okay.
E
Chris
went
so
I
think
both
John
and
I
have
contributed
our
opinions
on
different
data
models
and
I.
Think
that
was
the
path
we
were
heading
down
to
have
a
particular
data
model,
with
specific
indexes
that
you
can
query
specific
relationships
between
those
data
objects,
I,
don't
think
it'll
actually
be
a
tree
at
the
end
of
the
day.
I
think
it
will
just
be
more
of
a
relational
model.
I
C
Yeah
yeah
I
mean
it's
I.
Think
Paul's
point
was
more
like
you
know.
If
we
assume
that
every
carry
record
is
not
propagated
to
every
teri
service
and
that
there
are
different
records
resident
in
different
places
through
some,
thereby
authorities.
How
do
you
find
the
right
service
for
the
record
that
you
need
and
that
that
is
a
an
implementation
question
about
how
you
would
actually
operate
the
system
like
this?
There
are
a
bunch
of
design
decisions
you
could
make
about
how
to
do
that.
Yeah.
C
E
E
E
J
Tomic,
every
new
store
I
think
we
cover
at
least
some
of
this
when,
in
the
framework
document
where
we
talk
about
distributed
versus
central
registries,
at
least
that's
what
I
think
it
may
not
say
it
hats,
but
I
think
that
there's
gonna
be
multiple
ways
that
you
know
we
envision
multiple
ways
to
do
this
and
one
place
may
want
to
centralize.
So
you
know
where
to
search
and
the
place
may
want
it
distributed
so
your
service
provider,
your
favorite
service,
helps
you
do
that.
That's
how
I
thought
about
it!
Anyhow,
yeah.
We.
E
C
So
yeah
right
right
now,
because
we
are
trying
to
keep
this
to
kind
of
spread,
--is--
limits
like
there's
no
concept
of
like
uploading,
a
delta
about
a
record
or
anything
like
that.
You're
gonna,
replace
the
record.
You
replace
the
record,
that's
just
like
how
the
model
works
right
now,
maybe
later
well
care,
because
some
of
these
records
could
be
quite
large
to
the
point.
Maybe
later
we
will
care
about
that,
but
we
don't
care
about
it
now
and
any
authority
can
update
or
delete
its
own
records.
C
You
kind
of
can't
have
authorities
like
clobbering
each
other's
records,
but
again
it
doesn't
matter
if
multiple
authorities
are
talking
about
the
same
thing,
because
it
really
comes
down
to
the
conscience
of
the
relying
party
to
determine
which
authorities
they
trust
and
why
and
there'll
be
business
relationships
and
various
things
like
that
to
dictate
that
that
will
make
that
all
work
just
like
it
works
today.
Prob'ly
next
line,
so
I've
already
talked
about
these
things.
I,
don't
wanna
go
into
this
too
much
so
there's
an
acquisition
operation.
C
This
is
what's
in
it,
these
the
kinds
of
responses
you
get
I'm
just
gonna
flash
through
these
next
slide
management
like
in
management.
If
you
have
a
record
in
the
query,
what
you're
really
saying
is
probably
hey
put
this
record
in
the
provisioning
interface
for
this,
there
can
also,
in
the
management
interface,
be
records
and
responses
in
some
cases.
Next.
I
C
Yeah,
that's
that's.
Just
keep
going.
We've
got
this,
so
this
is
what
we
actually
want
to
talk
to
most
about
today.
Now
we've
done
the
refresher
course
on
Terry.
Everybody
is
aware
there
exists
such
a
thing
as
Terry
and
basically
what
it
does.
Okay,
so
here's
a
use
case,
here's
something
you
can
actually
like
do
with
this.
C
There
are
different
kind
of
appetites
right
for
letting
carriers
actually
prevent
and
users
are
receiving
calls.
We
aren't
going
to
make
a
judgement
about
that
you're
anyway,
we're
just
creating
the
tools
that
could
be
used
to
implement
whatever
people
think
the
appropriate
policies
are
for
remediation
of
this,
and
this
seems
like
a
good,
modern
use
case
right.
The
kinds
of
things
we're
talking
about
can't
do
this
we're
probably
barking
up
the
wrong
tree
right.
C
So,
let's,
let's
do
this
because
the
other
things
we
talked
about
because
there
are
they're
too
far
in
the
future
or
whatever
you
know,
I-
think
it's
been
harder
for
people
to
get
their
teeth
around
this.
This
is
something
that's
tangible
today
that
I
think
the
stuff
we're
doing
should
be
able
to
do
this
or
we
got
a
problem
next
slide
so
yeah.
The
idea
is:
there's
a
restriction
now
for
allocated
right
now.
C
It's
it's
we're
trying
to
do
this
in
the
barest
bones
possible
web,
you
basically
to
say
I'm
only
interested
in
formation
that
exists
and
records
about
whether
or
not
this
number
is
allocated
at
this
time
now.
I've
cast
this
here
as
a
request
beam.
This
is
an
important
caveat.
You
see
down
the
bottom
bullet
or
list
doesn't
necessarily
mean
a
network
death
I'm,
not
suggesting
that.
C
Oh,
if
you're
carrier,
like
every
time
you
receive
a
call,
you're
gonna
go
talk
to
some
service
in
the
cloud
and
wait
for
it
to
get
a
response
before
you
progress
it.
This
is
an
API.
I
can
either
be
based
on
a
network
dip
like
that
or
be
local.
In
other
words,
if
you
have
all
the
records
propagated
down
to
you
as
a
carrier
locally,
this
query
operation
is
something
that
just
happens
over.
C
You
know
you
know
your
Ethernet
or
whatever
right
so
so
we
don't
want
to
suggest
that
we're
sitting
here
saying
everybody
needs
to
do.
Queries
like
this.
It's
just
this
is
a
useful
API
for
us
to
talk
about
how
to
access
records
in
the
Terry
information
model
next
line-
and
this
is
what
a
response
might
look
like
the
interesting
thing
about
this
response,
which
says
alec
is
unknown,
which
basically
means
we
were
taking
a
whitelist
approach
to
this.
C
We're
assuming
that,
if
the,
if
and
this
this
something
Tom
raised
on
the
list,
we're
going
to
talk
about
it's
an
open
issue
in
a
bit
they're
kind
of
a
few
levels
of
allocated
that
we
consider
unknown
just
means.
Yes,
these
are
valid
numbers.
Yes,
some
carrier
has
them,
but
we
don't
know
if
the
carrier's
giving
them
out
yet
or
not,
is
what
unknown
words
and
we'll
get
into
the
three
semantics
that
we
have
for
this
in
a
minute.
C
But
the
interesting
thing
about
this
response
is
this
is
a
great
example
of
a
terry
request
that
leads
to
a
response
that
has
a
recording
that
encloses
the
number
that
was
the
subject
of
the
request,
so
the
request
active
a
test
about
a
specific
number
under
two
and
two
five
five
five
one,
but
this
particular
pool
thousand
block
has
just
one
record
that
governs
it.
That
indicates
its
allocation
status,
and
so
that's
what
you
end
up
getting
back
when
you
ask
for
hey.
Are
there
any
records
for
this
number
that
are
allocated
yeah?
C
C
I
don't
want
some
guy
to
like
outsmart
ring,
because
the
semantics
is
I
devised
for
what
an
invalid
number
possibly
could
be.
Has
some
like
loophole
in
it,
that
I
didn't
see
right
and
then
then
we're
screwed,
so
I
rather
just
have
it
be.
Here's
the
all
the
block,
the
allocated
numbers,
yes,
Pernik
well,.
G
C
G
C
C
You
can
have
our
yeah,
and
this
is
this
so
I
forget
if
we
have
an
example
where
we
actually
have
a
subject
with
requests
with
arrangement,
but
yeah
just
means
one
number
R
means
range
of
numbers,
and
the
only
way
Express
range
in
this
instance
is
prefix.
We
have
another
open
ish
in
the
data
model
of
whether
we
want
count
to
be
a
separate
way
of
doing
it.
I.
This
is
something
we
killed
ourselves
over
and
store
serfs
right
as
well
like
should
you?
C
C
C
So,
in
other
words,
if
you
have
a
record
that
says
allocated
know
what
that
means
is
this
is
a
valid
number
there's
an
allocatable
number,
but
it
is
absolutely
absolutely
sure
that
no
number
that
this
individual
number
of
rats
arranged
no
number
in
that
range
has
been
allocated
yet
would
be
the
meaning
of
that
record.
If
you
ask
about
a
number
that
is
literally
invalid,
that
is
unallocated
all
there
will
be
no
records
and
that's
how
you
will
know
that
that
is
an
invalid
number.
C
So
this
is
trying
to
use
this
one
right
now.
The
grounders
do
this
one
parameter
to
convey
a
couple:
different
states
of
information
right.
If
you
get
back
allocated
and
get
back
know
what
that
means,
this
valid
number
not
allocated
yet
no
record
means
invalid
number
can't
be
allocated
shouldn't,
certainly
shouldn't
be
originating
calls,
and
then
assignment
is
the
third
vector
of
this.
So
if
you
get
back
for
an
individual
telephone
number
record
assignment
equals
yes
or
allocation
allocated
equals.
Yes,
that
means
that
number
is
assigned.
Someone
has
that
number
it's
a
valid
number.
C
C
Unknown
just
means
like
I,
don't
know
now.
This
is
this
again
was
a
bare-bones,
how
much
maybe
with
a
single
parameter
just
to
get
this
discussion
started
Tom
raised
on
the
list.
Why
don't
you
decouple
some
of
this?
If
these
and
out
you
know
I,
guess
there
is
a
distinction
between
allocation
and
assignment-
that's
like
already
in
the
literature
of
this,
and
that
we
could
have
allocated
and
assigned
be
hierarchical.
Properties
of
this,
in
other
words,
number
must
be
allocated
in
order
to
be
assigned
those.
Those
two
are
dependent.
C
Probably
you
have
a
number
there's
a
sign,
but
not
allocated
right,
so
we
could
add
some
further
qualifier
to
allocate
it
that
then
says
and
also
assigned
if
we
were
so
inclined
to
do
so,
I
mean
I
think
that
we
can
do
that
for
the
sake
of
being
compliant
with
what
this
you
know,
terminology
is
it's
being
used
also
in
the
industry,
but
overall
I
mean
I.
Think
I
think
this
for
the
purposes
of
beating
the
threat
model
that
this
represents.
I
think
the
information
we
have
here
is
information
that
we
need.
C
In
other
words,
what
you
need,
what
you
really
need
to
know
is:
is
this
number
that
and
allocate
it
right?
If
those
things
are
true
right,
then
I
think
you
have
a
sense
of
whether
or
not
this
originated
numbers
having
that
kind
of
a
real
time.
Is
this
in
real
time
a
sign
to
some
particular
user?
That's
a
property
that
we
may
need
for
future
use
cases.
I
would
not
take
it
off
the
table.
C
E
One
I
feel
like
this
could
be
a
lot
simpler
and
you
know
I
think,
like
you're
sort
of
trying
to
think
of
the
implementation
and
the
requirements.
At
the
same
time,
and
to
me
a
number
block
is
either
allocated
or
not,
and
a
telephone
number
which
may
be
in
that
number
of
walk
or
May
or
well
could
well,
obviously,
it
will
be
in
some
number
lock,
but
it'll
be
you
can
be
have
a
property
of
both
allocated
or
assigned
or
both.
C
C
C
C
C
E
C
E
E
E
I
C
C
H
C
I
said
it's
an
I
think
I
have
been
presuming
that
real-time
allocation
I'm,
sorry,
real-time
assignment
data
is
unavailable
to
the
system
because
I
believe
in
North
America.
Real-Time
assignment
information
is
unavailable
to
this
system,
but
I
mean
I,
so
I
think
it'll
be
it'll,
be
in
no
lab
to
do
this,
which
is
why
I'm
like
saying
the
best
I
can
say
about
is
unknown.
B
D
Roach,
so
this
is
kind
of
up
leveling
a
bit
if
I
I
think
the
document
is
a
good
illustration
of
like
how
Terry
works.
You
know
in
a
very
practical
sense,
but
I
have
some
confusion
about
how
we
think
this
is
going
to
play
out
if
it's
actually
deployed
in
making
the
problem
rather
than
worse,
because
what
I
see
is
you
know,
game
theory
this
outright?
This
is
deployed,
people
start
getting.
You
know
the
calls
the
originating
from
an
allocated
numbers
stop
doing
what
they
want
to
do.
D
C
C
Thank
you
mean
if
we
drive,
we
drive
people
away
from
using
invalid
numbers.
What
we'll
do
is
spoof
valid
numbers
right
and
get
that
would
just
make
things
works,
wouldn't
it
well,
but
if
we
have
stir,
then
you're
not
gonna,
be
of
scooping
fella
converse
anymore.
Is
that
the
argument
right
so
we're
trying
to
drive
from
multiple
sides
to
get
this
address.
D
C
It's
I
probably
heard
various
arguments
about
this
right
about
what,
when
people
do
choose,
for
example,
to
spoof
valid
numbers
where
they
choose
them
from
headings
study
this
a
bit
and
they
think
there's
like
notoriously
prefixes
in
Washington
state
that
people,
you
so
I
mean
there's
like
all
kinds
of
things
that
end
up
factoring
into
how
that
happens.
Well,
I
know:
I
get
the
most
verbal
calling
personally
from
things
that
match
my
own
NPA
and
xx.
C
K
I
think
your
point,
my
gut
feel
as
you
will
have
to
have
the
separation
John
between
these
different
categories
of
unknown
allocated.
Maybe
some
allocated
potential
Ella
codes
in
there
too.
I've
not
only
thought
enough
about
this,
but
I
big
memories
of
something
was
back
to
the
days
of
the
you
know,
Morse
and
with
a
particular
problem
there
that
was
to
do
with
voice
operators
who
would
then
be
doing
an
enum
lookup
in
certain
cases,
and
you
needed
to
sell
me
a
signal
back
to
the
VoIP
operator.
There's
nothing
here.
K
K
C
I
think
yeah
I
do
remember
that
no
you
mention
it
again.
Problems
with
that
are
very
similar
to
the
problems
of
the
rest
of
you
know
that
you
know
so.
I
think
that
was
the
blacklist.
Approaches
have
wait
list,
first
of
all
where
it's
like.
This
is
something
you
shouldn't
go
back
to
the
PSTN
list.
Don't
do
it
if
it's
records,
president
I,
don't
want
that
to
be
the
way
this
work
for
I
have
to
think
of
every
record
that
needs
to
be
put
in.
Yeah
means
don't
do
this,
but.
E
Chris
went
so
maybe
just
to
provide
some
perspective
if
you'll
indulge
me
from
you
know,
from
service
provider
community,
just
as
in
stirrer
as
we
sort
of
took
the
approach
of
starting
with
service
provider
certificates
only
and
then
entertain
the
fact
sort
of
the
crawl
walk
run
approach.
That's
much
more
practical,
deploy
in
a
very
big
network
that
you
know
with
multiple
players
and
everything
else.
I
think
this
really
represents
something
that
you
know
and
and
maybe
just
to
go
back
to
the
real-time
thing
like
it.
E
E
C
J
Time
we
carry
news
star
I
just
want
to
give
a
little
more
background
on
what
you
were
just
getting
into,
and
and
also
first
say
that
I
think
this
is
a
great
opportunity
to
put
out
a
Terry
giraffe
of
a
use
case
that
we
can
understand
and
discussion.
The
room
is
really
great
because
we're
now
discussing
you
know
the
records
and
access
to
it.
The
the
allocated
versus
a
sign
kind
of
goes
back.
You
know,
at
least
in
the
u.s.
J
to
the
90s
when
we
almost
you
know,
blew
up
our
numbering
plan
and
we've
almost
had
to
go
past
ten
digits
because
of
competition,
local
competition,
where
we
gave
everybody
telephone
numbers,
ten
thousand
bucks
and
the
industry
really
wanted
to
know.
Okay.
How
many
of
these
we
know
how
many
were
giving
out
we're
allocating
how
many
were
actually
assigned,
so
we
implemented
something
else
where
we
take
inventory
once
or
twice
a
year
from
carriers,
and
now
we
basically
know
that
of
the
X
amount
that
we
allocate.
J
E
That
was
gonna,
be
my
comment
that
ultimately,
at
the
end
of
the
day,
he
could
no
matter
whether
it's
allocated
or
assigned
it
should
be
both
and
everything
should
be.
Real-Time
and
single
numbers
number
of
blocks
was
only
just
to
have
enough
inventory
because
you
didn't
have
a
real-time
database
right,
yeah.
C
I'm
kind
of
kind
of
fading
here,
I
think
so
so
yes,
we'll
get
this
viewfinder
sanctioned.
This
will
be
allocated
inside
next
one,
it's
kind
of
kind
of
a
related
point.
So
right
now
we
kind
of
created
two
two
approaches
to
this:
where
we're
gonna
use
ranges
or
things
like
true
so
north
american
numbering
plan
blocks
and
it
have
individual
TNS.
The
example
we
always
give
of
individual
TN
allocation
is
free
phone
right
like
if,
today
you
go,
get
like
an
800
number.
C
You
like
go
to
your
carrier,
get
like
a
block
of
800
numbers
right,
carry
don't
have
inventories
of
those.
There
are
these
rest
words
that
responsible
friend,
it's
this
whole
like
registry
system.
Much
like
with
domain
names.
Are
you
go
and
get
800
numbers
from
these
effectively
registrar's
and
and
then
get
carriers
to
operate
them
for
you?
C
That's
a
way
to
implement
what
we
just
described,
I'm
going
to
say:
we
only
talk
about
allocation
for
the
ranges
we
like
a
assigned
for
the
individual
numbers,
the
way
that
the
draft
is
written
today
again,
if
what
what
you
means
when
you
say
that
an
entire
block
is
allocated
is
effectively
that
it's
assigned
that
every
number
in
of
this
block
of
a
thousand
is
assigned.
That
may
not
be
a
useful
metaphor,
may
be
more
useful
to
just
have
allocated
be
this.
C
Yes,
no,
and
then
there
is
this
separate
property,
a
sign
that
applies
only
to
individual
TOS
I
mean
right
now,
they're,
not
in
any
way
hierarchical.
Whether
ascribe
they
could,
you
know,
they're,
just
separate
kind
of
what
I
took
away
from
the
previous
discussion
is.
Maybe
we
should
have
that
be
hierarchical
from
them,
whatever
say?
Okay,
if
we're
first,
we're
gonna
have
the
allocated
and
then
assigned
that
the
like
actual
concern
about.
That,
though,
is
this
thing
in
the
Terry
model
of
what
authority
is
for
these
things?
C
Right
for
authority
is
for
a
record,
and
you
know
we
want
to
allow
the
possibility
that
say
a
carrier.
Has
this
block
of
numbers
and
they
have
delegated
some
amounts
of
them
say
to
an
enterprise,
and
if
the
enterprise
is
going
to
be
doing
signatures
for
these
things,
if
we
have
the
kind
of
what
it
means
to
be
assigned
to
be
part
of
the
same
record
that
the
carrier
creates
to
describe
its
allocation,
then
hierarchically
like
it'll,
be
carrier.
C
Signature,
that's
over
that
whole
thing
and
the
enterprise
kind
of
doesn't
have
a
way
to
present
its
record.
For
that,
then.
So
maybe
I
would
like
it
better
if
they
were
separate
this
way,
it
still
gives
the
same
thing.
There's
these
two
properties
right
where
one's
allocated
what's
assigned
it's
just
the
assignment
property
is
tied
to
this
individual
TM
concept.
Okay,
well,.
E
E
C
C
I
think
it
goes
beyond
that
too.
In
that,
like
the
way
the
tairy
model
is
designed
again,
there
can
be
multiple
authorities
that
are
assigning
records
that
would
match
the
same
search
in
the
sense
of
there
can
be
a
record
for
the
block
and
a
record
for
the
neutral
TN
one
that
comes
from
the
carrier
when
it
comes
to
the
enterprise
they
can
both
live
in
the
surface.
When
you
do
retrieval,
they'll
get
one
of
the
other.
If
you
trust
only
two
carrier,
you
listen
to
that
one.
M
G
E
C
These
records
have
subjects
they're,
always
indexable
again
and
probably
have
a
search
function.
You
need
the
search
in
scrub
to
be
able
to
have
that
that
flexibility,
but
I
mean
it's
not
like.
You
know,
if
you're
inspecting
all
the
records
in
the
service
you're
not
going
to
tell
that
these
records
are
connected
by
the
fact
that
this
number
is
enclosing.
C
J
C
That
it's
true
so
I
guess
what
I'm
taking
away
from
that
I
mean
I'm.
So
I
agree
that
we
need
to
have
that
indexing
property
in
the
database
to
be
able
to
figure
out
how
these
records
are
correlated
but
I
think
a
clean
way
to
implement
the
distinction
that
we
want
to
have
between
the
allocated.
The
assigned
is
roughly.
E
C
B
C
C
But
it
also
could
just
be
that
the
management
interface
is
used,
share
records
kind
of
peer-to-peer
between
services.
We
cut
due
to
that
in
Terry
today,
but
since
we're
not
getting
down
to
the
concrete
implementation
of
this
of
that,
the
book
of
that
transport
effectively
for
these
records,
because
we're
not
doing
that
like
that's,
probably
where
most
of
that
would
live.
C
Like
this
is
often
starved
for
energy,
it
just
seems
like
every
time
we
should
be
working
on
this
there's
something
else
that
is
more
important.
Stur
has
been
more
important
for
a
long
time
now.
The
course
Dirac's
are
getting
to
be
our
C's,
of
course.
Now
there's
a
million
extension
sister
now
I'm
racking.
My
brain
assaults
are
out-of-band
and
things
like
that,
and
then
there's
acne
and
all
the
stuff.
We
need
to
do
in
acne
now,
which
is
going
to
have
rack
our
brains
as
well,
because
we
need
that
for
the
cert
steps
to
sportster.
C
However,
I
think
there
probably
is
enough
energy,
especially
if
we
treat
something
practical
like
this,
to
get
something
like
this
done
to
the
point,
where
Terry
isn't
just
a
hypothetical
statute
more.
That
people
here
think
that
this
is
a
good
use
case
for
us
to
go
pursue
for
this,
then
we
could
actually
maybe
do
some
good
with
that
I'm
happy
to
put
a
little
fire
under
it.
C
That's
kind
of
what
I'm
thinking
and
you
know
again.
We
would
use
this
as
a
way
to
flesh
out
Terry
as
we
go
right
is
the
idea
just
take
this
use
case.
We've
got
Terry
somewhat
specified.
Well,
as
we
get
deeper
into
this,
we'll
get
the
encoding
x'
and
things
like
that
and
the
transports
down
to
the
point
where
this
is
actually
practical.
J
C
She
did
that
I
got
the
good
stuff
all
right,
so
that's
all
I
got
that's
it.
This
is
my
it's.
My
last
slide.
C
D
C
You
know
I
don't
want
to
have
that
become
too
cumbersome,
but
for
right
now,
I
kind
of
like
having
yours
race
most
by
the
information
model.
Here's
where
you
specify
how
we're
encoding
that
information
model,
and
then
this
is
like
a
practical
use
case
that
shows
like
a
profile
of
it
and
how
you
actually
do
it
right.
This
one
valid
thing:
I,
don't
mind,
keeping
three
things
eventually,
I
would
merge
that
encoding
into
core
Terry
when
I'm
comfortable
with
that,
but
I'm,
not
comfortable,
yeah
and
I'd,
want
the
transport
stuff
to
be
done
before
I.
C
H
Mr.
Aaron
Berger
says,
given
that
Terry
is
still
looking
for
a
solid
use
case
and
from
today's
discussion
we
are
still
looking
for
a
direction.
Would
it
not
make
more
sense
to
keep
it
individual
until
something
solid
emerges?
Is
this
not
sufficiently
solid?
This
is
terra
firma
compared
to
where
we've
been
then
okay
well,
Erik
didn't
seem
to
hear
a
solid
use
case.
Okay,.
H
E
E
That
we
should
shouldn't
so
I
think
we
can
do
a
little
better
here
and
we
even
in
the
FCC
Strikeforce.
We
discussed
a
path
forward
for
even
though
we
didn't
have
a
specific
solution.
We
knew
some
of
these
things
were
on
the
horizon
and,
as
I
stated
before
evolving
the
industry,
to
have
be
more
confident
about
the
numbers
that
can
block
because
they're,
either
unallocated
or
on
assigned
or
whatever
seems
to
be
a
very
positive
direction
forward.
D
C
A
O
E
There
we
go
yeah,
so
I've
gone
through
drip
a
few
times
in
the
past,
I'm
fully
willing
to
go
through
a
view
again
sort
of
gauge.
You
know
who's
new
here
and
I'm
happy
to
go
through
it
again,
but
we
don't
need
to.
If
everybody's
already
hurt
this
time,
I
don't
see.
Any
clamoring
I'll
still
provide
a
higher
level
overview,
and
you
can
ask
specific
questions
if
needed
and
I
have
slides
to
complement
that.
E
So
the
idea
how
behind
drip
is
really
the
ability
so,
as
John
alluded
to
when
you're
doing
real-time
call
processing
doing
an
HTTP
query.
All
the
way
back
to
some
centralized
database
is
probably
not
a
good
idea
so
and
distributed
databases
you
know,
are
in
very
wide
use
at
this
point.
It's
a
proven
technology.
E
So
the
idea
is
that
you
have
a
registry
that
uses
a
gossip
style
protocol
where,
if
there's
an
update
on
a
single
node
in
the
distributed
mesh,
that
change
will
get
propagated.
Among
all
the
nodes
in
the
network
in
fair
amount
of
real
time
depends
on
the
size
of
the
mesh,
obviously,
but
I
think
for
all
practical
purposes.
We're
talking
about
a
reasonable
sized
mesh
for
the
use
cases
we're
looking
at,
and
the
idea
is
that
you
know
that
update
gets
pushed.
You
have.
E
Then
you
have
it
available
in
a
local
database
that
could
be
queried
in
a
matter
of
hopefully
milliseconds
versus
hundreds
of
milliseconds
or
seconds
or
whatever
the
case
may
be
so
yeah
it's
a
bit.
It's
it
follows
most
conventions.
The
big
thing
about
Tripp
was
that
we
try
to
take
a
fairly
straightforward
approach.
E
E
E
E
I
think
the
argument
is
the
same
with
Terry.
If
we
feel
like
we
have
a
valid
use
case
and
we
feel
like
there's
no
other
inputs
on
this
subject,
should
we
consider
it
as
a
working
group
document
we
also,
as
I've
mentioned
before,
we
have
an
implementation,
we're
willing
to
open
source
so
that
the
industry
can
play
around
and
provide
feedback.
I
think,
obviously,
if
this
will
need
a
lot
of
testing
and
operational
experience
to
go
into
it
to
be
very
confident
about
it,
so
that
that's
another
dimension
as
well.
C
Hi,
it's
John
again,
I
mean
I.
Think
we
should
do
something
like
this
at
some
point
here.
Right,
I
think
this
again
goes
back
to,
as
I
mentioned
at
the
start,
the
the
FCC
workshop
that
inspired
all
this
we're
talking
about
kind
of
alternative
approaches
to
numbering
that
might
be
interesting
and
I.
Think
one
of
those
two
interesting
experiments
we
really
do
is
one
that
used
a
distributed
registry
system
like
this,
to
allow
kind
of
real-time
allocations
from
a
mixed
number
block
from
carrier
or
something
to
be
a
really
cool
thing
to
do.
C
Is
that
kind
of
experiment?
So
definitely
it's
always
been
my
plan
to
get
us
here.
Right
I've
always
wanted
to
get
us
here,
which
was
like
what
order
we
should
do
things
in
or
what
what
is
most
used
to
do.
First,
we
we
have
reconciliation
work
to
do
to
figure
out
what,
how
drip
and
tarry
relate
and
kind
of
what
that
is
about,
but
I
think
I
think
pretty
much
as
soon
as
we
at
least
have
some
idea
of
that.
I
think
we're
in
good
shape
to
adopt
this
sure.
C
E
A
G
G
E
H
L
A
Okay,
well,
we
can
continue
this
on
the
list
and
see
what
kind
of
feedback
we
get
unless
were
for
promoting
it
too
great.
Thank
you
thanks
Chris.
So
that's
all
we
have
presentation-wise.
We
had
a
slot
for
for
discussion.
If
there's
anybody
has
anything
else
they
want
to
to
bring
up
today
seems
like
we
made
good
progress.
Hopefully
we
can
get
some
more
energy
on
the
list
now,
if
we,
if
we
start
advancing
some
work,
it
has
been
pretty
sleepy.