Changes between Version 1 and Version 2 of ConceptualModels

Sep 21, 2010, 12:48:07 AM (7 years ago)



  • ConceptualModels

    v1 v2  
    1 This area is for discussion of the conceptual model to be used for the command tool and other possible interfaces. It will talk about the issues at a higher level and will have pages for more detailed discussions for the aspects.
     1This area is for discussion of the conceptual data model to be used for the command tool.
    3 == Extensibility and Modularity ==
     3 * "natural" objects and operations
    5 One of the primary goals of BIND 10 was to make it modular and extensible in ways that BIND 9 was not. It would only make sense to make sense that the same constraints me followed for the command tool. Since this is somewhat vague, this will attempt to be more explicit for what is meant by extensible and modular.
     5A management data model is only useful when it facilitates the work of the organization to accomplish their goals.I refer to the steps necessary to accomplish the goals as a set of operations on a set of objects. When the objects and operations fit the goals and processes well, I refer to them as a natural fit.
    7  * forklift modularity: the ability to replace defined sections of the command tool without recompiling.
     7The ideal is to find the balance between a model that is so specific to a single organization that is has no further use and a model that is so general as to provide no benefit.
    9 A simple one is that database access should be through an interface that allows the type of server and much of the schema details to be hidden from the upper levels.
     9 * looking for natural objects from the protocols
    11 A more complex model is for someone to change the auth local data generators with ones that have different functionality to match a different auth server module.
     11The natural objects of the DNS protocol are names (fully qualified) that are made up of labels (letters and numbers between dots), resource records which provide various types of information about a name and zone cuts, which provide all the navigation information to traverse the hierarchy to locate the name server for a given name.
    13  * functional APIs: allowing people to use components from the command tool to build their own tools
     13The natural objects of DHCP are machines/interfaces with mac addresses and address ranges which have options attached to them and leases for dynamically allocated addresses.
    15 An example of this is an API and library that understands how to connect and authenticate with a BIND 10 server.
     15== a cursory look at an object model ==
     17 * devices: things that are capable of communicating on an IP network
     18   * interfaces: the end points of IP communications
     19     * Primary address
     20     * secondary address
     21     * mac address
     22     * name(s)
     23     * options for dhcp
     24   * services: things this device provides for other devices
     25     * web
     26       * preferred interface
     27       * ports
     28       * virtual hosts
     29     * mail
     30       * namespaces considered local
     31       * namespaces considered a recipient for
     32       * priority for namespaces
     33     * name server
     34       * preferred interface
     35     * DHCP server
     36       * probably need linked TFTP servers
     37     * routing
     38 * namespaces
     39   * zone cuts (including apex)
     40     * name servers
     41     * control info
     42     * common zone info (* mx...)
     43   * delegations (where the namespace changes from local administrative control)
     44   * names (things that don't generate from other data)
     45     * class, type, data
     46     * linkages (certain names/types are connected to others and want to be controlled simultaneously)
     47 * addresses
     48   * subnets
     49     * prefix, broadcast
     50     * default PTR generator (fills in in-addr if there is no more specific info)
     51     * options
     52     * dhcp servers
     53   * direct ranges (addr-addr)
     54     * dhcp servers
     55     * lease control (often used for dynamic allocation)
     56     * forward and reverse generators
     57   * single addresses
     58     * (many built from device model)
     59 * rolls, accounts and change control
     60   * Role based access control (RBAC)
     61   * accounts get OR of all role permissions on login
     62   * hierarchical scoping of roles
     63 * attachments (metadata pieces that can be attached to other elements)
     64   * auditing info
     65     * time of last action
     66     * account for last action
     67     * append only audit mechanism
     68   * operational info
     69     * ticket, provisioning or other action trace mechanism
     70     * approval status and requirement
     71     * other linkage hooks (such as a whois pointer for a registry delegation)
     72   * back trace objects (opaque tags in lower level data to be traced back for source identification)
    18  * data extensibility
    20 There are two aspects to data extensibility. One relates to changes to the data managed in the server and the other relates to data in the command tool.
    22 If one looks at the server data extensibility, a good example I often use is a new wombat resource record that has 3 fields. Rather than having to replace the entire data generator and display systems to handle this, it would be far better to allow this kind of mechanism to be added to the command tool as an extension.
    24 Management side extensibility would be more involved with the higher level structures used to help people control their servers. Extensions for things like provisioning records or trouble tickets are simple examples of this.
    26  * capability extension
    28 The ability to add new functions to the command tool in an organized way is both challenging and powerful. There are many things that can be done in unique ways when connected to the servers directly and having added data from the management data model at hand.
    30 One example of this would be a validator to confirm that all the configuration around a zone delegation is correct, including the zone transfers. A different example would be the generating of custom reports that combined server and management data into something more useful to the organization.
    32 == Data abstraction above the protocol level ==
    34 The DNS specifications and data model are designed to simply and exactly define the transfer of data needed in many internet actions. This model does not reflect the way organizations think of the things that need DNS data related to it. One of the reasons that managing DNS environments is hard is that we require everyone to learn the protocol level data model and use a combination of user tools and mental translation to get from the data that the organizatoin has to the data that the server needs.
    36 To address this issue, we are proposing that there be a management data model that is different than the server data model. The server data model needs to provide the specific information needed to feed the DNS protocol and does not want to be burdened by either the complexity or variability of higher level models. This implies that there is a translation of higher level model constructs into the lower level structures needed by the server components. This is part of the management side.
    38 == Data vs. metadata ==
    40 If one says that data is the stuff that DNS provides to support actions by other programs wishing to communicate on the internet, some interesting things come about. All of the components related to zones and zone cuts are really protocol defined metadata for navigating a hierarchy of servers. The same can be said for all the information related to secure DNS.
    42 A second level of metadata is all the information that an organization has about things that translate into DNS data and metadata. Things like the fact that a series of A records are virtual hosts of a given machine and if the machine main address changes, all the virtual host addresses need to change as well. Another type of metadata is related to operations, so a given change was made by some person in response to some work request which is tracked elsewhere.
    44 == Management data models ==
    46 BIND 9 and DHCP 4 have very different management data models. BIND has a fixed set of data files, one per zone and a single config file (but supports includes.) There is no concept of generating data within the config, that all is expected to happen outside the server. DHCP has gone almost the exact opposite route, where there is no separate data files, and the server itself processes often complex generation tasks to reach a running internal state.
    48 Though some of this can be seen as the result of the differences in usage of the two systems, it also reflects different choices by the initial designers on how to approach the problem. It is not clear that either was designed from the needs of current customers.
    50 To build a management data model that can encompass the needs of both of these is a challenge, but others have done so with varying degrees of success. As this is explored, one must keep in mind that any management data model should be able to be replaced with another, as long as a companion translation to the low level data required by the server is also included.