Subject: [Netconf] Comments on draft-ietf-netconf-restconf-14

From: "Steve Truong (struong)" <[email-masked]>
Date: Sun, 3 Jul 2016 16:17:45 +0000

In

https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-9.1

   The server MAY maintain a last-modified timestamp for this container,

   and return the "Last-Modified" header when this data node is

   retrieved with the GET or HEAD methods.  Note that the last-modified

   timestamp for the datastore resource is not affected by changes this

   subtree.

Is something missing in the last sentence?

Same comment for the next paragraph on ETag.

In

https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#appendix-D.2.2

D.2.2<https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#appendix-D.2.2>.  Detect Resource Entity Tag Change

   In this example, the server just supports the mandatory datastore

   last-changed timestamp.

Where is timestamp mandatory in draft version 14?

Thanks,

steve

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 06 Jul 2016 14:16:59 -0400

Andy Bierman <[email-masked]> writes:
> I have made all the edits except the 2nd 4.6 below

Thanks!

>> 4.6
>>
>> Yang has been extended to allow non-unique key values.  The result is
>> that URLs may identify multiple data instances.  This seems to be
>> specified for GET (if JSON is used, GET can return multiple instances;
>> if XML is used, a 400 response is given) and DELETE (only one instance
>> (arbitrarily chosen) is deleted; this may be modified by query
>> parameters).  But PATCH does not seem to specify the behavior if
>> multiple instances are selected.
>
> *** not sure what the previous comment is requested... perhaps sec. #  is
> wrong

It turns out I was mistaken.

Yang has been extended to allow non-unique values in leaf-lists, but
only in non-configuration leaf-lists.  (I was mistaken in thinking that
non-unique key values are allowed in lists.)  So we could have a module
definition

   module example-1 {
      namespace "urn:oid:1.3.6.1.4.1.14490.4.20160706.1";
      prefix "ex";

      organization "Example, Inc.";

      leaf-list datum {
        type string;
      }
   }

with a corresponding datastore

   <example-1>
     <datum>alice</datum>
     <datum>bob</datum>
     <datum>bob</datum>
   </example-1>

The result is that URLs may identify multiple data instances.  For
instance, you can request

   GET /restconf/data/example-1:datum=bob HTTP/1.1
   Host: example.com
   Accept: application/yang-data+json

and get

   HTTP/1.1 200 OK
   Date: Mon, 23 Apr 2012 17:02:40 GMT
   Server: example-server
   Content-Type: application/yang-data+json
   Cache-Control: no-cache
   ETag: "a74eefc993a2b"
   Last-Modified: Mon, 23 Apr 2012 11:02:14 GMT

   "example-1:datum" : "bob"
   "example-1:datum" : "bob"

(If I am right that {...} should not appear there.)

The specification for GET, section 4.3, handles this:  if JSON is used,
GET can return multiple instances; if XML is used, a 400 response is
given.

The question I had is what is the response if the URL for a PATCH
operation identifies more than one data instance?

The subtle point that I missed is that you can't edit non-configuration
data, and configuration data does not allow non-unique values in a
leaf-list.  So any instance that you can direct a PATCH to will not have
non-unique values, and the question cannot arise.

Dale