Use case described in 1) does not take into account that none of the connection are to be create if any of them fails. ConnectionConfigurationSets are processed as a unit, so separating them into enable and not enable break this unit and could cause multiple other problems.

This option is one of three enumeration, it is the one that would be used by a knowledgeable configuration expert /well designed tool. This is not about an engineer making a mistake, there are many other mistakes an engineer could make, such as setting intervals incorrectly (keep alive vs handshake etc.) again a well designed engineering tool would prevent this - so we do not add code to AC or CM to to check or overwrite this.

If we are worried about being able to debug what configuration is pushed down - the simpler solution is to require CommunicationModelConfigurationType be exposed instead of leaving it as optional (this could be done in a profile, if not in the specification). Actually the more I look at this I think leaving it as optional is a mistake, and maybe your entire discussion on diagnostic would go away. I can actually think of many other diagnostic difficulties that could result if this is not exposed.

I think the additional interface does not help matter and I don't believe it is only a C2D issue, in the process world that are many case where communication is configured, but not enable until needed (for example in batch processing). [note enabling a single writer or reader is something that one can already do via the PubSub interfaces, if they are exposed, so again maybe the solution is to require that these interface be exposed, so that an application could enable communication or disable it as needed - i..e not just a connectionmanager.]

This issue can be discussed, but I would not change the numeration option, but if diagnostics is a major issue I would instead mandate the communicationconfiguration be exposed and optionally the PubSub configuration . I would also feel that this issue has been discussed for a long time when the enumeration was decided and revisiting that issue again, when no actual problem exist may be counter productive to getting the specification actually released, so the best solution is a "No Change Required"

Use case described in 1) does not take into account that none of the connection are to be create if any of them fails.
ConnectionConfigurationSets are processed as a unit, so separating them into enable and not enable break this unit and could cause multiple other problems.

Correct. And yet, this use-case has never been discussed in detail, and we may be even missing more requirements. It only came up when we discussed the value of the enabled flag for PubSub elements when we discovered that this use-case was not possible with the current CM interface.
There is also no written use-case / requirement / Mantis issue that I am aware of -> Even now, we may not know fully, what the requirements are exactly.
What we know is: As currently specified, this use-case make use of a feature that uses EstablishConnections() in a communication-model specific manner, rather than using the FX connection abstraction provided. Which may cause errors that are difficult to diagnose.
The use-case itself, does not seem to warrant having such an implementation in the field. I would rather add this feature in a subsequent version of the spec. The interface on the AC allows this use-case and it is only a matter of creating additional methods on the CM to make it possible.

Even considering that an automatic rollback for CCS that are split into multiple ones, will not work, this use-case could be solved for C2C MVS by other means:

1) An application (e.g. standard OPC UA client or vendor-specific tool) using the methods of the CM, may be aware of the requirement, that 2 distinct CCSs are supposed to be treated as 1 (e.g. the system integrator may know this) - and call CloseConnections(Remove = true) on both CCs, if 1 or both fail to establish.
2) For C2C MVS, the ET and CM are considered to come from the same vendor. It is a matter of making this kind of use-case configurable in a vendor's engineering tool. The CM may then use CM.ProcessConnectionConfigurationSets(ActionEstablishConnectionsDisabled, Ccs) and a subsequent AC.EstablishConnections(connectionsToEnable).
The interface on the CM was always meant to be used by external OPC UA Clients (the system integrator). A CM implementation that automatically establishes connections on startup, will probably use internal functions, rather than connecting to its own Server-interface and calling OPC UA Methods. So it is free to call AC.EstablishConnections(EnableCommunicationCmd) to support this use-case.

A subsequent version of the specification may solve this use-case like so:

1) Use existing method ProcessConnectionConfigurationSet(ActionEstablishConnectionsDisabled, Ccs) to establish all connections in the CCS in a disabled state, making use of potential rollback.
2) Subsequently use a newly defined method "ConnectionConfigurationSetType.Process(FxProcessEnum, connectionsInCcsToProcess)" -> this could even make use of the existing enum, since all of them are applicable to single connections as well.

This option is one of three enumeration, it is the one that would be used by a knowledgeable configuration expert /well designed tool.
This is not about an engineer making a mistake, there are many other mistakes an engineer could make, such as setting intervals incorrectly (keep alive vs handshake etc.) again a well designed engineering tool would prevent this - so we do not add code to AC or CM to to check or overwrite this.

The expert using the (engineering) tool may not be the same as the one using an OPC UA Client to call methods on the CM. This is not about relying that experts dont make mistakes. It is about avoiding the consequences if mistakes do happen despite experts using a system.
Considering that we can solve this use-case in a well-designed manner in a future version of the spec, and that work-arounds exist to solve it in the current one (see above), it seems counter-productive to realize this use-case as currently specified.

We may inquire at the FA/PA team and/or SC, WG Arch, about whether this use-case is important enough for C2C MVS to warrant potential problems in the field.

If we are worried about being able to debug what configuration is pushed down - the simpler solution is to require CommunicationModelConfigurationType be exposed instead of leaving it as optional (this could be done in a profile, if not in the specification). >Actually the more I look at this I think leaving it as optional is a mistake, and maybe your entire discussion on diagnostic would go away. I can actually think of many other diagnostic difficulties that could result if this is not exposed.

I support the proposal of making it mandatory to expose the PubSubConfiguration used, but if, then only as binary file that can be downloaded on demand (RAM). At least for B&R, RAM consumption in combination with OPC UA is an issue - we'd have to find a solution that does not require the whole file to be loaded into RAM upon download.
This solves the diagnostic issue, but it does not solve the potential for errors. It also does not solve, that EstablishConnections() is being used in 2 different ways to enable connections - via the abstraction of FX connections, and via the communication model directly. This is a design issue. Proper design from the start avoids incorrect usage and many potential problems that can occur otherwise. We may not even have the complete picture of the potential error cases yet.

I think the additional interface does not help matter and I don't believe it is only a C2D issue, in the process world that are many case where communication is configured, but not enable until needed (for example in batch processing).
[note enabling a single writer or reader is something that one can already do via the PubSub interfaces, if they are exposed, so again maybe the solution is to require that these interface be exposed, so that an application could enable communication or disable it as needed - i..e not just a connectionmanager.]

ad C2D vs C2C: If this is a use-case that must be solved for C2C, then there should be or should have been an explicit document requirement for it (I am not aware of one). As of now, we are discussing a use-case that has not been considered in the design, when we are already at the stage of an RC2. We should not sacrifice design for a use-case that was not considered from the beginning.
The additional interface I outlined above, should solve this use-case (we may discuss if you think it does not - but the point is: EstablishConnections() allows this use-case, so it is a matter of the interface on the CM side only, to support this as well) and can easily be added in a subsequent version of the spec.

This issue can be discussed, but I would not change the numeration option, but if diagnostics is a major issue I would instead mandate the communicationconfiguration be exposed and optionally the PubSub configuration . I would also feel that this issue has >been discussed for a long time when the enumeration was decided and revisiting that issue again, when no actual problem exist may be counter productive to getting the specification actually released, so the best solution is a "No Change Required"

I do not agree: members of the group have pointed out the problem / design issue with allowing this, from the time when this was first discussed.
If we have possibilities to solve this problem with vendor-specific work-arounds now and specify a technically well-designed a solution for v1.x, we should do that, rather than having a "specified" work-around.

I propose to remove this enum constant completely for v1.0, and extend the CM interface with the outlined Method (or something similar to be discussed) to solve this use-case in a subsequent version.
In addition I propose, that the Enabled flag for all new PubSubConfiguration elements (ElementAdd), shall be set by the AC, rather than the CM. This would have the added benefit, that even 3rd party Clients of EstablishConnections() would use the method according to how it was designed.

Agreed to no changes to this issue

reviewed in call - agreed to close this issue