Terminate/modify functionality for approved IIAs

[janinamincer-daszkiewicz]

As requested during the Infrastructure Forum meeting on 2022-12-14 I closed old issues and have create this one to finalize the discussion on functionality to terminate/modify approved IIAs.

[janinamincer-daszkiewicz]

Copied from https://erasmus-plus.ec.europa.eu/resources-and-tools/inter-institutional-agreement

Termination of the agreement

It is up to the involved institutions to agree on the procedure for modifying or terminating the inter-institutional agreement. However, in the event of unilateral termination, a notice of at least one academic year should be given. This means that a unilateral decision to discontinue the exchanges notified to the other party by 1 September 20XX will only take effect as of 1 September 20XX+1. The termination clauses must include the following disclaimer: "Neither the European Commission nor the National Agencies can be held responsible in case of a conflict.”

Proposal for unilateral terminate:

• We add a new attribute of IIA, named \<termination-date>.
• It will be placed at the end of \<iia> as optional.
• We add parameter to IIA index and IIA get requests: include-terminated (optional) default YES; if given and value is NO, then the server should not send terminated IIAs.

Scenario

• Partner A decides to unilaterally terminate IIA approved by A and B.
• Partner A adds termination-date to IIA, sends IIA CNR to partner B.
• Partner B calls IIA get, finds the termination-date.
• Partner A would like to get some confirmation from B that he got the A's decision (equivalent to acknowledgment of receipt). If we do not want to add new API we can use IIA Approval.
• Partner B sends IIA Approval CNR.
• Partner A calls IIA Approval get. The response contains:

\<approval> \<iia-id>iia-id of the copy terminated by A\</iia-id> \<conditions-hash>original hash of the approved copy terminated by A\</conditions-hash> \<termination-date>repeated termination date\</termination-date> \</approval>

Proposal for modify/amend Below I describe two options, we may choose either one of them, or both, or none.

Option 1 (agree to changes which are not recorded in local systems) Partner informs us in the comment that exceptionally they would like to send 1-2 more/less students.

1. If we don't mind, we agree (in the comment).
2. Do we have to re-approve such IIA? What would we do in the old paper time?
3. The BPOs answered - nothing, the paper version would stay as it was. No need to re-approve.

We agree to some flexibility (if the users want it and both agree).

Option 2 (changes need to be recorded in local systems)

1. Amendments can be done by changing the IIA Get response and have the change confirmed by both partners . Server implementers should be required to keep all logs (snapshots) and therefore be able to find the original partner IIA before amendment, if need be.
2. Disapproval would follow the same logic as disapproval of IIAs before they have been mutually approved. Partner B would inform partner A that they do not agree to the changes and would either ask partner A to revert their IIA Get to the approved version, or, if an amendment has been agreed on, they would specify what changes partner A has to do before partner B confirms the amendment.
3. We should distinguish between unilateral termination versus termination agreed by both parties. In the first case the party unilaterally terminating an IIA will need to have a proof that it informed the counterparty at least one year in advance. In the second case, we need the approval of the counterparty.

[janinamincer-daszkiewicz]

No comments for this proposal? Terminate/modify is the most important functionality users need.

[demilatof]

My 2 cents...

* We add a new attribute of IIA, named <termination-date>.

I think that the termination-date may be useful, but ambiguous. What does it represent? The date when we agree to terminate the IIA or the date when the IIA will terminate? In both of cases it is not enough: we need the last academic year of validity.

E.g.: termination-date=4 march 2024 The cooperation condition for 2024/25 will be valid or not? Is 2024/25 the last academic year of validity? We open the applications on February for 2024/25, maybe others have different dates. .

Much better if we explicit the last valid academic year with a further element: <last-valid-academic-year>

* We add parameter to IIA index and IIA get requests: **include-terminated** (optional) default YES; if given and value is NO, then the server should not send terminated IIAs.

Here we may have another ambiguous point: an IIA may be unilaterally terminated, but even naturally terminated (e.g. an IIA from a.y. 2022/23 to 2022/23 is already terminated). If someone asks us to include terminated IIA in the index, should we list only unilaterally terminated or even the naturally terminated? Presently the index shows all IIAs (valid or naturally terminated), why should we manage differently for unilateral terminated?

We already have the _receiving_academic_yearid parameter to retrieve all the IIAs valid in the given set of academic years.

As concerns IIA-Get, what is the interest in specify include-terminated? We already fetch the IIA by its IIA-Id, terminated or not. We download it and then we can read from it if it is terminated. Adding include-terminate in IIA-Get would only add extra work for us.

• Partner A would like to get some confirmation from B that he got the A's decision (equivalent to acknowledgment of receipt). If we do not want to add new API we can use IIA Approval.

In my opinion, a dangerous choice as I'm going to explain.

* Partner B sends IIA Approval CNR.

* Partner A calls IIA Approval get. The response contains:

iia-id of the copy terminated by A original hash of the approved copy terminated by A repeated termination date

And so we will finish to have not only the same problem we already have for an IIA obsolete, but even:

• Now someone can approve the wrong date (giving approval for an IIA with the previous hash code)
• Someone can inject a cooperation-condition change together with the termination-date. We think to approve a termination whilst we approve a change too.

Last but not least: what happen if the termination is not approved by both parties for a whatever reason?

Proposal for modify/amend Below I describe two options, we may choose either one of them, or both, or none.

Option 1 (agree to changes which are not recorded in local systems) Partner informs us in the comment that exceptionally they would like to send 1-2 more/less students.

Haven't you said:

I do not suggest comments, we will not introduce them.

So, you'll introduce or not comments? If you'll not, as I hope, this option ends here. Anyway comments are dangerous, they could be in contrast with cooperation conditions, not considered by the condition-hash and so on.

Option 2 (changes need to be recorded in local systems)

We have to be more accurate about what we can change in an approved IIA. E.g.: we have a students-studies-mobility from a.y. 2022/23 to 2027/28, 6 places each year. If we want to reduce the places from 6 to 4 it would be wrong to write 4 where there was 6, because in the past years (and maybe in the currently opened position) we had 6 places and we cannot reduce them. Moreover, once approved, we will lost any reference to what was happened in the past (even as proof).

My proposal: specification must address the developers to split the involved cooperation conditions, so that in the above example we have:

• The old students-studies-mobility element, with 6 places and academic years from 2022/23 to 2023/24 (for example)
• The new student-studies-mobility element, a clone of the above mobility, with 4 places (as agreed) and academic years from 2024/25 to 2027/28.

Do we know if all providers can edit an approved IIA and manage a second Approval for their IIA or partner's IIA?

[Belenchusky]

My small contribution to this topic:

I think I understand all the allegations that @demilatoff makes to the proposal and I share his point of view.

Summarizing:

• I prefer a or , not a date.
• Option 1 not necessary and complicates the process.
• Option 2, we need to be able to see in the new IIA GET call, the complete IIA information and how it looks after its modification without having to merge the old and new version.

[demilatof]

• Option 2, we need to be able to see in the new IIA GET call, the complete IIA information and how it looks after its modification without having to merge the old and new version.

I think that splitting the mobility that needs a change could be the best way to see the old version (e.g. until 2022/23) and the new version (e.g. after 2022/23). I mean splitting the mobility inside the same IIA, not having 2 IIA (one for old mobility and another for the new one)

The question is: are we all able to manage a mobility that has different conditions from year to year? That is, for example, in the same IIA 4 places for two academic years, then 2:

[umesh-qs]

For modifying approved IIAs why can't we just restart the approval process with new changes? Everyone will anyways have all the logs. Why do we need to complicate this?

[demilatof]

For modifying approved IIAs why can't we just restart the approval process with new changes? Everyone will anyways have all the logs. Why do we need to complicate this?

This is not a huge complication, but this has even legal consequence. We are sharing the agreement that until a given date we have some conditions whilst now we have other conditions.

From my personal point of view: if we change the cooperation conditions for the same IIA-ID we affect our internal system, first of all we could have problems with tools that check that EWP IIAs and internal IIAs are the same

PS: of course I think to restart the approval process, but splitting the cooperation conditions that we need to change

[umesh-qs]

For modifying approved IIAs why can't we just restart the approval process with new changes? Everyone will anyways have all the logs. Why do we need to complicate this?

This is not a huge complication, but this has even legal consequence. We are sharing the agreement that until a given date we have some conditions whilst now we have other conditions.

@demilatof This will be done with knowledge of both partners. It is not going to be unilateral. So I do not see any legal complication here

From my personal point of view: if we change the cooperation conditions for the same IIA-ID we affect our internal system, first of all we could have problems with tools that check that EWP IIAs and internal IIAs are the same

@demilatof yes it will and that should be ok. But all this is when partners agree between them and there is a history to check if in case of any disagreement.

PS: of course I think to restart the approval process, but splitting the cooperation conditions that we need to change

@demilatof I am not sure if we are ready for a complex solution. We do not recommend having change history within IIA GET. You can always have change log internally and show it to the end users.

[mkurzydlowski]

Much better if we explicit the last valid academic year with a further element: <last-valid-academic-year>

Good point! I agree.

We already have the _receiving_academic_yearid parameter to retrieve all the IIAs valid in the given set of academic years.

Also good point! I agree to using this parameter to filter out terminated IIAs.

As concerns IIA-Get, what is the interest in specify include-terminated? We already fetch the IIA by its IIA-Id, terminated or not. We download it and then we can read from it if it is terminated. Adding include-terminate in IIA-Get would only add extra work for us.

I think that IIA Get wasn't really foreseen for the original proposal. I agree that no changes for it are needed.

And so we will finish to have not only the same problem we already have for an IIA obsolete, but even:

• Now someone can approve the wrong date (giving approval for an IIA with the previous hash code)
• Someone can inject a cooperation-condition change together with the termination-date. We think to approve a termination whilst we approve a change too.

This should be clearly distinguished in the client implementation, so no mistakes are being made.

I must admit that there is some complication here but that seemed the simplest solution for that business requirement.

However, I'm not quite sure why it isn't proof enough if the partner gives the same last-valid-academic-year in his IIA and we make a snapshot of it...

Last but not least: what happen if the termination is not approved by both parties for a whatever reason?

If it is not approved then he will probably want to call the partner. We would do the same for normal approval, I think.

As for the modification of IIA, I agree with Umesh:

For modifying approved IIAs why can't we just restart the approval process with new changes? Everyone will anyways have all the logs. Why do we need to complicate this?

And his latest answers.

I'm always for the simplest solution - so it seems. Maybe this will prove satisfactory?

Do we know if all providers can edit an approved IIA and manage a second Approval for their IIA or partner's IIA?

I don't see any technical issues they might have, although they will probably need to add this functionality in their current implementation.

[janinamincer-daszkiewicz]

After Infrastructure Forum meeting on 2023-01-18

Here we consider IIAs approved by both partners.

Unilateral terminate

Proposal

1. We add a new attribute of IIA, named last-valid-academic-year.
2. It will be placed at the end of as optional.
3. Partners can use receiving_academic_year_id to filter out terminated IIAs.

Scenario

1. Partner A decides to unilaterally terminate IIA approved by A and B.
2. Partner A adds last-valid-academic-year to IIA, sends IIA CNR to partner B.
3. Partner B calls IIA get, finds the last-valid-academic-year.
4. Partner A would like to get some confirmation from B that he got the A's decision (equivalent to acknowledgment of receipt).
5. Partner B adds last-valid-academic-year to IIA, sends IIA CNR to partner A.
6. Partner A calls IIA get, finds the last-valid-academic-year. This is the confirmation A needs.

Comments

• Needed changes in specification of IIA API and in implementation

Modify/amend

1. We keep in a system an approved agreement A1 but in real life we allow some exceptions (both partners should agree)

• to be confirmed by DG EAC/BPOs
• no changes in specification/software needed

3. We terminate an approved agreement A1 and start working on an agreement A2

• available after we implement unilateral terminate

5. We make snapshot of an approved agreement A1 and continue making changes in an agreement A1

• to be confirmed by DG EAC/BPOs
• some changes in specification/software needed

[demilatof]

I think that about the termination of an IIA we should take into account another scenario: the termination could be not the last operation we do with that IIA. For example, we may decide now to terminate an IIA in 2025/2026 (according the specifications we are going to adopt).

This means that the IIA will be valid until that date; before it comes to an end (2025/2026) we may need to modify it or to terminate it earlier (e.g. 2024/2025). Therefore, when we'll decide the procedure to terminate an IIA we should foresight and describe how can we manage such a situation: a new termination on the already terminated IIA.

(This scenario may be more complicated in case of using termination as a first step to modify an IIA)

[umesh-qs]

2. last-valid-academic-year

Each provider should make sure that modification in not allowed after both partners have added last-valid-academic-year (should be same in both IIA) in their IIAs. If it is done by mistake then the partner receiving it should reject those changes. Here again it would be good if we can come up with some mechanism within EWP network to inform the sending partner about this.

[umesh-qs]

@janinamincer-daszkiewicz new field last-valid-academic-year is at cooperation condition level or at IIA level?

[janinamincer-daszkiewicz]

At IIA level.

[demilatof]

Each provider should make sure that modification in not allowed after both partners have added last-valid-academic-year

@umesh-qs I think this is impossible, first of all because it could be possible that the partners need to anticipate the last-valid-academic-year (and maybe postpone, if it does not overlap another IIA).

@janinamincer-daszkiewicz For the same reason I think that even if the termination could be unilateral, it is not enough that both partners add the same last-valid-academic-year in their IIA. What happens if tomorrow one of change it (by mistake or not)? Who may resolve a dispute between them? I think that even if the termination is unilateral, this kind of change must be approved by both partners in any case, calling the Approval API. But this means that:

1. We should put the last-valid-academic-year inside the cooperation conditions to be computed in the hash code.
2. We have to check that there are no other changes apart of the last-valid-academic year

Or, better in my opinion, a new couple of APIs (Termination-CNR and Termination-API) similar to Approval-CNR and Approval-API, that do only a task: check the presence of a valid last-valid-academic-year and approve the termination. Who calls the Termination-API must know that every other change would be ignored.

[mkurzydlowski]

What happens if tomorrow one of change it (by mistake or not)? Who may resolve a dispute between them?

It's the same as with any other field in the IIA. Both sides should store a snapshot of the partner's IIA if they want to be able to prove that in some moment they saw an acknowledgment from the other side and proceeded with the workflow accordingly based on that.

[demilatof]

It's the same as with any other field in the IIA. Both sides should store a snapshot of the partner's IIA if they want to be able to prove that in some moment they saw an acknowledgment from the other side and proceeded with the workflow accordingly based on that.

No, it's not the same. The other fields are not so important (e.g. a contact name). If they were important, they would be computed in the cooperation condition hash that triggers an explicit approval.

Now we have a termination of an IIA formerly and officially approved by means of an approval process. A termination means that in a particular year after the last-valid-academic-year we'll not accept any students even if we have an IIA approved that states the contrary.

We cannot think that if, for a moment, two IIA contains the same last-valid-academic-year it's enough to prove that those IIA approvals were no more valid because terminated. Otherwise, we can remove the Approval API and use snapshots to consider the IIA approved as soon as there is a match between two fields.

It doesn't matter that this is a unilateral termination: we must me sure that the other party has received the proposal and accepted. Our partner is compelled to accept, but it may throw an exception, for example, if now it is too late for the given last-valid-academic-year.

Here we need a bit of more legal arguments; maybe in Italy we pay too much attention to this aspect, but our legislation is quite restrictive.

Edit: I've just heard my IRO and discovered that in the "paper" world they just terminate without problems and without feedback. But I still think that when we make the digital version of a process we have to take care of more aspects that in the real world we are not used taking into account, to avoid bugs, deadlock or ambiguous point.

[jiripetrzelka]

It seems to me that termination of an IIA is just a specific type of amendment which consists of removing one of more trailing academic years from cooperation-conditions. So once termination is mutually agreed, partners can make a snapshot of the originally approved IIA and then remove certain academic years and then have this amendment with a new conditions-hash approved in the standard way using the Approval API.

In case partners use systems that will not allow modification of the cooperation conditions after the original IIA is approved, I assume the new parameter last-valid-academic-year would come into play. What I don't understand is why you call it "unilateral" termination. I assume partners would communicate the intention to terminate the IIA outside EWP like any other amendment and once they find a consensus, they insert the last-valid-academic-year into their information systems.

The only problem will arrive if they don't reach a concensus and one of the partners will invoke their right for unilateral termination and force the other party to terminate the IIA from the academic year which corresponds to the clause: "This means that a unilateral decision to discontinue the exchanges notified to the other party by 1 September 20XX will only take effect as of 1 September 20XX+1." Now the party enforcing the termination has the burden to prove that it notified the other party in time. As I understand it, it could be for example a transcript of e-mail communication. Or not? Is this new proposal for unilateral termination intended to replace any other means by which the unilateral termination could be communicated and later corroborated? If so, the concept is a bit strange - I publish something on my server and then use it as a proof of delivery to the other party? Or do I understand it incorrectly and all these legal issues concerning timing of message delivery in case of legal dispute are supposed to play out outside the realm of EWP?

Also, I don't understand what should partners do in case they have mutually approved an IIA but want to terminate it as a whole. If they cannot delete it, how do they achieve this? Setting the last-valid-academic-year to the academic year that precedes the first year of validity, even if it is not present in the IIA?

[janinamincer-daszkiewicz]

Jiri, we will discuss these issues tomorrow, during the Infrastructure Forum meeting.

[jiripetrzelka]

Here are some more questions regarding amendments/termination for tomorrow's IF:

Modify/amend

1. We keep in a system an approved agreement A1 but in real life we allow some exceptions (both partners should agree)

• to be confirmed by DG EAC/BPOs
• no changes in specification/software needed

3. We terminate an approved agreement A1 and start working on an agreement A2

• available after we implement unilateral terminate

5. We make snapshot of an approved agreement A1 and continue making changes in an agreement A1

• to be confirmed by DG EAC/BPOs
• some changes in specification/software needed

"to be confirmed by DG EAC/BPOs" => Where can I find the information whether this has or has not been confirmed by DG EAC/BPOs?

If DG EAC/BPOs allow both the second and last option, will system implementers have to provide both processes for their users and let them decide in each case based on their business level preferences, or will system implementers be allowed to implement just one of the ways and thus limit their users' choices technically?

In the latter case, it would help if each system could somehow publish which options it supports so that the other system can reflect this and not allow their users to choose an unsupported option.

However, in case HEI changes provider, this would become tricky. Ideally, all systems should either be required to support both options or just one option should be allowed.

Termination

In case coordinators have already agreed by e-mail to terminate an IIA from academic year XY, what are their systems allowed/forced/forbidden to do based on their user input? a) Set the last-valid-academic-year element in their respective copies to what they have agreed? (regardless of who will be first) b) Remove one or more trailing receiving-academic-year-id elements from their IIAs and expect IIA Approval? c) Do a) and then b)? d) Do b) and then a)?

In case coordinator A does not contact coordinator B and puts the last-valid-academic-year into their copy right away, what should coordinator/system B do?

• Consider this a formal request to unilaterally terminate the IIA and verify (automatically or semi-automatically) its rightfulness by checking the datetime of the first IIA Get request that discovered the presence of the receiving-academic-year-id element in partner's IIA?
• In case the datetime is later than 1 September of the previous academic year, should the system inform coordinator B that A's request is formally late but can be accepted nevertheless if coordinator B has no problem with it?
• If B accepts and adds last-valid-academic-year into their copy, can/must/must not s/he then proceed to remove the trailing receiving-academic-year-id and request IIA Approval?

Is it possible to later resume a terminated IIA?

• If so and termination was previously done with scenario a) above, does it mean that the last-valid-academic-year element should be removed and new cooperations conditions added and re-approved?
• If so and termination was previously done with scenario b) above, can partners just add new cooperation conditions and expect re-approval?

[demilatof]

In my opinion @jiripetrzelka is listing a lot of real problems, and they may be not all, connected to the introduction of amendments and termination. I think we could simplify a bit if we consider them the same thing under certain assumptions:

1. We must be sure that all providers can manage the same cooperation condition split in two or more parts under the only condition that the academic years don't overlap each others. This grant us to have an amendment for the future, but keep the correct information for the past
2. To modify an IIA approved by both of the parties we split the cooperation conditions to be modified in two parts: the first one that regards the previous conditions currently in effect and the second one with the new conditions (doing so we make clear what it was and what it will be)
3. The termination is a specific case of the amendment, where we modify the last academic year of cooperation conditions (e.g. if we have the cooperation conditions from 2023 to 2027, we could change from 2027 to 2024 to terminate in 2024/25) 4.In any case, if an approved IIA is changed, it requires a new approval to substitute the previous one (golden rule: an approved IIA is approved and it requires the same procedure to be changed)
4. Every time we receive the approval we have to store the approved IIA
5. Because of we have two different IIA for the same IIA Id (the previously approved IIA and the IIA under review), we could need a new optional parameter to call IIA Get API: <last-approved>. If it is set to true, we return the last approved IIA to the partner, otherwise if it is false or not used we return the last IIA version (maybe under revision)

[spinho-uporto]

Considering the decision about IIA modifications communicated at the last Infrastructure Forum meeting (2023-03-15), and the need to make changes in our system, I would like to see some doubts clarified in the specification of the solution chosen.

For those who also continue to use pdfs, how do we know if the pdf being signed is a modification to an agreement or a new agreement to add more conditions for cooperation? Will there be any changes to the template to include an identifier for the agreement? Note that there are already pdfs signed by both parties (not yet approved in EWP network), and changes that can be made in the meantime with a new pdf signature may be considered additional conditions instead of changes.

Will the IIA template be updated to contemplate the structure defined in the EWP specification, namely the academic years in cooperation conditions? Our system reflects the IIA template (therefore, we cannot register cooperation conditions with different academic years since the entire agreement is valid for a period of academic years), but with this decision, agreements with conditions of cooperation with different academic years among themselves will appear.

We are waiting for the new specification so we can start working on the new version of our system.

[janinamincer-daszkiewicz]

Results of voting carried before the IF meeting on March 15, 2023 are uploaded to the shared drive. The winner is "Modification of IIA as he only option, i.e. terminate should be treated like any other modification".

Solution to specify: To modify IIA which has been mutually approved, HEIs should take a snapshot of the last approved version and continue with IIA in a usual way. That means that a partner can make changes to own copy of IIA and then send IIA CNR. The other partner may agree and send IIA Approval CNR or disagree and make changes to its copy of IIA, after that sending IIA CNR. If the partners do not reach the conclusion they should revert back to the last mutually approved version.

Options to allow termination of the IIA as a whole

• Deletion of mutually approved IIA is allowed – our proposal
  • We can keep IIA Approval Get response for the record (with the given ID and CC hash)
  • We need DG EAC approval and exemption on the "deleting approved IIA" from the Mandatory Business Requirements.
• Cooperation-conditions have minOccurs="0”
  • Would complicate the whole IIA process as it would mean such "empty" IIAs are technically correct and have to be validated based on the workflow.

[demilatof]

Options to allow termination of the IIA as a whole

* Deletion of mutually approved IIA is allowed – our proposal

  * We can keep IIA Approval Get response for the record (with the given ID and CC  hash)
  * We need DG EAC approval and exemption on the "deleting approved IIA" from the Mandatory Business Requirements.

May I ask you why you propose to introduce the deletion of a such important thing as mutually approved IIA, without discussing it on GitHub before? I don't remember that anyone asked for the deletion of a mutually approved IIA. I'm not for the deletion of mutually approved IIA; a mutually approved IIA is also an "in effect" IIA, too dangerous to delete completely, I don't think this solution could be compliant with Italian law, but neither with European Law.

If we need to terminate an IIA as a whole, I think there is a better solution with the tools we already have. I suppose that when we talk about "termination as a whole" we mean that none of the cooperation conditions have been ever activated (otherwise we should fall again in the "standard" termination).

Even if we need to terminate an IIA as a whole, we may need to keep it for any further needs, with all cooperation conditions. The solution, in my opinion, is quite easy: the element "receiving-academic-year-id" must be present in the cooperation conditions of the IIA get-response but the only limit of its data type is that it must be in the form [0-9]{4}/[0-9]{4} (as stated here).

Therefore, it must be something like "2023/2024". Just write in the specification that to terminate an IIA as a whole both partners must replace the list of academic years in the cooperation conditions with a single entry: 0000/0000 (or 0000/0001 if you like better) and then following the general rules for termination/modify (IIA CNR and then IIA CNR Approval/IIA Approval).

Nothing more: the zero academic year ensure to keep all important data in the IIA that is terminated as a whole. We can discuss if this IIA should always be listed in IIA-Index or only if explicitly requested with receiving_academic_year_id=0000/0000

[janinamincer-daszkiewicz]

May I ask you why you propose to introduce the deletion of a such important thing as mutually approved IIA, without discussing it on GitHub before?

We are in GitHub and we are discussing it :)

I don't remember that anyone asked for the deletion of a mutually approved IIA.

We discussed DELETE for a long time at various foras. I am pretty sure there exist implementations which already silently do exactly that.

I'm not for the deletion of mutually approved IIA; a mutually approved IIA is also an "in effect" IIA, too dangerous to delete completely, I don't think this solution could be compliant with Italian law, but neither with European Law.

This argument should of course be taken into account. But having locally stored snapshot and/or IIA Approval response gives you some legal evidence. Anyway it also effects Mandatory Business Requirements so we need to consult it with DG EAC.

replace the list of academic years in the cooperation conditions with a single entry: 0000/0000 (or 0000/0001 if you like better) and then following the general rules for termination/modify (IIA CNR and then IIA CNR Approval/IIA Approval).

I agree that such option is also possible. We may add it to the options to vote. Personally I prefer the option we propose as easier to implement. Of course we first have to make sure that it is OK from the legal point of view.

We can discuss if this IIA should always be listed in IIA-Index or only if explicitly requested with receiving_academic_year_id=0000/0000

As you see new questions arise. This is why I prefer simpler solution.

[demilatof]

May I ask you why you propose to introduce the deletion of a such important thing as mutually approved IIA, without discussing it on GitHub before?

We are in GitHub and we are discussing it :)

I don't remember that anyone asked for the deletion of a mutually approved IIA.

We discussed DELETE for a long time at various foras. I am pretty sure there exist implementations which already silently do exactly that.

We have already discussed and voted about DELETE and always under the condition that there is no possibility to delete a mutually approved IIA. In every forum. You should not try to propose again this possibility; do we need to terminate a mutually approved IIA as a whole? OK, we can discuss any solution but not the deletion of a mutually approved IIA, we have received the input that it was forbidden when we voted and forbidden it should remain. These are yours slide, and we voted knowing that the delete "Should only be done with IIA which has not yet been approved by both partners." You never said that in future we would have discussed about the deletion of a mutually approved IIA; it should be analyzed as a whole. Therefore, I repeat my original question: why?

[jiripetrzelka]

Cooperation-conditions have minOccurs="0”

• Would complicate the whole IIA process as it would mean such "empty" IIAs are technically correct and have to be validated based on the workflow.

If this is a problem then we could have for example: <cooperation-conditions><terminated /></cooperation-conditions>

The important thing is that by mutually approving an IIA, partners have explicitly expressed their will. And termination of an IIA partially (stripping some trailing academic years) will also require an explicit expression of will, that is a new approval. So I don't see any sense in treating the termination of the IIA as a whole as something that does not entail the same level of legal significance.

What I suggest is: Termination of an IIA as a whole would still require approval. Once both partners have their respective approvals logged, the IIA can be deleted. Because without the approvals, one of the partners could later claim that s/he has the previous approval and that the IIA had not been terminated.

[demilatof]

What I suggest is: Termination of an IIA as a whole would still require approval. Once both partners have their respective approvals logged, the IIA can be deleted. Because without the approvals, one of the partners could later claim that s/he has the previous approval and that the IIA had not been terminated.

I agree with you, the termination of an IIA as a whole would still require approval. The new tag <terminated> can be an option, but that could require a version change. Since the termination of an IIA as a whole means that none of the cooperation conditions were ever used, my proposal is to set to zero the academic year (0000/0000). This solution keeps the whole file, but invalidates any effect (termination as a whole).

In my opinion, it would be better not deleting anyway the IIAs after the mutual approval, because their IIA-Ids, that must be unique, should remain to avoid duplicates. Theoretically, if an IIA is deleted, its IIA-Id becomes available again, and someone could use it for a new IIA. Even if it can manage the situation, the partner's system could use that IIA-ID to reactivate old information, and this is no good.

[milsorm]

Because winner solution is nightmare for us (random changing of cooperation conditions in agreement and try to recognize "what happened" between two versions), can we add some identification to cooperation condition to help understand, what's happened (to show IRO which cooperation condition is removed/added/changed)? Because I think you don't want the game "found what's happened" to play with every CNR for IRO at all.

[milsorm]

And second thing - can we tell definitely how can be proofed that exists some version of signed IIA from some moment? We cannot say that "last version is only valid" because it can be changed now during time. So we need to store some signed agreement + something (like HTTP headers with signature) as proof of validity in some moment. Can you exactly describe this? I need to answer our IROs to question "how we can proof that we send somebody to somewhere based on some legal contract".

[umesh-qs]

And second thing - can we tell definitely how can be proofed that exists some version of signed IIA from some moment? We cannot say that "last version is only valid" because it can be changed now during time. So we need to store some signed agreement + something (like HTTP headers with signature) as proof of validity in some moment. Can you exactly describe this? I need to answer our IROs to question "how we can proof that we send somebody to somewhere based on some legal contract".

@milsorm Is legal proof part of the current specs/design? If not why do you need to answer your IRO?

[milsorm]

@milsorm Is legal proof part of the current specs/design? If not why do you need to answer your IRO?

They are asking me. I am the one who persuade universities to use EWP because they don't want it. They prefer original e-mail style... We are very hard to persuade clients to use IT for these things because EWP only complicate their work.

[demilatof]

can we add some identification to cooperation condition to help understand, what's happened

In our internal system we already have an ID for any of our cooperation condition, therefore it will not be a problem to provide it. The problem may be that this would be a major change, that involves a version upgrade. And I hope you don't want a binding as for IIA-ID, because it could be a nightmare. Nevertheless, theoretically without a binding there may be partners who change their Cooperation Condition ID from an IIA-Get to another, and so this innovation would be useless for your purpose.

And second thing - can we tell definitely how can be proofed that exists some version of signed IIA from some moment?

This is why I proposed to add a new parameter to IIA-Get request to retrieve the snapshot, that is the last version approved. If at any time I can ask the partner to provide me the last approved version, I can check if this version is the same for which I gave the approval (I have to save the partner's IIA-ID and hash code). Here may arise a problem: the API version changing, that could make the two hash codes different (the one I saved and the one computed to return the approved IIA version). There may be a better solution, but presently we don't use private and public keys.

If you need to give an answer to your IROs, the mandatory business requirements, at the end of page 5 state: "For the time being and until eSignature becomes a function available in EWP, approval by both parties in the EWP network is considered as the equivalent of a digital signature confirming institutional commitment"

They are asking me. I am the one who persuade universities to use EWP because they don't want it. They prefer original e-mail style... We are very hard to persuade clients to use IT for these things because EWP only complicate their work.

I completely agree with you, this EWP architecture only complicates their work (but not only, even our work). All that said, I don't think you have any role in persuading universities to use EWP, because they are compelled to use it by UE. I tried to explain to my IROs that EWP has a bad design and that it will require them a lot of work, but they answered me that they are compelled by national agency and that I should try to do my best to minimize every problem.

[milsorm]

National Agencies in CZ and SK ignore EWP at all :-) So our HEIs ignoring it too and it is up to me to persuade them. Otherwise they will use Dashboard (as using for LA a long time) and only blame my company that we are not connect to Dashboard and they have to transfer data manually (yes, they publicly blame us for things we cannot do :-( as usual...). So I have to do education work and learn them about EWP, his bad design at all, tragic misunderstanding in implementations, a lot of overhead in their work based on these things etc. etc.

But - absolutely agree with you in other things.

[janinamincer-daszkiewicz]

Since the termination of an IIA as a whole means that none of the cooperation conditions were ever used, my proposal is to set to zero the academic year (0000/0000). This solution keeps the whole file, but invalidates any effect (termination as a whole).

Since the proposal to delete mutually approved IIAs requires the approval of DG EAC and change in the Mandatory Business Requirement we will follow the proposal cited above. To terminate IIA as a whole one needs to replace all academic years in all CCs with this 'dummy' academic year and then follow the usual approval process.

[skishk]

why are we going to use "no real" data like 0000/0000 to terminate? and not using modify directly? we are introducing something not real instead using something clean and ready like modify.

[janinamincer-daszkiewicz]

What do you mean by that? We need a solution for terminating mutually approved IIA as a whole. We already discussed various possible options and the one with this dummy academic year is an acceptable compromise.

[skishk]

just changing cooperation condition of next years by removing them or set 0 mobilities-per-year and then 2 partners approve it. until they approve (or not) it, it will be valid the IIAs already approved. network already have everything to manage this scenario.

[janinamincer-daszkiewicz]

just changing cooperation condition of next years by removing them

> or set 0 mobilities-per-year this change seems equally intrusive to dummy academic year > and then 2 partners approve it. until they approve (or not) it, it will be valid the IIAs already approved. network already have everything to manage this scenario. This will be needed whatever way we will model terminating IIA as a whole

[skishk]

so we are introducing fake data in a Agreement between 2 Institutions? :sweat_smile:

[janinamincer-daszkiewicz]

We discussed various options, I would love to have an elegant solution for this case. Let's hope HEIs will not be terminating mutually approved IIAs.

[demilatof]

just changing cooperation condition of next years by removing them

There are no "next years" when we terminate as a whole ;-) because the cooperation conditions take no place in no academic year. This is the reason why 0000/0000 is not a so strong fake data. It simply means that the described cooperation conditions will never take place (or that they exist for a "null" academic year).

so we are introducing fake data in a Agreement between 2 Institutions? sweat_smile

Even setting 0 mobilities when they were 2 is a fake data.

[demilatof]

We discussed various options, I would love to have an elegant solution for this case. Let's hope HEIs will not be terminating mutually approved IIAs.

If you plan to upgrade the namespace anyway, the most elegant solution is to put a new element "terminate-as-a-whole" inside the cooperation conditions. It may even be an optional element, but if it is present and set to true, the IIA is terminated as a whole. Putting it inside the cooperation conditions also triggers the hash-code and the need of a new Approval

[janinamincer-daszkiewicz]

That's not as elegant as it sounds. 'Terminate as a whole' is a special case of 'Terminate from the next academic year', not something totally different which needs a different approach. Yes we plan to upgrade the namespace anyway so have more freedom in finding something suitable.

[demilatof]

That's not as elegant as it sounds. 'Terminate as a whole' is a special case of 'Terminate from the next academic year'

I don't think so. We can think it is a special case for convenience (if we don't want to change the namespace), but it is something different: cooperations never used VS. cooperation used at least for an academic year. The proof is that we have to introduce conventional (or fake) data to keep track of what was agreed, whilst "terminate from the next academic year" doesn't need any fake data, it's enough to remove the next academic years.

[janinamincer-daszkiewicz]

Providers voted against having termination as a separate case. They chose to have modify only. If we follow this lead and we don't want to introduce any (less or more) fake data the only solution is to agree to removing all academic years, i.e. changing

to with (possibly) an extra rule that 0 can only happen in that particular case of termination as a whole.

[demilatof]

Providers voted against having termination as a separate case. They chose to have modify only.

No, this is a wrong representation of the vote. The vote was between a unilateral termination with the element <last-valid-academic-year> outside the cooperation condition that therefore doesn't trigger any new approval and a termination that could be managed within the modify rules, triggering a new approval. The first survey option even excludes the possibility to modify an approved IIA, the third option allows this possibility, but in any case there are no needs for a new approval in case of the termination.

You have proposed that last-valid-academic-year was at IIA level, outside the cooperation condition and the hash code; this is the main reason for the vote, not the will to have a termination as a particular case of the modification.

If a namespace upgrade is allowed, I suggest to vote for a new element inside the cooperation conditions only to terminate the IIA as a whole. This means that it could even be used as suspension, because some time later the partners could agree to reactivate it removing the field and falling again under the general rules of the modification.

I suspend my opinion on removing the AcademicYearId until I don't fully understand how should we apply the "extra rule that 0 can only happen in that particular case of termination as a whole". Could you explain who should check that rule and how a partner can distinguish between a rule not respected and a termination as a whole? Moreover, we have to check that the AcademicYearIds are removed from all cooperation conditions (the same that should be done if we set them to 0000/0000). A new element "terminate-as-a-whole" is more clear, unambiguous and doesn't need to modify or check anything else if not that we are still in time to terminate as a whole.

[mkurzydlowski]

As it has been already voted to express the termination as IIA modification, both solutions:

• dummy academic year,
• empty academic years list,

seem to satisfy those expectations.

If we choose to use the second solution, then we need to add to the specification that an empty list is only valid if used for all CCs and may only be used to express a termination of IIA as whole.

[demilatof]

As it has been already voted to express the termination as IIA modification

Please, read my answer above yours. What are you saying is not completely true. We have chosen among three options, where the only that requires an approval for termination was the second option. We may read the vote in this way and claim that every solution that require a termination as a whole may be accepted if it involves a new approval

[janinamincer-daszkiewicz]

Let's wrap up. We consider the situation when IIA is mutually approved (MA). We want to treat termination as any other modification which is followed by re-approval. Since we will increase major version number, we may continue with the (voted positively) solution from https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/70.

Let's look at the very simple example. We have MA IIA with the following mobilities:

<student-studies-mobility-spec>
  ...
  <receiving-academic-year-start-id>2022/2023</receiving-academic-year-start-id>
  <receiving-academic-year-end-id>2024/2025</receiving-academic-year-end-id>
  ...
</student-studies-mobility-spec>

<student-studies-mobility-spec>
  ...
  <receiving-academic-year-start-id>2024/2025</receiving-academic-year-start-id>
  <receiving-academic-year-end-id>2025/2026</receiving-academic-year-end-id>
  ...
</student-studies-mobility-spec>

When we want to terminate (modify) we first make a copy of the last MA IIA and then make changes on that copy. We start the approval. When approval is finalised the new mutually approved copy replaces the previous mutually approved copy.

PROPOSAL 1

1. We terminate from 2025/2026. The new IIA is

   
   <student-studies-mobility-spec>
   ...
   <receiving-academic-year-start-id>2022/2023</receiving-academic-year-start-id>
   <receiving-academic-year-end-id>2024/2025</receiving-academic-year-end-id>
   ...
   </student-studies-mobility-spec>

... 2024/2025 2024/2025 ...

2. We terminate from 2024/2025. The new IIA is: 

... 2022/2023 2023/2024 ... ... 2024/2025 2023/2024 ...

3. We terminate from 2022/2023. The new IIA is: 

... 2022/2023 2021/2022 ... ... 2024/2025 2023/2024 ...

This is network representation. It should not be displayed like that in the user interface. It should be displayed like an empty set of academic years.

This way termination is like any other modification, for example we may want to extend mobilities like that:

... 2022/2023 2026/2027 ... ... 2024/2025 2026/2027 ...

Is such solution an acceptable compromise?

If that helps, we may add in the Readme file that (receiving-academic-year-start-id < receiving-academic-year-end-id) represents an empty set of academic years and is only acceptable if there already exists MA IIA.

PROPOSAL 2
After writing all this I checked one more option: when the list of academic years becomes empty, we just remove the whole mobility section. Termination as a whole is equivalent to having empty cooperating conditions:

If I have not missed anything, this is valid IIA.

P.S. Local systems may decide to keep ALL MA IIA versions, not just the last one.