This meant that the interfaces used to converse with a network element had to be preprogrammed rather than being learned on-the-fly. Second, the syntax of the languages
used to define the structure of messages and rules by which elements should handle
messages (i.e., read-only and read-write) are somewhat purpose-built for those man‐
agement interfaces. Third, these protocols often used binary encodings, meaning that
while they were compact on the wire, they were difficult to program, debug, and other‐
wise represent. Finally, the common practices around writing the syntactic modules
describing the schema of any one of these interfaces was often nonhierarchical, meaning
that it was difficult to navigate not only for applications, but also for humans trying to
find their way around the schema.
In most cases, an application that was allowed to have any sort of discourse with a
network element or its services was required to either communicate using one of these
protocols, or more commonly, had to communicate through a network management
element management system (EMS). The EMS acted as a proxy between the network
elements and the applications. Unfortunately, the EMS (or NMS) generally did not ex‐
pose the network elements or the services they provided in any sort of applicationfriendly way, meaning that coding toward these interfaces and paradigms was cumber‐
some and ultimately resulted in long periods of time between an application signaling
its desire to do something and that something actually happening. This is in fact what
we call the application-network divide, illustrated in Figure 5-1.