[netconf] draft-ietf-netconf-transaction-id-00 review

["James Cumming (Nokia)" <[e-mail]>]

Hi Jan,

Sorry for the delay but I know I promised you a proper review of the transaction ID draft.

Thanks for the hard work on this one, I think it’s very useful.  The draft is well written and generally clear.

As a general comment I would like to see some more inline XML NETCONF operation requests and responses to illustrate some of the points inline.  I know there are a number of examples at the end and there are some diagram examples but sometimes seeing (short) actual request and response messages is useful to help understand the specific point being discussed.

It might also be useful to review RFC7951 for the proposed JSON encoding for any tools doing conversion as well (this might be as simple as saying these are treated the same way as metadata annotations).

I don’t particularly like the “!” etag option.  Have you considered the allocation of etags immediately, even in a candidate?  This would allow for txid operations (conditional) to happen on a candidate configuration as well.  These would be allocated on an edit-config/edit-data operation (and returned to the user) and could be overwritten with new ones on commit (and returned to the user) (comments below detail where this is referenced in the document currently).  I believe the NETCONF spec might need to be updated if the OK message is to be extended to allow additional information to be returned on a success message.  This approach might also lend itself quite well to RESTCONF if txid is going to be applied there as well (although I know that already has an etag and I’m not clear on the interactions between these two solutions – but perhaps that’s alright).

Some specific comments/observations below:


Introduction:


  *   The introduction doesn’t explicitly state that this draft will not discuss state (config false) data and it probably should.  I know this is a question that came up when I was discussing it with colleagues.  You can derive this from the spirit and content of the draft (particularly the last paragraph in section 3.2) but an explicit statement up-front might be beneficial.

Section 3 - NETCONF Txid Extension:


  *   The compare operation (RFC9144) isn’t mentioned here.  Do you have a view on how/if TxID should be used with this?

Section 3.2 – General TxID principles


  *   ‘Each server MUST maintain a txid metadata value for each configuration datastore’ but it is unclear where/how this is envisaged being stored.  The top-level element might be one place but really this is just another versioned node.  The entire datastore may a txid value added to the NMDA datastore itself but then this would need to be returned outside of any <config> item returned from a NETCONF operation.  Perhaps a section of entire datastore txid might be useful describing where it is stored and how it is interacted with.

Section 3.3 – Initial configuration retrieval


  *   You mention this ‘The exact encoding varies by mechanism, but all txid mechanisms would have a special "txid-request" txid value (e.g. "?") which is guaranteed to never be used as a normal txid value.’ In the second paragraph.  I believe you are intending to detail that sending the get-config/get-data request without a txid would return the configuration with no txid values, sending it with a txid of ‘?’ would return all of them and sending a specific txid would return those nodes with that txid?  Is this is the intention perhaps this section could include some updated wording and some examples of each.  If this is not the intention, perhaps just omitting the txid value in the request would return all txid values on a server that supports txid.  Receiving this data won’t hurt if you choose not to use it (other than the additional characters being streamed).
  *   In the note at the end you mention the proposed options for the format of a txid.  This might be useful in its own section, particularly the details about the values not being contiguous increasing numbers.  We should also cover attempts for txid collision avoidance.  You do have something more about this in section 4.1 but perhaps splitting this out and referencing it from both places might be good?


Section 3.4 – Subsequent configuration retrieval


  *   This section is probably the least clear in the document for me.  Could you provide some examples (XML inline for each bullet point) to explain the behaviour and the expected results.
  *   The second bullet seems to imply that the match is an inverse match.  i.e. getting with a specific txid would return things that do not match that txid.  Is that the intent?
  *   How does subtree filtering get involved here.  It seems some of this limiting config output based on specific txids may sit in the subtree filtering rather than the main operation.

Section 3.5 – Configuration retrieval from the candidate datastore


  *   We should add some wording here about how this might work with private candidates here.  In these there is a high likelihood that the data in the private candidate does not match the running (or global candidate for that matter).  I think this should be somewhat straight forward though, txid requests on a (any type of) candidate datastore would return data from the candidate datastore only.  It is possible that the txid value could change in a candidate through transactions not made by that session (global candidate or continuous rebase mode private candidates) but as long as this work targeting a (any type of) candidate returns data only from that candidate I don’t believe this creates any sort of issues.

Section 3.6 – Conditional transactions


  *   Typo in paragraph 3 (confiuguration)
  *   Paragraph 4.  I like the idea to return the new txid with the edit-config response.  I think this should be standard (mandated) behaviour for devices supporting txid.  You did mention a client could request this behaviour (but didn’t detail how) but I think if you just made this the default you wouldn’t need to.  This will also address the use of the “!” etag mentioned later.

Section 3.7 Transactions toward the candidate datastore


  *   I believe this section is equally valid for any type of candidate datastore (incl. privates) – perhaps we just rename the section slightly to “Transactions towards any type of candidate datastore”?
  *   I am not particularly keen on the “!” and its use (see the section top of this email), this is also only briefly covered in this section as a comment to a picture.  Perhaps a reference to where this is discussed in the document would be useful in this comment.

Section 3.9 – Other NETCONF operations


  *   Commit – You mentioned in section 3.6 that the client could request returning the new txid on commit.  Did you have in mind that this behaviour request would be made in the commit operation, if so we should probably mention that here.  I don’t think we should (see my comment in 3.6) but if you think this is the approach, you’d like to take maybe here is the right place in the document.

Section 4 – Txid mechanisms


  *   I am not a fan of the current statement in the last paragraph: “If a client uses more than one txid mechanism, such as both etag and last-modified in a particular message to a server, or particular commit, the result is undefined.”.  I think if this is going to be defined as a txid mechanism then we must define what happens when we use both.  Given that the txid etag approach is mandatory and the txid last-modified is optional, this feels a little like the last-modified should be written as an informational annotation rather than an actual txid mechanism.

Section 4.3.1 – Candidate datastore


  *   Typo in the second bullet “candidata"
  *   Second bullet – This means that when you submit a number of changes to the candidate they are assigned the etag “!” until <commit> when they are assigned their new values.  I believe the solution at the top of this email might be simpler and more flexible.

Section 7.2 – Unchanged configuration


  *   Typo in first line: ‘confiuration’


Thanks again for the work.

James