6 Configuration management procedures

24.5463GPPConfiguration management - Service Enabler Architecture Layer for Verticals (SEAL)Protocol specificationRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.1 General

6.2 On-network procedures

6.2.1 General

6.2.1.1 Authenticated identity in HTTP request

Upon receiving an HTTP request, the SCM-S shall authenticate the identity of the sender of the HTTP request as specified in 3GPP TS 24.547 [5], and if authentication is successful, the SCM-S shall use the identity of the sender of the HTTP request as an authenticated identity.

6.2.1.2 Authenticated identity in CoAP request

Upon receiving an CoAP request, the SCM-S shall authenticate the identity of the sender of the CoAP request as specified in 3GPP TS 24.547 [5], and if authentication is successful, the SCM-S shall use the identity of the sender of the CoAP request as an authenticated identity.

6.2.2 Common procedures

6.2.2.1 Management of configuration update event subscription

6.2.2.1.1 SIP based procedures

6.2.2.1.1.1 General

The VAL service will use the same identity which has been authenticated by VAL service with SIP core using SIP based REGISTER message. If VAL service do not support SIP protocol, then HTTP based method needs to be used.

The SCM-C shall use mechanism provided by VAL service to add access-token in SIP messages. The SCM-S shall identify the originating VAL user ID from the access-token received from SCM-C using the mechanism defined in VAL service specification.

6.2.2.1.1.2 Create subscription

In order to subscribe to notification of changes of one or more group documents of VAL groups identified by VAL group IDs, a SCM-C shall send an initial SIP SUBSCRIBE request to the network according to the UE originating procedures specified in 3GPP TS 24.229 [8] and IETF RFC 5875 [9]. In the initial SIP SUBSCRIBE request, the SCM-C:

a) shall set the Request-URI to the configured public service identity for performing subscription proxy function of the SCM-S;

b) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.seal" (coded as specified in 3GPP TS 24.229 [8]), in a P-Preferred-Service header field according to IETF RFC 6050 [10];

c) shall include the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.seal" in the Contact header field;

d) shall include an application/resource-lists+xml MIME body. In the application/resource-lists+xml MIME body, the SCM-C shall include one <entry> element for each configuration document to be subscribed to, such that the "uri" attribute of the <entry> element contains a relative path reference to XCAP URI identifying an XML document to be subscribed to;

e) if the VAL server wants to fetch the current state only, shall set the Expires header field according to IETF RFC 6665 [11], to zero. Otherwise, shall set the Expires header field to the duration for which VAL user has requested for subscription;

Upon reception of an initial SIP SUBSCRIBE request:

a) with the Event header field set to xcap-diff;

b) with the Request-URI set to own public service identity for performing subscription proxy function of the SCM-S;

c) with an application/resource-lists+xml MIME body; and

d) with the ICSI value "urn:urn-7:3gpp-service.ims.icsi.seal" (coded as specified in 3GPP TS 24 229 [8]), in a P-Asserted-Service header field according to IETF RFC 6050 [10];

the SCM-S:

d) shall identify the originating VAL user ID and shall use the originating VAL user ID as an authenticated identity when performing the authorization;

b) if the authenticated identity is not authorized to subscribe to notification of changes of any resource in the application/resource-lists+xml MIME body, shall reject the request with a SIP 403 (Forbidden) response and shall not continue with rest of the steps;

e) act as a notifier according to IETF RFC 5875 [9].

6.2.2.1.1.3 Modify subscription

In order to modify or refresh subscription, the SCM-C shall send SIP re-SUBSCRIBE request on the same dialog as the existing subscription, and with the same "Event" header. The SCM-C shall follow the steps specified in clause 6.2.2.1.1.2.1 to create SIP SUBSCRIBE request.

Upon reception of a SIP re-SUBSCRIBE request:

a) with the Event header field set to xcap-diff; and

b) with an application/resource-lists+xml MIME body;

the SCM-S:

a) act as a notifier according to IETF RFC 5875 [9].

6.2.2.1.1.4 Delete subscription

In order to delete the subscription, the SCM-C shall send SIP re-SUBSCRIBE request on the same dialog as the existing subscription, and with the same "Event" header. The SCM-C shall follow the steps specified in clause 6.2.2.1.1.2.1 to create SIP SUBSCRIBE request with following clarification:

a) shall set the Expires header field to zero.

Upon reception of a SIP re-SUBSCRIBE request:

a) with the Event header field set to xcap-diff; and

b) with Expires header field set to zero;

the SCM-S:

a) act as a notifier according to IETF RFC 5875 [9].

6.2.2.1.2 HTTP based procedures

6.2.2.1.2.1 Creating subscription

Upon successful service authorization of the VAL service, the SCM-C shall create a subscription for configuration events by sending an HTTP POST request to the SCM-S. In the HTTP POST request, the SCM-C:

a) shall set the Request URI to the URI of the SCM-S appended with VAL service identity and the value "/configurationEventsSubscription";

b) shall include the Host header with public user identity of SCM-S;

c) shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in IETF RFC 6750 [6]; and

c) include the parameters specified in clause A.1.2 serialized into a JavaScript Object Notation (JSON) structure as specified in IETF RFC 7159 [7].

Upon reception of an HTTP POST request from SCM-C where the Request-URI of the HTTP POST request contains "/configurationEventsSubscription", the SCM-S:

a) shall determine the identity of the sender of the received HTTP POST request as specified in clause 6.2.1.1, and:

1) if the identity of the sender of the received HTTP POST request is not authorized user, shall respond with an HTTP 403 (Forbidden) response to the HTTP POST request and skip rest of the steps;

b) shall generate unique subscription identity and store the subscription details for the authorized user; and

c) shall send an HTTP 200 (OK) response including parameters specified in clause A.1.3.

6.2.2.1.2.2 Modify a subscription

Upon receiving a request from VAL user to modify existing subscription identified with unique subscription identity, the SCM-C:

a) shall generate an HTTP PUT request. In the HTTP PUT request:

1) shall set the Request URI to the same Request URI used while creating subscription in clause 6.2.2.1.2.1.1 appended with subscription identity;

2) shall include the Host header with public user identity of SCM-S;

3) shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in IETF RFC 6750 [6]; and

4) include the parameters specified in clause A.1.2 serialized into a JavaScript Object Notation (JSON) structure as specified in IETF RFC 7159 [7].

b) shall send the HTTP PUT request to the SCM-S.

Upon reception of an HTTP PUT request from SCM-C where the Request-URI of the HTTP PUT request contains "/configurationEventsSubscription" appended with subscription identity, the SCM-S:

a) shall determine the identity of the sender of the received HTTP PUT request as specified in clause 6.2.1.1, and:

1) if the identity of the sender of the received HTTP PUT request is not authorized user, shall respond with an HTTP 403 (Forbidden) response to the HTTP PUT request and skip rest of the steps;

b) shall determine whether subscription for configuration events exists or not based on received subscription identity in request URI; and

1) if subscription does not exist, shall respond with an HTTP 406 (Not Acceptable) response to the HTTP PUT request and skip rest of the steps;

c) shall update the subscription details based on received parameters from the HTTP PUT request; and

d) shall send an HTTP 200 (OK) response including parameters specified in clause A.1.3.

6.2.2.1.2.3 Delete a subscription

Upon receiving a request from VAL user to delete existing subscription identified with unique subscription identity, the SCM-C:

a) shall generate an HTTP DELETE request. In the HTTP DELETE request:

1) shall set the Request URI to the same Request URI used while creating subscription in clause 6.2.2.1.2.1.1 appended with subscription identity;

2) shall include the Host header with public user identity of SCM-S; and

3) shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in IETF RFC 6750 [6]; and

b) shall send the HTTP DELETE request to the SCM-S.

Upon reception of an HTTP DELETE request from SCM-C where the Request-URI of the HTTP DELETE request contains "/configurationEventsSubscription" appended with subscription identity, the SCM-S:

a) shall determine the identity of the sender of the received HTTP DELETE request as specified in clause 6.2.1.1, and:

1) if the identity of the sender of the received HTTP DELETE request is not authorized user, shall respond with an HTTP 403 (Forbidden) response to the HTTP DELETE request and skip rest of the steps;

b) shall determine whether subscription for configuration events exists or not based on received subscription identity in request URI; and

1) if subscription does not exist, shall respond with an HTTP 406 (Not Acceptable) response to the HTTP DELETE request and skip rest of the steps;

c) shall delete the subscription details based on received parameters from the HTTP DELETE request; and

d) shall send an HTTP 200 (OK) response to the SCM-C.

6.2.2.1.3 CoAP based procedures

6.2.2.1.3.1 General

CoAP based procedures shall use the mechanisms to observe a resource as specified in IETF RFC 7641 [14].

NOTE: CoAP "observe" mechanism uses the principle of eventual consistency where an intermediate state change can be lost when UDP is used. If it is critical for the client to receive every change in the resource state (and not just the latest state), TCP can be used to avoid missing notifications.

6.2.2.1.3.2 Create a subscription

In order to subscribe to changes of a configuration document the SCM-C shall send an extended CoAP GET request with the CoAP URI set to the URI of an observable configuration document and with the Observe option set to 0 (Register) as specified in IETF RFC 7641 [14].

Upon reception of such an extended CoAP request from SCM-C where the CoAP URI of the request points at an observable configuration document and with the Observe option set to 0 (Register), the SCM-S:

a) shall perform the steps as for a normal CoAP GET request for a configuration document as defined in clause 6.2.4.4 for VAL UE configuration and in clause 6.2.4.4 for VAL user profile;

b) shall register the SCM-C as an observer as per IETF RFC 7641 [14]; and

c) shall send a CoAP 2.05 (Content) response including the current content of the resource and the Observer option with the initial sequence number of the notifications.

6.2.2.1.3.3 Delete a subscription

In order to unsubscribe from changes of a configuration document the SCM-C shall send a CoAP GET request matching the CoAP GET request used to create the subscription but with the Observe option set to 1 (Deregister) as specified in IETF RFC 7641 [14].

Upon reception of a CoAP GET that matches an active subscription but with the Observe option set to 1 (Deregister), the SCM-S:

a) shall perform the steps as for a normal CoAP GET request for a configuration document as defined in clause 6.2.4.4 for VAL UE configuration and in clause 6.2.4.4 for VAL user profile;

b) shall deregister the SCM-C as an observer as per IETF RFC 7641 [14]; and

c) shall send a CoAP 2.05 (Content) response including the current content of the resource and shall not include the Observer option.

6.2.2.2 Notifications

6.2.2.2.1 SIP based procedures

6.2.2.2.1.1 Client procedure

Upon receiving a SIP NOTIFY request associated with a subscription created as result of the sent initial SIP SUBSCRIBE request, the SCM-S:

a) shall handle the SIP NOTIFY request according to IETF RFC 5875 [9].

6.2.2.2.1.2 Server procedure

In order to send notification of group document update event, the SCM-S shall send SIP NOTIFY to SCM-C according to IETF RFC 5875 [9].

6.2.2.2.2 HTTP based procedures

6.2.2.2.2.1 Receiving configuration update notification

Upon receiving an HTTP POST request over a call back URI which was given to SCM-S at time of the configuration update event subscription message, the SCM-C:

a) shall validate the subscription identity received in the "Identity" parameter of the HTTP POST request. If the subscription identity is not valid, the SCM-C:

1) shall send an HTTP 406 (Not Acceptable) response and skip rest of the steps;

b) shall send an HTTP 200 (OK) message; and

c) shall notify the VAL user about the modification of configuration document based on the "Event" parameter.

Based on VAL user’s request, the SCM-C may also retrieve the configuration document as specified in clause 6.2.3 or in clause 6.2.4.

6.2.2.2.2.2 Sending group modify notification

Upon successful modification of VAL user profile document or VAL UE configuration document, the SCM-S sends a notification to SCM-C. The SCM-S:

a) shall check whether valid configuration update event subscription exists for event SUBSCRIBE_USER_PROFILE_MODIFICATION (0x01) OR SUBSCRIBE_UE_CONFIG_MODIFICATION (0x02) as defined in clause A.1.2 or not;

1) if valid subscription does not exist, shall skip rest of the steps;

b) shall generate an HTTP POST message to notify configuration update notification. In HTTP POST message:

1) shall set the request URI to call back URI received in the creating subscription procedure;

2) shall set the Content-Type header to "application/json"; and

3) shall include an HTTP request entity-body with the parameters specified in clause B.2 serialized into a JavaScript Object Notation (JSON) structure; and

c) shall sent an HTTP POST request towards SCM-C.

6.2.2.2.3 CoAP based procedures

6.2.2.2.3.1 Client procedure

Upon receiving a CoAP 2.05 (Content) response that matches the extended CoAP GET request which initiated the subscription and which contains the Observe option, the SCM-C:

a) shall handle the response according to IETF RFC 7641 [14]; and

b) shall notify the VAL user about the modification of the configuration document.

6.2.2.2.3.2 Server procedure

In order to send a notification when the configuration document is modified, the SCM-S shall send a CoAP 2.05 (Content) response to SCM-C containing the modified document and the Observe option according to IETF RFC 7641 [14]. The Content-Format specified in a 2.xx notification shall be the same as the one used in the initial response to the GET request received for the subscription.

6.2.3 VAL UE configuration data

6.2.3.1 SCM client HTTP procedure

Upon receiving a request from the VAL user to retrieve a VAL UE configuration data, the SCM-C shall send an HTTP GET request to the SCM-S according to procedures specified in IETF RFC 4825 [3] "Fetch a Document". In HTTP GET request, the SCM-C:

a) shall set the Request-URI to a XCAP URI identifying the XML document to be retrieved. In the Request-URI:

1) the "XCAP Root" is set to the URI of the SCM-S;

2) the "auid" is set to specific VAL service identity; and

3) the document selector is set to a document URI pointing to the VAL UE configuration document;

b) shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in IETF RFC 6750 [6]; and

c) may include the parameters specified in clause A.2.1 serialized into a JavaScript Object Notation (JSON) structure as specified in IETF RFC 7159 [7]

6.2.3.2 SCM server HTTP procedure

Upon reception of an HTTP GET request where the Request-URI of the HTTP GET request identifies a UE configuration document as specified in the specific vertical application, the SCM-S:

a) shall determine the identity of the sender of the received HTTP GET request as specified in clause 6.2.1.1, and:

1) if the identity of the sender of the received HTTP GET request is not authorized to fetch requested configuration document, shall respond with a HTTP 403 (Forbidden) response to the HTTP GET request and skip rest of the steps; and

b) shall support handling an HTTP GET request from a SCM-C according to procedures specified in IETF RFC 4825 [3] "GET Handling".

6.2.3.3 SCM client CoAP procedure

Upon receiving a request from the VAL user to retrieve a VAL UE configuration data, the SCM-C shall send a CoAP GET request to the SCM-S. In the CoAP GET request, the SCM-C:

a) shall set the CoAP URI identifying the user profile document to be retrieved according to the resource API definition in Annex C.3.1:

1) the "apiRoot" is set to the SCM-S URI;

2) the "valServiceId" is set to specific VAL service;

3) if the SCM-C does not know the "ueConfigDocId" of the UE configuration document at the SGM-S, the SCM-C shall make a GET request for the UE Configurations as described in Annex C.3.1.2.2.3.1 and shall set applicable query parameters defined in table C.3.1.2.2.3.1-1; and

4) if the SCM-C knows the "ueConfigDocId" of the UE configuration document at the SGM-S, the SCM-C shall make a GET request for the Individual UE Configuration as described in Annex C.3.1.2.3.3.1, and shall set "ueConfigDocId" to point to the VAL UE configuration document; and

b) shall send the request protected with the relevant ACE profile (OSCORE profile or DTLS profile) as described in 3GPP TS 24.547 [5].

6.2.3.4 SCM server CoAP procedure

Upon reception of an CoAP GET request where the CoAP URI of the request identifies UE Configurations resource as described in Annex C.3.1.2.2.3.1, the SCM-S:

a) shall determine the identity of the sender of the received CoAP GET request as specified in clause 6.2.1.2, and:

1) if the sender is not authorized to fetch the requested UE configuration document(s), shall respond with a CoAP 4.03 (Forbidden) response to the CoAP GET request and skip rest of the steps;

b) shall support handling a CoAP GET request from a SCM-C according to procedures specified in IETF RFC 7252 [12];

c) shall check if the resource exists for the given VAL service, and:

1) if the resource does not exist, shall return a 4.04 (Not found) response and skip rest of the steps; and

d) shall return a 2.05 (Content) response including all the UE configuration documents found for the given values of the query parameters defined in table C.3.1.2.2.3.1-1.

Upon reception of an CoAP GET request where the CoAP URI of the request identifies Individual UE Configuration resource as described in Annex C.3.1.2.3.3.1, the SCM-S:

a) shall determine the identity of the sender of the received CoAP GET request as specified in clause 6.2.1.2, and:

1) if the sender is not authorized to fetch the requested UE configuration document, shall respond with a CoAP 4.03 (Forbidden) response to the CoAP GET request and skip rest of the steps;

b) shall support handling a CoAP GET request from a SCM-C according to procedures specified in IETF RFC 7252 [12]; and

c) shall check if the resource pointed at by the CoAP URI exists and:

1) if it exists, shall return the UE configuration document in a 2.05 (Content) response; or

2) otherwise, shall return a 4.04 (Not found) response.

6.2.4 VAL user profile data

6.2.4.1 SCM client HTTP procedure

Upon receiving a request from the VAL user to retrieve a VAL user profile data, the SCM-C shall send an HTTP GET request to the SCM-S according to procedures specified in IETF RFC 4825 [3] "Fetch a Document". In HTTP GET request, the SCM-C:

a) shall set the Request-URI to a XCAP URI identifying the XML document to be retrieved. In the Request-URI:

1) the "XCAP Root" is set to the URI of the SCM-S;

21) the "auid" is set to specific VAL service identity; and

3) the document selector is set to a document URI pointing to the VAL user profile document; and

b) shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in IETF RFC 6750 [6].

6.2.4.2 SCM server HTTP procedure

Upon reception of an HTTP GET request where the Request-URI of the HTTP GET request identifies a user profile document as specified in the specific vertical application, the SCM-S follow the procedure as described in clause 6.2.3.2.

6.2.4.3 SCM client CoAP procedure

Upon receiving a request from the VAL user to retrieve a VAL user profile data, the SCM-C shall send a CoAP GET request to the SCM-S. In the CoAP GET request, the SCM-C:

a) shall set the CoAP URI identifying the user profile document to be retrieved according to the resource API definition in Annex C.2.1:

1) the "apiRoot" is set to the SCM-S URI;

2) the "valServiceId" is set to specific VAL service;

3) if the SCM-C does not know the "profileDocId" of the user profile document at the SGM-S, the SCM-Cshall use the User Profiles resource GET, as described in Annex C.2.1.2.2.3.1, and shall set val-tgt-ue to either the VAL user identity or VAL UE identity; and

4) if the SCM-C knows the "profileDocId" of the user profile document at the SGM-S, the SCM-C shall use the Individual User Profile resource GET, as described in Annex C.2.1.2.3.3.1, and shall set "profileDocId" to point to the VAL user profile document; and

b) shall send the request protected with the relevant ACE profile (OSCORE profile or DTLS profile) as described in 3GPP TS 24.547 [5].

6.2.4.4 SCM server CoAP procedure

Upon reception of an CoAP GET request where the CoAP URI of the request identifies User Profiles resource as described in Annex C.2.1.2.2.3.1, the SCM-S:

a) shall determine the identity of the sender of the received CoAP GET request as specified in clause 6.2.1.2, and:

1) if the identity of the sender of the received CoAP GET request is not authorized to fetch requested user profile document(s), shall respond with a CoAP 4.03 (Forbidden) response to the CoAP GET request and skip rest of the steps;

b) shall support handling a CoAP GET request from a SCM-C according to procedures specified in IETF RFC 7252 [12]; and

c) shall check if the resource exists for the given VAL service, and:

1) if the resource does not exist, shall return a 4.04 (Not found) response and skip rest of the steps;

d) shall return a 2.05 (Content) response including all the user profile documents found for the given VAL user or VAL UE given in the query parameter.

Upon reception of an CoAP GET request where the CoAP URI of the request identifies Individual User Profile resource as described in Annex C.2.1.2.3.3.1, the SCM-S:

a) shall determine the identity of the sender of the received CoAP GET request as specified in clause 6.2.1.2, and:

1) if the identity of the sender of the received CoAP GET request is not authorized to fetch requested user profile document, shall respond with a CoAP 4.03 (Forbidden) response to the CoAP GET request and skip rest of the steps;

b) shall support handling a CoAP GET request from a SCM-C according to procedures specified in IETF RFC 7252 [12]; and

c) shall check if the resource pointed at by the CoAP URI exists and:

1) if it exists, shall return the user profile document in the 2.05 (Content) response; or

2) otherwise, shall return a 4.04 (Not found) response.

6.2.5 Update VAL user profile data

6.2.5.1 SCM client HTTP procedure

Upon receiving a request from the VAL user to update the VAL user profile configuration document, the SCM-C shall create an XML document as specified in coding of the specific vertical application and shall send the XML document to the SCM-S according to procedures specified in IETF RFC 4825 [3] "Create or Replace a Document". In the HTTP POST request, the SCM-C:

a) shall set the Request URI to a XCAP URI identifying an XML document to be updated. In the Request-URI:

1) the "XCAP Root" is set to the URI of the SCM-S;

2) the "auid" is set to specific VAL service identity; and

3) the document selector is set to the VAL user profile;

b) shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in IETF RFC 6750 [6];

c) shall include a Content-Type header field set to "application/vnd.3gpp.seal-user-profile-info+xml"; and

d) shall include an application/vnd.3gpp.seal-user-profile-info+xml MIME body and in the <seal-user-profile> root element:

1) may include <ProfileName> element indicating name of the profile;

2) may include <Status> element indicating status of the profile;

3) may include <isDefault> element indicating that the current profile is the selected profile for the requesting user;

4) shall include <user-profile-index> element indicating the unique profile number; and

5) shall include <profile-configuration> element as specified in clause 7.

6.2.5.2 SCM server HTTP procedure

Upon reception of an HTTP PUT request where the Request-URI of the HTTP PUT request identifies an XML document as specified in the specific vertical application, the SCM-S:

a) shall determine the identity of the sender of the received HTTP PUT request as specified in clause 6.2.1.1, and:

1) if the identity of the sender of the received HTTP PUT request is not authorized to update the configuration document, shall respond with a HTTP 403 (Forbidden) response to the HTTP PUT request and skip rest of the steps; and

b) shall support receiving an XML document as specified in application usage of the specific vertical application according to procedures specified in IETF RFC 4825 [3] "PUT Handling".

6.2.5.3 SCM client CoAP procedure

Upon receiving a request from the VAL user to update the VAL user profile configuration document, the SCM-C shall send a CoAP PUT request to the SCM-S. In the CoAP PUT request, the SCM-C:

a) shall set the CoAP URI identifying the user profile document to be updated according to the resource definition in Annex C.2.1.2.3.3.2:

1) the "apiRoot" is set to the SCM-S URI;

2) the "valServiceId" is set to specific VAL service; and

3) the "profileDocId" to point to the VAL user profile document;

b) shall include Content-Format option set to "application/ vnd.3gpp.seal-user-profile-info+cbor";

c) shall include "ProfileDoc" object with "profileInformation" which:

1) may contain "profileName" element indicating name of the profile;

2) may contain "status" element indicating status of the profile;

3) may contain "isDefault" element indicating that the current profile is the selected profile for the requesting user; and

4) shall contain "profileConfig" elements; and

d) shall send the request protected with the relevant ACE profile (OSCORE profile or DTLS profile) as described in 3GPP TS 24.547 [5].

6.2.5.4 SCM server CoAP procedure

Upon reception of an CoAP PUT request where the CoAP URI of the request identifies Individual User Profile resource as described in Annex C.2.1.2.3.3.2, the SCM-S:

a) shall determine the identity of the sender of the received CoAP PUT request as specified in clause 6.2.1.2, and:

1) if the identity of the sender of the received CoAP PUT request is not authorized to update requested user profile document(s), shall respond with a CoAP 4.03 (Forbidden) response to the CoAP PUT request and skip rest of the steps;

b) shall support handling an CoAP PUT request from a SCM-C according to procedures specified in IETF RFC 7252  [12]; and

c) shall replace the user profile documents pointed at by the CoAP URI with the "ProfileDoc" received in the request.

6.3 Off-network procedures

The off-network procedures are out of scope of the present document in this release of the specification.