A few versions ago a subtle change was made to the SID and the Config concept was introduced and the RFS was marked as "discontinued"... Being someone who has talked about RFSs extensively many people have asked me to explain the difference between Config and RFS.
To understand what has happened and why you must remember that many low level elements in the network can work in different ways - a router can also act as a firewall or a bridge. Additionally a SIP Port can support multiple different types of numbers and services associated with that number.
The SID's RFS defines the service delivered after the configuration of the Logical Resource that provides the RFS has taken place. The RFS does not describe the process of how to configure that Logical Resource, RFS, or even the corresponding CFS that the RFS and other RFSs support.
To understand the role of Config consider something a lot simpler than a Logical Resource, RFS or CFS, a children's toy, Transformers "Optimus Prime". A single toy can have two configurations - Optimus Prime or a Hino Brandler Fire Engine/Truck. The RFS view of this would define the services delivered by the robot - as a Fire Engine it delivers a set of fire extinguishing services and as Optimus Prime it delivers leadership as Autobot Leader and fighting services. These are useful when defining or understanding the role of the robot in relationship to other Transformers and their role in Earth society.
So the RFS is a "steady state" representation where the services or functions have already been set up or configured and it can be used to describe the service elements being delivered or when something goes wrong the symptoms (eg lack of function or service) can easily be understood.
This view however doesn't tell us how to turn Optimus Prime from his Fire Engine form into his fighting robot form, which is not a problem for most 10 year olds, but for a CSP implementing a Customer Facing Service or Product this is where most of the effort is expended, the transformation of a low level service through the application of certain commands or settings, in other words, the provisioning and orchestration of components in the network.
As I explained in an earlier blog (The Problem with RFSs) some people thought that the RFS defined the provisioning being performed on the network to get a CFS to function. This isn't the role of the RFS and there wasn't anything in the SID that defined this - hence the recent introduction of Config.
Config Specification defines how to change any instance of the transformer robot into a fire engine or into Optimus Prime - which bits to twist and reposition. When the Config has been applied we tend to call the general purpose robot after the config it has just had applied - so we have "Optimus Prime" or "Fire Engine"
So in summary
Configspec = Allocate a port to a number / Turn an Optimus Prime into a Fire Engine
Config = Allocate port xyz to number 12345758 / Turn Andrew's Optimus Prime into Andrew's Fire Engine (be careful when twisting left leg, it is loose).
Instance as a Config spec = "build them like this one" / Look at Andrew's Optimus Prime as an example
To understand what has happened and why you must remember that many low level elements in the network can work in different ways - a router can also act as a firewall or a bridge. Additionally a SIP Port can support multiple different types of numbers and services associated with that number.
The SID's RFS defines the service delivered after the configuration of the Logical Resource that provides the RFS has taken place. The RFS does not describe the process of how to configure that Logical Resource, RFS, or even the corresponding CFS that the RFS and other RFSs support.
To understand the role of Config consider something a lot simpler than a Logical Resource, RFS or CFS, a children's toy, Transformers "Optimus Prime". A single toy can have two configurations - Optimus Prime or a Hino Brandler Fire Engine/Truck. The RFS view of this would define the services delivered by the robot - as a Fire Engine it delivers a set of fire extinguishing services and as Optimus Prime it delivers leadership as Autobot Leader and fighting services. These are useful when defining or understanding the role of the robot in relationship to other Transformers and their role in Earth society.
So the RFS is a "steady state" representation where the services or functions have already been set up or configured and it can be used to describe the service elements being delivered or when something goes wrong the symptoms (eg lack of function or service) can easily be understood.
This view however doesn't tell us how to turn Optimus Prime from his Fire Engine form into his fighting robot form, which is not a problem for most 10 year olds, but for a CSP implementing a Customer Facing Service or Product this is where most of the effort is expended, the transformation of a low level service through the application of certain commands or settings, in other words, the provisioning and orchestration of components in the network.
As I explained in an earlier blog (The Problem with RFSs) some people thought that the RFS defined the provisioning being performed on the network to get a CFS to function. This isn't the role of the RFS and there wasn't anything in the SID that defined this - hence the recent introduction of Config.
Config Specification defines how to change any instance of the transformer robot into a fire engine or into Optimus Prime - which bits to twist and reposition. When the Config has been applied we tend to call the general purpose robot after the config it has just had applied - so we have "Optimus Prime" or "Fire Engine"
So in summary
Configspec = Allocate a port to a number / Turn an Optimus Prime into a Fire Engine
Config = Allocate port xyz to number 12345758 / Turn Andrew's Optimus Prime into Andrew's Fire Engine (be careful when twisting left leg, it is loose).
Instance as a Config spec = "build them like this one" / Look at Andrew's Optimus Prime as an example
