Who is the master of an IIA? Have been the specifications changed?

[demilatof]

I start a new issue to avoid to taint Emkas question.

I think we need to clear if the specifications are still valid or if in the meantime something is changed. Everything starts from what @janinamincer-daszkiewicz said here:

It calls get for iia-id-A and gets IIA with the pair of identifier iia-id-A and iia-id-B. He has no IIA with iia-id-B, so he reports an error and has every right to do so. It doesn't matter what else this IIA consists of.

One of the test scenarios will be just such a scenario and systems that, like A, deliberately use such a solution will be considered non-compliant with the specification.

I apologize if I return to this problem, but in my opinion this is a completely wrong approach and against the explanation of the EWP Mobility Process, that is part of the specification (otherwise, please remove it).

In the section Handling Interinstitutional Agreements (IIAs) it's clearly stated that:

Each partner uses his own ID for the IIA, so partners will need to manually "bind" their local agreements with their remote counterparts (by storing the remote partners' IIA IDs) before they will be able to compare them

Therefore, I correctly ask my IROs to bind our local IIAs with the one of the partner. You cannot pretend that my system automatically undoes something that my IROs have explicitly done. It doesn't exist, not in the Italian public administration.

If ours IROs perform an action, it's ours IROs that have to undo it, if they accept to accomplish with it. It's not up to you intrude our system neither our documents with your claims. We may decide to keep track of what happens to our documents exposed to the EWP network and if we have an agreement that misses its counterpart, we are fully legitimated to keep it as a proof, including the information about the partner's deleted IIA ID. Don't forget that it's our IIA, not yours. If and when they will decide to change the mapping, they (and not you) are entitled to do with our copy of the IIA.

The EWP Mobility Process explanation also describes what you, and not me, have to do in this case::

A partner can also peek on draft IIA proposals published by the other partner without actually storing them on his own server

Therefore, if you get my IIA with your deleted IIA ID inside and you detect the problem (for you), the only action you can do is discarding my IIA without storing on your server. The specification doesn't allow you to report me as a bad implementation; my implementation is specification compliant and Italian public administration law compliant.

You cannot intrude my system and pretend do decide what I can or cannot indicate in my IIA.

And, last but not least, we are not compelled to change your IIA Id in our IIA not even if you send and IIA CNR to notify that you have un-mapped our IIA from your. You cannot claim nothing about our IIA, you can only approve it or not. The IIA formation is an internal process that respect the decision-making autonomy of who decided the points of the agreement, as ensured by the master-master model.

These are the basis of EWP, if someone doesn't agree I think we may have a huge problem. For me, the question ends here, there is no place for other counter argumentation.

[umesh-qs]

@demilatof it has already been clarified by Janina with DG EAC in loop (in last IF meeting). Which means it is validated by DG EAC. You might want to reach out to DG EAC directly. I do not see a point in discussing same stuff again.

[demilatof]

@demilatof it has already been clarified by Janina with DG EAC in loop (in last IF meeting). Which means it is validated by DG EAC. You might want to reach out to DG EAC directly. I do not see a point in discussing same stuff again.

@umesh-qs I think I have been enough clear: your assumption, Janina's clarification or DG EAC public speaking worth nothing against the specifications. If you all are right, the specifications must be changed and providers officially informed, because the official developer page, at point 6.1.1 address to GitHub specification, where it clearly stated what are the basic features of the IIAs:

All partners are equal. There is no "master" of the agreement. Since all partners of a single IIA are allowed to serve their copies of this IIA, therefore multiple conflicting copies of a single IIA may exist in the network.

If you, or anyone else, think to infringe this rule, I want that the exception is clearly described and documented in the specifications, not generally discussed in a GitHub issue or during a meeting, doesn't matter who expressed it.

That's all, no more to say. My implementation will respect only the Italian law and the official specification, you can object whatever you want, but if it's not explicitly documented in the specifications I have not to comply and no one could impose me.

[umesh-qs]

@demilatof it has already been clarified by Janina with DG EAC in loop (in last IF meeting). Which means it is validated by DG EAC. You might want to reach out to DG EAC directly. I do not see a point in discussing same stuff again.

@umesh-qs I think I have been enough clear: your assumption, Janina's clarification or DG EAC public speaking worth nothing against the specifications. If you all are right, the specifications must be changed and providers officially informed, because the official developer page, at point 6.1.1 address to GitHub specification, where it clearly stated what are the basic features of the IIAs:

All partners are equal. There is no "master" of the agreement. Since all partners of a single IIA are allowed to serve their copies of this IIA, therefore multiple conflicting copies of a single IIA may exist in the network.

If you, or anyone else, think to infringe this rule, I want that the exception is clearly described and documented in the specifications, not generally discussed in a GitHub issue or during a meeting, doesn't matter who expressed it.

That's all, no more to say. My implementation will respect only the Italian law and the official specification, you can object whatever you want, but if it's not explicitly documented in the specifications I have not to comply and no one could impose me.

Hi @demilatof . You are being naïve here. Who has the authority to change the specification? Who has the authority to say what is the interpretation of the current specification? It really does not matter how you interpret the current specification. What matters is how DG EAC interprets it. What option do you have, when you say you will not implement the way it is interpreted by DG EAC? Only you will be at loss, as your APIs will not be approved to go live.

[demilatof]

Hi @demilatof . You are being naïve here. Who has the authority to change the specification? Who has the authority to say what is the interpretation of the current specification? It really does not matter how you interpret the current specification. What matters is how DG EAC interprets it. What option do you have, when you say you will not implement the way it is interpreted by DG EAC? Only you will be at loss, as your APIs will not be approved to go live.

This is your assumption, we are not in a common law system, where a public decision rewrites the law. The specifications must be considered as in a civil law system: if a rule is a golden rule, only a written statement can confute it. If someone thinks in a different way, it's his problem or lawyers' question. Not mine.

Short answer: who has the authority to change the specification MUST change the specification it he/she think that something should act in a different way. Speaking worth nothing.

[umesh-qs]

Hi @demilatof . You are being naïve here. Who has the authority to change the specification? Who has the authority to say what is the interpretation of the current specification? It really does not matter how you interpret the current specification. What matters is how DG EAC interprets it. What option do you have, when you say you will not implement the way it is interpreted by DG EAC? Only you will be at loss, as your APIs will not be approved to go live.

This is your assumption, we are not in a common law system, where a public decision rewrites the law. The specifications must be considered as in a civil law system: if a rule is a golden rule, only a written statement can confute it. If someone thinks in a different way, it's his problem or lawyers' question. Not mine.

Short answer: who has the authority to change the specification MUST change the specification it he/she think that something should act in a different way. Speaking worth nothing.

You are hinting towards a legal route. May be you can, but I am not sure on what basis. You chose to be part of EWP network on certain terms. Good Luck if you want to explore that route.

[demilatof]

Hi @demilatof . You are being naïve here. Who has the authority to change the specification? Who has the authority to say what is the interpretation of the current specification? It really does not matter how you interpret the current specification. What matters is how DG EAC interprets it. What option do you have, when you say you will not implement the way it is interpreted by DG EAC? Only you will be at loss, as your APIs will not be approved to go live.

This is your assumption, we are not in a common law system, where a public decision rewrites the law. The specifications must be considered as in a civil law system: if a rule is a golden rule, only a written statement can confute it. If someone thinks in a different way, it's his problem or lawyers' question. Not mine. Short answer: who has the authority to change the specification MUST change the specification it he/she think that something should act in a different way. Speaking worth nothing.

You are hinting towards a legal route. May be you can, but I am not sure on what basis. You chose to be part of EWP network on certain terms. Good Luck if you want to explore that route.

I think you don't remember well what are these "certain terms", otherwise you should well know this statement:

Developers chosen by the partners SHOULD:

• Understand Git and be able to work with it fluently, in order to continually keep track and review all the changes to the specifications.

The document and specifications are only this, not your interpretation, Janina explanation or DG-EAC more or less technical recap, neither a GitHub discussion.

I think you cannot ask your customer extra money because someone said that something is changed, without writing it in the specification, something that could even be changed again in a few days. Your customer most probably would want to have the proof that the change is real, approved and documented (specification). If you want to develop code in a world where the written specifications worth less than a generic speaking, the one who needs good luck is you.

[umesh-qs]

@demilatof all your arguments are based on your interpretation of what is written in the specifications. I am not a legal expert, but, for you to defend it legally (in case your APIs are blocked), you must be able to prove that your interpretation of the specifications is the correct one. But that will obviously be a long process. I hope you don't have to take that route.

Your good luck should go to everyone else who do not support your interpretation of the specs. Not right form me to take all the good luck alone :).

[demilatof]

Your good luck should go to everyone else who do not support your interpretation of the specs.

This is not my interpretation of the specs, these are the specs. What you're trying to sell as specs are speakings, not formalized.

Anyway, I'm still waiting for an answer to this question:

Is the master-master model still valid, so that I, and no one else, decide what I can write or not in my copy of the IIA?

Yes or not, tertium non datur

[umesh-qs]

Your good luck should go to everyone else who do not support your interpretation of the specs.

This is not my interpretation of the specs, these are the specs. What you're trying to sell as specs are speakings, not formalized.

Anyway, I'm still waiting for an answer to this question:

Is the master-master model still valid, so that I, and no one else, decide what I can write or not in my copy of the IIA?

Yes or not, tertium non datur

I guess I already answered this earlier in the IF meeting. Even though it is your copy, you cannot send anything you wish, to the network. If you send something that is not supposed to, then it is an error that must be reported. Tomorrow you will claim that you can pass anything in ISCED code, since it is your IIA, and until you didn't send CNR, I have no right to pull it and report it as an error.

[demilatof]

Your good luck should go to everyone else who do not support your interpretation of the specs.

This is not my interpretation of the specs, these are the specs. What you're trying to sell as specs are speakings, not formalized. Anyway, I'm still waiting for an answer to this question: Is the master-master model still valid, so that I, and no one else, decide what I can write or not in my copy of the IIA? Yes or not, tertium non datur

I guess I already answered this earlier in the IF meeting. Even though it is your copy, you cannot send anything you wish, to the network. If you send something that is not supposed to, then it is an error that must be reported. Tomorrow you will claim that you can pass anything in ISCED code, since it is your IIA, and until you didn't send CNR, I have no right to pull it and report it as an error.

As I said, tertium non datur. You can report a 2 digit code because it infringes the XML constraints, not because I use a 4 digit code that doesn't exist. The error that can be reported are those that infringed a written rule, not data that you don't like.

The rules, please observe the rules and nothing else...

All partners are equal. There is no "master" of the agreement. Since all partners of a single IIA are allowed to serve their copies of this IIA, therefore multiple conflicting copies of a single IIA may exist in the network. These conflicts are not resolved by the system itself, but our APIs allow partners to discover such conflicts early (so that they may fix them by themselves).

[umesh-qs]

Your good luck should go to everyone else who do not support your interpretation of the specs.

This is not my interpretation of the specs, these are the specs. What you're trying to sell as specs are speakings, not formalized. Anyway, I'm still waiting for an answer to this question: Is the master-master model still valid, so that I, and no one else, decide what I can write or not in my copy of the IIA? Yes or not, tertium non datur

I guess I already answered this earlier in the IF meeting. Even though it is your copy, you cannot send anything you wish, to the network. If you send something that is not supposed to, then it is an error that must be reported. Tomorrow you will claim that you can pass anything in ISCED code, since it is your IIA, and until you didn't send CNR, I have no right to pull it and report it as an error.

As I said, tertium non datur. You can report a 2 digit code because it infringes the XML constraints, not because I use a 4 digit code that doesn't exist. The error that can be reported are those that infringed a written rule, not data that you don't like.

The rules, please observe the rules and nothing else...

All partners are equal. There is no "master" of the agreement. Since all partners of a single IIA are allowed to serve their copies of this IIA, therefore multiple conflicting copies of a single IIA may exist in the network. These conflicts are not resolved by the system itself, but our APIs allow partners to discover such conflicts early (so that they may fix them by themselves).

Let me take a scenario on your logic of anything is allowed unless not written. If I take the below statement and combine it with, DELETED IIA should not appear in the network. Below statement essentially means that if the response to any IIA is empty 200, then that IIA ID cannot be used in the network. If I go by your logic there are 2 problems with this

"Invalid (or unknown) iia_id and iia_code values MUST be ignored. Servers MUST return a valid (HTTP 200) XML response in such cases, but the response will simply not contain any information on these missing entities. If all values are unknown, servers MUST respond with an empty element. This requirement is true even when both and are set to 1."

Point 1. I can just hit your IIA GET API with random IIA ID, that you have no IIA created with, and mark in my system as DELETED. Now when you have a new IIA created in your system with the IIA ID that I randomly marked as DELETED in my system, I will not accept those IIA from you. You are blocked because the above statement does not restrict me.

Point 2. Statement talks about only IIA ID, and not in context of any endpoint. That means the IIA ID cannot be used on a different HEI ID. So I should not allow same IIA ID on a different HEI ID?

More on this. I see statement in IIA specs, "An IIA that has not been mutually approved can be deleted by removing it from the EWP network". Where does it say that the IIAs that are not deleted cannot be removed from the network? Which means I can remove IIA from the network even without deleting. Which means IIAs that at some point, were removed from the network can re-appear. And I still am looking for definition of DELETE in the specs.

[demilatof]

Let me take a scenario on your logic of anything is allowed unless not written. If I take the below statement and combine it with, DELETED IIA should not appear in the network. Below statement essentially means that if the response to any IIA is empty 200, then that IIA ID cannot be used in the network.

I've always warned about this: be careful that an empty 200 not necessarily means a deletion.

If I go by your logic there are 2 problems with this

No, you aren't going by my logic; my logic comes from a strict reading of the specification, not a free interpretation of them, as you're doing here.

"Invalid (or unknown) iia_id and iia_code values MUST be ignored. Servers MUST return a valid (HTTP 200) XML response in such cases, but the response will simply not contain any information on these missing entities. If all values are unknown, servers MUST respond with an empty element. This requirement is true even when both and are set to 1."

Point 1. I can just hit your IIA GET API with random IIA ID, that you have no IIA created with, and mark in my system as DELETED. Now when you have a new IIA created in your system with the IIA ID that I randomly marked as DELETED in my system, I will not accept those IIA from you. You are blocked because the above statement does not restrict me.

And if you're doing so, you are in error; I understand you're trying to climb the glasses, but you are reading the specifications as you like and not as they are. Again...

Important rules:

An IIA that has not been mutually approved can be deleted by removing it from the EWP network. .(..) Identifiers of the deleted objects MUST NOT be reused for new IIAs.

You're forgetting, or you have an interest in forgetting the word "by removing it from the EWP network". This means that you can claim that an IIA has been deleted (and an IIA ID blocked) only and only if you have previously seen it in the EWP network. Otherwise, the term "removing" would be incorrect.

Strike 1

Point 2. Statement talks about only IIA ID, and not in context of any endpoint. That means the IIA ID cannot be used on a different HEI ID. So I should not allow same IIA ID on a different HEI ID?

Again, you're forgetting, or you have an interest in forgetting the something, in this case the definition of IIA ID; it's in the get-response.xsd:

Since IIA IDs are local (unique within a single HEI, but not within the world)

Therefore, no: you cannot use the same IIA ID on a different HEI. I don't know who can check, but formally you cannot. And I add that if one of your HEI currently is using the same IIA ID for different HEIs, it's infringing the specification.

Strike 2

More on this. I see statement in IIA specs, "An IIA that has not been mutually approved can be deleted by removing it from the EWP network". Where does it say that the IIAs that are not deleted cannot be removed from the network? Which means I can remove IIA from the network even without deleting. Which means IIAs that at some point, were removed from the network can re-appear. And I still am looking for definition of DELETE in the specs.

Once more, you're forgetting, or you have an interest in forgetting something, in this case the sentence that follows the one you have reported:

An IIA can be removed from the EWP network only if it is permanently deleted

I think it's enough clear: you can remove an IIA from the EWP network only if it is permanently deleted. It's your pure invention that you can remove an IIA from the network without permanently deleting it.

Strike 3: out!

I think you should do something better to discuss with an Italian about bureaucratic aspects of a specification, the term "azzeccagarbugli" has been invented here 2 centuries ago...

[umesh-qs]

You can read specification as per your choice, but others can't. This is how Italian's discuss? I was just giving you some examples of how the specifications can be read and twisted, as you are trying to do with this topic, with no obvious support, even after trying multiple times. So probably the word "azzeccagarbugli" suits you more.

Can you show me specification that proves the point below? Therefore, no: you cannot use the same IIA ID on a different HEI. I don't know who can check, but formally you cannot. And I add that if one of your HEI currently is using the same IIA ID for different HEIs, it's infringing the specification.

[umesh-qs]

"An IIA can be removed from the EWP network only if it is permanently deleted". If only permanently deleted IIAs are allowed to be removed from the network then why does the statement says "can" and not "must".

[demilatof]

I was just giving you some examples of how the specifications can be read and twisted, as you are trying to do with this topic,

I showed you that these specifications clearly state what you can or you cannot do. You can twist them only if you forget a part; it's completely different from what I'm saying about what can I do with my IIA. I'm still waiting you show me where is written "you have to remove the mapping from your IIA, if I delete my IIA". It's your pure invention.

"An IIA can be removed from the EWP network only if it is permanently deleted". If only permanently deleted IIAs are allowed to be removed from the network then why does the statement says "can" and not "must".

Because it's written from a different point of view, starting from the removal from EWP network and not from the deletion in your system. The above sentence is the answer to this question:

Can I remove an IIA from the EWP network? Yes, but only if it permanently deleted.

I don't understand if you are serious or not: how can you use "must" in that sentence? Let's try:

An IIA MUST be removed from the EWP network only if it is permanently deleted

Really? Do you think that if someone permanently deletes an IIA in his system, he can keep it in the EWP network? If so, it's not deleted... Your hypothesis is simply absurd.

Please focus on showing where the specification says that you can impose something in the content of my copy of the IIA, avoiding to provide example of specifications that only in your interpretation are ambiguous.

[umesh-qs]

I was just giving you some examples of how the specifications can be read and twisted, as you are trying to do with this topic,

I showed you that these specifications clearly state what you can or you cannot do. You can twist them only if you forget a part; it's completely different from what I'm saying about what can I do with my IIA. I'm still waiting you show me where is written "you have to remove the mapping from your IIA, if I delete my IIA". It's your pure invention.

"An IIA can be removed from the EWP network only if it is permanently deleted". If only permanently deleted IIAs are allowed to be removed from the network then why does the statement says "can" and not "must".

Because it's written from a different point of view, starting from the removal from EWP network and not from the deletion in your system. The above sentence is the answer to this question:

Can I remove an IIA from the EWP network? Yes, but only if it permanently deleted.

I don't understand if you are serious or not: how can you use "must" in that sentence? Let's try:

An IIA MUST be removed from the EWP network only if it is permanently deleted

Really? Do you think that if someone permanently deletes an IIA in his system, he can keep it in the EWP network? If so, it's not deleted... Your hypothesis is simply absurd.

Please focus on showing where the specification says that you can impose something in the content of my copy of the IIA, avoiding to provide example of specifications that only in your interpretation are ambiguous.

You might find my interpretation as absurd, in a same way others find it absurd on how you are still insisting on the exact wording, even after it being clarified in presence of DG EAC. Anyone can interpret the specs in their own way. That doesn't matters. In case of doubt it must be clarified and in your case it has already been. There is no need to focus on mentioning the exact statement that you are looking for. There are some rules that are implicit. And one of the basic rule is that one cannot expose garbage in the network.

But you brought up an interesting interpretation. I am assuming you who have read somewhere in the specs. So please help me to point out the specification that validates the below point, you mentioned earlier. "Therefore, no: you cannot use the same IIA ID on a different HEI. I don't know who can check, but formally you cannot. And I add that if one of your HEI currently is using the same IIA ID for different HEIs, it's infringing the specification."

[demilatof]

You might find my interpretation as absurd, in a same way others find it absurd on how you are still insisting on the exact wording, even after it being clarified in presence of DG EAC.

DG EAC worths nothing if it doesn't take its own responsibilities and transform its speaking in documents (specifications).

Anyone can interpret the specs in their own way. That doesn't matters. In case of doubt it must be clarified and in your case it has already been. There is no need to focus on mentioning the exact statement that you are looking for. There are some rules that are implicit. And one of the basic rule is that one cannot expose garbage in the network.

This is not the far west, this is a European Project. Rules must be written, if one of the main rules is that exists the master-master model and that

There is no "master" of the agreement

no implicit rule can overcome the golden rule, we need an explicit one. And you forget, again, that

Since all partners of a single IIA are allowed to serve their copies of this IIA, therefore multiple conflicting copies of a single IIA may exist in the network. These conflicts are not resolved by the system itself, but our APIs allow partners to discover such conflicts early (so that they may fix them by themselves).

Who says that mine is garbage and not yours? You think that something it's garbage, but for me is the proof required by Italian law that at a given time my IIA was bound to your IIA. And now? It's up to you to ignore my IIA if you don't like it; it will be changed only if and when I IROs will decide to change it.

I could be kind and publish an IIA as you wish, but I'm not compelled to do. I must expose a well formed XML document, it's up to you accept and approve it or not, you cannot claim anything else, you cannot decide what I have to write in it.

So please help me to point out the specification that validates the below point, you mentioned earlier. "Therefore, no: you cannot use the same IIA ID on a different HEI. I don't know who can check, but formally you cannot. And I add that if one of your HEI currently is using the same IIA ID for different HEIs, it's infringing the specification."

Let me understand... You claim that you're not interested if a rule is written or not, and then ask me this? I already addressed you, please read (and understand) the specification: get-response.xsd

and the specifications about the identifiers, as recalled by the same get-response.xsd:

Do you think to keep on going for a long time? Until now I showed you that all my claims are supported by a written specification; you have not been able to show me yet what specification allow you to claim anything from my IIA. This is the best practice in a wide project: written rule! What is written, must be observed by everyone, what is not written is upon each one to take care of, without relying on others behaviors.

I stop here until you show me a written rule that compels me to write in my IIA what you decide for me.

[umesh-qs]

You might find my interpretation as absurd, in a same way others find it absurd on how you are still insisting on the exact wording, even after it being clarified in presence of DG EAC.

DG EAC worths nothing if it doesn't take its own responsibilities and transform its speaking in documents (specifications).

Anyone can interpret the specs in their own way. That doesn't matters. In case of doubt it must be clarified and in your case it has already been. There is no need to focus on mentioning the exact statement that you are looking for. There are some rules that are implicit. And one of the basic rule is that one cannot expose garbage in the network.

This is not the far west, this is a European Project. Rules must be written, if one of the main rules is that exists the master-master model and that

There is no "master" of the agreement

no implicit rule can overcome the golden rule, we need an explicit one. And you forget, again, that

Since all partners of a single IIA are allowed to serve their copies of this IIA, therefore multiple conflicting copies of a single IIA may exist in the network. These conflicts are not resolved by the system itself, but our APIs allow partners to discover such conflicts early (so that they may fix them by themselves).

Who says that mine is garbage and not yours? You think that something it's garbage, but for me is the proof required by Italian law that at a given time my IIA was bound to your IIA. And now? It's up to you to ignore my IIA if you don't like it; it will be changed only if and when I IROs will decide to change it.

I could be kind and publish an IIA as you wish, but I'm not compelled to do. I must expose a well formed XML document, it's up to you accept and approve it or not, you cannot claim anything else, you cannot decide what I have to write in it.

So please help me to point out the specification that validates the below point, you mentioned earlier. "Therefore, no: you cannot use the same IIA ID on a different HEI. I don't know who can check, but formally you cannot. And I add that if one of your HEI currently is using the same IIA ID for different HEIs, it's infringing the specification."

Let me understand... You claim that you're not interested if a rule is written or not, and then ask me this? I already addressed you, please read (and understand) the specification: get-response.xsd

and the specifications about the identifiers, as recalled by the same get-response.xsd:

Do you think to keep on going for a long time? Until now I showed you that all my claims are supported by a written specification; you have not been able to show me yet what specification allow you to claim anything from my IIA. This is the best practice in a wide project: written rule! What is written, must be observed by everyone, what is not written is upon each one to take care of, without relying on others behaviors.

I stop here until you show me a written rule that compels me to write in my IIA what you decide for me.

Whatever you have pointed in the specification (highlighted in red box) in your comments above is not matching your interpretation. IIAs are unique with combination of HEI and IIA ID. It is obviously best to have IIA IDs unique across EWP network, but there is no way you can guarantee uniqueness. Hence it is only a recommendation and not a rule.

Yes you are pointing to specification, but who told you that your interpretation of those specification is correct? You say that definition master master model means that you can do anything with your copy of IIA and then expose it in the network. My interpretation is that you can keep what ever you want in your local copy as long as you do not expose any invalid/corrupt data. My interpretation says that exposing an invalid IIA ID in partner section is an error and must be corrected.

By the way, where is it written what errors can be reported to monitoring API and what cannot?

[demilatof]

Whatever you have pointed in the specification (highlighted in red box) in your comments above is not matching your interpretation. IIAs are unique with combination of HEI and IIA ID.

OK, now I understand that you may have problem understanding the specification., so this is really last time a I answer you. The sentence "all your identifiers still MUST uniquely identify your entities within each single HEI you cover" means that the ID must be unique for any single HEI you mange, not for any single HEI you communicate with. Your IIA, your unique IIA ID per (your) HEI. There is no place for interpretation. Cover means under your management

By the way, where is it written what errors can be reported to monitoring API and what cannot?

It's written on the monitoring API page here

This API allows clients in the EWP network to inform the network's administrators about any issues encountered when making requests.

If my XML is well formed and complain all the XSD "must", you haven't any issue when you make requests to me.

And here...

When to call Clients SHOULD call this API upon detecting any problem with communication with any of the servers in the EWP network, ... A general rule of thumb is to call this API every time you perform error handling or catch an exception when making a request.

You're confusing the envelope with the letter. You can report whatever you want, the server accepts even a report where you complain that someone is kidding you, but the monitoring API page doesn't list this kind of problems as interesting for the administrator. You could be the first, if you want, among more than 1200 reports; all of them currently refer to an infringed specification (an explicit specification).

https://stats.erasmuswithoutpaper.eu/monitoring/?group_by=&date_from=2023-01-01&http_code=200&api_name=iias

[umesh-qs]

Whatever you have pointed in the specification (highlighted in red box) in your comments above is not matching your interpretation. IIAs are unique with combination of HEI and IIA ID.

OK, now I understand that you may have problem understanding the specification., so this is really last time a I answer you. The sentence "all your identifiers still MUST uniquely identify your entities within each single HEI you cover" means that the ID must be unique for any single HEI you mange, not for any single HEI you communicate with. Your IIA, your unique IIA ID per (your) HEI. There is no place for interpretation. Cover means under your management

By the way, where is it written what errors can be reported to monitoring API and what cannot?

It's written on the monitoring API page here

This API allows clients in the EWP network to inform the network's administrators about any issues encountered when making requests.

If my XML is well formed and complain all the XSD "must", you haven't any issue when you make requests to me.

And here...

When to call Clients SHOULD call this API upon detecting any problem with communication with any of the servers in the EWP network, ... A general rule of thumb is to call this API every time you perform error handling or catch an exception when making a request.

You're confusing the envelope with the letter. You can report whatever you want, the server accepts even a report where you complain that someone is kidding you, but the monitoring API page doesn't list this kind of problems as interesting for the administrator. You could be the first, if you want, among more than 1200 reports; all of them currently refer to an infringed specification (an explicit specification).

https://stats.erasmuswithoutpaper.eu/monitoring/?group_by=&date_from=2023-01-01&http_code=200&api_name=iias

I can only say that you just want to interpret the specs as you wish to. Basically what you are interpreting is that provider A hosting HEI H1, and provider B hosting HEI H2 can have save IIA ID. But Provider A hosting HEI H1 and HEI H3 cannot have same IIA ID. I find this absurd. What happens when HEI H2 switches to provider A, and transfers their IIAs to provider A?

We interpret the specification as IIA being unique with combination of HEI and IIA ID. So we can have same IIA ID for different HEI ID hosted by us, if we choose to. Probably @janinamincer-daszkiewicz can clarify this further.

On the error reporting, again you are choosing to interpret how you want. We stick to what we think is important to report. Also by your logic if it is not written then it cannot be enforced.

[umesh-qs]

@demilatof finally, below is the specification that you have been asking for. Only if you wish to interpret it, as it should and not as you want.

[demilatof]

can only say that you just want to interpret the specs as you wish to. Basically what you are interpreting is that provider A hosting HEI H1, and provider B hosting HEI H2 can have save IIA ID. But Provider A hosting HEI H1 and HEI H3 cannot have same IIA ID. I find this absurd. What happens when HEI H2 switches to provider A, and transfers their IIAs to provider A?

Where should have I said that? What I have said is that each HEI has its own set of IIAs and must have a set of unique IIA IDs for these IIAs. In other words, if HEI A has an IIA with HEI B and an IIA with HEI C, it cannot have IIA_ID=1 for B AND IIA_ID=1 even for C. Instead, the ID of B's IIA can be =2 and also the ID of C's IIA can be 2.

We interpret the specification as IIA being unique with combination of HEI and IIA ID. So we can have same IIA ID for different HEI ID hosted by us, if we choose to. Probably @janinamincer-daszkiewicz can clarify this further

"Hosted by us" is a part you've missed to say before. In this case, I agree with you, it's exactly what I have represented to you with the image about the "cover" term, when instead you had said "IIAs are unique with combination of HEI and IIA ID." that can be read as "HEIs covered by you" or "HEI you deal with".

You have said something different, before:

Point 2. Statement talks about only IIA ID, and not in context of any endpoint. That means the IIA ID cannot be used on a different HEI ID. So I should not allow same IIA ID on a different HEI ID?

This is the problem you may have: you're reading the specification as a provider that has a set of HEI, but this is your internal problem. The specifications are per HEI: the IIAs are per HEI, the IIA IDs are per HEI, the deletion is per HEI, the approval is per HEI. To stress this now we have even the manifest per HEI. Please change your point of view and switch it "per HEI", everything would be clearer.

A lot of problems you have raised don't exist if you think of them per HEI.

[umesh-qs]

can only say that you just want to interpret the specs as you wish to. Basically what you are interpreting is that provider A hosting HEI H1, and provider B hosting HEI H2 can have save IIA ID. But Provider A hosting HEI H1 and HEI H3 cannot have same IIA ID. I find this absurd. What happens when HEI H2 switches to provider A, and transfers their IIAs to provider A?

Where should have I said that? What I have said is that each HEI has its own set of IIAs and must have a set of unique IIA IDs for these IIAs. In other words, if HEI A has an IIA with HEI B and an IIA with HEI C, it cannot have IIA_ID=1 for B AND IIA_ID=1 even for C. Instead, the ID of B's IIA can be =2 and also the ID of C's IIA can be 2.

We interpret the specification as IIA being unique with combination of HEI and IIA ID. So we can have same IIA ID for different HEI ID hosted by us, if we choose to. Probably @janinamincer-daszkiewicz can clarify this further

"Hosted by us" is a part you've missed to say before. In this case, I agree with you, it's exactly what I have represented to you with the image about the "cover" term, when instead you had said "IIAs are unique with combination of HEI and IIA ID." that can be read as "HEIs covered by you" or "HEI you deal with".

You have said something different, before:

Point 2. Statement talks about only IIA ID, and not in context of any endpoint. That means the IIA ID cannot be used on a different HEI ID. So I should not allow same IIA ID on a different HEI ID?

This is the problem you may have: you're reading the specification as a provider that has a set of HEI, but this is your internal problem. The specifications are per HEI: the IIAs are per HEI, the IIA IDs are per HEI, the deletion is per HEI, the approval is per HEI. To stress this now we have even the manifest per HEI. Please change your point of view and switch it "per HEI", everything would be clearer.

A lot of problems you have raised don't exist if you think of them per HEI.

@demilatof I was just giving you examples of how anyone can read the specification as per their convenience, as you are trying to interpret the definition of master-master model and then justifying exposing anything in the network, for want of exact statement that says yes or no.

I have no problems so far, except for DELETE. I still believe it is not thought through and can cause problems later on.

We have IIAs for which empty 200 means permanent DELETE, but we have other objects like LA, Mobility etc, for which 200 empty response is a temporary DELETE.

Why can't we just mention explicitly in the IIA specs that 200 empty response it a permanent DELETE, instead of trying to interpret statements from 2 different sections of the EWP that sums up to say "empty 200 response is a permanent DELETE".

Also somewhere you pointed that only something that was there in the network at some point can be removed from the network. Is there a definition of something "in the network"? Can that be proved always?

What happens when HEI changes a provider? If not coordinated well, it can end up IIAs getting permanently deleted.

[janinamincer-daszkiewicz]

Implementation of DELETE has been thoroughly discussed on the second day of the technical workshop on 2023-10-04. I have put the summary of opinions from the chat to the Excel file and uploaded it to the shared drive (file Chat-Delete.xlsx). The final conclusion is also given in the file. We will come back to it during the upcoming Infrastructure Forum meeting on 2023-10-18. I am very grateful to all participants of this meeting for the fruitful discussion.

[janinamincer-daszkiewicz]

The discussion on Delete is continued in https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/139, so I close this issue.