210 likes | 383 Views
nic.at EPP & friends project. Alexander Mayrhofer axelm@nic.at. Agenda. Nic.at EPP project Hypothesis: Adding the protocol alone is not enough So, what is needed additionally? What we are doing, what you can do Summary Discussion?. The nic.at EPP project.
E N D
nic.at EPP & friends project Alexander Mayrhofer axelm@nic.at
Agenda • Nic.at EPP project • Hypothesis: Adding the protocol alone is not enough • So, what is needed additionally? • What we are doing, what you can do • Summary • Discussion?
The nic.at EPP project • Working on an Open Source EPP aware registry system (AEPPS). • Participating in the Austrian ENUM trial (registry for e164.arpa) • And the not-so-technical-but-as-important-as-the-technical-part stuff:
Q: EPP – the holy grail? Assumption: Some flavour of EPP will become an industry standard in the ccTLD registry business. Questions: Is adding the protocol enough? Which flavour / holy grail will it be (the "Indiana Jones problem")? (Note: We all know what happens when you choose the wrong one ;)
Registrar Operations today „Device driver“ model limits registar‘s offer to its customers, an makes it impossible to work with all registries the same way.
Registrar Operations EPP I Switching Protocol (e.g. to EPP) increases registrar expense (implementation costs) and brings only few advantages because there's still so much different.
Registrar Operations EPP II Converging on a common data model adds a bit more value
Registrar Operations EPP III Adding a common set of processes reduces the number of „device drivers“ to only one (note: policy implications deliberately excluded ;)
Registrar Operations EPP IV And makes it easier for the registrar to work with more registries
Hypothesis: Adding the EPP protocol stack and "backporting" all the local oddities to the new protocol provides no value neither to the registry nor to the registrar.
Where do we have we look? EPP is impacted by:
Protocol – our work. We do: think that EPP is the way to go. Therefore: develop mod_epp plus related stuff. Otmar will elaborate later. Our vision:Provide an Open Source EPP „demo registry“ implementing our (that's you and me, not otmar plus me!) view of how a registry should operate.
Protocol – your work • Think about how an EPP server implementation should work on the protocol layer • Transport layer • Session management (AAA, timeouts, ...) • Intended clients Do a "finer-grained" definition than the EPP drafts. Find out where it clashes with the drafts.
Data model – our work We do:Work on a Data Scheme which supports a typical EPP registry plus investigate differences to currently used local data model. Our Vision:Either eliminate problems or come up with an data model / EPP object extension common to several ccTLD‘s.
Data model – your work • Find out the differences between data models implied by EPP draft mappings and your local model • Objects, e.g. "host"-objects: yes or no? • Attributes, e.g. format of phone numbers Try to map your current object data to EPP objects and vice-versa.
Processes – our work We do:Investigate implications of EPP on processes, look for unneccessary oddities and legacy. Vision:Come up with an proposal for a common set of processes among at least some ccTLD‘s.
Processes – your work • Find out if your current processes can be mapped to EPP transactions, look for legacy • Transactions not possible with EPP • EPP required transactions not currently implemented • Transactions violating a draft "MUST" ;) Try to flowchart your processes with EPP transactions.
Roles/Policies – our work We do:work on a definition of roles, their functions and ownership („who is allowed to do what on what object in which case“). Vision:Agree with other ccTLD‘s about a common model of roles. Avoids confusion at registrar side.
Roles & Policies – your work • Find out: • Who is allowed to do what • Who "owns" an object • Who is responsible for what (e.g. data quality) Try to list "ACL's" for your objects (Warning, may be a multi-dimensional matrix of role, object, transaction, client)
Summary • Changing only the protocol creates the next legacy • Changing protocol is the best opportunity to change data model, processes and perhaps policy • We have already done some small steps, we want your cooperation to complete the quest. Thank you! – Alex Mayrhofer – axelm@nic.at