Which of the following is responsible for the global coordination of the domain name system?

IANA and RIR

Starting at the top is IANA. According to their website they are “…responsible for the global coordination of the DNS Root, IP addressing and other Internet protocol resources.” What this means to the investigator is that they manage and assign the top level domains, that is, .com, org, mil, edu. (see Table 3.6 for additional examples) and coordinate the IP addresses and their allocation to the RIR. IANA established the RIR to allocate IP address in geographical regions.

The RIR system evolved over time, eventually dividing the world into the following five regions:

African Network Information Centre (AfriNIC) for Africa, http://www.afrinic.net/

American Registry for Internet Numbers (ARIN) for the United States, Canada, several parts of the Caribbean region, and Antarctica, https://www.arin.net/

Asia-Pacific Network Information Centre (APNIC) for Asia, Australia, New Zealand, and neighboring countries, http://www.apnic.net/

Latin America and Caribbean Network Information Centre (LACNIC) for Latin America and parts of the Caribbean region, http://www.lacnic.net/en/web/lacnic/inicio

Réseaux IP Européens Network Coordination Centre (RIPE NCC) for Europe, Russia, http://http://www.ripe.net/

Each site has a search “Whois” function that allows the investigator to identify IP registration information. IANA and the RIR are the official registrars and owners of the domain records and IP addresses. An investigator wishing to verify the owner of an IP can use the RIR to locate the records.

2.6.1.3 The Regional Internet Registries

Five Regional Internet Registries (RIR) are responsible for the allocation and registration of Internet numbers. These are outlined in Table 2.7.

Table 2.7. The Five Regional Internet Registries

IANA assigns Internet numbers to the RIR in huge blocks of millions of addresses. Each IRIR then has the freedom to allocate those addresses based on their own policies. Sometimes addresses are allocated directly to the end-users, but usually they are allocated further to Local Internet Registries (LIRs) that are typically ISPs who then normally assign parts of their allocations to their customers. Virtual ISPs (vISPs) are customers of the bigger ISPs who purchase allocations and infrastructure from the larger ISPs and resell them to the general public. Corporations that have been assigned blocks of IPs in this way can, of course (at least technically), divide the block and do with it what they want, including reselling it to someone else.

According to the IANA policies, each RIR and LIR should make registration information available via WHOIS or RWHOIS services. The WHOIS database should contain IP addresses, Autonomous System (AS) numbers, organizations or customers that are associated with these resources, and related points of contact (POC). However, although IANA does what it can to exert influence on those groups to comply with this regulation, many of them simply don't, with the result that it's often very difficult to obtain accurate and current information regarding IP address allocations and assignments.

The Regional Internet Registries

Five Regional Internet Registries (RIRs) are responsible for the allocation and registration of internet numbers. These are outlined in Table 2.7.

Table 2.7. The Five Regional Internet Registries

IANA assigns Internet numbers to the RIRs in huge blocks of millions of addresses. Each IRIR then has the freedom to allocate those addresses based on their own policies. Sometimes addresses are allocated directly to the end-users, but usually they are allocated further to Local Internet Registries (LIRs) that are typically ISPs who then normally assign parts of their allocations to their customers. Virtual ISPs (vISPs) are customers of the bigger ISPs who purchase allocations and infrastructure from the larger ISPs and resell it to the general public. Corporations that have been assigned blocks of IPs in this way can, of course (at least technically), divide the block and do with it what they want, including reselling it to someone else.

According to the IANA policies, each RIR and LIR should make registration information available via WHOIS or RWHOIS services. The WHOIS database should contain IP addresses, Autonomous System (AS) numbers, organizations or customers that are associated with these resources, and related points of contact (POCs). However, although IANA does what it can to exert influence on those groups to comply with this regulation, many of them simply don’t, with the result that it’s often very difficult to obtain accurate and current information regarding IP address allocations and assignments.

IP Address Assignment

Most people get IP addresses from their ISP. But where do ISPs get their IP addresses? Large organizations can still apply for their own IP addresses independent from any ISP. To whom do they apply?

IP addresses (and the Internet domain names associated with them) were initially handed out by the Internet Assigned Number Authority (IANA). Today the Internet Corporation for Assigned Names and Numbers (ICANN), an international nonprofit organization, oversees the process of assigning IP addresses.

Actual IP addresses are handed out by the following Regional Internet Registries (RIRs):

ARIN (American Registry for Internet Numbers) at www.arin.net—ARIN has handed out IP addresses for North and South America, the Caribbean, and Africa below the Sahara since 1997.

RIPE NCC (Reseaux IP European Network Coordination Center) at www.ripe.net—RIPE assigns IP addresses in Europe and surrounding areas.

APNIC (Asian Pacific Network Information Center) at www.apnic.net—APNIC assigns IP addresses in 62 countries and regions in Central Asia, Southeast Asia, Indochina, and Oceania.

LACNIC (Latin American and Caribbean Network Information Center) at www.lacnic.net—LACNIC assigns IP addresses from ARIN in 38 countries, including Mexico.

AfriNIC (African Network Information Center) at www.afrinic.net—AfriNIC took over assignment of African IP addresses from ARIN.

All of these Internet Registries databases (who has what IP address space?) combined are known as the Internet Routing Registry (IRR). Internet domain names comprise a related activity, but (like IP addresses) names must be globally unique and (unlike IP addresses) can be almost anything.

For the latest information on IP address assignment, which is always subject to change, see www.icann.org.

When it comes to IPv6, in particular, IANA still hands out addresses to the registries, which pass them along to IPv6 ISPs, who allocate IPv6 addresses to their customers. The current policy is given at www.arin.net/policy. An older policy is used in this chapter (see www.arin.net/policy/ipv6_policy.html) and uses these prefixes at each step of the process:

2001::/16 is reserved for IANA.

IANA hands out a /23 prefix to each registry.

Registry hands out a /32 or shorter prefix to an IPv6 ISP.

ISP allocates a /48 prefix for each customer site.

Local administrators add 16 bits for each LAN on their network, for a /64 prefix.

This scheme is shown in Figure 5.8. When the LAN is included, most IPv6 addresses have /64 network masks. This is the prefix length used on the Illustrated Network. IPv6 routers can perform the following tasks:

Route traffic to a particular ISP based on the first 32 bits of the IPv6 destination address.

Route traffic to a particular site based on the first 48 bits of the IPv6 destination address.

Route traffic to a particular LAN based on the first 64 bits of the IPv6 destination address.

In practice, IPv6 core routers can look at (and build forwarding tables based on) /32 or shorter prefixes, routers inside a particular AS (routing domain) can look at /48 prefixes, and site routers on the customer edge can look at /64 prefixes to get traffic right to the destination LAN.

Now we can better understand the IPv6 address assigned to CE0 that we saw at the beginning of the chapter:

fc00:ffb3:d5:b:205:85ff:fe88:ccdb

or

FC00:FFB3:00D5:000B:0205:75FF:FE88:CCDB

Let’s break it down one element at a time and see where it all comes from:

Registry—We use FC00 instead of 2001 to indicate a private ULA-local IPv6 address.

ISP—We add Best ISP’s AS number of 65531 (0xFFB3) for LAN 1 or Ace ISP’s AS number 65527 (0xFE67) for LAN2.

Site—We add telephony area code 213 (0x00D5) for the Los Angeles or 212 (0x00D4) for New York sites. (We could always use more of the phone number, but this is enough.)

LAN—We add 11 (0x000B) for LAN1 or 12 (0x000 C) for LAN 2. These are borrowed from the IPv4 addresses.

EUI-64—We add 0x0205 85FF FE88 CCDB for the hardware MAC address.

The mask is /64, naturally. Keep in mind that in the real world, none of this complex coding would be done.

Whois

Whois is a tool used to query the globally distributed set of databases that contain the information regarding domain names around the world. The databases contain information regarding when the domain was registered or last updated, which registrar it was registered with, contact information for the owners of the domain, and the name servers that are used to resolve requests sent to the domain name. We can see part of the reply from a basic whois query in Figure 6.1. One of the more interesting items of information displayed here is the nameserver to which the domain name is directed, which will lead us to additional information in the next section.

The information displayed in Figure 6.1 is the result of a command line whois query, a tool often found in Linux and Unix operating systems, but not so common in others, such as those distributed by Microsoft. We can also run such queries through a variety of web pages dedicated to such purposes, one of the more common being whois.net.

In some cases, the contact information found in the data returned from whois queries will contain a great deal of useful information, such as a physical address, phone number, and contact name from someone directly associated with the domain. Such information can be used as the basis for conducting searches for additional information when researching a target. In recent years, however, it has become more common for domains to be registered through a service that acts as a proxy for domain contact information, thus hiding the actual contact information for those associated with the domain.

In addition to conducting whois queries on domain names, we can also run queries on IP addresses. The information from these queries is returned from the databases maintained by the Regional Internet Registries (RIR), who keep track of IP address assignments for their particular regions. The RIRs are distributed as follows:

North America and some of the surrounding regions—American Registry for Internet Numbers (ARIN).

Europe, the Middle East, and some of Asia—Réseaux IP Européens Network Coordination Centre (RIPE NCC).

Asia Pacific—Asia Pacific Network Information Centre (APNIC).

Latin America and the Caribbean—Latin American and Caribbean Internet Address Registry (LACNIC).

Africa—AfriNIC.

Shown in Figure 6.2 are some of the results of an IP address query against an IP controlled by ARIN.

We can also conduct such queries based on information other than an IP address, such as a point of contact or an organization name.

13.1.6 Storing an IPv6 Address in SQL

The original designers of TCP/IP defined an IP address as a 32-bit number. The Internet Assigned Numbers Authority (IANA) manages the IP address space allocations globally. IANA works in cooperation with five Regional Internet Registries (RIRs) to allocate IP address blocks to Local Internet Registries (Internet service providers) and other entities.

The IP version 6 addresses are huge compared to IPv4 and are not likely to run out anytime soon. The problem is that it is a redesign of the Internet Protocol and not a simple extension. The address size was increased from 32 to 128 bits (16 bytes). The new design is so large that subnet routing prefixes are easy to construct without any kludges. Large blocks can be assigned for efficient routing. Windows Vista, Apple Computer’s Mac OS X, Linux distributions, and most other operating systems include native support for the IPv6 protocol.

9.12.3 Resource Public Key Infrastructure (RPKI) Architecture

Resource Public Key Infrastructure (RPKI) architecture [492] is a recent approach to secure BGP. While S-BGP and So-BGP tried to address BGP vulnerabilities, these schemes have heavy overhead in terms of deployment resulting in reluctance in acceptance.

RPKI addresses one of the most fundamental problems that BGP does not directly address. The BGP operation assumes that an AS that originates an IP prefix has the authority to do so; i.e., BGP is based on this key presumption. On the other hand, there have been a number of instances in the past two decades where this presumption has been exploited intentionally or unintentionally, known as IP prefix hijacking; see Section 10.8 for details. This causes a severe impact on the routing capabilities of the Internet while many sites becoming unreachable as well. Thus, the basic premise of RPKI is to address the fundamental issue of associating an IP prefix with an original AS reliably in order to prevent IP prefix hijacking and prevent mi-origination.

Briefly, RPKI allows to verify whether an AS is authorized to announce a specific IP prefix. In order to do so, digital certificates are attached to IP prefix and the AS number. Due to existing IETF standards, X.509 certificate extensions for IP prefixes and AS numbers, which is defined in RFC 3779 [520], are relied on. RPKI has three key components: trust anchors (TAs), Route Origination Authorizations (ROA), and validators.

Trust anchors in an X.509 architecture require one to be the root trust anchor holding the root certificate; the others' trusts are derived based on the root. In RPKI, the Internet Assigned Number Authority (IANA) acts as the trust anchor, while Regional Internet Registries (RIRs) (see Section 10.3 for details on RIRs) are the next level in trust anchors. Each RIR holds a self-signed root certificate for IP addresses and AS numbers it is designated to handle. Since an RIR can, in turn, delegate addresses spaces to National Internet Registries (NIRs) or Local Internet Registries (LIRs); the certificate hierarchy for RPKI is similarly followed. These entities serve as Certification Authorities (CA) and issues certificates to customers. CA certificates attest the IP address and the AS number. CAs can also issue End-entity (EE) certificates if they wish to delegate the authority.

Route Origination Authorizations (ROAs) are document objects that associate one or more IP prefixes with an origin AS number. That is, an ROA contains Origin ASN, IP prefixes (with minimum and maximum prefix lengths) along with an expiry date. It may be noted that multiple ROAs may include the same IP prefix. Operationally, ROAs are originated by the AS number that has an IP prefix block. CAs publish the ROA records.

A BGP speaker obtains ROA information from the RPKI cache (“validators”) for validation. This step is done out-of-band from the normal BGP protocol operation and is accomplished using RPKI-to-router protocol described in RFC6810 [132]. That is, if an AS hears about a new IP prefix through an announcement from its AS neighbor through a normal BGP update, it can first consult a Validator to check if the IP prefix is valid as well as its AS origin. Once this is established, the BGP speaker then forwards the IP prefix to its other neighboring ASes, who, in turn, can follow the same procedure for validation.

An important point to note about RPKI is that it provides authorization, but not authentication. This is where RPKI differ from most PKIs, and the issuers in RPKI avoids the costs and liabilities of verification. In turn, this allows the issuers to take the role of CAs. Also, in the RPKI architecture, each Relying Party (RP), such as an LIR or an ISP, could potentially create a trust anchor. Then the RP could be responsible for issuing certificates. The relation of the RP with NIRs and LIRs and to the RPKI-router protocol is shown in Figure 9.16.

Finally, in Figure 9.17, we show the relation of CAs through RIRs/NIRs, and ISPs with ROAs. This example also shows an ISP with allocation from two sources, an RIR and an NRI; in this case, it requires two CA certificates, following the rules described in RFC 3779.

10.3 Allocation of IP Prefixes and AS Numbers

So far, we have discussed AS numbering, IP addressing, customer and provider relationships, and so on. An important question remains: how does an organization obtain an IP address block? In this section, we answer this question.

Internet Corporation for Assigned Names and Numbers (ICANN) is the governing body that handles the global coordination of unique identifiers used in the Internet. More specifically, the Internet Assigned Numbers Authority (IANA) is a unit of ICANN that is in charge of handling the IP address space and the AS number space. Through agreements, IP address block assignments have been distributed to five different Regional Internet Registries (RIRs). The five RIRs are geographically organized as follows:

American Registry for Internet Numbers (ARIN) (http://www.arin.net/) to serve the North American region

RIPE (Réseaux IP Européens) Network Coordination Centre (http://www.ripe.net/) to serve the European and the West Asian region

Asia Pacific Network Information Centre (APNIC) (http://www.apnic.net/) to serve the South/East Asian and the Pacific region

Latin American and Caribbean Internet Address Registry (LACNIC) (http://www.lacnic.net/) to serve the Latin and South American region

African Network Information Center (AfriNIC) (http://www.afrinic.net/) to serve the African region.

Each RIR can distribute its allocated address space to National Internet Registries (NIRs) for addresses that fall within its address space. RIRs such as APNIC and LACNIC delegate their address blocks to NIRs. There is another set of registries known as the Local Internet Registries (LIRs). An LIR can obtain its address blocks from an RIR, and are in-charge of distributing them to organizations locally. An LIR can also request address space from an RIR on behalf of an end-user organization. Note that an ISP can be an LIR. Similarly, an academic institution or an enterprise can be an LIR.

Each registry has its own rules and pricing in regard to IP address block allocation; this allocation depends on allocation size as well, as indicated through a netmask boundary such as /19. For example, ARIN's current policy is that the minimum allocation size is a /20 while for multihomed organizations, the minimum allocation size is a /22. This means that if an organization needs only a /24 allocation, it cannot obtain it directly from ARIN; instead, it must obtain it from an upstream ISP (provider) who has already been allocated at least a /20 address block by ARIN. Similarly, registries put restrictions on allocations of an AS number. For example, currently ARIN would allocate an AS number to an organization only if it plans to do multihomed connectivity to two ISPs, or can justify that it has a unique routing policy requirement. Note that allocation polices, both for IP prefixes and AS numbers, do change from time to time. For recent polices, you may check the website of the respective registries listed above.

Suppose that an organization obtains an IP address block along with an AS number from ARIN. It would then need to establish multihomed connectivity to two upstream ISPs who would have their respective AS numbers. Once the physical connectivity is set up, the BGP speaker at the organization establishes a BGP session with the BGP speakers of its upstream ISPs to announce its address blocks. This information is then propagated throughput the Internet so that the rest of the Internet knows how to reach a host in this address block. Note that the organization may have separate BGP speakers, one each for connecting to its upstream ISPs; in this case, the organization would need to run iBGP between its two BGP speakers so as to establish rules on how to handle routing of outgoing traffic.

Now suppose that an organization obtains an IP prefix from one of the regional Internet registries, but does not obtain an AS number. In this case, at first it would need to set up an agreement with an ISP that has an AS number; this ISP would then serve as the “home” AS for this address block. Once connectivity and agreements are put in place, this ISP would then announce this IP prefix along with other IP prefixes that are in its AS to its upstream provider(s). Once this announcement is propagated throughout the Internet, the newly announced IP prefix becomes known to the rest of the Internet. We discuss below two possibilities of how the connectivity between an organization (customer) and its provider can be set up when a customer does not own a public AS number:

The ISP may set up private AS numbering to divide its customers into different ASes. Thus, each customer (organization) has the flexibility to choose a routing protocol of its choice internally, and then use a BGP session to talk to the provider's BGP and announce its IP prefixes.

If the provider uses OSPF protocol, then it can use Not-so-stubby Areas (NSSA) LSA (refer to Section 6.2.8) to allow external routes from its customer to be advertised into the OSPF autonomous system, while the customer may run its own routing protocol.

Choosing one over another or using any other mechanisms depends on the size of an ISP, as well as its internal network management philosophy and policy, and its business strategy. Furthermore, note that route redistribution (refer to Section 5.7) is a common mechanism to exchange prefixes among different administrative organizations that fall within an AS number.

It may be noted that a customer who obtains an IP address block from a provider may choose to switch to a different provider after sometime, yet keep the address block. Suppose that a provider has the address block 192.168.40.0/21, and it has allocated 192.168.45.0/24 to a customer. Initially, through route aggregation the provider will announce 192.168.40.0/21 with its AS number. Now the customer wants to move to a different provider keeping the address block. Thus, the address block, 192.168.45.0/24, would now need to be announced with the AS number of the new provider. This then creates a situation, known as a hole since the more-specific prefix (192.168.45.0/24) creates a hole in the aggregated prefix (192.168.40.0/21). However, both the aggregated prefix and the more-specific prefix would need to reside in the global routing table at a BGP speaker; this is so that packets can be forwarded properly to the right destination. This means that the IP address lookup process at a router needs to work very efficiently, handling holes as well. Details on IP address lookup algorithms are covered in Chapter 14.

Domain name registration

So, how does one get a domain registered in the name of their choice? Today it is fairly simple to do. One of hundreds of domain registrars are available on the Internet. A simple search of the term “domain registrar” on Google will bring up hundreds of results, such as d1.com, GoDaddy.com, Network solutions, and many others. With each of these a credit card number and the basic name and address information gets you the domain of your choice (that is if the domain you select is available). The registration of a domain name is for specified period of time from generally 1 year or more. The domain registrar submits the names to the Internet Corporation for Assigned Names and Numbers (ICANN) who is responsible for the actual assignment of Internet addresses. The investigator should be aware that any or all of this information can be falsified by the person registering a domain.

ICANN is a nonprofit organization formed under the direction of the US Department of Commerce in 1998 (ICANN 1998) to administer the domain name registration process and the DNS. ICANN has since entered into agreements with other authorities designed to assist in domain registrations for various areas around the world. The following are the five regional Internet registry (RIR) service regions:

RIPE, the Europeans IP Networks

AFRINIC, the African Internet Numbers Registry

APNIC, the Asia Pacific Network Information Center

ARIN, the American Registry for Internet Numbers

LACNIC, the Latin American and Caribbean Internet Addresses Registry.

In 2000, ICANN entered into another agreement with the US Government to operate the Internet Assigned Numbers Authority (IANA). At the time, the University of Southern California had been operating the functions of the IANA through a contract with the DARPA (Figure 3.15).

12.2.3 Related work

In Ref. [8], Almeida et al. present the most recent discussion on IoT governance. In this paper, the authors observe that the privacy and data protection measures that are often instituted are dependent on the function and scale of the data gathering mechanisms. For instance, when automated data processing became feasible due to the introduction of the Internet, many of the existing privacy legislations became necessary. Although the introduction of Internet and cloud-based back ends enable the automation of data analysis, IoT can bring in automated data capture. If proper safeguards are not put in, people can be subjected to massive automated surveillance as they go about doing their day-to-day activities. The paper argues the adoption of four principles for data protection: (1) notice and choice, (2) data minimization, (3) access to personal data, and (4) accountability. Notice and choice is a popular approach to address the data collection concerns in many Internet-centric systems (eg, online social networks). Implementing this idea on IoT might be challenging due to user interface restrictions and the shear number of devices and services one would encounter with IoT. Access to personal data mandates that the end user has the right to access the data that were collected on him/her. Many online portals are beginning to implement some form of this principle to address the mounting privacy concerns. In IoT, the volume of data could be so huge that merely having access to the collected data might not be very helpful.

The paper also notes that IoT governance could be an extension of the Internet governance which is already very well developed. Some issues such as standardization, interoperability, security, and privacy could leverage the frameworks that are already in place for Internet governance. Certain aspects of IoT governance such as multistakeholder involvement might need extensions of the existing frameworks.

In Ref. [6], Almeida et al. examine multistakeholder model and their connection to Internet governance. This paper defines stakeholders as individuals or groups who have interest in a particular decision because they can influence it or can be affected by it. The MSM described in the paper has five major components: goals, participants, scope, timelines, and connection to decision makers. The cooperation elicited by a successful MSM among its participants can yield a system that is not achievable by a single stakeholder. The Internet brings together diverse participants: governments, technical community, civil society, and private sector. An MSM can have stakeholders that operate at different scopes. For example, the Internet can have international organizations such as ICANN and regional organizations such as Regional Internet Registries. The MSM can be connected to the decision makers in two different ways: on a purely informational basis or developing best practices. When MSM is engaging with the decision makers in a purely information manner, the decision makers are not compelled to take the ideas of MSM into consideration. On the other hand, by generating best practices, the MSM can exert some pressure on the decision makers to follow the set guidelines.

One of the key activities in MSM bodies is consensus building. The process of consensus building is often very difficult and messy. The different stakeholders will arrive at an agreement only if their viewpoints or grievances are reasonably accommodated in the final decision. An agreement of the stakeholders indicates their willingness to accept and implement the final decision.

The paper identifies many research issues that should addressed for designing and implementing successful MSM bodies: (1) identifying the right set of stakeholders to participate in a particular decision-making process, (2) the mechanisms for selecting participants for the different groups, (3) inclusion of crowdsourcing in the MSM dialog, (4) technologies for the representative to stay connected to their constituencies, (5) technology support for achieving and accelerating consensus in MSM bodies, and (6) theoretical models for consensus development in MSM bodies.

In Ref. [9], Weber discusses IoT governance problem in depth. It starts off with a discussion of EC sponsored user study [7] on IoT. It then describes some IoT-specific issues by comparing IoT governance to Internet governance. Two major issues are identified in Ref. [9]: naming differences and issues requiring regulatory frameworks. In the Internet, domain names are used whereas object names such as RFID tags are used in IoT networks. Governing the object name space so that it would provide an interoperable facility for naming and discovering smart objects is an important problem. As issues requiring regulatory frameworks, the paper discusses privacy, security, ethics, and standardization of IoT architecture. Continuing further, the paper identifies important pillars of IoT governance. One of the ideas heavily discussed is the idea of setting up a regulator for IoT along the lines of existing ones for trade (World Trade Organization). The paper posits that it is still premature to float this idea and does not envision it to be a viable approach in the near future. Although setting up a regulator is deemed infeasible, the paper is favorable for regulation. It goes into a discussion of what would be the best approach to regulation: top-down or bottom-up. Another interesting idea floated in the paper is open mechanisms for coordination. The paper is of the opinion that depending on the underlying social structure we should adopt different coordination mechanisms to achieve an efficient regulatory mechanism.

The paper identifies the following set of substantive principles for IoT governance as part of exposition of the topic: (1) legitimacy and representation, (2) transparency, (3) accountability, and (4) IoT infrastructure governance. Everyone in a society could be affected by the way IoT is managed. Therefore, it is important that everyone has an opportunity to influence the IoT governance. Like the idea of transparency in the Internet, the IoT transparency involves the ability to identify the elements of the management structure, information pertaining to management, and the right to access information. Accountability is an important substantive principle which dictates that the governing body should be held responsible for its actions. For instance, governing regimes could be subject to sanctions for irregular practices.

A cloud-based management framework called GovOps (Governance and Operations) is presented in Ref. [23] for IoT. The objective of GovOps is to make operational governance of IoT cloud systems easier by seamlessly integrating the governance objectives into IoT cloud operation processes. Instead of defining a new methodology for governing IoT, GovOps attempts to obtain high efficiencies in the overall IoT cloud management by providing a facility to integrate governance policies into operation processes. Two example applications used in the paper are building automation systems (BASs) and fleet management systems (FMS). In both applications, we can have variety of different stakeholders: end users, managers, and government policy makers. The paper identifies three forms of governance: environment-centric, data-centric, and infrastructure-centric. In a BAS environment, residents, building managers, and regulatory policy makers (government) are concerned about governing the environment created within and outside the buildings. In data-centric governance, measures for securing data and enforcing privacy requirements are carried out. Infrastructure-centric governance focuses on issues related to installing, configuring, and deploying IoT cloud systems.

One of the example governance objectives used to illustrate GovOps is implementing the legal requirements with respect to sensory data in BAS or FMS environments. The corresponding operation process would be spinning up a secure aggregator gateway in the cloud for sensor data stream and setting it up properly. Another important component of the GovOps is the GovOps manager. It is a dedicated manager that is responsible for bridging the gap between the governance strategies and the operations processes.

An implementation of the GovOps concept presented in Ref. [23] is given in Ref. [24] and referred to as the runtime framework for GovOps (rtGovOps). It provides the first known large scale implementation of a governance framework. Following the philosophy of GovOps, the purpose of their framework is not to evolve the management policies, but to implement a given governance policy across a large cloud-based IoT system. An experiment involving an FMS was carried out in Ref. [24], where golf carts were controlled using a cloud-based rtGovOps framework. One of the experiments demonstrated in the paper was to switch the golf cart management from normal mode to emergency mode. The authors claim that without their rtGovOps framework such a switch is cumbersome particularly for a large fleet of golf carts. With the rtGovOps framework, golf cart renting agency can easily manage the operation by setting the policies using a cloud interface.