search

erasmus-without-paper / ewp-specs-api-iias

Specifications of EWP's Interinstitutional Agreements API.
MIT License
4 stars 13 forks source link

Process for correcting wrongly mapped IIAs #101

Closed umesh-qs closed 1 year ago

umesh-qs commented 1 year ago

@janinamincer-daszkiewicz can you please confirm if this is correct.

  1. Partner A maps IIA of partner B which it received earlier
  2. Partner A call IIA CNR API of partner B
  3. Partner B call IIA GET API of partner A
  4. Partner B maps the IIA based on the mapping in IIA GET of partner A
  5. Partner B realized that partner A has mapped wrong IIAs
  6. Partner B removes the mapping in their system and calls CNR of partner A
  7. Partner A calls IIA GET API of partner B and sees no mapping
  8. Partner A also unlinks the IIAs and wait for partner B to do the mapping.
  9. Partner B maps a different IIA and calls IIA CNR of partner A
  10. Partner A calls IIA GET of partner B and sees the new linking and does the same in their system.
janinamincer-daszkiewicz commented 1 year ago

Yes, if there is wrong mapping it has to be corrected and one of the partners should start (points 8-10).

umesh-qs commented 1 year ago

Yes, if there is wrong mapping it has to be corrected and one of the partners should start (points 8-10).

@kkaraogl I hope Dashboard is able to handle this scenario.

demilatof commented 1 year ago

Yes, if there is wrong mapping it has to be corrected and one of the partners should start (points 8-10).

@kkaraogl I hope Dashboard is able to handle this scenario.

I hope too, but I think that at point 5 it would be better if B contacts A by mail/phone. It seems to me that you do everything in an automatic way, relying on partner information to map you IIA. For us it could only be a suggestion, nothing more. Our officer has to choice by his/her self the partner's IIA.

Therefore, we could already have the right mapping and ask partner to correct its mapping. Obviously, until then we will not send an Approval CNR.

kkaraogl commented 1 year ago

What is the problem that these steps are aimed to correct? Is it for implementations that do not support 1:1 mapping? I need some context before responding. I don't understand Step 5. Step 7 will probably create duplicate in Partner A. There is no way to determine if this is a new IIA or a correction (unmapping/unbinding?) for an existing one.

demilatof commented 1 year ago

What is the problem that these steps are aimed to correct? Is it for implementations that do not support 1:1 mapping?

As concern what these steps are aimed to correct, I try to explain what I understood from @umesh-qs' description. The problem concerns a bad mapping: e.g. you (A) mapped your ID A1 with my ID B1. I realized that you made a bad mapping, because comparing the two IIAs I noticed that your A1 IIA is the same of my B2 IIA, not B1.

ps: personally I would ignore your IIA and I would email you to explain that your IIA A1 has a bad mapping. In the mean time I add A1 to my B1 IIA and then I send you an IIA-CNR. Are you able to modify the mapping in your A1 IIA, the one previously mapped by mistake with B1?

Step 7 will probably create duplicate in Partner A. There is no way to determine if this is a new IIA or a correction (unmapping/unbinding?) for an existing one.

Just to understand: every time you see one of my IIAs without a mapping, you create a new IIA in your system? And if yes, only when you receive an IIA-CNR or even when you look for them starting from an IIA-Index?

kkaraogl commented 1 year ago

Let's wait for Umesh to provide a decription of the problem.

@demilatof Dashboard acts only when it receives IIA-CNR from the partner. But there are other partners that heavily utilize the index endpoint. Not sure if we've tested with each other. Are you in the production network? If not, please ping us to test, whenever you feel ready.

umesh-qs commented 1 year ago

What is the problem that these steps are aimed to correct? Is it for implementations that do not support 1:1 mapping?

As concern what these steps are aimed to correct, I try to explain what I understood from @umesh-qs' description. The problem concerns a bad mapping: e.g. you (A) mapped your ID A1 with my ID B1. I realized that you made a bad mapping, because comparing the two IIAs I noticed that your A1 IIA is the same of my B2 IIA, not B1.

ps: personally I would ignore your IIA and I would email you to explain that your IIA A1 has a bad mapping. In the mean time I add A1 to my B1 IIA and then I send you an IIA-CNR. Are you able to modify the mapping in your A1 IIA, the one previously mapped by mistake with B1?

Step 7 will probably create duplicate in Partner A. There is no way to determine if this is a new IIA or a correction (unmapping/unbinding?) for an existing one.

Just to understand: every time you see one of my IIAs without a mapping, you create a new IIA in your system? And if yes, only when you receive an IIA-CNR or even when you look for them starting from an IIA-Index?

Yes this is what I mean. But I will not want my users to contact Dashboard. Instead I would like them to correct the mapping and send IIA CNR. This would mean that my partner would unlink the IIA triggering a CNR and then they would map the correct IIA which would trigger another CNR.

Also automatic creation of IIA when there is no mapping is a risky process. You are allowing your system to be screwed because of some problem in partner system. This can become worse if your system is doing bulk refresh and there is a problem in partner system, responding all IIA with empty partner IIA

demilatof commented 1 year ago

@demilatof Dashboard acts only when it receives IIA-CNR from the partner. But there are other partners that heavily utilize the index endpoint. Not sure if we've tested with each other. Are you in the production network? If not, please ping us to test, whenever you feel ready.

If you don't receive an IIA-CNR, don't you initiate any process? Thanks for your offer, we are still in dev; do you have an hei_id to contact the dashboard in dev? We are doing the final internal test

kkaraogl commented 1 year ago

Ok, I am now aware of what this is about. The issue is the partner changed their local ID, after they previously shared another local ID, i.e changing your local ID in the midst of negotiation. @umesh-qs please confirm.

Step 7 is tricky. There is no way for Partner A to identify that this is a correction in the local ID of the partner B of an IIA previously shared by simply doing an IIA Get. @umesh-qs do you have in mind what check should Partner A do to identify such a case by only parsing the IIA get?

umesh-qs commented 1 year ago

Ok, I am now aware of what this is about. The issue is the partner changed their local ID, after they previously shared another local ID, i.e changing your local ID in the midst of negotiation. @umesh-qs please confirm.

@kkaraogl most likely at the start of negotiation. But not limited to that. As mentioned earlier, there can be some issue that causes partner IIA to be passed as empty in all IIAs

Step 7 is tricky. There is no way for Partner A to identify that this is a correction in the local ID of the partner B of an IIA previously shared by simply doing an IIA Get. @umesh-qs do you have in mind what check should Partner A do to identify such a case by only parsing the IIA get?

@kkaraogl Partner A should mark the IIA in error and ask institution to contact the partner. Then proceed based on discussion Or Partner A should unlink the IIA in their system and ask the partner to send correct linking or allow their client to provide correct linking.

kkaraogl commented 1 year ago

@umesh-qs what is there on the XML response of the IIA Get, in Step 7, that will make Partner A determine that this IIA should be marked "in error" so that Partner A proceeds to the next steps?

umesh-qs commented 1 year ago

@umesh-qs what is there on the XML response of the IIA Get, in Step 7, that will make Partner A determine that this IIA should be marked "in error" so that Partner A proceeds to the next steps?

IIAs that partner A had linked earlier are not linked any more.

kkaraogl commented 1 year ago

@umesh-qs not sure what this means. There has to be something in the XML response to drive Partner A to identify such a case, and allow them to proceed in next steps.

demilatof commented 1 year ago

Ok, I am now aware of what this is about. The issue is the partner changed their local ID, after they previously shared another local ID, i.e changing your local ID in the midst of negotiation. @umesh-qs please confirm.

@kkaraogl I don't know if @umesh-qs agrees with me, but I think that the above issue could not be the only one. It seems to me that you are blaming the partner that changed its local ID, as if you're waiting for your partner doing something (mapping and sharing); but it may happen that on your side someone has mapped the IIA-Ids before, and therefore you are the first who mapped the two IDs. And you could make an error.

Are you waiting for your partner's IIA-CNR before mapping yours IIA?

kkaraogl commented 1 year ago

@umesh-qs if Partner A calls the IIA Get in Step 7, could you please list how many and which IDs is gonna find in there?

umesh-qs commented 1 year ago

@umesh-qs if Partner A calls the IIA Get in Step 7, could you please list how many and which IDs is gonna find in there?

Let me try to explain from Dashboard perspective as you most likely are thinking in that direction only

  1. MoveOn creates new IIA (IIA1) and shares it with Dashboard with empty partner IIA ID
  2. Dashboard automatically creates IIA (IIA2) in their system and share their IIA with MoveOn
  3. MoveOn automatically links Dashboard IIA (IIA2) with their IIA (IIA1)
  4. MoveOn user finds that there is already an IIA (IIA3) shared by Dashboard earlier
  5. MoveOn user unlinks IIA2 with IIA1. CNR sent to Dashboard
  6. Dashboard pulls IIA1 from MoveOn and finds IIA2 missing.
  7. MoveOn user links IIA3 with IIA1. CNR sent to Dashboard.

What is Dashboard doing in step 6?

I cannot be more detailed then this. I hope this is clear.

kkaraogl commented 1 year ago

@umesh-qs I am investigating of whether the steps you propose can be applied globally. Nothing to do with the Dashboard or MoveOn.

The above scenario could work because Partner A initiated the IIA and wishes to change their local ID, but it is not the whole story.

Could you please detail it the same way with Partner A initiating the IIA but Partner B wishes to change their local IIA ID after they previously shared another local ID?

umesh-qs commented 1 year ago

@umesh-qs I am investigating of whether the steps you propose can be applied globally. Nothing to do with the Dashboard or MoveOn.

The above scenario could work because Partner A initiated the IIA and wishes to change their local ID, but it is not the whole story.

Could you please detail it the same way with Partner A initiating the IIA but Partner B wishes to change their local IIA ID after they previously shared another local ID?

@kkaraogl Can you please respond on what Dashboard is currently doing in point 6?

kkaraogl commented 1 year ago

@umesh-qs again, not a matter of Dashboard. Everyone could accommodate step 6, including Dashboard, if we agree. It is technically feasible.

Now back to the other scenario and its technical feasibility. Could you please detail it the same way with Partner A initiating the IIA but Partner B wishes to change their local IIA ID after they previously shared another local ID?

umesh-qs commented 1 year ago

@umesh-qs again, not a matter of Dashboard. Everyone could accommodate step 6, including Dashboard, if we agree. It is technically feasible.

@kkaraogl will deal with other systems later on. I am asking this question specifically to you (Dashboard). How are you handling this currently?

Now back to the other scenario and its technical feasibility. Could you please detail it the same way with Partner A initiating the IIA but Partner B wishes to change their local IIA ID after they previously shared another local ID?

@kkaraogl Not sure what you want from me. You already listed the scenario.

kkaraogl commented 1 year ago

@umesh-qs we don't. This is a new process you are proposing, right? We are now collaboratively trying to find a way to cover this.

But I am saying that it is technically feasible to cover this specific scenario. When Partner B creates it and Partner B wishes to change its local ID, Partner A can identify such a case from the IIA Get (A's local ID is not anymore in the response), and proceed with the "unlinking" steps.

When, let's say Partner A creates it, both partners have exchanged IDs, and then Partner B wishes to change its local ID, Partner A cannot identify this case by simply doing an IIA Get after B's CNR ( it will only find B's new IIA ID in the response, right?), and cannot proceed with the "unlinking" steps. The steps you are proposing will not work in these cases.

Unless I don't see something clearly... In which case, please do correct me.

demilatof commented 1 year ago
  1. MoveOn user finds that there is already an IIA (IIA3) shared by Dashboard earlier
  2. MoveOn user unlinks IIA2 with IIA1. CNR sent to Dashboard
  3. Dashboard pulls IIA1 from MoveOn and finds IIA2 missing.
  4. MoveOn user links IIA3 with IIA1. CNR sent to Dashboard.

Point 5 may happen, so could be interesting to know what happens at point 6. But why are you doing this in 2 steps? At point 5 you could unlink IIA2, link IIA3 and send CNR.

umesh-qs commented 1 year ago
  1. MoveOn user finds that there is already an IIA (IIA3) shared by Dashboard earlier
  2. MoveOn user unlinks IIA2 with IIA1. CNR sent to Dashboard
  3. Dashboard pulls IIA1 from MoveOn and finds IIA2 missing.
  4. MoveOn user links IIA3 with IIA1. CNR sent to Dashboard.

Point 5 may happen, so could be interesting to know what happens at point 6. But why are you doing this in 2 steps? At point 5 you could unlink IIA2, link IIA3 and send CNR.

Any change has to have a CNR. It is user driven so user might not link it immediately. I need to keep partner updated with the latest status. This is just one example where it is done with client knowledge. Imagine there is a problem and all IIAs have partner ID empty. If Dashboard or any other provider can do bulk updates. So it is important to know how systems handle it, specially Dashboard that is catering to large user base.

umesh-qs commented 1 year ago

@umesh-qs we don't. This is a new process you are proposing, right? We are now collaboratively trying to find a way to cover this.

But I am saying that it is technically feasible to cover this specific scenario. When Partner B creates it and Partner B wishes to change its local ID, Partner A can identify such a case from the IIA Get (A's local ID is not anymore in the response), and proceed with the "unlinking" steps.

When, let's say Partner A creates it, both partners have exchanged IDs, and then Partner B wishes to change its local ID, Partner A cannot identify this case by simply doing an IIA Get after B's CNR ( it will only find B's new IIA ID in the response, right?), and cannot proceed with the "unlinking" steps. The steps you are proposing will not work in these cases.

Unless I don't see something clearly... In which case, please do correct me.

@kkaraogl I am not proposing a new process. I am highlighting potential problem with some systems, if not handled properly.

demilatof commented 1 year ago

Any change has to have a CNR.

@umesh-qs this is your interpretation. For complex changes we'll send a CNR when finished, a CNR for every little change is only confusing. Anyway, the change you propose can be done in one shot.

umesh-qs commented 1 year ago

Any change has to have a CNR.

@umesh-qs this is your interpretation. For complex changes we'll send a CNR when finished, a CNR for every little change is only confusing. Anyway, the change you propose can be done in one shot.

Of course it is up to individual provider to interpret. In our system we do not restrict. So user can unlink and link it back, or contact the partner to correct it. But then even without CNR situation remains the same. There would be systems doing bulk refresh of IIA without CNR.

demilatof commented 1 year ago

There would be systems doing bulk refresh of IIA without CNR.

Using the index, because for whatever reasons we could miss CNR. I think that in EWP project there is a lot of space for improving and very little availability for improving something. E.g.: all we know that we cannot rely on a CNR. But it is important to know if a CNR was sent, it can give a sort of timings declaring what the partner aimed to do.

I think that an improvement could be adding two elements in IIA, outside the cooperation condition:

  1. IIA_CNR_sent
  2. Approval_CNR_sent

They can help knowing if we are seeing an IIA that we miss due to a CNR lost or not. What I'm not sure: may be helpful adding the hash code to specify at what version of IIA was sent the CNR? I think yes, but I need to evaluate better

umesh-qs commented 1 year ago

There would be systems doing bulk refresh of IIA without CNR.

Using the index, because for whatever reasons we could miss CNR. I think that in EWP project there is a lot of space for improving and very little availability for improving something. E.g.: all we know that we cannot rely on a CNR. But it is important to know if a CNR was sent, it can give a sort of timings declaring what the partner aimed to do.

I think that an improvement could be adding two elements in IIA, outside the cooperation condition:

  1. IIA_CNR_sent
  2. Approval_CNR_sent

I think it is overengineering. I would rather have my system designed internally to not to let any other provider screw it.

They can help knowing if we are seeing an IIA that we miss due to a CNR lost or not. What I'm not sure: may be helpful adding the hash code to specify at what version of IIA was sent the CNR? I think yes, but I need to evaluate better

spinho-uporto commented 1 year ago

In the following situations, should we allow the correction of the mapping?

  1. Our agreement was already approved and the partner agreement was not.
  2. We already approved the partner agreement, but the partner didn't approve ours.
umesh-qs commented 1 year ago

Yes. Please note there is no restriction on changing an agreement that is approved from both side.

fioravanti-unibo commented 1 year ago

I agree with Umesh: as an example, in our system (University of Bologna) the operator can always change an incorrect mapping, but we think that EWP Dashboard cannot handle this scenario.

skishk commented 1 year ago

yeah, in the real life of Agreements they could be change in any time for different reasons and they could be changed in their mapping with others Agreements for different reason. So i think is better to give to all IROs the possibility to work well with a good flexibility on the needed actions to not block the normal/real work of IROs like unfortunately is happening now...

kkaraogl commented 1 year ago

Yes. Please note there is no restriction on changing an agreement that is approved from both side.

This is not true for all EWP partners.

I agree with Umesh: as an example, in our system (University of Bologna) the operator can always change an incorrect mapping, but we think that EWP Dashboard cannot handle this scenario.

Specs are pretty clear about this. Unless there is a common procedure followed by everyone, we all have to comply with what we have now.

This new proposal by Umesh discussed in this thread to tackle the issue of changing IDs in the midst of the flow, is technically not wholesome (in my opinion), as I've previously shared.

umesh-qs commented 1 year ago

Yes. Please note there is no restriction on changing an agreement that is approved from both side.

This is not true for all EWP partners.

Then those partners are not following mandatory business requirement. Is Dashboard one of them?

I agree with Umesh: as an example, in our system (University of Bologna) the operator can always change an incorrect mapping, but we think that EWP Dashboard cannot handle this scenario.

Specs are pretty clear about this. Unless there is a common procedure followed by everyone, we all have to comply with what we have now.

Not sure what you mean by this point.

This new proposal by Umesh discussed in this thread to tackle the issue of changing IDs in the midst of the flow, is technically not wholesome (in my opinion), as I've previously shared.

It is not a new process. You are probably assuming it as a new process

kkaraogl commented 1 year ago

The community discusses only recently on how to handle changes in approved by both IIAs, per the latest mandatory business requirements.

Hence the discussions in the Infrastructure Forum and the voting options on how to officially implement this, lead and guided by the specs.

The fact that you've implemented it unilaterally in a non-specs-regulated way, is another issue.

Let's wait for the community to decide first on how to handle this, technically, before writing "Please note there is no restriction on changing an agreement that is approved from both side" as it is some kind of global truth.

kkaraogl commented 1 year ago

By sheer luck, the email presenting and asking the providers' community to vote on the specs options of making changes to approved by both IIAs, just arrived in my inbox.

umesh-qs commented 1 year ago

You always tend to divert from one point to another. You mentioned that spec is very clear on it. Where does the spec say changes to approved IIA is not allowed? In fact the mandatory business requirement tied to the spec just tells that changes to approved IIA are allowed. I would like to mention here that we have this even before work on Dashboard started and even before you were part of it. Also there are already providers who have implemented the process to allow changes after IIA is approved. Probably you are not aware of lot of stuff that happened before you just like you were not aware how IIAs were approved earlier compared to how it is done now. Please do not generalize how Dashboard works. You even implemented auto creation of IIA and sharing without user input. Does the spec say this is allowed? So please get out of the notion that whatever Dashboard does must be followed by everyone.

umesh-qs commented 1 year ago

By sheer luck, the email presenting and asking the providers' community to vote on the specs options of making changes to approved by both IIAs, just arrived in my inbox.

Too much of a coincidence. But that doesn't change the fact the specs do not restrict changes in approved IIA and the fact that it is a mandatory business requirement tied to IIA spec

demilatof commented 1 year ago

Let's wait for the community to decide first on how to handle this, technically, before writing "Please note there is no restriction on changing an agreement that is approved from both side" as it is some kind of global truth.

@kkaraogl Could you show me where is written that once approved by both parties, an IIA cannot be modified and approved again as it was the first time? The community is discussing about the problems this solution involves, and how to agree on a better procedure. But this doesn't mean that currently the specifications are saying "once approved by both parties, the IIA cannot be modified". And therefore, the general procedure is the only still valid

janinamincer-daszkiewicz commented 1 year ago

We want to prepare a test scenario for this use case. Who else wants to comment? Do we already have a common understanding on how it should look like?

kkaraogl commented 1 year ago

Devil is in the details. The proposed steps do not tackle the issue in a wholesome way, in my opinion. There are cases, as I've already shared in comments above, that have not been taken into account.

@janinamincer-daszkiewicz I saw you've shared the issue in the email alias. Hopefully, more colleagues will come and share their technical opinions of whether this proposal is feasible for all the possible cases.

janinamincer-daszkiewicz commented 1 year ago

We discussed this issue during the technical workshop in Thessaloniki (30-31 March 2023). The final conclusion was that we need strict and simple rules because even if some partners can implement sophisticated solutions and cope with the problem of mapping changes, some may not. Also the whole mapping business will create additional confusion for end users. If we decide that changing mapping is like any other change (e.g. number of mobilities) and can be done at any time in an asynchronous way in a distributed system we may have many scenarios to discuss and elaborate (and more potential errors).

The proposed approach is the following. IIA-id is a key of the copy of the IIA (its primary key). A pair of (mapped) copies is identified by a pair of iia-ids. They should also be treated as the primary key. Different primary keys mean that we have different objects. If the system find out that the local IIA with some id A1 once mapped with id B1 now comes from the partner mapped with another id B2, it should treat this as an error. Identifiers are identifiers and should not be freely mapped and unmapped.

Instead of changing the mapping a system can change the (content of the) object and keep the mapping.

demilatof commented 1 year ago

The proposed approach is the following. IIA-id is a key of the copy of the IIA (its primary key). A pair of (mapped) copies is identified by a pair of iia-ids. They should also be treated as the primary key. Different primary keys mean that we have different objects. If the system find out that the local IIA with some id A1 once mapped with id B1 now comes from the partner mapped with another id B2, it should treat this as an error. Identifiers are identifiers and should not be freely mapped and unmapped.

Instead of changing the mapping a system can change the (content of the) object and keep the mapping.

Are we talking about mutual approved IIA? If so, I may agree; otherwise, I have some doubts and don't understand what is the difficulty to disassociate an IIA and to reset the process. If A1-B1 is a key, there is no problem to make a second key with A1-B2, keeping or not the old key.

janinamincer-daszkiewicz commented 1 year ago

Are we talking about mutual approved IIA?

Mutually approved objects must not be mapped/unmapped.

If so, I may agree; otherwise, I have some doubts and don't understand what is the difficulty to disassociate an IIA and to reset the process. If A1-B1 is a key, there is no problem to make a second key with A1-B2, keeping or not the old key.

Because it adds complexity. One partner changes mapping from A1/B1 to A2/B1, in the same time the other partner changes mapping from A1/B1 to A1/B2 etc.

demilatof commented 1 year ago

Because it adds complexity. One partner changes mapping from A1/B1 to A2/B1, in the same time the other partner changes mapping from A1/B1 to A1/B2 etc.

Already now a partner can map A1/B1 and the other A1/B2. And what we have to do? Thrash away everything or one of the two partners has to correct his mapping? We don't want to interfere with internal systems, but some internal system can interfere with the whole network? There is no much complexity in voiding a key for IIAs not mutually approved. If someone finds this too complex may he/she should ask why to themselves.

Identifiers are identifiers and should not be freely mapped and unmapped.

Instead of changing the mapping a system can change the (content of the) object and keep the mapping.

And IIA-ID is the "unique surrogate ID of this IIA" and not for a different IIA. You instead are suggesting to infringe the specification for a not clear complexity and to transform the IIA in something else.

janinamincer-daszkiewicz commented 1 year ago

Thrash away everything or one of the two partners has to correct his mapping?

Yes. But making a copy and starting from scratch is not a big deal.

There is no much complexity in voiding a key for IIAs not mutually approved. There is a lot of complexity of understanding what is going on, what is allowed, what not and how to recover from this situation.

And IIA-ID is the "unique surrogate ID of this IIA" and not for a different IIA.

Replacing current content and keeping the previous identifiers will simplify the understanding.

for a not clear complexity

Complexity is very clear. We have evidence in the network with much less complex issues which create problems like putting many emails into a field for one email. or not ordering academic years, or not keeping the format of the telephone number. You can find many examples here: https://stats.erasmuswithoutpaper.eu/monitoring.

janinamincer-daszkiewicz commented 1 year ago

Anyway, DG EAC will make a final decision.

demilatof commented 1 year ago

Yes. But making a copy and starting from scratch is not a big deal.

May be for some implementations that are interested in this solution, not for all. I hope we all agree that EWP is not living alone; we have other tools that share an IIA and its IIA-Id. We cannot change their content to satisfy the incapacity of someone to change a mapping.

Replacing current content and keeping the previous identifiers will simplify the understanding.

It's your opinion and may infringe the specifications In my opinion, in the master-master model my IIA-ID represent a given IIA; there is no simplification if it could represent something different.

Complexity is very clear. We have evidence in the network with much less complex issues which create problems like putting many emails into a field for one email. or not ordering academic years, or not keeping the format of the telephone number. You can find many examples here: https://stats.erasmuswithoutpaper.eu/monitoring.

You're not giving me any example of the complexity in changing the mapping. What you are listing are mistakes that nothing has to do with your proposal or with the complexity in changing the mapping.

Anyway, DG EAC will make a final decision.

Hoping they understand the problem, because it's mainly a technical matter that could interfere with internal systems. Before asking DG EAC I think that we (all) should have to discuss on GitHub and vote during an Infrastructure Forum.

janinamincer-daszkiewicz commented 1 year ago

DG EAC will decide if voting is needed.

demilatof commented 1 year ago

DG EAC will decide if voting is needed.

...if voting is needed about:

The proposed approach is the following.

That is: you propose something to DG EAC that modifies the behavior of internal system without consulting the providers and if DG EAC says that there is no need to vote, this proposal becomes a requirement without a shared discussion?