[netmod] Question on RESTCONF / Yang list creation without key value

[Ramon Casellas <[e-mail]>]

Dear all,

Apologies if this is a FAQ, or a basic question but we have been 
recently involved in using RESTCONF  / YANG as a controller NBI to 
request optical connections in the photonic media layer within the TAPI 
framework and we have a doubt.

TL&DR: is it possible to create a list entry without specifying its key, 
assuming that the server can allocate such key while processing the 
request ?



For the context, the TAPI connectivity model allows a client to request 
a connectivity-service. Assume the server manages a list of 
connectivity-services (within a context) keyed by a UUID.

   grouping connectivity-context {
             list connectivity-service {
                 key 'uuid';
                 uses connectivity-service;
             }
   }

with grouping connectivity-service {
             list end-point {
                 key 'local-id';
                 min-elements 2;
                 uses connectivity-service-end-point;
             }

             leaf uuid {
                 type uuid;
            }


For historical reasons, there are two flavors: one is RPC based and the 
other one is data node based. In the RPC based approach, the RPC method 
allows the client to specify the endpoints, the server creates the 
service and replies with the details.

         rpc create-connectivity-service {
             input {
                 list end-point {
                     key 'local-id';
                     min-elements 2;
                     uses connectivity-service-end-point;
                 }
          ...
             output {
                 container service {
                     uses connectivity-service;
                 }
             }
         }

When considering deprecating the RPCs and moving towards a plain POST, 
we want to know if the client MAY not specify a uuid, as in POST to 
http://localhost:4900/restconf/data/tapi-common:context/tapi-connectivity:connectivity-context
{
     "tapi-connectivity:connectivity-service" : [
        {
           "end-point" : [
              {
               ...
              },


A particular use case is as follows: 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 MUST use that UUID 
(provided there are no conflicts, other errors, etc)
- If such 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

It seems this case is somehow covered by the RPC, but when a new 
connectivity-service resource is requested through the RESTCONF Data API 
through a POST operation, MUST the client specify the key (uuid) or is 
it legal to allow the server to process the request, allocate the uuid 
in the process and return the location header?.
It is assumed that the server has all the information needed to allocate 
a uuid.

As per RFC7950

    The combined values of all the leafs specified in the key are used to
    uniquely identify a list entry.  All key leafs MUST be given values
    when a list entry is created.  Thus, any default values in the key
    leafs or their types are ignored.  Any "mandatory" statements in the
    key leafs are ignored.   A leaf that is part of the key can be of 
any built-in or
    derived type.  All key leafs in a list MUST have the same value for 
their "config"
    as the list itself.

It does not explicitly say "by the client", but it can be inferred. 
Different views are i) the server may allocate the uuid, [ as 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) ] ensuring unique leys or ii) the uuid must be provided 
by the client

  We are also aware that with NETCONF things can be different (7.8.6.  
NETCONF <edit-config> Operations  List entries can be created, deleted, 
replaced, and modified through <edit-config>, by using the "operation" 
attribute in the list's XML  element.  In each case, the values of all 
keys are used to uniquely   identify a list entry.  If all keys are not 
specified for a list    entry, a "missing-element" error is returned.)

Thank you very much in advance

Ramon