Resource types that support explicit creation with a create action, can also support optional implementation data.

The edge server publishes implementation data in the feedback channel along with the object’s status object using the impl topic, and accepts implementation data with the implementation argument to the create method.  

IAP does not define a particular value for the implementation data object. When published, the CMS captures the implementation data object and forwards it with the implementation property in a device create action in the event of a segment replacement.  This assists with fast and unintrusive replacement operation.

Edge processors can also publish implementation data in the feedback channel, along with the device’s status object.

Edge servers can publish implementation data in the feedback channel along with any object’s status object.

The CMS records the most recent implementation data for each item, if such data is available, and provides a verbatim copy of that data with the optional implementation property of the object’s create method.  This principle applies to all object types that support a create action.

Implementation data is a single JSON-encoded object. The edge server defines that object and its properties to include the details necessary to guide a replacement procedure.  The CMS does not interpret or modify this data but stores and forwards a verbatim copy.

Provisioning implementation data is optional. An edge server may never provide implementation data, or may provide implementation data only for some object types.

During a Segment Replacement

When restoring items during a segment replacement, the edge server tries to restore items in the least disruptive fashion. Implementation data may help to accomplish that goal, but in the general case, items outside the edge server itself may have changed and must be verified.

For example, edge devices controlled by, but not contained within the replacement edge server may have changed, perhaps as a result of repair attempts. The replacement edge server must verify these items and restore them to the correct configuration according to the replacement and implementation data.

The replacement edge server should execute disruptive steps only when necessary. For example, most edge devices will probably still be in the exact same configuration as they were before the edge server replacement, and may just need to be confirmed, while some may require a more disruptive re-provisioning step.

See also Edge Server Replacement.

glp/0/17qehie/fb/dev/lon/1/impl
{
    "meta":{
        "status":{},
        "eid":"1",
        "id":5,
        "link":{
            "channel":"/~/-4"
        },
        "programId":"900001153C000405",
        "type":"/~/type/dev/LON/pulseGen.XIF",
        "uniqueId":"00D07110024A",
        "address":{
            "UseExtendedCommandSet":"false",
            "BindingConstraints":"1",
            "domain":{
                "0":{
                    "domainId":"4C",
                    "domainLength":1,
                    "subnet":199,
                    "nodeId":117
                }
            }
        }
    },
    "mru":"2023-06-28 19:35:49.298 UTC"
}