Issues found in the GDS Push Management|OPC UA Standard|Forum|OPC Foundation

We found some issues and inconsistencies in the OPC UA specification regarding GDS Push Management which I will outline here:

• The transaction part of TrustLists in Figure 22 at https://reference.opcfoundatio...../docs/7.10 does not fit to the descriptions of Open(Write+EraseExisting) and CloseAndUpdate(). The creation of a new transaction is depicted at "Open()" while it is described to be at "CloseAndUpdate()".
• There is a misnomer in the description of "CloseAndUpdate()" at https://reference.opcfoundatio.....cs/7.8.2.3 - the result code "Bad_ChangesPending" does not exist and it should be "Bad_TransactionPending" instead.
• The description of "UpdateCertificate()" at https://reference.opcfoundatio.....ocs/7.10.4 lacks mentioning the "Bad_TransactionPending" result code. I expect the figure above is correct in that regard because it just makes sense.
• There is a potential deadlock when manipulating TrustLists via the File-API: Consider clients A and B. According to the specification they are both allowed to open distinct TrustLists objects concurrently for writing. Eventually Client A has finished writing and calls "CloseAndUpdate()". This will create a new transaction - so far so good.
  But now there is the following situation: if Client A calls "ApplyChanges()" it will get an "Bad_InvalidState" according to https://reference.opcfoundatio.....ocs/7.10.6 ("ApplyChanges returns Bad_InvalidState if any TrustLIst is still open for writing."). And also Client B cannot do anything meaningful, because calling "CloseAndUpdate()" should give it "Bad_TransactionPending" in this case (even if not mentioned at https://reference.opcfoundatio.....cs/7.8.2.3). The only resolution here is that either Client A calls "CancelChanges()" or closes its session or Client B calls "Close()" or closes its session, or the ActivityTimeout" triggers (which eventually closes the trust list of client B).
  -> Is this behaviour really desired? Would it make sense to just drop the any-trust-list-is-open-for-writing restriction in "ApplyChanges()" so that Client A can finish its change?
• Shall it be possible to concurrently open the same TrustLists object for reading or not? When reading the descriptions of "OpenWithMasks()", "AddCertificate()" and "RemoveCertificate()" it sounds like this would be desired. Nevertheless, "OpenWithMasks()" states the following "Bad_InvalidState - The TrustList has already been opened" without restricting this statement to "for writing".
  So does this mean now, that a TrustList can only be open once at any point in time (so the condition "OpenCount" <= 1 always holds)?
• "RemoveCertificate()" as currently specified may lead to a TrustList whose contents would be rejected if written through the File API - for example after removing a CA certificate other certificates in the TrustList depend on. Is this desired?
• In general it would be great, if all result codes, that are mentioned in the method descriptions, are also listed in the Method Result Codes table below the Signature table. It would make the interface easier accessible and reduces the risk of overseeing potential error paths.

Kind regards,
Marcel