Subject: [Netconf] RESTCONF timestamp and entity-tag for "default" resources

From: Robert Wilton <[email-masked]>
Date: Thu, 14 Sep 2017 14:57:52 +0100

Hi,

If I make a RESTCONF GET request with a path to a data resource that 
doesn't exist, but has an in scope schema default value, and I'm using 
one of the with-defaults options that means that the default value is 
returned, then what value is the "Last-Modified" header expected or 
required to take?

Specifically, I am thinking of a device that uses per data resource 
timestamps for all explicitly configured data resources rather than 
having a single top level datastore resource timestamp.

Thanks,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Sep 2017 15:05:38 +0000

The default value node was implicitly instantiated when the parent node was created, so I'd set its Last-Modified value to that value.

K.  // contributor

--

Hi,

Thanks,
Rob

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

---

From: Robert Wilton <[email-masked]>
Date: Fri, 15 Sep 2017 09:40:33 +0100

Hi Kent,

Thanks for the suggestion.

I think that your solution works if the implementation instantiates an 
an actual leaf to represent the default value, but I'm not sure that is 
meant to be required.  Without this "Last-Modified" requirement an 
implementation could implicitly instantiate default values from the 
schema when required (e.g. for validation) but not necessarily 
explicitly store them.

But from my reading of RESTCONF section 3.5, the two choices seem to be 
either:

(i) the device has to store the timestamp of when the default value took 
effect (e.g. the last time it was implicitly instantiated for whatever 
reason).

(ii) the device could return the datastore timestamp for the implicitly 
created default node.  But I'm not sure how meaningful that is if the 
device also chooses to return accurate last modified timestamps for 
explicitly configured nodes.  If an implementation was to do this then 
you could easily have a scenario where an implicitly created child node 
has a later timestamp than its parent node, which doesn't seem to to be 
good.

So, perhaps the conclusion is: if you want to return accurate timestamps 
for explicitly created nodes, then it is necessary to also maintain 
accurate timestamps for implicitly created default nodes as well?

Thanks,
Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 15 Sep 2017 10:48:11 +0200 (CEST)

Robert Wilton <[email-masked]> wrote:
> an actual leaf to represent the default value, but I'm not sure that
> is meant to be required.  Without this "Last-Modified" requirement an
> But from my reading of RESTCONF section 3.5, the two choices seem to
> be either:
> 
> (i) the device has to store the timestamp of when the default value
> took effect (e.g. the last time it was implicitly instantiated for
> whatever reason).
> 
> (ii) the device could return the datastore timestamp for the
> implicitly created default node.  But I'm not sure how meaningful that
> is if the device also chooses to return accurate last modified
> timestamps for explicitly configured nodes.  If an implementation was
> to do this then you could easily have a scenario where an implicitly
> created child node has a later timestamp than its parent node, which
> doesn't seem to to be good.
> 
> So, perhaps the conclusion is: if you want to return accurate
> timestamps for explicitly created nodes, then it is necessary to also
> maintain accurate timestamps for implicitly created default nodes as
> well?

IMO this is all implementation details.  One implementation might
instantiate all defaults, while another comes up with some other
clever mechanism to avoid redundant storage.  The spec should clearly
define the semantics associated with the timestamp, and not talk about
how it must be implemented.

/martin

> > The default value node was implicitly instantiated when the parent
> > node was created, so I'd set its Last-Modified value to that value.
> >
> > K.  // contributor
> >
> >
> > --
> >
> > Hi,
> >

---

From: Robert Wilton <[email-masked]>
Date: Fri, 15 Sep 2017 09:55:25 +0100

> how it must be implemented.
Sure.

Do you agree that both (i) and (ii) are allowed by the spec?

Do you also agree that doing (ii) could be confusing to clients?

Thanks,
Rob

> .

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 15 Sep 2017 11:01:46 +0200 (CEST)

> Do you agree that both (i) and (ii) are allowed by the spec?

I don't think (ii) is allowed, and it is not special for defaults.
The extreme of (ii) would be to have a single timestamp for the
datastore, but report it for every resource.

OTOH, just b/c the timestamp differ for a node doesn't mean that the
value is different.  The value might have been changed and the changed
back.  So an implementation might get away with (ii), but as you note,
this is confusing to clients.

> Do you also agree that doing (ii) could be confusing to clients?

Yes.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Fri, 15 Sep 2017 10:48:24 +0100

Hi Martin,

Thanks for the clarification.

OK.  I think the point that I was missing is that node is still a YANG 
data node even if it hasn't been explicitly created in the data tree and 
is taking a default value.  Hence the text for 3.5 applies to default 
nodes as well.

I think that the text at the top of 3.5.1 could be slightly clearer in 
that if a device chooses to maintain a "last-modified" timestamp for 
some configuration resources then it really needs to do this for all 
configuration resources.  I.e. I think that the text in the 3rd 
paragraph of 3.5.1 stating that the datastore timestamp must be used 
instead only reliably works if the device isn't maintaining any per data 
resource timestamps.

Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 Sep 2017 17:22:16 +0200

> how it must be implemented.

I think it would be better and simpler to adhere to the semantics that is
defined for each header field in HTTP specs.

For Last-Modified it is section 2.2 in RFC 7232:

   The "Last-Modified" header field in a response provides a timestamp
   indicating the date and time at which the origin server believes the
   selected representation was last modified, ...

So I think Kent's conclusion is correct: the representation was last
modified when the resource was (conceptually) created, which was at the
time of parent container creation.

ETag is also quite interesting (sec. 2.3):

   An entity-tag is an opaque validator for differentiating between
   multiple representations of the same resource, regardless of whether
   those multiple representations are due to resource state changes over
   time, content negotiation resulting in multiple representations being
   valid at the same time, or both.

As I understand it, if an otherwise unmodified resource (e.g. a
container instance) is represented once with defaults and another time
without defaults, the two representations should have different ETags.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Robert Wilton <[email-masked]>
Date: Mon, 25 Sep 2017 16:08:25 +0100

> time of parent container creation.
I don't think that this is necessarily true.  The default value may get 
"created" if an explicitly configured value for the leaf is removed/deleted.

So, i think that it is required to explicitly track the timestamp of 
when the default node logically came into existence, i.e. the same as 
for any other explicitly configured node.

> without defaults, the two representations should have different ETags.
Yes, I would think so.

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 26 Sep 2017 10:11:02 +0200

> "created" if an explicitly configured value for the leaf is removed/deleted.

Yes, but this is a later step:

- If the parent container is created without that leaf and the default value is
returned, it should have the same timestamp as the parent container.

- If the leaf is edited with a value that is different from the default, the
timestamp of the leaf and its ancestors should be bumped.

- If the leaf is then removed so that the default value is back in use, the
timestamp should be bumped again.

Lada