Applications Area Working Group M. O'Connell
Internet-Draft DNS International
Expires: January 2, 2016 July 1, 2015
Dynamic Business-Rule Implementation and Execution Framework
draft-oconnell-dbrief-01
Abstract
This memo details the structure for implementing a process of
routines or functions that govern any generic task in order to
achieve compliance to predefined a technical framework.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 2, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
O'Connell Expires January 2, 2016 [Page 1]
Internet-Draft D-BRIEF July 2015
1. Introduction
A challenge facing most complex systems is an inherant inflexibility
in the implementation of dynamic legal and technical policies. When
an industry is in constant flux it can increase workload on
developers to maintain the software standards while still allowing
for future extensibility. A formalised policy document is a
requirement in almost every industry however conversion of the
formalised policy document into working machine code is a time
consuming and tedious process, which is furthermore fraught with
hidden complexity and errors. The Policy Engine defined in this
document aims at alleviating the implementation of formalised policy
in a structured and concise format.
1.1. Structure
1.1.1. Technical
The Policy Engine is a structured XML document which contains a
scriptable language as a series of activities and logical branches.
Compiled language or compiled policy engine implementation falls out
of the scope of this document. The intention of the Policy Engine is
to operate on XML based payloads but this could be adapted to work on
any message format.
1.1.2. Methodology
In order to deal with unknown requirements and future extensibility
the Unix philosophy was adopted. The following Unix philosophy rules
(From Wikipedia) should be assimilated when developing the policy
code:
o Rule of Modularity - Developers should build a program out of
simple parts connected by well defined interfaces, so problems are
local, and parts of the program can be replaced in future versions
to support new features.
o Rule of Clarity - Developers should write programs as if the most
important communication is to the developer, including him- or
herself, who will read and maintain the program rather than the
computer.
o Rule of Separation - Developers should separate the mechanisms of
the programs from the policies of the programs; one method is to
divide a program into a front-end interface and back-end engine
that interface communicates with.
O'Connell Expires January 2, 2016 [Page 2]
Internet-Draft D-BRIEF July 2015
o Rule of Simplicity - Developers should design for simplicity by
looking for ways to break up program systems into small,
straightforward cooperating pieces.
o Rule of Parsimony - Developers should avoid writing big programs.
o Rule of Economy - Developers should value developer time over
machine time, because machine cycles as of the year 2014 are
relatively inexpensive compared to prices in the 1970s.
The Policy Engine is assembled using parts of the Policy Code in an
ordered and controlled environment. Meta-Functions should be
implemented in order to traverse, invoke, or destroy current tasks.
1.1.3. Hierarchical Structure
O'Connell Expires January 2, 2016 [Page 3]
Internet-Draft D-BRIEF July 2015
The business rules are stored in a hierarchical structure as detailed
below
+------+
| ROOT |
+---+--+
| +-----------+---------------------+-------------------+
+----> VARIABLES | LIBRARY DEFINITIONS | XPATH CONSTRAINTS |
| +-----------+---------------------+-------------------+
| +---------+
+----> OBJECTS |
+----+----+
| +--------+
+------> EVENTS |
+----+---+
| +------------+
+-----> ACTIVITIES <-----------------+
+------+-----+ |
| +--------+ |
| | LINE 1 | |
+-------> LINE 2 | |
| | LINE n | |
| +--------+ |
| +------------+ |
+-------> ACTIVITIES +--+
| +------------+ |
| XXXXXX |
| XX XX |
+------>XXX BRANCH XXX+-+
| XX XX
| XXXXXX
| +---------+
+-------> FINALLY |
+---------+
Figure 1
o Variables - Declared global variables which must be instantiated
for each policy engine instance
o Library Definitions - A series of library imports with defined
prefixes
o XPath Constraints - A collection of XPath queries with the
required minimum count, maximum count, minimum length, maximum
length, regular expression match, and description fields.
O'Connell Expires January 2, 2016 [Page 4]
Internet-Draft D-BRIEF July 2015
o Objects - A abstract base set of object names for example
'Domain', or 'Contact'
o Events - The abstract base object event to be invoked for example
'Create', or 'Update'
o Activities - A series of activities to perform in order of
appearance
o Line 1, Line 2, Line n - Lines of code either by library
invocation or direct code
o Child Activities - Nested child activities to perform, for
semantic value only
o Branch - A branch in order to separate logical program flow
o Finally - A block of activities to perform even in the event of an
exception in the previous activities, used for cleaning up or
handling an error in a 'clean' mechanism
1.2. implementation
Conversion and implementation can begin as soon as a formalised
policy document has been released. The document should outline a
clear process to adhere to when performing a routine. Bullet point
based procedures are the easiest to implement on condition each
bullet point defines a single task to perform. Each bullet point
should be able to be converted into usable machine code known as
Policy Code. The Policy Engine can begin construction once the
textual elements have been converted to Policy Code.
Appendix A. Acknowledgements
(In no particular order)
o Ed Pascoe
o David Peall
o Vlad Dinculescu
o Theo Kramer
O'Connell Expires January 2, 2016 [Page 5]
Internet-Draft D-BRIEF July 2015
Appendix B. EPP Registry Example
A sample policy XML file built by a specialised user interface
mygtld
[]
[]
[]
5 days
5 days
5 days
5 days
5 days
PolicyExec.checkPermission(request, clID, objectname, eventname)
PolicyExec.domain_isAvailable(request)
PolicyExec.domain_mandatoryValues(request)
PolicyExec.validation(request)
O'Connell Expires January 2, 2016 [Page 6]
Internet-Draft D-BRIEF July 2015
PolicyExec.checkBannedList(request.find(fns("{domain}name")).text,
banned_domain_list)
PolicyExec.host_inbailiwickCheck(request)
PolicyExec.domain_nameserverCheck(request)
PolicyExec.contact_adjustState(clID, "Linked")
PolicyExec.startTimer(request, "Domain",
"GracePeriod", \GracePeriod)
PolicyExec.domain_statusCheck(request, ["Active",
"Ok"])
PolicyExec.checkPermission(request, clID, objectname, eventname)
PolicyExec.domain_exists(request)
PolicyExec.domain_dependencyCheck(request)
PolicyExec.startTimer(request, "Domain",
"PendingRelease", PendingReleasePeriod)
PolicyExec.startTimer(request, "Domain",
"PendingTermination", PendingTerminationPeriod)
O'Connell Expires January 2, 2016 [Page 7]
Internet-Draft D-BRIEF July 2015
PolicyExec.domain_statusCheck(request, ["Active",
"Ok"])
PolicyExec.checkPermission(request, clID, objectname, eventname)
PolicyExec.domain_exists(request)
PolicyExec.domain_mandatoryValues(request)
PolicyExec.validation(request)
PolicyExec.host_inbailiwickCheck(request)
PolicyExec.domain_nameserverCheck(request)
PolicyExec.startTimer(request, "Domain",
"PendingUpdate", PendingUpdatePeriod)
PolicyExec.domain_statusCheck(request, ["Active",
"Ok"])
PolicyExec.checkPermission(request, clID, objectname, eventname)
PolicyExec.domain_exists(request)
PolicyExec.domain_isInGracePeriod(request)
PolicyExec.domain_mandatoryValues(request)
O'Connell Expires January 2, 2016 [Page 8]
Internet-Draft D-BRIEF July 2015
PolicyExec.validation(request)
PolicyExec.startTimer(request, "Domain",
"PendingTransferUpdate", \PendingTransferUpdatePeriod)
PolicyExec.domain_startTransfer(request, clID)
PolicyExec.domain_adjustState(request, "Active")
PolicyExec.domain_adjustState(request, "Active")
PolicyExec.domain_adjustState(request, "Active")
PolicyExec.checkPermission(request, clID, objectname, eventname)
PolicyExec.contact_isAvailable(request)
PolicyExec.contact_mandatoryValues(request)
PolicyExec.validation(request)
PolicyExec.checkBannedList(request, banned_contact_list)
O'Connell Expires January 2, 2016 [Page 9]
Internet-Draft D-BRIEF July 2015
PolicyExec.contact_adjustState(clID, "Ok")
PolicyExec.contact_statusCheck(request, ["Ok"])
PolicyExec.checkPermission(request, clID, objectname, eventname)
PolicyExec.contact_exists(request)
PolicyExec.contact_dependencyCheck(request)
PolicyExec.contact_adjustState(clID, "Deleted")
PolicyExec.contact_statusCheck(request, ["Ok"])
PolicyExec.checkPermission(request, clID, objectname, eventname)
PolicyExec.contact_exists(request)
PolicyExec.contact_mandatoryValues(request)
PolicyExec.validation(request)
PolicyExec.checkPermission(request, clID, objectname, eventname)
O'Connell Expires January 2, 2016 [Page 10]
Internet-Draft D-BRIEF July 2015
PolicyExec.host_isAvailable(request)
PolicyExec.host_mandatoryValues(request)
PolicyExec.validation(request)
PolicyExec.checkBannedList(request, banned_host_list)
PolicyExec.host_inbailiwickCheck(request)
PolicyExec.domain_nameserverCheck(request)
PolicyExec.contact_adjustState(clID, "Linked")
PolicyExec.checkPermission(request, clID, objectname, eventname)
PolicyExec.host_exists(request)
PolicyExec.host_dependencyCheck(request)
PolicyExec.checkPermission(request, clID, objectname, eventname)
PolicyExec.host_exists(request)
PolicyExec.host_mandatoryValues(request)
PolicyExec.validation(request)
O'Connell Expires January 2, 2016 [Page 11]
Internet-Draft D-BRIEF July 2015
PolicyExec.host_inbailiwickCheck(request)
PolicyExec.domain_nameserverCheck(request)
The above is an example of an EPP Registry Implementation, note the
use of the Library Prefix as defined in the libraries section
Appendix C. XML Schema
O'Connell Expires January 2, 2016 [Page 12]
Internet-Draft D-BRIEF July 2015
O'Connell Expires January 2, 2016 [Page 13]
Internet-Draft D-BRIEF July 2015
Author's Address
Michael J O'Connell
Domain Name Services (Pty) Ltd
COZA House
Gazelle Close, Corporate Park South
Midrand, Gauteng 1685
ZA
Phone: +27 11 568 2812
Email: mike@dnservices.co.za
URI: http://dns.net.za/
O'Connell Expires January 2, 2016 [Page 14]