POST should NOT contain uuid

[jgroom33]

As noted in the specification for REST: https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5

A POST should create a subordinate URI.

[arthurMll]

I do agree that POST operations to Data API resources corresponding to YANG List statements within TAPI models should create new elements within and that UUIDs should be created by the TAPI server in response to the succesful processing of a ConnectivityService or any other alike TAPI element.

The issues I have regarding this are:

• If UUID resources are not configurable by the TAPI clients, then TAPI models should be modified in order to mark UUID resources as read-only data (state information). I propose that UUIDs are updated by the TAPI server when the related tapi resource is marked as operational-state ENABLED.

• In order to retrieve any TAPI resource (e.g., a ConnectivityService) as UUIDs are proposed to be assigned by the TAPI server, there is needed another client identifier or local ID paramenter, that allows to uniquely indentify the resource from the client perspective. I propose to define, for every resource potentially configurable by a TAPI user which is indexed by the UUID (which should be assigned by the TAPI server according to this discussion), a new client identifier (e.g., local-id) parameter.

• In order to get straight access to a TAPI resource which is indexed in a list by UUID but which is created by a TAPI client based on a client identifier paramter, a new RPC might be created to discover the TAPI resource right away from the client identifier parameter: e.g., retrieveConnectivityServiceByName in case the name is chosen as the right client identifier parameter.

Comments?

[rcasellas]

On Mon, Feb 4, 2019, 12:13 PM Arturo Mayoral <notifications@github.com wrote:

I do agree that POST operations to Data API resources corresponding to YANG List statements within TAPI models should create new elements within and that UUIDs should be created by the TAPI server in response to the succesful processing of a ConnectivityService or any other alike TAPI element.

The issues I have regarding this are

-

In order to retrieve any TAPI resource (e.g., a ConnectivityService) as UUIDs are proposed to be assigned by the TAPI server, there is needed another client identifier or local ID paramenter, that allows to uniquely indentify the resource from the client perspective. I propose to define, for every resource potentially configurable by a TAPI user which is indexed by the UUID (which should be assigned by the TAPI server according to this discussion), a new client identifier (e.g., local-id) paramete

Hi

I don't follow this part. In one case you have the post response with the location response heart and the uuid. In the other case the RPC output. Can you elaborate? R.

You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub https://github.com/OpenNetworkingFoundation/TAPI/issues/340#issuecomment-460210417, or mute the thread https://github.com/notifications/unsubscribe-auth/AKDmXTYC6y6DRJAuWj47RJkXNOb_Dm4Bks5vKBXEgaJpZM4WfNda .

[arthurMll]

Oh my assumptions were based on the fact that when you create the resource through a POST operation to a RESTCONF Data API element, you won't get back the location response. If this is the case then I think there is not issue at all.

I guess the behaviour you are mentioning is the one described in https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5:

If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see section 14.30).

If so, this reference to the new resource should be in the form of a URI and included in the HTTP Response Location header right?

[rcasellas]

Yes, with the uuid

On Mon, Feb 4, 2019, 12:29 PM Arturo Mayoral <notifications@github.com wrote:

Oh my assumptions were based on the fact that when you create the resource through a POST operation to a RESTCONF Data API element, you won't get back the location response. If this is the case then I think there is not issue at all.

I guess the behaviour you are mentioning is the one described in https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5:

If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see section 14.30).

If so, this reference to the new resource should be in the form of a URI and included in the HTTP Response Location header right?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OpenNetworkingFoundation/TAPI/issues/340#issuecomment-460215657, or mute the thread https://github.com/notifications/unsubscribe-auth/AKDmXZfUudXTaR-CtR6xFom-aRGfulYcks5vKBmcgaJpZM4WfNda .

[rszwedowski]

The issues I have regarding this are:

• If UUID resources are not configurable by the TAPI clients, then TAPI models should be modified in order to mark UUID resources as read-only data (state information). I propose that UUIDs are updated by the TAPI server when the related tapi resource is marked as operational-state ENABLED.

I'm not sure if it is possible - referring to YANG RFC (https://tools.ietf.org/html/rfc6020#section-7.8.2): 'All key leafs MUST be given value when a list entry is created.' and 'All key leafs in a list MUST have the same value for their "config" as the list itself.'

• In order to retrieve any TAPI resource (e.g., a ConnectivityService) as UUIDs are proposed to be assigned by the TAPI server, there is needed another client identifier or local ID paramenter, that allows to uniquely indentify the resource from the client perspective. I propose to define, for every resource potentially configurable by a TAPI user which is indexed by the UUID (which should be assigned by the TAPI server according to this discussion), a new client identifier (e.g., local-id) parameter.

Is it really necessary? As far as I know, UUID is generated based on host ID and timestamp information. In overall this combination should be unique anyway.

I would really focus on YANG and protocol compatibility. If TAPI base on YANG, all of those use cases should be covered using NETCONF aswell.

EDIT: UUID is somehow locally unique anyway - I'm not aware of any mechanism that could check uniqueness across every UUID distributed over many list's in single datastore.

[rcasellas]

On 05/02/2019 15:30, Rafał Szwedowski wrote:

I would really focus on YANG and protocol compatibility. If TAPI base on YANG, all of those use cases should be covered using NETCONF aswell.

Hi

Although it is not strict requirement that we support TAPI  Yang models over Netconf, you raise a good point.

Using restconf it seems clear that we can allow the server to allocate a uuid and retrieve the Location: header.

Using netconf I am not sure how can we support server allocation, with an edit-config (not rpc)

R.

[italobusi]

@arthurMll : I have received a mail notification of a comment of you but cannot see it on github

Am I missing something?

[arthurMll]

According to YANG RFC (https://tools.ietf.org/html/rfc6020#section-7.8.2): 'All key leafs MUST be given value when a list entry is created.' and 'All key leafs in a list MUST have the same value for their "config" as the list itself.'

Then my assumptions regarding the current realization of the Use Case provisioning is the following:

• The UUID parameter as the key attribute of Connectivity-Service list and other list constructs in TAPI MUST be introduced when a new resource within the list is created. Thus, when a TAPI-CLIENT requests the creation a new list resource through the Data API, it MUST provide the key attribute value within the operation.

• Then, in order to assure UUID uniqueness within the TAPI-SERVER context, the TAPI-SERVER MAY check this UUID and generate a new UUID that replaces the TAPI-CLIENT defined one. In any case, the TAPI-SERVER MUST return the generated resource URI in the HTTP Response Location header.

[arthurMll]

@arthurMll : I have received a mail notification of a comment of you but cannot see it on github

Am I missing something?

I refined my post.

[karthik-sethuraman]

• Then, in order to assure UUID uniqueness within the TAPI-SERVER context, the TAPI-SERVER MAY check this UUID and generate a new UUID that replaces the TAPI-CLIENT defined one. In any case, the TAPI-SERVER MUST return the generated resource URI in the HTTP Response Location header.

Actually, any UUID (generated either by TAPI client or TAPI server) by definition is globally unique. So there is no need (and should not) for replacement by server. We agreed in ODTN and TAPI calls that the server just uses the UUID provided by the client.

[italobusi]

@arthurMll : regarding your comment https://github.com/OpenNetworkingFoundation/TAPI/issues/340#issuecomment-497329746

If I understand correctly, the proposal is that the TAPI-CLIENT passes the UUID when requesting the creation of an list entry but the TAPI-SERVER can assign a different UUID when creating the list entry

Is my understanding correct?

Is this behavior compliant with RESTCONF/NETCONF?

[karthik-sethuraman]

@arthurMll : regarding your comment #340 (comment)

If I understand correctly, the proposal is that the TAPI-CLIENT passes the UUID when requesting the creation of an list entry but the TAPI-SERVER can assign a different UUID when creating the list entry

Is my understanding correct?

The TAPI server uses the UUID provided by the TAPI client. It should not replace it

[arthurMll]

I would like to have a committed resolution from TAPI group about this conclusion and then close the issue.

[rcasellas]

On 30/5/19 15:37, Karthik Sethuraman wrote:

  * Then, in order to assure UUID uniqueness within the
    TAPI-SERVER context, the TAPI-SERVER MAY check this UUID and
    generate a new UUID that replaces the TAPI-CLIENT defined one.
    In any case, the TAPI-SERVER MUST return the generated
    resource URI in the HTTP Response Location header.

Actually, any UUID (generated either by TAPI client or TAPI server) by definition is globally unique. So there is no need (and should not) for replacement by server. We agreed in ODTN and TAPI calls that the server just uses the UUID provided by the client.

Hi all

Just my 2 cents, in case it's helpful, apologies for the long mail

First, in ODTN to instantiate a service, we only implemented  the RPC and the UUID  is allocated by the server (for clarification)

Second, from the sentence:

/"the UUID parameter as the key attribute of Connectivity-Service list and other list constructs in TAPI MUST be introduced when it is created, thus when a TAPI-CLIENT request the creation of one of these list resources through the Data API, MUST provide the key attribute value within the operation."/

I would like a clear answer from a RESTconf expert because I tend to disagree.

As per  YANG RFC (https://tools.ietf.org/html/rfc6020#section-7.8.2), 'All key leafs MUST be given value when a list entry is created.' and 'All key leafs in a list MUST have the same value for their "config" as the list itself.'

One could argue that the key is allocated when the server creates the service  - the list entry is created--. in another (private) implementation of an OLS controller, our "common" use case is both the RPC and the POST, as follows.

Send to the context: http://localhost:4900/restconf/data/tapi-common:context/tapi-connectivity:connectivity-context

{    "tapi-connectivity:connectivity-service" : [       {          "end-point" : [             {                "local-id" : "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa",                "layer-protocol-name" : "PHOTONIC_MEDIA",                "role" : "UNKNOWN",                "direction" : "UNIDIRECTIONAL",                "layer-protocol-qualifier" : "tapi-photonic-media:PHOTONIC_LAYER_QUALIFIER_NMC",                "service-interface-point" : {                   "service-interface-point-uuid" : "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"                },                "protection-role" : "WORK"             },             {                "layer-protocol-qualifier" : "tapi-photonic-media:PHOTONIC_LAYER_QUALIFIER_NMC",                "direction" : "UNIDIRECTIONAL",                "protection-role" : "WORK",                "service-interface-point" : {                   "service-interface-point-uuid" : "bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb"                },                "layer-protocol-name" : "PHOTONIC_MEDIA",                "local-id" : "bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb",                "role" : "UNKNOWN"             }          ],          "connectivity-constraint" : {             "requested-capacity" : {                "total-size" : {                   "value" : 50,                   "unit" : "GHZ"                }             }          }       }    ] }

And the server replies a "Created"  with an HTTP response header "Location"

/restconf/data/tapi-common:context/tapi-connectivity:connectivity-context/connectivity-service=9dfcf27d-eece-47d4-9345-923a11cd2e72

In my (humble) opinion, I understand that this may not be compliant pending further study, but OTOH I am not against a deployment model in which such UUIDs are generated exclusively by the server, so the user does not need to generate any

Best regards Ramon

[jgroom33]

Is it assumed that the TAPI server will always use client generated UUID's? IMO, this is a desired behavior, but is not a strict requirement in all scenarios.

Therefore, the implementation should handle both scenarios:

POST body to http://localhost:4900/restconf/data/tapi-common:context/tapi-connectivity:connectivity-context :

{
  "tapi-connectivity:connectivity-service": [
    { "requested-uuid":"9dfcf27d-eece-47d4-9345-923a11cd2e72",
      "end-point": [
        {
          "local-id": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
        },
        {
          "local-id": "bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb"
        }
      ]
    }
  ]
}

response:

{"uuid":"9dfcf27d-eece-47d4-9345-923a11cd2e72"}

If that uuid is not available, the response should fail.

That said, A more standard way to support this behavior is to allow the server to generate it's own uuid in all scenarios and store the client specified uuid in a separate property as follows:

POST body to http://localhost:4900/restconf/data/tapi-common:context/tapi-connectivity:connectivity-context :

{
  "tapi-connectivity:connectivity-service": [
    { "meta": {
        "uuid": "9dfcf27d-eece-47d4-9345-923a11cd2e72"
      },
      "end-point": [
        {
          "local-id": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
        },
        {
          "local-id": "bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb"
        }
      ]
    }
  ]
}

[italobusi]

@jgroom33 : is the solution you are proposing compliant with RESTCONF protocol as defined in [RFC 8040] or does it require some "proprietary" extensions to be mutually agreed between the TAPI client and server?

[jgroom33]

I read through the restconf spec and nothing proposed appears to be a violation of the standard. The first option might be more appropriate. The second option would require the client to use a query to retrieve the actual uuid.

[rcasellas]

On 13/6/19 7:30, Jeff Groom wrote:

I read through the restconf spec and nothing proposed appears to be a violation of the standard. The first option might be more appropriate. The second option would require the client to use a query to retrieve the actual uuid.

Hi Jeff, all

Wrt RESTConf, I tend to agree, although I was considering asking this to netmod@ and teas@ (Italo's thread is related but not exactly the same) for a confirmation. As stated in my previous message IMHO the key allocation and uniqueness can happen when the entry in the list is crated by the server, upon request, and it doe snot seem to contradict the RFC (given that the uuid field is not "mandatory") [ All key leafs MUST be given value when a list entry is created.' and 'All key leafs in a list MUST have the same value for their "config" as the list itself.' ]

On the other hand, I am not convinced with the "proposed/meta" and "final" uuid. My personal preference is "use the client provided one if allowed, allocate one otherwise" :

• The client MAY specify a uuid when requesting a connectivity service

• The server MUST allocate a uuid upon creation of the list entry

• If the client provided uuid can be used, the server SHOULD use that uuid.  (MUST?)

• [ In case of SHOULD ] If the server decides not to use the uuid, the server MUST reply with a failure (resource-denied 409) or similar

• If the uuid is already in use, the server MUST reply with a failure (in-use, 409) or similar. The client MAY retry the operation with another client generated UUID.

• If the operation is successful  the server MUST reply with the Location header

I am not sure what you mean by " second option would require the client to use a query to retrieve the actual uuid" in any case, the actual allocated uuid is in the Location: header

thanks Ramon

[jgroom33]

I agree with the described implemention.

There are three ways to implement:

1. POST to foo/<uuid>
2. POST to foo (uuid in body)
3. POST to foo (requested-uuid in body)

[italobusi]

@rcasellas : I agree that the best option is to validate our understanding regarding RESTCONF compliance it to check with the netmod wg (I do not think we need to involve teas wg to this discussion)

Could you please send a mail explaining the issue and the proposed solution to the netmod wg?

[karthik-sethuraman]

Agreed on TAPI call - June 25, 2019 (after getting feedback from IETF Netmod group):

• For TAPI 2.2, --- TAPI Client should provide the uuid/key in the POST (and create RPCs), the TAPI Server should honor this value provided by the TAPI Client. --- TAPI create RPCs need to be updated to include the uuid parameter as input.
• For future TAPI release 3.x, we will consider having 2 uuids/keys for client created resources - one assignedby the client and one assigned by the server

[jgroom33]

there are 2 ways to provide the uuid in the POST.

1. POST to foo/<uuid>
2. POST to foo/ (uuid in body of POST)

The second option would conform to the RESTful spec: https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5