A profile is a named group of requirements associated with a model or component. It is specified using the profile element (I.11). Profile usage is also discussed in Section 2.3/TR-106 [3]. Each profile element has a name specified using the profile/@name attribute, the profile/@base attribute, or both (depending on whether it is a new profile, it updates an existing profile, or it extends an existing profile, respectively). A profile’s name is formatted as follows: the name, a colon, and its version number (e.g. the initial version of a Baseline profile is named Baseline:1). Profile versioning is discussed in Section 2.3.3/TR-106 [3].
Each profile name is unique within the major version of its associated model.
A profile contains references to this model’s objects and/or parameters. These references are specified using the object (I.11.1) and parameter (I.11.2) reference elements. Their ref attribute
indicates the name of the object24 or parameter being referenced, and their requirement
attribute indicates the access requirement for that item.
A profile object requirement can be one of: notSpecified, present, create, delete, or createDelete. This is set using a profile/object/@requirement attribute. The create, delete, and createDelete settings only apply to multi-instance objects.
A profile parameter requirement can be one of: readOnly or readWrite. This is set using a profile/parameter/@requirement attribute.
A profile can have a description. This is defined using the profile/description element. Similarly, a profile’s objects and parameters can also have descriptions. However, most profiles (and their objects and parameters) do not have a description unless there are additional normative requirements that need to be specified.
Note – The examples throughout this section are of profiles defined within models. The mechanism is almost identical in defining profiles within components. However, a component’s profile name must be unique not only within the component itself, but also within (the major version of) any models from which the component is referenced (included).
6.8.1 Defining a New Profile
The initial version of a new profile is defined using a profile/@name attribute alone (i.e. omit the profile’s base and extends attributes). This attribute indicates the name and version of the profile. The version of a new profile always starts at 1.
24
For model profiles, model/profile/object/@ref will be the full path name of the referenced object. For component profiles, component/profile/object/@ref will be a path name that is relative to the component’s top-level object.
The profile will contain references to objects and/or parameters, where each item indicates its access requirement. Objects are referenced using their path name.
The following example defines the Baseline:1 profile within the Device:2 model. Note that the profile is defined at the bottom of the model, after any object definitions and component references. <dm:document xmlns:dm="urn:broadband-forum-org:cwmp:datamodel-1-2" ... spec="urn:broadband-forum-org:tr-181-2-0-0"> ... <model name="Device:2.0"> ... <object name="Device." ...> ... </object> ... <profile name="Baseline:1">
<object ref="Device." requirement="present">
<parameter ref="InterfaceStackNumberOfEntries" requirement="readOnly"/> </object>
<object ref="Device.DeviceInfo." requirement="present"> <parameter ref="Manufacturer" requirement="readOnly"/> <parameter ref="ProvisioningCode" requirement="readWrite"/> ... </object> ... </profile> ... </model> </dm:document>
Note – A best practice is to define a Baseline profile for each Root and Service Data Model. The Baseline profile should define a minimum set of object and parameter requirements for a CPE implementing the associated model. See Section 2.3.4/TR-106 [3].
6.8.2 Updating an Existing Profile
An updated version of an existing profile is defined using both a profile/@name and a profile/@base attribute.
Note – The syntax for modifying a profile is similar as for initially creating it, but there are rules. These rules are not specified in the DM Schema. See Section A.2.10.3/TR-106 [3] for details.
The base attribute indicates the profile name (and version number) of the existing profile, and the name attribute indicates this same name but with an incremented version number for the new (updated) profile. The version of an updated profile is always incremented by 1.
The updated profile will only contain references to those objects and/or parameters whose requirement is changing (i.e. adding or removing an item, or changing an existing item’s requirement).
The following example defines the Baseline:2 profile based on the existing Baseline:1 profile. The Baseline:1 profile is visible (can be referenced) within the local document because the Device:2.1 model that defines it has been imported via the import/model element.
<dm:document xmlns:dm="urn:broadband-forum-org:cwmp:datamodel-1-3" ... spec="urn:broadband-forum-org:tr-181-2-2-0">
...
<import file="tr-181-2-1.xml" spec="urn:broadband-forum-org:tr-181-2-1"> ... <model name="Device:2.1"/> </import> ... <model name="Device:2.2"> ... <object ...> ... </object> ...
<profile name="Baseline:2" base="Baseline:1">
<object ref="Device.InterfaceStack.{i}." requirement="present"> <parameter ref="HigherLayer" requirement="readOnly" /> <parameter ref="LowerLayer" requirement="readOnly" /> </object>
<object ref="Device.DNS." requirement="present">
<parameter ref="SupportedRecordTypes" requirement="readOnly"/> </object>
</profile> ... </model> </dm:document>
In the above example, the total object and parameter requirements for Baseline:2 are actually the union of those from Baseline:1 plus the new (or updated) requirements specified in Baseline:2. When an existing profile needs be deprecated, obsoleted, or deleted, this is done by updating its profile/@status attribute. See Section 6.10 for details. Note that such a status update will also apply to the profile’s contained items (e.g. object and parameter references), but only if this will “promote” a given item’s status to a “higher” value.
6.8.3 Defining a New Profile by Extension
The initial version of a new profile, which is an extension of (inherits from) another profile, is defined using both a profile/@name and a profile/@extends attribute.
The name attribute indicates the name and version of the new profile. The version of a new profile always starts at 1.
The extends attribute indicates the name and version of the profile(s) being extended (inherited from). This attribute can be a list, and so inheritance from multiple profiles is supported.
The following example defines the DHCPv6ServerAdv:1 profile, which specifies the profile/@extends attribute, and so inherits requirements from the DHCPv6Server:1 profile. <dm:document xmlns:dm="urn:broadband-forum-org:cwmp:datamodel-1-3" ... spec="urn:broadband-forum-org:tr-181-2-2-0"> ... <model name="Device:2.2"> ... <object ...> ... </object> ... <profile name="DHCPv6Server:1">
<object ref="Device.DHCPv6." requirement="present"/> <object ref="Device.DHCPv6.Server." requirement="present"> <parameter ref="Enable" requirement="readWrite"/>
<parameter ref="PoolNumberOfEntries" requirement="readOnly"/> </object>
... </profile>
<profile name="DHCPv6ServerAdv:1" extends="DHCPv6Server:1">
<object ref="Device.DHCPv6.Server.Pool.{i}." requirement="createDelete"> <parameter ref="DUID" requirement="readWrite"/>
<parameter ref="VendorClassID" requirement="readWrite"/> <parameter ref="UserClassID" requirement="readWrite"/> <parameter ref="SourceAddress" requirement="readWrite"/> <parameter ref="SourceAddressMask" requirement="readWrite"/> </object>
</profile> ... </model> </dm:document>
In the above example, the total object and parameter requirements for DHCPv6ServerAdv:1 are actually the union of those from DHCPv6Server:1 (via inheritance) plus the requirements specified in DHCPv6ServerAdv:1.