Presentation by George Michaelson And Byron Ellacott at APRICOT 2017 on Monday, 27 February 2017.

1. 2017#apricot2017
Whowas: A resource
history service at APNIC
Byron Ellacott
George Michaelson

2. 2017#apricot2017
Overview
• Motivations
• Approach
• API Service
• RDAP extension
• UI Experiment
• Future Plans
2
The Archimedes Palimpsest

3. 2017#apricot2017
Motivations
• Long standing request for a history function
– Dispute resolution
– LEA searches
– Transfers checking for ‘clear title’
– Research interest (informing the policy development process)
• Increasing the transparency of registry operations
– One of a number of activities aimed at improving trust
3

4. 2017#apricot2017
..But doesn’t Whois have history?
• RIPE Whois history mechanism since 2014
– Tracks changes of {ADD, UPD, UPD…} to all Whois objects
– Each change moves the prior state to the head of history for that
object, based on its object-id (an internal key)
• DEL-ADD events disconnect history from the “head” state
– The DEL/ADD pair even of the same data creates a new object-id
• The history is against the old object-id, which is now buried inside the system
– Many changes in Whois are done through sequences of {DEL,ADD}
• The history is “there” but its been disconnected from the head object
4

5. 2017#apricot2017
Approach
• Expose previous states of the registry as seen through
Whois
– Reconnect the disconnected history from DEL events
– Perhaps other information sources in the future (historical data)
• Provide stable entry points which others can code to
– Machine consumable APIs and a separate UI which uses it
• Leverage the investment in RDAP: REST+JSON
– Data returns directly into first-class data structures in most modern
languages: Python {dict} and Perl %{hash}
5

6. 2017#apricot2017
Approach
• Design for the cloud
– Not ‘build it here’ as much as designing service to deploy anywhere
– Scalable services which can meet demand without single points of
failure
– Using “container” models of deployment (docker/kubernetes)
• Open development model for increased transparency
– Use of mechanisms like git, community feedback
– Fork the code and develop your own
– Specification heading to standards processes (also in git)
6

7. 2017#apricot2017
API Service
• The RDAP API service is already deployed:
– IETF RFC on the standards track
– Implemented in common with names registries
– Extensible by design –So lets define an extension
• Extension defined for history
– A set of objects matching a query
– Each with an applicability date range
7

8. 2017#apricot2017
API Service: live
8

9. 2017#apricot2017
API Service: live
9

10. 2017#apricot2017
API Service: highlights
• History is a sub-space of the existing RDAP API
– https://rdap.apnic.net/<rdap-query>
• Gets the head-state of that resource
– https://rdap.apnic.net/history/<rdap query>
• Gets the history of that resource
• IP Records, Domains, ASN, Entities (person, role, IRT)
– There is not a 1-to-1 mapping to all existing WHOIS objects
– (The same as for RDAP: no routing objects, no maintainers)
• This is being explored as future work
10

11. 2017#apricot2017
RDAP Extension
• Draft text for a standard extension mechanism
– Will be registered as RDAP extension through IETF process
– Document in github at https://github.com/apnic-net/rdap-history
• Adds a ‘set’ concept
– To list the prior states of a given resource
• Adds an ’applicability’ concept
– To specify the date range between which a given instance applies
• No constraints on overlaps or continuity of applicability dates are specified
• Profile of RFC3339 Timestamps specification (ISO8601)
11

12. 2017#apricot2017
UI Experiment
• Explore mechanisms to show changing data in time
– Colorized difference between successive versions
– Usual ‘diff’ format markup
• Explore mechanisms to show changing scope
– Most specific to Most covering applicable ranges over a given
resource
– Limit the explosion of potential data from block fragmentations over
time
• What would you want in a UI to explore this data?
12

13. 2017#apricot2017
UI Experiment
13

14. 2017#apricot2017
UI Experiment
14

15. 2017#apricot2017
UI Experiment
15

16. 2017#apricot2017
UI Experiment
16

17. 2017#apricot2017
Future Plans
• Move to a non-experimental API
– Host a stable UI inside APNIC service model
– Underlying API for RDAP/history is already in service
– Warning: API may change as standardization progresses
• Seeking commonality with other RDAP providers
– Gauge interest in other communities
– Ensure the draft can work for anyone who wants to implement a
history mechanism
– Explore an RDAP extension for ‘raw data’
17

18. 2017#apricot2017
Its Alive!
• Overview, pointers to the UI, code, standards
– https://apnic.net/whowas
• User interface
– https://www.apnic.net/static/whowas-ui/
• API
– https://rdap.apnic.net/history/
• Please play, explore, and give us feedback on both aspects of
this work.
18