Subject: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)

From: Balázs Lengyel <[email-masked]>
Date: Wed, 23 Mar 2022 22:34:14 +0000

Hello Jan,
I assume that the etag defined in your I-D is the same as the one defined in Restconf. Does or should your draft include a statement like:
"The etag values maintained by the server are protocol/interface independent. If requested the same etag values will be visible on all interface including Restconf, Netconf, CLI etc."

Restconf also includes timestamps. What was your reason to exclude them from your I-D ? IMHO if the server maintains timestamps they would be protocol/interface independent just as etags, so the task is to make them available on Netconf too (and maybe the CLI).
Regards Balazs

---

From: Kent Watsen <[email-masked]>
Date: Wed, 23 Mar 2022 23:05:07 +0000

> “The etag values maintained by the server are protocol/interface independent. If requested the same etag values will be visible on all interface including Restconf, Netconf, CLI etc.”

While it makes sense that a server would use the same values across protocols, I'm unsure if it's needed and, if we do, if we could state it in a NETCONF-specific draft.

> Restconf also includes timestamps. What was your reason to exclude them from your I-D ? IMHO if the server maintains timestamps they would be protocol/interface independent just as etags, so the ta…

I agree and have mentioned before.  LastModified either needs to be added, or justified why not added, to get my adoption support.

> Regards Balazs

Kent // contributor

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 23 Mar 2022 23:32:41 +0000

From: Kent Watsen <[email-masked]>
Sent: Thursday, 24 March, 2022 00:05
To: Balázs Lengyel <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)

While it makes sense that a server would use the same values across protocols, I'm unsure if it's needed and, if we do, if we could state it in a NETCONF-specific draft.
BALAZS2: I see it as a VERY important advantage of the whole YANG/Netconf/Restconf ecosystem that the separate protocols (practically including the CLI and possibly a gui too) are just views of the same central configuration datastore. So IMO this is important and should be stated.

Regards Balazs

Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Mar 2022 17:03:56 -0700

On Wed, Mar 23, 2022 at 4:33 PM Balázs Lengyel <balazs.lengyel=
[email-masked]> wrote:

> *From:* Kent Watsen <[email-masked]>
> *Sent:* Thursday, 24 March, 2022 00:05
> *To:* Balázs Lengyel <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [netmod] Common etag, timestamp on all interfaces
> (draft-lindblad-netconf-transaction-id)
>
>
>
>
>
>
>
> I assume that the etag defined in your I-D is the same as the one defined
> in Restconf. Does or should your draft include a statement like:
>
> “The etag values maintained by the server are protocol/interface
> independent. If requested the same etag values will be visible on all
> interface including Restconf, Netconf, CLI etc.”
>
>
>
> While it makes sense that a server would use the same values across
> protocols, I'm unsure if it's needed and, if we do, if we could state it in
> a NETCONF-specific draft.
>
> BALAZS2: I see it as a VERY important advantage of the whole
> YANG/Netconf/Restconf ecosystem that the separate protocols (practically
> including the CLI and possibly a gui too) are just views of the same
> central configuration datastore. So IMO this is important and should be
> stated.
>
>
>

I strongly support this approach.
It applies to the entire server API, including notifications.
E.g., a client should be able to reuse code for processing NETCONF
notifications,
even if the protocol is RESTCONF or the new YANG-Push over UDP.

The RESTCONF mechanisms adapted from HTTP should be extended to be
protocol-independent.  Our goal should be code to the YANG models, NOT the
protocols.

>
> Restconf also includes timestamps. What was your reason to exclude them
> from your I-D ? IMHO if the server maintains timestamps they would be
> protocol/interface independent just as etags, so the task is to make them
> available on Netconf too (and maybe the CLI).
>
>
>
> I agree and have mentioned before.  LastModified either needs to be added,
> or justified why not added, to get my adoption support.
>
>
>

I agree. They both need to be supported in RESTCONF.
A timestamp can be applied to multiple servers, unlike the ETag values.
Typical usage is for the client to track its own polling timestamps,
and use If-Modified-Since to retrieve data only if needed.
The same timestamp can also be used with If-Unmodified-Since for edits.

> Kent // contributor

Andy

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

---

From: Jan Lindblad <[email-masked]>
Date: Thu, 24 Mar 2022 21:37:55 +0100

Andy, Balazs, Kent,

Thanks for your very good questions. Comments inline.
> BALAZS2: I see it as a VERY important advantage of the whole YANG/Netconf/Restconf ecosystem that the separate protocols (practically including the CLI and possibly a gui too) are just views of the…
As an implementor, I think it makes great sense to use the same underlaying mechanism for all mgmt interfaces.

I could imagine some implementors planning to lean on the wire representation to compute hashes over the data as their ETag implementation. That would not be possible under this requirement, but ruling out that particular idea would not be problematic, imo.

Long ago, I pondered this question for a while, but then I wasn't able to think of a use case where a client would benefit from a guarantee that all interfaces have common ETags, so I left it out in order to not produce a CLR. I'm not against adding this requirement if we can think of a reasonable reason why. Adding a requirement for CLI+GUI sounds hard in practice, though.
> E.g., a client should be able to reuse code for processing NETCONF notifications,
> protocol-independent.  Our goal should be code to the YANG models, NOT the protocols.

Yes, I certainly like that. 
> I agree and have mentioned before.  LastModified either needs to be added, or justified why not added, to get my adoption support.
I'm not against having Last-Modified in there. In fact, it was in the draft initially. Here's the justification why I removed it :-)

+ When I started the cost/benefit analysis for what I proposed, I soon found that it's not unimportant how many and how large ETag attributes are added to the payload. Having two mechanisms (i.e. both ETag and Last-Modified) doing pretty much the same thing started to look expensive in performance.
+ Since it's essential that the time stamp would have to be the same on all touched elements, all the components/subsystems/subagents involved would still have to be fed the exact time from the central management agent.
+ Then there's one or two more things with If-Unmodified-Since that I discuss below.

> I agree. They both need to be supported in RESTCONF.

RESTCONF has a SHOULD for the (single) datastore root level and MAY for the deeper levels. 

> A timestamp can be applied to multiple servers, unlike the ETag values.

I don't think this analysis is correct. A client connecting with 15 servers in a network wide transaction would surely receive several differing timestamps. The times may be fairly close if NTP is running fine, latency is low, network and cpu load is even and the servers are running similar code, but they will rarely all be the same even with the low 1s Last-Modified resolution. If you allow clients to set the ETag in the request (which is trivial to allow), then the tags could be exactly the same across all servers (and known to the client before the request is even sent to the servers, allowing request pipelining).

> The same timestamp can also be used with If-Unmodified-Since for edits.

If-Unmodified-Since is what set me going with this whole draft, so obviously I value that mechanism highly. The fact that it works with timestamps worries me a bit, however. 

First, the resolution is pretty low, 1s. It is quite possible that a server could process more than one edit/POST in the same second, in which case this mechanism might indicate no change has taken place when in fact it has.

Secondly, while the idea with timestamps and "unmodified since" is very convenient, it's also quite brittle. If a client ever sends an edit request to a server without using the If-Unmodified-Since, it may miss an update made by another client. The ETag mechanism does not have that issue.

If this isn't obvious, here's an example:
1. Client A sends an edit to the server If-Unmodified-Since t0. Successful. Receives a Last-Modified timestamp t1.
2. Client B sends a an edit to the server. Last-Modified timestamp on server is now t2.
3. Client A sends an edit to the server without If-Unmodified-Since. It just sets one tiny little leaf off in one corner. Successful. Received a Last-Modified timestamp t3.
4. Client A sends an edit to the server If-Unmodified-Since t3. Successful, but clobbers Client B's edit, leading to a misconfiguration, which opens a security hole.

This is because the If-Unmodified-Since uses less than or equal in its test. The ETag mechanism is not susceptible to this issue, as it uses an equality test.

Best Regards,
/jan

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 24 Mar 2022 20:52:36 +0000

Hello Jan,
I don’t see a specific need for timestamps, so I can accept your arguments against it. Just add a sentence about it somewhere into the draft. It can be an appendix.

Common/Uniform ETAGs for multiple interfaces is only important if you actually use multiple interfaces. That actually happens when troubleshooters use a big OSS system to do most of the work, but also use a thin client or the CLI to check a few things during the process. So yes uniform Etags are important.
Regards Balazs

From: Jan Lindblad <[email-masked]>
Sent: Thursday, 24 March, 2022 21:38
To: Andy Bierman <[email-masked]>; Balázs Lengyel <[email-masked]>; Kent Watsen <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)

Andy, Balazs, Kent,

Best Regards,
/jan

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Mar 2022 15:56:55 -0700

On Thu, Mar 24, 2022 at 1:52 PM Balázs Lengyel <[email-masked]>
wrote:

> Hello Jan,
>
> I don’t see a specific need for timestamps, so I can accept your arguments
> against it. Just add a sentence about it somewhere into the draft. It can
> be an appendix.
>
>
>

OK with me.
A timestamp could be added in the future if it is really important enough.

In fact, it would be a good idea to break from ETag completely, because
that is tied
to the representation, which is not what is needed here.

We call a "transaction-id" a "config-id" once it is applied to a datastore.
The internal uint64 ID is global, not per datastore.
The "config-id" attribute is added to the <config> element in certain cases.
(It is useful to expose the config-id in <get-config>, NV-store, etc)

Common/Uniform ETAGs for multiple interfaces is only important if you
> actually use multiple interfaces. That actually happens when
> troubleshooters use a big OSS system to do most of the work, but also use a
> thin client or the CLI to check a few things during the process. So yes
> uniform Etags are important.
>

I would say universal transaction-ids (same in each protocol) is a SHOULD,
not a MUST.

Andy

>
>
> *From:* Jan Lindblad <[email-masked]>
> *Sent:* Thursday, 24 March, 2022 21:38
> *To:* Andy Bierman <[email-masked]>; Balázs Lengyel <
> [email-masked]>; Kent Watsen <[email-masked]>
> *Cc:* [email-masked]
> As an implementor, I think it makes great sense to use the same
> underlaying mechanism for all mgmt interfaces.
>
>
>
> I could imagine some implementors planning to lean on the wire
> representation to compute hashes over the data as their ETag
> implementation. That would not be possible under this requirement, but
> ruling out that particular idea would not be problematic, imo.
>
>
>
> Long ago, I pondered this question for a while, but then I wasn't able to
> think of a use case where a client would benefit from a guarantee that all
> interfaces have common ETags, so I left it out in order to not produce a
> CLR. I'm not against adding this requirement if we can think of a
> reasonable reason why. Adding a requirement for CLI+GUI sounds hard in
> practice, though.
>
> I'm not against having Last-Modified in there. In fact, it was in the
> draft initially. Here's the justification why I removed it :-)
>
>
>
> + When I started the cost/benefit analysis for what I proposed, I soon
> found that it's not unimportant how many and how large ETag attributes are
> added to the payload. Having two mechanisms (i.e. both ETag and
> Last-Modified) doing pretty much the same thing started to look expensive
> in performance.
>
> + Since it's essential that the time stamp would have to be the same on
> all touched elements, all the components/subsystems/subagents involved
> would still have to be fed the exact time from the central management agent.
>
> I don't think this analysis is correct. A client connecting with 15
> servers in a network wide transaction would surely receive several
> differing timestamps. The times may be fairly close if NTP is running fine,
> latency is low, network and cpu load is even and the servers are running
> similar code, but they will rarely all be the same even with the low 1s
> Last-Modified resolution. If you allow clients to set the ETag in the
> request (which is trivial to allow), then the tags could be exactly the
> same across all servers (and known to the client before the request is even
> sent to the servers, allowing request pipelining).
>
>
>
> If-Unmodified-Since is what set me going with this whole draft, so
> obviously I value that mechanism highly. The fact that it works with
> timestamps worries me a bit, however.
>
>
>
> First, the resolution is pretty low, 1s. It is quite possible that a
> server could process more than one edit/POST in the same second, in which
> case this mechanism might indicate no change has taken place when in fact
> it has.
>
>
>
> Secondly, while the idea with timestamps and "unmodified since" is very
> convenient, it's also quite brittle. If a client ever sends an edit request
> to a server without using the If-Unmodified-Since, it may miss an update
> made by another client. The ETag mechanism does not have that issue.
>
>
>
> 1. Client A sends an edit to the server If-Unmodified-Since t0.
> Successful. Receives a Last-Modified timestamp t1.
>
> 3. Client A sends an edit to the server without If-Unmodified-Since. It
> just sets one tiny little leaf off in one corner. Successful. Received a
> Last-Modified timestamp t3.
>
> 4. Client A sends an edit to the server If-Unmodified-Since t3.
> Successful, but clobbers Client B's edit, leading to a misconfiguration,
> which opens a security hole.
>
>
>
> This is because the If-Unmodified-Since uses less than or equal in its
> test. The ETag mechanism is not susceptible to this issue, as it uses an
> equality test.
>
>
>
> Best Regards,
>
> /jan
>
>
>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 24 Mar 2022 23:24:30 +0000

Hi Jan,

> On Mar 24, 2022, at 4:37 PM, Jan Lindblad <[email-masked]> wrote:
> 
> f this isn't obvious, here's an example:

I don't think this example is valid.   Skipping past the obvious programming error, the equivalency you're trying to make applies to Etags too.

1. Client A sends an edit to the server If-Match e0. Successful. Receives a ETag e1.
2. Client B sends a an edit to the server. ETag on server is now e2.
3. Client A sends an edit to the server without If-Match. It just sets one tiny little leaf off in one corner. Successful. Received a ETag e3.
4. Client A sends an edit to the server If-Match e3. Successful, but clobbers Client B's edit, leading to a misconfiguration, which opens a security hole.

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Thu, 24 Mar 2022 23:33:29 +0000

> A timestamp could be added in the future if it is really important enough.

LastModified is drop-dead simple to do and achieves equivalency, no more justification is needed.

The same rules apply:

	- ETag is a MUST, LastModified is a MAY
	- root-node is a MUST, inner-nodes is a MAY

Kent

---

From: "Jan Lindblad (jlindbla)" <[email-masked]>
Date: Fri, 25 Mar 2022 08:45:24 +0000

Kent, Balazs,

The same rules apply:

I'm perfectly fine with this. Since we are in agreement maybe I should just stop here.

Since I noted that I haven't done a good job at explaining how the ETag mechanism works, let me take the example below and explain how this situation is avoided using ETags.

I also realized that servers supporting Last-Modified in deeper levels than just the root can do the same thing as I explain for ETags below.

Here's the same example again in some greater detail.

1. Client A edits server:/{eQ}ifs/{eR}interface[name="1/1/1"]{eZ}/... where {eX} means that the client asks the server to confirm the ETag value X sits at the path to the left before committing. Success. Server returns new ETag eB on / (the root), /ifs and interface 1/1/1.
2. Client B edits server:/acls[name="intf 1/1/1"]/... and server sets ETag eF on / and /acl intf 1/1/1.
3. Client A edits server:/users/user[name="joe"]/password without any ETag check. Server sets eY on / and /users.
4. Client A edits server:/{eY}acls[name="intf 1/1/1"]{eB}/... . Check eB fails (server has eF), edit aborted.

Best Regards,
/Jan

---

From: Kent Watsen <[email-masked]>
Date: Thu, 31 Mar 2022 15:20:59 +0000

[CC-ing NETCONF, as this discussion (and draft) belongs there.  To whomever replies to this message, please remove NETMOD from the CC-list.  Thanks!]

Hi Jan,

> I'm perfectly fine with this. Since we are in agreement maybe I should just stop here. 

The "rules" mentioned above are what RFC 8040 defines.  The same rules should apply to the NETCONF equivalent.   Which is to say, the draft that defines the NETCONF-equivalent should define support for both.

> Since I noted that I haven't done a good job at explaining how the ETag mechanism works, let me take the example below and explain how this situation is avoided using ETags.

<snip/>

Regarding the PROs and CONs of ETag vs LastModified, examples can be constructed showing each being better in cases.  As protocol-designers, the choice should be given to deployments.

Kent