Changes after mutual approval: what should we approve?

[demilatof]

I introduced my doubts here, but this could be a better place for this issue.

Let's think that we have two partners, A and B; once they mutually approve two IIAs (A1, B1), they state that the two IIAs are matching quite exactly. Therefore, the couple (A1, B1) is now a single IIA and the two IIAs are strongly tied each other, but this is true as concern their current version (for simplicity, version v1) I think that until now we can agree with the above scenario.

Now, if A decides to modify its IIA to move to a v2 of the agreement, we know that it needs a new approval by B. And this is what we are discussing and, I think, commonly accepting.

But my doubt is: can we still say that B1 v1 may keep its approval? A has approved B1 v1 because it has seen that the v1 version of B1 matched with the old version of A1 (v1). Now we have A1 but v2. Can we still assume that the old version of B1 can keep its approval under the new circumstance?

I think not; I think that A must explicitly approve again B1:

• As v1 to confirm it (e.g. because A1 v2 is more compatible with B1 v1 than before)
• As a new v2 (to be received from B) if A realizes that its A1 v1 can match only with a new version of B1 and not with the old one

Because the problem is that, until now, when A changes its A1 IIA, B1 v1 keeps its approval. And I think that this is not correct, not any more.

[umesh-qs]

I introduced my doubts here, but this could be a better place for this issue.

Let's think that we have two partners, A and B; once they mutually approve two IIAs (A1, B1), they state that the two IIAs are matching quite exactly. Therefore, the couple (A1, B1) is now a single IIA and the two IIAs are strongly tied each other, but this is true as concern their current version (for simplicity, version v1) I think that until now we can agree with the above scenario.

Now, if A decides to modify its IIA to move to a v2 of the agreement, we know that it needs a new approval by B. And this is what we are discussing and, I think, commonly accepting.

But my doubt is: can we still say that B1 v1 may keep its approval? A has approved B1 v1 because it has seen that the v1 version of B1 matched with the old version of A1 (v1). Now we have A1 but v2. Can we still assume that the old version of B1 can keep its approval under the new circumstance?

I think not; I think that A must explicitly approve again B1:

• As v1 to confirm it (e.g. because A1 v2 is more compatible with B1 v1 than before)
• As a new v2 (to be received from B) if A realizes that its A1 v1 can match only with a new version of B1 and not with the old one

Because the problem is that, until now, when A changes its A1 IIA, B1 v1 keeps its approval. And I think that this is not correct, not any more.

As soon as the version is changed, IIA needs to be re-approved, even if it is reverted back to the old version.

[demilatof]

As soon as the version is changed, IIA needs to be re-approved, even if it is reverted back to the old version.

What do you mean with IIA? The single IIA, that is A1 or B1, or the final IIA, that is the couple (A1, B1)? My question is if we have to approve again even the other part of the IIA (B1) when we change our copy, A1, and we ask B for an approval

[umesh-qs]

As soon as the version is changed, IIA needs to be re-approved, even if it is reverted back to the old version.

What do you mean with IIA? The single IIA, that is A1 or B1, or the final IIA, that is the couple (A1, B1)? My question is if we have to approve again even the other part of the IIA (B1) when we change our copy, A1, and we ask B for an approval

I am not sure what you mean by this. Both parties have to re-approve the IIA. Owner of B1 must re-approve A1 and owner of A1 should re-approve B1

[demilatof]

I am not sure what you mean by this. Both parties have to re-approve the IIA. Owner of B1 must re-approve A1 and owner of A1 should re-approve B1

I agree with you, this is what it should be done. But are you sure that this is what the specifications say and what the other partners are doing? This slide is not particularly clear on the approval And generally, what has been said always is that we have to give a new approval if we fetch an IIA and we see that its hash code (now version ID) is changed. Therefore, I think that presently most of us is convinced that when partner A modifies its component of the coupled (A1, B1), there is no need for a new approval to B1.

I would like to know what others are thinking about.

[umesh-qs]

I am not sure what you mean by this. Both parties have to re-approve the IIA. Owner of B1 must re-approve A1 and owner of A1 should re-approve B1

I agree with you, this is what it should be done. But are you sure that this is what the specifications say and what the other partners are doing? This slide is not particularly clear on the approval And generally, what has been said always is that we have to give a new approval if we fetch an IIA and we see that its hash code (now version ID) is changed. Therefore, I think that presently most of us is convinced that when partner A modifies its component of the coupled (A1, B1), there is no need for a new approval to B1.

I would like to know what others are thinking about.

There is no other way but to approve both IIAs, if one of the partner does important changes. I do not see why this can be an issue. If partner A change their IIA A1, partner B will have to match the new changes on their IIA B1. Once that happens approvals will be re-set for both IIAs and both parties need to re-approve their partners IIA

[demilatof]

There is no other way but to approve both IIAs, if one of the partner does important changes. I do not see why this can be an issue. If partner A change their IIA A1, partner B will have to match the new changes on their IIA B1. Once that happens approvals will be re-set for both IIAs and both parties need to re-approve their partners IIA

I totally agree with you, but in my opinion the issue is not to manage this possibility, but to be sure that all the providers accept this solution. And here the specifications play an important role.

The most important point, that could be a bit tricky to understand, is that B could not need to match the new changes on their IIA B1. E.g.: the mutually approved A1 wasn't really identical to B1; A makes it more identical with a change BUT B doesn't need to change its B1 because it was already correct. Nevertheless, A should approve anyway B1 even if untouched, simply to confirm that it is still good for the new approval (A1 v2, B1 v1)

[demilatof]

@umesh-qs I'm afraid that the approval of the changed IIA (and not of both of them) is enough for most of the providers. I'll try to explain in the following slide why I think it could be a great problem, especially if we plan to sign the approvals. I hope that @janinamincer-daszkiewicz and @mkurzydlowski can tell us something about this.

[mkurzydlowski]

What I understand from this slide is that it doesn't look right that after A changes IIA to A1 v.2 and B accepts this version, A might still say it approves B1 v.1.

If this should prove to be an issue (for A or for B?) then maybe A should not say it approves B1 v.1 when it decides to change its IIA to A1 v.2?

[janinamincer-daszkiewicz]

Or saying differently: do you suggest that after there is change on one side both copies should always be approved?

[demilatof]

Or saying differently: do you suggest that after there is change on one side both copies should always be approved?

Exactly; if I'm not wrong, @umesh-qs is of the same opinion as me.

From the network perspective, I think that an IIA exists when its two components are mutually approved. But... When can I approve my partner's IIA? I can approve my partner's IIA when I can confirm that what he wrote is substantially the same I wrote. If I change my IIA after the approval, my previous statement could be no more valid; I've to state explicitly that my partner's IIA is still good as it is; or I've to wait for his amendment before giving him a new approval.

[demilatof]

What I understand from this slide is that it doesn't look right that after A changes IIA to A1 v.2 and B accepts this version, A might still say it approves B1 v.1.

If this should prove to be an issue (for A or for B?) then maybe A should not say it approves B1 v.1 when it decides to change its IIA to A1 v.2?

I don't fully understand your objection (my bad), I hope that my answer to Janina could be useful for your question. I can say that in my opinion this is an issue for both of them, because they have an unbalanced approval (one copy says a thing, the other copy says a different thing), whilst they initially were convinced that the two copies are (quite) identical.

maybe A should not say it approves B1 v.1 when it decides to change its IIA to A1 v.2?

There is no way to un-approve; currently if A doesn't say that it approves B1 v. 1, B1 v. 1 is still approved anyway thanks to the previous approval. The only way to have always a full agreement is requiring a mutual approval every time. If there isn't a new mutual approval, the previous is the only one valid.

[umesh-qs]

There is no other way but to approve both IIAs, if one of the partner does important changes. I do not see why this can be an issue. If partner A change their IIA A1, partner B will have to match the new changes on their IIA B1. Once that happens approvals will be re-set for both IIAs and both parties need to re-approve their partners IIA

I totally agree with you, but in my opinion the issue is not to manage this possibility, but to be sure that all the providers accept this solution. And here the specifications play an important role.

The most important point, that could be a bit tricky to understand, is that B could not need to match the new changes on their IIA B1. E.g.: the mutually approved A1 wasn't really identical to B1; A makes it more identical with a change BUT B doesn't need to change its B1 because it was already correct. Nevertheless, A should approve anyway B1 even if untouched, simply to confirm that it is still good for the new approval (A1 v2, B1 v1)

@demilatof what we do is we reset my approval for partner IIA and also reset partner approval of my IIA internally. So if my partner is approving old IIA version of mine then I will not accept it and show it as unapproved in my system. Is that not solving the problem you are referring to?

[janinamincer-daszkiewicz]

Or saying differently: do you suggest that after there is change on one side both copies should always be approved?

Exactly; if I'm not wrong, @umesh-qs is of the same opinion as me.

Is this a business need?A technical need?

[demilatof]

@demilatof what we do is we reset my approval for partner IIA and also reset partner approval of my IIA internally. So if my partner is approving old IIA version of mine then I will not accept it and show it as unapproved in my system. Is that not solving the problem you are referring to?

This solves the problem of my IIA, and it is quite intuitive: I change my IIA and my partner must approve my new version. My issue is that if I change my IIA, I have to approve again even my partner's IIA. Most probably me and you are implementing such a situation, but not others.

Therefore your partner cannot understand why his IIA is still the same, with the same hash code, but now you ignore its call to your Approval API. Because if you are not ready to approve his version (untouched), you should ignore his request: "Values of iia_id that are not known by the server as owner_hei_id's agreements or not approved (yet or at all) MUST be ignored"

[demilatof]

Is this a business need?A technical need?

It's a business need that requires a technical solution. I think it's more correct to say that it is a conceptual need. Let's think about the mutual approval in terms of colors.

I have a black IIA, I check that you have a really dark grey IIA and I approve your IIA. And you do the same. We agree that my black IIA and your dark grey IIA are matching (master-master model).

Then I paint again my IIA and now it is blue, I send you a CNR and you approve my new IIA and forget to repaint your. But I've previously approved your IIA and this approval is still valid. Formally, now we are agreeing with the fact that my blue IIA is matching your dark gray IIA. Is this correct? Are we really thinking that in future we will digitally sign something similar?

If I paint blue my IIA and send you a CNR, I've changed my mind. I've to explicitly say that my blue is indeed really similar to your dark grey IIA anyway, or I have to wait for your repainting.

If you ask a lawyer for an opinion about this, I think he could be surprised that we can think to give legal relevance to something built as we currently do with approvals.

[janinamincer-daszkiewicz]

It's a business need that requires a technical solution.

Which means that we have to agree on that in the first place, before we start looking for the technical solution.

[mkurzydlowski]

Therefore your partner cannot understand why his IIA is still the same, with the same hash code, but now you ignore its call to your Approval API. Because if you are not ready to approve his version (untouched), you should ignore his request: "Values of iia_id that are not known by the server as owner_hei_id's agreements or not approved (yet or at all) MUST be ignored"

Then I paint again my IIA and now it is blue, I send you a CNR and you approve my new IIA and forget to repaint your. But I've previously approved your IIA and this approval is still valid.

When you paint the IIA to blue and it stops to match the other IIA then you mustn't respond to a Approval API request and must send a Approval CNR. Wouldn't that be a sensible solution?

[demilatof]

It's a business need that requires a technical solution.

Which means that we have to agree on that in the first place, before we start looking for the technical solution.

But currently specifications have not been written under BPO's requirements? Do they know what impact has the current technical solution in the process?

I'm afraid that there is a great lack in the specifications that could affect the EWP Network reliability; the specifications don't detail well the BPO requirements and the most of the providers have read only the specifications and not the BPO Mandatory Business requirements (they didn't have to do).

The BPO requirements were well written and there should not be any doubt about their meaning:

They clearly stated:

Modifying an approved agreement - Both partners should approve such a change in order to become valid

[demilatof]

When you paint the IIA to blue and it stops to match the other IIA then your mustn't respond to a Approval API request and must send a Approval CNR. Wouldn't that be a sensible solution?

Yes and not.

YES: I can send an Approval CNR if I think that my changes make my IIA more compliant to partner's IIA without he has to modify anything.

NOT: I must not send an Approval CNR if I need that my partner changes his copy too. After I have received his IIA CNR and after I'm sure that his new IIA satisfies me, I can send an Approval CNR.

In both of the cases, only after I have sent an Approval CNR more recent that the mutually approval timestamp, I can consider an Approval API request.

But I think that this is not what is currently requested to the providers and most providers could not understand the fact that I'm ignoring their Approval request for one of their IIAs that they haven't modified.

[mkurzydlowski]

I was talking about sending an Approval CNR to signify that the Approval object has been removed.

You are right that some note must be added to the current specification to make this clear if we decide to use this solution.

[janinamincer-daszkiewicz]

But currently specifications have not been written under BPO's requirements?

BPO group was created under the current ESCI/EWP+ FWC which does not mean that previous decisions concerning specifications had not been consulted with IROs. They were, very intensively.

[demilatof]

I was talking about sending an Approval CNR to signify that the Approval object has been removed.

Now I understand, it could be a solution under the specifications of the CNR, less under the Approval CNR specifications because it is always described as used to notify that the partner has approved and not removed the approval. E.g.: "Identifier of the HEI which has recently approved the partner's copy of the IIA" I think there is nowhere something that explains that an approval could be removed or required again. And indeed, we don't remove the approval, the old approval is still valid and we can revert to it if we don't agree on the new versions.

I remember that someone asked for both of the IIA IDs and hash codes in the approval response. Could it be useful?

You are right that some note must be added to the current specification to make this clear if we decide to use this solution.

I think so, and in several points (e.g Approval CNR), with a complete example to clarify the approval process after the first mutual approval.

[mkurzydlowski]

I remember that someone asked for both of the IIA IDs and hash codes in the approval response. Could it be useful?

That's in fact what I would like to suggest. If we add local IIA ID and version ID to the approval then every change to the local IIA will make the approval void. There is no need to remove such approval after modification and HEI doesn't need to change it if it reverts to the last approved version of the IIA.

This is the proposed change: https://github.com/erasmus-without-paper/ewp-specs-api-iias-approval/compare/hash-as-version...modify

[demilatof]

HEI doesn't need to change it if it reverts to the last approved version of the IIA.

Why they should revert to the last approved version of the IIA even if they don't agree on a new version of the IIA? They could leave their new IIAs as not approved; or not?

This is the proposed change: hash-as-version...modify

What should be the use of the file downloaded via the approved-iia-file?

[mkurzydlowski]

This file is part of the version ID introduction change. It's used as a proof of what has been approved by the partner.

[demilatof]

It's used as a proof of what has been approved by the partner.

This was clear, but what I meant is how should we use it as a proof? Could you make an example how could it be used as a proof? Depending on the task we have to perform to check that proof, we may need further specifications/rules

[skishk]

What should be the use of the file downloaded via the approved-iia-file?

approved-iia-file ?!?! are we leaving the way of exchange data to exchange files? :sweat_smile:

[mkurzydlowski]

Let's discuss changes introduced in hash-as-version branch here: https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/109

[umesh-qs]

@janinamincer-daszkiewicz @mkurzydlowski I have another scenario. Since we are not allowing changing of partner IIA after mutual approval (as per vote ), what will IROs do when they switch the provider?

[janinamincer-daszkiewicz]

They should take their approved IIAs with them to a new provider.

[umesh-qs]

They should take their approved IIAs with them to a new provider.

Please explain how.

[janinamincer-daszkiewicz]

By export/import.

[umesh-qs]

By export/import. And this is coming from DG EAC, or your idea?

[skishk]

I think this must be the normal process to migrate all the information about an IIA on the new provider

[janinamincer-daszkiewicz]

Yes, and this is also something which needs to be described in detail (e.g. how to keep identifiers unchanged). But let's first finalize IIA Approval, please.

[umesh-qs]

I think this must be the normal process to migrate all the information about an IIA on the new provider

@skishk can you please explain what you are doing currently. We do not see any process listed by DG EAC for the data migration.

[skishk]

I think this must be the normal process to migrate all the information about an IIA on the new provider

@skishk can you please explain what you are doing currently. We do not see any process listed by DG EAC for the data migration.

Unfortunately I can do nothing to solve the bad migration of others partners… Partners/providers could answer to our emails or answer to ESCI help desk and trying to fix their problem migration.

Data migration of a IIA (for example) as the word say is the migration of all information not only the content of the object but also all the action happened in it like approval.

we are continuously talking about new implementation and new modify on the network without fixing blocking problems…

[umesh-qs]

Unfortunately I can do nothing to solve the bad migration of others partners… Partners/providers could answer to our emails or answer to ESCI help desk and trying to fix their problem migration

ok. So you call good migration as keeping exact copy, including IIA ID, IIA Code, Ounit ID etc? It that practically possible with each provider having their own way to generate these IDs? It is always easy to say what should happen, but what about practical implementation?

I think you need to directly write email to DG EAC for blocking problems. I don't think they are going through these discussions even if they say so.

[skishk]

Unfortunately I can do nothing to solve the bad migration of others partners… Partners/providers could answer to our emails or answer to ESCI help desk and trying to fix their problem migration

ok. So you call good migration as keeping exact copy, including IIA ID, IIA Code, Ounit ID etc? It that practically possible with each provider having their own way to generate these IDs? It is always easy to say what should happen, but what about practical implementation?

I think you need to directly write email to DG EAC for blocking problems. I don't think they are going through these discussions even if they say so.

Yeah it’s what we will going to do.

about migration they could change id and code in my opinion but still mapped to partner IIA. So partner can see and understand that them are the same IIA, probably in this scenario a new approval is needed. the problem is when index give to you some IDs and then the GET-RESPONSE give to you a completely different ID 😅

[skishk]

And could be enough a good communication , for example the partner that is migrating tell to all his partner about that and could give to him the new corrispettive list of migrated IIA … is not very nice as a solution but at least they can find together a solution… better then having no answer when you see something strange with a partner and you cannot solve it

[umesh-qs]

Unfortunately I can do nothing to solve the bad migration of others partners… Partners/providers could answer to our emails or answer to ESCI help desk and trying to fix their problem migration

ok. So you call good migration as keeping exact copy, including IIA ID, IIA Code, Ounit ID etc? It that practically possible with each provider having their own way to generate these IDs? It is always easy to say what should happen, but what about practical implementation? I think you need to directly write email to DG EAC for blocking problems. I don't think they are going through these discussions even if they say so.

Yeah it’s what we will going to do.

about migration they could change id and code in my opinion but still mapped to partner IIA. So partner can see and understand that them are the same IIA, probably in this scenario a new approval is needed. the problem is when index give to you some IDs and then the GET-RESPONSE give to you a completely different ID 😅

Also empty 200 response in GET is permanent DELETE. So the migration as you suggest will create more problems for the IROs. That is the reason there has to be a discussion how migration should work. It is not as easy as some of Janina's comment suggest.

[janinamincer-daszkiewicz]

Also empty 200 response in GET is permanent DELETE.

The host should not expose IIA API when it is not supporting it anymore. All IIAs should be available from one point only. Why should anybody send requests to the old provider?

I am not suggesting that it is easy. Preserving ids is not easy.

[skishk]

Yeah yeah I think we all agree that is not very easy the migration but starting to communicate that to partner could be a first step for the solution. The empty response it could be seen good if then it will change id , in this scenario means it is deleted yes but reappear as new one on the other provider system . but @umesh-qs are you expecting specification for how to migrate object in EWP network? i think it is near impossible to find one solution because if you think for example in mobile phones number when you change company you can have the same phone number because they are using the same list of IDs (phone numbers) that are all unique. Here we can’t because everyone have is own way to produce IDs . This is my opinion, is why I’m saying at least providers can communicate the migration to partners to mange it

[umesh-qs]

Yeah yeah I think we all agree that is not very easy the migration but starting to communicate that to partner could be a first step for the solution. The empty response it could be seen good if then it will change id , in this scenario means it is deleted yes but reappear as new one on the other provider system .

Again your suggestion is on paper. Please translate it in terms of the manual steps and steps to be done in provider system. One quick problem. Lets say HEI has migrated to new provider. When the partner of this HEI calls IIA GET API for existing IIAs, empty response will be returned. If the IIAs are mutually approved, this is not allowed as per specification. I can neither DELETE mutually approved IIAs, not can I change IIA IDs.

but @umesh-qs are you expecting specification for how to migrate object in EWP network? i think it is near impossible to find one solution because if you think for example in mobile phones number when you change company you can have the same phone number because they are using the same list of IDs (phone numbers) that are all unique. Here we can’t because everyone have is own way to produce IDs . This is my opinion, is why I’m saying at least providers can communicate the migration to partners to mange it

Here is the problem @skishk . You are assuming that IDs will change during migration and re-approval will be needed. That is not what Janina thinks. Hence some sort of specification is definitely needed.

[janinamincer-daszkiewicz]

When the partner of this HEI calls IIA GET API for existing IIAs, empty response will be returned.

How can you call the partner at the old provider? There is no such endpoint in the catalogue file. There is only one, for the new provider.

[demilatof]

What you are saying requires two private agreements:

1. Between the HEI and the current provider, so that if the partnership ends the provider must give all the data to the HEI in a useful format
2. Between the HEI and the incoming provider, so that the new provider accepts the extra effort of importing data

Without them the specifications worth nothing. How to do should not be a great problem, I think that all the XML files exchanged could be enough (the old provider invokes all its APIs and save the result to a file). The new provider can easily make compatible the old IIA-IDs and its method of generating the new ones, just importing the old and adding an unused prefix to the new generated IDs.

[mkurzydlowski]

I will try to get back to the original question and respond to:

https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/109#issuecomment-1636748366

If I understand @demilatof's question correctly he is asking if A should still say it approves B v1 when it changes it's IIA to A v2.

I believe that A should in fact remove B v1 approval the moment it changes from A v1 to A v2.

After B approves A v2, A might state that B's IIA (B v1) doesn't need to change. In such case A might approve B v1 once more and end renegotiations.

[pargentieri]

Or saying differently: do you suggest that after there is change on one side both copies should always be approved?

Exactly; if I'm not wrong, @umesh-qs is of the same opinion as me.

Is this a business need?A technical need?

It is important? Reasoning, we have found this need.