Managing, Ordering, Distributing, Exposing, & Registering telephone

Numbers WG

IETF 93 Tuesday Afternoon session II - 15:20-17:20

15:20-15:25 (5 min) Agenda Bashing Chairs

Note Well

Agenda Bashing

Working Group Milestone Review

Date Milestone

Mar 2016 Submit Architecture Overview Draft to IESG (Informational)

Jul 2016 Submit Information Model Draft to IESG (Standards Track)

Jan 2017 Submit TN Resolution Draft to IESG (Standards Track)

Apr 2017 Submit Enrollment Data Access Process Draft to IESG (Standards Track)

Jun 2017 Submit Enrollment Process Draft to IESG (Standards Track)

15:25-16:15 (50 min) draft-peterson-modern-problems-01 Tom McGarry

Modern Problems

- problem statements – nothing new

- actors – some new

- mechanisms – not much new

- use cases – all new

- distributed registries and data stores – all new

Problem statement review

Actors – new in 01

- Separation of num auth from registry (focus on work of registry)

- Service enablers

- Should there be two categories of actors

o Adminatration

o Service management

- Assignee and Delegate

Henning – two types of actors

- logical actors such as regulators

- someone who actually participates in the protocol actions

- consumers might have access to a subset of information about their number – need to be clear if this is included as an actor

Tom – delegate is reseller

Henning – delegate is someone who can’t get access to protocol directly but can have some access (write access) to profile

Jon – Need to separate actors that participate in the protocol

Assignee and delegate are roles

Chris – can it be defined in the context of who is making the http request?

Jon – assignee has a business relationship

Henning – CSP and PBX context, small business could use the same protocol as CSP

Worried that the model isn’t general

Jon – Nothing restricting making it general

Chris – are consumer and csp the same?

Henning – could use the same bits on the network. Consumer to csp, csp to registrar but requests could be the same. Names should reflect roles in numbering management

Chris – need to discover if the interface for the end user is the same as interface for the CSP

Tom – user has different requirements then csp such as amount of inventory

Jon – use cases will expose this

Martin – agree with henning, keeping it at level of assignee/delegate with relationship, keeping policy out of discussion, protocol need to identify information conveyed, policy will determine what information is sent between players

Henning – for use cases it is ok to informally use terms, not ready to make them formal protocol roles

Mechanisms

- acquisition

- management

- retrieval

Use Cases

Acquiring TNs

- CSP acquires TN

o Is communication of qualifying info part of the protocol

Jon – modern protocols are not going to give utilization forecasts, will be some out of band information – probably not part of the protocol

- CSP requests TN

Henning – what is the minimal set of functionality we need to support

Tom – interconnect agreements part of problem

Chris – does inventory batch operations need to be part of this?

Tom – part of the way it works today

Jon – likely to need to include batch operations

- Registry assigns TN to CSP

Use case – Acquing TN

- User/Delegate acquires tns from CSP

- Very similar process

Pete – some of it is internal and not protocol, hard to understand which is protocol and which is not, helpful to separate

Martin – existing model requestor is currently carrier, govt authority has a degree of control, end users and corporations have little information, those users have relationship with carriers today and carrier has the information, more information will be needed for non traditional roles

Tom – profile date, right?

Jon – to petes point, credentials requirements is clearly protocol, problem statement is not specification, to martins point, enrollment is where martin’s point is true

Andrew Allen – request procedure – will it take into account vanity numbers? It needs to

Tom – need to specify what the requestor is wants, specific number, range, any, etc.

Chris – thinks it is needed

Henning – will be search criteria, for instance area code all the way to a specific number. Listing numbers that are available will result in millions of numbers

Allen – more of a search string like a domain name

Andry? – already have ability to search on area code

Use case – accessing numbering information

- Two types of information (administrative, service

- Info can be stored at registry or CSP

Use case – accessing numbering information

- service information access

- Privileged access for govt entities

Use case – service management for numbers

- service management

- Updating service information

- Updating administration information

- Changing CSP

- Terminating service

Distributed registries and data stores

Henning – based on prototype, multiple registries might be needed for redundancy purposes. Assuming that sync between registries are worked out. Actors are internally consistency in what they do. So don’t need

Chris – agree with henning

Jon – be good to have text from experience from prototype into the draft

Daryl? – wish this happened 7 years ago (speerment, drinks, etc). calling name part of this? No longer limited by SS7 15 digit limitation.

Jon – proposal for WG for CNIT. Profile will surely have calling name accessor but there are political considerations

Henning – how do you access version how do you validate. Validation is not in scope of modern for calling name.

Next steps

16:15-16:35 (20 min) MODERN Architecture deliverable Jon Peterson

Moving Parts

- acquisition protocol

- management protocol

- query protocol

- these protocols access overlapping data

- surely this is a common information model?

Telephone-Related Information (TeRI)

Jon – does this make sense?

Henning – at abstract level yes, maybe not at bits and bites level, in the end it is a database record. Two types of records so that not all information needs to be stored everywhere. Assume there is a telephone record that might have pointers to other records. We don’t worry about how other pieces are managed, just have pointer to it. Would be helpful to recognize that not all data needs to be replicated and that there will be indirection to things like OCN records.

Chris – word management might be too strong, records should be simple,

Jon – name might change, provisioning?

Chris – is admin info and service info really different things?

Jon – some of this is based on desire to reuse things like done in weirds

Chris – personal preference to keep things simple

Mapping the Modal to an Instance

- TeRi records would live in servers

- All sorts of entities might manage or query

Jon – question of how to organize the work

Andy Newton – are end users always related to telephone system. Is law enforcement one of the queriers of info

Henning – some numbers might be public

Andy – now understand why wierds is being considered

Operations and Records

- proposal – define all three protocols in terms of this TeRI model

- each protocol will have its own operations but operate on a common class of TeRI records

- Operations (query, response, etc) will have their own source, subject and attributes

- TeRI records contain info about TNs

TeRI Record Contents

Transport and Encoding

Chris – the words “data model” are important here. JSON makes a lot of sense. What do we think the data model will look like, how extensible, pretty simple?

Jon – crawl before we work. Look at semantics first, then worry about transport

Henning – will have small set of universal data objects. need to consider IANA considerations, no x-, p-

Dan York – digital signatures?

Jon – some level of digital sigs in objects

Chris – follow CRUD model

Jon – this is the easy part

Peter – will all these protocol run on public internet

Jon – assume they can run on both public and private networks.

Peter – no requirement that it be run only on private internet? Operation and security consideration might be different

Henning – separate issues – name space separation for instance military networks. Enterprises have ability to allocate numbers

Jon – no reason to disallow

Dan York – need to think about this as accessible over public internet. Is intent to write requirements draft?

The TeRI Suite

- Core TeRI model

- TeRA

- TeRM

- TeRQ

-

Jon – currently on the hook for three protocols. Proposal is to extract out the TeRI model. Is this reasonable and how do we execute.

Chris – have a single data model

Jon – should we change charter to reflect this

Henning – keep it simple as possible, distinction between acquisition and management is artificial. Single document might be enough.

Sanjay – are you saying to separate out common element

Jon – separate out core data model first then understand protocols

Steve – Arch spec might be good place for this

Cullen – doesn’t matter how many documents

Martin – agree with Henning and Chris in that they can all be worked at once, keep it simple

Allisa – charter is structured to allow this, milestones can change.

Andy – if we are doing multiple protocols then need data modeling

Jon – data model semantics first

Chris – established ways to handle this, potential approach to use requirements to define actions

Jon – need to avoid making requirements to big

Daryl – requirements docs can sink the process. There are RFCs that can be mined.

Jon – Charter compels us to do that.

Daryl – a lot of work has been done, lets leverage it.

16:35-16:55 (20 min) draft-peterson-terq-04 Jon Peterson

Why present TeRQ today?

The TeRQ Architecture

TeRQ Operations

??? – what is the query source, user or box?

Jon – could be domain name, or URI

TeRM Operations (hypothetical)

TeRQ Base Element Types

TeRQ Profiles

Next steps

Chris – http post put get with conventional mechanisms to map to crud operations

Jon – No re-invention at that level, focusing on semantics

Chris – can define that in data model

Alyssa – Do you envision that the intermediary can perform all operations

Jon – envisioned intermediary as a proxy

Alissa – intermediary might add some complexity

Jon – Query source and query intermediary defined in TeRQ

Chris – Intermediary could be doing other things than just proxy

Jon – Yes

Henning – unconvinced we need to specify the processing of the intermediary

16:55-17:20 (25 min) Modern Prototyping Henning Schulzrinne

Overview

Architecture

Authorization Model

Operations needed

Paxos (& similar dist. Consensus) assumptions

Paxos for distributed consensus

Paxos

Prototype

Implementation

Andy Newton – RDAP component, did you implement

Henning – in progress, need input on if or how to implement

Andy – See a benefit as clients for other registries can easily interface with this registry

Henning – Exactly why its being considered

Chris – with PIN, implying a secure token mech

Henning – yes, inspired by DNS registry model, Some notifications required for instance in number portability

Jon – seems like awesome stuff, where do you think it fits in?

Henning – lead into protocol spec