Subject: [Netconf] Timestamps and Etags for multiple value responses

From: [email-masked] (Dale R. Worley)
Date: Mon, 12 Sep 2016 10:18:11 -0400

In draft-ietf-netconf-restconf-16, section 4.3 says

   If any content is returned to the client, then the server MUST send a
   valid response message-body.  More than one element MUST NOT be
   returned for XML encoding.  If multiple elements are sent in a JSON
   message-body, then they MUST be sent as a JSON array.  In this case
   any timestamp or entity-tag returned in the response MUST be
   associated with the first element returned.

I think that last sentence doesn't do what we want.

The goal of timestamps and Etags is to allow the client, in a later GET
request for the same URL, to avoid the overhead of transmitting and
processing the response body if the content will be the same as that of
a preceding response.  In order to make that work, the timestamp/Etag
has to have the right semantics, which is described in the respective
specifications.  In particular, the cache-control data describes whether
the response representation for a particular URL has changed.

But the specification above doesn't have the right semantics, the
cache-control data will only track the changes to the first returned
item, and not the later items, or even whether items have entered or
left the set of selected items.

I don't know of a good fix to this problem.  But an implementation can
always detect which requests could potentially return multiple values,
and if so,

    for Etags:  assume Etag mismatch on GET, and never return an Etag in
    the response

    for timestamps:  assume the data has changed since the
    if-modified-since time

Dale

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Sep 2016 09:46:16 -0700

>     for timestamps:  assume the data has changed since the

So should we change the text to say that the server MUST NOT send an ETag
or a
Last-Modified  header line if the response contains multiple resource
instances?

Dale

Andy

>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 12 Sep 2016 14:50:01 -0400

[email-masked] (Dale R. Worley) writes:
> [...]

I think it's worse than that:  More than one element can be sent in a
response only if the URL specifies an unkeyed list.  Unkeyed lists can
only exist in non-configuration data.  Timestamps and Etags are only
maintained for configuration data.  So such a request intrinsically
cannot have a timestamp or Etag.  (Or am I overlooking something?)

Dale

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Sep 2016 11:57:59 -0700

> cannot have a timestamp or Etag.  (Or am I overlooking something?)
The issue raised befoew was "which node is the ETag for if a JSON array
is sent?  This seems to be generic for any payload using the
application/json
media type.  RESTCONF should do the same thing as other JSON payloads.

We want to support RESTCONF Collections in the near future, and a GET
request
for a list without any keys needs to be allowed for that.

Andy

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 13 Sep 2016 10:44:57 -0400

Andy Bierman <[email-masked]> writes:
> The issue raised [before] was "which node is the ETag for if a JSON
> array is sent?  This seems to be generic for any payload using the
> application/json media type.  RESTCONF should do the same thing as
> other JSON payloads.

All that is good in principle.  But in any situation where that can
happen, the data is non-configuration and the Restconf server *does not*
have timestamps/etags for the data being returned, as documented in
section 3.5.2.  So the server needs to do whatever is the standard thing
when the server doesn't have this information for what it is returning.
(I haven't dug into how timestamps and etags are specified, but
presumably RFC 7232 make that clear.)

> request for a list without any keys needs to be allowed for that.

If you mean to allow "a GET request for a keyed list that specifies no
keys", then yes, you can return timestamp/etag for that.  My approach
would be to not specify in this document how the server could handle
that, since there are a lot of approaches that would work, generally
allowing a tradeoff between amount of work on the server's part and
preventing false differences in timestamps/etags.  Instead, I'd fall
back on requiring the server to satisfy the semantics of using
timestamps/etags (which I presume are tightly defined in the RFCs that
define them) and leaving it to the implementor to decide how.

(E.g., if you do a GET and get a response with an Etag value, if you do
another GET with an If-None-Match header with that Etag value and the
server responds to the second request with 304 Not Modified, then an
unconditional GET would have returned the same representation as the
first GET did.)

But all of this can be worried about in the draft that defines the
possibility of a URL (resource) for a keyed list that specifies no keys.

Dale