IIA-INDEX return zero IIAs - that means are they all deleted?

[skishk]

Dear Colleagues,

if as a response of an IIA-INDEX we receive zero elements that means the partner DELETED all his IIAs?

[janinamincer-daszkiewicz]

Yes ;)
Who is the partner?

[skishk]

Yes ;) Who is the partner?

i hoped no... 😅

i opened the tkt ESCI-12135, tell me if you can see it or i'll give you details by email.

Thank you

[janinamincer-daszkiewicz]

Yes, I see it, thank you.

[umesh-qs]

Yes ;) Who is the partner?

Please point to the specifications regarding this.

[umesh-qs]

Yes ;) Who is the partner?

And the receiver is supposed to mark all the IIAs are deleted and never allow to reappear?

[sascoms]

Yes ;) Who is the partner?

I am writing this just as a note to the history as our such proposals were disregarded and even not evaluated...

This was unfortunately a bad solution as it is implicit.

Instead, there should be flags or status elements for deletion just like the termination flags.
And CNRs should have types: delete-cnr, terminate-cnr, modification-cnr, edit-cnr, approval-cnr, termination-approval-cnr, delete-approval-cnr, ...

Termination, deletion, CNRs, ... IIAs workflow has just become more complicated and more problematic with version 7 due to the complex and problematic solutions instead of clear and simple solutions to the problems..

[demilatof]

@skishk

if as a response of an IIA-INDEX we receive zero elements that means the partner DELETED all his IIAs?

@janinamincer-daszkiewicz

Yes ;)

Little particular: the deletion of a mutually approved IIA is forbidden

Instead, there should be flags or status elements for deletion just like the termination flags. And CNRs should have types: delete-cnr, terminate-cnr, modification-cnr, edit-cnr, approval-cnr, termination-approval-cnr, delete-approval-cnr, ...

The delete has been transformed after it was accepted, becoming more and more complicated.
In my opinion, the deletion must be forbidden, as it is now, as concern the mutually approved IIAs; except for this, the deletion should be outside of the network interest, anyone manages the case as he wants in its internal system without claiming anything from partner.

The actual CNR APIs could be enough for all, if we exclude it for the deletion, because everything else is a simple editing (I don't understand the difference between modification and edit).

Termination, deletion, CNRs, ... IIAs workflow has just become more complicated and more problematic with version 7 due to the complex and problematic solutions instead of clear and simple solutions to the problems..

And you forget the revert...
In my opinion, the great problem is that there is no analysis, no good specifications and not a good description of the rules, but only a huge set of scenarios that are raised at the level of specifications.
I try to recall a set of rules that, if well written and accepted, could be enough:

• An IIA in effect (at least once mutually approved) must not disappear forever from the network and not for more than X days
• If an IIA (not in effect) is not available from the partner you cannot claim anything from him and you could manage the event as you want on your system
• Any change to an IIA still available on the network must be notified to the partner as soon as possible (CNR), but the partner could discover it anyway thanks to the Index API
• Any change to an IIA still available on the network must be explicitly approved (IIA Approval) to be in effect when even the other IIA is (or has been) approved
• Until a new approval doesn't supercede the previous one, the last approval is valid and must be returned by IIA Approval
• A change in mapping is commonly allowed only for IIA not in effect (that is, before they mutually approved at least once) and is a normal change; any change in mapping due to the change of a provider (or SCHAC) is an exceptional case that should be faced in an exceptional way (presently, to be discussed)
• The revert and the termination are only particular amendments and therefore they need a new approval to become valid (or to be voided, if previously approved)
• We have the first mutual approval as soon as both of the IIAs are approved and a new approval as soon as one of the IIA is approved again (I don't like this assumption, it's against the BPO mandatory requirements, but this is the only one that the current specifications allow)
• Before sending an Approval CNR you MUST do an IIA-Get to be sure you're approving the IIA that you're considering
• Every time you approve your partner's IIA (Approval CNR), you must save at least: its full IIA as XML (snapshot), the relative IIA Hash and the current time stamp
• Every time your partner invokes your approval you MUST return the last IIA Hash you have saved (see above)
• Every time you receive an IIA Approval for your current IIA (same IIA hash), you must save at least: your full IIA as XML (snapshot), the relative IIA Hash and the current time stamp
• If you receive an empty approval, this mean that the partner doesn't know your IIA or he hasn't approved it yet; the last case is forbidden if your IIA has been approved at least once.
• If you receive an approval with an IIA Hash different from the current IIA Hash of your IIA, this means that your partner is approving a different version: if it is the same of the last approval you received, it means that your partner has not yet approved (or he doesn't want to approve) your current version. Instead, if it's different both from the current and the last approved version, there is an error to look for in your or in his system

If we agree on the above rules (and few all that I forget by sure), what scenarios do we still need?

[sascoms]

The first and the root problem was NOT using a central solution for IIAs.

And one of the second new big problems is that now each partner has to keep two of the copies (and maybe many more snapshots/copies).

I have nothing to say or discuss more after those.

And that is why we and I guess many more providers left talking about or discussing solutions/proposals..

[umesh-qs]

Most of the providers who are criticizing (or may want to in future) accepted and voted in favor of current form of DELETE.
So I do not see any point of starting this discussion again.

[demilatof]

Most of the providers who are criticizing (or may want to in future) accepted and voted in favor of current form of DELETE. So I do not see any point of starting this discussion again.

You're misrepresenting the reality and you should know that we have not voted the current form of DELETE; the current form of DELETE has been depicted later on the need of some providers, if not even only one.
What we voted on 15th February, 2023, was:

And the commit voted was this one:

An IIA that has not been approved can be deleted by removing it from the EWP network.
Such IIA MUST not be present in any of the IIA endpoints and an IIA CNR MUST be sent (see [CNR client part section][cnr-client-part]).
Although removing an IIA from the EWP network should only take place for IIAs that are being permanently deleted,
there is always a possibility for an IIA to reappear, i.e. in case of human error.

The above formulation, in case of one partner deletes an IIA, would have allowed:

• The other partner could be free to do nothing and most important he is not compelled to do anything;
• A "deleted" IIA could reappear (in case of human error)

This is not the current form of DELETE, therefore please stop misrepresenting that vote.

[umesh-qs]

So you (or may be others) are saying the EWP team cheated, by taking vote on something different and adding something else in the specifications. This sounds so funny.
Btw why didn't you (and others) ask for revoting then?

[demilatof]

The first and the root problem was NOT using a central solution for IIAs.

Yes, this is the original sin

And one of the second new big problems is that now each partner has to keep two of the copies (and maybe many more snapshots/copies).

Well, I think that already years ago a good practice should have suggested to keep the snapshot of what is approved, as a proof in every situation, even in respect of our IROs.
Maybe that we, that develop in house, are more in touch with the IROs, but it often happens that they could forget to have seen/approved a particular IIAs and we have to demonstrate that it was not a system error.
This is a consequence of the master-master model; v7 has only compelled providers to be more pailful to this aspect.

I have nothing to say or discuss more after those.

And that is why we and I guess many more providers left talking about or discussing solutions/proposals..

I understand you, but I think that if I, and some others, did the same months ago, now we could have a version 7 worst than this.
I suggested a possible solution months ago, but it was ignored: we have to split the cooperation in two and get rid of the outgoing mobiliites, because we cannot rule in the other HEI, but only accept its rules.
Therefore, in my IIA I write only incoming cooperation conditions for my half of the IIA and you do the same (you write the cooperation conditions for my students that want to study by your HEI). I approve your half of the IIA, you approve my half of the IIA.
If you change something, I'll approve (or not) your new version and this is enough.
When we want to show the full IIA to our IROs, both of us join his half IIA with partner's half IIA and we can trust they are the same.

[demilatof]

So you (or may be others) are saying the EWP team cheated, by taking vote on something different and adding something else in the specifications. This sounds so funny. Btw why didn't you (and others) ask for revoting then?

I can speak for me and you know I already said that several times; once you also asked to vote again when I said I voted for something else (IIA Get before approval, included in the vote for the deletion), if I'm not wrong.
And you know that Janina has always said that it was not possible.
I have been even quite clear and straight during the workshop in Warsaw at the beginning of October, when I polemically left the remote participation to the workshop because they were trying to address a further vote to a worst case (if someone deletes, you have to delete too).
Where were you in those days?

[umesh-qs]

So you (or may be others) are saying the EWP team cheated, by taking vote on something different and adding something else in the specifications. This sounds so funny. Btw why didn't you (and others) ask for revoting then?

I can speak for me and you know I already said that several times; once you also asked to vote again when I said I voted for something else (IIA Get before approval, included in the vote for the deletion), if I'm not wrong. And you know that Janina has always said that it was not possible. I have been even quite clear and straight during the workshop in Warsaw at the beginning of October, when I polemically left the remote participation to the workshop because they were trying to address a further vote to a worst case (if someone deletes, you have to delete too). Where were you in those days?

@demilatof I did not attend the workshop, but my colleagues were there. We were in touch about any contentious proposal and we did not agree to automatic deletion of linked IIA.
I did hear about you leaving the meet abruptly. And I can understand how frustrating it can become to deal with a project, where some individuals opinion supersede any logic and there is no one who can correct this style of working.
That is the reason, myself (and some others) now days, do not participate much in such discussions.