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

["Jan Lindblad (jlindbla)" <[e-mail]>]

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