How to deal with IIAs where previous approval hash was not stored

[ipnreddy]

Some partners are storing approval hash of previously approved IIA only with V7. This brings up an issue. E.g. - Partner A does not have approval hash stored for an IIA (created in V6). Partner B has stored the hash on their end. Partner B makes a change and then wishes to revert. Since A does not have a hash - reversion is not possible. Proposed solution - When Partner B tries to revert, their system should pull the approval from partner A. If there is no hash in the approval response, Partner B's system should show an error saying that the IIA cannot be reverted. Partner A can then reapprove the edited IIA from Partner B. Request you to please confirm if the proposed solution would be acceptable.

[janinamincer-daszkiewicz]

Thank you Indira for creating this issue. We discussed the described scenario in the email correspondence and then during the technical workshop in Thessaloniki (February 19-20, 2024). However not everybody was present there, so it is better to leave conclusions in GitHub for further reference.

I will rewrite your scenario to make it fully clear for everybody.

Assumption: Partner A does not store IIA approval hash of partner B's copy under v.6 (this happens because partner A deletes an approval hash of B when partner B changes their copy)

1. Partner A approves copy IIA-v1 of Partner B and stores hash-v1 of this copy.
2. Partner B changes their copy to IIA-v2.
3. Partner A removes the approval hash-v1 from their system (withdraws the approval) - only under v6.
4. Partner A does not accept the change to IIA-v2, proposes some other changes.
5. Partner B does not accept Partner A's proposal and decides to revert to IIA-v1. This is not possible, because approval hash-v1 has been deleted. When Partner B gets an empty response to IIA Approval request, they -- inform their user about the problem (the user may want to contact the partner outside EWP), -- log the situation in the local log system to be able to trace if the situation repeats in the future.
6. Partner B proceeds as in the case when no approval has been done, and sends IIA CNR.
7. Partner A gets IIA-v1, approves it and stores the approval hash-v1.

I will add such scenario to my Excel file and will upload it here for review (during the coming weekend).

[skishk]

3. Partner A removes the approval hash-v1 from their system (withdraws the approval) - only under v6.

how could be possible? if i understand well partner A will always answer empty if partner B change the IIA to send a proposal? IIA-V1 is still approved during the negotiation of IIA-V2. when partner A approve IIA-V2 so now can delete approval on IIA-V1. right? because IIA-V1 is still in effect and working.

[demilatof]

3. Partner A removes the approval hash-v1 from their system (withdraws the approval) - only under v6.

how could be possible? if i understand well partner A will always answer empty if partner B change the IIA to send a proposal? IIA-V1 is still approved during the negotiation of IIA-V2. when partner A approve IIA-V2 so now can delete approval on IIA-V1. right? because IIA-V1 is still in effect and working.

Exactly, it was said that this should not happen. The problem is the revert scenario; there is no need of a reversion, it's enough to leave the amendments in place, both of the partners should know the mutually approved version. If there is the will to come back to them, it can be obtained editing again the IIA to the old values.

I think that in the above scenario, the main problem is not the lack of the hash code mutually approved, but the lack of a snapshot that prevents from sending an approval under version 7. If he/she has the snapshot, the hash code under v. 6 can be easily computed again.

[janinamincer-daszkiewicz]

I think that in the above scenario, the main problem is not the lack of the hash code mutually approved, but the lack of a snapshot that prevents from sending an approval under version 7. If he/she has the snapshot, the hash code under v. 6 can be easily computed again.

Correct guess. In that case both are missing - approval hash (has been deleted), snapshot (has not been stored under v6). It is also true that instead of revert the modification could took place. The advantage of revert over modify is that no re-approval is needed (under the condition that the previous approval is still available).

[demilatof]

Correct guess. In that case both are missing - approval hash (has been deleted), snapshot (has not been stored under v6).

I understand that hash can be deleted by mistake, but I don't understand why is it possible to choose to delete the hash; an approval cannot be withdrawn, it was never said. Instead, as it it stated here for almost three years

Get partner’s copy of the agreement, check the hash, send approval of this version to the partner and store the partner hash as the proof;

It's hard to understand what kind of proof could be if someone could decide to delete it. The possibility to amend an IIA should not be yet in production, therefore everyone could be advised to not delete the hash ever.

It is also true that instead of revert the modification could took place. The advantage of revert over modify is that no re-approval is needed (under the condition that the previous approval is still available).

I don't see any difference, the revert is only a kind of friendly help to satisfy a particular implementation of the partner. Without a new mutual approval (and this is the critical part) the previous mutual approval is the only one that gives validity to the IIA. We can revert but we can also not revert, without the need to give a new approval: the IIA that produces effects is always the old one that was mutually approved. If it was not so, we have to admit that as soon as we start to amend an IIA there is no more a valid mutually approved IIA and, as a consequence, no mobility should take place.

All that said, as I've experienced during the testing session with Dashboard (v. 6.3.0), I could also modify my copy editing the IIA with the same values it had when it was approved; this is a modification and not a revert, nevertheless, if I put the same values, the hash code is again the same and my partner can suppose I reverted, but I didn't.

But what is the business need for both of the parties to come back to the mutually approved IIA? We have the snapshot for any occurrence, the current IIA can evolve freely.

[janinamincer-daszkiewicz]

I understand that hash can be deleted by mistake, but I don't understand why is it possible to choose to delete the hash; an approval cannot be withdrawn, it was never said.

This problem has already been discussed at length by you and Umesh in this issue, let's not start this discussion again. The purpose of this thread is to make everyone aware that this can happen and that all systems need to deal with it. We should be able to conclude such IIAs, regardless of the circumstances.

revert is only a kind of friendly help to satisfy a particular implementation of the partner

I remember that in one of the threads you wrote 'I will never revert'. All right. I have seen the REVERT button in the Dashboard interface, but whatever button we have in our systems and whatever we call it what is important is the end result - we started negotiations, we made some modifications but at some point it's easy (from the user's perspective) to restore the last approved version.

[demilatof]

I understand that hash can be deleted by mistake, but I don't understand why is it possible to choose to delete the hash; an approval cannot be withdrawn, it was never said.

This problem has already been discussed at length by you and Umesh in this issue, let's not start this discussion again. The purpose of this thread is to make everyone aware that this can happen and that all systems need to deal with it. We should be able to conclude such IIAs, regardless of the circumstances.

And the problem is going to be here for years, without an official pronouncement. How can we conclude such IIAs without storing for ever an approval? What @skishk has asked is still without an answer. Scenario:

1. We have an IIA mutually approved
2. I modify my IIA and send you an IIA CNR
3. You delete my IIA hash code, that is you delete the proof that you have approved my IIA

Now let's forget revert or anything else. We simply stop here our activity. Looking at my system, I can claim that we have a mutually approved IIA and I can organize my nominations. You have nothing, you have deleted the IIA approvals, how could you accept my students? How can you organize your applications to send me your students? How can you claim I've said 10 places and not 5?

revert is only a kind of friendly help to satisfy a particular implementation of the partner

I remember that in one of the threads you wrote 'I will never revert'. All right. I have seen the REVERT button in the Dashboard interface, but whatever button we have in our systems and whatever we call it what is important is the end result - we started negotiations, we made some modifications but at some point it's easy (from the user's perspective) to restore the last approved version.

I agree, everyone is free to implement in his/her system an easy way to editing his IIAs. What I don't understand yet is the need to restore the last approved version. Do you mean that if we don't restore the last approved version we don't have a mutually approved IIA to organize our mobilities?

[janinamincer-daszkiewicz]

How can we conclude such IIAs without storing for ever an approval?

The problem will disappear after upgrading to v7, because in this system both approval hash and snapshot will be preserved. The problem, as I understand it, is because under v6 the approval hash was deleted after modifications.

I promised to prepare the scenario showing what happens and how to recover from this situation. I will uploaded the scenario before the evening.

What I don't understand yet is the need to restore the last approved version. Do you mean that if we don't restore the last approved version we don't have a mutually approved IIA to organize our mobilities?

I mean that when any of the partners started making modifications, this should conclude somehow - whether by approving the modifications (new approvals) or by withdrawing them (which means reverting to the last approved versions).

[demilatof]

How can we conclude such IIAs without storing for ever an approval?

The problem will disappear after upgrading to v7, because in this system both approval hash and snapshot will be preserved.

Could you kindly show me where is written that they have to be preserved forever after upgrading to v. 7? I only see that they have to be stored as a proof, the same sentence we had in the previous version, with the only difference that it was written about the only hash code. But this hasn't prevented someone from deleting the hash.

The problem, as I understand it, is because under v6 the approval hash was deleted after modifications.

If I'm not wrong, the modifications are considered only in v. 6.3.0 (never in production) and in v. 7.0 (not yet in production), therefore everyone should still have at least the hash code.

I promised to prepare the scenario showing what happens and how to recover from this situation. I will uploaded the scenario before the evening.

We don't need scenarios, we need clear rules. A little exception to the scenario brings to unknown state, a clear rule can help to face any new unpredictable situation.

What I don't understand yet is the need to restore the last approved version. Do you mean that if we don't restore the last approved version we don't have a mutually approved IIA to organize our mobilities?

I mean that when any of the partners started making modifications, this should conclude somehow - whether by approving the modifications (new approvals) or by withdrawing them (which means reverting to the last approved versions).

You don't answer my question: during the modification what is the network state? There is no rule that compels us to conclude or revert, we can stay in an indefinite state forever, nevertheless in the meantime the procedure regarding the already mutually approved agreement must be able to go, it doesn't matter if an when the current modified IIA will come to a new or old state.

[janinamincer-daszkiewicz]

Could you kindly show me where is written that they have to be preserved forever after upgrading to v. 7?

This is what the providers of this system told me.

If I'm not wrong, the modifications are considered only in v. 6.3.0 (never in production) and in v. 7.0 (not yet in production), therefore everyone should still have at least the hash code.

But as we were told not everybody has it. See the first post in this thread.

We don't need scenarios, we need clear rules. A little exception to the scenario brings to unknown state, a clear rule can help to face any new unpredictable situation.

Scenarios help in creating rules. In this particular case we need to decide what to do with such situations in the network which should not happen but have happened.

during the modification what is the network state?

If partner A keeps both approvals from his point of view IIA is mutually approved. If partner B deleted one of the approvals from his point of view IIA is not mutually approved.

[janinamincer-daszkiewicz]

@ipnreddy This is the promised Excel file 2024-02-25-DeleteModifyScenarios.xlsx. The scenario you outlined in the first post is numbered 19 (the last tab).

P.S. this file contains also two bug fixes and two other scenarios (numbered 17 and 18). The first tab shows a change log.

Comments are welcome.

[demilatof]

Could you kindly show me where is written that they have to be preserved forever after upgrading to v. 7?

This is what the providers of this system told me.

Do you mean that we will have a solution not thanks to the v. 7 specifications but thanks to the kindness of the providers of this system? And other unknown providers, with similar issues, what will they do?

If I'm not wrong, the modifications are considered only in v. 6.3.0 (never in production) and in v. 7.0 (not yet in production), therefore everyone should still have at least the hash code.

But as we were told not everybody has it. See the first post in this thread.

They are heavily in fault, the storage of hash code is mandatory for almost three years. It's not even clear if they haven't the hash for their IIA of for their partner's IIA. In both of the cases the real problem is that they have no element to prove that they arrived to a mutual approval, doesn't matter if we are discussing about revert or not.

I'm really sorry for their partners, but this means that all the IIAs exchanged by both are not formally mutually approved (or, if they accept anyway that they are mutually approved, they can go on as until now). No scenarios for them, they are out of the rules, they have to find an internal agreement to return inside the rules. The maintainers should simply write and recall clearly rules.

We don't need scenarios, we need clear rules. A little exception to the scenario brings to unknown state, a clear rule can help to face any new unpredictable situation.

Scenarios help in creating rules. In this particular case we need to decide what to do with such situations in the network which should not happen but have happened.

Yes, I agree, but scenarios help in creating rules during the alpha or beta releases, maybe during release candidate version. Not after the releasing of a stable version. In this case, if something relevant appears, it is mandatory to hurry up in rewriting rules, and this is not happening.

during the modification what is the network state?

If partner A keeps both approvals from his point of view IIA is mutually approved. If partner B deleted one of the approvals from his point of view IIA is not mutually approved.

This is not the network state, this is the state of each system from the point of view of the network. Because I'm ready to bet that each system is internally sure to be in a mutually approved state. The network state instead is indefinite, the network state is filled with errors; we cannot even know what they report to the stats system as concern the number of the mutually approved IIAs: they both claim to have a mutually approved IIA, but only one of them can prove the approval. The network rules should avoid an indefinite state.

[demilatof]

@ipnreddy This is the promised Excel file 2024-02-25-DeleteModifyScenarios.xlsx. The scenario you outlined in the first post is numbered 19 (the last tab).

P.S. this file contains also two bug fixes and two other scenarios (numbered 17 and 18). The first tab shows a change log.

Comments are welcome.

My first comment: scenarios can help you to keep track of issues, but I cannot implement a system using scenarios, the reverse engineering is not the best approach but only the last resort. I need, but I think we all need, clear and written rules and not scenarios that even are split inside in more sub-scenarios; we have now 19 scenarios, most of them useless for me, but I have to deeply study just to realize that they satisfy the particular needs of some systems or bad implementation of other systems.

I limit my consideration to only the last scenario, recalling that during IF it was clearly stated that "To modify an IIA which has been mutually approved, HEIs SHOULD take a snapshot of the last approved version to be able to revert to it if they don't conclude a new approved version of the agreement".

When at row 12) you write "new approval hashes*: A0.iia-hash0, B0.iia-hash0" are we sure that A has the snapshot of A0? Do we know if A has the snapshot of B0 taken when there was a mutual approval? (in the scenario B0 has not changed, but it could be). Without the snapshots there are not iia-hashes.

Rows 18 to 22, two useless sub-scenarios: A can call B's IIA Approval for whatever reason (with or without an Approval CNR) and sending or not an IIA Get. In any case, A can always claim that there is a mutual approval, but it can anymore receive a confirmation from B (IIA Approval).

After many years, I still see the same conceptual error (row 25): "B likes it because A0 is equal to his copy, so B decides to approve A0." In the master-master model, there is no warranty that A0 is equal to B copy; it may be similar, it may be different. The reality is that B approves because it is simply "compatible" with its proposal. Therefore in this scenario once B has deleted A0.condition-hash0 it has deleted all it knows about the A's IIA: there are no differences if A reverts or not, for B it is a new IIA to approve, no more to say: A1 or A0 doesn't matter.

And last but not least: you depict a scenario across v6 and v7 version. B could even not delete A0.condition-hash0, but if it hasn't the A0 snapshot B cannot compute iia-hash0 and therefore (after switching to v7) when A calls IIA Approval on B, B will answer with an empty response as if A0 is not approved or giving a completely wrong iia-hash (e.g. the condition hash instead of the iia-hash).

This is the huge real problem!

[janinamincer-daszkiewicz]

When at row 12) you write "new approval hashes*: A0.iia-hash0, B0.iia-hash0" are we sure that A has the snapshot of A0? Do we know if A has the snapshot of B0 taken when there was a mutual approval? (in the scenario B0 has not changed, but it could be). Without the snapshots there are not iia-hashes.

I omit mentioning snapshots in this and other scenarios. Of course snapshots are a must starting from 6.3 when modification has been introduced.

Rows 18 to 22, two useless sub-scenarios: A can call B's IIA Approval for whatever reason (with or without an Approval CNR) and sending or not an IIA Get.

From the point of A these are two different scenarios and I wanted to highlight this fact. In scenario 1 A starts with IIA Approval request and after getting empty response knows that something bad happened. In scenario 2 A starts with IIA get and continues as no error would happen.

In any case, A can always claim that there is a mutual approval, but it can anymore receive a confirmation from B (IIA Approval).

A can claim until A gets an empty response from B to IIA Approval request. Yes, we know that this should not happen, but we also know that in some systems it happens. The whole scenario is for showing how to recover from such situation,

In the master-master model, there is no warranty that A0 is equal to B copy; it may be similar, it may be different. The reality is that B approves because it is simply "compatible" with its proposal.

You call it compatible, I call it equal. I hope it is clear that the users decide what they want to approve. The more important issue is (we should be aware of that and take it into account) that some of the systems do not allow to approve copies which are not 'equal' why the others allow the copies to differ. This was discussed during the technical workshop in Thessaloniki.

And last but not least: you depict a scenario across v6 and v7 version.

Yes because the problem we consider in this scenario is related to it. If we would start the scenario in version 7 there would be no problem because B would store hash and snapshot.

B could even not delete A0.condition-hash0, but if it hasn't the A0 snapshot B cannot compute iia-hash0 and therefore (after switching to v7) when A calls IIA Approval on B, B will answer with an empty response as if A0 is not approved or giving a completely wrong iia-hash (e.g. the condition hash instead of the iia-hash).

Scenario describes what happened. Under v6 B deleted hash and B does not have stored a snapshot. After switching to v7 B still does not have hash nor snapshot. Only after B calls IIA get under 7, B starts behaving as expected and saves hash and snapshot.

[demilatof]

Rows 18 to 22, two useless sub-scenarios: A can call B's IIA Approval for whatever reason (with or without an Approval CNR) and sending or not an IIA Get.

From the point of A these are two different scenarios and I wanted to highlight this fact. In scenario 1 A starts with IIA Approval request and after getting empty response knows that something bad happened. In scenario 2 A starts with IIA get and continues as no error would happen.

I don't understand what is the difference... A cannot conclude that B is not interested in their proposal just because B0 is not changed; maybe that B is still examining A's changes... This is a completely wrong approach, A cannot make any assumption from receiving the same IIA just because it keeps on polling its partner.

And I could add that B might have changed something (sending or not an IIA CNR) and so A could get B1 via an IIA Get and not B0. What can B suppose now? Do we need another scenario?

A can claim until A gets an empty response from B to IIA Approval request. Yes, we know that this should not happen, but we also know that in some systems it happens. The whole scenario is for showing how to recover from such situation,

A can claim forever, if it has the approval response HTTP signed and the full IIA fetched from B, HTTP signed too and with identical hash. The problem is that something has gone wrong in getting approval, but this happens in the same way both in row 20 and 22, whilst you write two different conclusions. Even if A is convinced that B is not interested in their proposal, and revert, it cannot have the following situation

approval hashes: A0.iia-hash0, B0.iia-hash0

because if A calls B's IIA Approval, A keep on receiving an empty approval. What A makes or supposes cannot change anymore what B has done, the approval of A0 is lost and the approval remains empty

You call it compatible, I call it equal. I hope it is clear that the users decide what they want to approve. The more important issue is (we should be aware of that and take it into account) that some of the systems do not allow to approve copies which are not 'equal' why the others allow the copies to differ. This was discussed during the technical workshop in Thessaloniki.

In IT "equal" has a strong meaning, and this meaning is not explicitly considered by the EWP specification. Obviously, when IIAs are compatible, they can accept, but not impose, that they are also equals, whilst saying that IIAs are equals exclude the possibility that they are only similar. What does it means that it means that we should be aware of that and take it into account, that some of the systems do not allow to approve copies which are not 'equal' ? My IRO must force their IIA just to satisfy partner's system? And how these providers detect that they are equasl? Field by field?

When you write "B likes it because A0 is equal to his copy, so B decides to approve A0" most probably you stop writing a scenario for the community and start writing a scenario for a particular system. At this point, much better give a name and surname to the scenario, that is the name of the provider, so that we consider the scenario only when we deal with that provider.

Yes because the problem we consider in this scenario is related to it. If we would start the scenario in version 7 there would be no problem because B would store hash and snapshot.

And this confirms that provider B currently has no snapshot, therefore it is false that all the approvals will be kept valid switching to version 6, as promised; at least for all the partner's of the HEIs that are using this provider's system. Are you sure that in version 7 all providers will keep hash and snapshot? It was required in version 6 for hashes, but as we have just seen, somebody has not stored it permanently.

Scenario describes what happened. Under v6 B deleted hash and B does not have stored a snapshot. After switching to v7 B still does not have hash nor snapshot. Only after B calls IIA get under 7, B starts behaving as expected and saves hash and snapshot.

This means that the approvals under v6 for B and A are lost (and for all the B's partners). Just to highlight what is not expressly said.

[janinamincer-daszkiewicz]

What A makes or supposes cannot change anymore what B has done, the approval of A0 is lost and the approval remains empty

This is true and this is the reason A has to accept that fact and conclude the negotiations on this IIA somehow anyway. We are talking about the ways of recovery from the erroneous situation.

What does it means that it means that we should be aware of that and take it into account, that some of the systems do not allow to approve copies which are not 'equal' ? My IRO must force their IIA just to satisfy partner's system?

Yes, IROs have to agree on the version of IIA which can be approved by both systems. Even when one is more strict and the other more flexible.

And how these providers detect that they are equasl? Field by field?

For example by comparing XMLs. I invite providers who does that to share information on their implementation.

At this point, much better give a name and surname to the scenario, that is the name of the provider, so that we consider the scenario only when we deal with that provider.

There may be more than one system implemented that way.

Are you sure that in version 7 all providers will keep hash and snapshot? It was required in version 6 for hashes, but as we have just seen, somebody has not stored it permanently.

I hope it will be checked during the acceptance testing with the Dashboard.

This means that the approvals under v6 for B and A are lost (and for all the B's partners).

Yes, A represents any partner of B in this scenario.

[janinamincer-daszkiewicz]

Thank you for discussion. In row 20 I changed 'approval hashes: --, B0.iia-hash0' to 'approval hashes: A0.iia-hash0 (but B refuses to confirm), B0.iia-hash0'. In row 25 I changed 'equal' to 'equivalent'. The file with scenarios will be uploaded to https://github.com/erasmus-without-paper/ewp-specs-api-iias/tree/stable-v7/scenarios-v6-v7.