t service creation of the DGs. 6.5 YANG SERVICE MODEL EXAMPLE The service model generally describes the high-level data items for a service along with the business functions that support the instantiation and lifecycle management of the service. Consequently, the main data items in a service model are the remote procedure calls (RPCs) that make up the northbound inter- face (NBI), along with the input and output data items for those RPCs. A typical service will have a cre- ate, update, and delete RPC method with the corresponding "customer orderable" data as input. While the service model simply captures the abstract view of the requested service, other models will assign, calculate, or engineer resources at the network and device layers to implement the requested service. The service model RPCs also handle the lifecycle management interface for modify and delete, however, the network service model does not specifically assign or release resources. The network model provides the mapping that addresses the assignment or release of resources, and when net- work state change should occur. This is important because a particular RPC message may only affect the database inventory and not affect state in the network or it may affect both. In the example service model below for a simple VPN service definition, there is an RPC for "create-vpn" that assigns a vpn identifier. It is not shown in the example, but there would be a separate RPC to actually "attach" a preexisting access connection to that VPN. Multiple calls to the "attach" RPC would be called to create the VPN due to two access connections. For the "create- vpn" request, the input is a custID, vpnName, and topology and the output is simply a vpnId that will be used in subsequent messages. The service model is complete when all the inputs needed for the network model to apply engi- neering rules, assign resources, and drive the set of business process RPC (create, update, delete) are satisfied. The service model is generally both network and device agnostic but 