Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)
[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, >> The same rules apply: >> >> - ETag is a MUST, LastModified is a MAY >> - root-node is a MUST, inner-nodes is a MAY > > 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. 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 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)
Kent, Balazs,
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.
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
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.
f 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.
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.
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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)
> 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. 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 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)
Hi Jan, > On Mar 24, 2022, at 4:37 PM, Jan Lindblad wrote: > > f 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. 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 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)
On Thu, Mar 24, 2022 at 1:52 PM Balázs Lengyel 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 element in certain cases. (It is useful to expose the config-id in , 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. > Regards Balazs > Andy > > > *From:* Jan Lindblad > *Sent:* Thursday, 24 March, 2022 21:38 > *To:* Andy Bierman ; Balázs Lengyel < > balazs.leng...@ericsson.com>; Kent Watsen > *Cc:* netmod@ietf.org > *Subject:* Re: [netmod] Common etag, timestamp on all interfaces > (draft-lindblad-netconf-transaction-id) > > > > Andy, Balazs, Kent, > > > > Thanks for your very good questions. Comments inline. > > 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. > > 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 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. > > > > Yes, I certainly like that. > > 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'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 inv
Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)
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 Sent: Thursday, 24 March, 2022 21:38 To: Andy Bierman ; Balázs Lengyel ; Kent Watsen Cc: netmod@ietf.org Subject: Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id) Andy, Balazs, Kent, Thanks for your very good questions. Comments inline. 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. 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 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. Yes, I certainly like that. 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'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). 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. If-Unmodified
Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)
Andy, Balazs, Kent, Thanks for your very good questions. Comments inline. > 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. > 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 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. Yes, I certainly like that. > 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'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). > 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. 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
Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)
On Wed, Mar 23, 2022 at 4:33 PM Balázs Lengyel wrote: > *From:* Kent Watsen > *Sent:* Thursday, 24 March, 2022 00:05 > *To:* Balázs Lengyel > *Cc:* netmod@ietf.org > *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. > > Regards Balazs > > > > Kent // contributor > > > Andy > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)
From: Kent Watsen Sent: Thursday, 24 March, 2022 00:05 To: Balázs Lengyel Cc: netmod@ietf.org 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. 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. Regards Balazs Kent // contributor ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
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. > 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. > Regards Balazs Kent // contributor ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
